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

From: Scott Kitterman <[email-masked]>
Date: Mon, 22 Jan 2018 23:38:38 -0500

I know the last call was a long time ago and so it'd be easy to have 
forgotten, but I think points 1 and 2 are still germane.  It would also still 
be nice to see a sample signature included.

Scott K

On Friday, December 01, 2017 06:57:31 PM Scott Kitterman wrote:
> On Friday, December 01, 2017 11:45:50 AM Murray S. Kucherawy wrote:
> > 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.
> 
> 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
> 
> _______________________________________________
> Dcrup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrup

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 22 Jan 2018 21:09:46 -0800

> be nice to see a sample signature included.

Thanks for the reminder.  And I'm planning to do a second WGLC since the
first one drew exactly one review.  Hopefully we get a little more the
second time around.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 23 Jan 2018 12:28:24 -0500

>> correct example to bounce my signing results against, that would help a

Unfortunately, as far as I know you're still the only person to implement it.  I'll try and 
hack it into Mail::DKIM but I don't know when I'll have the time.

The other edits are in -9, except that the spec for sha256 is now FIPS 180-4-2015.

R's,
John

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 24 Jan 2018 09:35:00 +0000

> hack it into Mail::DKIM but I don't know when I'll have the time.

I've had a working implementation in exim/gnutls for so long that it's
getting bit-rot.  I don't recall what state it's in wrt. the double-hash
issue.  It was internally consistent, sign vs. verify, but has had no
independent testing.  I think it was only buildable on fedora rawhide
due to the GnuTLS version required. It has not gone into the mainline
exim sourcebase only because there is no exim/openssl support yet, the
library being lacking in the required interfaces.

Mail::DKIM support would give me enough testing to release the gnutls-
only version.
-- 
Cheers,
  Jeremy

---

From: "John Levine" <[email-masked]>
Date: 24 Jan 2018 17:28:19 -0500

>library being lacking in the required interfaces.

Perhaps you and Scott can compare signature samples.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Jan 2018 23:05:14 +0000

>Perhaps you and Scott can compare signature samples.

It would be great if I could get the public key/signatures/messages you have produced.  My implementation "works", but the signatures don't self-verify.  If I could get your data to test against, I could narrow down if I have a signing problem or a verification problem.

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Mon, 29 Jan 2018 18:22:22 -0500

> first one drew exactly one review.  Hopefully we get a little more the

Document shepherd speaking:
If we're going to do a second WGLC, can we get that started forthwith?

On the other hand, what's your plan for getting more reviews the
second time than the first?  How do you think we'll get value out of
it, rather than sending it up with Publication Requested now?  Perhaps
the working group simply thinks it's ready for that.

Barry

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 29 Jan 2018 18:29:04 -0500

> the working group simply thinks it's ready for that.

I'd like to see my comments from the WGLC more fully addressed first.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 31 Jan 2018 12:07:55 -0500

>I'd like to see my comments from the WGLC more fully addressed first.

I think I'd like to have enough running code that we can get a signed
example into the draft that everyone agrees is correct.  That also
would make it more likely that my language about key format was right.