Hi, Joe, On Sat, Dec 11, 2010 at 6:45 PM, Joe Touch <to...@isi.edu> wrote: >> Any of these statistics publicly available? > > We had some SSL accellerators that have published statistics; you should be > able to find that on-line for modern products.
A bit of googling seems to indicate that SSL accelerators can handle a few thousand connections per second, and are a factor of 2 to 4 times faster than doing it in software on the main CPU. But, this bit of data doesn't really tell us much, if we are worried about the new load imposed by adding secure key derivation to what was previously a non-security-related middlebox, which I think is what you were questioning. But that's really an apples and oranges comparison. >> Do you really think all of these connections would be >> from unique names that you don't have LTSS in cache for? > > For a device near Google, probably not, but for one near Akamai, I would > guess probably. Those stats will be harder to come by... Indeed. >> The nice thing about using DNS to do key distribution is that all this >> would be set up automatically. But you're right, the administrative >> security policies would need to mesh up. > > Using the DNS to do key distribution does NOT mean automatic; it means you > have an existing infrastructure that requires configuration. Configuration > is the most challenging part, far as I've heard, of good key distribution. Sure, you've got to generate public/private key pairs and publish the public portion at the right place in DNS. You've got to make sure that the records are properly DNSSEC signed. But this is an O(N) operation, and once it's done, key distribution between any pair of boxes will happen without intervention. >> The benefit of public key is that it makes the distribution of the key >> material >> much easier. You don't have to use sneakernet or have another, >> key-wrapping >> key defined to push the symmetric key around the network where it might >> be vulnerable to being intercepted. Secret keys should stay in the place >> where they are generated. > > There are ways to derive symmetric keys from asymmetric ones, though. The > point is to not confuse required/desired properties of the primary keys that > you need to deploy with the keys used to authenticate the traffic. Diffie-Hellman is just such a derivation mechanism. The use of public key cryptography for the primary keys that are published in DNS means we can avoid an O(N^2) blowup in the manual configuration of symmetric keys that need to be unique between every pair of communicating entities. >> I'm not aware of any HMAC algorithms that work that way. The typical >> way this is done is to use public key to distribute a shared symmetric >> secret and then use that in an ordinary symmetric HMAC. > > If you're doing that, your HMAC-side is squarely in TCP-AO territory. Yes it is very similar, but doesn't cover the IP or transport headers. I thought draft-touch-tcp-ao-nat-01.txt was a good idea. Has it been decided not to pursue it? > The > rest is a key distribution issue - which, for AO, is out of band, but that > just means it's NOT in the AO portion. There's a bootstrapping issue if you > include it in the TCP header, but you have that regardless. Agreed, the contribution of pickle packets here is to point out that if we include the DNS names of sender and receiver in the initial transport connection, we can use them to index the public keys that can be retrieved from DNS and used to establish a Master_Key or something similar. You could use this key for AO if you wanted. -Pete _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
