Minutes IETF104: dnssd
minutes-104-dnssd-00

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.