Hi Roman and Sara, Here is a good reference for the vulnerability of NSEC3:
https://www.cs.bu.edu/~goldbe/papers/nsec3attacks.pdf On Thu, May 6, 2021 at 08:23 Roman Danyliw <[email protected]> wrote: > 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
