On Tue, Mar 05, 2013 at 01:52:55PM -0500, 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. > > 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 more or less agree with all these points. > 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. I fully agree. The operator should make that decision. But the operator is able to make a choice only if the software has a switch to turn on (or off) TLS usage. We are currently working towards a standards track RFC with the title "ALTO Protocol". My interpretation is that the primary goal of this document is NOT to give guidance to ALTO server operators whether/when to use TLS or not (this kind of information might become a side note, but I think it would better fit in our separate "ALTO deployment considerations" document, which admittedly still needs much work). Instead, I belive the primary goal of the "ALTO protocol" RFC will be, that when a software vendor offers ALTO software to an operator, they can claim "our software is RFCxxxx-compliant" and then the operator (i.e., software buyer) can expect interoperability with RFCxxxx-compliant software from other software vendors, as well as a well-defined set of properties to be fulfilled. The ability to switch on TLS if desired should be one such property. > Why should we say that ALTO data is so inherently sensitive > that any valid ALTO server MUST encrypt it? We don't want to say that. We want to say: "any piece of software that claims to be RFCxxxx-compliant MUST be linked against a SSL lib and have config file options where the operator can put the certificates, etc. Furthermore, there must be adequate mechanisms that kick in when certificate verification failed." More formal, as we do not know whether future operation system platforms will have libraries and config files: "Any ALTO implementation MUST support SSL/TLS [RFC5246]" Of course, there may be a config file option to disable TLS. Does this make sense to you? Thanks Sebastian _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
