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.