Peter Gutmann has been having some trouble with his email and asked me to manually forward this to the list. If you reply, don't credit me with the text, it is his.
>From pgut001 Thu Mar 25 17:29:06 2010 To: fra...@pwpconsult.com, pe...@piermont.com Subject: Re: "Against Rekeying" Cc: cryptography@metzdowd.com Bill Frantz <fra...@pwpconsult.com> writes: >Eric didn't mention it in his blog post, but he has been deeply involved in >cleaning up the mess left by a protocol error in in SSLv3 and subsequent TLS >versions. This error was in the portion of the protocols which supported >rekeying and created a vulnerability that affected all users of those >protocols, whether they used the rekeying part or not. I missed that in his blog post as well. An equally big one is the SSHv2 rekeying fiasco, where for a long time an attempt to rekey across two different implementations typically meant "drop the connection", and it still does for the dozens(?) of SSH implementations outside the mainstream of OpenSSH, Putty, ssh.com and a few others, because the procedure is so complex and ambiguous that only a few implementations get it right (at one point the ssh.com and OpenSSH implementations would detect each other and turn off rekeying because of this, for example). Unfortunately in SSH you're not even allowed to ignore rekey requests like you can in TLS, so you're damned if you do and damned if you don't [0]. A more general concern though is that the large amount of extra complexity caused by the rekeying (you're juggling a renegotiate of a new set of security parameters while simultaneously applying the current set of security parameters) provides a very large amount of attack surface - and in SSH's case failure modes - that just isn't justified by the hypothetical threats that rekeying is meant to address. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
