Re: [TLS] Proposed text for dnsssec chain extension draft

Nico Williams <> Thu, 26 April 2018 15:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3842127241 for <>; Thu, 26 Apr 2018 08:19:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.61
X-Spam-Level: *
X-Spam-Status: No, score=1.61 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_NONE=-0.0001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=3.6] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tqzPDPVKy9jS for <>; Thu, 26 Apr 2018 08:19:37 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AC41B12DA17 for <>; Thu, 26 Apr 2018 08:19:37 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 28559A004B84; Thu, 26 Apr 2018 08:19:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=ZxlifciczDxjF+ z2ac1wvg6Ykbs=; b=J++otNZLTimn240oS49WD3Q6t6WiyRdgku/MEWRtLwE7fd DPLNXCpwZXt8cJAGKmhd9u+VLbnKrq14hXddBbypNankgH7ohV6ux4qjUwUlRN0T PEusZZ0AU9SFo2b2DwcYEc+87fOVRoTe3uvsOU5u3qYRhreFpXdDkecziImLo=
Received: from localhost ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id BC9B6A004B82; Thu, 26 Apr 2018 08:19:36 -0700 (PDT)
Date: Thu, 26 Apr 2018 10:13:07 -0500
From: Nico Williams <>
To: Eric Rescorla <>
Cc: TLS WG <>
Message-ID: <20180426151305.GL25259@localhost>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <>
Subject: Re: [TLS] Proposed text for dnsssec chain extension draft
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Apr 2018 15:19:39 -0000

On Wed, Apr 25, 2018 at 11:30:02PM -0700, Eric Rescorla wrote:
> Thanks for producing some text. I understand why one might think that
> having a reserved 16-bit field is useful here, but I don't really
> agree.
> The conventional reason to reserve this kind of field is that you need
> to leave space for an extension in some PDU, because it's hard to add
> later. But that's not true here (or in TLS in general) because we

-07 has text on pinning.  There is no consensus on making that work
_now_.  There is only consensus on removing that text and revisiting
pinning later.  Well, later we will need these two bytes.

So there's the conventional reason to reserve this kind of field:
because we know we will need it, and adding it via some extension
facility will be harder than... already having it.

And yes, we (the IETF) do use reserved fields even in protocols where
there is extensibility.

> already have an extension mechanism (indeed, the one that's being used
> by this specification). If we end up having consensus to do pinning,
> then it's straightforward to define a new TLS extension that provides
> it.

Having these two bytes now will mean that they are always present, which
will make it a lot easier for implementations to a) start sending
non-zero values, b) start handling non-zero values, once we write a spec
on what non-zero values mean.  (And we know what that spec will say,
which is why we know we need two bytes.)

> If you look at HPKP and Expect-CT, you will note that there are a
> [...]

HPKP is completely different.  The idea here is NOT to pin key material,
CAs, or anything of the sort.  The idea here is to pin only the use of
this extension, and this does not even bind one to use DANE because the
extension can carry a denial of existence.