Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03

Jon Callas <jon@callas.org> Sat, 08 July 2017 07:40 UTC

Return-Path: <jon@callas.org>
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 82952126BF3 for <dcrup@ietfa.amsl.com>; Sat, 8 Jul 2017 00:40:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 AHmpCnJiiKW5 for <dcrup@ietfa.amsl.com>; Sat, 8 Jul 2017 00:40:53 -0700 (PDT)
Received: from smtp72.ord1d.emailsrvr.com (smtp72.ord1d.emailsrvr.com [184.106.54.72]) (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 03432128B8F for <dcrup@ietf.org>; Sat, 8 Jul 2017 00:40:52 -0700 (PDT)
Received: from smtp10.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp10.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 2D3D1A0081; Sat, 8 Jul 2017 03:40:52 -0400 (EDT)
X-Auth-ID: jon@merrymeet.com
Received: by smtp10.relay.ord1d.emailsrvr.com (Authenticated sender: jon-AT-merrymeet.com) with ESMTPSA id 8AD30A0080; Sat, 8 Jul 2017 03:40:51 -0400 (EDT)
X-Sender-Id: jon@merrymeet.com
Received: from [10.0.23.16] (media.merrymeet.com [173.164.244.98]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Sat, 08 Jul 2017 03:40:52 -0400
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Jon Callas <jon@callas.org>
In-Reply-To: <aeee2c9019114d9789a2cd768f0b15e1@usma1ex-dag1mb1.msg.corp.akamai.com>
Date: Sat, 08 Jul 2017 00:40:50 -0700
Cc: Jon Callas <jon@callas.org>, Jim Fenton <fenton@bluepopcorn.net>, Eric Rescorla <ekr@rtfm.com>, Martin Thomson <martin.thomson@gmail.com>, "dcrup@ietf.org" <dcrup@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F68DFD3-9F87-4CE1-87C2-AA08B0A62338@callas.org>
References: <CABkgnnW8nnoRGKoJQ4STAcT6CXdWFRCpz0h20hw+ksfw1x0PGg@mail.gmail.com> <6d4b76c9b42848f1b18c42ba22895993@usma1ex-dag1mb1.msg.corp.akamai.com> <CABcZeBM-qh+iW_+Br2URpdjHsLZ_L1xqZWUVirW-8-E7k4cvzg@mail.gmail.com> <564f297f17424f34b4ba1e118ab6f62c@usma1ex-dag1mb1.msg.corp.akamai.com> <D4D564D0-73C6-45CA-9962-33106229DE02@bluepopcorn.net> <220DB06A-E06D-4DAF-ADE6-7536B6E43630@callas.org> <aeee2c9019114d9789a2cd768f0b15e1@usma1ex-dag1mb1.msg.corp.akamai.com>
To: "Salz, Rich" <rsalz@akamai.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dcrup/KrwICjKgyO2rbJYLyRwrd5IWaGo>
Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03
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: Sat, 08 Jul 2017 07:40:54 -0000

> On Jul 7, 2017, at 7:24 PM, Salz, Rich <rsalz@akamai.com> wrote:
> 
>> For what it's worth, I agree with Jim and Ekr. Hashing is just fine.
> 
> Is it fine, or is it a required or just good?

Fine. Into just good.

> 
> Nobody is saying there is anything wrong with hashing.  Several are saying that, given the limitations of some DNS deployments, it is useful to avoid the indirection and just put the key when we can.

Yeah, I know. They've mentioned the limitations of some DNS implementations going back to the original DKIM work. It's true, but I tend to be on the side of just sucking it up and doing a big DNS query over TCP or whatever. 

I'm also with Jim Fenton that I think the fingerprints make things more future-proof, and I'd make some trivial encoding to put the algorithm along with it for even more future-proofing.

	Jon