On Jan 27, 2015, at 11:24 AM, A. Schulze <sca(_at_)andreasschulze(_dot_)de>
wrote:
Steve Atkins:
From operational perspective I experience no drawback using 4k RSA
keys for DKIM.
How do you know?
Not for sure. There was a feature to request reports in opendkim. Some people
used that and I got mostly no unexpected reports. Today DMARC reports
are a good source too.
I have some smaller "send only" domains. The DMARC reports also show
mostly positive results.
That's a self-selecting group of recipients who choose to run bleeding edge
protocols and software, and to configure them in a non-vanilla way. The
overlap between that group and the group who aren't seeing your email
because they're using older resolvers is probably zero.
So that's not evidence that you're not experiencing operational problems,
just that the way you're looking for them means you can't see them.
So there's no reason to use anything bigger than 2048 bits for DKIM,
I don't believe. I'd be far more concerned about other attacks on the
system, or even on the RSA algorithm, than I would be about people
brute-forcing 2048 bit keys this decade.
That's the point. The RFC don't make that clear enough.
It leave one side open.
How big is your DNS TXT record?
# dig J4bWGJQcBmxMQ._domainkey.andreasschulze.de. txt
;; Truncated, retrying in TCP mode.
...
;; MSG SIZE rcvd: 851
DNS responses that exceed UDP size are considered a very bad thing,
and will cause queries for that record to fail in many places. Given the
demographics
of people making that query it's not as big a problem as it would be for end
user
visible records, but it's still going to be a problem. And in the places
where it does work it's consuming a much, much more expensive pool
of resources than correctly configured DNS records do.
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html