* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Dnssd Status Pages

Extensions 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

Minutes

minutes-104-dnssd-00 minutes



          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.
          
          



Generated from PyHt script /wg/dnssd/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -