IETF
ohai
ohai@jabber.ietf.org
Monday, November 8, 2021< ^ >
Room Configuration
Room Occupants

GMT+0
[06:19:16] Glen joins the room
[06:19:20] Glen leaves the room
[13:21:22] Yoshiro Yoneya joins the room
[13:41:39] dkg joins the room
[14:03:04] Meetecho joins the room
[14:15:03] Watson Ladd_web_374 joins the room
[14:15:03] Stephen Farrell_web_576 joins the room
[14:15:03] Richard Barnes_web_352 joins the room
[14:15:03] Peter van Dijk_web_179 joins the room
[14:15:03] Tobias Pulls_web_652 joins the room
[14:15:03] Yoshiro Yoneya_web_459 joins the room
[14:15:03] Patrick Tarpey_web_369 joins the room
[14:15:03] Deb Cooley_web_121 joins the room
[14:15:03] Lorenzo Miniero_web_808 joins the room
[14:15:03] Olaf Kolkman_web_775 joins the room
[14:15:03] Daniam Henriques_web_680 joins the room
[14:15:03] Markus de Brün_web_765 joins the room
[14:15:03] Daniel Gillmor_web_742 joins the room
[14:15:03] Alessandro Toppi_web_954 joins the room
[14:19:13] Eric Kinnear_web_631 joins the room
[14:19:44] Tommy Pauly_web_912 joins the room
[14:19:51] Christopher Wood_web_928 joins the room
[14:19:58] Richard Barnes_web_352 leaves the room
[14:20:02] Richard Barnes_web_123 joins the room
[14:20:16] Richard Barnes_web_123 leaves the room
[14:20:19] Yuya Kawakami_web_417 joins the room
[14:20:20] Richard Barnes_web_188 joins the room
[14:20:34] Eric Kinnear_web_631 leaves the room
[14:20:37] Martin Thomson_web_115 joins the room
[14:21:05] Shivan Sahib_web_549 joins the room
[14:21:37] Benjamin Schwartz_web_637 joins the room
[14:21:39] Patrick Tarpey_web_369 leaves the room
[14:22:06] <Richard Barnes_web_188> Good morning / afternon / evening, everyone.  We will get started in a few minutes
[14:22:15] alexamirante joins the room
[14:22:16] Ted Hardie_web_704 joins the room
[14:22:35] Eric Rosenberg_web_956 joins the room
[14:22:45] <Shivan Sahib_web_549> Hi all!
[14:22:57] <Tommy Pauly_web_912> O, hai!
[14:23:33] Eric Kinnear_web_124 joins the room
[14:23:50] Kenneth Murchison_web_122 joins the room
[14:24:18] Florence D_web_270 joins the room
[14:24:28] <Christopher Wood_web_928> +1 can hear you
[14:24:28] <Watson Ladd_web_374> we can hear you
[14:24:30] <Martin Thomson_web_115> working
[14:24:36] <dkg> we canhear you
[14:24:40] Chen Li_web_449 joins the room
[14:24:40] <Richard Barnes_web_188> thanks
[14:24:46] Sean Turner_web_669 joins the room
[14:25:01] Eric Kinnear_web_124 leaves the room
[14:25:02] Kazunori Fujiwara_web_172 joins the room
[14:25:05] Eric Kinnear_web_197 joins the room
[14:25:05] Cullen Jennings_web_680 joins the room
[14:25:25] Christopher Patton_web_680 joins the room
[14:25:26] Harald Alvestrand_web_816 joins the room
[14:25:35] Nicholas Gajcowski_web_513 joins the room
[14:25:36] <Ted Hardie_web_704> @tommy shades of lolcode (https://en.wikipedia.org/wiki/LOLCODE)
[14:25:42] npd joins the room
[14:25:48] David Oliver_web_314 joins the room
[14:25:54] <dkg> we need a chekov rule of the IETF video meetings: if a musical instrument shows up in the background, someone has to play it before the meeting concludes.
[14:25:57] Ned Freed_web_771 joins the room
[14:26:00] <Christopher Patton_web_680> oh, hi everyone
[14:26:00] Dominique Lazanski_web_211 joins the room
[14:26:27] Francesca Palombini_web_840 joins the room
[14:26:36] npd waves via Matrix
[14:26:38] <Martin Thomson_web_115> Look at that.  Slides.
[14:26:49] Benjamin Kaduk_web_254 joins the room
[14:26:54] Takahiro Nemoto_web_619 joins the room
[14:26:59] Mark McFadden_web_358 joins the room
[14:27:01] <Richard Barnes_web_188> @Chris make sure to wake the dogs up
[14:27:03] Nick Doty_web_878 joins the room
[14:27:12] Steve Olshansky_web_768 joins the room
[14:27:12] Tadahiko Ito_web_561 joins the room
[14:27:36] Donald Eastlake_web_155 joins the room
[14:27:39] <Christopher Wood_web_928> This is even too early for them
[14:27:44] Chi-Jiun Su_web_321 joins the room
[14:27:45] kaduk@jabber.org/barnowl joins the room
[14:27:45] Eric Kinnear_web_197 leaves the room
[14:27:45] <Watson Ladd_web_374> Let sleeping dogs lie
[14:27:47] <Shivan Sahib_web_549> no snoring dogs heard, might have to re-do that mic check Chris..
[14:27:49] Eric Kinnear_web_406 joins the room
[14:27:53] <Christopher Wood_web_928> =)
[14:28:06] Jiri Novotny_web_168 joins the room
[14:28:10] Samuel Weiler joins the room
[14:28:15] Jonathan Hammell_web_417 joins the room
[14:28:25] Chen Li_web_449 leaves the room
[14:28:29] Chen Li_web_761 joins the room
[14:28:33] John Border_web_659 joins the room
[14:28:36] Eric Orth_web_305 joins the room
[14:28:38] Nick Banks_web_812 joins the room
[14:28:40] Bernie Hoeneisen_web_801 joins the room
[14:28:46] Jari Arkko_web_779 joins the room
[14:28:53] Jeffrey Haas_web_459 joins the room
[14:28:55] Samuel Weiler_web_856 joins the room
[14:28:58] Eric Kinnear_web_406 leaves the room
[14:29:04] Spencer Dawkins_web_662 joins the room
[14:29:04] Alan Frindell_web_112 joins the room
[14:29:07] Scott Rose_web_733 joins the room
[14:29:12] Chris Box_web_328 joins the room
[14:29:14] Luca Niccolini_web_914 joins the room
[14:29:21] <Tommy Pauly_web_912> @Ted yes, exactly! ;)
[14:29:23] Mirja Kühlewind_web_598 joins the room
[14:29:24] Eric Rescorla_web_617 joins the room
[14:29:26] Michael B_web_945 joins the room
[14:29:31] Monika Ermert_web_642 joins the room
[14:29:43] Shinta Sato_web_898 joins the room
[14:29:43] Jeffrey Haas_web_459 leaves the room
[14:29:51] Eric Kinnear_web_983 joins the room
[14:29:55] Mark Nottingham_web_441 joins the room
[14:29:57] Joseph Salowey_web_857 joins the room
[14:29:58] Donald Eastlake_web_155 leaves the room
[14:29:59] David Lawrence_web_263 joins the room
[14:30:01] Andrew S_web_513 joins the room
[14:30:02] Yoav Nir_web_380 joins the room
[14:30:02] Donald Eastlake_web_987 joins the room
[14:30:06] Paul Wouters_web_938 joins the room
[14:30:18] <David Lawrence_web_263> oh hi!
[14:30:25] Nalini Elkins_web_695 joins the room
[14:30:26] Alissa Cooper_web_358 joins the room
[14:30:29] Rikard Höglund_web_297 joins the room
[14:30:30] Allison Mankin_web_962 joins the room
[14:30:33] Quynh Dang_web_959 joins the room
[14:30:33] Joey Salazar_web_648 joins the room
[14:30:36] Chen Li_web_761 leaves the room
[14:30:39] David Schinazi_web_847 joins the room
[14:30:39] James Galvin_web_226 joins the room
[14:30:45] francesca joins the room
[14:30:48] Kazuaki Ueda_web_391 joins the room
[14:30:50] Robin Wilton_web_969 joins the room
[14:30:53] mnot joins the room
[14:30:56] Lucas Pardue_web_203 joins the room
[14:30:57] Xavier de Foy_web_417 joins the room
[14:31:02] Steven Hartley_web_274 joins the room
[14:31:04] Hiroyuki Goto_web_416 joins the room
[14:31:05] <mnot> My eyeballs would really appreciate it if meetecho were to honour dark mode in browsers.
[14:31:06] Vittorio Bertola_web_350 joins the room
[14:31:08] Christian Amsüss_web_252 joins the room
[14:31:08] Phillip Hallam-Baker_web_977 joins the room
[14:31:11] Carl Mehner_web_273 joins the room
[14:31:13] tim costello_web_603 joins the room
[14:31:24] Christopher Inacio_web_248 joins the room
[14:31:26] Taiji Kimura_web_395 joins the room
[14:31:30] Rikard Höglund_web_297 leaves the room
[14:31:34] Chen Li_web_980 joins the room
[14:31:34] sftcd joins the room
[14:31:35] Emiliano Spinella_web_437 joins the room
[14:31:35] Dirk Kutscher_web_233 joins the room
[14:31:36] Jonathan Hoyland_web_487 joins the room
[14:31:41] synp joins the room
[14:31:49] Christian Amsüss_web_252 leaves the room
[14:32:04] Tommy Jensen_web_848 joins the room
[14:32:35] Mallory Knodel_web_632 joins the room
[14:32:48] Andrew Campling_web_180 joins the room
[14:32:51] Donald Eastlake_web_987 leaves the room
[14:32:52] Marco Tiloca_web_455 joins the room
[14:32:55] Mike Bishop_web_247 joins the room
[14:32:55] Donald Eastlake_web_520 joins the room
[14:32:59] Wes Hardaker_web_186 joins the room
[14:33:12] Donald Eastlake_web_520 leaves the room
[14:33:16] Donald Eastlake_web_591 joins the room
[14:33:20] Michael Breuer_web_812 joins the room
[14:33:40] Peter Koch_web_155 joins the room
[14:34:12] <Eric Rescorla_web_617> Note: I am scribing but will only be scribing decisions
[14:34:14] Jonathan Lennox_web_769 joins the room
[14:34:20] Yangtao Deng_web_578 joins the room
[14:34:23] Mike Bishop_web_247 leaves the room
[14:34:27] Mike Bishop_web_453 joins the room
[14:34:30] <Mark McFadden_web_358> Why is it that the name of the protocol is not changing to that of the working group? Just curious.
[14:34:37] Jaime Jimenez_web_832 joins the room
[14:34:42] <Shivan Sahib_web_549> Notes here: https://notes.ietf.org/notes-ietf-112-ohai
[14:34:42] <Martin Thomson_web_115> the meeting is recorded, so capturing decisions is the only thing that is really necessary
[14:34:43] Mo Zanaty_web_701 joins the room
[14:34:45] <Eric Rescorla_web_617> Well, the protocol hasn't been adopted, so asking for that is in order
[14:34:59] Mike Bishop_web_453 leaves the room
[14:34:59] <mnot> Mark: That's TBD
[14:35:00] Dan McArdle_web_749 joins the room
[14:35:03] Mike Bishop_web_514 joins the room
[14:35:07] Colin Perkins_web_676 joins the room
[14:35:11] <Mark McFadden_web_358> @moot - thanks.
[14:35:12] <Martin Thomson_web_115> Mark: what the others said and also because I'm writing the draft and I think that it should be called Oblivious HTTP.
[14:35:32] <Martin Thomson_web_115> (I don't think that Chris cares.)
[14:35:35] <Eric Rescorla_web_617> If we are discussing changing the name, I will be proposing KTHX
[14:35:45] <mnot> +1
[14:35:50] <Eric Rescorla_web_617> Keyed Transactions for HTTP eXchanges
[14:35:57] Jared Mauch_web_369 joins the room
[14:35:57] Yangtao Deng_web_578 leaves the room
[14:36:23] <dkg> that's hard to argue with
[14:36:31] <Martin Thomson_web_115> Not K-anonymous?  (we don't have a K, but surely we should select widely from the canon)
[14:36:46] <Eric Rescorla_web_617> I hadn't thought of K-Anonymous and was under time pressure
[14:36:55] <Eric Rescorla_web_617> because I thought of saying KTHX first
[14:36:56] <Martin Thomson_web_115> with Blinded Anonymous Inquiries?
[14:36:56] <mnot> This is why we meet
[14:36:59] <Richard Barnes_web_188> @MarkMcFadden - note that WG name does not always equal name.  see, e.g., DPRIVE
[14:37:04] <Eric Rescorla_web_617> teamwork makes the dream work
[14:37:55] Jeffrey Yasskin_web_508 joins the room
[14:37:58] Greg Wood_web_898 joins the room
[14:38:00] <Eric Rescorla_web_617> Also, Prio et al. don't work for any setting where you need a response
[14:38:13] <Christopher Patton_web_680> + we stand up a proxy for ODoH already..
[14:38:17] Yoshiro Yoneya_web_459 leaves the room
[14:38:21] Yoshiro Yoneya_web_208 joins the room
[14:38:27] <Lucas Pardue_web_203> its pronounced pree-o ??
[14:38:33] <Eric Rescorla_web_617> Yeah
[14:38:42] <Richard Barnes_web_188> @Lucas, yeah that is the accepted one.  I had to adjust my brain as well
[14:38:47] <Mirja Kühlewind_web_598> is the this whole group only for name bikeshedding? Not that I'm saying it won't be fun
[14:38:52] Jonathan Lennox_web_769 leaves the room
[14:38:55] <Watson Ladd_web_374> naturally the RFC editor will pick an auspicious date for publication, the anniversary of the liberation of Brill.
[14:38:57] Justin Richer_web_366 joins the room
[14:39:04] Lixia Zhang_web_612 joins the room
[14:39:05] sftcd still unsure of the tradeoffs vs e.g. Tor - with this approach the proxy operator may be motivated to want to know more about the traffic
[14:39:25] <Martin Thomson_web_115> sftcd: if you want to break links between queries, Tor is very, very expensive.
[14:39:37] <npd> are there other use cases we know of specifically, besides DNS, telemetry and safe browsing?
[14:39:40] <Richard Barnes_web_188> @sftcd Tor is stream-oriented, not this WG
[14:39:43] <Martin Thomson_web_115> connection and circuit setup isn't cheap; ohttp is cheap
[14:39:43] Mary Barnes_web_292 joins the room
[14:39:51] <Lucas Pardue_web_203> it reminds me of Trio - https://www.youtube.com/watch?v=U-V-KCY7SMU
[14:40:00] <sftcd> well very rather than very, very but my worry is the proxy and target server operators may be the same entity
[14:40:07] <Watson Ladd_web_374> would have been perfect for AdScale
[14:40:19] Patrick Tarpey_web_138 joins the room
[14:40:28] <Eric Rescorla_web_617> @sftcd: don't do that then
[14:40:39] <sftcd> I don't get to choose though
[14:40:42] <Eric Rescorla_web_617> Regardless, these questions were adjudicated when we formed the WG, so there is a presumption of consensus on this point
[14:40:51] <Eric Rescorla_web_617> @sftcd: the client does
[14:40:54] <kaduk@jabber.org/barnowl> I think that fetching map tiles was mentioned as a potential use case
(though perhaps not by someone who actually runs that kind of mapping
system)
[14:41:09] <Martin Thomson_web_115> no, you don't, but you can not make that query (clients have to see identity of involved entities)
[14:41:25] <sftcd> @ekr: I'm not saying this wg ought not do stuff I'm expressing a valid concern about the upshot
[14:41:27] Lucas Pardue_web_203 leaves the room
[14:41:31] Lucas Pardue_web_946 joins the room
[14:42:05] Tirumaleswar Reddy.K_web_911 joins the room
[14:42:07] <Watson Ladd_web_374> a lot of the applications are just going directly today, because Tor would get overwhelmed.
[14:42:21] <sftcd> that's true that Tor wouldn't scale yes
[14:42:23] Jon Peterson_web_693 joins the room
[14:43:13] <Martin Thomson_web_115> note that the proxy doesn't see the resource identity
[14:43:22] Chris Inacio joins the room
[14:43:30] Francisco Arias_web_400 joins the room
[14:43:36] <Richard Barnes_web_188> to the degree that Target != Resource
[14:44:02] <sftcd> I'm wondering if enabling some form of transparency might help expose cases where proxy and target are operated by same entity, not sure what "enabling" might involve tbh
[14:44:06] Taiji Kimura_web_395 leaves the room
[14:44:07] <Richard Barnes_web_188> in other words, the deployment model has some impact on the privacy properties
[14:44:09] <Martin Thomson_web_115> Richard: Indeed, that's a choice in deployment; but it means that you can build something that hides URLs.
[14:44:11] <Vittorio Bertola_web_350> if we assume that target and resource are run by the same entity, the proxy will know the entity but not the specific service
[14:44:27] Alessandro Toppi_web_954 leaves the room
[14:44:28] <Richard Barnes_web_188> @Vittorio - that seems like a fair way to think about it
[14:44:31] Alessandro Toppi_web_437 joins the room
[14:44:47] <mnot> It would be good to disambiguate 'proxy' here — i.e., whether this is a HTTP proxy or something else.
[14:44:48] <Lucas Pardue_web_946> circuit breakers!
[14:44:49] <Martin Thomson_web_115> +1 Vittorio
[14:44:51] <dkg> Vittorio Bertola: right, like the network operator can currently see the SNI
[14:45:05] <Andrew Campling_web_180> @sftcd: I think it would be great if it would be possible to specify  that colluding proxies cannot be used
[14:45:06] <Martin Thomson_web_115> mnot: the draft has a more unwieldy term that it uses
[14:45:07] <Vittorio Bertola_web_350> this is of course true only if the entity is big - if it is an entity that only offers one service, then the distinction is moot
[14:45:15] <mnot> @mt: I am well aware :)
[14:45:17] Alexey Melnikov_web_358 joins the room
[14:45:30] Taiji Kimura_web_819 joins the room
[14:45:31] <Eric Rescorla_web_617> @Martin Thomson: why doesn't this use capsules?
[14:45:31] <sftcd> @andrew: dunno about "cannot be used" but "can be detected" might be easier
[14:45:35] <Richard Barnes_web_188> @Andrew - It's not so helpful to say "don't be evil" in a spec :)
[14:45:45] <Eric Rescorla_web_617> I don't see how this could possibly be detectable
[14:45:49] <npd> I'm also curious how the user can have increased confidence in non-collusion (compared to, say, just a DNS server that promises not to keep logs)
[14:45:51] <kaduk@jabber.org/barnowl> I don't think even "can be detected" is particularly achievable
[14:45:56] <Eric Rescorla_web_617> Proving that two entities are different is not really possible
[14:45:56] <Emiliano Spinella_web_437> who would host the Proxy? the ISP, the client, a cloud service? what about latency and bandwidth?
[14:46:02] <mnot> Collusion bit
[14:46:04] <dkg> it's not detectable, given that collusion can be entirely out-of-band
[14:46:11] Glenn Deen_web_733 joins the room
[14:46:16] <Chris Inacio> That's not really a threat model, but a trust model.
[14:46:17] <Jonathan Hoyland_web_487> W.r.t. traffic analysis there's a proof that a protocol of this type cannot be resistant to traffic analysis.
[14:46:21] <sftcd> @ekr: I didn't ask for proof
[14:46:21] <Vittorio Bertola_web_350> indeed the risk of collusion between target and proxy does not seem easy to prevent - not at the technical level, at least
[14:46:53] <Eric Rescorla_web_617> It's not verifiable in any way, afaict
[14:47:01] <Andrew Campling_web_180> If collusion is not detectable in-band then this gives the user the illusion of privacy but without any assurance that it is actually being provided
[14:47:03] <dkg> Chris Inacio: the boundaries of a threat model do typically describe a trust model
[14:47:14] <Jonathan Hoyland_web_487> Without a minimum number of participants and/or more message overheads it's provable that passive linking is possible.
[14:47:20] <Eric Rescorla_web_617> Andrew: that's simply not true. The proxies are *identifiable*
[14:47:36] <npd> I think it means that proxy discovery/selection is very important
[14:47:49] <Vittorio Bertola_web_350> it would be easier for users to trust such a system if users, not targets, chose the proxy. at least, they could decide who to trust.
[14:47:49] <Benjamin Schwartz_web_637> More selection, less discovery.
[14:47:50] Yuji Suga_web_845 joins the room
[14:47:53] <Martin Thomson_web_115> npd: identity is very important, discovery might not be
[14:47:55] <Richard Barnes_web_188> @npd yes, but that's mainly just Operational Considerations in the doc
[14:48:02] <Eric Rescorla_web_617> Yes, the proxy selection is very important. This WG charter assumes that they are preconfigured into the client
[14:48:08] <Chris Inacio> @dkg, yes, but at least tell me, first order, I'm worried about observation from the network that the client is on.
[14:48:16] <Martin Thomson_web_115> discovery creates a host of problems that selection does not
[14:48:40] <dkg> mt: selection also creates a host of distinct problems ☹
[14:48:56] <dkg> UI/UX problems, in particular, that we are terrible at
[14:48:57] <Martin Thomson_web_115> dkg: it's all problems in every direction for as far as you can see
[14:49:06] <npd> dkg: like consolidation, or other problems?
[14:49:10] <Richard Barnes_web_188> 2 is a number, Chris!
[14:49:20] <Richard Barnes_web_188> (zero is also a number, i guess)
[14:49:22] <kaduk@jabber.org/barnowl> We've graduated from "problems all the way down"?  Oh dear...
[14:49:26] <Eric Rescorla_web_617> -2 is also a number
[14:49:28] <Martin Thomson_web_115> 2 is the minimum required for interoperability, so that's something.
[14:49:33] <Vittorio Bertola_web_350> discovery might give more choice to users, thus alleviating concerns for possible proxy-target collusion. if you can only choose among three proxies run by similar entities, then it's not a lot of choice.
[14:49:48] <Richard Barnes_web_188> Reminder that the BoF decided that discovery is out of scope, and that is reflected in the charter
[14:49:54] <Martin Thomson_web_115> Vittorio: I don't think that we should pretend that discovery == choice
[14:50:11] <dkg> √π is a number
[14:50:14] <Jonathan Hoyland_web_487> @Chris observation of the client network is not a problem without view of the target server network. With a view of the target server network too there's no possible defence without very significant overheads.
[14:50:22] <kaduk@jabber.org/barnowl> Note that the target has to trust the proxy to not DoS it, so there is
inherently going to be some limitation of choice to the user
[14:50:31] <sftcd> I'd be ok with not being able to detect that a specific transaction involved collusion, e.g. if one could have evidence that x% of traffic from proxy-A went to target-B etc. - whatever'd be enough for some NGO to call out BS if needed (but again I'd need to think more about if/how it's possible)
[14:50:44] Chris Seal_web_891 joins the room
[14:50:53] <Jonathan Hoyland_web_487> @dkg, is √-1  a number?
[14:50:53] <npd> is that a third implementation?
[14:51:03] <Eric Rescorla_web_617> As DKG, the proxy can just send stuff to the server in a side channel
[14:51:21] <dkg> @Hoyland, i imagine it is
[14:51:29] <Watson Ladd_web_374> @sftcd: I don't think that's evidence either way. If you have a popular target, any proxy is going to send a bunch of traffic
[14:51:31] <Martin Thomson_web_115> Tommy: the static mapping was deliberate (to avoid open relays and other abuse patterns), but we can address that more directly in the draft
[14:51:56] <Jonathan Hoyland_web_487> @dkg, maybe only if you rotate by 90°?
[14:52:00] Karen O'Donoghue_web_958 joins the room
[14:52:16] <Chris Inacio> @jonathan - that was my understanding (without a ton of reading on this) but I would actually hope that we clearly state that somewhere - which was really my point.
[14:52:23] <Martin Thomson_web_115> Tommy, Chris: the body is sort of fixed.  Though we can fix that.
[14:52:27] <sftcd> @watson: so who, that is not a popular target, is intending to operate a proxy? if nobody then I'm back to wondering about the overall benefit
[14:52:37] <Florence D_web_270> The charter says that the WG may work on other use cases and deployment models including those that involve discovery..., not that discovery is out of scope.
[14:52:38] <Richard Barnes_web_188> closing queue for now.  we can have a bit more discussion before the adoption call
[14:52:43] <Jonathan Hoyland_web_487> @Chris, I also think it's something we should put in the security considerations.
[14:53:02] <mnot> Someone has a noisy mic…
[14:53:10] <Richard Barnes_web_188> @Florence - That is after the delivery of the base protocol
[14:53:11] <Jared Mauch_web_369> not hearing any noise
[14:53:19] <Vittorio Bertola_web_350> @sftcd: I would feel better if proxies were not run by commercial entities, but by reputable organizations that have privacy and digital rights as a mission
[14:53:19] <Jonathan Hoyland_web_487> But more as footgun protection.
[14:53:29] <Tommy Pauly_web_912> @MT: I like the static mapping, it just wasn't as spelled out in the doc as it could be
[14:53:34] <sftcd> @vittoria: sure, but who'd pay for that
[14:54:04] <Vittorio Bertola_web_350> that's a funding/organizational model that needs to be developed, unless the answer is "the user".
[14:54:14] <Tommy Pauly_web_912> @MT: Right, the body is fixed as binary HTTP + padding, and that seems to be a bit arbitrary and we don't need to have that restriction. I'm trying to understand what would be needed to peel that apart.
[14:54:21] <Vittorio Bertola_web_350> and we know users don't like paying for stuff
[14:54:45] <Jonathan Hoyland_web_487> If one was run by the NSA and the other by the CCP maybe we can assume non-collusion?
[14:54:47] <Jared Mauch_web_369> we also know that content people will take all they can for free too
[14:54:48] <dkg> reminder: "don't like" may also be "can't afford"
[14:54:52] chenmeiling_web_294 joins the room
[14:54:53] <Lucas Pardue_web_946> WGs working on proxies regularly de-scope discovery. That's fine by me. If it matters then some other (new?) WG should deal with the problem
[14:54:57] <Watson Ladd_web_374> Vittorio: we trust auditors despite the fact they are paid by the entities they audit.
[14:55:00] <Vittorio Bertola_web_350> @dkg: true
[14:55:26] <npd> I understand the drafts aren't going to answer the discovery/selection, but it still seems to important to know that it can be done in a healthy-for-the-Internet way.
[14:55:31] <Vittorio Bertola_web_350> @Watson: that's what could be meant by "a funding/organizational model that needs to be developed"
[14:55:32] <npd> even if it's just an implementation detail
[14:55:36] Jon Peterson_web_693 leaves the room
[14:55:40] Jon Peterson_web_843 joins the room
[14:55:47] <Martin Thomson_web_115> Tommy: I just opened https://github.com/unicorn-wg/oblivious-http/issues/78 for you
[14:56:01] <mnot> That sounds like a research project.
[14:56:03] <Tommy Pauly_web_912> Thanks!
[14:56:06] <dkg> @Vittorio, i agree: capitalism is the problem
[14:56:13] <mnot> (collusion detection, that is)
[14:56:17] <Eric Rescorla_web_617> The proxy can just leak it's private key to the servr
[14:56:20] <Martin Thomson_web_115> sftcd: happy to try to integrate ideas that are at the engineering stage.
[14:56:21] <Benjamin Schwartz_web_637> @sftcd: It's impossible.  Collusion would be "parties keep logs and later join them".
[14:56:31] Chen Li_web_980 leaves the room
[14:56:32] <Jared Mauch_web_369> thankfully there are no bugs where private keys have leaked in the past :-)
[14:56:34] Kirsty Paine_web_874 joins the room
[14:56:35] Chen Li_web_594 joins the room
[14:56:37] <Jari Arkko_web_779> +1 Stephen - and at least sec cons needs to discuss this
[14:56:38] <Andrew Campling_web_180> @Chairs: As detection of collusion is not discovery, not sure that was ruled out of scope previously?
[14:56:42] <Martin Thomson_web_115> Ben: I think that I have to agree.
[14:56:43] <Dominique Lazanski_web_211> +1 to Stephen
[14:56:49] <Dirk Kutscher_web_233> If we keep declaring these questions out-of-scope, we might end up with a situation where users will forced to pick one of several colluding proxies.
[14:56:55] <Andrew Campling_web_180> +1 to Stephen
[14:56:59] <Dominique Lazanski_web_211> Agreed
[14:57:07] <Chris Seal_web_891> +1 to Stephen
[14:57:18] <Jeffrey Yasskin_web_508> The client knows the identities of the proxy and target, right? So an offline audit could detect collusion later.
[14:57:25] <David Schinazi_web_847> What does collusion detection mean? How can anyone tell if I as a server operator write down secrets on a post-it note?
[14:57:27] <Tommy Pauly_web_912> +1 Jeffrey
[14:57:28] <Shivan Sahib_web_549> @EKR, queue is closed - we'll have some time before the adoption call if it can wait?
[14:58:19] <Jari Arkko_web_779> I think ietf rfcs need to document their security properties. You can’t entirely rule this out of scope.
[14:58:29] <Jeffrey Yasskin_web_508> Martin has implemented dark mode.
[14:58:32] <Eric Rescorla_web_617> Nobody is saying it doesn't go in security considerations
[14:58:39] <Lucas Pardue_web_946> https://www.thejohnrobertson.com/thedarkroom/
[14:58:43] Kenneth Murchison_web_122 leaves the room
[14:58:44] <Phillip Hallam-Baker_web_977> Scary video
[14:58:47] Kenneth Murchison_web_207 joins the room
[14:58:51] <Phillip Hallam-Baker_web_977> Monsterpiece theater
[14:58:56] <Robin Wilton_web_969> Could Stephen's requirement be met by a BCP "companion document" separate from the spec itself? (And pointed to in the security considerations...)
[14:58:56] <mnot> It goes in sec cons, but solving the problem can't gate the protocol.
[14:58:57] <Tommy Pauly_web_912> The way to think of this is as a strict improvement over sending all data to one entity, which guarantees collusion. Splitting the data up allows parties to behave in a more privacy-friendly way. It can't prove it, but auditing the ecosystem can help build confidence.
[14:58:57] <Benjamin Schwartz_web_637> @sftcd: However, you can layer more proxies (a la Tor)
[14:59:00] Bron Gondwana_web_456 joins the room
[14:59:09] <dkg> mt has spent his lighting budget on fonts
[14:59:20] Glenn Deen_web_733 leaves the room
[14:59:30] <Jari Arkko_web_779> Ekr: ok then
[14:59:30] <Benjamin Schwartz_web_637> I do think it would be worthwhile to make sure that OHTTP supports recursive encapsulation.
[14:59:35] <Watson Ladd_web_374> PKIX rfc doesn't include CA/B forum or root program requirements. There's plenty of precedent for kicking this compliance things to others
[14:59:38] <Mary Barnes_web_292> mt doesn't want to wake up the family (cat in particular)
[14:59:39] <Andrew Campling_web_180> @Tommy Pauly: the problem is that users may behave differently if they believe they have privacy when they actually have colluding proxies
[14:59:41] <Eric Rescorla_web_617> @benjamin: yes, I agree
[14:59:43] <Robin Wilton_web_969> @Tommy except that you then risk giving people the impression that they are mitigating the risk of collusion, and that might not be true.
[14:59:45] Craig Taylor_web_180 joins the room
[15:00:04] <Robin Wilton_web_969> (What Andrew C said...  ;^,  )
[15:00:04] <Dominique Lazanski_web_211> +1 Robin
[15:00:11] <Richard Barnes_web_188> @Andrew - Constructive solution proposals welcome.  Generically saying we need anti-gravity is not helpful.
[15:00:13] <Watson Ladd_web_374> @Andrew a lot of the applications don't involve user interaction, like telemetry
[15:00:18] <sftcd> @tommy: if we're willing to help people "audit the ecosystem" and do that well, then that'd satisfy my ask
[15:00:19] <Eric Rescorla_web_617> As Tommy said, they *are* mitigating the risk of collusion
[15:00:23] <Andrew Campling_web_180> @Robin Great minds .... :-)
[15:00:30] <Alissa Cooper_web_358> A clear statement that collusion cannot be prevented seems pretty straightforward to include.
[15:00:37] <sftcd> where "people" means someone more or less independent
[15:00:47] <Christopher Wood_web_928> @Andrew I'm not sure I follow the argument. Users also don't know that servers aren't leaking private keys to everyone. Concretely, why is this any different?
[15:00:51] <Lucas Pardue_web_946> martin looks like has just recorded a low-fiedlity loop, and is playing it back while he enjoys a margharita or something
[15:00:53] Glenn Deen_web_552 joins the room
[15:00:54] <Jonathan Hoyland_web_487> Question. What is the problem with collusion? It's not, per se. collecting the data. It's is performing actions based on that data. What action are we specifically worried about colluding proxy/target pairs taking?
[15:01:17] <Jonathan Hoyland_web_487> I think the issue is that the actions we worry about are real world / not Internet ones.
[15:01:58] <Wes Hardaker_web_186> Because conclusion allows for actions to be made, possibly in secret and without the knowledge of the people releasing the data.
[15:02:03] Yangtao Deng_web_730 joins the room
[15:02:10] <Eric Rescorla_web_617> I agree that collusion is bad
[15:02:16] <Eric Rescorla_web_617> I just don't think it's preventable
[15:02:21] <Christopher Wood_web_928> ^ +1
[15:02:33] <npd> will the same HTTP request lead to the same binary output, no matter who implements it (or based on something on the device)?
[15:02:34] <Watson Ladd_web_374> at least not through measures we can do in the ietf
[15:02:35] <dkg> just a reminder that "false sense of security" arguments in our space have frequently been used to drive down *actual* security on offer.
[15:02:37] <Jonathan Hoyland_web_487> Def. not preventable, but I don't think it's even detectable.
[15:02:41] <Andrew Campling_web_180> @Ekr In which case what benefit does this offer?
[15:02:49] <Benjamin Schwartz_web_637> Send half a bitcoin privkey to each party and see if someone steals it :)
[15:03:02] Yangtao Deng_web_730 leaves the room
[15:03:06] Yangtao Deng_web_848 joins the room
[15:03:14] <Shivan Sahib_web_549> queue is open
[15:03:24] <Eric Rescorla_web_617> Andrew: your premise is just wrong. this adds security value if the two entities do not collude and is no worse if they do. That's an improvement.
[15:03:38] <Eric Rescorla_web_617> And people are free to decide they don't like that.
[15:03:57] Yangtao Deng_web_848 leaves the room
[15:04:02] <sftcd> @ekr: I agree with your second last sentence but not your last
[15:04:20] <kaduk@jabber.org/barnowl> I don't think the CT analogy is particularly relevant; CT allows
detection when an entity that's not supposed to have a given type of
credential has such a credential that clients accept as valid.
But the "collusion" case here doesn't involve anyone having something
publicly visible that they're "not supposed to have" -- it involves
them sending secret data in an out of band channel, and that seems
inherently undetectable.
[15:04:23] <sftcd> as in "people are free" doesn't really describe the current ecosystem
[15:04:36] <Eric Rescorla_web_617> In any case, all of these topics were litigated in the adoption call, so this is just relitigating th at
[15:05:11] <Andrew Campling_web_180> @ekr: I'd agree if there was transparency, without that remember that we're increasing the compute cost and so carbon footprint without a confirmed benefit
[15:05:16] <dkg> kaduk: I agree, CT works for publicly-visible artifacts -- you can do this sort of oversight for signed material, but not for encrypted material
[15:05:17] <mnot> Not *exactly* the same people :)
[15:05:22] Joerg Ott_web_147 joins the room
[15:05:44] <Joey Salazar_web_648> +1
[15:05:46] <Jonathan Hoyland_web_487> +1 Watson.
[15:05:56] <npd> has HTTP agreed to take it on?
[15:06:04] <Eric Rescorla_web_617> Andrew: as I said, the adoption call answers this, so that objection is out of order
[15:06:07] Dan McArdle_web_749 leaves the room
[15:06:08] <Jari Arkko_web_779> Btw, charter does NOT rule operational issues, usage constraints, security or discovery
[15:06:10] <mnot> we've been waiting to issue the CfA until this meeting.
[15:06:11] Dan McArdle_web_314 joins the room
[15:06:22] <dkg> Jari: "rule out" ?
[15:06:22] <mnot> … but it's already been discussed and warmly received there.
[15:06:28] <npd> thx
[15:06:31] <Jari Arkko_web_779> … meant to say out if scope
[15:06:49] <Watson Ladd_web_374> what would transparency actually mean? like for CA root programs what ensures CAs behave right is an entire auditing program that the IETF isn't really involved in at all. Why can't that be the model for proxies?
[15:06:49] <Jari Arkko_web_779> Dkg: yes
[15:06:55] <Sean Turner_web_669> if this isn't going cold to http then +1 to what MT and Watson suggested for binary
[15:06:59] <Cullen Jennings_web_680> Uhmm, if I run all my HTTP traffic through a proxy that adds "advertising network enhancement" like a bunch of tracking IDs, that has made it worse than if I just connected directly to the end sites without the "enrichment" the proxy provides but I think that is a pretty far afield from anything we are talking about here. This is based on I have some reason to believe the OHAI proxy is doing whatever it's privacy policy says
[15:07:21] <Jari Arkko_web_779> Sorry I’m on a very small screen and keyboard
[15:07:29] <Martin Thomson_web_115> Cullen: sorry, I didn't follow that.
[15:07:37] <mnot> Cullen - those ids don't get forwarded
[15:08:31] <Cullen Jennings_web_680> (sorry - it was in response to something EKR said that colliding proxy could never make things worse. I think they can make it worse than no proxy in some cases but overall I agree with EKR )
[15:08:35] <dkg> mnot: they could be, no?  what's stopping the proxy from sending the HPKE blob with those additional headers tacked on?
[15:08:38] <Andrew Campling_web_180> Disappointing less that 50% participated  
[15:08:38] <Sean Turner_web_669> 51 raised hands and 10 do not raise hands
[15:08:43] <Robin Wilton_web_969> @Jari You'll have to hum loud, then...
[15:08:56] <Tommy Jensen_web_848> @cullen: How is that different than selection of VPN provider? No protocols vouch for the VPN not forwarding data to endpoints either
[15:08:57] <Bron Gondwana_web_456> I joined too late in the discussion to make an informed choice
[15:08:57] <Martin Thomson_web_115> Pretty happy that we got 50% participation.  That's high.
[15:09:02] <mnot> dkg: you mean if they collude?
[15:09:15] <Vittorio Bertola_web_350> I voted in favour of adoption also because I'm sure that this would be implemented anyway even if it were not an IETF standard, so it's better at least to have a formalized working group and discussion.
[15:09:16] <dkg> mnot: this is one type of collusion, yes
[15:09:19] <francesca> @Andrew that's more than I've seen elsewhere
[15:09:29] <kaduk@jabber.org/barnowl> Andrew: I didn't participate on account of having not actually read
the draft...
[15:09:35] <mnot> that'd effectively be a private protocol between them
[15:09:35] Wendy Seltzer_web_492 joins the room
[15:09:40] <Watson Ladd_web_374> since when does that stop people ben?
[15:09:48] Francois Ortolan_web_683 joins the room
[15:09:49] <Sean Turner_web_669> 51 for is a TON ;)
[15:09:53] <Jeffrey Yasskin_web_508> Tommy: Aren't VPNs exactly the sort of privacy trash fire that people are worried about here?
[15:09:53] <kaduk@jabber.org/barnowl> It doesn't.  But it stops me :)
[15:09:53] Patrick Tarpey_web_138 leaves the room
[15:09:54] Eliot Lear_web_293 joins the room
[15:09:55] <dkg> ben prefers to defer to other people who have not read the draft
[15:09:57] Patrick Tarpey_web_660 joins the room
[15:09:59] <Sean Turner_web_669> but we're not voting
[15:10:02] <mnot> my eyes
[15:10:07] <Andrew Campling_web_180> @francesca - true, still disappointing though
[15:10:09] <Jonathan Hoyland_web_487> The hell is up with the slides?
[15:10:09] Robin Wilton_web_969 leaves the room
[15:10:13] Robin Wilton_web_551 joins the room
[15:10:14] <Yoav Nir_web_380> it's encrypted
[15:10:21] <Watson Ladd_web_374> Telestra
[15:10:24] <Phillip Hallam-Baker_web_977> Corrupted metadata
[15:10:25] <Jonathan Hammell_web_417> That was a really bad font.
[15:10:26] <Jared Mauch_web_369> VGA over IP issues lost the SYNC
[15:10:28] Quynh Dang_web_959 leaves the room
[15:10:29] <francesca> @Andrew indeed
[15:10:35] <Mike Bishop_web_514> Mobius
[15:10:35] <Sean Turner_web_669> @Watson mwhahaha
[15:10:40] <Jonathan Hoyland_web_487> Had too many straight lines to be encryption. Or good encryption at least.
[15:10:41] <francesca> but more disappointing elsewhere :)
[15:10:44] <Tommy Jensen_web_848> @jeffrey: yes and this adds another colluding party that would be required, aka an improvement overwhat we have. I concur with ekr that this is better than the base case (what we have today) even if it isn't perfect)
[15:10:45] <Eric Rescorla_web_617> I don't think it's disappointing: I don't want to discourage people attending when they haven't read the drafts.
[15:10:46] Colin Perkins_web_676 leaves the room
[15:10:54] <Eric Rescorla_web_617> And it's fine for them then not to hum
[15:11:12] Yangtao Deng_web_673 joins the room
[15:11:12] <npd> +1 ekr
[15:11:25] <Jared Mauch_web_369> @jonathan it was rot13+n+1
[15:11:43] <Watson Ladd_web_374> @Jared: NTSC over IP
[15:11:50] <Lucas Pardue_web_946> you could use Capsules
[15:11:54] <Jeffrey Yasskin_web_508> Tommy: +1
[15:11:57] <mnot> be nice
[15:11:58] Craig Taylor_web_180 leaves the room
[15:12:06] Yangtao Deng_web_673 leaves the room
[15:13:17] Eliot Lear_web_293 leaves the room
[15:13:21] Eliot Lear_web_282 joins the room
[15:13:48] <Eric Rescorla_web_617> Re: collusion, the simple fact here is that we are not yet at the state where all computation can be performed in zero knowledge, and so privacy requires some level of trust in the correct action by others. The best tool we have in that setting is often to arrange that you need collusion between two such parties
[15:14:07] <Shivan Sahib_web_549> Emily Stark had a good blog post about the trust model in protocols like this https://emilymstark.com/2021/09/14/splitting-up-trust.html
[15:14:22] <npd> if I were downloading map tiles, I might want to download a dozen, and they all have basically the same privacy implication (this person is curious about this place)
[15:14:45] Scott Rose_web_733 leaves the room
[15:15:19] <Allison Mankin_web_962> Good reference, Shivan
[15:15:45] <Richard Barnes_web_188> Tommy has captured my concern here, we need some differentiation from layered MASQUE tunnels
[15:15:52] <Andrew Campling_web_180> @ekr you could reduce the risk of collusion by adding discovery
[15:15:56] <Christopher Wood_web_928> +1 to Tommy -- just use connection-oriented proxies for more complicated transactions
[15:16:01] <Jonathan Hoyland_web_487> By sending lots of "part 1 of 2" messages can I make the server store more state?
[15:16:13] <mnot> meetecho is broken apparently - hold on
[15:16:16] <Jonathan Hoyland_web_487> Or would standard protections fix that.
[15:16:17] <Christopher Wood_web_928> @Andrew discovery does not necessarily reduce risk of collision, right?
[15:16:21] Alexey Melnikov_web_358 leaves the room
[15:16:25] Mark Nottingham_web_441 leaves the room
[15:16:29] Mark Nottingham_web_623 joins the room
[15:16:44] <Christopher Wood_web_928> collusion*
[15:17:00] <mnot> "Error: audio track closed"
[15:17:00] <Eric Rescorla_web_617> Andrew: that's not at all obvious. Indeed, it might make it worse
[15:17:14] <kaduk@jabber.org/barnowl> Andrew: discovery does not decrease risk of collusion when the target
has a veto over what (even discovered) proxy is allowable.
[15:17:25] <sftcd> @andrew: I agree with ekr that discovery may not help
[15:17:27] <Andrew Campling_web_180> @Chris it may not eliminate it but it should reduce it (unless all proxies are colluding!)
[15:17:32] <Lucas Pardue_web_946> if constraining, how much difference would this end up being to CoAP?
[15:17:42] Eric Rosenberg_web_956 leaves the room
[15:17:46] Eric Rosenberg_web_729 joins the room
[15:17:50] Mark Nottingham_web_623 leaves the room
[15:17:51] <Eric Rescorla_web_617> No, I don't think it's obvious it will reduce it
[15:17:54] Mark Nottingham_web_503 joins the room
[15:18:01] <npd> how much overhead is there, if it takes ten different keys rather than ten requests/responses?
[15:18:03] <Eric Rescorla_web_617> Without a design, it's just speculation
[15:18:05] <Tommy Pauly_web_912> No, discovery won't necessarily help. Discovery can include more "sketchy" proxies that are less well understood.
[15:18:07] Jonathan Lennox_web_720 joins the room
[15:18:16] <Christopher Patton_web_680> +1 Richard
[15:18:28] <mnot> trying firefox, seems to work
[15:19:06] <kaduk@jabber.org/barnowl> Like, I am modeling this as the set of useful proxies is the
intersection between ones the client trusts to not collude and the
ones the server trusts to not DoS.
If that intersection is empty, you either fall back to direct
connection as currently done, or you just don't get service.
[15:20:00] chenmeiling_web_294 leaves the room
[15:20:27] <Eric Rescorla_web_617> Oblivious schmaitch-ttp?
[15:20:44] <Tommy Pauly_web_912> To the naming, I think of this as "oblivious request/response applications over HTTP"
[15:21:20] <David Schinazi_web_847> Oblivious Heterogenous Application Intermediation? We should stick to OHAI
[15:21:20] <Lucas Pardue_web_946> lol @richard barnes
[15:21:48] <Cullen Jennings_web_680> +1 david
[15:22:18] Sorin Faibish_web_255 joins the room
[15:22:28] <mnot> that's actually pretty good david
[15:22:56] Daniam Henriques_web_680 leaves the room
[15:23:24] <Richard Barnes_web_188> Transport of Oblivious Requests
[15:23:41] <Shivan Sahib_web_549> o no
[15:24:29] <Christopher Patton_web_680> What would be an example of a replay attack in this context?
[15:24:38] <Jonathan Hoyland_web_487> The server could return tokens inside the HTTP channel that the client needs to send to the proxy to allow more than one message in flight.
[15:24:59] Francois Ortolan_web_683 leaves the room
[15:25:16] <Jonathan Hoyland_web_487> @ChrisP proxy sending the same message multiple times.
[15:25:23] <kaduk@jabber.org/barnowl> And that would be an indication that it has to go to the same proxy?
[15:25:26] <Christopher Patton_web_680> ack, thx
[15:25:32] <Richard Barnes_web_188> Closing queue, need to wrap up after Chris
[15:26:00] <Eliot Lear_web_282> Is it not possible to add a nonce?
[15:26:27] <Martin Thomson_web_115> submit telemetry: twice
[15:26:29] <dkg> Eliot: who holds the nonce?  how is it checked?
[15:26:29] <Benjamin Schwartz_web_637> @Eliot there is a nonce, but it's expensive to remember them all.
[15:26:45] <Martin Thomson_web_115> A nonce is not really necessary (unique keys achieve that)
[15:26:54] <mnot> It depends on when you schedule them...
[15:27:00] <Christopher Wood_web_928> Mailing list seems fine for now
[15:27:05] <Jonathan Hoyland_web_487> I was referring to anti-DDOS.
[15:27:07] <Andrew Campling_web_180> Mailing list would be more inclusive
[15:27:19] <Eric Rescorla_web_617> Github, pls.
[15:27:20] <Sean Turner_web_669> GitHub works
[15:27:21] <npd> it seems like there are also delay attacks: the proxy can hold the message, prompt the client to contact through another proxy, and then later send along the original message anyway
[15:27:32] Peter Koch_web_155 leaves the room
[15:27:33] <Eric Rescorla_web_617> Let us not schedule any F2F unless necessary
[15:27:44] <Tommy Pauly_web_912> Interims once we have sufficient issue activity is fine, but not before
[15:27:52] <Martin Thomson_web_115> I think that we should spend some time on issues, but let's see how the list discussion develops
[15:27:53] <Christopher Wood_web_928> Thanks, all!
[15:27:57] <David Oliver_web_314> thanks, all
[15:27:58] Dan McArdle_web_314 leaves the room
[15:27:59] Monika Ermert_web_642 leaves the room
[15:28:01] Bron Gondwana_web_456 leaves the room
[15:28:01] sftcd leaves the room
[15:28:01] <Jonathan Hoyland_web_487> Thanks all :)
[15:28:02] Donald Eastlake_web_591 leaves the room
[15:28:02] James Galvin_web_226 leaves the room
[15:28:03] Christopher Inacio_web_248 leaves the room
[15:28:03] Alan Frindell_web_112 leaves the room
[15:28:03] Benjamin Kaduk_web_254 leaves the room
[15:28:03] <francesca> thank you!
[15:28:03] Eric Rosenberg_web_729 leaves the room
[15:28:03] Jeffrey Yasskin_web_508 leaves the room
[15:28:04] Tommy Pauly_web_912 leaves the room
[15:28:05] Andrew Campling_web_180 leaves the room
[15:28:05] Andrew S_web_513 leaves the room
[15:28:05] Chi-Jiun Su_web_321 leaves the room
[15:28:05] Kazuaki Ueda_web_391 leaves the room
[15:28:06] Steve Olshansky_web_768 leaves the room
[15:28:07] Chris Box_web_328 leaves the room
[15:28:07] <Christopher Wood_web_928> To clarify, I meant "GitHub + mailing list", not interims
[15:28:07] Tommy Jensen_web_848 leaves the room
[15:28:07] <David Schinazi_web_847> OBAI everyonw
[15:28:08] Jon Peterson_web_843 leaves the room
[15:28:09] Deb Cooley_web_121 leaves the room
[15:28:10] Yoav Nir_web_380 leaves the room
[15:28:10] Jared Mauch_web_369 leaves the room
[15:28:12] Yoshiro Yoneya_web_208 leaves the room
[15:28:13] Christopher Wood_web_928 leaves the room
[15:28:13] Marco Tiloca_web_455 leaves the room
[15:28:13] Florence D_web_270 leaves the room
[15:28:14] Vittorio Bertola_web_350 leaves the room
[15:28:14] Dirk Kutscher_web_233 leaves the room
[15:28:14] Yuji Suga_web_845 leaves the room
[15:28:15] Phillip Hallam-Baker_web_977 leaves the room
[15:28:16] <kaduk@jabber.org/barnowl> KTHX BAI
[15:28:18] Francisco Arias_web_400 leaves the room
[15:28:20] Harald Alvestrand_web_816 leaves the room
[15:28:22] kaduk@jabber.org/barnowl leaves the room
[15:28:22] Jonathan Hammell_web_417 leaves the room
[15:28:23] Carl Mehner_web_273 leaves the room
[15:28:27] Benjamin Schwartz_web_637 leaves the room
[15:28:27] <Richard Barnes_web_188> FIN KTHX BAI
[15:28:28] Nick Banks_web_812 leaves the room
[15:28:31] Alissa Cooper_web_358 leaves the room
[15:28:31] Eric Rescorla_web_617 leaves the room
[15:28:33] Glenn Deen_web_552 leaves the room
[15:28:33] Paul Wouters_web_938 leaves the room
[15:28:33] Lorenzo Miniero_web_808 leaves the room
[15:28:34] Greg Wood_web_898 leaves the room
[15:28:34] Eliot Lear_web_282 leaves the room
[15:28:36] Richard Barnes_web_188 leaves the room
[15:28:36] Stephen Farrell_web_576 leaves the room
[15:28:37] Shinta Sato_web_898 leaves the room
[15:28:38] Mary Barnes_web_292 leaves the room
[15:28:39] Cullen Jennings_web_680 leaves the room
[15:28:39] Steven Hartley_web_274 leaves the room
[15:28:40] Nicholas Gajcowski_web_513 leaves the room
[15:28:40] Christopher Patton_web_680 leaves the room
[15:28:41] Patrick Tarpey_web_660 leaves the room
[15:28:41] Mallory Knodel_web_632 leaves the room
[15:28:42] Tobias Pulls_web_652 leaves the room
[15:28:43] Kirsty Paine_web_874 leaves the room
[15:28:45] Jonathan Lennox_web_720 leaves the room
[15:28:45] Joseph Salowey_web_857 leaves the room
[15:28:45] Eric Orth_web_305 leaves the room
[15:28:46] Watson Ladd_web_374 leaves the room
[15:28:47] Tadahiko Ito_web_561 leaves the room
[15:28:47] Sean Turner_web_669 leaves the room
[15:28:48] Peter van Dijk_web_179 leaves the room
[15:28:50] Olaf Kolkman_web_775 leaves the room
[15:28:51] Luca Niccolini_web_914 leaves the room
[15:28:53] Wes Hardaker_web_186 leaves the room
[15:28:53] Ned Freed_web_771 leaves the room
[15:28:55] Mike Bishop_web_514 leaves the room
[15:28:56] Lucas Pardue_web_946 leaves the room
[15:28:59] Karen O'Donoghue_web_958 leaves the room
[15:28:59] Xavier de Foy_web_417 leaves the room
[15:29:01] Michael B_web_945 leaves the room
[15:29:04] Jonathan Hoyland_web_487 leaves the room
[15:29:06] Francesca Palombini_web_840 leaves the room
[15:29:08] Ted Hardie_web_704 leaves the room
[15:29:08] Chris Seal_web_891 leaves the room
[15:29:10] Jaime Jimenez_web_832 leaves the room
[15:29:11] David Schinazi_web_847 leaves the room
[15:29:11] Kazunori Fujiwara_web_172 leaves the room
[15:29:18] Nick Doty_web_878 leaves the room
[15:29:20] Justin Richer_web_366 leaves the room
[15:29:21] Yuya Kawakami_web_417 leaves the room
[15:29:22] Nalini Elkins_web_695 leaves the room
[15:29:22] Eric Kinnear_web_983 leaves the room
[15:29:27] Jiri Novotny_web_168 leaves the room
[15:29:31] Shivan Sahib_web_549 leaves the room
[15:29:36] Alessandro Toppi_web_437 leaves the room
[15:29:38] Chris Inacio leaves the room
[15:29:38] tim costello_web_603 leaves the room
[15:29:39] Chen Li_web_594 leaves the room
[15:29:42] Daniel Gillmor_web_742 leaves the room
[15:29:42] Markus de Brün_web_765 leaves the room
[15:29:42] David Oliver_web_314 leaves the room
[15:29:42] Martin Thomson_web_115 leaves the room
[15:29:42] Dominique Lazanski_web_211 leaves the room
[15:29:42] Takahiro Nemoto_web_619 leaves the room
[15:29:42] Mark McFadden_web_358 leaves the room
[15:29:42] John Border_web_659 leaves the room
[15:29:42] Bernie Hoeneisen_web_801 leaves the room
[15:29:42] Jari Arkko_web_779 leaves the room
[15:29:42] Samuel Weiler_web_856 leaves the room
[15:29:42] Spencer Dawkins_web_662 leaves the room
[15:29:42] Mirja Kühlewind_web_598 leaves the room
[15:29:42] David Lawrence_web_263 leaves the room
[15:29:42] Allison Mankin_web_962 leaves the room
[15:29:42] Joey Salazar_web_648 leaves the room
[15:29:42] Hiroyuki Goto_web_416 leaves the room
[15:29:42] Michael Breuer_web_812 leaves the room
[15:29:42] Emiliano Spinella_web_437 leaves the room
[15:29:42] Mo Zanaty_web_701 leaves the room
[15:29:42] Wendy Seltzer_web_492 leaves the room
[15:29:42] Kenneth Murchison_web_207 leaves the room
[15:29:42] Robin Wilton_web_551 leaves the room
[15:29:42] Lixia Zhang_web_612 leaves the room
[15:29:42] Taiji Kimura_web_819 leaves the room
[15:29:42] Mark Nottingham_web_503 leaves the room
[15:29:42] Tirumaleswar Reddy.K_web_911 leaves the room
[15:29:42] Joerg Ott_web_147 leaves the room
[15:29:42] Sorin Faibish_web_255 leaves the room
[15:29:53] Meetecho leaves the room
[15:30:11] Yoshiro Yoneya leaves the room
[15:31:58] Samuel Weiler leaves the room
[15:57:54] francesca leaves the room
[15:59:50] mnot leaves the room
[16:30:58] dkg leaves the room
[18:24:09] alexamirante leaves the room