On 2013-09-05, at 10:02 PM, Haya Shulman <[email protected]> wrote:
> I would recommend short term patched (that we recommend in the paper) in the > meanwhile, and addressing the deployment challenges of DNSSEC. Some comments on these recommendations. Based on the caveats documented by Google, I'm not sure the random prefix defenses would be recommended for general deployment, see link: https://developers.google.com/speed/public-dns/docs/security#add_entropy i.e., blacklist management. I also speculate that this will become even weirder with the new gTLD rollout. The random suffix defense makes sense, except then the attacker just has to repeat the attack for different checksums. Based on your research, only 1% of resolvers actually randomize the IP-ID, so it provides marginal entropy at best (side note, OpenBSD has been randomizing IP-ID for eons, I think even since the 90's-- http://www.openbsd.org/crypto.html#prng). Unmentioned variation: random-length suffix? Instead of just randomizing the fictitious IP address, tack a random string on the front of the fictitious domain name. The advantage is that, in addition to the checksum, you add IP and UDP length to the entropy (although these adjust in tandem, unfortunately). I would like to know if there is any merit to my earlier suggestion to Florian, namely, ignore glue records in large DNS responses, and have the recursors resolve dangling authority referrals using a separate (shorter) query. The second request is a simple A or AAAA query for the first[*] nameserver listed in the original response. The reply should contain the same authority and glue from the original response, but the data is more credible since the parameters of this query were not chosen by an untrusted stub. The assumption is that this second response would not also be fragmented, although I suppose the recursor could drop the EDNS0 option to force TC=1 just in case (even though that would result in a 3rd transaction, ugh). -Aaron [*] It is important to use the first namserver, since this is the one most likely to be contained in the first fragment (we have to consider that an attacker could corrupt the authority RRs, not just the additional glue RRs). _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
