Subject: Re: On email and web security

From: Doug Royer <[email-masked]>
Date: Fri, 1 Jan 2016 13:07:05 -0700

On 12/31/2015 10:00 PM, Phillip Hallam-Baker wrote:

> ...
> I have released the code:
> http://sourceforge.net/projects/mathematicalmesh/
> 

For those wanting to build the code, it looks as if you need at least VS
2012 with framework 4.6. Not having build MS code for while, I had 4.5 -
updating.

Its in C#.

-- 

Doug Royer - (http://K7DMR.us / http://DougRoyer.US)
[email-masked]
714-989-6135

---

From: Doug Royer <[email-masked]>
Date: Fri, 1 Jan 2016 13:37:26 -0700

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?

--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 1 Jan 2016 15:48:49 -0500

> 2012 with framework 4.6. Not having build MS code for while, I had 4.5 -

Since it is open source code, contributors can use Visual Studio 2015
Community edition free of charge. Or at least that is my understanding
of the license.

https://www.visualstudio.com/en-us/products/visual-studio-community-vs.aspx

The point of this release is to prove that what I show in the
demonstration is actually feasible and has been implemented. This is
not production code.

The reason for moving to .Net 4.6 is that Microsoft is currently in
the process of releasing .Net Core on Linux and OSX. I took the gamble
early on that this would happen and so I could use C# for all the code
development. Which is a big advantage when you use as many code
generators as I do.

Now I have not actually run the code on Linux or OSX yet, but it does
pass the tests in the compatibility checking tools.

The code does make use of some, OK a lot of build tools. These are
also open source and available on SourceForge. BUT, probably best to
wait a couple of days since I am currently getting to grips with the
VSIX packaging tools that make installing and using custom tools a LOT
easier. I am just writing a tool that will generate the packaging code
bindings.

The build tools also generate text for the documentation. Hence when I
finally get an Internet draft out, the text in the draft, the examples
and the reference code should all be in sync.

There is also a limitation in that the current code does not have the
DNS library linked in (oops forgot!) so right now the IP address of
the service is hardcoded. Will fix that after doing the demos. I have
a DNS parsing/generating library but have not added that to this
project base yet. The client should discover the service via SRV
lookup.

This particular release has code that will automatically configure the
S/MIME config in Windows Live Mail to use a self signed certificate
generated by the toolset. Comodo Group currently issues free S/MIME
certs and we are working on a way to get a free CA issued cert using
the tool in the very near future.

This is NOT a simply scheme to get people to use CA issued keys rather
than PGP or SSH however. I have written on this at length: The short
is that we need both a hierarchical and a web of trust based
infrastructure to meet all of our user-account trust needs. If I am
writing to Fred in his IETF capacity, I want to use an encryption key
that I trust for Fred. But If I am configuring my GIT repository to
receive code from [email-masked], it is absolutely essential that the
code is endorsed by the Cisco trust chain and not just my personal
relationship with Fred.

People will obviously want support for OpenPGP as well. But that is
not my immediate priority because the point of this code is to show
what can be done, if we can take a legacy application like Windows
Live Mail and enable the crypto in that without the need for any sort
of plug-in, we can obviously use the Mesh for OpenPGP. They way I
would want to support OpenPGP is to extend the OpenPGP libraries to
include the ability to import/export keys using the Mesh.

In the short term, a tool to manage SSH keys using the mesh is going
to be a lot more useful to a lot more people. Yes, people have 'ways'
to manage SSH keys today but the instructions people are being given
to follow are of the 'how to make this work' type, not 'how to be
safe'. More than half the instructions I found telling people how to
configure SSH keys for GIT left the private key sitting unencrypted on
a world readable directory.

Using the Mesh to move keys around means that we can build best
security practices into the protocol. Keys are automatically encrypted
during transport and are only ever decrypted on the target device.
Every device has a separate key set, etc.

The reason for targeting SSH is also that is the highest leverage
point right now. As far as IETF is concerned, SSH is a terminal
protocol. But right now, the SSH key infrastructure is what is
underpinning the production of most source code, either in GIT (or SVN
I presume?).

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 1 Jan 2016 16:32:53 -0500

> 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" : "[email-masked]",
        "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.

---

From: <[email-masked]>
Date: Sat, 2 Jan 2016 07:25:42 +0000

"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 <[email-masked]> on behalf of Phillip Hallam-Baker <[email-masked]>
Sent: Saturday, 2 January 2016 8:32:53 AM
To: Doug Royer
Cc: IETF Discussion Mailing List
Subject: Re: On email and web security

SignedData {
    "ProfileMailPublic" : {

---

From: Steve Crocker <[email-masked]>
Date: Sat, 2 Jan 2016 03:48:33 -0500

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, <[email-masked]> <[email-masked]> wrote:
> 
>

---

From: "John Levine" <[email-masked]>
Date: 2 Jan 2016 15:38:04 -0000

>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.

FYI, the Sympa list manager which is widely used in Europe does the
latter, S/MIME key for the list, and the list software re-encrypts the
messages to the recipients' keys.

Given a choice between trusting the list software and trusting all of
the subscribers, that seems a reasonable way to do it.

R's,
John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 2 Jan 2016 12:13:03 -0500

> really? not encrypt the message to a random key, then encrypt that key separately to each member? much less processing...

That is how it is done under the covers, yes. But that is the sort of
optimization that I assume everyone knows.

With standard S/MIME or PGP, the final message has a decryption blob
for every recipient. So if you are sending to the IETF list, there are
three consequences:

1) The sender has to know the entire recipient list
2) Every message sent reveals the entire recipient list
3) The recipient list cannot be expanded after the message is sent

Using the recryption approach, the sender only encrypts the message
once, to the key corresponding to the group (or security label if you
want to think of it that way). So messages don't disclose anything
about the other list members.

This isn't just better security, it is a lot easier to implement
because senders don't need extraneous information. It is also more
manageable because a member added to the list after the fact can read
all the messages in the archive.

This really is the way to do Content Rights Management and we should
use it to lock down every word processor and spreadsheet document.
Imagine being able to configure your information environment so hat
all your files are encrypted by default but you have access to them
from any machine you configured for access in the past or add in the
future.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 2 Jan 2016 12:24:51 -0500

> the subscribers, that seems a reasonable way to do it.

Using recryption means that you can meet both properties at once.

It is a very powerful tool and I remember Matt Blaze coming to tell us
about it. We have ignored it for 20 years.

---

From: Doug Barton <[email-masked]>
Date: Tue, 12 Jan 2016 17:32:49 -0800

> 2) Every message sent reveals the entire recipient list

Not necessarily ... there are ways to encrypt a message without 
revealing the encryption keys that it was encrypted to. They are 
slightly messier for each list member to decrypt if they have multiple 
keys, but for users who only have single keys they are actually quite 
painless.

> 3) The recipient list cannot be expanded after the message is sent

That's no worse than current mailing list software.

> all the messages in the archive.

Doesn't this require each member to have the group's private key so that 
they can decrypt the messages? I thought (but have not verified) that 
such systems decrypt the message with the group's private key, then 
re-encrypt it to the public keys of the list members at that point in time.

That would mean of course that you would only be able to decrypt 
messages from the time period where you were a member of the list.

Doug

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 12 Jan 2016 21:27:00 -0500

On Tue, Jan 12, 2016 at 8:32 PM, Doug Barton <[email-masked]> 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...
>>
>>
> Not necessarily ... there are ways to encrypt a message without revealing
> the encryption keys that it was encrypted to. They are slightly messier for
> each list member to decrypt if they have multiple keys, but for users who
> only have single keys they are actually quite painless.

Not without modifying the specs and the apps you can't. If you are
going to do that then proxy recryption does exactly what you want.

> they can decrypt the messages?

No, each user has their own private key. It is supplied by the group
admin when they subscribed or it is encrypted under their public key
and sent out with each message.

> I thought (but have not verified) that such
> systems decrypt the message with the group's private key, then re-encrypt it
> to the public keys of the list members at that point in time.

That is what my understanding of how it is done today by the systems
out there. What I am saying is that twenty years ago Matt Blaze showed
us a better scheme and nobody seemed to notice the importance at the
time.

> That would mean of course that you would only be able to decrypt messages
> from the time period where you were a member of the list.

If you use the old technology, that is one of the problems. The other
is that you have to find someone you trust to run the mailing list or
the jabber contact service or whatever.

---

From: Doug Barton <[email-masked]>
Date: Tue, 12 Jan 2016 22:33:37 -0800

> going to do that then proxy recryption does exactly what you want.

It's in GnuPG for years now:

