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
