Subject: [nbs] New draft related to name-based sockets

From: Pete McCann <[email-masked]>
Date: Wed, 8 Dec 2010 11:21:24 -0600

I've uploaded a new draft relevant to the name-based sockets
discussion and several others that have been going on in the
Internet Area and elsewhere:

https://datatracker.ietf.org/doc/draft-mccann-picklepacket/

It describes a framework for putting DNS names into transport
packets that is a bit different from the approaches I've seen
advocated on the NBS list.  For one thing, I wanted to work
with IPv4 as well as IPv6, which means avoiding all IP options
which cause packets to go on the slow path or get dropped.
The TCP options space is too limited for carrying DNS names,
let alone the extra authentication payloads that I wanted to
put there.  So, I'm proposing essentially extending the transport
options space in a non-backwards compatible way by shimming
in a magic number where the transport payload would normally
go.  This would apply to UDP as well.  I've defined a new header
which I think is relatively compact yet provides all the flexibility
we need, and a TLV format for carrying the DNS names and
public-key authentication tags.  I'm proposing to put public keys
into DNS TXT records so that they can be retrieved by middleboxes
that want to verify the transport connections passing through them.
Also, middleboxes can add their own names and authentication
tags, which allows them to make themselves known to the endpoints.
This enables them to be used as mobility anchor points in case the
path changes.

The focus of the introduction is on preventing denial-of-service attacks
but I think the protocol has many other useful features.
Names can be used to route connections such as multiple servers
sitting behind a NAT all on the same port.  Routing on names does
require some state to be kept in the middleboxes if we don't want
to put DNS names into every packet.  So, I'm proposing that each
middlebox choose a 32-bit cookie value that it can use to index the
flow state.  These cookies get distributed in the same round-trip as
the initial transport connection setup.

I'm very curious to have your feedback on the approach.  There is a
lot of stuff in the draft and the protocol is rather heavyweight, but
I think it addresses a lot of different themes that I've seen being
discussed in different working groups (TCP Auth Option, MPTCP,
NBS, MEXT, DKIM, KEYASSURE, etc).

-Pete

---

From: Joe Touch <[email-masked]>
Date: Wed, 08 Dec 2010 13:50:05 -0800

Hi, Pete,

This seems a little backwards. The port is in the context of the 
transport protocol, but if it's in the shim between IP and TCP it is - 
at best - a parameter to IP, not the transport (TCP, UDP, or other).

Using a transport other than TCP or UDP also puts it on the slow path 
(or just blackholes it) for anything that looks beyond the IP header, too.

As to where to put public keys, there's an RFC regarding reasons not to 
use TXT records for new DNS capabilities you might want to dig up (sorry 
- I'm in the airport and can't find it quickly - it was written by the 
IAB I think).

Joe

On 12/8/2010 9:21 AM, Pete McCann wrote:
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Pete McCann <[email-masked]>
Date: Wed, 8 Dec 2010 19:38:41 -0600

Hi, Joe,

I understand that ports are in the transport header.

The shim I am proposing goes *after* the transport header and
provides an encapsulation for the transport payload.  That way,
middleboxes see what looks like a standard IP/TCP header,
followed by a payload which contains the new stuff.  Think of
it as a way to get a lot of new options space without confusing
any of the middleboxes (unless they do try to parse beyond the
transport header like a "transparent" HTTP proxy.  The new stuff
I am proposing would confuse those kinds of boxes).  I only say
"not backwards compatible" because both endpoints need to be
upgraded to support the new extensions.  Middleboxes that have
not been upgraded shouldn't care; it looks like standard TCP or
UDP to them.  I agree that defining a new transport protocol is
a non-starter in today's deployed IPv4 network.  I think there will
always be only TCP, UDP, and maybe ICMP (the latter shouldn't
be trusted anyway) so I'm essentially trying to layer on top of them.

I know the choice of a DNS TXT record for public keys is controversial,
but it is very similar to the approach taken for DKIM which has been
quite successful.  The problem with new record types is that you have
to wait for all the servers and their configuration interfaces to support
them.

-Pete

