Notes from my presentation on opt-in at IETF 55

[Rob Austein <sra+namedroppers@hactrn.net>]

For those who missed it at the time, here's approximately what I said
about opt-in at the DNSEXT meeting in Atlanta (IETF 55).  Please note
that implementation and testing status has progressed since this was
written, so the comment about workshop experience is a bit dated.

===

Technical State Of Play

So far, almost all the opt-in corner cases we've investigated have
turned out to be base DNSSEC corner cases, not opt-in specific.

In a few corner cases, opt-in requires special treatment, (eg: the AD
bit); as far as we know none of the opt-in-specific stuff is major.

As far as we know, delegation-only opt-in with DS is just as capable
of providing a secure path down from the root as non-opt-in DNSSEC.
Signed delegations are handled with NXT and DS RRs down from the
parent whether one is using opt-in or not; the difference is just how
one handles unsigned delegations.

One important thing that the opt-in investigation has taught us is
that caching in a DNSSEC universe probably needs to be blobs of stuff
keyed by <qname,qclass,qtype>, rather than any attempt to cache under
the actual record types in the returned response.  Opt-in makes the
need for this a little more obvious, but the need is there even
without opt-in.

Chosing opt-in does impose a more complex code path (have to handle
both senses of the NXT bit).  Once chosen, opt-in is "forever",
although we might deprecate one value of the bit eventually.
Complexity is almost always the enemy of security.  DNSSEC is a
complex protocol even without opt-in.  Opt-in does make this a little
worse.

We do not yet have workshop experience with opt-in.  We have just had
our noses rubbed in the need for testing yet again with DS (psuedo
lame delegation and wildcard proof surprise issues).  Opt-in looks
workable on paper, but there seems no way that we could chose opt-in
without adding at least another N months for development and testing.

The one thing that (almost) all sides of the "are anycast roots a good
idea?" debate agree on is that the sooner we get a working DNSSEC out
there, the less scary anycast roots will be.

===

Does Opt-In Benefit Anybody?

Opt-in does help authoritative name server operators by allowing
(some) costs to scale with deployment.

Opt-in does not help resolver (aka "caching server") operators; it
probably makes things worse, because additional complexity almost
always means more failure modes.

Opt-in does not help developers; again, it probably makes things
worse, because additional complexity almost always means more failure
modes.

We don't really know whether opt-in helps users.  More precisely, we
know that is likely to help users with some things (reduction of some
costs passed along by authoritative zone operators) and hurt with
other things (increased cost of software development and maintenance).

===

My Personal Opinions

On the whole, the strictly technical costs of opt-in are higher than
the strictly technical benefits.

The cost vs benefit to the Internet as a whole is not just a technical
issue.  If the cost of non-opt-in DNSSEC is so high that authoritative
zone operators refuse to deploy it, it does not matter whether
non-opt-in DNSSEC is "better".

One day real soon now we really do need to make a decision and stick
to it.

We are probably getting to the point where we need DNSSEC badly enough
that the cost of not having DNSSEC is going to outweigh the cost of
DNSSEC either with or without opt-in.

===

"This holy war is not the first one, and probably will not be the last
one either....  I do hope that my way will be chosen, but I believe
that, after all, which way is chosen does not make too much
difference.  It is more important to agree upon an order than which
order is agreed upon.

How about tossing a coin ???"

Danny Cohen, "On Holy Wars And A Plea For Peace", Internet Engineering
Note 137, 1 April 1980.

===

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