Re: [auth48] AUTH48: RFC-to-be 9539 <draft-ietf-dprive-unilateral-probing-13> 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] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->


2) <!--[rfced] How can "steps" be defeated?  Perhaps a rephrase for this
     text would be beneficial (e.g., "The protections provided by
     following the steps in this document")?

Original:
The steps in this document can be defeated by an active attacker, but
should be simpler and less risky to deploy than more powerful
defenses.

-->


3) <!--[rfced] We had a few questions regarding the Terminology section:

a) Would the following update to the Do53 entry be agreeable to
clarify the 1:1 relationship between the initialism and expansion?

Perhaps:
   Unilateral:  Capable of opportunistic probing without external
      coordination with any of the other parties.

   Do53:  DNS over port 53 ([RFC1035]) for traditional cleartext.

   DoQ:  DNS over QUIC ([RFC9250]).

   DoT:  DNS over TLS ([RFC7858]).

   Encrypted transports:  DoQ and DoT, collectively.


b) We note that some of the conventions used in the document are
described in sections other than the Terminology section.  Please
confirm that they should remain where they are or consider if
consolidating them to some kind of "Terminology and Conventions"
section would be helpful to the reader.

Examples below:

Original (Section 4.3):
   This document uses the notation <transport>-foo to refer to the foo
   parameter for the encrypted transport <transport>. 

Original (Section 4.5):

   This document uses the notation E-foo[X] to indicate the value of
   field foo for encrypted transport E to IP address X.-->


4) <!--[rfced] We had a few questions related to the following text:

Original:
2.  Priorities

   This document aims to mitigate potential impacts of the described
   protocol and to aid implementors in selecting between possible DNS
   protocol choices.

2.1.  Minimizing Negative Impacts

   The protocol described in this document aims to minimize potentially
   negative impacts caused by the probing of encrypted transports for
   the systems that adopt these guidelines, for the parties that they
   communicate with, and for uninvolved third parties.

a) Please review these two sentences that appear in close proximity
for redundancy and/or consistency (i.e., the document aims or the
protocol in the document aims?).  Note that similar text also appears
in the Introduction as well.

b) This document has several occurrences similar to "The protocol
described in this document" or "the described protocol" (e.g., see the
first paragraph of Section 3) and later there are many mentions of
"This guidance" or "The guidance provided in this document".  Is a
name of the protocol available to use instead for some of these
instances?

c) In the second sentence, will it be clear to the reader what "these
guidelines" refers to?  Also, we assume "they" refers to "systems".
Perhaps some clarification of this sentence would make this text
easier to get through in a single read.

-->


5) <!--[rfced] In the following, should TC be expanded?

Original:
...and flags (e.g., TC bit) might vary based on the transport.

FYI: We see the following used in past RFCs:

"TrunCation" (TC) bit and Truncation (TC) bit
Traffic Class (TC) bits


-->


6) <!--[rfced] May we update this sentence as follows to avoid the
     "either"/"concurrently" matchup?

Original:
   In addition to querying on Do53, the recursive resolver will try
   either or both of DoT and DoQ concurrently.
   
Perhaps:
   In addition to querying on Do53, the recursive resolver will try
   DoT, DoQ, or both concurrently.
-->


7) <!--[rfced] FYI - We have changed "non-compatible" to "incompatible"
     in the following text. Please review and let us know if this
     alters your intended meaning.

Original:
When any encrypted transport fails, the recursive resolver remembers
that failure for a reasonable amount of time to avoid flooding a
non-compatible server with requests that it cannot accept.

Current: 
When any encrypted transport fails, the recursive resolver remembers
that failure for a reasonable amount of time to avoid flooding an
incompatible server with requests that it cannot accept.
-->


8) <!--[rfced] May we reformat the "Descriptions" in Table 1 to read as
     sentences rather than questions, to match the format of the other
     table in this document?

Originals:
persistence - How long should the recursive resolver remember
successful encrypted transport connections?

damping - How long should the recursive resolver remember unsuccessful
encrypted transport connections?

timeout - How long should the recursive resolver wait for an initiated
encrypted connection to complete?

Perhaps:

persistence - How long the recursive resolver remembers successful
encrypted transport connections

damping - How long the recursive resolver remembers unsuccessful
encrypted transport connections

timeout - How long the recursive resolver waits for an initiated
encrypted connection to complete

-->


9) <!--[rfced] We wanted to clarify a few demonstrative adjectives in
     Section 4.4:

a) Will the reader understand what "this guidance" is referring to as
this is the first paragraph in the section?

Original:

4.4.  Recursive Resolver Requirements

   To follow this guidance, a recursive resolver MUST implement at least
   one of either DoT or DoQ in its capacity as a client of authoritative
   nameservers.  A recursive resolver SHOULD implement the client side
   of DoT.

b) Perhaps "the strategies in this document" or "the strategies
herein" would be a good replacement for "these strategies"?

Original:
   While this document focuses on the recursive-to-authoritative hop, a
   recursive resolver implementing these strategies SHOULD also accept
   queries from its clients over some encrypted transport unless it only
   accepts queries from localhost.

-->


10) <!--[rfced] We had a few questions regarding this text in Section 4.6:

