Subject: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 09 Jan 2015 10:05:39 -0800

The IESG has received a request from the Transport Layer Security WG
(tls) to consider the following document:
- 'TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing
   Protocol Downgrade Attacks'
  <draft-ietf-tls-downgrade-scsv-03.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2015-01-23. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document defines a Signaling Cipher Suite Value (SCSV) that
   prevents protocol downgrade attacks on the Transport Layer Security
   (TLS) protocol.  It updates RFC 2246, RFC 4346, and RFC 5246.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 10 Jan 2015 14:31:16 -0500 (EST)

----- Original Message -----
>    (TLS) protocol.  It updates RFC 2246, RFC 4346, and RFC 5246.

The "TLS Fallback Signaling Cipher Suite" fix cannot be a proposed standard. 
The mechanism it fixes (the browser's special downgrade of TLS) is not an IETF
protocol, nor related to the TLS WG. Making this a proposed standard, would 
imply that the flawed technique is into standards track. I believe that this 
text should be informational.

regards,
Nikos

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 10 Jan 2015 15:54:09 -0500

> The mechanism it fixes (the browser's special downgrade of TLS) is not an
> IETF protocol, nor related to the TLS WG. Making this a proposed standard,
> would imply that the flawed technique is into standards track. I believe that
> this text should be informational.

I disagree.  Just because it addresses one common behavior, defining semantics for a client to say "I tried better, this is what I have now" and the related server semantics is a very good thing.  It keeps the  client/server interaction stateless (well on the server side) across multiple connections.

--  
Principal Security Engineer, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 11 Jan 2015 00:48:01 +0000

Hi Nikos,

On 10/01/15 19:31, Nikos Mavrogiannopoulos wrote:
> imply that the flawed technique is into standards track. 

I don't believe that that last conclusion follows. AFIAK there is
nothing to prevent the IETF standardising a fix for someone else's
or even our own past mistakes(*) even when those mistakes are not
on the standards track. And if in fact stardardising the "fix"
improves the Internet, then we should do that as the set of folks
responsible for this technology. (If doing so has IETF consensus.)

However, I'm pretty sanguine about us "doing the right thing
regardless" whereas I know others care more about the details of
this kind of thing so I'd be glad be corrected if I'm wrong about
this.

Cheers,
S.

(*) "mistake" is a bit pejorative but s/mistake/recently discovered
threat/ if you prefer - I think we reach the same conclusion so we
don't need to discuss if the downgrade dance was a mistake in order
to handle the issue that Nikos raises above.

> I believe that this 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 12 Jan 2015 10:15:56 +0100

> responsible for this technology. (If doing so has IETF consensus.)

It's not up to me to say whether there was consensus for this draft or
not. I voiced my opinion against that draft. However, if you think that
this has to be on standards track, please provide at least some
argumentation for it. 

As far as I understand, this fix exists because Microsoft, Google and
Mozilla cannot coordinate and drop their insecure negotiation of TLS.

regards,
Nikos

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 12 Jan 2015 11:11:53 +0000

Hi Nikos,

On 12/01/15 09:15, Nikos Mavrogiannopoulos wrote:
> not. 

Yep, we'll see when the IETF LC is done.

> I voiced my opinion against that draft. 

Not quite. You said this "cannot be" a PS based on an argument
that is independent of the content of the draft.

> However, if you think that

Sorry, I was only answering your general point above, where
you said the IETF couldn't produce a PS to fix a problem with
a non-IETF thing - I was addressing the "cannot be a proposed
standard" part. I think it clearly can, and given that you're
moving the discussion along to the specifics of the draft, I
assume you accept that.

So now you're being more specific and saying that I need
to provide an argument that this "has to be on the standards
track." I don't think I actually do need to provide such an
argument that there was no other good choice - that the TLS
WG chose to process it as a PS is reasonable enough. And are
we really going to benefit if we argue about the RFC status
here anyway? (Especially when it seems from the text below
and the WG list discussion that your main issue is with the
approach being taken and not with the RFC meta-data or
process followed.)

But in any case, this is changing protocol that is specified
in PS RFCs so a PS RFC does seem like the only good choice in
this case. I think the WG also made that choice because this
formally updates a bunch of RFCs and they want implementers
of those to pick this up, which is a teeny bit more likely
with the updates meta-data in the RFC editor's database.
That's explicitly noted in the shepherd's write-up [1] and I
assume was made clear on the WG list. As also noted in [1]
the volume of mail on this was very high, so I'd have to go
look. So having this be a PS that updates a bunch of other
PS RFCs is cleaner and I hope avoids a bunch of RFC process
wrangling. (It is sadly not uncommon for one or other of us
on the IESG to quibble about the utterly boring minutiae of
such relationships between RFCs as we process them:-)

> Mozilla cannot coordinate and drop their insecure negotiation of TLS.

I don't see that as a new argument. I think we all agree
there is a problem. The TLS WG (after much debate) chose
this particular approach. At this point I do not see that
opinions as to the ultimate cause of the problem are useful
for the IETF LC.

Cheers,
S.

[1]
https://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/shepherdwriteup/

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 12 Jan 2015 12:52:23 +0100

Nikos Mavrogiannopoulos <[email-masked]>:

>
> [...] However, if you think that

draft-ietf-tls-downgrade-scsv-03 mandates server-side behavior (in response
to certain Client Hello messages) that requires wide deployment to achieve
the desired effect, hence Standards Track seems appropriate and
Informational status would be insufficient.

I don't agree with your assessment that "Making this a proposed standard,
would imply that the flawed technique is into standards track."
draft-ietf-tls-downgrade-scsv-03
does not say that clients should implement a downgrade dance, it merely
recommends sending a certain signal *if* they choose to do so.

Also note that the point that some clients may use downgraded retries for
compatibility with buggy servers *is* already acknowledged by Standards
Track RFCs, e.g. RFC 5246 Appendix E.1:  "Note: some server implementations
are known to implement version negotiation incorrectly. [...]
Interoperability with such buggy servers is a complex topic beyond the
scope of this document, and may require multiple connection attempts by the
client."

Bodo

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 12 Jan 2015 13:03:34 +0100

> that is independent of the content of the draft.

I assumed that the history of discussions on this draft was known. There
have been long discussions in this list about this draft, where my
opinion was expressed. For example:
The thread:
https://www.ietf.org/mail-archive/web/tls/current/msg13871.html
My opinion:
http://www.ietf.org/mail-archive/web/tls/current/msg14016.html

regards,
Nikos

---

From: Hanno Böck <[email-masked]>
Date: Fri, 16 Jan 2015 21:03:27 +0100

Recently Mozilla has disabled the now so-called protocol dance, which
makes adding another workaround (SCSV) pretty much obsolete:
https://bugzilla.mozilla.org/show_bug.cgi?id=1084025#c7

And a few days ago mozilla dev Brian Smith tweetet this:
"Fx experiment to disable non-secure TLS version fallback is going even
better than expected. Starting to feel silly for delaying it so long."
https://twitter.com/BRIAN_____/status/555138042428526593

I think this adds further evidence that adding another workaround layer
(SCSV) is the wrong thing to do. Instead browsers should just stop
doing weird things with protocols that compromise security and drop
the protocol dance completely.

(By the way: Has anyone thought what happens when people implement TLS
hardware that is version intolerant to versions > 1.2 and at the same
time send SCSV in the handshake? I'm pretty sure that at some point
some hardware will appear that does exactly that. Will we need another
SCSV standard for every TLS version then?)

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42

---

From: Yuhong Bao <[email-masked]>
Date: Fri, 16 Jan 2015 12:05:07 -0800

This does not mean that every browser will do it.

----------------------------------------
Date: Fri, 16 Jan 2015 21:03:27 +0100
From: [email-masked]
To: [email-masked]
CC: [email-masked]
Subject: Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard

hardware that is version intolerant to versions> 1.2 and at the same

--
Hanno Böck
http://hboeck.de/

---

From: Adam Langley <[email-masked]>
Date: Fri, 16 Jan 2015 12:10:18 -0800

> makes adding another workaround (SCSV) pretty much obsolete:

Until they add TLS 1.3 support, when they'll need it again.

> SCSV standard for every TLS version then?)

The draft specifies that servers should compare the ClientHello
version to the version that they implement. If a client tries TLS 1.3,
fails because of intolerance then tries TLS 1.2 + FALLBACK_SCSV, the
server will accept the connection because the ClientHello version is
>= its maximum version.

Cheers

AGL

---

From: Andrei Popov <[email-masked]>
Date: Fri, 16 Jan 2015 20:13:48 +0000

> This does not mean that every browser will do it.

True, but if FF is able to stick with this, and roll it out into production, that's a strong indication that other browsers may be able to do the same. And, of course, this eliminates the fallback problem at the root.

One remaining issue, however, is reported high rates of TLS 1.3 version intolerance.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Yuhong Bao
Sent: Friday, January 16, 2015 12:05 PM
To: Hanno Böck; [email-masked]
Cc: [email-masked]
Subject: Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard

Recently Mozilla has disabled the now so-called protocol dance, which makes adding another workaround (SCSV) pretty much obsolete:
https://bugzilla.mozilla.org/show_bug.cgi?id=1084025#c7

And a few days ago mozilla dev Brian Smith tweetet this:
"Fx experiment to disable non-secure TLS version fallback is going even better than expected. Starting to feel silly for delaying it so long."
https://twitter.com/BRIAN_____/status/555138042428526593

I think this adds further evidence that adding another workaround layer
(SCSV) is the wrong thing to do. Instead browsers should just stop doing weird things with protocols that compromise security and drop the protocol dance completely.

(By the way: Has anyone thought what happens when people implement TLS hardware that is version intolerant to versions> 1.2 and at the same time send SCSV in the handshake? I'm pretty sure that at some point some hardware will appear that does exactly that. Will we need another SCSV standard for every TLS version then?)

--
Hanno Böck
http://hboeck.de/

---

From: Watson Ladd <[email-masked]>
Date: Fri, 16 Jan 2015 12:38:54 -0800

On Jan 16, 2015 12:14 PM, "Andrei Popov" <[email-masked]> wrote:
> True, but if FF is able to stick with this, and roll it out into
production, that's a strong indication that other browsers may be able to
do the same. And, of course, this eliminates the fallback problem at the
root.
> One remaining issue, however, is reported high rates of TLS 1.3 version
intolerance.

Why are we insisting on increasing on the wire version numbers for TLS 1.3,
instead of using the extension mechanism, even though we know this will
cause adoption problems?

Sincerely,
Watson Ladd
> Subject: Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS
Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol
Downgrade Attacks) to Proposed Standard
> Subject: Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS
Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol
Downgrade Attacks) to Proposed Standard
> (SCSV) is the wrong thing to do. Instead browsers should just stop doing
weird things with protocols that compromise security and drop the protocol
dance completely.
> (By the way: Has anyone thought what happens when people implement TLS
hardware that is version intolerant to versions> 1.2 and at the same time
send SCSV in the handshake? I'm pretty sure that at some point some
hardware will appear that does exactly that. Will we need another SCSV
standard for every TLS version then?)

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 16 Jan 2015 22:04:16 +0100

Hanno Böck <[email-masked]>:

> the protocol dance completely.

