Subject: Re: [dispatch] Updating DKIM for stronger crypto

From: Martin Thomson <[email-masked]>
Date: Tue, 21 Mar 2017 14:32:25 +1100

On 11 February 2017 at 07:50, Cullen Jennings <[email-masked]> wrote:
>
> The Chairs and ADs discussed this today and we plan to allocate some agenda time for it at IETF 98. At the meeting we can try and figure out best way to dispatch this.

I notice that this is on the agenda as simply "DKIM" and all we have
is "brief summary of problem - 10 min (John)", which took me a while
to latch on to.  "Update DKIM Crypto" would be a better title, and
John's full name would further help people reading the agenda.  If
nothing else, this email should help people find this thread again.

If I can summarize where I think this left off, we have a desire to
improve the strength of the cryptographic algorithms used in DKIM.  No
one seemed to object to that, but two options came out:

1. Define use of Ed25519
2. Define a modified RSA signature scheme where Sign(k, X) is defined
as K || Sign-RSA(k, X) and Verify(H, K || M) is Hash(K) == H &&
Verify-RSA(K, M)

A third option seems plausible as well: do both and let the market
decide.  I'd be surprised if either were a massive specification
effort.

In looking at this, we should probably dispatch this cross-area to
CURDLE.  It might require re-chartering (DKIM isn't explicitly
mentioned), but it's a small change.  CURDLE might be naturally
predisposed to favour the option 1, but I'm sure that the ultimate
decision might simply depend on whoever is willing to do the work.

---

From: "John R Levine" <[email-masked]>
Date: 21 Mar 2017 00:01:46 -0400

> as K || Sign-RSA(k, X) and Verify(H, K || M) is Hash(K) == H &&

Yup, either or both.

> CURDLE.

Please, no.  There's nothing interesting about the choice of algorithms, 
only about how to update the DKIM spec to say what to do.

R's,
John

---

From: Martin Thomson <[email-masked]>
Date: Tue, 21 Mar 2017 19:51:17 +1100

On 21 Mar. 2017 15:01, "John R Levine" <[email-masked]> wrote:

That doesn't seem like a good reason. I just spent a few minutes with RFC
6376 and it seems obvious that the changes required are minimal as long as
you can conform to the well-established signing API that everyone -
including DKIM - uses. You write a new draft that defines a new codepoint
and the algorithms that the codepoint represents and that is it.

That describes exactly what CURDLE does.  Frankly, the process is pretty
mechanical, if you want to pad a resume with RFCs, it is a good way to get
started.

If there is some way in which DKIM really *is* special despite outward
appearances, I'd be very interested in hearing about it. Requiring a small
public key representation isn't especially interesting or challenging.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Mar 2017 08:52:17 +0000

Hiya,

On 21/03/17 03:32, Martin Thomson wrote:
>> The Chairs and ADs discussed this today and we plan to allocate
>> some agenda time for it at IETF 98. At the meeting we can try and
>> figure out best way to dispatch this.
> 
> improve the strength of the cryptographic algorithms used in DKIM.
> No one seemed to object to that, but two options came out:
> 
> 1. Define use of Ed25519 
> 2. Define a modified RSA signature scheme
> where Sign(k, X) is defined as K || Sign-RSA(k, X) and Verify(H, K ||
> M) is Hash(K) == H && Verify-RSA(K, M)
> 

Hmm... WRT #2: I'd be against the idea of defining a mechanism at
that level without significant input from CFRG as it'd be re-used
if defined at that level so would need some analysis. I guess the
idea in #2 is publishing a hashed key in the DNS DKIM key record
instead of the key itself and of including the public key in a
mail header field, which is a little different (and less scary:-)
to how the above is presented.

> decide.  I'd be surprised if either were a massive specification 

I'm not sure letting the market decide here would be a good
plan TBH, and I don't think ease of specification ought be
a primary consideration.

> decision might simply depend on whoever is willing to do the work.

"Ask curdle" does seem like a reasonable approach, but I'd still
think it'd be worth considering the topic in dispatch first to get
a sense of desired direction, as I don't think those who would
write or deploy updated DKIM code tend to participate in curdle
today. So first, it'd be good to find out if there's a real
appetite/need for updated crypto, or if it's just a nice thing
that could be done but that'd not see deployment.

Separately, I'd like to raise a different idea wrt DKIM. I don't
expect it'll get traction, but no harm to at least raise it here
to check...

