[I'm not getting copies of my posts to ietf@xxxxxxxxx This is very obnoxious. I wonder if the ietf.org global mailman address change for me didn't cover ietf@xxxxxxxxx] On Thu, Apr 22, 2010 at 09:37:33PM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > 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. > > 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). It's a channel binding facility, yes. > 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". I'm not sure it can do better. > 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. 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 -- _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf