Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E33BC169400 for ; Wed, 21 Aug 2024 15:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.net Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUW6Izo-ZIcR for ; Wed, 21 Aug 2024 15:12:35 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57777C14F5F2 for ; Wed, 21 Aug 2024 15:12:35 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2f3f25a1713so1731261fa.2 for ; Wed, 21 Aug 2024 15:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; t=1724278353; x=1724883153; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rfYSyC5WQdSXsrHSKFZOzhVVRBJiLNoCW7wCLNPm+qg=; b=E2y0OeumcyuCh6q75+/4rHC5IAtA0HCF4GZkqRpsqQyTzP9LpH07jCYxKGpIdCjq0O CkugVRvryAYaNvdfGEmqWf0yvz/KYiHz+SM7GTjMl9lNJZ/QwUOf7g4mB91vVeFxjvPg KXoLDZI6pV3eNro8/ev11emwLDFVmGq2ueOXee8M0Ez3qdZBBkKQTfJhyRtRpUF6+9jw 1rbXJo8Cso2Oxg9Og0CUn/+ng5/43D+VehNAtL6ASYQWB5MUGMc55F6OxlRe2tCHjgKu m13pHYePfLZUDTJe6NI5N1wi03ecJsVLwkUaWFfNrObnIXyOxRmFnyh1pq9tg2okjgUM oTkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724278353; x=1724883153; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rfYSyC5WQdSXsrHSKFZOzhVVRBJiLNoCW7wCLNPm+qg=; b=UZwd7qnl5grJk8SbyhB4tWtrbYzq76VDUeExuP/ZHUj/b7ELpGApR0nIQUwMYfcW5G a3A+aDqzb2k1AxTspSEc1n6KpCAmxdBQuM7A5laP1x+SZtrfDurXrAgkp0VoWldtY2ru lWOrC527RD1a59m63SeEVbHwVqIx4w7SrMNP6KMW6bSoQ3HjX1p1WySFfrifViCnZfR+ 2e6u9V5dhtykOv7bLuvZzgG0zGeMLHJSzpeTD9BHTWSrFFLDmuPgCm6vA1vF/1SD5017 W4gPvbDsRwnztNK5C8EC73u1x6WGjA15vu0TA2FBhaquJEc4Dxwgnf5efT0v4JLjyiSV amDw== X-Gm-Message-State: AOJu0YwKtT7VMm5gauUZ8f2byIlD8jEoz+7/r1bhoVT7QU5iU1HXCGMZ EhjIoRUMoLqDpRMNpm+r1Klo6LsFbGA2SgexSxVu5rXEkQeVAWtBHhd1ZR41wUG4xqhoDVIgvQX TVbsA1py8ZvsilQyKDfOsQmc4sweaLXL6XxMvag== X-Google-Smtp-Source: AGHT+IGOKNKzJrXPQWJPL9HuGwO+R5JwdhElzF/fhdUoGsrVhZbu7rxqxc4HQxz6VfineiSIm/Mf1fT7Q7euxGiBF3U= X-Received: by 2002:a2e:86c2:0:b0:2ef:2dc7:a8f0 with SMTP id 38308e7fff4ca-2f3f8b57b50mr19024191fa.45.1724278353024; Wed, 21 Aug 2024 15:12:33 -0700 (PDT) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Wed, 21 Aug 2024 15:12:31 -0700 Mime-Version: 1.0 X-Mailer: Superhuman Desktop (2024-08-19T19:05:41Z) References: <98896B9D-259E-4E46-8DC7-E873D8B25F55@icann.org> <65A596AD-1A4F-400A-9404-E2D60A54BE66@icann.org> <36118f44-d18d-443b-8aa8-007b8b62db3f@nthpermutation.com> <49523BCB-7747-44A2-97FA-8F46B238B4E0@icann.org> <6b19942a-1392-47ac-8a50-1520713f2140@nthpermutation.com> <3ABBFB63-4953-4F9D-97C7-A31276496200@gmail.com> X-Superhuman-ID: m04esr7w.c1fce2cb-370f-4e3c-b0bf-f428371967c0 X-Superhuman-Draft-ID: draft001210996df92715 In-Reply-To: <3ABBFB63-4953-4F9D-97C7-A31276496200@gmail.com> From: Warren Kumari Date: Wed, 21 Aug 2024 15:12:31 -0700 Message-ID: To: Edward Lewis Content-Type: multipart/alternative; boundary="000000000000ba0a85062038d67f" Message-ID-Hash: JQU6CBXVOTE576Q5NTJ2V2BH26IIVUYD X-Message-ID-Hash: JQU6CBXVOTE576Q5NTJ2V2BH26IIVUYD X-MailFrom: warren@kumari.net X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: dnsop X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5BDNSOP=5D_Re=3A_=5BExt=5D_Request=3A_Review_changes_-_draft-ietf?= =?utf-8?q?-dnsop-rfc7958bis-03_=E2=86=92_04=2E?= List-Id: IETF DNSOP WG mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000ba0a85062038d67f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 21, 2024 at 10:28 AM, Edward Lewis wrote: > On Aug 20, 2024, at 20:42, Michael StJohns > 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=E2=80=99t want the protocol to different per zone for = that. We > didn=E2=80=99t address the uniqueness of the root zone though, specifical= ly in > distributing the trust anchor for it. This left a gap we=E2=80=99ve 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 fo= r > 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=E2=80=99t materially change the docume= nt - > without convincing IANA to alter something operational. This doesn=E2=80= =99t make > WG review futile, a =E2=80=9Crubber stamp=E2=80=9D step, IANA is listenin= g 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 =E2=80=9Cstandards = based=E2=80=9D > 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=E2=80= =99s) and > IANA has its methods (including this document) in place. > > =E2=80=9CAutomated Updates of DNSSEC Trust Anchors=E2=80=9D is the WG=E2= =80=99s 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 wo= rk > once I realized the only operational deployment of it would be for the ro= ot > zone, which isn=E2=80=99t enough to justify the standards work. The root = zone > implementation of Automated Updates isn=E2=80=99t precisely =E2=80=9Cby t= he RFC=E2=80=9D but it > works and for any change to the DNS Security Algorithm, it=E2=80=99ll be = =E2=80=9Cmade to > work=E2=80=9D, an alternate approach isn=E2=80=99t 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, seein= g > multiple independent implementations interoperate is the goal. As a resul= t, > 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. > I do not believe that that is the goal, nor should it be. >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. 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=E2=80=99s in the file. Ma= ybe 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 =E2=80=94 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. I=E2=80=99m 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 =E2=80=94 this document = isn't the place to do it=E2=80=A6 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=E2=80=A6 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 > To unsubscribe send an email to dnsop-leave@ietf.org > > > --000000000000ba0a85062038d67f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable




