OHAI Working Group Agenda - IETF 115

Time and Date

• Wednesday Session II (July 26 2022): 1 - 2.30 pm GMT
• In-Person Room: Richmond 1
• IETF Agenda Link

Links

• Meetecho remote participation
• Meeting chat
• Notes/minutes
• Chair slides

Agenda

Administrivia (10 minutes)

• Welcome
• Blue sheets / scribe selection / NOTE WELL
• Agenda revision
• Oblivious HTTP submitted for publication
• New work adopted

Current Work (25 minutes)

• Distribution of Oblivious Configurations via Service Binding
  Records (Tommy Pauly) - 25 mins

Slides

Tommy provided review describing both the goal and the mechanism. He
then moved on to open issues:

• SVCB Parameter Name
  GH Issue
  Proposal: "ohttp" or leave it "oblivious"

Ben Schwartz: after considering the open issues, I think that we should
park this until we solve some other things. "oblivious" changes the
behaviour of a DNS client, for instance, or don't use other transports
if it supports obliviousness, then maybe it could be a cross-transport
thing.

Chat: Seems to be okay with "ohttp".

• DNS Media Type
  GH Issue
  Proposal: OHTTP(BHTTP(DNS message))

Use case is oblivious DNS, where the DNS scheme is used for SVCB.

Tommy: The media type should be the same for the relay and gateway in
DoH. OHTTP wrapping a raw DNS message directly might allow for other
cases, but we might avoid doing that. Mints new acronym DOOH - DNS over
oblivious HTTP.

Ben Schwartz: Creating divergence. Should we claw back OHTTP I-D?

Tommy: you can have other things inside, the spec is correct in its
advice, but we could do something different.

Ralf Weber: This means if I am writing a DoH sserver I have to support
DoH over (lots of things)?

Tommy: This makes it somewhat easier because you only have a bit
wrapping to deal with. A gateway can make requests to an unmodified DoH
Server; a request immediately in OHTTP encapsulation means that the
gateway needs to understand DNS too

Martin Thomson: I am not really sure what sort of thing we're talking
about here because you can do all of theesse things. You should pick
one. If you're doing Oblivious DoH this makes sense. For a Oblivious DNS
this might not make sense; we don't need to define this here.

Tommy: when you receive oblivious over SVCB, do you then assume this or
something else?

Action Item: Will clarify.

• DDR Verification
  GH Issue
  Issue: if you get this from _dns.resolver.arpa, you need to
  validate the IP

Martin Thomson: I think this is something we can leave to the DDR. We
have ref id using to refer to the server.

Back to issue #30.
s
Ben Schwartz: the DNS says "oblivious" (or "ohttp") does that also apply
to DNS over QUIC if that ever is defined, or . One answer is that it
only applyfor oblivious HTTP.

Ralf: that is not how DNS works. you have RRs. Each record will say
oblivious or not.

Ben: SVCB uses a single service record to cover multiple protocols.

Ralf: they are different RR sets.

Ben: You can create a single service binding record. The one record can
include multiple protocols, all marked "oblivious". What does that mean?

Tommy: I think you original issue and suggestion is correct. This really
needs to be "ohttp".

Richard Barnes (Individual): agree with Tommy. We don't want to bundle
all the protocols together and be forced to implement all features on
all endpoints. Keep them separate.

DKG: Agree with the previous speakers. Can you do DNS oblviously - what
does that mean? "ohttp"

Ekr: I concur. This spec is two things: an encapsultaiton mechanism and
a set of indicators you provided to the gateway. To do this with
annother protocol you need another set. In particular, if you were going
to provide a conceptually similar service for QUIC it's called MASQUE!

Tommy: got input will revise I-D.

Proposed work (45 minutes)

• Oblivious Relay Feedback (Tiru Reddy) - 10 mins
  Slides

Tiru provided the motivations for the I-D and reviewed changes made as a
result of WG feedback.

DKG: Not sure I understand your arguement about this preserves the
annonmity of the clients. Seems like you're saying in the annonimity is
able to partition a small number of users.

Tiru: Yes.

DKG: But if there is a lot of clients and there is one offender. Then
it's easy to figure out who it is.

Tiru: explains mechanism on slide 7.

DKG: This doesn't sound like it has the guarantees I would want as a
client.

