ietf
[Top] [All Lists]

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

2015-06-09 21:59:07
On 10 Jun 2015, at 10:24 am, Roy T. Fielding <fielding(_at_)gbiv(_dot_)com> 
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/