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

Wan-Teh Chang <> Wed, 04 December 2013 18:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 00FE61AD943 for <>; Wed, 4 Dec 2013 10:59:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5X8fM_xcxkhw for <>; Wed, 4 Dec 2013 10:59:27 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c03::22d]) by (Postfix) with ESMTP id 65AD71AD8F4 for <>; Wed, 4 Dec 2013 10:59:27 -0800 (PST)
Received: by with SMTP id ia6so12087910vcb.32 for <>; Wed, 04 Dec 2013 10:59:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qbiXRsiQ5OxlUb/caVEx9Qpg4jF4hvqK1WB/fOAxoyE=; b=JtDelzAlSJ7SevyIeUJcTLTPlLRudR9Csfq9iqOx5qkDIYNiR0Yt1HRHV4/nGBERTH Qu7WfktN7sqKN6HyyxD+JJieBKl0woNpAU5cBwMjWpSNQjmIIMyZ7LLuEhlh4eFCJ7KH DkYFns4zIFOz57YRQhTIB7bKr0kN3PX8nZRy6FmBlb7G4z+Vm4KdOUPQhrESbtKVcOnQ FZeXsq+kGZy8Vkyi3V3bZlJJwvQ+sSkncK7Ia8lLJu7crlfeaLslXtvr/FGqAjwzI9Ck G5mzOPaq/cY9kNIqTRf6VDGjREe7S35QovvmZumrUTc7ETcsZWxEB/WbsnBs+XK/SS/p KwVA==
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=qbiXRsiQ5OxlUb/caVEx9Qpg4jF4hvqK1WB/fOAxoyE=; b=XgHSUoMQK0bSh7dQzAnVGV1CP20rN5BzdfEKo6LbIPsbZcCCVtoGZfFWn/WX8ufcGa muGls6bBfVBUEE9qHbI/IeqSecwqV1yPDVto8KpFnAbxJW40CIBOCFa9ZDBd1bjBAs7x mwBgxd2oK2HZKXNxh1xQZYuhwe1iDiMXF6IjrhgXGx7IG4h+aMQQbITC2gS2EgxWkTVZ OLKcgJSYM673Y1RxoOrF4jinmtsXeHL+6Fkr5Q6NN9QjA2PqlgBYUx+03jqIF91QmgUj NiejJyxXMqPhkPdk93Ms2LQmLl0cpoDWWmvKXhXw5dxn2kFv9VUM9U50JdWIMyZrBQor fTWA==
X-Gm-Message-State: ALoCoQmw4H7UWn2dyu1eUGQ38QJ4k/z1Ywnnf9/5B75efy/QjX53asxlVRfJ06x293iDo1iEtfwpjU1scJBAtUcMnFfqiZRb6JYVXuRMXBO/8greMnawSgFOLcD/Jy1o7yvq2wtdfT15/HHex+Mq3O8VC9UzixQQIxeSwGqSq3WxWqPYoRBWNQLpXObeqihp5fI7f9MJ9eAl
MIME-Version: 1.0
X-Received: by with SMTP id r7mr60622436vcr.12.1386183563876; Wed, 04 Dec 2013 10:59:23 -0800 (PST)
Received: by with HTTP; Wed, 4 Dec 2013 10:59:23 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Wed, 4 Dec 2013 10:59:23 -0800
Message-ID: <>
From: Wan-Teh Chang <>
To: Bodo Moeller <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "" <>
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 18:59:29 -0000


Thank you for your reply.

1. Re: a TLS extension vs. a SCSV:

I asked about an extension partly because RFC 5746 uses a dual
extension-SCSV approach, and partly because I wondered if it is useful
for the client to indicate its actual highest supported version in an

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.

2. Re: the less strict server behavior you specified:

I realized that my example of a client and a server with an
interfering middle box has mistakes. I am sorry that I wasted your
time analyzing an incorrect example.

In spite of my mistake, your reply answered my question, here:

On Wed, Dec 4, 2013 at 1:50 AM, Bodo Moeller <> wrote:
> Moreover, if servers were to reject connection attempts with
> TLS_FALLBACK_SCSV arriving in their native protocol version, this might
> cause a new interoperability nightmare in the future.  Current server
> implementations will generally be tested with TLS 1.2 clients, but not
> necessarily with clients that send a version number such as 0x03 0x04 (TLS
> 1.3) or 0x04 0x00 (TLS 2.0?).  They are broken if they don't support that,
> but preventing such broken servers from getting rolled out is outside of the
> scope of, and not in the power of, this specification.

I don't fully agree with this rationale. 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:

   TLS servers implementing this specification MUST ignore any unknown
   extensions offered by the client and they MUST accept version numbers
   higher than their highest version number and negotiate the highest
   common version.  These two requirements reiterate preexisting
   requirements in RFC 5246 and are merely stated here in the interest
   of forward compatibility.

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.

> Regarding making the draft clearer, I'm considering adding two or three
> example cases to the Internet-Draft to discuss how and why
> TLS_FALLBACK_SCSV will allow certain fallbacks and disallow others.

Yes, explaining why you want to allow certain fallbacks would be
helpful, because most people's first thought (as evidenced by my
question and Eric and Adam's old proposals) is to specify a strict
server behavior.

3. Re: the Security Considerations section:

Thank you for explaining what the CBC weaknesses you referred to are.

On second thought, I now suggest that the Security Considerations
section should only consider the security issues of TLS_FALLBACK_SCSV
itself. The section doesn't need to describe the security weaknesses
of SSL 3.0 or older versions of TLS. I agree that would be a
distraction from the simple TLS_FALLBACK_SCSV mechanism specified in
the draft.

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?

Wan-Teh Chang