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

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 26 Sep 2014 04:00:04 +0000

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 26 Sep 2014 07:41:42 +0100

> 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've implemented this specification, and it's available in Firefox
nightly builds.  I found no issues with implementing from the draft.
It's basically ready.

I have one very minor concern.

The exception in Section 4 implies that there is some interoperability
reason to avoid including the SCSV in a resumption request.  I think
that it would be better if the actual interoperability problem.  That
is, your original session was made to a server instance that only had
a lower version and is being resumed on an instance that has a higher
version AND the node with the higher version doesn't treat a resumed
handshake differently with respect to the handling of the SCSV.
Alternatively, the server could have been updated since the original
session was established.

After some consideration, I think that the only issue with resumption
is that it is somewhat wasteful.  Requiring servers to ignore the SCSV
on resumption would work equally well.

I have a few minor editorial nits:
  - the lists in Sections 3 & 4 have a single item, which is a little odd
  - Section 4 should just say when to use the SCSV, rather than
announce "This section specifies when to send it."

---

From: Martin Thomson <[email-masked]>
Date: Fri, 26 Sep 2014 08:01:55 +0100

On 26 September 2014 07:54, Bodo Moeller <[email-masked]> wrote:
> What specifically do you consider wasteful?

16 bits, that's all.  Not a big deal (unless you are close to having to pad...)

> Note that ignoring the SCSV *on resumption* wouldn't quite work. The server
> would need to ignore the SCSV on resumption *attempts*, successful or not; I
> don't think I'd like that.

The draft requires that downgrade on resumption attempts (yes, you are
completely correct) is not guarded.  Whether that's a requirement on
the server or client doesn't seem like a big deal to me.

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 26 Sep 2014 08:54:26 +0200

Martin Thomson <[email-masked]>:

> that it would be better if the actual interoperability problem.

I think it would be better if the verb :-)

> That

Note that ignoring the SCSV *on resumption* wouldn't quite work. The server
would need to ignore the SCSV on resumption *attempts*, successful or not;
I don't think I'd like that.

> announce "This section specifies when to send it."

ACK.

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 26 Sep 2014 09:08:48 +0200

Martin Thomson <[email-masked]>:

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

> the server or client doesn't seem like a big deal to me.

Hm, I think I don't follow. Wouldn't having the server ignore the SCSV on
resumption attempts be strictly more wasteful than having the client not
send it?

The main thinking behind the draft, however, is that the server-side logic
should be as simple as possible, because I want *every* server to do this.
(What's more, I want every server to do it *correctly*.) The client-side
logic, in contrast, can be a bit more complicated: if your client never
does those fallback retries, you don't have to do anything.

Bodo

---

From: Martin Thomson <[email-masked]>
Date: Fri, 26 Sep 2014 08:22:26 +0100

On 26 September 2014 08:08, Bodo Moeller <[email-masked]> wrote:
> logic, in contrast, can be a bit more complicated: if your client never does
> those fallback retries, you don't have to do anything.

I'm OK with that, but if this is the real reason for the MUST, then
it's not particularly clear.

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 26 Sep 2014 09:34:46 +0200

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

Bodo

---

From: Andrei Popov <[email-masked]>
Date: Fri, 26 Sep 2014 17:44:51 +0000

This I-D currently forces clients to do sequential fallbacks, without skipping versions: TLS1.3->TLS1.2->TLS1.1->TLS1.0 will work, but e.g. TLS1.3->TLS1.2->TLS1.0 won't. Clients may want to skip protocol versions in the fallback sequence to reduce latency. Clients may also need to disable arbitrary protocol versions for security reasons.

I see two ways to fix this in the draft:
1. Use a TLS extension instead of an SCSV. In the extension, the client could indicate the previously attempted protocol version. The problem with this is that SSL3 ClientHellos are not supposed to have extensions, but we'd like to secure fallbacks to SSL3.
2. Use one SCSV value per TLS & SSL protocol version. The client includes the SCSV indicating the previously attempted protocol version. The drawback here is that this creates multiple SCSVs:).

If this problem is not solved, then clients will have no choice but to avoid sending the SCSV when skipping protocol versions, e.g.: TLS1.3(no SCSV)->TLS1.2(with SCSV)->TLS1.0(no SCSV). Which (at least partially) defeats the purpose of the I-D.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Joseph Salowey (jsalowey)
Sent: Thursday, September 25, 2014 9:00 PM
To: <[email-masked]>
Subject: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

Thanks,
J&S
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Adam Langley <[email-masked]>
Date: Fri, 26 Sep 2014 11:05:20 -0700

