IETF
dnsop
dnsop@jabber.ietf.org
Thursday, November 11, 2021< ^ >
Benno Overeinder has set the subject to: IETF 112 DNSOP WG
Room Configuration
Room Occupants

GMT+0
[15:17:22] Yoshiro Yoneya joins the room
[15:34:13] Meetecho joins the room
[15:40:14] alexamirante joins the room
[15:45:03] Yoshiro Yoneya_web_358 joins the room
[15:45:03] Puneet Sood_web_680 joins the room
[15:45:03] Bruno Teixeira_web_148 joins the room
[15:45:03] Paolo Saviano_web_325 joins the room
[15:45:03] Tim Wicinski_web_945 joins the room
[15:45:03] Ching-Heng Ku_web_133 joins the room
[15:45:03] abdullahalshoaili_web_530 joins the room
[15:45:03] PE_web_421 joins the room
[15:45:57] abdullahalshoaili_web_530 leaves the room
[15:46:17] Benno Overeinder_web_495 joins the room
[15:46:37] abdullahalshoaili_web_884 joins the room
[15:46:58] Benno Overeinder_web_495 leaves the room
[15:47:08] Chi-Yuan Chen_web_239 joins the room
[15:47:13] Emiliano Spinella_web_288 joins the room
[15:47:19] Benno Overeinder_web_821 joins the room
[15:48:16] Yuji Koyama_web_475 joins the room
[15:48:20] Bruno Teixeira_web_148 leaves the room
[15:48:24] Bruno Teixeira_web_776 joins the room
[15:49:08] Ching-Heng Ku_web_133 leaves the room
[15:50:18] Kim Davies_web_291 joins the room
[15:50:29] Dan Wing_web_714 joins the room
[15:51:17] Kim Davies_web_291 leaves the room
[15:51:34] Steven Hartley_web_230 joins the room
[15:53:33] Suzanne Woolf_web_103 joins the room
[15:54:03] Kim Davies_web_989 joins the room
[15:54:17] David Lawrence_web_364 joins the room
[15:54:17] Mark Andrews_web_526 joins the room
[15:55:15] Hugo Salgado joins the room
[15:55:35] Peter van Dijk_web_507 joins the room
[15:55:42] Hugo Salgado_web_195 joins the room
[15:55:48] Nicklas Pousette_web_212 joins the room
[15:56:00] Paul Muchene_web_674 joins the room
[15:56:15] Pete Resnick_web_917 joins the room
[15:56:25] Kesara Rathnayake_web_415 joins the room
[15:56:32] Brian Haberman_web_967 joins the room
[15:56:47] Pete Resnick_web_917 leaves the room
[15:56:58] Scott Hollenbeck_web_982 joins the room
[15:57:02] Ralf Weber_web_331 joins the room
[15:57:18] Robert Story_web_532 joins the room
[15:57:25] Shinta Sato_web_521 joins the room
[15:57:44] Andrew Fregly_web_732 joins the room
[15:57:58] Fatima Zarinni_web_570 joins the room
[15:58:02] Petr Špaček_web_442 joins the room
[15:58:09] Puneet Sood_web_680 leaves the room
[15:58:10] Yoshitaka Aharen_web_633 joins the room
[15:58:12] <tale > tooooooo loud tooooo loud
[15:58:13] Puneet Sood_web_676 joins the room
[15:58:19] Alexey Melnikov_web_475 joins the room
[15:58:20] Peter Lowe_web_862 joins the room
[15:58:23] Michael Breuer_web_978 joins the room
[15:58:23] avri doria_web_307 joins the room
[15:58:29] Wes Hardaker_web_607 joins the room
[15:58:31] avri doria_web_307 leaves the room
[15:58:32] Alexey Melnikov_web_475 leaves the room
[15:58:35] avri doria_web_978 joins the room
[15:58:36] Alexey Melnikov_web_845 joins the room
[15:58:38] Puneet Sood_web_676 leaves the room
[15:58:39] Duane Wessels_web_901 joins the room
[15:58:41] <Petr Špaček_web_442> Sounds okay at this end ...
[15:58:41] Andrew Campling_web_444 joins the room
[15:58:41] <Tim Wicinski_web_945> who ? me?
[15:58:42] Puneet Sood_web_909 joins the room
[15:58:50] avri doria_web_978 leaves the room
[15:58:54] Ulrich Wisser_web_971 joins the room
[15:58:54] avri doria_web_310 joins the room
[15:58:57] <Petr Špaček_web_442> Well maybe because it's now silence :troll:
[15:59:00] Moritz Müller_web_878 joins the room
[15:59:03] <Benno Overeinder_web_821> tooo early tooo load?  :-)
[15:59:08] Paul Hoffman_web_778 joins the room
[15:59:09] avri doria_web_310 leaves the room
[15:59:10] Kazunori Fujiwara_web_702 joins the room
[15:59:12] fightingnemo joins the room
[15:59:13] Warren Kumari_web_492 joins the room
[15:59:13] avri doria_web_174 joins the room
[15:59:14] <tale > the purity of the silence was broken!
[15:59:21] avri doria_web_174 leaves the room
[15:59:22] Kevin Fleming_web_681 joins the room
[15:59:25] avri doria_web_944 joins the room
[15:59:27] <Petr Špaček_web_442> I could not resist, sorry.
[15:59:27] Takahiro Nemoto_web_277 joins the room
[15:59:28] <tale > it was shaping up to be the best dnsop \meeting ever
[15:59:32] Peter Koch_web_532 joins the room
[15:59:32] avri doria_web_944 leaves the room
[15:59:32] Paul Wouters_web_299 joins the room
[15:59:36] avri doria_web_444 joins the room
[15:59:38] Ray Bellis_web_189 joins the room
[15:59:41] <Benno Overeinder_web_821> load=loud
[15:59:42] Mike Bishop_web_350 joins the room
[15:59:43] David Blacka_web_342 joins the room
[15:59:55] Joey Salazar_web_310 joins the room
[16:00:00] Sara Dickinson_web_149 joins the room
[16:00:04] Andrew S_web_523 joins the room
[16:00:07] Jasdip Singh_web_715 joins the room
[16:00:19] Puneet Sood_web_909 leaves the room
[16:00:20] Michael StJohns_web_428 joins the room
[16:00:20] James Gould_web_748 joins the room
[16:00:23] Puneet Sood_web_114 joins the room
[16:00:23] <Warren Kumari_web_492> Yay for new headsets..
[16:00:25] <Tim Wicinski_web_945> we are sorry @tale -
[16:00:27] Shumon Huque_web_591 joins the room
[16:00:28] Ken Renard_web_588 joins the room
[16:00:29] Hugo Kobayashi_web_557 joins the room
[16:00:30] Tom Hill_web_847 joins the room
[16:00:31] Eric Orth_web_287 joins the room
[16:00:38] <Warren Kumari_web_492> Doh! and I forgot to mute...
[16:00:38] Michelle Cotton_web_358 joins the room
[16:00:43] Harald Alvestrand_web_118 joins the room
[16:00:46] avri doria_web_444 leaves the room
[16:00:49] Jonathan Reed_web_185 joins the room
[16:00:49] Ted Lemon_web_834 joins the room
[16:00:50] avri doria_web_203 joins the room
[16:00:50] Shivan Sahib_web_671 joins the room
[16:00:54] Monika Ermert_web_838 joins the room
[16:00:57] Joao Damas_web_542 joins the room
[16:00:59] <Andrew Campling_web_444> They had a ukulele in SAAG just now to break the silence before starting ....
[16:01:01] Puneet Sood_web_114 leaves the room
[16:01:02] Vittorio Bertola_web_585 joins the room
[16:01:05] Puneet Sood_web_634 joins the room
[16:01:06] Brett Carr_web_848 joins the room
[16:01:06] Peter Thomassen_web_715 joins the room
[16:01:08] Mohamed Boucadair_web_504 joins the room
[16:01:08] Ted Lemon_web_834 leaves the room
[16:01:09] Scott Rose_web_947 joins the room
[16:01:12] Ted Lemon_web_303 joins the room
[16:01:12] <Warren Kumari_web_492> How is everyone? Hanging in there?
[16:01:21] <Warren Kumari_web_492> Enjoying Madrid?
[16:01:26] Sergey Myasoedov_web_900 joins the room
[16:01:30] Joel Jaeggli_web_164 joins the room
[16:01:39] Mike StJohns joins the room
[16:01:44] Tommy Jensen_web_966 joins the room
[16:01:53] <Warren Kumari_web_492> The little Spanish ham roll things are great!
[16:01:57] Stuart Cheshire_web_247 joins the room
[16:02:00] avri doria_web_203 leaves the room
[16:02:04] avri doria_web_266 joins the room
[16:02:06] Dan McArdle_web_860 joins the room
[16:02:18] Qiaoyu Deng_web_616 joins the room
[16:02:18] <Mike StJohns> no fair talking about food that's not available in my house
[16:02:19] Lixia Zhang_web_545 joins the room
[16:02:31] Juliana Guerra_web_667 joins the room
[16:02:36] Benjamin Schwartz_web_236 joins the room
[16:02:36] Emmanuel Bretelle_web_533 joins the room
[16:02:58] Ching-Heng Ku_web_821 joins the room
[16:03:01] avri doria_web_266 leaves the room
[16:03:02] <Suzanne Woolf_web_103> My desk in my attic office does *not* look like I'm in Madrid....should have hung up some photos or something
[16:03:03] <Petr Špaček_web_442> I could have shared picture of a cake iIf Meetecho supported that to give you a sense of cafeteria...
[16:03:05] avri doria_web_975 joins the room
[16:03:09] avri doria_web_975 leaves the room
[16:03:11] Jim Reid_web_868 joins the room
[16:03:13] avri doria_web_801 joins the room
[16:03:15] Samuel Weiler_web_576 joins the room
[16:03:23] Erik Nygren_web_716 joins the room
[16:03:38] <Warren Kumari_web_492> https://www.wholefoodsmarket.com/product/la-quercia-sliced-jamon-iberico-americano-b08cbx36fd  ?!
[16:03:43] <Kim Davies_web_989> Thanks!
[16:03:47] Lixia Zhang_web_545 leaves the room
[16:03:54] Emmanuel Bretelle_web_533 leaves the room
[16:03:57] <Andrew Campling_web_444> :beer:
[16:03:58] Emmanuel Bretelle_web_608 joins the room
[16:04:10] John Levine_web_379 joins the room
[16:04:13] <Paul Wouters_web_299> reduce the backlog more :)
[16:04:19] avri doria_web_801 leaves the room
[16:04:24] avri doria_web_850 joins the room
[16:04:25] <Paul Hoffman_web_778> PaulH agrees with PaulW
[16:04:32] <Petr Špaček_web_442> +1
[16:05:04] Olaf Kolkman_web_426 joins the room
[16:05:23] <Vittorio Bertola_web_585> @Warren: I get a splash page that asks me whether I really want to go to the US site, or would I rather get the UK one. If I pick the US site, I get sent back to the same splash page again and again. So it's really not a choice - no American jamon in Europe, only the Spanish one.
[16:05:24] Peter Feil_web_575 joins the room
[16:05:29] John Todd_web_189 joins the room
[16:05:35] Chen Li_web_670 joins the room
[16:05:37] <Warren Kumari_web_492> https://datatracker.ietf.org/doc/draft-davies-int-historic/ : "The document marks as historic any "int" domain names that were
   designated for infrastructure purposes, and identifies them for
   removal from the "int" top-level domain.  Any implementation that
   involves these domains should be considered deprecated.  This
   document also updates RFC 1591 by removing the documented use of
   "int" for international databases." --- I'm hoping IETF LC this soon, any comments appreciated.
