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

[Paul Hoffman <[e-mail]>]

At 2:03 PM -0600 2/2/10, Brian Smith wrote:
> (a) Why does the intro say that extensions want to mix "particular data"
>into the calculation of the master secret? I think "additional random data"
>would be clearer.

That phrase appears in the introduction to draft-hoffman-tls-master-secret-input, *not* in draft-hoffman-tls-additional-random-ext. The former is the description of how to make extensions that mix particular data into the master secret; the latter is the definition of one such extension.

>(b) Why does there need to be more than one kind of additional input type?
>It seems like the sending side could just concatenate all the additional
>input into a single "additional_input" extension before it sends it. I think
>it's because this foundational work for channel binding mechanism. In that
>case, the IETF should treat the this mechanism and the channel binding
>mechanism as a single item to be accepted/rejected together--if channel
>binding gets rejected then there's no need (AFAICT) for multiple
>additional_input extensions.

There needs to be more than one additional input type because different parties might want to use different extensions. For example, if someone comes up with an extension for mixing in user identities (I'm using this as an example, not a suggestion), they might not want to mix in additional random. Thus, the extensions should remain separate.

And, to be clear, this is not "foundational work for channel binding mechanism". It is orthogonal to the work that has been proposed in that area. Note that the term "channel binding" does not appear in the drafts. 

>(c) Besides channel binding, an implementation might support this to help
>ensure a certain level of entropy was used for the pseudorandom inputs to
>the PRF for calculating the master secret. Why not include the definition of
>this extension in the same document, instead of requiring a separate
>document to define it?

Pasi Eronen, the AD, preferred the two proposals be split into two separate documents.

>(d) Wouldn't it be better to use the normal master_secret calculations to
>establish a secure channel, and then send the parameters for modifying the
>master secret over that secure connection? This would reduce the amount of
>data sent in the clear, so that an outside observer could not tell if/which
>channels are bound together. And it would reduce DoS on the entropy source
>of the PRNGs of each party, by allowing each party to authenticate the other
>before processing the extension. Finally, it would keep ClientHello messages
>small, which is important for improving latency.

Again, this presumes that the purpose is channel binding, and it is not.

--Paul Hoffman, Director
--VPN Consortium