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

Richard Barnes <> Thu, 26 April 2018 15:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C68112DA27 for <>; Thu, 26 Apr 2018 08:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.608
X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l8tSnlGN--4i for <>; Thu, 26 Apr 2018 08:22:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C6B6127241 for <>; Thu, 26 Apr 2018 08:22:41 -0700 (PDT)
Received: by with SMTP id f63-v6so24495281oic.4 for <>; Thu, 26 Apr 2018 08:22:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kCIggaYA/71vPMJZc9zILCDgq5tSouTYaTXsmSwSrik=; b=Tys1cY5P28Wn94toCJpQ3Su0CnEikRaBpyPKn/Xs3CMnh6YCefsHKZAEBJnjxVH33I iuJlVyCoIWb/tUySMOVvgdPVULUuYHGq7HYSdf/EygEiDPB5qMkkRfbDQcMR1UALpHHQ bY6UHCvqTFkMooKLx9lUhb6i3x1VQQrIV9ueAHMaY0rDeOTSfUI5r/ongtoSBUtnKG5e V83ySUwFOko+3sb9jZcJMgiuNqQ7YxBWviuoPF3WwpWlFBfe7lH4MMnkCwqo0VuP40PV nypXcEtDkVzG0sCIUUZmYFi0BTyEPCCSndo/foVZzhA5i4lkrNBZIo9su1E2FbyLPqnx nvnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kCIggaYA/71vPMJZc9zILCDgq5tSouTYaTXsmSwSrik=; b=EfDJ7pIdCIq+1GRnKoko2WaqKYdd2jC1czJEtB6TJ71NsToIUJ5LloQMswfbROWeMP daz7ML+Awcup1P+DqPuuv88HlxGTLMxMluG+HTgOJBDaePY09T6BYiMj9W4p7wVgJyoK nu9SU1xoYMxTAGcZeANIKc6dZ4mPZay1McLLKVvXg6TIhAOS8vHgiR33z+YBF5bO2PmV +LUXNCPvtTNXNH0jDA1lL9ioaXhNxMuB45RAGoGrBQgQH5X/REIkhGiwhHEdQ76CYomW HWu36Vf2bZWcoqxmRFj4SFNv1IgDyhzp9TzQikIZF0INKURGUrjbXILmL7okRrJtr9yK 1YSg==
X-Gm-Message-State: ALQs6tBf5aA1fMqiBanv6kNqZLwfarQu9/oy9BdQoDNSO4znsz3KDBHE GuIW+iJcWvFryqbMTSHnpWdKgayrcVookyZU/H/MZXfe
X-Google-Smtp-Source: AIpwx49Rb5H8JihKpy5PV2esAgRsF4erpqOo/lWIjusCBIRq8LX2QBuv11yFThZQlqeEA9k9q5vsyE7+LPaGO09vlZU=
X-Received: by 2002:aca:df44:: with SMTP id w65-v6mr19670611oig.155.1524756160498; Thu, 26 Apr 2018 08:22:40 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 26 Apr 2018 08:22:40 -0700 (PDT)
In-Reply-To: <20180426151305.GL25259@localhost>
References: <> <> <20180426151305.GL25259@localhost>
From: Richard Barnes <>
Date: Thu, 26 Apr 2018 11:22:40 -0400
Message-ID: <>
To: Nico Williams <>
Cc: Eric Rescorla <>, TLS WG <>
Content-Type: multipart/alternative; boundary="00000000000050e1b9056ac1f586"
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:22:43 -0000

On Thu, Apr 26, 2018 at 11:13 AM, Nico Williams <>

> 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.


All the instances of "reserved" I can think of are either due to bit
alignment or blocking off old stuff.


> > 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.
> Nico
> --
> _______________________________________________
> TLS mailing list