Richard, Your proposal sounds fine. After all, it's a "motherhood" statement. Who could argue with, "If you need security, etc, use ssl/tls."?
However, I am surprised by the suddenly perceived need for security, and I'd object to anything that implies that the default is to use ssl/tls. I think that will kill the protocol. I'd always thought that ALTO was primarily intended to be a public service that network operators provide to all applications, not an exclusive service available only to a few trusted components. A network operator would provide a public ALTO service because it benefits the operator as well as the client. Sure, some operators might restrict access, but most wouldn't bother. A few observations: * An ALTO server just returns a limited view of the network statistics. It's not like it gives out launch codes or banking data, or allows a client to change anything. Why is it so important to keep that data secret? Especially if a server can use ordinal mode to obscure the details? * The only use case in draft 14 is a P2P tracker. By definition, P2P trackers are distributed & anarchistic, and can be run by any Tom, Dick or Sally. I don¹t think it's practical to authenticate thousands of P2P tracker clients. Besides, most tracker operators wouldn't hesitate to post their ALTO authentication credentials on the web. :-) * I can see why an ALTO client might want to authenticate the server, to prevent spoofing. Although that begs the question of why someone would bother to spoof an ALTO server -- how would they benefit? - Wendy Roome From: "Y. Richard Yang" <[email protected]> Date: Mon, March 4, 2013 14:35 To: Bill Roome <[email protected]> Cc: "Reinaldo Penno (repenno)" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [alto] ALTO vs ssl/tls Hi Wendy, The context of the change is the following AD Review: " What security mechanism to use in what scenario. The considerations elaborate on the use of SSL/TLS, but it is not clear when to use it. In general, it seems to be really good, at least by today, to mandate the use of HTTPS in almost any scenario where the traffic crosses a publicly available infrastructure, e.g., the general Internet, wireless access networks, etc. Conversely, it can be good to always mandate the use of HTTPS and to list exceptional cases where it is required, i.e., CDNI peering point." How about the following revision: "When server and/or client authentication, encryption, and/or integrity protection are required, ALTO Server MUST support SSL/TLS [RFC5246] as a mechanism. For cases such as a public ALTO service or there is an implicit trust relationship between the client and the server, SSL/TLS may not be necessary." Richard
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
