Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

From: Brian Smith <[email-masked]>
Date: Fri, 3 Oct 2014 10:09:10 -0700

On Fri, Sep 26, 2014 at 11:58 AM, Brian Smith <[email-masked]> wrote:
> On Fri, Sep 26, 2014 at 12:34 AM, Bodo Moeller <[email-masked]> wrote:
>>> I'm OK with that, but if this is the real reason for the MUST, then
>>> it's not particularly clear.
>>
>> Hm, maybe so. I can add a brief note showing how the handshake would fail if
>> the server acts on the SCSV in this case, but I don't think the document
>> should have to explain why we require the client to omit the SCSV rather
>> than having the server ignore it. (Why would you want to send it if nothing
>> follows from that?)
>
> Here is what the draft actually says:
>
>       However, as an exception to the above, when the client intends to
>       perform an abbreviated handshake to resume a previously negotiated
>       session and sets ClientHello.client_version to the protocol
>       version negotiated for that session, the client MUST NOT include
>       TLS_FALLBACK_SCSV in ClientHello.cipher_suites.
>
> So, if the client does NOT set ClientHello.client_version to the
> version negotiated for that session, then the client MAY send the SCSV
> in the resumption handshake.

Bodo, could you please reword the above to make it clearer? e.g.:

"However, as an exception to the above, when the client sets
ClientHello.client_version to the protocol version negotiated for for
a session that it is trying to resume, and that version is less than
the ClientHello.client_version it would otherwise send if it were not
attempting to resume a session, then the client MUST NOT include
TLS_FALLBACK_SCSV in ClientHello.cipher_suites.

For example, if the client is doing a non-secure fallback, and it is
resuming a session that previously negotiated TLS 1.0, and it sets
ClientHello.client_version to TLS 1.1, then TLS_FALLBACK_SCSV must be
included in ClientHello.cipher_suites. However, as another example, if
the client is resuming a session that previously negotiated TLS 1.0,
and it sets ClientHello.client_version to TLS 1.0 to match the version
number of the session, then it must not include TLS_FALLBACK_SCSV in
ClientHello.cipher_suites."

> Now, if the server could indicate that it supports the SCSV somehow in
> its ServerHello, then the client could save that acknowledgement in

Please ignore this suggestion I had about an explicit indicator. It
isn't important and there are better ways of accomplishing the same
effect.

Cheers,
Brian

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 10 Oct 2014 21:52:24 +0200

> Bodo, could you please reword the above to make it clearer?
>

Maybe I should rather change it?

"However, when the client intends to
perform an abbreviated handshake to resume a previously negotiated
session and sets ClientHello.client_version to the protocol
version negotiated for that session, the client MAY omit
TLS_FALLBACK_SCSV from ClientHello.cipher_suites
even if that version is lower than the latest version supported by the
client.

(Given that the protocol version has previously been negotiated
between the client and server, TLS_FALLBACK_SCSV is only
expected to have an effect if the server has since been updated
to support higher versions. Omitting TLS_FALLBACK_SCSV
lets the client continue to use the previously negotiated protocol
version. Sending TLS_FALLBACK_SCSV, in contrast, could lead
to an inappropriate_fallback alert if the client should start anew
to create a new session using the new highest protocol version.)"

Previously I'd assumed you'd want to keep "normal" behavior (simply
continue to use the previous protocol version), but I don't see a
compelling reason for the specification to prescribe that to clients.

Bodo

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Oct 2014 13:07:43 -0700

On 10 October 2014 12:52, Bodo Moeller <[email-masked]> wrote:
> Previously I'd assumed you'd want to keep "normal" behavior (simply continue
> to use the previous protocol version), but I don't see a compelling reason
> for the specification to prescribe that to clients.

Yes, that's in general a good change.

Maybe a small editorial concern with the following:

> "[...]  Sending TLS_FALLBACK_SCSV, in contrast, could lead

This doesn't read particularly well to me.  It places the option to
create a new session as a condition on the first part of the
statement.

Maybe, "Sending TLS_FALLBACK_SCSV could lead to an
inappropriate_fallback alert. Clients that encounter an
inappropriate_fallback alert in response to a session resumption
attempt SHOULD use highest protocol version available to it when
connecting to that server."

I don't know if that's strictly better, but I hope that you catch my meaning.

---

From: Brian Smith <[email-masked]>
Date: Fri, 10 Oct 2014 22:07:41 -0700

> to create a new session using the new highest protocol version.)"

Let's review the scenerio in detail:

1. Client attempts handshake with client_version == TLS 1.2, and the
handshake fails.
2. Client attempts handshake with client_version == TLS 1.1, and the
handshake succeeds, with both sides saving the session information.
3. Server is upgraded to support TLS 1.2 or higher.
4. Client attempts to handshake with client_version == TLS 1.1 and a
resumed session ticket.

There are four cases to consider:

CASE 1: Client included the TLS_FALLBACK_SCSV, server forgot session
state when it was upgraded. The result is an inappropriate_fallback
alert.

CASE 2: Client included the TLS_FALLBACK_SCSV, server (magically!!!)
retained the session state across the server software upgrade. The
result is an inappropriate_fallback alert.

CASE 3: Client did not include the TLS_FALLBACK_SCSV, the server
forgot session state when it was upgraded. The server starts a new TLS
1.1 session. Thus, the downgrade protection mechanism has failed to
prevent a version downgrade.

CASE 4: Client did not include the TLS_FALLBACK_SCSV, the server
(magically!!!) retained the session state across the software upgrade.
The server resumes the TLS 1.1 session instead of starting a new TLS
1.2 session. Thus, the downgrade protection mechanism has failed to
prevent a version downgrade.

> for the specification to prescribe that to clients.

Doing that also allows version downgrade to succeed inappropriately in
the case where the server's capabilities were improved during the
lifetime of a session cached by a client.

I think the best solution is to take my original suggestion (i.e. keep
the current logic, but make it more clear), and also suggest that,
after the client has received an inappropriate_fallback alert, the
client SHOULD forget what it has learned about what the server's
version tolerance and cached sessions, and retry its version
intolerance logic over, taking care not to get into an infinite loop
in the even that it receives another inappropriate_fallback alert when
it retries.

I think it is realistic to expect that servers that implement the
inappropriate_fallback logic to implement at least TLS 1.2 (or at
least TLS 1.1), so you could also suggest that the client MUST (not
just SHOULD) send always send TLS_FALLBACK_SCSV when it negotiates TLS
1.1 or lower, because the "deployment of a new protocol version"
consideration does not apply for those versions.

If for some reason this cannot be done, then at a minimum the security
considerations need to be expanded to document that downgrade is still
possible in CASE 3 and CASE 4 above.

Cheers,
Brian

---

From: Andrey Jivsov <[email-masked]>
Date: Fri, 10 Oct 2014 23:36:26 -0700

On 09/25/2014 09:00 PM, Joseph Salowey (jsalowey) wrote:
> This is an announcement for the working group last call for draft-ietf-tls-downgrade-scsv-00.  Please review the document and send your comments to the list by Friday, October 17, 2014.
>
> Thanks,
> J&S

> 3. Server behavior

Suppose a server and a client support TLS1.2, client starts with TLS1.2 
but network failure makes the client reconnect with TLS1.1. Or perhaps 
there is an occasional bug in TLS1.2 path on the client or the server, 
leading to the same TLS1.1 reconnect.

In this case the server is prescribed to fail with 
inappropriate_fallback for TLS1.1 + SCSV.

* Assuming network failures, how does the client decide to continue with 
TLS1.1 ? (strictly speaking, this is not a "standard" behaviour)
* How should the client process the inappropriate_fallback?
* Has the server become "intolerant" when it issued 
inappropriate_fallback for TLS1.1 when it happily negotiates TLS1.0 and 
above "fresh"?

Is it possible that the majority of version-intolerant servers is 
limited to SSL2.0, SSL3.0 and TLS1.0 protocols? If so, would it be 
reasonable to expect that the servers supporting TLS 1.1 and above are 
maintainable and can be fixed "right", i.e. by making them compliant 
with the TLS spec?

( A general comment, it's reasonable to support two versions, {N, N+1} 
that are both considered secure at any given moment, as an gradual 
upgrade strategy, one of them on the way out. I think it looks odd to 
fail on N just because you happen to have N+1 supported. This is 
different when N is insecure. )

---

From: Brian Smith <[email-masked]>
Date: Mon, 13 Oct 2014 14:54:36 -0700

> result is an inappropriate_fallback alert.

There's an important thing to note about these two cases: They only
apply when the server is, or recently was, TLS intolerant. That is,
the client did a non-secure fallback due to TLS intolerance, then the
server was upgraded to support the TLS_FALLBACK_SCSV and/or a higher
version of TLS, and then the inappropriate_fallback is sent. If the
server wasn't already TLS intolerant, then CASE 1 and CASE 2 won't
happen. Thus, I think it is better to say tat clients MUST send the
TLS_FALLBACK_SCSV in the ClientHello whenever they decrease
ClientHello.client_version due to their TLS intolerance logic.

Also, the draft fails to state something that is obvious to us, but
which is better to state explicitly: The server needs to ensure it
isn't version intolerant, or else adding support for the
TLS_FALLBACK_SCSV will cause the server to stop working.

There are several non-obvious reasons why a server might seem like it
is "version intolerant" or "extension intolerant" even though it
generally supports version negotiation and generally parses extensions
correctly:

* I have seen modern servers act like they are "TLS intolerant" when
OCSP stapling is enabled and the server's certificate doesn't contain
an OCSP AIA URI. The fallback to SSL 3.0 "works" for them because
browsers stop sending the status_request extension. However, the
server actually does the version negotiation correctly, modulo this
OCSP stapling bug. The best solution to this is to get a new
certificate that has the OCSP AIA URI in it.

* I have seen some servers (e.g. from Cisco) that don't like certain
orderings of TLS extensions (especially the new padding extension).
Again, non-secure fallback to SSL 3.0 "works" for them because no
extensions get sent in the ClientHello. But, the servers actually get
the version negotiation correct, modulo this buggy extension handling.
The solution to this is to upgrade to the version of the server
software that Cisco hasn't released yet(!). (And, browsers should
probably find a workaround for this issue. See
https://bugzilla.mozilla.org/show_bug.cgi?id=998135#c11.)

* I have seen some servers where the hostname-specific TLS
configuration is broken, but where the generic non-host-specific
configuration works. These servers appear to be TLS intolerant because
they try to use the hostname-specific TLS configuration when the SNI
extension is given, and fail due to it being broken. When the browser
downgrades to SSL 3.0, the non-hostname-specific configuration is
picked up, and the handshake succeeds. Thus, the problem isn't in the
server's TLS stack's version engotiatoin at all, but rather in the web
server's configuration file. The solution to this problem is to fix
the fix the configuration file.

These types of issues, and other similar ones, need to be accounted
for when deploying TLS_FALLBACK_SCSV on the server. Because these
issues are relatively easy to fix, and relatively rare, the existence
of these issues shouldn't stop any server software vendor from
deploying TLS_FALLBACK_SCSV and enabling it by default. But, people
should be aware of these issues when diagnosing surprises.

Cheers,
Brian

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 14 Oct 2014 01:47:12 +0200

[...]

> There are four cases to consider:
[...]

> prevent a version downgrade.

Right, this is the most problematic case. Resuming a session using the old
protocol version (if the server still recognizes that session) is one
thing, but using the old version for a new session is another.

However, this issue really just follows from the relevant language in the
TLS RFCs: "Whenever a client already knows the highest protocol version
known to a server (for example, when resuming a session), it SHOULD
initiate the connection in that native protocol." If the client follows
these directions, using the old protocol version even in case the server
gets upgraded is expected.

> continue
> the current logic, but make it more clear),

Now I'm a bit confused. If you consider that consequence (using the old
version if server capabilities have improved since) "improper", why do you
suggest keeping the current logic?

> least TLS 1.1),

I'm not so sure -- the TLS_FALLBACK_SCSV mechanism by design works equally
well with TLS 1.0 and can be easily retrofitted at least in principle.
Thus, to allow essentially *every* implementation to benefit from the SCSV,
I wouldn't want to require any higher version.

Boo

---

From: Brian Smith <[email-masked]>
Date: Mon, 13 Oct 2014 17:22:03 -0700

On Mon, Oct 13, 2014 at 4:47 PM, Bodo Moeller <[email-masked]> wrote:
> protocol version (if the server still recognizes that session) is one thing,
> but using the old version for a new session is another.
>
> known to a server (for example, when resuming a session), it SHOULD initiate
> the connection in that native protocol." If the client follows these
> directions, using the old protocol version even in case the server gets
> upgraded is expected.

I agree. But, my conclusion is that the TLS specification is wrong,
and that that advice should be dropped from it and ignored by clients,
because it enables this scenerio. I also think that the spec should be
changed to require servers to never resume a session for a version
lower than min(ClientHello.version, <the highest version the server
supports>), for similar reasons.

In fact, your draft would be a good place to tell clients that they
SHOULD NOT follow that advice in the TLS specifications.

> suggest keeping the current logic?

The current logic in your draft says that if the client doesn't
downgrade ClientHello.client_version to equal the version in the
resumed session, then it must send the TLS_DOWNGRADE_SCSV if
ClientHello.client_version is less than the highest version that it
supports. That is the correct logic. The way it is written has made
people think that TLS_DOWNGRADE_SCSV is never supposed to be sent
during resumption handshakes, which is why it is good to clarify it.

> well with TLS 1.0 and can be easily retrofitted at least in principle. Thus,
> to allow essentially *every* implementation to benefit from the SCSV, I
> wouldn't want to require any higher version.

OK.

Cheers,
Brian

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 14 Oct 2014 03:08:32 +0200

> initiate

> I agree. But, my conclusion is that the TLS specification is wrong,

Got it; sorry for being slow.

Here's one way to write that.

"If a client sends a ClientHello.client_version containing a lower value
than the latest (highest-valued) version supported by the client, it SHOULD
include the TLS_FALLBACK_SCSV cipher suite value in
ClientHello.cipher_suites. (...)

Sometimes, a client assuming that it already knows the highest protocol
version supported by a server (such as when resuming a session) may
initiate the connection in that native protocol as per Appendix E.1 of
[RFC5246]. In this situation, as an exception to the above, the client MUST
NOT include TLS_FALLBACK_SCSV in ClientHello.cipher_suites (unless it
downgrades ClientHello.client_version further in additional connection
attempts), since server-side support of protocol versions may have changed
since the previous connection.

(To avoid perpetuating use of an earlier protocol version if the server in
question actually does get updated, such clients SHOULD time out knowledge
of the highest protocol version supported by the server. Also, any such
knowledge MUST be forgotten if the server ever sends an
inappropriate_fallback alert.)"

Bodo

---

From: Florian Weimer <[email-masked]>
Date: Wed, 15 Oct 2014 10:17:05 +0200

> This is an announcement for the working group last call for draft-ietf-tls-downgrade-scsv-00.  Please review the document and send your comments to the list by Friday, October 17, 2014.

I'm strongly against this proposal.  It severely punishes those who have 
correctly implemented the protocol all along by forcing them to upgrade 
their code base, for the benefit of those who fail to interoperate (or 
who want to interoperate with those who fail).

We need to get rid of broken implementation, not cater to them 
indefinitely.  With this mindset of unlimited workarounds, no protocol 
versioning mechanism (including the one proposed here) will ever work 
securely because implementations will be forced by overriding concerns 
to ignore protocol failures, against better judgment.

-- 
Florian Weimer / Red Hat Product Security

---

From: Fabrice <[email-masked]>
Date: Wed, 15 Oct 2014 01:50:13 -0700

> On Oct 15, 2014, at 01:17, Florian Weimer <[email-masked]> wrote:
> 
> I'm strongly against this proposal.  It severely punishes those who have correctly implemented the protocol all along by forcing them to upgrade their code base, for the benefit of those who fail to interoperate (or who want to interoperate with those who fail).

I don't see how this force anybody to implement this or punish anybody who doesn't. 

Even if the majority of implementations were to implement this, they would still interoperate with the ones that don't implement it.

> 
> We need to get rid of broken implementation, not cater to them indefinitely.  With this mindset of unlimited workarounds, no protocol versioning mechanism (including the one proposed here) will ever work securely because implementations will be forced by overriding concerns to ignore protocol failures, against better judgment.

Unfortunately, interop with broken systems is pretty much a requirement in many cases. 
Without the workarounds such as retry and fallbacks, I believe the adoption of newer, more secure, version of TLS would be even slower. Catering to broken implementation may actually help in the long term, I think.

-- Fabrice

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 15 Oct 2014 11:22:51 +0200

Note that if your server does not support formally obsolete protocol
versions, TLS_FALLBACK_SCSV support is a no-op.

Otherwise, you're making real-world tradeoffs, and I think
TLS_FALLBACK_SCSV is a reasonable one to make (with minimal server-side
logic to achieve the objective), not "punishment".

Bodo

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 15 Oct 2014 05:25:17 -0400

> Otherwise, you're making real-world tradeoffs, and I think TLS_FALLBACK_SCSV is a reasonable one to make (with minimal server-side logic to achieve the objective), not "punishment".