They shouldn't have to do the downgrade dance (and indeed
draft-ietf-tls-downgrade-scsv-03 does say so), and certainly I'll be very
glad if it turns out that now they really won't have to, but I wouldn't
hold my breath.

Ideally, the server-side TLS_FALLBACK_SCSV logic will be present as dormant
code that never gets executed (because clients just don't do those
fallbacks), but which is available if and when needed again.

I hope that the Firefox change will make it into the release channel and
survive there, but note that it doesn't actually remove the downgrade dance
entirely. Rather, there's now a setting that controls whether the downgrade
dance is enabled (https://bugzilla.mozilla.org/show_bug.cgi?id=1083058),
and the plan merely is to disable this by default (
https://bugzilla.mozilla.org/show_bug.cgi?id=1084025). Also, you may be
able to enable the kludge on a per-domain basis (
https://bugzilla.mozilla.org/show_bug.cgi?id=1114816).

There's still a lot that can happen here. If the change works well enough
for the Firefox release channel (and for all other browsers), I still
expect that a bunch of users will need to enable the downgrade dance to get
HTTPS connections to legacy devices on their local networks to work. Then
it would be discomforting to not have TLS_FALLBACK_SCSV support in servers.

Also, quite clearly, we can't yet know how the TLS 1.3 (1.4, 1.5, ...)
rollout will work out.

Bodo

---

From: Brian Smith <[email-masked]>
Date: Fri, 16 Jan 2015 13:19:06 -0800

> Until they add TLS 1.3 support, when they'll need it again.

I don't think so, because we can change the way versions are
negotiated for TLS 1.3, so that the issue doesn't arise. In
particular, we can keep ClientHello.client_version as 0x0303 (TLS 1.2)
and negotiate TLS 1.3 with an extension.

Also, the rate of TLS 1.3 intolerance might be significantly lower
than projected. Ivan's numbers are based on a ClientHello with 0x0304
(TLS 1.3) as the record-layer version number. We know from past
experience working on NSS that 0x0301 (TLS 1.0) is a more compatible
record-layer version number. I think it was established that many
servers work fine when ClientHello.client_version = 0x0304 (TLS 1.3)
as long as the record-layer version number is 0x0301 (TLS 1.0) but
break when then record-layer vsion is 0x0304 (TLS 1.3). We'll need to
measure this in a more definitive way, but there's reason to be
optimistic.

Cheers,
Brian

---

From: [email-masked] (Martin Rex)
Date: Sat, 17 Jan 2015 00:08:10 +0100 (CET)

Brian Smith wrote:
> break when then record-layer vsion is 0x0304 (TLS 1.3).

Sending { 0x03, 0x04 } at the record layer for the ClientHello at the
beginning of a new connection MUST be expected to get unconditionally
rejected by pre-TLSv1.2 servers.  It puzzles me to why so many implementers
get this wrong.

Adding the aggressive automatic silent fallback reconnects
(the "downgrade dance") to browser was not very smart.  The problems
such fallbacks create was extensively discussed in the TLS WG in late 2009
(renegotiation issue that resulted in rfc5746).

But what was a really bad idea was neither offering a user an opt-in
for individual downgrades, nor allowing the user to disable the downgrade
dance.  Also not attempt was made to count how often downgrades happened,
nor to limit how often browsers would perform automatic silen downgrades.
This gross negligence was one of the reasons why the brittle connection
management in Firefox, that regularly caused downgrades all by itself,
was (a) unnoticed by the responsible developers and (b) was ignored
for almost 6 years after reported as an easily reproducible FF bug...

Making repetitive/frequent downgrades (e.g. more than 1 full handshake
per host per hour) an interactive user opt-in, rather than the automatic
silent can-not-be-disabled-by-user nuisance and security problem that it
currently is, would immediately provide significant protection
-- and entirely without server-side changes.  As a bonus, this would also
help in identifying/reminding on server software/devices that should
probably be updated.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Sat, 17 Jan 2015 05:57:00 +0100 (CET)

> help in identifying/reminding on server software/devices that should

For quite a while, Yngve Petterson has been proposing a scheme to
limit the downgrade dance problem (and willingness of clients/browsers
to perform the downgrade dance), that will work immediately, not require
and server-side changes, and without all of the massive serious operational
problems of the current fallback-scsv proposal:

  https://tools.ietf.org/html/draft-pettersen-tls-version-rollback-removal-03

Rubber-Stamping the fallback-scsv hack onto the standards track is
IMHO a very bad idea.

I've once heard the saying "If you can't be good, at least be good at it."

If Browsers (and the few, if any) other TLS clients that are currently
doing the dangerous downgrade dances, can't be good and stop doing
such dangerous stuff, they should at least do this in a much less
risky fashion than what they're currently doing.

... such as adopting Yngve's approach above and do not perform downgrades
without interactive user confirmation where Yngve's proposal asks for a
handshake failure.

bottom line:  I am violently opposed to making the fallback-scsv
document a proposed standard.

-Martin

---

From: Jeffrey Walton <[email-masked]>
Date: Sat, 17 Jan 2015 00:07:44 -0500

> Also, quite clearly, we can't yet know how the TLS 1.3 (1.4, 1.5, ...)
The WG should be solving problems that do exist; and not manufactured
problems or theoretical future problems that don't exist.

Jeff

---

From: Yoav Nir <[email-masked]>
Date: Sat, 17 Jan 2015 09:55:37 +0200

> On Jan 17, 2015, at 7:07 AM, Jeffrey Walton <[email-masked]> wrote:
> 

They’re not theoretical. Servers that do not tolerate (0x03,0x04) in ClientHello exist *now*. Surprisingly, some of those do support TLS 1.2 and Renegotiation Info. Unless those are all gone by the time browsers roll out TLS 1.3, there will be a problem to solve.

Yoav

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 17 Jan 2015 06:36:47 -0800

> measure this in a more definitive way, but there's reason to be

Thanks for the detail. I've been planning to run some experiments using
Firefox Telemetry, but haven't gotten around to them yet. More when
I have them.

-Ekr

Cheers,

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 17 Jan 2015 13:31:29 -0500

> without all of the massive serious operational problems of
> the current fallback-scsv proposal:

Can you elaborate on what this problems are?  We didn't see any at Akamai.  I wonder if we got lucky?

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 18 Jan 2015 21:12:01 +0100

Jeffrey Walton <[email-masked]>:

> Bodo Moeller <[email-masked]> wrote:
>

> problems or theoretical future problems that don't exist.

I can't entirely agree with second part of this statement: presumably
everyone in the TLS WG is well aware of past design decisions that didn't
take into account problems that didn't exist then but should have been
foreseeable.  (Related: I really shouldn't have had to write
https://www.openssl.org/~bodo/ssl-poodle.pdf to kill off the fallback to
SSL 3.0 in practice ... the "insecure fallback" to earlier protocol
versions, including SSL 3.0, was a known "theoretical problem", and
deserving of being addressed independently of concrete attacks).

I do agree with the sentiment, though: we shouldn't create Rube-Goldberg
protocol mechanisms that don't serve a demonstrable purpose (and yet TLS
arguably has a fair number of those).  If the I-D was all about solving a
theoretical problem with TLS 1.3, it shouldn't be accepted as an RFC (if
only because then the TLS 1.3 specification would be the right place to
specify the mechanism).

But of course, this isn't the case.  The main point of the I-D is not to
solve a problem with TLS 1.3.  Rather, the specification's main purpose, at
this time, is to solve problems with earlier versions.  Notably, the
mechanism from this specification has demonstrably protected users against
vulnerabilities such as POODLE.  It's just that the I-D achieves that by
specifying a version-independent mechanism that *also* lends itself to
addressing potential future problems with potential future protocol
versions.

Bodo

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sun, 18 Jan 2015 12:32:52 -0800

> beginning of the Subject line to allow automated sorting.

+1 on making this document a standard.

The mechanism seems sensible and pragmatic.  I have implemented the
mechanism on the server side and the document was clear and helpful;
it took only a few minutes.

I'm not clear on how the IANA process works, but if the document
progresses to RFC (in any status); it'd be great if the existing
extension number and alert values were to remain the same.

-- 
Colm

---

From: Yuhong Bao <[email-masked]>
Date: Mon, 19 Jan 2015 00:01:55 -0800

________________________________
> Date: Sun, 18 Jan 2015 21:12:01 +0100 
> From: [email-masked] 
> To: [email-masked] 
> CC: [email-masked] 
> Subject: Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> 
> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing 
> Protocol Downgrade Attacks) to Proposed Standard 
> 
> Jeffrey Walton <[email-masked]<mailto:[email-masked]>>: 
> Bodo Moeller <[email-masked]<mailto:[email-masked]>> wrote: 
> 
> everyone in the TLS WG is well aware of past design decisions that 
> didn't take into account problems that didn't exist then but should 
> have been foreseeable. (Related: I really shouldn't have had to 
> write https://www.openssl.org/~bodo/ssl-poodle.pdf to kill off the 
> fallback to SSL 3.0 in practice ... the "insecure fallback" to earlier 
> protocol versions, including SSL 3.0, was a known "theoretical 
> problem", and deserving of being addressed independently of concrete 
> attacks). 
POODLE being in the news probably helped pushed admins to fix these servers, 
though it wasn't initially made clear that TLS extension intolerance can also cause SSLv3 fallback.

---

From: [email-masked] (Martin Rex)
Date: Mon, 19 Jan 2015 16:54:56 +0100 (CET)

Salz, Rich wrote:
> Can you elaborate on what this problems are?

The current document scratches the tip of the iceberg here:
   https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-03#section-5

We know that part of the problem isn't TLS version/extension intolerant
servers, but version/extension intolerant middle-boxes.  These can be
client-side middleboxes, network middle-boxes or servers-side middleboxes.
In such cases, the server will only see handshakes with the
fallback SCSV asserted and, if it supports a sufficiently new protocol
will (have to) abort all TLS handshakes that reach the server in a
knee-jerk-reaction if it follows that proposal.  There is exactly zero
room for common sense behaviour left by this proposal.

We also know that there is a significant amount of installed-base servers
which never return any fatal SSL alerts before closing a network connection
after a TLS handshake failure (Microsoft IIS), because they're using
a transport-less TLS protocol stack and the application caller (not just
the TLS server-side implementation) will have to be changed in order to
make a fatal TLS alert newly appear on the network.

Aborting the TLS handshake is going to be the most stupid behaviour
in any case, because it will require a new TCP connection and a
new TCP handshake, plus any necessary app-level protocol negotiation
(HTTP CONNECT proxy traversal and pre-STARTTLS protocol handshakes)
to be repeated.

It would be so *MUCH* cleaner and easier when a different server behaviour
was specified and allowed (rather than rubber-stamping the knee-jerk-reaction),
such as allowing the server to continue the TLS handshake with
protocol version (ClientHello.client_version + 1) when ClientHello
contained the FALLBACK_SCSV among the TLS ciphersuites.

Such server behaviour would still allow the client to recognize that
the server could do better when offered, and allow the client to perform
sensible risk management -- becaus only the client knows what kind of
"better" protocol options it did not offer (remove) from his ClientHello
and how often it attempted to connect to the server.

