Over the past too many weeks we have struggled to arrive at a rough
consensus on downgrade protection for the dnssec-chain extension.
Originally, and largely unnoticed by all, the specification described an
all too fragile approach that involved unilateral extension pinning by
the client. After I pointed this out, there was no controversy around
removing this, and I am not sad to see it go.
We've also reached consensus on adding denial of existence support, the
authors have started work on that, and perhaps some of the additional
text I'm proposing in that direction will be helpful.
The remaining issue is how to repair the gash in the specification
created by ripping out its original downgrade protection mechanism.
Though the original text was flawed the problem it attempted to address
does not go away just because we're not solving it yet. Only
applications where the extension is mandatory get by as-is.
There is in front of us a proposal to reserve 16-bits at the front of
the extension, that can later be used as part of a future downgrade
protection mechanism. The DNSSEC payload of the extension will be
multiple kilobytes, holding a signed TLSA RRset, and DNSKEY and DS
RRsets for multiple domains. It is hard to argue that prepending 16
zero bits is a burden on anyone, unless one is opposed not only to
implementing downgrade protection for this extension in one's own
applications at present, but is in fact opposed to ever implementing
it, and indeed opposed to giving others that same option (offering
a non-zero extension support lifetime is of course optional, as is
acting on such an offer).
Any negotiated (non-unilateral) downgrade protection will have finite
duration, and will include such a field. A principled stand against
16-bits of "wasted" payload, compared to the size of the included
DNSSEC chains, to block reaching a compromise on this draft suggests
a deeper opposition to any variant of downgrade protection one might
propose in a separate draft.
It would be helpful to know where opponents stand on negotiating
continued use of the extension in general and in the future. We
are confused by their statements so far, and wonder if they are
not just generally in opposition to any negotiation of continued
support for the extension (in all applications), and whether that
might be driving their opposition to the 16 bits, whether consciously
or not.
--
Viktor.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
