I think we should separate authentication from encryption/integrity more explicitly as I think there may be cases where one is required but not the other.
So how about: "When one or more of server or client authentication, encryption or integrity protection are required, an ALTO Server MUST support SSL/TLS [RFC5246] as a mechanism. For cases such as a public ALTO service or where there exists an implicit trust relationship between the client and the server, SSL/TLS may not be necessary." Ben On 4 Mar 2013, at 19:35, Y. Richard Yang wrote: > 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 > > On Mon, Mar 4, 2013 at 1:47 PM, Wendy Roome <[email protected]> > wrote: > I suggest just putting it back the way it was -- "An ALTO server MAY use > ssl/tls ..." Let the market decide. Providers who want to protect their > data will only provide secure ALTO servers. Fine! But if someone wants to > provide ALTO as a public service, and they don't care who uses it, why > should they be required to use ssl/tls? > > Also, ssl/tls is independent of the ALTO protocol spec. It's not like the > protocol defines client ids, how to authenticate clients, etc. > > Finally, wasn't one of our goals to allow proxy servers to cache full cost > maps, to cut the load on ALTO servers? Wouldn't the ssl/tls requirement > prevent that? > > - Wendy Roome > > > On 03/04/2013 13:23, "Reinaldo Penno (repenno)" <[email protected]> wrote: > > >Agreed. It would be good if we added wording such as: > > > >"An ALTO Server MUST support TLS/SSL unless there is an implicit trust > >relationship between client and server.." > > > >Implicit trust could mean that client and server are operated by same > >entity, or sit in some trusted network, etc. > > > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