On Wed, Aug 21, 2024 at 10:28 AM, E= dward Lewis <eppdnsprotocols@gmail.com> wrote:

On Aug 20, 2024, at 20:42, Michael StJohns = <msj@nthpermutation.com> wrote:

Hi Paul -

I'm confuse= d from your responses below - is this a WG document where the WG gets to de= cide, or is this an IANA document (like the one it was replacing) where IAN= A gets to decide? I *think* I saw you argue both ways in your response bel= ow.

This question interests me.

=

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

IANA has addressed this for= the DNS running on the global public Internet. Said in the sense that the= re is one DNS protocol and possibly many instantiations of a running DNS sy= stem. (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, w= hen it comes to the inter-planetary work, there may be a DNS system per, sa= y, planet.) This document is addressing how IANA is, has, and will be dist= ributing the trust anchor for the root zone they manage.

On the one hand, IANA wants to do what is in the best interests of th= e global public Internet and as such, seeks expert opinions of which this d= ocument is an example. The WG can=E2=80=99t materially change the document= - without convincing IANA to alter something operational. This doesn=E2= =80=99t make WG review futile, a =E2=80=9Crubber stamp=E2=80=9D step, IANA = is listening to the feedback. OTOH, I wonder if this is truly a WG documen= t 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 =E2=80=9Cstandards based=E2=80=9D 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=E2=80=99s) and IANA has its method= s (including this document) in place.

