Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

[Peter van Dijk <[e-mail]>]

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/