On 10/30/16 4:05 PM, Jon Callas wrote:
On Oct 28, 2016, at 5:02 AM, Eliot Lear <lear(_at_)cisco(_dot_)com> 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