-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Please correct me if I'm wrong. I think there is a problem in this draft.
Although the draft explicitly addresses Birthday Attacks it is still vulnerable. Section 10.2 (Birthday Attacks) states: > To counter this, every edns-client-subnet option in a response > packet MUST contain the FAMILY and SOURCE NETMASK fields from the > corresponding request, along with identical ADDRESS bits for > SOURCE NETMASK length. Intermediate Nameservers processing a > response MUST verify that these match, and MUST discard the entire > reply if they do not. So far so good, ECS as part of the q-tuple. But then Section 6.3.: > Replies coming from servers not supporting edns-client-subnet or > otherwise not containing an edns-client-subnet option SHOULD be > considered as containing a SCOPE NETMASK of 0 (e.g., cache the > result for 0.0.0.0/0 or ::/0) for all the supported families. These two excerpts directly contradict in my opinion and DO make ECS enabled resolvers vulnerable for cache poisoning. Scenario: 1) attacker sends a flood of N queries to the resolver with the same q-tuple but different source addresses or ECS options. 2) Resolver is not able to deduplicate queries since we are doing ECS and thus will send N queries to the authority. 3) attacker sends flood of spoofed responses with evil content and without the ECS option. It has a high success rate due to the birthday problem. I'm not sure where to go from here. Not echoing the option after all is the proper EDNS way of signalling lack of support for said option. So dropping the option-less answer is also not a good idea. //Yuri -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlU3is4ACgkQI3PTR4mhavgycQCdFDtW0U0APeJa1BtUppTFxN/+ b1sAoJ0ye884RaewYKcWUjbj6b64EP+a =8dOb -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
