Brian,
On Nov 6, 2008, at 12:44 PM, Brian Rosen wrote:
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.
DY> Wearing my "security" hat, I completely agree with you. It has
seemed to me that in the past various protocols have gone out with
security only an afterthought (if at all), resulting in something
having to be baked on later. So there's no argument from me on this
point. In my ideal world, it's all "secure" from the start.
DY> David was advancing two use cases where security is, in his
opinion, not really required and was advocating for having a non-TLS
mode of the protocol. Wearing my "product manager" hat, I can see his
points .
DY> My argument is that either: 1) security like TLS should be a MUST
in the protocol; or 2) it should be carved out into a separate RFC
that can be referenced and implemented.
DY> What we don't need are "SHOULD"s that will effectively mean that
the security protection is never implemented.
Dan
--
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
