[TLS] early code point assignment for draft-ietf-tls-certificate-compression

Sean Turner <sean@sn3rd.com> Mon, 23 April 2018 16:33 UTC

Return-Path: <sean@sn3rd.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5ADF712D7F1 for <tls@ietfa.amsl.com>; Mon, 23 Apr 2018 09:33:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id hMR5rpDp5YYg for <tls@ietfa.amsl.com>; Mon, 23 Apr 2018 09:33:12 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 63BDC12D7E5 for <tls@ietf.org>; Mon, 23 Apr 2018 09:33:12 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id v2so16751240qkh.10 for <tls@ietf.org>; Mon, 23 Apr 2018 09:33:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=iAYItgwP6AZFjcirV8Nj0yCjikRTQHFM4PAftu0hYJ4=; b=hh7Mz/Wwo4bwrzrRQui0oKldOLtZ/x7b2XYNSiIJr+5FyCvsQzkdCOU9i2gPM0cfkp d9yncH78Jxdfxj1Xsi75W/AILzOkW747rsbyySjKm7il7vvTRSUkN6nX6E+JLYpR/2rk vrH0bajE57W5G+qBw7fKbjXhHYGCOOdE/ssOM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=iAYItgwP6AZFjcirV8Nj0yCjikRTQHFM4PAftu0hYJ4=; b=oW5tJQ7fC6tNIeqwhKAYWRr+hdsB20xyYOY6QGoERnedCsYNY6YQl4sVcCX3TJ9ghk ZKsLjWHLyMK/3eipRH5iboPTBMdjT3Z0wD23+++ZZ2wswmg+IiMV3QuUt86YpHgDiWSy 7mCSNAwNar6AEag+XPYZMLLgnberoRK5eH/2iyMJNyQIAo2DjSbRI/pNY3mq+QEAlIcD AwErF2lIFAclvvB2mA07bcIH5Qk5DFfI6YBLZkHlp9ww34CAgJLjrqYG6RitnmvigoSG 1vLxxlF7QlIjLsNZUAMHeADo5U6Ao/9G773izSZOCyhiMDnMxsVa/QYK7cyZXaKbfcUA +nvA==
X-Gm-Message-State: ALQs6tCAbzqpLqKmXI2oSjdCPmQFPwUhFHs7MzB1WL1JN4P3nIHfSGrI 8XP2ajwOphwbeLz69+11MIYOxxGNrYs=
X-Google-Smtp-Source: AB8JxZobQ5MLjA7kdO2caXGIm7AQHoMxPoi0OqZTFElT5t6NrTFRkGM/vkG3mX/GvrO8R36/FY0v0A==
X-Received: by with SMTP id m187mr14488840qkd.119.1524501191020; Mon, 23 Apr 2018 09:33:11 -0700 (PDT)
Received: from [] ([]) by smtp.gmail.com with ESMTPSA id l70sm11282405qkl.13.2018. for <tls@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Apr 2018 09:33:10 -0700 (PDT)
From: Sean Turner <sean@sn3rd.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Message-Id: <54EDD7A6-6B15-4C6E-9181-12438F060C67@sn3rd.com>
Date: Mon, 23 Apr 2018 12:33:08 -0400
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/8TfnV3g4sDkKujjDWo8mJnQrgYs>
Subject: [TLS] 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: Mon, 23 Apr 2018 16:33:14 -0000


tl;dr: If you object to the following early code point assignments 1) add the compress_certificate in the TLS ExtensionType Registry and 2) compressed_certificate in the TLS HandshakeType Registry, then please let the list know why by 2359UTC on 10 May 2018.  The Certificate Compression Algorithm IDs will be populated with two values: zlib and brotli.

At IETF101, we discussed beginning the process of getting an early code point assignment for the extension defined in draft-ietf-tls-certificate-compression.  The one technical comments raised at the meeting was extending the compression code point space from 1 byte to 2 might be a good idea.  The authors have merged a PR to address this in the gh repo and once they submit a new version of the draft the process for an early code point assignment will begin.  The rules for this are specified in RFC7120, and the four criteria for a draft to be eligible for early code point assignment are:

Criteria A

       The code points must be from a space designated as "RFC
       Required", "IETF Review", or "Standards Action".  Additionally,
       requests for early assignment of code points from a
       "Specification Required" registry are allowed if the
       specification will be published as an RFC.

The Transport Layer Security (TLS) Extensions and TLS HandshakeType Registry registries are both RFC Required.  While we’re changing that registry’s rules with draft-ietf-tls-iana-registry-updates, there’s still every intention to publish draft-ietf-tls-certificate-compression as an RFC so we’re still good to go.

Criteria B

       The format, semantics, processing, and other rules related to
       handling the protocol entities defined by the code points
       (henceforth called "specifications") must be adequately described
       in an Internet-Draft.

When asked at IETF101 what other outstanding comments there were on the draft the only one identified was increasing the code point size for the compression algorithms.  Version -05 will address this point.

Criteria C

       The specifications of these code points must be stable; i.e., if
       there is a change, implementations based on the earlier and later
       specifications must be seamlessly interoperable.

At IETF101, it was noted that this specification was stable enough.  Implementation issues might be identifier later, but, well, that’s the point.

Criteria D

       The Working Group chairs and Area Directors (ADs) judge that
       there is sufficient interest in the community for early (pre-RFC)
       implementation and deployment, or that failure to make an early
       allocation might lead to contention for the code point in the

5 WG participants all from different organizations indicated their interest in implementing this draft (even if it was just for experimentation).

There are also 6 steps identified in RFC 7120 for early assignment, but only four involve the chairs:

  1.  The authors (editors) of the document submit a request for early
       allocation to the Working Group chairs, specifying which code
       points require early allocation and to which document they should
       be assigned.

An in-person request was made at IETF 101 for the early code point assignments.  There was also an earlier on-list request.

   2.  The WG chairs determine whether the conditions for early
       allocations described in Section 2 are met, particularly
       conditions (c) and (d).

The chairs agree that the four conditions have been met.

   3.  The WG chairs gauge whether there is consensus within the WG that
       early allocation is appropriate for the given document.

The sense of the room at IETF 101 was that yes early allocation is appropriate, but this email is verifying that.

   4.  If steps 2) and 3) are satisfied, the WG chairs request approval
       from the Area Director(s).  The Area Director(s) may apply
       judgement to the request, especially if there is a risk of
       registry depletion.

Once the chairs have determined WG consensus, we’ll pass it to Ben.