On Tue, Aug 05, 2014 at 10:24:52AM -0700, Joe Touch wrote: > On 8/5/2014 9:58 AM, Nico Williams wrote: > >Your posts have been more of the "this is not good, stop it" vein than > >"the proposal is inconsistent with the WG charter [details]". You > >can't have it both ways either. Please provide details or stop > >distracting. > > I did.
Let's take your summary point by point then (thanks for writing it). > To repeat in summary, the charter mandates a TCP solution based on > deployability to address pervasive monitoring. However: > > - unauthenticated anything protects against only shared-media > monitoring. the kind of pervasive monitoring I believe motivated > the BCP is at firewalls or routers on-path, and those can > easily act as MITM You missed the point and treat the rest of us as blithering idiots. I will answer this and your other two points below once. Beyond that the charter was recently approved, so fundamental changes to it are out. If you don't like it, too bad, you'll have to wait. > so any unauthenticated approach is likely not to suffice to > address the BCP that is the primary motivation of this work I don't agree. See below. > - there is no evidence that a TCP layer solution is easier > to deploy or that a kernel-based solution is easier to deploy, > or that the two are inextricably linked That's kind of irrelevant at this stage IMO. Also, I don't think that's true. We do know that: a) application-layer solutions require changes to applications, b) IPsec-based solutions (BTNS w/ connection latching) failed to get momentum. Therefore it follows that a solution below the app layer and above IP may work. Authentication is very difficult to do below the app layer without involving the application... because authentication is very difficult to do correctly without involving the application! Therefore it follows that the thing to provide is unauthenticated key exchange and "hooks for authentication" (which I read to include channel binding). > - there is no reason that a TCP layer solution is appropriate > if we're concerned about monitoring This effectively a repetition of the first item. If you're concerned about *massive* monitoring then *any* unauthenticated key exchange solution will greatly raise the cost of monitoring by forcing the adversary to deploy active (MITM) attacks instead of / in addition to passive attacks. Especially if the solution gets massive deployment. Massive active monitoring is much, much more expensive than massive passive monitoring: minimally there all the additional key exchanges, decryption and re-encryption to do, but there's also a lot of infrastructure work to do get that equipment in the middle. Perhaps fabulously more expensive, at least initially, though in the long run it may become more of a marginal cost of doing business. That you don't understand this tells me you've not been paying attention. > >(BTW, reviewing the charter just now, my only complaint is that > >channel binding is not mentioned, but I think it arguably falls under > >"hooks for authentication", and anyways, lack of presence in the > >charter is not really a problem, since channel binding is a no-brainer > >for this protocol.) > > Channel binding cannot be added post-facto; hooks for authentication > might not be sufficient for channel binding, and isn't there also a > need for connection latching that isn't addressed at all in the > charter? That's ridiculous. It's trivial to define the channel bindings for a TCP security protocol with unauthenticated key agreement. If key agreement is by [EC]DH, then something like: CB = H(H(client's public key) || H(server's public key)) will do. This can most definitely be added later. If I'd been paying attention at the time I'd have insisted on an explicit mention of channel binding in the charter. But I don't think this is a big problem, and adding CB to the charter -I'm sure- will not be a problem if we think we have to. Nico -- _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