Agreed.  And in fact, the quality of the protocol implementation doesn't enter into it.  It's more about the quality of the protocol.

	/r$

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

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 15 Oct 2014 13:03:57 +0200

> I don't see how this force anybody to implement this or punish anybody who doesn't. 

Of course, but then what is the point of standardizing it? In any case,
I don't believe how adding support for this extension on every
implementation (in order for the protection to matter) is easier than
fixing the few broken servers that don't properly do version
negotiation. I believe there is little point for this protocol
extension, given that the work arounds for the applications that use
non-standard version negotiation are very straightforward (disable SSL
3.0).

regards,
Nikos

---

From: Hanno Böck <[email-masked]>
Date: Wed, 15 Oct 2014 14:01:58 +0200

Am Wed, 15 Oct 2014 11:22:51 +0200
schrieb Bodo Moeller <[email-masked]>:

> TLS_FALLBACK_SCSV is a reasonable one to make (with minimal
> server-side logic to achieve the objective), not "punishment".

Can you quantify that tradeoff? How many devices are there really out
there that would break? I'd like to have this discussions with
hard numbers.

I mean we are not talking about legacy compatibility. We're talking
about compatibility with broken stuff.

I want to weight my voice in support of Florian. What we have here is
an out-of-protocol workaround with security and compatibility
implications and a solution that adds another workaround on top of that.

To compare the two:

One solution (keeping downgrade-workarounds and add SCSV):
* Compatiblity with a likely small number (but I'm waiting for hard
  numbers here) of broken legacy hard/software
* Add more complexity to TLS
* Support people who deploy broken stuff, punish people who support
  completely correct configs

Other solution (remove downgrade-workarounds):
* Break some compatiblity with broken devices
* Reduce complexity of TLS in browsers
* Support people who deploy correct implementations, punish people who
  support broken stuff

I think the argument is clearly in favor of the latter solution unless
you have some very good counterarguments.

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

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

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 15 Oct 2014 14:02:19 +0200

Nikos Mavrogiannopoulos <[email-masked]>:

In any case,
> negotiation.

Getting *every* implementation updated certainly is not easier. The
difference is that you don't have to -- the SCSV can be used (and indeed
*has* successfully been used) to protect against potential attacks when
connecting to servers that have been updated, while still allowing clients
to have kludgey interoperability with broken servers if they'd rather have
(potentially lower-security) connections to those than no interoperability
at all. As you know, browser implementors have widely seen a need for this.

At the same time, I completely agree that the broken servers must be shut
down too; but it's not either-or.

I believe there is little point for this protocol
> non-standard version negotiation are very straightforward (disable SSL

Note that the SCSV is not tied to a particular protocol version. Also, we
see the step of disabling SSL 3.0 taken as a concrete *response* (while
still allowing downgrades to any TLS versions that clients may be willing
to fall back to). The SCSV can be used to protect against downgrade attacks
in general, *preventively*.

So unless you disables all protocol versions below TLS 1.2 now, supporting
the SCSV has demonstrable advantages in protecting against potential
attacks.

Bodo

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 15 Oct 2014 08:19:59 -0400

> Can you quantify that tradeoff? How many devices are there really out there
> that would break? I'd like to have this discussions with hard numbers.

We (Akamai) see less than 1% SSLv2 and SSLv3 traffic globally and it's concentrated to a few particular clients.  Those clients are important to some customers. They want modern browsers to be protected, by not falling back to SSLv3, but they don't want to cut off those legacy clients.  SCSV fallback solves that problem. It also will solve a problem when some browsers try to use TLS 1.3 but servers haven't been updated.

Does that help?

---

From: CodesInChaos <[email-masked]>
Date: Wed, 15 Oct 2014 14:28:37 +0200

I think the question is about the number of buggy servers (and I think
firewalls or proxies) that don't implement version negotiation
correctly and thus cause clients which want to interoperate with them
to do the risky downgrade retry dance.

---

From: Hanno Böck <[email-masked]>
Date: Wed, 15 Oct 2014 14:36:11 +0200

Am Wed, 15 Oct 2014 08:19:59 -0400
schrieb "Salz, Rich" <[email-masked]>:

> We (Akamai) see less than 1% SSLv2 and SSLv3 traffic globally and
> it's concentrated to a few particular clients.  Those clients are
> important to some customers. They want modern browsers to be
> protected, by not falling back to SSLv3, but they don't want to cut
> off those legacy clients.  SCSV fallback solves that problem. It also
> will solve a problem when some browsers try to use TLS 1.3 but
> servers haven't been updated.

That's not really the point we're talking about.
SCSV is as far as I understood not to support SSLv2/3. SSLv3 should be
almost dead after POODLE (and I don't shed a tear).

What SCSV is about is a workaround to a workaround to support
servers that don't support in-protocol-downgrades. I think this has
been called "Protocol version intolerance" in the past (however I think
"protocol version breakage" would be a better term).

So the number I want to see is: How many servers are there that are not
capable of correctly negotiating the SSL/TLS versions they support?

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

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 15 Oct 2014 08:43:17 -0400

> capable of correctly negotiating the SSL/TLS versions they support?

That's not the question that SCSV is trying to address.

The question is:  how many clients end up using SSLv3 when the could use something better?

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 15 Oct 2014 14:54:24 +0200

> We (Akamai) see less than 1% SSLv2 and SSLv3 traffic globally and it's concentrated to a few particular clients.  Those clients are important to some customers. They want modern browsers to be prot…

No, it is irrelevant. What matters for this decision are how many TLS
negotiation intolerant servers are out there.

regards,
Nikos

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 15 Oct 2014 08:58:09 -0400

> negotiation intolerant servers are out there.

Sorry, I don't know what this means.

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 15 Oct 2014 14:59:59 +0200

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

> there that would break? I'd like to have this discussions with

Finding hard numbers is, well, hard. In general, you find out the whole
picture about what you've broken only after you've broken it.

That doesn't mean that people aren't trying to get good estimates (Ivan
Ristic has done some data collection -- I've include some of his results in
slide 2 of http://www.ietf.org/proceedings/90/slides/slides-90-tls-0.pdf).
However, this doesn't cover other use cases such as an old printer on your
LAN with an SSL 3.0 admin interface.

One solution (keeping downgrade-workarounds and add SCSV):
[...]

[...]

> you have some very good counterarguments.

I don't agree with the premise of your reasoning, because these two
approaches are in fact not mutually exclusive. Yes, we should get rid of
downgrade workarounds (browser vendors have been struggling with this for
years). At the same time, the SCSV offers us a general and simple way to
avoid security vulnerabilities when we fail to achieve perfection in that
area.

Less importantly, you've also not considered the complete incentive (or
disincentive, aka "punishment") structure. Disabling the downgrade dance in
one browser could drive that browser's users to a different browser that
"just works" (because it still willingly downgrades itself), which wouldn't
help anyone. In any case, the downgrade dance always punishes broken sites
with bad latency.

Bodo

---

From: Tom Ritter <[email-masked]>
Date: Wed, 15 Oct 2014 08:41:19 -0500

> * Support people who deploy correct implementations, punish people who

I think the last bullet may also be stated as "punish users trying to
connect to broken stuff".  As Bodo mentioned, browsers would like to
remove protocol downgrades, partly because they represent a security
vulnerability.  But the priority is to users and not breaking the
Internet in these situations (hard-fail OCSP is another example, CA
blacklisting a third).  The constraint we have (putting up with the
downgrade dance) means we have two options: deploy this SCSV and
protect your users, or do not deploy it and don't.

It's fair to reject the constraint and push for a more perfect
protocol, and in some situations I agree with you.  In this situation,
I accept the dirtiness in the interest of providing a way to protect
users.  Perhaps this should be "Informational" or "Experimental" to
try and isolate it from TLS? But regardless, I would like to see it
documented, implemented, and deployed.

-tom

---

From: Florian Weimer <[email-masked]>
Date: Wed, 15 Oct 2014 17:14:23 +0200

> versions, TLS_FALLBACK_SCSV support is a no-op.

No, only if you support exactly a single TLS version.  Then the presence 
of TLS_FALLBACK_SCSV support in the server code is indeed unobservable.

(As long as the presence of this feature is observable, server operators 
will be bullied into implementing it, with broken network-based testers 
etc.  It's not really optional.)

> logic to achieve the objective), not "punishment".

It's still punishes those who are responsible netizens and can update 
their servers—simply because they have to apply an update.  Their client 
base doesn't even directly benefit from that, it's just to enable their 
clients to preserve their own brokeness, so that they can continue to 
connect to broken servers that may or may not be out there.

Meanwhile, those who operate TLS-version-intolerant servers have to 
do—nothing.  That's what I find unfair and unsustainable.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 15 Oct 2014 17:20:09 +0200

> The question is:  how many clients end up using SSLv3 when the could use something better?

But the new SCSV will make things worse for accidental protocol 
downgrades (which happen quite frequently with Firefox, it seems).  What 
is now a protocol downgrade will turn into a hard connection failure.

Will the new SCSV enable additional clients to switch on more recent TLS 
versions by default?  I don't think so—you'd still need to code the 
fallback logic separately and outside of the TLS implementation (e.g., 
to support things like STARTTLS, which the TLS implementation typically 
doesn't know about).

---

From: Florian Weimer <[email-masked]>
Date: Wed, 15 Oct 2014 17:24:07 +0200

On 09/26/2014 08:37 PM, Adam Langley wrote:
> If an administrator is worried that version x is too weak, then all
> versions <= x need to be disabled too I believe? I can't think of a
> security concern that is not monotonic with respect to TLS versions.

An administrator may want to support local security services and run 
specific protocol versions and ciphers for which the security services 
have interception capabilities, to cut down the legal paperwork. :-)

---

From: Florian Weimer <[email-masked]>
Date: Wed, 15 Oct 2014 17:35:17 +0200

On 10/11/2014 08:36 AM, Andrey Jivsov wrote:
>> This is an announcement for the working group last call for
>> draft-ietf-tls-downgrade-scsv-00.  Please review the document and send
>> your comments to the list by Friday, October 17, 2014.
>>
>> Thanks,
>> J&S
>
>
>> 3. Server behavior
>

This scenario is described here:

<https://bugzilla.mozilla.org/show_bug.cgi?id=450280>

SCSV implementation would make things worse for Firefox users because it 
results in a reliable connection failure instead of a downgrade from TLS 
1.1 to TLS 1.2.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 15 Oct 2014 17:41:34 +0200

> This is an announcement for the working group last call for draft-ietf-tls-downgrade-scsv-00.  Please review the document and send your comments to the list by Friday, October 17, 2014.

One more issue: The draft is silent on how to respond to an 
inappropriate_fallback alert.  Considering that the draft was prompted 
by inappropriate responses to handshake alerts (and network failures 
during the handshake), this omission is curious.

Will we add

         TLS_FALLBACK_NO_THIS_TIME_I_REALL_MEAN_IT_SCSV   {0x56, 0x01}

in a few months or years?  Where does it end?

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 15 Oct 2014 12:08:15 -0400

> results in a reliable connection failure instead of a downgrade from TLS

Yes, exactly.  If a browser is going to fallback, it could ask the user "I'm going to retry, and you'll lose PFS; if the server is ever cracked by the NSA all your data will be readable.  Proceed?" If the usre clicks yes, then the browser tries again with the fallback SCSV.   (I would hope that the user-agent would provide more understable message, but I'm not optimistic.)

The point kis that a transient network error has highly visible security implications.

HTTP doesn't auto-retry, either.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 15 Oct 2014 18:11:11 +0200

> HTTP doesn't auto-retry, either.

I was trying to point out that HTTPS in Firefox actually did retry, in 
many cases successfully, and now it doesn't (attempts to retry will fail 
consistently).  That smells like a regression in the making.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 15 Oct 2014 12:12:01 -0400

> Yes, exactly.  If a browser is going to fallback, it could ask the user "I'm going
> to retry, and you'll lose PFS; if the server is ever cracked by the NSA all your
> data will be readable.  Proceed?" If the usre clicks yes, then the browser tries
> again with the fallback SCSV.   (I would hope that the user-agent would
> provide more understable message, but I'm not optimistic.)

Arrgh.  Tries again WITHOUT the fallback SCSV.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 15 Oct 2014 12:13:28 -0400

It retried because there was no way to indicate "let me try again with older version"  Now there is a way to indicate that this is happening.  Servers who support better protocols will reject the connection because the browser might be unwittingly giving up valuable security properties.  Servers who don't support better protocols will complete the handshake.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 15 Oct 2014 18:25:30 +0200

> It retried because there was no way to indicate "let me try again with older version"  Now there is a way to indicate that this is happening.  Servers who support better protocols will reject the c…

Sorry, but please review the Mozilla bug and re-read what I wrote.  I 
have a feeling that we both are talking about different things.

I'm concerned that a straightforward implementation of this new SCSV in 
Firefox will introduce user-visible connection failures when the 
downgrade is caused by a (likely spurious) networking event.  It's true 
that this network failure could be introduced deliberately by an on-path 
attacker (but even the SCSV design assumes that's rare*).  It's also 
true that an attacker can disguise most attacks as networking anomalies. 
  But it's unfortunate that this SCSV has such a broad area of ambiguity 
which does not help with browser UI design at all.

I understand that the ship has sailed on this one, and that we cannot 
change the protocol anymore.  So publishing the RFC seems unavoidable at 
this point, if only to ensure the codepoint reservations stick.

*) Deploying an SCSV-enabled browser to users on an intercepting network 
will largely knock these users off the net (assuming that SCSV support 
is widely deployed in public-facing TLS termination), so such attacks 
are hopefully very isolated, or else it's not possible to deploy this 
feature in browsers.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 15 Oct 2014 12:29:22 -0400

A spurious network event that gave up security properties SHOULD NOT quietly give those up on behalf of the user.

I betcha browsers soon retry with their best version, before decided when/how to fallback.

Network hiccups happen all the time. For plaintext protocols they are benign. For security protocols that would silently give up features they are not.

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 15 Oct 2014 18:52:17 +0200

I was teasing. So far at least, every new protocol version has formally
obsoleted the previous version, so we've only ever had a single
non-deprecated TLS version.

Real life, necessarily, is a different matter; that's the real point I
wanted to make.

This is right, but I don't consider it "punishment". (And in practice,
you'll have to apply occasional  implementation bugfix updates anyway, and
the protocol change may not pose any extra effort.)

> Meanwhile, those who operate TLS-version-intolerant servers have to
do—nothing.

If you insist on "punishment", the very least happening to them is an
increased rate of incoming connections, and increased latency for their
users. There are no technical means to force them to address that if they
don't care about their users, but in that case, what could you do?

Bodo

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 15 Oct 2014 18:55:36 +0200

That is (well, *was*) a clear bug in that particular implementation.

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 15 Oct 2014 20:09:41 +0200

> One more issue: The draft is silent on how to respond to an
inappropriate_fallback alert.

No, it is expressly a fatal alert. What else do you think would need to be
said?

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 15 Oct 2014 20:09:42 +0200

> I'm concerned that a straightforward implementation of this new SCSV in
Firefox will introduce user-visible connection failures when the downgrade
is caused by a (likely spurious) networking event.

This is similar to spurious network failures if you didn't have fallback
retries at all. The details of how browsers do or do not retry in response
to network glitches certainly are out of score for this spec.

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 15 Oct 2014 20:09:42 +0200

> *) Deploying an SCSV-enabled browser to users on an intercepting network
will largely knock these users off the net (assuming that SCSV support is
widely deployed in public-facing TLS termination), so such attacks are
hopefully very isolated, or else it's not possible to deploy this feature
in browsers.

Thanks for the value proposition, by the way :-)

Preventing such attacks, of course, is what we consider a feature. Google
servers support the SCSV, and so does the Chrome browser; so we have the
required real-life experience indicating that deploying the SCSV is
practical.

Bodo

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Oct 2014 11:24:12 -0700

> required real-life experience indicating that deploying the SCSV is

And I'd like to add that the SCSV has been in Firefox Nightly for a
while now.  We got some early reports of problems because of the way
we were reacting to spurious fallbacks, but that has been addressed
and I've not seen any subsequent reports of problems.

This is a strictly good feature for Firefox users.  The alternative
(disable insecure version intolerant fallback entirely) is completely
untenable for us.  If you personally don't like that, I've a patch
that allows users to disable fallback.  That should be landing
shortly.

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Wed, 15 Oct 2014 20:26:37 +0200

> No, it is expressly a fatal alert. What else do you think would need to be
Maybe the draft could mention that after aborting the downgraded connection due
to this fatal alert, clients may want to retry with the original version?

Manuel.

---

From: [email-masked] (Martin Rex)
Date: Wed, 15 Oct 2014 20:52:16 +0200 (CEST)

Florian Weimer wrote:
> Joseph Salowey (jsalowey) wrote:
>>
>> draft-ietf-tls-downgrade-scsv-00.  Please review the document
>> and send your comments to the list by Friday, October 17, 2014.
> 
> I'm strongly against this proposal. 

I'm also strongly opposed to this proposal, because it does not provide
any value--there is not one single *additional* TLS handshake that it
will make succeed, instead, the only thing that this proposal will
provide is either zero benefit or fatal interop failure, i.e. it
if there is any result from it it will be headaches to users, sysadmins
and helpdesks.

