Yes, this is what was meant. Any of the encryption methods for email -- PGP, PEM, SMIME -- generate a symmetric key and use it once to encrypt the text of the message and then the symmetric key is encrypted with the receiver's public key. To send a message to multiple recipients, the symmetric key is encrypted separately with each of the recipients' public keys and all of these are included in the message.
To send to a mailing list, the sender must either have a copy of the list or the system managing the list must decrypt and re-encrypt the message. Neither of these is a good fit with the current email architecture. The former is secure but unwieldy; the latter is reasonably efficient but breaks the desired end-to-end security.
Steve
Sent from my iPhone
> On Jan 2, 2016, at 2:25 AM, <l.wood@xxxxxxxxxxxx> <l.wood@xxxxxxxxxxxx> wrote:
>
>
> "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 <ietf-bounces@xxxxxxxx> on behalf of Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx>
> 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 <douglasroyer@xxxxxxxxx> 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" : "fred@xxxxxxxxx",
> "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.
>