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

Dear Amelia, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Amelia Andersdotter [mailto:amelia@article19.org]
> Envoyé : lundi 23 avril 2018 21:04
> À : BOUCADAIR Mohamed IMT/OLN; int-area@ietf.org
> Cc : Stephen Farrell
> Objet : Re: draft-andersdotter (was RE: [Int-area] WG adoption call:
> Availability of Information in Criminal Investigations Involving Large-Scale
> IP Address Sharing Technologies
> 
> Dear Mohamed,
> all,
> 
> On 2018-04-23 10:38, mohamed.boucadair@orange.com 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.

[Med] It is a not a problem with the language of the reco, but its implementation. The IETF cannot dictate which information is required to provide a service and whether an IP address is needed. This is really implementation-specific. 

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

[Med] I don't have a problem with the general intent of your text, my concern is that you link those explicitly with RFC6302 which is misleading. RFC6302 has a very clear focus: address sharing. 

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

[Med] How those servers will react to DDoS attacks or other abuses? 

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

[Med] But there are laws out of there. I don't think that we need to interfere with those. 

 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.

[Med] But how this is related to RFC6302 context? 

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

[Med] Rules to access regulatory data are well known. 

> 
> 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:int-area-bounces@ietf.org] De la part de Amelia
> >> Andersdotter
> >> Envoyé : lundi 23 avril 2018 10:11
> >> À : int-area@ietf.org
> >> 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
> >> Int-area@ietf.org
> >> 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
> 