For PSTN replacement deployments in effectively private networks, the case for transport-level security is unconvincing, sure.
To Steve Kent's earlier point, documents that explain why strong security is a best practice for particular environments would do better than a blanket assertion that SIP must always use TLS. If the latter statement were built into RFC3261, it would serve little purpose other than rendering many implementations non-compliant with RFC3261. A BCP could however provide the necessary motivation for using TLS in the situations where it will actually help, and the recent revelations make that case rather eloquently. Jon Peterson Neustar, Inc. On 10/9/13 1:55 PM, "Richard Shockey" <rich...@shockey.us> 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. > >-----Original Message----- >From: perpass-boun...@ietf.org [mailto:perpass-boun...@ietf.org] 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" <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 > _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass
