On 8/5/2014 11:26 AM, Nico Williams wrote:
On Tue, Aug 05, 2014 at 10:24:52AM -0700, Joe Touch wrote:
...
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 MITMYou missed the point and treat the rest of us as blithering idiots.
The point is - as you point out later well - to raise the bar for the attacker. We all know this - that was the point back in the days of BTNS that we both promoted, and it's the point here. But if that's the point, it needs to be used consistently.
Notably, the need for 4000-bit DH keys isn't relevant. Even a short DH key puts up the barrier that an attacker needs DH infrastructure and to participate on both sides of the connection.
So again, we need to be clear about what we're trying to solve and what benefits it is intended to provide, not merely accepting charter requirements as valid.
- 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 linkedThat'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.
The layer isn't what's relevant; deployability is. Yes, the IPsec-based solution failed to gain momentum, but that could be because of the layer, the implementation (typically in the OS), or the baggage that came with the name.
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!
Authentication could easily be based on IP addresses and provide assurances that upgraded apps can validate, but that legacy apps can ignore. That's no different regardless of what layer it's done at.
Therefore it follows that the thing to provide is unauthenticated key exchange and "hooks for authentication" (which I read to include channel binding).
It could easily follow that we should tie our solution into something like DANE where we have the OS lookup keying info in the DNS too.
Joe _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
