Defining "high risk domains" is kind of like defining obscenity. Hard to
come up with a good definition but I know one when I see it. Some of the
categories that help identify high risk domains:
* Banks and financial institution domains
* Charitable organization domains
* Educational domains
* Social expression domains
* Government agencies
I'm sure we could come up with more categories.
I would certainly say that anyone using a 384-bit key is high risk (in a
slightly different sense). I'd be curious as to how old the 384-bit
keys are.
One of the issues is that people treat DKIM signing as a project rather
than an ongoing process. Once they have it up and running it falls off
the radar screen.
-Mike
________________________________
From: Jim Fenton [mailto:fenton(_at_)bluepopcorn(_dot_)net]
Sent: Monday, June 21, 2010 1:50 PM
To: MH Michael Hammer (5304)
Cc: dkim-ops(_at_)mipassoc(_dot_)org
Subject: Re: [dkim-ops] DKIM key length criticism
MH Michael Hammer (5304) wrote:
-----Original Message-----
From: dkim-ops-bounces(_at_)mipassoc(_dot_)org
[mailto:dkim-ops-bounces(_at_)mipassoc(_dot_)org]
On Behalf Of Jim Fenton
Sent: Sunday, June 20, 2010 9:45 PM
To: dkim-ops(_at_)mipassoc(_dot_)org
Subject: [dkim-ops] DKIM key length criticism
I noticed a blog post critical of Facebook for only using a
512-bit
key
in their DKIM signatures:
http://blog.jgc.org/2010/06/facebooks-dkim-rsa-key-should-be.html
His analysis looks correct, except that he doesn't consider the
possibility that they might rotate their keys periodically
(although,
as
far as I can tell, they haven't yet).
Of course, there's a follow-on blog post that confuses the issue
further:
http://techie-buzz.com/tech-news/facebook-insecure-dkim-encryption-
mail.html
by suggesting that DKIM does encryption.
I'm in the process of collecting a bunch of DKIM selector data
to see
what the distribution of key lengths looks like. But I'm hard
pressed
to criticize a domain for using a key that's marginally too
short when
there are so many other domains that aren't signing at all.
Any thoughts?
-Jim
I don't think it's a generic when we talk about domains and DKIM
signing. The fact that someone's billybob.com domain doesn't sign is
orthogonal to the issue of high risk domains using 512-bit keys and not
rotating.
I'm doing a study of about 21,000 selectors (key records) I know about
and finding quite a few 512-bit keys (and even a few 384 bit keys!).
How do I decide what's a high risk domain? I was thinking about
weighting the results based on mail volume, and that probably helps, but
if you have any other ideas, let me know.
For many (most?) domains simply getting all their mail signed is a large
undertaking. Key rotation is a bit scary and raises potential self
inflicted pain if not handled well. This leads to many domains not
rotating at all as they put off dealing with the issue.
I've had this discussion with various people and it seems that quite a
few are looking to rotate once a year at this point.
We are using 1024-bit and my personal goal (stay tuned) is to rotate
every 90 days with a yet to be determined overlap on the keys. This is
not so much because of concern about weakness of keys but more about an
operational process that recurs at a frequency that the Ops team is
comfortable and confident implementing it.
I like your 90-day rotation idea for exactly the reasons you gave: when
you have something that happens once a year, there's enough time in
between for ops teams to lose track of the process. When you're doing
it 4 times a year, it will be learned faster and retained.
-Jim
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops