Re: [TLS] Fwd: New Version Notification for draft-bmoeller-tls-downgrade-scsv-00.txt

[[e-mail] (Martin Rex)]

Bodo Moeller wrote:
> >
> > https://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-00#section-3
> >
> >    This section specifies server behavior when receiving the
> >    TLS_DOWNGRADE_SCSV cipher suite from a client in
> >    ClientHello.cipher_suites.
> > [...]
> >
> > To me, this part of your document places two requirements on the _server_
> > to abort the handshake.
> 
> Yes. My point is that there's no server-side guesswork involved -- no
> "flawed or unjustified" assumptions. This is entirely client-directed
> behavior!


To me, these two requirements amount to an unnecessary knee-jerk reaction,
while we are fully aware that most TLS version interop problems are
non-malicious, i.e. _not_ caused by an active attacker.


I really see harm in increasing the amount of TLS handshake failures
with new "abort" requirements of the TLS protocol itself.  Any new/additional
handshake failures ought to be left purely and entirely to the calling
applications and their security trade-offs / policies, which may or
may not involve the decision of an interactive user.  Our concern in
TLS WG ought to be reducing handshake failures, and getting rid of
the reconnect fallback entirely.


TLS version negotiation is royally broken (throughout the installed base),
and has been a well known fact since before TLSv1.1 (rfc4346) was
published in 2006.  And it doesn't look like time is helping to improve
the situation.  Actually, by shipping a defective RSA premaster client_version
check in Windows7/2008R2 the situation has become more challenging
today than it was in 2006.

Maybe you remember that there was a change to OpenSSL in order to
*improve* interoperability (=less failed TLS handshakes) in face
of this defective RSA premaster client_version check:

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

  Relevant OpenSSL ChangeLog:

   Changes between 1.0.0h and 1.0.1  [14 Mar 2012]
  [...]
   *) Some servers which support TLS 1.0 can choke if we initially indicate
      support for TLS 1.2 and later renegotiate using TLS 1.0 in the RSA
      encrypted premaster secret. As a workaround use the maximum pemitted
      client version in client hello, this should keep such servers happy
      and still work with previous versions of OpenSSL.
      [Steve Henson]

Another example for TLS version challenges are defective middle-boxes
(Bluecoat seems popular for internet access from company networks):
https://kb.bluecoat.com/index?page=content&id=KB5493&actp=search&viewlocale=en_US&searchid=1380557656642


Yet another example would be the upgrade path for an installed server-farm,
where you would get yourself into trouble if the existing server-farm
causes clients to perform reconnect-fallbacks and trying to test
a new implementation of the kind you suggest would cause occasional
handshake failures for handshake where the first request went to an
old server, and the reconnect fallback to the updated server.
So for such a setup, this kind of feature would require a "flag day".


There is similar serious breakage in the TLS cipher suite documents that
describe AES in counter mode:
  http://tools.ietf.org/html/rfc5288#section-4
  http://tools.ietf.org/html/rfc6655#section-5

Implementing AEAD for TLSv1.0 or TLSv1.1 would be simple and straight-
forward, and the cipher suites (themselves) would exhibit the same
security properties.  But this breakage prohibits clients from even
proposing these cipher suites when they're doing a fallback, independent
of what is causing the fallback.

Consumers will typically (have to) limit the TLS version that their
client offers upfront to obtain robust behaviour.  And such a
configured limitation will typically be used for years (for as long
as the hardware is used and the software only upgraded).



To really improve the situation, new protocol features (including
TLS protocol versions >1.1) ought to be negotiated in a fashion that
increases the amount of successful TLS handshakes for the entire
installed base, and avoids the necessity for reconnect fallbacks--
something that the majority of programmtic TLS clients do not
even have.


-Martin