Original:
The subsections that follow offer pseudocode that corresponds roughly
to an asynchronous programming model for a recursive resolver's
interactions with authoritative servers.  The following subsections
also presume that the time of the discovery of the need for lookup is
time T0.

a) Is pseudocode in every subsection?  Or should the text read "Some
of the subsections that follow" or the like?

b) May we update the second use of "The following subsections" to
instead read "These same subsections" or "Subsections 4.6.1-..."?

-->


11) <!--[rfced] Please review this use of "any".

Original:
  The recursive resolver must decide whether to initially send a query
   over Do53, or over any of the supported encrypted transports (DoT or
   DoQ).

Perhaps A:
  The recursive resolver must decide whether to initially send a query
  over Do53 or over either of the other supported encrypted transports
  (DoT or DoQ).

Perhaps B:
  The recursive resolver must decide whether to initially send a query
  over Do53 or over any of the supported encrypted transports (those
  using DoT or DoQ).
-->


12) <!--[rfced] FYI - We have reformatted the steps below to read as a
     bulleted list. Please let us know any objections.

Original:
When sending a query to an authoritative server over encrypted
transport at time T4, the recursive resolver should take a few
reasonable steps to ensure privacy and efficiency.

After sending query Q, the recursive resolver should ensure that Q's
state in E-queries[X] is set to sent.

The recursive resolver also sets E-last-activity[X] to T4.

In addition, the recursive resolver should consider the guidance in
the following sections.

Current:

When sending a query to an authoritative server over encrypted
transport at time T4, the recursive resolver should take a few
reasonable steps to ensure privacy and efficiency.

* The recursive resolver should ensure that Q's state in E-queries[X]
is set to sent after sending query Q.

* The recursive resolver should set E-last-activity[X] to T4.

* The recursive resolver should consider the guidance in the following
sections.

-->


13) <!--[rfced] As the list below only contains one item, may we reformat
     this text to read as a sentence?

Original: 

One reasonable prioritization scheme would be:

  * close outstanding established sessions based on E-last-activity[X]
  (oldest timestamp gets closed first)

Perhaps:

One reasonable prioritization scheme would be to close outstanding
established sessions based on E-last-activity[X] (i.e., the oldest
timestamp gets closed first).
-->


14) <!--[rfced] Would you like the references to be alphabetized or left
     in their current order? -->


15) <!--[rfced] We have the following questions and updates regarding the
     terms below. Please review and let us know any guidance or
     objections.

a. We see both EDNS0 and EDNS(0) used in this document. Please review
and let us know which format you would prefer.

b. FYI - We have adjusted the format of Encrypted Client Hello and
Client Hello to Encrypted ClientHello and ClientHello for consistency
with previous RFCs.

c. FYI - We have removed hyphens from the following terms for
consistency with cited RFCs 8484, 9250, and 7858.

DNS-over-HTTPS
DNS-over-QUIC
DNS-over-TLS

d. FYI - We have added expansions for abbreviations upon first use per
Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review this
expansion in the document to ensure correctness.

DNS-Based Authentication of Named Entities (DANE)
-->


16) <!--[rfced] Please review the following questions regarding this
     document's use of the <tt> element:

a. In the html and pdf outputs, the text enclosed in <tt> is output in
fixed-width font. In the txt output, there are no changes to the font,
and these terms do not appear in quotation marks. Please review the
output files and let us know if quotation marks should be added
anywhere for the ease of the reader or if the document should remain
as is.

For example, would it be more clear to add quotations to the following
as so?

Original:

E-status[X] is success

Perhaps:

E-status[X] is "success"

b. The terms below appear both with and without the <tt>
format. Please review and let us know if any of these instances need
to be updated.

i. IP address

Examples with the <tt> element:
...the authoritative server's IP address <tt>X</tt>.
...to authoritative servers from IP addresses <tt>2001:db8::100</tt> and <tt>2001:db8::200</tt>...

But without:
... when the most recent DoT connection packet was sent to IP address 192.0.2.4.

ii. NS 

Example with the <tt> element: 
A recursive client who associates state with the
<tt>NS</tt> name and... 

But without: 
When doing so, the identity would presumably be based on the NS
name used for a given query or the IP address of the server.

iii. DoT and DoQ
-->


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

In addition, please consider whether "tradition" should be updated for
clarity.  While the NIST website
<https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone.
-->


Thank you.

RFC Editor/kf/mf

*****IMPORTANT*****

Updated 2024/02/12

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/rfc9539.xml
   https://www.rfc-editor.org/authors/rfc9539.html
   https://www.rfc-editor.org/authors/rfc9539.pdf
   https://www.rfc-editor.org/authors/rfc9539.txt

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

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

The following files are provided to facilitate creation of your own 
diff files of the XML.  

Initial XMLv3 created using XMLv2 as input:
   https://www.rfc-editor.org/authors/rfc9539.original.v2v3.xml 

XMLv3 file that is a best effort to capture v3-related format updates 
only: 
   https://www.rfc-editor.org/authors/rfc9539.form.xml


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

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

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9539 (draft-ietf-dprive-unilateral-probing-13)

Title            : Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS
Author(s)        : D. Gillmor, Ed., J. Salazar, Ed., P. Hoffman, Ed.
WG Chair(s)      : Brian Haberman, Tim Wicinski
Area Director(s) : Erik Kline, Éric Vyncke