Skip to main content

DNS Zone Transfer over TLS
draft-ietf-dprive-xfr-over-tls-12

Revision differences

Document history

Date Rev. By Action
2024-01-26
12 Gunter Van de Velde Request closed, assignment withdrawn: Jouni Korhonen Last Call OPSDIR review
2024-01-26
12 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2021-08-17
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-07-23
12 (System) RFC Editor state changed to AUTH48
2021-07-19
12 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2021-07-19
12 Tero Kivinen Assignment of request for Last Call review by SECDIR to Russ Mundy was marked no-response
2021-07-09
12 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-06-16
12 (System) IANA Action state changed to No IANA Actions from In Progress
2021-06-16
12 Cindy Morgan Downref to RFC 6973 approved by Last Call for draft-ietf-dprive-xfr-over-tls-12
2021-06-11
12 (System) RFC Editor state changed to EDIT
2021-06-11
12 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-06-11
12 (System) Announcement was received by RFC Editor
2021-06-11
12 (System) IANA Action state changed to In Progress
2021-06-11
12 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2021-06-11
12 Amy Vezza IESG has approved the document
2021-06-11
12 Amy Vezza Closed "Approve" ballot
2021-06-11
12 Amy Vezza Ballot approval text was generated
2021-06-11
12 Éric Vyncke As the -12 has addressed all DISCUSS points and the DISCUSS owners have cleared their DISCUSS.
2021-06-11
12 (System) Removed all action holders (IESG state changed)
2021-06-11
12 Éric Vyncke IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2021-06-08
12 Benjamin Kaduk
[Ballot comment]
Thanks for addressing my Discuss points and most of my comments as well.
The original COMMENT section is preserved below for archival purposes. …
[Ballot comment]
Thanks for addressing my Discuss points and most of my comments as well.
The original COMMENT section is preserved below for archival purposes.

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).
2021-06-08
12 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2021-06-03
12 Martin Duke [Ballot comment]
Thanks for addressing my DISCUSS.
2021-06-03
12 Martin Duke [Ballot Position Update] Position for Martin Duke has been changed to No Objection from Discuss
2021-05-27
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-05-27
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2021-05-27
12 Sara Dickinson New version available: draft-ietf-dprive-xfr-over-tls-12.txt
2021-05-27
12 (System) New version approved
2021-05-27
12 (System) Request for posting confirmation emailed to previous authors: Allison Mankin , Pallavi Aras , Sara Dickinson , Shivan Sahib , Willem Toorop
2021-05-27
12 Sara Dickinson Uploaded new revision
2021-05-06
11 (System) Changed action holders to Éric Vyncke, Sara Dickinson, Allison Mankin, Willem Toorop, Shivan Sahib, Pallavi Aras (IESG state changed)
2021-05-06
11 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2021-05-06
11 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2021-05-06
11 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2021-05-06
11 Robert Wilton
[Ballot comment]
Hi,

Thank you for this document.

I was surprised by the length of this document - i.e., 40 pages to say to use …
[Ballot comment]
Hi,

Thank you for this document.

I was surprised by the length of this document - i.e., 40 pages to say to use TLS rather than TCP, and noting that DoH is only 20 pages long!

But in reality, this document seems to be more than just zone transfers over TLS and seems to clarify/optimize various behavior related to using TCP connection handling.

I have a few concrete suggestions that you are at liberty to handle as you see fit:

(1) Please ensure that the abstract accurately summarizes the focus on the document, with a sentence of two summarizing the updates to RFC1995, RFC5936 and RFC7766.

(2) I presume that section 21.3 is intended to be deleted (since the references appear to only be from section 16 which is planned to be removed), if so adding a RFC editor note would be helpful.

(3) It wasn't clear to me whether the text in the appendix is meant to be normative or illustrative.  It might be helpful to be clear which it is meant to be.

Regards,
Rob
2021-05-06
11 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2021-05-05
11 Murray Kucherawy
[Ballot comment]
With my BCP 14 language complainer hat on:

Section 7:

* "Implementations SHOULD use [RFC7828] [...] to manage persistent connections." -- …
[Ballot comment]
With my BCP 14 language complainer hat on:

Section 7:

* "Implementations SHOULD use [RFC7828] [...] to manage persistent connections." -- since this is a SHOULD, can you suggest why an implementer might opt not to do this?  Section 7.3.1 does a great job of handling the SHOULD it presents, for example.

Sections 7.3.2 and 7.3.3:

* Same issue as above with the SHOULDs here.

Section 7.4:

* "Therefore, it is RECOMMENDED that [...] there SHOULD be no more than [...]." -- I don't know how to reconcile this RECOMMENDED-SHOULD combination in the same sentence.  I suggest that the first clause can be dropped with no loss of meaning.

Everything else is nits, some of which were probably also mentioned by others:

Section 1:

* "authoritatives" should probably be "authoritative nameservers"

* "authenticated denial of existences records" -- s/existences/existence/

Section 4:

* "The proposed mechanisms does not attempt" -- s/does/do/, or s/mechanisms/mechanism/

Section 6:

* "term is used to encompasses" -- s/encompasses/encompass/, or remove "is used to"

Sections 6.1 and 6.2

* "higher than the secondaries serial" -- s/secondaries/secondary's/

Section 6.2:

* "So there may be a fourth step above where [...].  There may also be a fourth step where [...]." -- so there can be two "fourth" steps?

Section 6.3:

* "This section attempts to presents" -- remove "attempts to", or s/presents/present/

* In the second paragraph, I think you need a comma after "servers".
2021-05-05
11 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2021-05-05
11 Murray Kucherawy
[Ballot comment]
Minor Stuff...

Section 7:

* "Implementations SHOULD use [RFC7828] [...] to manage persistent connections." -- since this is a SHOULD, can …
[Ballot comment]
Minor Stuff...

Section 7:

* "Implementations SHOULD use [RFC7828] [...] to manage persistent connections." -- since this is a SHOULD, can you suggest why an implementer might opt not to do this?  Section 7.3.1 does a great job of handling the SHOULD it presents, for example.

Sections 7.3.2 and 7.3.3:

* Same issue as above with the SHOULDs here.

Section 7.4:

* "Therefore, it is RECOMMENDED that [...] there SHOULD be no more than [...]." -- I don't know how to reconcile this RECOMMENDED-SHOULD combination in the same sentence.  I suggest that the first clause can be dropped with no loss of meaning.

Nits...

Section 1:

* "authoritatives" should probably be "authoritative nameservers"

* "authenticated denial of existences records" -- s/existences/existence/

Section 4:

* "The proposed mechanisms does not attempt" -- s/does/do/, or s/mechanisms/mechanism/

Section 6:

* "term is used to encompasses" -- s/encompasses/encompass/, or remove "is used to"

Sections 6.1 and 6.2

* "higher than the secondaries serial" -- s/secondaries/secondary's/

Section 6.2:

* "So there may be a fourth step above where [...].  There may also be a fourth step where [...]." -- so there can be two "fourth" steps?

Section 6.3:

* "This section attempts to presents" -- remove "attempts to", or s/presents/present/

* In the second paragraph, I think you need a comma after "servers".
2021-05-05
11 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2021-05-05
11 Francesca Palombini
[Ballot comment]
Thank you for the work on this document. My only (very minor) comment is on abbreviations, and will likely come up with the …
[Ballot comment]
Thank you for the work on this document. My only (very minor) comment is on abbreviations, and will likely come up with the RFC Editor: there is a number of acronyms used throughout the text, please expand them on first use: XFR, AXFR, IXFR, SOA, ACL, RR, ALPN.

Francesca
2021-05-05
11 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2021-05-04
11 Benjamin Kaduk
[Ballot discuss]
My understanding is that this point is essentially overtaken by events,
as a similar concern was raised already by Martin D, John, and …
[Ballot 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.)
2021-05-04
11 Benjamin Kaduk
[Ballot 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 …
[Ballot 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).
2021-05-04
11 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2021-05-04
11 Erik Kline
[Ballot comment]
[[ questions ]]

[ general ]

* The appendix discussion of ALPN made me think that some ALPN
  recommendation might be worth …
[Ballot comment]
[[ questions ]]

[ general ]

* The appendix discussion of ALPN made me think that some ALPN
  recommendation might be worth mentioning.  The ALPN registry mentions
  "dot" and claims RFC 7858 as the reference.

  However, I wasn't able to find a reference to "dot" in 7858 (certainly
  not in the IANA section), nor in 8310 (which has only an empty IANA
  section).

  Now I'm wondering where the "dot" ALPN really came from.  Nevertheless,
  given this state of things, it best to continue to not say anything
  specific about ALPN use on these XoT connections?

  (I'm fully prepared to accept "yes" as an answer, but support others'
  ALPN concerns.)

