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

Magnus Nyström <magnusn@gmail.com> Wed, 13 September 2017 03:43 UTC

Return-Path: <magnusn@gmail.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 7312B1321DE; Tue, 12 Sep 2017 20:43:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=gmail.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 bN9nmaZpVcC8; Tue, 12 Sep 2017 20:43:06 -0700 (PDT)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59A61320B5; Tue, 12 Sep 2017 20:43:06 -0700 (PDT)
Received: by mail-oi0-x234.google.com with SMTP id r20so39157696oie.0; Tue, 12 Sep 2017 20:43:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W9ZlHOyUk2Ym8C9QHOG9ngrI7uOv3SGOUdh1iGqAAK0=; b=BNDsIOEjqnBrY9g5Ov/aa1DPzaDVTRkIXoOUbwWBIludSIu1z+HoHmCvRg/QriW5l6 RnCkG+t92BxJBjQ0fi5/89jfsE4TDtF+8cmtp4JrwqD4pvKiD8ZxTASn2B6OUq+98ubh VNWAxAjbbbBvlib1StlZSvuH22ejh10hEYDlNfq6Dg4J6W11lW7nxem8+sUFQCkicPBc 5IV+I6lXAffALNbTcUhvvv7hPramV3QICKpTAT9Y7Ywn3iaGXfauzSF8vCyhzrpccHkh P0bS3smcOVMxytWK/6EcXUk6AB5AvmetEYvECop8FYLNXjvXKsiWVn8V03PRFkRO+GuP Ib1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W9ZlHOyUk2Ym8C9QHOG9ngrI7uOv3SGOUdh1iGqAAK0=; b=MSM+pj+VQFTDVHtzTtaRuQh7Cm4YoIFKvS21WNwdPPXOeVAdi+JG2h3pV6UoacC5Tk m18BrtpBmxdqHs5mpISUMO2lxCvkcefRVoBVT8++lsMlm3xaQAAc7mrpDpO7ku3wjAA3 C/lzMxI6oYZleJeab2Cwl3fuaUu0zJw8C5BvbuERzcZkso4TSZtKsP1Tge3buf4h76no KQIcyuCbbHXn7fmaeofUwuX8YsXk4WePb7t3mlmQCIlchhT43LSs2KgDtCEBjmoYdSzh UJlnp1fvdDYNjZYno1Xnx00uktgBohgrxtxxIYXpmHwoWVPIY0NyqalfMCewnOX3jOv7 fqNA==
X-Gm-Message-State: AHPjjUjjWF/E1q+S70Ot3o8AI+8atqrMw7aq2C5wfVAECUl0/ORpdNRy ptBnKP+U/B+z+U7fhjXUc4MESaZ3t1ojDLhin2Q=
X-Google-Smtp-Source: AOwi7QAVy7cQTXlph3FYNSLu2hd+B4fX4AXfnZVYEhBFNLVICH5SLKZ4NnfXBkVWdguVxnvUsqhnzjxJ5iuAk3PHfkM=
X-Received: by 10.202.196.195 with SMTP id u186mr5733056oif.315.1505274185814; Tue, 12 Sep 2017 20:43:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.53.148 with HTTP; Tue, 12 Sep 2017 20:43:05 -0700 (PDT)
In-Reply-To: <9B7000BF-A3DA-4344-B12E-A0D678D76993@vigilsec.com>
References: <CADajj4aj4ndB-ohsvSRF_DjjpKkS0EMJbSV9kZFDe28e9e7HXg@mail.gmail.com> <9B7000BF-A3DA-4344-B12E-A0D678D76993@vigilsec.com>
From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= <magnusn@gmail.com>
Date: Tue, 12 Sep 2017 20:43:05 -0700
Message-ID: <CADajj4Z6Bo0pW-1ixjK+Eseq46wZB3rL4MbYv1nfj__32nPNBQ@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Cc: IETF SecDir <secdir@ietf.org>, draft-ietf-dcrup-dkim-usage@ietf.org
Content-Type: multipart/alternative; boundary="001a11353034229a3c055909f54e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/t3ENl53_bWkh3D3TrnEfDCtQkek>
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 03:43:08 -0000

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> 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> 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