►
From YouTube: IETF114 OHAI 20220726 1730
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hey
y'all
we're
to
get
started
in
a
moment,
but
do
we
have
a
note
taker?
Is
anyone
willing
to
volunteer
to
be
a
note
taker.
B
I
think
chris
woodville
and
threatened
earlier
for
whatever
parts
he
wasn't
speaking
for,
but
a
second
second
set
of
hands
would
be
good.
B
A
A
Your
audio's
a
little
bit
unclear
to
me,
but
maybe
that's
just
me,
but
okay
cool
all
right
welcome
all
to
ohai.
I
am
one
of
your
chairs
siobhan
and
we
have
richard
joining
in
remotely
and
yeah.
I
think
this
is
the
note.
Well,
please
note
it
well.
Also.
A
The
ietf
has
a
masking
policy,
which
means
that
if
you're
in
this
room,
you
should
be
masked.
So
just
keep
that
in
mind
and
just
a
reminder
that
we
are
using
meat
echo
and
we
will
be
having
like
a
virtual
show
of
hands
at
some
point
in
this
meeting.
So
you
will
need
to
use
the
on-site
tool
if
you're
in
the
room
and
then
in
meet
echo.
I
think,
if
you're
online,
then
you
should
just
be
able
to
you.
A
You'll
get
a
pop-up
over
there,
so
yeah
just
just
keep
that
in
mind
that
you
might
be
asked
to
use
the
on-site
tool
perfect
and
we
have
a
note
taker.
Thank
you
eric.
A
So
I
think
we
can
get
started
chris
or
martin,
who
is
doing
the
presentation.
Chris,
okay,
perfect.
C
Right,
okay:
this
is
just
hopefully
the
last
update
for
the
main
document
that
we're
working
on
this
on
this
particular
group.
Ohttp
next
slide,
please.
C
There
are
a
number
of
updates
based
on
the
last
version
of
the
last
couple
versions
of
the
draft
between
last
itf
and-
and
today
I
think
the
biggest
one
is
the
state-based
anti-replay
mitigation
that
we
discussed
in
ietf
113.
C
Basically,
the
idea
being
that
if
a
client
sends
an
encapsulated
request
to
a
gateway
that
can't
process
it
because
it
was
like
too
old
in
the
past
or
the
clocks
are
too
different,
the
the
gateway
would
just
respond
with,
like
here's,
a
new
a
date
to
retry
your
request
with
such
that
I
can
apply
like
anti-replay,
I
mean
in
a
meaningful
way,
without
keeping
endless
stay
on
my
side,
we
went
through
the
use
case.
Last
time
went
through
the
proposed
mitigation,
the
pros
mechanism
and
the
text
was
landed
in
the
draft.
C
However,
as
I'll
discuss
in
a
little
bit,
we've
now
yanked
some
of
the
the
the
contents
of
this
particular
mechanism
that
were
previously
outsourced
to
another
draft.
That
martin
wrote
back
into
the
main
spec
here
and
there's
a
pull
request
up
for
actually
landing
that
particular
integration
and
that's
one
of
the
like
remaining
things
to
be
done.
C
But
it's
it's
basically
just
moving
bits
around
between
two
documents:
anyways
beyond
that
actual
mechanical
change
in
the
draft
there's
a
number
of
like
actual
terminology
and
editorial
things
that
we
we
we
fixed.
C
We
we,
as
people
probably
saw
we
had
this
tremendously
successful
bike
shed
on
the
mailing
list,
where
we
like
moved
away
from
proxy
to
relay
and
target
to
gateway,
hopefully
to
make
the
different
roles
of
the
parties
in
the
in
the
system
more
clear
and
there
and
what
they're
doing
and
we
we
did
our
best
to
make
sure
that
the
the
contents
of
the
the
draft
actually
match
what
was
discussed
in
the
mailing
list.
But
there
may
be
some
like
residual
references
to
proxy
or
whatever.
C
So
if
there
are,
please
be
sure
to
let
us
know
improve
text
on
various
like
privacy
related
things
in
particular
like
what
can
happen
if
a
relay
happens
to
be
offering
different
services
to
different
clients
in
response
to
like
how
a
client
is
interacting
with
a
gateway
or
how
a
client
is
interacting
with
a
relay
and
what
that
differential
treatment
has
on
the
privacy
posture
of
the
client,
interacting
with
the
gateway.
C
The
the
primary
motivating
example
for
this
particular
body
of
text
was
the
shadow
banning
use
case
where
relay
might
want
to
signal
to
the
gateway
hey.
This
particular
client
is,
you
know,
has
been
flagged
by
some
mechanism
and
the
relay
or
the
gateway
might
then
choose
to
act
differently
based
on
this
particular
bit
and
how
that
impacts.
The
the
overall
privacy
posture
of
the
client
is
worthy
of
consideration.
So
now
there's
text
that
actually
talks
about
this.
C
The
big
like
breaking
change
in
the
latest
version
of
the
draft
thanks
to
david
benjamin,
is
a
change
to
the
key
schedule,
a
very
minor
change,
but
it
is
a
breaking
change
nonetheless,
and
we'll
I'm
just
going
to
quickly
summarize
what
happened
in
the
next
couple
slides.
So
next
slide,
please,
okay!
So
the
old
key
schedule
looks
something
like
this:
I've
simplified
things
a
lot
just
to
kind
of
show
where
different
inputs
to
the
the
key
schedule
go.
C
Some
of
the
inputs
like,
for
example,
on
the
on
the
left
side
with
the
client
you
have
like
the
the
gateway's
public
key.
You
have
the
context
string
for
hpke,
that's
fed
into
like
create
an
hp
context
for
actually
encrypting
or
encapsulating
things
to
the
to
the
gateway
at
the
bottom.
We
have
what
I
refer
to
as
the
ohb
configuration
parameters.
C
That
includes
like
what
what
hbt
cypher
suite,
chem,
kdf,
aad
and
whatnot
was
configured
what
the
key
id
was
for
that
particular
and
those
are
bound
to
the
actual
encrypted
request.
That
goes
out.
Note
importantly,
that
the
the
these
configuration
parameters
are
not
bound
to
the
key.
That's
exported
from
this
http
context,
which
is
relevant,
should
go
to
the
next
slide.
Please,
because
this
exporter
key
is
the
thing
that's
piped
in
and
used
by
the
the
the
gateway
for
actually
encrypting
a
response
back
to
the
client.
C
So
we
had
the
situation
where
the
ciphertext
was
not
entirely
bound
to
like,
basically
everything
the
client
had
when
it
started
its
encapsulated
request.
C
It
was
only
bound
to
public
key
and
the
content
or
the
context
string,
which
is
ohtp,
slash
request
and
the
fix
was
simply
to
next
slide
to
lift
everything
that
was
previously
piped
into
the
aed
and
just
like
plumb
it
into
the
hpk
info
based
into
the
hp
key
schedule,
so
that
it
gets
folded
into
the
export
key,
such
that
the
request
that
gets
encrypted
from
the
client,
as
well
as
the
corresponding
key
or
content
that's
encrypted
from
the
gateway
back
to
the
client
using
the
exported
key.
C
It's
all
bound
to
basically
everything
and
there's
not
like
at
the
bottom
I've
written
that
there's
nothing
that's
sent
to
the
aad
as
additional
authenticated
data,
because
everything
is
now
piped
in
through
the
hp
info
parameter
and
therefore
about
to
the
key
schedule.
So
there's
not
any
more
possible
binding
that
we
can
do.
I
think
this
is
like
the
this
is
complete.
C
Okay
and
then,
as
I
was
referring
to
earlier,
we
had
this
other
other
big
kind
of
mechanical
change
that
was
landed
in
the
last
version
of
the
draft
between
or
since
the
last
meeting.
We
were
previously
referencing
this.
This
draft
that
martin
wrote
but
kind
of
in
a
unknown,
stalled
state
in
http
right
now,
so
we
figured
rather
than
just
block
on
that,
and
definitely
let's
just
yank
the
stuff
out
of
that
draft-
that
we
need
for
osu
tv
specifically
and
then
make
forward
progress.
C
C
That's
not
successful
with
a
date
header
in
it
and
it
talks
about
how
a
gateway
should
use
that
header
or
that
yeah
sorry
use
that
date,
header
for
the
purposes
of
triggering
this
retry
functionality
from
the
client
and
there's
lots
of
privacy
considerations
there
about,
like
clients
should
not
just
indefinitely
retry
with
you
know,
new
dates
and
whatnot
and
should
not
use
a
date
from
a
response
that
it
gets
from
a
gateway
for
more
than
one
request
and
so
on
so
relatively
straightforward,
and
this
is
purely
editorial,
just
lifting
text
from
one
document
to
another.
C
Thanks
a
lot
please!
Okay!
At
this
point,
I
think
barring
merging
this
particular
editorial
change.
The
documents
feature
complete.
We
have
a
number
of
interoperable
limitations
at
this
point.
C
It's
a
simple
protocol
and
I
think
at
this
we're
kind
of
ready
for
a
working
glass
call
unless
there
are
any
other
things
that
people
would
like
to
add.
So
I'll
turn
it
to
the
chairs
now
to
see
what
they
want
to
do.
A
Okay,
do
you
folks
have
comments
about
last
call
we'll
also
do
a
show
of
hands,
but
if
there
are
any
serious
concerns,
then
right
now
would
be
great
to
hear
them.
B
Does
anyone
know
any
reason
why
we
should
not
send
this
document
off
in
the
working
group?
Last
call
speak
now
or
hold
your
piece
into
the
last
call.
A
Maybe
a
good
question
to
ask
is:
have
folks
read
the
draft,
I'm
going
to
start
a
show
of
hands
online
if
you're
on
site,
you
will
have
to
join
the
the
onsite
tool.
D
D
A
Okay,
I'm
going
to
close
it
now,
there's
about,
I
guess,
out
of
the
40
people
who
said
the
people
who
participated
in
the
poll.
15
people
said
that
they
have
and
26
people,
I
guess,
did
not
raise
their
hands.
So
then
let
me
just
end
this
and
then
ask
my
second.
A
Yeah
and
the
folks
who
said
no
it'd
be
great
to
hear
why
or
if,
if
folks
don't
have,
if
the
people
who
are
saying
like
who
voted
for
no,
I
can
also
assume
that
that
that
means
that
you
don't
have
an
opinion
which
is
fine,
but
it
would
be
great
to
hear
any
concrete
reasons
as
to
why
not.
A
Okay,
I
think
we
can
close
the
session
like
overwhelmingly
people
who
participated
in
the
poll
said.
Yes,
so
I
think
we'll.
D
C
A
List
as
well,
but
this
looks
pretty
great
great-
is
there
anything
else
you
guys
want
to
talk
about.
C
No
we'll
we'll
we'll
merge
the
the
pr's
that
are
open,
we'll
add
some
editorial
text
for
your
issue
and
then
I
think
we
can
move
forward.
We'll
cut
a
new
version
soon.
A
A
Yeah
tommy
did
you
want
to
talk
about
the
svcd.
E
Okay,
hello,
everyone,
I'm
tommy
pauly
from
apple,
and
we
have
a
document
we
talked
about
last
time.
I
think
teru
also
was
helping
on
this
and
essentially
now
that
we
have
our
basic
ohtp
definition.
E
This
is
getting
a
little
bit
more
into
some
of
the
use
cases
and
deployment
models.
The
kind
of
default
that
ohtp
has
expects
that
you
have
very
coordinated
deployments
where
the
clients
and
the
targets
and
the
gateways
and
the
relays
kind
of
all
know
that
they're
working
together,
and
that
is
all
out
of
band
that
works.
Fine.
That
is
certainly
one
way
to
use
it,
but
there
are
also
potentially
some
use
cases
for
doing
a
bit
more
dynamic
discovery,
and
so
that's
what
this
document
tries
to
talk
about
next
slide.
E
E
The
second
use
case
is
one
in
which
you
are
using
this
target
service
through
the
oblivious
gateway
as
an
option
that
you
otherwise
would
not
use.
So
the
model
that
we
have
here
is
something
that
we
practically
have
when
we're
doing
dns
over
oblivious
http
and
in
this
model.
Let's
say
the
client
has
its
trusted
relay
again
and
it
has
a
default,
oblivious
gateway
and
a
default
dns
resolver
that's
going
to
use
in
general.
E
It
already
has
this
provisioned
out
of
band,
but
then
it
is
interested
to
say
that,
if
in
under
a
certain
scenario
like
it's
on
a
network
that
has
a
resolver
configuration
that
it
would
prefer
to
use
because
it
provides
the
right
either
filtering
for
the
requirements
of
being
on
the
network
or
resolution
for
access
to
internal
domains
that
are
particular
to
that
network.
E
So
the
scope
of
this
document-
it's
pretty
short,
we've
gotten
good
feedback,
and
I
think
the
the
current
shape
is
something
that
kind
of
is
a
bit
more
of
a
complete
story
and
can
actually
work
viably.
There
are
two
parts
to
it.
E
One
is
essentially
a
way
to
learn
that
a
service
has
an
associated
gateway
which
is
kind
of
one
piece
of
the
puzzle,
and
I
would
like
to
thank
the
main
ohtp
authors
for
clarifying
terminology
around
gateways
and
targets,
because
that
makes
it
actually
much
easier
to
refer
to
things
and
be
clear
about
what
we
mean.
E
As
a
client
is
know,
what
is
the
key
configuration
and
the
current
way
that
is
done
is
just
saying:
hey
if
you
have
this
gateway,
that
you
would
normally
do
a
oblivious
request
through
a
post
to
let's
just
do
a
get
and
specify
that
I
want
to
get
the
key
configuration
from
it,
and
that
is
a
way
to
fetch
that
these
are
just
essentially
the
proposed
mechanisms.
I
think
for
any
discovery
mechanism
like
this,
thus
trying
to
achieve
those
goals.
E
These
are
the
two
pieces
of
information
you
need,
so
we
can
of
course,
debate
what
is
our
preferred
way
of
getting
these
pieces
of
information
next
slide?
Please!
E
So,
just
concretely
to
give
examples
of
each
of
these,
we
have
the
dns
response,
which
can
include
the
oblivious
gateway,
and
it's
just
encoded
there
as
a
url
and
for
the
key
configuration
query.
We
just
do
a
get
and
we
say
I
want
to
get
the
ohtp
keys,
so
it's
pretty
straightforward
from
that
perspective
next
slide.
E
I
think
the
interesting
part
here
is
how
you
protect
against
key
targeting
or
url
targeting
and
making
sure
that
user.
That's
learning
about
this
isn't
being
singled
out.
If
you
do
have
a
unique
gateway,
uri
or
unique
key
config,
then
the
client
could
be
targeted
or
identified
when
it's
using
the
service,
you
could
have
your
proxy
or
relay
try
to
participate
in
recognizing,
like
oh
yeah.
This
is
a
common
gateway
versus
that's
a
gateway
that
only
you
are
using,
but
there
are
different
ways
of
doing
this.
E
I
think
this
is
where
a
lot
of
the
interesting
discussion
lies,
and
I
know
that
there
are
multiple
other
conversations
in
this
working
group
and
others
talking
about
consistency
and
key
targeting
and
ways
to
mitigate
that.
So
I
think
this
can
fold
into
that
broader
conversation
as
something
that
would
like
to
benefit
from
those.
E
So
that's
it.
I
think
at
this
point,
it's
mainly
a
question
of
you
know
is
the
working
group
interested
in
taking
on
the
discovery
of
a
gateway
and
config
problem.
I
think
it's
in
scope
for
what
is
in
the
working
groups
charter
we're
kind
of
done
with
the
main
protocol,
so
it
seems
like
if
we
want
to
do
this
at
some
point,
then
this
is
a
decent
time
to
do
it,
love
to
hear
your
feedback.
F
Ben
schwartz,
oh,
I
forgot
to
use
the
q
martin's
actually
in
the
queue,
so
I
I'm
having
trouble
understanding
the
the
security
properties
here.
It
looks
to
me
like
this
still
suffers
from
some
of
the
same
problems
that
that
I
was
concerned
about
with
the
the
first
revision
of
this
draft,
which
is
that
an
intermediary
on
the
dns
path,
that
is,
that
can
modify
this.
F
This
record
could
swap
out
the
gateway
for
entirely
for
their
own
gateway
and,
as
far
as
I
can
tell,
there's
nothing
here
that
would
that
would
that
would
detect
this
on
the
on
the
client
side.
So
I
could
take
any
origin
in
the
world
even
in
origin
that
doesn't
have
any
support
for
oblivious
http,
and
if
I
can
intercept
the
dns,
then
I
can
inject
myself
as
the
gateway
claim
that
ohttp
is
supported
and
then
impersonate
that
origin,
essentially
bypassing
the
protections
of
tls.
E
F
The
thinking
about
consistency
for
a
moment
it
depends
what
you
mean.
Maybe
if
consistency
is
about
making
sure
that
a
given
gateway
shows
the
same
key
configs
to
everybody,
then
it's
definitely
not
sufficient
here,
because
I
can
mint.
First
of
all
that
I
don't
need
to.
I
can
give
a
a
single.
The
attacker
can
can
have
a
consistent
gateway
and
still
be
consistently
impersonating.
F
B
F
That's
right
and
that's
why
the
gateway
always
has
to
be
provisioned
through
a
trusted
channel,
and
in
this
case
I
see
the
gateway
being
provisioned
through
an
untrusted
channel,
at
least
in
the
threat
models
that
I'm
used
to.
Okay.
So
on
the
adoption
question
I
do
want,
I
do
want
something
along
these
lines.
I
do
think
that
I'd
like
to
to
see
the
working
group
work
on
discovery,
but
I
think
maybe
we
need
to
have
a
little
bit
more
consensus
about
what
direction
we're
going
to
go
before
we
proceed
with
an
adoption
sure.
E
G
Yeah,
so
I
I
think
this
is
an
important
point
and-
and
I
I've
just
made
some
changes,
I
think
to
the
to
the
base
specification
that
sort
of
addressed
this
point.
If
you
have
the
gateway
operating
on
the
same
server
as
the
target,
then
I
I
think
the
concerns
that
you
have
are
less
lesser
yes
than
than
previously,
and
I
think
that's
what
tommy
wants
to
do.
Yes,.
E
But
that
is
an
interesting
point
that
if
they
are
not
co-located,
how
do
you
establish
that
they're
actually
related,
but
if
they
are
like,
if
you
use
the
same
tls
handshake
to
get
to
them,
no
matter
what
right
like?
If
the
thing
I'm
fetching
my
key
config
from
with
the
get
request
is
the
thing
that
I
that
is
my
target
service.
G
Yeah,
but
but
no
ben's
right,
he
shook
his
head
there.
There
is.
There
are
those
scenarios
where
you
have
multiple
tenants
on
the
same
host
sure
some
of
them
have
control
over
some
resources,
but
not
others,
and
if
they're,
in
a
position
to
put
themselves
in
the
position
of
the
gateway
they
are
then
able
to
do
that,
which
is
why
I
think
the
use
of
dot
well
known
in
this
context
does
give
us
something.
A
G
I
know
I'm
happy
to
move
back,
not
well
known,
yes,
but
I've.
I've
realized
that
I
think
perhaps
in
this
case
we
probably
need
something
along
those
lines.
Because
of
this
reasoning,
and-
and
that's
only
a
recent
realization
of
my
part-
and
I
think,
thanks
to
ben
and
richard
and
others
for
pointing
out
some
of
these
flaws,
I
think
that's
probably
where
we're
going
to
need
to
go
with
this
one.
Unfortunately,
that.
E
H
Eric
gorth,
google-
I
I
believe
I
agree
mostly
with
what
ben
and
others
are
saying
about
all
the
correctness
and
consistency
concerns.
D
H
Is
an
area
we
definitely
need
to
solve?
There's
huge
concerns
there
sure,
but
I
think
that's
big
enough
area
to
solve
that.
That
should
be
a
separate
draft
and
I
think
ben's
presenting
one
that
one
something
like
that
in
15
20
minutes
from
now.
So
we
can
discuss
that
a
little
bit
more
there,
but
assuming
we
have
stuff
like
that
solved
in
a
separate
draft,
saying
here's
how
to
get
these
packets
of
information
securely
and
consistently.
H
I
think
there's
good
room
for
this
draft
to
focus
much
more
on
just
the
payload
itself
say:
here's
how
you
give
the
discovery
from
the
key
info
in
dns.
Here's
how
you
give
it
in
an
hp
request
and
then
point
to
the
other
stuff
and
say
these
are
the
ones
that
tell
you
how
to
fetch
that
securely
and
safely
and
all
that
stuff
and
those
ones
can
point
at
this.
One
say:
here's
the
the
format
of
that.
So
I'm
very
supportive
of
working
on
stuff
like
this
and
adopting
this.
D
I
think,
with
that,
the
group
does
need
to
work
on
discovery.
I
think
it's
really
important.
I
think,
though,
it'd
be
helpful
to
try
and
ensure
that
there's
a
separate
discovery
for
the
gateway
and
the
relay
to
minimize
the
risk
of
collusion
between
those
two
they're
discovered
using
the
same
mechanism.
I
think
that
that
is
risky.
E
In
order
for
this
to
work
like
essentially
to
recognize
that
the
target
has
a
gateway,
the
document
says
like
yeah,
the
relay
discovery
is
out
of
scope,
and
I
think
if
people
are
interested
in
relay
discovery,
which
is
fine,
that
is
something
that
needs
its
own
considerations
and
likely
would
be
related
to
discovering
more
general
purpose
relays,
because
an
ohp
relay
likely
would
be
able
to
serve
as
a
much
broader
category
of
relay
for
things
like
mask
or
just
being
able
to
do
other
dns
services.
D
E
Yeah,
I
I
do
have
a
little
bit
of
a
question
on
the
the
relay
discovery
question
if,
depending
on
what
that
mechanism
ends
up
being,
that
may
not
belong
strictly
in
ohio
if
it
is
something
that
is
potentially
more
generic,
whereas
the
ojai
gateway
configuration
really
is
truly
specific
to
ohio
and
doesn't
apply
to
anything
else.
So
that's
why
I
believe
it
does
belong
clearly
here
and
I'm
just
not
sure
about
relays.
C
Yeah,
chris,
would
I
I
do
think
so
I
mean
sure
there
might
be
some
key
consistency
things
we
have
to
sort
out,
but
this
draft
is
a
good
step
in
the
right
direction
and
I
think
it
should
be
adopted.
I
do
not
think
we
should
pull
in
things
like
relay
discovery.
I
think
that's
a
separable
and
much
harder
problem,
as
you
have
indicated
so.
C
E
A
D
B
I
I
So
we
made
some
changes
to
update
the
document
based
on
some
feedback
and
to
align
it
with
the
http
api
rate
limit
headers,
we'll
talk
about
in
some
details.
So
to
recap,
what
this
draft
is
doing
is
trying
to
help
identify
misbehaving
clients
that
are
abusing
the
target
and
allowing
the
the
proxy
to
know
about
those
and
slow
those
down,
because
the
alternative
is
bad.
I
So
the
the
change
to
use
the
http
api
rate
limit
headers
is
we're
extending
those
slightly
to
include
detail.
That
is
just
for
the
proxy
so
that
the
proxy
knows
that
it's
supposed
to
process
that
header
and
deal
with
it
and
not
pass
that
on
to
the
client,
because
it's
it's
not
useful
for
the
client.
I
So
the
underscored
and
highlighted
text
here
is
the
extensions
that
we're
describing
in
the
draft.
Now
the
http
target
equals
two.
I
talk
about
in
a
couple
of
slides
from
now
and
that
that
is
a
signal
to
the
proxy
that
this
is
a
certain
style
that
you
know
of
a
attack
and
a
certain
style
of
behavior
that
we
would
like
to
see
from
that
proxy
and
if
the
proxy
can't
meet
that,
there's,
there's
no
feedback
that
it
can't
or
it
won't.
I
It's
just
a
way
to
hopefully
prevent
all
the
traffic
from
that
proxy
from
being
throttled
by
the
target
because
of
a
single
misbehaving.
Client
such
as
one
sending
malformed,
http
or
or
some
other
sort
of
attack
traffic
that
you
know
is,
is
either
purposefully,
malicious
or
accidentally
malicious,
because
something
has
gone
wrong
in
the
client.
I
And
this
is
the
example
message
flow,
it's
very
much
like
the
http
api
that
we're
patterning
this
after,
but
we're
just
tacking
on
the
o
http
target
parameter
to
this
that
is
processed
by
the
relay.
That's
proxying,
the
traffic.
I
And
the
interesting
one
here
you
know
one
is
somewhat
interesting.
Number
two
is
is
where
it's
more
interesting
in
that
the
the
client
traffic
is
identified
by
the
target
as
being
somehow
malicious.
Malformed
http
is
the
easiest
one
to
conceptualize
and
the
other
change
that
we
made.
I
That
is
probably
interesting
to
the
working
group
is
the
proxy
doesn't
need
to
take,
take
account
immediately,
but
can
wait
until
it
receives
several
of
these
messages
from
the
target
complaining
about
about
the
same
client
and
then
start
taking
action
against
that
client
to
rate
limit.
What
it's
doing.
I
The
purpose
of
that
is
to
prevent
the
partitioning
of
good
clients
from
bad
clients,
or
rather
they
pretend
to
prevent
the
partitioning
of
good
clients
and
good
clients
such
that
we're
only
partitioning
the
good
clients
versus
the
bad
clients,
where
the
bad
clients
are
generating
bad
http
and
bad
transactions.
I
And
one
other
addition
to
the
draft
is
a
mechanism
for
the
proxy
and
the
target
to
communicate
with
each
other,
about
which
headers
that
they're
going
to
understand
between
each
other.
The
value
here
is,
if
they're
not
configured
by
the
same
entity
where
the
the
changes
can
be
pushed
out.
At
the
same
time,
then
this
helps
prevent
inconsistencies
in
the
configuration
between
the
proxy
and
the
target
so
that
they
understand
the
headers
that
will
be
stripped
by
the
proxy
and
the
headers
that
will
be
sent
by
the
target.
F
F
It
seems
difficult
to
me
to
understand
how
you
do
this
within
the
ohtttp
threat
model,
basically
the
the
gateway
if
it
wants
to
try
to
link
different
requests
if
it
sees
a
bunch
of
requests
coming
in
and
it
wants
to
slow
them
down
that
that,
in
a
sense,
by
definition,
is
linking
them
right.
If
you
believe
that
that
this
particular
flood
of
requests
all
comes
from
a
single
user
being
able
to
answer
that
question
in
any
way
breaks
ohtttp's
unlinkability
guarantees.
F
So
so
it's
I'm
not
saying
it's!
It's
technically
impossible!
I'm
saying
that
we
need
to
be
very
careful
about
what
we
recommend
here,
because
we're
punching
a
hole
in
our
own
in
our
own
privacy
claims
right,
okay,
and
so
I
think
I
think,
there's
a
really
interesting
question
here
about
you
know
what
a
relay
can
safely
do
or
how
much
damage
it
does.
F
G
So
that's
one
type
of
treatment
that
we've
considered,
but
in
doing
that,
we've
been
trying
to
be
very,
very
clear
that
the
client
needs
to
understand
the
scope
of
the
things
that
are
possible
in
that
context,
once
you
add
feedback
into
the
loop,
it
becomes
much
more
complicated
in
terms
of
giving
the
client
some
confidence
that
the
the
gateways
and
the
targets
aren't
trying
to
back
out
the
privacy
protections
avoided
by
the
relay,
and
so
I
see
a
lot
of
positive
movement
here.
G
I
think
that
the
sorts
of
things
that
you're
doing
in
terms
of
trying
to
disconnect
the
immediate
effect
of
the
feedback
from
from
the
actions
that
occur
is
probably
a
good
direction
to
have.
I'm
afraid.
I
haven't
read
the
very
latest
in
this,
but
I
would
like
to
be
more
confident
that
that
analysis
was
good
before
I
be
confident
moving
forward.
I
think
there's
probably
a
few
things
we
could
change
about
the
spelling
as
well,
but
that's
that's
separate.
Okay,.
A
Does
that
sound
good
ben
sounded
like
the
consensus
is
not
yet,
and
we
can
revisit
this
in
a
bit.
A
F
Hi
benchwards
is
there
a
clicker?
Is
there
a
magic
clicker?
No
okay.
The
agenda
said
I
had
five
minutes,
so
I
squished
these
slides
down
to
nothing
to
to
try
to
squeeze
it
all
in.
It
seems
like.
Maybe
we
have
a
little
more
time
than
that?
Yes,
but
so
maybe
I'll
I'll
try
to
explain
a
little
more
what's
going
on.
F
For
for
oblivious
http,
although
it
might
have
some
more
general
applications,
but
let's,
let's
move
to
the
next
slide.
F
So
I
think
it's
easiest
to
to
think
about
this
in
concrete
terms.
So,
let's,
let's
pick
an
arbitrary
concrete
example
and
talk
about
this
sort
of
telemetry
use
case.
That's
mentioned
in
the
o,
http
document,
so
imagine
that
your
os
default
installation
state
reports
telemetry
to
some
sort
of
remote
service
and
that
remote
service
supports
ohttp.
F
Now
you
believe
that
the
os
image
or
I'm
sorry,
I
believe
that
my
os
image
is
the
same
as
everyone
else's.
I
haven't
been
served
a
custom
crafted
os
image
that
points
me
to
to
a
unique
instance
of
the
telemetry
service.
So
I
believe
that
that
there's
essentially
that
is
already
consistent,
but
I
still
don't
trust
the
telemetry
service
not
to
try
to
link
my
reports
together.
F
If
I
trusted
it,
then
I
wouldn't
need
ohttp,
so
I've
configured
my
os
to
make
use
of
that
oh
db
service,
I'm
using
an
ohttp
relay
and
I
trust
that
relay
not
to
collude
with
the
telemetry
service,
but
in
this
case
also,
I
don't
fully
trust
the
relay.
I
don't
trust
it
to
see
the
plain
text
context
of
my
reports.
Otherwise
again
we
wouldn't
need
ohttp.
F
So
this
is
this
is
trying
to
get
to
the
point
where
we
actually
need
ohttp
at
all.
Oh
db
serves
a
pretty
narrow
use
case.
F
Okay,
so
so,
with
all
those
assumptions,
how
do
I
convince
myself
that
I'm
using
the
gateway,
url
key
config
and
target
url?
So
in
this
case
the
target
url
is
the
telemetry
service?
F
That's
the!
So
that's
the
problem.
How
do
we
actually
get
the
ohtp
protections
next
slide?
Okay,
there's
an
easy
answer
to
this:
you
just
hard
code.
All
of
these
right
into
the
os
image.
We've
already
assumed
that
the
os
image
is
globally
consistent
and
I
haven't
been
served
a
unique
os
image
that
was
custom,
crafted
as
an
attack
on
me.
F
I
could
just
get
all
of
this
through
whatever
my
bootstrap
stages.
That's
that's
fine,
but
I
I
don't
think
it's
very
attractive
as
an
operational
practice.
Among
other
things,
it
prevents
key
rotation.
If
you
bake
the
key
configs
into
the
operating
system,
you
can't
rotate
the
keys.
So
that's
a
that's
a
pretty
obvious
problem
and
there
are
other
changes
you
might
like
to
make.
F
Maybe
you
want
to
maybe
your
gateway
is
operated
as
a
hosted
cloud
service
and
you
want
to
change
service
providers
to
a
different
gateway
operator
next
slide,
so
this
proposal
tries
to
solve
that
it
tries
to
enable
in
a
sense,
dynamic
bootstrap
without
losing
the
ohtttp
privacy
guarantees,
and
this
is
how
it
works.
First.
First,
you
you
create
some
kind
of
config
file
that
holds
the
gateway,
url,
the
key
config
and
a
description
of
the
actual
service
you're
trying
to
reach
target
url.
F
I
have
been
calling
this
the
service
description
host.
That's
the
origin
that
hosts
this
thing.
This
is
all
there's
another
draft
that
I'll
be
talking
about
in
mask
that
actually
lays
out
a
format
for
this
kind
of
config
file,
but
the
the
exact
format
doesn't
really
matter
here,
so
we
fetch
this
config
through
the
relay
and
we
ask
the
relay
to
act
as
a
cache,
and
this
is
basically
just
an
http
cache.
F
This
is
like
an
old-fashioned
http
forward
proxy
before
https.
So
it's
like
a
caching
forward
proxy.
We
just
ask
the
relay
to
fetch
the
the
service
description
for
us
and
since
it's
in
cash,
it's
usually
in
cash.
We
we
get
back
the
same
answer
as
all
the
other
users
of
that
relay.
F
Crucially,
one
of
the
one
of
the
crucial
observations
here
is
that
the
consistency
problems
for
ohttp
are
only
scoped
to
each
relay.
It
doesn't
matter
whether
users
of
different
relays
have
consistent
views
here.
So,
like
we've
talked
one
of
the
things
that
comes
up
occasionally
and
chris
wood
has
enumerated,
and
I
draft
all
of
the
sort
of
basic
strategies
for
for
dealing
with
the
key
consistency
problems.
F
Some
of
them
look
like
blockchains
and
you
know
that's
a
very
powerful
global
consistency
mechanism,
but
it
actually
doesn't
really
matter
because
it
doesn't
matter
beyond
the
scope
of
a
single
relay
if
you,
if
you're,
using
a
different
relay
you're,
clearly
a
different
user
so
so
to
to
get
consistency
scoped
to
a
given
relay.
We
just
essentially
read
the
description
out
of
cache
held
in
that
relay,
so
all
the
users
get
the
same
copy,
and
that
gives
us
consistency,
but
it
doesn't
give
us
authenticity
again.
F
We
don't
trust
the
relay
not
to
try
to
impersonate
the
gateway,
so
the
the
relay
could
just
be
lying
to
us,
giving
us
its
own
key
config.
F
So
to
solve
that,
we
fetch
it
again
and
this
time
we
fetch
it
directly
from
the
service
description
host
over
a
standard,
authenticated,
https
and
now
that
gives
us
authenticity,
but
it
doesn't
guarantee
consistency
so
to
make
sure
that
we
have
both.
We
just
check
that
they're
identical
and
they
should
be
identical.
F
There's
a
little
detail
here
that
we
ask
the
relay
in
this
system
to
also
be
a
mask
proxy,
so
connect
udp
proxy.
That
seems
as
as
tommy
suggested
earlier.
That
seems
like
something
that
may
be
pretty
common
and
that's
not
strictly
necessary
actually
for
for
our
consistency
guarantees.
But
if
you
don't
do
that,
then
the
gateway
ends
up
with
a
list
of
all
of
the
ip
addresses
of
the
users
behind
the
relay
and
while
it
can't
can't
then
link
requests
to
one
or
the
other.
F
You
can
imagine
that
it
might,
for
example,
take
those
ip
addresses
to
a
data
broker,
who
tells
it
more
information
about
the
users
that
it
could
eventually
use
to
profile
them
and
identify.
You
know
this.
This
request
is
really
only
likely
to
have
been
from
this
particular
person
who,
I
know,
know
quite
a
bit
about
via
their
ip
address
and.
B
Quick
quick
clarifying
question
here:
you're
assuming
the
relay
and
the
service
description
hosts,
are
not
colluding.
Correct.
B
B
F
F
Okay,
there
are
a
lot
of
details
in
the
draft
about
exactly
how
this
works.
It's
all
in
the
draft
in
this
proposal,
it's
all
stitched
together
from
standard
http,
stuff
lots
of
different
headers
for
standard
caching
headers.
There
are
a
few
slight
tweaks
beyond
what
is
just
required
by
the
standard
implementation
of
these
headers,
and
that
gives
us
defenses
against
a
bunch
of
different
kinds
of
attackers.
F
You
might
think
that
fetching
the
fetching
this
service
description
twice
before
you
can
use.
It
is
a
big
performance
penalty.
I
actually
think
it's
pretty
manageable,
my
in
my
analysis,
through
the
in
the
draft.
F
I
think
it
adds
up
to
about
two
round
trips,
basically
the
same
as
a
fresh,
quick
setup,
one
one
round
trip
to
set
up
quick,
one
round
trip
to
fetch
the
to
fetch
the
resource,
but
I
think
that
for
most
of
the
use
cases
we're
talking
about
once
you
get
that
service
description,
it's
good
for
hours,
two
days
so
two
round
trips
once
a
day
or
something
like
that,
I
think
is-
is
pretty
manageable.
F
So
I
my
current
thought
is
that
this
could
be
a
good
document
to
fit
into
ojai,
and
I
I
think
it's
it'll
probably
evolve
quite
a
bit,
but
I
would
like
to
see
it
see
it
move
forward
here
to
try
to
unlock
some
of
those
broader
use
cases
where
you're
discovering
your
your
gateway.
As
you
move
about
the
internet.
A
Cool
martin,
I
think
you
were
first
no.
E
Hi
ben,
thank
you
for
sharing
this.
I
originally
was
going
to
come
up
with
just
kind
of
about
a
nit
for
where
you're
listing
like
oh,
the
other
check
would
be
connect
udp.
I
you
know
that
works.
If
your
target
server
is
doing
quick,
it
obviously
could
just
be
another
h2
server.
E
So,
like
you
know,
connect
connect,
udp,
some
variant
of
that,
and
I
think
really,
rather
than
talking
about
that,
it
would
be
useful
to
structure
this
in
terms
of
the
like
the
tls
context
in
which
you
are
fetching
the
key
config
right
so
like
you
want
one
tls
con
like
a
tls
connection
to
the
actual
service
description,
that's
like
authoritative
for
this
target
and
then
another
one
so
to
a
different
context,
which
in
this
case
is
the
one
on
the
relay
so
like
you
have
essentially
two
tls
handshakes
to
two
different
entities
and
they
both
agree
and
then
really.
E
At
that
point
I
imagine
like
that.
Other
one
doesn't
even
need
to
be
the
relay.
That's
caching,
it
could
just
be
anyone
else.
So
I
think
this
sounds
like
it
generalizes
to
check
with
the
person
who
says
they
own.
The
key
config
and
check
with
someone
else
in
two
different
tls
handshake
contexts,
and
then
that
gives
you
a
bit
more
trust.
F
F
One
of
them
is
if,
if,
if
you're,
the
rule
is
that
you
just
have
to
check
with
some
independent
party-
and
there
are
10,
well-known,
independent
parties
that
people
like
to
use
right
and
then
all
the
people
on
your
relay
choose
one
of
them
at
random.
E
B
G
Yeah,
so
I
think
the
the
way
that
you
structure
this
is
quite
good.
I
like
the
idea
of
using
a
double
check
sort
of
technique.
G
The
relay
can't
give
you
any
assurances
about
correctness
if
you
ask
for
its
cash
copy
of
it,
but
the
relay
does
give
you
the
ability
to
get
some
amount
of
consistency
out
of
that,
and
so
that's
the
structure
that
I
would
look
for.
I
don't
know
that
I,
like
the
connect
stuff
that
you've
put
in
this
document.
G
So
I
I
would
prefer
to
to
maybe
step
back
a
little
bit
and
look
at
the
abstract
thing
and
talk
about
those
those
two
things
that
I
talked
about
before
and
then
talk
about
why
you
might
choose
to
do
things
like
connect,
tunnels
and
other
things
as
optimizations
or
so
on
and
so
forth,
as
as
enhancements,
rather
than
than
being
part
of
the
core
solution
that
you've
described.
F
Sure
I
would
be
interested
to
know
whether
you
think
in
general
for
ohtttp,
you
know:
do
you
feel
it's
important
that
the
gateway
not
learn
the
client
ip
addresses
as
a
as
a
whole?
The
pool
of
client
ap
addresses.
G
The
gateway
I
I
don't
think
that
in
general,
that's
that's
a
problem.
I
think
it
may
become
a
problem
depending
on
certain
deployments
and
contexts.
Yes,
particularly
when
you
consider
the
possibility
that
clients
might
also
be
connecting
to
the
server
that
operates
the
gateway
for
other
purposes
outside
of
the
this
particular
usage.
So
it's
something
to
think
about
and
we
should
probably
document
the
consequences
of
taking
the
direct
route
as
opposed
to
a
proxy
drought,
but
concentrating
on
the
core,
which
is
we
want
correctness
and
consistency
and
and
how
we
achieve.
H
Eric
google
a
couple
comments.
First,
I
really
like
this
overall
I've
been
saying
for
a
while
that
practice
and
consistency
is
something
we
really
need
to
solve,
and
this
is
you've
taken
a
pretty
good
approach
here.
I
think-
and
I
I
want
us
to
work
on
and
fine-tune
this
next
comment.
Those
are
the
correspond
comment
what
I
said
earlier
in
discovery
and
the
config
distribution.
H
Out
of
this
third
comment,
though,
once
we've
removed
the
specific
payload
from
this
draft,
this
just
becomes
a
generic
draft
for
receiving
a
shared
payload
with
proven,
correct
and
or
validate
correct
and
validated
actually
shared,
and
it's
not
even
using
oblivious
itself.
So
this
stops
feeling
like
an
oblivious
specific
thing
other
than
the
fact
that
we
really
need
it.
H
So
at
the
cost
of
potentially
slowing
down
a
draft
that
I
want
yesterday,
I
almost
suggest
that
we
should
maybe
send
this
to
a
dispatch
group
to
see
if
there's
a
better,
more
general
place
with
the
night.
You
have
to
have
this
and
if
no,
if
we
can't
find
a
better
place,
then
yes,
then
we
actually
should
adopt
into
this
group,
then,
because
we
do
need
it.
F
F
In
order
to
do
that,
by
my
logic,
we
need
a
format
that
can
convey
the
the
target
key
config
and
gateway
url
as
a
as
a
unit,
because
they
need
to
be
cached,
atomically
and
and
rechecked
atomically
so
and
that
format
I
will
be
talking
about
in
the
mask
because
it
also
embeds.
F
F
A
I
think
ben,
I
think
we
should
wrap
up
it's
yeah,
we're
over
time
yeah.
So.
A
Can
take
this
on
the
list
all
right,
great
thanks
all
for
coming,
I
think
the
highlight
was
that
we
decided
to
do
a
last
call
for
the
main
protocol
draft
and
there's
some
great
new
work
lined
up
so
see
you
all
next
time.