Re: [ietf-dkim] DKIM Key Sizes

[Jim Fenton <[e-mail]>]

On 10/30/16 4:05 PM, Jon Callas wrote:
>
> > On Oct 28, 2016, at 5:02 AM, Eliot Lear <[e-mail]> wrote:
>
> > 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.
>
> 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.

I recall no discussion (prior to this leak) about non-repudiation
characteristics of DKIM. We were concerned about making sure the
signatures are verifiable for long enough for the recipient MTA to
verify them (~1 week, accounting for delivery delays) and that there is
no requirement that they be verifiable longer than that. But there was
no effort to constrain the validity beyond that. We were concerned that
requiring large DKIM keys would be a barrier to deployment, largely
because of the computational burden it might impose on bulk senders. But
nothing other than DNS concerns about discouraging large keys.

It was perhaps an oversight not to mention it somewhere, in a similar
manner to the brief mention of information leakage (RFC 6376 section 8.10).

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

Ouch. I really don't get the analogy between an identifier that is
placed on a user's computer and, without their knowledge, permits
tracking their browsing, and this signature (that doesn't even represent
an individual) that travels with a message.
>
> 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.

Wandering off topic, but I'm positive the purveyors of super cookies
will cite "getting more relevant ads" as a benefit to the user. But what
does DKIM track?
>
> 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.

This reminds me of the discussion on the Shutup mailing list late last
year and earlier this year. AFAIK, that didn't end up going anywhere,
but there is much more exploitable information in Received header fields
(like IP address of the sender) than there is in DKIM signatures.
>
> 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).

I don't agree. If someone is concerned about deniability of their
messages, they should be concerned about deniability of "fresh" messages
sent within the past day as well.

This isn't is a problem for DKIM to try to solve. Few enough people care
about non-repudiation of their messages to drive deployment of any
change. For the few that do, perhaps some of the more privacy-focused
email providers will provide an option not to DKIM-sign your messages.
Or they can run their own mail server :)

The real problem here is that the messages leaked in the first place,
not that we had evidence that they were genuine.

-Jim



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