Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv

[[e-mail] (Martin Rex)]

Watson Ladd wrote:
> Martin Rex <[e-mail]> wrote:
>>
>> The _only_ reasonable server response of a TLS server that supports TLSv1.2
>> to a ClientHello that contains an SCSV which indicates that the client
>> (a) supports TLSv1.2 and (b) would prefer to use TLSv1.2
>> is a ServerHello with server_version=TLSv1.2.
> 
> Some servers are version intolerant to TLS 1.0. For this reason, and
> not because of middleboxes, version fallback cannot be stopped.

Servers intolerant to TLSv1.0 have become close to non-existant.

Servers intolerant to TLSv1.1 and TLSv1.2, on the other hand,
are too many to ignore.

The fiscal authority of portugal newly commissioned in July 2013 a mandatory
(for Portugal businesses) web service that requires TLS client certs
(issued by the authority) and which will drop the connection when
receiving a TLS ClientHello with TLSv1.1 or TLSv1.2 in it.
Handshake succeeds with TLSv1.0 or SSLv3.


> 
> Some clients only offer SSL 3.0. Until these clients are gone, some
> servers will want to serve them.

No problem.

> 
> Right now these servers have a dilemma: they cannot serve the SSL 3.0
> population without permitting clients offering TLS 1.0 or higher to
> get forced back down to SSL 3.0 by an attacker.  There are real,
> unfixable problems with SSL 3.0, including the lack of an extension
> mechanism.

You can not force down the server, only the client.

SSLv3 has the EXACT SAME extension mechanism as TLS.

  http://tools.ietf.org/html/rfc6101#page-27

It's true that this was retrofitted into the SSLv3 protocol late 1996,
after the initial SSLv3 spec and initial implementations of SSLv3 had
been shipped.  And it's also true that Netscape and the TLS WG failed
badly in making the 18-Nov-1996 SSLv3 spec easily accessible, which
is listed in the references of TLSv1.0 [RFC2246].

  http://tools.ietf.org/html/rfc2246#page-77

Curiously, there are not just old, extensions-intolerant SSLv3 servers,
there are also extensions-intolerant TLSv1.0 servers.


>
> Unfortunately, TLS 1.0, 1.1, and 1.2 rely
> on extensions to indicate which curves are supported. It isn't
> possible to send at ServerHello back after
> seeing a ClientHello with "I tried TLS 1.2, and it didn't work"
> because sending back a ServerHello requires
> information you don't have, like what curves are supported.


You're misled.  It is perfectly possible to send back a TLSv1.2 ServerHello.
If the client doesn't support ECDHE, it will not include any ECC cipher
suites anyway.  The semantics of the presence of TLS cipher suites, but
no accompanying ECC TLS extension is also well-defined in the TLS ECC
spec (rfc4492).


> 
> This proposal solves that problem by letting clients indicate if they
> are dropping down because of fallback or because they cannot offer
> anything better.

This proposal does not solve anything at all.
When Server sends back a ServerHello with server_version=TLSv1.2, then the
client could still decide to abort the handshake if the client so desires.
When the server sends a fatal TLS alert, then interop has completely failed.

Calling a complete interop failure a "solution" is incompatible with
the mission of the IETF.


> 
> Your complaint about signature strength is utterly bogus.

No, it isn't.  That TLSv1.2 breakage would have been easily
avoidable.  And we can still fix it, rather than pretending
that a sha1-with-rsa digital signature would be a reasonable and
secure default choice for a protocol.


>
> Cleartext HTTP doesn't have a little lock in the address bar with a
> green color. Stop pretending that weak crypto is better than no
> crypto:
> as I've pointed out to you, I can train my mother to not put in her
> credit card number without seeing that green lock. I can't train her
> to evaluate connection strength.

When she starts surfing with a HTTP URL, then the little green lock
that onlyappears when she is prompted for her credit card provides
pretty close to zero security.


> 
> Why should the existence of middleboxes permit an active attacker to
> interfere when I visit my bank website from my home computer?
> Why should the fact that some corporate networks want to use TLS
> interception prevent websites from choosing not to permit that sort
> of attack, while still serving the IE6/XP clients? Why should we let
> the lowest common denominator drive the security of all our
> connections, even when better options are supported by both sides?

When better options are supported by both sides, then it is our
task to (a) make these peers interoperate and (b) negotiate&use
at least some of those better protocol features in a fashion that
will not blow up badly in case of spurious internet connectivity failures
or when new TLS software is tested in a few servers of a NATed
server farm.


Fatally aborting the handshake is the far opposite of a successful
negotiation.


-Martin