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

[Benjamin Kaduk <[e-mail]>]

On Mon, Aug 12, 2019 at 07:32:41PM -0400, Tom Pusateri wrote:
> Comments below.
> 
> > On Aug 8, 2019, at 10:22 AM, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> > 
> > 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?
> 
> 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.

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

> > 
> > Can we have a discussion of padding policy to attempt to preserve the
> > 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.

Thanks!

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

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

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

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

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

> > 
> > 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?
> 
> I can reference RFC 8499 which defines split DNS.
> 
> > 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?
> 
> 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.

> > 
> > (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.)
> 
> Yes, early data isn’t a concern because a new DSO session means all new subscriptions and new MESSAGE ID space.
> 
> > 
> > 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.
> 
> Are you asking us to change “MUST” to “must” here too?

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

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

Okay, thanks for confirming.

> > 
> >   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.
> 
> I will change “a SUBSCRIBE request,” to “the SUBSCRIBE request,”
> 
> > 
> > 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.
> 
> 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>

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

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

Thanks!

> 
> > 
> > Section 10.2
> > 
> > I think RFC 7858 needs to be normative.
> > 
> > Likewise, RFC 8310.
> 
> Ok.
> 
> Thanks for the detailed review!

You're welcome!

-Ben