Subject: Re: [TLS] Downgrade SCSV info

From: Rob Trace <[email-masked]>
Date: Thu, 13 Nov 2014 03:54:12 +0000

> Right, although it couldn't hurt for the client to try TLS 1.1 next in case
> it sees an inappropriate_fallback alert. (Then in the end you have
> essentially the same outcome as if trying the protocols in decreasing order,
> in the presence of an active attacker forcing you to downgrade.)

When we looked at the fallback to HTTP 1.1, it was just as Martin stated and there were almost 0 times when the connection completed over TLS 1.1.  The 1.1 fallback was a lot of wasted roundtrips and did not provide any value.

I am not sure what a wasted fallback to HTTP 1.1 would provide with SCSV, in that the TLS 1.0 fallback would still result in the inappropriate_fallback before we send any data.

Thanks!!

-Rob

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 13 Nov 2014 09:47:24 +0100

> When we looked at the fallback to HTTP 1.1, it was just as Martin stated
> and there were almost 0 times when the connection completed over TLS 1.1.
> The 1.1 fallback was a lot of wasted roundtrips and did not provide any
> value.
>
>
>
> I am not sure what a wasted fallback to HTTP 1.1 would provide with SCSV,
> in that the TLS 1.0 fallback would still result in the
> inappropriate_fallback before we send any data.
>

I do understand the reasoning, although I don't think that this is a good
tradeoff.

- There are servers that are TLS 1.2 intolerant but do tolerate TLS 1.1, so
in that case the fallback to TLS 1.1 does have a chance to complete the
handshake without wasting any round trips (even if the negotiated protocol
may still be TLS 1.0).

- A handshake failure in the initial TLS 1.2 attempt may be due to network
problems rather than incompatibility or an attack. Now assume that the
server does not support TLS_FALLBACK_SCSV. In that case, if you fall back
to TLS 1.1 first (rather than straight to TLS 1.0), you'll end up using the
better protocol (TLS 1.1 instead of TLS 1.0).

I'd rather incur additional latency with servers that are TLS 1.1
intolerant than risk falling back to an unnecessarily bad protocol version.
 (I said that before, about SSL 3.0.  <Cue dramatic music>)

Anyway, if you *do* fall back from a TLS 1.2 Client Hello to a TLS 1.0
Client Hello with TLS_FALLBACK_SCSV, as I said above it might be a good
idea to do the missing TLS 1.1 Client Hello (with TLS_FALLBACK_SCSV) later
in the sequence, if you see an inappropriate_fallback alert with TLS 1.0.
This doesn't address known interoperability issues with particular servers,
but there *could* be servers that are TLS 1.2 intolerant but do support TLS
1.1 (take any decent TLS implementation and add a wacky load balancer in
front of it). This sequence still feels wrong (you really, really should
try TLS 1.1 before TLS 1.0), but it may improve interoperability further.

Bodo