Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sat, 25 Mar 2006 18:46:29 -0500

Hi,

See below at @@@

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Mike StJohns
Sent: Tuesday, March 21, 2006 5:02 PM
To: [email-masked]
Subject: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review

During the DNSEXT meeting today I volunteered to review the above
document with the goal of getting it off the DNSEXT rolls one way or the
other.

My findings:

1) It's currently expired.

@@@ I've submitted a revision that has just the date and version bumped
and the boilerplate nits fixed.

2) It appears to be pretty much the same thing as RFC2535 minus the glue
to actually describe the containing RR.  2535  described DSA in a SIG
record or a KEY record and described algorithm identifiers etc. 
This document describes DSA info as part of a containing RDATA for 
SIG and KEY.   The actual technical crypto grit hasn't changed.

3) There's no section describing these changes or the reasoning for
them.

4) The tools page reports several nits as well as one warning.

I can't support the advancement of this document at this time.  In the
attempt to make it RR agnostic the revisions took away too much
connective tissue.  I don't believe it to be prudent to describe the
RDATA content without describing the specific applicable record (RR)
type(s).

@@@ RFC 4034 describes all of the bits in the DNSKEY and RRSIG RRs (if
that's what you mean by "connective tissue") but not the algorithm
dependent data format. At this point, the DNS DSA key format is usable
in DNSKEY, KEY (to support TKEY), and IPSECKEY (to support IPSEC). The
DNS DSA signature format is usable in RRSIG and SIG (to support SIG(0)).
Things like the "algorithm number" are different in DNSKEY and IPSECKEY.
I believe it is contemplated that there might be additional application
specific key RRs, like IPSECKEY, defined in the future.

If this update expanded the application of these into both the RRSIG and
DNSKEY records (and left them available for SIG and KEY) I'd be much
happier.  If this document obsoleted the use in SIG and KEY and defined
them for RRSIG and DNSKEY I'd be very happy.  If the document also
described the triggering event (e.g. typecode rollover of DNSSEC) I'd be
ecstatic.

@@@ It's probably a good idea to give more background/motivational
material in this document. And it might be a good idea to list the RRs
(with a pointer to the best defining RFC) to which the data format
defined in this document is applicable, as long as it is made clear that
additional RRs may be defined in the future which would reference and
use this format. However, I don't see any reason to obsolete its use in
SIG or KEY since, as far as I know, those still exist to support SIG(0)
and TKEY.

Mike

@@@ Thanks,
@@@ Donald

--
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: Mike StJohns <[email-masked]>
Date: Sat, 25 Mar 2006 20:01:16 -0500

>specific key RRs, like IPSECKEY, defined in the future.

The problem is that you'd actually have to specify the actual way you 
fit this into DNSKEY and RRSIG to be useable.  This document is not 
sufficient to do that without making some possibly ambiguous 
assumptions.  Which means you'd need yet another document to fulfill 
that requirement.  And that makes this document somewhat useless and pointless.

Mike