Re: [dns-privacy] Benjamin Kaduk's Discuss on draft-ietf-dprive-xfr-over-tls-11: (with DISCUSS and COMMENT)

[Sara Dickinson <[e-mail]>]

> On 5 May 2021, at 05:44, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-dprive-xfr-over-tls-11: Discuss
> 
> 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/
> 

> ----------------------------------------------------------------------
> DISCUSS:
> ———————————————————————————————————

<snip> as this was responded to in a separate email

> 
> ----------------------------------------------------------------------
> COMMENT:
> ———————————————————————————————————

Hi Ben, 

Thanks for the very detailed review!!

> 
> I support Martin D's discuss about using the DoT ALPN value.
> 
> The Introduction might mention the three documents being updated (in
> addition to the Abstract and the dedicated document sections for
> effectuating the updates).  We typically treat Abstract and Introduction
> as things that are consumed entirely independently, even if that is not
> always true in practice.

I have already suggested this text in response to similar comments:

“Additionally, this specification updates RFC1995 and RFC5936 with respect to efficient use of TCP connections, and RFC7766 with respect to the recommended number of connections between a client and server for each transport."

> 
> Both Abstract and Introduction could probably stand to say a bit more
> about how this document is also providing general updates and
> optimizations for DNS-over-TCP behavior (mostly, but not entirely, for
> XFR-over-TCP), in addition to the details of XoT itself.  (This is
> understandable since providing support for XoT is a convenient milestone
> that other updates can be attached to.)

You are right, it says nothing about those updates, thanks for pointing that out. So perhaps text at the very end of the Introduction to say:

"This document also updates the previous specifications for zone transfers to clarify and extend them, mainly with respect to TCP usage:

* [RFC1995] (IXFR) and [RFC5936] AXFR are both updated to add further specification on efficient use of TCP connections
* Section 6.2.2 of [RFC7766] (DNS Transport over TCP - Implementation Requirements) is updated with a new recommendation about the number of connections between a client and server for each transport.

> 
> Thank you for updating in account of the genart reviewer; that saved me
> a few comments.
> 
> I made some editorial suggestions via a github pull request at:
> https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/pull/25

Thank you - that is now merged. 

> 
> Section 1
> 
>   In what way is exposing the full contents of a zone a privacy risk?
> 
> Brainstorming, in split-DNS scenarios the contents of the "internal"
> zone might only be intended for authenticated+authorized users, and
> leaking it would provide reconaissance into the internal network.

Indeed - we can add that in the fourth paragraph:
“particularly for IPv6 or private networks"

> 
>   hard to enumerate an DNSSEC signed zone as an unsigned zone).  Whilst
>   this is widely used, zone walking is now possible with NSEC3 due to
>   crypto-breaking advances.  This has prompted further work on an
>   alternative mechanism for DNSSEC authenticated denial of existence -
>   NSEC5 [I-D.vcelak-nsec5] - however questions remain over the
>   practicality of this mechanism.
> 
> Do we want to consider direct reference(s) for "crypto-breaking
> advances" instead of leaving a layer of indirection through the nsec5
> draft?
> 
> I would also strongly suggest demystifying the NSEC3 zone-walking
> mechanism and not suggesting that there has been a magic break against
> cryptographic hashes.  If I understand correctly, a mechanism roughly
> analogous to the classical NSEC-walking mechanism is used to enumerate
> the hash intervals in the zone, and then a standard brute-forcing
> mechanism is applied to the hash values, facilitated by knowledge of the
> structure of domain names (and optionally the statistical distribution
> of domain names as well).  So this might instead become:
> 
>> Whilst this is widely used, zone walking is also possible with NSEC3.
>> The initial procedure finds the hashed forms of the names in the zone,
>> and using the known properties and distributions of domain names,
>> brute-force attacks to recover the un-hashed names are feasible.  This
>> has prompted further work […]

Allison has suggested: https://www.cs.bu.edu/~goldbe/papers/nsec3attacks.pdf <https://www.cs.bu.edu/~goldbe/papers/nsec3attacks.pdf>, which is a great reference, so perhaps we can just say:

 "Whilst this is widely used, it has been demonstrated that zone walking is possible for precomputed NSEC3 using attacks such as those described in [ref].” ? 

> 
>   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.
> 
> I think the wording might be off, here, perhaps s/lower level network
> layer/lower level security layer/?

The phrase ‘lower level network layer’ is what is used in the NIST guide itself but your suggestion would be better.

> 
>   Because both AXFR and IXFR zone transfers are typically carried out
>   over TCP from authoritative DNS protocol implementations, encrypting
>   zone transfers using TLS, based closely on DoT [RFC7858], seems like
>   a simple step forward.  This document specifies how to use TLS (1.3
>   or later) as a transport to prevent zone collection from zone
>   transfers.
> 
> This seems to be the first standalone mention of TLS, so an RFC 8446
> reference is probably appropriate.

> 
> Section 3
> 
> Please use the boilerplate from RFC 8174 verbatim (it does not have an
> "and" between [RFC2119] and [RFC8174], at least).

Ack to both. 

> 
> Section 4
> 
>   o  an attacker who can monitor network traffic can relatively easily
>      infer relations between nameservers simply from traffic patterns,
>      even when some or all of the traffic is encrypted
> 
> This is generally true, though I could construct some scenarios (e.g.,
> using draft-ietf-ipsecme-iptfs) where it would not hold.  This would
> generally only be achievable for the defender at significant cost in
> unneeded ("chaff") traffic, though.  Should we qualify this statement
> somehow, e.g., in terms of current deployments or the common case?

Yes  - I’ll add that qualification. 

> 
> Section 5
> 
> I suggest including a preface to the list, other than the section title.
> Perhaps "The following principles [are/were] considered in the design
> for XoT”?

Sure. 

> 
>      *  Current usage of TCP for IXFR is sub-optimal in some cases i.e.
>         connections are frequently closed after a single IXFR.
> 
> Perhaps say something about how XoT is an opportunity to improve
> performance by providing different guidance, as was done for the
> "backwards compatibility" sub-bullet?
> 
> Section 6.3
> 
>   Since the SOA of the published zone can be trivially discovered by
>   simply querying the publicly available authoritative servers leakage
>   of this RR is not discussed in the following sections.
> 
> It seems it *is* discussed, though, in the context of hidden primaries or
> secondaries (which is qualitatively different from "the published zone"
> and thus not quite in conflict with the first part of the claim).

s/of this RR/of this RR via such a direct query/?

> 
> Section 7
> 
>   o  remove any need for XoT implementations to support legacy behavior
>      that XFR-over-TCP implementations have historically often
>      supported
> 
> I'm not sure I follow the reasoning for "remove any need".  If an
> authoritative resolver implementation that supports XoT also needs to
> talk to any non-XoT-supporting primary or secondary, it seems like it
> may still need that legacy behavior.  I see how an XoT-only
> implementation can divest the legacy baggage, but don't think we can get
> to assuming XoT-only in a single step.

s/legacy behaviour/legacy behaviour for XoT connections/?

> 
> Section 7.x
> 
> Is it possible to give clarity about which sections or which behaviors
> are being updated in these respective subsections?

Not for RFC1995, it said nothing in detail about TCP connections but I can add references to the two sections in RFC5936 that do mention TCP.

> 
> Section 7.2
> 
>   zones).  The response streams for concurrent AXFRs MAY be
>   intermingled and AXFR-over-TCP clients compliant with this
>   specification which pipeline AXFR requests MUST be able to handle
>   this.
> 
> Should we say anything about the demultiplexing strategy here (DNS
> header message ID?)?

I don’t _think_ it is needed, it is spelled out in both RFC7766 (and in RFC5936). 

> 
> Section 7.3.2
> 
>   o  pipeline such requests (if they pipeline XFR requests in general)
>      and MAY intermingle them
> 
> I don't think I understand what it means to intermingle *requests* (vs
> responses).  Is this defined somewhere that could be referenced?

It is simply clarification that the client can send an IXFR, an AXFR then an IXFR, etc. (we were asked to make this explicit).

s/MAY intermingle them/MAY intermingle AXFR and IXFR requests/ ?

