Re: [TLS] New drafts: adding input to the TLS master secret

[Paul Hoffman <[e-mail]>]

At 10:19 AM -0500 2/3/10, Marsh Ray wrote:
>I was thinking of TLS 1.0, since that's what seems to be mostly used.

draft-hoffman-tls-master-secret-input explicitly says it is modifies TLS 1.2.

>This is where my authority to speak goes off a cliff. But that never
>stopped me before. Anyway, it looks to me like HMAC PRF in TLS 1.0
>amounts to little more than the better of the two hash functions, which
>in this case is SHA-1.

Mixing cryptographic apples and oranges may not be helpful for this discussion. Please say whether or not you think that there is a cryptographic flaw in draft-hoffman-tls-master-secret-input that applies to TLS 1.2. If there is, then there is probably an underlying flaw in TLS 1.2 by itself, and that should be discussed seriously. I suspect that there is not.

> >> It also requires clients and servers to buffer the stuff and later
>>> implement a sorting algorithm based on type order.
>>
>> By "later" you mean "still within the same handshake sequence" and by
>> "sorting algorithm" you mean "ascending order of two-byte numbers",
>> yes?
>
>Yes.
>
>>> Lots could go wrong with that. Pathological sort order DoS attacks,
>>> etc.
>>
>> Please explain further. The TLS spec says that you can only have one
>> instance of an extension in a handshake. Thus, all TLS
>> implementations today already should be looking for multiple
>> instances of the same extension. What is left is a relatively small
>> number of extension values, each of which has a unique two-byte
>> number associated with it.
>
>Well, you could check for duplicated extension IDs with a hash table
>data structure that is O(1) in space and time.

The proposal in draft-hoffman-tls-master-secret-input does not change this; the one-use-of-each-extension rule comes from the TLS 1.2 spec, not from the draft.

>Sorting is a little less predictable.
>
>> Where does "pathological sort order DoS
>> attacks" or "etc" come in?
>
>For example, once upon a time Perl used classic quicksort. Quicksort has
>this worst-case of O(n**2). Sending thousands of extensions ordered in
>the worst way can consume a bunch of CPU (the kind which might not be
>offloaded onto crypto accelerator hardware).

If there are thousands of extensions that do master secret input, and you have an implementation that is able to do all those thousands, then I would agree with you. However, I believe that the complexity of adding the code for those thousands of extensions is probably higher than the complexity of your algorithm that sorts two-byte numbers

>I'm not saying this is a significant argument against new features in
>general, only that adding new complexity adds new attack possibilities.

Ah.

>So it needs a bit of justification.

It is justified because the two sides need to know what order to add in the values to the master secret PRF calculation. If the spec had said "in the order that the extensions came in", then you would be complaining that you need to add a new data structure to remember the order that they came in. Sorting on a value that is already in the extension data seemed like a better choice, yes?

--Paul Hoffman, Director
--VPN Consortium