Subject: Section 2 of draft-ietf-dnsext-dnssec-protocol-03

From: Mike StJohns <[email-masked]>
Date: Tue, 28 Oct 2003 20:11:50 -0500

I was originally just going to send these to the editor, but I think there 
are still a few substantive problems here.   (Obviously, these are opinions 
rather than directives, but its easier to write protocol stuff as 
directive...:-)

Meta comment - much of the language in this section describes operational 
constraints rather than protocol constraints.  This document really needs 
to describe the behavior of the protocol (e.g. "if the RRSIG is missing 
then..."), rather than trying to abscribe MUSTs and SHOULDs to the 
operators (e.g. "the zone must contain an RRSIG for every...").

These are in section order rather than order of importance...

2.1, first para, second sentence beginning:  "For each private 
key...".  Instead how about:  "For each RRSIG there MUST be a corresponding 
zone DNSKEY RR.  Orphan RRSIG RRs (e.g. those without corresponding DNSKEY 
RRs) are considered extraneous information and MUST be ignored."

2.1, 1para, 3rd sentence beginning "A zone key..." - delete "to one" - nit 
- flags are either set or cleared.

2.1 1para, last sentence - replace with "Public keys stored in DNSKEY RRs 
marked as zone keys SHOULD NOT be used for purposes other than DNS 
operations.  However, enforcement of this restriction is properly left up 
to the standards which describe those other purposes."

2.1 2nd para, last sentence beginning "This DNSKEY RR..." - DNSKEY signing 
key doesn't actually appear to be defined in the reference.

2.2, pg 7, 2nd para after the bullets at top beginning "An RRSIG 
RR...".  Replace entirely with:
"An RRSIG RR itself SHOULD NOT be signed since signing an RRSIG RR would 
add no value.  RRSIG RRs with a covered type of RRSIG are considered 
extraneous and MUST be ignored."

2.2 pg 7, 3rd para after bullets.  Insert after first sentence:  "Zones 
where the the apex NS RRSet is not validly signed (and should have been 
based on a validated DS in the parent zone) are considered bogus."

[Commentary - there are notionally three states for zones, insecure, secure 
and bogus.  The latter applies only to zones where the resolver was 
expecting to receive a secure result and did not.  Bogus results come from 
bad signatures, missing signatures, or broken chains from a trust anchor.  ]

2.2 pg7, 4th para after bullets beginning "There MUST be..."  This 
continues to feel like the tail wagging the dog.  The DS RR was added to 
prevent the requirement for close consultation between parent and child and 
this seems to have way too close coordination between parent and child.  It 
also seems strange to require every RRset in a zone to be signed by ALL 
algorithms...

How about:

"1) The apex DNSKEY RRset SHOULD be signed by all apex DNSKEYs with both 
the zone key and SEP key flags set. [General definition of a SEP key is 
that it signs the zone DNSKEY RRSet]

2) The apex DNSKEY RRSet SHOULD include at least one non-SEP zone DNSKEY 
with a matching algorithm for each algorithm in the SEP set at the apex. 
[Need this for flow through since these sign all the non-DNSKEY rrsets]

3) All DS RRsets in a zone SHOULD be signed by at least one non-SEP zone 
DNSKEY for each algorithm in the apex SEP zone DNSKEY set. [The maintains 
the algorithm consistency from root to leaf in each zone without requiring 
all the elements of the zone to be signed by all algorithms.]

4) The DS RRset in the parent SHOULD include pointers to all child apex 
DNSKEYs with both the zone key and SEP key flags set.

5) The above represents guidance which should be enforced by the tools 
designed to sign and maintain zones. Failure to enforce these criteria will 
generally result in the inability to verify the security of a zone. The 
actual impact of failure to follow such guidance is described later in 
sections 4 and 5.

6) All resolvers MUST be able to verify RSA and DSA signatures.  Signing 
tools MUST support RSA signatures and MAY support DSA signatures [is this 
the right order? I forget]"

 >>>>General comment: the most important thing is that the resolvers know 
how to resolve all the signature types.  If we add additional sig 
algorithms we will need to update the resolver requirement (6 above) but 
not the resolution process.  Its way too hard to try and enforce the 
numbers and types of signatures in the actual DNS.  Its more than hard to 
try and do the enforcement between parent and child.  The other thing we 
want to prevent is requiring a parent to do more signatures just because a 
child does them.

But, we still need language in section 5 addressing whether data signed by 
an algorithm you don't understand is either bogus or insecure - I argue for 
the latter.

Section 2.3 - There's some confusion here.  A "glue" address record can be 
a real record in the zone -  e.g. zone example.com,  bar.example.com ns 
foo.example.com, foo.example.com A 1.1.1.1.  Given that this is a real A 
record, I *think* it gets an NSEC RR, but the language in this section 
suggests otherwise.  [I think the fallacious assumption is that zones are 
either delegation-only, or non-delegation.]

Section 2.4 - This should reflect my comment above - item (4) that the DS 
RRSet should include pointers to all of the SEP keys.

--
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, 28 Oct 2003 20:52:11 -0500

At Tue, 28 Oct 2003 20:11:50 -0500, Michael StJohns wrote:
> ...
> suggests otherwise.

If foo.example.com is delegated, then the A RRset for foo.example.com
in the example.com zone is glue, and doesn't show up in the NSEC RR at
foo.example.com in the example.com zone.

If foo.example.com isn't delegated, then the A RRset for
foo.example.com isn't glue, and does show up in the NSEC RR.

> [I think the fallacious assumption is that zones are either
> delegation-only, or non-delegation.]

No such assumption.  You're just paying the word "glue" extra :).

---

From: Mike StJohns <[email-masked]>
Date: Tue, 28 Oct 2003 21:49:13 -0500

>foo.example.com in the example.com zone.

Right, but the zone that was delegated in my example was 
bar.example.com.  The A records for one of the name servers actually are in 
example.com (at foo.example.com) rather than being in the delegated domain 
(bar.example.com)

The problem is the term "glue" I think.  When I think of glue, I think of A 
records not in the zone, in which case its pretty clear that an NSEC record 
for that type of record shouldn't exist here.  The problem is the language 
at 2.4:

"Each owner name IN THE ZONE MUST have an NSEC resource record, except for 
the owner names of any glue address RRsets."  (emphasis mine)

E.g. is a true "glue address RRset" in the zone?

---

From: Rob Austein <[email-masked]>
Date: Tue, 28 Oct 2003 22:09:40 -0500

At Tue, 28 Oct 2003 21:49:13 -0500, Michael StJohns wrote:
> bar.example.com.

You said that bar.example.com was delegated.  You didn't way whether
foo.example.com was delegated or not, so I answered it both ways.

> The A records for one of the name servers actually are in
> example.com (at foo.example.com) rather than being in the delegated
> domain (bar.example.com)

So foo.example.com isn't delegated, so it's not glue, hence 2.4 says
it should have an NSEC RR.

> the owner names of any glue address RRsets."  (emphasis mine)

After reviewing RFC 2181, I'm inclined to agree that we should just
lose the word "glue" entirely here, albiet for slightly different
reasons.

For the purposes discussed in this section, there are three catagories
of data in a zone:

- Authoritative data;

- Nonauthoritative NS RRsets (the delegations themselves)

- All other nonauthoritative data (normally only addresses)

RFC 2181 5.4.1 refers to all non-authoritative data in a zone as
"glue", including the delegation NS RRsets.  So let's just punt the
term entirely as too blunt an instrument for this nitpicky level of
protocol detail.  How about:

"Every authoritative RRset or delegation point NS RRset in the zone
MUST have an NSEC resource record."

---

From: Mike StJohns <[email-masked]>
Date: Tue, 28 Oct 2003 23:09:20 -0500

At 10:09 PM 10/28/2003, Rob Austein wrote:
Thanks for reparsing this...

>MUST have an NSEC resource record."

I hate terminology... in this case a DS RRset is authoritative because it 
belongs to the parent even though the name is the apex name of the child 
zone...right..  I think that's more precise than what's there and less 
subject to confusion.

done.

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 29 Oct 2003 10:03:52 -0500

