[dns-privacy] Paul Wouters' Abstain on draft-ietf-dprive-unilateral-probing-12: (with COMMENT)

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-dprive-unilateral-probing-12: Abstain

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



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

Based on the authors response to my DISCUSS
(https://mailarchive.ietf.org/arch/msg/dns-privacy/mVGvnh3g0Z9O70XeguVNUx59SYk/),
I have updated by ballot to ABSTAIN.

I do not see any use of this draft. In its regular use, the user is still
sending their queries in the clear initially. The draft assumes that after the
initial leak, queries for the same target will be encrypted opportunistically.
I tried pointing out that on most mobile devices, this is not the case due to
frequent network changes and DNS cache purges. Any Operational or Security
Considerations related to this were deemed out of scope. I can only conclude
that no privacy is gained, and that the additional complexity in code is not
worth the effort of implementing.

Additionally, since the draft requires the DNS servers to generate a
certificate, the difference between generating a self-signed certificate, and
using an ACME based certificate that CAN be validated and wouldn't need
unilateral opportunistic security, I see even less reasons to attempt to deploy
this.

As no indications are given back to the user, the draft does the enduser no
harm (other than possibly introducing bugs due to added complexity on the code)
and I see no reason to further block it with a DISCUSS.