Re: [TLS] interop for TLS clients proposing TLSv1.1

[Martin Rex <[e-mail]>]

Florian Weimer wrote:
> 
> * Martin Rex:
> 
> > I really think we (the TLS WG) should provide a remedy to this awful
> > situation for the TLS protocol version negotiation in the installed
> > base.
> 
> Most vendors offer automated updates these days.  Deployments which are
> not updated are likely to have other issues besides interoperability
> problems.  Protocol fixes still do not end up in deployment.

The installed base of TLS is around 2 Billien endpoints (no kidding),
so any "updates" and new features should seriously take into account
how the installed base (in particular the part that is not going
to be updated) reacts to them.  Allergic reaction (=interop problems)
need to be avoided as much as possible.

It seems that no TLS client that propose TLSv1.1 or higher today
would want to do so without a reconnect fallback facility in place.
The problem of the reconnect fallback is, that it precludes a protected
negotiation of the TLS version.

There seems to be only one extensibility left in TLS that is sufficiently
robust to be usable in _all_ scenarios (and that allows for a real
negotiation inside TLS rather than an application level fallback after
a TLS handshake failure).


> 
> I think we should try to figure out the reason before we try to work
> around it.

TLS version negotiation (and the checking of the TLS version in the
RSA premaster secret) is sufficiently broken across the installed base
that we really don't need to know anything else.

A "nanny" spec that provide very detailed guidance about how an
alternative TLS version negotiation works, plus all the known issues
about the known defects in existing TLS version negotiation and how
thing MUST be done in future implementations, should be just fine
to address the problem ... and to bridge the 10-15 years that it
takes before all of the problematic TLS implementations, that
currently exist in the installed base, have died off sufficiently
so that the original TLS version negotiation (which is _not_ going
to be deprecated, just extended) can be expected to work as
originally intended.


>
> If we're unlucky, the workarounds are broken in a similar way,

It is not the original TLS version negotiation that is really broken,
but it seems to have been underexplained in a fashion that there was
apparent confusion among implementors about which protocol version
to use on the record layer for a ClientHello and which protocol
version to use (and to check) in the RSA permaster secret.

To address the problems apparent in the original installed base,
I believe that using a much clearer specification with the scope
limited to TLS version negotiation, plus real interop testing of
that extensibility feature should be sufficient.

Traditional SSL&TLS interop was done only in a limited fashion
and only about features that were implemented.  If anyone had
interop-tested the extensibility before shipping, they would
have realized their bugs.  It's a real pity that Microsoft did _not_
interop test their RSA premaster version check on renegotiation
handshakes before they shipped the TLS renegotiation fix for
win7/2008R2 (I haven't checked their older SChannels for this
characteristic).


>
> and we gain very little because vendors and deployments which use
> arguably more secure protocol versions are still punished by an
> incompatible installation base.

We can not do anything about the lack of features in the installed
base, other than _not_ let that stop us from using better features
with newer peers.  Currently, the installed base is a _real_ problem
for TLS clients to perform a protected TLS version negotiation,
and realizing that, the TLS WG should provide an alternative.


-Martin