Subject: [ietf-dkim] DKIM Key Sizes

From: Peter Goldstein <[email-masked]>
Date: Thu, 27 Oct 2016 10:29:35 +0200

Hi Everyone,

During a discussion about the ARC protocol yesterday the question of
appropriate key sizes came up.  The ARC proposal simply adopts the
guidelines for signing keys as laid out in RFC 6376.

Those guidelines are in section 3.3.3 of RFC 6376 (
https://tools.ietf.org/html/rfc6376#section-3.3.3).  They specify that
receivers MUST validate signatures of 512 to 2048 bits, but are not
required to validate signatures with longer keys - may be worth revisiting
given advances in computing power, the increasing importance of DKIM as an
element of email authentication, and the reuse of these guidelines in other
proposals (i.e. ARC).

I'd like to suggest that it may be a good idea to increase the upper value
to 4096 or even 8192, to ensure that the standard is compatible with best
practices going forward.

Some motivations for revisiting the key size requirements are:

   - 2048-bit keys are starting to become more common, with at least one
   large sender (GSuite by Google) defaulting to 2048 bit keys.
   - The TXT records for most 2048-bit keys exceed 512 bytes, so mandatory
   support for 2048-bit keys already requires receivers and senders to support
   EDNS or TCP fallback for DNS.  An increase to 4096 (or even 8192) bits will
   not change the required level of DNS support
   - While key rotation can somewhat mitigate the security risks of using a
   smaller key, in practice most real-world DKIM key implementations have not
   made such rotation part of their systems, and hence in-practice the
   mitigation is minimal
   - The extension of these guidelines via ARC to forwarders, mailing
   lists, etc. that are even more likely to keep their keys unchanged for long
   periods of time.

Is there any interest in the group to discuss this question and how we may
be able to improve the current guidelines?

Thanks.

Best,

Peter
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jon Callas <[email-masked]>
Date: Thu, 27 Oct 2016 15:29:26 -0700

> On Oct 27, 2016, at 1:29 AM, Peter Goldstein <[email-masked]> wrote:
> 
> Those guidelines ... specify that receivers MUST validate signatures of 512 to 2048 bits, but are not required to validate signatures with longer keys - may be worth revisiting given advances in computing power, the increasing importance of DKIM as an element of email authentication, and the reuse of these guidelines in other proposals (i.e. ARC).
>  

[...]

> I'd like to suggest that it may be a good idea to increase the upper value to 4096 or even 8192, to ensure that the standard is compatible with best practices going forward.

I don't object to increasing it in the standard, but operationally I don't think it's a good idea. Per-message processing cost is one reason, but the larger one is the semantic value of a DKIM signature, and what it is trying to do.

DKIM is a conversation between two administrative domains, and a signature only states that an administrative domain is taking responsibility for placing the message in the message stream. Nothing more. 

That assurance comes at a cost of whatever integrity that assigns to a message that might have been unintended. That message integrity is a privacy loss by the users.

The real-world case in point is the leaked Podesta emails, where some people have asserted that authenticity can be checked via the DKIM signatures. I've raised an eyebrow on that, and the bottom line is that you're presuming that attackers were sophisticated enough to steal the email, yet unsophisticated enough that stealing the DKIM key from an MTA is out of the question.

The full discussion is pretty nuanced, and I think the relevant part here is that if an administrative domain wants to protect the privacy of its users, it should be using *smaller* DKIM keys, not larger ones. I think I could convincingly argue that a privacy-friendly email provider is better off using 512 bit keys (where there's a chance of spam forgery) than 4K keys (where there's a chance of ruining the privacy of the customers). Now actually, I think the sweet spot for key size is above 512, but it's lower than 768. For maximum balance, you want the key to take longer than a week to crack, but less than a year, and change it every month. Or something like that. You get the idea.

In any event, I don't object to changing it, but I do think that if someone's going to implement long keys, they're going to get criticism about enabling surveillance of their users.

	Jon

---

From: Jon Callas <[email-masked]>
Date: Thu, 27 Oct 2016 22:35:27 -0700

> On Oct 27, 2016, at 9:55 PM, Dave Crocker <[email-masked]> wrote:
> 
> On 10/28/2016 12:29 AM, Jon Callas wrote:
>> The full discussion is pretty nuanced, and I think the relevant part here is that if an administrative domain wants to protect the privacy of its users, it should be using *smaller* DKIM keys, not larger ones. I think I could convincingly argue that a privacy-friendly email provider is better off using 512 bit keys (where there's a chance of spam forgery) than 4K keys (where there's a chance of ruining the privacy of the customers).
> 
> 
> Not just nuanced, but also counter-intuitive (at least to me)
> 
> It would be well worth having a stable pointer to a discussion that lays this out carefully and compellingly.

Okay. How should I do that?

	Jon

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 28 Oct 2016 11:06:34 +0100

Hi Jon,

On 27/10/16 23:29, Jon Callas wrote:
>> Those guidelines ... specify that receivers MUST validate
>> signatures of 512 to 2048 bits, but are not required to validate
>> signatures with longer keys - may be worth revisiting given
>> advances in computing power, the increasing importance of DKIM as
>> an element of email authentication, and the reuse of these
>> guidelines in other proposals (i.e. ARC).
> 
> 
> [...]
> 
>> I'd like to suggest that it may be a good idea to increase the
>> upper value to 4096 or even 8192, to ensure that the standard is
>> compatible with best practices going forward.
> 
> I don't object to increasing it in the standard, but operationally I
> don't think it's a good idea. Per-message processing cost is one
> reason, but the larger one is the semantic value of a DKIM signature,
> and what it is trying to do.
> 
> DKIM is a conversation between two administrative domains, and a
> signature only states that an administrative domain is taking
> responsibility for placing the message in the message stream. Nothing
> more.
> 
> That assurance comes at a cost of whatever integrity that assigns to
> a message that might have been unintended. That message integrity is
> a privacy loss by the users.
> 
> The real-world case in point is the leaked Podesta emails, where some
> people have asserted that authenticity can be checked via the DKIM
> signatures. I've raised an eyebrow on that, and the bottom line is
> that you're presuming that attackers were sophisticated enough to
> steal the email, yet unsophisticated enough that stealing the DKIM
> key from an MTA is out of the question.
> 
> The full discussion is pretty nuanced, and I think the relevant part
> here is that if an administrative domain wants to protect the privacy
> of its users, it should be using *smaller* DKIM keys, not larger
> ones. I think I could convincingly argue that a privacy-friendly
> email provider is better off using 512 bit keys (where there's a
> chance of spam forgery) than 4K keys (where there's a chance of
> ruining the privacy of the customers). Now actually, I think the
> sweet spot for key size is above 512, but it's lower than 768. For
> maximum balance, you want the key to take longer than a week to
> crack, but less than a year, and change it every month. Or something
> like that. You get the idea.

Ick.

I think the property you're aiming for is to not damage
deniability? If not, then can you explain.

I don't think a just-about-dodgy-rsa-length is a good
way to try get that because:

- it's extremely algorithm specific - other algs don't
have similar properties (and it'd be a horribly bad idea
to define 'em)

- it'd be vulnerable to an actual factorisation during
the operational lifetime of a key pair, which is not a
thing we can easily evaluate (more or less damage to
whom overall?)

- no matter that the semantics of a DKIM signature are
well defined to (try to) not damage deniability, we
can't stop people from associating other semantics with
signatures, of any length - IOW, so long as the factorisation
of a modulus isn't known, deniability is damaged

The only up-side of your suggestion I can see is that
it would keep some bad actors busy.

Instead, I'd point out that this can be handled, even now,
by simply rolling to a new key and then shortly publishing
the private key used to sign the messages. That way Podesta
could deny the content once more, at least at the crypto
level.

Whether or not publishing private keys would be something
that the community would do is a fine question, but it'd be
a better approach. (I forget, and didn't look back to see,
if someone suggested this before for DKIM, I think I recall
that someone may have though.)

Releasing the private key when you're done with it, is also
nicely algorithm independent so if we wanted to take that
route that would not prevent us moving DKIM to eddsa to get
the nice benefits that offers over RSA.

I could imagine us writing an RFC about why and how to do
DKIM signature key rollover and private key publication and
would be happy to help if there were a chance it'd get some
traction.

Cheers,
S.

> 
> In any event, I don't object to changing it, but I do think that if
> someone's going to implement long keys, they're going to get
> criticism about enabling surveillance of their users.
> 
> Jon
> 
> 
> 
> _______________________________________________ NOTE WELL: This list
> operates according to http://mipassoc.org/dkim/ietf-list-rules.html
>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 28 Oct 2016 14:02:38 +0200

Hi Jon,

On 10/28/16 12:29 AM, Jon Callas wrote:
>
> > I'd like to suggest that it may be a good idea to increase the upper
> value to 4096 or even 8192, to ensure that the standard is compatible
> with best practices going forward.
>

I really don't get your point.  Either the thing is worth signing or it
isn’t.  See below.
>
> That assurance comes at a cost of whatever integrity that assigns to a
> message that might have been unintended. That message integrity is a
> privacy loss by the users.
>
> steal the email, yet unsophisticated enough that stealing the DKIM key
> from an MTA is out of the question.

If it’s the same conversation I was engaged in, I think the person was
just confused.  A simpler approach to plausible deniability is simply
not to sign.  And further, just because a person can hack someone’s
personal message store, as seems to have happened to Podesta, doesn’t
mean that they can hack the private key out of Google.  Furthermore,
using the example above, the key would actually have to be around for a
while (e.g., not rotate out of DNS).  In fact, if the key really is
intended to verify the source over a longer period of time than, say,
delivery, certainly 512 is not enough.

> of its users, it should be using *smaller* DKIM keys, not larger ones.
> I think I could convincingly argue that a privacy-friendly email
> provider is better off using 512 bit keys (where there's a chance of
> spam forgery) than 4K keys (where there's a chance of ruining the
> privacy of the customers). Now actually, I think the sweet spot for
> key size is above 512, but it's lower than 768. For maximum balance,
> you want the key to take longer than a week to crack, but less than a
> year, and change it every month. Or something like that. You get the idea.

Color me obtuse, but are you worried about the incentives to break into
the user's account or are you worried about the provider wanting to peer
into users' email in order to assure itself that it’s not spam?

Eliot

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 28 Oct 2016 14:28:08 +0200

Hi, Eliot,

On 28-10-16 14:02, Eliot Lear wrote:
> not to sign.

An end user often cannot choose to sign or not to sign. The end user is 
dependent on what the ESP or the employers organization configures. 
Well, of course one could change ESP... But changing employer is quite a 
step ;-)

/rolf

---

From: Eliot Lear <[email-masked]>
Date: Fri, 28 Oct 2016 14:37:48 +0200

Hi Rolf,

On 10/28/16 2:28 PM, Rolf E. Sonneveld wrote:

> An end user often cannot choose to sign or not to sign. The end user
> is dependent on what the ESP or the employers organization configures.
> Well, of course one could change ESP... But changing employer is quite
> a step ;-)