> 
> Section 7.3.5
> 
>   Certain legacy behaviors were noted in [RFC5936], with provisions
>   that implementations may want to offer options to fallback to legacy
>   behavior when interoperating with servers known not to support
>   [RFC5936].  For purposes of interoperability, IXFR and AXFR
>   implementations may want to continue offering such configuration
>   options, as well as supporting some behaviors that were
>   underspecified prior to this work (e.g., performing IXFR and AXFRs on
>   separate connections).  However, XoT implementations should have no
>   need to do so.
> 
> Similarly to my remark on Section 7, does this only hold for "XoT-only
> implementations”?

As above, s/XoT implementation/XoT connections/?

> 
> Section 7.4
> 
> Just to check my understanding, these updates to RFC 7766 apply for all
> cases, not just XFR (in contrast to the Section 7.3 updates, which only
> apply for XFR scenarios)?  I wonder if this could be emphasized somehow
> (as well as that these updates apply for regular DNS over TCP, not just
> DoT), though I don't have any ideas at the moment.

The text in RFC7766 for TCP isn’t changed, just the text relating to the number of TLS connections. RFC7766 recommended a single TLS connection with no distinction of purpose, the update makes the TLS recommendation the same as the TCP one, so yes, it is more general than _just_ XFR. A minor update to this sentence might help

“This specification for XoT updates the guidance in [RFC7766] to
   provide the same separation of connection purpose (regular queries
   and zone transfers) for all transports being used on top of TCP.”

s/guidance/general connection guidance/?

> 
> Section 8.1
> 
>   For improved security all implementations of this specification MUST
>   use only TLS 1.3 [RFC8446] or later.
> 
> (nit) improved over what baseline?
> Perhaps "In order to provide the highest level of security protections”?

As mentioned in another review - stub to recursive DoT [RFC7766] only required TLS 1.2 or later. But will remove that comparison text. 

> 
> Section 8.3
> 
> (nit) is there some reason why the SOA request/response exchange could
> not be done on an unencrypted TCP connection (not that there would be
> much reason to do so if TCP/TLS is to be used for the actual XFR)?

No, if no connection is open then TCP can be used, if the TLS connection is already open then it would be easier to use that. We wanted to leave the choice up to the implementation. 

> 
> Section 8.7
> 
>   error or fallback path when queries were refused.  As a result the
>   client behavior could vary significantly.  XoT servers that refuse
>   queries must cater for the fact that client behavior might vary from
>   continually retrying queries regardless of receiving REFUSED to every
>   query, or at the other extreme clients may decide to stop using the
>   server over any transport.  [...]
> 
> This (non-normative) requirement seems vague and unactionable.  Can we
> give any more precise guidance on when the SHOULD from the previous can
> be ignored?

We intentionally didn’t add normative guidance here. This is actually just a heads up to server implementers to remind them that just because they are sending an EDE on a XoT connection, they can’t count on the client understanding it. And because there is no clear specification for how clients should behave when receiving REFUSED today, then EDE doesn’t solve the current problems with clients doing different things when they get a REFUSED. 

> (We might also clarify that the EDE code 21 is (likely?) to accompany a
> REFUSED RCODE, since we only mention REFUSED in this paragraph.)

Will do.

> 
> Section 8.8.1
> 
>   Note that the re-use of XoT connections for transfers of multiple
>   different zones complicates any attempt to analyze the traffic size
>   and timing to extract information.
> 
> I might try to hedge this statement a bit.  While it is technically true
> that analyzing the combined transfer is more complicated than analyzing
> individual transfers in isolation, past experience in traffic analysis
> (combined with the ability to query the live serial numbers of the
> domains being served) suggests that the additional burden on the
> attacker is not very large.

s/complicates/slightly complicates/?

> 
> Section 8.9.3
> 
> I'd suggest mentioning the possibility that a client will have to send
> dummy IXFR requests in order to achieve the strongest level of
> obfuscation (thus triggering dummy responses that do not correspond to
> actual zone updates).  I don't have a great sense for how many ways such
> dummy requests can be formed (is just asking for a repeat of the
> previously requested delta going to work?) or whether it is worth
> emphasizing that servers will need to be prepared to handle such
> requests, though.
> 
> We don't need to specify the actual mechanism here, just raise awareness
> that some mechanism might be used/defined in the future.

So perhaps we can update this text, which is at the end of both section 8.8.1 and 8.9.3:

OLD:
   Detailed considerations of such policies and the trade-offs involved are expected to be the subject of future work.

