Minutes IETF120: add: Thu 22:00
minutes-120-add-202407252200-00

Agenda ADD@IETF120

Meeting Materials, Links
Materials, Charter, Documents
ADD WG General Info
ADD Chairs: David Lawrence, Glenn Deen
Area Director: Eric Vyncke
Session link, minutes, jabber, materials
Meetecho Link
Meeting Minutes
Meeting Chat
Materials
Session times
Time: Thursday 15:00-16:30 Local (PDT) time
Agenda

1. Administration [10 min]

   • IETF NOTE WELL
   • Scribe selection
   • Agenda bash
   • Welcome from chairs
   • AD Comments

2. Announcements from Chairs

3. Document status

   1. IETF LCs
   2. ADD WG LCs
   3. ADD Adoption Calls

4. Docs

   1. WG Doc - Handling Encrypted DNS Server Redirection 15m (Tommy
      Jensen)
      EDSR Adopted
      draft-ietf-add-encrypted-dns-server-redirection - needs comments

Glenn: We have "Do Not Resuscitate", "Dance Dance Revolution" -- What
does EDSR stand for?
Tommy: "DNR" is your fault.
Ben: Check Chrome in the Interop Hackathon - it already implements a
variant of this behavior.

1. Architectural Directions Discussion

   1. Related work in other WGs [10 min] (Tommy Jensen)

      • Client Auth Recommendations for Encrypted DNS
      • Updating RFC 7050 to include DNR + (DoT, DoH, DoQ) as the
        preferred secure channel to DNS64 servers
        • These are being covered in DNSOP, not in this WG.
        • Lorenzo Colitti: RFC 7050 doesn't say that the server
          "SHOULD" be trusted. Doing 7050 with this seems pretty
          silly so maybe we can leave it alone. It doesn't say
          what constitutes trust.
        • Tommy: I'm not sure we can just leave it alone, given my
          reading of the requirements.

   2. Encrypted DNS & CPE Devices [20 min + open discussion] (Dan
      Wing)

      • Tobias Fiebig: The ACME/CA way with a domain per CPE would
        be the most technically sensible, but I understand the
        problem. I wonder if TLSA would be an appropriate solution.
        The ISP could handle TLSA registration for the devices, and
        the problem would be solved in a local way.
      • Eric Vyncke: As responsible AD, it looks like we are talking
        about a normal TLS server and not only a DNS
        server/forwarder in ADD. This is out of charter.
      • Dan: We need to solve this problem for ADD.
      • Eric: Let's at least keep focused just on the DNS
        forwarders. Otherwise it's completely outside of the scope
        of ADD.
      • Glenn: Question from the chairs: if we focus only on the DNS
        function on the ADD, is that in scope?
      • Eric: We can maybe push it into ADD if we focus only on the
        DNS forwarders, but otherwise it should go in a separate
        working group or somewhere else and be more useful
      • Glenn: It seems like discovering TLS is necessary for the
        DNS problem.
      • Eric: I would say "maybe" it's in the charter, but I would
        like to explore that outside of this working group first.
        Maybe in ACME.
      • Q Misell: I think you've correctly identified the problem
        that TLS is tied to a CA. There is work to not tied to a CA,
        but for now it is. ACME is probably the best way we
        currently have to do this. I don't think we should come up
        with a DNS-specific way. There is definitely a problem for
        TLS certificates for devices on a private/home network, but
        this is not the place for that. Maybe it's ACME. If the CPE
        runs a CA, then maybe it can also run an ACME server for the
        home network? We can take off the TLS bit and shove it off
        to ACME, and ACME can figure it out.
      • Ben: To Tobias: use of TLSA here would be the DANISH
        architecture. I think the right answer here requires deeper
        thought, and possibly going to the W3C and finding a new URI
        scheme instead of "https" to represent local network
        devices.
      • Erik Nygren: I agree that this is a problem worth solving,
        probably in a new working group. To what Ben says, it's not
        clear that the CA model makes sense here. Martin Thomson's
        model, using the hostname tied to the certificate, is a path
        worth exploring, but that would need to be explored in the
        context of a new working group that explored the
        requirements for this.
      • Tobias Fiebig: If we scope this to DNS, that carries the
        question of how relevant it actually is. Geoff Huston shows
        heavy usage of 8.8.8.8, 9.9.9.9, 1.1.1.1, so does the ISP
        really need local resolvers on the CPE? My ISP is sending
        many users to large central IPv4 anycast resolvers.
      • Glenn: There are many variants of how people deploy this at
        the ISP level. There probably are people, and there have
        been people who came forward to say that they do need this.
      • Tommy Jensen: The home for this doesn't need to be here, but
        we clearly all care a lot about this. I didn't see Delegated
        Credentials in the list of options. If you care about a
        service that only works when the box is online, why not use
        DC instead of STAR? If this were a BoF I would definitely
        help, attend, review, etc.
      • Dan: Our previous draft focused on delegated credentials,
        but this one replaced that one based on feedback we got.
      • Syd Alam: I support this, thank you for bringing it up.

2. AOB / Discussion (all)

3. Planning & Wrap up

A cry of disbelief