ietf
[Top] [All Lists]

RE: Last Call: draft-ietf-smime-sha2 (Using SHA2 AlgorithmswithCryptographic Message Syntax) to Proposed Standard

2008-03-03 08:23:17

Denis,

Responses are in-line.

spt 

-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org 
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Denis 
Pinkas
Sent: Monday, March 03, 2008 9:06 AM
To: Paul Hoffman; Turner, Sean P.; ietf(_at_)ietf(_dot_)org
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: Last Call: draft-ietf-smime-sha2 (Using SHA2 
AlgorithmswithCryptographic Message Syntax) to Proposed Standard


Responses are in-line.

(...)

There is a more substantive comment on the first paragraph 
of section 
1.

The text states:

   If an implementation chooses to support one of the algorithms
   discussed in this document, then the implementation 
MUST do so as
   described in this document.

I believe the text should be:

   If an implementation chooses to support one of the algorithms
   discussed in this document, then the implementation 
MUST do so as
   described in [SHS].

The algorithms aren't defined in this document only the OIDs 
and where 
they go in CMS ... so I still think it's actually "as described in 
this document". But, Spencer suggests removing the sentences because 
they're not needed and I tend to agree with him.

Spencer wins on this one. The sentence doesn't make much sense in a 
standards-track document.

It is important to know in which document the algorithms are 
described in detail.
Deleting the sentence would not solve my concern.

The 2nd sentence in the Intro says (or will say after I delete the and):
"The message digest algorithms are defined in [SHS]."  The 1st sentence in 3
references the DSS, X9.62, and RFC2313 for DSA, ECDSA, and RSA (we're moving
the references to 1st sentence of 2nd para. I think we're covered.

 >A small discussion in the security considerations section on
the advantages (in particular in terms of performances versus
security) of using one or another function from the SHA2 
family would 
be helpful.

I'll see if I can't get something from NIST (or at least 
point to it).

I'll disagree with this. These are not security considerations; they 
are performance considerations. And pretty obvious ones at that.

It is both performance and security. 
The larger the hash is, the better is the security, but the 
performance may be lower.

I don't really have a problem adding this sentence.

 >While I welcome this draft, everybody should take into
consideration that, if the SHA2 family happens to be broken then we 
will be at risk.
This should be mentioned into the security considerations section.

If an algorithm is cracked then isn't it obvious that we're in 
trouble?  No other algorithm document I could find says 
something like 
this so I'm inclined to not include this in the security 
considerations section.

... or anywhere else. If any algorithm (hash, encryption, signing,
...) is broken, it is broken. Sean's right here.

The message is the following: if the SHA2 family is broken, 
then you had better to use two hash algorithms from a 
different family (e.g. use Whirlpool).

We should also reference 
http://www.ietf.org/internet-drafts/draft-ietf-smime-multisig-04.txt
which allows to use two different hash functions (from 
different families, if possible).

I'm not sure we need to add this reference. 

Denis