Please see inline. On Tue, 18 Mar 2025 at 19:51, Madison Church <mchu...@staff.rfc-editor.org> wrote:
> Greetings, > > This is a friendly weekly reminder that this document awaits your > attention. Please review the document-specific questions and AUTH48 > announcement. Let us know if we can be of assistance as you begin the > AUTH48 review process. > > The AUTH48 status page of this document is viewable at: > http://www.rfc-editor.org/auth48/rfc9761 > > The AUTH48 FAQs are available at: > https://www.rfc-editor.org/faq/#auth48 > > We look forward to hearing from you at your earliest convenience. > > Thank you, > RFC Editor/mc > > > On Mar 11, 2025, at 12:12 AM, rfc-edi...@rfc-editor.org wrote: > > > > Authors, > > > > While reviewing this document during AUTH48 ( > https://www.rfc-editor.org/authors/rfc9761.html and other formats), > please resolve the following questions, which are also in the XML file. > > > > 1) <!-- [rfced] For clarity, we have updated the title and the first > > sentence of the Abstract from the combined abbreviation > > "(D)TLS" to "TLS and DTLS". Afterwards, "D(TLS)" will be used in the > > document. > > > > Original: > > This memo extends the Manufacturer Usage Description (MUD) > > specification to allow manufacturers to define (D)TLS profile > > parameters. > > > > Current: > > This memo extends the Manufacturer Usage Description (MUD) > > specification to allow manufacturers to define TLS and DTLS profile > > parameters > > --> > Okay. > > > > > > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > > the title) for use on https://www.rfc-editor.org/search. --> > a) Network Security Access Control Lists (ACLs) b) Firewall Policies c) Certificate Validation d) Unauthorized Software Detection e) Malware Detection > > > > > > 3) <!-- [rfced] We have rephrased "non-malware" in the text below. > Please let us > > know if you refer otherwise. > > > > Original: > > Malware often reuses certain libraries, and there are notable > > differences in how malware uses encryption compared to non-malware. > > > > Current: > > Malware often reuses certain libraries, and there are notable > > differences in how malware uses encryption compared to software > > that is not malware. > > --> > Okay. > > > > > > 4) <!-- [rfced] Please clarify the following sentence. We note that DDR > is > > defined in RFC 9462, and DNR is defined in RFC 9463. We also note that > > RFC 9463 is cited for DNR later in this document. May we update the text > > as shown below? > > > > Original: > > * Using an alternative DNS server (via encrypted transport) to avoid > > detection by malware DNS filtering services [malware-doh]. > > Specifically, malware may not use the Do53 or encrypted DNS server > > provided by the local network (DHCP, DNR [RFC9462] or DDR > > [RFC9462]). > > > > Perhaps: > > > > * Using an alternative DNS server (via encrypted transport) to avoid > > detection by malware DNS filtering services [malware-doh]. > Specifically, > > malware may not use the Do53 or encrypted DNS server provided by the > > local network (DHCP, Discovery of Network-designated Resolvers (DNR) > > [RFC9463], or Discovery of Designated Resolvers (DDR) [RFC9462]). > Looks good. > > --> > > > > > > 5) <!-- [rfced] We find that the phrase "layers 3 and 4 Access Control > Lists" may > > be difficult for readers to interpret. May we rephrase it as below > > for readability? > > > > Original: > > This is superior to the layers 3 and 4 Access Control Lists > > (ACLs) of Manufacturer Usage Description Specification (MUD) > > [RFC8520] which are not suitable for broad communication patterns. > > > > Perhaps: > > This is superior to the Access Control Lists (ACLs) of > > Layers 3 and 4 in "Manufacturer Usage Description Specification" > > [RFC8520], which are not suitable for broad communication patterns. > > --> > Okay. > > > > > > 6) <!-- [rfced] How may this sentence be rephrased for readability? > > Specifically: Does "to identify the IoT manufacturer no longer supports > > the device" mean > > (A) "to indicate that the IoT manufacturer no longer supports the > device" or > > (B) "to identify which IoT manufacturer no longer supports the device" or > > otherwise? > Please proceed with Option (A) > > > > Original: > > However, if the IoT device has reached end-of-life and the IoT > > manufacturer will not issue a firmware or software update to the IoT > > device or will not update the MUD file, the "is-supported" attribute > > defined in Section 3.6 of [RFC8520] can be used by the MUD manager to > > identify the IoT manufacturer no longer supports the device. > > > > Perhaps (if option (A)): > > However, if the IoT device has reached end-of-life (EOL) and the IoT > > manufacturer will not issue a firmware or software update to the IoT > > device or will not update the MUD file, the "is-supported" attribute > > defined in Section 3.6 of [RFC8520] can be used by the MUD manager to > > indicate that the IoT manufacturer no longer supports the device. > > --> > Looks good. > > > > > > 7) <!-- [rfced] May we update this sentence as follows? The "and in TLS > > to signal" part is unclear. > > > > Original: > > For example, a TLS client implementation can support different sets > of > > algorithms for certificates and in TLS to signal the capabilities > > in "signature_algorithms_cert" and "signature_algorithms" > > extensions. > > > > Perhaps: > > For example, a TLS client implementation can support different sets > > of algorithms for certificates, and it can signal the capabilities > in > > the "signature_algorithms_cert" and "signature_algorithms" > extensions. > > --> > Looks good. > > > > > > 8) <!--[rfced] Note that the YANG modules have been updated per the > > formatting option of pyang. Please let us know any concerns. > Thanks. > > --> > > > > > > 9) <!--[rfced] Regarding the contact statement in the ietf-acl-tls > > and ietf-mud-tls YANG modules, would you like to add Dan Wing > > and Blake Anderson, i.e., to list all authors of this document? > Yes. > > (FYI, Tiru, your name has been updated to match your preference > > in past RFCs. Just let us know if updates are needed.) > > > > Current: > > Author: Tirumaleswar Reddy.K > > kond...@gmail.com Looks good. > > > --> > > > > > > 10) <!-- [rfced] Please review the "type" attribute of each sourcecode > element > > in the XML file to ensure correctness. If the current list of preferred > > values for "type" > > (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) > > does not contain an applicable type, then feel free to let us know. > > Also, it is acceptable to leave the "type" attribute not set. > > --> > Okay, you can leave the "type" attribute not set. > > > > > > 11) <!--[rfced] Is the expansion of TCAM accurate here? > > (It was plural in the original; it is not plural currently.) > Yes. > > > > Original: > > While ACL technology is traditionally associated with fixed-length > > bit matching in hardware implementations, such as those found in > > TCAMs, the use of ACLs in software, ... > > > > Current: > > While ACL technology is traditionally associated with fixed-length > > bit matching in hardware implementations, such as those found in > > Ternary Content-Addressable Memory (TCAM), the use of ACLs in > > software, ... > > --> > Looks good. > > > > > > 12) <!-- [rfced] May this sentence be updated as follows? > > Should the "messages" be singular to match the first stage? > > > > Original: > > ACL matching would be performed in two stages: > > first, by filtering clear-text TLS handshake message and second, by > > filtering after decrypting the TLS handshake messages. > I prefer the original, In TLS 1.3, only the first TLS message is in clear-text. > > > > Perhaps (if singular): > > ACL matching would be performed in two stages: > > first, by filtering the clear-text TLS handshake message; second, by > > filtering after decrypting the TLS handshake message. > > > > Or (if singular, and putting the steps of the second stage in order): > > ACL matching would be performed in two stages: > > first, by filtering the clear-text TLS handshake message; second, by > > decrypting the TLS handshake message then filtering it once more. > > --> > > > > > > 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. > > --> > It is aligned with the Security Considerations Section Template in Section 3.7.1 of https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/ > > > > > > 14) <!--[rfced] Table 3: For psk-key-exchange-mode, would you like the > > description to start with a capital letter, to be consistent with the > > other descriptions? If so, we will ask IANA to update the registry > > (https://www.iana.org/assignments/acl-tls) accordingly. > > > > Current: pre-shared key exchange mode > > > > Perhaps: Pre-shared key exchange mode > > --> > Okay. > > > > > > 15) <!-- [rfced] Please review the questions below regarding references > in this > > document. > > > > a) Re: [X690], we added the URL > > https://www.itu.int/rec/T-REC-X.690-200207-S/en. However, it has been > > superseded by this version that was released in February 2021: > > https://www.itu.int/rec/T-REC-X.690-202102-I/en. May we update this > reference > > to use the most current version? > Yes, please go ahead. > > > > Current: > > [X690] ITU-T, "Information technology - ASN.1 encoding Rules: > > Specification of Basic Encoding Rules (BER), Canonical > > Encoding Rules (CER) and Distinguished Encoding Rules > > (DER)", ITU-T Recommendation X.690, July 2002, > > <https://www.itu.int/rec/T-REC-X.690-200207-S/en>. > > > > > > b) We note that there are no citations for [RFC8484] in this document. > Please > > let us know if there is a specific place in the document where we can > cite > > this RFC. Otherwise, we will remove this from the Informative References. > Update DNS-over-HTTPS to refer to [RFC8484]. OLD: DoH/DoT: Refers to DNS-over-HTTPS and/or DNS-over-TLS [RFC7858]. NEW: DoH/DoT: Refers to DNS-over-HTTPS [RFC8484] and/or DNS-over-TLS [RFC7858]. > > > > 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. > > > > Current: > > [X501] "Information Technology - Open Systems Interconnection - > > The Directory: Models", ITU-T Recommendation X.501, > > November 1993, > > <https://www.itu.int/rec/T-REC-X.501-199311-S/en>. > > > > d) Re: [CRYPTO-VULNERABILITY], the information provided does not > > match the information provided at the URL (which directs to an NSA > > Cybersecurity Advisory with the title "Patch Critical Cryptographic > Vulnerability in Microsoft Windows Clients and Servers" with a date of 14 > January 2020). > > > > Upon further research, we found the following URL: > > > https://securityboulevard.com/2020/01/exploiting-the-windows-cryptoapi-vulnerability/. > The > > title, date, and author at this URL match the original reference > information > > provided. Is that the correct URL for this reference? Or should we > update > > this reference to match the information provided at the original URL, > > i.e., the NSA Cybersecurity Advisory? Thanks, the updated URL is good. > > > > > Original: > > [cryto-vulnerability] > > Perez, B., "Exploiting the Windows CryptoAPI > > > Vulnerability", January 2020, > > <https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/ > > CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF>. > > > > e) FYI, we removed mention of "Cisco" from this reference, > > as there is no mention of "Cisco" at this archived URL. > > Please let us know if other changes are needed. > > > > Original: > > [slowloris] > > Cisco, "Slowloris HTTP DoS", > > <https://web.archive.org/web/20150315054838/ > > http://ha.ckers.org/slowloris/>. > > > > Current: > > [SLOWLORIS] > > "Slowloris HTTP DoS", Wayback Machine archive, > > <https://web.archive.org/web/20150315054838/ > > http://ha.ckers.org/slowloris/>. > > --> > Please update the reference to https://www.cloudflare.com/learning/ddos/ddos-attack-tools/slowloris/ or https://en.wikipedia.org/wiki/Slowloris_(cyber_attack) > > > > > > 16) <!-- [rfced] Please review the following terms and let us know how > we should > > update. If there are no objections, we will use the form on the right for > > consistency. > > > > Cipher Suite vs. cipher suite > > [1 instance of "Cipher suite" at the start of a description > > will remain as is.] > Please align with the usage in RFC8446. > > > > certificate message (1 instance) vs. Certificate message > > There is one instance of "certificate message" (lowercase 'c') in > > "server certificate message" in Section 1. Should it be changed to > > "Certificate message"? Elsewhere it seems this document is using > > the term as defined in RFC 8446. > > --> > Yes, we would like to use the term defined in RFC 8446 (please use "Certificate message"). Cheers, -Tiru > > > > > > Thank you. > > > > RFC Editor/mc/ar > > > > > > On Mar 10, 2025, at 10:10 PM, rfc-edi...@rfc-editor.org wrote: > > > > *****IMPORTANT***** > > > > Updated 2025/03/10 > > > > RFC Author(s): > > -------------- > > > > Instructions for Completing AUTH48 > > > > Your document has now entered AUTH48. Once it has been reviewed and > > approved by you and all coauthors, it will be published as an RFC. > > If an author is no longer available, there are several remedies > > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > > > You and you coauthors are responsible for engaging other parties > > (e.g., Contributors or Working Group) as necessary before providing > > your approval. > > > > Planning your review > > --------------------- > > > > Please review the following aspects of your document: > > > > * RFC Editor questions > > > > Please review and resolve any questions raised by the RFC Editor > > that have been included in the XML file as comments marked as > > follows: > > > > <!-- [rfced] ... --> > > > > These questions will also be sent in a subsequent email. > > > > * Changes submitted by coauthors > > > > Please ensure that you review any changes submitted by your > > coauthors. We assume that if you do not speak up that you > > agree to changes submitted by your coauthors. > > > > * Content > > > > Please review the full content of the document, as this cannot > > change once the RFC is published. Please pay particular attention to: > > - IANA considerations updates (if applicable) > > - contact information > > - references > > > > * Copyright notices and legends > > > > Please review the copyright notice and legends as defined in > > RFC 5378 and the Trust Legal Provisions > > (TLP – https://trustee.ietf.org/license-info). > > > > * Semantic markup > > > > Please review the markup in the XML file to ensure that elements of > > content are correctly tagged. For example, ensure that <sourcecode> > > and <artwork> are set correctly. See details at > > <https://authors.ietf.org/rfcxml-vocabulary>. > > > > * Formatted output > > > > Please review the PDF, HTML, and TXT files to ensure that the > > formatted output, as generated from the markup in the XML file, is > > reasonable. Please note that the TXT will have formatting > > limitations compared to the PDF and HTML. > > > > > > Submitting changes > > ------------------ > > > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > > the parties CCed on this message need to see your changes. The parties > > include: > > > > * your coauthors > > > > * rfc-edi...@rfc-editor.org (the RPC team) > > > > * other document participants, depending on the stream (e.g., > > IETF Stream participants are your working group chairs, the > > responsible ADs, and the document shepherd). > > > > * auth48archive@rfc-editor.org, which is a new archival mailing list > > to preserve AUTH48 conversations; it is not an active discussion > > list: > > > > * More info: > > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > > > * The archive itself: > > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > > > * Note: If only absolutely necessary, you may temporarily opt out > > of the archiving of messages (e.g., to discuss a sensitive matter). > > If needed, please add a note at the top of the message that you > > have dropped the address. When the discussion is concluded, > > auth48archive@rfc-editor.org will be re-added to the CC list and > > its addition will be noted at the top of the message. > > > > You may submit your changes in one of two ways: > > > > An update to the provided XML file > > — OR — > > An explicit list of changes in this format > > > > Section # (or indicate Global) > > > > OLD: > > old text > > > > NEW: > > new text > > > > You do not need to reply with both an updated XML file and an explicit > > list of changes, as either form is sufficient. > > > > We will ask a stream manager to review and approve any changes that seem > > beyond editorial in nature, e.g., addition of new text, deletion of > text, > > and technical changes. Information about stream managers can be found > in > > the FAQ. Editorial changes do not require approval from a stream > manager. > > > > > > Approving for publication > > -------------------------- > > > > To approve your RFC for publication, please reply to this email stating > > that you approve this RFC for publication. Please use ‘REPLY ALL’, > > as all the parties CCed on this message need to see your approval. > > > > > > Files > > ----- > > > > The files are available here: > > https://www.rfc-editor.org/authors/rfc9761.xml > > https://www.rfc-editor.org/authors/rfc9761.html > > https://www.rfc-editor.org/authors/rfc9761.pdf > > https://www.rfc-editor.org/authors/rfc9761.txt > > > > Diff file of the text: > > https://www.rfc-editor.org/authors/rfc9761-diff.html > > https://www.rfc-editor.org/authors/rfc9761-rfcdiff.html (side by side) > > > > Diff of the XML: > > https://www.rfc-editor.org/authors/rfc9761-xmldiff1.html > > > > > > Tracking progress > > ----------------- > > > > The details of the AUTH48 status of your document are here: > > https://www.rfc-editor.org/auth48/rfc9761 > > > > Please let us know if you have any questions. > > > > Thank you for your cooperation, > > > > RFC Editor > > > > -------------------------------------- > > RFC9761 (draft-ietf-opsawg-mud-tls-18) > > > > Title : Manufacturer Usage Description (MUD) for TLS and DTLS > Profiles for Internet of Things (IoT) Devices > > Author(s) : T. Reddy.K, D. Wing, B. Anderson > > WG Chair(s) : Henk Birkholz, Joe Clarke > > Area Director(s) : Warren Kumari, Mahesh Jethanandani >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
