Minutes IETF109: dprive
minutes-109-dprive-00

Meeting Minutes DNS PRIVate Exchange (dprive) WG
Title Minutes IETF109: dprive
State Active
Other versions markdown
Last updated 2020-11-23

Meeting Minutes
minutes-109-dprive

# DNS Privacy Exchange (DPRIVE) WG
IETF109
Date: Friday 20 Nov 2020
Time: 0900-1100 UTC
MeetEcho: http://www.meetecho.com/ietf109/dprive/
Minutes: https://codimd.ietf.org/notes-ietf-109-dprive

Chairs
* Tim Wicinski tjw.ietf@gmail.com
* Brian Haberman brian@innovationslab.net

Responsible Area Director
* Eric Vyncke evyncke@cisco.com

DataTracker
https://datatracker.ietf.org/group/dprive/documents/

## Administrivia
* Slides:
https://datatracker.ietf.org/meeting/109/materials/slides-109-dprive-dprive-chair-slides-00
* Agenda Updates, etc, 10 min
    * Paul Hoffman: Hopes that last section about Phase 2 will talk about
    larger issues that have been discussed on the list as well
* NOTE WELL : https://www.ietf.org/about/note-well.html

## Current Working Group Business

### DNS Zone Transfer-over-TLS

https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/
Slides:
https://datatracker.ietf.org/meeting/109/materials/slides-109-dprive-zone-transfer-over-dot-00
GitHub repo: https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls
Presenter: Sara Dickinson Chairs Action: closer to WGLC?

* Sara requests that people indicate in the chat if they have read this -03
version by typing "+1" * Sara ends with a request for reviews.

* Alex Mayrhofer - how do you want reviews?
    * Sara - open to either email or GitHub issues. Slight preference for email.
    * Brian - Is the GitHub repo set up to reflect back to the list?
    * Tim - No, it's not. Please send all big issues to the email list.
    Editorial comments to GitHub are fine.
* Puneet Sood - Should we say that XFR should be on a different port?
    * Sara - Does not see that as necessary at this time.
* Tim - Please send feedback to list. Sees this as close to WGLC but would like
final comments.
    * Jim Reid - are you going to set a deadline for review comments?
    * Tim - Yes. We should be looking at WGLC by the end of the year.

### DNS over QUIC

https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/
Slides:
https://datatracker.ietf.org/meeting/109/materials/slides-109-dprive-dns-over-quic-update-00
Presenter: Christian Huitema Chairs Action: ?

* Christian notes that the QUIC protocol is now in WGLC and on the path to
publishing. With that, this draft becomes more relevant. The draft has not
changed in some time. He would like feedback from the group as to whether there
is interest in this work. * Christian asks:
    * How much interest is there for DoQ from stub to recursive?
        * Do we know of prototype deployments?
    * Should we study DoQ for recursive to authoritative?

* Peter van Dijk - You say that several implementations are available, but
there is no "Implementation" section in the draft. Info should be added.
    * Christian - Thanks. We'll add that.

* Ben Schwartz - Agrees that DoQ is interesting for recursive to authoritative.
He thinks this draft is worth pursuing.

* Daniel Kahn Gillmor - Can you speak about your server resources claim? Do you
have data showing fewer resources for tracking DoQ state vs DoT state?
    * Christian - Doesn't have specific measurement for DoQ. Measurement on H3
    is that he can manage 50,000 connections on a single server. Overhead of
    handliing connections is not very high.

* Paul Hoffman - answering questions in chat about whether this is raw DNS over
QUIC or DNS over HTTP/3. This work is intended to be focused on raw DNS over
QUIC, and he hopes it stays that way.

* James Gressing - Need a public benchmark for doing DoQ versus DNS over HTTP/3
to understand if this draft should be expanded.
    * Christian - Agrees with Paul Hoffman that introducing HTTP/3 adds an
    unnecessary layer.

* Wes Hardaker - Is torn because he can see DoQ giving benefits, but notes that
IETF has historically had challenges deploying protocols over multiple
transports. We are at the point now to have DNS over 3 secure transports (DoH,
DoT, DoQ) without a clear reason to pick them. Concerned that deployment will
wind up seeing one of these paths dominating, and the others fading away. Wants
to have DoQ on the table, but concerned about the complexity of DNS
implementations, and wasting time of implementors on developing code that
ultimately doesn't get used.

