On Fri, Jul 7, 2017 at 10:11 AM, Jim Reid <j...@rfc1035.com> wrote: > > > 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 is not aimed solely at those clients. The intro mentions 3 things: (1) TLS clients don't need to do any additional DNS lookups for DANE/DNSSEC - the latency issue, (2) TLS clients don't need to deal with breakage caused by middlebox/last mile issues if they tried to do those lookups, and (3) they don't have secure access to a validating resolver. If an application has any subset of these issues, it might be candidate user of this extension. > > 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. > Maybe some day all end user machines will have a validating resolver, but this isn't remotely close to a reality today. > > 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”. > Ok, we can look through the text and disambiguate where needed. > >> 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? 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. -- Shumon Huque
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
