ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] need for clarification

2015-01-27 14:44:16

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.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

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