Subject: [perpass] A proposal for developing PRISM-Proof email

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Sep 2013 14:58:57 -0400

We need an email security infrastructure and recent events demonstrate that
the infrastructure we develop needs to be proof against PRISM-class attacks.

By PRISM-class I mean an attack that attempts pervasive surveillance with
budgets in excess of $100 million rather than the PRISM program in
particular.

Neither OpenPGP nor S/MIME is capable of providing protection against this
class of attack because they are not widely enough used. We can only hope
for these to be useful if at least 5% of Internet users start sending mail
securely.

But while the legacy protocols are not sufficient, 95% of the existing work
is fine and does not need to be repeated although there may be some details
of execution that can be improved.

The part that is going to need new research is in the area of trust models.
As someone who has seen the documents said to me this week, given a choice
between A and B, the NSA does both. We have to do the same. Rather than
have a pointless argument about whether Web 'o Trust or PKIX is the way to
go, let everyone do both. Let people get a certificate from a CA and then
get it endorsed by their peers: belt and braces.

The idea in this draft is to split up the problem space so that people who
know email clients can write code to support any of the research ideas that
might be proposed and any of the research ideas can be used with any of the
mail clients that have been enabled.

The draft is to be found at:

http://www.ietf.org/id/draft-hallambaker-prismproof-dep-00.txt

-- 
Website: http://hallambaker.com/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 22 Sep 2013 14:46:18 +0200

>http://www.ietf.org/id/draft-hallambaker-prismproof-dep-00.txt

The document is a bit of a mixed bag mixing analysis, requirements, pro-
posals, and other things in a manner I find hard to follow. To turn this
a bit around, if I wanted to create a secure email system, the first
thing I would probably think about is scope. You mention "PRISM". If
"PRISM" is some sort of "FAA 702" program, and that law seems to be

  [The] Attorney General and the Director of National Intelligence may
  direct, in writing, an electronic communication service provider to

    (A) immediately provide the Government with all information,
        facilities, or assistance necessary to accomplish the
        acquisition in a manner that will protect the secrecy of
        the acquisition and produce a minimum of interference with
        the services that such electronic communication service
        provider is providing to the target of the acquisition;
    ...

one scenario I would think about two people with tablet computers that
run the Acme tablet operating system and they are both using the Acme
Web Mail system through the Acme browser and they are connected to the
Internet over Acme Fibre. Now the United States want to read their mails
to determine whether they or their associates need to be brought free-
dom and democracy, and they tell Acme to make that happen using the law
above. Is the system supposed to help the two exchange mails securely?

Another scenario is that the supposedly secure email system relies on
personal private long-term cryptographic secrets, and then the system
becomes popular. How long before helpful cloud backup and cross device
synchronisation systems compromise the keys? For that matter, how many
will surrender the keys freely to their web mail system, for spam and
virus checks, or a coupon? On Google's Android system you can get some
cloud backup service, but only if you let Google have all "your" Wi-Fi
passwords (which often aren't yours to share with Google).

I also wonder whether active MITM attacks, where the bits on the wire
are changed, are really much of a concern for such a system, compared
perhaps to mass-scale passive eavesdropping; how important is being
able to find out whether your conversations are being monitored?

Another point is compatibility with the deployed email infrastructure.
It seems rather trivial these days to establish new communication sys-
tems to hundreds of millions of users; it's been done quite a number of
times in recent years. It seems to disregarding the deployed protocol
might make many desirable features available that are difficult to fit
in with the existing system, like encrypting subject headers and local
parts of addresses. Similarily, some features might be easy to let go
of, asynchronous offline delivery for instance is less interesting in
a always-on world.

That is what comes to mind thinking about securing the email system and
it is a bit of a long way from there to issues around web browsers ge-
nerating cryptographic certificates or the merits of S/MIME.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Adam Caudill <[email-masked]>
Date: Sun, 22 Sep 2013 16:55:49 -0400

> of, asynchronous offline delivery for instance is less interesting in

As much as I dislike breaking compatibility with the existing infrastructure, I think this might be necessary. I see three significant issues trying to make this work in the current system:

1). As you mentioned, the difficulty of integrating these privacy enhancing features in a system that wasn't designed with this in mind. Building a new system with security and privacy as a primary goal would minimize the compromises necessary to maintain compatibility with current infrastructure.

2). Lack of user confidence / awareness. One of the issues I have with the current email infrastructure is that as a user, I have no idea how my messages are handled once they reach my SMTP server. Is SSL/TLS used for the hop to the recipient's server? How about between the recipient and their server? Are the servers actually validating the certificates? Are they subject to a downgrade attack to force the data to be transmitted in the clear? With this proposal - or likely any proposal to update the current system, the user will remain unaware of this information.

This is one of the areas where browser developers have done (reasonably) well, providing a visual cue indicating if the data is being protected; while not necessarily perfect, it's far batter than what we have for transport security in the email system.

3). Transition time. This likely would be a very long process - and as per section 3.2, during the transition compatibility takes precedence over security. Given how long this transition will take, it's possible that these concessions will still be in play for a number of years to come - opening gaps that could be used to enable PRISM like programs.

If a new system is developed, it would be ideal if it was designed in such a way that gateways could be deployed to provide a compatibility layer with current infrastructure (of course messages traveling across said gateways should trigger some form of alert to the user so they know the security is likely to be reduced).

-- 
Adam Caudill
[email-masked]
http://adamcaudill.com/

---

From: Leif Johansson <[email-masked]>
Date: Mon, 23 Sep 2013 08:29:48 +0200

>> above. Is the system supposed to help the two exchange mails securely?

I think your analysis is correct: legal intercept will often be a right
that sovereign states assign to themselves.

Instead of tilting at that windmill, would it be possible to build a
mechanism for making detection of 3rd party intercept tools and
other malware in software easy?

Maybe we should be talking about transparency (in the sense of
certificate transparency) for software. Maybe it should be *hard*
for a vendor to hide capabilities in software targeted at specific
customers by making it *easy* to audit datasets (like software
binary packages).

        Cheers Leif

---

From: Jon Callas <[email-masked]>
Date: Mon, 23 Sep 2013 08:32:51 +0100

.
> 
> By PRISM-class I mean an attack that attempts pervasive surveillance with budgets in excess of $100 million rather than the PRISM program in particular.

Rather than using a word like PRISM-class to mean something other than what it sounds like (which is a good idea), invent a new term or just say what you mean.

> 
> Neither OpenPGP nor S/MIME is capable of providing protection against this class of attack because they are not widely enough used. We can only hope for these to be useful if at least 5% of Internet users start sending mail securely.

I understand what you are trying to say, but you have now created an objection that all new protocols fail against. So now nothing can meet the requirements because it has to be born with a user base. 

I have been saying that something new should use components that are available now. Each of OpenPGP and S/MIME suffer from nothing more than cruft accumulated over time and things we can do better from the start because we have an additional 20+ years of thought and techniques. 

Throwing them out because we can and should just do better is both bold and simple. 

Jon

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 23 Sep 2013 07:50:20 -0400

On Mon, Sep 23, 2013 at 3:30 AM, Jon Callas <[email-masked]> wrote:

> .
> >
> > By PRISM-class I mean an attack that attempts pervasive surveillance
> with budgets in excess of $100 million rather than the PRISM program in
> particular.
>
> Rather than using a word like PRISM-class to mean something other than
> what it sounds like (which is a good idea), invent a new term or just say
> what you mean.

Maybe that is the case inside the field.

Outside the field, PRISM has a different meaning, one that is very widely
understood and tapping into that is a good way to build critical mass.

> > Neither OpenPGP nor S/MIME is capable of providing protection against
> this class of attack because they are not widely enough used. We can only
> hope for these to be useful if at least 5% of Internet users start sending
> mail securely.
>
> I understand what you are trying to say, but you have now created an
> objection that all new protocols fail against. So now nothing can meet the
> requirements because it has to be born with a user base.
>

