<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Nov 23, 2013 at 6:44 AM, ianG <span dir="ltr"><<a href="mailto:iang@iang.org" target="_blank">iang@iang.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">On 22/11/13 19:30 PM, Phillip Hallam-Baker wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Does anyone know what the Dark Mail Alliance specs might look like?<br>
<br>
I have been trying to contact the principals with no success.<br>
</blockquote>
<br>
<br></div>
Shrink, Steal, Compete.  Don't try and form a committee ;-)</blockquote><div><br></div><div>The last thing we need now is a second VHS vs Betamax standards war on secure mail formats.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><span style="color:rgb(34,34,34)">But, the format is locked into the MUA.  So it has no bearing to anyone, as we can't change the design locked into N*MUAs.</span></div></blockquote><div><br></div><div>
Only the message formats are baked in. The trust model does not need to be managed in the MUA</div><div><br></div><div>I could care less what the format of the messages is. The S/MIME folk have done a very good job of working out how to get their messages through the SMTP infrastructure. Why duplicate that. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I'm obviously missing something here -- what can be done with S/MIME that unlocks the formats within the MUAs?</blockquote><div><br></div><div>No user interface is needed to receive encrypted S/MIME messages. All that is required is that the MUA is configured so it can find the decryption key. That does not need to be done by the MUA, another program can configure that. Alternatively a one time effort to get the cert and key into the MUA.</div>
<div><br></div><div>No user interface is needed to send encrypted messages. That can be done by redirecting outbound mail through a proxy. </div><div><br></div><div>To force encryption of an outbound mail, put a ? in front of the mail address. Let the proxy work out how to send it encrypted.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

I see a need for at least three distinct trust exchange models:<br>
<br>
1) Direct out of band trust.<br>
2) Peer-to-Peer Endorsement<br>
3) CA managed certificates<br>
</blockquote>
<br></div>
3a. root-list supplied CAs<br>
3b. peer- or user-endorsed CAs<br>
<br>
Practically speaking, people will look for endorsements over CAs.  At the moment, there is no choice here, you get imposed by the ubur-CA called the mail vendor, and it is hidden.<br></blockquote><div><br></div><div><a href="http://tools.ietf.org/html/draft-hallambaker-prismproof-trust-00">http://tools.ietf.org/html/draft-hallambaker-prismproof-trust-00</a><br>
</div><div><br></div><div>I don't have quite that model. But I do have the idea of combining peer endorsements and CA endorsements. So the idea is that if I get my key endorsed by a CA, that endorsement is fixed in tie and has a certain work factor associated with it. If I get my key endorsed by a peer, that also has a work factor.</div>
<div><br></div><div>The problem with the peer only model is that it is easy to generate a web of a million keys all purportedly endorsing each other. The trust needs to be grounded. Sprinkling in some CA endorsements into a Web grounds the Web.</div>
<div><br></div><div>So in the CA only model the work factor for a distant key is $100 (say) That is the cost of forging the documents.</div><div><br></div><div>In the Web of trust only model, the work factor for the same key would be $0 because the pat is a friend of a friend of a friend ^n.</div>
<div><br></div><div>In the Web of trust plus 100 CA endorsements model, the cost is $10,000/p where p is some factor to represent fading due to the distance from the endorsements. I think p can be kept to a low number.</div>
<div><br></div><div><br></div><div>I think it is viable to establish a Web of trust with some millions of CA endorsements in it. Which brings the work factor into the hundreds of millions plus a high risk of being caught.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
But in terms of the marketplace and the way users think, what they want is some sort of more localised trust list that they can choose.  E.g., just go with Iang's list or EFF's list or the Politburo's list. Obviously, people in Iran aren't that happy with the USA-dominated list of CAs, and people in the Pentagon aren't that keen on Mozilla's list including an Iranian CA.<br>

<br>
One list does not work.<br></blockquote><div><br></div><div>Actually I am not that bothered about who the CAs are as the CA endorsements would be fixed in time. The attacker does not have a TARDIS to go back in time and forge a key. </div>
<div><br></div><div>We can build a timestamp notary that does not need to be trustworthy.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><span style="color:rgb(34,34,34)">I wouldn't suggest using that old stuff.  Pick something well portable/ported and entirely distinct with a trivially small footprint, so that the code can be delivered in the app without any needs for any external library support.</span><br>
</div>
<br>
You've got a chance to dump the legacy, take it!<br></blockquote><div><br></div><div>Then I lose the chance to use that deployed code.</div><div><br></div><div>Plus I have an ASN.1 compiler and a JSON compiler that can target the language(s) of my choice.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Protocol Buffers from google is the closest thing I've seen of late, but it might already be too complex and require external libraries and developers to learn YetAnotherFormatLanguage. </blockquote><div><br></div><div>
I would rather stick to JSON and add in a length delimited binary chunk type.</div></div><div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>