First, we need to fix the Definition of the TLS_RENEGO_PROTECTION_REQUEST: This cipher suite value is the Client to Server signal that the client is updated and asks to apply the strict rules of secure renegotiation applied to the current handshake -- no excuses. If SCSV is received by a server on an initial handshake that does not contain a renegotiation_info TLS extension, then the server should apply the same semantics as if it had received an empty TLS extension RI in that ClientHello. Concerning the question what a client should send on a backwards interoperable renegotiation handshake: The rule is "if you can't be good, at least be good at it.". That means if the clients configuration permits old-style renegotiation, then he should NOT try fancy new tricks with that old server on the renegotiation handshake that he didn't do on the initial handshake. i.e. if the client had sent TLS extensions on the initial handshake, there is no problem with _sending_ TLS extension RI on the renegotiation handshake with the old server. However, if the client did _not_ use TLS extensions (but SCSV) on the initial handshake with an old server, then there are only to sensible options for the client on renegotiation: (a) abort when the client doesn't allow old-style renegotiation (b) send an extension-less ClientHello with MCSV on renegotiation. -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf