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
