Thanks jon for loading my plate! :) I plan to finish reading the
paper later today. Need to recall past discussions and how the paper
relates. But with initial reading, it made me recall the proposal I
wrote in 2006:
https://tools.ietf.org/html/draft-santos-dkim-rcvd-00
related to potential delayed verification timing problems with expired
and revoked keys. It served as a partial DKIM support as a migration
method for MDAs who may not yet implemented DKIM verification. Back
then, deployment was still low. Basically, a "DKIM-Received:" header
would added by the MDA.
DKIM-Received:
rt=<DKIM-timestamp>; # Current time msg was received.
sd=<selector-data>; # Selector DNS record Data.
[vt=<DKIM-timestamp>;] # Current time msg was validated.
--
HLS
On 10/2/2019 3:29 PM, Jon Callas wrote:
I know that I've written about this before, so please bear with me a bit. A
continuing concern of mine is the way that DKIM contributes to overall
surveillance smog that the Internet has.
When we designed DKIM, this was something we considered; it was a concern. It
wasn't so big a concern that we thought it should derail DKIM, and it wasn't
even a concern when it was taken over by the IETF. Nonetheless, it was an
issue, is an issue, and becomes a bigger issue nearly every day. The most
notorious failure here is the Podesta email dump, where the stolen emails were
verified against the DKIM signatures. This is precisely what we didn't want to
happen -- that DKIM was used for things beyond fighting inauthentic emails. We
ought to do something, the question is what.
When I think about how to reduce the tracking and surveillance issues, the
solution space includes: (1) Better management of the keys (e.g. lifecycle
management of some sort); (2) Better management of the emails (e.g. strip out
surveillance-friendly headers in an MDA between the MTA and MUA -- think
procmail filter that removes information leaks); (3) Better crypto. If I wave
my magic wand and can cause software to appear and be deployed, I'd do them
all. None of them are perfect. A crawler that would collect all DKIM keys would
blunt the benefits of better key management; building and deploying better
header handling is a huge task; better crypto needs an addendum to the DKIM
standard.
Nonetheless, I recently came across an interesting article, "KeyForge: Mitigating Email Breaches
with Forward-Forgeable Signatures". It's on the IACR eprint archive at
<https://eprint.iacr.org/2019/390.pdf>. I think that everyone here should look at it. The TL;DR is
that they have a signing mechanism that blunts attributable signatures and introduces some interesting
new concepts. They call it, "Delayed universal forgeability." Yes, that's vague, and it's my
point; consider that an advert for the paper. It's an interesting way to look at better crypto that
allows for spam-fighting without open-ended tracking.
I don't know that their solution is the answer, but I do know that it's asking
the right questions. In 2005-7, we were concerned about surveillance smog, but
we didn't have a good answer (or even consensus, but this was pre-Snowden). The
stated answer of the day was proper key management of keys, but it's not clear
that anyone has ever deleted a DKIM key out of DNS. (Okay, I'm exaggerating for
effect.) They have very good comments about that; I'm not sure I agree, but I
really like what they're saying. We also briefly considered some sort of ring
or group signature to blunt attribution. That a mediocre mitigation at best,
and one of our core goals was to boil the crypto down to essentials, using bare
keys rather than certs or any other uniforms for the keys. It's DKIM, not DCIM.
I think their signatures take that *intent* -- a mix of math and operation --
and creates something really worth considering. Even if it's not the answer,
the questions that we punted on in 2005 are vital for 2020 and beyond.
Thus, any discussion of it is good. I really liked it. Please read it.
Jon
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
