Hi Roy,
My overall concern here is that statements like this undermine the
integrity of the organization. I understand people wanting to improve
overall privacy, but this step does not do that in any meaningful way.
Encrypting the channel does provide some small amount of privacy for the
*request*, which is not public information. Browser capabilities, cookies,
etc. benefit from not being easily-correlated with other information.
That is message confidentiality, not privacy. Almost all of the privacy bits
(as in, which person is doing what and where) are revealed outside of the
message.
There's been a lot of historic confusion (or maybe it's just different jargon
for different communities) about confidentiality and privacy in protocols; I'm
assuming Joe meant, roughly "…provide a small amount of privacy by making the
request confidential…"
It would be interesting to define an HTTP header of "Padding" into which the
client would put some random noise to pad the request to a well-known size,
in order to make traffic analysis of the request slightly more difficult.
This is the sort of thing that comes up when we talk about doing more
encryption for the IETF's data, which shows the IESG's suggested approach to
be completely rational.
HTTP/2 has padding built into the relevant frames. In HTTP/1.x, padding is
sometimes done with (unregistered) headers, but more often is done with
chunk-extensions. Don't think anything needs to be registered here.
Browsers don't send singular messages containing anonymous information. They
send a complex
sequence of messages to multiple parties with an interaction pattern and
communication state.
The more complex and encrypted the communication, the more uncommon state and
direct
communication is required, which makes it easier to track a person across
multiple requests
until the user's identity is revealed.
+1. I'm very interested to see the research that showed this so clearly for
HTTP/1.x over TLS repeated for HTTP/2, since it has multiplexing and usually
uses a single connection per origin. I suspect that it's better, but certainly
not proof against these kids of attacks.
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...
Padding has very little effect. It isn't just the message sizes that change
-- it is all of the behavior that changes, and all of the references to that
behavior in subsequent requests, and the effects of those changes on both the
server and the client.
Padding may not be sufficient to be proof against information leakage, but it
is sometimes necessary. It may have little effect in the scenarios you're
thinking of, but it's still useful against some attacks.
TLS does not provide privacy.
No protocol "provides" privacy in the sense you're talking about. TLS helps to
maintain privacy in certain scenarios.
Given the news over the last two years (to almost the day!) and the nature of
the attacks we're talking about (where your access to public information can be
strung together to learn many things about you) it's not surprising that it's
being discussed. Using more TLS to achieve confidentiality *will* result in
more privacy from a pervasive network attacker — it just won't help against an
attacker (even with the best of intentions or the dodgiest of business models)
at the other end of that connection (which I absolutely agree that the IETF and
W3C should be thinking about as well).
What it does is disable anonymous access to ensure authority.
Please explain?
It changes access patterns away from decentralized caching to more
centralized authority control.
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.
That is the opposite of privacy.
No, it's the opposite of anonymity. The most relevant definition of privacy
I've seen was brought up on the Human Rights mailing list a little while back:
<http://www.internetsociety.org/blog/2013/12/language-privacy>
… and it's much more nuanced than that.
That said, I agree that both forced de-anonymisation and centralisation *can*
both be privacy-hostile. I don't think it follows that more TLS / HTTPS equals
less privacy, however.
TLS is desirable for access to account-based services wherein anonymity is
not a concern (and usually not even allowed). TLS is NOT desirable for
access to public information, except in that it provides an ephemeral form of
message integrity that is a weak replacement for content integrity.
I think reasonable people can disagree here. When faced with a pervasive
attacker (whether it be a government or a network provider) who can use your
access to public information against your will, it *is* desirable.
As an aside, the World Economic Forum has classified personal data — presumably
including browsing habits — as a "new asset class." One could argue that by
browsing without encryption, you're literally giving money to anyone on the
path who wishes to extract it.
If the IETF wants to improve privacy, it should work on protocols that
provide anonymous
access to signed artifacts (authentication of the content, not the
connection) that is
independent of the user's access mechanism.
Could you expand upon this a bit? I can think of many potential projects along
these lines (and even have one or two brewing), but I'm not quite sure what
you're getting at.
I have no objection to the IESG proposal to provide information *also* via
https. It would be better to provide content signatures and encourage
mirroring, just to be a good example,
but I don't expect eggs to show up before chickens. However, I agree with
Tony's assessment: most of the text is nothing more than a pompous political
statement, much like the sham of "consensus" that was contrived at the
Vancouver IETF. TLS everywhere is great for large companies with a financial
stake in Internet centralization. It is even better for those providing
identity services and TLS-outsourcing via CDNs.
*sigh* I'm always disappointed when people smear others' motivations without
facts to back it up.
E.g., from what I've seen of CDNs (take my personal view as you will), it's not
the nirvana you paint; scaling TLS is still difficult (thanks to lingering lack
of support for SNI), and there's a growing expectation in the market that HTTPS
will cost the same as or only a small increment over serving HTTP (despite the
consumption of IP addresses that it requires to serve a broad set of clients
well from a highly distributed set of servers).
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"?
Cheers,
--
Mark Nottingham https://www.mnot.net/