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

[Pete McCann <[e-mail]>]

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.

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

Ok.  Need more data to answer this.

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

Many devices such as home gateways would likely be just fine with
a much lower line rate.  If this really does catch on in the core, I
would expect hardware acceleration to be available.  I don't expect
every router along the path to participate; most likely you would
only do this at administrative boundaries.

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

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

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.  I am not aware
of any similar specification for TCP-AO.  I agree that the per-transport
key derivation is similar in concept to what is described in the pickle packet
draft.

-Pete