<as individual> I don't agree. In fact, if there was a way to guarantee the protocol wouldn't work without TLS, I'd prefer to do that.
I'm tired of marketing folks looking to save a buck of development costs slicing off security and foisting insecure implementations on unsuspecting consumers, only to be among the loudest voices slamming their engineering guys for why the security fix is necessary or can't be done yesterday when the problems show up. If you don't need security, then use a simple ciphersuite; don't lop off TLS. There is plenty of good open source TLS code around. Use it. ICE is a little trickier. I have the same concerns: implementations that work in some restricted environments escaping into the wild and failing; followed by horrible work around like opening holes in firewalls or lack of interoperability. The problem is that there isn't, yet, lots of good open source ICE implementations. So, I want to go the other way. I want every bit of documentation to say "it's mandatory" Brian -----Original Message----- From: Dan York [mailto:[EMAIL PROTECTED] Sent: Thursday, November 06, 2008 9:38 AM To: David A. Bryan Cc: Brian Rosen; p2psip Subject: Multiple RFCs or one giant RFC? Re: [P2PSIP] adding tcp-test option to reload David, On Nov 6, 2008, at 8:53 AM, David A. Bryan wrote: > Very good points...in many ways I'd definitely agree the approach of > doing things like this in different drafts, if we could get people to > go for that approach. As you point out -- much easier to specify what > one does and does not support... Problem would be the draft explosion. DY> Well, yes, draft explosion definitely IS a problem. We need only look at the fact that we need a Hitchhiker's Guide or Henry's simple SIP draft to know that there is a problem. On the other hand, we're all just in this wee minor little process of rearchitecting the entire communications infrastructure of the planet... :-) DY> As much as we don't want an explosion of a zillion drafts, do we really want giant documents that are complicated to implement? DY> Comparing to software development models, are we trying to do the monolithic approach of building big giant programs that do everything?? Or are we trying to do the UNIX approach of making many small utilities and stringing them together? > > Also for this one I think that we could specify a way in the draft for > the two sides to negotiate if they have TLS or not, although that > solves things at a protocol level, not at a "I support XXXX" level... DY> Right. So we can make the spec allow them to negotiate... but that does nothing to help with whether or not two P2PSIP implementations can interoperate. A vendor can't take the RELOAD spec, implement it, and know that they have a prayer of FULL interoperability with someone else... because there are optional parts to it. DY> You've already defined two very clear use cases for where P2PSIP would be implemented WITHOUT "security" aspects to the protocol. So why not simplify the main spec and carve those off as separate RFCs? DY> Let's look at a case where this has worked well - RTP. If you want to implement basic RTP, you implement RFC 3550. If you want to implement Secure RTP, you implement RFC 3711. Ta da... you're done. It's very easy for vendors to specify whether or not they support "secure" use of RTP because they can point to their use of "SRTP" as defined in RFC 3711. DY> Now, yes, I'm a "security guy" arguing to REMOVE security provisions from the main draft, but that's primarily because I realize that if they are left in there as (wink, wink) "options", then NOBODY WILL IMPLEMENT THEM. They text is in the RFC and so someone can say that they have appeased whomever is doing a security review, but in practice no one will implement them and the result is that protocols will wind up being LESS secure. DY> I've also been a product manager responsible for trying to ensure proper implementations of various RFCs and in that role I can assure you that large RFCs containing SHOULDs are horrible. I would vastly prefer multiple RFCs (where the division makes sense) that *only* contain MUSTs. DY> Why don't we put this on the P2PSIP agenda for IETF 73? (the idea of breaking out security aspects into a separate draft) My 2 cents, Dan P.S. And realizing that I'm advocating making MORE work for the WG and we just had a long thread on the RAI list about the lack of people to *do* things, I'll put my actions behind my mouth and say that if the group agrees with this path, I will volunteer to write one of the companion drafts. -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation [EMAIL PROTECTED] Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Build voice applications based on open standards. Find out how at http://www.voxeo.com/free _______________________________________________ P2PSIP mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/p2psip
