Subject: [Dcrup] I-D draft-ietf-dcrup-dkim-crypto-06

From: "John R Levine" <[email-masked]>
Date: 13 Sep 2017 13:41:13 -0400

I have sent in a new draft which is intended to take into account all of 
the comments I've seen.  There aren't any changes to bits on the wire, 
just editorial ones.

As far as I can tell, this is about as done as it's going to get.

R's,
John

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 13 Sep 2017 19:47:01 +0100

On 13/09/17 18:41, John R Levine wrote:
> the comments I've seen.

Section 4 says to use the Pure variant of Ed25519, which section 4
of rfc 8032 appears to describe as (my paraphrase) sign only; not
hashing the data handed to it.  What we hand to it is already a
hash, using sha256.

Do I have that right?

The existing interfaces in both GnuTLS and OpenSSL appear to
be aiming towards a Hash version of Ed25519, if I read them right -
and they don't say explicitly what the hash-function is.

For example, https://gnutls.org/reference/gnutls-abstract.html
says, for gnutls_privkey_sign_hash() :-

"Note that, not all algorithm support signing already hashed data. When
 signing with Ed25519, gnutls_privkey_sign_data() should be used."

(I'm assuming that ...sign_data() does a hash and then signs.  I also
fear, reading between some lines, that the hash might not be sha256).

Are we expecting these libraries to enhance their APIs?
Or am I totally off track?
-- 
Thanks,
  Jeremy

---

From: "John Levine" <[email-masked]>
Date: 14 Sep 2017 01:41:18 -0000

>hashing the data handed to it.  What we hand to it is already a

Yes.

>and they don't say explicitly what the hash-function is.

We know, see previous discussion of this exact topic.  The existing
RSA DKIM signatures already do a hash of the canonicalized text and it
is operationally a lot easier to pass the same hash to EC crypto
rather than invent a different canonicalization scheme just to move
the hash to the other side of the call to the crypto library.

>Are we expecting these libraries to enhance their APIs?

I haven't looked in detail at the APIs for Ed25519 crypto, but naively
assumed that if the spec says there's a pure version that doesn't hash
its input, the libraries would implement it.

R's,
John

---

From: Jeremy Harris <[email-masked]>
Date: Thu, 14 Sep 2017 09:25:33 +0100

> its input, the libraries would implement it.

Currently there is not, and the documentation seems to say there will
never be (at least for GnuTLS).  I think this needs sorting out before
publishing an RFC which might not be implementable.

I'll ask on the library mailinglists.
-- 
Cheers,
  Jeremy

---

From: James Cloos <[email-masked]>
Date: Thu, 14 Sep 2017 12:24:34 -0400

>>>>> "JL" == John Levine <[email-masked]> writes:

JL> I haven't looked in detail at the APIs for Ed25519 crypto, but naively
JL> assumed that if the spec says there's a pure version that doesn't hash
JL> its input, the libraries would implement it.

I thought that the consensus was the opposite.  Wasn't esr demanding
that and everyone else arguing the opposite?

It is certainly the case the the "pure" version of eddsa is unlikely to
get much support by the crypto libraries.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: "John R Levine" <[email-masked]>
Date: 14 Sep 2017 20:32:52 -0400

> that and everyone else arguing the opposite?

No, that was an unrelated issue of how to publish the verification keys. 
See the WG archives.

> get much support by the crypto libraries.

That seems strange, since the difference between pure and hash is that the 
pure version just skips the hash.  But if it is really the case that it 
will be hard to find pure versions it would be silly buy harmless to 
change the spec to say that it calls the hash version of Ed25519 so it 
rehashes the hash we give it.

As far as I know rehashing a hash with a reasonable second hash function 
doesn't make it any weaker.

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, 15 Sep 2017 12:02:08 +0000

➢ As far as I know rehashing a hash with a reasonable second hash function 
    doesn't make it any weaker.
    
It does not.

Apologies to the WG, I wasn’t paying attention on this.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 15 Sep 2017 10:15:34 -0400

> As far as I can tell, this is about as done as it's going to get.

Do we really need to add both rsafp and ed25519?

