Skip to main content

Minutes IETF110: dprive
minutes-110-dprive-00

Meeting Minutes DNS PRIVate Exchange (dprive) WG
Date and time 2021-03-09 12:00
Title Minutes IETF110: dprive
State Active
Other versions plain text
Last updated 2021-03-09

minutes-110-dprive-00
# DNS Privacy Exchange (DPRIVE) WG
## IETF110

* Date: Tuesday 09 Mar 2021
* Time: 1200-1400 UTC
* MeetEcho: http://www.meetecho.com/ietf110/dprive/
* Minutes: https://codimd.ietf.org/notes-ietf-110-dprive

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

### Responsible Area Director
* Éric Vyncke evyncke@cisco.com

=======

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

## Agenda

### Administrivia

* Agenda Updates, etc,  10 min
* NOTE WELL : https://www.ietf.org/about/note-well.html

=======

### Current Working Group Business

*   DNS over QUIC
    - https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/
    - Authors, 20 minutes
    - Chairs Action: ?

    * Sara Dickinson:
        * 4y since first proposed DoQ. How time flies
        * Still some uncertainty on draft direction. orig draft only
        stub-to-recursive. is the proto needed? performance Qs &c. * (Sara
        reviews history of draft revs) * slide 5: review of implementations (if
        you want to see how many there are, types of contexts/OS) * claims from
        Adguard works better in mobile * DoQ looks analogous to DoT in
        discovery (an open question) * stream model needs mods to support XFR.
        slides 9-10 discuss the choices the WG has to make * summary, 3 Qs to
        WG. 1. head to spec 2. does it encompass recursive to auth.  3. if it
        does rec-to-auth how to handle XFR
    * Questions/Comments
        * Jan Včelák: nice if covered everything we need now. not sure, if
        covered every future case, think we need XFR now. mentioned problem is
        multiple messages, if server used DoQ, if it **needs** to send multiple
        answers: the limitation came from TCP, for QUIC we have different
        signalling, can use stream encoded, can send much larger responses for
        XFR so can maybe make it work with the simpler approach. OTOH thinking
        use cases like proxies. If change this, then proxies wouldn't work.
            * Sara: good point(s) included the 65k limit, same as DoH the
            principle of larger packet sizes came up, same issue with proxying
            and compat with other transports. updated in 01 version to
            packetsize, can revisit but we'd be rehashing the same argument
            from DoH. solves problems to keep the limit. * Jan then go with the
            2byte prefix. Sara proxying is another reason the solution proposed
            is good fit
         * Ben Schwartz: Vote for port 853 UDP. DNS over DTLS draft is
         experimental, minimally deployed, QUIC and DTLS are fully de-muxable,
         designed to share ports, think we should aim to have final port num
         when we have a standard be 853
             * Sara: was a conversation offlist, others can speak to port alloc
             better. Concern is that its a process barrier: it will slow it
             down. dedicated port for QUIC, doesnt make a huge amount of
             deployment difference (eg blocking) -was considered, want to hear
             other people. * **Brian** Take to the ML
         * Jim Reid: uncomfortable with bytecount prepend. smells like a layer
         violation. Advance a document, draw a ring around XFR, TBD, deal with
         it later. get on with the core job, basic protocol spec, deal with
         most common query/response deal with later
             * Sara: proxies, translation, do have to "special-case" for XFR,
             feels like a bit of a <mumble/> but if have to redefine later,
             different ALPN, want to fully assess if we can support in the
             current protocol. 2byte len is just framing answers within the
             stream otherwise a simple bytestream. really just additional
             compatibility. Have to have these discussions, which direction to
             take.
         * Watson Ladd: didn't understand adv and disadv. to doing this over
         853.
             * Sara: little bit of discussion last IETF. for recursive-to-auth,
             packaging whole HTTP layer around DNS queries. most recursive,
             auth, see that as uneccessary overhead on that path. Want the
             cleaner, lighter, pure QUIC mapping in this draft. If others
             remember differntly please say so.
         * David Schinazi: (ex Tech lead for QUIC in Chrome) not all UDP ports
         are equal getting over the internet. using 443, with ALPN demux, share
         service, would just work. Get the point about fighting an uphill
         battle with purists but may be the best deployment strategy
             * Sara: take onboard.

### Related Business

