Transport Layer Security (TLS) Renegotiation Indication Extension
RFC 5746

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

(Jari Arkko) Yes

(Pasi Eronen) Yes

(Cullen Jennings) Yes

Alexey Melnikov (was Discuss, Yes, Discuss, No Objection) Yes

Comment (2009-12-17 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Ron Bonica) No Objection

(Ralph Droms) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

(Adrian Farrel) No Objection

Comment (2009-12-15 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Tim Polk) No Objection

Comment (2009-12-15 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Dan Romascanu) No Objection

(Robert Sparks) No Objection

Magnus Westerlund No Objection

(Russ Housley) Abstain

Comment (2009-12-14 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  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.