Re: Adding Security Considerations regarding interception to p1

+1 for this, sounds like good advice to be putting out there.


On Tue, Sep 17, 2013 at 6:30 PM, Mark Nottingham <mnot@mnot.net> 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/
>
>
>
>
>