Re: [dns-privacy] I-D Action: draft-ietf-dprive-xfr-over-tls-02.txt
Sara Dickinson wrote: > > On 13 Jul 2020, at 23:35, Tony Finch wrote: > > > > 7 authentication > > Belated responses on this topic! And a few more thoughts from me, pruned for length ... > Well the goal was to compare and contrast the set of existing control > methods - they do all have different properties and we wanted to explain > where TLS fits in with these and be clear it can’t directly replace > them… > > Perhaps authentication is too broad a term for this whole set of > mechanisms. Maybe the split here should be transport independent > verification mechanisms vs TLS…? What I would expect to get from reading this section is how TSIG and X.509 authentication interact (and maybe SIG(0) too), i.e. what the implications are for configuring server ACLs and client credentials. ZONEMD doesn't fit in that context, I think. > We use a v. broad definition of ‘data auth’: “Authentication that the > DNS message data is signed by the party with whom credentials were > shared”, but given your comment I believe better term would be something > like ‘data origin auth’ or ’transfer entity auth'. Right, that's the distinction I was making. But I think this draft only needs to care about the peer authentication because data authentication is unaffected by TLS. (And doesn't affect privacy.) > TSIG gives entity authentication but not guaranteed confidentiality. The > specific threat here is that in principle without authentication a MitM > attack is possible on the TLS connection….. that attack can see not only > the zone transfer requests but more importantly the responses, which is > what we are trying to avoid. Ah, I understand now, thanks. Given that I think you are right to leave out unauthenticated-but-required TLS as an option since it doesn't make much sense. I have not read RFC 8310 properly yet, but if it doesn't discuss why this middle option doesn't provide much extra privacy, then perhaps this draft should have a few words. Otherwise, it all sounds good. Thanks for working on this draft! Tony. -- f.anthony.n.finchhttp://dotat.at/ South Utsire: Northwest 4 or 5, becoming variable 3, then southeast 5 or 6 later. Slight or moderate. Fair. Good.___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] I-D Action: draft-ietf-dprive-xfr-over-tls-02.txt
Sara Dickinson wrote: > > Hi Tony, > > Many thanks for the detailed review! You're welcome! Your changes sound good, so I'll just answer a few quesions... > > 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. > > I don’t believe RFC5936 says anything expliclty about concurrent > transfer behaviour, and while there may not be a use case for it do you > think we should actually prohibit it? > > Of course a server can error any AXFR if it chooses [RFC5936]: > > "To indicate an error in an AXFR response, the AXFR server sends a >single DNS message when the error condition is detected, with the >response code set to the appropriate value for the condition >encountered. Such a message terminates the AXFR session;…” > > so it _could_ already answer SERVFAIL if it didn’t have the resources?, > or REFUSED if a transfer is already underway and it doesn’t want to do > another one? I’m not actually sure what existing implementations do in > this case? (will double check) > > I suppose the advantage of adding an extended error code would be so > that well behaved clients didn’t continue to request transfers that were > going to be refused. BIND at least has had quotas for controlling zone transfer concurrency for aaages, so the answer to this question is out there. I was thinking out loud a bit when I wrote that paragraph, mainly because I was surprised the specs did not AFAICT describe a fairly well-known xfer feature. > > 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. > > No, you are right - that behaviour isn’t explicitly specified there but > the discussion around using message IDs to match responses at the end of > section 4.1.1. suggests/implies intermingling should work. Our draft > doesn’t update RFC5936 at all (at the moment)… I hadn’t thought it > necessary but perhaps we should actually make the normative statements > around the updates to RFC1995 apply to RFC5936 as well for consistency? I thought when reading the draft that it might be a bit clearer if there were sections on stuff applying to xfers in general (connection management, concurrency, etc.) and particular details for axfr and for ixfr. This spec probably does need to update RFC 5936 because 5936 doesn't say anything about IXFR even though there are important details in how IXFR and AXFR interact. > Are you thinking of some text clarifying that servers can send AXoT > responses for different zones intermingled with each other and with IXoT > responses and clients have to handle them? I guess I thought that was > implicit in the RFC7766 model but we could add some clarifying text. > Again though, that would (I think) apply equally for AXFR and IXFR > sharing a connection so perhaps it needs to appear earlier when they are > discussed…. Do you have any error/problem cases in mind, or just > clarifying what needs to be supported? Yes, I was just unsure what degree of intermingling is supposed to be allowed; I don't know enough about this part of the innards of existing implementations to say what the right clarification is, though :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ disperse power, foster diversity, and nurture creativity___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] I-D Action: draft-ietf-dprive-xfr-over-tls-02.txt
> On 13 Jul 2020, at 23:35, Tony Finch wrote: > > I've had a read through and here are a few, er, I mean several things that > caught my eye: > Hi Tony, Many thanks for the detailed review! > > 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. Yes - agree this could be more specific on both topics. Will re-word as suggested. > > 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" :-) Both fixed. > > 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. Agree. These requirements are meant to apply specifically to IXFR-over-TCP so I have created a separate top level section with the title ‘Update to RFC1995 for IXFR-over-TCP’ and moved the normative statements there. > > 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? We didn’t include that in this threat model because that can in principle be discovered by active measurements of the DNS ….but it might be worth a sentence to explain that. > > 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? Not at all - perhaps it needs re-wording. RFC77666 recommended client/server connections be: * one TCP connection for regular queries * one TCP connection for zone transfers * one connection per other transport on top of TCP (the implication being this is used for everything) As an author on RFC7766 I was surprised when I went back to read it and could not remember the specific rationale for it! The intention in this section is to update this guidance to say that all connection based transport should use separate connections for regular queries and zone transfers, just like TCP. So in principle the client/server interaction _could_ look something like: * one TCP connection for regular queries * one TCP connection for zone transfers * one DoT connection for regular queries * one XoT connection for zone transfers * one DoH connection for regular queries * one XFR-over-DoH connection for zone transfers Listing the potential connections out like this might make it more obvious? > > 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? Ah yes - we should have specified REFUSED here as the base RCODE - fixed. > > 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? RFC7828 says "A DNS client that receives a response that includes the edns-tcp- keepalive option with a TIMEOUT value of 0 SHOULD send no more queries on that connection and initiate closing the connection as soon as it has received all outstanding responses." The intention of a 0 keepalive timeout is to stop further use of the existing connection, if the server needs to terminate a particular AXFR immediately then it still needs to close the connection at its end. The mention of abort in this text is misleading I think. I suggest updating: OLD: Note that this requirement, combined with the use of EDNS0 Keepalive, enables AXoT servers to signal the desire to close a connection due to low resources by sending an EDNS0 Keepalive option with a timeout of 0 on any AXoT response (in the absence of another way to signal the abort of a AXoT transfer). NEW: Note that this requirement, combined with the use of EDNS0 Keepalive, enables AXoT servers to signal the desire to close a connection (when existing transactions have competed) due to low resources by sending an EDNS0 Keepalive option with a timeout of 0 on any AXoT response. Aborting an
Re: [dns-privacy] I-D Action: draft-ietf-dprive-xfr-over-tls-02.txt
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
Re: [dns-privacy] I-D Action: draft-ietf-dprive-xfr-over-tls-02.txt
Hi All, The main updates in this version of the draft are: * Significantly update descriptions for both AXoT and IXoT for message and connection handling taking into account previous specifications in more detail * Add use of APLN and limitations on traffic on XoT connections. * Add new discussions of padding for both AXoT and IXoT * Add text on SIG(0) * Update security considerations * Move multi-primary considerations to earlier as they are related to connection handling Best regards Sara. > On 13 Jul 2020, at 17:43, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DNS PRIVate Exchange WG of the IETF. > >Title : DNS Zone Transfer-over-TLS >Authors : Willem Toorop > Sara Dickinson > Shivan Sahib > Pallavi Aras > Allison Mankin > Filename: draft-ietf-dprive-xfr-over-tls-02.txt > Pages : 27 > Date: 2020-07-13 > > Abstract: > DNS zone transfers are transmitted in clear text, which gives > attackers the opportunity to collect the content of a zone by > eavesdropping on network connections. The DNS Transaction Signature > (TSIG) mechanism is specified to restrict direct zone transfer to > authorized clients only, but it does not add confidentiality. This > document specifies use of TLS, rather then clear text, to prevent > zone contents collection via passive monitoring of zone transfers. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dprive-xfr-over-tls-02 > https://datatracker.ietf.org/doc/html/draft-ietf-dprive-xfr-over-tls-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-xfr-over-tls-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] I-D Action: draft-ietf-dprive-xfr-over-tls-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS PRIVate Exchange WG of the IETF. Title : DNS Zone Transfer-over-TLS Authors : Willem Toorop Sara Dickinson Shivan Sahib Pallavi Aras Allison Mankin Filename: draft-ietf-dprive-xfr-over-tls-02.txt Pages : 27 Date: 2020-07-13 Abstract: DNS zone transfers are transmitted in clear text, which gives attackers the opportunity to collect the content of a zone by eavesdropping on network connections. The DNS Transaction Signature (TSIG) mechanism is specified to restrict direct zone transfer to authorized clients only, but it does not add confidentiality. This document specifies use of TLS, rather then clear text, to prevent zone contents collection via passive monitoring of zone transfers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dprive-xfr-over-tls-02 https://datatracker.ietf.org/doc/html/draft-ietf-dprive-xfr-over-tls-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-xfr-over-tls-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
