[03:58:19] Ben Schwartz leaves the room
[03:59:00] bemasc joins the room
[04:00:05] bemasc leaves the room
[05:00:29] Simon Leinen joins the room
[10:38:43] AWinfield(SKY) joins the room
[11:12:17] AWinfield(SKY) leaves the room
[12:49:25] AlisterWinfield(Sky) joins the room
[13:16:12] AlisterWinfield(Sky) leaves the room
[13:17:43] AlisterWinfield(Sky) joins the room
[13:25:45] AlisterWinfield(Sky) leaves the room
[15:10:49] cabo joins the room
[15:35:22] cabo leaves the room
[16:18:14] danwing@jabber.uk joins the room
[16:22:10] danwing@jabber.uk leaves the room
[16:22:12] danwing@jabber.uk joins the room
[16:24:39] danwing@jabber.uk leaves the room
[16:24:47] Dan Wing joins the room
[16:29:55] Ash joins the room
[16:39:38] cabo joins the room
[16:41:55] avezza joins the room
[16:42:23] Dan Wing leaves the room
[16:42:57] Dan Wing joins the room
[16:43:47] Dan Wing leaves the room
[16:45:53] ChrisBox joins the room
[16:47:03] Dan Wing joins the room
[16:49:41] ChrisBox leaves the room
[16:58:15] ChrisBox joins the room
[16:58:46] <ChrisBox> Testing... does this work?
[16:58:46] Tommy Jensen leaves the room
[17:01:18] bemasc joins the room
[17:10:22] cabo leaves the room
[17:17:24] ChrisBox leaves the room
[17:19:28] ChrisBox joins the room
[17:26:12] <Dan Wing> Works as well as Jabber works.  heh.
[17:36:35] ChrisBox leaves the room
[17:52:24] ChrisBox joins the room
[17:54:17] andronkyr joins the room
[17:56:15] ChrisBox leaves the room
[18:01:11] bemasc leaves the room
[18:07:44] ChrisBox joins the room
[18:09:28] bemasc joins the room
[18:10:50] ChrisBox leaves the room
[18:15:27] ChrisBox joins the room
[18:18:29] ChrisBox leaves the room
[18:23:27] andronkyr leaves the room
[18:23:57] andronkyr joins the room
[18:39:29] ChrisBox joins the room
[18:42:36] ChrisBox leaves the room
[18:51:40] Barry Leiba joins the room
[18:57:31] willem joins the room
[18:58:01] willem leaves the room: Disconnected: closed
[18:58:25] Willem Toorop joins the room
[19:18:02] ChrisBox joins the room
[19:26:35] Nick Sullivan joins the room
[19:31:21] ChrisBox leaves the room
[19:35:08] Glen (AMS IT) joins the room
[19:35:21] cabo joins the room
[19:38:51] Yoshiro Yoneya joins the room
[19:39:16] Glen (AMS IT) leaves the room
[19:41:04] tale joins the room
[19:41:14] Jared Mauch joins the room
[19:42:35] Glen (AMS IT) joins the room
[19:43:45] Glen (AMS IT) leaves the room
[19:44:52] Ted.h joins the room
[19:45:37] <Ted.h> /topic IETF107
[19:46:13] ChrisBox joins the room
[19:46:33] merm joins the room
[19:47:00] Barbara Stark joins the room
[19:49:36] martin.duke joins the room
[19:49:37] Bob Moskowitz joins the room
[19:50:36] <Bob Moskowitz> Perhaps I will add this as a something to pay attention to...
[19:50:36] Vittorio Bertola joins the room
[19:50:44] mcr joins the room
[19:50:47] ChrisBox leaves the room
[19:50:52] <mcr> etherpad is in the usual place?
[19:51:13] <tale > https://etherpad.ietf.org:9009/p/notes-ietf-107-add?useMonospaceFont=true
[19:51:40] wseltzer@jabber.org joins the room
[19:51:40] Pete Resnick joins the room
[19:51:41] glen joins the room
[19:51:46] glen leaves the room
[19:51:58] Glen (AMS IT) joins the room
[19:52:18] <mcr> we can hear Daniel.
[19:52:23] vladimir.cunat joins the room
[19:52:28] <mcr> The pptx of the slides is corrupt according to LibreOffice.
[19:52:45] ChrisBox joins the room
[19:53:03] kaduk@jabber.org/barnowl joins the room
[19:53:30] pietro joins the room
[19:55:01] pardue joins the room
[19:55:09] neednnelg@sure.im joins the room
[19:55:15] spencerdawkins joins the room
[19:55:17] frode joins the room
[19:55:22] Jonathan Hammell joins the room
[19:55:50] <neednnelg@sure.im> Try the PDF version of the docs that's what they were uploaded as
[19:55:56] <tale > We won't be able to do anything about the pptx / LibreOffice issue until after the meeting
[19:56:14] <Bob Moskowitz> I tried the pdf and it is 4 blank pages
[19:56:22] Jari Arkko joins the room
[19:56:37] pietro joins the room
[19:56:44] Barbara Stark leaves the room
[19:57:00] Paul Hoffman joins the room
[19:57:06] Alissa Cooper joins the room
[19:57:10] Mirja joins the room
[19:57:13] ihlar joins the room
[19:57:14] <kaduk@jabber.org/barnowl> Bob: which pdf viewer?  (All docs look okay to me)
[19:57:31] Greg Wood joins the room
[19:57:49] <Bob Moskowitz> Firefox plugin.  I will try downloading them
[19:57:53] StephenBotzko joins the room
[19:57:59] StephenBotzko leaves the room
[19:58:31] jhoyla joins the room
[19:58:34] csperkins joins the room
[19:58:36] m&m joins the room
[19:58:41] chi.jiun.su joins the room
[19:59:00] SHollenbeck joins the room
[19:59:18] Warren Kumari joins the room
[19:59:22] Olaf Kolkman joins the room
[19:59:29] marka joins the room
[19:59:30] Melinda joins the room
[19:59:32] Jared Mauch leaves the room
[19:59:35] xp29srs joins the room
[19:59:38] sftcd joins the room
[19:59:55] <mcr> the link in the calendar item is for the pptx, maybe a chair could remove that file?
[19:59:59] adam joins the room
[20:00:02] Cullen Jennings joins the room
[20:00:15] John Mah joins the room
[20:00:17] <Bob Moskowitz> I am using the link on the virtual agenda for the session materials as pdf.  I download it and tried all my Linux viewers and I have 4 blank pages.
[20:00:25] mnot joins the room
[20:00:38] Martin Thomson joins the room
[20:00:41] tfpauly joins the room
[20:00:41] tim costello joins the room
[20:00:45] hta joins the room
[20:00:57] Hugo Salgado joins the room
[20:01:02] dschinazi joins the room
[20:01:09] <adam> As a quick reminder -- we're asking participants to keep their camera turned off to reduce the load on the webex servers we're using; and to make sure they're muted when not talking so as to avoid background noise.
[20:01:28] <kaduk@jabber.org/barnowl> I'm going to https://datatracker.ietf.org/meeting/107/agenda and using
the diagonal four arrows "show meeting materials" popup, and following
links from there.
[20:01:42] ek.ietf joins the room
[20:01:52] <vladimir.cunat> Yes, those appear OK to me.
[20:01:58] Dan McArdle joins the room
[20:02:19] leifj joins the room
[20:02:21] adam has set the subject to: https://etherpad.ietf.org:9009/p/notes-ietf-107-add?useMonospaceFont=true
[20:02:40] <Warren Kumari> Don't tempt fate...
[20:02:40] jon-ietf joins the room
[20:02:41] <mnot> that's a bold statement
[20:02:42] Thomas Peterson joins the room
[20:02:51] <Warren Kumari> Look ma, no hands...
[20:02:59] <kaduk@jabber.org/barnowl> Maybe Bob is trying the "piece of paper with folded corner and
Adobe/PDF logo" button for "download meeting materials as PDF file"?
[20:03:07] Tommy Jensen joins the room
[20:03:08] Eric Vyncke joins the room
[20:03:11] cvmiller joins the room
[20:03:12] StephenBotzko joins the room
[20:03:12] <mcr> I tried the links in the calendar feed.
[20:03:13] ssahib joins the room
[20:03:24] Atarashi Yoshifumi joins the room
[20:03:25] <mcr> that's where I got: slides-107-add-agenda-00.pptx which was broken.
[20:03:42] <mcr> I went back to the meeting materials page on DT, and all is well there.
[20:03:48] Barbara Stark joins the room
[20:03:50] <kaduk@jabber.org/barnowl> I do see a four-page apparently blank PDF for the resulting
https://datatracker.ietf.org/meeting/107/agenda/add-drafts.pdf link
for "download meeting materials as PDF file"
[20:04:08] <Bob Moskowitz> That is the one.  Where in the past I got the session material as a pdf to view...
[20:04:14] stpeter joins the room
[20:04:15] <mcr> I didn't know draft authors were supposed to submit pictures :-)
[20:04:18] shuaiizhao joins the room
[20:04:21] <kaduk@jabber.org/barnowl> I have some vague recollection that "download meeting materials as a
PDF file" only ever works for post-meeting proceedings, but can't
recall why I think that.
[20:04:22] Wes Hardaker joins the room
[20:04:46] Ralf Weber joins the room
[20:04:56] <neednnelg@sure.im> https://datatracker.ietf.org/meeting/107/session/add under meetings has the individual materials
[20:04:57] dkg joins the room
[20:05:15] Duane Wessels joins the room
[20:05:19] <Bob Moskowitz> I have followed other sessions in the past looking at the session material.  It is up to the chairs, I think.
[20:05:24] Eric Kinnear joins the room
[20:05:29] Jonathan Lennox joins the room
[20:05:35] Magnus Westerlund joins the room
[20:05:36] Samuel Weiler joins the room
[20:05:38] Seth Blank joins the room
[20:05:49] Alexey Melnikov joins the room
[20:05:53] Karen O'Donoghue joins the room
[20:05:58] Jay Daley joins the room
[20:06:03] <Barbara Stark> Individual links to meeting materials work
[20:06:40] evequefou joins the room
[20:06:45] Nicolai Leymann joins the room
[20:06:47] <dkg> ehterpad is failing for me when i try to use it as a "blue sheet" though ☹
[20:07:06] <Bob Moskowitz> OK.  That link got me somewhere worthwhile.  Thanks
[20:07:09] <Barbara Stark> I can add you. dkg
[20:07:11] <adam> dkg -- you want me to add you?
[20:07:15] Kazunori Fujiwara joins the room
[20:07:21] <dkg> thanks, it worked for me just now
[20:07:28] Vicky joins the room
[20:07:28] <mcr> I can help out in jabber.
[20:07:29] carrickdb joins the room
[20:07:35] pietro leaves the room
[20:07:46] g.e.montenegro joins the room
[20:07:47] <Barbara Stark> @dkg: you're there already
[20:07:47] Mike StJohns joins the room
[20:08:06] shuque@sure.im joins the room
[20:08:07] erik joins the room
[20:08:23] msk joins the room
[20:08:26] <dkg> Barbara Stark: yep, it worked for me after i complained 😛
[20:08:47] kivinen joins the room
[20:09:14] <kaduk@jabber.org/barnowl> squeaky wheel gets the grease?
[20:09:19] <Alissa Cooper> etherpad is here: https://etherpad.ietf.org:9009/p/notes-ietf-107-add?useMonospaceFont=true
[20:09:25] tim costello leaves the room
[20:09:45] Tim Wicinski joins the room
[20:10:01] ekr@jabber.org joins the room
[20:11:08] tim costello joins the room
[20:11:57] healthyao2000 joins the room
[20:12:09] dragana joins the room
[20:13:11] <pardue> pics or it didn't happen
[20:13:25] <Jonathan Lennox> https://www.ietf.org/lib/dt/media/photo/martin-thomson-VJv2R.jpg
[20:13:30] Francisco Arias joins the room
[20:14:40] John Levine joins the room
[20:16:02] <hta> I don't understand how the VPN-associated resolver would work. Only traffic destined for DNS servers down the VPN? That sounds narrow.
[20:16:13] <Jonathan Lennox> 🍪
[20:16:18] <dkg> i just lost ted's voice
[20:16:23] <dkg> can other folks hear?
[20:16:25] <sftcd> still ok here
[20:16:26] <Barry Leiba> I can
[20:16:30] <vladimir.cunat> yes.
[20:16:30] <jhoyla> Works for me.
[20:16:34] <dkg> ok, i'll reconnect
[20:16:47] <Martin Thomson> I'm getting cut-outs occasionally, but they are short
[20:16:55] <mcr> hta, there are IPsec things that now exist that help with the VPN stuff.  
[20:17:05] <dkg> all good now
[20:17:33] <mcr> RFC 8598 <https://datatracker.ietf.org/doc/rfc8598/> hta.
[20:17:40] <adam> hta: I think this is the thing that happens right now, which is that there are certain domains associated with the VPN, and all domains on that list are sent to the resolver associated with the VPN (but no others)
[20:18:11] <vladimir.cunat> I thought the filter is IP-based, typically.
[20:18:16] <mcr> for non-IKEv2 VPNs, it's all over the map, but typically the VPN eats all DNS requests unless they do somethiing smarter.
[20:18:31] <Eric Vyncke> @hta: my understanding based on VPN policies: all queries to the VPN recursive resolver then routing traffic inside / outside the VPN
[20:18:36] <mcr> vladimir, what goes through the VPN is IP-based.  Where does DNS go is another question.
[20:18:50] g.e.montenegro leaves the room
[20:19:01] <adam> vladimir.cunat: I'm not sure what you have in mind. So, I go to a web broswser and type in "foo.example.com". Which DNS resolver is used to turn that into an IP address?
[20:19:05] <Eric Vyncke> Hence the PvD helping to select the right DNS rec server & connection
[20:19:05] <sftcd> not sure I'd describe these options as trade-offs - maybe they're all bad?
[20:19:26] <vladimir.cunat> I meant... you usually need to first resolve a name to find out whether it belongs into a VPN or not.
[20:19:47] <vladimir.cunat> Though ideally you might tell by the name already.
[20:19:50] <sftcd> fwiw, my answer to all three questions would be "yes, but iff it actually works"
[20:19:52] <mcr> vladimir,cunat, yes, that's a good observation.  RFC8598.
[20:19:54] <adam> Right. Which is why the normal usage _today_ is to have domains associated with a VPN
[20:20:14] <Martin Thomson> A flood of +q suddenly arrives
[20:20:16] <jhoyla> @sftcd Isn't it still a trade-off as long as they're not _equally_ bad.
[20:20:17] <mcr> (my opinion is that RFC8598 is broken legacy IPv4 thinking)
[20:20:24] <hta> @adam, that makes some sense - it would have a local distributing resolver (dnsmasq can be configured this way) that distributes queries to different resolvers. what-goes-where is preconfigured.
[20:20:59] <mcr> anyone without webex want to be in the queue?
[20:21:02] <sftcd> @jhoyla: yeah, just that "trade-off" implies to me there's something positive somewhere
[20:21:04] <Barbara Stark> Many networks provide resolution for names that only exist on those networks. If you're bouncing around DNS servers, these will only sometimes work. Esp. prevalent on wireless networks.
[20:21:29] <adam> sftcd: The draft kind of goes into this a bit.
[20:22:25] <Tommy Jensen> +1, that is the status quo for Windows as well
[20:22:26] <sftcd> @adam: yep, lemme describe my position another way: this'd be ok to work on in the WG only if we're willing to drop it if it turns out not to work
[20:22:32] <Nicolai Leymann> Also depends on redundancy. If you do not use anycast but a list of resolvers for redundancy. But this use case might be different from a scenario where you have several "external resolvers".
[20:22:43] <adam> sftcd: Oh, yeah, 100% agree
[20:23:11] york@jabber.isoc.org joins the room
[20:24:01] <sftcd> we also need to consider the privacy leakage over relatively extended periods and different connectivity situations for the same person/device - IIRC the draft does a bit of that
[20:24:11] sureshk@jabber.org joins the room
[20:25:43] <jhoyla> So could you resolve a name over one interface and then connect over the other?
[20:25:53] joehall joins the room
[20:25:57] <Martin Thomson> yes, you could resolve over one and connect over another
[20:25:59] <ek.ietf> not just names available via that network but BCP38 might be in play forcing the client to use the right addresses to talk to the server(s) on that network
[20:26:00] <dkg> sftcd: yeah, if we don't model this leakage over time, we're not modelling the right thing.
[20:26:06] <ek.ietf> (but this is pvd 101)
[20:26:31] joshco joins the room
[20:27:55] <Eric Vyncke> (the raison d'être of PvD)
[20:28:03] <ekr@jabber.org> Well, PvD is the network's opinion -- but that's not the only opinion that matters
[20:28:09] <tfpauly> If you discover a locally-provisioned resolver of a specific interface, you should only use it there; if we add the notion of discovery of a remote resolver that has a broader provisioning domain, then it makes sense to let it be used across local networks
[20:28:32] <Eric Vyncke> @ekr: agreed
[20:28:58] <kaduk@jabber.org/barnowl> Having a useful story to authenticate "this interface's resolver tells
me it claims these DNS names" is an interesting problem, of course.
[20:29:36] <ekr@jabber.org> kaduk: I actually have no idea how to build that in any way that's not just "this is a naked assertion". Can't imagine why I would trust that.
[20:30:08] <kaduk@jabber.org/barnowl> ekr: Yeah, I was being polite
[20:30:13] <ekr@jabber.org> Ah ok
[20:30:23] <tfpauly> That’s part of what I’ll be discussing, so you can chime in there =)
[20:30:31] <mcr> ekr, yet RFC8598 makes that claim via IKEv2.
[20:30:55] <sftcd> I doubt there is one optimal outcome in most scenarios
[20:30:56] <tfpauly> Well split DNS for IKEv2 is a bit different; that was scoping things down rather than expanding
[20:30:58] keithmoore joins the room
[20:30:58] <ekr@jabber.org> mcr: yes, and I reviewed that document, but it's a special case.
[20:31:10] <tfpauly> The other case for IKEv2 is it got *all* names
[20:31:12] <ekr@jabber.org> it's the "this network" piece that's difficult
[20:31:18] <kaduk@jabber.org/barnowl> And we had a long fight^Wdebate about 8598
[20:31:20] Alister Winfield(Sky) joins the room
[20:31:44] <dkg> not to mention that "optimal" means different things for different end users
[20:31:45] <Warren Kumari> I must be being dumb, but in the multiple interfaces scenario, I don't understand how I know which names are out which interfaces - having a few names seems OK for provisioning, but this does not scale....
[20:31:53] <Warren Kumari> I'm guessing I'm jsut being dumb...
[20:32:04] <mcr> I think that there are better ways to build walled gardens, but it means leaving the 1980s IPv4 behind.
[20:32:06] <ekr@jabber.org> tfpauly: what you're saying in your draft is slightly different, which is "the entity associated with this TLS cert will serve these domains"
[20:32:15] <Eric Vyncke> @Ace: easy case is the VPN, else, indeed good luck ;-)
[20:32:15] <sftcd> @warren: each network i/f has to be named after a TLD :-)
[20:32:19] <kaduk@jabber.org/barnowl> Warren: I think that's what ekr, tfpauly, and I were just talking about.
[20:32:22] <Wes Hardaker> no, you're not dumb.  but how to coordinate what that list is to match each interface is, um, TBD
[20:32:53] <ek.ietf> @warren: there need to be some provisioning; someone mentioned 8598
[20:33:02] <Warren Kumari> @kaduk, et al.— possibly - I wasn't following jabber…
[20:33:13] <adam> Warren Kumari: Section 4 has a longer description of this than can reasonably be summarized in jabber. :)
[20:33:23] nemo joins the room
[20:33:53] kivinen leaves the room
[20:33:59] <Seth Blank> +1 to what EKR finds interesting
[20:34:02] kivinen joins the room
[20:34:15] <Warren Kumari> Yeah, I remember reading the RFC when it was a draft, but I still don't see how that scales well....
[20:34:35] <tfpauly> Lol ekr
[20:35:07] <ek.ietf> @ekr: you definitely want to talk to the network's resolver like when you're trying to pass a captive portal
[20:35:13] <neednnelg@sure.im> 214 participants and webex is holding up well
[20:35:55] <adam> ek.ietf: If we only had some protocol that told us when that was necesarry. ;)
[20:35:57] <ek.ietf> "definitely": in very specific circumstance, not universally true
[20:35:58] <Warren Kumari> 'tis fine for corp.exmaple.com and foo.example.net — but I don't see how one claims O(3000) names
[20:36:13] <Warren Kumari> But will reread...
[20:36:15] <Jonathan Lennox> Or NAT64
[20:36:27] <Alister Winfield(Sky)> Or how malicious doesn’t also do the same on some network.
[20:36:34] <jhoyla> @ekr Just for the record you are coming through loud and clear.
[20:36:49] tim costello leaves the room
[20:36:56] <adam> Warren Kumari: The notion is to use several resolvers, with some specially selected stickiness, so that no one resolver gets a full view of all of your activity.
[20:36:57] <ekr@jabber.org> Sorry about that Tommy. David was sending me PMs and I just got confused
[20:37:05] <tfpauly> No worries!
[20:37:08] tim costello joins the room
[20:37:18] <dschinazi> We're used to it by now
[20:37:25] <ekr@jabber.org> ek.ietf, yes, definitely about captive portals
[20:37:26] <Dan Wing> ECMP-like stickiness seems useful here.
[20:37:48] <Warren Kumari> Thats the high level view, but not the "per interface" bit… anyway…
[20:38:50] <sftcd> I set up my own DoT/DoH servers from playing; from very quick scanning (with permission!) I think I could easily enough identify the clients based on the qnames and patterns of query distributions
[20:39:19] <ekr@jabber.org> Oh, I wish I had mentioned: on the concentration piece. I think the message of this draft is that given the current state, privacy actually suggests you would be best concentrating all of your individual queries in a single resolver, though its not  maximally desirable that *everyone* use the same resolver
[20:39:23] <sftcd> those clients were in my home btw so I do kinda know the people
[20:39:47] <Wes Hardaker> @sf: yes, its been studied fairly extensively and there are multiple problems.  It buys you an improvement in privacy, not complete it seems.
[20:39:50] <ekr@jabber.org> sftcd: yes, I think it's quite likely that you can identify people from resolution patterns
[20:39:51] <adam> sftcd: I mean, sure? But security always only makes things better, not perfect.
[20:40:31] <Wes Hardaker> @adam: yes, but I think his point is that it looks worse than was hoped.
[20:40:37] <sftcd> yep
[20:40:56] <ekr@jabber.org> Well, I don't know about "hoped". This, at least, has always been my expectation
[20:41:25] <adam> Wes Hardaker: On a samples size like that, maybe. If the pool is "all customers of large US ISP _x_", that kind of analysis might not be quite as straightforward.
[20:42:05] <dkg> adam: if your goal is tracking a specific individual and you can include metadata like time/location of queries, you can still generate a pretty good guess
[20:42:11] <Wes Hardaker> more data always makes it more difficult, yes.  But if you're looking at the outgoing pipe from the ISP with current DNS you only know "someone is going to facebook".
[20:42:17] Tim Wicinski leaves the room
[20:43:04] <mcr> at what point do our stub resolvers get complex enough that they are just recursive secure resolvers?
[20:43:20] <Wes Hardaker> sometime yesterday I think.
[20:43:42] <Vittorio Bertola> I also don't get how this is different (in terms of who sees what) from just running a full resolver on each device.
[20:44:04] <Pete Resnick> This is the difference between the way VPNs work and other per-interface resolvers: VPN interfaces serve up a list of domains that say, "Lookup these here". That might be a useful feature for other resolvers.
[20:44:05] <adam> mcr: Quoting a friend who is always helpful when these kinds of issues arise: "Taxonomy is bunk."
[20:44:11] <Vittorio Bertola> Except that you could already do that today with existing protocols, that is :-)
[20:44:40] pietro joins the room
[20:44:46] <ekr@jabber.org> One thing to note here is that *this* design requires DNSSEC, which ESNI does not
[20:44:52] <Jonathan Lennox> Do the root servers do DoT?
[20:44:59] <ekr@jabber.org> LOL. NO
[20:45:01] <Ted.h> No.
[20:45:06] <Jonathan Lennox> So that's one difference...
[20:45:51] <ekr@jabber.org> (The reason ESNI does not require DNSSEC is that if the attacker controls DNS, then you are already screwed for SNI)
[20:46:07] <leifj> any academic research yet on privacy aspects of DoH based on current deployment ?
[20:46:27] <ekr@jabber.org> leifj: yes, some. At least some traffic analysis is possible so more work to do
[20:47:38] <vladimir.cunat> Sad thing is that the IP address sets themselves are often sufficiently unique to identify who you're talking to.
[20:48:00] <mcr> but, given 7706bis, do we really even need (many) root servers? ??
[20:48:15] Olaf Kolkman leaves the room
[20:48:27] Olaf Kolkman joins the room
[20:48:29] <vladimir.cunat> Privacy leak to root servers is easy to avoid.
[20:48:38] <vladimir.cunat> Completely.
[20:48:40] <ekr@jabber.org> vladimir.cunat: yes, that is a problem. one thing at a time :)
[20:49:06] <sftcd> more slides are visible at https://datatracker.ietf.org/meeting/107/materials/slides-107-add-adaptive-dns-paully
[20:49:28] <vladimir.cunat> ekr@jabber.org: the next step is to get the services even more cetralized to CDNs?
[20:49:37] <tale > … so who do we talk to about Apple products? :)
[20:49:40] <ekr@jabber.org> vladimir.cunat: not really
[20:49:41] <Martin Thomson> doesn't this overload the PvD semantics in an uncomfortable way?  my understanding is that PvDs allocate a domain name to an access network; but this presumes something about a target origin in a context other than network access.
[20:49:44] <Alister Winfield(Sky)> This is potentially a wonderful game for data aggregators….run DoH endpoints and collate the data on behalf of the app provider. Not sure how to avoid this privacy leak.
[20:50:10] <kaduk@jabber.org/barnowl> What breaks if you swap out .well-known/pvd for [insert name here]?
[20:51:02] <ChrisBox> Alister: do you mean website x designates doh.tracking-company.com ?
[20:51:34] <Alister Winfield(Sky)> Yes…. It would be advantageous for some to ‘sell’ the data to get the benefits back from the adverts.
[20:51:47] <leifj> an ecosystem for traffic analysis... sounds like a plan!
[20:52:00] <sftcd> +1 to being worried about the failure cases here (well, maybe more than 1;-)
[20:52:35] <jhoyla> @ Alister Winfield(Sky) that's a really nasty thought.
[20:52:42] <Jonathan Lennox> How does knowing the site names someone looked up at your domain give you substantially more tracking info than knowing the hostnames someone actually connected to at your domain?
[20:53:25] <bemasc> I've heard this called a "business dynamic instability".
[20:53:41] <Alister Winfield(Sky)> You get the ‘fails’ and near misses that the ‘connections’ don't
[20:53:58] Cullen Jennings leaves the room
[20:54:02] Cullen Jennings joins the room
[20:54:18] Cullen Jennings leaves the room
[20:54:20] pietro leaves the room
[20:54:27] Eric Kinnear leaves the room
[20:54:35] Cullen Jennings joins the room
[20:54:35] Cullen Jennings leaves the room
[20:55:29] <Jonathan Lennox> Yeah, but how big a deal is that for privacy? Unless there's a substantial amount of privacy-significant behavior where someone does a DNS lookup and then decides not to connect.
[20:55:53] Bernie Hoeneisen joins the room
[20:55:56] <bemasc> See also W3C Network Error Logging
[20:56:11] <jhoyla> @Jonathan Lennox I do that a lot for DNS leak testing.
[20:56:36] <jhoyla> Which is a privacy valent behaviour.
[20:56:59] <sftcd> how easy is it to know you're using a different source of DNS answers?
[20:57:04] Jay Daley leaves the room
[20:57:09] <sftcd> a quad-N could be upstream of anyone
[20:57:15] <Jonathan Lennox> Fair, but you're presumably doing that to a local DNS recursive resolver (that being the point) rather than to a site's DoH?
[20:57:40] <kaduk@jabber.org/barnowl> Reasoning about the trust properties of interactions between the Web
PKI and DNS is always exciting.
[20:58:06] Jared Mauch joins the room
[20:58:07] <sftcd> given one of the advantages of DoH is that the application knows it's being done, depending on different sources of DNS answers to bootstrap DoH for some names seems counterintuitive to me
[20:58:30] <leifj> +1
[20:58:30] teirdes joins the room
[20:58:30] <mcr> probably good to still identify yourself at the mic :-)
[20:58:50] carrickdb leaves the room: Disconnected: closed
[20:59:01] <Pete Resnick> If you have your display right in webex, you can see who's speaking.
[20:59:04] <vladimir.cunat> +1
[20:59:21] <Jonathan Lennox> The one with the blue box above the slides, right?
[20:59:39] <Barry Leiba> Pete, how do you set your display to be right?
[20:59:51] behcet joins the room
[20:59:57] <mcr> Pete, with 220 people, the participant list doesn't auto-scroll, so it's hit and miss.
[21:00:01] <Eric Vyncke> @jonathan: yes
[21:00:10] <Jared Mauch> depends on which UI you are using.. eg: you can dial with the webex app or webex teams (the number @ietf.webex.com) etc
[21:00:20] <Pete Resnick> Upper right corner of the section where the presentation is displayed, you'll see a little control that gives you a few choices.
[21:00:28] <Pete Resnick> The one without the scrolly bit is best.
[21:00:58] <Martin Thomson> did we skip mcmanus?
[21:00:59] <mcr> so, it just says "Tommy" in the upper big box, where the video could be, but there is some minimum speak time before it switches.
[21:01:10] <Martin Thomson> nevermind, we lost him, my bad
[21:01:11] <kaduk@jabber.org/barnowl> I think stating your name should be part of the mic check
[21:01:37] <mcr> +1
[21:01:39] <erik> To EKR's concern, one approach would be that the .well-known/pvd would have its domain be the SvcDomainName in the HTTPSSVC record.  For example with:  "www.example.com 7200 IN CNAME foo.cdn1.example."   and "foo.cdn1.example. 7200 HTTPSSVC 1 ."  then if the policy is on "https://cdn1.example/.well-known/pvd" it would apply for just that one CDN.  And since it is the A/AAAA records for "foo.cdn1.example" which want to have lower TTLs and the CDN-controlled mapping then this addresses the issue.  
[21:02:06] <ekr@jabber.org> glad to hear we have a candidate solution
[21:02:08] <tale > patrick dequeued
[21:02:15] <mcr> copied to etherpad, @erik.
[21:02:50] <erik> (thanks)
[21:04:04] <Jared Mauch> +1
[21:04:09] <bemasc> (mic) [Ben Schwartz] I understand how this scheme improves privacy when combined with Oblivious DNS, but in the absence of Oblivious DNS (which is out of scope for ADD) I think this is only a privacy improvement for certain assumptions about TTLs, and some queries will leak when TTLs expire.  I'd like to see those assumptions clarified, and see if there is a simpler solution, such as using long-lived CNAMEs.  I'd also want some consideration about whether these long TTLs are a tracking vector.
[21:04:10] <Alister Winfield(Sky)> +1
[21:05:05] <leifj> ok so if we centralize everything to cloudflare we're good ... gotcha
[21:05:47] <mcr> can you post your long-lived CNAME idea as an email, thank you.
[21:06:14] <evequefou> Is Oblivious in-scope for a different WG?
[21:06:20] <mcr> they are all google names :-)
[21:06:41] <Martin Thomson> function isGoogleName(name) {
[21:06:41] <jhoyla> Also the list of names in scope may change
[21:06:44] <Martin Thomson> return true;
[21:06:52] <Warren Kumari> *everything* is a google name :-P
[21:06:54] <tale > lawl
[21:06:58] <jhoyla> For example if a site changes CDN provider.
[21:07:07] healthyao2000 leaves the room
[21:07:08] <Warren Kumari> By that time you've leaked the question...
[21:07:18] <Jared Mauch> glenn audio is interesting now
[21:07:30] <adam> "Switch it over" has unfortunate implications that are covered in Jari & Ted's document.
[21:07:38] <Warren Kumari> Indeed.
[21:07:48] <Jonathan Lennox> I saw both "Glenn Deen" and "GDeen" active in the speaker list when the audio was interesting
[21:08:06] <bemasc> Warren, this is what I was talking about.  The assumption is that "For *.google.com use https://dns.google/dns-query" has a TTL of weeks, and is cached locally.
[21:08:12] <kaduk@jabber.org/barnowl> Jonathan Lennox: It did sound like he had two mics active, yeah.
[21:08:51] <jhoyla> Also, you might have a geocities style site, where there are different owners of different sub-domains.
[21:09:02] marka leaves the room
[21:09:02] Vicky leaves the room
[21:09:11] <keithmoore> Anytime someone proposes different solutions for home vs. enterprise networks that raises a red flag.   It would help to have some idea of what the expected difference is.
[21:09:32] <dkg> jhoyla: that just means that the site is itself a public suffix, right?
[21:09:33] Vicky joins the room
[21:09:33] Vicky leaves the room
[21:10:17] <Pete Resnick> I'm hoping that "home network" means "ISP provided network", and that "enterprise network" means "company private" network.
[21:10:56] <jhoyla> @dkg , right, but it's just an example where you can't assume that subdomains trust either each other or the parent domain.
[21:10:58] behcet leaves the room
[21:11:00] <keithmoore> Pete: that would be my first guess, but it still raises a red flag.   I really don't want to see different protocol stacks for different kinds of networks.
[21:11:06] marka joins the room
[21:11:09] <adam> jhoyla: Yep. There's a practical but imperfect solution at https://publicsuffix.org/ -- there was an attempt to develop a better solution in the DBOUND working group, but that failed to reach consensus.
[21:12:07] <Pete Resnick> @keith: I suspect it's not a different protocol stack, but a different set of config parameters. Maybe s/suspect/hope.
[21:12:21] <keithmoore> Pete: slippery slope :)
[21:13:50] <keithmoore> We should not presume that either a DHCP server or the ISP have the right to dictate what DNS service is used.
[21:14:05] Eric Kinnear joins the room
[21:14:24] <dkg> keithmoore: i agree that for some users, the ISP is a part of the threat model
[21:14:41] <keithmoore> dkg: whether they know it or not
[21:14:59] Eric Kinnear leaves the room
[21:15:16] tim costello leaves the room
[21:15:30] tim costello joins the room
[21:15:41] <adam> I'm wheezing over here
[21:15:56] <leifj> @dkg @keithmore but not all users and not all ISPs - lets not throw the baby out with the bathwater here
[21:16:05] <jhoyla> Is there another type of ISP?
[21:16:05] <Vittorio Bertola> But there are also situations in which the destination server or the application maker are potentially a threat and the ISP is not. It really depends on who gets trusted by the user
[21:16:43] <adam> Yep. This is why the charter stipulates that " Making any recommendations about specific policies for clients
or servers is out of scope."
[21:16:53] nemo leaves the room
[21:16:58] <keithmoore> leifj: agree that different users will rank threats in different orders
[21:17:08] <Jared Mauch> there's many types of ISPs and the fact that most of this is around "we hate the ISPs" is very concerning
[21:17:16] <leifj> my point is that ISPs are different
[21:17:32] <Jonathan Lennox> CPEs only get upgraded when they break.  Fortunately, this is frequent…
[21:17:41] <stpeter> MT: are you worried about physical upgrades or firmware upgrades or both?
[21:17:51] <Martin Thomson> stpeter: yes
[21:17:54] <stpeter> :-)
[21:17:55] <sftcd> seems like MT's critique is kinda telling - if new DHCP options just don't get used then maybe it's the wrong path...
[21:18:17] <Martin Thomson> that said, I think that generally DHCP (or RA, or PvD) is the right architectural approach
[21:18:24] <Jared Mauch> many CPE are never updated unless they auto-update.. i bet there's still 802.11b WAP11's out there with very buggy dnsmasq
[21:18:37] <ek.ietf> why would I care very much about TLS on just the first hop?  I'd want the ISP CPE to be doing DoT/DoH/DoQ for its forwarding too
[21:18:38] <keithmoore> This isn't about hating ISPs at least for me.  It's recognizing that, architecturally speaking, the model that presumes that the ISP dictates the DNS service is itself a privacy threat.   It may be the most benign threat for some set of users but it's still a threat.  It's not to say that ISPs are bad, but they certainly can be.
[21:18:39] <Martin Thomson> I just don't think that this is short-term realistic from a deployment perspective
[21:18:55] <stpeter> nod
[21:19:03] <Vittorio Bertola> In Europe, users have the right to use their own CPE of choice. So you cannot presume that ISPs, even if they wanted, will be able to control/upgrade 100% of them.
[21:19:44] <adam> Adding to what keithmoore is saying -- this is paricularly true because devices cannot in general tell the difference between "my ISP," "the local coffee shop's WiFi," and "Some black-hat's Pineapple"
[21:19:45] <Martin Thomson> What Vittorio said is true elsewhere also.  And CPE tends to be quite old.
[21:19:47] <Jared Mauch> +1(wes) about losing the cache efficiency
[21:19:52] <keithmoore> Vittorio: then the CPE vendor is a threat :)
[21:20:00] <Jared Mauch> Yes, the CPE vendor is a known issue.
[21:20:14] <mcr> the CPE vendor is a hostile actor :-)
[21:20:18] <erik> One advantage to using DoH for some of these cases is that angle around being able to specify different policies for different devices for cases where users do want to have different policies for different devices (eg, for "parental controls").
[21:20:19] <Jared Mauch> but this is the IETF so operational information is out of scope
[21:20:20] <Alister Winfield(Sky)> Caching at the CPE also helps especially on slower home connections.
[21:20:25] <Vittorio Bertola> Everyone can be a threat.
[21:20:29] <kaduk@jabber.org/barnowl> Apparently Wes did not like my idea to use  "state your name" as part
of the "is my mic working?" check
[21:20:37] <Wes Hardaker> whoops, sorry.
[21:20:42] <keithmoore> Vittorio: indeed.  
[21:21:14] <tfpauly> One relevant suggestion that @Tommy Jensen had offered on our GitHub that could be an interesting alternative for the local discovery case that doesn’t require adding DHCP/RA: https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/issues/86
[21:21:28] dkg joins the room
[21:22:12] marka leaves the room
[21:22:13] Vicky joins the room
[21:22:14] <erik> Users need to be able to pick alternates, but using a well-managed ISP resolver is a good default in many cases.  (For some examples of where there are ISP-managed CPE devices, look for wireline ISPs with very high IPv6 adoption.  It's been easier for ISPs to get very high IPv6 adoption when they have a small number of CPEs that they can manage and upgrade.)
[21:23:01] <mcr> yeah, ISP managed devices *can* result in good IPv6 adoption. I wish it was true more often :-(
[21:23:20] <keithmoore> erik: good default = slippery slope.   Though certainly if the user expects to get support from the ISP when the user's browser stops working, the ISP likes it if they control the DNS resolution - fewer things to break that they can't fix.
[21:23:42] <Warren Kumari> Meta comment (*not* related to this) — much of this feels *very very* complex…. We need to make sure that the solutions we are discussing are worth the complexity / pain….
[21:24:00] <sftcd> @warren: I agree with you
[21:24:06] <keithmoore> warren: concur
[21:24:11] <erik> +1 to @warren on the complexity of some of these
[21:24:16] <vladimir.cunat> +1
[21:24:17] <Pete Resnick> @wk: +1
[21:24:19] <Jared Mauch> +1 warren
[21:24:57] <mcr> I wanted to add, without taking mic time, that we actually have found a few entities willing to act as auditor, and they want a complete remote attestation (RATS) on the boot and configuration of the DNS server as part of their evaluation.
[21:25:01] <keithmoore> I feel like this problem has been lurking for 25 years - probably because it gets really ugly when you try to address it.
[21:25:05] <Pete Resnick> Warren: That (and that there were a number of +1s) should probably be written in the minutes somewhere.
[21:25:09] <Martin Thomson> So making another CA/B Forum is likely not to be worth the activation energy cost.
[21:25:31] <Ted.h> @wseltzer are you thinking p3p when hearing this, or is it only my own scars?
[21:25:31] <wseltzer@jabber.org> MT +1
[21:25:33] <Pete Resnick> Or maybe should be said outloud at the ending QA.
[21:25:38] <Paul Hoffman> Maybe making the first one wasn't either. :-)
[21:25:38] Bernie Hoeneisen leaves the room
[21:25:44] Bernie Hoeneisen joins the room
[21:25:55] <sftcd> @MT: isn't this list of PAT signers a bit like a list of TRRs though?
[21:25:56] <wseltzer@jabber.org> @Ted EEEEK
[21:26:05] <mcr> you don't need CA/B forum complexity. Most of this is within trusted computing space.  While you may find TCG hard to deal with (I do), there is a reason this work has come to the IETF.
[21:26:11] <Martin Thomson> sftcd: you caught us :)
[21:27:01] jhoyla joins the room
[21:27:08] <adam> Ted.h: That occurred to me also
[21:27:31] <Vicky> We need some standard privacy policies, akin to widely-accepted open source licenses so people don't have to parse them closely.
[21:27:40] <Alissa Cooper> A design premised on users reading privacy policies seems unsupported by empirical research about users.
[21:27:45] <Ash> YES
[21:27:47] <mcr> Vicky: +1
[21:27:52] <Ash> I completely agree, Vicky
[21:27:53] <Jared Mauch> cooper+1
[21:28:03] <Ash> Because nobody reads EULAs
[21:28:04] <wseltzer@jabber.org> @Ted.h P3P took years to obsolete
[21:28:05] <dkg> Alissa Cooper: agreed
[21:28:11] <mcr> as an end-user, anyone who makes their own is deeply suspicious :-)
[21:28:16] <Martin Thomson> PP0 analogous to CC0, except that PP0 means no privacy
[21:28:32] <sftcd> @Alissa: yeah true, a design premised on the likes of EFF reading 'em is less bad though (not saying this is that)
[21:28:54] <teirdes> cooper +1
[21:29:10] <teirdes> sftcd: or public authorities. practically speaking (and depending on your jurisdiction).
[21:29:27] <wseltzer@jabber.org> @sftcd, ahh, the Better Business Bureau model of privacy rankings
[21:29:33] <mcr> I think 95% of users will have two PATs: home and work (BYOD).  The rest of the time, they will probably opt to use public DoH rather than Starbucks.  Company lawyers might read the Hilton "PPx" and configure that yes/no into the company laptops.
[21:29:37] <wseltzer@jabber.org> ... and all the games that entails
[21:29:52] <sftcd> @wendy: not so much ranking, more like a properly cranky auditor
[21:30:01] <dkg> published policies seem only useful if (a) there are good policies published, and (b) dedicated advocates can raise a stink when an entity publishes bad policies, and can take meaningful action against groups that violate their stated policies
[21:30:02] <Jonathan Lennox> Or regulator?
[21:30:11] marka joins the room
[21:30:39] <Warren Kumari> Quick, someone give dkg some cash!
[21:30:45] <leifj> users trust "brands" - my guess is there is a class of users who would trust the ACLU DoH server more than the starbucks one
[21:30:46] <dkg> don't look at me, Warren Kumari
[21:30:54] <mcr> dkg, I keep hoping that government travel authorities will stamp out hotels that run DNS lying captive portals.
[21:31:01] <Warren Kumari> s/dkg/eff/
[21:31:02] dkg leaves the room
[21:31:02] <leifj> if given the choice that is
[21:31:03] <wseltzer@jabber.org> right, ratings more than rankings; but still requires some teeth to hold both raters and promisers accountable
[21:31:08] <sftcd> I heard dkg makes bad coffee though:-)
[21:31:11] <Jonathan Lennox> dkg: And can *discover* when entities violate their policies, which seems non-trivial
[21:31:17] <Jonathan Lennox> Depending on the violation
[21:31:23] <leifj> maybe coffee isnt a factor in privacy...
[21:31:26] <leifj> go figure
[21:31:30] <Vicky> ACLU and EFF could 'endorse' specific 'standard policies' and people who care about their opinion can insist on those
[21:31:30] <Warren Kumari> Oooh, I've never had dkg coffee — is hter a backstory / inside joke I'm missing?
[21:31:32] <dkg> Jonathan Lennox: right, that's always the fly in the ointment for privacy violations :(
[21:31:40] <wseltzer@jabber.org> and can get entities to make enforceable promises, rather than empty statements "we take your privacy seriously"
[21:31:43] <Jared Mauch> careful what you wish for w/ regulators getting involved, it can reduce the innovation space and then we end up with everything over TCP/443
[21:31:50] <leifj> @vicky I don't think the "off by one" link to policy will work
[21:31:54] carrickdb@jabber.calyxinstitute.org joins the room
[21:31:55] <mcr> dkg is secretly the real owner of Starbucks. That's my guess.
[21:32:00] <Warren Kumari> @jared - you mean things like DNS over 443?!
[21:32:11] <dkg> i don't even make coffee at all, that's how bad my coffee is
[21:32:12] <Warren Kumari> That would be crazypants...
[21:32:23] <keithmoore> I have yet to see a good model for effective user consent to privacy policies.    Agree that few users will read or understand written policies.   But having some 3rd party say "trust us, the policy models we propose are the right ones for you to pick from", is little better (if at all) from vendors saying "trust us, our privacy models are reasonable".   Because the industry leaders will try very hard to influence such privacy standards in their favor.
[21:32:32] <mcr> starbucks and all coffee shops are closed, so we look to dkg to make us coffee.
[21:32:34] <leifj> I make pretty good coffee but I'll leak everyones data
[21:32:46] <Vicky> we have managed to whittle down the # of open source licenses that are really widely used, over time by discouraging and penalizing anyone who insists on coming up with yet another one
[21:32:54] <Jonathan Lennox> As long as you don't leak coffee
[21:33:12] <dkg> Vicky: and people still try to make up new ones every year
[21:33:17] <leifj> @vicky true but the # of people who understand the notion of a license is not representative here
[21:33:19] <teirdes> the issue with privacy policies is that they get written to alleviate actors from a risk of being sued, so they are formulated entirely to the benefit of the stipulator
[21:33:24] <Jared Mauch> what is also going on here is some ISPs did experiments (like how some protocol people did experiments) and they failed (eg: AT&T giving a discount if you permitted sale/studying of DNS data)  - they failed, they changed practices, and much of this is a 5-10 year ex-post-facto response to those historical behaviors
[21:33:33] Benno Overeinder joins the room
[21:33:40] <leifj> @teirdes yes
[21:33:45] <keithmoore> Vicky: but is whittling down OS licenses a good thing?   or can it be taken too far?
[21:33:48] <dkg> keithmoore: i think you're saying that supposed oversight groups like BBB suffer from regulatory capture
[21:33:50] stpeter whispers "dark patterns"
[21:33:59] <teirdes> that's if they get made under contractual freedom in jurisdictions where contractual freedom is not particularly restricted (pretty much every (former) common-wealth country)
[21:34:26] <teirdes> but there's like.. most of the world's jurisdictions where that isn't necessarily the case - and it's not clear how users /should/ exercise their freedom of choice /without/ consenting either.
[21:34:28] <keithmoore> dkg: at least that's one version of the problem
[21:34:29] <Vicky> the similarity to OS licenses is that, anyone CAN publish a new one, but people are leery of adopting stuff that uses a wierd new license. so it is not a hard limit
[21:34:54] <Warren Kumari> Are others having a weird buzzing clip for Daniel?
[21:34:58] <Vicky> y
[21:34:59] <Jonathan Lennox> Yes
[21:35:01] <Alexey Melnikov> Yes
[21:35:03] <Vittorio Bertola> yes
[21:35:06] <dkg> definitely buzzing
[21:35:07] <kaduk@jabber.org/barnowl> Yes, Daniels' mic is bad(ly configured)
[21:35:09] <leifj> @vicky true but the reason people trust OS licenses is very different from this case
[21:35:20] <dkg> Daniel is actually a robot, and he's glitching
[21:35:38] <Warren Kumari> But how? it doesnt sound like gain clipping (it a hight pitches buzz)
[21:35:40] <Vicky> in this case it would be because of endorsements from, e.g. aclu, eff, that sort of org
[21:35:47] <Warren Kumari> its not popping
[21:35:49] <adam> Jared Mauch: I hate to pick on any one company, but I'd be curious to know of any evidence you have that they changed practice as opposed to simply stopping the discount. Keep in mind that xandr.com is an AT&T company, and therefore explicitly a company that they share "operational data" with.
[21:36:30] <kaduk@jabber.org/barnowl> The distribution of when it happens reminds me of clipping, but I
agree it's not quite a traditional clipping
[21:36:31] <Warren Kumari> I often wish I understood audio artifact causes better… like the "taking in a tin can" mode, etc.
[21:36:55] <Barbara Stark> AT&T has a specific (admittedly opt out) privacy selection people can make as to whether or not their DNS info can be used to provide targeted ads.
[21:37:08] <leifj> @vicky yes get that point - just not sure if "brand X endorses Y" will be enough
[21:37:09] <Warren Kumari> I cna usually picky up an echochanceller oscillating badly, but...
[21:37:10] <Jonathan Lennox> I feel like it's a compression artifact - maybe packet loss?
[21:37:18] <Barbara Stark> My understanding is that selection is honored.
[21:37:27] <Jonathan Lennox> Bad error concealment on packet loss on the audio?
[21:37:34] <sftcd> uplevelling a bit, it's not clear to me how any of the works presented today get to the point where they could be candidates for WG adoption, each seems to have some fairly hard problems that'd need solving first, so I'll be curious how the ever-wise chairs figure that one out
[21:37:36] <adam> Barbara Stark: Thanks! I'll go looking for that.
[21:37:38] <Jared Mauch> my intention was to give an example of a commercial thing in the marketplace that went away
[21:37:43] <Jared Mauch> not to pick on at&t or barbara stark
[21:37:45] <leifj> Daniel isn't using audiophile ethernet
[21:37:51] <cvmiller> @lennox +1
[21:37:53] <keithmoore> shell game: tell people they can opt out of targeted ads, and hope they won't notice the other ways their DNS queries can be abused
[21:38:07] <tfpauly> I believe doing a SVCB lookup requires the port along with the _dns service right, @erik?
[21:38:12] <Warren Kumari> @Jonathan - perhaps, but it seems to correlate with specific phenoms
[21:38:14] <Barbara Stark> Jared Mauch: Where's the fun in that?
[21:38:25] <Warren Kumari> phonems… (autocorrect fail)
[21:38:33] <Jared Mauch> :-)
[21:38:34] <bemasc> @tfpauly, he's proposing a new scheme so it's up to the new scheme mapping
[21:38:47] <Warren Kumari> phonemes… good laords...
[21:39:01] <dkg> Warren Kumari: when you're in a hole, stop digging
[21:39:02] <Warren Kumari> One day I will learn to type, really I will...
[21:39:15] Eric Kinnear joins the room
[21:39:32] xp29srs leaves the room
[21:40:01] <bemasc> (mic) [Ben Schwartz] https://public-dns.info/ has 11,000 resolvers.  Do you propose to publish them all
[21:40:03] <leifj> maybe the time has come for DHCP-over-NAPTR
[21:40:27] <Warren Kumari> I've reached the "I cannot type well, therefore I will randomly and arbitrarily change keyboards, because that will fix it" swapping stage…
[21:42:11] <Jonathan Lennox> Hypothesis: concealment has more problems with some phonemes than others (vowels are easy, consonants are hard)
[21:42:11] Andrew Campling joins the room
[21:43:36] <Pete Resnick> @sf: I think your comment about "problems to be solved" in all the documents, it seems related to Warren's comment above about "complexity".
[21:43:55] Cullen Jennings joins the room
[21:44:06] bemasc leaves the room
[21:44:23] <sftcd> @pete: complexity yes, but also who-owns-the-list, which seems to be kind of what started all the fuss about DoH wasn't it
[21:44:39] <Martin Thomson> time to move on
[21:44:51] <Warren Kumari> Like Puneet, I'm lost...
[21:45:02] leifj leaves the room
[21:45:03] leifj joins the room
[21:45:25] <Martin Thomson> that probably won't fit in a UDP packet
[21:45:39] <Warren Kumari> gzip -9 …
[21:45:44] <pardue> probably..
[21:45:50] bemasc joins the room
[21:45:51] <ek.ietf> Datagrams of Unusual Size
[21:45:59] <Paul Hoffman> Ummm, there are >100,000 in the last count I saw.
[21:46:20] <marka> DNS messages are 64K, still too small but DNS is not just UDP.
[21:46:30] <Jared Mauch> openresolverproject has a few million it sees :-)
[21:46:32] <marka> Or DoH or DoT
[21:46:33] <Vittorio Bertola> What happened to the Internet where you just brought up your server, connected it to the network and everybody would be able to use it without any centralized vetting/authorization/whitelisting/etc ?
[21:46:33] <kaduk@jabber.org/barnowl> Warren: we have zstd now; no need for gzip
[21:46:34] <erik> If this was for associated resolvers (ie, non-DNSSEC signed and you your Do53-resolver-from-DHCP gives you back these answers by inserting a name here) then maybe...  But trying to curate a single global list in a way that anyone or anything could meaningfully pick from seems like doom.
[21:46:36] <Warren Kumari> and if gzip -9 doesn't fix it, gzip -9 resolver_list.txt | gzip -9 | gzip -9… done...
[21:46:46] pietro joins the room
[21:46:48] <Jared Mauch> `bzip2 -9`
[21:46:54] <tale > if only we knew who ran openresolverproject
[21:47:00] <Martin Thomson> I think that Daniel was pointing out that the list of resolvers willing to receive queries from any client might be shorter than that
[21:47:08] <keithmoore> +1 to Harald's comment
[21:47:12] <leifj> +1
[21:47:34] <Warren Kumari> (Sorry, I keep forgetting that this isn't jsut for snark)…
[21:47:35] <Martin Thomson> cat list | gzip -9 | gzip2 -9 | zstd | brotli | ???
[21:47:37] <erik> and just wait until intergovernmental policy makers get involved, which for this they will try.
[21:47:39] <sftcd> @MT: that's likely currently a fairly short list, but I could see it getting longer
[21:47:51] <leifj> @dnsborat sais /etc/resolvers.txt
[21:47:52] <Jared Mauch> @martin you left out rot13 to secure it
[21:47:53] <Martin Thomson> sftcd: I still think that it's a fairly long list
[21:48:03] <sftcd> me too
[21:48:27] <kaduk@jabber.org/barnowl> Jared: triple-rot13 for good measure
[21:48:56] <mcr> the audience doesn't seem to have a mic line.
[21:49:13] <Jonathan Lennox> Or indeed an aisle - how do they get to those chairs?
[21:49:13] <joehall> reboot Preview.app! :)
[21:49:17] <Vittorio Bertola> double rot13 should be enough for everyone :-D
[21:49:23] <marka> Webex reconnect timers are too low.
[21:49:41] <Vicky> thank you Barbara for taking notes
[21:49:46] <erik> (I actually thought this worked surprisingly well...  Despite missing seeing you all in person.)
[21:49:54] <sftcd> not for the mic but I think this meeting suffered more from the lack of hallway/bar time than dispatch, probably just because it's a harder problem
[21:49:54] <Dan Wing> +1 to Martin's comment.
[21:50:07] <neednnelg@sure.im> +1000 on thank you Barbara - the notes are great
[21:50:11] <leifj> +1 sftcd
[21:50:26] <tfpauly> I think we need networks providing some resolver info too, Martin
[21:50:28] <ek.ietf> I think "clients gonna client"
[21:50:31] <tfpauly> But not only that
[21:50:58] <ek.ietf> clients need to validate any of the information given them, even just with test queries
[21:51:06] bemasc joins the room
[21:51:10] <Vittorio Bertola> Paul, that's the top of the todo list for me
[21:51:16] <mcr> huh?  I thought that all of these things were about, how I can get enough information to be able to upgrade to encrypted.
[21:51:19] <Tommy Jensen> +1, yes, I would love to talk about negotiating encrypted protocols with a server already configured for classic DNS
[21:51:19] <ek.ietf> so "discovery" needs to some be better than trial and error
[21:51:20] bemasc leaves the room
[21:51:24] <ek.ietf> but trial is gonna happen anyway
[21:51:26] <ek.ietf> so...
[21:52:05] <Martin Thomson> This question gets very much into a policy question.
[21:52:07] <Vittorio Bertola> "upgrade to encrypted" = "I already have a resolver configured, I just want to connect to it via DoH/DoT rather than unencrypted DNS"
[21:52:30] <leifj> +1 vittorio
[21:52:37] <Jonathan Lennox> And hopefully for a secure definition of "it"
[21:52:55] <marka> EDNS OPTION and ask with QCOUNT=0
[21:53:28] <Vicky> +1 vittorio
[21:53:35] <keithmoore> yeah I assume upgrade to encrypted involves getting a trust anchor for the server from a trusted source
[21:54:05] <Vicky> what are the bells for?
[21:54:24] <kaduk@jabber.org/barnowl> I think the bell is the "new chat message" indicator
[21:54:32] <Vicky> ty
[21:54:39] <kaduk@jabber.org/barnowl> Which is perhaps useful given that "new chat message" basically means
"someone got in the mic line"
[21:54:40] <ek.ietf> they complement the whistles
[21:55:58] <leifj> thx
[21:56:02] Vicky leaves the room
[21:56:02] leifj leaves the room
[21:56:05] mnot leaves the room
[21:56:05] Cullen Jennings leaves the room
[21:56:08] ek.ietf leaves the room
[21:56:10] Francisco Arias leaves the room
[21:56:11] Melinda leaves the room
[21:56:13] frode leaves the room
[21:56:13] Eric Vyncke leaves the room
[21:56:14] SHollenbeck leaves the room
[21:56:15] shuque@sure.im leaves the room
[21:56:17] Samuel Weiler leaves the room
[21:56:17] Paul Hoffman leaves the room
[21:56:17] erik leaves the room
[21:56:26] carrickdb@jabber.calyxinstitute.org leaves the room
[21:56:27] Bob Moskowitz leaves the room
[21:56:28] andronkyr leaves the room
[21:56:29] Vittorio Bertola leaves the room
[21:56:30] Magnus Westerlund leaves the room
[21:56:31] Jonathan Hammell leaves the room
[21:56:34] Atarashi Yoshifumi leaves the room
[21:56:39] Andrew Campling leaves the room
[21:56:42] Nicolai Leymann leaves the room
[21:56:42] wseltzer@jabber.org leaves the room
[21:56:44] Glen (AMS IT) leaves the room
[21:56:47] kivinen leaves the room
[21:56:47] keithmoore leaves the room
[21:56:50] Jonathan Lennox leaves the room
[21:56:57] shuaiizhao leaves the room
[21:56:57] spencerdawkins leaves the room
[21:57:02] Samuel Weiler joins the room
[21:57:03] Duane Wessels leaves the room
[21:57:19] cvmiller leaves the room
[21:57:32] joehall leaves the room
[21:57:59] tfpauly leaves the room
[21:58:13] pardue leaves the room
[21:58:15] Barbara Stark leaves the room
[21:58:24] Thomas Peterson leaves the room
[21:58:42] vladimir.cunat leaves the room
[21:58:46] mcr leaves the room
[21:58:48] Willem Toorop leaves the room
[21:59:27] pietro leaves the room
[21:59:35] martin.duke leaves the room
[22:00:47] msk leaves the room
[22:00:55] Mirja leaves the room
[22:00:56] Martin Thomson leaves the room
[22:01:31] jon-ietf leaves the room
[22:02:56] pietro leaves the room
[22:03:19] neednnelg@sure.im leaves the room
[22:03:53] sftcd leaves the room
[22:04:16] Benno Overeinder leaves the room: Disconnected: closed
[22:04:27] teirdes leaves the room
[22:04:37] tale leaves the room
[22:04:55] Seth Blank leaves the room
[22:05:00] avezza leaves the room
[22:07:08] bemasc joins the room
[22:07:33] tim costello leaves the room
[22:07:41] Hugo Salgado leaves the room
[22:10:06] Eric Kinnear leaves the room
[22:10:44] Eric Kinnear joins the room
[22:11:00] Alissa Cooper leaves the room
[22:11:06] sureshk@jabber.org leaves the room
[22:11:18] bemasc leaves the room
[22:11:31] evequefou leaves the room
[22:13:02] bemasc leaves the room
[22:13:35] hta leaves the room
[22:14:16] Warren Kumari leaves the room
[22:14:56] merm leaves the room: Disconnected: closed
[22:15:05] kaduk@jabber.org/barnowl leaves the room
[22:15:40] Pete Resnick leaves the room
[22:15:52] merm joins the room
[22:16:17] Ted.h leaves the room
[22:16:27] m&m leaves the room
[22:17:06] Ralf Weber leaves the room
[22:18:09] Greg Wood leaves the room
[22:18:12] merm leaves the room: Disconnected: closed
[22:18:17] Eric Kinnear leaves the room
[22:18:44] merm joins the room
[22:20:31] Kazunori Fujiwara leaves the room
[22:21:51] Eric Kinnear joins the room
[22:22:18] ChrisBox leaves the room
[22:23:40] Eric Kinnear leaves the room
[22:25:18] Samuel Weiler leaves the room
[22:26:54] stpeter leaves the room
[22:27:03] merm leaves the room: Disconnected: closed
[22:28:00] merm joins the room
[22:34:03] Eric Kinnear joins the room
[22:34:19] merm leaves the room: Disconnected: closed
[22:34:54] merm joins the room
[22:37:54] Eric Kinnear leaves the room
[22:40:43] Eric Kinnear joins the room
[22:41:13] Eric Kinnear leaves the room
[22:52:44] Dan Wing leaves the room
[22:55:18] Eric Kinnear joins the room
[22:59:41] Simon Leinen leaves the room: Connection failed: connection closed
[23:00:42] Eric Kinnear leaves the room
[23:01:52] Eric Kinnear joins the room
[23:02:34] Eric Kinnear leaves the room
[23:03:20] Eric Kinnear joins the room
[23:04:24] John Levine leaves the room
[23:04:28] John Levine joins the room
[23:10:21] nemo joins the room
[23:10:45] merm leaves the room: Disconnected: closed
[23:10:55] merm joins the room
[23:17:45] merm leaves the room: Disconnected: closed
[23:18:13] merm joins the room
[23:19:24] Ash leaves the room
[23:23:14] adam leaves the room
[23:23:46] stpeter joins the room
[23:24:02] stpeter leaves the room
[23:32:17] Tommy Jensen leaves the room
[23:33:03] nemo leaves the room
[23:35:24] Bernie Hoeneisen leaves the room
[23:40:24] Ash joins the room
[23:52:07] John Levine leaves the room
[23:54:28] Ash leaves the room