IETF
dprive@jabber.ietf.org
Thursday, July 29, 2021< ^ >
Yoshiro Yoneya_ has set the subject to: DPRIVE - IETF 110
Room Configuration
Room Occupants

GMT+0
[18:37:43] Meetecho joins the room
[18:45:03] Scott Hollenbeck_web_908 joins the room
[18:45:03] Alessandro Amirante_web_260 joins the room
[18:45:03] Éric Vyncke_web_341 joins the room
[18:45:24] Brian Haberman_web_630 joins the room
[18:45:25] Tim Wicinski_web_441 joins the room
[18:48:02] <Brian Haberman_web_630> /topic DPRIVE - IETF 111
[18:48:41] Andrew Campling_web_149 joins the room
[18:49:04] meetecho-alexamirante joins the room
[18:49:45] meetecho-alexamirante has set the subject to: DPRIVE - IETF 111
[18:50:06] Patrick Tarpey_web_791 joins the room
[18:50:30] Daniel Gillmor_web_760 joins the room
[18:51:06] Nicklas Pousette_web_537 joins the room
[18:51:15] Sara Dickinson_web_341 joins the room
[18:51:32] Zaid AlBanna_web_589 joins the room
[18:51:51] Pallavi Aras_web_463 joins the room
[18:51:52] Ted Hardie_web_609 joins the room
[18:52:44] Nai-Wei Lo_web_129 joins the room
[18:52:49] Yoshiro Yoneya joins the room
[18:53:29] dkg joins the room
[18:54:04] Lucy Lynch_web_425 joins the room
[18:54:09] James Gruessing_web_195 joins the room
[18:54:10] Yoshiro Yoneya_web_417 joins the room
[18:54:22] <Brian Haberman_web_630> So... we get 2*DKG this meeting?? :wink:
[18:54:29] Yoshiro Yoneya_web_417 leaves the room
[18:54:36] Brett Carr_web_271 joins the room
[18:54:40] Shinta Sato_web_423 joins the room
[18:54:41] Duane Wessels_web_458 joins the room
[18:54:42] Matthew Quick_web_139 joins the room
[18:54:51] Yoshiro Yoneya_web_114 joins the room
[18:55:00] <Éric Vyncke_web_341> it happens with dkg logs also in jabber
[18:55:04] Peter Koch_web_126 joins the room
[18:55:14] Frode Sorensen_web_509 joins the room
[18:55:49] Mike Bishop_web_568 joins the room
[18:56:13] Randy Bush_web_669 joins the room
[18:56:16] Paul Wouters_web_444 joins the room
[18:56:17] Geoff Huston_web_412 joins the room
[18:56:23] PE_web_806 joins the room
[18:56:24] <Brian Haberman_web_630> @Eric - yeah, but that is not as much fun as having clones of DKG around.
[18:56:27] Ginny Spicer_web_559 joins the room
[18:56:29] David K_web_670 joins the room
[18:56:32] Peter van Dijk_web_339 joins the room
[18:56:43] PE_web_806 leaves the room
[18:56:50] <Éric Vyncke_web_341> ;-)
[18:57:08] Michael Breuer_web_238 joins the room
[18:57:16] <dkg> if meetecho would let me view the text chat at the same time as viewing the queue and the "voiced" (audio-transmitting) participants, i *might* be willing to just use the webberface
[18:57:26] Lucy Lynch_web_425 leaves the room
[18:57:26] PE_web_200 joins the room
[18:57:41] Alexey Melnikov_web_953 joins the room
[18:57:42] Watson Ladd_web_298 joins the room
[18:57:47] <Meetecho> dkg: you can detach the jabber in a floating window
[18:58:01] Alessandro Ghedini_web_783 joins the room
[18:58:02] Christian Huitema_web_155 joins the room
[18:58:03] <Randy Bush_web_669> and that scrolls better
[18:58:04] James Gould_web_604 joins the room
[18:58:06] Lucy Lynch_web_313 joins the room
[18:58:18] <Andrew Campling_web_149> @dkg It does, go to the Meetecho chat and detach it, then you can view the participant list/queue as well as the chat and don't need Jabber too
[18:58:26] Andrew S_web_747 joins the room
[18:58:33] <dkg> ah, interesting, so i can.  thanks!  see, i knew i would learn something one day from attending these IETF meetings
[18:58:34] Robert Evans_web_435 joins the room
[18:58:35] Gustavo Lozano_web_253 joins the room
[18:58:45] <Mike Bishop_web_568> Yep.  Dual-monitor; left monitor has queue and presentation; right monitor has chat and notes.
[18:58:48] Steve Olshansky_web_444 joins the room
[18:58:54] Benjamin Schwartz_web_266 joins the room
[18:59:02] David Baldassin_web_939 joins the room
[18:59:05] Keith Bare_web_890 joins the room
[18:59:09] Kazunori Fujiwara_web_240 joins the room
[18:59:18] John Border_web_858 joins the room
[18:59:22] Christopher Wood_web_165 joins the room
[18:59:25] Ray Bellis_web_801 joins the room
[18:59:29] evansr joins the room
[18:59:30] Chris Box_web_462 joins the room
[18:59:30] Jorge Cano_web_335 joins the room
[18:59:32] Jeremiah Androscavage_web_929 joins the room
[18:59:33] <Paul Wouters_web_444> no one is talking now ? or is my audio broken? :P
[18:59:37] Allison Mankin_web_169 joins the room
[18:59:40] <Watson Ladd_web_298> time for me to go figure out how to connect this machine to my monitor
[18:59:44] <dkg> the web interface still doesn't let me tab-complete ppl's handles though
[18:59:45] Kris Shrishak_web_570 joins the room
[18:59:50] Wes Hardaker_web_817 joins the room
[18:59:58] Paul Hoffman_web_597 joins the room
[18:59:58] <dkg> Paul Wouters_web_444: i'm not getting any audio either
[19:00:06] <Andrew Campling_web_149> We definitely need a background music mode before sessions start
[19:00:11] <Paul Wouters_web_444> ah good ok it works :P
[19:00:14] David Lawrence_web_386 joins the room
[19:00:16] Francisco Arias_web_107 joins the room
[19:00:32] Tommy Pauly_web_326 joins the room
[19:00:49] Carrick_web_526 joins the room
[19:00:50] Hugo Kobayashi_web_984 joins the room
[19:00:56] Jay Daley_web_218 joins the room
[19:00:58] Shane Kerr_web_622 joins the room
[19:01:03] Eric Orth_web_714 joins the room
[19:01:04] Carrick_web_526 leaves the room
[19:01:07] Richard Wilhelm_web_495 joins the room
[19:01:14] Carrick_web_250 joins the room
[19:01:17] Robert Story_web_799 joins the room
[19:01:17] Alexander Mayrhofer_web_168 joins the room
[19:01:17] <dkg> Andrew Campling_web_149: i guess the chairs get to pick the music?
[19:01:19] David Smith_web_908 joins the room
[19:01:21] Avri Doria_web_523 joins the room
[19:01:31] Korry Luke_web_461 joins the room
[19:01:33] Jonathan Hoyland_web_550 joins the room
[19:01:33] Tim Cappalli_web_767 joins the room
[19:01:36] <Andrew Campling_web_149> Seems fair
[19:01:38] Jonathan Reed_web_774 joins the room
[19:01:48] Tomofumi Okubo_web_696 joins the room
[19:01:48] Joey Salazar_web_111 joins the room
[19:01:49] Vittorio Bertola_web_618 joins the room
[19:01:51] Jasdip Singh_web_286 joins the room
[19:01:53] Vincent Levigneron_web_351 joins the room
[19:02:00] Scott Rose_web_272 joins the room
[19:02:00] <Jonathan Hoyland_web_550> Happy to relay from Jabber
[19:02:05] Shivan Sahib_web_111 joins the room
[19:02:09] Linda Dunbar_web_259 joins the room
[19:02:10] Ralf Weber_web_451 joins the room
[19:02:17] Eric Kinnear_web_326 joins the room
[19:02:20] Mark Andrews_web_362 joins the room
[19:02:21] Puneet Sood_web_240 joins the room
[19:02:22] Rolf Sonneveld_web_358 joins the room
[19:02:23] Marco Davids_web_307 joins the room
[19:02:25] Yuji Koyama_web_214 joins the room
[19:02:38] <Shane Kerr_web_622> I'll take minutes.
[19:02:46] Jason Weil_web_240 joins the room
[19:02:46] Rich Salz_web_993 joins the room
[19:02:52] Hannes Tschofenig_web_189 joins the room
[19:02:52] Carlos Silva_web_382 joins the room
[19:02:57] Pallavi Aras_web_463 leaves the room
[19:02:59] Phillip Hallam-Baker_web_344 joins the room
[19:03:01] Pallavi Aras_web_236 joins the room
[19:03:14] <Tim Wicinski_web_441> thanks shane
[19:03:16] Martin Thomson_web_882 joins the room
[19:03:20] Jiao Kang_web_577 joins the room
[19:03:22] <dkg> i know, i know!
[19:03:24] <dkg> tricky
[19:03:26] Ulrich Wisser_web_637 joins the room
[19:03:37] tale joins the room
[19:03:41] Mirja Kühlewind_web_734 joins the room
[19:03:45] Sean Turner_web_271 joins the room
[19:03:52] Eric Rescorla_web_112 joins the room
[19:04:05] <dkg> thanks, Shane and Ginny!
[19:04:28] <Tim Wicinski_web_441> yes and thanks Ginny
[19:04:47] කෙසර රත්නායක_web_887 joins the room
[19:04:56] Jaime Jimenez_web_118 joins the room
[19:04:56] Stephan Emile_web_738 joins the room
[19:05:12] Frode Kileng_web_560 joins the room
[19:05:25] Korry Luke_web_461 leaves the room
[19:05:29] Korry Luke_web_982 joins the room
[19:05:50] Jason Weil_web_240 leaves the room
[19:05:55] Jason Weil_web_896 joins the room
[19:06:20] frodek joins the room
[19:06:30] Chi-Jiun Su_web_186 joins the room
[19:07:02] Tommy Jensen_web_797 joins the room
[19:07:18] Erik Nygren_web_411 joins the room
[19:08:00] Tim Cappalli_web_767 leaves the room
[19:08:04] ekr@jabber.org joins the room
[19:08:12] <Sean Turner_web_271> Can w hold comments until then?
[19:09:08] <Shane Kerr_web_622> I'm sad to see that QUIC is not over 9000.
[19:09:23] <Carrick_web_250> +1 Shane
[19:09:36] <James Gruessing_web_195> Shane: 9001 defines TLS in QUIC. So technicallly...
[19:10:03] Brian Dickson_web_260 joins the room
[19:10:04] Jim Reid_web_294 joins the room
[19:10:27] <Martin Thomson_web_882> I hope that this only uses a single ALPN
[19:10:33] Shumon Huque_web_922 joins the room
[19:10:34] <Martin Thomson_web_882> (it seems to)
[19:10:38] <Jonathan Hoyland_web_550> Reasonably good chance that XoQ hasn't been used for anything else yet :P
[19:11:15] nygren joins the room
[19:11:31] David Oliver_web_336 joins the room
[19:11:32] Tim Cappalli_web_266 joins the room
[19:11:37] Lucas Pardue_web_147 joins the room
[19:11:55] Tara Whalen_web_745 joins the room
[19:12:10] <Martin Thomson_web_882> 853 is the best choice
[19:12:16] Mirja Kühlewind_web_734 leaves the room
[19:12:26] Mirja Kühlewind_web_699 joins the room
[19:12:35] <Joey Salazar_web_111> why was it that 853 was chosen instead of 443?
[19:12:38] <Martin Thomson_web_882> I say 853 because of the work in TLS on cross-protocol downgrade protection, which will rely on having the same port
[19:12:49] <Allison Mankin_web_169> Joey, 443 may be used too
[19:12:55] <Martin Thomson_web_882> Joey: 443 would work, but it wouldn't give you downgrade protection
[19:13:11] whalen@jabber.org joins the room
[19:13:18] <Martin Thomson_web_882> Allison: are there not a number of DNS cases where you have discovery that only renders a hostname/ip?
[19:13:28] <Paul Wouters_web_444> joey: desire for filtering? :)
[19:13:39] <Joey Salazar_web_111> oh? @Allison it may? I thought the 853 choice put that possibility to the side
[19:14:00] <Mike Bishop_web_568> +1, 853 is reasonable.  443 is usable if you have a reason to coexist with HTTP, but it makes more sense to match the port for DoT.
[19:14:16] <Joey Salazar_web_111> @Paul do you mean "against filtering"? : ))
[19:14:16] Kazuho Oku_web_552 joins the room
[19:14:42] <Paul Wouters_web_444> GLOMAR
[19:15:01] Steffen Klassert_web_947 joins the room
[19:15:04] <Christian Huitema_web_155> It depends on the use case. Using a fixed port makes ADoQ much easier to deploy
[19:15:12] <Rich Salz_web_993> which org was thinking of making DoQ the default for their apps?
[19:15:23] <Jonathan Hoyland_web_550> Not clear that that is likely to remain the case.
[19:15:25] <James Gruessing_web_195> @Rich: AdGuard
[19:15:27] PuneetS joins the room
[19:15:29] <Shivan Sahib_web_111> DoQ sounds like it might be good for DNS resolution in mobile environments
[19:15:31] <Rich Salz_web_993> tnx james
[19:15:46] <Allison Mankin_web_169> Yes to Christian.  But as with DoT, by mutual agreement, client and server may use any port except 53
[19:15:46] <Martin Thomson_web_882> Is there a git repo for this work?  Because I found a pretty obvious bug.
[19:15:51] <nygren> +1 to 853 as that may make management easier for cases like RDoQ and ADoQ.  
[19:16:02] <Peter van Dijk_web_339> Martin, likely - what's the bug? :)
[19:16:15] <Sean Turner_web_271> @mt code?
[19:16:16] <Martin Thomson_web_882> there are three error codes defined, two of them sharing the same value
[19:16:27] <tale > In what way especially, Shivan?
[19:16:27] <Sean Turner_web_271> :)
[19:16:33] <James Gruessing_web_195> MT: https://github.com/saradickinson/dnsoquic
[19:16:38] <Lucas Pardue_web_147> NOT THE ERROR CODES
[19:16:42] <Peter van Dijk_web_339> https://github.com/huitema/
   dnsoquic
