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. > 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. > 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. > 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;-) 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. 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
