[dd] Re: [DNSOP] delext-12 vs. deleg-12 review

[Libor Peltan <[e-mail]>]

Hi,

I'm delighted that the delext document gained maturity and I'd love to 
see it moving forward.

I also concur with Petr's findings and here are some mine:

1) I feel a lack of proper description of the situation when 
Delegation-Extension-unaware (DE=0) validating resolver queries a name 
at/below NS-Omitting type. It can believe it is a NODATA/NXDOMAIN proof. 
Should it follow section 6.3 despite its unawareness, or should it keep 
believing there is nothing below? In any case, it should be mentioned 
more explicitly in the doc (I guess Petr complained the same in 
different words).

2) From an implementer's perspective, the subranges of the Delegation 
Types range could be rearranged to be more handy:
     - NS Preserving and Private types should be in adjacent ranges (to 
form a single bigger subrange) as they're pretty equal in properties
     - NS-Omitting, NS-Preserving, and Private types should be adjacent 
as well and form a bigger subrange because those share the requirement 
to be present in delegation responses

3) It should be made clear that the DE bit not only signals (commits to) 
Delegation-Extension-awareness, but also DELEG-awareness.

4) Compact Denial of Existence: §4.1.1 seems not precise enough. First, 
it doesn't clearly say that the considerations are regarding queries 
_below_ the non-NS delegation point. Second, it doesn't say how the 
non-NXNAME NXDOMAIN answer should look like (especially, how the "next 
name" field in the NSEC is crafted).

5) First paragraph if Section 4.2 is weird. Isn't it roughly already a 
consequence of other stuff in the document? And anyway, does it really 
say that for qtype=DELEG and qname being a non-existent name (not a 
delegation), the server MUST NOT return NXDOMAIN?? Doesn't it even 
forbid other rcodes like SERVFAIL, FORMERR etc for qtype=DELEG?

6) Queries for type ANY (4.4) is underspecified. Either improve, or 
remove this section whatsoever.

X) In general, I lack enough considerations about DE-rrtypes without 
DNSSEC. Yes, their security properties are obviously weak, but they're 
not forbidden or unuseful. Although not all, most of the paragraphs 
assume DNSSEC.

Y) Question. Assume a hybrid delegation with both legacy NS and 
NS-Omitting DELEG. Within the given Threat Model, should we consider the 
attack surface where for a legacy resolver, the attacker _injects_ a 
malicious DE bit into the resolver's queries, so that the resolver 
obtains cachable de-facto NXDOMAIN proofs of stuff below the delegation? 
I guess the defence is the presence of NSEC which uncovers the existence 
of NS, but this is not mentioned in the doc.

Thanks,

Libor

