Re: [secdir] SecDir review of draft-ietf-tls-downgrade-scsv-03

Bodo Moeller <> Sun, 18 January 2015 20:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 281C81ACE17; Sun, 18 Jan 2015 12:56:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ee0Sl0MpobB8; Sun, 18 Jan 2015 12:56:17 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA78D1ACD13; Sun, 18 Jan 2015 12:56:16 -0800 (PST)
Received: from ([]) by (mreue005) with ESMTPSA (Nemesis) id 0LtBoV-1XlPLJ2y8R-012r8N; Sun, 18 Jan 2015 21:56:14 +0100
Received: by with SMTP id hz20so3512392lab.3; Sun, 18 Jan 2015 12:56:09 -0800 (PST)
MIME-Version: 1.0
X-Received: by with SMTP id ry9mr26535361lbb.4.1421614569148; Sun, 18 Jan 2015 12:56:09 -0800 (PST)
Received: by with HTTP; Sun, 18 Jan 2015 12:56:09 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Sun, 18 Jan 2015 21:56:09 +0100
Message-ID: <>
From: Bodo Moeller <>
To: Yoav Nir <>
Content-Type: multipart/alternative; boundary=089e011836aa66dbb6050cf36ff8
X-Provags-ID: V03:K0:MykFgAfhUYaOHbJReBn772e9Ilz82b+4nPvv0VsOEGghBuXQVXP xJ+W9Gv+VNz7VyD1HvPtx/GVzIrjDGkMjHj8YICUFoOybj4mzyoajKAiMcqMM4LFa8OmisP ivm5s2EINXjRLAat0by9cR8pl0St4pNDgyOAD9SHVJv67Gf++GHChN8fYo5jExGPjzqR8Bh MMTSuMswNLhG9zmEjmVuA==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <>
X-Mailman-Approved-At: Sun, 18 Jan 2015 12:59:16 -0800
Cc: "" <>, The IESG <>, Adam Langley <>, secdir <>
Subject: Re: [secdir] SecDir review of draft-ietf-tls-downgrade-scsv-03
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 18 Jan 2015 20:56:19 -0000

Thanks for your comments, Yoav!

> The Security Considerations section has some strange text about omitting
> the SCSV when "the protocol version given by ClientHello.client_version
> still provides an acceptable level of protection". This implies that it is
> appropriate to use a protocol version that does not provide and acceptable
> level of protection as long as the client sends the SCSV. This is not the
> case, and this is the reason that several browsers are disabling the
> downgrade to SSLv3. I realize it is difficult to write text that turns the
> secure/insecure dichotomy into a trichotomy (secure/so-so secure/insecure),
> but if we're going to make including the SCSV optional we need such text.

Could you make a concrete (if rough) suggestion for what you'd like to see
in the document?  Note that the text that you cite above was essentially
contributed by one of the WG chairs :-) [*]  Personally, I don't see a need
for additional text because I think that the document already makes it
quite clear that the reason why a client might tolerate an otherwise
unacceptable level of security when sending the SCSV is as a last resort
for connections to legacy servers.

Regarding your statement that "this is the reason that several browsers are
disabling the downgrade to SSLv3", I don't agree.  If TLS_FALLBACK_SCSV was
already widely deployed in servers, browser vendors would have had a much
less pressuring need to disable the downgrade to SSL 3.0 entirely -- with
the SCSV, SSL 3.0 would have been exclusively about hopeless legacy servers

A scenario that bothers me is a server that returns an
> inappropriate_fallback whenever it receives a TLS_FALLBACK_SCSV with
> version TLS 1.1, but breaks at TLS 1.2. Such an (admittedly broken) server
> could potentially send the client into an endless loop of regular and
> fallback handshake attempts. An attacker could simulate this by RST-ing all
> TCP connections with TLS 1.2 in ClientHello. I think the draft should warn
> against doing the regular-fallback-regular cycle more than once. IOW: after
> receiving the alert, clients MUST NOT perform the downgrade dance on the
> following connection.

The problem is, the alert is not authenticated.  (We'd have to complete the
handshake to authenticate it.)  So a "MUST NOT" can't be right: if a
browser users tries to access a web page a second time after the above
failure, it's appropriate for the client to perform the entire downgrade
dance again if needed.  Implementors shouldn't go into infinite reconnect
loops, but I don't think there's anything special here about

> Nits and minor issues:
> Since the client speaks first, it would make sense to have section 4
> (Client Behavior) before section 3 (Server Behavior). Section 3 describes
> how the server responds to this SCSV when the document had only hinted
> about when the client should send it.

My rationale for describing server behavior before client behavior was that
I think this makes it easier to read the document, given that server
behavior follows simple, concrete, and strict rules. After you've read
those in the Server Behavior section, I believe it will be much easier to
make sense of the (more complex) section on Client Behavior.  If you don't
know what server behavior TLS_FALLBACK_SCSV triggers, my fear is that the
Client Behavior section will seem very esoteric, abstract, and nebulous.

> The IANA Considerations are very confusing, saying on the one hand that no
> values have been allocated, and on the other hand that IANA has assigned
> 0x56,0x00. Unless the authors are requesting that IANA assign the numbers
> that they have used in early implementations, it's better to just write
> "IANA is requested to assign..." and replace the numbers in the rest of the
> documents with TBDs (if you leave actual numbers and IANA assigns different
> identifiers, it's likely to be overlooked by the RFC editor).

Right, the point is specifically to use the numbers that have been used in
existing implementations.  Isn't the "TO BE REMOVED" note rather clear
about that?  In any case, the contradictive part obviously isn't meant to
go into the final document -- the current form is meant to show the
intended final document text while also making it clear that IANA hasn't
yet assigned anything.

> A few missing articles:
> "The fallback SCSV defined in this document is not *a* suitable substitute"
> "if *the* TLS implementations also include support for (the) predecessor
> protocol SSL 3.0"

I don't think either of these is technically necessary, but I'l entirely
leave the decision about these articles to my co-author :-)  (In the first
case, by the way, it's again language contributed by said WG chair. [*])


[*]  No intent to shift any blame: I think the current text is fine, or I
wouldn't have used it.  However, this lets you know who's in a special
position to convince me to change that wording.