This proposal is as far opposite from the spirit of the IETF as
one can possibly get.

What we would need instead of this proposal, is one that will

  (1) make more TLS handshakes succeed

  (2) make more TLS handshakes succeed with new protocol features

  (3) make more TLS handshakes succeed with new protocol features
      for regular app clients that do not have re-connect fallback in place,
      and _without_ interfering with conservative ClientHellos that these
      clients use to maintain interop with old, "broken" servers out there.

The "downgrade-scsv" has the effective semantics of
"kick me if you can read this", which is pretty silly on my scorecard.

A reasonable alternative SCSV would have the semantics
"Dear Server, I'm a new, full-featured client and would really like
to send you a full-featured ClientHello, but didn't dare doing as
the first message on the connection because of all the old broken
servers out there which choke on feature-rich ClientHellos".

And a new Server's response to such an SCSV should be to
respond with a ServerHello+ServerHelloDone which carries the SCSV
in the ServerHello.cipher_suite = SCSV, which the client will
recognize and understand as an invitation to send the desired
full-featured ClientHello (on the very same existing connection
transparently).

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Wed, 15 Oct 2014 12:02:51 -0700

> full-featured ClientHello (on the very same existing connection

This proposal looks to me to be clearly better theoretically. It's more
robust in the face of transient network issues. OTOH, if the practical
difference is minor, I'd rather get done sooner than later. I'm also by no
means knowledgeable about the impact on stateful firewalls expecting to see
TLS with a particular flow, or if this even is an issue.
>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/
<https://www.ietf.org/mailman/listinfo/tls>tls

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 15 Oct 2014 21:19:42 +0200

"Martin Rex" <[email-masked]>:

> will make succeed,
[...]

> full-featured ClientHello (on the very same existing connection

Improving interoperability per se certainly is not a goal of our spec
(instead, it's all about breaking interoperability with attackers if you
will).

That doesn't mean that avoiding the need for fallback retries isn't a
worthy goal, it just is completely orthogonal to what TLS_FALLBACK_SCSV
does. We give you a spec that you can deploy right to gain actual security
advantages (unless your clients never do fallback retries), where the
solution you sketch would be much more involved.

Once anything like what you propose gets successfully rolled out, there
would be no more need to send our SCSV, and the (simple!) server-side logic
would then lie dormant. However I think it's pretty clear that that day is
still pretty far away -- certainly far enough to warrant taking other
measures of protection.

Your claim that TLS_FALLBACK_SCSV
"does not provide any value" appears blatantly untrue, unless you don't
recognize preventing demonstrated attacks as "value".

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 15 Oct 2014 21:27:33 +0200

> to this fatal alert, clients may want to retry with the original version?

Hm -- probably probably not in this form as the specification doesn't say
that or how you should retry, but we could point out that network glitches
could result in seeing the alert on a fallback retry (so that implementors
can take this into account for whatever it is that they need to achieve).

---

From: Brian Smith <[email-masked]>
Date: Wed, 15 Oct 2014 13:39:19 -0700

> This is an announcement for the working group last call for draft-ietf-tls-downgrade-scsv-00.  Please review the document and send your comments to the list by Friday, October 17, 2014.

It seems like the draft should also advise clients that they MUST NOT
do the False Start optimization if the server does not choose the
maximum version of TLS that they support. For example, if the server
chooses a version less than ClientHello.client_version, or if the
client sent the TLS_FALLBACK_SCSV, then the client MUST NOT false
start. Currently the draft says nothing about this. Because of False
Start, there are several downgrades that are still possible even with
the current downgrade-SCSV-enabled Chrome and Firefox, for example.

1. During a False Start handshake, the MitM can remove the
TLS_FALLBACK_SCSV from the ClientHello, so that the server cannot
detect the version downgrade. The client will only be able to detect
this tampering once it has processed the server's Finished message.
But, by then, it has already sent application data using the
downgraded version.

2. Similarly, the MitM can tamper with ClientHello.client_version in a
ClientHello regardless of whether it has the TLS_FALLBACK_SCSV in it,
and a client that does the False Start optimization won't notice the
tampering until after it has sent some application data.

3. Even without tampering with TLS_FALLBACK_SCSV or
ClientHello.client_version, a MitM can easily degrade the cryptography
on a connection. For example, let's say a server supports ECDHE with
P-256 and DHE with 1024-bit keys. A P-256 key is much stronger than a
DHE-1024 key. If an attacker removes P-256 from the client's
supported_curves extension, then the server will choose a DHE-1024 key
in the handshake, even with TLS 1.2. This type of downgrade could have
a much bigger effect than a downgrade from TLS 1.2 to TLS 1.1.

In all these cases, the server won't process the client's application
data, because the server will detect the tampering before processing
it (because it processes the client's Finished message before it
processes the application data). But in theory there may be attacks
where just sending the initial application data in a downgraded
version would be a security problem. For example, when it is clear to
everybody that SHA-1 is broken, non-secure downgrades from TLS 1.2 to
TLS 1.1 alone will be a severe security problem. If these attacks are
out of scope, then the document should say so. Otherwise, they should
be addressed.

In summary, the way it is defined, the downgrade SCSV is only helpful
in preventing a limit number of unspecified downgrade attacks when
used in conjunction with False Start. Also, the draft is based on the
premise that preventing version downgrade is useful for preventing
some cryptographic attacks, but it does not substantiate that. POODLE
and BEAST are evidence that the mechanism helps for some attacks. But,
is this mechanism actually effective for preventing any other class of
attacks, other than TLS 1.1 -> TLS 1.0 -> SSL 3.0 downgrade for CBC
cipher suites? The answer to this should be in the security
considerations.

I don't think it makes sense to consider False Start out of scope for
this, because all the browsers that are doing the non-secure version
fallback are also doing the False Start optimization.

Cheers,
Brian

---

From: Brian Smith <[email-masked]>
Date: Wed, 15 Oct 2014 13:42:18 -0700

On Wed, Oct 15, 2014 at 5:19 AM, Salz, Rich <[email-masked]> wrote:
> We (Akamai) see less than 1% SSLv2 and SSLv3 traffic globally and it's concentrated to a few particular clients.  Those clients are important to some customers. They want modern browsers to be protected, by not falling back to SSLv3, but they don't want to cut off those legacy clients.  SCSV fallback solves that problem.

That problem is also solved by the browsers simply not doing the
non-secure fallback to SSLv3.

> It also will solve a problem when some browsers try to use
> TLS 1.3 but servers haven't been updated.

If TLS 1.3 is still planning to use the version negotiation mechanism
to negotiate TLS 1.3, then that's a defect in TLS 1.3, for this
reason. That defect should be addressed so that the downgrade SCSV
will be a non-issue for TLS 1.3.

Cheers,
Brian

---

From: Brian Smith <[email-masked]>
Date: Wed, 15 Oct 2014 14:13:53 -0700

> is caused by a (likely spurious) networking event.

First, Mozilla publishes some data regarding non-secure version
fallback at [1]. (The UI is terrible, but there is an option to get
the raw data in tabular form on the right hand side of the page). You
can see the key for that data in the source code at [2].

Anyway, Firefox needs to stop doing the non-secure version fallback in
the case of network failures. The overwhelming majority of TLS 1.2 ->
TLS 1.1 fallbacks in Firefox are due to server closing the connection
during the handshake. Probably in the vast majority of those cases,
the closed connection is not actually indicating version intolerance.
The second most common case of fallback is receiving a RST. Again, the
vast majority of those RSTs are probably not actually caused by
version intolerance. These two conditions make up about 99% of the
reason for fallback in Firefox.

The problem is there are a very small number of servers that DO
indicate intolerance by closing the connection or with a RST. However,
I also agree with the others that say that it doesn't make sense for
browsers to ask every server to implement the downgrade SCSV to be
safe, because browsers don't want to break compatibility with this
tiny minority of old, broken servers.

My understanding is that the Chrome web browser is currently
experimenting in pre-release versions with not doing the non-secure
fallback from TLS 1.0 to SSL 3.0. I think all browsers should extend
that experiment to disabling the non-secure fallback mechanism
completely.

In particular, browsers should disable the non-secure fallback
mechanism completely before TLS 1.3 gets deployed, so that the TLS 1.3
design doesn't become unnecessarily reliant on the non-secure fallback
mechanism for compatibility. Otherwise, we may never be able to remove
it.

Cheers,
Brian

[1] http://telemetry.mozilla.org/#filter=release%2F32%2FSSL_TLS12_INTOLERANCE_REASON_POST
[2] https://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsNSSIOLayer.cpp?rev=916f2837201c#1047

---

From: Fahima Ahmed Khan Etha <[email-masked]>
Date: Thu, 16 Oct 2014 10:08:37 +0600

Dear All,

It might be an off topic. But I am seeking guidance from all of you.

If any hacker group claimed that you are hacked... How to proof or find out
its authenticity?

Please share your view.

Best regards,

Fahima

On 3 October 2014 23:09, Brian Smith <[email-masked]> wrote:

> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Florian Weimer <[email-masked]>
Date: Thu, 16 Oct 2014 11:03:00 +0200

On 10/15/2014 08:09 PM, Bodo Moeller wrote:
> "Florian Weimer" <[email-masked] <mailto:[email-masked]>>:
>
> No, it is expressly a fatal alert. What else do you think would need to
> be said?

If it were that clear, we wouldn't need this new SCSV at all because 
browsers would never have performed fallback in response to fatal alerts.

So far I've come up with the following questions:

Should the client continue to retry with lower TLS versions once it 
receives an inappropriate_fallback alert?

Should it retry without the SCSV?  I guess you mean "no way!", but this 
is only implicit.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 16 Oct 2014 12:06:11 +0200

> and I've not seen any subsequent reports of problems.

Interesting things will start to happen once there is TLS 1.3. 
TLS_FALLBACK_SCSV could really complicate its deployment.

> untenable for us.

Why do you think that?  Is this observation based on data tainted by the 
spurious downgrade bugs you had?  Do you know if the downgrades are due 
to server problems or interception by law enforcement?  (I suspect the 
latter would magically go away if you got rid of the fallback code.)

I just find it difficult to reconcile your decision to keep the fallback 
with the announcement to disable SSL 3.0 by default.  Surely the latter 
change is going to bite many users.  (I'm aware that fallback can still 
happen from one TLS version to another, that's not what puzzles me.)

---

From: Hubert Kario <[email-masked]>
Date: Thu, 16 Oct 2014 06:26:48 -0400 (EDT)

----- Original Message -----
> From: "Hanno Böck" <[email-masked]>
> To: [email-masked]
> Sent: Wednesday, 15 October, 2014 2:01:58 PM
> Subject: Re: [TLS] Working Group Last Call for	draft-ietf-tls-downgrade-scsv-00
> 

I don't have hard numbers for that (I'm +1 this request), but
looking forward, I see many servers that are TLS 1.3 intolerant while
randomly scanning servers using the ssllabs.com scanner.

So it's not only about servers that are TLS1.2 Client Hello intolerant
(they should be mostly eradicated from the public Internet by now)
but also possible future issues.

-- 
Regards,
Hubert Kario

---

From: Hubert Kario <[email-masked]>
Date: Thu, 16 Oct 2014 06:36:07 -0400 (EDT)

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

> From: "Bodo Moeller" <[email-masked]>
> To: [email-masked]
> Sent: Wednesday, 15 October, 2014 2:59:59 PM

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

> slide 2 of http://www.ietf.org/proceedings/90/slides/slides-90-tls-0.pdf )

nice 
so ~1% is intolerant to TLS1.1 
~1% is intolerant to 1.2 
and 11% is intolerant to 1.3 (!!) 

were there any servers intolerant to TLS1.0? 

-- 
Regards, 
Hubert Kario

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Thu, 16 Oct 2014 12:40:32 +0200

> TLS_FALLBACK_SCSV could really complicate its deployment.
I'm afraid I don't understand which interesting things you're referring to.
Could you please elaborate on that?

I can think of the following scenarios (assuming the client supports 1.3 and
FALLBACK_SCSV):

1. The server also supports 1.3, and no middleware is blocking it -> all good.

2. The server also supports 1.3, but some middleware/attacker is blocking it.
The client retries with 1.2+FALLBACK_SCSV.
	2a. The server also supports FALLBACK_SCSV. The MitM downgrade is avoided.
That's a feature.
	2b. The server doesn't support FALLBACK_SCSV. The MitM downgrade succeeds. Too bad.

3. The server doesn't support 1.3 but is version-tolerant (and so is all
middleware in path). 1.2 is negotiated using the intended mechanism -> all good.

4. The server doesn't support 1.3 but it (or some middleware/attacker) is
1.3-version intolerant. The client retries with 1.2+FALLBACK_SCSV. Regardless of
whether the server supports FALLBACK_SCSV, the handshake succeeds because 1.2 is
indeed the highest version supported by the server. (Assuming it's 1.2 for the
sake of simplicity, but it should work the same way for lower versions.)

What am I missing?

Manuel.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 16 Oct 2014 15:41:01 +0200

> I can think of the following scenarios (assuming the client supports 1.3 and

A widely-deployed client might use TLS 1.2 with FALLBACK_SCSV 
unconditionally.  This client would break once servers start supporting 
TLS 1.3.  That's just one example of what could go wrong which could not 
go wrong before.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 16 Oct 2014 09:44:37 -0400

> unconditionally.

A widely deployed client might also start injecting line noise into the TLS stream.

We can't control what buggy clients do.  That's not new.

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Thu, 16 Oct 2014 15:48:00 +0200

> TLS 1.3.  That's just one example of what could go wrong which could not 
I'm sorry, but wouldn't that be very stupid of the client? Maybe the draft could
include wording that clients MUST NOT do that, to be extra clear, but IMHO it's
already quite clear.

Besides clients doing this stupid thing, do you see other bad things related to
FALLBACK_SCSV that could happen when TLS 1.3 will start being deployed?

Manuel.

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 16 Oct 2014 15:54:11 +0200

Florian Weimer <[email-masked]>:

 > One more issue: The draft is silent on how to respond to
>> an inappropriate_fallback alert.
>>
>

> Should it retry without the SCSV?  I guess you mean "no way!", but this is
> only implicit.

I see. The current I-D indeed doesn't say that you can't continue to retry
with lower versions in response to inappropriate_fallback, but I see no
need for normative language on that (it seems stupid, but not harmful). It
still can't hurt to mention that point, I guess.

Retry without SCSV in response to inappropriate_fallback? Here the same
SHOULD NOT applies as for the previous attempt, and I fail to see why
anyone would decide that doing the additional retry without SCSV could be
acceptable if they understand the full implications and carefully weigh the
case, so again I see no need to change the normative language. But then if
you honestly believe that the current language invites misguided
implementors to retry without SCSV, I wouldn't be opposed to adding an
explicit MUST NOT for that case.

Bodo

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 16 Oct 2014 09:57:02 -0400

> Should the client continue to retry with lower TLS versions once it receives an
> inappropriate_fallback alert?

Sure, if it likes  being told no over and over again. :)

> Should it retry without the SCSV?  I guess you mean "no way!", but this is

I disagree with Bodo.  It's a user-agent issue. A browser might pop up a warning about the loss of privacy features and ask if it should proceed.

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 16 Oct 2014 15:36:52 +0200

> the current downgrade-SCSV-enabled Chrome and Firefox, for example.

This is a valid concern about the interaction of allowing fallback protocol
versions (whether using the normal version negotiation mechanism, or
fallback retries) with False Start. Obviously the False Start spec already
covers such aspects on a general level (do not use False Start unless the
symmetric cipher is cryptographically strong, etc.), but points such as the
one that older protocol versions may have *no* sufficiently secure cipher
suites at all are not made explicit.

This isn't specific to fallback retries and certainly not to the
TLS_FALLBACK_SCSV mechanism (it's exactly the same with the standard
mechanism for protocol version negotiation), so I think an updated version
of the False Start specification would be the right place to set any strict
requirements for this. However, it would make sense to *mention* and
discuss this aspect in the TLS_FALLBACK_SCSV document (non-normatively).

[As for the specifics, while I think this isn't really for the
TLS_FALLBACK_SCSV specification to define, allowing False Start only with
the *one* most recent protocol version appears too strict. Specifically,
while deployment of a new protocol version is underway, clients may want to
use False Start both with this new version and with the previous version --
why downgrade the overall experience for those who enable the latest
protocol version?]

> cipher suites? The answer to this should be in the security

Well, what makes the TLS_FALLBACK_SCSV mechanism particularly valuable is
that it can help protect you from attacks that no one is aware of yet. So
enumerating concrete attacks sort of would be missing the point:
TLS_FALLBACK_SCSV is mainly about those vulnerabilities that we *can't*
list there yet. I can tell you *now* how you would have benefited from
supporting TLS_FALLBACK_SCSV half a year ago.

The simplest argument in favor of preventing unwarranted fallback to
earlier protocol versions is that if we didn't think that the newer
versions were better, why would we be specifying them in the first place?

That said, the question whether the mechanism has relevance for weaknesses
other than those found in CBC cipher suites can be answered in the
affirmative. For example, if clients fall back to SSL 3.0 without TLS
extensions, they can't use ECDHE and thus may lose forward security.

Bodo

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 16 Oct 2014 16:04:07 +0200

> include wording that clients MUST NOT do that, to be extra clear, but IMHO it's

Of course, but isn't this issue that SCSV is trying to fix in the first
place? Isn't the SCSV's reason of existance the fact that there are some
buggy servers that cannot handle TLS protocol version negotiation? Why
should we assume that buggy clients are impossible to happen?

regards,
Nikos

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 16 Oct 2014 10:06:31 -0400

Buggy servers caused buggy clients which now caused silent loss of security properties.  SCSV fallback is an effective way to help break the cycle.

(And what are you RH folks drinking, anyway, to be so vehemently opposed? :)

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 16 Oct 2014 16:08:41 +0200

Salz, Rich <[email-masked]>:

> is

> I disagree with Bodo.  It's a user-agent issue. A browser might pop up a
> warning about the loss of privacy features and ask if it should proceed.

Good point. So there is indeed a potential scenario in which retrying
without the SCSV could be acceptable.

A "MUST NOT" for *automatic* such retries might be right, but then Rich's
example already shows that we'd probably be over-regulating by going into
such details. The current "SHOULD NOT" is quite clear -- implementors
*could* still get this wrong, but would adding a "MUST NOT" for retries of
retries really make any difference?

(We'd end up with a more complexly written spec, which is not desirable
without good justification.)

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 16 Oct 2014 10:19:21 -0400

> will be a non-issue for TLS 1.3.

Sorry, can you clarify what you mean by this?

What mechanism *should* peers use to negotiate TLS 1.3 if not the
standard TLS version negotiation mechanism?

How should we address this in TLS 1.3?

	--dkg

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Thu, 16 Oct 2014 16:19:58 +0200

> should we assume that buggy clients are impossible to happen?
That's probably a good argument for mentioning it explicitly in the spec.

Maybe also mention that TLS implementations must not include this SCSV unless
explicitly requested to do so by the application, to prevent false good ideas
such as "let's include FALLBACK_SCSV automatically when the version we're
offering is less than the highest version we support" (which also should be
clear by reading the spec, but who knows).

I might be overly optimistic, but I hope that people implementing client
work-arounds made necessary by the existence of buggy servers are able and
willing to correctly implement a short a simple spec without adding bugs.

Manuel.

---

From: Hubert Kario <[email-masked]>
Date: Thu, 16 Oct 2014 10:28:25 -0400 (EDT)

----- Original Message -----
> From: "Manuel Pégourié-Gonnard" <[email-masked]>
> To: "Florian Weimer" <[email-masked]>, "Martin Thomson" <[email-masked]>, "Bodo Moeller"
> <[email-masked]>
> Cc: [email-masked]
> Sent: Thursday, 16 October, 2014 3:48:00 PM

I don't see any.

Both NSS and OpenSSL when they receive TLS1.2 client hello with this SCSV
accept and continue connection.

Both NSS and OpenSSL when they are limited by configuration to a lower protocol
version (e.g. TLS1.0) and receive Client Hello with the same or higher version
and this SCSV accept the connection.

In other words. If, for any reason, a future client (one that supports TLS1.3)
decides that it needs to downgrade the connection (and indicate that by adding
the SCSV) to interoperate with current implementations, it will work correctly.

Of course, if a client sets this SCSV always, even on first connection attempt,
then it will fail after the server upgrades to TLS1.3, or it uses the library
that doesn't support higher protocol versions (like 0.9.8), but that's
incorrect use of the SCSV.
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: [email-masked]
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Hubert Kario <[email-masked]>
Date: Thu, 16 Oct 2014 10:30:44 -0400 (EDT)

----- Original Message -----
> From: "Hubert Kario" <[email-masked]>
> To: "Manuel Pégourié-Gonnard" <[email-masked]>
> Cc: "Florian Weimer" <[email-masked]>, [email-masked]
> Sent: Thursday, 16 October, 2014 4:28:25 PM
> > To: "Florian Weimer" <[email-masked]>, "Martin Thomson"
> > <[email-masked]>, "Bodo Moeller"
> > <[email-masked]>
> > Cc: [email-masked]
> > Besides clients doing this stupid thing, do you see other bad things
> > related
> > to

like openssl 0.9.8*

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 16 Oct 2014 16:34:11 +0200

> should we assume that buggy clients are impossible to happen?

It's not *completely* inconceivable that this could happen -- regardless of
which client or server behavior is newly introduced, there's always *some*
chance that it might not work well with some buggy peer.

When writing the TLS_FALLBACK_SCSV specification, I was thus aiming to keep
it simple enough so that implementors would be extremely unlikely to get it
wrong (at least once there's some base deployment of clients and servers so
that basic interoperability tests will immediately expose large classes of
potential bugs, which should by now be the case). Do you seriously think
that implementors might end up sending TLS_FALLBACK_SCVS unconditionally?
If so, do you think that those implementors would be capable of avoiding
other more subtle bugs, and overall to create a mostly usable and possibly
even reasonably secure product? (I can't help thinking that if a client is
*that* broken, we'd probably be doing its users a favor by having all
handshakes fail.)

More importantly, if there were no fallback retries and thus no need for
TLS_FALLBACK_SCSV, how could that *possibly* make it *easier* to deploy TLS
1.3 given that buggy peers may be around?

Bodo

---

From: Florian Weimer <[email-masked]>
Date: Thu, 16 Oct 2014 16:55:04 +0200

On 09/26/2014 08:41 AM, Martin Thomson wrote:
> On 26 September 2014 05:00, Joseph Salowey (jsalowey)
> I've implemented this specification,

I have now implemented it as well.

One interoperability issue I encountered is that I initially sent a 
protocol version in the inappropriate_fallback alert that the OpenSSL 
client could not process because the protocol version had not been 
negotiated at this stage.  (This issue was also present in the code for 
the renegotiation SCSV.)  This is an ambiguity in the original TLS 
specification, I think, but perhaps the draft should say that you SHOULD 
send back the version used by the client.

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 16 Oct 2014 18:07:04 +0200

> negotiated at this stage.  (This issue was also present in the code for the
> renegotiation SCSV.)  This is an ambiguity in the original TLS

Thanks for the comment. Is this different from other fatal alerts that the
server might be sending in direct response to the ClientHello -- such as
handshake_failure, or even protocol_version?

Maybe it wouldn't hurt to explicitly say that if the client's version is
supported by the server but rejected due to the SCSV, that's the version to
use for the alert. But then record-layer version numbers are already a
muddy issue as is; I wouldn't want to specify side aspects of behavior that
may be incompatible, or utterly confusing if read in conjunction, with the
guidance on record-layer version numbers provided by the TLS specifications.

Bodo

---

From: Henrik Grubbström <[email-masked]>
Date: Thu, 16 Oct 2014 18:28:55 +0200

On Thu, Oct 16, 2014 at 6:07 PM, Bodo Moeller <[email-masked]> wrote:
>> protocol version in the inappropriate_fallback alert that the OpenSSL client
>> could not process because the protocol version had not been negotiated at
>> this stage.  (This issue was also present in the code for the renegotiation
>> SCSV.)  This is an ambiguity in the original TLS specification, I think, but
>> perhaps the draft should say that you SHOULD send back the version used by
>> the client.
>

Not as far as I can see.

> use for the alert. But then record-layer version numbers are already a muddy
> issue as is; I wouldn't want to specify side aspects of behavior that may be
> incompatible, or utterly confusing if read in conjunction, with the guidance
> on record-layer version numbers provided by the TLS specifications.

The way I've done it is to send early alerts as a packet with
min(client_version, server_max_version), as sending packets indicating
a newer version than the server actually supports seems a bit iffy. Of
course in the specific case of inappropriate_fallback and the
tls_fallback_scsv, for a correct server implementation the
client_version will always be less than the server_max_version as
otherwise the alert wouldn't be sent, so the two end up with the same
result.

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

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 16 Oct 2014 14:36:31 -0400

How can you always send SCSV when the darn name says “FALLBACK” ???

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 16 Oct 2014 11:42:40 -0700

> How can you always send SCSV when the darn name says “FALLBACK” ???

In the same way you can stab yourself repeatedly in the eye with a sharp stick.

I'm not particularly interested in entertaining willful
misinterpretations.  I trust that Bodo can correct any egregious
errors or misleading text.

---

From: Brian Smith <[email-masked]>
Date: Thu, 16 Oct 2014 13:03:12 -0700

On Thu, Oct 16, 2014 at 6:36 AM, Bodo Moeller <[email-masked]> wrote:
> requirements for this. However, it would make sense to *mention* and discuss
> this aspect in the TLS_FALLBACK_SCSV document (non-normatively).

If version downgrades during False Start are to be tolerated, then at
a minimum the security considerations of this draft must point out
that the mechanism is simple to subvert (partially, at least) when
False Start is used.

> why downgrade the overall experience for those who enable the latest

My point is that, because the clients that do the non-secure fallback
are also doing false start, without some version negotiation
restrictions for false start, the server still has no control over the
minimum version of TLS that will be used, even if they implement the
downgrade SCSV as specified. Right now it isn't a known emergency
because browsers (at least Firefox and Chrome) don't allow a MitM to
downgrade a connection to SSL 3.0 during false start. However, what if
the server administrator wants to be more cautious than browsers are?

It is true that, as the TLS 1.3 draft is currently written, browsers
will have to do non-secure fallback to TLS 1.2 often when they enable
TLS 1.3. I agree, given that current situation, that that is something
that should be allowed. But, I disagree that it should be allowed to
let a MitM downgrade a connection all the way to TLS 1.0 w/ the False
Start mechanism, especially when the server has implemented the
downgrade SCSV in an attempt to prevent that.

> TLS_FALLBACK_SCSV is mainly about those vulnerabilities that we *can't* list
> there yet. I can tell you *now* how you would have benefited from supporting
> TLS_FALLBACK_SCSV half a year ago.

Besides POODLE and BEAST? I do think it would be good to see some more examples.

Anyway, I'm not asking you to enumerate every possible attack that is
prevented with this mechanism. I'm asking for the downgrade SCSV
mechanism to be improved to prevent more attacks, or at least for the
limitations of the dowgrade SCSV mechanism to be documented more
clearly.

> extensions, they can't use ECDHE and thus may lose forward security.

No. When false start is allowed for RSA key exchange, the initial HTTP
request (including auth credentials), even if both sides implement the
downgrade SCSV correctly, an attacker can still force the client to
send the initial HTTP requests (with auth credentials) using a version
of its choosing and using RSA key exchange. In Chrome and Firefox, the
downgrade to RSA is prevented by their False Start policies, not by
the downgrade SCSV.

My point is that, without adding some restrictions on False Start, the
downgrade SCSV mechainsm is useless against any attack that would
succeed by being able to control what the client sends in its initial
application data. (Note that POODLE isn't such an attack, because it
only succeeds by being able to control what the server will decrypt,
not just what the client sends.)

Again, to be clear, I am not saving the downgrade SCSV is bad. I'm
saying it is surprising that the downgrade SCSV doesn't prevent
version downgrades, and that should be fixed.

Cheers,
Brian

---

From: Andrey Jivsov <[email-masked]>
Date: Fri, 17 Oct 2014 00:59:59 -0700

(On handling of the downgrade to a recent versions of the protocols, 
i.e. TLS1.3 to 1.2 or TLS1.2 to TLS1.1.)

Today, for example,

    www.wellsfargo.com, citibank.com, and bankofamerica.com don't 
support TLS 1.1 and

    mozilla.com doesn't support TLS 1.2.

The draft -00 asks the server supporting TLS 1.2 to fail the TLS 1.1 in 
some cases, while significant amount of traffic on the Internet goes 
over TLS 1.0.

I propose the following change that allows to do exactly what rev -00 
says, but now enables more tolerant server behaviour.

The text captures the need to be more forceful on the lower (insecure) 
end of the SSL2.0 - TLS1.2 range, while being more tolerant with more 
recent (secure) versions.

 > 3. Server behaviour
 >
 > This section specifies server behaviour when receiving the
 > TLS_FALLBACK_SCSV cipher suite from a client in
 > ClientHello.cipher_suites.
 >
> When TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the
> highest version of the protocol supported by the server is greater
> than the version indicated in ClientHello.client_version, this is an
> indication to the server that the client chose lower version of the
> protocol in its ClientHello message than the client is capable of
> negotiating.
 >
> When the server detects the above scenario, it MUST respond with an
> inappropriate_fallback alert when ClientHello.client_version
> indicates version <XXX> or lower and MAY respond with an
> inappropriate_fallback alert for higher versions of the protocol.

I would further propose to set <XXX> = SSL 3.0 and I accept to have it 
at TLS 1.0 as a second choice.

In the first case, it's easy to notice that if the server has disabled 
SSLv3 (and SSLv2) and tolerates TLS 1.0 and TLS 1.1, the server is 
compliant with the TLS_FALLBACK_SCSV.

If <XXX> = TLS 1.0, SSL3.0, SSL2.0 are disabled, the server may consider 
TLS 1.1 as acceptable (but also may choose to be intolerant of it + 
SCSV, although IMO this is undesirable today) but the server is required 
to issue inappropriate_fallback for TLS 1.0+SCSV. The server will need 
to implement parsing of SCSV in this case because it is required to 
distinguish TLS 1.0 from TLS 1.0+SCSV and have code to issue 
inappropriate_fallback.

Thank you.

---

From: Florian Weimer <[email-masked]>
Date: Fri, 17 Oct 2014 11:23:17 +0200

> We can't control what buggy clients do.  That's not new.

You recently wrote about SSL_MODE_SEND_FALLBACK_SCSV, without any 
qualifications:

“I recommend that you always set that flag.”

<http://article.gmane.org/gmane.comp.encryption.openssl.user/52991>

Unfortunately, you are not the only one who makes this mistake.

I'm now convinced that the scenario I described is extremely likely. 
The problem, of course, is that you will not notice this bug in the 
client application until the server supports TLS 1.3, when it may be too 
late to fix it in the client.

It would be better to say that connections with TLS_FALLBACK_SCSV need 
to fail unconditionally in the server, independent of client and server 
protocol version.  This approach would essentially be a promise of the 
server to be version-tolerant (or a statement of having been updated 
recently, which hopefully amounts to the same thing).  The advantage 
that it doesn't come with the time bomb that has been built into the 
current draft.

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 17 Oct 2014 11:56:28 +0200

Brian Smith <[email-masked]>:

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

> discuss

> that the mechanism is simple to subvert (partially, at least) when

Exactly, but the detailed recommendations should go into an updated False
Start I-D instead; I can do that.  Specifically, that spec could say that
if the client sends TLS_FALLBACK_SCSV in the client hello, False Start
SHOULD be disabled for that handshake.  And then we'll also have to say
that the client similarly should not use False Start with any protocol
version for which it would send TLS_FALLBACK_SCSV in fallback retries
(since otherwise the former recommendation wouldn't achieve anything.)  The
TLS_FALLBACK_SCSV spec's Security Considerations, then, will include a
reminder that allowing False Start with older protocol versions can be
problematic, and that this is a (general) problem that TLS_FALLBACK_SCSV
can't address.

So, I believe that your suggestion for client behavior is absolutely spot
on. My point is just that the very same issue w.r.t. False Start and
version downgrades exists if the client doesn't do any fallback retries --
and those who implement such clients shouldn't have to read the
TLS_FALLBACK_SCSV spec to find out when to allow False Start: this belongs
into the False Start spec.

> downgrade SCSV in an attempt to prevent that.

Right.  (Except that I don't think that you *disagree* with me on this.)

[...]

> downgrade to RSA is prevented by their False Start policies, not by

Here I don't agree. The downgrade to RSA is prevented by having *both*
(don't allow False Start here, *and* use the downgrade SCSV). Not allowing
False Start wouldn't have helped at all without the SCSV for fallback
retries, and using the SCSV wouldn't have been a complete solution if False
Start was enabled with legacy protocols.

> version downgrades, and that should be fixed.

Right. I'll mention that potential surprise with False Start in
TLS_FALLBACK_SCSV Security Considerations, and specify how to avoid it in
the False Start specification.

Bodo

---

From: Hubert Kario <[email-masked]>
Date: Fri, 17 Oct 2014 07:14:26 -0400 (EDT)

----- Original Message -----
> From: "Florian Weimer" <[email-masked]>
> To: "Rich Salz" <[email-masked]>, "Manuel Pégourié-Gonnard" <[email-masked]>, "Martin Thomson"
> <[email-masked]>, "Bodo Moeller" <[email-masked]>
> Cc: [email-masked]
> Sent: Friday, 17 October, 2014 11:23:17 AM
> Subject: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for
> draft-ietf-tls-downgrade-scsv-00)
> 
> recently, which hopefully amounts to the same thing).

But how can you test that the server really *is* tolerant to future
yet undefined protocol versions?

Sure, you can test if the code will accept a client hello with high
minor/major versions, but future versions may modify the initial hello
message in a way the programmers of the server didn't expect and that
actually crashes or generates a fatal error in the server (e.g. because
the server tries to parse whole hello message before looking at the
tls version).

Then to interoperate with such a server a browser would have to try
a client hello with lower version and without the SCSV to interoperate.
And we're in square zero...

>  The advantage

While this is a possibility, I think the only thing we can do to prevent
that is to be explicit in the document:

"The client MUST NOT advertise TLS_FALLBACK_SCSV if it initiates connection
with the highest protocol version it supports."

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 17 Oct 2014 15:20:14 +0200

Hubert Kario <[email-masked]>:

> [...] I think the only thing we can do to prevent

Right, I think stating this explicitly in the spec is probably the right
thing to do (of course this has been the intended behavior all along).
Thanks.

(Arguably the OpenSSL API is too fragile, and SSL_MODE_SEND_FALLBACK_SCSV
should be ignored in this case. So clarifying that in the spec is not the
*only* thing we can do to prevent this.

Also, if a few HTTPS servers log information such as the User-Agent header
if they see a client hello advertising TLS 1.2 with TLS_FALLBACK_SCSV, that
could be used to track down any clients that still manage to get it wrong.
That seems more practical than using clients to find version-intolerant
servers, because for that you'd have to send TLS 1.3 or TLS 1.4 client
hellos before these protocols actually exist, and then wouldn't quite know
what to do in case the server actually chooses one of these versions.)

While I don't see any way to completely avoid interoperability failures in
the presence of potential bugs, I think this failure scenario (buggy
clients potentially sending TLS_FALLBACK_SCSV in every handshake) really
isn't as bad as the alternatives -- such as strictly expecting servers to
be version-tolerant for protocol versions they've never been tested with.
There's always *some* way how buggy implementations could break
interoperability.

Bodo

---

From: Hubert Kario <[email-masked]>
Date: Fri, 17 Oct 2014 09:40:21 -0400 (EDT)

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

> To: "Hubert Kario" <[email-masked]>
> Cc: [email-masked]
> Sent: Friday, 17 October, 2014 3:20:14 PM
> Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group
> Last Call for draft-ietf-tls-downgrade-scsv-00)

