Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard

Brian Smith <> Mon, 19 January 2015 20:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 20ACC1B2C5A for <>; Mon, 19 Jan 2015 12:58:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.321
X-Spam-Status: No, score=0.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MANGLED_LOW=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id trlektEdnkk1 for <>; Mon, 19 Jan 2015 12:58:29 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 06B851ACDE7 for <>; Mon, 19 Jan 2015 12:58:29 -0800 (PST)
Received: by with SMTP id gq1so30870649obb.12 for <>; Mon, 19 Jan 2015 12:58:28 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=smN6GrFzKd7jSypLbQsII6ozcj+cRv6tu9Uoq6hPEQY=; b=gR0WTip40RmD5/8NQ86NTjYukhVTgOzzoNz2xb5pl0h5xCQOQTXZIohSjJgKrq1U7t wrv4+/ccjCNj+xE8k6nEhtrx2zlMk9MRNmrRD3FzTcssGceR7+jsYX1xCbi0ztSIKZp9 ooN3l/Am+dMJMCahV25MMnF13PpjNgIfHu0aknXO89e90ourl73q4NL8OGecrL/nPDEv NjmiHkcIyzaQirrh33CXwnjnXpiB7vSQi9mqUGAh+OPhq2khhERWgLv/LfE8TfzteTOR JwJZzu83E9zh22SGG9n+Y8Acm7lj2XTPKnHV0jaTY3pcuBIUV70yJbfbM4F5ITyVj617 mL8Q==
X-Gm-Message-State: ALoCoQnS2FsbQ0BCnsuF6mybo+akGUZR2AznaDyRcGQIVtqGQ69uh9VmbzUAVsXb77WjOuWTqXwR
MIME-Version: 1.0
X-Received: by with SMTP id r136mr12960404oie.92.1421701108471; Mon, 19 Jan 2015 12:58:28 -0800 (PST)
Received: by with HTTP; Mon, 19 Jan 2015 12:58:28 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Mon, 19 Jan 2015 12:58:28 -0800
Message-ID: <>
From: Brian Smith <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Jan 2015 20:58:33 -0000

Martin Rex <> wrote:
> Permitting the server to continue the TLS handshake with
> ServerHello.server_version = (ClientHello.client_version +1)
> This would be an extremely small change, but a *HUGE* improvement to this
> proposal and make TLS handshakes _succeed_, i.e. promote interop.

This doesn't work. Consider this example of how your suggestion would work:

Client and server both support TLS 1.2.

Client attempts TLS 1.2, receives RST.
Client attempts TLS 1.1 w/ downgrade SCSV, receives RST.
Client attempts TLS 1.0 w/ downgrade SCSV, receives TLS 1.1 ServerHello.

This results in a downgrade from TLS 1.2 to TLS 1.1.

> Should a TLS client be unsatisfied with the properties of the resulting
> TLS session, that client could still decide attempting a new/different
> handshake by proposing additional features in ClientHello (that should
> have never been absent from ClientHello in the first place).

I think at this point browsers are only "satisfied" when the
connection is TLS 1.2 using an AEAD cipher suite, but they still feel
the need to support servers that only support worse crypto. So, this
part of the idea doesn't work either.

> It's not that suggestions to improvement to this proposal haven't been
> made.  It's really disappointing to see this go _through_ the TLS WG
> and not seeing any improvement whatsoever, and then going straight
> to asking for rubber-stamping it.

I don't think that the characterization of "rubber-stamping" is
accurate or helpful for moving the discussion forward.

I DO think it would be useful for the IETF to wait ~8 weeks to see the
results of Firefox's experiment in disabling the non-secure fallback,
and to see the results of studies of TLS 1.3 intolerance with
ClientHello messages with different record-level version numbers. If
it turns out to be reasonable for web browsers to stop doing the
non-secure fallback, then it really would be bad policy for IETF to
make the downgrade a proposed standard, because the downgrade SCSV
will always be limited in effectiveness by the fact that a huge number
of servers will not deploy the downgrade SCSV mechanism any time soon.
Still, it's not clear yet that web browsers can reasonably stop doing
the non-secure fallback, so I think it makes sense to have the
downgrade SCSV mechanism ready as insurance.