Hi Jon, I think SIP vs. WebRTC could be a fine contrast that could shed some light on this, though its maybe a bit early in the latter case. Do you know if anyone's done a comparison between those two from the security point of view (well, between SIP deployment and WebRTC plans is probably the best that could be done I guess).
Some more points below... On 10/08/2013 11:23 PM, Peterson, Jon wrote: > > 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. I don't think I agree there. My suggestion was that we discuss whether or not we may have a new consensus, not a change in how we determine consenesus. In the event it appeared there was a new consensus on this list, that'd have to be tested more broadly before it'd impact on anything. > > Just to take an example I've followed a bit, SIP is relatively successful > IETF protocol. It has some notable security issues. Nice understatement;-) IMO that's quite relevant too. SIP could be at the same time a nice example of a successful insecure protocol and of a very unsuccessful security protocol. That's a bit pejorative but I guess you know what I mean. > 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. Well, that assumes that the SIP-proxy driven aproach that's current was always going to be necessary. Its clearly necessary now though so the middlebox aspect is a real issue here (and for HTTP). > 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. Yeah, that's a PITA. References to RFC 4744 and RFC 3118 are my least favourite things to see when reviewing drafts. Both indicate that people are trying to pretend to do security, and that they're even doing that badly;-) That does I think make for an argument for more than MTI - if it really has to be used for the protocol to operate, then its far more likely to work and get used and have been properly engineered. > 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. Fully agree. And that's what (I think) we're doing here. Seeing what really is new and what folks want to do about it. But maybe I'm mixed up, I've no idea what top-down thing you mean to be honest. > 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. That's one possible outcome - to say that more-than-MTI is a valid choice that can be made on a protocol by protocol basis. And while that's not described in BCP61, the WebRTC case shows its doable aleady I guess that's an argument for the status quo. (Which is fine, the point for now is to see what arguments there are that might convince folks here that the status quo is or is not ok.) S. > > Jon Peterson > Neustar, Inc. > > On 10/8/13 2:14 PM, "Stephen Farrell" <stephen.farr...@cs.tcd.ie> 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 >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass > > > _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass
