Bruce,
While I completely understand the desire to have an easy way for
implementations to test TCP connectivity, I do agree with Brian that
it's a slippery slope. For implementors trying to rush a product to
market (and to a degree isn't everyone?), I would expect that if a "no
security" mode is an option in the spec, it will be taken as the path
of easiest implementation and any number of warnings will simply be
ignored - and as a result you'll have countless insecure RELOAD
implementations out there.
Can't a developer simply NOT implement TLS when doing their initial
development?
Or perhaps someone could make a "reference test implementation"
available for developers to use that supports both "TLS" and "non-TLS"
connections? That would give developers something to work with... but
yet leave the spec as is so that "conforming" implementations must use
TLS.
My 2 cents,
Dan
On Nov 4, 2008, at 7:42 PM, Brian Rosen wrote:
<as individual>
I don't like this idea. I think that you are on a slippery slope
and I
think it's not that hard.
I'm not implementing reload at the moment, so I can't speak from
experience
in this instance.
Brian
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of
Bruce Lowekamp
Sent: Tuesday, November 04, 2008 3:34 PM
To: p2psip
Subject: [P2PSIP] adding tcp-test option to reload
There has been significant conversation around whether requiring both
TLS and ICE for a minimally functional reload implementation is too
big of a hurdle during development. Most developers first implement
something without these two components first regardless, but they need
to solve nodes exchanging identifiers (without TLS) on their own and
their protocols are not interoperable for testing purposes. The
reload authors would like to propose adding the following text, or
something similar, to introduce a tcp test mode options:
TCP Test Mode is a transport based on TCP but no security
layer. It SHOULD NOT be used in any production environment
as it
has many security vulnerabilities. It is meant only as
simple test
mode to facilitate testing and interoperability before
moving to
full TLS. When a new TCP session of this type is formed,
both ends
of the connection MUST write their binary Node-ID to the wire
before sending any other messages over the session. This
allows
both sides to discover the Node-ID of the other side and use
this
in a similar way to the Node-ID discovered when using TLS or
DTLS
from the certificate in the TLS handshake. This mode MUST
not be
used unless the configuration for the overlay instance
specifically allows it.
Bruce
_______________________________________________
P2PSIP mailing list
[EMAIL PROTECTED]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[EMAIL PROTECTED]
https://www.ietf.org/mailman/listinfo/p2psip
--
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
