Subject: [DNSOP] expanding on Re: Olafur's "black lies" presentation

From: Edward Lewis <[email-masked]>
Date: Fri, 8 Apr 2016 16:14:22 +0000

On 4/8/16, 12:08, "DNSOP on behalf of Ray Bellis" <[email-masked]
on behalf of [email-masked]> wrote:

>That said, Cloudflare's implementation appears to assert that the
>wildcard doesn't exist either - I've asked Olafur to check out the
>implications of that.

Not to pick, but I'm trying to remove the fact that this is tied to a
specific commercial offering.  Not because I want to ignore the real world
but to maintain proper discipline in thinking this through.

Yes, there is an implicit assumption about the wildcard.  I would restate
it as "the wild card doesn't apply".  Or, a "*" label doesn't exist one
label below the closest encloser (as defined in "The Role of Wildcards in
the Domain Name System" [trying to break the habit of talking in obscure
numbers]) of the QNAME.

The reason I recalled the MUST NOT is that, for the sake of argument, I
wrote it way back when.  I hadn't had in mind the wildcard, but, Ray's
right.  A non-DNSSEC aware zone could be left wondering -  although in
fairness, before DNSSEC, harking back to "Negative Caching of DNS Queries
(DNS NCACHE)" [2308], pre-DNSSEC, negative answers didn't reveal anything
about wildcards.

I do recall the reason why the MUST NOT clause came into being was so that
I could write a signer and keep my sanity.  I didn't want anyone to think
that they had to generate names just because they thought the name had to
say it didn't have any records.  There was some other reason too, when
eliminating names to sign, perhaps related to empty-non-terminals.  They
don't have NSEC records.

Where I see a root cause for concern is that DNSSEC was designed assuming
off-line signing.  This means that all negative answers had to be
precomputed.  With that, and a fairly large range of possible QNAMES, the
best approach to say "no" was to say "well, here's what I have, you can
see what you want isn't there."  NSEC and NSEC3 are both based on that
philosophy.  With on-line signing, you can craft a response to the
incoming QNAME that specifically says "what you want I don't have an
answer for."

This situation is fighting two uphill battles.  One, we are forcing the
use of a over-ly constrained container (meaning NSEC designed for not
having on-line keys).  Two, a zone has to say "no" consistently (this gets
into how a zone admin would work out having a set of servers that have
on-line signing simultaneous with a set that does not have on-line
signing).

What if some servers say QNAME NSEC QNAME++ nsec rrsig and another set say
ONAME NSEC YANAME types and *.something NSEC somethingelse.something
types?  I.e., the "black lies" and canonical NSEC.  Or if the other uses a
canonical NSEC3 response?  Will this confuse any attempts to do aggressive
use of NSEC?  And, not to be throwing FUD but asking out of wild
wondering, QNAME mininalization?

At first I thought that using NSEC would solve "two" above, but I'm not
sure.

What I am beginning to wonder about is how we can merge on-line signing
and off-line signing DNSSEC within a zone.  If we can rule that we can't
mix and match, that does change the assumptions regarding what it means to
interoperate between server implementations that do not support on-line
signing and those that do.

The off-line signing assumption of DNSSEC is not because anyone wanted it
that way.  In the era of the 90's, systems were 0wned so easily that no
one dreamed of putting keys on anything on the internet.  Today I can see
that there is willingness to run with on-line keys - but there are and
always will be - strong reasons for some operators to keep the key away
from the internet.  The choice to do so may work if done zone by zone and
not server set by server set.