[dns-privacy] Roman Danyliw's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-dprive-xfr-over-tls-11: 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 DISCUSS and COMMENT positions.


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



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

Section 1.  s/can make reconnaissance trivial/can make reconnaissance and
attack targeting easier/

Section 1.  Per “… zone walking is now possible with NSEC3 due to
crypto-breaking advances”, a reference here would be helpful.

Section 1.  As far as I can tell the work on draft-vcelak-nsec5 has not been
adopted and the draft is expired.  Perhaps this should be signaled via s/This
has prompted further work on an alternative mechanism/This promoted work on an
alternative mechanism/

Section 1.  Per “It is noted that in all of the common open source
implementations …”, as this is a point in time assessment, it would be helpful
to at least mention parenthetically the implementations/version numbers
assessed informally for this conclusion.

Section 1.  Editorial.  “… must cater for accepting …” doesn’t parse for me.

Section 4.

   The threat model does not, however, consider the existence of a zone,
   the act of zone transfer between two entities, nor the identities of
   the nameservers hosting a zone

To further document the assumptions, consider adding that this threat model
doesn’t consider/protect the mechanisms to decide on triggering the zone
transfer (e.g., protecting NOTIFY messages from an active attacker)

Section 6.2.  Per “However it is noted that most widely used open source
authoritative nameserver implementations (including both [BIND] and [NSD]) do
IXFR using TCP by default in their latest releases”, as this document ages,
“latest release” may not be meaningful.  Consider providing a version number
for [BIND] and [NSD].

Section 8.4 and 10.4.  As already mentioned by Martin and John -- It seems like
a strong statement to say that IP ACLs are in the same class of “channel
authentication” as mTLS.

Section 8.8.1.  It’s difficult to assess how effective this notional padding
approach would be for providing traffic analysis protection.  A few thoughts on
the existing text realizing the details are out of scope:

-- Does padding for AXoT need to be coordinated with the padding on IXoT?

-- Is keeping state required to ensure that padding provides the appropriate
obfuscation over time?