On Tue, Oct 8, 2013 at 1:46 PM, Bill Frantz <fra...@pwpconsult.com> wrote: > > On 10/8/13 at 7:38 AM, leich...@lrw.com (Jerry Leichter) wrote: > >> On Oct 8, 2013, at 1:11 AM, Bill Frantz <fra...@pwpconsult.com> wrote: > > >>> We seriously need to consider what the design lifespan of our crypto suites >>> is in real life. That data should be communicated to hardware and software >>> designers so they know what kind of update schedule needs to be supported. >>> Users of the resulting systems need to know that the crypto standards have >>> a limited life so they can include update in their installation planning. > > >> This would make a great April Fool's RFC, to go along with the classic "evil >> bit". :-( > > > I think the situation is much more serious than this comment makes it appear. > As professionals, we have an obligation to share our knowledge of the limits > of our technology with the people who are depending on it. We know that all > crypto standards which are 15 years old or older are obsolete, not > recommended for current use, or outright dangerous. We don't know of any way > to avoid this problem in the future.
15 years ago is 1997. Diffie-Hellman is much, much older and still works. Kerberos is of similar vintage. Feige-Fiat-Shamir is from 1988, Schnorr signature 1989. > > I think the burden of proof is on the people who suggest that we only have to > do it right the next time and things will be perfect. These proofs should > address: > > New applications of old attacks. > The fact that new attacks continue to be discovered. > The existence of powerful actors subverting standards. > The lack of a "did right" example to point to. As one of the "Do it right the first time" people I'm going to argue that the experience with TLS shows that extensibility doesn't work. TLS was designed to support multiple ciphersuites. Unfortunately this opened the door to downgrade attacks, and transitioning to protocol versions that wouldn't do this was nontrivial. The ciphersuites included all shared certain misfeatures, leading to the current situation. TLS is difficult to model: the use of key confirmation makes standard security notions not applicable. The fact that every cipher suite is indicated separately, rather than using generic composition makes configuration painful. In addition bugs in widely deployed TLS accelerators mean that the claimed upgradability doesn't actually exist. Implementations can work without supporting very necessary features. Had the designers of TLS used a three-pass Diffie-Hellman protocol with encrypt-then-mac, rather than the morass they came up with, we wouldn't be in this situation today. TLS was not exploring new ground: it was well hoed turf intellectually, and they still screwed it up. Any standard is only an approximation to what is actually implemented. Features that aren't used are likely to be skipped or implemented incorrectly. Protocols involving crypto need to be so damn simple that if it connects correctly, the chance of a bug is vanishingly small. If we make a simple protocol, with automated analysis of its security, the only danger is a primitive failing, in which case we are in trouble anyway. > > >> There are embedded systems that are impractical to update and have expected >> lifetimes measured in decades... >> >> Many perfectly good PC's will stay on XP forever because even if there was >> the will and staff to upgrade, recent versions of Windows won't run on their >> hardware. >> ... >> >> I'm afraid the reality is that we have to design for a world in which some >> devices will be running very old versions of code, speaking only very old >> versions of protocols, pretty much forever. In such a world, newer devices >> either need to shield their older brethren from the sad realities or >> relegate them to low-risk activities by refusing to engage in high-risk >> transactions with them. It's by no means clear how one would do this, but >> there really aren't any other realistic alternatives. -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ The cryptography mailing list email@example.com http://www.metzdowd.com/mailman/listinfo/cryptography