Subject: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv

From: Eric Rescorla <[email-masked]>
Date: Thu, 23 Jan 2014 11:06:04 +0100

WG Members,

This message is a call for acceptance of
http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01

As a TLS WG item.

Please provide any comments on this action by Feb 7. Because
there has been only modest discussion of this document, the
chairs ask people who have already spoken in favor or against
this document to re-register their opinion (feel free to just say
+1 or -1 and point back to the archives.)

-Ekr
[For the chairs]

---

From: Ben Laurie <[email-masked]>
Date: Thu, 23 Jan 2014 10:53:47 +0000

> +1 or -1 and point back to the archives.)

I think I haven't said anything before, but nevertheless, +1.

>
> -Ekr
> [For the chairs]
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Adam Langley <[email-masked]>
Date: Thu, 23 Jan 2014 12:57:27 -0500

> +1 or -1 and point back to the archives.)

0 currently because I don't know whether it'll work in the real world.
Ask me again in 10 weeks.

Cheers

AGL

---

From: Kurt Roeckx <[email-masked]>
Date: Thu, 23 Jan 2014 19:07:13 +0100

On Thu, Jan 23, 2014 at 11:06:04AM +0100, Eric Rescorla wrote:
> Please provide any comments on this action by Feb 7.

I think preventing downgrade attacks is important, and as such
I think it's a good idea.  But I have to wonder if it actually
solves anything or not.

I think the document starts from the assumption that there is
someone in the middle that can alter the data, and then let the
client do a downgrade.  What is stopping this attacker from
removing this scsv from the client hello?

Kurt

---

From: Adam Langley <[email-masked]>
Date: Thu, 23 Jan 2014 13:14:18 -0500

> removing this scsv from the client hello?

The Finished messages will detect any manipulation of the handshake.

The key to the draft is that we believe that no servers will be
intolerant to the SCSV, and thus clients can always send it when doing
a fallback.

Cheers

AGL

---

From: Rob Stradling <[email-masked]>
Date: Thu, 23 Jan 2014 20:34:59 +0000

> intolerant to the SCSV, and thus clients can always send it when doing

Adam, I wonder if [1] is relevant here.  Apparently some servers ignore 
the most significant byte of each cipher suite value sent by the client.

Those servers would presumably interpret...
   TLS_FALLBACK_SCSV          {0x56, 0x00}
...as...
   TLS_NULL_WITH_NULL_NULL    {0x00, 0x00}

I guess the chances of a server actually having TLS_NULL_WITH_NULL_NULL 
enabled and choosing to select it above all other mutually supported 
ciphers is pretty remote.  But nonetheless, is there any reason why 
TLS_FALLBACK_SCSV couldn't have a value of, say, {0x00, 0xFE} ?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=946147

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Adam Langley <[email-masked]>
Date: Thu, 23 Jan 2014 15:43:28 -0500

> enabled and choosing to select it above all other mutually supported ciphers
> is pretty remote.  But nonetheless, is there any reason why

Has anything ever implemented TLS_NULL_WITH_NULL_NULL?

Either way, it's not a big problem to change the SCSV value if need
be, although I don't believe that servers mistaking it for
TLS_NULL_WITH_NULL_NULL will be an issue. Additionally, the value is
added at the end of the list in practice.

Cheers

AGL

---

From: Rob Stradling <[email-masked]>
Date: Thu, 23 Jan 2014 21:03:08 +0000

> Has anything ever implemented TLS_NULL_WITH_NULL_NULL?

A quick Google search suggests Yes.

> TLS_NULL_WITH_NULL_NULL will be an issue.

OK.

> Additionally, the value is added at the end of the list in practice.

How about stating this "in practice" behaviour as a MUST or SHOULD 
requirement in the draft?

---

From: Adam Langley <[email-masked]>
Date: Thu, 23 Jan 2014 18:48:19 -0500

> requirement in the draft?

I don't have the XML for this one, but, if Bodo is around, I think
that makes sense.

Cheers

AGL

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 23 Jan 2014 16:59:33 -0800

> I don't have the XML for this one, but, if Bodo is around, I think

TLS_FALLBACK_SCSV would be our second SCSV so far, maybe we'll need
more of these at some point.  Only one of them can be last in the
cipher suite list though, so perhaps they SHOULD be placed after all
of the 'real' cipher suites, but not at a fixed location.

Mike

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Jan 2014 05:46:11 +0100

> Ask me again in 10 weeks.

That's probably a good reason to block publication, but not WG
adoption.  The good thing is that we rarely publish anything in less
than 10 weeks, so you'll have plenty of time to work out if this is
viable in practice.

I'm +1 on adoption.

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 24 Jan 2014 11:05:46 +0100

> Ask me again in 10 weeks.

This isn't a working group Last Call: this is solely about adoption by the
working group, still as a working document.  I agree that we shouldn't aim
to do a Last Call before we have sufficient practical experience with the
specification, but I also want to avoid unnecessary delays (and maybe we
can even get additional practical experience earlier if this is a working
group document).

Kurt Roeckx:

> removing this scsv from the client hello?

Note that the downgrade attack countered by this specification isn't one in
which the attacker modifies the protocol version sent by any of the
legitimate protocol participants: that kind of attack would be stopped by
existing integrity checks, just like removing the SCSV from the Client
Hello would.  Instead, it's about attacks in which the attacker
intentionally lets a first handshake fail in order to get the client to
fall back to an earlier protocol version.

Rob Stradling:

> [...] the value is added at the end of the list in practice.
>

Right, it's a good idea to include a note about this in the specification,
so that client implementations will avoid that potential problem.  However,
I think saying that this particular SCSV should go last would be wrong,
because it unnecessarily and unreasonably restricts other specifications --
this isn't the only SCSV ever, and when sending multiple SCSVs in
ClientHello.cipher_suites, there's no reason why this particular one would
have to go last.  I also don't agree with a "MUST": who knows what other
creative uses ClientHello.cipher_suites may find in the future?

Also note the pitfall here: We don't want any server-side implementations
start to make assumptions about where in the cipher suite list this SCSV
could appear (e.g., only honoring it if it indeed comes last, or only
honoring if it comes after all the "real" cipher suites); so we'll also
have to include a note about this aspect, telling servers to look at every
single item in ClientHello.cipher_suites.

I think that sending SCSVs last is really a corollary of the existing
definition of ClientHello.cipher_suites: These appear in order of
decreasing preference; and an SCSV, by definition, is a cipher suite that
you *don't* want to negotiate (thus, it has lower preference than any real
cipher suite).  So we'll include reminders about this, rather than imposing
new requirements or recommendations.

Adam Langley:

I don't have the XML for this one,

