Subject: Re: [dns-privacy] New Version Notification for draft-zatda-dprive-xfr-using-dso-00.txt

From: Sara Dickinson <[email-masked]>
Date: Tue, 9 Jul 2019 10:03:40 +0100

Hi All, 

A new draft has been submitted that outlines the basics of a DSO based mechanism for zone transfers requiring TLS. 

There is much more work to do on the details and potentially additional messaging to define but hopefully this includes information to get some initial feedback on this proposal.

Best regards

Sara. 

> On 8 Jul 2019, at 18:45, [email-masked] wrote:
> 
> 
> A new version of I-D, draft-zatda-dprive-xfr-using-dso-00.txt
> has been successfully submitted by Sara Dickinson and posted to the
> IETF repository.
> 
> Name:		draft-zatda-dprive-xfr-using-dso
> Revision:	00
> Title:		DNS Zone Transfer using DNS Stateful Operations
> Document date:	2019-07-08
> Group:		Individual Submission
> Pages:		21
> URL:            https://www.ietf.org/internet-drafts/draft-zatda-dprive-xfr-using-dso-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-zatda-dprive-xfr-using-dso/
> Htmlized:       https://tools.ietf.org/html/draft-zatda-dprive-xfr-using-dso-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-zatda-dprive-xfr-using-dso
> 
> 
> 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.  This document specifies use of
>   DNS Stateful Operations to enable a subscribe/publish mechanism for
>   zone transfers reducing the over head introduced by NOTITY/SOA
>   interactions prior to zone transfer request.  This additionally
>   prevents zone contents collection via passive monitoring of zone
>   transfers by restricting XFR using DSO to require TLS.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 9 Jul 2019 18:29:04 -0400

This is a great use of DSO and pub/sub. I support this work and I like the new acronym XuD in the spirit of DoT and DoH, etc.

Some minor comments:

In the Abstract is NOTITY/SOA instead of NOTIFY/SOA.

In the Terminology section, XuD is defined using DOS instead of DSO.

In the Overview, you mention clients should only subscribe for zones they are authorised to transfer. This needs a little more context. Who authorises a client? How does a client know it is authorised?

In 7.1, in a note, you mention TSIG can be used by the client to demonstrate that it is authorised so maybe this is what is meant earlier in the overview but it should be more explicit but also, it would be neat if SIG(0) certificate verification could be used for authorisation as well to obviate the need for out of band secret exchange.

In 7.1.1.1, there is mention of efficiently packing stream data into TCP segments. This is also in the PUSH draft but I think it should be removed from there and from here as well because once the data is encoded in a TLS session, it’s much more difficult for the sender to have control over the size of TCP segments sent.

In 7.3.1, you ask the question if the equivalent of a RECONFIRM message is needed. The answer is no. This is specific to the way service discovery currently works and it is not applicable in the XFR case.

Thanks,
Tom

> On Jul 9, 2019, at 5:03 AM, Sara Dickinson <[email-masked]> wrote:
> 
> Hi All, 
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 10 Jul 2019 13:56:58 +0100

> On 9 Jul 2019, at 23:29, Tom Pusateri <[email-masked]> wrote:
> 

Hi Tom, 

Thanks for the feedback

> In the Terminology section, XuD is defined using DOS instead of DSO.

Both fixed in the next version - thanks.

> In the Overview, you mention clients should only subscribe for zones they are authorised to transfer. This needs a little more context. Who authorises a client? How does a client know it is authori…

Yes - this does need more context. Perhaps it is better phrased that ’secondaries should only create XuD subscriptions on connections to severs that are expliclty configured as primaries for the zone in question’? This makes it independent of the authentication model.

> In 7.1, in a note, you mention TSIG can be used by the client to demonstrate that it is authorised so maybe this is what is meant earlier in the overview but it should be more explicit but also, it…

There is a full discussion of authentication methods in the 'DNS Zone Transfer-over-TLS’ (https://datatracker.ietf.org/doc/draft-hzpa-dprive-xfr-over-tls/) which is reference here but not reproduced. But a discussion of SIG(0) should be added there….

> In 7.1.1.1, there is mention of efficiently packing stream data into TCP segments. This is also in the PUSH draft but I think it should be removed from there and from here as well because once the…

I’ve actually had a couple of off list discussions that propose the TCP use case for this is a valid one and we should make TLS optional, in which case this should probably stay in this draft with that qualification? (I know PUSH requires TLS).

