Subject: Re: Comments on restrict key

From: "Scott Rose" <[email-masked]>
Date: Thu, 9 May 2002 10:05:53 -0400

Here's where we (as a group, not just you and me :) need to clarify how
"middleboxes" (as Ed calls them) should handle data.
A caching servers should either ignore or cache all or be transparent and
allow them to be cached.  And if they are cached, do we want them to be
given out to other queries?  That means the end resolver is responsible for
determining if the response should be considered valid by protocol rules?

If we allow middle servers and caching servers to retain the KEY set
containing an obsolete KEY, that goes against what the draft is proposing -
restriction of the KEY record definition.  And could allow further abuse of
the KEY record.  However, as Ed pointed out, if the server rejects the KEY
RR set based on a single key that doesn't fit the new rules, then not only
does the zone loose its secure status, but there is no way of determining
what went wrong at the resolver level.

Personally, I am in favor of "dropping the entire RR set" if an invalid KEY
RR is encountered in a set, but there might need to be more debate on this
issue.

Scott

----- Original Message -----
From: "Erik Nordmark" <[email-masked]>
To: "Scott Rose" <[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>; <[email-masked]>
Sent: Thursday, May 09, 2002 5:23 AM
Subject: Re: Comments on restrict key

> > Our view of "reject" was "silently ignore the RR" and not store it in
cache.
> > Dropping the entire RRset might not be a good idea (if it's a older BIND
> > that has a single ipsec key mixed in with the zone key set, that would
be
> > unfortunate).  That way, the RRset should be verified, then the invalid
KEY
> > records deleted and not cached.
>
> If the intent is to silently ignore except when the SIG(KEY) is calculated
> then I think the document should explicitly say so. That
> seems to imply that it needs to be cached so that user's of the cache
> can get the complete KEY RRset and verify the SIG.
> "reject" sounds like "drop" to me which would mean that the SIG wouldn't
> verify.
>
> On the other hand the intent might be to reject the whole KEY RRset
> when one KEY is "bad".
>
> > I think the SIG(0) and TKEY specs might have to be updated to reflect
the
> > absence of host/user key differences.  There are now only zone/non-zone
> > keys.  Otherwise, admins will have to generate "user" keys for SIG(0)
keys,
> > etc.  I don't think the SIG(0) and TKEY specs specify what the flags
should
> > be (i.e. host or user)
>
> I had a look at those RFCs and they don't say anything specific. So they
> are probably fine.
>
>   Erik
>

--
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: Derek Atkins <[email-masked]>
Date: 09 May 2002 12:00:30 -0400

Be liberal in what you accept and conservative in what you send.

Middle boxes should not drop any data.  Once the TTL expires, then
it may drop it like anything else.

The resolver may choose to ignore invalid responses, or it may want
to see them.

Servers SHOULD NOT send out invalid data.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Brian Wellington <[email-masked]>
Date: Thu, 9 May 2002 10:20:20 -0700 (PDT)

> RR is encountered in a set, but there might need to be more debate on this

I don't think that can be done.  No server I've seen has a separate 'this
data is good' pass called before caching an RRset.  The data validity
check is merged with the data parsing stage, which introduces a problem
here.  If an invalid KEY record is seen, it will cause the message parsing
to terminate with a format error, which will cause none of the records in
the message to be cached, and bad things to happen (like retransmission 
and the complete inability to debug problems).

I think the right thing to do is to just ignore keys that are not
compliant with restrict-key.  Is there any good reason why these records
should be banned from the DNS, rather than simply ignored when using KEYs?  
There's no requirement that a server MUST drop a CNAME pointing to itself,
even though it's obviously not useful.

Brian

---

From: Sam Weiler <[email-masked]>
Date: Thu, 9 May 2002 17:05:42 -0400 (EDT)

On Thu, 9 May 2002, Scott Rose wrote:

> Personally, I am in favor of "dropping the entire RR set" if an
> invalid KEY RR is encountered in a set, but there might need to be
> more debate on this issue.

If we care about the following, then the answer should not be "drop
the entire RR set":

A malicious cache (or a malicious dnsspoof) returns to the client:
  -- a real KEY RR (#1)
  -- a SIG(KEY) on that RR
  -- an additional KEY RR (#2)

What should the client do?  A dumb client will try to validate the SIG
for the KEY RR set containing both 1 and 2, fail, and drop the entire
RRset.  A smarter client will try to validate the SIG(KEY) for all
subsets of the KEY RR set it received, eventually finding the valid
subset.  To reduce the workload, it should start with the subsets of
the expected size (1 or 2 KEYs) and go up from there, but this still
presents an opportunity for an attacker to consume some CPU cycles.

Does our threat model say this is out of scope?  Or that any attacker
capable of it is capable of worse attacks, so we don't need to bother
with it?

-- Sam

---

From: Rob Austein <[email-masked]>
Date: Thu, 09 May 2002 21:21:58 -0400

I think Ed pegged it.  This is an end-to-end issue, so pass the entire
RRset through unchanged and don't try to get clever in the middle.

---

From: "Andy W. Barclay" <[email-masked]>
Date: Thu, 09 May 2002 23:06:41 -0700

Sam Weiler wrote:

> RRset.

I don't see the problem here... The client should do exactly that.
Drop the set. END.

> A smarter client will try to validate the SIG(KEY) for all

Doing this would be wrong. The SIG is supposed to sign the set. There is
no need to check subsets.

.... snip.....

-- 
Regards,
Andy W. Barclay.        [email-masked]
fax  (781) 823-8276
Always a UNIX Evangelist (and sometimes a system and network architect)

The truth of a proposition has nothing to do with its
credibility. And Vice-Versa.