Subject: Re: Proposal to fix NSEC

From: Paul Vixie <[email-masked]>
Date: Tue, 01 Jun 2004 14:20:46 +0000

> ...
> If we follow this path, it still leaves two options open at this stage,
> AFAICS:
> ...
> b) Assume that NSEC2 will somehow find a way within the DNSSECbis docset to
> migrate without change to DNSSECbis.

i'm writing up a proposal to this effect in the xterm next to this one.

> I actually am still of the view that if nameservers suddenly started
> returning NSEC2 instead of NSEC things would work as desired: namely old
> resolvers would suddenly get protocol errors instead of NXDOMAIN, and new
> resolvers would just work.

that would be a downgrade attack, launched by a zone owner against herself,
and would only be of interest to zone owners who had not previously
implemented dnssec-bis.  let's do better.  i know several ways to do better.

--
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/>

---

From: Paul Vixie <[email-masked]>
Date: Wed, 02 Jun 2004 14:08:01 +0000

> >    2.5. It is possible that DNSSEC-TER metadata could be synthesized
> >    using only DNSSEC-BIS metadata.  For example, an NSEC2 RR ...

> I'd note that you'd need a complete copy of the zone to do this.

that's true of NSEC2 as you've proposed it, but it may not be true of what
the chairs are calling "NSEC2/NO++".  in any case the possibility of such
synthesis should be discussed when setting the parameters for going forward.

it could be that such synthesis would be a bad thing in all cases, since the
NSEC (or NSEC2/NO++) might say that only one of the RR types actually exists,
yet if you query for the other one, you get a positive (synthetic) answer.

we do not need to select a particular "NSEC2/NO++" solution in order to prove
that one can exist.  in <draft-vixie-dnssec-ter-##.txt> i intend only that we
show an understanding of the working conditions of the DNSSEC-TER designers.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 09 Jun 2004 17:25:02 +0000

> > ...
> > There still needs to be some information about the DS, or lack
> > thereof.  I don't see what signing the NS set gains us with this.
> 
> It means that the delegation can't be spoofed.

the threat in this case is being delegated toward a serverset who can't sign
its responses with the key denoted by the parent's DS.  this is a denial of
service attack, but it would be easier to launch one using congestion than
by query-id guessing.

> Note that the delegation could be to a nameserver in a signed domain,
> and so its A record could also not be spoofed.

none of that matters.  the responding subdomain servers can either sign its
responses using the key given in the parent-DS, or it can't.  no amount of
NS-signing by the parent will cause a third alternative to appear.

at first glance there appears to be an opportunity to improve the situation
by offering trusted delegations to unsecure zones.  however, this just moves
the query-id guessing attack down one level.  if the subdomain zones are not
secure, then it doesn't help that the parent-NS that delegates to them is
signed and trustworthy.

dnssec isn't just end-to-end, it's root-to-leaf.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 09 Jun 2004 18:41:09 +0000

note: since this is about clarifying the existing documents rather than
about whether NSEC2 should be adopted (or what DNSSEC-TER should look like),
i don't believe that the chairs' radio silence request applies.  if i'm
wrong, i'd like a chair to clarify the radio silence request in public.

> > the threat in this case is being delegated toward a serverset who
> > can't sign its responses with the key denoted by the parent's DS.
> > this is a denial of service attack, but it would be easier to launch
> > one using congestion than by query-id guessing.
> 
> The assumption was that there would be no DS.

if there's no ds, then there's no value added by signing anything in the
delegation.

> Well, there may be other reasons to rely on the nameserver (or avoid
> spoofing thereof) - for example, it is at the other end of some IPSEC
> or VPN authentication, or it is inside a trusted network.

that configuration is outside of dns proper, and is not a topic area for
dnssec-bis.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 10 Jun 2004 14:24:32 +0000

> I'm not sure what you're saying here - do you mean it shouldn't be
> discussed at all w.r.t. DNSSEC, or do you mean that it isn't relevant to
> finalising the docset?

i think that the use of dns over non-ip networks like tunnels is not
described anywhere, and so the dnssec-bis protocol and docset has no
reason to mention the configuration you've described.  it's the same
as NAT.  there's no rfc that describes dns response rewriting by NAT
boxes, and so, dnssec-bis behaves as though such rewriting doesn't
occur.  this may be a bad thing, and it may be that there should be
rfc's about "implications of nat on dns" and "implications of private
secure tunnels on dns" and so on.  but today there are no such, and
the dnssec-bis design team would be foolish to try to cover undefined
working conditions.

note that the lack of signatures on nonauthoritative delegation NS RRsets
has simplified the design, and changing it in the 11th hour isn't an
option because of the impact such a change will have on other parts of
the model.  if it's to be changed, then it's really a dnssec-ter issue.

---

From: Jim Reid <[email-masked]>
Date: Thu, 10 Jun 2004 17:37:22 +0100

>>>>> "Ben" == Ben Laurie <[email-masked]> writes:

    Ben> Note sure I understand this - the presence of v2 of NSEC
    Ben> would signal that there are also NSECINFO and EXISTS records,
    Ben> wouldn't it?