DKIM defines signatures so that a bad or missing signature are
treated the same. The expectation in doing that was that DKIM
signatures would be ephemeral things, and that public keys might
be fairly often replaced using the selector mechanism. Last year,
we learned that DKIM signatures can survive exfiltration and
other subsequent steps leading to publication via wikileaks and
that the same public keys allowing verification were still in use.

That was surprising, for me at least. So I wonder if there's any
interest in further considering key rollovers in DKIM, and if
there's even interest in defining a scheme where old private keys
are published, as a means to improve deniability when caches of old
emails are subsequently leaked/published. Again, I'd be surprised
if this got traction, so I'm not asking for time on the agenda
unless the idea has resonated with folks on the list first. (It
may also be that I just like the unexpected cuteness of there
being potential utility in publishing private signature keys;-)

There was a brief thread on the DKIM list about this a while
back where the above and a couple of other ideas were mentioned
without any of them attracting much interest. [1]

Cheers,
S.

[1] http://mipassoc.org/pipermail/ietf-dkim/2016q4/017197.html

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Mar 2017 05:19:16 -0700

> to how the above is presented.

Yes. I only described it this way in the interest of explaining how
implementations
could be updated easily. Note that I have no particular axe to grind in
favor of
RSA, but to the extent to which your problem with RSA is merely the size of
the key in the DNS, then this is the minimal change. In fact, I would argue
that if you're going to bother to update the specs at all, you should stuff
the hash in the DNS, not the key.

> that could be done but that'd not see deployment.

I am fine with this being DISPATCHed to CURDLE. Less fine with it being
DISPATCHed to RFC.

-Ekr

> _______________________________________________
> dispatch mailing list
> [email-masked]

---

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

> Note that I have no particular axe to grind in favor of

Given the difficulty of opening up specs, if we're going to do anything 
I'd like to both add the new algorithm and the option to publish key 
hashes.

>> Last year, we learned that DKIM signatures can survive exfiltration and 
>> other subsequent steps leading to publication via wikileaks and that 
>> the same public keys allowing verification were still in use.

This wasn't a surprise to people in the mail ops community.  Most signers, 
even big ones, never rotate their keys, so if you can find an old message, 
you can probably validate it.  Even for people like me who do rotate, 
large passive DNS databases probably have the old keys.  Also, it is my 
recollection that the signatures weren't so much ephemeral as that they 
were expected to be checked fairly soon after signing so long-term 
security wasn't part of the model.

If someone wanted to write something about key lifetimes with a way to 
poison keys by publishing them, that would be OK with me but I wouldn't 
want to put it into the DKIM spec.  Currently it offers no advice on key 
rotation beyond noting that it's possible, and no useful advice on key 
sizes.

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Mar 2017 14:32:58 +0000

> rotation beyond noting that it's possible, and no useful advice on key

Fully agree - were this to be done it ought be in it's
own document. Personally, I'd be willing to help with it,
but only if someone was likely to use it. (And so far,
nobody is afaik.)

S.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Mar 2017 13:12:27 +1100

On 22 March 2017 at 01:05, John R Levine <[email-masked]> wrote:
> Given the difficulty of opening up specs, if we're going to do anything I'd
> like to both add the new algorithm and the option to publish key hashes.

This sounds fine, though I'd disagree with the premise.  I'm sure that
you can write an extension specification that doesn't even have to
update DKIM.  It just says, you can implement this in addition to DKIM
and it makes the keys bigger and better.

---

From: "John Levine" <[email-masked]>
Date: 22 Mar 2017 02:31:33 -0000

>and it makes the keys bigger and better.

I suppose but it wouldn't make much sense.  We designed DKIM so we can add
new hashes and signing algorithms.

R's,
John

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Mar 2017 13:38:06 +1100

On 22 March 2017 at 13:31, John Levine <[email-masked]> wrote:
> We designed DKIM so we can add

Precisely my point.  If that was successful (and it seems like it is
at least on face value), then a new signing algorithm could be done by
basically anyone.

---

From: "John R Levine" <[email-masked]>
Date: 21 Mar 2017 23:05:51 -0400

> at least on face value), then a new signing algorithm could be done by

Of course, but if the signers and verifiers don't agree on how the 
algorithm is represented in signatures and keys, it won't be very useful.

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

---

From: Wei Chuang <[email-masked]>
Date: Thu, 23 Mar 2017 08:57:25 -0700

I think we (Gmail) would be interested in having this update get published.

-Wei