►
From YouTube: IETF109-MLS-20201119-0900
Description
MLS meeting session at IETF109
2020/11/19 0900
https://datatracker.ietf.org/meeting/109/proceedings/
C
A
C
B
E
F
E
E
B
C
B
All
right,
I
think,
we're
here:
let's
do
this
welcome
to
mls
meeting
it's
thursday.
Hopefully
you
guys
have
seen
all
this
stuff
turn
your
video
off
meet
your
microphone
unless
you're
speaking,
obviously
you
made
it
here
at
meat
echo.
I
don't
know
if
the
audio
is
gonna
work,
if
it's
only
but
and
the
jabber
I
think,
is
down
as
well,
so
I
think
we're
just
gonna
plow
ahead
and
we'll
deal
with
it
later.
B
Oh
great
cool,
there's
the
address
there
mls
at
jabra.iotf.org.
I
believe
that
the
chat
in
meet
echo
actually
we're
lazy
to
jabber.
So
if
anybody
is
in
jabber
land
and
does
like
do
a
mic
colon,
please
feel
free
to
jump
in,
and
you
know
relay
that
for
me
and
nick
as
well
again:
here's
the
notewell,
basically,
you
know
put
rules
and
policies
to
play
along
with
the
itf,
we're
recording
it
be
polite.
B
B
Our
agenda
is
pretty
straightforward:
we're
going
to
go
through
some
minus
trivia,
we're
going
to
have
an
architecture
update
and
then
the
rest
of
the
time
we're
going
to
do
with
the
protocol.
Richard
lets
me
know.
The
chances
of
us
going
to
full
two
hours
is
somewhat
minimal,
so
that
might
be
good,
so
everyone
can
get
back
in
bed
so
we're
just
basically
just
gonna
jump
over
he's
got
some
slides,
I've,
uploaded
them
and
bedroom
and
also
gave
me
some
slides
in
the
architecture,
so
we're
gonna
go
through
status.
B
Yes,
I'm
in
the
cody
md
and
if
anybody
wants
to
join
me,
awesomely.
Thank
you.
Thank
you
very
much,
jonathan,
so
the
status,
basically
the
architecture
draft
we're
going
to
talk
about
that
we're
basically
waiting
for
a
new
version.
The
mls
protocol
draft,
I
guess
technically,
is
no
longer
in
working
group
last
call
it
ended
yesterday
and
the
federation
draft
we
had
has
expired,
but
I'm
hoping
that
we'll
we'll
we'll
get
back
to
that
after
we
get
the
protocol
document
kind
of
up
the
out
of
the
way.
B
B
The
plan
is,
is
that
we
are
going
to
publish
a
draft
11
which
addresses
all
known
comments
and
then
we're
going
to
have
a
feature
freeze
where
we're
going
to
let
the
security
researchers
kind
of
beat
on
things.
For
a
little
bit,
we
haven't
quite
decided
how
long?
That's
going
to
be,
but
I
think
it's
going
to
be
long
enough,
that
we
can
get
multiple,
multiple
sets
of
researchers
to
actually
provide
us
some
input.
B
B
If
we
get
to
a
draft
13,
if
we've
had
this
analysis,
it
makes
things
a
lot
easier
for
the
ad
and
later
for
us
when
we
have
to
deal
with
comments,
because
the
the
document
will
be
reviewed
by
more
than
just
the
people
in
the
working
group,
it's
actually
going
to
be
other
people.
Security
researchers
will
make
sure
it's
clear
that
the
the
document's
doing
what
it
says
it's
going
to
do,
but
our
a.d
ben
is
going
to
do
a
review
and
then
whatever
he
tells
us
to
make
changes
to.
B
We
will
discuss
with
him
we'll
make
some
changes
and
we'll
have
a
draft
14
and
then,
after
that,
it
goes
into.
What's
called
the
ietf
last
call
it'll
be
two
weeks
and
then
you
know,
I
suspect
there
will
probably
be
some
other
procedural
things
that
we
maybe
miss.
You
never
know,
maybe
we'll
get
lucky
and
we
don't
need
a
draft
15,
but
a
lot
of
times.
This
is
where
you
get
cross
area
review.
B
So
there's
directors
that
will
kick
off
like
jen
aren't
they'll
tell
us,
we
did
our
iana
considerations
wrong
or
something
and
we'll
fix
it.
And
then,
after
that
it
goes
to
isg
review.
All
of
the
area.
Directors
from
the
itf
will
take
a
review.
They
will
find
even
more
things
and
we'll
probably
do
another
draft
16
to
try
to
get
get
through
them
once
we're
there.
Basically,
it
gets
approved
and
gets
dumped
into
the
rfc
editor
queue.
B
Then
there's
a
process
at
the
very
end
of
that
called
off
48,
which
is
where
basically
it's
copy
editing,
but
sometimes
they
find
other
things.
So
there
will
be.
There
will
be
other
changes
that
come
out
of
the
draft
come
out
of
the
process.
Sorry
they
end
up
resulting
in
a
draft
and
at
the
end,
we're
gonna
have
an
rc.
The
process
after
we
get
from
area
director
review
to
an
rfc,
it's
probably
three
months,
so
I
think
we're
looking
at
you
know,
six
to
nine
months
away
before
we
could.
F
Hey
this
has
been
paid
up
to
80.
I
think
the
three
months
from
80
to
review
from
80
review
to
rfc
might
be
a
little
optimistic.
The
rfp
production
center
is
like
still
dealing
with
this
giant
cluster
of
webrtc
stuff.
No,
it's
still
doing
238
yeah
I
mean
most
of
it
is
in
off
48,
but
there's
there's
still
some
knockoff
effects,
basic
knock-on
effects.
Basically,.
B
All
right
well,
fair
enough.
I
mean,
I
think
it's
it's
good,
because
basically
it
still
gives
people
additional
time
to
review
things,
and
I
mean
I
think
the
nice
thing
is
that
we're
we're
basically
following
the
tls
kind
of
pattern,
and
I
think
it's
good,
because
when
we
get
after
the
feature,
freeze
and
analysis
and
we
actually
get
review
chances
are
we'll
we'll
we'll
find
most
of
the
big
things,
there's
a
chance
that
we
can
find
other
things
that
are
worthwhile
to
change
later.
B
A
D
I
C
I
I
can
hear
you
know
sorry
technical
things
yeah,
so,
okay,
let
me
jump
in
now.
Thank
you.
So
the
the
idea
was
that,
a
few
months
back,
we
sent
an
email
to
the
main
english
saying
that
we
are
gonna,
do
an
editorial
pass
collectively
on
the
architecture
documents
and
the
timeline
shifted,
obviously
because
of
multiple
things
covered
and
the
delay
in
the
protocol
document
as
well.
I
The
idea
was
like,
basically,
we
could
sort
of
go
back
to
the
architecture
documents
once
the
the
protocol
document
was
stable,
but
I
think
we
are
pretty
in
pretty
good
shape
to
actually
look
at
it
now.
So
the
chairs
ask
the
editors
to
actually
take
a
pass
on
the
architecture
document
which
will
which
I'm
doing
right
now
and
ask
for
the
other
editors
to
review.
I
The
idea
is
that,
basically,
I
want
to
have
something
stable
by
december
7th
so
that
people
can
sort
of
input
from
that
point.
So
I
don't
think
there
are
many
many
actual
things
to
discuss.
We
are
gonna
pretty
aggressively
as
sean
mentioned
in
in
the
mailing
list.
We
are
pretty
aggressively
gonna
close
issues
and
try
to
solve
them.
Of
course,
but
like
allow
people
and
encourage
people
to
to
do
a
pass
on
the
architectural
document
after
december
7.,
so
the
idea
is
basically
we
expect.
I
I
mean
I
expect,
depending
on
what
the
chairs
think
is
good
idea,
but
I
I
would
expect
that
between
beginning
of
december
and
under
january,
we
have
something
like
everybody
feeling
issues
and
reviewing
producing
pr's
for
the
documents
and
that
we
can
recurse
on
that
multiple
times
until
we
we
have
something.
That's
that's
good,
but
I
expect
that
the
changes
to
the
architecture
document
are
pretty
limited,
it's
more
typically.
What
we're
interested
in
here
is
the
the
fact
that
we
are
missing.
I
Some
things
like
with
the
dms
protocol
is
quite
big
right,
it's
complicated,
so
we
we
definitely
miss
important
information
or
insights
on
the
protocol
and
especially
in
the
arctic
architecture
document.
Sorry-
and
we
want
to
describe
very
clearly
the
security,
the
security
guarantees
that
we
expect
with
much
more
precision
than
we
have
right
now
so
right
now
we
have
something
very
generic,
which
is
like
oh
yeah.
I
By
the
way,
this
protocol
wishes
to
provide
forward
secrecy
across
epochs
forward
secrecy
for
application
messages,
post
compromise
security
across
epochs
things
like
this,
but
it
actually
depends
on
many
things
right.
It
actually
depends
on
people
updating
regularly
on
people
sharing
or
not
sharing
their
identity
keys.
Things
like
this
are
actually
left
to
the
application
for
the
protocol
document,
so
the
architecture
at
least
should
mention
what
are
the
pros
and
cons
of
doing
such
things
like
using
signature
keys,
not
using
them
updating,
frequently
or
not,
updating
frequently.
I
But
you
know,
like
people
have
looked
at
it.
We
have
done
security
analysis
of
the
protocol
and
we
know
that,
depending
on
what
you
do
exactly,
there
are
some
slight
differences
in
terms
of
security
guarantees,
so
we
want
to
actually
make
make
those
guarantees
and
expectations
very
precise
in
the
architectural
documents
without
without
mandating
anything.
In
some
sense,
it's
going
to
be
an
information
of
what's
the
what
the
protocol
should
give.
I
I
So
we
don't
want
like
this
document
will
not
be
able
to
moderate
anything
right
in
terms
of
infrastructure,
but
it's
it
will
be.
It
will
be
able
to
provide
guidance.
The
services
documents
on
maybe
this
solution
is
one
possible
solution
to
actually
provide
some
reasonable
privacy
guarantees
in
your
infrastructure,
and
I
believe
that
we
should
do
that
after
the
architecture
document
is
done,
so
that
I
mean
at
least
it's
stable,
so
that
we
can
focus
on
federation
and
serve
their
assists
after,
like
in
q1
q,
probably
in
q1
and
of
q1.
I
Something
like
this
so
yeah,
that's
it
for
me.
I
think
I
think
after
december,
7
and
end
of
january
sounds
good.
I
don't
know
what
you
think,
sean
and
and
nick,
but
it
feels
like
pretty
reasonable
so
that
people
don't
have
to
work
in
the
like
at
christmas
and
use
new
year's
eve
things
like
this.
We
can
have
the
full
january
months.
There
is
no
urgency
for
that
document
anyway,
but
I
think
it's
completely
fair
to
get
back
to
it
right.
I
B
B
It
is
what
it
is.
The
only
thing
I
would
add
to
your
summary
is
that,
in
terms
of
getting
to
getting
through
the
process,
the
only
way
that,
like
the
follow-on
process
like
to
get
through
the
isg,
is
going
to
be
able
is
going
to
happen
when
we
actually
get
the
architecture
and
protocol
document
together
and
get
them
moving
forward.
So
they'll
probably
go
forward
as
a
package,
so
I
think
it
kind
of
it
makes
sense.
So
all.
C
A
All
right
is
that
visible,
it's
all
of
its
bright
pinkness.
I
figured
I'd
use
a
little
bit
of
a
you
know,
visual
energy,
to
keep
people
awake
across
time
zones.
So
this
is
going
to
be
an
update
on
the
latest
stuff
on
the
protocol.
It's
going
to
be
blend
of
me
and
raphael
and
joelle
all
of
whom,
from
looking
at
different
aspects
here
we're
going
to
go
through
kind
of
what
we've
gotten
done
recently
for
folks
who
might
not
have
been
tracking
along
in
detail.
A
A
A
Authentication
of
membership
in
the
group
and
a
confirmation
that
it
commits
produced
the
right
output,
so
the
confirmation
that
the
recipient
of
a
commit
got
the
same
output
at
that
sender
did
we
had
had
this
confirmation
tag
hanging
around
for
a
while.
We
called
it
a
tag
now
moved
it
to
the
end
so
that
it
covers
the
signature
as
well.
A
This
is
due
to
some
work.
I
think
that
joelle
did
with
athena,
yost
and
martin
lunarchik,
finding
some
some
issues
with
not
covering
that
signature
with
the
confirmation
tag,
so
that
simplifies
the
structure.
A
little
bit
simplifies
that
little
select
statement
and
gets
some
better
security.
Moving.
The
confirmation
tag
down
that
same
group
also
noticed
some
issues
that
if
you
get
an
mls
plain
text,
you
know
you
get
a
signature
on
it
on
the
left
hand
side,
but
you
don't
get
any
authentication.
A
The
signer
is
actually
in
the
group
until
you
accepts
to
the
degree
that
you
you
look
at
the
verification
key
in
your
group
tree.
So
immediately
you
don't
get
any
authentication
that
the
sender
knows
the
group
secret.
So
if
someone,
you
know
compromised
the
signing
key,
but
not
the
group
secrets,
then
they
could
send
these
mls
plaintexts
into
the
group.
So
this
membership
tag
is
just
a
mac
over
everything.
A
I
A
Sure
thanks
second
cool
thing:
thanks
to
some
good
work
from
rita
hale
and
conrad
cobrook,
we
have
a
new
nice
psk
framework.
It
works
more
or
less
like
you'd
expect
people,
someone
who
wants
to
add
a
psk
at
an
epoch
sends
out
a
proposal.
You
can
get
multiple
those
proposals,
so
we
have
a
scheme
for
combining
multiple
psks
and
then
they
get
injected
into
the
key
schedule
as
you're
transitioning
from
one
the
last
xbox
in
its
secret
to
the
current
epochs
epoch
secret.
A
Really,
the
novelty
here
is
this
proposal
mechanism
and
there's
a
corresponding
signaling
welcome.
I
think
this
is
kind
of
nice
because
it
incorporates
you
know
it's
kind
of
inspired
by
the
tls13
design,
where
you
have
psk
ids
and
kpsks
and
incorporates
some
learnings
from
recent
tls
and
follow
on
work213.
A
So
we
have,
I
think
one
thing
that
has
been
done
more
recently
and
tls
is
folks
trying
to
introduce
structured
labels.
So
you
can
have
specific
labels
that
have
internal
structure
for
specific
use
cases.
We're
building
that
in
from
the
start
here
and
I
think
jonathan
hoyland
has
done
some
work
on
looking
at
and
also
stability
and
the
post
quantum
folks,
looking
at
how
you
incorporate
multiple
psks
or
multiple
entry
sources
into
the
key
schedule.
B
A
A
One
thing
that
came
up
is
kind
of
a.
This
is
a
kind
of
a
bit
of
a
performance
improvement.
You
know
before
the
center
of
a
proposal
could
send
out
a
bunch
of
I'm
sorry.
The
center
of
a
commit
could
send
alongside
that
a
bunch
of
proposals
and
those
proposals
would
each
be
individually
signed
in
their
own
envelopes.
Plain
text,
this
change
with
this
change.
A
Those
proposals
can
just
go
directly
in
the
commit,
and
so
you
save
a
lot
of
signature
overhead,
a
lot
of
bandwidth
overhead
and
just
send
the
proposals
in
line
now.
Syntactically
with
that,
you
know
we
wanted
to
preserve
this
property,
that
we
have
a
single
proposals
array.
So
it's
clear
what
order
the
proposals
are
applied
in,
and
so
what
we
did
is
just
change
that
array
of
proposals
from
being
a
list
of
references
to
proposals
by
hash
to
a
list
of
proposal
or
references.
A
So
you
can
get
the
proposal
by
value
or
by
reference.
So
we
maintain
that
ordering,
but
we
can
indicate
things
by
value
or
by
reference.
So
this
lets
the
committer
just
send
along
a
bunch
of
stuff
to
apply
as
part
of
that
commit.
So
you
can
imagine
that
if
the
committee
wanted
to
say
sentence,
add
a
psk
as
part
of
the
commit.
You
just
add
the
that
proposal
to
the
end
of
the
proposals
vector.
A
This
simplifies,
in
particular,
some
of
the
external
commit
stuff
which
raphael
will
talk
about
in
a
moment
and
another.
This
is
kind
of
consistent
with
another
idea
that
we
discussed
earlier
that
the
kind
of
design
principle
that
the
way
you
extend
the
commit
message
is
with
new
proposal
types
as
opposed
to
having
extensions
in
the
commit
message
itself.
So
you
know
being
able
to
put
proposals
directly
in
the
commit
message.
A
A
A
So
when
you
generate
a
subgroup
much
like
with,
I
think,
there's
a
nice
analogy
to
to
tls
and
resumption
here
that
the
key
schedule
produces
resumption
secrets
and
you
can
use
those
secrets
to
connect.
One
group
state
to
other
group
states
so
branching
is
one
instance
of
that,
where
you
want
to
instantiate
a
subgroup
or
a
related
group,
you
can
pull
that
resumption,
psk
out
of
the
prior
group
and
then
and
insert
it
into
the
subgroup
or
the
branch
group.
A
So
that's
kind
of
a
nice
application
of
the
psk
work
that
was
done
more
optimization
work
on
the
third
bullet
here,
the
ratchet
tree
for
these
cases,
where
the
the
delivery
service
might
cache
some
of
the
tree
information
based
on,
say,
plain
text,
handshake
messages.
If
the
server
is
following
along,
then
it
can
provide
the
tree
and
it
doesn't
need
to
be
provided
end
to
end
in
the
welcome.
A
So
the
welcome
just
provides
a
commitment
to
the
tree,
not
the
tree
itself.
It
can
optionally
include
the
tree
in
an
extension,
just
a
performance
optimization
there
more
work
from
alberta
and
conrad.
This
authentication
secret
derived
from
the
key
schedule.
This
provides
kind
of
a
yeah
in
a
lot
of
apps.
Today
you
have
these
security
codes
that
are
that
people
can
compare
to
verify
that
they
have
the
same
crypto
state.
So
here
we
can.
A
Just
since
we
have
this
framework
for
deriving
stuff
with
the
off
the
key
schedule,
we
can
just
derive
another
value
off
the
key
schedule
that
can
be
used
for
that
purpose.
So
you
can
compare
this
and
you
know
you're
in
the
you
know.
If
everyone
in
the
group
has
the
same
authentication
secret,
then
they
know
that
they
have
exactly
the
same
crypto
state
for
that
state
of
the
group
and
finally,
there's
been
some
concerns
off
and
on
about
deniability
sophia.
A
Chile
did
some
review
on
this
and
proposed
one
one
change
to
improve
compatibility
with
deniability
going
forward,
which
is
to
have
a
little
bit
of
decoupling
between
the
signing
keys
that
are
in
the
in
the
mls
transcript
and
the
signing
keys
that
are
used
for
for
verifying
messages
that
landed
after
draft
10.
But
it's
it's
in
master
right
now.
A
I
can't
remember
if
that
yeah,
I
think
that
was
before
before
we
made
the
switch
to
proposal
commit
we
had
constant
time.
Add
where
you
could
you
know
you
didn't
have
to
change
anything
about
the
tree.
Besides
the
leaf,
we
re-added
that
in
in
draft
10,
forgetting
the
details
of
how
that
was
done,
but
you
know
now
ads
can
be
kind
of
gonna
be
done
in
constant
time.
You
don't
have
to
all
right.
This
is
this
is
where
we
made
the
the
the
update
path
in
the
commit.
A
A
A
A
B
A
A
A
I
There
is
one
section
that
was
mentioned
multiple
times,
but
we
didn't
really
address
and
we
should
definitely
decide
whether
we
are
going
to
address
it
or
not.
Is
the
application
message,
location
thing
so
right
now
and
an
attacker
can
actually
like.
I
would
hardly
remove
messages
at
the
end
of
the
application
messages.
Hello
is
everybody
actually
knowing.
I
I
A
J
J
All
right,
okay,
so
yeah.
So
this
is
basically
what
this.
This
concerns
a
feature
called
parent
hash,
which
was
originally
introduced
by
karthik
and
benjamin
when
they
pointed
out
that
we
need
to
be
able
to
authenticate
this
tree,
in
particular,
to
give
guarantees
to
people
joining
the
group
right
and
so
what
we
did
is
or
what
they
did
at
the
time
is
they
introduced
this
notion
of
a
parent
hash
that
hashes
a
part
of
the
tree,
and
you
end
up
with
actually
a
sequence
of
parent
hashes.
J
Each
node
has
its
own
parent
hash
to
find,
and
then
you
put
the
the
last
one
down
the
leaf
every
time,
you're
doing
an
update
path,
and
then
you
sign
your
entire
leaf,
and
that
includes
the
parent
hash
and
so
in
so
doing
you're
kind
of
authenticating
certain
stuff
in
the
tree.
But
then
there
was
some
amount
of
debate
around
how
exactly
to
define
this
parent
hash
and
at
the
time
there
were
then
kind
of
two
candidates
and
we
went
with
one
which
hatched
in
less
because
we
were
hoping.
J
So
we
then
proposed
a
pr
that
addresses
this
attack.
So
this
is
basically
what
I'm
going
to
tell
you
about.
Now
you
can
go
to
the
next
slide.
Please,
okay!
So
first
I'll
tell
you
a
little
bit
about
what
the
attack
is,
because
that's
really
going
to
motivate
them
the
changes
as
well,
so,
first,
the
the
way
that
the
the
whole,
the
parent
hash,
has
been
defined
up
till
now,
this
sort
of
more
minimal
way
of
doing
we've
defined
it
in
the
past.
J
It's
basically
when
you
do
an
update
path,
so
you're
doing
a
commit
you're,
inserting
a
bunch
of
keys
on
your
direct
path
and
you
pretty
much
just
hash
back
down
to
your
leaf
again
only
those
hpk
public
keys
right.
So
here
on
the
top
left,
we've
got
a
picture
of
a
small
group
with
alice
bob
and
charlie
alice.
Just
did
the
most
recent
commit.
That's
why
her
direct
pass
is
mark
blue
and
so
in
particular.
She
would
then
hash.
J
So
the
issue
with
this
kind
of
in
a
nutshell,
is
that
it
really
doesn't
tell
you
anything
about
who
was
told
these
secret
keys
that
correspond
to
these
hpk
public
keys.
In
other
words,
it
makes
it
easy
to
or
possible
to
create
ratchet
trees
that
violate
the
two
invariant,
which
leads
to
other
bad
things.
Things
like
removes
not
really
working,
as
if
you
think
you
removed
somebody,
but
in
reality
you
didn't
really
remove
them
from
the
group.
J
So
here's
an
example
of
this,
like
a
sort
of
pretty
minimal
example
of
how
this
attack
would
work.
Bob
is
our
attacker.
So
this
is
about
insiders
all
right.
This
attack
would
be
mounted
by
an
insider
somebody,
who's,
actually
a
participant
in
a
legitimate
group,
and
the
legitimate
group
is
at
the
top
left.
J
It
contains
alice,
bob
and
charlie
right
now,
let's
did
the
most
recent
commit,
as
we
said
so,
here's
what
bob
does
bob
constructs
a
fake
ratchet
tree
like
an
artificial
one,
and
so
it's
it's
a
fake
group
and
it's
the
top
right
ratchet
tree,
and
then
he
invites
dave
who's.
The
victim
of
this
attack
to
this
ratchet
period.
Okay,
so
in
other
words
we
now
one
of
the
main
thing
to
notice.
J
Is
that
the
way
he
constructed
this
tree
is
he
took
this
direct
path
from
alice,
which
is
a
legit
direct
path,
but
then,
instead
of
putting
himself
where
he
was
in
the
actual
group,
he
switched
out
and
put
charlie
there
right,
and
then
he
put
himself
in
charlie's
spot
then
creates
this
proposal
to
add
dave
and
commits
to
it.
So
you
end
up
with
this
other
this.
J
But
of
course
the
attack
where
things
have
started
to
go
wrong
here
is
that
bob
actually
knows
the
hpk
secret
of
alice's
parent,
because
in
the
real
group
that's
also
on
his
direct
path.
But
in
this
fake
group
it
looks
like
it's
not,
he
doesn't
know
it.
It's
not
on
his
direct
path.
So
the
next
thing
he
does
is
he
now
you
know,
gets,
tells
dave,
hey,
look!
I
want
to
leave
this
group
and
gets
dave
to
commit
to
removing
bob
so
in
the
removal
process.
How
does
that
work?
J
Well,
we
blank
bob's,
you
know,
dave
announces
this
this
commitment
and
then
everybody
will
everybody
being
only
dave,
because
alice
and
charlie,
you
know,
aren't
even
aware
of
this
group.
Will
blank
bob's
leaf
key
and
then,
which
means
it'll
leave
that
node
alice's
parent
node
intact
it'll
leave
the
same
hpke
key
there,
which
bob
actually
knows
the
secret
to,
and
in
particular
it
even
encrypts
the
rude
secret
to
that,
so
bob
can
actually
still
decrypt
this
new
rude
secret.
J
This
this
commit
secret,
and
so
he
can
compute
the
new
key
schedule
for
this
new
epoch.
Despite
the
fact
that
dave
thinks
he's
removed
bob
from
the
tree.
In
other
words,
this
turned
into
an
attack
where
a
removal
did
not
actually
have
the
effect
we
would
expect,
and
the
real
problem
here
is
that
bob
was
able
to
create
a
tree
that
violated
the
tree
invariant.
J
That
was
really
the
cause
of
this
attack.
So
this
whole
class
of
attacks-
you
can
do
a
couple
different
things
with
this,
but
this
is
the
core,
and
the
problem
is
that
the
signature
at
alice's
leaf,
which
includes
this
parent
hash,
doesn't
authenticate
enough.
It
doesn't
bind
in
who
alice
told
each
one
of
these
new
hpk
secrets
to
so
this
is
what
we
address
with
this
pr
next
slide.
H
J
We
we
actually
figured
out
that
you
can
do
this
a
little
more
indirectly,
maybe
for
reasons
of
deniability
or
just
simplicity
really,
and
it's
enough
to
just
include
into
the
parent
hash.
Every
time
you
want
to
include
an
hpk
public
key
of
a
node
covered
by
a
parent
hash.
You
also
include
the
resolution
of
the
sibling
on
the
co-path
right.
So
that's
exactly
that
correspond
so
actually
the
hpk
keys
of
this
resolution
that
corresponds
exactly
to
the
keys
to
which
the
hpk
secret
is
being
sent
right.
J
J
So
here's
a
here's,
a
pictorial
depiction!
You
know
we
have
a
small
tree
with
three
three
leaves,
and
this
shows
how
you
would
compute
parent
hash
if
leaf.
Two
does
a
commit
all
right,
so
that
means
leaf.
Two
has
inserted
new
keys
at
node,
one
and
node
3
on
node
2
as
well,
and
so
now
it
comes
time
to
compute
the
parent
hash
and
the
way
it
works.
Is
these
red
arrows
indicate
which
values
you're
putting
into
the
hash
when
you
compute
the
parent
hash
at
a
node
right?
So
you
look
at
node
one.
J
J
In
addition,
you
also
include
the
resolution
at
node,
four,
all
right
and
that
sort
of
binds
into
this
parent
hash
value,
not
just
the
fact
that
oh,
this
is
the
key
at
node
three,
but
also
where
did
you
send
the
secret
key
corresponding
to
that
key?
Where
did
where
did
the
person
at
least
two
send
it?
They
sent
it
to
the
resolution
of
node
four
right,
so
that's
the
parent
hash
at
node
one
and
then
the
parent
hash
at
node
two.
J
But
of
course,
there's
a
little
bit
of
a
caveat
here,
which
is,
if
you
see
the
name
of
the
field
in
the
data
structure,
we
called
it
original
sibling
resolution
and
that's
because
the
following
thing
this
makes
this
is
all
clean
and
simple
at
the
time
of
a
commit.
But
of
course
the
whole
point
of
these
parent
hashes
is
that
five
epochs
later
when
somebody
joins,
the
group
gets
a
welcome
message.
They
want
to
verify
these
parent
hashes,
which
means
they
should
be
recomputing
the
parent
hashes
right.
J
So
you
got
to
make
sure
that
when
you
recompute
the
parent
hash
for
a
given
node,
say
node
1
that
you'll
end
up
with
the
same
value
as
the
person
as
as
did
the
person
at
the
time
who
who
put
it
into
the
tree,
namely
the
person
at
least
two
and
in
the
meantime,
in
these
intermittent
father
blocks,
things
can
change
in
the
tree
right.
There's
constantly
the
tree's
constantly
changing
in
every
epoch.
J
So
we
have
to
make
sure
that
the
way
we
define
these
parent
hatch
is
invariant
to
any
change
to
the
tree,
which
will
preserve
the
public
key
at
node.
One
because
the
moment
the
moment,
the
the
public
key
at
node
one
changes.
We
don't
care
about
recomputing
the
same
parrot
hash
anymore,
so
it
only
has
to
be.
This
definition
of
parenthesis
only
has
to
be
invariant
to
changes
of
the
tree
that
don't
affect
the
public
key
at
node
one.
How
can
it
be
affected?
Well,
either
node
one
can
be
blanked,
yep
questions
so.
A
I
haven't
quite
verified
this
to
convince
myself
totally,
but
I
think
we're
kind
of
okay
here,
because
the
parrot
hashes
are
all
sort
of
downward
looking,
they
only
incorporate
stuff
incorporate
the
parent
stuff,
but
they
only
are
kind
of
visible
lower
in
the
tree.
So
here,
for
example,
if
four
updated
and
overwrote
nodes
four
and
three
then
the
hashem
note
and
node
one
would
no
longer
verify
node
three,
but
that's
already
kind
of
accounted
for
in
the
validation
algorithm.
You
would
still
be
able
to
validate
that.
A
You
know
the
signature
over
the
parenthesis.
Node
two
verified
the
parenthesis
node
one,
which
then
would
verify
the
both
the
public
key
in
node
one
and
the
resolution
in
node
zero.
So
you
still
kind
of
have
that
invariant.
So
I
actually
think
that
this
that
we're
pretty
safe
on
this
consistency
count.
A
J
J
So
the
more
general,
no
definition
we
have
a
parent
hash
which
collapses
to
the
same
thing
and
the
commit
moment,
but
later
on
may
be
important.
This
generalization
is
what
you
actually
take
is
the
resolution
of
the
co-path
node.
But
then
you
take
out
the
nodes
which
are
unmerged
at
the
parent,
so
when
you're
computing,
parent
hash
is
one
you
take
the
resolution
of
four
and
you
remove
anything,
that's
unmerged
at
three.
J
So
now,
if
you
were
to
add
a
fifth
leaf,
yes,
it
gets
added
to
the
resolution
of
four,
but
it
would
get
removed
again
because
it's
also
an
unmerged
leaf
of
three.
So
you
end
up
with
the
same
with
the
original
resolution
of
four
that
you
had
at
the
time
before
five
was
added.
So
that's
the
only
sort
of
tricky
tricky
bit
and
that's
that's
the
way
that
it's
actually
defined
and
that's
why
the
field
is
called
original
sibling
resolution
yeah.
J
A
So
I
think
what
I'd
like
to
get
here
is
any
concerns.
People
have
with
this
general
approach,
because
if
folks
are
okay
with
this
general
scheme,
you
know
don't
have
any
of
the
concerns
that
we
had
back
in
in
january,
then
joel
and
I
can
work
out
the
details
in
the
pr
just
want
to
make
sure
the
group
is
okay.
With
this
general
approach,
you
know
kind
of
in
concept.
I
Yeah,
so
pretty
much
anyway,
I
mean
the
current
status
of
the
draft.
Is
that
it's
insecure
right
and
what
joel
is
bringing
us
is
immediately
stronger
anyway.
So
I'm
completely
in
favor
of
taking
that
right
now
and
anyway,
we
have
the
security
analysis
period
so
that
we
can
validate
that.
That's
a
good
fix
and
things
like
this,
so
I
don't
see
any
reason
to
not
take
it
in
some.
I
H
A
B
The
the
only
comment
I
have
is,
I
think
that
I'm
channeling
brendan
macmillan
here,
is
that
we
didn't
make
this
change
or
really
consider
this
earlier,
because
there
wasn't
an
attack,
and
so
since
joel
found
it
and
we
got
a
fix,
I
don't
see
a
reason
why
we
wouldn't
include
this.
So
basically,
just
echoing
what
benjamin
said.
So,
let's,
let's
make
it
so.
A
H
Yeah
yeah
thanks
richard
for
driving
the
slides
yeah.
So
this
is
something
that
had
been
there
for
a
while
as
a
problem.
So
I
can
talk
a
little
bit
about
the
motivation
here.
We
covered
that
extensively
in
the
interim
meetings,
but
I
think
it's
good
to
repeat
it
here.
So
essentially
in
the
architecture
document,
we
say
that
at
no
point
in
time
two
devices
of
the
same
group
ever
have
to
be
online.
H
At
the
same
time,
and
technically
that's
true
that
sensor
protocol
is
asynchronous,
but
when
somebody
wants
to
join
the
the
problem
was
that
one
of
the
existing
members
had
to
send
a
welcome
message
to
the
new
member.
In
order
for
the
new
member
to
be
able
to
join
the
group
and
intuitively,
that
seems
correct,
because
you
want
the
existing
members
to
guard
who
gets
access
to
the
group,
but
it
turns
out
that
you
don't
have
to
rely
on
this
welcome
mechanism
necessarily
in
order
to
keep
the
same
logic.
H
A
welcome
message,
for
example,
when
you
run
mls
in
a
multi-device
context,
where
you
have
a
concept
of
users
that
can
each
have
several
devices
and
a
user
wants
to
add
a
device,
and
in
that
scenario
up
until
now,
though,
you
would
have
to
rely
on
one
of
the
devices
of
that
user
or
other
users
to
be
online
in
order
to
grant
access
to
the
group
to
the
new
device.
But
realistically
is
not
how
a
lot
of
messaging
apps
work,
for
example,
and
so
maybe
just
a
quick
overview.
H
But
if
they
all
agree,
all
we
need
is
a
mechanism
for
the
new
joiner
to
actually
be
able
to
get
into
the
group
as
quickly
as
possible,
and
in
this
particular
example
that
I
mentioned
where
in
a
motor
device
context,
you
just
want
to
add
another
device.
If
on
the
authentication
layer,
you
can
clearly
prove
that
that
device
belongs
to
the
user
and
it's
a
legitimate
device
and
there's
actually
no
reason
why
that
device
couldn't
join
right
away.
H
H
So
the
the
way
the
the
policy
is
being
applied
is
still
the
same
so
before
external
commits
existing
members
could
always
reject
an
ad
proposal
or
ads
that
they
think
were
actually
not
legitimate,
and
this
remains
true
for
external
commits
and
we're
going
to
look
at
the
details
in
a
bit.
I
think
you
can
go
to
the
next
slide.
Richard.
H
H
There
are
no
secrets
needed
whether
this
should
be
available
or
not,
is
for
the
the
specific
application
to
decide,
but
we
have
the
structure
down
on
the
left
code.
Public
group
states,
where
we
have
some
of
the
parameters
like
the
cipher
suite
it's
being
used
for
the
group.
Obviously
the
group
id
and
the
epoch
we're
in.
H
H
H
So
this
is
a
public
key
whose
secret
key
is
known
to
existing
group
members
and
new
journalist
can
use
that
to
come.
Something
to
that
key.
So
in
the
first
iteration
we
didn't
have
that
mechanism,
and
there
essentially,
an
external
member,
would
just
send
a
commit
secret
like
in
a
regular,
commit
to
all
existing
members
so
that
essentially
they
could
handle
the
shared
secret
there.
H
Now
in
the
second
iteration,
I
think
richard
proposed
that
we
have
this
external
public
key
and
then
the
the
new
joiner
can
also
send
an
init
secret
to
that
key.
So
this
is
strictly
more
secure
in
the
sense
that,
before
an
attacker
would
only
have
to
have
one
secret
key
in
one
of
the
intermediate
nodes
of
the
tree,
one
of
the
leaf
nodes.
H
H
H
There
is
also
an
obvious
solution
to
that
which
is
not
on
master,
currently
we're
still
debating
on
some
of
the
details,
but
it
looks
pretty
straightforward
at
this
point.
So
all
we
need
here
is
to
have
a
signature
over
the
whole
public
group
state
that
includes
the
external
public
key.
There
was
a
bit
of
a
debate
on
whether
we
should
sign
all
of
the
fields
in
there.
H
Some
of
them.
We
don't
have
a
good
reason
to
sign
them,
but
also
only
be
cautious
here.
So
currently,
what
we
have
in
the
pr
I
think
433
is
that
all
the
fews
are
being
signed,
and
that
means
that
the
delivery
service
cannot
just
simply
swap
out
the
external
public
key
here,
and
so
we
we
have
a
signature
here
and
at
the
same
time
we
also
have
the
the
parent
hash,
which
is
signed.
H
H
So
one
obvious
downside
of
that
is
that
the
accumulated
entropy
in
the
group
is
lost
at
that
point.
So
obviously
we
want
random
number
generators
to
be
as
good
as
possible,
but
in
addition
to
that,
we,
since
we
keep
on
rehashing
things
between
apex,
we
also
accumulate
some
more
entropy,
which
is
a
good
thing.
So
this
takes
a
hit
in
that
particular
instance.
I
A
The
only
difference
is
that
the
that
entropy,
you
know
the
the
new
in
its
secret,
that's
derived
by
hpke,
is
also
accessible
to
someone
who
holds
the
you
know
the
new
joiners
asymmetry
key
pair.
So
there
is,
I
guess,
some
dilution
that
way,
but
you're
still
carrying
forward
the
information
that
was
in
the
group
already.
H
A
H
I
mean
the
status
quo
is
that
this
does
not
validate
any
of
the
security
guarantees
we
want
to
have
in
general,
like
you
still
have
authenticity,
confidentiality,
fs
and
pcs.
Obviously,
so
it's
going
to
be
a
matter
of
details,
hopefully,
and
so
yeah,
since
this
requires
you
know
certain
information
to
be
public,
like
the
whole
public
group
state
needs
to
be
published
with
every
epic
change.
H
This
mechanism
is
also
entirely
optional,
so
members
can
just
not
publish
that
and
therefore
external
commits
become
impossible,
because
you
don't
have
that
public
information
and
even
if
they
do
publish
it,
existing
members
can
also
simply
reject
these
external
commits,
which
is
something
so
again.
This
is
governed
by
the
authentication
service,
so
whether
a
member
is
allowed
to
enter
a
group
via
an
external
commit
is
for
existing
members
to
decide
if
they,
according
to
their
policy,
they
come
to
the
conclusion
that
the
new
member
should
not
enter
the
group.
H
A
So
this
is
richard.
I
I
am
totally
on
board
with
this.
I
think
you
know
so.
The
the
change
proposal
here
is
to
add
the
signing.
I
think
that
makes
sense.
We
already
merged
the
external
commit
stuff,
which
I
think
is
also
a
good
idea.
So
I
think
the
signing
is
a
good
idea.
I
think
rafael.
You
mentioned
one
thing
that
I
don't
think
I
quite
agree
with.
You
mentioned
that
the
signer
of
the
public
group
state
should
be
the
same
as
the
last
committer.
A
Well,
I
agree.
That's
the
obvious
implementation
strategy.
Like
you
know,
if
you're
implementing
this
in
a
whole
system,
you
should
probably
just
have
the
you
know.
Whenever
someone
sends
a
commit,
they
also
send
an
updated
public
group
state,
but
I
don't
think
that
necessarily
needs
to
be
the
case
you
could.
I
think
you
could
allow
for
other
any
any
group
member
to
sign.
H
Yeah,
possibly
yes,
the
question
is:
how
would
that
work
in
practice?
Because,
as
you
say,
the
committer
is
the
one
being
active
when
you
change
epochs,
so
this
would
require
another
group
member
to
be
active
at
the
same
time,
because
obviously
these
things
need
to
be
synced.
At
the
very
least,
you
know
the
epoch
number
is
in
the
public
group
state,
so
this
gets
stale.
H
A
H
H
H
A
But
yeah,
I
think,
that's
something
that
might
not
be
immediately
obvious
to
folks
about
this
external
commit.
It
is
actually
a
fairly
powerful
mechanism
and
that
you
can
include
the
you
know
the
person.
That's
adding
cannot
just
you
know
they
need
to
add
themselves,
that's
required
for
the
commit
to
be
valid,
but
in
addition
to
adding
themselves
they
can
do
any
other
group
operations.
So
they
can
add
other
people.
They
can
remove
people
from
the
group,
they
can
add
psks.
A
They
can
request
the
groupie
reinitialized
it
even
so
there's
a
full
power
commit
now.
Personally,
I
think
that's
a
feature
and
not
a
bug.
I
think
there's
some
cool
stuff
you
could
do
with
this
on
the
one
I
put
in
the
chat
is
that
you
could
you
know
one
of
the
concerns
that
had
been
raised
like
what,
if
someone
loses
their
loses,
their
state
need
to
resync.
A
Well,
this
gives
you
a
resync
operation
based
on
the
public
group
state,
because
you
can
now
make
an
external
commit
that
adds
your
new
version
of
you
as
you
re-adds
you
to
the
group
and
removes
your
old
appearance
at
the
same
time.
So
you
get
a
resync
operation
for
free
by
virtue
of
adding
this
external
thing.
B
I
think
the
it's
it's
great
to
be
powerful,
but
this
just
just
means
we're
gonna
have
more
security
review
of
it
to
see
what
what
the,
whether
it's,
the
power
for
good
or
the
power
for
bad.
So
I
think
that
it's
good
that
we've
got
a
security
review
time
built
in
so
I
mean
it
sounds
like
we
should
go
ahead
and
merge.
We
should
go
ahead
and
merge
this
stuff
and
then
basically
see
what
happens.
H
H
So
essentially
the
eviction
would
work,
and
I
think
there
was
also
a
previous
question
whether
the
new
genre
can
send
messages
or
not.
So
the
whole
idea
behind
this
mechanism
is
that
the
as
long
as
this
public
group
state
is
available
to
the
new
joiner,
the
new
joiner
can,
you
know,
get
started
immediately
with
that
by
issuing
the
external
commit
and
and
coming
the
external
limit
secure
to
the
group,
and
then
just
you
know,
apply
this
commit
to
its
own
state
and
and
then
the
new
member
can
immediately
start
sending
messages.
H
So
it's
immediately
part
of
the
group.
In
that
sense,
the
only
question
is,
if
other
members
will
agree
with
that
external
commit.
But
this
is
something
we
we
have
to
assume
that
we
do
otherwise
there
was
no
point
in
doing
it
in
the
first
place.
So
if
they
will
agree
that
external
commit,
then
the
new
genre
is
immediately
a
regular
group
member
after
having
issued
and
applied
the
external
commit,
there's
no
difference
anymore
between
the
new
joiner
and
other
members.
H
And,
as
richard
pointed
out
that
you
know
the
motivation
side,
I
think
this
simply
might
make
mls
way
more
accessible
in
scenarios
where
you
don't
want
to
have.
You
don't
want
to
have
this
constraint
that
two
devices
have
to
be
online
one
after
each
other
and
have
a
dramatic
effect
on
or
impact
on
where
mls
is
going
to
be.
B
A
A
A
A
I
A
A
A
Yeah,
I
think
we
should.
This
might
need
a
little
bit
more
discussion
in
the
pr
to
get
to
what
the
issue
is
because,
like
I'm
a
little
concerned
here,
that
there
are
cases
where
you
want
to
have
multiple
appearances
of
the
same
identity,
for
example,
for
multiple
devices,
and
you
might
have
multiple
credentials
of
the
same
identity.
And
so
I'm
worried
when
I
see
things
like
the
requirement
here.
That
and
multiple
ads
for
the
same
identity
would
get
ignored,
or
some
of
them
would
get
ignored.
H
H
A
All
right
so
sean
it
sounds
like
our
chairs.
It
sounds
like.
Maybe
we
should
have
a
call
in
in
a
couple
weeks
to
close
out
these
last
two
issues
and
then
and
obviously
we
can
have
some
discussion
in
the
pr
in
the
meantime
and
then
I
will
issue
draft
11
and
start
our
feature
freeze
and
analysis
period.
A
B
A
Yeah
and
actually
it
if
someone
in
the
group
in
the
on
on
the
in
the
meeting
wanted
to
was
more
new
to
this
and
wanted
to
get
familiar
with
stuff
that
might
be
a
way
to
contribute
is
to
help
think
through
what
some
of
those
cases
are
that
you'd
want
to
test
out
based
on
your
reading
of
the
spec,
so
help
would
be
welcome.
There.
H
H
A
A
We
might
be
able
to
do
some
degree
of
testing
that
way
just
to
verify
basic
functions
like
the
the
crypto
primitives
and
some
of
the
message
serialization,
but
to
really
get
the
the
behavioral
interop.
I
think
we're
going
to
need
to
do
some
live
testing
via
a
server,
so
we'll
probably
define
some
little.
You
know
json
json,
over
http
and
web
sockets
protocol
to
shut
things
back
and
forth.
H
Yeah,
exactly
I
mean
just
for
context,
test
factors
are
complicated
because
of
all
the
entropy
that
is
being
injected
all
the
time.
So
in
order
to
get
that
out
of
the
way
you
have
to
make
a
lot
of
modification
to
actual
implementation,
I
think
we
should
get
there
at
least
on
on
our
side
with
openmls,
where
we're
going
to
try
and
get
there
at
some
point,
because
I
think
els
also
has
done
that
in
the
past.
It's
a
good
thing
to
have,
but
it's
not
exactly
a
low-hanging
fruit.
H
So
the
test
factors
we
had
in
the
past
was
for
some
of
the
tree.
Math
and,
like
you
said
some
of
the
serialization
well
they're
completely
inaccurate.
Now,
because
I
think
that
we're
referencing
something
between
draft
one
and
four,
we
can
try
and
get
that
back
of
course,
but
I
fully
agree
that
we
should
try
and
interrupt
see
how
that
goes
and
then
do
full
test
requires.
As
a
second
step.
I
A
H
B
I
So
yeah,
I
think
that's
the
that's
the
main
point,
at
least
for
me
on
karthik,
because
we
are
doing
the
implementation
and
the
code
are
the
same
thing
for
us
right.
So
we
are
proving
something
on
the
code,
so
we
don't
want
to.
We
do
proofs
like
gazillions
of
times
but
yeah,
I'm
pretty
sure
we'll
have
to.
We
will
we'll
have
something
reasonable
in
the
next
few
months
during
the
analysis
part,
but
that
also
depends
on
kartik,
not
only
on
me.
B
So
all
right!
Well,
if
anybody
has
anything
else,
I
mean
at
some
point
to
be
honest
right:
we're
going
to
have
to
go
back
and
lean
on
a
mod
to
do
the
finish.
The
federation
draft
or
abandon
it
and
we're
gonna
need
to
do
the
server
assist
draft
and
get
working
on
that.
But
I
think
the
the
key
point
is
getting
the
protocol
done.
Get
the
analysis
started.
Do
the
architecture
draft
and
then
look
to
pick
up
the
other
pieces.
B
And
under
the
absolutely
go
ahead
and
submit
it
as
an
individual
submission,
whatever
you
know,
draft
dash,
whatever
name
last
name,
we're
going
to
use
and
just
go
ahead
and
put
it
up
as
soon
as
possible,
and
we
can
get
people
to
start
reviewing
it.
And
if
we
have
time
and
then
there's
people
that
have
reviewed
it,
we
can
adopt
it.
Whenever.