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

[Phillip Hallam-Baker]

On Tue, Jul 15, 2014 at 8:07 PM, Jerry Leichter <leichter at lrw.com> wrote:

> On Jul 15, 2014, at 5:03 PM, John Denker <jsd at av8n.com> wrote:
> > It seems to me that the binary distinction between "metadata" and
> > other data is a crock.  As a glaring example of the problem, common
> > protocols for encrypted email encrypt only the main body of the
> > message, leaving /all/ the headers unencrypted.  This is a serious
> > security breach, as discussed below [*].
> >
> > We can do better than this.  We need to do better than this....
> I agree with what you say, but want to inject one note of caution:  We've
> been down this road before, in defining XML security.  The financial
> industries needed to support all kinds of complex trust models and layers
> of authentication and encryption.  The end result some something its
> designers have pretty much disavowed.
>

Actually it was IBM and Microsoft who wanted to sell lots of high priced
consultancy that was the problem with WS-*

I have not exactly disavowed my role there. But I do now have a suite of
code based on JSON that does all the same stuff but the description is less
than 100 pages of RFC of which about half is worked examples.


I agree that we should redo mail. And this is one of the things that I
address in my scheme currently code-named PRISM-PROOF to be launched as
Privacy Protected Everything on Sunday in NYC.

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


Security policy is the vital part. Before Alice sends Bob an email she
needs to know

1) What transport layer protections does Bob's email server support
2) What end-to-end protections does Bob support
3) What end-to-end protections does Bob prefer
4) What authentication would be required to use end to end

2 and 3 might look like the same question but they are slightly different
because Bob probably reads his mail on multiple machines and he might not
have his private key available on them all.


In PPE the solution I adopt is 'Phingerprints' and 'Phingers'. A
Phingerprint is simply a hash of the KeyInfo block of a master public key,
i.e. algorithm + key parameters. A master public key being the root of a
PKI, typically a personal PKI.

A phinger is a JSON document that contains certificates and policy
statements that are signed under a particular master key. The document
itself is not signed but individual policies may be signed.


So in this case if Alice knows Bob's Phingerprint his phinger can be
retrieved automatically via HTTP and the .well-known scheme. This can
contain answers to the policy statements above. It could also contain a
statement of the form 'I accept JMTP, the JSON Mail Transport Protocol'.

So a security policy distribution mechanism is also a mechanism that could
be potentially used for protocol selection as well. And I think it is clear
that any new protocol would make a clean distinction between protocol
metadata (Received headers) and content metadata (To, From, Subject, Date,
Content-Type).


I don't think there would be any point to JMTP though. At this point we
have a whole rash of synchronous and asynchronous messaging protocols that
require different clients even though they are all much more the same than
they are different. An instant message is simply a short email. Chat, Voice
and Video are essentially just a messaging protocol where the peers talk
directly rather than through intermediary servers, Dropbox is just a
version of mail where the outbound MTA stores the bulk of the message until
the recipient requests delivery. Etc. etc.



> The main message has to be:  Keep it as simple as possible.  There's tons
> of stuff that would be "nice to have" but that ultimately it's better to
> live without.  Does email really need its own security model?  Forget the
> data/metadata distinction entirely.  (The main reason it's maintained in
> the mail-related protocols is to support various server-side sorting and
> searching operations - most of which don't work well anyway.)  We have some
> data to deliver; we need a way to specify and resolve who to send it to.
>  We may want to protect against traffic analysis.  These are issues common
> to many transport protocols.  There's little reason - other than history -
> for mail-specific encryption.
>

Quite. I know that it would be much easier to design a new messaging
infrastructure that is secure de novo. Just as it would have been much
easier to work from the basis of PGP rather than S/MIME.

The reason I took the design choices I did is because it is the way that
Tim Berners-Lee approached the Web. In fact he was the person who persuaded
me to do X.509 in the first place. He didn't like SGML any more than I like
ASN.1. But SGML is what the publishing industry had standardized on.


So this has to be a multi-step process:

Phase 1: Give people as much security as is possible with existing mail
clients and protocols. PPE works with unmodified Thunderbird, Windows Live
Mail and Outlook. No plug ins required. Leverage the existing S/MIME and
PGP infrastructures.

Phase 2a: Improve the configuration user experience by migrating the mail
sending functions currently implemented in the PEEP email proxy into the
clients.

Phase 2b: Deploy a next gen key discovery infrastructure built on JSON/REST
protocols and Certificate Transparency approaches.

Phase 2c: Replace the existing PKIX/PGP trust models with a synthesis of
the two. PKIX end entity keys may now be used to endorse other end-entity
keys. All endorsements are timestamped by the notary infrastructure.

Phase 3: Introduce a new messaging protocol that is based on JSON/REST.


Now based on experience of using PROTOGEN, my protocol compiler, I could
deliver specs and reference code for phase 3 in about a week. But nobody
would be in a position to use them till we were well into phase 2.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140716/6ba231cb/attachment.html>