Re: Adding Security Considerations regarding interception to p1

I saw an initial bunch of +1's to this suggestion and would
support those. This seems to me like a useful addition.

On 09/18/2013 08:12 AM, Roy T. Fielding wrote:
> This is confused.  

I don't agree. The wording can be improved I'm sure but I don't
find the suggested text at all confused or confusing.

> TLS does not provide privacy.  

Correct. But no protocol "provides" privacy. The fact that TLS
can provide confidentiality does however, make it possible
to HTTP to be more privacy friendly when compared to HTTP
without TLS.

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

I don't understand the above. I don't think Mark's suggested
text claimed to give privacy, but rather to encourage folks to
use TLS as a part of being more privacy friendly. That seems to
me to be a good plan.

> 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 don't understand the relevance of the above.

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

Nor that. (Really, not just being argumentative.)

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

I think encouraging more use of TLS as a part of being more
privacy friendly is worthwhile. Having said that, it may well be
a good idea to add a bit more text so that readers don't get
confused into thinking that confidentiality == privacy, so
maybe something like:

"Properly used, TLS provides good confidentiality which can be
an important part of being more privacy-friendly. However, even
the best network confidentiality service is essentially irrelevant
if the endpoints (browser, web server) are working against the
privacy expectations of users, for example by forwarding any PII
to an unwanted third party."

But even without that tweak, the suggested text is worth
adding IMO.

Cheers,
S.

> 
> ....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 Thursday, 19 September 2013 01:55:43 UTC