Well, search your email for draft-bmoeller-tls-downgrade-scsv-01.xml :-)
 (Also, the XML source is publicly available for download from the usual
location: http://tools.ietf.org/id/draft-bmoeller-tls-downgrade-scsv-01.xml)
 I'm fine with making the edits, though.

Bodo

---

From: [email-masked] (Martin Rex)
Date: Fri, 24 Jan 2014 19:52:22 +0100 (CET)

> Please provide any comments on this action by Feb 7.

-1

I'm strongly opposed to a scheme whose only purpose in life is
to make TLS handshakes _fail_ based on bogus heuristics by the
wrong communication peer.

-Martin

---

From: Ben Laurie <[email-masked]>
Date: Fri, 24 Jan 2014 18:54:12 +0000

> wrong communication peer.

Which one is the wrong one?

---

From: Kurt Roeckx <[email-masked]>
Date: Fri, 24 Jan 2014 19:58:28 +0100

> wrong communication peer.

I'm not sure I understand you.  Which heuristics do you mean?

The client is telling the server to drop the connection (under
some conditions).  The client is in control of sending this or
not.

Kurt

---

From: [email-masked] (Martin Rex)
Date: Fri, 24 Jan 2014 22:05:34 +0100 (CET)

Ben Laurie wrote:
[ Charset UTF-8 unsupported, converting... ]
> Which one is the wrong one?

The server is definitely the wrong peer to guess whether
the client wants to continue or abort TLS handshake.

-Martin

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 24 Jan 2014 16:26:29 -0500

> the client wants to continue or abort TLS handshake.

In the fallback scenario this SCSV is designed to address, the server
normally has no knowledge that the client's prior attempts to connect
with a reasonable protocol version had failed.

By transmitting this SCSV, the client is saying to the server "just so
you know, i tried a better protocol, but it didn't work -- if you meant
to accept better protocols, then someone is messing with us, please abort."

The server knows whether it believes it can accept better protocols, so
it is in the right position to make this call.   I support adoption of
this draft by the WG.

However, there is a risk that clients will offer the SCSV when other
non-version handshake parameters have changed (e.g. different
ciphersuites were offered, or extensions present in normal connections
that are removed in a fallback "compatibility" mode).  I'm assuming that
clients generally don't want to do multiple layers of fallback, each
time testing removing a particular extension or protocol or version or
ciphersuite; instead, i suspect clients will prefer a "normal mode" and
then a lowest-common-denominator "fallback mode".  In this scenario, it
does seem plausible that the SCSV could trigger a connection abort that
otherwise wouldn't happen.  Is there guidance we can give to server or
client implementors to mitigate this risk?

	--dkg

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 24 Jan 2014 16:43:38 -0500

> By transmitting this SCSV, the client is saying to the server "just so you know, i tried a better protocol, but it didn't work -- if you meant to accept better protocols, then someone is messing with us, please abort."

That's a really nice explanation.

+1

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Geoffrey Keating <[email-masked]>
Date: 24 Jan 2014 15:14:59 -0800

> to accept better protocols, then someone is messing with us, please abort."

Another way to phrase this is that the client is saying "I think you
are an old buggy server.  If you think you are not an old buggy
server, please abort."

The implicit assumption is that there will not be new buggy servers.
I think that's the greatest weakness of this concept.

---

From: [email-masked] (Martin Rex)
Date: Sat, 25 Jan 2014 01:33:55 +0100 (CET)

Salz, Rich wrote:
>
>> By transmitting this SCSV, the client is saying to the server
>> "just so you know, i tried a better protocol, but it didn't work
>> -- if you meant to accept better protocols, then someone is
>> messing with us, please abort."
> 

Nope, that is a bad idea.

We know pretty damn well that there are a number of non-malicious
middle-boxes all over the place on the internet.  They're the
reason that the fallbacks to overcome handshake failures were invented
in the first place.

If you either believe that giving those middle-boxes a hard time
and giving the end users a hard time and forcing the user
to use cleartext HTTP is desirable, then simply disable the
fallback on the client and be done with it -- this will reliably
work with every existing server out there.

But if instead, after having pestered enough of your users/customers,
you figure that you need to enable succeding with TLSv1.0 instead
of forcing the user to switch to cleartext-HTTP, then you will
need yet another level of fallback, to a ClientHello without that
SCSV -- at which point this whole effort turns into a complete waste.

Now on top of that, we do know that TLSv1.2 is cryptographically
weaker than TLSv1.0 and TLSv1.1 because of the weak default SHA1-only
digitally-signed with RSA server certificates.

I would really appreciate if this Working Group would spend more
time on making more TLS handshakes succeed and make strong
algorithms and cipher suites more easily achievable for the
huge installed base of TLS that is under software maintenance.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Sat, 25 Jan 2014 05:24:25 +0100 (CET)

Daniel Kahn Gillmor wrote:
> it is in the right position to make this call.

The _only_ reasonable server response of a TLS server that supports TLSv1.2
to a ClientHello that contains an SCSV which indicates that the client
(a) supports TLSv1.2 and (b) would prefer to use TLSv1.2
is a ServerHello with server_version=TLSv1.2.

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Fri, 24 Jan 2014 21:57:16 -0800

> is a ServerHello with server_version=TLSv1.2.

Let me try to explain, in words as simple as possible, why everything
you have contributed
to this thread is just wrong.

Some servers are version intolerant to TLS 1.0. For this reason, and
not because of middleboxes,
version fallback cannot be stopped.

Some clients only offer SSL 3.0. Until these clients are gone, some
servers will want to serve them.

Right now these servers have a dilemma: they cannot serve the SSL 3.0
population without permitting
clients offering TLS 1.0 or higher to get forced back down to SSL 3.0
by an attacker. There are real, unfixable
problems with SSL 3.0, including the lack of an extension mechanism.
Unfortunately, TLS 1.0, 1.1, and 1.2 rely
on extensions to indicate which curves are supported. It isn't
possible to send at ServerHello back after
seeing a ClientHello with "I tried TLS 1.2, and it didn't work"
because sending back a ServerHello requires
information you don't have, like what curves are supported.

This proposal solves that problem by letting clients indicate if they
are dropping down because of fallback or
because they cannot offer anything better.

Your complaint about signature strength is utterly bogus.
Cleartext HTTP doesn't have a little lock in the address bar with a
green color. Stop pretending that weak crypto is better than no
crypto:
as I've pointed out to you, I can train my mother to not put in her
credit card number without seeing that green lock. I can't train her
to evaluate connection strength.

Why should the existence of middleboxes permit an active attacker to
interfere when I visit my bank website from my home computer?
Why should the fact that some corporate networks want to use TLS
interception prevent websites from choosing not to permit that sort
of attack, while still serving the IE6/XP clients? Why should we let
the lowest common denominator drive the security of all our
connections,
even when better options are supported by both sides?
Sincerely,
Watson

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

---

From: [email-masked] (Martin Rex)
Date: Sat, 25 Jan 2014 07:48:34 +0100 (CET)

Watson Ladd wrote:
> Martin Rex <[email-masked]> wrote:
>>
> not because of middleboxes, version fallback cannot be stopped.

Servers intolerant to TLSv1.0 have become close to non-existant.

Servers intolerant to TLSv1.1 and TLSv1.2, on the other hand,
are too many to ignore.

The fiscal authority of portugal newly commissioned in July 2013 a mandatory
(for Portugal businesses) web service that requires TLS client certs
(issued by the authority) and which will drop the connection when
receiving a TLS ClientHello with TLSv1.1 or TLSv1.2 in it.
Handshake succeeds with TLSv1.0 or SSLv3.

> servers will want to serve them.

No problem.

> population without permitting clients offering TLS 1.0 or higher to
> get forced back down to SSL 3.0 by an attacker.  There are real,
> unfixable problems with SSL 3.0, including the lack of an extension
> mechanism.

You can not force down the server, only the client.

SSLv3 has the EXACT SAME extension mechanism as TLS.

  http://tools.ietf.org/html/rfc6101#page-27

It's true that this was retrofitted into the SSLv3 protocol late 1996,
after the initial SSLv3 spec and initial implementations of SSLv3 had
been shipped.  And it's also true that Netscape and the TLS WG failed
badly in making the 18-Nov-1996 SSLv3 spec easily accessible, which
is listed in the references of TLSv1.0 [RFC2246].

  http://tools.ietf.org/html/rfc2246#page-77

Curiously, there are not just old, extensions-intolerant SSLv3 servers,
there are also extensions-intolerant TLSv1.0 servers.

> information you don't have, like what curves are supported.

You're misled.  It is perfectly possible to send back a TLSv1.2 ServerHello.
If the client doesn't support ECDHE, it will not include any ECC cipher
suites anyway.  The semantics of the presence of TLS cipher suites, but
no accompanying ECC TLS extension is also well-defined in the TLS ECC
spec (rfc4492).

> are dropping down because of fallback or because they cannot offer
> anything better.

This proposal does not solve anything at all.
When Server sends back a ServerHello with server_version=TLSv1.2, then the
client could still decide to abort the handshake if the client so desires.
When the server sends a fatal TLS alert, then interop has completely failed.

Calling a complete interop failure a "solution" is incompatible with
the mission of the IETF.

> Your complaint about signature strength is utterly bogus.

No, it isn't.  That TLSv1.2 breakage would have been easily
avoidable.  And we can still fix it, rather than pretending
that a sha1-with-rsa digital signature would be a reasonable and
secure default choice for a protocol.

> to evaluate connection strength.

When she starts surfing with a HTTP URL, then the little green lock
that onlyappears when she is prompted for her credit card provides
pretty close to zero security.

> connections, even when better options are supported by both sides?

When better options are supported by both sides, then it is our
task to (a) make these peers interoperate and (b) negotiate&use
at least some of those better protocol features in a fashion that
will not blow up badly in case of spurious internet connectivity failures
or when new TLS software is tested in a few servers of a NATed
server farm.

Fatally aborting the handshake is the far opposite of a successful
negotiation.

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Sun, 26 Jan 2014 16:12:10 +0200

> +1 or -1 and point back to the archives.)

