IETF
Danish
danish@jabber.ietf.org
Friday, March 12, 2021< ^ >
Room Configuration
Room Occupants

GMT+0
[00:36:52] Ash Wilson joins the room
[00:49:00] Ash Wilson leaves the room
[06:39:19] zulipbot joins the room
[06:41:15] zulipbot leaves the room: Disconnected: closed
[06:48:42] zulipbot joins the room
[06:49:31] zulipbot leaves the room: Disconnected: closed
[06:49:48] zulipbot joins the room
[06:52:18] glen joins the room
[06:52:21] glen leaves the room
[06:58:48] zulipbot leaves the room: Disconnected: closed
[07:10:52] zulipbot joins the room
[07:12:33] glen joins the room
[07:12:37] glen leaves the room
[07:29:15] zulipbot leaves the room: Disconnected: closed
[07:29:21] zulipbot joins the room
[11:37:21] Roman Danyliw joins the room
[11:42:19] Yoshiro Yoneya joins the room
[11:47:41] Meetecho joins the room
[11:48:39] mcr joins the room
[11:48:46] <mcr> morning!
[11:50:03] Roman Danyliw_web_821 joins the room
[11:50:03] Tobia Castaldi_web_628 joins the room
[11:50:03] Nancy Cam-Winget_web_657 joins the room
[11:50:03] Olle Johansson_web_392 joins the room
[11:50:03] Wes Hardaker_web_418 joins the room
[11:50:03] Natalie Ennis_web_799 joins the room
[11:50:03] Peter van Dijk_web_832 joins the room
[11:50:03] Yoshiro Yoneya_web_781 joins the room
[11:50:10] Michael Richardson_web_914 joins the room
[11:51:19] Todd Herr_web_841 joins the room
[11:51:31] Ash Wilson joins the room
[11:52:39] Nancy Cam-Winget_web_657 leaves the room
[11:52:43] Nancy Cam-Winget_web_659 joins the room
[11:53:44] Benno Overeinder_web_733 joins the room
[11:54:23] <mcr> https://codimd.ietf.org/notes-ietf-110-danish?edit
[11:54:31] mcr has set the subject to: notes at: https://codimd.ietf.org/notes-ietf-110-danish?edit
[11:54:33] Anthony Faust_web_572 joins the room
[11:54:56] Ash Wilson_web_331 joins the room
[11:55:08] <mcr> Ash, do you want us to project your slides?
[11:55:21] <mcr> I don't see Shumon yet.
[11:55:33] <Ash Wilson> Yes [please
[11:56:28] Göran Selander_web_845 joins the room
[11:56:33] Shinta Sato_web_681 joins the room
[11:56:50] Shumon Huque_web_559 joins the room
[11:56:58] Benjamin Kaduk_web_376 joins the room
[11:57:07] Cullen Jennings_web_275 joins the room
[11:57:13] Dominique Barthel_web_975 joins the room
[11:57:31] Libor Peltan_web_106 joins the room
[11:57:46] Kohei Isobe_web_938 joins the room
[11:58:01] Jim Reid_web_967 joins the room
[11:58:02] Wei Pan_web_940 joins the room
[11:58:03] Anders Kölligan_web_756 joins the room
[11:58:07] Barry Leiba_web_484 joins the room
[11:58:13] tim costello_web_423 joins the room
[11:58:19] Luuk Hendriks_web_688 joins the room
[11:58:22] Zaid AlBanna_web_289 joins the room
[11:58:23] Alissa Cooper_web_246 joins the room
[11:58:24] Scott Rose_web_773 joins the room
[11:58:25] Michael Breuer_web_920 joins the room
[11:58:30] Olaf Kolkman_web_716 joins the room
[11:58:34] Michael Jenkins_web_802 joins the room
[11:58:37] Ulrich Wisser_web_842 joins the room
[11:58:45] Ken Takayama_web_160 joins the room
[11:58:53] Scott Rose_web_773 leaves the room
[11:58:56] Jacques Latour_web_898 joins the room
[11:59:06] John Preuß Mattsson_web_262 joins the room
[11:59:09] Shu-Fang Hsu_web_501 joins the room
[11:59:10] Daniel Gillmor_web_557 joins the room
[11:59:13] Shu-Fang Hsu_web_501 leaves the room
[11:59:25] Paul Wouters_web_606 joins the room
[11:59:27] Hannes Tschofenig_web_935 joins the room
[11:59:29] Kathleen Moriarty_web_368 joins the room
[11:59:42] Corey Bonnell_web_585 joins the room
[11:59:50] Tadahiko Ito_web_758 joins the room
[11:59:52] Benjamin Steinert_web_703 joins the room
[11:59:54] Yuji Koyama_web_501 joins the room
[12:00:02] Chris Box_web_759 joins the room
[12:00:03] <Hannes Tschofenig_web_935> Hi guys
[12:00:11] Jonathan Reed_web_385 joins the room
[12:00:16] Andreas Pantelopoulos_web_345 joins the room
[12:00:21] <Paul Wouters_web_606> i vould have slept another 2 minutes !
[12:00:25] Christopher Inacio_web_861 joins the room
[12:00:27] <Olle Johansson_web_392> Hi! Early in some time zones :-)
[12:00:34] Andrew S_web_471 joins the room
[12:00:35] Marco Liebsch_web_329 joins the room
[12:00:45] chenmeiling_web_299 joins the room
[12:00:46] Peter Yee_web_525 joins the room
[12:00:54] Chunshan Xiong_web_147 joins the room
[12:00:56] Greg Schumacher_web_222 joins the room
[12:01:00] dkg joins the room
[12:01:05] Stefan Santesson_web_169 joins the room
[12:01:09] Brendan Moran_web_119 joins the room
[12:01:10] Mohit Sethi_web_519 joins the room
[12:01:20] Ben Campbell_web_739 joins the room
[12:01:23] Philipp Tiesel_web_586 joins the room
[12:01:28] Karen Staley_web_752 joins the room
[12:01:43] <Paul Wouters_web_606> ohh travel... one day
[12:01:51] Jiri Novotny_web_328 joins the room
[12:01:55] Valery Smyslov_web_111 joins the room
[12:02:03] David Lawrence_web_610 joins the room
[12:02:05] Trent Adams_web_478 joins the room
[12:02:12] Gustavo Lozano_web_552 joins the room
[12:02:15] Vittorio Bertola_web_575 joins the room
[12:02:23] Vincent Levigneron_web_340 joins the room
[12:02:24] Sandoche Balakrichenan_web_619 joins the room
[12:02:44] Andreas Ruest_web_530 joins the room
[12:02:44] James Galvin_web_536 joins the room
[12:02:50] Antoine Fressancourt_web_688 joins the room
[12:03:05] <Jim Reid_web_967> Where's the URL for the slides?
[12:03:14] Andreas Pantelopoulos_web_345 leaves the room
[12:03:19] Peng Liu_web_760 joins the room
[12:03:20] Suzanne Woolf_web_886 joins the room
[12:03:21] <mcr> https://datatracker.ietf.org/meeting/110/materials/slides-110-danish-chair-slides-00
[12:03:27] <mcr> https://datatracker.ietf.org/meeting/110/materials/slides-110-danish-danish-bof-slides-02
[12:03:34] Geng-Da Tsai_web_265 joins the room
[12:03:43] Dominique Barthel_web_975 leaves the room
[12:03:50] Dominique Barthel_web_471 joins the room
[12:03:50] Antoin Verschuren_web_311 joins the room
[12:03:59] <Jim Reid_web_967> Thanks Michael
[12:04:00] Mike Boyle_web_190 joins the room
[12:04:07] Samuel Weiler_web_459 joins the room
[12:04:08] <Todd Herr_web_841> I'll do the minutes
[12:04:23] Allison Mankin_web_631 joins the room
[12:04:25] kaduk@jabber.org/barnowl joins the room
[12:04:31] <mcr> I am doing the jabber scribe, if you need something taken to the mic:
[12:04:35] Geng-Da Tsai_web_265 leaves the room
[12:04:52] Peter Koch_web_989 joins the room
[12:04:57] Michael Rosa_web_918 joins the room
[12:05:22] Alexander Mayrhofer_web_110 joins the room
[12:05:28] Olle Johansson_web_392 leaves the room
[12:05:33] Olle Johansson_web_153 joins the room
[12:05:37] Stephan Emile_web_894 joins the room
[12:05:46] John Kaippallimalil_web_557 joins the room
[12:05:46] Stephan Emile_web_894 leaves the room
[12:05:50] Stephan Emile_web_959 joins the room
[12:05:53] Gustavo Lozano_web_552 leaves the room
[12:05:57] Gustavo Lozano_web_516 joins the room
[12:06:16] Mark McFadden_web_497 joins the room
[12:06:43] Simon Hicks_web_376 joins the room
[12:07:00] Karen O'Donoghue_web_869 joins the room
[12:07:23] Pallavi Aras_web_291 joins the room
[12:07:35] Viktor Dukhovni_web_278 joins the room
[12:07:48] Hiromu Shiozawa_web_251 joins the room
[12:08:27] Francois Ortolan_web_641 joins the room
[12:09:00] Willem Toorop_web_307 joins the room
[12:09:00] Geng-Da Tsai_web_288 joins the room
[12:09:26] Viktor Dukhovni_web_278 leaves the room
[12:09:31] Viktor Dukhovni_web_640 joins the room
[12:09:37] Allison Mankin_web_631 leaves the room
[12:09:40] Anthony Faust_web_572 leaves the room
[12:09:52] Jari Arkko_web_313 joins the room
[12:10:14] Anthony Faust_web_262 joins the room
[12:10:29] John Preuß Mattsson_web_262 leaves the room
[12:10:39] Doug Montgomery_web_258 joins the room
[12:10:50] <Hannes Tschofenig_web_935> Btw, who came up with the term "mTLS" to refer to TLS with mutual authentication?
[12:11:08] <mcr> I'm not sure, and I was going to ask clarification, thinking he meant "MLS"
[12:11:18] Dominique Barthel_web_471 leaves the room
[12:11:18] <Hannes Tschofenig_web_935> No, certainly not
[12:11:19] <Peter van Dijk_web_832> Hannes, I don't know, but it's been confusing me for years
[12:11:20] <mcr> would you prefer a different term?
[12:11:24] Dominique Barthel_web_972 joins the room
[12:11:33] <chenmeiling_web_299> what's mTLS
[12:11:35] <Hannes Tschofenig_web_935> @mcr: I don't care
[12:11:36] <Peter van Dijk_web_832> The usage of the term is not new here in any case
[12:11:45] <Hannes Tschofenig_web_935> mTLS = TLS with mutual authentication
[12:11:53] Simon Leinen_web_586 joins the room
[12:11:55] <mcr> client and server (mutual) authentication.  Maybe TLS WG would like to give us advice :-)
[12:12:12] <Peter van Dijk_web_832> https://en.wikipedia.org/wiki/Mutual_authentication#mTLS
[12:12:12] <kaduk@jabber.org/barnowl> give advice, like paving the cowpath?
[12:12:14] Peng Liu_web_760 leaves the room
[12:12:36] Mat Ford_web_690 joins the room
[12:13:21] <Shumon Huque_web_559> I used to say 'TLS with mutual auth' too, until I found out the term mTLS appears to be widely used in corporate America at least.
[12:13:39] Dominique Barthel_web_972 leaves the room
[12:13:43] <Hannes Tschofenig_web_935> Makes sense.
[12:13:45] Dominique Barthel_web_284 joins the room
[12:14:28] <kaduk@jabber.org/barnowl> Hannes, isn't mTLS as a term pretty common in OAuth circles?  I don't
know where they got it from, though.
[12:14:55] <Paul Wouters_web_606> i never knew this until just now
[12:15:16] Monika Ermert_web_975 joins the room
[12:15:19] Suzanne Woolf_web_886 leaves the room
[12:15:23] Suzanne Woolf_web_474 joins the room
[12:15:25] <Hannes Tschofenig_web_935> @Ben: There is a spec in OAuth that also uses mutual TLS but that's OAuth specific.
[12:15:31] <dkg> i never knew "mTLS" either :/
[12:16:05] <dkg> also, client authentication has been one of the bugbears of the TLS specification for years.
[12:16:16] <kaduk@jabber.org/barnowl> > a spec in OAuth that also uses mutual TLS
and was named draft-ietf-oauth-mtls, for the gallery.  Now RFC 8705.
[12:16:38] <Hannes Tschofenig_web_935> > also, client authentication has been one of the bugbears of the TLS specification for years.It has only been a problem in browsers -- not in IoT
[12:16:49] <mcr> question: to those that were unclear about "mTLS", was the term "mutual-TLS" understood?  Or did we need to say "mutally authenticated TLS"?
[12:16:54] Dominique Barthel_web_284 leaves the room
[12:17:01] Dominique Barthel_web_680 joins the room
[12:17:17] <dkg> i'd say "mutually authenticated TLS" (or introduce the term formally at the beginning of the discussion)
[12:17:25] <mcr> +1 on what Hannes said. And APIs.
[12:17:45] <dkg> Hannes Tschofenig_web_935: i suppose it depends on what you think the problems are
[12:18:09] chenmeiling_web_299 leaves the room
[12:18:12] <dkg> it has traditionally leaked the identity of the client regardless of whether it's IoT or browser
[12:18:13] chenmeiling_web_938 joins the room
[12:18:20] <Brendan Moran_web_119> "Vendor is not bothering to turn it on" is still a problem in IoT, I guess.
[12:18:21] Alissa Cooper_web_246 leaves the room
[12:18:31] Alissa Cooper_web_132 joins the room
[12:18:45] <kaduk@jabber.org/barnowl> I would say that TLS client authentication is problematic if you are
trying to authenticate a human, but is not so if you are
authenticating a machine as part of a well-specified workflow
[12:19:04] Hiromu Shiozawa_web_251 leaves the room
[12:19:30] <Paul Wouters_web_606> megabytes of blockchain?
[12:19:34] <Jim Reid_web_967> @ Brendan, indeed. How could DANISH fix that?
[12:20:00] <Jim Reid_web_967> blockchain solves everything. :-)
[12:20:09] Geng-Da Tsai_web_288 leaves the room
[12:20:11] <Hannes Tschofenig_web_935> Does DANISH require a blockchain?
[12:20:13] <mcr> (we include blockchain, not because it's a good solution, but perhaps because we want to clarify how it fails...)
[12:20:13] Geng-Da Tsai_web_996 joins the room
[12:20:29] <Paul Wouters_web_606> didnt the start say everyone used their own private zone that even conflicts ?
[12:20:30] Libor Peltan_web_106 leaves the room
[12:20:35] Libor Peltan_web_698 joins the room
[12:21:00] <Jim Reid_web_967> example.com as a TA Paul?
[12:21:10] <dkg> or .local
[12:21:11] <mcr> Today, if one is lucky, there is a private CA.  In well run entity.
[12:21:17] <Brendan Moran_web_119> On its own, it can't. The only way to solve it is three factors: 1) make libraries that solve the problem easy to use. 2) make debugging it easy. 3) make a platform that integrates with it easily and turns it on by default.
[12:21:25] chenmeiling_web_938 leaves the room
[12:21:26] <Peter van Dijk_web_832> .local is limited to mDNS (which has nothing to do with mTLS ;) )
[12:21:32] chenmeiling_web_947 joins the room
[12:21:43] <Paul Wouters_web_606> or both parties using factoryfloor.internal
[12:21:50] <dkg> Peter van Dijk_web_832: oh, how i wish .local was actually limited to mDNS
[12:21:59] <Brendan Moran_web_119> Previous comment directed to @jim reid
[12:22:01] Mat Ford_web_690 leaves the room
[12:22:07] Mat Ford_web_914 joins the room
[12:22:23] <Jim Reid_web_967> @Peter myhouse.local only exists in my house - right?
[12:22:28] <dkg> (i understand that it is currently specified as such)
[12:22:31] Antoine Fressancourt_web_688 leaves the room
[12:22:35] Antoine Fressancourt_web_949 joins the room
[12:23:05] <Peter van Dijk_web_832> Jim, it might also exist in my house, but it would be unrelated to yours
[12:23:05] <Jim Reid_web_967> Thanks Brendan.
[12:23:18] chenmeiling_web_947 leaves the room
[12:23:25] <Peter van Dijk_web_832> dkg, oh, yes, I talk to hurt .local users every day - but let's not make that worse
[12:23:30] chenmeiling_web_904 joins the room
[12:23:54] <mcr> ah. the ".local users", are they the ".lusers" I hear about?
[12:24:30] <Paul Wouters_web_606> what is NS in this context?
[12:24:36] Jean-Michel Combes_web_766 joins the room
[12:24:50] <mcr> was on previous slide.
[12:25:03] <Hannes Tschofenig_web_935> NS = Network Server
[12:25:08] <mcr> oh, not expanded there either.
[12:25:11] <Paul Wouters_web_606> ah thanks
[12:25:28] <Hannes Tschofenig_web_935> Is the use of DNS really specified in LoRaWAN?
[12:25:29] Jean-Michel Combes_web_766 leaves the room
[12:25:31] <Brendan Moran_web_119> Authenticated connections to local network devices without internet visibility seems to be a continuing problem.
[12:25:36] Jean-Michel Combes_web_346 joins the room
[12:26:06] Pete Resnick_web_746 joins the room
[12:26:26] <Hannes Tschofenig_web_935> JS = Join Server (it is a kind of key distribution server)
[12:28:40] <chenmeiling_web_904> what's RG?  AS=Authentication Server?
[12:28:57] <Brendan Moran_web_119> Radio Gateway?
[12:28:59] <mcr> It's the gateway from LoraWAN and IP.
[12:29:21] <dkg> AS = Application Server, aiui
[12:29:35] <Brendan Moran_web_119> It has an antenna in the icon, so I'm guessing that RG === Radio Gateway
[12:29:58] <kaduk@jabber.org/barnowl> RG is definitely radio gateway, yes
[12:30:08] <tim costello_web_423> RG  = Residential Gateway ?
[12:30:17] <tim costello_web_423> BBF terminlogy
[12:30:19] <Paul Wouters_web_606> ok, i am convinced there a number of problems :)
[12:30:57] <mcr> RG is typically on a tower, not residential. Except among us nerds.
[12:31:33] <Francois Ortolan_web_641> You can run a RG with a raspberry pi
[12:31:38] <tim costello_web_423> of course, thanks.
[12:31:47] <Kathleen Moriarty_web_368> I'm late the the thread on mTLS, but when I first started to see it, I thought it was referring to the ETSI mTLS that was breaking TLSv1.3 to allow for interception.  mTLS is used in a lot of circles from the poking i did a while back when I first encountered this and made teh wrong assumption.
[12:31:50] <Brendan Moran_web_119> @francois, that doesn't make @mcr wrong ;)
[12:32:02] <Francois Ortolan_web_641> no it doesn't
[12:32:12] <mcr> among nerds, RG is a RPI1!
[12:32:14] <Paul Wouters_web_606> i am not convinced you can skip some step of "deciding which devices are allows on your network based on identity". Stuffing trillions of devices in DNS shouldnt mean those devices are all allowed. so some preconfigurations remains required
[12:32:48] <Simon Leinen_web_586> @Kathleen thanks for the reminder—mTLS rang a bell, now I understand the confusion.
[12:32:49] <Hannes Tschofenig_web_935> @Kathleen: the ETSI stuff was "eTLS"
[12:33:12] <Simon Leinen_web_586> Ah, or maybe it was that one :-)
[12:33:54] <Vittorio Bertola_web_575> How can anyone not be familiar with DANE? :-)
[12:34:17] <Hannes Tschofenig_web_935> Oh. I just realized that there is also MA-TLS and meTLS...
[12:34:44] <Jim Reid_web_967> So many TLSs to choose from...
[12:34:48] <Ash Wilson> @Paul I agree with you. Just because it's in DNS doesn't mean that it's trustworthy. But writing an interaction policy using DNS names is easier on the eyes, and can end up looking a little like a network ACL
[12:34:58] <Roman Danyliw> ETLS = https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/01.01.01_60/ts_10352303v010101p.pdf#page=8
[12:35:31] <Paul Wouters_web_606> ash: right
[12:35:31] Pete Resnick_web_746 leaves the room
[12:36:02] Pete Resnick_web_880 joins the room
[12:36:34] Sandoche Balakrichenan_web_619 leaves the room
[12:36:39] Sandoche Balakrichenan_web_122 joins the room
[12:37:06] <mcr> the PKIX modes are a "pin", as I understand it.
[12:37:37] <kaduk@jabber.org/barnowl> Yes ... to the extent that there is broad agreement about what the
word "pin" means in the certificate context
[12:38:17] Simon Hicks_web_376 leaves the room
[12:38:21] Simon Hicks_web_764 joins the room
[12:39:01] <Benno Overeinder_web_733> It is time to revive the twitter hash tag #daneiseverywhere
https://twitter.com/hashtag/daneiseverywhere
[12:40:38] <kaduk@jabber.org/barnowl> There is a challenge with using names in X.509 certs for TLS client
authentication in that there is not a great way to bind the claimed
client name to the TLS connection
[12:40:39] Geng-Da Tsai_web_996 leaves the room
[12:40:43] Geng-Da Tsai_web_135 joins the room
[12:41:22] <Jacques Latour_web_898> what's wrong with getting the device identity using a CERT query instead of TLSA for IoT device identity
[12:41:35] <Hannes Tschofenig_web_935> @kaduk: Could you explain where you believe there is a problem?
[12:41:41] <mcr> a DNS CERT RR, you mean?
[12:41:47] <Jacques Latour_web_898> yes
[12:41:52] <Hannes Tschofenig_web_935> I like the approach they take in draft-huque-dane-client-cert-05
[12:42:13] Chris Box_web_759 leaves the room
[12:42:17] <Jim Reid_web_967> DANE isn't widely used and hard to get right. How will this new initiative do better in the IoT space when SMTP providers struggle with DANE?
[12:42:31] <mcr> such a record is just a container for the certificate, and does address the four different DANE cases. That is, you still need to validate what's in the certificate, while in DANE uses 2/3, you just take what's there as having been verified by DNSSSEC.
[12:42:58] <Paul Wouters_web_606> Hannes pushed me to get teh draft into 7250 because he needed it? So I think it would be used?
[12:43:00] <Olle Johansson_web_153> @jim do you mean DANE or DNSsec? Just to clarify what's ahrd
[12:43:02] Simon Hicks_web_764 leaves the room
[12:43:03] <Olle Johansson_web_153> hard
[12:43:04] <Hannes Tschofenig_web_935> I see the client DNS identity conceptually similiar to the SNI
[12:43:11] <Wes Hardaker_web_418> We'll be discussing most questions will be related to problem/solution space at the end -- if there are clarifying questions during this presentation, feel free to join the queue to ask (as the presentation is long [~~30m]).
[12:43:12] <mcr> Jim, DANE in SMTP use is Internet scale. In IoT space, it's more than one vendor (or a private PKI would be fine), but it's no longer thousands.
[12:43:34] <Hannes Tschofenig_web_935> @Paul: s/pushed/convinced
[12:43:57] <mcr> s/and does address/and does not address/
[12:44:11] <kaduk@jabber.org/barnowl> Hannes: in the RFC 6125 procedure for authenticating a server you
start with a target name, make a TLS connection, and then validate if
the certificate you get back is valid for that name.  The TLS server
is passively accepting connections, and doesn't have the "initiate a
connection to a given named entity" step as a reference to validate
against -- in some sense the server is entirely reliant on what the
client claims.  If you really trust your PKI maybe this is fine, but
it is missing the sense of ambient authority provided by "I tried to
open a connection to this name and got to the entity at the other end
of the TLS connection"
[12:44:11] <Jim Reid_web_967> Both actually Olle.
[12:44:22] <Paul Wouters_web_606> hannes: i more meant, hannes came along and did most of the work to complete the draft :)
[12:44:27] Simon Hicks_web_586 joins the room
[12:44:59] <Paul Wouters_web_606> where i had failed t oconvince the ietf of use cases. so it was very good you came along!
[12:45:09] <kaduk@jabber.org/barnowl> Hannes: draft-huque-dane-client-cert is not bad per se, from a quick
skim, but there seem to just be some inherent qualitative differences
between what you can do for server auth vs. client auth
[12:45:15] <Jacques Latour_web_898> The client certificate CN should be unique and matching to a domain name
[12:45:25] <Hannes Tschofenig_web_935> @kaduk: the authorization for server is very different from the client.
[12:45:33] <mcr> (but, we want to deprecate CN completely now...)
[12:45:41] Gustavo Lozano_web_516 leaves the room
[12:45:49] Simon Hicks_web_586 leaves the room
[12:45:53] Simon Hicks_web_729 joins the room
[12:46:00] <Paul Wouters_web_606> CN deprecation is mostly for the web I thought ?
[12:46:05] David Schinazi_web_935 joins the room
[12:46:14] Gustavo Lozano_web_746 joins the room
[12:46:28] <mcr> I don't think Rich wanted to limit to web. PKIX. Only check SAN.
[12:46:37] <Hannes Tschofenig_web_935> @mcr: I am not sure why we would want to deprecate CN. It does not matter in which field you put the relevant information. Deployments for client authentication in IoT often rely on CNs
[12:47:01] <Jacques Latour_web_898> not for IoT devices... every device need a unique identity
[12:47:08] Alexander Mayrhofer_web_110 leaves the room
[12:47:30] chenmeiling_web_904 leaves the room
[12:47:40] chenmeiling_web_677 joins the room
[12:47:46] <Paul Wouters_web_606> do IoT devices need to present multiple identities? that's why webpki moved from CN to SAN
[12:48:00] <Olle Johansson_web_153> We could potentially create a new DNS SAN type
[12:48:11] <Olle Johansson_web_153> sorry TLS SAN type
[12:48:14] <Olle Johansson_web_153> Friday...
[12:48:16] <Hannes Tschofenig_web_935> @Paul: I haven't seen that
[12:48:19] <mcr> sure, include SubjectDN /serialNumber=123456/, but if you are verifying dns, then Rich's SAN document says check dNSName only.
[12:48:27] <Paul Wouters_web_606> hannes: so then using CN is fine
[12:48:34] <Hannes Tschofenig_web_935> Thanks, Paul
[12:49:10] <Paul Wouters_web_606> ugh
[12:49:29] <Paul Wouters_web_606> IETF saying DNSSEC is not mandatory is leading to more RFC pages of workaround than the DNSSEC specification
[12:49:41] <mcr> +1 on Paul.
[12:49:42] <kaduk@jabber.org/barnowl> A few slides back we saw a1b2c3._device.subdomain.example.net.
How common is it to use non-underscore labels as prefixes of
underscore labels?
[12:50:18] Scott Rose_web_755 joins the room
[12:50:37] <Antoine Fressancourt_web_949> Hearing the problem statement and proposed solutions, I would look at the way mobile networks are dealing with similar issues, because I think several issues have been tackled in teh cellular world already
[12:50:43] <mcr> Brendan, run DNSSEC and NSEC3 :-)
[12:50:57] Dominique Barthel_web_680 leaves the room
[12:51:04] Dominique Barthel_web_665 joins the room
[12:51:37] <mcr> I think that the new draft might be solved by CERT RR.
[12:52:24] Nancy Cam-Winget_web_659 leaves the room
[12:53:17] <dkg> names have to be high-entropy if you want them to be non-enumerable
[12:53:31] <Brendan Moran_web_119> @dkg +1
[12:53:52] <Paul Wouters_web_606> even that seems hardly enough with todays cpu/network powers ?
[12:53:55] <Jacques Latour_web_898> Yes, from experience, there's a huge barrier in getting MQTT provides to change their IoT device authentication methods, so it needs to be simple, and doing a DNS query in there to validate the identity is hard..
[12:54:00] <dkg> (that is, NSEC is fully-enumerable, and NSEC3 is a bit more expensive; once you're DNSSEC-signing, you probably want something like NSEC5 if you want to avoid enumerability)
[12:54:09] Eric Kinnear_web_847 joins the room
[12:54:16] <Peter van Dijk_web_832> dkg, do you think NSEC5 is going to happen? because I don't..
[12:54:20] <dkg> but once you have high-entropy names, they are *not* "easier on the eyes"
[12:54:41] <dkg> Peter van Dijk_web_832: i'm pointing out that if ppl care about non-enumerability, they need to help make it happen
[12:54:50] <Peter van Dijk_web_832> right, that makes sense
[12:55:09] <Peter van Dijk_web_832> NSEC3 narrow/white lies is a more likely solution, that is deployable today
[12:55:39] <Paul Wouters_web_606> so i will just send queries for 4 weeks instead of 2?
[12:55:47] <Peter van Dijk_web_832> hmm?
[12:56:27] <Paul Wouters_web_606> to enumerate.
[12:56:39] <Peter van Dijk_web_832> right, the same number of queries as without any DNSSEC
[12:56:39] <dkg> Paul Wouters_web_606: white lies and unique NSEC3 should require a much larger set of live queries for enumeration
[12:56:57] <Jim Reid_web_967> Adding even more DNSSEC complexity - NSEC3 narrow/white lies, NSEC5 - is NOT going to help.
[12:57:06] <Paul Wouters_web_606> yes. but if I'm attacking Philips i can send queries for a few weeks :P
[12:57:12] <dkg> NSEC3 walking is like 2 hours of queries
[12:57:38] <dkg> and the rest is offline attack
[12:58:04] <Peter van Dijk_web_832> Jim, +1 on that
[12:58:06] <Jim Reid_web_967> Is zone enumeration a big enough problem to justify even NSEC3?
[12:58:13] <Olle Johansson_web_153> Does not really have to be WebPKI, but trusted by a known pre-installed trust anchor
[12:58:13] <Paul Wouters_web_606> any interim before-dnssec solution will be the solution that will be in use forever
[12:58:16] Anders Kölligan_web_756 leaves the room
[12:58:32] <Peter van Dijk_web_832> Jim, some people feel that way, but my impression is that NSEC3 deployment in TLDs is mostly driven by opt-out now, which I also consider a weak reason.
[12:58:59] <Paul Wouters_web_606> I assume an IoT device will implement one, not two methods. so migration is never possible
[12:59:05] Anders Kölligan_web_289 joins the room
[12:59:23] Yali Wang_web_425 joins the room
[12:59:28] <Hannes Tschofenig_web_935> There are a lot of high-end IoT devices around as well
[12:59:29] <Jim Reid_web_967> I'm struggling to see how zone enumeration matters for DANISH.
[12:59:33] <mcr> devices get replaced and/or upgraded in industrial IoT, so, yes, some change is possible.
[12:59:51] <Hannes Tschofenig_web_935> We also have a firmware update mechanism .... ;-)
[12:59:53] <Paul Wouters_web_606> symchronised between vendors?
[12:59:56] Scott Rose_web_755 leaves the room
[12:59:57] Jiankang Yao_web_333 joins the room
[13:00:00] Scott Rose_web_411 joins the room
[13:00:02] <mcr> Jim, it goes to Brendan's comment about being able to get an inventory of the devices at a particularly location.
[13:00:08] <Hannes Tschofenig_web_935> Most deployments are within a single vendor today
[13:00:12] <Brendan Moran_web_119> @jim: it's an amazing source of OSInt for setting up for a network intrusion.
[13:00:17] <mcr> Paul, you don't need to synchronize.
[13:00:18] <Paul Wouters_web_606> lets just stick with the most common (interim) solution. since it just works
[13:00:57] <Paul Wouters_web_606> mcr: yes you do unless you want IoT devices to implement multiple mechanisms
[13:01:24] <Shumon Huque_web_559> Reading back in chat, our drafts don't use CN (per 6125 advice) and only propose to use SAN:dnsName.
[13:01:51] <Shumon Huque_web_559> The original version also supported SAN:OtherName:SRVName, but we realized that no-one really uses that, so we dropped it.
[13:02:00] <mcr> so, as we go to the MIC, let's remember that PKIX-CD is not core to the DANISH proposal.
[13:02:59] Antoine Fressancourt_web_949 leaves the room
[13:03:02] <Kathleen Moriarty_web_368> Thanks, Roman & Hannes.  It started out with another name: https://datatracker.ietf.org/liaison/1538/
[13:03:03] <Hannes Tschofenig_web_935> it is probably better to start small with the 2 drafts mentioned earlier
[13:03:45] <Paul Wouters_web_606> hannes: +1   doing the spec and the workaround for the spec at the same time seems a bit odd.
[13:03:50] Philipp Tiesel_web_586 leaves the room
[13:03:57] <Hannes Tschofenig_web_935> Thanks, Kathleen. I wasn't aware of the mcTLS name. A funny name. Reminds me of McDonalds
[13:04:16] <Jim Reid_web_967> @ Brendan and Michael, I understand that inventory concern. NSEC3 won't fix that.  It's just security through obscurity. The assumption here is is once a name is in the DNS, it's public. Repeat for all names in the inventory.
[13:04:17] <Brendan Moran_web_119> Or a DJ who spins encrypted beats.
[13:04:23] <mcr> Paul, you are right.  That's why it's a BOF :-)
[13:04:30] Tom Carpay_web_990 joins the room
[13:05:26] <Shumon Huque_web_559> On the network address exposure question, one thing I should have clarified is the client's identity is a domain name, but there is no expectation that it has an address record that could be looked up at that name.
[13:05:54] <dkg> on the naming confusion front, there's also https://mitls.org/
[13:06:15] <Hannes Tschofenig_web_935> ;-)
[13:06:23] mcr googles for dkgtls.
[13:07:03] <Hannes Tschofenig_web_935> Reserve the domain name
[13:07:15] <Brendan Moran_web_119> @jim: the question is whether it exposes any information other than just the number of devices under management. If the DNS record contains information that can be used to identify the device, then it allows an adversary to gather open-source intelligence.
[13:07:58] <mcr> they woudn't let me reserve br.ski, because apparently 2-letter zones that match ccTLDs are reserved in some TLDs.
[13:08:18] <Paul Wouters_web_606> isnt radius limited to SHA-1 ?
[13:08:27] Sandoche Balakrichenan_web_122 leaves the room
[13:08:32] <Hannes Tschofenig_web_935> Not in the way he uses it
[13:08:36] <mcr> no.
[13:08:55] <Paul Wouters_web_606> ok
[13:09:04] <kaduk@jabber.org/barnowl> brr.ski then?
[13:09:55] Antoine Fressancourt_web_167 joins the room
[13:09:59] <Hannes Tschofenig_web_935> @mcr - what about fido.do instead ;-)
[13:10:30] <mcr> it would be mean if I grabbed that.
[13:10:33] <kaduk@jabber.org/barnowl> It seems a little weird that we use both the underscore and the
non-underscore version of the name.  What would break if we just
always used the non-underscore version?
[13:10:36] Wei Pan_web_940 leaves the room
[13:10:41] Wei Pan_web_496 joins the room
[13:10:54] <Brendan Moran_web_119> @mcr: bℜ.ski?
[13:10:58] Shuping Peng_web_446 joins the room
[13:11:12] Jonathan Reed_web_385 leaves the room
[13:11:32] Jonathan Reed_web_257 joins the room
[13:12:36] Yali Wang_web_425 leaves the room
[13:12:49] <mcr> or- tls-dnssec-chain-extension for DANE auth before network access is granted  <- I think Paul is involved in this?
[13:13:02] Michael Rosa_web_918 leaves the room
[13:13:32] <Wes Hardaker_web_418> https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07
[13:13:36] <Shumon Huque_web_559> @mcr - yes, we mention that use case for tls dnssec-chain later in the deck (I'm involved in that draft too).
[13:13:59] <Shumon Huque_web_559> Wes - that's the old abandoned one. There is a newer version proceeding through ISE.
[13:14:02] <Peter van Dijk_web_832> You'll be reviving tls-dnssec-chain then?
[13:14:09] <Peter van Dijk_web_832> ah yes, now that you mention it
[13:14:11] <mcr> (always buy the dark blue device, it's more secure than the pink one)
[13:14:24] <Shumon Huque_web_559> https://tools.ietf.org/html/draft-dukhovni-tls-dnssec-chain-02
[13:14:32] <Paul Wouters_web_606> peter: it is being worked on. we just got two ISE reviews back finally.
[13:14:56] <Wes Hardaker_web_418> thanks shumon
[13:15:05] <Paul Wouters_web_606> https://tools.ietf.org/html/draft-dukhovni-tls-dnssec-chain-00
[13:15:19] <Kathleen Moriarty_web_368> @Hannes, yes and I think the Microsoft version before that may have been mTLS, so it's no wonder there is confusion.  And I am not keeping up on the chat well this morning, sorry for my lag.
[13:15:21] <Mohit Sethi_web_519> DNSSEC makes things simpler? Is it really simple to implement it on the IoT device side?
[13:15:26] <Paul Wouters_web_606> we already talked longer on this workaround for not having DNSSEC then on the core spec. :/
[13:16:31] <mcr> @Mohit the IoT device does no DNSSEC in the EAP-server use case.  Only in some m2m use does the IoT device need keys from DNSSEC, and that could be accomplished with a TSIG connection to a secure recursive server.
[13:17:17] <Peter van Dijk_web_832> Paul, nice - how about an Implementation Status section?
[13:18:26] <Mohit Sethi_web_519> @mcr: I think the slides that were just shown were doing both server and client authentication of EAP-TLS with DANE. Which would require DNSSEC on client?
[13:19:12] Cigdem Sengul_web_208 joins the room
[13:19:25] <Paul Wouters_web_606> peter: that would just cause another ref of the document. because it has to be removed again
[13:19:31] <kaduk@jabber.org/barnowl> on a tangent, why does everybody like PEM files for distributing certs
from the webserver?  We have a few other media types that are intended
for conveying certificates...
[13:19:45] <Paul Wouters_web_606> and how/when do you do that when in the ISE stream without WG
[13:19:53] <Hannes Tschofenig_web_935> If your device manufacturer goes bankrupt then you are toast
[13:19:56] <mcr> why is it PEM rather than DER?
[13:20:13] <Hannes Tschofenig_web_935> No protocol will help you
[13:20:14] <mcr> i.e. why the layer of base64?
[13:20:19] <Peter van Dijk_web_832> Paul, ok - I don't know the ISE process. I just hope there are implementations before it publishes :)
[13:20:28] <Brendan Moran_web_119> @hannes as soon as the first vulnerability is found...
[13:20:28] Stephan Emile_web_959 leaves the room
[13:20:46] Stephan Emile_web_390 joins the room
[13:21:04] <mcr> You are assuming that bankruptcy does not force disclosure of source, perhaps via escrow.
[13:21:23] <Hannes Tschofenig_web_935> @mcr: the source would not be enough
[13:21:37] <Brendan Moran_web_119> @mcr: Up to today, that seems to be a valid assumption.
[13:22:12] <mcr> Not true for Nortel equipement.
[13:22:23] <Hannes Tschofenig_web_935> The problem is that there is the root of trust on the device, which includes manufacturer provisioned keys. Those would be used for attestation, secure boot, and for doing the onboarding protocols.
[13:23:18] <Mohit Sethi_web_519> @Hannes: I can still do open-wrt on routers and cyanogenmod on smartphones
[13:23:19] <mcr> Yes, @Hannes, Escrow.
[13:23:47] <mcr> @Mohit, you can't. You can't get the device to talk to Google Play, or Hollywood, when you go that direction.
[13:23:49] <Olle Johansson_web_153> We have a lot of issues with end2end in protocols like SIP where this could come in handy
[13:23:54] <Hannes Tschofenig_web_935> Happy to talk about this at length but it is probably a distraction from this BOF
[13:23:56] <Brendan Moran_web_119> @mcr: I don't want any equipment on my network whose root keys have been released by Escrow.
[13:24:16] Doug Montgomery_web_258 leaves the room
[13:24:22] Doug Montgomery_web_715 joins the room
[13:24:24] Gustavo Lozano_web_746 leaves the room
[13:24:30] Gustavo Lozano_web_245 joins the room
[13:24:33] <Hannes Tschofenig_web_935> Who do we think is going to deploy the DANE solution?
[13:24:33] Michael Jenkins_web_802 leaves the room
[13:24:34] Jiri Novotny_web_328 leaves the room
[13:24:42] <mcr> ha. I don't want to pay for any device that haven't been.  Escrow does not mean public.  It means one or more lawyers have Shamir Shares and can reconstruct the root of trust.
[13:25:16] <Hannes Tschofenig_web_935> using DANE as a building blocks for software/firmware updates is easy
[13:25:17] <Brendan Moran_web_119> But, to whom do they give them? You? Your competitors?
[13:25:44] Bron Gondwana_web_186 joins the room
[13:25:58] <Hannes Tschofenig_web_935> @Brendan: Just publish it on the web
[13:26:04] <Brendan Moran_web_119> ;)
[13:26:07] <Hannes Tschofenig_web_935> (in a blockchain)
[13:27:09] <Antoine Fressancourt_web_167> I agree with Jacques that there are interesting technologies in the GSMA world (eUICC, roaming support for cellular network..)
[13:27:16] <Jim Reid_web_967> Hannes, I agree. But doing DANE is *hard*.
[13:28:25] <Antoine Fressancourt_web_167> low bandwidth, asymmetry in path ==> 0-RTT approach to favor
[13:28:29] <Hannes Tschofenig_web_935> @Jim: I agree. There needs to be some work to figure out how to convince folks to do the DANE deployment. Maybe that could be addressed in the problem statement
[13:28:43] Mat Ford_web_914 leaves the room
[13:28:49] Mat Ford_web_722 joins the room
[13:29:00] <Hannes Tschofenig_web_935> @Jacques: IoTSAFE rocks
[13:29:23] <Paul Wouters_web_606> have to run
[13:29:26] Paul Wouters_web_606 leaves the room
[13:29:31] <Hannes Tschofenig_web_935> jogging?
[13:29:36] Suzanne Woolf_web_474 leaves the room
[13:29:53] Ulrich Wisser_web_842 leaves the room
[13:30:06] Jacques Latour_web_898 leaves the room
[13:30:10] Jacques Latour_web_458 joins the room
[13:30:15] <Hannes Tschofenig_web_935> IoT SAFE: Here are documents for those interested: https://www.gsma.com/iot/iot-safe/
[13:30:23] Michael Breuer_web_920 leaves the room
[13:30:28] Michael Breuer_web_661 joins the room
[13:31:17] <Pete Resnick_web_880> Well said Wes. I always like when chairs state what they believe they've heard so far and invite especially comments that disagree with that.
[13:31:30] <Jacques Latour_web_458> yes, IoT SAFE rocks :-)  and our implementation is here: https://github.com/CIRALabs/CIRA-Secure-IoT-Registry
[13:31:40] <Mohit Sethi_web_519> I support doing this work. but perhaps starting with a limited set of documents (first two). get some deployment experience and then revisit the more fancy things later.
[13:31:47] <Hannes Tschofenig_web_935> I think the first two are. I think it would be useful to have a problem statement written somewhere, which could be combined with an architecture write-up
[13:32:29] <Hannes Tschofenig_web_935> @Jacques: Thanks for the link to your Github repo. Looks fantastic!
[13:33:23] <mcr> Hannes, so you'd like to see a problem statement document (perhaps never published)?
[13:33:43] <Brendan Moran_web_119> @mcr I, certainly, would appreciate that.
[13:33:45] <Pallavi Aras_web_291> What about certs for the web address : https://device.supplierdomain.com . If device names can be in thousands ( one name per device) then getting certs for this endpoint might be an operational nightmare in itself.
[13:33:51] Mat Ford_web_722 leaves the room
[13:34:09] <Mohit Sethi_web_519> @Jacques: Indeed. the github repo looks cool. Always good to see implementations
[13:34:16] <Jacques Latour_web_458> @Hannes we built a fist pass at the whole system and it works
[13:34:25] <mcr> @Pallavi, this is done today in quantity billions, according to people at Qualcomm and Rambus.
[13:34:43] <Pete Resnick_web_880> Speaking as someone outside of this technical area, this BOF was so boringly straightforward that it seems like it could have been a WG-forming BOF.
[13:34:57] <mcr> part of the whole point of this work is that one doesn't go to "godaddy", etc. to get those certificates.
[13:35:04] <Wes Hardaker_web_418> @pete: ha, thanks.  Unfortunately the charter wasn't ready in time
[13:35:13] <mcr> @Pete, that's partly true.
[13:35:15] <Peter van Dijk_web_832> +1 to that, Pete
[13:35:34] Dominique Barthel_web_665 leaves the room
[13:35:36] <Jim Reid_web_967> Pete, maybe it was boringly straightforward because there was no draft charter to bicker and shed-paint about
[13:36:09] Geng-Da Tsai_web_135 leaves the room
[13:36:29] <Pete Resnick_web_880> I always like to bring my paint can. :-)
[13:36:33] John Kaippallimalil_web_557 leaves the room
[13:36:43] <Jim Reid_web_967> Thanks and congrats to the organisers for a well-run and productive BoF.
[13:36:53] <Pallavi Aras_web_291> @mcr that is exactly my concern, to have millions of unique web address for the devices in itself can be hard problem to solve. Also zone is not DNSSEC signed so TLSA and web address are both insecure, really from DNSSEC standpoint.
[13:36:54] <kaduk@jabber.org/barnowl> That it was so boringly straightforward is probably a testament to the
work done by the chairs and proponents to prepare a clear portrayal of
the problem statement
[13:36:59] Kohei Isobe_web_938 leaves the room
[13:37:05] <Mark McFadden_web_497> Jim +1
[13:37:06] Kohei Isobe_web_163 joins the room
[13:37:09] Steffen Fries_web_370 joins the room
[13:38:07] <Jim Reid_web_967> @ Ben Kaduk +100
[13:38:22] <Pete Resnick_web_880> @Ben/Jim: +1. Very well prepped and well run.
[13:39:21] Eric Orth_web_979 joins the room
[13:39:46] Oliver Borchert_web_932 joins the room
[13:40:11] Yahya_web_671 joins the room
[13:40:55] Yahya_web_671 leaves the room
[13:41:15] <mcr> of course, we could this all with public DNS w/ IPv6 :-)
[13:41:44] <mcr> so don't hung up on the mapping to mDNS.
[13:41:52] <Shumon Huque_web_559> Maybe we don't need Godaddy for certs, but you might be able to use them to run your DNS zone. They've recently announced at ICANN they are planning to mass sign all their hosted zones.
[13:42:33] <Shumon Huque_web_559> Given their scale, that might make a sizable dent in the DNSSEC deployment numbers.
[13:43:05] <Wes Hardaker_web_418> @shumon: yes, our daily scanning system is already both excited and scared of that day
[13:43:12] <Shumon Huque_web_559> :)
[13:43:25] <dkg> maybe future examples shouldn't use "_auto" as an intermediate label, since "auto" has a bunch of different meanings
[13:43:39] <dkg> (just a suggestion for clearer presentations)
[13:44:03] <mcr> en quebecois, auto -> char(iot). which is even more confusing.
[13:44:05] Francois Ortolan_web_641 leaves the room
[13:44:07] <Wes Hardaker_web_418> good idea @dkg, though autos are now becoming auto so the dual use is maybe appropriate :-!
[13:44:15] Peng Liu_web_605 joins the room
[13:44:18] Francois Ortolan_web_699 joins the room
[13:44:27] <Bron Gondwana_web_186> self driving slides
[13:44:31] Lixia Zhang_web_615 joins the room
[13:44:47] <Jim Reid_web_967> Mass signing will be great. What about the validation side, point everyone's lookups at Quad-X?
[13:44:50] <mcr> I think that "char" is a "backronym" for franglais of "car"
[13:44:54] Mohit Sethi_web_519 leaves the room
[13:45:25] Jari Arkko_web_313 leaves the room
[13:45:56] <Shumon Huque_web_559> Jim - deploy your own validating resolvers? Or send to any of the Quads ..
[13:46:17] <Shumon Huque_web_559> Deploying validation is fairly straightforward compared to signing.
[13:46:25] <Jim Reid_web_967> I run my own validating resolvers. But I'm special. :-)
[13:46:49] <Shumon Huque_web_559> DNSOP people are generally special :)
[13:46:57] <David Lawrence_web_610> awww
[13:47:12] <Jim Reid_web_967> Thanks Shumon. I feel the love. :-)
[13:47:30] <Brendan Moran_web_119> If I spoof a mdns response, can I send all your traffic to my DVR instead of yours?
[13:47:40] Pallavi Aras_web_291 leaves the room
[13:47:44] Pallavi Aras_web_215 joins the room
[13:47:49] <Brendan Moran_web_119> (assuming I've gained access to your local network)
[13:48:12] <Jacques Latour_web_458> @mcr, "park to char", that's quebecois :-)
[13:48:13] <mcr> Maybe, assuming you have the right private key.  The TLS connection is still to the correct public name.
[13:48:35] <Peter van Dijk_web_832> Yes, PROXY protocol is not in IETF. I've been pondering doing something about that, but the stable spec with plenty of implementations seems to be doing the trick fine so far.
[13:48:41] <Jim Reid_web_967> DNS validation is tricky in large eyeball networks. It can introduce too many externalities in a mission-critical service.
[13:49:03] <mcr> @Peter, URL for PROXY thing?
[13:49:03] <David Lawrence_web_610> The pain is on the wrong side of the transaction
[13:49:18] <mcr> clarify please tale?
[13:49:22] <Peter van Dijk_web_832> mcr, https://www.haproxy.org/download/2.4/doc/proxy-protocol.txt
[13:49:35] <Shumon Huque_web_559> Jim - Comcast seems to have figure out how to run it for large eyeball networks.
[13:50:09] <Tadahiko Ito_web_758> brendan +1
[13:50:16] <Jacques Latour_web_458> the IoT middleware code we wrote does a DoT connection and fully trust the responses, so no need for local validation...
[13:50:22] <Wes Hardaker_web_418> shumon: so has the quads
[13:50:26] <David Lawrence_web_610> mcr, If DNSSEC validation fails, the people who take the most heat for it and the resolver operators.
[13:50:48] <David Lawrence_web_610> witness the whole "Comcast is censoring NASA!" debacle
[13:51:04] <Jim Reid_web_967> Indeed they do. As has Telia in Sweden. But they're the exceptions.
[13:51:07] <mcr> ah, @tale, got it.  You are observing that the responsability for failures is not aligned in DNSSEC situation.
[13:51:25] <David Lawrence_web_610> yerp
[13:51:25] <Bron Gondwana_web_186> @mcr the issue is that failures are reported as NXDOMAIN not as DNSSECFAILED
[13:51:37] <Peter van Dijk_web_832> SERVFAIL, not NXDOMAIN
[13:51:42] <mcr> @Bron, I complained about SERVFAIL back in 2003, but nobody listened.
[13:51:46] Göran Selander_web_845 leaves the room
[13:51:50] <Peter van Dijk_web_832> it's a long standing bug in browsers, at least Chrome, that it reports that as NXDOMAIN to the user
[13:51:58] <Brendan Moran_web_119> @mcr: Ah, I think I'd missed that the dash cam already knows the DNS name of the DVR
[13:51:59] <Peter van Dijk_web_832> but, this is besides the point that is being made
[13:52:03] <Jim Reid_web_967> I know one big UK mobile operator doesn't do validation because they don't want the reputation risks when a signer screws up.
[13:52:27] <mcr> I guess, Jim, that needs to be weighed against being responsible for spoofed answers.
[13:52:33] <Bron Gondwana_web_186> I have a series of quotes from our operations staff - chances of us turning on DNSSEC are crazy low
[13:52:58] Bill Silverajan_web_372 joins the room
[13:53:15] Shinta Sato_web_681 leaves the room
[13:53:23] <Eric Orth_web_979> Chrome does not ever inform the user whether or not a failure was NXDOMAIN.  (Some Chorme error codes include "nxdomain" but those don't actually mean an NXDOMAIN DNS result.)
[13:53:34] Shinta Sato_web_391 joins the room
[13:53:46] <Peter van Dijk_web_832> Eric, indeed, it's very annoying
[13:54:03] <dkg> i thought i was the only one annoyed by that "NXDOMAIN" error message in chrome
[13:54:20] <dkg> has anyone reported it to their bugtracker?
[13:54:25] <Peter van Dijk_web_832> good question, checking
[13:54:29] <mcr> also says NXDOMAIN,when it didn't find an IPv4, and couldn't be bothered to do IPv6.
[13:55:11] <Eric Orth_web_979> Pretty sure it's in the bug tracker.  I'm the one who would have to fix it, but it's low on the priority list because it only annoys us technical experts who look at error codes and know what "nxdomain" is.
[13:55:15] <Peter van Dijk_web_832> https://bugs.chromium.org/p/chromium/issues/detail?id=1157070&q=DNS_PROBE_FINISHED_NXDOMAIN&can=2 - Misleading error messages when IPv6 connectivity not present
[13:55:34] <Peter van Dijk_web_832> with comments from Eric, indeed
[13:55:40] <mcr> alas, "connectivity" does not include IPv6-LL or ULA.
[13:56:16] <Peter van Dijk_web_832> https://bugs.chromium.org/p/chromium/issues/detail?id=658323&q=DNS_PROBE_FINISHED_NXDOMAIN&can=2 - DNS_PROBE_FINISHED_NXDOMAIN is inaccurately named
[13:56:52] <dkg> Eric Orth_web_979: public-facing messages have a way of polluting technical conversations by blurring the commonly-understood meanings of technical terms
[13:56:55] Marco Liebsch_web_329 leaves the room
[13:57:19] Olaf Kolkman_web_716 leaves the room
[13:57:27] <Peter van Dijk_web_832> +1 dkg
[13:57:44] <dkg> widely-adopted projects that expose users to technical terms need to take that responsibility seriously
[13:58:04] <dkg> (though i understand the pain of changing error codes, and how that breaks continuity with historic reporting metrics, etc)
[13:58:16] <Jacques Latour_web_458> yes, thanks all! this is great :-)
[13:58:22] Francois Ortolan_web_699 leaves the room
[13:58:40] chenmeiling_web_677 leaves the room
[13:58:42] Pallavi Aras_web_215 leaves the room
[13:58:47] <Roman Danyliw> Please join -- https://mailarchive.ietf.org/arch/browse/danish/
[13:58:51] Geng-Da Tsai_web_965 joins the room
[13:58:51] Monika Ermert_web_975 leaves the room
[13:58:56] <Roman Danyliw> Please watch it for a charter
[13:58:58] <Peter van Dijk_web_832> thanks
[13:59:00] Alissa Cooper_web_132 leaves the room
[13:59:01] Greg Schumacher_web_222 leaves the room
[13:59:02] Jonathan Reed_web_257 leaves the room
[13:59:02] Libor Peltan_web_698 leaves the room
[13:59:04] Barry Leiba_web_484 leaves the room
[13:59:05] Ben Campbell_web_739 leaves the room
[13:59:05] Antoine Fressancourt_web_167 leaves the room
[13:59:06] Corey Bonnell_web_585 leaves the room
[13:59:07] Benjamin Kaduk_web_376 leaves the room
[13:59:07] Vincent Levigneron_web_340 leaves the room
[13:59:07] Samuel Weiler_web_459 leaves the room
[13:59:08] Stephan Emile_web_390 leaves the room
[13:59:08] Peter Yee_web_525 leaves the room
[13:59:09] Jim Reid_web_967 leaves the room
[13:59:09] Doug Montgomery_web_715 leaves the room
[13:59:09] Andreas Ruest_web_530 leaves the room
[13:59:09] Andrew S_web_471 leaves the room
[13:59:10] <Hannes Tschofenig_web_935> Thanks !
[13:59:10] Gustavo Lozano_web_245 leaves the room
[13:59:10] Shumon Huque_web_559 leaves the room
[13:59:10] Eric Orth_web_979 leaves the room
[13:59:11] Vittorio Bertola_web_575 leaves the room
[13:59:11] Michael Richardson_web_914 leaves the room
[13:59:11] David Schinazi_web_935 leaves the room
[13:59:12] Ken Takayama_web_160 leaves the room
[13:59:13] Jean-Michel Combes_web_346 leaves the room
[13:59:14] Anders Kölligan_web_289 leaves the room
[13:59:14] Steffen Fries_web_370 leaves the room
[13:59:14] Scott Rose_web_411 leaves the room
[13:59:15] Peter Koch_web_989 leaves the room
[13:59:16] James Galvin_web_536 leaves the room
[13:59:16] Geng-Da Tsai_web_965 leaves the room
[13:59:16] Jacques Latour_web_458 leaves the room
[13:59:16] Ash Wilson_web_331 leaves the room
[13:59:19] Brendan Moran_web_119 leaves the room
[13:59:19] Mark McFadden_web_497 leaves the room
[13:59:19] Christopher Inacio_web_861 leaves the room
[13:59:20] Mike Boyle_web_190 leaves the room
[13:59:20] Tadahiko Ito_web_758 leaves the room
[13:59:23] Wei Pan_web_496 leaves the room
[13:59:24] Luuk Hendriks_web_688 leaves the room
[13:59:25] Yoshiro Yoneya_web_781 leaves the room
[13:59:25] Karen Staley_web_752 leaves the room
[13:59:26] Trent Adams_web_478 leaves the room
[13:59:28] Pete Resnick_web_880 leaves the room
[13:59:28] Todd Herr_web_841 leaves the room
[13:59:30] <Roman Danyliw> Thanks to the chairs and proponents for the preparation; and the community for the feedback
[13:59:35] tim costello_web_423 leaves the room
[13:59:36] Cigdem Sengul_web_208 leaves the room
[13:59:37] Michael Breuer_web_661 leaves the room
[13:59:38] Shinta Sato_web_391 leaves the room
[13:59:40] Hannes Tschofenig_web_935 leaves the room
[13:59:41] Wes Hardaker_web_418 leaves the room
[13:59:41] Yoshiro Yoneya leaves the room
[13:59:44] Roman Danyliw_web_821 leaves the room
[13:59:46] Oliver Borchert_web_932 leaves the room
[13:59:47] Peter van Dijk_web_832 leaves the room
[13:59:50] Benjamin Steinert_web_703 leaves the room
[13:59:52] Tom Carpay_web_990 leaves the room
[13:59:52] Viktor Dukhovni_web_640 leaves the room
[14:00:06] Natalie Ennis_web_799 leaves the room
[14:00:06] Benno Overeinder_web_733 leaves the room
[14:00:06] Cullen Jennings_web_275 leaves the room
[14:00:06] Zaid AlBanna_web_289 leaves the room
[14:00:06] Daniel Gillmor_web_557 leaves the room
[14:00:06] Tobia Castaldi_web_628 leaves the room
[14:00:06] Kathleen Moriarty_web_368 leaves the room
[14:00:06] Chunshan Xiong_web_147 leaves the room
[14:00:06] Stefan Santesson_web_169 leaves the room
[14:00:06] Valery Smyslov_web_111 leaves the room
[14:00:06] David Lawrence_web_610 leaves the room
[14:00:06] Antoin Verschuren_web_311 leaves the room
[14:00:06] Olle Johansson_web_153 leaves the room
[14:00:07] Willem Toorop_web_307 leaves the room
[14:00:07] Karen O'Donoghue_web_869 leaves the room
[14:00:07] Anthony Faust_web_262 leaves the room
[14:00:07] Yuji Koyama_web_501 leaves the room
[14:00:07] Eric Kinnear_web_847 leaves the room
[14:00:07] Simon Leinen_web_586 leaves the room
[14:00:07] Jiankang Yao_web_333 leaves the room
[14:00:07] Shuping Peng_web_446 leaves the room
[14:00:07] Kohei Isobe_web_163 leaves the room
[14:00:07] Peng Liu_web_605 leaves the room
[14:00:07] Simon Hicks_web_729 leaves the room
[14:00:07] Bron Gondwana_web_186 leaves the room
[14:00:07] Lixia Zhang_web_615 leaves the room
[14:00:07] Bill Silverajan_web_372 leaves the room
[14:01:03] Meetecho leaves the room
[14:01:08] <mcr> jabber logs captured.
[15:26:05] mcr leaves the room
[15:39:03] Roman Danyliw leaves the room
[18:41:41] dkg leaves the room
[20:23:45] kaduk@jabber.org/barnowl leaves the room
[20:23:49] kaduk@jabber.org/barnowl joins the room
[20:23:52] kaduk@jabber.org/barnowl leaves the room