*   Oblivious DNS Over HTTPS
    - https://datatracker.ietf.org/doc/draft-pauly-dprive-oblivious-doh/
    - Authors, 20 minutes
    - Chairs Action: Call for adoption

    * Christopher Wood
        * Post Singapore IETF much work.
        * Discussion of goals of the proto, risk in collusive behaviour between
        the parties (can't be constrained formally AIUI) * slides 4-8: demo of
        the protocol entities, "how things work" * other ways to get to the
        outcome (eg using SOCKS) -ODOH aims to be "unlinkable" between discrete
        queries, noting it does a bunch more than the more general problem and
        allows the proxy NOT to become a general proxy (with all the risks) *
        deployment questions, (slide 10) things which really need to be talked
        out on the ML probably. The collusion risk is explicitly marked
        out-of-scope. * in use, in production. on cloudflare edge. "it's being
        dogfooded" -formal analysis being done (Tamarin) * "given interest in
        this protocol, investment, deployment: Is there interest in Adoption
        Experimental V1"
    * Questions/Comments
        * Paul Hoffman: reasonable experiment, but not WG work. take to
        independent submissions "not crazy, proof reasonable security concept"
        hesitant to take to this WG, Don't know how many users will understand
        the advantage "dont trust my immediate upstream to not collude"
        -especially when the best performance is they are the same
        organisation. Don't bring it in the WG, get published, let people bang
        on it
            * Chris: tricky to explain the privacy benefits.
        * Eric Orth: don't see the issue with explaining. Temp thing before new
        stuff, oblivious HTTPS, doesn't seem like full fledged, adopted
            * Chris: definitely not STDS track! but, use-case right now, want
            to continue experiment.
        * Tommy Pauly: echo Experimental appropriate. if WG doesn't want it, go
        direct to independent, or sponsored experimental, prefer to see it
        adopted as a quick processing thing for this WG to have the opportunity
        to reviews, give input on text. How to think about this area in general
        (future protocols) as implementor, planning having support for this,
        from Apple's side, reach a lot of users. provide benefit without deep
        understanding. Ask Chair, some kind of poll, best way to go forward.
            * Brian: can poll now, or repeat on the ML. Prefer to take
            Action-item poll adoption on ML, elaborate on 3 primary options
            assuming Exp: adopt, independent, or AD sponsored. (3rd requires
            chat with AD) * Tim: lets use the show-of-hands tool * Chris:
            comment in chat: discovery. Agree its open problem, hence
            out-of-scope. future spec can solve * Tim: can adopt, noodle, not
            proceed. Some people feel thats burning WG time. But, I think its
            useful

        * Watson Ladd: Stuck in RFC-ED. like whats on the slide, ODOH as
        experimental, bunch of +1s in the chat to Experimental * Ben Schwartz:
        said earlier support adopt, but heard change in context of discussion
        with authors noting deployment. this may not be a great fit for adopt,
        adoption means change control. need to think its right and reasonable
        to take a step back, what is really the right long-term solution here.
        how does this work in a world with DoQ, router architecture. Most
        interested in WG taking it on to design V2. let this version go out
        as-is from Authors
            * Chris: these are things we have to sort through, why I think
            experimental adoption in WG is the right thing. dont think we need
            to focus on V2, point of the exercise is to make sure we work out
            all the kinks in v1 in the experiment so in V2, easier time to get
            out the door
        * Ben: too late for non-breaking compat changes. get RFC number, move
        ahead, don't mess with it
            * Chris: open to handing over change control if thats whats needed.
            not seeking RFC num. want right way to shape the protocol. don't
            see an issue in that respect * Brian: do you want a doc which
            reflects current deployment or one which changes?
                * Chris: we expect the doc to change. by no means rigid with
                respect to whats in the doc, proto, crypto.
        * Ted Hardie: Cache semantics, what the experiment tells you. great
        deal of interest from proponents, relationship to rest of DNS, support
        experimental, but cautious to draw conclusions to broader use of HTTP.
        way caches work, HTTP vs DNS not always the same. concern that presume
        design for more limited MIME types, DNS cache mechanisms, harbinger of
        good result in HTTP. support going forward but be cautious what the
        results mean. Oblivious DOH will be divergent from Oblivious HTTP
        because of cache differences between two different arenas
            * Chris: there are subtle differences. can't lift ODOH results to
            DOH. hope is that we can use ODOH, divergence, delta very minimal
            not due to security, crypto changes, more the underlying technology
        * Tommy Pauly: scope difference is why interesting to pursue ODOH on
        its own now, that scope is more tractable in short-term. Change
        control, If adopted WG hs complete change control over proto. the doc
        is already designed to be versioned, has draft aligned version num,
        experience in QUIC. keep it up to date, aligned to WG. not a blocker *
        David Schinazi: job last year making google quic IETF quic. if we'd
        said "cant do <x/> its already deployed" we wouldn't have QUIC. we
        should do the exact same thing (process?) here. not a problem, its how
        we do it in this SDO. fully support doing it here, not a pushback
        reason, tis why its here. * Eric Orth: DNS is a specific case, Web used
        to "good samaritan" servers, could find an ecosystem for ODOH emerges.
        5 years down the line, nobody wants to run OHTTP at scale but run ODOH
        fine, still trying to make the ecosystem work for OHTTP.

    * Brian: Poll showed 23 interested in adopt, 13 not interested.
    Action-item: solicit ML Adoption as noted above.

### DNS Authoritative Encryption Discussion

* Scott Hollenbeck asks for comments to Requirements draft status
    * Brian: not getting enough feedback from WG. encourage people to bring
    topics to ML, to have discussion. Can't decide which of the two relevant
    drafts fix the problem (this is coments to DNS Auth Enc discussion) *
    Benno: "well. yes.. and no." more than happy to work with the WG on the
    requirements doc, incorperate discussion from IETF109 and ML. Would like to
    hear from WG how useful the document is. Happy to do the work, demonstrated
    need. Step back one:
        * "is this a useful doc, know the chairs, some individuals like, think
        its useful but, what does the WG at large think?"

    * **Action Item** - come up with set of recommendations for the authors

    * Paul Hoffman: we have two problems. Current requirements doc trying to
    "shoehorn" two things into one doc but clear from ML, some people care
    about one bit, some about another. Fine.. if the requirements doc can cover
    this, one or multiple solutions docs, can point to use-case doc. * Peter
    van Dijk: like having this document but 'requirements' is such a strong
    word. * Brian: other ways to think about this, but important discussion
    point for ML

*   Recursive to Authoritative DNS with Encryption
    - https://datatracker.ietf.org/doc/draft-ietf-dprive-opportunistic-adotq/
    - Authors, 45 minutes
    - Chairs Action: Facilitate new edits
    -

    * Peter van Dijk
        * working with paulH on the problem, adopted work
        * solves the DNS discovery problem, has comparisons of approaches,
        using TLSA or SVCB. has overview of the distinctions

*  Signaling Authoritative DNS Encryption
    - https://datatracker.ietf.org/doc/draft-rescorla-dprive-adox-latest/
    - Authors, 15min
    - Chairs Action:

    * Eric Rescorla
        * Talk about what we're trying to accomplish, what can, and cannot be
        done * (slide on threat models) * what needs to be encrypted? -both
        sides of traffic to parent and child, to prevent information leakage *
        discusses SVCB * Ben Schwartz: NS name insecure, even if DNSSEC sign,
        with SVCB could be an attacker, not received over a private channel *
        Paul Wouters: not about not wanting to serve SVCB. no mechanism yet,
        hard to get new records into the system eg trouble with CDNS CDS. its
        not "don't like it" the reality of operation of the DNS, registry
        system makes this hard. Can do SVCB at the child, for in-baliwick have
        no chance of privacy. * Jonathan Reed: don't like "can never do
        anything new in the parent" will lead to hacks we never intended.
        registry ecosystem so frozen, we can't do this, lets say this in DNSOP.
        everything new in the parent has to work in the child but "we can never
        change the parent" we have to get past this. interim methods until we
        get what we want in the parent. This is a non-starter * Jim Reid:
        provisioning in the parent, one problem. zone cut semantics issues,
        DNSSEC deployment, implementation concerns, for people writing
        resolvers. * "Its TLS all the way down" * three contentious issues DANE
        vs WebPKI DoT vs DoH why not both? SVCB is flexible.

    * Brian: we have 25 min for discussion over both drafts, what the WG wants
    to do, how to move forward.
        * Kirsty Paine: to clarify.. "how security works" slide. some "if"
        qualified statements. the properties are different, can't bundle them
        together. Another slide, discussing the thread model including some
        attack models and not others. Q: how do you make the value judgement
        and what is the thread model if not here, and what do you lose by not
        considering it here.
            * Eric: to take the second Q first. Its a weaker attacker issue,
            concrete example argue need recur-parent and recur-child. So,
            depending where attacker is, on which path, then.. alters what you
            need to do. Absolutely right, DNSSEC/TLS apply different values
            here. This is part of the confusion of "what are you trying to
            achieve" -not attempting to provide integrity for any records
            except the ones needed to get TLS. So, ignore all the other stuff,
            but for authenticating the NS and SVCB, roughly equivalent
        * Ben Schwartz: to the first draft of the two, what we had, before, was
        a way for auth servers to get some traffic, without guaranteeing
        uptime. the current draft makes the choice auth or non-auth choice of
        the requestor. no safe way to deploy a new protocol before given its
        full SLA. Point 2: requirements drafting is hard. do we need to figure
        out to require, or not require changes to EPP spec and ICANN registry
        agreements? Puzzle. Point 3: there is a path forward here blending
        ideas. Roughly, looks like use DS-hack, to encode just the flag that
        the child "plays the new game" then go ask the child for SVCB rec to
        find what to do, costs latency but only for the zones which opt in.
        Then eventually we get out of the latency by putting SVCB recs in the
        parent, and having the parents also do TLS or zoneMD digest. (root)
        only works for out-of-baliwick NS. can start getting protected
        now/soon, but can remove performance cost to make it more attractive.
            * Paul H: Ben, thank you, yes. incremental is important. On the
            general point adding recs to additional in parent. think thats
            going to be a real issue. on the "opportunistic" side don't care
            how it comes out, DS or whatever to be clear, adding anything to
            the additional takes contracts and updated s/w and auth s/w won't
            add willy-nilly to the additional. Said in chat, if the way we WANT
            then go there, don't be "oh its impossible" this is important
            encryption don't give up now. Since we do have 1 WG doc now,
            slammed one idea of fully auth in. EKR has a more full explanation
            including use-case, happy to split it out again. Up to chairs,
            Recommendation is, work on these two in parallel, not jam into one
            document. However the WG wants to go is fine.
        * Daniel Gillmor: Want to follow up on Ben, Paul "how to get to
        deployment phase" if signalling is a hard fail thats a problem. If its
        not a boolean, (and dont think it should be) then need to think what
        the intermediate state is. report-only state, requires reporting
        format, mechanism, to learn when failures. See this in other
        situations. Glossed over that in these, significant amount of
        engineering work. * Puneet Sood: from google pDNS, agree with DKG. need
        transitional support, partial, opportunistic * Robert Evans: Google,
        tech lead cloud DNS, so for the auth server interest. EKRs proposal
        interesting, focussed on the authenticated case, number of paths to
        security, incremental adoption of SVCB provides a road to security. If
        the elements, the TLS cert checks out, and the NS set is validatable,
        and a secure signal in SVCB you have a secure path. Could begin with
        DoH or DO53 query for SVCB. over time, paths, DS record with format or
        parent SVCB, adopted, then increases security. Can have fully secure
        from integrity PoV SVCB today, without parents as long as there are
        DNSSEC sigs for the SVCB and (missed) * Jim Reid: concerned we've moved
        to solutions, prematurely, Not sure risk/threat analysis has been done.
        we're jumping ahead.
   * Brian: think this goes to ML discussion:
       * Jim some stuff in other drafts not well aligned to things discussed
       today * Paul H: reporting mechanism, Auth server,
       https://datatracker.ietf.org/doc/draft-arends-dns-error-reporting/
       discussed in DNSOP, will be of interest, for general reporting recursive
       to auth. could be used here as well. not concerned about absence of
       reporting mechanism dont think we need our own, generalised mechanism
       can be assumed * Christopher Wood: Jim, nail down threat model, auth
       server, figure out what it is, what are viable solutions within that
       threat model * EKR: agree threat model important. try to lay out in our
       document. Lets try to get to agreement. Don't know what else needs to be
       don in the threat model. somebody else can weigh in * Brian: want the ML
       to agree to the model laid out, or say what they want to change. * Ben:
       agree with threat model on EKRs first slide. Aspiration is "solve the
       whole thing" going to produce some solutions which solve only part of
       it, weaker threat models EKR mentioned maybe

   * Tim:
       * recomm for authors on requirements doc (Scott)
       * more interest in OHTTP work. adopt or not (call to ML)
       * work with peter/paul new edits for Opportunistic draft
           * Paul H: Q for next-step where do requirements get specified? could
           be unauth draft talking reqts, and fully auth draft talk about
           theirs, or they go into a single doc, worst-case is 3 docs talking
           about it. Chairs to figure out. Speaking for Peter happy to throw
           ours out to the doc, but it hasn't been worked on. Better to have
           them in the fully auth doc.
               * Tim: Brian and I were not sure it would ever get published, WG
               doc status, have to take this back. need WG feedback.
   * Brian: adopt EKRs document?
       * Eric: fine with that but also fine with it not being done right away.
       Want to move how we're moving forward, not want 9 years workshopping
       requirements, want to get to solutions. If people think the Reqts laid
       out roughly suitable, solition roughly suitable, then move forward with
       that
           * Tim:agree nobody wants to workshop requirements forever.

   * Brian: AOB? three.. two.. one..
       * Tim and I will go back,  how to drive requirements, other Action-items
       kicked off.