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

David Benjamin <davidben@chromium.org> Fri, 02 December 2016 03:35 UTC

Return-Path: <davidben@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 3EA50129A7D for <tls@ietfa.amsl.com>; Thu, 1 Dec 2016 19:35:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.595
X-Spam-Level:
X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 Z0WamjqAfBld for <tls@ietfa.amsl.com>; Thu, 1 Dec 2016 19:35:12 -0800 (PST)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 AC565129A7C for <tls@ietf.org>; Thu, 1 Dec 2016 19:35:11 -0800 (PST)
Received: by mail-qk0-x236.google.com with SMTP id n21so266989326qka.3 for <tls@ietf.org>; Thu, 01 Dec 2016 19:35:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zBkatizUXGrMOZ2HlzDuInWowmZBCU+qDEtgsj1/JUs=; b=SU6jf67B+WTbQUeI3N78yijllIVFOndOu9mNZd9uUVqQl4RX7Jjk1LjkNHaJPpqvxr adARGuYuHYvaznMZlqvo+RmDFaSHXI/it/CVOJObRQeyaCvuKhMlQqvI4i6CroZz/v3H XtmAkSFctS5iyG22LkuZPch6GWb9QMxWq4UEc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=zBkatizUXGrMOZ2HlzDuInWowmZBCU+qDEtgsj1/JUs=; b=bYiovQpNXf9B4Wra4BGjnQvND9kN4OuOORUnjmEdOn/Z2Kawg5E1gRQ60rJ0vqxBrO 66jYwN2X7ZPuHSsQE2P7L0KmGPtqhPnF21s9MIE6y/T/VTIAzXmjGbGS8lRILSCh8BxV 12PWXFA14ZueIa/wzVKa7H3NWQx41X6Yf5CPYC8X3x/nbTIsu0UyMk1v/d4iCadsWaPI nbHU6KoTMJ1Ft8efD26jfDb8nVvoF+WNM4h/y5U+PAVpZgAmHxihHg9d/V+qtEmXqIPs hPn15Upi6MoP74mtqzAnH7Ru2khjzoS2aHwHTYHntchzW0fDQnfUIHcaOohcA6abDB8d V+6Q==
X-Gm-Message-State: AKaTC03F2ViTxU2v406OMmtVXmx0ZrMmYafMo/lUwUzhTVyZIChynvAI5bBbNhACztqCvl5pGfgU4hpoUZPbwEMb
X-Received: by 10.55.10.7 with SMTP id 7mr34299889qkk.162.1480649710688; Thu, 01 Dec 2016 19:35:10 -0800 (PST)
MIME-Version: 1.0
References: <CF83FAD0-B337-4F9E-A80B-2BAA6826BF41@sn3rd.com> <FDFEA8C9B9B6BD4685DCC959079C81F5E1913B9D@BLREML509-MBX.china.huawei.com> <CAOjisRy+Lt59rE-+_bJmD=0oQD+qbeUBsJQyOvH6OggfhqyYqg@mail.gmail.com> <1480566504487.58214@cs.auckland.ac.nz> <D538A9AE-7F5A-4A70-8EED-F7D4426CE087@dukhovni.org> <CAHOTMVJzvf8v0S3vhFASekd6ksut0uNBhJDmuYzSQcJfy6JYpg@mail.gmail.com> <1480648354917.41781@cs.auckland.ac.nz>
In-Reply-To: <1480648354917.41781@cs.auckland.ac.nz>
From: David Benjamin <davidben@chromium.org>
Date: Fri, 02 Dec 2016 03:35:00 +0000
Message-ID: <CAF8qwaAMcLQYhTVGnPA-=b-L1vmkyhKGPM39QV4+VvPf9GKkbQ@mail.gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Tony Arcieri <bascule@gmail.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114c563e0b3bed0542a4a057"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ki44Uhdfb6YopgeIfk9gFqFCNac>
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: Fri, 02 Dec 2016 03:35:14 -0000

On Thu, Dec 1, 2016 at 10:12 PM Peter Gutmann <pgut001@cs.auckland.ac.nz>
wrote:

> Tony Arcieri <bascule@gmail.com> writes:
>
> >There's already ample material out there (papers, presentations, mailing
> list
> >discussions, etc) which talks about "TLS 1.3".
>
> In other words, the TLS WG and a small number of people who interact with
> it
> call it TLS 1.3.  That's hardly a strong argument when most of the rest of
> the
> world doesn't even call it TLS.
>
> In fact that's something that's come up repeatedly in the bikeshedding so
> far,
> there are some really good, sound arguments for calling it TLS/SSL 4 or
> TLS/SSL 2017, while pretty much the only reasons I've seen for TLS 1.3 are
> inertia, "we've always called it that"/"I don't want to change"/etc.


I think TLS 4 makes everything worse, not better.

In hindsight, renaming SSL 3.1 was a terrible mistake. But TLS 1.2 is going
to exist for a long time. If we call the next one 4, we have to explain a
gap in the versioning (1.0, 1.1, 1.2, 4?) and placing 2.0 and 3.0 after 1.2
becomes even more inviting.

Short of a time machine so we can call this SSL 3.4, the best fix is to let
SSL 3.0 fall away. This is already semi-plausible (it's out of all
browsers) and is only going to become more realistic over time. Certainly
it will be faster than TLS 1.2 going away and undoing TLS 4's version gap
problem. (TLS 1.3 even places SSL 3.0 as a MUST NOT, for what little teeth
that has.)

Once SSL 3.0 falls away, we'll be left with 1.0, 1.1, 1.2, and 1.3, which
is a plausible numbering progression. There'll still be the mess with SSL
being the informal name for the protocol family, but that isn't a numbering
problem.

David