Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

Viktor Dukhovni <> Wed, 27 June 2018 16:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C7767130E95 for <>; Wed, 27 Jun 2018 09:56:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UQTJ0Mak_8bh for <>; Wed, 27 Jun 2018 09:56:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A75B5130EA6 for <>; Wed, 27 Jun 2018 09:56:14 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 7188B2963A0 for <>; Wed, 27 Jun 2018 12:56:13 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Wed, 27 Jun 2018 12:56:12 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <>
Message-Id: <>
References: <> <> <>
To: "<>" <>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <>
Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations
X-Mailman-Version: 2.1.26
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: Wed, 27 Jun 2018 16:56:18 -0000

> On Jun 26, 2018, at 12:20 AM, Joseph Salowey <> wrote:
> Hi Folks,
> There has been some discussion with a small group of folks on github -   I want to make sure there is consensus in the working group to take on the pinning work and see if there is consensus for modifications in the revision.  Please respond to the following questions on the list by July 10, 2018. 
> 1.  Do you support the working group taking on future work on a pinning mechanism (based on the modifications or another approach)?


> 2.  Do you support the reserved bytes in the revision for a future pinning mechanism?

Yes, no strong feelings whether it is exactly 2 bytes or an opaque<0..255>
to be defined as part of 1.  With either exactly 2 bytes, or an empty opaque,
the server signals that its operator does not (yet?) support unilateral
client-side pinning.  No to turning this into an extension block.

> 3.  Do you support the proof of denial of existence text in the revision?

Yes, with minor error corrections, where appropriate (perhaps
after the next I-D revision, easier perhaps to read a complete
snapshot than a pull request, and can also show

> 4.  Do you support the new and improved security considerations?

Yes.  We can word-smith any minor blemishes when the next I-D
version comes out.