Subject: Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

From: Dave O'Reilly <[email-masked]>
Date: Tue, 1 May 2018 12:21:11 +0100

Dear all,

The intarea chairs have set a deadline of this Friday, 4th May, for the adoption call of the document draft-daveor-cgn-logging-04. 

In my opinion, I have addressed all of the comments that have been raised in relation to this draft, at least to the extent that warrants further discussion of the recommendations by the group. If anyone is of the opinion that there are points that I have not adequately addressed, please highlight them and I will try again. 

I would therefore like to make a final request for support of the adoption of the draft document by the working group.

Regards,
daveor

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Tue, 1 May 2018 16:06:35 +0000

With the permission of Ted, I’m forwarding an off-line email that brings up an important point about the scope of the document, which is relevant for the decision about the adoption call by the WG.

Juan Carlos

From: Ted Lemon [mailto:[email-masked]]
Sent: May 1, 2018 11:43 AM
To: Dave O'Reilly <[email-masked]>
Cc: Stephen Farrell <[email-masked]>; Juan Carlos Zuniga <[email-masked]>; [email-masked]
Subject: Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On May 1, 2018, at 10:00 AM, Dave O'Reilly <[email-masked]<mailto:[email-masked]>> wrote:
Chairs (and Ted, in response to his mail): if you feel there are any objections that have not been adequately addressed, I would appreciate an opportunity to address them specifically.

Again, Dave, that is not the conversation we are having here.   The way that a document is adopted is not "we adopt it unless nobody objects."   It is "we see if there is consensus to adopt it, and if it's in scope for the work we are chartered to do, and if both of these are true, and if there is energy in the working group to work on it, then we work on it."

The problems you have are:

  1.  There are quite a few participants here who think this is not a good idea for the IETF to work on
  2.  It's not clear that the work is in scope for the working group anyway
  3.  For me at least, this is work that I can't get paid to do, and so I don't want to do it.   So if I'm going to participate, I have to be convinced that there's a really serious problem here that is urgent enough that the working group must work on it or there will be some bad outcome.   And you haven't made that case at all—it's pretty clear that there are some benefits to doing the work, but there are also some drawbacks, and figuring out the right balance will be a lot of work.   Not doing the work is less work.   So if you want the working group to work on this, you need to explain to us why it's worth it to us to spend our resources on this, rather than saying "no, let's not do this."

"No, let's not do this" is the default, and it's my personal preference, since I'm pretty sure there are other, more valuable things I could do with the time I'd spend trying to get this document to do as little harm as possible.   Unfortunately, it's pretty clear to me that if the working group adopts this document, I will have to do that work, so that's why I'm pushing back on adoption.

If this seems like a pretty high bar to get over, that's because it is.   The IETF should not work on a document just because some IETF participant thinks it's worth working on.   The reason you want to do this in the IETF is that there's value to you in the IETF having published the document, and not some other organization, and not you personally.   What's the value to the IETF in publishing this document?

---

From: Dave O'Reilly <[email-masked]>
Date: Tue, 1 May 2018 17:36:21 +0100

Thanks Juan Carlos,

My response to Teds email is below:

> Again, Dave, that is not the conversation we are having here.   The way that a document is adopted is not "we adopt it unless nobody objects."   It is "we see if there is consensus to adopt it, and if it's in scope for the work we are chartered to do, and if both of these are true, and if there is energy in the working group to work on it, then we work on it.”
>  

I’m aware of this and, to be honest, it’s clear to me that there is no consensus (at least no vocal consensus in this discussion so far) for the adoption of the document. Nevertheless, all I can do is present my arguments as robustly as I can and to the best of my ability.

> 	• There are quite a few participants here who think this is not a good idea for the IETF to work on

That is apparent to me :-)

> 	• It's not clear that the work is in scope for the working group anyway

Well, three things there:

1. It was Suresh Krishnan (the intarea director) that referred me to the intarea group with my draft in the first place.
2. If I look at the charter for the intarea group (https://datatracker.ietf.org/doc/charter-ietf-intarea/) I noted the following scope item in particular seems applicable: "The Internet Area receives occasional proposals for the development and publication of RFCs that are not in scope of an existing working group and do not justify the formation of a new working group. The INTAREA WG has a secondary role to serve as the forum for developing such workitems in the IETF."
3. If there is a more appropriate forum for discussion, what do you think it is?

> 	• For me at least, this is work that I can't get paid to do, and so I don't want to do it.   So if I'm going to participate, I have to be convinced that there's a really serious problem here that is urgent enough that the working group must work on it or there will be some bad outcome.  

Same here.

> And you haven't made that case at all—it's pretty clear that there are some benefits to doing the work, but there are also some drawbacks, and figuring out the right balance will be a lot of work.   Not doing the work is less work.   So if you want the working group to work on this, you need to explain to us why it's worth it to us to spend our resources on this, rather than saying "no, let's not do this.”

How can I make it more clear? 

In the document I refer to law enforcement publications that state that the crime attribution challenges presented by carrier grade NAT are serious internet governance challenges (https://www.europol.europa.eu/sites/default/files/documents/europol_iocta_web_2016.pdf). Also this document refers to an EU survey (reference no. 186) that indicates that 90% of respondents (cybercrime units in EU member states) regularly encounter carrier grade NAT in their investigations.

intarea has already published RFC6302 and all I’m trying to do is enhance the effectiveness of the recommendations already published in that document.

> If this seems like a pretty high bar to get over, that's because it is.   The IETF should not work on a document just because some IETF participant thinks it's worth working on.   The reason you wa…

I suppose I can see how it would appear that way to you. There’s value to me in the sense that I think the world (and the Internet in particular) would be a better place if more cybercriminals were caught. 

The IETF has a role in the governance of the Internet, I am pointing out a governance problem along with a proposal for some recommendations - that’s the value to the IETF. 

daveor

---

From: Ted Lemon <[email-masked]>
Date: Tue, 1 May 2018 12:55:30 -0400

> 3. If there is a more appropriate forum for discussion, what do you think it is?

I didn't say that there was a better forum.   I said that you haven't said anything to convince me that the IETF in particular should be working on this, or that it's worth my time in particular to try to help you navigate the balance between doing something you think is necessary and making things worse for the online safety of Internet users.

In particular, this is not an internet governance issue.   You are talking about logging of A+P on servers on the internet, not the operation of the internet.

Again, don't tell me what the value of this is to you.   We already understand that it's valuable to you.   Try to figure out how it's valuable to the IETF.  Why we should spend time working on it.   Tell us why we should put the IETF's name on it, and say that it's how the IETF recommends things be done.

The problem is that you've already tried to do that, and it wasn't convincing.   I don't think this is something the IETF should work on, and you haven't convinced me otherwise.   It seems to me more like something a government standards org should work on.   That would make it applicable in the right context, and would prevent it from becoming a blanket recommendation, which is what it would have to be if the IETF published it.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 May 2018 10:42:10 +1200

On 02/05/2018 04:36, Dave O'Reilly wrote:
...
> The IETF has a role in the governance of the Internet, 

That's news to me. I've never been completely sure what
"governance of the Internet" actually means**, but in any case
it isn't mentioned in the mission statement at
https://tools.ietf.org/html/rfc3935

Both this draft and draft-andersdotter-intarea-update-to-rfc6302
take me out of my comfort zone for IETF scope.

   Brian

** Full disclosure: my rants on this topic can be found at
https://www.cs.auckland.ac.nz/~brian/bits.html
but please let's not discuss them here.

---

From: Dave O'Reilly <[email-masked]>
Date: Wed, 2 May 2018 11:14:10 +0100

Ted,

> On 1 May 2018, at 17:55, Ted Lemon <[email-masked]> wrote:
> 
> I didn't say that there was a better forum.  

No, what you said was that “it’s not clear that the work is in scope of the working group anyway”. And I was asking you, if it isn’t, where would be a more appropriate place to have the discussion? 

> I said that you haven't said anything to convince me that the IETF in particular should be working on this, or that it's worth my time in particular to try to help you navigate the balance between doing something you think is necessary and making things worse for the online safety of Internet users.
> 

That depends how you define Internet governance, I suppose. I would argue otherwise but it’s not too important - see also the comments in the email to Brian. 

> The problem is that you've already tried to do that, and it wasn't convincing.   I don't think this is something the IETF should work on, and you haven't convinced me otherwise.   It seems to me mo…

Well what it seems to me that you’re saying is that you don’t want to work on the draft, and that’s entirely up to you. So we have you on one side of the opinion and me on the other. I can already see which way (at least the vocal part of the) consensus is - you’d need to be intellectually blind not to - but for me this conversation is as important as the eventual outcome of the document per se. 

I could go to law enforcement agencies, regulators etc. and talk about this problem - and I have - but they already know it’s a problem and recognise that something needs to be done. It’s only when you present an opinion to a group who have a totally different perspective that you get new arguments presented and get make any sort of intellectual progress. In that regard, none of this discussion has made me less convinced that source port logging is the best solution to crime attribution problems arising from CGN (IPv6 migration comes with its own can of worms that I discuss elsewhere). In fact I think I recall that even you agreed that if IP address is being logged, source port should be logged as well. 

The only alternatives that I can see for closing the crime attribution information gap that has been opened by CGN are (a) severely limit the number of endpoints behind a given CGN IP address (a la what the Belgian ISPs are doing) or (b) require ISPs to perform connection logging (which is a privacy disaster) or (c) force migration to IPv6 (which only moves the problem around as per my other document). If there are any other options, I’d love to hear them. I can tell you all out there who work in ISPs that if/when regulators act on this, it’s going to be one of those options for you. Regulators have only power to regulate ISPs so they will find ISP-centric solutions, which are the list of options above - none of which I consider to be very attractive (apart from migration to IPv6). What I was proposing was an “Internet” solution of a sort, where if source port logging is done routinely then there is no need for regulatory intervention to close the information gap - I would like to think that what I was trying to propose was the “least worst” option for dealing with the problem.

Whether the IETF is going to do anything about the problem - and I think it should - is incidental, but as you have pointed out I am only once voice. The problem is real and someone needs to do something. 

Finally, I’d also like to point out that one of the recommendations that I made in my document is that awareness of this issue needs to be raised and perhaps there’s someone who is reading this thread who might now be aware of this problem who wasn’t already and it might, in some small way, shape future thinking.

daveor

---

From: Dave O'Reilly <[email-masked]>
Date: Wed, 2 May 2018 11:15:54 +0100

Brian,

A very interesting email. 

Referring to the mission statement: https://tools.ietf.org/html/rfc3935

"The goal of the IETF is to make the Internet work better.”

I offer the following thoughts:

1. Definition of the term “Internet”

RFC3935 defines “Internet” as follows:

The Internet: A large, heterogeneous collection of interconnected systems that can be used for communication of many different types between any interested parties connected to it.  The term includes both the "core Internet" (ISP networks) and "edge Internet” (corporate and private networks, often connected via firewalls, NAT boxes, application layer gateways and similar devices).  The Internet is a truly global network, reaching into just about every country in the world.”

Although “systems” are referenced above it seems to me that the definition is intended to relate to internetworking connectivity, rather than end systems. Nevertheless, if you look at the work of the IETF, there is clearly work going on in relation to the activity of endpoints on the Internet - I could provide a list of working groups that I think fall into this category if people disagree with this point but I point to the application/real time area generally.

2. Definition of the term “better”

This term is undefined in the document. However, However, I put forward the following argument for your consideration:

a. “Better” will in some sense incorporate “more secure”
b. Security includes consideration of the implications of breaches of security
c. The implications of a breach of security need to take into account the risks to privacy ****BUT ALSO THE RIGHTS OF VICTIMS OF CRIME****

3. Once again I most also note that RFC3935 puts forward no consideration of the victims of crime on the Internet. 

4. On the point of the term internet governance - I agree with you that the term is poorly defined. I have briefly read some of your thoughts in the link you provided - I have some comments and would be interested in talking about that with you. I note you don’t want to have that discussion here but if you are interested in corresponding on this point further you might ping me an off-list email and we can start a separate discussion.

Regards,
daveor

> On 1 May 2018, at 23:42, Brian E Carpenter <[email-masked]> wrote:
> 
> ....
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Dave O'Reilly <[email-masked]>
Date: Wed, 2 May 2018 11:08:25 +0100

Brian,

Regards,
daveor

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 May 2018 09:02:55 -0400

> No, what you said was that “it’s not clear that the work is in scope of the working group anyway”. And I was asking you, if it isn’t, where would be a more appropriate place to have the discussion? 

It's possible that the IETF would be the best place to do this work if we had the energy to do it.   But I don't think we do.   Stephen actually said he'd be willing to work on something, but I don't think you took that as a genuine offer, or else you concluded that what he'd come up with wouldn't satisfy your needs.

There isn't some other working group in the IETF of which I'm aware that would be a better place to work on this.   That's why I've mentioned doing it in government standards bodies.   E.g., since I think you're in Ireland, maybe ETSI.

> Well what it seems to me that you’re saying is that you don’t want to work on the draft, and that’s entirely up to you. So we have you on one side of the opinion and me on the other. I can already…

What I was exactly saying is that if you want people here to work on it, you need to convince us that it's worth working on, and you haven't done that.

> I could go to law enforcement agencies, regulators etc. and talk about this problem - and I have - but they already know it’s a problem and recognise that something needs to be done. It’s only when…

Yes.   I don't think anybody here is disagreeing with you on a technical level—that's why that's not what we need to talk about.

> The only alternatives that I can see for closing the crime attribution information gap that has been opened by CGN are (a) severely limit the number of endpoints behind a given CGN IP address (a la…

That's a much better approach to take if you want to convince the working group that this is worth doing.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 May 2018 09:16:08 -0400

> That's a much better approach to take if you want to convince the working group that this is worth doing.

BTW, if you are going to take that approach, you should bear in mind that most of us assume that pervasive monitoring is going on already—that is, every connection is already being logged, just not by the ISP.   That may sound like an extreme position to take, but we've seen buildings built in the desert to house this data, so it's hard not to take it seriously.   What we haven't seen, unfortunately, is that data being used for anyone's benefit in terms of preventing or punishing actual online crime.   So at the moment it's all stick, no carrot.

---

From: Linus Lüssing <[email-masked]>
Date: Wed, 2 May 2018 16:08:57 +0200

On Wed, May 02, 2018 at 11:15:54AM +0100, Dave O'Reilly wrote:
[...]
> The Internet: A large, heterogeneous collection of interconnected systems that can be used for communication of many different types between any interested parties connected to it.  
[...]
> This term is undefined in the document. However, However, I put forward the following argument for your consideration:

Since the Internet is about communication, I would interpret
"better" in this context as improving and encouraging communication.
Any logging however, if not done as a temporary measure to understand
and enhance a protocol (configuration), will potentially discourage
communication.

> c. The implications of a breach of security need to take into account the risks to privacy ****BUT ALSO THE RIGHTS OF VICTIMS OF CRIME****

To me this draft has the potential to stifle the rights of
victims, too: A permanent IP/source-port logging could create a
significant barrier for victims to seek help and guidance over the
Internet. I could not find any such considerations in the current
draft.

Regards, Linus

---

From: Dave O'Reilly <[email-masked]>
Date: Wed, 2 May 2018 15:20:09 +0100

Linus,

> On 2 May 2018, at 15:08, Linus Lüssing <[email-masked]> wrote:
> 
> 

I don’t think even those who are most aggressively opposed to the viewpoint I am espousing here would agree with you that "any logging however, if not done as a temporary measure to understand and enhance a protocol would potentially discourage communication". 

> Internet. I could not find any such considerations in the current

I agree that the document does not contain this, because I do not think it is correct. In what way does logging IP/source port create a barrier for victims? Why is it any different to logging IP address, which is routine at the moment, in terms of creating any sort of barrier for victims?

You mention “permanent” - In case you haven’t already, I encourage you to read back over the rest of this thread because we’re specifically not talking about how long logs should be kept for, rather the advantages/disadvantages of logging source port whenever IP address is logged - and in the case of my document, what else can be done to encourage that approach.

daveor

---

From: Dave O'Reilly <[email-masked]>
Date: Wed, 2 May 2018 16:13:47 +0100

Dear all,

On reflection, I would like to send a clarification to my previous email. 

I didn’t want to see the conversation going all the way back to the beginning and covering the same ground again, so I responded to this email in haste.

In particular in relation to this comment:

> 
> I don’t think even those who are most aggressively opposed to the viewpoint I am espousing here would agree with you that "any logging however, if not done as a temporary measure to understand and enhance a protocol would potentially discourage communication”.

It is a mischaracterisation to represent those with whom I have been engaged as “aggressively opposed” to my viewpoint. I think we have covered a lot of ground here and both positions have been put forward with gusto but never aggressively. I would also like to say that I think that this has been a very worthwhile discussion. This comment subtracts from the value of the discussion and I apologise for that.

daveor

---

From: Dave O'Reilly <[email-masked]>
Date: Wed, 2 May 2018 23:02:25 +0100

Ted,

> On 2 May 2018, at 14:02, Ted Lemon <[email-masked]> wrote:
> 
> 

All of these points are addressed in the current version of the document. It’s perhaps not put in a way that refers so directly to the regulatory alternatives but they are discussed. Specifically, an entire section (Section 3) contains a discussion of the reasons why ISP connection logging is dismissed as a recommended solution to this problem. IPv6 as an ultimate solution is also mentioned in the paragraph at the end of Section 1.

> BTW, if you are going to take that approach, you should bear in mind that most of us assume that pervasive monitoring is going on already—that is, every connection is already being logged, just not…

Your terminology is not very clearly defined, so I’m presuming when you say pervasive monitoring you mean the interception of the content of communication. Is that fair?
 
Connection monitoring of the type you are alluding to, were it performed by an ISP - without some sort of legal instruction from a competent court - would almost certainly put them in violation of the terms of their operating license and probably criminally liable as well. In every jurisdiction that I am aware of there is a license obligation on ISPs to maintain the privacy and confidentiality of subscriber communication. Maybe someone can point to a counterexample but if it’s not universally true I’d imagine it’s true in the overwhelming majority of cases.

So what I assume we’re talking about here is law enforcement access to the content of communication. Once again, I ask is that what you meant?
 
If that is indeed what you meant, well then what I can tell you is that, as far as I understand, these powers cannot be exercised without the most stringent judicial oversight - at least not in any country where I have worked. So I really do not think the sort of wholesale, indiscriminate data collection of the type you are alluding to takes place (or is even an option) in routine criminal investigations. That’s to say nothing of the cost in terms of both equipment and manpower required to handle in any meaningful way such a volume of data.

Counter-terrorism (whatever that means) and national security - these are areas where things might be different but I have no experience with them. The Snowden and other revelations would certainly suggest that national security agencies all around the world are collecting data about all of us (hello NSA!). This is a very emotive topic so I request level-headed consideration of the context of these revelations, in particular:

1. I encourage you not to paint the entire criminal justice system with the brush that has been dirtied by the national security shenanigans that have been taking place. 
2. It’s probably fair to say that, in my experience at least, most law enforcement agencies neither have or want indiscriminate access to this type of data - these are the ones that need help with CGN. How do you reconcile the existence of a hypothetical database of everyone’s internet communication with being stumped by CGN? Surely one, if it existed and was accessible to law enforcement, would preclude the need for dealing with the other?

Finally, to your point about not seeing ‘"that data being used for anyone's benefit in terms of preventing or punishing actual online crime”. Well first of all that assumes (a) the existence of some data (perhaps all of our internet communications but you might clarify what data you mean?) and (b) that the data, if it exists, is accessible to those law enforcement agents that are investigating online crime. Would the application of Occam’s razor not suggest that, given the prevalence of online crime, either (a) or (b) or both are false? Why are law enforcement agencies, if they have access to all of this data, letting so many criminals operate on the internet with impunity? I’d be interested to hear what you think?

daveor

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 May 2018 18:14:40 -0400

> All of these points are addressed in the current version of the document. It’s perhaps not put in a way that refers so directly to the regulatory alternatives but they are discussed. Specifically,…

While this is true, there's nothing in the document that we haven't discussed on the mailing list.

> Your terminology is not very clearly defined, so I’m presuming when you say pervasive monitoring you mean the interception of the content of communication. Is that fair?

https://tools.ietf.org/html/rfc7258 <https://tools.ietf.org/html/rfc7258>

Look, I'm sorry to belabor the "lazy" point, but the question isn't "is there a problem."   We agree that there is a problem.   The question is, "should the IETF work on it."

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 May 2018 23:24:14 +0100

On 02/05/18 23:02, Dave O'Reilly wrote:
> This is a very emotive topic so I request level-headed consideration
> of the context of these revelations, 

Please review the long discussion that lead to RFC7258. (That's the
one I pointed you at the other day in an off-list discussion.) You
may be coming to this topic in an IETF context as a new one, but it
is not a new topic here. Asking that we be "level headed" only gives
an impression of not having done one's homework.

Other than that:

- In terms of discussion venues within the IETF - ISTM that there's
little point in a document about what applications ought log that
isn't discussed on the art-area list (as I pointed out in my
original mail on this topic and also mentioned the other day).

- Your discussion of PM totally misses the point. A lot of traffic
is being stored, it doesn't matter if your preferred LEAs don't have
access to that. The question instead is rather whether or not your
proposed mechanism makes PM easier/"better" or not for any of whomever
you consider bad actors doing PM. And then generalise from that to
realise that your (or my) classification of good/bad actors is likely
quite different from classifications that many other people may
find sensible. (That is not the only question to ponder related to
your proposed mechanism, but it is one question.)

In summary: I don't consider that the objections I raised originally
were answered, nor do recent mails make me any happier about this
draft. And yes, I would engage in attempts to openly discuss LEA
requirements (*not* mechanisms, requirements) and how those can or
cannot be reconciled with today's equally real requirements for
openness, security and privacy. I don't actually know of a good
IETF venue for that discussion, but I'd certainly bet a beer it is
not this list:-)

S.

---

From: Dave O'Reilly <[email-masked]>
Date: Thu, 3 May 2018 09:32:22 +0100

> On 2 May 2018, at 23:24, Stephen Farrell <[email-masked]> wrote:
> 
> 

I have read RFC7258 and everything that I can find on the mailing list archive relating to this topic. The fact that by doing so I haven’t come around to your opinion doesn’t mean I haven’t done my homework. Please point out to me what specifically you think I haven’t read rather than casting aspersions.

Maybe I didn’t make clear the point I was trying to make in my email last night - I don’t know. I thought I did, but maybe not. 

I am specifically drawing a distinction between monitoring of the sort you are talking about (pervasive monitoring) and the need for access to data for crime attribution. In my email from last night I said, for example "How do you reconcile the existence of a hypothetical database of everyone’s internet communication with being stumped by CGN?” and requested "not to paint the entire criminal justice system with the brush that has been dirtied by the national security shenanigans that have been taking place." 

Crime attribution is in some respects the opposite of monitoring - pervasive monitoring is a preemptive act (at least as you appear to be defining it in RFC7258 - "PM is distinguished by being indiscriminate and very large-scale”) whereas crime attribution is an after-the-fact, investigative action to associate known criminal activity with a perpetrator. It is possible to help out in one situation without making things worse in the other. 

Therefore the position adopted by the IETF in RFC7258 does not seem to be applicable because we’re not talking about the same thing.
 
> original mail on this topic and also mentioned the other day).

I haven’t got the headspace to have more than one discussion like this at a time, so I will post in the artarea list when this conversation has concluded.

> your proposed mechanism, but it is one question.)

