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

[Joe Touch <[e-mail]>]

On 12/11/2010 2:58 PM, Pete McCann wrote:
> Hi, Joe,
>
> On Sat, Dec 11, 2010 at 1:58 PM, Joe Touch<[e-mail]>  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