Wendy,
On 03/05/2013 07:52 PM, Wendy Roome wrote:
First, TLS is much more overhead, both network & server. It requires
several handshakes between the client & server. Granted, once a client &
server have established a TLS connection, they can reuse that TLS
connection for subsequent requests -- for a while. That's fine if a client
sends an ALTO request every few seconds, but not if it's minutes between
requests. And, of course, full cost maps can easily be megabytes, so the
encryption eats cpu cycles on the server.
The last part assumes that you tear down the TCP connection after you
have received the map. That is not necessarily true.
Further, there are a number of large services, e.g., to name a few
Google Maps, Facebook, etc, that use TLS by default and the apps and the
server haven't melted down.
Second, if I'm running a server, I have to get a properly signed
certificate. That usually means I must prove to an authority that I
legally represent some company, and pay for it. Yes, I can self-sign a
cert for testing, but that's useless for a production system.
This all assumes that your deployment is using TLS/SSL. However, the
ALTO protocol itself must support TLS/SSL even if it is not used in
certain deployments.
I see that you mix the need to have it in the protocol and the actual
usage in deployments.
Third, the server has to keep that cert in an encrypted file, and give the
password to the ALTO web server. The latter can be an interesting
challenge. The simple way is to put the password in a startup shell. Of
course, that's not very secure. A better way is to require a human to
enter the password each time the ALTO server starts. That has a different
set of problems.
What's the issue here?
Apparently there are deployments using TLS with proper certs...
Finally, on the client side, basic access is easier than it used to be.
But if a client needs to authenticate itself to a server, then the client
also has to get a certificate, keep it encrypted, and give the password to
the ALTO client application securely.
That is a different story, isn't it?
TLS is mainly used to check if the server is the server it claims to be
and to setup an encrypted connection to it. Sure there is the
possibility to also authenticate the client to the server, but that is
rarely used.
This is a very nice example to show what the protocol must implemented
but what is not used in deployments!
I think that if an ALTO server operator feels they need that level of
security, fine, let them use SSL/TLS. But I think the operator should make
that decision. Why should we say that ALTO data is so inherently sensitive
Right.
that any valid ALTO server MUST encrypt it? Particularly since a server
can use PIDs and ordinal costs to hide critical details of their network?
Nobody is saying this.
Section 7.3.5 of draft-ietf-alto-protocol-14 says
"An ALTO Server MUST support SSL/TLS [RFC5246] to implement server
and/or client authentication, encryption, and/or integrity
protection."
Put it another way, consider the arguments for why ALTO data *must* be
encrypted. Then apply those arguments to (say) google maps. I suspect
you'll conclude that google maps must be encrypted as well. After all,
clients give google maps their current locations, which is sensitive data.
And some creep who spoofs a google maps server can do a lot of harm --
probably more than someone who spoofs an ALTO server!
Have you recently used and checked what Google Maps is doing?
Martin
- Wendy Roome
On 03/05/2013 11:30, "Sebastian Kiesel" <[email protected]> wrote:
and I'd
object to anything that implies that the default is to use ssl/tls. I
think
that will kill the protocol.
Can you please be more specific.
Would it be too painful to write an ALTO server and client software that
has TLS support?
Or do you fear that operators would refrain from installing an ALTO
server if they read that they SHOULD enable TLS?
_______________________________________________
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
