At 9:39 AM -0400 8/25/09, Perry E. Metzger wrote: >Ben Laurie <b...@links.org> writes: > > Perry E. Metzger wrote: >>> Yet another reason why you always should make the crypto algorithms you >>> use pluggable in any system -- you *will* have to replace them some day. >> >> In order to roll out a new crypto algorithm, you have to roll out new >> software. So, why is anything needed for "pluggability" beyond versioning? > >For one example, it is not theoretical that some people will often want >to use different algorithms than others and will need negotiation. Some >things like SSH have approximately done this right. Others have done >this quite wrong. > >When we were planning out IPSec, a key management protocol, SKIP, was >proposed that had no opportunity for negotiating algorithms at all -- >they were burned into the metal. As it happens, by now we would have had >to completely scrap it. > >Of course you can go too far in the other direction. IPSec is a total >mess because there are far too many choices -- the standard key >management protocols are so jelly-like as to be incomprehensible and >unconfigurable.
Perry is completely correct on the two previous paragraphs. Hard-coded algorithms, particularly asymmetric encryption/signing and hash algorithms, will lead to later scrapping and a transition for the entire protocol. But it is quite easy to build a protocol with too many knobs, and IPsec is living proof of that. TLS's fixed, registered ciphersuites are far from perfect, but in retropsect, they seem a lot better from an operations / deployment standpoint than IPsec. > > It seems to me protocol designers get all excited about this because > > they want to design the protocol once and be done with it. But software > > authors are generally content to worry about the new algorithm when they > > need to switch to it - and since they're going to have to update their > > software anyway and get everyone to install the new version, why should > > they worry any sooner? > >You speak of "beyond versioning" as though introducing versioning or >algorithm negotiation were a trivial thing, but I don't think you can >generally tack such things on after the fact. You have to think about >them carefully from the start. A different answer to Ben would be "because not planning sooner causes your software users more grief". If you build in both algorithm agility and a few probably-good algorithms, the operational changes needed when one algorithm fails is low. Later software updates that contain other changes can also include new algorithms that are suspected to be good even if all of the original ones fail. --Paul Hoffman, Director --VPN Consortium --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com