Return-Path: 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 766601315C7 for ; Tue, 20 Jun 2017 10:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 1nhyWcvY5Sne for ; Tue, 20 Jun 2017 10:38:09 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30EE51315B8 for ; Tue, 20 Jun 2017 10:38:09 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id 63so55186201ywr.0 for ; Tue, 20 Jun 2017 10:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8wSxAJ+gHi0g98hDB1dbU7MZgAdNdntUI/snG/7ca/4=; b=lFmO/1V2o4iKJCw2F3DfXx7sLy+mxDF/l3zqZhGV/wHQFXAJLaA10y3CWuy7A8HkuQ QkcC5CyxuF1QuElPEsvgq/pkMPWERPyMG1ncL04lWb8eA7e2PrzBoxRu4LQwVWtxKT0+ rrZZ5MmEYZ2ewOqbt8hXT4kSPPO+SLqth+znOOqSGjhcymKqHu2Q4nAQQwMQNPJeluil LIopxxtk5w7nxDu54ieCObA18Pb/y030l8mBqjy43Mmyg4vUQOQ3H6agYsh3YaHskThv UYcWtHE+0+9HdNHDgdboF5OBzYjOLTFverzGHRPN6fE/ZierjOMpqGab/enJIwZ3Tu1Y mnzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8wSxAJ+gHi0g98hDB1dbU7MZgAdNdntUI/snG/7ca/4=; b=WsINHZrxZ4dBxU8H11lH1jzw249vlDHHsSAcg/isrUlk4DOgdf1NzJN9e315PYfJDe W06NYExQErVLyZ8ZwmjZajquSAX3kNeMEBc/alfwctI1qlgo2EfuOODpMoHFK/HIzVbI EwoRelmk62tbM7gwwEbft1qUaZwcC7XyDDEbJ9+hTT8417abJTJhmK5ieHgCMHwrtMWR 9WNUzCfTdaDTSPT6/Q46DPfVKJ50bREj+TI8jnm3olCfpDT0/aR/RpkSs8+Mj+3CQCgD EbrIl39KA0OgFAvRlgweOXvTnI0OaW5VhJM5b4ux3UHj8PK6K/g34b+gpBQu/jLvqMo3 lUyw== X-Gm-Message-State: AKS2vOzWYACFLldkZAICLgq+o4fmmgFcCuTBNV5QEjiWcJJTXQIACilQ G6ce7odDOghbiS4eHz+LO8AqxeyMbgApjDA= X-Received: by 10.129.109.4 with SMTP id i4mr24872562ywc.3.1497980288328; Tue, 20 Jun 2017 10:38:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Tue, 20 Jun 2017 10:37:27 -0700 (PDT) In-Reply-To: References: <20170619205309.10839.qmail@ary.lan> From: Eric Rescorla Date: Tue, 20 Jun 2017 10:37:27 -0700 Message-ID: To: John R Levine Cc: "dcrup@ietf.org" Content-Type: multipart/alternative; boundary="001a114dd184f7aedc055267b617" Archived-At: Subject: Re: [Dcrup] Is there anything this WG wants to do not yet in draft-ietf-dcrup-dkim-crypto-01 ? X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 17:38:11 -0000 --001a114dd184f7aedc055267b617 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 20, 2017 at 9:50 AM, John R Levine wrote: > Giving this document a quick read I see several things I would change. >> > > In case it's not clear, I do not purport to be any sort of crypto expert, > so I'm hoping that you, r$, et al. help us to be sure that what I say makes > sense. > > 1. You say you are using EdDSA with SHA-256? Does this mean you intend >> to use the HashEdDSA variant see ( >> https://tools.ietf.org/rfcmarkup?doc=8032#section-4)? If so you >> should say so. >> > > I think the answer is no. DKIM signatures use two chained hashes. First > it hashes a canonicalized version of the message body, and inserts the > base64 hash into the DKIM-Signature header. Then it hashes a canonicalized > version of the headers, signs that hash, and inserts the base64 signature > of the second hash into the DKIM-Signatuer header. To avoid infinite > regress, the verification step pretends the signature wasn't in the header > when verifying. > > As far as I can tell, feeding the canonicalized header text into HashEdDSA > gives the same result as feeding the hash into PureEdDSA. Since the > hashing in DKIM has been defined for a decade and we're not planning to > change it (other than to deprecate SHA-1) I'd rather say this is a > PureEdDSA signature of the existing hash. OK, I think this probably needs to be clearer in the document. 2. I wouldn't specific generic EdDSA but rather EdDSA with a specific >> curve. This is both for practical reasons (I don't want to have to >> distinguish keys by len()) and for algorithmic reasons (you want to >> use a stronger digest algorithm than SHA-256 with X448) >> > > OK. Looking at 8032, it appears I want to use Ed25519, right? Yes, I think so. -Ekr 3. You shouldn't name the keys ecdh(fp) but rather eddsa(fp) These keys >> are not intended for use with key exchange but rather signature. The >> document actually seems kinda confused on this point with the text >> saying one thing and the table saying another. >> > > OK. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > --001a114dd184f7aedc055267b617 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 20, 2017 at 9:50 AM, John R Levine <johnl@taugh.com><= /span> wrote:
Giving this document a quick read I see several things I would change.

 In case it's not clear, I do not purport to be any sort of crypto exper= t, so I'm hoping that you, r$, et al. help us to be sure that what I sa= y makes sense.

1. You say you are using EdDSA with SHA-256? Does this mean you intend
=C2=A0 =C2=A0to use the HashEdDSA variant see (
=C2=A0 =C2=A0https://tools.ietf.org/rfcmar= kup?doc=3D8032#section-4)?=C2=A0 If so you
=C2=A0 =C2=A0should say so.

 I think the answer is no.=C2=A0 DKIM signatures use two chained hashes.=C2= =A0 First it hashes a canonicalized version of the message body, and insert= s the base64 hash into the DKIM-Signature header.=C2=A0 Then it hashes a ca= nonicalized version of the headers, signs that hash, and inserts the base64= signature of the second hash into the DKIM-Signatuer header.=C2=A0 To avoi= d infinite regress, the verification step pretends the signature wasn't= in the header when verifying.

As far as I can tell, feeding the canonicalized header text into HashEdDSA = gives the same result as feeding the hash into PureEdDSA.=C2=A0 Since the h= ashing in DKIM has been defined for a decade and we're not planning to = change it (other than to deprecate SHA-1) I'd rather say this is a Pure= EdDSA signature of the existing hash.

OK, I= think this probably needs to be clearer in the document.


2. I wouldn't specific generic EdDSA but rather EdDSA with a specific =C2=A0 =C2=A0curve. This is both for practical reasons (I don't want to= have to
=C2=A0 =C2=A0distinguish keys by len())=C2=A0 and for algorithmic reasons (= you want to
=C2=A0 =C2=A0use a stronger digest algorithm than SHA-256 with X448)

 OK.=C2=A0 Looking at 8032, it appears I want to use Ed25519, right?


Yes, I think so.

-Ekr



3. You shouldn't name the keys ecdh(fp) but rather eddsa(fp)=C2=A0 Thes= e keys
=C2=A0 =C2=A0are not intended for use with key exchange but rather signatur= e. The
=C2=A0 =C2=A0document actually seems kinda confused on this point with the = text
=C2=A0 =C2=A0saying one thing and the table saying another.

 OK.

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

--001a114dd184f7aedc055267b617--