+0.5

I'm not opposed to this document, but we should be realistic as to what 
this solution can accomplish.

This extension (I use this term in the sense of protocol extension, not 
TLS ClientHello Extension) will not protect the client or the server 
from a TLS proxy. TLS proxies that do not support high versions of TLS 
will negotiate both the client and the server down to TLS 1.0, and will 
not forward the SCSV.

Also, older servers will not recognize the SCSV and ignore it. So to 
have this extension add any value, all of the following much be true:
  - an updated server
  - an updated client
  - Something that causes the negotiation to fail. This something could 
be the client, the server, or something in between. The goal of this 
extension is to catch the something in the middle.

So presumably, the server blocks the connection, or returns a 
poorly-protected error page whenever it gets the SCSV. But this could be 
caused by a MitM that drops negotiations that have a too-high TLS 
version, or by client bugs or by server bugs. Broadly speaking, I think 
there are four failure scenarios:
  1. either the (updated) client or the (updated) server have bugs that 
caused the TLS 1.2 handshake to fail.
  2. The (updated) client has a bug causing it to send the SCSV even 
though no downgrade happened
  3. An attacker is on-path and is dropping TLS 1.2 because it can break 
TLS 1.2.
  4. An older firewall is dropping the TLS 1.2 connections, because they 
fail some sanity check. (that all TLS records have 3.0 or 3.1 in the 
record header)

So the extension makes sense if #3 is the likely scenario for failure. 
Any failure for the other reasons is kind of "collateral damage" that I 
don't think is justified in a world where TLS 1.0 is not considered so 
terrible as to disable it entirely. So I guess we need to hear some 
real-world experience about where most such failures would come from.  
Of course, we don't have any data *now* about buggy updated servers, so 
we'd have to guess how many and what kind of bugs are going to be 
present in not-yet-written code.

Yoav

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 26 Jan 2014 12:08:04 -0500

> will negotiate both the client and the server down to TLS 1.0, and will

By "TLS proxy", i think you mean a MITM that controls a CA certificate
that the client already has loaded in their root store (and is therefore
willing to "trust" to terminate the other end of a TLS connection).
Otherwise, if it strips the SCSV, the peers would notice that their
Finished handshakes don't match.

This sounds like yet another reason why TLS proxies of this type are
actively bad for client communications security.  The client has
delegated these decisions to such a proxy, and cannot make them on its own.

> extension is to catch the something in the middle.

Yes, precisely.  This is a proposed extension that should make TLS safer
between two compatible peers.

> caused the TLS 1.2 handshake to fail.

 ... *and* this happens in a scenario that causes the client to initiate
its fallback/downgrade mode to a level that offers the SCSV.

> fail some sanity check. (that all TLS records have 3.0 or 3.1 in the

Is this a "sanity check" or an "insanity check" ? :)

Your breakdown of the scenarios where this extension seems relevant is a
good one.

> terrible as to disable it entirely. 

Remember also that clients can choose to offer the downgrade SCSV only
for particular protocols that they really want to see go away (e.g.
today they might implement it when falling back to SSLv3 only, but not
when falling back to TLSv1).  This is covered by the Security
Considerations section of the draft.

Another way to look at the situation is: do we want to accept that the
existence of some client or server bugs (1 and 2) and some
overly-restrictive firewalls (4) mean we should leave all of our
machines vulnerable to the attacker in (3), even though we have a
mechanism to protect against that attacker when communicating with
updated peers?

Regards,

	--dkg

---

From: Watson Ladd <[email-masked]>
Date: Sun, 26 Jan 2014 10:15:05 -0800

> mechanism to protect against that attacker when communicating with

If a server is buggy it shouldn't pretend to offer TLS 1.2 support. If
you don't notice this bug, what are you
doing when testing? As a workaround one can turn off the downgrade
protection if fallback is required
to interop.

Furthermore, I think we should have a name-and-shame lab if we are
going to be considering not addressing security
issues because of interop. Everyone brings in their implementation,
and we go through the whole
combination of setups, and see what fails in unacceptable ways, then
publish the results. If you don't want to do this, then
you shouldn't offer your product as supporting TLS. We'll also have
negative test cases as well, plus some fuzzing.

Why exactly wouldn't a serious implementor be doing this already?
Let's see if we can get this done by IETF 90.  Furthermore, since
gambling is legal in the UK, you can put your money
where your mouth is.

