<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.
