Subject: [Dcrup] Do we need both hashed RSA and elliptic curves?

From: Jim Fenton <[email-masked]>
Date: Fri, 21 Jul 2017 14:18:31 -0700

This is a repeat of a question I asked via Jabber in the WG meeting
yesterday, and didn't get much response probably because I worded it
tersely for Jabber and couldn't expand on the question easily.

At the outset of this WG's formation, it was noted that there are two
approaches to the problem with DNS record length with large RSA keys:
(1) hash the keys, put the public key into the message and the hash in
DNS; and (2) use a different algorithm such as elliptic curve that has
shorter public keys.

In the discussion about supporting both hashed and unhashed keys
(particularly the question of whether to hash the elliptic curve keys as
well), John Levine said:

"Since there is no negotiation between the sender and the receiver, a
receiver must implement every possible crypto scheme that any sender
might use to interoperate. I would rather minimize the number of schemes
and just add two rather than three."

I agree with John that keeping the number of schemes to a minimum is
good. Given that (1) and (2) above solve the same problem, why do we
have both in draft-ietf-dcrup-dkim-crypto? Shouldn't we pick one or the
other, or are there good reasons for some signers to use hashed RSA and
others to use EC?

-Jim

---

From: denis bider <[email-masked]>
Date: Fri, 21 Jul 2017 15:57:30 -0600

I agree. Every algorithm added is:

- an incremental improvement in options available to some senders, but

- a substantial increase in cost for ALL receivers.

If it's possible to address the needs of senders by adding only one of
RSA-FP or EC, but not both, that would be welcome for implementers of
receivers.

On Fri, Jul 21, 2017 at 3:18 PM, Jim Fenton <[email-masked]> wrote:

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

---

From: Brandon Long <[email-masked]>
Date: Fri, 21 Jul 2017 15:56:22 -0700

Although I'm leaning towards agreeing with only adding one of these, I
disagree this is a substantial cost for
ALL receivers.

In reality, there are likely <20 implementations, and although it's an
increase in cost for the implementations,
it's not a heavy one.

For receivers, the cost is going to be in upgrading, which is required if
they want to support any new algorithms,
regardless of how much new functionality is in that upgrade.

Perhaps the increased cost of updating implementations will lead to some
implementations not being updated,
which means receivers would have to switch implementations, which is a
higher cost than a simpler upgrade...
but second order effects are going to be much smaller anyways.

Also, if we're voting on choosing, I'd go with adding EC, as I feel that
allowing different algorithms makes
DKIM more robust in the face of the possibility of a breakthrough against
an existing algorithm.

Brandon

---

From: denis bider <[email-masked]>
Date: Fri, 21 Jul 2017 17:24:26 -0600

Only 20 implementations for DKIM...?

Email, as we know it, is on the order of 40 years old. I would be very
surprised if it has anything short of hundreds of implementations.

Many of those implementations support DKIM, and more will do so in the
future.

If we want to one day be able to assume that DKIM is supported universally,
it needs to be supported not just by major providers of email-as-a-service,
and major publishers of email software; but also by the long tail.

The long tail involves a large number of diverse implementations, many of
them using obscure software.

I would estimate, if we want to be able to assume DKIM is universal, the
number of implementations needs to be closer to 100.

That's a lot of receivers...

---

From: "A. Schulze" <[email-masked]>
Date: Sat, 22 Jul 2017 10:48:13 +0200

> DNS; and (2) use a different algorithm such as elliptic curve that has

as DNS operator I prefer any mechanism that result in less DNS response sizes.
as DKIM user I MUST wait if any new mechanism will be implemented some day.

hashed RSA
  + smaller DNS response
  - no new algorithm
  - need to wait until software is updated
  - public key location change from dns -> every message

unhashed EC Keys
  + smaller DNS response
  + new algorithm
  - need to wait until software is updated
  + public key stay in DNS only

for me there are more + on unhashed elliptic curves.
But I'm aware of Ekr's "Hash everything" that make me still a little bit uncertain.

hashed EC Keys
  + smaller DNS response
  + new algorithm
  - need to wait until software is updated
  - public key location change from dns -> every message
(+) Ekr is happy

I'm sure, in neither case we need both.

Andreas

---

From: "John Levine" <[email-masked]>
Date: 22 Jul 2017 14:37:18 -0000

In article <[email-masked]> you write:
>-=-=-=-=-=-
>surprised if it has anything short of hundreds of implementations. ...

>them using obscure software.

I agree with Brandon: there are not a lot of DKIM libraries.  I use an
MTA you probably never heard of called Mailfront, but my DKIM plugin
uses the same OpenDKIM library that Postfix and many other MTAs do.
When OpenDKIM is upgraded, I get the new stuff it handles
automagically.

By the way, if we have to pick one, I'd pick EC because it's a lot
faster, as well as having smaller keys.  Its main disadvantage at this
point is that it's only partly integrated into the usual crypto
libraries (of which there are about three), but I expect that to be
fixed pretty soon.

R's,
John

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 22 Jul 2017 17:56:28 +0000

> in draft-ietf-dcrup-dkim-crypto? Shouldn't we pick one or the other, or are
> there good reasons for some signers to use hashed RSA and others to use
> EC?

The cost of computation of EC is significantly smaller.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Sat, 22 Jul 2017 21:27:20 +0200

On 22-07-17 00:56, Brandon Long wrote:
> For receivers, the cost is going to be in upgrading, which is required 
> if they want to support any new algorithms,
> Perhaps the increased cost of updating implementations will lead to 
> some implementations not being updated,
> Also, if we're voting on choosing, I'd go with adding EC, as I feel 
> that allowing different algorithms makes
> DKIM more robust in the face of the possibility of a breakthrough 
> against an existing algorithm.

Except when this breakthrough would be a breakthrough in Quantum 
Computing, as QC is likely to break ECC sooner than RSA, as was argued 
earlier this week by Kenny Paterson [1]. Having said that, I do think 
adding only EC is preferred, as it prevents the overhead of sending the 
public key, while leaving the domain owners a choice.

/rolf

[1] 
https://www.ietf.org/proceedings/99/slides/slides-99-saag-post-quantum-cryptography-01.pdf

---

From: Seth Blank <[email-masked]>
Date: Mon, 24 Jul 2017 10:52:43 +0200

> libraries (of which there are about three), but I expect that to be

I concur with John