preventing downgrade attacks

[RoyArends]

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.

[bemasc]

Re 1: I think we should probably call this the "NSEC(3) referral flag", with the promise being "any secure delegation will be accompanied by an NSEC(3) record". Details aside, my point is that if we decide to add new RR types to delegation points in the future, they should also be protected by this flag.

[RoyArends]

Good point! That makes the flag more generic and future proof. If the flag is set, expect authenicated denial in a referral. Always.

[peterthomassen]

Re 2:

A disadvantage is that this is NOT what the DS record was meant to do, i.e. Yet Another Hack.

We can change what the DS record is meant to do; my take is that it might be OK if done "minimally invasive" (= without risking yet more hacks in the future).

The desire for delegation-specific flags controlled by the parent has come up a few times:

• DELEG signaling as discussed here
• Parent signaling some kind of organizational (non-)boundary (--> DBOUND?)
• DNSSEC multi-algorithm validation policy (AND vs OR in multi-signer setups with several algorithms)

Obviously, all of that is tentative; other use cases are also conceivable. Alas, the DS record (unlike the DNSKEY record) has no flags, which seems like an omission.

By reserving a hash digest number and repurposing the keytag+algorithm fields, one obtains 24 bits that can be used as flags.

I think we should ponder whether it's time to address this gap once and for all, by adding this signaling capability as a generic mechanism, which DELEG then can build on.

(One might reply that once DELEG is there, delegation-specific signaling can be done via DELEG parameters. At least for the second use case above, that's not the case though. Who knows what the future will bring.)

[bemasc]

Are you saying that DELEG can't be used for DBOUND? I don't see why not. I can certainly imagine a DELEG parameter indicating whether the delegation is "in house", or perhaps conveying even richer metadata about the organizational relationship.

[peterthomassen]

Are you saying that DELEG can't be used for DBOUND?

No, I'm not saying that.

My point was that a signaling mechanism would be a nice thing to have in various situations, not only for protecting DELEG against downgrade. I was trying to widen the scope of the discussion to see if thinking about a more general signaling solution would be worthwhile (instead of inventing one for DELEG downgrade protection and another one for another purpose).

I can certainly imagine a DELEG parameter indicating whether the delegation is "in house"

Maybe, maybe not. There may be multiple DELEG records, e.g. in a multi-provider setup. What are the implications of (not?) having to repeat this parameter in each of them?

[pspacek]

My preference is a new DNSKEY flag with a twist: Explicitly specified behavior that presence of this new flag in any DNSKEY present on zone apex turns on new behavior in (i.e. even a single DNSKEY with this flag).

The main reason is that it gives operators direct control over the flag and ability to react quickly when something goes wrong in the initial rollout.

• changing the flag does not require coordination with parent/registry
• DNSKEY can have short TTL before the flag get flipped, TTL is under operator's control
• because flag=1 in a single DNSKEY is enough the operator does not have to change existing DNSKEYs at all!
  • For the initial rollout the operator can introduce a dummy DNSKEY like example. DNSKEY 1024 0 251 (1024 being the new flag value, with no key blob, and with intentionally unknown algorithm).
  • This dummy DNSKEY now acts only as flags container and nothing else, and old validators will just ignore it.
  • This dummy DNSKEY can be easily pulled back when needed without doing key rollover etc.
  • If the operator is comfortable with the new behavior the flag can get incorporated into regular KSK and/or ZSK on operator's schedule and then then dummy DNSKEY can be dropped

I sort of agree with #19 (comment). It should apply to all new parent-side types (e.g. like https://www.ietf.org/archive/id/draft-peetterr-dnsop-parent-side-auth-types-00.txt)