IETF
ohttp
ohttp@jabber.ietf.org
Tuesday, July 27, 2021< ^ >
Room Configuration
Room Occupants

GMT+0
[20:15:22] glen joins the room
[20:15:26] glen leaves the room
[21:11:21] zulipbot leaves the room: Disconnected: closed
[21:16:47] zulipbot joins the room
[22:35:40] francesca joins the room
[22:35:58] Meetecho joins the room
[22:40:12] sftcd joins the room
[22:45:03] Eric Kinnear_web_378 joins the room
[22:45:03] Hamid Azizullah_web_354 joins the room
[22:45:03] Thomas Mangin_web_778 joins the room
[22:45:03] Patrick Tarpey_web_364 joins the room
[22:45:03] Cullen Jennings_web_205 joins the room
[22:45:03] Nicolas Kuhn_web_918 joins the room
[22:45:03] Carsten Bormann_web_739 joins the room
[22:45:03] Andrew Campling_web_920 joins the room
[22:45:03] Stephen Farrell_web_720 joins the room
[22:45:03] Greg Schumacher_web_244 joins the room
[22:45:03] tim costello_web_734 joins the room
[22:45:03] Zaheduzzaman Sarker_web_668 joins the room
[22:45:03] Daniel Gillmor_web_912 joins the room
[22:45:03] Alessandro Toppi_web_758 joins the room
[22:45:03] Alessandro Amirante_web_322 joins the room
[22:45:03] Dirk Hugo_web_535 joins the room
[22:45:03] Julien Maisonneuve_web_943 joins the room
[22:45:10] Tadahiko Ito_web_977 joins the room
[22:45:22] Nigel Hickson_web_497 joins the room
[22:45:33] tim costello_web_734 leaves the room
[22:45:45] Carsten Bormann_web_739 leaves the room
[22:45:51] Carsten Bormann_web_170 joins the room
[22:45:58] Paolo Saviano_web_108 joins the room
[22:46:07] Paolo Saviano_web_108 leaves the room
[22:46:43] dkg joins the room
[22:46:54] Nigel Hickson_web_497 leaves the room
[22:47:00] Carsten Bormann_web_170 leaves the room
[22:47:15] Mohit Sethi_web_408 joins the room
[22:47:16] Hannes Tschofenig_web_140 joins the room
[22:47:28] Nigel Hickson_web_403 joins the room
[22:47:37] Colin Whorlow_web_957 joins the room
[22:48:10] Frode Kileng_web_500 joins the room
[22:48:37] Sean Turner_web_433 joins the room
[22:48:43] frodek joins the room
[22:48:48] Nigel Hickson_web_403 leaves the room
[22:49:23] Chris Lemmons_web_804 joins the room
[22:50:03] Stephan Emile_web_819 joins the room
[22:50:13] Dhruv Dhody_web_869 joins the room
[22:50:27] Richard Barnes_web_868 joins the room
[22:51:26] Richard Barnes_web_868 leaves the room
[22:51:34] Richard Barnes_web_924 joins the room
[22:51:48] Justin Richer_web_168 joins the room
[22:52:01] Alexey Melnikov_web_872 joins the room
[22:52:26] Brendan Moran_web_255 joins the room
[22:52:36] Tommy Pauly_web_864 joins the room
[22:53:04] Robert Moskowitz joins the room
[22:53:07] chenmeiling_web_506 joins the room
[22:53:32] Eliot Lear_web_684 joins the room
[22:53:33] Barry Leiba_web_222 joins the room
[22:53:46] Pete Resnick_web_490 joins the room
[22:53:51] Dominique Lazanski_web_199 joins the room
[22:54:05] <Chris Lemmons_web_804> Success.
[22:54:09] <dkg> we hear you
[22:54:22] <Justin Richer_web_168> :white_check_mark:
[22:54:27] <Pete Resnick_web_490> Yep
[22:54:27] <dkg> yep, also you alexey
[22:54:30] Robert Moskowitz_web_565 joins the room
[22:54:30] David K_web_441 joins the room
[22:54:31] <Chris Lemmons_web_804> Yes/
[22:54:31] Nicklas Pousette_web_894 joins the room
[22:54:33] Marie-Hélène Bouchard_web_427 joins the room
[22:54:34] Francesca Palombini_web_174 joins the room
[22:54:54] Ralf Weber_web_975 joins the room
[22:55:03] Nicklas Pousette_web_894 leaves the room
[22:55:22] Nicklas Pousette_web_113 joins the room
[22:55:22] <francesca> hello everybody!
[22:55:24] tim costello_web_123 joins the room
[22:55:25] Lucy Lynch_web_628 joins the room
[22:55:26] Martin Thomson_web_799 joins the room
[22:55:28] Kazunori Fujiwara_web_871 joins the room
[22:55:36] Chris Box_web_555 joins the room
[22:55:38] <Tommy Pauly_web_864> I'm taking notes
[22:55:39] Roman Danyliw_web_682 joins the room
[22:55:45] <Alexey Melnikov_web_872> Thank you!
[22:55:53] Rikard Höglund_web_162 joins the room
[22:55:57] <francesca> such preparedness
[22:55:57] Justin Iurman_web_448 joins the room
[22:56:01] <francesca> wow chairs
[22:56:03] Christopher Wood_web_401 joins the room
[22:56:03] Geoff Huston_web_509 joins the room
[22:56:04] Frode Sorensen_web_701 joins the room
[22:56:10] Wes Hardaker_web_757 joins the room
[22:56:13] Geoff Huston_web_509 leaves the room
[22:56:17] Geoff Huston_web_867 joins the room
[22:56:21] Marco Tiloca_web_440 joins the room
[22:56:22] <Eliot Lear_web_684> nice font!
[22:56:29] Michael Rosa_web_397 joins the room
[22:56:31] <Martin Thomson_web_799> time enough to install https://martinthomson.github.io/rfc-css/meetecho.user.css
[22:56:34] Mark Nottingham_web_885 joins the room
[22:56:48] Stephen McQuistin_web_285 joins the room
[22:56:53] Kohei Isobe_web_492 joins the room
[22:57:08] <Mark Nottingham_web_885> Not enough to kill that slide typeface, unfortunately.
[22:57:13] Philipp Tiesel_web_628 joins the room
[22:57:16] Markus Amend_web_163 joins the room
[22:57:19] Tommy Jensen_web_527 joins the room
[22:57:26] Dragana Damjanovic_web_122 joins the room
[22:57:35] David Oliver_web_744 joins the room
[22:57:38] Spencer Dawkins_web_809 joins the room
[22:57:47] <sftcd> that typeface makes me think of an angry Mr. R. Bush:-)
[22:57:50] Peter Campbell_web_768 joins the room
[22:57:52] Chi-Jiun Su_web_545 joins the room
[22:58:00] Éric Vyncke_web_972 joins the room
[22:58:02] SeongHan Shin_web_683 joins the room
[22:58:05] <Sean Turner_web_433> @MT so awesome
[22:58:07] Marcus Ihlar_web_468 joins the room
[22:58:08] <Lucy Lynch_web_628> comic sans
[22:58:17] <Richard Barnes_web_924> i believe R. Bush was a Comic Sans purist
[22:58:18] Carrick_web_582 joins the room
[22:58:19] Kazuaki Ueda_web_889 joins the room
[22:58:19] Andrew S_web_607 joins the room
[22:58:22] Hannu Flinck_web_809 joins the room
[22:58:22] Jonathan Rosenberg_web_117 joins the room
[22:58:27] <Lucy Lynch_web_628> still is
[22:58:29] Thomas Fossati_web_184 joins the room
[22:58:33] Xavier de Foy_web_392 joins the room
[22:58:40] Suhas Nandakumar_web_636 joins the room
[22:58:40] Ted Hardie_web_425 joins the room
[22:58:43] Harald Alvestrand_web_212 joins the room
[22:58:47] Lars Eggert_web_589 joins the room
[22:58:51] Tara Whalen_web_749 joins the room
[22:58:54] Russ Housley_web_629 joins the room
[22:58:55] Eckard Bogenfeld_web_858 joins the room
[22:58:58] John Kaippallimalil_web_577 joins the room
[22:58:58] <Mark Nottingham_web_885> I may miss the first ~~5 minutes, as I'm getting some meat delivered.
[22:59:00] Jonathan Hammell_web_682 joins the room
[22:59:01] Mark McFadden_web_702 joins the room
[22:59:06] <sftcd> somewhere I still have a fine t-shirt of randy's making
[22:59:08] Alissa Cooper_web_751 joins the room
[22:59:09] <Mark Nottingham_web_885> (priorities)
[22:59:10] Benedict Wong_web_719 joins the room
[22:59:14] Ken Takayama_web_658 joins the room
[22:59:28] <Sean Turner_web_433> I just had two Ben Chilli Bowl half smokes ... mm good
[22:59:29] Florence D_web_145 joins the room
[22:59:30] Shigeya Suzuki_web_903 joins the room
[22:59:31] Magnus Westerlund_web_834 joins the room
[22:59:31] Valery Smyslov_web_879 joins the room
[22:59:35] Eric Rescorla_web_191 joins the room
[22:59:38] Stephan Emile_web_819 leaves the room
[22:59:40] Paul Wouters_web_769 joins the room
[22:59:45] Dan Druta_web_513 joins the room
[22:59:46] Christian Amsüss_web_790 joins the room
[22:59:47] Jon Peterson_web_113 joins the room
[22:59:48] Tero Kivinen_web_719 joins the room
[22:59:53] Chris Wendt_web_834 joins the room
[22:59:55] Phillip Hallam-Baker_web_159 joins the room
[22:59:56] Scott Rose_web_263 joins the room
[23:00:00] Deb Cooley_web_200 joins the room
[23:00:00] Keith Bare_web_267 joins the room
[23:00:05] Jesus Martin_web_459 joins the room
[23:00:05] Jari Arkko_web_522 joins the room
[23:00:05] Kazunori Fujiwara_web_871 leaves the room
[23:00:05] Philipp Tiesel_web_628 leaves the room
[23:00:06] Stephan Emile_web_671 joins the room
[23:00:07] Joey Salazar_web_492 joins the room
[23:00:08] Shumon Huque_web_723 joins the room
[23:00:09] Kazunori Fujiwara_web_298 joins the room
[23:00:11] <Lucy Lynch_web_628> I swear by Amana Meats because... bacon
[23:00:17] Wei Pan_web_715 joins the room
[23:00:19] Eric Orth_web_393 joins the room
[23:00:20] Marcus Ihlar_web_468 leaves the room
[23:00:23] David Schinazi_web_243 joins the room
[23:00:24] Marcus Ihlar_web_157 joins the room
[23:00:27] Philipp Tiesel_web_607 joins the room
[23:00:30] Joerg Ott_web_466 joins the room
[23:00:30] Jonathan Hoyland_web_493 joins the room
[23:00:31] Vittorio Bertola_web_262 joins the room
[23:00:31] whalen@jabber.org joins the room
[23:00:35] Jiri Novotny_web_453 joins the room
[23:00:40] Marcus Ihlar_web_157 leaves the room
[23:00:43] John Border_web_950 joins the room
[23:00:45] Matthew Finkel_web_244 joins the room
[23:00:48] Takahiro Nemoto_web_410 joins the room
[23:00:48] Trent Adams_web_120 joins the room
[23:00:49] Jasdip Singh_web_367 joins the room
[23:00:50] Marcus Ihlar_web_815 joins the room
[23:00:52] Lucas Pardue_web_689 joins the room
[23:00:52] Thom Wiggers_web_405 joins the room
[23:00:53] Christopher Patton_web_151 joins the room
[23:00:54] Keith Bare joins the room
[23:00:56] Benjamin Schwartz_web_817 joins the room
[23:00:59] Tim Cappalli_web_537 joins the room
[23:01:04] Hiroyuki Goto_web_246 joins the room
[23:01:05] Jonathan Reed_web_755 joins the room
[23:01:06] fightingnemo joins the room
[23:01:08] Francisco Arias_web_828 joins the room
[23:01:08] Mirja Kühlewind_web_871 joins the room
[23:01:13] <Christopher Patton_web_151> dang, it's crowded in here!
[23:01:13] Jorge Cano_web_239 joins the room
[23:01:16] Shivan Sahib_web_272 joins the room
[23:01:16] Glenn Deen_web_392 joins the room
[23:01:21] <Deb Cooley_web_200> @seanL  damn you
[23:01:26] Marcus Ihlar_web_815 leaves the room
[23:01:31] Diego Lopez_web_276 joins the room
[23:01:33] Marcus Ihlar_web_483 joins the room
[23:01:33] Jason Weil_web_280 joins the room
[23:01:39] Alan Frindell_web_990 joins the room
[23:01:46] Mike Bishop_web_188 joins the room
[23:01:46] <Richard Barnes_web_924> @sean WANT
[23:01:51] Will Hawkins_web_571 joins the room
[23:01:51] <Sean Turner_web_433> I mean I am not doing dinner. Alexis is bring me dinner - hasn't happened years! can we have an IETF next week too ;)
[23:01:52] Toerless Eckert_web_944 joins the room
[23:01:56] Greg Wood_web_810 joins the room
[23:01:57] Marcus Ihlar_web_483 leaves the room
[23:01:57] Gustavo Lozano_web_949 joins the room
[23:01:58] Patrick Kelsey_web_258 joins the room
[23:02:07] Nicolas Kuhn_web_918 leaves the room
[23:02:09] Marcus Ihlar_web_657 joins the room
[23:02:17] Nicolas Kuhn_web_682 joins the room
[23:02:20] Tim Cappalli_web_537 leaves the room
[23:02:24] Tim Cappalli_web_302 joins the room
[23:02:27] <Deb Cooley_web_200> right?  but we are too far from Ben's Chili Bowl to make that work.
[23:02:29] Al Morton_web_327 joins the room
[23:02:36] Carsten Bormann_web_306 joins the room
[23:02:39] Jana Iyengar_web_431 joins the room
[23:02:42] Jason Weil_web_280 leaves the room
[23:02:43] Robert Wilton_web_110 joins the room
[23:02:47] Steven Fenter_web_528 joins the room
[23:02:48] Jason Weil_web_982 joins the room
[23:02:49] Lixia Zhang_web_711 joins the room
[23:03:03] Benjamin Kaduk_web_587 joins the room
[23:03:06] Bryan Call_web_124 joins the room
[23:03:14] Jiao Kang_web_581 joins the room
[23:03:23] <Robert Moskowitz> Eating my chicken in soup while listening.  Just had time to boil noodles and heat the soup during break.   :)
[23:03:25] Dan Druta_web_513 leaves the room
[23:03:28] ekr@jabber.org joins the room
[23:03:37] Dan Druta_web_770 joins the room
[23:03:39] <Martin Thomson_web_799> or to confirm their blocks and whatever happens after that
[23:03:48] Erik Nygren_web_563 joins the room
[23:03:52] Leif Hedstrom_web_968 joins the room
[23:03:52] Jiao Kang_web_581 leaves the room
[23:03:58] sftcd looking now at https://datatracker.ietf.org/doc/charter-ietf-ohttp/ballot/
[23:04:00] Daniel Migault_web_727 joins the room
[23:04:11] Qiaoyu Deng_web_130 joins the room
[23:04:17] <Richard Barnes_web_924> this is so much easier than just screen sharing
[23:04:21] Jiao Kang_web_536 joins the room
[23:04:32] <Jana Iyengar_web_431> uuuhhh -- that typeface!
[23:04:32] Francois Ortolan_web_796 joins the room
[23:04:37] <Christopher Wood_web_401> =)
[23:04:40] Matthew Quick_web_167 joins the room
[23:04:40] <sftcd> I'm not sure what kind of R. Bush this one represents
[23:04:54] <Richard Barnes_web_924> I pretend to compete with Martin, but he always wins
[23:04:54] nygren joins the room
[23:04:57] Andrei Popov_web_877 joins the room
[23:04:57] <Alissa Cooper_web_751> Tim Burton's OHTTP
[23:05:11] Sofia Celi_web_242 joins the room
[23:05:13] Jason Livingood_web_872 joins the room
[23:05:14] <Brendan Moran_web_255> oblig typeface reference: https://laughingsquid.com/comic-papyrus/
[23:05:18] Lin Han_web_111 joins the room
[23:06:14] Richard Barnes_web_924 leaves the room
[23:06:16] John Preuß Mattsson_web_850 joins the room
[23:06:20] Richard Barnes_web_481 joins the room
[23:06:30] Nigel Hickson_web_389 joins the room
[23:06:47] <Alexey Melnikov_web_872> Clarifying questions about Martin's presentation at the end of it, please
[23:07:16] <sftcd> clarifying question: why be so mean to our eyeballs with the typeface?
[23:07:28] <ekr@jabber.org> More a comment and a question!
[23:07:29] Kazuho Oku_web_387 joins the room
[23:07:35] <ekr@jabber.org> s/and a/than a/
[23:07:40] Joseph Salowey_web_495 joins the room
[23:07:47] <Justin Richer_web_168> lots of whining about a font in here :face_with_rolling_eyes:
[23:07:55] Yan Yan_web_139 joins the room
[23:07:56] <Mark Nottingham_web_885> it matters
[23:08:01] Nick Banks_web_656 joins the room
[23:08:10] <Lucas Pardue_web_689> don't you mean typeface?
[23:08:10] <Mike Bishop_web_188> Just be happy you're getting still images instead of a video stream.
[23:08:13] <Eric Orth_web_393> Is that a deliberate strategy to give us something less important to complain about?
[23:08:14] <Suhas Nandakumar_web_636> font goes with the theme ?
[23:08:24] <Benjamin Schwartz_web_817> Also: no forward secrecy and no replay protection.
[23:08:25] <Mark Nottingham_web_885> Mike: Don't. Give. Him. Ideas.
[23:08:31] Nigel Hickson_web_389 leaves the room
[23:08:37] <Ted Hardie_web_425> I'm trying to imagine what accent this would induce in a screen reader that used the font as input.
[23:08:44] Nigel Hickson_web_161 joins the room
[23:08:55] <Lucy Lynch_web_628> pirate accent
[23:08:58] Kazunori Fujiwara_web_298 leaves the room
[23:09:02] Kazunori Fujiwara_web_310 joins the room
[23:09:02] <sftcd> screechy?
[23:09:17] <Richard Barnes_web_481> It seems like you could do replay protection based on the HPKE ephemeral bits
[23:09:24] Nathalie Moreno_web_286 joins the room
[23:09:31] whalen@jabber.org leaves the room
[23:09:32] Matthew Quick_web_167 leaves the room
[23:09:34] <Jonathan Hoyland_web_493> Clicking?
[23:09:37] <Jana Iyengar_web_431> Are those sound effects to go with the slide?
[23:09:37] <Benjamin Schwartz_web_817> Yep
[23:09:38] <dkg> i'm hearing clicking too
[23:09:39] <Lars Eggert_web_589> yeah
[23:09:40] <Suhas Nandakumar_web_636> yeah
[23:09:40] <Mark Nottingham_web_885> yes - MT's mic, I think
[23:09:41] <Jonathan Reed_web_755> same
[23:09:42] <Richard Barnes_web_481> creative artifacts
[23:09:43] <Mike Bishop_web_188> Yes.
[23:09:44] <Gustavo Lozano_web_949> yeap, clicking
[23:09:45] <Carrick_web_582> @Jana haha
[23:09:45] <dkg> i think MT needs to be rebooted
[23:09:46] <sftcd> font clicks
[23:09:46] <Jon Peterson_web_113> thumper - beware sandworm
[23:09:46] <Richard Barnes_web_481> untz untz untz untz
[23:09:48] cabo joins the room
[23:09:49] <Jonathan Hoyland_web_493> Bouncing ball on mic?
[23:09:51] <Tim Cappalli_web_302> Metronome
[23:09:51] <Mark Nottingham_web_885> EDM!
[23:09:52] whalen@jabber.org joins the room
[23:09:53] <David Schinazi_web_243> Beat's picking up
[23:09:53] <Lucas Pardue_web_689> it's like that scene in Whiplash
[23:09:55] <Christopher Patton_web_151> aw :(
[23:09:57] <Chris Lemmons_web_804> Yeah, the voice font has clicking in it. :)
[23:10:00] <Mark Nottingham_web_885> drop the beat, MT
[23:10:06] <Benjamin Schwartz_web_817> Resolved
[23:10:08] kaduk@jabber.org/barnowl joins the room
[23:10:10] <Carrick_web_582> :(
[23:10:21] <sftcd> no mention of DNS on this slide?
[23:10:26] <Mark Nottingham_web_885> is there an issue queue for MT himself?
[23:10:39] <dkg> https://github.com/mt/issues
[23:10:42] Christopher Inacio_web_438 joins the room
[23:10:45] Kazunori Fujiwara_web_310 leaves the room
[23:10:47] Taiji Kimura_web_680 joins the room
[23:10:51] <ekr@jabber.org> Note that there are techniques to have a proxy like this give small amounts of metadata that lets the origin server do DoS suppression
[23:11:07] <Jana Iyengar_web_431> dkg: lol
[23:11:10] <Richard Barnes_web_481> @ekr DoS-by-client suppression, yes?
[23:11:15] Kazunori Fujiwara_web_764 joins the room
[23:11:16] Armando Faz-Hernández_web_834 joins the room
[23:11:23] Toerless Eckert_web_944 leaves the room
[23:11:27] John Preuß Mattsson_web_850 leaves the room
[23:11:37] <sftcd> "not be able to see" == "feature"
[23:11:48] John Preuß Mattsson_web_479 joins the room
[23:11:49] <David Schinazi_web_243> unicorn-wg?
[23:11:50] <ekr@jabber.org> @Richard: correct. the assumption is that the proxy is non-malicious but maybe not good at anti-DoS
[23:11:54] Stephen McQuistin_web_285 leaves the room
[23:12:09] <Paul Wouters_web_769> who is "we" ?
[23:12:11] <sftcd> @mt: "we" there means moz?
[23:12:15] <Eliot Lear_web_684> I believe I raised the issue, and it wasn't a matter of "deliberate"
[23:12:16] <ekr@jabber.org> Yes, he's talking about Moz
[23:12:18] <Mark Nottingham_web_885> Stephen: I think the assumption is that a variety of encrypted DNS will be used.
[23:12:24] Andrei Popov_web_877 leaves the room
[23:12:29] <ekr@jabber.org> Firefox disables DoH if it detects a user-installed trust anchor
[23:12:29] whalen@jabber.org leaves the room
[23:12:41] <sftcd> @mnot: makes sense just needs noting
[23:12:49] <dkg> ekr@jabber.org: any user-installed trust anchor?
[23:12:56] Andrei Popov_web_767 joins the room
[23:13:12] <ekr@jabber.org> dkg: I think so, but say more?
[23:13:13] Juliusz Chroboczek_web_477 joins the room
[23:13:23] Dan Wing_web_756 joins the room
[23:13:25] Juliusz Chroboczek_web_477 leaves the room
[23:13:40] <Paul Wouters_web_769> I thought it was based on some special DNS answer ? that any network could do to you?
[23:13:41] <ekr@jabber.org> (to be clear, if you turn it on yourself, I don't think that's true).
[23:13:41] <dkg> .br and .jp have both at some point in the last decade required anyone interacting with certain government authorities to install their own trust anchors
[23:13:43] <Robert Moskowitz> So if GM installed their trust anchor within the corporate network it is broken?
[23:13:48] <ekr@jabber.org> @Paul: there are a number of tests
[23:14:04] <Mike Bishop_web_188> @ekr, just because an employer has a root for internal sites doesn't mean they're intercepting all requests.
[23:14:08] <ekr@jabber.org> @dkg: ah, yes, that would cause us to disable DoH
[23:14:27] <ekr@jabber.org> @Mike: I didn't say it meant that. I'm just saying we disable DoH in that setting
[23:14:32] Satoru Kanno_web_482 joins the room
[23:14:42] <dkg> glad i don't pay my taxes in .br, then :(  that's a pretty large side-effect
[23:14:56] <sftcd> not a question but "short-lived"? really?
[23:15:03] <ekr@jabber.org> @dkg: well, we also don't have DoH on by default in .br!
[23:15:11] <Mark Nottingham_web_885> I think this could be relatively short-lived. It certainly isn't QUIC.
[23:15:19] Kazunori Fujiwara_web_764 leaves the room
[23:15:20] <Jonathan Hoyland_web_493> @dkg you could always just use a container for Government stuff I guess.
[23:15:25] <Jason Livingood_web_872> Was there any note about the pros & cons of breaking HTTP content localization?
[23:15:29] Sanjay Mishra_web_283 joins the room
[23:15:32] Kazunori Fujiwara_web_349 joins the room
[23:15:36] <Mark Nottingham_web_885> Jason: what does that mean?
[23:15:39] <dkg> hoyland: sure, i could.  i also understand what i'm doing when i install root certs
[23:15:41] <Dominique Lazanski_web_199> +1 to Jason's question
[23:15:45] <dkg> i'm asking about "normal" users
[23:15:46] <sftcd> I think I recall one WG that claimed to aim for short-lived that did that
[23:15:50] <Éric Vyncke_web_972> +1 to Jason as well
[23:15:52] <ekr@jabber.org> @Jason: again, this isn't for generic browsing
[23:15:56] Wassim Haddad_web_438 joins the room
[23:15:57] <Spencer Dawkins_web_809> Hmmm. we're deferring discovery mechanisms for MASQUE, for OHTTP, ... what else?
[23:15:59] <Paul Wouters_web_769> jason: the ingress/egrress are in the same geo region ?
[23:16:00] <Éric Vyncke_web_972> @ekr until now....
[23:16:14] <Jason Livingood_web_872> Meaning in the potential cons, if the protocol is intended to hide network source and/or city/location then all the CDN-based HTTP content would be a lot slower for the users.
[23:16:16] <ekr@jabber.org> @Eric: No, no, it just won't work for that. Because it can't work for unmodified servers
[23:16:23] <ekr@jabber.org> If you want that, you want MASQUE
[23:16:38] Ali Hussain_web_736 joins the room
[23:16:42] <ekr@jabber.org> @Jason: yes, but that's not applicable to the cases here.
[23:16:46] <Mark Nottingham_web_885> Jason: it depends very much on how the CDN works, and how the proxies are deployed. There are also potential protocol extensions that could coordinate that.
[23:17:07] <Éric Vyncke_web_972> @ekr good point, I did not catch theat
[23:17:15] Jesus Martin_web_459 leaves the room
[23:17:21] Jesus Martin_web_842 joins the room
[23:17:24] <dkg> +1 to skepticism about PIR
[23:17:43] <ekr@jabber.org> Re: Safe Browsing: https://eprint.iacr.org/2021/345
[23:17:44] <Jason Livingood_web_872> @ekr I totally get that but it seems it should be clearly documented as a trade off to better inform end users. Certainly it is somewhat obvious because a user is seeking to avoid identification, on the other hand the layperson may not fully grasp the knock on effects.
[23:17:49] Scott Rose_web_263 leaves the room
[23:17:51] <Ted Hardie_web_425> Hmm, "state tracking mechanisms" really could have multiple meanings here.  Place that hyphen!
[23:18:16] <dkg> it works in so many ways
[23:18:18] <Lucas Pardue_web_689> :joy:
[23:18:22] Samuel Weiler_web_324 joins the room
[23:18:24] Benjamin Schwartz_web_817 leaves the room
[23:18:26] <ekr@jabber.org> Well, I'm happy to document it, I suppose, but I really think if people want something here it's incumbent upon them to actually document some case where it's relevant
[23:18:28] Benjamin Schwartz_web_964 joins the room
[23:18:36] <sftcd> nice hyphenation aside
[23:18:37] Benjamin Schwartz_web_964 leaves the room
[23:18:43] Benjamin Schwartz_web_292 joins the room
[23:18:50] <Daniel Migault_web_727> Given that a proxy needs to be trusted by both the client and the server. Don't we need to have a sort of agreement. Can we also have proxy-to-proxy communications ?
[23:19:19] <Jason Livingood_web_872> @ekr thx for the clarification
[23:19:24] Chris Inacio joins the room
[23:19:24] Jesus Martin_web_842 leaves the room
[23:19:28] Jesus Martin_web_828 joins the room
[23:19:39] <sftcd> @mic: (sorry can't send audio) can someone summarise the assumeptions about dns needed for this?
[23:19:46] <ekr@jabber.org> None.
[23:19:51] <ekr@jabber.org> The resolution happens in the proxy
[23:19:52] <Christopher Wood_web_401> No DNS assumptions.
[23:20:05] <sftcd> SVCB at least?
[23:20:09] <Richard Barnes_web_481> Consent is important, @mnot
[23:20:12] Dan Druta_web_770 leaves the room
[23:20:16] Dan Druta_web_988 joins the room
[23:20:16] <Martin Thomson_web_799> are we into commentary now?
[23:20:19] <Christopher Wood_web_401> @sftcd: nope, no SVCB dependency
[23:20:20] <ekr@jabber.org> No, not SVCB
[23:20:26] <Sean Turner_web_433> @ekr thanks for that clarification
[23:20:26] Steven Fenter_web_528 leaves the room
[23:20:30] <Richard Barnes_web_481> @mt this should just be clarification
[23:20:37] Bryan Call_web_124 leaves the room
[23:20:38] <Éric Vyncke_web_972> Still wondering which party would like to act as a proxy... as it is kind of expensive
[23:20:40] <sftcd> ah, HPKE ref confused me then, wheres; the public key from?
[23:20:40] <Benjamin Schwartz_web_292> New URI Scheme!
[23:20:40] <ekr@jabber.org> Let's call it ODoH
[23:20:40] <Alexey Melnikov_web_872> Martin: on your slides only
[23:20:41] Bryan Call_web_225 joins the room
[23:20:41] <Jari Arkko_web_522> +1 mnot
[23:20:44] <Martin Thomson_web_799> OK, mnot jumped the gun :)
[23:20:45] James Galvin_web_286 joins the room
[23:20:46] Jay Daley_web_170 joins the room
[23:20:53] <ekr@jabber.org> Eric: this is something that the client and the server (typically the same person) arrange with the proxy
[23:20:59] Jason Weil_web_982 leaves the room
[23:21:01] <Mark Nottingham_web_885> That's what I *DO*
[23:21:03] <Martin Thomson_web_799> as far as I'm concerned, name confusion is my speciality
[23:21:06] Jason Weil_web_712 joins the room
[23:21:14] <Daniel Migault_web_727> @ekr so this cannot be used as firefox vitual network for example ?
[23:21:14] <ekr@jabber.org> Like, ask, for instance, why Cloudflare acts as the proxy for Apple's iCloud Relay
[23:21:25] <Zaheduzzaman Sarker_web_668> thanks to EKR for the clarification... this helps.. and should be clear in the charter ..
[23:21:32] Stefan Santesson_web_171 joins the room
[23:21:52] <Éric Vyncke_web_972> @ekr, thanks but if the client & server are the same person/org then they could indeed contract a proxy but this looks weird (albeit feasable)
[23:21:59] <ekr@jabber.org> @Daniel: not to be nitpicky but for "virtual network" do you mean "firefox private network" (the connect proxy)
[23:22:14] <ekr@jabber.org> @Eric: why is that weird? There are several natural use cases for this in the doc/charter
[23:22:18] <sftcd> @mic: where's the HPPE public key come from? (apologies if I'm being slow)
[23:22:25] <sftcd> @mic: where's the HPKE public key come from? (apologies if I'm being slow)
[23:22:42] <ekr@jabber.org> @sftcd: unspecified, but generically it's by prior arrangement of the client and server
[23:22:54] <Benjamin Schwartz_web_292> I think the latency benefit is a red herring.  You can preheat a fresh QUIC connection for each request, and the resume it when you want to use it.
[23:22:58] <dkg> sftcd: that's the "discover" thing that everyone is trying to not talk about
[23:22:59] <Christopher Patton_web_151> makes sense to me
[23:23:02] <ekr@jabber.org> So, like in the case where you were doing Fx Telemetry, we would presumably just bake it into the client
[23:23:04] Matthew Quick_web_564 joins the room
[23:23:17] sftcd starting to understand the BLOCK positions (while being positive towards this)
[23:23:20] <ekr@jabber.org> @Benjamin: that's much more annoying to implement
[23:23:24] Dan Druta_web_988 leaves the room
[23:23:25] <kaduk@jabber.org/barnowl> Um, is there actually a jabber scribe designated?
[23:23:36] Jonathan Lennox_web_149 joins the room
[23:23:40] <Eliot Lear_web_684> Are we in the general discussion part?
[23:23:41] <Richard Barnes_web_481> there is not a jabber scribe designated
[23:23:46] Dan Druta_web_706 joins the room
[23:23:47] <dkg> Benjamin Schwartz_web_292: preheating also tracks the user across connections if they move networks between warm-up and use
[23:23:52] <Christopher Wood_web_401> @ben: resuming repeatedly introduces linkability -- that's an antipattern
[23:23:58] <Richard Barnes_web_481> @Eliot we are supposed to be in clarifying question mode
[23:24:05] <sftcd> @kaduk: I'm fine with the setup as is fwie
[23:24:07] <Éric Vyncke_web_972> Meetecho is linked to jabber whose logs are kept automagically
[23:24:09] <Benjamin Schwartz_web_292> @Christopher I'm talking about single-use resumptions.
[23:24:12] <Pete Resnick_web_490> @richard: Stephen needs mic relaying.
[23:24:21] <Erik Nygren_web_563> A great example might be map tiles.
[23:24:23] <Richard Barnes_web_481> @Pete thanks, will do
[23:24:25] <Christopher Wood_web_401> @ben: those are still linkable
[23:24:38] <dkg> Benjamin Schwartz_web_292: aren't you still linking between initial session and resumption?
[23:24:39] <kaduk@jabber.org/barnowl> @Benjamin: how do you pre-warm the QUIC sessions without giving the
server the client IP address?
[23:24:41] <sftcd> @pete/richard: it's ok for 1st one
[23:24:41] <Jonathan Hoyland_web_493> Happy to act as Jabber scribe.
[23:24:41] Rolf Sonneveld_web_279 joins the room
[23:24:45] Wassim Haddad_web_438 leaves the room
[23:24:49] Sofia Celi_web_242 leaves the room
[23:24:58] Thom Wiggers_web_405 leaves the room
[23:25:11] whalen@jabber.org joins the room
[23:25:25] <Benjamin Schwartz_web_292> dkg: Yes.  But the mobility thing is also a red herring: the endpoint doesn't see the client IP at all, since this is all through a proxy (e.g. MASQUE, IPSec).
[23:25:26] <Daniel Migault_web_727> @ekr sure. Firefoxe private network. Took me some time to check.
[23:25:33] Mo Zanaty_web_450 joins the room
[23:25:43] <Alissa Cooper_web_751> Seems like this narrow set of use cases where the properties that this provides are needed could be better documented.
[23:25:44] <Benjamin Schwartz_web_292> kaduk: Go through a proxy.
[23:25:50] <kaduk@jabber.org/barnowl> (I joined the queue to channel sftcd's question about locating the
HPKE public key, though I think it's out of scope)
[23:25:50] <Martin Thomson_web_799> The public key design for TLS is something that existed, but it would still be a LOT more overhead.
[23:26:01] <ekr@jabber.org> @Daniel: correct. FPN, like Tor, egresses into a generic TCP connection, so you can connect to any server
[23:26:02] <Patrick Tarpey_web_364> struggling to see the real use cases here....
[23:26:16] <Richard Barnes_web_481> queue is cut after Ben Kaduk
[23:26:23] <Dominique Lazanski_web_199> @Alissa - I was just going to say the same thing. Use case limitations need to be better articulated and documented.
[23:26:32] <Martin Thomson_web_799> keep in mind that you need QUIC for that (not everywhere) and the handshake size is prohibitive
[23:26:35] <Richard Barnes_web_481> ok, fine, after Tommy, assuming he didn't see this
[23:26:35] <Jason Livingood_web_872> +1 to Alissa's comment - would love to see very specific documented use cases
[23:26:42] <Jari Arkko_web_522> +1 to Alissa as well
[23:27:04] <dkg> isn't ODOH the primary motivating use case?
[23:27:14] <Andrew Campling_web_920> +1 to Alissa too, just bringing this to the mike
[23:27:15] <Richard Barnes_web_481> ODoH, telemetry, safe browsing have all been described
[23:27:25] Markus Amend_web_163 leaves the room
[23:27:26] <Éric Vyncke_web_972> a well delimited 'domain' would be nice indeed
[23:27:27] <Daniel Migault_web_727> @ekr what is unclear to me is why ohttp is more specific than FPN.
[23:27:28] <Vittorio Bertola_web_262> Just stating in the charter that "this is not for general browsing" would have made things clearer since the beginning
[23:27:31] <Ted Hardie_web_425> @dkg from my understanding yes.  But Erik's point about map tiles is a good one, as it would be similar data.
[23:27:32] <Zaheduzzaman Sarker_web_668> +1 to Allisa
[23:27:32] <Richard Barnes_web_481> agree that a better general description would be good
[23:27:37] <Patrick Tarpey_web_364> possibly unhelpful to call it oblivious HTTP, given it doesn't use it..
[23:27:46] <ekr@jabber.org> @Daniel: because you are end-to-end encrypting to a server with some format it doesn't understand
[23:27:52] <Andrew S_web_607> +1 to Alissa
[23:27:54] <dkg> ooh, map tiles.  i'd missed that, thanks.  +1 Erik
[23:27:57] <Mark McFadden_web_702> +1 to Andrew
[23:27:58] <ekr@jabber.org> Whereas FPN just lets you make a TLS connection to the server
[23:27:59] <Richard Barnes_web_481> @Patrick - HTTP != browsers
[23:28:02] <Thomas Mangin_web_778> Like Patrick, it would be nice if someone could walk us through a full end-to-end example of how things would work for a DoH resolution.
[23:28:16] <Martin Thomson_web_799> HTTP > browsers
[23:28:25] <sftcd> wrt safe browsing - given that claims to disguise the target about which the client wants info, what's the mega-benefit of ohttp for that use-case?
[23:28:27] <Jari Arkko_web_522> +1 on discovery needed
[23:28:32] <sftcd> (not doubting, just asking)
[23:28:37] <dkg> it's almost like OHTTP is making HTTP into a stateless protocol 😛
[23:28:40] <ekr@jabber.org> safe browsing's PIR is not good
[23:28:44] <Mark McFadden_web_702> +1 on discovery as well.
[23:28:46] <ekr@jabber.org> I can explain more in detail
[23:28:48] <kaduk@jabber.org/barnowl> dkg: haha
[23:28:48] <ekr@jabber.org> later
[23:28:52] <Patrick Tarpey_web_364> safe browsing, telemetry, seems very edge...
[23:28:53] <Dominique Lazanski_web_199> +1 on discovery too
[23:28:58] <Mark Nottingham_web_885> This is a constraint of HTTP; to meet the use cases you have to use it in a very specific way. It's clearly a HTTP variant, but it's very prone to being misunderstood.
[23:29:00] Leif Hedstrom_web_968 leaves the room
[23:29:10] Markus Amend_web_768 joins the room
[23:29:18] <kaduk@jabber.org/barnowl> Ah, Richard channeled Stephen for me already, so I will leave the
queue.
[23:29:27] <Alissa Cooper_web_751> I wouldn't describe the use cases as limitations, but I certainly had this a-ha moment just now when triangulating the low-latency + unlikability + need for server mods + pre-arrangement between client/server and proxy == set of properties
[23:29:27] <Mark Nottingham_web_885> Would people who advocate discovery actually address what their use case is?
[23:29:31] Korry Luke_web_250 joins the room
[23:29:34] Samuel Weiler_web_324 leaves the room
[23:29:34] <kaduk@jabber.org/barnowl> Eliot: queue is cut
[23:29:39] <sftcd> @kaduk: thanks for trying :-)
[23:29:41] <Mark Nottingham_web_885> Discovery does not magically prevent centralisation.
[23:29:42] Samuel Weiler_web_131 joins the room
[23:29:59] <Jari Arkko_web_522> I have a question on the ODOH use case. Does that need this functionality, that could certainly be done in a more application specific way, could it not? Also, oblivious DNS is not the only solution to the problems of DNS data grab... confidential computing for instance is another method, there may be more.
[23:30:06] <Éric Vyncke_web_972> what is the difference between "safe browsing" and "browsing" except filtering ? So, OHTTP could be used for plain HTTP ?
[23:30:12] <Richard Barnes_web_481> there will be time for more wide-ranging discussion in the charter portion
[23:30:18] Erik Kline_web_793 joins the room
[23:30:23] <Christopher Wood_web_401> @Jari: The application-specific variant of OHTTP for DNS is ODoH, right?
[23:30:28] <Richard Barnes_web_481> @Éric - Safe Browsing is a specific Google API
[23:30:29] <ekr@jabber.org> Eric: Safe Browsing is: https://safebrowsing.google.com/
[23:30:34] <ekr@jabber.org> It's a reputation system
[23:30:40] <Lucas Pardue_web_689> You could call it Noble HTTP, because it's hard to bond requests together
[23:30:41] <Richard Barnes_web_481> https://safebrowsing.google.com/
[23:30:42] <Éric Vyncke_web_972> Thanks Ekr & Richard
[23:30:52] <Daniel Migault_web_727> @ekr thanks for the response.
[23:30:53] <Tommy Jensen_web_527> Nobody wants to have the ADD discussion here, +1
[23:30:54] <Martin Thomson_web_799> https://datatracker.ietf.org/doc/html/draft-wood-key-consistency btw
[23:30:57] <Mark Nottingham_web_885> I'll just bring it up in the next segment :)
[23:30:57] <Erik Nygren_web_563> Some of the best use-cases may be closed-system ones (eg, an Maps application uses a combination of a global distributed proxy service operated by one party, and a CDN operated by another party).  In that concrete case, all of the configuration would be in the Map application and it could fetch tiles (lots of little small objects) but without either party getting information on client location.
[23:31:01] <sftcd> @eric: IIUC the safe-browsing query doens't expose the target but (for now) only the requestor (but open to correction)
[23:31:05] <ekr@jabber.org> Jari: I don't know speicfically what you mean by "confidential computing", but all of the available MPC-type mechanisms that you could use for DNS are much more expensive from this.
[23:31:07] <Spencer Dawkins_web_809> I don't  need to say this unless discovery turns out to be gating for OHTTP chartering, but I would like to see some discussion ("somewhere") about the general question of discovery - it's out of scope for OHTTP and for MASQUE, so far this week, and it's only Tuesday ...
[23:31:19] <ekr@jabber.org> sftcd: the safe browsing query exposes a hash of the target
[23:31:30] <ekr@jabber.org> Except that there are actually APIs which expose more
[23:31:32] <David Schinazi_web_243> Spencer, why do you want/need discovery to be in scope somewhere?
[23:31:37] <Jari Arkko_web_522> Martin: we need discovery to avoid applications fixing to a single or few service providers (often Google, Clouflare etc). Yes it is more effort but unfortunately we need to do this, or else this is going to make things worse.
[23:31:37] <ekr@jabber.org> For instance, the URI
[23:31:42] Jay Daley_web_170 leaves the room
[23:31:53] <sftcd> ta
[23:31:57] <Brendan Moran_web_255> So it's like reverse MASQUE?
[23:32:06] <Eliot Lear_web_684> Alexey- I think you are jumping the gun on chartering without allowing at least some substantial discussion about some of the use cases.  I'd like to understand, for instance, who is going to identify BOTs using DNS for C&C
[23:32:09] <Martin Thomson_web_799> Jari: this is Firefox talking to Firefox telemetry servers, should we consider sending our telemetry to Ericsson as well?
[23:32:12] <ekr@jabber.org> Jari: you keep saying that, but the problem is trust, and you haven't provided an answer for that
[23:32:33] <Martin Thomson_web_799> The DNS discovery topic is something I would like to leave to ADD
[23:32:35] <Andrew Campling_web_920> @Spencer I don't believe that we've agreed discovery is out of scope
[23:32:51] <Alissa Cooper_web_751> I don't understand how standardizing a discovery mechanism implies that there will be a minimum number of service providers.
[23:32:59] <Patrick Tarpey_web_364> so it safebrowsing hash check, telemetry, and crash dumps...?
[23:33:04] Ian Swett_web_548 joins the room
[23:33:05] Gustavo Lozano_web_949 leaves the room
[23:33:05] <Martin Thomson_web_799> +1 Alissa
[23:33:14] <cabo> I paid for my whole screen
[23:33:14] <Spencer Dawkins_web_809> @David, I don't actually need THAT, but I'd like for there to be a discussion beyond "it's out of scope". If the answer is "it's out of scope here, see ADD", fabulous.
[23:33:16] Ali Hussain_web_736 leaves the room
[23:33:16] <Thomas Mangin_web_778> Yes, I am still trying to understand how it is intended to be used too
[23:33:17] <kaduk@jabber.org/barnowl> Hmm, comic sans with jagged edges is definitely worse than regular
comic sans
[23:33:17] <Paul Wouters_web_769> obvlious fonts? :P
[23:33:25] <Vittorio Bertola_web_262> It's more like the opposite: without a discovery mechanism it's almost certain that there will not be many service providers (at least in the DNS case)
[23:33:32] <Jana Iyengar_web_431> Tommy -- agreed, though considering that this is describiing a solution for a set of specific problems, it's worth considering other solutions as well that might work well for subsets. I think that a more clear articulation of the problem space is going to be important.
[23:33:34] <Andrew Campling_web_920> @Martin T: Based on its charter, ADD is doing DNS discovery, not proxy or server discovery
[23:33:38] <Martin Thomson_web_799> Paul fonts is a good example, but font fetch is already ... funny
[23:33:40] Nick Banks_web_656 leaves the room
[23:33:46] Nick Banks_web_370 joins the room
[23:33:53] <Daniel Migault_web_727> @martin I expect a standard to be used for other purposes than Firefox speaking to Firefox.
[23:33:55] <nygren> I think MT is just going for Tempest-resistant fonts?
[23:34:03] <ekr@jabber.org> @Daniel: yes, but they all have basically this same property
[23:34:04] <Christopher Patton_web_151> OHTTPAPI?
[23:34:05] <Martin Thomson_web_799> Andrew: the problem there is not fundamentally different than making a choice between DoH and DoT
[23:34:06] <dkg> or reading-resistant fonts
[23:34:11] <ekr@jabber.org> Which is that they are to known API endpoints
[23:34:12] <dkg> grey-on-white, not so keen
[23:34:14] <David Schinazi_web_243> I hear folks wanting discovery, but no one is saying what use case would benefit from discovery. What am I missing?
[23:34:17] <Daniel Migault_web_727> @ekr trust is performed via attestation.
[23:34:18] <ekr@jabber.org> And via *trusted* proxies
[23:34:19] <Ted Hardie_web_425> "Oblivious proxy relay protocol" seems less likely to engender confusion, but it is less sexy.
[23:34:24] <ekr@jabber.org> Daniel, no I don't think so
[23:34:50] <ekr@jabber.org> Attestation of *what*?
[23:34:52] <Martin Thomson_web_799> proxied oblivious relay protocol - PORP
[23:35:06] <Mike Bishop_web_188> While this isn't useful for general browsing, there are browser-based aspects that might benefit from it.  Map tiles is a good example of that.
[23:35:07] <Andrew Campling_web_920> @David to reduce centralisation, to avoid letting the client decide etc
[23:35:13] <cabo> HTTP Oblivious Proxy Protocol — HOPP
[23:35:16] <ekr@jabber.org> Andrew: how would that happen?
[23:35:24] <David Schinazi_web_243> @Andrew that's not a use case though
[23:35:24] <Daniel Migault_web_727> @ekr open source code or code you trust.
[23:35:24] <Ted Hardie_web_425> Proxying relay for oblivious data (PROD)?
[23:35:25] <Jonathan Lennox_web_149> Martin: Can you extend the acronym to spell PORPOISE?
[23:35:28] <ekr@jabber.org> We don't let the client choose trust anchors
[23:35:34] <Glenn Deen_web_392> ONSFW?
[23:35:42] <dkg> i like HOPP
[23:35:43] <ekr@jabber.org> Or rather, we mostly don't. They can, but it's not a standard use case
[23:35:48] <Martin Thomson_web_799> Glenn: trying to imply something?
[23:35:53] <Mike Bishop_web_188> For cases where the same entity owns both sides of the connection and is deliberately blinding itself, discovery isn't needed.  When it's not, there needs to be a way to find the endpoint.
[23:35:54] <Patrick Tarpey_web_364> whats the business model for running part of the oblivious infrastructure ?
[23:35:58] <Glenn Deen_web_392> @martin use-cases
[23:36:09] <John Border_web_950> What part(s) of the proposed charter resulted in the AD blocks?
[23:36:09] <Shivan Sahib_web_272> The draft currently says "A proxy MUST NOT add information about the client identity when forwarding requests". I'd imagine an application might want to implement shadowbanning i.e. the proxy adds metadata saying "isMalicious" or something (but doesn't leak the actual IP to the server). Is that metadata considered "information about the client identity"? Might be worth clarifying in text.
[23:36:12] <ekr@jabber.org> Patrick: prior arrangement with the origin server
[23:36:16] <kaduk@jabber.org/barnowl> Mike: When would you use it when it's not a single entity blinding itself?
[23:36:17] <Martin Thomson_web_799> Patrick: the server or client would pay a proxy in the telemetry case, likely
[23:36:25] <Spencer Dawkins_web_809> @David, it seems reasonable to say "how does discovery work?", and if the answer is "we don't need to worry about that because we're assuming that $Entity will provide configuration information if it's needed", that's a fine answer.
I'm just curious about whether we're playing https://en.wikipedia.org/wiki/Whac-A-Mole here.
[23:36:28] <dkg> Mike: there still needs to be a way to learn the proxy in that case
[23:36:38] <Martin Thomson_web_799> Mnot: yeah, it's a new HTTP application
[23:36:39] <sftcd> go? not rust?
[23:36:39] <dkg> if the user is deliberately triyng to blind the client
[23:36:42] Stephen Farrell_web_720 leaves the room
[23:36:43] <Jari Arkko_web_522> Martin, Ekr: I understand that it is nice to fix a particular service provider in an app such as a browser. But I don't think that's in the benefit of the users. I don't discovery models need to be super complex though, perhaps "anything trusted by <configured party>" is a start, allowing new things to offer service if they are trusted by the root key.
[23:37:03] Rui Paulo_web_182 joins the room
[23:37:06] <ekr@jabber.org> Jari: see Mark's email. That's not a protocol problem but a client-side problem
[23:37:08] <Jari Arkko_web_522> But, the point is, we need this or else this is going to concentrate trafifc even more -- and we do need some trust on the proxy.
[23:37:09] Kazunori Fujiwara_web_349 leaves the room
[23:37:14] Hannu Flinck_web_809 leaves the room
[23:37:31] Stephen Farrell_web_797 joins the room
[23:37:32] <Spencer Dawkins_web_809> +1 Jari. Any answer would be fine, but no answer seems sketchier.
[23:37:35] <Richard Barnes_web_481> @Jari - How does this create more concentration that picking a server in the first place?
[23:37:39] <Mike Bishop_web_188> @Kaduk, it would be nice to use, say, maps.google.com without revealing my GPS location to Google.  That's a use-case where a browser-website connection would employ this usefully.
[23:37:41] <francesca> @John Border_web_950 see https://datatracker.ietf.org/doc/charter-ietf-ohttp/ballot/
[23:37:50] <Patrick Tarpey_web_364> I thought oblivious architecture relies on non collusion? neither party can see - who verifies this ?
[23:37:53] <John Border_web_950> Thanks
[23:37:57] <Sean Turner_web_433> use case = applicability statement I hope
[23:37:58] Kazunori Fujiwara_web_746 joins the room
[23:37:59] John Kaippallimalil_web_577 leaves the room
[23:38:03] <ekr@jabber.org> Patrick: that's a general problem with any MPC system
[23:38:12] <ekr@jabber.org> And we don't solve it here any more than in those systems
[23:38:15] <Zaheduzzaman Sarker_web_668> +1 to Mark
[23:38:24] <Kazuho Oku_web_387> +1 to mnot. This is relatively lightweight and we can have this for specific use-cases.
[23:38:31] <Ted Hardie_web_425> @Jari For some of the use cases (e.g. Safe Browsing) this is not a change to the single supplier model, but it is an improvement in privacy.  But teasing out which ones of the use cases meet that test would be useful.
[23:38:35] <kaduk@jabber.org/barnowl> Mike: don't you need google to buy-in to the server side of that?
If google bought in, google could serve up the maps page with logic to
do this
[23:38:50] <Richard Barnes_web_481> @Jari @Ted it might be useful to bring this discussion to the mic
[23:39:00] Lin Han_web_111 leaves the room
[23:39:17] <Spencer Dawkins_web_809> +1 about Richard's mic comment.
[23:39:18] <Patrick Tarpey_web_364> For it to be "worthwhile"  for safe browsing you need to believe in non collusion...
[23:39:36] <kaduk@jabber.org/barnowl> Kind of lousy SNR from Eliot, at least as delivered here
[23:39:39] <francesca> I was going to say: any significant comment please bring them to the mic, it will be much easier to recap the discussion since these are minuted
[23:39:39] Nigel Hickson_web_161 leaves the room
[23:39:46] <Spencer Dawkins_web_809> Our time here is really precious, and if the real BOF is happening in jabber, that's unfortunate.
[23:39:54] <sftcd> @mic: we have Tor (albeit we don't have a way to standarise Tor in practice) - are we better off standardising these "point" solutions or aiming for a more generic Tor-like scheme that has broader applicability?
[23:39:56] <Ted Hardie_web_425> Okay, I joined the mic line; if Jari joins, I'll drop and re-join, since his comments are prior to mine.
[23:40:05] <nygren> And for the maps.google.com example, you could see Google supporting this on their tile service, but then working with another party to operate the proxy.  My expectation here is that clients would authenticate to the proxy and the proxy would authenticate to the tile service.  The hop-by-hop auth would be to reduce abuse and keep it to the constrained use.
[23:40:12] <Jason Weil_web_712> I fee like the term 'safe browsing' has multiple meanings in this discussion
[23:40:15] <francesca> (yes chat is logged as well but... if we can avoid having to go through, it would be appreciated)
[23:40:17] <Mike Bishop_web_188> @Kaduk, that's fair; if this can be implemented in JS, Google could ship the client in the page source.
[23:40:32] <Patrick Tarpey_web_364> safe browsing API - hashed prefix lookup...
[23:40:40] Jonathan Rosenberg_web_117 leaves the room
[23:40:44] Jonathan Rosenberg_web_519 joins the room
[23:41:15] <ekr@jabber.org> To be clear: Safe Browsing is much more than hash prefix: there is also a straight URL lookup which is needed for some things
[23:41:15] Qin Wu_web_617 joins the room
[23:41:19] Nigel Hickson_web_787 joins the room
[23:41:29] <kaduk@jabber.org/barnowl> Mike: (It's not entirely clear to me that google's maptile server
would need to be modified to support this specifically, though you
might have trouble if you use a proxy not trusted by google that gets
rate-limited or banned.)
[23:41:57] Dan Druta_web_706 leaves the room
[23:42:35] <sftcd> aside: I miss the body-language of the people in the mic-queue ;-)
[23:42:40] Dan Druta_web_314 joins the room
[23:42:48] Will Hawkins_web_571 leaves the room
[23:42:54] <Jonathan Hoyland_web_493> @sftcd I'm happy to relay your comment.
[23:43:01] <sftcd> ta
[23:43:03] <Jonathan Hoyland_web_493> (and am in the queue)
[23:43:03] <Lucy Lynch_web_628> are we assuming a charter?
[23:43:04] <ekr@jabber.org> does anyone else have video?
[23:43:10] <John Preuß Mattsson_web_479> jari
[23:43:10] <Lars Eggert_web_589> nope
[23:43:15] <ekr@jabber.org> the chairs presetned a charter a few minutes ago
[23:43:15] <David Schinazi_web_243> I'm not receiving any video
[23:43:15] <Cullen Jennings_web_205> nope
[23:43:17] <Jonathan Hoyland_web_493> Nope
[23:43:18] Jonathan Reed_web_755 leaves the room
[23:43:23] <Martin Thomson_web_799> video is gone
[23:43:23] <Jari Arkko_web_522> FWIW, I think it should be fine for people to say that certain things need to be considered by the WG. In the charter.
[23:43:26] <Jonathan Lennox_web_149> Looks like no one has video or slides enabled?
[23:44:06] Greg Wood_web_810 leaves the room
[23:44:24] Greg Wood_web_810 joins the room
[23:44:25] <Éric Vyncke_web_972> @Ben S, the trust links is really puzzling me as well even after @Ekr's explanations earlier
[23:44:32] <ekr@jabber.org> What's confusing?
[23:44:33] <Martin Thomson_web_799> There is a multi-page section in the draft on this point @Ben S.
[23:44:50] <Daniel Migault_web_727> +1 ben, that is one of my concern.
[23:45:04] <Martin Thomson_web_799> Whether it is sufficient or not is debatable of course, but it is there and clearly in scope for a working group
[23:45:12] <ekr@jabber.org> The point here is to create a situation in which the both parties need to collude in order to track the user
[23:45:17] <Wes Hardaker_web_757> I've wondered how many sites will do the "we noticed you're using a adware blocker -- sorry, go away" with this as well.
[23:45:18] Jason Weil_web_712 leaves the room
[23:45:23] <Christopher Wood_web_401> @Ben: what would be the deliverable?
[23:45:24] <ekr@jabber.org> It's like a really standard Multi-party Computation assumption
[23:45:24] Jason Weil_web_486 joins the room
[23:45:28] <Richard Barnes_web_481> @Wes - Not Browsing
[23:45:33] <Mark Nottingham_web_885> Wes - Not Browsing
[23:45:36] <Éric Vyncke_web_972> @Erk I understood that client and server are the same person/org ?
[23:45:42] <Thomas Mangin_web_778> Yes, I would also like to see this trust information too
[23:45:47] <Wes Hardaker_web_757> understood, but they still want to track you over multiple protocols
[23:45:50] <Martin Thomson_web_799> @Ben S please send text, because that reads like "applicability" to me.
[23:45:51] <Thomas Mangin_web_778> It would really help to understand things
[23:45:57] <ekr@jabber.org> Eric: sure, quite possibly. See, for instance, Firefox talking to Mozilla Telemetry
[23:46:04] <Mark Nottingham_web_885> Wes - we should be enabling that?
[23:46:08] Toerless Eckert_web_889 joins the room
[23:46:10] spencerdawkins joins the room
[23:46:10] <ekr@jabber.org> Or working together as in Firefox talking to a TRR
[23:46:19] <Eliot Lear_web_684> Do the implementors envision clients authenticating to the proxies?
[23:46:25] <ekr@jabber.org> Eliot: probably not.
[23:46:31] <sftcd> good
[23:46:32] Markus Amend_web_768 leaves the room
[23:46:36] Markus Amend_web_552 joins the room
[23:46:40] <ekr@jabber.org> But of course you could with TLS Client Auth if you wanted to for some <shudder> reason
[23:46:55] <sftcd> bad
[23:46:57] Rolf Sonneveld_web_279 leaves the room
[23:47:01] <ekr@jabber.org> +1 on bad!
[23:47:46] <Ted Hardie_web_425> MT was really choppy at the beginning for me.
[23:47:51] <ekr@jabber.org> still is choppy
[23:47:53] <sftcd> I wonder if that good/bad exchange touches on my earlier question about point solutions vs. an attempt at a Tor-like thing
[23:47:53] Jonathan Rosenberg_web_519 leaves the room
[23:47:54] <francesca> MT stop playing with the mic
[23:47:55] <nygren> Auth from the proxy to the server might almost or more relevant.
[23:47:57] Jonathan Rosenberg_web_139 joins the room
[23:47:59] <Patrick Tarpey_web_364> So by and large this functionality will be implemented behind the scenes  for "telemetry", "safe browsing",   -hard coded as discovery is out of scope of this working group...
[23:48:09] <sftcd> MT is eating the delivered-meat
[23:48:10] <Jonathan Lennox_web_149> Sounds like a loose mic cable
[23:48:11] <Suhas Nandakumar_web_636> audio is bad
[23:48:15] <Zaheduzzaman Sarker_web_668> very hard to hear what Martin said
[23:48:17] <ekr@jabber.org> @nygren: yeah, though typically those people just use IP for this kind of thing
[23:48:21] <Martin Thomson_web_799> OK, that was bad, sorry about that
[23:48:29] Qiaoyu Deng_web_130 leaves the room
[23:48:31] <Hannes Tschofenig_web_140> Let's collect some money for a new microphone
[23:48:32] <Mark Nottingham_web_885> @sftcd: he's too far away. Thankfully.
[23:48:32] <Martin Thomson_web_799> Yes, this is in the charter already, at least to me.
[23:48:34] Qiaoyu Deng_web_605 joins the room
[23:48:40] <spencerdawkins> I certainly struggled to make out the words
[23:48:47] <nygren> Having a way for the server to indicate abuse back to the proxy might be also interesting.
[23:48:50] <Jason Livingood_web_872> MT sounded like the announcers on my public transit system. ;-)
[23:48:51] <ekr@jabber.org> FWIW, I would imagine that if we needed to publish keys, we could invent some /.well-known type format
[23:48:54] Qiaoyu Deng_web_605 leaves the room
[23:49:05] Qiaoyu Deng_web_431 joins the room
[23:49:05] <ekr@jabber.org> nygren: you can just do that by sending the hash of the offendng request
[23:49:11] <Andrew Campling_web_920> @Patrick As the charter hasn't been agreed, IMO people are being premature in saying what is out of scope
[23:49:26] <sftcd> @ekr: wouldn't a .well-known scheme have some bootstrapping issues?
[23:49:27] <Martin Thomson_web_799> Eric Orth:  In addition, the working group may work on other use cases and deployment models, including those that involve discovery of OHTTP proxies or servers +++ or their keying material +++.
[23:49:31] <Mark Nottingham_web_885> For all of the folks suggesting new capabilities: you should be asking yourselves why they shouldn't be proposed for HTTP itself, given that it has broader applicability.
[23:49:49] <ekr@jabber.org> @sftcd: sort of. the real problem is ensurign key consitency
[23:49:50] <Martin Thomson_web_799> That comes with a lot of machinery, unfortunately.  Wishing-pony territory, sadly.
[23:49:58] <ekr@jabber.org> key consistency
[23:50:01] <nygren> Or some other response header back to the proxy.
[23:50:21] <Martin Thomson_web_799> sftcd: https://datatracker.ietf.org/doc/html/draft-wood-key-consistency
[23:50:21] <Matthew Finkel_web_244> key consistency and discovery have come up in many working groups
[23:50:25] <Eliot Lear_web_684> @Tommy it would be good to have an operational flow for that sort botnet remediation.
[23:50:38] <ekr@jabber.org> Matthew: yes, and they are a mess in all of them :)
[23:50:47] <Matthew Finkel_web_244> I am aware :)
[23:51:10] Andrei Popov_web_767 leaves the room
[23:51:28] <Matthew Finkel_web_244> but I don't know where that discussion belongs
[23:51:29] <Martin Thomson_web_799> GIANT PINK BOX
[23:51:52] <Carrick_web_582> I'm not sure why discovery can necessarily be so one-size-fits-all?
[23:52:15] <sftcd> @tommy: I worry that "solving" some of these point things that aren't very generic might preclude what's really needed later
[23:52:17] <ekr@jabber.org> @DavidSchinazi: you are precisely correct
[23:52:17] <Richard Barnes_web_481> just shove it all in the DNS, amirite
[23:52:39] <Martin Thomson_web_799> AIA chasing is another one that Chrome might like
[23:52:40] <David Oliver_web_744> "safe browsing" are terribly overloaded words
[23:52:41] <Andrew Campling_web_920> @Carrick agreed, just because OHHTP and DNS need discovery, it doesn't mean that the same method will work for both
[23:52:49] Paolo Saviano_web_909 joins the room
[23:52:50] <David Oliver_web_744> David is really making that clear.
[23:52:51] <Matthew Finkel_web_244> service discovery is separate from key discovery. service discovery is not unique to this protocol.
[23:52:53] <Carrick_web_582> @Richard Right but what you shove in DNS might be different, depending on what it is?
[23:52:58] Watson Ladd_web_318 joins the room
[23:53:03] James Gruessing_web_861 joins the room
[23:53:05] <Christopher Wood_web_401> +1 Matthew
[23:53:12] <Ted Hardie_web_425> The cooperate-but-not-collude proxy relay service protocol for decreased linkability WG (ODOH)
[23:53:13] Paolo Saviano_web_909 leaves the room
[23:53:15] <sftcd> snark: chrome providing google with *less* information?
[23:53:18] <Phillip Hallam-Baker_web_159> Hmmm these are very interesting requirements... but not ones I would want to use this approach for :-)
[23:53:19] <Mark Nottingham_web_885> Right - if you need discovery, it's for the application *using* OHTTP.
[23:53:24] Al Morton_web_327 leaves the room
[23:53:42] Nigel Hickson_web_787 leaves the room
[23:53:51] <Jason Weil_web_486> I agree with David's def of safe browsing more so than some of the others I have heard here (total anonymity) but they are both useful in different use cases.
[23:53:55] <Christopher Wood_web_401> r.e. hard problem -- see ADD.
[23:54:09] <Jari Arkko_web_522> Just because we have a special use case does not mean there are no centralization concerns. If we had discovery for DNS for instance, we would not want to undo that effect by having a proxy that still concentrates everything.
[23:54:12] Kazunori Fujiwara_web_746 leaves the room
[23:54:13] <Martin Thomson_web_799> Jason: "safe browsing" is a term of art.  apologies for not defining it properly
[23:54:18] Kazunori Fujiwara_web_987 joins the room
[23:54:29] <Phillip Hallam-Baker_web_159> @sftcd Google already know everything on everyone. They have to protect their competitive advantage
[23:54:37] Dirk Hugo_web_535 leaves the room
[23:54:54] <dkg> the question seems to be whether we're solving "self-blinding for network services that can contract with a blinding proxy operator" or "users defending themselves from info-gathering from cooperating network services"
[23:54:58] <ekr@jabber.org> @jari: It's really incumbent on you to define a general case
[23:54:59] <Lucy Lynch_web_628> @jari +1
[23:55:00] <Mark Nottingham_web_885> Jari: If the requirement is for a HTTP-like protocol to *preclude* the possibility of a centralised service, that's pretty much impossible.
[23:55:00] <nygren> CRL/OCSP might be an interesting use-case (although harder since the OHTTP server might itself need to be a proxy)
[23:55:06] <sftcd> @phb: our job here ought IMO be to make that harder for people who want it to be harder
[23:55:12] <Jason Weil_web_486> the use cases may result in different requirements in the wg
[23:55:13] <Francois Ortolan_web_796> +1 Jari
[23:55:16] <Andrew Campling_web_920> @Jari +1
[23:55:19] <Vittorio Bertola_web_262> +1 @dkg - that's still unclear
[23:55:25] Alan Frindell_web_990 leaves the room
[23:55:26] <Martin Thomson_web_799> SEND TEXT
[23:55:29] <Patrick Tarpey_web_364> +1 OCSP as a use case would useful
[23:55:30] Alan Frindell_web_901 joins the room
[23:55:33] <sftcd> TEXT
[23:55:33] <Chris Lemmons_web_804> dkg: It really seems like it's the former and not the latter, but perhaps I've misunderstood.
[23:55:34] <Sean Turner_web_433> Stick that in the applicability statement paragraph!
[23:55:34] <ekr@jabber.org> It's actually not unclear, because everyone who wants to do this has told you it's the first
[23:55:35] <Shivan Sahib_web_272> Privacy-preserving prefetch might benefit from OHTTP
[23:55:41] Stephen Farrell_web_797 leaves the room
[23:55:45] Stephen Farrell_web_262 joins the room
[23:55:47] <dkg> Lemmons: yes, that's what we're landing on, i think.
[23:56:02] <ekr@jabber.org> If you want (2), it's MASQUE with a client-selected proxy
[23:56:08] <Martin Thomson_web_799> Tor != ohttp
[23:56:10] <Benjamin Schwartz_web_292> Self-blinding seems like ... a technical solution for a non-technical problem.
[23:56:14] <Martin Thomson_web_799> completely different things
[23:56:21] <Dominique Lazanski_web_199> use cases and security implications as well
[23:56:25] <Alissa Cooper_web_751> Tor seems to be addressing a rather different set of use cases
[23:56:29] <sftcd> so @mic gets no answer;-(
[23:56:31] <dkg> Benjamin Schwartz_web_292: you mean like "don't keep logs" ?
[23:56:48] <sftcd> if we had a standardised Tor like thing, then would we need ohttp?
[23:56:50] <Benjamin Schwartz_web_292> dkg: Right.  Publish a legal document saying you don't keep logs, and don't tie us up in crypto.
[23:57:08] <Richard Barnes_web_481> @sftcd - this has been addressed -- different operational properties
[23:57:11] <sftcd> is that an assertion that masque ~~== Tor?
[23:57:22] <dkg> Benjamin Schwartz_web_292: the difference here is that presumably you hold your proxy at arms length
[23:57:27] <dkg> then an attacker has to compromise you both
[23:57:28] <kaduk@jabber.org/barnowl> it sounded like an assertion that masque ~~== Tor, yes
[23:57:30] <Christopher Patton_web_151> it's pretty clear that masque != tor
[23:57:33] <Martin Thomson_web_799> no, that is an assertion that we already have all of the things in that space covered
[23:57:34] <John Preuß Mattsson_web_479> Stating that the Google will chose on behalf of the user seems wrong. I would like to chose myself.
[23:57:35] <Chris Lemmons_web_804> ben: Not quite, because this allows the user to "spread their trust". They only have to trust the proxy to not share their info and trust the origin to provide valid information.
[23:57:36] <Mark Nottingham_web_885> https://www.ietf.org/archive/id/draft-thomson-http-oblivious-01.html#name-applicability
[23:57:36] <ekr@jabber.org> @Benjamin, @DKG: we generally feel that technical approaches are superior to policy solutions where possible
[23:57:38] Robert Story_web_936 joins the room
[23:57:40] <Benjamin Schwartz_web_292> dkg: and how do I, the user, know that the relationship is actually at arms length?
[23:57:45] <sftcd> my concern is that we're wrapping ourselves around axles that may not be that telling in the end
[23:57:57] <ekr@jabber.org> Benjamin: you of course do not, but now you have to distrust *two* people
[23:57:59] <Jonathan Hoyland_web_493> @Chris Wood @sftcd TOR has different goals
[23:58:03] <Richard Barnes_web_481> @Benjamin - How do you know that the relationship between a browser and a CA is arm's length?
[23:58:04] <David Schinazi_web_243> Tor is a proxying protocol coupled with a discovery and circuit building system. MASQUE is similar to the first part here, not the others
[23:58:13] <sftcd> in which case I consider my question non-answered
[23:58:14] <Patrick Tarpey_web_364> Is the threat actor really a "global passive" adversary ? I thought it was the end-point ..?
[23:58:16] <Benjamin Schwartz_web_292> Richard: I don't.  I trust the browser.
[23:58:23] <dkg> Benjamin Schwartz_web_292: you can't, but it's still a different political/social dynamic between the players
[23:58:28] <Mark Nottingham_web_885> Could folks asking for use cases please make their request relative to https://www.ietf.org/archive/id/draft-thomson-http-oblivious-01.html#name-applicability ?
[23:58:28] <Jonathan Hoyland_web_493> TOR is protection against global passive adversary, OHTTP doesn't try and provide any protection against that.
[23:58:31] <Christopher Wood_web_401> To be clear: MASQUE + some other stuff is basically isomorphic to Tor.
[23:58:35] <Jonathan Lennox_web_149> Ben: the service provider (i.e. Mozilla) has the incentive to be able to say "I don't have, and cannot have, that information" in response to a subpoena.
[23:58:50] Kazunori Fujiwara_web_987 leaves the room
[23:58:52] <Benjamin Schwartz_web_292> Lennox: IMHO you're getting closer to the mark...
[23:58:54] <ekr@jabber.org> Uh, this *is* ODoH
[23:58:59] <dkg> "Tor" itself can also mean both the network and the browser that uses the network
[23:59:02] <Matthew Finkel_web_244> Jonathan, Tor doesn't protect against a global passive adversary (unfortunately)
[23:59:09] Jesus Martin_web_828 leaves the room
[23:59:10] <Matthew Finkel_web_244> but that seems out of scope for this protocol
[23:59:30] <Jonathan Hoyland_web_493> @Matthew, it doesn't succeed, but that doesn't mean that it's not the goal of the protocol.
[23:59:43] <sftcd> @matthew: but doesn't it have that as it's goal? maybe that goal is a better one for us to spend effort towards meeting?
[23:59:55] David K_web_441 leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!