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
