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

From: "Denis Pinkas" <[email-masked]>
Date: Mon, 3 Mar 2008 15:06:29 +0100

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.

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

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

Denis

_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Turner, Sean P." <[email-masked]>
Date: Mon, 3 Mar 2008 09:52:22 -0500

Denis,

Responses are in-line.

spt 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Denis Pinkas
>Sent: Monday, March 03, 2008 9:06 AM
>To: Paul Hoffman; Turner, Sean P.; [email-masked]
>Cc: [email-masked]
>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:
>>>>
>>>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.
>>

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.

>family would 
>>>>be helpful.

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

>>>>consideration that, if the SHA2 family happens to be broken then we 
>>>>will be at risk.
>>>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.
>>
>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

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 3 Mar 2008 07:44:00 -0800

>to use two hash algorithms from a different family (e.g. use Whirlpool).

There is no consensus in the IETF that this statement is true. We 
have discussed it many times for many years. Adding such a sentence 
to this document without community agreement is wrong.

>which allows to use two different hash functions (from different 

That's also inappropriate, given that this document covers many uses 
of SHA2 that are not related to multisig.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 04 Mar 2008 08:56:18 -0800

At Mon, 3 Mar 2008 07:44:00 -0800,
> to this document without community agreement is wrong.

I agree with Paul that there is no consensus here.

-Ekr