W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Adding Security Considerations regarding interception to p1

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 18 Sep 2013 11:30:27 +1000
Message-Id: <5155C19F-C67D-450E-90F8-2F09C4B481DF@mnot.net>
To: IETF HTTP WG <ietf-http-wg@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:15 UTC