- From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Date: Tue, 19 Nov 2013 11:29:46 +0000
- To: "Roy T. Fielding" <fielding@gbiv.com>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
Hiya, A bit of disagreement and agreement... On 11/19/2013 08:43 AM, Roy T. Fielding wrote: > However, there are far more cases where encapsulating the entire > message exchange in encryption will do nothing of value. The > only "private" information being exposed in HTTP is the same > information that is exposed by requesting DNS, making the connection, > and reacting to the results. Opportunistic encryption in those > cases is both unwanted by the server and useless for the user. So I disagree there. Encrypting more or all HTTP traffic would add value IMO. Given that only 30% of sites appear to have server-certs that chain up to a browser-trusted root, there is a lot of plaintext being sent that contains sensitive information. For example, I'd bet that the pattern of cleartext http:// URI accesses for images or whatever that an https:// page load causes would I'm sure be nicely identifying of a user or of transaction details in many cases and if so, that's a pure HTTP protocol effect that no DNS changes could fix. And site-authors are not perfect, so if we can do better by sending more HTTP via TLS, then there are real benefits right now, in that sensitive data that should have used https:// URIs but doesn't will get some better protection. Saying that's useless for the user is just overstatement. Yes, there's a cost for the server, but that cost is today far far more tractable than it was 20 years ago. That does require the wg to figure out how exactly to do more TLS, and there are some tricky bits to that, as the recent torrent of mail shows, but I'm still very hopeful that the wg will figure it out. And yes, there are other things like DNS to consider (and some people are looking at the DNS confidentiality issue [1]) but that doesn't mean that one shouldn't also look at how to encrypt more HTTP traffic. [1] http://www.ietf.org/mail-archive/web/perpass/current/msg00378.html > Furthermore, I have a hard time believing the privacy propaganda > being spread by the browser makers. If they want to improve > privacy, all they have to do is remove the crappy features > that cause their HTTP use to be insecure. Stop blaming the > protocols for exposing information that shouldn't be sent in > the first place. I'm somewhat in agreement with you there. I think it'd be better if the browser folks talked about adding encryption or confidentiality and didn't talk about that as being the same as privacy since it is not. Actually, I think they have gotten better in that respect, at least in the IETF context. And I'm sure there's an awful lot more that could be done both by browsers and web sites to be more privacy friendly. But overall, getting more confidentiality is a pre-requisite for eventually getting more privacy, but confidentiality (whether via authenticated keying or not) is definitely not sufficient to make a claim that the web will overall be much more privacy friendly. If the web is being used to collect every possible morsel of data about users then it is not at all privacy friendly, and that is the status quo as far as I can see. But even so, adding more confidentiality is a necessary step in the right direction for those who would like to eventually get to a more privacy friendly web. And that necessary step also has real security benefits now, aside from enabling a possible future that is more privacy friendly. Cheers, S.
Received on Tuesday, 19 November 2013 11:30:12 UTC