IANA, Please make the following capitalization changes to the Description column in the "ACL (D)TLS Paramaters" registry (https://www.iana.org/assignments/acl-tls/acl-tls.xhtml#acl-dtls-parameters):
1) pre-shared key exchange mode to Pre-shared key exchange mode 2) Cipher Suite to Cipher suite Thank you, RFC Editor/mc > On Apr 14, 2025, at 9:14 AM, Madison Church <mchu...@staff.rfc-editor.org> > wrote: > > Hi Paul, Authors, > > Paul - Thank you for your reply! We have noted your approval on the AUTH48 > status page (see https://www.rfc-editor.org/auth48/rfc9761). > > Authors - We will now ask IANA to make their updates. > > Thank you, > RFC Editor/mc > >> On Apr 9, 2025, at 7:38 AM, Paul Wouters <paul.wout...@aiven.io> wrote: >> >> Thanks for the reminder ping, >> >> I approve of the changes. >> >> Paul >> >> >> On Tue, Apr 8, 2025 at 12:47 PM Madison Church >> <mchu...@staff.rfc-editor.org> wrote: >> Hi Paul, >> >> This is a friendly reminder that we await your review and approval for the >> changes listed in the thread below. These changes are best viewed in the >> diff files below: >> https://www.rfc-editor.org/authors/rfc9761-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9761-auth48rfcdiff.html (side-by-side >> diff) >> >> Thank you, >> RFC Editor/mc >> >>> On Apr 1, 2025, at 2:08 PM, Madison Church <mchu...@staff.rfc-editor.org> >>> wrote: >>> >>> Hi Authors and *Paul, >>> >>> Thank you for your replies! We have noted your approvals on the AUTH48 >>> status page for this document (see >>> https://www.rfc-editor.org/auth48/rfc9761). >>> >>> *Paul - As the Responsible AD for this document, please review and approve >>> the following changes. These changes are best viewed in the diff files >>> below: >>> https://www.rfc-editor.org/authors/rfc9761-auth48diff.html >>> https://www.rfc-editor.org/authors/rfc9761-auth48rfcdiff.html (side-by-side >>> diff) >>> >>> 1. Changes in Paragraph 5 of Section 9.3: >>> >>> The Security Considerations Section for this document has been updated to >>> follow the Security Considerations Section Template in Section 3.7.1 of >>> rfc8407bis (see >>> https://www.ietf.org/id/draft-ietf-netmod-rfc8407bis-22.html#name-security-considerations-sect). >>> The following text appears in the template, but not in the document (the >>> authors have stated that this intentional): >>> >>> "Specifically, the following subtrees and data nodes have particular >>> sensitivities/vulnerabilities:" >>> >>> Instead, the paragraph contains the following sentence: >>> >>> "The YANG module will provide insights into (D)TLS profiles of the IoT >>> devices, and the privacy considerations discussed in Section 10 need to be >>> taken into account." >>> >>> Please let us know if this is acceptable. >>> >>> >>> 2. Changes in Paragraph 4 of Section 9.4: Similar to the above, the >>> following text appears in the template, but not in the document (the >>> authors have stated that this intentional): >>> >>> "Specifically, the following subtrees and data nodes have particular >>> sensitivities/vulnerabilities:" >>> >>> Instead, the paragraph contains the following text: >>> >>> "For instance, update that the device does not support (D)TLS profile can >>> dramatically alter the implemented security policy. For this reason, the >>> NACM >>> extension "default-deny-write" has been set for all data nodes defined in >>> this module." >>> >>> Please let us know if this is acceptable. >>> >>> >>> 3. Normative References: Note that RFCs 6242 and 9110 have been updated to >>> RFCs 4252 and 9000 to match the second paragraph of the Security >>> Considerations Section Template in rfc8407bis (see >>> https://www.ietf.org/id/draft-ietf-netmod-rfc8407bis-22.html#name-security-considerations-sect). >>> Please let us know any objections. >>> >>> Once we receive your approval, we will send our updates along to IANA. >>> >>> Thank you! >>> RFC Editor/mc >>> >>> >>>> On Apr 1, 2025, at 1:34 AM, tirumal reddy <kond...@gmail.com> wrote: >>>> >>>> Hi Madison, >>>> >>>> Updates to the draft look good. I approve publication of the document. >>>> >>>> Cheers, >>>> -Tiru >>>> >>>> On Tue, 1 Apr 2025 at 02:04, Madison Church <mchu...@staff.rfc-editor.org> >>>> wrote: >>>> Hi Tirumal, >>>> >>>> Thank you for your reply! We have updated the document accordingly and all >>>> of our questions have been addressed. >>>> >>>> Please review the document carefully to ensure satisfaction as we do not >>>> make changes once it has been published as an RFC. Contact us with any >>>> further updates or with your approval of the document in its current form. >>>> We will await approvals from each party listed on the AUTH48 status page >>>> prior to moving forward in the publication process. >>>> >>>> The files have been posted here (please refresh): >>>> https://www.rfc-editor.org/authors/rfc9761.txt >>>> https://www.rfc-editor.org/authors/rfc9761.pdf >>>> https://www.rfc-editor.org/authors/rfc9761.html >>>> https://www.rfc-editor.org/authors/rfc9761.xml >>>> >>>> The relevant diff files have been posted here (please refresh): >>>> https://www.rfc-editor.org/authors/rfc9761-diff.html >>>> https://www.rfc-editor.org/authors/rfc9761-rfcdiff.html (side by side) >>>> https://www.rfc-editor.org/authors/rfc9761-auth48diff.html >>>> https://www.rfc-editor.org/authors/rfc9761-auth48rfcdiff.html (side by >>>> side) >>>> >>>> For the AUTH48 status of this document, please see: >>>> https://www.rfc-editor.org/auth48/rfc9761 >>>> >>>> Thank you, >>>> RFC Editor/mc >>>> >>>>> On Mar 29, 2025, at 2:31 AM, tirumal reddy <kond...@gmail.com> wrote: >>>>> >>>>> On Sat, 29 Mar 2025 at 02:23, Madison Church >>>>> <mchu...@staff.rfc-editor.org> wrote: >>>>> Hi Authors, >>>>> >>>>> Dan - Thank you for your reply! We have noted your approval on the AUTH48 >>>>> status page (see https://www.rfc-editor.org/auth48/rfc9761). >>>>> >>>>> Tirumal - Thank you for your response to our followup questions! We have >>>>> updated the document as requested. We have one followup comment and >>>>> updated files can be found below. >>>>> >>>>>> On Mar 28, 2025, at 4:42 AM, tirumal reddy <kond...@gmail.com> wrote: >>>>>> >>>>>> Please ignore my responses to Section 9.2. Your proposed changes to this >>>>>> section look good. I mistakenly referred to Section 9.3 instead. >>>>> >>>>> [rfced] We updated Section 9.2 to add the "writeable/readable data nodes" >>>>> sentences per your note. We weren’t sure if this note also included >>>>> Question 1b per your first response, so we have not added the additional >>>>> text at the end of Section 9.2. >>>>> >>>>> There are no data nodes defined by the IANA maintained iana-tls-profile. >>>>> Please proceed to add the text proposed by you for Section 9.2. >>>>> >>>>> Please review and let us know if this section (or any section in the >>>>> Security Considerations) needs any further updates. >>>>> >>>>> Updates to the draft look good to me. >>>>> >>>>> Cheers, >>>>> -Tiru >>>>> >>>>> >>>>>> -Tiru >>>>>> >>>>>> On Fri, 28 Mar 2025 at 14:42, tirumal reddy <kond...@gmail.com> wrote: >>>>>> Hi Madison, >>>>>> >>>>>> Please see inline >>>>>> >>>>>> On Thu, 27 Mar 2025 at 23:06, Madison Church >>>>>> <mchu...@staff.rfc-editor.org> wrote: >>>>>> Hi Tirumal, >>>>>> >>>>>> Thank you for your reply! We have updated the document accordingly and >>>>>> have some followup queries marked with [rfced]. >>>>>> >>>>>> [rfced] Upon sending the initial AUTH48 email, we note that the address >>>>>> "blake.ander...@cisco.com" returned an "Undelivered Mail Returned to >>>>>> Sender" message. Is there an up-to-date email address for Blake that we >>>>>> can reach? >>>>>> >>>>>>>> 13) <!-- [rfced] Because of your note that the template in rfc8407bis >>>>>>>> has been used, we will update this paragraph (which appears in Sections >>>>>>>> 9.2, 9.3, and 9.4) to match Section 3.7.1 of rfc8407bis as follows. >>>>>>>> Please let us know if that is not what you intended. >>>>>>>> >>>>>>>> Original: >>>>>>>> This section follows the template defined in Section 3.7.1 of >>>>>>>> [I-D.ietf-netmod-rfc8407bis]. >>>>>>>> >>>>>>>> The YANG module specified in this document defines a schema for data >>>>>>>> can possibly be accessed via network management protocols such as >>>>>>>> NETCONF [RFC6241] or RESTCONF [RFC8040]. These network management >>>>>>>> protocols are required to use a secure transport layer and mutual >>>>>>>> authentication, e.g., SSH [RFC6242] without the "none" authentication >>>>>>>> option, Transport Layer Security (TLS) [RFC8446] with mutual X.509 >>>>>>>> authentication, and HTTPS with HTTP authentication (Section 11 of >>>>>>>> [RFC9110]). >>>>>>>> >>>>>>>> The Network Access Control Model (NACM) [RFC8341] provides the means >>>>>>>> to restrict access for particular users to a pre-configured subset of >>>>>>>> all available protocol operations and content. >>>>>>>> >>>>>>>> Perhaps (following draft-ietf-netmod-rfc8407bis-22): >>>>>>>> This section follows the template defined in Section 3.7.1 of >>>>>>>> [YANG-GUIDELINES]. >>>>>>>> >>>>>>>> The "iana-tls-profile" YANG module defines a data model that is >>>>>>>> designed to be accessed via YANG-based management protocols, such as >>>>>>>> NETCONF [RFC6241] and RESTCONF [RFC8040]. These protocols have to >>>>>>>> use a secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and >>>>>>>> QUIC [RFC9000]) and have to use mutual authentication. >>>>>>>> >>>>>>>> The Network Configuration Access Control Model (NACM) [RFC8341] >>>>>>>> provides the means to restrict access for particular NETCONF or >>>>>>>> RESTCONF users to a preconfigured subset of all available NETCONF or >>>>>>>> RESTCONF protocol operations and content. >>>>>>>> --> >>>>>> >>>>>> Looks good to me. >>>>>>> >>>>>>> It is aligned with the Security Considerations Section Template in >>>>>>> Section 3.7.1 of >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/ >>>>>> >>>>>> [rfced] Per your reply, we have updated the document as much as possible >>>>>> to match the template in Section 3.7.1 of 8407bis. We have the remaining >>>>>> questions regarding these updates. Note that this diff file may be best >>>>>> for viewing side-by-side updates: >>>>>> https://www.rfc-editor.org/authors/rfc9761-auth48rfcdiff.html. >>>>>> >>>>>> 1) Section 9.2: >>>>>> a) May we add the following sentences in Section 9.2 to match the >>>>>> template? >>>>>> >>>>>> "There are no particularly sensitive writable data nodes." >>>>>> "There are no particularly sensitive readable data nodes." >>>>>> >>>>>> No, sensitive writable/readable data nodes are present and the >>>>>> security/privacy considerations are explained in 4th and 5th paragraphs >>>>>> of Section 9.3. >>>>>> >>>>>> b) Would you like to add the following text at the end of Section 9.2 as >>>>>> per the template’s guidance? >>>>>> >>>>>> -- If the data model does not define any data nodes (i.e., none >>>>>> -- of the above sections or readable/writable data nodes or RPCs >>>>>> -- have been included), then add the following text: >>>>>> >>>>>> "The YANG module defines a set of identities, types, and >>>>>> groupings. These nodes are intended to be reused by other YANG >>>>>> modules. The module by itself does not expose any data nodes that >>>>>> are writable, data nodes that contain read-only state, or RPCs. >>>>>> As such, there are no additional security issues related to >>>>>> the YANG module that need to be considered." >>>>>> >>>>>> No, the YANG module defines data nodes. >>>>>> >>>>>> "Modules that use the groupings that are defined in this document >>>>>> should identify the corresponding security considerations. For >>>>>> example, reusing some of these groupings will expose privacy-related >>>>>> information (e.g., 'node-example')." >>>>>> >>>>>> >>>>>> 2) Section 9.3: >>>>>> In the "Some of the readable data nodes" paragraph, this sentence (from >>>>>> the template) is not present. Is this intentional? >>>>>> >>>>>> Yes. >>>>>> "Specifically, the following subtrees and data nodes have particular >>>>>> sensitivities/vulnerabilities:" >>>>>> >>>>>> Instead, the document has this sentence: >>>>>> "The YANG module will provide insights into (D)TLS profiles of the IoT >>>>>> devices, and the privacy considerations discussed in >>>>>> Section 10 need to be taken into account." >>>>>> >>>>>> >>>>>> 3) Section 9.4: >>>>>> a) May we add the following sentence per the templates guidance? >>>>>> "There are no particularly sensitive readable data nodes." >>>>>> >>>>>> No. >>>>>> >>>>>> b) For the "Some of the readable data nodes" paragraph, this sentence >>>>>> (from the template) is not present. Is this intentional? >>>>>> >>>>>> Yes. >>>>>> "Specifically, the following subtrees and data nodes have particular >>>>>> sensitivities/vulnerabilities:" >>>>>> >>>>>> Instead, the document has the following sentences: >>>>>> "For instance, update that the device does not support (D)TLS profile >>>>>> can dramatically alter the implemented security policy. For this reason, >>>>>> the NACM extension "default-deny-write" has been set for all data nodes >>>>>> defined in this module." >>>>>> >>>>>> >>>>>> 4) For all sections in the Security Considerations section, may we >>>>>> update the sentence below to accurately reflect the template? >>>>>> >>>>>> Current: >>>>>> This module does not define any RPCs, actions, or notifications, and >>>>>> thus the security consideration for such is not provided here. >>>>>> >>>>>> Perhaps: >>>>>> There are no particularly sensitive RPC or action operations. >>>>>> >>>>>> Okay. >>>>>> >>>>>>>> 15) <!-- [rfced] Please review the questions below regarding >>>>>>>> references in this >>>>>>>> document. >>>>>>>> c) Re: [X501], this reference has been superseded >>>>>>>> by the 2019 version of X.501 - available here: >>>>>>>> https://www.itu.int/rec/T-REC-X.501-201910-I/en. May we update this >>>>>>>> reference >>>>>>>> to use the most current version? FYI, the URL for the >>>>>>>> 1993 version of this reference has been included in the reference. >>>>>> >>>>>> Yes, good to update. >>>>>> >>>>>> Cheers, >>>>>> -Tiru >>>>> >>>>> Please review the document carefully to ensure satisfaction as we do not >>>>> make changes once it has been published as an RFC. Contact us with any >>>>> further updates or with your approval of the document in its current >>>>> form. We will await approvals from each author prior to moving forward in >>>>> the publication process. >>>>> >>>>> The updated files have been posted here (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9761.txt >>>>> https://www.rfc-editor.org/authors/rfc9761.pdf >>>>> https://www.rfc-editor.org/authors/rfc9761.html >>>>> https://www.rfc-editor.org/authors/rfc9761.xml >>>>> >>>>> The updated diffs have been posted here (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9761-diff.html >>>>> https://www.rfc-editor.org/authors/rfc9761-rfcdiff.html (side by side) >>>>> https://www.rfc-editor.org/authors/rfc9761-auth48diff.html (AUTH48 >>>>> updates only) >>>>> https://www.rfc-editor.org/authors/rfc9761-auth48rfcdiff.html (side by >>>>> side AUTH48 updates) >>>>> >>>>> AUTH48 status page: >>>>> https://www.rfc-editor.org/auth48/rfc9761 >>>>> >>>>> Thank you! >>>>> RFC Editor/mc >>>> >>> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
