[DNSOP] Re: [Ext] Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.

[Michael StJohns <[e-mail]>]

Hi Warren -

Inline -

On 8/21/2024 6:12 PM, Warren Kumari wrote:
>
>
>
>
> On Wed, Aug 21, 2024 at 10:28 AM, Edward Lewis 
> <[e-mail]> wrote:
>
>     On Aug 20, 2024, at 20:42, Michael StJohns <[e-mail]
>     <mailto:[e-mail]>> 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 -- [e-mail] <mailto:[e-mail]>
>     To unsubscribe send an email to [e-mail]
>     <mailto:[e-mail]>
>
>
>
>
> _______________________________________________
> DNSOP mailing list [e-mail]
> To unsubscribe send an email [e-mail]