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

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

Paul Hoffman wrote:
> At 3:30 PM +0100 2/2/10, Simon Josefsson wrote:
> >There is one thing in draft-hoffman-tls-additional-random-ext-00.txt
> >that bothers me: There is no requirement that additional random data
> >is generated using cryptographic principles.  This means the extension
> >can be used as a general-purpose extension mechanism to exchange data
> >that has meaning to, for example, some middle-ware that sits between
> >the client and server.
> >
> >Is this the intention?  I'm assuming no, and that the
> >additional_random_value actually are intended to be, well, just an
> >additional random value.
> 
> Correct. That's why the document says:
>    The recipient of an additional_random extension MUST NOT try to
>    parse the additional_random_value.
> 
> >Therefor, I would suggest that a new requirement is added:
> >
> >   The client and server MUST generate the additional_random_value
> >   data using a secure random number generator.  [RANDOM] provides
> >   guidance on the generation of random values.
> 
> This is a great addition, thanks. It will be in the -01.

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

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

(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?

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

Regards,
Brian