Are you asserting that source port logging would make PM easier/“better”? 

If so, here you are asserting this again without providing any evidence to support your position - I do not accept this and I challenge you to support this point with some evidence to move the discussion along.

> IETF venue for that discussion, but I'd certainly bet a beer it is

We briefly discussed this when we met and I also am happy to engage in a discussion about LEA requirements but, as I mentioned above, can we finish one discussion before moving on to something else.

daveor

---

From: Dave O'Reilly <[email-masked]>
Date: Thu, 3 May 2018 09:36:33 +0100

> On 2 May 2018, at 23:14, Ted Lemon <[email-masked]> wrote:
> 
> https://tools.ietf.org/html/rfc7258
> 

I suppose the reason I think the IETF should work on this topic is that I don’t think it is acceptable that the IETF wash its hands of the consequences of its technical decisions on crime attribution on the internet. Whether those implications are “by design" (e.g. IPv6 SLAAC privacy addresses) or indirect (e.g. the CGN issues we are currently discussing), the consequences are real and are making the world less safe from a criminal investigation point of view.

daveor

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 May 2018 10:39:50 +0100

Dave,

On 03/05/18 09:32, Dave O'Reilly wrote:
> Please point out to me what specifically you think I havenâ€™t read
> rather than casting aspersions.
That's not useful. I cast no aspersions but solely pointed
out questions that ought be asked. Please re-read my mail.

S.

---

From: Dave O'Reilly <[email-masked]>
Date: Thu, 3 May 2018 11:55:57 +0100

Stephen,

If I have given you the impression that I haven’t “done my homework” as you said in your email, then please point out what you think I should have read….I do happen to quite like reading after all.

Either way, are you going to respond to the substance of my previous email? I have re-read your email, and I think my follow-up comments and requests for clarification are reasonable.

daveor

>  On 3 May 2018, at 10:39, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Dave,
> 
> <0x5AB2FAF17B172BEA.asc>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 May 2018 13:08:22 +0100

Dave,

You asked for responses, so I'll try, but I don't expect that
they'll satisfy you as I am not attempting to do the work of
analysing how your draft does/doesn't affect PM (that's your
job, not mine:-). But just in case it's useful...

On 03/05/18 09:32, Dave O'Reilly wrote:
>>> This is a very emotive topic so I request level-headed
>>> consideration of the context of these revelations,
>> 
>> Please review the long discussion that lead to RFC7258. (That's
>> the one I pointed you at the other day in an off-list discussion.)
>> You may be coming to this topic in an IETF context as a new one,
>> but it is not a new topic here. Asking that we be "level headed"
>> only gives an impression of not having done one's homework.
>> 
> 
> I have read RFC7258 and everything that I can find on the mailing
> list archive relating to this topic. The fact that by doing so I
> haven’t come around to your opinion doesn’t mean I haven’t done
> my homework. Please point out to me what specifically you think I
> haven’t read rather than casting aspersions.
> 
> Maybe I didn’t make clear the point I was trying to make in my
> email last night - I don’t know. I thought I did, but maybe not.
> 
> I am specifically drawing a distinction between monitoring of the
> sort you are talking about (pervasive monitoring) and the need for
> access to data for crime attribution. 

