Re: On email and web security

[<[e-mail]>]

"If Alice wants to encrypt the message for a group of people, she has to encrypt the message for every member of the group."

really? not encrypt the message to a random key, then encrypt that key separately to each member? much less processing...
________________________________________
From: ietf <[e-mail]> on behalf of Phillip Hallam-Baker <[e-mail]>
Sent: Saturday, 2 January 2016 8:32:53 AM
To: Doug Royer
Cc: IETF Discussion Mailing List
Subject: Re: On email and web security

On Fri, Jan 1, 2016 at 3:37 PM, Doug Royer <[e-mail]> wrote:
> On 12/30/2015 01:17 PM, Fred Baker (fred) wrote:
>> ...
>>
>> First, I note that this email is going out unencrypted. Why?
>
> Confused - for private lists -I see your point. For public lists, what
> would you want still private after the email is publicly listed on the
> IETF email-list web servers?

The IETF list archives are a public document. But that is not the
general case for mailing lists. And right now we don't have a good
protocol for mailing list security, nor does SMTP handle mailing lists
very well at all.

This is one of the areas where the gap between where we are today and
where we want to be is simply too great to make working on top of the
legacy infrastructure of SMTP, SMIME & PGP viable. All three need
major modification to work. All three will need new code.

Right now I am building tools that apply the Mesh to the IETF
protocols as they are. One necessary component in that infrastructure
is a public email profile that contains information such as :

SignedData {
    "ProfileMailPublic" : {
        "address" : "[e-mail]",
        "name": "Fred Baker",
        "udf": "MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ-SV75J"
        "connection": [{
             "protocol": "SMTP",
             "encrypt": "OpenPGP",
             "prefer": "encrypt",
             "require": "sign",
             "key": { ... key data here ... }
             }]
        }
    }

What this is saying is that Fred prefers to have all his mail sent via
SMTP encrypted using OpenPGP format using the specified key. Without
that piece of information, it is not possible to have a tool that
automatically encrypts mail sent to Fred. Right now I read my mail on
3 desktops, 2 laptops, 1 phone, 2 iPads and a watch. If people send me
encrypted mail I can only read it on the one laptop with the private
key.

Don't worry about the privacy implications at this stage. They are
important but the way to address them is through a kimono protocol.
This is Fred's public profile that is world readable. He might also
have an encrypted profile that is only visible to people once they
connect. It is also possible to obfusticate this profile by encrypting
it under Fred's email address.

One of the reasons I realized something like the Mesh was needed is
that before mail can be sent encrypted by default, there has to be a
way to provision the decryption key out to every device the user might
want to read their mail on. And that process has to be completely
automated and completely under the user's control. I am really fed up
with all these cloud services where I invest my time and effort
managing data that I don't control and gets deleted at the whim of the
developer. Yes, I am talking to you Apple who resets all my settings
with every iOS or OSX upgrade. No I do not want to go through the new
features tour, it might be interesting to you but it is junk mail to
me.


We can also use the same profile mechanism to advertise support for a
new messaging protocol. So people with legacy SMTP clients can still
send mail to Fred but people with clients that support the new
protocol can make use of the new security capabilities.

OK, so what are those capabilities? Well, 20 years ago Matt Blaze and
some other folk invented a concept called Proxy Re-Encryption and now
that we are moving to ECC based encryption, it is a technique that
solves a lot of our current security problems.

Traditional public key exchange is a 2 party protocol, Alice encrypts
the message for Bob. If Alice wants to encrypt the message for a group
of people, she has to encrypt the message for every member of the
group.

Proxy re-encryption or Recryption for short is a technique that allows
Alice to encrypt a message to send to a group and then an untrusted
third party proxy can then recrypt the messages so that each member of
the group can read them but the proxy cannot decrypt the message
itself. This means that the proxy can be a service in the cloud
without introducing a new point of vulnerability which would be the
case if we did this sort of thing with traditional RSA encryption.

One area where this type of capability is valuable is in the mailing
list problem. Another is in an IMAP style mail server where the user
has 8 devices and wants each to have a different decryption key so
that they can re-establish their security is a device is lost,
compromised, whatever. Another place where it is very useful is for
sharing documents in an enterprise. The last is the subject of a
patent claim but fortunately the claim expires in a couple of years.


Recryption is powerful. We could cobble together extensions to SMTP,
IMAP, POP3, XMPP, etc. to make it work, but it is actually rather
simpler to design a new general purpose messaging service that allows
users to upload 'blobs' of content and make them visible to groups of
users through control of their recryption groups (which can be thought
of as a security label).

At root, there isn't any difference between Mail, Mailing Lists, News,
Blogs, Messaging, Chat, VOIP, Dropbox. In every case we have a
protocol in which a user uploads 'chunks' of data that are made
visible to a set of recipients. The only difference is in the way that
the notification takes place and the path the chunks follow.

It is a powerful technique but as I say, encumbered for a couple of
years. So if we build out the user-centric key infrastructure in those
two years, we will be ready to start deploying the schemes when the
patents expire.