On 08/16/2014 02:18 PM, John-Mark Gurney wrote:
Brandon Williams wrote this message on Fri, Aug 15, 2014 at 17:59 -0400:
On 08/15/2014 01:37 PM, John-Mark Gurney wrote:
Brandon Williams wrote this message on Fri, Aug 15, 2014 at 10:36 -0400:
On 08/08/2014 12:47 PM, Nico Williams wrote:
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.
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?
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?
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
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.
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.
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?
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...
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.
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...
That's true, but tcpcrypt is not the only proposal.
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.
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...
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?
--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
