IETF
add
add@jabber.ietf.org
Wednesday, January 26, 2022< ^ >
Meetecho has set the subject to: IETF 112 - ADD
Room Configuration
Room Occupants

GMT+0
[16:50:06] Monika Ermert_web_172 joins the room
[16:50:06] Kazunori Fujiwara_web_531 joins the room
[16:50:06] Daniel Gillmor_web_845 joins the room
[16:50:06] Christian Huitema_web_797 joins the room
[16:50:06] Suzanne Woolf_web_698 joins the room
[16:50:06] Tim Wicinski_web_675 joins the room
[16:50:07] Willem Toorop_web_327 joins the room
[16:50:07] Michael Richardson_web_518 joins the room
[16:50:07] Benno Overeinder_web_758 joins the room
[16:51:07] Glenn Deen_web_770 joins the room
[16:51:07] <Christian Huitema_web_797> Good morning, adders!
[16:51:22] <Christian Huitema_web_797> (or is it addlers?)
[16:51:34] <Benno Overeinder_web_758> Goodafternoon DNSOPers
[16:52:28] Tim Wicinski_web_675 leaves the room
[16:52:35] Tim Wicinski_web_285 joins the room
[16:52:40] <Glenn Deen_web_770> and welcome dprive too
[16:52:58] Tim Wicinski_web_285 leaves the room
[16:53:02] Tim Wicinski_web_900 joins the room
[16:53:43] Florian Obser_web_416 joins the room
[16:53:50] Tim Wicinski_web_900 leaves the room
[16:54:08] Tim Wicinski_web_614 joins the room
[16:54:34] <Glenn Deen_web_770> oh now, I'm getting page not found from datatracker when trying to use the meeting materials in meetecho
[16:54:45] Lixia Zhang_web_103 joins the room
[16:55:00] Peter Koch_web_953 joins the room
[16:55:12] Tim Wicinski_web_614 leaves the room
[16:55:16] Tim Wicinski_web_742 joins the room
[16:55:36] Tim Wicinski_web_742 leaves the room
[16:55:39] Benjamin Schwartz_web_133 joins the room
[16:55:40] Tim Wicinski_web_608 joins the room
[16:55:57] Michael Hausding_web_779 joins the room
[16:56:06] Hugo Salgado_web_608 joins the room
[16:56:10] Scott Hollenbeck_web_429 joins the room
[16:57:06] Chi-Jiun Su_web_808 joins the room
[16:57:43] Andrew Campling_web_171 joins the room
[16:57:51] Ted Hardie_web_626 joins the room
[16:57:56] Daniel LaCosse_web_185 joins the room
[16:57:57] Paul Vixie_web_467 joins the room
[16:58:22] Zaid AlBanna_web_490 joins the room
[16:58:22] John Border_web_877 joins the room
[16:58:40] <Ted Hardie_web_626> Aren't adders snakes?  Perhaps additions?
[16:58:43] Chris Box_web_245 joins the room
[16:58:52] Paul Hoffman_web_606 joins the room
[16:58:55] Matthew Quick_web_943 joins the room
[16:59:10] David Lawrence_web_193 joins the room
[16:59:17] Sean Turner_web_687 joins the room
[16:59:24] <Benjamin Schwartz_web_133> "ADD sufferers"
[16:59:40] Ralf Weber_web_459 joins the room
[16:59:43] Vittorio Bertola_web_683 joins the room
[16:59:50] Joey Salazar_web_581 joins the room
[16:59:51] Samuel Weiler_web_529 joins the room
[16:59:54] Dan Wing_web_444 joins the room
[17:00:00] Michael Hollyman_web_311 joins the room
[17:00:02] Robert Evans_web_175 joins the room
[17:00:04] Éric Vyncke_web_431 joins the room
[17:00:06] Carsten Bormann_web_132 joins the room
[17:00:15] Tim Wicinski_web_608 leaves the room
[17:00:15] zyxbac leaves the room
[17:00:15] Matthew leaves the room
[17:00:15] cjsu leaves the room
[17:00:15] Vittorio Bertola leaves the room
[17:00:19] Tim Wicinski_web_649 joins the room
[17:00:19] zyxbac joins the room
[17:00:19] Matthew joins the room
[17:00:19] cjsu joins the room
[17:00:19] Vittorio Bertola joins the room
[17:00:24] Joao Damas_web_424 joins the room
[17:00:28] Eric Orth_web_718 joins the room
[17:00:30] <Christian Huitema_web_797> You wouldn't want to step on a knot of adders, would you?
[17:00:32] Tommy Pauly_web_342 joins the room
[17:00:33] Joao Damas_web_424 leaves the room
[17:00:34] dkg joins the room
[17:00:35] Vladimír Čunát_web_668 joins the room
[17:00:36] Tommy Jensen_web_265 joins the room
[17:00:37] Joao Damas_web_116 joins the room
[17:00:44] Éric Vyncke_web_431 leaves the room
[17:00:48] <dkg> Christian, i think it's "addleds"
[17:00:48] Éric Vyncke_web_700 joins the room
[17:00:49] Duane Wessels_web_679 joins the room
[17:00:56] Nicolai Leymann_web_140 joins the room
[17:01:08] Michael Hausding_web_779 leaves the room
[17:01:12] Éric Vyncke_web_700 leaves the room
[17:01:12] Michael Hausding_web_419 joins the room
[17:01:16] Éric Vyncke_web_402 joins the room
[17:01:16] <dkg> looks good
[17:01:22] Mirja Kühlewind_web_487 joins the room
[17:01:28] <Chris Box_web_245> A half adder is usually harmless
[17:01:57] Petr Špaček_web_115 joins the room
[17:02:15] Andrew S_web_440 joins the room
[17:02:31] <Tim Wicinski_web_649> I will be attempting to take minutes here https://notes.ietf.org/notes-ietf-interim-2022-add-01-add?edit
[17:02:40] Samuel Weiler_web_529 leaves the room
[17:02:47] Jason Livingood_web_129 joins the room
[17:02:48] Tom Carpay_web_559 joins the room
[17:02:51] tale joins the room
[17:02:59] Lixia Zhang_web_103 leaves the room
[17:03:03] Lixia Zhang_web_816 joins the room
[17:03:20] Samuel Weiler_web_672 joins the room
[17:03:27] David Blacka_web_954 joins the room
[17:03:31] Paul Wouters_web_338 joins the room
[17:03:34] Ralf Weber_web_459 leaves the room
[17:03:37] <Éric Vyncke_web_402> Thanks Tim
[17:03:38] Ralf Weber_web_589 joins the room
[17:03:53] <Éric Vyncke_web_402> BTW, Warren told me that he will be late by 15 minutes or so
[17:03:58] cabo joins the room
[17:04:05] Samuel Weiler_web_672 leaves the room
[17:04:09] Samuel Weiler_web_518 joins the room
[17:05:02] <Michael Richardson_web_518> I can help scribe, but I have to leave at the top of the hour for RATS virtual interim.
[17:05:23] mcr joins the room
[17:06:02] <Tim Wicinski_web_649> https://datatracker.ietf.org/meeting/interim-2022-add-01/materials/slides-interim-2022-add-01-sessa-the-split-horizon-dns-problem
[17:06:07] Zaid AlBanna_web_490 leaves the room
[17:06:11] <Tim Wicinski_web_649> Ben's slides if you wish to follow along at home
[17:06:22] Robert Wilton_web_431 joins the room
[17:06:25] Zaid AlBanna_web_305 joins the room
[17:06:58] Jim Reid_web_487 joins the room
[17:07:20] Robert Wilton_web_431 leaves the room
[17:07:24] Robert Wilton_web_445 joins the room
[17:07:43] Ted Hardie_web_626 leaves the room
[17:07:44] zyxbac leaves the room
[17:07:44] Robert Wilton_web_445 leaves the room
[17:07:44] Matthew leaves the room
[17:07:44] cjsu leaves the room
[17:07:44] Vittorio Bertola leaves the room
[17:07:47] Ted Hardie_web_308 joins the room
[17:07:48] zyxbac joins the room
[17:07:48] Robert Wilton_web_420 joins the room
[17:07:48] Matthew joins the room
[17:07:48] cjsu joins the room
[17:07:48] Vittorio Bertola joins the room
[17:07:57] <Petr Špaček_web_115> Excellent "Notes on this session", I have to say.
[17:08:37] Erik Nygren_web_938 joins the room
[17:09:02] Zaid AlBanna_web_305 leaves the room
[17:09:06] Zaid AlBanna_web_504 joins the room
[17:09:36] Scott Rose_web_778 joins the room
[17:10:17] Chi-Jiun Su_web_808 leaves the room
[17:10:21] Chi-Jiun Su_web_965 joins the room
[17:10:23] Chi-Jiun Su_web_965 leaves the room
[17:10:27] Chi-Jiun Su_web_945 joins the room
[17:10:27] <Benno Overeinder_web_758> :thumbsup:
[17:11:44] Andrew Campling_web_171 leaves the room
[17:11:48] Andrew Campling_web_455 joins the room
[17:13:45] Warren Kumari_web_380 joins the room
[17:14:32] <Warren Kumari_web_380> Apologies all for being late - had to deal with appliance drama... :-P
[17:14:59] <Paul Wouters_web_338> I am making coffee too :)
[17:15:19] <dkg> yes, we see them
[17:15:40] Sean Turner_web_687 leaves the room
[17:15:44] Sean Turner_web_651 joins the room
[17:16:08] <Éric Vyncke_web_402> @Warren you announced 15 minutes and you in at 14:32 ;-)
[17:16:25] <Mirja Kühlewind_web_487> @Tim can you mute?
[17:16:54] <Tim Wicinski_web_649> apologies
[17:16:59] <Mirja Kühlewind_web_487> thx
[17:17:31] <dkg> they also do it by accident because they don't understand what they're doing with their IT systems ☹
[17:17:32] zyxbac leaves the room
[17:17:32] Matthew leaves the room
[17:17:32] cjsu leaves the room
[17:17:32] Vittorio Bertola leaves the room
[17:17:32] Vittorio Bertola joins the room
[17:17:33] cjsu joins the room
[17:17:36] zyxbac joins the room
[17:17:36] Matthew joins the room
[17:17:43] <Chris Box_web_245> I would say this isn't limited to network-provided resolvers. The device's configured resolver can also give meaningfully different answers.
[17:18:42] <Tim Wicinski_web_649> https://www.rfc-editor.org/rfc/rfc8499.html#page-21  current def of "split dns"
[17:19:39] <Warren Kumari_web_380> erm.... "not allowed" feel a little funny in this context, but Ok....
[17:19:42] <Duane Wessels_web_679> is it hijacking if you give the right answer?
[17:19:48] <Éric Vyncke_web_402> Local reply to 1.1.1.10.in-addr.arpa is another example which is ambivalent though ;-)
[17:19:59] <Éric Vyncke_web_402> But I like the slides
[17:20:14] <Warren Kumari_web_380> "It's complicated" would probably be the best title for that :-P
[17:20:16] <dkg> Duane, that sounds like forwarding, not answering
[17:20:25] <Petr Špaček_web_115> I think we need to keep in mind that tone of enterprises does "DNS hijacking" as defined here on .local, .internal etc.
[17:20:36] <Andrew Campling_web_455> A document that captures the use cases and definitions for terms would be helpful so that we have an agreed starting point that any proposed solutions can reference.  
[17:20:42] <Benno Overeinder_web_758> I have also heard of scenario's with company mergers. First using split horizon (using one infra for the merged company) and later getting rid of the split horizon.
[17:20:48] Eric Rescorla_web_806 joins the room
[17:20:52] <Paul Wouters_web_338> not .local ? we have an RFC on that? :)
[17:21:04] <Warren Kumari_web_380> @DKG: What if you set the authjorative bit?
[17:21:22] <dkg> Benno: those kind of collisions during org merge also happen with RFC1918 IP address ranges
[17:21:43] <dkg> Warren: that does sound like hijacking to me
[17:21:54] <Tim Wicinski_web_649> i would say not "also" but "always" happens
[17:22:36] <Eric Rescorla_web_806> +1 to exactly what MCR is saying
[17:22:44] <Ted Hardie_web_308> pomme(de terre)
[17:22:56] <Paul Wouters_web_338> "I am protecting you" vs "You are deceiving me"
[17:23:16] <Warren Kumari_web_380> I think that much of the "hijacking" definition / term has lots of "I know it when I see it" in it...
[17:23:39] <dkg> i know a banana when i see it
[17:23:40] Chi-Jiun Su_web_945 leaves the room
[17:23:44] Chi-Jiun Su_web_993 joins the room
[17:23:55] <Paul Wouters_web_338> to scale?
[17:24:09] <Eric Orth_web_718> The second "boring" case might lead to "alternative" mechanisms that are not split DNS.
[17:24:17] <Warren Kumari_web_380> e.g: If I do localroot, I'm answering authoritatively, but perhaps not according to the earlier defintion of authorized...
[17:24:36] <Andrew Campling_web_455> @dkg: It might be a plantain
[17:24:37] <Warren Kumari_web_380> Anyway, rathole...
[17:25:00] <Paul Wouters_web_338> localroot is just caching real answers. not that different from routing port 53 to the live servers
[17:25:01] <Tommy Pauly_web_342> @Eric Orth True, the case of using other resolvers — like knowing I have an enterprise resolver for some domains — allows a solution for "split DNS"
[17:26:04] <Warren Kumari_web_380> @Paul: Depends on how it is implemented - if you download and forward to it, then the "auth" side of it **could** be viewed as hickaing. Again, the intent is somewhat important here.
[17:27:17] <Vladimír Čunát_web_668> Here I wouldn't call it hijacking if it gives the same answer.
[17:28:01] <Warren Kumari_web_380> Yup, I agree. My point was that the provided definition is incomplete, and that any actual definition is hard....
[17:28:13] <Christian Huitema_web_797> Memories of NetBios...
[17:28:16] <Paul Wouters_web_338> the split in split-dns is on the client, not on the network. Or rather, the network behaviour is a wholy other matter
[17:28:28] <Benno Overeinder_web_758> Many resolver already implement this behaviour, not for split DNS, but running local root for example.
[17:28:43] <Éric Vyncke_web_402> true
[17:28:45] <Tommy Pauly_web_342> Right, the VPN case of split DNS is a local rule for splitting traffic between the network and the VPN
[17:28:47] <mcr> I love the shapes.
[17:28:56] <Éric Vyncke_web_402> Yeap, nice sldies
[17:28:59] <Andrew Campling_web_455> @Warren hickaing? Covfefe!
[17:29:05] <Benno Overeinder_web_758> Indeed, very clear!
[17:29:28] <Benno Overeinder_web_758> (the slides and presentation)
[17:29:45] <Paul Wouters_web_338> flashback to long AD assisted side meetings on IKEv2 split DNS RFC :)
[17:29:56] <Warren Kumari_web_380> @Benno: Yah. Or "locally served zones" (e.g: rfc1918 in-addr.arpa) or RPZ, or mitigations for DoS, or...
[17:29:57] <Petr Špaček_web_115> The shapes remarkably clearly show architectural complications of DNS resolvers :-D Nice work!
[17:30:30] <Benno Overeinder_web_758> @warren: indeed.  :-)
[17:30:31] <Warren Kumari_web_380> Another really important, but squishy bit is DNS64...
[17:30:48] <Paul Wouters_web_338> but only after confirming via provisioning !
[17:30:50] <dkg> to work on the DNS you must now be able to solve a jigsaw puzzle
[17:30:51] <Petr Špaček_web_115> I was hoping nobody will mention this ...
[17:31:29] <Erik Nygren_web_938> oooh, good point on DNS64.  I wonder how that best fits into this model, especially given how prevalent it is now.  (does it count as hijacking if endorsed by an rfc?)
[17:31:43] <Éric Vyncke_web_402> DNS64 could also be split if there are split NAT64 ;-)
[17:31:52] <Warren Kumari_web_380> @Petr: I think that it is important -- there is a tendency to underestimate the complxity of the real world in much of these discussions
[17:31:55] Burt Kaliski_web_818 joins the room
[17:31:59] <dkg> can someone unpack the specific problems raised by DNS64 for this topic?
[17:32:07] <Benno Overeinder_web_758> @paul, true
[17:32:10] <Warren Kumari_web_380> and / or assertions that they are corner cases.
[17:32:29] Monika Ermert_web_172 leaves the room
[17:32:33] Monika Ermert_web_101 joins the room
[17:32:39] Monika Ermert_web_101 leaves the room
[17:32:43] Monika Ermert_web_332 joins the room
[17:33:24] <Warren Kumari_web_380> @DKG: if all you have is IPv6, and need to reach www.ipv4only.net, your DNS server will "hijack" the lookup for www.ipv4only.net and synthenize a AAAA answer to send to a NAT64 box.
[17:33:54] <Éric Vyncke_web_402> DKG: DNS64 will create AAAA for a zone that it does not own
[17:34:29] <Vladimír Čunát_web_668> (if the name has A and not AAAA)
[17:35:09] <Christian Huitema_web_797> DNS64 is an interesting way to load the camel.
[17:35:10] <Paul Wouters_web_338> dkg: it synthesizes DNS records,so it cant have DNSSEC guarantees
[17:35:15] <Erik Nygren_web_938> And this is scoped to the network and applies across all zones, so doesn't really fit into this model but is rather orthogonal.The alternative is for clients to resolve ipv4only.arpa (which is explicitly provided by the local network) and for the clients to do the synthesis of AAAA from A.
[17:35:18] <Warren Kumari_web_380> So, I look up www.ipv4only.net, and the DNS64 server replaces 192.0.2.1 with 64:ff9b::192:0:2:1. This gets router to a NAT64 box, which extract the last bit, does does nat to convert IPv6 to IPv4. This is quite common, esp on mobile
[17:35:25] <dkg> thx all for the explanation; where do folks think this sits in Ben's taxonomy of DNS hijacking / split horizon
[17:35:53] <Warren Kumari_web_380> Generally, we try and ignore DNS64, because it makes questions like that hard :-P
[17:36:09] <Warren Kumari_web_380> This comes back and bites us later :-)
[17:37:07] <Christian Huitema_web_797> Or maybe we should treat DNS64 the same way as other transition technologies...
[17:37:16] <dkg> paul, feel free to write here and we can relay
[17:37:33] <Duane Wessels_web_679> I think "DNS hijacking is not allowed within IETF standards" is a false statement
[17:37:38] <dkg> Christian Huitema: you mean, let it linger indefinitely with no way to effectively kill it off?
[17:37:47] <Erik Nygren_web_938> It might be another class of things?  (ie, a filter).  It may have some degree of similarities to networks that replace names with NXDOMAIN or other values to do content filtering, albeit with different potential desirability on behalf of an end-user.  (ie, without DNS64 the network just doesn't work)
[17:37:52] <Warren Kumari_web_380> @Duane: Yes.
[17:38:06] <Sean Turner_web_651> I had that problem too, seemed to fix itself after returning
[17:38:28] <Christian Huitema_web_797> Teredo and 6to4 have seen their usage drop to almost zero. I think we should have the same goal for DNS64.
[17:38:35] Paul Wouters_web_338 leaves the room
[17:38:37] <Éric Vyncke_web_402> The smoke/vapor on Ben's background is weird...
[17:38:39] Paul Wouters_web_537 joins the room
[17:38:45] <Warren Kumari_web_380> Also, DNS hijacking happens constantly -- e.g captive portals. Pretending that things doesn't exist is part of a standard IETF failure mode.
[17:39:00] <Éric Vyncke_web_402> @Christian, I do not expect NAT64 going away before 10+ years :-(
[17:39:47] <Warren Kumari_web_380> Many ISPs also use these for subscribe menagemnt (when you get a new comcast modem), gvmnts use them for objectionable content blocking, etc.
[17:40:05] <Erik Nygren_web_938> If anything, DNS64+NAT64+464xlat is accelerating as one of the major transition technologies.  (It's likely that a majority of mobile phone connectivity relies on it globally now, but I don't have exact answers.)
[17:40:08] <Christian Huitema_web_797> We could encourage the "in the host" solution. Ten it becomes a matter of accomodating legacy IPv4 only hosts, and that could be segregated.
[17:40:59] <Paul Hoffman_web_606> That is not a problem "for ICANN", it is a problem for the entire DNS community.
[17:41:22] <Suzanne Woolf_web_698> @Warren +1. We tend to act as if solving a different problem will make  people migrate away from the problem they currently  have to one we've solved. But  telling people  to  have a different problem usually doesn't get them where they need to go.
[17:41:47] <Erik Nygren_web_938> There have been a few drafts in this area (eg, https://datatracker.ietf.org/doc/html/draft-bp-v6ops-ipv6-ready-dns-dnssec ) but most of those solutions require non-technical mandates that the IETF can't really enforce.
[17:42:24] <Eric Rescorla_web_806> Wouters: we can see you, so with luck, we can hear you soon!
[17:42:45] <Dan Wing_web_444> DNS64 can work with DNSSEC, details at https://datatracker.ietf.org/doc/html/rfc6147#section-3
[17:43:06] <Petr Špaček_web_115> Well, there are published approaches to this "does not exist in public but exists internally" problem. One of them: https://patents.google.com/patent/US20160197898A1/en
[17:43:11] <Paul Wouters_web_537> gma1l.com would be tricky for that
[17:43:31] <Eric Rescorla_web_806> The local fallback is actually not ideal because it causes leaks of non-resolvable domains
[17:43:59] <Petr Špaček_web_115> @Eric: Depends on level. For root it is easy to solve - just grab a local copy.
[17:44:12] Willem Toorop_web_327 leaves the room
[17:44:18] <Petr Špaček_web_115> I mean - grab a copy and search it locally. Then it does not leak anything.
[17:44:35] <Ted Hardie_web_308> This turns out to be advice like "if you sort your nsswitch.conf file so that the public dns resolver is first, this will make your life easier.  You may need to make your private namespace design congruent with this approach"
[17:45:06] <Ted Hardie_web_308> @Eric  agreed, but is this the least worst problem in this can of eels?
[17:46:27] <Dan Wing_web_444> @Eric, re-opening browser tabs while on Starbucks wifi leaks those queries, too.
[17:47:24] <Christian Huitema_web_797> What f, as a consultant, I have access to several split-DNS resolvers?
[17:47:53] <mcr> oooh! we need Spherical DNS resolvers to be compatible with our spherical routers!
[17:47:58] <Paul Wouters_web_537> reconfigure your local dns (stub) via different forwarders
[17:48:49] Paul Hoffman_web_606 leaves the room
[17:48:53] <Paul Wouters_web_537> imho: captive portal is a pre-network and pre-dns config scenario. I think we should assume that happens seperately from this split-dns discussion
[17:50:09] <Petr Špaček_web_115> +1 to Paul's comment
[17:50:48] <Warren Kumari_web_380> A huge number of companies have www.company.com resolve differently internally to www.company.com externally, and they also want this to wok with BYOD devices.
[17:51:14] <Paul Wouters_web_537> warren: use guest wifi with IKEv2 VPN   ? :)
[17:51:44] <Paul Wouters_web_537> (seriously, some kind of trusted / authenticated information exchange of domain list)
[17:52:03] <dkg> Warren: i've seen many such deployments, and about half of them are broken in subtle ways (like also resolving company.com, no www, with a wrong address)
[17:52:34] <Tommy Pauly_web_342> Agreed with ekr on filtering the fallback
[17:52:41] <Warren Kumari_web_380> Oh! I know, we could distribute this list via DHCP! (Warren runs away, giggling)
[17:52:42] <Tommy Pauly_web_342> And yes, captive portals are easy to special-case
[17:52:48] <Paul Wouters_web_537> yes, +1 ekr on that
[17:53:08] <Tommy Pauly_web_342> If you know it's local network (like portals) it's simple to handle
[17:53:48] <Paul Wouters_web_537> did ker just reveal is home domain is .ekr ? :)
[17:53:52] <Ted Hardie_web_308> @Warren  Just hijack sri-nic.arpa and distribute local names as a host file instead of using the DNS.
[17:54:02] <Warren Kumari_web_380> @Ekr: Yes, it is a special case, but it needs to be addressed (even if you just say "Don't do X until you know you are in the Internet")
[17:54:02] <Éric Vyncke_web_402> Wondering whether this meeting drifts more on a split DNS discussion rather than on designated resolver discovery (albeit both are linked)
[17:54:17] Tom Carpay_web_559 leaves the room
[17:54:21] <mcr> I have been trying to take notes in the official HedgeDoc. I wonder if someone else is taking notes elsewhere?
[17:54:26] <mcr> I have to leave in five minutes.
[17:54:41] <Paul Wouters_web_537> the split is the problem space that is vital to what methods of discovery are viable
[17:54:57] <Christian Huitema_web_797> I can't help thinking of a simple-but-wrong solution, a configuration line that says "for *.example.com use "internal-dns.example.com"...
[17:55:05] <Warren Kumari_web_380> @Eric: yes, to me it feels much more like a "DNS problem" than a resolver problem.
[17:55:16] <Eric Rescorla_web_806> Let us also not forget .eth!
[17:56:00] <Warren Kumari_web_380> Thank you Paul V! I was just starting to mention that we also need to figure out how this fits with RPZ.
[17:56:18] <Paul Wouters_web_537> Also, I think vixie looks like a jedi figher. May the force be with him !
[17:56:31] Burt Kaliski_web_818 leaves the room
[17:56:42] <Warren Kumari_web_380> s/looks like/is/
[17:56:57] <mcr> Tim and I found that we had different links, but he is doing a better job than I was :-)
[17:57:17] <Tommy Pauly_web_342> I think filtering is a separate case than split DNS as on the table here. Such a case would generally involve a network wanting to see all the names in order to filter.
[17:57:28] <Éric Vyncke_web_402> Let's reconciliate the minutes AFTER then ;) rather than having split-horizon minutes
[17:58:09] <Vladimír Čunát_web_668> I do consider the splitting closely related to (some kinds of) filtering.
[17:58:42] <Tommy Jensen_web_265> In line with Ben's point about building solutions only for technical gaps, I would assert that enterprises should directly manage devices where they want behavior that cannot be verified as secure by protocol use only. In other words, the solution may not be protocol based but product based where behavior about resolver choice is solved out of band.
[17:58:42] zyxbac leaves the room
[17:58:42] Matthew leaves the room
[17:58:42] cjsu leaves the room
[17:58:42] Vittorio Bertola leaves the room
[17:58:44] <Tommy Jensen_web_265> Maybe defining when each is the better solution should be considered for each use case.
[17:58:46] zyxbac joins the room
[17:58:46] Matthew joins the room
[17:58:46] cjsu joins the room
[17:58:46] Vittorio Bertola joins the room
[17:58:55] Michael Hollyman_web_311 leaves the room
[17:58:58] Michael Richardson_web_518 leaves the room
[17:59:00] <Christian Huitema_web_797> Ben classified as boring the case in which the domain can control the device configuration. Do we agree?
[17:59:33] <dkg> the BYOD case is the hard part, i think -- the admin doesn't (and shouldn't) control the device
[17:59:45] <Paul Wouters_web_537> also look at the future: mixing BYOB with Managed Devices, we might end up on a per-app DNS setting
[17:59:54] <Jim Reid_web_487> Well Christian, I for one think that particular use case is boring
[18:00:00] <Robert Evans_web_175> That scenario excludes clients that assume global DNS is available in some way - the crux of the problem is enterprises probably don't want to pay to patch/ban/manage every such client in their network
[18:00:10] <Éric Vyncke_web_402> @DKG quite often BYOD is linked to some sort of MDM...
[18:00:13] <Eric Orth_web_718> @Christian: I agree.  If the device is controlled, they can control it to make the right DNS queries without any IETF mechanism to tell it how.
[18:00:13] <Christian Huitema_web_797> Also, do we have agreement on the network topology, i.e. how the BYOD device is supposed to access the internal hosts?
[18:00:44] <Erik Nygren_web_938> It seems like there are options even for BYOB if the domain collaborates.  (eg, if the PvD record for "use resolver $foo for domain example.com" has a DNSSEC signature from example.com.)
[18:00:56] <Warren Kumari_web_380> If the device is MDM'ed, then it largely isn't BYOD, it is "lend your company your personal device"
[18:01:21] Samuel Weiler_web_518 leaves the room
[18:01:28] <Christian Huitema_web_797> If we assume that the device accesses the internal host either through a connection to a controlled network or through a VPN, does it simplify the issue?
[18:01:38] <Warren Kumari_web_380> If there is MDM, the 'Y' mostly disappears.
[18:01:41] <Éric Vyncke_web_402> Just wondering how many major corporations accept BYOD w/o MDM for 'really usefull apps'
[18:02:04] <Paul Wouters_web_537> the world is moving towards compartmentalizing a phone where some apps are managed and allowed access and others are not and just have 'internet access'
[18:02:06] <Tommy Pauly_web_342> (A VPN solves the issue, so far simpler)
[18:02:13] <Warren Kumari_web_380> @Cristian: it does simplify things, but it conflicts with what many IT admins would want to have to do...
[18:02:21] Hugo Salgado_web_608 leaves the room
[18:03:17] <Éric Vyncke_web_402> VPN from a corp network to the corp is not always the shortest path...
[18:03:36] <Warren Kumari_web_380> This again feels like "the real world use makes this harder, lets tell people not to do this, and then we can igonre the problem"
[18:03:40] <Éric Vyncke_web_402> ANyway, this is not really linked to the topic of the meeting ;-)
[18:04:36] Vittorio Bertola_web_683 leaves the room
[18:04:40] Vittorio Bertola_web_652 joins the room
[18:04:40] <Erik Nygren_web_938> and the "Zero Trust" push is shifting things away from the "just use a VPN" model and often has something like a localhost agent acting as a DNS resolver or dispatcher.
[18:04:54] <Éric Vyncke_web_402> Another interesting case is of course having 2 connections (cellular + WiFi) and asking for internal.example.org ;-)
[18:05:10] <Éric Vyncke_web_402> Hence the need for PvD (from a RFC 8801 authors)
[18:05:12] <Robert Evans_web_175> also roaming needs consideration
[18:05:38] <Dan Wing_web_444> @Paul, I have a proposal for a certificate like you described at the mic.  Advantage it avoids the client chatting with public DNS (which might be restricted, as said by others during meeting).
[18:05:41] Florian Obser_web_416 leaves the room
[18:05:46] <Éric Vyncke_web_402> @Erik indeed, I can see the end of VPN & split DNS in favor of zero-trust
[18:06:02] <Robert Evans_web_175> the same split dns names might be visible via (client authenticated) DoH/DoT as an internal resolver via Do53
[18:06:18] <Paul Wouters_web_537> dan: yeah like if you do EAPTLS like things to connect to the wifi, the cert could have a domain list embedded
[18:06:25] <Tommy Jensen_web_265> In addition, it seems to make sense that we create solutions even if they rely on public DNS since that will be a common scenario with Zero-Trust evolutions where there is no inherent trust in any network endpoint (not to dismiss the local cases described, simply to say that public-dependent scenarios are still worth solving on their own).
[18:06:35] <Paul Wouters_web_537> but again the problem is if that contains rogue entries
[18:08:48] <Tommy Jensen_web_265> (in a nutshell, +1 to Erik since I missed that message while typing mine)
[18:08:50] Christian Huitema_web_797 leaves the room
[18:08:51] Mirja Kühlewind_web_487 leaves the room
[18:08:54] Christian Huitema_web_649 joins the room
[18:08:55] Mirja Kühlewind_web_692 joins the room
[18:08:56] <Paul Wouters_web_537> I'd phrase it more as "the enterprise forces me to trust them", but yes what Tommy says :)
[18:09:07] Michael Hausding_web_419 leaves the room
[18:11:07] <Christian Huitema_web_649> Warren is speaking about filtering. Is that in scope?
[18:11:32] <dkg> it would be great to define whether filtering is out of scope -- that has come up repeatedly today
[18:11:56] <Vladimír Čunát_web_668> If you split to some other resolver that does whatever, even filtering?
[18:13:10] <Dan Wing_web_444> The confusion with filtering is that today's filtering is implemented using the same configuration as split DNS is configured.
[18:13:11] <Vladimír Čunát_web_668> I mean, IMHO in both cases you give away control over a subtree.
[18:13:19] <Paul Wouters_web_537> dkg: is filtering not a property _after_ the choice of resolver you make? Or are you saying you want a mcehanism to switch based on observed behaviour of your chosen DNS ?
[18:14:28] <dkg> Paul Wouters: if i wanted to filter, i'd want it to happen *after* i choose resolvers, yes.  but i also don't want my DNS filtered at all, so i might not be the most representative for the use case.
[18:14:32] <Warren Kumari_web_380> @Paul: Maybe. But I suspect that my views and e.g the Australian gvmnt (or my wife's company!) views differ...
[18:14:42] <Glenn Deen_web_770> filtering or not isn't part of discovery, it's a behavior of the resolvers.  So neither in or out of scope - it's a different conversation
[18:14:57] <Robert Evans_web_175> standards-based network assertions over DNS are only going to be useful if most/all use cases are accommodated... otherwise the status quo will continue for the unsupported use cases
[18:15:12] <Paul Wouters_web_537> I would say a choice based on detected/advertised filtering is a local client policy
[18:15:28] <Christian Huitema_web_649> We keep hearing the "dns as gatekeeper" request, i.e., force (some) clients to use a specific DNS server and only that one, so the DNS server can filter. Should that be a separate topic, and which group should address that?
[18:16:10] <Paul Wouters_web_537> signed domain lists certificate transparency ? :)
[18:16:27] <Eric Rescorla_web_806> That practice was replaced iwth MITM proxies :)
[18:16:36] <Paul Wouters_web_537> :)
[18:17:07] <Andrew Campling_web_455> @Ben: Agree its sensible to focus on solvable problems providing that these don't limit solutions to tiny edge cases  
[18:17:20] <Vladimír Čunát_web_668> Yes.
[18:17:20] <Christian Huitema_web_649> At least some organizations do NOT want MITM proxies, because they collect toxic data.
[18:17:22] <Erik Nygren_web_938> In many case vendors were able to switch from HTTP filtering to DNS filtering.  If we break DNS filtering, those vendors will have little incentive to not switch back to HTTPS MitM filtering.
[18:17:42] <Eric Rescorla_web_806> @huitema: true
[18:18:12] <Warren Kumari_web_380> @EKR: Actually, yes. We don't want to drive the same sort of thing happening to the DNS or because of this...
[18:18:15] <Eric Rescorla_web_806> @Erik: I don't think that's correct, because you need to manage the machine to do HTTPS MITM filtering and if you can manage the machine, then you can also configure DNS filtering
[18:18:26] <Tommy Pauly_web_342> @Paul Vixie Preventing tracking can be achieved in other ways (oblivious queries, etc)
[18:18:47] <Tommy Jensen_web_265> ekr: bingo, +1
[18:18:48] <Warren Kumari_web_380> (We need to beware of unintended consequences)
[18:19:18] Daniel Gillmor_web_845 leaves the room
[18:19:27] dkg leaves the room
[18:20:49] Andrew Campling_web_455 leaves the room
[18:20:53] Andrew Campling_web_480 joins the room
[18:21:11] <Vladimír Čunát_web_668> User's consent is quite tricky in practice, though.  Majority of people will just click OK to get their internet working.
[18:21:29] <Lixia Zhang_web_816> agree with Vixie on the need for transparency
[18:21:34] <Erik Nygren_web_938> @ekr: some customers of filtering products will always want fine-grained filtering.  The switch to HTTPS made it easy to argue that "DNS" was all you could get within reasonable trade-offs.  If it is as easy to do HTTPS filtering as DNS filtering (eg, installing a CA/policy into the client is needed for either) then those customers will be excited to switch back to fine-grained HTTPS filtering.
[18:21:43] Joey Salazar_web_581 leaves the room
[18:21:59] <Andrew Campling_web_480> @Vladimir: to be fair, there are many worse instances than DNS where that already applies today
[18:22:06] <Vladimír Čunát_web_668> :-)
[18:23:09] <Tommy Jensen_web_265> +1 to Paul on being transparent about behavior. This enables clients acting on their own policy. We do have to keep in mind that it's still Hard for that clam to be verifiable, though positive claims about filtering probably can be trusted (who would say they hijack when they don't?)
[18:23:19] <Christian Huitema_web_649> Transparency is more than user constant. It is also about making policies public. There is a difference between "your enterprise filtered virus-are-us.net" and "your ISP filtered Wikipedia".
[18:24:03] dkg joins the room
[18:24:29] <Tommy Jensen_web_265> +1 Christian. This can also be used automatically say for fallback behavior as ekr said earlier and not cause UX issues (with the blind click through Vladimir calls out)
[18:24:31] <Petr Špaček_web_115> Obviously there is many shades of Transparency. Starting with single-bit information "this answer was tampered with" to reasoning why it was tampered with, possibly what was the original value etc. etc.
[18:24:49] Daniel Gillmor_web_114 joins the room
[18:24:58] <Dan Wing_web_444> filtering is a different topic than split DNS.  Another document I co-author, https://datatracker.ietf.org/doc/html/draft-wing-dnsop-structured-dns-error-page-01, is a proposal for revealing filtering details to a DNS client.
[18:25:04] <Lixia Zhang_web_816> Christian: transparency (if I understand right) just ask users be made aware of what's going on first
[18:25:08] <Vittorio Bertola_web_652> @Christian: First of all, transparency would be about making it clear to you (the end-user) that if your connection fails it is because the domain was blocked and not because of network issues
[18:25:15] <Christian Huitema_web_649> I think filtering and split are two different issues. Split is about providing access to resources that are generally not available, filtering is about denying access to resources that are available.
[18:25:53] <Andrew Campling_web_480> @Petr: There are proposals (in DPrive I think) that provide potential solutions for greater transparency, not limited to split-DNS
[18:25:56] <Petr Špaček_web_115> Sorry Christian to disagree. In my mind split is about giving different answers.
[18:25:56] Jeff Damick_web_328 joins the room
[18:26:28] <Éric Vyncke_web_402> transparency would assume that the user is knowledgeable, not always a given
[18:26:46] <Erik Nygren_web_938> They may also be distinct in that with split the local network or device policy can pre-enumerate the domains wanting different behavior while with filtering you can't.
[18:27:06] <Andrew Campling_web_480> @Eric: It's fair to assume that most users do not know of, let alone understand, DNS
[18:27:07] <Robert Evans_web_175> split names and filtering are both shades of the same problem: discovery of local network policy... re filtering clients can react in a privacy enabling way if they refuse to operate or present strong warnings on "monitored" networks for instance
[18:27:55] <Tommy Jensen_web_265> Transparency doesn't always have to involve real-time user understanding (imagine a stub previously having config for "never use resolvers that claim they hijack", "always defer to local resolvers for names they claim to hijack", etc.)
[18:28:28] <Tommy Jensen_web_265> Such a mechanism could be useful to the stub resolver acting on behalf of previous admin signal (or default platform behavior with no user involvement)
[18:28:28] <dkg> i find Ted's attempt to constrain the discussion useful
[18:28:29] <Petr Špaček_web_115> +1 Tommy
[18:28:45] Jason Livingood_web_129 leaves the room
[18:28:46] Jeff Damick_web_328 leaves the room
[18:29:32] <Warren Kumari_web_380> @DKG / @Ted: Yah.
[18:29:57] <Andrew Campling_web_480> Split Horizon Chairs?
[18:29:58] <Warren Kumari_web_380> It also seems like much of this *could* actually be accomplished (and in some places is) by DNSSEC.
[18:30:15] David Blacka_web_954 leaves the room
[18:30:15] Scott Hollenbeck_web_429 leaves the room
[18:30:16] <Éric Vyncke_web_402> Special thanks to all the chairs !
[18:30:17] Suzanne Woolf_web_698 leaves the room
[18:30:18] Chi-Jiun Su_web_993 leaves the room
[18:30:19] Andrew S_web_440 leaves the room
[18:30:19] Ralf Weber_web_589 leaves the room
[18:30:19] Vittorio Bertola_web_652 leaves the room
[18:30:19] Chris Box_web_245 leaves the room
[18:30:22] Scott Rose_web_778 leaves the room
[18:30:23] <Éric Vyncke_web_402> And Ben for your slides ;-)
[18:30:23] <Tommy Jensen_web_265> See ya at 113, thanks chairs
[18:30:24] Matthew Quick_web_943 leaves the room
[18:30:25] Tim Wicinski_web_649 leaves the room
[18:30:26] <Benno Overeinder_web_758> Thanks!
[18:30:27] Tommy Pauly_web_342 leaves the room
[18:30:30] <Warren Kumari_web_380> I've seen tiings signed with 2 keys, one of which is only internal.
[18:30:30] <tale > Thank you all
[18:30:32] <Warren Kumari_web_380> Thanks all
[18:30:35] Andrew Campling_web_480 leaves the room
[18:30:38] <Tommy Jensen_web_265> And yes, Ben good heavy topic lifting
[18:30:43] Tommy Jensen_web_265 leaves the room
[18:30:44] <Petr Špaček_web_115> Thank you - and hopefully see you in Vienna or elsewhere - soon!
[18:30:46] <Benjamin Schwartz_web_133> Thanks!
[18:30:52] Erik Nygren_web_938 leaves the room
[18:30:53] Eric Rescorla_web_806 leaves the room
[18:30:56] Peter Koch_web_953 leaves the room
[18:30:56] Ted Hardie_web_308 leaves the room
[18:30:56] Eric Orth_web_718 leaves the room
[18:30:59] Éric Vyncke_web_402 leaves the room
[18:30:59] Daniel Gillmor_web_114 leaves the room
[18:30:59] Daniel LaCosse_web_185 leaves the room
[18:30:59] Robert Evans_web_175 leaves the room
[18:31:00] Christian Huitema_web_649 leaves the room
[18:31:02] Carsten Bormann_web_132 leaves the room
[18:31:02] John Border_web_877 leaves the room
[18:31:04] Benno Overeinder_web_758 leaves the room
[18:31:04] Paul Vixie_web_467 leaves the room
[18:31:04] Jim Reid_web_487 leaves the room
[18:31:04] Paul Wouters_web_537 leaves the room
[18:31:09] Dan Wing_web_444 leaves the room
[18:31:09] Mirja Kühlewind_web_692 leaves the room
[18:31:12] Sean Turner_web_651 leaves the room
[18:31:15] Warren Kumari_web_380 leaves the room
[18:31:21] Monika Ermert_web_332 leaves the room
[18:31:27] dkg leaves the room
[18:31:35] Duane Wessels_web_679 leaves the room
[18:31:43] Kazunori Fujiwara_web_531 leaves the room
[18:31:46] Robert Wilton_web_420 leaves the room
[18:31:50] Joao Damas_web_116 leaves the room
[18:31:51] <Petr Špaček_web_115> @Ben Thank you for attempting to constrain such a broad topic - it was an useful attempt, albeit not 100% effective.
[18:32:08] Benjamin Schwartz_web_133 leaves the room
[18:32:14] David Lawrence_web_193 leaves the room
[18:32:19] Glenn Deen_web_770 leaves the room
[18:32:42] Petr Špaček_web_115 leaves the room
[18:32:47] Lixia Zhang_web_816 leaves the room
[18:33:28] tale leaves the room
[18:35:56] Vladimír Čunát_web_668 leaves the room
[18:41:30] Zaid AlBanna_web_504 leaves the room
[18:47:52] Nicolai Leymann_web_140 leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!