Subject: [TLS] An SCSV to stop TLS fallback.

From: Adam Langley <[email-masked]>
Date: Mon, 25 Nov 2013 18:27:58 -0500

Sad as it is, in order to work on public Internet all browsers
implement TLS fallback: in the event of a handshake failure they will
retry the connection with a lesser SSL/TLS version.

This means that an active attacker can disable AES-GCM support and,
ultimately, ECDHE if they push the browser back to SSLv3. It would be
good to finally do something about this.

As I've mentioned before, with Chrome 31, we removed support for
falling back to SSLv3 for Google sites. With Chrome 32, we were
planning on removing all fallback for Google sites.

Chrome 31 has been released and saw a fair amount of breakage due to
an anti-virus that (in some configurations) acts as a local MITM and
had bugs. Previously it was depending on browsers falling back to
SSLv3 in order to function at all.

I've since contacted a few other anti-virus and MITM vendors and asked
them about the Chrome 32 change. A couple have informed me that they
will break, at least in some configurations, if Chrome removes all
fallback because they cannot do version negotiation correctly.

I had expected the problems to come in the form of DPI devices sniping
TLS 1.2 connections with injected RSTs rather than MITMs. These
experiments in Chrome 31 and 32 were designed to probe how large a
problem they were. The plan was always to gather information and then
figure out a general solution that avoids having a special case for
Google sites in Chrome.

Since the MITMs are turning out to be the problem, I think the plan
needs rethinking as the general solution need not break MITMs and thus
could be deployed more easily.

Thus I'd like to propose the design of an SCSV with which we can move forward:

  In the event that a client is making a fallback connection, it
includes TLS_FALLBACK_SCSV (0x5600) in the list of cipher suites. A
current server which sees this cipher suite in a ClientHello SHOULD
return a fatal alert, inappropriate_fallback (86) and abort the
connection.

This will not break MITMs because they will not process the SCSV. Any
vendors that try to support the SCSV while having bugs that need
fallback will find out when things stop working. But that, thankfully,
will be their problem based on the Universal Rule of Users: the last
thing that updated is to blame.

Of course, this doesn't mean that firewalls won't turn out to be a
problem but, at the moment, we can't even figure that out because of
the the broken MITMs. We can't protect MITMed users, but it would be
nice if they didn't ruin it for everyone else.

Cheers

AGL

---

From: Watson Ladd <[email-masked]>
Date: Mon, 25 Nov 2013 15:49:32 -0800

> return a fatal alert, inappropriate_fallback (86) and abort the
I enthusiastically support this extension: it will solve a bug as old
as SSL without breaking
anything it seems. Why the hell wasn't this done sooner?
> nice if they didn't ruin it for everyone else.
If firewalls block port 53, it's not the browser's problem. If
firewalls block 80, it's not the browser's problem. Why should
TLS 1.2 be any different?
>
>
> Cheers
>
> AGL
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Adam Langley <[email-masked]>
Date: Mon, 25 Nov 2013 18:52:35 -0500

> TLS 1.2 be any different?

Because firewalls that block (by RST injecting) TLS 1.2/1.1/etc
connections currently work and this change would stop them working.
Therefore it would be Chrome's fault. (This is exactly as stupid as it
sounds, yet it is the world I live in.)

Cheers

AGL

---

From: Andy Wilson <[email-masked]>
Date: Tue, 26 Nov 2013 13:52:33 +1300

I take it you're aware of
http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-00

-- 
Regards

Andy

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Tue, 26 Nov 2013 01:59:09 +0100

Adam, a few questions:

  - Are these implementations functioning as proxies or just inspecting the  
encrypted protocol data, without decrypting?

  - Does *any* of these implementations support the Renego patch? If they  
don't, then my suggestion for using the Renego extension support as a  
proxy for version tolerance might still work.

  - Do you know that none of them will not break due to an SCSV? If they  
are breaking due to expectations of what is supposed to be in the  
handshake, some of them they could very well break due to unexpected  
ciphersuites, as well. (while the Renego SCSV seem to have worked well, I  
don't think it can be relied on as a reliable indication as it is only  
used for SSL v3-only hellos, because there are servers that does not  
tolerate the Renego extension in combination with the Renego SCSV)

A pessimistic guess is that, as per Murhpy's Law, there will be both  
broken Renego patched implementations, and implementations that react to  
the proposed SCSV. As far as the SCSVs are concerned, how do you propose  
to handle those cases?

The questions then becomes: How many cases? And, are they are "too many"?  
(If the answer to the last one is "yes, always, one broken connection is  
one too many", then let's just park this entire discussion since it will  
never amount to anything. If there is no will to actually confront the bad  
implementations, the problem will never be fixed.)

Further thoughts:

Personally, I think a line needs to be drawn in the sand (or preferably  
concrete) and version rollback should be blocked in as many cases as  
possible, and as quickly as possibly (and needless to say, I think my  
proposal [1] will work better for both of those goals than SCSVs), and let  
the server, intermediary, and client side MITM vendors fix their products  
if they break other products, like browsers and other SSL/TLS clients.

The clients could include a message directly drawing the attention to (or  
better, putting the blame on) possible incompatible software in the system  
(particularly if other information can be used to make the case that it  
works from other network locations; diagnostic testing might also help).  
As long as incompatible implementations are allowed free reign, and IMO  
that is currently the case, then they will continue to be deployed and  
won't be retired. Only placing the user's security above user experience  
will help change the situation, because when placing the experience before  
security one only gets insecurity and vulnerabilities.

In my TLS Prober sample, 81.95% of servers are now Renego patched, of  
these 0.28% (~1200) are version and/or extension intolerant (mostly  
extension intolerant)

Since the TLS 1.3/2.0/4.0 discussion have raised its head again I'll also  
mention that 1.01% of renego patched servers are intolerant for Client  
hello version signaling v3.4,  and 8.34% are intolerant for Client Hello  
version signaling v4.1 (assumes a 3.1 record version).

The question needs to be asked: Will version rollback be acceptable in the  
next generation TLS client? Particularly considering the potential  
severity of the problems it is supposed to fix?

IMO the answer should be "No", and that means that the process of weeding  
out servers and intermediates that require clients to implement version  
rollback needs to be started now, and it also means that the next  
generation TLS will need to address the problem head on, and not back  
down. If that is not done, then we will be having this discussion again in  
(or for) another 15-20, maybe 30 years.

[1]  
http://datatracker.ietf.org/doc/draft-pettersen-tls-version-rollback-removal/

-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/

---

From: [email-masked] (Martin Rex)
Date: Tue, 26 Nov 2013 03:19:23 +0100 (CET)

> return a fatal alert, inappropriate_fallback (86) and abort the

We keep this proposals for newly creating interop problems keep
coming up on this list?

How about instead fixing the negotiation so that AES-GCM&AES-CCM
can be sent in whatever ClientHello there is (including SSLv2)
and an additional SCSV to signal availability of a specific subset of
ECDHE that can be used without a TLS ECC extension, such as the subset
that is supported by Windows 7+?

If there is a problem in negotiating what _we_want_to_do_, because the
installed base does not like the kind of negotiation that was originally
proposed to be used, then the pragmatic engineering approach will be
to define an alternative negotiation of at least a useful subset
that will be compatible with the installed base, and which will not need
to be stripped from a "conservative fallback handshake" -- and therefore
will be resilient to downgrade attacks, and cope with retarded middle boxes.

-Martin

---

From: Trevor Perrin <[email-masked]>
Date: Mon, 25 Nov 2013 18:33:07 -0800

[...]
> fallback because they cannot do version negotiation correctly.

Hi Adam,

Are these MITM products using special root certs installed in the
browser for MITM purposes?  If so, could the browser simply allow
SSLv3 fallback only when connecting to a cert under such an installed
root, while otherwise rejecting such a fallback?

Trevor

---

From: Adam Langley <[email-masked]>
Date: Tue, 26 Nov 2013 12:23:08 -0500

> http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-00

Yes thanks. My one sentence design is obviously very similar. I don't
understand some of the extra logic for the server in Bodo's draft.

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Tue, 26 Nov 2013 12:32:47 -0500

> encrypted protocol data, without decrypting?

