Re: [auth48] AUTH48: RFC-to-be 9463 <draft-ietf-add-dnr-16> for your review

[[e-mail]]

Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.

1) <!-- [rfced] Abbreviated (running) document title, which appears in the PDF: 
FYI, we updated the abbreviated title to "DNR", along the lines of the
running title "DDR" in the companion document 9462 (draft-ietf-add-ddr).
Please let us know if you prefer otherwise.

Original:
Internet-Draft  Discovery of Network-designated Resolver      April 2023

Current PDF:
RFC 9463                          DNR                     September 2023
-->


2) <!-- [rfced] Datatracker "idnits" output for the original approved
document included the following warning.  Please let us know if any
changes are needed as related to this warning:

 == There are [sic] 1 instance of lines with non-RFC2606-compliant FQDNs in the
    document. -->


3) <!-- [rfced] Section 1:  Please note that companion document
9462 (draft-ietf-add-ddr) cites both RFCs 4861 and 8106 when referring 
to IPv6 Router Advertisement options.  We have asked the authors of
that document if the same RFC should be cited in both places.

Please note, however, that we do not see any mention of Router
Advertisement options in RFC 4861 - only Neighbor Discovery options.

Would you like to see how/if draft-ietf-add-ddr updates its
comparable citation and update this document (or not) to match?

Original:
 In particular, the document specifies how a local encrypted DNS
 resolver can be discovered by connected hosts by means of DHCPv4
 [RFC2132], DHCPv6 [RFC8415], and IPv6 Router Advertisement (RA)
 [RFC4861] options. -->


4) <!-- [rfced] Section 3:  This sentence did not parse.  We removed
the colon (":").  If this is incorrect, please clarify "and Neighbor
Discovery protocol (Section 6): Encrypted DNS options".

Original:
 This document describes how a DNS client can discover local encrypted
 DNS resolvers using DHCP (Sections 4 and 5) and Neighbor Discovery
 protocol (Section 6): Encrypted DNS options.

Currently:
 This document describes how a DNS client can discover local encrypted
 DNS resolvers using DHCP (Sections 4 and 5) and Neighbor
 Discovery protocol (Section 6) Encrypted DNS options. -->


5) <!-- [rfced] Section 3.2:  Should "the encrypted DNS is discovered"
be "encrypted DNS resolvers are discovered"?  If the suggested text
is not correct, please clarify.

Original:
 If the encrypted DNS is discovered by a host using both RA and DHCP,
 the rules discussed in Section 5.3.1 of [RFC8106] MUST be followed.

Suggested:
 If encrypted DNS resolvers are discovered by a host using both RA
 and DHCP, the rules discussed in Section 5.3.1 of [RFC8106] MUST be
 followed. -->


6) <!-- [rfced] Section 3.3:  As [I-D.ietf-dnsop-svcb-https] does not
have a Section 6.1 and the title of its Section 7.1 is '"alpn" and
"no-default-alpn"', we updated the cited section number accordingly.
If this is incorrect, please provide the correct citation.

Original:
 ALPN-related considerations can be found in Section 6.1 of
 [I-D.ietf-dnsop-svcb-https].

Currently:
 ALPN-related considerations
 can be found in Section 7.1 of [RFC9460]. 

(see https://www.rfc-editor.org/authors/rfc9460.html#section-7.1)-->


7) <!-- [rfced] Section 3.4:  This sentence does not parse.  If the
suggested text is not correct, please provide clarifying text.

Original:
 Such considerations fall under the generic issue of handling multiple
 provisioning sources and which should not be dealt within each option
 separately as per the recommendation in Section 12 of [RFC7227].

Suggested:
 Such considerations fall under the generic issue of handling multiple
 provisioning sources and should not be processed in each option
 separately, as per the recommendation in Section 12 of [RFC7227]. -->


8) <!-- [rfced] Should any of the artwork elements (<artwork>) be
tagged as sourcecode or another element?  Please review
<https://www.rfc-editor.org/materials/sourcecode-types.txt>; if the
current list of preferred values for "type" does not contain an
applicable type, please let us know.  Also, it is acceptable to leave
the "type" attribute not set. -->


9) <!-- [rfced] Sections 4.1 and 5.1:  These definitions read oddly, as
the items preceding the colon are not the field name, unlike all of
the other field entries that follow each of them.  May we update as
suggested?

