Additional Master Secret Inputs for TLS
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 -)
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 -)
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 -)
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 -)
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.