I believe it would be good to state what version of TLS is mandatory to implement. I would suggest TLS 1.2. (I assume ALTO needs PK-based server side authentication)
On Mar 5, 2013, at 6:14 PM, Martin Stiemerling wrote: > Wendy, > > would a 'MUST implement TLS/SSL' fix your concern? This does say that the > implementation must have it, but it does not preclude to use it, e.g., if you > operate the ALTO server in your data center only. > > Martin > > On 03/05/2013 04:39 PM, Wendy Roome wrote: >> 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] <mailto:[email protected]>> >> Date: Mon, March 4, 2013 14:35 >> To: Bill Roome <[email protected] >> <mailto:[email protected]>> >> Cc: "Reinaldo Penno (repenno)" <[email protected] >> <mailto:[email protected]>>, "[email protected] <mailto:[email protected]>" >> <[email protected] <mailto:[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 >> > > -- > [email protected] > > NEC Laboratories Europe > NEC Europe Limited > Registered Office: > Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB > Registered in England 2832014 > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
