Brian, If the reason for security is to not lose security about let others know who I am talking too I would except that all "411" directory services will be encrypted. Probably people do not care for that.
Roni > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Brian Rosen > Sent: Saturday, December 12, 2009 12:03 AM > To: David A. Bryan > Cc: P2PSIP WG > Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as > part of the WGLC > > <as individual> > > Sorry, don't buy it. > > There is no flaw in SIP wrt what we are discussing. TLS is "mandatory > to > implement", but it's not integral to the protocol. I don't want to go > down > the path of yet another insecure protocol. > > Suppose there were 7 RTs for each branch of direct response, although > that > isn't true for a null ciphersuite, right? > > For the use cases we have so far considered, who cares? You are trying > to > optimize something that doesn't seem to matter enough to lose the > security > of knowing who you are talking to. > > One peer won't see that much traffic, and the total of all of them > isn't > really much of an issue. If it's a big deal to you, keep persistent > connections for all the fingers (or equivalent). > > Brian > > On 12/11/09 3:53 PM, "David A. Bryan" <[email protected]> wrote: > > > <as individual> > > > > The problem here is that this isn't SIP or a protocol like it, and so > > the design and deployment lessons don't precisely apply. While people > > often call SIP "peer-to-peer", it isn't in the same sense as we use > > that term when talking about a DHT. Assuming we make a protocol that > > works for a variety of routing techniques and DHT types, rather than > > the somewhat narrow subspace of just recursive response chord-like, > > the way messages are routed is highly variable. In many cases, > several > > new connections may be required for each transaction, just to get a > > reference to reach the remote party (then connecting to the remote > > party becomes very SIP like, and yes, (D)TLS may make sense once you > > are establishing a communications connection...) > > > > We got burned with a design flaw for SIP, but that doesn't mean that > > what would have worked for SIP is the right answer for every > protocol. > > > > Direct response. Parallel search with direct response. Iterative > > search, Parallel iterative search...all of these are valid P2P > > mechanisms in the literature, and in the deployed 'net, yet for all > > three, the overhead of DTLS, 7 messages per hop (and there could be > > many hops in iterative parallel search) as I cited in my reference in > > the initial email, is too much for a connection that may only be used > > once. Keep in mind it still at that point hasn't provided end-to-end > > security either (although obviously we can)... > > > > I have a paper in submission for publication that shows that even for > > networks with many NATs, direct response results in reduced message > > counts, and for large overlays, even reduces mean search time > (overlay > > wide) in some cases, depending on the fraction behind NATs. While I > > believe in v6-v6 NATs, over time, direct will make increasing sense > in > > a less NAT filled world, and the cost of TLS will not make sense as > > the one and only security mechanism for such a system. > > > > Security makes sense...but mandating one and only one mechanism will > > do one of two things: "Future-proof" the protocol (meaning the > > protocol protects itself against the pesky future and just doesn't > get > > used), or ensure that people will just break the spec. I'd rather > > avoid both outcomes... > > > > David > > > > On Fri, Dec 11, 2009 at 2:29 PM, Brian Rosen <[email protected]> > wrote: > >> <as individual> > >> Lots of implementations of a protocol like, say, SIP, don't "care" > to use > >> tls. It gets low on the implementation priority list, many > implementations > >> don't have it, and then even the ones that do can't use it because > the other > >> side doesn't. We have lousy, very lousy experience with security > options > >> like that. We KNOW what happens when we don't make it integral to > the > >> operation of the protocol. I don't want to go through that again. > >> > >> While there is no such thing as protocol police, I think the notion > that > >> p2pip ALWAYS uses D/TLS is a very useful, powerful, and important > >> characteristic of the protocol. If you don't need much security, > negotiate > >> a null cipher suite. The overhead is low, the benefits are great. > >> > >> Brian > >> > >> > >> On 12/11/09 2:07 PM, "jc" <[email protected]> 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 _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