----- Original Message ----- 
From: "Mike StJohns" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, October 28, 2003 8:11 PM
Subject: Section 2 of draft-ietf-dnsext-dnssec-protocol-03

> RRs) are considered extraneous information and MUST be ignored."

It is possible to have RRSIGs in a zone and the DNSKEY statically
configured, and not in the zone.  It is silly, but for some private DNS, it
might be desired.

> to the standards which describe those other purposes."

ack.

> key doesn't actually appear to be defined in the reference.
The def is for "key Signing key" - a more general definition.

> extraneous and MUST be ignored."

"MUST be ignored" is the phrase that I have a problem with.  Ignored by the
resolver, or the name server?  Forbidding RRSIGs from being signed gets the
point across in my opinion.

> bad signatures, missing signatures, or broken chains from a trust
nchor.  ]
> also seems strange to require every RRset in a zone to be signed by ALL

I believe that was to be "every algorithm /present/..." not necessary every
algorithm defined for DNSSEC.  The child MUST have a RRSIG generated using
the same algos as found in the DS set in the parent, plus any other algos
found in the child apex and not in the parent's DS set.

> DNSKEYs with both the zone key and SEP key flags set.

Not sure what you mean here with 4): Both the zone key and the SEP key?
That nullifies the idea of having a SEP key different than the zone key.  Or
all DNSKEY RRs with both the zone and SEP bits set?

> the right order? I forget]"

RSA/SHA1 is mandatory, DSA is recommended.  The records draft states this,
but maybe it could be repeated here.  I don't think it is a good idea to
designate algorithms by name, since RSA/DSA/ECC/ROT13 might be dropped for
some reason in the future.

Thanks for the input

Scott

---

From: Mike StJohns <[email-masked]>
Date: Wed, 29 Oct 2003 11:25:05 -0500

>configured, and not in the zone.  It is silly, but for some private DNS, it

Let's just say no.  The DNSKEY needs to be in the DNS. the static 
configuration of the trust anchor can refer to that DNSKEY, but can't 
synthesize it.   Reason: Referential integrity.  Reason: Simpler if less 
special cases in the resolver.

>The def is for "key Signing key" - a more general definition.

Yup - agreed, but these two need to use the exact same phrase to make sure 
the link is made.  E.g. use "DNSKEY key signing key" instead.

>point across in my opinion.

Forbidding RRSIGs signatures is an operational constraint - this document 
needs to describe what happens if some irrational zone manager actually 
manages to populate their zone with RRSIG RRSIGs.  "MUST be ignored" 
applies both to the name server and the resolver IMHO.  The name server 
probably shouldn't serve the data (but I don't know that that is a 
reasonable restriction), but if it does, the resolver shouldn't validate it 
or cache it.

>found in the child apex and not in the parent's DS set.

Right - but that's the wrong answer I think.  If we don't mandate the set 
of algorithms the resolver has to implement, then its possible that the 
resolver won't be able to resolve  part of the tree if its signed by an 
algorithm the resolver doesn't understand.  Mandating how the tree is 
signed is the wrong answer - because we can't control what people 
do.  Mandating how the resolver works is the right answer.

So:  "Resolvers MUST be able to validate and resolve both RSA and DSA 
signatures.  Signing tools MUST be able to sign using RSA and MAY sign 
using DSA.   Signatures using algorithms unknown by the resolver are 
considered extraneous material and MUST be ignored (e.g. treated as if they 
didn't exist).  Signatures using algorithms known by the resolver, but 
prohibited by configuration of the resolver are also considered extraneous 
material and MUST be ignored."

If we do this, then it doesn't matter who signs what and we move back from 
the realm of trying to control human behavior into the realm of controlling 
protocol behavior.

We still have the problem where we add new algorithms, delete old ones and 
haven't updated the resolvers, but that seems to be a lot less problematic 
than the current language (e.g. its a "lesser included offense"  :-)

>all DNSKEY RRs with both the zone and SEP bits set?

What is a non-zone SEP key?  Yeah, actually I meant all DNSKEY RRs [at the 
apex] with both the zone and SEP bits set.

>some reason in the future.

Correct.  But they get deprecated, before they get dropped.  We will have 
to mention them by name somewhere as mandatory/recommended.