I'm sure we could put together some instructive parables on the contrast between SIP and WebRTC, but that would largely be a discussion about the different market dynamics of browsers and the web versus the more telecom-centric influences that shaped SIP. Again, a question of which requirements constituents bring to the table and what points of consensus we can reach.
And... >> >> 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. I think we could get a consensus that people really should eat broccoli, but that's a very different matter than whether or not the meal in front of us at any given moment should have broccoli in it. We have a consensus that there should be cross-area review for security today, and we are working towards similar constraints for privacy, but we need to acknowledge that there is a certain amount of broccoli being shoved onto random plates that is perhaps not going into people's mouths today. If we replace the whole meal with broccoli, people will decide to dine elsewhere. [snip] >> >> 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. I think it makes an argument that we need to target our security requirements on places where they will genuinely impact implementations and deployments, rather than flooding security anywhere it will fit and hoping that a rising tide will lift all boats. Our current process is not however conducive to identifying places where security will be successful. [snip] >> 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.) I don't mean to argue for the status quo, I'm as outraged and scared as anyone. I just don't want to see us make changes that will ultimately work against our interests. I'd like to find ways that we can convince the community to accept confidentiality mechanisms as routine. My concern is that, as the case of SIP demonstrated, sometimes the success of a protocol depends on lacking security features in certain places, and if we're here to engineer successful protocols, broadly mandating the use of features like confidentiality will necessary limit that success. There will be places the community will accept security, and others where they won't. Today, where they find guidance onerous they just ignore it - if we make distasteful guidance inseparable from our protocols, then they will just ignore our protocols. Jon Peterson Neustar, Inc. >S. _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
