On Wed, 27 May 2020, Ben Schwartz wrote:
I agree that the TLS DNSSEC chain extension isn't substantially deployed today, but I don't think that should stop us from using it if it would help. This use case is important enough to drive deployment.
If people really want to avoid doing an extra RTT, then I guess this extension could be used. But you would still need to have some kind of TLS server SAN with FQDN conveyed within the DS record. Having a single bit in the DS signifying "yes there is DoT", isn't enough if the additional glue NS records can point to any machine with a valid TLSA chain.
Using this extension would indeed require the authoritative server to provide TLSA records for its own name. I don't think it actually has to "resolve its own name", because it can choose a name that is in-bailiwick. Servers can choose an in-bailiwick authentication name even if existing NS records have an out-of-bailiwick name. If an authoritative server has multiple names, it would presumably identify the right one from the TLS-SNI.
The nameserver name has to be known (from DS) before the resolver connects to the DoT server. How the DoT server would identify itself, via TLSA or via fake DNSKEY doesn't really matter as it can just provide whatever we decide to use. Personally, I think it would be cleanest if we use the DS to signal the DoT nameserver only by FQDN. Then connect to it and get the TLS chain containing the TLSA record and the CDS that matches the DS. That way, we can avoid adding pseudo-DNSKEY records. I understand not every registry supports DS/CDS, but I think if you want to deploy this, you cannot be depending on humands anything, so CDS or CDNSKEY support would be a requirement anyway. Let's just convince those registries that support CDNSKEY but not CDS, that they need to fix things. It would make everything a LOT cleaner and we got no bogus DNSKEY records to ignore in our DNSSEC validation path. Paul _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
