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

[Paul Hoffman <[e-mail]>]

At 3:30 PM +0100 2/2/10, Simon Josefsson wrote:
>I have read these two documents and believe they are generally fine.  As
>far as I can tell, they are not backwards compatible with earlier
>proposals. 

Correct.

>But that is not important.

I believe that is the case as well. The changes only are needed if both parties agree to use a TLS/DTLS extension that need the changes, and that negotiation is completely explicit. If an implementation doesn't support any such extension, there is no reason for it to support the changes either.

>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.
>...
>   [RANDOM]   Eastlake, D., 3rd, Schiller, J., and S. Crocker,
>              "Randomness Requirements for Security", BCP 106, RFC 4086,
>              June 2005.

This is a great addition, thanks. It will be in the -01.

--Paul Hoffman, Director
--VPN Consortium