[01:09:43] Christian Huitema leaves the room: Disconnected: closed
[01:09:43] Christian Huitema joins the room
[01:12:36] Christian Huitema leaves the room: Disconnected: closed
[03:00:08] zulipbot joins the room
[04:40:44] Christian Huitema joins the room
[04:40:55] Christian Huitema leaves the room: offline
[07:31:28] navi joins the room
[07:52:58] navi leaves the room
[08:37:33] Meetecho joins the room
[08:50:03] Paolo Saviano joins the room
[08:50:03] Kazunori Fujiwara joins the room
[08:50:03] Lorenzo Miniero joins the room
[08:50:03] Alister Winfield joins the room
[08:50:03] Zaid AlBanna joins the room
[08:50:03] Scott Hollenbeck joins the room
[08:50:03] Éric Vyncke joins the room
[08:50:03] Puneet Sood joins the room
[08:50:03] Tim Wicinski joins the room
[08:50:03] Sara Dickinson joins the room
[08:50:03] Mark Andrews joins the room
[08:50:03] Pieter Lexis joins the room
[08:50:04] Peter van Dijk joins the room
[08:50:04] Peter Koch joins the room
[08:50:04] Vladimír Čunát joins the room
[08:50:04] Bernie Innocenti joins the room
[08:50:20] Sara Dickinson leaves the room
[08:50:24] Sara Dickinson joins the room
[08:50:50] Sara Dickinson leaves the room
[08:51:01] y1 joins the room
[08:51:10] Sara Dickinson joins the room
[08:51:28] Paolo Saviano leaves the room
[08:51:37] Brian Haberman joins the room
[08:52:01] Dan York joins the room
[08:53:09] Paul Hoffman joins the room
[08:53:36] andrew_campling joins the room
[08:53:38] Jonathan Hammell joins the room
[08:54:18] <Dan York> I'm in there now
[08:54:37] <Brian Haberman> Awesome. Thanks!
[08:54:42] Sara Dickinson leaves the room
[08:54:45] <Dan York> https://codimd.ietf.org/notes-ietf-109-dprive?both
[08:54:46] Sara Dickinson joins the room
[08:54:51] Peter Koch leaves the room
[08:54:54] Andrew Campling joins the room
[08:54:59] Peter Koch joins the room
[08:55:38] Jonathan Reed joins the room
[08:55:44] James Galvin joins the room
[08:55:57] Yuji Koyama joins the room
[08:56:03] João Damas joins the room
[08:56:09] Patrick Tarpey joins the room
[08:56:36] <Sara Dickinson> @chairs - I'd like to get sense of how many folks have read the latest XoT draft.... shall I just ask for +1s in the chat (I'm thinking that it doesn't warrant a show of hands)?
[08:56:41] Jim Reid joins the room
[08:56:55] dkg joins the room
[08:57:06] Yoshiro Yoneya joins the room
[08:57:10] Burt Kaliski joins the room
[08:57:10] Gustavo Lozano joins the room
[08:57:22] <Andrew Campling> Background music needed before start of session
[08:57:25] <Brian Haberman> @sara If you don't need a show of hands, +1 in the chat works
[08:57:33] Ray Bellis joins the room
[08:57:42] <Brian Haberman> @andrew feature request for the meetecho folks?
[08:57:45] <Sara Dickinson> thanks
[08:57:58] Nicklas Pousette joins the room
[08:58:04] Richard Wilhelm joins the room
[08:58:07] <Paul Hoffman> Early +1. It looks good.
[08:58:13] <Andrew Campling> @Brian Definitely
[08:58:20] <Tim Wicinski> Agree - new draft looks good.  
[08:58:21] <Meetecho> You don't want to hear MY music though :)
[08:58:24] Han Zhang joins the room
[08:58:25] Libor Peltan joins the room
[08:58:27] Robert Story joins the room
[08:58:39] Daniel Gillmor joins the room
[08:58:41] <Andrew Campling> Rage against the machine?
[08:58:47] Eric Orth joins the room
[08:58:47] Benjamin Schwartz joins the room
[08:58:48] <Sara Dickinson> @paul - thanks
[08:58:52] Alister Winfield leaves the room
[08:58:56] Alister Winfield joins the room
[08:58:58] <Brian Haberman> Bill Fenner and I used to pipe music through the sound system prior to sessions when we co-chaired IDMR.
[08:59:11] James Gruessing joins the room
[08:59:13] Andrew S joins the room
[08:59:14] Oshani Dayaratna joins the room
[08:59:15] Naveen Kumar joins the room
[08:59:16] Tero Kivinen joins the room
[08:59:17] Frode Sorensen joins the room
[08:59:43] <Meetecho> The music at the beginning is a good suggestion, though (would help identifying problems with audio sooner too), we'll take that into account. Thanks!
[08:59:50] Amreesh Phokeer joins the room
[08:59:55] Roy Arends joins the room
[08:59:56] Duane Wessels joins the room
[09:00:02] <Jim Reid> Maybe the co-chairs could entertain us with a song while we wait for the WG to start? :-)
[09:00:04] Willem Toorop joins the room
[09:00:08] James Gould joins the room
[09:00:11] <Éric Vyncke> @Sara chairs could also ask to use the raise hand tool
[09:00:17] David Lawrence joins the room
[09:00:19] <Andrew Campling> Do you do requests?
[09:00:27] Lars-Johan Liman joins the room
[09:00:32] <David Lawrence> last meeting in bangkok woohoo
[09:00:33] Christian Huitema joins the room
[09:00:35] Monika Ermert joins the room
[09:00:36] Richard Wilhelm leaves the room
[09:00:37] Geoff Huston joins the room
[09:00:47] Shivan Sahib joins the room
[09:00:48] <Paul Hoffman> For some weird value of "in"...
[09:00:57] Alexander Mayrhofer joins the room
[09:01:02] Joey Salazar joins the room
[09:01:07] Richard Wilhelm joins the room
[09:01:11] Chi-Jiun Su joins the room
[09:01:12] <Andrew Campling> At least we're not thinking about flight times
[09:01:16] Amreesh Phokeer leaves the room
[09:01:18] Tommy Jensen joins the room
[09:01:19] <Peter van Dijk> Meetecho, indeed! When I get to my desk for a meeting, I first have to turn on some music locally to see if my volume is set usefully. So some test sound (perhaps behind a button) would be neat. Perhaps as part of the preflight for mic/cam?
[09:01:59] Ralf Weber joins the room
[09:02:00] <Éric Vyncke> @Andrew but still jet lag...
[09:02:00] Benjamin Schwartz leaves the room
[09:02:13] Wes Hardaker joins the room
[09:02:14] <Andrew Campling> True
[09:02:43] Michael Gibbs joins the room
[09:02:44] Man Zhang joins the room
[09:02:53] Suzanne Woolf joins the room
[09:02:57] <Meetecho> Peter van Dijk: we have ways of injecting pre-recorded audio in the bridge, so it may be something chairs can turn on/off
[09:03:33] <Andrew Campling> @Meetecho that would be good
[09:03:42] Vittorio Bertola joins the room
[09:03:45] <Vladimír Čunát> Perhaps record what the person says and echo it back?  (to test the mic as well)
[09:03:59] Jari Arkko joins the room
[09:04:17] <Meetecho> Vladimír Čunát: we had that in the "old" selftest page we shipped for in-person meetings. Wondering if it may mae sense to bring it back to life too
[09:04:24] Tommy C joins the room
[09:04:27] <Éric Vyncke> Thank you in advance Tim !
[09:04:49] Amelia Andersdotter joins the room
[09:05:13] Benjamin Schwartz joins the room
[09:05:16] <dkg> i think the chair has to grant you screensharing privs
[09:05:24] <Éric Vyncke> I was about to say it ;-)
[09:05:33] Daniel Migault joins the room
[09:05:49] Benjamin Schwartz leaves the room
[09:05:54] Bron Gondwana joins the room
[09:06:16] <Paul Hoffman> +1 to having read it. Nothing scary enough to comment on
[09:06:55] mglt joins the room
[09:06:56] Marcel Parodi joins the room
[09:07:41] <mglt> +1 maybe not the latest version
[09:07:56] <Peter van Dijk> i liked -02 except for ALPN and ALPN is gone in -03 :)
[09:08:02] <Joey Salazar> +1 -03
[09:08:11] <Jonathan Reed> +1 to 03
[09:08:34] <Shivan Sahib> People *really* didn't like the ALPN...
[09:08:52] Roy Arends leaves the room
[09:09:02] <Joey Salazar> want to know what other options other than sni could there be
[09:09:04] <Paul Hoffman> Even the ALPN authors didn't like it much...
[09:09:08] <dkg> +1 to having read it as well
[09:09:11] wes joins the room
[09:09:24] <Peter van Dijk> Joey, in dprive I've been repeating that name servers have IPs, not names; so why SNI at all
[09:09:36] <Peter van Dijk> (there are arguments against that position, though!)
[09:09:58] Man Zhang leaves the room
[09:10:01] Man Zhang joins the room
[09:10:10] Man Zhang leaves the room
[09:10:17] <Peter van Dijk> SNI can simplify cert/key checks, of course
[09:10:18] Man Zhang joins the room
[09:11:06] <dkg> reponses "intermingled" means "potentially out of order", right?
[09:11:07] <Brian Haberman> +1 @Peter about DNS servers have IPs, not names
[09:11:12] <Joey Salazar> and it'd be good for promoting eSNI adoption me thinks
[09:11:28] <Joey Salazar> but that's a fair point ofc Peter
[09:11:41] <dkg> Peter, Brian: NS records point to names, not to IP addresses
[09:11:56] <dkg> why would you claim that the authoritative server does not have a name?
[09:12:04] <Peter van Dijk> yes, but in today's unencrypted DNS, the name server you connect to does not know what name you have for it
[09:12:04] Marco Davids joins the room
[09:12:11] <Vladimír Čunát> @dkg: even normal DNS over TCP allows answering out of order.
[09:12:15] <dkg> Peter, that' certainly true
[09:12:22] <Peter van Dijk> so there are risks to suddenly starting to do that in TLS
[09:12:25] Chris Box joins the room
[09:12:35] <Peter van Dijk> (also benefits)
[09:12:37] <dkg> Vladimír Čunát: we just need to make sure that servers and clients do it right :)
[09:12:50] <Paul Hoffman> Peter: mostly downsides, I think
[09:12:50] <Peter van Dijk> and, for XFR, you really want to configure your primaries by IP, not by name, for chicken and egg reasons
[09:13:02] <Peter van Dijk> Paul, I agree
[09:13:45] <dkg> i don't think it's all downsides.  you want authentication, and authentication anchors in a meaningful namespace makes more sense.
[09:14:41] <dkg> for XoT i'd say you want to configure your primaries by name (for authentication), and potentially include IP address in the configuration to avoid the chicken and egg concerns Peter calls out.
[09:14:56] <Peter van Dijk> in ADoT context, one big problem is that a resolver does not actually know the NS names of zone for sure when it has only talked to the parent
[09:14:56] <Paul Hoffman> I would want to see your list of why it "makes more sense" before I agree. Some of us have lists of why it doesn't for DNS auth servers.
[09:15:14] <Peter van Dijk> dkg, sure, IP for connecting, name for getting TLS right makes sense
[09:15:17] Frédéric Fieau joins the room
[09:15:21] <dkg> Paul Hoffman: because that's what the NS record maps to.
[09:15:29] <Shivan Sahib> The draft currently suggests strict privacy profile for TLS for client authenticating the server + IP based ACLs or mTLS
[09:15:39] <Shivan Sahib> https://tools.ietf.org/html/draft-ietf-dprive-xfr-over-tls-03#section-6.4
[09:17:22] <Peter van Dijk> Brian, 'github set up to echo back to the mailing list' - is that a thing? and what is that thing then?
[09:17:29] <Shivan Sahib> GitHub repo: https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls
[09:17:35] y1 joins the room
[09:17:48] <dkg> warning about "echoing to the list" -- an active github repo can be *really* chatty
[09:18:05] <Peter van Dijk> right, if you mean 'get notifications', that sounds risky
[09:18:14] Man Zhang leaves the room
[09:18:46] <dkg> Paul Hoffman: i'd love to hear your lists about why authoritative nameservers *shouldn't* be considered to have names.
[09:18:51] <Brian Haberman> Yes, I meant notifications... Still a bit early here. ;)
[09:19:01] <Libor Peltan> By the way, Knot DNS's "kdig" utility might be able to serve as a one-shot client to debug XoT. Anyone willing to try it out?
[09:19:14] <Paul Hoffman> I didn't say they didn't have names.
[09:19:30] <Willem Toorop> @libor excellent! Will try that right away
[09:19:45] <Paul Hoffman> They don't necessarily know their names. And the list of names can change minute to minute.
[09:20:02] Jay Daley joins the room
[09:20:09] <dkg> Paul Hoffman: tell me more about the minute-to-minute changes
[09:20:22] <dkg> i agree that a cleartext authoritative DNS server doesn't need to know its name
[09:20:48] <Paul Hoffman> Name servers for hosters can have tens of thousands names under management.
[09:20:48] <dkg> but perhaps if you set up an authoritative DNS server that can handle XoT, then maybe that's an additional piece of configuration you need
[09:21:14] <dkg> (or, you could probably autodetect new names and automate cert management for it these days)
[09:21:45] <dkg> Paul Hoffman: number of names under management ≠ number of names of the authoritative, right?
[09:22:03] <Paul Hoffman> =
[09:22:10] Benjamin Schwartz joins the room
[09:22:28] <dkg> we must have different definitions of "under management"
[09:22:33] <Paul Hoffman> And each might have a vanity name for the name server
[09:22:43] <Peter van Dijk> 'pretending' that name servers have names is a much bigger problem in 'ADoT' context than in 'XoT' context - zone transfers do tend to happen between consenting parties mostly
[09:22:59] <Tim Wicinski> Agree with Peter.
[09:23:25] <Sara Dickinson> @libor - already been using kdig to test XoT :-)
[09:23:43] <dkg> yes, "vanity" (often "in-bailiwick") names for the same name server are an issue for sure
[09:23:47] Michael Breuer joins the room
[09:23:49] <Bernie Innocenti> Are there significant performance advantages in using DoQ over DoH?
[09:24:07] <dkg> Bernie Innocenti: not much, i think
[09:24:14] <dkg> (but i have not profiled it)
[09:24:19] <Vladimír Čunát> DoT vs. DoH/2 is like DoQ vs DoH/3
[09:25:04] Tommy C leaves the room
[09:25:23] <Bernie Innocenti> I've been uninterested because I expected h3 to be low overhead, amortized over several queries
[09:26:46] y1 leaves the room
[09:27:40] <Sara Dickinson> Adopted draft https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/
[09:28:09] <Paul Hoffman> dkg is under water...
[09:28:23] <Andrew Campling> Local mute?
[09:28:23] <Peter van Dijk> or at least his microphone is :)
[09:28:26] Alister Winfield leaves the room
[09:28:30] Alister Winfield joins the room
[09:28:50] <Joey Salazar> I don't hear dkg at all, not even underwater
[09:28:54] <Tommy Jensen> +1 to Bernie and Ben
[09:28:59] <Shivan Sahib> don't hear dkg
[09:29:17] <James Gruessing> @Ben Schwartz you said you have numbers on DoH/3, are those public somewhere?
[09:29:18] <Tim Wicinski> yea dkg
[09:30:12] Duane Wessels leaves the room
[09:30:38] Jonathan Reed leaves the room
[09:30:43] Jonathan Reed joins the room
[09:30:44] Jonathan Reed leaves the room
[09:30:49] Jonathan Reed joins the room
[09:30:55] <Vladimír Čunát> I also feel DoQ will be more relevant for auth case, but there we're right now dealing mainly with questions that don't really change whether we use DoT or DoQ.
[09:31:10] Duane Wessels joins the room
[09:31:28] <Peter van Dijk> yes - although protocol flexibility differs between the proposals and ideas that we have
[09:31:36] <Paul Hoffman> +1 to Vladimir
[09:34:37] <Chris Box> Benchmarking data (even any) would help guide people to know whether to deploy support for DoH3, DoQ or both.
[09:34:57] <Bernie Innocenti> the benchmark i would like to see is amortized bandwidth used per query
[09:34:59] <dkg> +1 to Christian
[09:35:29] <Vladimír Čunát> Our DoH vs. DoT implementation experience (Knot Resolver) is that the HTTP layer is a painful addition.
[09:35:30] <dkg> stuffing HTTP into recursive-to-authoritative queries seems like a mistake
[09:35:44] <Peter van Dijk> +100 dkg
[09:36:05] <Bernie Innocenti> mobile users pay for bandwidth and DoT is quite expensive
[09:36:37] <Pieter Lexis> HTTP adds a lot, like complexity no-one needs :)
[09:36:43] <Chris Box> @Bernie they are also looking for speed, and DoQ looks good on this front.
[09:36:48] <mglt> +1 for not having http
[09:37:48] <Paul Hoffman> 4 transports: DNS-over-DTLS
[09:37:52] <Andrew Campling> @Chris I'm assuming leaving out HTTP helps in terms of speed too?
[09:37:57] <Chris Box> yes
[09:38:06] <James Gruessing> @paul I've been told repeatedly by people nobody cares about DoDTLS
[09:38:09] <Tim Wicinski> +1 for more dkg
[09:38:34] <Paul Hoffman> James: that's exactly my point. :-)
[09:38:51] Han Zhang leaves the room
[09:38:56] <Vladimír Čunát> DTLS generally feels dead
[09:40:36] Benjamin Kaduk joins the room
[09:41:15] Geoff Huston leaves the room
[09:41:23] <Paul Hoffman> Ben: Fair point!
[09:41:31] <Peter van Dijk> nextdns is an excellent example, - SNI can go part of that way, of course
[09:41:41] <Andrew Campling> @Ben - user tracking on DNS?
[09:42:10] Man Zhang joins the room
[09:42:16] Man Zhang leaves the room
[09:42:18] <Peter van Dijk> Andrew, browse to https://my.nextdns.io/start and see
[09:42:19] Man Zhang joins the room
[09:42:22] kaduk@jabber.org/barnowl joins the room
[09:42:24] <Pieter Lexis> for stub -&gt; res HTTP(2,3) would be fine right? For rec-&gt;auth and auth-&gt;auth HTTP feels too heavyhanded
[09:42:49] <Peter van Dijk> Ben's argument does not extend to anything involving auths, I'd say
[09:43:15] <Pieter Lexis> it would need a mention of course
[09:43:16] <Peter van Dijk> but also, unbound can currently fetch zones via HTTP, and I see how people might prefer to use their HTTP CDN.. maybe
[09:43:48] <Pieter Lexis> fetching zones over HTTP is catagorically an XFR, but I don't see that as a DNS XFR
[09:44:01] <Andrew Campling> @Peter I know, just not sure it's wise to embed tracking into DNS as being a good idea
[09:44:10] Patrick Tarpey leaves the room
[09:44:12] Patrick Tarpey joins the room
[09:44:30] <Chris Box> Yes stub-&gt;res can be well served by DoH{2,3} but the point is that DoQ would introduce lower overhead, lower code risk, and better scalability so it feels like DoQ should be even better.
[09:45:42] Daniel Migault leaves the room
[09:46:06] Benjamin Kaduk leaves the room
[09:46:08] mglt leaves the room
[09:48:52] zyxbac joins the room
[09:49:52] <Paul Hoffman> Agree with Dan about the four categories
[09:50:02] <Shivan Sahib> DSTS
[09:50:03] <Peter van Dijk> yes, makes sense, I'm unsure it's only four, but this is a good start
[09:52:20] João Damas leaves the room
[09:52:55] <dkg> i think you're overcomplicating it, Ben!
[09:53:00] katerega micheal joins the room
[09:53:26] Jari Arkko leaves the room
[09:53:27] <Bernie Innocenti> where do you find a quic library that doesn't also come with h3?
[09:53:28] <dkg> if we've defined a signaled strict mode, then it's just a question of whether the recursor is willing to implement it or not
[09:53:41] <Sara Dickinson> +1 to dkg
[09:53:54] <Bernie Innocenti> and is it true that the h3 part is the majority of the complexity?
[09:54:05] kaduk@jabber.org/barnowl leaves the room
[09:54:12] <Sara Dickinson> I think auths that *ONLY* do secure transports are a long way off....
[09:54:37] <Paul Hoffman> Sara: that's not the way that Ekr and PaulW were talking on the list.
[09:54:39] <dkg> i'll try to make sure it's in the minutes
[09:54:42] <Sara Dickinson> so recursives will always have an option to fallback if they choose
[09:55:15] <Sara Dickinson> I know - hence my questions as to does the WG really think that is the end goal with no intermediate step
[09:55:21] <Dan York> DKG - I tried to capture the points in https://codimd.ietf.org/notes-ietf-109-dprive?both - feel free to add more
[09:55:26] <Benjamin Schwartz> @Sara Maybe ... some proposals have a flag in the zone to indicate whether that fallback is allowed
[09:55:44] katerega micheal leaves the room
[09:55:47] <Vladimír Čunát> yes
[09:55:50] katerega micheal joins the room
[09:56:01] <Paul Hoffman> Ben: nope. The server can't demand how the resolver acts.
[09:56:04] <Peter van Dijk> 'auths that do not have insecure transports' is not an end goal I can imagine - but 'zones that demand secure transports from those resolvers that support it' makes sense to me
[09:56:05] <Sara Dickinson> indeed but no auth can force a recursive to honor, apart from not answering over clear text
[09:56:14] <Peter van Dijk> Sara, of course
[09:56:31] <Peter van Dijk> so it's different than HSTS in browsers
[09:56:41] <Peter van Dijk> because that tends to come with 'this content is not even available over plain HTTP'
[09:56:43] Alissa Cooper joins the room
[09:56:44] <Sara Dickinson> ack
[09:56:53] <Vladimír Čunát> Peter +1
[09:57:07] <Peter van Dijk> but we can still write down 'this signal tells a resolver to never do plain text with this auth'
[09:57:19] <Peter van Dijk> and then two weeks later the users will demand a configuration flag for that :)
[09:57:21] <dkg> Dan York: thanks for that
[09:58:02] <dkg> Sara Dickinson: a network-based attacker can always set up a cleartext/unsecured responder for a given authoritative :)
[09:58:08] <zulipbot> [zulip] <Ralf Weber> Yes and what if getting to this domain requires insecure connection up the chain or sideways into NS names
[09:58:09] <dkg> sorry for leaving myself in the queue!
[09:58:25] <Alister Winfield> and a little later blackhats will try to find ways to use the flag to deny services.
[09:58:37] Monika Ermert leaves the room
[09:58:55] <Andrew Campling> @Alister - probably not that much later ....
[09:59:02] Monika Ermert joins the room
[09:59:39] Jay Daley leaves the room
[10:00:13] <Benjamin Schwartz> https://tools.ietf.org/html/draft-schwartz-svcb-dns-01
[10:00:21] <Tim Wicinski> thanks ben!
[10:00:42] Lorenzo Colitti joins the room
[10:02:24] Jonathan Reed leaves the room
[10:02:34] <Éric Vyncke> So, chairs and AD for ADD/DPRIVE and possible DNSOP should have another meeting ;-)
[10:02:35] <Peter Koch> on req 7: instead of saying which entity should be able to specify (the 'owner' or 'holder' is more a registry side concept) it might make sense to make this a property of either the zone or the authoritative server (likely the former)
[10:02:35] Vladimír Čunát leaves the room
[10:02:46] Vladimír Čunát joins the room
[10:03:16] <Peter van Dijk> yes - if you make it an auth property, you get some interesting situations when a zone is hosted with two operators
[10:03:17] <Paul Hoffman> +1 to DKG with "strong preference"
[10:03:41] <Peter van Dijk> ah yes i like dkg's turned-around version of this - 'i promise the secure transport works'
[10:04:06] <Vladimír Čunát> me too
[10:04:17] <Peter van Dijk> Peter Koch, oh now I see what you're saying - yes, it's a zone or auth property, not a owner/admin property
[10:04:18] <Paul Hoffman> Agree
[10:04:40] Michael Gibbs leaves the room
[10:04:41] Alissa Cooper leaves the room
[10:05:01] <Peter Koch> also, the difference zone vs domain is important
[10:05:31] <Paul Hoffman> No, Tim!
[10:05:46] <Paul Hoffman> Thank you, Dan.
[10:06:27] Frode Sorensen leaves the room
[10:06:36] <Tim Wicinski> Thanks dkg
[10:06:37] <Peter Koch> actually, there might be different 'use cases' for either making it a per zone or a per auth server property (say, the auth server 'knows' there's a forerign passive DNS probe nearby ...
[10:07:07] <Peter van Dijk> right - but the auth signal would never be stronger than 'offered' and the zone signal could go as far as 'preferred' or 'you are allowed to fail if you cannot go secure', i'd say
[10:07:47] Mark Andrews leaves the room
[10:09:13] Mark Andrews joins the room
[10:10:23] katerega micheal leaves the room
[10:10:32] katerega micheal joins the room
[10:12:08] <Peter Koch> well, Tim, zone vs server is a fundamental difference, not one of practicality
[10:12:32] <Benjamin Schwartz> (I think nameserver name is the logical scope.)
[10:12:46] <dkg> Benjamin Schwartz: that's the one that Tim says isn't correct :)
[10:12:57] <Benjamin Schwartz> I know.  We're not gonna figure this out now.
[10:13:14] <Tim Wicinski> yes ! i'm reading too many windows and getting things sideways
[10:13:56] <Brian Haberman> From my perspective, we haven't decided on auth by server or zone.
[10:14:06] <Brian Haberman> That's why we are having this session.
[10:14:13] <dkg> the more we discuss this, the more i'm thinking i just want to think about two options:   opportunistic by probing, and signalled strict mode
[10:14:43] <dkg> that means as long as we aren't talking about strict mode, we don't have to decide scope of signalling
[10:15:23] <Ray Bellis> probing needs to allow for firewalled ports that will just timeout a TCP connection (eventually) instead of sending an immediate RST.
[10:15:31] <Paul Hoffman> Opportunistic means "try to authenticate but don't fail communication if not". So it can get value from some of the authentication information.
[10:15:33] <Peter Koch> the MAY in req9 is misplaced IMHO; teh real requirement behind it is that the support be per zone; also 'support' is different from 'mandate'
[10:15:39] <Peter van Dijk> ^ what Ray said, which means I hate -that- form of probing
[10:15:47] <dkg> Ray Bellis: yeah, probing guidance is tricky, and i hate it too
[10:15:57] <dkg> nonetheless, i think it's the way to go :P
[10:16:12] <Ray Bellis> to avoid timeouts you'd need to send a Do53 query too (for first query) but that then leaks information...
[10:16:14] <Peter van Dijk> probing would, easily, be the quickest path to some substantial DoT usage
[10:16:23] <Dan York> @Alex - thank you for typing yourfeedback in the notes
[10:16:36] Bron Gondwana leaves the room
[10:16:40] <dkg> Ray Bellis: sure, but maybe you could adjust your probing after a successful connection goes through?
[10:16:44] <dkg> "leak the first query"
[10:16:50] <Peter van Dijk> i think Paul Hoffman's draft, and also something dkg said on-list I think, point to 'transport caches should live for days, not minutes' and then probing becomes more interesting - for busy domains
[10:17:10] <Peter van Dijk> whether we accept 'leaking the first query' makes a -lot- of difference in how valid various proposals are
[10:17:30] <Ray Bellis> I don't like per-zone signalling - IMHO it should be per server, and stored alongside the PTR record of the server's IP in the in-addr.arpa and ip6.arpa zones.
[10:18:01] <Ray Bellis> there's no feasible server mechanism where you'd have DoT support for some zones but not others in the same server.
[10:18:01] <Peter Koch> all servers 'MUST' behave the same way is not really actionable, also it is operational rather than aiming at the implementation
[10:18:12] <Peter van Dijk> PTR has the neat benefit of avoiding relying on, or leaking of, the NS name
[10:18:27] <Brian Haberman> @Peter agreed
[10:18:40] <Peter van Dijk> Peter Koch, in DOTPIN I took the variant of 'if you signal this, and some of your auths do not have DoT, then understand that a resolver will not use those auths'
[10:19:14] <Ray Bellis> @dkg I did indeed mean "just the first query"
[10:19:18] <Jim Reid> @PvD +1
[10:19:32] <Ray Bellis> or at least as many as it takes for the initial DoT probe to fail.
[10:19:34] <Vladimír Čunát> @Ray: yes for DoT support, but the "mandated DoT" does make sense to be per zone.
[10:20:11] <Vladimír Čunát> In particular you don't want to couple that for all zones that are being served by some servers.
[10:20:22] <Vladimír Čunát> (I think)
[10:21:10] katerega micheal leaves the room
[10:21:21] <dkg> of course you try to authenticate!  but if you're not going to fail if it fails, then you should also go ahead an query in the clear at the same time if you know nothing about it
[10:21:35] katerega micheal joins the room
[10:21:37] <Benjamin Schwartz> We can't even try to authenticate until we know what the reference identity is.
[10:21:45] <dkg> it doesn't have to be something that people do long term -- we are designing strategies for deployment, not jumping straight to end-game
[10:22:07] <dkg> for *incremental* deployment
[10:22:22] katerega micheal leaves the room
[10:22:28] katerega micheal joins the room
[10:22:50] <Peter Koch> indeed, chains of 'fortwarders' still exist, so demanding properties for the 'first mile' only is making a promise that can't be hold
[10:23:09] <Ray Bellis> forwarders in the recursor -&gt; auth path?
[10:23:12] <dkg> why *wouldn't* a resolver want to probe by port numbers?
[10:23:24] Monika Ermert leaves the room
[10:23:27] <Peter van Dijk> dkg, because resolvers already have plenty of work to do, and the users are waiting
[10:23:28] Monika Ermert joins the room
[10:23:37] <dkg> Peter van Dijk: ok, do it best effort then
[10:23:40] <Peter van Dijk> (the latter argument goes away if we just accept that the first few queries are always plain text)
[10:23:41] <Brian Haberman> @ray I have the same question
[10:23:53] <dkg> lowest possible priority, and yeah, accept that the first few queries are leaked
[10:23:56] <Éric Vyncke> Can probe all ports at the same time ? A la 'happy eyeball'
[10:24:05] <dkg> seems like a win
[10:24:05] <Ray Bellis> @BH I was questioning whether such things exist.
[10:24:10] <dkg> Éric Vyncke: yep
[10:24:19] <Peter van Dijk> i think happy eyeballs are a terrible idea at every point where i've seen them
[10:24:19] <Brian Haberman> @ray As am I
[10:24:30] <Peter van Dijk> "let's create double the TCP state on the server and then immediately throw one half away"
[10:24:35] <dkg> Peter van Dijk: they are, and users love them :)
[10:25:21] <dkg> +1 to Ben's suggestion of a narrowly-scoped draft that describes the mechanical guidance for opportunistic-by-probing
[10:25:22] <Éric Vyncke> @pvD indeed but this is how browsers do anyway
[10:25:37] <Peter van Dijk> well that's fine, i don't run browsers or webservers :)
[10:25:42] <Éric Vyncke> ;-)
[10:25:44] <Peter van Dijk> browsers have cpu to spare
[10:25:49] <Peter van Dijk> resolvers often do not really
[10:25:50] Marcel Parodi leaves the room
[10:25:56] Marcel Parodi joins the room
[10:25:57] <Paul Hoffman> I can do that, but I will also assume that something better MAY also be availble.
[10:25:59] <Éric Vyncke> fiar
[10:26:07] <Éric Vyncke> s/fiar/fair comment/
[10:26:20] <dkg> Paul Hoffman: for sure, something better will be there -- but we can move forward with the something better in parallel
[10:26:27] <Paul Hoffman> Yep
[10:26:58] <Peter Koch> @Ray: not between the (final recursor) -&gt; auth, but between user and that recursor.  If the zone's property was 'must only be conveyed over encrypted channel, then the signalling would have to be transitive.  Maybe too much to ask for, given that it's all hop by hop
[10:27:06] <Ray Bellis> forgive if already discussed - how do you securely bootstrap a requirement for mandatory DoT if the information about that requirement is _in the zone_ ?
[10:27:17] <Peter van Dijk> Ray, you don't
[10:27:23] <dkg> the nice thing about opportunisticy-by-probing means that servers can deploy without coordination or signalling, and clients can deploy without needing to care about signalling.
[10:27:36] <Peter van Dijk> Ray, that's why DOTPIN goes in DS
[10:27:44] <Ray Bellis> cK
[10:27:46] <Ray Bellis> ack
[10:27:55] <Peter van Dijk> dkg, absolutely
[10:28:19] <dkg> note that "per-server" signalling might mean "per-name" or "per-IP"
[10:28:28] <dkg> there is not consensus in the group about that
[10:28:37] <Peter van Dijk> i don't think we can get consensus on that
[10:28:41] <Ray Bellis> I'd go for "per-IP"
[10:28:43] <Peter van Dijk> different proposals might pan out in different ways there
[10:29:06] <Ray Bellis> servers are reached by name, but the _transport_ is done by IP
[10:29:08] <Peter Koch> @dkg or both, servers may have multiple names, (hopefully) have multiple addresses and sometime both in combination
[10:29:20] <dkg> Peter Koch: agreed
[10:29:28] <Alexander Mayrhofer> now, a server name can have lots of IPs.. and each IP might be used for various servers... *headexplode*
[10:29:37] <Christian Huitema> Isn't this server/zone debate precisely the reason for opportunistic? A zone cannot be strict unless all servers can, but a server could opportunistically serve many zones.
[10:29:47] <dkg> i mean, we can define lots of different signalling mechanisms that overlap.  but it sounds kinda bananas to actually do it
[10:29:53] <Peter van Dijk> a zone can be strict if just -some- of the servers can
[10:30:17] <Vladimír Čunát> Could be, but that would complicate the situation.
[10:30:40] <Peter van Dijk> 'incremental strict deployment' is a bit iffy, kyes
[10:30:42] <Peter van Dijk> -k
[10:30:44] <Peter Koch> I cannot imagine anything but an incremental deployment
[10:30:49] <Christian Huitema> If a zone is strict, what is the point of advertising servers that cannot authenticate?
[10:30:50] katerega micheal leaves the room
[10:30:57] katerega micheal joins the room
[10:31:05] <Peter van Dijk> no point, I'd say
[10:31:05] <dkg> Christian Huitema: a mistake, or a delayed cache
[10:31:12] <Peter van Dijk> but DOTPIN has some words to -allow- the situation
[10:31:22] <dkg> just saying we need to handle that scenario
[10:31:27] <Peter van Dijk> to the effect of 'if you do not do TLS, then at least fail fast on port 853'
[10:31:44] <Ray Bellis> IMHO - put per-server flag (for non-opportunistic use) in .arpa and put per-zone "mandatory use" flag somewhere else.   Don't use server names.
[10:32:06] <Ray Bellis> Mwoah DNSSEC :)
[10:32:34] Bernie Innocenti leaves the room
[10:32:39] <Peter Koch> how do you resolve the 'arpa' names, signalling pending (circular dependency)
[10:33:27] <Sara Dickinson> @PvD - yeah, that's the catch
[10:33:43] <Peter van Dijk> the beauty of arpa is that the lookups there don't leak anything interesting
[10:34:07] Bernie Innocenti joins the room
[10:34:33] tim costello joins the room
[10:34:45] <Peter Koch> @PvD except dislosing, amongst others, some IP addresses, which may be funny especially with IPv6
[10:34:46] <Peter van Dijk> so i don't see a circular problem, but i do see a problem with suddenly expecting the world to have useful PTRs, or even PTRs that don't timeout
[10:35:09] <Peter van Dijk> PK, yes, but you're about to disclose those anyway when you open your TLS connection to finally ask the question you are here for
[10:35:13] <Peter Koch> and yes, availability of reverse mapping for name servers is sub optimal
[10:35:22] <Peter van Dijk> ^ that
[10:35:41] <Ray Bellis> NB: not PTRs, but some other record in the reverse zones
[10:35:53] <dkg> i ♥ that everyone wants to figure out the signalling mechanism but no one is volunteering to do the grunt work of specifying guidance for how to do opportunistic-by-probing :)
[10:35:58] <Peter van Dijk> Ray, of course! doesn't change the problem
[10:36:08] <Peter Koch> @PvD that's the same argument we heard against DNS encryption, because subsequent action would disclose the target anyway
[10:36:42] <dkg> figuring out signalling is definitely a more fun intellectual puzzle
[10:36:46] <Peter van Dijk> @PK I agree in general "we can leak it here because we leak it there" is a bad argument but in this case I'm not sure it really applies
[10:37:14] <Peter van Dijk> dkg, we haven't really seen a lot of -actually worked out- signal proposals either, though - most of the ideas are badly specified between 3 threads on the list
[10:37:29] <dkg> Peter van Dijk: heh, true
[10:37:50] <Peter van Dijk> 'just use TLSA' is a collection of ideas some of which might or m ight not fit together in a coherent solution
[10:38:08] <Paul Hoffman> Orthogonal ten-foot poles
[10:38:13] <Peter van Dijk> (I might write a draft or two to make some of those coherent - if only to see what's there and what's not)
[10:38:18] <Peter Koch> any signalling is going to make deployment much harder, so who's the primary beneficiary?
[10:38:44] <Peter van Dijk> PK, I believe signalling makes deployment much easier
[10:39:17] <Peter van Dijk> but, that's in a vacuum
[10:39:25] <Peter van Dijk> because it avoids probing
[10:40:15] <dkg> Peter van Dijk: you still need to elicit the signal
[10:40:56] <Peter van Dijk> yes - but in some of the proposals (like DOTPIN, but I'm really not trying to toot my own horn here), it comes for free with the delegation response
[10:40:58] <Peter Koch> initially, there will be very little signal, so how to achieve a critcal mass in deployment?
[10:41:19] <dkg> Peter van Dijk: by opportunistically probing :)
[10:41:29] <Peter van Dijk> that depends - if you can get cloudflare and godaddy to signal, you suddenly have a decent chunk
[10:41:32] <Peter Koch> we do need data regarding numbers of authe per rec and vice versa
[10:41:41] <dkg> sorry, that was for Peter Koch
[10:41:49] <Paul Hoffman> Two or three, please.
[10:41:49] <Peter van Dijk> thanks, makes more sense :D
[10:42:58] <Peter Koch> req2 a 'MUST' as in 'MUST be able' is not actionable because it does not address the right party
[10:43:20] <dkg> we can move forward with opportunistic-by-probing without answering any of the hard questions about signalling that we don't have consensus on
[10:43:28] Chi-Jiun Su leaves the room
[10:43:33] Chi-Jiun Su joins the room
[10:43:43] <Peter van Dijk> dkg, i agree - on the condition that we also accept 'first query leaks' so the probing can get out of the hot path
[10:43:47] <Tim Wicinski> yes dkg
[10:43:52] <dkg> Peter van Dijk: agreed
[10:44:09] <Peter Koch> the signalling would not address the resolution path, only that path's final hop
[10:44:25] <Alexander Mayrhofer> +1 on "strict is a per-zone requirement"
[10:44:39] katerega micheal leaves the room
[10:45:25] <Alexander Mayrhofer> similar to HSTS
[10:45:50] Chi-Jiun Su leaves the room
[10:45:58] katerega micheal joins the room
[10:46:23] Chi-Jiun Su joins the room
[10:46:46] <dkg> can we have both? per-zone and per-server, and as long as either signal is present we enforce?
[10:46:59] <Ray Bellis> please, no.   That gets you requirement 9.
[10:47:00] <dkg> they're remarkably different semantics
[10:47:04] <Peter Koch> per-zone and per-server are orthogonal
[10:47:08] <Tim Wicinski> Let's start with per-zone perhaps ?
[10:47:28] <dkg> Ray Bellis: i don't think requirement 9 says anything about strict
[10:47:31] katerega micheal leaves the room
[10:47:35] <dkg> i'm thinking just about signalling for strictness
[10:47:36] katerega micheal joins the room
[10:47:43] <Peter van Dijk> requirement 9 is problematic because it allows something that makes no sense
[10:48:08] <Brian Haberman> @PvD : I think a fair number of people think Req 9 needs to go away
[10:48:16] <Peter van Dijk> definitely, me among them
[10:48:19] <Ray Bellis> yes, it does
[10:48:26] <dkg> req 9 doesn't make sense to me either
[10:49:11] <Libor Peltan> what if you operate hundreds of NS around the globe, and some aren'T capable of TLS, whereas others might be available for resolvers who wish some privacy ??
[10:49:12] <Ray Bellis> @dkg it's unclear that we need a "strictness" flag for servers at all.
[10:49:16] <Peter Koch> per-server may increase recursor efficieny, but it is very expensive
[10:49:32] <Ray Bellis> strictness is policy, not capability
[10:49:38] <dkg> Ray Bellis: the nice thing about strictness-by-server  is how easy it is to deploy
[10:49:40] <Peter van Dijk> Libor the approach in the DOTPIN draft works for that - at the cost of redundancy
[10:49:55] katerega micheal leaves the room
[10:49:56] Oshani Dayaratna leaves the room
[10:49:59] <Ray Bellis> per-server flags advertise capability, per zone-flags indicate policy
[10:50:07] <Peter Koch> also, there's more between n recursor and an authoritative than an 'attack' (think of port blocking)
[10:50:21] <Vladimír Čunát> @Libor: or you always do unauthenticated TLS in such scenarios
[10:50:25] <dkg> "a.ns.example.net will always have secure transport available, and you should treat lack of it as an attack" is easy for the operator of a.ns.example.net to assert
[10:50:32] katerega micheal joins the room
[10:50:34] <Peter Koch> well summarized, Ray
[10:50:44] <Peter van Dijk> +1 Ray yes
[10:50:53] <Vladimír Čunát> +1 Ray
[10:51:19] katerega micheal leaves the room
[10:51:20] <Peter Koch> @dkg and the absense of that signal would have what consequence? going plain instead of trying encrypted?
[10:51:23] <Puneet Sood> +1 Ray says what I was thinking
[10:51:42] <dkg> the absence of the signal would mean the recursor just falls back to opportunistic-by-probing
[10:51:42] <Peter Koch> i.e. the way @dkg specified it, it's again policy rather than capability
[10:52:01] Suzanne Woolf leaves the room
[10:52:43] <Puneet Sood> @Peter Koch: per-server may increase recursor efficieny, but it is very expensive
It would be expensive compared to what?
[10:53:28] <Paul Hoffman> Well, some of us should not write code...
[10:53:31] <Peter Koch> so we have two spolicy and one capability signalling, where the latter is inherently hop-by-hop,
[10:53:56] <dkg> spolicy?
[10:53:58] <Peter Koch> @Puneet incremental deployment
[10:54:22] <Peter Koch> s/spolicy/policy/
[10:55:14] <dkg> +1 to sara
[10:55:20] <Tim Wicinski> "per-server flags advertise capability, per zone-flags indicate policy". thanks  Ray
[10:55:41] <Dan York> Please feel free to update anything captured in the notes: https://codimd.ietf.org/notes-ietf-109-dprive?both
[10:55:54] <Ray Bellis> you're welcome!
[10:55:58] <Benjamin Schwartz> I still think it doesn't make sense for zones to have an opinion on the policy question
[10:55:59] Wes Hardaker leaves the room
[10:56:01] <Paul Hoffman> Sara: same on the resolver side. Some resolver ops would be happy to not have passive observers "enumerate" what their clients are doing.
[10:56:14] James Gruessing leaves the room
[10:56:22] <Sara Dickinson> @PH +1
[10:57:30] <Peter Koch> a server incapable of encryption would have to understand the zone signal 'encryption only' to avoid sending data unencrypted; hard to imagine that being implemented reliably
[10:57:53] <Éric Vyncke> Thank you all (+ chairs). Now, let's all relax and re-adjust to local TZ
[10:57:55] <dkg> thanks all
[10:57:55] Patrick Tarpey leaves the room
[10:57:56] Pieter Lexis leaves the room
[10:57:56] Eric Orth leaves the room
[10:57:57] Burt Kaliski leaves the room
[10:57:57] tim costello leaves the room
[10:57:58] Ralf Weber leaves the room
[10:57:59] Mark Andrews leaves the room
[10:57:59] Alexander Mayrhofer leaves the room
[10:58:00] Tommy Jensen leaves the room
[10:58:00] Jonathan Hammell leaves the room
[10:58:00] Andrew S leaves the room
[10:58:01] Vittorio Bertola leaves the room
[10:58:01] <Vladimír Čunát> @PH: say, resolvers might choose to be stricter for queries that came to them over an encrypted transport.
[10:58:02] Andrew Campling leaves the room
[10:58:02] Nicklas Pousette leaves the room
[10:58:02] Yoshiro Yoneya leaves the room
[10:58:02] Alister Winfield leaves the room
[10:58:03] David Lawrence leaves the room
[10:58:04] Chris Box leaves the room
[10:58:05] Joey Salazar leaves the room
[10:58:06] Robert Story leaves the room
[10:58:06] andrew_campling leaves the room
[10:58:07] <Paul Hoffman> Thanks, y'all! This was surprisingly good.
[10:58:07] Scott Hollenbeck leaves the room
[10:58:07] Puneet Sood leaves the room
[10:58:08] Kazunori Fujiwara leaves the room
[10:58:11] Brian Haberman leaves the room
[10:58:12] Jim Reid leaves the room
[10:58:13] Éric Vyncke leaves the room
[10:58:13] Duane Wessels leaves the room
[10:58:14] Richard Wilhelm leaves the room
[10:58:15] <Peter van Dijk> this was very good
[10:58:15] Benjamin Schwartz leaves the room
[10:58:15] James Gould leaves the room
[10:58:17] Ray Bellis leaves the room
[10:58:19] James Galvin leaves the room
[10:58:20] <Tim Wicinski> once I shut up things got better.  I have been up too long
[10:58:20] Dan York leaves the room
[10:58:22] Marcel Parodi leaves the room
[10:58:26] Naveen Kumar leaves the room
[10:58:32] Paul Hoffman leaves the room
[10:58:38] Sara Dickinson leaves the room
[10:58:41] Libor Peltan leaves the room
[10:58:41] Meetecho leaves the room
[10:58:44] Peter Koch leaves the room
[10:58:46] Tim Wicinski leaves the room
[10:58:46] Lars-Johan Liman leaves the room
[10:58:50] Zaid AlBanna leaves the room
[10:59:00] Lorenzo Colitti leaves the room
[10:59:00] Chi-Jiun Su leaves the room
[10:59:00] Bernie Innocenti leaves the room
[10:59:00] Shivan Sahib leaves the room
[10:59:00] Daniel Gillmor leaves the room
[10:59:00] Vladimír Čunát leaves the room
[10:59:00] Amelia Andersdotter leaves the room
[10:59:00] Christian Huitema leaves the room
[10:59:00] Tero Kivinen leaves the room
[10:59:00] Frédéric Fieau leaves the room
[10:59:00] Michael Breuer leaves the room
[10:59:00] Gustavo Lozano leaves the room
[10:59:01] Man Zhang leaves the room
[10:59:01] Lorenzo Miniero leaves the room
[10:59:01] Willem Toorop leaves the room
[10:59:01] Peter van Dijk leaves the room
[10:59:01] Yuji Koyama leaves the room
[10:59:01] Monika Ermert leaves the room
[10:59:01] Marco Davids leaves the room
[10:59:20] y1 leaves the room
[11:11:49] dkg leaves the room
[11:14:11] wes leaves the room: Disconnected: No route to host
[17:21:36] hardaker joins the room
[19:52:48] mglt joins the room
[20:47:36] mglt leaves the room