Re: [TLS] Fwd: New Version Notification for draft-pettersen-tls-version-rollback-removal-00.txt

[[e-mail] (Martin Rex)]

Personally, I consider going through a handshake failure an no-go
for standardization, and would rather like to see a slight (fully
optional and fully backwards-compatible) protocol modification
to support a succcessul TLS handshake with the most desirable
common characteristics, ZERO extra crypto overhead and a further
reduction of failed TLS handshakes on the internet.


Although retrying a TLS handshake with different characteristics after
a TLS handshake failure may be an option for some implementations and
some types of clients (in particular with Browsers), there are
applications and environments, where this option simply does not exist.

One other possibility to avoid waste of crypto cycles and a handshake
failure would be to specify&standardize an SCSV that can be used to
restart the handshake.  Wasn't something like this done for the
Server-Gated Crypto hacks in SSL3?

So a client could start with a "conservative" extension-less
SSLv3 ClientHello and include that SCSV, and a server who supports
a higher version number than offered in ClientHello.client_version
and/or supporting extensions that would acctually affect the
characteristics of the resulting handshake, could return
a ServerHello with that SCSV as the "common cihper suite",
(and maybe a ServerHelloExtension describing features that
can be safely used and may have been avoided by a conservative
client (potentially including things like DHE cipher suites
because of the small subgroup goof of some servers),
an upon receiving a ServerHello with that SCSV, the client
would simply restart the handshake with a full-blown
ClientHello carrying all the features that the client supports
and may want to offer.

For proposed session resumes, the client would then already have
the info about what the server supports in the TLS session cache,
so there would be no overhead for handshakes with proposed TLS
session resumes (even when the server perform occasional full
handshakes, as long as it returns a TLS session id, so that
this feature remains transparent/invisible to client applications.


SNI might become a useful feature in a few years.  Today there
is still a significant number of clients which does not support SNI,
and the interop problem that would result from an SNI prerequisite
is at least a magnitude larger than TLS version intolerance and
TLS extension intolerance problems.

-Martin