RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt

"Tony Capel" <capel@comgate.com> Fri, 08 August 2008 22:07 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 B41A83A6D25 for <ietfarch-smime-archive@core3.amsl.com>; Fri, 8 Aug 2008 15:07:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.461
X-Spam-Level:
X-Spam-Status: No, score=0.461 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, HELO_MISMATCH_COM=0.553]
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 Yc4h6Dj9zjn2 for <ietfarch-smime-archive@core3.amsl.com>; Fri, 8 Aug 2008 15:07:25 -0700 (PDT)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id C310D3A6CFE for <smime-archive@ietf.org>; Fri, 8 Aug 2008 15:07:25 -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 m78LpH0f017730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2008 14:51:17 -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 m78LpHZi017726; Fri, 8 Aug 2008 14:51:17 -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 mail-06.primus.ca (smtp-noauth4.primus.ca [216.254.180.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78LpGgp017715; Fri, 8 Aug 2008 14:51:16 -0700 (MST) (envelope-from capel@comgate.com)
Received: from ottawa-hs-209-217-122-183.s-ip.magma.ca ([209.217.122.183] helo=tony) by mail-06.primus.ca with esmtps (TLSv1:RC4-MD5:128) (Exim 4.63) (envelope-from <capel@comgate.com>) id 1KRZre-0005Yl-0l; Fri, 08 Aug 2008 17:51:14 -0400
From: Tony Capel <capel@comgate.com>
To: "'Turner, Sean P.'" <turners@ieca.com>, 'Paul Hoffman' <phoffman@imc.org>, 'Jim Schaad' <ietf@augustcellars.com>, 'Blake Ramsdell' <blaker@gmail.com>
Cc: ietf-smime@imc.org
Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
Date: Fri, 08 Aug 2008 17:51:11 -0400
Message-ID: <5D5FA15E749D429F9A1C68DFD6ABE55F@tony>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6838
In-Reply-To: <ECEBE14254684D9FB540EEC36B08E8B5@Wylie>
Importance: Normal
Thread-Index: Acj44BPhN82v+KlSRx69J/t9CEPPcAAsV3AQAAHOOUA=
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512
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>

My problems with the proposed text are:

1) I would prefer the security consideration apply to encryption as well as
signature checking.  Although less likely, it could be a sending agent who uses
an intended receiver's unvalidated encryption certificate to get the "big" key.
I would not want the text to imply that this is ONLY a receiver signature issue.
We should probably not make assumptions about how the certificates are
distributed and we need to address dual keypair use (the signing certificate
could be ok, but the encryption cert could be bad - a "time-bomb"?).  I agree
that implementers have more options to address the encryption case (not
beginning encryption until cert validation is done) but many implementers allow
encryption certificates to be manually marked as "trusted" - and it is not clear
that everyone only starts the encryption operations after successful cert
validation.  So my preference is to be generic: "be careful about using big keys
from unvalidated end user certs to validate signatures or encrypt".

2) The swamping is specifically related to the crypto element not necessarily
the CPU (i.e. it may be the h/w token that is swamped).


As per my post earlier today to the 3850bis list, the CERT security
considerations may be a bit more complex so having a separate discussion there
might be a good idea.

Tony

| -----Original Message-----
| From: owner-ietf-smime@mail.imc.org 
| [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Turner, Sean P.
| Sent: August 8, 2008 4:09 PM
| To: 'Paul Hoffman'; 'Jim Schaad'; 'Blake Ramsdell'
| Cc: ietf-smime@imc.org
| Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
| 
| 
| 
| >-----Original Message-----
| >From: Paul Hoffman [mailto:phoffman@imc.org]
| >Sent: Thursday, August 07, 2008 6:51 PM
| >To: Turner, Sean P.; 'Jim Schaad'; 'Blake Ramsdell'
| >Cc: ietf-smime@imc.org
| >Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
| >
| >At 1:42 PM -0400 8/7/08, Turner, Sean P. wrote:
| >>  >Proposed wording:
| >>>
| >>>Receiving agents that validate signatures need to be 
| cautious of CPU
| >>>usage when validating signatures larger than those 
| mandated in this 
| >>>specification. An attacker can send very large, bogus 
| signatures in 
| >>>order to swamp the CPU of the receiving party. Receiving 
| >parties that
| >>>verify large signatures are advised to have some sort of resource
| >>>management system to prevent such an attack.
| >>
| >>Is this in addition to or to replace the para that starts
| >"Larger keys
| >>are not" in 3851bis Sec 5?
| >
| >Replace.
| 
| I'm happy with replace, as long as we move the certificate 
| path validation stuff to [CERT].  Russ, Steve, and Tony all 
| suggested something about making sure the keys are validated 
| prior to use.
| 
| spt
|