On Tue, 23 Feb 2021, Eric Rescorla wrote:
I wanted to point people to a new draft by Tommy Pauly, David
Schinazi, Chris Wood, and myself that defines a mechanism
for authenticated resolver<->authoritative communication.
At a high level, the design is to use SVCB to indicate that
a given server supports ADo[THQ]. The expectation is that
the SVCB record would be supplied in additional_data along
with the NS records, allowing you to bootstrap to encrypted
transport without incurring additional transport. More details
in the draft, but a few points might be worth fleshing out
here:
https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.html
The idea seems fine. I guess the advantage of SVCB over TLSA is
that you can define the transport, which is a clear advantage
over trying to figure out which transport to try first, or trying
them all at once.
The disadvantage of using SVCB is that, at least for DNSSEC, you
would need to use another lookup to get the TLSA record. But that
is mitigated when using the TLS tls-dnssec extension.
You talk about adding SVCB to the additional data, but in practise
authoritative prefer small lean answers these days to avoid
amplification attacks, so I'm not sure if this is a reasonable
assumption of the future. But I also do not believe 1RTT for
privacy is too much of a price to pay, so I think this is fine.
So I think the cost for DNSSEC authentication is two lookups, but
as these are for the nameservers, and privacy really only works
for nameservers serving very many domains, I do not think this
cost is a big problem. But I do have some concern on this because
for smaller nameservers (eg ns0.nohats.ca serving only a dozen
zones), it will incur and extra cost. And we are seeing search
engines like google now penalizing PageRank based on responsiveness,
so this could actually effect smaller nameservers and push towards
more centralization. But I don't see a way to avoid this.
- The basic assumption is that the transport to the parent [0]
is encrypted, thus preventing attackers from substituting
NS or SVCB [1].
SVCB is not served by the parent right? You mean the substitution
would be in a second step after substituting the NS records?
Although an attacker with those powers can probably more easilly
just redirect IP that the NS records point to, so it does not need
to sit in the middle of the connection to the parent.
And the defense against this is of course verifying any NS record
using the signed DS record at the parent and confirming the records at
the child. This costs an extra lookup but gains you security. Unsigned
child zones are always vulnerable, and I personally find that to be out
of scope to mitigate.
If you are thinking of using tls-dnssec to the nameserver, then
some extra lookups are prevented, which is good. Maybe you can
help the ISE by doing a review of draft-dukhovni-tls-dnssec-chain, as
the ISE is having some trouble trying to get enough expert reviewers.
Note that the draft for tls-dnssec is not
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dnssec-chain-extension
but https://tools.ietf.org/html/draft-dukhovni-tls-dnssec-chain as it is
unfortunately no longer a TLS WG item. We do plan to update the document
based on some feedback of the ISE, but did not make it before the
cut-off.
Paul
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
