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

[Jim Reid <[e-mail]>]

I’ve got a few concerns/issues with the document.

1) There probably needs to be clearer guidance about the use cases for this extension and the trade-offs between TLS clients doing DNSSEC validation for themselves instead of sending DNS lookups to a validating resolver server. How does an application developer decide which approach would or wouldn’t be appropriate?

2) I’m not sure there is much of an "associated latency penalty” from DNS lookups. Something’s going to esxperience this one way or another. Either the TLS client takes that hit or the TLS server does it for them before it sends back the requested DNS data. And in both cases, whatever is making the DNS lookups should be benefitting from what’s in the resolver’s cache. That cached data may even have been validated too.

3) Something should be said about algorithm agility. We can be reasonably sure web browsers, DNS servers, smart phones and so on will generally have up-to-date DNSSEC validators and/or TLS code. Some TLS clients -- fire and forget embedded systems, IoT devices, etc -- might never get updated once they’re deployed. If these clients use their own DNSSEC validators, they will be screwed when/if DNSSEC drops SHA1 signatures (say) or adds a new flavour of ECC or even an all-new signing protocol.

4) It’s not clear if TLS clients can or should cache the DNS data (and the resulting validations?) returned though this extension. Suppose a jabber client validates foo.com, does it have to start at the root and work all the way down to validate bar.com? Could it start that validation at the previously validated and new cached trust anchor for .com? Can/should negative answers -- NOHOST/NXDOMAIN responses -- be cached?

5) How does a TLS client behave when its DNSSEC validation of a TLSA record or whatever fails? Can/should it give up or fall back to conventional validation of the certificate via a CA?

6) The draft doesn't seem to take account of key rollovers when DNS data will be signed by two or more keys. Zone signing keys are missing from the examples too. These might well have been omitted for cosmetic reasons. IMO they need to be included in the final document to illustrate what implementers can expect to find when the DNS returns signed data.