* Ben Schwartz - Would like a little more thought in the draft about the AXFR
use case.
    * Christian - That was out of scope when we started this draft.
    * Ben - With DPRIVE recharter, this is now in scope.
* Ben - Thinks there are use cases where DoQ will not suffice and where DoH3
will be needed. Gives use case of NextDNS.

* Christian to chairs - what next?  He's heard two suggestions:
    * Add Implementation section
    * Add AFXR use case
* Brian - encourages adding implementation, and then waiting on AXFR for
discussion through Phase 2 requirements.

### Phase 2 Requirements

https://datatracker.ietf.org/doc/draft-ietf-dprive-phase2-requirements/
Slides:
https://datatracker.ietf.org/meeting/109/materials/slides-109-dprive-phase-2-requirements-discussion-slides-00
Working Group, time remaining Chairs Action: Facilitate new edits

* Tim - There has been a great amount of discussion in the mailing list,
particularly around opportunistic connections. Is there any discussion on that?
    * Paul Hoffman - Does not see opportunistic as being in competition with
    other approaches. * Peter van Dijk - Agrees with Paul that there is no
    competition. We should pursue both approaches. * Sara Dickinson - Is it
    written down anywhere what we mean by whole authentication?
        * Tim - I don't think it's written down and that may be an issue.
        * Paul Hoffman - No, it's not. It's based on assumptions.
        * Pete van Dijk - the bin draft ...  In the context of the TLSA drafts,
        Sara's question is very valid.
    * dkg - Three use cases - Do we want to cover them all?
        * Probing opportunistic transport
        * Signaled opportunistic transport
        * Signal that server should expect encrypted transport (DNS equivalent
        of STS) "Signaled strict mode"
    * dkg - other axes that we need to consider:
        * signalling mechanism (how is it announced?)
        * signalling scope (e.g. signal applies to zone, to named NS, to NS IP)
    * Sara - Agrees with DKG on use cases. Ideally would like to only deal with
    two, but acknowledges there may be more. Notes that servers may need to
    signal back to clients with error codes. * Ben - Thinks there are
    inherently MANY different and complex conditions here. Multiple axes.
    Suggests we charge ahead with prototyping.

* Brian - ordered discussion of requirements based on his view of what he was
seeiing on the mailing lists. * Suggests we have an interim in January and
February to progress this work.

#### Requirement 7
>The authoritative domain owner or their administrator MUST have the option
to specify their secure transport preferences (e.g. what specific protocols are
supported). This SHALL include a method to publish a list of secure transport
protocols (e.g. DoH, DoT and other future protocols not yet developed). In
addition this SHALL include whether a secure transport protocol MUST always be
used (non-downgradable) or whether a secure transport protocol MAY be used on
an opportunistic (not strict) basis in recognition that some servers for a
domain might use a secure transport protocol and others might not.

* Ben Schwartz - He has a draft proposal (and there are others) on "Service
Binding for DNS" in ADD WG related to this. His draft is at:
    * https://tools.ietf.org/html/draft-schwartz-svcb-dns-01
* Paul Hoffman - Making servers demand authentication seems over-the-top. Would
like the latter part to be more of a MIGHT versus a hard requirement. * Peter
van Dijk - Concerned that there is a separation issue between DPRIVE and ADD.
Is not following the work there, and was not aware this was an area of work. *
dkg - Responding to Paul that strict mode is available in other protocols.
Mentions HSTS, and MTA-STS. "I guarantee you secure transport is available. You
should use it. If you can see this message, you must connect overs secure
transport." * Ralf Weber - DNS is more complex than HTTP. Harder for components
to determine what to do. Often more important for an operator to give an answer
than to not give an answer. * Peter Koch (in chat) - on req 7: instead of
saying which entity should be able to specify (the 'owner' or 'holder' is more
a registry side concept) it might make sense to make this a property of either
the zone or the authoritative server (likely the former) * Duane Wessels -
Wants to be clear we are talking about *zones* signaling their preferences
versus *servers* signaling their preferences. * Ben Schwartz - Thinks many of
these requirements are too detailed and too strict and is not sure he'd want to
implement them. For example doesn't think that signaling a non-strict
connection in in Requirement 7 is important. Also gives example from
Requirement 9. * dkg - Agrees with Ben that these requirements seem a bit
strange. Again points to requirement 9 and asks why we care? Asks about
requirement 7 and signaling. He sees multiple mechanisms. Have we collectively
settled on a specific mechanism? * Alex Mayrhofer - Agree to what Daniel said,
it's important to make a designation of whether the focus is per-zone,
per-nameserver-name, per-ip-address, and the existing requirements are a vague
interpretation that it's not per nameserver. * Peter van Dijk - Requirement 9
is a mistake. It should just go. As to signaling mechanism in Req 7, not sure
we can discuss that today. * Sara - * Tim - Asks about dkg noting he wants 2
cases * dkg - Sees now two cases:
    * Opportunistic with probing
    * Strict mode