On Wed, Dec 8, 2010 at 3:50 PM, Joe Touch <[email-masked]> wrote:
> Hi, Pete,
>
> This seems a little backwards. The port is in the context of the transport
> protocol, but if it's in the shim between IP and TCP it is - at best - a
> parameter to IP, not the transport (TCP, UDP, or other).
>
> Using a transport other than TCP or UDP also puts it on the slow path (or
> just blackholes it) for anything that looks beyond the IP header, too.
>
> As to where to put public keys, there's an RFC regarding reasons not to use
> TXT records for new DNS capabilities you might want to dig up (sorry - I'm
> in the airport and can't find it quickly - it was written by the IAB I
> think).
>
> Joe
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 8 Dec 2010 21:48:41 -0500

Hi Pete,

Sorry - you said transport payload, which - in hindsight - is ambiguous. 

First, as my old portnames ID explained, the strings need only be in the SYN. Using the data in the SYN for options has been proposed before, and there are many known issues. 

FYI. 

Joe

---

From: Pete McCann <[email-masked]>
Date: Wed, 8 Dec 2010 21:43:16 -0600

Hi, Joe,

Thanks - can you elucidate or send a pointer to the issues with
putting data in the SYN?  Are you worried that some middleboxes
will have problems and drop such packets?

I'd be particularly interested if you can point me at some of these
prior proposals.

-Pete

---

From: Joe Touch <[email-masked]>
Date: Thu, 09 Dec 2010 10:24:51 -0800

> will have problems and drop such packets?

There was a discussion a few years back on this list on various ways to 
extend the space for TCP options, which are most limited in SYNs.

The general problem is backward compatibility; that data cannot be 
assumed to be ignored by endpoints that don't support the option. TCP is 
required to ignore unknown options, and when it does, it would start a 
connection and interpret the options as data.

An additional problem is that many implementations simply discard SYN 
data, to reduce the amount of state until the connection handshake finishes.

I'm speaking most specifically of issues with putting options in the SYN 
data; there are other problems with putting options in the payload data.

Further, since this option can't be rejected by a legacy endpoint per 
se, the initiator needs to then stop the connection after receiving the 
SYN-ACK. Doing so without leaving state on the other end requires a RST, 
but that has other potential problems (RST gets lost, other end resends 
the SYN-ACK), etc.

So the key questions are:
- can TCP option space be extended without negatively impacting legacy 
implementations, in a way that isn't equivalent to creating a new 
transport anyway?

> I'd be particularly interested if you can point me at some of these

http://tools.ietf.org/html/draft-eddy-tcp-loo-03

http://tools.ietf.org/html/draft-kohler-tcpm-extopt-00

http://tools.ietf.org/html/draft-allman-tcpx2-hack-00

(if there are others, can others post?)

Joe

---

From: Pete McCann <[email-masked]>
Date: Thu, 9 Dec 2010 13:06:18 -0600

Hi, Joe,

Thanks for the issue list and the pointers to drafts.

I agree that backwards compatibility is an issue, if we are blindly
opening connections to previously unknown peers.  However, in
the pickle packet framework, opening a connection would always
be preceded by a DNS lookup for the TXT record at
_pickle.host.example.com which, if present, would be an indication
that the peer supports the new extensions.  So, I think there is
little danger of running into the issues you cite.

You might say that this is equivalent to defining a new transport,
but I think it's important to keep the protocol number 6 because
that is what today's middleboxes will pass.

-Pete

On Thu, Dec 9, 2010 at 12:24 PM, Joe Touch <[email-masked]> wrote:
> The general problem is backward compatibility; that data cannot be assumed
> to be ignored by endpoints that don't support the option. TCP is required to
> ignore unknown options, and when it does, it would start a connection and
> interpret the options as data.
>
> An additional problem is that many implementations simply discard SYN data,
> to reduce the amount of state until the connection handshake finishes.
>
> Further, since this option can't be rejected by a legacy endpoint per se,
> the initiator needs to then stop the connection after receiving the SYN-ACK.
> Doing so without leaving state on the other end requires a RST, but that has
> other potential problems (RST gets lost, other end resends the SYN-ACK),
> etc.
>
> implementations, in a way that isn't equivalent to creating a new transport
> anyway?
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 09 Dec 2010 11:10:43 -0800

> that is what today's middleboxes will pass.

But they won't. The read more than you think, including options. ;-(

Protocol 6 is an entire protocol, not just the default. If you want 
something inside that, you need to include framing.

However, this option is useful only in the SYN, IMO - as portnames 
pointed out. And that's the place where NATs are most problematic 
(stripping data, etc.).

On a separate point, _pickle.host.example.com presumes that _pickle is a 
transport, which it really isn't. Take a look at the SRV record specs, 
and the pending docs on that issue; I don't know what others feel about 
that, but that might a sticking point as well.

Joe

---

From: Pete McCann <[email-masked]>
Date: Thu, 9 Dec 2010 16:38:25 -0600

Hi, Joe,

> But they won't. The read more than you think, including options. ;-(

I'm trying to stay away from options for just that reason.
But, if middleboxes mess with the segment data in any
way (including coalescing or splitting segments) it would
indeed break the encoding I'm proposing.  But, that would
seem to break any transport-layer authentication option.

> something inside that, you need to include framing.

I guess the whole semantics of the protocol are now hard-coded
into the network.  It would really be nice if we could draw a line
somewhere and say, "ok, beyond this point, the e2e principle
applies and ye shall make no more modifications."

> However, this option is useful only in the SYN, IMO - as portnames pointed
> out. And that's the place where NATs are most problematic (stripping data,
> etc.).

"this option" is doing a lot more than just putting DNS names in.
The SYN contains a public key signature and information to bootstrap
keys for use in authentication tags of subsequent packets.  I hope
you can find the time to read the draft.

> transport, which it really isn't. Take a look at the SRV record specs, and
> the pending docs on that issue; I don't know what others feel about that,
> but that might a sticking point as well.

It might be a controversial choice but it is quite similar to the _domainkey
label that was defined in RFC4871.

-Pete

---

From: Joe Touch <[email-masked]>
Date: Thu, 09 Dec 2010 22:52:26 -0800

Hi, Pete,

On 12/9/2010 2:38 PM, Pete McCann wrote:
...
> you can find the time to read the draft.

I have, albeit briefly. Some comments:

- it'd be useful to understand the problem this is trying to solve. The 
doc just says "avoiding unwanted traffic", but doesn't define the 
boundaries of that problem

- signing the headers, i.e., to provide secure 'safe packet' tags, is 
insufficient protection against attack; an attacker can still read AND 
modify the data in the packets

- during the TCP-AO discussion, the issue of trying to exchange keying 
info inside TCP connection establishment was considered, and determined 
infeasible (for the reasons already noted; need for too much space, and 
inability to use the data of a SYN as a shim layer)

- overall, you're doing a bunch of things at once, and the rationale is 
not clear

It would be useful to start with a concise description of the problem 
you're trying to solve, the conditions for a solution (backward 
compatible or not, etc.), as well as a comparison of existing solutions 
in this space (IPsec, TCP-AO, SSL), and a discussion of the value this 
solution adds.

However, it seems that this solution won't work unless you have a LOT of 
option space - including in the SYN - and we have no known, 
backward-compatible way of doing that.

If this isn't backward compatible, and you just want to use port numbers 
to get through a NAT, you really need a framing protocol for your data 
inside TCP, or you should consider using UDP as your wrapper instead.

Joe

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 10 Dec 2010 12:52:31 +0100

Hi Pete,

as far as I remember they also tested SYN packets with payload in the 
Middlebox survey of Michio Honda. I couldn't find those results in the slides 
he presented at the last MPTCP meeting, but maybe just contact him.

Mirja

On Thursday 09 December 2010 04:43:16 Pete McCann wrote:
> > First, as my old portnames ID explained, the strings need only be in the
> > SYN. Using the data in the SYN for options has been proposed before, and
> > there are many known issues.
> >
> > FYI.
> >
> > Joe
> >
> >> to wait for all the servers and their configuration interfaces to
> >> support them.
> >>
> >> -Pete
> >>
> >>> use TXT records for new DNS capabilities you might want to dig up
> >>> (sorry - I'm in the airport and can't find it quickly - it was written
> >>> by the IAB I think).
> >>>
> >>> Joe
> >>>
> >>>> The focus of the introduction is on preventing denial-of-service
> >>>> attacks but I think the protocol has many other useful features.
> nbs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nbs

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

---

From: Pete McCann <[email-masked]>
Date: Fri, 10 Dec 2010 11:54:04 -0600

Hi, Joe,

On Fri, Dec 10, 2010 at 12:52 AM, Joe Touch <[email-masked]> wrote:
>> I hope

Great, thanks!

> - it'd be useful to understand the problem this is trying to solve. The doc
> just says "avoiding unwanted traffic", but doesn't define the boundaries of
> that problem

Yes, re-reading the introduction now I see it could use some additional
explanation.

The goal is to enable middleboxes to filter out unwanted traffic as close
to the sender as possible.  By adding a public-key based authentication
tag, middleboxes unknown to the original sender at the time he sends
the first packet can independently validate the signature and check the
reputation of the sender (similar to what DKIM does for e-mail, but this
is for transport connections).  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.

> modify the data in the packets

Completely agree; note that signing headers only is just one of the
options supported by the draft, and I expect coverage of the full
data packet will be commonly used.  But, the option to cover just
the header (or to omit the HMAC and just use a cookie) are there
to provide a low-overhead solution for particular threat models, e.g.,
when all attackers are off-path.

There have been a range of such options discussed in the literature
such as Lightweight Internet Permit System (LIPS) [1] and Passport [2].
I believe LIPS doesn't protect the payload in any way and Passport
protects only a limited portion of the payload.

> - during the TCP-AO discussion, the issue of trying to exchange keying info
> inside TCP connection establishment was considered, and determined

Yes, I definitely need a lot of space to put the DNS names and public
key signatures in.  If we are dealing with a path that does TCP re-segmentation,
it might be better to use UDP as you suggest below.

> - overall, you're doing a bunch of things at once, and the rationale is not
> clear

The draft attempts to describe a complete system including both the
packet authentication tags, key distribution, and DNS-based credentials.
I know this is unusual for work in the IETF that is usually done in smaller
chunks.  The draft grabs a bunch of bits and pieces and shows how to
fit them together, but maybe an overall system diagram would help.

> It would be useful to start with a concise description of the problem you're
> trying to solve, the conditions for a solution (backward compatible or not,
> etc.), as well as a comparison of existing solutions in this space (IPsec,
> TCP-AO, SSL), and a discussion of the value this solution adds.

IPSec and SSL are end-to-end, and the Diffie-Hellman exchange done
up front means that middleboxes have no chance to even see the identities
being exchanged in the credentials, let alone validate them (I'm sure the
designers of these protocols consider that a feature).  The endpoints of
an IPSec or SSL connection have to be known to the sender in advance.

In contrast, pickle packets put the DNS names in the clear for any middlebox to
examine and validate.  They can even participate in the key distribution
and subsequently filter out packets with bad authentication tags.  All without
pre-configuring their identities into clients or adding additional round-trips
(modulo the DNS queries, which could benefit from caching).

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.

> If this isn't backward compatible, and you just want to use port numbers to
> get through a NAT, you really need a framing protocol for your data inside
> TCP, or you should consider using UDP as your wrapper instead.

Yes, please note that the draft attempts to describe a transport-independent
format that should fit in *either* TCP or UDP.  If TCP re-segmentation is
being performed along a path you're right it would be better to fall back
to UDP.

[1] http://www.ee.hawaii.edu/~dong/papers/LIPS_report.pdf
[2] http://www.usenix.org/event/nsdi08/tech/full_papers/liu_xin/liu_xin.pdf

---

From: Pete McCann <[email-masked]>
Date: Fri, 10 Dec 2010 11:56:06 -0600

Thanks, I will get in touch with him.  I followed along with his
slides remotely during his presentation in Beijing but I also
don't recall seeing any test results about SYN payloads.  I
suspect they moved on after deciding to put most of their
new information elements into TCP options.

-Pete

---

From: Joe Touch <[email-masked]>
Date: Fri, 10 Dec 2010 19:02:49 -0800

Hi, Pete,

On 12/10/2010 9:54 AM, Pete McCann wrote:
> Hi, Joe,
>
> On Fri, Dec 10, 2010 at 12:52 AM, Joe Touch<[email-masked]>  wrote:
>>> I hope
> is for transport connections).

If a middlebox isn't on the path of the first packet, then:

a) it isn't a NAT; that traffic would be blocked

b) every packet would need to contain ALL the information needed to 
explain how to authenticate itself

The latter seems prohibitive, in terms of space (just as an overhead, 
regardless of whether it fits in the TCP option space).

> By performing a dynamic key derivation

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)

HMAC verificiation at line rate is likely to require additional hardware 
that middleboxes typically don't have (and cannot afford, AFAICT).

> when all attackers are off-path.

How do you know when attackers are off-path?

> fit them together, but maybe an overall system diagram would help.

A problem statement would be a start, including a threat model and a 
description of the costs (overhead, computation, etc).

Also how much effort will this require of the protected endpoints. I'm 
not sure I want to negotiate keys with a dozen middleboxes that all are 
trying to be helpful to me, and all are upstream on the same connection.

> (modulo the DNS queries, which could benefit from caching).

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?)

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

Joe

---

From: Pete McCann <[email-masked]>
Date: Sat, 11 Dec 2010 11:04:27 -0600

Hi, Joe,

On Fri, Dec 10, 2010 at 9:02 PM, Joe Touch <[email-masked]> wrote:
> b) every packet would need to contain ALL the information needed to explain
> how to authenticate itself
>

Sorry, all I was trying to say was that the client doesn't need to
know what middleboxes are on the path at the time it sends its
first transport packet.  These are dynamically discovered as the
first packet passes along the path.

Certainly, if the path changes, some kind of path restoration will
be needed.  That could be done end-to-end by periodic refreshes
of the ESTABLISH message or by some middlebox that has knowledge
of the path change and is both on the old path and the new path.

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

http://cr.yp.to/ecdh/reports.html

This would be under a millisecond on modern processors in software.
Faster if hardware acceleration is available.  As Moore's law continues,
I expect that the connection setup time will be dominated by the
message propagation delay which will be one or two orders of magnitude
higher than this.

> 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.  I think we could get up to a substantial fraction of 1gpbs
even with a software implementation.  Hardware assist should have
no problem keeping up at higher line rates.

> How do you know when attackers are off-path?

It's just an assumption of the threat model in a particular deployment.
If you feel the need to protect against on-path attackers, by all means,
do a full HMAC over the packet.

> description of the costs (overhead, computation, etc).

Will work on this, thanks.

> Also how much effort will this require of the protected endpoints. I'm not
> sure I want to negotiate keys with a dozen middleboxes that all are trying
> to be helpful to me, and all are upstream on the same connection.

The number of middleboxes on any given path is likely to be proportional
to the number of administrative domains through which the packet passes.
I expect this will be less than 10 for most paths.  Also, the key derivation
only needs to be done once the first time you interact with a given hostname.
You should cache the Long-Term-Shared-Secret after that and use simple
HMACs to derive keys for subsequent transport connections.

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

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

-Pete

---

From: Joe Touch <[email-masked]>
Date: Sat, 11 Dec 2010 11:58:38 -0800

Hi, Pete,

On 12/11/2010 9:04 AM, Pete McCann wrote:
...
> 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.

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

...
> between adjacent middleboxes so only one signature per packet will

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.

> manually, no?  Public key cryptography offers more flexibility and security

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.

Joe

---

From: Pete McCann <[email-masked]>
Date: Sat, 11 Dec 2010 16:58:05 -0600

Hi, Joe,

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

> prohibitive for line-rate devices in the middle of the net as well.

Ok.  Need more data to answer this.

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

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

> 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

---

From: Joe Touch <[email-masked]>
Date: Sat, 11 Dec 2010 15:20:32 -0800

On 12/11/2010 2:58 PM, Pete McCann wrote:
> Hi, Joe,
>
> On Sat, Dec 11, 2010 at 1:58 PM, Joe Touch<[email-masked]>  wrote:

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.

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

> 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

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.

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

---

From: Pete McCann <[email-masked]>
Date: Sat, 11 Dec 2010 17:55:19 -0600

Hi, Joe,

On Sat, Dec 11, 2010 at 5:20 PM, Joe Touch <[email-masked]> wrote:
> 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.

Any of these statistics publicly available?
Do you really think all of these connections would be
from unique names that you don't have LTSS in cache for?

>> So, security associations could
> 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.

The nice thing about using DNS to do key distribution is that all this
would be set up automatically.  But you're right, the administrative
security policies would need to mesh up.

> First, 'out of band' can happen by whatever other mechanism - it's just not
> inside TCP-AO.

Yes, understood.

> benefit of public key is in this case. You could use public key to derive
> the shared key.

Right, I'm not saying it's not possible, just hasn't been specified.

The benefit of public key is that it makes the distribution of the key material
much easier.  You don't have to use sneakernet or have another, key-wrapping
key defined to push the symmetric key around the network where it might
be vulnerable to being intercepted.  Secret keys should stay in the place
where they are generated.

> algorithms for creating HMACs and a different one for validating them, at
> which point you could use asymmetric keys.

I'm not aware of any HMAC algorithms that work that way.  The typical
way this is done is to use public key to distribute a shared symmetric
secret and then use that in an ordinary symmetric HMAC.

> That's what AO would consider an out-of-band key Master_Key management

Agreed.

> specified, such a system would be external.

Yes.

-Pete

---

From: Joe Touch <[email-masked]>
Date: Sat, 11 Dec 2010 16:45:55 -0800

Hi, Pete,

On 12/11/2010 3:55 PM, Pete McCann wrote:
> Hi, Joe,
>
> On Sat, Dec 11, 2010 at 5:20 PM, Joe Touch<[email-masked]>  wrote:

We had some SSL accellerators that have published statistics; you should 
be able to find that on-line for modern products.

> from unique names that you don't have LTSS in cache for?

For a device near Google, probably not, but for one near Akamai, I would 
guess probably. Those stats will be harder to come by...

> security policies would need to mesh up.

Using the DNS to do key distribution does NOT mean automatic; it means 
you have an existing infrastructure that requires configuration. 
Configuration is the most challenging part, far as I've heard, of good 
key distribution.

...
> where they are generated.

There are ways to derive symmetric keys from asymmetric ones, though. 
The point is to not confuse required/desired properties of the primary 
keys that you need to deploy with the keys used to authenticate the traffic.

> secret and then use that in an ordinary symmetric HMAC.

If you're doing that, your HMAC-side is squarely in TCP-AO territory. 
The rest is a key distribution issue - which, for AO, is out of band, 
but that just means it's NOT in the AO portion. There's a bootstrapping 
issue if you include it in the TCP header, but you have that regardless.

Joe

---

From: Pete McCann <[email-masked]>
Date: Sat, 11 Dec 2010 23:35:06 -0600

Hi, Joe,

On Sat, Dec 11, 2010 at 6:45 PM, Joe Touch <[email-masked]> wrote:
> We had some SSL accellerators that have published statistics; you should be
> able to find that on-line for modern products.

A bit of googling seems to indicate that SSL accelerators can handle
a few thousand connections per second, and are a factor of 2 to 4 times
faster than doing it in software on the main CPU.

But, this bit of data doesn't really tell us much, if we are worried about
the new load imposed by adding secure key derivation to what was
previously a non-security-related middlebox, which I think is what
you were questioning.  But that's really an apples and oranges comparison.

> guess probably. Those stats will be harder to come by...

Indeed.

> Using the DNS to do key distribution does NOT mean automatic; it means you
> have an existing infrastructure that requires configuration. Configuration
> is the most challenging part, far as I've heard, of good key distribution.

Sure, you've got to generate public/private key pairs and publish the
public portion at the right place in DNS.  You've got to make sure that
the records are properly DNSSEC signed.  But this is an O(N) operation,
and once it's done, key distribution between any pair of boxes will happen
without intervention.

> There are ways to derive symmetric keys from asymmetric ones, though. The
> point is to not confuse required/desired properties of the primary keys that
> you need to deploy with the keys used to authenticate the traffic.

Diffie-Hellman is just such a derivation mechanism.  The use of public
key cryptography for the primary keys that are published in DNS means
we can avoid an O(N^2) blowup in the manual configuration of symmetric
keys that need to be unique between every pair of communicating entities.

> If you're doing that, your HMAC-side is squarely in TCP-AO territory.

Yes it is very similar, but doesn't cover the IP or transport headers.
I thought draft-touch-tcp-ao-nat-01.txt was a good idea.  Has it been
decided not to pursue it?

> The
> rest is a key distribution issue - which, for AO, is out of band, but that
> just means it's NOT in the AO portion. There's a bootstrapping issue if you
> include it in the TCP header, but you have that regardless.

Agreed, the contribution of pickle packets here is to point out that if
we include the DNS names of sender and receiver in the initial transport
connection, we can use them to index the public keys that can be retrieved
from DNS and used to establish a Master_Key or something similar.
You could use this key for AO if you wanted.

-Pete

---

From: Joe Touch <[email-masked]>
Date: Sat, 11 Dec 2010 21:38:10 -0800

...
> decided not to pursue it?

It is intended to move forward as experimental. We haven't had a 
decision on making it a WG doc yet (not sure why). There's not much to 
do except have the WG agree, then move forward to last call. Maybe a 
little editing.

Joe