RE: Last Call: draft-ietf-smime-sha2 (Using SHA2 Algorithms withCryptographic Message Syntax) to Proposed Standard
At 4:06 PM -0500 2/29/08, Turner, Sean P. wrote: > >In addition, it is not acceptable to reference in the >>*normative* references "work in progess", i.e.[ECCADD]. > >I'm pretty sure this is done all the time. There are 17 IDs in the RFC >editor queue with works-in-progress in normative references. Sean is correct. This will cause the draft to be stuck in the RFC Editor publication queue until the other document becomes an RFC, but there is absolutely nothing wrong with this in a last-call draft. > >The same applies for [SHS]. The text states: >> >>NOTE [to be removed upon publication as an RFC]: NIST has not yet >>finalized FIPS 186-3 and there is a chance that the draft may be >>changed. This may result in differences between what is documented >>in the current version of this document and what is in the >>FIPS. It >>is intended to synchronize the final version of this draft with the >>FIPS before publication as an RFC. > >The FIPS PUB 186-3 part that this ID needs has very little chance of >changing. The WG wanted this note to be safe. Again, Sean is right. It is quite common to have comments like "This section to be removed upon publication" in documents going into the RFC Editor queue. > >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. > >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. > >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. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-smime-sha2 (Using SHA2 Algorithms withCryptographic Message Syntax) to Proposed Standard
Denis, Thanks for taking the time to review this ID. Responses are inline. spt >-Original Message- > >There are obvious errors (intentionnaly left by the editor in >order to know how many people read the document). If I was going to leave something intentionally in the document to see if you'd read it, then it would have been a lot better ... something like (note this isn't an actual offer) "if you mention this sentence to me I'll buy you a beer". This ID is way too short to sneak in this kind of phrase. >On page 1: > >The message digest algorithms are defined in and [SHS]. > ^^^ Also in section 2.4: Will remove the "and". >2.4. SHA-512 > > The SHA-256 message digest algorithm is defined in [SHS]. > >whereas it should be: > >2.4. SHA-512 > > The SHA-512 message digest algorithm is defined in [SHS]. Will replace SHA-256 with SHA-512 in 2.4. >It would be valuable to explain why DSA cannot be used with >SHA-384 and SHA-512. I'll add some text. >In addition, it is not acceptable to reference in the >*normative* references "work in progess", i.e.[ECCADD]. I'm pretty sure this is done all the time. There are 17 IDs in the RFC editor queue with works-in-progress in normative references. >The same applies for [SHS]. The text states: > > NOTE [to be removed upon publication as an RFC]: NIST has not yet > finalized FIPS 186-3 and there is a chance that the draft may be > changed. This may result in differences between what is documented > in the current version of this document and what is in the >FIPS. It > is intended to synchronize the final version of this draft with the > FIPS before publication as an RFC. The FIPS PUB 186-3 part that this ID needs has very little chance of changing. The WG wanted this note to be safe. >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. >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). >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. >The NESSIE program has evaluated with succces the WHIRLPOOL algorithm. >WHIRLPOOL would be a good substitute to SHA-512 and I would >encourage that "someone" drafts an RFC to specify OIDs for >using WHIRLPOOL with CMS. > >Denis > >>The IESG has received a request from the S/MIME Mail Security WG >>(smime) to consider the following document: >> >>- 'Using SHA2 Algorithms with Cryptographic Message Syntax ' >>as a Proposed Standard >> >>The IESG plans to make a decision in the next few weeks, and solicits >>final comments on this action. Please send substantive >comments to the >>ietf@ietf.org mailing lists by 2008-03-07. Exceptionally, >comments may >>be sent to [EMAIL PROTECTED] instead. In either case, please retain the >>beginning of the Subject line to allow automated sorting. >> >>The file can be obtained via >>http://www.ietf.org/internet-drafts/draft-ietf-smime-sha2-03.txt >> >> >>IESG discussion can be tracked via >>https://datatracker.ietf.org/public/pidtracker.cgi?command=vie w_id&dTag >>=16033&rfc_flag=0 >> >> > >Regards, > >Denis Pinkas > > > ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-smime-sha2 (Using SHA2 Algorithms withCryptographic Message Syntax) to Proposed Standard
There are obvious errors (intentionnaly left by the editor in order to know how many people read the document). On page 1: The message digest algorithms are defined in and [SHS]. ^^^ Also in section 2.4: 2.4. SHA-512 The SHA-256 message digest algorithm is defined in [SHS]. whereas it should be: 2.4. SHA-512 The SHA-512 message digest algorithm is defined in [SHS]. It would be valuable to explain why DSA cannot be used with SHA-384 and SHA-512. In addition, it is not acceptable to reference in the *normative* references "work in progess", i.e.[ECCADD]. The same applies for [SHS]. The text states: NOTE [to be removed upon publication as an RFC]: NIST has not yet finalized FIPS 186-3 and there is a chance that the draft may be changed. This may result in differences between what is documented in the current version of this document and what is in the FIPS. It is intended to synchronize the final version of this draft with the FIPS before publication as an RFC. 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]. 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. 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. The NESSIE program has evaluated with succces the WHIRLPOOL algorithm. WHIRLPOOL would be a good substitute to SHA-512 and I would encourage that "someone" drafts an RFC to specify OIDs for using WHIRLPOOL with CMS. Denis >The IESG has received a request from the S/MIME Mail Security WG (smime) >to consider the following document: > >- 'Using SHA2 Algorithms with Cryptographic Message Syntax ' >as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2008-03-07. Exceptionally, >comments may be sent to [EMAIL PROTECTED] instead. In either case, please >retain the beginning of the Subject line to allow automated sorting. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-smime-sha2-03.txt > > >IESG discussion can be tracked via >https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16033&rfc_flag=0 > > Regards, Denis Pinkas ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
