RE: WG Last Call: draft-ietf-smime-rfc3851bis-05.txt

"Turner, Sean P." <turners@ieca.com> Wed, 17 September 2008 19:59 UTC

Return-Path: <owner-ietf-smime@mail.imc.org>
X-Original-To: ietfarch-smime-archive@core3.amsl.com
Delivered-To: ietfarch-smime-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FAA33A6814 for <ietfarch-smime-archive@core3.amsl.com>; Wed, 17 Sep 2008 12:59:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpyCiXPT4Mw6 for <ietfarch-smime-archive@core3.amsl.com>; Wed, 17 Sep 2008 12:59:21 -0700 (PDT)
Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 08CFA3A683D for <smime-archive@ietf.org>; Wed, 17 Sep 2008 12:59:19 -0700 (PDT)
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8HJfX1m080533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Sep 2008 12:41:33 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8HJfXXQ080532; Wed, 17 Sep 2008 12:41:33 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from smtp100.biz.mail.re2.yahoo.com (smtp100.biz.mail.re2.yahoo.com [206.190.52.46]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8HJfLr0080510 for <ietf-smime@imc.org>; Wed, 17 Sep 2008 12:41:32 -0700 (MST) (envelope-from turners@ieca.com)
Received: (qmail 66751 invoked from network); 17 Sep 2008 19:41:21 -0000
Received: from unknown (HELO Wylie) (turners@ieca.com@71.191.0.27 with login) by smtp100.biz.mail.re2.yahoo.com with SMTP; 17 Sep 2008 19:41:20 -0000
X-YMail-OSG: NWnRwRQVM1mg4s8dCl16ogAJ1LXZIKNvQq2nFcGy_UP0LNDVsPdojd9VTwhd9JWJ0dXT9gFUn1tj8DiYfUtCI1H9JzGhjUmbDsExYWdlkyhQPkAWK7BVs01rN182pIzSb6Bk4NLoBSPNSzQ1k1dwHX5rqNDxIls6o.l2S9WYtuoekPNToLUnFOd2pZO58A--
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <turners@ieca.com>
To: "'Turner, Sean P.'" <turners@ieca.com>, 'Russ Housley' <housley@vigilsec.com>, ietf-smime@imc.org
References: <200809091358.m89DwKYh076619@balder-227.proper.com> <95464D8597D34F2C998097DB59FA9295@Wylie>
Subject: RE: WG Last Call: draft-ietf-smime-rfc3851bis-05.txt
Date: Wed, 17 Sep 2008 15:41:17 -0400
Organization: IECA, Inc.
Message-ID: <C2E17EF228214231BEC512B98858B813@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AckSh9nBjDRAM8o5TvSIAk/hOc8StgAdS+qwAX/haCA=
In-Reply-To: <95464D8597D34F2C998097DB59FA9295@Wylie>
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

It's been pointed out that we explain why the RSA and DSA key sizes are
different in draft-ietf-smime-rfc3851bis and not in
draft-ietf-smime-rfc3850bis (i.e., the standard isn't yet defined).  To
address this we should replace the suggested draft-ietf-smime-rfc3850bis
security paragraph as follows (add three new sentences to the end):

The 4096-bit RSA key size requirement for certificate and CRL verification
is larger than the 2048-bit RSA key sizes for message signature
generation/verification or message encryption/decryption in [SMIME-MSG]
because many Root CAs included in certificate stores have already issued
Root certificates with 4096-bit key.  The standard that defines comparable
key sizes for DSA is not yet available.  In particular, [FIPS186-3] only
defines DSA key sizes up to 1024 bits.  A revision to support larger key
sizes is being developed, and once it is available, implementors ought to
support DSA key sizes comparable to the RSA key sizes recommended in this
specification.

spt

>-----Original Message-----
>From: owner-ietf-smime@mail.imc.org 
>[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Turner, Sean P.
>Sent: Monday, September 15, 2008 6:22 PM
>To: 'Russ Housley'; ietf-smime@imc.org
>Subject: RE: WG Last Call: draft-ietf-smime-rfc3851bis-05.txt
>
>
>More than one person has asked about the different key sizes 
>in draft-ietf-smime-3850bis and draft-ietf-smime-3851bis.  To 
>save people searching through the archives, we should add some 
>text to the security considerations to address the following 
>two issues: 1) Why don't the DSA and RSA key sizes match up in 
>terms of security strength and 2) Why is 4096 bits the upper 
>bound in draft-ietf-smime-3850bis (CERT) while the upper 
>bounds in in draft-ietf-smime-3851bis (MSG) is 2048.
>
>1) The reason for the DSA key size recommendations not being 
>the same as RSA key size recommendations is that FIPS 186-3 
>only defines key sizes up to 1024.  With no 
>informative/normative reference for us to point to we can't 
>suggest DSA key sizes greater that 1024.  So in 
>draft-ietf-smime-3851bis, I suggest the following change be 
>made to say that when NIST does publish something implementers 
>ought to support the larger key sizes:
>
>Old:
>
>The choice of 2048 bits as the RSA asymmetric key size in this 
>specification is based on the desire to provide 100 bits of 
>security.  The choice of 1024 bits as the DSA, and DH 
>asymmetric key size in this specification is based on the 
>desire to provide 80 bits of security.  These key size seems 
>prudent for the Internet based on Section 4.3 of [STRENGTH].  
>There are other environments (e.g., government, financial, and 
>medical) that may consider this key size to be inadequate.  
>Likewise, there are other environments that may consider this 
>key size to be excessive.
>
>New:
>
>The choice of 2048 bits as the RSA asymmetric key size in this 
>specification is based on the desire to provide 100 bits of 
>security.  The standards to offer the same level of security 
>for DSA and DH are not yet available.  In particular, 
>[FIPS186-3] only defines DSA key sizes up to 1024 bits.  A 
>revision to support larger key sizes is being developed, and 
>once it is available, implementors ought to support DSA key 
>sizes comparable to the RSA key sizes recommended in this 
>specification.  The key sizes that must be supported to 
>conform to this specification seem appropriate for the 
>Internet based on [STRENGTH].  Of course, there are 
>environments, such as financial and medical system, that may 
>select different key sizes.  For this reason, an 
>implementation MAY support key sizes beyond those recommended 
>in this specification.
>
>2) With respect to the 4096 in draft-ietf-smime-rfc3850bis and 
>2048 in draft-ietf-smime-rfc3851bis, the discussion went 
>something like this: a) draft-ietf-smime-3850bis only 
>addresses certificate/CRL validation while 
>draft-ietf-smime-rfc3851bis addresses signature 
>generation/verification and encryption/decryption b) 4096 
>certificates are already in the Mozilla and MS cert store.  To 
>make sure people understand the difference in 
>draft-ietf-smime-rfc3850bis, I suggest adding the following to 
>its security
>considerations:
>
>The 4096-bit RSA key size requirement for certificate and CRL 
>verification is larger than the 2048-bit RSA key sizes for 
>message signature generation/verification or message 
>encryption/decryption in 
>[SMIME-MSG:draft-ietf-smime-rfc3851bis] because multiple 
>certificate stores already include Root certificates with 
>4096-bit keys.
>
>spt
>
>>-----Original Message-----
>>
>>Passing on some WG Last Call comments.
>>
>>Russ
>>
>>= = = = = = = = =
>>
>>1) Section 1.6: Section 1.2 should be 1.3 (conventions section).  Sec
>>1.3: Added references ... should be
>>Sect 1.4: Added references...
>
>Fixed.
>
>>2) Inconsistency: DSA with SHA-256 is a MUST in Section 1.6 and
>>SHOULD+ in section 2.2.  3250-bis and 3251-bis should be consistent
>>for DSA with SHA-256.
>
>DSA with SHA-256 should be SHOULD+ everywhere.
>
>>3) section 1.6 mentions Sec 2.5.2.1 (there is no 2.5.2.1)
>
>2.5.2.1 just talked about RC2 so I deleted it entirely.  I'll 
>split the bullet in two:
>
>Sec 2.5.2.1: Deleted entire section (discussed deprecated RC2).
>Sec 2.7, 2.7.1, Appendix A: references to RC2/40 removed.
>
>>4) Section 1.6 referencing Sec 2.5.2:  "DES-3EDE-CBC" and 
>"AES-128 CBC" 
>>should be "DES-3EDE-CBC" with "AES-128 CBC"
>
>Fixed
>
>>5) Section 1.6 referencing Sec 7: update should be updated
>
>Fixed
>
>>6) I believe that Denis pointed this out already but there is a 
>>contradiction in key sizes for RSA signatures between 3850bis and 
>>3851bis.
>
>See above.
>
>>7) Error in reference [SMIMEv2] in both 3850bis and 3851bis;
>>PKCS#7 is RFC 2315.
>
>Fixed
>