Re: PRISM and HTTP/2.0

Absolutely. However, I do think that the user should be in a place where they have enough information to make an informed decision about the security of their communication should they want to.

That means that we need to raise the game regarding TLS MITM (which several groups have been working on for some time) as well as making TLS easier to deploy well (which is also being worked upon AIUI). That's all out-of-scope here, unless we want to mandate use of some particular approach with HTTP/2.

TLS itself is out of our hands; if we want to recommend increased key lengths, etc., we should ask the TLS WG to produce a profile of the protocol that we can point to.

The UI stuff is hard. Yes, 99.x% of users will click through, but that doesn't mean that we shouldn't tell them. It'd be a good start if we could reduce the number of false positives in those dialogues (e.g. self-signed certs; they're easy to deploy and train users to ignore security dialogues; a bad mix). However, we don't do UI here (he says gratefully); the best venues for that are probably the WHAT WG and the W3C Web Application Security WG. 

What *is* in scope here -- barring doing something big like encrypting HTTP/2 per frame -- is sorting out the mess of intermediary configuration. As I said when we started, if people expect HTTP/2 to be used over TLS more (or HTTP/1, for that matter), we'd better have a more reasonable, interoperable way for networks to tell clients to use a proxy.

I have no problem using HTTP/2 as a way to drive these discussions and consolidate the efforts by requiring particular things to be done when you use the protocol. However, we can't fix the whole world here; we need to stay focused.

Cheers,


On 14/07/2013, at 10:16 AM, Roberto Peon <grmocg@gmail.com> wrote:

> I have a difficult time believing that any solution, short of new physics-based technologies, will overcome the tradition of users' ambivalence when faced with any obstacle to convenience.
> -=R
> 
> 
> On Sat, Jul 13, 2013 at 3:41 PM, J Ross Nicoll <jrn@jrn.me.uk> wrote:
> With regards to #1, I'm not sure the concept of "more encryption" is really what's meant here. Minimum key lengths could be increased, perhaps different encryption methods merged such that if one approach is broken then the message is still secure... however I think we can fairly realistically assume no-one's going to try tackling the encryption itself head-on.
> 
> Bogus certificates and server-side backdoors seem inevitable, at least in the current political climate. I don't think any realistic changes at the transport layer will affect that (unrealistic changes would include "move to a web of trust"). Equally I don't think there's any need for changes to enable access; they're doing that just fine without us, and inevitably any such hooks are weaknesses that can potentially be exploited by an attacker.
> 
> About the only changes I could suggest from a technical point of view would be user-interface related. Indicate when a server certificate changes, for example, especially if the previous certificate's expiry wasn't due for a while. The same sort of defences that are relevant against phishing attacks, are useful for evading other forms of site impersonation.
> 
> I think this is a discussion worth having, because even "There is nothing to be changed" is a concrete conclusion to come to, but that may be the answer here.
> 
> Ross
> 
> 
> On 13/07/2013 11:08, Poul-Henning Kamp wrote:
> I would like to advocate that everybody spends a little bit of time
> reconsidering how we design protocols after the PRISM disclosures.
> 
> We don't need to have a long discussion about the actual legality
> of the US spy operation, the sheer scale and the kind of efforts
> that went in to it is the relevant message to us.
> 
> The take-home message is that encryption will be broken, disabled,
> circumvented og watered down, if it gets in the way of political
> objectives.
> 
> We can do three things in light of this:
> 
> 1) We can try to add more encryption to fight back.
> 
> 2) We can recognize that there needs to be hooks for duly authorized access.
> 
> 3) We can change or at least influence the political objectives
> 
> I think PRISM is ample evidence that #1 will have the 100% certain
> result is that all encryption will be circumvented, with bogus CA
> certs all the way up to PRISM and designed-in backdoors, and the
> net result is less or even no privacy for anybody everywhere.
> 
> In my view, that would be very counterproductive.
> 
> #2 is not without challenges, but at least there are plausible paths
> from there to a state of affairs where innocent people might still
> have access to private communications, and it might seem to be a
> necessary precondition for any hope on #3
> 
> #3 is clearly not inside HTTPbis scope, but it may be time for
> all good nerds to come to the aid of their country and humanity.
> 
> A "market based" argument can be made under #3, that if we design
> protocols with the necessary access (#2), programs like PRISM will
> not be cost effective, but that will take some serious effort
> of education and politics.
> 
> Anyway:  Edward Snowden has moved the rug under the HTTP/2.0
> standardization process, and we should not ignore that.
> 
> Think about it.
> 
> 
> 
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Sunday, 14 July 2013 22:15:02 UTC