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

Joe Touch <touch@isi.edu> Sun, 12 December 2010 00:45 UTC

Return-Path: <touch@isi.edu>
X-Original-To: nbs@core3.amsl.com
Delivered-To: nbs@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D5543A6D54; Sat, 11 Dec 2010 16:45:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggBwDSqf5ThP; Sat, 11 Dec 2010 16:45:29 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 2916F3A6D51; Sat, 11 Dec 2010 16:45:29 -0800 (PST)
Received: from [192.168.1.92] (pool-71-105-94-39.lsanca.dsl-w.verizon.net [71.105.94.39]) (authenticated bits=0) by boreas.isi.edu (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: <4D041B43.4090900@isi.edu>
Date: Sat, 11 Dec 2010 16:45:55 -0800
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Pete McCann <mccap@petoni.org>
References: <AANLkTin4-uiFXoS9DaDWtTQartUb6DKEee+B8717odm5@mail.gmail.com> <4CFFFD8D.2000601@isi.edu> <AANLkTi=KG_CL5hQ0k4JQAy6oB=3RV3UWGQxTbYzGmsR3@mail.gmail.com> <72504C2E-CE17-4AE0-ACBC-E6BB4F002267@isi.edu> <AANLkTimmQ-HKJBpoqQCc9t1P=GFPFa8VojPTFh-D8Nay@mail.gmail.com> <4D011EF3.8080407@isi.edu> <AANLkTi=+PQKxMj4C83A90-DK3V-89ydBR02rR5zvA68L@mail.gmail.com> <4D0129B3.4050906@isi.edu> <AANLkTi=j1NdofgpJUDjFPcGSTT_96GByLaNTRxx7yuCy@mail.gmail.com> <4D01CE2A.9090804@isi.edu> <AANLkTim4jRQUE=FOvtQRZa7mFH1LS1h=OwkdspEV2k_J@mail.gmail.com> <4D02E9D9.2030508@isi.edu> <AANLkTimFfCcd4AnVejtp0cBwj6y-KVF+jCdH69nw3=xr@mail.gmail.com> <4D03D7EE.9010308@isi.edu> <AANLkTinKWs0-5d0BjzLPGQxEMc6E5DBkMtVA1TDEg02A@mail.gmail.com> <4D040740.8050207@isi.edu> <AANLkTi=4TwdErWFM7yMavXowsF+Vbc6qoB1s2NvXT2iw@mail.gmail.com>
In-Reply-To: <AANLkTi=4TwdErWFM7yMavXowsF+Vbc6qoB1s2NvXT2iw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "int-area@ietf.org" <int-area@ietf.org>, "nbs@ietf.org" <nbs@ietf.org>
Subject: Re: [nbs] [Int-area] New draft related to name-based sockets
X-BeenThere: nbs@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <nbs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nbs>
List-Post: <mailto:nbs@ietf.org>
List-Help: <mailto:nbs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=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<touch@isi.edu>  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