27 Srp
2024
27 Srp
'24
14:56
Hi Steve,
some internal discussion reminded me that I forgot to answer to this
topic.
When we implemented RFC 7344 and RFC 8078 back in 2017 we intentionally
omitted this kind of checks that are mentioned in RFC. The reason was
that we wanted to have consistency between channels for accepting
DNSKEY records in the registry. If DNSKEY is submitted via EPP we don't
prevent to publish DS that breaks DNSSEC chain. There may be valid
reasons to do so (tests, DNSSEC failure checkers, etc...) When DNSKEY
is updated via other channel (CDNSKEY) we valued more the consistency
with EPP.
I agree that from another point of view it may be considers as bug and
we will evaluate possibilities how to add some kind of checks as Libor
mentioned.
At the same time, I also think that both RFCs (as title suggest) are
meant for synchronization of DNSKEY with parent and DNS operator should
not abuse this intention.
Based on stats from our registry, it is not uncommon that DNS operators
are using keys with flag 256 as KSKs so preventing to accept such keys
via CDNSKEY would probably break updates for other users.
Regards,
Jaromir
On Tue, 2024-06-11 at 09:23 +0000, Libor Peltan wrote:
Hi Steve, all,
this topic has been also discussed on the multi-signer mailing-list
and OARC Mattermost. As a reminder, the situation is that DS is being
updated (at an already secured delegation point) as a result of
detecting novel CDNSKEY. What I think after those discussions:
1) FRED should not actually care about the Flags field in CDNSKEY
(nor in corresponding DNSKEY). Processing CDNSKEY with Flags 256
(i.e. SEP bit cleared) seems OK. I suspect that your assumption, that
256-flagged CDNSKEY would be ignored, was incorrect.
2) According to RFC 7344, Section 4.1, Bullet "Continuity", FRED
should (it is actually a MUST) check the delegation, if it works with
updated DS. The RFC is pretty vague about the details here. I suspect
that FRED is missing some (or any) such checks and this can be
considered a bug in FRED. There are some viable options what FRED
could check, depending on available codebase (and therefore ease of
implementation):
2a) perform an interative validation of the cild zone's DNSKEY with
the new DS-to-be installed as a trust anchor (this might be easy if
there is an iterative DNSSEC validation tool already part of FRED)
2b) the same as 2a) but validate the child zone's SOA (this might
avoid updating DS when the child zone is wrongly signed itself, dunno
if better or worse)
2c) only check that the DNSKEY corresponding to the DS-to-be is used
to sign DNSKEY in the child zone (this could be easier to implement
as a single-RR validator is only needed, which is already probably
part of FRED due to necessary CDNSKEY-RRSIG validation...)
2d) only check by keytag that the DNSKEY corresponding to the DS-to-
be is used to sign DNSKEY in the child zone (this is the easiest way
possible, only compute the keytag of the accepted CDNSKEY and search
for it in the child's DNSKEY-RRSIG)
(All those options would need to be elaborated, e.g. for the case of
multiple CDNSKEYs (and DSs)....)
Any of those possible bugfixes would prevent what you observed --
accepting a ZSK as an entry point for DS. Note that DNSKEY/CDSNKEY
flags don't play any role here. Nevertheless, the idea of re-
purposing apex CDNSKEYs is IMHO not good.
Libor
_______________________________________________
fred-users mailing list -- fred-users(a)lists.nic.cz
To unsubscribe send an email to fred-users-leave(a)lists.nic.cz