Re: [ietf-dkim] DKIM Key Sizes

[Brandon Long <[e-mail]>]

I don't think that's quite true.

Sure, in my mailbox, receiving the message as non-spam implies a certain
level of expectation that the message was not-spam.  Once exfiltrated,
however, there is no guarantee against tampering or anything.

Even in my mailbox, however, a digital signature is a stricter guarantee
than we've had on authenticity.  Which isn't to say it isn't possible to
spoof it, and it's only a guarantee for the domain, but it is a larger
degree of certainty than we've had before.  Of course, the other problem
with that is that the lower the chance of a problem, the more concerning
are the cases where there is a spoof.

I'm not sure if "privacy" is the right word for this concern, but it's an
elevation of verifiable authenticity of a message, which may be unexpected
to users.  I imagine that S/MIME would have a similar issue.

That said, I agree that trying to tie this concern to the keysize seems
very complicated.  Trying to tune the keysize for some consequence like
this is very complicated as the state of the art for breaking keys grows.
A 512 bit key can be broken in hours on publicly available resources within
the reach of most people in the first world.  Also, the challenge of key
rotation is very real, if we say people have to rotate keys every 7 days,
it just won't happen.  And if we think it's very unlikely for DKIM, the
orders of magnitude greater challenge for doing 7 day keys for S/MIME for a
large organization (5-9 orders of magnitude), not to mention the problems
there with key exchange

Brandon

On Thu, Nov 3, 2016 at 11:34 PM, Eliot Lear <[e-mail]> wrote:

> Jon,
>
> Thanks for the detailed expansion of your views.  I agree with you that we
> often do not state in our documents semantic intent.  Part of that is that
> we think in terms of building blocks, where semantic intent can actually
> change.  Part of that is perhaps that vendors don't want to expose all the
> intent they have.  In this vein, I agree with Jim's view of history that
> while we considered the minimum time a signature needed to be validated, we
> never really considered the maximum.  We were, I think, quite focused on
> short term delivery management.
>
> I still don't think signature size is the thing to chase here, re
> privacy.  If DKIM has done its job, then quite frankly whether or not the
> signature is in the message is irrelevant since one can look at the domain
> and establish some level of confidence regarding the sending domain and
> therefore the individual.  In effect, the From line is the supercookie
> you're worried about, only the sender provides it.
>
> Eliot
>
>
> On 10/31/16 12:05 AM, Jon Callas wrote:
>
>
> > On Oct 28, 2016, at 5:02 AM, Eliot Lear <[e-mail]>
> <[e-mail]> wrote:
>
> > * PGP Signed by an unknown key
>
> > Hi Jon,
>
> > I really don't get your point.  Either the thing is worth signing or it
> > isn’t.  See below.
>
> 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.
>
> >>
> >> 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.
>
> > 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.
>
> 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.
>
>
> >>
> >> 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.
>
> > 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?
>
>
> 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
>
>
> > > _______________________________________________ > NOTE WELL: This
> list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html
>
>
>
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
>
>

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