Session Date/Time: 08 Nov 2021 16:00

add Meeting Minutes

Summary

The "add" working group session covered updates and discussions on several key drafts related to the discovery of designated resolvers (DDR), network resolvers (DNR), and challenges with legacy forwarders and split-horizon DNS configurations. A core change to DDR regarding resolver verification was broadly accepted. The working group also discussed the potential adoption of two drafts: one on split-horizon DNS and another on deployment considerations for ADD protocols in home networks. Neither of these latter two drafts reached consensus for immediate adoption as standalone working group documents, with suggestions for further refinement or integration into other deliverables.

Key Discussion Points

Administrative and Note Well:
- A scribe volunteered to capture decisions and resolutions.
- An emphasis was placed on the IETF Note Well, reminding participants of anti-harassment policies and promoting respectful discussions.
- The svcd draft was removed from the agenda due to a lack of new material.
Discovery of Designated Resolvers (DDR) - draft-ietf-add-ddr:
- Draft 03 was published, aligning with dns svcb and allowing client flexibility in resolver verification.
- An editorial change from "authenticated mode" to "verified mode" was made for clarity.
- A primary issue regarding what is being verified was discussed:
  - The proposal to verify only the IP address (if starting with an IP) or the hostname (if starting with a hostname) in the certificate was generally accepted to simplify verification, treating it similar to a CNAME resolution.
  - Clarification was made that resolver.arpa should not be used as SNI or DOE authority if it was not the starting point.
- Significant discussion occurred on intermediate target names and their use in SNI/Host headers:
  - Concern was raised that allowing clients to use an intermediate target name (e.g., dns.google) when starting with an IP (e.g., 8.8.8.8) could lead to vulnerabilities like on-path attackers forcing different virtual host behaviors, and could violate HTTP semantics if the authority name is unverified.
  - The current inability of SNI to directly carry IP addresses was highlighted as a practical deployment challenge, though RFC 8738 (ACME IP identifier validation extension) was noted as a potential path for IP addresses in SNI.
  - There was a strong sentiment that, for simplicity and security, clients should stick to the original IP address when making connections for discovery initiated by an IP.
- The draft is expected to be ready for Working Group Last Call (WGLC) after addressing these points.
Discovery of Network Resolvers (DNR) - draft-ietf-add-dnr:
- Authors indicated the draft is ready for WGLC.
- The chairs expressed intent to hold off on DNR's WGLC until DDR's updates are complete, to ensure synchronization between the two documents.
Discovery of Designated Resolvers in Presence of Legacy Forwarders - draft-ietf-add-forwarder-ddr:
- This informational draft explores client policy for upgrading to encrypted DNS when behind legacy forwarders that cannot be upgraded, which affects a large number of internet users.
- The policy discussed removes the requirement for the IP address to appear in the certificate if the resolver is identified by a network-local IP (where authenticated security isn't otherwise possible).
- Discussion covered various security concerns (long-lived attacker responses, forensic logging) and compatibility impacts (split horizon, interposable domains), along with proposed mitigations (TTL caps, reputation, NXDOMAIN fallback).
- The draft aims to enable more DDR upgrades and increase encrypted DNS usage.
- There was significant interest in adopting this draft to continue discussion and find solutions for this common real-world deployment scenario, even while acknowledging its complexities and potential "harm reduction" nature rather than perfect security.
Split Horizon DNS Configuration - draft-ietf-add-split-horizon-dns-config:
- The draft now focuses on non-enterprise (e.g., mobile ISP) use cases, with improved support for geographic sub-domains.
- The proposed mechanism involves clients verifying network-provided domain ownership against public DNS resolvers to prevent typosquatting by malicious local networks.
- Concerns were raised about the mechanism for verifying private (internal-only) domains with public resolvers, and the potential for leaking private names.
- It was broadly acknowledged that split-horizon DNS is a real and difficult problem, but there was no clear consensus on whether this specific draft's solution was appropriate or ready for adoption in the "add" working group.
- Suggestions included focusing on the more challenging "dual-facing server" problem (public names with different internal resolutions), and leveraging DNSSEC for authentication to simplify the approach.
- The Area Director indicated that while the problem is relevant to "add," the draft's current abstract and content might not align perfectly with the working group's charter for immediate adoption as a standalone document.
Deployment Considerations for ADD Protocols in Home Networks - draft-ietf-add-deployment-considerations:
- This informational draft provides high-level architectures for ADD protocol deployment, particularly in managed/unmanaged home networks and with legacy routers. It covers scenarios for DNR, DDR, and ACME in this context.
- The authors found it useful during the development of DNR.
- The chairs suggested that this material could form a subset of a broader informational document already specified as a deliverable in the "add" charter.
- While some saw value in documenting these use cases as an informational reference, others expressed concerns about potential disagreements on specific details and whether it fully aligns with the "add" charter as a standalone document.
- The Area Director confirmed that, as it stands, the draft doesn't fit the charter for adoption but its content remains relevant and could be integrated into the charter's specified informational deliverable.

Decisions and Action Items

DDR Verification Logic: The working group generally agreed on modifying the DDR draft to simplify verification: if discovery starts with an IP, verify the IP in the certificate; if with a hostname, verify the hostname.
- Action Item: Tommy Pauly to update the DDR pull request to reflect this decision, specifically stating that the original IP address should be used for authority/SNI when starting discovery with an IP.
DNR Working Group Last Call (WGLC):
- Decision: DNR WGLC will be held off until DDR updates are complete to ensure synchronization.
Split Horizon DNS Configuration:
- Decision: The draft is not ready for adoption as a standalone working group document.
- Action Item: Discussion on this draft to continue on the mailing list. Chairs to consult with DNSOP and INT-AREA working group chairs regarding the appropriate venue and approach for this problem space.
Deployment Considerations for ADD Protocols in Home Networks:
- Decision: The draft will not be adopted as a standalone working group document in its current form due to charter fit.
- Action Item: Discussion to continue on the mailing list. Chairs will explore the possibility of incorporating relevant and useful material from this draft into the broader informational document deliverable specified in the "add" charter.

Next Steps

Tommy Pauly to submit the updated pull request for the DDR draft.
Chairs to monitor DDR progress and coordinate DNR's WGLC.
Chairs to gauge formal working group adoption interest for draft-ietf-add-forwarder-ddr via the mailing list.
Continued discussion on the "add" mailing list for the Split Horizon DNS Configuration and Deployment Considerations drafts.
Chairs to engage with DNSOP and INT-AREA working group leadership to determine the best path forward for the Split Horizon DNS Configuration problem space.
Chairs to explore avenues for integrating relevant content from the Deployment Considerations draft into the "add" working group's charter-defined informational document deliverable.