> >> For server authentication, TLS imposes four costs. > >> > >> Three are trivial: the amount of CPU usage for key exchange, > > > > Plus potential handshake delay - note that an ALTO query > could be part of a latency-sensitive operation, and ALTO > server and clients could be geographically distributed. > > In that case, add 2 network RTTs on the connection setup for > the handshake.
In the world of signaling protocols (and, yes, ALTO can be seen as a signaling protocol), two RTTs can be a lot. > And hold the connection open, both costs (CPU and handshake > latency) are only on connection establishment, so they should > only affect the first query, not subsequent queries. This assumes that the ALTO client can maintaining a pool of persistent connections, that the HTTP server has enough resources to keep these connections open, etc. All this is about software engineering. I don't think that the ALTO base document should enforce specific ways how an ALTO client or server is designed internally. > Finally, if you are so latency sensitive that you can't > handle the extra 2 RTTs of network latency on connection > establishment, do a protocol over DNS with DNSSEC validation, > because that can get you single RTT > cryptographically-authenticated query/response (if you also > do a parallel query for the DS and DNSKEY RRSETs so you have > all the cryptographic data at the same time. You can also > safely fall back to "DNS with no DNSSEC" if on a broken > network which is blocking DNSSEC and the protocol is only > used for host discovery, not key exchange.). ALTO is a protocol that provides am IT-friendly, RESTful network interface that can easily be integrated in whatever application. I doubt that many app developers would consider DNSSEC a reasonable alternative to HTTP/REST. > >> But TLS offers a huge advantage: Proxies abound, and HTTP proxies > >> even moreso. The result is there are an amazing number of network > >> devices which think they are smarter than the traffic, but > well, they > >> aren't. E.g. half of the in-path HTTP caches cache data > incorrectly. > >> Cellphone networks now experience image transcoding, etc. > > > > Why would such proxies be relevant if the ALTO client and > the ALTO server run on two high-end servers inside the same > data center rack, with a dedicated and isolated 1 or 10 > Gbit/s network link in between them? > > And in that model, there is NO cost for TLS because you do > the connection establishment once and the cost disappears. > > > ALTO is a generic protocol. It can be deployed in very > different ways. > > > At the same time, without at least #2, you are in huge > trouble if there exists some supposedly "smart" middlebox.... > > There are NATs that inject responses into HTTP traffic, as > well as ISPs. There are transcoding proxies that convert 64 > kB images into 4 kB blobs that would display poorly on a > commodore 64. There are web proxies that contain 3 year old! > vulnerabilities. If its possible for an HTTP middlebox to > screw up traffic in some way, there probably is a deployed > middlebox that does it already. > > > ALTO is something new, and if you really want it to work > reliably, in as many contexts as possible, ESPECIALLY over > port 80, you must account for the middleboxes. > > And the way to account for the middleboxes is to require > support for TLS on port 443, so that the middleboxes are > forced to go "hands off". > > And once you mandate support for TLS, what reason is there to > not always use it? I think that the root cause for this discussion is that we talk here about *very* different deployment cases. I agree that TLS could help if a residential user runs an the ALTO client behind a broken middlebox, if this is what you care about. If that helps, I am fine with adding some recommendation in the base protocol spec that recommends enabling of TLS when the ALTO server is accessed by residential users (even though this might much better fit into the ALTO deployment draft). But I disagree that this is the only relevant deployment scenario for the base protocol. And I strongly believe that we should not mandate what an ALTO server operator has to write into his configuration file. Michael _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
