Re: Adding Security Considerations regarding interception to p1

+1


On Tue, Sep 17, 2013 at 6:52 PM, Patrick McManus <pmcmanus@mozilla.com>wrote:

> Mark - that's great and I think it is good advice to add to http/1 bis
> based on operational experience.
>
>
> 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/
>>
>>
>>
>>
>>
>