►
From YouTube: IETF103-MLS-20181105-1610
Description
MLS meeting session at IETF103
2018/11/05 1610
https://datatracker.ietf.org/meeting/103/proceedings/
A
B
A
C
E
C
C
C
F
B
Here's
here's
the
note.
Well,
it's
Monday!
You
might
not
have
seen
it
that
much.
Basically,
it
says
you
what
you
say
and
do
it
the
mic
here.
So
it's
gonna
be
recorded
video
and
video
and
an
audio.
If
you
have
IP
are
you
need
to
disclose
it
professionally?
There's
a
bunch
of
documents
you
can
read
about.
If
you
want
to
get
the
details,
it'll
be
sick
of
seeing
the
slide
by
the
end
of
the
week
so
requests
we
did
a
good
job,
but
it
was.
We
got
a
minute
taker,
jabber
scribe.
B
B
Up
real,
quick,
basically,
is
this
administrivia?
The
interim
recap
where
we're
just
gonna
do
kind
of
a
quick
summary
and
we've
got
a
bunch
of
architecture.
The
both
documents
have
been
revised.
So
when
you
talk
about
some
changes
that
were
made
to
the
architecture
document
endings
outstanding,
and
then
we've
got
a
bunch
of
presentations
about
that
that
guts,
the
documents
of
the
protocol
tree
cam
and
double,
join
and
authentication,
handshake,
encryption
and
efficiency
considerations
and
some
message.
B
Protection
stuff
will
note
that
the
person
who
is
going
to
present
the
message
protection
is
currently
doesn't
have
power
in
his
building
in
France.
So
we
may
have
to
see
what
to
do
about
that,
so
that
may
fall
off,
but
we
have
another
session
on
Thursday,
so
I
may
go
there,
we'll
see
what
happens
and
then
we
might
have
some
updates
on
Thursday.
If
we
get
everything
done
early,
we
probably
will
cancel
the
Thursday
session
but
see
all
right.
H
C
So
we
had
a
great
interim
meeting,
it
went
pretty
well,
we
had
quite
a
few
people
working
on
the
documents
who
showed
up.
We
had
several
discussions
here
that
will
these
presentations
that
are
gonna
happen
today
are
going
to
kind
of
go
over,
and
summarize
we
had
discussions
about
double
joins
and
and
proposal
about,
blanking
entries
of
the
tree
was
was
introduced
and
debated.
C
We
had
a
discussion
about
art
versus
tree
chem
and
eventually
settled
on
going
with
tree
chem
as
the
the
main
construction,
with
the
caveat
that,
depending
on
the
formal
analysis,
if,
if
it
turns
out
that
tree
cam
does
have
some
some
larger
deficiencies
that
were
not
known
now
that
and
we
may
be
able
to
roll
it
back.
There
was
some
additional
discussion
about
message:
protection
in
particular
about
AES
versus
AES
SIV.
This
is
this
is
something
that
we
sort
of
tabled
and
we
didn't
didn't
resolve
at
the
interim
as
well.
C
There's
also
some
discussion
about
authentication
and
we'll
we'll
recap,
this
I
guess
in
the
presentation
today
and
yeah,
so
some
other
updates
from
there.
We
planned
to
go
to
the
hackathon
and
have
attempt
to
do
some.
Some
level
interrupts
and
that'll
that'll
be
discussed
as
well
here
today.
So
that's,
basically
the
summary
of
the
interim
and
yeah
a
bunch
of
ideas
that
were
brought
up,
but
the
notes
are
available.
B
Say
that
Richard
did
you
want
to
say
anything
about
the
hackathon
before
we
go
on
or
side
in
part
of
her
three
things
in
your
bombs
and
slides.
I
So
yeah
we
had
some,
we
didn't
work
at
the
hackathon.
We
had
two
implementations
there,
the
Melissa
one
from
from
the
wire
folks
and
my
mlsp
p
c,
plus
plus
one
we
unfortunately
had
a
crypto
Interop
issue
in
that
I
hadn't
implemented
with
P,
256
and
Raphael
implemented
with
curve
G
five,
five,
one,
nine
and
I
think
neither
of
us
got
crypto
agility
working
in
time,
but
we've
managed
to
get
some
basic
level
of
Interop.
I
B
G
To
use
this
okay,
I,
don't
think
I
would
use
the
15
minutes
for
this,
but
yeah
I
want
to
cover
the
of
an
issue
without
protection
unlock.
First,
these
two
points
that
I
should
to
verification
more
than
a
open
issued.
Something
will
still
confused
what
the
purpose
of
dark
shadow.
Quite
we
have
2.8
competing
dogs
with
the
protocol
dog
or
not.
So
our
intention
was
to
have
a
separate,
independent
dog
to
find
the
function
and
security
requirements
through
the
pass
code,
and
this
committee
server
from
the
protocol
is
not
competing.
G
G
It's
draft
in
the
current
dog
as
optional
still
an
argument
to
have
it
as
a
required
or
optional.
So
this
is
still
open
for
debate
to
clarify
the
nobility.
What
what
we
meant
by
the
nobility
here
is
children,
I
bet
you're,
not
server
than
every
key,
so
tears
can
not
correlate
Masjid
with
the
long-term
identities
des
trust
or
delivery
service
trust.
So
the
current
draft
mentioned
that
delivery
service
should
only
store
information
needed
to
deliver
messages.
G
However,
while
implementing
MLS
there
are
some
scenarios
the
trick
general
can
cover
later
is
it
makes
more
sense
that
more
efficient
to
store
some
public
groups
tape
in
the
delivery
service.
So
the
proposal
here
to
add
this
is
an
optional
mode
like
to
store
optional
information
about
our
public
Google
state
information
to
the
server.
It
makes
sense
more
efficient,
so
it's
safe
to
do
so,
and
it
okay
to
iso-octane
draft.
B
C
I
My
slides
for
three
different
slots
into
one
big
deck
so
will
be
piecing
through
this
as
we
go
so
wanted
a
recap,
real
briefly,
where
he
ended
up
at
the
after
the
interim.
We
presented
a
sketch
of
this
at
the
interim
and
then
I
integrated
that
into
the
draft
in
between
the
interim
and
now,
and
so
it
was
gonna
kind
of
recap
where
the
draft
is
now,
it's
people
kind
of
understand
what
the
what
the
approach
is.
I
I
The
cone
underneath
that
node
in
the
tree
and
that
what
that
enables
us
to
do
is
that
when
we
want
to
send
a
secret
value
to
a
part
of
the
tree
to
that
orange
area
there,
and
we
can
use
the
key
at
that
point
in
the
tree
to
encrypt
to
all
the
leaves
at
the
beneath
that
beneath
that
point
in
the
tree,
we've
had
for
a
little
while
in
the
protocol,
this
idea
of
a
double
join.
We,
the
phrase
comes
up
because
it
first
arose.
I
We
were
talking
about
adding
people
to
the
group
and
the
what
we
call
a
double
join
is
when
we
have
a
violation
of
this
invariant.
A
point
in
the
protocol,
where
the
private
key
for
that
node
in
the
tree
is
known
to
someone
so
the
holder
of
a
leaf
who's,
not
under
that
notice,
read
someone
who
who
shouldn't
have
it
according
to
this
tree
invariant.
So
these
double
joins,
make
the
tree
more
difficult
to
manage
the
invariants.
You
know
kind
of
assures.
I
It
gives
us
a
convenient,
calm,
mapping
between
points
in
the
tree
and
subsets
subgroups
of
the
overall
group,
and
so,
if
we
have
this
double
join
around,
then
it
makes
it
more
complicated
to
reason
about,
because
you
have
to
track
whose
double
join.
To
a
note,
in
addition
to
who
should
have
the
know,
the
private
key,
according
to
the
tree
invariants,
so
we've
been
trying
to
eliminate
these
double,
joins
to
clean
up
the
protocol
and
make
it
simpler
to
reason
about
who
has
which
keys
the
trade-off
is
well.
I
I
This
left
this
node
over
here
at
the
left,
is
adding
a
new
member
on
the
right
and
in
earlier
versions
that
the
end,
the
members
sending
the
add,
would
set
values
for
all
the
nodes
above
the
new
node,
the
new
member
in
the
tree.
What
that
implies
is
that
the
sender
of
the
add
gets
double
joined
to
all
of
these
nodes
above
the
new
member
in
the
tree,
because
he's
not
that
new
member,
but
he
still
has
access
to
those
keys
that
he
shouldn't
have
access
to
right,
because
you
can't
set
a
value.
I
I
You
just
kind
of
take
all
the
algorithms
we
had
for
doing
ads
and
removed
an
updates
before
and
wherever
you
are
going
to
encrypt
to
a
node
you
instead
encrypt
to
what
I've
called
the
resolution
of
that
node.
So
in
this
scenario
here
the
this,
this
node
is
updating
and
it
needs
to
send
out
private
values.
For
these,
it
needs
to
encrypt
the
private
value
for
this
nodes
of
this
node
and
the
private
value
for
the
route
to
this
node.
I
But
this
known
is
empty,
and
so
we
flow
through
in
this
resolution,
algorithm
to
the
populated
children
of
that
node.
So
this
this
one
here
and
then
this
leaf
here
and
so
the
the
ultimate
encryption
you
get
in
the
messages
is
this
encryption
of
this
value
to
this
node
and
the
encryption
of
this
value.
It
says
this
node
and
this
node
so
instead
of
having
to
encryptions,
you
have
three
which
hints
at
one
of
the
you
know
the
impending.
You
know
a
problem
here,
which
is
that
resolution
inherently
involves
more
encryptions
than
encryption.
J
I
I
Yeah,
so
this
is
what
our
remove
looks
like
when
you
remove
this.
This
third
node
here
your
blank
out
its
path
to
the
root.
It
turns
out
that
the
content
of
the
root
node
in
in
what
we've
got
so
far
doesn't
really
matter,
because
you
never.
You
use
the
cond
of
the
root
node
as
a
shared
secret
and
and
never
really
use
it
again.
When
you're
encrypting
to
the
group
you're
using
symmetric
secret
that
you've
derived
they're,
not
the
the
public
key
that
that's
at
the
root
yeah.
K
I
K
K
I
In
a
case,
you
cagey
going
back
to
your
question.
This
is
how
you
end
up
with
a
blank
root
node.
If
then
say
this
the
right
hand
node
sent
an
update
that
replaced
all
the
nodes
in
its
direct
path.
Then
you
would
end
up
resetting
the
root
node
to
attend
group
value,
that's
known
to
the
whole
group,
because
the
that
update
you
know
it
would
send
this
value
to
this
node
this
value
to
this
node,
and
then
it
would
send
the
new
value
for
the
route
to
the
populated
tree
heads
under
that
by
resolution.
Yeah.
I
I
You
know,
because
of
that,
that
increased
semantic
clarity
and
so
we've
kind
of
gone
all
the
way
from
the
semantic
ambiguity,
but
high
efficiency
into
the
spectrum,
to
the
high
semantic
clarity
and
terrible
efficiency
into
the
spectrum,
and
so
I
think
Raphael
has
some
thoughts
on
how
some
intermediate
points
we
might
explore.
I
will
observe
that,
so
this
is
kind
of
the
worst
case
for
efficiency.
If
you
have
a
tree,
that's
that's
reasonably.
Full
I
mean
in
kind
of
basing
the
empirical
some
simulation
work
that
Raphael.
I
K
I
K
I
I
K
I
Actually
yeah,
so
so,
if
you
do
this,
what
I
said
you
have
this
like
warm-up
phase,
so
the
blue
line
at
the
bottom,
which
you
can't
see
because
it's
next
to
the
axis
is,
is
login,
and
so,
if
you
had
a
full
tree
and
you
didn't
have
and
you
had
double
the
double
joints,
the
in
the
first
operation
would
be
linear
size
and
then
everything
else
would
be
log
size.
And
if
you
don't
do
that
and
you're
just
doing
random
operations,
you
you
kind
of
gradually
converge
from
linear
down
to
log.
So.
K
So
let
me
just
see
if
I
understand
the
intuition
here,
which
is
that,
can
you
go
back
so
the
first
person
who'd
update,
basically
fills
in
his
direct
path
and
so
then
then
updates
the
not
part
of
the
tree
or
somewhat
more
efficient.
They
were
four
and
then
gradually
more
and
more
the
tree
gets
filled
in
and
then
it
updates
get
faster.
Is
that
the
right
right,
yeah.
H
K
L
I
In
in
practice,
yeah,
you
would
hope
that,
like,
as
people
join
the
group
as
people
like
come
online
and
and
realize
they've
been
at
it,
they
would
send
an
update,
but
you
know
we're
designed
to
tell
or
designing
for
asynchronous
operation
here,
and
so
as
look
you
know,
if
if
half
the
group
never
comes
online,
then
they're
half
of
the
tree
will
never
get
populated,
so
I
think
Raphael,
listen,
that's
impossible!
Turning
this
year,.
M
M
So
the
idea
was
couldn't
we
do
something
about
it
in
general
and
specifically
for
the
in
it,
which
is
completely
inefficient
at
this
point,
so
just
to
look
at
it
from
another
perspective,
if
you
blank
something,
there
is
only
one
rule,
you
just
need
to
get
everybody
to
agree
on
which
nodes
have
to
be
blanked
and
that's
it.
The
next
step
only
comes
when
you
resolve
a
node
when
you
prepare
an
update,
for
example,
but
that
is
in
phase
two.
M
It
is
not
generally
super
useful,
so
this
cup
of
this
would
be
only
to
increase
the
efficiency
and
because
all
of
the
the
security
guarantees
we
have
achieved
with
blanking
already
so
there
there's
more
than
one
route
this
one,
because
if
you
set
a
secret
of
a
node,
you
need
to
tell
that
secret
to
the
children
of
a
node
or
to
the
resolution
of
the
children.
If
the
children
are
blanked
and
this
effectively
creates
a
double
drying,
the
very
thing
we
just
wanted
to
get
rid
of.
M
So
that
means
that
whoever
set
that
node
knows
that
secret
until
the
node
gets
overwritten
by
an
update.
But
if
that
doesn't
happen,
and
you
want
to
evict
the
setter
of
the
node,
you
effectively
need
to
blank
this
node.
In
addition
to
the
direct
path
of
the
setter,
the
upside
could
be
that
this
yields
the
tree
and
makes
it
more
efficient.
M
M
So
if
we
were
to
allow
double
joins,
we
would
have
to
track
all
of
them
to
know
exactly
which
member
has
the
secret
to
which
node
right
now,
we
implicitly
assume
that
every
member
has
the
secret
in
the
notes
of
a
direct
path.
So
there
is
no
need
to
store
that
anywhere,
but
if
they
know
the
secret
of
notes
outside
of
that,
we
would
have
to
do
some
bookkeeping.
So
there
would
have
to
be
some
structure
that
contains
that
information.
M
That's
what
we
would
call
the
book
and
this
book
would
have
to
be
passed
to
new
members
or
new
devices
in
a
multi
device
context,
and
what
is
also
important
is
that
everybody
has
the
same
view
on
the
book,
because
members
might
have
the
incentive
to
lie
about
certain
entries.
So,
for
example,
if
I
invite
someone
to
a
group
group,
I
might
be
tempted
to
not
tell
them
which
nodes
I
have
double
joined,
so
that
I
could
maliciously
still
be
part
of
the
tree.
M
So
this
is
a
naive,
yet
flexible
idea
of
what
a
book
could
look
like
so
for
every
node,
if
there
is
an
entry
which
might
have
zero
too
many
owners-
and
there
are
many
entries
in
the
book
depending
on
how
many
nodes
have
a
double
join.
Of
course,
there
could
be
more
efficient
representations
in
memory
of
a
book
if
you
accept
certain
constraints
on
how
many
owners
that
can
be
or
where
the
nodes
are
in
the
tree.
In.
I
This
Richard
Barnes
just
to
be
clear.
We
need
to
have
this
information
available
in
serializable
so
that
you
can
tell
it
to
someone
who's
group,
because
if
that
member
needs
then
needs
to
evict
someone
who's
double
joined,
he
needs
to
also
tell
everyone
to
blank
out
that
note
or
no
actually,
when
he's
processing
remove
needs
to
know
to
blank
out,
and
he
notes
to
which
that
then
they
were
being
evicted
is
double
joint,
almost
yeah.
It's
a
terrible
idea
outside
of
one
limited
case,
I.
M
Mean
it
was,
it
was
worth
investigating
or
at
least
presenting
the
results
so
that
we
don't
do
that
twice,
but
I
mean
this
is
exactly
why
it's
a
terrible
idea.
Maybe
you
suspected
that
already.
So
if,
if
piece
the
note
that
was
previously
blank-
and
we
want
to
set
a
secret
in
there,
then
we
would
have
to
tell
that
secret
to
the
left
and
the
right
children
or
the
resolution
of
these
nodes
and.
M
So
specifically,
when
we
set
something-
and
we
suppose
that
the
left
children
was
already
double
joined
by,
say,
Alice
and
now
Alice
previously
only
knew
the
secret
of
L.
If
we
came,
the
secret
of
P
to
L
than
Alice
has
effectively
also
double
joint
P
and
all
we
did
was
basically
to
just
set
P.
So
this
increased
the
number
of
double
joins
for
Alice,
which
is
certainly
not
nice.
M
But
it
is
quite
expensive
and
it
doesn't
really
help,
because
if
we
do
an
update
which,
as
Richard
pointed
out
earlier
today,
could
be
seen
as
a
number
of
sets
really
now.
The
problem
is
that
Alice,
initially
double
joined
L.
She
gets
to
know
the
secret
of
P
and
because
in
an
update
we
hash
up
the
secret
all
the
way
to
the
root.
So
Alice
has
now
doubled,
joined
all
the
nodes
from
L
to
the
root,
so
ya
worst
factor
would
be
log
of
n
in
this
case,
so
it
gets
messy
yeah.
M
So,
aside
from
that,
there
seems
to
be
an
invariant
where
you,
if
you
accept
that
the
book
would
increase
in
size,
the
operation
cost
would
go
down
and
vice-versa,
basically,
but
a
book
that
is
increasing,
only
means
that
you
have
postponed
some
of
the
work,
because
it
means
that
if
you
want
to
evict
members
at
some
point,
you
will
have
to
do
a
lot
of
blanking
because
of
all
of
the
entries
in
the
book
and
then
actually
everything
becomes
very
expensive
again.
So,
if
anything,
you
could
buy
time
with
this.
M
So
there
is
one
edge
case
as
Richard
said,
and
this
is
actually
what
triggered
this
whole
research
and
that's
the
reimage
edge
case
where
you
start
with
a
completely
linear
model
and
the
cost
is
in
in
o
of
n.
It
does
converge
rather
quickly,
so
Richard
did
that
simulation.
I
I
tried
it
on
my
end,
I
think
this
is
a
graph,
so
this
is
very
thin
on
this
monitor.
M
Here
so
this
means
is,
that
thousand
is
the
number
of
people
in
the
group,
and
so
the
very
first
update
has
a
cost
of
exactly
one
thousand,
because
the
resolution
will
be
one
thousand,
so
as
people
come
online
and
you
expect
them
to
actually
come
online
rather
quickly.
Typically,
I
mean
it
is
asynchronous,
but
some
people
are
going
to
be
online
and
they
will
immediately
start
to
do
an
update.
M
So
this
is
going
to
actually
decrease
very
quickly.
I,
don't
know
if
you
can
see
this
blue
line
here.
So
this
is
the
average
Co
path
lengths
the
average
from
from
all
members.
Basically-
and
there
is
a
worse
case
and
a
best
case
so
roughly
after
it's
hard
to
tell
from
this
graph,
but
after
less
than
50
updates,
you're
already
below
a
hundred
different
operations.
So
this
is
good
in
general.
The
problem
is
that
the
first
30
40
members
who
come
online,
they
have
an
insane
amount
of
calculation.
To
do
sorry,.
M
I
That's
not
yeah,
I
think
there's
two
things:
yeah,
there's
there's
no
adds
or
removes
here
and
I.
Think
there's
there's
many
more
time
steps
here.
So
mine
was
the
first.
You
know
50
or
so
time.
Steps
of
the
group
and
he's
covering
the
first
thousand
for
the
whole
groups
update
so
so
you're,
seeing
some
some
horizontal
compression
in
this
case
right.
M
Very
nice
scale
to
see
the
difference
between
n
up
here
and
low
down
here,
and
that
is
only
for
a
group
of
1000
members.
So
with
ten
thousand
or
fifty
thousand,
it's
even
more
dramatic.
We
all
know
that,
but
it's
always
impressive
when
you
see
it
so
the
one
idea
that
occurred
to
me
is
that
potentially
could
be
a
good
idea
to
increase
the
efficiency
by
warming
up
the
top
of
the
tree.
M
If
that
is
done
at
the
top
of
the
tree,
it
could
be
done
anywhere
because,
just
like
you
can
blank
a
node
anywhere,
you
can
also
set
a
node
anywhere,
but
it
is
most
efficient
at
the
top.
That's
where
you
reach
most
of
the
leaves
that
are
underneath,
and
so
a
tree
is
composed
of
levels
horizontally,
and
so
with
every
new
level
that
is
being
populated.
M
You
basically
divide
the
cost
of
the
first
update
by
2,
so
this
decreases
rather
quickly
so
an
example
in
numbers.
We
take
the
group
of
a
thousand
members.
Again
we
take
the
top
3
percent
of
the
nodes
in
the
tree,
so
there's
like
30
nodes.
In
this
case
they
are
pre-populated.
So
this
is
still
fairly
quick
because
we
only
pre
populate
3%.
M
So
for
the
creator,
this
is
really
not
very
expensive
to
do,
and
it's
still
linear
in
theory,
but
it
is
fairly
quick,
and
so
that
gives
us
a
completely
new
picture
where
the
scale
has
changed
quite
a
bit.
So
the
first
update
now
is
not
1,000.
It
starts
at
70
and
then
it
converges
again
in
the
same
fashion
as
the
other
one,
except
that
you
don't
have
these
high
numbers
anymore,
and
so
this
is
a
comparison
chart
between
the
two
so
that
the
purple
one
is
the
initial
one
that
started
at
1000.
M
This
one
starts
at
70
and
then
they
basically
very
quickly
not
only
converge
but
actually
become
identical,
because
the
effect
of
the
the
pre-population
of
the
top
of
the
tree
wears
off
rapidly,
as
updates
will
overwrite
all
of
that.
So
that
looks
good,
but
we
still
have
a
double
drawing
situation
as
such.
M
So
there
is
some
sort
of
a
cleaning
mechanism,
so
as
people
come
online
and
do
updates,
they
will
overwrite
the
tree.
So
we
still
have
this
proliferation
effect
that
we
saw
earlier
when
you
have
a
double
joined
node,
and
that
happens
to
be
in
the
co
path
of
an
update.
But
the
big
difference
here
is
that
first
of
all,
all
of
the
nodes
are
only
double
joined
by
one
person,
which
is
the
Creator,
and
so
anything
above
a
double
on
node
is
also
alright
double
joins.
M
So
this
this
particular
problem
has
no
effect
here
and
what
happens
is
that,
as
as
people
do
updates
one
level
at
a
time
the
double
joins
are
going
to
to
vanish.
Basically
until
you,
you
really
only
have
the
top
of
the
tree,
that
is
the
Padron,
and
then
also
that
goes
away,
and
so,
if
you
warmed
up
k
levels
of
the
tree,
it
would
take
two
roughly
two
to
the
k
plus
two
updates
to
do
this
cleaning
and
in
the
example
before
we
had
five
levels.
M
So
two
to
the
k
plus
two
is
128
in
this
case
in
a
group
of
thousand.
So
roughly,
when
a
bit
more
than
10%
of
the
people
have
come
online
and
done
an
update
which
they're
supposed
to
do
the
tree
is
completely
clean,
again
and
and
reasonably
populated.
If
they
don't.
For
some
reason,
you
can
still
evict
the
creator
of
the
group
by
blanking,
whatever
nodes
that
are
left
and
our
double
joined.
M
O
K
K
I
guess
I'm,
just
saying
like
there
are
certainly
all
like
you
know
their
messaging
system,
this
which,
basically
on
the
structure
like
you
service
in
the
Creator,
special
and
I'm,
just
wondering
if
you
willin
to
tolerate
you
know
if
you
only
tolerate
out
that
restriction
like
would
that
be
that'd,
be
a
very
substantial
game.
Yeah.
M
I
mean
that
that
is
definitely
a
good
observation,
because
most
systems,
where
you
have
a
creator,
you'd
assume
it's
some
sort
of
administrator
or
a
moderator
or
whatever,
and
those
rarely
get
evicted
from
a
group.
So
the
cost
you
would
pay
right
now
in
such
a
situation
would
only
be
the
bookkeeping.
If,
if
there's
only
one
person
who
can
double
join,
then
you
can
condense
the
bookkeeping
to
something
that
is
bytes
two
kilobytes,
maybe
regroups,
and
that
that
just
needs
to
be
passed
around
so
and
the
payload
size.
I
The
upshot,
if
you
want
to
do
double,
join
only
at
in
it
time,
is
that
you
need
to
carry
around
one
bit.
So
if
you
want
double
join
only
at
a
time-
and
you
want
to
be
able
to
evict
the
creator,
then
you
need
to
have
one
bit
per
node
in
the
tree.
That
indicates
whether
the
Creator
is
still
double
joints.
I
It's
at
that
node
and
the
costs
until
you
try
and
remove
the
creator
is
only
that
and
then,
when
you
try
to
remove
the
creator,
you
have
the
caught
you
take,
then
the
cost
of
removing
all
the
nodes
from
the
tree
that
the
creators
still
double
joined,
see
which
could
you
know,
drop
you
back
until
the
new.
Your
state
I
mean.
K
I
guess
that,
to
cut
to
the
chase
right,
it
seems
like
the
recommendation
you're
edging
towards
is
that
we
do
that,
namely
the
creator
create
the
tree
in
a
any
any
populated
state,
with
the
bookkeeping
to
all
the
Creator
to
get
kicked
out.
If
you
have
they
have
to
do
is.
Is
that,
where
you're,
basically
fitting?
For
just
that
sounds
like
a
good
plan.
L
I
M
Yeah,
it
would
be
interesting
to
do
some
simulations
because
so
again,
if
if
we
go
back
to
this
graph,
so
the
the
situation
comes,
you
know
more
than
bearable
after
20
percent
or
whatever
you
assume
to
to
be
a
good
situation.
So
if
you
pre
populate
the
whole
tree,
I
mean
yeah,
you
you
converge
more
quickly
towards
the
log
n
line
here,
but
that's
really
it
and
you.
You
would
put
a
lot
more
load
on
the
Creator
so
right
now
the
Creator
only
does
3%.
I
M
I
I
Period
if
you
pre
populate
the
tree
and
the
second
thing
which
which
John
Milliken
convinced
me
a
little
while
back,
is
that
you
don't
actually
have
to
do
any
additional
diffie-hellman
operations,
because
you're
already
assembling
a
secret
key
with
each
of
the
new
participants.
It's
just
additional
stuff.
You
should.
J
M
Absolutely
I
mean
if
you
start
with
a
small
group,
and
probably
most
groups
will
start
that
way
where
you
don't
have
a
fixed
set
of
participants
in
the
beginning,
then,
but
the
the
big
difference
there
is
that
the
tree
will
already,
you
know,
be
populated
with
the
small
group
of
people.
So
it
will
still
be
expensive
to
add
a
large
chunk
of
people.
But
it's
gonna
be
much
better
than
linear.
J
M
M
I
Change
so
I
mean
sending
message
is
always
constant
time,
because
you
establish
the
symmetric
key
that
everyone
has.
It's
only
so
ads
are
easy
in
any
case,
because
you're,
just
okay
well
ads
get
more
more
ish
expensive.
Oh
no!
Actually,
the
latest
one!
No,
you
just
ratchet
forward,
so
you
don't
actually
have
to
send
you
to
the
group
and
you
just
send
entropy
to
the
new
member
its
updates
and
removes
that
get
expensive,
because
you
have
to
send
information
to
a
subset
of
the
tree.
K
Well,
I
think
I'm,
like
just
about
tuck
at
numbers.
I
have
to
bias
between
first
about
the
bias
between
like
upfront,
great
time
versus
work
by
people
once
the
crease
created
I.
Think
I'd
prefer
to
buy
us
for
our
own
work,
create
time
because
you're
creating
a
person
group
like
first
of
all,
you
have
to
do
like
the
crap
ton
of
work
just
to
get
that
to
work.
I
mean,
like
you
know,
like.
K
Like
if
you
have
to
burn
like
comp,
if
that
operation
takes
seconds,
nobody
really
cares
but
I,
don't
you
don't
want
to
be
the
case
that
when
I
joined
the
ten
thousand
person
group
then
like
I,
got
to
spend
my
CPU
for
a
while?
Don't
like
just
do
anything
at
all,
so
I
think
I
tend
to
buy
us
that
way
in
terms
of
efficiency,
I'm,
true
to
pre-pivot
of
the
whole
tree,
just
yeah.
K
The
thing
about
I'm
like
dumb,
so
you
know
it's
like
easier,
the
is
it
is
as
I
understand
it
in
the
case
of
the
tree
gradually
grows.
It's
like
not
after
that
efficient.
You
build
the
tree
that
way,
but
the
spaced
out
over
time.
So
you
kind
of
don't
know.
Is
that
not
Korean
thinking
about
it
like
in
the
version
where
you
like,
add
people
one
at
a
time?
K
J
These
kids,
that
I
was
worried
about
was,
if
we're
talking
about
like
say,
company
size
groups,
is
that
the
admin
sets
one
up
with
you,
which
is
just
like.
You
know,
small
tests
to
make
sure
the
group
works.
Now
now
it's
working
now
we're
gonna
turn
around
and
add.
You
know
the
entire
division,
because
we've
because
now
we
know
that
the
group
is
working
and
now
we
add
the
entire
division
and
if
that
suddenly
becomes
expensive,
then
that's
kind
of
a
weird
like.
K
M
K
Indeed,
use
example
that
person
is
the
admin
and
so
double
joining
them
is
like
like
it's
like
hey,
you
know
what,
if
that
pushing
its
fire,
you
just
deal
with
it,
but
I
think
something
I
guess
I'm
sort
of,
like
generally
like
I,
mean
I
sort
of
have
my
head
that
there's
four
to
main
to
main
environments.
Here,
one
is
basically
Enterprise
cases
in
which
case
you're
like
a
lot
of
people,
but
you
do
a
lot
of
bulk,
adding
and
that
person
just.
N
K
M
I
mean
if
we
assume
that
the
creator
should
you
know,
never
be
evicted
or
if
we
want
to
evict
the
creator
it's
allowed
to
be
super
expensive,
then
we
can
actually
calculate
the
direct
paths
for
the
people.
We
add
I,
think
that
could
work
if
you
had
a
ton
of
people
after
the
creation
but
would
have
to
look
into
the
details.
I.
K
Think
that
would
be
a
simplification.
I
propose,
unless
somebody
thinks
alike,
those
important
kiddos
or
I
like
Seth,
or
a
lot
of
different
additions
and
I
spent
more
time
sure
I
spent
more
than
average
thing
at
the
tree
mouth
here,
I'd
like
to
nevertheless,
I
spend
the
first
10
minutes
being
like
you
copass
and
resolution
like
my
head,
like
hurts
it's
like
the
more
we
can
make
this
not
complicated
for
people
like
unless,
like
this
like
a
lie
again,
I
think
the
better.
J
J
Not
an
expensive
group
to
operate
in
might
be
like
if
the
if
the
efficiency
is
unpredictable
and
people
are
like
I,
don't
know
why
this
group
is
so
expensive
to
operate
and
the
trade-off
is
between
that
or
a
design
where
we
say
yes,
some
groups
have
admins
and
admins
are
expensive
to
evict,
like
that's
a
very
clear
and
predictable
behavior,
and
that
might
turn
out
to
be
easier
just
to
manage
in
terms
of
setting
expectations
for
the
users.
But.
M
Well,
I
think
I
curves
idea
to
basically
extend
the
the
warming
up
to
a
situation
where
you
add
a
bunch
of
people
after
creation.
That
would
be
interesting
to
see
if
that
words
are
searched
by
pre-populating
their
direct
path
and
and
what
the
efficiency
is
there.
And
if
we
come
to
the
conclusion
that
that
does
well,
then
yeah,
we
should
simply
add
both
things
to
the
spec.
Yes,.
I
I
C
I
Write
a
PR
that
does
in
it
and
with
this
and
then
I
think
along
with
that,
in
that
first
rush
is
adding
a
flag
to
the
trees
tree
node
struct,
to
indicate
that
a
node
has
tainted
its
double
joined,
yeah
and
I.
Think
you
will
you
hear
out
the
details
almost,
but
you
need
the
flag
there.
So
that's
kind
of
the
first
caution
and
I
think
the
second
trust
you
might
consider
is
effectively
a
batch.
Add
function
where
you
can
introduce
you.
I
Yeah
right,
so
so
the
yeah.
That's
that's!
Why
I
pause
and
make
noises
about
figuring
out
the
details,
because
the
critical
thing
is
that
the
participants
in
the
group
need
to
know
which
part
for
which
participants
when
those
participants
are
evicted,
do
they
need
to
delete
all
the
tainted
nodes
right.
I
I
L
D
M
M
N
M
I
mean
trees
are
not
guaranteed
to
be
balanced
anyway,
they're
they're
supposed
to
be
left
balanced,
but
now
that
you
can
remove
people
and
rank
their
path
they're
punctured
anyway,
so
trees
really
have
really
changed
in
shape
with
blanking
quite
a
bit,
because
you
can
think
of
them
as
a
collection
of
Supremes
some
extent.
But
yeah
can.
M
It
from
the
on
the
left
side
of
the
tree.
You
have
a
lot
of
blank
nodes,
then
yes,
otherwise
it
just
grows.
The
tree.
I
mean
that
they
don't
get
really
unbalanced.
The
only
thing
is
that
they
miss
a
lot
of
inner
nodes
so
that
that's
why
it
becomes
inefficient.
There
is,
however,
one
proposal
on
the
mailing
is
right
now,
which
I
think
makes
a
lot
of
sense,
and
that
is
to
add
people
into
the
spots
that
have
been
blanked
previously
simply
to
make
the
tree
look
nicer
again.
So.
G
P
C
I
Now,
when
I
say
authentication,
this
is
how
do
we
ensure
that
all
the
participants
of
the
group
have
a
consistent
view
of
the
public,
keys
and
identities
of
the
members
of
the
group,
and
how
do
they
use
that
information
to
authenticate
handshake
messages
as
they
come
in?
So
in
the
in
the
version
before
the
interim
I?
I
This
is
great
so
that
the
confidentiality
keys
are
tied
to
the
consistent
view
of
the
group
state.
So
you
have
a
nice
correlation
there.
The
thing
that
someone
observed
at
the
interim
is
yeah,
that's
great,
but
you
never
have
a
the
participants,
never
realized.
They
have
different
keys
and
some
messages
don't
decrypt.
So
the
suggestion
that
Cass
Kramer's
made
at
the
interim
was
to
have
some
explicit
key
confirmation
as
part
of
this,
and
so
that
is
the
addition
that
was
made
in
the
latest
version
of
the
draft.
I
So
in
draft
o2
we
had
now
have
a
key
confirmation
back.
So
we
you
basically
process
this
check
message
to
update
your
group
state
to
get
a
new
group
key
for
this
new
epoch,
and
then
you
use
that
new
group
key
to
compute
a
Mac
over
the
handshake
message
to
verify
that
you've
gotten
the
same
thing
as
the
sender.
So
now
by
the
time,
you're
finished,
processing
a
handshake
message.
I
I
The
only
real
question
that
came
up
can
you
fix
the
amoment
there
another
one
question
that
came
up
in
the
discussion
of
this,
which
was
admittedly
a
little
rush
because
it
came
in
right
before
the
draft
deadline
was
whether
to
have
whether
they
have
this
confirmation,
be
a
Mac
or
to
just
derive
something
off
the
key
schedule.
So
I
made
two
PRS,
the
one
of
them
got
merged,
I
forget
which
is
which
only
got
merged.
The
other
is
still
open.
The
observation
here
is,
you
know
in
TLS,
following
CSS
pattern.
I
We
derived
the
key
that
you
use
for
the
Mac
off
of
the
key
schedule,
but
the
key
scheduled
this
derived
secret
operation
already
folds
in
the
group
state,
which
includes
a
hash
of
the
the
handshake
message
you
just
processed.
So
the
group
state
and
the
messages
process
are
all
included
in
the
derivation
of
this
confirmation
key
so
in
principle,
I
think
without
having
built-ins
hammer
and
model
of
this
I
think
that
if
you
just
publish
that
group
that
confirmation
key
in
the
handshake
message
and
everyone
checks,
they
got
the
same
confirmation
key,
that's
sufficient.
I
If
it
proves
the
same
thing
that
you
would
get
as
using
that
thing
in
a
Mac,
so
it's
a
Mac
over
the
handshake
message
now,
what's
it
what
actually
landed
in
the
draft?
Is
you
take
that
confirmation
key
and
you
use
it
to
compute
a
Mac
of
the
handshake
message
so
which
is
very
much
parallel
to
what
TLS
does
in
terms
of
doing
it's
finished
Mac,
so
to
do
the
confirmation
there.
I
But
the
feeling
on
the
list
was
that
you
know
people
are
vaguely
more
comfortable
with
the
extra
HVAC
because
it
looks
more
like
TLS,
so
I
just
want
to
put
this
on
the
screen
in
case
anyone
had
any
other
opinions.
Anyone
wanted
to
express
their
visceral
discomfort
with
publishing
things
derived
off
the
key
schedule,
or
it
says
publishing
and
Mak
values,
otherwise,
I
think
we're
going
to
just
going
to
keep
the
Mak
until
the
academics
toss
something
one
way
or
the
other.
You
know
have
a
nice
thumbs
up
from
Chris
Wood.
F
D
Can
you
hear
me:
is
this
working
yep,
okay,
hi
everyone,
so
I'm
gonna
be
presenting
about
its
it's,
not
really
a
finished
proposal,
but
rather
something
that
I
think
might
be
interesting
in
certain
parts
of
MLS,
which
is
a
sort
of
primitive
or
scheme
that
I,
don't
think,
has
been
discussed
before,
even
though
the
underlying
problem
has
been
discussed
very
much
I.
Think
since
the
beginning.
So
next
slide,
please
alright.
D
And
so
why
is
ephemeral
signing
interesting
because
in
MLS,
as
in
signal
as
in
OTR
and
essentially
any
mainstream
secure
messaging
protocol,
you
have
a
long-lived
signature
key
and
that
signing
key,
never
changes,
and
it's
always
assumed
that
if
you
have
a
compromise
of
the
state,
then
that
long-term
identity
key
is
going
to
have
to
be
leaked.
So
I
I
think
that
it's
obvious
that
we
cannot
change
the.
We
cannot
have
a
rotating
long-term
identity.
Key.
D
That's
definitely
out
of
the
question,
but
I
do
still
want
to
see
how
we
can
address
that
problem
and
how
we
can
sort
of
try
to
limit
the
impact
of
long
term,
identity
or
long
term
signing
keys
as
much
as
possible
all
right.
So
the
the
idea
behind
hdk
is
essentially
that
if
you
have
a
private
key,
you
can
generate
a
public
key
from
that
private
key.
D
D
D
But,
however,
what
really
was
encouraging
to
me
is
seeing
this
paper
called
hierarchical,
deterministic
keys
over
a
nonlinear
space,
which
essentially
shows
that
it's
possible
to
apply
this
technique
to
280
to
509,
despite
8255
or
nine,
having
clamping
and
clearing
of
individual
bits
and
hashing
and
other
things
that
are
just
not
a
linear,
scalar
multiplication,
so
that
that
was
encouraging.
So
next
slide,
please.
D
So
this
is
how
this
would
generally
work.
So
if
you
just
have
a
so
at
the
top,
we
will
so
it's
essentially
a
tree
like
structure
and
at
the
top.
We're
gonna
have
this
root,
a
signature
key
or
a
root
public
key,
so
that's
KB
and
blue,
and
then
from
that
you
can
just
do
an
HK
D
F
with
Kb,
but
also
with
so
sorry.
D
So
if
you
look
at
the
left
most
child
key,
the
leftmost
green
block
from
there,
you
can
also
derive
something
that
is
called
a
hardened
child
key,
and
the
reason
for
that
is
that
the
hardened
child
key
shown
in
orange
instead
of
just
using
X,
uses
actually
the
output
of
the
previous
edge
KDF.
So
it
has
a
higher
level
of
sort
of
separation.
D
Shall
we
say
from
the
original
key
material
and
hardened
child
Keys
have
stronger
security
properties
for
reasons
that
I,
don't
think,
are
relevant
right
now,
but
we,
if
we
end
up
using
it,
we
want
to
focus
on
hardened
child
keys
next
slide.
Please
so
I
think
that
I've
been
pretty
hand
wavy
so
far
and
I
want
to
try
to
bring
that
all
together.
D
So
I
think
that
the
improvements
here
are
clear
in
case
of
partial
state
compromise.
But
that's
that
doesn't
matter
because
already
the
initial
signal,
like
method
of
dealing
with
identity
keys,
is
considered
to
be
sufficient
in
case
of
partial
state
compromise.
In
fact,
we
never
consider
the
danger
of
a
signing
key
being
compromised,
except
if
we're
talking
about
full
state
compromise
right.
So
so
far,
it's
not
really
clear
what
hdk
can
actually
bring
to
mls,
and
so
I've
been
thinking
about
this
and
I.
D
Think
that
there's
one
way
in
which
the
additions
that
are
possible
because
of
hdk
or
the
improvements
can
be
explained
so
next
slide.
Please
alright.
So
let's
look
at
the
way
that
signal
desktop
currently
does
key
management,
and
so
all
of
the
popular
secure
messaging
applications
currently
essentially
focus
on
smartphone
usage
for
obvious
reasons,
because
most
people
are
texting
and
messaging
using
their
smart
phone,
but
also
sometimes
maybe
you
want
to
use
them
at
work.
D
So
you
have
a
desktop
client
and
so
the
way
that
signal
does
this
is
when
you're
setting
up
your
desktop
client.
First,
you
have
to
register
using
your
phone,
but
then
there's
a
pairing
mechanism
and
then
all
of
the
keys
are
sent
from
your
phone
to
your
desktop
client,
and
that
includes
the
identity
key
as
well
as
really
just
anything
and
also
all
the
conversation
information,
and
so
this
is
how
it's
done
in
signal,
and
so
both
devices
now
will
have
your
identity
key.
D
D
It
just
has
an
aes
link
to
the
phone,
that's
established
by
scanning
a
QR
code,
and
then
it's
just
sending
requests
to
the
phone.
Please
encrypt
this
message
for
me
and
then
the
phone,
as
we
see
is
forwarding
the
encrypted
messages
back
to
the
computer
and
so
notice.
Here,
unlike
in
signal,
if
you
turn
off
your
phone,
you
will
not
be
able
to
use
whatsapp
on
your
computer.
D
The
phone
has
to
be
turned
on
and
connected
to
the
Internet
at
all
times
for
this
to
work,
because
otherwise,
otherwise
the
computer
cannot
contact
the
phone
and
send
any
messages,
because
all
the
keys
are
on
the
phone.
So
next
slide,
please
all
right.
So
if
we
look
at
signal,
it
would
seem
that
they've
decided
to
focus
on
usability,
so
they
wanted
to
so
that
you
can
turn
off
your
phone
and
you're
still
okay
and
that's
a
reasonable
choice.
D
And
if
you
look
at
what's
up,
it
seems
that
they've
decided
to
focus
on
maybe
security,
because
generally
the
environments
in
which
you're
executing
all
this
secure
messaging
code
on
the
desktop
tends
to
be
from
an
engineering
perspective,
maybe
more
susceptible
to
compromise.
It
maybe
is
running
in
the
web
browser
or
using
web
runtime
environments
and
on
on
phones
you,
especially
if
you're
using
iOS.
You
have
really
good
security
when
it
comes
to
key
management
and
security
in
general,
on
Android
it's
different,
but
on
iOS
it's
it's
very,
quite
secure
compared
to
everything
else.
D
We
needed
to
be
unchanging
for
for
identification
of
authentication
to
work
at
all,
but
what
we
can
do
here
is
that
that
can
stay
on
the
phone
and
then
the
hdk
root
derived
from
that
key
for
that
conversation
or
the
hardened
child
of
it
or
whatever.
You
know
these
are
details
that
we
can
come
to
if
we
decide
that
this
is
a
lucrative
thing
to
research
and
investigate
can
actually,
and
only
that,
for
the
existing
sessions
can
be
transferred
over
to
your
desktop.
D
D
However,
for
existing
group
chats,
you
will
still
be
able
to
authenticate
yourself,
and
so
you
have
the
ability
to
keep
using
your
multiple
devices
without
really
having
a
huge
risk
in
the
way
that
signal
does
have,
and
at
the
same
time
you
will
have
more
usability
in
the
case
that
your
phone
is
offline,
which
is
superior,
maybe
to
what's
up,
and
so
this
can
be
really
good
from
a
usability
perspective.
Because
I
don't
know
if
you
guys
have
ever
had
this
experience.
D
I
use
whatsapp
all
the
time,
and
even
if
my
phone
is
online
and
connected
and
powered
on
and
everything,
there
will
still
sometimes
be
a
delay
because
of
the
power
management
features.
And
so,
if
I
send
a
message,
it'll
take
time
to
arrive
because
the
phone
like
needs
to
be
woken
up
and
I
need
to
open
whatsapp,
because
it's
in
the
background,
and
so
all
of
these
things
will
be
avoided
as
well.
D
I
think
if
we
look
into
this
mechanism-
and
so
this
was
proposed
on
the
mailing
list
very
briefly
a
couple
of
weeks
ago-
some
people
said
that
it's
interesting,
but
there
are
potentially
better
ways
of
doing
it,
and
I
am
very
open
to
these
better
ways.
We
don't
necessarily
have
to
use
hdk
specifically,
but
from
my
from
my
perspective,
the
htk
was
the
idea
that
got
me
thinking
about
this
and
I
think
that
it
might
be
interesting
to
well
actually
next
slide.
Please
so.
B
B
D
It
is
all
right,
so
what
I?
What
I
the
the
general
question,
the
larger
question
that
I
was
asking
is:
to
what
extent
can
we
generalize
stuff
like
hdk,
in
order
to
restrict
the
damage
caused
by
state
compromise,
especially
with
regards
to
signing
keys,
and
that's
all
that
is
my
presentation.
Sorry,
if
I
took
too
long,
no.
J
J
Unless
my
phone
is
online
I'm
wondering
about
the
sort
of
usability
implications
there
and
that
led
me
to
the
question
of
well,
maybe
you
could
actually
maybe
the
phone
could
send
some
like
a
handful
of
not
yet
used
hdk
routes
to
the
to
the
laptop
so
that
you
could
start
a
new
chat,
but
you
can
maybe
only
start
three
or
four
or
something
like
that
as
so.
That's
just
so.
The
users
don't
typically
run
into
this
problem
of
like
wait.
I,
you
know,
I
need
to
I
need
to
message.
J
D
It's
definitely
not
it's
definitely
not
a
story,
illegitimate
compromise,
it's
still
something
that
is
bad.
I
think
that
what
I'm
trying
to
do
is
to
arrive
at
a
well
compromise
is
already
being
used
in
another
sense,
at
a
middle
middle
ground
between
between
what
signal
does
and
what
whatsapp
does,
because
both
approaches
have
really
strong
capabilities.
D
Signal
is
really
nice
to
use
and
fast.
Whatsapp
is
I,
guess
more
secure,
but
slow,
really
like
in
some
cases
like
30-second
delays,
which
are
annoying
in
them
in
the
middle
of
an
active
conversation
with
someone,
and
so
I
do
agree
that
if
you
want
to
do
a
kind
of
pre
key
approach
and
forwarding
all
of
those
keys
onto
the
device,
especially
that
would
even
exacerbate
the
window
of
compromise
that
you're,
mentioning,
which
is
already
quite
serious,
right
being
able
to
be
impersonated.
D
I
have
to
regenerate
a
new
identity
key
and
then
I
have
to
like
everyone's
going
to
freak
out
and
if
I'm
in
a
security
centric
community
everyone's
gonna
have
to
be
authenticate
and
check
my
fingerprints
and
so
on,
and
so
there's
a
sort
of
like
large
hurdle
to
overcome.
In
case
that
happens,
because
the
compromise
is
absolute
right.
D
J
I
think
what
you're
saying
is
that
is
that
recovery
from
compromise
is
actually
the
goal
here
right,
because
because
the
compromise
that
we're
looking
at
in
the
laptop
case
here
is
basically
impersonation
on
all
of
the
active
chat,
active
conversations
that
I
have
right,
and
so
so
the
goal
here
I
think,
is
to
provide
recovery
without
modifying
the
the
long-term
identity.
Key
I.
D
Suppose
I
suppose
that
would
have
to
be
the
case.
Yes,
it's
also
it's
also.
If
so,
it's
true
that
all
of
the
active
chats
would
not
be
protected
by
this,
and
therefore
it
does
make
sense
to
restrict
the
conversation
to
recovery
from
compromise.
The
thing
is:
if
we
look
at
the
current
MLS
spec,
there
is
some
notion
of
ethics,
that's
being
discussed,
and
so
perhaps
I
don't
know
how
this
would
affect
the
usability
element.
D
So
I
don't
know,
maybe
that
would
make
it
better,
but
at
the
same
time,
in
that
case
you
will
need
your
phone
to
be
online
intermittently,
but
maybe
that
may
be
in
fact
that's
more
realistic
because
in
general
people's
phones
are
indeed
turned
on
they're,
just
not
always
connected
to
strong
Wi-Fi,
and
they
don't
always
have
whatsapp
in
the
foreground.
They
do
certainly
have
it.
At
least
once
every
half
an
hour,
so
perhaps
that
is
the
better
way
to
do
things
so.
J
Sorry
this
sounds
really
interesting
from
a
brainstorming
perspective
and
I.
Don't
think
I
want
to
like
push
further
on
on,
like
hashing
it
out
at
the
mic,
but
I,
but
I
think
this
requires
a
lot
of
usability
and
like
saying
hey,
you
could
do
this
with
some
arbitrary
schedule,
because
we
assume
that
people's
phones
will
be
connected
at
some
certain
times,
like
I.
Think
that's
going
to
require
quite
a
bit
of.
D
Okay,
so
I,
first
of
all,
I
just
want
to
say
I
strongly
strongly
agree,
and
this
is
why
this
is
not
like
a
you
know:
guns
blazing
full
proposal.
This
is
like
the
the
title
of
the
slideshow.
It
starts
has
a
question
mark
at
the
end.
At
the
same
time,
it's
not
like
the
devices
are
supposed
to
be
online
at
certain
times,
we're
talking
not
about
a
certain
time,
but
actually
an
interval
so
I
think
that
expecting
devices
which
is
like
whatsapp
expects
them
to
be
online,
24/7,
I
think
expecting
them
to
be
online.
D
At
least
once
every
hour
is
extremely
reasonable,
given
that
it
gives
you,
these
legitimately
improved
authentication
guarantees
in
the
event
of
a
compromise.
So
that's
something,
but
yes,
this
is
something
that
I
need
to
sit
down
and
work
out
properly,
but
I
did
want
to
present
it
because
I
think
it's
interesting
and
I
think
I
will
certainly
be
like
have
a
better
opportunity
to
work
it
out
properly.
If
I
have
your
insight
and
feedback
any.
G
More
I
don't
work
for
whatsapp
or
or
Cigna,
but
from
my
personal
experience
or
if
you
know
more,
please
come
in,
please
come
up.
I
strongly
suggest
it
nice
that
signal,
choose
readability.
What
I'd
say:
security,
it's
actually
quite
the
opposite,
like
whatsapp,
it's
the
simplest
thing
possible
just
to
make
multi-vise
work,
which
in
this
case
not
too
much
advice.
However,
signal
made
too
much
device.
He
just
changes
in
idle
its
key.
G
D
D
If
you
were
to
do
that
and
so
I,
don't
because
like
if
you
look
at
the
way
that
whatsapp
or
signal
does
it,
you
have
these
QR
codes
that
are
generated
from
identity
keys,
but
in
the
case
of
multiple
devices
and
the
deployments
that
I've
seen,
for
example,
Oh
MIMO,
there
is
a
different.
You
know
hash
or
fingerprint
or
QR
code
for
every
device,
and
so
certainly
this
is
a
potential
direction
to
look
into.
But
there
are
some
complications
with
regards
to
authentication.
I
We
can
say
a
whole
lot
about
cross
group
usage
of
keys
I'm,
not
sure
that
that
cross
group
usage
is
all
that
salient
for
MLS.
So
what
what
is
salient,
though,
is
the
scoping
of
the
key
within
the
context
of
a
single
conversation,
single
group,
and
in
that
sense
it's
it's
more
I'll,
say
linear
than
hierarchical,
I.
Think
I
I
think
it's
there's
still
possible
applications
here,
but
I
haven't
quite
cracked
all
the
way.
It
might
be
interesting.
I
To
contrast
with
the
kind
of
naive
approach
to
mitigating
the
risk
of
signing
key
compromise,
which
is
to
have
you
know,
sequential
signing
of
identity
keys
where
you
roll
over
the
identity,
keys
inside,
have
the
the
old
keys
on
new
key
and
basically
have
a
thermal
signatures
in
that
way,
which
I
think
Purdue
should
propose
a
little
while
ago.
So
it
would
be
interesting,
I,
don't
know
we
need
to
hash
it
out
here
at
the
Mike,
but
it
would
be
interesting
to
be
able
to
kind
of
compare
and
contrast
that
approach
with
the
approach.
H
D
D
So
when
I
present,
something
like
this
I
have
to
have
some
axioms,
some
some
foundations
and
the
best
found
a
that
I
was
able
to
come
up
with
the
ones
that
seemed
to
be
the
most
standard
or
unsafe
is
that
we
currently
are
operating
in
a
model
where
we
just
have
a
long
term
identity
key
that
never
changes.
And
how
can
we
proceeding
from
that
starting
point?
Make
things
better,
I
think.
G
You're,
mixing
the
content
between
identity
and
signing
keys,
so
that
is
a
contract
for
the
official
dot
saying
the
long.
The
only
long-term
one
is
the
identities
for
signing
keys.
We'll
have
couple
of
modes
as
I
mentioned
earlier
about
deniability,
but
we
always
mentioned
signing
key
keys
are
to
change
it
like
per
conversation.
So
I
don't
think
that
is
mentioned.
Someone
is
that
right,
let's
say
signing
keys
are
long-term
peace.
I
didn't
give
the
ex-king.
D
Q
Hi
yeah
Nadine
for
this
proposal,
so
I
was
just
wondering
really
how
this
compares
against
a
situation.
Where
say,
every
device
has
their
own
key,
but
when
you
do
that,
when
you
scan
the
QR
code
and
irrelevant
exchange
and
to
have
the
master
device,
just
sign
the
identity
key
of
the
new
device,
so
you
sort
of
effectively
still
have
a
single
identity
key,
but
other
devices
have
revocable
keys
without
having
to
actually
share
anything.
D
So
that
could
also
work
that
that
device
would
be
able
to
start
new
conversations
on
its
own
without
querying
the
long
term
identity
key
on
the
original
device
that
may
come
with
a
different
set
of
consequences
in
the
event
of
the
compromise
of
that
device.
The
second
device
which
could
be
could
could
be
weaker,
I'm,
not
sure
I
can't
you
know,
do
a
symbolic
analysis
right
now.
No.
N
M
So
if
I
try
to
completely
oversimplify
what
the
goals
are
of
MLS,
one
is
to
make
secure
messaging
efficient
for
large
groups
and
we've
been
saying:
50k
is
a
large
group.
Sometimes
we
said
100
K,
and
so
this
is
what
I
want
to
focus
on
a
little
bit
so
in
in
order
to
measure
efficiency
operations
that
are
generally
expensive,
like
DPM
and
key
agreements
or
signing
or
other
things
is
what
we
need
to
measure.
M
And
so,
if
n
is
the
group
size
the
number
of
people
in
a
group,
then
some
of
it
can
be
a
linear.
Some
of
it
can
be
logarithmic,
and
sometimes
we
also
have
a
constant
time
for
operations
so
with
a
number
of
current
messaging
systems.
When
you
want
to
send
out
a
message
in
a
group
you
encrypted
individually
to
every
participant,
you
can
call
that
bgp
style
in
a
way.
So
this
is
very
expensive
because
it
is
an
operation
that
happens
at
a
pretty
high
frequency,
assuming
that
the
messaging
service
is
actively
being
used.
M
So
the
question
is:
how
is
MLS
better
in
terms
of
efficiency,
and
so
one
thing
that
was
clear
immediately
with
the
our
proposal
is
that
establishing
a
group
secret
is
quite
efficient,
because
you
should
put
members
in
a
tree,
then
that
becomes
logarithmic.
But
the
question
is:
are
there
other
operations
that
are
not
logarithmic
and
what
are
those
and
and
what's
left
so
just
want
to
give
a
brief
overview
of
that,
and
so
the
tree
kam
actually
solved
the
problem,
as
we
discussed
earlier
for
adding
and
removing
people.
M
So
when
you
remove
them,
you
can
you
can
blank
direct
path
and
generally,
that
is
still
logarithmic.
Although
there
is
a
certain
overhead
now,
but
it's
certainly
not
linear
other
than
image
cases
and
adding
is
the
same
particularly
when
you
warm
up
the
tree
as
we
discussed
earlier,
so
that
is
then
roughly
logarithmic
as
well.
M
So
what
yeah
one
one
way
to
basically
understand
what
efficiency
means
is
operations
that
are
costly
should
be
in
log
of
n,
and
if,
if
we
don't
manage
to
do
that,
then
essentially
we
have
a
peak
at
the
end
of
the
day
in
the
user
experience
which,
which
is
not
great.
So
this
is
maybe
how
MLS
is
gonna
work
most
of
the
time
so
once
in
a
while,
there's
going
to
be
a
group
operation
in
our
vlog
and
at
least
for
the
creator,
and
that
can
be
processed
on
the
recipient
side
in
constant
time.
M
So
if
we
can
get
everything
to
look
like
that,
that
would
be
the
ideal
solution
in
terms
of
efficiency,
and
so,
as
I
mentioned
already
so
for
the
the
group
creation.
We've
made
it
sort
of
logarithmic
now,
but
we
still
have
two
scenarios
where
it
is
linear
and
they're
sort
of
correlated.
So
one
is
when
you
invite
a
member
and
the
other
one
is
when
you
add
a
device,
if
you
run
MLS
in
a
multi
device
context.
M
So
when
you
invite
a
member
that
you
currently,
you
create
a
welcome
handshake
message
which
contains
all
of
the
tree
and
all
of
the
roster,
because
the
spec
says
that
every
participant
should
have
a
complete
view
of
the
tree,
and
that
goes
into
the
key
schedule.
So
everybody
needs
it,
and
so
this
is
directly
sent
from
one
member
to
another
as
part
of
the
working
message
and
when
you
add
a
device.
J
So
can
I
just
ask
on
the
previous
slide
here
for
device
ad.
It
sounds
like
you're
talking
here
in
a
situation
where
we
are
assuming
separate
identities
per
device
and
we're
treating
the
device
ad
in
that
context,
because
there
is
another
approach
which
says
that
a
device
ad
by
a
given
user
is
simply
reflected
to
the
group
as
a
refresh
right.
You
run
tree
camp
for
your
own
devices
and
then
adding
a
device.
Just
means
that
you
prefer.
You
change
your
yes.
N
M
Or
no
so
I
mean
that
is
true.
You
can
basically
mask
how
many
devices
you
have
to
the
rest
of
the
group
by
having
just
one
leaf
and
under
that
leave
you
you
have
like
your
own
private
tree
of
devices
and
then
you
just
do
the
update,
but
it
doesn't
fully
solve
the
problem
in
the
sense
that
the
new
device
still
needs.
Some
state
needs
to
get
it
from
somewhere
needs
the
at
least.
You
know
that
the
public
keys
of
the
tree,
it
needs
its
own
private,
leaf
key
sure.
M
Yeah
sure
it's
it's
not
broadcaster
to
the
group,
of
course
yeah,
because
why
would
you
do
that?
But
it
needs
to
be
transferred
between
the
two
users.
If
you
assume
that
you
have
some
sort
of
device
pairing
process,
if
you
don't
have
that
and
most
Sims
currently
don't
have
that
if
you
basically
log
into
your
device
and
want
to
connect
that
to
your
MLS
account,
then
that
device
needs
to
get
the
state
from
somewhere.
M
So
if
your
current
devices
are
not
around
or
you
lost
the
mod
or
whatever,
it
really
needs
to
get
to
safe
from
somewhere
and
and
as
Richard
pointed
out,
this
is
clearly
a
question
of
payload.
It
is
in
this
case
it
is
not
a
question
of
computational
resources,
so
currently
the
welcome
and
check
message
as
it
is
defined
in
the
spec
growth
rather
quickly.
So
for
a
group
of
50,000,
it's
almost
5
megabytes.
M
So
this
is
very
far
from
the
efficiency
we
have
achieved
with
all
other
operations
and
in
the
context
of
adding
a
device.
The
payload
per
conversation
is
basically
a
welcome
handshake
message,
so
you
can
multiply
that
by
the
number
of
conversations
you
have
on
your
device.
So
if
they're
small,
it
doesn't
matter
too
much,
but
if
you
have
a
number
of
large
ones,
this
could
be.
You
know
tens
of
megabytes
at
least.
C
L
Is
just
showing
that
the
Welcome
handshake
is
linear
in
the
number
of
group
messages
and
to
some
extent
we
had
already
accepted
that
there
was
gonna,
be
a
linear
amount
of
state
in
terms
of
the
roster
and
the
identity,
keys
and
whatnot,
and
so
it's
a
little
bit
unclear
to
me
how
worried
exactly
we
need
to
be
about
this,
because
there
is
this
or
unavoidable.
Linear
cost
and
I
mean
yes,
you
can
argue
about
the
constant
factor,
but
it's
still
just
the
house
infecting
yeah.
M
I
mean
one
aspect
of
this
is
to
actually
make
it
clear
that
this
exists
and
then
Richard
later
is
gonna
talk
a
bit
about
potential
solutions,
so
yeah
that's
right
below
a
so.
The
question
is:
can
can
the
tree
and
the
roster
be
signed
out
of
band
somehow,
and
could
the
server
be
this
out
of
band
Channel
and
assist
with
storing
at
least
some
of
the
tree,
yeah
and
I?
Guess
that
you
stand
over
to
Richard.
I
So,
yet
to
the
point
that
was
made
earlier,
I
think
that
there
there
is
inevitably
the
the
new
Anuja
node
joining
the
conversation
is
gonna
have
to
download
linear
state,
and
the
question
here
is
whether
the
entity,
adding
that
node
should
have
to
upload
linear
state
or
whether
the
server
can
kind
of
glean
and
maintain
a
copy
of
it
on
its
own.
So
yeah,
it's
a
recap.
Those
two
questions
and
these
reflect
those
different
changes
to
the
spec
as
well.
I
J
J
I
Well,
actually,
I
think
the
the
dis
it's
a
little
more
important
than
that
in
that.
If
we
assume
that
the
welcome
message
it
well
that
the
information
here
is
that
these
commitments
here
are
whatever
goes.
Alright,
let
me
just
summarize
the
slide.
The
proposal
here
in
protocol
terms
is
to
take
the
roster
entry
and
instead
of
having
those
by
value
and
the
commitment
just
put
a
in
the
welcome
message,
just
put
a
commitment
to
those
things.
I
So
if
these
things
that
the
hashes
of
these
the
commitments
to
those
parts
of
the
state
are
what
go
in
the
group,
state
objects,
probably
should
have
shown
in
the
group
stay
here
instead.
Well,
so
if
those
commitments
are
what
going
into
the
group
state,
which
is
what
goes
into
the
key
schedule,
then
the
new
member
can
join
the
group
and
compute
the
current
group
keys.
Just
by
having
this
constant
sized
object
and
not
downloading
the
group's
the
whole
linear
size
state
immediately.
I
I
Lazy
joint
you
can,
and
he
could
download
that
stuff.
It
doesn't
block
his
entry
into
the
group
and
his
ability
to
read
messages
that
are
being
sent
to
him.
Particularly
I
think
this
is
probably
a
good
idea
just
because
it
maintains
looser
coupling
it
would.
It
would
allow
out-of-band
distribution
in
cases
like
Raphael
proposes,
and
we
could
also
define
some
IND
and
stuff
just
like
roster
and
tree
nuts,
just
the
hands
and
stuff
in
band.
If
people
want
to
have
mechanism
to
find
here
so.
J
I
That's
fair
enough:
okay,
yeah,
because
I
think
the
spec
change
would
be
to
replace
these
values
and
welcome
message,
also
replace
them
in
the
group
state.
So
right
now
we
have
a
transcript
hash
in
the
group
state.
It
would
also
have
roster
and
tree
hashes
instead
of
the
things
by
value,
so
that
you
could
join
the
key
schedule
without
having
one
at
linear
size,
state.
M
Yeah
yeah,
maybe
try
to
that
so
I
mean
right
now
you
need
a
view
of
the
whole
tree
for
the
group
state,
but
if
we
replace
that
with
hashes
but
could
still
work
so
there's
situations
where
you
need
certain
elements
of
the
tree
is
when
you
want
to
remove
someone
or
an
actually
that's
it
right
now.
Well,.
K
Right
I
mean
it's
always
so
well,
I
think
my
understanding
is
is
in
order
to
like
just
send
messages.
All
you
need
is
the
route
in
order
to
process
updates.
You
need
your
own.
You
need
your
own
path
in
order
to
send
updates,
you
need
to
click
your
own
Co
path,
SEC,
correct,
correct
and
so,
and,
and
so
only
time
and
and
and
and.
I
I
It's
it's
actually
slightly
worse
than
that,
in
that,
when
you
receive
an
update,
you
need
to
update
the
tree
hash
that
you
have,
which
means
you
know,
depending
on
how
we
construct
that
hash.
You
might
need
to
have
the
whole
tree
like
you're,
just
taking
a
hash
of
a
representation
of
the
tree
that
he
needs
up
to
girls
and
stuff
I.
I
I
K
I
N
K
I
mean
I
about
that,
so
you
know
I
mean
yes,
so
I
think
you
know
like
I'm
all
for
reducing
complexity,
but
I
think
it'd
be
I,
guess
like
maybe
we
can
increase
the
complexity
now
and
reduce
complexity
later,
which
is
maybe
we
can
actually
worked
out
what
the
answer
these
questions
is
and
then
and
then
see
like
if
there's
a
sweet
spot.
I
I
Right,
that's
all
I'll,
take
the
action
point
Rebecca!
It's
like
go
through
the
analysis
and
see
you
know
if
we
can
come
up
with
a
hashing
scheme
that
can
be
selectively
updated
for
the
operations.
Ok.
This
is
this
is
perhaps
the
more
interesting
question
so
I
think
the
the
model
Rafael
is
positing.
Is
that
the
server
you
know
in
order
to
or
avoid
this
need
to
upload
linear
state?
I
When
you
add
someone
you
could
have
the
server
just
watch
messages
go
by
and
where
this
comes
in
detentions,
we've
discussed
often
on
this
idea
of
encrypting
the
handshake
messages
as
they
transit
the
server
to
hide
things
like
the
state
of
the
tree.
The
membership
of
the
group
in
order
to
you
know
enable
the
server
to
maintain
a
cache
of
the
roster.
You
would
need
to
expose
to
that
to
the
to
the
server
the
stuff
that
goes
in
the
roster,
so
the
identities
of
the
people
in
the
group
and
their
credentials.
I
If
you
do
that,
there's
not
a
hole.
If
you
expose
it,
so
you
know
the
stuff.
That's
in
colors
here
is
the
stuff
that
you'd
need
to
expose
to
make
that
cashing
effective.
The
upshot
of
it
is
you,
if
you
do,
if
you
expose
all
that
stuff
and
there's
not
a
lot
left
in
the
handshake
messages
its
protect,
so
it
may
not
be
worthwhile
even
pondering
any
sort
of
handshake
encryption.
If
we
want
to
allow
the
servers,
it's
a
cache
all
this
stuff.
I
So
that's
kind
of
the
question
like
where
do
people
right?
So
what
we're
exposing
here
is
mainly
public
keys
in
terms
of
the
contents.
The
amount
of
the
handshake
message
that
part
doesn't
Samee
seem
all
that
controversial,
because
it's
just
public
keys,
public
keys
are
public,
but
the
what
my
what's
more
concerning
here,
as
perhaps
the
credentials
that
would
expose
the
the
identities
involved
in
a
group,
but
even
there
I
think
that
some
folks
have
pointed
out
that
the
server
has
to
in
in
most
deployment
scenarios.
I
G
I
J
I
think
that
the
medic
like
just
throwing
in
the
towel
on
metadata
protection
at
this
stage
of
the
game
is
premature
and
I
would
be
pretty
sad
if
we
decided
to
do
that
and
I
think
that's
what
the
no
handshake
encryption
publish
all
the
identifiers
to
the
server
basically
means
is
just
punting
on
metadata
protection.
I
will
acknowledge
that
I'm
not
convinced
that.
So
the
way
this
was
presented
was
basically
like.
Look
at
these
huge
groups.
Look
how
expensive
they
are
to
join
and
I'd.
J
Be
pretty
sad
if
this
meant
that
MLS
in
a
non
huge
group
lost
all
metadata
protection
simply
because
we
expect
to
lose
all
meditative
reaction
for
large
groups
right.
It's
true
I,
don't
actually
care
that
much
about
metadata
protection
for
a
group
with
a
hundred
thousand
people
in
it
like,
because
probably
it's
all
exposed
to
all
hundred
thousand
of
those
people
and
those
hundred
thousand
people.
One
of
them
is
gonna
leak
that
metadata
list
somewhere.
J
But
if
you
tell
me
that
a
group
of
12
people
or
a
group
of
a
hundred
people
who
are
using
MLS
to
communicate
are
gonna
have
that
group
membership
directly
leaked
but
by
the
handshake
message
to
the
server.
That
would
make
me
sad
so
where
it
says
two
modes.
I
would
hope
that
in
that
that,
if
we
define
this
we're
not
talking
about
you
know,
your
MLS
deployment
should
offer
mode
a
or
mode
B.
I
We
discuss
that
some
I
think
that
it
is
possible
that
end
points
for
reject
messages.
I
think
my
initial
reaction,
that
was,
you
know
you
could
have
some
knack
scheme
where
yeah
you
could
just
provide
feedback
to
the
server
and
say
never
mind
that
one,
but
but
to
be
sure
there
are,
you
know,
can
issues
with
maintaining
consistency,
I.
P
I
M
Yeah,
coming
back
to
your
point,
so
I
fully
agree
that
it
is
a
bit
harsh
to
basically
get
rid
of
the
privacy
we
had
around
handshake
messages.
Just
spoke
very
large
groups,
so
I
think
it
could
be
a
model
where
this
is
entirely
optional
and
we
keep
on
encrypting
or
we
go
towards
encrypting,
handshake
messages
and
having
a
very
opaque
modus
operandi.
M
But
then
the
credentials
is
is
something
different,
so
they're,
potentially
I
think
the
idea
Richard
was
that
we
would
only
expose
part
of
the
credentials
and
that's
why
they're
in
blue
here
so
in
the
user
init
key,
you
would
only
expose
the
diffie-hellman
key
of
that
to
the
server,
but
not
the
actual
signature,
because
the
server
does
need
the
signature
to
to
basically
cache
than
fake
messages.
So
yeah
it's
it's
not
something
that
that
is
quite
clear
in
general,
so
we
need
to
come
up
with
a
concrete
proposal
to
basically
take
decisions.
B
Yep,
so
that's
we're
out
of
time.
For
today
we
do
have
another
session,
we're
gonna
kind
of
bump
the
message
protection
stuff
down
to
be
done.
Thursday
Benjamin
can't
make
it,
but
Richard
said
he
could
do
the
slides
and
we're
basically
just
gonna
recap
what
we
did
at
the
the
interims
to
get
people
up
to
speed.
So.
I
I
Know
action
items
are
this
last
slot,
so
I'm
I'm
gonna
plan
to
change
the
welcome
message
and
group
states
use
commitments
and
then
do
the
analysis
that
echo
suggested
about
who
needs
what
money?
How
do
we
can
make
that
commitment,
updating
and
scalable
Rafael
I
like
to
assign
you
the
the
action
items
to
take
a
look
at
at
this
question
of
how
you
might
be
able
to
do
it
out
to
bowl
handshake
message
encryption,
so
a
lot
of
the
server
decease
or
so
said?
Alright,
thanks
cool.