DNSSD Minutes IETF 102, Montreal, Canada Thursday, July 19, 2018 9:30-12:00 Local Time (EDT) Duluth Room Chairs: David Schinazi, Tim Chown (absent) Tim Wicinski (temporarily standing in for Tim Chown) Minutes: Barbara Stark Jabber: Tim Wattenberg -------------------------------------------------- Agenda -------------------------------------------------- Introduction -- Chairs -- 5 mins Discovery Proxy -- Stuart Cheshire -- 15 mins draft-ietf-dnsop-session-signal (DNS Stateful Operations) Awaiting shepherd writeup and IESG decision draft-ietf-dnssd-push (DNS Push) Currently held by working group, discuss next steps draft-ietf-dnssd-hybrid (Discovery Proxy) Approved by IESG, waiting for DNS Stateful Operations and DNS Push Discovery Relay -- Ted Lemon -- 15 mins draft-ietf-dnssd-mdns-relay Working group document, discuss starting working group last call Service Registration -- Ted Lemon -- 15 mins draft-sctl-service-registration Individual draft, discuss adoption CoRE Resource Directory DNSSD Mapping -- Kerry Lynn -- 15 mins draft-ietf-core-rd-dns-sd CoRE working group document, asking for input from DNSSD Privacy -- Stuart Cheshire -- 50 mins Discuss adoption and aim to reach consensus on way forward draft-ietf-dnssd-privacy (Privacy Extensions) draft-huitema-dnssd-prireq (Privacy and Security Requirements) draft-huitema-dnssd-privacyscaling (Privacy Scaling Tradeoffs) draft-ietf-dnssd-pairing (Short Authentication Strings) draft-ietf-dnssd-pairing-info (Pairing Design Issues) Rechartering -- Chairs & Tom Pusateri-- 30 mins Conclusion -- Chairs -- 5 mins -------------------------------------------------- Minutes -------------------------------------------------- 9:30 Chair Slides David Schinazi presented. Thanks to Tim Chown, who is stepping down as chair. Applause for Tim Chown from room. Contact Terry Manderson if you would like to be considered for the open co-chair position. Hackathon update Ted Lemon: It was very useful. Good discussion. Running code. Tim Wattenberg: It was good. -------------------------------------------------- 9:37 DNSSD Document Status Update Stuart Cheshire presented. dnssd-push which is currently held, will probably need some edits after IETF LC of Stateful Operations Terry Manderson: I approved earlier today. Tom Pusateri: I intend to re-read. Stuart: Yes, I intend to do that to. -------------------------------------------------- 9:41 DNS Discovery Relay Ted Lemon presented slide 5 Ted: May remove Discovery Proxy from document. Stuart: Discovery Proxy was in the draft as optional. Ted: It would be really great to have a second implementation. If you want to do interop with me, let me know. Tim Wicinski: It's in WGLC and there have been no comments. Read it and comment. David: Who has read? Please provide comments or explicitly say you have no comments. Tim Wicinski will shepherd -------------------------------------------------- 9:51 Service Registration Ted Lemon draft-sctl-service-registration David: We will reach out to DNSOP list and get review. Kerry Lynn: Discussion in CORE group about how a device can assert veracity of its claim that it owns a service. Are any people in this group investigating this question? Ted: You are talking about enrollment process. I agree that may be a problem. But I think we may be ok here (in this doc). But I would like to work with you on that. I think it applies to homenet, too. Anima also has an enrollment process. I don't want to see many, many enrollment processes. Andrew Sullivan: I agree. I don't think that belongs in this document. Stuart: With normal DNS Update, the assumption is that if you have the key you are trusted to make the update. What we want to do here is let any device with credentials make the update. But we also want to make sure it cannot be stolen. We need for Update to be the current DNS Update command (semantics). But we need to specify the sanity checking that gets done. Ted: We don't have Update constraints in this doc. We're trying to keep this down to single Update. So we're putting additional requirements on the server. slide 7 Tom Pusateri: You may have to do A/AAAA Registration over TCP and not UDP. Ted: Yes. This is something we need to decide what we want to do. Mark Andrews: It doesn't matter. Ted: We don't have proof of connection. This can potentially be used by device on local network to get access to device not on local network. I don't think we're ready to say it's not a problem. Mark: Disagree. Stuart: I think I agree with Mark. I think packing everything in one Update is useful to constrained device. But we need to consider downsides of possible attack. Ted: I'm not ready to say we don't care. We need to think about it more. David S: I think I agree with Ted. Ted: I don't think we actually have a problem with constrained devices. slide 12 Tom: When name is already taken there's no indication for what to try next. Not just problem here, but problem in general. Ted: Stuart and I talked about this and don't know of cases where this happens in the wild. We've seen it happen when we're doing strange things and a device with multiple network connections ends up competing with itself. There needs to be a user interface where you can configure this stuff. We need to figure out if name change is something stored in the service. Dave Robin: It's not hard to make unambiguous. Use MAC address. You are right that there is no delete function and you rely on garbage collection. But I think there does need to be a delete key here. I also want to talk about issue of replacing. I want to power down and have it say "delete me" during its dying breath. Ted: I don't think dying breath is realistic. Dave R: I'm in commercial space where we have a special ability to do this. Ted: You could go into UI and reclaim there. I'm not saying you're wrong, but I think you also want the UI. Stuart: We should make note of 3 things. (1) You're right about delete function need. (2) DNS server may not be the same one run on your corporate site. (3) The draft needs to talk about the UI. Mark: This is a problem that has already been solved. Kerry: Human in the loop is needed to set up security association. If printer is already on the link using mDNS, hasn't it already claimed the name and able to defend it? Ted: I don't think that's the same. Kerry: Is the device that is doing the registration also participating in mDNS? Ted: It's a good question. Stuart, I think you've said you think it's a good idea to also be doing mDNS? Stuart: I think you (Ted) have some use cases where there will not be mDNS. * Delete: yes last slide: Ted: I'd like to adopt. Tom: I think what is here is good, but I think RFC 6367 already has some of this and the name of this doc is confusing. If we changed name of this doc, I could support. Because this is not a new protocol. Ted: Are you aware of cases where it is being used for service registration? Tom: No. But 6367 says we don't need to define service registration because we have DNS Update. Will take this to email. Tim Wicinski: Address any Underscore naming attributes (if needed) Mark: I think you want to do some things. David: Adoption call goes through next week. If you do or don't support adoption, say so. Currently leaning towards adoption. ------------------------------------------------------------- 10:37 CoRE Discovery Mapping Kerry Lynn presented. Dave Thaler: Issue we talked about in CORE is about coming up with the oic.r label. This issue needs to be discussed. Is there any value in having per organization "dot" or just per resource "dot"? Don't have to worry about how to map? Kerry: I'll take you points one at a time. RFC 5690 was first output of CORE WG. That allows any rt as value and was done before there was any operational experience with CoAP. Maybe now is time to tighten up values of metadata. In general case, perhaps it is up to anyone who wishes to export to decide how translation is done. I think that is your point -- why break this up instead of seeing it as flat. Dave T: I don't think that has correlation with rt. Kerry: Trying to find semantic alignment with CORE and DNSSD. But there doesn't have to be direct or one to one translation. Barbara Stark: Broadband forum has uses for these records, we need to make sure CoRE does not impact that. We need to separate this from other uses Kerry: there is a heuristic Barbara: Just make sure we do not need to change existing devices - we have our rt and should not need to use this heuristic Tim Wicinski (as DNSOP co-chair): We have doc in WGLC that built entire IANA registry. As these docs come up, people need to pay attention. draft is draft which fixes existing is David S: Kerry's draft is a Core WG doc, CORE chairs and DNSOP chairs need to talk. Carsten Bormann: We want to provide both registered services can exist and things are useful for people who just want to build things. Maybe not everything registered on CORE needs to be registered on DNS-SD. Dave R: I have problem with using rt for service. Don't you want to export concept of thermostat, and isn't that more "if" than "rt"? Just register "if" and be done with it. David S : Please discuss this on mailing lists: cross-post core and dnssd Dave T: Don't relate "rt" with protocol. As long as you can put something in txt record you can get everything in one record. Kerry: Service types was not intended to be human readable. Stuart: Right. Dave said earlier that rt has nothing to do with service type. Mapping these may not be the right thing. rt is data model. Kerry: We will take this to the list. --------------------------------------------------------------- 11:05 DNSSD Privacy Stuart Cheshire presented on behalf of Christian Huitema Mohit Sethi: What do you mean by shared public key? Stuart: The intention is the device has key pair and it has shared its public key with devices around it. Mohit: So later, I will still know who is talking to these devices. Stuart: That's why "volunteers?" on the slide has a question mark. We have not explored all possibilities. Chris Wood: Trying to understand what you (Mohit) are asking. Mohit: Maybe I am misunderstanding. Stuart: I think Chris is saying there are mechanisms that don't reveal what key you are using. Chris: Yes. Another comment -- with Christian we are looking at some of the messaging in the shared key space. People interested in collaborating should let us know. David S : We're interested in opinions on this and on requirements. Dave R: This is reasonable. I assume we want observers not to know who is talking to whom. But people will know who has MAC address. They may not know contents of discussion, but they will always be able to figure out who the communicating parties are. David S : My understanding is that privacy is about fixing many holes. But we should not say we should not fix some holes just because we cannot fix all. Dave R: Not my point. I support this doc. I was just pointing out it does not support all aspects of privacy. It prevents additional PII from being leaked. Need to be clear on goals. Stuart: I think we could change some word to clarify things. Sara Dickinson: We've got new proposed research group on privacy enhancements (Privacy Enhancement Research Group -- PEARG). Should use RFC6973 (Privacy Considerations for Internet Protocols) as resource. It has good definitions, so people can start using common terminology and language. It also occurs to me this is a really a more generalized problem. Chris: Are there expectations that solution must cover all 3 scenarios? David : We need to see what's possible. It would be nice if we could have 1 solution fits all. Chris: One size fits all may not be possible. I think everything but last 2 (on slide 8) are difficult. Dave T: I think hardest (slide 8) is resistance to DoS attacks. Chris: Will talk about ways to optimize off-line. David: Chris, can you send paper you mentioned to list. Andrew Sullivan: Threat amplification should not be possible. Chris: You were thinking you want to scope the solution to not revealing new PII. Does that mean solutions that solve more than this are not in scope? David : More could be in scope. We need to clarify our scope more. David : Who has read at least one version of these drafts (slide 2)? Who has read all? --------------------------------------------------------------- 11:38 Using Github David Schinazi presented from the Chair slides David: Should we start using github? Tim Wicinski: DNSOP co-chair. We are using github for some docs. But not for full WG engagement; more that authors are using. Stuart: I see no reason not to. Ted: I agree with Stuart. Stuart/Tim/Ted: There is difference between individual draft and WG draft. But even for individual draft, no intention to keep it private. David: This wouldn't be requirement from chairs. We would set it up and offer it to authors. We'll pick a draft and see how it works. Stuart: Is there anyone who believes this isn't what we should do? -------------------------------------------------------------- 11:43 Rechartering David Schinazi presented the final slides from the Chair slides that describe the charter. Tom Pusateri presented Rechartering slides Tim Wicinski: My employer has lots of apps. I love a lot of these ideas. I'm all for this. Kerry: I remember when this group was first chartered. There were things in initial charter proposal for making things work over mesh or multi-link network. I want to make sure we capture homenet requirements this time and that they are part of charter. Dave T: I want to talk more about "finding things near me" and "finding things associated with me". Phillip Hallam-Baker: You have listed different methods of discovery. We need abstract definition of what discovery is. David: Please bring your proposal to list. Terry Manderson: Want to set aside more time than what we have today to discuss. Note we still have existing charter items to complete. David: Who volunteers to help draft the re-charter? Volunteers who raised hands: Kerry Lynn, Ted Lemon, Tom Pusateri, Tim Wicinski ------------------------------------------------------------- 11:59 Wrap-up David Schinazi read out action items he recorded: 1) DNS Stateful Ops will go through IESG telechat early August, then authors will update DNS Push and we can move forward. 2) mDNS Relay we would like more review from WG 3) service registration WG adoption imminent 4) Potential new draft for EDNS0 lease authors should bring the draft to the WG list 5) CoRE lively conversation on mapping participants should continue conversation, cross-posted on dnssd and core lists 6) Privacy Need to clarify scope of DNSSD privacy We'll look into RFC6973 Get early review and input from PEARG Chairs should make it easier to discover which privacy draft to read first 7) Github Support from working group for experimentation Chairs will experiment with one draft 8) Recharter Kerry, Ted, Tom, Tim Wi to provide new text on mailing list