Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Nico Williams <[e-mail]>]

On Wed, Apr 04, 2018 at 10:50:15AM -0700, Joseph Salowey wrote:
> Some objections were raised late during the review of
> the draft-ietf-tls-dnssec-chain-extension. The question before the working
> group is either to publish the document as is or to bring the document back
> into the working group to address the following issues:

For the record, I've had a document need changes after IESG publication
approval that were then made with a WG LC for those changes rather than
a repeat of WG LC, IETF LC, and IESG review.

I'm surprised that this changes should require "bring[ing] the document
back into the working group" if by that you mean going through the full
process all over.  Though, to be sure, I don't object if that's the
required path now, but I don't want people to feel compelled to be
against this LC on account of the delay in publication being much
bigger, not if there's a shorter method.  (Also, I don't mind a delay
all that much: it's hardly that big a deal; RFCs often end up stuck in
AUTH48 for much much longer!)

> - Recommendation of adding denial of existence proofs in the chain provided
> by the extension
> - Adding signaling to require the use of this extension for a period of
> time (Pinning with TTL)
> 
> This is a consensus call on how to progress this document.  Please answer
> the following questions:
> 
> 1) Do you support publication of the document as is, leaving these two
> issues to potentially be addressed in follow-up work?

I do not.

> If the answer to 1) is no then please indicate if you think the working
> group should work on the document to include
> 
> A) Recommendation of adding denial of existence proofs in the chain
> provided by the extension
> B) Adding signaling to require the use of this extension for a period of
> time (Pinning with TTL)
> C) Both

At least (B), and preferably (C).

My rationale for (B) is that this is the sort of thing where adding it
from the get-go will yield deployment where DANE is not mandatory for
the application whereas not adding it now will yield non-deployment of
DANE in such applications for a very long time.

My rationale for (C) is that (A) is trivial, so might as well throw it
in.  Mind you, (B) is also trivial (two bytes! to be conveyed however
you want, with 0 -> clear the pin to DANE).

Thanks,

Nico
--