> In 7.3.1, you ask the question if the equivalent of a RECONFIRM message is needed. The answer is no. This is specific to the way service discovery currently works and it is not applicable in the XF…

Thanks for that - I couldn’t see the use case for zone transfer. 

There are other cases of needing to ‘reset' the transfer in various ways which we’ll try to address in the next version.

Thanks

Sara.

---

From: Tony Finch <[email-masked]>
Date: Wed, 10 Jul 2019 18:09:44 +0100

Tom Pusateri <[email-masked]> wrote:
>
> In 7.1.1.1, there is mention of efficiently packing stream data into
> TCP segments. This is also in the PUSH draft but I think it should be
> removed from there and from here as well because once the data is
> encoded in a TLS session, it’s much more difficult for the sender to
> have control over the size of TCP segments sent.

I think the right abstraction here is operating system write() or send()
calls, since you can't normally control segmentation in detail except that
short writes usually lead to short packets. e.g. (covering both TCP and
TLS):

                           Since SUBSCRIBE-XFR requests are sent
   over TCP, multiple SUBSCRIBE-XFR DSO request messages can be
   concatenated in a single write call to make efficient use of
   the underlying transport.

... but of course this applies to any DNS messages over TCP or TLS ...

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon: Southwest, veering west or northwest, 4 or 5, occasionally 6 at
first. Moderate, occasionally slight at first in southeast. Occasional rain,
fog patches. Moderate or good, occasionally very poor.

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 12 Jul 2019 15:46:42 +0200

Hi Sara,

Thanks for this first version. I have read it and here are my thoughts.

1.
About use cases.  The draft mentions performance because it will reduce
the number of messages required to perform one transfer. Hopefully this
new protocol can also add performance improvements for the DNSSEC case
(reduce redundant information in the change such as RRSIG deletions,
basically ideas that are listed in my MIXFR draft [1]. Similar we could
incorporate the IXFR-ONLY idea [2] that will contribute to the improved
error handling use case.

[1] https://datatracker.ietf.org/doc/draft-mekking-mixfr/
[2] https://datatracker.ietf.org/doc/draft-kerr-ixfr-only/

2.
QUESTION: Is there a use case to allow XuD over TCP where
confidentiality is not an issue e.g when the zone contents are
already publicly available?

Section 3 lists several use cases other than confidentiality for DSO
based zone transfers, so I guess the answer to the question is yes :)

So why not allow DSO transfers over TCP too?

3.
QUESTION: Is there a use case where a client may want to signal that
the version of the zone it holds has been updated via another
mechanism and the zone transfer should restart from a different SOA
than that currently exchanged between client and server?

I think "signalling the version of the zone it holds" should be
supported. Not only because it may have been updated by another
mechanism, but also it can go out of sync. Consider the case where a
secondary is restored from a backup and has an older version of a zone
on disk.

Of course a client could do this by unsubscribing and resubscribing with
its current SERIAL, so maybe no special DSO type message is needed?

4.
>From the draft:

   DNS wildcarding is not supported.  SUBSCRIBE-XFR requests received
   for zones containing wildcards are considered an error (see below).

But I fail to find any text around wildcarding below.

But this does raise a question whether a SUBSCRIBE-XFR Request should
support multiple zones. I am thinking of a use case where a server has a
bulk of zones it serves, then it could end up with maintaining lots of
subscriptions.

5.
Alternatively if incremental zone transfer is not available, the
entire zone MAY be returned in a DSO-AXFR message.

QUESTION: Should we bother with a separate DSO-AXFR message or just
allow full zone transfer inside the DSO-IXFR message as with
[RFC1995] IXFR?  A separate message type makes is more explicit and
IXFR was constrained by having to respond to a IXFR request.

I don't see much value in two separate type of messages, except that it
is slightly easier to detect whether the transfer is an incremental or a
full one.  What does interest me is that a client can subscribe to
incremental zone transfers only, and may decide to subscribe to a
different master if an incremental zone transfer is not available (a
situation that should happen rarely though, when would an incremental
zone transfer be unavailable?).

6.
QUESTION: Do we need the equivalent of a RECONFIRM message from DNS
PUSH Notifications [I-D.ietf-dnssd-push]?

Yes, a client may want to reconfirm that the zone it serves is not
stale. The SOA REFRESH timer may expire without having received new
changes, and so a RECONFIRM message to ensure the zone is fresh seems
desirable.

Best regards,

Matthijs