I thought we had ~agreed (or at least discussed) earlier to only add ed25519 
since these new methods only work if widely deployed by both signers and 
verifiers and adding two new methods makes it less likely that either will 
achieve critical mass.

Scott K

---

From: Jim Fenton <[email-masked]>
Date: Fri, 15 Sep 2017 08:57:54 -0700

> verifiers and adding two new methods makes it less likely that either will 

+1. I don't have a strong feeling about whether we should go with rsafp
or ecc, but I don't see why we need both.

-Jim

---

From: James Cloos <[email-masked]>
Date: Fri, 15 Sep 2017 12:34:47 -0400

>>>>> "JL" == John R Levine <[email-masked]> writes:

>> get much support by the crypto libraries.

JL> That seems strange,

It is the impression I've gotten from reading the various project lists.

If I got it correct, some hardware devs recently complained about that,
too.  Something about having to send the data through the hw twice if
the hashing is part of eddsa rather than separate to it.  So protocols
seem to want to ignore the pre-hashed versions, too.  The feedback
between the two is likely a factor.

-JimC

---

From: "John Levine" <[email-masked]>
Date: 16 Sep 2017 05:15:35 -0000

>I thought we had ~agreed (or at least discussed) earlier to only add ed25519 

In July I proposed only doing EC but there was no consensus.  I would prefer
not to rerun old arguments unless we have learned something new in the meantime.

---

From: James Cloos <[email-masked]>
Date: Sat, 16 Sep 2017 08:02:13 -0400

> It is the impression I've gotten from reading the various project lists.

Nikos recently posted that he skipped pure because curdle chose to avoid it.

-JimC

---

From: Jim Fenton <[email-masked]>
Date: Mon, 18 Sep 2017 10:13:52 -0700

> not to rerun old arguments unless we have learned something new in the meantime.

I haven't found your proposal, but I asked on Jabber at the Prague
meeting whether one or the other would suffice, and repeated that
question on the list. See thread "Do we need both hashed RSA and
elliptic curves?" that begins on 21 July. There were responses from 7
people including you, and I didn't see anyone arguing that we should
have both (although it's not my place to judge consensus).

We would be doing a disservice if we require everyone to support two
ways of solving the key length problem unless there is a compelling
reason to do so.

I also support the use of elliptic curve signatures rather than rsafp.
Part of the reason is that rsafp may have IPR issues (see disclosure
3025). AFAIK EC signatures avoid this problem unless the selector DNS
record contains a hash of the public key, which shouldn't be necessary
because the key is shorter. I have no opinion on the choice of curve used.

-Jim

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 18 Sep 2017 13:31:38 -0400

On Monday, September 18, 2017 10:13:52 AM Jim Fenton wrote:
> >> I thought we had ~agreed (or at least discussed) earlier to only add
> >> ed25519> 
> > In July I proposed only doing EC but there was no consensus.  I would
> > prefer not to rerun old arguments unless we have learned something new in
> > the meantime.

Those all make sense to me.

I don't recall anyone pushing hard for retaining both and, while I agree there 
was never a formal consensus call by the chairs, it seemed like that was 
definitely the direction the group was leaning.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 24 Sep 2017 14:18:16 +0200

> Nikos recently posted that he skipped pure because curdle chose to avoid it.

Yes, that's the reply to the question Jeremy told us he was going to ask on
that list, on Sep 14:
https://lists.gnupg.org/pipermail/gnutls-help/2017-September/004387.html

My understanding is that curdle's decision is due to the fact that PureEdDSA
requires two passes over the input.  But then I didn't read the full details of
their decision (summer 2016):
https://www.ietf.org/mail-archive/web/curdle/current/msg00266.html

Dealing with generic functions, the GnuTLS manual does not expand much on why
gnutls_privkey_sign_hash [1] won't work.  It may be interesting to compare its
man page with that of nettle's ed25519_sha512_sign [2].  BTW, nettle is yet
another lib which doesn't seem to be going to implement the pre-hash variant
any time soon.

[1] GnuTLS
https://gnutls.org/manual/html_node/Abstract-key-API.html#gnutls_005fprivkey_005fsign_005fhash

[2] Nettle
https://www.lysator.liu.se/~nisse/nettle/nettle.html#EdDSA

hth
Ale