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

[Benoit Claise <[e-mail]>]

Benoit Claise 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:
----------------------------------------------------------------------

Here is Eric Vyncke's OPS DIR review:

>From the abstract: This document discusses Usage Profiles, based on one
or more authentication mechanisms, which can be used for DNS over
Transport Layer Security (TLS) or Datagram TLS (DTLS).  This document
also specifies new authentication mechanisms. DPRIVE (DNS Private
exchange) aims at enhancing DNS privacy by encrypting the DNS traffic
(DNSsec only provides authentication/integrity).

There are two profiles: strict and opportunistic. The latter allows
normal DNS operations as a fallback, which is key for successful
deployment. 

This document in section 6  compares the SIX different authentication
mechanisms and gives some guidelines with a lot of SHOULD and MAY and
little MUST. Unsure whether it makes the implementers' task easy. Section
8 is more directive and more useful.

Section 7.3 is mainly about the legacy DHCP server for the legacy IPv4.
No word about IPv6 and no word about RFC 8106 (DNS info for SLAAC).

Overall, there are no discussion about the performance (latency, load of
clients/servers) of one authentication mechanism compared to the others,
no discussion about resilience (i.e. if one server fails, for example in
the PKIX cert chains) and I believe that performance and resilience to
network error could be useful for the implementer/architect.

As a reader, I regret that this document combines two aspects:
description of the profiles but also how to extend one TLS authentication
method to DTLS... I would have preferred having two documents. But, this
is mainly about readability.