Ben Schwartz: IF we take the full cryptographic approach then this is a
really hard problem. Talking about timing correction things - and it's
not even sure we know how to make assertions for the threat model. And
then, there is client specific rate limiting. The state machine has a
lot of .... My advice would be forget about client targeted request.
Let's focus on advice for relay to leak the least amount of data.

EKR: A little puzzled about the definiton of malicious.

Tiru: If you have an attack pattern in the HTTP request. WAF rules.

EKR: I share DKG's concern about the set. You can use this for
partitioning. One potential avenue to fix this would be to have th
server supply the realy, but then we have other issues to deal with. I
understand others think this is an issue.

Tiru: the server wants to shed load from those requests.

ekr: Just not that concerne about (computational?) attacks.

Chairs: need to work through some of the attacks and issues brought up
before we can consider adoption.

• An Unreliable Oblivious HTTP Extension (Ralph Giles, remote) -
  20 mins
  Slides

Ralph provided motivations for the I-D and the mechansim that supports
their use case.

Ted Hardie: Not very enthusiastic and wearing curmudgeon hat. I think
you are designing an oblivious star service, but how you're doing it
sets my teeth on fire. Using Accept header in a bizare way. If you want
to add an Oblivious Star service but wouldn't want to start here.

Richard Barnes: Can you clarify how it is related to star.

Ralph: I do not think it is and instead applies to many applications.

Tommy Pauly: I agree with Ted that the spelling of HTTP needs more work,
but I am pretty positive about this. I do not personally have a use case
for a response. I can see use cases beyond star; abopt it respell
technical bits. Maybe rename it to remove "unreliable".

ekr: I am less positive for serveral reasons. 1) the motiviation for
being lazy to implement HPKE is not motiviating for me. 2) This just
changes the propoerties of HTTP. To say I just don't want the ack is not
how HTTP works. This has big impacts. 3) The design of the protocol is
by design has no feedback is kinda wrong from protocol design. Needs
more baking time.

Ben Schwartz: What I find interesting is the batching idea for privacy
and efficiency reasons. And not about the efficiency it's about provided
by the relay. Could do this as a header to the proxy, but this would be
interesting to specify. Also interesting to look at it in a high latency
environment.

Andrew S: Besides gagging clients could this be used by gateway to batch
clients?

David Schinazi: Agreeing with lots of people even those how are
disagreeing. HTTPWG might pass out - could we square this? CLient can
fire and forget and there is less encryption on the gateway. Which do
you care about?

Ralph: I care about the gateway.

David Schinazi: Could you just send and empty response? That would
trigger the relay to send something back to the client. might solve
ekr's problem.

Ralph: Not sure it fixes ekr concern because an empty blob would break
the encryption.

Ted Hardie: If there is a use case for this that doesn't require the
oblivious property is to take this to the HTTP WG. If there isn't a use
case for oblivious property you need to add more explaination that just
the threat model change.

Chairs: there seems to be interest in the proposal, but needs working
through mechanism especially the HTTP bits.

• DoubleCheck (Ben Schwartz) - 15 mins
  Slides

Ben provided a summary of changes since IETF 114.

Martin Thomson: I have a suggestion on how we approach these two
questions: Ask privacy pass WG! General approaches should be discussed
there. A little leery of reinterpretting specifications. Don't like the
2nd one.

Tommy Pauly: I like the approach of GET through a forward proxy. All of
the dependcies should just go away. Ben: they are gone. Take it to
privaxy pass and all of this document could go into key consistency I-D.
Quesiton: Abut the chacing bit: What happens if what you get back is not
....

Ben Schwartz: The client is supposed to reject. The attack is that the
gateway can reply to th relay with a key config with a long timer. Then
the gateway acting as a different client cann cause the config to flush
the cahce. Then both have long config. ?

ekr: I found a lst of caveats concerning. Trying to tease a couple of
things appart: detectionn vs enforcement. Second point: say we have a
mismatch - what then? The natural things is to call the NY Times: Need
to be signed by DV certificate?

Richard Barnes: What's about the "and beyond"? There's a lot of
resources that want consistency. Is this a general thing?

Ben Schwartz: This is just about HTTP resource consistency.

Eric Orth: 1) both this and the other info don't work well in either
place; let's go there too. 2) I maintain that this is one reasonable
solution - caveats show it's a complicated problem. Would like to solve
thundering herd problem.

Ben Schwartz: Trying to avoid minting a lot of these solutions.

Chairs: move this to PRIVACYPASS.

Balance of time (10 minutes)