Subject: FW: [OPS-DIR] review of draft-ietf-smime-rfc3287bis-07.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 25 May 2009 18:44:52 +0200

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bernard Aboba
	Sent: Monday, May 25, 2009 12:04 AM
	To: [email-masked]
	Subject: [OPS-DIR] review of draft-ietf-smime-rfc3287bis-07.txt

	This is a review of  "Use of Elliptic Curve Cryptography (ECC)
Algorithms 
	in Cryptographic Message Syntax (CMS)"
draft-ietf-smime-3278bis-07.txt for
	operations and management considerations.
	
	draft-ietf-smime-3278bis represents an update to RFC 3278.
Details of the changes 
	from RFC 3278 are provided within Appendix B. 
	
	Aside from clarifications to RFC 3278 and an updated and
enhanced 
	Security Considerations section, which are likely to enhance 
	interoperability and operational security, the most important
	changes include:
	
	    - Abstract: The basis of the document was changed to refer
to NIST 
	       FIPS 186-3 and SP800-56A.  However, to maintain backwards

	       compatibility the Key Derivation Function from ANSI/SEC1
is 
	       retained.  
	
	     - Section 2.1.1: The permitted digest algorithms were
expanded from 
	       SHA-1 to SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. 
	
	     - Section 9: Replaced text, which was a summary paragraph,
with an 
	       updated security considerations section.  Paragraph
referring to 
	       definitions of SHA-224, SHA-256, SHA-384, and SHA-512 is 
	       deleted. ms, 
	
	In terms of support for new algorithms, the document attempts to
bring
	RFC 3278 up to date.  From an operational perspective,
introducing new 
	algorithms is challenging, due to the potential for decreased
performance 
	and interoperability issues, but RFC 3278bis takes care to
preserve 
	backward compatibility. 
	
	From an operational perspective, my major concern would be
whether 
	specification of additional digest algorithms could be expected
once 
	the new NIST digest algorithm is chosen in the not-too-distant
future.  
	While it's hard to fault the authors for not providing guidance
relating to 
	a not-yet-chosen algorithm, much of motivation for deployment of
	algorithms such as SHA-256 relates to a desire to address
weaknesses
	found in SHA-1.  Given that it is possible that NIST will choose
algorithm(s)
	from another family, one wonders whether the additional digest
algorithms
	specified in this document will end up being more than a
temporary
	measure. 

_______________________________________________
OPS-DIR mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ops-dir

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 25 May 2009 11:17:43 -0700

At 6:44 PM +0200 5/25/09, Romascanu, Dan (Dan) wrote:
>From an operational perspective, my major concern would be whether
>specification of additional digest algorithms could be expected once
>the new NIST digest algorithm is chosen in the not-too-distant future.

The date of release of SHA-3 (aka AHS) is unknown. NIST has a roadmap with a timetable in it, but those are goals, not commitments of any sort.

>While it's hard to fault the authors for not providing guidance relating to
>algorithms such as SHA-256 relates to a desire to address weaknesses
>found in SHA-1.  Given that it is possible that NIST will choose algorithm(s)
>from another family, one wonders whether the additional digest algorithms
>specified in this document will end up being more than a temporary
>measure.

That is far from clear. NIST could, for example, choose a hash function that sucks on one axis in exchange for it being provably wonderful on another, and that would have a big effect on whether people would use the new algorithms in different protocols.

Part of the purpose of the hash competition is to increase the crypto community's understanding of hashes in general, not just coming up with a new one. It is quite likely that the outcome of that is a greater understanding of SHA-2, and therefore a greater understanding of its expected lifetime. Right now, all of this is hand-waving.

---

From: Sean Turner <[email-masked]>
Date: Mon, 25 May 2009 17:46:21 -0400

Romascanu, Dan (Dan) wrote:
>  
> 
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]]
>     *On Behalf Of *Bernard Aboba
>     *Sent:* Monday, May 25, 2009 12:04 AM
>     *To:* [email-masked]
>     *Subject:* [OPS-DIR] review of draft-ietf-smime-rfc3287bis-07.txt
> 
>     This is a review of  "Use of Elliptic Curve Cryptography (ECC) Algorithms 
>     in Cryptographic Message Syntax (CMS)" draft-ietf-smime-3278bis-07.txt for
>     draft-ietf-smime-3278bis represents an update to RFC 3278.  Details of the changes 
>     Aside from clarifications to RFC 3278 and an updated and enhanced 
>         - Abstract: The basis of the document was changed to refer to NIST 
>            compatibility the Key Derivation Function from ANSI/SEC1 is 
>            retained.  
> 
>          - Section 2.1.1: The permitted digest algorithms were expanded from 
>          - Section 9: Replaced text, which was a summary paragraph, with an 
>            updated security considerations section.  Paragraph referring to 
>     In terms of support for new algorithms, the document attempts to bring
>     RFC 3278 up to date.  From an operational perspective, introducing new 
>     algorithms is challenging, due to the potential for decreased performance 
>     and interoperability issues, but RFC 3278bis takes care to preserve 
>     backward compatibility. 
> 

Dan,

I tend to agree with what Paul wrote.  I'd only add that the time line 
supplied by NIST (http://csrc.nist.gov/groups/ST/hash/timeline.html) 
suggests that NIST won't actually pick a "winner" until 4th quarter of 
2012.  I'd like to have something at least standardized prior to that.

spt

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 25 May 2009 14:55:22 -0700

> 2012.  I'd like to have something at least standardized prior to that.

OK.  I had been under the impression that NIST deprecation of SHA-1
could occur as soon as 2010.

---

From: Sean Turner <[email-masked]>
Date: Mon, 25 May 2009 18:03:54 -0400

> could occur as soon as 2010.

Oh and that too.

spt