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

[Shumon Huque <[e-mail]>]

On Thu, Apr 12, 2018 at 6:09 PM, Viktor Dukhovni <[e-mail]>
wrote:

>
>
> > On Apr 12, 2018, at 5:47 PM, Martin Thomson <[e-mail]>
> wrote:
> >
> > If this is indeed about adding [goo], what prevents Viktor or Paul
> > from proposing a new addition to the protocol in the form of a new I-D
> > that enacts the changes they wish to see?
>
> Why publish a crippled specification that needs immediate amendments that
> would
> require a second parallel extension to be defined and used by clients and
> servers
> to fix the issues in the current specification?  And the time to get that
> second
> extension would effectively delay the publication of a usable protocol.
>
> The protocol as described prohibits denial of existence responses.  Willem
> acknowledged (thus far in an off-list message) that that's an oversight
> that
> should be corrected, and such a correction is the substance of option (A).
>

As I said in a previous message, I'll support relaxing the language in the
draft
to permit delivery of authenticated denial chains for future applications
of the
protocol - I think that's just adding or modifying a couple of lines to the
draft,
and no wire changes.

Someone actually argued to me in person that the draft could be read as
not explicitly prohibiting authenticated denial (for NXDOMAIN/NODATA), but
if we want to allow it, I think it's best to be crystal clear.

If we can get consensus on that, then you could write a separate extension
to convey the pinning information and describe the additional behavior.
That
in combination with the existing draft would satisfy your use case. That
would in
fact be an incremental addition, and not a whole new parallel protocol.

Implementers that are opposed to pinning would then just ignore this second
draft (and not bother with the authenticated denial part of the first
draft). Since it
seems pretty clear you're not going to consensus on adding pinning to the
current
draft, I think you should pursue this approach. And then you can try to
convince
implementers and deployers, now or in the future, that they need to use both
extensions in combination.

-- 
Shumon Huque