> On 7 Jul 2017, at 16:06, Shumon Huque <shu...@gmail.com> wrote: > > IMO, the real gain from having the client cache data, is that the server > could then potentially send a much smaller DNSSEC chain. But this requires > the client to signal what they've cached, and makes the protocol more > complex. I would prefer to leave that to a future revision of the spec, after > we've gained some operational experience with the current one.
Shumon, I think the biggest gain would be fewer RRSIGs for the client to validate. Having the server send a smaller DNSSEC chain (and perhaps add something to the protocol for a client to signal that) probably won’t have the right cost/benefit optics. YMMV. It would be a Good Thing if a TLS client didn’t need to revalidate everything in the chain for tlsa.foo.com after closing and reopening a TLS session to that end-point or it could start at the previously validated delegation for .com when the TLS server returned the full chain for tlsa.bar.com. As you hint at, it would be good to get more data and operational expertise. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