Continuation of the handshake would also work much nicer (not require any
app-level changes) with servers such as Microsoft IIS, which currently
do not send fatal alerts back before closing the network connection.

(the only thing we would have to addtionally specify for servers
 continuing with (ClientHello.client_version + 1) is to skip doing
 the protocol version check on the RSA premaster secret for
 static-RSA key exchanges).

Another problem of the current proposal is that it addresses only
TLS version intolerance, but not TLS extension intolerance.  *BOTH*
exist out there.  And it doesn't really address reconnect fallbacks
that skip TLS versions on the downgrade dance.   MSIE 8 on Windows 7
will apparently perform the downgrade dance in the fashion
  TLSv1.2 -> TLSv1.0 -> SSLv3

This gets more important if the cause for handshake failures are
middle-boxes rather than the servers themselves.

-Martin

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 19 Jan 2015 17:21:33 +0000

I read your note very carefully.  It is a nice detailed list of things that could be improved.

But I see no elucidation of any massive serious operational problems.  The I-D section you pointed to contains an answer. Many large network operators have rolled this out, and the net has been pretty silent about any "tales of woe."

	/r$

---

From: [email-masked] (Martin Rex)
Date: Mon, 19 Jan 2015 20:27:01 +0100 (CET)

Salz, Rich wrote:
> I read your note very carefully.
> It is a nice detailed list of things that could be improved.

Permitting the server to continue the TLS handshake with
ServerHello.server_version = (ClientHello.client_version +1)

This would be an extremely small change, but a *HUGE* improvement to this
proposal and make TLS handshakes _succeed_, i.e. promote interop.
Should a TLS client be unsatisfied with the properties of the resulting
TLS session, that client could still decide attempting a new/different
handshake by proposing additional features in ClientHello (that should
have never been absent from ClientHello in the first place).

And this improvement is something that I could imagine implementing
for our servers -- other than the currently specified knee-jerk-reaction.

> 
> But I see no elucidation of any massive serious operational problems.
> The I-D section you pointed to contains an answer.

The current last call is a request to rubber-stamp the current
fallback-scsv proposal, that wants to require from the server
an unconditional knee-jerk-reaction and complete interop failure,
onto the standards track.

It is difficult to conceive a proposal that violates rfc2116 section 6
in a more serious fashion than the current fallback-scsv proposal --
and fixing this would be trivial (see above).

It's not that suggestions to improvement to this proposal haven't been
made.  It's really disappointing to see this go _through_ the TLS WG
and not seeing any improvement whatsoever, and then going straight
to asking for rubber-stamping it.

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

>
> Many large network operators have rolled this out, and the net has
> been pretty silent about any "tales of woe."

If all of the parties that you care for already have this implemented,
then there is no need to puslish this proposal on the standards track
any more.  So we don't have to find out how others implement this.

I can easily remember the unfortunate outcome the last time that
the TLS WG asked for anal behaviour (RSA premaster secret version check)
and how much interop problems this caused in the installed base
because one vendor decided to ship this unvalidated:

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

This particular handshake failure flaw has is known for > 3 years,
and still has not been fixed on the platform that has by far the
largest market share...

No, I am *NOT* in favour of the IESG rubber-stamping another proposal
for TLS handshake failures, when the alternative, allowing a handshake
complete with better properties (such as suggested at the beginning
of this message) will be trivial to achieve. 

Several implementers may be in the fortunate position to ignore or
laugh at most end-users that see error messages or white pages in
their browsers.

And the firefox bug with the brittle client-side connection management
that caused fallbacks to SSLv3 all by itself over several years:
   https://bugzilla.mozilla.org/show_bug.cgi?id=450280

is a good example of this.

I'm not in such a position.  We take support seriously, and we try
to actually help customers overcome interoperability problems, even
when such interop problems are caused by third party software or
network middle-boxes.  (We don't actually fix third-party software,
but I do the analysis sufficiently thorough so that customers request
patches for clear defects from the relevant vendors).

-Martin

---

From: Brian Smith <[email-masked]>
Date: Mon, 19 Jan 2015 12:58:28 -0800

> proposal and make TLS handshakes _succeed_, i.e. promote interop.

This doesn't work. Consider this example of how your suggestion would work:

Client and server both support TLS 1.2.

Client attempts TLS 1.2, receives RST.
Client attempts TLS 1.1 w/ downgrade SCSV, receives RST.
Client attempts TLS 1.0 w/ downgrade SCSV, receives TLS 1.1 ServerHello.

This results in a downgrade from TLS 1.2 to TLS 1.1.

> have never been absent from ClientHello in the first place).

I think at this point browsers are only "satisfied" when the
connection is TLS 1.2 using an AEAD cipher suite, but they still feel
the need to support servers that only support worse crypto. So, this
part of the idea doesn't work either.

> to asking for rubber-stamping it.

I don't think that the characterization of "rubber-stamping" is
accurate or helpful for moving the discussion forward.

I DO think it would be useful for the IETF to wait ~8 weeks to see the
results of Firefox's experiment in disabling the non-secure fallback,
and to see the results of studies of TLS 1.3 intolerance with
ClientHello messages with different record-level version numbers. If
it turns out to be reasonable for web browsers to stop doing the
non-secure fallback, then it really would be bad policy for IETF to
make the downgrade a proposed standard, because the downgrade SCSV
will always be limited in effectiveness by the fact that a huge number
of servers will not deploy the downgrade SCSV mechanism any time soon.
Still, it's not clear yet that web browsers can reasonably stop doing
the non-secure fallback, so I think it makes sense to have the
downgrade SCSV mechanism ready as insurance.

Cheers,
Brian

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 20 Jan 2015 00:06:44 +0000

> ServerHello.server_version = (ClientHello.client_version +1)

Brian pointed out that this seems to not work.

> And this improvement is something that I could imagine implementing for
> our servers -- other than the currently specified knee-jerk-reaction.

Can we avoid this kind of language?

---

From: [email-masked] (Martin Rex)
Date: Tue, 20 Jan 2015 01:59:14 +0100 (CET)

> This results in a downgrade from TLS 1.2 to TLS 1.1.

The improvement works *PERFECTLY* in your above example.

 - the server continues the handshake successfully
 - the client can clearly see from the server's response that the
   server recognized the FALLBACK_SCSV

It is then properly up to the client who asserted FALLBACK_SCSV
to consciously decide whether aborting the current handshake could
*really* provide a benefit, maybe even keeping the established session
around.

In case the server, or client, or both, support only RC4 stream cipher 
and CBC cipher suites, the resulting TLS session with TLSv1.1
(the version that succeeds in your example) is comparable in strength
to one that would have succeeded with TLSv1.2.

The improvement is already better by a significant margin that the current
proposal if it makes *additional* TLS handshakes complete rather than fail
compared to the current proposal.  In your above example,

