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/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
