Re: [secdir] Secdir review of draft-ietf-dcrup-dkim-usage-04

Russ Housley <> Wed, 13 September 2017 03:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1533113352B for <>; Tue, 12 Sep 2017 20:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uBI1v5Gu3s_C for <>; Tue, 12 Sep 2017 20:11:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F91313292F for <>; Tue, 12 Sep 2017 20:11:24 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C7C9D3005A8 for <>; Tue, 12 Sep 2017 23:11:23 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id pV9JAwS3UeLB for <>; Tue, 12 Sep 2017 23:11:20 -0400 (EDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 6384D300277; Tue, 12 Sep 2017 23:11:19 -0400 (EDT)
From: Russ Housley <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_65E67875-CB5F-4FAE-B739-0CDCE1AB61B1"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 12 Sep 2017 23:11:22 -0400
In-Reply-To: <>
Cc: IETF SecDir <>,
To: Magnus Nystrom <>
References: <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [secdir] Secdir review of draft-ietf-dcrup-dkim-usage-04
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Sep 2017 03:11:26 -0000


I agree with your recommendation, but I would like to make sure I understand your suggestion.  The document says:

   ...  Since short RSA keys more easily succumb to
   off-line attacks, Signers MUST use RSA keys of at least 1024 bits for
   all keys.  Signers SHOULD use RSA keys of at least 2048 bits. ...

You want to change "1024" to "2048", and then drop the following sentence, right?


> On Sep 12, 2017, at 2:33 AM, Magnus Nyström < <>> wrote:
> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. 
> This document intends to update the DKIM specification with a new mandatory hash algorithm (SHA-256) and new RSA key size requirements.
> While I definitely agree with the stated direction, I do wonder about the RSA 1024 bit key size recommendation. Conventionally, this corresponds to about 80-bit security and to reach the equivalent of 128-bit security (which is what SHA-256 gives), a 3072-bit RSA key size should be recommended. In this day and age, mandating only 1024 bits seems a little weak. I recognize there may be limitations in the DNS records storing these keys, but it should be possible to store at  least 2048-bit keys (256 bits) (corresponding roughly to 112-bit security) or at least close to it and thus why not require 2048 bit RSA keys as a minimum? 1024 bit keys are, as is also commonly known, considered "legacy" by NIST SP 800-57 part 1 and shouldn't be used for new signatures at this point.
> -- Magnus