On Wed, 15 May 2024, Peter Thomassen wrote:
[ I know this message predates the telechat, but I had no time to process
this before the telechat ]
[ cut everywhere where we agreed ]
I have a few items to discuss and some comments. I'm leaving out the
discussion
of _signal as a name, as this discussion is taking place on dnsop. While I
have
a preference, I'll abide by the consensus call of the dnsop wgchairs.
I requested the chairs to do a consensus call on the matter two weeks ago.
The response was that the document is no longer a WG document, so the chairs
"have no role in this".
Warren as responsible AD has come forward, so this issue is resolved now.
Section 2:
The DS enrollment methods described in Section 3 of [RFC8078]
are deprecated and SHOULD NOT be used.
This was discussed on the IESG telechat today, and I think we had
consensus around some text that RECOMMENDS this documenter over
the existing methods, but does not obsolete/deprecate them because
those methods might be the only ones available for now. At a future
point this decision could be updated to obsolete the older methods.
If the authors/WG insists on the "deprecated" language, it should also
Obsolete: 8078. But be aware that the document currently does make
references
to it, which it cannot do if it obsoletes the document.
The authors don't insist on anything, and I find this language slightly
irritating.
(In my understanding of the word, it implies the absence of a
rationale and/or an unwillingness to engage in a discussion. I assume that
was not the intention ...)
Note that this seems to be just a miscommunication. The IESG does not
make decisions overriding the WG. It technically has no veto, and a
DISCUSS is just that - a discussion to try and resolve matters. In this
context, the word "insists" just meant to convey "sticks to their current
views" and did not convey anything about intensions of parties involved.
Section 4.1.1:
It is not clear to me if the "signaling domain" really has to be
its own zone or not. eg:
_dsboot.example.co.uk._signal.ns1.example.net
Could this be signed using the DNSKEY of "example.net", or does the
document insist on a zone cut at _signal.ns1.example.net ?
The document does not insist that there be a zone cut.
So in that case, I think it would be more clear to rename "Signaling
domain" to "Signaling name".
The Terminology section says:
Signaling domain: A hostname from the child's NS RRset, prefixed
with the label _signal.
Defining a hostname with an alias containing the word "domain" does not
prevent the confusion though (as in my case of reading the document)
Later on in the Operational Considerations, the issue is mentioned and
it states zone cuts are not mandatory. So I do think this needs some
cleanup.
I'm not sure what to clean up.
The confusion about name vs domain.
in Step 3: any failure to retrieve the CDS/CDNSKEY RRsets
located at the signaling name under any signaling domain,
including failure of DNSSEC validation, or unauthenticated data
(AD bit not set);
I think it also needs to exclude signaling signatures made by any DNSSEC
keys upstream from the DNS hoster's zone. Eg if we have
_signal.ns1.example.net
we also do not want to see the CDS/CDNSKEY RRsets signed by .net or the
root.
I'm not sure. It's conceivable for a TLD operator to run DNS service for some
of its child zones, and if I recall correctly, some of the smaller ccTLDs do.
In this case, address records of nameservers operated under a child may be
part of the TLD zone (along with the corresponding signaling names), so the
signaling records' signer name is indeed the TLD.
But then it is not a domain that can request DS records anyway (eg like
in .de)
In case that was an attack, the TLD (or root) would have to conceal the
delegation of example.net in order to then get asked for
_signal.ns1.example.net/CDS, to then publicly fabricate a signed response.
Unfortunately, they do not need to conceal it. If the .net TLD receives
a query for _signal.ns1.example.net, they can just give an authoritative
answer signed by their .net key, even if they publish NS records for
example.net. A resolver that does not do query minimalization will just
believe it.
That would discredit the operator quite significantly, and thus seems very
unlikely. Additionally, mitigation is available by using nameservers under
different TLDs, as mentioned in the document.
I still think placing an additional security control here makes
sense. Just to ensure that the DNS hoster is in fact the party that
signed the signaling data.
The problem lies in identifying "the DNS hoster's zone". There's no a priori
knowledge about how far up the tree it is.
You can detect a "deep sign", eg a signature that crosses a delegation.
It does not matter how many zone cuts there are, as long as the CDS is
not signed by a key on the upper side of a NS/DS delegation. I
understand this does involve some manual work (eg not just stock DNSSEC
validation).
Similarly as their is no
requirement for the signaling domain to be in a separate zone, there's no
requirement for the DNS hoster to use a zone distinct from the TLD. Such a
requirement would seem similarly unjustified as an imposed zone cut at
_signal.
So, I'm getting the feeling that I may have misunderstood the scenario you
described, in which case I'd appreciate your elaboration to that we can
include suitable text.
That is not a problem. As long as each signaure in the delegation does
not cross a zone cut. Eg for _signal.ns0.example.co.uk, it does not
matter if co.uk is signed by the same key or not, of if example.co.uk is
the zone cut or co.uk is the zone cut or whether there is a zone cut at
.signal. As long as whatever signed _signal is not a key upstream. So if
there is a (validatable) DS record for example.co.uk, then
_signal.ns0.example.co.uk
must not be signed by the key of uk. or the root key. If ns0.example.co.uk.
has a DS record, then _signal.ns0.example.co.uk must not be signed by
the key of example.com but or higher, but by the key of example.co.uk
(or if there is another DS for _signal.ns0.example.co.uk, by that key.
Section 5:
CDS/CDNSKEY records and corresponding signaling records MUST
NOT be published without the zone owner's consent.
This opens a can of worms. How is an implementer going to codify this
MUST? The only usable interpretation I can see is that the DNS hoster,
by being assigned the DNS hoster, has permissions to DNS host the zone
as it sees fit, and thus do DNSSEC. And especially not bother the zone
owner with techno-babble for permissions.
Likewise, the child DNS operator MUST enable the zone owner
Again, this wades into legalize and contractual matters best left
outside of RFC specifications.
These were added based on Warren's concerns that a DNS operator may lock in a
customer by enabling DNSSEC without consent, thus making it harder to move
away from that provider.
I talked to Warren a bit, and I think he understands my concern a bit
better. Perhaps something like this could work:
CDS/CDNSKEY records and corresponding signaling records can be
added using this protocol without explicit knowledge of the
domain owner. When transferring a domain to a new DNS hoster,
the old and new DNS hoster need to cooperate to allow for a
smooth transition. In the worst case, this might involve the
requesting the Registrar to remove all DS records and perform
a transfer as per draft-hardaker-dnsop-intentionally-temporary-insec
The authors believe either way is fine, and would like to hear the IESG's
decision on how to address this (or not).
The IESG does not make decisions like that. It points at what it thinks
are issues and everyone in the community hopefully works together to
resolve it. So above is my proposal. Let's see if Warren or you have
some improvements on this first proposal of me.
a zone cut ensures that bootstrapping activities do not require
modifications of the zone containing the nameserver hostname.
Why does this matter?
Because nameserver addresses are very static, so rarely touched. Touching a
zone comes with a risk that something goes wrong; at the same time, the
correctness and availability of nameserver addresses is critical to a DNS
operator.
It thus seems a good thing to not needlessly give write permission to
nameserver zones (or any zone, for that matter). Some provisioning systems
(such as at deSEC) follow this approach, and do not have production
credentials available for editing the nameserver zones (there's no API token
that can access them).
Ok, that is fair.
I think there should also be some text on
what to do when the parent and child NS RRsets for the domain mismatch.
(abort?)
The question really is whether CDS processing (also for updates, not only for
bootstrapping) should use child-centric or parent-centric resolution. It can
be further exacerbated by the question whether one needs to ensure
consistency across all NS *addresses* in case there are several. This rabbit
hole has been discussed in connection with draft-ietf-dnsop-cds-consistency,
where it was found that such "deep expansion" consistency checks are not
needed.
It can also be problematic if there is a non-coooperating/defunct DNS
hoster. Or if one of your nameservers is cut off because of routing
errors. But I agree that probably the existing RFCs text is enough for
this. It is not different for the bootstrap.
in Step 1: the child is already securely delegated or has
in-bailiwick nameservers only;
or the path from the root to the child traverses an insecure delegation.
Why is that a problem?
It seems fine to provision DS records for an insecure child even if the
parent is insecure, as long as the signaling records can be validated.
It seems risky to me. I am mostly worried about the effects of a
temporary DNSSEC -> insecure outage being abused. But I guess in the
case of trust islands could be supported. So I am fine with not adding
my sentence.
Paul
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
