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? _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
