On Mon, Nov 16, 2020 at 2:02 AM Peter van Dijk <[email protected]>
wrote:
> On Sun, 2020-11-15 at 12:40 -0800, Brian Dickson wrote:
> >
> > > > Using TLSA records at _853._tcp.<NS_NAME> in a signed zone provides
> an unambiguous signal to use optionally TLSA, in a downgrade-resistant
> manner.
> > >
> > > Not downgrade-resistant, until NS names in delegations become signed.
> >
> > 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).
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.
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.
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.
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.
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
- 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)
- Many large hurdles to overcome, including standardization,
implementation, and deployment
- May not be offered by all (or even any) TLDs
- Availability of ADoT at TLD servers
- Protects traffic via TLS
- May not be offered by all (or even any) TLDs
- 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
> > So, downgrade-resistant, period.
>
> No.
>
I stand corrected.
Downgrade resistant only if the delegation information is protected (NS
names in particular).
Protecting the delegation NS records against an on-path adversary (between
resolver and TLD) does not have any nice solutions.
Brian
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
