Session 2 Agenda

Discussion began with Glenn discussing the coffee kicking in.

Welcome

• NOTE WELL
• Scribe selection (Eliot)
• Agenda bashing
• Chairs & AD Comments

New AD: Éric Vyncke said a very quick "hi", and thanked Barry for helping in the formation and oversight of the WG.

There was the threat of one of the chairs breaking "into tune". We then got a history of Dave's HS musicals (Oklahoma, Mame, ...).

Continued discussion from Session 1

DNR Discussion continued

Mo continued presenting (Slide 2). There were two different flows: with and without DNSSEC.
Some confusion was expressed in the Jabber room on this slide.

{"Tommy" below is Tommy Pauly}

Tommy: why should DNSSEC matter? If we have the name then we can do a secure upgrade, apart from a DoS.
Mo: If DNSSEC is not supported, then someone can redirect you to a fake server.
Tommy: If I have the name from DHCP and I am trusting DHCP more than DNS, unless the name is fundamentally compromised...
Mo: The scenario is where the DNS is spoofed with parameters that the client does not support; and it becomes a DoS.
Tommy: there are many ways to do a DoS.
Mo: This avoids the case where the DoS isn't detected.
Tommy: As a client, if I received information in which I failed to connect, I would treat it as an attack; and we should mandate that.
EKR: The assumption is that whatever you got in this message was authentic. Server has no way of knowing the client capabilities. Server has to provide client something it can accept.
Mo: The server doesn't need to be aware of the capabilities of the client.
EKR: Just have one version, for when the client doesn't support DNSSEC. Do you believe the security properties of these two arms are the same?
Mo: Yes
EKR: then let's just have the second arm.
Mo: Proposal could just stick to the later.
EKR: We are adding tiny little pieces in SVCB into this proposal. Let's bring all of SVCB into this work. If it's too big, use a digest.
tale: Yes Tiru and Med, please give this serious consideration
Ralf Weber: initial draft was simple. Agrees DHCP should be like that. But what we're doing now is creating a circular dependency. Better to stick this information into DHCP.
Ben Schwartz: What happens if you are a DoH-only client, and your network hands you a resolver that says "this resolver supports DoH", and find that it only does "DoT". Fail open? Fail closed. Those options are both bad.
EKR: {went too fast}
Ben: At a minimum, you need the DHCP server to enumerate the set of protocols supported by the server. If you're going to include that kind of information, you should ship the whole config.
Jim: step back: what is the threat model and what is this particular proposal trying to solve from a threat perspective?
Glenn(no hat): In most cases, these will be legacy devices. We should keep that portion of things simple. Don't add a lot of complexity.
Tiru: If you put the SVCB into the a DHCP option, it seems to go against options guidelines to keep things as simple as possible.
Tommy: Could EKR clarify about using a hash in DHCP? Is it just a validation? That sounds interesting.
Tiru: that sounds interesting. ADN + IP addresses + hash.
Tommy: that would be the limit for DHCP or any other protocol.
At this point, sadly EKR could not be heard.
Ben: in terms of management, doesn't think shipping a hash is really pragmatic. Shipping these records doesn't create a lot of complexity, because they are opaque to the DHCP server. If the concern is about record size, SVCB is tightly optimized for size. We need to talk about TTLs. {Eliot lost his cookies at this point} Putting those TTLs aside, we could fit this in.
Kirsty: We need a clear threat model. Would like a lot more discussion about what problem this is solving.
EKR: Hashes may not be necessary
Eliot: The impact of different DHCP/RA lifetimes and DNS TTLs should be considered.

Slide 3

DoH implementations MUST support DoT. Updates RFC 8484.

At which point EKR had some pretty serious issues.

Chair: take this all to the list. At that point we can evalaute the proposal in its entirety.

Mo: ok.

DNS Server Information with Assertion Token

Tiru presented.

Several revisions to the draft.
A few clarifications for troubleshooting and human readable selection.

