Subject: Re: Last Call: draft-hoffman-tls-master-secret-input (Additional Master Secret Inputs for TLS) to Proposed Standard

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 Apr 2010 11:10:47 -0500

On Wed, Apr 21, 2010 at 10:27:03AM -0700, The IESG wrote:
> The IESG has received a request from an individual submitter to consider 
> the following document:
> 
> - 'Additional Master Secret Inputs for TLS '
>    <draft-hoffman-tls-master-secret-input-01.txt> as a Proposed Standard

I support publication of draft-hoffman-tls-master-secret-input-01.txt as
a Proposed Standard.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 Apr 2010 11:10:47 -0500

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Apr 2010 21:37:33 +0200 (MEST)

> I support publication of draft-hoffman-tls-master-secret-input-01.txt as

I'm fine with the "technology" in tls-master-secret-input.

It is a kind of inverse to TLS extractor/exporters and GSS_prf,
i.e. for cryptographically binding the TLS session to some other
information (secret or public) and provides a more rigid binding
than the gssapi channel_bindings facility (one that can not be ignored).

I have some nits with the text in section 1 and 2 because of the
lax terminology around randomness combined with the reference to
"(TLS) extensions with master secret input".

The document should carefully distinguish between data that
is merely unique and non-predictable, but public and fully known
to every observer and data that is "secret randomness" aka entropy.

There is no entropy in unique, non-predictable, _published_ data.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 Apr 2010 15:04:23 -0500

[I'm not getting copies of my posts to [email-masked].  This is very
obnoxious.  I wonder if the ietf.org global mailman address change for
me didn't cover [email-masked].]

> than the gssapi channel_bindings facility (one that can not be ignored).

It's a channel binding facility, yes.

> "(TLS) extensions with master secret input".

I'm not sure it can do better.

> to every observer and data that is "secret randomness" aka entropy.

Why?  That is a distinction for the extensions that make use of this one
to make.  I suppose that this document could provide some guidance to
people desiging extensions that make use of this one.

> There is no entropy in unique, non-predictable, _published_ data.

Right.  But I don't see this extension as being one intended for adding
entropy to the master secret.

Nico
--