--throw-keyids

Do  not  put the recipient key IDs into encrypted messages. This
helps to hide the receivers of the  message  and  is  a  limited
countermeasure against traffic analysis. ([Using a little social
engineering anyone who is able to decrypt the message can  check
whether  one  of  the other recipients is the one he suspects.])
On the receiving side, it may slow down the  decryption  process
because  all  available  secret keys must be tried.

There is another option as well that works similarly, but for single 
recipients.

> and sent out with each message.

So they have *a* private key for the list, just not necessarily *the* 
private key. I suppose that might make it easier to revoke someone's 
read access after they've been removed from the list ... it also means 
they can't read anything from before they joined, unless the archives 
get re-encrypted.

> If you use the old technology, that is one of the problems.

Well, yeah. :)  Did I miss a proposal for new tech?

> The other

Well that's a given no matter what solution you choose. If you're 
relying on someone else to do encryption on your behalf, you have to 
trust them. But that's a marginal increase in trust compared to running 
a non-encrypted list in the first place.

Doug

---

From: Dave Cridland <[email-masked]>
Date: Wed, 13 Jan 2016 08:23:05 +0000

On 13 Jan 2016 06:33, "Doug Barton" <[email-masked]> wrote:
> Well that's a given no matter what solution you choose. If you're relying
on someone else to do encryption on your behalf, you have to trust them.
But that's a marginal increase in trust compared to running a non-encrypted
list in the first place.

If I understand proxy re-encryption correctly - and I almost certainly do
not - then there are four roles. It'd be really useful to be shot down on
any misunderstandings here. Note that I have no clue how the maths works,
and have therefore attributed this to the crypto-fairies.

The sender, who has the private keys for themselves, and the public key of
the proxy.

The proxy, which has the recryption keys of the members.

The members, who each have their own private keys.

The administrator, who has magic fairy dust allowing new keys to be added
as members of the proxy.

When senders send to the proxy, they're encrypting in a special way which
means that the proxy can't decrypt; instead it can only re-key the message
to each member. The proxy also cannot add other keys (including its own),
so cannot just add itself as a member and decrypt the result. Members
receive the message, and thanks to the crypto-fairies, they see it as
signed by the sender. I like to think of this as a special-case of
homomorphic encryption, but only so I can sound like I know what I'm
talking about.

Members provide their public key to the administrator on joining; the
administrator then applies magic fairy dust to provide the proxy with a
recryption key specific to that member.

Reading Phillip's message, it seems that last bit may be wrong - perhaps
each member gets a key pair from the administrator. That would be rather
disappointing, since it requires the administrator to be much more trusted
than I'd hoped for. If I understand the literature correctly, though, the
proxy never has access to the private key.

I suspect that while Phillip is using the mailing list case to explain it,
proxy recryption is a much better fit when the members are your devices,
the administrator is you, and the proxy is your account-proxy in XMPP, or
your IMAP server (perhaps) in mail. The limitations of administrators
having to provide keys become much more manageable then.

For those not blessed with XMPP knowledge, the bare jid - [email-masked]
- is actually hosted on the server and can trivially see every message;
each connected device has a full-jid, [email-masked]/resource, so the
bare jid would be the recryption proxy and everything works out very neatly
with the existing model.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 13 Jan 2016 10:03:11 -0500

> Well, yeah. :)  Did I miss a proposal for new tech?

Yep, we all did. Twenty years ago.

> Well that's a given no matter what solution you choose. If you're relying on
> someone else to do encryption on your behalf, you have to trust them. But
> that's a marginal increase in trust compared to running a non-encrypted list
> in the first place.

That is precisely the point. With proxy re-encryption 'recryption' you
do not need to trust the mailing list server. Only the list admin
needs to be trusted with the master decryption key.

The reason for bringing this up right now is that it is a technique we
should start to look at using as soon as implementations of the CFRG
algorithms start becoming available.

---

From: Doug Barton <[email-masked]>
Date: Wed, 13 Jan 2016 13:13:21 -0800

On 01/13/2016 12:23 AM, Dave Cridland wrote:
> When senders send to the proxy, they're encrypting in a special way
> which means that the proxy can't decrypt; instead it can only re-key the
> message to each member. The proxy also cannot add other keys (including
> its own), so cannot just add itself as a member and decrypt the result.
> Members receive the message, and thanks to the crypto-fairies, they see
> it as signed by the sender. I like to think of this as a special-case of

