Minutes IETF103: dnssd
minutes-103-dnssd-01

# Minutes for DNSSD at IETF 103 on 2018-11-08

Minutes takers: Barbara Stark and Chris Wood
Jabber Scribe: Mikael Abrahamsson

Video of the session:
https://www.youtube.com/watch?v=hPuTD19R-uQ

## Chair's Introduction

David Schinazi presented.
https://datatracker.ietf.org/meeting/103/materials/slides-103-dnssd-a-chairs-introduction-02
Charter discussion dropped from agenda. No other bashing.
There were no questions.

## Roadmap

Stuart Cheshire presented.
https://datatracker.ietf.org/meeting/103/materials/slides-103-dnssd-b-cheshire-roadmap-00

Barbara: I would like to see this adopted as a WG item and morph into an
architecture that describes how all DNSSD efforts work together. Jake Holland:
Agree. As newcomer, it's a very useful document. Chris Wood: will help fill out
privacy section in the text.

Working Group hummed in support of adoption, no one in the room was opposed.
Chairs will confirm adoption on the mailing list.

## Unicast Service Discovery Autoconfiguration

Stuart Cheshire presented.
https://datatracker.ietf.org/meeting/103/materials/slides-103-dnssd-b2-cheshire-unicast-00
There were no questions.

David Schinazi: Please send the draft to the mailing list. Please read and
comment on list.

## DNS push notifications

Stuart Cheshire presented.
https://datatracker.ietf.org/meeting/103/materials/slides-103-dnssd-b3-cheshire-push-00
There were no questions.

David Schinazi: We did WGLC and didn't get a lot of comments. Please look at it
again. This is your last chance to comment. Comments now? *no comments*

## Service Registration Protocol for DNS-Based Service Discovery

Ted Lemon presented.
https://datatracker.ietf.org/meeting/103/materials/slides-103-dnssd-d-lemon-service-registration-00

Terry Manderson (AD): Would like to thank Ted and Stuart for work put into the
group. Please reach out to Ted and Stuart if you have cycles. Stuart Cheshire:
Thank Terry for support. Will be at the next Hackathon. Connect to coordinate
work. Barbara Stark: Yes, and we need people to review. How many people have
read? *a few hands raised* David and I will both be reading and providing
comments. Jake Holland: Are you referring to the privacy drafts? Barbara Stark:
Referring to all the drafts. David Schinazi: We need more people reviewing the
documents. Ted Lemon: Lots of activity on service registration in Montreal,
explains limited activity more recently.

## Privacy

### Shared public key proposal

Christian Huitema presented.
https://datatracker.ietf.org/meeting/103/materials/slides-103-dnssd-e-huitema-privacy-next-steps-00

Slide 5
Mikael Abrahamsson: Should we have more bits for timestamp?
Christian Huitema: OK, it does not change the principle.
Slide 6
Ted Lemon: Why base64 encode these? Why not just binary?
Christian Huitema: We could do that but it would be different from current
encodings. Ted Lemon: If you're putting one signature in a message you could
just use SIG0. Christian Huitema: Yes, do we want to keep DNS formatting or
not? Lots of pros to keep. David Schinazi: Do we lose sleep proxy support by
moving to binary messages? Stuart Cheshire: Thinking similar to Ted. We should
design it assuming we're not tied to existing format. Then figure out if we can
encode that in the DNS format since then we haven't compromised up front on the
design. Let's not get wrapped up in the encoding. Would be possible to extend
service registration for this use case. Ted Lemon: Worth preserving ability to
preserve infrastructure for doing service discovery. But supporting binary
labels isn't the end of the world. Stuart Cheshire: Might not work on some
servers if not base64 encoded. Christian Huitema: Acknowledged.

### Fully asymmetric proposal

Chris Wood presented.
https://datatracker.ietf.org/meeting/103/materials/slides-103-dnssd-f-wood-private-discovery-00

David Schinazi: Are there any specific questions about this proposal before we
try to compare the 2 proposals? *no questions*

### Discussion

