Sara Sorry for belated reply, I took a couple of days off.
Thank you for your detailed reply and actions. I am happy with all proposed changes; for a couple of remaining points, please look below for EV> As soon as a revised I-D is uploaded, then I am initiating the IETF Last Call. Regards -éric -----Original Message----- From: Sara Dickinson <[email protected]> Date: Monday, 29 March 2021 at 15:08 To: Eric Vyncke <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: AD review of draft-ietf-dprive-xfr-over-tls-08 > On 18 Mar 2021, at 15:33, Eric Vyncke (evyncke) <[email protected]> wrote: > > Dear authors, > > Thank you (and extended thanks to the WG) for this document. > > Please find below my AD review of -08 revision of the document. Before proceeding with the publication process, I will appreciate replies about the points below (and possibly a revised I-D). Many thanks for the review! > > - Section 1: please replace the reference to RFC7626 with the 7626bis document, which is already in the RFC editor queue Done. > - Section 1: does the use of legacy RFC 7626 rather than the bis impact the rest of the section ? Not in terms of XFR - the bis makes no updates to the discussion of XFR handling. But your comment on this paragraph prompted me to remove the reference to the draft-vandijk-dprive-ds-dot-signal-and-pin as the discussion in DPRIVE has moved on significantly from when that was first published. I suggest changing the text to: “and some suggestions for how signaling of DoT support by authoritatives might work." > - Section 1: “Some operators use SSH tunneling or IPSec to encrypt the transfer data” is this assertation backed by some public references ? I can’t find any good references for specific deployments even though it is a know technique, but the NIST guide referenced in the next paragraph does also mention it as an option. I propose to remove that specific sentence and update the following paragraph: “Section 8 of the NIST guide on 'Secure Domain Name System (DNS) Deployment' [@nist-guide] discusses restricting access for zone transfers using ACLs and TSIG in more detail. It also discusses the possibility that specific deployments might choose to use a lower level network layer to protect zone transfers, e.g., IPSec." > - Section 1: did you consider adding something about reconnaissance ? I.e., network scanning of an IPv6 prefix is basically impossible but having access to a DNS zone and its AAAA RR makes the reconnaissance trivial Not really, as I think the main concern with zone enumeration has largely been the exposure of the names rather than the IP addresses, but it is a good point. We could add the following text after the bullet points. “Additionally, the full zone contents expose all the IP addresses of endpoints held in the DNS records which can make reconnaissance trivial, particularly for IPv6 addresses." > - Section 4.1: from a logical flow perspective, I would have started with the threat model first, then the confidentiality/authentication/ parts Thanks - that makes more sense. I have changed section 4.1 into section 4 (threat model) and changed the use cases to be section 5 (but also see next answer). > - Section 4: I find the logic of the ‘performance’ point weird because it is not really generated by the document but rather by an upgrade. I suggest to rewrite this part. I think a better title for that section would be something like ‘Design considerations for XoT’ which might better describe what is being listed there? EV> good suggestion > - Some nits usually ‘e.g.’ is surrounded by commas Fixed > - BTW, while I appreciate the trend to replace master by primary, may I suggest to clarify in the terminology section that ‘primary’ means ‘master’ and ‘secondary’ means ‘slave’ ? Up to you as it is a touchy topic but making the linked with the legacy document seems important to me. Really up to the authors. Suggest moving the text on this to be a sub note to the RFC8499 reference which already deals with the legacy terms: “DNS terminology is as described in [@!RFC8499]. Note that as in [@!RFC8499], the terms 'primary' and 'secondary' are used for two servers engaged in zone transfers." > - Section 5.2 last § missing a closing ‘)’ > - Section 5.3.2 please qualify “lag” (I guess serial numbers) > - Section 6, unsure whether “(probably unintentional)" add any value, consider to remove ? All fixed. > - Section 6.4, "one DoH connection" even with the "could hypothetically include" appears a little weird to me The full list of multiple transports was added after a discussion in the WG to clarify the issue. We did think about using DNS-over-QUIC instead, but using a standardised protocol seemed better…. EV> understood > - Section 7, consider expanding the XoT in the section title ? It looks weird in the ToC > - section 7.6, perhaps also expand XoT and ADoT in the section title I tried to use acronyms everywhere after the terminology section where they are defined as I believe the RFC editor tends to ask this? So I’ve actually fixed up a couple of places where that wasn’t true… If you think this is a real readability issue for the section headings then we can change them (I’ve used XoT long enough not to think so!) EV> hmm, the ToC is before the terminology section though ;-) But, let's see what the RFC editor will say. > - section 7.6, §2 "short term,S.S. with regard" typo in S.S. fixed > - section 8, long RTTs are mentioned as a reason to change of preferred primary, but, RTT is only one part of the TCP throughput. Should this be elaborated further ? From my limited knowledge of existing algorithms I believe only the query/response RTT is used (the handshake is not measured), so I’ll clarify that. > - section 8, in " 'parallel primary connection' model" should this be "models” ? No, in this and the previous paragraph we are comparing two different models (unless I missed your point). > - section 9.3.1 " MitM" is not defined and current trend is to replace it with "on path active attacker" (really up to the authors as I do mind) > - section 9.3.3. nits in " client can authentic the” Fixed. > - section 9 and 10, I wonder why section 9 (mechanisms) is not a sub-section of section 10 (I do not really mind though) 9 is the outline of all the possible mechanisms for XFR/XoT, 10 is the specifics of what XoT requires. > - section 11, should there be a "then" in " if AXFRs use AXoT all IXFRs MUST use IXoT” ? fixed > - section 12, the text talks about implementations but I wonder whether the section title should rather be on operations The first two paragraphs are meant as specific notes to implementors, the second 2 are more operations though… I have split them out into a separate sections. > - section 15, should there be a discussion on using simple IP ACL as authentication ? IP spoofing exists ;) Do you mean specifically TCP IP address spoofing for TLS connections? Do you know of a good reference which would be suitable here? EV> indeed the secondary IP address could be spoofed. Alas, no real reference available but I would expect a comment from SEC dir or our SEC ADs on this part. A diff to the -08 version with the suggested updates (and a couple more typos fixed) for you to review is here: https://tinyurl.com/329f65yj Best regards Sara. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
