IETF
ohai
ohai@jabber.ietf.org
Wednesday, March 23, 2022< ^ >
Room Configuration
Room Occupants

GMT+0
[04:31:21] synp leaves the room: Disconnected: Replaced by new connection
[04:31:25] synp joins the room
[13:02:41] Yoshiro Yoneya joins the room
[13:02:42] npd leaves the room
[13:02:46] npd joins the room
[13:08:15] Meetecho joins the room
[13:15:03] Ching-Heng Ku_web_677 joins the room
[13:15:03] Francesca Palombini_web_465 joins the room
[13:15:03] Robin Wilton_web_104 joins the room
[13:15:03] Quynh Dang_web_877 joins the room
[13:15:03] Kazunori Fujiwara_web_302 joins the room
[13:15:03] Cullen Jennings_web_696 joins the room
[13:15:54] Mark McFadden_web_959 joins the room
[13:16:24] Robin Wilton_web_104 leaves the room
[13:16:28] Robin Wilton_web_186 joins the room
[13:17:11] <Francesca Palombini_web_465> oh, hi from the delegate table!
[13:17:18] Yuya Kawakami_web_258 joins the room
[13:18:04] Abhijit Singh_web_533 joins the room
[13:18:16] Robin Wilton_web_186 leaves the room
[13:19:25] Yoshiro Yoneya_web_629 joins the room
[13:19:32] Adnan Rashid_web_327 joins the room
[13:19:36] Thomas Morgan_web_824 joins the room
[13:20:18] Adnan Rashid_web_327 leaves the room
[13:20:35] francesca joins the room
[13:21:22] Tommy Pauly_web_463 joins the room
[13:21:28] Andrew Campling_web_300 joins the room
[13:21:38] Shivan Sahib_web_166 joins the room
[13:21:44] Mark McFadden_web_959 leaves the room
[13:22:43] Abhijit Singh_web_533 leaves the room
[13:22:46] Rebecca Guthrie_web_558 joins the room
[13:22:47] Abhijit Singh_web_730 joins the room
[13:22:53] Mark McFadden_web_825 joins the room
[13:23:07] svaldez@jabber.hot-chilli.net/barnowl joins the room
[13:23:18] <Andrew Campling_web_300> Very good :slightly_smiling_face:
[13:23:24] Jonathan Lennox_web_510 joins the room
[13:24:04] David Oliver_web_588 joins the room
[13:24:13] Robin Wilton_web_256 joins the room
[13:24:26] <Shivan Sahib_web_166> We are still looking for a note-taker!
[13:25:51] Geng-Da Tsai_web_294 joins the room
[13:26:16] Martin Thomson_web_375 joins the room
[13:26:16] Kenneth Murchison_web_857 joins the room
[13:26:21] Brendan Moran_web_787 joins the room
[13:26:49] Daniel Migault_web_264 joins the room
[13:26:52] davidlei_web_252 joins the room
[13:27:27] Hiroyuki Goto_web_243 joins the room
[13:27:34] Philipp Tiesel_web_881 joins the room
[13:28:03] Alexion Ramos_web_688 joins the room
[13:28:04] Jonathan Hammell_web_679 joins the room
[13:28:09] Robin Wilton_web_256 leaves the room
[13:28:13] Robin Wilton_web_283 joins the room
[13:28:17] Colin Whorlow_web_542 joins the room
[13:28:33] Florence D_web_103 joins the room
[13:28:35] Chi-Jiun Su_web_519 joins the room
[13:28:36] Chris Lemmons_web_372 joins the room
[13:28:36] Steve Olshansky_web_486 joins the room
[13:28:39] Abhijit Singh_web_730 leaves the room
[13:28:42] SeongHan Shin_web_206 joins the room
[13:28:43] Abhijit Singh_web_440 joins the room
[13:28:43] Eric Orth_web_920 joins the room
[13:28:45] davidlei_web_252 leaves the room
[13:28:49] Nick Doty_web_812 joins the room
[13:28:51] Renan Krishna_web_229 joins the room
[13:29:04] Abhijit Singh_web_440 leaves the room
[13:29:04] Robin Wilton_web_283 leaves the room
[13:29:08] Abhijit Singh_web_427 joins the room
[13:29:11] Robin Wilton_web_292 joins the room
[13:29:22] Sean Turner_web_684 joins the room
[13:29:22] Christian Veenman_web_476 joins the room
[13:29:28] Dan McArdle_web_655 joins the room
[13:29:31] Chris Wendt_web_266 joins the room
[13:29:35] dkg joins the room
[13:29:35] Robin Wilton_web_292 leaves the room
[13:29:36] Christopher Patton_web_254 joins the room
[13:29:39] Robin Wilton_web_885 joins the room
[13:29:44] Ted Hardie_web_157 joins the room
[13:29:47] Daniel Gillmor_web_264 joins the room
[13:29:58] Tommy Jensen_web_637 joins the room
[13:30:05] Patrick Kelsey_web_727 joins the room
[13:30:07] James Galvin_web_103 joins the room
[13:30:12] Jen Hufford_web_566 joins the room
[13:30:14] Eric Rescorla_web_502 joins the room
[13:30:16] Nick Banks_web_901 joins the room
[13:30:18] Juliana Guerra_web_561 joins the room
[13:30:23] Ken Takayama_web_293 joins the room
[13:30:24] Robin Wilton_web_885 leaves the room
[13:30:48] Robin Wilton_web_367 joins the room
[13:30:54] Mike Bishop_web_802 joins the room
[13:30:55] Frode Sorensen_web_100 joins the room
[13:30:55] Richard Barnes_web_149 joins the room
[13:30:56] Christopher Wood_web_562 joins the room
[13:31:04] frodek joins the room
[13:31:12] <Shivan Sahib_web_166> https://notes.ietf.org/notes-ietf-113-ohai
[13:31:23] Jonathan Reed_web_990 joins the room
[13:31:29] Christian Veenman_web_476 leaves the room
[13:31:33] Luca Niccolini_web_147 joins the room
[13:31:33] Christian Veenman_web_476 joins the room
[13:31:34] <Florence D_web_103> I can take notes
[13:31:38] Dan Druta_web_960 joins the room
[13:31:44] Alyssa Thompson_web_518 joins the room
[13:31:52] Francisco Arias_web_446 joins the room
[13:31:55] Alissa Cooper_web_784 joins the room
[13:31:55] Chen Li_web_922 joins the room
[13:31:58] jhoyla joins the room
[13:32:00] Xavier de Foy_web_774 joins the room
[13:32:09] Monika Ermert_web_228 joins the room
[13:32:11] Michael B_web_588 joins the room
[13:32:20] Michael Hollyman_web_873 joins the room
[13:32:21] William Carroll_web_198 joins the room
[13:32:27] Eric Kinnear_web_634 joins the room
[13:32:29] <jhoyla> Happy to help jabber scribe if people need me to relay at the mic.
[13:32:39] <Richard Barnes_web_149> thanks @jhoyla
[13:32:41] Erik Nygren_web_496 joins the room
[13:32:44] Chris Wendt_web_266 leaves the room
[13:32:48] Chris Wendt_web_505 joins the room
[13:32:49] Kazuaki Ueda_web_259 joins the room
[13:32:50] Benjamin Schwartz_web_365 joins the room
[13:33:10] Tirumaleswar Reddy.K_web_685 joins the room
[13:33:35] Samuel Weiler_web_106 joins the room
[13:33:53] <Richard Barnes_web_149> impressive as always @mt
[13:34:11] <Shivan Sahib_web_166> I didn't notice the animation before, wow
[13:34:19] Kyle Ouellette_web_567 joins the room
[13:34:24] <jhoyla> Fabulous slides, impressed that MeetEcho was able to handle that so smoothly.
[13:34:59] Stephen Farrell_web_452 joins the room
[13:35:10] Thomas Morgan_web_824 leaves the room
[13:35:10] <dkg> they're cool, but i dunno that they're worth 400Kbps though
[13:35:17] Ted Hardie_web_157 leaves the room
[13:35:21] Ted Hardie_web_365 joins the room
[13:35:27] sftcd-x-x-z joins the room
[13:35:29] <dkg> static slides are important for low-bandwidth participants
[13:35:35] Allison Mankin_web_317 joins the room
[13:36:00] Christian Veenman_web_476 leaves the room
[13:36:00] <Mike Bishop_web_802> I'm seeing ~~514kbps; is it possible that they scale based on bandwidth?
[13:36:04] Christian Veenman_web_392 joins the room
[13:36:12] David Schinazi_web_313 joins the room
[13:36:13] ekr@jabber.org joins the room
[13:36:13] <dkg> i'm seeing 508kbps now
[13:36:15] Timothy Carlin_web_709 joins the room
[13:36:22] <jhoyla> Fair point dkg.
[13:36:23] <francesca> statis slides also here: https://datatracker.ietf.org/meeting/113/session/ohai
[13:36:25] Rich Salz_web_282 joins the room
[13:36:45] <dkg> hard to follow what slide we're on if we're using martin's screenshare though
[13:36:47] <Meetecho> We just put a cap, the browser then decides how much bitrate to use for the encoded stream
[13:36:54] Timothy Carlin_web_709 leaves the room
[13:37:09] Tadahiko Ito_web_883 joins the room
[13:37:52] Timothy Carlin_web_944 joins the room
[13:37:56] Benjamin Kaduk_web_126 joins the room
[13:37:57] Rajeev RK_web_246 joins the room
[13:38:13] Michael B_web_588 leaves the room
[13:38:17] Michael B_web_579 joins the room
[13:38:18] Christian Veenman_web_392 leaves the room
[13:38:22] Christian Veenman_web_228 joins the room
[13:38:26] <npd> will a user be able to know what is being added about them, if the whole point is to be oblivious?
[13:38:26] Mallory Knodel_web_637 joins the room
[13:38:32] Gyan Mishra_web_920 joins the room
[13:39:03] <svaldez@jabber.hot-chilli.net/barnowl> For the shadowbanning case you wouldn't want the user to necessarily
detect the signal.
[13:39:14] <jhoyla> To pair this with the streaming / non-atomic issue (up next) couldn't 1-bit be used to encode the IP over multiple rounds?
[13:39:46] Stefan Berres_web_652 joins the room
[13:39:55] Gyan Mishra_web_920 leaves the room
[13:40:08] <ekr@jabber.org> Well, nothing stops the proxy and client from having a side channel
[13:40:10] <npd> right, but aren't we recommending what a proxy should guarantee (even if the user can't confirm it technically in band) in order to be an oblivious proxy?
[13:40:13] Haiguang Wang_web_404 joins the room
[13:40:14] Jim Reid_web_522 joins the room
[13:40:21] <ekr@jabber.org> s/client/server/
[13:40:35] <Mike Bishop_web_802> Given that there's no way to control (from the protocol perspective) what the proxy sends, I think this is more of an OUGHT TO.
[13:40:36] Zewei Chen_web_997 joins the room
[13:40:42] <Richard Barnes_web_149> RFC 6919 is my greatest contribution to the RFC series
[13:40:52] <ekr@jabber.org> All of ours
[13:41:01] <Richard Barnes_web_149> https://datatracker.ietf.org/doc/html/rfc6919#section-1
[13:41:05] <npd> should we at least define what the proxy shouldn't do?
[13:41:19] <Ted Hardie_web_365> Doesn't this really rely on the resource and the proxy having a side channel so it can tell the proxy what users belong in the shadow banned group?  Or am I missing a case where the proxy does the shadow ban based on behavior of the user towards the proxy?
[13:41:32] <npd> or is it just implicit that of course (though we won't write it down) a proxy should minimize or not include a Forwarded IP address?
[13:41:38] <Rich Salz_web_282> @rlb: one of the few 4/1 RFC's that was worth it.
[13:41:41] Magnus Westerlund_web_331 joins the room
[13:41:49] <Andrew Campling_web_300> Uncomfortable about introducing a side channel for communications from the proxy unless it is fully transparent to the client
[13:42:03] <ekr@jabber.org> We're not introducing a side channel. It's HTTP. There are headers
[13:42:17] Michael Hollyman_web_873 leaves the room
[13:42:18] <Richard Barnes_web_149> @ekr your point is that the side channel already exists?
[13:42:20] <dkg> the side channel exists whether we introduce it or not
[13:42:21] Michael Hollyman_web_197 joins the room
[13:42:23] <ekr@jabber.org> Exactly
[13:42:31] <dkg> this is a not-side channel
[13:42:32] <jhoyla> @rich salz RFC 1925 is also v. useful.
[13:42:52] <ekr@jabber.org> Like we're just talking about what text we have restricting what goes in those headers
[13:43:23] <Rich Salz_web_282> best part of 1925 is that it has errata reported :)
[13:43:47] <Ted Hardie_web_365> So, the HTTP response headers say "future comms should use group X, as this user is associated with X's charateristics?" If that, then shadow ban seems like a pretty small use case compared to other ones (like age range indicator being reflected back).
[13:44:00] Chris Wendt_web_505 leaves the room
[13:44:04] Chris Wendt_web_468 joins the room
[13:44:06] kaduk@jabber.org/barnowl joins the room
[13:44:21] <Andrew Campling_web_300> It feels like we’re edging towards normalising colluding proxies and targets
[13:44:23] Colin Whorlow_web_542 leaves the room
[13:44:23] <svaldez@jabber.hot-chilli.net/barnowl> The wording being that X can have a 1-bit value?
[13:44:24] <Ted Hardie_web_365> Which makes me wonder how oblivious things turn out to be...
[13:44:27] Colin Whorlow_web_256 joins the room
[13:44:28] Peter Koch_web_803 joins the room
[13:44:29] <jhoyla> Shadow banning seems like it would fall under @sftcd's ostensibly optional clause.
[13:44:49] <npd> wait, are we saying that a proxy can do anything, including the user's full ip address, and users should just negotiate it in an out of band contract?
[13:44:51] <dkg> this is a fundamental architectural problem with the ohai scheme though, right?
[13:45:28] <svaldez@jabber.hot-chilli.net/barnowl> It seems like a policy decision between the user and proxy rather than
an in-protocol enforcement?
[13:45:37] <Ted Hardie_web_365> @dkg agreed, and I think that means we don't want the standards signal to be null, and to treat anything as collusion.
[13:45:48] <Martin Thomson_web_375> It sounds like we are avoiding SHOULD also, which might need some finesse
[13:45:48] <jhoyla> MUST (BUT WE KNOW YOU WON'T)
[13:45:50] <Ted Hardie_web_365> Sorry, we want the standard signal to be null (no bits)
[13:45:51] <Christopher Wood_web_562> I think there's a misunderstanding about the MUST here.
[13:45:57] Luigi Iannone_web_100 joins the room
[13:46:07] Michael B_web_579 leaves the room
[13:46:11] Michael B_web_924 joins the room
[13:46:15] <Christopher Wood_web_562> (It's a restriction on the proxy about adding things the client explicitly does not know about)
[13:46:52] <dkg> Ted: it's interesting that both conclusions *could* be drawn :/
[13:47:03] <ekr@jabber.org> Indeed, the geo client hint
[13:47:09] <sftcd-x-x-z> could a client and target co-operate to discover what a proxy is currently adding? (i.e. enable that as a protocol feature for special "test" targets)
[13:47:10] Alan Frindell_web_506 joins the room
[13:47:12] <dkg> age limit
[13:47:14] <dkg> citizenship
[13:47:21] <Mike Bishop_web_802> The alternative is for the client to communicate with the server directly, and the proxy is effectively the server *choosing* to distance itself from certain information.
[13:47:23] <Mike Bishop_web_802> That is, this is a mechanism for the server to implement its own privacy policy.  The client's trust is in the privacy policy, not the proxy necessarily.
[13:47:26] <Tommy Pauly_web_463> Yes, targets could report what proxies add
[13:47:51] <Ted Hardie_web_365> So all of those seem like a "here are the permitted forms of collusion"and user consent for them on disclosure.  Doesn't that run into  the usual concerns about the viability of user consent?
[13:47:53] <dkg> but a colluding target would just omit that
[13:47:58] <sftcd-x-x-z> adding an example or something showing that might be some good text somewhere (dunno if in an RFC but wherever)
[13:48:10] Simon Hicks_web_584 joins the room
[13:48:18] Alissa Cooper_web_784 leaves the room
[13:48:22] Alissa Cooper_web_225 joins the room
[13:48:43] <Christopher Wood_web_562> @Ted I think it runs more closely towards the trust model
[13:48:51] <Andrew Campling_web_300> Having targets being transparent about additions from proxies seems like a good idea.  But normalising collusion between proxies and targets seems to be a bad idea, even if we can identify (some) good reasons for doing it.
[13:49:16] <Christopher Wood_web_562> @Andrew who suggested collusion between proxies and targets?
[13:49:22] Liwei Ma_web_332 joins the room
[13:49:24] <ekr@jabber.org> This isn't collusion.
[13:49:37] <Andrew Campling_web_300> @ekr I disagree
[13:49:44] Rikard Höglund_web_544 joins the room
[13:50:34] Liwei Ma_web_332 leaves the room
[13:50:38] Liwei Ma_web_316 joins the room
[13:50:40] <Andrew Campling_web_300> @chris: signalling from the proxy to target is a form of collusion
[13:50:42] <sftcd-x-x-z> wouldn't it be nice to be able to add a bit of cgi to some random web server that'd tell clients what a proxy has added? (proxies could learn about widely used test servers of course but still could be useful)
[13:50:47] <ekr@jabber.org> The entire principle of this system is that the proxy makes public guarantees about what it doe sor does not do
[13:50:59] <jhoyla> With the shadowban, does the target have any guarantees about the honesty of the proxy?
[13:51:03] <ekr@jabber.org> And one of those things might be sending some general data
[13:51:34] Liwei Ma_web_316 leaves the room
[13:51:37] <ekr@jabber.org> I'm not that interested in a semantic argument about whether that's "collusion" or not.
[13:51:48] <ekr@jabber.org> @jhoyla: no
[13:51:51] Chris Box_web_367 joins the room
[13:52:19] <Mike Bishop_web_802> Everyone seems to be assuming that the proxy is selected by the client, but isn't our scenario here that the proxy is chosen and indicated by the server?  The client's choice is proxy or direct, unless I've misunderstood.
[13:52:22] <Benjamin Schwartz_web_365> Richard: That would allow the proxy to execute a truncation attack.
[13:52:28] <ekr@jabber.org> @Mike: correct.
[13:52:34] <Andrew Campling_web_300> Isn’t the whole point of Oblivious that there should be separation between the proxy and target?  Anything that builds links seem like a bad idea
[13:52:37] <ekr@jabber.org> Well, or "nothing"
[13:52:53] Jessica Fitzgerald-McKay_web_678 joins the room
[13:52:56] <kaduk@jabber.org/barnowl> The server might publish a list of proxies that it accepts traffic
from, with the client picking between one of those and going direct.
But the server still picks.
[13:53:22] <ekr@jabber.org> As noted above, that link already exists. It's called HTTP headers
[13:53:29] <Mike Bishop_web_802> And if the proxy "belongs" to the server (even if operated by a third-party), they're effectively a single party for the client's trust purposes.
[13:53:40] <ekr@jabber.org> @Mike, no I don't think that that's true at all
[13:53:40] Andrew S_web_386 joins the room
[13:53:49] <jhoyla> @kaduk and a server might decide to only allow signalling proxies.
[13:53:51] <Richard Barnes_web_149> i have no opinion on whether streaming is needed or not
[13:53:57] Peter Koch_web_803 leaves the room
[13:54:01] Peter Koch_web_954 joins the room
[13:54:04] <ekr@jabber.org> I think Apple Private Relay provides a good example here.
[13:54:04] <kaduk@jabber.org/barnowl> @jhoyla: right
[13:54:32] <ekr@jabber.org> Apply pays the proxies, but I think "data goes through both Apple and CF" is pretty different from "data just goes through Apple"
[13:54:50] Jonathan Lennox_web_510 leaves the room
[13:54:54] Jonathan Lennox_web_589 joins the room
[13:55:19] <Mike Bishop_web_802> @ekr, disagree -- Private Relay has no opt-in or affiliation from the end server.  The proxy(ies) are a separate party from the server handling the request.
[13:55:29] Nick Sullivan_web_646 joins the room
[13:55:49] Harald Alvestrand_web_762 joins the room
[13:55:57] <ekr@jabber.org> @Mike: In the private relay case, the threat model is Apple looking at your browsing
[13:56:12] <Mike Bishop_web_802> And as to collusion between the proxies, it *is* a good comparison -- nothing stops one proxy from passing information to the second proxy.
[13:56:34] <Mike Bishop_web_802> You're trusting Apple's contract with the assorted third-parties that they're not doing that.
[13:56:36] <ekr@jabber.org> You're right that nothing stops them. The principle is that they are operated by different people who have reputational reasons not to collude
[13:56:52] <Eric Orth_web_920> My thought on streaming: If you stream a lot together, you essentially are in the traditional proxy case.  The only reason to support streaming is if we have a lot of usecases for small, limited-length streams.
[13:57:03] <ekr@jabber.org> No, I'm trusting Cloudflare (and Akamai's) representation that they are not colluding with Apple
[13:57:12] <Robin Wilton_web_367> FWIW, I think we need to base this on a term other than "shadowbanning" - because that implies value judgements I don't think the proxy should be party to.
[13:57:17] Lorenzo Colitti_web_955 joins the room
[13:57:23] <Tommy Pauly_web_463> Yeah I'd prefer a different media type
[13:57:32] <npd> don't we need to define what "not colluding" means? don't send the user's IP address, but it's okay if you send a single bit (without reflecting it to the end user) about shadowban-suspicion
[13:57:36] <Andrew Campling_web_300> Reputational reasons seems like a pretty thin defence for privacy
[13:57:46] Stefan Santesson_web_992 joins the room
[13:58:00] <ekr@jabber.org> The current status is no privacy at all, so this is what's known as "incremental progress"
[13:58:11] <Richard Barnes_web_149> @Tommy you mean different media types streaming vs. not?
[13:58:11] <Robin Wilton_web_367> @npd Why is it the proxy's responsibility to enforce a shadowban?
[13:58:23] Florence D_web_103 leaves the room
[13:58:24] Haiguang Wang_web_404 leaves the room
[13:58:47] <Tommy Pauly_web_463> @richard yes, exactly. Let that be an extension, and clearly have the client and server know what mode they're in
[13:58:52] <npd> @robin that's been a suggestion from some participants, because the proxy is the only one who can reasonably detect malicious/repeated activity
[13:59:05] <Mike Bishop_web_802> @ekr, I think we're saying the same thing but using different terms.  The client has to trust that the other parties aren't passing around information they've publicly promised not to.
[13:59:06] <dkg> +1 for Robin's suggestion that "shadowban" has problematic semantics; if we do this, it should be named something else.
[13:59:12] <dkg> (if we do it)
[13:59:19] <ekr@jabber.org> @Mike: yes, I 100% agree with that
[13:59:42] <Tommy Pauly_web_463> Agreed with ekr and Mike on that discussion
[13:59:53] Florence D_web_724 joins the room
[14:00:17] <Rich Salz_web_282> No collusion, Tommy/Mike.
[14:00:17] Chris Wendt_web_468 leaves the room
[14:00:22] Jen Hufford_web_566 leaves the room
[14:00:24] <Andrew Campling_web_300> Shadow ban does have negative connotations, at least to some groups in the US and possibly elsewhere
[14:00:34] <jhoyla> How wide does this window need to be to not have to worry about clock skew?
[14:00:47] David Navarro joins the room
[14:00:48] <Daniel Migault_web_264> why now not in the middle of accept ?
[14:00:48] <dkg> not just that it's pejorative -- that it has implications about things (like content) that the proxy cannot know)
[14:00:50] <jhoyla> lol, I guess MT preempted me.
[14:00:54] <svaldez@jabber.hot-chilli.net/barnowl> "Years".
[14:00:59] <Richard Barnes_web_149> i would note that ACME has anti-replay nonces at the application layer
[14:01:17] <David Schinazi_web_313> MT just doesn't realize time travel is real
[14:01:25] <Tommy Pauly_web_463> @Rich =P
[14:01:25] <svaldez@jabber.hot-chilli.net/barnowl> Unintended consequences of mobile daily games.
[14:01:33] <Jonathan Lennox_web_589> Doesn't TLS (or technically PKIX) break down with clocks that bad?
[14:01:35] <Richard Barnes_web_149> @Schinazi -- or doesn't want to reveal what he knows
[14:01:35] <Alan Frindell_web_506> at least time traveling HTTP requests
[14:01:42] <jhoyla> @David Schinazi shhhh!
[14:01:44] <David Schinazi_web_313> @Richard how long does ACME remember nonces?
[14:01:46] <jhoyla> It's a secret
[14:01:47] <npd> I must say, when I first saw `isMalicious` as the field name, it did seem like the evil bit was already defined in an RFC somewhere
[14:01:53] <kaduk@jabber.org/barnowl> I may have pointed to the ACME anti-replay nonce pattern as a good
example, on a few occasions.
[14:01:59] <Richard Barnes_web_149> @David up to the server
[14:02:06] Lorenzo Colitti_web_955 leaves the room
[14:02:13] Lorenzo Colitti_web_584 joins the room
[14:02:13] npd leaves the room
[14:02:17] <Christopher Wood_web_562> @rlb the HPKE context is effectively a nonce here
[14:02:17] npd joins the room
[14:02:19] <kaduk@jabber.org/barnowl> Things recover gracefully if the ACME server forgets some nonces
[14:02:30] <Christopher Wood_web_562> So we add the timestamp to shorten the window over which the server needs to remember them
[14:02:53] Erik Nygren_web_496 leaves the room
[14:02:53] Lorenzo Colitti_web_584 leaves the room
[14:02:54] <Robin Wilton_web_367> @npd I would want to distinguish between the target being able to *detect* malicious activity and being able to *attribute* malicious activity.
[14:02:55] <Rich Salz_web_282> @Jonathan TLS breaks with mis-synced clocks only if you're validating timestamps in certs and many don't bother.
[14:02:57] Erik Nygren_web_167 joins the room
[14:02:57] Lorenzo Colitti_web_621 joins the room
[14:03:24] <David Schinazi_web_313> We can always put on our HTTP hats and walk over to the other room
[14:03:37] <Daniel Migault_web_264> do we have data on client clocks ?
[14:03:39] <jhoyla> @Rich Salz do we need to care about non-compliant clients?
[14:03:57] <jhoyla> @Daniel Migualt there are a few papers I've seen
[14:03:59] <Rich Salz_web_282> Depends on if "we" is the IETF or if its implementors.
[14:04:06] Juliusz Chroboczek_web_689 joins the room
[14:04:15] <David Schinazi_web_313> @Daniel yeah IIRC Chrome did measurements and the results were terrifying
[14:04:20] <Richard Barnes_web_149> @Migault - the browser vendors have looked at this quite a lot
[14:04:23] <kaduk@jabber.org/barnowl> Thinking a bit about the scope of breakage in the face of
non-compliant clocks might inform how we discuss security
considerations, at least.  It might even inform design choices.
[14:04:33] <Robin Wilton_web_367> @npd It seems to me only to be an issue where the proxy is being used as a vector for DoS attacks on the target - and even then, the answer IMO is for the target to be able to alert the proxy, not vice versa.
[14:04:36] <Rich Salz_web_282> So did Mozilla, which is why OCSP stapling is seven days.
[14:04:36] <Richard Barnes_web_149> this is why Chrome has "fix your clock" guidance if you encounter an expired cert
[14:05:13] <Shivan Sahib_web_166> @David Schinazi was the clock skew in the order of seconds per day?
[14:05:18] Abhijit Singh_web_427 leaves the room
[14:05:20] <Daniel Migault_web_264> @rich@david @Richard thanks. If we have any links , I would be interested.
[14:05:22] Abhijit Singh_web_143 joins the room
[14:05:39] Allison Mankin_web_317 leaves the room
[14:05:58] <David Schinazi_web_313> I think there were non-trivial amounts with much much more broken clocks, as in years - and it caused TLS issues. I would have to ask DavidBen
[14:06:27] Abhijit Singh_web_143 leaves the room
[14:06:31] Abhijit Singh_web_139 joins the room
[14:06:43] <ekr@jabber.org> Of course, if you're 11s behind, you probably won't be 11s for too long :)
[14:06:53] <Jonathan Lennox_web_589> MT cites https://doi.org/10.1145/3133956.3134007 in his date-requests draft
[14:06:58] <dkg> why fuzzed instead of quantized?
[14:07:01] <Daniel Migault_web_264> on the current slide is there any reason "now" is not in the middle ?
[14:07:11] <jhoyla> Oh yeah, quantised would still leak on the changes.
[14:07:26] <jhoyla> Even fuzzed would leak eventually though.
[14:07:33] <ekr@jabber.org> @Daniel: message transmission latency :)
[14:07:34] <jhoyla> Esp. in the stream setting
[14:07:41] <dkg> i think you want quantized *and* fuzzed (in that order)
[14:07:44] <Daniel Migault_web_264> @ekr thanks!
[14:07:50] <npd> @robin I think in telemetry use cases, the proxy might notice some malicious repeated activity that could screw up the target's data, and the target wouldn't be able to notice that, only the proxy could identify the repetitive activity
[14:07:50] <ekr@jabber.org> Sorry, that was a joke.
[14:07:54] Glenn Deen_web_322 joins the room
[14:07:57] <Benjamin Schwartz_web_365> dkg: OHTTP provides unlinkability so I think you just need the fuzz
[14:07:59] <ekr@jabber.org> I mean, maybe that is what MT meant, but I was joking
[14:08:14] Juliusz Chroboczek_web_689 leaves the room
[14:08:24] <jhoyla> @Ben Schwartz is that true in the streaming case?
[14:08:36] Abhijit Singh_web_139 leaves the room
[14:08:40] Abhijit Singh_web_154 joins the room
[14:08:44] <dkg> schwartz: you're assuming that the http request itself won't provide linkability, right?
[14:08:46] <Benjamin Schwartz_web_365> jhoyla: I think so.  Each stream would only have a single date header at the beginning.
[14:09:07] <David Schinazi_web_313> +1 to what Eric said
[14:09:07] <dkg> for example, i could be given a custom URL that i don't realize is unique to me.
[14:09:12] <Benjamin Schwartz_web_365> dkg: Yes.  If your requests are linkable, you should use HTTP CONNECT (or MASQUE)
[14:09:20] <npd> @daniel now is in the middle because some messages sent with a date a little bit in the future are probably acceptable (because the client's clock is skewed forward a little bit)
[14:09:30] Nick Sullivan_web_646 leaves the room
[14:09:47] Abhijit Singh_web_154 leaves the room
[14:09:51] Abhijit Singh_web_453 joins the room
[14:10:13] <David Schinazi_web_313> I agree that should not be experimental
[14:10:21] <Eric Orth_web_920> +1 to agreement
[14:10:21] <Tommy Pauly_web_463> Agreed, not experimental
[14:10:29] Stefan Berres_web_652 leaves the room
[14:10:32] <svaldez@jabber.hot-chilli.net/barnowl> +1 to unexperimental.
[14:10:58] <ekr@jabber.org> not experimental
[14:11:06] <jhoyla> @schwartz Oh, of course, because you don't need replay protection on the second packet because of the sequence number.
[14:11:06] <Andrew Campling_web_300> On discovery, it depends on the use case(s) whether discovery is important.  If in doubt include it would seem like a reasonable position.
[14:11:13] Chris Box_web_367 leaves the room
[14:11:17] Chris Box_web_698 joins the room
[14:11:23] Philipp Tiesel_web_881 leaves the room
[14:11:37] <Daniel Migault_web_264> @npd thanks. what you are saying is that clocks are unlikely to skew forward as opposed as backward.
[14:11:47] <Christopher Wood_web_562> No
[14:11:49] <ekr@jabber.org> Nope.
[14:11:54] <David Schinazi_web_313> +1 to addressing discovery in another draft
[14:12:02] <Tommy Pauly_web_463> It would be a mistake to try to discovery in this document
[14:12:16] <dkg> please don't discuss discovery in this document
[14:12:17] <David Schinazi_web_313> I don't necessarily agree that those people are sensible, I happen to know them well
[14:12:20] <Andrew Campling_web_300> But it does need to be addressed by this group
[14:12:23] <Mike Bishop_web_802> Discovery changes the scenario we're going after.
[14:12:34] <Eric Orth_web_920> Absolutely something this WG should work on.  Not part of this draft.
[14:12:41] <Shivan Sahib_web_166> (removing chair hat) this is pretty clearly a protocol doc
[14:13:03] <Robin Wilton_web_367> @npd Fair point about some metrics only being visible to the proxy - but to my mind, if the target is going to delegate *any* function other than obliviation to the proxy, that's a matter for transparent terms of service, not for the protocol.
[14:13:14] <ekr@jabber.org> Very offended that my last minute issues and PRs weren't on MT's slides
[14:13:25] <Martin Thomson_web_375> I do agree that we need to get a better handle on what discovery might mean for ohttp
[14:13:42] <Robin Wilton_web_367> @ekr late binding is a b*tch...
[14:13:46] <Martin Thomson_web_375> it's clear from Tommy and Tiru's work that there are a lot of moving parts
[14:13:46] <ekr@jabber.org> @MT: you had like an hour to add them
[14:13:49] <Sean Turner_web_684> @MT as usual great slides
[14:14:08] <Martin Thomson_web_375> ekr: I was busy trying to write up the streaming design
[14:14:25] Colin Whorlow_web_256 leaves the room
[14:14:29] <ekr@jabber.org> NO EXCUSES
[14:14:29] Colin Whorlow_web_841 joins the room
[14:14:32] <Martin Thomson_web_375> hah
[14:14:56] <Richard Barnes_web_149> we're going to end up reinvent BGP black holes here
[14:14:56] <npd> on discovery, it seems useful for a target to be able to provide a pointer (Alt-Svc or a link relation or something) to an oblivious proxy to it
[14:17:01] Michael B_web_924 leaves the room
[14:17:07] <Benjamin Schwartz_web_365> I don't get it.  Why can't we just use the RateLimit-* headers?
[14:17:09] <jhoyla> Given that the proxy can't decapsulate (enucleate) the response do you need to specify that the proxy strips it?
[14:17:16] Christian Veenman_web_228 leaves the room
[14:17:20] Christian Veenman_web_380 joins the room
[14:17:26] <Tommy Pauly_web_463> @ben +1, it seems like we could just use the existing rate-limit header
[14:17:34] Rikard Höglund_web_544 leaves the room
[14:18:11] <jhoyla> Because the proxy is aggregating clients, and needs to allocate them to the clients?
[14:18:25] <jhoyla> them=request capacity
[14:18:42] <jhoyla> (i.e. the semantics are different)
[14:18:45] <Richard Barnes_web_149> @jhoyla but you want to avoid identifying clients, so i think the idea here is to make it the proxy's job to figure out which clients to limit
[14:19:19] <jhoyla> Right, I'm just saying that the semantics are different to the rate-limit semantics
[14:19:31] Andrew S_web_386 leaves the room
[14:20:19] David Navarro_web_893 joins the room
[14:21:11] <Mike Bishop_web_802> Request Resource is probably (but not necessarily) colocated with the Target Resource.  Target Resource is potentially public, for clients who don't support OHAI.  Either could be applying a rate limit and passing the info back to the proxy.
[14:21:24] <jhoyla> If you have a layer 7 attack that sends a small number of expensive requests, then the proxy can only rate limit the client no?
[14:21:29] Kathleen Moriarty_web_641 joins the room
[14:21:34] <Robin Wilton_web_367> @Richard +1; and what the proxy is entitled to do *on behalf of any upstream node* should be a ToS matter for them to pre-agree, and make visible to the end user.  Otherwise you run into Andrew C's "collusion" issue.
[14:21:54] <jhoyla> As in, can't the proxy rate limit a single bad client based on this header?
[14:21:57] David Oliver_web_588 leaves the room
[14:21:58] <Daniel Migault_web_264> Let's add a user identifier
[14:22:06] <Erik Nygren_web_167> Presumably a Proxy could look at the ratio of requests with and without feedback to determine if a client is bad.  An example might be a flood of DNS lookups for names in a given domain to hide an attack to an authoritity.
[14:22:12] <Robin Wilton_web_367> @Daniel naughty...  ;^)
[14:22:12] David Navarro_web_893 leaves the room
[14:22:20] <Rajeev RK_web_246> So you are ending up DoSing the proxy instead...
[14:22:31] <Martin Thomson_web_375> why can't the two resources use a back-channel?
[14:22:32] Phillip Hallam-Baker_web_207 joins the room
[14:22:38] <Benjamin Schwartz_web_365> Hm, I think the RateLimit-* headers don't quite work as specified because they would be forwarded back to the client, who would interpret them as coming from the proxy.  I think the right solution is probably to solve this in the RateLimit-* draft.
[14:22:50] <jhoyla> @Erik Nygren I don't think you need to look at the ratio just tarpit clients that send requests that get negative feedback.
[14:22:53] <Robin Wilton_web_367> @Martin because then you need to defend against collusion.
[14:23:04] <Martin Thomson_web_375> robin ???
[14:23:05] Jim Reid_web_522 leaves the room
[14:23:13] Marcus Ihlar_web_346 joins the room
[14:23:15] Craig Taylor_web_885 joins the room
[14:23:19] <Robin Wilton_web_367> @Martin ... if you introduce a backchannel.
[14:23:25] <jhoyla> How would it go back to the client?
[14:23:34] <jhoyla> The proxy can't encapsulate it!
[14:23:35] <Martin Thomson_web_375> the server is overloaded, it tells the proxy: "I'm overloaded, slow some of your noisier clients down"
[14:23:37] lpardue joins the room
[14:23:45] Valery Smyslov_web_912 joins the room
[14:23:49] Luigi Iannone_web_100 leaves the room
[14:23:52] <ekr@jabber.org> won't the client notice when it doesn't get a response
[14:23:56] <Robin Wilton_web_367> @Martin +1; that was actually my proposal on Issue 66.
[14:24:17] <lpardue> please don't reinvent another ratelimit HTTP field
[14:24:18] <Benjamin Schwartz_web_365> Don't HTTP reverse proxies generally forward unrecognized headers?
[14:24:19] <jhoyla> @MT it doesn't even need to be the noisy clients, it can be specific "bad" clients, because the proxy can de-anonymise them.
[14:24:28] <Martin Thomson_web_375> the response from the target will end up at the client, not the proxy
[14:24:37] <Andrew Campling_web_300> Adding to @Richard’s point, it seems like proxies having terms of service accessible to clients would be a good thing. This is something that could then be taken into account by a client in a discovery process.
[14:24:37] <svaldez@jabber.hot-chilli.net/barnowl> Isn't this header outside the encapsulated payload?
[14:24:43] <Martin Thomson_web_375> jhoyla: exactly my point
[14:24:43] <jhoyla> @ekr, not if you respond eventually, just very slowly.
[14:24:46] <Robin Wilton_web_367> @Martin it's an argument for a flag from the target to the proxy, not in the other direction.
[14:24:47] <Mike Bishop_web_802> @jhoyla, if the headers are coming from the public endpoint and are being blindly packaged up by the encapsulator.  You're absolutely correct if you envision this as an endpoint which can consume and respond to an encapsulated request.
[14:24:51] <ekr@jabber.org> @jhoyla: how does it know which ones are bad, other than that they are sending a lot of stuff
[14:24:55] <Christopher Wood_web_562> +1 to Tommy -- the target tells the proxy "I'm overloaded" and the proxy in turn applies rate limits to clients
[14:24:59] Luigi Iannone_web_847 joins the room
[14:25:15] <ekr@jabber.org> Mostly +1 to Tommy as well.
[14:25:35] <jhoyla> @ekr because the signal is sent in response to a single request (at least according to the diagram)
[14:25:55] <ekr@jabber.org> @jhoyla: but my point is that that doesn't actually work
[14:26:00] <ekr@jabber.org> because there's nothing wrong with the request
[14:26:00] sftcd-x-x-z leaves the room
[14:26:02] Craig Taylor_web_885 leaves the room
[14:26:06] Craig Taylor_web_312 joins the room
[14:26:10] Stephen Farrell_web_452 leaves the room
[14:26:13] sftcd joins the room
[14:26:14] Stephen Farrell_web_163 joins the room
[14:26:15] <ekr@jabber.org> it's just that there are too many aggregate requests
[14:26:25] <Tommy Pauly_web_463> Exactly, ekr
[14:26:34] <jhoyla> The thing that's wrong with it is the server says slow down to that one.
[14:26:36] <Richard Barnes_web_149> Mostly +1 to Tommy, though you might want to send different sets of headers Target->Client, Target->Proxy and Request->Proxy
[14:26:38] Frode Sorensen_web_100 leaves the room
[14:26:43] <Richard Barnes_web_149> E2E vs HBH headers
[14:26:44] <jhoyla> Doesn't have to have any fancy logic.
[14:26:53] <ekr@jabber.org> @jhoyla: but then you're just penalizing random people
[14:26:53] <jhoyla> Statistically you'll slow down the noisy clients.
[14:27:01] <Martin Thomson_web_375> target -> client === target -> request
[14:27:06] <Mike Bishop_web_802> Hey, look, we have another use-case for hop-by-hop headers!
[14:27:17] <Martin Thomson_web_375> Mike: hah
[14:27:31] <ekr@jabber.org> @CAW: don't CDNs already have something for this?
[14:27:41] <Christopher Wood_web_562> For rate-limits?
[14:27:43] <npd> isn't there an in-between attack, making an expensive request that could be valid, but if a single client sends it a hundred times, that's inappropriate?
[14:27:47] <Martin Thomson_web_375> Mike: you assume that there is only one hop involved though, so I don't think hbh is the answer.
[14:27:50] <Alissa Cooper_web_225> It's unclear that the property where the attacker does not become aware that the proxy knows it is being overloaded is needed.
[14:28:00] <ekr@jabber.org> Yeah, like if you're just sending too much traffic to my site
[14:28:20] <lpardue> if you want to target something, maybe you need the ratelimit equivelent of targetted cache-control is needed
[14:28:22] Jonathan Reed_web_990 leaves the room
[14:28:30] <Erik Nygren_web_167> It seems like this is solidly in the same bucket of shadow banning (eg, issue #66).  It may be that this area needs more requirement and design-space exploration before jumping into an implementation?
[14:28:32] Florence D_web_724 leaves the room
[14:28:36] Florence D_web_209 joins the room
[14:28:36] <jhoyla> If one client is sending 99% of the traffic, then almost always you'll penalise that client.
[14:29:00] <Martin Thomson_web_375> erik: I don't think that this is quite the same
[14:29:02] Ted Hardie_web_365 leaves the room
[14:29:06] <ekr@jabber.org> @jhoyla: one would hope that in that obvious case, the proxy would *already* have throttled that client
[14:29:06] Ted Hardie_web_755 joins the room
[14:29:07] <Martin Thomson_web_375> it's close, but not exact
[14:29:16] <David Schinazi_web_313> Meetecho could we reduce the gain a little bit in the room? Rajeev is sounding a bit too high volume in the room
[14:29:24] <Martin Thomson_web_375> erik: if this were request --> proxy, then it would be analogous to #66
[14:29:47] <Martin Thomson_web_375> Tiru has framed this as target --> proxy, which is a communication channel that doesn't currently exist
[14:29:48] <lpardue> I wish Rajeev sounded this clear duringthe MASQUE meeting earlier in the week :D
[14:30:00] Monika Ermert_web_228 leaves the room
[14:30:02] <Meetecho> David: ack, coming
[14:30:07] <jhoyla> @ekr, that's why I assume that this is mostly used for requests at a normal rate, but are expensive to process.
[14:30:28] Marco Tiloca_web_203 joins the room
[14:31:02] Monika Ermert_web_354 joins the room
[14:31:12] <jhoyla> @Meetecho thanks, that's much better.
[14:31:43] Jonathan Lennox_web_589 leaves the room
[14:32:02] <Richard Barnes_web_149> strawman resolution: Just use the existing headers for target->client and request->proxy feedback (no target->proxy) (?)
[14:32:17] <Benjamin Schwartz_web_365> "Intermediaries are expected to forward messages even when protocol elements are not recognized (e.g., new methods, status codes, or field names) since that preserves extensibility for downstream recipients."
[14:32:25] <Benjamin Schwartz_web_365> https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#message.forwarding
[14:32:37] Simon Romano_web_119 joins the room
[14:33:00] Chris Box_web_698 leaves the room
[14:33:04] Chris Box_web_264 joins the room
[14:33:11] Jonathan Lennox_web_477 joins the room
[14:33:12] <Erik Nygren_web_167> @mt: the general issue seems to be dealing with abuse in a privacy-preserving manner.  It seems like the approaches are proxy->target (eg, a client reputation bit) and target->proxy channels (eg, this request may want to degrade client reputation).  Rate-limiting on the proxy is just one way to deal with bad reputation.
[14:33:48] <Martin Thomson_web_375> if you s/target/request resource/ then I'm OK
[14:33:50] <Tommy Pauly_web_463> @Ben an OHTTP proxy is not a generic intermediary
[14:33:55] <Christopher Wood_web_562> Do we consider an OHTTP proxy to be an HTTP intermediary in that sense? (I don't)
[14:34:02] <Christopher Wood_web_562> What Tommy said
[14:34:18] <Tommy Pauly_web_463> I absolutely don't think it is — Chris there should probably be more explicit text in the document to clarify that
[14:34:25] <Benjamin Schwartz_web_365> My impression is that a generic gateway can be an OHTTP intermediary.
[14:34:36] Jonathan Lennox_web_477 leaves the room
[14:34:37] <Erik Nygren_web_167> @mt: yeah, s/target/request resource/
[14:34:40] Jonathan Lennox_web_862 joins the room
[14:34:44] <Tommy Pauly_web_463> @ben No, it shouldn't be
[14:34:46] <Christopher Wood_web_562> @Ben That's not correct
[14:34:50] Richard Barnes_web_149 leaves the room
[14:35:14] <Martin Thomson_web_375> a generic gateway would not work well.  you would need to configure it extensively to avoid doing bad stuff
[14:35:20] Jim Reid_web_651 joins the room
[14:35:21] <Christopher Wood_web_562> https://github.com/ietf-wg-ohai/oblivious-http/issues/106
[14:35:28] <Shivan Sahib_web_166> isMalicious header from server to proxy!
[14:35:37] <svaldez@jabber.hot-chilli.net/barnowl> A intermediary needs to specifically support the OHTTP
protocol/privacy guarantees? Generic ones don't give that?
[14:35:40] <Chris Lemmons_web_372> My observation is that most intermediaries don't consider themselves to be HTTP intermediaries per the RFCs. :) I agree that the OHTTP proxy should be explicitly called out as not subject to most of the things we'd normally think about an intermediary.
[14:35:48] Richard Barnes_web_237 joins the room
[14:36:13] Harald Alvestrand_web_762 leaves the room
[14:36:15] Joerg Ott_web_966 joins the room
[14:36:16] <Robin Wilton_web_367> @Eric IMO it makes more sense to fix this one first, and put support for  "shadowbanning" out of scope as a protocol requirement.
[14:36:17] Harald Alvestrand_web_729 joins the room
[14:36:28] <jhoyla> There is a massive difference between sending 1 bit from the proxy (which knows the client identity) to the target, and sending 1 bit from the target (which doesn't know the client identity) to the proxy.
[14:36:46] <jhoyla> The target _can't_ leak what it doesn't know.
[14:36:48] <Andrew Campling_web_300> This discussion seems to indicate that the target needs additional configuration to deal with Oblivious requests (and potential abuse)?
[14:36:57] <Shivan Sahib_web_166> https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-ratelimit-headers#section-4.1
[14:37:23] <jhoyla> I still don't understand how the proxy is encapsulating this info into the response.
[14:37:27] <Erik Nygren_web_167> and it may be that the target resource could return more than a single bit to the proxy (but a question then is how many bits and of what form).
[14:37:27] Ted Hardie_web_755 leaves the room
[14:37:31] Ted Hardie_web_378 joins the room
[14:37:56] <Eric Orth_web_920> @jhoyla: The target doesn't know client identity, but it does know request information that the proxy doesn't know.  They both know important pieces that the other doesn't.
[14:38:26] Richard Barnes_web_237 leaves the room
[14:38:30] Richard Barnes_web_739 joins the room
[14:39:31] <Andrew Campling_web_300> If targets needs to behave differently in order for Oblivious to work well, that‘s a different (bigger) task than simply letting clients decide to use an Oblivious proxy.
[14:39:55] Michael B_web_616 joins the room
[14:40:19] <Tommy Pauly_web_463> Oblivious HTTP is *not* generic. It always requires specially-designed target servers that support this. Targets cannot be accessed using Oblivious HTTP just randomly.
[14:40:41] <ekr@jabber.org> Exactly as Tommy sayss
[14:41:17] <jhoyla> Have the target server send WAF rules to the proxy :P
[14:41:31] <ekr@jabber.org> Indeed, the messages to the target are *encrypted*
[14:42:12] <lpardue> standard for edge WAF (etc)control, sounds useful beyond OHAI
[14:42:27] <Martin Thomson_web_375> I'm seeing a useful kernel of work here, but a lot more is needed than what I see in the current draft.
[14:43:04] Antoine Fressancourt_web_487 joins the room
[14:43:11] <jhoyla> @Rajeev of course the target has to be aware of OHAI, because otherwise it can't decrypt the traffic.
[14:43:11] <Martin Thomson_web_375> Two things: the one bit "this request should count toward a bad reputation for a client" as Erik suggested; and a general "I'm at 90% load, slow down" signal, which is independent of any request.
[14:43:22] <Rich Salz_web_282> i wonder how much could be solved by adding a "target={intermediate/endpoint}" field to the rate-limit headers.
[14:43:34] <ekr@jabber.org> And of course that second one could be piggybacked on some request
[14:43:37] <Richard Barnes_web_739> would it be too heretical to say that the distinction between Request Server and Target Server is not that useful?
[14:43:41] Valery Smyslov_web_912 leaves the room
[14:43:43] Jonathan Lennox_web_862 leaves the room
[14:43:49] <Martin Thomson_web_375> Richard, no, it's not heretical
[14:43:53] <ekr@jabber.org> @RLB: I actually felt the same way
[14:43:59] <Richard Barnes_web_739> might be worth eliding then
[14:43:59] Valery Smyslov_web_258 joins the room
[14:44:09] William Carroll_web_198 leaves the room
[14:44:10] <Martin Thomson_web_375> it's a convenience that we routinely elide in the draft already; it's more of a formality
[14:44:25] <npd> @martin, I think there's a third thing needed: this request was expensive and this user should be slowed down from doing it again, even though it's not malicious, and even though I'm not overwhelmed
[14:44:33] <Martin Thomson_web_375> as in, we can't define the draft without the concept, so we have it, but in practice it will be deployed in the same place
[14:44:36] <Erik Nygren_web_167> I put some notes into #66
[14:44:41] Colin Whorlow_web_841 leaves the room
[14:44:42] <Richard Barnes_web_739> you would probably still have to distinguish between proxy->Req/Tgt and client->Req/Tgt processing
[14:44:45] Colin Whorlow_web_456 joins the room
[14:44:45] <Martin Thomson_web_375> thanks Erik
[14:45:03] <Martin Thomson_web_375> it's not simple
[14:45:04] <Benjamin Schwartz_web_365> npd: That seems like something to put in ratelimit: This request costed X tokens from your leaky token bucket.
[14:46:10] Jim Reid_web_651 leaves the room
[14:46:46] <Mike Bishop_web_802> I think the distinction between them is conceptually useful *if* you assume that the Target Resource might also be a publicly accessible URL.  And perhaps if it lives on a separate server / port.
[14:46:52] <Benjamin Schwartz_web_365> I'm hearing dropouts
[14:47:00] Yoshiro Yoneya_web_629 leaves the room
[14:47:04] Yoshiro Yoneya_web_270 joins the room
[14:47:06] <Shivan Sahib_web_166> yeah Tommy's audio has been clipping intermittently
[14:47:13] <Benjamin Schwartz_web_365> Better now
[14:47:13] <Eric Orth_web_920> Same.  Noticable, but not enough to keep from being generally understandable.
[14:47:16] <Francesca Palombini_web_465> ok so it's not only in room
[14:47:30] <Martin Thomson_web_375> the problem is that information about the target resource isn't actionable without the identity of a proxy and request resource
[14:47:43] <Andrew Campling_web_300> Is Tommy. Connected via Private Relay? :-)
[14:48:07] <Richard Barnes_web_739> i could also envision discovering a proxy for your local network, for example
[14:48:37] Luigi Iannone_web_847 leaves the room
[14:49:47] Christopher Inacio_web_747 joins the room
[14:50:21] <Martin Thomson_web_375> yet another example of DNS being misappropriated for purposes for which it is poorly suited
[14:50:49] Abhijit Singh_web_453 leaves the room
[14:50:53] <David Schinazi_web_313> Hey "shove it in the DNS" is our team sport, stop dunking on it
[14:50:53] Abhijit Singh_web_146 joins the room
[14:51:08] Sean Turner_web_684 leaves the room
[14:51:11] <Martin Thomson_web_375> I'm OK with the example where the ISP server is better able to provide in-network addresses for servers that might be faster/closer/better, but this whole space of policy enforcement via DNS smells bad
[14:51:12] Sean Turner_web_517 joins the room
[14:51:33] <Erik Nygren_web_167> Camels are good at carrying lots?
[14:51:40] <Ted Hardie_web_378> In this scenario, does this result in the Client having access to the ISP ODoH service when it is off network?  So the ISP ODoH service now makes itself available to any off-network oblivious proxies?
[14:51:40] Abhijit Singh_web_146 leaves the room
[14:51:44] <Benjamin Schwartz_web_365> Martin: Doesn't make sense: you want a server close to your proxy, not close to the user
[14:51:44] Abhijit Singh_web_840 joins the room
[14:52:03] <Rajeev RK_web_246> @jhoyla I get that from the discussion, but not from a reading of section  3(Overview) of the draft, especially the Flow diagram on page 4. This diagram gives the impression that the OHTTP ends at the Request Resource, which then forwards the unencapsulated HTTP/S request to the target. Some indication there that this isnt just normal HTTP/S in the diagram would help
[14:52:23] <Mallory Knodel_web_637> Agree. Asking content moderation to happen elsewhere (than the DNS) is a positive outcome of this work imo.
[14:52:25] <Martin Thomson_web_375> Benjamin: I'm not assuming that you are using the proxy for all traffic; it's an OHTTP proxy (or ODoH)
[14:52:58] Andrew S_web_452 joins the room
[14:53:09] <Benjamin Schwartz_web_365> Martin: If you don't have a proxy for all traffic, it's not clear what you've gained.
[14:53:16] <Andrew Campling_web_300> @Tommy: this seems like a reasonable way to fit Oblivious to real-world requirements
[14:53:16] <Martin Thomson_web_375> the reason you use ODoH/DoH/OHTTP is to protect your query history; you might not care about the flows as much
[14:53:32] lpardue leaves the room
[14:53:39] <Benjamin Schwartz_web_365> A hostile resolver can cause the flows to disclose the queries
[14:53:45] <npd> what are the cases where the user wants the ISP's recommended DoH server?
[14:54:24] <Martin Thomson_web_375> npd: for example, Firefox's programme for resolvers includes some ISPs
[14:54:47] Michael B_web_616 leaves the room
[14:54:50] <jhoyla> @Rajeev the request resource can implement all load balancing / rate limiting to logic.
[14:54:51] Michael B_web_121 joins the room
[14:54:51] <Shivan Sahib_web_166> npd: I believe Chrome also prefers that
[14:55:07] <Martin Thomson_web_375> In that case we trust that the server has adequate privacy protections, but we might still use OHTTP to ensure that it doesn't build up a store of toxic query history linked together
[14:55:10] <npd> Martin Thomson_web_375: what's the benefit to the user?
[14:55:32] <npd> (audio is getting worse)
[14:55:46] <David Schinazi_web_313> Between the humming and the chopping it sounds like Tommy is spinning in a laundry machine
[14:55:46] <Martin Thomson_web_375> it's still chopping occasionally
[14:55:48] <Benjamin Schwartz_web_365> Toggling meetecho's mute seems to help
[14:55:51] Antoine Fressancourt_web_487 leaves the room
[14:55:56] <Andrew Campling_web_300> @Ekr your example is why we need a solution to colluding proxies / ODoH targets
[14:56:12] <Eric Orth_web_920> Chrome doesn't necessarily care about the ISP's recommendation, but we do care about the currently-configured DNS's recommendation, and by default that is often the ISP DNS.
[14:57:42] Craig Taylor_web_312 leaves the room
[14:58:28] <Richard Barnes_web_739> doesn't ECH config put HPKE keys in SCVB?
[14:58:43] <ekr@jabber.org> @Andrew: the attack I am proposing is about working with a correctly functioning non-clluding proxy
[14:58:44] <Eric Orth_web_920> +1 to Ben's concerns.  The security model absolutely has to consider that everything is compromised if the proxy is able to get the keys from anybody other than proxy/target collusion.
[14:58:49] <Dan McArdle_web_655> Indeed, though the ECH config goes in HTTPS RRs.
[14:58:58] Florence D_web_209 leaves the room
[14:58:58] <Martin Thomson_web_375> npd: if the ISP resolver is known to be as good (privacy-wise) as another resolver, and better (performance-wise) than that other resolver, where is the down side?
[14:59:02] Florence D_web_782 joins the room
[14:59:08] <ekr@jabber.org> @RLB: ECH is a special case in which the data being hidden (the SNI) is already known to the resolver
[14:59:13] <ekr@jabber.org> At the time you make the query
[14:59:27] <Richard Barnes_web_739> seems like this issue goes away if the parametes were signed with a WebPKI-certified key
[14:59:43] <ekr@jabber.org> @RLB: yeah
[14:59:54] <Richard Barnes_web_739> @ekr except for all the other data in the ClientHello
[15:00:04] <Martin Thomson_web_375> didn't we discuss signing EchConfig?
[15:00:26] <Eric Orth_web_920> Anything that confirms the key came from the target solves this.  DNSSEC, WebPKI, getting it directly from the target, etc.  But the draft needs to discuss these solutions.
[15:00:29] <npd> Martin Thomson_web_375: that's what I'm looking for. the premise is that there's potentially better performance by choosing the ISP's DoH server. but is that the case if the oblivious proxy isn't close to the ISP's DoH server?
[15:00:34] Robin Wilton_web_367 leaves the room
[15:00:37] <Tommy Pauly_web_463> @Eric yes, exactly
[15:01:14] <Richard Barnes_web_739> https://example.com/.well-known/ohai
[15:01:15] <npd> Martin Thomson_web_375: or is the benefit of the ISP's DNS server something else (as Tommy said briefly here, some policy thing like filtering sites out for a known child)?
[15:01:20] <Martin Thomson_web_375> npd: that will depend a great deal on network topology, and whether the client is also using a proxy for the flows it creates to the IP addresses it ultimately learns from the resolver
[15:01:23] <Shivan Sahib_web_166> doesn't the client then leak its IP address to exactly the party it didn't want to leak it to?
[15:01:23] npd leaves the room
[15:01:27] npd joins the room
[15:02:02] <Martin Thomson_web_375> it might not be concerned about leaking its IP address, but about leaking the identity of the sites that it is communicating with to the network
[15:02:04] Ching-Heng Ku_web_677 leaves the room
[15:02:04] <svaldez@jabber.hot-chilli.net/barnowl> Can't the OHTTP Config just be signed with the WebPKI keys and that
blob is what's stored in DNS?
[15:02:06] Christopher Patton_web_254 leaves the room
[15:02:08] Ching-Heng Ku_web_462 joins the room
[15:02:10] Chris Box_web_264 leaves the room
[15:02:10] <Martin Thomson_web_375> ...and to DNS resolvers
[15:02:11] <Benjamin Schwartz_web_365> Shivan: Not necessarily (if it has a MASQUE fallback), and not in a way that is linkable to its further requests (if it has a consistency mechanism)
[15:02:14] Chris Box_web_578 joins the room
[15:02:31] <Richard Barnes_web_739> @svaldez - i suggested that above
[15:02:39] <ekr@jabber.org> @RLB: yes, about other stuff in ECHConfig
[15:02:41] Ching-Heng Ku_web_462 leaves the room
[15:02:43] Eric Rescorla_web_502 leaves the room
[15:03:02] <Erik Nygren_web_167> Per Ben's suggestion, if it is just fetching a cacheable well-known resource then that might help (but there are lots more risk of returning info there that could be used for correlation later).
[15:03:11] <sftcd> @ben-schwartz: sorry, I didn't follow how this enables masquerade as any target - got a link to the mail archive for that? (or did I hear wrong)
[15:03:21] Sean Turner_web_517 leaves the room
[15:03:25] Sean Turner_web_297 joins the room
[15:03:45] <Benjamin Schwartz_web_365> sftcd: https://mailarchive.ietf.org/arch/msg/ohai/xodHZUYPhDIzbPArlwsZO4qwL1A/
[15:03:55] <sftcd> ta
[15:03:56] <Eric Orth_web_920> I like this WG.  Lots of suggestions of just using WebPKI in a DNS-based solution.  DNS WG's normally get controversial if you don't at least mention DNSSEC for similar purposes.
[15:04:10] Sean Turner_web_297 leaves the room
[15:04:14] Sean Turner_web_199 joins the room
[15:04:36] Alan Frindell_web_506 leaves the room
[15:04:53] <Benjamin Schwartz_web_365> WebPKI-signing the OHTTP config is a possible solution, but I think it's operationally much more challenging than directly fetching it (e.g. consider expiration issues)
[15:04:55] Alan Frindell_web_886 joins the room
[15:05:37] <svaldez@jabber.hot-chilli.net/barnowl> Semantically its the WebPKI that's assuring integrity if you were
doing the same fetch without OHTTP, seems odd to have to switch to
trusting DNSSEC to give integrity when doing OHTTP.
[15:05:50] <Martin Thomson_web_375> wow, the lighting in the room has Ted's forehead the same colour as David's shirt.  Very weird.
[15:05:53] Ted Hardie_web_378 leaves the room
[15:05:57] Ted Hardie_web_370 joins the room
[15:06:32] <jhoyla> @MT that's not the lighting, that's the rapidly increasing temperature.
[15:06:47] <jhoyla> Bit of a fail on the ventilation side tbh.
[15:06:49] <Martin Thomson_web_375> David is looking cherry also
[15:07:06] <David Schinazi_web_313> It is getting warm in here
[15:07:09] <Andrew Campling_web_300> It is pretty warm in the room (and getting more so)
[15:07:10] <David Schinazi_web_313> Room is pretty packed
[15:07:11] <Richard Barnes_web_739> controlling one's own temperature -- another advantage of being remote
[15:07:19] <Erik Nygren_web_167> (That room looks an order of magnitude more packed than any of the other sessions I've seen.)
[15:07:19] <sftcd> fwiw, I now (belatedly:-) get Ben Schwartz's problem, and agree with him
[15:07:23] Glenn Deen_web_322 leaves the room
[15:07:37] Jim Reid_web_175 joins the room
[15:07:51] <David Schinazi_web_313> Yeah this has the same in-person attendance as other sessions except this room is about 12 times smaller
[15:08:00] <jhoyla> Yeah, def. not hyperbolic, just a impressively bad bug.
[15:08:18] <Andrew Campling_web_300> @Erik it’s more a function that the room is significantly smaller as the big ones are being set up for the plenary later
[15:08:22] Magnus Westerlund_web_331 leaves the room
[15:08:26] Magnus Westerlund_web_336 joins the room
[15:09:03] <jhoyla> And the A/C appears to be off.
[15:09:06] Qin Wu_web_683 joins the room
[15:09:09] <Shivan Sahib_web_166> yikes
[15:09:46] <svaldez@jabber.hot-chilli.net/barnowl> /s Embed OHTTP configs in origin certificates and clients look them up in CT logs.
[15:10:19] <kaduk@jabber.org/barnowl> Hmm, I thought conventional wisdom for large events was to pre-"warm"
the A/C an hour or two before people show up, because the combined
biological heat output was larger than the cooling rate of the
ventilation system in the steady-state.
[15:10:49] <David Schinazi_web_313> This is IETF your conventional wisdom isn't valid here :P
[15:11:38] Peter Koch_web_954 leaves the room
[15:11:42] Peter Koch_web_410 joins the room
[15:11:47] <jhoyla> Maybe we should write a conference room prep document.
[15:12:09] <Shivan Sahib_web_166> why isn't there an RFC on that
[15:12:44] Abhijit Singh_web_840 leaves the room
[15:12:46] <Richard Barnes_web_739> MUST warm up the AC (BUT WE KNOW YOU WONT)
[15:12:48] Abhijit Singh_web_750 joins the room
[15:12:58] <Sean Turner_web_199> Not very gree
[15:12:58] <David Schinazi_web_313> @Richard perfect
[15:13:00] <Alissa Cooper_web_225> AMS in fact has a manual on room prep
[15:13:42] jhoyla leaves the room
[15:13:48] Abhijit Singh_web_750 leaves the room
[15:13:52] Abhijit Singh_web_270 joins the room
[15:13:53] Monika Ermert_web_354 leaves the room
[15:14:01] <Andrew Campling_web_300> Clarity on use cases may help inform the problem statement
[15:14:06] <Martin Thomson_web_375> this is a good outcome; it's worth doing more work on this, but I'd like more of an exploration of the space before we go there
[15:14:22] <Martin Thomson_web_375> SLEEP
[15:14:27] <David Schinazi_web_313> Going early sounds good, we need fresh air in the in-person room
[15:14:32] <Ted Hardie_web_370> COOL OFF
[15:14:42] <Richard Barnes_web_739> "HOTLY discussed" not just in the AC sense
[15:14:46] <Rich Salz_web_282> Martin, isn't the plenary for sleeping?
[15:14:50] Qin Wu_web_683 leaves the room
[15:14:51] Colin Whorlow_web_456 leaves the room
[15:14:54] Nick Banks_web_901 leaves the room
[15:14:54] Timothy Carlin_web_944 leaves the room
[15:14:55] Colin Whorlow_web_143 joins the room
[15:15:07] Luca Niccolini_web_147 leaves the room
[15:15:12] <kaduk@jabber.org/barnowl> It's so hot that the packets are getting exhausted and falling over
before delivering audio
[15:15:21] Abhijit Singh_web_270 leaves the room
[15:15:23] Mallory Knodel_web_637 leaves the room
[15:15:25] Stephen Farrell_web_163 leaves the room
[15:15:25] Abhijit Singh_web_867 joins the room
[15:15:27] Jim Reid_web_175 leaves the room
[15:15:27] Mallory Knodel_web_437 joins the room
[15:15:31] Abhijit Singh_web_867 leaves the room
[15:15:33] Joerg Ott_web_966 leaves the room
[15:15:35] Abhijit Singh_web_121 joins the room
[15:15:39] <David Schinazi_web_313> The packets are warming up on their way over and expand too much to fit in the local MTU
[15:15:39] sftcd leaves the room
[15:15:39] ekr@jabber.org leaves the room
[15:15:43] <Christopher Wood_web_562> +1 -- an interim on discovery and consistency makes sense
[15:15:59] <Andrew Campling_web_300> Discovery + use cases
[15:16:14] Kyle Ouellette_web_567 leaves the room
[15:16:15] Christopher Wood_web_562 leaves the room
[15:16:15] Steve Olshansky_web_486 leaves the room
[15:16:16] Tirumaleswar Reddy.K_web_685 leaves the room
[15:16:18] Dan McArdle_web_655 leaves the room
[15:16:19] Jonathan Hammell_web_679 leaves the room
[15:16:19] Benjamin Schwartz_web_365 leaves the room
[15:16:21] <Daniel Migault_web_264> and time flight of packet have been caught on the "now" slide.
[15:16:21] Benjamin Kaduk_web_126 leaves the room
[15:16:22] Mark McFadden_web_825 leaves the room
[15:16:23] Alan Frindell_web_886 leaves the room
[15:16:23] Tommy Pauly_web_463 leaves the room
[15:16:24] James Galvin_web_103 leaves the room
[15:16:25] Michael Hollyman_web_197 leaves the room
[15:16:25] Chris Lemmons_web_372 leaves the room
[15:16:26] David Schinazi_web_313 leaves the room
[15:16:26] Daniel Gillmor_web_264 leaves the room
[15:16:27] SeongHan Shin_web_206 leaves the room
[15:16:27] David Navarro leaves the room
[15:16:28] Mike Bishop_web_802 leaves the room
[15:16:28] Peter Koch_web_410 leaves the room
[15:16:29] Geng-Da Tsai_web_294 leaves the room
[15:16:29] Ken Takayama_web_293 leaves the room
[15:16:29] Christian Veenman_web_380 leaves the room
[15:16:29] Chi-Jiun Su_web_519 leaves the room
[15:16:30] David Schinazi_web_606 joins the room
[15:16:30] Richard Barnes_web_739 leaves the room
[15:16:32] <Francesca Palombini_web_465> meetecho: session over! :)
[15:16:34] Christopher Inacio_web_747 leaves the room
[15:16:35] Juliana Guerra_web_561 leaves the room
[15:16:35] Dan Druta_web_960 leaves the room
[15:16:37] Renan Krishna_web_229 leaves the room
[15:16:38] Xavier de Foy_web_774 leaves the room
[15:16:39] Dan Druta_web_355 joins the room
[15:16:44] Erik Nygren_web_167 leaves the room
[15:16:44] Kathleen Moriarty_web_641 leaves the room
[15:16:46] Eric Kinnear_web_634 leaves the room
[15:16:49] Patrick Kelsey_web_727 leaves the room
[15:16:49] Andrew S_web_452 leaves the room
[15:16:52] Tommy Jensen_web_637 leaves the room
[15:16:52] Michael B_web_121 leaves the room
[15:16:53] Rajeev RK_web_246 leaves the room
[15:16:56] Mallory Knodel_web_437 leaves the room
[15:16:56] Jessica Fitzgerald-McKay_web_678 leaves the room
[15:16:57] Sean Turner_web_199 leaves the room
[15:16:58] Rich Salz_web_282 leaves the room
[15:17:02] Francesca Palombini_web_465 leaves the room
[15:17:02] Cullen Jennings_web_696 leaves the room
[15:17:02] Kazunori Fujiwara_web_302 leaves the room
[15:17:02] Yuya Kawakami_web_258 leaves the room
[15:17:02] Andrew Campling_web_300 leaves the room
[15:17:02] Shivan Sahib_web_166 leaves the room
[15:17:02] Rebecca Guthrie_web_558 leaves the room
[15:17:02] Martin Thomson_web_375 leaves the room
[15:17:02] Quynh Dang_web_877 leaves the room
[15:17:02] Kenneth Murchison_web_857 leaves the room
[15:17:02] Brendan Moran_web_787 leaves the room
[15:17:02] Hiroyuki Goto_web_243 leaves the room
[15:17:02] Daniel Migault_web_264 leaves the room
[15:17:02] Nick Doty_web_812 leaves the room
[15:17:02] Alexion Ramos_web_688 leaves the room
[15:17:02] Eric Orth_web_920 leaves the room
[15:17:02] Alyssa Thompson_web_518 leaves the room
[15:17:02] Francisco Arias_web_446 leaves the room
[15:17:02] Chen Li_web_922 leaves the room
[15:17:02] Kazuaki Ueda_web_259 leaves the room
[15:17:02] Samuel Weiler_web_106 leaves the room
[15:17:02] Tadahiko Ito_web_883 leaves the room
[15:17:02] Zewei Chen_web_997 leaves the room
[15:17:02] Simon Hicks_web_584 leaves the room
[15:17:02] Alissa Cooper_web_225 leaves the room
[15:17:02] Stefan Santesson_web_992 leaves the room
[15:17:02] Lorenzo Colitti_web_621 leaves the room
[15:17:02] Phillip Hallam-Baker_web_207 leaves the room
[15:17:02] Marcus Ihlar_web_346 leaves the room
[15:17:02] Marco Tiloca_web_203 leaves the room
[15:17:02] Simon Romano_web_119 leaves the room
[15:17:02] Harald Alvestrand_web_729 leaves the room
[15:17:02] Yoshiro Yoneya_web_270 leaves the room
[15:17:02] Valery Smyslov_web_258 leaves the room
[15:17:02] Florence D_web_782 leaves the room
[15:17:02] Ted Hardie_web_370 leaves the room
[15:17:02] Magnus Westerlund_web_336 leaves the room
[15:17:02] Chris Box_web_578 leaves the room
[15:17:02] Colin Whorlow_web_143 leaves the room
[15:17:02] Abhijit Singh_web_121 leaves the room
[15:17:02] David Schinazi_web_606 leaves the room
[15:17:02] Dan Druta_web_355 leaves the room
[15:17:30] Yoshiro Yoneya leaves the room
[15:17:47] Meetecho leaves the room
[15:18:53] francesca leaves the room
[15:24:05] frodek joins the room
[15:24:13] frodek leaves the room
[15:25:19] jhoyla joins the room
[15:26:13] frodek joins the room
[15:31:58] svaldez@jabber.hot-chilli.net/barnowl leaves the room: Disconnected: closed
[15:34:45] jhoyla leaves the room
[15:37:14] frodek leaves the room
[15:47:25] frodek joins the room
[15:50:21] frodek leaves the room
[15:56:52] svaldez@jabber.hot-chilli.net/barnowl joins the room
[15:58:14] frodek leaves the room
[16:01:29] francesca joins the room
[16:02:35] francesca leaves the room
[16:06:37] sftcd joins the room
[16:08:44] sftcd leaves the room
[16:09:43] pardue joins the room
[16:11:00] pardue leaves the room
[16:24:22] pardue joins the room
[16:29:28] jhoyla joins the room
[16:50:38] jhoyla leaves the room
[16:55:16] jhoyla joins the room
[17:18:39] jhoyla leaves the room
[17:19:43] svaldez@jabber.hot-chilli.net/barnowl leaves the room: Disconnected: closed
[17:19:54] pardue leaves the room
[17:32:19] dkg leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!