Re: [TLS] draft-ietf-tls-renegotation: next steps

[Martin Rex <[e-mail]>]

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