I participated for two days last week in the joint W3C/IETF (IAB) workshop on
Strengthening the Internet against Pervasive Monitoring (aka STRINT).
Now that the IETF has declared pervasive monitoring of the Internet to be a technical attack the
goal of the workshop was to establish the next steps to take in
reaction to the problem. There were ~100 members of the
Internet engineering and policy communities participating - HTTP/2 standardization is an important test case to see if we're serious about following through.
I'm pleased that we were able to come to
some rough conclusions and actions. First a word of caution: there is no official report yet, I'm certainly not the workshop secretary, this post only reflects transport security which was a subset of the areas discussed, but I still promise I'm being faithful in reporting the events as I experienced them.
Internet protocols need to make better use of communications security and more encryption - even imperfect unauthenticated crypto is better than trivially snoopable cleartext. It isn't perfect, but it raises the bar for the attacker. New protocols designs should use strongly authenticated mechanisms falling back to weaker measures only as absolutely necessary, and updates to older protocols should be expected to add encryption potentially with disabling switches if compatibility strictly requires it. A logical outcome of that discussion is the addition of these properties (probably by reference, not directly through replacement) to BCP 72 - which provides guidance for writing RFC security considerations.
At a bare minimum, I am acutely concerned with making sure HTTP/2 brings more encryption to the Web. There are certainly many exposures beyond the transport (data storage, data aggregation, federated services, etc..) but in 2014 transport level encryption is a well understood and easily achievable technique that should be as ubiquitously available as clean water and public infrastructure. In the face of known attacks it is a best engineering practice and we shouldn't accept less while still demanding stronger privacy protections too. When you step back from the details and ask yourself if it is really reasonable that a human's interaction with the Web is observable to many silent and undetectable observers the current situation really seems absurd.
The immediate offered solution space is complicated and incomplete.
Potential mitigations are fraught with tradeoffs and unintended
consequences. The focus here is on what happens to http:// schemed
traffic, https is comparably well taken care of. The common solution
offered in this space carries http:// over an unauthenticated TLS
channel for HTTP/2. The result is a very simple plug and play TLS capable HTTP server that is not dependent on the PKI. This provides protection against passive eaves droppers, but not against active attacks. The cost of attacking is raised in terms of CPU, monetary cost, political implications, and risk of being discovered. In my opinion, that's a win. Encryption simply becomes the new equivalent of clear text - it doesn't promote http:// to https://, it does not produce a lock icon, and it does not grant you any new guarantees that cleartext http:// would not have. I support that approach.
The IETF HTTPbis working group will test this commitment to encryption on Wednesday at the London #IETF89 meeting when http:// schemed URIs over TLS is on the agenda (again). In the past, it not been able to garner consensus. If the group is unable to form consensus around a stronger privacy approach than was done with HTTP/1.1's use of cleartext I would hope the IESG would block the proposed RFC during last call for having insufficiently addressed the security implications of HTTP/2 on the Internet as we now know it.
#ietf89 #strint
