Transport Layer Security (TLS) Renegotiation Indication Extension
RFC 5746
Yes
No Objection
Abstain
Note: This ballot was opened for revision 03 and is now closed.
Lars Eggert No Objection
(Alexey Melnikov; former steering group member) (was Discuss, Yes, Discuss, No Objection) Yes
Updated as per revision -02: Sorry about flipping back and forth between YES and DISCUSS. But I think the following text is a bit confusing. (I am happy to clear if I misunderstood something): 4. Renegotiation Protection Request Signalling Cipher Suite Value In order to enhance compatibility with such servers, this document defines a second signalling mechanism via a special signalling cipher suite value (SCSV) "TLS_RENEGO_PROTECTION_REQUEST", with code point 0xNN, 0xMM. This SCSV is not a true cipher suite and cannot be negotiated. It merely has exactly the same semantics as an empty "renegotiation_info" extension. and then later on in the same section: Note that a minimal client which does not support renegotiation at all can simply use the SCSV in all initial handshakes. Any compliant server MUST generate a fatal "handshake_failure" alert and terminate the connection when it sees any (apparent) attempt at renegotiation by such a client. Clients which do support renegotiation MUST implement Section 3 as well. Does this mean that any use of SCSV means that the client doesn't support renegotiation? And does this mean that the use of the new TLS extension and the use of SCSV are not the same thing? 3. Extension Definition This requirement to validate any received RI extension still applies even after previous The acronym RI should be explained on first use. handshakes on the same the connection or session did not negotiate the use of RI. Every handshake must be treated independently in this respect because the attacker may attempt to make an initial handshake appear as a renegotiation handshake or vice-versa. 7. Security Considerations [...] By default, TLS implementations conforming to this document MUST verify that once the peer has been identified and authenticated within the TLS handshake, the identity does not change on subsequent renegotiations. For certificate based cipher suites, this means bitwise equality of the end-entity certificate. If the other end attempts to authenticate with a different identity, the renegotiation MUST fail. If the server_name extension is used, it MUST NOT change when doing renegotiation. I found the "by default" part to be confusing until I read the following paragraph. May I suggest that for clarify you make them a single paragraph? A TLS library MAY provide a means for the application to allow identity and/or server_name changes across renegotiations, in which case the application is responsible for tracking the identity associated with data it is processing. This may require additional API facilities in the TLS library.
(Cullen Jennings; former steering group member) Yes
(Jari Arkko; former steering group member) Yes
(Pasi Eronen; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
I have some sympathy with Russ's Comment, and my initial reaction having read the problem statement was to ask whether we actually need the renegotiation feature.
(Dan Romascanu; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Tim Polk; former steering group member) No Objection
I am satisfied that this solution is workable and resolves the problem at hand. I understand that other solutions exist and have been discussed within the working group, but I am less concerned about the details of the solution than getting a solution completed in a timely fashion. Let's approve this one now.
(Russ Housley; former steering group member) Abstain
As a protocol climbs the IETF standards-track maturity ladder, we sometimes drop features. I would rather see renegotiation dropped from TLS than see this complexity added to TLS protocol.