This definitely makes sense to me... On 5 Mar 2013, at 08:44 , Ben Niven-Jenkins wrote:
> 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 -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: [email protected] Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
