IETF110 ADD WG Session Agendas

ADD Chairs & AD

• AD: Barry Lieba(outgoing), Eric Vynke (incoming)
• Chairs: Glenn Deen, David Lawrence

Session link, minutes, jabber

• Meetecho remote
  participation * Minutes *
  Meeting chat

IETF 110 ADD Session Times

ADD has 2 sessions during IETF110:
* Session 1 is 1530-1630 UTC+1 Tuesday March 9, 2021
* Session 2 is 1300-1500 UTC+1 Thursday March 11, 2021

Session 1 Agenda

Welcome

• NOTE WELL
• Scribe selection (Chris Lemmons is taking notes)
• Agenda bashing
• Chairs & AD Comments

Issues from Drafts

Discovery of Designated Resolvers (DDR) draft-ietf-add-ddr

Presented by Tommy Jensen

Issue #2
Benjamin Schwartz: Why are we discussing hints at all?
Tommy Jensen: In order to reduce the round trip time. Also, because if it is not encrypted, it is subject to attack.
Benjamin Schwartz: We should give that more thought. I think it's only an issue when it's empty.

Issues #3 & #4
Benjamin Schwartz: For #4, I thought we had consensus that we don't need multiple name checks on a single cert.
Tommy Jensen: The need for both is laid out. I don't recall the consensus.
Benjamin Schwartz: I disagree with this. I proposed a substantial change to the draft and this behaviour. We'll talk about it more later.
Tommy Jensen: We could talk about it now.
Benjamin Schwartz: Over all, I think the draft contains some incorrect analysis aobut the location of the trust anchors. As a result, I think it comes to the wrong conclusion about cross-ip upgrade. I think we can handle this without changing the fundamental structure, but there are some changes I'd like.
ekr: (Audio cut out for the scribe.) The minimal requirement here is for the hash to contain the name that I started with and a name different than the name I started with.
Benjamin Schwartz: We need to be clear about what information we use as our starting point. That's the main thing we need to be checking.
ekr: As I understand it, I start with example.com and I won't trust any information that I get that doesn't demonstrate that it comes from example.com. I don't mind it having both names, but I don't think it has to have it for every address.
Glenn: So, I think Ben is bringing up good considerations. I think it might be useful if you tried to capture the thinking about the order of these things. If we can capture that in this or a separate document, it might be a very valuable thing long term as people look back.
Tommy Pauly: We should definitly iterate on this. As an example, if a user typed in 1.1.1.1 as their preferred DNS, that's all we know to start with. If that, for some reason that points me to a v6 address that serves quad-1, I want to make sure I can cover the address I started with. If we're doing DOH and we're having to look for cloudflare.com, it seems odd to tell the client NOT to check that the certificate is valid for cloudflare.com.
Benjamin Kaduk: In general, when you're doing TLS, you make a connection with an initial identifier and you have to determine if that cert matches the name you're trying to contact. You can try to say that the IP address is the authority and that makes some sense, but it isn't a great fit. I think it's going to be pretty valuable that the core model is to authenticate the initial connection.
Tommy Jensen: There are two identities being confirmed. Consider: an initial DNS and initial DOH can be different. I need to make sure the TLS cert can contain the DOH connection and also that it confirms the initial DNS connection. Otherwise, an attacker can redirect you to a DOH server they control.
ekr: There are two ways to think about it: cname or 302. On a cname, you expect the authority and cert to match. On a 302, you expect a first authority that you confirm and then you expect the second authority to match the second target. If we're thinking about it like the latter, it's odd to think about the cert for the second as part of the first.
Benjamin Schwartz: Putting a second name in the certificate breaks the HTTP abstraction. If we only have the one name, we can pass it off to an HTTP stack and it already knows how to validate that the name and the certificate matches. If we require multiple names, it gets confusing and we can no longer plug it into a stock stack.There's an analogy to how we use CDNs. We don't ask clients to validate both the authority and the CDN.
Daniel Gillmor: I'm not convinced that our stock HTTP stacks are actually good at checking names. But I agree that asking for multiple name checking is odd. What's the gain for having to check both names?
Tommy Pauly: If all you're validating is that the IP address is valid, you have to treat the authority as the IP address. And that's ok. But we could say that from the DDR perspective, validating only the IP is acceptable. But we could have an additional option there. (Scribe missed some context.)
Eric Orth: The one case where it would be really useful to have this name is when a client wants to verify that there's a whitelist. But then that whitelist could be used for the upgrade anyways. At the least, it's reasonable to say that clients should check against the name. I think the IP gives us all the security properties we need.
Ralf Weber: I agree that we should use a single trust anchor. In section 5, we say if there are 2 targets, we check the source and dest. But if we start with a name, we should check the name. If we start with an IP we should check the IP.
Tommy Jensen: I'll update the issue and take the rest to the list and github.

