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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 04 May 2021 21:44:01 -0700

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

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 5 May 2021 16:09:55 +0100

> On 5 May 2021, at 05:44, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 
> ———————————————————————————————————

Hi Ben, 

> it in at the Discuss level to make sure that I follow-up on the revised

As Allison already stated in reply to Martin, the authors agree that the `dot` ALPN should be used here, in light of the recent discussions. 

In terms of updating the text, I believe what is required is to add a new section at the start of section 8:

"8.1 Connection establishment

During connection establishment the ALPN token “dot” [ref] MUST be selected in the crypto handshake.”

I believe the later text relating to XoT vs ADoT in section 8.6 is still fully applicable, unless you see something you believe also needs updating? 

I will also update the first paragraph of Appendix A to reflect that the main reason for not using a separate ALPN (as originally proposed) is actually because XoT is DNS and so should share the `dot` ALPN. 

> mechanisms for authentication and authorization, when available.

That wasn’t the intention at all, and we are happy to add text to clarify that. 

To address this I would propose the following updates:

Section 8.4:

OLD:
"  o  the server MUST validate the client is authorized to request or
     proxy a zone transfer by using one or both of the following:

     *  an IP based ACL (which can be either per-message or per-
        connection)

     *  Mutual TLS (mTLS)

NEW

"  o  the server MUST validate the client is authorized to request or
     proxy a zone transfer by using one or both of the following:

     *  Mutual TLS (mTLS)

     *  an IP based ACL (which can be either per-message or per-
        connection)

If only one method is selected then mTLS is preferred because it provides strong cryptographic protection."

Section 10.4 (similar to text already proposed to Martin Duke). Add at the end of the second paragraph:

“mTLS provides a stronger authentication of the client than an IP ACL because it is based directly on a cryptographically verified identity.”

Section 11:

OLD:
“The following table summarizes the properties of a selection of the mechanisms discussed in Section 10."
NEW:
"The following table summarizes the high level properties of a selection of the mechanisms discussed in Section 10 (it does not, however, imply that methods that share the same basic property provide equivalent protection.)

OLD:
“ * Using just Mutual TLS can be considered a standalone solution since both end points are cryptographically authenticated.
  * Using Strict TLS and an IP based ACL on the primary also provides authentication of both end points”
NEW:
“  * Using Mutual TLS is a standalone solution since both end points are cryptographically authenticated. This is the preferred mode because it provides the strongest protection.
   * Using Strict TLS and an IP based ACL on the primary also provides authentication of both end points, although here only the server is authenticated cryptographically.”

> Sections 11 and 12 in addition to 8.4, per my COMMENT.)

So I _think_ your question here is why isn’t TSIG also considered a valid option in combination with Strict TLS?

The reason is that TSIG signed requests can be forwarded by a third party. The signature is ONLY over the DNS message payload, so it doesn’t cover the identity of the originator. That means that if only a TSIG is required, the server cannot be sure that the client originating the TLS connection is not an on-path attacker forwarding requests, and therefore inspecting the zone transfer responses. (The real value of TSIG is that the client can be sure the response hasn’t been tampered with and so it has a valid XFR response before applying the update, but in practice it is also widely used today in combination with IP ACLs to limit the sending of XFR responses). 

I think we could improve the text to clarify this. How about:

Section 8.4
OLD:
“The server MAY also require a valid TSIG/SIG(0) signature, but this
  alone is not sufficient to authenticate the client or server.”
NEW:
“The server MAY also require a valid TSIG/SIG(0) signature, but this
  alone is not sufficient to authenticate that the TLS client is authorised to receive a XoT transfer (e.g., is not an on-path attacker forwarding TSIG/SIG(0) signed DNS message payload.)”

And then in section 10 I’ll make clear that only the DNS message payload is signed with TSIG (it currently says ‘message/DNS message’, which is unclear). 

Best regards

Sara.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 5 May 2021 19:12:11 -0700

Hi Sara,

> Thanks for the review. I’m addressing just the DISCUSS points in this mail and will follow up separately on the COMMENTS:

Sounds good.

> During connection establishment the ALPN token “dot” [ref] MUST be selected in the crypto handshake.”

(I'd s/crypto/TLS/, myself, but that's hardly critical.)

