Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04

[Shumon Huque <[e-mail]>]

On Fri, Jul 7, 2017 at 11:34 AM, Jim Reid <[e-mail]> wrote:

>
> > On 7 Jul 2017, at 16:06, Shumon Huque <[e-mail]> 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