Subject: Comments on restrict key

From: Erik Nordmark <[email-masked]>
Date: Tue, 7 May 2002 10:58:42 +0200 (CEST)

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

Comments on draft-ietf-dnsext-restrict-key-for-dnssec-02.txt

Section 3. Why do the eliminated flags have "SHOULD be set to zero by the
sender" and not a "MUST"?
If there is a desire to reuse these bits at some point in time
(10 years from now) I think the "MUST" is called for to get all
implementations to stop setting them to 1.

In RFC 2535 bits 2,4,5,8,9,10,11 have "must be zero" but in this
draft is says "SHOULD be zero". Was this an intentional change?

Section 3 says
	Name servers and resolvers SHOULD reject any KEY with a Protocol
	other than 3. 
Is this notion of "reject" well-defined in the DNS? If not it would
be benefitial to specify their handling in more detail.
(Details like "silently ignore the RR" vs. "drop the whole KEY RR set"
vs. something else.)

Section 5 says:
	DNSSEC non-zone key records (SIG(0)/TKEY keys) are backwards compatible,
	but the distinction between host and user keys (flag bit 6) is lost.
Does this imply that the SIG(0) and TKEY specifications are updated by
this document? (I didn't check what they might say about
host/user keys.)

Section 7:
Is there an IANA registry for the flags field?
Section 4 talks about this requiring a standards action for flags in that
field. Does it make sense to repeat that in the IANA considerations section?
(It would if such a registry already existed.)

Nits:
Section 2.1 bullet 4 says at the end "the entire KEY set)."
It is more exact and well-defined to say "the entire KEY RR set."
"KEY set" might read like "all the KEYs in a zone".

Section 5:
	DNSSEC zone key records are not change and remain backwards compatible.
s/change/changed/

  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: Ed Lewis <[email-masked]>
Date: Wed, 8 May 2002 08:35:31 -0400 (EDT)

This discussion brings back the "middle box" theme that ran for a
short period of time a few months ago.  To me, name servers should
not be interfering too much in the data transfer and play by just
the protocol data learning rules - that is credibility and whether
data passes the security checks.  Name servers shouldn't look
into otherwise valid data and see if the records are being abused.

When I read "reject" in the context of this draft, I took this to
mean that the key or keys that were "being abused" were to be
excluded from the verification process.  I can also see the that
the authoritative server would complain about the unrestricted
keys.

But once the key set is in the DNS, it is best to let it pass
through the caches - for the benefit of debugging.  (This is at the
heart of the middle box discussion.  If the intermediary devices,
such as caches get too smart, then it becomes difficult for a person
at the periphery to identify the problem.)  E.g., if someone is using
an old version of DNS software and publishes unrestricted KEY RR's,
then I want to be able to track this down, which is helped if I see
the KEY RR's that are causing unhappiness.

On Wed, 8 May 2002, Scott Rose wrote:

> Yeah, I wasn't thinking about caching servers.   Dropping the whole KEY set
> is best - but another reason a flag day is needed.  Otherwise every zone
> that has a non-dnssec KEY record at the apex will be deemed unsecure.
> 
> Scott
> 
> ----- Original Message -----
> From: "Rob Austein" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, May 07, 2002 5:46 PM
> Subject: Re: Comments on restrict key
> 
> 
> > At Tue, 7 May 2002 12:11:46 -0400, Scott Rose wrote:
> > >
> > > 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.
> >
> > Er, I don't think it'd be a good idea to split the RRset, if that's
> > what you're suggesting.
> >
> 
> 
> 
> --

---

From: Paul Vixie <[email-masked]>
Date: Thu, 09 May 2002 23:06:04 -0700

> 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.

"middleboxes" have a choice of either caching or not, and if they cache,
they have a choice of regenerating a message through a cache or forwarding
it.  "pass it through unchanged" is an oversimple directive.