Subject: Re: [tcpinc] Charter should mention channel binding (Re: why not just TLS on secure port numbers?)

From: Brandon Williams <[email-masked]>
Date: Fri, 08 Aug 2014 12:09:37 -0400

Hi Nico,

I have concerns (expressed in an earlier post to the list) about binding 
the authenticators used for the data stream with authenticators used for 
TCP. If I've understood the earlier discussion on this thread and the 
content of RFC5056, you are suggesting that such bindings should be 
supported but not required. Is that correct?

Also, I'm curious about how you would envision this working in the case 
of, for example, a TCP optimization proxy where the endpoints of the TCP 
connections are not the same as the endpoints of the secure data stream. 
Do you think it's possible to design a channel binding solution that 
supports an authorized MITM while at the same time mitigating the risk 
of an unauthorized MITM without requiring the client-side application 
(at least) to know whether an authorized MITM is in use?

Basically what I'm trying to wrap my head around is the question of 
whether channel binding might prevent such middleware from functioning 
effectively, and also whether adoption of the proposed requirement (if 
it is adopted) might imply that the WG sees breaking such middleware as 
desireable.

Thoughts?

--Brandon

On 08/05/2014 05:10 PM, Nico Williams wrote:
> On Tue, Aug 05, 2014 at 01:44:19PM -0700, Christian Huitema wrote:
>> Absolutely. By the way, having hooks like the unique session-ID of TCP
>> Crypt is essential. It allows applications to implement a simple MITM
>> detection as part of an end-to-end authentication process. All
>> applications may not implement that, but some will. That creates lots
>> of uncertainty for any MITM attacker, because they now have a clear
>> risk of being detected.
>
> It would be useful if the charter were to mention channel binding.  It
> follows from everything else in the charter that channel binding is not
> only not precluded but should be possible for any WG products that
> adhere to the charter.  However, it wouldn't hurt to make channel
> binding support a requirement.  In particular it would make it easier to
> avoid accidentally desiging a "session ID" that is not suitable as a
> channel binding.
>
> Yes, I did not participate in the charter discussions; the absence of CB
> in the charter is my fault to some degree.  But adding it would be a
> very minor change with no significant costs to the WG.
>
> Nico
>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: Nico Williams <[email-masked]>
Date: Fri, 8 Aug 2014 11:47:43 -0500

On Fri, Aug 08, 2014 at 12:09:37PM -0400, Brandon Williams wrote:
> I have concerns (expressed in an earlier post to the list) about
> binding the authenticators used for the data stream with
> authenticators used for TCP. If I've understood the earlier
> discussion on this thread and the content of RFC5056, you are
> suggesting that such bindings should be supported but not required.
> Is that correct?

Well, I think the TCP security protocol should have to support channel
binding in that it should support outputting CB data for applications to
use.  Use of CB should be optional, of course.

Note that for any protocol using key agreement it's trivial to produce
channel bindings.  We're not talking about an onerous requirement.

There's only a relatively minor considerations, which is that the
implementations can't keep large public keys around, so they need to be
hashed as soon as possible and the hashes used for the construction of
CB data -- like TLS Finished messages, for example.  Of course, with
ECDH this isn't much of a concern anyways.

> Also, I'm curious about how you would envision this working in the
> case of, for example, a TCP optimization proxy where the endpoints
> of the TCP connections are not the same as the endpoints of the
> secure data stream. Do you think it's possible to design a channel

Each end-point has to trust its proxy and the proxy has to communicate
the correct CB to the local end-point.

> binding solution that supports an authorized MITM while at the same
> time mitigating the risk of an unauthorized MITM without requiring
> the client-side application (at least) to know whether an authorized
> MITM is in use?

Yes.  See above.

This is not the first time that we've discussed CB in the context of
proxies.  We've talked about it endlessly in the context of HTTP
proxies, and it's clear how to handle it.

Not supporting CB means that applications that want authenticated
security can't use this protocol unless this protocol provides that
authentication.  But applications tend to have different authentication
requirements at their layers than lower layers do -- retrofitting
authentication into TCP would quickly develop all the problems that TLS
user authentication has, and then some (because the typical
user-mode<->kernel-mode barrier will tend to limit API complexity).

Having neither CB nor authentication in this protocol may risk double
encryption or forgoing authentication in some cases.  That would be
disastrous.

Nico
--

---

From: Brandon Williams <[email-masked]>
Date: Fri, 15 Aug 2014 10:36:35 -0400

> the correct CB to the local end-point.

Well, yes, it's clear that would be necessary. I don't see how that 
would be accomplished if the proxy doesn't have direct access to the 
data stream security context. Doesn't the CB have to be delivered on an 
encrypted data channel in order to prevent an unauthorized MITM from 
seeing and misusing it?

> user-mode<->kernel-mode barrier will tend to limit API complexity).

Having worked this out for an application layer proxy scenario doesn't 
automatically mean that it will work for a transport layer proxy. All of 
the CB binding examples I can find appear to delegate security 
responsibility downward in the protocol stack ... typically application 
layer protocols binding to a lower layer secure channel like IPSec, TLS, 
or SSHv2. My question is specifically about delegating security 
responsibility upward; using the security context of an end-to-end 
authenticated and encrypted channel to authenticate the TCP headers for 
connections that are not end-to-end. How would this be done in a way 
that doesn't allow a MITM that is authorized to terminate the TCP 
connection from making unauthorized changes to the secure end-to-end 
data stream?

If you've got a document or archived e-mail thread that you can point me 
at that discusses this, I'll be happy to just read up on the problem. I 
haven't been able to find such a document yet.

--Brandon

---

From: John-Mark Gurney <[email-masked]>
Date: Fri, 15 Aug 2014 10:37:15 -0700

> encrypted data channel in order to prevent an unauthorized MITM from 

How can they misuse it?

If you're thinking someone MITM's the connection, well, then they'd
have to be using a trusted key to sign the CB data, and then the
failure is w/ the authentication, not w/ the CB, or are you thinking
of another misuse?

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

---

From: Brandon Williams <[email-masked]>
Date: Fri, 15 Aug 2014 17:59:03 -0400

> failure is w/ the authentication, not w/ the CB, or are you thinking

I think I'm just not expressing myself clearly enough, so I'll try again 
from the beginning.

If I understand what I've read about channel binding, the idea is for 
one layer in the protocol stack to delegate authority for some part of 
its security requirements to another layer in the protocol stack that 
has similar security properties. If you have a transport layer 
optimization proxy that is trusted to terminate TCP connections but not 
trusted to look into or modify the secure end-to-end data stream, how 
does channel binding apply?

If the TCP header is not being authenticated, then channel binding 
doesn't apply at all on the proxy because there are no security 
requirements for TCP. If the TCP header is being authenticated, there 
are security requirements for TCP, but they aren't shared with the 
end-to-end data channel. The fact that a received header has been 
authenticated doesn't mean anything for the data that was delivered in 
the header, since the expectation is that data will have been unmodified 
along the whole path. Authentication for the header and the data cannot 
be combined in this case, because authentication for the data must show 
that the data was unmodified end-to-end, while there is no such 
expectation for the header. I don't see an opportunity for security 
authority delegation that involves TCP.

--Brandon

---

From: John-Mark Gurney <[email-masked]>
Date: Sat, 16 Aug 2014 11:18:46 -0700

> its security requirements to another layer in the protocol stack that 

Well, lets be sepcific here.. it's to allow the authentication layer
be able to authenticate that the encrypted connection has not been
MITM or tampered with.

> does channel binding apply?

And by terminate TCP connection, I assume you mean to deframe and
sequence the session?  Why does an optimizing proxy need to do this
work?

So, why can't the optimizing proxy just queue up the frames and resend
them unmodified back out?  Yes, it'll be more work, but an optimizing
TCP proxy is already doing extra work (like it shouldn't be acking data
till the other side ack's it, etc)...

btw, I do realize people want to make these optimizing proxies, but
I think that at least for tcpcrypt, storing frames and retransmitting
them would be the easiest way, and keep the MAC's intact w/o having
to modify the protocol significantly to support these...

> If the TCP header is not being authenticated, then channel binding 

Turns out tcpcrypt protects quite a bit of the TCP header...  see
Figure 2 on page 6 for what is protected...

> authority delegation that involves TCP.

Why do proxies need to even modify the header?  The fact that there are
sooo many middle boxes that modify and refrace tcp got us into this
situation in the first place, that expanding and adding features to TCP
is extremely difficult...  If they had just saved the whole frame for
retransmission, things would have been a lot easier...

---

From: Brandon Williams <[email-masked]>
Date: Mon, 18 Aug 2014 09:10:07 -0400

> be able to authenticate that the encrypted connection has not been

The RFCs to appear to be quite that specifically related to encrypted 
connections, but focusing there is fine, since that's what tcpinc is 
focused on.

> to modify the protocol significantly to support these...

I can certainly see that a whole different architecture for the proxy 
could make it easier to support tcpcrypt, but that's just as much a 
result of how tcpcrypt is designed as it is the design of the proxy. A 
proposal that doesn't integrity check the TCP header and the data stream 
as a single unit would not have this problem.

> Figure 2 on page 6 for what is protected...

That's true, but tcpcrypt is not the only proposal.

> retransmission, things would have been a lot easier...

I see the question of why a proxy might be designed this way as a 
rathole for the list. The fact of the matter is that there are a broad 
range of such middle boxes, and I don't think that this WG's efforts are 
going to drive middleware vendors to completely redesign their 
technology (at least not in the near term), regardless of whether some 
WG participants think that the vendors have made bad design choices. On 
the other hand, middleware vendors might go to the trouble of supporting 
tcpinc if it is not designed in a way that prevents them from doing so.

This leads me to the question of what our goal is relative to such 
middleware. Do we want to positively influence adoption by ensuring 
interoperability with these types of boxes? Or do we want to declare 
these boxes to be part of the problem and explicitly not support them, 
despite the fact that it may slow adoption of the protocol?

---

From: Nico Williams <[email-masked]>
Date: Mon, 18 Aug 2014 12:44:35 -0500

On Sat, Aug 16, 2014 at 11:18:46AM -0700, John-Mark Gurney wrote:
> > If I understand what I've read about channel binding, the idea is
> > for one layer in the protocol stack to delegate authority for some
> > part of its security requirements to another layer in the protocol
> > stack that 

> be able to authenticate that the encrypted connection has not been

Here's another:

  You want application-layer authentication (because, e.g., lower-layer
  auth won't do for some reason), and you don't want to double encrypt
  (once at the TCP layer, again at the app layer) because that'd be a
  terrible waste of resources.

If you don't allow for channel binding then you'll either:

a) limit this protocol only to unauthenticated encryption, forcing apps
   that need authentication to either disable this protocol or
   double-encrypt;

b) be forced to add authentication options to the protocol that satisfy
   a large range of application authentication needs.

Do you really want either of those?  I seriously doubt it.

To be fair there are use cases with a happy middle of the road:
authenticate the server with, say, DANE or a reasonably strong PKI
(i.e., with few trust anchors) and use the server's name as the "channel
binding".  For TCP this would manifest as something like a socket option
or sockaddr extension by which the app can tell TCP what server name it
wants.  But that's not enough for at least some important use cases.

Back to leaving session crypto to lower layers...  That's desirable for
several possible reasons:

 - HW might do better at offloading the crypto.  That was/is reasonable
   for the IPsec case, but it's more of a stretch for the TCP case.

 - To reduce the number of cryptographic contexts needed for multi-user
   application protocols like NFS.

 - NEW since RFC5056: opportunistic security means you might get a
   lower-layer secure channel even if you could provide your own.

   Heck, we might end up with a situation in which the application
   necessarily will get a lower-layer secure channel no matter what
   (e.g., to avoid fingerprinting of application protocols).

If you want to avoid double-crypto, and also want to avoid pushing
authentication down to lower layers, then you really want channel
binding.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 18 Aug 2014 15:33:22 -0500

On Fri, Aug 15, 2014 at 10:36:35AM -0400, Brandon Williams wrote:
> data stream security context. Doesn't the CB have to be delivered on
> an encrypted data channel in order to prevent an unauthorized MITM
> from seeing and misusing it?

