fl1ger/deleg

Extensible Delegation for DNS

deleg's Issues

preventing downgrade attacks

A DELEG compliant, authoritative nameserver will include signed DELEG records, or authenticated denial of DELEG records. However, an adversary can remove these records from a response, and the resolver will treat the response as a legacy response, since there is no signed indication that DELEG or its authenticated denial should have been present.

Two methods of signed indication have been proposed.

1. DNSKEY flag.

The DNSKEY RR contains a 16 bit flag field in the RDATA. Of these, 3 have been allocated. The ZONE, REVOKE and Secure Entry Point (SEP) flag. Trivially, a fourth can be added, such as a DELEG flag. A validating resolver that observes a DELEG flag MUST expect either a signed DELEG record in a referral, or an authenticated denial record in a referral.

Advantage of this method is that it requires no additional space in a response for the signed indication.
A potential disadvantage is that state needs to be kept between observing the DELEG flag and parsing a response.
A potential disadvantage is that legacy validators may not understand the DELEG flag and ignore the key completely. That behavior is NOT standards compliant. This needs to be tested.

2. DS record.

The DS record contains a digest field. If the validator does not recognise the digest field value, then the DS record should be ignored. This protects legacy validators from failing over unknown DS records, and in addition, it can be used as an indicator that a DELEG or its denial should be present.

Advantage of this method is that it is "legacy validator safe" (but must be tested regardless) and that the resolver doesn't have to look at the key, since the signal is in the reponse.
A disadvantage is that this is NOT what the DS record was meant to do, i.e. Yet Another Hack.
A disadvantage is that it causes yet another record in a response that already contains NS, DS, DELEG/NSEC/NSEC3 and RRSIGs.

Can AliasMode RRs have parameters?

The current text has no examples of priorty=0 with parameters, but it doesn't explicitly forbid that. Is there a reason to allow ipv4hint or ipv46hint with aliasing?

I'm not saying we should prohibit parameters for AliasMode, because there might be later parameters that could affect aliasing that we haven't thought of yet (or I could be wrong and there is a reason to have ipv4hint or ipv46hint with aliasing). But we should document what we know now.

"sharedds" doesn't support validating stubs

A non-DELEG-aware ("legacy") validating stub can only use records that carry a non-DELEG DNSSEC signature chain. This seems to be incompatible with the "sharedds" mechanism proposed in the DNSSEC draft.

It's also unclear how to construct a DELEG-aware validating stub, as DELEG records are not presently passed to the stub at all.

At present, I think the result is that any query to a recursive resolver with DO=1 would require the resolver to skip any DELEG records with "sharedds", and would create some very complicated caching questions. This seems like bad news for "sharedds".

What to put in the SNI when DANE is not in use

When using DoT/DoQ/DoH, but not using DANE (no TLSA records or TLSA SvcParams), what SNI do we use? i.e. what is the Authentication Domain Name (ADN).

If DELEG follows the usual SVCB behavior, the ADN is the "apex name", and the nameserver must use a TLS certificate that covers this name (whether or not any AliasMode records appeared in the chain). However, this is very awkward for operational delegation scenarios: most businesses would not want to hand their DNS operator a valid certificate to impersonate their apex domain, enabling a trivial MITM attack (and bypassing Certificate Transparency protections!). Even in self-hosted infrastructure, using the high-value apex certificate in the DNS server may be difficult.

When DANE is in use, this problem is avoided because, in DANE modes where the ADN exists, the ADN is determined by the final TargetName, not the original owner name (as specified in SVCB-DANE).

There are many possible behaviors. The ADN could be:

1. The DELEG TargetName
2. The DELEG TargetName if DELEG is signed, otherwise the apex name.
3. The TargetName of the last securely resolved DELEG or SVCB record in the resolution chain, or the apex name if none are signed.
4. The apex name, coupled with a new X.509 Key Usage meaning "DNS authoritative nameserver".
5. A name explicitly specified in a SvcParam.

Generate gh-pages

https://github.com/martinthomson/i-d-template allows to easily create gh-pages of the documents, making them available in both .txt and .html format and viewable as HTML via github pages. For example: https://martinthomson.github.io/i-d-template/sample.html

This makes reading the document easier, but the repo also comes with a bunch of tooling/linting enforcement that will help keeping the document syntax valid. It will also make the workflow with IETF datatracker smoother.

I am not sure how this repo was created, but it would be nice to be able to generate the GH pages for it.

I gave a try on my repo and generated the GH pages.
index
deleg draft

using this branch: https://github.com/chantra/fl1ger-deleg/commits/fix_md_formats/

There is 2 commits there.

1. chantra@b986748 is needed to be able to compile the documents properly.
2. chantra@3a85ae6 is quite big and is supposed to set up the repo using martinthomson/i-d-template. The problem is that it would change some existing files like README.md, CONTRIBUTING.md so we cannot just merge this in. I believe this is an artifact that only happen on setup though, so it should be trivial to manually revert the couple of change we do not want.

Explain design decision to use a new RRtype instead of reusing SVCB

One question that has already come up is why a new DELEG RRtype that looks just like SVCB is needed instead of reusing SVCB. A sentence or two near the top of the document would be useful here.

IPv4hint, glue and address mismatches

Assume a signed DELEG record for example.com, with TargetName ns1.example.com and IPv4hint=192.0.2.1
Assume a delegation point NS record for example.com, with an NSDNAME ns1.example.com
Assume a glue address record (served by the server authoritative for .com) for ns1.example.com with address 192.0.2.2
Assume a hostname ns1.example.com with A record 192.0.2.3, in the example.com zone.
example.com is not a signed zone.

The DELEG record contains a signed binding between ns1.example.com and address 192.0.2.1.
All other records can be spoofed by an adversary.

The SVCB specification specifies that when A records for TargetName are locally available, the client SHOULD ignore these hints.

In short, the SVCB instruction here is to "trust" the unsigned "192.0.2.3" or "192.0.2.2" over "192.0.2.1". Experience tells me that there will be mismatches between parent and child records.

The same is true for IPv6, but have left this out to not convolute this example. We need clear instructions and rationale for developers.

Potential DELEG-only NXDOMAIN replay attack.

This is minor, but just wanted to put it out there.

When only a DELEG and Authenticated Denial record exist at a delegation point, and no NS and DS, then a referral response can be replayed as an NXDOMAIN response to legacy validators. However, legacy resolvers can't use this referral anyway, due to the absence of NS records. Ergo, it is highly unlikely that NS records will ever go away.

Nameserver status paradox

If a DNS server is

• Unconditionally authoritative for example.com, AND
• authoritative for foo.example.com via DELEG, but not via NS

what should it serve to a query for foo.example.com/A?

A non-DELEG-aware resolver requires a referral response to the nameserver that is authoritative via NS. A DELEG-aware resolver needs an answer to the question. The authoritative server doesn't know which kind of resolver is asking the question.

This distinction is especially apparent if we imagine that DELEG has overridden the DS record, using a different DS from the one that applies to the NS delegations.

Explicit DELEG queries should work

For the same reason explicit DS records need to work:

DS records are obscured when parent and child are hosted on the same server. Only an explicit DS request can establish a chain of trust. As an example, UK and CO.UK are hosted from the same server set, and explicit DS queries are needed to establish a chain of trust.

This can be made to work in the authoritative server by treating DELEG requests the same way as DS requests.