Chris Wood: Think TLS is excessive for the given use case.
Christian Huitema: Yes, we can debate it.
Daniel Kaiser: Given that structure of new proposal, why do we need a new
draft? See email on mailing list. David Schinazi: Bob submitted to get the
conversation started. Our goal is to only publish one document. Daniel Kaiser:
Makes sense. Christian Huitema: There are parts I don't understand. How server
mode is handled. Chris Wood: Server does need to be online. I don't know how
Bob intends to reconcile that. Maybe Stuart knows? Stuart Cheshire: Bob's
proposal was not designed with "server mode" in mind. I agree with your
assessment. Christian Huitema: Can be reconciled. Stuart Cheshire: We will need
to make engineering tradeoffs. Christian Huitema: First tradeoff we need to
make is if we should support the server mode. David Schinazi: Clarify server
mode? Christian Huitema: Server pushes records into DNS and uses that to
respond. Mohit Sethi: Think last bullet is missing some details regarding side
channels. Christian Huitema: Possible to make implementation decisions to
mitigate them, e.g., randomize order of verification. Mohit Sethi:
Randomization is not useful when you have two friends. Christian Huitema: Use
case is people in the same room trying to discover one another without others
learning. Trying to hide the fact that time of searching reveals server. Mohit
Sethi: Sequential traversal of list will reveal some information. Dave Thaler:
Size of list might reveal information too. Christian Huitema: Yes, it's a
fingerprinting attack. Very hard to prevent. Chris Wood: Should consider this
attack out of scope. Stuart Cheshire: The perfect solution is impossible. It's
easy to come up with objections. But that's not a reason to give up. We can do
better than cleartext here. Mikael Abrahamsson: Sometimes both modes are
necessary if we can't address all use cases. David Schinazi: Want to focus on
the main use case for now. Christian Huitema: DH exchange produces a symmetric
key. David Schinazi: This reduces number of RTTs. Christian Huitema: Not really
concerned about that on the local network. Chris Wood: Can you clarify the main
use case? David Schinazi: Server mode would restrict the design and make things
more complicated. (Chair hat off: do not feel it's a compelling use case.) Does
anyone need to support the server mode use case? Stuart Cheshire: Do not
disagree. Server mode is important for lower power devices that are asleep. Do
those devices need privacy? Might have two overlapping circles on the venn
diagram? Christian Huitema: What about devices you have on your body? Stuart
Cheshire: Good point. Ted Lemon: What about the amount of multicast that is
consumed? Sending a lot of messages is not good. Christian Huitema: Both
proposals are multicast out and unicast in. Ted Lemon: Main advantage of DNS
server version is that it reduces multicast traffic. If reducing that traffic
is unnecessary, then perhaps not an issue. Mikael Abrahamsson: Do not see
imminent improvements for multicast on WiFi. We should try to limit multicast
messages sending since its costly for the receivers. Not sure about the amount
of multicast for proposals, but we should aim to keep it down. Stuart Cheshire:
Is the cost of multicast due to powering on the radio, or marginal cost on top
of that? Mikael Abrahamsson: It's that and air time. There's also reliability
to consider. In general case, multicast does not retransmit. Ted Lemon: Might
need for unicast message delivery service to help discover conduit? Christian
Huitema: Bob's discovery does discovery of DNSSD channel. Combinations of both
proposals is possible but requires some work. Making Bob's proposal work would
require the server to describe to the proxy a list of all clients and forward
proxy unicast messages based on the advertised nonces. Mikael Abrahamsson:
There's work in other WGs on low power devices. They have a lot of knowledge.
Daniel Kaiser: Should we switch to one or two stage approach? Should we support
both? David Schinazi: Not sure how per-app is related to one or two stage.
Christian Huitema: Could incrementally discover things in multiple stages.
Mohit Sethi: Stuart had a slide on scalability in Montreal. Stuart Cheshire:
Preference leans towards single stage approach. In most cases it's one service
you're discovering that may run other services. Dave Robin: Privacy gains are
minimal with current chatty device, it might be a good idea to have multiple
identities. Even if they currently share a MAC address. David Schinazi: Does
anyone disagree that we should move to a one-stage approach? No one spoke up in
support of having a two-stage discovery mechanism instead of the one-stage
approach. Ted Lemon: Devices can give time-window profile to indicate when they
are willing to talk to you. Mohit Sethi: Even if your devices synchronize. Low
power devices are hard to make secure. Chris Wood: Do we need to consider TLS
vs rolling your own crypto. Christian Huitema: This goes away with the one
stage approach. David Schinazi: Does this remove the need for TLS in the
protocol at all? Christian Huitema: Yes David Schinazi: Does anyone disagree
that we should remove TLS from the protocol? No one spoke up in favor of using
TLS in the protocol. David Schinazi: Stuart, can you check with Bob if this
addresses his use case. Stuart Cheshire: Yes. Barbara Stark: Chris can you add
an explanation of one stage vs two stage in minutes? Chris Wood: One stage:
Send encrypted and authenticated service identifier, get encrypted and
authenticated service response. Two stage: Send encryption and authenticated
identifier, get encrypted and authenticated response, derive secrets, initiate
subsequent queries encrypted using shared secrets. David Schinazi: Daniel, do
you want to present some of the Bloom filter points from your mailing list
post? via jabber, Daniel Kaiser said he had no microphone. David Schinazi:
Christian, can you please roll up what was agreed today into the privacy
document? Christian Huitema: Yes, as long as there is only one document. David
Schinazi: Absolutely, the WG should only publish one privacy solution document,
and that's the adopted one (draft-ietf-dnssd-privacy). Christian Huitema: Yes,
and I will ask Bob Bradley to be co-author. David Schinazi: Thank you everyone.
I think we have a way forward for privacy.

## Charter

Showed Github site with recharter discussion.
https://github.com/dnssd-wg
David: Use of GitHub issues is encouraged to facilitate discussion.