Brandon Williams wrote this message on Mon, Aug 18, 2014 at 09:10 -0400:
> 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.
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...
> >>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.
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...
> 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?
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...
--
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
