On Mar 6, 2013, at 7:29 AM, Scharf, Michael (Michael) wrote: >> 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. 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. 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.). >> 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? _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
