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

Joe Touch <> Sat, 11 December 2010 23:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DEA013A6D17; Sat, 11 Dec 2010 15:19:40 -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 4p0lbPYlkH0b; Sat, 11 Dec 2010 15:19:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8F1083A6D09; Sat, 11 Dec 2010 15:19:39 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (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: <>
Date: Sat, 11 Dec 2010 15:20:32 -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-MailScanner-ID: oBBNKY1S016031
X-ISI-4-69-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: 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<>  wrote:
>>> An elliptic curve cofactor diffie-hellman computation on known keys
>>> takes less than 10^6 cycles:
>>> 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 

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