[Gen-art] Gen-ART review of draft-delany-domainkeys-base-05.txt
Black_David@emc.com Wed, 19 July 2006 12:37 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3BIT-0007Ha-BX; Wed, 19 Jul 2006 08:37:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3BIR-0007HV-Ku for gen-art@ietf.org; Wed, 19 Jul 2006 08:36:59 -0400
Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3BIQ-0007NR-BH for gen-art@ietf.org; Wed, 19 Jul 2006 08:36:59 -0400
Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6JCavVr008063; Wed, 19 Jul 2006 08:36:58 -0400 (EDT)
Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6JCanoB008019; Wed, 19 Jul 2006 08:36:49 -0400 (EDT)
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <MTK3C61N>; Wed, 19 Jul 2006 08:36:48 -0400
Message-ID: <F222151D3323874393F83102D614E05504E18E42@CORPUSMX20A.corp.emc.com>
From: Black_David@emc.com
To: gen-art@ietf.org, markd+domainkeys@yahoo-inc.com
Date: Wed, 19 Jul 2006 08:36:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.19.51432
X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0'
X-Spam-Score: 0.2 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: housley@vigilsec.com, Black_David@emc.com
Subject: [Gen-art] Gen-ART review of draft-delany-domainkeys-base-05.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Errors-To: gen-art-bounces@ietf.org
I am the assigned Gen-ART reviewer for draft-delany-domainkeys-base-05.txt. For background on Gen-ART, please see the FAQ at <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. This draft is basically ready for publication, but has nits that should be fixed before publication. The draft is generally well written, and contains good explanations of the design rationale, which is important to describe for this sort of document. I found two important issues that really need IESG attention, and a number of less important issues. (1) The IESG should replace the "Purpose of Submission" paragraph on p.2 with a "Purpose of Publication" paragraph explaining: - Why this draft is being published - Why it is being published as Historic - Where implementers should look for specifications that the IESG/IETF recommend for implementation. (2) Some of the public key lengths used are surprisingly short by comparison to current practice in other areas , e.g., 512-bit RSA keys are allowed. The only explanation I see for this is in section 3.2.4, which lists a couple of reasons why larger keys are harder to implement (space and time costs), and then says: o Keys can be replaced on a regular basis, thus their lifetime can be relatively short o The security goals of this specification are modest compared to typical goals of public key systems Both bullets need more explanation that should at least answer: - How and why are the security goals modest? - What are typical goals of public key systems? - Given these, what are reasonable key lifetimes for some of the shorter key lengths. The IESG may want to add a cautionary note specifically warning designers away from the key lengths used in this draft in the absence of careful analysis of level of threat, and the resulting key lifetimes. -- Less important issues Section 3.4.1 should recommend or reference a maximum line length that will avoid issues with long lines. Section 3.4.2.2 - Are "folding white space characters" removed from anywhere in a line, or only at its beginning? The use of "lifetime" in section 3.7 is potentially ambiguous, as there are two factors involved here: - How long a signer continues to use a key. - How long a key record needs to remain in the DNS after the last time it has been used to sign an email. This ought to be clarified - the primary concern in Section 3.7 appears to be the latter. Section 3.7.3 specifies a static policy of always preferring the earliest signature. I can envision mailing list examples, where the signature of the mailing list MTA verifying that this was indeed sent to the mailing list in question is more important than the signature of the sender. This could use some discussion. Section 3.8 - the disconnect between the verifier and the MUA is unfortunate. Removal of the "good" status is a double-edged sword - one thing that could be done here is to have the verifier sign the combination of the verified signature, the good status, and verifier information. The MUA can then validate the verification. This sort of possibility might be useful to discuss as a future opportunity to improve on this disconnect. Section 5.1 on the X.509 header should say something about what (if anything) was implemented. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art