Agenda ADD@IETF118 Meeting Materials, Links Materials, Charter, Documents ADD WG General Info ADD Chairs: David Lawrence, Glenn Deen Area Director: Eric Vyncke Note takers: Mike Bishop, Tim Wicinski Session link, minutes, jabber, materials Three new RFCs - 9461 through 9463, published 7 Nov 2 WLGC docs (Tiru Reddy) 2\.1 DNS Resolver Information 30m Handling WGLC feedback on DDR: * Adding `sig` attribute to RESINFO * Zero-trust security; cleartext between TLS termination and resolver * Resolver can lie about some attributes in RESINFO; multiple possible designs Tim: Run idnits on these documents Tommy Jensen: Nits are addressed Ben Schwartz: Not saying that RESINFO needs to be restricted; already is restricted this way. Authentication is wrong. Attributes that are purely troubleshooting don't need to be authenticated. `sig` provides no value here. RESOLUTION: Drop `sig` for now, analyze security, possible extension later Ben: Could RESINFO be in the Authority section? Ray Bellis: IANA template is not consistent. Suggests removing the Value Type column Tommy Pauly: Agree with dropping `sig`. When there is a name (initially or discovered), does that get us something better? Issue RESINFO query for the name and check the cert. Tommy Jensen: If you start with an IP address, the discovered name is not trustworthy. When the local attacker changes the name, the validation to IP address will succeed. Tommy P: For DDR, what matters is the address matching. But when the cert matches the trusted address and the untrusted name, can we issue another RESINFO query for that name? Tommy J: "Ish." Servers use different names based on different classes of service -- privacy, malware, etc. Answer may change based on domain name. Tommy P: Feels more like a functional recommendation if you run multiple sets of functionality. Chairs dispatch the topic to side-conversation. New WGLC expected after resolution. Tim W: That trust model is not clear in Section 3; needs clarification. BIND9 implementation of current spec available in December. 2\.2 Establishing Local DNS Authority in Validated Split-Horizon Environments 10m WGLC completed. few comments: * long-options in DHCP * wildcard subdomain * MTI hash algorithms from registry * internal domains * Ben will update section on DNSSEC Ready to submit to DNS Directorate; chairs will request early review from Security, Ops and INT directorates as well. 3 Draft Presentations 3\.1 Handling Encrypted DNS Server Redirection 15m Jensen/Todd/Mosher https://datatracker.ietf.org/doc/draft-jt-add-dns-server-redirection/ * Strict Origin mode: Redirections only within same trusted hostname * Recommends use of Delegated Credentials to validate same name without sharing private keys * Overlapping Origin Redirection: Server can have a new name, but cert must be authoritative for both names. * Clients should not support without prior configuration * IP Discovered DDR resolver: SOR requires IP identity; OOR not supported Ben S: Don't see appeal of OOR; doesn't provide security. Also doesn't seem necessary; defending against cache poisoning, and there are better ways to guard that. Tommy J: IETF should not be in the business of "Here's the way to do something insecurely" Ben S: Could also preconfigure scope of trusted redirects. Support adoption of EDSR in strict mode Mike Bishop: Point out similarities in trust model to alt-svc Tommy J: Redirection through a CDN chain. Mike B: After been somewhere with A and B, you can trust both A and B Tommy P: Discussion seems mature enough to adopt and solve as a WG document. Tommy J: Does anyone disagree with the scenario? That's the adoption blocker, if so. Ben S: Supportive of scenario; novel for DNS. Strict mode is fine; overlapping departs from our view of identity. Security seems okay, resolver could have forwarded queries. Raises questions about user expectations. Don't like solution, so I would be concerned about adoption. WG adoption call will go out; may remove mechanisms if the WG doesn't like them. 3\.2 Delegated Credentials to Host Encrypted DNS Forwarders on CPEs 15m + Q&A https://datatracker.ietf.org/doc/draft-reddy-add-delegated-credentials/ * Addressed comments from WG; added `delegated` SvcParamKey to indicate that only useful if client supports delegated credentials. Ben S: Worth moving forward; needs a new name. Needs to be reviewed by TLS WG. (Is this just a flag, or does it need particular parameters?) Tim W: SVCB is key-value; are flags allowed? (Yes.) Erik Nygren: Consider a "capabilities" list instead of a single flag. May need dnsop or TLS to do that, though. Authors will notify chairs when it's ready for adoption. Tommy J: Will implement this, support adoption when it's ready. 4 Hackathon Results 4\.1 The Little Pi that Could \[do DNR\], 5m Chris Box Pi as router, testing different DNR setups: * Directed to BT DoH server * DNSdist running on Pi, relaying to BT DoH server iOS and Windows both worked. ???: Certificate? (Issued by Let's Encrypt with public domain.) What about private domain with private CA? (If client trusts, which is generally just enterprise.) Tiru: We deployed subdomains for each CPE, then relayed CSRs to issue a certificate to each. Getting away from this was the motivation for using delegated credentials. Tommy P: Hackathon -- implementation was written on the plane here. Aditi: Do need to set a regkey to enable DNR in Windows. 5 AOB / Discussion (all) We've come so far -- we trust DHCP and we're not super-contentious! 6 Planning & Wrap up Probably another WGLC on the ResInfo changes. Poll for likely Brisbane attendance: 21 yes, 36 don't know, 13 no.