Re: [nbs] [Int-area] New draft related to name-based sockets

[Pete McCann <[e-mail]>]

Hi, Joe,

On Sat, Dec 11, 2010 at 6:45 PM, Joe Touch <[e-mail]> 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