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

Joe Touch <touch@isi.edu> Sat, 11 December 2010 23:19 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 DEA013A6D17; Sat, 11 Dec 2010 15:19:40 -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 4p0lbPYlkH0b; Sat, 11 Dec 2010 15:19:39 -0800 (PST)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 8F1083A6D09; Sat, 11 Dec 2010 15:19:39 -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 nitro.isi.edu (8.13.8/8.13.8) with ESMTP id oBBNKY1S016031 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 11 Dec 2010 15:20:45 -0800 (PST)
Message-ID: <4D040740.8050207@isi.edu>
Date: Sat, 11 Dec 2010 15:20:32 -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>
In-Reply-To: <AANLkTinKWs0-5d0BjzLPGQxEMc6E5DBkMtVA1TDEg02A@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: oBBNKY1S016031
X-ISI-4-69-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: Sat, 11 Dec 2010 23:19:41 -0000

On 12/11/2010 2:58 PM, Pete McCann wrote:
> Hi, Joe,
>
> On Sat, Dec 11, 2010 at 1:58 PM, Joe Touch<touch@isi.edu>  wrote:
>>> An elliptic curve cofactor diffie-hellman computation on known keys
>>> takes less than 10^6 cycles:
>>>
>>> http://cr.yp.to/ecdh/reports.html
>>>
>>> This would be under a millisecond on modern processors in software.
>>
>> Right, but that's 1,000 such attempts per second. That puts a cap on
>> software support for middleboxes that is fairly low.
>
> 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.

>>> Hopefully the discussion above clarifies.  The public key operations are
>>> only on the first time two parties interact in some way.  An ECC digital
>>> signature with NIST P-256 is 64 octets long.  The HMAC tag in subsequent
>>> packets (when using the pickle packet fragment signature header given
>>> in the draft) is 20 bytes plus variable amount depending on what level
>>> of protection is desired.  I expect SHA-1 (20 bytes) to be nominal for
>>> most connections.  The draft has enough flexibility to allow multiple
>>> HMACs on each packet to account for multiple middleboxes that all
>>> want to validate a tag from the same endpoint; however, I expect in
>>> most deployments that the tags will be computed on a pairwise basis
>>> between adjacent middleboxes so only one signature per packet will
>>> be needed.
>>
>> Not sure what that means; why would adjacent middleboxes be involved, vs.
>> separate interactions between each such middlebox and the endpoint. This
>> needs to be made more clear in your architecture.
>
> Just as endpoints build up knowledge about the topology of the middleboxes,
> the middleboxes would learn about each other and could develop their
> own security associations pairwise between them.  If you consider the
> pickle-aware middleboxes to be like beads on a string, adjacent beads
> could develop shared secrets and perform HMACs on the packets passing
> through.  A typical operation for a middlebox would then be to validate
> HMAC on an arriving packet, perform its middlebox type operations, and
> then re-sign the packet on the way out.  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.

>> TCP-AO can easily be extended to include other algorithms that support
>> public-key (you just need to specify the other algs and register them with
>> IANA, as per RFC 5926, AFAICT.
>
> 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.

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.

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

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

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

Joe