I don't think we can expect S/MIME or OpenPGP to get to 5% by just waiting
for the inevitable success like we have been doing for 20 years.

I have been saying that something new should use components that are
> available now. Each of OpenPGP and S/MIME suffer from nothing more than
> cruft accumulated over time and things we can do better from the start
> because we have an additional 20+ years of thought and techniques.
>

Umm, not sure what you mean. I don't want to have to revisit the
interfacing to mail part of the problem which is where most of the horror
show ends up being. And there are a billion+ email clients that are capable
of receiving encrypted email that are worth building on.

I don't think it is the accumulated cruft that is the problem. It is the
lack of key discovery, security policy and the monolithic trust model.

---

From: Scott Brim <[email-masked]>
Date: Mon, 23 Sep 2013 09:17:08 -0400

> other malware in software easy?

Nice idea. Back when I tried, my experience was that it's very hard to
distinguish good intercepts from bad ones. Would you get away from all
middleboxes?

Scott

---

From: Leif Johansson <[email-masked]>
Date: Mon, 23 Sep 2013 16:11:58 +0200

On 09/23/2013 03:17 PM, Scott Brim wrote:
>
>
> On Sep 23, 2013 2:30 AM, "Leif Johansson" <[email-masked]
> <mailto:[email-masked]>> wrote:
I might not be able to get away from them but I would like to know they
exist.

My guess is that endpoint intercept malware will slip through the hands
of govt owners and into the hands of regular criminals at which point I
*really* do want the reporter to be able to know if the local maffioso is
running intercepts on her laptop to find out what she is going to be writing
about next...

        Cheers Leif

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Sep 2013 16:00:55 -0400

> I might not be able to get away from them but I would like to know they

That's interesting if some of your messages are intercepted and others 
are not. But once you see that 100% of your messages are intercepted by 
Big Brother, then it isn't very helpful.

> running intercepts on her laptop to find out what she is going to be writing

Do you expect that it will be easy to tell who is operating the 
intercept? Of that the local maffioso doesn't get his data from a ring 
that intercepts Big Brother's intercept?

	Thanks,
	Paul

---

From: SM <[email-masked]>
Date: Tue, 24 Sep 2013 01:21:12 -0700

Hi Bjoern,
>passwords (which often aren't yours to share with Google).

I'll comment on a part of the above only.  The receiver no longer has 
the ability to perform spam and virus verifications when the message 
(body) is encrypted.  The receiver can ask the users for their keys 
to perform those verifications.  That is already done in unrelated 
scenarios and some of the users hand over their passwords [1].

The question I would ask is what is the secure email system supposed 
to provide to the user.

Regards,
-sm

1. I am not arguing that it is okay to do that.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 24 Sep 2013 14:49:12 +0200

>scenarios and some of the users hand over their passwords [1].

Whoever is meant to read the message can perform, and ask others to
perform, spam and virus checks as they see fit, with little need to
reveal much about the message to third parties (by employing fully
homomorphic encryption, generating noise, pulling blacklists in full
instead of pushing specific items to a third party to check whether
they are on the blacklist, for instance) and the ability to do so
selectively (mails from people I have had a lot of contact with in
the past do not need to be checked for spam, while I might not mind
if strangers have to jump through extra hoops to send confidential
mails to me). That's not on the path of least resistance, of course.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: [email-masked]
Date: Tue, 24 Sep 2013 16:23:09 -0700 (PDT)

> mails to me). That's not on the path of least resistance, of course.

OK... So I believe the goal here to make it harder if not impossible to perform
widespread surveilance on and interception of Internet traffic.

In the case of email, meeting that goal with end-to-end encryption mechanisms
like S/MIME or PGP is necessarily going to mean having a nonnegligable amount
of email traffic encrypted. The minute that happens spammers are going to join
the party in a big way precisely because of the ability this confers to get
past transport-side content inspection and filtering.