> Hubert Kario < [email-masked] > :

> *only* thing we can do to prevent this.

NSS API does allow this too. 

Thing is, we want to have a way to test if the servers are tolerant to future clients 
that claim they had to downgrade. So having the ability to set TL1.2 with this 
SCSV is useful, just like is having an easy to use, widely distributed CLI tool 
(openssl command) that can do this should help with testing and interoperability, 
IMHO.

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 17 Oct 2014 15:44:39 +0200

Andrey Jivsov <[email-masked]>:

(On handling of the downgrade to a recent versions of the protocols, i.e.
> TLS1.3 to 1.2 or TLS1.2 to TLS1.1.)
>

> some cases, while significant amount of traffic on the Internet goes over
> TLS 1.0.
>

Right. If both the client and the server *do* support TLS 1.2, we want to
ensure that they won't unnecessarily fall back to an earlier protocol
version (thus losing the benefits of TLS 1.2). If one of them only supports
an earlier protocol version, they'll still be using that one --
TLS_FALLBACK_SCSV doesn't get in the way for that.

Today, for example,

   www.wellsfargo.com, citibank.com, and bankofamerica.com don't support
> TLS 1.1 and

Note that this isn't the kind of downgrade that TLS_FALLBACK_SCSV is about.

All of the above sites, and indeed most TLS 1.0 sites on the internet, will
properly negotiate the supported protocol version. That is, the client can
send a Client Hello advertising support for TLS 1.2, and the server will
directly respond with a Server Hello selecting TLS 1.0 or TLS 1.1. There's
no fallback retry in which the client adjusts its advertised protocol
version, and thus no need to send TLS_FALLBACK_SCSV.

Also, even if the client *does* retry with a lower protocol version (TLS
1.1 with TLS_FALLBACK_SCSV, or eventually TLS 1.0 with TLS_FALLBACK_SCSV),
such as because the initial handshake failed due to some network glitch,
these servers would still accept the new handshakes according to the
TLS_FALLBACK_SCSV specification. The spec only requires them to reject
Client Hellos with TLS_FALLBACK_SCSV if the advertised protocol version is
*lower* than the maximum protocol version supported by the client.

> says, but now enables more tolerant server behaviour.

As discussed above, I don't see any problem that this change would address.

The spec intentionally gives exact rules for server-side behavior, allowing
the *clients* to fully drive the fallback strategy and determine when it's
OK to fall back to an earlier protocol version and when it's not (with no
server-side heuristics involved).

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 17 Oct 2014 15:51:06 +0200

> (openssl command) that can do this should help with testing and

I know. This is exactly why OpenSSL does honor SSL_MODE_SEND_FALLBACK_SCSV
even when the highest supported protocol version is enabled. (So the best
way to make the API less fragile might be to create an additional setting
that makes SSL_MODE_SEND_FALLBACK_SCSV behavior unconditional, such as
SSL_MODE_SEND_FALLBACK_SCSV_FOR_TESTING.)

Bodo

---

From: Andrey Jivsov <[email-masked]>
Date: Fri, 17 Oct 2014 11:04:15 -0700

On 10/17/2014 06:44 AM, Bodo Moeller wrote:
> Andrey Jivsov <[email-masked] <mailto:[email-masked]>>:
>
>     (On handling of the downgrade to a recent versions of the
>     protocols, i.e. TLS1.3 to 1.2 or TLS1.2 to TLS1.1.)
>
>     The draft -00 asks the server supporting TLS 1.2 to fail the TLS
>     1.1 in some cases, while significant amount of traffic on the
>     Internet goes over TLS 1.0.
>
>
> Right. If both the client and the server *do* support TLS 1.2, we want 
> to ensure that they won't unnecessarily fall back to an earlier 
> protocol version (thus losing the benefits of TLS 1.2). If one of them 
> only supports an earlier protocol version, they'll still be using that 
> one -- TLS_FALLBACK_SCSV doesn't get in the way for that.

Yes, but note that the draft requires servers to fail on TLS 1.1 when 
they were not required to do so before.

This is on the backdrop that the downgrade issue is entirely due to some 
client-specific implementation of the protocol negotiation (the 
fallback) and client's view that TLS 1.1 is secure (as a matter of fact, 
they would currently talk SSL3.0 without any warning).

>
>
>     Today, for example, 
>
>     www.wellsfargo.com <http://www.wellsfargo.com/>, citibank.com
>     <http://citibank.com/>, and bankofamerica.com
>     <http://bankofamerica.com/> don't support TLS 1.1 and
>     mozilla.com <http://mozilla.com/> doesn't support TLS 1.2.
>
>
> All of the above sites, and indeed most TLS 1.0 sites on the internet, 
> will properly negotiate the supported protocol version. That is, the 
> client can send a Client Hello advertising support for TLS 1.2, and 
> the server will directly respond with a Server Hello selecting TLS 1.0 
> or TLS 1.1. There's no fallback retry in which the client adjusts its 
> advertised protocol version, and thus no need to send TLS_FALLBACK_SCSV.

The reality of the Internet today is that TLS 1.1 is viewed as 
acceptable. Clients treating TLS 1.1 treating it this way too. The draft 
*requires* to introduce a rejection of TLS 1.1 connection on the server 
when the server detects the downgrade.

My point is that downgrades from TLS1.0 to SSL3.0 is one thing but from 
TLS1.3 to TLS1.2 is another.

>
> Also, even if the client *does* retry with a lower protocol version 
> (TLS 1.1 with TLS_FALLBACK_SCSV, or eventually TLS 1.0 with 
> TLS_FALLBACK_SCSV), such as because the initial handshake failed due 
> to some network glitch, these servers would still accept the new 
> handshakes according to the TLS_FALLBACK_SCSV specification. The spec 
> only requires them to reject Client Hellos with TLS_FALLBACK_SCSV if 
> the advertised protocol version is *lower* than the maximum protocol 
> version supported by the client.

If the server supports TLS1.2 and the server sees TLS1.1+SCSV, the 
server MUST fail with inappropriate_fallback. Isn't this is what section 
3 says?

>
>     I propose the following change that allows to do exactly what rev
>     -00 says, but now enables more tolerant server behaviour.
>
>
> The spec intentionally gives exact rules for server-side behavior, 
> allowing the *clients* to fully drive the fallback strategy and 
> determine when it's OK to fall back to an earlier protocol version and 
> when it's not (with no server-side heuristics involved).

Servers are often independent nodes on the Internet. Servers may have 
their own policy regarding when it's appropriate to reject a connection 
and, in general, what are the security implications of the version 
downgrade is.

Today, latest popular browsers will happily connect to a SSL3.0 server 
without any indication to a user.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 17 Oct 2014 13:03:23 -0700

> SSL_MODE_SEND_FALLBACK_SCSV_FOR_TESTING.)

I considered building this sort of feature, but it comes down to this:
if you are doing the fallback thing, such that setting this option is
even a possibility, then you are already tall enough to work out when
to send the SCSV and when not to.

Furthermore, we have situations where clients are configured to send
less than the highest version initially, such that it would not be
appropriate to set the SCSV.  And, we now have experimental TLS 1.3
code in NSS, all of which makes the question of  what the actual
highest version that is supported quite murky.

Another alternative is to have a value that is set to the highest
version permitted.  Handshakes that go out with lower version numbers
get marked with the SCSV.  Set this to a low value and the SCSV is
suppressed.

---

From: Andrei Popov <[email-masked]>
Date: Fri, 17 Oct 2014 20:35:05 +0000

Now that SSL's days are counted, why use SCSV (rather than a TLS extension)?

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Friday, October 17, 2014 1:03 PM
To: Bodo Moeller
Cc: [email-masked]
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)

On 17 October 2014 06:51, Bodo Moeller <[email-masked]> wrote:
> I know. This is exactly why OpenSSL does honor 
> SSL_MODE_SEND_FALLBACK_SCSV even when the highest supported protocol 
> version is enabled. (So the best way to make the API less fragile 
> might be to create an additional setting that makes 
> SSL_MODE_SEND_FALLBACK_SCSV behavior unconditional, such as

I considered building this sort of feature, but it comes down to this:
if you are doing the fallback thing, such that setting this option is even a possibility, then you are already tall enough to work out when to send the SCSV and when not to.

Furthermore, we have situations where clients are configured to send less than the highest version initially, such that it would not be appropriate to set the SCSV.  And, we now have experimental TLS 1.3 code in NSS, all of which makes the question of  what the actual highest version that is supported quite murky.

Another alternative is to have a value that is set to the highest version permitted.  Handshakes that go out with lower version numbers get marked with the SCSV.  Set this to a low value and the SCSV is suppressed.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 17 Oct 2014 14:03:03 -0700

> Now that SSL's days are counted, why use SCSV (rather than a TLS extension)?

I wasn't going to ask that question now that it's been implemented and
deployed, but I do have to wonder if that's not the right thing to do
here...

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 17 Oct 2014 17:14:49 -0400

> deployed, but I do have to wonder if that's not the right thing to do
+1

Related: "Why do browsers probe and fallback (or, why
SSL_MODE_SEND_FALLBACK_SCSV)?",
http://security.stackexchange.com/q/70988.

---

From: Andrei Popov <[email-masked]>
Date: Fri, 17 Oct 2014 21:37:09 +0000

It's not an RFC yet, so perhaps we should at least consider using a TLS extension. SCSVs are ugly hacks. A simple TLS extension is probably not much harder to implement than an SCSV, and may result in cleaner code.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Friday, October 17, 2014 2:03 PM
To: Andrei Popov
Cc: Bodo Moeller; [email-masked]
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)

> Now that SSL's days are counted, why use SCSV (rather than a TLS extension)?

I wasn't going to ask that question now that it's been implemented and deployed, but I do have to wonder if that's not the right thing to do here...

---

From: Marsh Ray <[email-masked]>
Date: Fri, 17 Oct 2014 23:49:05 +0000

From: TLS [mailto:[email-masked]] On Behalf Of Andrei Popov
> It's not an RFC yet, so perhaps we should at least consider using
> a TLS extension. SCSVs are ugly hacks. A simple TLS
> extension is probably not much harder to implement than
> an SCSV, and may result in cleaner code.

At least I think I remember hearing somewhere that
"SSLv3 without extensions" is one of the configurations that some
of these auto-downgrading client applications fall back to.

- Marsh

---

From: Andrei Popov <[email-masked]>
Date: Fri, 17 Oct 2014 23:54:27 +0000

Correct; however thanks to POODLE, these auto-downgrading client applications are rapidly removing SSL3 from the fallback sequence. So the reason for having SCSV (instead of a proper TLS extension) is disappearing.

-----Original Message-----
From: Marsh Ray 
Sent: Friday, October 17, 2014 4:49 PM
To: Andrei Popov; Martin Thomson
Cc: [email-masked]
Subject: RE: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)

> It's not an RFC yet, so perhaps we should at least consider using a 
> TLS extension. SCSVs are ugly hacks. A simple TLS extension is 
> probably not much harder to implement than an SCSV, and may result in 
> cleaner code.

At least I think I remember hearing somewhere that
"SSLv3 without extensions" is one of the configurations that some of these auto-downgrading client applications fall back to.

- Marsh

---

From: Martin Thomson <[email-masked]>
Date: Fri, 17 Oct 2014 17:16:25 -0700

> Correct; however thanks to POODLE, these auto-downgrading client applications are rapidly removing SSL3 from the fallback sequence. So the reason for having SCSV (instead of a proper TLS extension)…

I think on balance it's worth leaving this.  I expect NSS will
maintain SSLv3 for some time to come for various reasons that I don't
like, but am willing to tolerate.  The SCSV is going to provide a
measure of protection to those people who are forced to allow it to
live.

---

From: Andrei Popov <[email-masked]>
Date: Sat, 18 Oct 2014 01:08:20 +0000

Certainly a lot of implementations will keep SSL3 code around for a while, just disabled by default.

On the client side, SCSV (not extension) is only needed if fallback to SSL3 is allowed, correct? This is the very fallback that browser vendors are disabling right now. So the only browsers that fall back to SSL3 will be the ones without the Downgrade-SCSV support.

On the server side, SCSV (not extension) is only needed if a) SSL3 is enabled, and b) the server tries to protect clients that offer TLS1.0 (not 1.1 or 1.2) at the first connection attempt. Am I missing something? However, a browser that implements a shiny new Downgrade-something RFC is unlikely to offer TLS1.0 on the first connection attempt.

This is why I think the case for SCSV not extension is very weak, and getting weaker by the day.

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Friday, October 17, 2014 5:16 PM
To: Andrei Popov
Cc: Marsh Ray; [email-masked]
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)

> Correct; however thanks to POODLE, these auto-downgrading client applications are rapidly removing SSL3 from the fallback sequence. So the reason for having SCSV (instead of a proper TLS extension)…

I think on balance it's worth leaving this.  I expect NSS will maintain SSLv3 for some time to come for various reasons that I don't like, but am willing to tolerate.  The SCSV is going to provide a measure of protection to those people who are forced to allow it to live.

---

From: Bodo Moeller <[email-masked]>
Date: Sat, 18 Oct 2014 13:56:23 +0200

> Now that SSL's days are counted, why use SCSV (rather than a TLS

Even once we no longer need to worry about extension *intolerant* servers,
we still should take into account that extension *support* remains optional
for TLS servers. Servers can legitimately ignore ClientServer.extensions
entirely. Having a fallback_indication TLS extension would be overly
onerous for such servers: they'd need to implement extension parsing just
to be able to find this one signal. Looking for the SCSV is much simpler.

(Also, there's less overhead in sending an SCSV vs. sending an empty
extension.)

Also, of course, it will be a while until we know whether the premise of
your question is even true. I certainly hope so, but users that might need
to enable a fallback to SSL 3.0 for whatever reason still deserve the best
possible protection from attacks.

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Sat, 18 Oct 2014 14:08:54 +0200

The reality of the Internet today is that TLS 1.1 is viewed as acceptable.
> Clients treating TLS 1.1 treating it this way too. The draft *requires* to
> introduce a rejection of TLS 1.1 connection on the server when the server
> detects the downgrade.
>

According to the draft, this server-side rejection is REQUIRED *if the
client sent TLS_FALLBACK_SCSV to request it*. For the client, however, it
is merely RECOMMENDED to send TLS_FALLBACK_SCSV in all fallback retries.

> TLS1.3 to TLS1.2 is another.

You appear to be saying that, carefully weighing the case, a silent
fallback to TLS 1.2 can be acceptable. I don't disagree: the spec takes
this into account, it's just that it leaves it to the *client* to make this
decision, without further *server*-side heuristics interfering with it,.

(I think this makes sense because it's the client that decides whether to
do fallback retries in the first place. For clients that don't set
TLS_FALLBACK_SCSV at all, for example, any server-side enabled protocol
version can be negotiated anyway -- the server can't avoid using old
versions with such clients other than by disabling them entirely.)

Bodo

---

From: Yuhong Bao <[email-masked]>
Date: Sat, 18 Oct 2014 19:03:07 +0000 (UTC)

