[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
[01:16:02] undefined joins the room
[03:00:08] zulipbot joins the room
[04:22:33] alex-meetecho joins the room
[04:29:08] Ash joins the room
[04:40:44] Christian Huitema joins the room
[04:40:57] Christian Huitema leaves the room: offline
[04:45:02] Barbara Stark-jabber joins the room
[04:45:52] y1 joins the room
[04:46:16] <Barbara Stark-jabber> TGI -almost- F
[04:46:24] Barry Leiba joins the room
[04:49:29] Meetecho joins the room
[04:50:03] Scott Hollenbeck joins the room
[04:50:03] Mark Andrews joins the room
[04:50:03] Alister Winfield joins the room
[04:50:03] Kirsty P joins the room
[04:50:03] Chris Lemmons joins the room
[04:50:03] Tim Wicinski joins the room
[04:50:03] Paolo Saviano joins the room
[04:50:03] Alessandro Amirante joins the room
[04:50:09] Yoshiro Yoneya joins the room
[04:50:29] Barbara Stark joins the room
[04:50:42] Joseph Kalfa joins the room
[04:51:09] Richard Wilhelm joins the room
[04:51:22] Barry Leiba_427 joins the room
[04:51:48] Benjamin Schwartz joins the room
[04:52:14] Bob Hinden joins the room
[04:52:22] Jonathan Lennox joins the room
[04:52:25] Jonathan Lennox leaves the room
[04:52:27] Paolo Saviano leaves the room
[04:52:28] Jonathan Lennox joins the room
[04:52:49] Fred Baker joins the room
[04:53:30] Michael Gibbs joins the room
[04:53:46] Takahiro Nemoto joins the room
[04:53:57] Sean Turner joins the room
[04:54:09] PE joins the room
[04:54:12] James Gould joins the room
[04:54:33] Gustavo Lozano joins the room
[04:54:55] Kirsty P leaves the room
[04:54:59] Kirsty P joins the room
[04:55:32] Christopher Wood joins the room
[04:55:33] tale joins the room
[04:55:39] englishm joins the room
[04:56:13] Paolo Saviano joins the room
[04:56:17] Ray Bellis joins the room
[04:56:18] Ted Hardie joins the room
[04:56:23] Paolo Saviano leaves the room
[04:56:24] Glenn Deen joins the room
[04:56:32] <Sean Turner> test
[04:56:38] Lars-Johan Liman joins the room
[04:56:46] Bernie Innocenti joins the room
[04:56:46] <Ted Hardie> I see your test message.
[04:56:49] Eric Rescorla joins the room
[04:57:08] tim costello joins the room
[04:57:11] <Tim Wicinski> Sean is test, test is Sean
[04:57:42] Kazunori Fujiwara joins the room
[04:57:52] Tommy Pauly joins the room
[04:57:56] Zaid AlBanna joins the room
[04:57:56] Chi-Jiun Su joins the room
[04:58:05] Libor Peltan joins the room
[04:58:19] Pete Resnick joins the room
[04:58:24] David Lawrence joins the room
[04:58:30] <Sean Turner> thanks for witnessing my test ;)
[04:58:33] Marco Davids joins the room
[04:58:34] Harald Alvestrand joins the room
[04:58:35] Pieter Lexis joins the room
[04:58:42] Chris Box joins the room
[04:58:45] Paul Wouters joins the room
[04:58:59] Robert Story joins the room
[04:59:08] Jim Reid joins the room
[04:59:12] Pete Resnick leaves the room
[04:59:16] Éric Vyncke joins the room
[04:59:16] Roland Schott joins the room
[04:59:22] Pete Resnick joins the room
[04:59:50] Tommy Jensen joins the room
[04:59:51] John Mah joins the room
[04:59:56] Erik Kline joins the room
[05:00:05] Eric Orth joins the room
[05:00:09] Vittorio Bertola joins the room
[05:00:21] James Galvin joins the room
[05:00:22] <Mark Andrews> not a issue at 16:00
[05:00:25] Daniel Migault joins the room
[05:00:28] Duane Wessels joins the room
[05:00:38] Joey Salazar joins the room
[05:00:43] Nicklas Pousette joins the room
[05:00:45] <Barbara Stark-jabber> I need a break from minute taking. Come on y'all
[05:00:53] Ralf Weber joins the room
[05:00:59] Carrick joins the room
[05:01:01] chantra joins the room
[05:01:02] Pete Resnick leaves the room
[05:01:04] PE leaves the room
[05:01:07] PE joins the room
[05:01:12] Wes Hardaker joins the room
[05:01:13] Frode Sorensen joins the room
[05:01:14] Dan McArdle joins the room
[05:01:15] Emmanuel Bretelle joins the room
[05:01:16] Michael Richardson joins the room
[05:01:19] Pete Resnick joins the room
[05:01:23] Ulrich Wisser joins the room
[05:01:31] Mike English joins the room
[05:01:31] <Barbara Stark-jabber> I can follow along and fix things up
[05:01:32] Alexander Mayrhofer joins the room
[05:01:46] Zidago Sako joins the room
[05:01:49] Joseph Kalfa leaves the room
[05:01:51] Joseph Kalfa joins the room
[05:01:53] <tale > Thank you Barbara
[05:01:54] Burt Kaliski joins the room
[05:01:58] mglt joins the room
[05:02:11] Mark Nottingham joins the room
[05:02:18] <Joseph Kalfa> mp3 audio stream seems broken
[05:02:20] David Schinazi joins the room
[05:02:22] Fred Baker leaves the room
[05:02:28] mcr joins the room
[05:02:30] Fred Baker joins the room
[05:02:31] Peter Koch joins the room
[05:02:31] <Tim Wicinski> Barabra - you do way too much and thanks!
[05:02:33] Martin Thomson joins the room
[05:02:36] <Meetecho> Joseph Kalfa: checking
[05:02:48] <Joseph Kalfa> fixed
[05:02:49] <Meetecho> It should work now
[05:02:49] Andrew Campling joins the room
[05:03:01] Shivan Sahib joins the room
[05:03:04] Roland Schott leaves the room
[05:03:08] Valery Smyslov joins the room
[05:03:09] <Martin Thomson> I didn't get the chance to try out the updated build.
[05:03:29] Francois Ortolan joins the room
[05:03:40] Eric Kinnear joins the room
[05:04:14] Paolo Saviano joins the room
[05:04:18] englishm leaves the room
[05:04:27] Paolo Saviano leaves the room
[05:04:31] Kohei Isobe joins the room
[05:04:56] Monika Ermert joins the room
[05:04:57] Roland Schott joins the room
[05:05:09] Yuji Koyama joins the room
[05:05:34] Patrick Tarpey joins the room
[05:05:46] <Sean Turner> see saag discussion about WebPKI :)
[05:06:03] Puneet Sood joins the room
[05:06:05] Marcel Parodi joins the room
[05:06:16] Taiji Kimura joins the room
[05:06:23] <Martin Thomson> The facts are pretty simple here.  ACME supports IP certs, but not all CAs do.  And obviously you can't get a certificate for a non-unique address.  End of story.
[05:06:34] Xavier de Foy joins the room
[05:06:38] andrew_campling joins the room
[05:06:44] <Sean Turner> yep
[05:06:49] <Ted Hardie> It couldn't hurt to have it up.
[05:07:02] Simon Hicks joins the room
[05:07:20] <Martin Thomson> See https://www.rfc-editor.org/rfc/rfc8738
[05:07:56] <Eric Rescorla> I believe LE currently does not support IP address certs. OTOH, LE is not the only CA
[05:07:56] Eve Schooler joins the room
[05:08:07] Marcus Ihlar joins the room
[05:08:07] <Eric Rescorla> Nor even the only ACME CA
[05:08:10] <mcr> @Martin, we need a FAQ on certificates for .local and 192.168.1.1, because while you and I, and I hope 94% of the room get it, most of the web people out there don't.
[05:08:16] <Tommy Jensen> They don't yet, but it's in their backlog
[05:08:18] Mike Bishop joins the room
[05:08:33] <Tommy Jensen> (LE and IP SANs)
[05:08:49] <Eric Rescorla> @TommyJ, you may know more about this than I at this point
[05:08:55] Stephanie Ifayemi joins the room
[05:09:04] <Martin Thomson> mcr: the .local and 1918 thing is simple: if the identifier isn't uniquely yours, you can't get a certificate for that identifier
[05:09:32] <mcr> Yes, I agree it is simple. But, non-IETFs out there don't understand.  So they don't see the problem.
[05:09:46] <Tommy Jensen> @ekr doubtful, I just looked up RFC8738 adoption when doing a yes/no analysis of current resolvers using IP SANs
[05:10:15] Oliver Borchert joins the room
[05:10:16] Suzanne Woolf joins the room
[05:10:40] <mglt> agree with Eric
[05:10:44] <Tommy Jensen> The big names using Digicert/GlobalSign/Google all do, but many small ones don't largely because of LE
[05:10:45] <Chris Box> Me too
[05:10:59] <Chris Box> (Eric Orth's points)
[05:11:06] Oliver Borchert leaves the room
[05:11:20] englishm joins the room
[05:12:09] <Tommy Pauly> Yes, the "same responses" needs to be scratched out
[05:12:20] Joseph Kalfa leaves the room
[05:12:22] Joseph Kalfa joins the room
[05:12:33] Hannu Flinck joins the room
[05:13:09] <Martin Thomson> So I prefer the idea that something/someone might delegate to a DoT/DoH server, as Ekr suggested.
[05:13:29] Joseph Kalfa leaves the room
[05:13:47] <Martin Thomson> That avoids the need to define equivalence.
[05:14:03] <Harald Alvestrand> the language "A is equivalent to B" seems to imply that B is equivalent to A. And none of the methods actually assert that.
[05:14:18] Joseph Kalfa joins the room
[05:15:05] <mglt> and A shoudl be equivalent to A as well.
[05:15:30] <Pete Resnick> EKR: Isn't the answer to your question, "You can't tell"?
[05:15:39] <Pete Resnick> Or "probably not"?
[05:15:39] <mglt> There is also the question of transitivite when multiple resolvers are being equivalent.
[05:15:48] <Harald Alvestrand> a forwarding resolver that forwards to 1.1.1.1 should be "equivalent" in this sense to 1.1.1.1, but 1.1.1.1 is not equivalent to it.
[05:15:51] <Eric Rescorla> To tip my hand, I think it would be good to have a system where I could point my users to "DoH at 1.1.1.1"
[05:16:06] <Harald Alvestrand> I think the word "equivalent" needs to go.
[05:16:11] <Ted Hardie> But that wouldn't entail a claim of equivalence.
[05:16:15] <Eric Rescorla> @Harald: that is where I am coming to
[05:16:27] <Eric Rescorla> I think the word we actually want here is *authorized*
[05:16:35] <Eric Rescorla> Or we have used the word "Affiliated"
[05:16:41] <Paul Wouters> i guess i missed the context of the usefulness of this "claim", which seems like a claim I can never verify or trust ?
[05:17:02] <Harald Alvestrand> I like verbs. "A recommends B".
[05:17:21] Stephanie Ifayemi leaves the room
[05:17:23] Tirumaleswar Reddy.K joins the room
[05:17:29] Stephanie Ifayemi joins the room
[05:17:37] <Chris Lemmons> Right. I'm slightly behind the ball here, but it's not entirely clear to me that a definition of equivalence would even be useful if we could produce one.
[05:17:41] <Eric Orth> Further hypothetical: Resolver A isn't authorizing/recommending something well-known like 1.1.1.1.  It recommends some obscure resolver nobody has heard of that many would reasonably consider to be "sketchy".
[05:17:42] ihlar joins the room
[05:17:52] <Vittorio Bertola> "Recommended" is the most precise description for what we want to happen (A suggesting the user to move to B)
[05:18:00] <Eric Orth> I would be much more concerned about that than I would have been for 1.1.1.1.
[05:18:28] <Tommy Pauly> Happy to switch back to "designated", as that was our original term =)
[05:18:28] <Eric Rescorla> So taking a step back, we are making requirements about what the technology has to do
[05:18:31] <Tommy Jensen> I'm with Eric's point (I think?) that recommendations from an untrusted port 53 channel seems dangerous
[05:18:33] <Harald Alvestrand> @eric in that case, A is corrupted, and you're toast.
[05:18:33] <Vittorio Bertola> That's squarely in the realm of client policy, though :)
[05:18:54] <Chris Lemmons> If a resolver says I should go get data from somewhere else, I&nbsp;have no reason to believe that the other resolver is in any way worse, since the first resolver could just do whatever bad thing I'm worried about instead.
[05:19:05] <Eric Rescorla> And so the requirement, I think, is what sort of operational control we require of the designated resolver
[05:19:10] <Eric Rescorla> I.e., do they need to be able to opt-in
[05:19:16] Monika Ermert leaves the room
[05:19:20] Monika Ermert joins the room
[05:20:02] Taiji Kimura leaves the room
[05:20:21] <Harald Alvestrand> short-term, we may see attacks on the config because only specific attack targets will be affected and the user is unlikely to notice the reconfig (sort of like corrupting users' proxy config in the browser).
[05:21:47] <Alister Winfield> Only problem is that if you are using plain text your security tools can see the requests and replies and thus alert you / security teams (if enterprise) that something bad is happening. Once you upgrade the useful privacy features of DoH stop the tools seeing the bad replies and thus can't protect you.
[05:22:01] Taiji Kimura joins the room
[05:22:22] <Paul Wouters> or harm you :P
[05:22:29] <Alister Winfield> So although the bad actor can do the same things the level of awareness of what that badness is changes.
[05:22:41] Junyu Lai joins the room
[05:23:12] <Eric Rescorla> I think what Andrew said here is confusing, because the ISP could just decide to switch to 9.9.9.9. any time they choose"
[05:23:45] <Tirumaleswar Reddy.K> some ISPs use public DNS servers like 8.8.8.8 as backup
[05:23:53] <Eric Rescorla> or as primary
[05:23:54] <Tommy Jensen> @ekr meaning hand out quad9 throuhg DHCP, or switch to using quad9 behind a forwarder?
[05:23:58] Antoin Verschuren joins the room
[05:24:01] <Martin Thomson> Alister: If you want those tools to help, send them your queries and ask their opinion directly.
[05:24:06] <Eric Rescorla> @Tommy: I meant the former, but the latter as well
[05:24:35] <Jim Reid> Maybe take a hum on whether a definition of equivalence is necessary here?
[05:24:43] <Martin Thomson> Jim++
[05:24:44] <Andrew Campling> @Ekr, Tiru: where ISPs do that they (hopefully) spell it out in their Ts and Cs with their customers
[05:24:55] Loren McIntyre joins the room
[05:25:15] <Eric Rescorla> I don't see how that's different from designating 8.8.8.8 as your DoT resolver and running Do53 yourself
[05:25:23] <Tommy Pauly> Absolutely there can be multiple equivalent/designated resolvers on different protocols
[05:25:48] <Martin Thomson> Andrew made a reasonable case for a policy that does insist on equivalence, but that is better served by configuring endpoints. You can't get that policy if your endpoint operates in a "I'll take whatever I get" mode.
[05:26:41] <Pete Resnick> Can someone who thinks that a single "equivalence" term is desirable (if there is such a person) please explain why?
[05:27:13] <zulipbot> [zulip] <Ralf Weber> Multiple resolvers (e.g /etc/resolv.conf) is the standard today. Which is why I brought it up on Monday as we currently don't have any text around that
[05:27:38] <Tommy Jensen> @Pete I'm not ok with necessarily allowing designation over port 53 but as a co-author I'm fine with using any other terms we deem appropriate and agree equivalent is more trouble than help
[05:27:47] <Tommy Jensen> Tommy Pauly said something similar earlier I think
[05:27:58] <Chris Lemmons> I'm not sure you can even do that then. Consider if an authoritative resolver tries to discriminate for or against DoH resolvers and resolves names differently if it thinks the resolver contacting it is a DoH recursive resolver.
[05:28:09] <Martin Thomson> Another hypothetical.  The ISP logs are kept for a day; the quad-N "delegate" keeps logs for a week.  The same?
[05:28:20] <Chris Lemmons> So two different resolvers can't ever promise that they have access to the same names.
[05:28:30] <Glenn Deen> @Pete - the notion of equivalence is a possible attribute that the particular scenario described in add-box-requirements would use.  There are other scenarios, where equivalence may not be an attribute being used in the selection
[05:28:36] <Martin Thomson> I think that Ted just made my point regarding delegation.
[05:28:41] <Andrew Campling> @MT - privacy policy is out of scope for the charter (I think)
[05:28:48] <Tirumaleswar Reddy.K> I presume we all want the client to pick a encrypted resolver hosted by a legitimate entity (like ISP, TRR) and not by an attacker by both network-identified and resolver-identified discovery mechanisms. Equivalence is introduced to solved that.
[05:28:49] mnot joins the room
[05:28:54] <Martin Thomson> Andrew: it is kinda in scope explicitly.
[05:29:29] <Martin Thomson> Andrew: "Define a mechanism that allows communication of DNS resolver information to clients for use in selection decisions."
[05:29:55] <Andrew Campling> True , but it does go on to say policy is out of scope.
[05:29:58] <Kirsty P> @Ted, I think that's a good point about splitDNS and having equivalent access to data/the same vantage point.
[05:30:06] <Joey Salazar> a delegated DoH resolver can still give equivalent or non-equivalent(local results...) resolution, then we might still need the definition for both delegation and equivalency
[05:30:14] Nancy Cam-Winget joins the room
[05:30:33] <Andrew Campling> +1 to Joey
[05:30:42] <Martin Thomson> Andrew: that's the key split.  In making the information available, we are explicitly enabling different policies.  So in deciding what information to provide, we also decide what policies are valid.
[05:30:48] <Martin Thomson> So I regard that as a chartering fail.
[05:30:51] <Tirumaleswar Reddy.K> @Andrew - why is it not in scope ?
[05:31:53] Stephanie Ifayemi leaves the room
[05:32:04] Stephanie Ifayemi joins the room
[05:32:10] <Andrew Campling> @Tiru: because the charter says it is - I'd prefer that policy wasn't out of scope but that was too contentious for some
[05:32:21] <Andrew Campling> (the WG charter)
[05:32:27] Daniel Gillmor joins the room
[05:32:35] <Tirumaleswar Reddy.K> but providing the resolver information is not out of scope
[05:32:35] <Tommy Pauly> Agreed with ekr
[05:32:37] Patrick Tarpey leaves the room
[05:32:44] <Eric Rescorla> that was rather longer than i meant to go on
[05:33:04] <Tommy Jensen> I agree with ekr that we shouldn't be ruling out the ability to designate
[05:33:05] <Martin Thomson> ekr says add == :point_right:
[05:33:17] <Eric Rescorla> I actually don't think we don't care about equivalence
[05:33:33] <tale > note that equivalence is not fully in control of the resolver.   it is only one party in dns resolutions, and multiple other parties can act independently w.r.t. it.
[05:33:35] <Eric Rescorla> I can live with Ben's proposal there
[05:33:38] <Martin Thomson> same
[05:33:39] Patrick Tarpey joins the room
[05:33:51] <Martin Thomson> I would say that you want similar performance, access to names, and privacy treatment
[05:33:52] dkg joins the room
[05:33:58] <Eric Rescorla> I think the reason for that is "it's going to be bad if you get different names if you speak ADD or not"
[05:34:01] <Andrew Campling> Ben's comment makes sense to me
[05:34:16] <Simon Hicks> I think we do care.  We'd like to see it, but then is anybody obliged to offer it
[05:34:30] <Tommy Jensen> Not sure how we define "privacy treatment" Martin... do you mean parties privy or how those parties use the data?
[05:34:31] <Eric Rescorla> so, like here's a concrete example.
[05:34:38] <Chris Lemmons> For example, is it useful to tell enterprises not to configure their resolvers to point at public resolvers that won't resolve internal names properly? Or do we just let people figure that out?
[05:34:44] <Eric Rescorla> Suppose that my Do53 resolver doesn't do DNSSEC validation
[05:34:59] <Eric Rescorla> But I want to roll out a DoT resolver that does, but I'm too lazy to update my Do53 resolver
[05:35:01] <Martin Thomson> Tommy, I mean a bunch of things: log retention, qname minimization, client subnet, etc...
[05:35:04] Mike Bishop leaves the room
[05:35:09] <Eric Rescorla> Why should this protocol discourage that
[05:35:20] <Martin Thomson> ekr: Similar or better ?
[05:35:24] <Mike English> +1 Eric Orth
[05:35:31] <Eric Rescorla> I can live with that
[05:35:33] <Vittorio Bertola> We should really separate the technical mechanism for A to recommend B, and any best practice on when and under which conditions A should recommend B
[05:35:43] <dkg> also: should they have to pull from the same specific cache?  if they don't, then it's easy to imagine different actual results
[05:35:48] <Benjamin Schwartz> +1 Vittorio
[05:35:50] <Jim Reid> @Martin: for some definition of better?
[05:36:00] <Tim Wicinski> Agree with Vittorio
[05:36:04] <Tommy Jensen> @martin I do not see how we can accomplish that given the client can't verify server behavior on things like qname minimalization
[05:36:06] <Simon Hicks> We are defining something that could usefully be built into a system, so that implementors know what they are trying to build
[05:36:10] <Harald Alvestrand> the protocol has no business checking those things (it can't). The protocol could possibly include a means of asserting those things.
[05:36:25] <Tirumaleswar Reddy.K> +! Harald
[05:36:38] Stephanie Ifayemi leaves the room
[05:36:42] <Martin Thomson> Jim: sure, it's all subjective
[05:36:45] <Ted Hardie> @dkg That's why I said you should have access to the same pool of names, rather than returns the same name.  Cache behavior can give different results from the same set based on normal operations like load balancing or geolocation.
[05:37:04] <Martin Thomson> Tommy: it's a bald assertion, and an unenforceable SHOULD, sure.
[05:37:24] <dkg> Ted, yep, makes sense
[05:37:25] <Tommy Jensen> Ah, then yes I agree with you that that's how it should work.
[05:37:26] <Martin Thomson> Remember that the posture the client adopts needs to consider the possibility that servers will lie.
[05:37:45] <Tommy Jensen> Certainly
[05:37:45] Stephanie Ifayemi joins the room
[05:38:16] <Eric Rescorla> I'd like to propose that we go with Ben's proposal
[05:38:25] <Chris Lemmons> Right. Though that doesn't mean we shouldn't necessarily put some text around what would constitute a "lie" so that servers that want to behave themselves know what good behaviour is.
[05:38:26] <Martin Thomson> I joined the queue to propose just that.
[05:38:27] <Eric Rescorla> I think that's as good as we are going to get
[05:38:32] <Eric Rescorla> +1!
[05:38:45] <Puneet Sood> +1 to that
[05:38:48] Man Zhang joins the room
[05:38:50] <dkg> also note that if you have a sketchy network that does Do53 interception, then the network operator itself can force the answers to differ between Do53 and DoT or DoH
[05:39:29] Erik Kline leaves the room
[05:39:29] Linlin Zhou joins the room
[05:40:40] Emmanuel Bretelle leaves the room
[05:40:53] <mglt> hi, just clarifying what I tended to say: From the begining of this session, i tend to understand that the authorized or equivalent designated resolver is being managed by the same entity as the one managing the initial Do53 resolver.
From the last session is seems that some raised the issue that is too restrictive and I am wondering what use cases they have in mind where an enquivalent resolver would not be managed by the same entity as the initial Do53.
It also seems that we are restricting the discovery to a "single" encrypted resolver and I believe that we should consider a list of authorized resolvers instead. As a result, the discovery mechanism should enable the discovery of a list of resolvers.
I see the discovery mechanism as a mean to derive the list of authorized/equivaent resolvers from an IP address - the one of an initial Do53 resolver for example, but the list should also be discovered from the other encrypted resolvers.
[05:41:43] <Martin Thomson> Right.  The proposal is that we are enabling a network or resolver to make a claim about a delegation that has authentication properties that are *no worse than* the existing delegation to their Do53 server.  Then, we would recommend that the delegated server - in addition to providing encrypted transport - have similar or better characteristics when it comes to performance, privacy, access to DNS records, and other characteristics that we might deem relevant to recommend.
[05:42:43] <Ted Hardie> Please use some term other than delegation, which is pretty overloaded in the DNS---designation or something.
[05:42:57] <Eric Rescorla> yeah, this seems like a good start. I think it could use some wordsmithing, but we could do that asynchronously
[05:42:59] <Tommy Pauly> Designation is what we used in our initial drafts for this
[05:43:08] Nancy Cam-Winget leaves the room
[05:43:11] <Jim Reid> Delegated is a dirty word in DNS. Could we talk about designated servers here?
[05:43:14] Nancy Cam-Winget joins the room
[05:43:15] <Tommy Pauly> Agreed that delegation has too much baggage here
[05:43:29] <Tommy Jensen> I will call out "designation" versus "recommendation" based on whether the client can verify the relationship between the two resolvers or not
[05:43:30] <Vittorio Bertola> Incidentally, it's not really like we have to define rules to protect the user's privacy. In many countries there are already privacy laws that say that you can't just add one entity into the data loop without explicitly asking the user. That kind of policy protection is already happening at the regulation layer.
[05:43:34] <Martin Thomson> Sure, wordsmith away.
[05:43:40] <Martin Thomson> designation is a good choice
[05:44:21] Sara Dickinson joins the room
[05:44:28] <Eric Rescorla> ascertainment :)
[05:44:40] <Tommy Jensen> Ah there we go.
[05:45:05] <Lars-Johan Liman> @Harald: spot on. Hence my suggestion to move to "alternative resolver".
[05:45:57] <Martin Thomson> I think that alternative short-sells it.  The addition of an encrypted transport makes it superior in at least one way and I would be sad if the designation were to regress other characteristics.
[05:46:34] Bernie Innocenti leaves the room
[05:46:38] <Chris Lemmons> "upgrade"?
[05:46:38] <Tommy Jensen> +1 Eric Orth
[05:46:40] Bernie Innocenti joins the room
[05:47:22] <Harald Alvestrand> mechanisms can be provided to identify the source of the assertion so that you can complain if he lied, and to make sure you have correctly identified the designator and the resolvers A and B. But we can't put in protocol what can't be checked.
[05:47:52] wes joins the room
[05:47:54] <mglt> I agree with David. To me equivalent resolvers are all resolvers the entity operating one resolver woudl recomnmend
[05:47:56] Jiankang Yao joins the room
[05:47:58] <Andrew Campling> @Martin - the discovery process could of course apply to any type of resolver, not just Do53 to DoH
[05:48:10] <mglt> the client may chose either of those being proposed.
[05:48:14] <Tirumaleswar Reddy.K> Cryptographic assertion of the resolver information is discussed in https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-05
[05:49:00] Jonathan Reed joins the room
[05:49:22] <Kirsty P> @Martin, can you define more clearly what you mean by "no effort has been made" to choose a resolver?
[05:49:46] <Martin Thomson> For example, I buy a machine and plug it into the network and it uses DHCP.
[05:50:15] George Michaelson joins the room
[05:50:18] <Martin Thomson> This is the default posture of clients prior to now.
[05:50:38] <Alister Winfield> You do care ... just you assume that DHCP and DNS is sufficiantly protected locally that you will go to the network designated DNS service.
[05:50:40] <Kirsty P> Just checking that you choosing and buying a machine doesn't count as effort?
[05:50:45] <Andrew Campling> @Martin: in my view I have made a decision on my resolver operator if I use, for example, the ISP - I did that when I contracted with the ISP to provide my Internet service.  
[05:50:50] <dkg> arguably, i might buy a machine because i know that the pre-installed OS protects my DNS queries better than the alternate machine i could buy
[05:50:53] <Tommy Jensen> I take issue with folks assuming use of DHCP == client has no opinion. Client may have said use DHCP specifically for EmployerNetwork and 1.1.1.1 elsewhere. IOW, just having an IP address does not mean "I'm happy to use whatever resolver I find"
[05:51:01] <Kirsty P> Alister, Martin, DKG - agree with you all
[05:51:12] <Kirsty P> And Tommy!
[05:51:43] <Martin Thomson> OK, this is why it is important to be precise.  I was not sufficiently precise in saying "no special effort".
[05:52:08] <Martin Thomson> The "I trust the network" is not generically knowable in the sense that the software on the client has no information to suggest that.
[05:52:28] <Martin Thomson> The same software used on an untrustworthy network can't tell.
[05:52:39] <Tommy Jensen> Totally agree Martin. That lack of mechanism is the source of 90% of our troubles :)
[05:53:21] <Andrew Campling> @Martin but using the network to determine the "equivalent" resolver is no change in the current level of trust
[05:53:30] <dkg> +1 Andrew
[05:53:33] <Martin Thomson> Of course, if the software had an indication from a trustworthy source (e.g., UI) that might affects its policy, that would likely override its default posture.
[05:53:50] <dkg> both "described modes of asserting the claim" depend on trusting the local network
[05:54:03] <Martin Thomson> Andrew: yes, that is why I'm suggesting that DEER or DHCP or RA is acceptable in those cases.
[05:54:41] <Martin Thomson> DEER has the DNS forwarder hole to make it marginally worse, but  it isn't fundamentally different.
[05:54:46] <Harald Alvestrand> dkg: only if the assertion can't be checked by other means (such as being signed by a chain-of-trust)
[05:55:17] <Ted Hardie> A forwarder commonly has different anonymity properties than a designated alternative, so I don't think Ben's comment reflects the whole story.
[05:55:24] <dkg> Harald Alvestrand: ah, true, thanks.
[05:55:43] Jiankang Yao leaves the room
[05:55:50] <dkg> but a network operator can still strip that signature, right?
[05:56:53] <Harald Alvestrand> dkg: yes, but then it's unsigned :-)
[05:57:47] <dkg> right: so if the client receives a signed assertion, it can verify it.  but if it receives an unsigned assertion or no assertion, it can't be sure that there is no "equivalence"
[05:57:52] Jiankang Yao joins the room
[05:58:05] <dkg> shades of OCSP's failure modes here
[05:58:08] <Eric Rescorla> I think the implicit premise of DEER is that the IP address you started from is somehow more secure than the rest of the network
[05:58:39] <Eric Rescorla> And that the purpose of DEER is to authenticate the designation in a way that as long as the IP is right, then the designation is also right
[05:58:41] Jiankang Yao leaves the room
[05:58:44] Jiankang Yao joins the room
[05:58:57] <Joey Salazar> +1 Tommy Jensen
[05:59:00] <Tommy Jensen> ekr: bingo ^
[05:59:24] <Eric Rescorla> That might actually be the explicit premise of DEER. It's late.
[05:59:43] Jiankang Yao leaves the room
[05:59:48] <Tommy Jensen> Ha I didn't catch that. Cheers to Thailand time.
[06:00:12] <Harald Alvestrand> dkg: if the client receives nothing, it can never guarantee that there is nothing that can be known. That's just a property of the universe.
[06:00:18] <Glenn Deen> it's late and it's the end of the IETF meeting week.
[06:00:20] <Eric Rescorla> Hmmm... I wouldn't be in favor of a DoT -&gt; Do53 mapping!
[06:01:00] <Vittorio Bertola> Here it's early, but I guess that as you can't know how that IP was procured, you also can't know whether that IP was chosen or not, and whether it was considered more secure or not. But I'm fine with assuming that it is.
[06:01:18] <Eric Rescorla> Right, I'm just stipulating that it is
[06:01:26] <Eric Rescorla> Because if it isn't, then you've got nothing
[06:01:28] <Martin Thomson> If we don't make assumptions like that, things get really, really hard.
[06:01:38] <Vittorio Bertola> I agree.
[06:01:44] Jiankang Yao joins the room
[06:01:52] <Tommy Jensen> I think we can all agree "equivalent" is so yesterday.
[06:02:15] <Eric Rescorla> Let's just say "isomorphic"
[06:02:20] <Vittorio Bertola> But I was suggesting that, in the end, a lot of our elaborate thinking might be futile :-)
[06:02:21] <Tirumaleswar Reddy.K> +1 Lars
[06:02:21] <Tommy Jensen> Until you involve same-entitiy
[06:03:03] <dkg> "trustworthy" is an entirely different can of worms.  I hope we aren't going to try to define "trust" next
[06:03:21] <Tommy Jensen> @ekr so you're saying the destination resolver can also send the client back the other way?
[06:03:25] <Ted Hardie> @liman Even the pool of names question would be hard to answer by "going to the other resolver" .  I can design heuristics for it, but it would slow and failure prone.
[06:03:28] <Eric Orth> There are cases where you know how the IP was procured, eg because it was directly user-entered into the client.  But in other cases the client just won't know at all, so I imagine most clients would choose to assume it wasn't completely random and untrusted to error on the side of following user intent.
[06:03:38] <Paul Wouters> I trust dhcp's dns to get me to the signon portal :)
[06:03:43] <Andrew Campling> @dkg Agree, let's not define trust too, at least not just now ;-)
[06:03:47] <Tommy Jensen> @dkg same, let's leave trust out of it
[06:03:51] <Martin Thomson> Designation requires that we extend a certain amount of trust.  In the network or the Do53 resolver.  Adding additional information to this makes this harder, not easier.
[06:04:08] <Eric Rescorla> @Tommy: I wasn't saying that. I was only saying that even if it could, we shouldn't tell people how to start with a DoT resolver and go to a Do53 resolver. that would be weak sauce
[06:04:14] Emmanuel Bretelle joins the room
[06:04:18] <Tommy Jensen> Oh yes 100%
[06:04:29] Erik Kline joins the room
[06:04:35] <Joey Salazar> Lars' idea does seem to simplify things a bit; here's a DoH resolver, do you trust it?" It might be same entity, it might be a different entity, doesn't matter; the client has the info and makes the choice
[06:04:42] <Tommy Jensen> but say DoT -&gt; DoH, basically {all} -&gt; {all - Do53}
[06:05:12] <Martin Thomson> I don't see much value in lateral movement.
[06:05:12] <Tommy Jensen> @joey yes, so long as I the client can tell if it is same entity or not then I'm happy
[06:05:20] <Eric Rescorla> Interesting question. I mean, it's implicit in DEER, though I guess you'd have to tell the DEER client to keep checking
[06:05:32] <Eric Rescorla> It's not implicit in the DHCP/RA ones
[06:05:40] <Eric Orth> I imagine some client that really cares about reliability above all else might find a DoH-&gt;Do53 designation reasonable enough to have as a backup.
[06:05:41] <Paul Wouters> which enterprise wants a split dns where they dont get to see some of the DNS sent ? This is an imaginary use case
[06:06:01] <Jim Reid> @Joey, trust is a *much* harder thing to define and do here.
[06:06:14] <Joey Salazar> @Tommy, then once the choice is made, or about to be made, another mechanisms on top of that first one to actually verify if that's same entity or not
[06:06:19] <Benjamin Schwartz> +1 Ted.  Especially privacy properties!
[06:06:45] <Andrew Campling> @TommyJ - I think both same entity and same answers matters, eg there could be malware filtering on one, malware and adult content filtering on another
[06:06:58] <Joey Salazar> like, in layers; first here's an option for you -&gt; wanna know more? -&gt; it's same entity -&gt; ...
[06:07:24] <Martin Thomson> Andrew, if that is your policy decision, then you need to have a client adopt that policy.
[06:07:47] <Paul Wouters> no. firefox is saying "we deem A and B good enough to recommend them to you"
[06:07:58] <Paul Wouters> i assume. but ekr can say that :)
[06:08:06] <Andrew Campling> Sure, but these are both aspects of equivalence
[06:08:06] <Martin Thomson> Paul: that is correct.
[06:08:09] <Jonathan Lennox> 8.8.8.8 would presumably say it's equivalent to dns.google.
[06:08:28] Bob Hinden leaves the room
[06:08:34] <Tommy Jensen> @Andrew I trust the entity to know that. If I verify it's the same entity then it's in their best interest to send me to the same service. If I can't trust them to do that, then why am I using them at all?
[06:08:34] <Martin Thomson> Jonathan: but why would it?  What value have we obtained in that process?
[06:09:12] <Benjamin Schwartz> Tommy: If you trust them to provide equivalent service, why don't you trust them to designate a suitable equivalent?
[06:09:46] <Andrew Campling> @TommyJ - the entity may operate different resolvers, eg Cloudflare has several
[06:09:57] <Tommy Jensen> @Ben because if they recommend a different server over 53 and that resolver can't prove it's the same entity, then how do I know it wasn't an attacker's recommendation
[06:09:58] <Martin Thomson> Ben has it right.  This designation ONLY works in the case where you were about to send queries to a resolver anyway.
[06:10:24] Alissa Cooper joins the room
[06:10:44] <Tommy Jensen> @Andrew yes that's my point. Once I know it's the same entity, I rely on that entity to give me "same functionality" the same way I trust them to give me the functionality on the original server
[06:11:07] <Martin Thomson> The net effect is either A: sending queries in the clear - if that path has an attacker, then the attacker gets those queries and can answer then. or B: sending queries to the entity identified in the exploratory query/configuration.
[06:11:16] Tirumaleswar Reddy.K leaves the room
[06:11:21] Tirumaleswar Reddy.K joins the room
[06:11:28] Tirumaleswar Reddy.K leaves the room
[06:11:32] <Andrew Campling> @TommyJ - so I would treat same entity and same functionality == equivalence
[06:11:36] <Eric Orth> @TommyJ More importantly, I think you're saying you trust the same entity to truthfully tell you whether or not it is same functionality, not that you trust automatically that it is same functionality.
[06:11:48] <Tommy Jensen> @eric correct
[06:11:49] <Vittorio Bertola> @TommyJ: To that effect, isn't enough for you to know that the recommendation actually comes from the operator of server A, independently from whether B is run by the same entity?
[06:11:59] Robert Story leaves the room
[06:12:02] <Tommy Jensen> @andrew correct
[06:12:08] Robert Story joins the room
[06:12:11] Benjamin Schwartz agrees
[06:12:55] <Tommy Jensen> @vittorio I don't see the difference when the first resolver is over port 53
[06:13:15] <Simon Hicks> I think we have to accept normal operation here. If a path is attacked I don't think we can expect, or even want, equivalence
[06:13:19] <Tommy Jensen> In that situation, I can never guarantee anything about its identity independent of the destination resolver wighing in
[06:14:11] Tirumaleswar Reddy.K joins the room
[06:14:32] <Tommy Jensen> @martin say the client only uses 53 to do bootstrapping. In that case, and it insists on same entity, then it will give up and throw no connection sooner than fall back or use a rogue recommendation
[06:14:32] <Vittorio Bertola> Yes, the fundamental problem is that we are unable to authenticate the recommendation 100% in that case, so either the client is willing to at least adopt TOFU and accept it anyway, or it will never accept any recommendation and we can go home :)
[06:15:35] <Vittorio Bertola> Would you have any additional, measurable condition that would make you accept a recommendation received over 53 that you would not otherwise accept?
[06:15:46] Tirumaleswar Reddy.K leaves the room
[06:15:50] Tirumaleswar Reddy.K joins the room
[06:15:56] George Michaelson leaves the room
[06:16:21] <Tommy Jensen> @vittorio DEER contains what I would accept (the recommended claiming ownership of the recommender) in the "same entity or bust" scenario.
[06:16:28] <Martin Thomson> Tommy: if you insist on perfection and provide no means to guarantee that, you will get failure, sure.
[06:17:05] <Tommy Jensen> @martin for that scenario that would be expected. I also think the average case makes sense (no need for same tnity). I just need to know the difference between the two t run time.
[06:17:37] <Vittorio Bertola> Sorry, I'm still sleepy. I sincerely don't remember how you verify the claim of same ownership in DEER.
[06:17:47] <Tommy Jensen> @ekr I do want to keep working on requirements, but I do agree we should not block adoption discussions as that seems to be a good way to block WG progress.
[06:18:05] <Tommy Jensen> @vittorio nw :) We check the TLS cert for IP SAN of the recommender
[06:18:15] <Paul Wouters> that's what we said about the charter discussion too :P
[06:18:29] <Tommy Jensen> The reqs and the adopted docs will likely feed on e another rahter than the ideal waterfall model
[06:18:46] <Eric Rescorla> The other reason to try to look at DEER (or, you know, another of the concrete protocol) is that it will help us flesh out what the true requirements are
[06:18:51] <Vittorio Bertola> Ah, now I know why I didn't remember - that's the "15%" use case that is not on the top of my mind
[06:19:17] <Tommy Jensen> @ekr exactly. Whiteboarding only gets you so far before prototyping is needed
[06:19:19] <Eric Rescorla> I mean, we could look at our CNAME proposal. I know that's not good enough, so maybe trying to look at that would help us flesh out why!
[06:19:23] <Martin Thomson> I'm going to put this out there.  There is no solid means of providing clients with information that would allow them to strongly assert that a DoH server and a Do53 server are the same.
[06:19:27] Alissa Cooper leaves the room
[06:19:44] <Tirumaleswar Reddy.K> +1 Martin
[06:19:45] Shivan Sahib leaves the room
[06:19:48] Shivan Sahib joins the room
[06:19:57] <Tommy Jensen> +1, for "the same"
[06:19:57] <Martin Thomson> Even in the case where the DoH server offers a certificate with an ipAddress SAN that matches the Do53 address, that is not proof I personally would accept.
[06:20:01] <dkg> Martin Thomson: agreed.  that's the problem
[06:20:04] <Harald Alvestrand> +1 martin
[06:20:06] <Vittorio Bertola> @Martin that's what I've come to think as well, at least in the key use case of upgrading the standard home user with a private IP forwarding CPE.
[06:20:08] <Tommy Jensen> @martin wait why?
[06:20:11] <Tirumaleswar Reddy.K> the assertion can only reduce the threat surface but cannot prove they are hosted by the same entity
[06:20:11] Junyu Lai leaves the room
[06:20:19] <Martin Thomson> Tommy: Dolev-Yao
[06:20:36] Peter Koch leaves the room
[06:20:49] <Eric Rescorla> @MT: you mean in the context where the certificate is bogus or the context where you are wrong about the IP of the Do53 server?
[06:20:54] <Martin Thomson> The assertion we might reasonably make is that "by using this designated server, you are no worse off"
[06:21:02] Jiankang Yao leaves the room
[06:21:13] Jiankang Yao joins the room
[06:21:22] <Harald Alvestrand> "are the same" is an undefinable and likely not useful. It is easier and more useful to say something like "in the opinion of A, the client would be equally well or better served by sending its queries to B".
[06:21:26] <Martin Thomson> Ekr: no, because you have no means of authenticating that you are really talking to the owner of the IP address when you use unauthenticated UDP.
[06:21:28] <Tirumaleswar Reddy.K> yup
[06:21:33] Peter Koch joins the room
[06:21:43] <dkg> Martin Thomson: there are many different axes by which one can measure "worse"
[06:21:45] <Tirumaleswar Reddy.K> IP addresses can be easily spoofed
[06:21:52] <dkg> what if latency is different?
[06:22:03] <Eric Rescorla> @MT: right, hence the text I proposed about if the data was securely delivered to that entity
[06:22:15] <Joey Salazar> @Martin "There is no solid means of providing clients with information that would allow them to strongly assert that a DoH server and a Do53 server are the same" I think this is acceptable as long as there's explicit consent on the client side
[06:22:22] <Harald Alvestrand> dkg: that's why "in the opinion of A" needs to be part o the definition.
[06:22:22] <dkg> i like Harald's approximation
[06:22:25] <Martin Thomson> dkg: sure, and you might get worse results in some ways, like with latency, so we might need to finagle it a little.
[06:22:46] <Paul Wouters> anycast IP... equivalent... except they are hosted in different world regimes....
[06:22:46] <Martin Thomson> Harald's formulation is good.
[06:22:58] <Martin Thomson> With the same caveats, of course.
[06:23:00] <Vittorio Bertola> I restate the fact that there are three parts to the story:1) The operator of A decides that B is equivalent according to their own policy2) A protocol conveys that statement to the client3) The client decides whether to accept that recommendation according to their own policy.Trying to impose conditions upon 1 or 3 is IMHO futile.
[06:23:19] <dkg> David, we're not all in the same TZ
[06:23:38] <Vittorio Bertola> (also trying to CRLF mid-message in this chat is futile)
[06:23:40] <Eric Rescorla> @dkg: true, though at this point of IETF i think everyone is exhausted no matter what the time zone
[06:23:54] <Tommy Jensen> yeah sorry Martin might have to do email, I'm losing the thread
[06:24:07] <Tommy Jensen> oh perfect, nvm
[06:24:12] <Tommy Jensen> We'll do it live!
[06:24:22] <Eric Rescorla> Martin stated this much earlier
[06:24:59] Daniel Migault leaves the room
[06:25:06] Daniel Migault joins the room
[06:26:12] <Tommy Jensen> oh, I thought you might bring up the security model you were concerned with Martin
[06:26:13] <Éric Vyncke> Having a CA issuing a cert for a RFC 1918 internal address will be interesting ;-)
[06:26:33] <dkg> Éric: no more interesting than certs for foo.local :)
[06:26:41] <Éric Vyncke> ;-)
[06:26:44] <Paul Wouters> I'm looking forward to some AWS IP certificates
[06:26:46] Alexander Mayrhofer leaves the room
[06:26:58] Alexander Mayrhofer joins the room
[06:27:07] <Jonathan Lennox> Well, if the lifetime is very short...
[06:27:18] <Jonathan Reed> @paul: exactly
[06:27:19] <dkg> Paul Wouters: wasn't there a paper in last years ANRW about AWS IP capture?
[06:27:30] <Paul Wouters> dkg: yes
[06:27:41] <dkg> (and using it to gain DNS name-based certs from lagged DNS records)
[06:27:41] <Paul Wouters> dkg: but it was about forward DNS i think ?
[06:27:57] <Paul Wouters> dkg: exactly.
[06:28:05] <dkg> delicious.
[06:28:13] Erik Kline leaves the room
[06:28:20] <Paul Wouters> dont get me wrong. I like IP certs. I can use them to auth IPsec :)
[06:28:59] Yuji Koyama leaves the room
[06:29:22] <Paul Wouters> how can you not accept what the network gives you?  In the enterprise you get blocked, in the coffeeshop you can't get past the portal.
[06:29:43] <Tommy Pauly> @martin, thank you for stating that. I am too tired, but that is exactly the right point.
[06:30:07] <Tommy Jensen> +1 thanks Martin. Definitely not all IP only starting points are the same
[06:30:59] <Eric Orth> +1 to Ben's point.  At least for Chrome, we usually don't know where an IP came from, so we have to assume it came from something secure or user-chosen.
[06:31:13] <Tommy Jensen> Same. And I'd rather assume too much intent than too little.
[06:31:34] <Benjamin Schwartz> Yep, I think DEER's choice is safe and sensible on that front.
[06:32:17] <Tommy Pauly> This is actually a not terrible use of the hands tool!
[06:32:28] <Martin Thomson> Re: interim, definitely "no" if we make no progress on these issues.
[06:32:32] <Tirumaleswar Reddy.K> prefer DHCP/RA and a fallback to DEEP
[06:32:45] <Martin Thomson> Frankly, if we can't nail down something akin to what Ben suggested earlier before then, I'm not going.
[06:32:48] <Tirumaleswar Reddy.K> wait for reasonable progress and then a interim
[06:32:55] Gustavo Lozano leaves the room
[06:32:59] <Tommy Jensen> One person is 100% done with today apparently
[06:33:00] <Christopher Wood> +1 - what is the goal of the interim?
[06:33:01] Gustavo Lozano joins the room
[06:33:13] <Vittorio Bertola> There's dnsop and dprive following us :-)
[06:33:17] Burt Kaliski leaves the room
[06:33:17] <Suzanne Woolf> DNSOP starts in about an hour :-)
[06:33:18] <Joey Salazar> sleep?! dnsop and dprive next!! &gt; : )
[06:33:20] <Joey Salazar> T-T
[06:33:37] <Vittorio Bertola> Today is the dawn of DNS (in CET)
[06:33:42] <Tommy Jensen> Oh I can't wait. I've got caffeine and the knowledge it's Friday
[06:33:49] <Martin Thomson> Tiru, I also share that bias, but I think that DHCP/RA is less likely to reach enough people to matter.
[06:34:15] <Joey Salazar> I got the memory of Thai Coconut-mango-rice to keep me company &lt;3
[06:34:29] <Benjamin Schwartz> @Tiru DEER also supports a named-based bootstrap, for a name distributed over DHCP/RA.
[06:34:30] <Martin Thomson> Joey easy to make at home
[06:34:30] Jiankang Yao leaves the room
[06:34:37] <Vittorio Bertola> @TommyJ: It's Friday but I have to attend the GA of an association up to 6pm, so it'll be a long Friday...
[06:34:37] Eric Rescorla leaves the room
[06:34:37] Jiankang Yao joins the room
[06:34:38] <Tommy Pauly> Agreed that DHCP/RA should be preferred by a client, but will be less common
[06:34:40] Christopher Wood leaves the room
[06:34:43] Carrick leaves the room
[06:34:46] Mark Nottingham leaves the room
[06:34:49] <Tommy Jensen> @vittorio ugh, I'm so sorry
[06:34:50] Jonathan Reed leaves the room
[06:34:50] <Martin Thomson> Tommy: exactly.
[06:34:52] Sean Turner leaves the room
[06:34:53] <Chris Lemmons> Thanks for the discussion.
[06:34:54] <Tirumaleswar Reddy.K> @Martin- the network security agent we ship on millions of home routers is upgradable; we have seen both upgradable/non-upgradable routers
[06:34:54] <Andrew Campling> Thanks Dave, Glenn - and good luck to the note takers!
[06:34:54] <Joey Salazar> would be missing that Thai flavor though
[06:34:54] Kirsty P leaves the room
[06:34:55] <Tommy Jensen> That was me on monday with Andrew's EDDI call
[06:34:56] Barry Leiba_427 leaves the room
[06:34:56] Patrick Tarpey leaves the room
[06:34:57] Zidago Sako leaves the room
[06:34:57] Alexander Mayrhofer leaves the room
[06:34:57] Francois Ortolan leaves the room
[06:34:58] PE leaves the room
[06:34:58] Tim Wicinski leaves the room
[06:34:58] Eric Kinnear leaves the room
[06:34:59] Roland Schott leaves the room
[06:34:59] Emmanuel Bretelle leaves the room
[06:34:59] Mike English leaves the room
[06:34:59] Alister Winfield leaves the room
[06:34:59] Eric Orth leaves the room
[06:34:59] Scott Hollenbeck leaves the room
[06:35:00] Lars-Johan Liman leaves the room
[06:35:00] Nancy Cam-Winget leaves the room
[06:35:01] Dan McArdle leaves the room
[06:35:01] Hannu Flinck leaves the room
[06:35:01] Ulrich Wisser leaves the room
[06:35:01] Chi-Jiun Su leaves the room
[06:35:01] Duane Wessels leaves the room
[06:35:02] Frode Sorensen leaves the room
[06:35:02] Paul Wouters leaves the room
[06:35:02] David Lawrence leaves the room
[06:35:03] Yoshiro Yoneya leaves the room
[06:35:03] <Vittorio Bertola> It's the double working day of IETF weeks in other timezones!
[06:35:04] Éric Vyncke leaves the room
[06:35:04] Tommy Pauly leaves the room
[06:35:04] Andrew Campling leaves the room
[06:35:04] Suzanne Woolf leaves the room
[06:35:05] Sara Dickinson leaves the room
[06:35:05] Gustavo Lozano leaves the room
[06:35:05] Kazunori Fujiwara leaves the room
[06:35:06] Nicklas Pousette leaves the room
[06:35:06] Michael Gibbs leaves the room
[06:35:06] Chris Lemmons leaves the room
[06:35:07] Barbara Stark leaves the room
[06:35:08] Puneet Sood leaves the room
[06:35:08] Harald Alvestrand leaves the room
[06:35:09] Jim Reid leaves the room
[06:35:09] Marco Davids leaves the room
[06:35:10] Pete Resnick leaves the room
[06:35:11] Barbara Stark-jabber leaves the room
[06:35:12] Fred Baker leaves the room
[06:35:13] James Galvin leaves the room
[06:35:14] Xavier de Foy leaves the room
[06:35:15] Joey Salazar leaves the room
[06:35:17] Daniel Gillmor leaves the room
[06:35:22] <Martin Thomson> Tiru: exactly why that matters, and also because that option is marginally more secure
[06:35:23] Tommy Jensen leaves the room
[06:35:24] Ted Hardie leaves the room
[06:35:28] Martin Thomson leaves the room
[06:35:39] Jonathan Lennox leaves the room
[06:35:40] Shivan Sahib leaves the room
[06:35:42] tim costello leaves the room
[06:35:47] Benjamin Schwartz leaves the room
[06:35:48] Chris Box leaves the room
[06:35:51] Taiji Kimura leaves the room
[06:35:53] Stephanie Ifayemi leaves the room
[06:35:59] Vittorio Bertola leaves the room
[06:36:00] Stephanie Ifayemi joins the room
[06:36:15] mglt leaves the room
[06:36:15] Glenn Deen leaves the room
[06:36:21] Daniel Migault leaves the room
[06:36:22] Ralf Weber leaves the room
[06:36:25] Takahiro Nemoto leaves the room
[06:36:28] Linlin Zhou leaves the room
[06:36:43] Kohei Isobe leaves the room
[06:36:45] Paolo Saviano joins the room
[06:36:57] <alex-meetecho> is the meeting over?
[06:37:10] Jiankang Yao leaves the room
[06:37:15] Paolo Saviano leaves the room
[06:37:18] Peter Koch leaves the room
[06:37:40] Zaid AlBanna leaves the room
[06:39:04] wes leaves the room
[06:39:16] <Tirumaleswar Reddy.K> yes, because it is more secure and no need to rely on Do53
[06:39:24] Marcel Parodi leaves the room
[06:39:49] Marcus Ihlar leaves the room
[06:40:00] Monika Ermert leaves the room
[06:40:20] Valery Smyslov leaves the room
[06:41:19] Man Zhang leaves the room
[06:42:04] mnot leaves the room
[06:43:00] Barry Leiba leaves the room
[06:43:17] Eve Schooler leaves the room
[06:43:27] James Gould leaves the room
[06:44:01] Stephanie Ifayemi leaves the room
[06:44:07] Pieter Lexis leaves the room
[06:44:32] Alessandro Amirante leaves the room
[06:45:01] alex-meetecho leaves the room
[06:45:10] Mark Andrews leaves the room
[06:45:10] Ray Bellis leaves the room
[06:45:10] Michael Richardson leaves the room
[06:45:10] Tirumaleswar Reddy.K leaves the room
[06:45:10] John Mah leaves the room
[06:45:10] Bernie Innocenti leaves the room
[06:45:10] Antoin Verschuren leaves the room
[06:45:10] Robert Story leaves the room
[06:45:10] Wes Hardaker leaves the room
[06:45:10] Richard Wilhelm leaves the room
[06:45:10] Joseph Kalfa leaves the room
[06:45:10] Loren McIntyre leaves the room
[06:45:10] David Schinazi leaves the room
[06:45:10] Libor Peltan leaves the room
[06:45:10] Simon Hicks leaves the room
[06:45:15] Meetecho leaves the room
[06:50:29] andrew_campling leaves the room
[06:53:29] y1 leaves the room
[06:55:31] chantra leaves the room: Stream closed by us: Timed out waiting for stream resumption (connection-timeout)
[07:35:46] chantra joins the room
[08:38:38] chantra joins the room
[08:44:37] chantra leaves the room: Stream closed by us: Timed out waiting for stream resumption (connection-timeout)
[08:48:14] chantra leaves the room: Stream closed by us: Timed out waiting for stream resumption (connection-timeout)
[09:48:51] Vittorio Bertola joins the room
[09:48:55] Dan York joins the room
[09:48:55] zyxbac joins the room
[09:55:00] Matthew joins the room
[10:12:55] Ash leaves the room: Disconnected: read timeout
[10:19:07] englishm joins the room
[10:20:09] englishm leaves the room
[10:24:20] englishm joins the room
[10:25:04] englishm leaves the room
[10:28:51] englishm joins the room
[10:29:51] englishm leaves the room
[10:42:03] chantra joins the room
[10:57:20] chantra leaves the room: Stream closed by us: Timed out waiting for stream resumption (connection-timeout)
[11:11:49] dkg leaves the room
[11:58:53] tale leaves the room
[12:00:27] Ash joins the room
[12:15:06] Ash leaves the room
[12:43:00] chantra joins the room
[12:48:57] chantra leaves the room: Stream closed by us: Timed out waiting for stream resumption (connection-timeout)
[13:14:05] Paolo Saviano joins the room
[13:14:41] Paolo Saviano leaves the room
[14:01:21] Ash joins the room
[14:16:02] Ash leaves the room
[15:24:56] ihlar leaves the room
[16:02:19] Ash joins the room
[16:11:29] chantra joins the room
[16:17:05] Ash leaves the room
[16:41:58] tale joins the room
[16:41:58] tale leaves the room
[16:41:58] tale joins the room
[16:41:58] tale leaves the room
[17:13:20] tale joins the room
[17:13:20] tale leaves the room
[17:21:51] tale joins the room
[17:21:56] tale leaves the room
[17:27:00] tale joins the room
[17:27:04] tale leaves the room
[17:36:19] tale joins the room
[17:36:24] tale leaves the room
[17:49:02] tale joins the room
[17:49:02] tale leaves the room
[17:53:05] Ash joins the room
[18:00:30] tale joins the room
[18:00:30] tale leaves the room
[18:00:30] tale joins the room
[18:18:07] tale leaves the room: Disconnected: closed
[18:23:07] tale joins the room
[18:23:55] tale leaves the room
[18:30:00] ihlar joins the room
[18:43:59] tale joins the room
[18:43:59] tale leaves the room
[18:44:25] tale joins the room
[18:44:31] tale leaves the room
[20:01:26] Ash leaves the room: Disconnected: read timeout
[20:28:56] Ash joins the room
[21:17:35] tale joins the room
[22:04:30] ihlar leaves the room
[22:10:30] tale leaves the room