Issues #6 and #7
Benjamin Schwartz: This is a fundamental scope question: Do we want to try to enable encrypted DNS through legacy customer equipment. If I have a forwarder pointed to my ISP's resolve and all it does is forward, can I or can I not get an encrypted connection to my ISP without replacing my access point. Lots of people are asking for that, but the draft DOES NOT support this use case. I believe it is possible to enable a secure upgrade and I've written the text. But it's up to the WG to decide if we want to include it in the scope.
Tommy Jensen: I think we'll touch on this in the next slide. But right now, the scenario is out of scope because we don't have a solution.

Issues #8 & #9
Eric Orth: Continuing the scope discussion.... It's in a grey area that might be ok for some client's desires and not others. Maybe we should make it an optional case and document it in the draft. Some clients might not accept it, but ecosystem changes might make future clients more willing to support it.

Final Comments
Daniel Migault: I had a question about the use of a special domain. Since those domains break DNSSEC and can't be protected by it, I wonder if we could use a standard name that is part of the DNS heirarchy. We should consider addressing that.
Tommy Jensen: this is an interesting proposal. I think the existing proposal will get better adoption. What you're proposing is possible. Raise the issue on GitHub, please.
Benjamin Schwartz: I think the semantic here doesn't match the way we're using it. (Scribe missed some context.)

DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR) draft-ietf-add-dnr

Presented by Mohamed Boucadair

Slide 3
ekr: Why aren't you just putting in an SVCB record. Why don't we define a common piece of information and put it both places. The information you need here is the same as is in the DDR.
M: That is certainly one option.
ekr: I'm saying put the information in there directly.
M: That's true for the IP addresses and the port number. You can use that directly.
ekr: But there's more stuff in SVCB than the IP and port number
M: We'll discuss that in another slide. Here, we're providing only the minimal information.
ekr: I am disagreeing with that. Let's not reinvent there.
David Lawrence: Let's raise this as an issue.

Slide 6
Schwartz: My preference would be to just provide the name and let the client do DDR with an insecure resolver. This costs some round trips, but it's only on a setup and they're to a local resolver that should be fast. It's only on network connect. It's also operationally preferable in many cases. If I'm on a CP controlled network using the ISPs DNS. If all the information is hardcoded in DHCP, they have to be updated all at once. There's operational value in putting them together. This simplifies the formats.
Jensen: The RTTs are one concern, but security is another. (Scribe missed some context.)
Schwartz: A DNS attacker can't do anything but deny you service.
Pauly: I agree with Ben on this one. Having the name is enough for security. the worst case scenario is that a client would know that encrypted DNS is available and that thye are under attack. Just having the name is enough for that. The overall style of approach is used in VPNs and IPSEC. (Scribe: not sure?) I think it's cleaner to have the name there and let everything else just work. If we have a new DNS encryption type in the future, it would be nice if I just have to update my resolver. If we go another way, we have to propagate the protocol information every time it changes.
ekr: I think Pauly is making a good point. There are two coherent positions: have the name and do DDR or stuff all the DDR information in.
Tirumaleswar Reddy.K: We started with just the name, but we were concerned about DNS attacks modifying responses. But if DNSSEC is required, then we could have just the name. (Scribe: missed context)
Mohamed: I'm hearing the comments. We started with one option and as we progressed we were hearing that the WG is sensitive to the security attacks, internal and external. And there's a tradeoff on the attacks. This is really deployment specific. If there's no list of IP addresses retuned to the client, we have a discussion... see slide 8. We need more discussion and input on this topic.
Daniel Gillmor: I'm confused. The distinction is just a name or full DNS records. If you put just names, then you have a problem linking them to which IP addresses are in use. If you use whole DNS records, you get linkage between IP addresses and domain names.
Schwartz: To answer Tiru: see DDR section 5. It specifies how to connect when you start with an auth name. Even if you have forged DNS records, you do TLS on the end server. If you have insecure DNS to get there, you still auth the end server. To move IP addresses around and if each named resovler is associated with a bag of records, we don't have a problem.
Tiru: If an attacker modifies the DNS record, they can force the client to use a problematic resolver.

Thanks to Chris Lemmons for taking notes.

Discussion (if time permits)

Time did not permit.

Planning & Wrap Up

• Session 2 planning

Session 2 Agenda

Welcome

• NOTE WELL
• Scribe selection
• Agenda bashing
• Chairs & AD Comments

Continued discussion from Session 1

Issues & Discussion

Split-Horizon DNS Configuration in Enterprise Networks

Open Microphone

Planning & Wrap up

* Wrap up + Future Planning