Re: [Int-area] draft-andersdotter (was RE: WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

[Amelia Andersdotter <[e-mail]>]

Dear Mohamed,
all,

On 2018-04-23 10:38, [e-mail] wrote:
> Dear Amelia, 
>
> Some comments about the main recommendations in draft-andersdotter: 
>
>       SHOULD only store entire incoming IP addresses for as long as is
>       necessary to provide the specific service requested by the user.
>
> Med: This is implementation and deployment-specific. Not sure we can mandate a server how to service users.  

It's a recommendation. Cf. RFC2119 on the word SHOULD. That said, the
draft is meant to encourage good (best!) practises that can assist with
both privacy focus and regulatory compliance. The IETF cannot stop
anyone from following a poor practise, and certainly I can't.

>       SHOULD keep only the first two octets (of an IPv4 address) or the
>       first three octets (of an IPv6 address) with remaining octets set
>       to zero, when logging.
>
> Med: A server can decide to follow this reco, but it will be difficult for the owner of the server to claim an abuse and help identifying responsibilities.  

The recommendation is partially inspired by web analytics
recommendations for Piwik/Matomo installations by French DPA CNIL, but
of course also enjoys support from the data minimization strategies
advanced in RFC6973.

> Please note that RFC6302 ** does not recommend to log IP addresses** :.
>
>    "It is RECOMMENDED as best current practice that Internet-facing
>    servers logging incoming IP addresses from inbound IP traffic also
>    log "
>
> which means ** IF ** a server logs source IP address, then it has to log also the source port. 

Indeed, my proposal is to recommend that servers do not log IP addresses
other than to the extent recommended. If they don't log IP addresses at
all, they would be following the recommendations.

>       SHOULD NOT store logs of incoming IP addresses from inbound
>       traffic for longer than three days.
>
> Med: It is out of the scope of the IETF to define the duration of logs. This is country-specific. 

I'm proposing a recommendation for a best practise. Presumably if for
legal reasons one finds oneself unable to follow best practise, one
follows a worse practise instead. The fact that some people may have to
follow a worse practise is not a reason to recommend a poor practise.

>       SHOULD NOT log unnecessary identifiers, such as source port
>       number, time stamps, transport protocol numbers or destination
>       port numbers.
>
> Med: Not sure to understand this one. "unnecessary identifiers" is not clear. I prefer the current language in 6302 which identifies the minimum set of information. 

The recommendation follows immediately from data minimization in
RFC6973, which is consistently adhered to in IETF drafts with a privacy
focus.

>       SHOULD ensure adequate log access control, with suitable
>       mechanisms for keeping track of which entity accesses logged
>       identifiers, for what reason and at what time.
>
> Med: I hear you, but this is out of scope of the IETF. Access rights to retention data is well known and is not altered by the IETF specification. 

I don't understand the objection. The IETF discusses access control and
authentication in various circumstances.

If anything, the recommendation could be accused of being too inexact to
qualify as a good recommendation. The scope of it is fine and well
within IETFs mandate.

best regards,

Amelia

> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Int-area [mailto:[e-mail]] De la part de Amelia
>> Andersdotter
>> Envoyé : lundi 23 avril 2018 10:11
>> À : [e-mail]
>> Cc : Stephen Farrell
>> Objet : Re: [Int-area] WG adoption call: Availability of Information in
>> Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
>>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/int-area


-- 
Amelia Andersdotter
Technical Consultant, Digital Programme

ARTICLE19
www.article19.org

PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55