In message <44d34c00-2ada-443e-9387-ef79171b4...@fl1ger.de>, "Ralf Weber" writes: > 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.
Read the draft. It does not say that. It is IP address + client cookie + secret (min 64 bits) + whatever else the server adds to the mix (for named that is time + a 32 bit nonce). It's also why the secret needs to be updated periodically for the plain 64 bit secret. Thats 32 + 64 + 64 bits of input minimum. For named it has at least 64 bits of input and possibly 96 more bits on top of that. > 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. If you are talking to the CPE as a nameserver. If you are talking to remote nameservers (e.g. 8.8.8.8) through the NAT you normally just have port manipulation. > 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. So you leap from random ports to fixed port 53. > > 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. Much better to not to have to detect and recover from being garbage nameservers and addresses in the first place. > -Ralf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
