Re: Adding Security Considerations regarding interception to p1

Hello Mark, others,

The text below is a big improvement over the previous version, and I can 
support it.

Regards,   Martin.

On 2013/09/19 11:01, Mark Nottingham wrote:
> Hi Werner,
>
> On 19/09/2013, at 4:24 AM, Werner Baumann<werner.baumann@onlinehome.de>  wrote:
>
>> I don't like the proposed text at all. It proposes TLS as sole and
>> efficient means to protect privacy. That's wrong for different reason:
>>
>> - TLS does not help against collecting and analyzing connection
>>   data, which is an important and dangerous part of the actions of
>>   governmental surveillance organizations.
>
> That's true, but I don't see how it follows that we shouldn't document TLS as a mitigation for passive interception attacks.
>
>> - TLS does not help against data collection conducted by providers of
>>   internet services, which is an equal important threat to end user's
>>   privacy.
>
> The scope of these documents is the protocol itself, not what is done with data once it's on someone's server.
>
>> - The text only considers passive interception and man in the middle
>>   attacks and claims that TLS can mitigate the danger. It does not deal
>>   with MITM attacks on TLS-traffic which is known to happen. It ignores
>>   that TLS (at the moment) completely depends on the trustworthiness of
>>   CAs. But there is nobody who could tell for sure that these CAs are
>>   trustworthy. Quite the contrary. We have learned recently that even
>>   big companies seem to be quite defenseless when governments request
>>   their users data.
>
> I'm happy to add text to address this, but it seemed to me that such attacks are on TLS itself, and therefore more in-scope for it.
>
>> - It only comes up with proposals what servers should do. But it would
>>   be even more important to talk about what end users can do and what
>>   vendors of HTTP-clients should do to help end users in this (and
>>   what most browser vendors don't).
>
> Again, happy to add text. We're going to have a much more involved discussion of this for HTTP/2, however, and I suspect we'll be able to do more there. Since HTTP/1 is already widely deployed, it seemed more appropriate (as discussed in Berlin) to simply document the risk.
>
>> Discussion of security threats and measures against them is important.
>> But it should be done seriously. Ritually promoting the
>> one-size-fits-none security of TLS does not help.
>
>
> The intent wasn't to say that TLS is the answer for all security problems, and if we need to adjust the text to take the focus away from that, it's fine. It does, however, improve things -- I hope you're not disputing that?
>
> In my experience, many security discussions end up being about perfect and complete security. That's a very high (indeed, impossible to meet) bar, and I think it's much more reasonable to simply attempt to make things better -- a much more realistic goal.
>
> To that point, the motivation for this text was that it seemed like a quite large omission for the revised definition of HTTP/1.1 to completely fail to document these issues.
>
> With that in mind, a few tweaks below:
>
> ---8<---
>
> Interception
>
> Common use of HTTP often contains a considerable amount of sensitive data; this might include cookies [RFC6265], application data, and even patterns of access.
>
> When 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 help to mitigate such passive interception attacks. Note that TLS itself has many modes of use with different security properties, and there are currently known attacks against server authentication in "https://" URIs.
>
> 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.  Using TLS [RFC2818] may or may not mitigate this form of attack, depending on the client and individual behaviors.
>
> --->8---
>
>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>

Received on Thursday, 19 September 2013 04:08:04 UTC