Those aren't commensurate things, so that's not a useful
distinction, for this discussion.

> In my email from last night I
> said, for example "How do you reconcile the existence of a
> hypothetical database of everyone’s internet communication with
> being stumped by CGN?” and requested "not to paint the entire
> criminal justice system with the brush that has been dirtied by the
> national security shenanigans that have been taking place."

- I didn't say there was a DB of everyone's comms. But there are
lots of large DB's with lots of peoples comms, under the control
of various actors some of whom spend *lots* of money on their
PM attacks. So "hypothetical" doesn't help the discussion,
as that gives the impression that you don't accept that PM is a
real thing.
- And I never painted any picture of any criminal justice system,
neither a dirty one, nor a clean one.

> 
> Crime attribution is in some respects the opposite of monitoring -

Yet your draft is not the "opposite" of monitoring. (And just
in case you misinterpret that, I am not saying that monitoring
is always bad or anything like that.)

> pervasive monitoring is a preemptive act (at least as you appear to
> be defining it in RFC7258 - "PM is distinguished by being
> indiscriminate and very large-scale”) whereas crime attribution is
> an after-the-fact, investigative action to associate known criminal
> activity with a perpetrator. It is possible to help out in one
> situation without making things worse in the other.

Maybe. That's where I think the onus is on you to figure out
if that's the case or not, and to document it in such a way
that others can (dis)agree with your analysis.

> 
> Therefore the position adopted by the IETF in RFC7258 does not seem
> to be applicable because we’re not talking about the same thing.

7258 is a BCP that says that the IETF will consider the PM threat.
You may think you've done that, but my reading of the draft (a
few weeks ago) doesn't convince me of that. Saying that "crime
attribution is not PM" is not an answer IMO. Setting HTTP cookies
is not PM, but has been abused for PM for example.

Note that I've not said that logging source ports is a huge new
PM threat. Among the many things I'm also not saying is that
logging source ports is unrelated to PM:-)

> 
>> Other than that:
>> 
>> - In terms of discussion venues within the IETF - ISTM that
>> there's little point in a document about what applications ought
>> log that isn't discussed on the art-area list (as I pointed out in
>> my original mail on this topic and also mentioned the other day).
>> 
> 
> I haven’t got the headspace to have more than one discussion like
> this at a time, so I will post in the artarea list when this
> conversation has concluded.

IMO, that's where a discussion of your draft could be much more
fruitful. That's where there are people who'd know if adding source
ports to application logs would be feasible, break things etc.
I've no clue myself if people who write the code related to such
logs would or would not want to do this. I do suspect that an
RFC recommending something that'd break logging tooling would be
pretty pointless as it'd not happen, and thus not solve the
problem you're aiming to solve.

