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

"Salz, Rich" <rsalz@akamai.com> Wed, 13 September 2017 13:05 UTC

Return-Path: <rsalz@akamai.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9A3132A1A; Wed, 13 Sep 2017 06:05:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8OOn35pZV4D; Wed, 13 Sep 2017 06:05:28 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AB4213291C; Wed, 13 Sep 2017 06:05:28 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v8DD5Puc003404; Wed, 13 Sep 2017 14:05:25 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=6UHh5Lgpq5dpfXihOzu+m6dd99W4xv7Xx+UPqv3Lj9A=; b=khX+UFxHXKwRQ6vu6HDexQDGCQ0vHVDahClbQjJNSh2/SkC9+fHDydGtK+ST0WPAQHQW tPb+goApe2/v4iXRBz3mKTDSZKzfvNwLhFNxtO6aq8BTNqTyblE1GzYo05PoKYaEaa6Q bXMBncUm5luVh0aVW3ls1k+j0+Tb0NHCodYNbOKcABXzPfsyuKicgMnEwMT8q2f02HYw CCWFZuBuM/9gJuiudffs4plHx/CBb/uE/ClDYjVJkMiDmu4DdWFSohqb4iDvUwOcHvKw Pa9/bsdDuO0xwmpNSc6I4IOo0m3FliJ4e45P//ACtFxMST8p21mq1EM01Ypa3w/RFQOM uA==
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050102.ppops.net-00190b01. with ESMTP id 2cx9syfmx2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Sep 2017 14:05:25 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v8DD1dv1002305; Wed, 13 Sep 2017 09:05:24 -0400
Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint3.akamai.com with ESMTP id 2cwwtxdp29-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 13 Sep 2017 09:05:23 -0400
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 13 Sep 2017 08:05:13 -0500
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Wed, 13 Sep 2017 08:05:13 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Magnus Nyström <magnusn@gmail.com>, Russ Housley <housley@vigilsec.com>
CC: "draft-ietf-dcrup-dkim-usage@ietf.org" <draft-ietf-dcrup-dkim-usage@ietf.org>, IETF SecDir <secdir@ietf.org>
Thread-Topic: [secdir] Secdir review of draft-ietf-dcrup-dkim-usage-04
Thread-Index: AQHTK5ErVbgeVvdF1024CzuDI7ABUqKyeKMAgAAI3ICAAFoBgA==
Date: Wed, 13 Sep 2017 13:05:12 +0000
Message-ID: <1B4FD5B0-AB8F-4BD4-B564-46251BAB92E6@akamai.com>
References: <CADajj4aj4ndB-ohsvSRF_DjjpKkS0EMJbSV9kZFDe28e9e7HXg@mail.gmail.com> <9B7000BF-A3DA-4344-B12E-A0D678D76993@vigilsec.com> <CADajj4Z6Bo0pW-1ixjK+Eseq46wZB3rL4MbYv1nfj__32nPNBQ@mail.gmail.com>
In-Reply-To: <CADajj4Z6Bo0pW-1ixjK+Eseq46wZB3rL4MbYv1nfj__32nPNBQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1b.0.161010
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.41.157]
Content-Type: multipart/alternative; boundary="_000_1B4FD5B0AB8F4BD4B56446251BAB92E6akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-13_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709130205
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-13_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709130205
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/yfcJtvRA46BKtG3vlrDSbP85iMk>
Subject: Re: [secdir] Secdir review of draft-ietf-dcrup-dkim-usage-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Sep 2017 13:05:30 -0000

Because of limitations in the DNS system, RSA 1K is really all that’s practical.  For stronger security we are moving to ECC, which is covered in a separate I-D.  This document is really about getting rid of RSA-512.


From: Magnus Nyström <magnusn@gmail.com>
Date: Tuesday, September 12, 2017 at 11:43 PM
To: Russ Housley <housley@vigilsec.com>
Cc: "draft-ietf-dcrup-dkim-usage@ietf.org" <draft-ietf-dcrup-dkim-usage@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-dcrup-dkim-usage-04

Yes, Russ. Perhaps "When using RSA, signers MUST use keys at least 2048 bits long." (I could imagine that at some point DKIM would support ECC)
Thanks,

On Tue, Sep 12, 2017 at 8:11 PM, Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>> wrote:
Magnus:

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?

Russ


On Sep 12, 2017, at 2:33 AM, Magnus Nyström <magnusn@gmail.com<mailto:magnusn@gmail.com>> 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




--
-- Magnus