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

Pete McCann <mccap@petoni.org> Sat, 11 December 2010 23:53 UTC

Return-Path: <mccap@petoni.org>
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 76D293A6D1A; Sat, 11 Dec 2010 15:53:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 Vpb4X3cDi2mc; Sat, 11 Dec 2010 15:53:46 -0800 (PST)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 392573A6D17; Sat, 11 Dec 2010 15:53:46 -0800 (PST)
Received: by wyf23 with SMTP id 23so4807333wyf.31 for <multiple recipients>; Sat, 11 Dec 2010 15:55:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.227.198.67 with SMTP id en3mr684828wbb.179.1292111720009; Sat, 11 Dec 2010 15:55:20 -0800 (PST)
Received: by 10.227.13.136 with HTTP; Sat, 11 Dec 2010 15:55:19 -0800 (PST)
X-Originating-IP: [64.53.131.166]
In-Reply-To: <4D040740.8050207@isi.edu>
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>
Date: Sat, 11 Dec 2010 17:55:19 -0600
Message-ID: <AANLkTi=4TwdErWFM7yMavXowsF+Vbc6qoB1s2NvXT2iw@mail.gmail.com>
From: Pete McCann <mccap@petoni.org>
To: Joe Touch <touch@isi.edu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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: Sat, 11 Dec 2010 23:53:47 -0000

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?
Do you really think all of these connections would be
from unique names that you don't have LTSS in cache for?

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

>> So in the language of RFC 5926, I am talking about the method used
>> to configure the Master_Key.  I think it's an assumption of all the TCP-AO
>> work that such a Master_Key is configured out-of-band in two peers and
>> consists of a symmetric (not public key) shared secret.
>
> First, 'out of band' can happen by whatever other mechanism - it's just not
> inside TCP-AO.

Yes, understood.

> Second, yes, we assume that the masters are symmetric. Not sure what the
> benefit of public key is in this case. You could use public key to derive
> the shared key.

Right, I'm not saying it's not possible, just hasn't been specified.

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.

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

>> Pickle packets provides a DNS-based framework for distributing public
>> keys tied to DNS names, and for deriving Long-Term-Shared-Secrets
>> (the Master_Keys) from pairs of public/private key pairs.
>
> That's what AO would consider an out-of-band key Master_Key management
> system.

Agreed.

>> I am not aware
>> of any similar specification for TCP-AO.
>
> There has been none specified for use by TCP-AO, but the way AO is
> specified, such a system would be external.

Yes.

-Pete