Original:
 Option-code:  OPTION_V6_DNR (TBA1, see Section 9.1)
...
 Code:  OPTION_V4_DNR (TBA2, see Section 9.2).

Perhaps:
 OPTION_V6_DNR:  An Option Code (144; see Section 9.1).
...
 OPTION_V4_DNR:  An Option Code (162; see Section 9.2). -->


10) <!-- [rfced] Figure 3:  We changed the field name in the diagram
from "ipv6-address" to "ipv6-address(es)" per usage in the rest of
this document (e.g., "shown in Figure 3" in Section 6.1) and also
updated the figure title accordingly.  Please let us know any
objections.

Original:
 |                         ipv6-address                          |
...
 Figure 3: Format of the IPv6 Addresses Field 

Currently:
 |                       ipv6-address(es)                        |
...
 Figure 3: Format of the ipv6-address(es) Field -->


11) <!-- [rfced] Section 4.2:  Section 18.2.5 of RFC 8415 does not
explicitly mention the Option Request Option or "ORO".  Please
confirm that the citation for Section 18.2.5 of RFC 8415 will be
clear to readers.

Original:
 To discover an encrypted DNS resolver, the DHCPv6 client MUST include
 OPTION_V6_DNR in an Option Request Option (ORO), as in Sections
 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7 of [RFC8415]. -->


12) <!-- [rfced] Section 5.2:  Should 'multiple DNR instance data' be
'multiple "DNR Instance Data" field entries' here?  If the suggested
text is not correct, please provide clarifying text.

Original:
 The DHCPv4 client MUST be prepared to receive multiple DNR instance
 data in the OPTION_V4_DNR option; each instance is to be treated as a
 separate encrypted DNS resolver.

Suggested:
 The DHCPv4 client MUST be prepared to receive multiple "DNR Instance
 Data" field entries in the OPTION_V4_DNR option; each instance is to
 be treated as a separate encrypted DNS resolver. -->


13) <!-- [rfced] Section 6.1:  We see that Figure 7 has the
"0 ... 1 ... 2 ... 3" ruler markers above the
"0 1 2 3 4 5 6 7 8 9 ..." ruler lines but Figures 1 and 3 do not.
(We're not sure whether or not Figures 4 and 5 would also apply
here.)  Would you like to place additional ruler-marker lines over
Figures 1 and 3, and perhaps Figures 4 and 5?  (For example, similar
figures in companion document 9464 (draft-ietf-ipsecme-add-ike) all
include the additional ruler-marker line.)

Original (best viewed with a fixed-point font such as Courier):
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -->


14) <!-- [rfced] Section 6.1: FYI, in Figure 7, rather than 
insert the value for TBA3 (144), we put the word "Type" to 
correspond to the text below the figure. Please let us know 
if you prefer otherwise.

Original:
 |     TBA3      |     Length    |        Service Priority       |

Current:
 |     Type      |     Length    |        Service Priority       | -->


15) <!-- [rfced] Section 6.1:  We changed 'Service Parameters field' to
'"Service Parameters (SvcParams)" field' per the field name.  Please
let us know any objections.

Original:
 SvcParams Length:  16-bit unsigned integer.  This field indicates the
    length of the Service Parameters field in octets.

Currently:
 SvcParams Length:  16-bit unsigned integer.  This field indicates the
    length of the "Service Parameters (SvcParams)" field in octets. -->


16) <!-- [rfced] Section 7.1:  We defined "CA" as "Certificate Authority"
per companion document 9464 (draft-ietf-ipsecme-add-ike).  If this is
incorrect, please provide the correct definition.

Original:
 The attacker can get a domain name with a domain-
 validated public certificate from a CA and host an encrypted DNS
 resolver.

Currently:
 The attacker can get a domain name with a domain-
 validated public certificate from a Certificate Authority (CA) and
 host an encrypted DNS resolver. -->


17) <!-- [rfced] Section 7.1:  It appears that "but cannot provide"
refers to the endpoint, but does it refer to the mechanisms?  If the
endpoint, may we update as suggested?

Original:
 The above mechanisms would ensure that the endpoint receives the
 correct configuration information of the encrypted DNS resolvers
 selected by the DHCP server (or RA sender), but cannot provide any
 information about the DHCP server or the entity hosting the DHCP
 server (or RA sender).

Suggested ("endpoint can receive ... but cannot provide"):
 The above mechanisms would ensure that the endpoint can receive the
 correct configuration information of the encrypted DNS resolvers
 selected by the DHCP server (or RA sender) but cannot provide any
 information about the DHCP server or the entity hosting the DHCP
 server (or RA sender). -->


18) <!-- [rfced] Section 7.4:  We see that "PSK" has been defined but not
"WPA".  Will this abbreviation be clear to readers?  If not, how
should it be defined?

Original:
 If the pre-shared key (PSK) is the same for all clients that connect
 to the same WLAN (e.g., WPA-PSK), the shared key will be available to
 all nodes, including attackers.

Possibly:
 If the pre-shared key (PSK) is the same for all clients that connect
 to the same WLAN (e.g., Wi-Fi Protected Access Pre-Shared Key
 (WPA-PSK)), the shared key will be available to all nodes,
 including attackers. -->


19) <!-- [rfced] Section 8:  To what does "but does not" refer in this
sentence - the mechanism, or the DHCP client or IPv6 host?

Also, we see "mechanisms specified in this document" in
Sections 3.1.9 and 3.4.  Which mechanism is referred to here?

Original:
 The
 mechanism defined in this document can be used to infer that a DHCP
 client or IPv6 host support encrypted DNS options, but does not
 explicitly reveal whether local DNS clients are able to consume these
 options or infer their encryption capabilities. -->


20) <!-- [rfced] References:  We could not find a connection between the
Unicode Consortium and the [Evil-Twin] Wikipedia page.  If the
"Possibly" text is not correct, please provide an appropriate URL
for "Evil twin (wireless networks)".

Original:
 [Evil-Twin]
            The Unicode Consortium, "Evil twin (wireless networks)",
            <https://en.wikipedia.org/wiki/
            Evil_twin_(wireless_networks)>.

Possibly:
 [Evil-Twin]
            Wikipedia, "Evil twin (wireless networks)", November
            2022 <https://en.wikipedia.org/wiki/
            Evil_twin_(wireless_networks)>. -->


21) <!-- [rfced] References:  We could not find a connection between the
Unicode Consortium and the [Krack] paper.  Should author Mathy
Vanhoef be listed instead?

Also, please confirm that the provided URL is stable.

Original:
 [Krack]    The Unicode Consortium, "Key Reinstallation Attacks",
            2017, <https://www.krackattacks.com/>. -->


22) <!-- [rfced] References:  We could not find a connection between the
Unicode Consortium and the [Dragonblood] paper.  Also, the provided
URL appears to be a personal URL.

Will the currently listed URL remain stable?  Is there a site related
to the Unicode Consortium that also provides this paper?  If not,
should the authors (Mathy Vanhoef and Eyal Ronen) be credited?

Original:
 [Dragonblood]
            The Unicode Consortium, "Dragonblood: Analyzing the
            Dragonfly Handshake of WPA3 and EAP-pwd",
            <https://papers.mathyvanhoef.com/dragonblood.pdf>. -->


23) <!-- [rfced] References:  We could not find any mention of Cisco on
the provided web page.  We updated this listing as noted below.  If
this is incorrect, please provide the correct title and the matching
URL.

Original:
 [dot1x]    Cisco, "Basic 802.1x Wireless User Authentication",
            <https://openwrt.org/docs/guide-user/network/wifi/
            wireless.security.8021x>.

Currently:
 [dot1x]    OpenWrt, "Introduction to 802.1X", December 2021,
            <https://openwrt.org/docs/guide-user/network/wifi/
            wireless.security.8021x>. -->


24) <!-- [rfced] References:  We see on the provided URL, under the
"Versions" tab, that quite a few versions have been added since
December 2019 (Release 16.3.0).  Should this listing be updated?
We see that the latest version (Release 18 / version 18.3.0, dated
June 2023) also mentions "protocol configuration options" and
"ePCO".

Original:
 [TS.24008] 3GPP, "Mobile radio interface Layer 3 specification; Core
            network protocols; Stage 3 (Release 16)", December 2019,
            <https://www.3gpp.org/DynaReport/24008.htm>. -->


