Subject: Re: draft-ietf-dnsext-delegation-signer-01

From: Ramakrishna Gummadi <[email-masked]>
Date: Tue, 21 Aug 2001 15:04:13 -0700 (PDT)

> | One solution to this could be for the child itself to announce key
> | compromise into its name servers. The idea is that packet
> | hijacking
> | (either removing/redirecting packets from wire, or a man-in-the-middle
> | attack) is MUCH 
> | harder (although by no means impossible) than spoofing or introducing
> | bogus packets.  This way, the resolver (or a cache server) would get both
> | bogus info signed under the compromised key introduced by the hacker as
> | well as revocation information signed under the compromised key from the 
> | legitimate server. By preferring and caching such revocation info, servers
> | can protect themselves from bogus info.
> | 
> | Thus, the attacker would be successful under this model only for the
> | first query, even after compromising the key and spoofing replies.
> | 
> 
> Interesting idea...  so you would add a new revocation record?  

That's what I propose---a new revocation record that would be published by
the child and would be in effect until the parent changes the key. We can 
exploit DNS's "pull" model, and even if the attacker caches and
spoofs data using compromised key, the presence of a "revocation
key" record returned in the legitimate client's answer would render
attackers data useless in most cases. 

Note that revocation is not an issue in the DNSSec rfc, 
but I think a clean delegation scheme as 
described in draft-ietf-dnsext-delegation-signer-01 
offers enough
operational benefits to outweigh the cost of an extra signature
verification. I plan to write up a short note with the exact details on
how to support revocation in this case.

cheers,
ramki

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 22 Aug 2001 10:34:46 -0400

Didn't this idea come up some time ago?  I don't think anyone suggested a
"revocation RR", but the idea of adding a revocation list to DNS was
suggested.  I think it was because the idea was a full revocation list (all
the KEYs ever used, then expired by the zone - which makes a large list).
The other point brought up was that most applications don't check revocation
lists anyway, so what's the point ;-)

This new revocation record will be short lived (i.e. removed from the zone
after a period of time) or be persistant of all expired KEYs?  What's
stopping an attacker from deleting the revocation RR in transit?

Scott

---

From: Edward Lewis <[email-masked]>
Date: Wed, 22 Aug 2001 21:13:36 -0400

IMHO, DNS != PKI, and we shouldn't make it one.

There are many reasons why I feel this way.  Probably the most basic is the
observation that a lookup service, such as DNS, is so critical to the
operations of the distributed system surrounding it that we need to keep it
as simple as possible.  This should be done to limit the chance the service
will fail (principly by keeping the implementation software simple).

Note that what constitutes simplicity is poorly defined.  DNS as of RFC
1035 (and clarifications such as 2181) is much simpler than DNS + DNSSEC
and/or DNS + A6.  But the services added by DNSSEC and A6 are (argueably)
simple enough and important enough to stretch the mission a bit more.
Augmenting DNS to become a PKI is not so simple, take for example the PKIX
WG documents and try "porting" them to DNS.  (Some of the document titles
are longer than DNS drafts. :))

Note: I don't intend to make the claim that A6 is a must do for DNS -
especially not in this thread - but it is an example of a recent effort to
significantly augment DNS.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Wed, 22 Aug 2001 17:02:57 -0700 (PDT)

> lists anyway, so what's the point ;-)

In this case, the resolver/cache would get a positive affirmation of
revocation for just the name being resolved, in place of further
resolution information. Such a "revocation" is an answer produced
on-demand that aborts the secure name-resolution process, and applications
don't have to be aware of all revocations in
the world. Therefore, 
revocation *decreases* availability temporarily to avoid the risk of
being redirected to bogus servers. Such a behavior may be deemed
acceptable for some servers (mail, etc.) but not for others, and it
can be a policy choice at the client/resolver whether it wants to heed
this info.

> after a period of time) or be persistant of all expired KEYs?  

The child does revocation only to convey the information that the parent 
has not yet been able to host a signature over the newly created key (in
other words, the parent still holds signature over a compromised key),
and, as such, no revocation history info need be stored. The child
deletes a revocation record permanently once the
parent hosts the new signature.

> What's

The assumption here is that packets are much harder to delete/hijack,
rather than spoof/watch/copy. This does not offer any provable/perfect
security because it relies on the physical media
(wire/wireless) properties, and on 
"reversibility" property of routing. However, note that even
a large chunk of DNSSec relies on this---for example, if a hacker can
subvert routing, then the attacked host can still end up talking to bogus
hacker-controlled web servers and mail servers (or any server that does
not use end-to-end authentication) even though these addresses are obtained
securely.

cheers,
ramki

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 23 Aug 2001 09:30:39 -0400

I guess I'm with Ed on this point when he says that DNS was designed as a
lookup service, not a PKI.  Putting more PKI features in DNS requires more
coding on the server and resolver end, and we'll end up with a bloated
protocol too.  "Key revocation" in DNS has usually always meant "low TTL
values in case of compromise".  And if the DS record is used, the parent
will be ultimately reponsible for stating the security status of the child
zone.  The best use (as I see it) of a revocation RR would be when the child
has changed KEYs (emergancy) and the parent hasn't updated it's DS record to
reflect that yet.

IMHO, Since there are many security features DNS lacks, forcing it to try
and be more like a PKI is counter productive.

 Scott
===============================================================
Scott Rose
Advanced Network Technologies Division
NIST

ph: 301-975-8439                       fax: 301-590-0932
http://www.nist.gov
===============================================================
----- Original Message -----
From: "Ramakrishna Gummadi" <[email-masked]>
To: "Scott Rose" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 22, 2001 8:02 PM
Subject: Re: draft-ietf-dnsext-delegation-signer-01

> > > > | bogus packets.  This way, the resolver (or a cache server) would
get
> > both
> > > > | bogus info signed under the compromised key introduced by the
hacker
> > as
> > > > | well as revocation information signed under the compromised key
from
> > the