[Cryptography] multi-key encryption of "meta" data

[Phillip Hallam-Baker]

On Wed, Jul 16, 2014 at 4:45 PM, John Kelsey <crypto.jmk at gmail.com> wrote:
>> On Jul 16, 2014, at 9:46 AM, Phillip Hallam-Baker <phill at hallambaker.com> wrote
> ...
>> The missing links that makes PGP and S/MIME unworkable from a usability point of view are
>>
>> 1) No consistent infrastructure for key discovery
>> 2) No mechanism for stating security policy
>
> (2) seems to me to make for a pretty unworkable system for normal people.  I think I could conceivably get my mom, dad, and sister to understand some specific security policy that was more-or-less global, but not to read through a security policy for every recipient they might want to send to.

Exactly, any user defined policy has to be very very simple and high
level. But some policy details can be set automatically. But even that
is a little tricky. Experience from email spam control is that
security policies often need to be curated.


  The security policy that would make sense there would be something like:
>
> a.  If it comes to you with my from: address through this system and shows up, it's really from me (or at least someone with my private key).
>
> b.  Nothing sent through this system can be read by anyone along the way except the listed recipients.
>
> c.  Nobody can determine that you are sending messages to me or receiving them from me by observing the communications in and out of the system.
>
> More details should be available for those who want them, but don't require people to know or care about them to use the system securely.

That is actually more detailed than I would want a user to see.

The only policy that I would want a user to be setting is 'Encrypted
email is preferred' and there would be a warning box coming up to the
effect 'Hey if you set this then you will only be able to read your
email on devices that you have set up to get you private key, are you
sure?'.


The automatically generated policy elements would be things the client
can determine like the cipher suites it supports (so we can use AES
with S/MIME at last) and the transport protocol options.

To make ubiquitous end to end email viable it is going to be necessary
to have a mechanism to make it easy to update private decryption keys.
At the moment I am using a standalone tool. But this is obviously a
feature I would want to integrate into the clients themselves.

Each device is going to have a per-device authentication key and
encryption key that are permanent for the life of the device, never
get exported type keys. When the S/MIME key is rolled (i.e. once a
month) the devices pull their encrypted copy of the new private key
from a service via OmniPublish. This would also be used to grab the
new authentication keys as needed.


What I definitely want to avoid in the policy layer is complexity. I
do not see the need to make it Turing complete (like policymaker back
in the day).


To make the mechanism palatable to end users I am simplifying the
mechanism for configuring all the parameters an email client needs to
access an account. All Alice should need to connect to an email system
is her email address and the domain of her security provider.

Given those two pieces of information and a previously established
security context at the provider, client should be able to get all the
information it needs to connect to the email account via the security
provider, including any necessary authentication information. All that
the user would need to do is to accept the connection request from
their authorization device and they would get a question 'want to let
this new ipad to connect to your account'


The policy problems do potentially get rather more complex if we move
from email messages to documents in a CRM type system. My longer term
goal is to turn PPE (Personal Privacy Environment) into a CRM scheme
as well just as soon as the Wiener-Ford patent expires.

The reason this gets harder is that when someone sends an email
message they know who it is being sent to. When they write a document
deciding the intended readership is rather more complicated.

Given the abject incompetence demonstrated by the NSA in this area
with two major leaks in as many years, I think this is something that
NIST should be looking into urgently. It is clear that the NSA is
actually the International Insecurity Agency: Their only talent is in
breaking things. They have not done a good job of keeping stuff secret
that should be secret. That is they haven't provided the US with
security, that has not been a priority.