Re: [TLS] early code points assigned (was Re: early code point assignment for draft-ietf-tls-certificate-compression)

Benjamin Kaduk <bkaduk@akamai.com> Thu, 24 May 2018 19:54 UTC

Return-Path: <bkaduk@akamai.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 F3BF612EB11; Thu, 24 May 2018 12:54:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 V9Pe9RnoTcmC; Thu, 24 May 2018 12:54:49 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19911275F4; Thu, 24 May 2018 12:54:48 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w4OJrInU027325; Thu, 24 May 2018 20:54:47 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=0M32ngXn4toQQKtiRjYna/8QyjlfejehZtsXDwN9E0o=; b=aqwHnnzPL4ijQmQylf5VRov+5G8qxFxfzlnNw0Ym1O9zfQxYFVvRqsmAXTcew2rxrGkw baVYMO3OBagLp2G0XkpaOaKUmNl9OHgLbWNwLDP5R27Oikvypp2NEAaM490Sq+7bfiFY bJmFrGKqgueIuJEdb6xMyVvkNx+OrzWbl2XtLkH4UFXsBUuxbD/+L9RYQVWu4p5meAhs ovU3MWEOpSqEjV0oie9cLPJvNZQxDrfxewmwbQxa7p3MZK3nSN15I2UtzazIVx3eaHzF HF2S/tksYoRw90DiulGo2R1wM0WivwMo5Bv2coTihEabWHY38hgqWmK+Ria+cVwjvVVz jA==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2j5g0ebp47-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 24 May 2018 20:54:47 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w4OJqAVQ026391; Thu, 24 May 2018 15:54:46 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2j2f8utf16-1; Thu, 24 May 2018 15:54:45 -0400
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id B90D01FCD8; Thu, 24 May 2018 19:54:45 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1fLwJw-0005l1-V9; Thu, 24 May 2018 14:54:45 -0500
Date: Thu, 24 May 2018 14:54:44 -0500
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Nico Williams <nico@cryptonector.com>
Cc: draft-ietf-tls-certificate-compression@ietf.org, tls@ietf.org
Message-ID: <20180524195444.GS13834@akamai.com>
References: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com> <A04F3B59-960C-4947-846F-EC988E6353FA@sn3rd.com> <9E57701A-E98C-4DEF-B0C3-EE563D1AFBB7@sn3rd.com> <1527132197784.15190@cs.auckland.ac.nz> <CAMfhd9VMJ5g0gDD2V9=BwPyW_u16OVhe77ftrLV2=rt7tWjQ=Q@mail.gmail.com> <20180524194624.GC14446@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20180524194624.GC14446@localhost>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-24_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805240225
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-24_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=986 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805240225
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2Sx6GsJcS0nslSHUlwM9lDO14Ls>
Subject: Re: [TLS] early code points assigned (was Re: early code point assignment for draft-ietf-tls-certificate-compression)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 24 May 2018 19:54:51 -0000

On Thu, May 24, 2018 at 02:46:26PM -0500, Nico Williams wrote:
> On Thu, May 24, 2018 at 09:30:59AM -0700, Adam Langley wrote:
> > On Wed, May 23, 2018 at 8:23 PM Peter Gutmann <pgut001@cs.auckland.ac.nz>
> > wrote:
> > > That's going to cause clashes with implementations that use that value for
> > > TLS-LTS, it would be better to use a value other than 26 that isn't
> > already in
> > > use.
> > 
> > Obviously I'm not adverse to using the occasional, non-IANA code point. But
> > they need to be picked randomly and outside the dense, IANA area.
> > Otherwise, this is certain to happen in short order.
> 
> Why can't we make it so IANA does early codepoint assignment?

They already do, and we've got documents approved by the IESG that make the
registration policy just "specification required" (as opposed to "IETF review").

While Peter did mention the value 26 on the list two years ago, there hasn't exactly
been a lot of visible action with TLS-LTS in the intervening period...

-Ben