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

Hubert Kario <> Mon, 06 June 2016 10:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 856B712D6A5 for <>; Mon, 6 Jun 2016 03:48:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.328
X-Spam-Status: No, score=-8.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, 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 K7PmTylmeFxR for <>; Mon, 6 Jun 2016 03:48:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F3DE912D5A9 for <>; Mon, 6 Jun 2016 03:48:22 -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 5782EC04D28F; Mon, 6 Jun 2016 10:48:22 +0000 (UTC)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id u56AmKTQ009046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jun 2016 06:48:22 -0400
From: Hubert Kario <>
Date: Mon, 06 Jun 2016 12:48:20 +0200
Message-ID: <>
User-Agent: KMail/4.14.10 (Linux/4.4.11-200.fc22.x86_64; KDE/4.14.17; x86_64; ; )
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1726266.PhP440cdS0"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 ( []); Mon, 06 Jun 2016 10:48:22 +0000 (UTC)
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: Mon, 06 Jun 2016 10:48:24 -0000

On Friday 03 June 2016 16:16:13 Dave Garrett wrote:
> 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.

The reason why we want to add this is because there are programmers that 
get the normal version negotiation wrong.

What makes you think that a new version negotiation that works more or 
less in the same way will _not_ be implemented incorrectly?

Counter example: there are servers which handle TLSv1.2 and do not 
handle TLSv1.3 (e.g., and there are implementations that do 
not handle multiple names in SNI extension. Both are supported only by 
either recent or very recent implementations.

And don't forget that what we are proposing here is significantly 
complicating implementations that most likely _are_ behaving properly 
and _are_ handling unknown versions/extensions/ciphersuites correctly; 
just because there are few bad apples.

> 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.

it's still after the variable-length list of ciphersuites...

Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purky┼łova 99/71, 612 45, Brno, Czech Republic