Tuesday, July 27, 2021< ^ >
mcr has set the subject to: notes at:
Room Configuration
Room Occupants

[18:39:10] Yoshiro Yoneya joins the room
[18:39:50] Meetecho joins the room
[18:45:03] Liang Qin_web_983 joins the room
[18:45:03] Alessandro Toppi_web_725 joins the room
[18:45:03] Gaël Berthaud-Müller_web_130 joins the room
[18:45:03] Sandoche Balakrichenan_web_926 joins the room
[18:45:03] Yoshiro Yoneya_web_576 joins the room
[18:45:03] Chi-Yuan Chen_web_260 joins the room
[18:45:03] Tobia Castaldi_web_636 joins the room
[18:45:47] meetecho-alex joins the room
[18:47:25] Michael Richardson_web_797 joins the room
[18:48:27] Shigeya Suzuki_web_304 joins the room
[18:49:34] Wes Hardaker_web_711 joins the room
[18:49:53] meetecho-alex has set the subject to: notes at:
[18:50:17] Roman Danyliw_web_855 joins the room
[18:50:29] James Galvin_web_257 joins the room
[18:50:54] Christian Amsüss_web_994 joins the room
[18:51:34] Greg Schumacher_web_404 joins the room
[18:52:17] Michael Breuer_web_217 joins the room
[18:52:59] mcr joins the room
[18:53:16] Robert Moskowitz_web_831 joins the room
[18:53:26] Robert Moskowitz joins the room
[18:54:03] Christian Amsüss_web_994 leaves the room
[18:54:06] Hannes Tschofenig_web_782 joins the room
[18:54:14] Christian Amsüss_web_727 joins the room
[18:54:52] <mcr> Hi, I'll be your jabber scribe.
[18:54:57] Samuel Weiler_web_833 joins the room
[18:55:06] Carlos Silva_web_297 joins the room
[18:55:11] Jonathan Hammell_web_195 joins the room
[18:55:39] Michael Jenkins_web_486 joins the room
[18:55:47] Wei Pan_web_524 joins the room
[18:56:06] Wataru Ohgai_web_514 joins the room
[18:56:17] Gustavo Lozano_web_975 joins the room
[18:56:33] <Robert Moskowitz> IPsec from decades ago.
[18:56:44] Russ Housley_web_112 joins the room
[18:56:50] Jiankang Yao_web_813 joins the room
[18:56:51] Rikard Höglund_web_981 joins the room
[18:56:51] Paul Wouters_web_335 joins the room
[18:56:56] Robin Wilton_web_797 joins the room
[18:57:05] Kerry Lynn_web_926 joins the room
[18:57:07] Marco Tiloca_web_382 joins the room
[18:57:14] Tadahiko Ito_web_793 joins the room
[18:57:23] Scott Rose_web_258 joins the room
[18:57:28] <Paul Wouters_web_335> mcr could use more volume
[18:57:33] Dieter Sibold_web_416 joins the room
[18:57:39] Rich Salz_web_963 joins the room
[18:57:41] Tero Kivinen_web_898 joins the room
[18:57:52] Dan Harkins_web_918 joins the room
[18:57:55] Takahiro Nemoto_web_779 joins the room
[18:57:56] Ash Wilson_web_447 joins the room
[18:57:58] <Robert Moskowitz> Michael, who else besides you and I were at the 1st interop?  Was Tero there?  Oh, Dan was part of it...
[18:57:58] <mcr> okay, I'll tweak my gain.
[18:58:05] Peter Campbell_web_129 joins the room
[18:58:09] Jacques Latour_web_800 joins the room
[18:58:14] <Paul Wouters_web_335> still too soft
[18:58:15] SeongHan Shin_web_962 joins the room
[18:58:17] Nicklas Pousette_web_302 joins the room
[18:58:18] Shumon Huque_web_844 joins the room
[18:58:19] <Paul Wouters_web_335> yes
[18:58:28] Eckard Bogenfeld_web_391 joins the room
[18:58:34] Eckard Bogenfeld_web_391 leaves the room
[18:58:41] <Robin Wilton_web_797> @MCR volume is good  for me
[18:58:41] Jim Fenton_web_913 joins the room
[18:58:41] Stefan Santesson_web_694 joins the room
[18:58:50] Taiji Kimura_web_179 joins the room
[18:58:57] Tomofumi Okubo_web_550 joins the room
[18:58:59] Brendan Moran_web_410 joins the room
[18:59:04] Benjamin Kaduk_web_525 joins the room
[18:59:05] <mcr> okay. Gain at 122%....  I'll turn my fan (aka "Swamp cooler") off when I want to talk.
[18:59:22] Rohit Abhishek_web_796 joins the room
[18:59:23] Dieter Sibold_web_416 leaves the room
[18:59:27] Burt Kaliski_web_676 joins the room
[18:59:28] fightingnemo joins the room
[18:59:31] Dieter Sibold_web_897 joins the room
[18:59:35] Andrew S_web_110 joins the room
[18:59:37] <Robert Moskowitz> More time for dinner.
[18:59:43] Daniel Migault_web_149 joins the room
[18:59:48] Steve Olshansky_web_576 joins the room
[18:59:49] Brian Haberman_web_630 joins the room
[18:59:54] Benjamin Schwartz_web_219 joins the room
[19:00:00] Michael Rosa_web_855 joins the room
[19:00:02] Kazunori Fujiwara_web_339 joins the room
[19:00:02] Andrew S_web_110 leaves the room
[19:00:08] Phillip Hallam-Baker_web_964 joins the room
[19:00:12] joins the room
[19:00:15] Timothy Panton_web_365 joins the room
[19:00:17] Andrew S_web_695 joins the room
[19:00:18] Yuji Koyama_web_703 joins the room
[19:00:30] Xavier de Foy_web_257 joins the room
[19:00:31] Dieter Sibold_web_897 leaves the room
[19:00:35] <mcr> Not seeing Jim Reid in the list. Anyone see him this week?
[19:00:39] Dieter Sibold_web_414 joins the room
[19:00:48] Xavier de Foy_web_257 leaves the room
[19:00:49] <Rich Salz_web_963> he was at dispatch IIRC
[19:00:56] Carlos Silva_web_297 leaves the room
[19:01:03] Jon Peterson_web_575 joins the room
[19:01:08] Joseph Salowey_web_262 joins the room
[19:01:09] Ines Robles_web_189 joins the room
[19:01:13] Jaime Jimenez_web_205 joins the room
[19:01:14] Francisco Arias_web_359 joins the room
[19:01:15] Peter Koch_web_233 joins the room
[19:01:17] Trent Adams_web_285 joins the room
[19:01:22] Jorge Cano_web_786 joins the room
[19:01:28] Nicklas Pousette_web_302 leaves the room
[19:01:31] Ash Wilson joins the room
[19:01:31] dkg joins the room
[19:01:33] Daniel Gillmor_web_666 joins the room
[19:01:38] Eric Orth_web_112 joins the room
[19:01:39] Lucy Lynch_web_256 joins the room
[19:01:46] Shane Kerr_web_177 joins the room
[19:01:49] Carlos Silva_web_586 joins the room
[19:01:58] Todd Herr_web_749 joins the room
[19:02:04] Bill Woodcock_web_810 joins the room
[19:02:06] Valery Smyslov_web_923 joins the room
[19:02:09] Qiaoyu Deng_web_338 joins the room
[19:02:20] <mcr>
[19:02:24] Steffen Fries_web_125 joins the room
[19:02:27] Pieter Kasselman_web_736 joins the room
[19:02:33] කෙසර රත්නායක_web_938 joins the room
[19:02:59] Bill Woodcock joins the room
[19:03:00] Ulrich Wisser_web_448 joins the room
[19:03:03] Bill Woodcock leaves the room: Paris
[19:03:22] <Robin Wilton_web_797> I'll contribute to note-taking if that would help - but don't let me stop anyone else having a go.
[19:03:30] Göran Selander_web_573 joins the room
[19:03:31] Diego Lopez_web_106 joins the room
[19:03:38] <Robin Wilton_web_797> yup
[19:03:46] Kohei Isobe_web_232 joins the room
[19:03:52] Tim Cappalli_web_524 joins the room
[19:03:54] Robert Wilton_web_579 joins the room
[19:04:11] Diego Lopez_web_106 leaves the room
[19:04:37] Qiaoyu Deng_web_338 leaves the room
[19:04:43] Carlos Silva_web_586 leaves the room
[19:04:46] Carl Mehner_web_318 joins the room
[19:04:48] Carlos Silva_web_481 joins the room
[19:05:03] Corey Bonnell_web_682 joins the room
[19:05:05] Qiaoyu Deng_web_933 joins the room
[19:05:07] Leif Johansson_web_862 joins the room
[19:05:13] <Shane Kerr_web_177> Jim was also at dnsop, I think.
[19:05:26] <Brian Haberman_web_630> Yes, Jim was at DNSOP.
[19:05:41] Diego Lopez_web_115 joins the room
[19:05:57] Mohit Sethi_web_155 joins the room
[19:06:26] <Paul Wouters_web_335> no technical controls? what about name constains ?
[19:07:07] Samuel Weiler_web_833 leaves the room
[19:07:19] Erik Nordmark_web_182 joins the room
[19:07:30] Samuel Weiler_web_451 joins the room
[19:07:44] Liang Qin_web_983 leaves the room
[19:07:50] Liang Qin_web_628 joins the room
[19:07:53] <Christian Amsüss_web_727> I see what is meant with Private PKI, but it still sounds weird.
[19:08:01] Kathleen Moriarty_web_823 joins the room
[19:08:06] Peng Liu_web_100 joins the room
[19:08:06] Rolf Sonneveld_web_895 joins the room
[19:08:28] <dkg> Paul Wouters_web_335: are name constraints actually widely deployed?
[19:08:31] Jim Reid_web_405 joins the room
[19:08:32] Peng Liu_web_100 leaves the room
[19:08:37] <Shumon Huque_web_844> WebPKI has no name constraints!
[19:08:54] <Christian Amsüss_web_727> maybe DANISH is a good starting point to get them deployed
[19:08:58] <Hannes Tschofenig_web_782> IoT deployments do not use the WebPKI, as far as I have seen
[19:08:58] <Rich Salz_web_963> sure it does.  Just not used very often.
[19:09:08] <Paul Wouters_web_335> it is specified, and your CA cert can have it
[19:09:09] <dkg> Shumon Huque_web_844: X.509 has name constraints -- are you saying that they would be ignored by web clients that evaluate X.509 certs?
[19:09:19] Vincent Roca_web_295 joins the room
[19:09:23] David Lawrence_web_822 joins the room
[19:09:30] <Jim Reid_web_405> @mcr, I'm here!
[19:09:35] <> Christian Amsüss: a couple of secdispatches ago, IIRC we saw a scheme
that used a public key as something analogous to a (private) PSK...
[19:09:39] <mcr> We used to think that we'd have ubiquitous Enterprise subordinate CAs (with name constraints), but if Enterprises were allowed to run their own subordinate CAs (with connections up to WebPKI), then they might violate CABForum rules.
[19:10:18] Qiaoyu Deng_web_933 leaves the room
[19:10:24] <Shumon Huque_web_844> I guess, my knowledge may be dated. They have them now,? but they are likely not widely used, I'd guess. Please correct me if I'm wrong.
[19:10:33] <dkg> why not XMPP S2S?
[19:10:37] <Rich Salz_web_963> O
[19:10:39] <Paul Wouters_web_335> why would this be covered by cabforum? if you surrender to camforum, might as well take their CA bundle as life
[19:10:48] <mcr> So weird that in my alphabetically sorted list of 100 people in the room, that Jim is not listed....
[19:10:56] <Robert Moskowitz> I am working with a potentially really big private PKI  The International Civil Aviation Authority ( IATF.  They want to have all the certs for all the devices and people in aviation.  At least that which touches on international aviation.
[19:11:03] Daphanie Nisbeth_web_273 joins the room
[19:11:03] <dkg> Paul Wouters_web_335: cabforum is sort of WebPKI by definition, like it or not :(
[19:11:29] Qiaoyu Deng_web_814 joins the room
[19:11:33] Yoshiro Yoneya_web_576 leaves the room
[19:11:39] <Rich Salz_web_963> Name constraints in the WebPKI are almost never used.  I don't know about other PKI's.
[19:11:41] <Paul Wouters_web_335> but here people want private CAs? so then you are out of that context ?
[19:11:45] <Jim Fenton_web_913> @Robert Moskowitz Does that include the PKI for passport data signatures?
[19:11:57] <dkg> just specify this for TLS 1.3 only to avoid the privacy considerations, no?
[19:12:06] <mcr> If a public (CABFORUM) CA signs your Enterprise (subordinate) CA certificate, then they become responsible for your Enterprise actions.  So nobody sells enterprise PKIs unless they parent actually operations (controls) the subordinate CA.
[19:12:09] <Paul Wouters_web_335> rich: never used? but always enforced in validation ?
[19:12:15] <Hannes Tschofenig_web_782> Typically, deployments are siloed by design because IoT devices are purpose built for a specific task. Hence, the private CA.
[19:12:19] <Robert Moskowitz> I believe so.  I have heard it mentioned in at least one of the ICAO DIWG calls.
[19:12:24] <Eric Orth_web_112> Does anybody else keep trying to move the mouse pointer in the middle of the screen?
[19:12:26] Yoshiro Yoneya_web_996 joins the room
[19:12:44] <Shumon Huque_web_844> @dkg - yes, 1.3 would be my recommendation, but the DANE client auth drafts currently support 1.2 also for practical reasons.
[19:12:48] <Rich Salz_web_963> as for NC in validation, I'd guess the code if it exists is latent.  And since it got so little use, probably still has bugs.
[19:13:18] Alessandro Amirante_web_526 joins the room
[19:13:36] <Robert Moskowitz> I know that use of Name Constraints is in the IATF Cert Policy (ver .98 came out last week).
[19:14:17] <mcr> @Paul, the reason why the private CAs are a problem is because of silo effect. Enterprise CAs would help out, if only they were easily trusted (i.e. connected to webpki).
[19:14:51] Jon Peterson_web_575 leaves the room
[19:14:56] Paolo Saviano_web_148 joins the room
[19:15:07] <mcr> Eric, I even try to move mouse pointers when watching the youtube recording...
[19:15:11] Jon Peterson_web_432 joins the room
[19:15:13] Viktor Dukhovni_web_701 joins the room
[19:15:29] Paolo Saviano_web_148 leaves the room
[19:15:53] Takao Kondo_web_266 joins the room
[19:15:56] <Hannes Tschofenig_web_782> There always seems to be the impression that the silos are a problem. This design allows devices to stay simple.
[19:16:50] <Phillip Hallam-Baker_web_964> How much more security does this scheme provide over a change in Web browsers to simply connect to private network IP addresses using a self signed cert without reporting an error to the user?
[19:16:57] Peter Campbell_web_129 leaves the room
[19:17:01] Peter Campbell_web_326 joins the room
[19:17:04] <Phillip Hallam-Baker_web_964> I see a lot of complexity and not much return
[19:17:14] <Phillip Hallam-Baker_web_964> DNS is a poor match to the IoT world
[19:17:25] Peter Campbell_web_326 leaves the room
[19:17:32] <mcr> As to whether NameConstraints are deployed, apparently there was a CVE on IE 7 or something a decade ago where it would fail to do DNS-ID validation correctly if it had done a NameConstraint evaluation.  So, a decade ago, there was enough Enterprise PKI with NameConstraints deployed for this failure to be discovered.  If you told me that Firefox or Chrome didn't do it at all, I would not be surprised, but OpenSSL seems to have code to implement this.
[19:17:46] <> How are you going to manage your browser config?
What do you do when there is no browser in the flow?
[19:17:52] Peter Campbell_web_197 joins the room
[19:17:54] Alessandro Amirante_web_526 leaves the room
[19:17:57] <dkg> does "supplier" mean "IoT vendor" ?  or "software toolkit vendor"?
[19:17:59] Alessandro Amirante_web_510 joins the room
[19:18:00] <mcr> @PHB, this WG is not really aiming at browser issues, I would say.
[19:18:19] Maarten Aertsen_web_815 joins the room
[19:18:33] <Phillip Hallam-Baker_web_964> @mcr, so even easier?
[19:19:17] <mcr> ManySecured WG SUIB ( is supposed to release the problem statement document, perhaps today, which does care about the situation that you describe (connecting to RFC1918 / ULAs with certificates without errors)
[19:19:24] <Paul Wouters_web_335> dane is just not a good tool for devices that are basically not meant to be publicly registered
[19:19:49] <Paul Wouters_web_335> all these private devices publishing stuff in public dns is just a bad fit
[19:19:52] <Phillip Hallam-Baker_web_964> @Paul, but we have a hammer....
[19:19:53] <Wes Hardaker_web_711> thees are publicly registered in the dns
[19:20:12] කෙසර රත්නායක_web_938 leaves the room
[19:20:16] Ching-Heng Ku_web_112 joins the room
[19:20:16] කෙසර රත්නායක_web_396 joins the room
[19:20:29] <Paul Wouters_web_335> i guess these could be private DNS trees :P
[19:20:37] <Shumon Huque_web_844> One thing I want to mention: the DANE client authentication drafts have wider applicability than the IOT use case this BoF is focussed on. Folks from those other application spaces are also interested in seeing some of this work move forward.
[19:21:03] <Wes Hardaker_web_711> we would love to hear from all people with alternate use cases
[19:21:20] Paolo Saviano_web_731 joins the room
[19:21:25] <Robert Moskowitz> I am looking at this to mesh with DRIP.  Use case sometime soon?
[19:21:35] <> I wonder how the need to trust the manufacturer's issuance compares
between this scheme and, e.g., BRSKI
[19:21:36] Paolo Saviano_web_731 leaves the room
[19:21:42] Alessandro Amirante_web_510 leaves the room
[19:21:42] Paolo Saviano_web_699 joins the room
[19:22:02] <Paul Wouters_web_335> shumon: what is needed beyond the existing RFCs for TLSA records to do mutual TLS auth ?
[19:22:15] <mcr> @kaduk, I think that it's a mixed bag of pluses and minuses.
[19:22:33] <Rich Salz_web_963> Looks like 2016 was when NC support was added to openssl.
[19:22:34] <Russ Housley_web_112> What happens when mfr stops publishing the DNS record?
[19:22:37] <Shumon Huque_web_844> @paulwouters - the client auth drafts mentioned in this preso.
[19:22:59] Cullen Jennings_web_680 joins the room
[19:23:06] <mcr> *clarifying* questions!
[19:23:24] <mcr> @Russ, that's one of the minuses :-)
[19:23:33] <Robert Moskowitz> With Unmanned Aircraft Systems (UAS), there are the CTA 2063-A serial numbers that could easily fit within DNS and then link to this work.  This is on top of DRIP HHITs.
[19:24:05] Paolo Saviano_web_699 leaves the room
[19:25:00] <Brendan Moran_web_410> That concern applies equally to where the device's firmware updates come from. The answer is *probably* key escrow
[19:25:05] <Wes Hardaker_web_711> isn't that a similar problem with long term client TLS certs too right?  anything with a timeline can age out.
[19:25:22] <Jim Fenton_web_913> @Russ, isn't that the same situation as when mfr stops supporting their cloud service?
[19:25:29] <Shumon Huque_web_844> To Viktor's 1st question, I'm not plugged into IOT companies currently, but back in ~~2015/2016 when I was originally working on these drafts at Verisign, we were definitely talking to IOT companies interested in this.
[19:26:41] Rolf Sonneveld_web_895 leaves the room
[19:28:34] <Phillip Hallam-Baker_web_964> @Jim yes it is, but that is also a real issue for the IoT world as my crates of dead devices prove.
[19:28:35] <Paul Wouters_web_335> i sometimes had to off -> on it again to get it to work
[19:29:15] Liang Qin_web_628 leaves the room
[19:29:21] Liang Qin_web_906 joins the room
[19:29:24] <Jim Fenton_web_913> @phill Agreed, just pointing out this isn't a new problem.
[19:29:54] Jim Fenton_web_913 leaves the room
[19:30:31] <Hannes Tschofenig_web_782> FYI: The IAB published a nice document that explains design patterns of IoT devices and the document also explains how silos can be dealt with (see Section 2.4 of
[19:30:59] Lucy Lynch_web_256 leaves the room
[19:31:06] <Tim Cappalli_web_524> DIDs solve the portability issues
[19:31:06] Paolo Saviano_web_144 joins the room
[19:31:08] Lucy Lynch_web_798 joins the room
[19:31:18] <Tim Cappalli_web_524> And key rotation
[19:31:20] Paul Lanzi_web_277 joins the room
[19:31:25] <Jacques Latour_web_800> those domains have to be DNSSEC signed, to a transfer would go insecure and TLSA would be servfail
[19:32:02] <Lucy Lynch_web_798> Thanks
[19:32:18] <Hannes Tschofenig_web_782> @Tim: DID -- decentralized identifiers ?
[19:32:22] <Tim Cappalli_web_524> Yes
[19:32:32] <Hannes Tschofenig_web_782> Blockchain
[19:32:43] <Tim Cappalli_web_524> Not necessarily
[19:32:43] <Robin Wilton_web_797> Hannes, go to your room.
[19:32:47] <Shumon Huque_web_844> @jacques - we are working on solving the problem of non-disruptive transfer of signed zone between operators (for the authorized use case).
[19:32:51] <Phillip Hallam-Baker_web_964> @hannes one of the few cases blockchain makes sense.
[19:32:56] <Tim Cappalli_web_524> DIDs do not have to be anchored to a ledger
[19:32:56] <Russ Housley_web_112> At first, the new owner could resign the same (or different) content
[19:32:57] <Robin Wilton_web_797> ;^p
[19:33:14] <Phillip Hallam-Baker_web_964>
[19:33:22] Maarten Aertsen_web_815 leaves the room
[19:33:26] Maarten Aertsen_web_553 joins the room
[19:33:33] <Hannes Tschofenig_web_782> Thanks, Phil. Have not seen that draft before
[19:33:37] <mcr> I guess it depends upon whether the new owner cared about the stuff, or if they were just acquiring assets for resale.
[19:33:39] <Tim Cappalli_web_524> Service endpoints and keys can be updated in the DID doc in the event of an organizational change
[19:33:43] <Paul Wouters_web_335> my only issue here is that this problem statement is incompatible with "a non-dnssec variant much be supported"
[19:33:53] <Rich Salz_web_963> > one of the few cases blockchain makes sense.Time for you to leave now, Phil.
[19:33:54] Carlos Silva_web_481 leaves the room
[19:33:55] <Phillip Hallam-Baker_web_964> @hannes, I have running code
[19:33:58] Paolo Saviano_web_144 leaves the room
[19:34:09] <Hannes Tschofenig_web_782> +1
[19:34:12] <mcr> @Paul, we removed the "non-dnssec variant" from the charter for that reason.
[19:34:19] <Phillip Hallam-Baker_web_964> @rich, I tried to buy out the patent in 2005
[19:34:32] <Paul Wouters_web_335> oh ok. i see
[19:34:33] Gustavo Lozano_web_975 leaves the room
[19:34:40] <Phillip Hallam-Baker_web_964> @rich haber stornetta hash chain
[19:34:52] <Tim Cappalli_web_524> The issue around a domain disappearing and breaking "stuff" has existed in the user identity world for years and DIDs + VCs are the solution
[19:34:54] Gustavo Lozano_web_580 joins the room
[19:35:12] <Tim Cappalli_web_524> Replace DNS with OpenID provider
[19:35:13] <Phillip Hallam-Baker_web_964> Signing a DNSSEC zone is a non trivial cost
[19:35:14] <dkg> this problem statement very clearly focuses on IoT and not the SMTP use case
[19:35:56] <Robert Moskowitz> Separate providers.   I think.
[19:36:01] Phillip Hallam-Baker_web_964 leaves the room
[19:36:12] Phillip Hallam-Baker_web_638 joins the room
[19:36:39] <Phillip Hallam-Baker_web_638> @dkg, isnt SMTP done in DANE??
[19:36:57] Hugo Salgado_web_110 joins the room
[19:36:59] <Phillip Hallam-Baker_web_638> @dkg like, is DANE used for anything other than SMTP STARTTLS ???
[19:37:06] Francois Ortolan_web_208 joins the room
[19:37:16] <Paul Wouters_web_335> sshfp ? :P
[19:37:32] <Paul Wouters_web_335> i guess that is not "dane" as in "tlsa"
[19:37:54] <Shumon Huque_web_844> @dkg - client authentication in SMTP Transport security could be accommodated by the drafts that will be worked on in this group (and was one of the original use cases for the drafts).
[19:37:58] <Rich Salz_web_963> > Replace DNS with OpenID providerFB, Google, who else has one that will last?
[19:38:05] <Shumon Huque_web_844> But you're right, the charter is focussed on IOT right now.
[19:38:38] <dkg> Shumon Huque_web_844: i agree, that's what i'm most interested in.  but this "problem statement" on slide 9 misses that problem.
[19:38:40] <Tim Cappalli_web_524> Microsoft is the largest OP in the world ;)
[19:38:55] <Roman Danyliw_web_855> What's a better phrase than "application owners"?
[19:39:07] Alessandro Toppi_web_725 leaves the room
[19:39:09] <dkg> PHB: dane is used in SMTP STARTTLS for *server* authentication; not for client authentication.
[19:39:12] Alessandro Toppi_web_326 joins the room
[19:39:14] <dkg> (as far as i'm aware)
[19:39:16] <Shumon Huque_web_844> @dkg - I think folks wanted the BoF to be focussed on one specific problem for scope reasons.
[19:39:29] <Paul Lanzi_web_277> audio is pretty broken up
[19:39:31] <dkg> still choppy, Bob ☹
[19:39:39] <Phillip Hallam-Baker_web_638> @dkg... ok but why would it be different????
[19:39:41] <Shumon Huque_web_844> I am okay with that, as long as it doesn't exclude other application uses for DANE client auth.
[19:39:41] <Cullen Jennings_web_680> Perhaps mute if you are not speaking as the audio sounds like crap with several people contributing
[19:39:44] <Stefan Santesson_web_694> Get new mike Bob
[19:39:47] <Tero Kivinen_web_898> sounds like bad networks connection...
[19:39:58] <dkg> Bob sounded like this yesterday too
[19:40:04] <Stefan Santesson_web_694> Maybe this is how Bob talks?
[19:40:11] <Robin Wilton_web_797> That makes note-taking quite challenging ;^,
[19:40:13] <Roman Danyliw_web_855> Bob, can you type up your feedback?
[19:40:15] <Phillip Hallam-Baker_web_638> @dkg, I never understood the client cert/server cert fetish and I kinda created it.
[19:40:22] <Robert Moskowitz> I am going to have to do meetecho on its own system.  :(
[19:40:31] <Jaime Jimenez_web_205> probably should mute everyone else except whomever is speaking...
[19:40:37] <Hannes Tschofenig_web_782> Maybe bad Internet connectivity
[19:40:57] <Shumon Huque_web_844> @phb - you can relinquish the cert fetish by doing DANE and raw public keys :)
[19:40:58] <Phillip Hallam-Baker_web_638> @dkg VeriSign Class 1+2 were for authenticating PEOPLE, 3 was for organizatrions
[19:41:04] <dkg> PHB: are you saying that we *shouldn't* use this particular model for SMTP STARTTLS client auth?
[19:41:08] <Robert Moskowitz> The use case text is really clear to me, but I think I am too close to this problem.
[19:41:19] <mcr> Shuman, rather than "relinquish", I think you mean "atone" :-)
[19:41:29] <Shumon Huque_web_844> Ok, that's better @mcr!
[19:41:32] Rohit Abhishek_web_796 leaves the room
[19:41:39] Rohit Abhishek_web_481 joins the room
[19:41:53] <Phillip Hallam-Baker_web_638> @dkg, I am saying that if DANE makes sense, whether you use them for TLS server or client auth should make no real difference.
[19:42:18] <Phillip Hallam-Baker_web_638> @dkg, maybe you have an SMTP extension to write...
[19:42:36] meetecho-alex leaves the room
[19:42:37] <Ash Wilson> Hi @bill I would love to hear more about your use case
[19:42:39] <dkg> PHB, that's not very helpful if we're trying to specify bytes on the wire and intended semantics
[19:42:46] Dawei Fan_web_164 joins the room
[19:42:47] <Robert Moskowitz> I see too often solved with federated PKI.  Maybe not a bad thing, but then you get lots of federations with different policies which drive the auditors crazy and drive up the auditing cost to meet a CP.
[19:42:47] alexamirante joins the room
[19:43:17] <Paul Lanzi_web_277> we can hear you, yes
[19:43:40] <dkg> i mean, they're all roughly morally equivalent.  the challenge is getting conensus on interoperability (as in all the IETF)
[19:43:42] Erik Nordmark_web_182 leaves the room
[19:43:46] Erik Nordmark_web_957 joins the room
[19:43:57] Oliver Borchert_web_465 joins the room
[19:44:10] <Phillip Hallam-Baker_web_638> @dkg, what I am saying is that SMTP STARTTLS, write me a check, give me three weeks and I could write a spec that 90% of people would be completely happy with. It is a nice easy closed problem. The IoT use cases are a complete S...S....
[19:44:17] Diego Lopez_web_115 leaves the room
[19:45:07] <Bill Woodcock_web_810> @Wes, I'm fine with what's there, but I guess I'd deemphasize the IoT stuff to the degree necessary to make clear that there are also a lot of different use cases, and a broad base of support.
[19:45:51] <Paul Lanzi_web_277> +1 re: not-IoT specific
[19:45:56] Maddy Conner joins the room
[19:46:05] <Bill Woodcock_web_810> I have nothing against the IoT thing, go them!  But I'd like to make clear that's not the only use case.
[19:46:23] <Robert Moskowitz> I am looking at: and not seeing IoT in the charter.  What am I missing?
[19:46:46] <Tero Kivinen_web_898> My understanding is that e are talking about devices who currently connect to the cloud services using TLS...
[19:47:08] <mcr> Robert, that's the canonical spot.
[19:47:26] <Shane Kerr_web_177> There's no need to change the client certificate on any schedule, is there? That's more of a TLS issue than a DNS issue, right?
[19:47:28] <Wes Hardaker_web_711> @bob: see screen for the iot text
[19:47:31] <mcr> is latest.
[19:47:44] <Wes Hardaker_web_711> but that's more problem space
[19:48:00] Glen (AMS IT) joins the room
[19:48:11] <dkg> i think the previous speaker seemed to assume that DNSSEC resigning schedules would somehow force a key/cert refresh on every client named in the zone
[19:48:15] <Jacques Latour_web_800> a cloud provider could validate the cert/key presented via a TLSA _device for that identity
[19:48:15] <Shumon Huque_web_844> @shane - yes, I agree. I was wondering where the once per quarter statement from the current speaker came from.
[19:48:18] <Robert Moskowitz> the missmatch on slides and github charter was giving me problems..
[19:48:21] <dkg> i don't think that's correct, is it?
[19:48:35] Christian Amsüss_web_727 leaves the room
[19:48:41] <Rich Salz_web_963> so does this presume a split-horizon DNS?
[19:48:43] <Shumon Huque_web_844> @dkg - yes, I don't think that's correct.
[19:48:44] <mcr> I agree that I don't think that it's correct to assume the device has to be involved once per quarter.
[19:48:45] Christian Amsüss_web_165 joins the room
Room Configuration
[19:48:56] Chatroom configuration modified
[19:48:59] <mcr> no split horizon DNS would be useful in my opinion.
[19:49:06] Dawei Fan_web_164 leaves the room
[19:49:12] Dawei Fan_web_224 joins the room
[19:49:17] <Robert Moskowitz> On a coin battery IoT, I do not see full certs at all.  Do they even have the CPU/Memory for this?
[19:49:29] <Rich Salz_web_963> @mcr, please add punctation, can't understand "no split horizon DNS"
[19:49:44] <Jaime Jimenez_web_205> So, to clarify, as per rfc7228 anything less than class 2 devices are out of scope?
[19:50:10] <Robert Moskowitz> IMHO
[19:50:28] <Bill Woodcock_web_810> @mcr: Yes, split horizon DNS is a huge driver for DANE client auth in the DNS space.
[19:50:31] <Paul Wouters_web_335> I uhm... agree with phb a lot :)
[19:50:33] <dkg> Rich Salz_web_963: i don't think this depends on split-horizon DNS
[19:50:48] <mcr> @Rich, I think that split horizon DNS would not be helpful in DANISH.  I guess one could AXFR the manufacturer zones into your walled garden, but that seems really difficult to manage.
[19:50:52] <Rich Salz_web_963> so Akamai's air conditioning systems will be in the public DNS?
[19:51:01] <Sandoche Balakrichenan_web_926> In a LoRaWAN Scenario, where the IoT Device is one of the most constrained.. the DANE use-case is useful.. when the Gateway recevies a Join Request frol the IoT device.. it needs to interact with multiple servers such as the Application Server and AAA server to securely interact for the IoT device booststrapping.. This is where DANE client/Server authentication is useful.
[19:51:15] <mcr> @Bill, split-horizon is what is pushing us to do something different, or ??
Room Configuration
[19:51:16] Chatroom configuration modified
[19:51:16] <Bill Woodcock_web_810> (Where split horizon can mean different clients get different answers, or some clients get answers, while unauthorized ones don't get to use the server for amplification attacks.
[19:51:30] Glen (AMS IT) leaves the room
[19:51:40] Glen (AMS IT) joins the room
[19:51:42] <Paul Wouters_web_335> rich: great ransomware.  pay or we disable your airco :)
[19:52:14] <Rich Salz_web_963> I'm now very confused.  Does DANE for client-auth require that the client be in DNS?
[19:52:23] <Hannes Tschofenig_web_782> Yup
[19:52:26] Gustavo Lozano_web_580 leaves the room
[19:52:27] <Bill Woodcock_web_810> @mcr: As people move to work-from-home and endpoint security, there's huge demand for split horizon that's not based on source IP address.  And DNS amplification attacks are a problem for "public" recursive resolver operators.  (Also, authenticating that the user is a paying customer).
[19:52:31] <dkg> Rich Salz_web_963: its *name* has to be in the DNS, but its *address* does not.
[19:52:32] Gustavo Lozano_web_764 joins the room
[19:52:34] <mcr> @Rich, the certificates for the chillers that Akamai bought from Frobit Inc Coolers, will be in  Whether that zone can be queries by the world is another question.
[19:52:36] Maddy Conner leaves the room
[19:52:37] <David Lawrence_web_822> Validity really does not have to be the minimum of the parents.
[19:52:40] alexamirante leaves the room
[19:52:46] Maddy Conner joins the room
[19:52:53] cabo joins the room
[19:52:54] meetecho-alexamirante joins the room
[19:53:03] <mcr> @Bill, split-horizon DNS is dead for me.  work-from-home killed it.
[19:53:06] <Rich Salz_web_963> So if the DNS answer varies depending on who asks, let's call that split-horizon.
[19:53:18] කෙසර රත්නායක_web_396 leaves the room
[19:53:20] <Bill Woodcock_web_810> Right.
[19:53:25] <mcr> @Rich, it's not what we built as split-horizon back in 1995, but okay.
[19:53:29] <Hannes Tschofenig_web_782> @MCR: If the entries in the DNS cannot be queried by everyone then how is it different from a private CA deployment?
Room Configuration
[19:53:30] Chatroom configuration modified
[19:53:36] <Viktor Dukhovni_web_701> I can answer Ben's question.
Room Configuration
[19:53:43] Chatroom configuration modified
[19:53:48] <mcr> @Hannes, I didn't say they couldn't. I said it was a different question.
[19:53:55] <Jacques Latour_web_800> right, the validation of the identity via the DNS  { public or private }, not any information about IoT devices in DNS
Room Configuration
[19:54:11] Chatroom configuration modified
[19:54:12] <Bill Woodcock_web_810> @mcr: People need the "split horizon" effect...  But yeah, we've completely gotten past source IP being a useful differentiator.  TLS client cert, on the other hand, is an excellent differentiator.  And DANE is the correct way to find that.
[19:54:20] <Bill Woodcock_web_810> Or TLS in-band, but we need both.
Room Configuration
[19:54:48] Chatroom configuration modified
[19:54:54] <Tim Cappalli_web_524> If only there were a standardized dereferenceable identifier format....
[19:54:55] <Brendan Moran_web_410> I support the use of URIs to identify devices.
[19:54:56] <Ash Wilson> There are updates required for the TLS handshake, defined in the drafts
[19:55:17] Qin Wu_web_388 joins the room
[19:55:21] Dawei Fan_web_224 leaves the room
[19:55:35] <Rich Salz_web_963> I didn't realize the devices would have certs and identities from the manufacturer.
[19:55:54] <Robin Wilton_web_797> Anyone else losing audio from Viktor?
[19:55:59] <Wes Hardaker_web_711> no
[19:56:03] <Hannes Tschofenig_web_782> Works well
[19:56:36] <mcr> @Rich, that's the point. The manufacturer provisions identities, and rather than do a transfer of ownership via certificate issuance (LDevID, with BRSKI, etc...), they put the identity in a namespace they control.
[19:56:49] <Rich Salz_web_963> Assuming we don't want 'split horizon', then yeah, I don't want to have to trust Carrier's DNS implementation to only give valid answers to the right people.  This is why many orgs offload DNS services to CDN's etc.
[19:56:59] <Robin Wilton_web_797> uh oh
[19:56:59] <Robin Wilton_web_797> Could someone capture this for the notes? I'll try and fix my bandwidth :^(
[19:57:00] <Robert Moskowitz> @Rich, as always it depends.  If the device has the umph, there is 802.1AR that some are using.  But the CA is their own.
[19:57:04] <Robin Wilton_web_797> sorry, my connection has dropped
[19:57:10] <Robin Wilton_web_797> OK - back
[19:57:35] <Dan Harkins_web_918> does this have to be TLS-specific? This sounds useful for a server to obtain a device's public key which is useful for TLS but does not necessarily mean you're doing TLS.
[19:57:46] <Tim Cappalli_web_524> ^^^
[19:57:56] Vincent Roca_web_295 leaves the room
[19:58:02] <Phillip Hallam-Baker_web_638> @dan, DANE was limited to TLS. Against my attempts to prevent that
[19:58:12] <mcr> @Dan, I don't think so, but we needed an extension to TLS to be able to carry the name and not the certificate.
[19:58:14] <Dan Harkins_web_918> @PHB :-(
[19:58:14] <Robert Moskowitz> Better not be TLS specific.  e.g. IKE should use it.  And HIP can.
[19:58:48] <Jacques Latour_web_800> exactly, see our implementation:
[19:59:11] <Robert Moskowitz> So we need TLS 1.3 drafts.  Do other uses need updates?
[19:59:12] <Dan Harkins_web_918> This discussion just seems very TLS-specific and I'd like to make sure it's not a constraint.
[19:59:21] <Christian Amsüss_web_165> on DANE being limited to TLS: Is there anything that stops this WG's results from being applied to TLSA-parallel records (SSHFP etc)?
[19:59:49] <Christian Amsüss_web_165> s/parallel/analogous/
[19:59:55] Jorge Cano_web_786 leaves the room
[19:59:59] Jorge Cano_web_247 joins the room
[20:00:01] <Robert Moskowitz> @Dan, because TLS needs fixes for this.  How will IKE fair?  Tero?
[20:00:11] Robin Wilton_web_797 leaves the room
[20:00:25] Jorge Cano_web_247 leaves the room
[20:00:29] Jorge Cano_web_611 joins the room
[20:00:48] Robin Wilton_web_515 joins the room
[20:01:04] <dkg> i want to hear why it's not deployable
[20:01:04] leaves the room
[20:01:31] <Robert Moskowitz> I want client DANE in DNS.  Each application will have its way to add clients to DNS.
[20:02:08] <David Lawrence_web_822> boy yeah because only experts are using pki
[20:02:14] Patrick Tarpey_web_413 joins the room
[20:02:15] <Dan Harkins_web_918> @Bob, it's more than just IKE. Some places won't give you IP connectivity without a credential so doing TLS to get a credential is kind of a catch-22
[20:03:11] <Robert Moskowitz> @Dan, that is part of the TLS fix, as I understand.  To allow the server to get that client cert from DNS/DANE.  At least that is my reading of the draft.
[20:03:14] Robin Wilton_web_515 leaves the room
[20:03:35] <Shumon Huque_web_844> I don't think DANE is limited to TLS. We had an object/message security use case in the original BoF, but the current charter was scoped down to try to get a focussed charter out of the door.
[20:03:58] Ali Hussain_web_652 joins the room
[20:04:07] Scott Rose_web_258 leaves the room
[20:04:10] <Robert Moskowitz> @Viktor.  Iot will often be a once-in-a-lifetime use.
[20:04:17] Michael Richardson_web_797 leaves the room
[20:04:21] Michael Richardson_web_575 joins the room
[20:04:37] Scott Rose_web_361 joins the room
[20:04:47] Pieter Kasselman_web_736 leaves the room
[20:04:49] Robin Wilton_web_830 joins the room
[20:04:55] <Robert Moskowitz> @Viktor with clients in DNS.  We are working on that for Unmanned Aircraft Systems (UAS) in DRIP.
[20:05:48] Joseph Salowey_web_262 leaves the room
[20:05:55] <dkg> Rich, i don't understand that argument.  i think you're saying "certs are too hard for these folks, why would DNSSEC be easier?"  seems to me like Certs are hard because there are too many confusing conflicting options.  if this specifies a narrow, clear path toward authentication, then it should reduce the complexity.  "all" it requires is publishing and maintaining a signed DNSSEC zone itself.
[20:06:35] <mcr> @dkg, and you can outsource the maintaining DNSSEC part to a number of places.
[20:06:39] <Rich Salz_web_963> no.  I'm saying you have to do keys in DNS, from the largest mfr down to the smallest $5 part mfr.  I don't see it happening.
[20:06:55] <Rich Salz_web_963> "anybody can set up an email server"  'nuff said.
[20:06:55] Dawei Fan_web_925 joins the room
[20:06:57] Glen (AMS IT) leaves the room
[20:07:10] <mcr> @Rich, no, not for every single thing.  Why would this be the only solution the world would ever see?
[20:08:03] <Dan Harkins_web_918> Matter is a closed protocol from a vendor consortium.
[20:08:07] <mcr> I would reply, but I can't get audio.
[20:08:09] <mcr> reloading.
[20:08:10] Michael Richardson_web_575 leaves the room
[20:08:11] <Bill Woodcock_web_810> @Rich, not at all.  The VAST majority of people with DNSSEC signed records don't even know that DNSSEC exists.
[20:08:17] Michael Richardson_web_515 joins the room
[20:08:22] <Bill Woodcock_web_810> It happens at lower layers of the service-provider stack.
[20:08:47] <Bill Woodcock_web_810> I can't imagine letting end-users muck about in any space I was responsible for keeping working.
[20:08:52] <Hannes Tschofenig_web_782> .. where the vendors are Apple, Google, Amazon, ....
[20:09:05] Stephan Emile_web_766 joins the room
[20:09:26] <mcr> Apparently my mic has disappeared.  I will write a comment about MATTER to list, but the summary is twofold:  a) MATTER is about home, and likely won't scale to buildings.  b) the spec is not yet public, so it's hard for many people to know what it's about.
[20:09:40] <Rich Salz_web_963> Are they?  Or is it people who do heating systems, office lighting systems, etc?
[20:10:06] <Bill Woodcock_web_810> @Hannes, no, you've just named three companies which are both customers and medium-sized providers, among many, many others.
[20:10:12] <Tim Cappalli_web_524> Things designed for home never stay at home.
[20:10:15] <Rich Salz_web_963> Shrug.  I'll stop trying to rain in the parade you folks are having.
[20:10:38] Maddy Conner leaves the room
[20:11:12] <Bill Woodcock_web_810> @Rich, I completely agree that the vast majority of folks shouldn't try to look under the hood of this thing.  That's also true of DNSSEC generally, and CA certs.  But this is desperately needed, and has been for a long time.
[20:11:31] <Bill Woodcock_web_810> Whereas CA certs have desperately needed to die for a long time.
[20:11:33] <Hannes Tschofenig_web_782> The point is that these are relevant companies in the IoT space.
[20:11:34] <Robert Moskowitz> @Brenden, these end devices can use RPK to dodge the overhead of X.509.  then you need a "nice" e2e protocol within a home.  See, for example, Zwave 2.0 (Disclaimer, I worked in it).
[20:11:39] <Shane Kerr_web_177> Changing the certificate on the device also involves renaming it. That's not lock-in, IMHO.
[20:11:44] <mcr> @Tim, it's true. And I fully expect MATTER to wind up running the local Hair Salon, but not the 10,000 Tim Hortons or the systems in the mall or the Chrysler Building.
[20:11:48] <Phillip Hallam-Baker_web_638> says the employee of the company that obsoleted my revolv hub stranding $3000 of equipment built into walls.
[20:12:09] <Tim Cappalli_web_524> Orphan devices is another use case solved by DIDs
[20:12:17] <Shumon Huque_web_844> @benschwartz - this doesn't require the IOT client names to be provisioned in the manufacturer's namespace. It can be in your own.
[20:12:23] <Tim Cappalli_web_524> Aka the OpenID provider that disappears overnight.
[20:12:28] Jim Fenton_web_594 joins the room
[20:12:31] Jaime Jimenez_web_205 leaves the room
[20:12:34] <Bill Woodcock_web_810> @Hannes: I honestly don't care one whit whether IoT folks use this or not, I need it for actual DNS.
[20:12:37] Jaime Jimenez_web_696 joins the room
[20:12:42] <Shane Kerr_web_177> Agree with Shumon. I think it does make sense to document how this would be done though.
[20:12:59] <Tim Cappalli_web_524> Yes it is trivial!
[20:13:06] <mcr> @Ben, do you mean devices abandonned by manufacturer?
[20:13:06] <Brendan Moran_web_410> @Benschwartz I agree. IoT devices should outlive their manufacturers!
[20:13:07] <Shumon Huque_web_844> @shane - yes, that's worth spelling out.
[20:13:12] <Bill Woodcock_web_810> Heh, sure it's trivial to re-target control of IoT devices...  Botmasters do it all the time.  :-)
[20:13:16] <Hannes Tschofenig_web_782> @Bill. That's totally fine. The question was how does DANISH relate to Matter and what is Matter
[20:13:17] <Tim Cappalli_web_524> That's exactly the point of service endpoints in a DID doc
[20:13:23] <Eric Orth_web_112> +1 to Ben's point.  It's an item at the level of "we need to develop a way to solve this problem", so it should be in the charter.
[20:13:27] Alexander Mayrhofer_web_383 joins the room
[20:13:40] Dawei Fan_web_925 leaves the room
[20:13:53] Leif Johansson_web_862 leaves the room
[20:13:57] Leif Johansson_web_139 joins the room
[20:14:42] <mcr> @PHB, but why would you need to input the TLSA records for devices that you didn't build?
[20:14:43] <Benjamin Schwartz_web_219> mcr: Pretty much, yeah
[20:14:45] Jaime Jimenez_web_696 leaves the room
[20:14:49] Jaime Jimenez_web_852 joins the room
[20:15:01] Michael Richardson_web_515 leaves the room
[20:15:09] Michael Richardson_web_712 joins the room
[20:15:20] Francois Ortolan_web_208 leaves the room
[20:15:28] Jaime Jimenez_web_852 leaves the room
[20:15:29] <Benjamin Schwartz_web_219> Relatedly, I would like to see support for ~~permanent offline operation, rather than effectively requiring at least periodic public internet access.
[20:15:32] Jaime Jimenez_web_722 joins the room
[20:15:51] <Paul Wouters_web_335> i tried to put that in an 2 pkix peple blocked it
[20:17:25] <Dan Harkins_web_918> @Paul, what are you referring to?
[20:17:43] John Preuß Mattsson_web_297 joins the room
[20:17:59] <Dan Harkins_web_918> what did you try and put in?
[20:18:01] <Wes Hardaker_web_711> he's referring to tlsa indicating must TLS
[20:18:11] Erik Nordmark_web_957 leaves the room
[20:18:11] <Dan Harkins_web_918> ahh
[20:18:21] <Phillip Hallam-Baker_web_638> @mcr if I can;t take control of the device, I don't want this at all.
[20:18:54] <Phillip Hallam-Baker_web_638> @mcr my system allows that
[20:19:37] Henk Birkholz_web_841 joins the room
[20:19:50] <Leif Johansson_web_139> I think the point was about planned obsolescence at scale.
[20:20:09] <Leif Johansson_web_139> by the time the market adjusts we will have a world full of IKEA lamps that can't talk to their sockets
[20:20:16] <Paul Wouters_web_335> RFC 9102 yay :)
[20:20:25] Kerry Lynn_web_926 leaves the room
[20:20:29] <dkg> dnssec chain extension would resolve the privacy concerns i'd mentioned
[20:20:31] <Benjamin Schwartz_web_219> IoT is full of ephemeral manufacturers, so tying them into a global namespace that can't be change is a recipe for sadness.
[20:20:31] Kerry Lynn_web_573 joins the room
[20:20:39] <David Lawrence_web_822> I legit thought that was done a long time ago
[20:20:41] <Trent Adams_web_285> If the intent is for this work to be focused on industrial scale with some constraints (guiding home IoT deployers away from it), I'd suggest that the charter explicitly call that out.
[20:20:54] <Brendan Moran_web_410> @ben 100%
[20:21:23] <Bill Woodcock_web_810> I'm willing to work on both standardization and implementation of DANE client auth in the DNS space.
[20:21:41] <dkg> Ben is absolutely right about fly-by-night manufacturers and deliberate obsolescence.
[20:21:41] <mcr> @Ben, HOME IoT is full ephermeral manufacturers.  Automotive IoT and Building IoT is the same set of mfrg which have been around for 50 years....
[20:22:24] <Robert Moskowitz> can we take IoT out of the wg name?  I mean, UAS is IoT (for the most part)...
[20:22:29] <Scott Rose_web_361> I'm willing to read/review docs.  We had early projects in this space we may revive if we can get resources.
[20:22:40] <Gustavo Lozano_web_764> I am willing to work on standardization and implementation. I see value in the TLS extension when doing tls-client authentication in business-business APIs. I know that this is a non-IOT use case, but it will benefit from this work. +1 on a WG being formed.
[20:22:53] <Shumon Huque_web_844> The work items are definitely general use.
[20:22:56] <Brendan Moran_web_410> @mcr: Not sure I agree. Many of those devices are made by 3rd party contractors you've never heard of.
[20:23:02] <Benjamin Schwartz_web_219> DANe authentication for Inter-Service Handshakes
[20:23:09] <Tim Cappalli_web_524> Agree with removing IoT from name
[20:23:14] <Daniel Migault_web_149> willing to review the work. I do not think this is restricted to IoT.
[20:23:14] <Scott Rose_web_361> DANE Authenticating Network Clients Everywhere (DANCE).
[20:23:26] <mcr> very nice Ben! Thank you.
[20:23:27] <Christian Amsüss_web_165> +1 on DANCE :-)
[20:23:28] <Shumon Huque_web_844> Nice Scott :)
[20:23:32] <Ash Wilson> I like DANCE
[20:23:32] <Gustavo Lozano_web_764> +1 DANCE
[20:23:37] <Hannes Tschofenig_web_782> I am happy to work with folks interested in adding support to Mbed TLS
[20:23:37] <Tim Cappalli_web_524> :eyes: Scott
[20:23:38] <Robert Moskowitz> +1 on DANCE
[20:23:39] <Ash Wilson> If you want to
[20:23:40] <Trent Adams_web_285> @ScottRose +1
[20:23:52] <Christian Amsüss_web_165> Ash: Not leaving friends behind!
[20:23:56] <mcr> so, now that we are down to a bikeshed discussion on the name, I think the work is done ;-)
[20:23:57] Shigeya Suzuki_web_304 leaves the room
[20:24:09] <Shumon Huque_web_844> Agree with Bill Woodcock - if we can generalize the charter, without too much additional work, that would be best.
[20:24:11] <Cullen Jennings_web_680> +1 Bill. The best thing about IoT is that the things are on the internet so all we need is something that works on internet
[20:24:13] <Timothy Panton_web_365> If you specify IoT - then you have to support DTLS - SMTP only needs TLS
[20:24:17] Qin Wu_web_388 leaves the room
[20:24:22] <dkg> to Bill's point, this is not the first time at this IETF that "IoT" has been referred to as a four-letter word
[20:24:22] <Bill Woodcock_web_810> +1 on DANCE.
[20:24:31] Shigeya Suzuki_web_316 joins the room
[20:24:46] <dkg> +1 on DANCE
[20:24:46] Ali Hussain_web_652 leaves the room
[20:24:51] <mcr> There is also some value in outsiders that care about IoT stuff actually find stuff that matters to them.
[20:25:02] <Dan Harkins_web_918> everybody DANCE now!
[20:25:04] <Benjamin Schwartz_web_219> +1 DANCE
[20:25:20] <Bill Woodcock_web_810> Yep.
[20:25:50] <Russ Housley_web_112> changing the name after the mail list is set up leads to confusion.  Example spasm --> lamps
[20:26:04] <mcr> @Russ, but that's gonna get fixed, right :-)
[20:26:04] <dkg> it's only confusion if you let it persist
[20:26:05] <Brian Haberman_web_630> No singing at an IETF meeting unless Spencer has his drums out.
[20:26:15] <dkg> just tear off the band-aid
[20:26:26] <mcr> yes, new ML if we do new name, please.
[20:27:16] <Shane Kerr_web_177> So PHB is trying to kill the working group because he has a competitive technology? ;-)
[20:27:46] <Brian Haberman_web_630> On a serious note, I agree with Bill that the client auth work can be done without focusing on IoT.
[20:28:05] <Bill Woodcock_web_810> @Shane, PHB is saying two working groups is appropriate.  I don't care whether it's two working groups or one that deals with this in IoT _and_ DNS _and_ SMTP _and_ whoever else needs it.
[20:28:14] <Brian Haberman_web_630> To Roman's question, I do not see anything in the work items that are problematic.
[20:28:25] <Robert Moskowitz> +1 to "client identity".  even though IoT is where I am.
[20:28:50] <mcr> I'd like the word "IoT" to appear somewhere in the charter, just so that outsiders will find it.
[20:29:04] <Wes Hardaker_web_711> maybe as examples @mcr
[20:29:04] <Sandoche Balakrichenan_web_926> +1 @mcr
[20:29:10] Samuel Weiler_web_451 leaves the room
[20:29:20] <mcr> examples are fine!
[20:29:27] <Phillip Hallam-Baker_web_638> @shane, no I am saying it is two seprate WGs
[20:29:27] Joseph Salowey_web_343 joins the room
[20:29:40] <Robert Moskowitz> IoT is a major use and thus stays in the charter.  Just not the end-all.
[20:29:54] <Bill Woodcock_web_810> @mcr, why not DNS and SMTP, then?  IoT is one application.
[20:30:01] <Phillip Hallam-Baker_web_638> @shane we don't have to talk about IoT to find a justification to fix the undone parts of DANE
[20:30:13] <Bill Woodcock_web_810> Agreed, @PHB.
[20:30:44] <Christian Amsüss_web_165> Having IoT in the charter will also help ensure that things work on constrained[rfc7228] devices to the extent that's reasoable.
[20:30:45] <Robert Moskowitz> There are other RR for clients than TLSA.  How do we do this inclusively.
[20:30:47] Mohit Sethi_web_155 leaves the room
[20:30:51] <Benjamin Schwartz_web_219> I think we should avoid focusing on examples in the charter.  Any example is likely to raise some eyebrows.
[20:30:54] <mcr> @Bill, I'm happy to have DNS and SMTP as examples mentioned.  But, most people who do DNS and SMTP and are going to participate are IETF insiders, and will understand why we gave it a name that comes with top-40 hit song.
[20:30:56] Todd Herr_web_749 leaves the room
[20:31:13] Mark Andrews_web_529 joins the room
[20:31:50] <Phillip Hallam-Baker_web_638> @bob the only reason to not want to focus on IoT in the charter is that the requirements for SMTP STARTTLS client auth are really well defined. IoT is a moving target. It would take us a year to decide how to apply DNS/DANE to IoT
[20:32:03] <Benjamin Schwartz_web_219> (Client authentication for DNS raises serious privacy concerns, and client authentication for SMTP could be viewed as a solved problem.)
[20:32:30] <Bill Woodcock_web_810> @Benjamin: blinded certs for that.
[20:32:44] <Ash Wilson> Raw public key
[20:33:00] Ulrich Wisser_web_448 leaves the room
[20:33:02] Michael Jenkins_web_486 leaves the room
[20:33:09] Corey Bonnell_web_682 leaves the room
[20:33:14] <Benjamin Schwartz_web_219> @Bill Is there an RFC for that?
[20:33:21] Dieter Sibold_web_414 leaves the room
[20:33:24] <Bill Woodcock_web_810> Yeah, hang on a sec...
[20:33:31] <Robert Moskowitz> RPK is supported in TLSA RR.
[20:33:36] Patrick Tarpey_web_413 leaves the room
[20:33:39] <Benjamin Schwartz_web_219> Anyway, I'm supportive, just suggesting that examples are likely to add more controversy than clarity.
[20:33:44] Burt Kaliski_web_676 leaves the room
[20:33:45] Timothy Panton_web_365 leaves the room
[20:33:47] Qiaoyu Deng_web_814 leaves the room
[20:33:52] <Hannes Tschofenig_web_782>
[20:33:54] Tomofumi Okubo_web_550 leaves the room
[20:33:55] <Benjamin Schwartz_web_219> To me, Oauth-type applications seem like the clearest use case.
[20:33:58] <Bill Woodcock_web_810>
[20:34:12] <Roman Danyliw_web_855> Could we re-engineer a better name back into DANISH?
[20:34:23] <Bill Woodcock_web_810> @Benjamin, actually, I completely agree.  Examples are toxic.  :-)
[20:34:29] <mcr> @Roman, we had: DANe authentication for Inter-Service Handshakes
[20:34:30] <Roman Danyliw_web_855> Bof names that are difference that WG names that are different than ML is painful
[20:34:31] Christian Amsüss_web_165 leaves the room
[20:34:32] <Benjamin Schwartz_web_219> @Bill.  OK.  I would love to see that in TLS but we're not there yet.
[20:34:43] <Robert Moskowitz> See RFC 6698 sec 2.1.4
[20:34:50] <mcr> or: DANE Authenticating Network Clients Everywhere
[20:35:00] Daphanie Nisbeth_web_273 leaves the room
[20:35:32] Mark Andrews_web_529 leaves the room
[20:35:39] <Benjamin Schwartz_web_219> +1 to Keeping Scope of Work AS-IS
[20:35:41] <Bill Woodcock_web_810> @Benjamin, yeah, it was new to me, too, as of maybe six weeks ago.  Use-case is authenticating paid users of ingress nodes in oblivious proxy architectures.
[20:35:42] Kerry Lynn_web_573 leaves the room
[20:35:45] Tim Cappalli_web_524 leaves the room
[20:35:55] <Bill Woodcock_web_810> Ingress node just needs to know that the bill has been paid, not who the user is.
[20:36:04] <Benjamin Schwartz_web_219> @Bill Come to PRIVACYPASS on Friday :)
[20:36:10] John Preuß Mattsson_web_297 leaves the room
[20:36:11] Vincent Levigneron_web_669 joins the room
[20:36:25] Cullen Jennings_web_680 leaves the room
[20:36:38] <Bill Woodcock_web_810> @Benjamin: Nooooooo thank you.  I do physical security, not cryptographic.  :-)
[20:36:43] <Benjamin Schwartz_web_219> (but I don't believe you can combine that with DANE)
[20:36:48] <Shumon Huque_web_844> Agree, the IOT use case can be described in an architecture document.
[20:36:53] Cullen Jennings_web_595 joins the room
[20:37:04] Vincent Levigneron_web_669 leaves the room
[20:37:07] Peter Campbell_web_197 leaves the room
[20:37:12] <Robert Moskowitz> DANISH will specify the client authentication (e.g. TLS) use case and an architecture describing the primary components and interaction patterns.
[20:37:14] <Rich Salz_web_963> I spoke with the tools folks about the name change. It's hard to do, archive links break, etc.  All of the obvious easy fixes ("I know mailman") do not work for important use-cases.
[20:37:16] Kazunori Fujiwara_web_339 leaves the room
[20:37:17] Peter Koch_web_233 leaves the room
[20:37:22] Francisco Arias_web_359 leaves the room
[20:37:46] <Daniel Migault_web_149> I think architecture is sufficient. I suspect that use case / example will bring unecessary debates.
[20:38:05] <Robert Moskowitz> DRIP wg is on the tm-rid mailing list...
[20:38:11] <Benjamin Schwartz_web_219> Can we say "Industrial IoT"?
[20:38:21] <Bill Woodcock_web_810> I agree with @Daniel...  Examples paint a target on the back of the thing we need finished.
[20:38:28] <Robert Moskowitz> @Ben:  no.
[20:38:53] Andrew S_web_695 leaves the room
[20:38:55] <Daniel Migault_web_149> @rob which leaves to many messages being lost. ;-)
[20:39:10] <Jacques Latour_web_800> @ben yes :-)
[20:39:20] Gustavo Lozano_web_764 leaves the room
[20:39:23] <dkg> so axfr?
[20:39:24] Gustavo Lozano_web_953 joins the room
[20:39:26] Göran Selander_web_573 leaves the room
[20:39:31] Göran Selander_web_899 joins the room
[20:39:33] Gustavo Lozano_web_953 leaves the room
[20:39:41] Gustavo Lozano_web_608 joins the room
[20:39:45] Gustavo Lozano_web_608 leaves the room
[20:40:37] <David Lawrence_web_822> "primary" ... and please let's not call it "politically correct"
[20:40:42] <Robert Moskowitz> So new mailing list and live with the jump.
[20:41:39] <Robert Moskowitz> How would Oauth fit in here besides Oauth use of TLS.
[20:42:45] Benjamin Schwartz_web_219 leaves the room
[20:42:49] <Ash Wilson> Oauth was originally considered for inclusion. I have some notes on how that might work. We could do that in a re-charter.
[20:42:49] Benjamin Schwartz_web_132 joins the room
[20:42:49] <Jacques Latour_web_800> certificate or keys?
[20:42:50] Benjamin Schwartz_web_132 leaves the room
[20:42:54] Benjamin Schwartz_web_595 joins the room
[20:42:58] Brian Haberman_web_630 leaves the room
[20:42:59] <Bill Woodcock_web_810> @tale: Sorry, you're absolutely right, I was just tongue-tied.
[20:43:06] Paul Lanzi_web_277 leaves the room
[20:43:11] <Robert Moskowitz> I don't disagree with TLS as deliverable.  But I do disagree with limiting the charter to only TLS as protocol of interest.
[20:43:13] <David Lawrence_web_822> I got ya, friend
[20:43:19] Benjamin Schwartz_web_595 leaves the room
[20:43:24] Benjamin Schwartz_web_846 joins the room
[20:43:58] <Bill Woodcock_web_810> @dkg: "ADoT" is "Authoritative DoT" or DNS-over-TLS-for-*xfr.
[20:44:15] <mcr> Bill, in your DNS use, are you considering non-XoT uses? i.e. SIG(0) authentication for AXFR?
[20:44:24] Lucy Lynch_web_798 leaves the room
[20:44:48] <Bill Woodcock_web_810> @mcr, lemme think about that a minute, and make sure I understand the question.  Not ignoring it.
[20:46:21] <Robert Moskowitz> +1 with NOT TLS only.  Though rechartering COULD work.
[20:46:23] <Bill Woodcock_web_810> @mcr, so are you asking whether I'm looking for a mechanism for propagating TSIG keys?
[20:46:30] <Bill Woodcock_web_810> (as an example?)
[20:46:32] <Roman Danyliw_web_855> My strong preference would be to re-charter for additional scope
[20:46:45] <mcr> TSIG is shared secret. One can authenticate with SIG(0) instead.
[20:46:46] <Hannes Tschofenig_web_782> Agree with Roman
[20:47:02] <Benjamin Schwartz_web_846> I propose "Client key management practices for DANE" for the second bullet point
[20:47:27] <Benjamin Schwartz_web_846> Currently, I can't really tell the difference between the points 2 and 3.
[20:47:31] <dkg> sshfp is known
[20:47:42] <dkg> has sshfp records, iirc
[20:47:48] <Bill Woodcock_web_810> @mcr, I'm out of my depth a bit, since I'm _really_ not a crypto guy, but yeah, that seems reasonable.  And, again, we're going to need to be able to handed the blinded certs, and I definitely don't want that to have to be a separate mechanism, else it'll be a pain to get that implemented also.
[20:47:58] <Phillip Hallam-Baker_web_638> @dkg using DANE for SSH makes perfect sense.
[20:48:07] <dkg> and openssh supports sshfp verification directly, iirc
[20:48:08] <Bill Woodcock_web_810> I like @Benjamin's suggestion.
[20:48:10] <Bill Woodcock_web_810> Yeah.
[20:48:23] <Maarten Aertsen_web_553> @dkg yes it does
[20:48:44] <mcr> PHB, @dkg, do we need anything in DNS to allow SSHFP to be used for client authentication?  I think we need an openssh extension here.
[20:48:57] <mcr> I mean, anything new in DNS?
[20:49:12] Hugo Salgado_web_110 leaves the room
[20:49:26] <Phillip Hallam-Baker_web_638> @mcr, I see that as different problem to DANISM
[20:49:43] Brendan Moran_web_410 leaves the room
[20:49:54] <dkg> mcr: hm, ssh client authentication would need a bit more work -- but yeah, someting like an "extension".
[20:49:59] <Bill Woodcock_web_810> How about "Client key application and management for DANE"?  Or something similar?  So that it doesn't seem like it's just PKI and provisioning, but also includes actual authentication.
[20:50:06] <Phillip Hallam-Baker_web_638> @mcr, authenticating server-server is straightforward because DNS is designed to authenticate servers.
[20:50:24] <Phillip Hallam-Baker_web_638> @mcr authenticating an SSH USER... ugh... problemo...
[20:50:41] <Phillip Hallam-Baker_web_638> @dkg is there an ssh client cert format?
[20:50:53] Juan-Carlos Zúñiga_web_660 joins the room
[20:51:04] <Phillip Hallam-Baker_web_638> @dkg so I have 30 devices, I want to use to log in as 'phill'
[20:51:11] <mcr> @dkg, I think that if I wanted to authenticate a user with SSHFP, that I'd just want to tell my SSH server to look at DNS.NAME.EXAMPLE, and that I don't even think we need an extension to the protocol.
[20:51:18] Jim Fenton_web_594 leaves the room
[20:52:40] Alessandro Toppi_web_326 leaves the room
[20:52:45] Alessandro Toppi_web_261 joins the room
[20:52:48] <dkg> mcr: the trick is to tell the ssh server how to map from the proposed client identity to the DNS
[20:53:27] <dkg> e.g. should "ssh" make the sshd on look up "" or "" or just "phill." ?
[20:54:16] <Phillip Hallam-Baker_web_638> @dkg.... each one of my devices has a different SSH key so I can disable the device if it is lost or compromised
[20:54:21] <mcr> @dkg, yes, it could be, but currently we configure literal keys in a file as authorization.   So, we just need to configure indirect keys via DNS.  We already have SSHFP.  
[20:54:47] <mcr> @PHB, there is no reason to believe that phill and have any relationship in DNS.
[20:54:59] <Viktor Dukhovni_web_701> The TLS extension is needed. I can explain.
[20:55:04] <dkg> mcr: i see, you're saying that instead of ~~/.ssh/authorized_keys, you have ~~/.ssh/authorized_dns_names
[20:55:05] <Phillip Hallam-Baker_web_638> @mcr, sshfp is a bit different because I type in ssh to connect, there is a DNS name involved
[20:55:12] <Ash Wilson> Agree. TLS extension is essential
[20:55:42] joins the room
[20:55:45] <Phillip Hallam-Baker_web_638> @dkg, I don't like that because I might lose my DNS name.
[20:55:50] <Shumon Huque_web_844> the TLS extension is required to use raw public keys.
[20:55:56] <mcr> sorry to abandon, but nature calls.  see y'all in saag.
[20:55:59] <Robin Wilton_web_830> How about "management and publication practices for client keys and certiificates"?
[20:55:59] <dkg> phb: then you shouldn't use this mechanism
[20:56:05] <Phillip Hallam-Baker_web_638> I rent, I don't own it
[20:56:06] Jon Peterson_web_432 leaves the room
[20:56:09] <Shumon Huque_web_844> (the DANE Client Identy extension)
[20:56:09] Michael Richardson_web_712 leaves the room
[20:56:43] <Jacques Latour_web_800> the TLS extension is to pass the client TLSA identifier
[20:56:44] <mcr> I agree with @dkg, you want a way to put mathmesh identities in .ssh/authorized_keys_foo, not DNS names.
[20:56:48] Hannes Tschofenig_web_782 leaves the room
[20:57:02] <Phillip Hallam-Baker_web_638> @dkg, should anyone use it though? All these people who used to get worried about CAs as TTPs. Now you want to put that hole in access to your systems????
[20:57:11] Paolo Saviano_web_522 joins the room
[20:57:33] Paolo Saviano_web_522 leaves the room
[20:57:36] <Jacques Latour_web_800> +1 Bill
[20:57:38] Paolo Saviano_web_353 joins the room
[20:57:39] <Phillip Hallam-Baker_web_638> @mcr, precisely how I got into the callsign registry in the first place
[20:57:45] Hannes Tschofenig_web_883 joins the room
[20:58:12] <Robin Wilton_web_830> OK, based on Bill's comment, how about: "management, publication and provisioning practices for client keys and certiificates"?
[20:58:12] Viktor Dukhovni_web_701 leaves the room
[20:58:18] Viktor Dukhovni_web_445 joins the room
[20:58:21] <Benjamin Schwartz_web_846> That still doesn't seem to be client-specific.
[20:58:24] Michael Rosa_web_855 leaves the room
[20:58:25] Liang Qin_web_906 leaves the room
[20:58:33] <Benjamin Schwartz_web_846> I want DNSSEC chain extension to be in-charter.
[20:58:41] Kathleen Moriarty_web_823 leaves the room
[20:58:51] <Bill Woodcock_web_810> @Robin, I agree that that covers that side of things, but the authentication is the part that needs fast-tracking at this point.
[20:58:55] <Shumon Huque_web_844> Ah, Ben - you and I were talking about 2 different extensions :)
[20:58:55] <Bill Woodcock_web_810> Provisioning will catch up.
[20:59:06] Paul Wouters_web_335 leaves the room
[20:59:09] <Ash Wilson> Chain extension is RFC 9102
[20:59:13] Dan Harkins_web_918 leaves the room
[20:59:20] <Bill Woodcock_web_810> Thanks much Wes for excellent chairing.  :-)
[20:59:21] <Jacques Latour_web_800> thanks all!
[20:59:23] <Benjamin Schwartz_web_846> Shumon: Yes, but also raw public keys could equally be used to identify a server with that kind of extension
[20:59:27] Viktor Dukhovni_web_445 leaves the room
[20:59:37] <Shumon Huque_web_844> Yes, that's true also.
[20:59:37] Steve Olshansky_web_576 leaves the room
[20:59:38] <Benjamin Schwartz_web_846> So I think that extension could be symmetric.
[20:59:44] <Shumon Huque_web_844> Yes, it could.
[20:59:47] SeongHan Shin_web_962 leaves the room
[20:59:48] Trent Adams_web_285 leaves the room
[20:59:48] Takao Kondo_web_266 leaves the room
[20:59:49] Shigeya Suzuki_web_316 leaves the room
[20:59:50] Wataru Ohgai_web_514 leaves the room
[20:59:50] Jonathan Hammell_web_195 leaves the room
[20:59:50] Leif Johansson_web_139 leaves the room
[20:59:51] Eric Orth_web_112 leaves the room
[20:59:51] Jacques Latour_web_800 leaves the room
[20:59:51] Bill Woodcock_web_810 leaves the room
[20:59:52] Scott Rose_web_361 leaves the room
[20:59:52] Carl Mehner_web_318 leaves the room
[20:59:52] Joseph Salowey_web_343 leaves the room
[20:59:52] Rohit Abhishek_web_481 leaves the room
[20:59:52] Ash Wilson_web_447 leaves the room
[20:59:52] Shane Kerr_web_177 leaves the room
[20:59:53] Valery Smyslov_web_923 leaves the room
[20:59:53] Göran Selander_web_899 leaves the room
[20:59:53] Shumon Huque_web_844 leaves the room
[20:59:54] Benjamin Kaduk_web_525 leaves the room
[20:59:55] Robin Wilton_web_830 leaves the room
[20:59:57] Cullen Jennings_web_595 leaves the room
[20:59:58] Jorge Cano_web_611 leaves the room
[20:59:58] Benjamin Schwartz_web_846 leaves the room
[20:59:59] Alexander Mayrhofer_web_383 leaves the room
[20:59:59] Greg Schumacher_web_404 leaves the room
[21:00:01] Takahiro Nemoto_web_779 leaves the room
[21:00:02] Wes Hardaker_web_711 leaves the room
[21:00:04] Roman Danyliw_web_855 leaves the room
[21:00:04] Robert Moskowitz_web_831 leaves the room
[21:00:07] Yoshiro Yoneya_web_996 leaves the room
[21:00:07] Tero Kivinen_web_898 leaves the room
[21:00:10] Wei Pan_web_524 leaves the room
[21:00:12] Yuji Koyama_web_703 leaves the room
[21:00:15] Meetecho leaves the room
[21:00:15] Russ Housley_web_112 leaves the room
[21:00:17] Alessandro Toppi_web_261 leaves the room
[21:00:19] Rikard Höglund_web_981 leaves the room
[21:00:22] Henk Birkholz_web_841 leaves the room
[21:00:22] Gaël Berthaud-Müller_web_130 leaves the room
[21:00:22] Chi-Yuan Chen_web_260 leaves the room
[21:00:22] Tobia Castaldi_web_636 leaves the room
[21:00:22] James Galvin_web_257 leaves the room
[21:00:22] Michael Breuer_web_217 leaves the room
[21:00:22] Jiankang Yao_web_813 leaves the room
[21:00:22] Marco Tiloca_web_382 leaves the room
[21:00:22] Tadahiko Ito_web_793 leaves the room
[21:00:22] Sandoche Balakrichenan_web_926 leaves the room
[21:00:22] Rich Salz_web_963 leaves the room
[21:00:22] Stefan Santesson_web_694 leaves the room
[21:00:22] Taiji Kimura_web_179 leaves the room
[21:00:22] Daniel Migault_web_149 leaves the room
[21:00:22] Ines Robles_web_189 leaves the room
[21:00:22] Daniel Gillmor_web_666 leaves the room
[21:00:22] Steffen Fries_web_125 leaves the room
[21:00:22] Kohei Isobe_web_232 leaves the room
[21:00:22] Robert Wilton_web_579 leaves the room
[21:00:22] Jim Reid_web_405 leaves the room
[21:00:22] David Lawrence_web_822 leaves the room
[21:00:22] Ching-Heng Ku_web_112 leaves the room
[21:00:22] Phillip Hallam-Baker_web_638 leaves the room
[21:00:22] Oliver Borchert_web_465 leaves the room
[21:00:22] Stephan Emile_web_766 leaves the room
[21:00:22] Jaime Jimenez_web_722 leaves the room
[21:00:22] Juan-Carlos Zúñiga_web_660 leaves the room
[21:00:22] Paolo Saviano_web_353 leaves the room
[21:00:22] Hannes Tschofenig_web_883 leaves the room
[21:00:22] Maarten Aertsen_web_553 leaves the room
[21:00:25] Alessandro Toppi_web_304 joins the room
[21:00:41] Yoshiro Yoneya leaves the room
[21:05:11] stf joins the room
[21:06:22] Robert Moskowitz leaves the room
[21:09:10] Ash Wilson leaves the room
[21:10:23] meetecho-alexamirante leaves the room
[21:10:27] leaves the room
[21:11:21] zulipbot leaves the room: Disconnected: closed
[21:16:47] zulipbot joins the room