<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 30, 2014 at 3:27 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="">On Jun 30, 2014, at 3:01 PM, Phillip Hallam-Baker <<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>> wrote:<br>
<div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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">
So the logical outcome of asking for algorithm agility is ... a single more complex algorithm.<br></blockquote><div><br></div><div>Not really.</div><div><br></div><div>The reason I specify AES as the mandatory to implement algorithm in protocol specifications is that it is the only algorithm currently in use that satisfied all the following criteria:</div>

<div><br></div><div>1) Informed option considers the algorithm to be acceptably secure for all encryption applications.</div><div><br></div><div>2) Is the result of an open selection competition that is generally agreed to have been reasonably transparent and to have made the decision on empirical grounds,</div>

<div><br></div><div>3) Is ubiquitously supported on all platforms including hardware.</div><div><br></div><div>A new more complex algorithm would not meet those criteria. But that is OK because my criteria for a backup algorithm are not the same as my criteria for a default algorithm.</div>
</div></div></div></blockquote></div></div>I'm responding to John Kelsey's point that a fallback is only useful if you're willing and able to throw the primary away.  You're basically saying that you trust the primary, but will kind of accept the fallback if you're forced to.  Not at all the same thing.  And if that's really how you feel ... many will argue that the threat to the primary isn't really so bad, we aren't really so confident in the fallback, no one's seen an actual break yet ... and you're left in the position that many won't move to the fallback, so you're forced to use the primary you no longer trust in order to communicate with them.</div>
</blockquote><div><br></div><div>Of course the primary has to be (almost) completely trusted. But you also want to plan ahead for the next transition. And at a given time you might be at a different stage in the lifecycle of your different algorithms. </div>
<div><br></div><div>The backup is always the candidate for the next primary so it should make use of a different principle to the primary (SHA2 was a bad choice of backup for SHA1)</div><div><br></div><div><br></div><div>
I suggest the following stages:</div><div><br></div><div>Green: You have a primary algorithm and you are 100% happy with it. There is no backup</div><div><br></div><div>Amber: You have a primary algorithm that you are less than 100% happy with, there is no backup<br>
</div><div><br></div><div>Red: You have a primary algorithm that is broken and no backup</div><div><br></div><div><br></div><div>Gold: As for Green except that you also have a deployed backup that is based on a different principle and appreciably stronger (e.g. more rounds).</div>
<div><br></div><div>Silver: As for Amber, except that you have a deployed backup that you are transitioning to and an agreement for the next.</div><div><br></div><div>Bronze: As for silver, except that you don't know where to go after the transition.</div>
<div><br></div><div><br></div><div>The key objective is to avoid ever ending up in the state Red. From a security point of view, a breach is unlikely in any other state. But the difference between Silver and Amber is that if you are in Silver you have a chance of getting back to Green or Gold while if you are in Amber you have a much higher risk of ending up in Red.</div>
<div><br></div><div><br></div><div>Right now the situation as I see it is that we are in the following states:</div><div><br></div><div>Symmetric Encryption: Green (AES, no backup)</div><div>Symmetric Hash: Silver (SHA-1 transitioning to SHA-2 with SHA3 as the new backup)</div>
<div>Asymmetric Signature: Green (RSA is OK right now)</div><div>Asymmetric Key Exchange: Gold (RSA with ECDH the likely successor)</div><div><br></div><div><br></div><div>Agreeing on what the next signature algorithm is, is only hard because there are a few parameter choices that might matter. But we could probably agree on those if we had a summit with the relevant folk to all agree to go the same direction.</div>
<div><br></div><div>I would like to get to the gold state on symmetric encryption and the hash function is moving towards gold naturally.</div></div></div></div>