On Tue, 2020-05-19 at 11:46 -0400, Paul Wouters wrote: > On Tue, 19 May 2020, Peter van Dijk wrote: > > > The draft is managed on GitHub in .md format at > > https://github.com/PowerDNS/parent-signals-dot/tree/master/draft-vandijk-dprive-ds-dot-signal-and-pin > > We first added the KEY RRTYPE in the 1990's to allow generic public > keys in DNS. Then the DNS (and CA) people got upset at the KEY record > being used for something else than securing DNS. So KEY was obsoleted > for DNSKEY that signified it is for DNSSEC only.
And we are forever stuck with a '3' that I keep forgetting the meaning of :) > This draft now tries to shoehorn a TLS key into the DNSKEY record. > > A much cleaner solution would be to use a proper TLSA record. If you > want to signal securely within DNSSEC that encrypted DNS is available, > use a DNSKEY flag on the existing DNSKEYs to signal that (similar to > the DELEGATION_ONLY flag). You only need 1 bit and TLSA records - which > are port specific - can be used to signify presence of DoT or DoH. Or > if you want to support both on port 443 for middleware circumvention, > you can use _dot and _doh prefixed (eg _443._dot.nohats.ca IN TLSA <blob> As I remarked in my reply to Jeremy, I spent quite some time thinking about how to do the signalling&pinning with actual TLSA records, but I never ended up with a satisfactory solution. https://github.com/PowerDNS/parent-signals-dot/blob/master/README.md has some terse notes on fitting TLSA to this problem. Perhaps we should add similar notes to the draft in a not-for-publication section? For your specific proposal, how would I see the DOT_TLSA flag on the nohats.ca DNSKEY without first querying for that DNSKEY over a plain text connection to your name servers? Also, as Petr pointed out, our DNSKEY/DS-based proposal does not involve additional queries and thus roundtrips; as far as I can imagine, anything using TLSA would need extra queries. > The TLSA records can also be of different types, so you can pin the TLSA > record to a pubkey, certificate or specific CA. This would allow the DoH > or DoT maintainer to change/update their keys witout needing to update > or have access to the DNSSEC signer to update the DNS. In our 'emulation' (or perhaps re-syntaxing) of TLSA, we explicitly chose to only map TLSA Certificate Usage 3, because all other forms require that you are confident about the name of the remote end you are connecting to. As delegation NS records are not signed, those usages would be susceptible to attack if the TLSA records are not somehow tied to both the delegated domain name -and- the names of its name servers. '_443._dot.nohats.ca' (ignoring, for a moment, that it lives in the child zone and thus is not available when the resolver needs it for safely connecting to the nohats.ca name servers) does not tie itself to the names of the name servers, and thus cannot support anything other than TLSA Certificate Usage 3. Of course, I've had to read between the lines of your proposal a bit, as it was specified very tersely. If you, or somebody else, comes up with a fully fleshed out proposal based on TLSA, I would be very interested in reading it! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
