►
From YouTube: IETF110-MLS-20210308-1430
Description
MLS meeting session at IETF110
2021/03/08 1430
https://datatracker.ietf.org/meeting/110/proceedings/
A
Five
at
the
beginning
sounds
good,
so
all
right
without
further
ado-
let's
get
to
it,
I
think
everybody
that's
going
to
present
might
be
here.
We
have
well
welcome
to
itf
110.
note
the
well.
This
is
the
first
session.
Maybe
some
of
you
were
at
this
week
so
make
sure
that
you
read
all
this
good
stuff
about
understanding
that
we're
recording
this
video
anything
you
say
at
the
microphone.
Can
it
will
be
used
against
you?
A
A
lot
of
it
comes
down
to
having
to
deal
with
ipr.
If
you
know
about
something
and
you
contribute,
you
need
to
make
sure
you
disclose
that
accordingly,
if
you
have
any
questions
about
any
of
this,
please
feel
free
to
ask
maker
myself
or
any
of
the
other
people
that
you
see
floating
around.
A
lot
of
the
ietf
will
be
gladly
willing
to
answer
your
questions.
A
Hello,
so
basically
we're
gonna
go
through
some
administrivia.
Then
we're
going
to
give
richard
the
majority
of
the
talk
here.
The
time
I
wasn't
sure
if
rafael
was
going
to
present
as
well,
because
oftentimes
you
guys
tag
team.
It
then
we're
going
to
go
on
to
do
some
architecture
discussions
and
then
have
some
time
to
talk
about
deniability.
A
The
blue
sheets
are
automatic,
so
if
you're
here
you've
already
been
noted,
so
that's
really
nice.
We
have
a
note
taker.
That
is
awesome.
I
don't
know
if
anybody
actually
goes
in
the
jabber
room
in
this
particular
session,
but
if
there
is
somebody
in
the
jabber
room,
that's
there
and
is
also
here
if
you
could
just
channel
if
there's
any
questions
that
come
up.
Actually,
I
think
maybe
the
meat
echo
thing
is
plugged
into
this
as
well.
A
So
all
right
without
further
ado,
let's
go
to
the
status
slide.
Basically
the
we
were
awaiting
a
new
draft
in
the
architecture
thing
till
about
an
hour
ago
and
it
popped
up.
So
thank
you
very
much,
benjamin
the
mls
protocol,
I'll
get
to
in
a
second
and
the
mls
federation
draft
expired.
I
think
we
had
some
swapping
of
chairs
of
where
people
work
so
we'll
try
to
get
that
reinvigorated,
but
where
most
people
are
really
interested
is
about
the
timeline
for
for
the
most
protocol.
A
So
at
the
last
meeting
we
basically
I
showed
this
slide.
The
only
thing
really
I
did
was
move
the
bullets
as
we
are
here.
So
the
idea
is
that
we're
in
this
this
feature
freeze
to
allow
for
interop
as
well
as
security
analysis,
and
so
then,
at
the
end
of
all
this,
we're
basically
going
to
have.
How
do
we
do
with
interop?
A
Could
they
get
interop
and
security
input
from
people
to
make
sure
that
if
we
blew
anything
that
we
needed
to
fix
it,
this
is
kind
of
the
agreement
we
have
with
the
security
researchers
we're
trying
to
get
them
to
help
us
and
we
get
to
make
them
famous
by
looking
at
our
protocol.
Before
we
publish
it,
we
need
to
make
sure
we
actually
listen
to
what
they
say
before
we
publish
it.
So
that's
really
about
it.
The
plan
is
that
anything
that
we've
changed
as
a
result
of
interop
or
anything
else.
A
C
So
the
first
slide
I've
already
screwed
up
it's
the
wrong
draft
I'll
get
the
chairs
an
updated
deck.
So
at
like,
like
sean
said,
we
are
in
our
feature,
freeze
and
analysis
period,
so
we
issued
draft
11
after
working
group
last
call
and
some
issue
resolutions
at
the
last
ietf
meeting
and
since
then
over
the
holidays
and
in
q1
here
we've
been
in
a
future
phrase
and
implementation
timeline.
We
have
at
least
two
implementations
going
based
on
draft
11
that
we
have
begun.
C
Interop
testing
I'll,
have
some
more
comments
on
that
a
minute.
So
today
our
focus
is
going
to
be
a
few
issues
and
pr's
that
have
come
up
during
that
feature.
Freeze
mainly
around
pretty
minor
stuff
clarification,
some
some
bugs
people
found,
and
so
we'll
talk
that'll
be
most
of
our
time
today.
So
next
slide,
please.
C
There
we
go
yeah,
keep
going
past
that
one
yeah,
so
we're
on
interop
testing.
Oh,
so
we
have
kind
of
a
cool
test,
interrupt
testing
framework
right,
so
we
want
to
test
various
mls
libraries
and
assemble
those
tests
in
kind
of
a
you
know
and
be
able
to
test
out
various
scenarios.
It's
not
it's
a
little
bit
more
complicated
than
something
like
tls,
where
you
have
a
straightforward,
set
up
a
connection
scenario
that
you
want
to
test
and
maybe
test
it
in
various
configurations.
C
But
it's
always
just
like
set
up
a
connection
from
a
client
to
a
server
with
mls.
You
want
to
do
things
like
have
people
join
a
group.
Do
updates
to
removes.
Do
external
joins
things
like
that,
so
we
needed
a
little
bit
more
flexibility.
So
we
set
up
this
framework
based
on
grpc,
where
the
stacks
under
test
can
be
grpc
servers,
which
means
they
accept
rpcs,
and
we
can
have
a
test
runners
that
can
send
rpcs
off
to
these
clients
to
make
them
do
mls
stuff.
C
So
we've
got
two
types
of
tests
going
here:
test
vectors
and
scenarios,
the
test,
vectors
test
kind
of
simple
subsystems
within
mls,
and
then
the
scenarios
get
the
actual
whole
protocol
and
the
test
runner
is
set
up.
So
it
automatically
generates
all
these
tests,
so
that
kind
of
gets
us
some
thorough
test
coverage
of
the
protocol.
Once
we
have
a
stack
wired
up
into
this
harness
next
slide,
please.
C
So
we
have
some
very
during
the
the
kind
of
code
sprint
or
hackathon
week.
Last
week,
mls
vp
and
openmls
teams
got
together
and
started
doing
some
interop.
We
got
a
couple
steps
along
this,
so
there's
there's
five
levels
of
test
vectors
we've
got
and
then
some
scenarios
we
got
through
the
tree,
math
test
vectors
and
just
the
beginning
of
the
key
schedule.
C
C
Just
to
show
off
what
what
interop
looks
like
this
is,
you
know
the
output
from
our
our
test
runner
and
this.
The
important
line
is
that
second
one
there.
So
the
top
and
bottom
lines
are
just
the
stacks
interoperating
with
themselves.
But
the
second
line
is,
you
know,
first
record
of
interop
between
mls
stacks
mlsp
generated
some
test
vectors
for
tree
math
and
mls
successfully
consumed
them.
C
This
is
also,
incidentally,
our
first
interrupt
failure
where
openmls
didn't
enter
it
didn't
generate
quite
as
many
cases
as
mls
vp
was
expecting,
and
so
mls
vp
rejected
that,
but
I
think
that's
since
been
fixed
over
the
weekend
and
now
we're
interoperating
at
that
level.
Yeah
sean,
hey
richard
are
we
gonna
save
this,
so
we
can
sell
it.
C
C
A
C
Yeah
we
started
with
those
two
we
have.
I
think
chris
wood
has
expressed
some
interest
in
dusting
off
the
go
implementation
that
we
did
earlier
on.
That
needs
some
updating,
but
we
have
an
easy
way
to
plug
it
into
the
test
harness.
So
as
as
that
comes
up,
we
should
be
able
to
to
interrupt
it
pretty
quickly.
C
We
have
if,
if
folks
have
stacks,
we
we
have
example:
grpc
input
integrations
in
c
pulse,
plus,
go
and
rust,
so
it
should
be
easy
to
take
your
implementation
and
plug
it
into
the
the
grpc
based
test
harness
and
do
interrupt
testing
as
soon
as
it's
as
you
as
soon
as
you
get
that
hooked
up
so
well,
we
welcome
you,
know
more
people
coming
along.
I
think
the
easiest
thing
to
do
is
probably
show
up
in
the
mls
implementations
wirespace
and
mention
that
you're
working
on
stuff
there.
C
So
yeah
glad
glad
to
have
more.
I
think
we
had
a
couple
folks
that
were
looking
at
this
earlier
on
and
might
need
to
dust
off
a
few
and
update
things
to
draft
eleven.
But
hopefully
we
can
get
a
few
more
stacks
here
all
right.
So
this
is
just
the
list
of
changes
that
are
in
github
or
expected
to
be
on
github
that
have
protocol
impact.
C
So
there
are
some
editorial
things
that
I
have
not
listed
here,
but
here
we
could
go
ahead
and
have
some
discussion
and
maybe
come
to
some
resolutions
on
these
changes
that
results
in
substantive
changes
to
the
protocol.
Like
I
said
above,
these
are
all
pretty
straightforward:
they're,
pretty
minor
impacts
on
on
the
protocol,
so
I
think
they're
you
know
they're
appropriate
for
the
for
the
future,
freeze
and
appropriate
for
kind
of
fixing
and
and
tweaks
after
after
that
last
call.
So,
let's
dive
in
next
slide.
C
C
D
C
Of
them
were
at
the
far
left
of
the
tree,
and
one
was
all
the
way
out
at
the
right
when
we
remove
that
right,
most
participant,
we
should
also
get
rid
of
all
of
those
unnecessary
nodes
that
the
the
two
remaining
participants
on
the
left
aren't
going
to
use.
That
was
specified
in
draft
of
seven.
When
we
did
the
proposal
commit
thing
in
draft
08,
we
lost
it
and
it
has.
C
C
C
C
C
C
All
right
hearing,
none
unanimous
consent-
where's
my
parliamentarian-
to
keep
me
on
track
here.
So
this
one
is:
we've
had
a
little
bit
of
discussion
today
on
in
github.
I
I
needed
a
little
education
from
the
proposer.
This
is
from
eric
cronelson,
I'm
proposing
to
add
the
group
context
into
the
key
schedule
a
bit
earlier
than
it
is
right
now
so
right
now
the
group
context
gets
added
into
the
epoch
secret,
which
is
kind
of
below
the
bottom
of
this
slide
in
the
key
schedule.
C
The
idea
of
this
adding
the
group
context
in
here
a
bit
earlier
is
to
you
know
ensure
that
the
key
schedules
diverge
faster
in
the
case
that
the
parties
don't
agree
on.
The
group
context
that
that's
my
inelegant
way
of
saying
that
there's
probably
a
clear
way,
there's
some
some
discussion
in
the
in
the
pull
requests
that
make
it
clear,
but
the
idea
here
is
to
get
get
more
context
folded
into
the
key
schedule
faster.
C
C
C
The
leaves
of
that
tree
that
and
each
of
those
key
packages
represents
a
credential
with
an
identity
and
a
signature
public
key
for
the
participant
right
now
we
have
no
constraints
on
those
on
the
uniqueness
of
those
identities
or
public
keys.
So
you
can,
in
principle,
have
a
group
where
every
leaf
of
the
tree
represents
effectively
the
same
same
user.
Has
the
same
credential
same
identity,
same
public
key,
don't
know
why
you
would
have
that
in
practice,
and
that's
kind
of
why
this
this
comes
up.
C
So
the
proposal
in
this
pull
request
is
to
have
some
uniqueness
constraints
on
the
leaves
of
the
trees.
So
to
say,
if
you
see
an
ad
and
it's
an
ad
for
an
identity
or
a
public
key,
that's
already
in
the
tree,
then
you
must
reject
that
ad,
so
that
we
have
a
tree
where
every
key
has
a
distinct
or
every
leaf
of
the
tree
has
a
distinct
identity
and
a
distinct
signing
public
key.
C
C
It
seems
in
you,
given
multi-device.
It
seems
plausible
that
you
would
have
multiple
appearances
of
a
single
identity
with
different
public
keys,
so
I
would
probably
want
to
relax
the
uniqueness
constraint
on
identities,
but
I
I
could
definitely
live
with
a
uniqueness
constraint
on
public
keys
or
on
identity.
Public
key
pairs.
C
B
Yeah,
I
think
the
do
you
had
around
that
was
that
the
the
identity,
in
specifically
in
the
multi-device
scenario,
it
could
simply
be
extended
with
some
device
identifiers
so
that
you
end
up
having
a
unique
identity
that
the
application
can
recompose
and
see
that
that
belongs
to
one
user,
but
that
at
the
protocol
level
we
can
absolutely
distinguish
the
identity.
There.
C
C
The
obvious
way
to
write
a
requirement
is
a
requirement
on
credentials
and
you,
you
might
imagine,
putting
a
device
identifier
in
somewhere
outside
the
credentials.
So
if
you
had
say
certificates
which
have
a
very
structured
constrained
format,
you
might
put
a
device
identifier
in
say
a
key
package
extension
right.
As
you
know,
a
a
field
where
you
can
have
more
control,
it's
not
as
constrained.
C
So
if
you
were
going
to
have
a
must
here-
and
I
see
this,
it
says-
should
in
the
title
slide.
So
maybe
we
can
leave
it
should
and
the
advisory.
But
if
you're
going
to
have
a
harder
constraint
here,
you
would
have
to
find
some
way
to
cover
both
the
credential
case
and
the
you
know:
device
identity
being
elsewhere
case.
D
F
Martin,
the
shoot
is
interesting:
what's
the
interoperability
consequence
of
violating
the
should,
and
if
someone
were
to
enforce
a
policy
that
said
that
the
keys
have
to
be
unique,
and
that
was
not
a
universal
policy?
How
would
someone
adding
people
to
this
group
know
that
that
this
is
something
that
they
would
be
constrained
by?
I
think
that
applies
more
to
the
identities
than
it
does
to
the
keys.
C
Yeah,
that's
a
good
point.
I
I
think
the
interoperability
is
a
real
challenge
here.
I
think
we
could
we
should.
We
could
probably
have-
and
it
sounds
like
there's
some
agreement-
that
we
should
probably
have
a
hard
requirement
must
that
you
should
must
have
unique
signing
keys
per
leaf,
but
that
maybe
the
constraint
around
identity
could
be
softer.
C
E
C
So
dkg
to
your
question
java,
the
identities
right
now
are
arbitrary,
byte
strings
they're,
represented
by
credentials
which
I'll
have
extensible
types,
there's
a
basic
type,
which
just
carries
a
byte
string.
You
can
also
put
a
credential
an
x59
certificate
in
that
slot,
in
which
case
you
get
a
more
structured
identity,
so
it
sounds
like
they're
based
on
the
chat.
There
might
be
a
little
bit
more
discussion
of
this,
but
it
sounds.
C
A
A
C
All
right,
so
this
this
is
one.
This
is
an
issue
that
I
believe
francisco's
file
tonight,
there's
a
corresponding
pr
that
joel
provided
there's
a
kind
of
obvious
problem
and
a
broader
suggestion.
The
obvious
problem
is
just
a
missing
word,
which
joel's
pr
reads
that
fixes
a
you
know
an
issue
with
the
parent
hash
verification
algorithm.
C
There's
also
the
this
request
for
a
more
formal
description
of
the
the
the
algorithms
in
the
spec
to
reduce
ambiguity.
I
don't
know
if
franciscus
is
on
the
call
or
if
joelle
has
talked
to
franciscus
about
this
knows
what
kind
of
what
the
objective
is
here,
but
yeah,
I'm
kind
of
unclear
on
what
to
do
with
this
without
further
details.
C
C
B
C
Yeah,
I
think
what
I
might
do
is
maybe
we
could
kind
of
put
this
on
hold
until
we
get
some
interoperability
going
on
tree,
chem
and
parent
hash
validation
and
see
if
we
run
into
any
interop
issues
as
we're
doing
that.
That
would
benefit
from
clarification
kind
of
empirically
test.
Whether
this
is
clear
enough
to
get
implementations
that
work
together
so
kind
of
mark
this
one
I'll,
merge
the
the
typo
fix
and
then
keep
the
issue
open
pending
interop
issues.
C
Next
one:
there
we
go
okay,
so
this
one
is
a
little
complex.
This
is
an
issue
that
brita
filed.
I
don't
know
if
she's
on
it's
a
bit
earlier
times
in
so
when
we
introduced
external
commit.
That
was
one
of
the
last
big
changes
we
made
to.
Let
people
join
from
outside
external,
commit.
You
can
add
multiple
proposals
in
there.
C
In
the
in
the
issue,
I
think
raphael
noted
that
if
we
have
this
uniqueness
criterion,
you
can
recognize
this
case
now
right,
because
the
old
self
and
the
new
self
will
have
the
same
identity,
presumably
at
the
top
level,
but
maybe
different
device,
identifiers
or
and
certainly
different
public
keys.
So
you
can
recognize
when
you
are
doing
this
recent
operation.
C
In
this
resync
scenario,
it
would
require
a
bit
more
formality
for
kind
of
formalizing,
this
resync
operation,
but
I
think
we
kind
of
have
the
tools
to
do
it
between
identity,
uniqueness
being
making
the
situation
recognizable
and
the
resumption
psk
so
mainly
be
a
recommendation.
You
know
formalizing
the
situation
and
recommending
what
you
do
in
that
situation.
C
C
Oh,
while
while
people
come
to
the
queue
I'll
note
that
the
bottom
bullet
here,
this
does
make
a
bit
of
an
odd
assumption
about
state
loss
right.
The
point
of
reset
is
that
you've
lost
your
state
associated
with
the
group,
you've
desync
with
the
group,
and
you
need
to
reinitialize
from
from
no
state.
C
But
if
we
require
that
you
have
a
psk
from
earlier
epoch,
then
you
can't
resync
if
you've
lost
that
state.
So
we
would
kind
of
reduce
the
utility
the
applicability
of
this
resync
operations,
cases
where
you've
lost
most
of
your
state,
but
you
still
have
your
psks
around
somewhere.
I
think,
given
that
operation
little
thing,
I
think
I
might
tilt
slightly
away
from
making
this
a
requirement
just
to
make
the
recent
operation
a
little
bit
more
general.
C
That
does
have
the
you
know,
there's
a
there's,
a
trade-off
here
between
applicability
and
requiring
that
you
keep
state
around.
You
still
have
state
around,
not
desync,
that
state
versus
you
know
allowing
folks
who
don't
have
that
state
to
rejoin
but
yeah
again
open
to
feedback
on
where,
where
folks
think
we
should
land
on
this.
B
Yeah
this
reference
speaking
so
yeah
to
that
point,
I
think
there
is
a
valid
case,
though,
where
your
state
could
get
corrupted
over
time,
because
that
simply
happens
in
reality
and
if,
if
you
just
flip
one
bit,
then
you're
not
able
to
participate
in
a
group
anymore,
while
your
resumption
secrets
might
still
be
perfectly
valid,
so
that
would
actually
still
work.
The
other
question
here
is
in
reality
on
a
device.
How
well
are
the
resumption
secrets
protected
versus
the
signing
key,
because
if
anything,
I'd
assume
that
the
signing
key
is
usually
better.
B
Than
resumption
secrets,
so
the
question
is
what
what
kind
of
threat
model
is
it
exactly
where
an
attacker
compromises
the
device?
I
would
assume
that
that
attacker
would
get
their
hands
on
both
the
resumption
secrets
and
the
signing
key
in
that
sense,
but
I
mean
I
don't
want
to
dismiss
this.
I
think
it's
very
important
thing
to
look
into.
C
G
Yeah
yeah
I
mean
it
depends.
I
guess
the
presumption
secret
would
be
less
likely
to
be
in
multiple
devices,
whereas
you
might
use
the
sign-in
key
across
multiple
devices
which
would
extend
the
attack
surface
there
so
and
also
depending
on
the
updating
regime.
You
might
be
cycling
between
epochs
and
keeping
your
group
states
and
your
resumption
key
is
fresh
but
you're,
depending
on
the
authentication
that
you
use.
You
might
not
cycle
your
signing
key
all
that
much
so
the
signing
key
might
not
get
regenerated.
G
C
C
So
I'm
not
hearing
a
real,
strong
movement,
one
way
or
another.
I
think
we
could
certainly
have
a
recommendation
around
this
say
in
security
considerations
or
operational
considerations
that
if
you're
doing
one
of
these
research
resync
operations,
then
you
should
include
a
resumption
psk,
and
I
think
you
could
also
recommend
that
applications
enforce
this
criterion
that
if
they
allow
resync
in
this
way,
then
they
should
also
enforce
that
a
recent
psk
must
be
present.
C
C
C
Is
the
last
of
the
issues?
I
think
hubert
chatty
from
matrix.org
raised
this
on
the
mailing
list,
that
there
is
some
ambiguity
around?
What
group
context
you
use
where,
with
proposal
commit,
we
basically
isolated
all
of
our
complexity
into
one
function,
call
or
two
generating
commits
and
handling
them
in
the
process
of
generating
or
handling
a
commit.
It
turns
out
that
you
need
to
use
three
different
group
contexts
for
different
operations
when
you
create
or
process
an
update
path.
C
You
need
to
use
the
group
context
that
represents
the
tree
as
a
plot.
You
know,
as
you're,
using
it
to
create
or
process
that
update
path,
which
means
you've
taken
the
old
group
context
and
you've
applied
the
proposals,
but
you
haven't
moved
forward
the
transcript
yet
so
it's
this
kind
of
intermediate
group
contexts.
C
When
you
update
the
key
schedule
a
little
later
on
to
generate
the
confirmation
tag,
you
use
the
group
context
for
the
new
epoch
you
know,
using
with
with
the
transcript,
updated
and
everything
representing
the
new
app
pocket.
And
finally,
when
you
go
to
sign
the
mls
plaintext
at
the
end,
that
needs
to
be
verifiable
by
someone
who's
in
the
last
epoch,
and
so
you
need
to
use
the
group
context
for
the
last
last
epoch.
C
C
C
C
C
That
is
the
last
one.
I
just
wanted
to
talk
quickly
about
the
next
few
steps.
So
I
think
we've
got
some
interrupt.
Testing
going,
we
would
love
to
have
more
implementations
seems
like
we're
we're
on
track
to
kind
of
get
that
done
in
the
next.
The
rest
of
this
month
april
is
a
generous
eta
on
getting
interrupt
testing
done
at
the
end
of
that,
I
think
we'll
continue
to
target
draft
11..
C
Maybe
we
may
let
in
say
the
truncation
thing
or
something
like
that-
maybe
not,
but
continue
to
target
draft
11
for
interrupt
testing.
Then,
once
we
get
to
the
you
know,
we
once
we
have
things
interoperating
and
have
some
some
good
signs.
You
know
land
all
the
last
prs
issue,
draft
12
and
kind
of
do
that
as
soon
as
we
have
interop
on
draft
11..
That
means
the
interrupt.
C
A
So
my
only
caveat
here
is
that
we
have
to
make
sure
that
whatever
security
research
we
get
back
from
the
community
gets
reflected.
I
know
you're
plugged
in
pretty
closely
with
them,
so
there
shouldn't
be
any
surprises,
but
I'm
hoping
that
at
some
point
we
can
have
some
kind
of
like
hey
these
six
people
looked
at
it.
These
guys
used
tamara
and
these
guys
used
pro
verify
these
guys.
A
Did
it
by
hand
we're
basically
good
with
you
know
these
20
different
caveats
to
go
from
there,
because
I
think
that
if
we're
gonna,
you
know
make
this
deal
with
the
devil.
To
have
the
researchers
look
at
our
protocol
before
we
publish
them,
we
have
to
make
sure
that
we
explicitly
acknowledge
that
we
actually
look
and
took
their
input
in
and
that
may
require
having
another
interim
or
something
just
to
like
formally
go
through
that
to
give
people
a
chance
to
say
something
or
try
to
understand
it.
C
Yeah
absolutely
happy
to
address
those,
and
I
think
joelle
was
maybe
talking
to
some
researchers
to
try
and
calibrate
who's
doing
what
and
when
we
expect
to
see
some
results.
Speaking
of
interims,
I
think
there's
already
brendan
raised
an
issue
on
the
mailing
list
this
morning.
That
probably
merits
anyone
to
talk
about.
So
we
should
probably
have
a
couple
calls
sort
out
any
last
issues
as
we
get
through
this
all
right.
I
think
I'm
done
all.
A
So
benjamin
produced
these
slides
somewhere
like
20
minutes
ago,
so
I
just
got
him.
I
just
uploaded
him
it's
one
of
the
things
I
was
doing
in
the
background.
He
unfortunately
couldn't
make
it
so
I'm
going
to
go
ahead
and
give
the
one
slide.
This
should
give
plenty
of
time
for
sophia
the
o6
draft
version
was
released
today,
not
surprising,
I
think
to
me,
but
there
was
a
whole
lot
more
work
involved.
I
think
than
what
he
really
thought.
A
A
A
lot
of
the
changes
really
were
just
editorial
and
didn't
really
affect
any
previous
decisions,
which
is
good,
and
it's
going
to
take
some
time
to
actually
sync
these
sync,
these
two
drafts
and
the
reason
why
I
think
that
is
important
basically,
is
because
I
don't
think
that
we
could
drop
the
protocol
draft
in
front
of
the
isg
without
the
architecture
draft.
So
if
we
need
to
speed
up
the
architecture
draft
to
get
in
line
with
the
protocol
document,
people
need
to
kind
of
start
focusing
and
spending
their
attention
on
that.
A
So
the
next
step
for
the
document
this
is
this
is
again
the
only
slide
to
determine
what's
missing,
should
be
moved
or
removed,
and
the
way
to
do
that
really
is
to
kind
of
you
know,
kick
stuff
up
on
on
the
mailing
list
and
the
repo
please
sync
with
the
authors,
to
make
sure
we
can
contribute
everything
all
all
in
a
row
and
a
good
thing.
If
you
have
any
security
considerations,
I
think
conrad's
being
thrown
under
the
bus
here.
A
So
he's
gonna
try
to
make
sure
that
it's
clear
and
makes
sense
to
everybody,
and
also,
I
guess,
there's
some
use
case.
There's
a
use
case
section
that
brendan
has
been
looking
at.
We
want
to
make
sure
that
you
reach
out
to
him
as
well-
and
this
is
a
nod
to
our
other
server
assist
document
that
we
discussed
adopting
last
january
in
2021-
that's
with
raphael
and
hopefully
we'll
eventually
we'll
get
a
draft
out
of
that
and
maybe
even
adopt
it
in
the
working
group,
I'm
kind
of
pinching
here.
A
D
A
I
think
it's
probably
I'm
hoping
for
the
latter,
where
it
can
kind
of
happen
organically,
that,
if
conrad
is
kind
of
you
know,
corralling
security,
consideration
stuff
that
he'll
be
looking
at
like
what
else
is
also
missing
and
the
same
with
brendan
looking
at
the
use
cases,
but
yeah,
I
get
your
point
at
some
point.
We
have
to
be
like
all
right,
raise
your
hand,
you're
gonna,
go
look
at
this.
A
B
H
Yeah,
okay,
so
thank
you
very
much
for
allowing
me
to
talk
today.
My
name
is
sophia
from
cloudflare
and
today
I'm
going
to
be
talking
about
the
nobility
in
mls.
It's
an
exercise!
Please,
yes,
and
a
little
bit
of
the
context
of
why
we
want
this.
There
has
been
a
sean
said
at
the
beginning.
There
has
been
already
some
talks
of
having
the
nobility.
H
And
on
the
past
weeks,
past
months
I'll
say
there
has
been
an
increase
of
deniability
in
terms
of
because
sometimes
the
messages
that
we're
sending
through
emails
or
to
child
applications
are
strongly
authenticated,
which
creates
a
strong
proof
of
authentication
which
can
be
later
used
for
other
purposes.
So
the
idea
is
always
to
put
an
ability
on
top
of
authentication.
C
Sophia,
if
I
could
inject
a
quick
question
in
the
last
slide,
yes,
I
would
like
to
distinguish
between
two
deniability
notions,
one
where
the
set
of
people
who
could
have
generated
a
message
is
the
set
of
people
in
a
participant
in
a
conversation
versus
anybody
in
the
universe.
So
they
seem
like
pretty
two
pretty
designations.
Are
you
targeting
one
or
the
other
of
those.
H
So
in
the
first
case
of
authentication
in
which
you
know
that
someone
in
the
groups-
and
this
message,
we
already
achieved
some
certain
form
of
deniability,
because
you
don't
know
exactly.
You
cannot
pinpoint
exactly
so
who's
who
author
are
messaging
that
conversation,
but
the
idea
of
this
that
I'm
going
to
propose
is
mostly
go
to
the
second
form
of
authentication
in
which
you're
using
digital
signatures
and
try
to
come
up
with
a
proposal
to
have
a
deniable
weight
for
these
stronger
notion
of
authentication.
H
C
H
Okay,
yes,
and,
as
I
said
in
the
first
in
the
first
form
of
authentication
that
mls
has,
we
already
have
a
form
of
wikidine
ability,
because
no
one
can
actually
pinpoint
who
exactly
send
the
message
on
the
com.
On
the
group,
we
can
say
that
someone
in
the
group
send
a
message,
but
we
cannot
say
who
exactly.
H
H
It
was,
allowing
people
to
reveal
the
key
as
a
sender
or
as
a
receiver,
and
the
problem
with
this
is
that,
if
you
reveal
a
key
as
a
sender,
then
the
authentication
gets
diminished,
because
the
receiver
of
that
message
will
not
have
will
not
have
the
insurance
that
it
did.
This
message
was
offered
by
the
participant
who
was
intended
to
be
other,
but
it
could
have
been
authored
by
anyone
else.
So
at
the
end,
for
example,
oti
inspection
2
decided
that
only
the
receivers
who
should
reveal
the
appropriate
key.
H
The
problem
with
this
is
that,
of
course,
in
a
group
chat
setting.
You
cannot
reveal
the
keys
of
the
participants
receiving
it
because
you
are
never
sure
when,
indeed
the
message
has
been
received
because
it
could
have
been
received
by
a
participant
at
x,
amount
of
time
and
then
by
the
other
participant
an
x
plus
one
amount
of
time.
So
you
will
never
be
sure
when
indeed
the
message
has
been
received
by
them
all.
So
that
is
like
a
no.
H
H
The
credential
belongs
to
the
key
package
object
in
the
leaf
of
the
tree,
and
they
can
be
expired
because
they
have
a
lifetime
valid
extension
and
because
they
also
sometimes
you
can
revoke
them,
because
you
change
the
signature
algorithm
or
because
the
keys
get
compromised.
So
the
idea
is
to
use
the
same
capability
of
the
key
packages
to
be
expired
or
to
be
revoked
or
to
be
renewed.
H
Something
to
think
about
more
forward
is
also
which
kind
of
the
nobility
this
is.
This
is
not
a
traditional
deniability,
because
you
are
not
achieving
the
nobility
every
time
that
you
receive
a
message,
but
rather
something
that
you,
after
you
receive
x,
amount
of
messages
and,
after
the
application
say
hey
it's
time
to
revoke
this
message,
then
you
actually
reveal
the
key.
So
I'm
somewhat
more
similar
to
what
post-compromise
security
is.
This
is
something
like
post-compromising
ability
and
there's
still
missing
the
details
to
correctly
define
this
property.
H
Also,
what
happens
to
messages
that
arrive?
There
are
way
out
of
time
when
they
arrive
that
arrive
really
delayed.
In
this
case,
those
messages
will
not
be
strongly
authenticated
anymore,
because
the
key
has
already
been
revealed,
but
this
is
the
same
case
of
what
happens
if,
for
example,
you
rotate
the
key
and
you
lose
the
access
to
the
corresponding
private
key
or
you
change
the
signature
algorithm
and
you
update
after
that.
So
it's
the
same
case.
H
This
is
somewhere
related
also
to
what
richard
was
already
talking
at
the
beginning,
about
signature,
keys,
being
the
device
or
being
unique.
In
this
case
it
would
be
better
if
they
are
unique
to
device,
because
it's
much
more
easier
to
rebuild
a
key
per
device
rather
to
coordinate
between
devices
to
say
to
all
of
them.
H
C
C
Myself
in
the
queue
from
before
but
I'll,
I
also
have
a
question
here
so
I'll
go
ahead
and
ask
it
so
does
this
draft
so
so
I
I
admit
I
haven't
dived
into
this
draft
real
deeply,
but
I
think
we
can
debate
like
whether
this
you
know
what
what
deniability
we're
getting,
what
the
operational
challenges
are.
What
I,
what
I'd
like
to
ask
instead,
is
you
know,
regardless
of
what
we're
doing
here,
do
you
need?
H
No,
it
doesn't
require
changes
to
the
main
protocol.
That
was
one
of
the
of
the
ideas,
also
that
it
shouldn't
change
the
main
protocol
that
much
it
will
be
added
as
an
extension.
So
anyone
who
has
this
as
an
extension,
then
the
keys
will
be
get
revealed
by
the
authentication
service
or
what
any
kind
of
other
application.
But
it's
not
changing
the
main
draft
itself.
A
A
Let's,
I'm
gonna
basically
try
to
take
this
to
the
list
because
it
looks
like
this
is
something
that
we
should
be
looking
at
and
we
just
have
to
make
sure
that
we
document
any
security
considerations
as
you've
got
going
there.
So,
knowing
that's
one
of
your
focus
of
your
jobs,
that'll
be
great
all
right,
so
I
think
we're
going
to
switch
switch
drafts
here.
A
A
A
I
Hallelujah,
okay,
I
was
getting
nervous,
then
I
start
clicking
random
buttons
and
it
gets
worse.
So
all
right,
yeah,
I'm
gonna,
try
and
summarize
a
bit
the
the
the
state
of
cryptographic,
analysis
of
mls-
and
let
me
start
by
saying
you
know
a
real
in-depth
analysis
of
this
is
kind
of
out
of
the
scope
here,
and
so
I'm
just
gonna
try
and
give
you
the
high
level
and-
and
you
know,
ask
ask
whatever
questions
so?
Can
we
go
to
the
next
slide.
I
D
I
Let's,
let's
start
out
next
slide
all
right,
so
if
nothing
else
right,
then
this
slide
is
kind
of
the
takeaway.
I
think
that
this
is
sort
of
my
summary
of
the
state
of
all
the
different
research
projects.
There's
been
a
fair
bit
of
work
on
this,
and
this
is
kind
of
my
takeaway
right
now
of
where
we
stand.
I
I
Okay,
so
this
is
like
the
application
messages.
Okay,
those
things
they're,
private,
that's
sort
of
goal,
number
one!
That's
been
really
analyzed
here,
then
we
have
authenticity
of
content.
So
that
means,
if,
if
your
client
says
this
message
came
from
bob,
it
came
from
bob
transcript.
Consistency
is
another
property.
We've
been
analyzing
in
various
guises.
That
means,
if
alice
and
bob
can
talk.
I
I
What
kind
of
attacker
you're
getting
in
right,
so
sort
of
the
type
of
attacker
that
you
know
more
or
less
we've
been
looking
at?
You
can
think
of
them
well,
they're
extremely
powerful
on
the
network
side
of
things:
okay,
so
they're
they're
man
in
the
middling
all
traffic.
Here
they
basically
own
the
delivery
server.
There
is
no
distinction
between
the
delivery
server
and
the
attacker
here.
They
can
schedule
packets
at
will.
I
They
can
drop
packets,
modify
packets
right,
so
network
side
super
powerful
in
some
of
the
most
advanced
security
models,
but
they've
been
considered
we're
also
looking
at
insiders.
Okay,
so
these
are.
These
are
participants
in
legitimate,
so
legitimate
participants
in
groups
who
are
trying
to
use
their
view
of
this
group
state
to
do
bad
things
like
break
privacy
of
content
in
some
other
group,
or
even
an
artificial
group
that
they
created
and
then
invite
people
to
right.
This
is
the
insider
side
of
things.
This
is
why
mls
does
blanking.
I
For
example,
it's
because
we're
worried
about
insiders,
then
we
another
thing
the
these
type
of
attackers
can
do.
Is
we
give
them
the
ability
to
compromise
group
members,
which
means
specifically
means
they
can
say:
okay,
alice's
cell
phone?
I
want
to
know
everything,
that's
on
alice's
cell
phone
and
of
course
you
know
there
are
limits,
then,
to
the
security
we
get,
because
you
can't
ask
for
privacy
the
moment
they
compromise
alice's
cell
phone,
but
we
show
that
the
pcs
part
of
mls
works.
I
Well
and
then
in
other
words,
even
though
they're
compromising
first
alice-
and
this
then
that
then
this
the
the
protocol
is
constantly
healing
itself
and
we
show
that
this
mechanism
works
quite
well.
It
really
does
heal
itself
quite
well
and
another
thing
that
another
capability
of
the
adversary
that
we've
been
looking
at
is
what
happens
if
the
adversary
can
start
registering
keys
in
the
pki
right.
I
I
What
security
properties
do
we
still
get
if
the
adversary
can
do
these
things
and
remember,
there's
this
this
notion
of
certificate
right.
So
if,
if
the
adversary
doesn't
have
the
ability
to
compromise
a
certificate,
make
a
fake
certificate
for
some
key,
it
registered
doesn't
necessarily
matter
that
much
that
the
adversary
can
register
these
things,
because
all
honest
clients
want
to
be
checking
certificates.
I
So
that's
kind
of
our
route
of
trust
is
the
certificate,
not
the
key
server
itself
and
that's
great
because
this
is
in
line
with
this
end-to-end
mentality
here
and
the
crypto
has
reflected
this
and
showed
that
as
long
as
your
certificates
are
secure,
the
key
server
we're
not
really
relying
on
them
they're,
just
basically
another
distribution
channel,
it's,
but
it's
the
certificates.
That
matter,
which
is
good
because
that's
kind
of
the
intuition,
I
think
I
at
least
had-
and
I
think
that's
born-
played
out
in
the
crypto
analysis:
hey
joel
how's.
The
fact,
though,.
A
I
I
One
of
the
main
focuses
has
been
this
thing
that
you
know
people
are
calling
a
continuous
group
key
agreement
which
kind
of
encapsulates
treechem,
but
also
the
stuff
around
treecamp.
That
makes
it
more
authentic
that
you
know
authentication
mechanisms
like
the
confirmation
tag,
the
max
that
kind
of
stuff,
and
we
bundle
that
all
up
into
its
protocol.
That's
it's
inside
mls,
it's
called
continuous
group
key
agreement
and
the
functionality
it
provides.
Is
you
essentially
manage
your
group?
I
So
you
can
add
people
remove
people
update,
but
you
don't
you
don't
get
all
the
way
up
the
application,
the
key
schedule.
It's
just
every
epoch,
you
get
a
symmetric
key,
and
this
symmetric
key
is
only
known
to
group
members
and
you
want
pcfs
for
this,
and
so
this
has
like
been
a
lot
of.
The
focus
has
been
on
this
because
kind
of
to
once
you've
got
that
going.
All
the
way
to
secure
group
messaging
is
not
that
much
more
complicated.
You
basically
need
a
smart,
it's
not
trivial,
but
you.
I
I
Some
of
the
work,
though,
has
actually
focused
on
trying
to
really
do
full
stack,
mls,
some
that's
going
to
come
out,
karthik,
benjamin
and
I'm
not
sure
sorry
meldrum,
I
don't
know
his
first
name
have
done
also
really
interesting.
They
did
full
stack
for,
but
the
version
seven
they're,
just
in
the
works
of
updating
that
to
the
current
version
and
one
thing
I
really
like
about
their
work-
is
it
uses
automated
proof
tools
right?
I
So
that's
quite
different
than
most
of
the
other
work
which
has
been
pen
and
paper
proofs,
and
so
I
really
like
that.
We're
doing
both,
because
the
automated
like
really
gives
us
this,
like
high
level
of
assurance
in
the
quality
of
this
proof
and
the
pen
and
paper,
is
really
good
at
explaining
why
things
are
secure.
I
What
is
it
about
the
mls
protocol
that
gives
us
this
property
or
that
property,
rather
than
just
certifying
that
it
does
give
the
property
and
that's
good
if
we
want
to
start
understanding
how
we've
modified
so
they're,
quite
complimentary
yeah?
So
that's
another
aspect
of
how
the
research
has
been
going
next
slide.
I
I
I
don't
know
how
we
are
in
time,
but
I
wanted
to
like
get
a
little
more
into
what
these
capabilities
are,
because
really
that's
kind
of
the
goal
that
the
crypto
has
been
mainly
focused
on
is
so
we
want
to
understand
what
is
an
insider
attacker
and
I
guess
most
of
the
things
I've
said
already:
network
full
control,
insider
participating
in
legit
groups.
Pki
can
register
keys
at
will,
but,
like
so
there's
no
assumption
about
proof
of
knowing
your
secret
key,
that's
a
common
thing,
pki
sort
of
assumes.
We
don't
need
any
of
that.
I
He
can
register
your
public
key
as
his
own
if
he
wants,
even
if
he
doesn't
know
your
secret
key.
So
that's
really
good
means
very
weak
assumptions
about
our
keys,
key
distribution
stuff
fully
adaptive
can
make
all
his
attack
decisions
on
the
fly
that
makes
things
very
difficult,
often
to
prove
in
crypto.
But
that's
that's.
How
things
have
been
done
drives
the
execution,
so
the
adversary
in
these
models
gets
to
say
he
gets
to
drive,
says
alice.
You
need
to
add
bob
to
group
x,
charlie.
You
need
to
remove
yourself.
I
So
that's
also
good,
because
it
shows
that
even
if
the
attacker
gets
to
have
like
the
lucky
execution,
which
basically
he's
driving
it's
not
going
to
help
him
here
gets
to
corrupt
users
and
one
other
thing
we've
looked
at
is
rngs
susceptibility
of
mls
to
bad
rngs
leaking
of
random
coins,
even
all
going
all
the
way
to
the
point
where
the
adversary
gets
to
decide.
Okay,
alice,
your
rng
is
going
to
output
this
string
next,
so
we've
also
been
looking
at
how
mls
behaves
against
that
there's.
I
Actually
a
pr
coming
up
that
might
strengthen
things
a
little
bit
as
and
that's
a
result
of
this,
this
hardening
against
bad
rngs.
But,
of
course,
there's
limits
and
that's
this
is
where
the
model
says.
Well,
these
are
your
trust
assumptions
you
got
to
make
sure
this
stuff
is
holes.
The
adversary
cannot
make
fake
certificates.
I
So
this
is
the
last
slide.
This
is
my
musings
on
where
to
go.
What
other,
like
crypto
research?
We
would
be
nice
to
have
yeah
so
metadata
security.
As
far
as
I
know,
no
one's
really
looked
at
that
mls
clearly
considers
it.
Otherwise
why
do
we
have
mls
cypher
suite?
Why
is
not
everything
being
you
know?
Why
is
our
wire
format
not
just
mls
plain
text?
Well,
because
we
might
very
well
care
about
metadata
security,
encrypting
headers,
I
don't
know
any
analysis
about
that
at
the
crypto
level.
I
The
automated
analysis
from
benjamin
carthage,
those
guys
that's
lagging
a
little.
We
you
know
that's
going
to
be
updated
to
mls
version,
11.,
really
looking
forward
to
that
post
quantum
analysis.
Further
out
on
the
roadmap.
We've
said
we
want
to
support
post
quantum.
We
have.
We
have
a
pq
cipher
suite.
You
know
that
option
is
there,
but
there's
no
analysis
yet
right,
there's,
no
quantum
random
oracle
security
analysis.
What
if
you
plug
in
a
post
quantum
secure
cipher
suite,
do
you
really
get
post
quantum
security?
D
I
Probably
yes,
but
we
haven't
done
no
one's
done
the
analysis
and,
of
course,
analyzing
the
more
advanced
features
of
mls
right.
We
got
these
psks
that
we
can
mix
in
external
commits.
We
want
to
maybe
upgrade
cypher
suite
or
protocol
version
mid
session.
These
kind
of
things,
as
far
as
I
know,
have
not
really
been
analyzed
in
some
crypto
sense.
So
to
do
so
yeah!
A
No,
I
mean
I
thank
thanks
again
for
this
and
I
guess,
having
gone
through
the
tls
reviews,
there's
a
bunch
of
caveats
that
always
happen,
and
we
we
appreciate
any
work
that
you
and
your
compatriots
do
before
before
the
ending
of
the
protocol
and
again
like
I
said,
I
think
we
need
to
make
sure
that
we
understand
the
input
that's
provided,
so
we
make
any
changes
to
try
to
mitigate
anything,
because
otherwise,
there's
kind
of
no
point
and
you
guys
can
show
up
early.
So
thanks.
A
And
that
wraps
us
up,
like
I
said,
we'll,
probably
try
to
have
an
interim
pr,
I'm
going
to
shoot
for
early
april
to
try
to
address.
I
know:
brenda's
got
some
issues.
We
should
probably
go
maybe
more
in
depth
on
this
security
analysis
stuff
and
any
any
additional
changes
on
the
protocol
and
architecture
draft
so
stay
tuned
and
let's
move
it
to
the
list.
Thank
you
very.