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