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

Bodo Moeller <> Wed, 04 December 2013 21:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2BA271AE334 for <>; Wed, 4 Dec 2013 13:05:36 -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 94Sz5HiuQmeg for <>; Wed, 4 Dec 2013 13:05:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id F201D1AE30A for <>; Wed, 4 Dec 2013 13:05:32 -0800 (PST)
Received: from ( []) by (node=mreu2) with ESMTP (Nemesis) id 0LwmZo-1VYrDc0pwW-016JMo; Wed, 04 Dec 2013 22:05:28 +0100
Received: by with SMTP id wn1so16673604obc.19 for <>; Wed, 04 Dec 2013 13:05:27 -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 :cc:content-type; bh=iO1gV/669D5mREPhHhBIgYrGjqYBxcfoLqU1FsqZCxM=; b=Hxh312sTh92GiCyJFzAwYTsJZ4drvwp3z9Yab1/4NULc2k87t2qhnAAIJ/ThYVX6X6 p1Kg9x3yzW4F0+TrCyITwgEI7/LbVzhpFhhLz8x/Cf12W3jc0qm20NnhZvwpa85iDPIU PwuGA/1QKOZP4VUF4lgRnezdwwhh5d1xa0oc5x3rl69Nk9NvtfdsnBYxJrLNW9qvDJJ+ mcRMPmKSPlGC57WY4rHqMs6GAGlkwk+qV8tKTLKGuBaeOZYHhJ1wEcipSUDywPDBH2uU G1x4pXtY7ivS34FjbmruMiV0I9zkW3gvkDq/a4rp050z54GqS15+hmQPtEqc7OtI8nWU UDpw==
MIME-Version: 1.0
X-Received: by with SMTP id qr5mr15846019obc.41.1386191127003; Wed, 04 Dec 2013 13:05:27 -0800 (PST)
Received: by with HTTP; Wed, 4 Dec 2013 13:05:26 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
Date: Wed, 4 Dec 2013 22:05:26 +0100
Message-ID: <>
From: Bodo Moeller <>
To: "" <>
Content-Type: multipart/alternative; boundary=f46d0444ee69b74bc104ecbbc5c5
X-Provags-ID: V02:K0:WQlZ8Dm6+C/+UOj3T5wd/TqHDTrSh220iSiza/4dqZm Yzx5UTp6dlj0uILQNLmgl2d3vIS8QsCm+ogQ1zI4VMa6CuAesW 5nz+K3h+zXptoC218i1pv5I/msOOxyuFaag2Pk1ZFSe0WakHB3 rW9bmHXLsiV0MXCl6iVjGvZDDiTQyBPTaeTGwpEGJphYsV1I5q U3Ni7kUIEOI0snwGTydGa8PKX1bm8z1/5A+ANo/NpIhIrokh1r hTmYfVleIvO5YlPZfY/M328fkEyKRA+PpzoFqVX10HMqDi7H2b mZx+00QQl5dj4tVn0ZI952o/XmZZZzUu/70bumRCS6Gx2B6uRq h5m1sGWbSKJ93ZnRMgQthMMs83c6Ua8+2q+Gbgqtq7KfGlvnHd iwMxthpNFZLeb5SOL2YzSLu3lUXUxst2w79DFuUI8TFaxGa6xy qKeZR
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, 04 Dec 2013 21:05:36 -0000

Wan-Teh Chang <>om>:

> However, I can't come up with a reason why the client's actual highest
> version is useful to a server. Although Eric Rescorla and Adam's old
> proposals ([1] and [2]) also included the client's actual highest
> version (which necessitated multiple, version-specific SCSVs), careful
> analysis of their old proposals showed that that version is only
> compared with ClientHello.client_version. The boolean result of that
> comparison is equivalent to your TLS_FALLBACK_SCSV.

Right. This single SCSV is the simplest tool that does the job (and because
it is simple, also easy to get right in implementations).

The work to implement TLS
> version negotiation correctly should be similar to the work to add
> support for TLS_FALLBACK_SCSV. Why don't we require that servers that
> support TLS_FALLBACK_SCSV must also do version negotiation correctly?
> RFC 5746 has such a requirement:

All standards-compliant TLS servers are already required to do version
negotiation correctly -- otherwise they wouldn't be standards-compliant TLS
servers :-)  The problem is, something that *appears* to be a
standards-compliant TLS server (and acts exactly like a standards-compliant
TLS server, as far as interactions with current standards-compliant TLS
clients are concerned) may not actually be standards-compliant: current
standards-compliant TLS clients won't ever indicate version TLS 1.3, so
incorrect protocol version negotiation behavior wouldn't be obvious.

