Hi Stephen, I'll respond in line to clarify my initial email.
Thanks, Kathleen -----Original Message----- From: Stephen Farrell [mailto:[email protected]] Sent: Tuesday, October 08, 2013 9:34 PM To: Moriarty, Kathleen; Peterson, Jon; perpass Subject: Re: [perpass] mandatory-to-implement vs. more? On 10/09/2013 02:00 AM, Moriarty, Kathleen wrote: > +1 > > I do run into cases where people are already confused on MTI and think > it means MTU on IETF documents. True, but a different discussion. KM> Yes, but if these are more clearly defined, it could help with the problem you are trying to solve. Non-IETF people (developers and those who use/setup protocols), from my experience, have trouble understanding what MTI means and the scope of it. Having MTU defined and differentiated clearly could help this group and assist with the problem you are trying to solve. > I've heard it used as a reason > not to use a protocol (too complex for users to implement). Users don't implement as I'd use those terms, so I'm not sure I get what you mean. KM> By implement, I mean setup as opposed to develop code, which is where you mean implement. Using a protocol may not be the same person as the one who set up a connection. > In one > case, mutual authentication on a peer-to-peer exchange of sensitive > information was argued as too much and a non-IETF standard is getting > some traction as a result (so is the IETF standard by those who > actually evaluated). I do think it is important to have key features > as MTI, then making it very clear what is MTU and what is by policy > may be fine. Right, that's the status quo. AFAIK it leads to pretty much all Diameter exchanges being done in clear. Now that we have a new threat model, is that still considered ok? I think that is really worth questioning. As Jon said - WebRTC can do it, the initial SPDY proposals did it, so there's no reason why most protocols can't do similarly that I can see - what's different other than intent? I think there are interesting questions there to explore. KM> In the case of MILE, there was a protocol written outside of the IETF called TAXII, that is very similar to RID. Some of the initial reasons that the developers of TAXII used to promote it over RID was that their protocol didn't require mutual authentication, it also does not require TLS and can be sent in the clear if security is too much trouble to configure. This explanation came my way by a few people. RID also specifies the ability to provide object level security (XML encryption and digital signatures), this was also seen as too much by the TAXII team even though RID has it as MTI, not MTU. They are promoting the use of many options, which in addition to security problems, will make interoperability difficult. There is a lot more to this discussion, but I am limiting it to security features and the result - a protocol that did not have the benefit of IETF review and security options is in use for some instead. Some are using RID, but how this will play out is still TBD as some prefer the security features and I think it is necessary to have them in a protocol that transports sensitive data. There are other protocols that may be better for some use cases, but that's another discussion as well. > Many of us will have to worry about customer requirements that will > cover a broad range from different governments (these could evolve), > those worried about monitoring, and those that don't set forth any > requirements. That's a little ambiguous: I'm not sure if you're saying you have customers who are concerned that pervasive monitoring might be happening, or customers who are governemtns that worry that they can't monitor enough;-) KM> Both - some governments do not want to sue protocols they suspect could be subject to monitoring. Then we still have to worry about FIPS compliance requirements for the US government. For the last group who are in the dark, it would be nice to have them using secure protocols without them having to know about it. But either way, the new reality seems to be that we have a demonstration that a set of governments want to pervasively monitor everything. And I'm sure there're others also trying that. And now there'll be a whole new set trying to join that club. So even the governments that want to monitor everyone else will I think soon realise that they're better off it they themselves/their citizens are less easy to monitor. I'm very simple: this is an attack on the network. If we treat it that way, and do that well, we might all win. KM> The current reality for vendors is that we have to have options. There might be a monitoring prevention set of options or a profile and a profile to meet specific requirements for regulations (industry or government). In an ideal world, we could just prevent monitoring everywhere (to the best of our knowledge) S. > > Thanks, Kathleen > > -----Original Message----- From: [email protected] > [mailto:[email protected]] On Behalf Of Peterson, Jon Sent: > Tuesday, October 08, 2013 6:24 PM To: Stephen Farrell; perpass > Subject: Re: [perpass] mandatory-to-implement vs. more? > > > Moving the bar from MTI to mandatory-to-use (can we overload the > acronym MTU?) goes beyond just questions of policy, and into the > questions of how we build consensus and what the shapes the output of > our engineering process. > > Just to take an example I've followed a bit, SIP is relatively > successful IETF protocol. It has some notable security issues. We > could have designed SIP in a way that reduced the ability of middlemen > to work themselves into the path of SIP messages, and thus reduced the > potential for eavesdropping on the sessions that SIP creates - and its > usefulness as a tool of surveillance. > > Had we made some of those design decisions, however, it's unclear to > me that SIP would have been such a successful protocol. But we > wouldn't have made those decisions anyway, because the relevant > documents would never have garnered consensus in the working groups. > Our consensus process reflects the aggregate of the requirements of > our participants, which come from many sources: employers, or > regulators, or academic interests, or personal consciences. > > If we had designed SIP to be a protocol that didn't meet those > requirements, of course it wouldn't see much deployment. Extensions to > SIP that have leaned in this direction have had little impact on the > protocol's use. That is the purpose of a consensus process, to reflect > the likely implementation and deployment community. Like it or not, > the participants in our consensus process want protocols like SIP to > be modifiable by intermediaries for numerous reasons - and once we > open that door, we have to understand it will be open for all comers. > > We could change our process so that it overrides consensus on some of > these crucial points. I think it would be safe to say that we already > do so, in a limited way, as a results of various forms of cross-area > review. As popular protocol go through our process, we levy > requirements that are winked at by document authors and ignored by > implementers. There are however lines here we could cross that would > result in nothing but the severing of IETF work from the reality of > deployment. That would not serve our mission of making the Internet > better. > > We undoubtedly need to make changes to reflect our new understanding > of the threats facing the Internet. I think this needs to come from > the bottom up, though, not from the top down. I am heartened that our > consensus process has elevated core security mechanisms to > mandatory-to-use level for some recent work, like in RTCWeb. We need > to shed the brightest light we can on these issues, educate the > community about the new risks and the practical countermeasures, and > then execute our consensus process as we always have. In some cases, > mandatory-to-use will be the right choice. In others, it won't. > > Jon Peterson Neustar, Inc. > > On 10/8/13 2:14 PM, "Stephen Farrell" <[email protected]> > wrote: > >> >> Hi, >> >> Steve's mail argues for the current IETF position that >> mandatory-to-implement (MTI) is the correct target IETF >> specifications. >> >> Some folks (me included to be honest) wonder if the current situation >> argues for raising the bar there somewhat on the basis that MTI >> security features are frequently turned off or not sufficiently well >> tested to be usable. (Pick your favourite example, mine are usually >> rfc4744 or Diameter being run in clear.) And an upshot from that is >> that that helps those who want to pervasively monitor everything. >> >> Others argue that that'd be the IETF straying into the space of >> policy - all we should do is define how to use strong security >> features and make sure the code is there so they can be turned on and >> the rest is policy. >> >> I'm sure there are loads more arguments, and I do think it'd be >> useful to see those discussed here. >> >> Thanks, Stephen. >> >> PS: Our -00 privacy BCP doesn't go beyond MTI for now, but were there >> consensus for that, I think it'd be good if we could go further. >> >> >> _______________________________________________ perpass mailing list >> [email protected] https://www.ietf.org/mailman/listinfo/perpass > > _______________________________________________ perpass mailing list > [email protected] https://www.ietf.org/mailman/listinfo/perpass > > _______________________________________________ perpass mailing list > [email protected] https://www.ietf.org/mailman/listinfo/perpass > > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