I think that the problems so far have been with full MITM proxies.

> don't, then my suggestion for using the Renego extension support as a proxy
> for version tolerance might still work.

Unfortunately I've no idea. There seem to be more variants of some of
these products than pips in a pomegranate.

>  - Do you know that none of them will not break due to an SCSV? If they are
> breaking due to expectations of what is supposed to be in the handshake,
> some of them they could very well break due to unexpected ciphersuites, as
> well. (while the Renego SCSV seem to have worked well, I don't think it can
> be relied on as a reliable indication as it is only used for SSL v3-only
> hellos, because there are servers that does not tolerate the Renego
> extension in combination with the Renego SCSV.

It is possible that there could be compat issues with an SCSV but, as
far as I know, it's the least likely to have problems.

> A pessimistic guess is that, as per Murhpy's Law, there will be both broken
> Renego patched implementations, and implementations that react to the
> proposed SCSV. As far as the SCSVs are concerned, how do you propose to
> handle those cases?

Tiny amounts of breakage are acceptable if there are some edge cases.
I don't know yet whether the breakage will be tiny and, as ever, it'll
be a bunch of work to find out. But it seems to be the best way
forward.

You report that 0.3% of sites are expected to fail if we use renego as
an anti-fallback signal. That is not a heart warming number and I'd
like to try to break less, if at all possible.

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Tue, 26 Nov 2013 12:34:32 -0500

> will be resilient to downgrade attacks, and cope with retarded middle boxes.

Backporting AES-GCM, ECDHE, etc all the way back to SSLv3 is a
possibility if it comes to it. However, it's a lot more work than the
anti-fallback mechanisms currently under consideration so I'd want to
exclude them first.

I know know of a reason to believe that they would have less
compatibility problems than an SCSV.

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Tue, 26 Nov 2013 12:38:47 -0500

On Mon, Nov 25, 2013 at 9:33 PM, Trevor Perrin <[email-masked]> wrote:
> browser for MITM purposes?

Yes.

> If so, could the browser simply allow

Yes, but I don't believe that would be viable on the Internet as a
whole. There are certainly many HTTPS servers on the Internet that
need fallback in order to function. We would like not to break them
while stopping them dragging everyone's security down. So we still
need some way to identify non-broken servers. At the moment we're
doing that with an "if (is_google)", but that's just an experiment. We
would need an SCSV or the existing renego signal to deploy this
properly in any case, although a root check would fix the current
experiment.

Cheers

AGL

---

From: [email-masked] (Martin Rex)
Date: Tue, 26 Nov 2013 21:12:58 +0100 (CET)

Adam Langley wrote:
[ Charset UTF-8 unsupported, converting... ]
> possibility if it comes to it.

Strictly speaking, there is no need to backport anything, if this
was implemented as an alternative fashion to negotiate the use
of TLSv1.2 protocol PDUs&semantics.

ECDHE is already allowed with TLSv1.0 and TLSv1.1, so the only thing that
is missing is permitting AES-GCM (i.e. the GenericAEADCipher PDU)
with TLSv1.0&TLSv1.1 -- which is an extremely trivial and straightforward
change -- half of the work is removing lines of the kind
  "if ( tls_version<TLS_VERSION_12 ) { goto abort_handshake; }"
in the code that implements the TLS record layer.

>
> However, it's a lot more work than the

No, it should be negligible.  For a reasonably structured implementation
of TLSv1.2, it should be less changes than rfc5746 (renego)

> compatibility problems than an SCSV.

You're trying to mitigate the risks of reconnect fallbacks in clients,
and perpetuate the reconnect fallbacks, where as the correct fix is to
obviate the reconnect fallbacks.  Making AES-GCM and ECDHE more
backwards-interop friendly will also allow clients that do not
implement reconnect fallbacks, to use these features (=a reasonable
subset of them).

-Martin

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 26 Nov 2013 12:21:10 -0800

On Tue, Nov 26, 2013 at 9:38 AM, Adam Langley <[email-masked]> wrote:
> need some way to identify non-broken servers.

Sure, makes sense.

There was an earlier thread about TLS-intolerant middleboxes and the
problem they pose for TLS enhancements which require TLS Extensions
(like CT, TACK, and OCSP "must-staple") [1].

Are your observations actually good news for that case?  If many of
those intolerant middleboxes that were being observed are actually
*MITM* boxes with installed MITM roots, presumably browsers could
detect when they are connecting to such a MITM middlebox, and relax
their requirements around (CT, TACK, OCSP "must-staple", etc.)?

Trevor

[1]
http://www.ietf.org/mail-archive/web/tls/current/msg09450.html
http://www.ietf.org/mail-archive/web/tls/current/msg09468.html

---

From: Watson Ladd <[email-masked]>
Date: Tue, 26 Nov 2013 17:13:40 -0800

> We keep this proposals for newly creating interop problems keep
Why didn't you complain before we had the problems?
How does AGL's proposal introduce interop issues?
I agree this is important to avoid in the future, but I don't think
this proposal
causes any more problems.
> that is supported by Windows 7+?
SSLv2.0 is irredeemably broken.
SSLv3.0 doesn't use HMAC, so the decision was made to go to TLS 1.0, rather than
negotiate an extension. It also only supports SHA1 and MD5. The
allowable key exchanges
also changed. Implementing this in a backwards-compatible manner would be hard.
Why the SSL structure was kept around is beyond me: surely someone in
1999 should have
understood the cryptographic issues inherent in the design. (Actually
someone did, namely Rogaway, and everyone ignored him).
But yes, to the extent we can make future changes backwards compatible
we should.

---

From: Brian Smith <[email-masked]>
Date: Tue, 26 Nov 2013 17:42:57 -0800

> return a fatal alert, inappropriate_fallback (86) and abort the

Adam, I think what you propose makes sense. However, I think it might
not be ideal if there are any circumstances where the browser could
accidentally fall back to a lower version--e.g. falling back after a
timeout or falling back in response to the connection being reset.
AFAICT, we currently have to do fallback from TLS 1.2 -> TLS 1.1 and
from TLS 1.1 -> TLS 1.0 in response to connection resets. There will
be some false positives here. In addition to potentially reducing the
security of the connection, these fallback connections add a lot of
latency. If we attempt a fallback connection in response to a
connection reset, and we receive an inappropriate_fallback alert, then
we'd have to make yet *another* connection without the fallback. All
other things being equal, it would be better if the server could
respond respond exactly as it would with a TLS 1.2 ClientHello,
without downgrading the cipher suite or any other feature, more like
what Martin Rex suggested.

However, I don't think it is realistic to backport features all the
way to SSL 3.0. The information in the TLS extensions is too
important, and trying to define good defaults for missing extensions
that make sense long-term seems like it will just bind our hands too
much in the future.

So, we should could consider backporting TLS 1.2 cipher suites to TLS
1.1 and TLS 1.0, but then using your suggested inappropriate_fallback
for for SSL 3.0 handshakes only.

Whether this complication is justified depends on how frequently we
receive false-positive connection resets (and anything else that can
be a false positive) and how much we care about optimizing performance
for that case.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 27 Nov 2013 12:40:03 +0100

> understand some of the extra logic for the server in Bodo's draft.

I think your new proposal corresponds to my original sketch for the SCSV's
semantics ("If you can read this, tear down the connection"), before I
actually wrote that Internet-Draft.

Writing the I-D, I realized that it would be a pity if, in case a need came
up to implement similar fallback strategies when deploying future protocol
versions, you'd have to wait for *another* document to specify *another*
SCSV to be able to prevent new protocol downgrade attacks, such as from TLS
1.3 to TLS 1.2.  Ideally all servers
implementing TLS_FALLBACK_SCSV/TLS_DOWNGRADE_SCSV would be fully version
tolerant, but obviously tolerance for *future* protocol versions is not a
server feature normally exercised in practice -- so to cope with the "Universal
Rule of Users", we'll have to assume that some servers may be around that
aren't fully version tolerant, while working perfectly as far as said Users
are concerned.  Hence the server logic to compare the client's protocol
version to the server's supported protocol version: if the client is
falling back to the server's highest supported protocol, that's not a
malicious protocol downgrade.

Similarly, implemented in TLS 1.2-intolerant servers,
draft-bmoeller-tls-downgrade-scsv-00 could prevent a rollback from TLS 1.1
to TLS 1.0 without breaking interoperability with clients employing a
fallback strategy (and using the SCSV); in TLS 1.1-intolerant servers, it
could prevent a rollback from TLS 1.0 with TLS extensions to TLS 1.0
without TLS extensions without breaking interoperability.  As you've noted,
if the SCSV is used by widely deployed clients first, we won't have to
worry about interoperability with such servers (because the vendors will
notice that their servers are broken before they get deployed).

So in that case, the special logic for client_hello_extension_list can be
removed from the specification (yay!); only the version comparison needs to
remain.

Bodo

PS: Needless to say ...

1. None of the above is meant to imply that I think of TLS version fallback
as a protocol feature meant to stay.  Rollback connections *are*
an abomination -- the I-D is all about what to do *if* we find ourselves in
the sad situation of having to reconnect for interoperability.  If we
manage to get rid of the need for that, all the better.

2. None of the above is meant to imply that we shouldn't retrofit secure
ciphersuites to older protocol versions.  This, too, seems pretty much
orthogonal to what this I-D is all about.  (A TLS 1.0 client hello
proposing only secure ciphersuites wouldn't need the SCSV.)

---

From: Adam Langley <[email-masked]>
Date: Wed, 27 Nov 2013 10:25:31 -0500

> their requirements around (CT, TACK, OCSP "must-staple", etc.)?

We already detect and relax requirements about public key pinning when
a MITM box is detected by a certificate that roots at a user-installed
CA.

The worry has generally always been around "firewall" like devices
that do DPI and "filter" certain TLS versions. They might still be a
problem but MITMs turned out to be so broken that we didn't get as far
as being able to test for them! The SCSV should let us do so.

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Wed, 27 Nov 2013 10:28:22 -0500

On Tue, Nov 26, 2013 at 8:42 PM, Brian Smith <[email-masked]> wrote:
> these fallback connections add a lot of
> we'd have to make yet *another* connection without the fallback.

I didn't have that in mind. In the code as I currently have it
written, an inappropriate_fallback doesn't trigger an "upgrade".
Rather the original error code that triggered the downgrade is
remembered and returned.

So the connection might go: TLS 1.2, connection reset; fallback to TLS
1.1, inappropriate_fallback; fail the connection with a connection
reset error.

We don't retry HTTP connections, after all.

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Wed, 27 Nov 2013 11:13:30 -0500

On Wed, Nov 27, 2013 at 6:40 AM, Bodo Moeller <[email-masked]> wrote:
> 1.3 to TLS 1.2.  Ideally all servers implementing
> TLS_FALLBACK_SCSV/TLS_DOWNGRADE_SCSV would be fully version tolerant, but
> obviously tolerance for *future* protocol versions is not a server feature
> normally exercised in practice -- so to cope with the "Universal Rule of
> Users", we'll have to assume that some servers may be around that aren't
> fully version tolerant, while working perfectly as far as said Users are
> concerned.  Hence the server logic to compare the client's protocol version
> to the server's supported protocol version: if the client is falling back to
> the server's highest supported protocol, that's not a malicious protocol
> downgrade.

Ah, I understand now, thanks. That's a good point, I'll do that.

Cheers

AGL

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 28 Nov 2013 13:21:47 +0100

Everyone,

the new I-D for TLS_FALLBACK_SCSV is now at
http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01.

I hope we can get rough consensus on this beyond Adam and me, and get it
adopted as a Working Group item with all due haste.

Bodo

---

From: "Jack Lloyd" <[email-masked]>
Date: Thu, 28 Nov 2013 16:46:38 -0500

> adopted as a Working Group item with all due haste.

+1 from me on this draft.

Jack

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 29 Nov 2013 09:51:48 +1100

> the new I-D for TLS_FALLBACK_SCSV is now at http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01.
>
> I hope we can get rough consensus on this beyond Adam and me, and get it adopted as a Working Group item with all due haste.
>
> Bodo

+1; looks like a useful and simple approach.

--
James Manger