<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 15, 2014 at 8:07 PM, Jerry Leichter <span dir="ltr"><<a href="mailto:leichter@lrw.com" target="_blank">leichter@lrw.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Jul 15, 2014, at 5:03 PM, John Denker <<a href="mailto:jsd@av8n.com">jsd@av8n.com</a>> wrote:<br>

> It seems to me that the binary distinction between "metadata" and<br>
> other data is a crock.  As a glaring example of the problem, common<br>
> protocols for encrypted email encrypt only the main body of the<br>
> message, leaving /all/ the headers unencrypted.  This is a serious<br>
> security breach, as discussed below [*].<br>
><br>
</div>> We can do better than this.  We need to do better than this....<br>
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.<br>
</blockquote><div><br></div><div>Actually it was IBM and Microsoft who wanted to sell lots of high priced consultancy that was the problem with WS-*</div><div><br></div><div>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.</div>
<div><br></div><div><br></div><div>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.</div>
<div><br></div><div>The missing links that makes PGP and S/MIME unworkable from a usability point of view are</div><div><br></div><div>1) No consistent infrastructure for key discovery</div><div>2) No mechanism for stating security policy</div>
<div><br></div><div><br></div><div>Security policy is the vital part. Before Alice sends Bob an email she needs to know</div><div><br></div><div>1) What transport layer protections does Bob's email server support</div>
<div>2) What end-to-end protections does Bob support</div><div>3) What end-to-end protections does Bob prefer</div><div>4) What authentication would be required to use end to end</div><div><br></div><div>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. </div>
<div><br></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>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'.</div>
<div><br></div><div>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).</div>
<div><br></div><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>So this has to be a multi-step process:</div><div><br></div><div>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.</div>
<div><br></div><div>Phase 2a: Improve the configuration user experience by migrating the mail sending functions currently implemented in the PEEP email proxy into the clients. </div><div><br></div><div>Phase 2b: Deploy a next gen key discovery infrastructure built on JSON/REST protocols and Certificate Transparency approaches.</div>
<div><br></div><div>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.</div>
</div><br></div><div class="gmail_extra">Phase 3: Introduce a new messaging protocol that is based on JSON/REST.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
</div>