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

Eftychios Theodorakis <> Fri, 18 November 2016 21:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D7EDA12959B for <>; Fri, 18 Nov 2016 13:36:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 rAre8zUBeSnx for <>; Fri, 18 Nov 2016 13:36:07 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1EB3A129405 for <>; Fri, 18 Nov 2016 13:36:07 -0800 (PST)
Received: by with SMTP id b35so181663570uaa.3 for <>; Fri, 18 Nov 2016 13:36:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=dGQEwRGZcwYZZTlrmnsyY/hgfYr/QvYe8Pd7prvxLpc=; b=r1jtJ0rWvr8Ueq3XCelY+VGMK91y2+nFELnApHjQkBzX+PJ5kjhh8YTug9CcPQP5zr GKtG7nuuS4ukKtBm3gRYcUMpoHwArPNPHFmdBlFS/xLg/f22GdnBhrn49kKYwKs8d1BU CZ5GrDm7KXL7pyTEhvFRjDcllmK6ECehyIuKtXeajB0yQXwKqOIIOaLBEPyyOYe+lDKV vXL+ax6f7BwlGphqh5fFtynrRJ+c/UeIcKdnJbQfuvidVr42jG0mHVsbrsXGpwuMc/lA beC730Exf1Xwfm9O9tQ3thwGbabCrSLV5us7TZlR3kKQMOkaO9nuFulXYcNJlOAFnrU/ YYMA==
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:from:date :message-id:subject:to; bh=dGQEwRGZcwYZZTlrmnsyY/hgfYr/QvYe8Pd7prvxLpc=; b=FBf2W7Dc5YXcplcNce1IjQRpioog87VN0aK8eCQCOrCErhxlhwM5f/nN5NNeoEKDLc trqw1Cy046fuN/KQWPBieZBgakFywnUEi7AiCUTUNZyQ6jBNzU9MiJAWZZlEWrQEyWAc Si7I7kWhmRbmkhgC00sW/bunA7MOqZ1N7mNeE7+nLwbKwEXl0M7tv+eVefjppqXVpkG2 MVgR1eD6LESfG8iKrsGKrjz/ZvV0v46ihZFRYj8CkrIcN7voKQbnk3ysMg28PdeVQda7 t4wT1IhoW9o7rjNDUXaXRSILPpc7lB4+ls2oRgTV756cnpixYefTgeoqxeRMS3z1UNpA yVPw==
X-Gm-Message-State: AKaTC00UZoFjhRz9WsVl9pfbaCdLVI1a6O3eEP2v9wJI7U3Tr58ylX0ooY3e9MujrpKhRDlrdcBB+Mvw1mLx1Q==
X-Received: by with SMTP id 107mr1039347uar.51.1479504966098; Fri, 18 Nov 2016 13:36:06 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 18 Nov 2016 13:36:05 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Eftychios Theodorakis <>
Date: Fri, 18 Nov 2016 13:36:05 -0800
Message-ID: <>
Content-Type: multipart/alternative; boundary=001a113f0fa4f2a5a105419a17c9
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 21:37:22 -0000

It is imprinted in people's mind that minor version numbering = small
improvements and compatibility. People for better or worse see a minor
version as minor improvements and often disregard them considering the
effort versus the payout - even if that is a single configuration change.
That's how they learned from non security related projects.

> I prefer TLS 1.3, because is signals continuity with the
> ongoing TLS deployment efforts.

The alternative suggestion (4) also signals the ongoing efforts. True it
does hint on possible incompatibility; but is this not an honest versioning

I think educating people is a good cause, but that's not enough. One has to
account for all the real life anecdotes mentioned above. If people were
good and fully informed decision makers there would not be a need for "do
not press this red button" signs.

I am not sure what will end up being the better version, but I am certain
that 1.3 will be disregarded as a minor change - it is not. My suggestion
is for TLS 4.

2016-11-18 10:07 GMT-08:00 D. J. Bernstein <>;:

> 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.
> ---Dan
> _______________________________________________
> TLS mailing list