On Thu, Jul 16, 2015 at 12:52 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote: > <secretary-hat on> > > Greetings. The WG Last Call for draft-ietf-dnsop-cookies was supposed to end > today, but it got extremely little review during the Last Call. It would be > helpful to all of us if more people can review the document, say what they > do or don't like about it, and so on.
I've read draft-ietf-dnsop-cookies-05 (a post-WGLC version). It basically looks good to me to ship: I agree the idea is at least worth trying, and I see the document is generally well written. I have some comments and questions that I think may be worth discussing, however: - About applicability: I see it can be a useful supplemental measure for cache poisoning. Whether it really helps mainly depends on whether the authoritative server operators have an incentive to enable it, which I really don't know, but I believe it's at least worth trying. On the other hand, I'm not so sure about mitigating reflection/amplification type of DoS attacks. I thought we've reasonably addressed this problem for authoritative servers with the surprisingly quick adoption and deployment of RRL (but I may be wrong, in which case I'm happy to be corrected). And so in my understanding the main current issue is open resolvers. But if we can expect these resolvers to be updated to support DNS cookies to the extent that they are not a main concern, I guess the problem would have been resolved much earlier with the support of default ACL for those resolvers. This does not necessarily mean DNS cookies are useful for this type of attacks, so it may still be worth trying, but the scope of expected attacks can affect how tricky the server cookies need to be as described in Section 6. So, while I do not necessarily request to limit the scope, it may be good if the draft provides some more detailed discussion on these points. - Section 4.1 In order to maintain the security properties of this protocol, a client MUST NOT use the same Client Cookie value for requests to all servers. Specifically what does this mean? Does this mean, for example, the client generates a different cookie value for a different server (identified by its IP address) and maintain the cookie values per server basis? - Section 4.2 In order to maintain the security properties of this protocol, a server MUST NOT use the same Server Cookie value for responses to all clients. I'm also not sure how I should interpret this. Can't we basically assume this condition is met because the server cookie contains (in some way) the request source address and client cookie? Of course, a naive implementation of how to "contain" them could lead to the same server cookie value regardless of the difference of these values, but if this sentence tries to avoid such naiveness, I'd make the point clearer. - Section 5.2.3 Servers MUST, at least occasionally, respond to such requests to inform the client of the correct Server Cookie. By saying "occasionally", it could read (to me) as if it intends to mean maintaining per-client state. While a server implementation could actually do that, I guess that's something that this draft wants to avoid to see. If so, perhaps something like "randomly" instead of "occasionally" may be a better choice. - Section 5.5 Clients and servers MUST NOT continue to use the same secret in new requests and responses for more than 36 days and SHOULD NOT continue to do so for more than 26 hours. Many clients rolling over their It would be helpful if the rationale (if any) of these constant values (36 days and 26 hours) is explained. - Section 5.5 When a server or client starts receiving an increased level of requests with bad server cookies or replies with bad client cookies, it would be reasonable for it to believe it is likely under attack and it should consider a more frequent rollover of its secret. It's not very clear to me how a more frequent rollover helps in this case. In such a case the attacker basically keeps trying random cookies (right?), so whether or not we do rollover more frequently the attacker's odds wouldn't be different. Or, does this intend to minimize the risk in case an attacker actually identifies the valid cookie by the random try (by reducing the attackable window)? -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
