IETF 105 DNSSD Minutes * Montreal, Canada * 2019-07-25 13:30-15:30 (EDT) (Thursday Afternoon session I) * Meeting Room: Duluth Chairs: David Schinazi, Barbara Stark AD: Éric Vyncke Jabber: Tim Wattenberg Notes: Michael Richardson, Christian Amsüss ============== Agenda + Notes ============== ## Introduction (Chairs - 15 minutes) Chair slides https://datatracker.ietf.org/meeting/105/materials/agenda-105-dnssd-03 Github organization https://github.com/orgs/dnssd-wg/ Today's session goals: See agenda, plus future plans. ## Update on DNS Push (Stuart Cheshire - 15 minutes) https://datatracker.ietf.org/meeting/105/materials/slides-105-dnssd-stuart-cheshire-update-on-push-00 * draft-ietf-dnssd-push - TLS close_notify vs. TCP reset - Allowing subscribe request in TLS early data? - Implementation report and demo Publication requested, feedback received and updated. What's new: reality is that anything that connects to a server that does not support push, should limit how often, and the document now talks about this. Also advice about when to use TLS early data. Discussion about TLS close_notify thread... Document now details when to TCP RST, when to use retry, etc. Duplicate SUBSCRIBE messages might be benign, or might be okay, but we want to make sure it gets flagged and fixed. hackathon: Ted, Barbara and Stuart had a productive time at the Hackathon working on the DNS responder for Mac, Linux and OpenWRT (prebuilt packages). Did demos and everyone can dogfood this at home. https://github.com/IETF-Hackathon/mDNSResponder Barbara: Friday Code Lounge at 10:00. will try to plug things together. Michael Richardson (MCR): Stuart, you have plugged the device's wired WAN port into home device, creating two layers of routers, and on inner port can now see the outer devices? Stuart: yes! (He goes on to explain benefit to Wi-Fi bandwidth) Ted explains that you want to do a build before Friday, because it takes more than 2 hours to build everything. ## Discovery Relay (Ted Lemon, 5 mins) https://datatracker.ietf.org/meeting/105/materials/slides-105-dnssd-dnssd-discovery-proxydiscovery-relayservice-registration-protocol-00 * draft-ietf-dnssd-mdns-relay - Implementation report - Future of the draft Ted explains features of this software in slide 2. Stuart Cheshire: Discovery Proxy is valuable for OpenWRT. Convincing enterprise routers to include it will be a harder sell, and maybe not a good idea because it will never be updated until end of lifetime. Tom asked about usability of VLANs instead. If configured, makes sense -- should add paragraph on how to choose one would be a good addition. David on document: Already adopted, WGLC failed for lack of interest. Nobody but authors had much interest. So chair question: If this is aimed at enterprise market, is there anyone from there who would say this is useful? As chair believe it's a good document, but to proceed as WG document needs more voices. Tim Wattenberg: If this is intended for enterprise vendors, then those routers probably can do VLANs. Would be interesting to hear good use cases not covered by this. No particular idea of whether good or bad. If not aiming for consumer but enterprise, question is whether it can't be solved in another way already. MCR: Sorry about silence there. People this is targeted at may not be in this room. This would be attractive for companies with farly remote locations. Even if there are VLANs, multicast is probably turned off over ancient frame-relay satellite links. Barbara: Which WG would you suggest? MCR: Maybe EMU, as the architecture is similar in how 802.1x works and EAP is backhauled over radius, not via VLANs/ David/Barbara: Update the document, and we'll start another WGLC. Stuart: It's only 29 pages, no more than an hour to read. If people have uninvolved contacts in enterprise, please pass on contacts so we can contact individually. Tom Pusateri: Operators know how to troubleshoot VLANS and they learned how to troubleshoot BOOTP relays but a Discovery Relay is different and they won’t know how to troubleshoot it. Another way to do this: IGMP proxying over a tunnel, and AMT. Compare approaches. Ted: Just to clear this up: There are two things. Discovery proxy is smart and does multicast resolution, Discovery Relay is the dumb thing just forwards. ## Service Registration (Ted Lemon, 15 minutes) * draft-ietf-dnssd-srp - Latest updates to the draft - Tom Pusateri’s comments - Implementation report - Future of the draft SRP updates services.arpa -> service.arpa makes more sense to Ted, so seems like the right way. TLS supported. either we say: "SRP update" / "RR update", or we say "RR Add" -> maybe **Register** says Tom Pusateri Tom: Call it an SRP Registration instead of an SRP Update. Ted: OK, I'll do that. Should we require TLS support? Tim: YES. Keith Moore via Jabber: Yes, require TLS always, even on LAN. Bernie Innocenti: Who signs the TLS certificates? Ted: Opportunistic. Bernie: TOFU? Ted: Would need to describe how to do that, but would like to use DANE but not ready yet. MCR: But you were already running over TLS. Ted: This is trying to solve a different problem. MCR: I don't think this is a useful feature. No device so constrained that it can't do TLS should be doing this. The gateway can be the thing that is the translator. Ted: This is not to do some mapping between Core and SRP. MCR said stuff that will get repeated on the Mailing list :-) Stuart says that the Thread group does not have a discovery protocol, but rather assumes the cloud does stuff. Homekit is not interested/has-not-deployed such a system, and wants it to work in the home without cloud help. Stuart suggests that the Thread world could provision a mesh local address for SRP updates. Ted agrees; suggests that this would work well. SLEEP PROXY: MCR suggests that unless the document is too big, or unless Sleep Proxy can exist without SRP, then it might as well be in the document, and the IESG will be happier with fewer documents. Ted: SRP registrations are the same for all use cases, to DNS server, to constrained network border router, or to SRP sleep proxy) Tim Wattenberg: Agree with previous statements. Good to have things in one document but clearly separated, because too many documents don't make it better. And now for something completely different: SRP protocol on 802.15.4 development board. (<10K of code) Tim wrote a simple SRP client at the IETF 102 hackathon. However, it does not do SIG(0) for update. Also implemented SRP proxy; receive SRP updates on port-53, and update a zone with DNS-update. Tom Pusateri brought up the issue, that we might wanna have a de-registration as well (if a service is taken down before the end of the lease lifetime). ## Future of the Working Group (Chairs - 30 minutes) David brings up option to move the privacy work to another WG and close this WG. Feedback: Stuart: agrees with what David is saying. Privacy is really important, and there is a lot more awareness of privacy. Thought about the questions about how to discovery in the privacy preserving way. If there are other people in the WG with good ideas, then happy to support that. Would not like to wrap up the WG just as the world is realizing that there is privacy. Ted: attended a side meeting on Wednesday, the NETUP(?), some of those people might be interested. Distributed something Privacy. Ad-hoc privacy... Sounds related says David. Work to come up with ways to do ad-hoc keying... Daniel Khan-Gilmore, encrypted email that doesn't suck (but has a good experience). There are synergies involved. Christien Huitema: has been trying for some years to get the privacy work started in this WG, and had come to the conclusion that it isn't going to happen. We have done some work that needs to be published, and he would like to find a way to publish the requirements documents. But as for the solution, but they have to come organically from the other groups that are doing discovery. David asks how many have read document... (about 10) Christian notes that the document expired, but can be revived. Michael McCool: WoT co-chair in W3C, and want to do it in a privacy preserving way. But fundamentally need a discovery service to distribute metadata. The real question is, where does this work belong? In DNS, and also there one in Core (RD). Two questions: what are the available services, and how do I find the service. But, some have said that if it's published, then it's already leaked. maybe DNS should only be the springboard to a controlled service that does not leak. Tim Wattenberg: the WG does valuable work, and we are not finished, so closing it down does not make sense. There is a problem with lack of participation on the ML. Today we got good discussion on the topics. Tom probably didn't want the WG to shutdown, but was making a wake-up call. Can not answer how to get the people in here. Éric Vyncke: Lack of interaction on privacy is concerning, good that reviewers showed. Document can stay here, but publicity to other WGs (DPRIVE) is good, people with privacy knowledge are there. David: Tried that, got little support from IETF community at large, nobody came here. Maybe they care about privacy but not in this context. MCR: SAAG is running right now, we're in conflict. People you wanted are over there. Would have gone there but thought this was interesting having read Christian's documents. Was unaware documents were stalled. Yes WG has difficulties, but not point to give up. Let's get SRP published. We're not done, encourage Christian to resume. Barbara: We would probably have been supposed to forward existing discussion to support rechartering. Ted: Support what Mike said. Missed TLS often because it was opposite DNS-SD. Likelyhood to get deepply committed privacy people opposite any SEC area is minimal. Doesn't have to happen at IETF meeting. Could present at HotRFC. W/rt energy on documents: reviewed all, sent substantial comments, then stopped seeing new versions. Not blaming anybody b/c done same things being busy on implementations. Lots of expertise in room, would be shame to disband. Clock rate of this WG is not 3x/a. It appears it's because it's not that fast. Not a reason to disband. Barbara: In Singapore we could have a joint meeting with HomeNet? Stuart: HotRFC would be great opportunity. Sec Area listed as a conflict. Tom Pusateri: Doesn't take a lot of work to say "I think it's good". Who are we doing this for? Initially people came with problem to be solved. Those are gone -- are they deploying it? Ask they vendors to implement it so they can deploy it? Need to answer that. David: What's actually supported in handheld devices? Stuart: Ted has been working (as contractor, now full time at Apple) on implementing this in mac- & iOS. iOS 13 and macOS Catalina have a fully functional push notification client. Connects to OpenWRT router. Pleasing to turn services on/off and see it working. Tom: Implementers went ahead and solved the problem in switches and routers in non-optimal way; those solutions are deployed today in campuses. Have to find compelling reasons to stop that and start this. MCR: Implementation question: Will I discover devices at home when connected via VPN? Ted: Yes. MCR: Wonderful. Killer app. Ted: When demoing at Apple, used that feature. Printout over Internet from California. Had IoT camera pointed at it. Stuart: Ted did demo for guy in charge. Didn't think it makes a difference because had a slide. But something about showmanship -- whole room in applause. David: Feels to me that consensus is on still being energy, not crazy fast but OK. Keep things open, keep shorter meeting in Singapore, joint w/ Homenet. Depend on what we get on agenda. Please don't wait for day before meeting. Ted: announcing DNS-SD homenet interaction for Singapore. ## Conclusion (Chairs - 5 minutes)