Subject: Re: DNSSEC - Application use of Provable non-existence

From: Shane Kerr <[email-masked]>
Date: Mon, 4 Dec 2006 14:10:24 +0000

On 2006-11-30 14:36:25 -0500, Mike StJohns wrote:
> Unsecure is data under a trust anchor where there was a secure
> delegation into an unsecure zone (e.g. proof at the parent that the
> DS record didn't exist)

So, there is the equivalent of PNE for DS records under any model?
Otherwise an attacker can break the chain of trust, right?

> All you can say about data in an unsecure zone was that the parent 
> said it was unsecure.  A response of non-existence is no better or 
> worse than without DNSSEC or data not subordinate to a trust anchor.
> 
> If you say a site doesn't exist securely of course you know that the 
> data doesn't exist - now.  The question is how long you wait until 
> you decide that it might exist (e.g. TTLs)?  And how does that
> differ from what you do with DNS today (e.g. negative caching ttls)?
> I know that if I get an answer like that regardless of whether its
> validated or unvalidated, I'm probably going to try and force a DNS
> lookup past the cache, especially if I *know* (someone told me,
> someone wrote it down, it was on a web page, etc) it existed.
> 
> If you say a site doesn't exist insecurely, you don't have the data 
> to connect (i.e. no return of a A record) so you can't connect.  You 
> might want to try again - and if you get a validated answer that it 
> does exist (either PNE or SO) at a later time you connect.
> 
> I can't see any difference on the final result or even much on how I 
> got there...

So the difference under discussion is the TTL on negative caching,
right? (*)

In general, I thought we trust the administrator in DNS. We respect
TTL for caching.

If DNSSEC without negative caching is okay, then I guess we don't need
PNE, for some classes of applications. A big scary notice to anyone
using DNS might be in order though ("no doesn't *always* mean no").

> >For non-interactive applications... I don't know. The possible
> >attack is DoS, right? I guess some analysis of classes of
> >non-interactive applications can be made, but my intuition tells me
> >that most applications will need to handle this attack in a unique
> >way.
> 
> Yes.  I'd really like someone to make and publish analyses for 
> several applications rather than assume a field of dreams 
> approach.  At the very least it would silence some of the DNSSEC 
> critics who ask "What's the value-add for DNSSEC?"

Yeah... RFC 3833 says about authenticated denial of domain names: "The
question remains: how serious is this threat?"

It's been a couple of years... has there been any work done since
then?

--
Shane

(*) I'll think a bit more on the actual resolution process, I think
there is a difference there.

--
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: Mike StJohns <[email-masked]>
Date: Mon, 04 Dec 2006 12:31:34 -0500

>Otherwise an attacker can break the chain of trust, right?

Not exactly.  In both SO and PNE you break the chain of trust by 
failing to have a signature chain - in PNE, the semantics of that 
signature chain include signatures over NSEC(3) records which gives 
you the ability to  prove that a record doesn't exist.  In either 
case, you use the signature chain to prove the validity of one or 
more records - but what the records might say is that something 
doesn't exist.  So doing a deletion or modification attack on any 
RRSIG record results in an unvalidated answer for either SO or 
PNE.  Breaking the chain on a PNE proof of DS non-existence has the 
side effect of making all the stuff covered by the DS record "bogus".

>using DNS might be in order though ("no doesn't *always* mean no").

We trust current DNS to do reasonable negative caching - and that's a 
point of weakness mitigated by relatively short caching times.  If 
you do negative caching based on a proof of non-existence, you could 
up the negative caching time somewhat, but you then have to have 
another discussion about just how long you keep the stuff negatively 
cached.  Too long and the server may not retrieve legitimately new 
data that's published after the negative response from the 
authoritative server.

The semantics of a signature over existing data generally mean you 
can trust the binding of the name to the data over the signature 
lifetime (e.g. from signature inception to expiration) - that's a 
separate issue from keeping it in the cache which is a TTL issue.

The semantics of a signature over non-existing data - does that mean 
you can trust there will never be a binding of a name to data covered 
by the non-existence proof during the signature lifetime?  Can a 
validator rely on this?

In practice, the answer is that the reliance on a proof of 
non-existence is bounded by a number lower than the signature 
lifetime (e.g. the embedded original TTL of the NSEC record) - 
otherwise an administrative error (e.g. proving there are no MX 
records at the zone name for the next 20 years) would really screw 
you. (But consider an attacker who could get his hands on such a 
record and keep replaying in for the next 20 years :-) )

>It's been a couple of years... has there been any work done since

Some - not enough.

Later, Mike