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

Joe Touch <> Sun, 12 December 2010 00:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D5543A6D54; Sat, 11 Dec 2010 16:45:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ggBwDSqf5ThP; Sat, 11 Dec 2010 16:45:29 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2916F3A6D51; Sat, 11 Dec 2010 16:45:29 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id oBC0k8uR028601 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 11 Dec 2010 16:46:17 -0800 (PST)
Message-ID: <>
Date: Sat, 11 Dec 2010 16:45:55 -0800
From: Joe Touch <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Pete McCann <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: "" <>, "" <>
Subject: Re: [nbs] [Int-area] New draft related to name-based sockets
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 12 Dec 2010 00:45:30 -0000

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