On Tue, Aug 4, 2015 at 4:21 PM, Ted Lemon <ted.le...@nominum.com> wrote: > On Aug 4, 2015, at 3:01 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote: >> +1 to Donald's response, and -1 to Ted Lemon calling cookies a "kludge". > > Sigh. The actual proposal, particularly the key rollover bit, is quite > elegant, if a bit underspecified, so you’re right to call me out for this > choice of terminology. I called it a kludge because it is an attempt to > use something that makes sense in one context in a different context where > it won’t work very well. It makes sense with IKE because you are > preventing key spamming attacks from consuming massive amounts of CPU. It > wouldn't make sense to use in combination with TSIG because TSIG doesn’t use > public keys.
It all depends on what algorithms you are using, how fast your processor is, how close to saturation your processor is in processing the request stream it is getting, whether it has hardware assist for your algorithm, etc. I agree that there would typically be more benefit for IKE than for TSIG. From that it does not follow that it "wouldn't make sense" to use COOKIEs in connection with TSIG. The non-cryptographic calculations you do for COOKIE verification are going to be at least two orders of magnitude cheaper than the cryptographic calculations you do for TSIG verification. > In the particular use case that has been proposed, > it is > pure speculation that it would actually deliver any benefit at all, but it’s I would say it is more like it is easy to construct situations in which it of great benefit and easy to construct situations in which it is of no benefit. But it is not certain as to where on this spectrum things will typically fall and how that will change with time. > pretty easy to enumerate the costs: twice as many packets sent to clients > that don’t implement it, which will be most clients, and a number Since there is no change in behavior for clients that don't support COOKIEs, there is no increase in packets for them. > approaching twice as a limit as many packets for clients that _do_ support > it, depending on how many of them are repeat customers. I don't see any increase in packets for clients that support COOKIEs. If a server does not think it is under attack and is getting few enough requests from a client (and it seems to me that the first request if it has no previous history of requests would always qualify), it just processes the request normally and includes a server COOKIE with the response. If, on the other hand, a server was going to discard a request from a client then, in the case where the client supports COOKIEs but did not include a correct server COOKIE, the server can return a short BADCOOKIE response, which means the client will be authenticated on its next try so that that client won't send a series of retries that are discarded saving on traffic. 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