The question then becomes this: what is the purpose of that signature? 
How long should accountability last?  There is also the minor matter of
the operational complexity of rotating keys.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Fri, 28 Oct 2016 15:37:32 +0200

Hi Dave,

I understand your despair, but even at the time we allowed for varying
key sizes precisely because we really didn't know how long people would
want to validate for, and we also didn't realize how real a crypto
attack on a dkim signature would be (Google found this problem out the
hard way).  You're precisely correct that when we see people saying that
somehow "John Podesta sent X" means "John Podesta said X" is not
something that DKIM was out to solve.  DKIM CAN'T solve that problem,
and if we attempt to architect it to do so, I'd recommend calling it
something else, because it surely will have very little to do with
Domain-based authentication.

For what it does, if people want to verify that the message came from a
given domain and the key remains valid, so long as the key size is
reasonable, there is some confidence that it will not have been hacked. 
Whether there is value in that is not a question we should even attempt
to answer, but if someone wants to produce keys of a larger length, so
long as it does not cause processing problems on the recipient end, I
don't see a problem.

Eliot

On 10/28/16 2:46 PM, Dave Crocker wrote:
> On 10/28/2016 2:37 PM, Eliot Lear wrote:
>> Hi Rolf,
>>
>>
> Just to pour some salt into the wound of this topic:
>
>    DKIM is formally for the very narrow purpose of affixing an
> accountable identity/identifier to a message, where the proffered
> accountability is intentionally quite weak.  It doesn't claim to prove
> anything else.
>
>    It uses authentication crypto to do the affixing, and therefore it
> gets some data integrity as a side-benefit; it's meant to be
> short-term, but as long as the public key stays available, apparently
> it can work for longer-term, as we are seeing.  But really, it's
> purpose is not for the usual array of benefits that accrue with object
> signing.
>
>    However, we are consistently seeing people -- including folk
> attempting to offer technical guidance -- claim that DKIM does offer
> classic authentication benefits.  So, proof of data integrity; proof
> that the message came from the signer; and even proof that the
> contents are 'valid'.
>
>    Trying to educate people into the nuances of DKIM semantics has
> been almost completely useless, although some of us have been making
> vigorous efforts for 10 years.
>
>    I'm coming to think that we probably should stop fighting that
> battle and should, instead, make sure DKIM is does a worthy job of
> performing the functions people tend to assume it does.
>
> sigh.
>
> d/

---

From: "John R. Levine" <[email-masked]>
Date: 29 Oct 2016 13:04:07 -0400

> You're precisely correct that when we see people saying that

The point of DKIM is to attach an identifer to messages which you can use 
in combination with the identifier's reputation to do stuff.  If the 
messages were from some random linux box, you couldn't conclude anything 
beyond the fact that the signatures are valid today. But they're not, 
they're from gmail about which we know a lot, and we also know that the 
messages were collected by spear phishing a specific account, not by 
attacking gmail's internal security.

Put together the DKIM signatures and what we know about the signer, that 
gmail is rather picky about what they sign and is very unlikely to have 
signed a backdated message, and that their internal security is quite 
good, and you can reasonably conclude that the valid gmail signatures on 
the Podesta messages mean the messages are real.

To get back to the previous argument, if you don't want people using DKIM 
to validate old messages, rotate the keys more often.  Deliberately weak 
signatures strike me as a poor alternative.  We can know exactly when a 
key was withdrawn (mine rotate monthly, with the old keys going away on 
the 10th of the following month) but we can only guess who might be able 
to crack or fake a key and even more so whether someone faked a particular 
signature.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Martijn Grooten <[email-masked]>
Date: Sat, 29 Oct 2016 19:26:01 +0000

> could deny the content once more, at least at the crypto