=E2=80=9CAutoma= ted Updates of DNSSEC Trust Anchors=E2=80=9D is the WG=E2=80=99s in-band me= chanism. A while ago I wrote a replacement for that to address issues unco= vered 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 fo= r the root zone, which isn=E2=80=99t enough to justify the standards work. = The root zone implementation of Automated Updates isn=E2=80=99t precisely = =E2=80=9Cby the RFC=E2=80=9D but it works and for any change to the DNS Sec= urity Algorithm, it=E2=80=99ll be =E2=80=9Cmade to work=E2=80=9D, an altern= ate approach isn=E2=80=99t worth pursuing.

<= p class=3D"">Syntax is easy. Semantics are hard and this document has a bi= t too much ambiguity for a naive relying party. Strangely, if this were si= mply 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 thin= k.

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 u= p 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.


I do not believe that that is the goal, nor should it be.
=

From the Abstract:
"This document describes the format and publication m= echanisms IANA uses to distribute the DNSSEC trust anchors."
=
and Introduction:
"The public= ation of trust anchors for the root zone of the DNS is an IANA function per= formed by ICANN, through its affiliate Public Technical Identifiers (PTI).= =C2=A0 A detailed description of corresponding=C2=A0 key management practic= es can be found in [DPS].

This document describes the formats and distribution methods of DNS= SEC trust anchors that is used by IANA for the root zone of the DNS.=C2=A0 = Other organizations might have different formats and mechanisms=C2=A0for di= stributing DNSSEC trust anchors for the root zone; however, most operators = and software vendors have chosen to rely on the IANA=C2=A0 trust anchors.

The formats and distribut= ion methods described in this document are a complement to, not a substitut= e for, the automated DNSSEC trust anchor update protocol described in [RFC5= 011]."

This documen= t describes the "format and publication mechanisms IANA uses", no= t "this is what we believe that the IANA should do" - there are o= ther venues for that discussion.=C2=A0

<= div class=3D"">

The document could be here to just present the marshaling of= the trust anchor materials - describing the syntax as it does - leaving th= e interpretation up to the writer (IANA) and reader (relying parties).
=

Maybe this document ought to just describe what=E2=80=99s= in the file. Maybe this document ought to expand to include rules for rel= ying on the document as Mike suggests.


This is a -bis to RFC7958, and the changes are intentionally rela= tively minor - see Section "1.2.=C2=A0 Changes from RFC 7958".=C2= =A0 A document=C2=A0 providing more rules and checks and processes and algo= rithms and advice for implementers and operators ingesting the trust anchor= s would be a fine document to write =E2=80=94 but it is (to me) clearly a d= ifferent document to this one.=C2=A0
Just like RFC= 7958 this has some operational warnings, but does at it says "A valida= tor operator can choose whether or not to accept the trust anchors describe= d 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= .=C2=A0

I=E2=80=99m not decided on this, frankly I n= eed 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 ma= naging the trust anchors.


Managing t= he trust anchors is (luckily!) not this documents purpose. The TA's man= agement is IANAs job, and it's a hairy one =E2=80=94 this document isn&= #39;t the place to do it=E2=80=A6=C2=A0

=
My initial email in this thread said:
"As this required a change to the XML syntax, I'd like to ge= t the DNSOP WGs review / feedback on these changes.

The IANA is eagerly awaiting this becomin= g a standard so that they can update their trust anchor with the DNSKEY mat= erial - so, if you have any strong objections to these changes, please let = me know by end of day (anywhere!) on Aug 18th."

I encourage peo= ple to write an "implementation considerations for trusting a new TA&q= uot; document, and / or advice to the IANA on managing the TA(s), successio= n planning, etc=E2=80=A6 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 s= tart from scratch.

I thi= nk that we are falling into the perfect becoming the enemy of the good enou= gh. We can always bis this document in the future and / or publish a more c= omprehensive document, but for now I think that this is good enough to prog= ress.=C2=A0

Thank you ve= ry much everyone for the review and feedback,
W


=



____= ___________________________________________
DNSOP= mailing list -- dnsop@ietf.org
To un= subscribe send an email to dnsop-leave@ietf.org
=



--000000000000ba0a85062038d67f--