RE: draft-ietf-dnsext-rfc2539bis-dhk-06.txt

["Eastlake III Donald-LDE008" <[e-mail]>]

Hi,
 
See below at @@@

________________________________

From: [e-mail]
[mailto:[e-mail]] On Behalf Of Mike StJohns
Sent: Tuesday, March 21, 2006 5:25 PM
To: [e-mail]
Subject: draft-ietf-dnsext-rfc2539bis-dhk-06.txt


As part of the DNSEXT meeting I agreed to review the above document with
a view to getting it off of the chair's list.  It has passed WGLC, but
hasn't had sufficient reviewers for AD comfort.

1) The document is currently expired. 
 
@@@ As with the 2536bis draft, an update has been submitted with just
the version and date bumped and the boilerplate nits fixed.

2) The document appears to substantially share text with RFC2539 with
the exception that the specific reference to how to incorporate DH data
with a KEY record has been replaced with "
within the RDATA portion
of a RR". 

@@@ In addition, one more abbreviation for a standard Diffie-Hellman
group has been included. Also, as per my 12/27/2005 posting to
namedroppers, there are yet two more additional standard DH groups
defined in RFC 3526 (in connection with IPsec), for which DNS DH key
format abbreviations should be defined and, to avoid duplication and
possible inconsistency, the details of these standard DH groups should
be omitted and RFC 3526 referenced.
 
 3) The document includes text about a "work in progress" that was a
work in progress back when 2539 
 was published.  That either needs to be removed or cited. 
 
@@@ This is just in the acknowledgements section, since some of the
material in this draft was duplicated from another Internet-Draft which
was long ago abandoned and has expired. I suppose I could change the
acknowledgements to be less informative by removing that reference while
leaving in the names of the  people being acknowledged. 

4) There are several nits and warnings on the existing draft (e.g. old
boilerplate)

For at least some of the same reasons as I cited in for the DSA draft, I
can't support advancement of this draft.  E.g. there isn't enough
connective tissue between this document and RFC4034 which specifies the
various record formats.  To be adequate for publication, this document
should explicitly cite DNSKEY as the record reference and completely
specify the part of the RDATA for the DNSKEY to which this applies.
Also, the algorithm information identifier from 2535 should be added to
this document.

@@@ The format in this document is usable in both DNSKEY and KEY (to
support TKEY). It is probably a good idea to list the RR types in which
it is used and cite their best RFC definition. I'm also fine with giving
the motivations for this revision. But all the bits outside of the DH
key format defined in this document are defined in other documents, like
RFC 4034. While the same algorithm number is used in DNSKEY and KEY, it
is the case that as shown by the IPSECKEY RR, it is quite possible that
in the future application specific RRs might be defined which would want
to reference this DH data format but use different algorithm numbers or
identifiers. So, if the algorithm number is included in this document,
it needs to be clear that the "DH" algorithm might be otherwise
identified in future defined RRs.

Also, the "
PublicValue is the binary representation of
the DH public value with most significant byte first." statement
needs to clearly identify this is a positive integer (ditto for prime)
with no leading zero octets or some such. - This is necessary to ensure
implementers don't accidentally just plug the number into the
"BigInteger" function and end up with negative numbers of some
sort.  In other words, the binary representative as stated is
ambiguous.

@@@ OK. This would be a good change to make.

Mike

@@@ Thanks,
@@@ Donald

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>