- From: Mark Watson <watsonm@netflix.com>
- Date: Wed, 12 Nov 2014 13:03:56 -0800
- To: Brad Hill <hillbrad@fb.com>
- Cc: Adam Langley <agl@google.com>, Mike West <mkwst@google.com>, Frederik Braun <fbraun@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Nov 12, 2014, at 12:27 PM, Brad Hill <hillbrad@fb.com> wrote: >> >> ​I think that is about enabling the server to authenticate the request. >> What I think we need is for the UA to verify that the request processed >> by the server was the same as the one it sent, so that the ​ >> ​UA can be sure the traffic is not subject to attacks such as the Verizon >> "perma-cookie".​ > > It's too late at that point, isn't it? You've been identified to the > server (and anyone in the middle). > > I believe the concerns blocking consensus are regarding the privacy, not > the integrity, of requests, so not sure this is a productive track to head > down. It's true that the server learns that this user made a request. But the response is going to be ignored and subsequent requests sent over HTTPS. The UA might remember the scenarios when this happened and default future requests to HTTPS too. The egregious thing about the Verizon attack is that it permits tracking over time, even if the user clears cookies and changes IP address. That possibility is undermined if the identifier is only sent once. Remember that there is little we can really do at the client about such network attacks on outgoing messages except make them more difficult / less useful: the network could independently send messages to the destination identifying the user associated with each TLS connection. I appreciate that this track is not a panacea, but neither is TLS. And this approach could get a lot of sites into secure origins a lot sooner, which is why I wonder if it is worth exploring despite the rough edges ? ...Mark > > -Brad >
Received on Wednesday, 12 November 2014 21:04:28 UTC