►
From YouTube: IETF102-TOKBIND-20180720-1150
Description
TOKBIND meeting session at IETF102
2018/07/20 1150
https://datatracker.ietf.org/meeting/102/proceedings/
A
So,
as
opposed
to
like
earlier
meetings,
we
don't
we're
not
spending
more
first
ten
minutes
of
the
meeting
field
figuring
around
will
blood
connectors
to
the
predictor,
because
the
nine
secretarial
people
provide
well
for
us
all
right.
This
is
token
mining
at
IDF
102
on
the
final
homestretch
of
the
IDF
Montreux,
and
you
know
this
is
one
note
well,
you
know
take
a
take
a
note
of
the
note
wall
and
I
think
you
will
know
what
it
says.
A
So
what
we're
gonna
do
today
is
to
briefly
update
you
on
core
document.
Is
you
status
and
then
we're
gonna
do
proxy
and
and
we're
going
to
talk
about
at
the
station
and
then
open
mic
if
you're,
if
you,
if
you
think
you're
missing
the
0,
RT,
+,
1
or
TT
stuff
here,
that's
because
first
one
it
couldn't
be,
and
he
said
some
message
that
he
hadn't
really
made
any
significant
update.
So
I
think
we
was
gonna
cover
those
things
on
the
list.
So
John
do
you
wanna?
A
B
B
D
A
F
You
go
big
crowd
here
at
the
last
Friday
meeting,
thanks
for
coming
out
stating
my
name
I'm,
Brian
Campbell
with
me,
identity
and
I'm
here
want
to
welcome
you
all
to
not
San
Francisco,
it's
a
joke.
This
meeting
was
supposed
to
be
in
San
Francisco
that
got
changed.
Okay,
I'm
gonna
talk
about
hcp
s,
token
binding
with
TLS.
Terminated,
reverse
proxies.
I
have
this
here.
F
F
You
see
this
in
all
sorts
of
things
in
actual
commercial
products,
in
all
sorts
of
open-source
implementations,
Apache
and
in
Ex,
and
more
and
more
so
now,
and
as
a
service
type
deployments.
Cloudflare
Amazon
application
layer,
load,
balancer
and
for
Microsoft
has
some
variant
of
that
and
tow
combining
is
something
we've
all
been
working
on
in
here,
but
in
general
for
applications.
The
back-end
applications
to
take
advantage
of
the
benefits
that
token
binding
brings.
Some
sort
of
information
needs
to
go
from
that
front.
F
End
layer,
that's
terminating
TLS
back
to
the
the
application
layer
in
the
absence
of
some
kind
of
standard
to
facilitate
this
everybody's
going
to
do
it
different,
which
is
a
real
pain
for
I'm
sure
all
of
us
have
experienced
in
one
way
or
another,
or
they
won't
do
it
at
all,
thus
sort
of
undermining
you
know
the
benefit
of
token
binding
or
the
potential
for
adoption.
There's
also
an
alarming
shortage
of
acronyms
in
the
world.
F
So
I
wanted
to
thank
Jeff
for
bringing
TT
rp2
to
me
after
I
fumbled
over
saying
and
writing
it
a
few
times
so
TT
RPS
TLS
terminate
in
reverse
proxy
and
sometimes
say
that
for
sure.
So
that's
why
I'm
here
the
solution
overview?
The
draft
is
now
in
in
draft
5
and
basically
it's
to
define
a
set
of
HTTP
headers,
which
enable
the
T
TRP
in
the
backend
application
this
to
function
together
as
though
they're
a
single
logical
deployment
of
server-side
HTTP
tow
combining
the
TT
RP
gets.
F
The
message
validates
the
token
binding
message
passed
in
in
the
normal
sector
combining
header
and
removes
it
from
the
requested
dispatches
at
the
back
end.
What
it
does
instead
is
assuming
it's
valid
as
a
new
header.
This
SEC
provided
token
binding
ID
it's
a
little
long,
but
that's
currently
how
I
name
things
and
it
includes
their
the
basics.
F
The
solution
requires
some
kind
of
trust
between
the
TT
RP
in
the
backend
server
at
deployment,
and
then
it
also
requires
that
the
PRP
sanitizes
these
headers,
so
the
client
doesn't
inject
them
directly
to
bypass
the
security
controls
they
get
at.
This
is
a
very
common
pattern
and
in
reverse
proxy
type
deployments,
just
to
give
sort
of
a
visual
of
the
overview.
Sometimes
it
help
help
me.
F
F
The
TT
RP
validates
the
token
binding
message
sanitizes
in
the
headers
and
then
passes
the
encoded
token
binding
and
as
the
new
header
to
the
backend
just
shown
in
here,
and
obviously
the
referred
in
the
others
as
well,
if
applicable,
and
this
allows
the
the
backend
application
server
to
bind
cookies
or
other
tokens
to
that
tow,
combining
ID
or
verified
into
the
binding
there
of
a
few
changes
in
happening
since
London
we've
had
a
few
reviews.
Thank
you
for
those
that
have
done
that
published
drafts,
4
and
5,
largely
editorial
updates
and
clarifications.
F
But
I
did
add
a
section
on
TLS
versions
and
best
practices
pointed
to
be
CP
195
and
also
made
mention
of
Nix
tow,
combine
negotiation
for
TLS
1/3
draft
and
mention
of
TLS
1/3
in
general,
just
to
sort
of
make
it
clearly
expanded.
Use
and
scope
of
the
scope
of
this
isn't
just
to
TLS
one
too,
but
try
to
make
it
sort
of
variable,
and
so
it
would
age
a
little
bit
better
in
the
document.
F
That
said,
hey.
Let
me
know
if
you,
if
you
think
you
should
be
acknowledged
and
I
forgot
you,
so
that's
not
in
the
draft
anymore,
but
it
still
stands.
Please.
Let
me
know
willing
to
provide
a
little
bit
of
design,
motivation
and
rationale
for
the
way
things
work
as
they
do
now.
The
main
idea
here
was
to
make
the
common
and
simple
usage
simple
and
that's
particularly
true
targeted
at
the
web
application
developer.
That
could
be
read
as
sort
of
a
slight
to
a
web
application
developer.
F
But
I
can
say
that,
because
I
am
one
it's
good
to
make
things
simple
for
them,
but
we
want
to
still
make
the
other
cases,
the
other
other
things
possible,
which
is
something
that
working
group
is
requested.
So
the
overwhelming
vast
majority
of
usage
of
Toe
combining
is
going
to
be
the
provided
token
binding.
It's
going
to
be
the
only
one
and
and
it's
going
to
be
in
every
HTTP
request,
and
this
oh.
F
Sorry,
following
my
own
notes
and
just
quoting
a
bit
of
the
protocol
here,
basically
it's
a
token
binding
protocol
implications
should
make
token
binding
IDs
available
to
the
application
as
an
opaque
byte
sequence.
That's
exactly
what
we're
doing
here,
we're
providing
and
there's
an
encoded,
because
it
has
to
be
for
a
CV
and
encoded
opaque,
byte
sequence
to
the
back-end
application.
This
is
really
simple
for
the
application
developer
to
do
tow,
combining
if
the
roughest
of
the
infrastructure
is
in
place,
they
just
grab
one
well-known
named
header
and
use
the
value
done.
That's
it.
F
The
same
is
true
for
refer
to
combining
in
terms
of
usage.
It's
simple
because
it's
specified
and
we
we
know
what
it
is.
It
is
probably
going
to
be
a
distant
second
in
terms
of
usage
for
a
relatively
specialized
use
case,
which
is
the
an
IDP
or
a
token
provider
or
some
entity.
That's
issuing
tokens
for
another
domain,
which
is
less
common,
but
still
valuable.
Let's
try
to
make
that
case
simple
as
well
same
pattern,
and
then
we
have
250
for
other.
F
Currently,
undefined
took
combining
types
with
some
text
quoted
in
here
about
sort
of
how
they
should
be
used
and
shouldn't
use.
They
should
be
ignored,
but
it
could
possibly
contain
them.
So
really
it
takes
a
proxy
that
knows
what
the
type
is
to
pass
it
along
and
a
back-end
application.
That
knows
what
to
do
with
it,
but
it's
somewhat
more
complicated
encoding
of
the
type
and
a
string
concatenation
of
the
encoded
value
is
used
to
allow
for
all
these
other
types
to
be
passed.
F
So
it's
it's
not
restricted
in
that
context,
but
it
is
intentionally
a
different
encoding
type
to
keep
the
simple
cases
as
simple
as
possible,
while
still
allowing
for
the
more
complex
cases
so
leaving
Montreal
as
the
core
three
documents:
I'm
not
going
to
dance,
but
thanks
John
for
that
good
RFC
on.
Basically,
at
this
point
going
to
ask
requests
that
we
consider
moving
this
to
a
working
group
last
call
and
then
because
we're
in
Canada
I
imply
it
and
said.
Please
and
I
did
it
in
French,
because
we're
in
Montreal.
A
F
A
A
B
E
A
G
Yeah
just
a
short
question:
I
asked
you
before
whether
there
would
be
any
reason
to
provide
any
means
to
authenticate
for
the
for
the
application
server
to
authenticate
that
the
relate
tell
combining
information
actually
comes
from
the
reverse
proxy
and-
and
you
said
well,
there's
you
don't
want
to
do
that.
Extra
complexity.
I
still
have
a
question
whether
if
there
would
be
a
good
reason
in
the
future,
is
it
there's
an
extensibility
possibility
where
you
could
add
that
in
some
sense,
if
it
would
be
important
to.
F
There
was
discussion
in
this
group,
but
it
wouldn't
be
appropriate
to
do
it
in
this
group
of
defining
a
more
generalized
mechanism
for
a
reverse
proxy
to
convey
to
a
back-end
which
headers
it
had
in
fact
looked
at
and
processed
to
to
to
do
that
as
a
more
standardized
mechanism.
That
didn't
seem
to
be
the
the
appetite
in
in
the
HP
working
group
to
go
forward
with
that.
F
If,
in
fact,
though,
that
was
work
that
was
undertaken,
my
expectation
would
be
that
it
would
be
generalized
such
that
it
could
be
applied
to
any
specific
header
used
in
this
kind
of
context.
Security
aware
context
between
the
proxy
in
the
back
end
and-
and
thus
this
would
be
as
applicable
as
any
other
similar
content
to
that
kind
of
protection.
A
This
is
not
the
work
you
have
to
do
it
and
it's
a
general
problem,
but
so
far
there
hasn't
been
appetite
to
do
it
that
doesn't
preclude
you
know
anybody,
including
you
right
from
going
to
go
to
it.
Http
work
here,
don't
say:
hey
I
need
to
solve
this
problem.
You
know,
would
you
consider
a
raft
and
I.
F
Think
the
main
I
think
is
appropriate
pain,
point
and
concern
of
the
question
was
if,
in
fact
that
happened
is
there
anything
in
here
that
might
preclude
it
from
working
with
that
and
there's
certainly
nothing
that
I'm
aware
of
or
put
in
there
intentionally.
It
should
be
fine
and
applicable
to
that
kind
of
thing.
Okay,.
H
Someone
comes
to
me,
I
think,
there's
a
there
are
too
many
options
in
this
place
for
us
to
actually
know
anything
anything
down.
Concretely
we're
talking
about
attestations,
client,
authentication,
I,
don't
think
the
suggestion
of
a
private
network
is
actually
a
good
one,
but
but
it
happens,
it
happens.
Unfortunately,
till
I
said
SSL
added
and
removed
here,
I
remind
everyone.
I
noticed
that
there's
nothing
in
the
draft
on
this
point,
certainly
not
other
security
considerations.
H
F
H
A
A
A
B
J
The
group
for
a
couple
years
now,
but
we
only
started
seriously,
considering
it
as
of
London
I'll
apologize
to
the
group,
because
I
did
submit
a
revision
this
week.
I,
don't
think
that
that's
normally
the
way
generally
like
to
do
things,
putting
a
putting
a
draft
on
everybody's
plate
during
the
meeting,
but
I
actually
got
some
very
good
feedback.
J
J
Okay,
so
you
know
to
give
a
recap
of
well
I
think
everybody
knows
what
TLS
token
mining
is
about.
It's
a
little
bit
more
than
just
bearer
tokens.
It's
also
proof
of
possession
of
a
private
key,
and
the
current
specification
requires
that
the
ekm
be
signed
and
there's
also
the
so-called
tope
tope
bonding
type
talk
line
key
parameter,
so
they
have
to
be
exchanged
as
part
of
the
as
part
of
the
it's
part
of
the
score.
The
whole
message
flow.
J
So
where
does
that
a
station
come
in,
the
browser
could
maintain
private
keys
associated
with
token
mining,
but
the
problem
is:
is
that
user
agents
are
in
user
space
and
therefore
there's
they're
subject
to
potential
compromise
and
particularly
browser
maintained,
key
stores
are
vulnerable.
We
seen
we've
seen
some
advances
at
all
yo
and
platforms
to
actually
to
actually
actually
better
protect
key
stores,
but
right
now,
I
think
we
see
with
a
lot
of
TLS
token
binding
implementations
that
that's
what
you
have
user
user
space
protection
of
keys
native
applications.
It's
not
much
better.
J
You
know,
there's
a
there's:
a
lot
of
reliance
on
open
source,
libraries,
there's
code,
obfuscation,
and
you
know
in
basically
crossing
your
fingers
that
your
binaries
don't
get
reverse
engineered,
so
I
mean
even
if
you're
talking
about
native
clients,
implementing
TLS
tow,
combining
they
if
they
maintain
a
private
key
store.
There
are
still
vulnerabilities
with
the
there
are
still
vulnerable
--'tis
with
that.
So
this
is
where
attestation
comes
in,
so
attestation
wanna
go.
One
definition
is
given
here
and
now.
J
I
know:
we've
had
two
bar
boss
this
week,
where
you
discussed
a
lot
of
different
views
on
whatever
attestation
remote
attestation
is
about,
but
it's
generally
a
piece
of
software
providing
a
sort
of
providing
information.
That's
cryptographically
verifiable
about
the
environment
in
which
the
private
key
is
stored,
specifically
in
the
case
of
token
binding.
It
could
also
be
more
general
purpose
about
the
security
profile
of
the
device,
and
you
can
include
several
things
in
there,
including
the
health
of
the
device.
You
know,
for
instance,
Android
safety.
J
H
J
J
C
J
Yeah,
so
if
we
look
at
the
current
at
the
current
draft,
for
a
talk
by
protocol
specifically
was
called
out
when
in
where
the
extensions
are
defined,
that
that
attestation
is
envisioned
as
a
potential
extension.
So
this
is
kind
of
trending
a
little
bit
of
new
ground.
Now
that
we
have
the
three
main
drafts
going
into
our
C
status.
Now
we
can
go
ahead
and
say:
ok,
how
do
we
would
want
to
define
extensions?
J
You
could
provide
an
attestation
for
that.
I
really
see
a
point,
I'm
hoping
that
one
day
we'll
get
to
a
point
where
there's
enough
performant
eStore
implementations
where
Chrome
will
be
able
to,
but
it
will
be
able
to
move
off
from
a
user
space,
maintain
key
store,
so
I
defined
an
Android
key
store.
Attestation
is
one
of
the
initial
formats
and
the
anticipation
of
that
that's
open
to
any
cut
in
put
from
the
group
for
edge.
J
There's
also
a
problem
with
the
problem
there.
As
far
as
performance
is
current
concern
for
TPM
based
key
stores.
I.
Think,
though,
based
on
some
offline
discussions,
Microsoft
will
come
in
as
so.
If
this
giraffe
goes
forward,
Microsoft
will
come
in
to
extend
it
with
their
preferred
approach,
using
a
more
performant
key
store
than
a
TPM
I
put
in
a
TPM
just
a
boot
it.
You
know
just
to
you
just
to
seed
this
attestation.
This
has
these
attestation.
What
will
hopefully
then,
should
become
an
attestation
registry
for
token
binding
yeah.
K
J
Bart
heavily
from
what
often,
and
what
about
the
know
about
the
no
but
a
web
part
and
we
defined
it
with
respect
to
1.2.
My
interpretation
was
that
this
isn't
kind
of
a
general
TPM
attestation
that
you
see
as
part
of
the
secure
boot
that
you
see
generated
secure
boot.
This
is
something
specific
to
the
token
binding
operation
and
I
thought.
The
version
1.2
solution
was
a
was
sufficient
for
that,
but
yeah
there's
a
lot
of
different.
J
This
isn't
even
the
only
TPM
attestation
in
the
spec,
but
in
the
web,
author
inspector
is
also
there's
also
an
EC
DAA
version
of
version
of
that
at
a
station
as
well
I'm
open
to
other
I'm
open
to
other
things.
The
1.2
I
thought
was
pretty
well
understood,
it's
509
based
you
could
it
serves
a
job
for
this
particular
purpose.
J
J
Because
there
was
a
lot
of
a
hard
work,
not
so
much
just
for
the
Android
key
scores
and
keystore
much
for
interpreting
the
TCG
specifications
for
the
TPM
attestation,
then
I
wanted
to
leverage.
There
are
some
primary
differences.
The
web
oven
at
a
station
signature
is
over
a
combination
of
what
they
call
client
data,
not
data.
The
client
data,
where
the
client
data
incorporates
the
challenge
a
server
generated
challenge
in
this
case.
J
I
didn't
see
a
need
for
a
server
generated
challenge
because
we
have
a
km
so
that
binds
to
the
so
that
binds
to
the
TLS
session.
It
works
for
the
token
binding
message:
I,
don't
see
why
I
couldn't
work
for
the
attestation.
Other
thing
is
web
often
requires
between
reach
of
the
actual
algorithm
used
outside
of
the
certs.
I
personally
worry
about
such
things,
because
I
figure,
because
there's
always
a
slim,
possibility
that
the
algorithm
you
received
out
of
and
could
not
be
the
same.
J
J
J
Okay,
so
I
think
I'm,
a
I
think
I
need
to
go
back
and
verify
this.
What,
with
the
TPM
five,
the
509
for
Android
keep
strong
I'm,
pretty
confident
that
that's
yeah
as
far
as
I
can
tell
that's
the
algorithm
that
was
used
for
the
creation
of
the
signature.
The
thing
is,
though,
if
you
read
Google's
documentation,
they
don't
specifically
require
inclusion
of
that
field.
In.
M
The
search
so
I'm
just
saying
that,
like
that
you
know
fiber
on
keys
or
like
I've
typed
RSA
encryption,
and
so
it
could
be
any
signature
and
we
can
actually
PSS
or
pkcs1,
and
you
can't
tell-
or
maybe
maybe
you
are
say
encryption
and
say
and
then
the
same
thing
is
true
quasi.
True
for,
like
you
know,
sometimes
for
easy.
So,
like
you
can't
you
can't
go
from
the
five
lines,
aren't
necessarily
notes
in
charge
of
what
yeah
so.
J
Actually,
why
I
got
you
online?
So
what
do
you?
So?
What
is
your
recommendation
if,
if
the
client,
ok,
the
client
in
this
case
a
token
by
Incline,
knows
what
algorithm
it
used
to
create
the
signature,
because
it,
you
know
I,
commanded,
whatever
key
store
to
get
create
that
signature.
So
what
it?
What
should
a
relying
party
do
when
the
algorithm
conveyed
by
the
client
is
different
from
the
algorithm
in
the
search?
Well,.
M
I
guess
it
depends
what
we
mean
by
I
mean
so
I
mean
it's
only
search
video
to
our
business
or
obviously
ones
the
one
that
covers
the
surface
and
sure
to
ignore
nails.
When
that
tells
you
kind
of
key
you
have
so
I
mean,
there's
I
mean
those.
Do
you
need
to
match
up,
or
you
know,
are
going
to
work
right
on
the.
M
Yeah
I
mean
I.
Think
so
you
mean
like
it's,
you
know
it's,
it's
the
the
the
algorithm
in
the
services
like
ECG,
essay
and
and
and
and
that
and
the
one
with
one
group
and
like
this
sorry,
it's
like
it's
like
claims
to
be
like
ECG
is
a
one
group
and
like
the
little
group,
I
don't
know
like
I
mean
yeah.
J
Okay,
so
I'll
do
that
and
on
safer
next
version,
I'll
just
separate
out
algorithm
thing
to
do
some
different
efficiencies
for
doing
that,
but
it
yeah
like
I,
said
it's.
That's
the
one
thing
that
it
kind
of
been
scratching
my
head
over
and
I.
Think
you
know
for
web.
Ought
that
I'm
scratching
my
head
over?
That's
you!
J
Okay
could
go
down
okay,
so
this
is
actually
changing.
I'm,
not
sure
this.
Even
if
the
group
wants
to
do
this
I'm,
they
even
sure
it
belongs,
and
I'm
not
even
sure
this
mechanism
belongs
in
this
draft,
basically
yeah,
unfortunately
Dirk
and
the
rest
of
the
Google
guys,
don't
seem
to
be
here
today
and
I.
Don't
like
talking
about
people
when
they're,
not
here,
okay,
yes,
okay,
so
Dirk
convey
Dirk,
convey
to
me
in
a
one-on-one
discussion
and
he
said
that
there
needs
to
be
a
mechanism
for
suppressing
in
attestation.
J
In
case
the
relying
party
isn't
interested
in
wasting
bits
over
the
wire
on
that
so
I
kind
of
looked
at
it
a
little
bit
I
kind
of
looked
at
it
and
said.
Well,
how
do
I
how?
What
would
be
the
best
way
to
do
this
and
I
thought
that
a
simple
way
to
do
it
is
the
way
we
treat
cipher
suites
in
the
TLS
handshake
and
therefore
I
proposed
a
new
TLS
extinction
code.
Point
for
token
for
token
bonding
sessions
when
extensions
are
used
where
the
client
hello
was.
J
This
includes
a
list
of
supported
extensions,
and
the
server
hello
would
include
would
include
a
subset
of
those
extensions
listed
in
the
client
list.
Now
I've
been
scratching
my
head
over
this
a
lot
first
off
you're
bloating,
the
TLS
handshake,
which
is
not
particularly
fun.
Second
thing
is
I:
don't
like
the
idea
of
defining
top
mining
Kok
mind
ty6
in
Chico
point
I'd.
Rather
you
said
there
wasn't
the
one
that's
already
there.
J
K
Undrinkable
Microsoft,
so
the
bigger
issue
with
this
proposal
they
think,
is
that
it
doesn't
solve
the
stated
problem.
If
the
stated
problem
is
that
the
client
avoids
generating
you
know
an
attestation
statement
which
can
be
expensive
and
you
know
putting
a
little
bytes
from
the
wire,
because
those
statements
tend
to
be
large
right.
It's
they
involve
a
certificate
changing
stuff
certificate
chain.
K
So
if
that's
the
the
goal,
then
just
saying
you
know:
hey
I
support
at
the
station,
you
know
and
then
waiting
for
the
server
to
respond
doesn't
solve
this
problem
make
it
should
be
much
more
expressive
than
that.
You
have
to
say
I
support
GPM
at
the
station
DSM
at
the
station
key
store
at
the
station.
You
know
whatever
you
support
and
the
server
has
to
say
well,
I
can
verify
this
type
of
attestation
with
these,
possibly
even
with
these
trusted
roots
or
not.
K
J
C
J
To
we
wanted
to
basically
follow
the
WBC's
fingerprint
device,
fingerprinting
guidance,
which
is
minimizing
exposure
potential
privacy,
privacy
violating
information
which
could
include
additional
device
capabilities
so
Minoo.
If
we
feel
the
way
this
risk
isn't
so
much
which
feature
like
token
mining,
then
yeah
I
think
you
know
advertising
the
capability
is
one
thing,
I
think
as
far
as
trusted
rates
and
I
think
that
corresponding
with
you
on
this
private
way,
I
actually
propose
that
in
web
authentication,
where
a
server
could
actually
say.
J
K
J
J
B
J
J
K
To
this
question
under
HIPAA,
both
Microsoft
again
so
to
this
question,
I
think
that
it's
kind
of
overkill
to
advertise
your
extensions
before
you
send
them.
The
the
draft
currently
says
that
this
over
ignores
extensions,
that
you
know
the
server
doesn't
understand
it's.
You
know
it's
as
if
in
TLS
first,
you
negotiated
that
you
will
send
us
an
i10.
You
sent
us
and
I.
You
know
it
seems
like
a
second
layer
of
negotiation
that
so
far
I
don't
see
this
work,
but.
J
Okay,
thanks
Andrea.
If
we,
if
the
group
feels
it
doesn't
need
it,
then
I
don't
even
need
to
define
a
new
extension
code
point.
So
what
that
means
is
that
you
can
live
with
the
existing
TOS
top
bind
extension
extension
code
point
and
the
client
supports
an
extension.
It
sends
it
off.
The
server
is
interested
in
it
find
it.
It
goes
ahead
and
it
goes
and
parses
and
interprets
it
and
acts
upon
it
or
adjusting
noises.
It
tosses
it
to
the
ground.
N
So
I
haven't
spoken.
This
visited
Dirk
about
this,
but
to
to
try
to
show
interpret
his
I.
Think
one
of
the
issues
is
that
it's
not
enough
just
about
support
it's
also
about,
if
you're,
comparing
to
web
bottom.
The
reason
that
we
have
the
authorization
conveyance
professional
reference
there
is
that
in
many
cases
the
server
does
not
want
explicitly
does
not
want
at
the
station,
because
it's
privacy
reveal
and
server
may
not
want
that.
That
could
be
because
the
server
does
not
want
the
data
because
it
ends
up
logs.
N
It
could
also
be
because
in
web
often
the
client
or
the
browser
may
actually
throw
it
back.
So
you
I
for
that
and
that's
probably
a
concern
that
is
not
necessarily
valid
in
the
context
we're
talking
by
me.
But
it's
it's
not
just
about
supporting
optimizing.
What
goes
on
the
wire,
but
it's
also
that
that's
one
of
the
other
reason
for
deterrence
yeah.
J
So,
there's
two
so
one
of
the
things
we
talked
about
in
web
off
and
not
just
with
that
a
station
where
the
extensions
in
general
is
that
the
attestation
was
originating
outside
of
the
browser
therefore
removes
the
privacy
violating
the
browser,
wouldn't
necessarily
be
able
to
do
anything
about
it.
They
couldn't
modify
the.
J
The
signature
right
I
think
in
this
case,
so
they
talked
mine,
stack
it's
fully
controlled
by
the
browser.
So
at
least,
if
the
browser
feels
that
okay,
I
don't
have
the
user
permission
for
this,
it
can
suppress
it
and
the
server
the
server
just
would
never
receive.
The
extension.
I
think
the
problems
a
little
bit
better
bound
in
the
talk-line
context.
J
A
Can
can
I
make
a
suggestion
there?
If
you
know
no,
we
know
I
mean
this
is
not
a
working.
What
document
and
we
haven't
even
talked
about
that
yet,
but
what
I
would
suggest
is
that
you
go
talk
to
that
TLS
working
group
about
this,
but
it
because
it
seems
to
me
that
you're
gonna
have
like
similar
situations
in
other
extensions
where
a
person's
encrypted
sni
right
where
well
you
know
the
client
is,
you
know
deciding
to
send
SNI.
A
Information
to
their
server
and
the
server
doesn't
have
a
say
whether
that
client
does
that
or
not
right.
There's,
there's
no
negotiable.
Okay
with
me,
sending
an
SI
request
right
before
you
send
a
as
now
so,
and
this
sort
of
seems
to
me
to
me
to
be
like
a
similar
situation
right.
So
you
know
maybe
have
a
conversation
with
the
TLS
folks,
some
of
whom
are
in
the
room
right
to
figure
out
whether
this
even
makes
sense
to
try
to
get
out
of
this.
M
A
J
So
here's
the
thing
attestation
being
one
example:
there
could
be
situations
where
the
server
is
not
interest
in
the
a
data.
In
an
extension
a
talk,
mind
extension,
that's
being
produced
by
the
client,
but
now
in
the
latest,
IDE
I
put
in
a
way
for
the
server
to
suppress
this
particular
extension.
But
it's
kind
of
more
general.
It
can
be
used
with
all
extension.
M
J
M
Point
is:
is
that
okay
see
so
like
the
wait
that
relationship
works
right
is
the
client
gets
his
extensions
first,
the
server
sends
extensions
right
and
so
the
if
you
want
to
send
the
if
you
if
you
want
to
access
it.
So
so,
if
you're
saying
I
support
at
the
station,
which
I
think
it's
been
extension,
I
support
at
the
station
or
like
decision
information,
it's
I.
M
Yeah
the
wait
else
works
is
like.
Basically,
you
advertise,
you
get
the
advertise.
What
you
support
and
me
Ike
I,
like
you
know,
like
lots
of
and
he'll,
doesn't
like
leaks
like
sniff
I
kind
of
figure,
pre
information
about
you
about
your
client,
and
maybe
we
should
solve
that
problem.
Don't
like
we're
not
house
all
year,
yeah.
J
So
is
so
in
this
case,
the
way
the
way
I'd
kind
of
propose
it
to
summarize
is
that
the
client
sends
a
list
of
extensions
of
sports.
One
of
them
could
be
attestation.
The
server
says
the
sends
a
list
of
what
he
would
select
among
that
that
he
could
support,
and
if
it's
not
interested
in
attestation,
it
would
just
say
no.
M
J
M
M
Mean
so
the
retailers
works
now
right,
if
you
didn't
want,
if
you,
if
the
client
does
at
the
station,
but
the
server
doesn't
want
it,
then
the
pattern
would
be
the
client
offers
it
the
server
agility
more.
Is
it
and
then
the
talk
doesn't
happen?
That's
the
pattern.
The
expect
now
right,
okay,
so
I
guess
what
I'm
saying
is.
If
what
you
want
is
to
suppress
the
clients
offer
about
so
station
yeah.
B
H
Yes,
I'm
Alan,
Thompson
I
think
you've
got
the
basic
design
is,
is
the
same
as
with
token
binding.
The
client
advertisers
the
that
enter
station.
It
supports
the
server
list,
the
subset
of
those
that
is
willing
to
accept
and
the
advantage
that
you
have
in
the
case
where
the
servers
don't
want
particular
forms
of
attestation
is
that
the
client
doesn't
have
to
generate
them
and
then
spend
the
bytes
on
them,
but
that's
exactly
the
same
analysis
as
you
have
with
the
standard
talking
binding.
So
nothing
changes,
no
nothing's,
no
extra
complication.
They
did
okay.
J
Okay,
so
we
have
the
opening
we
have.
The
opening
questions
is
what
MOA
says
should
even
be
in
extensions
negotiation
mechanism,
because
the
server
can
always
draw
up
extensions
that
it
doesn't
care
about.
You
know
I'm
personally,
not
that
convinced
about
saving
bits
over
the
wire,
but
for
your
client
generated
extension
to
the
server
doesn't
care
about,
but
you
know,
maybe
it
could
be
a
it.
Maybe
could
be.
Consideration
of
future
should
supported
attestation
types.
The
advertised
the
current
ID
only
says
whether
the
client
supports
attestation.
J
J
H
So
mutton
Thomson
I
think
that
the
mechanism
that
we
discussed
just
just
now
covers
the
first
two
points.
I,
don't
think,
there's
much
value
in
us
having
a
single
boolean
value
here.
I
mean
if
you
say
you
support
attestation
and
there
could
potentially
be
multiple
types
of
them.
It
sort
of
makes
a
bit
more
sense
to
actually
negotiate
the
types.
Okay,
don't
advertise
trust
anchors?
We
don't
do
this
anywhere
else
and
it's
a
cork,
Meyer
I,
don't
know
what
the
current
listed
that.
H
H
With
respect
to
other
stations
might
be
further
improved
by
the
other
work
that
you're
doing
here
rather
than
trying
to
solve
that
problem.
Here,
we
will
have
to
make
a
call
as
to
how
how
mature
that
work
is
with
respect
to
those
other
things
and
and
how
well
deployed
it
is
before
before
we
get
to
that
data
point,
and
that's
probably
a
working
group
last
call
point:
we
make
that
sort
of
decision
or
certainly
much
further
down
the
path
for
this
and
I.
Don't
know
what
the
verification
procedures
are,
but
ya.
J
Know
that's
I
mean
in
the
you
know
we're
and
I'm
having
a
pre
verify
and
REE
verify.
We've
been
doing
this
in
the
context
of
web,
often
as
well.
If
I'd
I
was
setting
up
a
server
certification
program,
so
we're
trying
to
actually
do
that
or
trying
to
make
sure
those
verification
procedures
were
accurate.
So.
H
I
have
a
question
for
you
related
to
the
verification
stuff.
We
covered
a
large
portion
of
the
token
binding
header
structure
with
the
signature.
We
don't
cover
the
extensions
with
the
signature.
Do
we
so
we're
going
to
have
to
make
some
sort
of
assessment
about
how
the
signature
and
the
attestation
in
interim
interact
with
each
other
such
that
we
don't
have
any
problems
with,
say,
copy/paste
attacks
in
all
essence
of
all
things
and.
K
People
will
Microsoft.
That's
that's
a
valid
point.
We'll
need
to
think
about
that.
But
I
think
before
we
even
get
to
that
there
is
a
bigger
issue,
bigger
open
question.
I
have
for
this.
So
in
the
current
draft
it
talks
about
using
the
TLS
I
am
in
the
attestation
message,
validation
and
then
generation
pass,
obviously
all
right,
and
so
that
to
me
does
not
make
a
lot
of
sense.
K
We
need
to
first
like
figure
out
how
long
those
at
the
station
statements
will
last
whether
they
will
be
generated
for
every
TLS
session
which
to
me
wouldn't
make
sense
right
so
like
if
I
am
attesting
the
token
binding
here
and
probably
generating
that
statement
once
and
it
maybe
lives
for
a
while.
So
we
need
to
kind
of
think
about
that
basic
question.
First,.
H
J
So,
okay,
okay,
that's
fine
I
mean
an
attestation,
signature
and
I'm
talking
about
the
attestation
signature,
specifically,
not
the
talk
about
message,
signature
to
me:
it
doesn't
make
sense.
Unless
it
was
a
to
me,
it
doesn't
make
sense
generating
it
without
a
potential
to
prevent
replay
right
and
he
can
just
seem
like
low-hanging
fruit.
In
order
to
get
it,
you
know
it
creates
challenge
data
I
mean
we
can
do
some.
You
know,
but
that's
that
was
what
my
motivation
was
behind,
that
right.
So.
K
Again
in
favor
of
Microsoft,
so
the
replay
is
mitigated,
in
my
opinion,
by
by
providing
a
token
binding
signature
in
the
token
binding
message
on
every
like,
and
that
is
based
on
the
qiam
right,
but
it.
But
my
thinking
was
that
there,
the
station
Draft,
is
about
attesting
to
the
fact
that
the
token
binding
key
that
I'm
using
is
actually
stored
securely
like
in
south
and
GPM
and
VSM
whatever
it
is
in
the
key
store.
So
so.
I'm
thinking
that
actually
at
the
station
statement
does
not
need
to
be
generated
every
time.
K
J
K
Think
that
is
just
a
signature
with
the
like
in
any
attestation
mechanism
that
I'm
aware
of
and
I'm,
not
in
at
the
station
expert
by
any
stretch
of
the
imagination.
But
basically
there
is
an
attesting
key
that
will
sign
the
the
probably
the
public
portion
of
the
token
binding
key
or
something
based
or
something
including
that
right.
So
basically,
it's
a
signature
over
the
token
binding
key.
K
J
H
B
H
J
Yeah
I
can
keep
getting
a
minute.
Maybe
you'll
have
different
relying
parties,
particularly
using
a
TT
RP
in
the
middle
right
yeah.
No,
that's
fine.
We
can.
We
can
do
that.
We
can
create
a
signature
over
the
public
key
in
that
way.
It
doesn't
change
per
connection
and
you
know-
and
we
relied
anti
replay.
K
And
remove
Microsoft,
so
if
it
saves
us,
you
know
a
signature
on
every
you
know
connection,
that's
a
good
thing
and
the
signature
verification
potentially
if
the
server
is
able
to
a
cache,
maybe
those
things
we'll
see.
So
the
other
thing
is,
you
know
if
we
were
to
sign
the
key
em.
You
know
a
key
M
is
a
bag
of
bytes.
If
your
TPM
is
willing
to
attest
to
the
to
sign
like
a
random
bag
of
bytes
that
the
something
is
broken
in
that
at
the
station.
So
just
a
comment
on
that
ma'am,
fair.
J
Enough,
okay,
so
that's
something
I
need
to
correct
I'll,
get
it
so
I.
Think,
first
off
those
are
the
open
questions.
I
got
some
feedback
on
that
I
think
the
second
one
needs
to
wait
adopting
the
idea
standards
track
until
they
get
a
new
version.
The
other
thing,
too,
is
I
want
to
get
the
Google
answers
on
what
they
want
to
see.
As
far
as
extension,
negotiation
and
extensions
approach
and
they're
concerned,
and
also
co-editors
are
welcomed.
J
I
will
say
will
message
to
the
chairs,
though,
that
even
though
the
you
know
once
we
get
through
this,
and
this
becomes
a
working
grade
graph
and
I
think
that
I
think
that
opens
up
possibilities
for
the
for
people
to
extend
the
attestation
registry
so
I.
My
probably
my
my
recommendation
is
not
to
let
this
do.
I
got
too
long
before
making
the
decision
to
get
this
yet
the
standards
track.
So.
A
Getting
to
that,
so
it
it's
sort
of
I.
Think
the
limiting
factor
here
are
two
things
right.
How
you
know
how
quickly
can
you
spin
another
version
and
get
some
review
on
that
and
then
we'll
actually
have
to
be
ascertained
that
the
working
group
is
interested
in
working
on
this
and
I
think
it
has
to
happen
very
quickly,
because
none
of
the
core
documents
are
out
and
proxy
is
getting
there.
A
I,
don't
think
we're
going
to
be
around
for
that
much
longer
if
we
don't
have
active
work,
so
my
my
suggestion
here
would
be
for
you
to
spin
a
new
version
very
quickly
and
I'm
gonna
ask
a
couple
of
questions
for
the
working
group
if
just
sort
of
well
while
I
have
everybody
here
right.
The
and
I
also
want
to
ask
a
question
of
our
ad
whether
he
thinks
that
this
is
actually
in
scope
for
the
for
the
working
group,
because
that's
number
one.
It's.
A
M
A
A
B
A
C
M
That's
fine,
alright,
so
one
thing
that
we
would
have
to
think
about
is
there's
a
concurrent,
a
cessation
work
going
on
in
other
parts
of
the
IETF
I'm,
assuming
you
coordinate
with
those
people,
so
I'm
not
saying
that
that's
a
problem
also
Qualcomm
yeah
exactly
right
exactly
so
so,
but
you
know
it
might
be
the
case
that
if
this
is
the
only
remaining
work
for
tofind
that
are
we
better
to
consider
doing
and
doing
it
in
a
forum
rather
than
trying
to
keep
tofind
alive
right.
So
that's
anything
else
on
John
Center,
absolutely.
A
All
right,
but
I
think
the
quicker
we
get
to
an
erosion
and
some
rule
that
the
quicker
we
get
to
that
point
where
we
can
even
have
a
discussion
where
this
goes.
If
it
goes.
A
Tls
1.3
yeah,
we're
gonna
remind
me.
We
were
gonna,
ask
for.
A
A
So
you
know
there
I
think
we'll
have
to
ask
that
on
the
on
the
list
and
just
just
as
a
you
know,
quick
show
of
hands.
How
many
have
read
the
last
version
of
the
TLS
1.2,
a
draft
and
I
I
noticed
Mick
Sullivan.
It
was
racing,
you
were
racing
your
hand
Nick
have
since
you've
reviewed
it.
Have
you
do
you
have
any
issues
with
that
there
after
you,
as
in
TLS
contributor.
A
A
I
I
I
A
All
right,
thank
you,
everyone,
it
seems
like
when,
when
we
might
meet
in
in
in
Thailand,
but
who
knows
yeah.