Hi Jinmei, On Fri, Aug 7, 2015 at 2:40 PM, 神明達哉 <jin...@wide.ad.jp> wrote: > ... > > 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.
Thank you. > I have some comments and questions that I think may be worth > discussing, however: > > ... > > - 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? The draft does not require a client to use any particular way to generate Client Cookies as a function of server IP address. It just says the function "SHOULD" be as strong as FNV. What if the client just always sends a constant value for the Client Cookie? That would provide little security because, for example, any server that got a request from that client could copy to Client Cookie and use it to forge responses to the client for any request to any server. So this text prohibits a client from just sending a fixed value client cookie to all servers. It would be nice to require a client to send a different cookie to every server, but, as you say, that is usually impractical without excessive state in the client to remember what cookies it has sent to what servers. Using the sort of hashing techniques in the draft, the probability is high that a different cookie will be sent to every server, but it is not guaranteed. Actually, the wording in the draft doesn't seem that good. Perhaps it should be more like "In order to provide minimal authentication, a client MUST send client COOKIEs that will usually be different for any two servers at different IP addresses." > - 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. Can you suggest replacement text? You seem to understand what is being said. As above, it could be reworded as "In order to provide minimal authentication, a server MUST send server COOKIEs that will usually be different for clients at any two different IP addresses or with different client COOKIEs." > - 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 I don't know why you would think that. > 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. I don't think there is much difference between "randomly" and "occasionally" but randomly implies some attempt at an actual pseudo-random mechanism. "Occasionally" can be satisfied by a pseudo-random mechanism but also by some simple rule like responding to every tenth request or every Nth request for some reasonable N. > - 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. The rational is cryptographic hygiene. The longer you use any secret, the higher the probability it has been compromised. The specific values are to be sure in one case that the secret will not be used for much more than a month and in the other case for not much more than a day. The numbers may seem a bit odd but are designed to allow for weekends and holidays and time changes for daylight savings time and the like. While I don't think these times should be any longer I'm not sure the precise value is that important. > - 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)? The more you re being attacked the higher the probability that one or more such attacks will succeed. More rapid rollover decreases the benefit to the attacker when an attacker succeeds. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com > -- > JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
