DNS Query Name Minimisation to Improve Privacy
draft-ietf-dnsop-rfc7816bis-11

[Ballot comment]
Thank you for the work put into this document. A simple but efficient technique.

Thank you also for addressing completely my previous blocking DISCUSS. It is now cleared.

Special thanks to Tim Wicinski for his shepherd's write-up notably about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric


== PREVIOUS DISCUSS (no more valid) ==


-- Section 2.1 --
I support Erik Kline's COMMENT on this and am raising it to a blocking DISCUSS.

A/ in all the discussion in the last §, a AAAA would have the same benefit when compared to a NS QTYPE. Or what did I miss ?

B/ the last two sentences "Another potential benefit...happy eyeballs query for the A QTYPE." are puzzling as using A QTYPE will actually only cache the A answer for the minimized request and more and more Internet users are using IPv6 nowadays (and possibly even more recursive DNS servers).

Hence, I would welcome some discussion in the last § about the benefit of using A QTYPE rather than AAAA QTYPE and, as suggested by Erik Kline, please remove the last 2 sentences.

[Ballot comment]
Thank you for the work on this document.

Thanks to Valery Smyslov for the ART ART review, please address his comment with the next update:

> Nit: RFC 7626, referenced in the document, has been just obsoleted by RFC 9076.

Francesca

[Ballot comment]
Thanks for this document.

I have one question -

* what is a "full cache" as mentioned in the section 5? if not a well known term to describe a cache then please explain it shortly.

[Ballot comment]
I support Eric's discuss, and Erik's comment on 2.1's use of A records.  Specifically, I wonder whether it wouldn't be more forward looking to recommend using AAAA records rather than A records.

[Ballot discuss]
Thank you for the work put into this document. A simple but efficient technique.

Please find below one blocking DISCUSS point (probably easy to address).

Please also address Jean-Michel Combes' INTDR review at https://datatracker.ietf.org/doc/review-ietf-dnsop-rfc7816bis-10-intdir-telechat-combes-2021-08-20/

Special thanks to Tim Wicinski for his shepherd's write-up notably about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric


== DISCUSS ==


-- Section 2.1 --
I support Erik Kline's COMMENT on this and am raising it to a blocking DISCUSS.

A/ in all the discussion in the last §, a AAAA would have the same benefit when compared to a NS QTYPE. Or what did I miss ?

B/ the last two sentences "Another potential benefit...happy eyeballs query for the A QTYPE." are puzzling as using A QTYPE will actually only cache the A answer for the minimized request and more and more Internet users are using IPv6 nowadays (and possibly even more recursive DNS servers).

Hence, I would welcome some discussion in the last § about the benefit of using A QTYPE rather than AAAA QTYPE and, as suggested by Erik Kline, please remove the last 2 sentences.

[Ballot comment]
DOWNREF from this Standards Track doc to Experimental [RFC7816].

"Abstract", paragraph 3, comment:
>    This document is part of the IETF DNSOP (DNS Operations) Working
>    Group.  The source of the document, as well as a list of open issues,
>    is at

Should this not be removed before publication?

Obsolete reference to RFC7626, obsoleted by RFC9076 (this may be on purpose).

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Terms "traditional", "tradition", "Traditionally"; alternatives might be
  "classic", "classical", "common", "conventional", "customary", "fixed",
  "habitual", "historic", "long-established", "popular", "prescribed",
  "regular", "rooted", "time-honored", "universal", "widely used",
  "widespread".

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

"Table of Contents", paragraph 2, nit:
> ed in Section 6.1 of [RFC6973]: the less data you send out, the fewer privac
>                                    ^^^^
Did you mean "fewer"? The noun data is countable. (Also elsewhere.)

Section 1.2. , paragraph 3, nit:
>  is to minimise the amount of privacy sensitive data sent from the DNS resolv
>                              ^^^^^^^^^^^^^^^^^
This word is normally spelled with a hyphen. (Also elsewhere.)

Section 4. , paragraph 1, nit:
> en saved if the incoming QTYPE would have been the same as the QTYPE selected
>                                ^^^^^^^^^^^^^^^
Did you mean "had been"? (Also elsewhere.)

[Ballot discuss]
This is a process DISCUSS (directed at the responsible AD).

The datatracker indicates that the intended status of this document is Internet Standard.  However, two process points are not being followed:

1- The replaced document (rfc7816) is an Experimental RFC.  According to rfc6410, the Standards Track maturity levels first go through a Proposed Standard.

2- rfc6410 requires a 4-week IETF LC to move to Internet Standard, but the LC for this document lasted only 2.


Moving the intended status of this document to Proposed Standard would be one way to address this DISCUSS.

[Ballot discuss]
This is a process DISCUSS.

The datatracker indicates that the intended status of this document is Internet Standard.  However, two process points are not being followed:

1- The replaced document (rfc7816) is an Experimental RFC.  According to rfc6410, the Standards Track maturity levels first go through a Proposed Standard.