>> is being stored, it doesn't matter if your preferred LEAs don't
>> have access to that. The question instead is rather whether or not
>> your proposed mechanism makes PM easier/"better" or not for any of
>> whomever you consider bad actors doing PM. And then generalise from
>> that to realise that your (or my) classification of good/bad actors
>> is likely quite different from classifications that many other
>> people may find sensible. (That is not the only question to ponder
>> related to your proposed mechanism, but it is one question.)
>> 
> 

No. I'm asserting that the analysis isn't visible in your
draft. I posed a question, I didn't take a position on the
answer.

> 
> If so, here you are asserting this again without providing any
> evidence to support your position - I do not accept this and I
> challenge you to support this point with some evidence to move the
> discussion along.
> 
>> In summary: I don't consider that the objections I raised
>> originally were answered, nor do recent mails make me any happier
>> about this draft. And yes, I would engage in attempts to openly
>> discuss LEA requirements (*not* mechanisms, requirements) and how
>> those can or cannot be reconciled with today's equally real
>> requirements for openness, security and privacy. I don't actually
>> know of a good IETF venue for that discussion, but I'd certainly
>> bet a beer it is not this list:-)
>> 
> 
> We briefly discussed this when we met and I also am happy to engage
> in a discussion about LEA requirements but, as I mentioned above, can
> we finish one discussion before moving on to something else.

IMO that's backwards. A mechanism such as the one you're proposing
would much more likely be acceptable if there were consensus on the
requirements beforehand, and if the mechanism was consistent with
that consensus. (I don't believe there is such a consensus today,
but luckily I'm not a consensus-caller for any of this so it's not
that important what I think:-)

