[ietf-dkim] DKIM Key Sizes

Peter Goldstein <peter@valimail.com> Thu, 27 October 2016 08:31 UTC

Return-Path: <ietf-dkim-bounces@mipassoc.org>
X-Original-To: ietfarch-ietf-dkim-archive@ietfa.amsl.com
Delivered-To: ietfarch-ietf-dkim-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0C7129C84 for <ietfarch-ietf-dkim-archive@ietfa.amsl.com>; Thu, 27 Oct 2016 01:31:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.095
X-Spam-Level: *
X-Spam-Status: No, score=1.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_FONT_FACE_BAD=0.981, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=valimail.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 HhC7Faa66vki for <ietfarch-ietf-dkim-archive@ietfa.amsl.com>; Thu, 27 Oct 2016 01:31:10 -0700 (PDT)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 7D6CE129C8E for <ietf-dkim-archive@ietf.org>; Thu, 27 Oct 2016 01:31:10 -0700 (PDT)
Received: from simon.songbird.com (simon.songbird.com [127.0.0.1]) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u9R8UVup007159; Thu, 27 Oct 2016 01:30:34 -0700
Authentication-Results: simon.songbird.com; dkim=fail reason="verification failed; unprotected key" header.d=valimail.com header.i=@valimail.com header.b=AilNA3gG; dkim-adsp=none (unprotected policy); dkim-atps=neutral
Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com [209.85.216.179]) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u9R8UQ5v007155 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for <ietf-dkim@mipassoc.org>; Thu, 27 Oct 2016 01:30:28 -0700
Received: by mail-qt0-f179.google.com with SMTP id 12so17512382qtm.3 for <ietf-dkim@mipassoc.org>; Thu, 27 Oct 2016 01:29:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:from:date:message-id:subject:to; bh=MVjFBPgeHjRtmzxr7mwYFT5jpMsahIgqkT6xAA4mDzs=; b=AilNA3gG4GFJoFmA5jPl1hk1Dy5b/swQzO9qLdYZOMc/MJ/o21NxVbFHRj6ClsTyt6 +urL3B9tfEyyvCRtSuDAQta82UUCriRLdckVJXhkXUNUDTOopjtsjy0eaeG+NBVvXyII tq42IRpNkwen9OfBH0L13o5Q/Jr3BrFspjzhODzgRgS9Rmg2d1m7MZIdtHvXD3EKbojd cQa+7tbvnMnLM0ZK270z/fCdmmOoSm6+ej3GamvejlJNF60GBcuc80zVrd7a37mAck08 IT/64I69gY4b47vfxSD2vUE1nRt497AQYgXW8wGgH1pPpFl0iaYqrbz9Pjl/qsI/hYKL 15Nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MVjFBPgeHjRtmzxr7mwYFT5jpMsahIgqkT6xAA4mDzs=; b=M8o/4kLqnG8iPN4tpRP5DBvxIQx9T5yhgU13qudW3KN0Uyk4QBKBPXXxtj8GK0jRB7 J5c7do655F75TIl8cYUn6C/k/J1jUFxbF1+p0g8BiJWWO56Q4zU/4AT8isC1ad/Q6+yZ 7QTa7rQf5aVR985i+di094EYTJXEPupHu7ix2KLQ1g6K3usHvsmVfOj0emi1wBG5zCaF 4cSG5P0u15sYaUgKhcCQ2J47ZC/a57n+Yj5ACWZmDBLy4j8PNqNAkqPZFu9wYSwFVOcn UoB9d5XPmzp2iR+Qkrngr9SHOzrbhr7yI02AVs8c920GC7Jur5hADIGHuqmMzPmteluB BKYQ==
X-Gm-Message-State: ABUngvfAC4ViIjw67RLniP3zMNUeWq5DvU64GrFQEMZVgCF98iq7dokbq+/UooQSLNOZIrmAkOzw15gmk2wzqQ==
X-Received: by 10.200.36.202 with SMTP id t10mr5416076qtt.85.1477556975393; Thu, 27 Oct 2016 01:29:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.130.5 with HTTP; Thu, 27 Oct 2016 01:29:35 -0700 (PDT)
From: Peter Goldstein <peter@valimail.com>
Date: Thu, 27 Oct 2016 10:29:35 +0200
Message-ID: <CAOj=BA3TFzxnHHZ+-tpoMCWxhaGvOg0RREbcYbpzS9g3g8i=Qg@mail.gmail.com>
To: ietf-dkim@mipassoc.org
Subject: [ietf-dkim] DKIM Key Sizes
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.16
Precedence: list
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/options/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim/>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5094440492727041828=="
Errors-To: ietf-dkim-bounces@mipassoc.org
Sender: ietf-dkim <ietf-dkim-bounces@mipassoc.org>

Hi Everyone,

During a discussion about the ARC protocol yesterday the question of
appropriate key sizes came up.  The ARC proposal simply adopts the
guidelines for signing keys as laid out in RFC 6376.

Those guidelines are in section 3.3.3 of RFC 6376 (
https://tools.ietf.org/html/rfc6376#section-3.3.3).  They specify that
receivers MUST validate signatures of 512 to 2048 bits, but are not
required to validate signatures with longer keys - may be worth revisiting
given advances in computing power, the increasing importance of DKIM as an
element of email authentication, and the reuse of these guidelines in other
proposals (i.e. ARC).

I'd like to suggest that it may be a good idea to increase the upper value
to 4096 or even 8192, to ensure that the standard is compatible with best
practices going forward.

Some motivations for revisiting the key size requirements are:

   - 2048-bit keys are starting to become more common, with at least one
   large sender (GSuite by Google) defaulting to 2048 bit keys.
   - The TXT records for most 2048-bit keys exceed 512 bytes, so mandatory
   support for 2048-bit keys already requires receivers and senders to support
   EDNS or TCP fallback for DNS.  An increase to 4096 (or even 8192) bits will
   not change the required level of DNS support
   - While key rotation can somewhat mitigate the security risks of using a
   smaller key, in practice most real-world DKIM key implementations have not
   made such rotation part of their systems, and hence in-practice the
   mitigation is minimal
   - The extension of these guidelines via ARC to forwarders, mailing
   lists, etc. that are even more likely to keep their keys unchanged for long
   periods of time.


Is there any interest in the group to discuss this question and how we may
be able to improve the current guidelines?

Thanks.

Best,

Peter
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html