Subject: Re: Comments on restrict key

From: "Scott Rose" <[email-masked]>
Date: Tue, 7 May 2002 12:11:46 -0400

As one of the authors, I think I can address some of these items - and try
to clarify things that I found to be muddy too.

> [ 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?
>

This is one of the muddy things:  RFC2535  uses "must be zero"  The
restrict-key draft says "SHOULD" and the DNSSEC resource records draft says
"MUST".  I am in favor of the resource records draft:  "MUST" be zero.  Not
sure why "SHOULD" was chosen, but MUST covers information hiding as well.

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

> 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.)
>
With this draft, there will only be 2 types of keys:  zone and non-zone
(assumed to be host).  Non-zone keys will be used to generate SIG(0) and
TKEY applications.  In the current BIND implementation, host keys are flaged
"10" (bits 6 and 7) while zone keys are "01" and user keys are "00".

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)

> 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.)
>
Not that I am aware of.  RFC2535 says that the flag bits in the KEY record
were to be assigned through "IETF consensous" so there is no IANA registry
for flag bits.  Only protocol (obselete now) and algorithim.

> 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".
>
Good correction.  I think this will make it more clear.

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

>   Erik

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

ph: 301-975-8439                       fax: 301-590-0932
http://www.antd.nist.gov/proj/dnssec
===============================================================

--
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: Rob Austein <[email-masked]>
Date: Tue, 07 May 2002 17:46:23 -0400

> 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: "Scott Rose" <[email-masked]>
Date: Wed, 8 May 2002 07:29:19 -0400

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

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 9 May 2002 11:23:05 +0200 (CEST)

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

> etc.  I don't think the SIG(0) and TKEY specs specify what the flags should

I had a look at those RFCs and they don't say anything specific. So they
are probably fine.

  Erik