Now the part that you didn't say here:  if the cause of the RSTs wasn't
an attacker, but a dense middle-box, then the result would be a complete
interop failure -- and the only workaround (rather than the user removing
the "s" from the https://some.host/ URL), would be for the client to
not send the FALLBACK_SCSV -- in which case the entire protection scheme
would fail.

> part of the idea doesn't work either.

Many servers do not even support AEAD cipher suites, including lots of
servers that support TLSv1.2.  And hundreds of millions of clients do
not support AEAD cipher suites either (think mobile).

Keep in mind that TLSv1.2 (rfc5246) contains not a single AEAD cipher
suite in the base specification, and the mandatory-to-implement cipher
suite in TLSv1.2 is TLS_RSA_WITH_AES_128_CBC_SHA.
Until _VERY_ recently (in a botched initial Hotfix delivery), Microsoft
did not support any AEAD cipher suites with RSA server certificates
on Windows 7 & 2008R2.

Random pick of a production Akamai server (TLSv1.2, but no AEAD):
https://www.ssllabs.com/ssltest/analyze.html?d=www.microsoft.com&s=23.203.223.109

-Martin

---

From: [email-masked] (Martin Rex)
Date: Tue, 20 Jan 2015 23:46:03 +0100 (CET)

> Brian pointed out that this seems to not work.

Technically, my proposed and extremely simple improvement works *PERFECTLY*
in his example.  But Brian and I might be talking past each other.

I'm not saying that the early adopters of the downgrade-scsv proposal
must change.  But I also do not want to see a knee-jerk reaction, that
can easily lead to a complete interop failure rubber-stamped for
standards track, when it could be easily improved by allowing servers
an alternative response that bears a significantly lower risk of
causing harm in the form of complete interop failure, when shipped
as server patch into an installed base of unknown usage scenarios.

The semantics of the FALLBACK_SCSV (i.e. the presence of the cipher suite
in ClientHello) specified in the current proposal could be described as

"Client signals to Server that it supports a TLS protocol version
 that is higher than what is currently conveyed in ClientHello.client_version".

The semantics of the fatal inappropriate_fallback(86) alert from the
server of the current proposal could be described as

"Server signals to Client that it also supports a TLS protocol version
 that is higher than what the server received in ClientHello.client_version".

Improving the current downgrade-scsv proposal, by giving the server the
choice to alternatively continue the TLS handshake successfully, using
ServerHello.server_version = (ClientHello.client_version+1) will convey
back to the client the same information as the "inappropriate_fallback(86)"
fatal alert--but give the client significantly *MORE* options to
perform a successful TLS handshake with that server.

The server's willigness to continue the handshake, selected from among
the TLS protocol options actually offered in ClientHello, is *NOT* an
obligation for the client to continue that handshake and to send
application data over the resulting session.  If the TLS client believes
that it could do better, it may take chances and retry a new connection
immediately.  But with the alternative of a successful continuation of
the handshake, interop is still a viable option to the client, and not
all conceivable protocol downgrades will actually impair the security.

Clients, in particular Web Browsers, are notorious about breaking
connections frequently and during all connection states (after connect
after TLS handshake start or during data transfer).  This may be users
doing navigation on partially loaded pages that contain myriads of embedded
seperate objects, or this may be active scripting composing colorful
UIs from myriads of small UI elements.

Servers, on the other hand, are normally patient and well-behaved, but
may appear unresponsive under high load or flaky network connectivity.

I firmly believe that most of the causes for TLS protocol downgrades
will continue to be non-malicious rather than active attacks.  And
in many cases, the proposed improvement of the server successfully
continuing with ServerHello.server_version=(ClientHello.client_version + 1)
will provide a comparable level of security to what would happen had
the client had proposed a higher protocol version in ClientHello.
So this improvement can also save network round-trips on non-malicious
downgrades.

Looking at the downgrade dance of Firefox 34, it does

  1.  record={3,1}   client_version={3,3}  + extensions
  2.  record={3,1}   client_version={3,2}  + extensions
  3.  record={3,1}   client_version={3,1}  + extensions
  <error page>

So Firefox seems to have abandoned not only SSLv3, but also
extension-less ClientHellos.

It seems that the only "problem" that is left here, is an unfortunate
requirement in AEAD cipher suite RFCs (such as AES-GCM, rfc5288):

https://tools.ietf.org/html/rfc5288#section-4

   4.  TLS Versions

   These cipher suites make use of the authenticated encryption with
   additional data defined in TLS 1.2 [RFC5246].  They MUST NOT be
   negotiated in older versions of TLS.
*                                         Clients MUST NOT offer these
*   cipher suites if they do not offer TLS 1.2 or later.
                                                         Servers that
   select an earlier version of TLS MUST NOT select one of these cipher
   suites.  Because TLS has no way for the client to indicate that it
   supports TLS 1.2 but not earlier, a non-compliant server might
   potentially negotiate TLS 1.1 or earlier and select one of the cipher
   suites in this document.  Clients MUST check the TLS version and
   generate a fatal "illegal_parameter" alert if they detect an
   incorrect version.

Considering that TLS version intolerance had been well-known when the
AEAD cipher suite documents where published, the above (*) requirement
should have better been something like the following from the beginning:

   When a Client offers any of these cipher suites, it implies that
   the client supports and is willing to use protocol version TLS 1.2
   or later.  This implication will take precedence over any protocol
   version in ClientHello.client_version that is lower than TLS 1.2,
   and might have been used by the client purely for better interoperability
   with old or defective TLS servers that are intolerant to newer TLS
   protocol versions in ClientHello.client_version.

Then browsers would not have had to worry as much about their downgrade
dance, there would be a strong argument for programmatic clients (those
that do not contain any app-level downgrade dance heuristics)
to adopt TLSv1.2 + AEAD cipher suites.

How about assigning a small number (<=4) of alternative TLS cipher suite IDs
to existing AEAD TLS cipher suites than will carry the above implication?

Candidate cipher suites for assignment of an alias cipher suite ID:

     CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256    = {0xC0,0x27};
     CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384    = {0xC0,0x28};

-Martin

---

From: Xiaoyin Liu <[email-masked]>
Date: Tue, 20 Jan 2015 23:01:31 -0500

Hi,
 
I just finished a scan of Alexa top 1 million websites to test for TLS version intolerance. I hope this information can be useful in the discussion of downgrade SCSV.
 
For each site, I made at most four attempts with the following order to fallback:
(TLS 1.3, TLS 1.3) -> (TLS 1.0, TLS 1.3) -> (TLS 1.0, TLS 1.2) -> (TLS 1.0, TLS 1.0)
where the first is TLS record layer version, and the second is Client Hello version.
 
Here is the result:
(1) Number of sites scanned: 1,000,001
(2) Number of DNS Error: 45,402
(3) Number of sites that refuse TCP connection on port 443 (RST, timeout): 289,334
(4) Number of sites that fail sending ServerHello in all 4 attempts: 238,846
(5) Number of sites that are tolerant to (TLS1.3, TLS1.3): 397,152 (93.1%)
(6) Number of sites that need to fallback to (TLS1.0, TLS1.3): 22,461 (5.3%)
(7) Number of sites that need to fallback to (TLS1.0, TLS1.2): 6,352 (1.5%)
(8) Number of sites that need to fallback to (TLS1.0, TLS1.0): 454 (0.1%)

The total number of TLS enabled sites is 426,419. TLS 1.3 intolerant sites (7 and 8) are about 1.6%. TLS 1.2 intolerant sites are about 0.1%. Also it shows setting a lower record layer version does improve compatibility a lot. An example is https://paypal.com is intolerant to (TLS 1.3, TLS 1.3) but is tolerant to (TLS 1.0, TLS 1.3). Please note that I did not validate certificates nor check the integrity of handshakes. I closed the connection immediately after receiving ServerHello.
 
If my data is accurate, I am against making downgrade SCSV a proposed standard, and I believe browsers should stop insecure fallback. At least, the percentage of TLS 1.2 intolerant sites is low enough. For TLS 1.3, I think maybe browser vendors can announce a deadline, after which fallback to TLS 1.2 will no longer be accepted? Or simply break them? Both are reasonable to me. Also I want to point out that if even as few as 1.6% sites won't upgrade their servers, can we count on most of the rest 98% supporting SCSV?
 
P.S. The statistic of Server Hello version is:
(9) SSL 2.0: 0 (0.0%)
(10) SSL 3.0: 413 (0.1%)
(11) TLS 1.0: 176051 (41.3%)
(12) TLS 1.1: 2261 (0.5%)
(13) TLS 1.2: 247668 (58.1%)
(14) Above TLS 1.2: 26 (0.0%, malformed response)
 
The raw data of my scan result can be downloaded from here: https://onedrive.live.com/redir?resid=8D6F364311BB35F2!110&authkey=!AI5Kno4OzsXbkII&ithint=file%2czip.
 
Best,
Xiaoyin

> Date: Mon, 19 Jan 2015 12:58:28 -0800
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Wed, 21 Jan 2015 08:47:15 +0200

Hi, Xiaoyin

Thank you for the effort. I have one question. See below

> On Jan 21, 2015, at 6:01 AM, Xiaoyin Liu <[email-masked]> wrote:
> 
> Hi,
>  

What do you mean by tolerance here? Since no servers at all support TLS 1.3, they have to break this kind of connection. Does it count as tolerance if they issue the proper alert?

> (6) Number of sites that need to fallback to (TLS1.0, TLS1.3): 22,461 (5.3%)

Does tolerance here and below means the same thing as above? In other words, do they count as tolerant if they break the connection, or only if they respond in TLS 1.2, 1.1, or 1.0 ?

> The total number of TLS enabled sites is 426,419. TLS 1.3 intolerant sites (7 and 8) are about 1.6%. TLS 1.2 intolerant sites are about 0.1%. Also it shows setting a lower record layer version does improve compatibility a lot. An example is https://paypal.com <https://paypal.com/> is intolerant to (TLS 1.3, TLS 1.3) but is tolerant to (TLS 1.0, TLS 1.3). Please note that I did not validate certificates nor check the integrity of handshakes. I closed the connection immediately after receiving ServerHello.
>  
> If my data is accurate, I am against making downgrade SCSV a proposed standard, and I believe browsers should stop insecure fallback. At least, the percentage of TLS 1.2 intolerant sites is low enough.

I think you will find that browser vendors may not consider this low enough. 

> For TLS 1.3, I think maybe browser vendors can announce a deadline, after which fallback to TLS 1.2 will no longer be accepted? Or simply break them? Both are reasonable to me.

OpenSSL has been version tolerant forever. As has Microsoft’s SChannel. I’m not sure, but I think the Java library is as well. The people running these servers are using some exotic technology, and it’s not clear they know how to upgrade them.

> Also I want to point out that if even as few as 1.6% sites won't upgrade their servers, can we count on most of the rest 98% supporting SCSV?

This is a strong argument, especially if we could obtain a list of high-value sites in the sense that the data on them is high-value. Sites like Facebook, banking, shops, email providers, dating sites, and check those. 

Yoav

---

From: Xiaoyin Liu <[email-masked]>
Date: Wed, 21 Jan 2015 02:40:48 -0500

Hi, Yoav, Thanks for your reply! Here is my answer: What do you mean by tolerance here? Since no servers at all support TLS 1.3, they have to break this kind of connection. Does it count as tolerance if they issue the proper alert?            A: I count a server tolerant to TLS 1.3 if and only if it replies a ServerHello handshake message with its version being TLS 1.2 or lower. Sending fatal alert (such as handshake failure, decode error, and protocol version) is not considered as tolerance. By the way, I wonder what's the proper alert here, since RFC 5246 Appendix E.1 requires "if a TLS server receives a ClientHello containing a version number greater than the highest version supported by the server, it MUST reply according to the highest version supported by the server".
 Does tolerance here and below means the same thing as above? In other words, do they count as tolerant if they break the connection, or only if they respond in TLS 1.2, 1.1, or 1.0 ?          A: Yes, all of the "tolerance" means the same thing: only if they respond in TLS 1.2, 1.1, 1.0 or SSL 3.0.  Best, Xiaoyin
 Subject: Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
From: [email-masked]
Date: Wed, 21 Jan 2015 08:47:15 +0200
CC: [email-masked]
To: [email-masked]

Hi, Xiaoyin
Thank you for the effort. I have one question. See below
On Jan 21, 2015, at 6:01 AM, Xiaoyin Liu <[email-masked]> wrote:Hi,

 
Here is the result:

---

From: Yoav Nir <[email-masked]>
Date: Wed, 21 Jan 2015 11:16:43 +0200

Thanks

In that case, I think my implementation would fail with (1.3,1.3). Since I can’t know what changes TLS 1.3 made to the record layer, I can’t be sure that I understand what I’m parsing. Perhaps those bytes that I thought were the ClientHello are actually some new fields that were added to the record header.

If the record layer version exceeds what the server supports, I think it wouldn’t be prudent to reply with anything but an alert. Many implementations treated the record layer version in the ClientHello as a minimum version number. Yes, I know this goes against a MUST requirement in appendix E.1 or RFC 5246, but as that appendix says, this is behavior that is often implemented.

Yoav

> On Jan 21, 2015, at 9:40 AM, Xiaoyin Liu <[email-masked]> wrote:
> 
> Hi, Yoav,
>  
> Thanks for your reply! Here is my answer:
>  
>            A: I count a server tolerant to TLS 1.3 if and only if it replies a ServerHello handshake message with its version being TLS 1.2 or lower. Sending fatal alert (such as handshake failure, decode error, and protocol version) is not considered as tolerance. By the way, I wonder what's the proper alert here, since RFC 5246 Appendix E.1 requires "if a TLS server receives a ClientHello containing a version number greater than the highest version supported by the server, it MUST reply according to the highest version supported by the server".
> 
>  
>           A: Yes, all of the "tolerance" means the same thing: only if they respond in TLS 1.2, 1.1, 1.0 or SSL 3.0. 
>  
> Best, 
> Xiaoyin
>  
> On Jan 21, 2015, at 6:01 AM, Xiaoyin Liu <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi,
>

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 21 Jan 2015 11:56:01 +0100

> In that case, I think my implementation would fail with (1.3,1.3).
> Since I can’t know what changes TLS 1.3 made to the record layer, I
> can’t be sure that I understand what I’m parsing. Perhaps those bytes
> that I thought were the ClientHello are actually some new fields that
> were added to the record header.

You can know that. It is mentioned in rfc5246:
https://tools.ietf.org/html/rfc5246#appendix-E.1

"TLS servers compliant with this specification MUST accept any value
{03,XX} as the record layer version number for ClientHello."

It is, then, explicit that the record format cannot change without
changing the TLS major version from 03 to 04 or so.

> If the record layer version exceeds what the server supports, I think
> it wouldn’t be prudent to reply with anything but an alert. Many
> implementations treated the record layer version in the ClientHello as
> a minimum version number. Yes, I know this goes against a MUST
> requirement in appendix E.1 or RFC 5246, but as that appendix says,
> this is behavior that is often implemented.

Well, we can only interoperate as long as we implement the same
protocol, and the protocol is specific on what to do in that case.

regards,
Nikos

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 21 Jan 2015 16:11:31 +0100

Yoav Nir <[email-masked]>:

Also I want to point out that if even as few as 1.6% sites won't upgrade
> their servers, can we count on most of the rest 98% supporting SCSV?
>
>
> This is a strong argument, especially if we could obtain a list of
> high-value sites in the sense that the data on them is high-value. Sites
> like Facebook, banking, shops, email providers, dating sites, and check
> those.
>

I must admit I don't quite understand what the argument here is (sorry),
but in any case let me point out this:

If even just a *single* high-value site that you, personally, use does
support the SCSV, you'll benefit from the SCSV (provided that you're using
a browser that does a downgrade dance for compatibility with other servers
and sends the SCSV in downgraded Client Hello messages).

