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

[David-Sarah Hopwood <[e-mail]>]

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. With that
requirement, I'm still weakly opposed to your argument here. Always
sending the extension in a renegotiating ClientHello is much simpler.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com