[dns-privacy] Alexey Melnikov's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Alexey Melnikov via Datatracker <[e-mail]>]

Alexey Melnikov has entered the following ballot position for
draft-ietf-dprive-bcp-op-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I think this is a very useful document and I am looking forward to it getting
published.

I support updated Ben’s DISCUSS.

**********************************************************************
* Note, that I am conducting an experiment when people aspiring to be*
* Area Directors get exposed to AD work ("AD shadowing experiment"). *
* As a part of this experiment they get to review documents on IESG  *
* telechats according to IESG Discuss criteria document and their    *
* comments get relayed pretty much verbatim to relevant editors/WGs. *
* As an AD I retain responsibility in defending their position when  *
* I agree with it.                                                   *
* Recipients of these reviews are encouraged to reply to me directly *
* about perceived successes or failures of this experiment.          *
**********************************************************************

The following comments were provided by Benjamin Schwartz <[e-mail]>:

Benjamin would have balloted *DISCUSS* on this document. He wrote:

This draft is close to ready, but it contains some elements that are not
appropriate for IETF publication or lack IETF consensus.

## Section 1

Typo: “For example the user has a clear expectation of which resolvers have
visibility of their query data however this...” -> Add a period before
“however”.

Inappropriate subject matter:

    It is an untested area that simply using a DNS
    resolution service constitutes consent from the user for the operator
    to process their query data.

This is legal speculation, not appropriate for IETF.  Strike this sentence.

Clarity:

    Privacy considerations specifically
    from the perspective of an end user ... are out of scope.

This seems confusing as written: surely it is the privacy of end users (and not
of resolver operators) that this draft seeks to protect.  Please rephrase or
omit this disclaimer.

## Section 5.1

Version skew: dprive-rfc7626-bis no longer has a Section 2.4.2 or 2.5.3.

## Section 5.1.2

Clarity: Redirection of traffic to rogue servers does not match the usual
definition of “surveillance”.  I would suggest adding an explanation of how
this active attack is a privacy threat.  Presumably you are referring to merely
intercepting the user’s DNS queries, as opposed to substituting modified DNS
responses in order to monitor post-DNS network activity, but the text is not
clear on this distinction.

## Section 5.1.3.1

Current practices:  I don’t think either EDNS(0) Keepalive or DNS Stateful
Operations is currently in use with DNS-over-TLS, so this recommendation seems
too strong for a BCP.  For example, this could say “Management of TLS
connections as described in RFC 7766.  EDNS(0) Keepalive and DNS Stateful
Operations may provide additional performance benefits.”

Scope: The optimizations here are performance optimizations, which seem out of
place in this document.  I would suggest focusing the document on “Encrypted
DNS Service Privacy Recommendations”, and remove any recommendations related to
performance and reliability, which are already well-covered by standards-track
RFCs.

## Section 5.2.1

Content: I think there’s a missing mitigation here, which is employed virtually
universally among large DNS Privacy deployments: IP erasure.  DNS operators
typically distinguish between PII-logs, which are retained at most briefly, and
non-PII logs, which are retained for a longer period.  I believe this is a best
practice and worth documenting.

## Section 5.3.1

Document interaction: This section comes awfully close to updating or
deprecating ECS, which we do not have IETF consensus for.  I think the BCP here
should restrict itself to disclosing the server’s ECS behavior and imposed
prefix length limit.

## Section 6.1.1

Terminology: “PII” appears here for the first time, and is not defined.