Subject: [Dcrup] dcrup - Requested session has been scheduled for IETF 100

From: "\"IETF Secretariat\"" <[email-masked]>
Date: Fri, 20 Oct 2017 17:24:19 -0700

Dear Murray Kucherawy,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

dcrup Session 1 (0:30:00)
    Wednesday, Morning Session I 0930-1200
    Room Name: Bras Basah size: 100
    ---------------------------------------------

Special Note: 1130-1200

Request Information:

---------------------------------------------------------
Working Group Name: DKIM Crypto Update
Area Name: Applications and Real-Time Area
Session Requester: Murray Kucherawy

Number of Sessions: 1
Length of Session(s):  30 Minutes
Number of Attendees: 20
Conflicts to Avoid: 
 First Priority: cfrg lamps jmap dmarc dispatch

People who must be present:
  Rich Salz
  Alexey Melnikov
  Murray Kucherawy

Resources Requested:

Special Requests:
  
---------------------------------------------------------

---

From: "John Levine" <[email-masked]>
Date: 21 Oct 2017 02:46:30 -0000

Can we please put my draft draft-ietf-dcrup-dkim-crypto-06 on the
agenda?

As far as I know the only significant unresolved question is whether
to use PureEdDSA or HashEdDSA as the new crypto function.  The draft
currently says the pure version, and the extra hash in the hash
version provides no benefit in our application, but people have said
that crypto libraries may not provide the pure version.

Some people keep re-asking whether we really want both new algorithms
but the answer keeps being yes, we do, because they address different
issues.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Fri, 20 Oct 2017 22:16:03 -0500

> On Oct 20, 2017, at 9:46 PM, John Levine <[email-masked]> wrote:
> 

For the record, what are the different issues?

-Jim

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 21 Oct 2017 03:32:46 +0000

>but the answer keeps being yes, we do, because they address different

That wasn't my take on the most recent discussion.  I haven't gone back and looked at the archive, but I don't recall much push for adding both.  I certainly think adding both would be a mistake though, so maybe that's just my personal bias.

I agree that the major decision on EdDSA is pure or hash.  On that, I think the choices are add hash now or defer action and wait to see if pure implementations become more common.  An extra trip through hash functions is way less important than avoiding a solution that will end up causing lots of roll your own crypto to.be used.

Scott K

---

From: "John R Levine" <[email-masked]>
Date: 20 Oct 2017 23:36:20 -0400

> For the record, what are the different issues?

Hashed RSA addresses the issue that many provisioning systems can't 
publish keys longer than about 1K bits and that's looking kind of short 
for RSA.

Ed25519 is a completely different algorithm, and happens to be faster and 
smaller.  It's there if RSA turns out to be broken at some point.

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

---

From: Jim Fenton <[email-masked]>
Date: Fri, 20 Oct 2017 22:55:44 -0500

> On Oct 20, 2017, at 10:36 PM, John R Levine <[email-masked]> wrote:
> 
> Hashed RSA addresses the issue that many provisioning systems can't publish keys longer than about 1K bits and that's looking kind of short for RSA.
> 
> Ed25519 is a completely different algorithm, and happens to be faster and smaller.  It's there if RSA turns out to be broken at some point.

When you put it that way, faster and smaller sounds better. It also addresses the key length issue because it uses shorter public keys. So what’s the motivation for doing hashed RSA as well?

-Jim

---

From: "John R Levine" <[email-masked]>
Date: 21 Oct 2017 00:09:47 -0400

> When you put it that way, faster and smaller sounds better. It also addresses the key length issue because it uses shorter public keys. So what’s the motivation for doing hashed RSA as well?

Some people seem to like RSA.

Regards,

---

From: Jim Fenton <[email-masked]>
Date: Fri, 20 Oct 2017 23:22:07 -0500

> Some people seem to like RSA.

That’s a very weak argument.

It sounds like Scott Kitterman also feels this is not a settled issue, so going back to the origin of this thread, I request that the chairs agendize a discussion on the need for both algorithms.

-Jim

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 21 Oct 2017 12:16:24 +0000

>    It sounds like Scott Kitterman also feels this is not a settled issue, so going back to the origin of this thread, I request that the chairs agendize a discussion on the need for both algorithms.
    
Agendize?

Anyhow, yes.

---

From: Kurt Andersen <[email-masked]>
Date: Sat, 21 Oct 2017 05:38:40 -0700

On Fri, Oct 20, 2017 at 8:36 PM, John R Levine <[email-masked]> wrote:

> publish keys longer than about 1K bits and that's looking kind of short for
> RSA.
>
> <https://www.ietf.org/mailman/listinfo/dcrup>
>

I thought that the "different algorithms" question was regarding Pure
Ed25519 vs. Hashed Ed25519 which is a question about double hashing.

--Kurt

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 21 Oct 2017 17:09:17 +0200

On Sat 21/Oct/2017 05:32:46 +0200 Scott Kitterman wrote:
> I agree that the major decision on EdDSA is pure or hash.  On that, I think
> the choices are add hash now or defer action and wait to see if pure
> implementations become more common.  An extra trip through hash functions is
> way less important than avoiding a solution that will end up causing lots of
> roll your own crypto to.be used.
The choice can also lie between pure and hash.  Well, sort of.  For example, we
can use a (4K - 256) byte buffer to be filled with canonicalized text, while
any exceeding text will be compressed in a 256 byte hash.  Next, the resulting
4K-or-less buffer is passed to gnutls_privkey_sign_data() or whatever the
signing function.

By passing a fair amount of "pure" text, we enjoy a fair amount of resilience
to hash-collisions —one of the feathers in EdDSA's cap.  Plain double hashing
misses that feature.  Yet, we're not maddening implementors by requiring an
indefinite-size buffer.  I said 4K as it is not more than the page size on most
systems, but we can also specify a varying size, e.g. by specifying a tag like
buf=4096.  A system's policy may refuse to verify signatures that require an
overly large buffer, and send aggregate reports with a suitable policy override
reason.

jm2c
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 21 Oct 2017 12:09:16 -0400

On Sat, 21 Oct 2017, Kurt Andersen wrote:
>> publish keys longer than about 1K bits and that's looking kind of short for RSA.
>>

No, as you can see we're still refighting RSA vs. elliptic.

Regards,

---

From: "John Levine" <[email-masked]>
Date: 21 Oct 2017 16:46:30 -0000

In article <[email-masked]> you write:
>The choice can also lie between pure and hash.  Well, sort of. ...

Really, no, it can't.  There are two defined variants for eddsa
PureEdDSA and HashEdDSA, and we already have a defined way to create
the DKIM message hash.  I have no interest in implementing yet another
nonstantard mutant version and I doubt anyone else does either.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 21 Oct 2017 17:13:27 +0000

>nonstantard mutant version and I doubt anyone else does either.

+1. Most definitely not.

Scott K

---

From: James Cloos <[email-masked]>
Date: Sun, 22 Oct 2017 01:55:09 -0400

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

JL> I have no interest in implementing yet another nonstantard mutant
JL> version and I doubt anyone else does either.

There is nothing mutant about it.  Just send whatever would go to a hash
function directly to eddsa.

Simple as can be.

Given the (highly) likely lack of library support for pureeddsa, doing
otherwise is unreasonable.

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

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 22 Oct 2017 12:26:30 +0200

On Sat 21/Oct/2017 18:46:30 +0200 someone wrote:
> 
> There are two defined variants for eddsa PureEdDSA and HashEdDSA, and we
> already have a defined way to create the DKIM message hash.

DKIM has a defined way to create a sha256 hash, which suits RSA signatures
pretty well, but is not what section 4 of rfc8032 specifies.  Ed25519
signatures customarily use a different hashing, so as to achieve collision
resistance.  In their "Security notes on prehashing"[*] the authors conclude as
follows:

    The main motivation for HashEdDSA is the following storage issue (which is
    irrelevant to most well-designed signature applications).  Computing the
    PureEdDSA signature of M requires reading through M twice from a buffer as
    long as M, and therefore does not support a small-memory “Init-Update-
    Final” interface for long messages.  Every common hash function H'
    supports a small-memory “Init-Update-Final” interface for long
    messages, so H'-EdDSA signing also supports a small-memory “Init-
    Update-Final” interface for long messages.  Beware, however, that analogous
    streaming of verification for long messages means that verifiers
    pass along forged packets from attackers, so it is safest for
    protocol designers to split long messages into short messages to
    be signed; this splitting also eliminates the storage issue.
                                    http://ed25519.cr.yp.to/eddsa-20150704.pdf

Ciao
Ale
--

---

From: Jeremy Harris <[email-masked]>
Date: Sun, 22 Oct 2017 13:33:57 +0100

On 22/10/17 11:26, Alessandro Vesely wrote:
>     Update-Final” interface for long messages.

That storage amount would be bounded by the size of the hash fed to
PureEdDSA in the DKIM case.  So the suggestion that it is unwise does
not apply to this use-case.

As alternate, could we ask that the libraries doing HashEdDSA make the
intermediate hash available?
-- 
Cheers,
  Jeremy

---

From: "John R Levine" <[email-masked]>
Date: 22 Oct 2017 10:05:18 -0400

> function directly to eddsa.

This is exactly what we do *not* want to do.  We debugged the DKIM 
canonicalization and hashing code a decade ago, and have no interest in 
rewriting it.

> otherwise is unreasonable.

If you'll review the messages to which you were responding, you'll find 
that the plan is to feed the DKIM hash into HashEdDSA since a rehash won't 
make anything worse other than a tiny slowdown.

R's,
John

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 22 Oct 2017 15:30:36 +0000

Right.  So the signed data is a hash.

Most crypto libraries (including the one I work on, OpenSSL) have a start/digest/end-with-sig API.  When all this was (er) hashed over in CFRG, we decided consistency of API was better.  Yes this meant everyone had to have the original content. IoT devices and long CRL’s were brought up, and it was decided that this is not a use-case to worry about.