Also remember that even if the actual TLS server implementation is
standards-compliant (in particular, version tolerant), a middlebox may
break that, by rejecting ClientHellos with versions that it doesn't
understand.  Such middleboxes clearly are broken, but that alone doesn't
prevent them from getting deployed.

Do you think it is reasonable for a server to reject a currently
> undefined ClientHello.client_version (such as TLS 1.3 or TLS 2.0)? Or
> do you think that if something is not tested, it is likely to be
> broken? Although I think the latter is true in general, in this
> particular case, I think the risk is low. So you are taking a very
> conservative approach.

I don't really think that it is *reasonable* for a server (or middlebox) to
reject that, but I wouldn't want to bet the usefulness
of draft-bmoeller-tls-downgrade-scsv-01 on servers (and middleboxes) being
that reasonable.

> 4. Why do you not use the server's support of the renegotiation_info
> extension as a signal ([3])? Is it because you want to allow servers
> to opt in to the fallback prevention mechanism?


I don't want to allow servers to opt in to or opt out of TLS_FALLBACK_SCSV.
 Rather, I want *all* servers to be strict about TLS_FALLBACK_SCSV -- hence
the word "MUST" in the specification of server-side behavior.  This allows
client implementations to send or not send the SCSV based on their security
needs (the draft says that clients SHOULD include
ClientHello.cipher_suites when falling back to a lower protocol version,
where the word "SHOULD" means that "there may exist valid reasons in
particular circumstances to ignore a particular item, but the full
implications must be understood and carefully weighed"; RFC 2119).

I don't think that the server's support of the renegotiation_info extension
is necessarily the right signal in practice: for example, if the server
supports it, you might still be deploying a broken version-intolerant
middlebox without anyone noticing that something's wrong.  Maybe, as
described in draft-pettersen-tls-version-rollback-removal-02, such breakage
will eventually become irrelevant in practice, and thus we'll avoid the
need for fallback connections: once we're there, TLS_FALLBACK_SCSV wouldn't
generally be seen on the wire in normal usage (servers would still watch
out for it, but if no client has a need to fall back to earlier protocol
versions, it wouldn't ever be sent).  In this case,
won't be doing any harm (it merely requires a small amount of additional
server-side logic).  Well, upon starting to deploy TLS 1.3 or any other
future version, the future us might find out that there *is* then a (new)
need for fallback connections after all, to allow clients to try TLS 1.3 in
the presence of version-intolerant servers and/or middleboxes that, up to
then, didn't appear to be broken.  In that case, the TLS_FALLBACK_SCSV
mechanism will be useful again, until all the version-intolerant servers
and middleboxes have been removed.  Rinse, repeat: with each new protocol
version, TLS_FALLBACK_SCSV may become relevant again until all servers and
middleboxes intolerant to that new protocol version have been evicted from
the internet.

Generally, getting something like TLS_FALLBACK_SCSV deployed on *many*
servers (so that clients can benefit from it at least for many of their
connections) seems more easily feasible than getting rid of (nearly) *all*
broken servers and middleboxes (so that clients can live entirely without
protocol fallback strategies).  So TLS_FALLBACK_SCSV certainly can be
deployed much quicker (if you are interested in keeping some
interoperability with broken servers -- which of course is why protocol
fallbacks are an issue in the first place): To newly roll it out on a
server, you have to make sure that that server (and any middleboxes
handling the traffic to it) support or tolerate the *currently* deployed
TLS versions, which something that you'd automatically be observing in
standard interoperability testing (as long as you use a client supporting
the current TLS version, with TLS_FALLBACK_SCSV for any protocol fallbacks).

As I've said before, you can do both: deploy TLS_FALLBACK_SCSV for best
security even if protocol fallbacks are sometimes necessary; deploy
to get rid of the need for those fallback connections as soon as we can.
 There's no conflict between these, rather they complement each other --
draft-pettersen-tls-version-rollback-removal-02 doesn't seem right as a
security fix (because (1) you'll have to clean out broken servers and
middleboxes from the internet before you can actually deploy it, and (2)
once we've fixed the internet accordingly, a new TLS version may surface
more breakage), while draft-bmoeller-tls-downgrade-scsv-01 does nothing to
avoid those protocol "downgrades" in which you're only falling back to the
protocol that should have been negotiated anyway.