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: Stephen Farrell <[email-masked]>
Date: Sun, 11 Jan 2015 00:48:01 +0000

Hi Nikos,

On 10/01/15 19:31, Nikos Mavrogiannopoulos wrote:
> ----- Original Message -----
>>
>> 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.
>>    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 "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 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 
> text should be informational.
> 
> regards,
> Nikos
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

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:
> On Sun, 2015-01-11 at 00:48 +0000, Stephen Farrell wrote:
>> Hi Nikos,
> It's not up to me to say whether there was consensus for this draft or
> 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
> this has to be on standards track, please provide at least some
> argumentation for it. 

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:-)

> As far as I understand, this fix exists because Microsoft, Google and
> 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: Sat, 10 Jan 2015 14:31:16 -0500 (EST)

----- Original Message -----

imply that the flawed technique is into standards track. I believe that this 

regards,
Nikos

---

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

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. 

regards,
Nikos

---

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: "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: Brian Smith <[email-masked]>
Date: Fri, 16 Jan 2015 13:19:06 -0800

Adam Langley <[email-masked]> wrote:
> On Fri, Jan 16, 2015 at 12:03 PM, Hanno Böck <[email-masked]> wrote:
>> Recently Mozilla has disabled the now so-called protocol dance, which
>> makes adding another workaround (SCSV) pretty much obsolete:
>
> 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: 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:
> 
> On Fri, Jan 16, 2015 at 4:04 PM, Bodo Moeller <[email-masked]> wrote:
>> Hanno Böck <[email-masked]>:
>> 
>>> 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.
>> 
>> Also, quite clearly, we can't yet know how the TLS 1.3 (1.4, 1.5, ...)
>> rollout will work out.
>> 
> The WG should be solving problems that do exist; and not manufactured
> problems or theoretical future problems that don't exist.

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: Adam Langley <[email-masked]>
Date: Fri, 16 Jan 2015 12:10:18 -0800

> (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?)

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

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

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: Bodo Moeller <[email-masked]>
Date: Fri, 16 Jan 2015 22:04:16 +0100

> 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.

Bodo

---

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: Hanno Böck <[email-masked]>
Date: Fri, 16 Jan 2015 21:03:27 +0100

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

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

---

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

Jeff

---

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: Yuhong Bao <[email-masked]>
Date: Fri, 16 Jan 2015 12:05:07 -0800

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

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

---

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: Henrik Grubbström <[email-masked]>
Date: Thu, 22 Jan 2015 15:39:52 +0100

On Thu, Jan 22, 2015 at 12:07 PM, Hubert Kario <[email-masked]> wrote:
> On Wednesday 21 January 2015 16:45:31 Michael D'Errico wrote:
>> Martin Rex wrote:
>> 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
>
> that's not allowed by the RFC's, the server can send back only the extension
> id's client has sent

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

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

---

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

-- 
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: Michael D'Errico <[email-masked]>
Date: Wed, 21 Jan 2015 16:45:31 -0800

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

Mike