State of the art AS/AV vendors employ honeypots and other forms of feedback to
rapidly generate rules, patterns, hashes, and other information, which is then
rapidly distributed to filtering systems attached to vast numbers of ingress
MTAs operated by their customers. Some of this filtering is done on the basis
of IP addresses, envelope, or outer header information, but a lot of it depends
on content analysis - analysis that will be blocked by encryption.

Even so, nasty stuff still makes it through, so vendors also implement various
schemes to "undeliver" mail containing malware that was only detected after
the fact. These mechanisms are if anything even more dependent on content
analysis than ingress filtering is.

It follows that one effect of the widespread use of end-to-end encryption will
be an *enormous* increase in the amount of spam and malware that can't be
blocked at the transport layer and will end up getting delivered to user
mailboxes. Irrespective of what happens to this email after delivery, it's
going to represent a significant cost increase to ISPs and MSPs. Any plan to
significantly increase the use of end-to-end encryption is going to have to
address this issue.

And as for what happens to spam and malware-laden email after delivery, one
reason that things have shifted to a centralized scanning approach is it's been
shown over and over and over again that end users cannot be relied upon to
perform this sort of filtering themselves. So this is another issue that is
going to have to be addressed - how filtering can done reliably at this stage.

For better or worse, while the IETF has been spending time holding PGP key
signing parties and designers the S/MIME extension du jour, the ISPs and MSPs
have been busy building a vast infrastructure used by hundreds of millions if
not billions of people that is heavily dependent on the *lack* of widespread
use of end-to-end encryption. (The need for content analysis by AS/AV
mechanisms is only one example of this; there are many others.)

Any halfway realistic plan to deploy end-to-end encryption at Internet scale is
going to have deal with the totality of contemporary email services and usage
in addition to solving the myriad problems surrounding key/certificate
distribution and management as well as UI issues. (As if the latter weren't
difficult enough.)

Finally, the desire to address the surveilance/intercept problem may be so
strong that people may be tempted to dismiss these sorts of issues as "someone
else's problem". So let me close by noting that quite a lot of spam originates
from infected PCs, and is done by sending those messages using whatever
submission mechanism that user uses, borrowing their credentials in the
process. And if those credentials include a private key, that's going to be
borrowed as well. Anything that increases the rate at which malware makes it to
end user mail accounts is going to increase the rate of infection, and that in
turn is going to compromise the integrity of the end-to-end security system
you're trying to deploy.

				Ned

---

From: Randy Bush <[email-masked]>
Date: Wed, 25 Sep 2013 13:27:44 -1000

> It follows that one effect of the widespread use of end-to-end
> encryption will be an *enormous* increase in the amount of spam and
> malware that can't be blocked at the transport layer and will end up
> getting delivered to user mailboxes.

almost.  for some of us, mailboxes are on hosts we own, and are inside
our trust boundary.  the local delivery agent could decrypt and analyse.
i am not sure i would want the delivery agent decrypting.  but i just
want to point out an opportunity.

randy

---

From: Dave Crocker <[email-masked]>
Date: Wed, 25 Sep 2013 16:50:26 -0700

On 9/25/2013 4:27 PM, Randy Bush wrote:
> almost.  for some of us,

Except that "almost" and "some of us" don't in any way contradict the 
original observation.

As for there possibly being an "opportunity" to make major changes to a 
global, distributed infrastructure that is essential for filtering spam, 
well, uhhh, sure...

No doubt a simple and inexpensive and risk-free endeavor.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Sep 2013 20:12:19 -0400

> past transport-side content inspection and filtering.

Yes, I anticipated that problem. Though I am not sure what the solution is.
I consider this to be part of the 'research' problem and didn't want to
bias the paper describing the decomposition of the problem.

One approach would be to only accept encrypted mail if it is signed by
someone in my circle of trust or an adjacent circle. Which is one of the
reasons I started looking again at a hybrid of Web o' Trust and CA managed
trust.

One option would be that a notary allows parties registered to notarize up
to 10 key endorsements per week, pick a limit, the bad guys need thousands
of disposable addresses every hour.

Another would be to get an EV cert and use that to endorse EE certs as
legit. Consumers are not going to want to spend that sort of money but it
is probably the cheapest solution for an enterprise.

> on content analysis - analysis that will be blocked by encryption.

And you need malware blocking and quite a bit of other stuff which is why I
suspect that some enterprises will not permit genuinely end-to-end
encrypted email. In fact some are blocked by regulation.

> distribution and management as well as UI issues. (As if the latter weren't

The key distribution and key endorsement infrastructure counts as
'research' for that reason.

But we can certainly put together a system that is adequate for use within
the security community and provides transparent security. That is kind of a
no-brainer to deploy since the bad guys have always known that spying on
security researchers is most likely to reveal important info. Mitnick was
no genius, he just hacked the voicemail of the VMS security guru.

---

From: Carl Wallace <[email-masked]>
Date: Thu, 26 Sep 2013 22:40:51 -0400

From:  Phillip Hallam-Baker <[email-masked]>
Date:  Thursday, September 26, 2013 8:12 PM
To:  <[email-masked]>
Cc:  SM <[email-masked]>, perpass <[email-masked]>, Bjoern Hoehrmann
<[email-masked]>
Subject:  Re: [perpass] A proposal for developing PRISM-Proof email

> Yes, I anticipated that problem. Though I am not sure what the solution is. I
> consider this to be part of the 'research' problem and didn't want to bias the
> paper describing the decomposition of the problem.
> 
> One approach would be to only accept encrypted mail if it is signed by someone
> in my circle of trust or an adjacent circle. Which is one of the reasons I
> started looking again at a hybrid of Web o' Trust and CA managed trust.
> 
> 
> One option would be that a notary allows parties registered to notarize up to
> 10 key endorsements per week, pick a limit, the bad guys need thousands of
> disposable addresses every hour.
> 
> Another would be to get an EV cert and use that to endorse EE certs as legit.
> Consumers are not going to want to spend that sort of money but it is probably
> the cheapest solution for an enterprise.

Another would be to encrypt using multiple keys for each recipient.  This
could help with the multiple device problem.  The set of keys used could
include a key for a filter if desired.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Sep 2013 11:34:54 -0400

On Thu, Sep 26, 2013 at 10:40 PM, Carl Wallace <[email-masked]>wrote:

> Cc: SM <[email-masked]>, perpass <[email-masked]>, Bjoern Hoehrmann <
> [email-masked]>

I came to the exact opposite conclusion, that the decryption key needs to
be shared across every device and with no predetermined expiry.

You have no idea which of the devices I use that I might read your email
on. I have 2 desktops, 2 iphones, one iPad and 3 laptops in regular use.
And that is just the ones that I consider essential.

The set of devices changes at least once a year. The MacBook typically
lasts about 6 months between visits to Apple customer service.

There is no security advantage to having mail sent to me encrypted under a
different key per device. There is however an advantage to having mail
signed under a different key per device and not sharing those across
devices .

---

From: Carl Wallace <[email-masked]>
Date: Fri, 27 Sep 2013 11:37:54 -0400

> I came to the exact opposite conclusion, that the decryption key needs to be
> shared across every device and with no predetermined expiry.
> 
> You have no idea which of the devices I use that I might read your email on. I
> have 2 desktops, 2 iphones, one iPad and 3 laptops in regular use. And that is
> just the ones that I consider essential.
> 
> The set of devices changes at least once a year. The MacBook typically lasts
> about 6 months between visits to Apple customer service.

Sure, but you know what keys are on each device and could publish those
accordingly.  You also know the key of your filter.  If the sender encrypted
to your set of keys (instead of single key as is current practice), there
are a couple of potential advantages.

> different key per device. There is however an advantage to having mail signed
> under a different key per device and not sharing those across devices .

No security advantage, but a usability advantage.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Sep 2013 12:30:27 -0400

> No security advantage, but a usability advantage.

I think it is better to work on making it easier and more secure to import
the keys. Here is the scheme that I am currently coding for.

Note that at present I am only considering how to configure to RECEIVE and
decrypt the emails in existing clients. I know that much work is going to
have to be done with those clients before it is practical to use them for
signed mail or to send encrypted mail. But I don't need to be able to send
encrypted mail on every single machine and this can be done with a local
proxy in any case. But I absolutely MUST be able to read anywhere.

Step 1: To generate my first key:

I run the KeyMan tool as follows:

keyman /generate [email-masked] /service hallambaker.com /share 5

hallambaker.com is just the pki equivalent of a news server, it is a
gateway to the trust infrastructure (whatever that turns out to be) not the
infrastructure itself. I assume that there will be multiple trust models.

In production mode, the omniconnect service to use and the necessary
credentials will be defined as a Windows registry or other platform/user
config file. I have included it here so that it is visible.

[This is the line mode version of the tool but it is easy to write a UI
version as the interaction is trivial.]

What this does is to

* Generate an RSA2408 keypair (the default alg)
* Choose a random 256 bit password to encrypt it with AES256 in a PKCS #12
* Generate a self signed certificate for 10 year validity and a CSR
* Submit the CSR, Self Signed cert and PKCS12 to the OmniRegistration
service at hallambaker.com
* Installs the private key on the machine and configures any email client
on the machine to allow use of the key/self signed cert to decrypt messages.
* Prints out the five key shares for the 256 bit password to the console in
groups of five Base32 characters.

[The arbitrary defaults can be over-ridden of course]

The user is instructed to write down the five key shares, three of which
can be used to reconstruct the key. These can be sent to a printer, but
that leads to security issues with the printer having a cache and we
probably don't want to add a printer to some builds such as a Raspberry Pi
running a stripped / secured stack.

The ordinary user would just choose the default and have one password to
write down.

At this point the email clients on that particular machine can decrypt
email encrypted under the self-signed certificate. Now one twist that I
have not looked into quite yet is whether this would also allow those email
readers to decrypt messages to the same key but under a different
certificate. I suspect not for the existing clients and protocols but we
could make this possible in principle by adding an extension into any
certificates generated by a CA to tell clients that the private key is to
be found in the self signed cert container. Alternatively an IMAP proxy
might rewrite the S/MIME messages for me.

This would allow the next step to be eliminated.

1a) To enable use of a CA issued certificate on the machine

keyman /register [email-masked] /service  hallambaker.com

Note that there are no files involved. The tool is going to talk to the
service and only the service.

* Tool retrieves the issued cert(s) from the service and installs them for
use transferring the private key obtained earlier.

At this point the tool might ask the user for the key shares so that the
ability of the user to decrypt their key can be verified before telling the
service to mark it as 'live'.

2) To enable use of a CA issued certificate on a different device

keyman /register [email-masked] /service  hallambaker.com
[user types in their key shares]

If the device is a completely new one it will configure the email service
info as well as the private key.

Considerations:

This is only for encryption keys. There should be a separate signature key
for every device.

Private keys should never move off a device to which they have been
installed. It might well be desirable to let a user generate keypairs on
one particular device under controlled circumstances. For example, I might
dedicate an SD card to containing a Raspberry Pi build for this exact
purpose and only use it for this purpose, generating an encryption keypair
and a set of signing keypairs for all my devices in one go, then erasing
the contents at the end.

While some folk might object to storing their encrypted private key in the
cloud, I doubt that the risk is worth worrying about. If AES256 is broken
then we are toasty toast and no need to worry about anything. The data is
almost certainly going to have to sit on the endpoint machine in less than
perfect security.

Most users probably don't need to bother with keyshares. A single password
will be enough for them. Or they might have a password for personal use and
keyshares registered so that survivors can reconstruct the key if needed.

Printing the keyshares out on paper is much simpler and more reliable than
use of USB fobs or the like. A malicious actor could copy the data but I
don't see that mattering in this particular application. The point is to
convince the user that they are not going to loose their data due to a
hardware failure under any circumstances.