Subject: [Dcrup] Working Group Last Call for draft-ietf-dcrup-dkim-crypto

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 1 Dec 2017 11:45:50 -0800

Colleagues,

We hereby begin Working Group Last Call for draft-ietf-dcrup-dkim-crypto,
to end December 15th.  Please review the document and post the (preferably
at least somewhat detailed) results of your reviews to the list or to the
chairs and author by end of that day.  Assuming no major revisions or
discussion are needed, we hope to have this shipped to Alexey by the
beginning of the December holidays.

Of note here: OpenSSL has begun the work of developing the API functions
that will be needed to add this to various implementations of DKIM.  For
details, see https://github.com/openssl/openssl/pull/4829.

-MSK, DCRUP co-chair

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 01 Dec 2017 18:57:31 -0500

> beginning of the December holidays.

I've reviewed the document (and started working on implementation).  I think 
it is generally ready to go, but I have four comments:

1.  The existing RFC 6376 signature algorithms specify what to use for hash-
alg.  That's missing from the Ed25519-SHA256 definition in section 3.  As 
implied by the name (and discussed on the list), the hash-alg should be 
SHA256.  Recommend replacing the leading sentence phrase in section 3 with:

The Ed25519-SHA256 Signing Algorithm computes a message hash as described in 
Section 3.7  of [RFC6376] using SHA-256 [FIPS-180-3-2008] as the hash-alg, ...

This matches the way other signing algorithms are described in RFC 6376.

2.  For clarity, per some of the IETF LC feedback on draft-ietf-dcrup-dkim-
usage, recommend adding after the main body of section 3 and before the note:

This is an additional DKIM signature algorithm added to Section 3.3 of 
[RFC6376] as envisioned in Section 3.3.4 of [RFC6376].

3.  Private key storage format

Unlike RSA, Ed25519 does not appear to have a standardized textual format.  I 
think it might make sense to specify that for DKIM Ed25519 purposes the 
private key is stored as the base64 encoded output of the RFC 8032 Section 
5.1.5 private key generation processes.  This would provide a (slightly) human 
readable private key representation that could be used by different 
implementations so that operators can safely switch implementations without 
regenerating keys and that are more understandable for trouble shooting 
purposes.

4.  Examples

It would be nice to have at least one signing example for implementers to use 
to verify correctness.  I currently have either a signing bug or a 
verification bug in my work and I'm not sure which.  If I had a known correct 
example to bounce my signing results against, that would help a lot.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 Dec 2017 09:42:40 -0800

Colleagues,

WGLC has completed and this is sadly the only feedback we received.  I will
do a chair's review today, but it would be really helpful to have some more
reviewers to comment on this before we send it to Alexey.

Simultaneously: John, your comments in reply to this?

-MSK

On Fri, Dec 1, 2017 at 3:57 PM, Scott Kitterman <[email-masked]>
wrote:

> _______________________________________________
> Dcrup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrup
>

---

From: Seth Blank <[email-masked]>
Date: Mon, 18 Dec 2017 11:30:03 -0800

On Mon, Dec 18, 2017 at 9:42 AM, Murray S. Kucherawy <[email-masked]>
wrote:

> WGLC has completed and this is sadly the only feedback we received.  I
> will do a chair's review today, but it would be really helpful to have some
> more reviewers to comment on this before we send it to Alexey.
>

The document is sound to me, and I have only one tiny nit related to the
final paragraphs in sections 4.1 and 4.2:

   4.1:
   DKIM signatures identified as having been signed with historic
   algorithms (currently rsa-sha1) have permanently failed evaluation as
   discussed in [RFC6376] Section 3.9.

   4.2:
   DKIM signatures with insufficient key sizes (currently rsa-sha256
   with less than 1024 bits) have permanently failed evaluation as
   discussed in [RFC6376] Section 3.9.

For "permanently failed evaluation" should it be explicitly mentioned that
this requires a PERMFAIL response? As I said, a tiny nit...

Seth

-- 

Bringing Trust to Email

Seth Blank | Director of Industry Initiatives
[email-masked]
+1-415-894-2724 <415-894-2724>

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 18 Dec 2017 15:14:20 -0500

> this requires a PERMFAIL response? As I said, a tiny nit...

That's what the reference to RFC6376] Section 3.9 does.

Scott K

---

From: Seth Blank <[email-masked]>
Date: Mon, 18 Dec 2017 12:28:36 -0800

> That's what the reference to RFC6376] Section 3.9 does.

Yes, that was what my nit was about. Right now, following the reference you
still need to infer that PERMFAIL is the appropriate response, and the
question was if it needs to be explicitly stated in conjunction with the
reference. "No" is a perfectly acceptable response.

-- 

Bringing Trust to Email

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 18 Dec 2017 15:57:56 -0500

> reference. "No" is a perfectly acceptable response.

OK.  That's copy/pasted from the -update draft that's been through IETF last 
call/IESG approval already, so I'd go with "No" then.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 Dec 2017 16:26:55 -0800

> call/IESG approval already, so I'd go with "No" then.

This document has been through neither of those processes yet.  Are you
thinking of the usage document?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 19 Dec 2017 01:08:06 +0000

On December 18, 2017 7:26:55 PM EST, "Murray S. Kucherawy" <[email-masked]> wrote:
>> > Yes, that was what my nit was about. Right now, following the
>reference
>> you
>> OK.  That's copy/pasted from the -update draft that's been through
>IETF
>> last

Sort of.  The language is identical to how we did it in the usage document (which has made it through those hurdles), so I think this document should stay consistent with it.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 18 Dec 2017 20:43:22 -0500

>> Section 3.7  of [RFC6376] using SHA-256 [FIPS-180-3-2008] as the hash-alg,

That's fine.

>> [RFC6376] as envisioned in Section 3.3.4 of [RFC6376].

Also fine.

>> 5.1.5 private key generation processes.  This would provide a (slightly)
>> human readable private key representation that could be used by different

OK by me but I'm no crypto expert.  Perhaps we could ask the openssl folks what
key format they'll be using.

>> 4.  Examples
>>
>> It would be nice to have at least one signing example for implementers to
>> use to verify correctness.  I currently have either a signing bug or a
>> verification bug in my work and I'm not sure which.  If I had a known
>> correct example to bounce my signing results against, that would help a lot.

A reasonable albeit somewhat painful request.  What ed25519 library are you using?

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 19 Dec 2017 01:54:18 +0000

On December 18, 2017 8:43:22 PM EST, John Levine <[email-masked]> wrote:
>>> 1.  The existing RFC 6376 signature algorithms specify what to use
>for
>>> hash-
>>> The Ed25519-SHA256 Signing Algorithm computes a message hash as
>described
>>> in
>>> usage, recommend adding after the main body of section 3 and before
>the
>>> note:
>>>

I'm using python-nacl, which wraps libsodium.

https://pynacl.readthedocs.io/en/stable/
https://download.libsodium.org/doc/

Scott K