(...) 

> would be happy to help if there were a chance it'd get some

I think this is a really neat solution and I'd love to see an RFC like
this. In theory, that is.

In practice, I think that plausible deniability is something that
concerns very few people outside the crypto community. Maybe there is a
need for such an RFC among the modern day Lavabits, and if that is the
case it would be great if we could contribute, but I would expect people
running such services to understand their complex threat models quite
well already.

As for the original question, I agree that longer keys should be
supported as a matter of principle. But before we end up with an RFC
that makes implicit promises about what receivers can handle that don't
match reality, does anyone have an idea whether receivers can handle
key sizes larger than 2048 bits in practice? (I know the maths is the
same, but it'd make sense to set some kind of upper limit to avoid
getting DoS'ed and for all I know, people may have set that limit to be
2048 bits.)

Martijn.

---

From: Roland Turner <[email-masked]>
Date: Sun, 30 Oct 2016 18:11:27 +0800

On 10/30/2016 01:04 AM, John R. Levine wrote:

> To get back to the previous argument, if you don't want people using 
> DKIM to validate old messages, rotate the keys more often.

I'd suggest that as security services and political operatives have now 
been alerted to the potential value of DKIM in validating leaks[1], any 
realistic threat model now has to assume that the adversary/ies have 
access to a complete DKIM public key history - at least for any sizeable 
sender. Indeed:

  * this may already have been happening for some time; and, depending
    upon their means of information gathering[2]
  * passive DNS operators may already have this capability as a
    side-effect of what they've always done.

