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

[Martin Rex <[e-mail]>]

David-Sarah Hopwood wrote:
> 
> Martin Rex wrote:
> > 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 [S]CSV on renegotiation.
> 
> (b) is only secure if an upgraded server MUST abort if it receives an
> SCSV without an extension on a renegotiating handshake.
> I am *strongly* opposed to (b) without that requirement.

That is what I tried to describe in the second sentence above of 
the mail that you quoted: "apply the strict rules of secure renegotiation
to the current handshake -- no excuses".  You're welcome to use
more appropriate words to describe this.


> 
> With that requirement, I'm still weakly opposed to your argument here.
> Always sending the extension in a renegotiating ClientHello is much
> simpler.

That is one of the few useful conditionals, because it would be
backwards-incompatible and unreasonable action to send an extension
on a backwards-interop renegotiation scenario with an old(!) server
if _NO_ extension was sent on the initial handshake.

The spec should _not_ require implementers to offer this, and neither
require apps to enable this, but _IF_ they offer it, then it just
doesn't make sense to offer backwards interop renegotiation in an
inconsistent fashion.

-Martin