2- rfc6410 requires a 4-week IETF LC to move to Internet Standard, but the LC for this document lasted only 2.


Moving the intended status of this document to Proposed Standard would be one way to address this DISCUSS.

[Ballot comment]
The discussion about how many labels to add at each step is rather
spread out amongst Sections 2, 2.3, and 3, and my preference would be to
have a single more-clear specification of behavior for the Proposed
Standard level of publication (but this is just a non-blocking comment
and I recognize that addressing it would require somewhat invasive
changes to the text).

Looking over the diff from RFC 7816, I see that the discussion of empty
non-terminals has been removed.  Is that because the prevalence of
servers that fail to handle them properly in the wild has dropped to an
insignificant level?  (If so, hooray!)  If not, why was the text
removed?

We also removed the discussion of "some broken name servers [that] do
not react properly to QTYPE-NS requests", which is mostly understandable
since we no longer recommend that NS is used as the QTYPE for masking
minimized requests.  I don't know if it's worth retaining this warning
in some form as it might apply to legacy implementations that retain the
RFC 7816 behavior.

Thanks to Donald Eastlake for the secdir review.

I echo the intdir reviewer's question about where "strict mode" of QNAME
minimization is defined.

I also see the genart reviewer's question about whether the number of
labels per iteration can remain large after the division, and I think
that the maximum allowed length of a domain name helps some here, but
would appreciate if someone more familiar with the actual limits ran the
numbers and opined that the resulting number of labels is capped at some
reasonable bound.

Abstract

If the note about the WG and git source is expected to be removed before
publication as an RFC, it seems prudent to note that somewhere (whether
in the visible prose or as a comment in the XML).

Section 2.1

  The QTYPE to use while minimising queries can be any possible data
  type (as defined in [RFC6895] Section 3.1) for which the authority
  always lies below the zone cut (i.e. not DS, NSEC, NSEC3, OPT, TSIG,
  TKEY, ANY, MAILA, MAILB, AXFR, and IXFR), as long as there is no
  relation between the incoming QTYPE and the selection of the QTYPE to
  use while minimising.  [...]

At risk of being overly pedantic, the procedure will still get you the
right answer even if there is a relation between the incoming and
selected QTYPE, so the "can be ... as long as" isn't quite correct.  We
insist on the lack of relationship because that gives better privacy
properties, not because it is required for correct behavior, as I
understand it.

Section 3

  (3) If CHILD is the same as QNAME, or if CHILD is one label shorter
      than QNAME and the original QTYPE can only be at the parent side
      (like QTYPE=DS), resolve the original query as normal starting
      from ANCESTOR's name servers.  Start over from step 0 if new
      names need to be resolved as result of this answer, for example
      when the answer contains a CNAME or DNAME record.

We might want to reference RFC 6672 for DNAME (since we use it later in
step 6 as well).

Section 6

  the amount of data sent also, in part, addresses the case of a wire
  sniffer as well as the case of privacy invasion by the servers.

Who are "the servers"?

Section 7.1

It seems rather unconventional to make a normative reference to the
document being obsoleted (RFC 7816).  It seems like that document would
be more appropriately classified as an informative reference.

Section 7.2

Deferring to RFC 8499 for terminology definitions may well merit
classifying it as a normative reference.


NITS

Thanks for putting the git repo link in the Abstract.  Since I only have
a proposed wording for one of these I didn't go through the effort of
phrasing it in the form of a patch, but it's nice to have the option
available.

Section 3

  (4) Otherwise, add the next relevant label or labels from QNAME to
      the start of CHILD.  The number of labels to add is discussed in
      Section 2.3.

It might be worth being a little more explicit that this is updating the
current value of CHILD, as opposed to producing a new temporary value
consisting of (next relevant label or labels)+CHILD.  (E.g., "Update the
value of CHILD to consist of [...]".)

Section 4

  have been A.  Using the most used QTYPE to hide the original QTYPE
  therefore slightly reduces the number of outgoing queries.

I'd probably say "compared to using any other QTYPE to hide the original
QTYPE".

Section 6

  QNAME minimisation's benefits are clear in the case where you want to
  decrease exposure to the authoritative name server.  But minimising

I'd probably clarify "exposure of what?".

[Ballot comment]
[S2.1 comment]

* It seems to me that using A QTYPEs for Happy Eyeballs clients is
  only a "potential benefit" for an IPv4 connection setup, and does
  nothing to aid any possible IPv6 connection setup.

  There are networks with IPv6-only clients accessing mostly
  IPv6-reachable services for which this might actually slow down
  services (by delaying AAAA resolution resulting in an IPv4
  connection setup that uses something like NAT64 rather than
  native IPv6).

  Suggestion 1: Just trim these HE-related sentences.

  Suggestion 2: Make it clear that this might not always be a "benefit"
                in certain network deployments.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-dnsop-rfc7816bis-09, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-06-07):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-rfc7816bis@ietf.org, tjw.ietf@gmail.com, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DNS Query Name Minimisation to Improve Privacy) to Internet Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'DNS Query Name Minimisation to
Improve Privacy'
  as Internet Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-06-07. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes a technique called "QNAME minimisation" to
  improve DNS privacy, where the DNS resolver no longer always sends
  the full original QNAME and original QTYPE to the upstream name
  server.  This document obsoletes RFC 7816.

  This document is part of the IETF DNSOP (DNS Operations) Working
  Group.  The source of the document, as well as a list of open issues,
  is at




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7816bis/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/4851/



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7816: DNS Query Name Minimisation to Improve Privacy (Experimental - Internet Engineering Task Force (IETF))
    rfc6973: Privacy Considerations for Internet Protocols (Informational - Internet Architecture Board (IAB))

(1) RFC is Standards Track, and this is the correct RFC type.


(2)

Technical Summary:

  This document describes a technique called "QNAME minimisation" to
  improve DNS privacy, where the DNS resolver no longer always sends
  the full original QNAME and original QTYPE to the upstream name
  server.  This document obsoletes RFC 7816.

Working Group Summary:

Working group consensus was strong. There was a delay in updating the document
during WGLC.  This was affected by one of the authors starting a new position
and not having time.


Document Quality:

This document is turning an Experimental document into a standards track document, after having implementations deployed across the internet,
data collected, and analyzed. 


Document Shepherd:  Tim Wicinski
Responsible Area Director: Warren Kumari

(3)  The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth
of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) Authors have no IPR disclosures needed

(8) rfc7816, which this document is obsoleting, has an IPR filed against it: https://datatracker.ietf.org/ipr/2542/

The owners of this IPR have  filed an updated IPR on this document: https://datatracker.ietf.org/ipr/4851/


(9) The WG Consensus on this document is very solid.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are two downward normative references:

    RFC 6973, which is an IAB document which is used as a normative reference
        in many places;

        RFC 7816, which is an experimental document being obsoleted bt this documebnt

(16) This document will obsolete 7816 and that is listed in the abstract and the introduction.

(17) N/A

(18) N/A


(19) N/A

(20) No Yang Necessary

(1) RFC is Standards Track, and this is the correct RFC type.


(2)

Technical Summary:

  This document describes a technique called "QNAME minimisation" to
  improve DNS privacy, where the DNS resolver no longer always sends
  the full original QNAME and original QTYPE to the upstream name
  server.  This document obsoletes RFC 7816.

Working Group Summary:

Working group consensus was strong. There was a delay in updating the document
during WGLC.  This was affected by one of the authors starting a new position
and not having time.


Document Quality:

This document is turning an Experimental document into a standards track document, after having implementations deployed across the internet,
data collected, and analyzed. 


Document Shepherd:  Tim Wicinski
Responsible Area Director: Warren Kumari

(3)  The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth
of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) Authors have no IPR disclosures needed

(8) rfc7816, which this document is obsoleting, has an IPR filed against it:
https://datatracker.ietf.org/ipr/2542/

The owners of this IPR have notified the document shepherd they will be filing
an updated IPR "soon".

(9) The WG Consensus on this document is very solid.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are two downward normative references:

    RFC 6973, which is an IAB document which is used as a normative reference
        in many places;

        RFC 7816, which is an experimental document being obsoleted bt this documebnt

(16) This document will obsolete 7816 and that is listed in the abstract and the introduction.

(17) N/A

(18) N/A


(19) N/A

(20) No Yang Necessary

(1) RFC is Standards Track, and this is the correct RFC type.


(2)

Technical Summary:

  This document describes a technique called "QNAME minimisation" to
  improve DNS privacy, where the DNS resolver no longer always sends
  the full original QNAME and original QTYPE to the upstream name
  server.  This document obsoletes RFC 7816.

Working Group Summary:

Working group consensus was strong. There was a delay in updating the document
during WGLC.  This was affected by one of the authors starting a new position
and not having time.


Document Quality:

This document is turning an Experimental document into a standards track document, after having implementations deployed across the internet,
data collected, and analyzed. 


Document Shepherd:  Tim Wicinski
Responsible Area Director: Warren Kumari

(3)  The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth
of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) Authors have no IPR disclosures needed

(8) rfc7816, which this document is obsoleting, has an IPR filed against it:
https://datatracker.ietf.org/ipr/2542/

The owners of this IPR have notified the document shepherd they will be filing
an updated IPR "soon".

(9) The WG Consensus on this document is very solid.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state.

(15) There are two downward normative references:

    RFC 6973, which is an IAB document which is used as a normative reference
        in many places;

        RFC 7816, which is an experimental document being obsoleted bt this documebnt

(16) This document will obsolete 7816 and that is listed in the abstract and the introduction.

(17) N/A

(18) N/A


(19) N/A

(20) No Yang Necessary