On Jun 9, 2015, at 7:58 PM, Mark Nottingham <mnot(_at_)mnot(_dot_)net> wrote:
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.
No, I am advocating that https is not the solution you say it is, and further
that
moving everything to https is actively harmful to the cases you haven't
considered.
This doesn't stop anyone from improving https, or choosing a better solution
for the
problem, or just moderating the message to be more truthful.
If it weren't for the absolutist position of the campaign, cloaked in the
petals of
privacy, I would not feel a need to say anything at all.
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.
I won't be in Prague. I doubt that I will attend another IETF in person, given
how
distasteful the experience was in Vancouver and Honolulu.
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.
No, but adjusting the campaign to be truthful in its statements and abundantly
clear on
the exceptions does make sense. I don't like seeing governmental agencies
refer to
contrived agendas as if they were technical recommendations by the IETF.
https://https.cio.gov/everything/
I also don't like the way that rational exceptions have been dismissed
https://github.com/GSA/https/issues/107
I particularly don't like the assumption that all HTTP use is by browsers.
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.
Sorry, I didn't mean here. I meant in the campaign itself.
Your turn, Roy from Adobe and Apache.
I am not the one campaigning, but since you ask ... I have no idea what Adobe's
position
would be, and am not aware of any impact one way or another given we already
use https.
For Apache, it is fair to say that the ASF's software distribution network that
mirrors
our software, for free, world-wide
http://www.apache.org/dyn/closer.cgi
would be severely impacted by an https-everywhere policy, for no benefit
whatsoever
given that the artifacts are cryptographically signed using gpg and have been
for
the past 20 years. In fact, the ASF would not have been able to afford its
own bandwidth costs, at least for the first ten years when we didn't have
sponsors,
if it were not for that mirror network.
[…]
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*?
This part of the thread, which is about the proposed statement overreaching
the actual proposed policy.
....Roy