Re: [TLS] Minutes from Tuesday

[[e-mail] (Martin Rex)]

Bodo Moeller wrote:
> Martin Rex <[e-mail]>:
> 
>> Rather than aborthing the TLS handshake, the server ought to include
>> a TLS extension in the ServerHello indicating that he recognized a
>> potentially inappropriate fallback and otherwise continue the TLS handshake
>> in the regular fashion, leaving the decision of whether&how to continue
>> entirely up to those clients who do perform insecure fallbacks.
> 
>
> I just don't think that the additional benefit (per connection)
> is worth the additional computational effort (per connection), and the
> extra latency: for many clients, there is *no* additional benefit at all.

There is a *HUGE* benefit for clients.  They will be able to properly
recognize accidental fallbacks that should not have happened in the
first place.  Otherwise it takes bug reports and several years before
client connection management failures get fixed.


> 
> I'm also concerned about the mechanism being more error-prone if servers
> don't respond with a fatal alert.  If it's a warning alert (or other
> signal) instead

NO Alert at all.  Regular continuation of the handshake.

>
> clients will require additional code to handle this properly,
> whereas reacting to a fatal alert is something that all TLS
> implementations already know how to do.

That reaction is called interop failure.  That is the far opposite
of what IETF working groups are supposed to consciously cause to happen
when the alternative would be to make interop succeed.

As I keep saying, the server decides based on the server's policy
whether it is OK to proceed with the handshake and pick his favorite
properties from the parameters proposed by the Client, and then it is
up to the client to determine, based on the client's own policy,
whether the client is OK to continue.

The TLS protocol offers a negotiation of protocol parameters, and it
actually cryptographically protects this negotiation.  It is silly for
a client to propose parameters that it actually does not want to
have negotiated.  


> 
> We could create a client-side signal that allows the client to specify the
> desired AlertLevel, but this again would add further complexity to the
> protocol (by making server behavior more complex).

The Server ought to continue the regular TLS handshake SUCCESSFULLY.
But it could include a ServerHelloExtension in response that tells
the client "if you really think you could do better, and your app
on top contains the megabyte of flawed "downgrade dance" app coding
that makes Poodle so successful, then you may want to reconsider
your ClientHello offer."

Even when falling back all the way to SSL VERSION 2.0 CLIENT-HELLO,
should be safe and spec-compliant for the client to offer
at least { 0x03, 0x01 } aka TLSv1.0 and the mandatory-to-implement
TLSv1.2 cipher suite TLS_RSA_WITH_AES_128_CBC_SHA

   https://tools.ietf.org/html/rfc5246#section-9

and I really do not understand why all those downgrade dancers
didn't fix their code at least when they renego-patched, because
back then we discussed rather extensively how bad it would be if
an attacker would be able to remove a capability from ClientHello
that both client and server support, and the client even believes
to be a necessity.


-Martin