[03:50:59] marka joins the room
[04:27:27] marka leaves the room
[12:42:48] Paul Hoffman joins the room
[12:53:23] tale joins the room
[12:54:17] <tale > https://codimd.ietf.org/notes-ietf-interim-2020-add-02-add
[12:54:21] tale has set the subject to: https://codimd.ietf.org/notes-ietf-interim-2020-add-02-add
[12:54:59] Tommy Jensen joins the room
[12:55:04] jdub99@sure.im joins the room
[12:56:09] <Paul Hoffman> Meeting URL? It was not posted to the mailing list in the past day.
[12:56:47] <jdub99@sure.im> https://ietf.webex.com/ietf/j.php?MTID=mcf596c63ad88ee204beada8351a0f015
[12:57:03] Barbara Stark-jabber joins the room
[12:57:06] neednnelg@sure.im joins the room
[12:57:41] <Paul Hoffman> Was that every posted to the mailing list? It is different than the one for last week.
[12:58:23] <tale > We overlooked that, sadly.  Thanks for bringing it up, we're rushing off a message now
[12:58:49] andrew_campling joins the room
[12:59:15] <jdub99@sure.im> I may have the wrong link
[12:59:54] <tale > You may; it changed from last meeting.  Please use https://ietf.webex.com/ietf/j.php?MTID=mcf596c63ad88ee204beada8351a0f015
[12:59:57] bemasc joins the room
[13:00:29] tfpauly@xmpp.jp joins the room
[13:00:29] tfpauly@xmpp.jp leaves the room
[13:00:32] <jdub99@sure.im> Thanks!
[13:00:39] ChrisBox joins the room
[13:00:55] chi.jiun.su joins the room
[13:01:11] jdub99@sure.im leaves the room
[13:01:11] bemasc leaves the room
[13:01:13] Ben Schwartz joins the room
[13:01:28] Jason_Weil joins the room
[13:01:54] mglt joins the room
[13:02:02] mcr joins the room
[13:02:12] <andrew_campling> Happy to do Jabber again
[13:02:40] Martin Thomson joins the room
[13:02:57] ekr@jabber.org joins the room
[13:04:48] <andrew_campling> Remember to prefix comments with mic if you want them read out for you
[13:06:36] ChrisBox leaves the room
[13:10:27] <Martin Thomson> ekr: clarify "local authentication" here?
[13:11:18] <andrew_campling> @ekr In the Uk it's quite common for the ISP to provide a router with wifi etc, so many users do not insert their own network kit (they can and clearly some do, including to substitute the ISP CPE)
[13:11:20] <ekr@jabber.org> Sorry, the local discovery -- i.e., your "my singel use case"
[13:11:40] <Martin Thomson> I see, authentication for local discovery, as opposed to authentication for quad9 config or content provider resolvers.
[13:11:43] <ekr@jabber.org> @andrew: it's common here as well, but it's *also* common for people to provide their own AP
[13:11:53] Jason_Weil leaves the room
[13:11:54] Jason_Weil joins the room
[13:12:16] <ekr@jabber.org> So I guess perhaps we should establish how well we want this to work
[13:12:44] <ekr@jabber.org> Say that 25% of people put in their own AP and half of them don't support new DHCP options, and you therefore get a 12.5% failure rate, is that good?
[13:12:53] <ekr@jabber.org> Or is it bad?
[13:13:27] <Martin Thomson> My understanding is that DHCP options are not passed on, unless specifically configured to do so.  So most won't pass.
[13:13:30] <mcr> if it's my AP, and I care about the options, then I get 100% success, but 100% failure when I go to Starbucks.  
[13:13:34] <ekr@jabber.org> Note that if thenetwork could push a trust anchor to you in a secure way, we would be in a great position
[13:13:43] ChrisBox joins the room
[13:14:04] <ekr@jabber.org> @mcr: sure, I mean if X% of users do not successfuly process this indication
[13:14:27] <mcr> @Martin, you are right.  Home routers that pass on DHCP options do so beacuse they are programmed to copy certain data (i.e. name servers), not because they copy DHCP options.
[13:14:28] <Martin Thomson> mcr made the relevant point: can we assume that the device knows the network a priori?  Which might happen for cellular networks, 801.x, some enterprise managed configurations.
[13:15:39] <Martin Thomson> My put in response to that is "no the device doesn't know the network ahead of time" (which was the single use case)
[13:15:43] <Paul Hoffman> @ekr: fully agree with "if it could". Haven't seen that to date, but I'm not up on all the technologies
[13:15:51] <ekr@jabber.org> @paul: me neither
[13:15:52] Jason_Weil leaves the room
[13:15:54] Jason_Weil joins the room
[13:16:05] <mcr> PaulW did not even understand my comment.  I didn't ask about WPA per see.  WPA-PSK does authenticate the network (mutually), so you can't impersonate my network. WPA-Enterprise really does this with certificates. But, this wasn't about WPA: this is about authenticating the operator of the network via SOMETHING.
[13:16:06] francois.ortolan@jabb3r.org joins the room
[13:16:52] tfpauly@xmpp.jp joins the room
[13:17:00] <mcr> @Andrew.Campling, but TR369, which isn't quite here yet, provides a split brain, so users can partially own their ISP provided KIT.
[13:17:02] <Martin Thomson> Doesn't WPA-PSK only validate that the network knows the password you are using?  So anyone who copies from the chalkboard in the coffee shop is potentially in a position to impersonate the network?
[13:17:33] <ekr@jabber.org> @MT: I don't know how to design a protocol that doesn't have that property with a short password
[13:17:42] <mcr> @Martin, yes, in the coffee shop, anyone who knows the WPA-PSK can impersonate the network, which is why I think WPA3 has some hybrid modes, but I haven't really looked deeply.
[13:17:44] <andrew_campling> @mcr they can unplug their ISP kit completely if they wish and provide their own instead
[13:17:50] <Martin Thomson> ekr: My point exactly. :)
[13:18:10] <mcr> but, if you don't know the PSK, then you can't impersonate.
[13:18:54] <Martin Thomson> mcr: every network user can impersonate the network, so it's not really a secret
[13:19:04] <mcr> @Andrew, in a few jurisdictions, you can't replace, but you can augment.  European guidelines say that's not a good idea, but it's not at the level of European regulation. Some countries have that regulation.  The US and Canada do NOT, AFAIK, but it usually works.
[13:19:17] <mcr> @Martin, yes at Starbucks.
[13:19:38] <mcr> But my neighbour can't impersonate my ESSID just by knowing my ESSID name.
[13:21:35] Nicolai Leymann joins the room
[13:23:53] Nicolai Leymann leaves the room
[13:23:57] <Martin Thomson> Jim doesn't have a detectable accent to me.
[13:24:27] Nicolai Leymann joins the room
[13:24:30] <tale > :)
[13:24:51] <neednnelg@sure.im> :)
[13:25:04] <Tommy Jensen> For the record, nobody should feel like they need to apologize for accent, whether it's "hard to understand" is relative to the accent of the listener
[13:25:15] mohit joins the room
[13:25:16] <tale > agreed
[13:25:34] <ekr@jabber.org> My accent might not be fine!
[13:25:46] ChrisBox leaves the room
[13:26:08] Mike Bishop joins the room
[13:26:16] marka joins the room
[13:26:21] <Tommy Jensen> @ekr lol, and sorry for missing the humor Jim, not awake yet
[13:26:49] <Paul Hoffman> @paulw: You are lucky. My CPE would not even let me change the DNS settings at all.
[13:27:22] <Martin Thomson> let's not build a tower based on anecdata
[13:27:28] <marka> Reminder to add yourself to
[13:27:28] <marka> https://codimd.ietf.org/notes-ietf-interim-2020-add-02-add?edit
[13:27:29] <Nicolai Leymann> Heavily depends on ISP.
[13:27:50] <mcr> are we still bashing the subtopics agenda?
[13:27:58] <Nicolai Leymann> Even if you allow changes, most of the users do not change the default settings.
[13:28:17] <Paul Hoffman> Thanks, @marka.
[13:28:30] <Paul Hoffman> Chairs: maybe remind people of that.
[13:28:38] <andrew_campling> Stats from larger European ISPs suggest that tyically 60-80% of devices are under their management
[13:28:46] <Martin Thomson> 49 on the call, 28 on codimd
[13:29:02] <Tommy Jensen> +1 to mcr, are we on agenda?
[13:30:51] Vittorio Bertola joins the room
[13:31:28] <andrew_campling> Reminder to prefix comments with "mic" if you want them relayed to the mic for you
[13:31:55] <Martin Thomson> I think that TommyP's model is reasonable.  The assumption is that your configuration protocol is secured somehow (likely at layer 1/2), which isn't great, but you need no more assumptions than that.
[13:33:03] ChrisBox joins the room
[13:33:26] <andrew_campling> @Glenn Home user and micro/small business can often be the same
[13:33:45] Nicolai Leymann leaves the room
[13:34:03] nygren joins the room
[13:34:04] Nicolai Leymann joins the room
[13:35:31] <Paul Hoffman> +1 to Ekr's question to TommyP
[13:36:31] <Martin Thomson> my understanding (15 years old now) is that DHCP is routinely secured in switches and routers by blocking UDP cross traffic on UDP ports
[13:36:39] <neednnelg@sure.im>          @andrew - for the most part wouldn't people know when they are at home versus at their office?    For the work at home case - do people have different networks for when they work versus are not working                                                          
[13:36:48] <mcr> The reason we never got RFC3319 (DHCP authentication) never took off was because we didn't have any credential to authenticate the network with.  If it's the case that we now are going to have something we can use to authenticate the network, then we could consider if that should lead towards better authentication for DHCP.
[13:37:04] <Martin Thomson> Just like a v6 router won't generally let others advertise an RA
[13:38:07] <mcr> RAguard and DHCP filters do occur, but it's not universal. We should leverage it where it's available, but recognize that it's a layer-2 hack due to lack of layer-3 security.  
[13:38:44] <mcr> it would be nice to have a solution that didn't depend upon specific L2 security, or specific L3 security, but can combine with each to make life better over time.
[13:38:45] <andrew_campling> @Glenn - Yes they would know and many people working from home use their home network for this.  My earlier point was that micro/small business not based in a home often use the same services as consumers, so the distinction between the two can be completely articifial
[13:38:59] <andrew_campling> Me
[13:39:07] <andrew_campling> Ben Schwartz
[13:39:09] <neednnelg@sure.im> @andrew - ah ok
[13:39:10] ChrisBox leaves the room
[13:39:14] <andrew_campling> Chi-Jiun Su
[13:39:16] <andrew_campling> Chris Box
[13:39:23] <andrew_campling> Dan Geist, Cox
[13:39:36] <andrew_campling> Daniel Migualt, Ericsson
[13:39:39] <andrew_campling> Davey Song
[13:39:43] <andrew_campling> David
[13:39:56] <ekr@jabber.org> Note that the client doesn't know what protections are on the network
[13:39:58] <andrew_campling> @Glenn Sorry for not being clearer
[13:41:33] <Martin Thomson> The argument is: if an attacker controls DHCP, then they can substitute Do53 and can suppress DoH, or whatever they choose.
[13:42:23] <mcr> +1 on what Tommy said.
[13:44:10] <mcr> I don't know if this means we should just trust what DHCP says, because we are sunk anyway otherwise, or if that means that we should never trust Do53 from DHCP.
[13:44:44] <mcr> . o O ( no idea what a DNS guard is.  Except for mDNS, DNS is not discovered itself. It's announced by DHCP or RA )
[13:45:48] <tfpauly@xmpp.jp> mcr: Agreed, whether we trust DHCP is a question we already have and up to the client on that network to decide. The client may or may not trust it, but if it does, the discovery mechanism should not allow an injection attack that just uses DNS
[13:48:24] <mcr> "we don't want to give attackers capabilities they didn't have before"  <- agreed.    Do we want to remove capabilities that they did have before?
[13:48:37] <Tommy Jensen> +1, negotiating with a server should be authenticated but changing server advertised in existing mechanisms doesn't need to be
[13:48:47] <Tommy Jensen> (to speaker)
[13:49:04] <andrew_campling> @mcr - is that in scope in the wg charter?
[13:49:50] <Tommy Jensen> @mcr I think that would be nice, but the minbar is to not make it worse; in more specific context, removing the ability to attack network recommendations is a problem much larger and out of scope from DNS discovery
[13:50:12] <ekr@jabber.org> @mcr: yes
[13:50:24] <andrew_campling> @Tommy J +1
[13:50:38] Nicolai Leymann leaves the room
[13:50:58] <Martin Thomson> 15 years ago, DHCP guards were available in cheap switches
[13:51:30] <mcr> All "Enterprise" class switches. It's not turned on by default in most small office switches, and not there on SOHO routers.
[13:51:41] <Tommy Jensen> +1 to ekr, since DNS isn't aware of whether DHCP protections are in place or not, we should operate as if there is none
[13:52:16] <mcr> If my 8 year old Cisco small office switch has DHCP guard, I have never seen it.
[13:52:26] <ekr@jabber.org> I think the more persuasive part about Tommy Pauly's DHCP point is that if you can't trust DHCP you are already hosed.
[13:52:37] <mcr> (I should replace it, because they never issues an image with TLS beyond 1.0. Sigh)
[13:52:48] nicolai joins the room
[13:52:48] <ekr@jabber.org> @mcr: soon you will be violating a MUST!
[13:53:24] <mglt> "Do we want to remove capabilities that they did have before?"<-- I think we shoudl try as much as possible to reduce the attack surface. Typically, trust may not entirely rely on information provided by the CPE, but instead being validated/cross checked with information provided by the ISP.
[13:53:41] <ekr@jabber.org> @mt: I agree with you. I think the problem with DHCP is deployment
[13:53:57] <ekr@jabber.org> I.e., what fraction of users will successfully be able to use DHCP
[13:54:01] <mcr> I wish the whitelabel runs openwrt/Linux in the control plane switches weren't so expensive.  Yes, they are *cheap* if you want 1000/10G/40G, but I just need 100/1000.
[13:54:50] <mcr> @ekr, yes, I noticed I had to force Firefox to speak 1.0 to be able to manage the switch.  It made be very very grumpy.
[13:55:20] Jason_Weil leaves the room
[13:55:26] Jason_Weil joins the room
[13:55:29] <Martin Thomson> ekr: DHCP is not likely to work, yes.  But we need to understand the degradation in security of alternatives.
[13:57:19] ChrisBox joins the room
[13:57:19] <tfpauly@xmpp.jp> Right—I wouldn’t advocate for using DHCP, but a discovery mechanism that proves that the DoH resolver can authenticate that it is the same as the Do53 address you got from DHCP, it’s something
[13:57:32] <Martin Thomson> Sorry, DHCP/RA is not likely to be deployed widely enough to hit enough clients to matter.
[13:57:35] <ekr@jabber.org> @tfpauly: yes, that seems interesting
[13:57:44] <mcr> I'm still confused about the agenda bashing.
[13:57:47] <mcr> @tale.
[13:57:52] <Paul Hoffman> Yeah, @martin and @marka, get some coffee now.
[13:58:05] <Martin Thomson> This is why we ended up building RFC 7216.  Not advocating for that.
[13:58:05] <mglt> agree with Tommy.
[13:58:09] <tfpauly@xmpp.jp> @mcr I think we’re into the agenda now =)
[14:01:06] <mcr> but which item are we discussing?
[14:01:41] <Paul Hoffman> @mcr: we started on #5 and quickly devolved to "everything"
[14:01:41] <Ben Schwartz> I think DHCP/RA could be a fine basis for discovery; I just don't think we should fixate on it being more secure than DNS.  For example, and EDNS0-based discovery option could have similar security properties and might have some architectural advantages.
[14:03:15] <Tommy Jensen> But can it run doom
[14:03:25] <Tommy Jensen> (at break convo)
[14:04:03] ChrisBox leaves the room
[14:07:08] ChrisBox joins the room
[14:07:33] ChrisBox leaves the room
[14:08:27] ChrisBox joins the room
[14:09:08] nygren leaves the room: Disconnected: closed
[14:09:39] <ekr@jabber.org> Somebody flag when we are starting agian
[14:09:56] <neednnelg@sure.im> will do - targeting 10 after the hour
[14:09:59] <mglt> I agree with Ben. I am not convinced we should look at securing DHCP in add and rather try to do our best with these limitations. I would like the discovery protocol simple.  
[14:10:10] <mcr> https://www.cisco.com/c/en/us/products/collateral/switches/small-business-220-series-smart-plus-switches/datasheet-c78-731284.html  <- I can't find RA guard or DHCP guard anywhere here. Did I miss it?
[14:10:30] <mglt> bell is ringing
[14:10:30] <Paul Hoffman> Starting again
[14:12:19] <mglt> how do we answer yes/no
[14:12:21] <ekr@jabber.org> So here's my put: a DNS query that just says "If you connect to this IP address, I would speak Do[TH]"
[14:12:23] <Martin Thomson> 1. Yes, but it won't be sufficient.  No additional authentication is needed in that case.
[14:12:28] <mcr> Yes, but....
[14:13:05] <andrew_campling> Yes to DHCP
[14:13:46] nygren leaves the room
[14:13:57] nygren joins the room
[14:15:31] <mglt> mike: what would be the other tools other than DHCP we could envisionned ?
[14:17:44] Jason_Weil leaves the room
[14:18:25] <tfpauly@xmpp.jp> @mglt A signal in DNS responses themselves would be such a mechanism, right?
[14:18:46] <Mike Bishop> The resinfo draft looks like a useful path, doing it over DNS.
[14:18:47] <mglt> sure. ok I see.
[14:18:58] <ekr@jabber.org> @tfpauly: note that my signal would allow an attacker who controlled DNS to block upgrade
[14:19:09] <ekr@jabber.org> but it's still probably what you can do
[14:19:11] <tfpauly@xmpp.jp> Yeah, that’s true.
[14:19:43] <tfpauly@xmpp.jp> There are lots of blocking attacks, I mainly don’t want to open up a redirection-to-attacker attack
[14:20:05] <andrew_campling> @mglt is your comment intended for @mcr or to be read out?
[14:21:42] <tfpauly@xmpp.jp> @andrew it was a response to Mike Bishop
[14:21:44] <mglt> @andrew I was responding to tommy and mike.
[14:21:58] <Barbara Stark-jabber> No-one uses PPPoA anymore. PPPoE deployments often doo not include DHCP, but that's by choice (not perceived as adding enough benefit to justify additional opertional complexity). DHCP can be used with PPPoE -- there is no technical barrier.
[14:22:07] <andrew_campling> @mglt Thanks, just wanted to be sure
[14:22:19] <Martin Thomson> Thanks Barbara.  My last box did PPPoA.
[14:22:44] <Martin Thomson> Australia is slowly eradicating DSL, but slowly is operative.
[14:23:36] <Barbara Stark-jabber> @ Martin: OMG. Stone age technology. No wonder Telstra wants to leapfrog to 5G wireline.
[14:23:57] <tale > Ethernet smoke is still an important part of the network
[14:24:01] <Martin Thomson> Telstra is no longer involved (though their legacy is still felt).
[14:24:23] <Martin Thomson> One aspect of that legacy is my inability to get a v6 address.
[14:25:03] <Tommy Jensen> +1 to Jim, writing down the threat models we're trying to address
[14:25:24] <mcr> I think that we've just agreed that our threat model is that DHCP can be trusted to provide hints.
[14:25:27] <Martin Thomson> FWIW, applications can access DHCP info from the OS relatively easily (or at least it was easy 15 years ago), even for unknown options.
[14:25:51] <Martin Thomson> That said, I completely understand why an application might choose not to do so.
[14:31:42] <andrew_campling> +1 to can't make things worse
[14:32:13] <ekr@jabber.org> Where I think worse and better are defined by "what would happen if there was no attack"
[14:33:47] <mcr> New DNS vs Classic DNS. cf: COKE.
[14:33:56] <Mike Bishop> I just keep coming back to the attack of a malicious thumb drive that manifests to the OS as a network interface and proceeds to get the OS to tell it as much as it can.  DHCP indicating the presence of a proxy server, the proxy server asking for authentication, etc.  When the entire network is the attacker, the only security is not to tell it anything.  "Possibly better, definitely not worse." is absolutely the right metric.
[14:34:46] <Martin Thomson> Why would you ever let the network choose a proxy server?
[14:35:00] <Tommy Jensen> And to TommyP's point, an address may have come from other sources than unauthenticated network discovery, such as direct endpoint provisioning the client would consider secure
[14:35:07] <Martin Thomson> I mean, people did, in the past, but it is no longer something people should do.
[14:35:29] ChrisBox leaves the room
[14:35:52] <Tommy Jensen> And +1 to the what seems like a general consensus around "don't make it worse, enable it to make it better"
[14:36:25] <andrew_campling> @Martin Thompson: What about in an Enterprise environment?
[14:36:31] <Mike Bishop> Because the network doesn't provide direct Internet access, for whatever reason.  I agree it's not the network layout I would recommend, but it exists.  And I've also been on the network where you *didn't* get the proxy information, so you just had no Internet access until someone verbally told you the address of the proxy.
[14:37:00] <Martin Thomson> andrew_campling: this is still a bad idea.  Managed devices that insist on automatical proxy discovery are exploitable if they leave that context.
[14:37:25] <Martin Thomson> The number of WPAD-based attacks we've dealt with in the last 10 years is enough to sour me on that mechanism entirely.
[14:38:45] <Martin Thomson> add proxy.pac to that, btw
[14:39:24] <tfpauly@xmpp.jp> +1 to Paul H
[14:39:42] <ekr@jabber.org> I tend to agree with Paul, but I note that this basically excludes all of the CPE-based DNS proxy cases
[14:39:48] <Tommy Jensen> @paul +1 to "private is private"
[14:40:34] <Tommy Jensen> @ekr - agreed, but the exclusion is authentication. It can still bootstrap, and whether a client wants to accept an unauthenticatable bootstrap is a policy decision up to them
[14:40:37] <Martin Thomson> ekr: I think that I am inclined to disagree with that, but insist that the solution be carefully padded with lots of caveats.
[14:40:50] <ekr@jabber.org> yes.
[14:40:51] <tfpauly@xmpp.jp> @ekr, yes that’s the conclusion I feel we’re coming to for a DNS-based discovery mechanism. If you want your CPE to have DoH, add it to DHCP directly.
[14:41:21] <Martin Thomson> In the case where you have a forwarder at a private address you might still want to know the opinion of the upstream resolver.
[14:42:48] <Martin Thomson> Not that you necessarily trust that, but because it enables SPAU-like scenarios the likes of which Mozilla/Google are trialing, each with their own separate mechanism for deciding to proceed.  An attacker under that model can only choose between a set of otherwise-acceptable resolvers.
[14:43:34] <Vittorio Bertola> "CPE advertising the DoH URI via DHCP" is a long term solution as it requires CPE upgrade. "Client discovering the same-provider DoH URI by sending a Do53 query to the CPE" is an immediately available solution matching a current deployment model. I think we possibly need both.
[14:44:34] ChrisBox joins the room
[14:44:53] <Tommy Jensen> @vittorio I think what you're hearing is the quick solution can't be authenticated and many of us would prefer we take the time to do it right. Any bootstrapping we do would need to be unauthenticated if it will be a quick solution
[14:45:20] <ekr@jabber.org> And the thing i would follow up with is: if we're willing to have something downgradeable, does authentication of the downgradeable resolver matter?
[14:45:33] <ekr@jabber.org> [modulo HSTS-type mechanisms]
[14:45:41] <mcr> I need clarification about which resolver*s* are being affliated?  the Do53 and DoH? Or is there something else I'm missing.
[14:45:48] <ekr@jabber.org> @mcr: yeah
[14:46:26] <Vittorio Bertola> @Tommy: I think the quick solution can be authenticated, if what you are authenticating is just the fact that the CPE's Do53 resolver and the DoH resolver you get through discovery are controlled by the same entity, which is all you need for the SPAU model.
[14:46:27] <tfpauly@xmpp.jp> @ekr, I think it still matters to authenticate the resolver. Downgrading/blocking is an attack, but without authenticating, we open up an entirely new set of attacks where the attacker has an encrypted channel with the client and is now in sole control of DNS
[14:46:44] <mcr> It is the assertion: "https://resolver.example/ is the DoH resolver corresponding to Do53" that needs to be expressed?
[14:47:05] <tfpauly@xmpp.jp> @mcr, I think so yes
[14:47:10] <Paul Hoffman> I thought so, now I'm not so sure.
[14:47:20] <ekr@jabber.org> @tfpauly: how is that different from (by hypothesis) controlling the Do53 resolver?
[14:47:29] <Tommy Jensen> @vittorio if the Do53 resolver is using an RFC1918 address, which seems to be the common case you want to address, I disagree this can be authenticated.
[14:48:14] <mcr> It's not an RFC1918 case, it's the IPv6 LL fe80::2 case :-)
[14:48:31] <Paul Hoffman> What Ben just said is sensible and scary.
[14:48:37] <ekr@jabber.org> 1918 is a lot easier to say than LL fe80::2:)
[14:49:43] <tfpauly@xmpp.jp> @ekr I think the two differences are (1) controlling the Do53 resolver requires being a man-in-the-middle for traffic to the provisioned DNS address, while the DoH attack just needs to get the hint to the client once and redirect it to an attacker-controlled server; (2) Do53 could be observable by others on the network, which makes an attack more obvious in some scenarios, while an attacker’s DoH channel is harder to detect
[14:49:46] <Paul Hoffman> private is private :-)
[14:50:06] <ekr@jabber.org> @tfpauly: sorry, I was assuming for the moment that it was the same IP
[14:50:09] ChrisBox leaves the room
[14:50:25] <neednnelg@sure.im> make sure you've put your personal info into the etherpad - we have 35 names there and  49 webex users
[14:50:45] <tfpauly@xmpp.jp> @ekr: Got it. Same IP may sufficient to be “address validation”, if we decide that.
[14:50:57] <Martin Thomson> So is same provider upgrade predicated on the assumption that the resolvers are "the same"?
[14:51:06] ChrisBox joins the room
[14:51:09] <andrew_campling> The Etherpad is at https://i.imgur.com/wn7YZVg.gif
[14:51:41] <andrew_campling> SOrry, https://codimd.ietf.org/notes-ietf-interim-2020-add-02-add
[14:51:45] <Tommy Jensen> I don't know how to add my name and affiliation to that, Andrew :)
[14:52:04] <andrew_campling> :-[
[14:52:06] <Vittorio Bertola> @Martin that's the policy assumption, which removes most of the problems of things breaking, legal issues around data transmission etc (at least that the two resolvers are controlled by the same entity)
[14:52:07] <Martin Thomson> Tommy, memedad.com can help you
[14:52:26] <mcr> 1) the system gets somehow (including via RA, DHCPv6, DHCP, IPCP, and by being typed in on the Network Properties dialog), can they find a DoH server.  vs 2) there is a hint in DHCP about a DoH server.
[14:52:36] <Tommy Jensen> @martin "Tommy Jensen, Bottom Text"
[14:52:39] <mcr> (2) can be reduced to (1), but (2) is not the same as (1).
[14:53:05] <Martin Thomson> Vittorio Bertola: I don't think that is a necessary assumption in the case where the network provides fully-usable resolver information.
[14:53:40] <Vittorio Bertola> @TommyJ of course we need to discuss that. But in the ISP/forwarding CPE use case, if you can use DNSSEC to validate a Do53 response to a query you send to a private IP CPE (which will forward it to the ISP's main resolver and send the response back), and then you can validate the DoH resolver's certificate through crypto information you get in the Do53 response (e.g. TLSA record), then this looks possible to me. But I am not the security expert here, maybe I am missing something obvious.
[14:54:34] <Martin Thomson> I can see cases where the network says DoH to quadX is fine, but would answer Do53 itself.
[14:55:05] <Tommy Jensen> @vittorio I didn't have an identity associated with the Do53 server, so how will I recognize the signing identity is really who the local address represents? The approach with the IP address in the cert allows the CA to confirm the owner, but this would allow an attacker to return their own cert and hijack. Unless I'm not following you?
[14:55:22] <Martin Thomson> ekr: isn't that what the DoH resinfo thing does?
[14:55:34] <Vittorio Bertola> @Martin: my use case is, the client asks the Do53 resolver "do you have a DoH equivalent?" and the resolver replies "sure, here it is". What "equivalent" means is a policy issue. If the Do53 resolver tells you "IMHO Google's DoH URI is equivalent to me", that's their choice and responsibility.
[14:55:40] <ekr@jabber.org> @MT: yeah, I think that's going to be a problem
[14:56:17] <Martin Thomson> ekr: my thought is that if you have a list of names that are OK, that might be workable, but you can't do unguided upgrade
[14:56:22] <ekr@jabber.org> @MT: yah
[14:56:42] <Martin Thomson> Vittorio Bertola: why does the resolver have to answer as opposed to the network?
[14:56:45] <ekr@jabber.org> One question to have is: do we think it's a problem to have the client think that it has secure DoH/DoT when it actually has insecure Doh/ToT
[14:56:50] <nygren> certs to local IP addresses are a disaster.  it's far too easy for people to just ship the same private keys to all devices.  
[14:56:52] <ekr@jabber.org> DoH/DoT
[14:56:54] <Vittorio Bertola> @TommyJ the TLSA record ensures that the party responding to the Do53 query has access to the private key corresponding to the certificate that the DoH resolver shows you when establishing the connection. There is no signing identity, you do not identify who is running the two services, just the fact that they are the same entity.
[14:57:19] <ekr@jabber.org> Vittorio: I'm not able to follow. Perhaps you could write this up in more detail
[14:57:34] <Tommy Jensen> @vittorio then this isn't secure, as a local attacker can replace the TLSA record with their own cert and direct to their own server, which will match the TLSA record
[14:57:47] <Tommy Jensen> +1 to nygren
[14:58:09] <Vittorio Bertola> If the TLSA record is DNSSEC-signed, and you validate the response, this should not be possible.
[14:58:22] <Vittorio Bertola> (unless of course the Do53 resolver has been taken over)
[14:58:52] <andrew_campling> But then you're no worse off
[14:59:10] <Ben Schwartz> Vittorio Bertola: TLSA record for what name?
[14:59:46] <Martin Thomson> x.y.z.10.in-addr.arpa. :p
[14:59:51] <Vittorio Bertola> For something like _doh.<resolver>.<isp.domain>?
[15:00:05] tfpauly@xmpp.jp leaves the room
[15:00:07] <Tommy Jensen> Exactly Ben's question, the attacker just injects their own DNSSEC signed record for their own server
[15:00:09] <Martin Thomson> where do <resolver> and <isp.domain> come from?
[15:00:27] <Tommy Jensen> The problem is we never had a name associated with the local Do53 server
[15:01:14] ChrisBox leaves the room
[15:01:25] <nygren> It seems like for private servers / home networks it may make sense to distribute keying information along with the association or hand-out.  (eg, include a key fingerprint along with the URL or as a separate DHCP/RA attribute)
[15:01:40] ChrisBox joins the room
[15:01:51] <andrew_campling> https://codimd.ietf.org/notes-ietf-interim-2020-add-02-add?edit
[15:02:10] <Tommy Jensen> @nygren which really cuts to the point "to authenticate a local resource, you need entropy to be communicated out of band"
[15:02:12] <Martin Thomson> nygren: if your root of trust is DHCP/RA, you can do many things
[15:02:19] mohit leaves the room
[15:02:26] <nygren> The current state here is bad, and the solutions people come up with are horrible (eg, "add this CA with a key hardcoded into all of our CPE products to your trust store")
[15:02:31] <Vittorio Bertola> @Martin I thought you would just get them through the discovery process, and perhaps validate them against a list you have (like Google/Microsoft do) if you want extra security (if not, this is basically TOFU).
[15:02:44] Barbara Stark-jabber leaves the room
[15:02:45] Jason_Weil joins the room
[15:02:56] chi.jiun.su leaves the room
[15:03:15] <Vittorio Bertola> But perhaps ekr is right that I should write this down so that it can be analyzed better
[15:03:58] <Martin Thomson> Vittorio Bertola: that would be helpful, because I think we all want to understand what lines are being drawn from actions to trust anchors.
[15:04:10] <Tommy Jensen> @vittorio our (Microsoft) list is a data gathering beta. It isn't inclusive of many large DoH servers even. I don't want to work on any standard that requires pre-configured DNS server identities for authentication
[15:04:32] <Tommy Jensen> @vittorio yes, a written proposal would be appreciated. I know you sent the email, but a more formal write up would be helpful
[15:04:35] francois.ortolan@jabb3r.org leaves the room
[15:04:36] Martin Thomson leaves the room
[15:04:44] <nygren> ie, it's better to not authenticate local network devices than to try to use a global/PKIX/DNSSEC trust anchor to authenticate them as the solutions to bridge between those are often worse than no solution.
[15:05:21] <Tommy Jensen> @nygren yes, absolutely. Adding smoke and mirror security is worse than just acknowledging you don't have security
[15:06:14] <nygren> not only that but people leave broken glass on the floor and use toxic smoke as part of the smoke-and-mirror security here in most designs/implementations I've seen in-practice.
[15:06:19] tfpauly@xmpp.jp joins the room
[15:06:35] tfpauly@xmpp.jp leaves the room
[15:06:42] tfpauly@xmpp.jp joins the room
[15:06:58] ekr@jabber.org leaves the room
[15:07:18] Vittorio Bertola leaves the room
[15:07:40] tfpauly@xmpp.jp leaves the room
[15:07:53] <Tommy Jensen> @nygren thank you for that visual, I'm going to share that with my team
[15:08:01] <Tommy Jensen> See you all at IETF 109!
[15:08:05] Tommy Jensen leaves the room
[15:08:56] tfpauly@xmpp.jp joins the room
[15:10:05] tfpauly@xmpp.jp leaves the room
[15:12:18] ChrisBox leaves the room
[15:19:01] neednnelg@sure.im leaves the room
[15:19:22] andrew_campling leaves the room
[15:33:26] tfpauly@xmpp.jp joins the room
[15:34:41] tfpauly@xmpp.jp leaves the room
[15:38:41] Mike Bishop leaves the room
[16:23:02] <mcr> nygren, that really is an interesting visual for smoke-and-mirror....
[16:23:34] Paul Hoffman leaves the room
[16:28:22] tale leaves the room
[16:31:43] tfpauly@xmpp.jp joins the room
[16:32:42] tfpauly@xmpp.jp leaves the room
[16:35:43] Jason_Weil leaves the room
[16:55:55] nygren joins the room
[17:06:27] nygren leaves the room: Disconnected: Replaced by new connection
[17:06:28] nygren joins the room
[17:25:53] nicolai leaves the room
[17:30:59] nygren leaves the room
[17:44:36] Ben Schwartz leaves the room
[17:58:11] tfpauly@xmpp.jp joins the room
[17:59:34] tfpauly@xmpp.jp leaves the room
[18:08:35] evequefou joins the room
[18:44:01] tfpauly@xmpp.jp joins the room
[18:44:02] tfpauly@xmpp.jp leaves the room
[18:44:57] mglt leaves the room
[19:29:03] tfpauly@xmpp.jp joins the room
[19:29:03] tfpauly@xmpp.jp leaves the room
[19:36:44] evequefou leaves the room
[22:34:07] Yoshiro Yoneya leaves the room