* dkg - Signaling is hard and there is a good bit of work to do. Thinks we will
need signaling. But for right now should focus on probing and strict. * Ben -
Would like to see an experimental draft that explains in great detail
opportunistic by probing on port 853. * Paul - Thinks people are using
"opportunistic" incorrectly. You try to authenticate, but then continue if you
don't. Can't imagine that probing by port number is something people are going
to want to do. Thinks TLSA records may work better. Thinks that transport paths
are most important for both opportunistic and strict. Going back to Sara's
question earlier, what do people who fail to authenticate do? We need detail
about use cases and how things will fail. * Alex Mayhofer - What if last
authenticated server fails? Does resolver go back to unencrypted server? Do we
identify dimensions? Do a hackathon to identify issues? Do both?

* Brian notes that Req 2 and Req 3 directly relate to whether we are scoping
this "per zone" or "per server". Our decision will impact those. * Tim - yes,
we'll need to make this decision.

* Paul Hoffman - Draft authors started a year ago with very different
assumptions. Let the authors take a look at what has been discussed and adjust
the draft. * Sara - Notes that several of the solutions have a requirement on
DNSSEC. We need to be care to be sure that we want that coupling. That's
another requirement that may feedback on here. * Peter van Dijk - Agrees with
Sara that we need to be careful about coupling. * Wes Hardaker - We have one
example of this working well. Start with RFC7672 - strict secure SMTP falling
back to opportunistic secure SMTP falling back to insecure SMTP. * Paul Hoffman
- Notes that in those secure SMTP solutions, many SMTP servers are getting
certs from CAs versus DNS. May be something considered here for secure DNS. *
Ben Schwartz - Agrees with Paul that we should be open-minded about different
roots of trust. There are people in this ecosystem who won't touch CAs with a
10-foot pole, while others won't touch DNSSEC with a 10-foot pole. We need to
get them all working together. Authentication is only interesting if you will
terminate the connection and not deliver the query IF the authentication fails.
* Paul Hoffman - Has now been convinced by mailing list conversation to be more
open about authentication scenarios.

* Brian - It seems that we have a set of requirements in the document that are
obsolete or have gone by the wayside.  Shall we instead focus on how to look at
a different set of requirements? * Tim - As we hear all of this, I think we do
need to step back and rethink what we are doing between recursive to
authoritative?

* Puneet Sood - Whether the transport secure is really a server problem. Strict
is a property of the zone. We don't have much secure transport at all right
now. To jump to all strict is premature. * Ben Schwartz - If the server signals
it has a reliable connection, if the resolver receives insecure info, it should
think of it as an attack. * Peter van Dijk - (agrees with Ben) * Puneet -
Scalability is an issue.

* Ray Bellis (in chat) - per-server flags advertise capability, per-zone flags
indicate policy

* Tim - are people willing to lead some work on scenarios?
* Paul Hoffman - has provided some drafts to the list. Very open to seeing
other people submit other drafts.

* Alex Mayrhofer - clarified that when he said "on paper", he didn't mean we
shouldn't write code, but rather that some scenarios could be figured out in
text.

* Sara - Different topic. Threat model in requirements has two cases. Third
case is zone owners who are interested in privacy and trying to defeat
enumeration. They may also be interested in encryption to prevent passive
monitoring.
    * Paul Hoffman (in chat) -  same on the resolver side. Some resolver ops
    would be happy to not have passive observers "enumerate" what their clients
    are doing.

* Brian - Timing will be tight before IETF 110 in the beginning of March, but
there should be room for interim meetings.

Meeting finished.