Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roman Danyliw's No Objection on draft-ietf-dnssd-prireq-05: (with COMMENT) #15

Open
huitema opened this issue Mar 5, 2020 · 0 comments

Comments

@huitema
Copy link
Owner

huitema commented Mar 5, 2020

Roman Danyliw 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:

Thanks for this document. Kuddos on the amazing ASCII art.

** Section 3.1.1. Per “Identifying devices leads to identifying people, either
just for tracking people or as a preliminary to targeted attacks.”, this didn’t
parse for me and the intent of the “just for tracking people” wasn’t clear. Is
the following the intent:

“Identifying devices can lead to identifying people, either for surveillance of
these individuals in the physical world or as a preliminary step for a targeted
cyber attack.”

** Section 3.1.2. Per “The requirement in that scenario is that the discovery
activity should not disclose the identify of either the client or the server”,
is something stronger more desirable? For example, is there any desire to
thwart the discovery of the “business and social interactions” between the
device owners?

** Section 3.1.3 It seems as if all of the same challenges of Section 3.1.1
“identifying people” and using the information for a “targeted attack” apply
here too (but it’s said in a different way). Is it worth link the same issues
across scenarios?

** Section 3.2. Per “Information conveyed via multicast messages can be
obtained by an on-link attacker, while unicast messages are only available to
MITM attackers.”, please clarify why a passive on-link attacker can’t see the
unicast messages?

** Section 3.2.5. Per “This combination of services and attributes will often
be sufficient to identify the version of the software running on a device”,
makes sense. Is it worth adding that with this information and traffic
analysis, you might also be able to get identity (track people).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant