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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 04 Mar 2020 22:04:32 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnssd-prireq-05: 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-prireq/

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

Section 1

   connected to the same network.  Consider for example a traveler
   wanting to upload pictures from a phone to a laptop when connected to
   the Wi-Fi network of an Internet cafe, or two travelers who want to

[both devices are on the same Wi-Fi, right?]

   Disclosing Information  In this document "disclosing information" is
      also focused on disclosure by data conveyed via messages on the
      service discovery protocol layer.

This is generic non-identity but still potentially sensitive data,
right?

Section 3.2

   kinds of means for making DNS-SD resource records available.  These
   means comprise but are not limited to mDNS [RFC6762], DNS servers
   ([RFC1033] [RFC1034], [RFC1035]), e.g. using SRP
   [I-D.ietf-dnssd-srp], and multi-link [RFC7558] networks.

nit: this "e.g." seems out of place.

Section 3.2.2

There is, of course, also no authentication requirement to claim a
particular instance name, so an active attacker can provide resources
that claim to be Alice's but are not.

Section 3.3.2

This sort of problem frequently ends up with a third-party "trusted
introducer", though it's not clear that mentioning this in the document
will add value.

3.4.2

I'm given to understand that for many radio technologies, multicast is
both effectively broadcast and has specific spectrum
requirements/properties that make it especially scarce, compared to
unicast spectrum.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 6 Mar 2020 16:17:08 -0800

Ben,

I am trying to incorporate your feedback, but I have issues with two of
your points.

...
> introducer", though it's not clear that mentioning this in the document

I would rather not say that, because people are also looking at P2P
pairing systems -- for example, let your phone read a QR code from the
the screen of your friend's laptop. As you say, we can leave that to
developers, we don't need to try add value.

> requirements/properties that make it especially scarce, compared to

I am not sure about the spectrum requirements. AFAIK, for Wi-Fi, unicast
and multicast operate on the same frequencies and the same channel.
Multicast requires transmitting at the lowest data rate acceptable for
all recipients, which means that the transmission of a multicast message
may last longer than the transmission of a unicast message, maybe much
longer, and that means occupying the spectrum for a longer time. On the
other hand, the same transaction using unicast would require several
messages, and that too creates requirements on the channel. I am
concerned that explaining the issue with fairness would require a long
development.

MDNS does rely on multicast, and writing something about the cost of
multicast would beg the question, what about MDNS? That's a fine
discussion to have in the DNSSD working group but, again, I don't think
the privacy requirement document is the right place for that.

Now, if you have a good citation, we could point at it.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Fri, 6 Mar 2020 16:41:47 -0800

Ben,

Thinking about this some more, I think I can propose a minimal edit to
the section 3.4.2:

    <t>Creating a discovery protocol that has the desired security
    properties may result in a design that is not efficient.
    To perform the necessary operations the protocol may
    need to send and receive a large number of network packets,

>>>    or require an inordinate amount of multicast transmissions. <<<

    This may consume an unreasonable amount of network capacity,
    particularly problematic when it is a shared wireless spectrum.
    Further, it may cause an unnecessary level of power consumption
    which is particularly problematic on battery devices,
    and may result in the discovery process being slow.</t>

That is, just a subtle hint, but enough to draw attention on potential
issues.

Would that work?

-- Christian Huitema

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 6 Mar 2020 16:48:12 -0800

Hi Christian,

> That is, just a subtle hint, but enough to draw attention on potential

It was a non-blocking comment and I was not sure that any change was
needed, so even "do nothing" would work :)
That said, I do think this strikes a good balance, so thank you.  (Whether
"or" or "and/or" is better is probably a matter of style.)

Thanks,

Ben

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sat, 7 Mar 2020 07:43:14 +0000

Ben

About your comment in section 3.4.2, Christian is correct on the two points:
- multicast over WiFi is sent over the same channel as unicast but indeed 'waste' bandwidth (probably what you meant by 'spectrum')
- the prireq document is about DNSSD and not on mDNS, so, talking about mDNS is out of scope imho

Regards

-éric

    

    -- Christian Huitema

    _______________________________________________
    dnssd mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/dnssd