Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

Benjamin Kaduk <bkaduk@akamai.com> Tue, 29 May 2018 20:14 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 4DFF312ECEC; Tue, 29 May 2018 13:14:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level:
X-Spam-Status: No, score=-2.711 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] 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 sgE8JJtH7qqT; Tue, 29 May 2018 13:14:27 -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 CA31E12EC45; Tue, 29 May 2018 13:14:24 -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 w4TK7IeM013873; Tue, 29 May 2018 21:14:17 +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=lGhoQ1HbYNRt/8ZzsdT4YnXXnwm1mpYjQ5KiGNk4dgE=; b=IRm7XfBO1K+9Br0C/mTsVgQIo//bXzJ1xQcnigloywKgzNUcll+cSrbDJuR85hQeRS5c BfCnWy7WWiy3z7QlPA6KcwGkmdHHtHhdALpURm0XgZxO44FmzBJE4NZsWegPaZiUvHe5 /rORl/XOC/RvyxPtXyb/LLzyCzSkjq8v+iRuFMzBDudvW6W6euQCikDIAH/onEEjLSav UqiwhIo1mRIEKG7PltU8AtHvOtao2tUWyGcCsOwS53CTFcwG1RTlbUNysdRN+NI9x4e7 AWO1pd9OOR2h73HotfgHZFzsKx4o+0BGBdXNvw8mrptS13IK2REV4zxSbbtWdgIawn8s uw==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2j9cw60545-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 May 2018 21:14:17 +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 w4TKBKf5001854; Tue, 29 May 2018 16:14:16 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2j9cvt07nb-1; Tue, 29 May 2018 16:14:15 -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 CE0481FCDC; Tue, 29 May 2018 20:14:15 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1fNl0Z-0005Fn-5p; Tue, 29 May 2018 15:14:15 -0500
Date: Tue, 29 May 2018 15:14:14 -0500
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: "tls@ietf.org" <tls@ietf.org>, "tls-chairs@ietf.org" <tls-chairs@ietf.org>
Message-ID: <20180529201414.GL13834@akamai.com>
References: <152727817174.12617.11617762950737426284.idtracker@ietfa.amsl.com> <1527425365931.63162@cs.auckland.ac.nz> <CABcZeBPaU5u4WG8Jj8L8waAHJrTYhQyFVzqs7s7rYLfvQ9Oe9A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABcZeBPaU5u4WG8Jj8L8waAHJrTYhQyFVzqs7s7rYLfvQ9Oe9A@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-29_09:, , 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-1805220000 definitions=main-1805290214
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-29_09:, , 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1805290214
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/yzc3XBLLnmZrLDAR9vfHLijhfyo>
Subject: Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)
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: Tue, 29 May 2018 20:14:36 -0000

On Sun, May 27, 2018 at 09:56:30AM -0700, Eric Rescorla wrote:
> Well, this is a bit premature because the document hasn't actually been
> published, just approved.

It's also not properly addressed -- regular allocations under the
"specification required" policy go directly to IANA, whereas RFC 7120 early
allocations it is the WG chairs and ADs that need to judge the level of
interest in the community.

> In any case, I don't think we should assign code point 26 to this
> extension. I recognize that you have existing implementations that happen
> to use it, but that's a result of the unfortunate decision to squat on a
> code point which was right in the way of near future assignments, and those
> implementations can change to the new code point. Of course, it might be
> useful to add a note to implementations of the compression draft as well.

There's a tradeoff between respecting the official allocation processes
and avoiding real-world breakage.  I think we can all make our own assessments
on the former, but for the latter, all the evidence we have so far is a claim
from Peter that there exists software that hardcodes this number, with no
indication of scale of deployment or ease of updating such software.

-Ben