# Minutes for DNSSD at IETF 103 on 2018-11-08 Minutes takers: Barbara Stark and Chris Wood Jabber Scribe: Mikael Abrahamsson Video of the session: https://www.youtube.com/watch?v=hPuTD19R-uQ ## Chair's Introduction David Schinazi presented. https://datatracker.ietf.org/meeting/103/materials/slides-103-dnssd-a-chairs-introduction-02 Charter discussion dropped from agenda. No other bashing. There were no questions. ## Roadmap Stuart Cheshire presented. https://datatracker.ietf.org/meeting/103/materials/slides-103-dnssd-b-cheshire-roadmap-00 Barbara: I would like to see this adopted as a WG item and morph into an architecture that describes how all DNSSD efforts work together. Jake Holland: Agree. As newcomer, it's a very useful document. Chris Wood: will help fill out privacy section in the text. Working Group hummed in support of adoption, no one in the room was opposed. Chairs will confirm adoption on the mailing list. ## Unicast Service Discovery Autoconfiguration Stuart Cheshire presented. https://datatracker.ietf.org/meeting/103/materials/slides-103-dnssd-b2-cheshire-unicast-00 There were no questions. David Schinazi: Please send the draft to the mailing list. Please read and comment on list. ## DNS push notifications Stuart Cheshire presented. https://datatracker.ietf.org/meeting/103/materials/slides-103-dnssd-b3-cheshire-push-00 There were no questions. David Schinazi: We did WGLC and didn't get a lot of comments. Please look at it again. This is your last chance to comment. Comments now? *no comments* ## Service Registration Protocol for DNS-Based Service Discovery Ted Lemon presented. https://datatracker.ietf.org/meeting/103/materials/slides-103-dnssd-d-lemon-service-registration-00 Terry Manderson (AD): Would like to thank Ted and Stuart for work put into the group. Please reach out to Ted and Stuart if you have cycles. Stuart Cheshire: Thank Terry for support. Will be at the next Hackathon. Connect to coordinate work. Barbara Stark: Yes, and we need people to review. How many people have read? *a few hands raised* David and I will both be reading and providing comments. Jake Holland: Are you referring to the privacy drafts? Barbara Stark: Referring to all the drafts. David Schinazi: We need more people reviewing the documents. Ted Lemon: Lots of activity on service registration in Montreal, explains limited activity more recently. ## Privacy ### Shared public key proposal Christian Huitema presented. https://datatracker.ietf.org/meeting/103/materials/slides-103-dnssd-e-huitema-privacy-next-steps-00 Slide 5 Mikael Abrahamsson: Should we have more bits for timestamp? Christian Huitema: OK, it does not change the principle. Slide 6 Ted Lemon: Why base64 encode these? Why not just binary? Christian Huitema: We could do that but it would be different from current encodings. Ted Lemon: If you're putting one signature in a message you could just use SIG0. Christian Huitema: Yes, do we want to keep DNS formatting or not? Lots of pros to keep. David Schinazi: Do we lose sleep proxy support by moving to binary messages? Stuart Cheshire: Thinking similar to Ted. We should design it assuming we're not tied to existing format. Then figure out if we can encode that in the DNS format since then we haven't compromised up front on the design. Let's not get wrapped up in the encoding. Would be possible to extend service registration for this use case. Ted Lemon: Worth preserving ability to preserve infrastructure for doing service discovery. But supporting binary labels isn't the end of the world. Stuart Cheshire: Might not work on some servers if not base64 encoded. Christian Huitema: Acknowledged. ### Fully asymmetric proposal Chris Wood presented. https://datatracker.ietf.org/meeting/103/materials/slides-103-dnssd-f-wood-private-discovery-00 David Schinazi: Are there any specific questions about this proposal before we try to compare the 2 proposals? *no questions* ### Discussion Chris Wood: Think TLS is excessive for the given use case. Christian Huitema: Yes, we can debate it. Daniel Kaiser: Given that structure of new proposal, why do we need a new draft? See email on mailing list. David Schinazi: Bob submitted to get the conversation started. Our goal is to only publish one document. Daniel Kaiser: Makes sense. Christian Huitema: There are parts I don't understand. How server mode is handled. Chris Wood: Server does need to be online. I don't know how Bob intends to reconcile that. Maybe Stuart knows? Stuart Cheshire: Bob's proposal was not designed with "server mode" in mind. I agree with your assessment. Christian Huitema: Can be reconciled. Stuart Cheshire: We will need to make engineering tradeoffs. Christian Huitema: First tradeoff we need to make is if we should support the server mode. David Schinazi: Clarify server mode? Christian Huitema: Server pushes records into DNS and uses that to respond. Mohit Sethi: Think last bullet is missing some details regarding side channels. Christian Huitema: Possible to make implementation decisions to mitigate them, e.g., randomize order of verification. Mohit Sethi: Randomization is not useful when you have two friends. Christian Huitema: Use case is people in the same room trying to discover one another without others learning. Trying to hide the fact that time of searching reveals server. Mohit Sethi: Sequential traversal of list will reveal some information. Dave Thaler: Size of list might reveal information too. Christian Huitema: Yes, it's a fingerprinting attack. Very hard to prevent. Chris Wood: Should consider this attack out of scope. Stuart Cheshire: The perfect solution is impossible. It's easy to come up with objections. But that's not a reason to give up. We can do better than cleartext here. Mikael Abrahamsson: Sometimes both modes are necessary if we can't address all use cases. David Schinazi: Want to focus on the main use case for now. Christian Huitema: DH exchange produces a symmetric key. David Schinazi: This reduces number of RTTs. Christian Huitema: Not really concerned about that on the local network. Chris Wood: Can you clarify the main use case? David Schinazi: Server mode would restrict the design and make things more complicated. (Chair hat off: do not feel it's a compelling use case.) Does anyone need to support the server mode use case? Stuart Cheshire: Do not disagree. Server mode is important for lower power devices that are asleep. Do those devices need privacy? Might have two overlapping circles on the venn diagram? Christian Huitema: What about devices you have on your body? Stuart Cheshire: Good point. Ted Lemon: What about the amount of multicast that is consumed? Sending a lot of messages is not good. Christian Huitema: Both proposals are multicast out and unicast in. Ted Lemon: Main advantage of DNS server version is that it reduces multicast traffic. If reducing that traffic is unnecessary, then perhaps not an issue. Mikael Abrahamsson: Do not see imminent improvements for multicast on WiFi. We should try to limit multicast messages sending since its costly for the receivers. Not sure about the amount of multicast for proposals, but we should aim to keep it down. Stuart Cheshire: Is the cost of multicast due to powering on the radio, or marginal cost on top of that? Mikael Abrahamsson: It's that and air time. There's also reliability to consider. In general case, multicast does not retransmit. Ted Lemon: Might need for unicast message delivery service to help discover conduit? Christian Huitema: Bob's discovery does discovery of DNSSD channel. Combinations of both proposals is possible but requires some work. Making Bob's proposal work would require the server to describe to the proxy a list of all clients and forward proxy unicast messages based on the advertised nonces. Mikael Abrahamsson: There's work in other WGs on low power devices. They have a lot of knowledge. Daniel Kaiser: Should we switch to one or two stage approach? Should we support both? David Schinazi: Not sure how per-app is related to one or two stage. Christian Huitema: Could incrementally discover things in multiple stages. Mohit Sethi: Stuart had a slide on scalability in Montreal. Stuart Cheshire: Preference leans towards single stage approach. In most cases it's one service you're discovering that may run other services. Dave Robin: Privacy gains are minimal with current chatty device, it might be a good idea to have multiple identities. Even if they currently share a MAC address. David Schinazi: Does anyone disagree that we should move to a one-stage approach? No one spoke up in support of having a two-stage discovery mechanism instead of the one-stage approach. Ted Lemon: Devices can give time-window profile to indicate when they are willing to talk to you. Mohit Sethi: Even if your devices synchronize. Low power devices are hard to make secure. Chris Wood: Do we need to consider TLS vs rolling your own crypto. Christian Huitema: This goes away with the one stage approach. David Schinazi: Does this remove the need for TLS in the protocol at all? Christian Huitema: Yes David Schinazi: Does anyone disagree that we should remove TLS from the protocol? No one spoke up in favor of using TLS in the protocol. David Schinazi: Stuart, can you check with Bob if this addresses his use case. Stuart Cheshire: Yes. Barbara Stark: Chris can you add an explanation of one stage vs two stage in minutes? Chris Wood: One stage: Send encrypted and authenticated service identifier, get encrypted and authenticated service response. Two stage: Send encryption and authenticated identifier, get encrypted and authenticated response, derive secrets, initiate subsequent queries encrypted using shared secrets. David Schinazi: Daniel, do you want to present some of the Bloom filter points from your mailing list post? via jabber, Daniel Kaiser said he had no microphone. David Schinazi: Christian, can you please roll up what was agreed today into the privacy document? Christian Huitema: Yes, as long as there is only one document. David Schinazi: Absolutely, the WG should only publish one privacy solution document, and that's the adopted one (draft-ietf-dnssd-privacy). Christian Huitema: Yes, and I will ask Bob Bradley to be co-author. David Schinazi: Thank you everyone. I think we have a way forward for privacy. ## Charter Showed Github site with recharter discussion. https://github.com/dnssd-wg David: Use of GitHub issues is encouraged to facilitate discussion.