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.

This question interests me.

When DNSSEC was designed, there was a decision to treat all zones the same.  
The fear was large delegated zones (COM) would need special treatment, we 
didn’t want the protocol to different per zone for that.  We didn’t address the 
uniqueness of the root zone though, specifically in distributing the trust 
anchor for it.  This left a gap we’ve never addressed.

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.

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.

“Automated Updates of DNSSEC Trust Anchors” is the WG’s in-band mechanism.  A 
while ago I wrote a replacement for that to address issues uncovered in looking 
at a root zone DNS Security Algorithm change but abandoned the work once I 
realized the only operational deployment of it would be for the root zone, 
which isn’t enough to justify the standards work.  The root zone implementation 
of Automated Updates isn’t precisely “by the RFC” but it works and for any 
change to the DNS Security Algorithm, it’ll be “made to work”, an alternate 
approach isn’t worth pursuing.

> 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.

_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

Reply via email to