Hi Paul,
On 5/17/24 20:45, Paul Wouters wrote:
# Section 2
OLD
The DS enrollment methods described in Section 3 of [RFC8078] are
deprecated and SHOULD NOT be used. Child DNS operators and parental
agents who wish to use CDS/CDNSKEY records for initial DS enrollment
SHOULD instead support the authentication protocol described in
Section 4 of this document.
NEW
The DS enrollment methods described in Section 3 of [RFC8078] are
less secure than the method described in Section 4 of this document.
It is therefore RECOMMENDED that Child DNS operators and parental
agents who wish to use CDS/CDNSKEY records for initial DS enrollment
instead support the authentication protocol described here.
I would remove the word "instead", as it now doesnt deprecate it.
Otherwise okay.
OK. This leads to the confusing constellation "for initial DS enrollment support", where
"support" looks like a noun but is a verb. I thus restructured the last sentence
equivalently as follows:
NEW
The DS enrollment methods described in Section 3 of [RFC8078] are
less secure than the method described in Section 4 of this document.
Child DNS operators and parental agents wishing to use CDS/CDNSKEY
records for initial DS enrollment SHOULD therefore support the
authentication protocol described here.
That adds significant complexity, to defend against a scenario that is simply "part of
life" in the DNSSEC security model ("there is no way to defend against the parent").
We will leave it to dnssec transparency logging to find "deep signs"....
;-)
Thus: Would it address your concern if we said that QNAME minimization is
REQUIRED or RECOMMENDED for resolving signaling records? (Which of the two?)
Let's leave it out for now. Or if you want you can add it as
RECOMMENDED, but I think then you'd also need to talk a bunch about
starting from an empty cache and stuff, so I would leave it out
completely.
Section 5.2 (parent-side operational considerations) already says that it is
"RECOMMENDED toperform queries into signaling domains with an (initially)
coldresolver cache", so it actually fits well.
I used the opportunity to replace "cold" with "empty" (avoiding jargon), and
added right after:
NEW
It is also RECOMMENDED to use QNAME minimization [RFC9156] when
resolving queries for signaling records, to guard against certain
attacks (see Section 6).
In Section 6 (security considerations), I then added:
NEW
If QNAME minimization [RFC9156] is not used when querying for
signaling records, an upstream parent of a signaling domain will see
those CDS/CDNSKEY queries and could respond with an authoritative
answer signed with its own key, instead of sending the referral.
Enabling QNAME minimization reduces the attack surface for such
forgery.
What do you think?
OLD
CDS/CDNSKEY records and corresponding signaling records MUST NOT be
published without the zone owner's consent. Likewise, the child DNS
operator MUST enable the zone owner to signal the desire to turn off
DNSSEC by publication of the special-value CDS/CDNSKEY RRset
specified in [RFC8078] Section 4. To facilitate transitions between
DNS operators, child DNS operators SHOULD support the multi-signer
protocols described in [RFC8901].
NEW
It is possible to add CDS/CDNSKEY records and corresponding signaling
records to a zone without explicit knowledge of the domain owner. To
spare domain owners from being caught off guard by state changes
induced by this practice, Child DNS operators doing so are advised to
make this transparent.
Maybe add: ", for example by notifying the domain owner via email".
Mmh, I find this quite prescriptive ("a priming example"). It could also be
done as an info box when you create the zone (perhaps you can untick a box to disable),
or as an advertised feature when you book the plan. Those approaches seem favorable,
because they are ahead of time (before it actually happens), while a notification is
after the fact.
Now, I'm not sure whether we should go into elaborating on all of this; but *if* we say
something, I feel we should mention one of the "ahead-of-time" ways. I'd be
curious to know what you think of this.
When transferring a zone to another DNS operator, the old and new
child DNS operators need to cooperate to achieve a smooth transition,
e.g., by using the multi-signer protocols described in [RFC8901]. If
all else fails, the domain owner might have to request the removal of
all DS records (e.g., by using the special-value CDS/CDNSKEY RRset
specified in [RFC8078] Section 4) and have the transfer performed
insecurely (see [I-D.hardaker-dnsop-intentionally-temporary-insec].)
If the current DNS hoster does not cooperate, It would not let you use
CDS/CDNSKEY,
so I wouldn't mention 8078.
There's an assumption here that I don't share. It's rooted in the fact that it's very unclear what
"not cooperate" means. Does it mean "not doing multi-signer transitions"?
I suppose many DNS hosters are not aware of multi-signer and its intricacies,
and wouldn't dare such a setup until we come up with good automation schemes.
(That gap is on us to fix.) But until that's there, a DNS hoster trying to
cooperate may much more easily support CDS-delete.
But, should they? Isn't disabling DS the wrong thing to do? Well, the domain
owner may have good reasons (they're not for us to judge), and in a properly
automated environment, it should never be necessary to have a manual
interaction with the registrar about DS.
So it seems reasonable to me that if you can turn something on without a human
reaching out to the registrar, you should also be able to turn it off the same
way. That also helps with cases where the domain owner hadn't agreed, and the
operator provisioned DS records accidentally etc.
Finally, there are cases where cooperation doesn't get you where you want.
Consider the following scenario: Moving from a DNS hoster that only does one
algorithm to a hoster that only does another one (e.g., 8 vs. 13). Even if both
want to cooperate, a valid multi-signer setup can't be constructed (because it
would require announcing both algorithms via DS, which is illegal as long as
they can't sign the zone with both algorithms [0]).
In this case, one might want to go insecure for a brief period (although that
would of course be a very suboptimal thing to do; OTOH, asking one provider to
implement the other's algorithm has near zero hopes to succeed). Using RFC 8078
CDS-delete would spare the domain owner from having to touch the registrar's DS
interface, which I think is the right design.
[0]: In this context, Section 2.2 of
https://datatracker.ietf.org/doc/draft-huque-dnsop-multi-alg-rules/ offers a
solution that I think should be advanced.
So I believe with this we addressed all concerns, and if a new draft is
published I will update by DISCUSS ballot to Yes.
Thanks. I'll hold off with the submission in case you'd like to respond.
Otherwise, I'm planning to upload a new revision on Monday.
Cheers,
Peter
--
https://desec.io/
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
