Subject: Re: [TLS] 2nd WGLC: draft-ietf-tls-downgrade-scsv

From: Brian Smith <[email-masked]>
Date: Wed, 3 Dec 2014 15:37:07 -0800

On Tue, Nov 25, 2014 at 8:46 PM, Sean Turner <[email-masked]> wrote:
> This message initiates the 2nd WGLC for draft-ietf-tls-downgrade-scsv-02.   Please review the document and send your comments to the list by Friday, December 12, 2014.

The current draft [1] says "(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.)"

The text in the draft should be changed to read something like
"Clients SHOULD put the TLS_FALLBACK_SCSV after all cipher suites that
the client actually intends to negotiate."

Recently, it has been shown that it is problematic to put the
TLS_FALLBACK_SCSV cipher suite ahead of any real cipher suites in the
ClientHello, because doing so causes unintended handshake failures.

I don't know whether it matters whether the TLS_FALLBACK_SCSV appears
before or after the secure renegotiation SCSV (when the secure
renegotiation SCSV appears after all the cipher suites that the client
actually intends to negotiate).

Nit: The current draft says "Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions [...]." The "Section 4" in
that statement is a hyperlink to section 4 of the draft, but that is
clearly not what was intended.

Cheers,
Brian

[1] https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-02

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Dec 2014 16:29:37 -0800

Your edit makes sense.

> clearly not what was intended.

That's a tooling problem with the (obviously limited) html conversion,
not a draft issue.

---

From: [email-masked] (Martin Rex)
Date: Thu, 4 Dec 2014 03:16:47 +0100 (CET)

Brian Smith wrote:
> Sean Turner <[email-masked]> wrote:
>> This message initiates the 2nd WGLC for draft-ietf-tls-downgrade-scsv-02.
>> Please review the document and send your comments to the list by Friday,
>> December 12, 2014.
> 

That is silly.  I don't think there is such a weird recommendation
in rfc5746.

> ClientHello, because doing so causes unintended handshake failures.

This statement is self-contradictory.

The entire and only purpose of this I-D is to cause handshake failures,
which is why this entire proposal is currently totally bogus.

Should I ever make any changes to a server in response to this document,
then it will be continuing the handshake with
ServerHello.server_version = { 3, 1 } if it appears in a ClientHello
with ClientHello.client_version = { 3, 0 } plus a configuration setting
to keep the server igoring the fallback scsv entirely.

-Martin

---

From: Brian Smith <[email-masked]>
Date: Wed, 3 Dec 2014 19:03:31 -0800

Martin Rex <[email-masked]> wrote:
> That is silly.

This suggestion is based on implementation experience, known
interoperability issues, and testing that has been already reported on
this list and on the openssl-dev list.

> I don't think there is such a weird recommendation in rfc5746.

Apparently, there is not yet evidence that RFC5746 has similar problems.

> The entire and only purpose of this I-D is to cause handshake failures,

That is true, but *only* in a specific set of circumstances. The
problem is that handshake failures occur in other circumstances where
the draft does not prescribe a failure.

Cheers,
Brian

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 4 Dec 2014 09:53:52 +0100

Your edit makes sense.

Yes, I agree.

(The recommended behavior will be exactly the same, the change is only that
it will be explicitly RECOMMENDED using RFC 2119 magic words where the
current wording is possibly too vague, and certainly too complicated.)

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 4 Dec 2014 10:02:38 +0100

> The entire and only purpose of this I-D is to cause handshake failures,

No. The *purpose* is to prevent downgrade attacks. Handshake failures
(under certain circumstances) are the *means* towards that purpose.

When the server's highest protocol version doesn't exceed
ClientHello.client_version, this doesn't apply and there's no point in
aborting the handshake, regardless of whether and where TLS_FALLBACK_SCSV
appears. I see no contradiction.

Bodo