Bodo

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 21 Jan 2015 16:45:31 -0800

> Rubber-Stamping the fallback-scsv hack onto the standards track is

I apologize if this has been discussed before (I have about 1400
unread TLS mailing list messages in my queue), but it seems that
a simpler SCSV or extension could just ask the server to echo its
highest supported version:

     ClientHello w/SCSV    ----->
                           <-----    ServerHello w/version extension

Servers wouldn't have to change any logic or close the connection,
the client would make that call.

Mike

---

From: [email-masked] (Martin Rex)
Date: Thu, 22 Jan 2015 07:11:32 +0100 (CET)

> and sends the SCSV in downgraded Client Hello messages).

I've been looking long and hard, but I'm having difficulties
to see a noticable benefit.   OK, a Poodle demonstration of the CBC
padding weakness will no longer work, and maybe a minor fraction of
the script kiddies will spend their time on other activities.

But for the security of the typical web browser, and I'm not currently
aware of any TLS clients other than web browsers that are doing
downgrade dances.  I'm not seeing a measurable benefit from fallback-scsv.

The real problem, that is a prerequisite to Browser attacks like Poodle
(and BEAST and CRIME predecessors) are

   1) a browsers aggressive willingness to execute *ANYTHING* from
      *ANYWHERE* that looks like active content

   2) provisioning of a cross-site-request-forgery (CSRF) facility,
      where the browser will share/insert the user's authentication
      credentials into *EVERY* GET/POST, irrespective where that
      request originates

For a number of sites, being able to perform crafted GETs and POSTs,
for which the browser will automatically provide/perform the
authentication on behalf of the user, will provide ample room
to cause trouble or damage to the end user.  No existing nor future TLS
protocol version and no existing or future TLS cipher suites
can prevent exploitation of such a Browser (mis)feature.

A single Poodle attack on a browser requires the attacker to be on-path
between browser and server, for which the attacker intends to recover the
users basic authentication credentials or SSL session cookie through
repeated guessing -- and to perform active attacks on thousands of
network connections between browser and server, creating thousands
of otherwise quite rare TLS MAC errors in the server's logfile.

When (ab)using the browsers CSRF facility directly, rather than for noisy
and boring Poodle, it will be sufficient to piggy-back one single arbitrary
page that the user's browsers happens to load (or can be lured to load).
When properly done, the attack will be indistinguishable from a genuine
action of the user for the server, and be noticable for the user only
by forensic inspection.  The browser's CSRF facility may even
allow (ab)use of TLS PSK credentials or TLS client certificates,
a form of credential that can not be attacked/recovered by Poodle.

Attacking an *arbitrary* page is still quite trivial depressingly often,
because so many sites force their users to use plaintext HTTP for at
least parts of their stuff -- effectively throwing all security
overboard each time.

lots of online shops.  a popular auction site.

Today I visited the site of a popular video/phone/chat software.
Even when accessing their site via https: the "Sign in" and "Join us"
URLs (at the upper right of all pages of the site) will _force_ the
user through plaintext-HTTP.   The link to their Download section
is https, but in the download section, the actual green software
download button, again, forces you through plaintext-HTTP -- OUCH!

-Martin

---

From: Michael Clark <[email-masked]>
Date: Thu, 22 Jan 2015 16:40:35 +0800

Hi All,

* Very interesting stats. Are they independently verifiable?

* Very interesting facts on the specification ambiguity regards
  ClientHello "message Layer" version and "record layer" version
  SCSV might not have existed had implementations followed E.1.

- Agree with not adding SCSV to the proposed standard assuming
  the accuracy of these stats (even if I wrote SCSV myself I would
  stand corrected).

+ SCSV served a purpose of a mitigation while clients downgraded
  due to version upgrade intolerant servers. It may have served its
  purpose. Don't downgrade and there is no attack vector (1.6% servers).

Recommendations:

= Based on these numbers, it appears that clients MUST avoid downgrade
  when sending their highest ClientHello "Message Layer" TLS minor
  version number; given the TLS 1.3 ClientHello "Message Layer" minor
  version upgrade intolerance is 1.6% (for the Alexia top 1 million).

= ClientHello "Message Layer" TLS minor *version upgrade tolerance*
  intrinsically mitigates downgrade attacks.

= Appendix E.1 should state that servers MUST tolerate higher
  ClientHello "Message Layer" TLS minor protocol versions rather
  than recommend it and recommends the lower bound on the record
  layer TLS minor protocol version. It states:

  "No single value will
   guarantee interoperability with all old servers, but this is a
   complex topic beyond the scope of this document."

Reasoning:

= Based on these findings, we could safely tighten the spec:

   During non resumed handshake the ClientHello record protocol
   version MUST indicate the clients minimum supported TLS version
   and the ClientHello message layer TLS version must indicate the
   maximum supported TLS version. The ClientHello TLS version MUST
   be greater than or equal to the record protocol TLS version.

= TLSv1.3 implementations could remove SSLv3.0 support such that
  the minimum TLS record layer version for TLS 1.3 is 1.0 { 3, 1 }
  instead of { 3, 0 } which is mentioned in the Appendix as a
  "typical value" and the maximum "message layer" version a server
  accepts is specified as { 3, XX }. A TLSv1.2 client could send
  { 3, 1 } { 3, 3 } and a TLSv1.3 client would send { 3, 1 } { 3, 4 }
  in its ClientHello to support TLSv1.0 through TLSv1.2/3. This accords
  with protocol major/minor best practices for binary changes and
  backwards compatibility. i.e. no binary incompatible changes in minor
  versions. Just raise non-compliance with Appendix E.1 as a bug.

= Ambiguity only exists for ClientHello.

= ClientHello Message Layer TLS version tolerance; no upper bound
  for the *message layer* TLS "minor" protocol version) is protective.
  { 3, XX } or even { 4, 0 } for TLSv1.3 as I reason below.

= ClientHello Record Layer TLS version intolerance; strict lower bound
  for the *record layer* TLS "minor" protocol version) is protective.
  Use { 3, 1 } to deprecate SSLv3.0, which is now past its use by date
  (from an evolutionary perspective).

Issues (beyond the scope of TLS spec according to Appendix E.1):

= The issue is there is an (implicit and variable) *range* of
  acceptable versions; based on different policy of various clients
  and servers; caused by recommendations for deprecation of earlier
  protocol versions; most importantly SSLv3.0 (predictable IV); and
  the timing of roll outs of protocol upgrades to clients and servers.
  The deprecation, or lower bound needs to be made explicit.

= The notes in Appendix E.1 considers a "backwards compatibility"
  mechanism but do not make explicit the "deprecation" mechanism.

= Forward and Backwards compatibility (backwards binary compatibility
  through careful structure addition, unknown extension tolerance,
  minor version upgrade tolerance and unknown cipher suite tolerance
  should be preserved within "minor" protocol versions. This matches
  best practices for protocol discipline. Reconnecting with a lower
  version after alerts should only be attempted for deprecated
  protocols (SSLv3.0) after going through a "proceed with caution"
  screen. e.g. new minimum at the record layer of { 3, 1 }. You
  then only have "user agreement" to downgrade, or based on stats
  you can make { 3, 1 } the new minimum.

= It raises the issue that the TLSv1.3 spec specifies major version
  tolerance for the "message layer" ClientHello e.g. { 3, 1 } { 4, 0 }
  for at least "one major version" to prevent future downgrade attacks
  with a new major protocol version upgrade. This would build into
  TLSv1.3 the provision to introduce a new major version without
  being attacked.

= This would mean that a new major protocol version would need to
  define an embedding for its ClientHello within the record protocol
  of the previous major version (verbose legacy) as well as defining
  its new ClientHello format. A putative TLSx { 4, 0 } could send a
  verbose ClientHello "message layer" { 3, 1 } { 4, 0 } containing a
  legacy "combinatorial explosion" of cipher suites and already
  widely supported curve point formats, etc, SNI ext and optimistically
  embed its { 4, 0 } Hello data in an extension then learn/cache the
  version of servers and subsequently sends concatenated new Hellos
  { 4, 0 } { 4, 0 } for fast starts using a lean "profiles" system
  with profiles and pre-negotiated cryptographic primitives. Servers
  tolerant of ClientHello message layer major version upgrade is also
  protective given a mandate that major version upgrades define an
  embedding of their ClientHello (yucky verbose cipher suites) for
  the previous major protocol version. Doable.

= Yes. AEAD-AES-GCM is the cipher suite you would keep to maintain a
  bridge to TLSv1.2. Most of the other 304? are not AEAD.

= Do you want to specify more cipher suites at present? I argue below
  that based on verify_data that it may be a bad idea. See below
  TL;DR --- related but forward looking --- and the missing
  specification of verify_data_length in all cipher suites including GCM

On 21/1/15 5:16 pm, Yoav Nir wrote:
> Thanks
> 
> In that case, I think my implementation would fail with (1.3,1.3). Since
> I can’t know what changes TLS 1.3 made to the record layer, I can’t be
> sure that I understand what I’m parsing. Perhaps those bytes that I
> thought were the ClientHello are actually some new fields that were
> added to the record header.

Reasoning aloud.

You can if we know we are adhering to strict minor protocol version
binary compatibility rules. i.e. reasoned structure addition and
length prefixes, unknown extension tolerance and higher Hello version
tolerance. The "rule of thumb" is to only break binary compatibility
on major version changes.

If you are a 1.2 server and you receive a 1.3 ClientHello
{ 3, 1 } { 3, 4} and reply with a { 3, 3 }, { 3, 3 } ServerHello
then tolerant behavior (tolerance to higher ClientHello minor version
is protective) and is acting on the presumption that the client accepts
the older version specified in the record layer as you mention.
Likewise client intolerance to lower than ClientHello record layer
TLS version in ServerHello is also protective.

This accords with Appendix E.1 and it makes sense to avoid round trips,
and this intrinsically mitigates the downgrade attack vector. An alert
due to version upgrade intolerance in fact *opens* the attack vector.

If you are a 1.3 server, your server knows as with other TLS versions
that the ClientHello and ServerHello format will be designed with
"forwards compatibility" so you would not have any problem replying,
with the version you support, either 1.3 (after it is specified) or
1.0, 1.1 or 1.2 in response to a 1.3 ClientHello (Appendix E.1) with
1.0 at the record layer. Sure, if you reply with 1.3 now then a client
will abort. The version tolerance as per Appendix E.1 mitigates
downgrade tampering, as intolerance (or non compliant implementations)
lets your security be downgraded, by the "work-around" reconnect.
The implementations that are not version tolerant are not compliant
and stopping "work-around" reconnect improves things.

There is also TLS extension tolerance and cipher suite tolerance
(which SCSV relies on) to consider.

    https://bugzilla.mozilla.org/show_bug.cgi?id=689814

The core issue is Appendix E does not make explicit a protocol version
deprecation mechanism. It seems TLSv1.3 { 3, 4 } should specify a
lower bound of { 3, 1 } for the record layer TLS version in the
ClientHello as they are the same major version (in reality).
The fact that SSLv3.0 has partial record layer binary compatibility
is a red herring. We should notionally subtract { 2, 1 }.
SSLv3.0 is past the used by date.

Thought experiment.

The crux is the server lacks the information (through ambiguity of
specification) on the "range" of older versions supported by the
client. The reality is as Yoav mentions is the record layer has become
an adhoc signalling mechanism of the lower bound. Without this knowledge
we might invent an extension for the ClientHello to signal a list of
earlier versions in a "Compatible Versions Advisory Extension"
to signal to older servers that the client also accepts these.
This would provide for deprecation once servers are *upgraded* with
the "Compatible Versions Advisory Extension" extension. However the
problem is not with servers that upgrade. It's the 1.6% that have not
been upgraded. So yes. This is also equally as redundant as SCSV if
the record layer TLS version in the ClientHello is the lower bound.
The real issue is the client has to stop talking SSLv3.0.
i.e. There is no point to upgrade a server with this mechanism, rather
you need to start blocking the 1.6% servers that are not upgrading,
or at least prompt the user before downgrading a connection. i.e.
The proceed with caution screen. Simply becoming intolerant of
"message layer" version intolerance makes you no longer susceptible
to downgrade attacks.

This or any other advisory signalling mechanism becomes redundant
assuming downgrades should never happen within the same minor protocol
version and that the ClientHello record layer lower bound is { 3, 1 }
and the message layer ClientHello version upper bound is say { 3, 99 }.

End thought experiment.

Conclusion: Ipso facto, SCSV is redundant if servers implement version
tolerance as per the spec and clients don't try downgraded connections.

That said, SCSV was a valuable temporary fix to prevent downgrade
workarounds while lots of SSLv3.0 and/or version intolerant servers
were still in the wild. According to stats, this is no longer the case.

Based on those stats, if browsers adopted a common strategy of not
attempting to re-connect at lower TLS versions than what they signal
at the record layer, and servers followed Appendix E.1 version
tolerance, we would gain downgrade tamper resistance without any
signalling mechanism, and servers that were version intolerant would
naturally end up being upgraded when enough new clients adopted
Appendix E.1 guidelines. The small fraction of servers will get
upgraded if they have any customers.

If the recalcitrant servers are doing eCommerce, then we would be
doing them a public service. Give them 90 days and cut the cord on
SSLv3.0. They can always put a proxy in front :-D

> If the record layer version exceeds what the server supports, I think it
> wouldn’t be prudent to reply with anything but an alert. Many
> implementations treated the record layer version in the ClientHello as a
> minimum version number. Yes, I know this goes against a MUST requirement
> in appendix E.1 or RFC 5246, but as that appendix says, this is behavior
> that is often implemented.

I agree. If clients become intolerant of implementations that are not
version tolerant (compliant with the spec) then there is no need to
attempt to re-connect, and thus become vulnerable to downgrade attacks.
The nuance that is missing is clear text on guidance for the constraints
on the "record layer" and "message layer" TLS versions for the
ClientHello. Thanks for making it clear. I wasn't aware of the
ClientHello version ambiguity.

TL;DR --- related but forward looking ---

SNI is being sent to many servers that don't support the SNI extension
but most servers are tolerant of unknown extensions? I am now curious
about extension tolerance.

1). Q. Is there a similar data for extension intolerance?
2). Q. Is extension tolerance on the flip-side an attack vector?
       i.e. appending unknown extensions to the handshake to forge
       the 96-bits of verify_data?

There is a related threat analysis of extension tolerance forgery
potential; version and extension tolerance seem to be the status.
I found anecdotal mention from Ivan Ristic related to a small number
of servers that are SNI extension intolerance. Extension tolerance
however provides verify_data forgery potential. The question was
whether it is a credible threat. The answer was not right now.
Perhaps not this year, but certainly in the time-frame of TLSv1.3.

3). Q. From TLSv1.2 rfc5246, cipher suites can specify a longer
verify_data. Do any of them do so? neither rfc4492 (ECC) or rfc5289
(AES-GCM) mention verify_data length.

  In previous versions of TLS, the verify_data was always 12 octets
      long.  In the current version of TLS, it depends on the cipher
      suite.  Any cipher suite which does not explicitly specify
      verify_data_length has a verify_data_length equal to 12.  This
      includes all existing cipher suites.  Note that this
      representation has the same encoding as with previous versions.
      Future cipher suites MAY specify other lengths but such length
      MUST be at least 12 bytes.

As discussed earlier, using specially crafted extension data and
exploiting extension tolerance to forge verify_data is bounded by the
probability of a verify_data collision with a 16K message (2^14) which
with 96-bits verify_data (2^96). This is tractable at quantum scale (in
the TLSv1.3 timeframe) but not a present credible thread (unless there
is information to the contrary). The probability is (if my math is
correct?):

    handshakes * (2^14) / (2^96)
    handshakes / (2^82)

This is not a credible threat right at this moment, but I believe it
should be addressed in TLSv1.3. i.e. 96-bits doesn't offer enough
handshake forgery protection for the next 10 years.

4). Q. Is there consideration in TLSv1.3 to decouple verify data from
the cipher spec (given it is in practice decoupled) and extend it?

>From master https://github.com/tlswg/tls13-spec/draft-ietf-tls-tls13.md

  In previous versions of TLS, the verify_data was always 12 octets
     long. In the current version of TLS, it depends on the cipher
     suite. Any cipher suite which does not explicitly specify
     verify_data_length has a verify_data_length equal to 12. This
     includes all existing cipher suites. Note that this
     representation has the same encoding as with previous versions.
     Future cipher suites MAY specify other lengths but such length
     MUST be at least 12 bytes.

Based on the current wording, all cipher suites would need to be changed
to increase the handshake integrity, which gives one pause
to consider wiping them in TLSv1.3, or only offering the AES_GCM
subset with different operational semantics (to allow for backwards
compatibility) with respect to verify_data if TLSv1.3 is negotiated,
and then add new cryptographic primitives through extensions as is
already done with ECC curve points, etc or profiles. I know a lot
about combinatorial explosions. TLS already has one. What about
only having three of four cipher suites?

  TLSX_XKEX_XVERIFY_XAEAD = { ?, ? }

  "Supported Elliptic Curves Extension" {}
  "Supported Point Formats Extension" {}
  "Supported Key Exchange Mechanism Extension" {}
  "Supported Certificate Verification Algorithms Extension" : { }
  "Supported Authenticated Encryption Algorithms Extension" : { }
  "Supported Signature Algorithms Extension" : { }

or

  TLSX_PSK_XPROFILE = { ?, ? }
  TLSX_ECDHE_RSA_XPROFILE = { ?, ? }
  TLSX_ECDHE_ECDSA_XPROFILE = { ?, ? }
  TLSX_ECDHE_EDDSA_XPROFILE = { ?, ? }

  "Supported Profiles Extension" : { ssf112_embedded_r1 }

This gives you a TLSv1.x embedding with extensions and a mechanism for
a short short negotiation with a newer TLS server that uses
prenegotiated labels and makes these now widespread primitives
part of the new mandate.

This approach was alluded I think by Watson and or others (apologies
if I am wrongly attributing this). I don't see why within TLSvx.x,
that cipher suites could be eliminated, and servers could advertise
"cryptographic primitives" in extensions, as an embedding in TLS1.x
and/or use a concatenated negotiation for profiles where all of the
primitives have been pre-negotiated against specified profiles.
The extension embedding relies on protection for "verify_data".
i.e. solving the verify_data forgery attack vector, but most
implementations are already extension tolerant. It is bounded.
Sending profile labels to indicate support of a predefined table of
primitives just requires the Server to tell you which primitives it
selected from the list it knows you support.

Using more extensions pushes onto the handshake sign, encrypt, verify
mechanism. i.e. so that the minimum RSA, PSK or ECC/EdDSA can protect
must be >= 128-bits of verify_data in a maximum 16K handshake messsage.
With a "profiles" or "labeled" primitives approach servers could
distinguish between embedded and desktop. i.e. servers can prohibit
certain operations. Often an embedded device is used for second factor
auth or recovery for a desktop profile device.

Cipher Suites are not necessarily wrong. They were right when there was
about 32 of them. 304 changes things. Evolution...

Michael.

---

From: Michael Clark <[email-masked]>
Date: Thu, 22 Jan 2015 16:52:19 +0800

>    complex topic beyond the scope of this document."

This is the salient point. If laxity of the spec introduces an
attack vector then it is within the scope of the spec.

It seems { 3, 1 } should be the new minimum and version upgrade
intolerance should be a bug.

If the 1.6% of servers are fixed (assuming this is validated)
then SCSV and downgraded reconnect attempts in general should be
avoided.

~mc

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 22 Jan 2015 10:40:42 +0100

On Thu, 2015-01-22 at 16:40 +0800, Michael Clark wrote:

> [...]

These recommendations are plainly wrong, and worse, they harm
interoperability for no security benefit. Unfortunately for some reason
they somehow got implemented.

1. The version in the record layer, _DOES NOT_ indicate the minimum
version the client supports. It does indicate the format of the record
packet. Having SSL 3.0 is perfectly valid, since the packet format
remained the same.

2. Using it as an indicator of the client's minimum version is wrong as
this field is not protected by the handshake hashes, so it shouldn't
affect any of the decisions taken as part of the handshake.

3. Forbidding SSL 3.0 version from the record layer breaks perfectly
valid clients, which advertise TLS 1.2. These clients can only use a
variant of fallback dance to connect to broken servers which impose
those limits. Please _DON'T CREATE MORE REASONS FOR FALLBACK DANCES_.

regards,
Nikos

---

From: Michael Clark <[email-masked]>
Date: Thu, 22 Jan 2015 18:11:53 +0800

> packet. Having SSL 3.0 is perfectly valid, since the packet format

The spec has wording that alludes to this. In my read.

> affect any of the decisions taken as part of the handshake.

This I was not aware of. That is a hole I can now see (in my reasoning
with respect to handshake tampering). Thanks for pointing this out.

I was under the impression that verify data protects the handshake.

Thanks. This should be addressed.

> those limits. Please _DON'T CREATE MORE REASONS FOR FALLBACK DANCES_.

OK. Then an extension to indicate supported versions would in fact be an
improvement as it would be protected by verify_data.

I'm not in supported of downgrade dancing. I was completely unaware that
the entire handshake is not hashed.

Thanks.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 22 Jan 2015 11:24:49 +0100

> improvement as it would be protected by verify_data.

Some time ago, I had proposed a method for clients to advertise the list
of protocols they support, for the same reason. To allow the server to
fallback to their preferred protocol:
https://tools.ietf.org/html/draft-mavrogiannopoulos-tls-more-extensions-00#section-4

regards,
Nikos

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 22 Jan 2015 05:30:12 -0500

On Thu, Jan 22, 2015 at 4:40 AM, Nikos Mavrogiannopoulos
<[email-masked]> wrote:
> ...
If its not protected, then its wrong - period. It lacks semantic
authentication. If its not going to be protected, then it should not
be used. Since it should not be used, it should be removed altogether.

Wagner and Schenier told us that back in the 1990s.
https://www.schneier.com/paper-ssl.html.

---

From: Michael Clark <[email-masked]>
Date: Thu, 22 Jan 2015 18:37:24 +0800

> the entire handshake is not hashed.

I guess this is the crux of the matter. I was trying to figure this out
from the spec. A future version needs to state that *all* handshake data
is authenticated. My original suspicion.

My read of the stats was that < TLS1.0 { 3, 1 } represents 1.6%

Clearly the version *range* indication as per Appendix E.1 i.e. the
actual point of my mail, should be hashed as it does then allow for
handshake tampering. I made a note of my *false* assumption, that
the handshake is hashed (and required pre-image).

The spec does say:

 TLS clients that wish to negotiate with older servers MAY send any
   value {03,XX} as the record layer version number.  Typical values
   would be {03,00}, the lowest version number supported by the client,
   and the value of ClientHello.client_version.  No single value will
   guarantee interoperability with all old servers, but this is a
   complex topic beyond the scope of this document.

SSLv3.0 is advised against everywhere. I guess it's living with a wart
of using a record protocol version that you don't support given the
minimum most are willing to negotiate these days is TLSv1.0 { 3, 1 }.

Anyway that fact that the handshake is *not* completely hashed is
perhaps the most important issue to address given there is no secure
way to indicate a range of supported versions. i.e. SSLv3.0 deprecation.

If { 3, 0 } has to be the record protocol version in an unauthenticated
layer then so be it. It only gives more weight to the need for a
mechanism to indicate "Supported Versions" in an extension that is part
of the hash. i.e. the Thought Experiment that I discounted based on the
false assumption of the forgery proof of handshake messages.

Clearly TLS needs to authenticate the *whole* handshake and signal
minimum version securely and have no fallback to insecure versions if
this minimum version can be tampered with. Clearly the minimum version
needs to be in the verify_data hash (somehow as an extension).

TLS 1.0 should be a minimum. People need to upgrade. You can't keep
backwards compatibility and security at the same time when SSLv3.0
is insecure.

---

From: Michael Clark <[email-masked]>
Date: Thu, 22 Jan 2015 18:40:17 +0800

> https://tools.ietf.org/html/draft-mavrogiannopoulos-tls-more-extensions-00#section-4

Good idea. Thanks I understand now. More logical than SCSV to have the
minimum version in the handshake hash.

---

From: Michael Clark <[email-masked]>
Date: Thu, 22 Jan 2015 19:06:31 +0800

> minimum version in the handshake hash.

I would audit the handshake hash in an open implementation to be certain
and (based on new information in *my head* at least):

a) support Nikos proposal to advertise the list of protocols as
   a better short/medium term mitigation in preference to SCSV as
   this is the real issue. We could easily make the SCSV mistake if
   we were unaware of the handshake hash construction. I did.

b) TLSv1.3 in the medium to long should authenticate the entire
   handshake. There shouldn't be any unauthenticated bytes that
   can be tampered with. This would be in concert with reviewing
   verify_data_length and the 12 octet and the wording that defers
   to the cipher suite to increase it, but then they don't.
   TLSv1.3 could address this in a more permanent way.

So the thought experiment still stands, rather we made a false
assumption on authentication of the handshake. Some bytes can
be tampered with.

I will be reading (Open|Boring)SSL code to make sure. The reality
is however that when I reasoned from the spec, I saw hash(handshake)
but I did not see the wording that specified whether this is
the content of the handshake record or the whole record. I will look
for the wording in the spec. If it is there and specifies only the
content then it is a little mistake (for some value of little).

The reasoning in my prior email still stands despite the *pivot*
on the knowledge of the handshake hash construction.

I will read code...

---

From: Hubert Kario <[email-masked]>
Date: Thu, 22 Jan 2015 12:07:08 +0100

>                            <-----    ServerHello w/version extension

that's not allowed by the RFC's, the server can send back only the extension 
id's client has sent

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Henrik Grubbström <[email-masked]>
Date: Thu, 22 Jan 2015 15:31:25 +0100

On Wed, Jan 21, 2015 at 5:01 AM, Xiaoyin Liu <[email-masked]> wrote:
> Hi,
>
> I just finished a scan of Alexa top 1 million websites to test for TLS
> version intolerance. I hope this information can be useful in the discussion
> of downgrade SCSV.

Great work!

[...]
> The total number of TLS enabled sites is 426,419. TLS 1.3 intolerant sites
> (7 and 8) are about 1.6%. TLS 1.2 intolerant sites are about 0.1%. Also it
> shows setting a lower record layer version does improve compatibility a lot.
> An example is https://paypal.com is intolerant to (TLS 1.3, TLS 1.3) but is
> tolerant to (TLS 1.0, TLS 1.3). Please note that I did not validate
> certificates nor check the integrity of handshakes. I closed the connection
> immediately after receiving ServerHello.

Probably not an issue yet, but note that servers actually implementing
TLS 1.3 as currently drafted will for a TLS 1.3 or later ClientHello:

  * Wait for a ClientKeyShare packet.

  * May reply with a HelloRetryRequest instead of a ServerHello.

  * Fail if the ClientHello doesn't contain AEAD suites or sufficient
extensions.

Any of the above may skew your statistics to have more failures.

/grubba

-- 
Henrik Grubbström                                       [email-masked]
Roxen Internet Software AB                              [email-masked]

---

From: Henrik Grubbström <[email-masked]>
Date: Thu, 22 Jan 2015 15:39:52 +0100

> that's not allowed by the RFC's, the server can send back only the extension

Not quite; cf RFC 5746 (Renegotiation Indication Extension), where the
client may use the SCSV TLS_EMPTY_RENEGOTIATION_INFO_SCSV instead of
the renegotiation_info extension in its ClientHello, but the server
will reply with the renegotiation_info extension.

/grubba

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 22 Jan 2015 17:47:17 +0100

Martin Rex <[email-masked]>:

[...]
[...]

> page that the user's browsers happens to load (or can be lured to load).

Yes and no.  While it is certainly true that this is an unfortunate problem
with the protocols that browsers use today, the kind of cross-site request
forgery that you describe is commonly prevented by adding appropriate
additional verification tokens (that the attacker couldn't obtain or
predict or otherwise caused to be added) into legitimate requests,
supplementing the credentials (such as HTTP basic authentication passwords
or HTTP cookies) that would also go into the requests caused by the
attacker.  (Often enough, of course, the need for such protection is
missed, or tokens are added but not verified, etc.)

With such protection in place, browsers attacks like BEAST and POODLE can
undermine the security you'd otherwise achieve.  So in the reality of the
web today, browser attacks like BEAST and POODLE *are* relevant if they are
possible.  You might wish that this wasn't the case, but there's certainly
no near-term resolution of the basic CSRF issues in sight.

[As an aside, note that the "cross-site" jump may be only from
http://www.example.com/foo to https://www.example.com/bar if we assume that
the attacker controls the network, so it's a "cross--web-origin" attack
rather than a "cross-site" attack.]

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 22 Jan 2015 17:59:14 +0100

Michael Clark <[email-masked]>:

>   purpose. Don't downgrade and there is no attack vector

This is certainly true, but note that all the major browsers (including the
current release of Mozilla Firefox) still *do* downgrade. Firefox has plans
to disable the downgrade dance by default, but there'll still be a user
setting for this, and various users may (have to) set this.  Not
downgrading isn't entirely science fiction any more, but it ain't over
until the fat lady sings.

Not having to do downgrade retries is the right goal, but when we have
achieved that, having the SCSV logic dormant in servers is really a minor
low-complexity addition to the protocol that won't do any harm, and may (or
may not) turn out to be useful again in the future.

Bodo

---

From: Dave Garrett <[email-masked]>
Date: Thu, 22 Jan 2015 19:18:56 -0500

[...]
> SSLv3.0 is past the used by date.

I have PRs to deal with this area in TLS 1.3 still pending a decision. The 
current version is the consensus from the previous discussion on the topic.

https://github.com/tlswg/tls13-spec/pull/105
https://github.com/tlswg/tls13-spec/pull/107

The changes are to prohibit SSL negotiation, drop SSL2 hello format 
documentation, freeze record layer hello version to 3.1, as well as other 
editorial improvements.

I haven't heard back from ekr in a couple weeks.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Jan 2015 16:23:31 -0800

Sorry I've been AWOL here. I'll try to take a look at it this weekend.

If the chairs wanted to review these PRs and confirm that they match the
WG consensus, that would save me some time.

-Ekr

---

From: Michael Clark <[email-masked]>
Date: Fri, 23 Jan 2015 10:33:16 +0800

On 23/1/15 12:59 am, Bodo Moeller wrote:
> Michael Clark <[email-masked]
> <mailto:[email-masked]>>:
>  
>
> This is certainly true, but note that all the major browsers
> (including the current release of Mozilla Firefox) still *do*
> downgrade. Firefox has plans to disable the downgrade dance by
> default, but there'll still be a user setting for this, and various
> users may (have to) set this.  Not downgrading isn't entirely science
> fiction any more, but it ain't over until the fat lady sings.
>
> achieved that, having the SCSV logic dormant in servers is really a
> minor low-complexity addition to the protocol that won't do any harm,
> and may (or may not) turn out to be useful again in the future.

I agree with you. Ideally a standards track draft should not codify a
workaround. People make mistakes. I'm not suggesting SCSV is a mistake.
It appears to be a workaround. We're humans.

If we have the ears (or eyes) of the standards group then I think
working towards downgrade avoidance and adding an extension to indicate
acceptable versions is a cleaner long term solution. If a server replies
with the version it uses on the record layer in an extension and we know
this is signed in verify_data then this serves an almost equivalent
purpose of SCSV but is much more explicit and offers a deprecation
mechanism that will be useful in the future. IMHO a cleaner mitigation.
Sure I understand the context that mitigation often needs to be deployed
in a hurry so I am sure everyone has consideration of that.

However this is my thinking, which was modified by the comments of others.

A).

    1). Codify use of a "Supported TLS Versions Extension" with either a
strong recommendation for a minimum of TLSv1.0 { 3, 1 } to deprecate SSLv3.0
        * Advisory to recommend the record layer ClientHello version be
fixed to the lower bound { 3, 0 } ; which there seems to be some
consensus for
        * In the case where the extension is echoed. i.e. supported, the
record layer version is echoed by the server and signed in the handshake.
        * This is TLSv1.0 through TLSv1.2 compatible via extension
tolerance. i.e. All TLS implementations can benefit from it.

And in TLSv1.3, where payload can be changed, and extensions can be
mandated, without breaking backwards compatibility, it also makes sense to:

B).

    1). MUST Codify use of a "Supported TLS Versions Extension" with
either a strong recommendation or MUST for a minimum of TLSv1.0 { 3, 1 }
to deprecate SSLv3.0
        * In the case where the extension is echoed. i.e. the lower
bound is signed in the handshake.
        * This provides administrators with a clear indication of
supported versions and the ability to set their lower bound
        * This is TLSv1.0 through TLSv1.2 compatible via extension
tolerance.
        * Complete deprecation of SSLv3.0 would like be achieved by the
time TLSv1.3 is in the wild.

    2). MUST tighten the wording with respect to the ClientHello record
layer and message layer versions
        * Fix the record layer ClientHello version to the lower bound {
3, 0 } ; which there seems to be some consensus for
        * This is TLSv1.0 through TLSv1.2 compatible via extension
