Subject: [DNSOP] draft-ietf-dnsop-edns-client-subnet-00 Birthday Attack

From: Yuri Schaeffer <[email-masked]>
Date: Wed, 22 Apr 2015 13:49:34 +0200

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