<as individual> inline...
On Fri, Dec 11, 2009 at 5:03 PM, Brian Rosen <[email protected]> wrote: > <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. Sorry, I didn't mean to claim there was some big flaw or anything. By flaw, I just meant your assertion that not designing the protocol to require TLS was wrong. Sorry for the confusion. What if someone has a desire to use another security mechanism? (we come up with something else, an industry standard gets brought in ala XMPP, we have hardware optimized for IP sec, etc.) Currently we are forcing the protocol -- forever -- to exactly one possible security mechanism. This is silly. Folks can run this without a cypher suite (or just ignore the speak and run UDP). If they don't add end-to-end security or hop-to-hop security, they are doing something dumb. If we assume we are smart enough to determine that one mechanism will be perfect for every deployment, forever, we are doing something arrogant. In the end, I'm concerned we'll have lots of people doing "work arounds" that will truly be non-standard, or they will just decide to look elsewhere for a DHT protocol. > Suppose there were 7 RTs for each branch of direct response, although that > isn't true for a null ciphersuite, right? Good question/point. Not actually sure with the null suite. Can anyone comment on the message count? That would be useful for getting a better handle on the discussion, actually. I'd particularly like to know if you could spoof the behavior if not running a cypher. (i.e., can you do it without a TLS stack if I am running another security mechanism). Still seems like an ugly hack, but an interesting point of debate. > 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. I think it matters a whole heck of a lot. The group's main use case is a distributed registrar. I think we can show that in systems that are not completely NATed direct response works better (and if we use clients for the peers behind NATs, even better). We can certainly show that some DHTs will want ot make connections to new peers with each transaction. Unless you REALLY trust the peers, we need end-to-end security. With signed routing blocks, there may be deployments (particularly those that are providing alternate link security) that don't need software hop-to-hop security. That can be accomplished much less expensively with other techniques. If you mean the case RELOAD seems most optimized for now (one that assumes we must use recursive or that we want a persistent connection to the peer storing the registration, after returning it) then maybe no, but that isn't actually quite the primary use case the group specified. It's an interesting case, but I don't think it quite fits the primary use case of the WG perfectly, actually. We should make sure we allow for all the possible scenarios. > 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). Sorry, for this one point, I actually don't quite understand what you are trying to say. I'm arguing that in some some (often more efficient) routing techniques, you need to connect to peers that aren't persistent fingers, so saying keep them doesn't quite make sense. I may just be missing this line of reasoning... Thanks, David > 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