Not necessarily. Who can say now what NSECv2 will finally look like or
predict how many new RR types it'll need?

---

From: Paul Vixie <[email-masked]>
Date: Thu, 10 Jun 2004 17:15:54 +0000

> > as NAT.  ... and the dnssec-bis design team would be foolish to try
> > to cover undefined working conditions.

> ... but I do think it should be explained and possibly also mentioned
> in the security considerations.

why is that, exactly?  should we also mention that it won't work over
sneaker-net or avian-net, or after global thermonuclear war?  i'm not
*just* being peevish, i'm trying to point out that there are a lot of
actual, potential, or imaginable circumstances under which dnssec-bis
would be unusable or inapplicable.  why is this particular one worthy
of specific mention in the document?

some years ago an earlier instance of IAB gave us a "statement regarding
the end-to-end nature of internet communications" or some such.  i thought
it was a mistake, since even at that time, real internet communications
used very different models than the one described in that statement.  but
the one thing that statement gave us was well defined starting conditions
for subsequent (or even previous) protocol specifications.

using dnssec to get a secure path from some trust anchor (like the root,
maybe, someday) to some delegation point, where the NS RR was trustworthy
but the A RR maybe or maybe not so and the zone definitely not, on the
basis that perhaps some validators will have out-of-band methods of
trusting the communications with or content received from the servers for
such zones, is so far away from dnssec-bis's "starting conditions" that
you might just as well talk about how dnssec-bis would work for harry
potter if his wand spoke tcp/ip.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 11 Jun 2004 17:28:22 +0000

> > I hope the assumptions one might have about a crypto-driven DDoS attack
> > is hereby tuned to a non-issue.
> 
> I can't agree that having to deploy expensive crypto accelerators makes
> anything a non-issue.

then you're having a different conversation than the rest of us.

> What I would agree is that it makes it a soluble issue.

anything that can be solved outofband is a nonissue for dnssec-bis @IESG.

the conversation at hand is, can we send dnssec-bis to the IESG.

you appear to be saying "yes", both in the above "makes it soluble" comment
and in your agreement with my dnssec-ter-01 draft.

any issue like "the crypto boards will cost too much" isn't relevant.  any
issue like "online NSEC synthesis will expose the signing key to attacks
because the attacker can force the victim to do unsalted crypto" is relevant.

i realize that these issues are equally near and dear to you.  but they are
very different from the point of view of our chairs, who only want to know
if they can forward the dnssec-bis docset to the IESG.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 11 Jun 2004 17:32:48 +0000

> > ...  Dynamic NSEC synthesis is currently the middle ground to
> > satisfy both sides of the spectrum where one side wants to deploy
> > DNSSEC-bis as-is, and the other side wants to deploy DNSSEC with
> > defense against zone-traversal.  This middle-ground would be
> > temporal until an upgrade is available per Vixie's dnssec-ter
> > proposal, where, again, both side of the spectrum are satisfied.  I
> > stick with the short and long term recommendation in the draft. I
> > hope it reaches consensus, so we can move on.
> 
> Consensus on that point would presumably require some people willing
> to implement it - are there any?

i don't expect isc's existing funding sources to think that this is an
important topic for us to spend effort on in the short term.  (the bind
forum seems to be more interested in performance and documentation and
usability than on advanced dnssec features, but that could change.)

however, new funding would bring its own rules.  so, theoretically at
least, there are some people willing to implement/prototype dnssec-ter,
subject only to resource availability.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 11 Jun 2004 17:42:13 +0000

> > I would suggest the next domain name be the apex - indicating it is
> > the last canonical name in the zone.  Yes, it isn't true, but caches
> > should be fabricating non-existance responses for non-authoritative
> > data anyway.

there's a replay attack possible if the range of domain names between the
owner and target of an NSEC is not actually known to be empty.

> Or would just:
> example. NSEC example.
> suffice?

this is my preference, but i admit i don't know whether the current -bis
spec requires that either an NSEC owner or target name, or both, actually
does exist.  certainly the expectation is that the owner name exists, which
is why there's a list of RRtypes in the NSEC rdata.  but as to whether the
validation model actually requires such existence, i don't know.  would an
NSEC asserting that no RRtypes were present at its owner name be valid?

---

From: Paul Vixie <[email-masked]>
Date: Fri, 11 Jun 2004 21:29:30 +0000

> ..., I'm leaning towards the vastly cheaper and safer option of having
> a single (or two) NSEC record(s) that can be used for all denials as the
> interim measure of choice.

this will open you up to replay attacks.  anyone who receives one of these
NSECs, signed by you and clearly covering a large range of existing names,
would be able to use it along with queryid-guessing to make someone believe
an existing domain name does not exist.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 23 Jun 2004 14:14:43 +0000

> > what would be best, though, is if implementors either followed the -bis
> > specs completely (avoiding loopholes), or waited for -ter.

this is still my position.

> > since it's possible to synthesize NSEC with a target range that only
> > covers the qname,
> 
> This is also in violation of the protocol, surely, since both the owner and
> next domain fields would not exist.

yes, sorry.  i forgot where we'd gotten to last time we explored this.