<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 30, 2014 at 9:41 AM, John Kelsey <span dir="ltr"><<a href="mailto:crypto.jmk@gmail.com" target="_blank">crypto.jmk@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">> On Jun 27, 2014, at 9:32 AM, Peter Fairbrother <<a href="mailto:zenadsl6186@zen.co.uk">zenadsl6186@zen.co.uk</a>> wrote:<br>
...<br>
<div class="">> I was almost convinced, for a moment. Two or maybe three suites, only SHALLs allowed, so there is no question of whether a suite is installed or fit for purpose - sounds good.<br>
><br>
> But who decides when to stop using an algorithm suite? The luser client? The boss server?<br>
><br>
> It's certainly not the cryptologist.<br>
<br>
</div>I'm working on the assumption that the knowledge that a given ciphersuite has problems will, in fact, get around and eventually lead to people being willing to turn off one of the ciphersuites,</blockquote><div>
</div><div><br></div><div>This is an ancient problem.</div><div><br></div><div>Shared libraries was one solution that does not work for embedded hardware or languages</div><div>like Google's GO. Deprecation of bad ideas including bad code is a human issue involving communication.</div>
<div>Correct tool in the correct context... same tool in a different context is all wrong.</div><div><br></div><div>It is not just crypto the same issue is at the heart of some of the anti-vaccer problems</div><div>where an authority declared that he had scientific proof that autism and vaccines were linked.</div>
<div>We now know that he invented the data out of thin air and all the research built on</div><div>it and all the laws built on it are wrong. Some might be correct for the wrong reason.</div><div><br></div><div>For cryptographic topics there is a chain of issues that need to be considered</div>
<div>for the code.</div><div><br></div><div>1) simple bug... once fixed at both ends all is good.</div><div>1a) an alternate path is needed while the fix is deployed.</div><div>2) key generation bugs... fix the bug, generate new keys and invalidate the old.</div>
<div>3) total blunder -- it does not work and must be abandoned.</div><div>4) compromised in unknown ways...</div><div><br></div><div>Other issues need to be considered in the context of deployment.</div><div><br></div><div>
A) can it be audited in use?</div><div>B) can it be subverted?</div><div>C) can it be used in ways invisible to audit?</div><div>D) does it bypass normal inspection?</div><div>E) does use invite scrutiny?</div><div>F) can policy be enforced or enhanced at a firewall?</div>
<div><br></div><div>I recall the ssh bug where secure shell was</div><div>so broken by a bug now fixed that telnet with passwords</div><div>in the clear was more secure. Once the server</div><div>side bug was fixed system admins could reboot after</div>
<div>enabling ssh again and close down telnet with a window</div><div>to transfer new keys as needed.</div><div><br></div><div>As the above ssh bug decades ago showed some agility is needed.</div><div>Agility can be administrative or automated.</div>
<div><br></div><div>As the arrest of Eldo Kim at Harvard demonstrated as one </div><div>of six that used TOR simply using a tool invited scrutiny.</div><div><br></div><div>Agility is only one issue. Consider HTTPS with multiple</div>
<div>keys and multiple algorithmic methods under the hood.</div><div>If the likes of Google, Amazon, <a href="http://bsd.edu">bsd.edu</a> discover a problem</div><div>they can turn one off and leave the other in play. If agility</div>
<div>is involved the issue is invisible.</div><div><br></div><div>Invisible adaption is both good and bad. At some point it must trigger </div><div>resolution and communication but not zero day exploits. </div><div>Adaptive code can trigger randomly or trigger on command. </div>
<div>It is not just code, key selection and use needs to be adaptive</div><div>as central key repositories can be hacked. A central repository</div><div>is a single point of failure. Is agility good or bad here. Does </div>
<div>agility open or close exploit doors.</div><div><br></div><div>In my mind.... "use invite scrutiny" is a critical path topic.</div><div><br></div><div><br></div></div>-- <br><div dir="ltr"> T o m M i t c h e l l</div>
</div></div>