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.
> 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...
> 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...
> 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...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