> If this problem is not solved, then clients will have no choice but to avoid sending the SCSV when skipping protocol versions, e.g.: TLS1.3(no SCSV)->TLS1.2(with SCSV)->TLS1.0(no SCSV). Which (at l…

We've had the design of an SCSV-per-version before and it didn't
really go anywhere. (There is, at least, ekr's draft[1].)

Yes, you have to step down every version. But stepping down is a good
idea because you want to lose as few features as possible. If you drop
right down to SSLv3 then you loose ECDHE and so on.

It's more latency, but only for the case of very old, broken servers. So be it.

[1] https://github.com/ekr/ietf-drafts/blob/master/draft-rescorla-tls-version-cs.txt

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Andrei Popov <[email-masked]>
Date: Fri, 26 Sep 2014 18:32:48 +0000

> But stepping down is a good idea because you want to lose as few features as possible.
This may well be, but arguably the TLS protocol should not be creating new constraints on the upper SW layers, where it's possible to avoid doing so.

Regardless of what the browser wants to do, the system admin will sometimes disable a specific TLS version machine-wide (or enterprise-wide), e.g. due to version-specific security concerns. I am pointing out that, with the current draft, the browser is forced to not send the SCSV when skipping versions.

Cheers,

Andrei

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Langley
Sent: Friday, September 26, 2014 11:05 AM
To: Andrei Popov
Cc: Joseph Salowey (jsalowey); <[email-masked]>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

> If this problem is not solved, then clients will have no choice but to avoid sending the SCSV when skipping protocol versions, e.g.: TLS1.3(no SCSV)->TLS1.2(with SCSV)->TLS1.0(no SCSV). Which (at l…

We've had the design of an SCSV-per-version before and it didn't really go anywhere. (There is, at least, ekr's draft[1].)

Yes, you have to step down every version. But stepping down is a good idea because you want to lose as few features as possible. If you drop right down to SSLv3 then you loose ECDHE and so on.

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Fri, 26 Sep 2014 11:37:20 -0700

> Regardless of what the browser wants to do, the system admin will sometimes disable a specific TLS version machine-wide (or enterprise-wide), e.g. due to version-specific security concerns. I am po…

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.

Cheers

AGL

---

From: Andrei Popov <[email-masked]>
Date: Fri, 26 Sep 2014 18:51:18 +0000

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

This may be true for the issues we know about today, and only taking into consideration protocol-level vulnerabilities. There are sometimes implementation-level bugs that affect a specific protocol version, and these are quickly worked around by temporarily disabling this protocol version.

In any case, the client app has a workaround (which is to not send the downgrade SCSV when skipping TLS versions). This workaround is far from perfect, but I can live with the current downgrade-scsv draft if I have to. In this case, the fix is pretty trivial, so I thought it was worth bringing this up.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Langley
Sent: Friday, September 26, 2014 11:37 AM
To: Andrei Popov
Cc: Joseph Salowey (jsalowey); <[email-masked]>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

> Regardless of what the browser wants to do, the system admin will sometimes disable a specific TLS version machine-wide (or enterprise-wide), e.g. due to version-specific security concerns. I am po…

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.

Cheers

AGL

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 26 Sep 2014 20:53:17 +0200

Andrei Popov <[email-masked]>:

> Regardless of what the browser wants to do, the system admin will
> sometimes disable a specific TLS version machine-wide (or enterprise-wide),
> e.g. due to version-specific security concerns.

That's not supported with normal TLS version negotiation either -- if the
client offers version X, the server may pick Y (< X) without having any way
of knowing that Y is disabled in the client whereas some other version Z (<
Y) is not.

If you really see a good reason to support this (which I don't) and are
concerned about latency, you'd already need some TLS extension to send this
information from the client to the server. I've never seen anyone propose
this, and would be skeptical about it.

I am pointing out that, with the current draft, the browser is forced to
> not send the SCSV when skipping versions.

I'd rather say that the client is forced not to skip versions when sending
the SCSV (and that this is a feature).

Bodo

---

From: Andrei Popov <[email-masked]>
Date: Fri, 26 Sep 2014 18:58:28 +0000

Ø  If you really see a good reason to support this (which I don't) and are concerned about latency, you'd already need some TLS extension to send this information from the client to the server. I've never seen anyone propose this, and would be skeptical about it.
I think all that needs to be done is for the client to signal the previously attempted version, via extension or SCSV. Rather than just saying “I’ve tried a higher version before”, which is what the draft allows now.

Ø  I'd rather say that the client is forced not to skip versions when sending the SCSV (and that this is a feature).
I agree that the client app is forced, but disagree that this is a feature☺.

From: Bodo Moeller [mailto:[email-masked]]
Sent: Friday, September 26, 2014 11:53 AM
To: Andrei Popov
Cc: Adam Langley; <[email-masked]>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

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

Regardless of what the browser wants to do, the system admin will sometimes disable a specific TLS version machine-wide (or enterprise-wide), e.g. due to version-specific security concerns.

That's not supported with normal TLS version negotiation either -- if the client offers version X, the server may pick Y (< X) without having any way of knowing that Y is disabled in the client whereas some other version Z (< Y) is not.

If you really see a good reason to support this (which I don't) and are concerned about latency, you'd already need some TLS extension to send this information from the client to the server. I've never seen anyone propose this, and would be skeptical about it.

I am pointing out that, with the current draft, the browser is forced to not send the SCSV when skipping versions.

I'd rather say that the client is forced not to skip versions when sending the SCSV (and that this is a feature).

Bodo

---

From: Brian Smith <[email-masked]>
Date: Fri, 26 Sep 2014 11:58:54 -0700

On Fri, Sep 26, 2014 at 12:34 AM, Bodo Moeller <[email-masked]> wrote:
> 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

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.

Now, if the server could indicate that it supports the SCSV somehow in
its ServerHello, then the client could save that acknowledgement in
the session state, and then make sure that it always sets
ClientHello.client_version to the highest version it supports,
regardless of the version that it negotiated for the session it is
trying to resume. That would be a very worthwhile addition to the
mechanism.

Cheers,
Brian

---

From: Brian Smith <[email-masked]>
Date: Fri, 26 Sep 2014 12:05:22 -0700

On Fri, Sep 26, 2014 at 11:58 AM, Andrei Popov
<[email-masked]> wrote:
> I agree that the client app is forced, but disagree that this is a featureJ.

I think the goal should be, in the long term, to remove the non-secure
downgrade bug from the clients. The semantics of the current draft are
aligned with that goal. Additional features were added to the
mechanism to allow for version skipping would be incompatible with
that goal. In other words, the feature/bug where the client system
administrator can disable arbitrary versions of TLS (e.g. TLS 1.0
enabled, TLS 1.1 disabled, and TLS 1.2 enabled) depends on the client
having the non-secure version downgrade bug, and thus seems like a bad
thing, all things considered. (We considered allowing that kind of
flexibility in the NSS API, and decided against it, for this reason.
So, in NSS, you can choose which range of versions to use, but you
can't poke holes within that range.)

Cheers,
Brian

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 26 Sep 2014 21:09:38 +0200

Andrei Popov <[email-masked]>:

> In any case, the client app has a workaround (which is to not send the
> downgrade SCSV when skipping TLS versions).

Well, that could sometimes be acceptable. Or do send the downgrade SCSV for
the version that you want to skip just to confirm that it's this server's
highest supported protocol, and then just use the previous version instead
(in a new connection). There's an extra latency penalty in this, but I
consider this version-skipping scenario very unlikely and we haven't ever
bothered to address this in standard version negotiation either (the client
can't send a list of supported protocol versions) and so have a similar
latency penalty there, so I don't think we should consider this a serious
drawback.

This workaround is far from perfect, but I can live with the current
> downgrade-scsv draft if I have to. In this case, the fix is pretty trivial,
> so I thought it was worth bringing this up.

You mean, version-specific SCSVs? I'd rather not do that, because then
there's much more to do (and possibly get wrong) in servers. And even if we
allocate a bunch of SCSVs for future protocol versions, at some point we
might run out.

(As an aside, if latency is the utmost concern, you don't strictly have to
try protocol versions in sequence -- you could do multiple connections in
parallel. However, that shouldn't be the norm. We *do* have version
negotiation in the protocol, after all. We shouldn't forget that the entire
fallback business is about servers that aren't just up to date with the
latest protocol version, but are exceptionally broken on top of that.)

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 26 Sep 2014 21:38:27 +0200

> > Hm, maybe so. I can add a brief note showing how the handshake would

*Could* fail, sorry. (As already explained by Martin, the problem appears
if by the time you try to resume, the server supports additional protocol
versions. Of course that could also happen for an immediate retry, and
you'll have to live with it then; so I wonder if that "MUST" isn't too
strict after all: if you're willing to start over
on inappropriate_fallback, you might actually prefer to send
TLS_FALLBACK_SCSV *in order* to get a connection failure if the server has
been updated.)

> trying to resume.

Hm, if you can set ClientHello.client_version to the highest version
supported by the client and the server tolerates that, you shouldn't be
employing the fallback mechanism with this server in the first place.

Bodo

---

From: Brian Smith <[email-masked]>
Date: Fri, 26 Sep 2014 13:02:52 -0700

>> On Fri, Sep 26, 2014 at 12:34 AM, Bodo Moeller <[email-masked]> wrote:

<snip>

> *Could* fail, sorry. (As already explained by Martin, the problem appears if
> by the time you try to resume, the server supports additional protocol
> strict after all: if you're willing to start over on inappropriate_fallback,
> you might actually prefer to send TLS_FALLBACK_SCSV *in order* to get a
> connection failure if the server has been updated.)

Right. In general, a resumption ClientHello SHOULD be just like a
non-resumption ClientHello, except for the presence of the session ID
and/or session ticket, because a resumption ClientHello is potentially
the start of a full handshake.

The TLS specs (TLS 1.2, in this case) say:

   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.

However, actually the client does not ever know the highest protocol
version the server supports, because the server may have expanded its
version support since the last time the client contacted it. But, the
consequence of that sentence is that at least NSS sends the session
version as client_version instead of its actual max supported version.
I think that is wrong. However, it isn't clear if there are
compatibility issues with changing that.

> employing the fallback mechanism with this server in the first place.

I had thought that NSS was changed to use the session version for
ClientHello.client_version during resumption for compatibility
reasons. However, looking at the change history, it appears to be the
case that that change was made coincidentally with a compatibility fix
for renegotiation, not initial resumption handshakes. So, it may be
the case that it is already safe to always send the max supported
version as client_version in an initial resumption handshake, without
any indication from the server, even in the non-secure fallback case.
It would require some implementation to make that change and test the
compatibility to know for sure.

Cheers,
Brian

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 26 Sep 2014 22:21:25 +0200

> I think that is wrong.

Well, arguably it is, but at least if you had to do an additional fallback
handshake just to successfully complete a handshake (which is the situation
we unfortunately have to concern us with here), you probably wouldn't want
to repeat this trial-and-error on every session resumption.

So if we accept that fallback handshakes can be a necessity, we also have
to accept that lowered client_version on resumption as a fact of life.

> So, it may be

If the server is version-intolerant for new sessions, why would it be
tolerant on (attempted) resumption?

Bodo

---

From: Brian Smith <[email-masked]>
Date: Fri, 26 Sep 2014 13:31:19 -0700

> tolerant on (attempted) resumption?

First, the client tries to handshake with client_version == TLS 1.2 and fails .

Then the client tries to handshake with client_version == TLS 1.1 and
succeeds, with the server choosing TLS 1.0.

Later, the client tries to resume the previously negotiated session.
It could choose client_version == TLS 1.1 (ignoring the session
version, but remembering the version intolerance), or it could choose
client_version == TLS 1.0 (using the session version). My argument is
that the client should choose client_version == TLS 1.1 and send the
SCSV.

Cheers,
Brian

---

From: [email-masked] (Martin Rex)
Date: Mon, 29 Sep 2014 21:33:06 +0200 (CEST)

Bodo Moeller wrote:
> parallel.

Ouch?

When using (EC)DHE cipher suites, then is the costly operation for the
server not already triggered by ClientHello?  I think it would be a bad idea
for *good* clients to perform multiple parallel connections to a server
that force the server through PK-crypto, because that hits the server
hard and makes it much more difficult for the server to distinguish
good and bad clients in order to perform self-defense when the server
is suffering from high load.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Mon, 29 Sep 2014 21:48:44 +0200 (CEST)

Martin Thomson wrote:
> completely correct) is not guarded.

Today's servers are permitted to completely ignore resumption requests
(and perform a full handshake instead) for protocol versions other than
the version that was used to create the (cached) session.  

Allowing resumption of cached sessions with different parameters
(such as a different protocol version or different cipher suite)
would look more like a server bug to me.

Or could this actually be abused as a "feature":
1. create a new TLS session with TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
   with a Windows 2008R2 Server (IIS).

2. propose resumption with the previously created session, but
   try to make server resume with TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256

for processing resumption, the key exchange portion of the cipher suite
would technically not strictly be necessary.  But the server may have
groomed his list of supported cipher suites (not having an ECDSA cert)...

-Martin

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 29 Sep 2014 22:06:33 +0200

> is suffering from high load.

That's a good point, so multiple parallel connections probably aren't a
useful suggestion. (At least with (EC)DHE enabled.)

Of course, since this is about fallback retries, it would only affect
version-intolerant servers; maybe we shouldn't have too much sympathy with
those :-)

Bodo

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Sep 2014 14:15:57 -0700

> version-intolerant servers; maybe we shouldn't have too much sympathy with

It's not always their fault.