Re: [TLS] Confirming consensus: TLS1.3->TLS*

"D. J. Bernstein" <> Fri, 18 November 2016 18:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58D8F12962C for <>; Fri, 18 Nov 2016 10:07:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sFHyzlWh_BUe for <>; Fri, 18 Nov 2016 10:07:43 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id E86471295E3 for <>; Fri, 18 Nov 2016 10:07:42 -0800 (PST)
Received: (qmail 30058 invoked by uid 1017); 18 Nov 2016 18:07:40 -0000
Received: from unknown (unknown) by unknown with QMTP; 18 Nov 2016 18:07:40 -0000
Received: (qmail 16476 invoked by uid 1000); 18 Nov 2016 18:07:37 -0000
Date: 18 Nov 2016 18:07:37 -0000
Message-ID: <>
From: "D. J. Bernstein" <>
In-Reply-To: <>
Archived-At: <>
Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS*
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, 18 Nov 2016 18:07:45 -0000

The largest number of users have the least amount of information, and
they see version numbers as part of various user interfaces. It's clear
how they will be inclined to guess 3>1.3>1.2>1.1>1.0 (very bad) but
4>3>1.2>1.1>1.0 (eliminating the problem as soon as 4 is supported).

We've all heard anecdotes of 3>1.2>1.1>1.0 disasters. Even if this type
of disaster happens to only 1% of site administrators, it strikes me as
more important for security than any of the arguments that have been
given for "TLS 1.3". So I would prefer "TLS 4".

Yes, sure, we can try to educate people that TLS>SSL (but then we're
fighting against tons of TLS=SSL messaging), or educate them to use
server-testing tools (so that they can fix the problem afterwards---but
I wonder whether anyone has analyzed the damage caused by running SSLv3
for a little while before switching the same keys to a newer protocol),
and hope that this education fights against 3>1.3 more effectively than
it fought against 3>1.2. But it's better to switch to a less error-prone
interface that doesn't require additional education in the first place.