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

[Viktor Dukhovni <[e-mail]>]

On Fri, Jul 07, 2017 at 11:06:45AM -0400, Shumon Huque wrote:

> We've had this discussion numerous times over the life of this draft, and
> there was never any consensus for the client caching or not. An
> implementation could have the client cache the data, and only validate the
> portion of the chain that it needs to, without any wire protocol change.
> I'm okay with mentioning that possibility.
> 
> 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.

Once the client obtains a validated TLSA RRset for the service
endpoint, it may (up to the TTLs of the provided records, validated
to conform to the max ttl of the RRSIGs and not exceed the RRSIG
expiration) simply not omit the extension in subsequent requests,
and validate the server certificate per the cached TLSA RRs.

This requires no complex protocoll machinery, just caching of the
validated TLSA RRset.  This is essentially the same as obtaining
validated TLSA records via DNS, where they are cached in the client's
resolver up to the relevant TTL.  Only here the client can choose
to cap the TTL to a lower value, and ask the server again sooner.
The client cannot as easily cap the maximum cache TTL of its
iterative resolver.

So, indeed I would not try to engineer partial caching, with the
client soliciting a portion of the complete set of validation
RRsets.  However, simple caching of the given server's validated
TLSA RRset for repeat visits is not unreasonable, if the client
implementation chooses to do that.

Servers may wish to cap their TLSA record TTLs knowing that they
may be cached by clients.  Clients might also save some CPU by
not revalidating previously validated RRsets, but they will not
avoid the overhead of receiving the full set of records from
the server.

-- 
	Viktor.