I've had a read through and here are a few, er, I mean several things that caught my eye:
In the intro, I think it's too strong to say that RFC 5155 was "to prevent" zone enumeration - its abstract says it "provides measures against" which is a more accurate guide to NSEC3's effectiveness. Also the same paragraph could probably be more clear that NSEC5 is not a practical thing (yet? or likely ever?). I.e., neither of them are really useful privacy mechanisms. 4.2 IXFR - RFC 1995 doesn't use RFC 1123-style requirements keywords (and obviously it predates RFC 2119) so I don't think you can say the lower-case "should" is non-normative. Spelling "forth" -> "fourth" :-) The last paragraph in this section should have a cross-reference to the section that describes the new IXFR requirements in detail. If these requirements are supposed to apply to pure TCP as well as IXoT then it's probably worth promoting them to a top-level section to make it more obvious that they exist, independent of TLS. Apart from this paragraph, section 4 looks more like a non-normative summary of existing specifications, which is useful background information, but I think it's helpful to clearly separate normative and informative sections. 4.3 Is it worth discussing information leakage about which zones are present on a secondary? i.e. is that part of the threat model? 5.3 I'm not sure I understand what this section is getting at. Is it saying that a client can have either an XoTCP or an XoTLS connection, but not both? Because it should try to limit itself to one connection of any kind for zone transfers? 5.4 What is the base DNS RCODE for non-XoT traffic on an XoT connection? (extended errors do not have a fixed association with RCODEs) What about non-EDNS queries? 5.6.2 AXoT In the keepalive discussion, is the intention that a server can use a timeout of 0 to abort a connection in the middle of a transfer, or is it supposed to indicate that there can be no more transfers on the connection, but existing transfers in progress are allowed to finish? Is there a reason for allowing concurrent AXFRs of the same zone? Actually, thinking about this more generally, I can't see a way in RFC 5936 for the server to impose backpressure to limit the number of concurrent AXFRs. And there isn't an extended error code for concurrency control or backpressure. If the server had a suitable response, that would allow it to control xfer resources in general, as well as to choose whether or not it wants to allow multiple AXFRs for the same zone at the same time. Still 5.6.2 The connection re-use requirements seem to be restating 5.3 in more detail. Would it be more clear to put these related requierments in the same section? Re pipelining, I can't see in RFC 5936 whether concurrent AXFRs are just concurrent outstanding queries, with all the response messages for one zone sent back-to-back, or whether response messages for different concurrent AXFRs can be interleaved. 5.6.3 padding Why would empty response messages be needed? Isn't it enough to pad the regular response messages that contain RRs? (Or maybe reduce the number of RRs per message and increase the padding if more obfuscation is needed?) Servers need to keep track of zone sizes in order to mitigate CVE-2016-6170 (DoS attack by sending an excessively huge AXFR response) so I would expect servers to be able to use that accounting to decide how to spread padding between AXFR response messages, without the need for extra padding-only messages. 5.7 IXoT Looking back and comparing with section 4.2, it looks like the concurrency requirements in section 5.7 only apply to TLS. Are they supposed to apply to TCP as well? I think it would help to have some more explicit discussion of how IXoT and AXoT share a connection, wrt concurrency, interleaving of response messages (or not), and so forth. Perhaps as a subsection beween 5.5 and 5.6? Or maybe as an expanded 5.3? Also covering other things that are common to IXot and AXoT like keepalive timeouts, concurrency backpressure, presence or absence of EDNS, padding, and anything else I've missed. 7 authentication It seems weird to mix up channel auth and data auth, since they are quite different things. As I understand it, ZONEMD isn't really authentication, it's just an integrity check (unless it is used in a signed zone). And if you are talking about data authentication it seems odd to leave out RRSIGs. TSIG doesn't provide data authentication. It provides mutual authentication of the endpoints, and data integrity, but the server can lie to the client about the zone contents. (The server is not necessarily the ultimate authority for the zone.) It would be useful to have terminology to distinguish between TLS where the client software tries on its own initiative, with fallback to TCP (which is what I think of when I read "opportunistic"); as opposed to TLS configured by the admin without fallback to TCP and without any client or server certificate auth. I'll call the latter "unauth". I don't think strict TLS + TSIG adds any benefits beyond unauth TLS + TSIG, because TSIG already provides mutual auth. Well, there's some risk that the client may send requests to the wrong server, which goes back to my section 4.3 question about whether it is part of the threat model to worry about exposing which zones a client holds. Mutual TLS is roughly comparable to unauth TLS + TSIG, but it has the advantage that it's a bit easier to set up in a way that prevents clients from being able to impersonate the server. If you want to do this with TSIG then every client needs its own key, and the server config has to be updated whenever a client is provisioned or decommissioned. With mutual TLS the server only needs a relatively static CA cert that can authenticate any client cert. I think there should be something in the spec about how certificate subject names relate to how (in strict and mutual TLS) the client authenticates the server, and how (in mutual TLS) the server decides that the client's requests are authorized. I would like to be able to give my client a server name (and optional address) and have it authenticate the server using the system CA cert store and server certificate subjectAltNames. I would like to be able to give my server an ACL containing my private CA cert and a client cert subject name pattern. 8 policies I think the definition of xfer group can be slightly improved, like: We call the entire group of servers involved in XFR for a particular set of zones (all the primaries and all the secondaries) the 'transfer group' for those zones. (My auth servers host multiple sets of zones belonging to several different institutions, with different and partially overlapping transfer groups, with different security configurations...) I think "mTLS" should be written "Mutual" for consistency? Finally, at last ... The figures and tables were missing from the plain text version that I looked at so I didn't review them. I could guess what the diagrams showed but I got the impression that the table in section 7 was a bit more substantive. Tony. -- f.anthony.n.finch <[email protected]> http://dotat.at/ Irish Sea: West or northwest 3 to 5. Smooth or slight, occasionally moderate in south. Showers, then rain later. Good, occasionally moderate. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
