Moin! On 5 Aug 2015, at 5:36, Mark Andrews wrote: > The analysis above is lacking. > > "has cookie" is not the determining factor. "has good server cookie" > is the determining factor. For the attack that Ted describes later these attackers will have a good server cookie as they are behind open resolvers that implements cookies, so I think his analysis is correct.
But lets focus on the way the server handles cookies. I think I discussed that with you or Donald in Prague. There are two ways to do this so that each client gets a different cookie, which is what the draft suggest: - provide a total random cookie for each client. That way you have to keep state for every client making it very easy to exhaust the server by sending different cookie requests from different addresses (spoofed or as part of a /64 every IPv6 user gets) - provide a deterministic function that takes the client IP and a secret to generate the cookie. That way you can generate the same cookie on every request. So the last method becomes a cryptoanalytics problem and I am not a cryptographer, but it would be good if someone with more know how there could comment on how difficult it would be to break the secret given that one can easily generate 2^64 different inputs to that function and examine the output. As soon as the attacker knows the secret he can spoof request from any address with correct cookies rendering the cookie protection useless. > Actually there are good reasons for clients to implement cookies. > They reduce the amount of port randomisation that needs to happen > in a recursive server (if the server supports cookies you don't > need to randomise the source port) and client cookies work even > when the NATs undoes port randomisation. If NAT leaves the DNS packet untouched. I'm not sure they do this and most home gateways or firewalls have a DNS proxy anyway. Also I don't want to get back to source and destination port being 53 it was quite a journey get various parties convinced that multiple ports above `1024 are ok as source ports for DNS. > Even when the client does DNSSEC validation this is useful as the > referral is not signed. Sure, but we would catch that with checking the DS against the keys. So long -Ralf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
