In the RFC Editor queue now. Some difficult DISCUSS topics came up
during that. Thanks to authors and chairs for their forebearance.
About discovery of Gateways.
Tommy has much fancier pictures of the architecture than are in the
draft.
The gateway and target need to be collocated, or at least (so the client
can tell) the same origin.
svcb parameter -> ohttp
.well-known label -> ohttp-gateway
Clarify DoH/DDR behavio[u]r
The gateway location is now /.well-known/ohttp-gateway relative to the
target URI. Uses a single flag (ohttp) in the SVCB record. A GET request
to the gateway will return a key configuration. No key consistency on
display.
DooooOOH ＼（〇_ｏ）／ (Duo) (⊙_◎)
Consistency is the main issue remaining. KCCS for the key from the .wk.
Might do a double-check with a proxy arrangement (CONNECT + OHTTP
perhaps?).
Chris Wood: Friday Privacy pass will involve discussion of KCCS.
Tommy: consistency is right to get the privacy properties we need; is it
enough to point out vaguely to the KCCS draft, with mayb non-normative
language about the considerations; or we could be tighter.
Chris: Maybe we can do the same thing as Privacy Pass did, which is to
avoid specifics here and just outline requirements. We can do something
later. It might take a while to make something that we really want. We
might standardize something more than doublecheck which is pretty
simple.
Tommy: Not happy punting entirely. But maybe we could point at something
concrete in the interim.
Chris: We don't have anything solid in Privacy Pass. That has the same
requirements. We should be consistent.
Ben Schwartz: Agree that the problem is the same as the one in Privacy
Pass. Say the same. But the two are quite different. I don't have a firm
opinion on what to do.
Ben: dohpath consistency is a similar problem. Limiting dohpath to a
default is problematic because it squats on the HTTP namespace.
Tommy: we don't use a .well-known for DoH, but everyone does /dns-query.
Maybe we can list a few things that clients might not need to double
check.
Ben: DoH wanted to use a .well-known, but got told that it was a bad
idea.
Eric Orth: Privacy pass should be where we address this. We should
reference their work. We should recommend a specific thing.
Tommy: If we fix this issue, are we done?
Using ratelimit policy. Policy applies to an entire relay.
Chris: Why do we need this in practice. Cloudflare operates a relay and
hasn't found a need for it.
Tiru: We looked at the target wanting to rate limit all clients, which
might allow a fair distribution of that.
Chris: of those who have deployed relays, would you use this?
Tiru: At my previous employer we wanted to have this.
Chris: Would be good to hear of this.
Richard: The need would be driven by gateways and targets. Question for
relays is whether they would consume this signal. Is that a signal you
could apply.
Chris: The point is that we have not been asked to throttle in any way.
Richard: useful feedback would be from relays or gateways and whether
the signal is needed
Ted Hardie: related question; regarding impact severity. there is no
difference in the document in the reaction depending on the severity and
the information is not forwarded to anyone, so why does the element
exist? Maybe you are doing this to track how often the problems occur,
but if there is no evidence that this correlates with activity, so it
seems like the parameter does not do anything (if even the mechanism as
a whole is needed).
Tiru: People said would like to see the severity levels. Maybe this
could feed into logic about when to throttle. Low severity might not
result in any action, but higher severity might engage limiting.
Ted: Write that down. Risk is that you might change behaviour in the
"high" scenario such that you might degrade privacy protections, which
is not what we want.
Tommy: To Chris' point, we haven't seen a need for this in existing
deployments. In defense of it, those existing deployments are few and
new, where there is trust between relays and gateways. We could explore
more about the types of deployments, particularly if there is a weaker
relationship between relays and gateways or less confidence in the
validation mechanisms used. Attestation in our deployment ensures better
protection; open relays might have a different outcome. Put this in
context of what the relay is doing. Maybe we need to hear more about use
cases, like safe browsing and different scale or different fraud
prevention. If there is an intent to deploy OHTTP, do they anticipate a
need for something like this to enable use of OHTTP.
Tiru: ISPs might look to deploy relays, which is where this might be
helpful. As deployment catches up we will start to see what we might
need.
Chris: Tommy raised a good point. We're very early in deployment.
Perhaps we can sit on this until the need arises. Or maybe until we get
more information about use cases. The current draft doesn't seem to
match with what is deployed in practice. That might change, so maybe we
can wait just a little more.
Alex: Is there anything in the draft about deployment size. Perhaps the
assumption is that the relay is deployed at larger scale than the
target/gateway. That might not hold. Endpoints need to defend themselves
in practice, even if they were going via a relay. The target needs to
have quite substantial serving power. Does the draft provide anything
more than an advisory signal? How would anyone do anything other than
apply a best effort, with the target sinking the attack anyway. How
could this turn into an effective deployment.
Tiru: Targets have firewalls to defend themselves. A loosely coupled
relay might not effectively apply the policy, but more an attempt to
leverage cooperation.
David Schinazi: Conflicted. On one hand it is vague about its
assumptions on deployment, but also it seems a little to specific to
rate limiting. In MASQUE you can have similar problems. A signaling
channel might be useful there too. To Chris' point, we have a contract
with Fastly on OHTTP and we haven't needed it. Future needs might change
and so we can hold it. It might not even be rate limiting at that point.
So again, hold on to this.
Richard: the authors have listened to feedback and there are no
remaining technical blockers, it's more a question about enthusiasm or
demand. propose an adoption call as a way of measuring the enthusiasm
for the mechanism; there will be no implied presumption of adoption, so
I encourage the authors to solicit others to express interest if there
is interest. chairs think that the general shape seems to have support
so if this passes, we'll take that as affirmation
Shivan: early time! thanks all.