+1 I do run into cases where people are already confused on MTI and think it means MTU on IETF documents. I've heard it used as a reason not to use a protocol (too complex for users to implement). 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.
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. 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
