The authors of the following draft wanted me to bring their draft to your attention:
http://www.ietf.org/internet-drafts/draft-liao-smimeheaderprotect-00.txt
spt
The IESG has approved the following document: - 'Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type ' <draft-ietf-smime-cms-auth-enveloped-06.txt> as a Proposed Standard This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Tim Polk and Sam Hartman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-auth-enveloped-06.txt Technical Summary This document describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped- data content type. Working Group Summary This document is a product of the smime working group. The document follows the style of RFC 3852 (CMS) in describing a content type and it's fields. It is heavily based on an existing content type (authenticated-data) therefore it is straightforward to understand the fields and their use. The only discussion point on the list was the number and location of the authenticated attributes (authAttrs) field. It was argued that the current document, which has one authAttrs field after the content, is optimized for the aes-gcm/ccm algorithms (see aes-gcm/ ccm draft) and that it would be better to have two locations for the authAttr field. With two fields, efficiencies are afforded to both the current algorithms and yet-to-be-defined algorithms that work "faster/better" with the authAttrs before the content. The counter argument against two fields was complexity. The working group determined one field after the data could adequately support the full range of algorithms based on tests performed by Peter Gutmann. Protocol Quality Tim Polk reviewed this document for the IESG. There are no current implementations, although WG members have expressed interest in implementing this specification. Note to RFC Editor Please make the following changes. In section 3: OLD: accept unsolicited encrypted messages, they become even more vulnerable to unwanted traffic since the present mitigation ^^^ NEW: accept unsolicited encrypted messages, they become even more vulnerable to unwanted traffic since many present mitigation ^^^^ In section 2.2: OLD: the AAD, the IMPLICIT [1] tag in for authAttrs field is not used for ^^^ NEW: the AAD, the IMPLICIT [1] tag in the authAttrs field is not used for ^^^
The IESG has received a request from an individual submitter to consider
the following document:
- 'Additional Diffie-Hellman Groups for use with IETF Standards '
<draft-lepinski-dh-groups-01.txt> as an Informational RFC
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 <at> ietf.org mailing lists by 2007-10-23. Exceptionally,
comments may be sent to iesg <at> ietf.org 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-lepinski-dh-groups-01.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16420&rfc_flag=0
The IESG has received a request from an individual submitter to consider
the following document:
- 'Additional Diffie-Hellman Groups for use with IETF Standards '
<draft-lepinski-dh-groups-01.txt> as an Informational RFC
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 <at> ietf.org mailing lists by 2007-10-23. Exceptionally,
comments may be sent to iesg <at> ietf.org 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-lepinski-dh-groups-01.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16420&rfc_flag=0
The IESG has received a request from an individual submitter to consider
the following document:
- 'Additional Diffie-Hellman Groups for use with IETF Standards '
<draft-lepinski-dh-groups-01.txt> as an Informational RFC
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 <at> ietf.org mailing lists by 2007-10-23. Exceptionally,
comments may be sent to iesg <at> ietf.org 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-lepinski-dh-groups-01.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16420&rfc_flag=0
I asked a developer to take a look, and they are unable to figure out what the problem. More information is needed to confirm. Russ At 11:21 PM 9/25/2007, Peter Gutmann wrote: >-- Snip -- > >From: henrick <at> streamsec.se >Newsgroups: sci.crypt >Subject: Error in RFC 3217 >Date: Wed, 01 Aug 2007 11:54:13 -0700 > >There is an error in the test vectors for RC2 Key Wrap given in RFC >3217. The specification states that RC2 should be used with a 128 bit >key and 128 effective key bits. The test vectors are however generated >using RC2 with a 128 bit key but only 40 effective key bits (which BTW >was the default for MS CryptoAPI prior to Windows XP). > >I don't know if R. Housley is reading these groups, but clearly this >is an error that should be corrected. > >The algorithms specified in RFC 3217 are primarily used for S/MIME. If >you have ever used S/MIME for encrypting email using a certificate >with a DH public key and the RC2-CBC encryption algorithm, chances are >you only got 40 bits of security even if you opted for 128 bit >encryption.
[[ Never hurts to ask the original poster ... ]] At 4:37 PM -0400 10/2/07, Russ Housley wrote: >I asked a developer to take a look, and they are unable to figure >out what the problem. More information is needed to confirm. > >Russ > >At 11:21 PM 9/25/2007, Peter Gutmann wrote: > >>-- Snip -- >> >>From: henrick <at> streamsec.se >>Newsgroups: sci.crypt >>Subject: Error in RFC 3217 >>Date: Wed, 01 Aug 2007 11:54:13 -0700 >> >>There is an error in the test vectors for RC2 Key Wrap given in RFC >>3217. The specification states that RC2 should be used with a 128 bit >>key and 128 effective key bits. The test vectors are however generated >>using RC2 with a 128 bit key but only 40 effective key bits (which BTW >>was the default for MS CryptoAPI prior to Windows XP). >> >>I don't know if R. Housley is reading these groups, but clearly this >>is an error that should be corrected. >> >>The algorithms specified in RFC 3217 are primarily used for S/MIME. If >>you have ever used S/MIME for encrypting email using a certificate >>with a DH public key and the RC2-CBC encryption algorithm, chances are >>you only got 40 bits of security even if you opted for 128 bit >>encryption.
Hi, The problem has two sides. Firstly, RFC 3217 doesn't explicitly say that the test vectors are generated using 40 effective key bits. Without that information the test vectors are not unequivocally specified. You need that piece of information in order to reproduce the values. Secondly, RFC 3217 is now part of S/MIME Charter. This charter also includes RFC 3370 (CMS algorithms) which refers to RFC 3217, but states that RC2 Key Wrap keys MUST be used with 128 effective key bits (parameter value 58). This is a potentially serious documentation bug. Say, for instance, that you are programming against MS CryptoAPI in Windows 2000 or earlier, which had 40 effective key bits as the default for RC2. In such case the test vectors in RFC 3217 *will* check out OK with default settings, and you might be mislead to believe you have implemented RFC 3370 correctly even though you haven't. If the test vectors in RFC 3217 had been generated using 128 effective key bits, or if RFC 3217 had explicitly specified the use of 40 effective key bits, such errors would be a lot more easy to spot during testing and code review. Hope that makes my case clear. P.S. Why doesn't *this* list accept S/MIME signed email? ;) D.S. Paul Hoffman wrote: > [[ Never hurts to ask the original poster ... ]] > > At 4:37 PM -0400 10/2/07, Russ Housley wrote: >> I asked a developer to take a look, and they are unable to figure out >> what the problem. More information is needed to confirm. >> >> Russ >> >> At 11:21 PM 9/25/2007, Peter Gutmann wrote: >> >>> -- Snip -- >>> >>> From: henrick <at> streamsec.se >>> Newsgroups: sci.crypt >>> Subject: Error in RFC 3217 >>> Date: Wed, 01 Aug 2007 11:54:13 -0700 >>> >>> There is an error in the test vectors for RC2 Key Wrap given in RFC >>> 3217. The specification states that RC2 should be used with a 128 bit >>> key and 128 effective key bits. The test vectors are however generated >>> using RC2 with a 128 bit key but only 40 effective key bits (which BTW >>> was the default for MS CryptoAPI prior to Windows XP). >>> >>> I don't know if R. Housley is reading these groups, but clearly this >>> is an error that should be corrected. >>> >>> The algorithms specified in RFC 3217 are primarily used for S/MIME. If >>> you have ever used S/MIME for encrypting email using a certificate >>> with a DH public key and the RC2-CBC encryption algorithm, chances are >>> you only got 40 bits of security even if you opted for 128 bit >>> encryption. > >
At 10:46 AM +0200 10/3/07, Henrick Hellström wrote: >Firstly, RFC 3217 doesn't explicitly say that the test vectors are >generated using 40 effective key bits. Without that information the test >vectors are not unequivocally specified. You need that piece of >information in order to reproduce the values. After reading and re-reading, I do not see how you can say that the test vectors are generated using 40 effective key bits. Where does that show up in the RFC?
Paul Hoffman wrote: > > At 10:46 AM +0200 10/3/07, Henrick Hellström wrote: >> Firstly, RFC 3217 doesn't explicitly say that the test vectors are >> generated using 40 effective key bits. Without that information the test >> vectors are not unequivocally specified. You need that piece of >> information in order to reproduce the values. > > After reading and re-reading, I do not see how you can say that the > test vectors are generated using 40 effective key bits. Where does > that show up in the RFC? It *doesn't* say that in the RFC, which is *exactly* what I am complaining about. I discovered it myself by trial-and-error, and to be honest, it took me a couple of days, because there were a lot of other variables I checked first (such as endianess etc)
RSS Feed9 | |
|---|---|
3 | |
7 | |
1 | |
1 | |
1 | |
2 | |
7 | |
8 | |
5 | |
13 | |
7 | |
7 | |
2 | |
7 | |
11 | |
21 | |
6 | |
11 | |
6 | |
3 | |
9 | |
1 | |
3 | |
8 | |
6 | |
8 | |
31 | |
23 | |
24 | |
10 | |
81 | |
76 | |
19 | |
37 | |
34 | |
27 | |
23 | |
30 | |
79 | |
20 | |
41 | |
24 | |
33 | |
27 | |
33 | |
41 | |
24 | |
30 | |
20 | |
25 | |
34 | |
59 | |
19 | |
13 | |
59 | |
27 | |
24 | |
12 | |
2 | |
3 | |
6 | |
10 | |
21 | |
17 | |
20 | |
1 | |
8 | |
17 | |
17 | |
3 | |
10 | |
6 | |
16 | |
16 | |
3 | |
2 | |
2 | |
30 | |
15 | |
10 | |
9 | |
7 | |
72 | |
20 | |
33 | |
22 | |
23 | |
35 | |
54 | |
9 | |
9 | |
13 | |
13 | |
34 | |
14 | |
74 | |
53 | |
54 | |
34 | |
22 | |
26 | |
22 | |
15 | |
11 | |
9 | |
30 | |
24 | |
38 | |
31 | |
14 | |
36 | |
30 | |
31 | |
29 | |
6 | |
44 | |
14 | |
60 | |
61 | |
78 | |
118 | |
25 | |
29 | |
61 | |
34 | |
38 | |
29 | |
29 | |
68 | |
21 | |
21 | |
52 | |
23 | |
43 | |
65 | |
34 | |
41 | |
40 | |
4 | |
30 | |
64 | |
41 | |
23 | |
45 | |
50 | |
37 | |
44 | |
26 | |
78 | |
113 | |
71 | |
95 | |
113 | |
74 | |
96 | |
55 | |
74 | |
50 | |
155 | |
161 | |
248 | |
233 | |
163 | |
152 | |
306 | |
64 | |
72 | |
17 | |
88 | |
21 | |
53 | |
123 | |
2 | |
2 | |
17 | |
2 |
