Subject: Re: [P2PSIP] Concerns, questions and nits about base -06 as part of the WGLC

From: "Michael Chen" <[email-masked]>
Date: Fri, 11 Dec 2009 10:49:12 -0700

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-masked]>

Date: Fri, December 11, 2009 7:26 am

To: Ari Keranen <[email-masked]>

Cc: P2PSIP WG <[email-masked]>

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-masked]>

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-masked]

> https://www.ietf.org/mailman/listinfo/p2psip

_______________________________________________

P2PSIP mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/p2psip

---

From: Brian Rosen <[email-masked]>
Date: Fri, 11 Dec 2009 13:16:39 -0500

<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-masked]> 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
>>>> I¹ve raised this issue before, but I¹m hoping that now that

---

From: jc <[email-masked]>
Date: Fri, 11 Dec 2009 14:07:43 -0500

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

---

From: Roni Even <[email-masked]>
Date: Fri, 11 Dec 2009 21:05:29 +0200

Brian,
The issue is not if to have or not to have security. It is what level of
security is satisfactory and there is no one solution fits all, note also
that the p2psip solution should also make it easier to nodes to serve as
peers by not putting too much burden on them. 
Deployment of security is motivated by requirements of the specific
deployment and not because of the standard, what will happen is that you
will see no compliance in cases where p2p solution will be deployed but
would prefer different security mechanism. We also need to see that there
may be other p2p overlays and joining policies as well as other usages which
may have different security requirements. 
I think that the p2prg draft that outline the security option as well as
having a security analysis for p2psip will be enough. My thought was that
specifying TLS/DTLS was to address interoperability but this can be done by
mandating implementation and not usage.

Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Brian Rosen
> Sent: Friday, December 11, 2009 8:17 PM
> To: Michael Chen; P2PSIP WG

---

From: Brian Rosen <[email-masked]>
Date: Fri, 11 Dec 2009 14:29:43 -0500

<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

---

From: Brian Rosen <[email-masked]>
Date: Fri, 11 Dec 2009 14:31:32 -0500

The way you tune the level of security is the ciphersuite choice.

That's a plenty good enough knob.

The overhead of TLS with simple ciphersuites is low.  Low enough that the
argument to remove it in some circumstances doesn't make any sense to me.

Brian

---

From: Salman Abdul Baset <[email-masked]>
Date: Fri, 11 Dec 2009 14:33:18 -0500 (EST)

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

---

From: jc <[email-masked]>
Date: Fri, 11 Dec 2009 14:56:44 -0500

Salman,
If you see my other email, yes the iterative nature of Kademlia makes D/TLS  too expensive, it would have to be made recursive to obey the draft. 

I agree about "Attempting" to connect all Nodes even if it MUST TURN them. This is a big failure that won't see success.

> 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.

I see this as impossible. Peers and Nodes' need revisited. For instance, it's cheaper to Peer than to TURN so what good is TURN for the Overlay connections? TURN is useless to the Overlay IMHO, this could be used for call routing and app layer services. If you are a Node and you MUST TURN you should Peer instead IMHO.

Julian Cain

On Dec 11, 2009, at 2:33 PM, Salman Abdul Baset wrote:

> 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
> 
>> 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
>>

---

From: "David A. Bryan" <[email-masked]>
Date: Fri, 11 Dec 2009 15:53:14 -0500

<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

---

From: Brian Rosen <[email-masked]>
Date: Fri, 11 Dec 2009 17:03:19 -0500

<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

---

From: "David A. Bryan" <[email-masked]>
Date: Fri, 11 Dec 2009 19:20:37 -0500

<as individual>

inline...

> 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.

> 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.

> 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.

> 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

---

From: Roni Even <[email-masked]>
Date: Sat, 12 Dec 2009 03:30:33 +0200

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

> Sent: Saturday, December 12, 2009 12:03 AM
> To: David A. Bryan
> Cc: P2PSIP WG
> >>>>> previous post voice concerns about redundancy and efficiency of
> the
> >>>>> transport
> >>>>> layer.
> >>>>>
> >>>>> --Michael
> >>>>>> I said this about 7 months ago and I still agree that there
> should
> >>>>>> be

---

From: jc <[email-masked]>
Date: Fri, 11 Dec 2009 21:16:02 -0500

The overlay should obtain the transport layer security mechanism from  
the configuration file.

I was a senior engineer at gizmo5 recently aquired by google. One  
thing that occured prior to my arrival was that we had bricked  
ourselfs off via TLS and this could only decrypt/encrypt gizmo to  
gizmo. Skype has a hard coded security mechanism of the base overlay  
protocol.

Let's not do the same.

Julian

---

From: Francois Audet <[email-masked]>
Date: Fri, 11 Dec 2009 20:15:06 -0800

Perhaps what should be done is mandate TLS for now, and leave it open  
for alternative mechanisms to be later standardized.

On Dec 11, 2009, at 18:16 , jc wrote:

> The overlay should obtain the transport layer security mechanism  
> from the configuration file.
>
> Julian_______________________________________________
> P2PSIP mailing list
> [email-masked]

---

From: Roni Even <[email-masked]>
Date: Sat, 12 Dec 2009 09:12:10 +0200

If you mandate using TLS you are stuck with it. You can mandate implementing
it which will allow alternative mechanisms, today and in the future. The
fear is that implementers will not do it but the same concerns should have
been about implementing Chord in Reload
Roni

> From: Francois Audet [mailto:[email-masked]]
> Sent: Saturday, December 12, 2009 6:15 AM
> To: P2PSIP WG
> Cc: Roni Even; jc

---

From: Song Haibin <[email-masked]>
Date: Thu, 17 Dec 2009 11:51:23 +0800

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  

> From: [email-masked] 
> [mailto:[email-masked]] 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
> 
> >> 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.
> >>
> >> 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
> >>
> >>
> >>> previous post voice concerns about redundancy and 
> efficiency of the 
> >>> transport layer.
> >>>
> >>> --Michael
> >>>> Subject: Re: [P2PSIP] Concerns, questions and nits about 
> base -06 
> >>>> as part of the WGLC
> >>>> 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
> >>>>
> >>>>>> 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

---

From: jc <[email-masked]>
Date: Thu, 17 Dec 2009 16:19:42 -0500

Nor is ICE good for overlays making use of iterative routing.

Julian