Roy Thanks for this ! at first read it looks good. Also thanks for adding in the Operational Consideration and section 2.1.
I take it you plan to push a new document update when last call is over? thanks tim On Mon, May 4, 2026 at 7:39 PM Roy Arends <[email protected]> wrote: > Hi Tim, > > I’ve just now added a security section: > > 6. Security Considerations > > This section discusses the security properties of the mechanisms > defined in this document, identifies attack surfaces, and describes > the mitigations provided or required. > > 6.1. Threat Model > > The threat model assumed by this document includes an on-path > attacker capable of intercepting, modifying, dropping, and injecting > DNS messages in transit between a resolver and an authoritative name > server. Off-path attackers capable of response forgery (e.g., via > birthday attacks on UDP) are also considered. Attackers may attempt > to cause a resolver to use unencrypted transport, to resolve names > incorrectly, or to be denied service entirely. > > 6.2. Downgrade Attacks > > 6.2.1. Stripping of Delegation Types from Referrals > > An on-path attacker may remove Delegation Types and associated NSEC > or NSEC3 records from a referral response, leaving only unsigned NS > records. A resolver that accepts such a modified referral would > proceed to resolve the delegated name using unencrypted transport, > defeating the purpose of Delegation Types such as those indicating > encrypted transport parameters. > > The DNSKEY-ADT flag defined in Section 5.1 provides a mitigation > against this attack for validating resolvers. When the ADT flag is > set in any DNSKEY of the delegating zone's DNSKEY RRset, a validating > resolver MUST verify that the referral contains NSEC or NSEC3 records > proving the presence or absence of Delegation Types for the delegated > name. A referral lacking this proof MUST be treated as tampered with > and MUST be ignored. > > This mitigation is effective only when all of the following > conditions hold: > > * The delegating zone is signed with DNSSEC. > * The ADT flag is set in the delegating zone's DNSKEY RRset. > * The resolver performs DNSSEC validation. > * The resolver enforces the ADT requirement as specified in > Section 5.2 > > Operators of zones that publish Delegation Types MUST set the ADT > flag in their DNSKEY RRset to ensure that validating resolvers can > detect this form of tampering. Zones that have not set the ADT flag > provide no cryptographic protection against this attack. > > 6.2.2. Stripping of the DE Flag from Queries > > The DE flag is carried in the EDNS(0) OPT record of query messages > sent by resolvers. An on-path attacker may remove this flag from a > query before it reaches the authoritative name server. A server that > receives a query with DE clear will respond without Delegation Types, > returning NS records only. > > However, when the ADT flag is set in the delegating zone's DNSKEY > RRset, a validating resolver expects that NSEC or NSEC3 proof of > Delegation Types MUST accompany any referral from that zone. This > obligation is established by the DNSKEY, not negotiated per-query via > the DE flag. Consequently, a referral response lacking the required > NSEC or NSEC3 records MUST be rejected by a validating resolver, > whether or not the DE flag was stripped from the outgoing query. In > this case, the ADT mechanism defeats the DE-stripping attack. > > This mitigation is subject to the same conditions as those listed in > Section 6.2.1: the delegating zone must be signed, ADT must be set, > and the resolver must validate. In the absence of these conditions, > no cryptographic protection against DE-flag stripping is available, > and the considerations in Section 6.5 apply. > > 6.2.3. Interaction Between Flag Stripping Attacks > > The two downgrade attacks described above may be attempted in > combination. An attacker who strips the DE flag from a query causes > the authoritative server to respond with NS records only and no > Delegation Types. Without Delegation Types in the response, the > resolver cannot apply the NS-ignoring rule defined in Section 3.2, > and would ordinarily follow the NS records to resolve the delegated > name, potentially over unencrypted transport. > > As described in Section 6.2.2, the ADT flag defeats this combined > attack for validating resolvers in zones where ADT is set. The > resolver's obligation to require NSEC or NSEC3 proof derives from the > previously validated DNSKEY RRset, not from the contents of the > referral itself. A referral containing only NS records, with no NSEC > or NSEC3 proof, will be rejected regardless of whether Delegation > Types were present. > > The residual risk in both Section 6.2.2 and this section therefore > reduces to the same condition: zones in which ADT is not set, or in > which DNSSEC is not deployed, provide no cryptographic protection > against either attack. This is a deployment risk, addressed in > Section 6.5. > > 6.3. Injection of Delegation Types > > Section 3.2 specifies that when Delegation Types are present in a > referral response, accompanying NS records MUST be ignored. An > attacker capable of injecting or forging a referral response could > exploit this rule by introducing a fabricated Delegation Type into > the response, causing the resolver to ignore legitimate NS records > and use only the attacker-supplied Delegation Type, which may point > to an attacker-controlled server. > > This attack is mitigated by DNSSEC. In a DNSSEC-signed zone, > Delegation Type RRsets MUST be signed as specified in Section 5. A > validating resolver will reject responses containing unsigned or > incorrectly signed Delegation Types. > > In unsigned zones, no cryptographic protection against this attack is > available. > > 6.4. Denial of Service via NXDOMAIN for Legacy Resolvers > > Section 4.1 specifies that when the DE flag is clear and no NS > records exist for a referral, the authoritative name server SHOULD > return a Name Error (NXDOMAIN) response. This behavior is intended > to prevent a legacy resolver from exhausting other authoritative > servers for information it cannot act upon. > > An attacker may attempt to exploit this behavior by stripping the DE > flag from a query directed at a zone that publishes only Delegation > Types and no NS records, causing the server to return NXDOMAIN for a > name that legitimately exists. > > However, a resolver that set the DE flag expects NSEC or NSEC3 proof > in any NXDOMAIN response, demonstrating that the queried name does > not exist or that no Delegation Types are present at or above it. A > bare NXDOMAIN response lacking such proof is therefore detectable by > a validating resolver. When the ADT flag is set in the delegating > zone's DNSKEY RRset, the resolver MUST reject an NXDOMAIN response > that does not include the required NSEC or NSEC3 records, as the > absence of proof indicates tampering. > > As with the attacks described in Section 6.2, this mitigation depends > on the delegating zone being DNSSEC-signed, ADT being set, and the > resolver performing validation. In zones where these conditions do > not hold, a DE-stripping attack may result in an NXDOMAIN response > that the resolver cannot distinguish from a legitimate one, causing a > denial of service for the queried name. This residual risk is > addressed in Section 6.5. > > Authoritative servers SHOULD include an Extended DNS Error [RFC8914] > code in NXDOMAIN responses returned when the DE flag is clear and no > NS records exist, to assist in diagnosing misconfiguration or attack. > > 6.5. Partial Deployment and Transition Risks > > The mechanisms defined in this document are effective only when > deployed end-to-end. During the transition period in which some > resolvers, authoritative servers, and zones have adopted this > specification and others have not, a number of residual risks apply. > > The ADT flag provides protection against the downgrade attacks > described in Section 6.2 only when the delegating zone is DNSSEC- > signed, ADT is set in the zone's DNSKEY RRset, and the resolver > performs validation. In zones that publish Delegation Types but have > not set ADT, or that are not signed, no cryptographic protection > against referral-stripping or DE-flag-stripping attacks is available. > > Zone operators that publish Delegation Types in signed zones are > REQUIRED to set the ADT flag upon deployment. Zones relying on > Delegation Types for security properties such as encrypted transport > MUST be DNSSEC-signed. > > Warmly > > Roy > > > > > On 4 May 2026, at 21:02, Tim Wicinski <[email protected]> wrote: > > > > Hi > > > > I had a question on the "Security Considerations" section > > > > This section discusses security considerations, including downgrade > > attacks and resolver behavior. Further details will be added. > > > > Do we have any idea when this will come together? > > > > thanks > > > > tim > > > > > > On Thu, Apr 23, 2026 at 3:53 PM Ondřej Surý via Datatracker < > [email protected]> wrote: > > Dear dnsop WG, > > > > the authors of the document said the document is ready for the WGLC > > and the dnsop WG chairs have considered the discussions on the mailing > > list and the state the document and we consider the document to be > > ready for the WGLC. Hence this message starts a WG Last Call for: > > draft-ietf-dnsop-delext-02 > > > > This Working Group Last Call ends on 2026-05-07 > > > > Abstract: > > The Domain Name System (DNS) protocol permits Delegation Signer (DS) > > records at delegation points. This document describes modifications > > to the Domain Name System (DNS) protocol to permit a range of > > resource record types at delegation points. These modifications are > > designed to maintain compatibility with existing DNS resolution > > mechanisms and provide a secure method for processing these records > > at delegation points. > > > > File can be retrieved from: > > > > Please review and indicate your support or objection to proceed with the > > publication of this document by replying to this email keeping > [email protected] > > in copy. Objections should be explained and suggestions to resolve them > are > > highly appreciated. > > > > Authors, and WG participants in general, are reminded of the Intellectual > > Property Rights (IPR) disclosure obligations described in BCP 79 [1]. > > Appropriate IPR disclosures required for full conformance with the > provisions > > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > > Sanctions available for application to violators of IETF IPR Policy can > be > > found at [3]. > > > > Thank you. > > > > [1] https://datatracker.ietf.org/doc/bcp78/ [datatracker.ietf.org] > > [2] https://datatracker.ietf.org/doc/bcp79/ [datatracker.ietf.org] > > [3] https://datatracker.ietf.org/doc/rfc6701/ [datatracker.ietf.org] > > > > The IETF datatracker status page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-delext/ [ > datatracker.ietf.org] > > > > There is also an HTML version available at: > > https://www.ietf.org/archive/id/draft-ietf-dnsop-delext-02.html [ > ietf.org] > > > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-delext-02 [ > author-tools.ietf.org] > > > > _______________________________________________ > > DNSOP mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