Sincerely,
Watson

---

From: Bill Frantz <[email-masked]>
Date: Sun, 26 Jan 2014 10:18:10 -0800

On 1/26/14 at 6:12 AM, [email-masked] (Yoav Nir) wrote:

>1. either the (updated) client or the (updated) server have 
>bugs that caused the TLS 1.2 handshake to fail.
>2. The (updated) client has a bug causing it to send the SCSV even though no downgrade happened

Perhaps a decent public test suite could make these causes 
disappear. The idea that we're designing for buggy new software 
offends me. We should have procedures that eliminate these 
situations no later than very early in deployment.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | I don't have high-speed      | Periwinkle
(408)356-8506      | internet. I have DSL.        | 16345 
Englewood Ave
www.pwpconsult.com |                              | Los Gatos, 
CA 95032

---

From: Yoav Nir <[email-masked]>
Date: Mon, 27 Jan 2014 01:32:51 +0200

> Is this a "sanity check" or an "insanity check" ? :)

When attacks are known, it's easy to program firewalls or IPS systems to 
detect them. the problem is unknown attacks. One countermeasure that is 
as old as firewalls is to make a sanity check of what a protocol should 
look like. This is somewhat beneficial. Most buffer overflow exploits 
and even SQL injections would not pass a sanity check. So firewall 
validations are written to common practice, not necessarily to RFC.

Sometimes this has unintended consequences. 12 years ago, many firewalls 
(including ours) would make a sanity check on TCP: we enforced the 
sequence SYN--SYNACK--ACK--data. Apple introduced some version of Mac OS 
(I think it was 9.2) that had a unique feaure: The first data from the 
client was sent in the third packet instead of following it. For the 
firewall this was a violation of TCP sanity. But as it turns out, this 
is not prohibited by the TCP specs. We fixed our firewall, but I guess 
this broke some things. I haven't seen this behavior again anywhere, and 
all versions of Mac OS following that did not do this*.

So I wouldn't be surprised if there are some version-intolerant 
firewalls out there just as there are version intolerant servers.

Yoav
(*) Yes, I realize that this has probably more to do with moving to a 
BSD kernel than with traversing firewalls, but it is instructive that 
nobody repeated this experiment.

---

From: Watson Ladd <[email-masked]>
Date: Sun, 26 Jan 2014 16:24:01 -0800

On Sun, Jan 26, 2014 at 3:32 PM, Yoav Nir <[email-masked]> wrote:
> detect them. the problem is unknown attacks. One countermeasure that is as
> old as firewalls is to make a sanity check of what a protocol should look
> like. This is somewhat beneficial. Most buffer overflow exploits and even
> SQL injections would not pass a sanity check. So firewall validations are
> written to common practice, not necessarily to RFC.

How exactly does that hurt this proposal? If the server is behind the
firewall and the SCVC is
recognized, someone screwed up big time: not our fault, they can
always disable the
SCVC check, and it lets them know something is broken. If it's the
client, then this is the calculation
server operators get to make: kick them off, vs. enable downgrade attacks.

The second part is that this behavior is highly suboptimal for
permitting protocol evolution. Part of this
is our fault: validating and parsing incoming data should be done with
as little complexity as possible, reducing
future bugs.
However, it raises a big problem for TLS 1.3: something like reducing
round trips might get blocked
spuriously, or maybe we run into problems with big extensions etc.
More clarity on what is being done here is required, or you need to
tell your customers
"this product can break the internet in ways unanticipated, and it is
our fault". F5 was kind enough to explain
why they broke the internet, and it was for a somewhat good cause.
I'ld like to see future issues like this get
resolved before five years of worry go by.

The third part is that exploits don't necessarily fail sanity checks:
Even if limited to ASCII bytes,
I can most likely find a gadget that does what I need to get inside
within any large codebase. Oddly enough,
I've never seen a CVE where "firewall XYZ prevents exploitation" is
mentioned. You would think firewall vendors
would trumpet these successes if they ever happened. Or think of all
the sendmail bugs exploitable by sending email
to the wrong people: no firewall could ever stop them.

> (including ours) would make a sanity check on TCP: we enforced the sequence
> SYN--SYNACK--ACK--data. Apple introduced some version of Mac OS (I think it
> was 9.2) that had a unique feaure: The first data from the client was sent
> in the third packet instead of following it. For the firewall this was a
> violation of TCP sanity. But as it turns out, this is not prohibited by the
> TCP specs. We fixed our firewall, but I guess this broke some things. I
> haven't seen this behavior again anywhere, and all versions of Mac OS
> following that did not do this*.
>
> So I wouldn't be surprised if there are some version-intolerant firewalls
> out there just as there are version intolerant servers.
>
> Yoav
> (*) Yes, I realize that this has probably more to do with moving to a BSD
> kernel than with traversing firewalls, but it is instructive that nobody
> repeated this experiment.
>
>
>

---

From: "Yngve N. Pettesen" <[email-masked]>
Date: Mon, 27 Jan 2014 01:35:34 +0100

-1

I dislike this approach for several reasons:

1) I dislike the recent tendency to use (throw) an SCSV for (at) any  
protocol problem showing up. At present these decisions seem to be too  
ad-hoc IMO. If this use of SCSVs is to continue (which I do not recommend)  
perhaps the WG should first define a policy for when to use them, and  
possibly also set aside a range of ciphersuite values for SCSVs and  
interpretation of unknown SCSVs? E.g. should some SCSVs be considered  
critical, and should a server that knows about SCSVs but which does not  
understand a critical SCSV abort the connection?

2) The use of this SCSV require both client and server to be updated to  
understand the SCSV. The deployment of such a fix is going to take a  
minimum of 5-10 years (The renego patch, fixing a major security  
vulnerability, have only recently passed 80%, more than 3 years after it  
was released). I would prefer a solution that only require one party, the  
client, to be updated.

3) Involving two parties in determining what to do about the fallback  
issue will complicate implementations, and also risk interoperability  
problems. There is one party that specifically knows that it has been  
falling back, and who can (and IMO should) be making the decisions: the  
client. The reason for the fallback (assuming no client bugs) may be  
normal network issues, server non-compliance, non-compliant intermediates,  
or an MITM attack.  The only cases in which an SCSV might help, is in the  
case of non-compliant intermediates and MITM attacks, but that requires  
(as mentioned above) that the server supports the SCSV indication. If the  
server does not support the SCSV the client will have to assume that the  
server is just non-compliant and continue the connection using an older  
protocol, or use other means to try to discover if the connection is being  
interfered with before trusting it.

In my opinion the WG should not, at this stage, take on a specific  
solution as as work item, but should instead explore, as an I-D (by a  
neutral editor), the problem space and alternative proposals for solving  
the issues, including SCSVs, proxy indications (such as my renego-based  
proposal), or recommending "no fallback". That would collect information  
about the problems and proposals in a single document, and make the matter  
more readily accessible to new readers than trying to review several years  
of discussion threads in the WG mailing list. As for the time aspect,  
using 6-12 months to produce such a document might create a better  
understanding of the problem and solution, and would not delay the 5-10  
year deployment by much (for that matter, there are still many SSL v3-only  
servers 15 years after TLS 1.0 was published, so deployment might be 10-20  
years instead; unless the WG decides to set hard deadlines and to risk  
"breaking the internet").

