<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 18, 2014 at 5:57 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=""><div class="h5">On 18/03/2014 04:35 am, Tony Arcieri wrote:<br>
> On Sun, Mar 16, 2014 at 1:44 PM, ianG <<a href="mailto:iang@iang.org">iang@iang.org</a>> wrote:<br>
><br>
>> Further, in some sort of foreseeable future, CAESAR comes out and we now<br>
>> have a suite of AE algorithms, so even ChaCha/Poly is starting to look<br>
>> like last year's fashion, not cool.<br>
><br>
><br>
> AES-GCM is arguably good enough. I wish more effort were invested in<br>
> creating a new, modern TLS stack that isn't completely terrible, or<br>
> creating a protocol to replace TLS which is built atop CAESAR-style<br>
> authenticated stream ciphers.<br>
><br>
> If I were to try to create a crypto contest, its goal would be to create a<br>
> better transport encryption protocol.<br>
<br>
<br>
</div></div>Sounds good to me.  There are two general efforts that I know of:<br>
google's QUIC and a project by DJB and friends called TP Curve or<br>
something (I can never find it, can anyone?).<br>
<br>
It's not impossible, I do one myself that is more purposed at financial<br>
transactions but has migrated over time to being an also-ran contender.<br>
 I reckon a competition would bring out o(10) contenders.<br>
<br>
Although with a nod to PHB, he's looking for help on his messaging<br>
project, not on his TCP/TLS replacement ;)</blockquote><div><br></div><div>That is the aim. Only for obscure reasons I am this morning working on transport layer encryption for DNS.</div><div><br></div><div>One of the modules on which I am building my messaging proposal is a scheme called Omnibroker. The idea of Omnibroker is that in certain situations you are better off putting complex trust decisions in a cloud based service rather than embedding them into the end points. </div>
<div><br></div><div>For example, if you want to do research on new trust models, you probably don't want to start off embedding that code in the end points. Otherwise you have to change every client every time you tweak the trust model. That is no way to run an experiment.</div>
<div><br></div><div>Alternatively, consider the day you want to run PKI to your SousVide, coffee pot and telly. You probably don't want to have to manage PKI on a device that has no user interface. So the trust configuration is going to come from outside. Better to keep it there.</div>
<div><br></div><div>Now before people start getting hot under the collar, remember that 'the cloud' simply means 'some place I haven't decided yet'. The cloud could be off in an Amazon data center, a Comodo SOC or it might be on a RaPi that you configured yourself using an SD card with a golden distribution of ubuntu having personally checked the hash code with Mark Shuttleworth, Linus Torvald and Rebecca Watson.</div>
<div> </div></div><br clear="all"><div>So to be completely general the Omnibroker service answers questions such as:</div><div><br></div><div>* What is the trusted value of current time</div><div>* How does X connect to Y to perform protocol Z</div>
<div>* Is this credential valid for Y</div><div><br></div><div>The first only needs to be accurate to a second or a minute to be a vast improvement on current security systems. I don't so much care about the time being right to the milisecond as that an attacker can't unwind me by more than a few minuted.</div>
<div><br></div><div>The second gives rise to </div><div><br></div><div>* How does <a href="mailto:alice@example.com">alice@example.com</a> send to <a href="mailto:bob@example.net">bob@example.net</a> using mail</div><div>
* How does <a href="mailto:alice@example.com">alice@example.com</a> send to <a href="mailto:bob@example.net">bob@example.net</a> using chat<br></div><div>* How does * connect to <a href="http://www.example.com">www.example.com</a> using HTTP</div>
<div><br></div><div>These are very abstract questions. The idea of having a trust service answer them is that it can say things like</div><div><br></div><div>* Use SMTP to 10.1.2.3 port 25, expect STARTTLS, cert hash is X</div>
<div>* Use HTTPS to 10.3.4.3 port 443, cert hash is Y ignore the subject data, don't put up UI chrome signaling security</div><div><br></div><div>And those answers can come in two flavors:</div><div><br></div><div>* Just the conclusions (a trusted query service)</div>
<div>* The conclusions with proof (DNSSEC, cert chains, etc)</div><div><br></div><div><br></div><div>So anyway, the protocol consists of two parts, a key exchange part to establish a kerberos like ticket and a query/response part. The query/response part is very simple, very easy to do. The key exchange part is a lot more complicated because there are different use cases in which the client must be authenticated using a lightweight scheme, a strong scheme, not authenticated at all or possibly with some form of anonymity.</div>
<div><br></div><div>All the complexity goes into that key exchange. Which for crypto purposes I am actually punting on to rely on TLS right now for the crypto part.</div><div><br></div><div><br></div><div>So having developed a scheme that does the very abstract protocol, it seems completely sensible to then reuse the difficult and complex part to also support the 'DNS Privacy' requirement that was raised at the last IETF.</div>
<div><br></div><div>Basically when someone binds to an Omnibroker service they get back a list of service hosts which are IP address, port, protocol and credential tuples. To support the DNSE use case, all I need to do is to add in a transport binding for DNS query/response messages. I already separated out the Omnibroker query scheme from the OmniConnect scheme.</div>
<div><br></div><div><br></div><div>My particular key exchange may not be the best way to do it. In fact I deliberately stripped down the protocol to the minimum so as to minimize possibilities for objection. It is easier to add bits in than take them out. But if we divide up the DNS privacy problem in my particular way we can then reuse the same mechanism for the messaging layer problems.</div>
<div><br></div><div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>