Subject: Re: dns-threats, DNSSEC, and glue

From: Masataka Ohta <[email-masked]>
Date: Mon, 16 Feb 2004 21:10:42 +0900

Rob Austein wrote:
> <hat dnssec-editor=off just-another-bozo-on-this-bus=on>
> 
> Two separate reviewers of draft-ietf-dnsext-dns-threats have raised
> essentially the same question over the following paragraph:
> 
>    DNSSEC signatures do not cover glue records, so there's still a
>    possibility of a name-based attack involving glue, but with DNSSEC it
>    is possible to detect the attack by temporarily accepting the glue in
>    order to fetch the signed authoritative version of the same data,
>    then checking the signatures on the authoritative version.
> 
> Both reviewers asked, in essence, "does that mean that a
> security-aware resolver -will- use this defense?"

Sigh...

The only defense is to use separate cache for each delegation, which
has nothing to do with DNSSEC.

Never use glue of some delegation or cache of it for other delegation.

> The DNSSECbis drafts are silent on this issue.

That's fine.

> Should they say
> something about this?

No.

						Masataka Ohta

--
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: Samuel Weiler <[email-masked]>
Date: Mon, 16 Feb 2004 16:08:49 -0500 (EST)

> The DNSSECbis drafts are silent on this issue.  Should they say
> something about this?

No, DNSSECbis should neither mandate using this defense nor prohibit
using it.

Reasoning:

1) So long as the rest of the zone's data passes validation, the
essential service provided by DNSSEC (data authentication) is intact.

2) If an attacker substitutes nameservers that don't answer, the
resolver is left with no documented mechanism to find working
nameservers.  It doesn't make much sense to tell resolvers to do this
check when they have no fallback.  But such mechanisms are likely to
be developed in the future, which is why we shouldn't prohibit this
sort of checking,

3) Unless we care about query confidentiality.  At attacker could
redirect queries to itself, then answer with real signed zone data.
The benefit?  The attacker sees the queries.  Without doing the check,
resolvers don't know this is going on.  If we claimed that DNSSEC
offered any confidentiality protection, this might be worth looking at
in more depth.  (intro-08 reminds readers at least three times that
DNSSEC does not provide confidentiality protection.)

-- Sam

---

From: Derek Atkins <[email-masked]>
Date: Tue, 17 Feb 2004 12:22:39 -0500

> No, DNSSECbis should neither mandate using this defense nor prohibit

But should DNSSECbis _mention_ this defense as a potential means to
thwart the attack?  Sure, it doesn't have to mandate it, nor should it
prohibit, but should it at least be mentioned?  Or should we expect
resolver implementers to have read the threats document as well as
DNSSECbis?

-derek

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

---

From: "Scott Rose" <[email-masked]>
Date: Tue, 17 Feb 2004 13:11:45 -0500

----- Original Message ----- 
From: "Derek Atkins" <[email-masked]>

> resolver implementers to have read the threats document as well as

Maybe drop the defense suggestion (to avoid it sounding like a mandate), and
adding a more explicit reference to the threat document?

Trying to reach a compromise - I agree that the DNSSECbis drafts shouldn't
be making suggestions on things if they are not part of the spec.

Scott