Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

[Martin Rex <[e-mail]>]

Kemp, David P. wrote:
> 
> Perhaps I misunderstand the issue, but if there is absolutely no
> known security problem in the absence of C->S signaling (ClientHello
> contains neither SCSV nor empty RI), then it would seem that
> C->S signaling is superfluous and should have been omitted from
> the renego spec.  I inferred from its existence that it served
> some useful purpose.

We need the C->S signaling in order to allow the S->C signaling,
because the originial SSL&TLS protocols do not provide sufficient
slack for S->C signaling without prior C->S signaling.

Technically a S->C signaling for the initial handshake would be
sufficient to prevent an updated client from having a client
perform an old renegotiation with an updated server.  Doing
it both ways makes it more robust, and provides additional
room for policy decisions.


> 
> That is not a policy decision embedded in protocol, it is a
> truth in advertising requirement.  If a client's or server's
> policy is that communication is more important than resistance
> to renegotiation attack, than that policy is expressed by accepting
> connections using the SSLv3, TLSv1.0, TLSv1.1, and TLSv1.2
> protocols.

A TLS client or TLS server that does _not_ interoperate with an old
TLS implementation on the initial handshake is simply not compliant
to whatever protocol (SSLv3, TLSv1.0, TLSv1.1 or TLSv1.2) is
negotiated.

The new specification about (secure) TLS renegotiation _only_
deprecates an optional feature of the existing protocol and
adds a new optional feature for them.  This spec does _NOT_
change the core protocol.  Otherwise it would not be an
update, but a new protocol.


-Martin