Hi Warren -
Inline -
On 8/21/2024 6:12 PM, Warren Kumari wrote:
On Wed, Aug 21, 2024 at 10:28 AM, Edward Lewis
<eppdnsprotoc...@gmail.com> wrote:
On Aug 20, 2024, at 20:42, Michael StJohns <m...@nthpermutation.com
<mailto:m...@nthpermutation.com>> wrote:
... trimmed ...
But this document is not a pure protocol-defining document, it is
an operational process document. As such, it ought to be more
concrete. That is, if the goal is to describe the entirety of
distributing the trust anchors.
I do not believe that that is the goal, nor should it be.
I don't believe the goal of this document is to describe the process
that the IANA uses to create, service and revoke TAs, but to simply
describe the format by which the public can be informed of a set of TAs
that exist at a particular time. Unfortunately, the content of the
document does not limit itself to this.
From the Abstract:
"This document describes the format and publication mechanisms IANA
uses to distribute the DNSSEC trust anchors."
and Introduction:
"The publication of trust anchors for the root zone of the DNS is an
IANA function performed by ICANN, through its affiliate Public
Technical Identifiers (PTI). A detailed description of corresponding
key management practices can be found in [DPS].
This document describes the formats and distribution methods of DNSSEC
trust anchors that is used by IANA for the root zone of the DNS.
Other organizations might have different formats and mechanisms for
distributing DNSSEC trust anchors for the root zone; however, most
operators and software vendors have chosen to rely on the IANA trust
anchors.
The formats and distribution methods described in this document are a
complement to, not a substitute for, the automated DNSSEC trust anchor
update protocol described in [RFC5011]."
This document describes the "format and publication mechanisms IANA
uses", not "this is what we believe that the IANA should do" - there
are other venues for that discussion.
If only this were the case. You've quoted the abstract - but it helps
to get into the fine print. This document goes past the "format and
mechanisms" of publication and into directing behavior of both the
recipients and the IANA.
First - there's this part of section 2.2. Part of this was in RFC7958 -
but has been rewritten in a manner that appears reflects IANA practice
and not DNSSEC protocol behavior. E.g. the "change to a trust anchor"
language here does not accurately reflect the DNSSEC protocol behavior.
Relying parties can, may and do use any un-revoked trust anchor to chain
signatures for current RR sets rather than changing from one TA to another.
As I mentioned in other emails, validFrom and validUntil should be read
more as "we expect to start signing with this key on or about validFrom
and continue to use this key until validUntil. No language in this
document should be read as prohibiting chaining to an unrevoked trust
anchor key regardless of the relationship to the "validFrom" or
"validUntil" dates. In otherwords, someone reading this should take the
information as a snapshot of what the IANA believes are the current set
of trust anchors and what the public should understand about IANA's
plans for those trust anchors.
The validFrom and validUntil attributes in the KeyDigest element
specify the range of times that the KeyDigest element can be used as
a trust anchor.
Note that the validUntil attribute of the KeyDigest element is
optional. If the relying party is using a trust anchor that has a
KeyDigest element that does not have a validUntil attribute, it can
change to a trust anchor with a KeyDigest element that does have a
validUntil attribute, as long as that trust anchor's validUntil
attribute is in the future and the KeyTag, Algorithm, DigestType, and
Digest elements of the KeyDigest are the same as the previous trust
anchor.
Relying parties SHOULD NOT use a KeyDigest outside of the time range
given in the validFrom and validUntil attributes.
"can be used as a trust anchor" appears to be telling the relying party
that irrespective of the live content of the DNS, keys must not be used
outside of this range. "SHOULD NOT" is a protocol directive, not merely
a "here's what we're doing" note and should not be present in this
document without a whole lot of other discussion on what it means to the
relying parties.
Section 3.3 has this:
A KeyDigest element can contain both a Digest and a publickeyinfo
named pattern. If the Digest element would not be a proper DS record
for a DNSKEY record represented by the publickeyinfo named pattern,
relying parties MUST NOT use that KeyDigest as a trust anchor.
The MUST NOT here is misleading and confusing and under described. For
example, what happens if these disagree, but then we start seeing
something that matches the public key in the root DNSKEY RRSet? Or we
see a valid public key in the DNSKEY RR set that chains to the hash?
The language for the new element needs work to clarify what happens if
IANA gets this wrong. Instead: "It is IANA's intent that these two
values should match. Please notify IANA if you find any mismatch in
these related items in a published file." is probably what should be
here rather than the above.
Lastly - section 5 has this as new text differing from the previous RFC:
When a trust anchor that was previously published is no longer
suitable for use, IANA MUST update the trust anchor document
accordingly by setting a validUntil date for that trust anchor. The
validUntil attribute that is added MAY be a date in the past or in
the future, depending on IANA's operational choices.
This seems to be creating a pseudo-revocation mechanism by overloading
what they originally meant by "validUntil". As mentioned above, this
is directive both to the IANA and has protocol implications related to
the section 2.2 text. If you want to signal revocation of a TA in this
file, use the 5011 mechanism and provide a signed revoked key here
instead of this.
Finally, section 2 needs:
"Unless there are countervailing operational needs, IANA plans to
include in the published XML file all trust anchors for the root zone
that are currently under management by IANA as of the time of
publication of that file instance." Right now, this is a collection
of data points lacking some context of how they were selected for the file.
And perhaps:
"IANA intends on updating this file at least annually, and in any case
at least 6 months in advance of signing with a new trust anchor key."
The document could be here to just present the marshaling of the
trust anchor materials - describing the syntax as it does -
leaving the interpretation up to the writer (IANA) and reader
(relying parties).
Maybe this document ought to just describe what’s in the file.
Maybe this document ought to expand to include rules for relying
on the document as Mike suggests.
This is a -bis to RFC7958, and the changes are intentionally
relatively minor - see Section "1.2. Changes from RFC 7958". A
document providing more rules and checks and processes and algorithms
and advice for implementers and operators ingesting the trust anchors
would be a fine document to write — but it is (to me) clearly a
different document to this one.
Just like RFC7958 this has some operational warnings, but does at it
says "A validator operator can choose whether or not to accept the
trust anchors described in this document using whatever policy they want."
This is just a cleanup document - let's get this shipped so that the
IANA can publish new TAs in a better format.
See above - it really has greater operational implications than just
cleanup.
I'd be happy if they backed out all of the MUST or MUST NOT guidance and
left this solely as a data format document with some clarification for
the meanings as above. But it needs work before publication. Even the
escape clauses conflict!
Later, Mike
ps - one last question. Does the IETF publish XML schemas for easy
retrieval? If so, it might be useful to do so with this schema and
reference it from within the TA xml document.
I’m not decided on this, frankly I need to go over the thread
again. But its going to be a debate over whether this document is
only about marshaling the trust anchors or it is about managing
the trust anchors.
Managing the trust anchors is (luckily!) not this documents purpose.
The TA's management is IANAs job, and it's a hairy one — this document
isn't the place to do it…
My initial email in this thread said:
"As this required a change to the XML syntax, I'd like to get the
DNSOP WGs review / feedback on these changes.
The IANA is eagerly awaiting this becoming a standard so that they can
update their trust anchor with the DNSKEY material - so, if you have
any strong objections to these changes, please let me know by end of
day (anywhere!) on Aug 18th."
I encourage people to write an "implementation considerations for
trusting a new TA" document, and / or advice to the IANA on managing
the TA(s), succession planning, etc… but again, that is not this
document. It **could** even be a rfc7958bis-bis, but I feel it is a
much larger topic and would start from scratch.
I think that we are falling into the perfect becoming the enemy of the
good enough. We can always bis this document in the future and / or
publish a more comprehensive document, but for now I think that this
is good enough to progress.
Thank you very much everyone for the review and feedback,
W
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org <mailto:dnsop@ietf.org>
To unsubscribe send an email to dnsop-le...@ietf.org
<mailto:dnsop-le...@ietf.org>
_______________________________________________
DNSOP mailing list --dnsop@ietf.org
To unsubscribe send an email todnsop-le...@ietf.org
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
