Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

Dave Garrett <> Fri, 03 June 2016 20:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A6B112D165 for <>; Fri, 3 Jun 2016 13:16:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id okLAgpzGLOzW for <>; Fri, 3 Jun 2016 13:16:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 23D0D12D100 for <>; Fri, 3 Jun 2016 13:16:17 -0700 (PDT)
Received: by with SMTP id o16so90822794ywd.2 for <>; Fri, 03 Jun 2016 13:16:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:cc :mime-version:content-transfer-encoding:message-id; bh=ELS173TNnKo/cbgYpTDZe6t7UOdxR4kGHU5ChRh2Kxo=; b=YpNSCjMURD/MSxcmKeexfcdrOuvCkp2KG+bj4gwtNAMVgyVp/G+2T/j2QYfJFXFoa5 W9UXujwPnioYBY74lzBZILy3SfGMuLGi0e5E28N0tK/Ivt++r/E7D7V218UNZfOTgRBg /Q2hWsjeB9+/gF7Hh6F+yGnbyjK4UEFmy/xlP+dr+cEhXfYHHj1fH4kIMwkZ2WE3Aumy dKiuzvGkzfHJurcPplzEpRkrsZHD2rk/T/qHpZiDMavs6ZFio4zLW/ShwbUHZ91XhmJA IJLmdRTHz9NjvSegJhbblYkDkbVX9RXu4YHPeUNC9f5QPYG2PVXZUO76CT1zyARPyTsb ebdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:references :in-reply-to:cc:mime-version:content-transfer-encoding:message-id; bh=ELS173TNnKo/cbgYpTDZe6t7UOdxR4kGHU5ChRh2Kxo=; b=LEKRsukE6xpo0MscZgvikgZL130oomY5ZD5AWiwVf/KcHxP8/zs38vcz72Lndtahh0 kZKeHYBtw9Dz/tU/oJhF1t2YeLP8AC+pTf4tdKkGUNwmZrhnDM3n9R3GPgG2fzrWwlsX WSvXAyXOEI2aoncAxDjfDc4LjhzNy/Hc3+jzzDSFPMkpZwjaO5TxloFJiA6anNeAYyAS P4p/bL3ba/DuRMXinxeVx0vPR7im6rRQF1cVXla932m5630gxYU2FmzYcML+zcAr/Coe kBUJjb0GvxvVF+mkqyI+cVmBkyWvVVTV/tSrBv2ypjBrWYE1ckpZZxqAVMhFk0XlE89W gqyQ==
X-Gm-Message-State: ALyK8tJ/adchWs8Aq5kyxPDz5u5Nl4c5mXOt+XS9dJNzlGZV1B4vdu7a+e5M5HECDpKzXg==
X-Received: by with SMTP id z127mr3651851yba.152.1464984976293; Fri, 03 Jun 2016 13:16:16 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id a62sm4167753ywc.29.2016. (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 03 Jun 2016 13:16:15 -0700 (PDT)
From: Dave Garrett <>
Date: Fri, 3 Jun 2016 16:16:13 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
Subject: Re: [TLS] no fallbacks please [was: 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: Fri, 03 Jun 2016 20:16:19 -0000

The idea of using an empty extension as an indicator really isn't fundamentally different from what I'm suggesting here. We'd just have an arbitrary set of new version indicators mixed in with extensions instead of inside a new generalized basket. My replacement was (again, it's over a year old) designed to be a general purpose long-term solution that could handle 1.3, 1.4, draft versions, experiments, etc, without special-casing. I'm not fundamentally against just adding a TLS 1.3 version indicator extension and freezing the old version number to 1.2. It just feels a little more hacky to me, though in the short-term it's simpler.

With respect to the concern of version numbers being moved to a non-fixed position, we could just require that the new version list extension be first or last in the extensions list. Being required to be last would also permanently mitigate the known issue of some buggy servers choking with an empty extension last. Conversely, with an empty extension indicator for each 1.3+ version, we'd probably want to require that to be first in the list to avoid that bug. (servers would of course still have to parse as an extension as not all clients will be sending 1.3+, so it's not reliably placed like the current hello version)


On Friday, June 03, 2016 02:19:52 pm David Benjamin wrote:
> I think I could be convinced in either direction right now.
> It is definitely ugly and more of a nuisance to implement. The alternative
> is a fallback and then painfully driving it out later. We've done that
> before and we have FALLBACK_SCSV and the server_random trick now.
> At the same time, I am rather bored of this fallback game. We can actually
> avoid the intolerance problem with this mechanism. Suppose we used empty
> indicator extensions, one for each new version. Then as long as servers
> tolerate unknown extensions, we'll be fine. So far this has not rusted yet,
> and we can defend it from rust by having clients send random fake
> extensions out of a range of values we burn for this purpose[*] (or private
> use area). If one extension with a list of values, we can do something
> similar.
> (Strictly speaking, the version already does not appear at a fixed position
> because a ClientHello may be pathologically fragmented. OpenSSL even had
> CVE-2014-3511 here. I believe the master branch no longer has a sniff-based
> version negotiation. BoringSSL hasn't for a while now. But rejecting such
> pathologically fragmented ClientHellos is reasonable and OpenSSL 1.0.x does
> it now.)
> David
> [*] I'm planning on writing something up here soon.
> On Fri, Jun 3, 2016 at 1:40 PM Viktor Dukhovni <>;
> wrote:
> > On Fri, Jun 03, 2016 at 06:39:58AM -0700, Eric Rescorla wrote:
> > > My opinion on this hasn't really changed since the last time. This seems
> > > like it's more complicated and it's not clear to me why it won't lead to
> > > exactly the same version intolerance problem in future.
> >
> > Doing version negotiation through extensions would be a major
> > implementation burden.  At present the client version appears early
> > in the ClientHello at a fixed position in the packet, and the server
> > can quickly grab the version, compute the highest shared version
> > and branch to the protocol implementation for that version to parse
> > the rest of the ClientHello.
> >
> > Putting the client version in an extension dramatically complicates
> > server-side processing.  So my view is that this would not be
> > progress.  This is IMNSHO even less likely to interoperate than
> > what we have now.