- From: J Ross Nicoll <jrn@jrn.me.uk>
- Date: Sat, 13 Jul 2013 23:41:51 +0100
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>, HTTP Working Group <ietf-http-wg@w3.org>
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. >
Received on Saturday, 13 July 2013 22:42:16 UTC