Re: [TLS] An SCSV to stop TLS fallback.

Bodo Moeller <> Wed, 27 November 2013 11:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D8B741AE141 for <>; Wed, 27 Nov 2013 03:40:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.93
X-Spam-Status: No, score=-0.93 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XbFw-41zeABU for <>; Wed, 27 Nov 2013 03:40:07 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 760421AE135 for <>; Wed, 27 Nov 2013 03:40:07 -0800 (PST)
Received: from ( []) by (node=mrbap3) with ESMTP (Nemesis) id 0MYvSd-1W7rC21IXr-00V80a; Wed, 27 Nov 2013 12:40:05 +0100
Received: by with SMTP id m1so7527559oag.17 for <>; Wed, 27 Nov 2013 03:40:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=tUTklapNk9T+zk/NkzLDHFLWtU1QDFeJD1B50upBi9M=; b=F6K+2TxFx7nwo7sXDoHaxCuLnnTAJ36mmRqoQs9gZWaBBQy0dQmCHdyj8Uo4vEByBV 2dLkvgow0D2C6ljdDNrocixGpBV+I4pdLAYO2BKmrsWJmt4k0JBJSv/5lokyd6/1bgkf VIOLUCVbZ7jp+aH+g07LNPFXzkumiRLAp5zv4gmOhLODVsMU+yK4SLJZa9pM2n7CGGNP 4BZPeoZxWW5BrnGES3hGnyGoQP7hqkTMiWtlLT8LpnWKBWav2csOIG0KcNIemi99CNjR lXdqFVmxSOYiZ+gnfsurjIsRVEmyUx+MfXlDdUogy2qDlR5T0LbCXvh2B0u0fOe0faXn NTjw==
MIME-Version: 1.0
X-Received: by with SMTP id i8mr33508637oew.11.1385552404019; Wed, 27 Nov 2013 03:40:04 -0800 (PST)
Received: by with HTTP; Wed, 27 Nov 2013 03:40:03 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Wed, 27 Nov 2013 12:40:03 +0100
Message-ID: <>
From: Bodo Moeller <>
To: "" <>
Content-Type: multipart/alternative; boundary=047d7b33d548dc02c404ec270ec2
X-Provags-ID: V02:K0:8GRzv47Eb6pkXmdU6GQC5XMVqrJ0WS+UgA9N3PpySCD F0vGJuUMKW3NOc42WD5+SDWg/YyoGJyWFCpy/eF0zWvT00h5Jo Y1V53q13aODrEB+z9rldoTqsx5RgbziPHeb1409/c0TwUxu1vS sZMFZaFGhwdckH9VwbQODxurHLEAi3m79VqHuW9DJYzbe+smt1 M7UB39azNaOwy382Q0Q5oOVjUH/PbFAd1MbyFMt4hM9ZpIieNa IJWbXvqJ4Ja9DwuFUFSv1qV3tyCgka8a00FeI2cl8svOLNdhzF nGFCJsd2eLE/hfms9fdPxuVTi9B1fZcN3aTvo20B6JAw3cvsd0 oyP/MSNHMLmk9YBOtRF4hHd7DKVwpUfZhjSIf12VgqTTY+FRVP QjxxFe4gO2xBVQpArbddYXwdhQXp4nHNprYm3nTnqh0iSgW9W7 dc38O
Subject: Re: [TLS] An SCSV to stop TLS fallback.
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: Wed, 27 Nov 2013 11:42:21 -0000

Adam Langley <>om>:

> On Mon, Nov 25, 2013 at 7:52 PM, Andy Wilson <>
> wrote:

>  > I take it you're aware of
> >

 Yes thanks. My one sentence design is obviously very similar. I don't
> understand some of the extra logic for the server in Bodo's draft.

I think your new proposal corresponds to my original sketch for the SCSV's
semantics ("If you can read this, tear down the connection"), before I
actually wrote that Internet-Draft.

Writing the I-D, I realized that it would be a pity if, in case a need came
up to implement similar fallback strategies when deploying future protocol
versions, you'd have to wait for *another* document to specify *another*
SCSV to be able to prevent new protocol downgrade attacks, such as from TLS
1.3 to TLS 1.2.  Ideally all servers
implementing TLS_FALLBACK_SCSV/TLS_DOWNGRADE_SCSV would be fully version
tolerant, but obviously tolerance for *future* protocol versions is not a
server feature normally exercised in practice -- so to cope with the "Universal
Rule of Users", we'll have to assume that some servers may be around that
aren't fully version tolerant, while working perfectly as far as said Users
are concerned.  Hence the server logic to compare the client's protocol
version to the server's supported protocol version: if the client is
falling back to the server's highest supported protocol, that's not a
malicious protocol downgrade.

Similarly, implemented in TLS 1.2-intolerant servers,
draft-bmoeller-tls-downgrade-scsv-00 could prevent a rollback from TLS 1.1
to TLS 1.0 without breaking interoperability with clients employing a
fallback strategy (and using the SCSV); in TLS 1.1-intolerant servers, it
could prevent a rollback from TLS 1.0 with TLS extensions to TLS 1.0
without TLS extensions without breaking interoperability.  As you've noted,
if the SCSV is used by widely deployed clients first, we won't have to
worry about interoperability with such servers (because the vendors will
notice that their servers are broken before they get deployed).

So in that case, the special logic for client_hello_extension_list can be
removed from the specification (yay!); only the version comparison needs to


PS: Needless to say ...

1. None of the above is meant to imply that I think of TLS version fallback
as a protocol feature meant to stay.  Rollback connections *are*
an abomination -- the I-D is all about what to do *if* we find ourselves in
the sad situation of having to reconnect for interoperability.  If we
manage to get rid of the need for that, all the better.

2. None of the above is meant to imply that we shouldn't retrofit secure
ciphersuites to older protocol versions.  This, too, seems pretty much
orthogonal to what this I-D is all about.  (A TLS 1.0 client hello
proposing only secure ciphersuites wouldn't need the SCSV.)