Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt

From: Paul Vixie <[email-masked]>
Date: Mon, 14 Jun 2004 15:54:07 +0000

> > (geoff, i'm not clear on how this proposal applies to NOERROR responses.)
> 
> Yes, this would likely not work properly if there were an owner name
> match.  There would have to be an NSEC RR associated with every
> authoritative owner name with a fictitious "Next Domain Field" entry.

yes.

> Am I correct in thinking this is the essence of the "NSEC White Lies"
> proposal in -trans?

i think so, yes.

> > if you do nothing, then paranoid clients will continue to have very
> > little confidence in spoofed data.  if you use a zone-covering NSEC
> > for all responses, then paranoid clients will have high confidence
> > in spoofed data.
> > 
> > not that i know of any paranoid clients, but we're all implicitly
> > assuming that there will be some, or else we wouldn't be doing dnssec.
> > 
> > i do not think that "a zone-covering NSEC" should be listed in -trans
> > as one of the alternatives.
> 
> Is "zone-covering NSEC" worse than "do-nothing"?  In "do-nothing",
> NOERROR replies can be spoofed; with "zone-covering NSEC", only
> NXDOMAIN replies could be spoofed, which seems to have substantially
> less potential for damage.

security is of course not a single metric.  it's rare to be able to boil
the "amount of security" in two proposals down to single numbers that you
can then compare and say "proposal one has more security than proposal two."

however, according to the dnssec threat model as i understand it, we treat
"becoming confident, due to proofs, in something which is actually not true"
as having "less security" overall (or perhaps having "more insecurity") then
"not being confident, due to lack of proof."

therefore, "zone-covering NSEC" is worse than "do-nothing".  as a potential
author of a client for all this technology, i'd much rather face a condition
where i know what i don't know, then one where i don't know what i know.

--
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: Peter Koch <[email-masked]>
Date: Mon, 14 Jun 2004 17:53:18 +0200

> Am I correct in thinking this is the essence of the "NSEC White Lies"

exactly.

> less potential for damage.

This is difficult to answer as it depends on one's expectations. In "do
nothing" we know it can happen, whereas in DNSSEC-bis we ``know'' it can't
happen. That's why NSEC white lies needs an agreed upon signalling method
which shouldn't need any new bits/flags.

-Peter

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 14 Jun 2004 19:45:44 +0200

Paul Vixie <[email-masked]> writes:

> therefore, "zone-covering NSEC" is worse than "do-nothing".

I don't understand this argument.

To evaluate a solution against a threat model, I believe the metric
you should use is what an attacker can and cannot do, given different
capabilities.

Here is simple evaluation:

In DNS, an active attacker can spoof anything, but positive and
negative responses, and cause DoS.  A passive attacker can't do much,
besides perhaps gathering query id information which can be used later
in an active attack, because the data sent is not confidential.

In DNSSEC an active attacker can cause DoS.  An active attacker cannot
spoof positive responses -- any correctly implemented resolver will
not be able to sign the signatures to a trusted root.  An active
attacker cannot spoof negative responses -- only data for which a
successfully verified NSEC exist will be authenticated as
non-existing.  For a passive attacker the situation is similar as
before, with the possible addition of being able to read ciphertext
for keys she may want to crack.

In DNSSEC with NSEC-lies, an active attacker can cause DoS.  An active
attacker cannot spoof positive responses.  An active attacker can
spoof negative responses, by replaying the lying NSEC.  For a passive
attacker the situation is similar as the previous case.

If you can show that with DNSSEC-with-NSEC-lies an active attacker can
spoof positive responses, you may have a case.  Otherwise, I believe
the conclusion is simple, if evaluated from the above perspective:
DNSSEC-with-NSEC-lies is an improvement to vanilla DNS.

It is possible, and useful, to go into more detail by differentiating
among the capabilities of active attackers: generic active attackers,
cache poisoning attackers, etc.  But I believe the DNSSEC threat model
include generic active attackers, so any less capable active attacker
is included in the generic active attacker.

> as a potential author of a client for all this technology, i'd much
> rather face a condition where i know what i don't know, then one
> where i don't know what i know.

DNSSEC doesn't guarantee data correctness, never has.  It guarantee
that what you see is the same as what the publisher of the zone wants
you to see.  If this include lying NSEC's, this is what you will see.

Regards,
Simon

---

From: Derek Atkins <[email-masked]>
Date: Mon, 14 Jun 2004 15:30:01 -0400

> DNSSEC-with-NSEC-lies is an improvement to vanilla DNS.

They cannot forge a new positive response to replace the real positive
response, but they can replay the lying-NSEC and cause the recipient
to believe authentically that there is no positive response to their
query even when it exists.  All they need to do is make sure the NSEC
replay is received and suppress the positive response.  So I suppose
this is just a DoS attack, but it's a DoS attack that does not exist
in normal DNSSec (nor with DNSSec with real-time signed NSEC).

In other words, an attacker could effectively authentically deny the
existence of all nodes in your zone covered by the lying NSEC records.

> is included in the generic active attacker.

This is correct.

> you to see.  If this include lying NSEC's, this is what you will see.

Right, but with lying NSEC you are not guaranteed that you'll receive
all the data.  A real positive response could be dropped in transit,
and with normal DNSSec you can detect this, but with lying NSEC you
cannot.

> Simon

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 14 Jun 2004 22:21:49 +0200

> in normal DNSSec (nor with DNSSec with real-time signed NSEC).

But compared with vanilla DNS, the situation is the same.  So I
couldn't follow how DNSSEC with lying NSEC's is worse than vanilla
DNS.  Compared to full DNSSEC, naturally DNSSEC with lying NSEC is
worse, but I doubt anyone thought otherwise.

Of course, being able to spoof that something doesn't exist is worse
than one might first assume; missing MX records can redirect e-mail.

Thanks,
Simon

PS. There were at least two typos in my post quoted above; `but
positive and negative' should have been `both positive and negative',
and `sign the signatures to a trusted root' should of course have been
`verify ...'.