[[ comments ]]

[ sections 8.4 and 12 ]

* Section 8.4 has MUST for two of three client authorization strategies,
  whereas section 12 has a lowercase "should" where these are listed for
  inclusion in an XoT policy.

  "Should" there be more agreement in use of requirements language?


[[ nits ]]

[ section 4 ]

* "The proposed mechanisms does not" -> "do not", or just "mechanism"?

[ section 6 ]

* "The term is used to encompasses" -> s/es//
2021-05-04
11 Erik Kline [Ballot Position Update] New position, Yes, has been recorded for Erik Kline
2021-05-04
11 Roman Danyliw
[Ballot comment]
Section 1.  s/can make reconnaissance trivial/can make reconnaissance and attack targeting easier/

Section 1.  Per “… zone walking is now possible with NSEC3 …
[Ballot comment]
Section 1.  s/can make reconnaissance trivial/can make reconnaissance and attack targeting easier/

Section 1.  Per “… zone walking is now possible with NSEC3 due to crypto-breaking advances”, a reference here would be helpful.

Section 1.  As far as I can tell the work on draft-vcelak-nsec5 has not been adopted and the draft is expired.  Perhaps this should be signaled via s/This has prompted further work on an alternative mechanism/This promoted work on an alternative mechanism/

Section 1.  Per “It is noted that in all of the common open source implementations …”, as this is a point in time assessment, it would be helpful to at least mention parenthetically the implementations/version numbers assessed informally for this conclusion.

Section 1.  Editorial.  “… must cater for accepting …” doesn’t parse for me.

Section 4.

  The threat model does not, however, consider the existence of a zone,
  the act of zone transfer between two entities, nor the identities of
  the nameservers hosting a zone

To further document the assumptions, consider adding that this threat model doesn’t consider/protect the mechanisms to decide on triggering the zone transfer (e.g., protecting NOTIFY messages from an active attacker)

Section 6.2.  Per “However it is noted that most widely used open source authoritative nameserver implementations (including both [BIND] and [NSD]) do IXFR using TCP by default in their latest releases”, as this document ages, “latest release” may not be meaningful.  Consider providing a version number for [BIND] and [NSD].

Section 8.4 and 10.4.  As already mentioned by Martin and John -- It seems like a strong statement to say that IP ACLs are in the same class of “channel authentication” as mTLS.

Section 8.8.1.  It’s difficult to assess how effective this notional padding approach would be for providing traffic analysis protection.  A few thoughts on the existing text realizing the details are out of scope:

-- Does padding for AXoT need to be coordinated with the padding on IXoT?

-- Is keeping state required to ensure that padding provides the appropriate obfuscation over time?
2021-05-04
11 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2021-05-04
11 John Scudder
[Ballot comment]
Thanks for the well-written and easy to follow spec. Below are some comments you may want to take into consideration.

1. Abstract

  …
[Ballot comment]
Thanks for the well-written and easy to follow spec. Below are some comments you may want to take into consideration.

1. Abstract

  XFR-over-TLS (XoT).  Additionally, this specification updates
  RFC1995, RFC5936 and RFC7766.

Please say a few words about how the spec updates those RFCs, don’t make the reader go digging for it.

2. Section 1

  transfers (this draft) is orthogonal to preventing zone enumeration,
  though they aim to protect the same information.

s/this draft/this document/

3. Sections 6.1, 6.2

  3.  If the primary serial is higher than the secondaries serial

s/secondaries/secondary’s/

4. Section 6.3

  This section attempts to presents a rationale for considering

“Attempts to present”. But really, why not just “presents”?

5. Section 6.3

  Since the SOA of the published zone can be trivially discovered by
  simply querying the publicly available authoritative servers leakage

Comma between “servers” and “leakage”.

6. Section 6.3.2

  For hidden primaries or secondaries the SOA response leaks only the
  degree of SOA serial number lag of any downstream secondary.

I don’t understand. This either means the sentence would make sense if only I had the right domain knowledge (which is OK then), or it means the sentence doesn’t make sense (which isn’t).

7. Section 7

  The following sections include detailed clarifications on the updates
  to XFR behavior implied in [RFC7766] and how the use of [RFC7828]
  applies specifically to XFR exchanges.  It also discusses how IXFR
  and AXFR can reuse the same TCP connection.

“They also discuss” — agreement in number with “the following sections”.

8. Section 7.4

  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.

The “for XoT” confuses this sentence, making it sound a bit like the advice is restricted to XoT. I think those two words should be struck, it would be just fine as “this specification updates…”

9. Section 8.1

  For improved security all implementations of this specification MUST
  use only TLS 1.3 [RFC8446] or later.

Improved compared to what? I think the first three words could go, then the question wouldn’t come up.

9. Section 8.4 (also 10.4)

  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)

The former is weaker, surely? I see Martin also raised this in his comments, I agree with what he wrote. It’s odd to see these two authorization methods, with very different security properties, presented as equivalent with no discussion anywhere of their relative (de)merits.

10. Section 8.8.1 (also 8.9.3)

  The goal of padding AXoT responses would be two fold:

“Is”, not “would be” (also 893)

11. Section 10.2

  SIG(0) [RFC2931] similarly also provides a mechanism to digitally

Similarly, or also — pick one.

12. Section 11

  The XoT authentication requirement specified in Section 8.4 addresses
  the issue of ensuring that the transfers is encrypted between the two

“Transfers are” or “transfer is”.

13. Section 11

  endpoints directly involved in the current transfers.  The following
  table summarized the properties of a selection of the mechanisms

“Summarizes”

14. Appendix A

  For completeness, it is noted that an earlier version of the
  specification suggested using a XoT specific ALPN to negotiate TLS

Please define APLN on first use

15. A.4

  As an aside, whilst [RFC7766] makes a general purpose distinction to
  clients in the usage of connections (between regular queries and zone

Do you mean “general purpose distinction between clients“? The use of “to” doesn’t make sense to me.

16. A.4

  Client behavior to REFUSED response is not clearly defined (see
  below).

I do not see anything relevant below.
2021-05-04
11 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2021-05-03
11 Martin Duke
[Ballot discuss]
In further discussions it became clear that the authors do not intend for XoT traffic to use an ALPN code at all. I'm …
[Ballot discuss]
In further discussions it became clear that the authors do not intend for XoT traffic to use an ALPN code at all. I'm afraid this may be a misunderstanding of previous guidance from TLS that XoT did not need its own ALPN code, but could simply use the DoT ALPN since the messages are distinguishable on the wire.

To not use an ALPN at all violates best TLS practice. The reasoning given in Appendix A, that this creates difficulty for proxies, doesn't make sense to me. We can talk about it in the telechat.
2021-05-03
11 Martin Duke
[Ballot comment]
- There ought to be a warning somewhere that mTLS verifies that the CA has verified identity, while IP ACLs merely prove that …
[Ballot comment]
- There ought to be a warning somewhere that mTLS verifies that the CA has verified identity, while IP ACLs merely prove that the bearer can observe the path to the address. The former is much stronger than the latter, unless there are more mechanisms built into the ACL than are obvious from the text here.
2021-05-03
11 Martin Duke [Ballot Position Update] Position for Martin Duke has been changed to Discuss from No Objection
2021-05-03
11 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2021-04-30
11 Lars Eggert
[Ballot comment]
Section 7, paragraph 7, comment:
>    Therefore this document updates both the previous specifications for
>    XFR-over-TCP to clarify that

It …
[Ballot comment]
Section 7, paragraph 7, comment:
>    Therefore this document updates both the previous specifications for
>    XFR-over-TCP to clarify that

It would be useful to explicitly cite those here; I assume you mean [RFC1995]
and [RFC5936].

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools, so there will likely be some false positives. There is no need
to let me know what you did with these suggestions.

Section 1, paragraph 10, nit:
-    contemplates the risk that someone gets the data through
-              -
+    contemplate the risk that someone gets the data through

Section 1, paragraph 11, nit:
-    Zone enumeration is trivially possible for DNSSEC zones which use
-                                                            ^ ^^^
-    NSEC; i.e.  queries for the authenticated denial of existences
-              ^
+    Zone enumeration is trivially possible for DNSSEC zones that use
+                                                            ^ ^^
+    NSEC; i.e., queries for the authenticated denial of existences
+              ^

Section 4, paragraph 4, nit:
-    o  much of this information can be obtained by various methods
+    o  much of this information can be obtained by various methods,
+                                                                  +

Section 5, paragraph 5, nit:
-          multiple AXFR sessions or XFRs of different zones because they
+          multiple AXFR sessions or XFRs of different zones, because they
+                                                          +

Section 5, paragraph 6, nit:
-      *  Current usage of TCP for IXFR is sub-optimal in some cases i.e.
+      *  Current usage of TCP for IXFR is sub-optimal in some cases, i.e.,
+                                                                    +    +

Section 6.1, paragraph 8, nit:
-        [RFC5936] defines this specific step as an 'AXFR session' i.e. as
+        [RFC5936] defines this specific step as an 'AXFR session', i.e., as
+                                                                +    +

Section 6.2, paragraph 12, nit:
-    using TCP by default in their latest releases.  For BIND TCP
-    connections are sometimes used for SOA queries but in general they
+    using TCP by default in their latest releases.  For BIND, TCP
+                                                            +
+    connections are sometimes used for SOA queries, but in general they
+                                                  +

Section 6.3, paragraph 3, nit:
-    simply querying the publicly available authoritative servers leakage
+    simply querying the publicly available authoritative servers, leakage
+                                                                +

Section 6.3.2, paragraph 2, nit:
-    For hidden primaries or secondaries the SOA response leaks only the
+    For hidden primaries or secondaries, the SOA response leaks only the
+                                      +

Section 7, paragraph 4, nit:
-    specific guidance on TCP/TLS connection usage for XFR because this
+    specific guidance on TCP/TLS connection usage for XFR, because this
+                                                        +

Section 7, paragraph 9, nit:
-      significantly more complex for clients to handle both because of
+      significantly more complex for clients to handle, both because of
+                                                      +

Section 7, paragraph 9, nit:
-      be multiple messages in the responses.  For these reasons it is
+      be multiple messages in the responses.  For these reasons, it is
+                                                                +

Section 7, paragraph 9, nit:
-      when they are all XFR queries i.e. clients sending multiple XFRs
+      when they are all XFR queries, i.e., clients sending multiple XFRs
+                                    +    +

Section 7, paragraph 9, nit:
-      later) since they will never receive them.
+      later), since they will never receive them.
+            +

Section 7, paragraph 11, nit:
-    applies specifically to XFR exchanges.  It also discusses how IXFR
-                                            ^^            --
+    applies specifically to XFR exchanges.  They also discuss how IXFR
+                                            ^^^^

Section 7, paragraph 12, nit:
-    the extended DNS error code 18 (Prohibited) can also be sent.
-                                                ^^^
+    the extended DNS error code 18 (Prohibited) MAY also be sent.
+                                                ^^^

Section 7.1, paragraph 2, nit:
-    For clarity - an IXFR-over-TCP server compliant with this
-    ^^^^^^^^^^^^^^^
+    An IXFR-over-TCP server compliant with this
+    ^

Section 7.2, paragraph 2, nit:
-    For clarity - an AXFR-over-TCP server compliant with this
-    ^^^^^^^^^^^^^^^
+    An AXFR-over-TCP server compliant with this
+    ^

Section 7.3.1, paragraph 4, nit:
-      zones might be preferred for operational reasons.  In this case
+      zones might be preferred for operational reasons.  In this case,
+                                                                      +

Section 7.3.2, paragraph 7, nit:
-      available i.e. responses MAY be sent intermingled
+      available, i.e., responses MAY be sent intermingled
+                +    +

Section 7.3.4, paragraph 2, nit:
-    does not support edns-tcp-keepalive the client MAY keep the
+    does not support edns-tcp-keepalive, the client MAY keep the
+                                      +

Section 7.3.5, paragraph 2, nit:
-    that implementations may want to offer options to fallback to legacy
-    behavior when interoperating with servers known not to support
-                                                      ---
+    that implementations may want to offer options to fall back to legacy
+                                                          +
+    behavior when interoperating with servers known to not support
+                                                    +++

Section 7.4, paragraph 6, nit:
-    TCP in any given client/server interaction there SHOULD be no more
+    TCP in any given client/server interaction, there SHOULD be no more
+                                              +

Section 7.4, paragraph 7, nit:
-    As an illustration, it could be imagined that in future such an
+    As an illustration, it could be imagined that in the future such an
+                                                    ++++

Section 8.1, paragraph 2, nit:
-    For improved security all implementations of this specification MUST
+    For improved security, all implementations of this specification MUST
+                        +

Section 8.3, paragraph 2, nit:
-    It is useful to note that in XoT it is the secondary that initiates
+    It is useful to note that in XoT, it is the secondary that initiates
+                                    +

Section 8.3, paragraph 2, nit:
-    of connectivity the secondary is the TLS client and the primary the
+    of connectivity, the secondary is the TLS client and the primary the
+                  +

Section 8.4, paragraph 2, nit:
-    with XoT all XFR requests and response for that zone MUST be sent
+    with XoT, all XFR requests and responses for that zone MUST be sent
+            +                              +

Section 8.4, paragraph 3, nit:
-      authentication domain name using a Strict Privacy Profile as
+      authentication domain name using a Strict Privacy Profile, as
+                                                                +

Section 8.5, paragraph 2, nit:
-    However any behavior specified here takes precedence for XoT.
+    However, any behavior specified here takes precedence for XoT.
+          +

Section 8.6, paragraph 3, nit:
-    near future with a small number of configured secondaries but that do
-    wish to support DoT for regular queries from recursive in that same
+    near future with a small number of configured secondaries, but that do
+                                                            +
+    wish to support DoT for regular queries from recursives in that same
+                                                          +

Section 8.7, paragraph 2, nit:
-    connection it SHOULD respond with the extended DNS error code 21 -
-    Not Supported [RFC8914].  XoT clients should not send any further
-                                          ^^^^^^ ^^^
+    connection, it SHOULD respond with the extended DNS error code 21 -
+              +
+    Not Supported [RFC8914].  XoT clients SHOULD NOT send any further
+                                          ^^^^^^ ^^^

Section 8.7, paragraph 2, nit:
-    (for example, one hour) i.e., long enough that the server
+    (for example, one hour), i.e., long enough that the server
+                          +

Section 8.7, paragraph 3, nit:
-    Historically servers have used the REFUSED RCODE for many situations,
+    Historically, servers have used the REFUSED RCODE for many situations,
+                +

Section 8.7, paragraph 3, nit:
-    error or fallback path when queries were refused.  As a result the
+    error or fallback path when queries were refused.  As a result, the
+                                                                  +

Section 8.8.1, paragraph 3, nit:
-    o  to obfuscate the actual size of the transferred zone to minimize
+    o  to obfuscate the actual size of the transferred zone, to minimize
+                                                          +

Section 8.8.1, paragraph 4, nit:
-      updates to minimize information leakage about zone update activity
+      updates, to minimize information leakage about zone update activity
+              +

Section 8.8.1, paragraph 6, nit:
-    It is noted here that, depending on the padding policies eventually
-                        -
+    It is noted here that depending on the padding policies eventually

Section 8.8.1, paragraph 6, nit:
-    the EDNS(0) option for padding.  For example, without this capability
+    the EDNS(0) option for padding.  For example, without this capability,
+                                                                        +

Section 8.8.1, paragraph 6, nit:
-    theoretically be limited if there had to be a minimum of 1 RR per
+    theoretically be limited, if there had to be a minimum of 1 RR per
+                            +

Section 8.8.1, paragraph 7, nit:
-    response series in order to signal the conclusion of the zone
+    response series, in order to signal the conclusion of the zone
+                  +

Section 8.9.1, paragraph 2, nit:
-    Whilst it does add complexity to generating responses it can
-    significantly reduce the size of responses.  However any such
+    Whilst it does add complexity to generating responses, it can
+                                                        +
+    significantly reduce the size of responses.  However, any such
+                                                        +

Section 8.9.3, paragraph 2, nit:
-    incremental changes to the zone between SOA updates to minimize
+    incremental changes to the zone between SOA updates, to minimize
+                                                      +

Section 8.9.3, paragraph 3, nit:
-    IXFR responses can vary in size greatly from the order of 100 bytes
-                                  ^^^^^^^^
+    IXFR responses can greatly vary in size, from the order of 100 bytes
+                      ++++++++            ^

Section 8.10, paragraph 2, nit:
-    structure is 16384.  For some DNS implementations this limits the
+    structure is 16384.  For some DNS implementations, this limits the
+                                                    +

Section 8.10, paragraph 3, nit:
-    particularly helpful when padding is used since minimizing the
+    particularly helpful when padding is used, since minimizing the
+                                            +

Section 9, paragraph 3, nit:
-    When using persistent connections the secondary may have a XoT
+    When using persistent connections, the secondary may have a XoT
+                                    +

Section 9, paragraph 4, nit:
-    a 'preferred primary connection' model.  In this case the secondary
+    a 'preferred primary connection' model.  In this case, the secondary
+                                                        +

Section 9, paragraph 5, nit:
-    model.  Here a secondary could keep multiple persistent connections
+    model.  Here, a secondary could keep multiple persistent connections
+                +

Section 9, paragraph 5, nit:
-    reasonably low this might be feasible if latency is the most
+    reasonably low, this might be feasible if latency is the most
+                  +

Section 9, paragraph 6, nit:
-    document but implementations are encouraged to provide configuration
+    document, but implementations are encouraged to provide configuration
+            +

Section 10, paragraph 2, nit:
-    To provide context to the requirements in section Section 8.4, this
-                                              --------
+    To provide context to the requirements in Section 8.4, this

Section 10, paragraph 5, nit:
-      communication channel between the client and server (i.e. the two
+      communication channel between the client and server (i.e., the two
+                                                                +

Section 10.2, paragraph 2, nit:
-    sign a DNS message but uses public key authentication, where the
+    sign a DNS message, but uses public key authentication, where the
+                      +

Section 10.3.1, paragraph 4, nit:
-    o  however they MAY fallback to using TLS without authentication and
+    o  however, they MAY fallback to using TLS without authentication and
+              +

Section 10.3.1, paragraph 6, nit:
-    As such it does not offer a defense against active attacks (e.g., an
+    As such, it does not offer a defense against active attacks (e.g., an
+          +

Section 10.4, paragraph 3, nit:
-    This is also possible with XoT but it must be noted that, as with
+    This is also possible with XoT, but it must be noted that, as with
+                                  +

Section 10.4, paragraph 4, nit:
-    As discussed in Appendix A an IP based per connection ACL could also
-                                    ^        ^
-    be implemented where only TLS connections from recognized secondaries
+    As discussed in Appendix A, an IP-based per-connection ACL could also
+                              +      ^        ^
+    be implemented, where only TLS connections from recognized secondaries
+                  +

Section 10.5, paragraph 4, nit:
-    It is complementary but orthogonal the above mechanisms; and can be
-    used in conjunction with XoT but is not considered further here.
+    It is complementary but orthogonal to the above mechanisms; and can be
+                                        +++
+    used in conjunction with XoT, but is not considered further here.
+                                +

Section 11, paragraph 2, nit:
-    single primary/secondary relationship where both servers are under
-    the control of a single operator to a complex hierarchical structure
+    single primary/secondary relationship, where both servers are under
+                                        +
+    the control of a single operator, to a complex hierarchical structure,
+                                    +                                    +

Section 11, paragraph 9, nit:
-      origin authentication which might be desirable for deployments
+      origin authentication, which might be desirable for deployments
+                            +

Section 12, paragraph 6, nit:
-    both the client and server are configured to use only XoT and the
+    both the client and server are configured to use only XoT, and the
+                                                            +

Section 12, paragraph 10, nit:
-    Since this may require configuration of a number of servers who may
-                                                                ^ ^
-    be under the control of different operators the desired consistency
+    Since this may require configuration of a number of servers that may
+                                                                ^ ^^
+    be under the control of different operators, the desired consistency
+                                              +

Section 12, paragraph 11, nit:
-    Certain aspects of the Policies can be relatively easily tested
-                          ^
+    Certain aspects of the policies can be relatively easily tested
+                          ^

Section 12, paragraph 11, nit:
-    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
+    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
+                                                                +

Section 12, paragraph 12, nit:
-    the scope of this document but may be the subject of future
+    the scope of this document, but may be the subject of future
+                              +

"Appendix A.", paragraph 2, nit:
-    connections that supported only a limited set of queries (SOA, XRFs)
+    connections that supported only a limited set of queries (SOA, XRFs),
+                                                                        +

"A.1.", paragraph 2, nit:
-    Obviously a nameserver which hosts a zone and services queries for
+    Obviously, a nameserver which hosts a zone and services queries for
+            +

"A.2.", paragraph 3, nit:
-    assessed.  Once the connection is accepted the server might well be
-    willing to answer any query on that connection since it is coming
+    assessed.  Once the connection is accepted, the server might well be
+                                              +
+    willing to answer any query on that connection, since it is coming
+                                                  +

"A.4.", paragraph 2, nit:
-    based ACLs to authenticate secondaries.  In this case the primary
+    based ACLs to authenticate secondaries.  In this case, the primary
+                                                        +

"A.4.", paragraph 3, nit:
-    transfers) this is not strict and nothing in the DNS protocol
-    prevents using the same connection for both types of traffic.  Hence
+    transfers), this is not strict and nothing in the DNS protocol
+              +
+    prevents using the same connection for both types of traffic.  Hence,
+                                                                        +

"A.4.", paragraph 5, nit:
-    o  strict: REFUSE all queries on TLS connections except SOA and
+    o  strict: REFUSE all queries on TLS connections, except SOA and
+                                                    +

"A.4.", paragraph 8, nit:
-    o  relaxed: answer all non-XoT queries on all TLS connections with
+    o  relaxed: answer all non-XoT queries on all TLS connections, with
+                                                                +

Section 1, paragraph 2, nit:
> rt by authoritatives might work. However there is currently no RFC that speci
>                                  ^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 1, paragraph 15, nit:
> ations such ACLs are applied on a per query basis. Since requests typically
>                                  ^^^^^^^^^
In this context, "per-query" forms an adjective and is spelled with a hyphen.

Section 1, paragraph 16, nit:
> ow to use TLS (1.3 or later) as a transport to prevent zone collection from
>                                ^^^^^^^^^^^
Uncountable nouns are usually not used with an indefinite article. Use simply
"transport".

Section 2, paragraph 1, nit:
> O BE REMOVED BEFORE PUBLICATION] The Github repository for this document is a
>                                      ^^^^^^
The official name of this software platform is spelled with a capital "H".

Section 4, paragraph 3, nit:
> information. The proposed mechanisms does not attempt to obscure such informa
>                                      ^^^^
You should probably use "do".

Section 4, paragraph 6, nit:
> n attacker had such capabilities. However this threat is likely true of any
>                                  ^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 6, paragraph 9, nit:
> FR-over-TCP The term is used to encompasses the range of permutations that a
>                                ^^^^^^^^^^^
The verb after "to" should be in the base form: "encompass".

Section 6.1, paragraph 10, nit:
> Rs and AXFRs of different zones. However [RFC5936] was constrained by having
>                                  ^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 6.2, paragraph 9, nit:
>  packet, otherwise, TCP is used. In fact it says: "Thus, a client should f
>                                    ^^^^^^^
The comma is probably missing here: "fact, it".

Section 6.2, paragraph 11, nit:
> primary does not support IXFR. However it is noted that most widely used ope
>                                ^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 6.3, paragraph 1, nit:
> xchanges This section attempts to presents a rationale for considering encryp
>                                  ^^^^^^^^
The verb after "to" should be in the base form: "present".

Section 7, paragraph 3, nit:
>  before TCP was considered a first class transport for DNS. [RFC1995], in fa
>                            ^^^^^^^^^^^^^^^^^^^^^^^
Uncountable nouns are usually not used with an indefinite article. Use simply
"first class transport".

Section 7.3.1, paragraph 6, nit:
> on an open connection o a large number of timeouts or slow responses have oc
>                        ^^^^^^^^^^^^^^^^^
Specify a number, remove phrase, or simply use "many" or "numerous"

Section 7.3.1, paragraph 8, nit:
> received from the server and the client is in the process of closing the con
>                                        ^^
Did you mean "are"?

Section 8.6, paragraph 3, nit:
> e XoT in the near future with a small number of configured secondaries, but t
>                              ^^^^^^^^^^^^^^^^^
Specify a number, remove phrase, use "a few", or use "some"

Section 8.8.1, paragraph 1, nit:
> l of padding AXoT responses would be two fold: o to obfuscate the actual size
>                                      ^^^^^^^^
The adjective or adverb 'twofold' needs to be written as one word.

Section 8.8.1, paragraph 6, nit:
>  is, AXoT responses that contain no RR's apart from an OPT RR containing the
>                                    ^^^^
The possessive apostrophe seems to be incorrect. Please remove the apostrophe
if you want to use the plural form of 'RR'.

Section 8.10, paragraph 2, nit:
> e to something around the order of 16kB. In principle, larger payload sizes
>                                    ^^^^
Insert a space between the numerical value and the unit symbol: "16 kB"

Section 9, paragraph 2, nit:
> messages and can send an SOA to all of the configured primaries. It can then
>                                ^^^^^^^^^^
Consider using "all the".

Section 10, paragraph 2, nit:
> tion provides a brief summary of some of the existing authentication and vali
>                                  ^^^^^^^^^^^
If the text is a generality, 'of the' is not necessary.

Section 10.4, paragraph 2, nit:
> transfers on primary servers on a per query basis. This is also possible wit
>                                  ^^^^^^^^^
In this context, "per-query" forms an adjective and is spelled with a hyphen.

Section 20, paragraph 13, nit:
>  references o Correct typos in acknowledgments draft-ietf-dprive-xfr-over-tls
>                                ^^^^^^^^^^^^^^^
Do not mix variants of the same word ('acknowledgment' and 'acknowledgement')
within a single text.

Section 20, paragraph 20, nit:
> -ietf-dprive-xfr-over-tls-04 o Add Github repository o Fix typos and referen
>                                    ^^^^^^
The official name of this software platform is spelled with a capital "H".

Section 21.2, paragraph 10, nit:
> nsaction Signatures ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, Sep
>                          ^^^
The word '0)s' is not standard English. Did you mean "0's" (curly apostrophe)
or "0's" (straight apostrophe)?

"A.1.", paragraph 3, nit:
> zone transfer on all transports on a per query basis. Cons: Attackers passiv
>                                      ^^^^^^^^^
In this context, "per-query" forms an adjective and is spelled with a hyphen.

"A.4.", paragraph 2, nit:
> TLS specific response policy on a per query basis. As an aside, whilst [RFC7
>                                  ^^^^^^^^^
In this context, "per-query" forms an adjective and is spelled with a hyphen.

"A.4.", paragraph 3, nit:
> d make per query decisions about whether or not to answer those queries. Exa
>                                  ^^^^^^^^^^^^^^
Consider shortening this phrase to just "whether". It is correct though if you
mean 'regardless of whether'.

"A.4.", paragraph 10, nit:
> ions just to perform XFRs with a small number of secondaries. Client behavior
>                                ^^^^^^^^^^^^^^^^^
Specify a number, remove phrase, use "a few", or use "some"

"A.4.1.", paragraph 1, nit:
> I based response policies In a similar fashion, XoT servers might use the pre
>                          ^^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "similarly" to avoid wordiness.

"A.4.1.", paragraph 2, nit:
> S connections. Pros: This has to potential to allow a clean distinction betw
>                              ^^^^^^^^^^^^^^^
Did you mean "too potential to"?

Document references draft-ietf-dprive-rfc7626-bis-08, but
draft-ietf-dprive-rfc7626-bis-09 is the latest available revision.

Document references draft-ietf-dprive-dnsoquic-01, but
draft-ietf-dprive-dnsoquic-02 is the latest available revision.

Document references draft-ietf-tls-esni-09, but draft-ietf-tls-esni-10 is the
latest available revision.
2021-04-30
11 Lars Eggert Ballot comment text updated for Lars Eggert
2021-04-30
11 Lars Eggert
[Ballot comment]
Section 7, paragraph 7, comment:
>    Therefore this document updates both the previous specifications for
>    XFR-over-TCP to clarify that

It …
[Ballot comment]
Section 7, paragraph 7, comment:
>    Therefore this document updates both the previous specifications for
>    XFR-over-TCP to clarify that

It would be useful to explicitly cite those here; I assume you mean [RFC1995]
and [RFC5936].

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools, so there will likely be some false positives. There is no need
to let me know what you did with these suggestions.

Section 1, paragraph 10, nit:
-    contemplates the risk that someone gets the data through
-              -
+    contemplate the risk that someone gets the data through

Section 1, paragraph 11, nit:
-    Zone enumeration is trivially possible for DNSSEC zones which use
-                                                            ^ ^^^
-    NSEC; i.e.  queries for the authenticated denial of existences
-              ^
+    Zone enumeration is trivially possible for DNSSEC zones that use
+                                                            ^ ^^
+    NSEC; i.e., queries for the authenticated denial of existences
+              ^

Section 4, paragraph 4, nit:
-    o  much of this information can be obtained by various methods
+    o  much of this information can be obtained by various methods,
+                                                                  +

Section 5, paragraph 5, nit:
-          multiple AXFR sessions or XFRs of different zones because they
+          multiple AXFR sessions or XFRs of different zones, because they
+                                                          +

Section 5, paragraph 6, nit:
-      *  Current usage of TCP for IXFR is sub-optimal in some cases i.e.
+      *  Current usage of TCP for IXFR is sub-optimal in some cases, i.e.,
+                                                                    +    +

Section 6.1, paragraph 8, nit:
-        [RFC5936] defines this specific step as an 'AXFR session' i.e. as
+        [RFC5936] defines this specific step as an 'AXFR session', i.e., as
+                                                                +    +

Section 6.2, paragraph 12, nit:
-    using TCP by default in their latest releases.  For BIND TCP
-    connections are sometimes used for SOA queries but in general they
+    using TCP by default in their latest releases.  For BIND, TCP
+                                                            +
+    connections are sometimes used for SOA queries, but in general they
+                                                  +

Section 6.3, paragraph 3, nit:
-    simply querying the publicly available authoritative servers leakage
+    simply querying the publicly available authoritative servers, leakage
+                                                                +

Section 6.3.2, paragraph 2, nit:
-    For hidden primaries or secondaries the SOA response leaks only the
+    For hidden primaries or secondaries, the SOA response leaks only the
+                                      +

Section 7, paragraph 4, nit:
-    specific guidance on TCP/TLS connection usage for XFR because this
+    specific guidance on TCP/TLS connection usage for XFR, because this
+                                                        +

Section 7, paragraph 9, nit:
-      significantly more complex for clients to handle both because of
+      significantly more complex for clients to handle, both because of
+                                                      +

Section 7, paragraph 9, nit:
-      be multiple messages in the responses.  For these reasons it is
+      be multiple messages in the responses.  For these reasons, it is
+                                                                +

Section 7, paragraph 9, nit:
-      when they are all XFR queries i.e. clients sending multiple XFRs
+      when they are all XFR queries, i.e., clients sending multiple XFRs
+                                    +    +

Section 7, paragraph 9, nit:
-      later) since they will never receive them.
+      later), since they will never receive them.
+            +

Section 7, paragraph 11, nit:
-    applies specifically to XFR exchanges.  It also discusses how IXFR
-                                            ^^            --
+    applies specifically to XFR exchanges.  They also discuss how IXFR
+                                            ^^^^

Section 7, paragraph 12, nit:
-    the extended DNS error code 18 (Prohibited) can also be sent.
-                                                ^^^
+    the extended DNS error code 18 (Prohibited) MAY also be sent.
+                                                ^^^

Section 7.1, paragraph 2, nit:
-    For clarity - an IXFR-over-TCP server compliant with this
-    ^^^^^^^^^^^^^^^
+    An IXFR-over-TCP server compliant with this
+    ^

Section 7.2, paragraph 2, nit:
-    For clarity - an AXFR-over-TCP server compliant with this
-    ^^^^^^^^^^^^^^^
+    An AXFR-over-TCP server compliant with this
+    ^

Section 7.3.1, paragraph 4, nit:
-      zones might be preferred for operational reasons.  In this case
+      zones might be preferred for operational reasons.  In this case,
+                                                                      +

