Concerning the SCSV behavior I prefer publishing the specification as-is. regards, Nikos On Tue, Jan 26, 2010 at 9:49 AM, <Pasi.Eronen@xxxxxxxxx> wrote: > Concerns have been raised that the IESG may have judged community > consensus about one specific detail of draft-ietf-tls-renegotiation > prematurely. In particular, the discussion that happened just after > the IETF Last Call ended might have caused some people to change their > opinion, and also the holiday season may have delayed replies. To > eliminate doubt about the situation, and allow the RFC to come out as > soon as possible, we have decided to confirm the community consensus > about this detail. > > The detail in question is whether the "Signalling Cipher Suite Value" > (SCSV) can be included when performing secure renegotiation (in > addition to the renegotiation_info extension). > > Currently, the SCSV is not included. In the version that went to IETF > Last Call (version -01), the relevant text was: > > "This cipher suite has exactly the same semantics as an empty > "renegotiation_info" extension. [..] Because this cipher suite is > equivalent to an empty "renegotiation_info" extension, only > "renegotiation_info" may be used rehandshakes." (in Section 4) > > Version -03 (the latest version) has rephrased the text as follows: > > "The SCSV MUST NOT be included." (in Section 3.5, "Client Behavior: > Secure Renegotiation") > > "When ClientHello is received, the server MUST verify that it does > not contain the TLS_RENEGO_PROTECTION_REQUEST SCSV. If the SCSV is > present, the server MUST abort the handshake." (in Section 3.7, > "Server Behavior: Secure Renegotiation") > > It has been suggested that recent discussions may have changed the > consensus, and some people have proposed changing this so that > including the SCSV in secure renegotiation ClientHellos is allowed > (but not required), and rephrasing the text that says SCSV, when > received, is treated the same as an empty renegotiation_info extension > (which means "not renegotiation"). > > Note that this text applies to secure renegotiation ClientHellos. > Other possible changes to the details concerning the SCSV (such as > requiring it in all ClientHellos) were suggested during the IETF Last > Call, but are explicitly outside the scope of this email. > > According to our notes, at least the following individuals seem to > have expressed support for publishing version 01/02/03 (without making > further changes to the details concerning the SCSV): > > Adrian Farrel > Alexey Melnikov > Ben Laurie > Bodo Moeller > Chris Newman > Cullen Jennings > Dan Romascanu > David P. Kemp > Eric Rescorla > Geoffrey Keating > Glen Zorn > Jari Arkko > Lars Eggert > Lisa Dusseault > Magnus Westerlund > Nicolas Williams > Pasi Eronen > Peter Robinson > Ralph Droms > Rob P. Williams > Robert Relya > Robert Sparks > Ron Bonica > Stephen Farrell > Steve Checkoaway > Steve Dispensa > Tim Polk > Uri Blumenthal > > The following individuals seems to have expressed a preference for > *not* publishing this document until the details concerning the SCSV > are changed as described above: > > Marsh Ray > Martin Rex > Michael D'Errico > Nasko Oskov > Robert Dugal > Stephen Henson > Yoav Nir > > A number of other people also sent comments during the IETF Last Call > (possibly proposing other changes to the details concerning the SCSV), > but did not clearly fall into either list above. > > If the recent discussions have caused you to change your mind (or we > have interpreted your preference incorrectly, or you were not on > either list), please send an email to the TLS WG mailing list by > Tuesday February 2nd. In your reply, please include one of the > following: > > (1) I prefer publishing the specification as-is. > > (2) I prefer *NOT* publishing the specification as-is, and instead > prefer changing the text so that including the SCSV in secure > renegotiation ClientHellos is allowed (but not required). > > Unless a significant amount of additional people believe that making > this change if preferable over publishing the spec now, the IESG > expects to have the RFC out soon after February 2nd. So we hope this > consensus confirmation does not delay the RFC, or deployment of its > implementations. > > Note that this is not a general call to revisit other details of > draft-ietf-tls-renegotiation, or propose additional changes. If you > absolutely wish to have other discussions related to the draft, we > respectfully ask you to change the subject line. > > Best regards, > Pasi > IETF Security Area Director _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf