<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 25, 2014 at 11:01 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">Hi all on the crypto group,<br>
<br>
<br>
<br>
over on TCPcrypt [0] it is being debated whether Algorithms should be<br>
Agile [1] for a future extension of TCP that includes opportunistic<br>
encryption.<br>
<br>
It has been claimed that the consensus is that algorithms MUST be agile.<br>
 And, ditto for TCPcrypt, being a lightweight MITMable protocol.<br>
<br>
My question in 2 parts, purely to measure *consensus in this group* as<br>
opposed to the IETF group:<br>
<br>
<br>
     1.  Do you believe that in general case for the security for the<br>
net, (a) security protocols MUST be agile w.r.t cryptography ciphers ?<br>
OR, in the negative, no, protocols may set one cipher and stick with it.<br></blockquote><div><br></div><div>Neither, </div><div><br></div><div>Exactly one preferred algorithm and one backup algorithm per crypto function and this should be consistent across all protocols.</div>
<div><br></div><div>A problem with mix and match crypto is that people mess up with assumptions such as stream ciphers being secure against known plaintext attacks and such. 'Never send a stream cipher to do a block cipher's job' as Jon Callas said to me once.</div>
<div><br></div><div>Then there are the attacks against the negotiation mechanism.</div><div><br></div><div><br></div><div>This is a draft I was asked to write on this but nobody seemed interested after...</div><div><br></div>
<div><a href="http://tools.ietf.org/html/draft-hallambaker-consensuscrypto-00">http://tools.ietf.org/html/draft-hallambaker-consensuscrypto-00</a><br></div><div><br></div><div>The idea here is that there would be two algorithms, a primary and a backup that are MUST and SHOULD compliance requirements. Specifications must still be agile to allow the use of any algorithm but the mechanism need not be efficient or pretty. So I would have no qualms about requiring algorithms to be specified by ASN.1 OID injected into the slot for ciphertext as a prefix and junk all the per protocol algorithm registries.</div>
<div><br></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">
     2.  Do you believe in the specific case of an opportunistic,<br>
dynamic, transparent upgrade inside TCP to an (e.g.,) anonymous DH<br>
protected secret key protocol, that, the ciphers must be agile?  OR, in<br>
the negative, no, that particular protocol can insist on only one and be<br>
done with it.<br></blockquote><div><br></div><div>I am not sure what the question is here.</div><div><br></div><div>I certainly don't believe in frameworks for negotiating key exchange mechanisms. Just have one algorithm and do the job right. </div>
<div><br></div><div>When we designed IPSEC, PGP and S/MIME RSA was expensive. Even at 1024 bits it was a notable machine drag. Today I was testing a key manager for Prism-Proof-Email which generates 4 2048 bit keys when it initializes a user's personal PKI hierarchy and found it was only a minor inconvenience testing the registry setting routines.</div>
<div><br></div><div>In 1995 the choice to do an ephemeral key exchange made sense. Today, just do it, it will take longer to find out if you need it than to just do it.</div><div><br></div><div><br></div></div></div></div>