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

Anders Rundgren <anders.rundgren.net@gmail.com> Sat, 19 November 2016 06:49 UTC

Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18BD129446 for <tls@ietfa.amsl.com>; Fri, 18 Nov 2016 22:49:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level:
X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgZvfhMDa8W1 for <tls@ietfa.amsl.com>; Fri, 18 Nov 2016 22:49:44 -0800 (PST)
Received: from mail-wj0-x22b.google.com (mail-wj0-x22b.google.com [IPv6:2a00:1450:400c:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08DBA1293FB for <tls@ietf.org>; Fri, 18 Nov 2016 22:49:44 -0800 (PST)
Received: by mail-wj0-x22b.google.com with SMTP id xy5so5188056wjc.0 for <tls@ietf.org>; Fri, 18 Nov 2016 22:49:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=QM9YVM/eP8H5cghuUaJ0jYAeOWERAdhhWsQNnv38mW0=; b=cz89zURhb7JTNGsxYeIVmiiD474pnWvq34cdU7EuixCaa6+EfHzRTTAeWw6i4JNb// TIJYI67I/UvijfTZ60t2QAveES9TEj5ufk4co7lyfprlDL4CtJYGM5Dm2QjfCqkMeMN6 MBdZWbJokYDcAFHX38tV+ZWwsUh+JICwBFYPRXJ6c2jZcHvRLxEm1/lvHkINHpXwKaWG 9/9zxCcR6WWD0lWm7AwOXqKEWhGyJXudOZZpp1KoYF4lfrFuCDuhcXs/h1xIOUbqqfgw YwNrl4pEW6dRcIiMqKwc4AyuWLRglqT/3WuAbyQpYwQ+vwnnvDanm/21COlPGYZ106IG m95Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=QM9YVM/eP8H5cghuUaJ0jYAeOWERAdhhWsQNnv38mW0=; b=ftLN5gnBX5HSYeTP6ujBWxY2BjYl2HMmvxt0yU1YCwz4+CFMY0KeZm/J6eMfLlxW3G iSZ+c1XcMw+5GjMeiSmqRztQcT/Jy3QzLuMuuTuatb1Tmv2JdQrmgCMMLgvxAiTXvZEf A3UAA8nmmUCGrr8VR8P2JjVLq57WJReY2zWizAG+xIK8pJxTPO6C9qy5OiytD24uuiRn dqOq70nVfgdK+qnEnwRZf5Mj/8ORw8IfMEwRlCCdz3YgaxZuBTZNXAlOxxzURDJyLr/q T++Sa1sJd0ulhA2LZm7BbJJ4IAuc6xspNH/1z3LzW6MH22ehpT5XPTGgBreP27JXDatQ zvJA==
X-Gm-Message-State: AKaTC01D7TkrPuTkefAQIkzTPDlOBIQvaIZHeVQ6byOkEYVtYgxhRzm1b2C9RJPljpwCug==
X-Received: by 10.194.60.195 with SMTP id j3mr2113209wjr.149.1479538182392; Fri, 18 Nov 2016 22:49:42 -0800 (PST)
Received: from [192.168.1.79] (124.25.176.95.rev.sfr.net. [95.176.25.124]) by smtp.googlemail.com with ESMTPSA id g197sm7158601wmd.15.2016.11.18.22.49.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Nov 2016 22:49:41 -0800 (PST)
To: Victor Vasiliev <vasilvv@google.com>, Kazuho Oku <kazuhooku@gmail.com>
References: <CF83FAD0-B337-4F9E-A80B-2BAA6826BF41@sn3rd.com> <20161118180737.16475.qmail@cr.yp.to> <CANBOYLVwx7TDaP3ffoBQD1etN+N2VDKijec=7zmrVRHLCBF7yA@mail.gmail.com> <CANatvzzLG1w-4nfT8UGYjQBq-mqN26+Xv5CWnEWPt5PFSZeWcw@mail.gmail.com> <CAAZdMachoNb4G1J=honR2a2=Ur+dGhq9-nAtuDH5ZNK=6cxMSA@mail.gmail.com>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <4467b475-d17e-581a-a142-4a0a7c2708f9@gmail.com>
Date: Sat, 19 Nov 2016 07:49:29 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <CAAZdMachoNb4G1J=honR2a2=Ur+dGhq9-nAtuDH5ZNK=6cxMSA@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/itcyuC4xMhfcQOUPGuXaPsd2dkQ>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS*
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Nov 2016 06:49:45 -0000

On 2016-11-19 07:35, Victor Vasiliev wrote:
> On Fri, Nov 18, 2016 at 9:30 PM, Kazuho Oku <kazuhooku@gmail.com <mailto:kazuhooku@gmail.com>> wrote:
>
>     I oppose to going to TLS 4, due to the following reasons:
>
>     * it might give people false notion that  SSL 2.0, 3.0 is superior to TLS 1.0-1.2
>     * if name the new protocol TLS 1.3, 2.0, or 2, then there would be no confusion once SSL goes away. However, if we name the new version TLS 4, then people would (for upcoming tens of years) continue to ask where TLS 2 and TLS 3.

Windows 9 never made it to the public.  Hardly nobody complained.

If the TLS protocol you are working on is "Brand New" or is just an "Incremental Upgrade"
is more a matter of personal opinion than an absolute truth.  It is definitely a "Major Overhaul"
since every little bit of the protocol has been reviewed thoroughly.

TLS 4 seems OK to me.

Anders

>
>
> I very much agree with those points.
>
> TLS 4 is a confusing name that, as far as I can tell, cannot actually make
> things better.  Right now we have:
>
>     SSL 2 -> SSL 3 -> TLS 1.0 -> TLS 1.1 -> TLS 1.2 -> TLS 1.3              (1)
>
> Now, some people may get confused by this because of the "SSL is TLS" idea, but
> once you learn that in reality "SSL is a thing that was before TLS", it does
> make sense and seem fairly straightforward (a series of numbers under one name,
> followed by another series of numbers under the new name).
>
> With TLS 4, we have:
>
>     SSL 2 -> SSL 3 -> TLS 1.0 -> TLS 1.1 -> TLS 1.2 -> TLS 4                (2)
>
> This does has a nice property of indicating that TLS 4 is clearly the latest
> version (as long as you know that SSL came before TLS), but omission of TLS 2
> and TLS 3 will leave people confused, and most likely lead them to conclude
> that what happened is TLS was renamed to SSL and then back again, so that
>
>     TLS 1.0 -> TLS 1.1 -> TLS 1.2 -> SSL 2 -> SSL 3 -> TLS 4.               (3)
>
> But this is not even the worst of the problems.
>
> The real problem is that we can't actually rename TLS 1.3, because at the end
> we will merely create a new name for it.  It has already been TLS 1.3 for a few
> years, it has been discussed in the tech community as TLS 1.3, researchers have
> published papers about TLS 1.3, there's probably already the marketing material
> with TLS 1.3 out there.  The code that refers to it as TLS 1.3 will probably
> end up being referring to it as 1.3 for approximately forever, even if all the
> implementers had been enthusiastic about renaming it, because refactoring is
> high-cost and low-priority, and may not be even possible if you've already
> exposed it via the ABI.  The old name will never die, and it will be a burden
> to anyone in this community, making confusing versioning scheme even more
> confusing.  It will probably leak outside of it too, and instead of (2), we
> will end up getting
>
>     SSL 2 -> SSL 3 -> TLS 1.0 -> TLS 1.1 -> TLS 1.2 -> TLS 1.3 = TLS 4      (4)
>
> which seems strictly more confusing than (1) in any way.
>
> tl;dr: the only way to minimze confusion at this point is to not change
> anything.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>