Re: [ietf-dkim] DKIM Key Sizes

[Eliot Lear <[e-mail]>]

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

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

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

Eliot

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