[12:30:48] <neednnelg@sure.im> —  ADD Interim Sept 10 2020
[12:30:48] Christian Huitema leaves the room
[12:50:31] Barbara Stark-jabber joins the room
[12:51:37] tale joins the room
[12:52:26] tale has set the subject to: https://codimd.ietf.org/notes-ietf-interim-2020-add-01-add
[12:53:57] ChrisBox joins the room
[12:54:13] mglt joins the room
[12:55:36] Barry Leiba joins the room
[12:57:45] andrew_campling joins the room
[13:00:40] sftcd joins the room
[13:01:23] bemasc joins the room
[13:01:39] marka joins the room
[13:01:45] Mike Bishop joins the room
[13:02:09] Mirja joins the room
[13:02:11] Ralf Weber joins the room
[13:03:08] Vittorio Bertola joins the room
[13:03:47] ChrisBox leaves the room
[13:04:46] ChrisBox joins the room
[13:05:13] Tommy Pauly joins the room
[13:05:16] <andrew_campling> Jabber doesn't seem to be a popular choice today
[13:05:20] Valery Smyslov joins the room
[13:05:24] <tale > Ja, noted
[13:07:08] Paul Hoffman joins the room
[13:07:33] <andrew_campling> If the Jabber scribe's role is to call out comments needing to be raised on the mic then I can do that.  If it's something else I can do that too if someone can let me know
[13:07:45] <tale > That's it, so thank you.
[13:07:45] Dan Wing joins the room
[13:07:50] ekr@jabber.org joins the room
[13:07:57] Martin Thomson joins the room
[13:08:09] <tale > Kind of minimal in all-virtual sessions like this.
[13:08:31] jdub99@sure.im joins the room
[13:09:01] <ekr@jabber.org> Where is the blue sheet>
[13:09:18] <Martin Thomson> I don't think that I can type and participate given that half the issues are mine
[13:09:18] <tale > In the Codi
[13:09:23] <Martin Thomson> I can help, but not commit
[13:09:47] <Mirja> https://codimd.ietf.org/notes-ietf-interim-2020-add-01-add
[13:09:55] <andrew_campling> https://codimd.ietf.org/notes-ietf-interim-2020-add-01-add?edit
[13:10:00] chi.jiun.su joins the room
[13:12:19] Tommy Jensen joins the room
[13:15:15] mcr joins the room
[13:17:29] Tommy Pauly leaves the room
[13:18:32] Tommy Pauly joins the room
[13:19:34] <neednnelg@sure.im> @Martin Thomson - absolutely jump in - especially on issues you submitted
[13:19:35] ChrisBox leaves the room
[13:19:51] <Martin Thomson> I will do so, when those issues come up.
[13:22:02] <andrew_campling> Helpful for people to mute if not talking to avoid background noise
[13:22:13] <ekr@jabber.org> This seems like a very very strong requirement
[13:22:52] <ekr@jabber.org> I mean to the extent to which the authoritative uses any kind of geographic steering, if the "equivalent" resolver was somewhere diferrent topologically, then it might give different answers
[13:25:16] <tale > Agreed.  I wass going to comment similarly on the list but I thought Paul's response essentially encompassed that without saying it explicitly.  The word "equivalent" is just too thorny.
[13:27:30] Tommy Pauly leaves the room
[13:28:06] Tommy Pauly joins the room
[13:29:56] <Paul Hoffman> "Subtly different"
[13:32:05] <Martin Thomson> Apologies to anyone for whom I have not gotten affiliations correct, I'm filling out the blue sheets for you.
[13:33:05] <Martin Thomson> ++ To Chris on the webex chat.
[13:33:49] <Paul Hoffman> I thought affiliation on blue sheets was optional?
[13:34:51] <Martin Thomson> I have no idea Paul.
[13:35:25] <tale > Yes, it is
[13:37:22] <ekr@jabber.org> This use case is really boiling the ocean
[13:37:52] <Martin Thomson> That's why we need to spend 4 hours on this.
[13:39:01] <Paul Hoffman> Martin, are you suggesting that we now have technology that can boil the ocean un under 5 hours? I hadn't see the HN article on that.
[13:39:56] <andrew_campling> Opportunistic solution is only available for DoT?
[13:40:07] <Paul Hoffman> Correct.
[13:40:21] <Paul Hoffman> I fully disagree with that "requirement".
[13:40:23] <Martin Thomson> So isn't this entire thing opportunistic encryption?  Except under specific conditions, where it isn't really opportunistic.
[13:40:46] <Paul Hoffman> s/specific/unspecified specific/
[13:41:05] <Martin Thomson> Oh, yes, we don't know what conditions those are, but they will be specific.
[13:41:10] <ekr@jabber.org> It seems like the predicate question is what the status of this draft is
[13:41:18] nygren joins the room
[13:41:54] <Paul Hoffman> +1 to ekr, with a sign
[13:41:59] <Paul Hoffman> sigh, that is
[13:42:41] <tale > It isn't a wg doc yet, but looked at for adoption.
[13:42:52] ChrisBox joins the room
[13:43:09] Tommy Pauly leaves the room
[13:43:50] Tommy Pauly joins the room
[13:44:49] <Martin Thomson> There are four if you take different approaches to the first piece.
[13:45:23] <andrew_campling> Split horizon is a distinct requirement too
[13:45:24] <mcr> I tend to say that it's not opportunistic encryption if you won't fail open.  Having said that, in Freeswan (back in 2002), we actually had a per-policy destination policy possible as to whether we failed open. That was a local decision, so rfc4322 didn't document such a thing.  But, it took local effort, so really, when the admin configures a destination to closed, what they were doing was just leveraging a DNS-based source of Keys to build a VPN. (That RFC4322 was DNS based has nothing to do with ADD)
[13:45:47] Tommy Pauly leaves the room
[13:46:32] <mcr> As to the status of this draft, the WG chairs, having written it, probably should have just made it a WG document by fiat, and then had a discussion about what the content should be.
[13:48:51] <ekr@jabber.org> Did the chairs write it?
[13:49:13] <tale > No, neither Glenn nor I is a co-author or otherwise contributor
[13:49:23] <andrew_campling> @ekr no, Chris Box did
[13:49:49] <nygren> It seems better to keep this as a single document and hold off on splitting it up until later as I suspect there may be a need to refactor as it evolves.
[13:50:20] <mglt> thanks ekr.
[13:51:58] <mcr> tale, sorry, I thought that Chris was a co-chair, My stupid.
[13:52:05] <tale > No worries
[13:52:15] <Tommy Jensen> Paul, your comment about needing to know what you need to know before you know it really cuts back to the underlying problem of authenticating RFC1918 addressed resolvers: we don't have authenticated network communication today. I don't think this WG is the right place to solve that problem since it isn't a DNS problem despite it having DNS implications.
[13:52:23] <Tommy Jensen> Unless I misunderstood what you meant by that?
[13:53:18] <ekr@jabber.org> FWIW I generally agree with MT about priorities here. Local discovery is clearly the index patient
[13:54:00] <Martin Thomson> I should point out that this includes many cases where people "know" the network operator.  I know my ISP, but I'm not going to tell my software everything it needs to authenticate that provider.
[13:54:18] francois.ortolan@jabb3r.org joins the room
[13:54:35] Barry Leiba leaves the room
[13:54:36] <Martin Thomson> Unfortunately, I think that we have to deal with the forwarder case as part of that.  So we have a fairly complex thing to tackle, even with that very "narrow" scope.
[13:54:46] <mglt> @ralf I missed what you would oppose to.
[13:54:47] <nygren> I assume only comments from Jabber need to be relayed if prefixed by "(mic)"?
[13:55:00] <Martin Thomson> nygren, that is my operating assumption
[13:55:36] <tale > Yes, Erik
[13:55:50] <andrew_campling> @nygren I was about to add that request - please add mic to any Jabber comments that you'd like raised on your behalf
[13:56:19] <Ralf Weber> Point 4.2 @mglt
[13:56:56] <ekr@jabber.org> I mostly concur with Tommy's interpretation here. What I meant was just that the VPN already has mechanisms or doing fairly sophisticated resolver configuration mechanisms
[13:57:31] <Martin Thomson> And now we're fully into the realm of policy.
[13:57:35] <Martin Thomson> This is a trap.
[13:57:44] <ekr@jabber.org> If we want a signal that says "to use this network, use this resolver" then isn't that for CAPPORT.
[13:57:47] Tommy Pauly joins the room
[13:59:16] <mglt> @ralf thanks for the pointer and to clarify you ar eagainst use case 4.2
[13:59:23] <mglt> in the draft
[13:59:54] <Martin Thomson> Policy alert!
[14:00:28] <mcr> The corporate VPN is not a question of "user" choice.   The "owner" of the computer (the company) made this choice.  The "user" has the choice of VPN on/off.  Our problem here is that we have not distinguished between users and owners.  (Yes, in some cases, people own their own laptops, which they decide to install the corporate VPN on. In which case, there is some delegation of ownership here).  I also think we should distinguish the Corporate VPN, from the Privacy-enhancing VPN. (Which makes me question what the P-in-VPN ....)
[14:00:54] <ekr@jabber.org> Also the unencrypted MPLS VPN
[14:00:59] <ekr@jabber.org> :)
[14:01:12] <Martin Thomson> We need an interrupt on this.
[14:01:19] <andrew_campling> RFC 8890 has "indirect users" to encompass parents and could also cover enterprises etc
[14:01:26] <Paul Hoffman> Ekr, please do not make me cry this early in the morning.
[14:01:27] <mcr> Yes, we need the network to authenticate itself to the user.  This is really where we are struggling.  We need to make this happen.
[14:01:43] <Martin Thomson> I don't want to spend more time on this question of who decides what resolver is used.
[14:01:56] <Tommy Jensen> @martin oh agreed, my point is we shouldn't take "network mandating" DNS servers a requirement because it is policy
[14:02:02] <mcr> @andrew_camping, that's a good point, and we should adopt that language.
[14:02:55] <mglt> I agree with Tommy. Anyone object this ?
[14:03:00] <Martin Thomson> I don't think that 8890 informs this discussion at alll.
[14:04:17] <nygren> I was thinking the section of "client selected DNS" should just be clear that there are multiple ways this can be configured (eg, direct user choice, enterprise policy, use of a localhost service which does its own logic, etc).  And that for some of these it may be preferable to distribute/configure a DoH service directly via config/policy than to try and do association as the former likely has better security properties.
[14:06:04] Tommy Pauly leaves the room
[14:06:05] <mcr> I think that the PC/Mac/Linux desktop will have to explicitly migrate towards the iPhone/Android PvD notion rather explicitely. We need to see the return of the Compartmentalized Workstation System, or maybe it was called Multilevel Security.(MLS).  It was a horrible failure to get anywhere in the 1990s, probably because we didn't have VMs or containers, etc.  
[14:06:41] Tommy Pauly joins the room
[14:06:57] <andrew_campling> I don't see how splitting the document makes a huge difference except in it taking more effort to coordinate input
[14:07:11] <mcr> @tale, as for not coming to the mic, I've been to the dentist just now, still recovering from gravol. Speech is a bit slurred.
[14:07:44] <tale > Totally understood.   If in retrospect you want Andrew to bring it on your behalf ...
[14:07:46] <andrew_campling> @mcr feel free to flag any comments with mic that you'd like read out on your behalf
[14:07:59] <ekr@jabber.org> It seems like there is a good way to address both my points and MT's: create a separate requirement document which just covers the local discovery thing
[14:08:36] <mcr> @martin, rfc8890 section 2 makes it clear that there are different kinds of users.  Not every user on every device gets to define policy the same way that the owner can.  Meanwhile, the user probably does need to informed of policy.
[14:08:37] <Martin Thomson> That would work, as would cutting this down to just that.  Dropping section 4 would likely achieve that.
[14:08:44] <nygren> Should we have anti-requirements as well?  For example, it would be good to be clear to set expectations that untrusted local networks may not be able to use DNS to enforce policy without user acceptance.
[14:09:44] <Tommy Jensen> @nygren to me that's a natural conclusion from "no policy or forcing client DNS choices" but I would support writing it as explicitly as you just suggested
[14:17:15] Tommy Pauly leaves the room
[14:18:24] <mglt> +1 to Tommy P.
[14:19:23] <Tommy Jensen> +1 as well
[14:19:46] <Martin Thomson> -1 to Tommy.
[14:19:59] Yoshiro Yoneya joins the room
[14:20:25] <Martin Thomson> This group has demonstrated an inability to focus on what is a ridiculously simple problem, preferring instead to chase butterflies.
[14:20:30] <mglt> The purpose of use cases is not to have all of the different flavors of use cases but to make sure every specific usecases are considered. This enable a high level description of the usecases.
[14:21:22] Tommy Pauly joins the room
[14:21:35] <andrew_campling> +1 to Paul in terms of focusing on the hard ones
[14:21:35] <mcr> I probably agree with Paul Hoffman.  Pick the hardest.  
[14:22:00] <Tommy Jensen> Authenticating local network connection is indeed a hard problem. It doesn't belong in this WG however because it's a much more general problem than DNS discovery.
[14:22:15] <Tommy Jensen> I support discovery of local encrypted resolvers
[14:22:27] <Tommy Jensen> I do not support authentication of local resolvers, encrypted or not
[14:22:59] <Tommy Jensen> (in this WG)
[14:23:26] ChrisBox leaves the room
[14:24:40] ChrisBox joins the room
[14:24:59] <Martin Thomson> We don't need to authenticate the local network connection.  We don't need to know if the resolver supports qname minimization.  We just need to know if there is an equivalent resolver that provides service over TLS.
[14:25:07] <mglt> It is unclear what "authentication of local resolvers"  means ?
[14:25:18] <Paul Hoffman> @TommyJ: Given your strong support for authenticating the discovery messages, are you saying that any solution fo the local network would need additional trust anchors?
[14:25:18] <Martin Thomson> Exactly.  Do we do that today?
[14:25:43] ChrisBox leaves the room
[14:27:42] <Vittorio Bertola> This is the question I brought to the list earlier today... I do not understand what do we mean by "authenticating the network-provided resolver", it can mean different things. Also I do not understand whether people consider the auto-upgrade of a local unencrypted resolver discovered via DHCP etc "opportunistic security". It looks different people mean different things with the same words.
[14:29:08] <Martin Thomson> Vittorio: that is why it is probably best to be very precise in what is happening rather than to rely on imprecise labels of dubious utility.
[14:29:57] <Tommy Jensen> @martin: I think the point in the draft of saying this is already possible today is: why doesn't the local network just advertise DoT supporting addresses so there's no question of "equivalent functionality"?
[14:30:40] <Tommy Jensen> @paul I'm saying any solution for local network resources needs to be generic beyond DNS
[14:31:13] <Paul Hoffman> Wow. I don't think this WG is the right place for that.
[14:31:48] <andrew_campling> @Tommy but isn't this the key problem to solve given that it's addressing the situation relavant to the majority of users
[14:32:16] <neednnelg@sure.im> I'll point our that one of the github issues is Authentication and what that means in this context. #18 in fact
[14:33:19] <neednnelg@sure.im> and issue #8
[14:33:37] <mcr> did we start again, and my audio is broken?
[14:34:09] <tale > still quiet for another minute
[14:34:22] <Tommy Jensen> @paul I agree 100%, that's my point in being noisy :) it needs to be excluded from our goals
[14:34:23] <mcr> okay. I like nap time.
[14:34:39] <Paul Hoffman> Bio breaks can be used for many different bio-y things.
[14:34:41] <Tommy Jensen> @andrew it is a valid problem, but not one for this WG
[14:35:00] mcr crunch. crunch. crunch.
[14:36:41] <Vittorio Bertola> The problem with network-provided DoT resolvers is that browsers don't support them. So it's not a solution to the problem that is being brought here.
[14:36:45] <bemasc> Having had a few minutes to think, I think the interesting question is: how do we focus on the unauthenticated case while ensuring that develop a unified architecture, to the extent possible?
[14:37:30] Tommy Pauly leaves the room
[14:37:39] <Paul Hoffman> I think that question is what is driving people insane. I propose it is not possible.
[14:38:07] <Yoshiro Yoneya> I think we should focus on very simple and narrowed use case first.
[14:38:25] <Tommy Jensen> @vittorio wait, what problem is that? Browsers can get local network DNS from the OS today. I think whether they do or not is an implementation request outside of this WG
[14:38:59] <mcr> @bemasc, coming from an IoT point of view, we really really really want devices to use the local DNS. For privacy and malware filtering reasons.  But, device vendors want to use 8.8.8.8 for reliability.  
[14:39:02] <bemasc> Vittorio: To be clear, if your local network has DoT on port 853, Chrome on Android will use it by default (via the system resolver)
[14:39:23] <bemasc> mcr: For IoT, I really like the MUD-type approaches
[14:39:25] <andrew_campling> The GitHub issues link is https://github.com/ietf-wg-add/draft-add-requirements/issues
[14:39:29] <mcr> I prefer that we work on issues on the list.  And pull requests on github.  Pull requests are focused and atomic.
[14:39:33] <Barbara Stark-jabber> Using issues also allows a PR to be created that is intended to handle a specific issue.
[14:40:18] <Tommy Jensen> +1 to mcr and Barbara (GitHub issues are a great way to keep change discussions specific and focused)
[14:40:40] <mcr> @bemasc, MUD probably fails if you don't use the same DNS that the MUD controller uses.  That's the topic of          draft-richardson-opsawg-mud-iot-dns-considerations-02 which was deemed not interesting to ADD.
[14:41:08] ChrisBox joins the room
[14:41:13] <bemasc> mcr: I think "name-based MUD" would be a great idea, but it's probably for the MUD group, not ADD.
[14:41:58] <mcr> I don't object to opening issues on github, I just would rather that, until we have specific text (when we are dealing with the problem) that it be on the list.  That could mean doing the right list-integration, which I've never gotten to work right.
[14:42:29] <mcr> @bemasc, MUD uses names.  As for "MUD group", that's OPSAWG for now, and that WG has too much other work.
[14:43:06] <Vittorio Bertola> @Tommy Jensen it is unreasonable to expect browsers to implement another protocol for that specific use case only. Since they already have DoH, plus organizational architectures to vet DoH resolvers etc, it is more reasonable to make sure that whatever DoH discovery mechanism we create also works for that use case.
[14:45:05] <mcr> @ben, rather than CTRL+ to make the font bigger, make the window that you are sharing smaller.  That way you send fewer pixels, which means webex doesn't scale it to be unreadable.
[14:45:06] <Tommy Jensen> @vittorio they have no work to do. All they have to do is use the system resolver and they'll get the network DNS (when it is trusted by the user).
[14:45:51] <Tommy Jensen> @vittorio if what you want is authenticated local network DoH servers, then I'm back to my position on that not belonging in this WG because authenticating local addresses is a problem bigger than DNS
[14:46:15] <ChrisBox> I think Paul’s referring to 3.1.
[14:46:19] <Martin Thomson> I'm OK with what Paul is saying.
[14:46:56] <mcr> I thought it was ben campbell that was displaying. I thought that his voice. So my comment is to Glenn!
[14:46:59] <Martin Thomson> That keeps VPN config out, but does it keep "I have a resolver configured, but I need DoT/DoH" out also?
[14:48:10] <ChrisBox> +1 to Tommy’s point
[14:51:10] Tommy Pauly joins the room
[14:52:57] <Yoshiro Yoneya> My thought of use case first is that it is for applications use DNS to check something additional check such as DNSSEC validation failure and/or CAA for validation. It is not for name resolution, but for checking validity.
[14:53:09] Martin Thomson leaves the room
[14:53:12] Martin Thomson joins the room
[14:54:32] <Yoshiro Yoneya> Applications = browser extensions and/or smartphone apps
[14:59:11] <Martin Thomson> I have precisely TWO use cases: I join a network that I have no prior relationship with and I want to discover the DoT or DoH resolver that corresponds to the Do53 resolver.  a) without a forwarder, and b) with a forwarder
[14:59:15] <andrew_campling> Reminder to prefix any comments with "mic" in Jabber if you want them read out for you
[15:00:10] Tommy Pauly leaves the room
[15:00:17] <Paul Hoffman> +1 to Martin's use cases. However, I have no idea how (b) would be know.
[15:00:19] <Paul Hoffman> known, that is.
[15:00:57] Tommy Pauly joins the room
[15:03:18] ChrisBox leaves the room
[15:04:45] ChrisBox joins the room
[15:04:49] <ekr@jabber.org> @MT what do you think should happen with (b)
[15:05:22] <mglt> Another use case: a trust entity tells me which resolvers I should trust for global request.
[15:05:53] <Martin Thomson> Oh, you are saying ( b ).  My client renders that as a beer.
[15:06:13] <Martin Thomson> I don't know, but that is the use case.
[15:08:32] <Paul Hoffman> Martin: where are you geogrpahically?
[15:08:50] <Martin Thomson> Sydney.  UTC+10 currently.
[15:09:03] <mcr> my topic: devices that aren't containers for human-focused browsers.  {which some might say includes digital signage, which might be entirely browser driven, but no human in control, but really that's an edge case}
[15:09:44] <mcr> I couldn't hear... what draft has bounced around?
[15:10:00] <andrew_campling> Res info
[15:10:06] <andrew_campling> (@mcr)
[15:10:28] <mcr> ah. Thank you.
[15:10:49] <mcr> +5 on What Paul is talking about trust anchors.  
[15:13:11] <andrew_campling> +1 to ekr's point  on discussing network
[15:13:25] Martin Thomson leaves the room
[15:13:27] Martin Thomson joins the room
[15:13:36] <ekr@jabber.org> BTW, I was serious about resinfo. What prevents us from just saying "that's it" and declaring victory
[15:13:40] <nygren> Clearly not appropriate for this WG to define, but some things might be easier for the local DoH use-case if there was a way to include list of cert hashes in https scheme URIs.  eg, https://192.168.1.1#5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03/doh-endpoint?{}
[15:13:53] <Yoshiro Yoneya> Trust anchors are very important. Meanwhile, I don't want to see RootStore discussions here.
[15:14:26] <ekr@jabber.org> @nygren: I do like hash URIs, but it seems like whatever mechanism we produce could probably provide both address and fingerprint/hash
[15:15:30] <nygren> It might be worth exploring hash URIs elsewhere as they might come in handy in a number of these local network environment use-cases.
[15:15:51] <Yoshiro Yoneya> I'd like to see trust anchors are on DNS also, such as TLSA RR.
[15:16:05] <ekr@jabber.org> @nygren: no disagreement there
[15:18:11] <ekr@jabber.org> @bemasc: ladder diagrams
[15:18:25] Tommy Pauly leaves the room
[15:19:22] Tommy Pauly joins the room
[15:20:26] Tommy Pauly leaves the room
[15:21:15] sftcd leaves the room
[15:21:18] Martin Thomson leaves the room
[15:21:25] <Yoshiro Yoneya> +1 to Martin for shorter meeting on next Tuesday.
[15:21:29] francois.ortolan@jabb3r.org leaves the room
[15:21:32] andrew_campling leaves the room
[15:21:40] Vittorio Bertola leaves the room
[15:21:45] <mglt> thanks bye!
[15:21:48] Barbara Stark-jabber leaves the room
[15:22:05] Dan Wing leaves the room
[15:22:10] Valery Smyslov leaves the room
[15:22:23] Paul Hoffman leaves the room
[15:22:26] ChrisBox leaves the room
[15:22:32] Ralf Weber leaves the room
[15:30:11] Mike Bishop leaves the room
[15:33:08] bemasc leaves the room
[15:45:02] bemasc joins the room
[15:45:36] bemasc leaves the room
[15:47:06] mglt leaves the room
[16:06:26] chi.jiun.su leaves the room
[16:17:06] neednnelg@sure.im leaves the room
[16:35:58] Tommy Jensen leaves the room
[17:34:59] mcr leaves the room
[18:42:26] jdub99@sure.im leaves the room
[19:02:08] ekr@jabber.org leaves the room
[19:14:18] Mirja leaves the room
[20:24:35] tale leaves the room
[22:14:43] Paul Hoffman joins the room
[22:14:51] Paul Hoffman leaves the room