On Mon, 2020-11-16 at 10:22 -0800, Brian Dickson wrote: > > > That's a moot point. > > > TLSA records MUST be signed, and the TLSA RFC makes this very clear: RFC > > > 6698 section 4.1 (Determining whether a TLSA RRSet can be used MUST be > > > based on the > > > DNSSEC validation state (as defined in [RFC4033]). > > > > Which buys you very little if the name you are looking up is from an > > unauthenticated source - like NS names in delegations. > > > > Ah, okay, now I understand. > > Yes, this is a huge gap in the fundamentals for any privacy architecture > (ADoT), which is rooted in the unsigned nature of NS records regardless of > the security state of a delegation (DNSSEC or not).
Indeed. That's why we designed DOTPIN (whose shortcomings pretty much come from not being NS-centric!) to not rely on those names. > This pretty much impacts any solution that relies on either the names or IP > addresses of authoritative servers (the latter served as glue from the TLD). > An on-path active adversary (between recursive and TLD authoritative server) > would be able to modify these unsigned values. Exactly. A TLSA-authenticated ns1.evil.org does you no good. > Without any way to obtain them with some degree of protection (transport or > data), there is no path to connecting to the correct server initially over > TLS. We could twist this into saying that we can solve the problem by also doing DoT on the root and the TLDs! (But you also mention that below.) > If the domain in question (the delegated domain, not the nameserver > namespace) is DNSSEC signed, it is possible to detect a discrepancy between > the delegation and apex NS records, assuming DNSSEC responses are not blocked > or tampered with. Yes - but by then you've already leaked yourdirtysecrets.com to ns1.evil.org! > If the domain in question is not DNSSEC signed, there is no defense against > such an attacker, if the query to the TLD is not protected by transport or > data security. > However, even in the signed zone case, confirming the apex NS records does > require a query to the authoritative server to verify things, > If the IP address used operates on port 853, there is no guarantee the server > responding is the actual authoritative server rather than an attacker's > server, since the name/IP could have been tampered with initially. Yes (examples given above). > This leads to a few possible conclusions: > * With no changes to the DNSSEC management of TLDs (protocol and > implementations), and with no availability of ADoT to TLD servers, an on-path > active adversary : > * * Can defeat any attempt at privacy (ADoT) for unsigned zones > * * Can at most DOS any privacy mechanism for signed zones Yes and yes. > * The following techniques can alter the prerequisite conditions, each of > which has deployment/operation concerns: > * * Changes to DNSSEC signing of (at minimum TLD) delegation data (NS records > and glue A/AAAA records) I mentioned 'hash of NSSET into DS' in a dprive thread earlier. https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-delegation-information-signer/ does something like this (including glue, which we don't need for our problem). > * * * Many large hurdles to overcome, including standardization, > implementation, and deployment > * * * May not be offered by all (or even any) TLDs I believe DOTPIN (again, with all its shortcomings) has very few hurdles in this area. > * * Availability of ADoT at TLD servers > * * * Protects traffic via TLS > * * * May not be offered by all (or even any) TLDs It's DNSSEC all over again. > * * Eliminating the on-path possibility, by obtaining the TLD zone via > AXFR/IXFR > * * * Protecting the TLD zone transfer is possible by either ZONEMD > signature, or by doing AXFR over TLS > * * * May not be offered by all (or even any) TLDs Last time I checked, TLD operators where not very eager to drop whole zone dumps on the world. Also, some zones are simply too large for this. Ignoring those issues, yes, ZONEMD and/or XoT would solve the on- path problem. > > > So, downgrade-resistant, period. > > > > No. > > I stand corrected. > Downgrade resistant only if the delegation information is protected (NS names > in particular). Indeed, and the privacy properties then still depend on what the NS names (and their IPs) tell you. (Some of that goes for DOTPIN as well, of course). > Protecting the delegation NS records against an on-path adversary (between > resolver and TLD) does not have any nice solutions. I like 'hash of NSSET [in DS]'. Now perhaps you see why I offered these possibly-useful puzzle pieces earlier: * https://tools.ietf.org/id/draft-vandijk-dnsop-ds-digest-verbatim-00.txt * https://tools.ietf.org/id/draft-peetterr-dnsop-parent-side-auth-types-00.txt Both of these make room for non-hashing variants of 'authenticate data that is unsigned today'. :-) (If you'd like to have more puzzle pieces, https://github.com/PowerDNS/parent-signals-dot has some additional semi-rambly thoughts in the area, although most of it has made it into conversations on DPRIVE and DNSOP meanwhile). 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