On 09. 10. 26 15:06, Petr Špaček wrote:
> Hi everyone.
>
> I'm attempting to read both drafts in lockstep before we send it to WGLC.
>
> I feel more people need to do this before we rubber stamp both documents.
>
>
> Here are my notes, ordered by perceived severity:
>
>
> ## DELEG 5.1. Resolvers vs. DELEXT 5.1
>
>> A resolver that is DELEG-aware MUST signal in queries that it 
>> supports the DELEG protocol by setting the DE bit to 1 (see Section 
>> 4). This indicates that the resolver understands the DELEG semantics 
>> and does not need NS records to follow a referral.
>
> I've generalized DELEG to "Delegation-Extension-aware":
> https://github.com/ietf-wg-deleg/draft-ietf-deleg-base/pull/215
>
>
> This highlighted an implicit assumption:
>
> Client which implements DELEXT/DE=1 must also support DELEG. I.e. 
> sending DE=1 while NOT implementing DELEG will cause interop problems 
> because DELEG is in NS-omitting range, so DE=1 client will not see NS 
> anymore.
>
> I guess we need to add sentence or two to both documents saying - if 
> you implement this, implement the other protocol as well.
>
> Future extensions might need to invent their own signal if they want 
> to _replace_ (as opposed to augment) DELEG.
>
> Opinions?
>
> ------------------------------
>
> ## 3.2. NS-Preserving Delegation Types
>
>> The NS-Preserving Delegation Type segment contains types for 
>> delegation mechanisms that are used alongside the existing NS RRset.
>
> I think this is wrong. We don't know what these types might do in 
> future, but I there already were proposals for "DSver2" record type. 
> Such type is equally applicable to NS and DELEG, too.
>
> Besides that, I guess all three NS-Preserving/On-Demand/Private 
> Delegation Types could use something like ~ 'MUST NOT exist on name 
> without NS or a NS-Omitting Delegation Types'.
>
> This is similar to DS: It cannot exist without an actual delegation. 
> (It would open can of worms for DNSSEC.)
>
> Or said yet differently, only NS and NS-Omitting Types create a 
> delegation. The others just ride on that delegation.
>
>
> ## DELEXT 5.3. Algorithm for "Finding the Best Servers to Ask"
>
>> 2.2.2. If a given SNAME is proven to not have NS-Omitting Delegation 
>> Type RRsets but does have an NS RRset, the resolver MUST copy the NS 
>> RRset into SLIST. The resolver MUST process any NS-Preserving or 
>> Private Delegation Type RRsets according to the specification 
>> defining those types.
>
> I think "The resolver MUST process any NS-Preserving or Private 
> Delegation Type RRsets according to the specification defining those 
> types." should get it's own step, like 2.2.3. Now it can be read as if 
> it applies only to cases with fallback to NS, which I don't think was 
> intended.
>
> The same remark applies to 5.2. Referrals:
>
>> NS-Preserving and Private Delegation Type RRsets present in the 
>> referral supplement the delegation information provided by the NS RRset.
>
> I think it can generally apply to all NS-Omitting types as well.
>
> Same for 9.4. Additional Expert Review Criteria:
>
>> A type that supplements the NS RRset should be allocated from the 
>> NS-Preserving segment.
>
> Perhaps "A type that supplements the delegation should be allocated 
> from the NS-Preserving segment." ?
>
>
> Nit in 5.3:
>
>> This is the same recommendation to bound the amount specified in 
>> [RFC1034] Section 5.3.3.
>
> A missing word? "bound the amount of work"?
>
> ------------------------------
>
> ## DELEXT 4.1.1. Compact Denial of Existence
>
>> This document updates Compact Denial of Existence (CDOE) [RFC9824]. 
>> For CDOE enabled servers, the negative response required above is an 
>> exception to the CDOE method, i.e., it MUST be generated as a 
>> conventional Name Error proof ([RFC4035], or [RFC5155] for NSEC3) 
>> rather than as an NXNAME-based NODATA response, and it MUST be 
>> returned regardless of whether the query sets the Compact Answers OK 
>> (CO) flag [RFC9824].
>
> I find this confusing. "Name Error" is defined in 4035 3.1.3 as> Name 
> Error: The zone does not contain any RRsets that match <SNAME, SCLASS> 
> either exactly or via wildcard name expansion.
> I.e. the name does not exist.
>
> What if the QNAME=delegation point? In that case it should be "No 
> Data" with the accurate type bitmap, right?
>
> ------------------------------
>
> ## DELEXT 4. Name Server Requirements
>
>> When the value of the EDNS(0) DE flag is 0, the server behaves as a 
>> server that does not implement this specification, i.e., Delegation 
>> Types are processed as ordinary Data Types.
>
> This needs a clarification. 'Delegation Types' are not entirely 
> ordinary even for DE=0.
>
> On auth side, they still have to cause occlusion of data underneath 
> them, even for DE=0. That's needed so the server can have only a 
> single NSEC chain for the zone, and that's really a design requirement 
> for sane implementation.
>
> (Perhaps mention single-NSEC-chain rule in 6. DNSSEC Requirements, too?)
>
> On the other hand, if auth is configured with both parent and child 
> zones, then for DE=0 query the zone lookup needs to return *child* 
> zone so the generated proof of nonexistence can be validated by 
> unaware client.
>
> On client side, they look like ordinary records, the magic is 
> restricted to auth.
>
> Compare with DELEG sections A.1 and A.4.1.3.
>
> DELEG text around this is in 5.2. Authoritative Servers and 5.2.2 
> needs to carry over to DELEXT.
>
> ------------------------------
>
> ## DELEXT 6.2. Validating a Referral
>
>> When the DNSKEY-ADT flag is set to 1 in any DNSKEY record in the 
>> DNSKEY RRset of the delegating zone, the validator MUST check the 
>> NS-Omitting, NS-Preserving, and Private Delegation Type RRsets in the 
>> Authority section of the referral against the Type Bit Maps of the 
>> NSEC or NSEC3 record that matches the delegated name. If any are 
>> absent, the referral MUST be considered tampered with, and the 
>> response MUST be ignored.
>
> NSEC3 Opt-out is not covered (sic). If none of the types are present 
> at all (i.e. delegation only with NS and nothing else) then there is 
> no "NSEC3 record that _matches_ the delegated name", only a covering 
> NSEC3.
>
> I think we better make this clear.
>
> Secondly:
>
>> If any are absent, the referral MUST be considered tampered with, and 
>> the response MUST be ignored.
>
> Some types might be legally omitted, and what about extra types 
> present in response but not in the bitmap?
>
> I suggest wording like this:
> """
> When the DNSKEY-ADT flag is set to 1 in any DNSKEY record in the 
> DNSKEY RRset of the delegating zone, the validator MUST check the 
> Delegation Type RRsets in the Authority section of the referral as 
> follows:
>
> - If an NSEC or NSEC3 RR matching the delegated name is present, the 
> set of NS-Omitting, NS-Preserving, and Private Delegation Types 
> present in the Authority section MUST be equal to the set of these 
> types in its Type Bit Maps field. On-Demand Delegation Types are 
> disregarded in this comparison.
>
> - If the delegated name is covered by an NSEC3 RR with the Opt-Out 
> flag set ([RFC5155] Section 8.9), the Authority section MUST NOT 
> contain any Delegation Type RRsets.
>
> - Otherwise, the referral lacks the required proof.
>
> If any of these checks fails, the referral was tampered with.
> """
>
> I also omitted the trailing "response MUST be ignored" because that's 
> not what resolvers actually do. They act in an implementation defined 
> way, but generally not "ignore" it.
>
>
> Thirdly:
> This triggered a thought that we did not mention TC=1 handling 
> anywhere. I think it can be reasonably derived from existing spec, 
> just saying it out loud in case people feel differently.
>
> ------------------------------
>
> ## DELEXT 6.4. Insecure Delegation Proofs
>
>> Alternatively, the validator must make sure that the delegation with 
>> an NS record is covered by an NSEC3 RR with the Opt-Out flag set.
>
> I suggest adding word "only", e.g.:
> Alternatively, the validator must make sure that the delegation with 
> only an NS record is covered by an NSEC3 RR with the Opt-Out flag set.
>
> Just to make less likely someone will read this incorrectly.
>
> ------------------------------
>
> ## DELEXT 4.1. Including Delegation Types in a Referral Response
>
>> For DNSSEC-signed zones, the response MUST include DNSSEC proof of 
>> the existence or non-existence of Delegation Type RRsets at the 
>> delegated name.
>
> I guess it should say "For DNSSEC-signed zones and queries with DO=1," 
> at the beginning. Or reference RFC 4035 section 3.1 which explains 
> this, maybe.
>
> ------------------------------
>
> ## DELEXT 4.2. Explicit Queries for Delegation Types
>
>> When the DE flag is set to 1, a query for a Delegation Type MUST 
>> result in an authoritative answer if the queried Delegation Type 
>> exists, or a NODATA response (AA flag set, RCODE=0, empty answer 
>> section).
>
> I would add a sentence to clarify this section applies only to 
> "QNAME=delegation point" queries. If QNAME is longer then response can 
> also be referral, NXDOMAIN etc.
>
> ------------------------------
>
> ## DELEXT 4.3. Queries for type ANY
>
>> Queries for type ANY where the QNAME matches a delegation point with 
>> Delegation Types present MUST behave the same way as if a DS record 
>> was present at the delegation point.
>
> I think we misunderstood each other when we discussed this in Vienna. 
> The ask is: Special handling of Delegation Types for QTYPE=ANY should 
> be consistent with special handling already implemented for DS. 
> (Either implementation omits it, or includes it - but please please 
> make it consistent for all parent-side types incl. DS.)
>
> ------------------------------
>
> ## DELEG 5.2.1.2. DELEG-aware Clients with NS RRs Present but No DELEG 
> RRs
>
>> According to specification in [I-D.ietf-dnsop-delext], if the 
>> delegation does not have a DELEG RRset, the authoritative server puts 
>> the NS RRset into the authority section of the referral.
>
> Generalized to range:
> https://github.com/ietf-wg-deleg/draft-ietf-deleg-base/pull/214
>
> ------------------------------
>
> ## DELEXT 3.5.1. Criteria for Delegation Type Allocation
>
>> The RR type carries information associated with the delegation that 
>> is intended to be processed by a resolver.
>
> I suggest generalizing to mere "information associated with the 
> delegation" period. I think On-Demand Delegation Types might see 
> non-DNS usage as well. Made up examples: DBOUND, maybe a new flavor of 
> CAA, perhaps parent-side RP-equivalent so you can contact domain admin 
> if the delegation is down etc. (BTW this might be a nice use for DNS 
> Error reporting - right now it cannot report that all auths seem to be 
> down, but if it were in parent it could ...)
>
> ------------------------------
>
> ## DELEXT 5.1. The EDNS(0) DE Flag
> Nit:
> The diagram and bit definition appears only in section 5.1 but the bit 
> is referenced already from section 4.
>
> ## DELEXT 6.1. The DNSKEY-ADT Flag
>
>> The DNSKEY Flags field for Authoritative Delegation Types (ADT) 
>> consists of 16 bits shown in Figure 2.
>
> Huh, I find this formulation really weird. Perhaps something like this?
>
> "The DNSKEY Flags field consists of 16 bits shown in Figure 2. The 
> Authoritative Delegation Types (ADT) flag is bit 14."
>
> ------------------------------
>
> ## DELEXT 4.1. Including Delegation Types in a Referral Response
>
>> The server SHOULD include the Delegation Extension Required INFO-CODE 
>> 34 ("New Delegation Only") Extended DNS Error [RFC8914] specified in 
>> [I-D.ietf-deleg] absent a local policy requiring otherwise.
>
> "the Delegation Extension Required" looks like leftover from previous 
> version. The registered name is "New Delegation Only".
>
> BTW deleg draft is now referenced as Informative but this reference 
> probably upgrades it to normative, I think?
>
> ----------
>
> ## DELEG examples
>
> I've noticed numerous errors and fixed them:
> https://github.com/ietf-wg-deleg/draft-ietf-deleg-base/pull/217
>
> I feel there must be more!
>
>
> Congratulations if you made it this far. Now, where's YOUR review?!
>