Those who are serious about plausible deniability can always use a 
separate keypair per message and retire the public key after a long 
enough interval for any likely delivery to take (60s? 2 minutes?), 
thereby defeating all subsequent analysis, at least until/unless 
ARC-signing by receivers becomes widespread. Whether this is a workable 
approach, or whether the objective is even a good idea, appears to be a 
long way out of scope for the DKIM specification.

> Deliberately weak signatures strike me as a poor alternative.

Agreed. Worse still, trying to simultaneously pursue the "long enough to 
support abuse prevention" and "short enough to support non-repudiation" 
creates either of two unworkable situations:

  * If we're "lucky", the former is shorter than the latter and we can
    tweak the recommended key length to stay within the gap on a regular
    basis until the end of time.
  * If we're unlucky, the former is longer than the latter and we've
    taken on an impossible objective.

In practice, neither length is likely to be able to be determined with 
sufficient precision to support realistic decision-making.

- Roland

1: not to a forensic standard perhaps, but certainly to make real-world 
determinations about whether a leaked document has been tampered with

2: collecting cached DNS data vs. crawling the DNS

---

From: Peter Goldstein <[email-masked]>
Date: Sun, 30 Oct 2016 22:37:38 +0100

> getting DoS'ed and for all I know, people may have set that limit to be

This is certainly a fair point.

I raised the issue with representatives of one of the big U.S.-based
receivers, and they indicated that they can accept keys at least up to 4096
bits.  But it's probably worth setting up a test mail server and validating
the behavior with assorted receivers.  I can look into doing that.

It's also probably worth ensuring that the major open source DKIM
implementations support both signing and verifying with 4096-bit keys.
Aside from OpenDKIM and dkimpy, are there any others that should be checked?

Best,

Peter

On Sat, Oct 29, 2016 at 9:26 PM, Martijn Grooten <[email-masked]
> wrote:

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJYFPfJAAoJEI5dMs9dIv8Z/SUH/jAe2uvRQ26D+/rEAMLRbsKP
> Bc8/SPsYH2lEKEf9w2xljTbRyP6M6puUFZsciPTq7v44L7Giov0gvdcDzDVVfL/A
> 71yZD7abViSqIbIvcAvh0yWtWF8oRv8oOfivcGdoOaDec+zTgS0FnEyBhyA70lJC
> W0pbIm8RvFCwKPjVMuFQ1mElFnSPoi0PPwP6HEpFXdtnqwfVOPWfcMfnBns6HlnR
> ymwCkiYL1z/i/A5P8Gj3VknwtwJxvuOQUYjB+iZVaHDiANlSAnU0MdTSkVenKeBH
> FYe8l3sEYk8NTxoJK+Z1iJ+LwasOg8qztZOimP4MMrED+5RnLfdwMQk5bDzClJw=
> =3yQ1
> -----END PGP SIGNATURE-----
>

-- 

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

[email-masked]
+1.415.793.5783

---

From: "John R. Levine" <[email-masked]>
Date: 30 Oct 2016 17:50:33 -0400

> Aside from OpenDKIM and dkimpy, are there any others that should be checked?

Perl Mail::DKIM is still widely used.  It calls Crypt::OpenSSL::RSA which 
is a wrapper around openssl so I'd be surprised if it had trouble with 
large keys.

Regards,

---

From: Jon Callas <[email-masked]>
Date: Sun, 30 Oct 2016 16:05:51 -0700

