Hi, On Wed, Aug 5, 2015 at 4:58 AM, Ralf Weber <d...@fl1ger.de> wrote: > ... > > 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.
The second option above is the only method described in the draft except that you can easily throw in additional fields as shown in Appendix B.2. > 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. Counting out 2**64 is not that easy. Assuming you can count once a microsecond, it will take you about 600,000 years. Of course, you only have to count through half the space on average and, since it is suggested that a non-cryptographic function may be adequate, there are analytical short cuts. This could do with some more analysis but if, for example, the estimated effort to break a value with some short cuts is a savings of a factor of 100,000, the expected time would be 40 months. This is all an engineering trade off. You can use a stronger function or a bigger field but at some point, it is cheaper for the attacker to use more computers to attack the network rather than using more computers to cryptanalyze what the server is doing. Typical cryptographic authentication systems these days usually like a 96 bit or larger authentication code. > As soon as the attacker knows the secret he can spoof request from > any address with correct cookies rendering the cookie protection > useless. Until the server changes its secret, which the draft suggests it should do daily subject to a +0% to -40% jitter. There is no particular reason the server couldn't change its secret more often, something like once an hour, and the draft suggests that the server do that if it suspects it is under attack. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
