Re: Adding Security Considerations regarding interception to p1

This is confused.  TLS does not provide privacy.  HTTP rarely
contains PII (as that term is commonly defined) unless the user has
authenticated, in which case it really should be under TLS for
confidentiality (not privacy).  To get privacy, the user needs to
obscure the routing and filter the protocol stream, which can be done
by using other-protocol routing through anonymizing proxies.

Cookies are usually not PII unless they are being used to store
email or account names.  What they are, more often, is an easy
handle for data correlation over time, and eventually that correlation
might lead to a record that does contain PII, at which point the
entire data set involving that correlation becomes PII.  In any case,
this spec does not define cookies.

I really don't think we want to have that discussion in HTTP.
It is bad enough to deal with it in DNT and actual regulations.
If we want to write something useful, like the additions I made
for logfile processing, tracking, and fingerprinting, that's fine;
no more FUD.  We can reference the privacy RFC for the larger
discussion.

If we want to add a discussion about preserving confidentiality
and data integrity via TLS, that's also fine, though I personally
think it belongs in a TLS spec (not here).

....Roy


On Sep 17, 2013, at 6:30 PM, Mark Nottingham wrote:

> 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 07:12:32 UTC