Re: Proposed Statement on "HTTPS everywhere for the IETF"

[Mark Nottingham <[e-mail]>]

On 10 Jun 2015, at 10:24 am, Roy T. Fielding <[e-mail]> wrote:
> […]
>>> Furthermore, with TLS in place, it becomes easy and commonplace to send stored authentication credentials in those requests, without visibility, and without the ability to easily reset those credentials (unlike in-the-clear cookies).
>> 
>> Yes. This is a concern that I talked through with Balachander Krishnamurthy (who said his cookie research would have been much more difficult with pervasive HTTPS) and others when SPDY came around. I think we need much better tooling here. There has been a bit of progress, but it's been very slow...
> 
> I don't think you appreciate the impact of authenticated requests on the overall system.
> It isn't just that the sites you intend to visit now have the ability to uniquely identify
> you at no additional infrastructure cost.  It is that every https reference on every page
> has the same ability, and is no longer hindered by limitations on Referer or "privacy"
> concerns (again, because people like the IETF claim that encrypted data sent over TLS is
> private even when we have no control over the CAs, the recipient, and the data sent).

Or perhaps you just weren't explaining what you meant very well. Thanks for doing so below.

I agree that there are aspects of TLS that could be abused into tracking users (e.g., session tickets), and that this is a concern. However, the same can be said for HTTP (ETags, anyone?), URIs, JavaScript, and many other parts of the Web. 

Maintaining truly anonymous, untracked Web access is really, really hard — to the point that if you're serious about it, each time you want to use a Web site, you'll use a different physical machine (think side channel attacks; this is a fun sampler: <http://arxiv.org/pdf/1502.07373v2.pdf>).

As such, equating TLS to "authenticated requests" confuses the matter more than it helps explain what's happening. If TLS has the potential for adding entropy to a browser fingerprint, we can and should look at ways to mitigate that. But, it's not like people who want to track users using things other than cookies are over the moon about HTTPS Everywhere; they already have a buffet of choices to do that on the modern Web. 

And yes, HTTPS does hide what happens on the wire. However, the techniques used are still apparent in the endpoints, and we have a growing galaxy of privacy-aiding browser plugins to find at least some of them, as well as more hardened approaches like TorBrowser. The ones that can't be found in the browser by a plugin probably can't be detected on the wire either.

Don't get me wrong - many people (including me) are very concerned about this problem, and we're talking about it in the TAG right now. I just don't see any reason to recommend that people NOT deploy HTTPS based upon these specific concerns — they're dwarfed by other (very real) concerns about cookieless tracking as well as pervasive monitoring.


[…]
>>> What it does is disable anonymous access to ensure authority.
>> 
>> Please explain?
> 
> The https scheme relies on the notion of authority in the URI combined with direct or
> tunneled connection to that authority to establish a trusted exchange of information
> between the user and that authority (assuming that the user trusts that authority).
> For various performance reasons, a great deal of state is held on the user agent to
> ensure that its next connection to the same authority isn't depressingly slow.
> Recipients are discouraged from shared caching or mirroring of the content, since
> the authority is vested only in the connection that delivered it, not in the bits
> that were delivered, and the user agent doesn't know why the bits were secured.
> 
> Anonymous access, in contrast, does not presume that the user trusts the authority.
> Very little state is maintained on the user agent, since it doesn't actually help.
> Recipients are encouraged to cache or mirror the content, especially if the
> content itself is signed, which means other users can access the content without
> making a request to the authority.  Information can be replicated and accessed at
> locations the user does trust, perhaps even offline.
> 
> The other advantage that replication has over https, aside from not requiring
> a connection to the authority, is that the information cannot be personalized.
> If you can go to a public library to see a copy of the tax code, or legal code,
> or some other document of public interest, it makes it much harder for that code
> to be changed without people noticing, or for certain viewers of the code to see
> a different version than others.

Thanks again.


>> I think the combination of how HTTP is defined and Web browsers' specific usage patterns of HTTP over TLS does that. We're already seeing some background discussion of how to offer caching without sacrificing security. 
> 
> We can't have a reasonable comparison of the effect of HTTPS-everywhere based on
> proposals that are deployed nowhere.  Deploy them first, advocate later.

Well, exactly. You seem to be arguing that we should stop advocating for/improving HTTPS (for all of the reasons that led us to this) while we wait for a new proposal/protocol to be developed and deployed, because it might be a better overall solution.

It indeed might be better in many aspects — and I'd love to get such a thing going. Let's do a Bar BoF in Prague. 

In the meantime, we have a deployed Web that needs maintenance and evolution. It needs to be secured from a variety of attacks — pervasive monitoring being just one — that HTTPS can help mitigate.

"HTTPS Everywhere" is not an edict from the IESG (or IAB, TAG or anyone else); it's at most an aspirational goal shared by many. Pretty much all of the actual activity has been focused on making sure that it's easy / possible to deploy, and that it is used when a new feature is powerful / privileged enough to warrant it (e.g., ServiceWorker).

Stopping that on the basis that we hope something better will come along doesn't make sense.


> If you are going to conduct a political campaign, I expect to see reasonable and
> responsible disclosures of the profit motive even if it has no personal relevance
> to the person disclosing.  Readers can reach their own conclusions.

OK. 

I don't know if I'm "conducting a political campaign" (which seems like a pejorative phrase already), but regardless: I'm employed by a CDN, Akamai. They make money by running a lot of servers on the Internet and doing interesting things with them, including serving TLS.

Your turn, Roy from Adobe and Apache.


[…]
>>> It's a shame that the IETF has been abused in this way to promote a campaign that will
>>> effectively end anonymous access, under the guise of promoting privacy.
>> 
>> How does HTTPS "end anonymous access"?
> 
> Because https-everywhere eliminates anonymous access; not just in the technical
> leaks that result from all that authenticating the authority, but also in the social
> effects it has on the overall ecosystem.  It excludes the features of HTTP
> that encouraged shared caching (by default) and removes social and technical
> barriers associated with persistently identifying each user.
> 
> If we are going to make grand recommendations that change the way the Web works,
> we should at least understand the consequences.  If we are going to tell people
> that something will improve privacy, then it had better improve privacy to the
> same degree that we say it does.

So, the start of this thread was about using HTTPS to serve IETF.org sites. We seem to be veering off-topic; I don't see a "grand recommendation" of any sort in <https://trac.tools.ietf.org/group/iesg/trac/wiki/HttpsEverywhere>. What exactly are you arguing against *here*? 

Cheers,


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