[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
- [ietf-dkim] DKIM Key Sizes Peter Goldstein
- Re: [ietf-dkim] DKIM Key Sizes Jon Callas
- Re: [ietf-dkim] Smaller keys/Bigger privacy (was:… Jon Callas
- Re: [ietf-dkim] DKIM Key Sizes Stephen Farrell
- Re: [ietf-dkim] DKIM Key Sizes Eliot Lear
- Re: [ietf-dkim] DKIM Key Sizes Rolf E. Sonneveld
- Re: [ietf-dkim] DKIM Key Sizes Eliot Lear
- Re: [ietf-dkim] DKIM Key Sizes Eliot Lear
- Re: [ietf-dkim] DKIM Key Sizes John R. Levine
- Re: [ietf-dkim] DKIM Key Sizes Martijn Grooten
- Re: [ietf-dkim] DKIM Key Sizes Roland Turner
- Re: [ietf-dkim] DKIM Key Sizes Peter Goldstein
- Re: [ietf-dkim] DKIM Key Sizes John R. Levine
- Re: [ietf-dkim] DKIM Key Sizes Jon Callas
- Re: [ietf-dkim] DKIM Key Sizes Scott Kitterman
- Re: [ietf-dkim] DKIM Key Sizes Jim Fenton
- Re: [ietf-dkim] DKIM Key Sizes Eliot Lear
- Re: [ietf-dkim] DKIM Key Sizes Brandon Long