Subject: [TLS] 1.0 or else (was Re: Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00)

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Jan 2015 21:04:59 -0800

On 28 January 2015 at 15:31, Martin Rex <[email-masked]> wrote:
> That's not quite true.  There es little, if any stuff outside of the
> browser world that could go to > extension-less TLSv1.0, because there
> are still too many servers out there that will abort the handshake
> when extensions are present or when the version is > TLSv1.0.

Our limited survey thus far has identified only a small number (0.27%)
of sites [1][2] that can't handle our TLS 1.2 handshake [3], even
though they will tolerate our TLS 1.0 handshake.  In contrast,
disabling SSL3 affected more than twice this amount.

Note that we don't drop extensions now that SSL3 is disabled, so we
have no information on Martin's claims of extension intolerance.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1084025#c96
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1084025#c99
[3] We use a TLS 1.0 record layer, 1.2 ClientHello and a modest set of
extensions.

---

From: [email-masked] (Martin Rex)
Date: Thu, 29 Jan 2015 19:00:33 +0100 (CET)

Martin Thomson wrote:
> Martin Rex <[email-masked]> wrote:

For our TLS client and our customers, the amount of public Websites
with TLS extension or TLS version intolerance is not very meaningful.

We do _not_ provide a browser.  Our customers are using our TLS client
for programmatic data exchange scenarios.  Historically most was PKCS7,
but newer scenarios often use WebService/SOAP.  However, we know very
little about our customers' usage scenarios, except that we are
not permitted to break it with software updates.

A while ago I mentioned this site:
http://www.elemica.com/

which uses TLS-protected data exchange, authenticated by SSL client certs,
on the following endpoints:
     https://preprod.connect.elemica.com:5443
     https://connect.elemica.com:5443

both of these (TLSv1.0) services are TLS version tolerant,
but will abort the handshake with a fatal unexpected_message alert
when the ClientHello contains *any* TLS extensions.

This server/service became known to me only by coincidence.  For a short
time, the service seems to have been selecting a TLS cipher suite that
our TLS client did not propose.  A customer reported the interop problem
because it affected a production scenario. But when I analyzed the
scenario, I could no longer reproduce that handshake failure with our
client.

Reproducing handshake failures with OpenSSL is trivial, though.
It seems impossible to have the openssl 1.0.1 s_client send an
extension-less TLS ClientHello. (only 0.9.8 s_client with "-no_ticket").

We will not be able to ship any substantial change in client behaviour
as default behaviour, but will have to limit it to "explicit customer opt-in"
-- which means that the vast majority of customers will not use it.

Substantial changes that are well known to cause interop problems are
 - use of TLS extensions in initial ClientHello
 - use of ClientHello.client_version > (3,1) for initial ClientHello
 - use of record layer protocol version other than (3,0) or (3,1)
   for initial ClientHello

adding a small number of TLS cipher suites IDs to ClientHello creates
only a manageable risk (rfc5746 did not cause any interop problems).

This is why I would really appreciate a mechanism bein standardized
similar to the one described in this message:

http://www.ietf.org/mail-archive/web/tls/current/msg11238.html

One additional round-trip is a completely negligent price for
full interop.  Heavily used communication links see a
ratio of session resumes vs full handshakes of 10:1 to 50:1,
so most of the time, the additional round trip on a clean
initial handshake will not matter anyway.  With the information
stored in the existing regular client-side TLS session cache,
the fall-forward strategy can also be avoided.  No additional
heuristics nor additoinal per-server caching of meta-data necessary.

-Martin

---

From: Hubert Kario <[email-masked]>
Date: Fri, 30 Jan 2015 18:15:21 +0100

> with TLS extension or TLS version intolerance is not very meaningful.

the point of those studies is not to test the whole TLS ecosystem - that's 
simply impossible

the point is to have at least /some/ reference point

also, HTTPS is the biggest user of TLS so it's likely that if there is a TLS 
implementation it is used by somebody to encrypt web traffic. HTTPS is also 
basically the only one that gets any kind of scrutiny wrt. used 
configurations.

if you have different statistics, please share them

> only a manageable risk (rfc5746 did not cause any interop problems).

It probably did not, but tests done by Yngve say something different wrt to 
cipher id selected for fallback scsv

-- 
Regards,
Hubert Kario