Adding Security Considerations regarding interception to p1

In Berlin, we discussed the implications of HTTP's use of encryption upon privacy, in light of recent developments. See:
  <http://www.ietf.org/proceedings/87/slides/slides-87-httpbis-3.pdf>

One of the proposals that got strong support in the room (i.e., very loud hum in favour, only a few humming in dissent) was adding text to Security Considerations in HTTP/1.1 to indicate the privacy implications of running without encryption.

We are very nearly ready for IETF Last Call -- possibly days away.  So, my inclination is to see if we can achieve consensus to add some text in a reasonable amount of time. 

Based on the discussion in Berlin, I've come up with proposed text for a new subsection of Security Considerations in p1. Please have a look below and indicate if you think it's a good idea to add this, disagree with adding it, or have an alternative that you think can gain consensus more easily. 

Be warned -- I don't want to rathole on this, and the easiest thing to do is not to add anything. 

---8<---

Interception and Privacy

Common use of HTTP often contains a considerable amount of Personally Identifying Information; this might include cookies [RFC6265], application data, and even patterns of access.

If used without encryption, HTTP makes this data vulnerable to passive interception. There are known instances when third parties have exploited the in-the-clear nature of "http://" URIs to obtain sensitive information, for a variety of purposes. Use of TLS [RFC2818] can mitigate such passive interception attacks.

Moreover, like other clear text protocols, HTTP/1.1 is subject to an active man-in-the-middle attack.  That is, it is possible for an intermediary
device to terminate a client TCP connection and respond as if it had the IP address of the intended HTTP server.  An attacker may insert or delete content or redirect the client to a completely different web site.  Encryption [RFC2818] may or may not mitigate this form of attack, depending on the client and individual behaviors. 

HTTP/1.1 does not make any particular security mechanism -- including encryption -- Mandatory to Implement, as its deployment pre-dated [RFC3631]. Nevertheless, servers ought to carefully consider the privacy implications of using HTTP without encryption (i.e., using TLS [RFC2818]), preferring its use where there is any potential for access to be considered sensitive. 

--->8---

Regards,

--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 18 September 2013 01:30:56 UTC