Generally "yes", but for some systems the network between them and the
proxy might be considered secure (e.g., physically, or perhaps using
IPsec).  In any case, this protocol should be composable for the proxy
case: tcpcrypt to the proxy, proxy tcpcrypts to the server (or server's
proxy, which then might tcpcrypt to the server).

> [...  "this" == CB with trusted proxies in the path  ...]
> Having worked this out for an application layer proxy scenario
> doesn't automatically mean that it will work for a transport layer
> proxy. [...]

Why wouldn't it?

> [...]. All of the CB binding examples I can find appear to delegate
> security responsibility downward in the protocol stack ... typically
> application layer protocols binding to a lower layer secure channel
> like IPSec, TLS, or SSHv2. [...]

Answered separately.

>                     [...]. My question is specifically about
> delegating security responsibility upward; using the security
> context of an end-to-end authenticated and encrypted channel to
> authenticate the TCP headers for connections that are not
> end-to-end. How would this be done in a way that doesn't allow a
> MITM that is authorized to terminate the TCP connection from making
> unauthorized changes to the secure end-to-end data stream?

Well now, TCP headers are supposed to be end-to-end.  If middleboxes
must be able to mess with those headers then the protocol design has to
be more careful but it can still be made to work because what we're
after isn't "integrity protection for headers" but "integrity (and
confidentiality) protection for [two paired] octet streams".

Once you cast the problem in that mold it is easier to see that a
requirement for CB doesn't interfere with the trusted middleboxes nor
middleboxes that are not trusted but which are allowed to do things like
reframe the streams (if indeed such middleboxes must be tolerated).

> If you've got a document or archived e-mail thread that you can
> point me at that discusses this, I'll be happy to just read up on
> the problem. I haven't been able to find such a document yet.

Probably in the KITTEN WG list archives from a few years ago.  The
subject was trusted HTTP proxies, not meddlesome untrusted middleboxes.

Nico
--

---

From: John-Mark Gurney <[email-masked]>
Date: Mon, 18 Aug 2014 15:42:59 -0700

> as a single unit would not have this problem.

what about RST?  Also, I don't see a way to have a protected data stream
if you don't at least protect the sequence numbers... If you don't, then
you have replay and injection attacks, or its harder to reject invalid
packets, etc...

If you belive that it is possible to do this, then please, put forward
a proposal along w/ security proof and description of attack senarioes..

I have reviewed the security considerations on the other proposals,
and I must say that they need to be fleshed out...  The TLS one is
especially lacking in details...  It says nothing about various attacks
that it is vulnerable to...  The others aren't much better...

> tcpinc if it is not designed in a way that prevents them from doing so.

Currently, only one of the four proposals does not protect the TCP
header, and that one TLS...  Not protecting the header makes it
extermely easy to DoS the connection, since it specificly states that
any invalid payload will cause the connection to be torn down...  This
is because it can't reject fake incoming data, and once the data has
been received, it can't know where to rewind state to (well, it could,
but I'd hate to think about what that would do to the TCP state
machine)...

So, from the looks of it, the TCP header will likely be protected in
one of the chosen solutions...

And remeber, the IETF is proposing TCP in UDP because of these
middleware boxes...  I can't wait till the day we do TCP in UDP in UDP
(turtles all the way down) because the middleware boxes become aware
of TCP in UDP, etc. etc.  The IETF needs to address the broken
middleware box issue, but obviously, not in this forum...

> despite the fact that it may slow adoption of the protocol?

This is a very good question to have answered.

We cannot make any compromises to support middleware boxes that would
prevent us from providing the security stated by the charter...  That
includes various bits about not authenicating parts of the header... If
we do that, then we might as well never produce a standard...

I was concerned about supporting middleware boxes, but now that I
thought of the store and forward idea, I don't have any worries... Yes,
it might be a bit more work for the middleware boxes, but supporting
any new protocol/option (which they rarely do, so, no loss there)
requires work...  If they are interested in this discussion, they'll
join and add their insight, but breaking the charter doesn't make
sense...

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 18 Aug 2014 16:00:02 -0700

On Mon, Aug 18, 2014 at 3:42 PM, John-Mark Gurney <[email-masked]> wrote:

> > >>>>>binding in that it should support outputting CB data for
> applications
> > >>>>>to
> an

It's pretty important to distinguish between attacks that result in bogus
data being accepted and those which result in the connection being
torn down or otherwise failing. To make this point sharp, consider
ordinary TLS over TCP such as with TLS. Because the TLS records
include a sequence number, if the attacker injects his own traffic
or reorders it, it should be detected at the TLS layer, but not at
the TCP layer, with the result that any tampering causes
connection failure making it susceptible to DoS.

> that it is vulnerable to...  The others aren't much better...

I'll see what I can do in the next draft.

> one of the chosen solutions...

Maybe.

The problem here is that you either protect RST or you don't. If you
do protect RST, then it causes problems with resynchronization after
loss of state (e.g., machine reboot). If you don't protect RST, then
an attacker can just inject an RST and so it's not clear it's worth
protecting against other attacks on the header, as long as you
have integrity mechanisms for the payload itself.

Stepping up a level, it seems important to figure out what we are
trying to achieve with DoS prevention. An on-path attacker can just
suppress tcpinc negotiation or block packets until the TCP state
machine gives up. So, this mostly applies to off-path attackers? But
for most settings, just having it be relatively difficult for an off-path
attacker to DoS the connection would probably be OK, since you
have application layer mechanisms that deal with other types of
network failure anyway. The big exception here is BGP, but that
has already adopted AO for integrity.

-Ekr

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 23 Aug 2014 10:41:22 -0700

> machine gives up. So, this mostly applies to off-path attackers? 

Actually, we already have evidence of "listen in the middle, inject from the side." It would be nice to protect against such attacks. That means preventing RST injection.

> But
> network failure anyway. 

Looking at the big picture, an encrypted TCP can be naturally extended to support multi-homing. If we do that, then we will regret giving misbehaving on-path agents a way to DOS a connection.

In fact, it seems that the reasonable balance is to empower the endpoints of the TCP connection. Detect that an RST is not signed, and let the end point decide whether to believe it or to ignore it. Use channel binding to detect MITM, then let the application decide whether to continue using the MITM connection or not. Etc.

-- Christian Huitema

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 18 Aug 2014 20:14:30 -0700

On Sat, Aug 23, 2014 at 10:41 AM, Christian Huitema <[email-masked]>
wrote:

> Actually, we already have evidence of "listen in the middle, inject from
> the side." It would be nice to protect against such attacks.

Can you be a bit more explicit about what you are referring to
here?

> That means preventing RST injection.

See above for the consequences of this.

-Ekr

> Looking at the big picture, an encrypted TCP can be naturally extended to
> support multi-homing. If we do that, then we will regret giving misbehaving
> on-path agents a way to DOS a connection.
>

In fact, it seems that the reasonable balance is to empower the endpoints
> of the TCP connection. Detect that an RST is not signed, and let the end
> point decide whether to believe it or to ignore it. Use channel binding to
> detect MITM, then let the application decide whether to continue using the
> MITM connection or not. Etc.
>

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 18 Aug 2014 21:21:30 -0700

> Can you be a bit more explicit about what you are referring to here?

Referring to the QUANTUM attacks (http://www.wired.com/2014/03/quantum/, https://www.techdirt.com/articles/20131004/10522324753/how-nsa-pulls-off-man-in-the-middle-attacks-with-help-telcos.shtml). 

> See above for the consequences of this.

I think that by now, we all understand the tradeoff. If we want to prevent illegitimate RST attacks, we will also prevent use of unprotected RST by rebooting hosts. Which is why I believe the protocol should be able to differentiate between protected RST, which should be processed immediately, and unprotected RST, which should be treated according to host policy.

-- Christian Huitema

---

From: Derek Fawcus <[email-masked]>
Date: Tue, 19 Aug 2014 02:36:49 -0700

> I think that by now, we all understand the tradeoff. If we want to prevent illegitimate RST attacks, we will also prevent use of unprotected RST by rebooting hosts. Which is why I believe the proto…

Yeah - that does strike me as about the best we can achieve for RST.

Maybe some recommendations for the policy,  but ultimately down to policy for the unprotectable RST cases.

.pdf

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 19 Aug 2014 11:51:35 +0200

Christian,

> In fact, it seems that the reasonable balance is to empower the endpoints of the TCP connection. Detect that an RST is not signed, and let the end point decide whether to believe it or to ignore it…

I agree with you but instead of extending an encrypted TCP to support 
multihoming, we could extend Multipath TCP to support encryption.

Looking at the RST attack which is currently discussed, Multipath TCP 
already provides a solution to cope with this attack. Since Multipath 
TCP supports make before break and break before make, the reception of a 
RST on a subflow (even if there is only one subflow) would terminate 
this subflow but not the Multipath TCP connection. A Multipath TCP host 
that receives a RST can simply recreate a new subflow and the connection 
(as seen from the application) would continue. The reception of the RST 
would cause a small interruption of the dataflow (during the 
reestablishment of one subflow), but this is similar to classical 
retransmissions for packet losses. This works for TLS, SSH, BGP or 
whatever application runs above Multipath TCP.

Although this WG was chartered to extend regular TCP and not Multipath 
TCP, I think that Multipath TCP already contains several mechanisms 
(subflow management, middlebox interference, data sequence numbers 
notably) that will be very useful for any TCPinc proposal.

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

---

From: Brandon Williams <[email-masked]>
Date: Tue, 19 Aug 2014 08:53:31 -0400

> proxy, which then might tcpcrypt to the server).

This approach does not meet the security requirements that I'm 
interested in: MITM is authorized to reframe the data stream for 
transport optimization purposes, but is not authorized to decrypt or 
inject data. Splitting transport layer authentication at the TCP 
termination points could be done without violating the security policy, 
but splitting tcpcrypt could not, at least not as it's currently defined.

>> doesn't automatically mean that it will work for a transport layer

An application layer proxy is authorized to view and modify decrypted 
data. A transport layer proxy does not necessarily have this authorization.

> confidentiality) protection for [two paired] octet streams".

The data stream is end-to-end, but the TCP connections are not, which is 
why the security requirements at the transport layer are distinctly 
different from the security requirements at the higher layers.

> reframe the streams  (if indeed such middleboxes must be tolerated).

The question of whether such boxes must be tolerated is the one that I'm 
primarily trying to answer.

--Brandon

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Aug 2014 11:07:46 -0500

On Tue, Aug 19, 2014 at 7:53 AM, Brandon Williams
<[email-masked]> wrote:
> This approach does not meet the security requirements that I'm interested
> in: MITM is authorized to reframe the data stream for transport optimization
> purposes, but is not authorized to decrypt or inject data. Splitting
> transport layer authentication at the TCP termination points could be done
> without violating the security policy, but splitting tcpcrypt could not, at
> least not as it's currently defined.

If the octet stream has nested framing (basically a length an
authentication tag) then the properties you want can be had and you
can still have CB and the proxy needn't be trusted.

It costs more overhead, but not because of CB but because what you
want + integrity protection pretty much requires extra overhead
(unless I'm missing something).

If you want encryption without integrity protection, then I'm afraid
that's a bad idea.

Nico
--

---

From: Brandon Williams <[email-masked]>
Date: Tue, 19 Aug 2014 13:08:41 -0400

> a proposal along w/ security proof and description of attack senarioes..

I'm definitely not suggesting that it's a bad idea to authenticate TCP 
headers. I'm simply suggesting that combining TCP header authentication 
with data stream authentication could break a specific existing type of 
middleware.

> but I'd hate to think about what that would do to the TCP state

IIRC, the TLS proposal doesn't ignore this entirely. It simply states 
that tcp-ao can be used for this purpose and that tcpinc doesn't have to 
provide the capability.

> one of the chosen solutions...

I haven't seen this clear consensus from the WG so far, which is part of 
what drove the "why not just TLS?" thread to begin with. That said, I'm 
not arguing that the protocol should or shouldn't authenticate the 
header. I'm focused only on what I see as the implications of the 
proposed methods for providing such authentication.

> join and add their insight, but breaking the charter doesn't make

My goal in engaging in this discussion is exactly that, to bring the 
perspective of a middleware vendor who desires to support the protocol 
that comes out of this WG's efforts. I'm definitely not asking for the 
charter to be compromised. I'm just trying to figure out whether it will 
be possible for my system to support the resulting protocol without 
sacrificing my customers' security requirements. It's not clear to me 
that separating TCP header integrity checks from encrypted data stream 
integrity checks would necessarily compromise the charter, but I also 
understand that the eventual WG consensus might not be with me.

--Brandon

---

From: Brandon Williams <[email-masked]>
Date: Tue, 19 Aug 2014 16:20:44 -0400

> can still have CB and the proxy needn't be trusted.

Agreed, provided that the authentication on the nested framing doesn't 
extend to the TCP headers themselves, as in some of the proposals.

> (unless I'm missing something).

Agreed, though the extra overhead for framing shouldn't be too bad. Or 
are you thinking of overhead from something more than just the effort of 
framing the octet stream?

> If you want encryption without integrity protection, then I'm afraid

Agreed. That's definitely not something I would suggest.

--Brandon

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Aug 2014 18:39:35 -0500

On Tue, Aug 19, 2014 at 04:20:44PM -0400, Brandon Williams wrote:
> >>[...]
> Agreed, provided that the authentication on the nested framing
> doesn't extend to the TCP headers themselves, as in some of the
> proposals.

Right.  This is really like TLS-over-TCP, really, at least as to the
"record layer".

> Agreed, though the extra overhead for framing shouldn't be too bad.

Right.  The authentication tag you need anyways, so it's really just a
length field, which needn't be that long since it often doesn't pay to
encrypt in large chunks (for cache effect reasons, but this applies
mainly to general purpose CPUs).  Two bytes should suffice; its size
could always be negotiated.

> Or are you thinking of overhead from something more than just the
> effort of framing the octet stream?

No, just that.

> Agreed. That's definitely not something I would suggest.

Alright, so you agree that CB is feasible then, yes?

Nico
--

---

From: Brandon Williams <[email-masked]>
Date: Wed, 20 Aug 2014 09:27:55 -0400

Yes, I definitely think it's feasible. It hasn't been my intention to 
suggest that channel binding is infeasible or that building support for 
it into the protocol would be a bad idea. I've really just been trying 
to figure out what the implications might be (if any) for a certain type 
of middleware.

It's still my opinion that binding TCP header integrity/authentication 
to either data stream or application layer security would most likely 
prevent this type of middleware from using the protocol, and so I would 
prefer to see the protocol allow but not require such integration.

For example, hooks that allow tcp-ao keys to be used by tcpinc would 
provide the capability to prevent an unauthorized MITM while at the same 
time allowing for an authorized transport layer MITM to be used. I think 
that such an approach would meet your proposed channel binding support 
goal with sacrificing the flexibility the system I'm concerned about 
would require.

--Brandon

---

From: John-Mark Gurney <[email-masked]>
Date: Thu, 21 Aug 2014 14:53:15 -0700

Olivier Bonaventure wrote this message on Tue, Aug 19, 2014 at 11:51 +0200:
> >the side." It would be nice to protect against such attacks. That means 
> >preventing RST injection.
> >
> >>But
> >support multi-homing. If we do that, then we will regret giving 
> >misbehaving on-path agents a way to DOS a connection.
> >

Though if the new subflow uses a different key, we'd need a way to
signal the upper layers to reauth the new channel, otherwise it'd be
a great way to MITM an authenticated connection...

---

From: Nico Williams <[email-masked]>
Date: Thu, 21 Aug 2014 16:59:28 -0500

> a great way to MITM an authenticated connection...

Oh, if there's any way to bind the first to the previous then there's no
problem, otherwise, yes, there's a problem.  Since we're assuming
(right?) that neither endpoint has crashed/rebooted yet, it seems fair
to mix in the previous flow's session keys into the new flow's session
key derivation, which cures the problem.

(Just as in TLS renego (since it was fixed) and SSHv2 renego.)

Make before or after break makes no difference, as long as the previous
flow's TCB is still around.

> > notably) that will be very useful for any TCPinc proposal.

Well, presumably it's enough to say that TCPinc should work with
Multipath TCP.  No?

Nico
--