Subject: RE: Last Call: draft-ietf-smime-3851bis (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification) to Proposed Standard

From: "Turner, Sean P." <[email-masked]>
Date: Thu, 13 Nov 2008 13:05:02 -0500

One thing I noted is that to ensure interoperability of the SHOULD- for the
DH ephemeral-static requirement we need to pick a MUST key wrap algorithm
(note that E-S DH was a SHOULD in RFC 3851 but RFC 3851 did not include
requirements for a key wrap algorithm).  The text should not only indicate
which key wrap algorithms to use but what kind of content encryption keys
the algorithm is "good" for.  I suggest adding the following text to Section
2.3 right after the bullets (all of the references were already normative
references):

When DH ephemeral-static is used, a key wrap algorithm is also specified in
the KeyEncryptionAlgorithmIdentifier [CMS].  When DH ephemeral-static is
used with an AES content encryption algorithm (see Section 2.7), the key
wrap algorithm MUST be an AES key wrap algorithm from [CMSAES].  When DH
ephemeral-static is used with the Triple DES content encryption algorithm
(see Section 2.7), the key wrap algorithm MUST be either Triple DES key wrap
from [CMSALG] or one of the AES key wraps from [CMSAES].  The strength of
the key wrap algorithm MUST be as strong as the content encryption
algorithm:

- The Triple-DES key wrap algorithm can be used with the Triple-DES content
  encryption algorithm,
- The AES 128 key wrap algorithm can be used with The Triple-DES and AES 128
  content encryption algorithms,
- The AES 192 key wrap algorithm can be used with The Triple-DES, AES 128,
  and AES 192 content encryption algorithms,
- The AES 256 key wrap algorithm can be used with The Triple-DES, AES 128,
  AES 192, and AES 256 content encryption algorithms. 

spt 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of The IESG
>Sent: Thursday, October 30, 2008 12:42 PM
>To: IETF-Announce
>Cc: [email-masked]
>Subject: Last Call: draft-ietf-smime-3851bis 
>(Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 
>3.2 Message Specification) to Proposed Standard 
>
>The IESG has received a request from the S/MIME Mail Security 
>WG (smime) to consider the following document:
>
>- 'Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 
>   Message Specification '
>   <draft-ietf-smime-3851bis-08.txt> as a Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and 
>solicits final comments on this action.
>
>In particular, the IESG solicits comments on the cryptographic 
>strength requirements specified in section 4.1 through 4.5, 
>and the following statement from Section 6, Security Considerations:
>
>   "Today, 512-bit RSA, DSA and DH keys are considered by many experts
>   to be cryptographically insecure."
>
>These sections allow the continued use of RSA, DSA, and DH key 
>lengths between 512 and 1024 bits.  Given that other 
>organizations are moving to a minimum key length of 2048 bits, 
>the IESG wishes to verify IETF consensus for the cryptographic 
>minimums in this document.
>
>Please send substantive comments to the
>[email-masked] mailing lists by 2008-11-13. Exceptionally, 
>comments may be sent to [email-masked] 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-3851bis-08.txt
>
>
>IESG discussion can be tracked via
>https://datatracker.ietf.org/public/pidtracker.cgi?command=view
>_id&dTag=16577&rfc_flag=0
>
>_______________________________________________
>IETF-Announce mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 13 Nov 2008 12:45:46 -0800

>  AES 192, and AES 256 content encryption algorithms.

Wouldn't it be much simpler to say that the key wrap algorithm must be the same as the content encryption algorithm? Yes, one *might* want a keywrap of greater strength as you have above, but that forces implementations to have tables of what "greater" means. Saying they need to be the same is much more straight forward.

---

From: Russ Housley <[email-masked]>
Date: Thu, 13 Nov 2008 16:00:37 -0500

>Wouldn't it be much simpler to say that the key wrap algorithm must 
>be the same as the content encryption algorithm? Yes, one *might* 
>want a keywrap of greater strength as you have above, but that 
>forces implementations to have tables of what "greater" means. 
>Saying they need to be the same is much more straight forward.

The keysize could be the same, but the mode will probably be 
different.  One would not want to use AES Key Wrap for the content.

Russ

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 13 Nov 2008 13:11:34 -0800

At 4:00 PM -0500 11/13/08, Russ Housley wrote:
>The keysize could be the same, but the mode will probably be different.  One would not want to use AES Key Wrap for the content.

Sorry, of course. I meant "same underlying encryption function", not "same algorithm".

---

From: "Turner, Sean P." <[email-masked]>
Date: Thu, 13 Nov 2008 16:52:39 -0500

>From: Paul Hoffman [mailto:[email-masked]] 
>Sent: Thursday, November 13, 2008 4:12 PM
>To: Russ Housley; Turner, Sean P.; [email-masked]; [email-masked]
>Subject: RE: Last Call: draft-ietf-smime-3851bis 
>>>Wouldn't it be much simpler to say that the key wrap 
>algorithm must be the same as the content encryption 
>algorithm? Yes, one *might* want a keywrap of greater strength 
>as you have above, but that forces implementations to have 
>tables of what "greater" means. Saying they need to be the 
>same is much more straight forward.
>>

Paul,

Yes, it would be simpler.

When DH ephemeral-static is used, a key wrap algorithm is also specified in
the KeyEncryptionAlgorithmIdentifier [CMS].  The underlying encryption
functions for the key wrap and content encryption algorithms ([CMSALG] and
[CMSAES]) and the key sizes for the two algorithms MUST be the same (e.g.,
AES 128 key wrap algorithm with AES 128 content encryption algorithm). As
AES 128 CBC is the mandatory to implement content encryption algorithm thus,
when DH ephemeral-static is supported, AES-128 key wrap algorithm MUST also
be supported.

spt

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 14 Nov 2008 12:36:07 +0100

Hi

Would it be possible to add a comment concerning the multipart/signed 
creation
or better some section mulipart/signed parsing that a system should nicely
treat a multipart/signed message that has more than two parts.

It may be not the right doc, probably better in CMS.

it happens that some firewalls add "disclaimers" as an additional body-part
as soon as they see that the top level mime is multipart/*

At least one well known user agent refuses to show such messages.

TIA for consideration.
Peter Sylvester