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

["Kemp, David P." <[e-mail]>]

That is simply a terminology issue.  Whether you call TLSv1.1 (without
renegotiation protection) and TLSv1.1p (with protection) different
protocols or the same protocol with different features, the point
is that the UI must have a separate checkbox for the version/feature.
The fact that there will be a new RFC and that it assigns a new minor
version number influenced my terminology, but it is fine to regard
the "p" as a feature instead.

If only "p" versions are checked or if the "p" feature is checked
(depending on which way the UI is designed), then an RFC-WXYZ-compliant
endpoint MUST either abort any connection with partners that do
not support protection or it MUST disable its own support for
renegotiation.

This is no different than ciphersuites - if your policy is to
require AES encryption, then you would demand that the partner
also support AES or you would refuse to connect.  If your policy is
that single DES is good enough, then you will check both the DES
and AES boxes and communication with DES-only installed-base
partners is possible.

Dave

(To head off other red herrings, the UI checkbox is just
an example - obviously policy may be expressed using header files,
config files, registry settings, or otherwise.)



-----Original Message-----
From: Martin Rex [mailto:[e-mail]] 

> 
> 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