Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.txt

Scott Kitterman <sklist@kitterman.com> Sun, 02 July 2017 20:00 UTC

Return-Path: <sklist@kitterman.com>
X-Original-To: dcrup@ietfa.amsl.com
Delivered-To: dcrup@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5732D127B57 for <dcrup@ietfa.amsl.com>; Sun, 2 Jul 2017 13:00:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.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 e7GW8_Z8GCkD for <dcrup@ietfa.amsl.com>; Sun, 2 Jul 2017 13:00:49 -0700 (PDT)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E229F120454 for <dcrup@ietf.org>; Sun, 2 Jul 2017 13:00:48 -0700 (PDT)
Received: from [10.53.15.243] (mobile-166-170-30-35.mycingular.net [166.170.30.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 81F7EC401B8; Sun, 2 Jul 2017 15:00:46 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1499025646; bh=qSeK2Kzofngv88XoFUzumuAmB4q7xL31iDmEZAGIXuA=; h=Date:In-Reply-To:References:Subject:To:From:From; b=AxK6jSVv0BAjeqesJ1Ylma45bPFgV32Od5otAu6lCacdRoeBrbRWN9lu37Skb5X+4 +zCtrZDUwKdp4rxiVn2EeTKDTlXBFQ4+taU5wmSQePazxx4Dz1zd9OgsWRGqW0x3bE 2O+B/MveZq7bof7QRKhzW/4OsZr3fsE4PnCDZhsc=
Date: Sun, 02 Jul 2017 20:00:44 +0000
In-Reply-To: <alpine.OSX.2.21.1707021544590.72907@ary.qy>
References: <CABcZeBOs1yZ7q3oBgNeVkw=zSQb_SuS4hqK8BH0ebrD5LRYTFg@mail.gmail.com> <20170702025650.55902.qmail@ary.lan> <CABcZeBM4KEr5CEZq4t9BX50btCRPLhZBAtZN18v_6gZ5B-ni5A@mail.gmail.com> <alpine.OSX.2.21.1707012341180.70305@ary.qy> <CABcZeBOLSrYo8mEQ1evyU7CzctV0VF4r7_bX3nA0oxtHCeEgSQ@mail.gmail.com> <alpine.OSX.2.21.1707021544590.72907@ary.qy>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
To: dcrup@ietf.org
From: Scott Kitterman <sklist@kitterman.com>
Message-ID: <54B05A3A-C142-4CB9-8DD7-2E303E1B1869@kitterman.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dcrup/KwGms1ZKWNRnK4zvA2mCkZ1k5Zg>
Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.txt
X-BeenThere: dcrup@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DKIM Crypto Update <dcrup.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dcrup>, <mailto:dcrup-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dcrup/>
List-Post: <mailto:dcrup@ietf.org>
List-Help: <mailto:dcrup-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dcrup>, <mailto:dcrup-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Jul 2017 20:00:51 -0000


On July 2, 2017 3:53:18 PM EDT, John R Levine <johnl@taugh.com> wrote:
>> Given that (a) we already have algorithms that are bigger and (b) 
>> post-quantum keys might be quite a bit bigger, it seems unwise to
>design 
>> under the assumption that it will not happen.
>
>Well, OK, but concretely, what do you want us to do now?
>
>DKIM has had algorithm tags since it was defined a decade ago.  This
>draft 
>adds two new algorithm tags (rsafp-sha256 and eddsa-sha256) and
>deprecates 
>one old one (rsa-sha1) and as part of that adds RSA key hashes as a key
>
>verification method.  If it turns out that we need to switch signature 
>algorithms, we'll revise DKIM again, and add and deprecate tags and 
>algorithms as needed.  Maybe new algorithms will use key hashes, maybe 
>they won't, but at that point we can define whatever we need.
>
>Right now, today, I don't see that hasned ed25519 keys solve any
>problem, 
>so I'm not going to include them unless there is something I don't 
>understand that they can do that plain ed25519 keys in the key records 
>don't.

+1

Scott K