Subject: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-09.txt

From: [email-masked]
Date: Fri, 11 May 2018 10:24:28 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DKIM Crypto Update WG of the IETF.

        Title           : A new cryptographic signature method for DKIM
        Author          : John Levine
	Filename        : draft-ietf-dcrup-dkim-crypto-09.txt
	Pages           : 7
	Date            : 2018-05-11

Abstract:
   This document adds a new signing algorithm to DKIM.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-crypto/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dcrup-dkim-crypto-09
https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-crypto-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dcrup-dkim-crypto-09

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "John R Levine" <[email-masked]>
Date: 11 May 2018 13:26:16 -0400

This version adds a signed example message (one of Scott Kitterman's 
examples from dkimpy) and makes a few minor editorial changes we discussed 
several months ago.  I really really really hope it's done now.

> https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-crypto/

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 11 May 2018 18:22:18 +0000

Yes.  Let's wait one week to make sure nobody has issues that haven't been addressed.  Final last call, as it were.

Is anyone interested in doing the shepherd writeup?  If not, I'll do it.

---

From: Jeremy Harris <[email-masked]>
Date: Fri, 11 May 2018 20:34:26 +0100

> 	Filename        : draft-ietf-dcrup-dkim-crypto-09.txt

Section 3 specifies PureEDdSA.  I thought we'd been forced
by library implentations to use the sha-512 prehashed
variant.  Am I merely being confused by the naming?

-- 
Cheers,
  Jeremy

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 11 May 2018 16:16:16 -0400

> On May 11, 2018, at 3:34 PM, Jeremy Harris <[email-masked]> wrote:
> 

Perhaps in DKIM the data to be signed is already pre-hashed
(the body and header hashes in the DKIM signature header).

The OpenSSL docs for the Ed25519 algorithm used for the keys
we've been discussing says:

------------
NAME
       Ed25519, Ed448 - EVP_PKEY Ed25519 and Ed448 support

DESCRIPTION
       The Ed25519 and Ed448 EVP_PKEY implementation supports key generation,
       one-shot digest sign and digest verify using PureEdDSA and Ed25519 or
       Ed448 (see RFC8032). It has associated private and public key formats
       compatible with draft-ietf-curdle-pkix-04.

       No additional parameters can be set during key generation one-shot
       signing or verification. In particular, because PureEdDSA is used, when
       signing or verifying a digest must NOT be specified.

NOTES
       The PureEdDSA algorithm does not support the streaming mechanism of
       other signature algorithms using, for example, EVP_DigestUpdate().  The
       message to sign or verify must be passed using the one-shot
       EVP_DigestSign() asn EVP_DigestVerify() functions.
------------

See also: https://tools.ietf.org/html/rfc8032#section-4

-- 
	Viktor.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 11 May 2018 23:26:10 +0200

>     This document adds a new signing algorithm to DKIM.

Three editorial remarks/nits.

1. A suggestion to align Title and Abstract of the document. The Title 
mentions 'A new cryptographic signature method' where the Abstract 
mentions 'a new signing algorithm'. I would suggest to change the Title 
into 'A new signing algorithm for DKIM', to get the terminology in line 
with par. 3.3 of RFC6376 and with the last line of par. 1 of this draft.

2. Suggestion for par. 1: instead of

'creating hashes of the message headers and body [...]'

use

'creating hashes of a set of message headers and of the body [...]'

3. Suggestion for par. 1: use 'public key' instead of 'signature 
verification key', as RFC6376 does not use the term 'signature 
verification key', while it uses 'public key'.

/rolf

---

From: "John Levine" <[email-masked]>
Date: 11 May 2018 17:52:58 -0400

>variant.  Am I merely being confused by the naming?

No, it turns out I got it backwards.  Everyone implements the pure
version, not the prehashed version.

R's,
John

---

From: Stan Kalisch <[email-masked]>
Date: Tue, 15 May 2018 20:27:34 -0400

Apologies for the relative lateness in replying.

> On May 11, 2018, at 1:26 PM, John R Levine <[email-masked]> wrote:
> 
> This version adds a signed example message (one of Scott Kitterman's examples from dkimpy) and makes a few minor editorial changes we discussed several months ago.  I really really really hope it's done now.

A reference to RFC 8017 should either accompany the reference to RFC 3447, which 8017 obsoletes, or replace it.

Thanks,
Stan

---

From: "John R Levine" <[email-masked]>
Date: 15 May 2018 21:00:04 -0400

> A reference to RFC 8017 should either accompany the reference to RFC 3447, which 8017 obsoletes, or replace it.

The only reference to 3447 is a passing mention to the previous document:

  The defining documents specify a single signing algorithm, RSA [RFC3447].

That is indeed what it says.  Maybe we should update 6376 but this draft 
isn't about RSA.

Regards,

---

From: Stan Kalisch <[email-masked]>
Date: Tue, 15 May 2018 21:30:12 -0400

On May 15, 2018, at 9:00 PM, John R Levine <[email-masked]> wrote:

> That is indeed what it says.

And I agree on this; this is more about 3447 being cited as normative.  But if people think the RFC Editor will accept this kind of rationale, then I'm okay with it and this shouldn't be considered a full-on objection.

> Maybe we should update 6376 but this draft isn't about RSA.

Agreed.

Stan

---

From: "John Levine" <[email-masked]>
Date: 15 May 2018 21:36:48 -0400

In article <[email-masked]> you write:
>And I agree on this; this is more about 3447 being cited as normative.  But if people think the RFC Editor will
>accept this kind of rationale, then I'm okay with it and this shouldn't be considered a full-on objection.

The editors will doubtless make lots of little changes to make it
match the stylebook, no need to worry about it.  If the guide has
some rule about citing obsolete RFCs (I have no idea), they'll fix it.

R's,
John

---

From: Stan Kalisch <[email-masked]>
Date: Tue, 15 May 2018 21:51:00 -0400

> On May 15, 2018, at 9:36 PM, John Levine <[email-masked]> wrote:
> 
> If the guide has some rule about citing obsolete RFCs (I have no idea), they'll fix it.

It does; that's why I mentioned it. 0:-)  Anyway, if nobody cares enough, I'm happy to drop it and just leave it.

Stan