> On 5 Jul 2017, at 18:12, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > On Wed, Jul 05, 2017 at 05:30:49PM +0100, Jim Reid wrote: > >> 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? > > On today's Internet, DNSSEC is not generally available to end-user > devices. There are too many "last mile" problems. Thus, while > direct acquisition of DANE TLSA records works for (e.g.) dedicated > SMTP servers, any end-user application that wants to do DANE TLS > needs to use the proposed extension.
I am too painfully aware of those last mile issues. IMO the draft could be clearer about the fact it’s aimed at TLS clients that don’t have access to or a trust relationship with a validating DNS resolver. It might also be worthwhile explaining the trade-offs between the DNSSEC lookup and TLS chaining approaches and how an implementer or operator can choose between them when/if both are available. Though if the spec was to say “don’t bother with DNSSEC lookups at all and just use this chaining extension”, that would be fine. > Perhaps you're asking whether once the relevant records are obtained, > their validation should be via library calls to a suitable API, or > via a suitable protocol to the local resolver? No. I couldn’t care less about API issues or how the RRSIGs get validated. They’re implentation details for the implementation detail. I am uneasy at the prospect of every TLS client application include what will be essentially its own validating DNS resolver when there could/should be one of these already running on the device itself. > Except that the records will be warm in the server's cache, since > many clients will be asking it for the *same* data. The same is > not as likely to be true at the client. So there is indeed a likely > latency reduction in farming out the lookups to the server. OK. It might be helpful to explicitly say “TLS server” rather than “server” to avoid confusion or ambiguity. Sometimes this is obvious from the context. But at other places in the draft “server” could be read as “DNS server”. >> 4) It's not clear if TLS clients can or should cache the DNS data (and >> the resulting validations?) returned though this extension. > > The server will return TTLs, and caching per those TTLs is no less > appropriate than it is in DNS generally. Is there some reason why this isn’t in the draft? >> 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? > > This is application/configuration dependent. That probably needs to be captured in the document too. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
