1. 18
  1.  

  2. 16

    I feel like this page quotes the author in a somewhat unfair way, by omitting the first few paragraphs. In fact, going through the details of what was changed - as I would not have done had it not been seeming to portray so unlikely a position - I think the quote is a hit piece intended to discredit him. I’m of course not blaming the Lobsters user who linked it, and please don’t take it that way; I almost didn’t notice either.

    Don’t worry, though, I’m still critical of the author. And of everyone else involved in the discussion this turns out to be from. I’ll get to that below. :)

    Click through via the header to the original email and you’ll see… well… I’ll quote the whole thing. I’ve boldfaced the parts not present in the quote:

    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.

    [upthread content elided]

    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. 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).

    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.

    TLS does not provide privacy. What it does is disable anonymous access to ensure authority. It changes access patterns away from decentralized caching to more centralized authority control. That is the opposite of privacy. 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.

    [This paragraph was moved to the end in the quote, making it appear to be a summary of the author’s core point, which it is not. It appears here in the original; it was otherwise unmodified. The reordering was noted in small print below the quote, but that hardly makes it less disingenuous.] 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.

    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. 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.

    What he’s describing is a strategy by which passive adversaries can reidentify visitors to a secure site. That attack does work, to an extent; it’s essentially a browser fingerprint. This is why Tails users are encouraged to change as few of the default settings as they possibly can. Because this reidentification is unnecessary to an attacker on the LAN, who can simply make note of your IP and MAC addresses, it’s really only talking about global passive adversaries who are trying to track the same user and device over a variety of uplinks over a long period of time. Certainly a legitimate threat.

    That doesn’t mean it’s the only threat that TLS addresses, nor the only one that it’s meant to address. To reuse an example from another comment thread a few weeks ago, I’m much happier with telling everyone on my LAN that I’m browsing WebMD, than I am with telling them the specific venereal disease I’m researching at length. (Hypothetically. I do research diseases for both fun and personal relevance, but not usually those ones. :) But it’s a major use of the site.)

    As someone whose job is to mitigate privacy risks, I take issue with the attempt to distinguish “confidentiality” from “privacy”. Reidentification is a very serious privacy concern, yes; that doesn’t make data leakage less of one! I’m not too concerned with what it’s called, though, as long as both are protected.

    Also, the author claims that TLS “disables anonymous access”, which is true in the sense that the site owner cannot be anonymous, at least not without lying to a certificate authority. It has no such effect on the end user. That’s the one thing in this particular mail that really bothers me. There could, of course, be context that makes it clear; I only read about ten messages of the thread, which has nearly a hundred.

    So much for what’s being discussed proximately. I read some of the surrounding thread, which is apparently an attempt by several dozen IETF members to filibuster (note: my opinion) a planned move to serve the IETF’s own website via https by default, with an http fallback; the present situation already has both options.

    I find this such a bizarre issue to generate so many words, that I am not even going to try to summarize the entire thread, but feel free to go read it if you’d like to have your own opinion. As people should be aware, this comes in the context of the forthcoming HTTP/2 standard having been initially proposed to have only a TLS mode, no cleartext, but meeting numerous objections by IETF members. Personally, though I am very thankful not to have been involved, I consider those objections insincere and full of misleading assumptions and framing, which is also my impression of this thread that we’re seeing a couple months later.

    What I actually saw nobody say in the entire thread was anything in support of privacy as I think of it. Everything was either taking an anti-encryption privacy-blind stance, or taking a pro-encryption stance at a very abstract level and with no specific reason given. I understand that being involved in a standards committee as a career choice requires one to moderate one’s words, but… That’s deeply disturbing.

    I think it’s generating so much noise precisely because changing the default is meant as a symbolic endorsement of encryption, and there are strong interests who do not approve of encryption. I would not expect to see much sincerity in this, since the strategy is very clearly to just generate confusion and bad will until everyone gives up and agrees to preserve the status quo.

    I have no advice on what anyone could do about this. :)

    Edit: I had used code-block syntax instead of blockquote syntax; fixed.

    1. 3

      Blockquote is >; indentation is fixed-width. I would be very surprised if @ap were trying to discredit Roy with this quote.

      I think Roy is exactly taking the more nuanced position you’re saying is missing from the debate: his position is neither pro-encryption (in this particular case) nor anti-encryption nor privacy-blind. And the attacks he’s saying TLS enables are somewhat subtler and more varied than the one you mention.

      1. 1

        It’s possible. It’s certainly hard to tell. I was originally just going to write something to the effect of “it’s really bad when people take things out of context”, and I was aware of the irony of then realizing that the full context was much, much longer than I could reasonably understand.

        If you’re aware of other attacks he’s describing, I’d like to hear about them. That was all I could get out of it, but I can certainly miss things.

        On a reread, I’d been so caught up with trying to understand the surrounding piece that I missed his point about opaque authentication methods… but even in the presence of asynchronous JS that invents its own mechanism, it can only do that because of browser-side storage mechanisms. An incognito window will still do what it’s supposed to, and so will the network pane of the debug console. There are definitely mechanisms to create supercookies, but the use of TLS does not change those, and browsers are catching up. I don’t understand how the use of TLS in this scenario allegedly destroys privacy.

        Thanks, re: formatting; I’ll fix it.

        1. 5

          I think what he was pointing to is that HTTPS makes it safe to use capability URLs which verify the user’s authorization to access the linked page, like those used by EtherPad Lite; the user can’t tell if those URLs also deanonymize them. (On the other hand, cap URLs can also be used to securely and anonymously delegate access to particular resources, and EtherPad Lite uses them in that way.) But maybe he had some other things in mind.

          1. 2

            Interesting threat. It would be possible to tell whether a site could be doing this, but never whether it was. I appreciate your describing it.

            It’s in the category of things that I still think of as moving forward. Yes, risks evolve; that doesn’t mean we stand still. Especially not with known risks in the status quo that are, to some of us, unacceptable.

            1. 5

              Yeah, agreed. I do think Roy is right (as usual!) about access to public data: if you can get it from a distributed data store and authenticate its integrity without having to have a conversation with an origin server — who, in many cases, you have to trust not to corrupt the data uploaded to it by the person you actually wanted to communicate with — that can be a lot better at privacy protection, at preventing malicious system updates, at scalability, at preventing monetization, and at protecting the integrity of messages. But HTTP URLs are not adequate for this.

              1. 2

                Yes, I actually very much agree that there should be such a system. I just don’t think it should be instead of the web as we know it. At least not right away; it needs to prove itself first!