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: > >> On 2 May 2018, at 23:24, Stephen Farrell >> <[email protected]> wrote: >> >> >> 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. >> > > 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. > >> - 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.) >> > > Are you asserting that source port logging would make PM > easier/“betterâ€? 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. > > daveor > >
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
