<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Apr 19, 2014 at 9:31 AM, Sandy Harris <span dir="ltr"><<a href="mailto:sandyinchina@gmail.com" target="_blank">sandyinchina@gmail.com</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="">One criterion, I think, is that forward secrecy is a MUST.<br>

</div></blockquote><div><br></div><div>Definitely</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=""></div>
I'd also have MUST support AES</blockquote><div><br></div><div>Sure, we have AES-NI, and aside from silly things like Biclique attacks and related key attacks (which should be mitigated by a good key agreement protocol) AES is free of dangerous confidentiality-breaking cryptanalysis. So yes, AES, definitely, and preferably an authenticated mode of AES like AES-GCM.</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">SHOULD support the other AES finalists with open licenses (Twofish, MARS & Serpent).<br>

</blockquote><div><br></div><div>Why bother? Few people use these ciphers and with AES-NI there's no reason to. We should look to more modern authenticated ciphers like the CAESAR finalists and things like ChaCha20/Poly1305.</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="">
> 2) Better key exchange (Tcpcrypt is also tackling this)<br>
<br>
</div>Is it perhaps time for another look at Photuris? That was a simpler<br>
alternative to IPsec, might still have useful ideas to offer. There<br>
are RFCs.<br></blockquote><div><br></div><div>There are also these papers, linked from the OP:</div><div><br></div><div><ul style="margin-top:0px;margin-bottom:10px;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,Arial,sans-serif;font-size:14px;line-height:20px">

<li><a href="http://www.isg.rhul.ac.uk/~kp/ModularProofs.pdf" style="color:rgb(66,139,202);text-decoration:none">Modular Security Proofs for Key Agreement</a></li><li><a href="https://research.microsoft.com/en-us/um/people/klauter/security_of_kea_ake_protocol.pdf" style="color:rgb(66,139,202);text-decoration:none">Security Analysis of KEA Authenticated Key Exchange Protocol</a></li>

<li><a href="https://research.microsoft.com/pubs/81673/strongake-submitted.pdf" style="color:rgb(66,139,202);text-decoration:none">Stronger Security of Authenticated Key Exchange</a></li><li><a href="http://cacr.uwaterloo.ca/techreports/2011/cacr2011-11.pdf" style="color:rgb(66,139,202);text-decoration:none">Anonymity and one-way authentication in key exchange protocols</a></li>

</ul></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="">Can we get rid of certificates instead?</div>

</blockquote><div><br></div><div>For practical reasons I don't think so, but this deserves more discussion.</div></div><div><br></div>-- <br>Tony Arcieri<br>
</div></div>