Re: [TLS] PRF in TLS 1.2

[David Hopwood <david.nospam.hopwood@xxxxxxxxxxxxxxxx>]

Peter Gutmann wrote:
> "Kyle Hamilton" <aerowolf@xxxxxxxxx> writes:
> 
>>My thought is that even if one of the hash algorithms is badly broken,
>>the fact that more than one hash is being used means that a 'hedge'
>>exists against that possibility.
>>
>>MD5 may be able to be broken.  SHA1 may be able to be broken.
>>However, their outputs both rely on the original input

(half the original input, but that's enough.)

>>for their
>>value, such that 1 bit of entropy in the input leads basically to 1
>>bit of entropy in the output.
>>
>>As well, I haven't heard of anyone being able to create a bitstring
>>that will go through both hashes to form an identical bit pattern from
>>both of them.  So, even if MD5 is broken (such that a valid message
>>can be created for message injection/session hijack), the fact that
>>another cipher suite is also in use arguably provides at least as much
>>security as using that cipher suite alone, and hypothetically more.
>>(I cannot attest to theory.)  Especially if the outputs are XORed
>>together -- if SHA1 cannot be predicted but MD5 can, there's still the
>>entire output space of 160 bits to go through.  If SHA1 can be
>>predicted but MD5 cannot, then there's still 128 bits of output space
>>to go through.  (Believing that (SHA1 & MD5) has the same amount of
>>entropy as (sizeof(SHA1) + sizeof(MD5)) is a fallacy; it has the
>>amount of entropy that the largest unpredictable one gives.)
> 
> I agree with everything in the above text.  This is a completely
> unnecessary change, it gratuitously breaks compatibility with the
> existing PRF, it provides no extra security (that anyone knows of), and
> by eliminating the current belt-and-suspenders design, it may even reduce
> the overall security.

I also agree. Note that for the foreseeable future, because implementations
would support versions with both new and old PRFs, the attacker has a choice
which one to try and break. So even if, for the sake of argument, there were
a security problem with the old PRF, changing it still would not increase
security; it can only potentially decrease it.

(Note that if you can break the PRF, you can also break any protection
against version rollback -- not that that protection was particularly robust
to start with.)

> If new research appears showing that (a) there's
> a problem in the current design and (b) a new, demonstrably more secure
> design, then let's switch.  But changing the design simply because we
> haven't changed anything else for awhile and we need to meet some 
> quota for new text in the next draft (or whatever's motivating the
> current change) is not only pointless, it's counterproductive.

Hear, hear.

-- 
David Hopwood <david.nospam.hopwood@xxxxxxxxxxxxxxxx>



_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls