Administrative

• chair slides
• Agenda bashing: none

Documents

4.1 WG Doc Status

Handling Encrypted DNS Server Redirection

• there has'nt been recent changes recently, what do we do
• Tommy Jensen: Updated recently (yesterday)
  • there are some outstanding changes that need to be dealt with
    after working through edge cases (change redirects, etc)
  • want to see the non-happy paths tested before going to WGLC
  • ideally that should be complete by next update
  • hopefully before december-ish timeframe
  • would love to have other implementations
  • otherwise have the feedback we need

4.2 New I-Ds

Multicast DNS-Based Service Discovery for Encrypted DNS Services

• draft-liu-add-dnssd-edns-00

• slides

  • introduces new service types for _dot._tcp, _doh._tcp,
    _doh._tcp

• Steward Chesire:

  • thinks this is a good idea
  • there are services that need discovering
  • potentially better than adding options to DHCP
  • not sure you "multicast" in the title and document
  • should work with unicast service discovery
  • airprint is a worked example of how to add records to your local
    service for adding it

• Chris Box:

  • Why would a client be interested in using an encrypted service
    that appeared on the network?
  • This gets around RA guard and anyone can send their own access
    points
  • What's the use case that makes this of interest?
  • answer: this draft is complimentary to the existing approach and
    works without infrastructure, eg for temporary disaster recovery
    and in this case dnssd can be used instead. Or in military
    networks. This is different than DHCP-RA.
  • Stuart: similar guards exist for DHCP or other starbuck's
    services prevent official services from being advertised, and
    this could be done similar
  • Éric: starbucks actually did this to reduce traffic not for
    security (aledgegly)

• Éric:

  • why are you using TXT instead of SVCB as in RFC 9462
  • Response: because it's in the standard DNSSD records

• tommy Jensen:

  • makes sense on paper
  • unlike printers, which is user facing, DNS is something that
    users shuold never know exists
  • multicast discovery is things that are available here and not
    something necessarily automated
  • disaster recovery sounds different in scope and may need to be
    solved differently

• Michel François:

  • 9563 uses SVCB and SVPARAMS and since this accomplishes the same
    job.
  • May want to use the same semantics.
  • No objections for using SVCB with mDNS, it's just not done yet
    -- but it could be
  • also, may not want to use EDNS acronym here as an acronym
    because EDNS is already an acronym for extended

• Lorenzo:

  • this seems harmful for someone coming into a network and
    potentially advertising services
  • you might as well broadcast the information, but that doesn't
    mean you should trust it
  • DHCP is already easy to set up and configure

• Tommy Pauly:

  • echo what a lot of people said
  • DNR and DDR already do many of these cases
  • this should be handled with certificate handling
  • why would you trust this?
  • if you had a UI for selecting it then maybe that would be
    better, but users would still need to know how to make
    selections
  • need a way to designate something as a legitimate network
    service
  • this would all require client modifications anyway, so they
    could just have a list of public infrastructure that could be
    used as a backup
  • agree we want to reuse encoding for SVCB
  • there is a draft for how to use SVCB in a draft already

• Jim Reid:

  • interesting but it's not clear what problem you're solving
  • use cases need to be clarified
  • need to move away from txt records
  • requires sorting through lots of records for the right one

• chairs:

  • make changes to the draft based on comments
  • then discuss on list for future feedback

• Tommy Pauly:

  • would be good to establish motivation first because no one seems
    to agree with the motivations
  • instead we should have a list discussion to determine the
    motivation behind the draft
  • then we can determine which mechansim (eg DNSSD) is the right
    one to use

• Chairs:

  • the authors should try to better describe the problem space too

PPP IPCP Extensions for Encrypted DNS Server Negotiation

• draft-liu-add-ppp-edns-negotiation-00
• slides

• Tommy Jensen:

  • Draft says reason to extend ppp is isps can force clients to use
    their encrypted dns service
  • is the intent here to restrict clients from using other secure
    edns services?
  • this was in the draft's introduction but not in the presentation
  • author's admit that this was a goal

• Tommy Pauly:

  • Don't think the PPP layer doesn't technically enforce that goal

• Tobias:

  • echo the concerns
  • can't be technically confirmed either

• Lorenzo:

  • why doesn't ipv6 options use the same options with RA?
  • authors: we were considering an option talking about IPv6

• Authors:

  • the goal of both drafts is to cover network acquesion to
    deployment

• Jim Reed:

  • these need both to be reviewed by DNSDIR
  • might as well get these there now

• Wes Hardaker:

  • don't think we should throw to the dnsdir since its not an
    official document

• Jim Reed:

  • all documents are treated equally
  • "na na nah na nah"

• Tommy Jensen:

  • second draft does belong here
  • the technical mechanim itself does belong here
  • as written the motivation as written is incorrect and shouldn't
    guide implementations

• Chairs:

  • substantial comments were made
  • suggest updating it and bringing it back to the list to discuss
    further
  • incorperate changes and resubmit to the list

• Authors:

  • thanks for the comments here today

wrap up

• AD Eric:

  • was planning on closing the working group once the work was
    completed
  • but it may be that more work is coming?
  • We'll leave the group open for a bit to determine whether or not

• Tommy Pauly:

  • seems like only the PPP case remains in scope
  • but it could be in intarea too
  • if here, we need expertise from people in ppp
  • otherwise we could do most of this on the list if there wasn't a
    need for face-to-face time
  • we'll always have some new provisioning mechanism that will need
    new work

• AD:

  • suggest we keep it open at the moment

• Lorenzo:

  • does anyone use DDR in production?
  • SVCB records don't survive well in the wild
  • may be middle box issues?
  • room seems to indicate it does work

• Chairs:

  • Joking: ADD should go to ops now???
  • in our charter was an operations document

• Tommy Jensen:

  • the first draft makes sense that it could be here

• AD:

  • better to make them here because that's where the knowledge is
  • dnssd people are here/there

• Wes Hardaker:

  • I'm collecting feedback this week on DNS in the IETF and what to
    do structurally
  • Come see me or comment on the discussion list about this sort of
    topic if you have opinions

• Tommy Pauly:

  • not convienced this is the right venue
  • bleaching questions

• Chairs/Dean:

  • if bleaching is a problem, where should that be worked on?

• Tommy P:

  • for cases where the local network is picking/blocking services
    then where do we have that discussion?
  • if you're not getting to the service you wanted to get to,
    including other SVCB content, then ...

• Eric:

  • let's measure the problem space first