Key size security considerations

Paul Hoffman <phoffman@imc.org> Sun, 10 August 2008 01:43 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 9B7AB3A6BC4 for <ietfarch-smime-archive@core3.amsl.com>; Sat, 9 Aug 2008 18:43:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.091
X-Spam-Level:
X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_40=-0.185, 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 i7GyvO1Fx7Mm for <ietfarch-smime-archive@core3.amsl.com>; Sat, 9 Aug 2008 18:43:14 -0700 (PDT)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id DA7833A6A99 for <smime-archive@ietf.org>; Sat, 9 Aug 2008 18:43:14 -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 m7A1FEfF009875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Aug 2008 18:15:14 -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 m7A1FEFn009874; Sat, 9 Aug 2008 18:15:14 -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 [165.227.249.203] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7A1FDYf009868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-smime@imc.org>; Sat, 9 Aug 2008 18:15:13 -0700 (MST) (envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p0624081bc4c3ef2526f9@[165.227.249.203]>
In-Reply-To: <p06240813c4bf6bc2ad3e@[10.20.30.152]>
References: <20080701171501.66C9E3A6B99@core3.amsl.com> <01e001c8f0b4$4182f4a0$c488dde0$@com> <p06240800c4bb6ddc408b@[10.20.30.249]> <000701c8f7a9$10d35c40$327a14c0$@com> <p06240813c4bf6bc2ad3e@[10.20.30.152]>
Date: Sat, 09 Aug 2008 18:15:11 -0700
To: ietf-smime@imc.org
From: Paul Hoffman <phoffman@imc.org>
Subject: Key size security considerations
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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>

Earlier, I proposed  a replacement for part of the security 
considerations in 3851bis (S/MIME message). The current text reads:

    Larger keys are not necessarily better keys.  Larger keys take more
    computational resources, and this can quickly become impractical.  In
    fact, support for an excessively large key offers a denial of service
    opportunity if the attacker can cause excessive cryptographic
    processing by providing such a public key.  One mitigation approach
    would require that the corresponding public key certificate be
    validated to a trust anchor prior to use, thus ensuring that only
    trusted public keys are used.  However, some implementations may
    choose to perform signature verification (or key establishment for
    encryption) in parallel with certificate validation, even if
    certificate validation fails.  In such cases, measures should be
    included to limit the impact, for example by limiting cryptographic
    processing time or requiring certificate validation prior to the use
    of large keys.

There is no parallel text in 3850bis.

There has been some good discussion, and I now propose different, 
more general wording that should be included in both documents. This 
would replace the above paragraph in 3851bis and be added to 3850bis.

Sending and receiving agents need to be cautious of CPU usage and 
other resources when handling public keys larger than those mandated 
in this specification (that is, larger than 2048 bits). For example, 
an attacker can send very large, bogus signatures in order to swamp 
the CPU of the receiving party. Another example is that an attacker 
can try to cause a sender to try to encrypt with a very large key. 
One mitigation approach would require that the corresponding public 
key certificate be validated to a trust anchor prior to use, thus 
ensuring that only trusted public keys are used.  However, some 
implementations may choose to perform signature verification (or key 
establishment for encryption) in parallel with certificate 
validation, even if certificate validation fails. Sending and 
receiving parties are advised to have some sort of resource 
management system to prevent such attacks.