[dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-dtls-and-tls-profiles-09: (with COMMENT)

[Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-dprive-dtls-and-tls-profiles-09: 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-dtls-and-tls-profiles/



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

The final paragraph of section 6.6 says "The system MUST alert by some
means that the DNS is not private during such bootstrap." -- presumably,
this means "client" where it says "system" (as opposed to any other part
of the infrastructure) -- but I'm having a hard time envisioning how this
gets practically implemented, given that the functionality described by
this section is going to be implemented in DNS stub resolver libraries,
which tend to be pretty far removed from any user interface. Given that
this is a MUST-strength requirement, I think it would be very useful to
describe what this alerting might look like for (a) interactive
applications like a web browser; (b) commandline utilities like curl; and
(c) background tasks like software update daemons. This would provide
some context for the library implementors to provide the proper hooks to
enable this "MUST" to be satisfied.

Section 11.1 mentions that it will describe techniques for thwarting DNS
traffic analysis, including "monitoring of resolver-to-authoritative
traffic". I see that there have been measures added to prevent
authoritative servers from determining the identity of the client; but
given the phrasing I cite above, I was expecting a description of how to
prevent eavesdroppers who can see both incoming and outgoing traffic from
the recursive resolver from correlating the encrypted packets I send to
that resolver with the plaintext queries it emits for non-cached results.
As far as I can tell, there are no described counter-measures against
such an attack (aside from hoping that volume of traffic to the resolver
is too great to perform such correlation with any real precision), right?
If such measures have been defined, I imagine a citation would be
warranted. If not, the above phrasing should probably be qualified; e.g.,
"monitoring of resolver-to-authoritative traffic alone."

Nits:
draft-ietf-dprive-dnsodtls has been published as RFC 8094
The draft header indicates that this document updates RFC7858, but the
abstract doesn't seem to mention this, which it should.