we still should take into account that extension *support* remains optional
for TLS servers. Servers can legitimately ignore ClientServer.extensions
entirely. Having a fallback_indication TLS extension would be overly onerous
for such servers: they'd need to implement extension parsing just to be able
to find this one signal. 
MS had to do this in order to backport the TLS renegotiation extension to
XP/Server 2003 back in 2010.

---

From: Andrey Jivsov <[email-masked]>
Date: Sun, 19 Oct 2014 00:44:21 -0700

On 10/18/2014 05:08 AM, Bodo Moeller wrote:
>     acceptable. Clients treating TLS 1.1 treating it this way too. The
>     draft *requires* to introduce a rejection of TLS 1.1 connection on
>     the server when the server detects the downgrade.
>
>
> client sent TLS_FALLBACK_SCSV to request it*. For the client, however, 
> it is merely RECOMMENDED to send TLS_FALLBACK_SCSV in all fallback 
> retries.

Thinking more about it, there are two issues I see with the above: 
"smart client / dumb server" model and SHOULD for the client use of 
TLS_FALLBACK_SCSV.

What was the rationale for the dumb server / smart client design?

Please allow me to suggest that the opposite might be equally viable: a 
client MUST include TLS_FALLBACK_SCSV (with any downgraded negotiation) 
and server SHOULD respond with an inappropriate_fallback alert.

Example. Most often the servers are the custodians of the information / 
content. Servers are managed by professionals and are properly 
maintained. A server security policy might require TLS 1.1 to access the 
content that it serves. When such a server receives a ClientHello with 
TLS 1.0, it might proceed with a handshake, but display an HTML page 
explaining that access was denied due to low security, perhaps adding 
how to remedy the problem. In the end this is more secure: the same 
result of denying access to information, but with a more informative 
message. Neither the server nor the client implementations may find it 
appealing to code a special warning message specifically to flag MiT 
downgrade attack when TLS_FALLBACK_SCSV is used (e.g. to avoid 
false-positives), however, the server may include some of this 
information on the above-mentioned page as well, or choose to send 
inappropriate_fallback alert.

>     My point is that downgrades from TLS1.0 to SSL3.0 is one thing but
>     from TLS1.3 to TLS1.2 is another.
>
>
> fallback to TLS 1.2 can be acceptable. I don't disagree: the spec 
> takes this into account, it's just that it leaves it to the *client* 
> to make this decision, without further *server*-side heuristics 
> interfering with it,.

Thank you for considering this issue, Bodo.
>
> (I think this makes sense because it's the client that decides whether 
> to do fallback retries in the first place. For clients that don't set 
> TLS_FALLBACK_SCSV at all, for example, any server-side enabled 
> protocol version can be negotiated anyway -- the server can't avoid 
> using old versions with such clients other than by disabling them 
> entirely.)

... Yet the server has the content.

Currently the client has SHOULD for TLS_FALLBACK_SCSV. Why is this one 
not MUST (regardless of the server MUST or SHOULD)?

This SHOULD for the client means that the client that implements the 
draft will use some logic to switch between cases:
a) as if doesn't implement the draft
b) client sends TLS_FALLBACK_SCSV with any downgraded negotiation

If client does a), perhaps by interpreting network errors, POODLE 
continues to live.

Is this intended for clients that allow end-users to tweak how SHOULD is 
interpreted?

If we have protocol dance on the client (heuristic #1) and SHOULD 
include TLS_FALLBACK_SCSV  (heuristic #2), this may complicate 
diagnosing this on the server.

I would say (regardless of the server SHOULD or MUST), that one is free 
not to implement the draft on the client. If he does, he MUST send the 
TLS_FALLBACK_SCSV on the downgrade.

---

From: Hubert Kario <[email-masked]>
Date: Mon, 20 Oct 2014 06:13:50 -0400 (EDT)

----- Original Message -----
> From: "Andrei Popov" <[email-masked]>
> To: "Martin Thomson" <[email-masked]>
> Cc: [email-masked]
> Sent: Saturday, 18 October, 2014 3:08:20 AM
> On the client side, SCSV (not extension) is only needed if fallback to SSL3
> is allowed, correct? This is the very fallback that browser vendors are
> disabling right now. So the only browsers that fall back to SSL3 will be the
> ones without the Downgrade-SCSV support.

We don't know yet if it will be disabled in all browsers.

> On the server side, SCSV (not extension) is only needed if a) SSL3 is
> enabled, and b) the server tries to protect clients that offer TLS1.0 (not
> 1.1 or 1.2) at the first connection attempt. Am I missing something?

1.3 to 1.2. Over 10% of Internet web servers are intolerant to 1.3 ClientHello

> However, a browser that implements a shiny new Downgrade-something RFC is
> unlikely to offer TLS1.0 on the first connection attempt.

Browsers maybe not (time will tell), but it got implemented in OpenSSL 0.9.8
which supports TLS 1.0 max.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 20 Oct 2014 13:47:48 +0200

On Thu, 2014-10-16 at 16:34 +0200, Bodo Moeller wrote:

> When writing the TLS_FALLBACK_SCSV specification, I was thus aiming to
> keep it simple enough so that implementors would be extremely unlikely
> to get it wrong (at least once there's some base deployment of clients
> and servers so that basic interoperability tests will immediately
> expose large classes of potential bugs, which should by now be the
> case). Do you seriously think that implementors might end up sending
> TLS_FALLBACK_SCVS unconditionally? If so, do you think that those
> implementors would be capable of avoiding other more subtle bugs, and
> overall to create a mostly usable and possibly even reasonably secure
> product? (I can't help thinking that if a client is *that* broken,
> we'd probably be doing its users a favor by having all handshakes
> fail.)
> More importantly, if there were no fallback retries and thus no need
> for TLS_FALLBACK_SCSV, how could that *possibly* make it *easier* to
> deploy TLS 1.3 given that buggy peers may be around?

I pretty much understand your argumentation, but I think that the
argument for the SCSV boils down on whether we want to keep the insecure
browser fallback mechanism for long. I believe that we shouldn't, and
this is the reason I don't like this draft; it gives legitimacy to an
out-of-standard insecure protocol fallback mechanism.

Indeed, there is an arguments to keep that mechanism, as there are still
some TLS 1.3 intolerant servers. But instead of prolonging the life of
such an insecure mechanism wouldn't it make sense to fix those broken
servers instead; e.g., by peer pressure by documenting the
implementations that are not TLS 1.3-ready in [0]?

[0]. http://en.wikipedia.org/wiki/Comparison_of_TLS_implementations

regards,
Nikos

---

From: Martin Thomson <[email-masked]>
Date: Mon, 20 Oct 2014 04:53:18 -0700

> implementations that are not TLS 1.3-ready in [0]?

I think that we should do that, but as a practical matter, I suspect
that we'll be stuck with some amount of fallback for a while yet.  I
find the TLS 1.3 intolerance numbers pretty alarming in this regard;
even with rapid improvement, I doubt it will go away quickly.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 20 Oct 2014 04:53:48 -0700

> even with rapid improvement, I doubt it will go away quickly.

...enough.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 20 Oct 2014 14:21:39 +0200

> It certainly makes sense to fix those broken servers. I disagree with
> fixing them *instead* of deploying TLS_FALLBACK_SCSV; I think that's a
> false dichotomy. If you are willing to stop fallback retries in the
> client products that Red Hat distributes right now, great (do you?),
> but clearly not everyone is willing to take that step at this time.
> Until it has happened, clients already can benefit from
> TLS_FALLBACK_SCSV.

I disagree. It is a correct dichotomy :) If the servers are fixed, there
is no use for the fallback SCSV, as clients would not need to perform
the insecure fallback.

As of the argument that clients would be protected from the SCSV, that
only works if both the clients _and_ the servers are updated to support
the fallback SCSV. Why is that step necessary, if we can instead fix the
clients and the servers to properly negotiate TLS?

regards,
Nikos

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 20 Oct 2014 14:13:07 +0200

It certainly makes sense to fix those broken servers. I disagree with
fixing them *instead* of deploying TLS_FALLBACK_SCSV; I think that's a
false dichotomy. If you are willing to stop fallback retries in the client
products that Red Hat distributes right now, great (do you?), but clearly
not everyone is willing to take that step at this time. Until it has
happened, clients already can benefit from TLS_FALLBACK_SCSV.

Bodo

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Mon, 20 Oct 2014 14:30:32 +0200

On 26/09/2014 06:00, Joseph Salowey (jsalowey) wrote:
> draft-ietf-tls-downgrade-scsv-00.  Please review the document and send your
> comments to the list by Friday, October 17, 2014.
> 
Just to mention that I just implemented this. As expected (since it's one of the
design goals of the draft), it was very easy.

The only problem I ran into was an interop issue with OpenSSL, which apparently
does not like it if the SCSV appears before the actual ciphersuites in the
ciphersuite list. If the intention of the draft was that the SCSV MUST be placed
after the actual ciphersuites, it would be good to state so using normative
language, rather than the current one which doesn't look normative:

                                     (Since the cipher suite list in the
      ClientHello is ordered by preference, with the client's favorite
      choice first, signaling cipher suite values will generally appear
      after all cipher suites that the client actually intends to
      negotiate.)

Otherwise, it should probably be clarified that servers MUST recognize the SCSV
at any position in the ciphersuite list, which is my preferred option. (It can
be combined with a "clients SHOULD place it after actual ciphersuites", I have
no opinion on that one).

Manuel.

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 20 Oct 2014 14:39:59 +0200

> is no use for the fallback SCSV, as clients would not need to perform

True, but clearly they aren't fixed *now*, and more importantly, various
current clients *do* still find it necessary to use fallback retries to
work with such servers.

I agree that TLS_FALLBACK_SCSV is hypothetically pointless :-)

In reality, though, it does serve a purpose.

> clients and the servers to properly negotiate TLS?

Using the SCSV already helps if *some* servers have been updated to support
it: connections to these servers, at least, will be more secure. For other
servers, you get what you have now.

Disabling fallback retries provides more encompassing protection, but
before you can take that step, you *first* need to fix the servers (that
is, all servers you'd still want to be able to connect to).

If you want to protect information in practice, it's not sufficient to be
confident to have a solution at some point in the future. It also matters
when you can deploy it. There's nothing that blocks you from deploying
TLS_FALLBACK_SCSV -- the broken servers will be just as broken, but you
don't depend on them getting fixed to be able to protect your connections
to servers that do support TLS_FALLBACK_SCSV.

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 20 Oct 2014 14:51:52 +0200

> your

> language, rather than the current one which doesn't look normative:

This is not meant to be normative -- it's a bug in OpenSSL's server-side
code. [If ClientHello.cipher_suites includes TLS_FALLBACK_SCSV, all
following cipher suites are ignored by the server. This will be fixed in
the next release.]

Bodo

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Mon, 20 Oct 2014 15:50:51 +0200

On 20/10/2014 14:51, Bodo Moeller wrote:
>> The only problem I ran into was an interop issue with OpenSSL, which 
>> apparently does not like it if the SCSV appears before the actual
>> ciphersuites in the ciphersuite list. If the intention of the draft was
>> that the SCSV MUST be placed after the actual ciphersuites, it would be
>> good to state so using normative language, rather than the current one
>> which doesn't look normative:
> 
Ok, thanks.

Manuel.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 20 Oct 2014 13:18:11 -0400 (EDT)

> I agree that TLS_FALLBACK_SCSV is hypothetically pointless :-)

No, not only pointless, it gives the broken servers an incentive to continue
being broken. With this change, clients still consider the servers that
require a downgrade dance secure. Why should that be the case? Why for example
chrome or firefox doesn't warn on these servers? They are certainly not
secure.

If the draft should mention that a compliant to SCSV interactive client MUST
warn the user in case of a fallback dance, then yes, I would agree that the
draft is a step forward. I believe the goal must be the elimination of 
non-compliant servers, not only to patch things up until the next attack.

> servers, you get what you have now.

I agree on that, but the issue there is that we tolerate non-TLS compliant
servers and we consider them equally secure, even though your attack shows
that they are not.

regards,
Nikos

---

From: Brian Smith <[email-masked]>
Date: Mon, 20 Oct 2014 10:30:36 -0700

> even with rapid improvement, I doubt it will go away quickly.

That's why the version negotiation mechanism for TLS 1.3 should be
different. We've already made the mistake 3 times of trying to use
ClientHello.client_version to negotiate versions and 3 times we've learned
that it has terrible compatibility issues. Why keep repeating that same
mistake? By negotiating TLS 1.3 with a new extension, and keeping
ClientHello.client_version = TLS 1.2 for TLS 1.3, you avoid the
compatibility costs without losing anything.

Also, even if we decide to keep making that mistake, browsers could stop
fallback for TLS 1.3 -> TLS 1.2, while dropping the rest.

Cheers,
Brian

---

From: Watson Ladd <[email-masked]>
Date: Mon, 20 Oct 2014 10:32:49 -0700

After all these years you would think software vendors would test proper
version negotiation before release.

---

From: Brian Smith <[email-masked]>
Date: Mon, 20 Oct 2014 10:32:55 -0700

On Mon, Oct 20, 2014 at 5:51 AM, Bodo Moeller <[email-masked]> wrote:

>> apparently

For compatibility reasons, clients should put the renegotiation info and
TLS_FALLBACK_SCSV at the end of the cipher suite list, to avoid this bug
and similar bugs in other server software. This should be added to the
draft too.

Cheers,
Brian

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 20 Oct 2014 14:46:22 -0400

I don't think the cipher can appear anywhere.
Can you send details of the OpenSSL bug?
Thanks.

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Mon, 20 Oct 2014 20:52:39 +0200

> Can you send details of the OpenSSL bug?

It's #3575.

Manuel.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 20 Oct 2014 14:56:36 -0400

> It's #3575.

Ah thanks.  Yup, Bodo's fixing it :)

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Mon, 20 Oct 2014 20:56:59 +0200

> and similar bugs in other server software. This should be added to the
Currently, PolarSSL puts the renego SCSV at the beginning of the list and we
didn't get any report of interop issues so far. However, if there's consensus
that it's safer to put the SCSV at the end, I'll follow your advice and change that.

(For the fallback scsv, obviously I added it at the end since we want to interop
with the current version of OpenSSL.)

Manuel.

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 20 Oct 2014 22:12:21 +0200

With this change, clients still consider the servers that
> chrome or firefox doesn't warn on these servers? They are certainly not

I'm not sure why you think that the TLS_FALLBACK_SCSV specification should
be setting UI requirements for this. The same protocol versions, negotiated
using the normal version negotiation mechanism, are just as secure or
insecure, so this isn't specific to TLS_FALLBACK_SCSV.

Bodo

---

From: Andrei Popov <[email-masked]>
Date: Mon, 20 Oct 2014 20:52:15 +0000

>1.3 to 1.2. Over 10% of Internet web servers are intolerant to 1.3 ClientHello

1.3 to 1.2 could be protected by an extension; I think SCSV is only needed to protect the downgrade from TLS1.0 to SSL3.

Cheers,

Andrei

-----Original Message-----
From: Hubert Kario [mailto:[email-masked]] 
Sent: Monday, October 20, 2014 3:14 AM
To: Andrei Popov
Cc: Martin Thomson; [email-masked]
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)

----- Original Message -----
> Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working 
> Group Last Call for
> On the client side, SCSV (not extension) is only needed if fallback to 
> SSL3 is allowed, correct? This is the very fallback that browser 
> vendors are disabling right now. So the only browsers that fall back 
> to SSL3 will be the ones without the Downgrade-SCSV support.

> However, a browser that implements a shiny new Downgrade-something RFC 
> is unlikely to offer TLS1.0 on the first connection attempt.

Browsers maybe not (time will tell), but it got implemented in OpenSSL 0.9.8 which supports TLS 1.0 max.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 20 Oct 2014 17:02:00 -0400

> >1.3 to 1.2. Over 10% of Internet web servers are intolerant to 1.3

Shrug, since it's not defined I don't think it matters that much.

> 1.3 to 1.2 could be protected by an extension; I think SCSV is only needed to
> protect the downgrade from TLS1.0 to SSL3.

I would rather not have two mechanisms that do the exact same thing.

---

From: Andrei Popov <[email-masked]>
Date: Mon, 20 Oct 2014 22:27:45 +0000

Having both SCSV and extension would indeed be worse than just having the SCSV. I'm advocating extension as a less hacky, more forward-looking mechanism that also potentially allows more flexibility in the fallback sequence.

Cheers,

Andrei

-----Original Message-----
From: Salz, Rich [mailto:[email-masked]] 
Sent: Monday, October 20, 2014 2:02 PM
To: Andrei Popov; Hubert Kario
Cc: [email-masked]
Subject: RE: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)

> 1.3 to 1.2 could be protected by an extension; I think SCSV is only 
> needed to protect the downgrade from TLS1.0 to SSL3.

---

From: Andrei Popov <[email-masked]>
Date: Mon, 20 Oct 2014 22:36:28 +0000

It would be nice to keep TLS extensions optional; unfortunately, TLS extensions mechanism is already used to patch protocol security issues: renegotiation info, extended master secret extensions come to mind. I think we've crossed this bridge a long time ago.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Yuhong Bao
Sent: Saturday, October 18, 2014 12:03 PM
To: [email-masked]
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)

