Subject: Re: [TLS] Minutes from Tuesday

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Sat, 01 Nov 2014 18:13:18 +0100

On 31/10/2014 02:26, Martin Rex wrote:
> Bodo Moeller wrote:
>> 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.
>
It seems to me the current draft allows that too, so I don't see how your
proposal provides additional value compare to the draft on this exact point.
(I agree it does provide value compared to current situation, obviously).

>> 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.
> 
I'm not so sure. There are already a lot of situations where implementations are
requires to make the handshake fail, eg if the verify data from the Finished
message don't match, which indicates the handshake data has been tampered with.
This is not entirely different, the main difference is that the suspected
tampering happened during the previous handshake.

I'm not saying breaking the handshake is the only right thing to do, I can see
the benefits of the solution you suggest, but I think the simplicity of the
current draft is a big advantage in getting it widely (and correctly) deployed
sooner rather than later, which IMO outweighs the advantages of a more complex
approach.

Manuel.

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 5 Nov 2014 09:30:22 +0100

Manuel Pégourié-Gonnard <[email-masked]>:

> Martin Rex wrote:

> >> [...] reacting to a fatal alert is something that all TLS

> sooner rather than later, which IMO outweighs the advantages of a more

Right. If we figure out how to make more handshakes succeed immediately
without a fallback dance, that's completely orthogonal to TLS_FALLBACK_SCSV
(which won't be needed in such handshakes).

Any such proposal will be considerably more complex than the
TLS_FALLBACK_SCSV mechanism, and I think there's no excuse for allowing
downgrade attacks to happen until it is deployed.

Bodo

---

From: [email-masked] (Martin Rex)
Date: Thu, 6 Nov 2014 11:01:44 +0100 (CET)

Bodo Moeller wrote:
>> current draft is a big advantage in getting it widely (and correctly)
>> deployed sooner rather than later, which IMO outweighs the advantages
>> of a more complex approach.

It's actually hard to think of a more unreasonable behaviour than
the one currently specified.

A different, equally simple and magnitudes more useful server behaviour
would be for the server to continue the handshake as normal and simply
assume in the processing of the ClientHello that the Client means
ClientHello.client_version +1 compared to what it sent over the wire.

(but when doing that, the server ought to skip the RSA premaster secret
 client_version check later on when selecting a cipher suite with
 static RSA key exchange.  Since Microsoft botched the RSA premaster
 secret version on renegotiation handshakes in Win7, and there is no
 security value in the check anyway, this should be perfectly OK.)

-Martin

---

From: Brian Smith <[email-masked]>
Date: Tue, 11 Nov 2014 18:04:11 -0800

> the one currently specified.

No it isn't. For example, the server could do all of these, which are
more unreasonable:
1. Reboot the server.
2. Start thermonuclear war.
3. Send a reply on this thread to this mailing list.

There are many other more unreasonable things the server could do.

> ClientHello.client_version +1 compared to what it sent over the wire.

No, because the client might have done multiple levels of fallback,
but the server might not have seen all of the levels. So, for example,
the server might be seeing ClientHello.client_version = SSL 3.0 with
the fallback SCSV, but the client actually supports TLS 1.2. It
wouldn't be good for the server to carry on with TLS 1.0 (because of
the CBC IV problems in TLS 1.0, amongst other reasons).

>  security value in the check anyway, this should be perfectly OK.)

I disagree. If there is a compatibility issue regarding renegotiations
only, then the compatibility workaround should be limited to
renegotiations only. Since most clients don't even want to renegotiate
unless the server demands it, limiting the workaround to
renegotiations means that most connections will never be affected by
it.

Cheers,
Brian