Subject: [dnssd] Benjamin Kaduk's No Objection on draft-ietf-dnssd-push-24: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 08 Aug 2019 07:22:10 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnssd-push-24: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/

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

Thanks for this well-written document!

What are the privacy considerations to zone content owners (e.g.,
machine owners listed in a zone) about the availability of near-realtime
information tracking their changes?

Can we have a discussion of padding policy to attempt to preserve the
privacy of push transactions?

Section 1.2

Do we need to give a reference for the BSD Sockets API?   (I honestly
forget what we did for other documents referencing it.)

Section 3

Perhaps we should put quotation marks around statements taken from RFC
8490 (so as to avoid the appearance that we are duplicating normative
requirements made in that document).

Section 5

   server in this protocol specification.  Additional security measures
   such as client authentication during TLS negotiation MAY also be
   employed to increase the trust relationship between client and
   server.

Do we want to say anything about the validation procedures for that
client authentication, maybe RFC 6125 with a DNS-ID check, or would that
be too restrictive?

Section 6.1

   In many contexts, the recursive resolver will be able to handle Push
   Notifications for all names that the client may need to follow.  Use
   of VPN tunnels and split-view DNS can create some additional
   complexity in the client software here; the techniques to handle VPN
   tunnels and split-view DNS for DNS Push Notifications are the same as
   those already used to handle this for normal DNS queries.

Is there a good reference discussing these techniques?

Section 6.2.1

   The MESSAGE ID field MUST be set to a unique value, that the client
   is not using for any other active operation on this DSO session.  For

Isn't this already mandated by 8490?

(Hmm, the interaction of TLS early data's replayability and MESSAGE ID
uniqueness might require some thought.  But the MESSAGE ID uniqueness is
within a DSO session, not global, so that may not make a difference.)

Section 6.3.1

   The other header fields MUST be set as described in the DSO spec-
   ification [RFC8490].  The DNS OPCODE field contains the OPCODE value
   for DNS Stateful Operations (6).  The four count fields MUST be zero,
   and the corresponding four sections MUST be empty (i.e., absent).

We may not need the 2119 terms for the requirements duplicated from
8490.

   For collective remove notifications, if CLASS is not 255 (ANY) and
   TYPE is not 255 (ANY) then for the given name this deletes all
   records of the specified type in the specified class.

(et seq) What does it mean to "delete a record", from the recipient's
point of view?  (How does the server communicate that the RRset's
contents have changed to a completely disjoint value -- delete plus add?)

   a SUBSCRIBE request, subject to the usual established DNS case-
   insensitivity for US-ASCII letters.  If the TYPE in the SUBSCRIBE
   request was not ANY (255) then the TYPE of the record must match the
   TYPE given in the SUBSCRIBE request.  If the CLASS in the SUBSCRIBE

nit: we switch from using the indefinite article to the definite article
with "SUBSCRIBE request", which is a bit jarring since we don't give a
great indication of what distinguishes the definite case.

Section 6.5

It's not entirely clear to me that we need quite this much detail about
discovery proxy operations, in order to motivate RECONFIRM.

If we're going to talka bout Apple's dns_sd.h API (which I have somewhat
mixed feelings about to begin with), we should have a reference for it.

Section 7.1

   Deployment recommendations on the appropriate key lengths and cypher
   suites are beyond the scope of this document.  Please refer to TLS
   Recommendations [RFC7525] for the best current practices.  Keep in

Please cite this as BCP 195.

Section 7.4

   servers.  The server may keep TLS state with Session IDs [RFC8446] or
   operate in stateless mode by sending a Session Ticket [RFC5077] to

5077 was made obsolete by 8446; from the practical side of tings there
is no wire-visible distinction between stateful session IDs and
stateless session tickets.

Section 10.2

I think RFC 7858 needs to be normative.

Likewise, RFC 8310.

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 12 Aug 2019 19:32:41 -0400

Comments below.

> On Aug 8, 2019, at 10:22 AM, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 

With the primary case of service discovery, this information is already available today as link-local multicast announcements. And many unicast DNS servers already have policy controls that would apply to subscriptions as well. We’re not really creating any new exposure.

> privacy of push transactions?

Analysis of message size is a component of traffic analysis. I can add a paragraph about this and reference the Padding TLV as discussed in RFC 8490.

> forget what we did for other documents referencing it.)

RFCs 8547, 8490, 8095, 7663, 7640, & 7242 are the most recent to reference the BSD socket api. Of these, only RFC 8095 reference the POSIX Base Specifications which probably isn’t useful since no one is going to go read the POSIX docs but instead read operating system docs. None of the other RFCs in this list provide a reference. I would like to skip this.

> requirements made in that document).

Need more specifics. If referring to:

   Generally, as described in the DNS Stateful Operations specification
   [RFC8490], a client must not keep a DSO session to a server open
   indefinitely if it has no subscriptions (or other operations) active
   on that session.  A client MAY close a DSO session immediately it
   becomes idle, and then if needed in the future, open a new session
   when required.  Alternatively, a client MAY speculatively keep an
   idle DSO session open for some time, subject to the constraint that
   it must not keep a session open that has been idle for more than the
   session's idle timeout (15 seconds by default) [RFC8490].