> Even once we no longer need to worry about extension *intolerant* 
we still should take into account that extension *support* remains optional for TLS servers. Servers can legitimately ignore ClientServer.extensions entirely. Having a fallback_indication TLS extension would be overly onerous for such servers: they'd need to implement extension parsing just to be able to find this one signal. 
MS had to do this in order to backport the TLS renegotiation extension to XP/Server 2003 back in 2010.

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 21 Oct 2014 00:51:05 +0200

It would be nice to keep TLS extensions optional; unfortunately, TLS
> extensions mechanism is already used to patch protocol security issues:
> renegotiation info, extended master secret extensions come to mind. I think
> we've crossed this bridge a long time ago.

You should be able to get away without the actual renegotiation_info
extension if you don't support renegotiation.

Bodo

---

From: Marsh Ray <[email-masked]>
Date: Mon, 20 Oct 2014 23:28:01 +0000

From: TLS [mailto:[email-masked]] On Behalf Of Bodo Moeller
> extension if you don't support renegotiation.

The thing with the renegotiation attack is the client doesn’t know in advance that the server is renegotiating.

If clients don’t send RI, the server can’t protect them from renegotiation attacks.

If servers don’t parse and respond with renegotiation info, then clients can’t know that they are secure from renegotiation attacks.

We eventually need to get to a day where clients and servers can actively refuse to talk today’s TLS versions without RI. Yeah, it will take a long time.

Basically, clients and servers opting out of RI today because they feel “it doesn’t affect me” are tomorrow’s “auto downgrade to SSLv3 because who needs TLS 1.0”.

-          Marsh

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 21 Oct 2014 01:48:19 +0200

> The thing with the renegotiation attack is the client doesn’t know in
> advance that the server is renegotiating.
>
>
>

I know. What I meant is that expecting TLS_EMPTY_RENEGOTIATION_INFO_SCSV
would be sufficient if you don't do renegotiation. (The server still needs
to respond with an empty extension, but that's just a fixed string.)

Bodo

---

From: Andrei Popov <[email-masked]>
Date: Tue, 21 Oct 2014 00:09:00 +0000

Yes, and you should be able to get away without Downgrade-SCSV if you do not do fallbacks (which are not even part of the TLS protocol).

Cheers,

Andrei

From: Bodo Moeller [mailto:[email-masked]]
Sent: Monday, October 20, 2014 3:51 PM
To: [email-masked]
Cc: Andrei Popov
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)

Andrei Popov <[email-masked]<mailto:[email-masked]>>:

You should be able to get away without the actual renegotiation_info extension if you don't support renegotiation.

Bodo

---

From: Rob Stradling <[email-masked]>
Date: Tue, 21 Oct 2014 10:57:59 +0100

On 20/10/14 18:30, Brian Smith wrote:
> On Mon, Oct 20, 2014 at 4:53 AM, Martin Thomson wrote:
<snip>
> ClientHello.client_version to negotiate versions and 3 times we've
> learned that it has terrible compatibility issues. Why keep repeating
> that same mistake? By negotiating TLS 1.3 with a new extension, and
> keeping ClientHello.client_version = TLS 1.2 for TLS 1.3, you avoid the

How about negotiating TLS 1.3 using yet another new SCSV?

Yes, I know, that'd be even more of a hack than negotiating TLS 1.3 with 
a new extension.  But since server-side support for extensions is 
optional, and since there are servers out there that are 
extension-intolerant, I figured I should at least suggest the idea.  ;-)

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 21 Oct 2014 13:03:24 +0300

On Tue, Oct 21, 2014 at 10:57:59AM +0100, Rob Stradling wrote:
> Yes, I know, that'd be even more of a hack than negotiating TLS 1.3 with a
> new extension.  But since server-side support for extensions is optional,
> and since there are servers out there that are extension-intolerant, I
> figured I should at least suggest the idea.  ;-)

One needs extensions anyway in order to transport data required for
TLS 1.3 handshake (groups supported and key shares for subset of those).

-Ilari

---

From: Bill Frantz <[email-masked]>
Date: Tue, 21 Oct 2014 09:07:14 -0700

>version negotiation before release.

Agreed. It doesn't take much of a test suite to check that a 1.2 
server receiving 1.3 or 2.0 does the right thing. You don't even 
have to know what exactly 1.2 or 2.0 means since the server 
under test is going to offer its highest protocol: 1.2.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | If the site is supported by  | Periwinkle
(408)356-8506      | ads, you are the product.    | 16345 
Englewood Ave
www.pwpconsult.com |                              | Los Gatos, 
CA 95032

---

From: Brian Smith <[email-masked]>
Date: Tue, 21 Oct 2014 13:33:29 -0700

> with the current version of OpenSSL.)

I am not sure if it is problematic to put the renegotiation_info SCSV
anywhere except the end. In NSS, it has always been at the end, as far as I
know. Not too long ago, NSS was changed to always use the TLS extension
instead of the SCSV except for SSL 3.0; see [1] for why. However, in
retrospect, this might have increased the amount of TLS extension
intolerance seen by NSS-based applications, if some servers are intolerant
to the renegotation_info extension but not other ones sent by NSS.

In the case of TLS_FALLBACK_SCSV, it was assigned the value { 0x56, 0x00 }.
>From past experience, we know that some implementations only look at the
second byte of the value. This means that some implementations may confuse
TLS_FALLBACK_SCSV with { 0x00, 0x00 }, which is TLS_NULL_WITH_NULL_NULL.  Thus,
if you put TLS_FALLBACK_SCSV ahead of any real cipher suites, some
implementations may attempt to negotiation TLS_NULL_WITH_NULL_NULL,
especially if that implementation is attempting to honor the client's
cipher suite preference order. If that were to happen, the best case
scenerio is that your client will refuse the server's choice of
TLS_NULL_WITH_NULL_NULL,
which is not good. By putting TLS_FALLBACK_SCSV at the end, you avoid this
problem with these broken servers, assuming you offer some cipher suite
that they actually support. See [2]. Note that these kind of broken servers
are the reason you'd be doing TLS intolerance fallback in the first place.

Cheers,
Brian

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=549042#c4
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=946147#c5

---

From: Brian Smith <[email-masked]>
Date: Tue, 21 Oct 2014 13:42:46 -0700

On Tue, Oct 21, 2014 at 3:03 AM, Ilari Liusvaara <
[email-masked]> wrote:

> a

 Yes, and also more fundamental things like the server_name and
status_request extensions. I think after TLS_FALLBACK_SCSV, we should avoid
new SCSVs.

Cheers,
Brian

---

From: Andrey Jivsov <[email-masked]>
Date: Thu, 23 Oct 2014 22:53:45 -0700

Server list of acceptable ciphersuites is sometimes protocol-specific. 
For example, AES-GCM suites are associated with TLS1.2.

There may be ciphersuites that apply to all protocols but only 
configured to be available with lower ones on some servers. For example, 
DES-CBC3-SHA (or RC4-SHA, etc) might be made available for SSL3.0 only.

Let's assume that the server supports all protocols SSL3.0-TLS1.0, but 
this server supports DES-CBC3-SHA with SSL3.0 only.

Assume that a client only negotiates DES-CBC3-SHA (or that this would be 
the only intersection)

Client does {DES-CBC3-SHA} with TLS1.2 in ClientHello. The pair 
negotiates DES-CBC3-SHA with SSL3.0.

Client decides to drop to TLS1.1 (due to network glitch, etc). It SHOULD 
do {DES-CBC3-SHA,TLS_FALLBACK_SCSV} with TLS1.1 per sec 4. The server 
MUST fail with inappropriate_fallback per sec 3.

Is it a good idea to reject a more secure protocol than the server can 
possibly negotiate with this client? Did I interpret the draft correctly?

( The scenario applies in other cases when you adjust some of values 
here. For example, we expect TLS1.3 intolerant servers, so TLS1.2+SCSV 
was advocated in this case this list. The server is expected to fail 
with inappropriate_fallback even when it doesn't have a match with 
ciphersuites associated with TLS1.2. )

Thank you.

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 24 Oct 2014 11:58:47 +0200

Client decides to drop to TLS1.1 (due to network glitch, etc). [...] The
> server MUST fail with inappropriate_fallback per sec 3.
>
> possibly negotiate with this client?

In this case, the connection really fails due to the network glitch. If the
client wasn't attempting fallback retries, it would similarly fail. (This
could happen independently of the cipher suites that the server accepts.)

In the kind of hypothetical scenario that you describe, it indeed wouldn't
cause a reduction in security to accept the connection instead of failing,
but optimizing for corner cases like this one doesn't seem reasonable: it
necessarily would make the mechanism more complex overall.

