Hi Ed -
Thanks for a thoughtful reply. Notes in line.
On 8/21/2024 10:28 AM, Edward Lewis wrote:
On Aug 20, 2024, at 20:42, Michael StJohns<m...@nthpermutation.com> wrote:
Hi Paul -
I'm confused from your responses below - is this a WG document where the WG
gets to decide, or is this an IANA document (like the one it was replacing)
where IANA gets to decide? I *think* I saw you argue both ways in your
response below.
....
IANA has addressed this for the DNS running on the global public Internet.
Said in the sense that there is one DNS protocol and possibly many
instantiations of a running DNS system. (I knew of a non-Internet DNS at one
time, operating on a separate, private inter-network. It may not be around any
more, on the other hand, when it comes to the inter-planetary work, there may
be a DNS system per, say, planet.) This document is addressing how IANA is,
has, and will be distributing the trust anchor for the root zone they manage.
On the one hand, IANA wants to do what is in the best interests of the global
public Internet and as such, seeks expert opinions of which this document is an
example. The WG can’t materially change the document - without convincing IANA
to alter something operational. This doesn’t make WG review futile, a “rubber
stamp” step, IANA is listening to the feedback. OTOH, I wonder if this is
truly a WG document or something that is best through the Independent stream
but reviewed by the DNSOP WG.
Yes. This document tries to be both a "here's how the IANA does it"
and "here's what the receiving party MUST do with it" and does both less
than completely successfully. I didn't look at the document when it
first came out in the ISE stream and I missed it when it showed up in
DNSOP. The older RFC is fairly benign, but still has some directive
(to the recipient) language related to validFrom and validUntil. This
version added additional directives - both to the relying party and to
the IANA about validity periods of the keys. It moved further from a
"here's how we do it" operational document to a protocol document with
those changes. Unfortunately, the protocol has (and has had) a number
of ambiguities.
I doubt there is enough energy for the WG to design a “standards based” means
for root zone trust anchor management and distribution that is out of band,
despite the gap, as there is only one working example (IANA’s) and IANA has its
methods (including this document) in place.
I don't actually think that's (write an OOB protocol for root TA
management) what's needed here. Removing the validFrom/validUntil
elements and language, removing the directive language to the IANA that
requires it to add a validUntil tag to a superceded key, and adding text
similar to what I suggested that states what this document is from the
POV of the IANA only would turn this back into what I think it was
intended to be: a secondary publication mechanism for trust anchors.
Alternately, language about what validFrom and validUntil mean in terms
of IANA operations instead of this directive of "don't use the key past
the valid time, even if we keep signing with it" would alleviate some of
my issues.
...
Syntax is easy. Semantics are hard and this document has a bit too much
ambiguity for a naive relying party. Strangely, if this were simply a signed
file of hashes with a time associated with it indicating the IANA's current
view (at time of publication) of the trust anchor set, I'd have a lot less to
argue about. Someone tried to do too much I think.
Protocol-defining IETF documents are meant to spur implementations, seeing
multiple independent implementations interoperate is the goal. As a result,
the documents often leave details up to the reader/implementer.
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. 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. 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.
Either "complete protocol" or "IANA operational process" would be
correct. This half-complete middle state is problematic. Returning this
to IANA to remove the directive language and then running it through the
ISE might be the quickest path to publication.
Last note - I don't know if there's any requirement for backwards
compatibility here. The primary target groups for this are big ISPs and
DNS software providers who mostly only look at this file when there's
enough noise in the world indicating a change in the root TA store. If
we do head in the protocol direction, let's do it right. If we stay in
the operational space, perhaps suggesting that IANA reduce the hash
process to a hash of just the key bytes instead of the contents of a DS
record or DNSKEY record may simplify a number of the technical issues
that were identified in this pass.
Later, Mike
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
