I do not think the argument is not worth. Many people expressed their desire for a opening security mechanism in RELOAD. Many of them agree TLS/DTLS should not be mandatory. That is an acheivement of this discussion.
Am I right? 2009/12/26 Eric Rescorla <[email protected]> > While I don't find any of the arguments below particularly convincing, > I'm not sure it's worth arguing about it. You agree we need security > and TLS/DTLS is what we've got. If your concern is purely to allow > for extensibility than I propose the following: > > - Adjacencies in a RELOAD network MUST be secured by a mechanism > that provides at minimum > + Peer authentication > + Message integrity > + Confidentiality > - Implementations MUST support TLS/DTLS. > - An overlay MAY specify any alternate mechanism in their configuration > files (and we'll provide some syntax for it) > > Would that be satisfactory? > > -Ekr > > > At Mon, 7 Dec 2009 12:57:54 -0500, > 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 more support for > > modifying the requirement for TLS/DTLS. TLS/DTLS makes sense in some > > cases, but if we are expecting RELOAD to be reusable, 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 am not advocating we allow unsecured system. There needs to be a way > > to do that for development/debugging, but you can do that with a null > > cipher, so that concern is addressed. > > > > Instead my concerns are two-fold: > > > > 1) TLS/DTLS is too heavy for query-response systems using > > direct-response routing. > > 2) There are applications that may want to secure at a different level > > or using a different technology. > > > > First, looking at DTLS for query-response systems using direct routing. > > > > A bit of background: Clearly, RELOAD should work for query-response > > systems, where the only use of the DHT is to obtain a small item of > > information (e.g. obtaining a registration or a certificate). > > Similarly, while there has been discussion about whether the current > > individual draft is the appropriate mechanism, the group hummed in > > Minneapolis to include direct routing in the protocol, and in SF the > > hum was repeated, with strong consensus to include it as an extension > > and ensure base draft doesn?t preclude it. > > > > Establishing a TLS/DTLS connection is a very heavy way to establish a > > connection between two peers for a simple response, particularly if > > using direct where the connection is used only to convey that > > response. (7 messages for DTLS [1]) With recursive response, it makes > > sense, since the connection is persistent, but a lighter mechanism > > (for example, including the requestors public cert in the request, and > > having the responder encrypt the reply) is far more appropriate for a > > direct routed response. The current draft mandates TLS/DTLS and only > > TLS/DTLS, leading to an artificially high cost for direct response > > routing. Based on my work with potential real-world users of P2PSIP > > going back almost 4 years, request-response is a very likely scenario. > > While the TLS-PSK/TLS-SRP stuff helps here, other mechanisms would > > still be more efficient. > > > > Similarly, we should allow alternate mechanisms: > > > > Even if one is using the recursive response approach for routing, > > there may be other architectures. A system of persistent peers (for > > example provisioned set-top boxes using reload to share information) > > may have ISP assigned IDs, and persistent peers connected to one > > another, and use hardware based encryption, VPNs, etc. between the > > peers. > > > > There are many ways to encrypt a connection, and mandating one and > > only one seems inappropriate. A better design is to provide a > > mechanism in the draft for an alternate encryption technique, > > recommend DTLS, provide information, and require some encryption be > > used. While someone could choose to build without encryption, the > > argument seems weak. They could also just ignore the requirement in > > the first place. In my opinion, we are more likely to have problems > > later (extensions that will have to modify the original draft to use a > > different security mechanism, deployments that are ?almost? RELOAD but > > with different security etc.) if we proceed with the current draft?s > > approach. > > > > [1] Modadugu, N., Rescorla, E., "The Design and Implementation of > > Datagram TLS", Proceedings of ISOC NDSS 2004, February 2004. > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > -- Sun Chongwei Mobile LIfe and New Media Lab Beijing University of Posts and Telecommunications
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
