Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps

Viktor Dukhovni <> Wed, 17 October 2018 06:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D3FA130E74 for <>; Tue, 16 Oct 2018 23:38:58 -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 LSBNatDlZTpp for <>; Tue, 16 Oct 2018 23:38:56 -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 6EA3412F1A5 for <>; Tue, 16 Oct 2018 23:38:56 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 6CE902C5AD; Wed, 17 Oct 2018 02:38:54 -0400 (EDT)
Date: Wed, 17 Oct 2018 02:38:54 -0400
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps
X-Mailman-Version: 2.1.29
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, 17 Oct 2018 06:38:58 -0000

On Wed, Oct 17, 2018 at 01:46:20AM -0400, Paul Wouters wrote:

> On Tue, 16 Oct 2018, Daniel Kahn Gillmor wrote:
> > That said, it sounds like negotiating the details of how to do this
> > pinning is the main blocker, and i'm sick of this proposal being blocked
> > (because i want it for "greenfield" implementations last year).
> Imagine how sick I will be when I try to do this later in a separate
> docment, where the WG might not even accept it as a WG item. I am not
> confident enough that pinning would be resolved in a later document at
> all, leaving me with my use case dead in the water forever.

Agreed, but at the same time in DKG's response, beyond the frustration
with the process, I see real signs of potential progress in the
form of broad agreement with the points we'ev made about the need
for and the nature of the proposed pinning approach.

So frankly, barring strong evidence to the contrary, I think we're
finally seeing an emerging consensus in support of the proposed
approach, be it so long as the deadlock is ultimately resolved.

Well, if rough consensus emerges for a non-deadlocked pinning design,
with no substantive unaddressed objections, then the deadlock goes
away, and we get to move forward to writing the consensus text,
with a bit of the usual bikeshedding, and will soon be done.