Nor is ICE good for overlays making use of iterative routing. Julian
On Dec 16, 2009, at 10:51 PM, Song Haibin wrote: > > TLS/DTLS is not good to the DHT algorithms that use iterative routing. And > it also prevents using of direct response to a certain extent. Having a > security analysis draft for p2psip for deployers to consider threats and > possible solution in their deployment scenarios will qualify. > > For interoperability, it depends on both the standard and the number of > deployers who want to obey the standard. > > Thanks, > Haibin > >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Salman Abdul Baset >> Sent: Saturday, December 12, 2009 3:33 AM >> To: jc >> Cc: P2PSIP WG >> Subject: Re: [P2PSIP] Concerns, questions and nits about base >> -06 as part of the WGLC >> >> Kademlia does iterative routing with parallel requests, and >> iterative routing has to pay the penalty of TLS/DTLS >> connection establishment at every hop which is at least 1.5 RTT. > >> >> The alternative is to devise a secure transport protocol or >> optimize DTLS/TLS to reduce the connection establishment >> penalty. Security folks may argue that it is a non-starter at IETF. >> >> Yet, another alternative is to design a custom secure >> transport. But interoperability is the obvious looser. >> >> In general, for Internet scale deployment, the idea of trying >> to make all nodes, no matter what their connectivity, fully >> participate in the overlay as a peer is highly questionable. >> >> -s >> >> On Fri, 11 Dec 2009, jc wrote: >> >>> Some individuals may not care to use tls or dtls. These standards >>> aren't practical in all cases. Encrypted transports a MUST but >>> mechanism should be optional. This is better than people not using >>> this draft and resolves conearns about the underlying >> transports lack >>> of performance in certain use cases. >>> >>> Thinking Chord only as a topology plugin is too narrow from >> a security >>> performance perspective. I have bad experience with Kademlia as a >>> topology plugin. If you understand Kademlia you should >> understand how >>> the routing table functions and how the transports reflect >> that. All >>> topology plugins will be forced to tune themselves to d/tls >> which the >>> result is a less efficient system. >>> >>> I don't see where anyone mentioned throw out encryption >> entirely but I >>> may be wrong. >>> >>> Julian >>> >>> Sent from my iPhone >>> >>> On Dec 11, 2009, at 1:16 PM, Brian Rosen <[email protected]> wrote: >>> >>>> <as individual> >>>> I disagree. >>>> >>>> The problem is that we have a whole lot of history and experience. >>>> >>>> The experience is that if we don't insist, and make >> security integral >>>> to the protocol, it doesn't get implemented and we have a >> majority of >>>> insecure systems. >>>> >>>> If we do insist, the cost of the security is reasonable: the dire >>>> predictions that it's too costly, too hard, ... don't happen. >>>> >>>> No amount of text explaining when the security mechanism >> is or isn't >>>> appropriate works. You have to make the mechanism integral to the >>>> operation of the protocol, as we have done here. >>>> >>>> I don't see anything in p2psip which would be different then our >>>> history and experience. The costs aren't as bad as you fear. The >>>> probability of nearly every system being implemented insecurely is >>>> very high if you make it optional. >>>> >>>> Don't do that. >>>> >>>> Brian >>>> >>>> >>>> On 12/11/09 12:49 PM, "Michael Chen" >> <[email protected]> wrote: >>>> >>>>> I too agree with the three of you. D/TLS should be optional. >>>>> Several of my >>>>> previous post voice concerns about redundancy and >> efficiency of the >>>>> transport layer. >>>>> >>>>> --Michael >>>>>> -------- Original Message -------- >>>>>> Subject: Re: [P2PSIP] Concerns, questions and nits about >> base -06 >>>>>> as part of the WGLC >>>>>> From: jc <[email protected]> >>>>>> Date: Fri, December 11, 2009 7:26 am >>>>>> To: Ari Keranen <[email protected]> >>>>>> Cc: P2PSIP WG <[email protected]> >>>>>> >>>>>> I said this about 7 months ago and I still agree that >> there should >>>>>> be no mandatory transport layer encryption as this should be >>>>>> provided outside of the scope of this draft. >>>>>> >>>>>> Julian >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> On Dec 11, 2009, at 5:39 AM, Ari Keranen >>>>>> <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> David A. Bryan wrote: >>>>>>>> Concern 1: Mandatory TLS/DTLS Inappropriate in some >> Contexts I've >>>>>>>> raised this issue before, but I'm hoping that now that people >>>>>>>> have had a bit more time to think about all the use cases, see >>>>>>>> what it means in the real world, etc., there might be >> a bit mo re >>>>>>>> support for modifying the requirement for TLS/DTLS. >> TLS/DTLS ma >>>>>>>> kes sense in some cases, but if we are expecting RELOAD to be >>>>>>>> reus able, it is clear to me that it does not make >> sense in all cases. >>>>>>>> It was familiar >>>>>>>> to the editors, and well understood, so it made sense as a >>>>>>>> proposal, but I disagree with it being the mandatory/only >>>>>>>> solution. >>>>>>> >>>>>>> I fully agree with David that making (D)TLS mandatory is not a >>>>>>> good idea, especially concerning re-usability of the >> protocol in >>>>>>> scenarios where you already have similar security features >>>>>>> provided by the underlying system. >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> Ari >>>>>>> _______________________________________________ >>>>>>> P2PSIP mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>>> _______________________________________________ >>>>>> P2PSIP mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>> >>>>> >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/p2psip >>> _______________________________________________ >>> P2PSIP mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/p2psip >>> >> > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
