On 25/04/2018 00:49, Dave O'Reilly wrote:
> Amelia,
> 
> I have read this draft now and, once again, it seems there has been no 
> consideration of the implications for law enforcement of these 
> recommendations. A further example of the "privacy is good, more privacy is 
> better" philosophy. 
> 
> I also reviewed RFC6973 and the exact same problem is present there. The 
> privacy threats highlighted in RFC6973 are reasonable from a privacy 
> advocate’s perspective and worthy of consideration, and the mitigants listed 
> also make sense in the context of the listed threats. However, to intimate 
> that the representations of RFC6973 are the only possible perspective, or in 
> some objective sense the “right” perspective, or indeed in any way a complete 
> perspective, misses out important societal issues such as those that are 
> being discussed in this thread.
> 
> The considerations that appear to be foremost in RFC6973 are the issues 
> relating to the collection and use of personal data for commercial purposes 
> and the impact of data breaches

These days we would add "political purposes", and that is interesting because
it has both societal and possible criminal implications. But those issues are
much wider than IP addresses and ports. 

> - the crime attribution characteristics are hardly considered at all. Only 
> surveillance is mentioned and this category, crime attribution per se is not 
> considered at all.

For a reason. A tool that can be used by the authorities for tracing crime to 
its
source can be used by authorities for tracing political activity to its source,
which in many countries is considered to be abuse of power. And if the tool 
itself
is vulnerable, it can be mis-used by non-government actors for bad purposes.
This is the argument behind RFC 2804 of course, and I don't see this discussion
as anything different in principle.

RFC 6302 is a bit different. Server logs are sometimes essential for problem
debugging, rather than for penetrating privacy.

   Brian

> It is also sort of implied that surveillance is always a bad thing (it is, 
> after all, listed in the privacy threats section with no consideration of if, 
> or why, there might be a legitimate use for surveillance, subject to 
> appropriate legal safeguards of course) - another point that should be 
> debated and not automatically accepted.
> 
> The only trade-offs that are suggested for consideration are (ref. section 
> 4.a)  "privacy and usability, privacy and efficiency, privacy and 
> implementability, or privacy and other design goals”. What about, for 
> example, privacy and potential for misuse, privacy and potential for 
> concealing criminal activity, etc. etc.?
> 
> Coming back to the Internet Draft for a moment, there are other points that I 
> could raise but I only want to draw out one rather glaring misrepresentation 
> for now:
> 
> "Earlier recommendations contained in [RFC6302] relied heavily on 
> observations made in Section 12 of [RFC6269] that regulatory requirements 
> could imply a broad obligation to log identifiers.”
> 
> RFC6302 has nothing to do with regulatory requirements to log anything. 
> RFC6302 relates to recommendations that Internet-facing servers log source 
> port information alongside IP address. The overwhelming majority of 
> Internet-facing servers are subject to no form of regulation at all. The fact 
> that RFC6269 highlights a regulatory requirement to maintain subscriber 
> identity, and the subsequent striking down of the data retention directive, 
> is immaterial to the substance of RFC6302 and RFC6302 does not rely on it in 
> any way. Attempting to throw out the existing recommendations in RFC6302 
> because of the ECJ ruling on data retention directive is disingenuous. 
> 
> daveor
> 
>> On 23 Apr 2018, at 09:10, Amelia Andersdotter <[email protected]> wrote:
>>
>> I've tabled a similar draft but with a different scope. Happy to discuss
>> with members on the list:
>>
>> https://datatracker.ietf.org/doc/draft-andersdotter-intarea-update-to-rfc6302/
>>
>> -- 
>>
>> Amelia Andersdotter
>> Technical Consultant, Digital Programme
>>
>> ARTICLE19
>> www.article19.org
>>
>> PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55
>>
> 
> _______________________________________________
> Int-area mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/int-area
> 

_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to