Re: [dispatch] Updating DKIM for stronger crypto

[Stephen Farrell <[e-mail]>]

Hiya,

On 21/03/17 03:32, Martin Thomson wrote:
> On 11 February 2017 at 07:50, Cullen Jennings <[e-mail]> 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)
> 

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.

> 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.

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.

> 
> 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.

"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 [e-mail] 
> https://www.ietf.org/mailman/listinfo/dispatch
>