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
