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

2018-04-25 Thread Dave O'Reilly 

> On 25 Apr 2018, at 05:59, Amelia Andersdotter  wrote:
> 
> On 2018-04-25 03:22, Ted Lemon wrote:
>> On Apr 24, 2018, at 7:57 PM, Brian E Carpenter
>> > wrote:
>>> Clearly not, but operations people are much more likely to apply a "log
>>> everything we can store" approach than to be selective in advance. I
>>> think
>>> it's privacy law, not IETF BCPs, that will make them think more
>>> carefully.
>> 
>> That would be an argument for not doing this work, then.
>> 
> 
> It will also be very challenging for lots of smaller operations (I've
> interacted a lot with Swedish municipalities, some varities of Swedish
> NGOs) to know what good practises are, when something is *technically
> necessary* or just *convenient*, when they need to start considering
> privacy terms (basically one it's convenience rather than technology
> that's at play).
> 
> I think these are things that would be helpful if the IETF weeds out.

I agree with the assertion that the IETF has an important role to play here.. 

The point I’m trying to make is that logging less is not a priori the best 
solution, because logging less does not have zero negative consequences. 

daveor
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

2018-04-24 Thread Amelia Andersdotter 
On 2018-04-25 00:26, Brian E Carpenter wrote:
> On 24/04/2018 18:08, Amelia Andersdotter wrote:
>> Dear Mohamed,
>>
>> See below:
>>
>> On 2018-04-24 07:25, mohamed.boucad...@orange.com wrote:
>>> [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. 
>>>
>>> [Med] But how this is related to RFC6302 context? 
>> RFC6302 is hopelessly out of date. It was specifically justified by a
>> regulatory framework which no longer exists(!) and it takes into account
>> none of the privacy guidances given by RFC6973.
> I can't find any reference to regulatory matters in RFC 6302,
> but I did find this:
>   "In the absence of the source port number and accurate timestamp
>information, operators deploying any address sharing techniques will
>not be able to identify unambiguously customers when dealing with
>abuse or public safety queries."
> Has that changed since 2011?

The reference is to RFC6269 in the introduction, which claims (section
12) that the need for traceability is regulatorily motivated. When one
makes a recommendation starting from the assumption of some regulatory
need or other, and that regulatory need subsequently changes, I think
that's "outdated".

best,

A

> RFC6973 adds this:
>   "When requiring or recommending that information
>about initiators or their communications be stored or logged by end
>systems (see, e.g., RFC 6302 [RFC6302]), it is important to recognize
>the potential for that information to be compromised and for that
>potential to be weighed against the benefits of data storage."
> Indeed. But since that's a general requirement, not specific to port
> logging, what is obsolete in RFC6302 itself? It's what happens to the data
> *after* it's been collected that matters, and that affects everything
> the server collects, not just addr+port.
>
> Regards
>Brian
>
>> If we mean to say the
>> privacy guidelines of RFC6973 should not be applied specifically in our
>> recommendations for logging to internet-facing servers, then fine. If,
>> however, we believe privacy guidelines apply also when we make
>> recommendations to internet-facing servers (as we have done), then
>> RFC6302 needs updating.
>>
>> I think this is the primary thing to establish. I'll provide more
>> comments later.
>>
>> best,
>>
>> A
>>
>>

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

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

2018-04-24 Thread Amelia Andersdotter 
On 2018-04-25 03:22, Ted Lemon wrote:
> On Apr 24, 2018, at 7:57 PM, Brian E Carpenter
> > wrote:
>> Clearly not, but operations people are much more likely to apply a "log
>> everything we can store" approach than to be selective in advance. I
>> think
>> it's privacy law, not IETF BCPs, that will make them think more
>> carefully.
>
> That would be an argument for not doing this work, then.
>

It will also be very challenging for lots of smaller operations (I've
interacted a lot with Swedish municipalities, some varities of Swedish
NGOs) to know what good practises are, when something is *technically
necessary* or just *convenient*, when they need to start considering
privacy terms (basically one it's convenience rather than technology
that's at play).

I think these are things that would be helpful if the IETF weeds out.

best regards,

A

>> http://www.waitrose.com/privacynotice is worth a read, I found. It makes
>> IP addresses look very uninteresting.
>
> True.   However, one can in principle configure the not to send this
> sort of information.   IP address and port are unavoidable.
>

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

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

2018-04-24 Thread Ted Lemon 
On Apr 24, 2018, at 7:57 PM, Brian E Carpenter  
wrote:
> Clearly not, but operations people are much more likely to apply a "log
> everything we can store" approach than to be selective in advance. I think
> it's privacy law, not IETF BCPs, that will make them think more carefully.

That would be an argument for not doing this work, then.

> http://www.waitrose.com/privacynotice  
> is worth a read, I found. It makes
> IP addresses look very uninteresting.

True.   However, one can in principle configure the not to send this sort of 
information.   IP address and port are unavoidable.

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

2018-04-24 Thread Brian E Carpenter 
On 25/04/2018 11:37, Ted Lemon wrote:
> Brian, does the server *have* to collect everything?

Clearly not, but operations people are much more likely to apply a "log
everything we can store" approach than to be selective in advance. I think
it's privacy law, not IETF BCPs, that will make them think more carefully.

http://www.waitrose.com/privacynotice is worth a read, I found. It makes
IP addresses look very uninteresting.

Brian

> 
> On Tue, Apr 24, 2018, 18:26 Brian E Carpenter 
> wrote:
> 
>> On 24/04/2018 18:08, Amelia Andersdotter wrote:
>>> Dear Mohamed,
>>>
>>> See below:
>>>
>>> On 2018-04-24 07:25, mohamed.boucad...@orange.com wrote:

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

 [Med] But how this is related to RFC6302 context?
>>>
>>> RFC6302 is hopelessly out of date. It was specifically justified by a
>>> regulatory framework which no longer exists(!) and it takes into account
>>> none of the privacy guidances given by RFC6973.
>>
>> I can't find any reference to regulatory matters in RFC 6302,
>> but I did find this:
>>   "In the absence of the source port number and accurate timestamp
>>information, operators deploying any address sharing techniques will
>>not be able to identify unambiguously customers when dealing with
>>abuse or public safety queries."
>> Has that changed since 2011?
>>
>> RFC6973 adds this:
>>   "When requiring or recommending that information
>>about initiators or their communications be stored or logged by end
>>systems (see, e.g., RFC 6302 [RFC6302]), it is important to recognize
>>the potential for that information to be compromised and for that
>>potential to be weighed against the benefits of data storage."
>> Indeed. But since that's a general requirement, not specific to port
>> logging, what is obsolete in RFC6302 itself? It's what happens to the data
>> *after* it's been collected that matters, and that affects everything
>> the server collects, not just addr+port.
>>
>> Regards
>>Brian
>>
>>> If we mean to say the
>>> privacy guidelines of RFC6973 should not be applied specifically in our
>>> recommendations for logging to internet-facing servers, then fine. If,
>>> however, we believe privacy guidelines apply also when we make
>>> recommendations to internet-facing servers (as we have done), then
>>> RFC6302 needs updating.
>>>
>>> I think this is the primary thing to establish. I'll provide more
>>> comments later.
>>>
>>> best,
>>>
>>> A
>>>
>>>
>>
>> ___
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
>>
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

2018-04-24 Thread Brian E Carpenter 
On 24/04/2018 18:08, Amelia Andersdotter wrote:
> Dear Mohamed,
> 
> See below:
> 
> On 2018-04-24 07:25, mohamed.boucad...@orange.com wrote:
>>
>> [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. 
>>
>> [Med] But how this is related to RFC6302 context? 
> 
> RFC6302 is hopelessly out of date. It was specifically justified by a
> regulatory framework which no longer exists(!) and it takes into account
> none of the privacy guidances given by RFC6973.

I can't find any reference to regulatory matters in RFC 6302,
but I did find this:
  "In the absence of the source port number and accurate timestamp
   information, operators deploying any address sharing techniques will
   not be able to identify unambiguously customers when dealing with
   abuse or public safety queries."
Has that changed since 2011?

RFC6973 adds this:
  "When requiring or recommending that information
   about initiators or their communications be stored or logged by end
   systems (see, e.g., RFC 6302 [RFC6302]), it is important to recognize
   the potential for that information to be compromised and for that
   potential to be weighed against the benefits of data storage."
Indeed. But since that's a general requirement, not specific to port
logging, what is obsolete in RFC6302 itself? It's what happens to the data
*after* it's been collected that matters, and that affects everything
the server collects, not just addr+port.

Regards
   Brian

> If we mean to say the
> privacy guidelines of RFC6973 should not be applied specifically in our
> recommendations for logging to internet-facing servers, then fine. If,
> however, we believe privacy guidelines apply also when we make
> recommendations to internet-facing servers (as we have done), then
> RFC6302 needs updating.
> 
> I think this is the primary thing to establish. I'll provide more
> comments later.
> 
> best,
> 
> A
> 
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

2018-04-24 Thread mohamed.boucadair 
Re-,

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Amelia Andersdotter [mailto:ame...@article19.org]
> Envoyé : mardi 24 avril 2018 08:09
> À : 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,
> 
> See below:
> 
> On 2018-04-24 07:25, mohamed.boucad...@orange.com wrote:
> >
> > [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.
> >
> > [Med] But how this is related to RFC6302 context?
> 
> RFC6302 is hopelessly out of date. It was specifically justified by a
> regulatory framework which no longer exists(!)

[Med] Hmm, 6302 says the following: 

   Discussions about data-retention policies are out of scope for this
   document.  

Further, if we suppose an extreme case where regulatory forbids logging source 
addresses, then 6302 won't contradict with those. 

 and it takes into account
> none of the privacy guidances given by RFC6973.
 If we mean to say the
> privacy guidelines of RFC6973 should not be applied specifically in our
> recommendations for logging to internet-facing servers, then fine.

[Med] This is subtle, 6302 is motivated by address sharing. 6302 does not 
recommend logging IP addresses per se, but if a server logs IP addresses for 
whatever reason (regulatory, prevent abuses, etc.), then it should consider the 
source port too. More discussion can be found in RFC6269. 

 If,
> however, we believe privacy guidelines apply also when we make
> recommendations to internet-facing servers (as we have done), then
> RFC6302 needs updating.

[Med] It is completely fine to have such analysis/discussion for logging in 
general, but as I said earlier 6302 has a clear scope: address sharing 
complications. 

> 
> I think this is the primary thing to establish. I'll provide more
> comments later.
> 
> best,
> 
> A
> 
> 
> --
> 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

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

2018-04-24 Thread Amelia Andersdotter 
Dear Mohamed,

See below:

On 2018-04-24 07:25, mohamed.boucad...@orange.com wrote:
>
> [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. 
>
> [Med] But how this is related to RFC6302 context? 

RFC6302 is hopelessly out of date. It was specifically justified by a
regulatory framework which no longer exists(!) and it takes into account
none of the privacy guidances given by RFC6973. If we mean to say the
privacy guidelines of RFC6973 should not be applied specifically in our
recommendations for logging to internet-facing servers, then fine. If,
however, we believe privacy guidelines apply also when we make
recommendations to internet-facing servers (as we have done), then
RFC6302 needs updating.

I think this is the primary thing to establish. I'll provide more
comments later.

best,

A


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

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

2018-04-23 Thread Amelia Andersdotter 
Dear Mohamed,
all,

On 2018-04-23 10:38, mohamed.boucad...@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.

>   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:int-area-boun...@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


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

2018-04-23 Thread mohamed.boucadair 
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.  

  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.  

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. 

  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. 

  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. 

  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. 

Cheers,
Med

> -Message d'origine-
> De : Int-area [mailto:int-area-boun...@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

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area