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

[Joe Touch <[e-mail]>]

Hi, Pete,

On 12/11/2010 3:55 PM, Pete McCann wrote:
> Hi, Joe,
>
> On Sat, Dec 11, 2010 at 5:20 PM, Joe Touch<[e-mail]>  wrote:
>>> Remember, this only happens for new communication peers, at the
>>> time the transport connection is established.  1000 connections
>>> established
>>> per second is a pretty high number, let alone connections from DNS names
>>> that you've never heard from before.
>>
>> It might be useful to take a look at some stats from a typical middlebox;
>> 1000 connections/sec was high for small boxes about 15 years ago, AFAIR.
>
> 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.

> 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...

>>> So, security associations could
>>> be hop-by-hop along the path in addition to end-to-end.
>>
>> In understand this may be supported in your architecture, but I'm not sure
>> it would ever happen administratively. That part may need to be addressed
>> further.
>
> 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.

...
> 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.

>>> 5926 contains
>>>
>>> algorithm IDs for the actual per-packet MAC algorithm (HMACs and CMACs)
>>> as well as the KDFs that are used to derive per-connection keying material
>>> from the preconfigured master key.  However, neither of these registries
>>> has anything to do with methods for provisioning the Master_Key.
>>
>> I'm not sure you couldn't create a new algorithm that used different
>> algorithms for creating HMACs and a different one for validating them, at
>> which point you could use asymmetric keys.
>
> 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. 
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.

Joe