So I think standard EdDSA hashing of DKIM data that is a hash of specially-canonicalized data makes sense.  I agree the cost of an “extra” hash isn’t worth worry about, especially when the input is a hash, the cost of the key operations will completely dominate.

Speaking as an individual.  But speaking as co-chair: Does this make sense?

---

From: "John Levine" <[email-masked]>
Date: 22 Oct 2017 15:30:41 -0000

>intermediate hash available?

We could ask, but since the reason we're having this discussion is
that we expect them not to implement PureEdDSA which is part of the
RFC 8032 spec, it seems vanishingly unlikely that they would add yet
another non-standard interface of no interest to anyone else.

I would be interested to hear exactly what security or performance
problems people think would be introduced by using HashEdDsa on the
existing hash.  The existing hash can't be that bad since we seem
perfecly happy to keep using it with RSA.

R's,
John

PS:  "You could do this instead" is not, to the best of my knowledge,
a security or performance problem.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 22 Oct 2017 15:54:16 +0000

On October 22, 2017 11:30:36 AM EDT, "Salz, Rich" <[email-masked]> wrote:
>Most crypto libraries (including the one I work on, OpenSSL) have a
>start/digest/end-with-sig API.  When all this was (er) hashed over in
>CFRG, we decided consistency of API was better.  Yes this meant
>everyone had to have the original content. IoT devices and long CRL’s
>were brought up, and it was decided that this is not a use-case to
>worry about.
>
>So I think standard EdDSA hashing of DKIM data that is a hash of
>specially-canonicalized data makes sense.  I agree the cost of an
>“extra” hash isn’t worth worry about, especially when the input is a
>hash, the cost of the key operations will completely dominate.
>

I think it does.

Scott K

---

From: James Cloos <[email-masked]>
Date: Mon, 23 Oct 2017 17:15:23 -0400

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

>> There is nothing mutant about it.  Just send whatever would go to a
>> hash function directly to eddsa.

JL> This is exactly what we do *not* want to do.

How can c(m) *ever* be harder than a(b(m))?

The objection really makes no sense.

All doing it right means is that you get a signed hash instead of
a to-be-signed hash out of the hashing step.

It is of course not a performance issue.

And if the consensus is to double then so be it,
but it had to be mentioned.

-JimC

---

From: "John R Levine" <[email-masked]>
Date: 23 Oct 2017 17:25:21 -0400

> How can c(m) *ever* be harder than a(b(m))?

When a() and b() are existing, debugged, documented code, and c() is not, 
it happens all the time.

As you note, the performance difference is insignificant.

Regards,

---

From: James Cloos <[email-masked]>
Date: Tue, 24 Oct 2017 16:12:27 -0400

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

JRL> When a() and b() are existing, debugged, documented code, and c() is
JRL> not, it happens all the time.

But c() is eddsa(), so you can't call it undebugged or undocumented.

-JimC

---

From: "John R Levine" <[email-masked]>
Date: 24 Oct 2017 16:30:06 -0400

> But c() is eddsa(), so you can't call it undebugged or undocumented.

Sorry, this is hopeless.  If it's not self-evident why we want to use 
existing DKIM routines that produce a short fixed-length hash rather than 
tearing the libraries apart to invent new interfaces that produce variable 
length text, potentially very long text so it'd need some kind of 
coroutine to produce it in chunks, I don't think I can help.

Regards,

---

From: denis bider <[email-masked]>
Date: Tue, 24 Oct 2017 17:54:22 -0500

I'd like to support John Levine here with a +1. Just because "c" is EdDSA,
doesn't mean it can be easily pulled into existing implementations. Doing
c() instead of a(b()) complicated implementation by an order of magnitude
for the savings of one hash.

On Tue, Oct 24, 2017 at 3:30 PM, John R Levine <[email-masked]> wrote:

> length text, potentially very long text so it'd need some kind of coroutine
> to produce it in chunks, I don't think I can help.
>
> Regards,
> _______________________________________________
> Dcrup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrup
>

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Oct 2017 00:16:45 +0000

Yes.  Absolutely.  There are only two realistic choices:

HashEdDSA now

Wait and see if PureEdDSA gets implementation traction.

My preference is the first one, but either is incomparably better than inventing something new.

Scott K

On October 24, 2017 3:54:22 PM PDT, denis bider <[email-masked]> wrote:
>coroutine

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 27 Oct 2017 13:37:11 +0200

On Tue 24/Oct/2017 22:30:06 +0200 someone wrote:
> Sorry, this is hopeless.  If it's not self-evident why we want to use existing
> DKIM routines that produce a short fixed-length hash rather than tearing the
> libraries apart to invent new interfaces that produce variable length text,
> potentially very long text so it'd need some kind of coroutine to produce it in
> chunks, I don't think I can help.

What is not self-evident is a(b()) == c().  I'm less of a crypto expert than
you, but I suspect there's a reason why Schnorr signatures have different hash
function requirements than RSA.  At a minimum, DKIM should use sha-512,
according to draft-ietf-curdle-cms-eddsa-signatures, which is different from
a(b()) already.

Ale
--