A couple of questions that might be investigated in such a document  
includes: Should the solution support SSL v3-only servers? TLS 1.0 servers  
without TLS Extension support? Should SCSV capable servers be required to  
implement TLS 1.2? Can the indication be implemented as an extension  
instead? and so on.

Sincerely,
Yngve N. Pettersen

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

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 27 Jan 2014 10:43:50 +0100

> I think that's the greatest weakness of this concept.

New buggy servers that work exactly like the old buggy servers, and thus
require the same workarounds to achieve interoperability, are sort of out
of scope for this measure.   The spec changes essentially nothing about how
you work with these: you send an additional cipher-suite value, but expect
such servers to ignore it.  They really are old servers.

If "new" means servers with an updated implementation including support for
this SCSV, the hope is that once the spec has sufficient client-side
deployment, this can prevent the deployment of (certain) buggy servers,
because they'll fail standard interoperability testing.  If the new buggy
server honors the SCSV, the protocol downgrade workaround that exist to
deal with old buggy servers won't hide the problem as it otherwise might.

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 27 Jan 2014 12:03:29 +0100

Yngve N. Pettesen <[email-masked]>:

> understand a critical SCSV abort the connection?

I don't really like SCSVs either -- they are a last-resort measure: using
TLS extensions instead certainly would be cleaner, but we resort to an SCSV
so that we can send the signal even if we suspect that the server might not
tolerate any Client Hello extensions.

(Accordingly, I don't see a use case for critical SCSVs.  Only updated
implementations would know which SCSVs are to be considered critical; but
with updated implementations, we shouldn't need SCSVs in the first place.
 Possibly there'd be a cause for critical TLS extensions instead, but we'd
have a similar problem about retroactively declaring something "critical":
existing implementations just won't know about this.  If you want the
client to be able to insist on a particular extension, have the server send
it back when it sees it: that's something you can check in the client,
without depending on changes to the server implementation.  Of course you
could, say, specify a new TLS extension that allows negotiating a range of
critical TLS extensions, or specify such a range for all TLS 1.3
connections, but my first instinct is that anything like that is overly
complicated given what it can achieve.)

> was released). I would prefer a solution that only require one party, the

Your 5-10 year estimate is for wide deployment.  Narrower deployment can
happen much quicker: once you update your client, you get the expected
protection for all connections to those servers that have been updated.
 Even if that's just 1% of *all* servers, that 1% might include those
servers you care about most.  A percentage of servers isn't a very useful
metric (and even a percentage of appropriately specified "sessions"
couldn't do justice to the fact that security will be much more important
for some of these than for others).

 I would prefer a solution that only require one party, the client, to be
> updated.

I think everyone would prefer that; note that the TLS_FALLBACK_SCSV spec
doesn't preclude it.  Any client-only solution is still available, and if
the client doesn't need TLS_FALLBACK_SCSV (such as because it doesn't
attempt any fallback reconnections in the first place), it doesn't have to
send it.  Server-side support for TLS_FALLBACK_SCSV gives clients a
particular option: I think this option is currently useful, and expect that
it may be useful again when TLS 1.3 deployment starts, but certainly any
(intermediate) state in which clients don't have to make use of it would be
nicer.

> of discussion threads in the WG mailing list. As for the time aspect, using
> 6-12 months to produce such a document might create a better understanding
> of the problem and solution, and would not delay the 5-10 year deployment
> by much (for that matter, there are still many SSL v3-only servers 15 years
> after TLS 1.0 was published, so deployment might be 10-20 years instead;
> unless the WG decides to set hard deadlines and to risk "breaking the
> internet").
>

I don't agree with your assessment of the impact of a deployment delay, as
discussed further above.  The TLS_FALLBACK_SCSV spec exists specifically
*because* we want to be able to fix security for those connections going to
updated servers long before we can fix security with *all* servers.  If we
could just get all servers fixed (or give up interoperability with the
unfixed servers), we wouldn't need it.

(For example, if an updated server supports the extension from
draft-gutmann-tls-encrypt-then-mac-05, TLS_FALLBACK_SCSV can prevent
falling back to a handshake with no extensions, and thus without that
protocol fix.  With old servers, we might still have to use unfixed CBC
ciphersuites.)

> implement TLS 1.2? Can the indication be implemented as an extension

In case it's not clear, draft-bmoeller-tls-downgrade-scsv-01 is based on
the assumption that we do need to allow interoperability with SSL-3.0-only
servers and with extension-intolerant servers (because that's what various
clients currently do), and thus couldn't rely on an extension only.   (I'd
expect any server actually implementing TLS_FALLBACK_SCSV to also include
extension support, but it's about interoperability with servers that aren't
there yet.)  In the interest of simplicity -- reducing the burden on server
implementations --, the feature is specified as an SCSV only, without an
equivalent TLS Extensions.  As it happens, this also reduces the
on-the-wire overhead (2 bytes for the SCSV vs. at least 4 bytes for an
empty extension).

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 27 Jan 2014 12:40:55 +0100

> is a ServerHello with server_version=TLSv1.2.

Well, I guess that this sort of would work: I'd still expect many
connection failures (if a middle box doesn't like TLS 1.2 in the Client
Hello, why would it like it in the Server Hello and in actual use?), but
then with the TLS_FALLBACK_SCSV spec, failures are expected in the similar
scenario too.  Of course, a TLS_FALLBACK_SCSV-induced early abort is
computationally much cheaper than proceeding with a handshake and running
into a failure later.

Also note that TLS_FALLBACK_SCSV as specified in
draft-bmoeller-tls-downgrade-scsv-01
is *not* about having the client indicate to the server that it supports
TLS 1.2 and would like to use that particular protocol version.  To keep
the protocol as simple as possible and entirely *avoid* servers-side
heuristics, the SCSV simply indicates that the client has fallen back below
the protocol version it would normally try to use: maybe it would really
want to use TLS 1.3, maybe it would really want to use TLS 1.1 (but has
fallen back to 1.0).  Trying to do a secondary protocol version negotiating
using SCSVs as sketched by you would be much more complex than handling
TLS_FALLBACK_SCSV, with unclear practical advantages (see above).

Of course, TLS_FALLBACK_SCSV won't prevent you from experimenting with that
kind of fix.  The caveat is that where the current spec has the server look
at ClientHello.client_version, server implementations would have to look at
the overridden client_version value instead.

Bodo

---

From: [email-masked] (Martin Rex)
Date: Mon, 27 Jan 2014 16:07:39 +0100 (CET)

Watson Ladd wrote:
> 
> If a server is buggy it shouldn't pretend to offer TLS 1.2 support.
> If you don't notice this bug, what are you doing when testing?
>   [...]
>
> going to be considering not addressing security issues because of
> interop.
>   [...]
>
> If you don't want to do this, then you shouldn't offer your product
> as supporting TLS.
>   [...]
> 

