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