IETF Logo Mail Archive

Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

"John R Levine" <johnl@taugh.com> Fri, 07 April 2017 15:29 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9610212773A for <dmarc@ietfa.amsl.com>; Fri, 7 Apr 2017 08:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=SK/Xnzdv; dkim=pass (1536-bit key) header.d=taugh.com header.b=iz7eBwVJ
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 LJSn3rSSFBqP for <dmarc@ietfa.amsl.com>; Fri, 7 Apr 2017 08:29:49 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDC01127444 for <dmarc@ietf.org>; Fri, 7 Apr 2017 08:29:48 -0700 (PDT)
Received: (qmail 90279 invoked from network); 7 Apr 2017 15:29:42 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=160a5.58e7b066.k1704; bh=7GMtyiiqDPF0/0TDFeYR7wWmCRaq3KsPZBdEfHO6Hic=; b=SK/XnzdvCFAlz+nBStllQjeydE5oOxxcrfPTJ5q7MRweMiGNIWZM0SghcZpfhcPadpWUS5tAvXP67p2FlY/xWnGVMUvhjLxQgw4C8frSIOikxIQdrRFM0HCNvTS9gVpQh6tlAVrUMUpGDnH5xWl5ZALnlFxCdOoyslb7SS0tuAF2PxT1fFVCW9dMsb7tRQ6dsyhHGn5nO2qav2i/l/wvUyYC54qqFTnF5gfSiCftlPNeL8qlkEqeF+jERcSbJNaV
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=160a5.58e7b066.k1704; bh=7GMtyiiqDPF0/0TDFeYR7wWmCRaq3KsPZBdEfHO6Hic=; b=iz7eBwVJAd3XESO0Wmm5RQYKc+yB3VJTgm24BHxJdVvEYItF9U3vmpkZfFBJxII4Qk7OGUYQMvJtMi9LnqEcKm8FinhvZoPb9BwKPiL1zUdBdXRwmWmJGbILRZ18Skiz00fcBC1K+J2MCCveCfWyKBLHYDo3LQRHh//fTuNDH8g+QRHWbwWD9Df9l9ZNM7vsLRmz8ZL480teFPS5YhU87Jn4sdqre1SobPLM1PtoDPSt+JZM0mEueA9RShWhmrCK
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 07 Apr 2017 15:29:42 -0000
Date: Fri, 07 Apr 2017 11:29:41 -0400
Message-ID: <alpine.OSX.2.20.1704071118590.55219@ary.qy>
From: John R Levine <johnl@taugh.com>
To: Brandon Long <blong@google.com>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
In-Reply-To: <CABa8R6v8xXgbhywVA4yEEsDDZ8RW7t49FHnX1rhDQUbeMWdwsg@mail.gmail.com>
References: <d91de205-05b4-0b59-b3a3-568fc0f57375@corp.mail.ru> <20170406235815.47843.qmail@ary.lan> <CABa8R6v8xXgbhywVA4yEEsDDZ8RW7t49FHnX1rhDQUbeMWdwsg@mail.gmail.com>
User-Agent: Alpine 2.20 (OSX 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/FF0SKS9RjcOS54NswTVEFQoO3qI>
Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Apr 2017 15:29:50 -0000

> Should we add more hash algorithms?

As far as I know SHA-256 is still adequate for the forseeable future, but 
I expect the crypto experts will weigh in.  Ditto whether we really need 
three new algorithms since the more ways there are to sign, the more ways 
there are to have broken signatures.  I'd rather pick a single ECC 
algorithm that is mathematically respectable and widely implemented.

> Also, I'm very unclear of the benefit of the fp versions, adding nearly 400
> bytes per signature to the message seems expensive, and in the arc case, an
> extra 800 bytes per hop (nearly doubling the size of each hop) seems like
> an odd compromise.  Maybe I'm being silly.

This is only to work around the 256 byte TXT provisioning bugs.  If your 
provisioning works, you can keep publishing keys the current way.

I probably could be persuaded that if we're going to tell people to update 
their DKIM and ARC signing/verifying libraries, we should just tell them 
to add ECC crypto and the key length problems go away forever.

R's,
John

v2.23.0 | Report a Bug | By Email