Section 7.3.2, paragraph 7, nit:
-      available i.e. responses MAY be sent intermingled
+      available, i.e., responses MAY be sent intermingled
+                +    +

Section 7.3.4, paragraph 2, nit:
-    does not support edns-tcp-keepalive the client MAY keep the
+    does not support edns-tcp-keepalive, the client MAY keep the
+                                      +

Section 7.3.5, paragraph 2, nit:
-    that implementations may want to offer options to fallback to legacy
-    behavior when interoperating with servers known not to support
-                                                      ---
+    that implementations may want to offer options to fall back to legacy
+                                                          +
+    behavior when interoperating with servers known to not support
+                                                    +++

Section 7.4, paragraph 6, nit:
-    TCP in any given client/server interaction there SHOULD be no more
+    TCP in any given client/server interaction, there SHOULD be no more
+                                              +

Section 7.4, paragraph 7, nit:
-    As an illustration, it could be imagined that in future such an
+    As an illustration, it could be imagined that in the future such an
+                                                    ++++

Section 8.1, paragraph 2, nit:
-    For improved security all implementations of this specification MUST
+    For improved security, all implementations of this specification MUST
+                        +

Section 8.3, paragraph 2, nit:
-    It is useful to note that in XoT it is the secondary that initiates
+    It is useful to note that in XoT, it is the secondary that initiates
+                                    +

Section 8.3, paragraph 2, nit:
-    of connectivity the secondary is the TLS client and the primary the
+    of connectivity, the secondary is the TLS client and the primary the
+                  +

Section 8.4, paragraph 2, nit:
-    with XoT all XFR requests and response for that zone MUST be sent
+    with XoT, all XFR requests and responses for that zone MUST be sent
+            +                              +

Section 8.4, paragraph 3, nit:
-      authentication domain name using a Strict Privacy Profile as
+      authentication domain name using a Strict Privacy Profile, as
+                                                                +

Section 8.5, paragraph 2, nit:
-    However any behavior specified here takes precedence for XoT.
+    However, any behavior specified here takes precedence for XoT.
+          +

Section 8.6, paragraph 3, nit:
-    near future with a small number of configured secondaries but that do
-    wish to support DoT for regular queries from recursive in that same
+    near future with a small number of configured secondaries, but that do
+                                                            +
+    wish to support DoT for regular queries from recursives in that same
+                                                          +

Section 8.7, paragraph 2, nit:
-    connection it SHOULD respond with the extended DNS error code 21 -
-    Not Supported [RFC8914].  XoT clients should not send any further
-                                          ^^^^^^ ^^^
+    connection, it SHOULD respond with the extended DNS error code 21 -
+              +
+    Not Supported [RFC8914].  XoT clients SHOULD NOT send any further
+                                          ^^^^^^ ^^^

Section 8.7, paragraph 2, nit:
-    (for example, one hour) i.e., long enough that the server
+    (for example, one hour), i.e., long enough that the server
+                          +

Section 8.7, paragraph 3, nit:
-    Historically servers have used the REFUSED RCODE for many situations,
+    Historically, servers have used the REFUSED RCODE for many situations,
+                +

Section 8.7, paragraph 3, nit:
-    error or fallback path when queries were refused.  As a result the
+    error or fallback path when queries were refused.  As a result, the
+                                                                  +

Section 8.8.1, paragraph 3, nit:
-    o  to obfuscate the actual size of the transferred zone to minimize
+    o  to obfuscate the actual size of the transferred zone, to minimize
+                                                          +

Section 8.8.1, paragraph 4, nit:
-      updates to minimize information leakage about zone update activity
+      updates, to minimize information leakage about zone update activity
+              +

Section 8.8.1, paragraph 6, nit:
-    It is noted here that, depending on the padding policies eventually
-                        -
+    It is noted here that depending on the padding policies eventually

Section 8.8.1, paragraph 6, nit:
-    the EDNS(0) option for padding.  For example, without this capability
+    the EDNS(0) option for padding.  For example, without this capability,
+                                                                        +

Section 8.8.1, paragraph 6, nit:
-    theoretically be limited if there had to be a minimum of 1 RR per
+    theoretically be limited, if there had to be a minimum of 1 RR per
+                            +

Section 8.8.1, paragraph 7, nit:
-    response series in order to signal the conclusion of the zone
+    response series, in order to signal the conclusion of the zone
+                  +

Section 8.9.1, paragraph 2, nit:
-    Whilst it does add complexity to generating responses it can
-    significantly reduce the size of responses.  However any such
+    Whilst it does add complexity to generating responses, it can
+                                                        +
+    significantly reduce the size of responses.  However, any such
+                                                        +

Section 8.9.3, paragraph 2, nit:
-    incremental changes to the zone between SOA updates to minimize
+    incremental changes to the zone between SOA updates, to minimize
+                                                      +

Section 8.9.3, paragraph 3, nit:
-    IXFR responses can vary in size greatly from the order of 100 bytes
-                                  ^^^^^^^^
+    IXFR responses can greatly vary in size, from the order of 100 bytes
+                      ++++++++            ^

Section 8.10, paragraph 2, nit:
-    structure is 16384.  For some DNS implementations this limits the
+    structure is 16384.  For some DNS implementations, this limits the
+                                                    +

Section 8.10, paragraph 3, nit:
-    particularly helpful when padding is used since minimizing the
+    particularly helpful when padding is used, since minimizing the
+                                            +

Section 9, paragraph 3, nit:
-    When using persistent connections the secondary may have a XoT
+    When using persistent connections, the secondary may have a XoT
+                                    +

Section 9, paragraph 4, nit:
-    a 'preferred primary connection' model.  In this case the secondary
+    a 'preferred primary connection' model.  In this case, the secondary
+                                                        +

Section 9, paragraph 5, nit:
-    model.  Here a secondary could keep multiple persistent connections
+    model.  Here, a secondary could keep multiple persistent connections
+                +

Section 9, paragraph 5, nit:
-    reasonably low this might be feasible if latency is the most
+    reasonably low, this might be feasible if latency is the most
+                  +

Section 9, paragraph 6, nit:
-    document but implementations are encouraged to provide configuration
+    document, but implementations are encouraged to provide configuration
+            +

Section 10, paragraph 2, nit:
-    To provide context to the requirements in section Section 8.4, this
-                                              --------
+    To provide context to the requirements in Section 8.4, this

Section 10, paragraph 5, nit:
-      communication channel between the client and server (i.e. the two
+      communication channel between the client and server (i.e., the two
+                                                                +

Section 10.2, paragraph 2, nit:
-    sign a DNS message but uses public key authentication, where the
+    sign a DNS message, but uses public key authentication, where the
+                      +

Section 10.3.1, paragraph 4, nit:
-    o  however they MAY fallback to using TLS without authentication and
+    o  however, they MAY fallback to using TLS without authentication and
+              +

Section 10.3.1, paragraph 6, nit:
-    As such it does not offer a defense against active attacks (e.g., an
+    As such, it does not offer a defense against active attacks (e.g., an
+          +

Section 10.4, paragraph 3, nit:
-    This is also possible with XoT but it must be noted that, as with
+    This is also possible with XoT, but it must be noted that, as with
+                                  +

Section 10.4, paragraph 4, nit:
-    As discussed in Appendix A an IP based per connection ACL could also
-                                    ^        ^
-    be implemented where only TLS connections from recognized secondaries
+    As discussed in Appendix A, an IP-based per-connection ACL could also
+                              +      ^        ^
+    be implemented, where only TLS connections from recognized secondaries
+                  +

Section 10.5, paragraph 4, nit:
-    It is complementary but orthogonal the above mechanisms; and can be
-    used in conjunction with XoT but is not considered further here.
+    It is complementary but orthogonal to the above mechanisms; and can be
+                                        +++
+    used in conjunction with XoT, but is not considered further here.
+                                +

Section 11, paragraph 2, nit:
-    single primary/secondary relationship where both servers are under
-    the control of a single operator to a complex hierarchical structure
+    single primary/secondary relationship, where both servers are under
+                                        +
+    the control of a single operator, to a complex hierarchical structure,
+                                    +                                    +

Section 11, paragraph 9, nit:
-      origin authentication which might be desirable for deployments
+      origin authentication, which might be desirable for deployments
+                            +

Section 12, paragraph 6, nit:
-    both the client and server are configured to use only XoT and the
+    both the client and server are configured to use only XoT, and the
+                                                            +

Section 12, paragraph 10, nit:
-    Since this may require configuration of a number of servers who may
-                                                                ^ ^
-    be under the control of different operators the desired consistency
+    Since this may require configuration of a number of servers that may
+                                                                ^ ^^
+    be under the control of different operators, the desired consistency
+                                              +

Section 12, paragraph 11, nit:
-    Certain aspects of the Policies can be relatively easily tested
-                          ^
+    Certain aspects of the policies can be relatively easily tested
+                          ^

Section 12, paragraph 11, nit:
-    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
+    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
+                                                                +

Section 12, paragraph 12, nit:
-    the scope of this document but may be the subject of future
+    the scope of this document, but may be the subject of future
+                              +

"Appendix A.", paragraph 2, nit:
-    connections that supported only a limited set of queries (SOA, XRFs)
+    connections that supported only a limited set of queries (SOA, XRFs),
+                                                                        +

"A.1.", paragraph 2, nit:
-    Obviously a nameserver which hosts a zone and services queries for
+    Obviously, a nameserver which hosts a zone and services queries for
+            +

"A.2.", paragraph 3, nit:
-    assessed.  Once the connection is accepted the server might well be
-    willing to answer any query on that connection since it is coming
+    assessed.  Once the connection is accepted, the server might well be
+                                              +
+    willing to answer any query on that connection, since it is coming
+                                                  +

"A.4.", paragraph 2, nit:
-    based ACLs to authenticate secondaries.  In this case the primary
+    based ACLs to authenticate secondaries.  In this case, the primary
+                                                        +

"A.4.", paragraph 3, nit:
-    transfers) this is not strict and nothing in the DNS protocol
-    prevents using the same connection for both types of traffic.  Hence
+    transfers), this is not strict and nothing in the DNS protocol
+              +
+    prevents using the same connection for both types of traffic.  Hence,
+                                                                        +

"A.4.", paragraph 5, nit:
-    o  strict: REFUSE all queries on TLS connections except SOA and
+    o  strict: REFUSE all queries on TLS connections, except SOA and
+                                                    +

"A.4.", paragraph 8, nit:
-    o  relaxed: answer all non-XoT queries on all TLS connections with
+    o  relaxed: answer all non-XoT queries on all TLS connections, with
+                                                                +

Document references draft-ietf-dprive-rfc7626-bis-08, but
draft-ietf-dprive-rfc7626-bis-09 is the latest available revision.

Document references draft-ietf-dprive-dnsoquic-01, but
draft-ietf-dprive-dnsoquic-02 is the latest available revision.

Document references draft-ietf-tls-esni-09, but draft-ietf-tls-esni-10 is the
latest available revision.
2021-04-30
11 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2021-04-27
11 Éric Vyncke Closed request for Telechat review by IOTDIR with state 'Withdrawn': It was a simple try to check the tool.
2021-04-27
11 Éric Vyncke Requested Telechat review by IOTDIR
2021-04-23
11 Martin Duke
[Ballot comment]
- Please explicitly state that, IIUC, these XoT connections use the DoT ALPN.

- There ought to be a warning somewhere that mTLS …
[Ballot comment]
- Please explicitly state that, IIUC, these XoT connections use the DoT ALPN.

- There ought to be a warning somewhere that mTLS verifies that the CA has verified identity, while IP ACLs merely prove that the bearer can observe the path to the address. The former is much stronger than the latter, unless there are more mechanisms built into the ACL than are obvious from the text here.

- Please educate me: from my skim of the RFCs AXFR has message IDs, but IFXR does not. So how would a client demux IFXR responses?
2021-04-23
11 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2021-04-20
11 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2021-04-20
11 Éric Vyncke Placed on agenda for telechat - 2021-05-06
2021-04-20
11 Éric Vyncke Ballot has been issued
2021-04-20
11 Éric Vyncke [Ballot Position Update] New position, Yes, has been recorded for Éric Vyncke
2021-04-20
11 Éric Vyncke Created "Approve" ballot
2021-04-20
11 (System) Changed action holders to Éric Vyncke (IESG state changed)
2021-04-20
11 Éric Vyncke IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2021-04-20
11 Éric Vyncke Ballot writeup was changed
2021-04-20
11 Sara Dickinson New version available: draft-ietf-dprive-xfr-over-tls-11.txt
2021-04-20
11 (System) New version approved
2021-04-20
11 (System) Request for posting confirmation emailed to previous authors: Allison Mankin , Pallavi Aras , Sara Dickinson , Shivan Sahib , Willem Toorop
2021-04-20
11 Sara Dickinson Uploaded new revision
2021-04-20
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-04-20
10 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2021-04-20
10 Sara Dickinson New version available: draft-ietf-dprive-xfr-over-tls-10.txt
2021-04-20
10 (System) New version approved
2021-04-20
10 (System) Request for posting confirmation emailed to previous authors: Allison Mankin , Pallavi Aras , Sara Dickinson , Shivan Sahib , Willem Toorop
2021-04-20
10 Sara Dickinson Uploaded new revision
2021-04-20
09 Éric Vyncke
A revised I-D is needed to address Dan's last call nits at: https://datatracker.ietf.org/doc/review-ietf-dprive-xfr-over-tls-09-genart-lc-romascanu-2021-04-17/ . Let's aim to perfection ;-)

Once published, I will initiate the …
A revised I-D is needed to address Dan's last call nits at: https://datatracker.ietf.org/doc/review-ietf-dprive-xfr-over-tls-09-genart-lc-romascanu-2021-04-17/ . Let's aim to perfection ;-)

Once published, I will initiate the ballot.

Regards

-éric
2021-04-20
09 (System) Changed action holders to Éric Vyncke, Sara Dickinson, Allison Mankin, Willem Toorop, Shivan Sahib, Pallavi Aras (IESG state changed)
2021-04-20
09 Éric Vyncke IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2021-04-20
09 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2021-04-17
09 Dan Romascanu Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Dan Romascanu. Sent review to list.
2021-04-16
09 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2021-04-16
09 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-dprive-xfr-over-tls-09, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-dprive-xfr-over-tls-09, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2021-04-15
09 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Withdrawn'
2021-04-15
09 Tero Kivinen Assignment of request for Last Call review by SECDIR to Sandra Murphy was withdrawn
2021-04-15
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Sandra Murphy
2021-04-15
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Sandra Murphy
2021-04-15
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Russ Mundy
2021-04-15
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Russ Mundy
2021-04-08
09 Jean Mahoney Request for Last Call review by GENART is assigned to Dan Romascanu
2021-04-08
09 Jean Mahoney Request for Last Call review by GENART is assigned to Dan Romascanu
2021-04-08
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Alexey Melnikov
2021-04-08
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Alexey Melnikov
2021-04-08
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jouni Korhonen
2021-04-08
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jouni Korhonen
2021-04-06
09 Amy Vezza IANA Review state changed to IANA - Review Needed
2021-04-06
09 Amy Vezza
The following Last Call announcement was sent out (ends 2021-04-20):

From: The IESG
To: IETF-Announce
CC: dns-privacy@ietf.org, dprive-chairs@ietf.org, draft-ietf-dprive-xfr-over-tls@ietf.org, evyncke@cisco.com, tjw.ietf@gmail.com …
The following Last Call announcement was sent out (ends 2021-04-20):

From: The IESG
To: IETF-Announce
CC: dns-privacy@ietf.org, dprive-chairs@ietf.org, draft-ietf-dprive-xfr-over-tls@ietf.org, evyncke@cisco.com, tjw.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DNS Zone Transfer-over-TLS) to Proposed Standard


The IESG has received a request from the DNS PRIVate Exchange WG (dprive) to
consider the following document: - 'DNS Zone Transfer-over-TLS'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-04-20. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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 the use of TLS, rather than clear text, to prevent
  zone content collection via passive monitoring of zone transfers:
  XFR-over-TLS (XoT).  Additionally, this specification updates
  RFC1995, RFC5936 and RFC7766.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc6973: Privacy Considerations for Internet Protocols (Informational - Internet Architecture Board (IAB))
    draft-ietf-dprive-rfc7626-bis: DNS Privacy Considerations (None - Internet Engineering Task Force (IETF))
    rfc7626: DNS Privacy Considerations (Informational - Internet Engineering Task Force (IETF))



