Hi Sara! > -----Original Message----- > From: iesg <[email protected]> On Behalf Of Sara Dickinson > Sent: Thursday, May 6, 2021 6:13 AM > To: Roman Danyliw <[email protected]> > Cc: [email protected]; [email protected]; The IESG <[email protected]>; draft- > [email protected]; [email protected] > Subject: Re: Roman Danyliw's No Objection on > draft-ietf-dprive-xfr-over-tls-11: > (with COMMENT) > > > > > On 4 May 2021, at 22:44, Roman Danyliw via Datatracker <[email protected]> > wrote: > > > > 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: > > ——————————————————————————————————— > > Hi Roman, > > Many thanks for the review. > > > > > Section 1. s/can make reconnaissance trivial/can make reconnaissance > > and attack targeting easier/ > > Yes. > > > > > Section 1. Per “… zone walking is now possible with NSEC3 due to > > crypto-breaking advances”, a reference here would be helpful. > > Agreed and requested by another reviewer - let me dig a good one out. > > > > > 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/ > > That seems reasonable.
Thanks for all of the above edits. > > > > 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. > > Another review suggested just adding “(at the time of writing)” to qualify > that > statement. Would that be enough (there are at least 5 implementations we > could name)? That works for me. > > > > Section 1. Editorial. “… must cater for accepting …” doesn’t parse for me. > > “must therefore accept”? > > > > > 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) > > Thats a reasonable point - I’ll add it. FYI - some operators do protect the > NOTIFY > with a TSIG for _some_ added protection. > > > > > 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]. > > Yes - that makes sense here. Thanks. > > > > 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. > > Hopefully addressed in the thread with Ben. No problem. I know a number of us made a related or identical comment. I'll follow along in the DISCUSS made by Ben. > > > > 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? > > I think that any zone that uses IXoT and pads would also always apply AXoT > padding (because IXoT can fall back to AXoT). It would expect the draft on the > specific padding policy would address that in more detail. > > > > > -- Is keeping state required to ensure that padding provides the > > appropriate obfuscation over time? > > Interesting question. Are you thinking about AXoT where the zone could e.g. > grow then shrink? If so, that does seem like a good idea (again - input for > the > follow up padding policy draft - thanks!). Exactly. Changes in sizes would be a prime traffic analysis metric. This obfuscation would have to be consistently maintained to provide protection (to the degree that this obfuscation is robust) against a persistent observer who can take multiple measurements at different points in time. With this comment and the one above it, I appreciate there is a fine line between balancing what's out of scope for a future, detailed specification; and adding design considerations or cautions in a notional architecture specified here. I leave it to you and the rest of author team to assess the right balance as these were just (optional) ballot comments. Regards, Roman > Thanks and regards > > Sara. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
