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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 357903A6CF0; Sat, 11 Dec 2010 11:57:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.597
X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4JBulgxdAcoe; Sat, 11 Dec 2010 11:57:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 151623A6CAF; Sat, 11 Dec 2010 11:57:39 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id oBBJwfXT012596 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 11 Dec 2010 11:58:50 -0800 (PST)
Message-ID: <>
Date: Sat, 11 Dec 2010 11:58:38 -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: Sat, 11 Dec 2010 19:57:40 -0000

Hi, Pete,

On 12/11/2010 9:04 AM, Pete McCann wrote:
>>> By performing a dynamic key derivation
>>> operation, the endpoint and the middlebox can agree on a shared secret
>>> to protect subsequent packets with an HMAC-based tag which should
>>> be verifiable at line rate.
>> You expect the middlebox to derive a shared key with the endpoint WHILE in
>> order to protect subsequent packets?
>> What will you be doing with the packets for the connection in the meantime?
>> (this will take a while)
> 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.

>> HMAC verificiation at line rate is likely to require additional hardware
>> that middleboxes typically don't have (and cannot afford, AFAICT).
> I haven't run the experiments, but from data on the web it looks like
> an HMAC is about two orders of magnitude faster than a D-H key
> derivation.

My previous experiments suggest that HMAC calculations are fairly 
prohibitive for line-rate devices in the middle of the net as well.

 > I think we could get up to a substantial fraction of 1gpbs
> even with a software implementation.

See RFC1810; MD5 is one of the fastest algorithms. You're now talking 
about a single CPU running flat-out 100% just to keep up with the line 
rate, maybe...

>> Well, you'll introduce a lot of delays every time you meet a middlebox in
>> the middle of a connection. The overhead in EACH packet that is required to
>> ensure that a packet can be signed is a bit prohibitive, AFAICT, as well
>> (what's the raw number?)
> 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.

>>> TCP-AO is in an architecturally similar place in the stack but is also
>>> end-to-end
>>> and doesn't have any key management defined for it.
>> The key management is separate, but as you note there's not enough
>> information after connection start to establish shared keys with new parties
>> (the ISNs are gone).
> But configuration of the root symmetric shared secrets must be done
> manually, no?  Public key cryptography offers more flexibility and security
> in this respect.

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.