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

Victor Vasiliev <vasilvv@google.com> Sat, 19 November 2016 06:35 UTC

Return-Path: <vasilvv@google.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 69EB912957E for <tls@ietfa.amsl.com>; Fri, 18 Nov 2016 22:35:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 SY0R_L2vZQjK for <tls@ietfa.amsl.com>; Fri, 18 Nov 2016 22:35:44 -0800 (PST)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 E8B7D12978C for <tls@ietf.org>; Fri, 18 Nov 2016 22:35:43 -0800 (PST)
Received: by mail-qk0-x231.google.com with SMTP id q130so291886850qke.1 for <tls@ietf.org>; Fri, 18 Nov 2016 22:35:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lSK4EsJIGiKa83ULefOv2K/h9ppjm75XBKueRQnMzsE=; b=Y6dQb8z13fIyaFTKV0svprxjEnEG7szP/6PQOj2lRH5oA6fA2+hqVUmcKKBsR2X6o8 xecUr8dR5S623XWaVC5V/R7GbPfiNTnvBk5DvkkCCUiB82m6QzgDEYLLGCx4LVI7g/oY 0HSDiCY7W+Zp4V+n5eYZTwYaZ7kJuTv3H6ANN7mP13AfijfknZls1ygTorp860VqJgTx +qDkGyxiFDJPue+h9NvyP6NSQuW8Wsr0CP4d5c34dw+w1OcDjBFxfjXQqU4XAnIuue58 9SNc0DLWdGS/fFJZIps5LQ5+7mAhfGhbIu0QbLJtgh/3qzBcm06/cdMcaiIiPV527Pjo BVew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lSK4EsJIGiKa83ULefOv2K/h9ppjm75XBKueRQnMzsE=; b=SKtYGb87ad+cEn/mFDVuJ95JMZY2FYlCBR+a8we9qrDas1Zjbw7sfCPbWuzB+q5Yym VQgojmRGWjhCW10A3HZSTo6M1hS3tpV98CxOVk4pbJ8RGGZpTim2wih+SP2znYgb+pHh M14PZcI0Ckr/w4GAIo9SWNoySPmUO/RGmWM/z45OETU8lTObHDc3E5sR0MJ1+XX91qFi oQmt7Je9SuP/PuJCwSLOgcwcPkfOHNjAcjV0yL265X03wVTcDbZLxw6C9VplIYJ4h03f JGJbIXuB3wPBxNpLGuq38IDQ2enN6NLdVGlxzjnb7FDXFgb5DlNlxapvF9+QeqIFSw9J kiCw==
X-Gm-Message-State: AKaTC02JgH76KkhCjanbrHvBxhRN/YhqmwlIEy0czFr+WjUCuIJ8M3CYGHSnYhNiskGYM5cIUQiTuZkcqMGX5tFi
X-Received: by 10.55.86.70 with SMTP id k67mr4583548qkb.280.1479537342842; Fri, 18 Nov 2016 22:35:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.55.157.11 with HTTP; Fri, 18 Nov 2016 22:35:41 -0800 (PST)
In-Reply-To: <CANatvzzLG1w-4nfT8UGYjQBq-mqN26+Xv5CWnEWPt5PFSZeWcw@mail.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>
From: Victor Vasiliev <vasilvv@google.com>
Date: Sat, 19 Nov 2016 01:35:41 -0500
Message-ID: <CAAZdMachoNb4G1J=honR2a2=Ur+dGhq9-nAtuDH5ZNK=6cxMSA@mail.gmail.com>
To: Kazuho Oku <kazuhooku@gmail.com>
Content-Type: multipart/alternative; boundary="001a114e718ec0f0bd0541a1a199"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/P2bzd0OCszrtFs1jsdIlnumMvhw>
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:35:45 -0000

On Fri, Nov 18, 2016 at 9:30 PM, Kazuho Oku <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.
>
>
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.