Re: [DNSOP] Updating RFC 7344 for cross-NS consistency

[Peter Thomassen <[e-mail]>]

On 6/28/22 02:56, Paul Wouters wrote:
>> Does the WG think this is a reasonable thing to pursue?
> 
> I think this could be an excellent super short RFC that Updates: 7344.
Reading RFC 7344 more closely, I stumbled upon this paragraph in Section 4.1:

    o  Signer: MUST be signed with a key that is represented in both the
       current DNSKEY and DS RRsets, unless the Parent uses the CDS or
       CDNSKEY RRset for initial enrollment; in that case, the Parent
       validates the CDS/CDNSKEY through some other means (see
       Section 6.1 and the Security Considerations).

This is commonly taken to mean that "Like DNSKEY records, CDNSKEY and CDS records must be signed by the zone’s KSK" (https://blog.apnic.net/2020/01/17/sha-1-chosen-prefix-collisions-and-dnssec/).

However, strictly speaking: the above provision allows that the key that signs CDS/CDNSKEY records is in the DNSKEY rrset, and referenced by a DS record, but does *not* sign the DNSKEY (i.e. is not a KSK).

This is legal iff the zone has (another) KSK of the same algorithm that is also referenced in a DS record (see last paragraph of RFC 4035 Section 2.2).

The situation would amount to pre-publishing a spare KSK in DNSKEY and DS without using it for signing; then, begin its use inside the zone with an RRSIG over CDS/CDNSKEY. But when making the key available for signing CDS/CDNSKEY, it could also sign DNSKEY, turning it into a full-fledged KSK. -- It's not clear to me what could be the motivation for this edge case, where the CDS/CDNSKEY signing key has a corresponding DS record, but does not sign DNSKEYs.

Perhaps it is just unfortunate phrasing in RFC 7344, and the authors simply intended to say that CDS/CDNSKEY must be signed by a KSK? (And then, it would make sense if it were signed by a KSK of each algorithm!)

What do you think about these aspects? In the short update RFC, do you think they would be worth clarifying?

Thanks,
Peter

-- 
https://desec.io/