[19:16:47] <Christian Huitema_web_155> @martin: https://github.com/huitema/dnsoquic
[19:16:52] <Watson Ladd_web_298> why except 53? UDP disambiguation?
[19:16:57] <James Gruessing_web_195> (ignore my link, clearly wrong)
[19:17:12] Takahiro Nemoto_web_779 joins the room
[19:17:22] <ekr@jabber.org> @Watson: can one unambiguously distinguish QUIC Initials from DNS messages?
[19:17:42] <Watson Ladd_web_298> i don't know enough to know this one
[19:17:45] <Shivan Sahib_web_111> tale: I was thinking connection migration in QUIC
[19:18:03] <Christian Huitema_web_155> For port 53, we would have to worry about reflection attacks
[19:18:04] <ekr@jabber.org> I think you *can* distinguish QUIC from !QUIC, but you don't want to process QUIC initials as if they were DNS
[19:18:32] fightingnemo joins the room
[19:18:32] <Allison Mankin_web_169> @watson - yes disambiguation from DNS over UDP
[19:19:28] <Sean Turner_web_271> just - yes
[19:20:51] <Hannes Tschofenig_web_189> PoC: What Quic library are you using?
[19:20:52] <Jonathan Hoyland_web_550> Perhaps an implementer who hasn't implemented Zone Transfer over TLS.
[19:21:01] <Allison Mankin_web_169> Shane, the separateness of XFR docs could be seen as an accident of history.
[19:21:27] <Martin Thomson_web_882> It seems to me that this document needs some editorial work, based on my reading thus far.
[19:21:29] <Sean Turner_web_271> @am :)
[19:21:41] <Benjamin Schwartz_web_266> The existence of XoQ also helps to motivate the length field in the general syntax.
[19:22:02] <Sean Turner_web_271> @mt - yes, but on the right track\
[19:22:23] Kazuho Oku_web_552 leaves the room
[19:22:31] Tomofumi Okubo_web_696 leaves the room
[19:22:37] Tomofumi Okubo_web_479 joins the room
[19:22:48] <Martin Thomson_web_882> Sean Turner: absolutely, this looks like the right shape
[19:22:51] <Christian Huitema_web_155> @mt - more feedback would definitely help!
[19:22:54] <Watson Ladd_web_298> PRs are so much easier than emails for little editorial things. aim us at the repo
[19:23:09] Jiao Kang_web_577 leaves the room
[19:23:53] <Rich Salz_web_993> does 'unauthenticated' mean like opportunistic, and not in comparison to authenticated ciphers like AESGCM?
[19:24:16] <ekr@jabber.org> correct
[19:24:22] Carrick_web_250 leaves the room
[19:24:23] <Paul Wouters_web_444> the word opportunistic was avoided on purpose. because of how IETF ended up defining the term
[19:24:32] <Martin Thomson_web_882> Christian: expect a few issues to be opened
[19:24:34] <ekr@jabber.org> but close enough
[19:24:53] James Galvin_web_484 joins the room
[19:25:49] <Chris Box_web_462> Agree DoQ is the future
[19:26:00] James Galvin_web_484 leaves the room
[19:26:38] Linda Dunbar_web_259 leaves the room
[19:26:59] David Oran_web_651 joins the room
[19:27:23] Linda Dunbar_web_691 joins the room
[19:28:04] <Rich Salz_web_993> @Paul: So it differs from SMTP "opportunistic" in which way?  Or shoudl I just read the draft?
[19:29:07] Dan Wing_web_722 joins the room
[19:30:50] <Geoff Huston_web_412> @ Paul - :-)
[19:31:15] <Geoff Huston_web_412> @Paul - we are doing the Yin and Yang dance - right?
[19:31:18] <dkg> Paul, are you saying that if there's an authentication failure it should fall back to cleartext?
[19:31:20] <ekr@jabber.org> FWIW, I agree with Paul Wouters on this topic. If this document is to go forward, it should be Experimental
[19:31:37] <ekr@jabber.org> @dkg: I would say that it should fall back to failure
[19:32:01] <dkg> so, no DNS at all if the authoritative server doesn't offer DoQ?
[19:32:34] <ekr@jabber.org> Well, in our version: no DNS at all if the reference you got to the authoritative server tells you it supports DoX but you can't negotiate it
[19:32:53] <nygren> I agree with Paul Wouters as well.  I worry that doing this as anything other than experimental will make it harder for us to roll out actual authenticated and will result in more failure modes and confusion.
[19:33:01] <Andrew Campling_web_149> Failing closed would be surprising
[19:33:27] <ekr@jabber.org> I don't see why. Failing closed when someone gives you an https:// URL and you can't connect to it, that fails
[19:33:39] <Brett Carr_web_271> I think there is value in this draft as authenticted will take a long time to complete this gives people something ppl to cut their teeth on.
[19:33:40] Viktor Dukhovni_web_247 joins the room
[19:33:51] <Paul Wouters_web_444> and likely an ACME based cert :)
[19:34:13] <Christian Huitema_web_155> Building a dependency of DNS on Let's encrypt. What can possibly go wrong?
[19:34:17] <dkg> i think managers of Authoritative Servers will be scared to signal that they offer DoQ if it means that their entire zone breaks when they screw it up
[19:34:18] James Galvin_web_841 joins the room
[19:34:30] <ekr@jabber.org> @dkg: well, that's certainly possible.
[19:34:32] <Ray Bellis_web_801> @Christian urk!
[19:34:32] <dkg> people are going to want to deploy without risking breakage
[19:34:40] <dkg> this seems like it lets us do that
[19:34:49] <Jonathan Hoyland_web_550> Just to +1 Watson, without having followed the mailing list this whole discussion is pretty mysterious.
[19:34:50] <Paul Wouters_web_444> dkg: if transport fails, fallback to classic DNS ?
[19:34:55] David Schinazi_web_813 joins the room
[19:34:57] <ekr@jabber.org> FWIW, the ADoX draft includes a mechanism for signaling "you should expect to be able to use TLS but you might not be able to authenticate"
[19:35:11] Jason Weil_web_896 leaves the room
[19:35:11] <dkg> Paul: why bother?  why not keep the unauthenticated link?
[19:35:18] <ekr@jabber.org> (by signaling "I only support some method of authentication you have never heard of")
[19:35:19] Jason Weil_web_111 joins the room
[19:35:22] <tale > dkg that's pretty much what happens with adding security to insecure things.   valid uses sometimes fail when they would have otherwise succeeded.    sad, but a balance.
[19:35:28] <Watson Ladd_web_298> I think its easy to add one more bit to say expect working X509 or not
[19:35:39] <ekr@jabber.org> Watson: this is the topic of the next set of talks
[19:35:47] <Paul Wouters_web_444> dkg: might be different servers/ports/loadbalancer etc. it might be a whole different infrastructure
[19:35:53] <Andrew Campling_web_149> What discussion has there been with managers of Authoritative Servers about this and the Authenticated proposal?
[19:35:56] Mirja Kühlewind_web_699 leaves the room
[19:35:58] <ekr@jabber.org> But approximately, the question is "how does the recursive know to expect authentication
[19:36:09] <ekr@jabber.org> @Andrew: Well, Robert Evans (Google) has been working with us on ADoX.
[19:36:11] <Paul Wouters_web_444> and should it hard fail or not :)
[19:36:18] Pallavi Aras_web_236 leaves the room
[19:36:25] <ekr@jabber.org> And you'll also note that Cloudflare runs an authoritative.
[19:36:29] <Watson Ladd_web_298> I don't think the next set of talks is necessarily about this. it's about locating the record and this assumes you can
[19:36:50] <Christian Huitema_web_155> I am very worried about X.509 here. In practice, it means something like let's encrypt, which pretty much relies on DNS for asserting ownership of the name. So we would have a circular dependency.
[19:37:09] <Jonathan Hoyland_web_550> Do you think anything unusual like an IP cert here?
[19:37:12] <ekr@jabber.org> Christian: well, I don't really agree, but at least our draft is agnostic on it
[19:37:17] <Paul Wouters_web_444> christian: watch all the ships that have sailed :)
[19:37:20] <Ray Bellis_web_801> and who needs the CA Forum involved with DNS...?
[19:37:33] Jason Weil_web_111 leaves the room
[19:37:33] <ekr@jabber.org> CABF would not be involved here.
[19:37:35] <Peter van Dijk_web_339> Watson, the problem is locating the record and knowing it is correct. We have chosen not to solve that. And it is unsolved - that's why another hour of agenda has been reserved for it.
[19:37:40] <dkg> Christian Huitema_web_155: arguably, the DNSSEC chain extension will be published shortly
[19:37:44] <Geoff Huston_web_412> @Ray: +1
[19:37:44] <Paul Wouters_web_444> also, we have tls-dnssec-chain to help people :)
[19:37:50] <Ray Bellis_web_801> @ekr that's a relief...
[19:37:53] Jason Weil_web_844 joins the room
[19:37:59] <Brett Carr_web_271> As an auth operator we would have a lot of doubts/worry about deployign something on our servers that relied on x509
[19:38:00] <Watson Ladd_web_298> but then this draft is both auth and unauth: add the bit
[19:38:00] halfshot leaves the room
[19:38:00] cjsu leaves the room
[19:38:00] Vittorio Bertola leaves the room
[19:38:00] zyxbac leaves the room
[19:38:04] zyxbac joins the room
[19:38:04] halfshot joins the room
[19:38:04] cjsu joins the room
[19:38:04] Vittorio Bertola joins the room
[19:38:10] Carrick_web_275 joins the room
[19:38:10] Mark Kosters_web_542 joins the room
[19:38:48] <ekr@jabber.org> I would really encourage people to read the relevant sections of https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.html
[19:39:05] <Jonathan Hoyland_web_550> :eyes:
[19:39:14] Benno Overeinder_web_652 joins the room
[19:39:20] <ekr@jabber.org> Which you may not like, but represent what it is we are proposing
[19:39:52] <dkg> ekr@jabber.org: you mean "[[OPEN ISSUE: figure out error details]]"
[19:39:59] <ekr@jabber.org> LOLOL
[19:40:04] <ekr@jabber.org> That part is also amazing, but no.
[19:40:12] <Watson Ladd_web_298> I'm not sure how that's different from this draft? same record, same meaning, only difference is what you do
[19:40:12] <dkg> i mean, that's what we're talking about
[19:40:14] <ekr@jabber.org> That just meant "figure out exactly what error to send"
[19:40:17] <Christian Huitema_web_155> If client both X.509 and Dane, we have fewer risk of breakage. But we need to at least allow Dane, because otherwise it gets very hard to renew an expired X.509 cert
[19:40:21] <ekr@jabber.org> We already say to hard fail
[19:40:23] Jason Weil_web_844 leaves the room
[19:40:27] Benjamin Schwartz_web_266 has to leave.  Have fun y'all.
[19:40:29] Jason Weil_web_228 joins the room
[19:40:32] <Peter van Dijk_web_339> Watson, same record, different meaning, different -source-
[19:40:36] Benjamin Schwartz_web_266 leaves the room
[19:40:40] <Peter van Dijk_web_339> but, I'll stop now, all of this is coming up later
[19:41:00] <Watson Ladd_web_298> that's an optimization
[19:41:05] <Watson Ladd_web_298> like glue
[19:41:08] <dkg> so the only way to deploy on the authoritative side is to risk breaking the zone :(
[19:41:16] <Peter van Dijk_web_339> Watson, the next hour -is about glue-
[19:41:21] <Watson Ladd_web_298> right
[19:41:33] Burt Kaliski_web_445 joins the room
[19:41:33] <Peter van Dijk_web_339> or, as some might say, other parent side data that is not glue, but that's semantics
[19:41:42] <Peter van Dijk_web_339> it certainly smells like glue (don't smell the glue)
[19:41:56] <Watson Ladd_web_298> but given that next hour, why is this draft not the mechanism beyond the record, and we assume the next hour something like this is here. which I think is what Paul and Ben agreed on
[19:42:04] <Paul Wouters_web_444> note they technically did not say it is glue or a record that lives authoritatively on the other side of the zone cut - but i do think they mean it as glue
[19:42:26] <Scott Hollenbeck_web_908> @dkg: that's precisely why some authoritative name servers operators have reservations about such proposals
[19:42:31] <Paul Wouters_web_444> (see also dnops glue-is-not-optional discussion)
[19:42:54] <Christian Huitema_web_155> +1 EKR. Most QUIC stack will require a valid credential, or fail the connection. So DoQ will mostly not work in the absence of credential.
[19:43:12] <Watson Ladd_web_298> yeah, otherwise in-baliwick NS breaks
[19:43:31] Nigel Hickson_web_580 joins the room
[19:43:34] <Paul Wouters_web_444> in-baliwick privacy is not possible anyway :)
[19:43:51] <Peter van Dijk_web_339> sure it is ;)
[19:44:05] Enock Mbewe_web_345 joins the room
[19:44:23] <Paul Wouters_web_444> sure, no one will know what nameserer or zones live on 193.110.157.101 anyway? :)
[19:44:33] <Hannes Tschofenig_web_189> @Christian: Many TLS stacks allow you to disable certificate checking. That's what the ANIMA guys are doing to get BRISKI to work
[19:44:41] <Peter van Dijk_web_339> PaulW, that's a different claim
[19:44:42] <Martin Thomson_web_882> if you try TLS, get TLS, but can't authenticate the server, what do you do?  use TLS anyway?  use UDP?  abort because it's an attack?
[19:44:58] John Border_web_858 leaves the room
[19:45:00] <Ted Hardie_web_609> This says, use TLS anyway.
[19:45:03] <Ray Bellis_web_801> use DNSSEC, and if the answer's right, who cares?
[19:45:23] <Watson Ladd_web_298> if we had keys in the SVBC record...
[19:45:26] John Border_web_564 joins the room
[19:45:34] <Paul Wouters_web_444> ray: if you send nqame before auth, you lost the privacy
[19:45:35] <Watson Ladd_web_298> someone decided to put keys in the NS record one time
[19:45:39] <Brett Carr_web_271> if you fall back to normal dns you might as well just use TLS at least you havw the encryption
[19:45:40] Lixia Zhang_web_229 joins the room
[19:46:10] <Paul Wouters_web_444> watson: you will never believe what is proposed in one of the  next presentations
[19:46:31] <dkg> that makes sense to me
[19:46:34] <Brett Carr_web_271> best - Auth TLS middle Non Auth DNS worst PODNS
[19:46:39] <Paul Wouters_web_444> remember it only works for single domains and without caches. djb was wrong :)
[19:47:13] <ekr@jabber.org> So to recap what I was saying before, which is potentially dumb:
[19:47:15] <Martin Thomson_web_882> one of the things we did with ECH was that if you got a valid record saying that ECH was available you would then fail hard.  Same might apply here: if you get a signal that authentication is available, perhaps you could fixate on that
[19:47:22] <ekr@jabber.org> SVCB ==> Expect authenticated TLS
[19:47:23] Hannes Tschofenig_web_189 leaves the room
[19:47:28] David Lawrence_web_386 leaves the room
[19:47:29] <Martin Thomson_web_882> right
[19:47:32] David Lawrence_web_188 joins the room
[19:47:33] <ekr@jabber.org> The current draft won't have signaling in the parent, so there's no strong way to get there.
[19:47:55] Ali Hussain_web_909 joins the room
[19:48:01] <ekr@jabber.org> You should feel free to connect to the server with DoT/DoQ and see what happens (without using authentication, because you might as well fall back to unauthenticated rather than Do53).
[19:48:14] <ekr@jabber.org> And then if you *get* SVCB, that switches you to auth mode.
[19:48:26] <ekr@jabber.org> If you really squint, this is vaguely like HSTS
[19:48:38] <Paul Wouters_web_444> ekr: if you give up on in-baliwick privacy, that is not a big deal. eg you connecting to ns1.dreamhost.com won't leak that much info as compared to going to their IP anyway
[19:50:34] <tale > New plan: thwart this whole framework so that I stop the fact that I get email at all.
[19:50:34] whalen@jabber.org leaves the room
[19:50:43] <Rich Salz_web_993> +1 tale.
[19:50:51] <Watson Ladd_web_298> connecting yes, but intercepting the contents would be bad
[19:51:24] <Andrew Campling_web_149> New WG charter to deprive Tale of email?
[19:51:27] <Paul Wouters_web_444> maybe add a slack transport to SVCB :)
[19:51:46] <tale > BoF of 1 says yes
[19:51:51] Ralf Weber_web_451 leaves the room
[19:52:20] <ekr@jabber.org> I'm not really excited about having this tied to DNSSEC
[19:52:22] Ralf Weber_web_661 joins the room
[19:52:33] whalen@jabber.org joins the room
[19:52:36] <nygren> the HTTPS instantiation of SVCB does behave somewhat HSTS-like...  (in that it forces up to HTTPS)
[19:52:38] <tale > When your other option is CAs?
[19:52:40] <Viktor Dukhovni_web_247> The DANE PKIX use cases don't make sense here...
[19:52:52] <Paul Wouters_web_444> ekr: you can use DS without dnssec in child
[19:53:02] <Paul Wouters_web_444> (for signaling)
[19:53:06] <Watson Ladd_web_298> and we're going around it again next presentations!
[19:54:40] <Viktor Dukhovni_web_247> TLSRPT is NOT MTA-STS-specific, it equally applies to DANE.
[19:54:46] Francisco Arias_web_107 leaves the room
[19:54:52] <Paul Wouters_web_444> that's why you keep port 53
[19:55:03] <Paul Wouters_web_444> (in re: dkg)
[19:55:11] Nai-Wei Lo_web_129 leaves the room
[19:55:38] Nai-Wei Lo_web_813 joins the room
[19:55:56] <Paul Wouters_web_444> you cant protect in-baliwick..... you are going to connect to the IP you got (via encrypted and /or authenticated)
[19:56:00] <evansr> auth has enough open questions that it should stay out of draft-ietf-dprive-unauth-to-authoritative; when it's settled another draft can add the auth probing & resolvers that want to authenticate can detect using that signal
[19:56:44] <Martin Thomson_web_882> not true Christian
[19:56:46] Ali Hussain_web_909 leaves the room
[19:56:48] <Viktor Dukhovni_web_247> OpenSSL does not require a server name for DANE.
[19:56:53] <Martin Thomson_web_882> you can use IP addresses
[19:57:04] Jay Daley_web_218 leaves the room
[19:57:27] <Viktor Dukhovni_web_247> That said, you need a server name to find the TLSA RRs.
[19:57:39] <Mike Bishop_web_568> Not sure about QUIC, but most TLS stacks I've interacted with allow you to manually validate the certificate.  Isn't that typical?
[19:57:45] <Watson Ladd_web_298> if we're using the SVCB record might have issue with next
[19:57:46] <Peter van Dijk_web_339> Mike, that is typical
[19:58:07] <Viktor Dukhovni_web_247> OpenSSL in unauthenticated by default, and widely used.
[19:58:18] <Viktor Dukhovni_web_247> It is trivial to not check the server name.
[19:58:25] <Watson Ladd_web_298> and that's a problem
[19:58:41] <Martin Thomson_web_882> It is too trivial not to check the server name.  But some stacks (rustls) are much better.
[19:58:46] Burt Kaliski_web_445 leaves the room
[19:58:48] <Paul Wouters_web_444> administrivia: the chairs after me said, this doc needs to continue. we then had 30 mins of discussion on people having a lot of doubt on this
[19:58:53] <Viktor Dukhovni_web_247> Yes, it would be nice to be authenticated by default, but backwards compat is a barrier...
[19:58:58] James Gould_web_604 leaves the room
[19:59:01] Avri Doria_web_523 leaves the room
[19:59:10] <Martin Thomson_web_882> You can use rustls without proper authentication, but it is somewhat tricky.
[19:59:17] Jaime Jimenez_web_118 leaves the room
[19:59:26] Patrick Tarpey_web_791 leaves the room
[19:59:52] <Paul Wouters_web_444> doesnt python mostly do tls without authentication per default? :)
[19:59:57] <Viktor Dukhovni_web_247> Anyway, it is not difficult to add support for DANE to a stack, if the use-cases are compelling.
[20:00:03] Eric Rescorla_web_112 leaves the room
[20:00:03] <Christian Huitema_web_155> Tricky means there will be bugs, which I would rather avoid.
[20:00:10] Scott Hollenbeck_web_908 leaves the room
[20:00:11] Kris Shrishak_web_570 leaves the room
[20:00:14] Rich Salz_web_993 leaves the room
[20:00:15] Linda Dunbar_web_691 leaves the room
[20:00:15] Steve Olshansky_web_444 leaves the room
[20:00:16] Christopher Wood_web_165 leaves the room
[20:00:16] Rolf Sonneveld_web_358 leaves the room
[20:00:17] Jonathan Reed_web_774 leaves the room
[20:00:18] Marco Davids_web_307 leaves the room
[20:00:18] Sara Dickinson_web_341 leaves the room
[20:00:18] Shumon Huque_web_922 leaves the room
[20:00:19] Jeremiah Androscavage_web_929 leaves the room
[20:00:19] Tara Whalen_web_745 leaves the room
[20:00:20] Geoff Huston_web_412 leaves the room
[20:00:20] Chi-Jiun Su_web_186 leaves the room
[20:00:20] Joey Salazar_web_111 leaves the room
[20:00:20] Watson Ladd_web_298 leaves the room
[20:00:21] Gustavo Lozano_web_253 leaves the room
[20:00:21] කෙසර රත්නායක_web_887 leaves the room
[20:00:23] Zaid AlBanna_web_589 leaves the room
[20:00:23] Vittorio Bertola_web_618 leaves the room
[20:00:24] Tomofumi Okubo_web_479 leaves the room
[20:00:25] Randy Bush_web_669 leaves the room
[20:00:25] John Border_web_564 leaves the room
[20:00:25] Shivan Sahib_web_111 leaves the room
[20:00:25] Mark Andrews_web_362 leaves the room
[20:00:26] Frode Sorensen_web_509 leaves the room
[20:00:26] Nai-Wei Lo_web_813 leaves the room
[20:00:26] Christian Huitema_web_155 leaves the room
[20:00:26] James Gruessing_web_195 leaves the room
[20:00:26] PE_web_200 leaves the room
[20:00:26] David Oliver_web_336 leaves the room
[20:00:26] Richard Wilhelm_web_495 leaves the room
[20:00:28] Lucy Lynch_web_313 leaves the room
[20:00:28] Jim Reid_web_294 leaves the room
[20:00:28] Alessandro Ghedini_web_783 leaves the room
[20:00:29] Shane Kerr_web_622 leaves the room
[20:00:29] Mike Bishop_web_568 leaves the room
[20:00:31] David Baldassin_web_939 leaves the room
[20:00:31] Tim Wicinski_web_441 leaves the room
[20:00:32] Brian Haberman_web_630 leaves the room
[20:00:32] Yoshiro Yoneya_web_114 leaves the room
[20:00:34] Lixia Zhang_web_229 leaves the room
[20:00:34] Carrick_web_275 leaves the room
[20:00:34] Andrew Campling_web_149 leaves the room
[20:00:35] Duane Wessels_web_458 leaves the room
[20:00:35] Nigel Hickson_web_580 leaves the room
[20:00:35] Scott Rose_web_272 leaves the room
[20:00:36] Andrew S_web_747 leaves the room
[20:00:38] Éric Vyncke_web_341 leaves the room
[20:00:39] Steffen Klassert_web_947 leaves the room
[20:00:41] Yuji Koyama_web_214 leaves the room
[20:00:42] Robert Story_web_799 leaves the room
[20:00:49] Keith Bare_web_890 leaves the room
[20:00:53] Alexey Melnikov_web_953 leaves the room
[20:00:56] Tommy Pauly_web_326 leaves the room
[20:00:59] James Galvin_web_841 leaves the room
[20:01:00] David Schinazi_web_813 leaves the room
[20:01:01] Kazunori Fujiwara_web_240 leaves the room
[20:01:03] Puneet Sood_web_240 leaves the room
[20:01:07] James Galvin_web_725 joins the room
[20:01:09] Robert Evans_web_435 leaves the room
[20:01:11] James Galvin_web_725 leaves the room
[20:01:14] Ginny Spicer_web_559 leaves the room
[20:01:17] Sean Turner_web_271 leaves the room
[20:01:28] Martin Thomson_web_882 leaves the room
[20:01:28] <Viktor Dukhovni_web_247> Limitations in current stacks are not a compelling reason to conclude that it will not be possible in a DNS resolver to find a way to authenticate the peer in a non-default manner.
[20:01:33] Nicklas Pousette_web_537 leaves the room
[20:01:41] Jason Weil_web_228 leaves the room
[20:01:42] Allison Mankin_web_169 leaves the room
[20:01:57] Korry Luke_web_982 leaves the room
[20:02:02] Shinta Sato_web_423 leaves the room
[20:02:03] <Peter van Dijk_web_339> +1 on that
[20:02:06] Takahiro Nemoto_web_779 leaves the room
[20:02:06] Mark Kosters_web_542 leaves the room
[20:02:23] George Michaelson_web_667 joins the room
[20:02:32] <Paul Wouters_web_444> viktor: right, so auth and unauth would use the same encrypted transport, just leaves the question of auth or not at the end. which turns it into a softfail or hardfail question
[20:02:40] <Viktor Dukhovni_web_247> Many are using OpenSSL anyway, but if not, they could choose an alternative chain verification mechanism, and the stacks can be updated to add support, ...  Resolvers are specialised software, and can use up to date stacks to implement bleeding edge features.
[20:02:55] <Peter van Dijk_web_339> -1 on that, though
[20:03:07] <Peter van Dijk_web_339> I'm not the TLS vendor and I do not want to be
[20:03:11] Lucas Pardue_web_147 leaves the room
[20:03:19] <Peter van Dijk_web_339> although for DoQ I might have to be for a few years
[20:03:20] <dkg> we've designed this kind of piecemeal upgrade at least twice in the past: HSTS and MTA-STS
[20:03:21] <Paul Wouters_web_444> resolvers are not up to date specialised software
[20:03:32] Eric Kinnear_web_326 leaves the room
[20:03:54] Chris Box_web_462 leaves the room
[20:04:04] <Viktor Dukhovni_web_247> If they are looking to implement aDOT, they're definitely bleeding edge.
[20:04:12] <Paul Wouters_web_444> dkg: that was before ubiquitous TLS
[20:04:21] <Peter van Dijk_web_339> most of our customer deployments are fresh PowerDNS on RHEL7
[20:04:25] Frode Kileng_web_560 leaves the room
[20:04:28] <Peter van Dijk_web_339> where we don't ship openssl - RedHat does
[20:04:28] Peter Koch_web_126 leaves the room
[20:04:31] Frode Kileng_web_371 joins the room
[20:04:32] <dkg> we're before ubiquitous TLS in the authoritative DNS space too
[20:04:49] <Viktor Dukhovni_web_247> OpenSSL 1.1.0 and up has all the requisite hooks.
[20:05:13] Frode Kileng_web_371 leaves the room
[20:05:14] <Paul Wouters_web_444> dkg: but not before ubiquitous authentication is easy
[20:05:23] Ching-Heng Ku_web_653 joins the room
[20:05:28] <Viktor Dukhovni_web_247> Even in 1.0.2 one can take control of X.509 chain construction with a bit more effort.  I have a standalone DANE library for 1.0.2, that's used in Exim.
[20:05:31] <Paul Wouters_web_444> pick TLSA or webpki. at least one will work
[20:05:47] <dkg> ubiquitous authentication is still not easy, and the consequences for failure for the authoritative nameserver is even worse than the failure of your https endpoint
[20:06:08] <Viktor Dukhovni_web_247> If the signalling to use or not use authentication is in DNS, then WebPKI is silly.
[20:06:12] <Paul Wouters_web_444> dkg: the consequence is at most "no privacy while doing port 53 fallback"
[20:06:29] <dkg> Paul Wouters_web_444: why would that be the consequence?  why bother falling back to port 53?
[20:06:39] Ching-Heng Ku_web_653 leaves the room
[20:07:00] <dkg> Viktor Dukhovni_web_247: i agree with you that dragging the WebPKI into this is silly, but key management is still hard
[20:07:01] <Paul Wouters_web_444> viktor: yes i agree, but i spent my energy on that too many times already
[20:07:09] <Viktor Dukhovni_web_247> The security of the system then depends on DNS security, so might as well use DNS security, without adding more fragile components and redundant trusted parties.
[20:07:34] <Paul Wouters_web_444> dkg: because the encrypted transport is likely a _seperate_ infra from classic port 53, and it that infra fails, you really want to go back to trusted safe mode
[20:07:39] <dkg> viktor, i agree, but that's still going to make people gun-shy about deploying encryption at the authoritative.
[20:07:52] <Viktor Dukhovni_web_247> The reason why WebPKI works for the Web is that the signal to use TLS is in the "httos://" scheme in the URL, so is fixed prior to communication.
[20:08:33] <Paul Wouters_web_444> I tried to make TLSA presence do that too but two PKIX people got worried they were being obsoleted 10 years ago :P
[20:08:41] <Paul Wouters_web_444> I'm glad you made it happen for SMTP
[20:08:49] Daniel Gillmor_web_760 leaves the room
[20:09:05] <Viktor Dukhovni_web_247> Once authentication is signalled separately, and in particular via DNS, authentication is fundamentally reliant on DNS... This covered in Section 1.3 of RFC 7672.
[20:09:57] <Viktor Dukhovni_web_247> The MTA-STS kludge is thankfully not viable for aDOT.
[20:10:21] Paul Wouters_web_444 leaves the room
[20:10:50] Ulrich Wisser_web_637 leaves the room
[20:11:15] <dkg> look, we need four things: (1) at least one well-understood, probeable encrypted transport that folks can agree on,  (2) a reporting mechanism so that operators of authoritative servers can gather evidence of breakage without the entire zone failing, (3) an authentication mechanism that folks can agree on, and (4) a signalling mechanism to indicate softfail vs. hardfail
[20:11:16] <Viktor Dukhovni_web_247> Also, I would not want to trust all the national WebPKI trust anchors for my DNS privacy except unavoidably when visiting domains in their ccTLD.
[20:11:26] Ted Hardie_web_609 leaves the room
[20:12:37] <Viktor Dukhovni_web_247> @dkg, yes we can take lessons learned from DANE SMTP and MTA-STS and do something that's at least as good as both, and likely with in-band signalling of errors from resolver to server, rather than a daily report after 24 hours of down time...
[20:13:14] <Viktor Dukhovni_web_247> SMTP mail may queue and ultimately be delivered some hours or days later, with modest impact, but for DNS the error channel needs to be real-time.
[20:13:22] <Viktor Dukhovni_web_247> So TLSRPT is not fit for purpose.
[20:13:46] <dkg> this gives recursive resolvers an obvious path forward as implementers:   probe by default and report authentication failures while continuing to use the connection; check signalling and convert authentication failures to hardfails while still reporting
[20:13:56] <Viktor Dukhovni_web_247> I've been heard to mutter about the need for an in band reporting mechanism for SMTP but never quite found time to write a draft and implement...
[20:13:57] David K_web_670 leaves the room
[20:14:04] <Viktor Dukhovni_web_247> Here it would probably be needed.
[20:14:27] <dkg> and it gives authoritative operators an obvious path forward: implement and collect reports, then decide whether to signal hardfail
[20:14:38] <Alessandro Amirante_web_260> This Meetecho room is closing. You can connect to https://meetings.conf.meetecho.com/ietf111/?group=dprive&item=2 and continue the discussion there. The room will open in a few seconds
[20:14:54] Carlos Silva_web_382 leaves the room
[20:14:57] <Viktor Dukhovni_web_247> Yes.  We seem to be agreeing.
[20:15:02] zyxbac leaves the room
[20:15:02] halfshot leaves the room
[20:15:02] cjsu leaves the room
[20:15:02] Vittorio Bertola leaves the room
[20:15:03] Paul Wouters_web_647 joins the room
[20:15:03] Alessandro Amirante_web_152 joins the room
[20:15:03] Patrick Tarpey_web_814 joins the room
[20:15:03] Kazunori Fujiwara_web_491 joins the room
[20:15:03] Daniel Gillmor_web_286 joins the room
[20:15:03] Allison Mankin_web_888 joins the room
[20:15:03] Benjamin Enchun_web_941 joins the room
[20:15:03] Yoshiro Yoneya_web_596 joins the room
[20:15:03] Andrew Campling_web_897 joins the room
[20:15:03] David K_web_468 joins the room
[20:15:03] Takahiro Nemoto_web_777 joins the room
[20:15:03] Tim Wicinski_web_896 joins the room
[20:15:03] Eric Kinnear_web_823 joins the room
[20:15:03] Nicklas Pousette_web_743 joins the room
[20:15:05] Alessandro Amirante_web_260 leaves the room
[20:15:05] Matthew Quick_web_139 leaves the room
[20:15:05] Brett Carr_web_271 leaves the room
[20:15:05] Michael Breuer_web_238 leaves the room
[20:15:05] Ray Bellis_web_801 leaves the room
[20:15:05] Jorge Cano_web_335 leaves the room
[20:15:05] David Oran_web_651 leaves the room
[20:15:05] Peter van Dijk_web_339 leaves the room
[20:15:05] Erik Nygren_web_411 leaves the room
[20:15:05] Dan Wing_web_722 leaves the room
[20:15:05] Jonathan Hoyland_web_550 leaves the room
[20:15:05] Vincent Levigneron_web_351 leaves the room
[20:15:05] David Smith_web_908 leaves the room
[20:15:05] Jasdip Singh_web_286 leaves the room
[20:15:05] George Michaelson_web_667 leaves the room
[20:15:05] Hugo Kobayashi_web_984 leaves the room
[20:15:05] Enock Mbewe_web_345 leaves the room
[20:15:05] Viktor Dukhovni_web_247 leaves the room
[20:15:05] Stephan Emile_web_738 leaves the room
[20:15:05] Tim Cappalli_web_266 leaves the room
[20:15:05] Wes Hardaker_web_817 leaves the room
[20:15:05] Ralf Weber_web_661 leaves the room
[20:15:05] Benno Overeinder_web_652 leaves the room
[20:15:05] David Lawrence_web_188 leaves the room
[20:15:05] Eric Orth_web_714 leaves the room
[20:15:05] Paul Hoffman_web_597 leaves the room
[20:15:05] Tommy Jensen_web_797 leaves the room
[20:15:05] Alexander Mayrhofer_web_168 leaves the room
[20:15:05] Brian Dickson_web_260 leaves the room
[20:15:05] Phillip Hallam-Baker_web_344 leaves the room
[20:15:06] zyxbac joins the room
[20:15:06] halfshot joins the room
[20:15:06] cjsu joins the room
[20:15:06] Vittorio Bertola joins the room
[20:15:15] Nicklas Pousette_web_743 leaves the room
[20:15:19] Suzanne Woolf_web_185 joins the room
[20:15:42] Brian Dickson_web_895 joins the room
[20:16:08] Benno Overeinder_web_124 joins the room
[20:16:14] <Brian Dickson_web_895> Aargh! I was mid-sentence typing on the previous chat channel...
[20:16:48] Ulrich Wisser_web_260 joins the room
[20:17:40] <Alessandro Amirante_web_152> Sorry about that!
[20:18:24] <Brian Dickson_web_895> No worries... poop happens
[20:18:38] Erik Kline_web_124 joins the room
[20:19:01] Brian Haberman_web_185 joins the room
[20:19:32] <Brian Haberman_web_185> @BrianD Now you have a fresh channel for your thoughts!
[20:20:45] <Brian Haberman_web_185> @Alessandro A feature request for Meetecho... WGs need intro music so that incoming participants know if their audio feeds are working. :wink:
[20:20:48] <dkg> Brian Dickson_web_895: it's the same channel if you use XMPP :P
[20:21:05] Nicklas Pousette_web_818 joins the room
[20:21:09] <Paul Wouters_web_647> hahaha
[20:21:11] <dkg> Brian Haberman_web_185: i'm pretty sure you can provide that yourself, right?
[20:21:26] Yoshiro Yoneya_web_596 leaves the room
[20:21:30] Yoshiro Yoneya_web_581 joins the room
[20:21:36] <meetecho-alexamirante> Brian Haberman_web_185: noted! :wink:
[20:21:37] <dkg> i'm scared to think what the various WG chairs will choose as their intro music though
[20:21:38] Yoshiro Yoneya_web_581 leaves the room
[20:21:42] <Brian Haberman_web_185> @dkg I don't think so
[20:21:51] Robert Story_web_904 joins the room
[20:22:05] <dkg> can't you just route the input from your local music player to the browser?
[20:22:11] <Brian Haberman_web_185> Next time we are in-person, ask me what Bill Fenner and I used to do when we chaired IDMR together.
[20:22:12] Vincent Levigneron_web_110 joins the room
[20:22:16] Yoshiro Yoneya_web_681 joins the room
[20:22:21] Michael Breuer_web_689 joins the room
[20:23:14] Viktor Dukhovni_web_754 joins the room
[20:23:22] <Andrew Campling_web_897> How about some show tunes while we wait for the session to start .....
[20:23:23] whalen@jabber.org leaves the room
[20:23:35] <Alessandro Amirante_web_152> Billo played a nice music intro yesterday while waiting for the plenary to start... :smile:
[20:24:18] <Paul Wouters_web_647> honestly, some music is good because i keep wondering if my laptop isn't working. because well, I am using linux audio :)
[20:24:19] <Andrew Campling_web_897> Or WG Chair karaoke?
[20:24:27] whalen@jabber.org joins the room
[20:24:29] <Brian Dickson_web_895> Siri: play Sabotage by the Beastie Boys... (that's what is playing in Star Trek reboot when JTK steals the car)
[20:24:42] <Erik Kline_web_124> @campling: "76 internet drafts led the big parade, ..."
[20:24:52] Jim Reid_web_931 joins the room
[20:24:58] Geoff Huston_web_712 joins the room
[20:24:58] <dkg> for some reason i'm thinking of this: https://youtu.be/SFo2uiwjIJQ
[20:25:18] <Meetecho> Linux audio rocks! I only wish browsers started supporting Jack too ;-)
[20:25:22] Watson Ladd_web_481 joins the room
[20:25:28] Alexander Mayrhofer_web_862 joins the room
[20:25:29] Frode Sorensen_web_590 joins the room
[20:25:34] John Border_web_507 joins the room
[20:25:43] <dkg> i can just play "waltzing matilda" on the ukulele for you all
[20:26:02] David Lawrence_web_296 joins the room
[20:26:05] Paul Hoffman_web_743 joins the room
[20:26:13] Ginny Spicer_web_417 joins the room
[20:26:15] <dkg> that should clear the room
[20:26:22] <Brian Haberman_web_185> @dkg Why have we not seen the ukulele in-person???
[20:26:34] Éric Vyncke_web_219 joins the room
[20:26:36] Lixia Zhang_web_571 joins the room
[20:26:51] <Jim Reid_web_931> @dkg bagpipes and/or banjos will clear the room even quicker
[20:26:52] Alessandro Ghedini_web_448 joins the room
[20:27:14] Ralf Weber_web_267 joins the room
[20:27:21] Peter van Dijk_web_860 joins the room
[20:27:22] <Brian Haberman_web_185> I can see a quartet forming now...
[20:27:34] Eric Rescorla_web_180 joins the room
[20:27:50] PE_web_667 joins the room
[20:27:57] Marco Davids_web_849 joins the room
[20:27:58] <Andrew Campling_web_897> bagpipes, digeridoo and ukulele + show tunes?
[20:27:58] whalen@jabber.org leaves the room
[20:28:10] Duane Wessels_web_756 joins the room
[20:28:17] Brett Carr_web_125 joins the room
[20:28:26] Steffen Klassert_web_697 joins the room
[20:28:27] Frode Kileng_web_287 joins the room
[20:28:27] Vittorio Bertola_web_442 joins the room
[20:28:31] <Brian Haberman_web_185> We have a few bongo players in the IETF as well...
[20:28:31] <Paul Wouters_web_647> so far we lost half the people? I thought we had 110 in the first session?
[20:28:38] Andrew S_web_636 joins the room
[20:28:41] Ted Hardie_web_281 joins the room
[20:28:41] Lixia Zhang_web_571 leaves the room
[20:28:43] Keith Bare_web_198 joins the room
[20:28:50] <Peter van Dijk_web_860> certainly >100
[20:28:50] Mark Andrews_web_682 joins the room
[20:28:56] Robert Evans_web_580 joins the room
[20:28:59] <dkg> Brian Haberman_web_185: you never asked about the ukulele!
[20:29:00] <Brian Haberman_web_185> It may have been a little higher than that.
[20:29:01] <Andrew Campling_web_897> Are they still in the bar?
[20:29:02] Puneet Sood_web_428 joins the room
[20:29:07] <Paul Wouters_web_647> and its not that the hallways are too busy!
[20:29:08] <dkg> Jim Reid_web_931: do you have bagpipes?
[20:29:15] <Jim Reid_web_931> Hell no.
[20:29:21] <dkg> Jim Reid_web_931: i could also bust out my banjolele for two-in-one
[20:29:25] <dkg> aww :(
[20:29:27] Erik Nygren_web_569 joins the room
[20:29:31] <Brian Haberman_web_185> Jim kills bagpipes on sight, right?
[20:29:33] James Galvin_web_334 joins the room
[20:29:42] Stuart Cheshire_web_792 joins the room
[20:29:50] Jonathan Hoyland_web_797 joins the room
[20:29:52] Antoin Verschuren_web_319 joins the room
[20:29:53] <Paul Hoffman_web_743> Jim: that's best news I have heard all day.
[20:29:54] <Éric Vyncke_web_219> Or loud typing ?
[20:30:00] <Jim Reid_web_931> Only when I'm armed Brian.
[20:30:00] <Watson Ladd_web_481> oh, i've been taking up the ukulele
[20:30:02] <Paul Wouters_web_647> is that the same rule that he breaks all whiskey with "glen" in the name ?
[20:30:03] Peter Koch_web_549 joins the room
[20:30:14] Joey Salazar_web_968 joins the room
[20:30:16] Mike Bishop_web_195 joins the room
[20:30:20] Zaid AlBanna_web_331 joins the room
[20:30:28] Shane Kerr_web_168 joins the room
[20:30:30] Christopher Wood_web_979 joins the room
[20:30:30] Gustavo Lozano_web_728 joins the room
[20:30:30] James Gruessing_web_414 joins the room
[20:30:31] Jeremiah Androscavage_web_312 joins the room
[20:30:33] Sara Dickinson_web_714 joins the room
[20:30:45] Jasdip Singh_web_571 joins the room
[20:30:46] Tommy Jensen_web_645 joins the room
[20:31:06] James Gould_web_412 joins the room
[20:31:06] Sanjay Mishra_web_679 joins the room
[20:31:08] Jorge Cano_web_229 joins the room
[20:31:13] Rolf Sonneveld_web_932 joins the room
[20:31:17] Scott Hollenbeck_web_387 joins the room
[20:31:24] <Tim Wicinski_web_896> "a poor craftsman who blames his tools"
[20:31:36] <nygren> we just need to backronym "LATEST"
[20:31:37] Benjamin Enchun_web_941 leaves the room
[20:31:37] <Paul Wouters_web_647> lol
[20:31:43] David K_web_468 leaves the room
[20:31:48] David K_web_970 joins the room
[20:31:51] Chris Box_web_191 joins the room
[20:31:52] <Paul Wouters_web_647> software is clearly not a craft
[20:32:00] Warren Kumari_web_746 joins the room
[20:32:31] Christian Huitema_web_305 joins the room
[20:32:31] Shumon Huque_web_724 joins the room
[20:32:46] Matthew Quick_web_483 joins the room
[20:32:52] David Smith_web_174 joins the room
[20:32:58] Tommy Pauly_web_894 joins the room
[20:33:09] Eric Orth_web_521 joins the room
[20:33:12] Yuji Koyama_web_723 joins the room
[20:33:12] Christian Elmerot_web_800 joins the room
[20:33:23] <dkg> but good software devs are definitely crafty
[20:34:23] <Watson Ladd_web_481> similarly to  Alberich, judging by the results of the fruits
[20:34:35] Mark Kosters_web_677 joins the room
[20:34:42] <Éric Vyncke_web_219> Do we have minute taker for this part of DPRIVE ?
[20:34:58] David Oliver_web_480 joins the room
[20:34:59] Richard Wilhelm_web_881 joins the room
[20:35:30] David Schinazi_web_670 joins the room
[20:35:36] John Kaippallimalil_web_318 joins the room
[20:36:11] <Watson Ladd_web_481> I'll do it
[20:36:33] Chi-Jiun Su_web_586 joins the room
[20:36:40] Hugo Kobayashi_web_797 joins the room
[20:36:54] whalen@jabber.org joins the room
[20:36:56] Tara Whalen_web_781 joins the room
[20:36:58] <Éric Vyncke_web_219> Thank you Watson
[20:37:16] <Watson Ladd_web_481> Jonathan also jumped on
[20:38:30] Δημήτρης Μαρουλίδης_web_108 joins the room
[20:38:40] Δημήτρης Μαρουλίδης_web_108 leaves the room
[20:39:00] <evansr> We need to decide if the in-bailiwick NS query should have privacy or not
[20:39:04] Bernie Innocenti_web_661 joins the room
[20:39:12] Benedict Wong_web_881 joins the room
[20:39:15] Burt Kaliski_web_979 joins the room
[20:39:36] Dimitris Maroulidis_web_598 joins the room
[20:40:27] Yan Yan_web_569 joins the room
[20:40:36] Yan Yan_web_569 leaves the room
[20:41:37] Nigel Hickson_web_537 joins the room
[20:41:54] <Paul Wouters_web_647> there is only one answer. and it is DS :)
[20:42:11] <Paul Wouters_web_647> (which does not require child zone to do dnssec)
[20:42:36] Jonathan Lennox_web_198 joins the room
[20:42:41] <Peter van Dijk_web_860> DOTPIN proves it can be solved; it just violates various other constraints that are important too, unless registrars get on board for that too
[20:42:55] <Paul Wouters_web_647> no no it does not need dnssec
[20:43:05] Alissa Cooper_web_753 joins the room
[20:43:24] <Paul Wouters_web_647> ekr: the DS is signed by the parent. the parent needs dnssec, not the client
[20:43:30] <ekr@jabber.org> Sure.
[20:43:33] <Paul Wouters_web_647> (not the child)
[20:44:02] <Paul Wouters_web_647> ipv6 reverse is dead :(
[20:44:06] <Warren Kumari_web_746> @Peter: registrars and web UIs and similar, I think?
[20:44:30] Rich Salz_web_246 joins the room
[20:44:54] <dkg> using inaddr.arpa would assume that all named nameservers on a given IP address need to support authenticated crypto at the same time
[20:45:07] <Paul Wouters_web_647> you have a private path to parent
[20:45:11] <Paul Wouters_web_647> else you are gone to befin with
[20:45:36] Burt Kaliski_web_979 leaves the room
[20:46:22] <Paul Wouters_web_647> (we are getting to the point where it might make sense to do my presentation first)
[20:47:15] <Paul Wouters_web_647> it is interesting... because looking up ".ca" might prove to someone you went to nohats.ca and not harmless.com
[20:47:43] Ray Bellis_web_593 joins the room
[20:47:47] <Brett Carr_web_125> As a TLD Operator we would be very unlikely to be an early adopter of something like this.
[20:48:04] <Marco Davids_web_849> +1
[20:48:06] <Jim Reid_web_931> @dkg inaddr.arpa won't work when the name server and reverse zone are controlled by different entities: eg my name server sitting on an AWS VM.
[20:48:12] <Brett Carr_web_125> Risk Averse aha :)
[20:48:14] <Paul Wouters_web_647> what PaulH says :)
[20:48:42] <Peter van Dijk_web_860> dkg, arguments keep popping up for not tying authentication to names :)
[20:48:48] James Galvin_web_334 leaves the room
[20:48:53] James Galvin_web_783 joins the room
[20:49:02] කෙසර රත්නායක_web_242 joins the room
[20:49:08] <Watson Ladd_web_481> what is authentication without names?
[20:49:09] <Viktor Dukhovni_web_754> DNSSEC deployment has not leveled out.
[20:49:13] <Alexander Mayrhofer_web_862> Encryption of TLD zones is one thing (and probably the easier one), accepting any kind of "new" parent information for TLDs is probably the bigger thing (speaking as a medium size TLD operator)
[20:49:23] <Ted Hardie_web_281> They definitely won't do if there isn't a workable spec.
[20:49:26] කෙසර රත්නායක_web_242 leaves the room
[20:49:41] <Brian Haberman_web_185> I cut the mic line at DKG
[20:49:42] <Andrew Campling_web_897> So why not ask the TLDs?  Or has this happened already?
[20:49:44] <Alexander Mayrhofer_web_862> (and i mean encrypted transport to auth ns of TLDs)
[20:49:47] <Peter van Dijk_web_860> Warren, I should have said registries. Then, in the specific case I'm describing (for DOTPIN) the problem is that we'd want the registry to apply some DS data to every zone pointed at a certain NS. There is of course also a secondary UI problem in registrars for that.
[20:49:55] <Ted Hardie_web_281> But giving up now means that there is no way to pressure them, and no way to allow any TLD to do it and povide comparison.
[20:50:01] <Watson Ladd_web_481> what if it's just the NS's own name
[20:50:17] <Paul Wouters_web_647> watson: see my last slide :)
[20:50:23] <Watson Ladd_web_481> exactly
[20:50:24] <Christian Huitema_web_305> +1 dkg. TLDs compete.
[20:50:38] <Watson Ladd_web_481> think we need to rearrange drafts: too many saying overlapping things
[20:50:40] <Ray Bellis_web_593> ccTLDs don't need differentiation on features
[20:50:55] <Peter van Dijk_web_860> Ted, agree, and I think PCH, as a TLD operator, has indicated interest, in opposition to what Verisign has been suggesting, which is that no TLDs do it.
[20:50:57] Burt Kaliski_web_245 joins the room
[20:51:00] Hirochika Asai_web_627 joins the room
[20:51:01] <ekr@jabber.org> Ray: is that really true? Like .io versus .ly?
[20:51:23] <Jim Reid_web_931> @Alex, new parent info will further complicate the already complicated zone cut semantics. We found this out the hard way when DNSSEC was developed.
[20:51:34] <Peter van Dijk_web_860> Jim, unless that parent info is in DS
[20:51:36] <Viktor Dukhovni_web_754> DANE 3 1 1 does not care about names.
[20:51:39] <Ray Bellis_web_593> well if your feature is selling domains that could disappear at any time when your host country decides they don't like what your doing...
[20:51:42] <Alexander Mayrhofer_web_862> @Jim, indeed.
[20:51:46] <Warren Kumari_web_746> @Peter: Yes, but you still need a means for the child to communicate the information to the registry, yes? This requires web UIs to be updated so the child can provide info, something in EPP to transfer this data, etc, yes?
[20:51:51] <ekr@jabber.org> Ray: well, that is in fact a quite common model
[20:51:58] <Brett Carr_web_125> I dont think we would go to the step of discouraging other TLD operators but i would be surprised if any of the large operators would be keen
[20:52:08] <Ray Bellis_web_593> right, but it's not a technical feature.
[20:52:20] <Peter van Dijk_web_860> Warren, correct - it has been widely deemed that this is not feasible. I'm just pointing out it is possible ;)
[20:52:21] Florence D_web_526 joins the room
[20:52:29] <Jim Reid_web_931> Indeed Peter. But tinkering with DS brings its own problems: backwards compatibility
[20:52:33] <Warren Kumari_web_746> Ah, ok, I missed that :-)
[20:52:41] Alissa Cooper_web_753 leaves the room
[20:52:54] <dkg> Jim Reid_web_931: DS already has compatibility issues based on unknown algorithms
[20:53:01] <Peter van Dijk_web_860> Jim, I have sent extensive report to dnsop and dprive showing that the backwards compatibility problems are at the EPP-and-related level, not at the DNS level
[20:53:02] <Alexander Mayrhofer_web_862> @Warren - interface is one thing, processes is the other one. Adding another "what if" switch to each process is non-trivial.
[20:53:11] Praveen Balasubramanian_web_666 joins the room
[20:53:32] <Alexander Mayrhofer_web_862> @Warren - think DNSSEC vs ADoX signaling vs Registrar Lock vs Transfer grace period ... etc..
[20:53:37] <Warren Kumari_web_746> @Alex / Peter: I think we are in violent agreement here...
[20:54:00] <Peter van Dijk_web_860> Certainly 90% of violent :)
[20:54:07] <Brian Dickson_web_895> DS is per-algorithm, and unknown algorithms fail safe (insecure rather than bogus). New DS algorithm is a viable path forward. (Tested, BTW, works.)
[20:54:45] Ralf Weber_web_267 leaves the room
[20:54:51] <Peter van Dijk_web_860> Brian, quad1 has rolled back their fix for that and last time I checked the ticket at quad8 was open but unfixed; but if it's just those two, I am optimistic. (All open source validators have been fine since early 2019 or longer.)
[20:54:53] <Brian Dickson_web_895> Also, DS is supported independent of upstream (Registry) validation, as long as the algorithm is IANA registered, generally.
[20:55:02] <Peter van Dijk_web_860> no, wrong
[20:55:09] <Peter van Dijk_web_860> many registries have short allowlists for what goes into DS
[20:55:19] Ralf Weber_web_521 joins the room
[20:55:26] <Warren Kumari_web_746> ... and I'll point at the web UI issue again for this.
[20:55:30] <Peter van Dijk_web_860> that too
[20:55:47] <dkg> i don't understand Paul's claim about further centralization of DNS resolvers :(
[20:55:50] <Peter van Dijk_web_860> in this case it's definitely both registries and registrars and registrar resellers
[20:55:54] <ekr@jabber.org> neither do I, actually
[20:56:00] <Ray Bellis_web_593> IANA themselves (until recently?) had an incomplete shortlist of acceptable DS algos.
[20:56:01] <nygren> One solution approach is covered in the (currently expired) draft-tapril-ns2-01 <https://datatracker.ietf.org/doc/html/draft-tapril-ns2-01>.  One key part of this is putting only SVCB AliasMode records in the parent zones but with the ServiceMode records with the actual details elsewhere.
[20:56:12] <ekr@jabber.org> Because even in a case of like Firefox, we only control the recursive.
[20:56:16] <Brian Dickson_web_895> Some CCTLDs do have strict requirements, of course. My comments are mostly applicable to gTLDs... but nonetheless, adding to an allow-list, with no other support work, is IMHO potentially viable.
[20:56:26] Stephan Emile_web_572 joins the room
[20:56:32] <Peter van Dijk_web_860> Ray, DS (DNSKEY) algos or DS digests?
[20:56:44] <ekr@jabber.org> It's not like we're going to refuse to connect to foo.com because it doesn't have TLS
[20:56:47] <ekr@jabber.org> It's not like we're going to refuse to connect to foo.com because it doesn't have TLS
[20:56:48] <Ray Bellis_web_593> umm, DNSKEY I think
[20:56:52] <ekr@jabber.org> TLS for it's auth
[20:57:37] <Brian Dickson_web_895> UI is an issue, but CDS is a path that avoids that (and ties into authority server side bits, which are generally serviceable parts.)
[20:57:52] <Warren Kumari_web_746> Can someone help me understand bullet 2?
[20:57:59] <ekr@jabber.org> I also do not understand it
[20:58:07] <ekr@jabber.org> Like isn't that just inherent with the NS record?
[20:58:13] <Warren Kumari_web_746> The *key* isn;t in the name...
[20:58:15] <Peter van Dijk_web_860> it is, but before we put keys in there, it was not a problem
[20:58:16] <evansr> Do we have evidence that DS is widely accepted and compatible?
[20:58:32] <ekr@jabber.org> @Chairs: can we get some clarifying questions here?
[20:58:52] <Peter van Dijk_web_860> evansr, yes - I did the research 2.5 years ago. Kont Resolver and quad1 got fixed; quad8 said 'we will fix it'. Quad1 since rolled the fix back, and fixed it again a few months ago.
[20:58:56] <Peter van Dijk_web_860> *Knot
[20:59:00] Robert Story_web_904 leaves the room
[20:59:11] <Peter Koch_web_549> except in those cases where the parent (==TLD) only accepts DNSKEY RRs ...
[20:59:12] Robert Story_web_851 joins the room
[20:59:22] <Brian Dickson_web_895> DS without DNSKEY is what I'll be writing up. As long as the validator understands the new DS algorithm, this is both backward compatible and a mechanism that should work modulo allow-lists on algorithms for DS
[20:59:24] Praveen Balasubramanian_web_666 leaves the room
[20:59:31] Lixia Zhang_web_406 joins the room
[20:59:32] <Peter van Dijk_web_860> Peter, I proposed the VERBATIM digest for that, and modelled DOTPIN such that it survived the digesting. It's solvable.
[20:59:42] Burt Kaliski_web_245 leaves the room
[20:59:46] Stuart Cheshire_web_792 leaves the room
[21:00:04] Jesus Martin_web_465 joins the room
[21:00:07] <dkg> *resolvers* need to change -- i think wouters' point is that you don't want each *zone* maintainer to have to update their NS records
[21:00:16] James Galvin_web_783 leaves the room
[21:00:20] <Peter van Dijk_web_860> yes, that is the point
[21:00:23] James Galvin_web_465 joins the room
[21:00:31] <Brian Dickson_web_895> @peter koch correct. Those might need per-algorithm exceptions added...
[21:00:59] Burt Kaliski_web_426 joins the room
[21:01:10] <Brian Dickson_web_895> @dkg correct, this would not be associated with the zone, this is for validation of the NS through a signed record type (DS).
[21:01:17] Robert Story_web_851 leaves the room
[21:01:22] Robert Story_web_996 joins the room
[21:01:28] <ekr@jabber.org> I think we can all agree that the signal *could* say "encrypt and assume that the thing can authenticate"
[21:01:30] <Christian Huitema_web_305> recursive resolvers need to change. centralized resolvers will change faster. Thus we should not do any change, because it encourages centralization? Really?
[21:01:31] James Galvin_web_465 leaves the room
[21:01:38] James Galvin_web_465 joins the room
[21:02:04] <ekr@jabber.org> I feel like we can find some way to fix this issue
[21:02:26] <Brian Dickson_web_895> (NS is the name of the authoritative server. LHS is the zone name, RHS is the server name, and as long as RHS is not in-bailiwick, scales well, particularly for high ratios of zone:server)
[21:02:30] <ekr@jabber.org> For instance <flag>.customer-domain.com
[21:03:07] <Christian Huitema_web_305> @ekr from the dicussion, it seems that no glue can be trusted. Except maybe if you sniff it?
[21:03:09] <Jonathan Hoyland_web_797> @Warren, I think I misunderstood your final point, could you check the minutes?
[21:03:44] <nygren> I think an important property is that configuration needs to be associated with the server name and under the control of the authoritative server operator.
[21:03:49] <Alexander Mayrhofer_web_862> DS at parent would definitely be an easier solution than SVCB for TLDs, because most do accept DS already.
[21:04:10] <Peter van Dijk_web_860> Alex, nygren, you two together just described the problem space
[21:04:12] <Alexander Mayrhofer_web_862> and doesn't overload the NSset
[21:04:18] Joseph Kalfa_web_299 joins the room
[21:04:23] <Peter van Dijk_web_860> getting DS to parent is easy; updating DS for a million domains, when you're not even the registrar, is hard.
[21:04:26] <zulipbot> (Ralf Weber) But there are TLDs that accept DNSKEY and it would not work with them
[21:04:31] Benjamin Schwartz_web_724 joins the room
[21:04:49] <Peter van Dijk_web_860> Ralf, I have two drafts that prove that that is not a problem
[21:05:13] John Kaippallimalil_web_318 leaves the room
[21:05:19] <Brian Dickson_web_895> @peter van dijk correct modulo registrar supporting CDS - which is relatively straightforward to do, and e.g. GoDaddy will be doing, soon.
[21:05:28] Patrick Tarpey_web_814 leaves the room
[21:05:32] <Ray Bellis_web_593> DS is a pragmatic solution, but I don't like the semantic abuse
[21:05:42] <Brian Dickson_web_895> Registrar polling for CDS, submit via EPP
[21:06:02] <Robert Evans_web_580> a drawback of DS is that it is owned by the registrant semantically; name server operators can't signal their support without cooperation from domain owners or parent zones
[21:06:05] <Peter van Dijk_web_860> Brian, if the auth operator is also the signer
[21:06:17] <Brian Dickson_web_895> DS with new algorithm is semi-semantic abuse. Which is semantic abuse of semantic abuse discussions :-)
[21:06:35] <Ray Bellis_web_593> Robert - the DS is owned by the DNSSEC signer, not necessarily the registrant
[21:06:36] <Peter Koch_web_549> the semantic overloading moves the burden elsewhere - and of course is not proper protocol design, which is more than an aesthetic assertion
[21:06:41] <ekr@jabber.org> Viktor: thanks, I think we're on the same page about the properties
[21:06:49] Richard Wilhelm_web_881 leaves the room
[21:06:54] Richard Wilhelm_web_979 joins the room
[21:07:15] Tim April_web_620 joins the room
[21:07:28] <Ray Bellis_web_593> Robert - when used for DNSSEC, that is :)
[21:07:34] <Mark Andrews_web_682> QNAME minimisation is still needed
[21:07:36] <ekr@jabber.org> I also agree here: I think we should encode effectively [Do DoT and expect it to be WebPKI] or [Do DoT and expect it to be TLSA]
[21:08:03] <Brian Dickson_web_895> No, the auth operator does not need to be the signer. If the auth operator is doing dnssec and publishes CDS, and the registrar polls for CDS, the registrar is not involved in the signing. The registrar probably needs to validate the signature over the CDS, i.e. the auth operator publishing the CDS on a special domain (like the bootstrap proposal for the mechanism for going secure.)
[21:08:06] <evansr> @Ray Bellis no the signer gives the DS, the domain owner has to program it (sometimes the owner lets an operator do all that, but not in general)
[21:08:47] <evansr> As a large operator I prefer non-DS because I don't expect it's realistic for large numbers of individual customers to change DS to enable ADoT
[21:08:50] <ekr@jabber.org> TBH, in the browsers when things fail we mostly just give up
[21:09:02] <Peter van Dijk_web_860> Evan, that's why I say that can only work if the registry cooperates
[21:09:11] <Brian Dickson_web_895> The DS is a non-DNSSEC DS thing, i.e. not linked to the child being signed... there isn't any actual signature, the DS record itself would be something else (hash of NS set)
[21:09:11] Burt Kaliski_web_426 leaves the room
[21:09:25] <ekr@jabber.org> In case it wasn't clear, if the DNS-person consensus is that DS is the best spelling, then great
[21:09:35] <Brian Dickson_web_895> The limit on registry cooperation would be, allow new algo
[21:09:40] <evansr> registry CDS can't do anything for unsigned child zones....
[21:09:45] <Ray Bellis_web_593> it's not best, it's just least worst
[21:09:47] <Peter van Dijk_web_860> ekr, I have always liked the DS spelling, but only with serious registry code refactoring
[21:09:58] <Warren Kumari_web_746> I think that, if you want the DNS-person consensus, you shuld ask DNSOP...
[21:10:26] <Brian Dickson_web_895> @evansr, correct, this would likely be EPP-only as the comms channel for this DS record (new algo)
[21:10:36] <ekr@jabber.org> Warren: did you just volunteer?
[21:11:18] <evansr> @Brian Dickson right, so this requires the name server operator have registration power but that's not the case for standalone DNS hosts (e.g. the one I run)
[21:11:28] <Warren Kumari_web_746> The namehack hack can, I think, be started now. Resolvers would need to start checking, but there is no change needed in the registry, UI, resellers, etc. It is less secure, but it can be done in parallel...
[21:11:53] James Galvin_web_465 leaves the room
[21:11:57] <Warren Kumari_web_746> Sorry, namehack == namesignal.
[21:11:59] James Galvin_web_452 joins the room
[21:13:49] <Brian Dickson_web_895> @evansr or to have the registrar being willing/able to poll the DNS operator for NS apex, or more likely to maintain accurate state regarding the delegation NS set. The DS would be submitted by the Registrar, and would consist only of hash of NS records RDATA (contents). This scales really well, and the Registrar is always on-path for EPP updates for NS changes.
[21:14:28] <Chris Box_web_191> Ben your microphone is slightly muffled and clipping - but still good enough to be understood.
[21:14:34] <Peter van Dijk_web_860> Depending on your arbitrary data, the DS record can be construed as an oracle that answers yes/no questions about the presence of certain data. I'm not familiar enough with name-signal to say if that would work there. (DOTPIN got so many other things wrong because it managed to fit into the oracle requirement.)
[21:14:47] Burt Kaliski_web_144 joins the room
[21:15:37] <Warren Kumari_web_746> The 50'000ft summary of name-signal is you make the nameserver name be:
svcb-qt.ns3.example   600 IN NS 192.0.2.1
[21:15:53] <ekr@jabber.org> right
[21:16:04] <Ray Bellis_web_593> NS with an IP in it?
[21:16:04] <evansr> @Brian Dickson if registrar is adding DS for the NS recordset that's something; are you suggesting the registrars do unauth probing then signal a secure indicator? because that's kind of super interesting
[21:16:20] <Warren Kumari_web_746> the name 'svcb-qt.ns3.example.' itself says that it does svcb- and supports Q and T.
[21:16:30] <Warren Kumari_web_746> @Ray, no, sorry, fingers got carries away :-)
[21:16:38] <ekr@jabber.org> @Warren: i was hoping that it meant that it supports R and U
[21:16:53] <Brett Carr_web_125> Perhaps we should just deprecate the support for in-balliwick NS's would save us a lot of hassle all over the place :)
[21:17:20] <Watson Ladd_web_481> who names the nameservers?
[21:18:08] <Warren Kumari_web_746> dig +short ns ietf.org
ns0.amsl.com.
ns1.ams1.afilias-nst.info.
ns1.hkg1.afilias-nst.info.
ns1.mia1.afilias-nst.info.
ns1.sea1.afilias-nst.info.
ns1.yyz1.afilias-nst.info.
[21:18:18] <Warren Kumari_web_746> Yuk:
[21:18:48] <Alexander Mayrhofer_web_862> We can rename DS from "Delegation Signer" to "Delegation Security" :-P
[21:18:56] <Erik Kline_web_124> are these two paths mutually exclusive?
[21:19:43] <Alexander Mayrhofer_web_862> or even "Delegation Signalling" :P
[21:19:53] <Ray Bellis_web_593> good point re: zone vs name server
[21:20:24] <ekr@jabber.org> Presumbaly we could find some way to make these per-server
[21:20:37] <Benjamin Schwartz_web_724> IMHO a DS-hack should encode a SVCB record for a specific nameserver
[21:20:40] <Peter van Dijk_web_860> zone vs NS is the big problem with DS
[21:20:53] <Peter van Dijk_web_860> and solving it towards per-NS requires registry help
[21:20:53] <ekr@jabber.org> Or one DS record that is a JSON list of SVCB records :)
[21:21:04] <Warren Kumari_web_746> $ dig ns ietf.org
;; ANSWER SECTION
ietf.org.        1799    IN    NS    ns0.amsl.com.
if the nameserver ns0.amsl.com supported T, it would be called svcb-t.ns0.amsl.com (and ietf,org would need to change to using):
ietf.org.        1799    IN    NS    svcb-t.ns0.amsl.com.
[21:21:24] <Warren Kumari_web_746> Bah.... that was all formatted perfecty until I pressed enter...
[21:21:30] <Ray Bellis_web_593> @Warren is that the child side NS records or parent side?
[21:21:45] <Alexander Mayrhofer_web_862> We just dropped the requirements draft :D
[21:21:53] <Warren Kumari_web_746> Child
[21:22:27] Benjamin Schwartz_web_724 leaves the room
[21:22:34] Benjamin Schwartz_web_740 joins the room
[21:22:39] <Warren Kumari_web_746> @EK: Nope, not at all mutually exclusive...
[21:22:58] Benjamin Schwartz_web_740 leaves the room
[21:23:00] <Warren Kumari_web_746> Possibly complementary
[21:23:02] Benjamin Schwartz_web_420 joins the room
[21:24:54] Sara Dickinson_web_714 leaves the room
[21:25:03] Jim Reid_web_931 leaves the room
[21:25:18] <Erik Kline_web_124> acknowledging the usual "don't do things in too many ways", if the multiple sources of information are available as a result of a linear set of steps I think that's less of a problem (e.g.: got DS and DS has magic? -> use this, else if NS name is specially formated? -> use this info, else legacy DNS)
[21:25:31] <Benjamin Schwartz_web_420> That sounds a _lot_ like https://www.ietf.org/archive/id/draft-fujiwara-dnsop-delegation-information-signer-00.txt
[21:25:41] Chi-Jiun Su_web_586 leaves the room
[21:25:45] Chi-Jiun Su_web_802 joins the room
[21:25:49] <Benjamin Schwartz_web_420> It requires clients to be able to update glue, NS, and DS atomically.
[21:26:26] <Peter van Dijk_web_860> Delegation Information Signer, or anything similar to it, only makes sense if it's a piece of code somewhere between 'zone generation' and 'zone signer' in the TLD
[21:26:42] <Peter van Dijk_web_860> and even those cannot do it atomically for caching reasons, so you'd need a rollover process
[21:26:43] Chris Box_web_191 leaves the room
[21:26:47] whalen@jabber.org leaves the room
[21:27:03] <Peter van Dijk_web_860> this is not hard; but it leans on the big question of whether we can get a hundred registrars to start doing things very differently
[21:27:47] <Brian Dickson_web_895> @benjamin yes, very similar, except without needing any new record types.
[21:28:22] <Benjamin Schwartz_web_420> "The DiS resource record reuses the type code and wire format of DS resource record, and distinguishes it from existing DS RRSet by using a new digest type."
[21:28:36] whalen@jabber.org joins the room
[21:28:44] <Brian Dickson_web_895> @benjamin, also the SVCB would be on the child side in the signed zone of the authoritative name server's name.
[21:30:16] James Galvin_web_452 leaves the room
[21:30:23] James Galvin_web_842 joins the room
[21:31:09] <dkg> or, the unauthenticated mechanism could drop signalling entirely and just rely on probing
[21:31:21] <evansr> +1 drop signalling for unauth
[21:31:22] <Warren Kumari_web_746> I think one of the big advantages of name-signal is that it can be deployed *now*, without having registries and registrars and resellers and dns operators all upgrade. It also doesn't require 2 DNS looksups...
[21:31:27] <dkg> signalling is only needed to decide whether to hardfail
[21:31:29] <ekr@jabber.org> @dkg: that would also work
[21:31:33] <Watson Ladd_web_481> +1 Warren
[21:31:37] <Ray Bellis_web_593> would now be a good time to start specifying a generic parent-side TLV container record so that in 10 years time we can use that?
[21:31:46] <Warren Kumari_web_746> The other solutions are stonger, but take much much longer to deploy.
[21:32:10] <Paul Wouters_web_647> cds implies child is signed though. and i think we want this to work for the non-dnssec case too ?
[21:32:11] <Peter van Dijk_web_860> Ray, I proposed 'reserve a few numbers to be DS-like' to the some time ago and was booed out of the room. Perhaps it was not concrete enough.
[21:32:27] PE_web_667 leaves the room
[21:32:28] <Peter van Dijk_web_860> *to the list
[21:32:31] <Peter van Dijk_web_860> dnsop it was, though
[21:32:33] <evansr> @Ray Bellis that's was one reason for interest in SVCB
[21:32:41] <Paul Wouters_web_647> peter: yeah reserving some range for DS might be good as we keep coming back to (ab)using it :)
[21:32:51] Tommy Jensen_web_645 leaves the room
[21:33:03] <ekr@jabber.org> DS as a generic container!
[21:33:13] <dkg> or, just accept that it's going to be abused this way and make the algorithm codepoint explicitly flexible like this
[21:33:38] <Peter van Dijk_web_860> Paul, please feel free to reply to your own objections in your email from 2020-09-25 :D
[21:33:39] Marco Davids_web_849 leaves the room
[21:33:40] Rich Salz_web_246 leaves the room
[21:33:41] Jeremiah Androscavage_web_312 leaves the room
[21:33:43] Eric Rescorla_web_180 leaves the room
[21:33:43] Paul Hoffman_web_743 leaves the room
[21:33:44] David Oliver_web_480 leaves the room
[21:33:44] Christopher Wood_web_979 leaves the room
[21:33:45] Alexander Mayrhofer_web_862 leaves the room
[21:33:45] Watson Ladd_web_481 leaves the room
[21:33:46] Tommy Pauly_web_894 leaves the room
[21:33:46] Chi-Jiun Su_web_802 leaves the room
[21:33:46] James Gruessing_web_414 leaves the room
[21:33:46] <Paul Wouters_web_647> :)
[21:33:46] whalen@jabber.org leaves the room
[21:33:47] Ted Hardie_web_281 leaves the room
[21:33:47] James Gould_web_412 leaves the room
[21:33:47] Andrew S_web_636 leaves the room
[21:33:48] Shumon Huque_web_724 leaves the room
[21:33:48] <Tim Wicinski_web_896> Thanks All
[21:33:48] Hugo Kobayashi_web_797 leaves the room
[21:33:48] Suzanne Woolf_web_185 leaves the room
[21:33:49] Geoff Huston_web_712 leaves the room
[21:33:49] Nicklas Pousette_web_818 leaves the room
[21:33:50] Erik Nygren_web_569 leaves the room
[21:33:51] Christian Huitema_web_305 leaves the room
[21:33:51] Vittorio Bertola_web_442 leaves the room
[21:33:51] Éric Vyncke_web_219 leaves the room
[21:33:52] Andrew Campling_web_897 leaves the room
[21:33:52] John Border_web_507 leaves the room
[21:33:52] Jonathan Hoyland_web_797 leaves the room
[21:33:52] Florence D_web_526 leaves the room
[21:33:52] Richard Wilhelm_web_979 leaves the room
[21:33:52] Dimitris Maroulidis_web_598 leaves the room
[21:33:52] Ray Bellis_web_593 leaves the room
[21:33:53] Tim Wicinski_web_896 leaves the room
[21:33:54] Frode Sorensen_web_590 leaves the room
[21:33:54] Alessandro Ghedini_web_448 leaves the room
[21:33:55] Keith Bare_web_198 leaves the room
[21:33:55] Mark Andrews_web_682 leaves the room
[21:33:56] David Schinazi_web_670 leaves the room
[21:33:56] Shane Kerr_web_168 leaves the room
[21:33:57] Jorge Cano_web_229 leaves the room
[21:33:57] Ralf Weber_web_521 leaves the room
[21:33:57] Joey Salazar_web_968 leaves the room
[21:34:00] Yoshiro Yoneya leaves the room
[21:34:01] <Peter van Dijk_web_860> thanks all, see you on the list
[21:34:01] James Galvin_web_842 leaves the room
[21:34:02] Kazunori Fujiwara_web_491 leaves the room
[21:34:03] Ulrich Wisser_web_260 leaves the room
[21:34:03] Christian Elmerot_web_800 leaves the room
[21:34:03] Benjamin Schwartz_web_420 leaves the room
[21:34:03] Jonathan Lennox_web_198 leaves the room
[21:34:04] Gustavo Lozano_web_728 leaves the room
[21:34:06] Daniel Gillmor_web_286 leaves the room
[21:34:07] <Viktor Dukhovni_web_754> Likewise...
[21:34:08] <Paul Wouters_web_647> peter: the good thing of science is you can always do more and learn !
[21:34:08] Eric Kinnear_web_823 leaves the room
[21:34:09] Erik Kline_web_124 leaves the room
[21:34:10] Hirochika Asai_web_627 leaves the room
[21:34:11] Yoshiro Yoneya_web_681 leaves the room
[21:34:12] <Peter van Dijk_web_860> yep!
[21:34:14] Takahiro Nemoto_web_777 leaves the room
[21:34:18] Robert Story_web_996 leaves the room
[21:34:20] Yuji Koyama_web_723 leaves the room
[21:34:20] Tim April_web_620 leaves the room
[21:34:21] Ginny Spicer_web_417 leaves the room
[21:34:22] <Brian Dickson_web_895> Thanks everyone!
[21:34:24] Rolf Sonneveld_web_932 leaves the room
[21:34:26] Paul Wouters_web_647 leaves the room
[21:34:27] Scott Hollenbeck_web_387 leaves the room
[21:34:29] Mike Bishop_web_195 leaves the room
[21:34:32] Viktor Dukhovni_web_754 leaves the room
[21:34:37] Allison Mankin_web_888 leaves the room
[21:34:39] Brian Haberman_web_185 leaves the room
[21:34:44] Warren Kumari_web_746 leaves the room
[21:34:46] ekr@jabber.org leaves the room
[21:34:52] Sanjay Mishra_web_679 leaves the room
[21:35:00] Bernie Innocenti_web_661 leaves the room
[21:35:01] Frode Kileng_web_287 leaves the room
[21:35:26] Peter Koch_web_549 leaves the room
[21:35:36] Benedict Wong_web_881 leaves the room
[21:35:38] Meetecho leaves the room
[21:35:43] Tara Whalen_web_781 leaves the room
[21:35:44] frodek leaves the room
[21:35:56] Lixia Zhang_web_406 leaves the room
[21:36:07] Alessandro Amirante_web_152 leaves the room
[21:36:07] Benno Overeinder_web_124 leaves the room
[21:36:07] Vincent Levigneron_web_110 leaves the room
[21:36:07] Michael Breuer_web_689 leaves the room
[21:36:07] Peter van Dijk_web_860 leaves the room
[21:36:07] Duane Wessels_web_756 leaves the room
[21:36:07] Brett Carr_web_125 leaves the room
[21:36:07] Steffen Klassert_web_697 leaves the room
[21:36:07] Puneet Sood_web_428 leaves the room
[21:36:07] Antoin Verschuren_web_319 leaves the room
[21:36:07] Zaid AlBanna_web_331 leaves the room
[21:36:07] David Lawrence_web_296 leaves the room
[21:36:07] Jasdip Singh_web_571 leaves the room
[21:36:07] David K_web_970 leaves the room
[21:36:07] Matthew Quick_web_483 leaves the room
[21:36:07] David Smith_web_174 leaves the room
[21:36:07] Mark Kosters_web_677 leaves the room
[21:36:07] Robert Evans_web_580 leaves the room
[21:36:07] Eric Orth_web_521 leaves the room
[21:36:07] Nigel Hickson_web_537 leaves the room
[21:36:07] Jesus Martin_web_465 leaves the room
[21:36:07] Stephan Emile_web_572 leaves the room
[21:36:07] Joseph Kalfa_web_299 leaves the room
[21:36:07] Brian Dickson_web_895 leaves the room
[21:36:07] Burt Kaliski_web_144 leaves the room
[21:41:45] meetecho-alexamirante leaves the room
[21:47:28] whalen@jabber.org joins the room
[21:53:08] whalen@jabber.org leaves the room
[22:02:50] evansr leaves the room
[22:44:05] whalen@jabber.org joins the room
[22:48:10] dkg leaves the room
[22:50:32] tale leaves the room
[23:05:09] tale joins the room
[23:21:10] whalen@jabber.org leaves the room
[23:22:38] whalen@jabber.org joins the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!