►
From YouTube: IETF115-OHAI-20221109-1300
Description
OHAI meeting session at IETF115
2022/11/09 1300
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
Welcome
all
to
ohai,
we
are
your
chairs,
Siobhan
and
Richard,
which
is
joining
remotely,
and
we
have
note
takers,
I,
think
Martin
and
Sean
are
going
to
help.
Thank
you
so
much
I'll.
C
A
The
notes
we'll
do
yeah
already.
This
is
the
note.
Bell
you've
probably
seen
it
by
now,
but
please
do
note
it
well.
It
concerns
the
patent
policy
and
and
as
a
reminder
like
there
is
the
ombuds
team
that
you
should
feel
free
to
reach
out
to
and
also
just
specifically
for
this
meeting.
A
There
is
the
on-site
tool
that
you
should
be
using
that
helps
get
numbers
for
it
kind
of
serves
as
a
blue
sheet,
and
it's
also
really
helpful
if
you
can
use
that
to
join
them,
IQ
so
that
we
can
be
Equitable
towards
people
joining
remotely
as
well
helps
with
Cube
management,
essentially,
and
also,
if
you're
remote,
then
make
sure
that
your
audio
and
video
are
off
unless
you're,
presenting
and
headset
is
always
recommended,
and
as
a
reminder
that,
if
you're
not
speaking,
then
you
you
must
wear
a
mask
and
yeah
I.
A
Think
that's
everything.
So,
just
to
make
sure
everyone
knows,
the
main
protocol
draft
for
obliviously
HTTP
was
submitted
and
it's
in
the
ad
review
stage,
so
that
should
be
hopefully
getting
published
soon.
And
then
we
also
adopted
one
new
draft
since
last
meeting
and
Tommy's
going
to
be
talking
about
that
and
unless
there's
anything
to
be
said
about
the
agenda
going
once
going
twice,
I'll
ask
Tommy
to
present.
C
D
E
Okay,
hello,
everyone
so
I'll
be
presenting
our
Discovery
draft,
and
this
is
about
bootstrapping
the
use
of
an
oblivious
HTTP
Gateway
using
records
that
we
find
in
DNS.
E
This
was
discussed
at
the
last
ITF,
but
as
it's
newly
adopted
I'm
going
to
give
a
brief
recap
of
the
use
case
and
how
the
protocol
looks
before
we
go
into
the
open
issues.
E
Okay,
so
this,
if
you
saw
the
presentation
last
time,
this
should
just
be
a
reminder,
but
if
you
didn't,
the
Discovery
Model
assumes
that
we
have
a
client
that
knows
about
a
Target
service
that
it
wants
to
communicate
with
some
HTTP
service
out
there,
and
the
client
also
knows
about
one
or
more
oblivious
relays
that
it
is
willing
to
work
with,
or
it
has
credentials
for,
or
what
have
you
and
the
target
service
Also
may
have
an
oblivious
Gateway
that
it
works
with
which
can
be
co-located
with
the
target
service.
E
But
essentially,
you
can
think
of
this,
as
the
target
service
is
willing
to
be
accessed
over
oblivious
http,
so
that
clients
that
would
prefer
oblivious
access
to
direct
access
can
use.
It.
E
E
E
E
The
reason
the
protocol
has
this
shape
is
that
we
need
to
make
sure
that
the
discovered
Gateway
and
its
config
are
actually
strictly
bound
to
the
Target,
because
access
to
this
target
through
the
Gateway
is
replacing
any
other
certificate
evaluation.
Other
trust
you
have
in
that
Target,
and
so
you
need
to
prove
that
the
Gateway
has
authority
over
the
target
resource,
and
this
effectively
means
that
you
have
to
co-locate
them,
at
least
in
terms
of
something
that
is
able
to
do.
E
Tls
termination
for
the
Target
and
past
the
normal
client
trust
evaluation.
E
E
The
actual,
well-known
location
is
dot
well
known,
slash,
oblivious,
Gateway
and
the
way
to
get
the
key
configuration
is
to
instead
of
doing
a
post,
you
do
a
get,
and
you
say
that
you
accept
application,
ohtp
keys
and
then
you
get
the
key
config.
E
So
it's
quite
simple:
if
you
have
questions
I
guess
we
could
take
him
now
or
at
the
end,
but
this
is
just
a
recap
and
we
have
a
couple
different,
open
issues
that
I
wanted
to
highlight.
E
So
first
I
think
this
was
from
Ben
was
about
the
parameter
name.
Currently,
it's
named
as
oblivious.
He
was
pointing
out
that
this
that
is
potentially
too
broad.
You
could
have
other
things
that
are
oblivious
in
the
future,
particularly
if
you're,
using
this,
not
on
the
https
resource
record.
F
Hi
so
after
considering
the
the
sort
of
one
of
the
other
open
issues
here,
I
think
that
I
think
let's
park
this
until
we've
solved
some
other
things.
In
particular,
if
we
I
that
oblivious
changes,
the
behavior
of
the
DNS
client,
for
example,
telling
the
DNS
client
to
not
use
DNS
cookies,
then
maybe
we
or,
for
example,
if
it
tells
the
DNS
client,
don't
use
other
transports.
If
they
don't
support
obliviousness,
then
maybe
it
actually
is
a
cross-transport
flag.
F
Maybe
it
is
not
HTTP
specific,
so
I
guess
it's
not
clear
to
me
yet.
E
Okay,
all
right,
so
let's
come
back
to
this
one
then,
and
let's
have
the
other
discussion.
The
comments
in
the
chat
seem
to
be
fine
with
ohtp
in
principle.
So
Ben,
let's
come
back
to
this,
so
the
next
one
was
a
source
of
confusion
and
was
a
problem
of
a
lack
of
clarity
and
a
bit
of
confusion
in
the
document
that
needs
to
be
cleared
up.
The
issue
number
29
was
originally
raised
about
the
media
type
being
used
for
DNS
cases,
so
The
General
the
generic
use
case.
E
The
current
text
has
issues
I
think
based
on
the
discussion
on
the
issue.
The
correct
outcome
is
that
you
know
really
the
media
type
from
the
perspective
of
the
Gateway
and
the
target
are
all
the
same
as
they
would
be
for
http.
E
This
is
the
Gateway
does
not
see
anything
different.
It
just
sees
oh
HTTP,
Rec
and
response.
It
has
binary
HTTP
inside
that
gets
turned
into
an
HTTP
request
to
the
Target.
The
target
itself
is
a
dough
resolver
and
it
just
sees
a
normal
do
request
over
http.
E
That
is
distinct
from
a
theoretical
case
that
you
could
have,
which
would
be
ohttp
wrapping
just
the
raw
DNS
message,
because
technically
you
don't
really
need
the
other
bits
of
the
HTTP
response,
every
request
and
response
that
are
in
bhdp.
It's
just
a
wrapper,
but
that
does
add
media
type
complexity
and
is
no
longer
just
a
generic,
Gateway
and
I
think
we
should
avoid
doing
that.
E
Based
on
that
any
questions
oh
and
the
nice
thing
is,
you
know
we
had
Odo
before,
but
now
technically
this
is
DNS
over
oblivious
HDPE,
so
we
can
call
it
a
Duo
d-o-o-h
anyway.
I'll
stop.
Now
Ben.
F
So,
just
as
a
document
matter,
I
want
to
stress
that
this
is
creating
a
Divergent,
so
I
I
agree
with
Tommy's
choice.
I
fully
support
it
I
wonder
if
we
should
claw
back
the
the
ohttp
draft
and
make
some
changes,
because
right
now,
section
4.6
of
the
ohttp
draft
lays
out
a
sort
of
speculative
design
and
a
couple
of
paragraphs
of
like
here's,
how
you
could
use
ohttp
for
DNS.
But
it's
not
this.
It's
the
other
thing.
E
One
we
could
certainly
remove
I
mean
I.
Can
let
Martin
no
other
speak.
Remove
the
example.
I
think
you
definitely
you
can
have
other
things
other
than
bhtp
inside
and
I.
Think,
though,
oh
the
main
ohtp
document
is
correct
in
its
advice
of
what
to
do.
If
you
do
that,
but
I
don't
think
we
need
to
do
it
here.
E
G
I
feel
like
so
this
means,
if
I'm
sort
of
riding
a
doe
server
I'll,
have
to
support
kind
of
door
over
H2,
the
whole
Rage
3
and
then
dough
over
hdp,
and
then
there's
the
Adaptive
DNS
draft.
That
is
a
different
encoding
right
that
is
odor.
E
Yeah
so
right,
oh
Odo
is
its
own
thing.
I
I
think.
Actually,
this
this
approach
makes
it
simpler
for
implementation.
Even
though,
technically
you
have
a
little
bit
of
extra
packaging,
because
you
can
run
a
completely
unmodified
H2
doe
server
as
the
target
service,
and
then
you
have
in
front
of
it
an
ohtp
Gateway
that
receives
the
ohttp
request
encrypted
decrypts.
It
gets
the
binary
HTTP
and
translates
that
into
a
request
to
the
unmodified
H2
doe
server.
E
Now
these
are
co-located,
so
you're
doing
decapsulation
Etc
in
you
know
two
things
right
next
to
each
other,
but
it
allows
you
to
have
unmodified
doe
server
code.
If
you
have
the
DNS
message
directly
within
the
ohttp
encapsulation,
then
that
effectively
is
meaning.
You
have
a
doe
server
that
has
to
directly
speak
the
oblivious
HTTP
request,
so
that
is
potentially
more
work.
E
E
H
I
Thanks
Sean
for
doing
the
note-taking,
Martin
Thompson
I'm,
not
really
sure
what
sort
of
thing
we're
talking
about
here,
because
you
can
do
all
of
these
things.
We
probably
should
choose
one
though
and
I
think
for
anyone
doing,
oblivious
dough.
Then
this
makes
a
whole
lot
of
sense.
I
think
this
is
the
natural
wrapping.
What's
on
the
slide
is
what
what
is
the
natural
wrapping
for
that
sort
of
thing?
I
You
have
an
oblivious
HTTP
Gateway,
that's
just
a
an
oblivious
HTTP
Gateway,
you
have
a
doe
Target
and
the
two
could
be
independently
implemented
and
everything
will
be
fine,
I
think
there's.
There
is
a
separate
design
that
says
that
you've
got
an
oblivious,
dough,
I
I,
believe
it's
DNS,
which
looks
very
much
different
to
this.
Potentially
has
a
different
rapper
potentially
has
a
different
thing
on
the
inside,
but
that
we
don't
need
to
Define
that
here.
E
Exactly
that's
what
I'm
saying
as
well
and
really
the
only
thing
that's
relevant
for
this
document
is
saying
when
you
receive
the
oblivious
or
whatever
we're
going
to
call
it
parameter
over
an
svcb
record
for
a
resolver.
E
Okay,
so
that
is
that
one
I
think
it
sounds
like
people
are
okay
with
re-clarifying.
The
document
to
just
mean
this,
because
it's
a
natural
thing
to
do.
E
The
one
last
issue
I
was
going
to
bring
up
was
specifically
again
around
the
DNS
case.
If
you're
getting
this
from
DDR,
which
is
the
thing
defined
in
the
add
working
group
where
you
have
learned
about
your
resolver
from
a
special
use
domain
name,
dns.resolve.arpa,.
E
In
that
case,
in
order
to
trust
the
resolver,
you
need
to
validate
the
IP
address
in
the
Target
certificate
and
the
text
currently
in
this
document
says
you
know
if
you
were
doing
the
oblivious
dance
to
get
that
Target,
then
either
before
you're
doing
things
obliviously.
You
need
to
just
directly
connect
to
that
Target
and
validate
a
certificate,
or
you
create
some
separate
proxied
connection
through
a
connect
proxy
or
whatever.
You
can
still
validate
the
target
certificate,
and
if
you
have
validated
the
target
certificate,
then
you
can
go
ahead
and
do
the
oblivious
requests.
E
I
Yeah
mountains
again,
I
think
this
is
probably
something
we
can
leave
for
the
DDR
draft,
in
the
sense
that
you
have
a
reference
identity
that
you're
using
to
authenticate
the
server
that
reference
identity
may
be
different
to
the
thing
you
put
in
DNS
to
query
it,
but
you
still
have
reference
identity
and
all
of
those
rules
apply
on
the
DDR
side
of
things
as
much
as
they
apply
here.
Maybe
a
note,
but
I
wouldn't
put
any
normative
language
around
it.
E
Okay,
so
that
those
are
the
main
issues
we
have
I
guess
going
back
to
the
naming.
Now
that
we've
talked
about
this
Ben
did
you
want
to.
E
F
The
the
question
I
I
ran
into
was,
on
the
one
hand,
so
in
the
DNS
record
you
run
into
this
thing.
It
says:
oblivious.
F
F
Does
the
oblivious
instruction
also
apply
to
DNS
over
quick
in
pursuit
of
some
future
specification
for
oblivious
DNS
over
quick,
which
doesn't
exist
right
now,
or
is
it
only
for
for
use
with
oblivious
HTTP?
So,
like
maybe
one
answer
so
one
answer
is
it
only
applies
to
oblivious
HTTP.
F
Your
options
are
DNS
over
quick
and
there's
DNS
over
HTTP
or
an
oblivious
DNS
over
http
so
forth.
Another
option
is
to
say
it
actually
applies
to
the
whole
record,
and
so
what
we
expect
the
client
to
do
is
speak
obliviously
to
any
of
these
endpoints
and
and
if
it
doesn't
know
how
to
do
that,
then
it
shouldn't
use
transports
if
it.
Basically,
if
it
supports
oblivious
communication
over
some
of
these
transports,
but
not
others,
then
it
should
probably
only
use
the
transports
that
it
can
speak
to
obliviously.
F
G
That
I,
oh,
so
that
that's
not
how
DNS
works!
You
have
resource
records,
so
that
means
in
every
research
record
you
have
a
kind
of
oblivious
or
yes
or
no.
So
if
you
have
a
quick
record-
and
this
would
be
an
additional
resource
record.
F
The
the
service
B
DNS
binding
uses
a
single
resource
record
to
represent
HTTP
TLS,
quick,
etc.
Those
are
all
wrapped
in
no.
G
F
Optional
but
you
can
form
a
single
service,
binding
record,
which
says:
alpn
equals
H2
H3
doqdot.
E
Yeah
I,
don't
think
you
should
just
to
respond
to
event,
I
think
your
original
issue
and
your
suggestion
was
correct.
I
think
it
based
on
this
really
needs
to
be
ohdp,
because
otherwise
we
do
not
know
what
that
future
thing
is
or
what
it
would
need
in
a
parameter.
So
the
presence
of
this
means
you
can
access
this
over
normal,
vanilla,
ohttp
with
a
normal
Gateway
doing
binary
HTTP
in
it,
and
that
is
all
it
means.
If
you
have
some
other
protocol,
it
gets
a
new
marker,
and
that
is
not
done
here.
C
Which
is
Richard
Burns
is
an
individual
and
I
was
exactly
what
I
was
going
to
say
here
like
to
just
like
off
fortiori,
like
we
don't
you
know
you,
we
don't
want
to
bundle
all
these
protocols
together
because
you
don't
know
who
they
are
and
because
this
is
providing
the
contact
point,
we
don't
want
to
force
all
of
those
things
to
be
implemented
on
the
same
contact
Point
so
like
yeah.
Definitely,
let's
keep
these
things
separate.
B
How
about
this?
That
should
be
better,
so
I
I
agree
with
the
prior
speakers
in
part,
because
it
was
very
confusing
for
me
to
hear
you
can
do
DNS,
obliviously
I,
don't
even
know
that
we
know
what
you
can
do.
Dns
obliviously
means
as
a
client
the
client's,
not
oblivious
right,
the
it's
the
the
point
of
oblivious.
B
These
oblivious
protocols
is
to
keep
the
intermediaries
and
the
and
the
server
oblivious
about
what's
happening,
and
so
the
client
needs
to
know
what
what
kind
of
state
it
needs
to
trim
to
reject
all
of
that
stuff
and
I.
Don't
think
we
actually
have
answers
for
that
at
the
different
levels,
so
yeah,
so
so.
Ohtp.
E
Yeah
yeah.
J
I
I
concur
with
what
everybody's
just
been
saying:
I
mean
the
the
specification
is
two
things:
it
is
an
encapsulation
format
for
talking
to
to
the
terminal,
Target
HTTP
server,
and
it
is
a
set
of
indicators
that
you
provide
to
the
Gateway
and
like
in
the
in
the
end,
and
so
if,
in
order
to
provide
this
functionality
for
some
other
hypothetical
protocol
like
DNS,
you
would
then
need
an
encapsulation
format
that
is
used
to
talk
to
talk
to
those
those
systems
and
things
and
in
the
cases
of
you
know
in
the
in
in
the
most
likely
that
is
like
called
TLS
or
called
quick,
and
so
like.
J
It's
not
like
understandable,
like
that's
just
like
completely
asking
for
this
working
group,
so
like
so
really
specify
the
HTTP
thing
and
and
leave
other
things
other
people,
and
in
particular,
like
you
know,
just
to
like
harp
on
this
a
little
bit.
If
you
were
to
say
if
what
you
wanted
was
to
provide
like
a
like
a
conceptually
similar
service
to
this
that
did
DNS
but
was
like
the
military
they
were
tunneling.
The
name
of
the
Gateway
is
called
mask.
J
E
I
think
that
is
all
of
the
issues,
so
on
authors
and
I
think
we
have
enough
to
rev
the
document
and
take
it
from
there.
A
All
right
we're
doing
really
well
on
time.
Tiru.
Are
you
going
to
present
the
oblivious
relay
feedback.
K
Hello,
everyone
good
afternoon,
I'm
thiru
I'll,
be
presenting
updates
to
the
obvious
relay
feedback
draft.
This
was
presented
in
the
last
idea
of
when
we
had
received
some
good
feedback
and
we
updated
the
draft
to
address
those
feedback
next
slide.
Please.
K
Yeah
next
slide
yeah,
just
a
quick
recap
for
those
who
haven't
read
this
draft.
This
is
primarily
written
for
the
case
that
was
often
rate
limit
incoming
requests
for
various
reasons.
K
If
the
server
rate
limits
the
relay,
then
it
would
harm
all
the
clients
using
that
way
and
that's
the
problem
we
are
trying
to
solve
with
this
draft
next
slide.
Please
so.
A
K
K
Clients
the
feedback
we
had
received
from
the
working
group
was
to
use
the
work
happening
in
HTTP
API
working
group
and
be
co-authored
with
the
author
of
that
draft,
and
he
helped
us
update
it
to
use
the
service
parameters,
that's
being
defined
in
that
right.
Limit
headers
next
slide
yeah.
So
that's
the
change
that
we're
bringing
in
to
update
the
right
limit
policy
to
have
a
new
parameter
to
Signal
the
rate
limit
to
the
relay
next
slide.
K
So
this
was
all
there
in
the
previous
version,
so
that
was
just
a
quick
recap.
So
what
the
draft
does
is
it?
It
sends
two
values,
one
value
to
integrate
to
the
relay,
to
rate
limit
all
the
clients
and
the
second
value
was
breaking
beta
finding
clients.
The
big
comment
that
we
received
from
the
working
group
was:
can
that
be
abused
by
the
Target
if
the
relay
starts
rate
limiting
clients
so
that
it
would
help
the
target
to
De
anonymize
these
clients?
K
So
we
updated
the
draft
to
address
these
comments
next
slide
yeah.
So
if,
if
in
case,
the
rate
limit
is
for
a
client
which
is
probably
sending
some
malicious
request
which
the
target
has
identified,
then
what
are
the
prerequisites
for
the
relative
even
start
rate
limiting
so
the
first,
the
first
two
prerequisites
have
to
be
that
it
has
to
be
serving
a
large
number
of
clients
sending
large
volume
of
requests.
K
Otherwise,
it's
going
to
ignore
that
it
needs
to
have
a
very
large
number
of
benign
clients
for
which
it
is
not
doing
any
rate
limiting
versus
the
number
of
clients
for
which
it
has
to
do
the
rate
limiting
the
third
rule.
Is
that
really
does
not
immediately
rate
limit
the
offending
client?
So
what
it
does
is
it
basically
starts
watching
how
many
requests
from
the
client
are
indeed
malicious
for
which
the
value
2
was
provided
versus
the
request
for
which
there
was
no
value
provided,
for
instance,
some
important.
K
It
is
sending
a
large
volume
of
malicious
request.
The
idea
behind
that
rule
was
malform.
Request
typically
has
some
pattern,
which
is
matched
by
let's
say
a
web
application
firewall,
whereas
valid
HTTP
request
should
not
be
linkable
in
case.
If
you
want
the
Privacy
protection
for
obvious
HTTP,
so
that
way,
the
target
will
not
be
able
to
partition
the
anonymity
set
of
legitimate
clients.
K
So
that
was
the
idea
that
we
enhanced
this
specific
section
to
handle
the
big
issue
that
was
raised
with
regard
to
Red
limit
being
abused
by
the
Target
for
malicious
purposes.
K
Next
slide,
please
even
in
case
where
I
think
Ben
raised
this
comment,
that
a
rate
limiting
field
for
all
the
clients
could
also
be
misused
in
case
if,
for
instance,
there
are
very
low
volume
of
clients
sending
requests
once
in
a
while.
So
we
have
set
email
prerequisites
for
that
that,
after
the
rate
limiting
there
has
to
be
a
good
enough.
K
High
volume
of
messages
from
a
large
volume
of
clients
and
dividing
the
rate
limit
fairly
among
the
active
clients
could
create
a
timing
pattern
of
requests
that
could
possibly
be
strongly
correlated
by
the
Target
to
the
anonymous
clients.
So
we're
just
relying
on
the
mitigation
technique.
That's
already
defined
in
the
obvious
https,
which
discusses
delaying
requests
to
increase
the
nonhead
we
set
into
which
in
which
the
requests
are
attributed
to.
K
So
that
should
that
we
think
should,
with
the
previous
one
and
previously
two,
we
believe
that
should
address
the
side
effects
of
rate
limiting
all
the
clients
next
slide.
B
I'm
not
sure
that
I
understand
your
argument
about
about
how
this
preserves
the
anonymity
for
the
clients.
I
I,
understand
that
you,
it
doesn't
permit
the
Target
to
fully
partition
the
state
space
of
all
users,
but
it
seems
to
me
like
what
you're
saying
is
it's
okay,
if
the
anonymity
or
the
or
the
is
able
to
partition
a
small
percentage
of
the
users
is.
That
is
that
is
that
the
mitigation
that
you're
proposing
here.
L
B
But
if
there's
a
large
number
of
clients,
then
the
relay
and
the
relay
receives
this
feedback.
That
says
this
is
the
particular.
You
know
block
further
request
from
this
client
and
the
relay
acts
on
that
behavior
acts
on
that
request.
They
can
still
you
know
that
allows
the
identification
of
those
specific
that
specific
user
right.
K
No,
it
does
not
because
the
if
you
go
back
to
the
previous
slides,
where
we
were
discussing
the
the
previous
slide
yeah,
we
really
does
not
immediately
act
on
a
request
from
the
target
it
starts
noticing
how
many
requests
are
getting
these
kind
of
malicious
requests.
So,
for
instance,
if
let's
say
there
are
100
requests
coming
from
the
client
and
there
are
like
99
requests,
which
are
being
said-
that
they
are
malicious
and
there's
just
one
legitimate
request,
which
is
one
then
then
I
and
it
meets
the
other
criteria.
K
B
This
doesn't
sound
like
it
has
the
guarantees
that
I
would
want
as
a
client
to
use
this,
but
but
maybe
I'm,
misunderstanding
I'll.
Let
next
books
in
the
keyboard.
F
Hi,
so
in
general,
I
think
that
this
is,
if
we
take
the
full
sort
of
cryptographic,
seriousness
approach
of
like
you
know,
there
shall
not
be
any
leakage
or,
like
all
leakage,
shall
be
Quantified
and
understood
exactly,
but
this
is
a
really
hard
problem.
This
is
like,
because
the
timing
we're
talking
about
like
timing,
correlation
things
that
depend
on
you
like
what
actual
clients
timing
behaviors
were-
and
it's
not
even
really
clear
to
me
how
to
formulate
it
like
what
are
the
assumptions
that
we're
making
that?
F
How
much
does
our
threat
model
cover,
for
example,
clients
who
are?
Whose
timing
is
supposed
to
be
uncorrelated?
You
know
that
they're
issuing
requests
randomly,
but
their
timing
becomes
correlated
because
of
a
rate
limit
applied
to
them
by
the
relay
I.
Think
that
so,
like
even
the
threat
modeling,
it
seems
non-trivial
here
and
then
this,
like
client-specific
targeted
rate,
limiting,
is
even
harder
to
understand.
F
It's
not
clear
to
me
that
this
state
machine
has
a
bunch
of
mitigations
in
it
which,
which
actually
are
so
strong
that
I'm
not
sure
that
it
actually
works
as
a
defense
anymore,
like
a
malicious
client,
can
just
send
a
lot
of
requests
for
a
slash
like
a
lot
of
really
boring
requests
along
with
whatever
it's
malicious
requests
are,
and
now
the
relay
looks
at
the
percentage
of
malicious,
flagged
requests,
and
that
percentage
is
not
high
enough,
so
it
doesn't
apply
any
rate
limit.
F
Let's
just
try
an
informational
draft
on
the
question
of
like
good
practices
for
a
relay
to
to
implement
rate,
limiting
which,
by
the
way,
doesn't
even
have
to
be
explicit,
even
if
you
don't
have
an
explicit
rate
limit
from
the
Gateway
at
some
point,
you're
still
going
to
have
to
turn
away
some
fraction
of
requests,
and
so
I
think
there's
some
some
interesting
questions
about
what
are
the
best
ways
to
do
that
that
leak,
the
least
amount
of
information.
How
do
we
model
that
problem.
J
D
J
I'm
sure
tkg
is
concerned
about
the
anonymity
set.
There's
no
way
for
the
as
far
as
I
can
tell
there's
no
way
for
the
Relay
to
verify
that
these
are
malicious
and
not
just
cleaning
wishes,
and
it
seems
quite
clear
you
can
use
you
say
you
can't
be
used
for
partitioning,
but
of
course
it
can
because
I
just
like
so
so
I
I
believe,
like
I,
see
a
set
of
requests.
J
That
I
think
are
all
from
one
person
and
I,
don't
know
for
sure,
but
they
seem
to
be
correlated,
and
so
what
I
do
is
I
fly
them
all
as
malicious
and
then
I
see.
If
that
to
see
if
it
throttles
back
and
if
it
does,
then
then
I
verify
the
guesses
for
one
person
and
since
you
have
no
way
you're
going
to
find
them
malicious
that
doesn't
work.
So
I
think
if
you
want
I,
think
so.
I
think,
like
I'm,
also
concerned
about
the
ability
to
actually
demonstrate
this
is
safe.
J
I
think
you
know,
one
potential
Avenue
would
be
to
would
would
be
to
have
the
the
server
the
server
Supply
the
key
to
the
relay.
So
they
really
could
verify
for
themselves.
They're
malicious,
of
course,
now
we're
in
key
committing
I'll
just
say
that
right
now,
but
like
I,
just
don't
understand,
I,
don't
think
it's
gonna
work
to
make
the
servers
more,
that
things
are
malicious
for
the
reason.
I
just
indicators,
okay
and
I,
I
guess,
I,
understand
people
think
it's
a
problem.
J
J
J
K
Yeah,
it's
it's
just
trying
to
save
its
resources
from
processing
those
bad
reviews.
Yeah.
C
All
right
so
we're
at
time
on
this
slot.
Thanks
for
the
presentation
too,
it
sounds
like
we
need
maybe
a
little
bit
more
clarity
on
the
threat
model
here
before
we.
We
move
ahead,
so
yeah
I
think
we're
going
to
take
that.
Take
that
back
to
the
list
thanks.
C
All
right
checking
the
agenda
here
looks
like
next
up
is
Ralph
Giles,
presenting
remotely
on
unreliable
ohttp
extensions,
Ralph.
M
M
A
client
that
wants
to
send
stuff
to
a
Target
and
without
them
learning
too
much
about
each
other.
So
there's
a
relay
service.
The
client
encrypts,
the
data
for
using
the
gateways
key,
send
it
to
the
relay
the
relay
forwards
it
to
the
Gateway
stripping
the
IP
address,
so
everybody
doesn't
learn.
What's
in
the
client's
request,
the
Gateway
doesn't
learn
what
the
client's
IP
address
is
and.
H
M
M
Okay,
simple
enough,
so
for
we
have
an
application
where
we're
using
the
star
protocol,
which
is
there's
been
some
interest
in
over
in
the
Privacy
surveying
measurement
group,
to
do
Telemetry
submission
like
things
about
it
or
things
that
applications
are
doing,
they
want
to
submit
it
to
some
server
and
the
way
this
works
right
now
is
the
client
constructs.
The
message
sends
it
to
a
web
endpoint
and
rather
than
the
web
endpoint
doing,
processing
directly
or
speed
and
simplicity.
M
We
just
shove
it
into
a
queue
and
then
there's
a
batch
job
that
runs
on
separate
with
separate
missions
elsewhere
that
pulls
the
log
down
out
of
band
and
analyzes
it
in
a
batch,
and
so
this
simplifies
the
infrastructure.
The
endpoint
can
be
really
fast.
All
it
has
to
do
is
append
to
a
log
and
because
we're
doing
sort
of
aggregation
of
the
data.
M
It's
not
helpful
to
look
at
the
data
individually,
but
we
can
look
at
the
IP
address
if
it's
coming
from
the
clients
who
can
associate
the
eventual
things
that
we
process
with
the
client's
IP
address.
So
we
could
build
a
profile
of
individual
visual
clients
from
what
they
send.
So
that's
not
as
privacy,
preserving
as
you'd
like.
I
M
Address
we
just
start
to
relay
which
talks
to
a
Gateway
which
talks
to
the
endpoint,
but
now
we
need
two
new
services,
and
since
we
already
have
this
custom
thing,
that's
listening
to
for
the
endpoint,
maybe
we
can
just
teach
the
battle,
oblivious
HTTP
and
combine
the
Gateway
in
the
endpoint.
So
the
relay
talks
to
the
endpoint,
which
then
stuff
thing
is
into
the
log.
M
So
one
less
service
we
have
to
run
and
then
the
log
could
be
processed
out
of
band
later
so
that
works,
sort
of
the
same
as
before
we
just
added
the
single
service
we
have
to
put
in
to
handle
the
relay,
but
teaching
the
endpoint
about
oblivious
HTTP
complicates
the
code.
A
lot
I
mean
remember,
it's
supposed
to
be
really
simple:
it
just
takes
bodies
from
like
Jason
bodies,
that's
been
submitted
by
the
client
and
it
shoves
them
in
a
log
file.
So
now
we
have
to
implement
oblivious
HTTP.
We
have
to
do
so.
M
We
can
do
the
request
and
response
serialization.
We
need
to
provision
keys
for
it,
and
so
it's
a
fair
amount
of
extra
code
and
security
service.
We
need
to
audit
and
the
endpoint
was
supposed
to
be
simple,
so
the
inside
I
had
think
about
thinking
about.
This
is
the
only
reason
we
need
I
believe
it's
HTTP,
parsing
and
hpac
encoding
and
all
that
sort
of
stuff,
and
so
we
can
return
a
200
okay,
because
this
is
just
a
submission
service.
We,
the
client,
sends
data,
it's
a
report
or
something
it's
done,
and
it
doesn't.
M
The
server
doesn't
ever
actually
return
any
data.
It's
just
yes,
I
got
your
response
and
because
we're
doing
our
aggregation
processing
offline
in
a
batch
job,
we
don't
even
validate
the
message
content.
So
the
client
is
sending
nonsense.
We
don't
find
out
in
time
to
tell
them
you
send
nonsense,
so
there's
actually
no
real
value
to
encoding
the
empty
body
with
the
200,
okay,
Response
Code
with
oblivious
HTTP,
but
that's
what
the
spec
requires.
M
So
to
address
this.
We
Chris,
Wood
and
I
wrote
a
draft
for
unreliable
delivery
is
what
we're
calling
it,
which
is
just
an
extension
that
says
instead
of
requiring
that
the
Gateway
return
an
encrypted
response
to
the
relay
which
is
sent
back
to
the
client.
What?
If
you
were
just
able
to
say,
202
accept
and
return
an
empty
body,
and
that
way
the
Gateway
doesn't
actually
have
to
understand
anything
about
oblivious
HTTP
other
than
this
is
what
you
respond
with.
M
So
it's
two
lines
of
code
instead
of
500
or
whatever
it
takes
to
implement,
oblivious
http.
So
simple
enough,
the
client
could
opt
in
by
setting
certain
headers
what
we
suggested
except
and
then
a
message.
Oh
HTTP
acknowledgment
message
type
so
signal.
M
That's
okay,
with
this
Martin
Thompson
suggested,
maybe
we
could
use
the
prefer
respond
to
async
header,
which
has
a
bunch
of
stuff
you
can
attach
to
it
to
say
how
long
you're
willing
to
wait
for
an
answer,
and
things
like
that
also,
given
that
the
in
at
least
in
our
application,
the
Gateway
will
probably
only
support
this
method.
Probably
it
should
be
possible
for
the
out-of-band
configuration
that
tells
the
relay
how
to
talk
to
the
Gateway
could
also
say.
M
We
only
accept
this,
so
the
Relay
can
reject
traffic
right
away
that
doesn't
that
tries
to
do
something
else,
so
it
seems
to
be.
There
are
some
advantages
to
this
like
it
makes
it
easier
to
secure
the
Gateway
code,
because
you
don't
have
to
do
code,
you
don't
have
to
do
key
provisioning
and
it's
just
much
simpler
code.
It
gives
you
more
ways
of
deploying
oblivious
HTTP
within
different
Frameworks
and
another
nice
Advantage.
M
Is
that
because
you
don't
have
to
deliver
right
away
because
the
Gateway
and
and
the
Relay
can
just
respond,
200
accepted
right
away
and
then
buffer
the
message
by
H
delivered
later?
That
gives
you
a
much
larger
window
when
you
can
Shuffle
the
data,
send
it
in
a
different
order,
and
that
helps
defeat
traffic
analysis,
where
you
try
and
figure
out
which
clients
and
which
message
based
on
when
it
was
sent.
On
the
other
hand,
there's.
B
M
Config
to
worry
about-
and
the
relay
at
least
has
to
be
configured
to
accept
this
and
not
reject
it
as
a
not
valid,
oblivious
HTTP,
and
it's
not
suitable
for
a
lot
of
applications,
because
you
don't
get
any
acknowledgment
other
than
the
relay
hurt.
You
there's
no
way
to
re-transmit.
If
the
transmission
fails,
there's
no
way
to
transfer
State
and.
A
M
Is
so
that
was
our
motivation
and
so
I
was
just
curious.
If
is
there
interest
in
the
working
group
in
addressing
this
as
a
use
case?
What
do
you
think
of
the
draft?
Are
there
any
technical
improvements
you
could
suggest,
because
it
seems
like
there's
lots
of
ways.
We
could
do
this
and
it's
unclear
how
it
interacts
with
other
things
like
service
discovery.
L
L
So,
looking
through
the
draft
and
and
following
through
to
the
distributed
secret
sharing
for
private
threshold,
aggregation
I
get
why
you
would
want
a
an
oblivious
star
service
but
I
think
what
you're
doing
to
try
and
get
there
sets
my
teeth
on
edge,
there's
a
whole
bunch
of
stuff
in
in
your
draft
in
the
way
you're
using
HTTP
that
just
kind
of
hurts.
L
So
an
example
of
this
is
is
202
in
general.
For
my
experience
is
a
a
final
server's
answer:
hey
we've
accepted
this,
but
we
haven't
processed
it
you're,
using
it
in
a
relay
in
a
way
that
I,
don't
think
actually
matches
what
people
in
the
web
world
are
going
to
necessarily
expect,
and
in
your
description
of
how
you
signal
this
you're
using
you
know,
accept
headers
in
a
way
that
that
really
are
bizarre
to
me
in
particular,
using
accept
headers,
where
star
dot
star
means
that
you
might
use
this.
L
Just
it's
bizarre,
I
I
think
the
the
basic
idea
here
that
you
want
an
oblivious
star
service,
well
good,
go
ahead.
I!
Just
don't
think
that
trying
to
make
the
oblivious
HTTP
become
the
star
service.
By
throwing
in
these
these
message,
headers
and
and
reusing
202.
The
the
way
you're
doing
it
is
is
fine.
So
if
you
think
what
you
want,
this
working
group
to
consider
is
adding
a
a
deliverable
for
for
an
oblivious
star
service.
L
C
I'm,
just
going
to
inject
myself
here
real
quick
with
a
clarifying
question,
could
you
clarify
to
what
degree
this
draft
is
specific
to
Star
and
to
what
degree
it's
kind
of
generically
providing
a
service
where
there's
no
response
needed?
It's
just
a
submission.
Endpoint.
M
I
think
of
it
as
as
completely
orthogonal
to
Star
I
mean
the
way
star.
Works
means
that
we
have
this
particular
architecture
where
we
have
to
submit
things,
and
we
don't
care
about
writing
back
because
we're
relying
on
the
crypto
to
make
sure
that's
Anonymous,
except
for
the
IP
address,
but
it
seems
like
you,
wouldn't
have
any
example
where
you
have
this
sort
of
simple
input
thing
where
you
want.
You
don't
want
to
have
to
generate
the
keys.
You
don't
want
to
have
to
have
a
key
so
that
you
can
just
respond.
M
D
E
E
I,
don't
personally,
like
the
use
cases.
I've
had
for
oblivious
HTTP
have
wanted
responses
so
far,
but
metrics
collection
and
others
can
definitely
use
this
I
think
it
is
applicable
to
more
than
star
and
so
I
think
it
fits
within
this
working
group,
so
I
think
we
should
adopt
it.
I
think
we
should
adopt
it
with
this
document,
acknowledging
that
the
details
can
be
respelled,
I
I.
Imagine
you
and
Chris
are
not
particularly
wed
to
I'm.
E
The
one
suggestion
I
would
make
is
maybe
renaming
it
saying
unreliable.
Every
time,
I
hear
it
I
have
to
remember
what
it
is
again.
So
maybe
something
like
no
response
submission
only
one
way:
ohtp
something
like
that.
J
Yeah
I
I,
guess
I'm
less
positive
about
this,
so
I
think
for
several
reasons.
So
first
I
think
like
like
the
the
sort
of
like
the
motivation
for
this
of,
like
you
know,
I'm
gonna
Implement,
like
a
secret
sharing
protocol
just
polynomials,
but
I'm
too
lazy
to
do
hpka
like
I
just
like
does
not
motivate
me
at
all.
Like.
M
It's
not
lazy
stuff,
it's
about
protecting
the
but
simplifying
the
implementation.
So
there's
less
Security
Service,
like
the
endpoint
that's
doing
the
HTTP
hpac
is-
has
to
be
open
to
the
internet,
whereas
the
thing
that
actually
does
the
decoding
in
our
proposal
is
it's
not
by
log
server.
J
J
Improvement
I
just
don't
buy
the
all
right
so
but
I
mean
but
I
think
but
they're
more
like
relatively
like
this
just
changes,
the
entire
properties,
lectures
of
this
system
of
HTTP
in
general,
where
HTTP
is
a
protocol
where
you
send
a
message
and
get
a
response,
and
that
response
says
things,
and
maybe
it
just
says
thanks,
but
it
says
something
and
so
to
say:
well,
no
I
just
don't
want
the
ACT,
that's
not
the
way
designed
to
work
and,
and
so
it's
like
and
and
you
can
and
you
can
see,
it
actually
has
a
significant
impact
on
the
threat
model,
which
is
you
taking
a
system
which
had
an
end
threat
model
for
delivery,
and
now
has
it
in
the
middle
front,
mobile
for
delivery.
J
And
so,
if
the
you
know,
if
the,
if
the,
if,
for
instance,
the
proxy
decides
that
it
simply
wants
to
like
gag
some
set
of
clients,
because
if
we
do
something
so
that's
the
reason.
Two
reason
three
is
that
the
designing
a
protocol
that
is
like
by
Design?
J
You
know
one
way
like
this,
where
the
client
gets
no
feedback
whatsoever.
When
something
is
wrong
is
like
I
understand,
you
don't
want
to
do
the
VSS
checking
in
line,
but
like
format,
checking
like
lots
of
things
can
go
wrong
and
to
have
a
design
that
basically,
is
like
the
client
should
kind
of
blind
these
10
things
to
the
server
and
not
care
if
they
cannot
care
if
they're
valid,
like
that
seems
like
fundamentally
incorrect
critical
design.
J
Even
if
you
know
all
these
topics
so
I'm
like
less
positive
about
this
workout,
yes,
I
I,
don't
think
it
needs
more
break
time.
At
least.
F
Hi
Ben,
Schwartz
I
think
the
the
thing
that
I
find
interesting
here
and
and
compelling
is
really
the
batching
idea,
the
delay
in
batching,
for
privacy
and
for
efficiency
reasons,
I,
don't
really
see
a
security
benefit,
and
it's
not
about
the
efficiency
of
the
of
the
Gateway
or
Target,
really
they
can
always
batch
and
buffer
on
their
end.
If
they
want
it's
really
about
efficiency
and
privacy
provided
by
the
relays,
this
I
view
as
an
increase
in
the
Privacy
that
that
can
be
offered
in
oblivious
HTTP.
F
In
some
cases
you
know,
I
I
think
that
the
points
that
have
been
raised
here
are
definitely
valid.
This
is,
in
a
sense,
a
very
deep
HTTP
level
change
and
you
could
imagine
spelling
it
as
like
a
header
to
the
proxy
that
says
you
know,
I
don't
need
a
response
that
has
otherwise,
in
a
sense
nothing
to
do
with
with
the
rest
of
oblivious
http.
F
It
could
apply
to
any
HTTP
request
proxy.
So
but
I
do
think.
That's
a
very
interesting
thing
to
be
able
to
specify
I
think
you
know
to
some
of
ecker's
points.
F
It
would
also
be
really
interesting
to
take
this
in
in
really
a
like
high
latency
messaging
Direction,
where
you
sort
of
treat
this
as
as
like
oblivious
SMTP
like
this
is
because
this
really
looks
like
a
an
email
mixed
net,
and
in
that
case
you
actually
can
get
a
response,
it's
at
very
high
latency,
and
that
high
latency
response
can
be
useful
for
things
like
detecting
misconfigurations
or
confirming
that
you're
not
subject
to
a
long
running
attack.
C
D
Which
is
like,
besides
gagging
clients,
I
wondered
if
this
gives
a
method
for
the
Relay
to
identify
clients
by
batching
in
certain
ways
to
indicate
properties
about
the
clients,
or
you
know,
there's
funky
things,
I
think
you
could
do
and
I
I
don't
know.
That's
like
an
addition
to
the
threat
model.
Here,
that's
something
to
consider
thanks
great.
N
David
scanazi
HTTP
Enthusiast
I'm
find
myself
agreeing
with
a
lot
of
people,
including
people
who
are
strongly
disagreeing
here.
So
on
one
hand,
I
I
see
why
this
is
useful.
I
can
kind
of
buy
that
like
in
some
submission
case,
you
want
to
simplify
things,
but
I
also
see
that
like
when
this
goes
in
front
of.
As
you
know,
it
would
because
it
the
way,
an
impacts,
HTTP
semantics.
We
would
tell
the
HTTP
about
them
and
they
would
like
probably
pass
out.
N
How
do
we
square
that
and
I
was
thinking
about
it,
so
you
have
two
benefits
from
doing
this.
One
is
that
the
client
can
far
and
forget
quicker,
and
the
other
is
the
less
cryptography
on
the
an
encryption
on
the
gate
weight
if
I'm
getting
the
terminology
right,
which
one
of
those
do
you
care
about,
is
it
both
or
a
single
one.
M
N
My
case
yeah
all
right.
No,
no
that
makes
sense
in
that
case,
would
it
make
sense
for
you
to
keep
HTTP
the
way
it
is
and
just
send
an
empty
response
because,
like
you
know,
HTTP,
we
already
have
a
flow
for
errors
where
you
can
say
like
no
I'm
not
going
to
give
you
an
encrypted
response,
because,
like
I've
forgotten
the
keys
or
something
and
you
could
add
a
response
that
is
like
yup
A-Okay
I'm,
just
not
sending
you
a
response,
so
the
and
then
that
triggers
the
relay
to
say.
N
Oh
A-Okay,
back
to
the
client
the
same
way
where
today,
if
it
sends
an
error,
the
the
the
relay
sends
that
error
back
to
the
client,
so
that
I
think
addresses
ecker's
concerns
that,
like
there's
no
longer
a
response,
you
don't
have
any
way
of
hearing
errors
back
because
I
think
that's
a
real
concern,
but
it
solves
your
cryptographic
problem.
So
that
might
be
a
way
just
a
thought.
L
Again,
I
apologize
for
for
getting
up
to
to
kind
of
restate
something
but
I
think
I
want
to
pull
on
something
that
was
set
up
in
the
chat
room
and
connect
it
to
something
that
that
Eckert
said
it's
like.
If
there
is
a
use
case
for
this
that
doesn't
require
the
oblivious
property,
then
the
clear
thing
to
do
with
this
document
is
to
take
it
to
http
and
work
through
the
HTTP
process
to
to
figure
out
whether
there
are
new
methods
involved.
L
If
there
isn't
a
use
case
for
this
submission
service
that
doesn't
require
the
oblivious
property,
then
I
think
you
have
to
do
a
much
clearer
job
about
describing
what
it
is
about:
the
oblivious
property
and
the
submission
property
that
have
to
be
tied
together
in
some
way,
that's
better
than
the
threat
model.
Change
that
I
see
in
the
document
now,
I
I,
honestly,
don't
get
that
personally
and
it
may
be
just
because
I
didn't
read
deeply
enough
into
the
interconnection
you're.
A
A
Cool
I
think
to
move
on
Ben.
Did
you
want
to
present
thanks
Ralph,
okay,.
C
Causing
that
rough,
it
sounds
like
the
feedback
here
is
that
you
know
there's
there's
some
folks
who
are
in
tune
with
the
use
case,
but
it
sounds
like
we
need
to
drill
in
a
bit
on
the
how
we
measure
the
HTTP,
semantics
and
kind
of
how
we
make
things
fit
together
nicely.
So,
thanks
for
the
presentation,
thank
you.
F
So
this
I
presented
about
this
idea
at
the
last
ITF
meeting,
and
since
then
this
draft
has
had
a
I
I've
made
a
lot
of
changes
to
the
flavor
text
and
basically
no
changes
to
the
actual
technical
content.
But
a
lot
of
the
normative
language
has
shifted.
F
Definitely
people
seem
to
think
that
it
was
too
normative
and
it
seems,
like
people
still
think
it's
too
normative,
but
so
the
the
technical
proposal
has
not
changed.
The
biggest
difference
I
would
say
is
that
I've
tried
to
generalize
the
description
to
also
talk
about
how
this
idea
applies
in
the
Privacy
pass
context,
and
it
seems
like
probably
in
the
future.
This
draft
will
will
move
to
privacy
pass
if
there's
interest
in
continuing
to
discuss
it
at
all
and
and
so
that
you
know
fair
warning.
F
So,
just
as
a
reminder,
there's
Now
new
terminologies
that
I've
changed
the
terminology
compared
to
the
previous
draft.
But
this
is
the
same
idea:
there's
a
client
there's
a
proxy
and
there's
an
origin
that
holds
some
desired
HTTP
resource
it
could
be
any
kind
of
resource
and
our
goal
is
to
fetch
that
resource
in
a
way
that
guarantees
both
consistency
and
authenticity,
consistency,
meaning
everybody
sees
the
same
version
of
the.
H
F
Had
an
unstable
connection
to
meet
Echo
so
that
the
key
idea
here
really
is
that
if
you
need
key
consistency,
you
probably
also
already
have
a
proxy-
and
you
probably
already
trust
that
proxy
not
to
reveal
your
identity
to
the
the
destination
where
you're
trying
to
use
this
key
consistency,
because
otherwise
your
IP
address
will
give
you
away
to
that
destination,
and-
and
so
the
key
consistency
won't
be
sufficient
to
help
you
protect
your
privacy
and
avoid
becoming
linkable.
F
So
if
we're
sort
of
willing
to
make
that
assumption
or
narrow
our
use
cases
to
cases
where
that
assumption
applies,
then
the
whole
problem
becomes
a
lot
easier.
The
key
consistency
problem.
You
only
need
key
consistency
among
the
other
users
of
this
proxy,
because
you're
distinguishable
by
essentially
the
proxies
exit
IP
from
users
of
other
proxies.
F
I'll
just
note
that
the
design
the
draft
has
a
bunch
of
language
in
it
about
how
to
avoid
different
kinds
of
leakage.
There
are
a
lot
of
different
ways
that
you
can
leak
and
and
I
think
these
these
ways
are
not
trivial.
F
They're,
not
it's
not
obvious
how
this
leakage
happens,
so
I
think
it's
worth
documenting,
but
Martin
on
the
mailing
list
pointed
out
that
this
normative
guidance
is
not
actually
necessary
for
the
protocol
to
work
so
we'll
have
to
figure
out
some
way
to
put
up
warnings
of
the
appropriate
kind
without
necessarily
invoking
normative
language.
F
But
the
real
thing
that
I
want
to
present
to
the
working
group
is
this
question:
is
this
actually
how
we
want
to
do
it?
Because
the
remember
this
is
not
an
abstract
design
about
like
here
about
key
consistency.
This
is
a
very
specific
protocol
and
there
are
a
lot
of
different
ways
that
you
could
build
a
protocol
like
this
and
they
have
quite
different
properties.
F
So
I
want
to
mention
two
things
that
are
not
what's
in
the
draft.
One
would
be
to
employ
bespoke
consistency,
logic
at
the
proxy
slash
relay
point,
this
The
Trusted
proxy
intermediary.
That
is,
that
we're
trusting
to
help
us
protect
our
privacy
right
now.
F
As
far
as
I
can
tell,
you
can't
do
that
just
using
HTTP
caching
logic,
and
so
because
of
that
this
design
has
a
Thundering
Herd
effect,
where
all
clients
have
a
single
version
of
the
resource
and
if
the
resource
ever
changes,
all
clients
need
to
flip
essentially
simultaneously
to
the
new
version,
and
so
you
could
get
load
spikes
at
times
when
that
happens.
Maybe
obviously
I
have
not
implemented
this
and
another
question
is:
do
we
really
want
this
double
check?
Or
do
we
just
want
to
sign
the
object?
F
Because
if
we
just
sign
the
thing
like
in
the
ohttp
context,
if
we
sign
the
key
config
with
with
essentially
the
certificate
chain
of
the
of
the
origin,
then
of
the
Gateway
origin,
then
we
don't
need
this
double
check.
We
only
have
to
fetch
once
and
and
everything
becomes
well
that
the
network,
the
flow
diagram-
becomes
a
lot
simpler,
but
the
setup
becomes
a
lot
more
complicated.
Now,
I
need
to
build
some
kind
of
signing
system
and.
F
C
F
Right
so
Ben
is
that
time
for.
F
C
I
I
This
sort
of
line
between
these
two
groups
has
been
sort
of
a
little
fuzzy
on
this
consistency
question
and
we
decided
to
adopt
the
key
consistency
and
correctness
draft
in
that
working
group,
and
it
seems
to
me,
like
that's
a
good
place
to
to
have
that
discussion,
where
the
sort
of
architectural
questions
about
how
we
do
consistency
and
the
requirements
and
what
what
have
you
and
the
general
approaches?
I
I
discussed
there
along
with
this
as
a
fairly
concrete
instantiation
of
these
things,
I'm,
not
sure
what
you
mean
by
the
first
alternative
here
in
terms
of
concrete
specific
steps
and
so
I'm
a
little
leery
of
saying,
let's
just
take
existing
specs
and
then
reinterpret
them
very
creatively.
That's
risky
and
I'm
certain
that
I,
don't
like
the
second
one,
because
the
signing
thing
it
is
much
harder
to
reason
about
and
I
prefer
to
avoid
that
sort
of
thing.
I.
Think
two
requests
is
for
the
for
this
sort
of
thing
perfectly:
tolerable.
F
E
Tommy,
hello,
yeah
so
overall
I
like
the
approach
of
doing
a
get
and
something
through
a
forward
proxy
and
that
part
I
I
like
that
it
doesn't
require
any
new
protocols
being
designed
or
applied
like
it
is
merely
a
technique
that
a
client
can
apply
if
it
has
proxies
available
to
it.
E
F
Have
removed
that
those
are
those
are
now
they
are
I've
still
structured
the
examples
that
way,
but
there's
no
there's
no
longer
any
normative
dependency
on
that.
E
As
like
kind
of
like
a
unadopted
thing
like
it's
a
bit
distracting,
okay,
so
I
agree
with
Martin
that
we
should
talk
about
this
in
privacy
pass
now
that
we
have
key
consistency
adopted
there.
I
personally
think
also
like
that.
All
of
this
can
probably
go
into
that
document
if
it
is
just
about
technique
applying
and
not
new
protocol
work,
and
then
the
question
I
had
for
you
just
about
the
caching
bits.
E
F
The
attack
is
so:
if,
if
you
don't
have
cash
control
immutable
for
example,
then
the
server
can
send
you
can
can
reply
to
the
sorry,
the
the
Gateway
can
rep
or
the
you
know.
Http
terms,
the
Gateway
can
reply
to
the
relay
with
a
with
a
key
config
with
some
long
lifetime.
F
You
know
a
week
and
that
can
go
to
the
client
and
then
the
the
Gateway,
acting
as
a
different
client,
can
can
send
another
HTTP
request
to
the
relay
that
causes
it
to
flush
that
cache
entry
and
replace
it
with
a
new
key
config.
So
now
the
next
client
gets
an
its
own.
You
know
different
key
config.
That
also
has
a
cache
lifetime
of
week.
Now
both
clients
have
long-lived
distinct,
key
configs.
F
E
E
And
the
requests
that
go
over
like
the
forward
proxy,
the
relay
server
manages
the
timing
perfectly
so
that
it
gives
out
the
same
evil
config
to
the
same
client.
E
F
E
F
So
client,
a
and
client
B
have
different
key
configs.
They
send
get
requests
directly
to
the
to.
F
With,
if
match
header
with
an
if
match
header
saying,
here's
the
basically
the
version
of
the
key
config
that
I
want,
is
this
one
valid
and,
and
they
get
it
back
again,
and
the
reason
for
that,
if
match
header,
is
that
the
Gateway
needs
to
be
able
to
rotate
the
key
config.
And
it
doesn't
know
a
priori
whether
a
given
client
has
the
old
one
or
the
new
one.
F
So
so
it
can't
just.
E
J
So
I
found
realistic
caveats
quite
concerning,
like
and
I'm
quite
concerned
that,
like
perhaps
AGP
caches,
not
behave
the
way,
what
everyone
hopes
they
behave
and
they
won't
be
very
sad
people,
so
I
think
like
by
the
way
to
try
to
tease
a
couple
things
apart,
which
is
detection
from,
in
particular,
detection
from
enforcement
right
so
like
if
we
just
went
back
to
the
dumb
design
right
and
forget
about
caching,
you
say:
look
I
just
query
directly
and
like
we're
through
a
proxy
and
the
IP
addresses
are
different
and
now
you're,
not
timing,
attacks,
I
suppose
this
is.
J
F
Yes,
you
also
like
I
said
need
to
worry
about
how
to
handle
cases
where
the
key
config
has
actually
changed,
but
sure.
J
Okay,
so
I
can
imagine
it's
all
that,
like
you
know
forcing
the
server
to
get
a
list
of
every
key
it's
ever
used
and
and
that
kind
of
thing
right
you
know
you
haven't,
maintain
our
block
a
blockchain.
Basically
of
you
know
a
hash,
Channel
lookies,
so
I
guess
this
gets
me
to
my
second
point,
which
is
that
say
that
we
have
mismatch.
What
then.
J
And
and
the
natural
Thursday
is
okay
well
I'm
like
culinary
times
and
but
like
I,
don't
want
to
be
right
and
so
I
think
you
actually
need
the
key
to
be
signed
by
by
the
DVD
certificate
anyway,
and
the
reason
is
simply
that
that's
the
only
way
you
can
demonstrate
that
you
can
Target
someone's
reputation
in
this
base
and
so
like,
if
you
think
of
the
logic
of
CT
right
logic
is
a
t,
CT
is,
is
that
the
certificates
are
all
signed
and
there's
an
assurance
by
the
by
the
ca
that
the
certificates
of
the
log
and
any
time
you
see
a
signed
value
does
not
log.
J
That's
evidence
in
office
right
and
so
I
think
that
I
think
that
we
need
the
same
structure
here,
which
is
basically
some
kind
of
structure
here,
which
is
basically
that
there's
a
plot
that
that
there's
an
understanding
of
what
the
values
or
value
is
supposed
to
be
and
any
value
any
value.
That's
outside
of
that
of
that
period,
if
self-verifiable
or
self-verifying.
Therefore,
it's
kind
of
official
evidence
of
fraud,
but
I,
just
like
I
guess,
I
just
worry
that
we're
gonna
build
cooperatus.
J
That's
going
to
allow
us
to
detect
this
kind
of
malfeasance
and
then
you're
going
to
like
and
you're
going
to
be,
like
you
know,
like
basically
reduce
the
posting
on
Hacker
News.
Does
anybody
else
see
like
this
right
like
this
book
is
key
and
it's
like,
oh,
but
then,
like
I,
see
the
hacker
newspaper
I,
take
it
down.
J
It
just
seems
like
very
complicated
I
think
we're
going
to
end
up
having
to
sign
anyway,
and
so
maybe
I'd
like
this
so
and
so
like
I
guess,
if
you
buy
that
argument,
then
I'm
not
sure
what
that
gets.
Then
I
think.
Maybe
by
that
argument,
then
you
may
have
to
step
back
and
say
if
I'm
signing,
then
what
other
pieces
of
the
puzzle
are
are
changed
right
so
that
that's
I
I,
don't
know
what
I
think
about
this,
but
I'm
just
trying
to
like
work
through
the
entire
problem
at
once.
C
So
next
again
speaking
this
individual
contributor
here
yeah
your
very
first
slide
here
but
had
end
Beyond,
so
I
kind
of
wanted
to
push
on
that
a
little
bit
kind
of
ask
what
the
right
level
of
thinking
about
this
is.
You've
talked
a
lot
about
key
consistency
but,
as
I
think
Nick
Jody
pointed
out
in
the
chat.
There
are
a
lot
of
other
resources
on
the
web
that
one
would
like
to
be
consistent.
C
Like
you
know,
the
Nick
reads:
privacy
policies
I'd
like
to
like
make
sure
that
I'm
getting
the
same
jQuery
as
everybody
else,
so
I
mean
you.
You
could
scope
this.
It
seems
like
the
requirements
are
broadly
pretty
similar
with
regard
to
those
things
even
to
the
level
of
reactions
like
Ecker,
which
is
phrased
so
I
wonder
if
this
is
actually
a
pretty
General
thing
now
it
may
be
that
you
know
if
this
is
a
critical
property
for
something
like
privacy
pass.
C
That
would
be
you
could
it
could
be
addressed
there
first
and
then
generalize
other
things,
but
yeah.
It's
not
really.
This
is
seeming
more
General
than
an
Ojai
problem,
so,
like
maybe
the
right
direction
to
go
with.
This
is
kind
of
you
know
if
it's
really
critical
for
privacy
pass,
which
it
seems
to
be
like
hit
it
there
first,
but
with
an
ice.
These
other
applications.
H
To
find
them
available
now,
for
some
reason
might
meet.
Echo
is
taking
forever
load
up
for
me
today,
but
you're
on
Audible,
yes,
okay,
yep,
so
two
comments.
First,
just
sort
of
for
the
info
people
in
here
repeating
something
I
said
the
Privacy
pass
working
group
a
couple
of
weeks
ago,
both
this
and
the
the
other
consistency
draft,
the
informational
one.
They
both
work
well
in
my
mind,
either
here
or
in
privacy
past.
H
F
H
All
right,
but
I
and
many
others
seem
to
think
yeah.
Let's
just
push
this
into
privacy
pass
and
Ben
gets
to
deal
with
the
hats
problems
from
that,
but
as
far
as
the
actual
Solutions
here
I
maintain
that
this
is
one
reasonable
solution.
This
problem
I
think
that
the
fact
that
we
rent
all
these
caveats
and
potential
pitfalls
and
stuff
is
the
big
proof
that
this
is
a
very
difficult
problem
that
anything
you
have
is
going
to
have
those.
H
So
that's
why
we
need
something
like
this
draft
to
spell
out
a
possible
solution,
because
otherwise
there
was
some
time
with
their
own
bespoke
solutions
that
just
have
all
these
problems,
because
they
didn't
realize
the
issues.
So
we
need
something
like
this,
whether
it's
this
specific
solution
or
the
other
two
Alternatives
you
present
on
this
slide.
I,
don't
have
a
huge
opinion.
It
would
be
nice
to
solve
a
Thundering
Herd
problem,
but
at
the
same
time,
Solutions
I've
tried
to
kind
of
to
solve
the
Thundering
herds.
H
It
might
be
a
matter
of
yeah,
let's
publish
this
draft
with
this
solution
and
it's
usable
for
anyone
that
isn't
quite
as
susceptible
to
the
Thundering
Herd
issue
and
when
we
come
up
with
a
better
solution
that
isn't
thundering
or
hurt
susceptible
we'll
come
with
a
yet
another
draft
for
another
alternative
solution
that
people
could
use
is
not
a
huge
problem
with
having
different
options
of
the
space
if
we
have
to
publish
multiple
protocols.
So
that's
fine,
so.
F
H
Yeah
but
two
solutions:
one
is
simpler,
but
subjectable
of
Thundering
Herd
and
the
other
one
is
a
little
more
complicated
requires
more
logic,
but
is
more
useful
for
bigger
parties
that
care
about
huge
amounts
of
traffic
spikes
and
all
that
sort
of
stuff
that
those
two
solutions
seems
like
a
reasonable
number
to
end
up
with
Mutiny.
So
yeah.
A
Cool
yeah
I
think
it
sounds
like
we
have
consensus
that
this
should
follow
draft
key
consistency
into
privacy
passive
if
the
chairs
of
privacy
pass
agree,
which
then
can
speak
to
that.
D
A
All
right
sounds
good.
We
do
have
a
little
bit
of
time
in
case
anyone
has
any
other
business
going
once
going
twice.
If
not
thanks
all
for
joining
Richard
did
you
want
to
say
anything
else.