TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks
RFC 7507

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

(Richard Barnes) Yes

Comment (2015-02-18 for -04)
No email
send info
This is the second SCSV value going into the registry.  I noted that the value proposed in Section 7 is not adjacent to the other SCSV value (0x00,0xFF TLS_EMPTY_RENEGOTIATION_INFO_SCSV), and in fact lies in the middle of a broad swath of unallocated code points.  

Would it be worthwhile to allocate a range of ciphersuite values to be used for these sorts of things (say 0x00,0xD0-0xFF), or at least make the code point assigned for this document adjacent to the other one so that if there are others, they can be managed in a range-like fashion?

(Spencer Dawkins) Yes

Comment (2015-02-16 for -04)
No email
send info
Thank you for working through Last Call comments on this one. I did have one niggle.

In this text:

6.  Security Considerations

   However, it is strongly recommended to send TLS_FALLBACK_SCSV when
   downgrading to SSL 3.0 as the CBC cipher suites in SSL 3.0 have
   weaknesses that cannot be addressed by implementation workarounds
   like the remaining weaknesses in later (TLS) protocol versions.
I'm wondering whether "recommended" is intended as an RFC 2119 RECOMMENDED, but wondering more why someone wouldn't do this (why is it not required/REQUIRED?).

(Stephen Farrell) Yes

(Brian Haberman) Yes

(Ted Lemon) Yes

(Kathleen Moriarty) Yes

(Jari Arkko) No Objection

Comment (2015-02-19 for -04)
No email
send info
Russ' Gen-ART observation needs to result in document a change. Hopefully that can be implemented as part of the approval process (or a new draft if otherwise required).

(Alia Atlas) No Objection

(Benoît Claise) No Objection

Alissa Cooper No Objection

Comment (2015-02-16 for -04)
No email
send info
Glad folks came to consensus on this even if it was tough.

The header of the document and the intro say that it updates RFCs 2246, 4346, 4347, 5246, and 6347, but the abstract only lists three of those.

The IANA considerations section is a little weird, since the actual allocations are listed in the part that is to be removed and then there is a sentence that claims the allocations are already done. Why not do the usual "This document registers the following values in XYZ registry ..." and keep the registrations themselves in there?

(Adrian Farrel) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2015-02-17 for -04)
No email
send info
The Abstract should mention DTLS also, and the two DTLS RFCs that are updated.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection