On 5/08/2014 18:24 pm, Joe Touch wrote: > 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
This ignores the attacker's cost equation. An attacker in (eg) a firewall or router on-path can monitor any traffic if it is in the clear without any cost and without leaking its activity. If an attacker has to do an MITM and crypto, this is an active attack. It incurs a cost of running those two TCPIncs (2 x crypto so let's make it slower ;) and it now leaks evidence of its activity because the two end points are using different secrets. This is a risk which attackers in the PM category will not want to run without some care. This cost will drive them to target their MITMs. Which is not PM. That's what we want. The point of this thrust is to kill PM by forcing some costs on the attacker and forcing them to target their attacks based on their costs and their risks. Additionally, API hooks can help caller to bind/check/whatever. But this is a secondary consideration within an overall strategy: + First we get in place unauthenticated encryption. + Second, add some hooks in so that callers can check. + Third, add some auth in at that layer too. ... So, yes. This WG does not require auth, and expects there to be none. That's a pragmatic decision. If your proposal however did auth as well, for the price of the unauth, then I don't think anyone would grumble. (Idk, I haven't looked...) > so any unauthenticated approach is likely not to suffice to > address the BCP that is the primary motivation of this work In short, unauthenticated approachs do destroy PM because they add some costs and some risks which forces targetting. It also lays groundwork for the future... > - 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 > > - there is no reason that a TCP layer solution is appropriate > if we're concerned about monitoring > > In fact, the charter starts from a position of wanting to protect > traffic from monitoring, but jumps to the conclusion that a TCP solution > is needed. What fraction of TCP traffic isn't already protected from > monitoring by TLS, I've nothing to hand or recent, but the number of websites indicates something like a 100 to 1 ratio of HTTP to HTTPS. I've seen some old figures on ipv6 that indicates that encrypted traffic was like 3% of total. > and what fraction is TCP of the total traffic > potentially being monitored? That's a speculation, they aren't telling us. Indications from the Snowden documents are that they are trying to do all of it. AS far as I've seen, the capacity they are installing into the major hubs seems to track the capacity of the switches/fibres used for net. But, it is totally fruitless to speculate here. Perhaps easier to simply assume that it is all of it. > This is a clear case of the streetlight effect. > (http://en.wikipedia.org/wiki/Streetlight_effect) No, Snowden documents cleared that up fairly clearly. iang _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
