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

From: Jeremy Harris <[email-masked]>
Date: Tue, 21 Nov 2017 01:11:37 +0000

On 15/09/17 01:32, John R Levine wrote:
>> 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?
> 
> No, that was an unrelated issue of how to publish the verification keys.
> See the WG archives.
> 
>> It is certainly the case the the "pure" version of eddsa is unlikely to
>> 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.

Wouldn't it be more aesthetically pleasing to decouple, for dkim
a=ed25519-sha256 signing, the hash used for the body (sha256 as
specified by the 'a' tag) from the hash used for signing headers
(sha512, I think, but whatever the libraries have tied to
Ed25519 signing)?

[I think we should specify the hash method that goes with
 the signing, too]

The hash of the headers does not appear to be used for anything
but debug output and feeding to the signing stage, at least in
the current Exim implementation of dkim signing.  Doing the
above would avoid the rehash.  Either way (this or the rehash),
Ed25519 signing is going to be different to RSA signing.
-- 
Cheers,
  Jeremy

---

From: "John Levine" <[email-masked]>
Date: 21 Nov 2017 22:03:34 -0000

Keeping in mind that you're responding to a message I wrote two months ago ...

>(sha512, I think, but whatever the libraries have tied to

No.

R's,
John

---

From: Jeremy Harris <[email-masked]>
Date: Tue, 21 Nov 2017 23:28:04 +0000

>> (sha512, I think, but whatever the libraries have tied to

I think you need to further support your position.
-- 
Jeremy

---

From: "John Levine" <[email-masked]>
Date: 22 Nov 2017 04:35:53 -0000

>I think you need to further support your position.

You might want to review some of the 100 messages posted to this list
since the one you were responding to.

R's,
John

PS: look for the ones about many libraries don't plan to provide the
pure version of ed25519, and how we agreed to deal with that.

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 22 Nov 2017 09:25:18 +0000

> pure version of ed25519, and how we agreed to deal with that.

I already did.  All assumed immediately the re-hash, once it was
accepted that we had no chance of the libraries providing a pure
signing facility.  I didn't see one that suggested that the headers
be passed in original unhashed form to the library hash-and-sign.

Is your position "it's too late, we already decided"?  You
final sentence above implies that, but perhaps I misread you.
-- 
Cheers,
  Jeremy

---

From: denis bider <[email-masked]>
Date: Wed, 22 Nov 2017 05:19:26 -0600

Jeremy,

I believe the exact thing you describe (whether to pass original headers to
the library to hash and sign) was discussed in many back-and-forths. That
is the obvious alternative to re-hash, so the entire discussion was about
that, vs. re-hash.

denis

On Wed, Nov 22, 2017 at 3:25 AM, Jeremy Harris <[email-masked]> wrote:

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

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 22 Nov 2017 11:34:20 +0000

> is the obvious alternative to re-hash, so the entire discussion was about

Ah, I must have been blind then.
My apologies for the noise.  I'll go search yet again.
-- 
Cheers,
  Jeremy

---

From: "John Levine" <[email-masked]>
Date: 22 Nov 2017 13:59:33 -0000

>be passed in original unhashed form to the library hash-and-sign.

As several people noted, passing the unhashed canonicalized headers
and body would require opening up code that was written and debugged a
decade ago, and inventing some tricky coroutine interfaces since the
string is likely to be too big to buffer in memory.

Compared to that, a second hash is a no-brainer.

R's,
John

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Nov 2017 15:05:50 +0000

Yes, the question about whether to pass the hashed content to the signing library, or whether to pass the raw headers, was discussed a great deal, and the WG decided to “sign a hash.”

Speaking as chair, let’s not re-open this issue unless there is new content to discuss.