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

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

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.




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


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



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

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
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc

Reply via email to