Dnssd Status PagesExtensions for Scalable DNS Service Discovery (Active WG)
Int Area: Suresh Krishnan | 2013-Oct-25 —Chairs:
IETF-104 dnssd minutes
Session 2019-03-25 1610-1810: Berlin/Brussels - Audio stream - dnssd chatroom
IETF 104 - DNSSD WG Minutes Prague, Czechia Monday, March 25, 2019 16:10-18:10 Monday Afternoon session II Berlin/Brussels (meeting room) Introduction (Chairs - 10 minutes) Chairs: Barbara Stark, David Schinazi Notes: Stuart Cheshire, Éric Vyncke Jabber: David Schinazi ====================================================================================== https://datatracker.ietf.org/meeting/104/materials/slides-104-dnssd-chairs-01 ====================================================================================== There were rounds of applause for exiting AD Terry Manderson and new AD Eric Vyncke. Update on DNS Stateful Operations, Push, Discovery Proxy (Stuart Cheshire - 5 minutes) ====================================================================================== https://datatracker.ietf.org/meeting/104/materials/slides-104-dnssd-cheshire-status-update-01 ====================================================================================== Update on DNS Stateful Operations, push notifications and discovery proxy. DNS Stateful Operations (draft-ietf-dnsop-session-signal) is now RFC 8490 ;-) DNS push has now an implementation by Ted Lemon and he discovered a small issue... Because of the way the DNS UPDATE message format was borrowed for DNS Push Notifications there was no way to express the DNS CLASS of a deleted record. New simpler encoding fixes this. Stuart will send the text to the list. Stuart Cheshire will email the list shortly to discuss latest changes to DNS Push. DNS Push will go into WG last call today which will end 2 weeks after the end of this IETF then follow the process with a view to RFC publication by IETF-105. Terry Manderson: Agrees that WGLC is warranted, because changes are substantive. Discovery proxy went to a WGLC, but more clarification is required. Also discovered during testing Ted's implementation. Stuart Cheshire assumes that no further WGLC is required. Stuart Cheshire will email the list with details of the changes so everyone can take a look. David Schinazi: We'll start a new WGLC for two weeks after this IETF to confirm everything is OK. Service Registration, implementation experience, and more (Ted Lemon, 15 minutes) ================================================================================= https://datatracker.ietf.org/meeting/104/materials/slides-104-dnssd-lemon-implementation-report-00 ====================================================================================== All specifications have been implemented. Stateful operations implemented in mDNSResponder Discovery proxy also implemented but without link naming and not yet packaged for OpenWRT. Tom Pusateri: perhaps a bad idea to start LC during the IETF week. David Schinazi: Chairs will start a WGLC for mDNS relay and SRP after this IETF. Update Proxy (Tom Pusateri - 20 minutes) ====================================================================================== https://datatracker.ietf.org/meeting/104/materials/slides-104-dnssd-pusateri-update-proxy-01 ====================================================================================== This could be a rechartered item for WG: how to use only unicast to discover the proxy. Proposal: send the updates (with pre-shared key) only to a few boxes on the network rather than the usual multicast. During Tom's description: Ted Lemon: ask clarification about what sends the updates; Tom: the services. Subdomains can be discovered via mDNS request or by generating the subdomains based on the IP prefix. Unicast transition: after discovery the update proxy, all further requests send unicast to the discovered update proxy. Tom compares discovery proxy and his proposal for update proxy showing a big change in the amount of multicast traffic. Stuart Cheschire: good chart for comparing, O(n^2) should specify what n is Tom: n^2 = #subdomains * #responses Stuart: not really the same 'n' then => needs to be clarified in the table. Let's talk off-line for more discussions. With the specific case that the source address of the multicast packet is not always where the service resides. Also, discovery proxy traffic should be less because clients only search for services they are interested in and not the full set of services. Tom: good points, I will update the chart Stuart: do we have time to continue the discussion? Chairs: yes Stuart: I am sad that printers advertised their services using names with hexadecimal rather than any webui to change name, so what about a PSK? But, let's not be constrained by history and feel free to define new mechanisms. Code exists on github (rupdateproxy) and is mostly working (next steps TSIG, TLS, subdomain discovery, ...) Questions: Stuart: good job, let's work at next hackathon, the appendix comparing with Ted's discovery idea but this is not really competing: the two ideas could work together Ted Lemon: no need to answer the question, we have discovery proxy and SRP, so it feels that this draft solves the very same problem. We need to have a simple choice between the solutions. Ted had a similar idea in IETF Argentina but Stuart convinced him to abandon this approach. Tom: starting from mDNSResponder proved to be faster indeed but what if you cannot start from mDNSresponder => then my approach is faster to implement. WG chairs: Ted can you explain the above in more details on the list Ted: I would rather prefer to write a document on this Private Subdomains (Tom Pusateri - 10 minutes) ====================================================================================== https://tools.ietf.org/html/draft-pusateri-dnsop-private-subdomains-01 https://datatracker.ietf.org/meeting/104/materials/slides-104-dnssd-pusateri-private-subdomains-01 ====================================================================================== Make it easy to create private subdomains (authenticated and encrypted access). A trusted provider is used to create a private subdomain, the use UPDATE to store a public key, all access to this subdomain need to be authenticated with the private key and encrypted to the server. Mohit Sethi: how can I share the private key in all my devices? while the public key is stored in one place Tom: this was just a possible way of doing but should be more opened Christian Huitema: ask confirmation that the private key is shared by all devices Tom: yes, Ashu Singh: we could use transparency certificates Tom: could also synchronize à la PGP Tom had some questions that he wanted to ask the WG but will do it over the list. Chairs: need to terminate for sake of time all remaining questions to the list TIMEOUT resource records (relevant to service registration protocol and update proxy) (Tim Wattenberg - 5 minutes) ====================================================================================== https://tools.ietf.org/html/draft-pusateri-dnsop-update-timeout-02 https://datatracker.ietf.org/meeting/104/materials/slides-104-dnssd-wattenberg-update-timeout-00 ====================================================================================== It is about the transfer RR lifetime state between zone's primary and secondaries and store the lifetime during server restarts. This would avoid services registered via SRP but clean-up can not happen in case of server restarts, ... Running code at Hackathon (timeoutd) by scanning the existing TTL 'live' and issuing an UPDATE to kill 'to be determined' RR. I-D presented at DNSOPS but getting more advices is always useful. Ted Lemon: you may consider using a generic ANY that can be overwritten by more specific Pieter Lexis: not opposed to the draft but no intention to implement it Tom: Joe Abley did not want a specific record for handling timeout Stuart: there are other ways to safe lifetime than RR but the biggest advantage of this timeout RR is interoperation. Also, language around the handling of the RR by secondaries is unclear. David Schinazi: is it specific to DNSSD ? Tim: intention is to present to DNSOPS, already a lot of discussion on the DNSOPS mailing list Private DNS Discovery with TLS and ESNI (Christian Huitema -- 40 mins) ====================================================================================== https://tools.ietf.org/html/draft-huitema-dnssd-tls-privacy-00 https://datatracker.ietf.org/meeting/104/materials/slides-104-dnssd-huitema-privacy-00 ====================================================================================== One use case is clients/services on the same network without revealing identity. Design assumptions: Using TLS 1.3 which provides server privacy (because server cert is encrypted) and also the Encrypted Service Name Indication (ESNI) encrypted via the server public key. Can also UDP (QUIC or DTLS). First multicast over UDP with TLS client hello ESNI, only the right server will be able to decrypt the request and send back a unique response. But, ESNI relies on DNS which gives out the public key... which is readable by everyone. Fix: provision the ESNI public only to authorized clients (and renamed this 'public key' into 'discovery key'). Mohit: kind of like the idea. TLS is asymmetrical while dnssd is more peer-to-peer so symmetrical. So, how to decide? Christian: in one use case (diabetic sensor & mobile app), it is very clear Mohit: the 'discovery key' must be provisioned Christian: yes Open question: what if server does not use DTLS or QUIC? Still use DTLS/ESNI to discover a DNS server and use this DNS server as usual with DNSSD. Chris Wood: 'discovery key' is used for two different usages, this could be strange. Also, DTLS is heavy. Alternate proposal for ESNI, what about distributing a cert (trust anchor) to all participants to simplify ESNI. Christian: as request is sent multicast, all servers can see the request then Big issues if private key is leaked as history can be read => should rotate the key quite often. Ashu Singh: can we use this for normal servers Christian: no, it is not for your normal CDN servers ;-) Mohit: why not issuing a new key after handshake? Christian: ESNI is useful to hceck whether the request was for you Chairs: during WG, we make good progress but no more during over the week. What about having a side meeting this week? Positive replies. Stuart Cheschire, Ashu Singh, Chris Wood, Christian Huitema. Let's have this side meeting. Mohit: is it for a single subnet Christian: yes Rechartering (Chairs & Tom Pusateri - 10 minutes) 7 opened issues in the DNSSD github but no further comments. Chair: we will send the github link to the list to attract comments. Perhaps no need for re-charter. We will see. Tom: some of issues will need discussion (esp the new topics) and did not feel comfortable to propose a re-charter on his own. Conclusion and AOB (Chairs - 5 minutes) ====================================================================================== Minutes from the Private DNSSD Design Team Meeting 2019-03-27 08:00-09:00am Prague local time Attendees: Stuart Cheschire, Ashu Singh, Chris Wood, Christian Huitema, David Schinazi Minutes: David Schinazi ====================================================================================== We will focus on Christian's latest ESNI proposal: draft-huitema-dnssd-tls-privacy Work on implementation should start soon. Chairs will organize periodic videochat interims, 2 hours long once a month. Focus on the multicast use-case; networks that do not support multicast can be supported by creating a dumb server that replicates the multicast traffic as unicast. The discovery key (hidden server public key) does not have forward secrecy, need to rotate that key periodically, so we'll need to build a key rotation mechanism, but we can reuse the key acquisition mechanism that will need to be built anyway. Christian should add text about certificate leakage, certificate transparency, and lack of perfect forward secrecy.