then changing “MAY" to “may" could resolve this issue.

> client authentication, maybe RFC 6125 with a DNS-ID check, or would that

This does not include client certificates, DANE, or out of band mechanisms. 6125 is helpful but only describes one approach.

> Is there a good reference discussing these techniques?

I can reference RFC 8499 which defines split DNS.

> Isn't this already mandated by 8490?

Are you asking us to change “MUST” to “must”? I haven’t heard it suggested before that you can only use 2119 terms once.

> within a DSO session, not global, so that may not make a difference.)

Yes, early data isn’t a concern because a new DSO session means all new subscriptions and new MESSAGE ID space.

> We may not need the 2119 terms for the requirements duplicated from

Are you asking us to change “MUST” to “must” here too?

> contents have changed to a completely disjoint value -- delete plus add?)

To “delete a record” means the record is being removed from the zone. That could be because the service is no longer offered or the host has been decommissioned. In mDNS (RFC 6762), an announcement with TTL 0 is used to signal a delete. This could trigger a PUSH notification deleting the record. A received DNS UPDATE message could also trigger a PUSH notification deleting a record.

If the name of a DNS service changes then, yes, the old service is deleted and the new service is added (although the delete doesn’t have to come before the add).

> great indication of what distinguishes the definite case.

I will change “a SUBSCRIBE request,” to “the SUBSCRIBE request,”

> mixed feelings about to begin with), we should have a reference for it.

Do you prefer something like

https://opensource.apple.com/source/mDNSResponder/mDNSResponder-878.70.2/mDNSShared/dns_sd.h.auto.html <https://opensource.apple.com/source/mDNSResponder/mDNSResponder-878.70.2/mDNSShared/dns_sd.h.auto.html>

or

https://github.com/IETF-Hackathon/mDNSResponder/blob/master/mDNSResponder/mDNSShared/dns_sd.h <https://github.com/IETF-Hackathon/mDNSResponder/blob/master/mDNSResponder/mDNSShared/dns_sd.h>

> Please cite this as BCP 195.

Ok.

> stateless session tickets.

Ok. I can change this to:

   TLS Session Resumption [RFC8446] is permissible on DNS Push Notification
   servers.  However, closing the TLS connection terminates the DSO session.

> I think RFC 7858 needs to be normative.

Ok.

Thanks for the detailed review!

Tom

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 14 Aug 2019 19:50:14 -0500

> With the primary case of service discovery, this information is already available today as link-local multicast announcements. And many unicast DNS servers already have policy controls that would a…

It sounds like it, yes, but thanks for checking.

> Analysis of message size is a component of traffic analysis. I can add a paragraph about this and reference the Padding TLV as discussed in RFC 8490.

Thanks!

> RFCs 8547, 8490, 8095, 7663, 7640, & 7242 are the most recent to reference the BSD socket api. Of these, only RFC 8095 reference the POSIX Base Specifications which probably isn’t useful since no o…

Skipping it seems like a good plan; thanks for checking the prior art.

> then changing “MAY" to “may" could resolve this issue.

I think that was what I was thinking of, yes, and the proposed resolution
sounds good.

> This does not include client certificates, DANE, or out of band mechanisms. 6125 is helpful but only describes one approach.

I guess it's pretty unclear to me what the normative value of the "MAY" is
if this is totally up to deployment preferences (but I definitely support
having all of those as options!).  So perhaps we could consider an
alternate tack, like "In some deployments the trust relationship between
client and server might be further strengthened, such as via TLS client
authentication, but since the trust relationship is a local deployment
matter, the details of such authentication are also a matter for local
configuration".  (But probably with fewer words, if possible.)

> Are you asking us to change “MUST” to “must”? I haven’t heard it suggested before that you can only use 2119 terms once.

It's not a hard rule, but the cost/benefit of having them get out of sync
tends to skew towards only using them once.  In this case, the reader may
want to know whether this is a new requiremnet for push vs. something that
they get for free with a stock DSO implementation, for example.

> Are you asking us to change “MUST” to “must” here too?

Slightly weaker than asking to change, but the same story, yes.

> If the name of a DNS service changes then, yes, the old service is deleted and the new service is added (although the delete doesn’t have to come before the add).

Okay, thanks for confirming.

> https://github.com/IETF-Hackathon/mDNSResponder/blob/master/mDNSResponder/mDNSShared/dns_sd.h <https://github.com/IETF-Hackathon/mDNSResponder/blob/master/mDNSResponder/mDNSShared/dns_sd.h>

Hmm, not an easy choice, but probably the apple.com one.  (Using a specific
commit hash rather than the 'master' symbolic ref would make the github one
potentially more archival/stable, but in this case I think the authority of
Apple is preferred.)

>    servers.  However, closing the TLS connection terminates the DSO session.

Thanks!

> Thanks for the detailed review!

You're welcome!

-Ben