OHAI Working Group - IETF 113

Current work (60 minutes)

• Issue discussion (Martin Thomson)
  • Changes in draft-01
    • Moved padding to binary messages
    • Changes to request/response changes
    • New text on resource mapping and anti-relay
  • Issue 66 Shadow Banning - Should proxy be able to signal to oblivious request resource. Is one bit enough? (one bit option in PR 96)
    • Eric Rescorla (EKR) - There are a number of things you might want proxy to say. These are all out of scope for this protocol, we should leave that to applications. What's in the metadata is for client and proxy to work out themselves.
    • MT - So as long as the things the proxy might say to the client are known to the client then the client can use that as part of its decision to use proxy.
    • Chris Wood (CW) - That's what the text tries to say at the minute. Public metadata is agreed between client and proxy. Private metadata must be strictly bounded. Need to trust proxy not to do bad things.
    • MT - There are two things here: 1. types of metadata and 2. values the metadata might take.
    • CW - Client doesn't know precise value, just the type of value that might be communicated.
    • Tommy Pauly (TP) - Agree with EKR that it's difficult/impossible to make this normative. Maybe we should have a normative statement about future standardisation. Agree this comes down to trust between client and proxy.
    • Shivan Sahib (SS) - Think this should be a SHOULD and we should describe what might go badly.
    • David Schinazi (DS) - This is unenforceable and we'll probably have uses for it later. I'd prefer no MUST. A SHOULD is good.
    • EKR - Let's go back to pull request. People seem to agree we should give some guidance but not enforce anything.
    • MT - A lot of this might be generic HTTP things that would benefit from standardisation. Could take these to HTTP WG.
    • Conclusion: No resolution, discussion to continue on the PR
  • Issue 75 Streaming - OHTTP is atomic, generic HTTP is streaming. Should we change that? Martin has a design for streaming OHTTP, chunk message and apply HPKE multiple times.
    • Ben Schwartz (BS) - Can you confirm that proxy can stream requests and responses? MT - yes, it's the client and server that can't. BS - I would prefer this in a separate document as an extension to HPKE.
    • Richard Barnes (RB) - HPKE has concept we could use. I was wondering if we need something new here? Can we use chunked encoding? MT - I don't think we can rely on that here.
    • TP - Does supporting this change the wire format for the encapsulated request? MT - Just add a zero byte to the beginning of the frame, otherwise exactly the same. TP - use cases? MT - Some things I've been looking at for MPC (multi party computation) submission of ads would benefit from streaming.
    • DS - Not sure we have a real use case. At some point you can just use MASQUE.
    • Conclusion: Martin Thomson will ship a PR and people can see what they think.
  • Issues 76 and 89 - Anti-Replay. Two options: 1. Servers don't care 2. Servers remember part of every request they receive. Proposed solution: include date in requests and remember requests for a limited period. If client clocks are bad the client can retry - see date-requests draft.
    • EKR - Confirming that this is about replay by proxy. Maybe the answer is just don't try to correct the clock. Can try with a nonce and skip the clock part.
    • BS - Neither draft mentions problem of distinctive skew linkability, where you'd lose oblivious property.
    • TP - Normative bits should be more general. Client and target should ensure that protocol isn't vulnerable to replay attacks.
    • Eric Orth (EO) - Not sure this belongs in the main oblivious draft. There could be just a quick informational draft.
    • Conclusion: Take this to the list.
  • Issue 58 - should this be experimental?
    • Suggest no. No objections expressed, support for "not experimental" in chat
    • Conclusion: not experimental.
  • Issue 19 - should we address discovery?
    • Suggest: Not in this draft. No objections expressed, support for "no discovery" in chat
    • RB: Note that charter says that the WG may discuss other use cases and discovery, so it is secondary to main draft at best.
    • Conclusion: Close issue and move on.

New work (30 minutes)