S.

---

From: Dave O'Reilly <[email-masked]>
Date: Thu, 3 May 2018 14:12:41 +0100

Stephen,

> On 3 May 2018, at 13:08, Stephen Farrell <[email-masked]> wrote:
> 
> job, not mine:-). But just in case it's useful…
> 

I agree. That’s what I’m trying to do here - argue that my draft has nothing to do with pervasive monitoring (I’m using your term as defined in RFC7258).

>> havenâ€™t come around to your opinion doesnâ€™t mean I havenâ€™t done
>> havenâ€™t read rather than casting aspersions.
>> 
>> Maybe I didnâ€™t make clear the point I was trying to make in my
>> email last night - I donâ€™t know. I thought I did, but maybe not.
>> 

I agree they’re not commensurate - the issue of crime attribution is smaller, and easier to tackle.

I don’t see why the fact that the two issues are different sizes makes the distinction that I made made invalid. Can you explain that to me?

>> hypothetical database of everyoneâ€™s internet communication with
>> being stumped by CGN?â€ and requested "not to paint the entire

I agree “hypothetical” doesn’t help the discussion. I also acknowledge that the Snowdon revelations would suggest that large-scale indiscriminate monitoring of our data has been taking place - my question remains though - what has that got to do with crime attribution? 

I have already explained the difference - do you recognise that there is a difference between these two things?

> is always bad or anything like that.)

My draft proposes logging sufficient information to attribute crime (in the presence of CGNs) in the most privacy sensitive way possible - nothing to do with monitoring at all.

>> indiscriminate and very large-scaleâ€) whereas crime attribution is

I refer you to the Council of Europe Budapest convention on cybercrime (https://www.coe.int/en/web/conventions/full-list/-/conventions/rms/0900001680081561). This is the most widely adopted model law on cybercrime in the world, with currently 56 country signatories - so its provisions are representative of the legal situation in 56 countries, including the United States (but ironically enough, not including Ireland) :-)

Article 19 describes the procedural powers relating to the search and seizure of stored computer data - this is the access to data for crime attribution aspect.

Article 20 describes the procedural powers relating to the real-time collection of traffic data - this is the monitoring aspect. 

Both are subject to the scope, conditions and safeguards provisions of Articles 14 and 15, but in summary, these are different things. 

If a national security/police agency/other competent authority walks into an ISP with an appropriate court order and tells the ISP to perform monitoring on person A (or more ominously in the case of national security, attach this “black box” to your network), then that person (or people) is/are going to be monitored - otherwise the ISP will be in breach of the law. What has that got to do with logging source ports? How does logging source ports make the slightest bit of difference to that? Logging source ports won’t make one jot of difference to the ability (or lack of ability) of any agency with appropriate legal authority to do something like that. 

>> to be applicable because weâ€™re not talking about the same thing.
> 

Why is saying that "crime attribution is not PM” not an answer? 

If A is bad and B is not A, then you can’t say that because A is bad, therefore B is bad. (A = pervasive monitoring, B = crime attribution).

> logging source ports is unrelated to PM:-)

I agree with you that logging source ports is not a PM threat. 

I assert that logging source ports is nothing to do with PM - I believe I have demonstrated that in this email. If you do not agree, what do you not find convincing about what I have said here?

>> I havenâ€™t got the headspace to have more than one discussion like

Yes, and that conversation will happen after this one.

>> Are you asserting that source port logging would make PM
>> easier/â€œbetterâ€?
> 

Well, if the document is adopted by the working group, we can put it in there :-) 

I’ll work on that analysis (along with anyone else who is interested) if the working group accepts the document. Further, if the analysis shows that source port logging would make monitoring easier/better then I am prepared to accept that the working group drop the draft altogether at that point. 

> that important what I think:-)

I would still like to have this discussion with you (and others) after we have finished the discussion about this document.

daveor

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 May 2018 14:26:42 +0100

Dave,

> I agree with you that logging source ports is not a PM threat. 

No, you do not agree with me on that because I did not
say that. It seems the more words I type in this thread
the more times I end up having to correct such things,
so I'm gonna leave it to the chairs to figure out how
they view the overall state of play and leave it at
that for now.

S.

---

From: Dave O'Reilly <[email-masked]>
Date: Thu, 3 May 2018 15:00:15 +0100

That was a minor point in my email - what about all of the rest of it?

daveor

> On 3 May 2018, at 14:26, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Dave,
>