Re: [ietf-dkim] DKIM Key Sizes

[Stephen Farrell <[e-mail]>]

Hi Jon,

On 27/10/16 23:29, Jon Callas wrote:
> 
>> On Oct 27, 2016, at 1:29 AM, Peter Goldstein <[e-mail]>
>> 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
> 

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