►
From YouTube: IETF112-OHAI-20211108-1430
Description
OHAI meeting session at IETF112
2021/11/08 1430
https://datatracker.ietf.org/meeting/112/proceedings/
A
All
right,
it
is
6,
30
a.m,
pacific.
So
let's
begin!
Oh
hi.
Everyone
welcome
to
the
first
official
working
group
meeting
of
the
newly
formed,
oblivious
http
application
intermediation
working
group.
We
are
your
chairs
welcome
and
we
have
multiple
notetakers.
Thank
you
all
for
for
volunteering
and
for
job
describing
richard,
and
I
figured
that
we
can.
We
can
just
keep
an
eye
on
the
chat
and
relay
any
questions.
A
This
is
the
note.
Well,
please
read
carefully,
especially
if
you're
this
is.
This
is
your
first
ietf
meeting,
but
even
if
not,
please
always
be
sure
to
be
mindful
of
the
node
well,
and
also
the
ietf
code
of
conduct,
as
laid
out
in
rfc
7154
folks,
are
expected
to
be
courteous,
not
engaged
in
personal
remarks,
mindful
of
diversity
and
contributory.
A
And
this
is
our
agenda
and
we
have
a
one
hour
slot
reminder
that
the
session
is
recorded
and
the
blue
sheet
attendance
is
auto
generated.
Please
keep
video
and
audio
off
in
case
you
are
not
if
you
are
not
presenting
or
not
recognized
in
the
queue
and
to
enter
the
queue.
There
should
be
a
button
over
here
which
raised
hand
icon
to
join
the
queue.
So
please
press
that
in
case
you
want
to
join
the
queue
I'll
pause
here
for
a
second
to
see.
A
B
Okay,
just
to
confirm
you
can
see
the
slides
great
okay,
all
right,
so
thank
you
on
this
is
just
an
overview
of
oblivious
http,
I'm
still
going
to
refer
to
the
protocols
of
http,
even
though
the
word
group
has
probably
one
of
the
best
names
we've
seen
in
the
itf
for
some
time
now.
This
is
primarily
led
by
martin,
but
I've
helped
him
know
a
little
bit
along
the
way.
Okay.
So
the
the
problem
statement
for
oblivious
hp
is
quite
simple.
B
Doing
simple,
very
simple
tasks
like
performing
you
know
a
dns
query
or
executing
a
safe,
a
safe
browsing
query
in
which,
in
interacting
with
the
server
they're,
revealing
a
bit
of
sensitive
information,
the
actual
data
itself
is
sensitive
and
by
virtue
of
connecting
directly
to
the
server
they're,
also
reviewing
their
identity.
That
is
the
ip
address
of
the
client
directly
to
the
server
as
well.
B
B
So
if
you
consider
the
case
of
the
dns
queries,
this
allows
say,
for
example,
a
dns
recursive
resolver
to
collect
effectively
the
the
browsing
history
of
clients
and
they
may
have
you
know,
policies
around
how
those
how
that
data
is
managed,
but
essentially
it's
it's
it.
It's
not
great
for
the
data
to
be
collected
or
available.
In
the
first
place
there
are
a
number
of
other
applications
as
well.
B
It's
been
discussed
on
the
list,
for
example,
uploading
telemetry
data
from
a
browser
or
any
other
application
to
a
server
where
the
telemetry
data
might
have
sensitive
information
about
that
particular
client's
experience
using
the
web
page
or
doing
some
other
activity
where
you
don't
want
to
link
that
particular
data
with
a
specific
client
and
in
general,
there's
there's
a
lot,
there's
plenty
of
applications
and
scenarios
where
we
have
these
sort
of
transactional.
You
know
single
request
response
protocols
or
exchanges
taking
place
in
which
the
exchange
itself
does
reveal
sensitive
information.
B
Of
course,
there
are
a
number
of
ways
you
could
address
this
without
any
new
protocol.
For
example,
you
could
use
a
general
connection,
oriented
proxy
like
connect
as
it's
already
standardized
or
the
hask
or
tor,
but
as
of
it's
often
the
case
that
these
these
connection,
oriented
proxies,
have
much
stronger
requirements,
extra
privacy
and
on
anonymity
requirements
in
practice.
B
Tor,
for
example,
has
multiple
hops
that
clients
go
through
in
order
to
further
off
you
skate
and
and
make
sure
that
linking
a
specific
client
to
a
specific
target,
eventually
connecting
to
is,
is
hard
in
the
presence
of
some
some.
You
know
a
very
pervasive,
active
attacker
and,
as
a
result
of
you
know,
stretching
things
out
or
adding
more
layers
or
hops.
There's
more
overhead
added
to
the
protocol,
which
is
problematic,
because
typically,
these
transactional
exchanges
that
take
place
for
dns
queries.
B
B
You
could,
for
example,
get
great
performance
with
connect
or
mask
if
you
kept
the
connection
open
for
a
long
amount
of
time
and
then
just
sent.
You
know
these.
These
single
request
response
queries
over
that
over
that
long
lived
connection,
but
then
you'd
be
allowing
the
server
to
potentially
link.
You
know
these
multiple
queries
of
these
multiple
requests
over
the
single
connection,
even
though
the
server
might
not
know
who
you
are,
which
is
less
good
from
a
privacy
perspective.
B
Alternatively,
if
you
wanted
to
break
that
link
ability,
you'd
have
to
stand
up
a
fresh
connection,
a
fresh
tunnel
every
single
time,
which
does
incur
a
performance
penalty.
So,
in
general,
you
know
this
trade-off
is
not
great,
especially
for
performance-sensitive
applications
like
dns
and
other
things,
and
it's
unnecessary.
It
turns
out,
as
is
exemplified
by
obvious
http.
B
You
can
also
go
down
the
route
of
using
a
specific
application.
Specific
protocol,
for
you
know
breaking
this
link
ability.
So
in
the
case
of
telemetry,
where
you
are,
you
know
trying
to
it,
collects
some
information
about.
You
know
what
the
browser's
user's
experience
is
like
you.
You
could
collect
this
data
in
a
privacy
preserving
way
using
something
like
prio
or
privacy,
preserving
measurement,
there's
a
bluff
happening
later
this
week.
B
I
encourage
folks
to
check
out,
but
these
inherently
are
more
complicated
protocols
involving
more
parties,
and
it
requires
infrastructure,
non-trivial
infrastructure
that
is
not
currently
there.
It's
also
true
that
oblivious
http
requires
new
infrastructure
as
well.
It's
it's
significantly
simpler
and
retrospect
in
the
case
of
prio,
specifically
as
well.
This
these
application,
specific
verticals,
add
delay.
You
can't
just
like
collect
the
data
instantaneously
and
then
look
at
it,
whereas
with
you
know
the
protocols
that
we're
talking
about
here
and
oblivious
http
dns
state
browsing.
B
B
It's
a
very,
very
simple,
message-oriented
proxy
between
client
and
server.
That
combines
two
well-known
things
for
achieving
privacy,
and
you
know
breaking
this
linkability
between
client
and
identity,
the
first
of
which
is
a
network
proxy
between
the
client
and
the
target,
we'll
call
it
that
exists
to
obfuscate
or
hide
the
client
ip
address,
or
it's
identity
from
the
target
server
and
the
second
of
which
is
public
key
encryption
using
hpke
to
hide
data
from
the
proxy
itself.
B
B
And
here's
just
a
sort
of
quick
overview
of
how
it
works
just
to
in
case
you're
not
familiar
with
it.
So
the
typical
arrangement
is,
you
have
this
client
proxy
and
a
target,
and
then
typically,
you
know
resource
for
servers
beyond
a
particular
target.
I'm
like
sort
of
separating
them
here,
because
the
target
has
a
particular
role
in
terms
of
the
actual
encryption
and
decryption
that
takes
place
and
the
resource
server
is
the
one
that
actually
has
the
content
of
the
clients.
B
B
So
fundamentally,
what
we
have
here
are
well
fundamentally,
we
have
here
is
a
simple
request
response
encrypted
in
each
way
and
if
the
client
was
to
send
multiple
of
these,
each
of
them
would
be
sort
of
unlinkable
from
from
each
other.
From
the
perspective
of
the
target,
because
all
the
target
sees
is
a
single
tls
connection
to
the
proxy
and
then
multiple
encrypted
requests
or
queries
coming
over
it.
It
doesn't
know
whether
or
not
they're
coming
from
the
same
client
or
not.
C
Hey
chris
quick
clarifying
question:
I
noticed
you've
drawn
this
dotted
box
on
the
target
server
and
the
resource
server.
It
does
that
indicate
that
you
know
in
principle
those
two
could
be
operated
by
the
same
menstru
or
could
be
instantiated
on
the
same
device
without
undermining
the
security
guarantees.
We're
after
here
that's
correct.
B
Especially
in
the
case
of
dns
or
oblivious
doe,
which
is
like
the
predecessor
to
this
work,
it's
advantageous
for
the
target
server
and
the
resource
server,
which
is
the
recursive
resolver
in
this
case,
to
be
operated
by
the
same
entity
to
minimize
performance
penalties
involved.
There's
there's
no.
I
again,
as
as
I
was
saying
earlier,
they've
only
separated
them
for
the
purposes
of
you
know,
separating
the
roles
that
they
play.
B
B
So
if
we,
if
we
revisit
the
the,
if
you
think
back
to
the
the
initial
the
initial
slide,
wherein
the
server
previously
saw,
both
the
data
and
identity
quickly
convince
you
that
that
this
is
no
longer
the
case
in
in
this
particular
protocol,
assuming
non-collusion
requirements
I'll
get
to
in
just
a
little
bit.
So
it
should
be
obvious
that
the
client
knows
both
the
data
that
wants
to
send
and
the
data
it
receives,
as
well
as
its
own
identity.
B
Proxy.
However,
though,
because
it's
just
sending
encrypted
requests
and
response
between
the
client,
the
target,
all
it
sees
in
clear
text-
are
the
identities
of
either
end.
So
it
knows
the
client
that
it's
engaging
with,
and
it
knows
the
target,
that's
it's
sending
data
to
on
behalf
of
the
client,
but
it
doesn't
know
anything
about
the
data.
B
Beyond
that,
you
know
module
like
length
of
the
encrypted
data
and
whatnot,
but
touch
on
that
a
little
bit
as
well,
and
then
the
target
equally
sees
just
the
identity
of
the
targets
or
the
proxy
server.
That's
engaged
with,
as
well
as
any
of
the
client
data,
the
that
is
the
encrypted,
or
rather
the
decrypted
request
and
the
response
that's
produced
in
result
as
a
result
and
eventually
sent
back
to
the
client.
B
So
the
threat
model
is
fairly
simple.
It
assumes
some
trust
between
parties
that
are
engaged
in
the
protocol
so,
for
example,
the
the
client
in
in
its
configuration
and
selection
of
a
particular
proxy.
It
trusts
that
the
proxy's
not
obviously
just
revealing
sensitive
information
to
the
target
like
not
just
sending
along.
You
know
the
client
h
ip
address
and
an
http
header
along
the
request,
and
the
target
also
assumes
that
the
proxy
is,
you
know,
taking
measures
to
ensure
that
it's
not
overloading
it's
not
overloading
the
target.
B
B
B
B
As
a
a
practical
matter
in
you
know,
using
oblivious
http
there's
a
number
of
number
of
things
to
consider
from
an
operational
perspective,
I
think
the
very
first
thing
to
to
make
abundantly
clear
is
that
this
is
an
application
specific
proxy
protocol.
So
I
mentioned
dns.
I've
mentioned
telemetry
data
uploading,
I
mentioned
safe
browsing
queries
as
well.
B
It
is
not
meant
to
be
a
general
purpose,
proxy
protocol,
for
which
we
already
have
solutions,
if
that
was
something
you
desired,
like
connect
like
mask
like
tor,
and
so
on
importantly
also
that
the
discovery
and
configuration
of
you
know
what
clients
are
sorry
which
proxies
a
client
will
use,
as
well
as
which
targets
clients
will
engage
with
across.
These
proxies
is
out
of
scope
of
this
particular
document.
B
The
the
the
main
idea
is
very
similar
to
doe
in
that
we're
simply
specifying
the
protocol
mechanics
and
leaving
the
the
deployment
considerations
to
subsequent
work
and
subsequent,
I
guess
yeah
effort
either
in
this
in
this
in
this
working
group
or
elsewhere.
I
forget
exactly
what
the
charter
says
about
this,
but
anyways.
B
It's
it's
distributed
out
of
band
discovered
out
of
band
and
configured
clients,
it's
possible
for
proxies
to
take
encrypted
messages
under
these.
These
static
keys
and
replay
them,
and
so
targets
need
to
make
care
targets
need
to
ensure
you
know
that
they
are
injecting
pressure
randomness
into
every
single
response.
That's
it
that's
produced
in
response
to
an
encrypted
request,
and
the
protocol
does
dictate
that
this
happens.
But
you
know
care
needs
to
be
taken.
Nevertheless,
to
ensure
that
randomness
is
fresh.
B
There
are
a
number
of
remember:
there
are
at
least
two
implementations
that
we're
aware
of
that
are
interoperable,
one
of
which
was
written
by
martin.
Another
one
was
written
by
me
and
there
is
a
test
server
up
that
you
can
interact
with
a
test
target
server
that
you
can
interact
with,
that
will
simply
spit
out
whatever
bytes
you
happen
to
send
it
and
then
in
an
encapsulated
http
request.
B
I
guess
let
me
know
or
send
a
message
to
the
mailing
list.
We
can
share
details
in
terms
of
like
what
the
how
to
use
this
thing,
but
it's
there
ready
to
ready
to
be
hit
and
with
that
I
think
I'll
pause
for
any
like
technical,
clarifying
questions
and
assuming
we
get
through
all
those
I'll
turn
it
over
to
the
the
chairs
to
to
deal
with.
This
question
tell
me:
go
ahead.
D
All
right,
hello,
thank
you
for
the
presentation,
so
one
comment:
I
just
wanted
to
volunteer
that
I
did
recently
implement
the
protocol
from
the
drafts,
both
this
and
binary
http
messages,
and
I
think
that
the
specs
are
good
and
definitely
usable
and
ready
for
adoption.
Based
on
that,
I
did
have
a
couple
clarifying
questions
based
on
that
that
I'll
just
quickly
ask
one
of
the
things
that
wasn't
obvious
initially
reading
through
the
doc.
D
That
became
obvious
implementation
is
the
fact
that
the
proxy
has
to
have
like
a
pretty
static
mapping
to
like
when
you
give
it
a
request.
Where
is
it
supposed
to
go
on
the
back
end
and
there's
a
fair
amount
of
state?
That's
not
mentioned
there.
So
it'd
be
nice
to
see
a
bit
more
because
that's
a
piece
of
the
architecture
that
wasn't
really
clear,
but
then
the
other
question
I
haven't.
Maybe
this
is
the
one
we
can
address
now.
D
The
part
about
binary
http
being
the
body
of
this
seems
to
be.
You
know,
as
there
are
different
documents
pretty
disconnected
and
like
in
odo,
you
know
we
didn't
actually
have
the
interior
of
the
oblivious
message
be
http,
it's
fine
for
it
to
be
http,
but
in
this,
in
the
current
document
we
are
specifying
like
this.
Payload
always
is
a
binary
hp
message.
It
seems
that
both
the
client
and
the
target
could
decide
to
put
something
else
in
there.
D
B
I
I
think
the
latter
and
the
document
is
at
least
the
oblivious
hdb
document
is
sort
of
written
in
that
particular
way
and,
as
you
point
out,
as
you
observe,
that
is
it,
it
deals
strictly
with
the
the
encapsulation
and
decapsulation
mechanism.
Doesn't
make
any
sort
of
that.
I'm
that
I
can
recall
stronger
requirements
in
terms
of
what
is
actually
in
the
the
encrypted
payload
so
yeah.
B
B
And
on
your,
I
guess
your
your
first
question
regarding
sort
of
proxy
configuration
yeah,
I
agree.
Certainly
more
information
could
be,
I
guess,
included
with
respect
to
what
state
proxies
need
to
keep
in
order
to
keep
in
order
to
route
requests
from
clients
to
particular
targets,
as
you
know,
in
obviously
erin
oblivious
doe.
Rather,
we
sort
of
put
the
state
on
the
wire,
so
clients
would
specify
effectively
the
route
via
the
request
that
came
into
the
proxy
but
oblivious
http.
B
C
So
the
protocol
starts
from
an
assumption
that
the
client
has
selected
a
proxy
server
and
a
target
server
that
it
assumes
are
non-colluding
how
the
client
makes
that
choice
is
out
of
scope.
You
can
imagine
a
variety
of
ones,
ranging
from
fully
automated
discovery
to
highly
manual
configuration.
That
is
not
the
business
of
this
working
group.
So
any
discussion
of
you
know
how
we
you
know.
E
Andrew
so
I
was
gonna
exit,
the
cube
and
I'll
ask
the
question
anyway,
which
was
what
can
we
do
to
try
and
avoid
the
problem
of
colluding
proxies,
but
noting
richard's
comment
you
might
want
to
ignore
that
for
now,
but
I
think
it
is
a
problem
that
at
some
point
we
have
to
address
otherwise
we're
giving
the
illusion
of
privacy,
but
with
absolutely
no
guarantees
of
anything
whatsoever
being
provided
to
the
end
user.
So,
from
an
end
user
point
of
view,
I
think
that's
hugely
problematic.
B
Yeah,
I
mean
it's,
it's
a
good
question
and
I'm
gonna
punt,
because
for
now
it's
out
of
scope,
but
when
we
start
talking
about
you
know
dynamic
configuration
of
these
things
and
actual
discovery
protocols.
I
think
we'll
obviously
need
to
address
that,
but
for
the
time
being,
with
the
assumption
that
you
know
the
configuration
falls
from
the
air
and
the
the
participants
just
run
with
it,
I
think
we
can
safely
ignore
it.
B
F
B
Sorry,
I'm
not
closely
following
the
chat,
but
the
situation
to
me
seems
very
indistinguishable
from
or
trying
to
detect.
Whether
or
not
you
know
parties
are
colluding
seems
very
similar
to
trying
to
detect
whether
or
not
say
a
tls
terminating
server
is
just
like
posting
its
you
know,
keys
to
twitter
or
or
you
know,.
F
Sure
my
counter
argument
would
be
that
we
would
have
said
the
same,
but
the
web
pki
before
certificate
transparency-
probably
but
given
certificate
transparency,
that's
no
longer
true
and
again,
but
not
in
an
individual
transactional
kind
of
level,
but
at
some
kind
of
if
somebody
clever
goes
looking
level.
It's
some
kind
of
technical
auditor
type
thing.
C
Yeah,
I
I
I
maybe
sure
something
is
chair
here.
It's
like
stephen,
if
you
have
concrete
proposals
here
by
all
means,
feel
free
to
propose
into
the
list
but
yeah.
I
don't
think
this
is
something
that's
clear
in
the
charter
as
a
requirement
and
needs
to
be
blocked,
needs
to
block
the
main
protocol
document.
C
C
G
We
I've
opened
an
issue
in
response
to
tommy's
query,
and
that
is
something
that
we
can
talk
about
later.
If
we
get
past
these
things,
the
initial
more
important
issues,
but
for
the
moment
the
protocol
is
fixed
to
the
use
of
this
binary,
http
messaging
coding,
and
how
do
I
get
to
the
next
one
all
right
there?
It
is
so
the
idea
is
to
cover
entire
http
messages
to
the
target
resource.
G
G
G
I
have
an
implementation
of
this.
I
heard
that
tommy
has
implemented
some
of
this
as
well.
It's
relatively
straightforward.
I
think
it
was
about
300
lines
of
code
in
rust,
not
that
difficult
most
of
the
hard
part
of
writing.
This
code
was
parsing
http11
messages,
which
is
what
you
see
at
the
top
of
the
slide
there,
or
rather
in
the
middle,
because
those
are
terrible
in
various
ways.
G
So
I'm
here
to
really
just
say
this
is
probably
not
something
that
this
working
group
wants
to
take
on.
We
should
take
on
the
encapsulation
part
and
all
of
the
difficult
questions
that
people
have
raised
about
how
this
all
fits
together,
but
instead
we
asked
the
http
working
group
to
take
this
sort
of
work
on
I've
gotten
some
feedback
there.
C
H
G
Yeah,
so
it
depends
on
the
extent
to
which
we
allow
for
tommy's
idea
of
generic
things
to
to
be
facilitated
in
the
framework.
So
it
doesn't.
It
doesn't
really
carry
http
at
that
point,
but
you
can
carry
other
things
over
http,
and
so,
if
we
make
allowances
for
that
we
could
we
could
get
this
to
work.
C
G
G
C
I
I
C
J
G
C
C
C
Okay,
I'm
going
to
start
the
show
of
hands
now,
please
raise
your
hand
if
you
think
that
the
working
group
should
adopt
the
drafts
that
chris
presented
as
the
starting
point
for
fulfilling
our
charter
milestones
and
click.
The
do
not
raise
hand
button.
If
you
have
concerns
about
adopting
this,
isn't
working
as
a
starting
point
for
our
working,
your
deliverables,
okay,
so
clicking
the
button
now.
C
C
Okay,
so
we
will
take
this
out
and
confirm
it
on
the
mailing
list
feel
free
to
contribute
to
any
discussion
there.
If
you've
already
raised
your
hand
here,
there's
no
need
to
reconfirm
it.
There
we'll
just
cover
any
additional
issues
there,
but
it
looks
like
we
have
pretty
good
consensus
to
adopt
this
oblivious
http
draft
and
get
to
work
on
it
as
a
working
group
item
thanks
all
so
with
that
our
remainder
of
our
agenda
is
set
aside
for
looking
at
issues
related
to
that
draft.
C
G
G
G
The
only
difference
would
be
that
when
you
construct
a
request
or
a
response,
you
would
be
able
to
construct
it
in
such
a
way
as
that
pieces
of
it
would
be
available
for
processing,
as
opposed
to
the
entire
thing.
I
I
don't
know
if
there's
any
desire
to
go
for
anything
far
more
generic
than
that
along
the
lines
of
what
you
described.
G
H
D
C
I
see
mark
back
in
cuba,
maybe
I'll
I'll
vamp
for
a
second
while
he
gets
audio
going
so
just
to
try
and
throw
the
decision
into
higher
relief
here.
Martin
is
the
choice
here
between
having
more
flexibility
and
capturing
the
entire
range
of
interactions.
That
http
allows,
on
the
one
hand
and,
on
the
other
hand,
having
a
simpler
interaction
model,
say
a
simple,
a
single
request,
single
response
and
declaring
certain
http
patterns
cannot
be
done
over
this
channel.
C
G
I
messages
that
was
true
already,
although
it
shifts
where
you
maintain
that
state.
So
in
the
current
design,
you
can
send
up
one
of
six,
but
the
server
would
would
not
be
able
to
decrypt
it,
so
it
would
be
holding
the
ciphertext
and
this
one
potentially
changes
that
to
shift
to
the
application
domain.
So
if
that's
important,
that's
important,
I
don't
know.
G
L
All
right,
it's
like
this
webrtc
thing
isn't
done
or
anything
yeah.
I
was
one
of
the
folks
who
was
asking
these
questions
and
I
don't
have
direct
strong
feelings
about
it
or
or
concrete
use
cases.
This
was
just
one
of
the
things
where
it
felt
like
we
often
put
these
artificial
barriers
in
place.
You
know
because
of
design
constraints
and
then
applications
immediately
trip
across
them.
So
we
should
do
so
really
consciously
if
we're
going
to
do
it
and
and
also
to
me,
it
really
spoke
to
the
naming
issue.
G
L
So
so
I
guess
that's
the
question
as
well.
As
I
understand
it,
this
is
really
a
question
for
the
generic
proxy
layer
or
or
or
how
you
how
you
bundle
up
the
crypto.
I
guess
it's
it's
and
it's
also
a
question
for
things
like
one
xx
about
the
the
http
format.
So
how
do
you
see
this
being
reflected
in
the
two
different
drafts.
G
L
A
G
G
Okay,
all
right,
so
the
next
one
talks
about
what
additional
data
we
need,
and
this
gets
it
into
interesting
questions
about.
Well,
two
things
really
so
chris
open
the
issue,
and
I
think
I
split
it
two
ways.
The
first
one
I
I
think
we're
going
to
want
to
talk
about
the
question
of
what
information
does
the
client
or
the
server
need
to
provide
to
the
the
intermediary
in
terms
of
what's
going
on
under
the
encapsulation,
in
order
for
it
to
more
effectively
do
its
job?
G
And
that's
really
not
something
that
I
think
we
need
to
discuss
here
unless
someone
has
a
stunning
idea,
but
if
it's
something
that
people
might
want
to
think
about,
the
other
aspect
of
that
that
I
think
we
might
want
to
discuss
at
some
point
is
anti-replay
capabilities.
So
one
of
the
more
unfortunate
properties
of
this
is
that
the
proxy
becomes
a
potential
source
of
replay
attacks
against
the
server
and
providing
some
capabilities
or
some
sort
of
facilities
for
doing.
B
That's
exposed
in
the
clear,
so
the
the
idea
was.
Could
you
potentially
reuse
ohtp
for
this
particular
purpose,
including
some
additional
authenticated
data
allowing
one
to
deploy
a
proxy
between
client
and
server
if
you
wanted
one
later
on
without
any
other
sort
of
wire
format
change?
But
I
agree
with
the
the
pushback
that
has
been
discussed
on
the
on
the
issue
that
you
don't
necessarily
want
to
be,
adding
or
exposing
more
things
to
proxies,
but
that
was
the
origin.
C
C
I
think
getting
people
in
sync
getting
a
good
adoption,
call
clear
adoption
call
which
we'll
confirm
on
the
list
now,
as
we
work
on
burning
down
these
issues
and
making
progress
on
our
new
working
group
document
just
wanted
to
see,
if
folks
would
think
it
useful
to
have
some
virtual
interims
scheduled.
So
we
could
do
something
like
have
monthly
or
bi-weekly
calls
to
go
through
some
of
these
issues
and
try
and
keep
up
the
keep
up.
C
C
Okay,
so
we
can
focus
on
async
for
now
should
should
we
should
real-time
face-to-face
be
useful.
We
are
always
two
weeks
away.
We,
the
itf,
requires
two
weeks
notice
before
we
have
a
working
group,
virtual
interim
so
feel
free
to
propose
such
and
we
can
get
something
scheduled
all
right.
I
think
we
are.
That
is
the
last
I
had
on
my
agenda.
So
I
think
we
are.
We
are
done
here.
Three
minutes
early,
so
enjoy
the
rest
of
your
ietf
day.