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

Kazuho Oku <kazuhooku@gmail.com> Sat, 19 November 2016 02:37 UTC

Return-Path: <kazuhooku@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 A3E07129619 for <tls@ietfa.amsl.com>; Fri, 18 Nov 2016 18:37:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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, SPF_PASS=-0.001] autolearn=unavailable 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 Xj6yXGHIps3d for <tls@ietfa.amsl.com>; Fri, 18 Nov 2016 18:37:51 -0800 (PST)
Received: from mail-wj0-x22a.google.com (mail-wj0-x22a.google.com [IPv6:2a00:1450:400c:c01::22a]) (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 7882C129607 for <tls@ietf.org>; Fri, 18 Nov 2016 18:31:00 -0800 (PST)
Received: by mail-wj0-x22a.google.com with SMTP id v7so3758831wjy.2 for <tls@ietf.org>; Fri, 18 Nov 2016 18:30:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g522h9B+aNTHfTFJ/A/VgiYBA9ENbVdMjidnrIP4SvQ=; b=i9CkfeYCN7ZB6xp4JG2/9PPjB4X6sXwqsbDNlimSbME6e+pYo2edH1rKBp4PIePjVp YegDztxLT0je7HI9wBwRTVnV1f7PGrqf23KNOPpt0DhHXxiNjEUBQCDWXSDMyz2fa5DM Bs6cFaw/aq0vIfJL/DXkWMbAn0ClmzQ1kX2072Le18LOunJmL9GvzaYADrwjF4BdEB8f adGPy3ZfPMEmrIlSsjP7K1LYCr/L0mN0+ydfpztbFOWRZKCJ5vC+BR0pJohCq3kQICpc FNzZCS9X/lx8BfnoTErGT/mjeP7tPabPqT4ED+JXVW8Ae8jFdWOQiz6sTVUC4fZbQcVa k71w==
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=g522h9B+aNTHfTFJ/A/VgiYBA9ENbVdMjidnrIP4SvQ=; b=aeM33TzCI1DX7fRGJPZD0B/Qm7mcGGp8fn9/G28Qw2VPhhceB39l3qxFZjMBcDACfA T2iDNsHkGTlT7vO7+LdY2NMlp83xJjnLqh8uvGd+o35Wd8anvIpN1j84hhQhNxc0EwEy Y866sIfgaBjZNpt4W2ihtFDN7iUUA1PkhzgmkbTpiGTskP1A4y3V80RxUcRzQOr3kIab Uor6fHbNi0MS57JCE5BjLV4ZaEdeumSkJ+VAGYPASDP0sjA/IQMD5HXLpFVDn7ykrP/4 gqczKy2PakhtwjJMR1z28EwMRBcX2PtSO+snygB2f9rtyPdF2oo1l3yFxKhxV+yxw6q5 4TSg==
X-Gm-Message-State: AKaTC00ngHA8fEa1PdbL6hjjzbVSAJA6Z1gMxPaBg8H08Hk7ecjLVm2BIp0dTx64VsNFjZNZwFv7AsBpTbGdkA==
X-Received: by 10.194.116.66 with SMTP id ju2mr1567534wjb.223.1479522658389; Fri, 18 Nov 2016 18:30:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.32.1 with HTTP; Fri, 18 Nov 2016 18:30:57 -0800 (PST)
In-Reply-To: <CANBOYLVwx7TDaP3ffoBQD1etN+N2VDKijec=7zmrVRHLCBF7yA@mail.gmail.com>
References: <CF83FAD0-B337-4F9E-A80B-2BAA6826BF41@sn3rd.com> <20161118180737.16475.qmail@cr.yp.to> <CANBOYLVwx7TDaP3ffoBQD1etN+N2VDKijec=7zmrVRHLCBF7yA@mail.gmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Sat, 19 Nov 2016 11:30:57 +0900
Message-ID: <CANatvzzLG1w-4nfT8UGYjQBq-mqN26+Xv5CWnEWPt5PFSZeWcw@mail.gmail.com>
To: Eric Mill <eric@konklone.com>
Content-Type: multipart/alternative; boundary=001a1130d2667d917505419e36a5
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/m9Oz-vw13GgNlDx-kTocdYtcObk>
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 02:37:52 -0000

2016-11-19 7:32 GMT+09:00 Eric Mill <eric@konklone.com>;:

> It seems like TLS 2 and TLS 2.0 have very little support, so it's really
> just deciding between:
>
> TLS 1.3
> TLS 4 (or maybe 4.0)
>
>
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'll just amplify Rich's and djb's points by noting that the cost of
> switching away from TLS 1.3 really only affects a very small number of
> people -- really just the people in and around this WG.
>
> There is a much, much larger universe of people who will make deployment
> and implementation decisions, with varying attention span and degrees of
> skill, and I think they're best served with a clean start of an unambiguous
> version number. Just because it feels uncomfortable to us doesn't mean it
> will feel uncomfortable to the larger technical/enterprise community who
> don't really *care* about the versioning scheme, they just need to make
> some decisions and move on.
>
> -- Eric
>
> On Fri, Nov 18, 2016 at 1:07 PM, D. J. Bernstein <djb@cr.yp.to>; wrote:
>
>> 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
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
>
> --
> konklone.com | @konklone <https://twitter.com/konklone>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>


-- 
Kazuho Oku