On Wed, Jul 29, 2015 at 05:38:48PM +0000, Viktor Dukhovni wrote: > On Wed, Jul 29, 2015 at 12:01:28PM -0500, Nico Williams wrote: > > If there's a latency hit, it will be when a sever has both, [...] > > This raises an interesting point. > > [...optimization discussion elided...] > > I don't know whether it is appropriate for the extension draft to > discuss such potential (bandwidth) optimizations. The code that > I wrote to validate DANE chains certainly ignores any certificates > beyond the leaf with DANE-EE(3) and beyond the trust-anchor with > DANE-TA(2).
An "extension" may be where the stapled DANE data goes. That doesn't mean that it's an "extension" in the sense that you're thinking. Arguably this is core functionality for TLS. Still, I'd advise for specifying and implementing this optimization, but I'd make it OPTIONAL to implement. It's only an optimization. > So the optimization opportunity is there, but we'd have to declare > that a client sending the extension effectively commits to using > DANE and forgoes the option of using the full PKIX chain (when a > shorter chain suffices for DANE, i.e. the TLSA RRs contain exclusively > certificate usage DANE-EE/DANE-TA not PKIX-EE/PKIX-TA). Yes. > If the optimization is "blessed", then it might even be the case > that at times the leaf certificate plus TLSA RRset with evidence > is shorter than the PKIX chain (if the RRSIGS are EC-based). Quite likely. Plus there's no need for OCSP stapling, nor CRL checking. So in fact DANE stapling will be a net win. > This brings us to another point, the server can't know whether its > domain is even DNSSEC-signed in the eyes of the client. The client's > supported DNSSEC signature algorithms are not sent in the client's > extension. Whether the server "optimize" or not, there's not much > point sending a pile of TLSA RRs, and associated RRSIG/DNSKEY/DS > records, if some DS RRset needed to validate the response lists no > algorithms supported by the client. > > It might make sense to change the client portion of the extension > to send a list of the client's supported DNSSEC algorithm numbers. Agreed. > On the other hand, clients that hand-off the validation to the > local resolver (as suggested in recent threads) might not always > know which algorithms are supported by that resolver. That would > have to be client configuration, or something the client can ask > the resolver via an EDNS option of some sort. Good point. Nico -- _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
