TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks
draft-ietf-tls-downgrade-scsv-05
Yes
(Brian Haberman)
(Kathleen Moriarty)
(Stephen Farrell)
(Ted Lemon)
No Objection
(Adrian Farrel)
(Alia Atlas)
(Benoît Claise)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
Note: This ballot was opened for revision 03 and is now closed.
Brian Haberman Former IESG member
Yes
Yes
(for -04)
Unknown
Kathleen Moriarty Former IESG member
Yes
Yes
(for -04)
Unknown
Richard Barnes Former IESG member
Yes
Yes
(2015-02-18 for -04)
Unknown
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 Former IESG member
Yes
Yes
(2015-02-16 for -04)
Unknown
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 Former IESG member
Yes
Yes
(for -03)
Unknown
Ted Lemon Former IESG member
Yes
Yes
(for -04)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -04)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -04)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(2015-02-16 for -04)
Unknown
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?
Barry Leiba Former IESG member
No Objection
No Objection
(2015-02-17 for -04)
Unknown
The Abstract should mention DTLS also, and the two DTLS RFCs that are updated.
Benoît Claise Former IESG member
No Objection
No Objection
(for -04)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2015-02-19 for -04)
Unknown
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).
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -04)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -04)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -04)
Unknown