Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On Sun, Sep 22, 2013 at 6:59 PM, Paul Wouters p...@cypherpunks.ca wrote: snip Note that decentralising makes you less anonymous. If everyone runs their own jabber service with TLS and OTR, you are less anonymous than today. So decentralising is not a solution on its own for meta-data tracking. When I'm talking about decentralizing of internet I'm talking more about the traffic flow. We are sort of already on the way there with CDN moving much used content close to the user, Microsoft updates are done this way afaik, youtube, think gmail are distributed to. I think this is mostly done due to cost and user-experience reasons. We should go further, end-users should be able to communicate with each other in a direct fasion as possible, preferable not going through central chokepoints at all. Why send a videosession between two neighbours 3000km just because they have different ISP that don't want to exchange local traffic local even they are in the same physical room with their equipment? In a rack next to each other? That is how internet in Norway are mostly done today with a very few exceptions. That means more interconnect between ISPs, more IX'es, and alot more distributed routing... ... but not sure if this is really in the IETF domain at all, is it a technical, economical or political issues that preventing this today? -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On 21 September 2013 06:02, SM s...@resistor.net wrote: Hi Brian, At 21:54 19-09-2013, Brian E Carpenter wrote: I got my arm slightly twisted to produce the attached: a simple concatenation of some of the actionable suggestions made in the discussion of PRISM and Bruce Schneier's call for action. Thanks for writing the draft. For the sake of disclosure [1], I know some of the XSF members. draft-carpenter-prismatic-reflections-00 mentions that: Clearly, we have a lot of specification work ongoing in different areas that helps to mitigate various security vulnerabilities. This ranges from recent work on XMPP end-to-end security I recently read an article about XMPP ( https://www.eff.org/deeplinks/2013/05/google-abandons-open-standards-instant-messaging ). From the article: removes the option to disable the archiving of all chat communications What it removes is default disabling. It is still possible to disable all archiving, you just have to do it for each chat.
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On 22/09/2013, at 1:08 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Mark Nottingham wrote: Then, protocols not have any authoritative specification and should never be standardized and there should be no central authority to manage different versions of the protocols. From a PRISM viewpoint, the cost of parsing different formats, understanding different wire protocols, etc. is trivial. That is a reasoning to deny the point of you: : I draw the opposite conclusion, actually. With good standards, ; we can encourage a larger number of services to exist, : raising the cost of monitoring them all. So, denying the point, you agree with me. I'm really not sure what you're getting at here, but I suspect we're not going to convince each other. That's OK with me. Regards, -- Mark Nottingham http://www.mnot.net/
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
From: Dave Crocker d...@dcrocker.net Except that essentially all services other than email have gained popularity in centralized form, including IM. So there appear to be some important and difficult operational and usability barriers, standing in the way of more truly distributed applications. Yes. $$$. Nobody makes much/any money off email because it is so de-centralized. People who build wonderful new applications build them in a centralized way so that they can control them. And they want to control them so that they can monetize them. Noel
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
--On Sunday, 22 September, 2013 07:02 -0400 Noel Chiappa j...@mercury.lcs.mit.edu wrote: ... Yes. $$$. Nobody makes much/any money off email because it is so de-centralized. People who build wonderful new applications build them in a centralized way so that they can control them. And they want to control them so that they can monetize them. That is even true of the large email providers who are happy to provide free email in return for being able leverage their other products and/or sell the users and user base to advertisers. And people, including, I've noticed, a lot of IETF participants, go along. Email is, in practice, a lot more centralized than it was ten or 15 years ago and is at risk of getting more, not only as more users migrate but as those providers decide it is easier to trust only each other. With DKIM, increasing use of blacklists, and other things, the latter may be better (from a distributed environment standpoint) than it was a half-dozen years ago, but I'm concerned that the pattern may be cyclic with new domains providing new challenges and incentives for trust those you know already models. john
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On Sat, 21 Sep 2013, Dave Crocker wrote: 2) Encourage distributed services over centralized services. For example, social networking services today are heavily centralized. +1 Except that essentially all services other than email have gained popularity in centralized form, including IM. Note that decentralising makes you less anonymous. If everyone runs their own jabber service with TLS and OTR, you are less anonymous than today. So decentralising is not a solution on its own for meta-data tracking. So there appear to be some important and difficult operational and usability barriers, standing in the way of more truly distributed applications. Because people still think of data centers are the CPUs running the internet, when they should be thinking of loading up everyone's phones with these services. These devices are more powerful that our 4U servers of 10 years ago. Paul
RE: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
Yes. $$$. Nobody makes much/any money off email because it is so de-centralized. People who build wonderful new applications build them in a centralized way so that they can control them. And they want to control them so that they can monetize them. That is even true of the large email providers who are happy to provide free email in return for being able leverage their other products and/or sell the users and user base to advertisers. It is very true that innovation can only be sustained with a revenue stream. But we could argue that several services have now become pretty much standardized, with very little additional innovation going on. Those services are prime candidates for an open and distributed implementation. I mean, could a WG design a service that provides a stream of personal updates and a store of pictures and is only accessible to my friends? And could providers make some business by selling personal servers, or maybe personal virtual servers? Maybe I am a dreamer, but hey, nothing ever happens if you don't dream of it! -- Christian Huitema
RE: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
I like what Christian said. Also, perhaps we should figure out how to unbundle services and monetize what we can. On Sep 22, 2013 1:38 PM, Christian Huitema huit...@microsoft.com wrote: Yes. $$$. Nobody makes much/any money off email because it is so de-centralized. People who build wonderful new applications build them in a centralized way so that they can control them. And they want to control them so that they can monetize them. That is even true of the large email providers who are happy to provide free email in return for being able leverage their other products and/or sell the users and user base to advertisers. It is very true that innovation can only be sustained with a revenue stream. But we could argue that several services have now become pretty much standardized, with very little additional innovation going on. Those services are prime candidates for an open and distributed implementation. I mean, could a WG design a service that provides a stream of personal updates and a store of pictures and is only accessible to my friends? And could providers make some business by selling personal servers, or maybe personal virtual servers? Maybe I am a dreamer, but hey, nothing ever happens if you don't dream of it! -- Christian Huitema
RE: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
--On Sunday, 22 September, 2013 17:37 + Christian Huitema huit...@microsoft.com wrote: ... It is very true that innovation can only be sustained with a revenue stream. But we could argue that several services have now become pretty much standardized, with very little additional innovation going on. Those services are prime candidates for an open and distributed implementation. I mean, could a WG design a service that provides a stream of personal updates and a store of pictures and is only accessible to my friends? And could providers make some business by selling personal servers, or maybe personal virtual servers? Maybe I am a dreamer, but hey, nothing ever happens if you don't dream of it! I agree completely. However, one could equally well say that operations can only be sustained with a revenue stream and trust models among parties that don't already have first-hand relationships can get a tad complicated. Setting up a distributed email environment that supports secure communication among a small circle of friends (especially technically-competent ones) is pretty easy, even easier than the service you posit above. Things become difficult and start to encourage centralized behavior when, e.g., (i) the community allow basic Internet service providers to either prohibit running servers or make it unreasonably expensive, (ii) one wants the communications to be persistent enough that storage, backup, and operations becomes a big deal, and/or (iii) one wants on-net or in-band ways to introduce new parties to the group when there are Bad Guys out there (which more or less reinvents the PGP problem). Architecturally, one can make a case that the Internet is much better designed for peer to peer arrangements than for client to Big Centrally-Controlled Server ones, even though trends in recent years run in the latter direction (and I still have trouble telling the fundamental structural differences between a centralized operation with extensive web services and users on dumb machines on the one hand and the central computer services operations of my youth on the other). So, a good idea and one that should be, IMO, pursued. But there are a lot of interesting and complex non-technical barriers. best, john
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On 9/22/13 11:35 AM, Scott Brim wrote: I like what Christian said. Also, perhaps we should figure out how to unbundle services and monetize what we can. On Sep 22, 2013 1:38 PM, Christian Huitema huit...@microsoft.com mailto:huit...@microsoft.com wrote: Yes. $$$. Nobody makes much/any money off email because it is so de-centralized. People who build wonderful new applications build them in a centralized way so that they can control them. And they want to control them so that they can monetize them. That is even true of the large email providers who are happy to provide free email in return for being able leverage their other products and/or sell the users and user base to advertisers. It is very true that innovation can only be sustained with a revenue stream. But we could argue that several services have now become pretty much standardized, with very little additional innovation going on. There are it most be said enormous economies of scale that are hard to ignore. Those services are prime candidates for an open and distributed implementation. I mean, could a WG design a service that provides a stream of personal updates and a store of pictures and is only accessible to my friends? And could providers make some business by selling personal servers, or maybe personal virtual servers? Maybe I am a dreamer, but hey, nothing ever happens if you don't dream of it! -- Christian Huitema
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
--On Sunday, 22 September, 2013 12:59 -0400 Paul Wouters p...@cypherpunks.ca wrote: Except that essentially all services other than email have gained popularity in centralized form, including IM. Note that decentralising makes you less anonymous. If everyone runs their own jabber service with TLS and OTR, you are less anonymous than today. So decentralising is not a solution on its own for meta-data tracking. Perhaps more generally, there may be tradeoffs between content privacy and tracking who is talking with whom. For the former, decentralization is valuable because efforts to compromise the endpoints and messages stored on them without leaving tracks is harder. In particular, if I run some node in a highly distributed environment, a court order demanding content or logs (or a call asking that I cooperate) in disclosing data, keys, etc., would be very difficult to keep secret from me (even if it prevented me from telling my friends/ peers). And a lot more of those court orders or note would be required than in a centralized environment. On the other hand, as you point out, traffic monitoring is lots easier if IP addresses identify people or even small clusters of people. The other interesting aspect of the problem is that, if we want to get serious about distributing applications down to very small scale, part of that effort is, I believe necessarily, getting serious about IPv6 and avoidance of highly centralized conversion and address translation functions. john
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
Jari, It is important to understand the limitations of technology in this discussion. We can improve communications security, and in some cases reduce the amount information communicated. But we cannot help a situation where you are communicating with a party that you cannot entirely trust with technology alone. That does not mean we should not do anything. Right. My primary concern was that the most effective responses for these issues are rather different (technical controls versus regulatory controls). I understand that PRISM is being used as a convenient label to describe a multitude of sins; but, this will only be obvious to those that understand the issues. Given the level of interest in this topic (e.g., the daily media circus), we should be honest in what we can practically achieve at a protocol level. I would also like to focus this topic on the general implications for Internet technology, rather than any specific alleged activities. The discussion has heightened our need to consider the large-scale monitoring threat. It is important to understand that the overall situation is probably bigger and more complex than we see today, and it will also evolve as time goes by. Hence: if we build something, lets build for the general case, reducing ability of outsiders to get into communications, reduce amount of sensitive information transported, make privacy attacks more costly, etc. That's all good stuff. That said, personally I would characterise this as a problem of Internet governance, and so I rather hope that ISOC have ambitions beyond releasing a press statement. Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On Fri, Sep 20, 2013 at 6:54 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I got my arm slightly twisted to produce the attached: a simple concatenation of some of the actionable suggestions made in the discussion of PRISM and Bruce Schneier's call for action. There are one thing I don't see mention in your draft, the discussion that moved from ietf@ and over into lisp@ about encryption by default wherever it's possible. It's one concrete action this NSA/Snowden/Bruce thing has started. -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On 09/21/2013 02:42 PM, Roger Jørgensen wrote: On Fri, Sep 20, 2013 at 6:54 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I got my arm slightly twisted to produce the attached: a simple concatenation of some of the actionable suggestions made in the discussion of PRISM and Bruce Schneier's call for action. There are one thing I don't see mention in your draft, the discussion that moved from ietf@ and over into lisp@ about encryption by default wherever it's possible. It's one concrete action this NSA/Snowden/Bruce thing has started. FWIW, I'm also maintaining a list of concrete proposals and relevant I-Ds that I've seen. [1] I've not noticed an I-D on the LISP idea though but let me know if there's one I missed. S. [1] http://down.dsg.cs.tcd.ie/misc/perpass.txt
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On Sat, Sep 21, 2013 at 7:24 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 09/21/2013 02:42 PM, Roger Jørgensen wrote: snip There are one thing I don't see mention in your draft, the discussion that moved from ietf@ and over into lisp@ about encryption by default wherever it's possible. It's one concrete action this NSA/Snowden/Bruce thing has started. FWIW, I'm also maintaining a list of concrete proposals and relevant I-Ds that I've seen. [1] I've not noticed an I-D on the LISP idea though but let me know if there's one I missed. are no new I-Ds yet no.. :( -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On Sat, 21 Sep 2013, Stephen Farrell wrote: On 09/21/2013 02:42 PM, Roger Jørgensen wrote: On Fri, Sep 20, 2013 at 6:54 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I got my arm slightly twisted to produce the attached: a simple concatenation of some of the actionable suggestions made in the discussion of PRISM and Bruce Schneier's call for action. There are one thing I don't see mention in your draft, the discussion that moved from ietf@ and over into lisp@ about encryption by default wherever it's possible. It's one concrete action this NSA/Snowden/Bruce thing has started. FWIW, I'm also maintaining a list of concrete proposals and relevant I-Ds that I've seen. [1] I've not noticed an I-D on the LISP idea though but let me know if there's one I missed. It's a draft from 1998: http://tools.ietf.org/html/draft-ietf-ipsec-internet-key-00 I'm considering implementing something like that for the next version of libreswan. But if we resurrect this draft, it needs work to get modernized or be started as a complete rewrite from scratch. For exaple, we'd have to ensure that these connections remain sandboxed to the machine, and that any IP assignments are not leaking outside the machine (in the light of NAT based inner IPs, etc) Paul
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
Mark Nottingham wrote: Then, protocols not have any authoritative specification and should never be standardized and there should be no central authority to manage different versions of the protocols. From a PRISM viewpoint, the cost of parsing different formats, understanding different wire protocols, etc. is trivial. That is a reasoning to deny the point of you: : I draw the opposite conclusion, actually. With good standards, ; we can encourage a larger number of services to exist, : raising the cost of monitoring them all. So, denying the point, you agree with me. Note that the number of services != the number of service providers. The real cost is negotiating with / bullying each provider into giving access. Especially if it's not hosted or doing business in a country you control. If only the number of cloud providers were large. However, as there is some scale merit, there is a tendency that the number of the providers will be small and all of the providers naturally have considerable amount of hardware at the central part of the Internet, that is, in US, which means the providers are subject to USG control. And, USG is not the only government we should be protected from. I should be able to choose my own data sync server, whether it's one I run, or one run by my paranoid friend, or by a local company, or a US company that's in bed with the NSA. The only secure way is to run your own. That's a very simplistic definition of secure. See above how simplistic your view is against so complex nature of PRISM etc, against which, only the simplest protection is effective. Masataka Ohta
RE: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Thursday, September 19, 2013 9:55 PM To: IETF discussion list Subject: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt] I got my arm slightly twisted to produce the attached: a simple concatenation of some of the actionable suggestions made in the discussion of PRISM and Bruce Schneier's call for action. Brian Original Message Subject: I-D Action: draft-carpenter-prismatic-reflections-00.txt Date: Thu, 19 Sep 2013 21:47:18 -0700 From: internet-dra...@ietf.org Reply-To: internet-dra...@ietf.org To: i-d-annou...@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Prismatic Reflections Author(s) : Brian Carpenter Filename: draft-carpenter-prismatic-reflections-00.txt Pages : 9 Date: 2013-09-19 Abstract: Recent public disclosure of allegedly pervasive surveillance of Internet traffic has led to calls for action by the IETF. This draft exists solely to collect together a number of possible actions that were mentioned in a vigorous discussion on the IETF mailing list. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-prismatic-reflections There's also a htmlized version available at: http://tools.ietf.org/html/draft-carpenter-prismatic-reflections-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
RE: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
I got my arm slightly twisted to produce the attached: a simple concatenation of some of the actionable suggestions made in the discussion of PRISM and Bruce Schneier's call for action. Brian, This is a useful summary, but I would like to see a few additions: 1) Encourage protocol designs that rely on peer-to-peer transmission, rather than intermediate relays, because relays are natural targets for interception services. 2) Encourage distributed services over centralized services. For example, social networking services today are heavily centralized. A distributed architecture would allow distribution of data at multiple location, managed by different commercial companies and covered by different legal authorities. 3) Require security sections of new RFC to include mass surveillance in their threat model and consider mitigations. -- Christian Huitema
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On 9/21/2013 9:40 PM, Christian Huitema wrote: 1) Encourage protocol designs that rely on peer-to-peer transmission, rather than intermediate relays, because relays are natural targets for interception services. Unless you are interacting on the same local net segment, when is Internet communications not through a relay? Router, MTA, Web cache, whatever. Given that, ultimately, there are always routers, what is the realistic improvement you are suggesting? 2) Encourage distributed services over centralized services. For example, social networking services today are heavily centralized. +1 Except that essentially all services other than email have gained popularity in centralized form, including IM. So there appear to be some important and difficult operational and usability barriers, standing in the way of more truly distributed applications. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On 20 Sep 2013, at 05:54, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I got my arm slightly twisted to produce the attached: Thanks for getting that done S
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
I confess that I am confused by much of this discussion. As I understand it, PRISM is not a signals intelligence activity; it only addresses that data at rest within those organisations who have partnered with the NSA. As such, improving protocol security will achieve nothing against PRISM; it is a socio-political issue that is outside of the scope of a technical standards organisation. As such the only practical way for a typical user to protect themselves against PRISM is to switch to other providers based in jurisdictions that provide the appropriate protections, or agitate to change the applicable laws within their own jurisdiction, where appropriate. This is not, of course, an argument not to improve the security of our protocols for other reasons, but let's please motivate this work correctly. It will yield a greater probability of success. Josh. On 20/09/2013 05:54, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I got my arm slightly twisted to produce the attached: a simple concatenation of some of the actionable suggestions made in the discussion of PRISM and Bruce Schneier's call for action. Brian Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
Josh Howlett wrote: I confess that I am confused by much of this discussion. Several people in IETF is under control of NSA, maybe. As I understand it, PRISM is not a signals intelligence activity; it only addresses that data at rest within those organisations who have partnered with the NSA. As such, improving protocol security will achieve nothing against PRISM; it is a socio-political issue that is outside of the scope of a technical standards organisation. Right. As such the only practical way for a typical user to protect themselves against PRISM is to switch to other providers based in jurisdictions that provide the appropriate protections, or agitate to change the applicable laws within their own jurisdiction, where appropriate. Not necessarily. The proper protection is to avoid cloud services and have our own end systems fully under control of ourselves. Toward the goal, IETF should shutdown all the cloud related WGs and never develop any protocol to promote cloud service. This is not, of course, an argument not to improve the security of our protocols for other reasons, but let's please motivate this work correctly. It will yield a greater probability of success. Using DH could protect us, until USG start deploying active attack. So, it is important to develop technologies to detect attacks against DH. Masataka Ohta
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On 09/20/2013 10:59 AM, Josh Howlett wrote: I confess that I am confused by much of this discussion. As I understand it, PRISM is not a signals intelligence activity; it only addresses that data at rest within those organisations who have partnered with the NSA. As such, improving protocol security will achieve nothing against PRISM; it is a socio-political issue that is outside of the scope of a technical standards organisation. As such the only practical way for a typical user to protect themselves against PRISM is to switch to other providers based in jurisdictions that provide the appropriate protections, or agitate to change the applicable laws within their own jurisdiction, where appropriate. This is not, of course, an argument not to improve the security of our protocols for other reasons, but let's please motivate this work correctly. It will yield a greater probability of success. Brian I think nicely summarised the discussion that happened. The way I think of it is that PRISM is just one label that's being used to reflect the whole set of recent disclosures and ensuing discussions. Phill has also talked about PRISMproofing which seemed to resonate with some people. I've started using the term Snowdonia for all this stuff, but we really shouldn't get hung up on the labels since that's all they are. As you say, what we need to do in the IETF is figure out what we should be doing about it all, and then go do that. That is a work in progress and will undoubtedly be for a while to come, but folks are working at it, which is good. S. Josh. On 20/09/2013 05:54, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I got my arm slightly twisted to produce the attached: a simple concatenation of some of the actionable suggestions made in the discussion of PRISM and Bruce Schneier's call for action. Brian Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
Josh, Stephen, It is important to understand the limitations of technology in this discussion. We can improve communications security, and in some cases reduce the amount information communicated. But we cannot help a situation where you are communicating with a party that you cannot entirely trust with technology alone. That does not mean we should not do anything. I would also like to focus this topic on the general implications for Internet technology, rather than any specific alleged activities. The discussion has heightened our need to consider the large-scale monitoring threat. It is important to understand that the overall situation is probably bigger and more complex than we see today, and it will also evolve as time goes by. Hence: if we build something, lets build for the general case, reducing ability of outsiders to get into communications, reduce amount of sensitive information transported, make privacy attacks more costly, etc. Jari
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
(2013/09/20 21:15), Jari Arkko wrote: Josh, Stephen, It is important to understand the limitations of technology in this discussion. We can improve communications security, and in some cases reduce the amount information communicated. But we cannot help a situation where you are communicating with a party that you cannot entirely trust with technology alone. We can discourage people communicating with a party that are under full control of USG, which is why using cloud services should be discouraged, which is a technical issue. Masataka Ohta
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On Fri, Sep 20, 2013 at 8:15 AM, Jari Arkko jari.ar...@piuha.net wrote: It is important to understand the limitations of technology in this discussion. We can improve communications security, and in some cases reduce the amount information communicated. But we cannot help a situation where you are communicating with a party that you cannot entirely trust with technology alone. That does not mean we should not do anything. I would also like to focus this topic on the general implications for Internet technology, rather than any specific alleged activities. The discussion has heightened our need to consider the large-scale monitoring threat. It is important to understand that the overall situation is probably bigger and more complex than we see today, and it will also evolve as time goes by. Hence: if we build something, lets build for the general case, reducing ability of outsiders to get into communications, reduce amount of sensitive information transported, make privacy attacks more costly, etc. Yes. I'm really pleased that privacy in communications has come to the fore and that we're trying to design it in, but there is much more to it than the issue of general surveillance. Scott
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
Hi Masataka, On 20.09.2013 16:06, Masataka Ohta wrote: (2013/09/20 21:15), Jari Arkko wrote: Josh, Stephen, It is important to understand the limitations of technology in this discussion. We can improve communications security, and in some cases reduce the amount information communicated. But we cannot help a situation where you are communicating with a party that you cannot entirely trust with technology alone. We can discourage people communicating with a party that are under full control of USG, which is why using cloud services should be discouraged, which is a technical issue. An open standardization process means that everyone can participate, including people who work for the government (directly or indirectly). Whether you like what someone is putting forward is a completely different story but I hope you would at least look at the content before judging it. So, I believe this attitude against people and companies who may have had, or still have relationships with governments is counterproductive. On your argument against cloud standardization in the IETF I have two remarks, namely : * Cloud services (with whatever definition you use) indeed presents challenges for privacy and security. * There is no standardization in the IETF on something like the cloud. On the other hand I have to say that almost every protocol we standardize in the IETF could be used in a cloud service. For example, many cloud services use HTTP. Should we stop working on HTTP? Ciao Hannes Masataka Ohta
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
Hannes Tschofenig wrote: We can discourage people communicating with a party that are under full control of USG, which is why using cloud services should be discouraged, which is a technical issue. An open standardization process means that everyone can participate, including people who work for the government (directly or indirectly). As long as a standard being developed is within the scope of the process, yes. Whether you like what someone is putting forward is a completely different story but I hope you would at least look at the content before judging it. Developing protocols to promote antisocial activities is worse than developing Ethernet/Wifi protocol in IETF. So, I believe this attitude against people and companies who may have had, or still have relationships with governments is counterproductive. Protection from governments is not very productive, indeed, which does not mean we shouldn't do it. On your argument against cloud standardization in the IETF I have two remarks, namely : * Cloud services (with whatever definition you use) indeed presents challenges for privacy and security. * There is no standardization in the IETF on something like the cloud. On the other hand I have to say that almost every protocol we standardize in the IETF could be used in a cloud service. For example, many cloud services use HTTP. Should we stop working on HTTP? For example, the following RFC: 6208Cloud Data Management Interface (CDMI) Media Types K. Sankar, A. Jones [ April 2011 ] (TXT = 23187) (Status: INFORMATIONAL) (Stream: IETF, WG: NON WORKING GROUP) is a product of IETF to promote cloud service. Masataka Ohta
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On 20/09/2013, at 9:16 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: As such the only practical way for a typical user to protect themselves against PRISM is to switch to other providers based in jurisdictions that provide the appropriate protections, or agitate to change the applicable laws within their own jurisdiction, where appropriate. Not necessarily. The proper protection is to avoid cloud services and have our own end systems fully under control of ourselves. Toward the goal, IETF should shutdown all the cloud related WGs and never develop any protocol to promote cloud service. I draw the opposite conclusion, actually. With good standards, we can encourage a larger number of services to exist, raising the cost of monitoring them all. The problem is that the data is all concentrated in a small number of places, making it too easy to collect. To wit, right now Dropbox has a stranglehold on the personal data sync market; if I try to run my own server, or use an alternative service, I lose a significant number of benefits. I should be able to choose my own data sync server, whether it's one I run, or one run by my paranoid friend, or by a local company, or a US company that's in bed with the NSA. Good standards allow that to happen. Sticking our collective heads in the sand and saying cloud isn't happening isn't going to change anything. Cheers, -- Mark Nottingham http://www.mnot.net/
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
Mark Nottingham wrote: Not necessarily. The proper protection is to avoid cloud services and have our own end systems fully under control of ourselves. Toward the goal, IETF should shutdown all the cloud related WGs and never develop any protocol to promote cloud service. I draw the opposite conclusion, actually. With good standards, we can encourage a larger number of services to exist, raising the cost of monitoring them all. Cost for monitoring should be large? Then, protocols not have any authoritative specification and should never be standardized and there should be no central authority to manage different versions of the protocols. I should be able to choose my own data sync server, whether it's one I run, or one run by my paranoid friend, or by a local company, or a US company that's in bed with the NSA. The only secure way is to run your own. Good standards allow that to happen. I'm afraid you want to increase monitoring cost. Masataka Ohta
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
Hi Brian, At 21:54 19-09-2013, Brian E Carpenter wrote: I got my arm slightly twisted to produce the attached: a simple concatenation of some of the actionable suggestions made in the discussion of PRISM and Bruce Schneier's call for action. Thanks for writing the draft. For the sake of disclosure [1], I know some of the XSF members. draft-carpenter-prismatic-reflections-00 mentions that: Clearly, we have a lot of specification work ongoing in different areas that helps to mitigate various security vulnerabilities. This ranges from recent work on XMPP end-to-end security I recently read an article about XMPP ( https://www.eff.org/deeplinks/2013/05/google-abandons-open-standards-instant-messaging ). From the article: removes the option to disable the archiving of all chat communications Regards, -sm 1. I welcome any questions about conflict of interest.
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On 21/09/2013, at 11:33 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Cost for monitoring should be large? Then, protocols not have any authoritative specification and should never be standardized and there should be no central authority to manage different versions of the protocols. From a PRISM viewpoint, the cost of parsing different formats, understanding different wire protocols, etc. is trivial. The real cost is negotiating with / bullying each provider into giving access. Especially if it's not hosted or doing business in a country you control. I should be able to choose my own data sync server, whether it's one I run, or one run by my paranoid friend, or by a local company, or a US company that's in bed with the NSA. The only secure way is to run your own. That's a very simplistic definition of secure. -- Mark Nottingham http://www.mnot.net/
