On Thu, 28 May 2020, Eric Rescorla wrote:
If you want to use tls-dnssec-chain, there's no reason you have to wait for the ISE. The code points can be assigned today based on the existence of the draft.
Thinking about this again. There is actually no strong reason for tls-dnssec-chain. The TLS channel you are authenticating is the actually TLS channel you intend to use for DNS queries anyway. We are not talking about a browser needing to setup a TCP connection to resolver to then go back to its other TCP/TLS connection it is actualy trying to use. And we are not building a huge chain over CNAMEs or other zones either, so we might not even need RFC 7901 Query Chain support. The tls-dnssec-chain was much more about full recursive query chains spanning multiple domains and choices regarding webpki vs dnsec or pinning. But our queries are only for a single domain here. And the webpki isn't in use here, and pinning happens via DS/CDS existence. Let's talk about a full example. Let's lookup www.libreswan.org. I've connected with DoT to d0.org.afilias-nst.org, I ask for NS/DS of libreswan.org. I am returned a DS for libreswan.org and NS/A glue records for ns*.nohats.ca. I determine the DS record contains a "do DoT" entry that contains the name "ns0.nohats.ca". I connect to ns0.nohats.ca following the glue that .org gave me on the Dot port. I setup a TLS connection, but I haven't authenticated it yet. It should query it for DNS records for authentication until I authenticated the TLS layer. I send a query for TLSA of ns0.nohats.ca over the unverified TLS channel. I get back a DNSSEC verifiable answer (DNSKEY, TLSA, RRSIGs) I DNSSEC verify the data, and can trust the TLSA record contents. I know know the public key, EE-cert or CA-cert for the DoT connection on ns0.nohats.ca. I verify my TLS channel. Now I'm authenticated, and I can send a query for CDS libreswan.org to confirm the child agrees with the parent on DoT and nameservers. Once confirmed, I can now query any kind of data for libreswan.org over this DoT channel. Where would we gain much by using RFC 7901 Query Chains or tls-dnssec-chain? Paul
On Thu, May 28, 2020 at 9:44 AM Shumon Huque <[email protected]> wrote: On Thu, May 28, 2020 at 5:33 AM Stephen Farrell <[email protected]> wrote: On 28/05/2020 02:55, Paul Wouters wrote: > But we are unfortunately waiting on the ISE :/ I hope not for too long, given the TLS WG more or less sent this to the ISE. I haven't read the draft that is the original topic of this thread yet, but a quick comment on the tls-dnssec-chain draft. It was submitted to the ISE on December 17th, and acknowledged as received and processing a month later. No updates since then. I'll ping the ISE to see what the current status is. Shumon. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
