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

[Benjamin Kaduk via Datatracker <[e-mail]>]

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:
----------------------------------------------------------------------

My understanding is that this point is essentially overtaken by events,
as a similar concern was raised already by Martin D, John, and Roman,
and there is a commitment to update the text already made.  I'm putting
it in at the Discuss level to make sure that I follow-up on the revised
text when it appears.

But, for concreteness: the text in Sections 8.4, 10.4, and 11 treat
cryptographic mTLS, TSIG, and SIG(0) authentication as providing an
equivalent level of protection to the (non-cryptographic) IP ACL.  My
understanding is that IETF consensus is to prefer cryptographic
mechanisms for authentication and authorization, when available.

Relatedly, the text in Section 8.4 says that TSIG/SIG(0) are "not
sufficient to authenticate the client or server", which is technically
true, but also seems misleading.  In XFR scenarios it's not clear that
specific identification (authentication) of the counterparty is
necessary for secure operation, if authorization to receive/send the
zone can be established without specific identification.  My
undersatnding is that, when combined with a strict TLS profile for
server authentication and appropriate trust policy on TLS clients, TSIG
and SIG(0) both serve to provide proof of authorization for the exchange
even though they only provide authentication in the form of group
membership (the relevant key material is typically available to multiple
machines).  As such, don't they provide strong enough cryptographic
protection (and end-to-end, no less!) to be a superior authorization
mechanism than an IP ACL?  (Any resulting text changes may bleed into
Sections 11 and 12 in addition to 8.4, per my COMMENT.)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

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.)

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

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.

   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 [...]

   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/?

   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).

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?

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"?

      *  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).

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.

Section 7.x

Is it possible to give clarity about which sections or which behaviors
are being updated in these respective subsections?

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?)?

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?

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"?

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.

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"?

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)?

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 might also clarify that the EDE code 21 is (likely?) to accompany a
REFUSED RCODE, since we only mention REFUSED in this paragraph.)

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.

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.

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.

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).

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".)

   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.

   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.

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.

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.)

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.

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.

   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...

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).