On 10/09/2013 09:55 PM, Richard Shockey wrote: > Well from a SIP perspective we have always had mandatory to implement TLS in > any number of specifications but in practice no one uses it. No one. No one > cares.
BTW - thanks Rich - I think saying what really happens is very helpful. Pretend security is IMO worse and defo much more of a PITA. S. > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Stephen Farrell > Sent: Tuesday, October 08, 2013 7:13 PM > To: Peterson, Jon; perpass > Subject: Re: [perpass] mandatory-to-implement vs. more? > > > 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" <[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
