Additional Master Secret Inputs for TLS
RFC 6358

Note: This ballot was opened for revision 03 and is now closed.

(Jari Arkko) (was Discuss) Yes

(Tim Polk) Yes

(Sean Turner) Yes

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Lars Eggert) No Objection

(Adrian Farrel) No Objection

(Russ Housley) No Objection

Comment (2010-07-01 for -)
No email
send info
  The Gen-ART Review by Dorothy Gellert on 30-June-2010 call for two
  changes.  I think they should both be addressed, but neither is
  worth blocking publication as an Experimental RFC.
  > Section 2, paragraph 2 duplicates the last paragraph in the
  > Introduction.
  > Is it possible to provide an example of an extension with master
  > secret?  Can you explain why the extension order is important?
  > Is this a security issue, if extension order is not maintained?

Alexey Melnikov No Objection

Comment (2010-06-19 for -)
No email
send info
I hope there are already cases of extensions that would like to define additional master secret inputs.

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

Comment (2010-06-28 for -)
No email
send info
Nothing in the document indicates that this extension will improve the security profile of TLS/DTLS, only that it is meeting the requirements of some unnamed implementers who "want to mix particular data into the calculation of the master_secret". Some text about this might help to motivate the specification.

(Robert Sparks) (was Discuss) No Objection

Comment (2010-07-08 for -)
No email
send info
The Intended Status line in the draft still says Standards Track. Suggest at least adding an RFC Editor note to help avoid confusion later in the process.