On Tue, Jul 28, 2015 at 05:26:16PM -0800, Melinda Shore wrote: > I think the primary concern about that is the possibility > of introducing additional latency, given that we're trying > to minimize the DANE performance hit on clients like browsers, > who tend to be extremely sensitive to delay. [...]
This is probably worth going over in some detail. Where there is no last-mile problem the client will do best to issue async DNS lookups for all the records it needs, and this will probably be faster than stapling. But the client won't always know (especially if it's mobile) when stapling is the only thing that will help, so stapling we must. When stapling is needed there is no latency hit on the server (of course), and the only latency hit on the client is a) the time to transmit the stapled data (server-to-client), b) the time to transmit the stapled data (client-to-resolver-daemon), c) the time to validate the stapled data, d) having to wait until all the stapled data is available to begin validation. (a) and (c) are present whether we staple or not, and (b) is negligible (loopback networking). There's a negligible win in not having to send requests. That leaves just (d): having to wait for the stapled data. But (d) is the same for DANE as for WebPKI/PKIX, which leaves us with... nothing that adds latency by comparison to WebPKI/PKIX. The case where client can speak DNS itself is a win compared to WebPKI/PKIX because the client can asynchronously do some of the trust chain validation work before getting the stapled data from the server. Stapling DNSSEC/DANE is no different than the server sending its certificate chain to the client and needs to be compared to just that, not just to stapling of OCSP Responses. If there's a latency hit, it will be when a sever has both, a long PKIX certificate chain and a long DNSSEC/DANE RRset chain to send (since both have to be transmitted, and the client may end up having to validate both). Operators should avoid this. In any case, I don't see how the encoding of the RRsets affects latency except that using a DNS message is a win for those who use DNS to a local resolver daemon as the validation API. Using a DNS message is neutral for all other implementors. Nico -- _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