Issue 1 (Slide 4)

relies on a draft that is expired.

Ben: {trolled version.bind approach} supports using RESINFO RRtype.

Issue 2 Resolver Assertion Token -> Separate draft?

Eliot: please change the term to avoid conflict with RATS
Tiru: ok
Glenn: go with a separate draft.
Tiru: too early for adoption

Split-Horizon DNS Configuration in Enterprise Networks

Tiru spoke to this one as well.

Goals:
Discover local names.
Discover that network does split DNS
Scope: client can authenticate the identity of the network.

Mechanism (slide 5): provisioning domains.
Slide 6: PVD example

Issue 1 (slide 7): how does the client know that the network is not lying?

Use NSEC3

If public resolver is not reachable, IKE clients MAY want to require whitelisted domains for TLDs and SLDs.

Glenn: there are three scenarios: doesn't exist in global dns. someone publishes non-signed version of that domain. the owner of domain has both internal and external, but the two versions are not aligned.

Tiru: got an issue for this.

Issue 2: network is authortative of the public (Interet-side) domain, but there are different versions.

Feedback requested.

Ben: I like this version, achieves a new version of split-DNS that has new and interesting properties. Is there client-side interest? Simple clients don't need this. Simple clients will use their own or what they get from DNR. The case where it matters is when the client wants to use multiple resolvers. Are there such clients?

Tommy Pauly: As a client implementor, I'm interested in the problem. Agree with Ben on the simple case, but would like to move to scenarios where there is a more private stance by default. "This network has special authority over a special domain" is useful.

Tale: room seems to like the draft. Pushback? [none]

We then took a 7 minute break.

And Dave brought us back with a song.

Open Microphone

Andrew Campling: very encouraging progress.
Tiru: talking about legacy cases where router is doing DNS filtering. Talking about these use cases would be good.
Glenn: RFC 1918, CGNAT, and ability to support these systems.
Tiru: {lots of stuff about products as to why he's interested in ADD on home routers, especially for IoT devices}
Jim Reid: can we please have a draft first on CGNAT/1918? And we need more engagement from those people.
Jim Reid: confused about the state about the daunting number of drafts here.
Neil: likes the idea of adding 1918 and CGNAT considerations. {May not have captured this right}
Tommy Pauly: important to address. Beware of mandates on retry timers etc.

Chair: Ben, regarding your PR, could you please post to the list a pointer to the PR with some prose around it.
Ben: I did.
Ben: what does it mean to get an authentication anchor from an untrusted source? The upgrade is secure if you haven't converted a transcient attacker into a persistent attacker.
Ben: Thus repeat the process every five minutes. But this is not the only hueristic.
Tiru: various ways to identify transcient attacker.
Jim Reid: how should this be incorporated?

{Brief discussion between Andrew and Glenn over the reqs draft}

Tommy: this one just belongs in security considerations for DDR. What stops the transcient attacker from blocking the message later? An attacker could tear down encrypted channels.
Ben: I have assumed that any adversary that can selectively drop packets can selectively insert packets, so we're already hosed.
Tommy: then we have to worry about packet loss
Ben: of course there's retry, but need to look at effects of retries.
Ben: could you surface to the user questions
Tommy: we have examples of implementations that have lists.
Eliot: let's see a draft.
EKR: I'm skeptical that we can ask the right question in a safe way.
Daniel: Why is this so difficult?
EKR: Actually determining which network you're on is difficult.
Fred Baker: with EKR on this point.
Tommy: let's not dive into UI
Tiru: legal entities can solve some of this...

Planning & Wrap up

• Wrap up + Future Planning

Glenn:
No interim meetings yet planned. Stay tuned.
We have two drafts that are adopted. One is adopted for informational purposes.
Let's make sure we make a conscious effort to keep discussions on list, rather than just in github issues.

Meeting Adjourned!

Scribing for session 2 done by Elliot Lear.