• Oblivious Proxy Feedback (Tirumal Reddy) - 10 mins
  • Problem: if traffic from oblivious proxy to target server is too high then server will rate limit proxy.
  • Proposal: signal overload from server to oblivious proxy. Have defined a new HTTP header Ohai-Proxy-Feedback. Signals to proxy resource via the request resource so the proxy resource can rate limit an offending client. Parameters align with fields in draft-ietf-httpapi-ratelimit-headers.
    • DS - Can you clarify whether proxy resource or request resource is being overwhelmend? TR - Could be request resource or target resource.
    • EKR - How is this meant to work? TR - There are different types of attacks. EKR - This doesn't work where traffic is legitimate looking. TR - Rate limit doesn't need to be specific for client, could be for a proxy resource. EKR - Don't see how this works, you're going to have to rate limit everything.
    • TP - Doesn't seem to be quite aligned with draft-ietf-httpapi-ratelimit-headers. Suggest you just use the ratelimit header. TR - We didn't want to signal to go back to the client, just to the proxy. TP - Overall for HTTP the proxy shouldn't be relaying arbitrary headers. We should have normal rate limiting between target and proxy. We don't need more layers of rate limiting.
  • Security considerations - should header only be conveyed to trusted proxies? i.e. authenticated proxies.
  • Comments:
    • Rajeev RK (RRK) - Not convinced rate limit approach is the right approach. Won't work for individual malicious requests. Trying to protect against these could DoS server. Target resource should not know that the traffic is coming from an oblivious proxy. TR - The target will know this because of the protocol, doesn't affect privacy. (Conclusion on this topic is to go to the list).
    • RRK - Doesn't work effectively against volumetric attacks either. TR - Depends on how you authenticate clients.
    • EO - Simplest thing we can do is that the server sends a bit to the proxy saying something is bad with request. Sounds similar to shadow banning. Suggest shelving this until we've decided what to do on shadow banning.
    • BS - Think this issue is worth solving. Understand concern about using unmodified rate limit headers directly. Suggest working with the ratelimit-headers draft to ensure it works in the way you want.
    • MT - There's an idea of sending a single bit from proxy to request resource saying a request is suspicious. Same thing could work from request resource to proxy. Needs private channel. Looking at proposal: if request resource and target resource are co-located none of this communication needs to happen. Otherwise, I don't think this works.
    • RRK - Suggest having some text in the draft saying that requests should have something in the header saying they come from a proxy.
    • SS (chair) - I think there's a need for something like this but it's not clear whether it fits in the rate limiting draft or in OHAI.
  • Conclusion: Work on feedback, and then go to mailing list to see which WG this fits in.
• Distribution of Oblivious Configurations via Service Binding Records (Tommy Pauly) - 20 mins
  • Starting point for discussion on discovery.
  • Draft defines sending configs and paths for OHTTP targets via SVCB. New record parameters. Explains this for generic HTTP services and for Oblivious DNS.
  • Draft doesn't cover oblivious proxy discovery. Not sure there's much of a use case for this.
  • DNS example: client can access ISP ODoH target through a proxy if the target is known to the proxy.
  • Deployment model: client knows one or more proxies it trusts. Client wants to access oblivious targets, client can discover if a target is supported by a proxy and the path.
  • Unknown/untrusted proxy use case is less clear. Interested to hear these.
  • Next steps: Adopt? Get SVCB parameter adopted.
  • Comments:
    • EKR - Need to think through privacy implications. Suppose I have two DNS endpoints, and give one to only one user. Lose privacy properties. TP - Relies on trust relationship between client and proxy. Proxy can recognise if there are clients with unique paths or clients can work with other clients to detect unique configurations.
    • BS - I conclude this isn't secure. This hands over root CA powers to the proxy server. I am seriously concerned and don't support the draft as written. TP - I disagree. There's a trust relationship between the client and the proxy. BS - Can't trust DNS. Proxy can swap out DNS responses. I also don't like the use of the path parameter. Would like a fixed path, something in .well-known. I think there's a simpler approach, a fixed flag saying "I need OHTTP" and then the client can contact the target directly and get OHTTP path.
    • Ted Hardie (TH) - Is the assumption that if ISP DNS resolver presents ISP ODoH target then it must be globally accessible on the network? Typically ISP DNS resolvers aren't globally accessible. TP - Yes. Doesn't need to be globally accessible but does need to be accessible by the proxies, so not isolated in ISP network. TH - Then options are to try all proxies to see if they're on the allow list or to publish the allow list. This changes the scope to include discovery for the proxy. TP - You could get trusted proxies with target configuration. Otherwise client can have established relationship with proxy to check if it has a relationship with a particular target. TH - Need to work this out in more detail.
    • DS - There's a problem worth solving here. Agree with Ben that this solution breaks security model of the protocol.
    • MT - Open problem: finding the set of proxies the target and client trust respectively is difficult as there's no way of discovering proxies. Think we need something more on this. TP - existing model requires proprietary mechanism between client/proxies/target. With this new mechanism you still need proprietary comms between proxy and client. Something more generic is more difficult. MT - Think we need to think these issues through.
    • Chris Box (CB) - I think this is a really interesting idea. Allows ISP to offer DNS based services without requiring client's identity. Agree we need to explore implications but it's a good idea and I'd like to see it identified.
    • EO - Similar to last comment. Like overall solution. Question is if we should solve security issues before adoption or adopt and then solve security issues. I support adoption.
    • TP - Contribute on github please.
    • BS - I think we need more of an integrated architecture approach. What makes sense depends on how we handle key consistency. Would like to see us step back and produce a clean overall solution.
  • RB (chair) - Energy around this, problem useful to solve but the draft isn't in a state to adopt yet.
  • Conclusion: Keep working on draft, refining security requirements and we can look at this again.

Buffer time (20 minutes)

• SS - Would people be interested in virtual interims e.g. on shadow banning? Please let us know.
  • MT: I think we can come to a conclusion on shadow banning in the next weeks. The anti-replay stuff is less settled but I think we can make good progress. Might be good to have an interim on discovery.
  • Conclusion : Don't need to schedule interim now but chairs are happy to schedule them if it would be useful.

AOB (5 minutes)