[{"author": "Shivan Sahib", "text": "https://notes.ietf.org/notes-ietf-113-ohai
", "time": "2022-03-23T13:31:13Z"}, {"author": "Florence D", "text": "I can take notes
", "time": "2022-03-23T13:31:35Z"}, {"author": "jhoyla", "text": "Happy to help jabber scribe if people need me to relay at the mic.
", "time": "2022-03-23T13:32:30Z"}, {"author": "Richard Barnes", "text": "thanks @jhoyla
", "time": "2022-03-23T13:32:40Z"}, {"author": "Richard Barnes", "text": "impressive as always @mt
", "time": "2022-03-23T13:33:54Z"}, {"author": "Shivan Sahib", "text": "I didn't notice the animation before, wow
", "time": "2022-03-23T13:34:12Z"}, {"author": "jhoyla", "text": "Fabulous slides, impressed that MeetEcho was able to handle that so smoothly.
", "time": "2022-03-23T13:34:25Z"}, {"author": "dkg", "text": "they're cool, but i dunno that they're worth 400Kbps though
", "time": "2022-03-23T13:35:11Z"}, {"author": "dkg", "text": "static slides are important for low-bandwidth participants
", "time": "2022-03-23T13:35:30Z"}, {"author": "Mike Bishop", "text": "I'm seeing ~~514kbps; is it possible that they scale based on bandwidth?
", "time": "2022-03-23T13:36:01Z"}, {"author": "dkg", "text": "i'm seeing 508kbps now
", "time": "2022-03-23T13:36:14Z"}, {"author": "jhoyla", "text": "Fair point dkg.
", "time": "2022-03-23T13:36:23Z"}, {"author": "francesca", "text": "statis slides also here: https://datatracker.ietf.org/meeting/113/session/ohai
", "time": "2022-03-23T13:36:24Z"}, {"author": "dkg", "text": "hard to follow what slide we're on if we're using martin's screenshare though
", "time": "2022-03-23T13:36:46Z"}, {"author": "Meetecho", "text": "We just put a cap, the browser then decides how much bitrate to use for the encoded stream
", "time": "2022-03-23T13:36:48Z"}, {"author": "npd", "text": "will a user be able to know what is being added about them, if the whole point is to be oblivious?
", "time": "2022-03-23T13:38:27Z"}, {"author": "svaldez@jabber.hot-chilli.net/barnowl", "text": "For the shadowbanning case you wouldn't want the user to necessarily
detect the signal.
", "time": "2022-03-23T13:39:04Z"}, {"author": "jhoyla", "text": "To pair this with the streaming / non-atomic issue (up next) couldn't 1-bit be used to encode the IP over multiple rounds?
", "time": "2022-03-23T13:39:15Z"}, {"author": "ekr@jabber.org", "text": "Well, nothing stops the proxy and client from having a side channel
", "time": "2022-03-23T13:40:09Z"}, {"author": "npd", "text": "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?
", "time": "2022-03-23T13:40:11Z"}, {"author": "ekr@jabber.org", "text": "s/client/server/
", "time": "2022-03-23T13:40:22Z"}, {"author": "Mike Bishop", "text": "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.
", "time": "2022-03-23T13:40:36Z"}, {"author": "Richard Barnes", "text": "RFC 6919 is my greatest contribution to the RFC series
", "time": "2022-03-23T13:40:43Z"}, {"author": "ekr@jabber.org", "text": "All of ours
", "time": "2022-03-23T13:40:53Z"}, {"author": "Richard Barnes", "text": "https://datatracker.ietf.org/doc/html/rfc6919#section-1
", "time": "2022-03-23T13:41:02Z"}, {"author": "npd", "text": "should we at least define what the proxy shouldn't do?
", "time": "2022-03-23T13:41:06Z"}, {"author": "Ted Hardie", "text": "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?
", "time": "2022-03-23T13:41:20Z"}, {"author": "npd", "text": "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?
", "time": "2022-03-23T13:41:33Z"}, {"author": "Rich Salz", "text": "@rlb: one of the few 4/1 RFC's that was worth it.
", "time": "2022-03-23T13:41:39Z"}, {"author": "Andrew Campling", "text": "Uncomfortable about introducing a side channel for communications from the proxy unless it is fully transparent to the client
", "time": "2022-03-23T13:41:50Z"}, {"author": "ekr@jabber.org", "text": "We're not introducing a side channel. It's HTTP. There are headers
", "time": "2022-03-23T13:42:04Z"}, {"author": "Richard Barnes", "text": "@ekr your point is that the side channel already exists?
", "time": "2022-03-23T13:42:19Z"}, {"author": "dkg", "text": "the side channel exists whether we introduce it or not
", "time": "2022-03-23T13:42:21Z"}, {"author": "ekr@jabber.org", "text": "Exactly
", "time": "2022-03-23T13:42:24Z"}, {"author": "dkg", "text": "this is a not-side channel
", "time": "2022-03-23T13:42:32Z"}, {"author": "jhoyla", "text": "@rich salz RFC 1925 is also v. useful.
", "time": "2022-03-23T13:42:33Z"}, {"author": "ekr@jabber.org", "text": "Like we're just talking about what text we have restricting what goes in those headers
", "time": "2022-03-23T13:42:53Z"}, {"author": "Rich Salz", "text": "best part of 1925 is that it has errata reported :)
", "time": "2022-03-23T13:43:24Z"}, {"author": "Ted Hardie", "text": "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).
", "time": "2022-03-23T13:43:48Z"}, {"author": "Andrew Campling", "text": "It feels like we\u2019re edging towards normalising colluding proxies and targets
", "time": "2022-03-23T13:44:22Z"}, {"author": "svaldez@jabber.hot-chilli.net/barnowl", "text": "The wording being that X can have a 1-bit value?
", "time": "2022-03-23T13:44:24Z"}, {"author": "Ted Hardie", "text": "Which makes me wonder how oblivious things turn out to be...
", "time": "2022-03-23T13:44:25Z"}, {"author": "jhoyla", "text": "Shadow banning seems like it would fall under @sftcd's ostensibly optional clause.
", "time": "2022-03-23T13:44:30Z"}, {"author": "npd", "text": "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?
", "time": "2022-03-23T13:44:50Z"}, {"author": "dkg", "text": "this is a fundamental architectural problem with the ohai scheme though, right?
", "time": "2022-03-23T13:44:52Z"}, {"author": "svaldez@jabber.hot-chilli.net/barnowl", "text": "It seems like a policy decision between the user and proxy rather than
an in-protocol enforcement?
", "time": "2022-03-23T13:45:29Z"}, {"author": "Ted Hardie", "text": "@dkg agreed, and I think that means we don't want the standards signal to be null, and to treat anything as collusion.
", "time": "2022-03-23T13:45:38Z"}, {"author": "Martin Thomson", "text": "It sounds like we are avoiding SHOULD also, which might need some finesse
", "time": "2022-03-23T13:45:49Z"}, {"author": "jhoyla", "text": "MUST (BUT WE KNOW YOU WON'T)
", "time": "2022-03-23T13:45:49Z"}, {"author": "Ted Hardie", "text": "Sorry, we want the standard signal to be null (no bits)
", "time": "2022-03-23T13:45:51Z"}, {"author": "Christopher Wood", "text": "I think there's a misunderstanding about the MUST here.
", "time": "2022-03-23T13:45:52Z"}, {"author": "Christopher Wood", "text": "(It's a restriction on the proxy about adding things the client explicitly does not know about)
", "time": "2022-03-23T13:46:16Z"}, {"author": "dkg", "text": "Ted: it's interesting that both conclusions *could* be drawn :/
", "time": "2022-03-23T13:46:53Z"}, {"author": "ekr@jabber.org", "text": "Indeed, the geo client hint
", "time": "2022-03-23T13:47:04Z"}, {"author": "sftcd-x-x-z", "text": "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)
", "time": "2022-03-23T13:47:10Z"}, {"author": "dkg", "text": "age limit
", "time": "2022-03-23T13:47:13Z"}, {"author": "dkg", "text": "citizenship
", "time": "2022-03-23T13:47:15Z"}, {"author": "Mike Bishop", "text": "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.
", "time": "2022-03-23T13:47:22Z"}, {"author": "Mike Bishop", "text": "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.
", "time": "2022-03-23T13:47:24Z"}, {"author": "Tommy Pauly", "text": "Yes, targets could report what proxies add
", "time": "2022-03-23T13:47:27Z"}, {"author": "Ted Hardie", "text": "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?
", "time": "2022-03-23T13:47:52Z"}, {"author": "dkg", "text": "but a colluding target would just omit that
", "time": "2022-03-23T13:47:54Z"}, {"author": "sftcd-x-x-z", "text": "adding an example or something showing that might be some good text somewhere (dunno if in an RFC but wherever)
", "time": "2022-03-23T13:47:59Z"}, {"author": "Christopher Wood", "text": "@Ted I think it runs more closely towards the trust model
", "time": "2022-03-23T13:48:44Z"}, {"author": "Andrew Campling", "text": "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.
", "time": "2022-03-23T13:48:52Z"}, {"author": "Christopher Wood", "text": "@Andrew who suggested collusion between proxies and targets?
", "time": "2022-03-23T13:49:17Z"}, {"author": "ekr@jabber.org", "text": "This isn't collusion.
", "time": "2022-03-23T13:49:25Z"}, {"author": "Andrew Campling", "text": "@ekr I disagree
", "time": "2022-03-23T13:49:38Z"}, {"author": "Andrew Campling", "text": "@chris: signalling from the proxy to target is a form of collusion
", "time": "2022-03-23T13:50:41Z"}, {"author": "sftcd-x-x-z", "text": "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)
", "time": "2022-03-23T13:50:43Z"}, {"author": "ekr@jabber.org", "text": "The entire principle of this system is that the proxy makes public guarantees about what it doe sor does not do
", "time": "2022-03-23T13:50:48Z"}, {"author": "jhoyla", "text": "With the shadowban, does the target have any guarantees about the honesty of the proxy?
", "time": "2022-03-23T13:51:00Z"}, {"author": "ekr@jabber.org", "text": "And one of those things might be sending some general data
", "time": "2022-03-23T13:51:04Z"}, {"author": "ekr@jabber.org", "text": "I'm not that interested in a semantic argument about whether that's \"collusion\" or not.
", "time": "2022-03-23T13:51:38Z"}, {"author": "ekr@jabber.org", "text": "@jhoyla: no
", "time": "2022-03-23T13:51:49Z"}, {"author": "Mike Bishop", "text": "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.
", "time": "2022-03-23T13:52:20Z"}, {"author": "Benjamin Schwartz", "text": "Richard: That would allow the proxy to execute a truncation attack.
", "time": "2022-03-23T13:52:23Z"}, {"author": "ekr@jabber.org", "text": "@Mike: correct.
", "time": "2022-03-23T13:52:29Z"}, {"author": "Andrew Campling", "text": "Isn\u2019t the whole point of Oblivious that there should be separation between the proxy and target? Anything that builds links seem like a bad idea
", "time": "2022-03-23T13:52:35Z"}, {"author": "ekr@jabber.org", "text": "Well, or \"nothing\"
", "time": "2022-03-23T13:52:38Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "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.
", "time": "2022-03-23T13:52:57Z"}, {"author": "ekr@jabber.org", "text": "As noted above, that link already exists. It's called HTTP headers
", "time": "2022-03-23T13:53:23Z"}, {"author": "Mike Bishop", "text": "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.
", "time": "2022-03-23T13:53:30Z"}, {"author": "ekr@jabber.org", "text": "@Mike, no I don't think that that's true at all
", "time": "2022-03-23T13:53:41Z"}, {"author": "jhoyla", "text": "@kaduk and a server might decide to only allow signalling proxies.
", "time": "2022-03-23T13:53:50Z"}, {"author": "Richard Barnes", "text": "i have no opinion on whether streaming is needed or not
", "time": "2022-03-23T13:53:52Z"}, {"author": "ekr@jabber.org", "text": "I think Apple Private Relay provides a good example here.
", "time": "2022-03-23T13:54:05Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "@jhoyla: right
", "time": "2022-03-23T13:54:05Z"}, {"author": "ekr@jabber.org", "text": "Apply pays the proxies, but I think \"data goes through both Apple and CF\" is pretty different from \"data just goes through Apple\"
", "time": "2022-03-23T13:54:33Z"}, {"author": "Mike Bishop", "text": "@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.
", "time": "2022-03-23T13:55:20Z"}, {"author": "ekr@jabber.org", "text": "@Mike: In the private relay case, the threat model is Apple looking at your browsing
", "time": "2022-03-23T13:55:58Z"}, {"author": "Mike Bishop", "text": "And as to collusion between the proxies, it *is* a good comparison -- nothing stops one proxy from passing information to the second proxy.
", "time": "2022-03-23T13:56:13Z"}, {"author": "Mike Bishop", "text": "You're trusting Apple's contract with the assorted third-parties that they're not doing that.
", "time": "2022-03-23T13:56:35Z"}, {"author": "ekr@jabber.org", "text": "You're right that nothing stops them. The principle is that they are operated by different people who have reputational reasons not to collude
", "time": "2022-03-23T13:56:37Z"}, {"author": "Eric Orth", "text": "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.
", "time": "2022-03-23T13:56:53Z"}, {"author": "ekr@jabber.org", "text": "No, I'm trusting Cloudflare (and Akamai's) representation that they are not colluding with Apple
", "time": "2022-03-23T13:57:04Z"}, {"author": "Robin Wilton", "text": "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.
", "time": "2022-03-23T13:57:13Z"}, {"author": "Tommy Pauly", "text": "Yeah I'd prefer a different media type
", "time": "2022-03-23T13:57:24Z"}, {"author": "npd", "text": "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
", "time": "2022-03-23T13:57:33Z"}, {"author": "Andrew Campling", "text": "Reputational reasons seems like a pretty thin defence for privacy
", "time": "2022-03-23T13:57:37Z"}, {"author": "ekr@jabber.org", "text": "The current status is no privacy at all, so this is what's known as \"incremental progress\"
", "time": "2022-03-23T13:58:01Z"}, {"author": "Richard Barnes", "text": "@Tommy you mean different media types streaming vs. not?
", "time": "2022-03-23T13:58:12Z"}, {"author": "Robin Wilton", "text": "@npd Why is it the proxy's responsibility to enforce a shadowban?
", "time": "2022-03-23T13:58:12Z"}, {"author": "Tommy Pauly", "text": "@richard yes, exactly. Let that be an extension, and clearly have the client and server know what mode they're in
", "time": "2022-03-23T13:58:48Z"}, {"author": "npd", "text": "@robin that's been a suggestion from some participants, because the proxy is the only one who can reasonably detect malicious/repeated activity
", "time": "2022-03-23T13:58:53Z"}, {"author": "Mike Bishop", "text": "@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.
", "time": "2022-03-23T13:59:06Z"}, {"author": "dkg", "text": "+1 for Robin's suggestion that \"shadowban\" has problematic semantics; if we do this, it should be named something else.
", "time": "2022-03-23T13:59:07Z"}, {"author": "dkg", "text": "(if we do it)
", "time": "2022-03-23T13:59:13Z"}, {"author": "ekr@jabber.org", "text": "@Mike: yes, I 100% agree with that
", "time": "2022-03-23T13:59:20Z"}, {"author": "Tommy Pauly", "text": "Agreed with ekr and Mike on that discussion
", "time": "2022-03-23T13:59:43Z"}, {"author": "Rich Salz", "text": "No collusion, Tommy/Mike.
", "time": "2022-03-23T14:00:18Z"}, {"author": "Andrew Campling", "text": "Shadow ban does have negative connotations, at least to some groups in the US and possibly elsewhere
", "time": "2022-03-23T14:00:25Z"}, {"author": "jhoyla", "text": "How wide does this window need to be to not have to worry about clock skew?
", "time": "2022-03-23T14:00:35Z"}, {"author": "Daniel Migault", "text": "why now not in the middle of accept ?
", "time": "2022-03-23T14:00:49Z"}, {"author": "dkg", "text": "not just that it's pejorative -- that it has implications about things (like content) that the proxy cannot know)
", "time": "2022-03-23T14:00:49Z"}, {"author": "jhoyla", "text": "lol, I guess MT preempted me.
", "time": "2022-03-23T14:00:51Z"}, {"author": "svaldez@jabber.hot-chilli.net/barnowl", "text": "\"Years\".
", "time": "2022-03-23T14:00:55Z"}, {"author": "Richard Barnes", "text": "i would note that ACME has anti-replay nonces at the application layer
", "time": "2022-03-23T14:01:00Z"}, {"author": "David Schinazi", "text": "MT just doesn't realize time travel is real
", "time": "2022-03-23T14:01:18Z"}, {"author": "Tommy Pauly", "text": "@Rich =P
", "time": "2022-03-23T14:01:26Z"}, {"author": "svaldez@jabber.hot-chilli.net/barnowl", "text": "Unintended consequences of mobile daily games.
", "time": "2022-03-23T14:01:26Z"}, {"author": "Jonathan Lennox", "text": "Doesn't TLS (or technically PKIX) break down with clocks that bad?
", "time": "2022-03-23T14:01:34Z"}, {"author": "Richard Barnes", "text": "@Schinazi -- or doesn't want to reveal what he knows
", "time": "2022-03-23T14:01:36Z"}, {"author": "Alan Frindell", "text": "at least time traveling HTTP requests
", "time": "2022-03-23T14:01:36Z"}, {"author": "jhoyla", "text": "@David Schinazi shhhh!
", "time": "2022-03-23T14:01:43Z"}, {"author": "David Schinazi", "text": "@Richard how long does ACME remember nonces?
", "time": "2022-03-23T14:01:45Z"}, {"author": "jhoyla", "text": "It's a secret
", "time": "2022-03-23T14:01:47Z"}, {"author": "npd", "text": "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
", "time": "2022-03-23T14:01:48Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "I may have pointed to the ACME anti-replay nonce pattern as a good
example, on a few occasions.
", "time": "2022-03-23T14:01:54Z"}, {"author": "Richard Barnes", "text": "@David up to the server
", "time": "2022-03-23T14:02:00Z"}, {"author": "Christopher Wood", "text": "@rlb the HPKE context is effectively a nonce here
", "time": "2022-03-23T14:02:18Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Things recover gracefully if the ACME server forgets some nonces
", "time": "2022-03-23T14:02:20Z"}, {"author": "Christopher Wood", "text": "So we add the timestamp to shorten the window over which the server needs to remember them
", "time": "2022-03-23T14:02:31Z"}, {"author": "Robin Wilton", "text": "@npd I would want to distinguish between the target being able to *detect* malicious activity and being able to *attribute* malicious activity.
", "time": "2022-03-23T14:02:55Z"}, {"author": "Rich Salz", "text": "@Jonathan TLS breaks with mis-synced clocks only if you're validating timestamps in certs and many don't bother.
", "time": "2022-03-23T14:02:56Z"}, {"author": "David Schinazi", "text": "We can always put on our HTTP hats and walk over to the other room
", "time": "2022-03-23T14:03:25Z"}, {"author": "Daniel Migault", "text": "do we have data on client clocks ?
", "time": "2022-03-23T14:03:38Z"}, {"author": "jhoyla", "text": "@Rich Salz do we need to care about non-compliant clients?
", "time": "2022-03-23T14:03:40Z"}, {"author": "jhoyla", "text": "@Daniel Migualt there are a few papers I've seen
", "time": "2022-03-23T14:03:58Z"}, {"author": "Rich Salz", "text": "Depends on if \"we\" is the IETF or if its implementors.
", "time": "2022-03-23T14:04:00Z"}, {"author": "David Schinazi", "text": "@Daniel yeah IIRC Chrome did measurements and the results were terrifying
", "time": "2022-03-23T14:04:16Z"}, {"author": "Richard Barnes", "text": "@Migault - the browser vendors have looked at this quite a lot
", "time": "2022-03-23T14:04:21Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "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.
", "time": "2022-03-23T14:04:24Z"}, {"author": "Robin Wilton", "text": "@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.
", "time": "2022-03-23T14:04:34Z"}, {"author": "Rich Salz", "text": "So did Mozilla, which is why OCSP stapling is seven days.
", "time": "2022-03-23T14:04:37Z"}, {"author": "Richard Barnes", "text": "this is why Chrome has \"fix your clock\" guidance if you encounter an expired cert
", "time": "2022-03-23T14:04:37Z"}, {"author": "Shivan Sahib", "text": "@David Schinazi was the clock skew in the order of seconds per day?
", "time": "2022-03-23T14:05:14Z"}, {"author": "Daniel Migault", "text": "@rich@david @Richard thanks. If we have any links , I would be interested.
", "time": "2022-03-23T14:05:21Z"}, {"author": "David Schinazi", "text": "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
", "time": "2022-03-23T14:05:59Z"}, {"author": "ekr@jabber.org", "text": "Of course, if you're 11s behind, you probably won't be 11s for too long :)
", "time": "2022-03-23T14:06:44Z"}, {"author": "Jonathan Lennox", "text": "MT cites https://doi.org/10.1145/3133956.3134007 in his date-requests draft
", "time": "2022-03-23T14:06:54Z"}, {"author": "dkg", "text": "why fuzzed instead of quantized?
", "time": "2022-03-23T14:06:59Z"}, {"author": "Daniel Migault", "text": "on the current slide is there any reason \"now\" is not in the middle ?
", "time": "2022-03-23T14:07:02Z"}, {"author": "jhoyla", "text": "Oh yeah, quantised would still leak on the changes.
", "time": "2022-03-23T14:07:12Z"}, {"author": "jhoyla", "text": "Even fuzzed would leak eventually though.
", "time": "2022-03-23T14:07:27Z"}, {"author": "ekr@jabber.org", "text": "@Daniel: message transmission latency :)
", "time": "2022-03-23T14:07:34Z"}, {"author": "jhoyla", "text": "Esp. in the stream setting
", "time": "2022-03-23T14:07:35Z"}, {"author": "dkg", "text": "i think you want quantized *and* fuzzed (in that order)
", "time": "2022-03-23T14:07:42Z"}, {"author": "Daniel Migault", "text": "@ekr thanks!
", "time": "2022-03-23T14:07:45Z"}, {"author": "npd", "text": "@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
", "time": "2022-03-23T14:07:51Z"}, {"author": "ekr@jabber.org", "text": "Sorry, that was a joke.
", "time": "2022-03-23T14:07:51Z"}, {"author": "Benjamin Schwartz", "text": "dkg: OHTTP provides unlinkability so I think you just need the fuzz
", "time": "2022-03-23T14:07:58Z"}, {"author": "ekr@jabber.org", "text": "I mean, maybe that is what MT meant, but I was joking
", "time": "2022-03-23T14:08:00Z"}, {"author": "jhoyla", "text": "@Ben Schwartz is that true in the streaming case?
", "time": "2022-03-23T14:08:25Z"}, {"author": "dkg", "text": "schwartz: you're assuming that the http request itself won't provide linkability, right?
", "time": "2022-03-23T14:08:45Z"}, {"author": "Benjamin Schwartz", "text": "jhoyla: I think so. Each stream would only have a single date header at the beginning.
", "time": "2022-03-23T14:08:47Z"}, {"author": "David Schinazi", "text": "+1 to what Eric said
", "time": "2022-03-23T14:09:08Z"}, {"author": "dkg", "text": "for example, i could be given a custom URL that i don't realize is unique to me.
", "time": "2022-03-23T14:09:08Z"}, {"author": "Benjamin Schwartz", "text": "dkg: Yes. If your requests are linkable, you should use HTTP CONNECT (or MASQUE)
", "time": "2022-03-23T14:09:13Z"}, {"author": "npd", "text": "@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)
", "time": "2022-03-23T14:09:21Z"}, {"author": "David Schinazi", "text": "I agree that should not be experimental
", "time": "2022-03-23T14:10:14Z"}, {"author": "Eric Orth", "text": "+1 to agreement
", "time": "2022-03-23T14:10:22Z"}, {"author": "Tommy Pauly", "text": "Agreed, not experimental
", "time": "2022-03-23T14:10:22Z"}, {"author": "svaldez@jabber.hot-chilli.net/barnowl", "text": "+1 to unexperimental.
", "time": "2022-03-23T14:10:33Z"}, {"author": "ekr@jabber.org", "text": "not experimental
", "time": "2022-03-23T14:10:59Z"}, {"author": "jhoyla", "text": "@schwartz Oh, of course, because you don't need replay protection on the second packet because of the sequence number.
", "time": "2022-03-23T14:11:07Z"}, {"author": "Andrew Campling", "text": "On discovery, it depends on the use case(s) whether discovery is important. If in doubt include it would seem like a reasonable position.
", "time": "2022-03-23T14:11:07Z"}, {"author": "Daniel Migault", "text": "@npd thanks. what you are saying is that clocks are unlikely to skew forward as opposed as backward.
", "time": "2022-03-23T14:11:38Z"}, {"author": "Christopher Wood", "text": "No
", "time": "2022-03-23T14:11:48Z"}, {"author": "ekr@jabber.org", "text": "Nope.
", "time": "2022-03-23T14:11:50Z"}, {"author": "David Schinazi", "text": "+1 to addressing discovery in another draft
", "time": "2022-03-23T14:11:55Z"}, {"author": "Tommy Pauly", "text": "It would be a mistake to try to discovery in this document
", "time": "2022-03-23T14:12:03Z"}, {"author": "dkg", "text": "please don't discuss discovery in this document
", "time": "2022-03-23T14:12:17Z"}, {"author": "David Schinazi", "text": "I don't necessarily agree that those people are sensible, I happen to know them well
", "time": "2022-03-23T14:12:18Z"}, {"author": "Andrew Campling", "text": "But it does need to be addressed by this group
", "time": "2022-03-23T14:12:21Z"}, {"author": "Mike Bishop", "text": "Discovery changes the scenario we're going after.
", "time": "2022-03-23T14:12:24Z"}, {"author": "Eric Orth", "text": "Absolutely something this WG should work on. Not part of this draft.
", "time": "2022-03-23T14:12:35Z"}, {"author": "Shivan Sahib", "text": "(removing chair hat) this is pretty clearly a protocol doc
", "time": "2022-03-23T14:12:42Z"}, {"author": "Robin Wilton", "text": "@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.
", "time": "2022-03-23T14:13:04Z"}, {"author": "ekr@jabber.org", "text": "Very offended that my last minute issues and PRs weren't on MT's slides
", "time": "2022-03-23T14:13:15Z"}, {"author": "Martin Thomson", "text": "I do agree that we need to get a better handle on what discovery might mean for ohttp
", "time": "2022-03-23T14:13:26Z"}, {"author": "Robin Wilton", "text": "@ekr late binding is a b*tch...
", "time": "2022-03-23T14:13:43Z"}, {"author": "Martin Thomson", "text": "it's clear from Tommy and Tiru's work that there are a lot of moving parts
", "time": "2022-03-23T14:13:47Z"}, {"author": "ekr@jabber.org", "text": "@MT: you had like an hour to add them
", "time": "2022-03-23T14:13:47Z"}, {"author": "Sean Turner", "text": "@MT as usual great slides
", "time": "2022-03-23T14:13:50Z"}, {"author": "Martin Thomson", "text": "ekr: I was busy trying to write up the streaming design
", "time": "2022-03-23T14:14:09Z"}, {"author": "ekr@jabber.org", "text": "NO EXCUSES
", "time": "2022-03-23T14:14:30Z"}, {"author": "Martin Thomson", "text": "hah
", "time": "2022-03-23T14:14:33Z"}, {"author": "Richard Barnes", "text": "we're going to end up reinvent BGP black holes here
", "time": "2022-03-23T14:14:57Z"}, {"author": "npd", "text": "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
", "time": "2022-03-23T14:14:57Z"}, {"author": "Benjamin Schwartz", "text": "I don't get it. Why can't we just use the RateLimit-* headers?
", "time": "2022-03-23T14:17:08Z"}, {"author": "jhoyla", "text": "Given that the proxy can't decapsulate (enucleate) the response do you need to specify that the proxy strips it?
", "time": "2022-03-23T14:17:10Z"}, {"author": "Tommy Pauly", "text": "@ben +1, it seems like we could just use the existing rate-limit header
", "time": "2022-03-23T14:17:27Z"}, {"author": "jhoyla", "text": "Because the proxy is aggregating clients, and needs to allocate them to the clients?
", "time": "2022-03-23T14:18:12Z"}, {"author": "jhoyla", "text": "them=request capacity
", "time": "2022-03-23T14:18:26Z"}, {"author": "jhoyla", "text": "(i.e. the semantics are different)
", "time": "2022-03-23T14:18:43Z"}, {"author": "Richard Barnes", "text": "@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
", "time": "2022-03-23T14:18:46Z"}, {"author": "jhoyla", "text": "Right, I'm just saying that the semantics are different to the rate-limit semantics
", "time": "2022-03-23T14:19:20Z"}, {"author": "Mike Bishop", "text": "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.
", "time": "2022-03-23T14:21:12Z"}, {"author": "jhoyla", "text": "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?
", "time": "2022-03-23T14:21:25Z"}, {"author": "Robin Wilton", "text": "@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.
", "time": "2022-03-23T14:21:35Z"}, {"author": "jhoyla", "text": "As in, can't the proxy rate limit a single bad client based on this header?
", "time": "2022-03-23T14:21:55Z"}, {"author": "Daniel Migault", "text": "Let's add a user identifier
", "time": "2022-03-23T14:21:59Z"}, {"author": "Erik Nygren", "text": "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.
", "time": "2022-03-23T14:22:07Z"}, {"author": "Robin Wilton", "text": "@Daniel naughty... ;^)
", "time": "2022-03-23T14:22:13Z"}, {"author": "Rajeev RK", "text": "So you are ending up DoSing the proxy instead...
", "time": "2022-03-23T14:22:21Z"}, {"author": "Martin Thomson", "text": "why can't the two resources use a back-channel?
", "time": "2022-03-23T14:22:32Z"}, {"author": "Benjamin Schwartz", "text": "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.
", "time": "2022-03-23T14:22:39Z"}, {"author": "jhoyla", "text": "@Erik Nygren I don't think you need to look at the ratio just tarpit clients that send requests that get negative feedback.
", "time": "2022-03-23T14:22:51Z"}, {"author": "Robin Wilton", "text": "@Martin because then you need to defend against collusion.
", "time": "2022-03-23T14:22:54Z"}, {"author": "Martin Thomson", "text": "robin ???
", "time": "2022-03-23T14:23:05Z"}, {"author": "Robin Wilton", "text": "@Martin ... if you introduce a backchannel.
", "time": "2022-03-23T14:23:20Z"}, {"author": "jhoyla", "text": "How would it go back to the client?
", "time": "2022-03-23T14:23:26Z"}, {"author": "jhoyla", "text": "The proxy can't encapsulate it!
", "time": "2022-03-23T14:23:35Z"}, {"author": "Martin Thomson", "text": "the server is overloaded, it tells the proxy: \"I'm overloaded, slow some of your noisier clients down\"
", "time": "2022-03-23T14:23:36Z"}, {"author": "ekr@jabber.org", "text": "won't the client notice when it doesn't get a response
", "time": "2022-03-23T14:23:53Z"}, {"author": "Robin Wilton", "text": "@Martin +1; that was actually my proposal on Issue 66.
", "time": "2022-03-23T14:23:57Z"}, {"author": "lpardue", "text": "please don't reinvent another ratelimit HTTP field
", "time": "2022-03-23T14:24:18Z"}, {"author": "Benjamin Schwartz", "text": "Don't HTTP reverse proxies generally forward unrecognized headers?
", "time": "2022-03-23T14:24:19Z"}, {"author": "jhoyla", "text": "@MT it doesn't even need to be the noisy clients, it can be specific \"bad\" clients, because the proxy can de-anonymise them.
", "time": "2022-03-23T14:24:20Z"}, {"author": "Martin Thomson", "text": "the response from the target will end up at the client, not the proxy
", "time": "2022-03-23T14:24:29Z"}, {"author": "Andrew Campling", "text": "Adding to @Richard\u2019s 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.
", "time": "2022-03-23T14:24:38Z"}, {"author": "svaldez@jabber.hot-chilli.net/barnowl", "text": "Isn't this header outside the encapsulated payload?
", "time": "2022-03-23T14:24:38Z"}, {"author": "Martin Thomson", "text": "jhoyla: exactly my point
", "time": "2022-03-23T14:24:44Z"}, {"author": "jhoyla", "text": "@ekr, not if you respond eventually, just very slowly.
", "time": "2022-03-23T14:24:44Z"}, {"author": "Robin Wilton", "text": "@Martin it's an argument for a flag from the target to the proxy, not in the other direction.
", "time": "2022-03-23T14:24:47Z"}, {"author": "Mike Bishop", "text": "@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.
", "time": "2022-03-23T14:24:48Z"}, {"author": "ekr@jabber.org", "text": "@jhoyla: how does it know which ones are bad, other than that they are sending a lot of stuff
", "time": "2022-03-23T14:24:52Z"}, {"author": "Christopher Wood", "text": "+1 to Tommy -- the target tells the proxy \"I'm overloaded\" and the proxy in turn applies rate limits to clients
", "time": "2022-03-23T14:24:56Z"}, {"author": "ekr@jabber.org", "text": "Mostly +1 to Tommy as well.
", "time": "2022-03-23T14:25:16Z"}, {"author": "jhoyla", "text": "@ekr because the signal is sent in response to a single request (at least according to the diagram)
", "time": "2022-03-23T14:25:36Z"}, {"author": "ekr@jabber.org", "text": "@jhoyla: but my point is that that doesn't actually work
", "time": "2022-03-23T14:25:56Z"}, {"author": "ekr@jabber.org", "text": "because there's nothing wrong with the request
", "time": "2022-03-23T14:26:01Z"}, {"author": "ekr@jabber.org", "text": "it's just that there are too many aggregate requests
", "time": "2022-03-23T14:26:16Z"}, {"author": "Tommy Pauly", "text": "Exactly, ekr
", "time": "2022-03-23T14:26:26Z"}, {"author": "jhoyla", "text": "The thing that's wrong with it is the server says slow down to that one.
", "time": "2022-03-23T14:26:35Z"}, {"author": "Richard Barnes", "text": "Mostly +1 to Tommy, though you might want to send different sets of headers Target->Client, Target->Proxy and Request->Proxy
", "time": "2022-03-23T14:26:37Z"}, {"author": "Richard Barnes", "text": "E2E vs HBH headers
", "time": "2022-03-23T14:26:44Z"}, {"author": "jhoyla", "text": "Doesn't have to have any fancy logic.
", "time": "2022-03-23T14:26:45Z"}, {"author": "ekr@jabber.org", "text": "@jhoyla: but then you're just penalizing random people
", "time": "2022-03-23T14:26:54Z"}, {"author": "jhoyla", "text": "Statistically you'll slow down the noisy clients.
", "time": "2022-03-23T14:26:54Z"}, {"author": "Martin Thomson", "text": "target -> client === target -> request
", "time": "2022-03-23T14:27:02Z"}, {"author": "Mike Bishop", "text": "Hey, look, we have another use-case for hop-by-hop headers!
", "time": "2022-03-23T14:27:07Z"}, {"author": "Martin Thomson", "text": "Mike: hah
", "time": "2022-03-23T14:27:18Z"}, {"author": "ekr@jabber.org", "text": "@CAW: don't CDNs already have something for this?
", "time": "2022-03-23T14:27:32Z"}, {"author": "Christopher Wood", "text": "For rate-limits?
", "time": "2022-03-23T14:27:42Z"}, {"author": "npd", "text": "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?
", "time": "2022-03-23T14:27:44Z"}, {"author": "Martin Thomson", "text": "Mike: you assume that there is only one hop involved though, so I don't think hbh is the answer.
", "time": "2022-03-23T14:27:48Z"}, {"author": "Alissa Cooper", "text": "It's unclear that the property where the attacker does not become aware that the proxy knows it is being overloaded is needed.
", "time": "2022-03-23T14:27:51Z"}, {"author": "ekr@jabber.org", "text": "Yeah, like if you're just sending too much traffic to my site
", "time": "2022-03-23T14:28:01Z"}, {"author": "lpardue", "text": "if you want to target something, maybe you need the ratelimit equivelent of targetted cache-control is needed
", "time": "2022-03-23T14:28:21Z"}, {"author": "Erik Nygren", "text": "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?
", "time": "2022-03-23T14:28:31Z"}, {"author": "jhoyla", "text": "If one client is sending 99% of the traffic, then almost always you'll penalise that client.
", "time": "2022-03-23T14:28:37Z"}, {"author": "Martin Thomson", "text": "erik: I don't think that this is quite the same
", "time": "2022-03-23T14:29:01Z"}, {"author": "ekr@jabber.org", "text": "@jhoyla: one would hope that in that obvious case, the proxy would *already* have throttled that client
", "time": "2022-03-23T14:29:07Z"}, {"author": "Martin Thomson", "text": "it's close, but not exact
", "time": "2022-03-23T14:29:08Z"}, {"author": "David Schinazi", "text": "Meetecho could we reduce the gain a little bit in the room? Rajeev is sounding a bit too high volume in the room
", "time": "2022-03-23T14:29:17Z"}, {"author": "Martin Thomson", "text": "erik: if this were request --> proxy, then it would be analogous to #66
", "time": "2022-03-23T14:29:25Z"}, {"author": "Martin Thomson", "text": "Tiru has framed this as target --> proxy, which is a communication channel that doesn't currently exist
", "time": "2022-03-23T14:29:48Z"}, {"author": "lpardue", "text": "I wish Rajeev sounded this clear duringthe MASQUE meeting earlier in the week :D
", "time": "2022-03-23T14:29:49Z"}, {"author": "Meetecho", "text": "David: ack, coming
", "time": "2022-03-23T14:30:03Z"}, {"author": "jhoyla", "text": "@ekr, that's why I assume that this is mostly used for requests at a normal rate, but are expensive to process.
", "time": "2022-03-23T14:30:08Z"}, {"author": "jhoyla", "text": "@Meetecho thanks, that's much better.
", "time": "2022-03-23T14:31:13Z"}, {"author": "Richard Barnes", "text": "strawman resolution: Just use the existing headers for target->client and request->proxy feedback (no target->proxy) (?)
", "time": "2022-03-23T14:32:03Z"}, {"author": "Benjamin Schwartz", "text": "\"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.\"
", "time": "2022-03-23T14:32:18Z"}, {"author": "Benjamin Schwartz", "text": "https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#message.forwarding
", "time": "2022-03-23T14:32:26Z"}, {"author": "Erik Nygren", "text": "@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.
", "time": "2022-03-23T14:33:13Z"}, {"author": "Martin Thomson", "text": "if you s/target/request resource/ then I'm OK
", "time": "2022-03-23T14:33:49Z"}, {"author": "Tommy Pauly", "text": "@Ben an OHTTP proxy is not a generic intermediary
", "time": "2022-03-23T14:33:51Z"}, {"author": "Christopher Wood", "text": "Do we consider an OHTTP proxy to be an HTTP intermediary in that sense? (I don't)
", "time": "2022-03-23T14:33:56Z"}, {"author": "Christopher Wood", "text": "What Tommy said
", "time": "2022-03-23T14:34:03Z"}, {"author": "Tommy Pauly", "text": "I absolutely don't think it is \u2014 Chris there should probably be more explicit text in the document to clarify that
", "time": "2022-03-23T14:34:19Z"}, {"author": "Benjamin Schwartz", "text": "My impression is that a generic gateway can be an OHTTP intermediary.
", "time": "2022-03-23T14:34:26Z"}, {"author": "Erik Nygren", "text": "@mt: yeah, s/target/request resource/
", "time": "2022-03-23T14:34:38Z"}, {"author": "Tommy Pauly", "text": "@ben No, it shouldn't be
", "time": "2022-03-23T14:34:45Z"}, {"author": "Christopher Wood", "text": "@Ben That's not correct
", "time": "2022-03-23T14:34:47Z"}, {"author": "Martin Thomson", "text": "a generic gateway would not work well. you would need to configure it extensively to avoid doing bad stuff
", "time": "2022-03-23T14:35:15Z"}, {"author": "Christopher Wood", "text": "https://github.com/ietf-wg-ohai/oblivious-http/issues/106
", "time": "2022-03-23T14:35:22Z"}, {"author": "Shivan Sahib", "text": "isMalicious header from server to proxy!
", "time": "2022-03-23T14:35:29Z"}, {"author": "svaldez@jabber.hot-chilli.net/barnowl", "text": "A intermediary needs to specifically support the OHTTP
protocol/privacy guarantees? Generic ones don't give that?
", "time": "2022-03-23T14:35:38Z"}, {"author": "Chris Lemmons", "text": "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.
", "time": "2022-03-23T14:35:41Z"}, {"author": "Robin Wilton", "text": "@Eric IMO it makes more sense to fix this one first, and put support for \"shadowbanning\" out of scope as a protocol requirement.
", "time": "2022-03-23T14:36:17Z"}, {"author": "jhoyla", "text": "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.
", "time": "2022-03-23T14:36:29Z"}, {"author": "jhoyla", "text": "The target _can't_ leak what it doesn't know.
", "time": "2022-03-23T14:36:47Z"}, {"author": "Andrew Campling", "text": "This discussion seems to indicate that the target needs additional configuration to deal with Oblivious requests (and potential abuse)?
", "time": "2022-03-23T14:36:49Z"}, {"author": "Shivan Sahib", "text": "https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-ratelimit-headers#section-4.1
", "time": "2022-03-23T14:36:58Z"}, {"author": "jhoyla", "text": "I still don't understand how the proxy is encapsulating this info into the response.
", "time": "2022-03-23T14:37:24Z"}, {"author": "Erik Nygren", "text": "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).
", "time": "2022-03-23T14:37:28Z"}, {"author": "Eric Orth", "text": "@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.
", "time": "2022-03-23T14:37:57Z"}, {"author": "Andrew Campling", "text": "If targets needs to behave differently in order for Oblivious to work well, that\u2018s a different (bigger) task than simply letting clients decide to use an Oblivious proxy.
", "time": "2022-03-23T14:39:32Z"}, {"author": "Tommy Pauly", "text": "Oblivious HTTP is *not* generic. It always requires specially-designed target servers that support this. Targets cannot be accessed using Oblivious HTTP just randomly.
", "time": "2022-03-23T14:40:20Z"}, {"author": "ekr@jabber.org", "text": "Exactly as Tommy sayss
", "time": "2022-03-23T14:40:42Z"}, {"author": "jhoyla", "text": "Have the target server send WAF rules to the proxy :P
", "time": "2022-03-23T14:41:18Z"}, {"author": "ekr@jabber.org", "text": "Indeed, the messages to the target are *encrypted*
", "time": "2022-03-23T14:41:32Z"}, {"author": "lpardue", "text": "standard for edge WAF (etc)control, sounds useful beyond OHAI
", "time": "2022-03-23T14:42:13Z"}, {"author": "Martin Thomson", "text": "I'm seeing a useful kernel of work here, but a lot more is needed than what I see in the current draft.
", "time": "2022-03-23T14:42:28Z"}, {"author": "jhoyla", "text": "@Rajeev of course the target has to be aware of OHAI, because otherwise it can't decrypt the traffic.
", "time": "2022-03-23T14:43:12Z"}, {"author": "Martin Thomson", "text": "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.
", "time": "2022-03-23T14:43:12Z"}, {"author": "Rich Salz", "text": "i wonder how much could be solved by adding a \"target={intermediate/endpoint}\" field to the rate-limit headers.
", "time": "2022-03-23T14:43:23Z"}, {"author": "ekr@jabber.org", "text": "And of course that second one could be piggybacked on some request
", "time": "2022-03-23T14:43:35Z"}, {"author": "Richard Barnes", "text": "would it be too heretical to say that the distinction between Request Server and Target Server is not that useful?
", "time": "2022-03-23T14:43:38Z"}, {"author": "Martin Thomson", "text": "Richard, no, it's not heretical
", "time": "2022-03-23T14:43:50Z"}, {"author": "ekr@jabber.org", "text": "@RLB: I actually felt the same way
", "time": "2022-03-23T14:43:54Z"}, {"author": "Richard Barnes", "text": "might be worth eliding then
", "time": "2022-03-23T14:44:00Z"}, {"author": "Martin Thomson", "text": "it's a convenience that we routinely elide in the draft already; it's more of a formality
", "time": "2022-03-23T14:44:11Z"}, {"author": "npd", "text": "@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
", "time": "2022-03-23T14:44:26Z"}, {"author": "Martin Thomson", "text": "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
", "time": "2022-03-23T14:44:34Z"}, {"author": "Erik Nygren", "text": "I put some notes into #66
", "time": "2022-03-23T14:44:37Z"}, {"author": "Richard Barnes", "text": "you would probably still have to distinguish between proxy->Req/Tgt and client->Req/Tgt processing
", "time": "2022-03-23T14:44:43Z"}, {"author": "Martin Thomson", "text": "thanks Erik
", "time": "2022-03-23T14:44:46Z"}, {"author": "Martin Thomson", "text": "it's not simple
", "time": "2022-03-23T14:45:04Z"}, {"author": "Benjamin Schwartz", "text": "npd: That seems like something to put in ratelimit: This request costed X tokens from your leaky token bucket.
", "time": "2022-03-23T14:45:05Z"}, {"author": "Mike Bishop", "text": "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.
", "time": "2022-03-23T14:46:47Z"}, {"author": "Benjamin Schwartz", "text": "I'm hearing dropouts
", "time": "2022-03-23T14:46:53Z"}, {"author": "Shivan Sahib", "text": "yeah Tommy's audio has been clipping intermittently
", "time": "2022-03-23T14:47:07Z"}, {"author": "Benjamin Schwartz", "text": "Better now
", "time": "2022-03-23T14:47:14Z"}, {"author": "Eric Orth", "text": "Same. Noticable, but not enough to keep from being generally understandable.
", "time": "2022-03-23T14:47:14Z"}, {"author": "Francesca Palombini", "text": "ok so it's not only in room
", "time": "2022-03-23T14:47:17Z"}, {"author": "Martin Thomson", "text": "the problem is that information about the target resource isn't actionable without the identity of a proxy and request resource
", "time": "2022-03-23T14:47:31Z"}, {"author": "Andrew Campling", "text": "Is Tommy. Connected via Private Relay? :-)
", "time": "2022-03-23T14:47:44Z"}, {"author": "Richard Barnes", "text": "i could also envision discovering a proxy for your local network, for example
", "time": "2022-03-23T14:48:08Z"}, {"author": "Martin Thomson", "text": "yet another example of DNS being misappropriated for purposes for which it is poorly suited
", "time": "2022-03-23T14:50:22Z"}, {"author": "David Schinazi", "text": "Hey \"shove it in the DNS\" is our team sport, stop dunking on it
", "time": "2022-03-23T14:50:54Z"}, {"author": "Martin Thomson", "text": "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
", "time": "2022-03-23T14:51:12Z"}, {"author": "Erik Nygren", "text": "Camels are good at carrying lots?
", "time": "2022-03-23T14:51:34Z"}, {"author": "Ted Hardie", "text": "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?
", "time": "2022-03-23T14:51:41Z"}, {"author": "Benjamin Schwartz", "text": "Martin: Doesn't make sense: you want a server close to your proxy, not close to the user
", "time": "2022-03-23T14:51:45Z"}, {"author": "Rajeev RK", "text": "@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
", "time": "2022-03-23T14:52:04Z"}, {"author": "Mallory Knodel", "text": "Agree. Asking content moderation to happen elsewhere (than the DNS) is a positive outcome of this work imo.
", "time": "2022-03-23T14:52:24Z"}, {"author": "Martin Thomson", "text": "Benjamin: I'm not assuming that you are using the proxy for all traffic; it's an OHTTP proxy (or ODoH)
", "time": "2022-03-23T14:52:26Z"}, {"author": "Benjamin Schwartz", "text": "Martin: If you don't have a proxy for all traffic, it's not clear what you've gained.
", "time": "2022-03-23T14:53:10Z"}, {"author": "Andrew Campling", "text": "@Tommy: this seems like a reasonable way to fit Oblivious to real-world requirements
", "time": "2022-03-23T14:53:17Z"}, {"author": "Martin Thomson", "text": "the reason you use ODoH/DoH/OHTTP is to protect your query history; you might not care about the flows as much
", "time": "2022-03-23T14:53:17Z"}, {"author": "Benjamin Schwartz", "text": "A hostile resolver can cause the flows to disclose the queries
", "time": "2022-03-23T14:53:40Z"}, {"author": "npd", "text": "what are the cases where the user wants the ISP's recommended DoH server?
", "time": "2022-03-23T14:53:46Z"}, {"author": "Martin Thomson", "text": "npd: for example, Firefox's programme for resolvers includes some ISPs
", "time": "2022-03-23T14:54:25Z"}, {"author": "jhoyla", "text": "@Rajeev the request resource can implement all load balancing / rate limiting to logic.
", "time": "2022-03-23T14:54:51Z"}, {"author": "Shivan Sahib", "text": "npd: I believe Chrome also prefers that
", "time": "2022-03-23T14:54:52Z"}, {"author": "Martin Thomson", "text": "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
", "time": "2022-03-23T14:55:08Z"}, {"author": "npd", "text": "Martin Thomson_web_375: what's the benefit to the user?
", "time": "2022-03-23T14:55:11Z"}, {"author": "npd", "text": "(audio is getting worse)
", "time": "2022-03-23T14:55:33Z"}, {"author": "David Schinazi", "text": "Between the humming and the chopping it sounds like Tommy is spinning in a laundry machine
", "time": "2022-03-23T14:55:47Z"}, {"author": "Martin Thomson", "text": "it's still chopping occasionally
", "time": "2022-03-23T14:55:47Z"}, {"author": "Benjamin Schwartz", "text": "Toggling meetecho's mute seems to help
", "time": "2022-03-23T14:55:49Z"}, {"author": "Andrew Campling", "text": "@Ekr your example is why we need a solution to colluding proxies / ODoH targets
", "time": "2022-03-23T14:55:57Z"}, {"author": "Eric Orth", "text": "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.
", "time": "2022-03-23T14:56:13Z"}, {"author": "Richard Barnes", "text": "doesn't ECH config put HPKE keys in SCVB?
", "time": "2022-03-23T14:58:29Z"}, {"author": "ekr@jabber.org", "text": "@Andrew: the attack I am proposing is about working with a correctly functioning non-clluding proxy
", "time": "2022-03-23T14:58:44Z"}, {"author": "Eric Orth", "text": "+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.
", "time": "2022-03-23T14:58:45Z"}, {"author": "Dan McArdle", "text": "Indeed, though the ECH config goes in HTTPS RRs.
", "time": "2022-03-23T14:58:50Z"}, {"author": "Martin Thomson", "text": "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?
", "time": "2022-03-23T14:58:59Z"}, {"author": "ekr@jabber.org", "text": "@RLB: ECH is a special case in which the data being hidden (the SNI) is already known to the resolver
", "time": "2022-03-23T14:59:09Z"}, {"author": "ekr@jabber.org", "text": "At the time you make the query
", "time": "2022-03-23T14:59:14Z"}, {"author": "Richard Barnes", "text": "seems like this issue goes away if the parametes were signed with a WebPKI-certified key
", "time": "2022-03-23T14:59:28Z"}, {"author": "ekr@jabber.org", "text": "@RLB: yeah
", "time": "2022-03-23T14:59:44Z"}, {"author": "Richard Barnes", "text": "@ekr except for all the other data in the ClientHello
", "time": "2022-03-23T14:59:55Z"}, {"author": "Martin Thomson", "text": "didn't we discuss signing EchConfig?
", "time": "2022-03-23T15:00:05Z"}, {"author": "Eric Orth", "text": "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.
", "time": "2022-03-23T15:00:27Z"}, {"author": "npd", "text": "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?
", "time": "2022-03-23T15:00:30Z"}, {"author": "Tommy Pauly", "text": "@Eric yes, exactly
", "time": "2022-03-23T15:00:38Z"}, {"author": "Richard Barnes", "text": "https://example.com/.well-known/ohai
", "time": "2022-03-23T15:01:15Z"}, {"author": "npd", "text": "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)?
", "time": "2022-03-23T15:01:16Z"}, {"author": "Martin Thomson", "text": "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
", "time": "2022-03-23T15:01:21Z"}, {"author": "Shivan Sahib", "text": "doesn't the client then leak its IP address to exactly the party it didn't want to leak it to?
", "time": "2022-03-23T15:01:24Z"}, {"author": "Martin Thomson", "text": "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
", "time": "2022-03-23T15:02:03Z"}, {"author": "svaldez@jabber.hot-chilli.net/barnowl", "text": "Can't the OHTTP Config just be signed with the WebPKI keys and that
blob is what's stored in DNS?
", "time": "2022-03-23T15:02:05Z"}, {"author": "Martin Thomson", "text": "...and to DNS resolvers
", "time": "2022-03-23T15:02:11Z"}, {"author": "Benjamin Schwartz", "text": "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)
", "time": "2022-03-23T15:02:12Z"}, {"author": "Richard Barnes", "text": "@svaldez - i suggested that above
", "time": "2022-03-23T15:02:32Z"}, {"author": "ekr@jabber.org", "text": "@RLB: yes, about other stuff in ECHConfig
", "time": "2022-03-23T15:02:40Z"}, {"author": "Erik Nygren", "text": "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).
", "time": "2022-03-23T15:03:03Z"}, {"author": "sftcd", "text": "@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)
", "time": "2022-03-23T15:03:12Z"}, {"author": "Benjamin Schwartz", "text": "sftcd: https://mailarchive.ietf.org/arch/msg/ohai/xodHZUYPhDIzbPArlwsZO4qwL1A/
", "time": "2022-03-23T15:03:46Z"}, {"author": "sftcd", "text": "ta
", "time": "2022-03-23T15:03:56Z"}, {"author": "Eric Orth", "text": "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.
", "time": "2022-03-23T15:03:57Z"}, {"author": "Benjamin Schwartz", "text": "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)
", "time": "2022-03-23T15:04:54Z"}, {"author": "svaldez@jabber.hot-chilli.net/barnowl", "text": "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.
", "time": "2022-03-23T15:05:38Z"}, {"author": "Martin Thomson", "text": "wow, the lighting in the room has Ted's forehead the same colour as David's shirt. Very weird.
", "time": "2022-03-23T15:05:51Z"}, {"author": "jhoyla", "text": "@MT that's not the lighting, that's the rapidly increasing temperature.
", "time": "2022-03-23T15:06:33Z"}, {"author": "jhoyla", "text": "Bit of a fail on the ventilation side tbh.
", "time": "2022-03-23T15:06:48Z"}, {"author": "Martin Thomson", "text": "David is looking cherry also
", "time": "2022-03-23T15:06:50Z"}, {"author": "David Schinazi", "text": "It is getting warm in here
", "time": "2022-03-23T15:07:07Z"}, {"author": "Andrew Campling", "text": "It is pretty warm in the room (and getting more so)
", "time": "2022-03-23T15:07:10Z"}, {"author": "David Schinazi", "text": "Room is pretty packed
", "time": "2022-03-23T15:07:11Z"}, {"author": "Richard Barnes", "text": "controlling one's own temperature -- another advantage of being remote
", "time": "2022-03-23T15:07:12Z"}, {"author": "Erik Nygren", "text": "(That room looks an order of magnitude more packed than any of the other sessions I've seen.)
", "time": "2022-03-23T15:07:20Z"}, {"author": "sftcd", "text": "fwiw, I now (belatedly:-) get Ben Schwartz's problem, and agree with him
", "time": "2022-03-23T15:07:20Z"}, {"author": "David Schinazi", "text": "Yeah this has the same in-person attendance as other sessions except this room is about 12 times smaller
", "time": "2022-03-23T15:07:52Z"}, {"author": "jhoyla", "text": "Yeah, def. not hyperbolic, just a impressively bad bug.
", "time": "2022-03-23T15:08:01Z"}, {"author": "Andrew Campling", "text": "@Erik it\u2019s more a function that the room is significantly smaller as the big ones are being set up for the plenary later
", "time": "2022-03-23T15:08:19Z"}, {"author": "jhoyla", "text": "And the A/C appears to be off.
", "time": "2022-03-23T15:09:04Z"}, {"author": "Shivan Sahib", "text": "yikes
", "time": "2022-03-23T15:09:10Z"}, {"author": "svaldez@jabber.hot-chilli.net/barnowl", "text": "/s Embed OHTTP configs in origin certificates and clients look them up in CT logs.
", "time": "2022-03-23T15:09:47Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "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.
", "time": "2022-03-23T15:10:20Z"}, {"author": "David Schinazi", "text": "This is IETF your conventional wisdom isn't valid here :P
", "time": "2022-03-23T15:10:50Z"}, {"author": "jhoyla", "text": "Maybe we should write a conference room prep document.
", "time": "2022-03-23T15:11:48Z"}, {"author": "Shivan Sahib", "text": "why isn't there an RFC on that
", "time": "2022-03-23T15:12:10Z"}, {"author": "Richard Barnes", "text": "MUST warm up the AC (BUT WE KNOW YOU WONT)
", "time": "2022-03-23T15:12:47Z"}, {"author": "Sean Turner", "text": "Not very gree
", "time": "2022-03-23T15:12:59Z"}, {"author": "David Schinazi", "text": "@Richard perfect
", "time": "2022-03-23T15:12:59Z"}, {"author": "Alissa Cooper", "text": "AMS in fact has a manual on room prep
", "time": "2022-03-23T15:13:01Z"}, {"author": "Andrew Campling", "text": "Clarity on use cases may help inform the problem statement
", "time": "2022-03-23T15:14:02Z"}, {"author": "Martin Thomson", "text": "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
", "time": "2022-03-23T15:14:07Z"}, {"author": "Martin Thomson", "text": "SLEEP
", "time": "2022-03-23T15:14:23Z"}, {"author": "David Schinazi", "text": "Going early sounds good, we need fresh air in the in-person room
", "time": "2022-03-23T15:14:28Z"}, {"author": "Ted Hardie", "text": "COOL OFF
", "time": "2022-03-23T15:14:33Z"}, {"author": "Richard Barnes", "text": "\"HOTLY discussed\" not just in the AC sense
", "time": "2022-03-23T15:14:43Z"}, {"author": "Rich Salz", "text": "Martin, isn't the plenary for sleeping?
", "time": "2022-03-23T15:14:47Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "It's so hot that the packets are getting exhausted and falling over
before delivering audio
", "time": "2022-03-23T15:15:13Z"}, {"author": "David Schinazi", "text": "The packets are warming up on their way over and expand too much to fit in the local MTU
", "time": "2022-03-23T15:15:40Z"}, {"author": "Christopher Wood", "text": "+1 -- an interim on discovery and consistency makes sense
", "time": "2022-03-23T15:15:44Z"}, {"author": "Andrew Campling", "text": "Discovery + use cases
", "time": "2022-03-23T15:16:00Z"}, {"author": "Daniel Migault", "text": "and time flight of packet have been caught on the \"now\" slide.
", "time": "2022-03-23T15:16:22Z"}, {"author": "Francesca Palombini", "text": "meetecho: session over! :)
", "time": "2022-03-23T15:16:33Z"}]