►
From YouTube: IETF103-TOKBIND-20181106-0900
Description
TOKBIND meeting session at IETF103
2018/11/06 0900
https://datatracker.ietf.org/meeting/103/proceedings/
A
B
A
At
least
that's
what
my
my
coke
says,
so
it
must
be
true.
So
let's
hear
you
alright,
since
it's
the
first
session
of
the
morning,
let's
just
take
another,
take
an
extra
couple
of
seconds
to
look
at
the
note
well
and
remember
what
it
says:
your
cap,
your
subject,
I
see,
are
the
ITF
IB
origin,
while
you're
participating
in
this
working
group.
Alright,
this
our
agenda
and.
A
A
Alright,
and
if
the
working
group
is
okay
with
letting
Nick
talk
about
zero
RTT
and
say
that's
one
point
three
I
guess
before
Brian
and
other
items
because
he
actually
has
to
be
an
HTTP
as
well
or
sorry
in
and
in
them
also
patreon
yeah.
Alright,
do
you
want
to
start
there
at
with
zero
TT?
Oh
let's
do
that
then
sure
we
got
them
all
queued
up
here.
C
A
D
A
D
So
for
0tt
with
token
binding,
as
you
may
know,
there
was
previously
a
working
group
draft
on
this.
That
has
since
expired.
The
chairs
have
asked
me
to
just
go
over
the
issues
with
doing
token
bindings
area
RTT
together
and
some
of
the
options
for
how
that
might
be
done.
So
next
slide
I'm
going
to
talk
about
why
we
might
care
about
this
combination.
D
So,
basically
the
problem
with
doing
as
your
tea
and
token
mining
is
there
might
be
some
clients
that
want
to
do
both
of
these.
On
the
same
connection
and
doing
token
binding
in
early
data
require
is
using
the
early
exporter
master
secret
instead
of
the
exporter
master
secret
for
deriving
the
sine
value,
and
that
gets
into
some
interesting
issues.
So
next
slide,
when
evaluating
this,
the
making
some
assumptions
about
how
this
is
set
up,
I'm,
assuming
that
token
binding
keys,
are
in
hardware
that
they're
not
extractable
I'm.
D
Assuming
that
when
I
say
that
an
attacker
has
access
to
the
key
this
is
they
have
access
to
an
Oracle
to
sign
an
arbitrary
operations.
They
don't
actually
have
the
bytes
for
the
private
key
I'm,
assuming
that
an
attacker
is
not
going
to
substitute
a
hardware
backed
key
store
with
a
software
back
to
key
store
that
the
attacker
controls.
There
are
some
interesting
attacks
in
this
space
by
forcing
the
client
to
reallocate
and
rebind
to
a
new
key,
but
that
is
orthogonal
to
the
discussion
around
zero
RTT.
D
Those
attacks
could
still
be
done
with
abnormal
token
binding,
so
I'm
going
to
sort
of
exclude
those
for
this
talk
and
I'm
also
going
to
assume
that
if
an
attacker
has
access
to
the
clients,
s
and
session
cache,
they
also
have
access
to
the
token
binding
Oracle.
So
this
is
basically
sort
of
all.
This
is
assuming
that
our
attacker
is
sort
of
a
client,
malware
type
attacker.
D
So
the
first
thing
to
consider
for,
as
you
are
exit
iam
token
binding
options
is:
do
we
even
allow
it
at
all
right
now,
after
HF
took
by
until
s1
3
says
that
they
are
not
allowed
together,
which
is
heading
to
work
in
the
classic,
all
the
way
that
the
expired
0rt
draft
gets
around
this
is
it
adds
a
new
TLS
extension
that
that
sort
of
overrides
that
and
allows
that,
but
one
possible
option
that
I
think
is
reasonable,
is
just
decide.
You
don't
do
0tt
and
tow
combining
together.
D
If
we
decide
we
do
allow
zero,
our
GT
and
token
binding.
On
the
same
connection,
the
next
question
to
ask
is:
can
a
token
binding
message
be
sent
in
early
data,
so
you
could
say
no
you
don't
allow
it
to
open
minded
message
in
early
data.
You
do
allow
some
application
data
to
be
sent
zero
RTT,
but
you
can
only
send
a
token
binding
message
once
the
handshake
has
complete
now
that
this,
whether
this
is
useful,
depends
on
the
application,
since
we've
only
been
looking
at
an
HTTP
mapping
in
this
working
group.
D
So
far,
this
probably
isn't
that
useful,
but
other
applications
say
where
the
server
is
speaking
first,
this
might
be
useful,
I,
don't
know.
If
we
do
allow
the
token
binding
message
in
early
data,
then
we
start
looking
at
exporters,
because
this
is
when
the
early
exporter
master
secret
needs
to
be
used,
at
least
for
the
token
binding
and
early
data.
D
So
next
slide
I
think
there
are
three
options
for
which
exporter
to
use
when,
assuming
that
we
are
allowing
the
use
of
the
early
exporter
master
secret,
the
first
option
is
to
always
use
the
early
exporter
if
zero,
RTT
and
token
binding
have
been
negotiated.
This
is
what
I
described
in
the
previous
draft.
D
Another
option
is
to
have
the
client
switch
to
using
exporter
master
secret
as
soon
as
possible.
This
is
sort
of
very
vague
if
there
isn't
some
sort
of
application
level
signal
or
other
signal
for
the
server
to
say
to
the
client.
You
must
use
the
exporter
master
secret,
then
this
is
just
the
same
case
as
above,
because
an
attacker
can
just
send
the
keep
sending
early
exporter
master
secret
and
use
that
for
the
lifetime
of
the
connection.
D
And
then
another
option
is
you
use
early
exporter
master
secret
when
you're
in
early
data
use
exporter
master
secret
for
everything
post
handshake?
This
is
unknowable
because
there's
no
way
to
guarantee
that
the
early
data
as
the
client
is
writing.
It
ends
up
in
early
data
and
send
them
ends
up
post
and
shake.
So
it's
not
really
an
option
on
the
table,
but
there
for
completeness
so
next
slide.
D
So
the
when
looking
at
sort
of
the
security
differences
between
these
two
exporters,
what
it
basically
comes
down
to
is
what
point
in
time
was
the
token
binding
key
used
to
sign
with
when
the
expert
or
master
secret
is
used.
This
is
what
is
done
in
token
binding
as
specified
in
RFC
84.
Seventy
one
two,
three,
the
the
token
by
new
key,
is
used
right
when
the
TLS
handshake
is
finished
once
the
finished
messages
are
sent.
On
the
other
hand,
when
using
when
signing
over
the
early
expert
or
master
secret.
D
This
is
just
proving
that
the
whoever
sent
the
Ito
combining
message
had
access
to
the
token
binding
key
at
some
point
after
the
new
session
ticket
for
establishing
that
connection
was
used.
So
you
send
the
in
the
first
flight
like
one
hour,
TJ
handshake
server
sends
the
new
session
ticket,
then
at
some
future
time
the
client
does
the
resumption.
You
only
know
that
that
signature
was
valid
over
or
you
only
know.
D
There,
when
the
0tt
case,
if
this
signature
is
sent
in
early
data,
there's
also
the
chance
that
the
attacker
didn't
have
access
to
the
key
at
all,
but
it
just
took
the
client,
hello
and
the
early
data
and
replayed
it
verbatim.
So
I'll
talk
about
that
a
little
bit
later,
but
sort
of
considering
the
client
malware
attacker
for
these
two
scenarios.
For
the
first
scenario,
an
attacker
can
get
access
to
the
key
at
the
beginning
of
the
handshake
and
then
even
if
it
loses
access
to
the
key.
D
As
long
as
that
connection
is
still
alive,
it
can
continue
to
use
token
mining
messages
on
it,
and
this
connection
doesn't
need
to
be
from
the
machine
where
the
keys
are
because
the
attacker
can
proxy
the
Oracle
to
wherever
the
attacker
is
controlling
it.
In
the
second
case,
basically,
what
is
happening
is
again.
The
attacker
can
be
proxying
the
key
Oracle
to
an
attacker
controlled
machine,
but
in
this
case
the
attacker
can
continue
to
use
this
signature.
It
can
make
a
bunch
of
connections
to
the
server
get
a
bunch
of
new
session
tickets.
D
D
If,
if
you
were
to
do
the
same
setup
but
without
token
binding
and
some
some
data
and
zero
RTT,
you
still
have
the
same
replay
concerns
that
you
have
in
TLS,
1.3
toh
combining
isn't
really
adding
any
extra
protection
to
prevent
that
replay.
So
it's
a
it
is
an
issue
it
token
binding,
doesn't
really
make
it
any
better
or
worse
and.
D
There
there's
also
an
edge
case
where
an
attacker
has
access
to
client
secrets
for
assumption
and
can
replay
the
client,
hello
and
token
binding
message
with
new
application
data.
But
if
the
client
is
able
to
do
that
it
or
if
the
attacker
is
able
to
do
that,
then
it
can
basically
just
perform
the
attack
where
it
pre
computes
signature
values.
D
So
that's
sort
of
about
it
for
the
security
differences,
and
the
last
slide
is
talking
about
some
limitation
considerations.
If,
if
you
take
an
approach
where
you
switch
exporters
partway
through
there
needs
to
be
some
sort
of
signal
in
the
token
binding
struck
which
exporter
was
used
so
that
you
know
which
to
use
for
doing
the
verification.
Also,
it
might
be
possible
to
define
something
where
you
don't
need:
a
new,
a
TLS
extension,
but
for
simplicity.
A
A
E
So,
like
I
mean
you
have
the
these
two
cases
about
the
your
access
to
the
token
binding
key
afternoon
session
ticket
or
two
full
replay,
and
the
second
case
the
full
replay
is
sort
of
uninteresting
in
some
sense,
because
you
know
the
protections
against
that
are
sort
of
the
same
sort
of
protections.
You
would
need
in
general
for
zero
ITT,
yes,
but
the
first
case
is
more
worrisome
because
it's
sort
of
turning
a
single
compromised
access
to
these
terminal,
binding
keys
into
a
reusable.
For
you
know,
air
quotes
indefinitely.
E
D
So
the
way
I
sort
of
think
about
this
is
we're
already
looking
at
an
attacker
that
is
client
malware
resident
on
the
machine.
So
we
don't
know
what
sort
of
bad
things
it's
doing.
In
the
first
case,
though,
once
that
malware
has
been
identified
and
removed,
then
basically
the
threat
is
over.
In
the
second
case,
it's
once
it's
been
removed,
then,
seven
days
later,
the
threat
is
over
so
part
of
the
consideration.
If
someone
wanted
to
do
this
might
be
well.
How
long
has
this
starting
going
on
and
how
long
can
we
live
with?
D
F
Like
Joan's
Microsoft
trying
to
wrap
my
head
around
the
situation
for
zero
RTT
with
token
binding
I'm,
going
to
ask
a
question
about
zero
RTT
without
token
value.
Given
you
can
capture
and
replay
an
early
data
packet
and
have
it
succeed?
What
are
the
mitigations
that
use
of
zero
RT
t
have
to
take
in
the
first
place?
I've
heard
told
that,
for
instance,
you
must
make
sure
that
the
data
in
the
initial
packet
resents
represents
an
idempotent
operation
such
that,
if
it's
replayed,
it
has
no
effect,
which
is
an
interesting
layering
violation
to
implement.
D
Yeah
so
I
I,
don't
remember
all
of
the
text
in
the
tailless
1.3
RFC
about
it,
but
but
having
an
idempotent
or
that
similar
requests
is
one
of
the
things
there
are
I
think
some
other
potential
mitigations
that
servers
could
use,
but
they're
not
like
completely
foolproof.
So
one
example
is
the
server,
could
make
tickets
be
single-use
and
keep
track.
This
ticket
has
already
been
used
for
as
your
assumption
and
won't
let
another
one
happen
in
practice
for
something
with
a
large
server
fleet.
D
E
A
A
A
All
right,
I
I,
think
that's
I,
think
it's
a
good
suggestion.
Obviously
this
sort
of
the
it's
a
suggestion
that
the
working
you
would
do
if
sort
of
provide,
if
we're
not
presented
with
any
other
option
right
or
any
other
alternative.
Somebody
wants
to
present
a
draft
that
does
zero
RTT
it.
So
that's
always
a
possibility,
at
least
for
as
long
as
the
working
group
exists,
so
I
think
at
this
point,
we'll
have
to
leave
it
there
at
at
this
point,
we
don't
from
like
a
procedural
standpoint.
We
don't
I.
A
D
F
Chance
I
assume
you'll
take
this
tentative
decision
to
the
list.
F
A
A
H
H
I
might
on
my
head,
it's
a
little
bit
of
quick
context.
I
try
to
just
give
some
background
on
Josh,
so
we
don't
jump
right
into
things.
People
in
America,
maybe
aren't
familiar
with
it,
can
can
follow
along
at
home.
This
draft
is
designed
to
support
cases
of
token
binding,
where
there's
some
kind
of
TLS
terminating
reverse
proxy
system
in
place
in
front
of
the
actual
application,
and
this
is
really
common
deployment
architecture.
You
see
it
with.
You
know:
I'm
premise:
systems
where
you
have
an
Apache
and
nginx
terminating
or
an
f5.
H
That's
consistent
with
what
push
HTS
token
binding
provides
and
do
so
in
a
way
that
the
header
names
are
standardized
and
the
value
of
such
headers
are
standardized.
So,
hopefully,
you
could
have
turnkey
kind
of
integrations
between
disparate
systems.
Any
front-end,
TLS
terminating
reverse
proxy,
that
implements.
This
could
be
turned
on
to
do
that
past.
The
same
headers
back
in
a
known
name,
format
and
back
in
applications.
H
Would
then
you
could
turn
it
on
and
they
would
know
without
any
additional
configuration
or
anything
what's
headers
to
look
for
and
how
to
parse
them
and
what
the
semantic
meaning
of
it
is
and
again.
The
whole
idea
here
is
to
facilitate
this
reverse
proxy
and
the
backend
server
eeen
server
functioning
together
as
though
they
are
single,
logical,
server-side
deployment
of
HTS
token
binding.
That's
the
idea.
H
Basically,
it
really
comes
down
to
a
few
headers
and
and
how
you
encode
the
token
binding
message
in
them
and
what
what
the
rules
are
about,
validating
that
and
stripping
headers
and
sanitizing,
and
passing
on
information
to
the
backend
I
was
gonna.
Ask
you
to
advance
the
slide,
but
I
can
do
it
myself,
so
some
notable
happening
since
the
last
time
we
were
all
together
in
Montreal,
I,
published
draft
six
of
this
and
really
just
switched
around
some
sections
having
based
on
some
feedback
from
Martin.
H
He
wanted
to
find
some
and
I
couldn't
find
it
because
it
was
buried.
So
I
brought
a
throughout
this
particular
section
up
to
its
own
top
level
section
in
the
internet,
meaning
time
we
had
a
major
browser,
decide
to
drop
support
for
tow,
combining
which
isn't
directly
relevant
to
all
this,
but
it's
kind
of
a
bummer
in
terms
of
at
least
to
me,
pushing
this
work
and
hoping
to
see
it
widely
adopted.
H
Thank
you
for
doing
it,
and
only
one
comment
was
received
during
the
the
last
call
period
and
basically
that
was
a
from
a
gentleman
that
we
heard
from
a
few
times
before,
and
it's
always
the
same
issue
regarding
that
there's,
not
enough
text
in
the
draft
describing
how
this
doesn't
prevent
against
client
collusion
attacks.
As
a
result,
there
is
some
text
in
one
of
the
core
token
mining
documents,
and
the
reaction
from
the
working
group
was
basically
pushing
back
and
saying,
there's
already
enough
coverage
of
it.
It's
not.
H
It's
not
really
something
we're
trying
to
address
or
talk
about
here,
you've
gotten
more
or
less
more
airtime
on
it
than
didn't,
probably
need
to,
and
nothing
is
needs
to
be
done
in
this
draft.
So
basically,
the
the
consensus
from
the
working
group
was
that
the
one
comment
received
there
was
there
was
no
action
to
be
taken
on
it.
H
The
only
action,
then
that
was
taken
similar
to
what
Nick
said
as
I
published
a
draft
7
and
just
updated
the
references
to
the
the
now
RFC
versions
of
the
three
quarto
combining
specs,
as
well
as
a
reference
to
TLS
1
3,
the
RFC
version
of
that,
and
so
that's
all.
There
really
is
on
it.
So
it's
supposed
to
be
a
joke,
but
trying
to
find
a
document.
Shepard
now
I
think
we're
at
the
point.
Where
we're
it's
ready
to
move
up.
H
A
G
H
There's
there's
one
fully
compliant
implementation
for
Apache
that
I'm
aware
of
I've
heard
rumors
that
maybe
there's
an
engine
X
bug
and
that
kind
of
sorta.
Does
it
I'm
not
sure
how
much
has
been
updated
to
reflect
this
and
at
previous
meetings,
there's
been
statements
to
the
effect
of
well
like
Facebook,
is
doing
this
internally
and
some
things
like
that,
but
I,
don't
it
I,
don't
have
any
verification
of
that
so
right
now
the
the
implementations
are.
Open-Source
modules
are
plugins
for
for
popular
web
server
type
type
things.
A
A
Does
our
ad
have
any
anything
you
wanna
or
just
I
I?
Don't
I,
don't
see
anything
coming
down
the
pipeline?
We,
you
know
there
might
be
related
work
in
the
future,
but
that
doesn't
necessarily
mean
that
the
working
group
needs
to
be
kept
around
so
I.
Think
with
that-
and
you
know,
if
there's
no
other
issues,
I
think
they're
working
group
for
your
hard
work,
we
actually
finished
alright,
yeah,
alright,
thank
you
and
you
get
most
of
the
meeting
time
back.