RE: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt

[Daniel Brown <dbrown@xxxxxxxxxxxx>]

Paul,

Regarding your comment 3) below about validation requirements, I suggest that this RFC 3279 update mandate SHA2 as a "SHOULD" (rather than a MUST as it is in the WGLC draft).  

Not making it a MUST avoids making existing implementations non-conformant.  Making it a SHOULD alerts implementers to the security issues and to the NIST compliance/interoperability issues.

Regarding your comment 2) below about key sizes and lifetimes, I suggest this RFC 3279 update make the associated NIST recommendations a SHOULD.  Again, this is for security reasons and better NIST compliance/interoperability issues.  

Generally, the DSA/ECDSA and SHA-1/2 algorithms come from NIST and ANSI, and have some normative security requirements about key sizes.  Completely dropping some of the normative security requirements should require strong justification. 

Best regards,

Dan


-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Paul Hoffman
Sent: Saturday, May 09, 2009 12:51 PM
To: ietf-pkix@xxxxxxx
Subject: Re: WGLC for draft-ietf-pkix-sha2-dsa-ecdsa-06.txt


...

2) Mandating key sizes and lifetimes is inappropriate in this document

RFC 3279 does not mandate key sizes; this draft does. Worse, this draft relies on the tortured logic in NIST SP 800-57 Part 1 that conflates multiple effective key strengths onto a single hash algorithm. The logic that NIST used in making that decision had to do with the difficulty of upgrading a disparate US government infrastructure over a long period of time. That's fine for NIST, but an IETF standard should not make such compromises. It is just wrong to update an existing algorithm RFC by adding a new set of restrictions, but only for some of the algorithms, namely the new ones being added.

The key strength matching and lifetime mandates should be ripped out. It is fine to have a non-normative reference to NIST SP 800-57 Part 1 and NIST SP 800-78-1 in the Security Considerations to help people find the documents.


3) Adding new validation requirements at this late date is wrong

RFC 3279 specified DSA only with SHA-1; this document adds DSA with SHA-2. However, this document now makes all implementations of RFC 3279 that could validate DSA non-conformant. It is wrong to add new algorithms and then punish existing implementations by labelling them non-conformant to a long-established standard.

Following the three guidelines above, the meat of the document is reduced to that below.