MD5 considered harmful today, SHA-1 considered harmful tomorrow

Peter Gutmann pgut001 at cs.auckland.ac.nz
Fri Jan 23 20:55:15 EST 2009


Eric Rescorla <ekr at networkresonance.com> writes:
>At Tue, 20 Jan 2009 17:57:09 +1300, Peter Gutmann wrote:
>> "Steven M. Bellovin" <smb at cs.columbia.edu> writes:
>>
>> >So -- who supports TLS 1.2?
>>
>> Not a lot, I think.  The problem with 1.2 is that it introduces a pile of
>> totally gratuitous incompatible changes to the protocol that require quite a
>> bit of effort to implement (TLS 1.1 -> 1.2 is at least as big a step, if not a
>> bigger step, than the change from SSL to TLS), complicate an implementation,
>> are difficult to test because of the general lack of implementations
>> supporting it, and provide no visible benefit.  Why would anyone rush to
>> implement this when what we've got now works[0] just fine?
>
>Ordinarily I wouldn't bother to respond to Peter's curmudgeon act,

:-).

>but since I was obviously heavily involved with TLS 1.2, I think a bit of
>context is in order.

I'm aware of why the changes were made, but the point of my comment was to
explain their consequences in the lack of support for TLS 1.2.  I had (AFAIK)
one of the first implementations of TLS 1.1, an incremental upgrade of TLS 1.0
(and then had some fun trying to find things to interop against) but for TLS
1.2 I haven't implemented it and have no plans to implement it because it
provides absolutely no benefit over TLS 1.1 and a great many downsides.

>Yes, the changes between TLS 1.1 and TLS 1.2 are about as big as those
>between SSL and TLS. I'm not particularly happy about that either, but it's
>what we felt was necessary to do a principled job.

It may have been a nicely principled job but what actual problem is the switch
in hash algorithms actually solving?  Making changes of such magnitude to a
very, very widely-deployed protocol is always a tradeoff between the necessity
of the change and the pain of doing so.  In TLS 1.2 the pain is proportionate
to the scale of the existing deployed base (i.e. very large) and the necessity
of doing so appears to be zero.  I don't know of any attack or threat to the
existing dual-hash mechanism that TLS 1.2 addresses, and it may even make
things worse by switching from the redundant dual-hash (a testament to the
original SSL designers) to a single algorithm.  This is why I called the
changes "gratuitous", there is no threat that they address - it can even be
argued (no doubt endlessly) that they make the PRF weaker rather than stronger
- but they come at considerable cost.

SSL/TLS is (and has been for many years) part of the Internet infrastructure.
You don't make significant, totally incompatible changes to the infrastructure
without very carefully weighing the advantages and disadvantages.  Maybe
there'll be a sudden flood of unexpected TLS 1.2 implementations right after I
post this, but at the moment it seems that implementors have weighed up the
cost and said "no thanks".

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list