I don't see any way that this could work using PGP, but I confess I 
don't know enough about S/MIME to know if it could be done using it or not.

Doug

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Jan 2016 14:23:58 -0700

> needs to be trusted with the master decryption key.

And you would have to trust the mailing list software verified that the
incoming email was encrypted, and by a trusted source, and only accepted
encrypted email.

If the list server accepted unencrypted email, encrypted it with the
lists key, would anyone be able to tell?

--

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 14 Jan 2016 07:33:58 +1000

> lists key, would anyone be able to tell?

If it comes in plaintext, nothing stops the server (algorithmically or
morally) from adding a header or some body text that says "I encrypted
this, but before that it was clear"

At least then the recipients would know the message they received is the
one the list server distributed, even if not the original author.

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Jan 2016 15:34:30 -0700

On 01/13/2016 02:33 PM, Matthew Kerwin wrote:
> 
> On 14/01/2016 7:25 AM, "Doug Royer" <[email-masked]
> <mailto:[email-masked]>> wrote:
>>

A person that replied to the list message, and had expected the
conversation to be secure, might want to know that part of the
conversation was not secure.

So, I would think that an added header would be a MUST.

In ether case your trusting the list server implementation,
configuration, and site admins and not just the list admin with the list
key as commented above.

It would also be a hole where a subpoena could allow anyone to see the
communications. After decryption, and before re-encryption. For those
that really want a secure list.

In addition, users of the list would have to trust that the
implementation, configuration, or site admins would forward only
encrypted emails to other list members, else its only secure at the
endpoints that happen to use encryption.

How could you tell that the encrypted email sent to a list server did in
fact encrypt the email when it forwarded the email to all recipients?

So, I can't see how anyone that wanted a secure communication could
trust re-encrypted list forwarding. (or at least how I understand this
idea as described in this thread).

--

---

From: "John Levine" <[email-masked]>
Date: 13 Jan 2016 23:30:02 -0000

>don't know enough about S/MIME to know if it could be done using it or not.

The one list manager that I know of that actually does S/MIME, Sympa,
sends a separate copy of the message to each recipient encrypted to
his key.  I think it's more likely because it's easier to code than
due to security concerns since the list management software usually
lets each subscriber look at the subscription list and archives.

With respect to Doug Royer's question, I believe one normally
configures an encrypted list to accept only encrypted submissions.  At
some level you have to trust the list software not to lie too badly
about what it's doing.

R's,
John

---

From: Doug Barton <[email-masked]>
Date: Wed, 13 Jan 2016 16:34:41 -0800

On 01/13/2016 03:30 PM, John Levine wrote:
> his key.

Well the question I responded to was wondering if there was a way to 
have the list software re-encrypt to the members without being able to 
decrypt the message first. If I understand correctly, you're saying that 
S/MIME can't do that either?

Doug

---

From: "John Levine" <[email-masked]>
Date: 14 Jan 2016 02:43:14 -0000

>S/MIME can't do that either?

Not unless there is something hidden inside all of the X.509 glop that
I'm unaware of.  Message bodies are encrypted with a session key
which is in turn encrypted with the public keys of the message
recipients.  Nothing magic there.

R's,
John

---

From: Doug Barton <[email-masked]>
Date: Wed, 13 Jan 2016 20:26:47 -0800

> recipients.  Nothing magic there.

Right-O, thanks for clarifying. :)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 14 Jan 2016 01:23:12 -0500

> recipients.  Nothing magic there.

You end up having to modify the clients that decrypt the messages.

The sender merely needs to use an encryption scheme that is based on
an algorithm that there is a recryption scheme for. I have only seen
Diffie Hellman based schemes. But since the receiver code is likely to
be for the new CFRG ECDH algorithms, you are backed up on the sender
and receiver side.

There are probably ways you could shoehorn this into S/MIME and
OpenPGP but why not do the job right and extend wherever necessary?
the client code has to change anyway.

---

From: George Michaelson <[email-masked]>
Date: Thu, 14 Jan 2016 16:35:19 +1000

I thought bloom filters + cryptography == group crypto.

(not a cryptographer, deep trawling memory of articles read many years ago)

On Thu, Jan 14, 2016 at 4:23 PM, Phillip Hallam-Baker <[email-masked]
> wrote: