Thursday, November 11, 2021< ^ >
meetecho-alexamirante has set the subject to: DPRIVE - IETF 111
Room Configuration
Room Occupants

[11:16:05] Meetecho joins the room
[11:38:47] Yoshiro Yoneya joins the room
[11:41:02] alexamirante joins the room
[11:41:19] alexamirante has set the subject to: DPRIVE - IETF 112
[11:45:07] Yoshiro Yoneya_web_842 joins the room
[11:45:07] abdullahalshoaili_web_614 joins the room
[11:45:07] Alessandro Amirante_web_834 joins the room
[11:45:07] Éric Vyncke_web_404 joins the room
[11:45:07] Tim Wicinski_web_148 joins the room
[11:45:07] Christian Huitema_web_355 joins the room
[11:45:11] abdullahalshoaili_web_614 leaves the room
[11:45:14] abdullahalshoaili_web_713 joins the room
[11:47:03] abdullahalshoaili_web_713 leaves the room
[11:47:11] abdullahalshoaili_web_599 joins the room
[11:47:15] Sara Dickinson_web_342 joins the room
[11:48:14] Sara Dickinson_web_342 leaves the room
[11:49:55] Ralf Weber_web_287 joins the room
[11:50:06] Ralf Weber_web_287 leaves the room
[11:50:10] Ralf Weber_web_765 joins the room
[11:50:15] Harald Alvestrand_web_401 joins the room
[11:50:24] abdullahalshoaili_web_599 leaves the room
[11:50:49] Brian Haberman_web_575 joins the room
[11:50:51] Sara Dickinson_web_616 joins the room
[11:51:12] abdullahalshoaili_web_321 joins the room
[11:51:42] Scott Hollenbeck_web_480 joins the room
[11:52:28] Sara Dickinson_web_616 leaves the room
[11:52:32] Sara Dickinson_web_689 joins the room
[11:53:39] Benjamin Schwartz_web_586 joins the room
[11:54:08] Ken Renard_web_768 joins the room
[11:54:38] James Galvin_web_857 joins the room
[11:54:42] Kazunori Fujiwara_web_684 joins the room
[11:54:52] Patrick Tarpey_web_305 joins the room
[11:55:31] Michael Hollyman_web_463 joins the room
[11:55:41] fightingnemo joins the room
[11:55:43] Ted Hardie_web_177 joins the room
[11:55:54] David Goldstein_web_456 joins the room
[11:55:59] Takahiro Nemoto_web_618 joins the room
[11:56:03] Jiankang Yao_web_538 joins the room
[11:56:06] Zaid AlBanna_web_871 joins the room
[11:56:08] Markus de Brün_web_280 joins the room
[11:56:17] Jonathan Reed_web_458 joins the room
[11:56:24] Daniel Gillmor_web_718 joins the room
[11:57:03] dkg joins the room
[11:57:24] Paul Hoffman_web_257 joins the room
[11:57:48] Allison Mankin_web_699 joins the room
[11:57:50] Stephen Farrell_web_362 joins the room
[11:57:52] Yuji Koyama_web_217 joins the room
[11:57:52] Nai-Wei Lo_web_162 joins the room
[11:57:53] Peter van Dijk_web_702 joins the room
[11:58:01] Jiri Novotny_web_826 joins the room
[11:58:11] Moritz Müller_web_371 joins the room
[11:58:13] Patrick Tarpey_web_305 leaves the room
[11:58:15] Andrew S_web_128 joins the room
[11:58:26] Warren Kumari_web_458 joins the room
[11:58:44] Shinta Sato_web_676 joins the room
[11:58:47] Sean Turner_web_136 joins the room
[11:58:49] Petr Špaček_web_178 joins the room
[11:58:57] Wes Hardaker_web_264 joins the room
[11:59:05] Juliana Guerra_web_424 joins the room
[11:59:09] Joey Salazar_web_308 joins the room
[11:59:09] <Christian Huitema_web_355> Dots! I finally realized we have IETF dots in the participant list!
[11:59:21] Craig Pearce_web_200 joins the room
[11:59:28] afregly@verisign.com_web_654 joins the room
[11:59:39] sftcd joins the room
[11:59:46] Suzanne Woolf_web_273 joins the room
[11:59:47] John Border_web_901 joins the room
[11:59:49] Jim Reid_web_788 joins the room
[11:59:50] Mike Bishop_web_510 joins the room
[11:59:53] Brett Carr_web_792 joins the room
[11:59:55] Kevin Fleming_web_267 joins the room
[11:59:56] Jasdip Singh_web_801 joins the room
[12:00:01] Emmanuel Bretelle_web_164 joins the room
[12:00:06] John Border_web_901 leaves the room
[12:00:10] John Border_web_753 joins the room
[12:00:20] Craig Pearce_web_200 leaves the room
[12:00:31] Mark Andrews_web_496 joins the room
[12:00:31] Richard Wilhelm_web_997 joins the room
[12:00:39] Eric Orth_web_389 joins the room
[12:00:40] Michael B_web_658 joins the room
[12:00:42] <Éric Vyncke_web_404> Better late than never ;-)
[12:00:45] Scott Rose_web_525 joins the room
[12:00:45] John Todd_web_125 joins the room
[12:00:50] Vittorio Bertola_web_503 joins the room
[12:01:00] Tommy Jensen_web_940 joins the room
[12:01:04] Eric Rescorla_web_305 joins the room
[12:01:09] <Tim Wicinski_web_148> "dots are  an IETF caste system"
[12:01:17] Chris Box_web_218 joins the room
[12:01:18] Mike Bishop_web_510 leaves the room
[12:01:21] Michael Breuer_web_555 joins the room
[12:01:22] Mike Bishop_web_711 joins the room
[12:01:22] Hiroyuki Goto_web_127 joins the room
[12:01:25] Duane Wessels_web_386 joins the room
[12:01:26] Jason Weil_web_326 joins the room
[12:01:52] Shivan Sahib_web_852 joins the room
[12:01:53] Peter Lowe_web_303 joins the room
[12:01:59] David Lawrence_web_124 joins the room
[12:02:00] Paul Wouters_web_758 joins the room
[12:02:05] Peter Thomassen_web_685 joins the room
[12:02:16] <Tim Wicinski_web_148> thanks Wes for the slides
[12:02:22] Shumon Huque_web_956 joins the room
[12:02:37] Eric Rosenberg_web_444 joins the room
[12:02:58] Robert Story_web_970 joins the room
[12:03:07] Robert Evans_web_528 joins the room
[12:03:10] Mike Bishop_web_711 leaves the room
[12:03:21] Andrew Campling_web_926 joins the room
[12:03:43] Dan McArdle_web_442 joins the room
[12:03:58] David Blacka_web_413 joins the room
[12:03:58] Chen Li_web_339 joins the room
[12:04:07] Mallory Knodel_web_421 joins the room
[12:04:15] <Tim Wicinski_web_148> all *rthree* authors
[12:04:27] Kris Shrishak_web_943 joins the room
[12:04:46] <dkg> +1 for reallocating 853/UDP to DoQ, and moving DTLS to historic
[12:04:47] Xavier de Foy_web_583 joins the room
[12:04:48] Mallory Knodel_web_421 leaves the room
[12:04:52] Mallory Knodel_web_715 joins the room
[12:04:54] <Allison Mankin_web_699> +1
[12:04:56] Peter Thomassen_web_685 leaves the room
[12:05:00] Peter Thomassen_web_119 joins the room
[12:05:03] <sftcd> sounds sensible to reallocate that port
[12:05:07] Jean-Michel Combes_web_626 joins the room
[12:05:07] joins the room
[12:05:10] Peter Thomassen_web_119 leaves the room
[12:05:10] Alessandro Ghedini_web_661 joins the room
[12:05:12] Erik Nygren_web_421 joins the room
[12:05:14] Peter Thomassen_web_660 joins the room
[12:05:17] <Shivan Sahib_web_852> +1
[12:05:19] Peter Thomassen_web_660 leaves the room
[12:05:20] Brian Dickson_web_843 joins the room
[12:05:23] Peter Thomassen_web_798 joins the room
[12:05:24] <Tim Wicinski_web_148> +1 (as not chair)  
[12:05:25] <> I don't care if we mark it as historic or not, but there's no technical reason you need to do so
[12:05:27] <Paul Hoffman_web_257> No slides, and much shorter than 30 minutes
[12:05:29] <> QUIC and DTLS are demuxable
[12:05:33] <Petr Špaček_web_178> Are we running out of port numbers or ...? It seems easier to just pick another number.
[12:05:44] Peter Thomassen_web_798 leaves the room
[12:05:46] <Peter van Dijk_web_702> ekr, I understand this is strictly a IANA process problem - the number can't have both names
[12:05:48] Peter Thomassen_web_220 joins the room
[12:05:55] <Sean Turner_web_136> Assume no IPR issues with salazar I-D? Just asking
[12:06:00] Martin Thomson_web_210 joins the room
[12:06:05] <Sara Dickinson_web_689> The issue is an IANA one as I understand it
[12:06:05] <> That seems like not a good reason to do something
[12:06:15] <Ted Hardie_web_177> I agree with EKR; if we change the name in IANA, that's fine, but the document still describes a working protocol.
[12:06:24] <> IANA exists to serve our needs, not the other way around
[12:06:25] Erik Nygren_web_421 leaves the room
[12:06:29] Erik Nygren_web_226 joins the room
[12:06:41] Mallory Knodel_web_715 leaves the room
[12:06:45] Mallory Knodel_web_808 joins the room
[12:06:46] <> I mean, we can just call it "DTLS/QUIC"
[12:06:49] <Kevin Fleming_web_267> still morning on the east coast of the US too :)
[12:06:49] Peter Thomassen_web_220 leaves the room
[12:06:52] <Sean Turner_web_136> +1 to what ekr said
[12:06:53] Alissa Cooper_web_110 joins the room
[12:06:53] Peter Thomassen_web_636 joins the room
[12:06:56] Robert Evans_web_528 leaves the room
[12:07:10] Robert Evans_web_700 joins the room
[12:07:16] <David Lawrence_web_124> What's the objection to moving it to historic, even if it doesn't strictly need to be?   Is it Ted's "still describes a working protocol"?  Because humanity has a pile of historic working protocols.
[12:07:39] <Jonathan Reed_web_458> ==tale, I don't understand why this is controversial
[12:07:41] <Peter van Dijk_web_702> a working protocol with zero implementations
[12:07:48] <Tim Wicinski_web_148> This chair is still waiting for an implementation
[12:07:49] <Christian Huitema_web_355> I would be fine with DTLS/QUIC.
[12:08:11] <> So I think we ought to have one of two positions: (1) Nobody should use DNS over QUIC or (2) the port is jointly assigned
[12:08:33] <Jim Reid_web_788> Since nobody seems to be using DNSoverDTLS, why should anyone care aboutthe status of the RFC? +1 to what Peter said.
[12:08:35] <Petr Špaček_web_178> To be clear: I'm not objecting to moving it to Historic status, I'm just saying that it seems like more work than "pick another number and be done with it".
[12:08:36] Mike Bishop_web_398 joins the room
[12:08:37] <> but "oh, the protocol is fine and people can use it but we should take the port away for administrative reasons...." not so ,uch
[12:08:38] Puneet Sood_web_115 joins the room
[12:08:47] <Peter van Dijk_web_702> Petr, but DoQ already has deployments
[12:08:49] Puneet Sood_web_115 leaves the room
[12:08:53] Puneet Sood_web_638 joins the room
[12:08:55] <> Beause the point of all this stuff is to signal to the world what they ought to do
[12:09:03] <> And so having them in inconsistent states is bad
[12:09:04] <Christian Huitema_web_355> And move to historic of DoD on the basis that this was an experiment and it saw no deployment.
[12:09:11] Jody Kolker_web_533 joins the room
[12:09:11] <Ted Hardie_web_177> Basically, I think this whole field is new enough that declaring something a dead idea is premature.  I think allocating the port to DoQ is fine, but, as ekr points out, that won't change the ability of someone to use the DTLS approach on the same port.
[12:09:12] Peter Thomassen_web_636 leaves the room
[12:09:13] <David Lawrence_web_124> I think some sort of flag should be there to indicate "yes, this could work, but it's almost certainly not worth pursuing".    Historic is good as one of those flags.
[12:09:16] Peter Thomassen_web_123 joins the room
[12:09:37] <> But that shouldn't go in IANA. It should go on the document!
[12:09:40] Samuel Weiler_web_795 joins the room
[12:09:45] Sile Yang_web_453 joins the room
[12:09:54] Dragana Damjanovic_web_644 joins the room
[12:09:56] <David Lawrence_web_124> I'm also pretty happy with not reusing the number.  y not both?
[12:10:10] evansr joins the room
[12:10:18] <> My point is just that these are unrelated issues
[12:10:21] <Benjamin Schwartz_web_586> I like reusing the number
[12:10:28] <David Lawrence_web_124> I am with that point.
[12:10:41] Bron Gondwana_web_517 joins the room
[12:10:54] <Petr Špaček_web_178> Maybe chairs can flip a coin for not/resuing the port so we can focus on actually important questions? :-)
[12:10:56] James Evans_web_418 joins the room
[12:10:58] Martin Thomson_web_210 leaves the room
[12:11:28] Jörg Backschues_web_650 joins the room
[12:11:29] <David Lawrence_web_124> and I'm pretty indifferent on reusing the number or not.  I'm as happy with reusing it as with not reusing it.
[12:11:31] <Jim Reid_web_788> Like arguing about what sort of coin they use? :-)
[12:11:56] <Ted Hardie_web_177> It seems simple enough to write a document instructing IANA to change the registration to DoQ, while noting that it can be demultiplexed.  That seems equal amount of work to the declaration of historic, and a better reflection of the potential state.  If we still don't have an implmentation in 5 years, sure, mark it historic.
[12:12:05] Martin Thomson_web_880 joins the room
[12:12:09] <dkg> +1: we all share the same goal of more confidential traffic where possible
[12:12:13] weiler joins the room
[12:12:18] <Tim Wicinski_web_148> It will be 5 years in February of 2022
[12:12:34] <Benjamin Schwartz_web_586> We've accomplished a lot in 5 years!
[12:12:40] <Ted Hardie_web_177> @Tim I meant 5 from now, but fair point.
[12:12:59] <sftcd> I assume some f/w products by now have checkboxes that block/unblock 853 - keeping the number for DoQ might speed up the unblocking of that by a little bit so I'd keep the number; I don't care about the RFC status.
[12:13:09] <dkg> wow 5 years, and still no widely-deployed ESNI/ECH :/
[12:13:31] <Martin Thomson_web_880> dkg: I blame those people who keep changing things for no good reason
[12:13:44] <dkg> i shake my fist
[12:13:59] <Petr Špaček_web_178> Don't forget that paint has barely dried out on DoT/DoH in DNS responders, so I don't think that DTLS DoT is necessary dead. Maybe it will be if QUIC libraries are in good shape and widely available, but it it was PITA to find something suitable a year ago (I did not look since).
[12:14:02] <dkg> (but not at the people who keep changing things for good reason)
[12:14:09] Hugo Kobayashi_web_789 joins the room
[12:14:28] <> My position is slightly different from Ted's. It is as follows: (1) There is no technical reason they can't share a port (2) As long as we think that DNS over DTLS is potentially a going concern, we should have that written in IANA (3) Whatever IANA rules there are about that are not a good reason (4) If we don't think DNS over DTLS is a going concern, the place to say that is by relabeling the RFC, not just putting something in IANA
[12:14:37] David Smith_web_133 joins the room
[12:14:49] Jaime Jimenez_web_928 joins the room
[12:14:59] <Tim Wicinski_web_148> Please remember all your comments when we start this on the mailing list.,
[12:15:01] <Brian Haberman_web_575> The chairs will kick this conversation off on the mailing list. Doesn't make sense to discuss in Jabber.
[12:15:04] Benno Overeinder_web_117 joins the room
[12:15:21] <dkg> can we still make wisecracks on jabber?
[12:15:27] <Christian Huitema_web_355> Isn't Jabber the actual WG meeting?
[12:15:28] <> Brian: thanks
[12:15:35] <David Lawrence_web_124> Makes as much sense to discuss on Jabber as anything ;-)
[12:15:58] <Ted Hardie_web_177> I'm honestly not sure what the slight differences are between ekr's position and mine, but whatever they are, they are slight.  I guess it might be that I don't care whether the registry says DoQ or lists both.
[12:16:16] <Christian Huitema_web_355> +1 Ted
[12:16:26] Matthew Quick_web_365 joins the room
[12:17:27] Alessandro Ghedini_web_661 leaves the room
[12:18:07] <Paul Wouters_web_758> some of the proposals were also basically impossible to deploy within 10 years.
[12:20:22] Antoin Verschuren_web_190 joins the room
[12:20:37] Jiankang Yao_web_538 leaves the room
[12:20:41] Jiankang Yao_web_622 joins the room
[12:21:22] Mallory Knodel_web_808 leaves the room
[12:21:32] <Paul Wouters_web_758> yeah. there we core issues with the suggestions, so i dont think directorate reviews would be very useful
[12:23:21] Taiji Kimura_web_735 joins the room
[12:23:55] <Tim Wicinski_web_148> I agree on waiting. There was a smart comment from someone on the wgchairs list about requesting reviews earlier in the process.
[12:24:24] Mallory Knodel_web_530 joins the room
[12:24:49] Jiri Novotny_web_826 leaves the room
[12:24:54] Patrick Tarpey_web_325 joins the room
[12:26:23] <Benjamin Schwartz_web_586> I support adoption of this draft.  And I also supported adoption last time when Paul Hoffman wrote it.
[12:26:41] <> Well, in a few years, someone else can write it
[12:28:22] <Paul Hoffman_web_257> Excellent point about STARTTLS (wince)
[12:28:42] Jiankang Yao_web_622 leaves the room
[12:28:46] Jiankang Yao_web_288 joins the room
[12:28:53] Rick Alfvin_web_465 joins the room
[12:29:25] Markus de Brün_web_280 leaves the room
[12:29:27] Barbara Stark_web_816 joins the room
[12:29:29] <Benjamin Schwartz_web_586> I'm fine with limiting this to DoT/Q.
[12:29:47] <Peter van Dijk_web_702> +1 DoH can get in the sea
[12:29:59] Taiji Kimura_web_735 leaves the room
[12:30:11] <> This seems like a reasonable point re: DoH, though I think if there was a lot of demand for DoH, it is easy to do in the way DKG suggests
[12:30:35] <Benjamin Schwartz_web_586> As DDR has found (in ADD), HTTPS + Opportunistic security is a very weird combination.
[12:30:47] <zulipbot> (Puneet Sood) Also fine with limiting to DoT/DoQ.
[12:31:06] <Christian Huitema_web_355> Where can I find DKG's draft?
[12:31:17] <Peter van Dijk_web_702>
[12:31:28] <Christian Huitema_web_355> Thanks
[12:31:38] <Joey Salazar_web_308> thanks Peter! beat me to it : )
[12:31:43] <Erik Nygren_web_226> Does this want to also mandate using alpn?  Otherwise I worry about cross-protocol attacks when sharing a cert.
[12:32:07] <Peter van Dijk_web_702> I think no protocol leaves the IETF without ALPN these days anyway, so I just assumed it'd do that.
[12:32:08] <Éric Vyncke_web_404> Getting those drafts in the data tracker before today meeting would have been better though...
[12:32:19] Rick Alfvin_web_465 leaves the room
[12:32:25] Sidan Qi_web_206 joins the room
[12:32:46] <Tim Wicinski_web_148> The chairs failed on following up with the authors Ertic
[12:32:54] <Éric Vyncke_web_404> ;-)
[12:33:58] <Paul Hoffman_web_257> Peter and I already sent Joey and DKG some comments on the things that he just listed.
[12:34:10] <Tim Wicinski_web_148> Thanks Peter and Paul !
[12:34:28] <Éric Vyncke_web_404> Those I-D could still be uploaded after this WG meeting to allow archiving and versioning on the mailing list discussions.
[12:34:51] <> I believe this is called HSTS :)
[12:35:31] <Christian Huitema_web_355> The SNI is a big issue, would deserve specific work.
[12:35:35] <Paul Hoffman_web_257> The slope just got steeper and slipperier
[12:36:15] <Joey Salazar_web_308> @Christian Huitema your thoughts on this on github would be most welcome!
[12:36:31] <Martin Thomson_web_880> Are you suggesting that the hard fail is an option, or a consequence of the presence of this configuration?
[12:37:04] <Paul Hoffman_web_257> Joey, my preference is that this happens on the mailing list.
[12:37:08] <Martin Thomson_web_880> ah, the reporting thing suggests that it is optional
[12:37:31] <Peter van Dijk_web_702> the reporting thing looks like an inkling of an idea, nothing more
[12:37:45] <Peter van Dijk_web_702> there's also Roy's dns error reporting draft (that DNSOP had an interim on, a few weeks ago)
[12:38:27] Mike Bishop_web_398 leaves the room
[12:38:40] Mallory Knodel_web_530 leaves the room
[12:38:43] <sftcd> TLSRPT has been important in getting mail services to move towards being less opportunistic I think - FWIW, reporting via mail seems more natural to me than via Roy's thing
[12:38:44] Mallory Knodel_web_454 joins the room
[12:39:44] <Joey Salazar_web_308> +1 dkg XD
[12:39:53] <Peter van Dijk_web_702> lol, nice work indeed
[12:39:59] <Tim Wicinski_web_148> +1 to provocations
[12:40:26] <Martin Thomson_web_880> what SNI would a signaled connection use?
[12:40:41] Craig Pearce_web_411 joins the room
[12:40:51] <Kevin Fleming_web_267> asking a large group "what do you want to do?" is never as productive as proposing something that nobody in the group wants to do :-)
[12:40:51] <Jim Reid_web_788> @Joey. Can we discuss your doc on the list and not github?
[12:40:53] <Peter van Dijk_web_702> the one in the signal that allows the connection to authenticate against a cert/key
[12:40:54] <Paul Wouters_web_758> the target ip is already well known, i doubt it is a new privacy leak
[12:41:11] <Andrew Campling_web_926> +1 to substantive discussion on the mailing list rather than github
[12:41:16] <Martin Thomson_web_880> Peter why would you trust the signal to provide you a reference identity?
[12:41:39] <Tim Wicinski_web_148> chairs prefer normative type discussions on the mailing list.  
[12:41:49] <Peter van Dijk_web_702> Martin, that depends on the signal - some of the proposals floated on the list (and even in the tracker) would reliably provide such a reference
[12:41:49] <Brian Haberman_web_575> Substantive comments on drafts should be on the mailing list
[12:42:05] <Martin Thomson_web_880> hmm, that seems problematic.  MX-problematic
[12:42:05] Bron Gondwana_web_517 leaves the room
[12:42:11] <Peter van Dijk_web_702> Correct!
[12:42:19] <Martin Thomson_web_880> :)
[12:42:26] <Éric Vyncke_web_404> Brian, Tim: +1 for using mailing list for substantive discussions
[12:42:33] <> I do think that you are going to need SNI because of the following logic: whatever HX-type signal you eventually want to send will need to be sent over this channel and will also need to be authenticated via this cert. And so the logic of HSTS means that it needs the right cert
[12:43:35] <Christian Huitema_web_355> Reading the draft, it seems like the obvious thing to do & easy to deploy.
[12:43:47] Mike Bishop_web_337 joins the room
[12:44:04] <> Well, it seems like the resolver could just statistically reject these connections
[12:44:28] <Christian Huitema_web_355> Great candidate for early usage is "resolving ECH"
[12:44:49] <Tim Wicinski_web_148> If someone feels more comfortable filing git issues, we trust the authors will summarize and bring to the mailing list.
[12:45:12] Craig Pearce_web_411 leaves the room
[12:45:16] Craig Pearce_web_290 joins the room
[12:45:55] <Paul Wouters_web_758> we can demux ports to other services to not endanger port 53
[12:46:02] <afregly@verisign.com_web_654> Seems their is an assumption of no qname minimization between resolver and authoritative.
[12:46:02] <Paul Wouters_web_758> other servers...
[12:46:11] <Paul Hoffman_web_257> I opened two issues on things that I didn't feel were necessarily WG items, but am happy to take them to the list as well.
[12:46:25] <tale > ?   I don't understand re qname min
[12:46:55] <afregly@verisign.com_web_654> Only the portion of the domain name needed by the authoritative is sent to it by a resolver.
[12:47:18] <afregly@verisign.com_web_654> So subdomains are removed if authoritative does not need them for response.
[12:47:34] Monika Ermert_web_808 joins the room
[12:48:14] <Joey Salazar_web_308> @Jim @Paul absolutely! we appreciate all type of input (git/ml) but indeed the ml is the best way to go
[12:48:19] <Benjamin Schwartz_web_586> Queue should be closed?
[12:48:56] <tale > Yes, I'm familiar with how qname min works.  I'm unclear on the assumption you're seeing.
[12:49:07] Ralf Weber_web_765 leaves the room
[12:49:22] <afregly@verisign.com_web_654> Why would you need to encrypt if qname minimization is being performed?
[12:49:27] <Martin Thomson_web_880> Maybe those who are concerned about the cost should talk to Adam Langley about managing TLS connection termination costs.
[12:49:37] <> Indeed. Or, like Cloudflare :)
[12:49:48] <Benjamin Schwartz_web_586> @afregly To keep label N+1 confidential at each step.
[12:50:28] <Brett Carr_web_792> Just to add weight to Brians comments. I think its a noble goal to have all rec>auth queries encrypted but large volume and critical auth operators like us (Nominet) are a very very long way from being willing to support that IMHO.
[12:50:35] <afregly@verisign.com_web_654> And why is that needed? Who's confidentiality does that protect for queries to root and TLDs?
[12:51:04] <afregly@verisign.com_web_654> That mainly return NS
[12:51:15] <afregly@verisign.com_web_654> referrrals
[12:51:18] <Benjamin Schwartz_web_586> It's the QNAME that's sensitive, typically the TLD+1.
[12:51:56] <sftcd> queries to TLDs contain what'll be the SNI in TLS in many cases, those are sensitive unlike almost all queries to the root, confusing the two isn't helpful
[12:52:15] <Andrew Campling_web_926> Also adding to Brian's comments, has anyone considered the additional resource cost and carbon footprint of moving to all rec>auth traffic being encrypted?
[12:52:18] Ralf Weber_web_114 joins the room
[12:52:19] <zulipbot> (Puneet Sood) @afregly also helps prevent flooding based cache poisoning attacks
[12:52:31] <Paul Hoffman_web_257> For Ekr: the uptake on STARTTLS for SMTP what very slow for a decade, and is now significant.
[12:53:43] Shinta Sato_web_676 leaves the room
[12:53:47] Shinta Sato_web_906 joins the room
[12:54:26] <Andrew Campling_web_926> +1 to asking auths what they want / are prepared to implement
[12:54:41] <Jim Reid_web_788> @Martin At scale, TLS transactions for DNS (20K+/s) are a very different beast from web traffic.
[12:54:47] <Brian Haberman_web_575> I have closed the queue.
[12:55:27] <> @Jim: there are plenty of at-scale free DoT/DoH recursives
[12:55:32] <Martin Thomson_web_880> Jim: people keep saying that, but 20k/s is not that much
[12:55:45] <> 20K+/s is a trivial amount for any big CDN
[12:55:50] <Wes Hardaker_web_264> I'll note one document from RSOs about encrypted DNS and the root:
[12:56:29] <sftcd> @wes: winning over the TLDs for this is much more important that the root IMO
[12:56:37] <> @Wes: yes, I've read this and i think it's misguided, but again, I've got other things to do than push ta rock uphill
[12:57:11] <Wes Hardaker_web_264> yes, agreed.  and the document says this: the root is the less critical target (and some dprive document says that too... with qname min on and aggressive nsec or 8806 even.... )
[12:57:15] Nicolai Leymann_web_580 joins the room
[12:57:29] <Petr Špaček_web_178> I personally done experiments with hundreds of thousands of TLS clients talking to a single DoT resolver and it is perfectly _feasible_ even on 5+ years old hardware. Of course operational _cost_ is a different matter and it surprises me that anyone is surprised to hear that increasing operational cost is met with pushback.
[12:57:43] <Wes Hardaker_web_264> (that "agreed" was with sftcd)
[12:58:15] <Martin Thomson_web_880> of course, the exactly rate at which a note can process HTTP requests is often considered proprietary information, but I have seen material that suggests that 20k/s is possible on relatively small scale  (Willy Tarreau had some great slides showing nanosecond-level measurements for request handling, with breakdowns on where code was run in kernel vs. user space)
[12:58:33] <> I'm not surprised to hear that it's met with pushback, but my point is that it's not *prohibitive*
[12:58:44] <Petr Špaček_web_178> But this is general dnsop/dprive problem. We like talking about protocols a lot, very often without buy-in from operators first.
[12:58:48] <Paul Wouters_web_758> that's a good point, re: probes
[12:58:55] Moritz Müller_web_371 leaves the room
[12:59:02] <Wes Hardaker_web_264> anything is possible.  there is just a cost that someone has to bear to make it possible.
[12:59:04] Yoshiro Yoneya_web_842 leaves the room
[12:59:08] Yoshiro Yoneya_web_812 joins the room
[12:59:11] <Christian Huitema_web_355> A separate project using QUIC is serving 25,000 connections per CPU core, so I think DoQ will eventually scale just fine.
[12:59:50] <Jim Reid_web_788> @ekr, it's easy to say the costs aren't prohibitive when you're not writing the cheques. :-)
[12:59:51] <> Wes: welll, these are the exact same arguments we heard about Web 10 years ago, but now ibasically it's recognized as a noni-issue
[13:00:08] Brett Carr_web_792 leaves the room
[13:00:12] Brett Carr_web_128 joins the room
[13:00:17] <Wes Hardaker_web_264> no, there is an additional cost of anything in the web too.  It's just *worth* it.
[13:00:19] <Petr Špaček_web_178> +1 Wes. It depends on cost threshold which somehow filtered down from shareholders down to engineering, which might not have anything in common with engineering assessment.
[13:00:38] <Jim Reid_web_788> Audio probs..
[13:00:38] <Christian Huitema_web_355> Also, we see that about 2/3rd of the CPU cost of QUIC are spent in the UDP APIs, so I suspect the difference between DoQ an Do53 is not that high...
[13:00:45] <> Wes: I strongly encourage you to watch Adam Langley's velocity talk. The point is that the incremental cost is actually very very low
[13:01:04] Richard Barnes_web_147 joins the room
[13:01:06] <sftcd> +1 to ekr's point about costs and 2011 (and the same happened for mail services too - once the big ones tried STARTLS their fear of TLS perf costs fell away almost immediately)
[13:01:11] Craig Pearce_web_290 leaves the room
[13:01:15] Craig Pearce_web_766 joins the room
[13:02:02] Jim Reid_web_788 leaves the room
[13:02:06] Jim Reid_web_314 joins the room
[13:02:23] <Martin Thomson_web_880> error reporting is interesting here
[13:02:29] <Petr Špaček_web_178> @ekr Look, I think me and also Wes are already sold. Go convince people who allocate resources for DNS in companies. DNS is seen as cost center which just eats resources and generates none, which is AFAIK a huge difference from web ecosystem.
[13:02:47] <sftcd> errors via mail will work better is my bet
[13:02:52] <Peter van Dijk_web_702> +1 on no SNI, again :)
[13:03:11] Bron Gondwana_web_306 joins the room
[13:03:14] <Jim Reid_web_314> I  give up
[13:03:15] <> @Petr: as I said quite a bit earlier, you do know that there are quite a few free DNS recursive DoH/DoT servers, right?
[13:03:18] <Martin Thomson_web_880> I don't see there being much point in SNI in this setting
[13:03:23] <Jim Reid_web_314> Will comment on the list.
[13:03:39] <Richard Barnes_web_147> MUST omit SNI seems like unnecessary fiddliness
[13:03:40] <evansr> I'm interested in hearing from DoT/Q experts on how to make resumption cheap enough that authoritatives can absorb the uptick in cost.
[13:03:43] <> @MT: I regret that we may actually need SNI
[13:03:45] <Joey Salazar_web_308> @Jim send your question here and we relay it on the mic?
[13:03:55] <Martin Thomson_web_880> ekr: virtual hosting?
[13:04:03] <Joey Salazar_web_308> or the list ofc, as you prefer : )
[13:04:05] <Erik Nygren_web_226> Changes in cost also take multiple years of planning for large providers.  eg, if hardware often has a 5-year upgrade lifecycle and is built for one workload (and associated attack capacity+model), changing that capacity just takes time.  This is a big concern from many ISPs for client to recursive as well: their budgets are often baked into 3+ year plans so even while expanding or deploying different/better hardware to handle DoX may eventually be desired, the practical reality is that it will take multiple years to get there, and operators need to have the control over that ramp.
[13:04:08] <Richard Barnes_web_147> like if my TLS stack already normally sends SNI, you're going to make me turn it off?
[13:04:18] <> Yeah, because it scopes the credential you provide which then scopes the HSTS thing
[13:04:39] <Peter van Dijk_web_702> Richard, the only reason to be that fiddly is so that "do use SNI" remains "free" to be used by (future) authenticated proposals. Otherrwise, I agree, and would only want to specify "auths should serve the same content regardless of SNI"
[13:04:41] <Martin Thomson_web_880> Richard: you can't send SNI for an IP address, so that seems fixable
[13:04:54] <sftcd> @Erik: yeah I think that'll be an issue for zones where the authoritatives are distribted over >1 operator
[13:05:12] <Peter van Dijk_web_702> (I don't have much empathy for "my TLS stack does this or that", all stacks I've seen are, at the API level, flexible enough)
[13:05:15] <Martin Thomson_web_880> ekr: is this because there are multiple logical nameservers on the same host?
[13:05:19] <Petr Špaček_web_178> @ekr Sure, but that does not change anything in the logic "it increases cost without business justification".
[13:05:23] <> @MT: possibly
[13:05:32] <Andrew Campling_web_926> @ekr: on free DoT/DoH recursive resolvers, the cost *may* of course be recouped elsewhere, depending on the business model.
[13:05:52] <Paul Wouters_web_758> SNI for privacy is not an issue, you are connecting to a well known nameserver IP address. So just send SNI anddecide on wether to ignore authentication or not
[13:05:53] <Richard Barnes_web_147> @Peter is the intent here to *not* be authenticated?  that seems super sketchy
[13:06:02] <Erik Nygren_web_226> @sftcd: this is part of where control over the configuration here is on the basis of the authority operator not the zone is going to be important.
[13:06:10] <sftcd> @Petr: at some point "better privacy" will be as accepted a biz justification as "better security", though in this case, the beneficiary is pretty distant form the auth operator for sure
[13:06:16] <Petr Špaček_web_178> @Andrew Oh it is, possibly with some exceptions.
[13:06:25] <Richard Barnes_web_147> and if you want to be unauthenticated / opportunistic, better to signal that with an additional extension
[13:06:27] <sftcd> @Erik: yep
[13:06:27] <Martin Thomson_web_880> so putting the nameserver name in the SNI seems like it might be easy enough; you got it from an NS record, after all
[13:06:29] <Peter van Dijk_web_702> Richard, intent, not necessary, but this draft and the previous one discussed are in fact unauthenticated. I believe Brian is going to present an authenticated proposal after.
[13:06:39] <Christian Huitema_web_355> There is discovery going on: what SNI is expected, what color of cert is expcted. Makes me thing of "do TOFU until the server publishes a clear signal".
[13:06:51] <Peter van Dijk_web_702> Martin, NS records in delegations are not even DNSSEC-signed
[13:06:54] <Ted Hardie_web_177> the IETF has never controlled deployment.  Saying that we want it gives us an engineering goal: make this cheap and easy.  But it will not create a flag day, bring on the police, or anything else.
[13:06:58] <Paul Hoffman_web_257> Brian: no one said that it was a *requirement* for all rescursive-to-authoritative. It is a long-term goal.
[13:07:12] <Shivan Sahib_web_852> "privacy bit"
[13:07:13] <> @christian: yes, but you may need the right cert to make that signal work. For instance, with HSTS, you need to have it sent over a properly authenticated channel
[13:07:25] <Martin Thomson_web_880> Peter: ah, but then you aren't able to authenticate anything then
[13:07:27] <Jim Reid_web_314> Thanks Joey. My comments are too long for this lousy typiest to type. Might as well start the mailing list discussion...
[13:07:33] <Christian Huitema_web_355> Of course some queries should be private, such as finding ECH related records.
[13:07:33] <Erik Nygren_web_226> TOFU has a big "poison the well" risk here that will prevent operators from enabling.
[13:07:38] <Kevin Fleming_web_267> yep to dkg's comments... people don't realize they need privacy until after they already needed it
[13:07:51] <> @Erik: I don't think it's TOFU one wants but rather HSTS
[13:08:07] <> i.e., delivered over a channel which only the legit operator can send
[13:08:09] <> i.e., delivered over a channel which only the legit operator can send
[13:08:15] <> s/send/control/
[13:08:17] <Paul Wouters_web_758> so dkg is suggesting we only allow eSNI DoQ / DoT / DoH ?
[13:08:27] Alissa Cooper_web_110 leaves the room
[13:08:38] <Paul Wouters_web_758> but eSNI stuff works .... over DNS ?
[13:08:55] <sftcd> Q: HOWTO protect the small numbers who absolutely need confidentiality? A: do it for everyone.
[13:09:00] <Tommy Jensen_web_940> +1, it's hard/impossible for a DNS client to decide when queries should be or do not need to be private. Not to mention privacy is for everyone, not a special case.
[13:09:14] <Peter van Dijk_web_702> +1
[13:09:18] <Kevin Fleming_web_267> +1
[13:09:20] <Christian Huitema_web_355> We discussed eSNI when writing DoQ. The position was to firmly say nothing.
[13:09:33] <Richard Barnes_web_147> I tend to think that if we can make an authenticated form, we should *not* do an unauthenticated one.  Authentication is just not that hard, especially in a strict hierarchy like the DNS.
[13:09:35] <> I don't think the "stuff comes in on encrypted transport" is going to work, because in the very near future, a huge fraction of that traffic is going to be over an encrypted transport as browser traffic moves there
[13:09:52] <Peter van Dijk_web_702> Richard, years of WG discussion would like to argue that apparently it is that hard..
[13:10:10] Patrick Tarpey_web_325 leaves the room
[13:10:14] <John Todd_web_125> The concerns about overwhelming the auth servers could be slowly feathered in by creating permitted lists of recursive egress IP addresses which an auth will recognize over time. This list can be generated out of band, or via some other signal method (TBD.)
[13:10:14] Patrick Tarpey_web_943 joins the room
[13:10:24] <Richard Barnes_web_147> @Peter - Things change over the years :)
[13:10:31] <Peter van Dijk_web_702> I hope so!
[13:10:33] <Benjamin Schwartz_web_586> To be clear: I mean that SNI must be omitted when using this probing-driven opportunistic mechanism.  When using an explicit signal, SNI must be included.
[13:10:33] <Paul Hoffman_web_257> Richard: Please send a draft so that we have something to discuss.
[13:10:36] <sftcd> @rlb: I disagree with that, 'cause of the way zones are distributed over >1 operator, I can't see how it's likely interesting zones (e.g. ccTLDs) could switch on auth all at once
[13:10:47] <Erik Nygren_web_226> @ekr: But for an operator to roll out HSTS, it is the last step of a very long chain of other steps beforehand where they can do things incrementally.  (eg, sending 302 redirects for some fraction of traffic, spend years fixing bugs/issues, and eventually send 302 for everything for long enough to ensure things work, then start sending HSTS but with a very low TTL and start stepping it up.)
[13:10:47] Craig Pearce_web_766 leaves the room
[13:10:54] <Ralf Weber_web_114> Looks Like I can not get the audio
[13:10:56] <Ralf Weber_web_114> to work
[13:11:03] <Ralf Weber_web_114> Sorry - will send mail to the list
[13:11:05] <Martin Thomson_web_880> Ben: Why is is necessary to create a distinction between probing and "for realsies"?
[13:11:09] <Joey Salazar_web_308> @Paul I don't quite understand your question, can you rephrase? we're saying let's not (SHOULD NOT) use SNI unless it's eSNI
[13:11:25] <Richard Barnes_web_147> @sftcd well, brute force would be Let's Encrypt.  you could ship that today.  If you want to be fancy and DS-like, you can provision multiple keys for all your servers.  easy peasy.
[13:11:51] <Richard Barnes_web_147> high performance, authenticated TLS service is a solved problem!
[13:11:56] <Peter van Dijk_web_702> except in DNS
[13:11:59] <sftcd> @rlb: no way it's easy peasy to get e.g. 5 independent operators to do any one thing at once
[13:11:59] <Peter van Dijk_web_702> where NS names in delegations are unsigned data
[13:12:03] <Richard Barnes_web_147> DNS is not a special snowflake
[13:12:07] <Paul Wouters_web_758> @joey: isnt eSNI information published in DNS to make it work ?
[13:12:08] <Richard Barnes_web_147> it's just another service
[13:12:12] <> Hence DS glue and the like
[13:12:20] Patrick Tarpey_web_943 leaves the room
[13:12:30] Peter Thomassen_web_123 leaves the room
[13:12:34] Peter Thomassen_web_750 joins the room
[13:12:36] <sftcd> @rlb: yes, web people tend to say that:-)
[13:12:49] <Richard Barnes_web_147> @sftcd if you can't coordinate technical ops across your zone, you have bigger problems
[13:12:55] <Erik Nygren_web_226> @Josh: downside of that by-IP approach is that it doesn't play well with also doing authenticated unless there's a way to distinguish clients.
[13:13:18] <Peter van Dijk_web_702> Richard, Ben's talk now should help you see the holes in the "easy peasy" :)
[13:13:30] <sftcd> @rlb: I've spoken to a few of 'em and no they don't have other problems they have decades-long arrangements with others and are sensibly keen to not bugger those up
[13:13:37] <Erik Nygren_web_226> It *would* be nice if unauth probing was visible in the handshake somehow to allow servers to distinguish.  That might help.
[13:13:48] <Peter van Dijk_web_702> Erik, ALPN?
[13:14:31] <Martin Thomson_web_880> Erik: what would the purpose of that distinguishing be?
[13:14:37] <sftcd> fwiw, claims that this is easy peasy seem as bogus to me as claims that there's no benefit in TLDs doing TLS because it's not interesting to the root
[13:14:47] <Peter van Dijk_web_702> +1
[13:15:15] <Paul Wouters_web_758> assuming query minimalization, yes
[13:15:19] <Martin Thomson_web_880> Because distinguishing probing in the clear makes it possible to selectively interfere with probing to deny people access to opportunistic upgrades
[13:15:25] Barbara Stark_web_816 leaves the room
[13:16:10] Barbara Stark_web_818 joins the room
[13:16:12] <> "This is the most important slide, but I won't show it for more than 30s" :)
[13:16:19] <Peter van Dijk_web_702> actually -this- is the most important slide :)
[13:16:26] <Sean Turner_web_136> :)
[13:16:29] <Paul Hoffman_web_257> +1
[13:16:37] <Paul Wouters_web_758> yes :)
[13:16:38] <Peter van Dijk_web_702> it mirrors things I have said on the list many times before
[13:16:44] Suzanne Woolf_web_273 leaves the room
[13:16:44] <Peter van Dijk_web_702> (and others have too)
[13:16:48] <sftcd> "briefly" :-)
[13:16:54] Suzanne Woolf_web_304 joins the room
[13:17:30] Peter Thomassen_web_750 leaves the room
[13:17:34] Peter Thomassen_web_907 joins the room
[13:17:52] Dragana Damjanovic_web_644 leaves the room
[13:17:54] Peter Thomassen_web_907 leaves the room
[13:17:58] Peter Thomassen_web_931 joins the room
[13:18:11] Joey Salazar_web_308 leaves the room
[13:18:15] Joey Salazar_web_898 joins the room
[13:19:08] <dkg> it's RRsets all the way down
[13:19:14] <sftcd> can a DSGLUE contain a DSGLUE (he asks not having read the draft:-)
[13:19:18] <Paul Hoffman_web_257> And up! :-)
[13:19:19] Ralf Weber_web_114 leaves the room
[13:19:23] Ralf Weber_web_520 joins the room
[13:19:25] <Martin Thomson_web_880> sftcd almost certainly
[13:19:30] Peter Thomassen_web_931 leaves the room
[13:19:34] Peter Thomassen_web_197 joins the room
[13:20:18] <Paul Wouters_web_758> not sure parents would be happy to host arbitrary data , possibly illegal stuff
[13:20:24] <Erik Nygren_web_226> mt: Biggest reason to distinguish probing is to be able to prioritize explicitly configured traffic (as the you want that to be able to hard-fail when rejected but also has more roll-out control) while probing traffic can hopefully get filtered/limited/etc.
[13:20:50] <Tim Wicinski_web_148> CDS sighting!  woot
[13:21:50] <sftcd> wow, this hack it getting involved
[13:21:59] <Martin Thomson_web_880> Erik: I am not sure that is a good idea.  If you have ADoT, then I would prefer that you treat all attempts equally.  Attempts to probe can, with access to the SVCB records and whatnot, turn into a pin for A2DoT)
[13:22:12] <weiler> stfcd++
[13:22:53] <Paul Hoffman_web_257> We would all like something less involved if it fulfills the use case. We haven't seen it yet.
[13:22:57] <Martin Thomson_web_880> I didn't read the draft, but this was perfectly comprehensible.  This isn't complicated relative to ECH.
[13:23:09] <sftcd> @paul: agreed
[13:23:13] <Martin Thomson_web_880> Though if ECH is the complexity bar, then we're doomed.
[13:23:31] <sftcd> @mt: depending on CDS deployment seems.... optimistic
[13:23:56] <weiler> didn't we have an RFC about points for expanding the DNS?
[13:24:12] <weiler> also, where's Bert Hubert to say "camel"?
[13:24:14] <Martin Thomson_web_880> is someone going to trot out the camel now?
[13:24:14] <Peter van Dijk_web_702> we do, I don't think it's very good
[13:24:25] <Peter van Dijk_web_702> (the expanding DNS document)
[13:24:53] XiPeng Xiao_web_655 joins the room
[13:25:51] <> Ben, you don't need to be in the queue
[13:26:14] <Brett Carr_web_128> It's a clever idea but... I think many operators shy away from DNSSEC because if of it's complexity adding another type of DS for a different reason is going to make that worse.
[13:26:21] <weiler> NO NO NO NO NO
[13:26:27] <sftcd> btw: I like Ben's last bullet about not being blocked
[13:26:35] <Peter van Dijk_web_702> tale,
[13:26:40] <Paul Wouters_web_758> bites on tongue
[13:26:43] <Brett Carr_web_128> I think if this flys it should be a new different RRTYPE
[13:26:55] <weiler> jonathan: we can't add new RRtypes that are ONLY at a parent.  for reasons.
[13:27:18] <Petr Špaček_web_178> That's a good point, but this is exactly then point where we need input from operators (that is all RRR pieces).
[13:27:20] <Paul Wouters_web_758> new RRtypes are fine. new RRtypes that move to the parent, is not. we can do a generic mechanism for this. but still that only helps us in 10 years. (and yes we should do it)
[13:27:26] <Wes Hardaker_web_264> if we could only put *all* child information in the parent, DNS would be so much faster
[13:27:28] <Peter van Dijk_web_702> I believe PaulW did a whole session about what's possible in the parent, at a previous session
[13:27:35] <Erik Nygren_web_226> This is part of where Tim April's NS2 draft defined two RRTypes (NS2 and NS2T).
[13:27:46] Frédéric Fieau_web_982 joins the room
[13:27:51] <Peter van Dijk_web_702> PaulW, want to email dnsop supporting my parent auth types draft then?
[13:28:38] <weiler> is EKR going to say "camel"?
[13:28:48] <Jim Reid_web_314> I'm having flashbacks to the zone cut semantics debates when dnsext was doing DNSSE.
[13:28:56] <Martin Thomson_web_880> weiler: I don't think so
[13:28:58] James Evans_web_418 leaves the room
[13:28:58] <Paul Wouters_web_758> @peter: I'll (re?)read it and comment
[13:29:00] <Erik Nygren_web_226> +1 to we should be willing to consider things that involve changes at the parent.  It may take longer, but none of this will happen overnight at scale no matter how we do it so we should be aiming for the most robust, most understandable, and most maintainable solution.
[13:29:04] Mallory Knodel_web_454 leaves the room
[13:29:06] XiPeng Xiao_web_655 leaves the room
[13:29:08] Mallory Knodel_web_106 joins the room
[13:29:17] <Peter van Dijk_web_702> PaulW, you did read it before and hated it, see the archives :)
[13:29:22] <Richard Barnes_web_147> +1 EKR
[13:29:28] James Evans_web_171 joins the room
[13:29:38] <Petr Špaček_web_178> +1 EKR. (Can I have +100, please?)
[13:29:56] <Peter van Dijk_web_702> I grant you a single use +100
[13:29:57] <tale > I think in the context of trying to do what the end goal here is, the problem of new rrtype rollout is not really a blocker.    
[13:30:06] James Evans_web_171 leaves the room
[13:30:08] <Paul Wouters_web_758> @peter I believe you. I am known to change my mind on new data :)
[13:30:17] <> And I forgot to say Paul's effort. Paul thanks for driving this for so long
[13:30:17] <weiler> Pvd: where is that RFC re: expansion points?  (I did some analysis back in rfc3755, but I'm not finding the newer doc)
[13:30:21] <Jonathan Reed_web_458> O
[13:30:25] <Martin Thomson_web_880> We saw that Jonathan maybe disagreed with the "no new RRs at the parent" conclusion, are there other contested points on the "most important slide"?
[13:30:28] <Peter van Dijk_web_702> Weiler, don't have it ready, sorry
[13:31:11] <Jonathan Reed_web_458> I didn't necessarily disagree with it.  But I'd like us to decide.   I'd like us to say "We are doing this because the WG does not meaningfully believe we can add new RRTYPEs in any sort of bounded time, so we're not going to try".
[13:31:40] Jasdip Singh_web_801 leaves the room
[13:31:51] <Jonathan Reed_web_458> We've all been _assuming_ we can't do it.  With good anecdata.   But as Ben notes, his proposal is predicated on this assumption.  So if we adopt Ben's doc, then the WG needs to adopt those answers to his question.
[13:31:53] Peter Thomassen_web_197 leaves the room
[13:31:57] Peter Thomassen_web_504 joins the room
[13:32:01] Peter Thomassen_web_504 leaves the room
[13:32:05] Peter Thomassen_web_429 joins the room
[13:32:40] David Blacka_web_413 leaves the room
[13:32:44] David Blacka_web_447 joins the room
[13:32:48] <Christian Huitema_web_355> How do we tie that with the probing draft?
[13:32:58] Alissa Cooper_web_233 joins the room
[13:33:20] <Jonathan Reed_web_458> +1 to dkg's "we need new signed record types in the parent"
[13:33:24] <> This is actually an important distinction between Ben's proposal and ADoX, which is we are willing to sacrifice the case where the parent zone was not retrieved securely
[13:33:26] <Petr Špaček_web_178> I'm going to make things even worse: Did people really read this article?What Can You Learn from an IP?:
Simran Patil and Nikita BorisovPresented at ANRW 2019: TL;DR is "there is no way tweak _just_ DNS to make it privacy-preserving", possibly unless almost everything is centralized on very few hosters.So yes, EKR might be right. We are wasting huge amounts of resources for a very marginal benefit.
[13:33:50] <Petr Špaček_web_178> Omg sorry for the formating, Meetecho does not like newlines, it seems.
[13:33:57] James Evans_web_179 joins the room
[13:34:02] <Brian Haberman_web_575> The mic line is closed.
[13:34:04] <> Actually, having things just centralized on hosters is *good" because it makes ECH work
[13:34:13] <Petr Špaček_web_178> Slides:
[13:34:19] <Petr Špaček_web_178> Paper:
[13:34:28] <Paul Wouters_web_758> Petr: thanks!
[13:34:52] <dkg> sorry, i missed: the other advantage to this proposal besides a new parent-signed record is that the existing pattern of recursor queries for DS doesn't need to change.
[13:35:16] <Peter van Dijk_web_702> dkg, well, there's some query reordering there, but it's true enough
[13:35:17] <dkg> so i actually prefer this over the idea of a new RR type
[13:35:22] Patrick Tarpey_web_408 joins the room
[13:35:33] <Scott Hollenbeck_web_480> @petr +1: even with encryption, there' a lot that can be learned by analyzing plaintext information (including IP addresses) exchanged between resolvers and authoritative name servers
[13:35:52] <> @Sott, @Petr: of course. We're trying to make *incremental* progress
[13:36:27] <> You've just got to take one step at a time
[13:36:32] <sftcd> +1 to ekr
[13:36:34] <Petr Špaček_web_178> @ekr Agreed - but we are reaching the point where incremental progress is very costly & at the same time seems to provide little benefit.
[13:36:47] Alissa Cooper_web_233 leaves the room
[13:36:53] <> Well, I think we just disagree on both of those claims
[13:37:12] <Warren Kumari_web_458> It feels like these are changes to the DNS itself, and need to be discussed in DNSOP.....
[13:37:23] <Peter van Dijk_web_702> (my new types draft was in dnsop)
[13:37:25] <sftcd> @petr: that research also e.g. points out that CDNs randomising address allocations could help a lot
[13:37:49] <dkg> "what can you learn from an IP" is a great paper -- it should *motivate* additional data encryption, not *demotivate* it.
[13:37:49] <Jonathan Reed_web_458> It feels like every time we try and make progress in anything here, someone says it should go in dnsop.   I'm not saying it's right or wrong.  But it's definitely frustrating.
[13:37:58] <Jonathan Reed_web_458> (here or add, for that matter)
[13:38:03] Craig Pearce_web_616 joins the room
[13:38:05] <> @sftcd: the situation is that right now there's no point in doing that because we don't have ECH, etc. So, yeah, we just need to do both
[13:38:12] <Paul Hoffman_web_257> Warren, we only need this in DNSOP if we have a use case in DPRIVE for it.
[13:38:15] <Paul Wouters_web_758> that sounds like my delegation_only draft - making parents commit to their own claims
[13:38:19] Craig Pearce_web_616 leaves the room
[13:38:23] Craig Pearce_web_835 joins the room
[13:38:25] <dkg> we already have a lot of evidence that IP addresses leak information: minimizing all other data leaks is necessary so that we can focus on offering IP-layer protections.
[13:38:32] <Petr Špaček_web_178> Sure, content on CDNs is more "hidden in crowd" - but only if most stuff is concentrated on CDNs, which is IMHO right the opposite of what it's needed for strong privacy.
[13:38:34] Peter Thomassen_web_429 leaves the room
[13:38:38] Peter Thomassen_web_594 joins the room
[13:38:40] <sftcd> @warren: personally, I think we need *some* deployment experience before we should bother the dnsop people about any of this
[13:38:58] <Warren Kumari_web_458> " The working group will work with
DNS operators and developers (via the DNSOP WG) to ensure that
proposed solutions address key requirements."
[13:39:11] Peter Thomassen_web_594 leaves the room
[13:39:15] Peter Thomassen_web_657 joins the room
[13:39:24] <Peter van Dijk_web_702> PaulW, here is the old thread with your old comments -
[13:39:29] Peter Thomassen_web_657 leaves the room
[13:39:33] Peter Thomassen_web_352 joins the room
[13:39:45] <Andrew Campling_web_926> @Petr Špaček: +1 on the privacy (and resilience) risks arising from allowing more centralisation on CDNs
[13:39:47] <Warren Kumari_web_458> @sftcd: The concern is that once things are deployed, it is really really hard to say No / undo them.
[13:39:59] <sftcd> @warren: right, but seems to me that all proposals so far are a bit speculative and haven't been tried - I'd argue we should try 'em (all) out but sure there's a risk
[13:40:12] <Jim Reid_web_314> IMO, the time to engage with dnsop wll be when we have an I-D has rough-ish consensus.
[13:40:24] <Jonathan Reed_web_458> ==jim, that's what I was trying to say
[13:40:55] <Éric Vyncke_web_404> @Warren: your point about DNSOP is taken
[13:41:32] <sftcd> I agree with @jim too, but also think we won't approach rough-consensus in the WG on this topic until someone can show they've done some experimental deployments
[13:41:38] Kevin Fleming_web_267 leaves the room
[13:41:42] Kevin Fleming_web_136 joins the room
[13:41:57] Alissa Cooper_web_175 joins the room
[13:42:02] <Peter van Dijk_web_702> there are experimental deployments of probing - which, of course, needs no help from DNSOP
[13:42:25] <Warren Kumari_web_458> @sftcd / Jim: Yes, but if the proposals are suggesting notable changes / additional complexity that DNSOP would need to deal with, having the conversation early / before it is a fait accompli is useful.
[13:42:36] <Warren Kumari_web_458> @Peter: Yup.
[13:42:47] <Warren Kumari_web_458> I suspect that we are all in violent agreement :-P
[13:42:51] <Peter van Dijk_web_702> :)
[13:44:11] <Jim Reid_web_314> I agree Warren. I think that would happen anyway because there's a lots of overlaop in the membership of both WGs. And a co-chair.
[13:44:27] Sara Dickinson_web_689 leaves the room
[13:44:55] Robert Story_web_970 leaves the room
[13:44:59] Robert Story_web_704 joins the room
[13:45:15] <Benjamin Schwartz_web_586> @Paul Wouters: Yes, I think adding  new authenticated parent RR Type would require something like your delegation-only flag in the super-parent.
[13:45:46] <Benjamin Schwartz_web_586> (and we would need a new flag like that every time we want to add more authenticated parent RRs)
[13:45:56] <Paul Wouters_web_758> @peter: my past self was not wrong :)
[13:46:06] <Peter van Dijk_web_702> ok! thanks for the clarity
[13:46:40] <Paul Wouters_web_758> @peter: it would be safer to limit the generic nature of things. and also, the parent publishing things in a special _label zone is also very valid
[13:46:45] <Petr Špaček_web_178> @Ben @Paul What about continuing this on dnsop list? It does not belong here anyway and the mailing list archive really should have this discussion.
[13:46:50] Jonathan Lennox_web_478 joins the room
[13:47:05] <Peter van Dijk_web_702> yes, _label is valid, although it is not cheap
[13:47:08] <Petr Špaček_web_178> (Because if it takes off, purely theoretically, it has potential to be biggest change since introduction of DNSSEC.)
[13:47:59] Puneet Sood_web_638 leaves the room
[13:48:03] Puneet Sood_web_473 joins the room
[13:48:16] <Benjamin Schwartz_web_586> I agree that it would be an enormous change.  For that reason, I don't view it as very promising.
[13:49:19] Jaime Jimenez_web_928 leaves the room
[13:50:03] <Petr Špaček_web_178> Unfortunately that's my view as well. On the other hand it would really boost extensibility of DNS protocol, so maybe it's still worth trying?
[13:50:34] <Sean Turner_web_136> @warren I keep wanting to high five you in the queue :)
[13:50:38] Patrick Tarpey_web_408 leaves the room
[13:50:42] Patrick Tarpey_web_520 joins the room
[13:51:34] <Brian Haberman_web_575> @sean No high-fives in the virtual queue!! :grinning:
[13:53:35] <Suzanne Woolf_web_304> FWIW, DNSOP co-chair here--  we'll do what  the WG  has consensus for, but generally we're trying to encourage implementation experience if not deployment experience  before attempting to  advance a document. For large chunks of protocol work we sometimes give drafts an initial home and then help launch a separate WG (DPRIVE,  ADD).
[13:53:49] <Suzanne Woolf_web_304> I *think* that's consistent with  what my AD just said.  :-)
[13:54:19] <Paul Hoffman_web_257> I note that there is a huge difference between the DSGLUE proposal and put all new types in TXT: DSGLUE is clearly differentiated from other algorithms
[13:54:23] <Tim Wicinski_web_148> From the Minutes: Brian and I have the following Action Items.  *Action Item: Will take this to the mailing list
    Moving DNS-over-DTLS to Historic
    Update name for port 853 to QUIC/DNSoDTLS*
*Action Item: Chairs will huddle with AD on  Use case discussion*
*Action Item: follow up on ekr's mechanism crafting comment*
[13:54:28] <Kevin Fleming_web_136> at least one draft suggests that sending a query in the TLS negotiation itself is an option, so that last point on the last slide may not be true
[13:54:44] <Brian Haberman_web_575> We are running short of time, so we will not take any comments/questions on Dickson's drafts. They will be presented in DNSOP later today as well.
[13:55:01] <Tim Wicinski_web_148> If foiks want us to have more action items, please add to the etherpad
[13:55:19] Alissa Cooper_web_175 leaves the room
[13:55:54] <Christian Huitema_web_355> @Tim this should be Update name for port 853 to DNSoQUIC/DNSoDTLS*
[13:56:02] <Peter van Dijk_web_702> -1
[13:56:28] <Tim Wicinski_web_148> Thanks @Christian
[13:56:31] <Christian Huitema_web_355> Or maybe use the protocol names reserved with IANA, ie., DoQ
[13:56:31] Scott Hollenbeck_web_480 leaves the room
[13:56:42] <Paul Wouters_web_758> so i think this also cannot protect in baliwick names?
[13:57:05] <Peter van Dijk_web_702> PaulW, Brian has a whole draft (glueless) on avoiding in-bailiwick names, yes
[13:57:16] <Peter van Dijk_web_702> that one might get more coverage in his dnsop presentation, I suppose
[13:57:28] Allison Mankin_web_699 leaves the room
[13:57:48] <Paul Wouters_web_758> i will have to really read all the drafts .....
[13:57:50] Sidan Qi_web_206 leaves the room
[13:58:02] <Peter van Dijk_web_702> you have two hours until DNSOP :D
[13:58:11] <Petr Špaček_web_178> They are mostly short so you can still make it :-)
[13:58:25] Scott Rose_web_525 leaves the room
[13:58:52] <Vittorio Bertola_web_503> There's actually PEARG in the middle :)
[13:58:56] Shivan Sahib_web_852 leaves the room
[13:59:08] Brett Carr_web_128 leaves the room
[13:59:17] <Martin Thomson_web_880> please look into the world hunger issue
[13:59:26] David Smith_web_133 leaves the room
[13:59:29] Sean Turner_web_136 leaves the room
[13:59:30] <Tim Wicinski_web_148> OF course @martin
[13:59:30] <Martin Thomson_web_880> climate change also
[13:59:32] Dan McArdle_web_442 leaves the room
[13:59:40] <Martin Thomson_web_880> thanks
[13:59:45] <Christian Huitema_web_355> carbon footprint of different proposals?
[13:59:48] Jason Weil_web_326 leaves the room
[13:59:55] Michael Hollyman_web_463 leaves the room
[13:59:58] Stephen Farrell_web_362 leaves the room
[14:00:00] <Martin Thomson_web_880> Christian: I was thinking more broadly than that
[14:00:07] Kris Shrishak_web_943 leaves the room
[14:00:07] Mike Bishop_web_337 leaves the room
[14:00:09] Andrew S_web_128 leaves the room
[14:00:09] Andrew Campling_web_926 leaves the room
[14:00:09] Nai-Wei Lo_web_162 leaves the room
[14:00:09] Paul Hoffman_web_257 leaves the room
[14:00:10] <Jim Reid_web_314> That's taking place 20Km away from me in Glasgow  thsi week.
[14:00:11] Chris Box_web_218 leaves the room
[14:00:11] David Blacka_web_447 leaves the room
[14:00:11] Mark Andrews_web_496 leaves the room
[14:00:11] Richard Barnes_web_147 leaves the room
[14:00:11] Ken Renard_web_768 leaves the room
[14:00:12] abdullahalshoaili_web_321 leaves the room
[14:00:12] Benjamin Schwartz_web_586 leaves the room
[14:00:12] Juliana Guerra_web_424 leaves the room
[14:00:13] Ralf Weber_web_520 leaves the room
[14:00:13] Hugo Kobayashi_web_789 leaves the room
[14:00:14] Richard Wilhelm_web_997 leaves the room
[14:00:15] Eric Rosenberg_web_444 leaves the room
[14:00:15] Shinta Sato_web_906 leaves the room
[14:00:15] sftcd leaves the room
[14:00:16] Peter Thomassen_web_352 leaves the room
[14:00:16] Daniel Gillmor_web_718 leaves the room
[14:00:17] Matthew Quick_web_365 leaves the room
[14:00:19] Jonathan Lennox_web_478 leaves the room
[14:00:21] Yuji Koyama_web_217 leaves the room
[14:00:25] Bron Gondwana_web_306 leaves the room
[14:00:27] Vittorio Bertola_web_503 leaves the room
[14:00:29] Takahiro Nemoto_web_618 leaves the room
[14:00:30] Barbara Stark_web_818 leaves the room
[14:00:32] Brian Haberman_web_575 leaves the room
[14:00:32] Éric Vyncke_web_404 leaves the room
[14:00:34] evansr leaves the room
[14:00:40] Tommy Jensen_web_940 leaves the room
[14:00:42] Patrick Tarpey_web_520 leaves the room
[14:00:46] Jonathan Reed_web_458 leaves the room
[14:00:46] Kevin Fleming_web_136 leaves the room
[14:00:46] Ted Hardie_web_177 leaves the room
[14:00:47] Emmanuel Bretelle_web_164 leaves the room
[14:00:47] Christian Huitema_web_355 leaves the room
[14:00:47] Benno Overeinder_web_117 leaves the room
[14:00:49] Wes Hardaker_web_264 leaves the room
[14:00:49] Shumon Huque_web_956 leaves the room
[14:00:50] Yoshiro Yoneya_web_812 leaves the room
[14:00:50] Eric Orth_web_389 leaves the room
[14:00:50] Samuel Weiler_web_795 leaves the room
[14:00:50] Robert Story_web_704 leaves the room
[14:00:53] Peter Lowe_web_303 leaves the room
[14:00:54] Suzanne Woolf_web_304 leaves the room
[14:00:54] Mallory Knodel_web_106 leaves the room
[14:00:55] Antoin Verschuren_web_190 leaves the room
[14:00:56] Sile Yang_web_453 leaves the room
[14:00:58] John Border_web_753 leaves the room
[14:00:58] Brian Dickson_web_843 leaves the room
[14:00:59] David Goldstein_web_456 leaves the room
[14:01:01] <Tim Wicinski_web_148> I'll be uploading minutes but I want to relisten to the session to cover all bases
[14:01:04] Duane Wessels_web_386 leaves the room
[14:01:04] Warren Kumari_web_458 leaves the room
[14:01:06] John Todd_web_125 leaves the room
[14:01:06] Eric Rescorla_web_305 leaves the room
[14:01:06] Robert Evans_web_700 leaves the room
[14:01:07] Michael B_web_658 leaves the room
[14:01:09] Tim Wicinski_web_148 leaves the room
[14:01:11] Jim Reid_web_314 leaves the room
[14:01:14] Martin Thomson_web_880 leaves the room
[14:01:15] Petr Špaček_web_178 leaves the room
[14:01:16] Paul Wouters_web_758 leaves the room
[14:01:21] afregly@verisign.com_web_654 leaves the room
[14:01:25] Yoshiro Yoneya leaves the room
[14:01:27] Zaid AlBanna_web_871 leaves the room
[14:01:44] Hiroyuki Goto_web_127 leaves the room
[14:01:50] Jean-Michel Combes_web_626 leaves the room
[14:01:50] Joey Salazar_web_898 leaves the room
[14:01:52] Kazunori Fujiwara_web_684 leaves the room
[14:01:56] Jiankang Yao_web_288 leaves the room
[14:02:06] Michael Breuer_web_555 leaves the room
[14:02:14] Xavier de Foy_web_583 leaves the room
[14:02:30] Meetecho leaves the room
[14:02:31] Craig Pearce_web_835 leaves the room
[14:02:57] Alessandro Amirante_web_834 leaves the room
[14:02:57] James Galvin_web_857 leaves the room
[14:02:57] Harald Alvestrand_web_401 leaves the room
[14:02:57] David Lawrence_web_124 leaves the room
[14:02:57] Chen Li_web_339 leaves the room
[14:02:57] Peter van Dijk_web_702 leaves the room
[14:02:57] Erik Nygren_web_226 leaves the room
[14:02:57] Jody Kolker_web_533 leaves the room
[14:02:57] Jörg Backschues_web_650 leaves the room
[14:02:57] Monika Ermert_web_808 leaves the room
[14:02:57] Nicolai Leymann_web_580 leaves the room
[14:02:57] Frédéric Fieau_web_982 leaves the room
[14:02:57] James Evans_web_179 leaves the room
[14:02:57] Puneet Sood_web_473 leaves the room
[14:06:10] alexamirante leaves the room
[14:25:28] fightingnemo leaves the room
[15:53:53] weiler leaves the room
[15:58:24] weiler joins the room
[16:56:02] leaves the room
[18:34:00] weiler leaves the room
[19:59:21] weiler joins the room
[21:11:32] weiler leaves the room
[22:42:38] weiler joins the room
[23:05:42] weiler leaves the room
[23:05:42] cjsu leaves the room
[23:05:42] halfshot leaves the room
[23:05:42] Vittorio Bertola leaves the room
[23:05:42] zyxbac leaves the room
[23:05:46] cjsu joins the room
[23:05:46] halfshot joins the room
[23:05:46] Vittorio Bertola joins the room
[23:05:46] zyxbac joins the room
[23:09:23] weiler joins the room
[23:18:44] weiler leaves the room
[23:48:45] dkg leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!