On Jan 27, 2015, at 11:53 AM, Steve Atkins <steve(_at_)wordtothewise(_dot_)com>
wrote:
On Jan 27, 2015, at 11:24 AM, A. Schulze <sca(_at_)andreasschulze(_dot_)de>
wrote:
Steve Atkins:
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.
With EDNS you can go up to 4k UDP packet size, tho fragmentation is an issue.
DNS with UDP packets <1200 pass most broken firewalls.
With DNSSEC, you see more and more big UDP DNS requests. DNSSEC resolution is
deployed enough. Just don’t put a TTL of 5mn on these entries…
I don’t think a DNS answer of 851 bytes is a serious issue today (especially
for DKIM).
I think an addendum to DKIM, to allow more flexibility in key size could be
useful. The times it takes to reach standard, about 3 years (then deployment
another 2-3 years), we need to prep the work long before we need it.
It is like quantum computing, the time to create a new encryption is longer
than the projected availability of a quantum computer that will crack all
current encryptions within minutes.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html