Re: Adding Security Considerations regarding interception to p1

I support this.  However, as written, some of the text is poorly worded:

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

Here, "its use" may be misunderstood to mean "the use of HTTP without 
encryption", which is almost certainly not the intent.  Maybe this will work 
better:

"Nevertheless, servers ought to carefully consider the privacy implications 
of using HTTP without encryption, preferring the use of encryption (such as 
TLS [RFC2818]) where there is any potential for access to be considered 
sensitive."

--Peter

-----Original Message----- 
From: Mark Nottingham
Sent: Tuesday, September 17, 2013 9:30 PM
To: IETF HTTP WG
Subject: 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 02:31:53 UTC