On Fri, Jul 7, 2017 at 11:34 AM, Jim Reid <j...@rfc1035.com> wrote: > > > 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. >
Okay, absent any strenuous objections, I propose that we mention that the client may cache data from the chain. For the case of a TLS client re-connecting to the same end point, most likely TLS session resumption would be used (thus dnssec_chain re-validation wouldn't be needed) so this optimization doesn't gain anything. But yes, it would help save the client some signature validation work in the case of tlsa.foo.com to tlsa.bar.com. -- Shumon Huque
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
