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

[Stefan Santesson <[e-mail]>]

Paul, 

I have a few questions:

1)  Could/Should the draft say anything more about the benefits?

The draft states the undeniable fact that "This mixing creates a
cryptographic binding of the added material directly into the secret that is
used to protect the TLS session.  For example, some systems want to be sure
that there is sufficient randomness in the TLS master_secret"

But is this solution provided because the PRF, unless amended with
additional entropy, could cause security issues that motivates this change?

2) What is the added value of defining the amended master secret calculation
in absence of any extension that provide data to the calculation.

Once such extension is defined, would it not have to more or less duplicate
the definition provided in this draft? (e.g. see question 3)

3) How do you decide the order of input from multiple extensions?

Which extension will provide ClientHello.additional_ms_input_1 and
ClientHello.additional_ms_input_2. How can you sort this out unless each
extension explicitly define its input order in relation to other similar
extensions or by creating an IANA registry where input's and their order are
registered.


/Stefan


On 10-01-30 12:42 AM, "Paul Hoffman" <[e-mail]> wrote:

> Greetings again. I have submitted two drafts that are probably of interest to
> some people in the TLS WG. I intend to submit them as individual submissions,
> not through the WG, but getting input from the WG before I do so would be
> great.
> 
> The first document changes the TLS/DTLS master secret calculation when there
> are particular kinds of extensions present. Of course, it does not change the
> calculation when those extensions are not present, and there are no extensions
> yet that would kick in the change.
> 
> The second document is an extension that is similar to the one that Ekr
> proposed over a year ago. It allows one or both parties to add more random
> input to the master secret calculation. This is desired by some organizations
> who want to match the guaranteed amount of randomness in the master secret
> calculation with the strength of the encryption and authentication functions.
> 
> Both documents are (purposely) short and hopefully easy to read. If you have
> any comments, send them to me or, if you think they pertain to the WG, maybe
> send them here. Again, these are not meant to be WG work items; I doubt that
> the effort to recharter and so on would be worth the value.
> 
> --Paul Hoffman
> 
> Title  : Additional Master Secret Inputs for TLS
> Author(s) : P. Hoffman
> Filename : draft-hoffman-tls-master-secret-input-00.txt
> Pages  : 4
> Date  : 2010-1-29
> 
>    This document describes a mechanism for using additional master
>    secret inputs with Transport Layer Security (TLS) and Datagram TLS
>    (DTLS).
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hoffman-tls-master-secret-input-00.t
> xt
> 
> Title  : Additional Random Extension to TLS
> Author(s) : P. Hoffman
> Filename : draft-hoffman-tls-additional-random-ext-00.txt
> Pages  : 3
> Date  : 2010-1-29
> 
>    This document specifies a TLS/DTLS extension that uses the additional
>    master secret inputs to achieve useful security properties.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hoffman-tls-additional-random-ext-00
> .txt
> 
> 
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls