On Jan 27, 2015, at 11:53 AM, Steve Atkins <st...@wordtothewise.com> wrote:
> > On Jan 27, 2015, at 11:24 AM, A. Schulze <s...@andreasschulze.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