NEW:
   Detailed considerations of such padding policies, the use of traffic obfuscation techniques (such as ‘dummy' traffic), and the trade-offs involved are expected to be the subject of future work.

> 
> Section 9
> 
> The way we describe two potential options for policy on secondaries for
> selecting which primary to request XFR from risks running afoul of the
> RFC 7127 characterization that proposed standards have "resolved known
> design choices".
> 
> I am choosing to not ballot Discuss on this topic because the scenario
> is predicated on there existing a multi-primary configuration, which
> suggests that any server that is primary is authorized to be a source of
> the data, and thus that there is not supposed to be a difference in end
> result regardless of which primary is selected.

I’m not sure what change you are requesting here that could resolve this…?

* Clarify the language to list more clearly when each option should be used or
* Move this section to e.g. the ‘Implementation Considerations’ or a (non-normative) Appendix

> 
> Section 11
> 
> In the vein of my discuss point, it's not entirely clear whether it's
> more important to focus on client authentication or client
> authorization.  TSIG and SIG(0) seem to be better modeled as
> authorization mechanisms than authentication ones (in addition to
> providing DO as already indicated), and considering the questino of
> authorization to initiate XFR may be more relevant to operational needs
> than specifically authentication of the client (which is just going to
> be used as input to an ACL that performs an authorization check).

Hopefully addressed via the response to the DISCUSS?

> 
> Section 12
> 
>   Within any transfer group both AXFRs and IXFRs for a zone MUST all
>   use the same policy, e.g., if AXFRs use AXoT then all IXFRs MUST use
>   IXoT.
> 
>   In order to assure the confidentiality of the zone information, the
>   entire transfer group MUST have a consistent policy of requiring
>   confidentiality.  If any do not, this is a weak link for attackers to
>   exploit.
> 
> These two requirements seem to be at least partially redundant.  It's
> also not entirely clear to me how useful it is to preclude the
> possibility of a mixed environment where all the protocols used provide
> equivalent levesl of confidentiality protection.  (The latter
> requirement on protecting confidentiality does not preclude this
> possibility, to be clear, just the example policy of "MUST use XoT”.)

I think the text here is slightly out of date compared to earlier versions where the authentication requirements were not as clear and so it should be updated (some of these suggestions might change slightly depending on the outcome of the DISCUSS).

For this text I would suggest: 

“In order to assure the confidentiality of the zone information, the
  entire transfer group MUST have a consistent policy of using XoT.  If any do not, this is a weak link for attackers to
  exploit.  For clarification, this means that within any transfer group both AXFRs and IXFRs for a zone MUST all
  use XoT. “


> 
>   A XoT policy should specify
> 
>   o  What kind of TLS is required (Strict or Mutual TLS)
> 
>   o  or if an IP based ACL is required.
> 
>   o  (optionally) if TSIG/SIG(0) is required
> 
> I'm not sure this is a clear way to spell the required behavior.  In
> particular, my understanding is that strict TLS is always required, plus
> at least one of TLS client authentication (for mutual TLS) or IP ACL.
> The rest of the document suggests that TSIG/SIG(0) is an orthogonal
> axis, but my understanding is that TSIG/SIG(0), as cryptographic
> mechanisms, would be preferred over the IP ACL, and in fact that they
> would fill the roll well enough to be able to serve as a third option
> alongside TLS client authentication and IP ACL.  I understand that some
> changes to the exposition in this area are in preparation based on the
> feedback already received from Martin D, John, and Roman, and may have
> further comments when the updated text is available.

And re-org this:

“ A XoT policy should specify

  o  If Mutual TLS is used or

  o  if an IP based ACL in combination with TSIG/SIG(0) is used."

> 
>   Certain aspects of the Policies can be relatively easily tested
>   independently, e.g., by requesting zone transfers without TSIG, from
>   unauthorized IP addresses or over cleartext DNS.  Other aspects such
>   as if a secondary will accept data without a TSIG digest or if
>   secondaries are using Strict as opposed to Opportunistic TLS are more
>   challenging.
> 
> (Pedantically, I don't think it would be very hard to acquire a
> certificate+private key that could be used to produce a TLS connection
> that would succeed if the secondary is using opportunistic TLS and fail
> under strict TLS -- a self-signed certificate not expected to be trusted
> would likely suffice.  That said, I don't dispute the "more challenging"
> characterization, since the operational consequences of actually using
> that mechanism to test the behavior of the secondary could be
> significant.)
> 
> Section 14
> 
> Is there anything useful to say about a hidden primary setup where the
> primary serves only XFR and not regular queries?  Off the top of my
> head it might allow for enforcing the IP ACL sooner, before an actual
> XFR request is seen, but I expect that my insight is not the most useful
> contribution in this space.  Similarly, such a hidden primary might
> reject all non-TLS connections, etc.

Hmm... I’m not sure there is a huge difference between a hidden primary that does XoT and one that doesn't in terms of managing connections because they should both only ever receive queries from other servers in the transfer group (not recursives). And they would both need to answer for SOA queries over clear text. 

> 
> Section 16
> 
>   Both items 1. and 2.2. listed above require the client (secondary) to
>   authenticate the server (primary) using a configured authentication
>   domain name if XoT is used.
> 
> I recognize that this section is to be removed for publication, but
> knowing what is used as the X.509 trust store along with the configured
> authentication domain name would be interesting.

They both employ the same logic as used in DoT implementations - the default client certificate store (with a configuration option to specify a custom location).

> 
> Section 21.2
> 
> Though RFC 2931 is not referenced in many places, the prose does have
> some MAY-level guidance to use TSIG and SIG(0) as providing equivalent
> protection, so I think that RFC 2931 should be classified as normative
> just as RFC 8945 is.  (It's a proposed standard so there is no downref
> issue.)

Agree. 

> 
> I guess that RFC 6891 is going to be transatively normative by way of
> Extended DNS Errors and RFC 7828, but I'm not going to insist that it be
> classified directly as normative here.
> 
> Section A.3
> 
> I'm extremely reluctant to suggest using SNI in this manner (as an
> impromptu authorization bearer token, akin to port knocking).  At a
> protocol level it would be just as easy to configure the use of TLS with
> pre-shared key, that would provide real security.  Note that as of RFC
> 8773 it is permitted to use a PSK and certificate authentication in
> combination, so use of PSK in this manner would not (again, at the
> protocol level) impede security.  Implementation support is probably
> lacking on this front, but that's no different than the currently
> described mechanism...
> 
> Because this topic relates to TLS usage, I have started an email thread
> with the TLS WG for it:
> https://mailarchive.ietf.org/arch/msg/tls/ZIPo1mF_wnOXkgS7Uv_wzIBFmR8/
> 
> The tentative recommendation so far is in rough agreement with my
> instincts, and suggest removing the entire appendix.

There was a discussion at IETF108 about using ALPN to distinguish between XoT and ADoT - the results was the clarification that ALPN should not be used for that purpose and requests by several people that the document outline the other mechanisms that could be used by operators (including SNI, which was mentioned). Appendix A was added in response to those requests and so removing it entirely at this stage feels like the wrong thing. 

Obviously if there is text that needs updating/correcting though, that should be done. Do you have some specific text you would like to see added to the cons for this section and A.4.1 to clarify/deter its use? 

> 
> Section A.4
> 
>   Some primaries might rely on TSIG/SIG(0) combined with per-query IP
>   based ACLs to authenticate secondaries.  In this case the primary
>   must accept all incoming TLS connections and then apply a TLS
>   specific response policy on a per query basis.
> 
> (nit) Is this actually necessarily a "TLS-specific" response policy?
> IIUC essentially the same procedures apply today for DNS-over-TCP XFR.

We could change the title to ’Transport specific’ and fix up the first paragraph?

> 
>   Cons: The server must handle the burden of accepting all TLS
>   connections just to perform XFRs with a small number of secondaries.
>   Client behavior to REFUSED response is not clearly defined (see
>   below).  [...]
> 
> (nit) Is this still "below"?  I recall discussion of this up in §8.7 and
> there's not much left in the document…

Yes - text got moved - will fix. 

> 
> Section A.4.1
> 
> (Similar concerns as for A.3, above, apply to this (ab)use of SNI.
> I expect there are other superior mechanisms here, as well, though did
> not think about it much.  Even defining a new TLS extension (the policy
> is only "specification required") would be an improvement (though still
> not provide very solid security properties).


Thanks and regards

Sara.