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

[Melinda Shore <[e-mail]>]

On 4/10/18 3:53 PM, Nico Williams wrote:
> The earlier consensus is not just applicable, as if it were, we would
> not be having this LC.

I have no idea what that even means, to be honest.  We're through
last call, and it's not that the earlier wg consensus isn't
"applicable," it's that you've raised new issues.  So let's be
clear about that.

I've been watching this discussion and trying to get a handle
on what's been going on (and how this fits into several other
IETF issues more generally), and I think this discussion would
be over if the people arguing in favor of changing the use
of the extension had plans to implement it.  But so far nobody
has said that they do.  It's been suggested that if we intend to
stick with the original, intended use we can just ignore the extra
bytes, which strikes me as an exceedingly odd argument for including
new protocol features.

It's unfortunate that over in DNS-land they're discussing how
to get rid of unused features that increase complexity, while over
here we're having a discussion of how to add unused features that
increase complexity.

I think those of us who care about the institutional effectiveness
of the IETF and the value of the standardization process care
quite a bit about the amount of time it takes to push a document
through to publication.  Aside from negatively affecting the chances
of the success of a given protocol, it's harmful to the standards
process more broadly and discourages participation from people who want
to get work done.  There's an unfortunate number of IETF protocols that
people worked on for years and that never saw implementation, and
it seems to me that we ought to be trying to minimize the chances
of that happening with the protocols we're working on.  I haven't seen
anything in this discussion that leads me to believe that the
extension as specified is fundamentally broken or insecure for its
intended use.  I'm good with adding clarifying text or scoping it
more clearly, but beating this thing to death for a use case that
nobody intends to implement seems a bit misguided to me.

Melinda

-- 
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
                 34C0 DFB8 9172 9A76 DB8F