Subject: [TLS] SCSV versioning

From: 🔓Dan Wing <[email-masked]>
Date: Thu, 26 Feb 2015 12:34:44 -0800

I recently became aware that Microsoft IE won't implement SCSV.  Near as I can tell, this is the main concern, but it is not terribly detailed about the concern:

https://connect.microsoft.com/IE/feedback/details/1002874/internet-explorer-should-send-tls-fallback-scsv

> One of the developers pointed out that the TLS_FALLBACK_SCSV feature has a significant downside-- because it doesn't convey any specific version information, it becomes a general "never fall back" signal. The problem is that such signals are too broad; fallbacks were only ever introduced because servers often use TLS stacks with implementation bugs. Any "don't fallback" signal sent by such a server will be very bad for compat.
> 
> Now, the counterargument is that servers should just implement TLS properly and update when new versions are released and/or bugs are found, but there's strong precedent showing that this just doesn't happen. IE's decade long "DocumentMode/CompatibilityView" fiasco comes from the fact that there was a single "StandardsMode" flag that the majority of pages had opted-into without actually being standards compliant.

Has this concern been discussed in the working group?  Should we resolve this?  (I think a resolution might be along the lines of "I have previously tried 1.2 and 1.1", but really depends on one's interpretation of the 'significant downside' concern that an IE developer has.)

Yes, I know SCSV has finished WG review and IESG review.

-d

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 26 Feb 2015 16:06:29 -0500

Dan Wing <[email-masked]>:

I recently became aware that Microsoft IE won't implement SCSV.  Near as I
> can tell, this is the main concern [...]:
>

> One of the developers pointed out that the TLS_FALLBACK_SCSV feature has
> a significant downside-- because it doesn't convey any specific version
> information, it becomes a general "never fall back" signal. The problem is
> that such signals are too broad; fallbacks were only ever introduced
> because servers often use TLS stacks with implementation bugs. Any "don't
> fallback" signal sent by such a server will be very bad for compat.
>

I haven't seen this particular complaint before, and also can't quite make
sense of it. TLS_FALLBACK_SCSV is a signal sent by the client, not by the
server as that statement implies (and of course, IE acts as a client). The
specification (draft-ietf-tls-downgrade-scsv-05) says that clients SHOULD
send TLS_FALLBACK_SCSV in fallback handshakes, and that servers MUST react
to it in a specific way. This expressly gives clients some latitude,
allowing trade-offs that may be needed for the sake of compatibility.
(Also, if a client never does a fallback handshake, there's no reason to
send TLS_FALLBACK_SCSV in the first place.)

A related (in a Chinese-whispers way, anyway) complaint that I *have* seen
is the one I've addressed in
http://www.ietf.org/mail-archive/web/tls/current/msg14848.html.  (See also
https://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/shepherdwriteup/
.)

Bodo

---

From: Geoffrey Keating <[email-masked]>
Date: 26 Feb 2015 16:26:01 -0800

Bodo Moeller <[email-masked]> writes:

> sense of it.
...

I believe it's the same thing I mentioned last year, in

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

The implicit assumption made by the SCSV is that all new servers
(supporting the SCSV) will not have bugs requiring a fallback.  As
soon as that first server appears which supports SCSV but requires
fallback, this SCSV can't be used.

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 26 Feb 2015 20:32:36 -0500

> fallback, this SCSV can't be used.

This would affect fallback handshakes from *future* protocol versions to
TLS 1.2, as we've seen that it's not a problem in practice when falling
back from TLS 1.2 to earlier versions. So it could mean that clients that
want to maintain interoperability with servers that can't handle their TLS
1.3 handshake attempts might not want to send TLS_FALLBACK_SCSV in fallback
handshake Client Hello messages announcing TLS 1.2. (The document's
Security Considerations cover this, by the way.) I don't see how it could
be a reason to not use the SCSV when falling back to a version below TLS
1.2.

Bodo

---

From: Geoffrey Keating <[email-masked]>
Date: 26 Feb 2015 17:52:28 -0800

> be a reason to not use the SCSV when falling back to a version below TLS

It affects any client which is talking to a server which is buggy and
where the bugs can be avoided by a fallback.  For example, a server
with an issue in its TLS 1.2 implementation (perhaps in an extension),
which could be solved by retry and fallback with TLS 1.1 or without
the extension, would instead be prevented from working by the SCSV.

As far as I know, there are no currently known examples of such
servers, but it doesn't seem unreasonable that such a thing might
appear in the future.

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 26 Feb 2015 21:25:04 -0500

> the extension, would instead be prevented from working by the SCSV.

Certainly.  However, now that a fair number of clients do support
TLS_FALLBACK_SCSV and use it in fallback retries (or may not fall back at
all), you should generally notice this kind of problem early as you try to
deploy the new server: this server just would be obviously broken and so
most likely won't make it far in its deployement.  So I think this is
extremely unlikely to become a concern in practice.

If you really were to try and do everything to interoperate with any kind
of theoretical server brokenness in your client, though, you'd end up with
lots and lots of retries -- you couldn't even rely on cipher suite
negotiation because the server might be getting individual cipher suites
wrong, for example.

The current reality of downgraded retries obviously isn't quite as
complicated, but is more complicated than just protocol versions.
TLS_FALLBACK_SCSV can take care of just one dimension, the protocol
version, because it's meant to be very simple (yet meaningful for security)
and because it would not make sense to perpetuate a snapshot of current
implementation brokenness in a protocol change.

Bodo