> On Oct 28, 2016, at 5:02 AM, Eliot Lear <[email-masked]> wrote:
> 
> * PGP Signed by an unknown key
> 
> Hi Jon,
> 

No problem. That you say, "either the thing is worth signing or it isn't" shows that you don't get it. I'll try to explain more.

> delivery, certainly 512 is not enough.

Yup! I agree completely. If the key is intended to verify the source longer than delivery, then 512 is not enough.

And -- the key is *PRECISELY* intended to verify the source *NO* *LONGER* than delivery. 512 probably still isn't quite enough, since you can break a 512-bit key too easily. If I lick my finger and stick it into the wind, 600-700 bits is about where they should be.

512 is slight exaggeration for effect. You can make it work, but you really need to put some infrastructure in place to make it work well. But I belive that 512 is a better choice than 8K. Or even 4K. But not for the same reasons.

> into users' email in order to assure itself that it’s not spam?

Ah, I see I'm going to have to at least snuggle, if not embrace the fuller discussion.

My issue -- not a worry -- is the *semantic* value of the signature.

Many, if not most protocols we deal with in the IETF are strictly syntactic. We don't look at the meaning, we don't look at the internals of them. Often this is both good and intended. Look at IPsec, TLS, SSH, OpenPGP, S/MIME, and on and on, these are syntactic standards.

In some of them, the unspoken semantic issues are a wart. In S/MIME and OpenPGP, there's a huge semantic issue as to what a signed message *means*. I had a co-worker (at both Pretty Good Privacy, Inc. and PGP Corporation) who would not sign his emails. The reason he wouldn't is that he said that we didn't know what signed email meant and that he didn't want to end up finding out twenty years later that his signing a message was suddenly a legal commitment that he didn't intend.

This is also an interesting long discussion. Is a signature on an email nothing more than an source-directed integrity check? Does it mean a little more, such as the digital equivalent of letterhead? Does it mean even more than that, that it's 'official'? Or more than that, that it's certified true and accurate? I know where I stand on it, which is far more towards the integrity check or at most letterhead. I might even roll my eyes, but it's a not unreasonable concern that I simply happen to disagree with.

My last bit if setup and groundwork is to gesture towards Phil Rogaway's essay of last year on crypto and its social aspects, which is such a big thing that I'm just going to say, "Thanks, Phil," and move on.

All of this setup is relevant here because the mission of DKIM is to stop a certain class of message forgeries. These message forgeries are / were a danger to the public health of the Internet. DKIM addresses them. Note that I used the word "address" not "solve." SPF also addresses them, in a different way. So does a lot of other network infrastructure, as well, as well as the upper parts of the DKIM stack like DMARC.

I think it was Mark Delaney's words in his mission statement for the DK part of DKIM that it lets Alice's ISP know that a message from her from her bank actually came from her bank, even when forwarded through her alumni association. DKIM gives source attribution that travels with the message.

However, that source attribution has another side to it. That other side is that at its core, one might say a DKIM signature is in a similar moral space as the "super cookies" that some providers put into web connections (like Verizon, who the FTC fined $1.3M). It is a tracking thing that is put without the user's consent into their email that can be used for identification later without their knowledge. Worse, it's not merely a cookie that's a constant, it's a content-specific digital signature. Shock horror.

Now of course, the counter-argument is about the semantic layer. Yeah, syntactically, there's a resemblance, but the reason they're different is many-fold and has to do with purpose, use, and so on. 

For one, the "super cookies" are a conversation between the network provider and an ad network that does not benefit the user in any way. They are an *exploitation* of the user. A DKIM signature benefits us all through that initial use case. They add to the public health of the Internet as a whole and the email infrastructure at large. I can mount a vigorous defense of DKIM, but I could also use DKIM in a defense of tracking cookies. I believe I could also shoot down that analogy.

I also think that we can improve DKIM in a lot of ways operationally that further breaks whatever improper analogy there is. We also ought to re-examine a lot of the email infrastructure with a post-Snowden eye, and that eye should include a post-Yahoo-scanning scandal as well. We really should look at how much the email ecosystem as a whole has become part of the broader surveillance structure of the Internet.

