Re: [dispatch] Updating DKIM for stronger crypto

[Eric Rescorla <[e-mail]>]

On Tue, Mar 21, 2017 at 1:52 AM, Stephen Farrell <[e-mail]>
wrote:

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

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.



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

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

-Ekr


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