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

["Brian Smith" <[e-mail]>]

Paul Hoffman wrote:
> 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.

> 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.

I misunderstood how the extensions work. Thanks for the clarification.
But...

> At 2:03 PM -0600 2/2/10, Brian Smith wrote:
> >(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.

OK, I shouldn't have said "channel binding," but all of the concerns still
stand, AFAICT. If the additional inputs are random data then it may be OK to
send them in the clear. However, other kinds of additional inputs like user
identities would be better off protected. And, it is better not to increase
the size/processing of the hello messages required before each party gets to
see the other's certificate. If these additional inputs appear in hello
messages then the only way to protect them is with the handshake/renegotiate
anti-pattern, which makes connection latency even worse by adding more round
trips.

Any  extensions that contain non-trivial amounts of data and/or possibly
sensitive information should be transmitted after change_cipher_spec
messages--not in hello messages--whenever practical. When a hello extension
does contain non-trivial amounts of information or sensitive information,
then the security considerations section of its specification should explain
why the extension cannot be moved to after the change_cipher_spec messages. 

Anyway, please disregard my mention of channel binding. What I really meant
is that it's hard to understand and evaluate
draft-hoffman-tls-master-secret-input without seeing the definitions of the
other kinds of additional input--in particular, whether or not those kinds
of additional input are better put before or after the first
change_cipher_spec message (consequently, before or after an initial master
secret is calculated).

Regards,
Brian