I don't know why vendors are not testing in any reasonable fashion
before shipping, but I know that it is happening regularly.

Microsoft goofed the RSA premaster secret version check for
the renegotiation handshake in Windows 7 (the first version of
SChannel that supports TLSv1.2):

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

The TLS WG knew very well that there were serious interop problems in the
installed base about the RSA Premaster secret version check and that
these interop problems lead to handshake failures.  The TLS WG also knew
that the security of TLS does not depend on RSA premaster secret
client_version number, because it this additional version number appears
only in static RSA key exchanges, it does not appear in DH and DHE key
exchanges.

Now in spite of knowing this, the TLS WG added s not-well-baked text
to the TLSv1.2 specification recommending that servers be anal about
the RSA premaster secret and abort the TLS handshake in a knee-jerk reaction:

  https://tools.ietf.org/html/rfc5246#page-59

and Microsoft's SChannel is (a) anal about the check and (b) got the
check wrong for the renegotiation handshake in Windows 7 and is actively
causing painful and unnecessary interop problems at zero benefit:

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

-Martin

---

From: [email-masked] (Martin Rex)
Date: Mon, 27 Jan 2014 16:29:56 +0100 (CET)

> extension is to catch the something in the middle.

You're missing an even more important pre-requisite.

This SCSV will only provide any value for application clients that are
actually implementing a reconnect fallback logic at the application
level.  A fallback reconnect can not be transparently implemented
by a TLS implementation, because it requires a seperate and new connection
to be established, and any application-level protocol handshakes
(such as a HTTP CONNECT proxy traversal or the application protocol
exhanges that happen before and include "STARTTLS".

The vast majority of programmatic TLS clients does still does not have
any reconnect fallback logic, and would have zero benefits from this
proposal.

A modified extension that allows the server to continue the handshake
with a TLSv1.2 ServerHello, could be processed transparently within
the TLS client implementation and provide immediate benefits to TLS clients
that do not have any application-level reconnect fallback.

What you also have to keep in mind is that the reconnect fallback that
has been implemented&shipped was quite brittle/flaky, and reconnect
fallbacks often happen unnecessarily because of bugs in the clients
connection handling (keep in mind that this is app-level reconnect
fallback logic, since this can not be transparently hidden within TLS):

  https://bugzilla.mozilla.org/show_bug.cgi?id=450280#c3

I know that Microsoft Internet Explorer has similar problems in its
client-side app-level connection state handling, which can already cause
connection failures (and white pages/frames).

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 27 Jan 2014 09:10:52 -0800

Bodo Moeller wrote:
> 
> I don't really like SCSVs either -- they are a last-resort measure: 
> using TLS extensions instead certainly would be cleaner, but we resort 
> to an SCSV so that we can send the signal even if we suspect that the 
> server might not tolerate any Client Hello extensions.

Then we really don't want to define TLS_FALLBACK_SCSV at all since
it's too specific.

The SCSV we really need is one that indicates a belief by the client
that the server is intolerant to extensions.  The downgrade protection
can be a normal extension, and a client would only resort to sending
the TLS_NO_EXTENSIONS_SCSV if it gets pushed all the way back to TLS
v1.0 w/o extensions or SSLv3.

Mike

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 27 Jan 2014 09:22:25 -0800

-1

We should consider whether we can define a single SCSV that a
client issues when it thinks a server is extension intolerant.

Such an SCSV could be used in conjunction with a normal extension
used for downgrade protection, if the client gets pushed all the
way back to TLSv1.0 without extensions, or to SSLv3.

This approach could solve the problem of desiring more SCSVs in
the future.

Mike

---

From: Adam Langley <[email-masked]>
Date: Mon, 27 Jan 2014 12:27:30 -0500

> that do not have any application-level reconnect fallback.

The ServerHello could not contain options that the ClientHello didn't
offer. For example, AES-GCM or even ECDHE (if the client fell back to
SSLv3). Thus an attacker could still choose important features of the
connection.

Cheers

AGL

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 27 Jan 2014 20:34:35 +0100

> This approach could solve the problem of desiring more SCSVs in

Hm, that would mean having the SCSV for special-case downgrade protection
(extension intolerance) and an extension for general-case downgrade
protection (when extension intolerance is not an issue).  That means
requiring more code to be added to servers (to *all* servers, since these
mechanisms only work as intended if all servers support them).  In
practice, what would be gained from that over just having the SCSV and
using it for both?

(If someone really wanted to add a new negotiation mechanism for anything
and allow it to be backported to SSL 3.0 implementations with no extension
support, they'd *still* want a new SCSV for that ...  however, I hope that
with the protocol downgrade issue getting addressed, the need to support
any other new protocol tweak to these obsolete protocol versions will go
away.  For example, draft-gutmann-tls-encrypt-then-mac-05 doesn't need an
SCSV when you can use TLS_FALLBACK_SCSV to avoid falling back to old
protocol versions.)

Bodo

---

From: [email-masked] (Martin Rex)
Date: Tue, 28 Jan 2014 01:17:37 +0100 (CET)

Bodo Moeller wrote:
> mechanisms only work as intended if all servers support them).

But you _are_ aware that your proposal is vitally dependent that
the TLS server puts a fatal SSL alert on the wire before closing
the connection?  Historically, (close to) all applications running
on top of Microsoft SChannel (including MSIE client and IIS server)
do not send any fatal alerts before closing connections, because
they use a transport-free API (Microsoft SSPI, similar to GSS-API)
to their TLS implementation, and the application code does not support
(a) processing a fatal error messages and (b) sending tokens over
the network at the same time.  It's basically the same reason
why the forwarding of error tokens and outputs of "gss_delete_sec_context()"
was deprecated in GSS-API v2 -- because most apps will simple refuse
to do it.

It would not be possible to hide such a change in behaviour (writing
a fatal alert to the network before closing the connection) within
SChannel, it would also require a change to at least Microsoft IIS.
How likely is that going to happen?  (It's been the way it is not
for the last ~14 years...).

Which server implementers are eager to send such a fatal alert as
is contained in this proposal anyway?  I will certainly ensure that
our server implementation will NEVER grow such silly behaviour.

-Martin

---

From: Adam Langley <[email-masked]>
Date: Mon, 27 Jan 2014 19:34:46 -0500

On Mon, Jan 27, 2014 at 7:17 PM, Martin Rex <[email-masked]> wrote:
> SChannel.

I don't believe that sending an alert is beyond the ken of Andrei and
Microsoft free to speak up if they have a problem with it.

Cheers

AGL

---

From: Andrei Popov <[email-masked]>
Date: Tue, 28 Jan 2014 01:04:40 +0000

For my understanding: why is this proposal vitally dependent on the server sending inappropriate_fallback alert? If the server receives the SCSV, has a higher protocol version enabled than that in the ClientHello, and quietly aborts the handshake, isn't the downgrade attack thwarted?

Thanks,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Monday, January 27, 2014 4:18 PM
To: Bodo Moeller
Cc: [email-masked]
Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv

Bodo Moeller wrote:
>> We should consider whether we can define a single SCSV that a client 
>> issues when it thinks a server is extension intolerant.
>>
>> used for downgrade protection, if the client gets pushed all the way 
>> back to TLSv1.0 without extensions, or to SSLv3.
>>
>> This approach could solve the problem of desiring more SCSVs in the 
>> future.
> 
> Hm, that would mean having the SCSV for special-case downgrade 
> protection (extension intolerance) and an extension for general-case 
> downgrade protection (when extension intolerance is not an issue).  
> That means requiring more code to be added to servers (to *all* 
> servers, since these mechanisms only work as intended if all servers support them).

But you _are_ aware that your proposal is vitally dependent that the TLS server puts a fatal SSL alert on the wire before closing the connection?  Historically, (close to) all applications running on top of Microsoft SChannel (including MSIE client and IIS server) do not send any fatal alerts before closing connections, because they use a transport-free API (Microsoft SSPI, similar to GSS-API) to their TLS implementation, and the application code does not support
(a) processing a fatal error messages and (b) sending tokens over the network at the same time.  It's basically the same reason why the forwarding of error tokens and outputs of "gss_delete_sec_context()"
was deprecated in GSS-API v2 -- because most apps will simple refuse to do it.

It would not be possible to hide such a change in behaviour (writing a fatal alert to the network before closing the connection) within SChannel, it would also require a change to at least Microsoft IIS.
How likely is that going to happen?  (It's been the way it is not for the last ~14 years...).

Which server implementers are eager to send such a fatal alert as is contained in this proposal anyway?  I will certainly ensure that our server implementation will NEVER grow such silly behaviour.

-Martin

---

From: Andrei Popov <[email-masked]>
Date: Tue, 28 Jan 2014 01:46:36 +0000

Just to clarify: schannel does generate alerts as specified for SSL/TLS, and these alerts are exposed via SSPI. For a variety of reasons, SSPI callers may choose to not send alerts when a handshake is aborted, but technically they could.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Adam Langley
Sent: Monday, January 27, 2014 4:35 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv

On Mon, Jan 27, 2014 at 7:17 PM, Martin Rex <[email-masked]> wrote:
> It would not be possible to hide such a change in behaviour (writing a 
> fatal alert to the network before closing the connection) within 
> SChannel.

I don't believe that sending an alert is beyond the ken of Andrei and Microsoft free to speak up if they have a problem with it.

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Mon, 27 Jan 2014 20:52:22 -0500

> For my understanding: why is this proposal vitally dependent on the server sending inappropriate_fallback alert? If the server receives the SCSV, has a higher protocol version enabled than that in…

Yes, just closing the connection is good enough for security. The
advantage of returning the fatal alert is that a) it stops the
fallback process faster and b) the client can report the error that
caused the original connection to fail, rather than that the final
fallback hit connection closed.

Cheers

AGL

---

From: [email-masked] (Martin Rex)
Date: Tue, 28 Jan 2014 04:31:41 +0100 (CET)

> SSLv3). Thus an attacker could still choose important features of the

You really do not need to curtail your imagination and creativity so
badly.

If you have an urge to resend a ClientHello with TLS extensions,
how about extending this proposal to allow the client to do this
within the handshake rather then dropping the connection like
a hot potato and expecting the application to clean up the resulting
mess with an app-supplied reconnect fallback facility?

The negotiation could work like this:

Client is performing a fallback and stripping information from
ClientHello (such as TLS extensions or certain cipher suites)
that the client would prefer to use if availabe and marks that
omission with an SCSV.

Server checks the ClientHello, recognizes the SCSV and if the
server supports features beyond those currently present in
ClientHello _and_ features which would be preferable _to_the_server_ 
(such as ECC cipher, AES-GCM cipher suites, TLS signature extension),
then the server could return ServerHello with ServerHello.cipher_suite=SCSV
and ServerHello.server_version set to the highest TLS version supported
by the server directly followed by ServerHelloDone, and upon receiving
this, the client would simply restart the Handshake with a new
ClientHello handshake message that contains all the previously omitted
stuff.

In a number of situations, the server may simply want to continue
the handshake, when the server does not support any features beyond
what is offered in that fallback ClientHello, or when the choices present
in the fallback ClientHello meet the preferences configured by the
server administrator.   i.e. when the server admin has configured
to prefer TLS_RSA_WITH_AES_128_CBC_SHA, this cipher suite is
present in the fallback ClientHello and the server has only a
single cipher suite, then it wouldn't matter when
ClientHello.client_version is only TLSv1.1 or when there are
no TLS extensions in ClientHello, and no need to suggest resending
his ClientHello to the client.

i.e. the regular full TLS handshake:

  http://tools.ietf.org/html/rfc5246#page-36

     Client                                               Server

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

             Figure 1.  Message flow for a full handshake

the fall-forward full TLS handshake: 

     Client                                               Server

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

             Figure 1.  Message flow for a full handshake

-Martin

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 28 Jan 2014 09:52:31 +0100

The negotiation could work like this:

>       Application Data             <------->     Application Data

Well, it could, but I certainly think it's fair to say that getting this
deployed will take much more design and implementation work than
deploying TLS_FALLBACK_SCSV.

There's actually no conflict here.  TLS_FALLBACK_SCSV provides an
immediately available simple fix for clients that use protocol fallback
strategies.  Later, if and when a more elaborate solution is available (or
if broken servers simply are no longer an issue, whichever happens first),
either clients won't have to send TLS_FALLBACK_SCSV (if there's no fallback
reconnect), or servers won't have to abort the connection (if they are able
to negotiate a non-downgraded protocol version as in your protocol sketch).

(I'm highly skeptical that extending the protocol by another round as shown
in your diagram would be desirable overall and that this would solve a
real-world problem in the real world, but the utility of TLS_FALLBACK_SCSV
does not depend on that question.)

Bodo

---

From: t.petch <[email-masked]>
Date: Tue, 28 Jan 2014 11:09:53 +0000

Accept.

I never wanted SCSV in the first place but now the cat is out of the
bag, we might as well make the most of it.

Tom Petch

---

From: Andrei Popov <[email-masked]>
Date: Tue, 28 Jan 2014 15:41:44 +0000

Yes, this makes sense, and the other fatal TLS alerts are defined for similar reasons. Because of Martin's comment, I thought I might be overlooking a security issue with not sending inappropriate_fallback.

Thanks,

Andrei

________________________________________
From: Adam Langley <[email-masked]>
Sent: Monday, January 27, 2014 5:52 PM
To: Andrei Popov
Cc: [email-masked]; Bodo Moeller; [email-masked]
Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv

Cheers

AGL

---

From: Yoav Nir <[email-masked]>
Date: Tue, 28 Jan 2014 15:57:36 +0000

Well, suppose a client implements a three-stage fallback: TLS1.2-with-extensions--->TLS1.0-with-extensions--->SSLv3.

Suppose TLS1.2-with-extensions got a RST. The client is now trying TLS1.0-with-extensions. If it gets an alert, it will know that it needs to stop. If it gets another RST, it will proceed to try SSLv3, and that's a bad thing, because it should have stopped at TLS 1.0.

I don't think it matters much, because if an attacker can cause a TLS 1.2 session to fail, it can do the same to a TLS 1.0 session. So an attacker can always force the sides to the lowest common denominator. The best this extension can do is to make sure that when they finally do talk to each other at the lowest common denominator, that they recognize that the interference had happened. As long as they don't go below SSLv3, they will know that with the SCSV, regardless of whether the server resets or sends an appropriate alert.

Yoav

On Jan 28, 2014, at 5:41 PM, Andrei Popov <[email-masked]>
 wrote:

> Email secured by Check Point

---

From: Andrei Popov <[email-masked]>
Date: Tue, 28 Jan 2014 20:12:01 +0000

Correct, but I'm more concerned about this scenario: suppose a client implements a three-stage fallback: TLS1.2-with-extensions ---> TLS1.0-with-extensions ---> SSLv3.
Suppose TLS1.2-with-extensions got a RST from a TLS1.2-supporting server because there is an interoperability problem, or a middle box problem, or a configuration problem, etc.
The client is now trying TLS1.0-with-extensions + SCSV. Without the SCSV, the handshake may have succeeded, but with SCSV the TLS connection will fail.

>From the standpoint of the browser vendors, this largely defeats the purpose of re-connects. Perhaps a browser could only send the SCSV on the last re-connect, when downgraded to the least secure protocol version (e.g. SSL3). But even this compromise seems unlikely to get deployed.

Cheers,

Andrei

-----Original Message-----
From: Yoav Nir [mailto:[email-masked]] 
Sent: Tuesday, January 28, 2014 7:58 AM
To: Andrei Popov
Cc: Adam Langley; [email-masked]
Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv

Yoav

---

From: Adam Langley <[email-masked]>
Date: Tue, 28 Jan 2014 15:19:31 -0500

> The client is now trying TLS1.0-with-extensions + SCSV. Without the SCSV, the handshake may have succeeded, but with SCSV the TLS connection will fail.

We have pretty good evidence that SCSVs are ok from putting them in
SSLv3 for renego, no?

I suppose it's possible that there exist some TLSv1 servers that
handle the renego extension, but couldn't handle the SCSV, but we have
deployed new ciphersuites in the past without issue, no? (Except for
the servers that only look at the lower 8-bits, but we believe that we
can order the ciphersuites to avoid those problems.)

Cheers

AGL

---

From: Watson Ladd <[email-masked]>
Date: Tue, 28 Jan 2014 12:38:28 -0800

> We have pretty good evidence that SCSVs are ok from putting them in

No, that isn't the concern Mr. Popov expresses. The concern is that
the TLS 1.2 supporting server thinks it supports TLS 1.2 but actually
doesn't. Then the fallback to TLS 1.0 fails, instead of succeeds,
because it's a fallback that is unnecessary according to the server.
He's exactly correct that putting in this SCSV will cause a connection
failure.

However, this can't be distinguished from a downgrade attack, and I
doubt that servers will have mistaken beliefs about their TLS 1.2
support.

---

From: Adam Langley <[email-masked]>
Date: Tue, 28 Jan 2014 15:43:30 -0500

> because it's a fallback that is unnecessary according to the server.

Ah, I see.

It's certainly possible that clients that are currently doing a
fallback because of a middle box will stop working because of this
SCSV, yes. It won't be clear how big a problem this is until Chrome 33
rolls out.

If we get a good population of clients with this SCSV however, servers
that add support for it and need fallbacks should find any problems in
testing.

There might be areas of TLS 1.2 that the population of SCSV-enabled
clients don't test and bad servers could grow in that space. That's
also the case today.

Cheers

AGL

---

From: [email-masked] (Martin Rex)
Date: Wed, 29 Jan 2014 04:18:35 +0100 (CET)

> does not depend on that question.)

In contrast to your proposal, such an approach would result in additional
interoperability that can be transparently provided by two TLS
implementations.

Compare it to what your current proposal *REALLY* amounts to:

      Client                                               Server

       minimal ClientHello w/SCSV    -------->
                                    <--------           FatalAlert
    close()          TCP FIN         -------->
                                    <--------    TCP FIN ACK
                     TCP ACK         -------->

    connect()        TCP SYN         -------->
                                    <--------    TCP SYN ACK
                     TCP ACK         --------> 

   "HTTP CONNECT a.b.c:1234"  --->
                             <--- "HTTP/x.y 200 Connection established"

       ClientHello                   -------->
                                                       ServerHello
                                                      Certificate*
                                                ServerKeyExchange*
                                               CertificateRequest*

and you need to redesign each and every TLS application caller
to implement this reconnect fallback in order to be able to
use this.

The example protocol flow that I gave is just one possible outcome,
the server could simply continue a regular handshake if it doesn't
expect any benefits from the client doing a reconnect fallback.

Right now, the vast majority of programmatic TLS clients do not
implement reconnect fallbacks and will therefore use a conservative
TLSv1.0-only ClientHello, maybe even an extension-less TLSv1.0 ClientHello
to get the best interoperability results.

With the fall-forward approach, the TLS implementation could transparently
provide an in-band upgrade to TLSv1.2 features without loosing any
connectivity to TLS version-intolerant and TLS extensions-intolerant
servers, and without any single caller having to retrofit a reconnect
fallback at the application layer.

In many communication scenarios, full handshakes are rare to compared
to TLS session resumes, and none of the complexity appears on
TLS session resumes and neither on full handshakes with a session
resumption proposal (that may turn into a full TLS handshake when the
server has already expired the session on his side).

If you're wondering about the amount of changes that are required
and the likelyhood of a change getting deployed--the real benefit
and the amount of situations/connections & components that will
benefit from a change may actually be more important than the size
of the code change itself.

The sooner we can obviate reconnect fallback hacks, the better.

I've had a few apps folks come and ask for support for TLSv1.1 & TLSv1.2
in our TLS client.  Every time when I explain to them that they will
either be facing a sustained level of customer support calls to analyze
and fix connection failures, or they will have to retrofit a complex,
heuristics-based multi-level reconnect fallback logic into their
application I see jaws dropping all the way to the floor and they
bin their plans.

-Martin

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 29 Jan 2014 19:30:35 +0000

Hi Folks,

I'm glad that we have people that are motivated and passionate about this topic participating in this discussion.  This is a good thing for the standards process, however we need to temper our comments on the list so the tone does not come across as personal and negative.  This behavior turns both observers and other participants away from the discussion.  This is bad for the standards process.   If you have issues with some aspect of the discussion please raise that with the chairs or ADs.  

Some comments inline below. 
 
Thanks,

Joe

> to this thread is just wrong.

[Joe] The above is unnecessary.

> to evaluate connection strength.

[Joe]  The tone of the above is also unnecessary.

---

From: Russ Housley <[email-masked]>
Date: Fri, 31 Jan 2014 11:45:17 -0500

I did not previously voice an opinion, but I think the TLS WG should adopt the document and push to WG Last Call very quickly.

Russ