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.
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.
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.
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.
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
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?
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!
- 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