25) <!-- [rfced] Acknowledgments:  We found this sentence confusing,
as Section 7.3.1 of [RFC8310] says "... does not provide an
authentication domain name for the DNS resolver" and "This document
does not specify or request any DHCP extension to provide
authentication domain names".  The current text seems to indicate
the opposite.  Will this text be clear to readers, or should it be
updated?

Original:
 The use of DHCP to retrieve an authentication domain name was
 discussed in Section 7.3.1 of [RFC8310] and in an Internet-Draft
 authored by Tom Pusateri and Willem Toorop
 [I-D.pusateri-dhc-dns-driu].

Possibly *:
 An issue related to using DHCP to retrieve an ADN is discussed in
 Section 7.3.1 of [RFC8310].  [DNS-TLS-DHCPv6-Options], authored by
 Tom Pusateri and Willem Toorop, discusses ways to address the issue.

* Per this text from [I-D.pusateri-dhc-dns-driu]:
  This document was motivated in part by Section 7.3.1 of [RFC8310].
  Thanks to the authors Sara Dickinson, Daniel Kahn Gillmor, and
  Tirumaleswar Reddy for documenting the issue. -->


26) <!-- [rfced] Acknowledgments:  Please confirm that, unlike the other
individuals listed here, Rich Salz did more than one review ("secdir
reviews").

Original:
 Thanks to Rich Salz for the secdir reviews, Joe Clarke for the ops-
 dir review, Robert Sparks for the artart review, and David Blacka for
 the dnsdir review. -->


27) <!-- [rfced] Contributors section:  Per RFC 7322 (RFC Style Guide), 
we changed "Contributing Authors" to "Contributors".

If desired, you can add some information to the Contributors section to
describe their contributions.  If Nicolai Leymann and Zhiwei Yan should be
credited as coauthors, the following could be added (e.g., see RFC 9089).
Please let us know how you would like to proceed.

Original:
 11.  Contributing Authors

    Nicolai Leymann
...

Currently:
 Contributors

    Nicolai Leymann
...

Possibly:
 The following people contributed to the content of this document and
 should be considered coauthors:

    Nicolai Leymann
... -->


28) <!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide at
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
and let us know if any changes are needed.

Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice. -->


29) <!-- [rfced] The following term appears to be used inconsistently in
this document.  Please let us know which form is preferred.

 Encrypted DNS Option (1 instance - last paragraph of Section 7.1) /
   Encrypted DNS option (23 instances) /
   encrypted DNS option (1 instance - Section 8, Paragraph 1)*

 * As it appears that the option is of type "Encrypted DNS", we
   suggest "Encrypted DNS option".

Also, some field names are quoted, but some are not.  Would you like
to apply a consistent style (i.e., all quoted or none quoted)?
Please review usage, and advise.

For example:
 authentication-domain-name field

 Option-length field

 Type and Length fields

 "DNR Instance Data" field

 "Addr Length", "IPv4 Address(es)", and "Service Parameters
 (SvcParams)" fields ... -->


Thank you.

RFC Editor/lb/ar


On Sep 8, 2023, [e-mail] wrote:

*****IMPORTANT*****

Updated 2023/09/08

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

  *  [e-mail] (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).

  *  [e-mail], 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, 
       [e-mail] 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/rfc9463.xml
  https://www.rfc-editor.org/authors/rfc9463.html
  https://www.rfc-editor.org/authors/rfc9463.pdf
  https://www.rfc-editor.org/authors/rfc9463.txt

Diff file of the text:
  https://www.rfc-editor.org/authors/rfc9463-diff.html
  https://www.rfc-editor.org/authors/rfc9463-rfcdiff.html (side by side)

Diff of the XML: 
  https://www.rfc-editor.org/authors/rfc9463-xmldiff1.html

This diff file compares an altered original and the RFC 
(in order to make the changes in moved text viewable):
  https://www.rfc-editor.org/authors/rfc9463-alt-diff.html


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
  https://www.rfc-editor.org/auth48/rfc9463

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9463 (draft-ietf-add-dnr-16)

Title            : DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)
Author(s)        : M. Boucadair, Ed., T. Reddy.K, Ed., D. Wing, N. Cook, T. Jensen
WG Chair(s)      : David C Lawrence, Glenn Deen
Area Director(s) : Erik Kline, Éric Vyncke