> I believe the later text relating to XoT vs ADoT in section 8.6 is still fully applicable, unless you see something you believe also needs updating? 

I also think that part looks fine.

> I will also update the first paragraph of Appendix A to reflect that the main reason for not using a separate ALPN (as originally proposed) is actually because XoT is DNS and so should share the `d…

Good catch; thanks!

> If only one method is selected then mTLS is preferred because it provides strong cryptographic protection."

I think in some sense even being listed as sibling bullet points can imply
"equivalent" for some readers, and accordingly this is not what I see as an
ideal change.  But the new text does acknowledge the qualitative difference
and is something I would be able to accept, even if it is not my most
preferred outcome.

>    * Using Strict TLS and an IP based ACL on the primary also provides authentication of both end points, although here only the server is authenticated cryptographically.”

This seems fine, thanks.

> So I _think_ your question here is why isn’t TSIG also considered a valid option in combination with Strict TLS?

Yes, that's a fair summary.

> The reason is that TSIG signed requests can be forwarded by a third
> party. The signature is ONLY over the DNS message payload, so it doesn’t
> cover the identity of the originator. That means that if only a TSIG is

Yes.  Part of my point is that the specific identity of the originator is
not always needed, if authorization to receive a transfer can be determined
without knowing the actual identity.

> required, the server cannot be sure that the client originating the TLS
> connection is not an on-path attacker forwarding requests, and therefore
> inspecting the zone transfer responses. (The real value of TSIG is that

Yes.  But in order to get into such an on-path position the attacker would
have to compromise the strict TLS required by the original client.  An
attacker that can do that could also inject themself as on-path for a pure
mutual TLS solution.  In this sense we could consider that, when an
(authorized) client sends an XFR+TSIG to a proxy on a TLS connection where
strict server certificate validation has succeeded, the client is
delegating its authorization to receive the XFR to the proxy, and thus that
the proxy is also authorized to receive the transfer.

TSIG of course does allow more than one proxy in a chaing, which does
introduce questions of transitive trust, but I believe that an attacker
that is capable of compromising strict TLS + TSIG is also capable of
compromising mutual TLS.

> the client can be sure the response hasn’t been tampered with and so it
> has a valid XFR response before applying the update, but in practice it
> is also widely used today in combination with IP ACLs to limit the
> sending of XFR responses). 
>

In light of my above remark, while this seems to be an improvement over the
old text, I'm not sure that it's the right end-state.  If we consider
sending XFR+TSIG to an authenticated proxy as a delegation of
authorization, then the TLS client in this case would actually be
authorized to receive the transfer.

> And then in section 10 I’ll make clear that only the DNS message payload is signed with TSIG (it currently says ‘message/DNS message’, which is unclear). 

(This is worth doing regardless of the previous stuff.)

Thanks,

Ben

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 6 May 2021 15:08:34 +0100

> On 6 May 2021, at 03:12, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi Sara,
> 

Hi Ben, 

Thanks for the detailed response.

<snip to remaining issues>

> and is something I would be able to accept, even if it is not my most

One option here is to update the second bullet point to be a combination of IP ACL + TSIG to provide additional protection. As mentioned, this is what is done in practice today by anyone who wants to control TCP zone transfers. TSIG was earlier discounted as a standalone option (see my comment below) and with hindsight I’m surprised we didn’t propose the combination instead. 

<snip>

> the proxy is also authorized to receive the transfer.

One concern is that an attack or misconfiguration that resulted in the client sending the XFR request in clear text would allow the attacker to obtain the signed message for replay. Since this is a migration from a clear text protocol to a TLS based protocol that doesn’t seem impossible. Whereas compromising mTLS directly is somewhat more challenging? 

> that is capable of compromising strict TLS + TSIG is also capable of

And also, because such an clear text message could be sent anywhere along that chain it seemed to exacerbate the problem...

Thanks

Sara.

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 12 May 2021 13:16:16 +0100

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

Hi Ben, 

Thanks for the very detailed review!!

> as things that are consumed entirely independently, even if that is not

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

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

> https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/pull/25

Thank you - that is now merged. 

> leaking it would provide reconaissance into the internal network.

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

>> 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].” ? 

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

> "and" between [RFC2119] and [RFC8174], at least).

Ack to both. 

> somehow, e.g., in terms of current deployments or the common case?

Yes  - I’ll add that qualification. 

> for XoT”?

Sure. 

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

> to assuming XoT-only in a single step.

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

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

> Should we say anything about the demultiplexing strategy here (DNS

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

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

> implementations”?

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

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

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

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

> give any more precise guidance on when the SHOULD from the previous can

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. 

> REFUSED RCODE, since we only mention REFUSED in this paragraph.)

Will do.

> attacker is not very large.

s/complicates/slightly complicates/?

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

> 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

> be used as input to an ACL that performs an authorization check).

Hopefully addressed via the response to the DISCUSS?

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

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

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

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

> just as RFC 8945 is.  (It's a proposed standard so there is no downref

Agree. 

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

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

> there's not much left in the document…

Yes - text got moved - will fix. 

> not provide very solid security properties).

Thanks and regards

Sara.

---

From: Rob Sayre <[email-masked]>
Date: Sat, 15 May 2021 18:02:58 -0700

On Wed, May 12, 2021 at 5:16 AM Sara Dickinson <[email-masked]> wrote:

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

It doesn't seem like the appendix is informative in the sense that someone
could read it and make an informed decision.

It might be better to link to other documents for the concerns listed
(which are valid).

thanks,
Rob

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 18 May 2021 20:08:18 -0700

Hi Sara,

> One option here is to update the second bullet point to be a combination of IP ACL + TSIG to provide additional protection. As mentioned, this is what is done in practice today by anyone who wants…

The combination does seem much more powerful than either alone.  I'd be
happy to see that change, if there's support from the WG for it.

In light of the other topic (below), do we want to consider reformulating
the requirement along the lines of "MUST validate the client is authorized
to request or proxy a zone transfer.  The following methods are deemed
sufficient, and implementations may also use other methods that provide
equivalent or better protection"?

> One concern is that an attack or misconfiguration that resulted in the client sending the XFR request in clear text would allow the attacker to obtain the signed message for replay. Since this is a…

It's a valid concern in migration scenarios, yes.

My preference (as always) would be to get some text in the document that
covers the properties that TSIG+strict-TLS provide, as well as the
perception of risk in the migration scenario that TISG migh be sent without
(strict) TLS and the consequences should that happen.  That would be
useful, IMO, regardless of whether it ends up being a recommended/permitted
option or not.  I am sensitive to concerns about adding a lot of new text
at a late stage without sufficient review, though, so I will ask if you
think we can come up with such text and get it reviewed or not.

> And also, because such an clear text message could be sent anywhere along that chain it seemed to exacerbate the problem...

Yes, that's the "transative trust" issue, where you have to trust everyone
in the path to behave properly and not fall back to cleartext.  There's not
really a good answer for that, which is why end-to-end protections get a
lot of attention...

Thanks,

Ben

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 20 May 2021 11:49:33 +0100

> On 19 May 2021, at 04:08, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi Sara,
> 

Hi Ben,

<snip>

> happy to see that change, if there's support from the WG for it.

I’ve chatted with a couple of the other authors and we suggest that we make this change (and any other changes needed for consistency) in the next version and discuss the level of review required with AD/chairs?

> equivalent or better protection”?

I would personally be reluctant to make that change (as would the other authors). The introduction discusses that there are a variety of other ways to protect zone transfers. I would argue we should clearly define exactly what constitutes ‘XoT’ as per this specification, rather than leave it open ended. 

> covers the properties that TSIG+strict-TLS provide, 

There are a couple of places that need tweaks for the move to the combined IP+TSIG model - I think the required update to the bullet points in section 11 Section (describing the properties of the combined mechanisms) should address this.

> as well as the

We do already give a general warning in section 12: 

“  An individual zone transfer is not considered protected by XoT unless
   both the client and server are configured to use only XoT, and the
   overall zone transfer is not considered protected until all members
   of the transfer group are configured to use only XoT with all other
   transfers servers (see Section 13).”

and later in the same section we touch on how to test/validate this. Section 14 highlights to use ‘migration mode’ with care. So assuming the IP+TSIG combination is a MUST, I’m not sure we need to add a specific call out for cleartext TSIG here? 

Best regards

Sara.