Subject: [Ietf-dkim] Thinking About DKIM and Surveillance

From: Jon Callas <[email-masked]>
Date: Wed, 2 Oct 2019 12:29:25 -0700

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Oct 2019 20:35:38 +0100

Hiya,

> Thus, any discussion of it is good. I really liked it. Please read it.

I will (but haven't yet:-).

Personally I'd advocate for implementations that regularly
cycle signing keys and publish previous private key values,
also in the DNS perhaps, or could be in some other repository.
While fancier crypto might be a more elegant way to handle
it, I'll be surprised if it gets much better than publishing
old signing keys so as to be able to disavow leaked messages.

Cheers,
S.

---

From: "Mark Delany" <[email-masked]>
Date: 2 Oct 2019 21:01:31 +0000

> publish previous private key values, also in the DNS perhaps

The private/public key swap idea is a nice simple way of creating
feasible key theft - not sure about plausible key theft. Probably for
a court to decide.

Key swap also won't offer much protection against email in archives or
backups which can be shown to have been plausibly created prior to
publishing the private key. A history of arrivals from a domain would
give a probably swap date so arguing against an archived domain might
be tough. For example using a public email service would not benefit
from this approach as many people in many places will have "archived"
signed email from that domain which would be easy to obtain.

Nonetheless I do like it as something very simple technically and
which is possibly of some benefit. There's a little administrative
dance as you need timing delays between last use and publishing to
protect emails in transit - perhaps a week or two, but otherwise it's
pretty trivial work.

What might give it more strength is if many people adopted key swap
otherwise a solitary Snowden-like operative publishing a private key
in an essentially obscure location on the Internet is unlikely to
convince a judge that security thru obscurity is ineffective. So if
private key publishing has legal plausibility value, then a standard
should strengthen that value.

Mark.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Oct 2019 22:21:02 +0100

Hiya,

> should strengthen that value.

I agree with all you say. If however, we did think it useful
to try standardise something then it'd likely be better to start
with a read of the paper Jon posted (still not done;-) and
any other relevant work. While publishing private keys is
simple and v. easy to explain, (and so far still my fav idea
for this), it might not be the best thing.

S.

---

From: Jim Fenton <[email-masked]>
Date: Wed, 2 Oct 2019 16:49:57 -0700

> 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 t…

Yes, we definitely considered privacy with respect to DKIM. But my
recollection is different: I don't remember discussion of the potential
forensic use of DKIM signatures to provide unintended non-repudiation of
leaked emails. I also wouldn't describe the presence of such signatures
on email messages to be surveillance -- although it does contribute to
the effectiveness of surveillance done by other means.

The type of surveillance we were discussing at the time was the
potential that the verification of a DKIM signature might give the
sender information on the location of the recipient (by observing the
DNS requests at the point where the key record is hosted). Use of
different selector names could also differentiate requests on behalf of
a particular target. I believe this concern was addressed by the
observation that the signature verification would typically be done by
the recipient's mail provider, and not by the recipient themselves.

I don't doubt that others (particularly Jon) thought more thoroughly
than I about privacy concerns such as this.

-Jim (who will read the article soon!)

---

From: "Mark Delany" <[email-masked]>
Date: 3 Oct 2019 00:22:39 +0000

> than I about privacy concerns such as this.

And in any event it appear some now think it's a real issue so whether
it was thought about much in the past and by who probably isn't that
material since it didn't result in any action at the time.

> -Jim (who will read the article soon!)

Ulp! Now you're gonna make us all feel guilty.

Mark.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 Oct 2019 02:11:12 +0100

Hiya,

Had a quick flick through the paper. Good work but
not something that could yet be immediately used
(which is entirely reasonable). Nonetheless it'd be
good to see work done in this space.

I do however disagree with some of the motivations
for the smarter crypto:

- The authors say: "The public key is required to
persist over disclosures:  otherwise, the frequency
of manual key updates and DNS updates would render
fine-grained disclosures inviable." ESNI is an example
that frequent (hourly) public key rotation is entirely
doable and in any case the effort required is in
publishing anything at some frequency - it makes no
difference if the value is cryptographic (like an RRSIG)
nor mostly how frequently one publishes - once the
automation is in place then you're done.

- I don't buy threat model 2 being that sensible as
one against which to focus defences. AIUI, mostly the
signatures that end up having undesirable properties
(non-repudiation) are leaked from collections. In
real-time, leaking the message content (regardless of
whether that came in email, sms, signal or whatever)
and not an email envelope seems much more likely.

- It's not clear to me there's an hierarchical IBS
scheme that could scale and that hasn't got a fatal
key escrow problem. There may be - I didn't look,
but I don't know there is. (And IBS always seem to
smell patenty, sadly.) Even if key escrow were to
somehow be considered ok, I'm not sure that the
role of key generator fits into the architecture
of email.

- section 5.1: starting out with (paraphrasing)
"replace the currently widely deployed thing"
isn't realistic

- TimeForge seems pretty complex to the point where
I can't see it happening.

In the end, I'd like to see us exploring this space
and this paper is a fine input for that exploration
but I don't see that it provides usable solutions
so far. Still a good paper though.

Cheers,
S.

On 02/10/2019 20:29, Jon Callas wrote:
> _______________________________________________
> Ietf-dkim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-dkim
>

---

From: Damon <[email-masked]>
Date: Wed, 2 Oct 2019 21:56:52 -0400

On 10/2/19 12:29 PM, Jon Callas wrote:

> >> 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.
>
> On Wed, Oct 2, 2019 at 7:50 PM Jim Fenton <[email-masked]> wrote:
>

> There were a lot of smart people looking at it and working on it and I am
absolutely sure we didn't even consider the forensic use... or if we did (I
don't remember it) I don't think a scenario was constructed by anyone that
showed it. I am also certain that if we did J would have had a lot to say
about it. ;-) But back then, and even now, this case is pretty fringe.

-Damon

---

From: Hector Santos <[email-masked]>
Date: Thu, 03 Oct 2019 11:57:55 -0400

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