2021-04-06
09 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2021-04-06
09 Éric Vyncke Ballot writeup was changed
2021-04-06
09 Éric Vyncke Last call was requested
2021-04-06
09 Éric Vyncke Last call announcement was generated
2021-04-06
09 Éric Vyncke Ballot approval text was generated
2021-04-06
09 Éric Vyncke Ballot writeup was generated
2021-04-06
09 (System) Changed action holders to Éric Vyncke (IESG state changed)
2021-04-06
09 Éric Vyncke IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2021-04-06
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-04-06
09 Sara Dickinson New version available: draft-ietf-dprive-xfr-over-tls-09.txt
2021-04-06
09 (System) New version approved
2021-04-06
09 (System) Request for posting confirmation emailed to previous authors: Allison Mankin , Pallavi Aras , Sara Dickinson , Shivan Sahib , Willem Toorop
2021-04-06
09 Sara Dickinson Uploaded new revision
2021-03-19
08 Éric Vyncke Revised I-D is probably required based on AD review: https://mailarchive.ietf.org/arch/msg/dns-privacy/xI2eTy9_qbfOLsi0sgKxPK0iRvc/
2021-03-19
08 (System) Changed action holders to Éric Vyncke, Sara Dickinson, Allison Mankin, Willem Toorop, Shivan Sahib, Pallavi Aras (IESG state changed)
2021-03-19
08 Éric Vyncke IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2021-03-08
08 Shivan Sahib New version available: draft-ietf-dprive-xfr-over-tls-08.txt
2021-03-08
08 (System) New version accepted (logged-in submitter: Shivan Sahib)
2021-03-08
08 Shivan Sahib Uploaded new revision
2021-03-04
07 (System) Changed action holders to Éric Vyncke (IESG state changed)
2021-03-04
07 Éric Vyncke IESG state changed to AD Evaluation from Publication Requested
2021-02-28
07 Tim Wicinski
(1) RFC is Standards Track, and this is the correct RFC type.

(2)

Technical Summary:

DNS zone transfers are transmitted in clear text, which gives …
(1) RFC is Standards Track, and this is the correct RFC type.

(2)

Technical Summary:

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 the use of TLS, rather than clear text, to prevent
zone content collection via passive monitoring of zone transfers:
XFR-over-TLS (XoT).  Additionally, this specification updates
RFC1995, RFC5936 and RFC7766.


Working Group Summary:

There were several discussions during the working group process,
but they were all resolved.

Document Quality:

The document was the result of different interpertations of the original
RFC that cause some implementation issues.  Section 14 points out there are
several implementations that interact successfully.


Personnel:

Document Shepherd:  Tim Wicinski
Responsible Area Director: Éric Vyncke


(3)  The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth
of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is very solid.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) normative references draft-vcelak-nsec5 has expired and is a normative reference.


(15) There are two downward normative references: RFC6973 and RFC7626.
Both documents have been used as a downward reference previously.

(16) This document will update RFC1995, RFC5936 and RFC7766, and it is in the abstract and the
introduction.

(17) N/A

(18) N/A

(19) N/A

(20) No Yang Necessary

2021-02-28
07 Tim Wicinski Responsible AD changed to Éric Vyncke
2021-02-28
07 Tim Wicinski IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2021-02-28
07 Tim Wicinski IESG state changed to Publication Requested from I-D Exists
2021-02-28
07 Tim Wicinski IESG process started in state Publication Requested
2021-02-28
07 Tim Wicinski
(1) RFC is Standards Track, and this is the correct RFC type.

(2)

Technical Summary:

DNS zone transfers are transmitted in clear text, which gives …
(1) RFC is Standards Track, and this is the correct RFC type.

(2)

Technical Summary:

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 the use of TLS, rather than clear text, to prevent
zone content collection via passive monitoring of zone transfers:
XFR-over-TLS (XoT).  Additionally, this specification updates
RFC1995, RFC5936 and RFC7766.


Working Group Summary:

There were several discussions during the working group process,
but they were all resolved.

Document Quality:

The document was the result of different interpertations of the original
RFC that cause some implementation issues.  Section 14 points out there are
several implementations that interact successfully.


Personnel:

Document Shepherd:  Tim Wicinski
Responsible Area Director: Éric Vyncke


(3)  The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth
of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is very solid.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) normative references draft-vcelak-nsec5 has expired and is a normative reference.


(15) There are two downward normative references: RFC6973 and RFC7626.
Both documents have been used as a downward reference previously.

(16) This document will update RFC1995, RFC5936 and RFC7766, and it is in the abstract and the
introduction.

(17) N/A

(18) N/A

(19) N/A

(20) No Yang Necessary

2021-02-28
07 Tim Wicinski IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2021-02-16
07 Sara Dickinson New version available: draft-ietf-dprive-xfr-over-tls-07.txt
2021-02-16
07 (System) New version accepted (logged-in submitter: Sara Dickinson)
2021-02-16
07 Sara Dickinson Uploaded new revision
2021-02-11
06 Sara Dickinson New version available: draft-ietf-dprive-xfr-over-tls-06.txt
2021-02-11
06 (System) New version accepted (logged-in submitter: Sara Dickinson)
2021-02-11
06 Sara Dickinson Uploaded new revision
2021-01-21
05 Tim Wicinski Notification list changed to tjw.ietf@gmail.com because the document shepherd was set
2021-01-21
05 Tim Wicinski Document shepherd changed to Tim Wicinski
2021-01-21
05 Tim Wicinski IETF WG state changed to In WG Last Call from WG Document
2021-01-20
05 Sara Dickinson New version available: draft-ietf-dprive-xfr-over-tls-05.txt
2021-01-20
05 (System) New version approved
2021-01-20
05 (System) Request for posting confirmation emailed to previous authors: Allison Mankin , Pallavi Aras , Sara Dickinson , Shivan Sahib , Willem Toorop
2021-01-20
05 Sara Dickinson Uploaded new revision
2020-11-23
04 Sara Dickinson New version available: draft-ietf-dprive-xfr-over-tls-04.txt
2020-11-23
04 (System) New version accepted (logged-in submitter: Sara Dickinson)
2020-11-23
04 Sara Dickinson Uploaded new revision
2020-11-19
03 Tim Wicinski Added to session: IETF-109: dprive  Fri-1600
2020-11-02
03 Sara Dickinson New version available: draft-ietf-dprive-xfr-over-tls-03.txt
2020-11-02
03 (System) New version approved
2020-11-02
03 (System) Request for posting confirmation emailed to previous authors: Allison Mankin , Willem Toorop , Shivan Sahib , Sara Dickinson , Pallavi Aras
2020-11-02
03 Sara Dickinson Uploaded new revision
2020-07-23
02 Tim Wicinski Added to session: IETF-108: dprive  Fri-1410
2020-07-13
02 Sara Dickinson New version available: draft-ietf-dprive-xfr-over-tls-02.txt
2020-07-13
02 (System) New version approved
2020-07-13
02 (System) Request for posting confirmation emailed to previous authors: Han Zhang , Willem Toorop , Allison Mankin , Sara Dickinson , dprive-chairs@ietf.org, Pallavi Aras
2020-07-13
02 Sara Dickinson Uploaded new revision
2020-05-20
01 Sara Dickinson New version available: draft-ietf-dprive-xfr-over-tls-01.txt
2020-05-20
01 (System) New version approved
2020-05-20
01 (System) Request for posting confirmation emailed to previous authors: Pallavi Aras , Sara Dickinson , Han Zhang , Allison Mankin , Willem Toorop
2020-05-20
01 Sara Dickinson Uploaded new revision
2019-11-20
00 Tim Wicinski Changed consensus to Yes from Unknown
2019-11-20
00 Tim Wicinski Intended Status changed to Proposed Standard from None
2019-11-18
00 Tim Wicinski This document now replaces draft-hzpa-dprive-xfr-over-tls instead of None
2019-11-18
00 Sara Dickinson New version available: draft-ietf-dprive-xfr-over-tls-00.txt
2019-11-18
00 (System) WG -00 approved
2019-11-18
00 Sara Dickinson Set submitter to "Sara Dickinson ", replaces to (none) and sent approval email to group chairs: dprive-chairs@ietf.org
2019-11-18
00 Sara Dickinson Uploaded new revision