> 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.
I used my browser to go to maps.google.com, and the URL used is http://maps.google.com. So it seems Google already concluded that maps must be encrypted. :) You'll find that more than a few public web services (search, social nets) use TLS/SSL to protect the client side. You should consider the ALTO client's request to be sensitive information, not just the server's response. -- Rich On 3/5/13 1:52 PM, "Wendy Roome" <[email protected]> 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. > >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 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
