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

Mike StJohns <Mike.StJohns@nominum.com> Tue, 21 March 2006 22:26 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpIs-0001Ie-1W for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 17:26:14 -0500
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLpIr-00073w-LF for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 17:26:14 -0500
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1FLpG8-000D46-E7 for namedroppers-data@psg.com; Tue, 21 Mar 2006 22:23:24 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,HTML_10_20, HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.0
Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from <Mike.StJohns@nominum.com>) id 1FLpG7-000D3t-Q5 for namedroppers@ops.ietf.org; Tue, 21 Mar 2006 22:23:23 +0000
Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 2636D56848 for <namedroppers@ops.ietf.org>; Tue, 21 Mar 2006 14:23:23 -0800 (PST) (envelope-from Mike.StJohns@nominum.com)
Message-Id: <7.0.1.0.2.20060321170911.03c2f898@nominum.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Tue, 21 Mar 2006 17:24:50 -0500
To: namedroppers@ops.ietf.org
From: Mike StJohns <Mike.StJohns@nominum.com>
Subject: draft-ietf-dnsext-rfc2539bis-dhk-06.txt
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_153480983==.ALT"
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30

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.

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

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.

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.

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.

Mike