►
From YouTube: IETF115-HTTPBIS-20221107-1530
Description
HTTPBIS meeting session at IETF115
2022/11/07 1530
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
A
So,
first
of
all,
first
and
foremost
the
note
well
policy.
You
should
all
be
familiar
with
this
by
now,
but
if
not,
these
are
the
policies
under
which
we
participate
in
the
ITF
regarding
things
like
intellectual
property
and
privacy
and
harassment
code
of
conduct,
copyright
there
are
many
different
aspects
to
it.
So
if
you're
not
familiar
with
them,
please
do
familiarize
yourself
with
it.
It's
important.
A
This
meeting
does
have
a
mask
policy,
I'm,
hoping
you're,
aware
of
that
by
now
too,
if
you're,
not
speaking
or
or
eating
or
drinking,
please
do
wear
a
mask
and
and
exercise
common
sense,
and
yes,
I
did
notice
that
someone
left
their
power
cord
here,
hi,
hi,
Lucas,
well,
I
didn't
want
to
name
names,
so
please
do
remember
to
keep
your
mask
on
and
if
someone
gently
reminds
you
take
it
in
the
spirit
which
it
was
intended,
can
we
have
a
scribe
for
this
session?
Is
anyone
willing
to
take
minutes
please.
A
A
C
All
right,
hi
everybody
I'm
Justin
richer.
This
is
going
to
be
a
short
presentation.
Next
slide,
please,
on
update
on
HTTP
message,
signatures
we've
gone
through
a
couple
of
revisions
of
editorial
updates.
Added,
more
examples.
We
added
something
called
the
tag
parameter,
which
was
very
briefly
called
the
context
parameter
until
we
got
some
feedback
that
that
was
a
dumb
name
and
so
there's
the
tag
parameter
in
there.
Now
it's
optional
don't
need
to
get
into
it
and
we
have
gone
through
a
one
month.
C
Long
working
group
last
call,
after
which
a
lot
of
comments
came
in
about
the
document.
So
thank
you
for
those
that
that
have
done
that
so
far
right
now,
there
are
only
a
couple
of
small
things
going
in
so
first
Lucas
needs
to
apparently
get
me
an
update
on
the
digest.
Example
in
the
draft
I
think
thank
you
I
guess.
Apparently,
it's
wrong
I'm,
not
sure
how
it's
wrong,
but
if
you
could
make
it
not
wrong,
that'd
be
awesome
and
we
can
touch
base
in
the
hallway
or
something.
C
But
somebody
pointed
at
a
line
in
HTTP
semantics
and
I'm
getting
some
head
shakes
in
the
room,
so
this
might
be
a
very
short
discussion
next
slide,
please
so
so,
obviously,
if
we
have
a
hypothetical
field
that
can
exist
as
both
a
header
and
a
trailer
do
we
both
call
these
both
food
next
slide,
because
the
naive
thing
to
do
would
be
to
just
cram
them
together.
To
look
like
this,
that's
what
the
spec
says
to
do
right
now,
I'm
getting
a
lot
of
head
shakes.
C
This
is
why
I
tagged
you
guys
on
the
GitHub
issue,
so
I
wouldn't
have
to
have
these
slides,
but
I'm
glad
we're
here
so
next
slide.
The
alternative
proposal
is
to
just
explicitly
call
something
out
as
a
trailer
as
a
data
source
using
a
Boolean
flag.
That
tells
this
that
allows
the
signer
to
signal
and
the
verifier
to
know
where
to
Source
the
information
and
then
otherwise
we
just
treat
it
like
any
other
any
other
field.
Next
slide.
We
actually
have
precedent
for
this
with
the
request
parameter.
A
Let's,
let's
go
to
the
key
I'll
interject
and
then
Martin
might
have
something
to
say
so
in
in
HTTP
the
most
recent
series
of
updates.
We
recognize
that
trailers
had
some
really
fundamental
interoperability
and
deployability
issues,
and
so
we
defined
them
as
a
separate
namespace
from
headers,
so
they
are
distinct.
You
cannot
just
naively
combine
them
unless
the
definition
of
the
header
field
or
sorry
the
field
says
yes,
you
may
do
that.
Oh.
C
A
And
so
we
flipped
that
so
so
your
approach,
the
approach
that
you
talk
about
here,
we're
using
TR,
might
be
workable.
The
only
thing
that
I
would
add
to
that
is
you
have
to
realize
that
it
is
completely
legal
to
drop
trailers
on
the
floor.
Both
you
know
intermediaries
and
by
recipients
they
can
just
disappear,
and
so
you
need
to
account
for
that.
If
you
want
it
to
be
robust,
yeah.
D
D
C
D
C
C
C
C
The
second
bullet
is
that
if
you
have
an
implementation-
or
you
know-
of
an
implementation
of
the
HTTP
working
group
draft,
not
the
Cabbage
draft
I'm
going
to
be
putting
up
a
tab
on
httpsig.org
our
sort
of
demo
site
playground
space
to
start
listing
these
implementations,
because
I've
had
a
lot
of
people
coming
at
me.
Lately
asking
for
that
list,
so
I'm
gonna
put
it
up
and
then
just
have
a
link
to
like
make
a
GitHub
pull
request.
A
A
E
E
There's
also
for
those
cdns
that
use
anycast
anycast
can
wind
up
in
the
wrong
spot.
It
happens,
there's
a
lot
of
work
that
goes
on
to
make
sure
that
doesn't
happen,
but
it
still
does,
and
in
some
cases
we
have
endpoints
that
can
offer
you
better
service
based
on
where
you
are
or
who
you
are,
that
we
didn't
know
when
you
did
the
DNS
resolution.
So
we
might
like
to
be
able
to
point
to
to
some
endpoint
that
we
control
that
special.
E
That
would
give
you
faster
service
and
the
most
common
use
of
alt
service
right
now
is
for
protocol
availability.
So
you
spoke
to
us
over
H2
we'd,
like
to
tell
you
that
we
also
have
our
H3
endpoint,
or
you
spoke
to
us
over
each
one
and
we'd
like
to
tell
you
that
H2
is
a
different
port
hypothetically,
although
that
mostly
doesn't
happen
in
the
real
world.
A
F
F
D
E
All
right,
so
we
at
this
point
have
two
main
ways
to
redirect:
the
user.
We
can
either
do
it
before
the
request
happens
using
DNS
or
we
can
do
it
after
the
request
happens
using
alt
service
and
those
are
both
great
options
slide
Trouble
Comes,
when
we
have
to
combine
them
right
now.
What
the
service
B
spec
says
is
that
if
you
implement
alt
service
and
https,
you
take
all
the
host
names
you
found
in
alt
service.
F
E
And
Delay,
oh
okay,
so
the
trouble
that
we
have
other
than
just
using
them
together
is
what
do
we
do
when
we
get
both
sets
of
information
because
the
old
service
is
potentially
old?
So
how
do
we
make
sure
it's
still
valid,
but
it
was
received
over
a
TLS
connection
directly
from
the
origin,
whereas
DNS
comes
through
other
servers
along
the
way,
possibly
unencrypted.
E
How
much
do
we
trust
when
they
don't
say
exactly
the
same
thing,
so
we
want
a
way
that
lets
us
make
sure
things
are
fresh
before
we
use
it.
One
of
the
concerns
that
we've
heard
is
an
ALT
service
that
says
you
can
come
talk
to
me
over
H3,
but
when
you
resolve
the
hostname,
you
get
pointed
to
a
different
CDN
that
doesn't
support
H3
and
your
connect
fails
in
your
timeout,
which
is
not
great
big
slide.
E
Just
do
an
https
lookup
for
the
hostname.
Do
all
the
service
B
required
connection
stuff,
that's
in
the
https
spec
and
use
that
connection
instead
of
this
one.
So
we're
trying
to
move
you
over
to
a
different
endpoint
now
and
then
in
the
future.
Remember
what
endpoint
you
wound
up
on
and
give
that
some
preference,
when
you
do
future
https
resolutions
connecting
to
this
origin.
If
you
don't
see
that
endpoint,
oh
well,
you
just
go
on
with
what
DNS
says
and
you
forget
it.
E
And
this
does
leave
us
in
a
little
bit
of
a
situation
around
stickiness,
which
is
that
if
you're,
not
remembering
or
if
you
don't
have
that
endpoint
in
the
DNS,
all
the
time,
then
you're
going
to
go
to
origin
get
redirected
without
service.
The
next
time
around
you
go
back
to
the
origin
and
it'll
tell
you
to
go,
go
over
to
the
alternative
again,
so
you
might
wind
up
flip-flopping
unless
you
put
all
of
your
possible
endpoints
in
the
DNS.
E
But
if
you
remember
it
too
long,
then
you
override
the
ability
of
a
site
to
do
multi-cdn
or
otherwise
change
where
they're
pointing
you.
So
this
is
a
trade-off
that
we're
going
to
have
to
make.
Now
we
had
a
long
conversation
about
this
at
the
HTTP
Workshop
slide
and
we
had
over
the
course
of
that
long
conversation.
We
basically
redesigned
the
proposal
and
then
wound
up
right
back
at
the
proposal
that
was
submitted
because
everything
else
we
tried
didn't
really
work
out
or
had
some
some
conceptual
difficulty
that
made
us
drop.
E
F
G
E
Stickiness,
so
the
issue
about
stickiness
is
how
how
does
the
client
verify
that
the
information
it
has
cached
is
still
valid
for
an
old
service
that
potentially
has
a
very
long
long
time.
So
so
you
have
conflicting.
We
would
like
to
have
a
long
Lifetime
on
the
alt
service
advertisement,
because
we
want
you
to
remember
what
protocol
to
use,
especially
at
the
different
endpoint
when
you
come
back
on
a
future
connection,
but
on
the
other
hand,
load
balancing
happens
at
a
much
shorter
time
scale.
G
G
Yeah
one
thing
that
I
wonder
about
here
is:
should
we
just
make
this
stickiness
thing
a
like
general
property
of
of
the
https
record
of
service
bindings?
Like
you
gotta,
you
know,
you
tried
various
service
bindings
in
the
past
and
you
found
that
one
of
them
was
the
one
that
actually
worked
like
do
you
really
have
to
try
them
in
priority
order
next
time,
since
you
know
that
so
the
other
ones
didn't
work,
and
this
one
did
or
your
selection
algorithm
selected
this
one
last
time.
G
A
D
Yeah
so
I
wanted
to
make
clear
here
that
the
The
Proposal
from
the
the
design
team
that's
been
working
on
on
this
whole
service
thing
is
effectively
to
take
this
or
something
approximating
this
as
the
complete
replacement
for
Old
service.
So
the
draft
proposes
that
we
I
think
that
I've
got
to
use
the
right
words
now
obsolete.
D
D
There
are
some
suggestions
on
how
we
might
improve.
There
are
a
number
of
open
questions
that
we
have
Mike,
probably
didn't
touch
on
all
of
them.
The
more
interesting
ones
for
me
is
https.
Records
have
priority
order.
That
gives
you
some
control
over
where
people
end
up,
and
you
can
always
put
these
Alternatives
that
you
don't
want
people
to
use
as
the
primary
entry
point
to
your
service
down.
D
The
priority
list
on
your
https
are
assets
that
you
return,
but
maybe
that's
not
as
not
definitive
enough,
so
we
also
defined
an
attribute
on
on
each
one
of
them.
That
says,
don't
use
this
unless
it's
an
alternative
that
you've
been
told
to
use
explicitly
those
two
mechanisms
both
provide
you
with
some
amount
of
control
over
the
use
of
an
alternative,
we're
not
sure
if
we
need
those
things.
D
H
D
Post
it
to
the
mailing
list
and
if
they
don't
I
will
because
I
think
it's
an
interesting
idea,
but
we're
sort
of
trying
to
get
a
sense
of
the
general
shape
of
this
thing
to
see
if
people
are
interested
in
you
know
does
this.
Does
this
solve
your
problems?
We've
heard
from
a
number
of
people
that
simply
deprecating
old
service
and
relying
more
on
https
records
solves
their
problems
adequately,
and
they
don't
necessarily
need
this
thing.
D
D
I
Eric
knier
Apple,
so
I
just
wanted
to
reiterate
a
little
bit,
and
you
were
saying:
is
this
useful
for
people
and
so
I
thought
I
could
say
heck?
Yes,
it
is
so
we
we
strongly
prefer
getting
this
kind
of
information
from
DNS.
It's
much
nicer,
because
it's
for
the
place
that
you're
actually
going
and
it's
something
most
importantly,
that
you
know
up
front
at
the
time
that
you're
going
so
rather
than
saying
for
next
time.
I
So
that
much
is
awesome
being
able
to
take
https
records
and
say
these
are
lower
priority
and
have
a
separate
signal
for
do
not
use
this
in
less
houses
on
fire.
Both
of
those
signals,
I
think
we
find
are
super
useful
and
we
have
a
number
of
people
where
we
are
asking
them
to
do
that,
and
they
say
we
do
not
have
a
mechanism.
So
we
can't
do
that.
So
if
this
gives
them
that
mechanism,
then
like
both
of
those
unique
signals,
are
awesome.
I
J
E
You
it
probably
is
important
to
note
that
at
least
at
1
14
we
did
have
some
people
saying
they
didn't
want
the
ability
to
indicate
H3
with
a
header
to
go
away
entirely.
So
we
may
that
may
just
be
solved
by
okay.
You
can
use
the
obsolete
thing
if
you
really
have
to,
but
it's
important
for
us
to
remember
that
some
people
do
still
need
that
affordance
for
a
little
while.
K
Yeah
David
schenazi,
that's
pretty
much
exactly
what
I
was
going
to
say
and
just
to
explain
that
Chrome
and
other
web
browsers
today
don't
always
have
access
to
the
https
record
because,
like
apple
platforms
are
awesome
and
they
have
good
apis.
But
if
you
look
at
Posse's
cross-platform
get
Adder
info
gives
you
pretty
much
what
existed
at
the
time.
K
So
realistically
speaking
in
some
platforms,
where
Chrome
has
its
own
DNS,
resolver,
everything's,
fine
I
know
there's
some
people
at
ITF
weeping
that
the
applications
are
all
bundling
their
DNS
resolvers
now,
but
for
cases
where
we
don't
we'll
still
need
to
use
the
old
thing.
I,
don't
love
that
we're
obsoleting
the
old
thing,
because
it's
still
useful,
but
you
know
at
the
end
of
the
day
it
doesn't
really
matter
as
long
as
we're
on
the
same
page
that
we
might
still
make
changes
to
Old
service.
K
A
B
All
right,
this
is
a
question
for
David.
If
he's
still
up,
I
I
think
there's
some
comments
on
the
list
around.
Can
you
know
when
are
we
going
to
update
posix
get
at
our
info?
You
know,
I,
don't
think
that
functions
function.
Signature
is
going
to
change
at
any
point
soon,
just
to
confirm
I.
Imagine
people
would
probably
be
okay
with
a
separate
function
in
some
standard.
B
K
Yeah
well
David
schenazi,
Happy,
eyeballs,
Enthusiast
yeah,
like
in
practice.
It's
a
matter
of
time
at
the
end
of
the
day
like
and
resources.
Chrome
today
has
like
all
the
energy
like.
We
don't
have
a
huge
networking
team
as
we
used
to,
and
so
the
energy
goes
into,
the
client
DNS
like
I,
don't
work
on
Chrome
anymore.
The
the
energy
is
going
on
to
like
the
DNS
resolver.
That
is
bundled
with
chrome
and
the
like.
K
Cross-Platform
fallback
users
get
Adder
info
and
pretty
much
is
not
going
to
see
any
love,
probably
unless
it
becomes
like
a
pressing
issue,
so
give
an
infinite
time
totally
will
do
it.
It
makes
sense
it's
possible,
but
it's
in
Practical
things,
there's
always
another
shiny,
API
web
API
to
do
instead,
but
just
to
clarify
I
think
the
goal
is
to
ship
the
its
chromosome
resolver
on
all
platforms
and
that
kind
of
makes
this
go
away.
L
Lucas
sorry
I
didn't
use
the
tool.
My
phone
ran
out
no
recovery
from
that.
So
is
somebody
responsible
for
advertising
H3
and
wanting
to
work
and
being
involved
in
the
design
team.
I
support
the
shape
of
the
solution
that
we've
got
as
Martin
said
that
the
the
suggestion
on
GitHub
the
other
day
is
kind
of
interesting,
be
willing
to
see
where
that
goes
or
doesn't.
L
But
I
really
like
this,
because
I
don't
have
to
do
anything
like
I
would
support
this,
because
the
clients
need
to
do
some
things
and
change
stuff
and
we
already
do
HBS
records
and
it
would
all
kind
of
work
very
straightforwardly
but
I'm
not
in
a
humongous
rush
to
to
remove
the
old
service
header
tomorrow
or
or
whatever
like.
We
can
leave
it
there
and
it
has
a
place
for
me.
L
The
important
signal
here
is
is
for
people
who
who
are
suffering
now
with
the
the
problems
of
the
old
service
header
they're,
asking
us
to
try
and
find
Solutions
around
it
and
and
having
the
ITF
give
them
a
clear
signal
that
this
is
not
the
power
to
be
explored
for
future
Solutions.
But
it's
not
a
dead
end
either
in
the
sense
that
it's
going
to
be
turned
off
and
we're
never
going
to
speak
anything
and
you're
just
going
to
be
left
in
limbo,
with
no
way
to
use
H3.
That's
not
what
we
want.
D
Yeah
so
Mountain
Thompson
I
find
it
funny
sometimes
too,
when
we're
talking
about
lack
of
engineering
resources
at
Chrome
when
it's
often
the
other
way
around,
but
the
I
think
I
think
that's
the
transient
problem.
I
think
probably
the
more
pressing
one
is
the
availability
of
https
records
and
how
able
you
are
to
to
make
a
query
for
them.
We've
done
some
research
that
hopefully,
will
be
published
relatively
soon,
that
that
talks
about
the
success
rates
for
for
different
types
of
DNS
records
and
off
the
top
of
my
head.
D
D
It
was
more
like
45
for
our
DNS
Sac
related
Records
for
those
who
are
who
are
curious
about
those
sorts
of
things,
so
that
that
to
me
speaks
to
to
having
some
amount
of
https
sorry
alt
service,
Legacy
style
around.
It
may
be
that
we
want
to
encourage
people
to
to
start
shortening
their
max
age
on
that
side,
something
closer
to
this
sort
of
behavior
from
from
the
systems,
and
we
don't
run
into
the
sort
of
two
caches
problem.
That
was
a
major
issue
with
without
service
in
the
first
place.
D
D
A
E
E
E
E
Which
is
we
don't
use
them,
but
we
might
in
the
future.
So
then
there
are
four
flags
that
are
mandatory
to
understand
if
the
flag
is
set,
and
you
don't
know
what
it
means
ignore.
The
frame,
the
other
flags
are
not
mandatory
to
understand
if
they're
set
and
you
don't
know
what
they
mean,
shrug
and
move
on,
keep
using
the
frame,
as
you
understand
it,
so
we
have
those
in
H3.
We
would
have
no
way
to
set
them
if
we
ever
did
Define
them
in
the
future
next
slide.
E
E
D
D
K
David
dude,
it's
kanazi,
similar
to
Mt,
I,
think
yeah.
We
have
a
fourth
option,
which
is
Kick
the
Can
down
the
road,
we're
not
painting
ourselves
into
a
corner,
because
if
we
need
it,
the
correct
thing
is
the
frame
types.
We
have
one
extension
joint
that
we
should
grease.
Well,
we
don't
need
17
of
them.
So
just
say
we
don't
use
them
done.
Okay
and
sure,
maybe
I
won't
even
bother
deprecating
them
from
H2
like
just
don't
use
them,
don't
don't.
L
Accommodate
them
Lucas,
Lucas,
Pardo,
yeah,
so
I
created
the
issue
and
I
didn't
think
of
any
solutions.
For
it.
Sorry
I
forgot
I'd
opened
it,
but
it
was
in
a
fit
of
late
night
spec
reviewing
yeah
I,
don't
like
any
of
those
options.
I,
don't
think
we
should
change
H2
at
all,
so
I
agree
with
David
there.
Adding
adding
bites
and
stuff
just
seems
weird
I,
don't.
L
This
is
a
lot
of
the
time
with,
with
H2
and
H3
we're
trying
to
mitigate
kind
of
proxies
that
might
pass
through
frames,
even
though
you're
not
passing
frames
through
you're
reconstituting
them
from
their
parts.
Kind
of
thing.
Origin
is
a
bit
of
an
odd
one.
I,
don't
think.
There's
many
anyone
kind
of
passing
origin
across
multiple
proxies
like
that,
like
I,
don't
think
we
know
enough
about
the
problem
to
be
able
to
design
anything.
L
That
would
make
sense
and
not
complicate
stuff,
no
good
use.
So
if
we
want
to
Define
four
frame
types
that
just
basically
all
know
up,
so
it's
just
this
is
these
are
all
the
types
for
origin
in
H3
and
they're
all
the
same?
But
since
fine,
it's
not
it's
no
harder
to
write
that
code
than
for
one
type.
L
A
I'll
just
give
my
own
feedback
to
me
that
the
the
clearly
worst
option
here
is
the
last
one.
For
the
reason,
for
the
reason
you
point
out,
it
is
not
worth
doing
that
to
save
one
bite.
Okay,
but
it
sounds
like
we
might
be
converging
on
kicking
it
down
the
road,
giving
the
problem
to
a
future
us
and
closing
the
issue
with
no
action.
I
think
is
the
outcome
which.
A
E
E
F
E
A
E
A
M
Hello,
all
my
name
is
Stephen
bingler,
Google,
Chrome
and
I'll
be
going
over
a
status
update
for
6265
this
for
anybody
who
was
present
at
the
last
interim
meeting.
These
slides
are
going
to
seem
very
familiar
next
slide.
Please
so
there
hasn't
been
a
new
draft
since
actually,
that's
that's
not
true.
As
of
about
five
minutes
ago,
when
we
just
pushed
a
new
draft
but
I'm
going
to
talk
as
if
we
didn't
do
that
there
hasn't
been
a
new
draft
since
ITF
114.
M
These
are
the
underscore
underscore,
secure
and
underscore
underscore
host
Dash
cookies,
but
it
turns
out
that
servers
don't
always
check
cookies,
sent
case
sensitively,
because
of
course
they
don't
so
servers
were
setting
prefixes
without
realizing
that
they
weren't
getting
any
of
the
guarantees
from
browsers
and
that's
bad.
So
we
fixed
that
next
slide.
M
We
have
three
open
issues
currently
same-site
cookies
and
redirects.
Click
recap
on
this.
The
there
was
a
bug
in
the
original
spec,
where
same
site
did
not
take
the
redirect
chain
into
account.
So
if
you
redirected
from
site
a
through
site
B
and
back
to
site
a,
we
would
consider
that
same
site
and
happily
send
you
your
same-site
cookies,
that's
wrong.
The
spec
was
fixed,
but
when
Chrome
tried
to
launch
this
or
enable
this
feature,
we
got
a
ton
of
complaints
and
there
was
a
lot
of
site
breakage.
M
So
we
disabled
it
and
currently
trying
to
figure
out
next
steps,
we're
collecting
metrics
on
how
sites
are
using
this
Behavior
to
try
to
get
a
better
idea
of
what
to
do
with
it,
but
with
the
US
holiday
season,
approaching
I'm
expecting
I'm
not
going
to
get
anything
useful
until
until
q1,
the
other
two
open
issues,
internal
white
space
and
cookie
names
and
values.
This
was
recently
filed
turns
out
that
the
three
major
browsers
Chrome,
Firefox
and
Safari
all
handle
internal
tabs
somewhat
differently,
internal
tab.
M
M
What
this
means
is
that
now
the
spec
says
you
should
accept
those
internal
tabs,
but
not
all
browsers
do
so
I'm
trying
to
figure
out
if
that
change
to
the
spec
should
have
happened
and
whether
we
should
revert
it
final.
One
is
a
mouthful.
The
spec
should
more
clearly
advise
which
parts
a
reader
should
Implement
I
filed
this
one,
because
we've
had
a
number
of
issues
with
implementers
implementing
the
wrong
requirements
because
they
are
confused
on
what
they
should
do
and
I
can't
exactly
blame
them.
M
M
So
we've
already
have
some
work
plan
post,
RFC
6265
this
the
first
is
cookies
having
independent
partition.
State
Dylan
will
be
up
here
in
a
few
minutes
to
talk
in
more
detail
about
that.
The
second
one
is
Cookie
spec
layering,
originally
Johann
Hoffman
was
going
to
speak
on
that.
Unfortunately,
he
wasn't
able
to
make
it
so
I'm
going
to
say
a
few.
A
few
words
about
it.
M
Yep
I'm,
hitting
things
on
my
computer
here
so
cookie
layering
is
an
effort
being
headed
by
Johann,
Hoffman
and
Anna
van
kestron.
The
idea
is
that
the
cookie
spec
has
kind
of
intermingled
itself,
with
the
browser
specs
with
same
site
and
partition
cookies
and
blocking,
and
this
is
an
effort
to
sort
of
decouple
the
cookie
spec
from
things
that
could
be
better
handled
by
say
the
fetch
spec.
M
A
So
I
I
think
the
idea
here
is
you
want
to
close
those
three
issues.
Go
through
working
group
last
call
go
to
the
ITF
isgq
publication
process
and
then
we'll
we'll
talk
about
starting
almost
an
immediate
revision
again
to
address
your
your
deferred
issues
and,
and
these
work
items
is
that
kind
of
yes,.
A
And
the
cookie
spec
layering
and
there's
been
some
background
discussion
about
that
I
think
that's
we've
for
a
long
time
talked
about
how
to
make
the
the
cookie
spec
more
accessible,
more
user,
friendly
I
think
we
want
to
try
and
involve
non-browser
communities
as
well
to
see
where
the
right
line
is
to
draw
about
making
that
separation,
but
that
that's
a
discussion
we
can
have
I
think
that's
very
reasonable.
David
spanazi.
K
Hi
I'm
failing
to
find
the
issue
but
I,
remember
there
being
some
discussion
on
the
topic
of
utf-8
characters
and
it
just
allowed
characters
in
general
about
how
the
spec
allows
a
different
set
for
setting
cookies
than
for
sending
them
and,
like
I,
think
April
King
kind
of
found.
Some
issues
there
that
were
even
somewhat
were
worrisome
from
a
security
perspective.
Where
did
that
discussion?
Go
I
just
couldn't
find
it.
Sorry.
D
M
M
M
K
K
M
A
F
A
A
A
N
We
mean
that
these
third
party
cookies
would
only
be
available
on
the
top
level
site
in
which
were
they
were
created,
and
then,
if
the
user
were
to
navigate
to
a
different
top
level
site,
then
the
third
party
domain
would
receive
like
a
brand
new
cookie
jar.
Also,
this
is
like
a
forewarning.
This
talk
is
going
to
be
like
because
it's
partition
cookies
a
little
more
browser
heavy
than
some
other
like
talks.
So
if
that's
not
your
thing
feel
free
to
tune
me
out
slide.
N
So
the
partitioned
attribute
is
a
proposal
for
a
new
cookie
attribute
which
would
allow
sites
to
opt
into
this
Behavior
and
just
to
go
over
the
design
really
quickly.
It
would
require
secure
domains
would
be
allowed
up
to
10
kilo,
kilobytes
or
180
cookies
per
partition,
and
we
determine
how
much
memory
a
domain
is
using
per
Partition
by
the
size
of
the
name
and
value
of
the
cookies.
N
And
then
another
detail
is
that
clear
site
data
would
also
only
clear
cookies
in
the
current
partition
that
it
was
in,
and
this
would
be
to
prevent
cross
domain.
Entropy
leaks,
essentially,
there's
a
tax
you
could
set
up
where
you
intentionally
call
clear-site
data
on
different
top
level
domains
in
order
to
essentially
like
build
enough
cross-site
entropy
to
develop
a
like
persisting,
cross-site
identifier
slide.
N
N
N
This
is
kind
of
where
the
issue
arises.
Chrome
supports
both
unpartitioned
and
partition
cookies
at
the
same
time
and
uses
null
for
the
latter's
partition
key,
whereas
in
other
browsers,
as
soon
as
storage
access
API
is
granted
the
partition
key
for
that
context,
essentially
switches
to
that
first,
that
cookies
domain,
as
if
it
were
like
kind
of
originating
from
the
cookies
site.
N
And
so
the
question
is
how
do
we
handle
cookies
that
are
set
with
a
partitioned
attribute
in
these
contexts?
You
know:
do
we
set
the
partition
key
to
be
like
the
current
top
level
site,
which
is
what
we
are
proposing?
Is
the
right
answer,
or
do
we
just
use
like
whatever
the
current
partition
key?
Is?
N
Next
slide,
oh
and
then
one
more
note
about
that
asterisk
point
when
I
say,
like
Chrome,
supports
partition
and
unpartitioned
cookies.
At
the
same
time,
what
I
I
don't
mean
that
Chrome
will
like
continue
supporting
unpartitioned
third-party
cookies
into
the
future
posts?
It's
third
party
cookie
deprecation
timeline
just
wants
to
like
kind
of
clear
the
air
there
in
case
I
accidentally
store
any
fires,
and
so
moving
on
from
there
on.
N
The
next
thing
we
want
to
talk
about
is
whether
the
partition
key
should
have
what's
called
a
cross-site
ancestor
bit
and
I
think
the
best
way
to
explain
this
is
visually.
So,
let's
say
a
server
is
setting
a
partition
cookie
in
a
first
party
context,
where
the
request
domain
and
the
top
level
domain
are
the
same.
N
N
N
N
And
then
the
last
issue:
how
can
user
agents
convey
if
a
site
us
all
right?
How
can
user
agents
convey
if
a
request
comes
from
a
context
in
which
the
browser
would
only
accept
partition
cookies,
and
we
think
that
this
shouldn't
really
be
a
blocker
for
specking
partition
cookies?
This
is
kind
of
a
long-term
question
and
has
implications
Beyond
like
just
partition,
cookies
and
so
kind
of
our
solution
for
now
is
just
pump
this
down
the
line
next
slide.
N
Having
independent
partition
state
is
a
good
example
of
actually
how
iitf
might
benefit
from
cookie
layering,
because
essentially,
if
cookie
layering
happens
and
we
move
some
of
these
more
browser,
specific
things
into
the
fetch
spec,
then
really
all
the
ietf
needs
to
be
concerned
with
is
how
how
user
agents
parse
the
a
partition
token
in
the
cookie
line,
and
then
they
can
kind
of
let
the
fetch
spec
handle
the
rest
of
the
partitioning
Behavior
and
that's
it.
So
anyone
has
any
questions,
feel
free.
A
So
I
think
from
a
process
standpoint
here
when
we
talked
about
adding
major
new
features
for
6265
bits,
we
had
a
relatively
rigorous
process
for
getting
consensus
around
here's
a
proposal
with
a
draft.
Does
the
community
want
to
add
that
to
6265
scope,
and
so
this
is
probably
too
late
for
62.65.
This
and
I.
Don't
think
that's
a
surprise
to
you,
which
is
good,
and
the
question
is
you
know
when
we
do
this
next
revision
that
we
were
just
talking
about
you
know,
are
we
going
to
use
a
similar
process?
A
And
if
so,
you
know
what
would
our
folks
interested
in
taking
this
on
as
as
a
piece
of
work
and
as
before,
I
think
you
know
in
in
6065
original
as
well
as
this
we
kept
the
focus
very
firmly
on
implementer
intention,
and-
and
so
you
know,
folks
who
have
cookie
jars
they're,
not
the
only
people
who
matter,
but
they
do
really
matter
to
this
discussion.
So
that's
who
at
least
we
we
should
hear
from
Martin.
D
Yeah,
so
during
my
Mozilla
hat,
but
the
Privacy
CG
chair
and
w3c
that
that
group
has
pretty
broad
support
for
this
work
and
would
very
much
like
to
see
the
work
proceed
and
I
I
think
we
have
agreement
also
that
the
ITF
is
the
right
place
to
do
that,
because
the
ITF
owns
the
cookies
back
and
it
doesn't
make
any
sense
to
put
it
anywhere
else.
I
I
think
we're
willing
to
be
guided
by
everyone
else
in
terms
of
timelines
and
whatnot,
and
it
very
much
seems
like
this.
D
D
I
think
this
is
probably
something
that
I
would
sort
of
advocate
for
some
sort
of
signal
that
it's
working
in
the
ITF
process,
so
I
sort
of
would
prefer
if
this
were
adopted
here,
perhaps
parked
on
the
side,
so
that
we
can
continue
to
work
on
it
and
refine
it
and
answer
some
of
the
interesting
questions
Dylan's
asking
here,
but
not
block
other
important
work.
That
would
be
my
preference
here.
A
N
O
There's
maybe
sort
of
a
naive
question,
but
can
you
explain
a
little
bit
more
the
rationale
for
providing
this
at
all
versus
the
the
browser
just
making
its
own
decisions
about
how
it
will
partition
or
not
partition
that
it?
It's
always
felt
to
me
like
it's
a
a
question
of
how
the
behavior
of
the
client
itself
the
browser
or
whatever
behaves
and
putting
it
onto
the
wire
and
part
of
the
cookies
back,
it's
hard
hard
to
articulate
it
more
than
that,
but
referring.
O
Like
yeah,
okay,
yeah,
like
at
least
it's
my
understanding
like
Firefox
Mozilla,
basically
partition
cookies
right
or
has
the
opportunity
to
partition
cookies
in
their
client,
and
they
just
did
it.
They
partitioned
them
top
level
domain,
lower
level
domain.
It
just
sort
of
happens
so
bringing
this
into
a
spot
trying
to
give
servers.
The
opt-in,
behavior
is
never
quite
I've,
never
quite
understood
the
the
rationale
or
the
motivation
behind
that,
and
it
almost
feels
simpler
to
not
to
just
allow
it
to
continue
to
be
a
behavior
that
the
the
client
decides
on.
N
At
least
Karma's
philosophy
on
this
is
that
we
want
to
encourage
this
to
be
like
an
opt-in
Behavior,
at
least
in
the
time
between
now
and
when
on
partition.
Third-Party
cookies
are
turned
down,
and
the
reason
being
is
that,
like
a
lot
of
servers,
rely
on
third-party
cookie
functionality
for
various
things,
some
of
that's
cross-site
tracking,
which
we're
not
okay
with,
but
then
some
of
it
are
some
use
cases
that
we
are
okay
with
and
in
this
sort
of
transitory
period,
where
we
move
off
of
third-party
cookies.
N
We
think
that,
like
providing
this
attribute,
and
this
opt-in
Behavior
provides
developers
with
an
opportunity
to
kind
of
migrate
their
systems
over
to
this
partitioned
World.
You
know
before
we
just
completely
kind
of
take
the
rug
out
from
under
them
and
remove
on
a
partitioned
third-party
cookies.
O
Again,
I
apologize
for
I'm,
not
fully
understanding,
but
in
terms
of
compatibility
it
always.
It
feels
like
there's
cases
that
are
going
to
break
then,
if
you're
expecting
third-party
cookies,
that
will
otherwise
work
in
a
partition
context
and
you're
not
opting
into
them
so
like
a
server
that
you
know,
does
whatever
it
does
in
a
in
a
frame
or
something
and
continues
to
get
set
cookies
get
cookies
as
they
would.
O
You
partition
those
it
doesn't
know
the
difference
in
terms
of
How
It's
behaving,
but
if,
if
suddenly
it's
changed
such
that
you
have
to
opt
in
with
their
or
partition
cookies,
then
that
would
I
believe
stop
working
with
unless
you
make
the
migration.
So
it
feels
like
that
area
is
not
compat,
at
least
not
in
the
way
that
I
think
about
it,
be
a
breaking
change
and
require
software
updates
to
well
continue
working.
N
I
think,
like
kind
of
at
some
point,
there
is
a
breaking
change
that
needs
to
be
made
either
it's
like
removing
third-party
cookies
entirely
or
it's
just
partitioning
them
by
default.
So
at
some
point
we're
going
to
be
breaking
sites.
I
think
it's
just
like
a
matter
of
difference
on
sort
of
how
we
want
that
breakage
to
occur.
N
You
know
the
the
server
getting
the
lack
of
cookie
back
once
we
do
turn
down.
Third
party
cookies
is
a
signal
that,
like
it's
not
working
as
intended
versus
having
the
user
agent
just
sort
of
like
change
the
behavior
of
the
cookie
from
underneath
the
site
without
really
giving
it
any
indication
that
that's
what's
going
on
is
like
kind
of
just
as
bad.
In
our
opinion,.
N
D
So
Martin
Thompson,
this
has
been
debated
at
length
in
other
forums,
and
it
was,
it
was
a
the
consensus
view.
I
think
was
that
that
blocking
blocking
cookies
in
these
third-party
context
was
the
desirable
outcome.
It
was
not
necessarily
unanimous
that
that
was
the
the
outcome
there
were.
There
were
a
number
of
reasons,
the
ones
that
Dylan
articulated
for
doing
it.
D
A
A
A
F
O
L
Hello
Lucas,
it's
here,
yeah
I,
just
had
a
blast
of
the
draft.
Like
you
say,
loads
of
these
are
just
really
low-key.
There's
a
little
things
you
can
pick
and
tidy
up,
but
it
got
caught
in
some
other
reviewer,
some
other
editorial.
Like
I
say
we
disagree.
That's
okay,
you're
the
editor.
If
you
want
to
do
it
that
way,
that's
that's
your
discretion.
So
just
just
wanted
to
give
some
kind
of
contrast
and
feedback,
so
that
in
case
you
didn't
think
of
it
that
way
so
I'm
happy.
However,
we
resolve
them.
O
L
L
P
O
P
C
O
P
So
there
are
all
kinds
of
like,
obviously
you
don't
design
protocol
standing
on
one
foot,
but
like
the
the
easy
or
not
the
easy.
There
seems
to
be
an
obvious
way
of
trying
this
with
sort
of
exported
authenticators
or
like
some
kind
of
certificate.
That's
actually
bound
to
the
TLs
connection,
and
then
you
just
pass
through
a
proof
that
the
the
the
terminating
proxy
controls
this
particular
session
and
that
that
particular
scientist
client
had
signed
that
particular
session
like
to
prevent
it
mismatching
and
swapping
and.
A
So
that
was
discussed,
some
I
think
when
we
talked
about
adoption
and
the
place
we
ended
up
at
was
that
this
is.
The
intention
of
this
draft
is,
is
to
standardize
existing
practice
within
the
bounds
of
of
described.
Thank
you
existing
practice
and
and
align
on
a
single
header,
because,
frankly,
a
lot
of
reverse
proxies
and
cdns
already
do
this,
and
and
so
that
that's
one
of
the
reasons
it's
informational,
because
we
don't
want
to
put
too
strong
of
a
recommendation
behind
that,
realizing
that
there
are
better
Solutions.
A
A
O
A
A
A
K
Hello,
everyone
David
scanazi,
mask
enthusiast,
big,
surprise,
I
know
so
the
chairs
of
HTTP
reached
out
and
asked
if
someone
from
Mass
could
just
give
an
update
to
the
HTTP
working
group
about
whatever
the
hell
is
going
on
in
mask,
because
it's
totally
different
people,
sometimes
mostly
the
same
people
but
not
everyone
knows,
and
some
people
might
care
and
they
don't
know
next
slide.
Please.
K
Geez,
that
is
slow,
so
what
is
mask
so
the
acronym
is
multiplexed
application
substrate
over
quick
encryption,
which
is
quite
a
mouthful.
We
came
up
with
the
name
back
in
2018.
It
was
quite
unfortunate
that
there
was
then
a
global
pandemic
for
actually
more
reasons
than
this,
but,
but
so
now
everyone
Associates
it
with
a
covet
mask,
but
that's
not
what
we
were
going
for
anyway.
K
So
just
kind
of
a
quick
history
lesson
here
back
in
the
good
old
days
of
HTTP
before
they
had
this
thing
called
SSL
like
bandwidth
was
expensive
and
people
will
building
cash
servers,
especially
if
they
were
on
other
continents
where
things
were
really
really
far
away.
Now
we
call
them
intermediaries,
and
then
there
was
the
idea,
like
an
Enterprise
or
School
networks,
that
you
would
intentionally
go
talk
to
that
terminatory
because
it's
getting
stuff
to
you
faster,
because
it's
already
has
it
cached.
K
That
was
you
know
in
what
we
call
Web
1.0
these
days,
because
everyone
was
loading
the
same
thing,
so
you
could
cache
it
and
nothing
was
encrypted,
but
then
eventually
SSL
happened
and,
as
usual,
the
security
people
ruin
everything
for
everyone
by
making
things
safer
and
not
working
anymore,
and
so
people
had
to
deployed
these
boxes
and
were
saying
no.
If
you
want
to
reach
the
internet,
you
have
to
go
through
our
HTTP
proxy
because
that
reduces
our
internet
bill.
K
K
K
K
So
let's
just
do
connect
for
UDP,
so
let's
call
it
connect
UDP,
and
then
we
got
to
arguing
for
about
three
years
on
how
exactly
to
do
that
and
you
end
up
with
a
solution,
that's
kind
of
as
simple
as
you
would
imagine
where
you
take
the
UDP
and
you
put
it
in
in
the
packet
and
you
send
it.
So
we
got
that
published
a
few
months
ago,
which
was
really
nice
fun
time
and
because
we
had
to
have
quite
a
few
bike
sheds.
K
We
decided
to
split
the
baby
in
half,
so
there's
one
RFC
for
proxy
UDP
and
HTTP,
and
one
RFC
that
it
depends
on
which
is
HTTP,
datagrams
and
also
the
capsule
protocol,
because
we
didn't
couldn't
come
up
with
a
better
name
than
capsule,
so
HTTP
datagrams.
The
idea
is
that,
in
addition
to
your
regular
HTTP
stream,
which
is
a
concept
that
we've
had
since
HTTP
2,
you
can
send
datagram
for
little
bits
of
data,
and
that's
really
handy
if
you
want
to
send
UDP,
you
just
put
them
in
there.
K
The
really
reason
for
that
this
exists
is
that
you
can
then
map
it
to
a
quick
datagram
frame
which
doesn't
get
retransmitted,
which
is
exactly
what
you
want
for
connect2db,
because
if
you
put
it
inside
the
stream,
you'd
get
bad
performance
and
the
capsule
protocol
that
I
mentioned
was
something
that
we
thought
would
be
useful.
A
it's
useful
for
like
HTTP
one
and
two
or
you
don't
have
the
quick
data
grab
frame
and
it's
also
useful
for
other
things
or
more.
K
We
wanted
it
for
that
and
we
said
well,
let's
toss
in
a
tlv,
so
it's
extensible.
We
have
some
use
cases
for
it,
so
it
allows
you
to
send
something
all
the
way
through
all
the
intermediaries
reliably,
and
so
those
were
our
first
deliverables
here,
I've
seen
shipped
a
few
months
ago,
we
are
working
now
on
proxying,
IP
and
HTTP.
K
We
had
a
whole
nice
fun
detour
on
writing
a
requirements
document
for
that,
first,
which
I
was
kind
of
annoyed
at
Mark
when
he
suggested
that
at
that
first,
but
he
made
a
point
that,
like
oh
you're,
not
actually
all
agreeing
on
what
you
mean
by
proxying
IP,
and
you
were
right.
So
we
ended
up
arguing
on
the
requirements
document
instead
of
arguing
on
the
discussion
on
the
solution
document,
but
at
least
when
we
went
to
build
the
solution,
we
knew
what
we
were
going
to
build.
K
K
K
Well,
sometimes
it's
nice
to
be
able
to
run
over
networks
that
block
qdp,
so
putting
it
out
of
http
means
you
have
access
to
http
one
and
two
I,
really
like
the
fact
that
if
you
put
it
over
HTTP,
then
it
starts
looking
like
web
traffic,
so
it
makes
it
really
harder
to
block.
So
now
you
have
a
VPN
that
looks
like
web
traffic
hard
to
censor
I
like
that.
Don't
say
that
some
people
don't
like
that.
K
Another
part
that
I
hadn't
thought
of
at
all,
but
that
we
realized
was
companies
like
Google,
have
already
put
in
a
lot
of
effort
in
having
a
really
good
HTTP
server,
and
so
a
quick
stack.
That's
efficient
and
security
reviewed
and
HTTP
HTTP
load
balancers.
And
if
you
build
this
over
HP,
you
kind
of
get
to
reuse
all
of
this
for
free.
So
we
end
up
like
in
places
where,
like
oh,
can,
we
use
ipsec
and
people
were
like
no
we'd
have
to
review
that
whole
new
stack
and
we
don't
want
to.
K
Can
you
just
find
a
way
to
make
it
work
over
quick
and
then
there's
a
fun
story
there,
where
Alex
and
others
back
at
Google
actually
implemented
a
VPN
over
quick
way
before
the
mask
effort
and
was
kind
of
the
Catalyst
for
the
whole
thing,
and
then
we
are
closing
the
loop
on
making
that
use
mask
now,
which
is
fun
and
then,
when
we
built
this
folks
that
like
to
use
buzzwords
like
zero
trust
and
other
things
that
and
serverless
and
things
that
I
don't
understand
said.
Oh,
this
is
great.
K
Can
I
use
this
too,
and
they
were
apparently
much
the
problem
they
had
was
they
had
VMS
in
the
cloud
somewhere
that
needed
to
talk
to
each
other,
but
there
were
HTTP
load
balancers
in
the
middle
and
they
wanted
magic
crypto
and
we
said
well.
Actually
they
had
built
something
using
connect,
because
that
was
the
simplest
thing
for
them,
and
then
they
had
a
customer
who
wanted
UDP
so
boom.
This
actually
works
for
there,
like
reusing
stuff,
is
useful.
Next
slide.
K
So
where
are
we
going
from
here?
The
mass
working
group
was
very
tightly
scoped
to
make
sure
we
didn't
get
too
distracted
and
to
make
it
to
kind
of
get
us
to
focus
on
shipping
connect2dp
and
connect
IP,
but
now
that
we're
almost
done
with
that
we're
talking
about
a
sculptory
chartering
for
future
things.
So
that's
also
on
our
agenda.
K
We
don't
I,
don't
I,
don't
think
the
current
plan
from
what
I
hear
far
on
my
isg
overlords
is
that
they
don't
want
to
mask
maintenance
working
group
that
lasts
forever,
we'll
just
re-charter
for
a
few
scoped
extensions.
Do
those
and
then
potentially
shut
it
down
and
say
future
things
happen
in
the
HTTP
working
group.
We'll
have
to
discuss
those
things.
It's
not
entirely
figured
out,
but
I
guess
that's
what's
going
to
happen,
but
what
are
the
extensions
that
we've
been
discussing
that
might
happen
before
then?
So?
K
First,
we
have
extensions
to
connect
UDP,
so
connect
UDP
is
similar.
Connect
kind
of
gives
you
a
connected
five
Tuple.
But
if
you
want
to
do
something
like
webrtc,
where
you're
talking
to
multiple
hosts
you're
one
proxy,
it
doesn't
work
for
that.
So
we
have
a
little
extension
for
for
doing
that.
We
have
an
extension
for
doing
quick
over
connect
GDP,
you
can
run
quick
over
connect2dp
non-extended,
but
Tommy
had
some
clever
ideas
on
how
you
can
optimize
that
and
make
it
better.
K
We
have
extensions
kind
of
at
the
HTTP
datagram
layer,
Marcus
and
Erickson
folks
have
an
idea
for
adding
sequence
numbers
to
catch
reordering
when
they're
doing
multi-path
quick,
there's
an
extension
from
Ben
about
having
a
way
to
figure
out
your
path,
MTU
through
the
entire
chain
between
your
client
and
your
endpoint.
So
that
way
it
makes
it
easier
to
run
protocols.
Unlike
quick,
they
can't
do
it
themselves.
Lucas
has
a
draft
about
priorities
in
HTTP
datagrams
that
he's
very
excited
about
next
slide.
K
Please,
and
we
have
some
generic,
like
other
HTTP
extensions,
that
the
authors
were
thinking
like
mainly
in
the
context
of
mask,
but
could
also
be
applicable
to
other
HTTP
use
cases.
So
we
haven't
selected
the
view
in
a
venue
like
all
this
feature,
work
that
I'm
talking
about
is
individual
drafts.
So
Tommy
has
something
about
sending
more
DNS
information
as
using
the
recently
published
proxy
status.
Header
and
Ben
has
documents
on
describing
what
mask
services
and
HTTP
origin
has
and
on
modernizing
connect
itself.
Next
slide.
K
A
F
A
A
A
I'm
prompted
in
principle,
I,
don't
have
a
problem
with
that.
I'm
just
worried
that
somebody
who
was
expecting
it
on
Friday
might
be
a
little
surprised
by
that.
But,
of
course,
there
is
always
the
mailing
list
where,
if,
if
we
do
adopt
something
or
whatever
it'll
make
these
senses,
so
as
long
as
whatever
happens
goes
to,
melon
must
I
think
yeah,
which
it
would
yeah
I,
think
so
sure
any.
A
K
Know
we
have
a
mask
for
that,
there's
a
better
way
to
phrase
that
I'm
sure
all
right,
hello.
It's
me
again,
David's
kanazi,
HTTP
Enthusiast,
so
this.
So
this
is
a
draft
that
was
initially
part
of
the
original
Mass
proposal.
So
this
is
actually
not
a
bad
segue,
and
people
gave
me
very
good
advice
at
the
beginning
that
you
don't
merge
everything
into
a
big
castle
in
the
sky
and
otherwise
it
doesn't
work.
K
You
split
it
up
into
small
bits
that
makes
sense,
and
so
this
was
one
of
those
that
then
went
dormant
as
we
were
all
focusing
on
mask
itself,
and
now
people
reached
out
that
were
interested
in
it
and
I'm
trying
to
resurrect
it
and
see
where
we
want
to
go
with
it.
So
this
now
we
have
multiple
co-authors.
This
work
is
joined
with
David
Oliver,
who's,
I
think
attending
virtually
this
time
and
Jonathan
who's
right.
There
next
slide.
Please.
K
So
the
the
draft
initially
was
called
transport
authentication,
and
the
reason
for
that
was
that
the
original
mask
proposal
was
I.
Think
the
term
is
monstrosity
in
terms
of
HTTP
semantics
because
it
took
over
the
whole
connection
and
did
things
that
were
very
evil
by
HTTP
standards
and
so
the
new
version
of
masks,
as
we
talked
about
fits
into
HTTP
semantics,
but
because
of
this,
the
old
version
needed
a
way
to
authenticate
the
whole
transport.
K
K
We
want
to
use
asymmetric
cryptography
because
there
are
some
use
cases
where
you
want
to
be
able
to
share
the
like
access
list
with
their
public
Keys
across
multiple
Origins
that
don't
necessarily
trust
each
other,
and
you
want
to
avoid
having
an
Argent
be
able
to
impersonate
one
of
the
clients
and
then
the
third
requirement
is
we
want
the
server
to
hide
the
fact
that
it
serves
authenticated
resources.
So
what
I
mean
by
that
is?
K
If
you
try
to
get
this
resource,
you
don't
want
a
server
to
send
you
a
401,
and
the
reason
for
that
is.
Let's
say
you
have
your
personal
website,
but
you
want
to
offer
some
mask
services
to
authenticated
clients.
You
don't
want
someone
to
be
able
to
probe
your
server
and
go.
Oh,
no!
No!
That
offers
Mass.
That's
blocked
on
my
network,
bang,
bang!
K
Yes,
so
not
that
it
is
serving
so
yeah.
Let
me
rephrase
that
I
guess
that's
not
very
well
written.
Let's
say
that
the
the
server
offers
a
resource
to
only
authenticated
clients.
That's
a
common
thing
and
an
unauthenticated
client
must
not
be
able
to
find
out
whether
that's
the
case
or
not.
So
it
can't
probe
the
server
to
find
out
that
the
resources
there
you're
just
not
allowed
to
see
it.
K
So
the
why
don't
we
already
have
this
in
our
very
large
suite
of
HTTP
authentication
methods?
So
if
you're
doing
cryptography
and
you're
using
a
signature,
you
need
something
to
sign
and
you
need
that
to
be
fresh.
Otherwise,
this
is
things
are
replayable,
so
in
common
protocols
today,
the
way
we
do
that
is
the
server
sends
announced
the
client
signs.
K
That
nonce
sends
the
signature
back
and
the
server
goes
great,
that's
fresh,
but
that
breaks
our
requirement
of
the
server
not
letting
on
that
it
does
this,
because
if
it
sends
a
nonce,
you
go,
oh
I
got
an
answer
from
you.
I
know
you
all
you
you
support
this
scheme,
so
hoba
is
a
is
a
means
that
that
does
that,
for
example,
that's
already
standardized,
but
that
leaks
the
fact
that
the
server
does
this
next
slide,
please.
K
K
The
I'm
blanking
on
the
name,
Channel
binding,
use
that
as
well,
but
we're
not
doing
Channel
binding,
very
different,
but
like
just
that
same
idea
of
using
a
key
exporter
not
to
generate
a
key,
but
just
to
use
it
as
a
nonce.
So
that
doesn't
link
any
information
because
any
side
can
export
the
key
locally
and
it
can
be
replayed
either
empty.
D
I,
don't
know
if
you've
thought
about
this
one,
but
it
it's
possible
that
in
certain
contexts
say
like
web
browsers,
an
adversary
might
be
in
a
position
to,
for
example,
make
requests,
and
this
only
prevents
the
authenticator
from
being
moved
to
another
connection
that
doesn't
prevent
it
from
being
reused.
On
the
same
connection,.
D
K
This
is
the
attack
we
discussed
this
at
the
at
the
last
ITF
and
so
Jonah
Jonathan
and
I
thought
about
it
for
a
bit
and
that's
a
real
Attack.
If
you
leak
that
you
sent
a
header
with
this
on
one
request,
you
could
put
that
on
another
request,
but
the
threat
model
there
is
an
attacker.
That
kind
is
already
like
inside
the
TLs,
and
so
we
decided
like
that,
wasn't
practical
in
practice.
So
we
added
a
paragraph
to
security,
consideration
saying
that
that
was
out
of
scope,
but
it's
a
real
Attack
as.
K
K
K
So
the
the
advantage,
if
you
you
have
the
same
thing,
is
that
then
it
gets
compressed
by
each
pack
or
qpac,
and
we
thought
that
was
a
nicer
benefit
than
this
attack.
I
mean
that's
totally.
We
can
go
either
way
both
work.
It's
a
it's
a
you
know:
security
versus
performance
trade-off,
as
we
often
have
Alex
sorry.
H
Yeah
I
I,
Alex,
fromowski
Google
I
just
wanted
to
add
that
I
also
previously
brought
up
a
similar
thing
around
the
fact
that
this
was
a
connection
oriented
export
and
it
really
did
weird
things
around
streams,
so
like
I,
think
if
we
Incorporated
Martin's
idea
about
making
it
be
request
or
stream
oriented
somehow
it
would
also
make
it
clear
that
this
wasn't
a
shared
resource,
so
maybe
somewhat
repeatable,
but
not
100.
Repeatable,
like
URL,
is
definitely
a
nice
one.
That
would
still
get
you
some
of
the
compression
yeah.
K
K
So
we
went
with
this
at
least
it's
clear
about
what
it
is.
The
server
doesn't
tell
the
client
that
it
needs
to
authenticate
the
client.
Does
it
without
being
prompted
and
it
indicates
a
single
request
and
you
send
what
kind
of
authentication
so
signature
hmac
and
then
which
algorithm
like
for
a
signature,
algorithm
or
hash
algorithm
you're
using
so
initially
we
use
the
IDS
and
Mt
found
that
gross
so
I
grabbed
something
from
the
Ina
registry
and
I
managed
to
get
that
wrong
too.
K
K
I'll
I'll
get
back
to
that
in
terms
like
we
kind
of
discussed
this
with
the
client
search
idea.
Similarly,
this
can't
be
transparently
forwarded
because
it
pertains
to
the
TLs
connection,
so
the
intermediary
checks
it
and
then
tells
Upstream
what
the
result
was
that
part
we've
declared
it
out
of
scope.
You
could
build
something
like
the
the
previous
presentation
if
we
wanted
to,
but
I
don't
have
a
use
case
for
that.
So
we
decided
it's
out
of
scope
of
this
draft
for
now
and
it
can
be
built
separately
next
slide.
K
So
what
we
changed
since
last
time,
because
we
got
some
pretty
good
feedback
when
we
presented
this,
so
we
renamed
the
draft
we
removed
the
oids.
We
added
the
security
concerns
to
discuss
this.
The
issue
that
we
just
talked
about
Jonathan
joined
as
co-author
to
make
sure
that
I
stopped
shooting
my
toes
off
security
wise
and
we
switched
to
structured
Fields.
Maybe
I
got
it
wrong
again:
I'm
an
HTTP
Enthusiast,
not
an
expert,
but
I
tried
to
switch
to
structured
Fields,
because
I
hear
they're
all
their
age.
K
So
we
have
an
independent
implementation
by
The,
Guardian
Project,
so
multiple
entities
kind
of
interested
in
this
we're
wondering
is
it.
The
HTTP
is
working
group
interested
in
seeing
this
progress
here.
Should
we
take
it
elsewhere?
What
do
people
think?
Is
this
completely
insane?
Is
this
a
good
idea?
Do
other
people
find
it
useful
any
thoughts,
questions?
This
is
my
last
slide,
so
come
on
up
Mike.
K
E
But
more
broadly
written,
yes,
I
think
this
is
of
interest.
It's
it's
a
useful
property
and
there
are
already
HTTP
servers
that
will
refuse
to
admit
a
resource
exists
unless
you're
authenticated.
They
just
have
some
other
endpoint
that
you
off
to
first.
So
this
would
be
a
nice
Improvement
in
security
for
them.
G
Thanks
for
helping
me
understand
a
bigger
piece
of
it,
I'm
closer,
but
the
thing
that
I'm
most
confused
about
is
this
the?
If
we
assume
that
there
is
no
indication
that
a
given
origin
supports
this,
then
client
presumably,
must
be
configured
out
of
band
with
information
to
know
that
it
can
use
this
mechanism
with
this
origin.
G
But
any
mechanism
that
could
configure
this
client
to
know
that
about
this
origin
could
have
just
provided
this
client
with
a
per
origin
symmetric
secret,
a
password
that
would
allow
that
the
client
would
send
unprompted
unprompted
authentication
yes
to
that
server.
But
this
would
not
authenticate
the
client
right.
This
would
just
reveal
the
client
as
being
among
the
set
of
clients.
That
knows
this
information
about
the
server
and
then
the
server
can
respond
with
a
challenge.
We
can
go
through
standard
challenge
response
authentication.
So
why
didn't
you
do
that?.
K
So
it's
the
general
question
about
shared
cryptography
versus
or
symmetric
cryptography
with
versus
asymmetric
cryptography
and
yeah.
Pretty
much
almost
everything
that's
done
with
asymmetric.
You
could
do
it
with
symmetric
and
N
keys,
but
then
you
kind
of
have
to
tie
the
list
of
potential
Origins
with
the
keys
and
you
get
like
a
bad
scaling
problem,
whereas
here
you
can
get
the
keys
once
and
then
later
over
time
get
the
origin
simpler.
So
it
gives
you
like
more
flexibility,
I
mean
there's
yeah.
G
I'm
I'm
not
convinced
that
it
actually
provides
that
kind
of
efficiency
Improvement.
In
this
case,
because
again
you
need
to
be
provisioned
out
of
band
with
this
information
about
each
origin
that
you
could
potentially
contact,
and
so
you
already
have
and
the
clients
are
already
being
provided
with
with
order
and
information
here,
adding
passwords
on
top
of
that
doesn't
increase
the
the
order
of
information.
G
That's
required
to
be
shared
with
clients,
and
if
you
want
this
kind
of
shared
cross-origin
authentication
of
clients
where
clients
use
a
single
credential
across
or
all
of
these
Origins,
you
can
still
do
that.
You
no
longer
have
to
do
it
within
an
unprompted
context.
For
example,
you
can
do
it
in
a
hoba
context,
and
then
you
don't
have
to
worry
about
this
thing
of
like
I'm
bound
to
the
TLs
session.
I
can't
Traverse
intermediaries,
you
know
I'm
doing
Channel
bind
foreign.
K
G
Well,
so
I'm
I'm
telling
you
that
you
don't
need
it
like
Guardian,
Project,
I'm,
very
familiar
with
their
use
case.
They
do
not
like
the
system
I'm
describing
is.
Is
their
system
like?
That's
that's
how
it
already
works.
That's
how
the
the
bridge
distribution
system
is
is
already
defined,
so
I
think
look
I!
Think
if
there's
an
advantage
here,
I
could
argue
that
it
like
it
saves
a
round
trip
like
it
avoids
the
need
to
sort
of
pre-authenticate,
and
then
you
know
and
then
actually
authenticate
as
a
as
a
second
step.
G
You
can
do
it
in
one
go.
Maybe
that's
important
in
some
use
case,
but
I'm
not
actually
aware
of
again
of
a
use
case
where
that
efficiency
gain
would
matter,
and
so
I
think
that
basically
there's
a
more
flexible,
less
complicated
solution
here,
I
think
we
should
solve
the
problem,
but
I
I'd
like
to
see
this
a
little
more
strongly
motivated
for
this
design.
K
G
J
K
So
from
memory
it's
been
a
while,
since
I've
done,
I've
looked
into
that
I
well,
I
mean
one
problem.
Is
it's
it's
more
complicated
machinery
and
it's
at
the
TLS
layer,
I.
Well,
of
course
it's
at
the
TLs
layer,
but
for
I
don't
know
if
it
has.
The
property
of
client
speaks
first
or
directly
tied
to
a
request.
J
So
the
standard
way
of
doing
token
binding
does
involve
a
negotiation
at
the
TLs
layer,
but
I
think
that
could
be
emitted
and
get
the
property
that
you
have
here
in
effectively
the
same
way
where
the
client
would
derively
ekm
from
the
TLs
connection
and
then
create
a
signature
of
it.
Put
in
the
token.
K
Playing
header,
so
I
would
have
to
double
check
from
memory.
There
was
a
lot
more
involved
in
token
binding
and
the
interactions
with
the
TLs
layer
that
made
it
quite
a
more
complicated
beast
and
would
be
harder
to
just
have
like
a
little
token
that
you
send
I.
Can
that's
a
reasonable
question.
I
can
give
you
a.
Let
me
do
some
research
I
can
give
you
a
better
answer,
because
it's
been
a
while
since
I've
looked
into
token
by
Nick.
A
Would
be
great
yeah,
so
so
without
making
any
commitments
or
saying
that
yes,
we'll
drop
something
or
that
you're
going
to
implement
it.
Just
a
show
of
hands
online,
as
well
as
in
the
room.
I,
don't
know
how
it
works
online,
but
we'll
sort
stuff
out
who's
interested
in
continuing
this.
This
discussion
that
there
might
be
something
here.