[16:06:01] Vasilis_web_784 joins the room
[16:06:04] Zaid AlBanna_web_488 joins the room
[16:06:13] avri doria_web_850 leaves the room
[16:06:20] <Warren Kumari_web_492> @Vittorio: That was for MsJ -- you have the advantage of living in Europe....
[16:06:20] David Smith_web_684 joins the room
[16:06:31] Lixia Zhang_web_945 joins the room
[16:07:07] Brian Dickson_web_851 joins the room
[16:07:17] <Warren Kumari_web_492> But, if you send me much money via PayPal I'll order it for you, and then ship it... via surface mail....  :-P
[16:07:38] avri doria_web_782 joins the room
[16:07:43] Emmanuel Bretelle_web_608 leaves the room
[16:07:47] Emmanuel Bretelle_web_559 joins the room
[16:07:53] avri doria_web_782 leaves the room
[16:07:57] avri doria_web_269 joins the room
[16:07:57] avri doria_web_269 leaves the room
[16:08:01] avri doria_web_239 joins the room
[16:08:05] Emmanuel Bretelle_web_559 leaves the room
[16:08:09] Emmanuel Bretelle_web_530 joins the room
[16:08:17] <Petr Špaček_web_442> @Warren Did it go to mailing list? I have seen it at dns-operations@ and then encouraged Kim to move to dnsop, but did not hear since then.
[16:08:41] Weiler joins the room
[16:09:05] avri doria_web_239 leaves the room
[16:09:38] <Warren Kumari_web_492> @Petr: It did, but quite a while back. Kim/I will send reminders / call for feedback closer to the time....
[16:10:00] <Kim Davies_web_989> I sent it to the list but it may have been caught in moderation. We can resend.
[16:10:11] <Warren Kumari_web_492> I don't think that it is really appropriate for adoption by DNSOP, but I **do** want DNSOP input.
[16:10:22] <Warren Kumari_web_492> Oh, well, there we go then :=)
[16:10:27] Emmanuel Bretelle_web_530 leaves the room
[16:10:31] Emmanuel Bretelle_web_124 joins the room
[16:10:39] Peter Thomassen_web_715 leaves the room
[16:10:43] Peter Thomassen_web_688 joins the room
[16:10:55] Antoin Verschuren_web_588 joins the room
[16:11:05] <Hugo Salgado> @Tim About rrserial, I plan some minor updates before expiration, hope to have implementations running too.
[16:11:16] <Paul Hoffman_web_778> There will also hopefully be good discussion in IETF Last Call
[16:11:29] <Petr Špaček_web_442> I can't find it in https://mailarchive.ietf.org/arch/browse/dnsop/?q=.int or https://mailarchive.ietf.org/arch/browse/dnsop/?q=kim+davies :shrug:
[16:11:38] Florence D_web_842 joins the room
[16:12:05] <Paul Wouters_web_299> from a process point of view, these dickson drafts came late and should have gone through the list before getting to face time. (I'm very interested in time, but had to rush reading it and not very happy about the process followed here)
[16:12:22] <Peter van Dijk_web_507> +1
[16:12:45] <Brian Dickson_web_851> Very sorry... I had been doing updates but not sharing/spamming the lists on each minor update.
[16:13:05] <Mike StJohns> @warren - I think doing the int document would be good.  I lost track of who is the current .INT owner and lookup.icann.org fails to provide that.  At multiple points it was me (at DDN and then at ARPA), but I think I pawned it off on NSF at some point.  It would be useful to have a statement identifying the domain owner and giving consent.
[16:13:06] Viktor Dukhovni_web_237 joins the room
[16:13:15] <Peter van Dijk_web_507> Brian, that doesn't help in getting feedback either :)
[16:13:27] <Peter van Dijk_web_507> (I also note you never responded to the feedback I did post on an earlier version)
[16:13:34] <Paul Wouters_web_299> brian: again, i am happy for the drafts and discusion. but dnsop always runs out of time so i think the chairs should have done more pushback with respect to putting it into this IETFs face to face meeting.
[16:13:34] <Paul Hoffman_web_778> Brian: without us understanding the use case, it is hard to understand what is being presented
[16:13:40] Andrew S_web_523 leaves the room
[16:13:50] Richard Wilhelm_web_422 joins the room
[16:13:57] Simon Hicks_web_791 joins the room
[16:13:58] <Benno Overeinder_web_821> noted Paul W.
[16:14:02] avri doria_web_499 joins the room
[16:14:11] avri doria_web_499 leaves the room
[16:14:15] avri doria_web_685 joins the room
[16:14:16] Ulrich Wisser_web_971 leaves the room
[16:14:17] avri doria_web_685 leaves the room
[16:14:20] Ulrich Wisser_web_819 joins the room
[16:14:24] avri doria_web_672 joins the room
[16:14:36] <Tim Wicinski_web_945> noted Paul W.
[16:14:42] <Peter Thomassen_web_688> The <= 100 and <= 150 numbers are in contradiction
[16:14:48] avri doria_web_672 leaves the room
[16:14:52] avri doria_web_870 joins the room
[16:14:54] Florence D_web_842 leaves the room
[16:14:55] <Peter van Dijk_web_507> oh indeed they are
[16:14:55] <John Levine_web_379> @mike there is a link to .int on the www.iana.org home page
[16:15:20] <Paul Wouters_web_299> maybe they meant 100 - 150 as a range ?
[16:15:39] Robert Evans_web_643 joins the room
[16:15:40] Stuart Card_web_964 joins the room
[16:15:41] <Warren Kumari_web_492> @Petr: Huh. looks like I / we hadn't actually sent mail to DNSOP yet -- I'd seen the subject "[dns-operations] Deprecating infrastructure .INT domains" and my brain autocorrect did s/dns-operations/dnsop/ :-P
[16:15:41] Lixia Zhang_web_945 leaves the room
[16:15:45] <Peter van Dijk_web_507> I'm quite convinced they don't
[16:15:51] Ulrich Wisser_web_819 leaves the room
[16:15:56] avri doria_web_870 leaves the room
[16:16:00] avri doria_web_302 joins the room
[16:16:01] <Mike StJohns> @john - so this is considered an undelegated domain now?
[16:16:07] Robert Evans_web_643 leaves the room
[16:16:11] Robert Evans_web_677 joins the room
[16:16:18] <Mike StJohns> @john this -> .int
[16:16:19] <Paul Wouters_web_299> insecure, not undelegated
[16:16:26] Emmanuel Bretelle_web_124 leaves the room
[16:16:27] <Paul Wouters_web_299> oh sorry. different discussion :
[16:16:30] Emmanuel Bretelle_web_131 joins the room
[16:16:38] avri doria_web_302 leaves the room
[16:16:42] avri doria_web_222 joins the room
[16:16:49] <Kim Davies_web_989> @Mike Operating INT is part of the IANA functions
[16:17:05] <Peter Koch_web_532> how many of those dnsop(!) participants run NSEC3 for non-opt-in purposes, i.e., are interested in mitigating zone-walking?
[16:17:16] Robert Evans_web_677 leaves the room
[16:17:20] Robert Evans_web_460 joins the room
[16:17:23] avri doria_web_222 leaves the room
[16:17:27] avri doria_web_144 joins the room
[16:17:28] <Tim Wicinski_web_945> Sorry @Kim I wasn't throwing you under the DNSOP bus.  
[16:17:30] Ulrich Wisser_web_493 joins the room
[16:17:53] avri doria_web_144 leaves the room
[16:17:57] avri doria_web_533 joins the room
[16:17:58] avri doria_web_533 leaves the room
[16:17:59] Michael Hollyman_web_246 joins the room
[16:18:02] avri doria_web_367 joins the room
[16:18:03] avri doria_web_367 leaves the room
[16:18:07] avri doria_web_811 joins the room
[16:18:08] Ulrich Wisser_web_493 leaves the room
[16:18:12] Ulrich Wisser_web_583 joins the room
[16:18:21] Florence D_web_787 joins the room
[16:18:31] Ulrich Wisser_web_583 leaves the room
[16:18:35] Ulrich Wisser_web_629 joins the room
[16:18:41] <Mike StJohns> @kim - thanks.  So it's considered undelegated and if the root zone management moved .int management would move with it (not that that will happen).
[16:18:45] Robert Evans_web_460 leaves the room
[16:19:09] Michael Hollyman_web_246 leaves the room
[16:19:13] Michael Hollyman_web_280 joins the room
[16:19:34] Patrick Tarpey_web_687 joins the room
[16:19:36] <Suzanne Woolf_web_103> @Paul-- setting the agenda is always something of a balancing act, but one purpose of doing the interims is to allow more time for substantive technical issues and not run out of time in "IETF week" meetings. We're still experimenting, and appreciate the feedback.
[16:19:55] avri doria_web_811 leaves the room
[16:20:03] Ulrich Wisser_web_629 leaves the room
[16:20:07] Ulrich Wisser_web_345 joins the room
[16:20:27] <Kim Davies_web_989> .int is delegated and in active use by intergovernmental treaty organizations today. The draft is just about cleaning up legacy pre-2001 references for experimental "international databases", stuff like tpc.int and using ip4.int instead of in-addr.arpa. My view this is a somewhat overdue housecleaning.
[16:20:36] <Warren Kumari_web_492> draft-davies-int-historic doesn't remove .int, only some .int domain names that were  designated for infrastructure purposes .
[16:21:08] <Warren Kumari_web_492> Yup, what Kim said.
[16:21:11] <Suzanne Woolf_web_103> @Kim IIRC all of the infrastructure .arpa domains have been formally obsoleted or deprecated, yes?
[16:21:14] Juan Cerezo_web_699 joins the room
[16:21:23] avri doria_web_829 joins the room
[16:21:48] <tale > servfail sends resolvers rotating through all auths
[16:21:49] <Kim Davies_web_989> @Suzanne - that is the objective of the draft, they are not yet all formally obsoleted
[16:22:04] Chris Box_web_960 joins the room
[16:22:08] <tale > oh nm, that's to the client
[16:22:11] <Peter van Dijk_web_507> Tale, that does not ring universally true
[16:22:14] <Peter van Dijk_web_507> ack
[16:22:19] <Mike StJohns> @kim - if this is delegated it needs a delegation record in whois I think?
[16:22:19] <Suzanne Woolf_web_103> Right, thanks-- no loose ends though
[16:22:41] <Paul Wouters_web_299> servfail would require a (i dont believe i am saying this)   a DNS flag day
[16:22:56] <tale > we don't believe you're saying it either
[16:23:03] <tale > who are you and what have you done with paul
[16:23:13] <Peter van Dijk_web_507> you only need a flag day if you want parameter abuse to continue for too long ;)
[16:24:34] <John Levine_web_379> @mike what whois do you mean? whois.iana.org knows all about it
[16:24:53] <Jim Reid_web_868> Icky policy concerns: what does the validator do if it ends up with an "insecure" answer that might validate?
[16:25:15] Florence D_web_787 leaves the room
[16:25:36] <Mike StJohns> @john - thanks - I expected it at internic.net actually.
[16:25:36] <Paul Wouters_web_299> +1 on Petr
[16:25:38] <Suzanne Woolf_web_103> Meetecho has this cool new button for locking the queue without having to interrupt people at the mic-- at the top of the left-hand edge of the display, lights up red
[16:25:55] <Peter Thomassen_web_688> +1 Petr
[16:26:00] <Suzanne Woolf_web_103> (Thank you @meetecho)
[16:26:56] <Peter Thomassen_web_688> The validator-SHOULD includes iterations = 1, and is then immediately overriden by MAY for iterations = 1.
--> The SHOULD should be for iterations > 1
[16:27:00] avri doria_web_829 leaves the room
[16:27:04] avri doria_web_945 joins the room
[16:27:06] <Peter Koch_web_532> I do not believe that it is useful for a dnsop(!) group to not reflect operational practice; I am seriously concerned about the way of decision making
[16:27:38] <Peter van Dijk_web_507> pt, Wes did mention the slide was wrong there(and I also think it is a very confusing way to communicate it)
[16:27:46] <Paul Wouters_web_299> Peter: i almost made a joke about creating DNSIMPL. I agree with you.
[16:27:59] Paul Muchene_web_674 leaves the room
[16:28:03] Paul Muchene_web_519 joins the room
[16:28:15] Robert Evans_web_773 joins the room
[16:28:40] Paul Muchene_web_519 leaves the room
[16:28:44] Paul Muchene_web_102 joins the room
[16:28:58] <Peter Thomassen_web_688> What happens if you "ask to share slides", as opposed to "share screen"?
[16:28:59] <Wes Hardaker_web_607> @PeterK: so what would you put in the document?  Would you document current practice as a standard and update it later, recognizing that current values are a source of attack?
[16:29:21] Paul Muchene_web_102 leaves the room
[16:29:25] Paul Muchene_web_122 joins the room
[16:29:59] <Peter van Dijk_web_507> I always considered the servfail range as an attack surface and would still like it gone :)
[16:30:01] Paul Muchene_web_122 leaves the room
[16:30:05] Paul Muchene_web_168 joins the room
[16:30:35] Patrick Tarpey_web_687 leaves the room
[16:31:18] <Paul Wouters_web_299> @wes: add this evaluation to RFC 8640bis
[16:31:19] <Peter van Dijk_web_507> (oh, that's not the attack you meant)
[16:31:36] <Kevin Fleming_web_681> @Peter T: i believe 'ask to share slides' loads the slide deck into your Meetecho client directly, as opposed to Meetecho capturing some part of your system's screen
[16:31:36] <Paul Wouters_web_299> 8624
[16:32:01] Robert Evans_web_773 leaves the room
[16:32:02] <Wes Hardaker_web_607> yeah, that's a lot more work
[16:32:06] Gianpaolo Scalone_web_918 joins the room
[16:32:17] <Andrew Campling_web_444> @Peter: Share Slides uses pre-loaded material, takes less bandwidth than sharing screen
[16:32:39] <Peter Thomassen_web_688> aha. Will it ask for uploading something (pdf, pptx?) or will it offer a selection from what's uploaded to the agenda?
[16:32:53] PE_web_421 leaves the room
[16:32:58] Fatima Zarinni_web_570 leaves the room
[16:33:02] <Meetecho> Peter: chairs can import them from the materials page
[16:33:20] <Meetecho> There's a dialog in the UI they can use for the purpose
[16:33:36] PE_web_107 joins the room
[16:33:43] Robert Evans_web_775 joins the room
[16:34:33] <Peter Koch_web_532> deploying validators that either SERVFAIL or treat zones as insecure for iterations > 0 appears like a "source of attack", too, doesn't it?   the approach feels a putting the cart before the horse; ttyo
[16:34:37] Jiri Novotny_web_204 joins the room
[16:34:41] <Petr Špaček_web_442> @Peter Koch I'm also curious what is your operational problem with the proposal. Nobody is taking NSEC3 away, so the protection it provides from "causal" zone walking will stay in place.
[16:35:38] Sergey Myasoedov_web_900 leaves the room
[16:35:53] <Tim Wicinski_web_945> As an operational person, I like this document a lot.  As a chair, please don't stop working on this!
[16:36:11] <Wes Hardaker_web_607> @peterK: so, lets start with a goal: the goal should be iterations=0 right?  Then the path to get to that goal, via documentation, is where the mud lies.
[16:36:14] <Brian Dickson_web_851> Yes, but it does that by making the entire zone insecure if the iterations > 1 is the case. For e.g. TLDs, this may not be a good thing.
[16:36:47] <Brian Dickson_web_851> (Prev was @petr)
[16:36:51] <Paul Wouters_web_299> dnsopop
[16:37:00] <Tim Wicinski_web_945> +1
[16:37:01] <Peter van Dijk_web_507> we'll call it dnsops
[16:37:06] <Peter van Dijk_web_507> this will not confuse anybody
[16:37:28] <Shumon Huque_web_591> real-dns-ops? :)
[16:37:30] <Wes Hardaker_web_607> somewhere "dnsoap" is a goal
[16:37:35] <Paul Wouters_web_299> would make more sense to create dnsme (Minor|Major) Extensions :)
[16:37:47] <Petr Špaček_web_442> Sure, that's why repeatedly say that we should not prescribe specific values for validators. These values need to change over time as operators migrate to lower iteration values. On the other hand, we ought to clearly say to zone signers that iterations=0 is the only interoperable value in long term.
[16:37:50] <Shumon Huque_web_591> that will incur the additional startup time of spinning a new WG though Paul.
[16:37:57] <Brett Carr_web_848> Mmm is there another wg that is for operators that is not protocol focused
[16:38:03] <Brian Dickson_web_851> Do we need to revive the dnsext WG? 1/2 :-)
[16:38:13] <Brett Carr_web_848> Have i been missing that for all these years
[16:38:53] <Suzanne Woolf_web_103> Still, worth noting that part of our charter is to help DNS-oriented work find its way to other WGs if that works better, as we did with DPRIVE and ADD
[16:38:54] <Paul Wouters_web_299> shumon: i was joking, your work belongs here.
[16:39:08] <Shumon Huque_web_591> Yes, agree Peter - there are protocol considerations involved.
[16:39:21] <Brett Carr_web_848> I quite like the idea but if it isnt protocol related does it belong at the IETF?
[16:39:22] <Tim Wicinski_web_945> Ralf FTW!
[16:39:26] Jasdip Singh_web_715 leaves the room
[16:39:49] <Paul Wouters_web_299> dnsnog ? :)
[16:39:57] <Harald Alvestrand_web_118> The purpose of the IETF is to make the Internet work better, not to work on protocols....
[16:40:01] <Suzanne Woolf_web_103> We can also talk with chairs of existing WGs and ask for cross-group review....sometimes that works, sometimes not so much.
[16:40:05] <Tim Wicinski_web_945> I have many things to say on this topic but I'm just a humble operations person
[16:40:07] <Shumon Huque_web_591> PaulW - that was directed at PaulH!
[16:40:10] <Ray Bellis_web_189> please bring back DNSEXT, the other groups don't attract enough protocol folks.
[16:40:22] <Petr Špaček_web_442> :troll:
[16:41:17] <Paul Wouters_web_299> dnsscotch ?
[16:41:20] <Peter Koch_web_532> @Wes: I am not convinced that the goal is '0', but whatever it is, the inetersts of the parties involved don't seem to be balanced heer
[16:41:27] <Peter Koch_web_532> s/heer/here/
[16:41:48] <Peter van Dijk_web_507> I am convinced that the goal is 0.
[16:43:09] <Petr Špaček_web_442> It was a glaring security hole before we patched it "in secret", after an agreement among software vendors. Right now cap at 150 still gives attackers 3x bigger power than they would have with 0 extra iterations.
[16:44:05] <Jim Reid_web_868> @ Peter, that's unreasonable. How can the WG have a discussion with parties who aren't here (or not saying anything)?
[16:44:15] Lixia Zhang_web_239 joins the room
[16:46:14] <Tim Wicinski_web_945> +1 PaulW. but then again I am an operations person
[16:46:44] <Paul Wouters_web_299> reminder:  dig txt cnn.com
[16:46:44] <Warren Kumari_web_492> I personally also like this, but think that we need to have the poll before adoptions...
[16:46:49] <John Levine_web_379> Agree this is worth adopting
[16:46:56] <Petr Špaček_web_442> @Petr Koch. At the moment you can rightfully argue that vendors are non-compliant with RFC 5155 because the cap at 150 iterations is simply not there. On the other hand, I do not see queue of customers asking for full compliance with RFC 5155 because it would make the attack vector even more powerful (as it was). So at this point it's totally unclear to me what you are asking for. More power to attackers? Or ...?
[16:47:01] <Tim Wicinski_web_945> Secret: Warren loves polls
[16:47:02] <PE_web_107> support this draft. current state is a mess
[16:47:33] <Wes Hardaker_web_607> Not a secret
[16:47:58] <Brian Dickson_web_851> @jim I think that is why there are e.g. liasons to various external entities. There may be a need for a liason for these sorts of things. I think it is unreasonable to not reach out for major impacting changes to DNS protocol or operations. But that's just my knee-jerk reaction..
[16:48:00] <Tim Wicinski_web_945> Also not a secret: Warren loves pretty graphs
[16:48:28] <Paul Wouters_web_299> I'd really like to see the expiry in easy human readable part of the TXT record. so admins can clean up better
[16:48:37] <Warren Kumari_web_492> Warren likes shiny things!
[16:48:42] <Peter van Dijk_web_507> PaulW, +1
[16:48:53] <Tim Wicinski_web_945> +1 PaulW
[16:48:53] Alexander Azimov_web_108 joins the room
[16:49:20] <Petr Špaček_web_442> @Brian Rest assured that reach out is already happening to parties in order of their current iteration #. In fact Victor & company managed to lower iteration count for bunch of TLDs already.
[16:49:51] <Peter van Dijk_web_507> Outreach for nsec3 iterations has been going on for months, yes
[16:50:23] <Brian Dickson_web_851> Yep, I was making the distinction between the specific work vs the general process (and possibly visibility beyond the individual efforts.)
[16:50:23] <Jim Reid_web_868> Fair enough Brian, but who are the external enties that need a liaison on NSEC3 iterations? And why aren't they here (or on the list)?
[16:50:43] <Petr Špaček_web_442> (Without the outreach even 150 limit would not be possible - kudos to Victor, Roy and others.)
[16:50:51] <Peter van Dijk_web_507> Jim, or on dns-operations, where outreach has also happened
[16:50:59] <Wes Hardaker_web_607> Agreed: Viktor's outreach efforts are stellar and have produced great results both on nsec3 and on algorithm selection.
[16:51:08] <Petr Špaček_web_442> +1
[16:52:06] <Paul Wouters_web_299> I will help. I need it
[16:52:34] <Brett Carr_web_848> I was just going to a) Add my support and b) question the title of the draft it says "Survey" but you tlaked about reccomendations
[16:52:34] Robert Evans_web_775 leaves the room
[16:52:57] <Brett Carr_web_848> The title may confuse people into thinking its jusr informational
[16:53:01] Patrick Tarpey_web_564 joins the room
[16:53:23] <Brett Carr_web_848> And I'm happy to help with it
[16:53:31] Qiaoyu Deng_web_616 leaves the room
[16:53:35] Qiaoyu Deng_web_989 joins the room
[16:53:42] <Tim Wicinski_web_945> Thanks Brett/PaulW
[16:53:46] <Brett Carr_web_848> Would next steps to be more prospective about what ppl should do
[16:54:07] <Alexey Melnikov_web_845> Just a thought: you can start as Informational and move towards PS later, if needed.
[16:54:14] Emiliano Spinella_web_288 leaves the room
[16:54:49] <Alexey Melnikov_web_845> +1 to adopting this as well,
[16:55:49] Florence D_web_527 joins the room
[16:56:24] Daniel Gillmor_web_746 joins the room
[16:57:00] Matthew Quick_web_682 joins the room
[16:57:09] Olaf Kolkman_web_426 leaves the room
[16:57:13] Olaf Kolkman_web_227 joins the room
[16:57:20] Yoshiro Yoneya_web_358 leaves the room
[16:57:21] dkg joins the room
[16:57:23] abdullahalshoaili_web_884 leaves the room
[16:57:24] Yoshiro Yoneya_web_747 joins the room
[16:57:27] abdullahalshoaili_web_800 joins the room
[16:57:36] <Suzanne Woolf_web_103> @Alexey agreed, the status doesn't have to be set from the beginning
[16:57:54] Olaf Kolkman_web_227 leaves the room
[16:57:58] Olaf Kolkman_web_453 joins the room
[16:58:07] Kohei Isobe_web_554 joins the room
[16:58:14] Peter Thomassen_web_688 leaves the room
[16:58:18] Peter Thomassen_web_923 joins the room
[16:58:23] Peter Thomassen_web_923 leaves the room
[16:58:27] Peter Thomassen_web_107 joins the room
[16:58:36] <Shivan Sahib_web_671> Alexey: that was our thinking as well
[16:59:02] Kevin Fleming_web_681 leaves the room
[17:01:01] <Paul Wouters_web_299> nice example of filtering job searching jobs. is that what we want the protocol to support ? :)
[17:01:04] Joel Jaeggli_web_164 leaves the room
[17:01:19] <dkg> that's what it will enable (and worse) if we advance it
[17:01:44] <Shumon Huque_web_591> Yeah, our initial target was a lower bar, hence informational. If work on an adopted document reveals important security or operational issues that need to be addressed, that would argue for reclassifying to PS.
[17:02:11] <Vittorio Bertola_web_585> @dkg That is already happening today and will continue to happen no matter what the IETF does. The draft is meant to enable providing meaningful human-readable feedback to users.
[17:02:37] <Petr Špaček_web_442> @dkg I've missed what the objection is? (crappy audio here)
[17:02:45] <Tim Wicinski_web_945> "Dear Employee: You can't have nice things. Signed, Management"
[17:03:08] Mohamed Boucadair_web_504 leaves the room
[17:03:08] Andrew S_web_500 joins the room
[17:03:11] <Peter Lowe_web_862> @dkg It's happening already, but problematically because it's hard to see what's filtering what, or why
[17:03:16] <dkg> Vittorio: true, "enable" is the wrong word
[17:03:20] <Benjamin Schwartz_web_236> This implicitly requires long-lived logs
[17:03:36] <Petr Špaček_web_442> @Ben Can you elaborate?
[17:03:52] <Jonathan Reed_web_185> @Ben: Really?  I interpret it as not requiring them.  If I tell you at the time of transaction why you can't resolve, I don't need to record it for later debugging.
[17:03:54] <Benjamin Schwartz_web_236> The URL implies that the filtering events are logged
[17:03:57] <dkg> identifying the response by timestamp implies that you keep a history
[17:04:00] <Paul Wouters_web_299> do censors really want to advertise why they are censoring ?
[17:04:07] <Peter van Dijk_web_507> PaulW, many do, yes
[17:04:09] <Andrew Campling_web_444> This gives the opportunity to provide transparency to end users, seems to me to be entirely consistent with RFC 8890.  
[17:04:17] <Peter Lowe_web_862> @paul Censors, no, but filtering services, yes absolutely!
[17:04:19] <Benjamin Schwartz_web_236> And many want to misrepresent the reason to the user
[17:04:35] <Jonathan Reed_web_185> @ben: Then the reason can be "because we said so"
[17:04:40] <Petr Špaček_web_442> @dkg @Ben it might not be clear from the slides, but the ?timestamp= is just an example. There is no mandate in the protocol.
[17:04:40] <Paul Wouters_web_299> @peter: www.bigcensor.com/why/domainname.com
[17:04:44] <Andrew Campling_web_444> Also, the "censors" may be parents, employers on enterprise networks etc
[17:04:45] <Peter Lowe_web_862> IoT devices have no standard way of handling blocked requests at the moment, with a standard filtering response they can at least deal with it
[17:04:47] <dkg> "sorry, there was malware hosted on politicalprotest.example"
[17:04:54] <Vittorio Bertola_web_585> There are many cases in which the filter has actually been requested by the user (e.g. parental controls or malware blocks).
[17:05:16] <Harald Alvestrand_web_118> that's requested by the customer (parent), not by the user (child).....
[17:05:18] <Benjamin Schwartz_web_236> @Vittorio: That doesn't require this.
[17:05:27] <Benjamin Schwartz_web_236> It can be done at the application layer
[17:05:35] <Paul Wouters_web_299> i think the kids usually know why their porn or drug side is censored by the parent ? :)
[17:05:43] <dkg> to do that, you'd need to identify the natural language of the free-form text
[17:05:58] <Andrew Campling_web_444> Malware filtering is another current use case where this would be beneficial
[17:06:25] <Vittorio Bertola_web_585> @Ben not on all devices. E.g. try to do that on a smart TV. Or on some IoT thingie that was cracked in the meantime.
[17:06:31] <Erik Nygren_web_716> There seems to be an analog to http 451. (rfc 7725).  although more general scope-wise.
[17:06:42] <Petr Špaček_web_442> I really see the problem. "Bad" censors do just fine without support for this draft already. This draft supports "good" censors who want to be transparent about what they block and why to their users.
[17:06:48] Joel Jaeggli_web_599 joins the room
[17:06:57] <Andrew Campling_web_444> @Petr: +1
[17:07:00] <Petr Špaček_web_442> *I really _don't_ see ...
[17:07:18] <John Todd_web_189> @Petr +1
[17:07:34] <Vittorio Bertola_web_585> Yes, that's the point. This draft does not make filtering harder or easier. It just provides a much better UX for many real-world use cases.
[17:07:46] <Peter Lowe_web_862> @Vittorio +1
[17:07:51] <dkg> note that 451 can be fine-grained enough to explain specific HTTP resources.  this approach involves blocking entire DNS lookups
[17:08:10] Michael StJohns_web_428 leaves the room
[17:08:14] <Vasilis_web_784> Isn't DNS manipulation the current methodology for blocking websites and services?
[17:08:19] <dkg> could someone who thinks this offers a better UX describe how they think the UX would actually work?
[17:08:25] <Peter van Dijk_web_507> dkg, specific HTTP resources? in this HTTPS world?
[17:08:38] <dkg> HTTP 451, yes, specific HTTPS resources
[17:08:43] <Peter Lowe_web_862> @dkg It's not just HTTP, it's IoT devices, apps, mobile phones, ...
[17:08:48] <dkg> i'm ignoring legacy cleartext HTTP deployments
[17:08:49] <Petr Špaček_web_442> @dkg Sure, it's right in the Introduction. What part of the section is inaccurate?
[17:09:08] Sidan Qi_web_742 joins the room
[17:09:11] <Vasilis_web_784> There is a vast amount of data with network measurements for censorship case since 2012 at https://ooni.org/data
[17:10:17] <Peter Koch_web_532> one could say that the draft (or, more precisely, the IETF's eventually publishing it) would make "filtering" an integral part of the Domain Name System (as in: the DNS architecture)
[17:10:29] <Benjamin Schwartz_web_236> @Jonathan: That's covered by the EDE code
[17:10:33] <Peter Lowe_web_862> @peter It already is, isn't it?
[17:10:40] James Gould_web_748 leaves the room
[17:10:53] Mike StJohns leaves the room
[17:11:25] <Jonathan Reed_web_185> @ben: Fair, but still a bit high level.   But I take your point that there's something here to integrate with EDE
[17:11:34] <Peter Koch_web_532> drunk driving is a reality, too. (find Keith Moore's I-D on that topic as an exercise)
[17:12:01] <Vasilis_web_784> Many ISPs are not allowed to mention the reason for blocking, or/and they don't have the resources to do so.
[17:12:11] <Erik Nygren_web_716> For a mixture of better and worse, some types of filtering that used to happen at HTTP per-resource now happens at DNS due to HTTPS uptake, and that's better than doing TLS MitM.  451 is also only useful for well-behaved operators, and the same applies here (with similar warnings about risks about exposing too much to end-users)
[17:12:30] <dkg> Petr: i don't thnk there is a clear description of the UX in the introduction, but maybe i'm reading it wrong
[17:12:48] <Vittorio Bertola_web_585> @Peter K. I'm not sure that the IETF gets to decide what is DNS and what is not, but anyway "filtering" is already explicitly acknowledged in RFC 8914. This is just an extension to that.
[17:13:38] <Vasilis_web_784> Will this be "compatible" with DoH/DoT resolvers?
[17:13:43] <Petr Špaček_web_442> @dkg Maybe we are talking past cross each other. Intro elaborates why current state of things is total bummer from UX perspective. I'm saying that _something_ should be done about it, so I'm unhappy dismissing the draft as unnecessary.
[17:14:02] <dkg> i agree that the current situation is a bummer!  what i'm not hearing is what the improvement is
[17:14:16] <Vittorio Bertola_web_585> @Vasilis: it is actually a requirement in the draft that it is only used on encrypted DNS transport.
[17:14:44] <dkg> I share Orth's concerns (from just now at the mic) about the dangers of implementing some UX behavior from this draft
[17:14:46] <Jonathan Reed_web_185> @Paul: I don't think Andrew or I said it's used _just_ in the Enterprise.  I think we said it _is_ a use case.
[17:15:03] <Petr Špaček_web_442> @dkg You mean the UX which is not described there? :troll:
[17:15:23] <dkg> right, that's what i'm asking for.
[17:15:34] <Vittorio Bertola_web_585> The browser could just prefix any text with a big red warning saying "this text is not coming from the website you requested but from your local network".
[17:15:38] <dkg> if the goal is to improve UX, just providing this dataset doesn't paint the full picture
[17:15:39] <Petr Špaček_web_442> On a more serious note: There is no _new_ UX in the draft. It just provides data for UX developers to process as they see fit.
[17:15:40] <Andrew Campling_web_444> @Jonathan: agreed, valid elsewhere too
[17:16:06] Sidan Qi_web_742 leaves the room
[17:16:06] <Benjamin Schwartz_web_236> @Petr: Yes, but the flavortext says that this is for display to users.
[17:16:19] <Petr Špaček_web_442> @dkg Agreed, that's why I said on the mailing list yesterday that we badly need browser people here. UX is not for DNS people to decide.
[17:16:22] <Paul Wouters_web_299> VPN per App.  MDM per app. it is already working
[17:16:40] <Vasilis_web_784> @Vittorio This will only apply to regional/country resolvers what if I use a generic DoT/DoH resolver?
[17:17:19] <Petr Špaček_web_442> @dkg But that's not a valid argument of saying "it's bad" because we are _not_ the UX people.
[17:17:23] <Vittorio Bertola_web_585> If you use a resolver that does not filter any domain and/or does not support this, you will not get any message. It's entirely optional.
[17:17:31] <Andrew Campling_web_444> @Vasilis: They will have the option to use this or not as they see fit
[17:17:34] <Paul Wouters_web_299> RPZ can be compatible with DNSSEC. Move the record from Answer To Additional.
[17:18:10] <Paul Wouters_web_299> that makes it also a voluntary censorship vs coercion
[17:18:46] Stuart Cheshire_web_247 leaves the room
[17:18:50] Stuart Cheshire_web_909 joins the room
[17:19:37] Brian Haberman_web_967 leaves the room
[17:19:46] <dkg> Petr, as someone who occasionally dabbles in UX (not well) i can see huge red flags in the implied UX here.  those red flags are the reason for being grumpy about it, and i was looking for someone to calm those fears.
[17:20:10] <dkg> i'm not hearing anyone make me more confident in what a safe and useful UX would actually look like.
[17:20:27] <dkg> that makes it smell like a footgun
[17:21:24] Peter Lowe_web_862 leaves the room
[17:22:58] Ching-Heng Ku_web_821 leaves the room
[17:22:58] <Petr Špaček_web_442> That's entirely possible, yes. The main point of the draft is that we (as dnsop) can provide some data but it's up to (very small) group of vendors outside of dnsop to decide if it is the right type of data, in right format, transport, etc. and to design the UX. After all this is what I sent to the list:
[17:23:00] <Petr Špaček_web_442> I believe we really really _really_ need input from end-client vendors, most importantly Google Chrome and Safari. Is there any indication that they might be interested? If not, why?
[17:23:27] <dkg> makes sense, Petr.
[17:23:29] <Petr Špaček_web_442> All I'm saying don't put it to trash bin until we hear back from browsers.
[17:23:44] Scott Rose_web_947 leaves the room
[17:24:16] <Petr Špaček_web_442> (After all, if browsers are not interested in solving this UX problem then we can stop right here even if the protocol is perfectly secure - it would be just busy work.)
[17:24:28] <dkg> right: i'm saying the WG shouldn't adopt until we hear a positive and plausible response from the browsers that they have a way to use it :)
[17:24:48] <Petr Špaček_web_442> Good! We are in violent agreement then!
[17:24:54] <dkg> ☺
[17:25:18] <Peter van Dijk_web_507> Brian has now skipped discussion of glueless in two forums, that's a bit weird, as it is a very weird requirement that the whole set of proposals leans on heavily
[17:25:21] <Brett Carr_web_848> I can't say that I'm very keen on re-using DS for another purpose. DNSSEC is challenging to deploy for a lot of operators due to primarily being seen as complex and this is adding to that complexity.
[17:25:33] Vittorio Bertola_web_585 leaves the room
[17:26:20] <Eric Orth_web_287> At the risk of jumping into the deep end of the filtering discussion: I am a "browser person", so my statements could easily be considered feedback from that perspective.
[17:26:57] <Brett Carr_web_848> Explaining to people who aren't familar with DNSSEC that a DS is usually used for standard DNSSEC apart from when it's used for ADOT will cause  more confusion IMHO
[17:27:45] <tale > "DS is used for security in the DNS".  Any further than that and even for many engineers I know their eyes glaze over.
[17:27:55] <Peter van Dijk_web_507> DS, the DNS Security record
[17:28:38] <Benjamin Schwartz_web_236> "Delegation Signatures"
[17:29:05] Stuart Cheshire_web_909 leaves the room
[17:29:09] Stuart Cheshire_web_225 joins the room
[17:29:19] <Brett Carr_web_848> DS > RRSIG Delegation Signature Signature
[17:30:15] <Paul Wouters_web_299> I think SVCB can do all that a new TLSADOT can ?
[17:30:28] Stuart Cheshire_web_225 leaves the room
[17:30:32] Stuart Cheshire_web_326 joins the room
[17:30:49] <Benjamin Schwartz_web_236> Paul: s/TLSADOT/DNST/ ?
[17:31:11] <Paul Wouters_web_299> well, both really
[17:31:53] <Paul Wouters_web_299> both are basically saying "ignore in-baliwick protection, then lookup encrypted transport for a specific nameservere here"
[17:31:54] <Peter van Dijk_web_507> PaulW, I posted a response to Brian's -02(?) a few months ago pointing out the deltas between this and various other things. Those deltas are small but not zero.
[17:32:29] <Peter van Dijk_web_507> instead of DNST, we could also specify that SVCB lives at ns.example.com instead of _dns.ns.example.com, but ADD wouldn't have it
[17:33:03] <Paul Wouters_web_299> yes the "put NS name securely into DS" is the shared part. we need some sort of way for that.
[17:33:13] Patrick Tarpey_web_564 leaves the room
[17:33:13] <Peter van Dijk_web_507> i prefer Ben's over Brian's for that
[17:33:27] <Peter Koch_web_532> i'm a bit lost (again): how much of this really happens at the parent?
[17:33:40] <Peter van Dijk_web_507> PeterK, publication of the DS, period
[17:33:45] <Paul Wouters_web_299> i prefer using specific data, ideally in ascii/string, over stuffing wire format inside RRDATA
[17:34:31] Paul Wouters_web_299 leaves the room
[17:34:35] Paul Wouters_web_390 joins the room
[17:34:41] Robert Evans_web_130 joins the room
[17:35:01] <dkg> i think i prefer Ben's dsglue framework over this mechanism
[17:35:07] <Peter Koch_web_532> @PvD thanks; the 'original' DS, I assume?
[17:35:35] <Peter van Dijk_web_507> PeterK, yes, no processing required in the registry in this case, I believe
[17:35:44] Stuart Cheshire_web_326 leaves the room
[17:35:48] Stuart Cheshire_web_153 joins the room
[17:36:11] Peter Feil_web_575 leaves the room
[17:36:58] <Erik Nygren_web_716> Another draft in this space which is expired, but I'm looking to have one of my colleagues pick it back up and incorporates ideas/discussion that have happened since:  https://datatracker.ietf.org/doc/html/draft-tapril-ns2-01
[17:37:42] <Peter van Dijk_web_507> Erik, please have them incorporate the Yes/No list that Ben had in his dsglue slides earlier today so we know what we're talking about :)
[17:38:22] Stuart Cheshire_web_153 leaves the room
[17:38:26] Stuart Cheshire_web_337 joins the room
[17:38:26] Zaid AlBanna_web_488 leaves the room
[17:38:30] Zaid AlBanna_web_502 joins the room
[17:38:40] Gianpaolo Scalone_web_918 leaves the room
[17:38:43] <Andrew Campling_web_444> ADD Draft: Service Binding Mapping for DNS Servers https://datatracker.ietf.org/doc/draft-schwartz-svcb-dns/
[17:38:56] <Suzanne Woolf_web_103> Thanks Andrew
[17:39:25] <Erik Nygren_web_716> Agreed and will do.  (We were discussing this earlier after ADD.)  We also want to get some other authors as well, but wanted to find someone to take point on it first.  Utilizing draft-schwartz-svcb-dns is high on the list of changes.
[17:40:19] <Andrew Campling_web_444> NB The ADD doc is already adopted
[17:41:26] Shivan Sahib_web_671 leaves the room
[17:42:00] Stuart Cheshire_web_337 leaves the room
[17:42:04] Stuart Cheshire_web_160 joins the room
[17:42:23] Zaid AlBanna_web_502 leaves the room
[17:43:17] Qiaoyu Deng_web_989 leaves the room
[17:43:21] Qiaoyu Deng_web_883 joins the room
[17:44:45] Moritz Müller_web_878 leaves the room
[17:45:25] <Peter van Dijk_web_507> Brian, did you just allude to some unpublished cache poisoning vulnerability?
[17:46:08] Qiaoyu Deng_web_883 leaves the room
[17:47:25] <Paul Wouters_web_390> also, dsglue and this set of drafts put stuff in DS and mark it trusted and signed. But it is not. It is just "accepted by the parent". Without CDS confirmation you dont know if this is really a directive of the delegated zone
[17:47:55] <Paul Wouters_web_390> (eg the same security as the parent's unsigned glue)
[17:49:25] <dkg> PvD: it sounded like he did to me :/
[17:49:42] <Peter Koch_web_532> there's more than one registry that deosn't operate on DS, in the first place
[17:49:50] <Benjamin Schwartz_web_236> Paul: It's the same security level as the child's DS record in the parent.
[17:50:41] <Peter van Dijk_web_507> PeterK, indeed, and some multi-TLD resellers (like RRPProxy/Key Systems) even require DNSKEY for TLDs that don't - if I understand correctly
[17:50:54] PE_web_107 leaves the room
[17:50:55] Hugo Kobayashi_web_557 leaves the room
[17:51:00] <Paul Wouters_web_390> ben: I dont understand what you are saying
[17:51:14] Florence D_web_527 leaves the room
[17:51:17] <Benjamin Schwartz_web_236> We'll have to discuss that another time.
[17:51:22] Daniel Gillmor_web_746 leaves the room
[17:51:24] Steven Hartley_web_230 leaves the room
[17:51:24] John Levine_web_379 leaves the room
[17:51:24] Andrew Campling_web_444 leaves the room
[17:51:25] Joao Damas_web_542 leaves the room
[17:51:25] Benjamin Schwartz_web_236 leaves the room
[17:51:26] David Blacka_web_342 leaves the room
[17:51:26] Alexey Melnikov_web_845 leaves the room
[17:51:26] avri doria_web_945 leaves the room
[17:51:26] Ken Renard_web_588 leaves the room
[17:51:26] Hugo Salgado_web_195 leaves the room
[17:51:27] Tommy Jensen_web_966 leaves the room
[17:51:27] abdullahalshoaili_web_800 leaves the room
[17:51:27] Andrew S_web_500 leaves the room
[17:51:27] Mark Andrews_web_526 leaves the room
[17:51:28] Shinta Sato_web_521 leaves the room
[17:51:28] Paul Muchene_web_168 leaves the room
[17:51:29] Ulrich Wisser_web_345 leaves the room
[17:51:30] Erik Nygren_web_716 leaves the room
[17:51:30] Lixia Zhang_web_239 leaves the room
[17:51:30] Juliana Guerra_web_667 leaves the room
[17:51:30] Peter Thomassen_web_107 leaves the room
[17:51:31] Ralf Weber_web_331 leaves the room
[17:51:31] Dan McArdle_web_860 leaves the room
[17:51:31] Jonathan Reed_web_185 leaves the room
[17:51:33] fightingnemo leaves the room
[17:51:33] Paul Hoffman_web_778 leaves the room
[17:51:38] Yoshiro Yoneya_web_747 leaves the room
[17:51:38] Harald Alvestrand_web_118 leaves the room
[17:51:38] Takahiro Nemoto_web_277 leaves the room
[17:51:39] Michael Hollyman_web_280 leaves the room
[17:51:39] Yuji Koyama_web_475 leaves the room
[17:51:40] Richard Wilhelm_web_422 leaves the room
[17:51:43] Yoshiro Yoneya leaves the room
[17:51:44] Scott Hollenbeck_web_982 leaves the room
[17:51:49] Michelle Cotton_web_358 leaves the room
[17:51:57] Viktor Dukhovni_web_237 leaves the room
[17:52:00] <Brian Dickson_web_851> BTW, PvD yes, or rather stronger than published (related to Fragmentation Considered Poisonous)
[17:52:01] Chen Li_web_670 leaves the room
[17:52:02] Shumon Huque_web_591 leaves the room
[17:52:04] Sara Dickinson_web_149 leaves the room
[17:52:05] Olaf Kolkman_web_453 leaves the room
[17:52:05] Duane Wessels_web_901 leaves the room
[17:52:06] Mike Bishop_web_350 leaves the room
[17:52:06] Paul Wouters_web_390 leaves the room
[17:52:07] Wes Hardaker_web_607 leaves the room
[17:52:07] Yoshitaka Aharen_web_633 leaves the room
[17:52:08] Warren Kumari_web_492 leaves the room
[17:52:10] Samuel Weiler_web_576 leaves the room
[17:52:12] Ray Bellis_web_189 leaves the room
[17:52:13] Emmanuel Bretelle_web_131 leaves the room
[17:52:14] Peter Koch_web_532 leaves the room
[17:52:15] John Todd_web_189 leaves the room
[17:52:20] Robert Story_web_532 leaves the room
[17:52:20] Kesara Rathnayake_web_415 leaves the room
[17:52:25] Suzanne Woolf_web_103 leaves the room
[17:52:30] Kohei Isobe_web_554 leaves the room
[17:52:35] Alexander Azimov_web_108 leaves the room
[17:52:36] Nicklas Pousette_web_212 leaves the room
[17:52:39] Eric Orth_web_287 leaves the room
[17:52:41] David Lawrence_web_364 leaves the room
[17:52:42] Chi-Yuan Chen_web_239 leaves the room
[17:52:43] Joel Jaeggli_web_599 leaves the room
[17:52:55] Andrew Fregly_web_732 leaves the room
[17:52:57] Puneet Sood_web_634 leaves the room
[17:53:00] Jim Reid_web_868 leaves the room
[17:53:01] <Peter van Dijk_web_507> ok, seems inappropriate to just throw that out there
[17:53:05] Bruno Teixeira_web_776 leaves the room
[17:53:09] Bruno Teixeira_web_456 joins the room
[17:53:19] <Brian Dickson_web_851> The DS hash of the name server name is not itself trusted, as it cannot even be directly seen. Pre-image collision would be required for that to not be the case.
NSV is literally just "NS validation", because of the hashing.
[17:53:30] Antoin Verschuren_web_588 leaves the room
[17:53:47] Tom Hill_web_847 leaves the room
[17:53:55] Petr Špaček_web_442 leaves the room
[17:54:30] Michael Breuer_web_978 leaves the room
[17:54:53] <Brian Dickson_web_851> (BTW, I actually agree with ben on the security properties of CDS vs DS, but I am doing behind-the-scenes work on that problem. IMHO, it is necessary for the CDS signature to be passed to the Registry in all cases, so the Registry can validate the changes that occur.
This ties in to the bootstrap proposal by Peter.
[17:55:30] <Brian Dickson_web_851> Yes, but while I would like to write it up in detail, there is a question of audience and the implicit zero-day nature of the details.
[17:55:43] <Brian Dickson_web_851> (Re: the throwing that out there)
[17:56:17] Jiri Novotny_web_204 leaves the room
[17:58:20] Peter van Dijk_web_507 leaves the room
[17:58:43] <Brian Dickson_web_851> The gist of it is, regardless how poisoning is accomplished, if poisoning is possible, it allows an off-path attacker to become on-path.
This can also be accomplished via BGP, of course, modulo topological locality. Hijack a BGP prefix, or leak a prefix, and you can promote yourself to an on-path attacker.
[17:59:11] Juan Cerezo_web_699 leaves the room
[17:59:56] Stuart Cheshire_web_160 leaves the room
[18:00:33] Robert Evans_web_130 leaves the room
[18:01:23] Kazunori Fujiwara_web_702 leaves the room
[18:03:14] Stuart Card_web_964 leaves the room
[18:05:01] Chris Box_web_960 leaves the room
[18:05:16] Tim Wicinski_web_945 leaves the room
[18:05:16] Paolo Saviano_web_325 leaves the room
[18:05:16] Benno Overeinder_web_821 leaves the room
[18:05:16] Dan Wing_web_714 leaves the room
[18:05:16] Kim Davies_web_989 leaves the room
[18:05:16] Joey Salazar_web_310 leaves the room
[18:05:16] Monika Ermert_web_838 leaves the room
[18:05:16] Brett Carr_web_848 leaves the room
[18:05:16] Ted Lemon_web_303 leaves the room
[18:05:16] Vasilis_web_784 leaves the room
[18:05:16] David Smith_web_684 leaves the room
[18:05:16] Simon Hicks_web_791 leaves the room
[18:05:16] Brian Dickson_web_851 leaves the room
[18:05:16] Matthew Quick_web_682 leaves the room
[18:05:16] Bruno Teixeira_web_456 leaves the room
[18:05:30] alexamirante leaves the room
[18:06:08] Meetecho leaves the room
[18:09:12] Hugo Salgado 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] Half-Shot leaves the room
[23:05:42] halfshot leaves the room
[23:05:42] Jan Včelák leaves the room
[23:05:42] sftcd leaves the room
[23:05:42] weiler leaves the room
[23:05:42] zyxbac leaves the room
[23:05:46] cjsu joins the room
[23:05:46] Half-Shot joins the room
[23:05:46] halfshot joins the room
[23:05:46] Jan Včelák joins the room
[23:05:46] sftcd joins the room
[23:05:46] weiler joins the room
[23:05:46] zyxbac joins the room
[23:09:25] 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!