(The server behavior that you describe also would be really odd. The CBC
cipher suites are more broken in SSL 3.0 than in TLS 1.0, and more broken
in TLS 1.0 than in TLS 1.1. If the server *does* support one of the newer
protocol versions, why would it only support the most broken incarnation of
that cipher suite?

Also note that in the *specific* hypothetical scenario that you describe,
the server actually would accept the fallback retry: you said that TLS 1.0
is the highest protocol version supported by the server; this is not higher
than ClientHello.client_version in the TLS 1.1 retry, so the server
wouldn't reject.)

Bodo

---

From: Andrey Jivsov <[email-masked]>
Date: Fri, 24 Oct 2014 13:21:08 -0700

On 10/24/2014 02:58 AM, Bodo Moeller wrote:
>     Client decides to drop to TLS1.1 (due to network glitch, etc).
>     [...] The server MUST fail with inappropriate_fallback per sec 3.
>
>     Is it a good idea to reject a more secure protocol than the server
>     can possibly negotiate with this client?
>
>
> In this case, the connection really fails due to the network glitch. 
> If the client wasn't attempting fallback retries, it would similarly 
> fail. (This could happen independently of the cipher suites that the 
> server accepts.)

In this scenario the client would succeed with the same server if the 
server doesn't implement draft-ietf-tls-downgrade-scsv but will fail if 
the server implements draft-ietf-tls-downgrade-scsv-03. Interestingly, 
regardless of draft-ietf-tls-downgrade-scsv-03 implementation the 
negotiated ciphersuite will be the same (when the pair succeeds with the 
handshake, that is)

>
> In the kind of hypothetical scenario that you describe, it indeed 
> wouldn't cause a reduction in security to accept the connection 
> instead of failing, but optimizing for corner cases like this one 
> doesn't seem reasonable: it necessarily would make the mechanism more 
> complex overall.
>
> (The server behavior that you describe also would be really odd. The 
> CBC cipher suites are more broken in SSL 3.0 than in TLS 1.0, and more 
> broken in TLS 1.0 than in TLS 1.1. If the server *does* support one of 
> the newer protocol versions, why would it only support the most broken 
> incarnation of that cipher suite?
>

This configuration of the server may be driven by the logic that "we 
will use legacy algorithms (RC4, SHA1, etc) with legacy protocols (SSL*, 
TLS1.0) for legacy clients".

> Also note that in the *specific* hypothetical scenario that you 
> describe, the server actually would accept the fallback retry: you 
> said that TLS 1.0 is the highest protocol version supported by the 
> server; this is not higher than ClientHello.client_version in the TLS 
> 1.1 retry, so the server wouldn't reject.)

No, this is not what I was saying.

In my scenario the server supports TLS1.2 in general with some 
ciphersuites (and will support TLS1.3 in the future). The server is 
configured in a way that the ciphersuite that it can negotiate with the 
client requires SSLv3.

What does draft-ietf-tls-downgrade-scsv-03 want the server to do here: 
assume it's highest version is TLS1.2 or SSL 3.0?  I.e. is the max. 
version a static property on the server or dynamic based on ciphers in 
ClientHello?

---

From: Bodo Moeller <[email-masked]>
Date: Sat, 25 Oct 2014 01:04:23 +0200

>> Also note that in the *specific* hypothetical scenario that you
describe, the server actually would accept the fallback retry: you said
that TLS 1.0 is the highest protocol version supported by the server; this
is not higher than ClientHello.client_version in the TLS 1.1 retry, so the
server wouldn't reject.)

> No, this is not what I was saying.

Yes, it is ("Let's assume that the server supports all protocols
SSL3.0-TLS1.0").  I gather that's not what you meant, though.

> What does draft-ietf-tls-downgrade-scsv-03 want the server to do here:
assume it's highest version is TLS1.2 or SSL 3.0?  I.e. is the max. version
a static property on the server or dynamic based on ciphers in ClientHello?

There's no -03 draft, but the current draft's implication should be clear:
the server compares protocol versions only and hence rejects. (Pretending
that the highest protocol version is SSL 3.0 wouldn't make sense.)

---

From: Andrey Jivsov <[email-masked]>
Date: Sat, 25 Oct 2014 00:55:16 -0700

> SSL3.0-TLS1.0").  I gather that's not what you meant, though.
( Sorry for confusion caused by two typos. )

Yes, I am talking about a "modern" server (so TLS1.2 is implemented or 
TLS1.3 in the near future).

> configured in a way that the ciphersuite that it can negotiate with 
> the client requires SSLv3.
> >
> > What does draft-ietf-tls-downgrade-scsv-03 want the server to do 
> here: assume it's highest version is TLS1.2 or SSL 3.0? I.e. is the 
> max. version a static property on the server or dynamic based on 
> ciphers in ClientHello?
>

> There's no -03 draft, but the current draft's implication should be 
> clear: the server compares protocol versions only and hence rejects. 
> (Pretending that the highest protocol version is SSL 3.0 wouldn't make 
> sense.)
>

Thanks, that's what I thought the draft is saying. The server simply 
uses hardcoded value that represents the highest version it implements. 
Well, consider that if the server "pretends" that its version is SSL 3.0 
(because this is what it will negotiate in my example, along the lines 
of the logic for the client in the draft), this will avoid breaking the 
fallback connection, an unnecessary failure in the example I gave.

Repeating my point earlier, it looks kind of harsh to fail TLS 1.1 on 
the server when it can only negotiate SSL3.0 with that client.

In summary, I still don't see good justification for discrepancy: the 
client "SHOULD include the TLS_FALLBACK_SCSV", while the server "MUST 
respond with an inappropriate_fallback". I would prefer that the server 
had SHOULD keyword, which is a reasonable keyword for secure protocols. 
The draft is not MUST with TLS, of course, and it would be reasonable to 
give some wiggle room to server implementation to determine when to fail 
the handshake.

---

From: Martin Thomson <[email-masked]>
Date: Sat, 25 Oct 2014 01:02:39 -0700

On 25 October 2014 00:55, Andrey Jivsov <[email-masked]> wrote:
> Repeating my point earlier, it looks kind of harsh to fail TLS 1.1 on the
> server when it can only negotiate SSL3.0 with that client.

Why, if the client is willing to do TLS 1.1, there's an unnecessary fallback.

Note that the maximum version in play is always the maximum version
that the server (or client) is willing to negotiate.  If a server is
capable of 1.2, but configured with 1.1, only downgraded handshakes to
1.0 or SSL will cause the alert to be generated.

---

From: Andrey Jivsov <[email-masked]>
Date: Sat, 25 Oct 2014 01:21:22 -0700

> Why, if the client is willing to do TLS 1.1, there's an unnecessary fallback.
In my example the client failed TLS1.2 ClientHello and decided 
(incorrectly, due to network failure, etc) to do TLS1.1+TLS_FALLBACK_SCSV.

> that the server (or client) is willing to negotiate.
The above is too general, so let's ignore it for now :-)
> If a server is
I don't think this is what Bodo is saying. Sec 3 (server) is missing the 
concept of "configured", while the sec 4 (client) has it.

My example again is:

* the server capable of TLS 1.2 and lower. I mean, it will accept TLS 
1.2 ClientHello.
* the pair of the server and client happened to only able negotiate a 
ciphersuite that is set on the server to be SSL3.0
* client sends TLS1.1+TLS_FALLBACK_SCSV

So, what is server's maximum version? Bodo says it's TLS1.2. Thus, 
TLS1.1+TLS_FALLBACK_SCSV must fail. I say it's harsh because this pair 
can only negotiate SSL 3.0.

---

From: Bodo Moeller <[email-masked]>
Date: Sat, 25 Oct 2014 12:25:30 +0200

If a server is

> concept of "configured", while the sec 4 (client) has it.

That's an inconsistency that I can fix. If a protocol version is completely
disabled in the server, of course using that version isn't supposed to be
an "inappropriate fallback".

> My example again is:
>
> * the server capable of TLS 1.2 and lower. I mean, it will accept TLS 1.2
> ClientHello.
>

And will negotiate TLS 1.2?

> TLS1.1+TLS_FALLBACK_SCSV must fail. I say it's harsh because this pair can
> only negotiate SSL 3.0.
>

If the server is willing to negotiate TLS 1.2, then this is an
inappropriate fallback and will fail. It's not reasonable to optimize the
specification to provide extra error redundancy for blatantly stupid
servers as in this scenario (at the cost of making it more complex, which
can lead to other problems).

Bodo

---

From: Florian Weimer <[email-masked]>
Date: Sat, 25 Oct 2014 19:08:55 +0200

* Andrei Popov:

> Yes, and you should be able to get away without Downgrade-SCSV if
> you do not do fallbacks (which are not even part of the TLS
> protocol).

But you still have to patch servers to protect broken clients from
their foolishness.  It doesn't matter that you don't do downgrades on
the server side.  That's one reason why I think TLS_FALLBACK_SCSV is
an embarrassment—it sanctifies the sinners, instead of forcing them to
clean up their act.

---

From: Andrey Jivsov <[email-masked]>
Date: Sat, 25 Oct 2014 12:41:33 -0700

On 10/25/2014 03:25 AM, Bodo Moeller wrote:
>     I don't think this is what Bodo is saying. Sec 3 (server) is missing
>     the concept of "configured", while the sec 4 (client) has it.
>
>
> That's an inconsistency that I can fix. If a protocol version is
> completely disabled in the server, of course using that version isn't
> supposed to be an "inappropriate fallback".
>
>     My example again is:
>
>     * the server capable of TLS 1.2 and lower. I mean, it will accept
>     TLS 1.2 ClientHello.
>
>
>     * the pair of the server and client happened to only able negotiate
>     a ciphersuite that is set on the server to be SSL3.0
>     TLS1.1+TLS_FALLBACK_SCSV must fail. I say it's harsh because this
>     pair can only negotiate SSL 3.0.
>
>
> inappropriate fallback and will fail. It's not reasonable to optimize
> the specification to provide extra error redundancy for blatantly stupid
> servers as in this scenario (at the cost of making it more complex,
> which can lead to other problems).
>

Regarding "blatantly stupid servers",

what you are saying is that the set of ciphers that can be negotiated 
with TLS1.2 must be a superset of the ciphers that can be negotiated 
with TLS1.1 in any server configuration, and so on to SSL 3.0

I am not sure that this will always be possible. Let's say I must offer 
RC4-MD5 for legacy products that only support SSL 3.0.

I think it would be more secure to offer

   TLS1.2: X, Y
   TLS1.1: X
   TLS1.0: X
   SSL3.0: X, RC4-MD5

than

   TLS1.2: X, Y, RC4-MD5
   TLS1.1: X, RC4-MD5
   TLS1.0: X, RC4-MD5
   SSL3.0: X, RC4-MD5

where X, Y are reasonable sets that currently works well with modern 
products.

The last line in each of the two sets above is a weak configuration, but 
this is the only cipher+protocol that outdated and unpatched clients can 
negotiate.

If I make RC4-MD5 available for higher protocols, this will mean that 
it's now potentially available to modern clients. Hopefully the clients 
don't negotiate it, or at the very least order it at the bottom of the 
ClientHello, however, there is now an insecure RC4-MD5 offered with 
TLS1.2. At the very least it looks bad to auditors, scanners, etc.

My example earlier in this thread involved the modern client negotiating 
RC4-MD5, supposedly due to misconfiguration. I think the first 
configuration on the server is slightly better because SSL 3.0 would 
likely be disabled by some global override on the client, preventing 
this scenario.

I think one should accept a small probability for TLS1.2-capable servers 
to negotiate lower version with TLS1.2 clients.

---

From: Brian Smith <[email-masked]>
Date: Sat, 25 Oct 2014 13:52:12 -0700

On Sat, Oct 25, 2014 at 12:41 PM, Andrey Jivsov <[email-masked]> wrote:
>
> what you are saying is that the set of ciphers that can be negotiated with
> TLS1.2 must be a superset of the ciphers that can be negotiated with TLS1.1
> in any server configuration, and so on to SSL 3.0
>

No. The set of ciphers that can be negotiated with TLS 1.2 must overlap
with the set of ciphers that clients offer in their TLS 1.2 handshake.

> I think it would be more secure to offer

That seems OK to me. You just need to make sure that X is offered by all
the clients you want to support that support TLS_FALLBACK_SCSV and that
don't support TLS 1.2, and that at least one of {X, Y}  is supported by by
all TLS-1.2-capable clients that support TLS_FALLBACK_SCSV. (Approximately.)

Cheers,
Brian

---

From: Andrei Popov <[email-masked]>
Date: Sat, 25 Oct 2014 22:05:14 +0000

Yes, there is some truth in what you say. Downgrade-SCSV is a hack, but it will be hard/impossible to convince browser vendors to stop doing fallbacks. Perhaps that's because browsers compete on interoperability and connectivity, not security?

-----Original Message-----
From: Florian Weimer [mailto:[email-masked]] 
Sent: Saturday, October 25, 2014 10:09 AM
To: Andrei Popov
Cc: Bodo Moeller; [email-masked]
Subject: Re: [TLS] The TLS_FALLBACK_SCSV time bomb

* Andrei Popov:

> Yes, and you should be able to get away without Downgrade-SCSV if you 
> do not do fallbacks (which are not even part of the TLS protocol).

But you still have to patch servers to protect broken clients from their foolishness.  It doesn't matter that you don't do downgrades on the server side.  That's one reason why I think TLS_FALLBACK_SCSV is an embarrassment—it sanctifies the sinners, instead of forcing them to clean up their act.

---

From: Andrey Jivsov <[email-masked]>
Date: Sat, 25 Oct 2014 20:35:28 -0700

On 10/25/2014 01:52 PM, Brian Smith wrote:
> On Sat, Oct 25, 2014 at 12:41 PM, Andrey Jivsov <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     what you are saying is that the set of ciphers that can be
>     negotiated with TLS1.2 must be a superset of the ciphers that can be
>     negotiated with TLS1.1 in any server configuration, and so on to SSL 3.0
>
>

I was talking about the way ciphers are structured on the server, but I 
think we agree because you accept the below "table" and use the word 
"overlap" (as oppose to superset).

>
>     I am not sure that this will always be possible. Let's say I must
>     offer RC4-MD5 for legacy products that only support SSL 3.0.
>
> don't support TLS 1.2, and that at least one of {X, Y}  is supported by
> by all TLS-1.2-capable clients that support TLS_FALLBACK_SCSV.
> (Approximately.)

Let's wait with TLS_FALLBACK_SCSV for a minute :-).

To be even more specific, let's simplify the above a bit:

        TLS1.2: X, Y
        TLS1.1: X
        TLS1.0: X
        SSL3.0: RC4-MD5

( SSL3.0 has only RC4-MD5, and RC4-MD5 is not in X or Y. )

If you accept that this is allowed on the server, for the purpose of the 
draft what's the server's maximum protocol version?

1. TLS1.2
2. runtime-dependent, the highest version that a given ClientHello and 
server's set of ciphersuites can possibly negotiate (e.g. ClientHello 
containing only RC4-MD5 --> SSL3.0).

Certainly, the server max. version is TLS1.2 is the simplest of two. 
However, this results in odd behaviour when the server is required to 
fail fallback handshakes with versions that are more secure than it 
could negotiate if TLS_FALLBACK_SCSV was not present.

Example, using the above table:

ClientHello: TLS1.1+RC4-MD5+TLS_FALLBACK_SCSV
Server: MUST fail

v.s.

ClientHello: TLS1.1+RC4-MD5
Server: negotiates SSL3.0+RC4-MD5

Had it been SHOULD fail for the server, the server could have noticed 
that this is not a downgrade that harms the security and allowed the 
handshake to continue.

---

From: Florian Weimer <[email-masked]>
Date: Sun, 26 Oct 2014 10:08:38 +0100

* Andrei Popov:

> Yes, there is some truth in what you say. Downgrade-SCSV is a hack,
> but it will be hard/impossible to convince browser vendors to stop
> doing fallbacks. Perhaps that's because browsers compete on
> interoperability and connectivity, not security?

There's some discussion about disabling fallback in this Mozilla bug,
but I don't know it will turn out because I'm not familiar with
Mozilla's processes:

  <https://bugzilla.mozilla.org/show_bug.cgi?id=1084025>

What's odd is that competing on interoperability should also prevent
other useful security enhancements, but it does not happen
consistently: disabling MD5 in certificates, minimum RSA key sizes,
stricter Same-Origin Policy enforcement, click-to-play, and, more
recently, disabling SSL 3.0 by default (only announced by Mozilla so
far).  So it appears that failure-inducing security improvements are
completely off the table simply because vendors fear that users will
just switch to a browser that happens to work.

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 27 Oct 2014 15:53:03 +0100

[...]

> draft what's the server's maximum protocol version?

Very clearly it is TLS 1.2, but I'll make it clearer in the next version of
the I-D to avoid any ambiguity.

Note that in fallback retries, clients might omit cipher suites (that don't
work with the older protocol version).  We don't want to the server to try
to be clever then and say "Well, this Client Hello doesn't look a fallback
after all because I only support these ciphers with older protocols".

> [...] However, this results in odd behaviour when the server is required
> to fail fallback handshakes with versions that are more secure than it

Maybe so, but I can live with that: this is not an arbitrary restriction,
but it follows from rules that serve the purpose they are designed for, and
it does not affect servers that follow the TLS specification.

Bodo

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 27 Oct 2014 11:22:10 -0400

[...]
> Server: negotiates SSL3.0+RC4-MD5

I think you've just demonstrated that the server is misconfigured in
this example.

Because of its misconfiguration, the server has selected SSL3.0 when it
could have selected TLS1.1.

(this scenario might have more nuance if we're talking about a TLS 1.3
specification that doesn't permit negotiation of RC4-MD5, but that's not
the scenario painted above)

----

In general, i don't have a lot of sympathy for the complaint that a
network failure causes fallback negotiation, which might fail.  Outside
of TLS, when a network failure causes a TCP session to abort, the
connection fails anyway.

We should have guidance to the implementer of any fallback dance that
the receipt of an inappropriate_fallback alert means you should clear
your notion of whether a given host needs a fallback.

In a browser context, this means that the user clicks "reload", and they
get a new try at the connection.  This is something users are familiar
with in other network-glitch scenarios.

     --dkg

---

From: Andrey Jivsov <[email-masked]>
Date: Mon, 27 Oct 2014 11:58:19 -0700

> could have selected TLS1.1.

... or it's a feature on the server to kill SSL3.0-era cipher when 
SSL3.0 is disabled in a browser

> with in other network-glitch scenarios.

I think that these fallback heuristics will contain false-positives. My 
thought was that if the server has SHOULD fail, it could do something 
like never fail on TLS1.1 and higher (or TLS1.2 when TLS1.3 is out). 
Otherwise one must accept that servers implementing TLS_FALLBACK_SCSV 
will contribute to higher number of failed handshakes.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 27 Oct 2014 15:17:22 -0400

> will contribute to higher number of failed handshakes.

The failed handshakes associated with false positive fallback behavior
are from network glitches, right?  not from poorly-implemented or
unmaintained servers.

in the face of a network glitch, user agents have three options (browser
behavior in parens):

 0) report the connection failure up the stack (browsers: show the user
the "try again button")

 1) automatically try the connection again, same as last time

 2) try the connection again with a fallback handshake

in the false positive cases that we're discussing here, (1) is probably
the best option.  doing (2) leads directly to choosing a degraded
ciphersuite.

including the SCSV with (2) gives the client an inappropriate_fallback
alert, which they can use to recognize the false positive situation and
do (1) instead.

	--dkg

---

From: [email-masked] (Martin Rex)
Date: Wed, 29 Oct 2014 03:35:28 +0100 (CET)

> are from network glitches, right?  not from poorly-implemented or

As you can see from 5-years-unfixed annoying broken connection management
in Firefox you should be able to see that a huge amount of problems
of false positives come from poor connection management and poor
heuristics, and some from middlelboxes.  network glitches are probably
quite rare.

> alert, which they can use to recognize the false positive situation and

This is a misunderstanding.  You may see much less of the
inappropriate_fallback alerts that you might believe you would.

Apps on top of transport-less SSL implementations, such as
Microsoft's IIS on top of Microsoft SChannel SSP has historically never
written any fatal alerts (from the SChannel SSP) to the network
before closing the connection upon handshake failures.

I don't know what the current state is, but if this behaviour is still
common with Micrsoft IIS, then asking the server to abort with
a fatal alert rather then continuing the handshake with a
ServerHelloExtension might have *MUCH* less of a chance to get
hotfixed into the installed base compared to purely TLS-internal
(i.e. SChannel-only) change similar to Renego-protection,
where the server continues the Handshake (provided that the negotiable
security parameters are still acceptable to the servers own policy),
leaving the decision whether to abort and reconnect up to the client
--because only the client is in the position to perform a reconnect,
and only the client has a chance to keep track on whether and how
often it is doing fallbacks and whether the fallback frequency crosses
some threshold that should not be exceeded without prior explicit
user confirmation.

Continuing the handshake would not require any app-level changes to Servers
that have not been writing fatal SSL alerts to the network before 
connection closure in the past, such as Microsoft IIS, so clients
with fallback heuristics will be in a *MUCH* better position to
recognize and distinguish accidental network glitches or connection
management bugs from attacks.  I expect the false positives to
outnumber attacks by at least three orders of magnitudes.

-Martin

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 29 Oct 2014 10:55:58 +0100

Martin Rex <[email-masked]>:

> heuristics, and some from middlelboxes.  network glitches are probably

I think you have mentioned that issue before, but I must admit that I am
not sure I understand what your concern is. If you are referring to
https://bugzilla.mozilla.org/show_bug.cgi?id=1072382, that's a bug that was
found and fixed *because* TLS_FALLBACK_SCSV was rolled out. How, then, is
this an argument *against* TLS_FALLBACK_SCSV semantics?

> before closing the connection upon handshake failures.

[Historically, I've even seen TCP RST for what should have been a clean
closure alert, meaning that it was up in the air whether the server's
application data would even be delivered to the client application. But
those servers were quite simply broken.]

> (i.e. SChannel-only) change similar to Renego-protection,

Why's that? If broken servers suppress the alert when they tear down the
connection, that's unfortunate, but they can still tear down the
connection. I wouldn't want to optimize for obsolete broken server
implementations at the expense of servers that get things right.

> outnumber attacks by at least three orders of magnitudes.

If there's an *actual* attack and the client doesn't continue with the
connection, the attacker can suppress alert details anyway. The alert (if
it gets through) is useful for heuristics; the only definitive protection
is from making sure that the client and server won't exchange application
data.

Bodo

---

From: Florian Weimer <[email-masked]>
Date: Wed, 29 Oct 2014 12:27:00 +0100

> this an argument *against* TLS_FALLBACK_SCSV semantics?

This bug in the fallback logic was actually reported in 2008:

My concern is that this bug has tainted the telemetry data collected
by Mozilla, and may have grossly exaggerated the need for fallback.
And as far as I can tell, the patch for bug 1072382 only makes the
fallback less sticky, it still does not result in better reporting of
fallbacks in telemetry data.

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 29 Oct 2014 12:34:02 +0100

Florian Weimer <[email-masked]>:

>   <https://bugzilla.mozilla.org/show_bug.cgi?id=450280>

Thanks! That makes it six years old (as a *known* bug -- presumably the
problem is older than that).

> by Mozilla, and may have grossly exaggerated the need for fallback.

The folks at Mozilla are well aware of this kind of problem, and that the
number of downgraded handshakes observed is inflated over the number of
handshakes that should have been downgraded.

Bodo

---

From: [email-masked] (Martin Rex)
Date: Wed, 29 Oct 2014 21:27:45 +0100 (CET)

> is from making sure that the client and server won't exchange application

I believe we're still talking past each other.

It will be impossible to protect the handshakes between two TLS peers
where one of them does not know about the FALLBACK_SCSV.

We're discussing purely the situation where _both_ sides are patched.

With the current proposal, the server is supposed to abort the handshake,
but with pretty much no useful information to perform any kind of sensible
risk management, no means to cause the client to retry with "more features",
and not the slightest clue what "more features" really means.

If instead, the server includes a ServerHelloExtension when recognizing
the Fallback SCSV, then the client will have *MUCH* better information
available to make sensible risk management:
   - only the client knows *which* features it actually omitted
   - only the client knows how often it has tried to perform the handshake
     (how long he has been doing the "downgrade dance") on the current
     request.
   - only the client can decide to perform another request with 
     more/better options than what the server picked and returned in
     ServerHello
   - only the client can tell the user/admin about what happend
     (how often and how far it attempted to downgrade) and obtain
     a confirmation whether to continue/retry or abort.

It's up to you / the WG to decide what the contents / semantics of
such a ServerHelloExtension should be, i.e. whether the presence
of the extension is a simple Boolean with a meaning closer to
the currently suggested fatal alert (i.e. an encouragement for the
client to abort and reconnect), or whether there should be a more
fine grained response, such as a structure that conveys the highest
protocol version of the server, whether the TLS server understands
and would appreciate TLS extensions or even a list of TLS extensions
that the server would _really_ like to see (such as ECC, SNI, ...)
or whether the server would really appreciate being offered
a larger variety of TLS cipher suites.

I've been doing customer support for almost 20 years, I'm not just
doing software development and maintenance, and the type of support
that I do includes analyzing and explaining to customers interop failures
when trying to access TLS-protected resources and suggesting them how
to change their configuration in order to obtain interop.

Interop failures that end with a fatal SSL alert or silent connection
closure are a royal pain to analyze, which is why I will never consider
a specification as the current one (neither on the client, nor on
the server side).   Both, as IETF TLS WG and as software engineer(s),
we can do *MUCH* better easily.

-Martin