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

From: Paul Hoffman <[email-masked]>
Date: Fri, 29 Jan 2010 15:42:26 -0800

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

	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

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 30 Jan 2010 01:35:31 +0100

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" <[email-masked]> 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
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 29 Jan 2010 17:10:18 -0800

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

Not really; I put what I knew into the doc.

>additional entropy, could cause security issues that motivates this change?

The first sentence (mixing) is, as you say, undeniable. Different people want different items cryptographically mixed into the secret. For instance, some people really want the parties' identities mixed in. (Note that I'm not proposing to do that, just saying that some folks want it.)

The second sentence (random) is the motivation for the extension. A PRF which turns out to be weaker than expected might have that weakness shored up by stuffing more random in the master_secret. To date, no PRF weaknesses have ever been made worse by adding random inputs.

>the definition provided in this draft? (e.g. see question 3)

There is no value to amending the calculation unless there is at least one extension that will use it. However, do not assume that the only possible valuable extension is for adding randomness; there are others that other folks might want in the future.

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

That's covered in draft-hoffman-tls-master-secret-input:

   For the calculation of the master secret, the
   extensions MUST be sorted by extension type order.  Note that RFC
   5246 specifies that there can only be one extension per type, and the
   extensions can appear in mixed order.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dean Anderson <[email-masked]>
Date: Sat, 30 Jan 2010 17:13:41 -0500 (EST)

On Fri, 29 Jan 2010, Paul Hoffman wrote:

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

Unless I misunderstand what you plan to change, te master secret
calculation is a core subject of TLS and thus the TLS Working Group
activity.

I am concerned that this is an out-of-WG framework change that
effectively alters WG standards on the master secret calculation and
impacts subsequent extensions; and that as it is outside of the WG
standards process.  Independent submissions are not allowed on WG
subject matter. It would seem to me that the RFC editor ought to reject
this independent submission because it is related to WG activity, and
amounts to an end-run around WG decision-making on master secret
calculation and how TLS extensions affect core facilities. Merely
bringing such work to the attention of the WG before independent
submission seems to be insufficient to comply with the requirement that
Working Groups decide on standards in their chartered area.

Changing the master secret calculation in a nonstandard way is a
proprietary change.  The WG gives approval by accepting the document,
reviewing it, and deciding on it. Saying "Hey WG, look at this" isn't
sufficient.  Putting an "RFC"  imprimatur on your change via independent
submission doesn't alter the fact of WG non-standardization, but merely
confuses both implementers and the public, and constrains WG decisions
in the future. But of course, that's why the RFC editor is supposed to
reject independent submissions that overlap WG work.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 256 5494

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 30 Jan 2010 17:34:08 -0800

>calculation is a core subject of TLS and thus the TLS Working Group

You do not misunderstand what I plan to change. What I am far from clear on is whether this WG can add such a work item without rechartering, given that the charter disagrees with your view that this is inherently a WG activity. If the WG can adopt the work without rechartering, that would be fine with me. If, however, it takes a bunch of silly work, there is no need to do that: individual submission would give folks just as much review opportunity and will give the AD just as much input from the community.

>standards process. 

As you can see from the draft itself, it only affects "subsequent extensions" if those extensions want to be affected. That is, they have to explicitly declare themselves as affected; otherwise, they aren't.

>Independent submissions are not allowed on WG

All quite true. That's why I said I intended them to be by "individual submission", not "independent submission".

>proprietary change. 

True, but completely irrelevant. As one can see from the drafts themselves, they are meant to be on standards track.

>The WG gives approval by accepting the document,

Again, true but irrelevant. Independent submissions are fully vetted in the IETF, and the AD would certainly want to be sure that there was "enough" technical discussion in the TLS WG before even considering the documents for IETF Last Call.

--Paul Hoffman, Director
--VPN Consortium