draft-bortzmeyer-dprive-resolver-to-auth-01: authenticating nameserver names

[TomTervoort]

I have a small remark about section 2 of draft-bortzmeyer-dprive-resolver-to-auth-01: it states that a resolver should use the domain name of the name server to construct TLSA queries. However, it doesn't specify a requirement for the resolver to verify the authenticity of the name.

Section 1 states that this name is "obtained from zone delegation", which I assume to mean it is taken from the NS record of the parent nameserver. This, however, would allow a man-in-the-middle attack (even in strict mode) when the parent server does not support TLS, but the child server does. This is because DNSSEC does not require the parent server to provide signatures along with delegation records, so an attacker could alter the name contained within NS records.

Assuming the nameserver of example.com supports encryption, such an attack could work as follows:

• The resolver wishes to resolve secret.example.com, and first performs an NS query for example.com to the TLD nameserver, which does not happen to support (authenticated) encryption.
• The attacker substitutes the name ns1.example.com in the reply's NS record with the attacker-owned domain name ns.evil.org. Optionally they could also mess with the glue records.
• The resolver queries the TLSA record at _853._tcp.ns.evil.org.
• The attacker provides their own signed record, or authenticated denial, which they can do because they own evil.org.
• The resolver accepts this and sends the query for secret.example.com to the attacker-controlled nameserver.

A solution would be to require the resolver to query the supposed authoritative nameserver for NS records for example.com and require them to be signed, so the resolver can verify the nameserver name in addition to DANE checking.

This extra check would only be necessary if the nameserver domain name is not in the same zone it is supposed to be authoritative for: so it's fine when ns1.example.com claims authority for example.com, but when the nameserver's name is ns.somethingelse.com, it should be queried for a secure NS record for example.com that explicitly points to ns.somethingelse.com. If the result is bogus/missing/insecure, and the resolver is in strict mode, the resolver should stop querying this nameserver.

I hope this recommendation was helpful.

[bortzmeyer]

If the parent zone is not signed, all bets are off, anyway, an attacker can always redirect you to the name servers of his choice. So, the solution is "do not expect any security when your parent zone is unsigned". (This is a consequence of the fact that DNS is tree-structured and DNSSEC follows this path. You need a trustable parent.)

For your last paragraph, note that some people believe that name servers should always be in the zone they serve, for security and control. (In France, it is in the official recommendations from ANSSI, the national cybersceurity agency.)

[TomTervoort]

If the parent zone is not signed, all bets are off, anyway, an attacker can always redirect you to the name servers of his choice. So, the solution is "do not expect any security when your parent zone is unsigned". (This is a consequence of the fact that DNS is tree-structured and DNSSEC follows this path. You need a trustable parent.)

That's correct. But even a signed parent zone does not need to sign its delegation records. They just need to provide a signed DS record (or authenticated denial thereof). This means that DNSSEC allows attackers to alter nameserver names during delegation (which apparently was not considered to be problematic originally). Section 2.2 of RFC 4035 says the following:

The NS RRset that appears at the zone apex name MUST be signed, but
the NS RRsets that appear at delegation points (that is, the NS
RRsets in the parent zone that delegate the name to the child zone's
name servers) MUST NOT be signed.  Glue address RRsets associated
with delegations MUST NOT be signed.

For your last paragraph, note that some people believe that name servers should always be in the zone they serve, for security and control. (In France, it is in the official recommendations from ANSSI, the national cybersceurity agency.)

I agree. Unfortunately as long as resolvers will accept nameservers that are not in the zones they serve, the attack I described should be possible. The upside is that if the majority of nameserver names are in their own zone, it will rarely be needed to query an additional NS record to verify nameserver name authenticity.

[bortzmeyer]

This means that DNSSEC allows attackers to alter nameserver names during delegation

Yes, but because of the DS record, the responses obtained from the bad name servers will be bogus and therefore rejected by validating resolvers. So this attack cannot be a hijacking, it is "only" a DoS (something the attacker could do in other ways, anyway).

I agree

Not me. Because it makes you depend on glue records, which are one more possible way to error.

[TomTervoort]

This means that DNSSEC allows attackers to alter nameserver names during delegation

Yes, but because of the DS record, the responses obtained from the bad name servers will be bogus and therefore rejected by validating resolvers. So this attack cannot be a hijacking, it is "only" a DoS (something the attacker could do in other ways, anyway).

Ah, I didn't intend to claim this would allow domain hijacking, just a confidentiality violation: an attacker can forward queries to the legitimate authoritative nameserver, and send the correct responses back along with a signature. What the attacker gains is that they can see exactly what subdomains the resolver is querying.

If I understood correctly, when in strict mode, an active man-in-the-middle attacker should not be able to read the queries from a resolver in strict mode to an authoritative nameserver, when both support this mechanism. This attack shows a way an attacker can break this requirement, when the parent (or parent's parent etc.) nameserver does not implement this mechanism itself.

[bortzmeyer]

I do not see a solution for this issue. Authentication of authoritative name servers is much more complicated than authentication of the resolvers because they are many and you don't have a preexisting relationship with them.

[TomTervoort]

DNSSEC requires that authoratative nameservers store a signed NS record that binds them to the zone they serve. Couldn't that be used to validate the name used for nameserver DANE validation? Or is there a reason why this wouldn't work in practice?

[bortzmeyer]

It would require resolvers to be fully child-centric (revalidating the NS RRset they got from the parent) which is a long-standing debate...