IETF
dprive@jabber.ietf.org
Tuesday, March 9, 2021< ^ >
Brian Haberman has set the subject to: DPRIVE - IETF 108
Room Configuration
Room Occupants

GMT+0
[10:58:06] evansr joins the room
[11:42:49] jhoyla joins the room
[11:46:27] Yoshiro Yoneya_ joins the room
[11:48:43] sftcd-pidgin joins the room
[11:48:54] mnot joins the room
[11:50:03] Willem Toorop_web_690 joins the room
[11:50:03] Alexander Mayrhofer_web_468 joins the room
[11:50:03] George Michaelson_web_513 joins the room
[11:50:03] Paolo Saviano_web_338 joins the room
[11:50:03] Trinh Viet Doan_web_507 joins the room
[11:50:03] Yoshiro Yoneya_web_591 joins the room
[11:50:03] Sara Dickinson_web_320 joins the room
[11:50:03] Akira Kato_web_691 joins the room
[11:50:03] Jonathan Hoyland_web_876 joins the room
[11:50:03] Yuji Koyama_web_299 joins the room
[11:50:03] Scott Hollenbeck_web_431 joins the room
[11:50:03] Kazunori Fujiwara_web_370 joins the room
[11:50:03] Peter van Dijk_web_915 joins the room
[11:50:03] Stephen Farrell_web_993 joins the room
[11:50:46] Tim Wicinski_web_598 joins the room
[11:51:22] Peter Koch_web_798 joins the room
[11:52:05] Antoin Verschuren_web_655 joins the room
[11:52:07] Christian Elmerot_web_582 joins the room
[11:52:12] Brian Haberman_web_250 joins the room
[11:53:11] Takahiro Nemoto_web_862 joins the room
[11:53:39] Ted Hardie_web_887 joins the room
[11:54:00] Watson Ladd_web_815 joins the room
[11:54:08] Éric Vyncke_web_694 joins the room
[11:54:35] Anthony Faust_web_333 joins the room
[11:55:07] Alessandro Ghedini_web_435 joins the room
[11:55:44] Malte Granderath_web_481 joins the room
[11:55:51] Christopher Wood_web_553 joins the room
[11:55:52] Joe Harvey_web_792 joins the room
[11:55:59] Francois Ortolan_web_660 joins the room
[11:56:30] Duane Wessels_web_730 joins the room
[11:56:34] Petr Špaček_web_529 joins the room
[11:56:42] Paul Hoffman_web_847 joins the room
[11:56:47] Puneet Sood_web_618 joins the room
[11:56:54] Jonathan Hoyland_web_876 leaves the room
[11:56:58] Jonathan Hoyland_web_951 joins the room
[11:57:04] Tommy Pauly_web_171 joins the room
[11:57:15] Hiroyuki Goto_web_845 joins the room
[11:57:21] Jonathan Reed_web_380 joins the room
[11:57:35] David Lawrence_web_856 joins the room
[11:57:54] Trinh Viet Doan_web_507 leaves the room
[11:57:54] Steffen Klassert_web_591 joins the room
[11:57:55] Andrew Campling_web_728 joins the room
[11:57:58] Burt Kaliski_web_746 joins the room
[11:58:16] Matt Green_web_305 joins the room
[11:58:25] Anders Kölligan_web_267 joins the room
[11:58:37] Frode Sorensen_web_237 joins the room
[11:58:38] Olaf Kolkman_web_511 joins the room
[11:58:39] Vladimír Čunát_web_790 joins the room
[11:58:56] Benno Overeinder_web_870 joins the room
[11:58:56] Lixia Zhang_web_988 joins the room
[11:58:56] Andrew S_web_835 joins the room
[11:58:59] Eric Orth_web_845 joins the room
[11:59:13] Doug Stamper_web_847 joins the room
[11:59:21] Joey Salazar_web_995 joins the room
[11:59:31] <Éric Vyncke_web_694> Nice to see that slides are full-screen  :-)
[11:59:42] Ulrich Wisser_web_319 joins the room
[11:59:44] Michael Breuer_web_134 joins the room
[11:59:46] Trinh Viet Doan_web_988 joins the room
[11:59:52] Philipp Tiesel_web_694 joins the room
[11:59:53] Chris Box_web_781 joins the room
[11:59:54] Patrick Tarpey_web_221 joins the room
[11:59:54] Ray Bellis_web_967 joins the room
[11:59:58] Benno Overeinder joins the room
[12:00:00] Tom Carpay_web_422 joins the room
[12:00:01] Paul Wouters_web_852 joins the room
[12:00:12] Burt Kaliski_web_746 leaves the room
[12:00:13] Brett Carr_web_374 joins the room
[12:00:14] Gijs Beernink_web_589 joins the room
[12:00:15] Burt Kaliski_web_296 joins the room
[12:00:16] Marco Davids_web_791 joins the room
[12:00:24] <Brian Haberman_web_250> /topic DPRIVE@IETF110
[12:00:26] <Paul Hoffman_web_847> Apologies to anyone in Alaska or Hawaii
[12:00:26] Andreas Pantelopoulos_web_811 joins the room
[12:00:28] Yoshiro Yoneya_ has set the subject to: DPRIVE - IETF 110
[12:00:31] Jan Včelák_web_189 joins the room
[12:00:35] Benjamin Schwartz_web_249 joins the room
[12:00:47] Vaibhav Bajpai_web_386 joins the room
[12:00:53] Libor Peltan_web_879 joins the room
[12:00:53] Andrew McConachie_web_556 joins the room
[12:01:01] Taiji Kimura_web_267 joins the room
[12:01:05] Chi-Jiun Su_web_905 joins the room
[12:01:10] Swapneel Sheth_web_143 joins the room
[12:01:10] Ben Schwartz joins the room
[12:01:11] Richard Wilhelm_web_391 joins the room
[12:01:21] Robert Evans_web_797 joins the room
[12:01:21] Jim Reid_web_882 joins the room
[12:01:50] Yahya_web_706 joins the room
[12:01:54] Hiromu Shiozawa_web_240 joins the room
[12:01:54] Avri Doria_web_128 joins the room
[12:01:55] <David Lawrence_web_856> Personally I'd almost prefer being in Alaska or Hawaii, it'd totally change how I approach the week
[12:02:07] Hugo Salgado_web_908 joins the room
[12:02:16] Suzanne Woolf_web_723 joins the room
[12:02:16] Tommy Jensen_web_652 joins the room
[12:02:25] Dan McArdle_web_519 joins the room
[12:02:25] Pallavi Aras_web_496 joins the room
[12:02:31] Vittorio Bertola_web_453 joins the room
[12:02:32] Brian Dickson_web_549 joins the room
[12:02:33] Jari Arkko_web_490 joins the room
[12:02:39] Glenn Deen_web_383 joins the room
[12:02:40] Daniel Gillmor_web_723 joins the room
[12:02:56] hugo-salgado joins the room
[12:02:57] ekr@jabber.org joins the room
[12:03:00] <David Lawrence_web_856> inglorious?!
[12:03:04] James Gould_web_499 joins the room
[12:03:10] Francisco Arias_web_369 joins the room
[12:03:17] Jiankang Yao_web_666 joins the room
[12:03:19] Corinne Cath_web_428 joins the room
[12:03:21] Erik Nygren_web_519 joins the room
[12:03:22] Tirumaleswar Reddy.K_web_505 joins the room
[12:03:24] Tobias Mayer_web_535 joins the room
[12:03:26] Joao Damas_web_796 joins the room
[12:03:30] Monika Ermert_web_378 joins the room
[12:03:32] dkg joins the room
[12:03:57] Mallory Knodel_web_179 joins the room
[12:04:02] <ekr@jabber.org> FYI, I am stuck in RFCEDFP for the beginning of this. I am going to be watching Jabber, but could someone please flag me when we get towards the end of the ODoH presentation
[12:04:06] Mike Bishop_web_330 joins the room
[12:04:28] Nicklas Pousette_web_937 joins the room
[12:04:44] Zaid AlBanna_web_397 joins the room
[12:04:48] Zaid AlBanna_web_397 leaves the room
[12:04:52] <Watson Ladd_web_815> Will do, but I haven't seen the slides, so if there unnumbered i might miss it
[12:04:55] Nicklas Pousette_web_937 leaves the room
[12:04:55] Robert Story_web_244 joins the room
[12:04:57] Zaid AlBanna_web_255 joins the room
[12:04:58] Vincent Levigneron_web_111 joins the room
[12:04:59] Nicklas Pousette_web_742 joins the room
[12:05:07] <dkg> ekr's name needs more r's
[12:05:15] David Schinazi_web_993 joins the room
[12:05:17] <ekr@jabber.org> More piratical?
[12:05:17] Luigi Iannone_web_924 joins the room
[12:05:19] <dkg> "rescola"
[12:05:19] <Scott Hollenbeck_web_431> +q
[12:05:23] Michael Richardson_web_170 joins the room
[12:05:27] Matthew Quick_web_304 joins the room
[12:05:32] <ekr@jabber.org> LOL. OK that too
[12:05:32] Nicklas Pousette_web_742 leaves the room
[12:05:35] Nicklas Pousette_web_301 joins the room
[12:05:40] Burt Kaliski_web_296 leaves the room
[12:05:45] Burt Kaliski_web_330 joins the room
[12:05:54] John Border_web_122 joins the room
[12:06:04] <Watson Ladd_web_815> the queue is with the hand raise button
[12:06:04] Eric Rescorla_web_755 joins the room
[12:06:04] Nicklas Pousette_web_301 leaves the room
[12:06:07] Nicklas Pousette_web_705 joins the room
[12:06:12] <jhoyla> @Watson the ODoH presentation has 12 slides.
[12:06:31] Tirumaleswar Reddy.K_web_505 leaves the room
[12:06:41] <Watson Ladd_web_815> thanks!
[12:06:42] Nicklas Pousette_web_705 leaves the room
[12:06:45] Nicklas Pousette_web_618 joins the room
[12:07:10] Farni Boten_web_480 joins the room
[12:07:10] Nicklas Pousette_web_618 leaves the room
[12:07:14] Nicklas Pousette_web_381 joins the room
[12:07:19] Nicklas Pousette_web_381 leaves the room
[12:07:19] John Mah_web_708 joins the room
[12:07:22] Nicklas Pousette_web_811 joins the room
[12:07:28] Eric Kinnear_web_841 joins the room
[12:07:54] Sara Dickinson_web_320 leaves the room
[12:07:54] Gianpaolo Scalone_web_795 joins the room
[12:07:59] Sara Dickinson_web_544 joins the room
[12:09:08] Luuk Hendriks_web_696 joins the room
[12:09:12] <Paul Wouters_web_852> it seems we need a requirements draft to say "what are the limitations of the DNS ecosystem"
[12:09:14] <David Lawrence_web_856> yes to document
[12:09:18] <Zaid AlBanna_web_255> +1
[12:09:28] <Brian Dickson_web_549> +1
[12:09:33] <dkg> +1 to document as well
[12:09:42] Kris Shrishak_web_756 joins the room
[12:09:56] <Joey Salazar_web_995> +1
[12:09:58] <Brett Carr_web_374> +1
[12:10:11] <Andrew Campling_web_728> +1
[12:10:27] Lu Zhao_web_678 joins the room
[12:10:28] <Scott Hollenbeck_web_431> +1, it's a chartered work item
[12:10:31] mcr joins the room
[12:10:34] <Jim Reid_web_882> yes to doc, but what happens if the WG can't or won't make progress?
[12:10:37] Tirumaleswar Reddy.K_web_441 joins the room
[12:10:41] <Brett Carr_web_374> Id be happy to be a reviewer
[12:10:50] <David Lawrence_web_856> I also like the idea of Paul's proposed doc
[12:11:14] Burt Kaliski_web_330 leaves the room
[12:11:17] Burt Kaliski_web_614 joins the room
[12:12:09] <Benno Overeinder_web_870> Thank you all for your feedback on the document.
[12:12:21] Puneet Sood_web_618 leaves the room
[12:12:24] Puneet Sood_web_818 joins the room
[12:12:27] Puneet Sood_web_818 leaves the room
[12:12:27] Tirumaleswar Reddy.K_web_441 leaves the room
[12:12:41] Puneet Sood_web_251 joins the room
[12:12:54] Francisco Arias_web_369 leaves the room
[12:12:58] Francisco Arias_web_332 joins the room
[12:13:10] <Brian Dickson_web_549> Requirements are absolute, since the same authoritative servers are going to be involved regardless of whether the client wants to be opportunistic or enforcing.
[12:13:19] <Benno Overeinder_web_870> And thank you Scott and Peter for earlier feedback and contributions to the requirements (by lack of better word now) document.
[12:13:23] Hugo Kobayashi_web_871 joins the room
[12:13:25] <Brian Dickson_web_549> I.e. there is no "choose" from that perspective.
[12:13:34] <Peter van Dijk_web_915> Brian, -some- of the requirements are absolute :)
[12:13:50] <Brian Dickson_web_549> Yes, I sit corrected :-)
[12:13:53] Tirumaleswar Reddy.K_web_844 joins the room
[12:13:58] <Peter van Dijk_web_915> and some requirements might be absolute from a solution description, not before
[12:14:27] Linlin Zhou_web_525 joins the room
[12:14:48] Brad Gorman_web_284 joins the room
[12:15:21] Omer Shapira_web_556 joins the room
[12:15:27] <Andrew Campling_web_728> Link to AdGuard DoQ presentation if interested: https://419.consulting/encrypted-dns/f/dns-over-quic-doq
[12:15:29] Tirumaleswar Reddy.K_web_844 leaves the room
[12:15:30] Jari Arkko_web_490 leaves the room
[12:15:34] Tirumaleswar Reddy.K_web_933 joins the room
[12:15:44] Avri Doria_web_128 leaves the room
[12:15:47] Avri Doria_web_935 joins the room
[12:16:04] Omer Shapira_web_556 leaves the room
[12:16:07] Omer Shapira_web_738 joins the room
[12:16:30] <dkg> i find it unusual to register ports > 1024, because aiui, some systems might have them in the dynamic allocation range
[12:16:46] Tara Whalen_web_378 joins the room
[12:16:49] Tirumaleswar Reddy.K_web_933 leaves the room
[12:16:54] Tirumaleswar Reddy.K_web_493 joins the room
[12:16:56] Burt Kaliski_web_614 leaves the room
[12:16:59] Burt Kaliski_web_512 joins the room
[12:17:05] Omer Shapira_web_738 leaves the room
[12:17:15] <Peter van Dijk_web_915> >1023 can be bound by any user on a system, generally, instead of being limited to 'root'; and the dynamic range indeed tends to be a subset of 1024-65535
[12:17:33] Leif Johansson_web_514 joins the room
[12:17:39] Alissa Cooper_web_926 joins the room
[12:17:45] <Peter van Dijk_web_915> so, weird to me too
[12:17:55] David Smith_web_807 joins the room
[12:18:03] <Watson Ladd_web_815> IANA has put a number of things in the user range
[12:18:11] <Vladimír Čunát_web_790> Yes, this permission issue seem more relevant to me.
[12:18:11] <Paul Wouters_web_852> yeah it would hit things like SElinux and AppArmor and need exceptions everywhere
[12:18:14] <dkg> and yes, i meant >1023, it's too early to not make off-by-one-errors
[12:18:16] <Éric Vyncke_web_694> OTOH, not having to be root to run a service is a simple security feature
[12:18:30] <Peter van Dijk_web_915> having to be root to run a service is also a security feature ;)
[12:18:42] Mallory Knodel_web_179 leaves the room
[12:18:42] <Paul Wouters_web_852> you still arent putting things in dedicated containers/namespaces/VMs ? :)
[12:18:44] <Peter van Dijk_web_915> it does not mean the software has to run as root, it just means the system admin is in control
[12:18:48] Mallory Knodel_web_354 joins the room
[12:18:58] Burt Kaliski_web_512 leaves the room
[12:19:00] <Paul Wouters_web_852> what peter said :)
[12:19:01] Burt Kaliski_web_847 joins the room
[12:19:06] <dkg> modern supervisors allow selective assignment of capabilities like CAP_NET_BIND
[12:19:13] Maarten Aertsen_web_272 joins the room
[12:19:16] <Peter van Dijk_web_915> dkg, exactly that
[12:19:16] <Vladimír Čunát_web_790> +1
[12:19:17] <dkg> (without running as root)
[12:19:21] Luigi Iannone_web_924 leaves the room
[12:19:25] <Éric Vyncke_web_694> @PvD sure for the mapping or for dropping uid after
[12:19:36] <Vladimír Čunát_web_790> (or it's possible to pass a bound socket)
[12:19:46] <dkg> +1 Vladimir
[12:19:51] Brad Gorman_web_284 leaves the room
[12:20:04] Glenn Deen_web_383 leaves the room
[12:20:07] Glenn Deen_web_988 joins the room
[12:20:30] Samuel Weiler joins the room
[12:20:37] whalen@jabber.org joins the room
[12:23:04] Akira Kato_web_691 leaves the room
[12:23:07] Akira Kato_web_142 joins the room
[12:23:34] Anthony Faust_web_333 leaves the room
[12:23:51] Joao Damas_web_796 leaves the room
[12:23:54] Joao Damas_web_817 joins the room
[12:24:03] whalen@jabber.org leaves the room
[12:24:16] <David Lawrence_web_856> ... oh let me tell you about old arguments on the 65k limit
[12:24:18] Luigi Iannone_web_996 joins the room
[12:24:19] <Ray Bellis_web_967> NB: compression pointers in DNS are limited to 16kB, not 64kB
[12:24:38] <David Lawrence_web_856> FWIW I'm on your side, I don't think it makes sense to keep the limit.
[12:24:48] <dkg> makes me think about the old 512B limit on UDP
[12:24:48] <David Lawrence_web_856> er 64k
[12:24:57] <Andrew Campling_web_728> @David Where's Bill Gates when you need him?  
[12:25:02] Anthony Faust_web_846 joins the room
[12:25:12] <Watson Ladd_web_815> silly question: why not DoHTTP3?
[12:25:23] <Vladimír Čunát_web_790> That's standardized already.
[12:25:26] <dkg> Watson Ladd_web_815: i think that's already being done :)
[12:25:44] <Vladimír Čunát_web_790> But unlikely towards auths.
[12:25:52] <Libor Peltan_web_879> I vote against relaxing the 64k limit, if not very clearly much needed.
[12:25:59] <Peter van Dijk_web_915> I like 853
[12:25:59] <Ray Bellis_web_967> you also can't proxy from DoQ into Do53 if DoQ permits a larger message size
[12:26:29] <Andrew Campling_web_728> @Watson - the AdGuard team had some clear views on why DoQ was a better choice than HTTP3
[12:26:37] <dkg> can these things be done in parallel?
[12:26:38] <Mike Bishop_web_330> +1 for 853; QUIC was designed to demux with DTLS.
[12:26:46] Jiri Novotny_web_232 joins the room
[12:26:57] Omer Shapira_web_926 joins the room
[12:27:09] Shumon Huque_web_761 joins the room
[12:27:16] Thomas Duffy_web_369 joins the room
[12:27:21] <Vladimír Čunát_web_790> I'm also unsure if DNS over DTLS really exists in practice (or ever will).
[12:27:30] <Petr Špaček_web_529> Most importantly other limits are baked into the protocol in other places as well so there is no point in relaxing one just to hit another one. Think of compression pointers, RR counts in message headers, ...
[12:27:55] <Libor Peltan_web_879> FYI modern auth implementations send only ~~17k XFR messages in order to make compression efficient.
[12:27:56] <David Lawrence_web_856> The discussion over keeping 64k might go differently this time, since one of its primary advocates isn't doing DNS now.
[12:27:57] <Ben Schwartz> RDATA length field :-/
[12:28:10] <Erik Nygren_web_519> +1 for 853
[12:28:13] <Ted Hardie_web_887> I think the AXFR version is very useful and not that much additional work to get done now..  Just a personal opinion, of course.
[12:28:21] Mirja Kühlewind_web_669 joins the room
[12:29:00] <David Lawrence_web_856> Personally I don't find "but there are other limits" to be compelling.  Yes, there are, no argument there.    But why keep one where you don't need to?
[12:29:06] Anders Kölligan_web_267 leaves the room
[12:29:11] Anders Kölligan_web_832 joins the room
[12:29:31] <Petr Špaček_web_529> Wondering out loud: Why would we need to do anything extra, except for simply allowing multiple answers in single "stream"? DNS client receiving XFR already has code to detect if end of XFR was received or not. I mean - clients already can detect this condition without additional signal. What am I missing?
[12:30:11] <Peter van Dijk_web_915> It would be nice if we could stop counting SOAs in proxies, though :)
[12:30:18] <Paul Hoffman_web_847> There's lots of stuff here that would be good on the list.
[12:30:27] <Erik Nygren_web_519> I'm also inclined to hope that we can make DoQ as MTI for encrypted recursive-to-authoritative
[12:30:37] <Vladimír Čunát_web_790> @David: proxying sounds like a good argument to me.
[12:31:19] Omer Shapira_web_926 leaves the room
[12:31:22] Omer Shapira_web_908 joins the room
[12:31:38] <Paul Hoffman_web_847> +1 to @Erik
[12:31:54] <Vladimír Čunát_web_790> +1
[12:32:11] <Erik Nygren_web_519> (and please don't do recursive-to-authoritative over udp/443...  Although using a different port for recursive-to-auth vs client-to-recursive might not be bad.
[12:32:38] <Brian Dickson_web_549> +1e6
[12:32:46] <David Lawrence_web_856> Of all of them it might have the most strength, but for the inability of proxying to handle some types of transactions is one that's far older than the DNS, and already exists in the DNS as well for TCP vs UDP.
[12:32:47] <Ben Schwartz> (With SVCB-like discovery, resolvers can use whatever port suits them.)
[12:32:51] <dkg> Erik Nygren_web_519: why not ?  can you be more specific about your concerns?
[12:33:26] Shumon Huque_web_761 leaves the room
[12:33:29] Shumon Huque_web_602 joins the room
[12:33:53] <Joey Salazar_web_995> 443 does seem better than the alternatives imo
[12:34:01] Linlin Zhou_web_525 leaves the room
[12:34:49] <Eric Rescorla_web_755> I also do not see a problem with 443
[12:34:52] <Eric Rescorla_web_755> DoH is 443
[12:35:03] <Jan Včelák_web_189> @Petr Spacek: Good point. The 16-bit RR count in the header is another reason why XFR needs to support more response messages. I didn't realize that when commenting on removing the message size.
[12:35:51] <Peter van Dijk_web_915> does QUIC compress?
[12:35:58] <Eric Rescorla_web_755> @Peter: no
[12:36:01] <Brian Dickson_web_549> DoHTTP3 is 443, I don't think DoQ should squat
[12:36:05] <Eric Rescorla_web_755> I mean it compresses HTTP headers
[12:36:06] Matthew Quick_web_304 leaves the room
[12:36:19] <Peter van Dijk_web_915> right, but not content
[12:36:20] <Watson Ladd_web_815> @ekr we're on slide 10 or so by my count
[12:36:28] <Eric Rescorla_web_755> @Brian: sorry, I'm following this asycnhronously, so I thought this was about DoH
[12:36:30] <dkg> compression and encryption are not really a good idea to mix (cf CRIME attack)
[12:36:39] <Peter van Dijk_web_915> dkg, I remembered that but did not want to guess :)
[12:36:45] <Watson Ladd_web_815> so you might want to hop on if youw ant to ask ODOH questions
[12:36:46] Samuel Weiler_web_499 joins the room
[12:36:49] Linlin Zhou_web_281 joins the room
[12:37:04] Robert Story_web_244 leaves the room
[12:37:09] Robert Story_web_848 joins the room
[12:37:16] <Eric Rescorla_web_755> I am stuck in RFCEDFP for now
[12:37:25] <Eric Rescorla_web_755> But I'll just say what I think about ODoH versus OHTTP
[12:37:32] Omer Shapira_web_908 leaves the room
[12:37:35] Omer Shapira_web_745 joins the room
[12:37:38] <Eric Rescorla_web_755> Which is that I like what's on this slide, but I'd hopefully like to see a merge.
[12:37:47] <Eric Rescorla_web_755> I suggest we have ODoH as experimental in case there is no merge
[12:37:55] <Eric Rescorla_web_755> as we expect ODoH to eventually be replaced
[12:38:13] <Ray Bellis_web_967> @dkg if you want to proxy Do53/DoTCP into DoQ *without* compression then that puts the onus on the proxy to decompress the stream completely and then resend it, instead of just replacing transport headers.
[12:38:36] <dkg> the bullet point here sort of mischaracterizes Alec's slides from NDSS, thought Chris said it verbally
[12:38:44] Matthew Quick_web_993 joins the room
[12:38:54] <Paul Wouters_web_852> yes I agree. Alec's conclusion was at times it was faster
[12:39:10] <dkg> Muffett said using tor was slower, but it was so unnoticeable that he forgot about it for months while it was working
[12:40:08] <Paul Wouters_web_852> but he also saw lower latency than using various large dns hosters at times.
[12:40:31] Dan McArdle_web_519 leaves the room
[12:40:36] Dan McArdle_web_988 joins the room
[12:40:36] <Andrew Campling_web_728> Link to DoH over TOR presentation from Alec Muffet - https://419.consulting/encrypted-dns/f/dns-over-https-over-tor
[12:40:37] <dkg> Ray Bellis_web_967: which compression are you talking about?
[12:40:55] <Patrick Tarpey_web_221> The second bullet point is very pertinent "what are the incentives to operate an ODoH proxy"?
[12:41:17] Nicklas Pousette_web_811 leaves the room
[12:41:18] Akira Kato_web_142 leaves the room
[12:41:22] Nicklas Pousette_web_396 joins the room
[12:41:23] Akira Kato_web_799 joins the room
[12:41:51] Hugo Salgado_web_908 leaves the room
[12:41:53] Bron Gondwana_web_369 joins the room
[12:41:56] Hugo Salgado_web_459 joins the room
[12:42:19] <Jim Reid_web_882> @ Patrick The same incentives to run a ToR node?
[12:42:23] Ted Hardie_web_887 leaves the room
[12:42:26] Ted Hardie_web_245 joins the room
[12:42:30] <Paul Wouters_web_852> same as for running a large open anycast dns cloud?
[12:42:33] <zulipbot> (Puneet Sood) DoHoToR presentation was of a ad-hoc solution for one person. It was not tuned for latency compared to the ODoH experiments presented at NDSS.
[12:42:38] Yahya_web_706 leaves the room
[12:42:49] <dkg> Jim Reid_web_882: it's just "Tor" :)
[12:43:09] Bron Gondwana_web_369 leaves the room
[12:43:20] <Ray Bellis_web_967> @dkg the built-in label compression in the DNS protocol.
[12:44:39] <dkg> Ray Bellis_web_967: i think there's interesting analysis work to be done there.  
[12:44:54] <Leif Johansson_web_514> @dkg https://en.wikipedia.org/wiki/Tor_functor
[12:45:02] <Eric Rescorla_web_755> To recap what I said before: let's take this as Experimental
[12:45:06] Burt Kaliski_web_847 leaves the room
[12:45:09] <Ben Schwartz> +1
[12:45:13] Burt Kaliski_web_833 joins the room
[12:45:13] <Brian Dickson_web_549> Vague, hand-wavy open question about ODoH, has any thought been given to ODoT, or is the issue of naming DoT resolver a roadblock?
[12:45:14] <Joey Salazar_web_995> +1
[12:45:17] <Tommy Pauly_web_171> +1, as an author and implementor, I'd like this to be experimental
[12:45:18] Antoin Verschuren_web_655 leaves the room
[12:45:20] <dkg> i'd expect anyone doing encrypted recursive to authoritative to think about padding at least
[12:45:30] Antoin Verschuren_web_552 joins the room
[12:45:34] Vaibhav Bajpai_web_386 leaves the room
[12:45:49] <David Lawrence_web_856> sounds like a cooing pigeon
[12:46:00] <George Michaelson_web_513> I thought it was a brontosaur grinding rocks in its stomach, or a whale
[12:46:02] <Tim Wicinski_web_598> I thought only my dog sawed logs
[12:46:09] <Joey Salazar_web_995> cute dog snores
[12:46:42] <Eric Kinnear_web_841> +1 experimental is fine, I think we're in alignment on future OHTTP updates
[12:46:57] <Eric Rescorla_web_755> To be clear, this is amazing
[12:47:10] <Eric Rescorla_web_755> and I love that it got kicked off
[12:47:21] Omer Shapira_web_745 leaves the room
[12:47:22] <Tim Wicinski_web_598> +1 on the experimental
[12:47:24] Omer Shapira_web_833 joins the room
[12:47:25] <Andrew Campling_web_728> +1 to Paul Hoffman's point - most users don't even know what DNS is!
[12:47:51] <Watson Ladd_web_815> do we have a jabber scribe? or should I hop on and read ekrs comment and the +1 's to experimental
[12:47:52] <Joey Salazar_web_995> user's knowledge shouldn't be a constraint to how much privacy benefit they get
[12:48:21] <jhoyla> I think there's no official Jabber scribe.
[12:48:28] Brad Gorman_web_492 joins the room
[12:48:31] Taiji Kimura_web_267 leaves the room
[12:48:31] <Jiri Novotny_web_232> +1 to Joey
[12:48:35] <dkg> agreed, asking users questions about how this stuff works leads to https://xkcd.com/2432/
[12:49:01] <Tommy Jensen_web_652> +1 to Joey
[12:49:12] <Erik Nygren_web_519> +1 on Experimental, but WG may be better since this experiment requires multiple parties (client/proxy/target) to cooperate.
[12:49:13] <Eric Kinnear_web_841> Yes
[12:49:25] <zulipbot> (Puneet Sood) +1 to experimental
[12:49:32] <Vladimír Čunát_web_790> Experimental adoption sounds OK.
[12:49:33] <Tim Wicinski_web_598> at least to adopt and let folks noodle on
[12:49:43] <Andrew Campling_web_728> Any options to ensure that this doesn't cause further centralisation?
[12:49:56] <Petr Špaček_web_529> Given prospect of OHTTP adoption sounds like waste of WGs time.
[12:49:59] <Joey Salazar_web_995> Experimental adoption +1 I think the WG should work on it
[12:50:04] Hugo Kobayashi_web_871 leaves the room
[12:50:29] <Paul Hoffman_web_847> Tommy: this WG *never* does quick processing. You're essentially asking for a long delay before specification.
[12:50:34] <Mirja Kühlewind_web_669> +1 this work is interesting and I would rather like to see in dprive than AD sponsored or something
[12:50:39] <dkg> Andrew Campling_web_728: this seems like an attempt to *answer* concerns about centralization, no?
[12:50:47] <Erik Nygren_web_519> Maybe a hum on general interest for adoption?
[12:50:52] <Christopher Wood_web_553> A hum sounds good.
[12:50:57] <Joey Salazar_web_995> @Petr how certain can we be that OHTTP will be succesful?
[12:51:00] <zulipbot> (Puneet Sood) -1 to adoption by this WG at the moment. More than the protocol bits, the discovery aspect will probably take more work.
[12:51:01] <Tirumaleswar Reddy.K_web_493> How would it impact the work in ADD ?
[12:51:38] <Erik Nygren_web_519> The show-of-hands tool works well for polls here
[12:51:40] <Andrew Campling_web_728> @dkg - possibly, unless only a few proxies step forward, ditto targets etc
[12:51:44] <Watson Ladd_web_815> the bar to adoption is not the same as for WGLC
[12:51:50] <Watson Ladd_web_815> work can be done in the working group
[12:51:54] <Christopher Wood_web_553> The discovery bit is *out of scope*
[12:52:00] <dkg> Andrew Campling_web_728: in particular, it reduces the pool of data held by any of the actors
[12:52:02] <ekr@jabber.org> I agree.
[12:52:07] <ekr@jabber.org> (with DKG)
[12:52:10] <David Lawrence_web_856> How do you imagine it would impact the work here?  (I'm not saying it would or would not, just having a failure of imagination.)
[12:52:16] <David Lawrence_web_856> er, in add I mean
[12:52:24] Brad Gorman_web_492 leaves the room
[12:52:32] <Joey Salazar_web_995> @Andrew the concern being that it's being championed by Cloudfare? Or how it selects from the available DoH resolvers?
[12:52:44] <Eric Rescorla_web_755> Should this say "ODoH"?
[12:52:49] <Eric Rescorla_web_755> (in the poll)
[12:52:54] <dkg> lack of discovery defintely means this is Experimental
[12:53:04] <Christopher Wood_web_553> +1
[12:53:07] <zulipbot> (Puneet Sood) @_**JabberBot|28** [said](https://zulip-trial1.ietf.org/#narrow/stream/7-jabber/topic/dprive/near/21336):
```quote
Christopher Wood_web_553: The discovery bit is *out of scope*
```
True - but then we are not getting much value by picking up this draft in this WG.
[12:53:09] <Petr Špaček_web_529> @Joey For what definition of "successful"? And what are guarantees that ODoH will be?
[12:53:16] <Éric Vyncke_web_694> AD-sponsored for such a document is kind of weird as it really fits the DPRIVE charter. Selecting AD-sponsorship to go fast is... not the right choice ;-)
[12:53:55] <Tommy Pauly_web_171> @zulip DoH itself didn't have discovery. I think this doesn't need to have discovery to be a useful spec.
[12:54:02] <Eric Orth_web_845> I wouldn't say lack of discovery means Experimental (although I still support Experimental for the other reasons).  DoH is successful right now as non-Experimental without widespread standardized discovery.
[12:54:09] <Andrew Campling_web_728> @Joey: the comment wasn't aimed at Cloudflare, more generally that a limited number of proxies and targets would suggest less resilience  
[12:54:31] Alexander Mayrhofer_web_468 leaves the room
[12:54:36] Alexander Mayrhofer_web_398 joins the room
[12:54:42] <Tommy Pauly_web_171> change control in the WG is good and fine, and implementations would adapt.
[12:54:51] <Paul Hoffman_web_847> +1 to what Ben is saying
[12:54:52] John Mah_web_708 leaves the room
[12:54:57] John Mah_web_987 joins the room
[12:55:26] <Paul Hoffman_web_847> Again, I don't see a reason to delay v1 as experimental by having  it in the WG.
[12:55:41] <Brian Dickson_web_549> Is there a way to cut the baby in half? Get the input in the WG adopt phase, but then as-is at adoption to publish for experimental, similar to v1 of RPZ?
[12:56:02] <Watson Ladd_web_815> What happened to rough consensus and Running Code? you can always roll a bis with lessons learned and improvement
[12:56:11] <Tommy Pauly_web_171> No, not too late at all
[12:56:12] Leif Johansson_web_514 leaves the room
[12:56:12] <Peter van Dijk_web_915> Brian, RPZ never made it to publication
[12:56:14] <Éric Vyncke_web_694> +1
[12:56:17] Leif Johansson_web_611 joins the room
[12:56:25] <Tim Wicinski_web_598> RPZ went indepenent stream
[12:56:29] <Brian Dickson_web_549> Well shame on us then for RPZ... :-/
[12:56:43] Nicklas Pousette_web_396 leaves the room
[12:56:46] Nicklas Pousette_web_240 joins the room
[12:56:48] Tirumaleswar Reddy.K_web_493 leaves the room
[12:56:53] Tirumaleswar Reddy.K_web_793 joins the room
[12:57:11] <Paul Hoffman_web_847> No, shame on the RPZ authors for not turning over editorial control when they said they would.
[12:57:23] Tirumaleswar Reddy.K_web_793 leaves the room
[12:57:24] <dkg> Andrew Campling_web_728: are you concerned about resilience or about centralization?
[12:57:37] Jason Weil_web_191 joins the room
[12:57:40] Tirumaleswar Reddy.K_web_380 joins the room
[12:57:48] Peter Koch_web_798 leaves the room
[12:58:03] <Eric Orth_web_845> I don't think deployment is so widespread yet that we should be too worried about breaking changes.
[12:58:10] <Christopher Wood_web_553> Indeed!
[12:58:11] <Andrew Campling_web_728> @dkg one of the negative effects of centralisation is loss of resilience
[12:59:00] <dkg> so you support adoption so that it's easier for interoperable deployments to be rolled out?
[12:59:13] Jody Kolker_web_298 joins the room
[12:59:30] Brett Carr_web_374 leaves the room
[12:59:35] <Eric Rescorla_web_755> @Andrew Campling: [Citation Needed]
[12:59:51] <dkg> b/c lack of standardization seems to push in the direction of dominance of proprietary deployments
[13:00:15] Jody Kolker_web_298 leaves the room
[13:00:29] Mirja Kühlewind_web_669 leaves the room
[13:00:32] Mirja Kühlewind_web_375 joins the room
[13:00:56] Jody Kolker_web_322 joins the room
[13:01:11] <Ted Hardie_web_245> I agree with Tommy on the scope point; it's a good reason to run the ODoH experiment independently of an OHTTP development effort.
[13:01:29] Samuel Weiler_web_499 leaves the room
[13:01:40] Samuel Weiler_web_721 joins the room
[13:01:47] Burt Kaliski_web_833 leaves the room
[13:01:50] Burt Kaliski_web_801 joins the room
[13:01:54] Simon Hicks_web_447 joins the room
[13:01:56] Linlin Zhou_web_281 leaves the room
[13:02:01] Omer Shapira_web_833 leaves the room
[13:02:02] Luuk Hendriks_web_696 leaves the room
[13:02:06] Luuk Hendriks_web_767 joins the room
[13:02:07] Omer Shapira_web_438 joins the room
[13:02:23] Nicklas Pousette_web_240 leaves the room
[13:02:26] Nicklas Pousette_web_962 joins the room
[13:03:00] <Andrew Campling_web_728> @Ekr: see for example https://datatracker.ietf.org/doc/html/draft-arkko-arch-infrastructure-centralisation-00
[13:03:15] <Joey Salazar_web_995> +1 to David
[13:03:20] <dkg> +1 to david
[13:03:33] <Watson Ladd_web_815> +1 to david
[13:03:45] Frode Sorensen_web_237 leaves the room
[13:03:50] Frode Sorensen_web_317 joins the room
[13:03:59] <Paul Wouters_web_852> just make sure there are authors on the document that are not all single vendor - like for 6962bis. or you might end with newer versions not getting implemented/deployed
[13:04:16] <ekr@jabber.org> yes, I've read it. But there's actually plenty of evidence that centralization increases reliability (Slashdot effect, etc.) I'm not saying centralization is awesome for other reasons, but I think the "loss of resilience" point is much less clear cut than you are saying
[13:04:36] <Erik Nygren_web_519> +1 to Eric's mic comment: there are people who may be willing to particpate in an ODoH ecosystem but not an OHTTP ecosystem
[13:05:03] <ekr@jabber.org> Erik:aren't those the same protocol but with just different ACLs
[13:05:21] <Tommy Pauly_web_171> @Paul W, right--we do have three companies represented already as authors
[13:05:38] <dkg> i'm also not happy about centralization.  but a recent centralization/resilience situation is the OpenPGP SKS keyserver network vs. keys.openpgp.org
[13:05:57] Kirsty Paine_web_674 joins the room
[13:06:07] <dkg> k.o.o is centralized and *significantly* more performant and reliable than the decentralized SKS network
[13:06:09] Tirumaleswar Reddy.K_web_380 leaves the room
[13:06:54] HAIGUANG Wang_web_567 joins the room
[13:06:55] <Watson Ladd_web_815> the SKS issue is a bit more complicated than just centralized vs. decentralized. and a sysadmin having a bad day can be a lot worse in a centralized system.  Learned that myself through bitter experience.
[13:07:20] <dkg> Watson Ladd_web_815: yes, agreed, there is more to the SKS situation than just centralization
[13:07:41] <dkg> but the decentralized nature of SKS also made it harder to fix the other issues with SKS
[13:07:46] Jan Včelák_web_189 leaves the room
[13:08:25] <dkg> anyway, i'm not saying i prefer centralization in general, just that resilience doesn't seem to always align with decentralization
[13:08:34] <ekr@jabber.org> dkg++
[13:08:41] <Paul Hoffman_web_847> BTW, Peter is not going to take 45 minutes, so Ekr will have plenty of time for his slides. Questions after both presentations would be good, given that the two presentations are kinda linked.
[13:09:20] <ekr@jabber.org> Thanks. I am now here.
[13:09:20] Farni Boten_web_480 leaves the room
[13:09:23] Farni Boten_web_276 joins the room
[13:09:40] <Vittorio Bertola_web_453> In a purely abstract discussion, I think centralization is a bet. If the centralized entity is good, you will end up with better service, but if it is not, you risk being locked into a horrible situation. And when it comes to non-technical factors, centralization often implies an aggregation of power / control / money / business interests that tends to make the public interest not a priority.
[13:09:48] Francois Ortolan_web_660 leaves the room
[13:09:53] Francois Ortolan_web_927 joins the room
[13:10:04] <Vittorio Bertola_web_453> But that should perhaps be a separate discussion in another time and place.
[13:10:10] <Watson Ladd_web_815> the competition is a click away. there's no network effect with the proxying
[13:10:38] <dkg> which is why we need standards -- so that the service provided is a commodity, without lock-in
[13:10:43] Linlin Zhou_web_892 joins the room
[13:11:02] <Andrew Campling_web_728> +1 to benefit of standards
[13:11:48] <Petr Špaček_web_529> @Watlson Ladd Not sure I agree. Previous there was talk of browsers deciding for users by default, and we already know how much that encourages centralization. There might be options burried somewhere, but almost nobody is changing defaults anyway.
[13:12:12] <Vittorio Bertola_web_453> @dkg I agree that standardization counters centralization. However standardization is not a guarantee, as dominant providers can just deploy standards in non-interoperable mode (e.g. see the various non-interoperable OAuth/OpenID Connect social media login systems, or the closed IM systems using XMPP for transport).
[13:12:52] <Paul Wouters_web_852> ugh that is not opportunistic :(
[13:12:52] <Brian Dickson_web_549> Polite request, let's now switch to the current presentation for discussion? Other stuff can go on list easily.
[13:13:10] <Paul Wouters_web_852> that is optional encryption against passive attacks only
[13:13:15] Leif Johansson_web_611 leaves the room
[13:13:18] <Paul Hoffman_web_847> @PaulW: right, we are not saying opportunistic any more.
[13:13:40] <ekr@jabber.org> FWIW, what we were saying was "Try all of them (you should) but once you've tried all you are willing to try you fail with error [TBD]".
[13:13:56] Mallory Knodel_web_354 leaves the room
[13:14:07] Omer Shapira_web_438 leaves the room
[13:14:07] <ekr@jabber.org> It's probably SERVFAIL but we just didn't have strong feelings about the precise error code
[13:14:34] <Paul Wouters_web_852> if there is a signal for encrypted transport, you should not fallback by default.
[13:14:46] <ekr@jabber.org> Paul that's what I meant to be saying
[13:14:56] <ekr@jabber.org> Mostly as I'll say
[13:15:18] <dkg> i think strictly boolean signalling is going to make deployment difficult
[13:15:54] Hugo Salgado_web_459 leaves the room
[13:15:55] <Ben Schwartz> I think we need a way for authoritative servers to get some traffic to a new protocol without guaranteeing that protocol's uptime
[13:16:03] <dkg> we want a "report-errors" mode
[13:16:25] <evansr> @PaulW with SVCB if a supported authv protocol is discovered then you should not fallback; if validation is not possible then there's no good answer
[13:16:26] <dkg> (similar to MTA-STS)
[13:16:27] <Peter van Dijk_web_915> @PaulW I have trouble getting used to the RFC definition of Opportunistic so I may have misspoken, we definitely mean 'optional against passive'
[13:16:33] <Brian Dickson_web_549> There are new semantics that classic Do53 was never capable of supporting. E.g. publishing by authoritative with "only offered via TLS, no Do53 support". It would be worth discussing whether that could be supported cleanly, including the signaling for supported transport in the discovery.
[13:16:33] <Paul Wouters_web_852> now we are back at the PIN discussion of tls-dnssec :)
[13:16:43] <Paul Wouters_web_852> we MADE that mechanism :)
[13:17:10] <Paul Wouters_web_852> where you can express commitment to encryption for hard/soft fail
[13:17:47] <Paul Hoffman_web_847> "kind of annoying" ++
[13:18:29] <Brian Dickson_web_549> distinct versions of auth name that have same address, so the NS name plus the whatever mechanism is used for discovery gives that semantic.
[13:18:46] Sean Donelan_web_149 joins the room
[13:19:07] <Watson Ladd_web_815> and maybe the auth name could have the public key for encryption to avoid a round trip /s
[13:19:33] <Brian Dickson_web_549> Common issue for all proposals: requirement to either have encrypted transport to parent, or to have signed protection on NS name or signed protection for whatever is in the parent side.
[13:20:39] Gijs Beernink_web_589 leaves the room
[13:20:44] Gijs Beernink_web_622 joins the room
[13:20:47] <Brian Dickson_web_549> @watson yes, depending on protocol details, assuming discovery for transport is at the name server name's zone, so both the support and keys are served authoritatively.
[13:21:19] Joe Harvey_web_792 leaves the room
[13:21:20] Vladimír Čunát_web_790 leaves the room
[13:21:20] Michael Breuer_web_134 leaves the room
[13:21:25] Joe Harvey_web_360 joins the room
[13:21:25] Michael Breuer_web_327 joins the room
[13:21:27] Vladimír Čunát_web_962 joins the room
[13:21:56] Hugo Kobayashi_web_926 joins the room
[13:21:58] <Brian Dickson_web_549> Another issue that is likely for the "requirements" document: anycast instances are first-class entities, and possibly offer different services for transport differentiated by instance (e.g. some locations do not offer TLS, other locations only offer TLS)
[13:22:06] Jiri Novotny_web_232 leaves the room
[13:22:11] Jiri Novotny_web_783 joins the room
[13:22:16] Corinne Cath_web_428 leaves the room
[13:22:22] Corinne Cath_web_536 joins the room
[13:22:29] Lorenzo Colitti_web_911 joins the room
[13:22:31] <Paul Wouters_web_852> huh?
[13:22:35] <Watson Ladd_web_815> i'm not sure why you'd want to do that
[13:22:39] <Paul Wouters_web_852> datra about the child at the parent isnt DNSSEC signed
[13:22:41] <Paul Wouters_web_852> so this is not true
[13:22:43] <Watson Ladd_web_815> except as a transient state
[13:23:12] <Watson Ladd_web_815> @Brian: I was joking about https://dnscurve.org/ which did not get adopted at all
[13:23:19] <Brian Dickson_web_549> Not want, need. Local requirements from jurisdiction about whether the server can serve DNS over encrypted transport.
[13:23:26] <dkg> Watson Ladd_web_815: if you've got an anycast system and some nodes have different capabilities than other capabilities, then it's not really anycast
[13:23:32] <Brian Dickson_web_549> @watson LOL, didn't catch that.
[13:23:45] <dkg> Watson Ladd_web_815: dnscurve never even tried for IETF adoption
[13:24:07] <Paul Wouters_web_852> thanks ben
[13:24:54] Yahya_web_894 joins the room
[13:25:00] <Paul Wouters_web_852> (my audio is fixed now)
[13:25:09] <Peter van Dijk_web_915> dkg, https://tools.ietf.org/html/draft-dempsky-dnscurve-01
[13:25:31] <Brian Dickson_web_549> @paul what I was trying to say was, the requirements have to include anycast, and the proposed standards have to be compatible with anycast.
[13:25:46] <dkg> Peter van Dijk_web_915: interesting, i stand corrected.
[13:25:48] <Brian Dickson_web_549> (Paul Wouters that is)
[13:25:55] <Peter van Dijk_web_915> dkg, that said, I don't recall how that process went
[13:26:27] <Erik Nygren_web_519> SVCB helps with the anycast topic as you can have different SvcDomainNames for different SVCB records and you just need to make sure any given one of those points to an anycast cloud with homogeneous capabilities.
[13:26:28] Christopher Wood_web_553 leaves the room
[13:26:43] Christopher Wood_web_224 joins the room
[13:27:07] <Paul Hoffman_web_847> Fully disagree with "absolutely no way we can ever get those records in the parent". It will take time, but it could happen.
[13:27:08] <Jim Reid_web_882> +1 to what Paul says about SVCB provisioning at the parent
[13:27:19] <dkg> Jim Reid_web_882: which Paul?
[13:27:37] Joao Damas_web_817 leaves the room
[13:27:38] <Petr Špaček_web_529> +1 as well, basically anything which requires registry involvement is not going to be deployed
[13:28:10] <Ben Schwartz> Petr Špaček_web_529: Anything that doesn't require registry involvement is mostly useless
[13:28:16] <Brian Dickson_web_549> DS is the only option currently, as the NS name is not signed.
[13:28:21] <Erik Nygren_web_519> +1 to Paul : we should design something that can make eventual/opportunistic progress, but with getting this into the parent being a long-term solution as part of the design/plan.
[13:28:27] <Ben Schwartz> We need the registries to deploy or we aren't protecting anything that matters
[13:28:40] <dkg> Brian Dickson_web_549: so a customized abuse of DS ?
[13:28:40] <Brian Dickson_web_549> Overloading DS using new algorithm is a little ugly but works today.
[13:28:57] <Jim Reid_web_882> Paul Wouters. I disagree with Paul-H saying it could happen. Well it could happen - in the same way as universal deployment of DNSSEC or IPv6 could happen.
[13:29:16] <Petr Špaček_web_529> @Ben I'm not arguing with that, but it is what it is now. dprive cannot fix it, dnsop cannot fix it. It's registry business and out of protocol-folks reach.
[13:29:16] <Brian Dickson_web_549> Not abuse, technically a new algorithm. The handling of unsupported algorithms is well defined. Treat unknown as insecure.
[13:29:26] <Paul Wouters_web_852> again, see how we worked around this with CDS/CDNSKEY.     it is just reality
[13:29:26] <Ben Schwartz> Jim Reid_web_882: IPv6 is now over 33% of traffic to Google :)
[13:29:36] <David Lawrence_web_856> I was with the "yes, let's be able to change the parent" right up to "interim measures" .... stretching decades
[13:29:37] <Paul Hoffman_web_847> Folks, can we please let Ekr finish?
[13:29:39] Joao Damas_web_760 joins the room
[13:29:54] <Paul Wouters_web_852> david: exactly
[13:30:30] <Christian Elmerot_web_582> +1 to Paul W point this is the DS deployment model again and CDS/CDNSKEY attemts to fix this but support of that is lacking to say hte least
[13:31:11] <evansr> SVCB at parent is sort of a distraction; it can be resolved in the child/out-of-bailiwick now and start to add value
[13:31:14] <Brian Dickson_web_549> FYI (to EKR and others): DANE includes WebPKI, first 2 flavors of DANE. Recommend against not using DANE.
[13:31:51] <Jonathan Reed_web_380> @Tale: Sure, there's a problem with interim measures, but we could have a flag day to EOL them
[13:31:54] Mirja Kühlewind_web_375 leaves the room
[13:32:13] <Brian Dickson_web_549> @evansr unless parent is available over TLS, that won't work. No secure method of validating child name server and glue address.
[13:32:23] <Paul Wouters_web_852> that service indicator encoded in an extra NS record, and you DO get that signal at the parent
[13:32:36] <dkg> i'm really liking Brian Dickson's suggestion of a custom algorithm ID for DS.  it is ugly, but should be deployable in a lot of places today
[13:33:04] <Erik Nygren_web_519> On the parent vs glue topic, https://tools.ietf.org/html/draft-tapril-ns2-01  which is a similar/parallel proposal also has some considerations and details  (and I'd love to see parts of that merged n here)
[13:33:04] <Peter van Dijk_web_915> dkg, I tested deployability of unknown DS algorithms two years ago - the two resolvers that choked on it have been fixed since :)
[13:33:09] <Paul Wouters_web_852> dkg: i agree but then you require DNSSEC. and some people dont want that
[13:33:19] <evansr> @Brian Dickson correct; it's imperfect but NS DNSSEC signatures at child provide some more security here
[13:33:21] <dkg> Paul Wouters_web_852: why do you require DNSSEC?
[13:33:23] <Brian Dickson_web_549> I've been experimenting with custom alg for DS, some code fixes need in public validator tools to give the right evaluations, but it works.
[13:33:29] <Paul Wouters_web_852> I personally think if you are a modern DNS nameserver, you should be in a domain that dnssec signed :P
[13:33:41] <Jonathan Reed_web_380> @dkg: Doesn't that open the door to folks treating DS as arbitrary bytes to put in the parent?
[13:33:43] <Petr Špaček_web_529> @dkg That was already proposed and shot down in the list: https://datatracker.ietf.org/doc/draft-vandijk-dprive-ds-dot-signal-and-pin/
[13:33:49] <dkg> Peter van Dijk_web_915: thanks for doing that groundwork
[13:33:56] Michael Richardson_web_170 leaves the room
[13:34:05] <Paul Wouters_web_852> dkg: you cant put a new DS in with fake algorithm and expect existing dployments to not fail on that ?
[13:34:14] Tobias Mayer_web_535 leaves the room
[13:34:16] <Peter van Dijk_web_915> Petr, dotpin was shot down for a lot of reasons but several people mentioned that using the DS like that in itself was still interesting
[13:34:23] <Watson Ladd_web_815> but once you reached out the wrong server, that's it. so auth in child lets you know too late
[13:34:23] <Peter van Dijk_web_915> PaulW, yes, I checked
[13:34:23] <Vladimír Čunát_web_962> Well, maybe there was previously more hope that there will be a better way than misusing DS.
[13:34:55] <Paul Wouters_web_852> misusing the NS record :)
[13:34:55] <Petr Špaček_web_529> "Hope" is probably appropriate description :-)
[13:35:01] <Brian Dickson_web_549> @evansr - en passent - you can't get to the desired NS DNSSEC records unless you get the right NS, i.e. not possible if MITM attack model, and no TLS at parent is the situation.
[13:35:02] <Paul Wouters_web_852> it is all awful
[13:35:03] Erik Kline_web_578 joins the room
[13:35:13] <David Lawrence_web_856> computers were clearly a bad idea
[13:35:25] <Paul Wouters_web_852> :)
[13:35:33] <dkg> David Lawrence ++
[13:35:41] Stephan Emile_web_136 joins the room
[13:36:07] Lorenzo Colitti_web_911 leaves the room
[13:37:28] <evansr> @Brian Dickson the NS query reveals some information but allows detection of attack when the child is signed; some future thing would require getting signed information from the parent e.g. if it eventually support TLS then security increases
[13:38:13] <Paul Wouters_web_852> the fallback to plaintext is never needed, you can always just not validate the TLS connection to get the same AND get passive attacker protection
[13:38:33] <Watson Ladd_web_815> if we're using TLS all the way down, the problems with NS records are solved
[13:38:40] <Watson Ladd_web_815> maybe easier than anything else
[13:38:44] <Brian Dickson_web_549> @evansr That assumes the NS is not modified, which is contrary to the attack model. TLS assumption is only valid if EVERY TLD is offering TLS. Not realistic IMHO.
[13:38:44] <Peter van Dijk_web_915> Watson, good luck convincing the root and the big TLDs :)
[13:38:56] <Paul Wouters_web_852> watson: transport security is not data integrity
[13:39:17] Geng-Da Tsai_web_531 joins the room
[13:39:38] <Vladimír Čunát_web_962> We don't need root, I think.
[13:39:39] <Watson Ladd_web_815> no, but it does mean only Alice could change it
[13:39:50] <Paul Wouters_web_852> see tls-dnssec for a comitment PIn where you _can_ express that
[13:39:51] <ekr@jabber.org> Paul: so your position is that if the server advertises TLS and you can't connect to them for some reason (e.g., no common cipher) you should just hard fail
[13:39:54] Geng-Da Tsai_web_531 leaves the room
[13:40:12] <ekr@jabber.org> Even if you don't have any common authentication method?
[13:40:18] Farni Boten_web_276 leaves the room
[13:40:24] <Erik Nygren_web_519> To Ben's question, we could have a SVCB param which says "experimental, only use N% of the time and only if you can fallback if this doesn't work"
[13:40:27] Farni Boten_web_325 joins the room
[13:40:33] <ekr@jabber.org> Erik: I was just thinking this
[13:40:37] Tim Wicinski_web_598 leaves the room
[13:40:38] Yuji Koyama_web_299 leaves the room
[13:40:41] <Paul Wouters_web_852> ekr: I guess. how is that different from https vs http ?
[13:40:42] Tim Wicinski_web_125 joins the room
[13:40:44] Yuji Koyama_web_267 joins the room
[13:40:57] Zaid AlBanna_web_255 leaves the room
[13:40:58] <ekr@jabber.org> Paul: only in the sense that HTTPS implicitly requires WebPKI
[13:41:02] <evansr> @Brian Dickson if the parent has a DS for the child zone then the NS record set for the child zone can be affirmatively validated; the spoofed NS response would be detected
[13:41:03] <dkg> "go ask the child" leaks data for in-bailiwick NS records, right?
[13:41:11] <Paul Wouters_web_852> I'm fine with an "experimental" indicator
[13:41:12] <ekr@jabber.org> As opposed to allowing WebPKI or TLSA
[13:41:24] Farni Boten_web_325 leaves the room
[13:41:25] <Erik Nygren_web_519> Maybe I'm missing something, but doesn't the whole tls-dnssec pin problem go away with this SVCB approach since there is a path to this rather than it being opportunistic?
[13:41:30] <Paul Wouters_web_852> ekr: I mostyl meant, don't drop the TLS connection if you cannot validate, only to go back to cleartext
[13:41:37] <ekr@jabber.org> I agree
[13:41:59] Farni Boten_web_968 joins the room
[13:42:07] David Lawrence_web_856 leaves the room
[13:42:10] <Paul Wouters_web_852> dkg: in bailiwick NS records have no hope
[13:42:11] Francois Ortolan_web_927 leaves the room
[13:42:12] David Lawrence_web_474 joins the room
[13:42:16] Francois Ortolan_web_133 joins the room
[13:42:33] <dkg> Paul Wouters_web_852: that seems a little strong to me.  you mean because of SNI?
[13:42:48] <Paul Wouters_web_852> dkg: even for small nameservers, the gain is low. if you connect with TLS to ns0.nohats.ca, we know you are interested in one of 20 domains
[13:43:01] Jan Včelák_web_654 joins the room
[13:43:13] Francois Ortolan_web_133 leaves the room
[13:43:16] Linlin Zhou_web_892 leaves the room
[13:43:33] <Paul Wouters_web_852> dkg: no because you cannot get any security information about the domain without leaking the domain since its the same info
[13:43:35] <Brian Dickson_web_549> @evansr The DS is for the served zone, not the name server zone, so (a) not necessarily the case, and (b) not the right DS for the actual case.
[13:44:24] <Erik Nygren_web_519> WebPKI for ADoX seems like the wrong direction.  I dislike DNSSEC/DANE for the "Web"/HTTP use-cases but it seems DNSSEC seems like the right approach here.  And doesn't using tls-dnssec mean that you get a full proof without adding additional RTTs, and can't that help with the DNSSEC-signing-of-NS-records issue since it would be in a tls-dnssec chain?
[13:44:24] Linlin Zhou_web_868 joins the room
[13:44:37] <David Schinazi_web_993> We can't hear you DKG
[13:44:39] <ekr@jabber.org> DKG is anoynmous
[13:44:48] <Brian Dickson_web_549> @evansr the use case requirement, I believe, is the name server is in a signed zone, but the actual zone of interest is not required to be in a signed zone.
[13:44:52] <David Schinazi_web_993> Privacy-preserving microphones
[13:45:40] Linlin Zhou_web_868 leaves the room
[13:45:57] <evansr> @Brian if NS for child is sent insecurely (Do53) then DNSSEC validation of NS in the child detects active attacks
[13:46:06] <Paul Hoffman_web_847> There is a new draft being considered by DNSOP for reporting from resolvers to authoritatives.
[13:46:14] <Erik Nygren_web_519> (ah, good point from DKG on the reporting/signalling for fallback.)
[13:46:16] <ekr@jabber.org> Erik: that's a reasonable opinion, but what I'm trying to do here is to get the maximum amount of deployment, and given the amount of DNSSEC deployment so far, I think it's reasonable to think of WebPKI as being easier. That's why I said "why not both"
[13:46:24] <Brian Dickson_web_549> @evansr - do not assume the child is signed.
[13:46:25] <Peter van Dijk_web_915> https://datatracker.ietf.org/doc/draft-arends-dns-error-reporting/
[13:46:37] <ekr@jabber.org> @dkg: good point. yeah, I agree with what you are saying in terms of warn only
[13:46:55] <Paul Wouters_web_852> confused here. the _client_ decides whether to go back to port 53
[13:47:13] <Paul Wouters_web_852> the impact for deployment is the delay on failure
[13:47:18] Willem Toorop_web_690 leaves the room
[13:47:54] <dkg> Paul Wouters_web_852: if signalling implies that you are asking clients to hard fail, no authoritative will want to signal that without feedback first
[13:47:57] <Brian Dickson_web_549> @ekr I think zone DNSSEC is a different deployment rate than nameserver name DNSSEC. I think a hard requirement for nameserver deployment of DNSSEC is reasonable, and that would be then justify making DANE a hard requirement.
[13:48:14] <ekr@jabber.org> @Brian: again, a respectable opinion, but not one share.
[13:48:20] <ekr@jabber.org> one I share
[13:48:26] <Paul Wouters_web_852> dkg: i guess we have different interpretation of hard fail
[13:48:58] <Paul Hoffman_web_847> https://datatracker.ietf.org/doc/draft-arends-dns-error-reporting/
[13:49:12] <Brian Dickson_web_549> @dkg The auth server could make offers of TLS-only, or TLS-or-DO53, and the client could honor that (or not) and hard fail as appropriate. (The TLS-only would be signaled by differentiation by NS names)
[13:49:15] <Paul Wouters_web_852> brian I agree with you, but alas.
[13:49:43] Alessandro Ghedini_web_435 leaves the room
[13:50:08] <Brian Dickson_web_549> DANE with option 1 or 2 (CA or EE with PKI) would be compatible with the WebPKI client, so there is that.
[13:51:13] <evansr> @Brian Dickson if the child is unsigned then _some_ attacks are possible, we can't do anythign about that unless the parent offers TLS and has SVCB in the additional section
[13:51:16] Luigi Iannone_web_996 leaves the room
[13:51:19] Luigi Iannone_web_898 joins the room
[13:51:28] Brad Gorman_web_938 joins the room
[13:52:24] <dkg> we need to make sure that the reporting mechanism we rely on is capable of representing errors associated with encrypted transport
[13:52:31] Brad Gorman_web_938 leaves the room
[13:52:38] <dkg> but yes, +1 for reusing existing reporting mechanisms
[13:53:12] Brad Gorman_web_150 joins the room
[13:53:23] <Brian Dickson_web_549> @evansr if the nameserver is signed, and there is a path to protect the NS of the child, I think that it is possible to protect against those, without requiring the child be signed. The one I am experimenting with is using a new-algorithm DS for the child domain, which encodes the NS set (and is signed), but does not signal/require that the child is actually signed.
[13:54:00] <Paul Wouters_web_852> also please take into account parental SVCB   MITM accounts by nation states :P
[13:54:05] <Peter van Dijk_web_915> Brian, so like Fujiwara's DiS draft?
[13:54:34] <Paul Wouters_web_852> there should be accountability of parent zones
[13:55:20] <dkg> Paul Wouters_web_852: if the signalling mechanism has semantics that allow you to express "DoT or Do53" then that is sufficiently flexible for reporting.  If the signalling mechanism only permits "DoT is available" and that is interpreted by some clients to mean "hard fail" then it is going to be too scary for an authoritative to deploy.
[13:55:42] Stephan Emile_web_136 leaves the room
[13:55:45] <Brian Dickson_web_549> Very similar. Use a dnskey of literally the parental NS set (RDATA for scalability reasons), and the DS being the hash of that. Validation requires a hash, so very performant.
[13:55:53] Malte Granderath_web_481 leaves the room
[13:56:09] Francois Ortolan_web_780 joins the room
[13:56:10] <Paul Wouters_web_852> dkg: like I said, I'm fine with an "experimental" marker, or a tls-dnssec style PIN timer
[13:56:15] <Peter van Dijk_web_915> Brian, yes that works :)
[13:56:22] <Paul Wouters_web_852> just squish it into SVCB
[13:56:52] Avri Doria_web_935 leaves the room
[13:57:08] <Tim Wicinski_web_125> SVCB will become the next TXT
[13:57:24] <Ted Hardie_web_245> @Tim that seems unfortunately likely.
[13:57:25] <Vladimír Čunát_web_962> The presentation format looks similar.
[13:57:42] <Paul Hoffman_web_847> +1 (again) to Ekr
[13:57:46] <Paul Wouters_web_852> ekr: its fine but you really need to drop the SVCB at parent idea.
[13:57:47] Francois Ortolan_web_780 leaves the room
[13:57:48] <evansr> @Brian the NS proof element can come from the parent as you describe OR other sources; my POV is incremental please
[13:57:50] Andreas Pantelopoulos_web_811 leaves the room
[13:58:10] <Brian Dickson_web_549> DS is incremental and backward compatible 100%
[13:58:17] <dkg> TXT became a swamp because many authoritative resolvers were slow to permit publication of novel record types.
[13:58:28] Shumon Huque_web_602 leaves the room
[13:58:30] <Peter van Dijk_web_915> thanks all!
[13:58:30] <Paul Wouters_web_852> brian: DS wont work on insecure zones. you cannot JUST have a non-real DS record
[13:58:30] Joao Damas_web_760 leaves the room
[13:58:30] Ted Hardie_web_245 leaves the room
[13:58:31] <dkg> sounds like DS is going to become a swamp because of parent resolvers refusing to publish different glue
[13:58:32] Kris Shrishak_web_756 leaves the room
[13:58:32] Tara Whalen_web_378 leaves the room
[13:58:32] Marco Davids_web_791 leaves the room
[13:58:33] Hugo Kobayashi_web_926 leaves the room
[13:58:34] Pallavi Aras_web_496 leaves the room
[13:58:34] Lu Zhao_web_678 leaves the room
[13:58:34] Anders Kölligan_web_832 leaves the room
[13:58:35] Eric Orth_web_845 leaves the room
[13:58:35] Eric Rescorla_web_755 leaves the room
[13:58:35] Dan McArdle_web_988 leaves the room
[13:58:35] Éric Vyncke_web_694 leaves the room
[13:58:36] Paul Hoffman_web_847 leaves the room
[13:58:37] Christopher Wood_web_224 leaves the room
[13:58:37] Burt Kaliski_web_801 leaves the room
[13:58:37] Jonathan Reed_web_380 leaves the room
[13:58:38] Doug Stamper_web_847 leaves the room
[13:58:38] Thomas Duffy_web_369 leaves the room
[13:58:38] Robert Story_web_848 leaves the room
[13:58:40] <Peter van Dijk_web_915> PaulW, yes you can - why wouldn't you?
[13:58:40] Trinh Viet Doan_web_988 leaves the room
[13:58:40] Vittorio Bertola_web_453 leaves the room
[13:58:40] Frode Sorensen_web_317 leaves the room
[13:58:41] Watson Ladd_web_815 leaves the room
[13:58:41] Glenn Deen_web_988 leaves the room
[13:58:42] Gianpaolo Scalone_web_795 leaves the room
[13:58:43] Duane Wessels_web_730 leaves the room
[13:58:43] Matt Green_web_305 leaves the room
[13:58:44] Tommy Pauly_web_171 leaves the room
[13:58:44] Eric Kinnear_web_841 leaves the room
[13:58:44] Jonathan Hoyland_web_951 leaves the room
[13:58:45] Jiri Novotny_web_783 leaves the room
[13:58:45] Andrew S_web_835 leaves the room
[13:58:45] Francisco Arias_web_332 leaves the room
[13:58:46] John Mah_web_987 leaves the room
[13:58:46] James Gould_web_499 leaves the room
[13:58:47] Erik Kline_web_578 leaves the room
[13:58:47] Kirsty Paine_web_674 leaves the room
[13:58:47] Scott Hollenbeck_web_431 leaves the room
[13:58:47] Christian Elmerot_web_582 leaves the room
[13:58:48] Lixia Zhang_web_988 leaves the room
[13:58:49] Benjamin Schwartz_web_249 leaves the room
[13:58:51] <Brian Dickson_web_549> New algorithms are ignored if not supported, and if no algorithm that is supported in the set of algorithms for the set of DS records, the result is treat as unsigned.
[13:58:52] Tom Carpay_web_422 leaves the room
[13:58:53] Akira Kato_web_799 leaves the room
[13:58:53] Joe Harvey_web_360 leaves the room
[13:58:55] <Peter van Dijk_web_915> PaulW, as I mentioned earlier, I've done this experiment
[13:58:55] Yoshiro Yoneya_web_591 leaves the room
[13:58:57] <Peter van Dijk_web_915> but i have to go now
[13:58:59] Sean Donelan_web_149 leaves the room
[13:59:00] Sara Dickinson_web_544 leaves the room
[13:59:00] Jim Reid_web_882 leaves the room
[13:59:01] Philipp Tiesel_web_694 leaves the room
[13:59:03] Mike Bishop_web_330 leaves the room
[13:59:03] Hiromu Shiozawa_web_240 leaves the room
[13:59:04] Yuji Koyama_web_267 leaves the room
[13:59:04] Andrew McConachie_web_556 leaves the room
[13:59:05] Andrew Campling_web_728 leaves the room
[13:59:15] Antoin Verschuren_web_552 leaves the room
[13:59:16] Yoshiro Yoneya_ leaves the room
[13:59:19] <Paul Wouters_web_852> peter: because IF a DS is present, resolvers will interpret it to mean there must be at least one working DNSKEY algorithm for DNSSEC
[13:59:19] Takahiro Nemoto_web_862 leaves the room
[13:59:21] <Brian Dickson_web_549> DS is trivial, as EPP and parents do not actually check algorithms
[13:59:26] Nicklas Pousette_web_962 leaves the room
[13:59:27] <Peter van Dijk_web_915> PaulW, no, they don't. I checked :)
[13:59:38] Stephen Farrell_web_993 leaves the room
[13:59:39] Luigi Iannone_web_898 leaves the room
[13:59:41] David Lawrence_web_474 leaves the room
[13:59:42] <dkg> Peter van Dijk_web_915: do you have a writeup of that experiment?
[13:59:45] <Paul Wouters_web_852> that would be a big bug then
[13:59:53] sftcd-pidgin leaves the room
[13:59:56] Jason Weil_web_191 leaves the room
[14:00:04] Linlin Zhou_web_557 joins the room
[14:00:05] Chi-Jiun Su_web_905 leaves the room
[14:00:05] <Brian Dickson_web_549> It is actually a feature, not a bug.
[14:00:06] <Peter van Dijk_web_915> dkg, it's in the dprive archives around IETF prague early 2019.
[14:00:15] <Peter van Dijk_web_915> PaulW, no :)
[14:00:18] <dkg> thanks, i'll dig around and see if i can find it
[14:00:24] David Schinazi_web_993 leaves the room
[14:00:27] <Peter van Dijk_web_915> ok gotta go, peter.van.dijk@powerdns.com if anybody has questions for me
[14:00:33] Peter van Dijk_web_915 leaves the room
[14:00:41] <Paul Wouters_web_852> peter: I'd be interested in the data and RFC text that allows that
[14:00:42] Jan Včelák_web_654 leaves the room
[14:00:51] <Brian Dickson_web_549> Happy to chat on OARC Mattermost too
[14:00:59] Paul Wouters_web_852 leaves the room
[14:01:04] Linlin Zhou_web_557 leaves the room
[14:01:05] Maarten Aertsen_web_272 leaves the room
[14:01:09] Brian Haberman_web_250 leaves the room
[14:01:13] Richard Wilhelm_web_391 leaves the room
[14:01:16] Ben Schwartz leaves the room
[14:01:20] <Brian Dickson_web_549> 403[345] specify that handling, can look up exact sections if you like
[14:01:46] Zaid AlBanna_web_720 joins the room
[14:02:23] Simon Hicks_web_447 leaves the room
[14:02:24] <Petr Špaček_web_529> There is no magic. If all algorithms are "unsupported" then the zone is insecure.
[14:02:44] Zaid AlBanna_web_720 leaves the room
[14:02:50] Yahya_web_894 leaves the room
[14:03:00] Anthony Faust_web_846 leaves the room
[14:03:37] hugo-salgado leaves the room
[14:03:53] Ulrich Wisser_web_319 leaves the room
[14:04:00] Kirsty Paine_web_222 joins the room
[14:04:32] Paolo Saviano_web_338 leaves the room
[14:04:32] George Michaelson_web_513 leaves the room
[14:04:32] Petr Špaček_web_529 leaves the room
[14:04:32] Hiroyuki Goto_web_845 leaves the room
[14:04:32] Steffen Klassert_web_591 leaves the room
[14:04:32] Kazunori Fujiwara_web_370 leaves the room
[14:04:32] Olaf Kolkman_web_511 leaves the room
[14:04:32] Benno Overeinder_web_870 leaves the room
[14:04:32] Joey Salazar_web_995 leaves the room
[14:04:32] Chris Box_web_781 leaves the room
[14:04:32] Patrick Tarpey_web_221 leaves the room
[14:04:32] Ray Bellis_web_967 leaves the room
[14:04:32] Swapneel Sheth_web_143 leaves the room
[14:04:32] Libor Peltan_web_879 leaves the room
[14:04:32] Robert Evans_web_797 leaves the room
[14:04:32] Suzanne Woolf_web_723 leaves the room
[14:04:32] Tommy Jensen_web_652 leaves the room
[14:04:32] Brian Dickson_web_549 leaves the room
[14:04:32] Daniel Gillmor_web_723 leaves the room
[14:04:32] Jiankang Yao_web_666 leaves the room
[14:04:32] Erik Nygren_web_519 leaves the room
[14:04:32] Monika Ermert_web_378 leaves the room
[14:04:32] Vincent Levigneron_web_111 leaves the room
[14:04:32] John Border_web_122 leaves the room
[14:04:32] Puneet Sood_web_251 leaves the room
[14:04:32] Alissa Cooper_web_926 leaves the room
[14:04:32] David Smith_web_807 leaves the room
[14:04:32] Matthew Quick_web_993 leaves the room
[14:04:32] Alexander Mayrhofer_web_398 leaves the room
[14:04:32] Jody Kolker_web_322 leaves the room
[14:04:32] Samuel Weiler_web_721 leaves the room
[14:04:32] Luuk Hendriks_web_767 leaves the room
[14:04:32] HAIGUANG Wang_web_567 leaves the room
[14:04:32] Gijs Beernink_web_622 leaves the room
[14:04:32] Michael Breuer_web_327 leaves the room
[14:04:32] Vladimír Čunát_web_962 leaves the room
[14:04:32] Corinne Cath_web_536 leaves the room
[14:04:32] Tim Wicinski_web_125 leaves the room
[14:04:32] Farni Boten_web_968 leaves the room
[14:04:32] Brad Gorman_web_150 leaves the room
[14:04:32] Kirsty Paine_web_222 leaves the room
[14:06:09] Samuel Weiler leaves the room
[14:11:00] Benno Overeinder leaves the room
[14:20:21] jhoyla leaves the room
[14:26:31] jhoyla joins the room
[14:30:34] mnot leaves the room
[18:07:24] ekr@jabber.org leaves the room
[20:20:49] zulipbot leaves the room: Disconnected: closed
[20:23:06] dkg leaves the room: leaving
[20:24:33] zulipbot joins the room
[20:25:06] zulipbot leaves the room: Disconnected: closed
[20:38:40] zulipbot joins the room
[20:38:57] zulipbot leaves the room: Disconnected: closed
[20:39:00] zulipbot joins the room
[20:39:23] zulipbot leaves the room: Disconnected: closed
[20:39:31] zulipbot joins the room
[20:39:52] zulipbot leaves the room: Disconnected: closed
[20:42:32] zulipbot joins the room
[20:43:36] zulipbot leaves the room: Disconnected: closed
[20:52:04] zulipbot joins the room
[21:28:00] jhoyla leaves the room
[23:02:26] evansr leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!