Subject: Re: planned obsolescence, and another TCR

From: Paul Vixie <[email-masked]>
Date: Sun, 30 May 2004 02:10:41 +0000

> It seems like, at the very least, it should be possible to rev all the
> DNSSEC record types, such that zones signed with DNSSECtre (which
> somehow magically solves the enumeration "problem" with compromising
> something equally important) appear unsigned to DNSSECbis-only
> resolvers.

yes.  this is what we did in TCR to invalidate the universe of RFC2535.

> This plan might present an upgrade impediment to zones signed with
> DNSSECbis; they might have to choose between providing twice as much
> data or appearing unsigned to DNSSECbis-only resolvers.

it won't be twice as much data.  another EDNS0 option bit will have to
be allocated to say "when i set the i-want-dnssec option, i really mean
dnssec-ter".  middleboxes who havn't cached an answer that was fetched
using this option will go upstream (forward, using this option) and only
data that was fetched using this option will be returned from a middlebox
who is queried using this option.  (that's what RRD and QDCOUNT>0 did in
the original EDNS specification, it was a way of upgrading a hop-by-hop
signalling method to end-to-end, and it would have worked, but we were a
weary and wary group of folks by that point in the EDNS adventure...)

> But if the only reason to upgrade to DNSSECtre is enumeration, then
> that choice has to be made anyway (either you didn't deploy DNSSECbis,
> or you did deploy it in spite of the enumeration concern, and you
> won't solve the enumeration concern without leaving behind
> DNSSECbis-only resolvers).

speaking for bind, i think it would be necessary to support both -bis and
-ter when signing (if that's what the zone operator asks for) and serving.
DNSKEY wouldn't have to rev this time, only RRSIG and/or NSEC.

it's even dimly possible that NSEC2 or RRSIG2 could be generated from NSEC
or RRSIG, assuming that the new ones are subsets of the old, so that a -ter
middlebox could synthesize -ter style responses if it had cached something
from a -bis style response.

the sky's the limit.  as long as, that is, we don't try to do it before -bis.
if we try to do it before -bis, then either -bis is late, or we have some
unfortunate compromises whose sideeffects take a long time to become known,
or more likely, both.  -bis must go as is.  TCR++ is the way to -ter.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>