These include:

- - MDAs should strip out DKIM signatures. If they did, my whole silly comments about key sizes are moot. It means that they aren't part of the whole permanent record of email stores and their insecurity because of the peculiar legal status of email.

- - MDAs should also be stripping Received headers and a bunch of others. Received headers write in stone the geoposition someone was at when they pressed send. It's a 4-space pin in the map. You can track people in their business travels by looking through old mailing list archives. You can see what type of computer they run, what MUA they are using, and their upgrade patterns. All the better to spearphish them with. 

- - That goes double for you, Mailman. And any other list archiver. 

These and more are part of why email is so broken these days. It was made for an environment when we all used terminals on timesharing systems and things that made sense then (putting logging and debug information into a message) do not make sense in a world of mass surveillance. Cleaning up old messes is always hard, and this is another one.

But anyway, back to DKIM --

The problem here -- DKIM being a super cookie -- can be handled any number of ways. One of those is to rotate keys frequently. Really, big ISPs like Google and Yahoo and Apple and Microsoft ought to be putting out keys with one week of use and two weeks of life. That doesn't solve the whole problem because there's no reason why The Internet Archive or other entities can't just start archiving the DKIM public keys. Moreover, even if you rotate the keys, that merely downgrades the DKIM information from being a cryptographically authenticated super cookie to an unauthenticated super cookie (like the ones Verizon was using). 

The comments I made that started this -- cryptographically weak DKIM -- is also a partial solution at best. But I want to swing back to my point, which is that we crypto people have a tendency to look at crypto parameters and just blithely start using them everywhere, looking at the surface structure of what we're doing and not the deep structure.

Part of the deep structure is that DKIM had cryptographic authentication post-delivery as something between an non-goal and an anti-goal. We didn't want to have to force MUAs to have to play with them, and didn't even really *want* MUAs to do it, certainly not long term. Yahoo had plans to show DKIM status in their web client, but only for a short term. Yes, your email came from your bank. Moreover, this is why DKIM is really important for banks, and not at all important for domains like callas.org. 

Back in pre-Snowden days, it was hard to argue this sort of privacy / metadata / traffic analysis stuff without looking like a looney. I also realize that DKIM is not a *mere* tracking cookie, it serves and succeeds at improving the public health of the Internet. My wry points about weak-keyed DKIM are there in part to look at the whole issue. The good that DKIM provides is not improved by 8K keys. It's not improved by 4K keys, or even 2K keys (at the time of this writing). That's because a DKIM key needs to be alive for no more than a week, and in the vast majority of cases not even an entire minute! The threat model of DKIM is also such that if someone managed to compromise a DKIM key, they are only able to authenticate a spam message. 

Yes, yes, I know that that "only" could empty someone's bank account, but the defense against that adversary is a defense-in-depth strategy which has a series of filters and checkpoints and the whole point of defense in depth is that each screen plays a part in the filter as a whole. My point is that DKIM is designed to be effective with lower levels of cryptographic security and that's part of why it's so cool! Increasing the crypto in just about *any* system is strengthening the strongest link in the chain. The DKIM link in the anti-fraud, anti-spam email defense does not benefit with even 2K keys. It benefits by having operations management rotate those keys and having operations management look at the broader problem of cruft in our basement of email -- like the way headers in general add to the surveillance-friendly problems of email stores and list archives.

Like many security issues, crypto is only part of the complete breakfast. DKIM headers are an issue because they provide long-term cryptographic surveillance. But the surveillance tags are there in non-cryptographic places, too, and it is wrong to say that we don't need to fix them because well, the park is still dirty after we clean up our litter. We must clean up our litter and get others to clean theirs up, too.

	Jon

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 31 Oct 2016 00:02:03 -0400

> is a wrapper around openssl so I'd be surprised if it had trouble with

There's also https://sourceforge.net/projects/libdkim/ by ALT-N.

Scott K