-----Original Message----- From: Stephen Farrell [mailto:[email protected]] Sent: Tuesday, October 29, 2013 6:49 PM To: Richard Shockey Cc: [email protected] Subject: Re: [perpass] Traffic analysis
Hi Rich, On 10/29/2013 09:43 PM, Richard Shockey wrote: > > Ned makes a number of excellent points here and the real elephant in > the room is under what terms and conditions is the ongoing collection > of metadata about IP communications in any form actually needed and in > fact absolutely necessary. To the extent I can parse that, it seems like blatant assertion. > There are perfectly good reasons to collect this stuff. Though the ongoing > concern of this list is clearly the Snowden revelations some of us > actually want that data to prevent and investigate real and legitimate > fraud and abuse within the communications systems, optimize network transport etc. Countering fraud is a real requirement, agreed. I don't accept that that implies a requirement that pervasive monitoring be possible. But there are trade-offs and we do need to consider those carefully. [RS> ] Of course, then please define what you mean by pervasive monitoring. Is it just monitoring by nation state actors or are you including British Telecom, ATT, Google, Yahoo and Amazon etal into the mix. Optimising transport seems bogus though - can you provide a reference or argument as to why you'd need to pervasively monitor in a privacy unfriendly way to do that? [RS> ] [RS> ] That is simple traffic engineering. This is friendly pervasive monitoring. Any reasonable network operator wants to know where its IP traffic is coming from and where it is going. That provides the essential data to optimize Layer 1 links and all sorts of other stuff not to mention the negotiation of transit peering agreements. If I can see from the IP packets an asynchronous volume of traffic coming from one particular AS then my peering coordinator will have a friendly chat with their counterpart. This has reared its ugly head is several well-known incidents specifically involving CDN. The well-known one is the US Comcast vs Level 3 dispute instantly comes to mind. The difference between pervasive surveillance and traffic management is ONE Octet. Deep Packet Inspection is a fact of life. How you plan or ridding the planet of that petulance is beyond my feeble brain. > First if you take a little stroll over to the IETF STIR problem > statement you will see that fraudulent voice communications is becoming a huge problem > for National Regulators and Law Enforcement. In the US the failure of > Rural Calls to certain areas now requires the US carriers to maintain ever > larger CDR records in order to preserve the integrity of the PSTN itself. I think STIR is a red herring here. Adding STIR doesn't really affect pervasive monitoring since the overwhelming majority of calls already use valid phone numbers so STIR doesn't really add to the ability to pervasively monitor. [RS> ] So long as the majority of traffic is still TDM/SS7 based but we are rapidly moving down a path that will no longer be the case which is why the STIR problem statement is actually very important and very relevant to this discussion. I want to know who is trying to contact me and from where. Now if we had a mechanism that added a useful signature whilst disguising the caller identity, that might be interesting. [RS> ] I still want to track and trace the traffic. I'd want to see what your suggestion looks like but annominity can be used as a shield for something more nefarious. My running assumption here is the "The needs of many ( to be left alone) outweigh the needs of the few." There are actually moral dilemmas here that have to be considered in the larger context. Or one that used a public key previously used to verify a signature to encrypt call setup. And STIR does offer longer term possibilities for both of those. [RS> ] [RS> ] Agreed. So I don't see STIR as being "for" or "against" pervasive monitoring. Same as for any authentication mechanism. But yes, there are privacy issues related to STIR that do need to be considered. [RS> ] Who's privacy? The calling party or the called party. This is my point. Enabling privacy for one may violate the privacy of the other. Now we are really blasting past Layer 8-10 Economic Political and Religious into Layer 11 Philosophy. I'm totally incompetent to make judgments on that Layer. > http://www.fcc.gov/document/fcc-acts-combat-call-completion-problems-r > ural-a > merica > > Consumers are totally outraged by the violations of THEIR PRIVACY... > the right to be left alone... by malicious Robo Callers who ignore the various > Laws about Do Not Call lists etc. E-Mail spam has not gone away by any > account but the need for logs and records to attempt to track criminal > activity is still required. We want to hunt these people down and > shut down their operations. Yes, helping folks block robo-calls is a good. I don't think STIR is meant to actually define how to hunt anyone down though:-) [RS> ] You might think that.. I couldn't possibly comment. But it is a valuable tool to validate trusted traffic from SIP UA to UA. So how do I hunt down robo callers? I have the drones fueled and ready. My point is we still need track and trace for perfectly valid reasons any consumer or enterprise can understand. STIR as you well know is no "silver bullet" it's a tool. One of many. The problem is well understood. I'll post to STIR later further comments on other ideas such as Enhanced CNAM etc. People who really want to communicate to someone they have no prior relationship with should have the tools available to fully identify themselves. That is a good thing. We can do productive work there. I'm also not at all sure that logging all the ham is required to help track spammers. [RS> ] Ask the people who have been defrauded. There are really two sides to this which is my larger point. > The issue is appropriate safeguards on those records and there is > essentially nothing the IETF can do about that. > > It is useful to talk about strengthening key length and understanding > to underlying archectural reasons no one really wants to deploy secure > communications. > > I totally agree with this statement. " I think there are small > technical changes around the edges that can help, but I really see the > solutions for the metadata problem as more political and social than technical. There is a political angle sure. And that's not an IETF concern since the politics seem to be very different in different places. Basically, the same logic as is set out in RFC 2804 applies to that I think. RS> 2804 was a very appropriate statement but there is a underlying thread here that is running counter to those principals. However, I very much disagree that this is *only* political. If whoever is your favorite authority can pervasively monitor everyone then so can others that you don't like so much. And that's true for all values of "authority", at least in principle and quite likely in practice, at least at some scale. And if we can have such bad actors, there's no reason why they need to be nation states at all. Plain old criminals can play this game and will. I believe we do have good technical reasons for wanting to counter pervasive monitoring. Having said all that, yes, I do agree that doing more than making the crypto stuff easier/better is hard. Doesn't mean we shouldn't try though, if we really want to do better on privacy. RS> Then you need to define who's privacy you want to defend. Regards, S. > Concentrating on making encryption really, really easy to use would go > a lot further at this time than messing with deep changes, because > people are not even using what is already available." > > Though I would not have used Tony's precise language on a public mail. I'm > afraid I agree with the underlying sentiment. > > There are more than one joke running around Washington DC about > actually wanting the NSA to keep the CDR records if they would > actually use them to stop robo calls and call spoofing. > > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of [email protected] > Sent: Monday, October 28, 2013 2:30 PM > To: Joe St Sauver > Cc: [email protected]; [email protected]; [email protected] > Subject: Re: [perpass] Traffic analysis > >> Hi, > >> Stephen Farrell <[email protected]>: > >> #Not quite sure, but I think we might get some benefit at the #moment >> from considering how specific fields in real protocols #undermine >> privacy (e.g. as Christian's draft does with the #Received header >> fields in mail messages) even if/when TLS or #other existing security >> mechanisms are properly used. > >> My concern is that many traffic analytic approaches tend to be >> exceedingly robust to "protocol improvements." Protocol tweaks may >> accomplish little when it comes to practically improving privacy if >> the underlying protocol's architecture and operational practice goes >> unchanged. > >> For example, when it comes to email, shouldn't section 6 of >> http://huitema.net/papers/draft-huitema-perpass-analthreat-00.txt >> basically say, "if you want to avoid traffic analytic approaches in >> the case of email, deploy and use Mixmaster anonymous remailers"? >> ( >> https://en.wikipedia.org/wiki/Anonymous_remailers#Untraceable_remaile >> r >> s ) > > And good luck with that, at least on any kind of scale. > > But your underlying point is very well taken: The section on email in > this draft focuses on irrelevancies and fails to take note of the real issues. > > I hate to sound like a broken record, but folks really need to have > some familiarity with present-day email as it is actually deployed > before making these sorts of asssessments. > > Again, present day email usage is increasingly concentrated to a > fairly small number of large ISPs and MSPs. (Small ISPs and enterprise > setups are shifting to using cloud services, and while the Snowden > revelations may have slowed this trend, they haven't stopped it.) > > In regards to traffic analysis, this is in some ways a good thing. If > the connections from user clients to the ISP/MSP servers are secured > at the transport layer - and I have demonstrated that a lot of them > are - then we gain a lot by securing the streams between the large > providers at the transport level. > > But the elephant in the corner is logging. Service providers maintain > very extensive logs of email traffic, if for no other reason than as a > support tool. These logs provide every possible detail needed for traffic analysis. > > Of course one of the earliest Snowden revelations was that the NSA is > collecting these logs from US providers on a massive scale. And > hopefully everyone is aware of Smith v. Maryland, which essentialls > says that metadata is not constitutionally protected. > > But before Eupopeans and others get all smug about this, speaking as > someone who has seen quite a few RFPs for mail systems, the only > substantive difference I see between the US and elsewhere is the US > approaches this in a less organized and systematic way and generally > has fewer auditing and data protection requirements. The data is still > being collected, and most likely shareed. > > And as for practical and deployable measures that can be undertaken to > address this, I'm at something of a loss to suggest anything. Shifting > back to a more decentralized model sounds nice, but seems a bit > outside the purview of a standards process to try and make that happen. > > And even if it a completely decentralized model was practical, in a > peer-to-peer world the metadata that would accrue from watching the > connections themselves would be a fair substitute. > > As for mixed models, look at what happened to Lavabit. > >> And if we *are* talking about that sort of approach, then I think >> inevitably we also need to talk about how we simultaneously manage to >> allow *wanted* private traffic while simultaneously preventing or >> managing *unwanted traffic* (e.g., spam). > > Yep. It's a daunting problem. And it is far from the only one. > >> An awful lot of current anti-spam technology depends upon either >> reputation (which is obviously not present in the case of >> anonymous/non-attributable traffic), or content analysis (which is >> also obviously problematic, at least if we presume use of end-to-end >> encryption (at least until the content is decrypted on the end-user's >> device)). > > You basically have to push the content checks to the client. This has > not proven to be a terrific solution in practice. > >> I also think that if you're serious about email privacy, you really >> can't keep the discussion just at the level of sanitizing headers. >> You need to get into the format of the content that's allowed as >> well. For example, it's well known that non-plain text email content >> (e.g., HTML-formatted email) is potentially a serious threat to >> privacy due to potential use of things like tracking gifs included in >> HTML-formatted email. > > I think we can do a lot to make it harder to snoop on email content, > although ironically what we're likely to be able to accomplish under > the "prism-proof" > rubric is unlikely to much of anything about the data collection the > actual Prism program performs. > > But traffic analysis... unless the fact that those logs are likely to > only be accessible to state entities offers some consolation, I don't > think there's going to be much happiness here. > > Ned > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass > > > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