tolerance.

    3). MUST Extend the TLSv1.3 verify_data size from 12 octets to >=16
octets
        * In the TLSv1.3 time frame we are approaching a point where (
handshakes * ( 2^12) / ( 2^96 ) ) becomes a potentially exploitable weakness
        * The wording that defers to the cipher suite for
verify_data_length should be changed.

    4). MUST Include the entire handshake record layer rather than
content in the veryify_data hash
        * While this is a duplication of the mitigation in A.1, it is in
fact the real fix and the "Supported TLS Versions Extension" becomes an
indicator
        * "Supported TLS Versions Extension" would echoed to indicate
the lower bound and { 3, 0 } would be fixed at record layer.
        * Reasoning: The fact a mitigation is deployed (for backwards
compatibility) should not prevent the standard from deploying the real fix.
        * TLSv1.3 has an opportunity to change content layer semantics
of the handshake hash without breaking backwards compatibility
        * It needs to be tight { 3, 1} lower bound via extension and at
the same time loose { 3, 0 } in record layer for inclusive backwards and
forwards compatibility.

This is my analysis (plastic based on new information discovery); and I
realize my MUSTs may be different from the standards track or chair.

I still need to read the handshake hash code in one of the open
implementations. i.e. to prove at least to myself the core issue is
Hash(handshake_messages) vs Hash(handshake_records).

I read Hash(handshake_messages) which is a little ambiguous or a little
mistake. We're all human.

Below is a work in progress patch for 3). and 4).

Cheers,
Michael.

--- a/draft-ietf-tls-tls13.md
+++ b/draft-ietf-tls-tls13.md
@@ -2674,7 +2674,7 @@ Structure of this message:

 verify_data
-:      PRF(hs_master_secret, finished_label, Hash(handshake_messages))
+:      PRF(hs_master_secret, finished_label, Hash(handshake_records))
              [0..verify_data_length-1];
 
 finished_label
@@ -2691,7 +2691,7 @@ Finished computation.
 > In previous versions of TLS, the verify_data was always 12 octets long. In
 the current version of TLS, it depends on the cipher suite. Any cipher suite
 which does not explicitly specify verify_data_length has a verify_data_length
-equal to 12. This includes all existing cipher suites. Note that this
+equal to 16. This includes all existing cipher suites. Note that this
 representation has the same encoding as with previous versions. Future cipher
 suites MAY specify other lengths but such length MUST be at least 12 bytes.

---

From: Michael Clark <[email-masked]>
Date: Fri, 23 Jan 2015 10:40:39 +0800

>  suites MAY specify other lengths but such length MUST be at least 12 bytes.

Extending verify_data obviously pushes on he lower bound of the
protection bits offered by the lowest asymmetric encryption or
pre-shared key size allowed in TLSv1.3 so that should probably be advised.

I'll leave it up to the experts to decide whether my patch is appropriate.

I made a mistake and missed a second occurrence of 12. Here is a re-spin
of the Hash verify_data patch.

 verify_data
 
 finished_label
@@ -2691,9 +2691,9 @@ Finished computation.
 the current version of TLS, it depends on the cipher suite. Any cipher suite
 which does not explicitly specify verify_data_length has a verify_data_length
-equal to 12. This includes all existing cipher suites. Note that this
+equal to 16. This includes all existing cipher suites. Note that this
 representation has the same encoding as with previous versions. Future cipher
-suites MAY specify other lengths but such length MUST be at least 12 bytes.
+suites MAY specify other lengths but such length MUST be at least 16 bytes.
 
 handshake_messages

---

From: Michael Clark <[email-masked]>
Date: Fri, 23 Jan 2015 11:48:15 +0800

On 23/1/15 10:33 am, Michael Clark wrote:
>     1). Codify use of a "Supported TLS Versions Extension" with either
> a strong recommendation for a minimum of TLSv1.0 { 3, 1 } to deprecate
> SSLv3.0
>         * Advisory to recommend the record layer ClientHello version
> be fixed to the lower bound { 3, 0 } ; which there seems to be some
> consensus for
>         * In the case where the extension is echoed. i.e. supported,
> the record layer version is echoed by the server and signed in the
> handshake.
> either a strong recommendation or MUST for a minimum of TLSv1.0 { 3, 1
> } to deprecate SSLv3.0
>         * Complete deprecation of SSLv3.0 would like be achieved by
> the time TLSv1.3 is in the wild.
>
>     2). MUST tighten the wording with respect to the ClientHello
> record layer and message layer versions
>         * Fix the record layer ClientHello version to the lower bound
> { 3, 0 } ; which there seems to be some consensus for

Based on Nikos's comment there needs to be a clarification on the
mitigation track (for TLSv1.0 through TLSv1.2) vs standards track (for
TLSv1.3) on whether the ClientHello "record layer" lower bound is { 3, 0
} or { 3, 1 } and this could potentially be different in TLSv1.3?

From my read, it seems in the time frame of current mitigations (SVSC in
the field or Nikos's "Supported Versions Extension" as a more elegant
forwards and backwards compatible version signalling mechanism). Nikos
was pushing on { 3, 0 } for a current lower bound (at the record layer)
for TLSv1.0 through TLSv1.2 as { 3, 1 } at the record layer in the
current time-frame *allegedly* causes dancing for a few remaining
upgrade recalcitrant servers. i.e. causing problems in the wild. This
was my read.

So the decision remains whether { 3, 0 } or { 3, 1 } is the "record
layer" lower bound in TLSv1.3; depending on whether mitigation
propagation has made provision for the lower bound to be raised to { 3,
1 } in TLSv1.3. Implementors tried { 3, 1 } and Nikos disagreed and said
this compounded the dancing issue. We proposed a compromise that is both
forwards and backwards compatible and it happened to match something
Nikos had previously proposed. It was to pin { 3, 0 } at the record
layer (essentially making the protocol major version the record layer
version as opposed to TLSv1.0 { 3, 1 } ; this is in fact a record layer
binary compatibility boundary) and listing "Supported TLS Versions
Extension" with { 3, 1 } as a mandatory lower bound (ignored by the
recalcitrant servers). This allows someone unwise to add SSLv3 { 3, 0 }
to "Supported Versions" if they want to support it, but most importantly
lets you signal { 3, 1 } as a signed lower bound in any TLS version (1.0
through 1.3) while showing { 3, 0 } at the record layer for
compatibility. This seems ideal.

I understand this is issue is already mitigated where it is important
(using SVSC or other tightening mechanisms) rather the mechanism is
completely not standardized.

Sorry I am on the temporal track, not the standards track. I'll read
these pull requests:

Thanks for clarifications.

---

From: [email-masked] (Martin Rex)
Date: Fri, 23 Jan 2015 20:31:43 +0100 (CET)

> content in the veryify_data hash

Excuse me while I panic.

There seems to be a complete misunderstanding of the TLS protocol.
The TLS record protocol was *INTENTED* to be independent of the
protocol inside (handshake, appdata, alerts, ccs).

>               [0..verify_data_length-1];

This would be totally wrong.

The TLS record layer protocol was designed to be independent of the
protocols within ON PURPOSE.  In particular, the TLS record protocol
is independent from the protocol within about fragmenting and coalescing
data.

Look at the TLS protocol handshake flowchart:

https://tools.ietf.org/html/rfc2246#page-31

     Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

How the TLS record layer packages the initial response from the server
to the client into TLS records, is entirely up to the TLS record layer
and irrelevant to the computation of handshake message hash and the
TLS finished handshake messages:

                                                     ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                                 ServerHelloDone

i.e. whether each handshake message is packaged into a seperate TLS record,
whether some or all of them are stuffed into one record -- and where
exactly the fragmentation will occur if the maximum TLS plaintext size
(2^14 = 16384 bytes) is reached, is entirely at the discretion of the
TLS record layer, and the TLS handshake protocol engine does not know
or care about it.   This complete independence is likely also the
reason why ChangeCipherSpec is a seperate content type (this forces
flushing of the record layer buffers, because the record layer might
want to coalesce handshake messages, e.g. in the abbreviated handshake
for the server response:

      Client                                                Server

      ClientHello                   -------->
                                                       ServerHello
                                                [ChangeCipherSpec]
                                    <--------             Finished

While this might not be an issue for TLSv1.3 when Renegotiation is dropped
-- completely ignoring additional HelloRequests from the server would
not be possible if the handshake message hash would cover *EVERYTHING*
rather than only the handshake messages that belong to the current
handshake.

-Martin

---

From: Henrik Grubbström <[email-masked]>
Date: Sat, 24 Jan 2015 00:59:19 +0100

[...]
> fixed to the lower bound { 3, 0 } ; which there seems to be some consensus
> for

I don't see a need for this. The current SCSV in the draft seems
sufficient; it indicates to the server that the client believes that
there's some sort of problem with the connection, which not
necessarily is due to the protocol version, but that the client has
downgraded in an attempt to workaround.

Your approach risks cementing the misinterpretation of the record
layer version as the minimum protocol version, which is the cause of
many of the version-related problems.

>     1). MUST Codify use of a "Supported TLS Versions Extension" with either
> a strong recommendation or MUST for a minimum of TLSv1.0 { 3, 1 } to
> deprecate SSLv3.0
>         * In the case where the extension is echoed. i.e. the lower bound is
> signed in the handshake.
>         * This provides administrators with a clear indication of supported
> versions and the ability to set their lower bound
>         * Complete deprecation of SSLv3.0 would like be achieved by the time
> TLSv1.3 is in the wild.

Why mess with the version negotiation? The current protocol works fine
if the parties actually implement the RFCs.

>         * Fix the record layer ClientHello version to the lower bound { 3, 0
> } ; which there seems to be some consensus for

See above.

>         * The wording that defers to the cipher suite for verify_data_length
> should be changed.

This makes some sense.

>     4). MUST Include the entire handshake record layer rather than content
> in the veryify_data hash
>         * "Supported TLS Versions Extension" would echoed to indicate the
> lower bound and { 3, 0 } would be fixed at record layer.
>         * TLSv1.3 has an opportunity to change content layer semantics of
> the handshake hash without breaking backwards compatibility
>         * It needs to be tight { 3, 1} lower bound via extension and at the
> same time loose { 3, 0 } in record layer for inclusive backwards and
> forwards compatibility.

This seems stupid. There are three pieces of extra information
contained at the packet level in this case:

  * The packet content type

     This is handshake for all packets in the handshake (now that CCS
is gone in TLS 1.3), and thus contains no information.

  * The packet fragmentation.

    This is not relevant, since all payloads are concatenated before
the protocol actually looks at them.

  * The packet version number.

    This is not relevant, as either the version is 3.x in all packets
and the packets are accepted, or the version is something else and the
connection will be terminated.

/grubba

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 24 Jan 2015 03:28:43 -0500 (EST)

----- Original Message -----
> layer" lower bound in TLSv1.3;

Note that I was not pushing for anything. I merely presented my interpretation 
of what the record version numbers mean. As it is now, using { 3, 0 } in the
record version causes connections to fail to several web sites (see Martin's mail
on 'ClientHello and record layer version interop'), so it's not much of an
option.

regards,
Nikos