A place to cache linked articles (think custom and personal wayback machine)
您最多选择25个主题 主题必须以字母或数字开头,可以包含连字符 (-),并且长度不得超过35个字符

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354
  1. title: Re: Proposed Statement on "HTTPS everywhere for the IETF"
  2. url: http://www.ietf.org/mail-archive/web/ietf/current/msg93416.html
  3. hash_url: 05736d9775fba3be938ebd24c978ac6c
  4. > On Jun 4, 2015, at 9:53 AM, Joe Hildebrand wrote:
  5. >
  6. >> On 4 Jun 2015, at 9:37, Tony Hain wrote:
  7. >>
  8. >> 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.
  9. >
  10. > 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.
  11. That is message confidentiality, not privacy. Almost all of the privacy bits (as in, which
  12. person is doing what and where) are revealed outside of the message.
  13. > 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.
  14. Browsers don't send singular messages containing anonymous information. They send a complex
  15. sequence of messages to multiple parties with an interaction pattern and communication state.
  16. The more complex and encrypted the communication, the more uncommon state and direct
  17. communication is required, which makes it easier to track a person across multiple requests
  18. until the user's identity is revealed. Furthermore, with TLS in place, it becomes easy and
  19. commonplace to send stored authentication credentials in those requests, without visibility,
  20. and without the ability to easily reset those credentials (unlike in-the-clear cookies).
  21. Padding has very little effect. It isn't just the message sizes that change -- it is all
  22. of the behavior that changes, and all of the references to that behavior in subsequent
  23. requests, and the effects of those changes on both the server and the client.
  24. TLS does not provide privacy. What it does is disable anonymous access to ensure authority.
  25. It changes access patterns away from decentralized caching to more centralized authority control.
  26. That is the opposite of privacy. TLS is desirable for access to account-based services wherein
  27. anonymity is not a concern (and usually not even allowed). TLS is NOT desirable for access to
  28. public information, except in that it provides an ephemeral form of message integrity that is
  29. a weak replacement for content integrity.
  30. If the IETF wants to improve privacy, it should work on protocols that provide anonymous
  31. access to signed artifacts (authentication of the content, not the connection) that is
  32. independent of the user's access mechanism.
  33. I have no objection to the IESG proposal to provide information *also* via https. It would
  34. be better to provide content signatures and encourage mirroring, just to be a good example,
  35. but I don't expect eggs to show up before chickens. However, I agree with Tony's assessment:
  36. most of the text is nothing more than a pompous political statement, much like the sham of
  37. "consensus" that was contrived at the Vancouver IETF.
  38. TLS everywhere is great for large companies with a financial stake in Internet centralization.
  39. It is even better for those providing identity services and TLS-outsourcing via CDNs.
  40. It's a shame that the IETF has been abused in this way to promote a campaign that will
  41. effectively end anonymous access, under the guise of promoting privacy.
  42. ....Roy
  43. </pre>