Re: [TLS] Downgrade protection, fallbacks, and server time (Martin Rex) Mon, 06 June 2016 16:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C45E012D82D for <>; Mon, 6 Jun 2016 09:25:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 83aSZpZDO1tO for <>; Mon, 6 Jun 2016 09:25:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0CCF412D84B for <>; Mon, 6 Jun 2016 09:25:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 89AE644361 for <>; Mon, 6 Jun 2016 18:25:18 +0200 (CEST)
X-purgate-ID: 152705::1465230318-0000082D-1CCFF146/0/0
X-purgate-size: 3295
X-purgate: clean
X-purgate: This mail is considered clean (visit for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R)
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ( []) by (Postfix) with ESMTP id 7BCA7428F4 for <>; Mon, 6 Jun 2016 18:25:18 +0200 (CEST)
Received: by (Postfix, from userid 10159) id 492BD1A4E0; Mon, 6 Jun 2016 18:25:18 +0200 (CEST)
In-Reply-To: <>
Date: Mon, 6 Jun 2016 18:25:18 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
From: (Martin Rex)
Archived-At: <>
Subject: Re: [TLS] Downgrade protection, fallbacks, and server time
X-Mailman-Version: 2.1.17
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, 06 Jun 2016 16:25:45 -0000

The IMO most reasonable way forward would be to side-step the
TLS version negotiation through ClientHello.client_version
entirely, because of the well-known interop problems.

Simply use the presence of *ANY* TLSv1.2+ TLS cipher suite in the
offered list of TLS cipher suites as an indication that a TLS client is
capable and willing to actually _use_ TLSv1.2, even when
ClientHello.client_version might indicate (3,2) or (3,1) for
better interop.  The same approach will work for TLSv1.3,
where the presence of a TLSv1.3 could be used to tell the server
that the client is capable and willing to talk TLSv1.3, even when
ClientHello.client_version might indicate a lower version of the

Only the client is in the position to decide whether aborting
the TLS handshake and retrying with a more feature-creeping ClientHello
could provide additional benefits to the client (that it previously
didn't offer, for whatever reason), and only the client is in the
position to know how many TLS handshake attempts with which properties
it previously attempted, and when to better stop retrying automatically
and silently and to perform risk management (such as warning user/admin
that something odd is going on).

To get a smooth migration to using newer TLS protocol versions, we
first need to define a scheme that lets new implementations recognize
each other without upsetting the installed base.  We know what works,
the code points already exist, we will just have to align the documented
semantics to provide a more forward-interoperable and more reasonable

Viktor Dukhovni wrote:
>> David Benjamin <>; wrote:
>> I'm not sure I follow. The specification certainly spells out how
>> version negotiation is supposed to work. That hasn't stopped servers
>> from getting it wrong. Fundamentally this is the sort of thing where
>> bugs don't get noticed until we make a new TLS version, and we don't
>> do that often enough to keep rust from gathering.
> A better way to keep rust from gathering is to not instutionalize fallback,
> force the broken sites to deal with the issue.

It's not the sites, but rather the software vendor providing the
underlying TLS implementation.  Sometimes you don't actually have
a choice and an alternative to using what exists.

> While 2% is noticeable, you can probably drive 1.3 version intolerance
> out of the ecosystem relatively quickly if Chrome implements fallback
> for a limited time (say 6 months after TLS 1.3 RFC is done) and with
> a diminishing probability (60% first month, 10% less each month
> thereafter), season to taste.

There exist various different flavour of TLS version intolerance,
and the amount of defective servers out there is probably much larger.

The entire installed base of Windows 2008R2 and Windows 20012R2
is TLS version intolerant with respect to TLSv1.2.

If you send propose TLSv1.2 inside an SSLv2Hello to such a server,
it will negotiate TLSv1.1 (rather than TLSv1.2).  If you send
an extensionless SSLv3 Hello proposing TLSv1.2, these Windows
server with choke and close the network connection.  An extension-less
SSLv3 Hello with at client_version = TLSv1.1 or TLSv1.0 will succeed.