►
From YouTube: IETF104-MLS-20190326-1350
Description
MLS meeting session at IETF104
2019/03/26 1350
https://datatracker.ietf.org/meeting/104/proceedings/
A
A
B
A
You
have
any
IPR,
you
declare
it.
Obviously,
we've
got
some
processes
and
procedures
that
you
can
read
about
from
the
list
there.
It's
about
it
requests.
We
have
a
jabber
scribe,
Thank
You
dkg.
What
who
who
who
would
okay?
So
we
need
a
jabber
scribe
and
we
need
a
minute
taker
so
minute
take
her
X.
Oh,
you
do
minute
taker
all
right
great
and
if
you
have
to
bail,
then
we
can
swap
that's
awesome.
A
There's
some
blue
sheets
going
around
I
appreciate
that
if
you
do
that,
if
you
do
the
minutes
in
the
ether
pad,
then
other
people
can
link
into
it
as
well.
Do
you
know
where
that
is
all
right
cool?
Please
state
your
name
into
Mike
and
as
well,
keep
a
professional
at
the
Mike.
A
C
Have
the
power
Richard
burns?
One
minor
agenda
bachelor
since
I
think
you
mad
is
not
going
to
be
here
until
the
Thursday
session
I
might
propose,
taking
the
simplify
key
schedule
thing,
which
is
one
of
his
big
care
abouts
and
moving
that
to
a
Thursday
and
moving
the
identifiers
discussion,
evidence
that
slot,
which
I
think
I
said
she
slides
for
both.
A
C
C
All
right,
so
we
get
for
having
the
first
session
after
one
chance'
turn
on
all
the
equipment.
Again.
So
just
a
brief
interrupt
of
dates.
We
have
four
or
five
implementations.
Going
raise
your
hand
if
you
have
an
implementation
of
MLS
in
progress.
Oh,
oh,
is
that
do
go
there,
excellent
cool
good
to
see
it
so
yeah
we've
got
Cisco
wire,
Google
trail
of
bits
and
INRI
all
doing
implementations.
The
approach
we've
been
taking
right
now
is
kind
of
operating
off,
generating
test
vectors
for
different
chunks
of
the
protocol.
C
So
we've
got
test
vectors
for
the
tree
math
for
the
resolution
algorithm
for
the
key
schedule
for
the
core
key
scheduler
for
the
application,
key
scheduling
for
some
of
the
message
parsing.
So
that's
kind
of
the
the
framework
in
which
we've
been
doing
interrupts
so
far,
not
doing
kind
of
live,
interrupts
between
stacks
I'm,
trying
to
kind
of
gradually
work
our
way
up
to
that
by
getting
the
the
core
parts
the
protocol.
So
we
we
had
some
calls.
You
may
have
seen
scheduled
on
the
list.
The
first
couple
of
calls
we
had.
C
You
used
reports
recently
as
well.
I
saw
some
green
in
there
for
you,
so
we've
got
a
fair,
a
fair.
You
know
some
some
some
slots
in
the
matrix
filled
in
so
we're
starting
to
get
some
inter
up
on
core
parts.
Protocol
I
think
the
like
the
tree
math
and
resolution
stuff
that
doesn't
involve
any
crypto
like
that.
You
know
people
have
developed
their
own
implementations
and
and
then
we're
agreeing
on
that
by
and
large
and
they're
starting
to
ratchet
up
and
verify
that
real
crypto
stuff
starts
to
match.
C
D
So
the
the
interim
meeting
we
had
between
the
last
ITF
and
this
current
one
was
held
in
Mountain
View
right
next
to
real
world
crypto.
So
we
did
get
some
other
interested
parties
who
were
in
adjacent
conference
for
real-world
crypto
who
showed
up,
and
there
were
some
pretty
substantive
conversations.
D
Presentations
about
the
encryption
of
welcome
messages,
add
in
place,
lazy,
handshake
messages,
proxy
rien,
Krypton
for
server
assists
user
initiated.
Add
a
brief
update
on
analysis
as
well
as
definitely
some
some
conversation
about
efficiency
and
one
other
thing
that
was
brought
up.
That
we
will
talk
about
here
is
there's
the
possibility
to
have
a
federation
component
and
a
federation
milestone,
as
well
as
a
document
that
you
might
has
has
published
as
an
individual
draft
that
should
become
coming
up
as
well.
D
There
are
also
alternative
tree
math
proposals
made,
one
of
which
was
about
a
two
to
three
tree,
so
we'll
see
if
that
results
in
a
draft
being
sent,
sent
forward
to
be
discussed
here
or
not.
But
I
have
not
seen
seen
that
yet,
and
it
was.
It
was
a
pretty
great
event
because
all
the
people
who
did
show
up
participated-
and
there
was
a
lot
of
a
lot
of
conversations
that
the
notes
are-
are
available
in
the
on
the
data
tracker
for
this
okay.
So
any
questions
about
the
interim
meeting.
D
F
G
Okay,
so
I'm
gonna
quickly
discuss
about
the
architecture
stuff.
Basically,
nothing
has
changed
much
since
the
last
few
interims,
because
we
focused
a
lot
on
the
on
deonda
protocol
on
the
protocol
document.
So
one
thing
that
changed
across
both
document
is
the
fact
that
we
are
on
the
architectural
document
terminology
instead
of
the
protocol,
one
that
was
using
something
called
participants.
So
now
everything
is
using
client
and
the
protocol
document
was
moved
to
effect.
G
So
since
there
are
not
too
many
things
to
say
and
I
just
took
the
slides
from
ITF
one
or
two
when
I,
when
we
are
go
of
explicit
requirements
and
goals,
and
and
basically
we
can
see
that,
like
most
of
the
things
we
want,
we
currently
have
typically
messages
are
accepted.
Only
member
of
the
group
message
spading
fork,
efika
for
protecting
against
African
and
is
this
has
been
optionally
included
in
the
protocol
documents.
G
But
since
that's
that
still
I
love
all
architectural
role,
that
our
G
notification,
with
the
authentication
of
everybody
who
the
authentication
service
that
we
still
keep
abstract
nothing
changed
so
that
you
can
do
whatever
kind
of
on
education.
He
wants
the
one
thing
that's
going
to
be
discussed,
probably
on
cells.
There
is
deniability
because
it
actually
many
people
want
some
kind
of
deniability
and
it's
been
very
interesting
to
discuss
what
what
we
really
want
or
not-
and
we
see
and
all
the
main
security
codes
have
currently
in
the
protocol
document,
which
suppose
they
are.
G
We
don't
have
a
proof
yet
that
ongoing
progress,
but
we
think
that
we
respect
those
properties.
So
it's
good
scalability.
We
have
experiments
that
show
we
can
actually
scale
for
fifty
thousand
clients.
It's
gonna
be
interesting
to
see
your
3d
works
feel
like
on
the
on
the
network,
a
synchronicity
except
for
the
group
operations
which
are
like
Karis
tricky
right
now
after
doctor
left,
deliver
service
actually
say
that
they
are,
although
and
we
might
relax
that
condition
for
date,
messages
we
are
actually
interesting
discussions
on
least
risk
results.
G
I
am
sterically,
something
that
we
don't
really
looked
at
it
yet.
So
that's
one
big
point
that
we
need
to
look
at
and
meta
data
protection
is,
is
ongoing.
Work.
The
common
framing,
we'll
discuss
this
a
bit
more
I,
guess
Federation
of
using
in
progress,
and
we
are
running,
is
something
that's
gonna
be
discussed
as
well.
So
the
previous
the
quickie
open
question
that
you
actually
didn't.
G
Look
that
frequency
of
the
key
update
I
think
that's
something
we
left
to
so
is
that
we
would
click
command
and
updates
frequency
depending
on
the
number
of
people
in
the
group
exit
they
are
and
that's
I
think
I
mean
we
need
feel.
We
need
a
real
that
data
to
be
able
to
actually
do
these
kind
of
recommendations.
G
There
is
ongoing
discussion
on
whether
it
should
be
whether
we
should
do
subtrees
entry
camp
or
doing
protecting
the
number
of
device
etc.
So
that's
also
something
that's
being
discussed,
but
nothing
settled
yet
and
requirements
on
the
south
side.
For
when
the
several
elapsed
is
something
right
now,
the
the
in
the
Transpac
boozy
architecture
on
paula,
cole,
the
the
server,
doesn't
know
anything
about
the
groups
membership
it
might
change
depending
on,
if
we
add
the
services
tall
nuts.
So
this
is
the
questions
concurrency
of
group
operations,
I
talked
about
it
metadata
its
retention.
G
There
is
an
interesting
questions.
That's
probably
going
to
be
discussed
by
a
half
file
about
the
fact
that
in
the
key
schedule,
when
you
pick
when
you
pick
the
key
to
decrypt
application
messages,
you
have
the
Sandow
in
the
player,
which
is
not
the
public
eats,
and
so
strong
identifier
I.
Don't
you
find
identifiers?
But
it's
like
is
the
index
of
the
position
of
the
Sandow
in
the
tree,
which
is
matrix
emitted
that
for
some
people
it
might
not
be
acceptable.
G
G
So,
on
the
editorial
point
of
view,
since
nothing,
that's
as
change
in
terms
of
security
artists
that
we
really
want
for
for
the
architectural
draft,
I
mean
we
are
gonna.
The
editors
will
do
a
round
of
actually
trying
to
make
precise
the
text
way
more
precise
in
terms
of
security
guarantees
that
we
want
to
achieve.
The
the
architectural
document
is
quite
a
long
high
level
for
now
and
I.
Think
it's
it's
a
good
idea
that
we
actually
spend
time
to
detail
way
more.
G
Obviously
there
will
be
the
changes
due
to
the
existence
of
the
Federation
document.
We
might
actually
outsource
to
the
Federation
document,
some
constraints
or
not,
or
include
some
the
Federation
constraints
inside
the
architectural
document,
and
we
see
that
data
and
I
think
that's
all
nothing.
Nothing
much
happened.
B
C
All
right,
so
we
are
currently
on
draft.
Oh
four,
that
was
published
shortly
before
the
meeting
due
to
us
and
hiccups
with
deadlines
and
approvals.
So
I'll,
forgive
you.
If
you
haven't
done
a
real,
thorough,
read
through
so
I'll
provide
some
summary
what
we
did
since
since
303
I
think
was
published
right
before
the
interim.
So
it's
been
a
couple
months
since
we've
graphed,
then
we've
got
a
couple
of
open
issues,
I
think
all
of
which
have
pr's,
most
of
which
fpr's
ready
and
so
we'll
kind
of
present.
C
What
the
proposals
we've
got
sketched
out
for
these
various
issues
and
solicit
input
from
the
community.
So
changes
from
oh
three
bunch
of
relatively
small
stuff,
so
I've
been
I'm
very
grateful
for
Ben's
I.
You
know
looking
through
and
thinking
carefully
through
what
the
terminology
should
be
and
making
sure
it
was
all
aligned.
So
that's
all
aligned
now
consistent
between
the
protocol
document
and
the
architecture
document.
So
so
that's
good.
There
were
some
things
about
the
application
key
schedule.
C
You
know
three
that
were
ambiguous,
and
so
we
got
those
cleared
up
and
kind
of
clearly
defined.
So
now
we
have
something
we
can
target
for
implementation,
where
we've
got
some
Interop
already
on.
You
know.
Four
we've
changed
front
now
in
this
version
from
using
EC,
IES
and
kind
of
a
custom
define
in
this
draft
framework
to
using
a
framework
called
HP,
ke,
hybrid
public,
key
encryption
that
Karthik
and
I
have
submitted
to
see.
If
RG
will
be
talking
about
tomorrow
morning,
tomorrow
morning,
anyway,
sometime
this
week,
but
never
see.
C
If
RG
is
meeting
this
week,
we'll
be
presenting
that
draft
proposing
for
adoption
there.
The
idea
is
to
have
kind
of
a
reusable
EC
IES
like
primitive,
that
could
be
used
in
this
protocol
in
ES
and
I
and
TLS
contexts
in
a
couple
of
other
contexts
where
that's
useful.
So
we
went
ahead
and
submitted
that
draft,
and
so
we've
changed
the
definition
in
in
MLS
to
use
that
down
as
well.
We've
got
some
version
negotiation
stuff
in
there,
which
we've
got
just
a
very
shim
thing.
You
know
for
that.
C
We'll
have
some
more
discussion
about
today
added
a
hash,
the
welcome
and
the
add
which
there
was
a
thread
on
this
on
the
mailing
list
that
we
had
some
authentication
vulnerabilities
do
there
being
not
enough
tying
between
the
welcome
message
that
is
sent
to
the
new
joiner
and
the
add
messages
it
announces
into
the
group.
So
adding
I
know
in
in
the
tamarind
model.
I
did,
which
you
know.
I
am
NOT
a
tamarind
expert,
but
I
think
it
was
more
or
less
correct
in
the
Tamra
model.
C
I
did
having
a
hash
with
welcome
info
and
the
add
message
was
enough
to
address
that
vulnerability,
so
hopeful
that
the
academics
in
the
crowd
can
help
it
build
some
assurance
around
this
I
think
it's
at
least
a
step
in
the
right
direction
and
then
well
I'll.
Take
it
to
two
topics:
I'll
talk
about
here,
our
key
separation
with
entry,
chem
that
Conrad
Co
Brooke
proposed
and
some
this
question
about
garbage
collection.
We
addressed
the
interim
and
kind
of
finalized
to
note
for
just.
A
C
Doesn't
reduce
of
dependency?
Okay,
my
hope
is
that
I
was
just
talking
about
this
with
Karthik.
If
we
can
get
this
a
dot
if
CFR
g
to
adopt
it
now-ish
it's
in
much,
it's
a
very
it's
a
pretty
consolidated
piece
of
work,
so
my
hope
is.
We
can
work
it
through
CFR
gene
expeditiously
and
not
cause
any
delay
for
this
way:
yep,
okay,
so
key
separation
within
shriek
em.
C
Conrad
pointed
out
that
you
know
this.
This
means
that
you
now
have
some
relationship
between
the
nodes
in
a
direct
path
which
I
guess
is
kind
of
unfortunate.
It
made
him
a
made,
maybe
academics
that
hadn't
Britta's
nodding
here,
sighs
soon,
yeah
academics
are
unhappy
about
that
and
you
know
we
try
and
keep
our
our
academic
friends
happy
here.
C
F
C
No
so
it's
you
know,
entry
CEM
style.
Actually
the
bottom
box
doesn't
go
anywhere
so
in
in
this
case
the
second
box
would
be
encrypted
to
this
guy
and
the
third
box
be
encrypted
to
that
guy.
The
same
pattern
is
trick.
Em
off
our
fair
are
not
hash
are
morally
related.
No.
H
C
They
are
ok,
I
got
it.
Thank
you.
The
bold
arrows
here,
the
solid
arrows
are
our
kid.
Yes,
I
forget
whether
they're
just
hash
or
whether
they're
it's
some
sort
of
some
chunk
of
each
KDF
yeah.
Okay,
that's
that.
Finally,
this
garbage
collection
topic,
which
we've
talked
about
a
few
times
we
discuss
this
at
the
interim.
You
know,
there's
there's
two
cases
here.
You
know
you
want
to
be
able
to
add
people
in
place
which
is
fairly
straightforward.
C
C
The
idea
is:
we've
got
this
this
tree,
where
we
used
to
have
six
members,
these
three
intermediate
members
got
removed
and
we're
left
with
the
two
on
the
left
and
now
we're
going
to
remove
the
guy,
on
the
right
hand,
side
and
we'd
like
to
clean
up
the
rest
of
this
tree,
so
that
we
only
have
a
little
tree
for
the
two
members
and
so
the
algorithm.
That's
in
the
doc
now,
which
is
what
was
proposed,
what
we
discuss
in
the
interim!
C
You
just
wait
when
you
delete
this
last
member,
you
delete
nodes
from
the
tree
until
you
get
back
to
a
non
blank
leaf,
and
so
you
delete
everything
to
the
right
of
that
leaf
when
you,
when
you,
when
you
delete
the
rightmost
or
delete
a
member,
that's
yeah
the
rightmost
non
blank
member,
that's
the
algorithm
when
we
discussed
this
at
the
interim,
we
kind
of
decided.
Yes,
this
kind
of
looks
good
on
the
face
of
it.
C
If
we
can
convince
each
other
that
this
tree
and
barring
it
still
holds,
remember
our
tree
and
Varian's
the
thing
we
spend
all
our
time
trying
to
keep,
which
is
that
for
every
node
in
the
tree
and
for
every
member
in
the
group
that
member
holds
the
secret
for
the
node.
If
and
only
if
it
is
a
descendant
of
that
node
in
the
tree.
C
And
so
my
one
line
argument
here
is
that
you've,
given
that
definition
of
the
tree
invariance,
if
you
simply
take
a
subset
of
the
nodes
and
members
which
is
what
we're
doing
when
we
throw
away
the
tree
that
invariant
still
holds,
and
so
the
tree
invariant
still
holds,
and
so
it's
okay
to
do
this,
this
garbage
collection
in
this
way.
So,
given
that
kind
of
loose
argument,
we
went
ahead
and
landed
the
P
R
and
you
know,
hopefully
further
deeper
analysis-
will
bear
this
out.
C
C
Yeah,
no,
it's
a
fair
question
because
and
then
you
know
it's
it's
hard
to
say
because
you
know,
groups
in
reality
are
are
sociological
things
yeah,
but
I
mean
so
I.
Think
I
think
the
idea
is,
if
you
pair
this
one
other
thing
we
discussed
is
the
ability
to
move
a
member
from
one
leaf
to
another
and
you
notice,
if
you
combine
remove
with
add
in
place,
you
effectively
get
a
move
on
right
and
so
I
had
sketched
something
out
at
the
inner
I'm
about
doing
that.
As
a
combo
operation,
I
mean.
I
C
B
Is
dkg?
Do
we
have
any
sense
of
how
frequently
this
sort
of
thing
is
going
to
need
to
happen?
We're
talking
about
actually
being
able
to
do
this
kind
of
cleanup
I?
Don't
just
I
think,
maybe
that
we
should
push
off
this
question
about.
If
you
know
efficient
compaction
and
garbage
collection
like
it
seems
like
we
don't
even
have
evidence.
This
is
a
problem
for
a
deployed
scenario,
so
I'm
happy
with
just
having
remove
it
out
in
place
and
not
trying
to
make
some
sort
of
fancy
compound
Archy.
C
Yeah
I
agree,
that's
kind
of
why
we
started
with
what
we
did
just
defining
updating
the
remove
operation
so
that
it
garbage
collects
when
you
do
remove
I.
Think
in
practice
should
be
like
your
goal:
BG
seeing
two
or
three
slots,
maybe
on
a
given
time,
but
yeah.
If
we
find
in
practice
that's
you
know
you
need
to
do
some
compact
compaction
before
you
garbage,
collects
I.
Think
that's
something
we
could
do
plausibly
as
a
follow-up
or
handle
later
and
yeah.
C
C
Alright,
so
this
is
another
issue
we
discussed
briefly
at
the
interim,
so
we
want
to
highlight
here
side
by
side,
the
identifiers
we
have
for
cryptographic,
things
in
TLS
and
in
MLS
version
of
for
the
current
version
right.
So
as
usually
92f
protocols,
we
have
pluggable
primitives
and
we
have
identifier
spaces
that
identify
either
single
primitives
or
combinations
of
those
primitives
and
the
trade
spaces.
C
We
do
have
to
decide
like
to
what
degree
do
we
want
to
have
an
a
single
identifier
that
identifies
a
whole
combination
of
primitives
and
to
what
degree
we
want
to
make
the
primitives
plug-and-play?
So
TLS
has
kind
of
gone
back
and
forth
on
this
earlier
in
TLS,
you
had
cipher
suites,
which
defined
a
single
value
to
find
all
of
the
algorithms
in
use,
and
now
until
s13,
we've
decoupled
that
a
lot
more.
C
So
you
have
separate
identifier,
spaces
for
signature
schemes
and
use
the
D
H
groups
in
use
and
the
cipher
suite
now
just
identify
as
the
aad
cipher
and
the
hash
function.
That's
in
use.
So
that's
the
only
combination.
That's
their
current
version
is
current
version
of
MLS
is
a
little
bit
more
aggregated
than
that.
So
we
have
signature
schemes
broken
out,
so
you
can
use,
say
ECDSA,
together
with
ex
five
two
five
five
one
nine,
but
the
curve,
the
hash
function
and
the
a
EAD
function
are
all
together
in
one
identifier
space.
C
So
the
one
value
defines
all
of
those
things,
and
so
the
question
is
I.
Think
ecker
proposed
that
we
split
this
part
that
we
would
have
better
experience
with
evolvability
of
the
protocol.
If
we
had
these
Brooklyn
separate
things.
So
the
general
question
is,
you
know,
kind
of
what
groupings
we
want
to
have
here.
So
the
first
line
here
is
what
we
have
right
now
in
MLS,
where
we
have
the
D
H
group,
the
AED
and
the
hash,
all
together
in
one
go
to
fire
space,
the
signature
in
a
different
identifiers
space.
C
The
second
line
here
is
what
TLS
has
we
have
the
groups
in
one
space,
a
d-plus,
hash
and
signature
space?
The
third
line
is
one
that
came
to
my
head.
The
thing
that
is
concerning
that
is
potentially
concerning
in
the
MLS
context.
Is
that
we
are
using
the
hash
function
to
derive
D,
H,
key
pairs
or
CEM
key
pairs
for
whatever
we're
doing,
and
now,
whichever
can
we're
using
to
do
tree
Kim?
There
were
Basecamp
right,
so
you,
for
instance,
if
you're
using
84
for
8
or
p5
to
1
in
a
high-security
setting.
C
You
might
not.
You
might
want
to
forbid
the
use
of
shots.
You
five
six
as
for
deriving
key
pair
step,
because
you
end
up
in
some
like
low
entropy
subspace
of
your
big
curve
spacing
you're
not
getting
the
full
benefit
of
that
curve.
So
was
that
you
might
I'm
just
proposing
you
might
want
to
match
these
things
up.
It
seems
it
seems
bad
I
think
the
numbers
don't
match,
I
guess,
but.
C
So
I
mean
I
think
we
can.
We
can
do
any
one
of
these,
like
the
usual
concern
here.
You
here
is,
is
phrases
level
matching
here
like?
Is
it
okay
to
use
P
256
together
with
a
yes,
five
six
which
is
going
to
so
you
you're,
getting
more
strengths
but
weaker
keys
going
into
the
to
the
AED?
You
know,
TLS
has
decided
that
this
is
not
worth
pursuing
like
you
can
you
can
have
that
combination
with
TLS
yeah.
F
I
mean
I,
think
that
can
you
about
your
previous
I
mean
so
like
so
I
mean
it's
worth,
noting
that
that
if
you
actually
had
a
level
matching
three,
then
what
would
you
use?
F
The
cha-cha
write
an
answer:
BP
521,
perhaps
so,
I
don't
think
a
lot
of
magic
as
coherent,
never
has
been
and
I
think
that
I
mean
there
might
be
some
like
there
was
a
crypto
reason
why
you
want
to
have
a
much
larger
hash
with
with
a
with
a
large
group,
but
I,
don't
think
I,
don't
think
entropy
is
the
answer
unless
car
facing
like
correct
me
here,
you
know,
make
me
be
want
white
or
something
my
impression
was
like
the
thesis
to
be
made
to
go
up
to
a
light
if
you
structure
it
properly.
F
What
do
you
mean
by
wide
here
like
univie?
If
for
some
reason,
because
you're
need
to
generate
like
more
than
you
run
the
turn?
If
it's
these
bits
right,
educate,
you
have
concern
about
it?
Is
you
want
so
I
think
it's
probably
okay.
If
we
treated
it
like
it
was
okay
in
TLS
I
think,
certainly
as
far
as
matching
I
mean,
can
you
go
back
to
the
nice
light
now?
F
I
guess
I
know
this
any
sensible
of
a
matching
story
about
like
the
group
of
the
AE
ad,
like
that
just
doesn't
make
in
some.
You
know
I
think
maybe
there's
some
coherent
story
about
the
group
in
the
hash
which
I
defer.
If
you
know
CFR
Vigo,
we
do
like
I
would
defer
to
that.
F
We
just
didn't.
We
just
didn't,
define
ko
points
that
were
like
that,
and
you
can
do
a
five
point.
Nine,
which
hasn't
has
an
implicit
hash.
Please
don't
say
what
it
is
right
so
on
you
know
the
only
reason
this
first
one's
named
this
way
is
because,
like
it
used
to
be,
you
could
mix
and
match
them
right.
So
I
think
that
if
you
do
services.
C
F
Really
suck
I,
just
I'm
just
saying
I
wouldn't
build
to
come
to
her
smorc
explosion
of
things.
I
would
just
be
like
you
know,
who
fixes
user
shot,
do
it
to
sex
yeah,
but
I
guess
but
I
guess
I
suspect
her
ended
up
with
like,
if
you
like,
so
her
for
for
eight
you're
gonna
use
this
all
three
before
you
need
to
shut
through
to
sex,
uh-huh,
I
guess
I
would
just
pick
one
I,
don't
think
we
have
to
like
try
to
like.
C
Right
so
the
the
question
I
think
the
major
question
here
is
like
how
what
whether
people
are
concerned
about
you
know
shorter
hashes
being
used
with
bigger
curves
and,
if
that's
a
concern,
then
how
we
want
to
constrain
it.
C
You
know
you
could
constraint
it
by
just
saying
in
the
definition
of
how
you
use
the
curve
that
it
has
to
be
used
as
a
hash
function,
that
Bruce's
at
least
X
bits
of
output,
and
you
handle
that
of
the
application
there
or
you
could
define
these
combined
group
plus
hash
I
kind
of
nail
it
up
that
way.
It's
like
do.
People
have
opinions
about
whether
this
is
a
problem
and
if
so,
how
to
handle
it.
Martin.
J
Yeah
not
on
Thompson,
oh
that's
good,
it
may
send.
You
may
make
sense
to
have
a
look
at
the
actual
units
that
you're
dealing
with
in
the
protocols,
so
the
the
D
H
component
that
you
use
for
this
is
one
thing
and
that
and
the
ECE
whatever
the
thing
is
that
you're
using
for
encryption
is
another
thing
and
and
the
heydays
another
thing
entirely.
So,
rather
than
saying
are
we
have
these
groups
and
we
have
these
hashes
and
we
have
these
AEA
DS.
J
That
act
on
this,
so
you
have
a
CEM
and
that
can
comprises
of
the
following
group,
and
maybe
you
need
to
hash
to
the
to
the
group.
So
therefore
you
need
to
put
pair
the
hash
up
with
that
and
that
sort
of
speaks
to
the
last
one.
I
think
it
to
some
extent-
and
you
know
the
last
one
is
just
we're
just
talking
about
protection
of
messages
once
we
have
keys
so
think
about
that
way,
more
than
more
than
you
think
actually.
J
F
F
Exactly
so
I
think
that's
the
module
now
like
I
mean
I.
Think
because
HP
key
is
new
like
we
don't
really
have
to
deal
with
this
question
of
library,
people
or
or
like
or
really
people
have
our
oid
iady's
to
their
to
their
community,
but
I,
certainly
don't
I.
Guess
what
when
I
argued
about
this
in
the
interim,
my
complaint
was
I.
Don't
think
you
should
tie
the
bulk
encryption
to
the
key
key
establishment.
C
C
K
Alright,
so
next
we're
gonna
talk
about
the
server
initiated,
removal
and
just
for
context.
That
is
something
that
has
been
requested
by
some
vendors,
so
just
to
understand
what
it
is.
Some
vendors
have
made
it
quite
clear
that
they
would
like
to
use
MLS,
but
with
the
server
knowing
what
the
roster
is.
So
the
server
knows
who's
in
a
group,
and
in
that
scenario
they
wanted
the
server
to
be
able
to
remove
someone
from
a
group.
K
A
F
Because
I
mean
like
a
lot
of
these,
things
are,
like
you
know,
corporate
systems,
and
so
you
know
someone
gets
terminated
and
you
wish
to
another
group,
or
you
know,
as
someone
said,
they
don't
don't
put
their
bill.
There's
like
lots
of
reasons
for
managed
systems
to
one
end
in
security,
but
still
walk
control
of
some
group.
Yeah
yeah.
K
That's
a
very
good
point,
so
the
first
one
just
to
recap
was
inactivity
to
the
extent
that
the
server
can
actually
monitor
the
inactivity,
which
is
not
quite
clear.
Yet
it
would
be
one
reason
and
then
yeah
manage
environments
in
corporate
environments
is
the
other
one
or
maybe
simply
for
consumer
messengers.
If
somebody
closes
their
account
and
therefore
kind
of
do
any
crypto
any
more.
That
needs
to
be
a
way
to
remove
that
person
as
well.
K
So
first
proposal
under
the
codename
of
external
remove
so
the
external
party,
meaning
the
server,
can
send
a
handshake
message
to
the
group,
and
that
is
of
course
not
encrypted
under
the
group
secret,
because
it
is
an
external
party
that
doesn't
know
any
of
the
group
secrets,
but
that
message
would
have
to
be
signed
in
the
same
way
that
hand
check
messages
are
currently
being
signed,
except
it
will
be
signed
by
an
external
identity,
and
so
that
is
precisely
the
problem.
It's
not
quite
clear
what
that
identity
is
how
that
is
being
managed.
K
So
none
of
that
is
currently
linked
to
the
group
state.
We
have.
The
group
state
really
only
contains
the
identities
of
the
members
of
the
group,
but
nothing
else
so
that
raises
the
question:
how
can
a
client
trusts
this
signature
at
the
end
of
the
day
and,
more
importantly,
how
can
all
of
the
clients
trust
it?
Because,
in
order
for
this
to
to
work
in
a
robust
fashion,
all
of
the
clients
would
have
to
come
to
the
same
conclusion
that
this
is
a
trustworthy
signature
and
and
would
remove
the
person
from
the
group.
K
And
now
the
question
is
these
external
identities?
Are
they
going
to
be
managed,
and
that
seems
to
be
completely
out
of
scope
for
the
MLS
protocol?
At
this
point,
the
assumption
is
that
it
might
have
to
be
dynamic,
because
groups
don't
have
any
restriction
on
their
lifetime,
so
you
could
probably
assume
that
the
server
identity
or
whatever
it's
going
to
be
might
change
over
time
might
need
to
be
a
revocation
mechanism.
K
L
A
question
then
k-tec
yeah,
so
I'm
not
entirely
convinced
that
the
clients
all
have
to
agree
on
who
to
trust.
But
perhaps
we
don't.
Like
the
other
options,
I
mean
you
could
say
some
scheme
where
the
external
entities
and
a
new
extra
move
message
to
all
the
group
participants
and
if
any
one
of
them
trusts
that
external
part
participant.
They
then
like
proxy.
That
message
sign
it.
K
C
Yeah
I
think
the
upshot
of
this
one
is
that
if
we
wanted
to
have
this,
then
we
would
basically
need
to
extend
the
what
is
now
the
group
state.
That
is
the
thing
that
everyone
agrees
on
by
the
key
schedule
and
have
additional
things
that
the
group
is
agreed
on
in
there
and
include
information
about
the
authorized
external
parties
there,
which
you
know
is
doable
but
I
agree,
is,
is
probably
not
worth
the
trouble
yeah.
K
I
mean
we
could
certainly
try
and
get
a
list
of
those
external
identities
into
the
group
state.
However,
if
it
is
a
requirement
that
this
list
is
highly
dynamic,
then
it
might
not
be
good
enough
to
just
have
it
in
there
because
it
might
change
in
between.
So
if
the
epic
never
changes
for
whatever
reason,
because
the
group
is
completely
inactive,
but
you
have
a
change
to
the
identity
list,
then
you
do
have
a
problem,
so
I
mean
just
just.
F
So
I'm
clear
on
the
behavior
here,
so
we
have
a
group
of
you
know.
Four
people
and
some
server
sends
a
you
know:
a
evict
individual,
a
and
B&C
trust
the
server
and
D
does
not.
Then
now
you
end
up
with
basically
do
you
know,
D
ignores
the
message
and
B
and
C
take
it,
and
now
you
have
a
partition
right,
but
they,
but
they.
F
Yeah
yeah
right,
I'm,
not
sure
I
mean
hopefully
I'm.
Guessing
fact.
This
is
proposal.
One
meter
for
littles
knows
problem
huh-huh-huh-huh
right,
I,
I
didn't
live
with
that
property.
H
H
K
K
Ok,
let's
look
at
proposal
to
and
then
we
can
debate
some
more.
So
the
idea
here
is
that
the
server
or
the
external
party
sends
a
request
to
the
group
that
somebody
should
be
removed
and
then
probably
the
first
member
to
come
online
and
to
see
that
requests
will
honor
it
by
actually
removing
the
member
in
question,
and
so
that
would
be
done
through
a
normal,
remove
handshake
message,
which
is
not
ambiguous,
because
everybody
in
the
group
is
going
to
follow
up
on
that.
K
The
only
thing
that
is
a
slightly
strange
at
first
is
that
say
if
Bob
was
the
one
to
be
removed
with
a
normal,
remove
message.
The
user
interface
of
the
messaging
system
would
typically
say:
Alice
removed
Bob,
whereas
in
this
case
it
was
requested
by
server.
So
it
would
have
to
be
surfaced
slightly
differently
to
the
user,
to
give
some
more
context
of
what
happened
here
and
that
could
be
achieved
by
somehow,
including
the
the
remove
request
that
came
from
the
server
so
that
other
clients
can
interpret
what
happened
correctly.
F
Unfortunately,
it's
not
just
that
so
many
systems
have
group
systems
have
one
or
two
group
administrators
and
no
one
else
can
do,
can
do
kicking
or
removal,
and
so,
in
those
cases
this
simply
won't
work
at
all.
In
this
case,
is
your:
unless
Appenzell
don't
want
to
do
it,
but
I
mean
I,
often
they're,
like
not
online,
all
the
time
right
and
so
you
get.
Is
you
get
very,
very
slow
removal?
If
any?
So
this
doesn't
seem.
This
seems
like
only
a
very
partial
solution.
What
is
the
concern?
At
which
scenario?
Wouldn't
it
work?
F
This
is
an
area,
a
scenario.
Is
you
have
a
group
of
like
200
people
right
and
there's
two
people
or
min
Affairs,
and
only
minister
is
gonna
fix
people,
and
so,
like
you
know,
so
you
know
like
to
take
go
back
to
my
example.
B
G
B
You
wouldn't
want
to
actually
say
that
wouldn't
want
to
remove
the
picture
of
Alice
being
the
one
who
does
the
removal.
If
this
proposal
goes
forward,
I
mean
yes,
I
agree
with
you
that
you
would
need
to
that.
It
would
be
reasonable
for
it
to
say
bob
was
removed
by
Alice
at
the
request
of
the
external
party,
but
totally
aligning
the
fact
that
Alice
was
the
agent
of
the
action
would
be
a
mistake.
Yeah.
K
B
B
Of
the
protocol,
it
really
does
like
it
is
still
Alice
who's
making
that
call
and
yeah.
We
can
offer
some
additional
cryptographic
justification,
but
we
could
do
that
in
many
other
types
of
removal
contexts
as
well.
If
we
wanted
to
Alice
could
say,
I
found
this
C
RL
online.
That
convinced
me
that
this
person
need
to
be
removed
or
something
I'm,
not.
G
H
It
scott
reil
again
just
to
push
back
on
what
echo
said
a
little
bit
because
who
can
remove
is
only
an
application-level
policy
anyway,
in
as
as
I
understand
it,
anyone
cryptographically
can
remove
anyone
and
the
application
law
enforce
our
well.
Alice
wasn't
actually
allowed
to
do
that,
and
therefore
you
could
have
a
policy
that
said
only
the
admins
can
remove
somebody
unless
they
attach
an
extra
remove,
request
message
and
then
you
should
process
it
well.
F
I
thought
that
maybe
I
forgotten
but
I
thought
that,
like
you,
didn't
need
to
issue
the
request
for
graphical.
You
mean
part
of
the
group
either
of
you
right
so
I
mean
like
I
means
I.
Guess
I
understand
like
the
that
his
entire
story
is
about
like
authorization,
the
authorization
of
the
request
not
about
the
formation,
the
trait.
E
C
Yeah
absolutely
but
I
think
what
catriel
saying
is.
You
know,
you're,
presuming
that
the
removed
policy
that
the
app
enforces
is
these
two
admins
are
allowed
to
remove
and
no
one
else
like
what
he's
saying
is
that
you
could
have
a
policy
that
says
the
people
who
can
remove.
Are
these
two
admins
or
anyone
in
possession
of
a
remove
request?
I.
C
K
Maybe
taking
one
step
back
in
my
mind
at
least
proposal
two
is
basically
saying
all
of
it
should
be
solved
on
the
application
layer.
We
don't
touch
the
protocol,
as
such
people
are
effectively
being
removed
with
a
standard,
remove
handshake
message,
but
the
rest
needs
to
be
done
on
the
application
there,
whereas
proposal
one
would
potentially
mandate
that
we
change
things
in
the
group
state,
meaning
we
effectively
change
how
the
protocol
works.
F
Let's
it's
like,
like
I,
think
I
actually
kind
of
like
to
catch
rails.
These
controls
question
earlier
right.
It's
like
we're
like
all
running
wire
and
like
well.
You
know
that,
wouldn't
it
be
great-
and
you
know,
and
presumably
we're
all
connected
to
wipe
the
wire
Update
channel
for,
like
you
know,
tells
me
to
get
a
new
version
of
wire,
occasionally
right,
and
so
you
know
so
why
are
just
well
perfect?
Will
somebody
mentioned
on
that
channel
that
says,
like
listen,
you
know
like
this
guy's
been
kicked
out
of
the
system
like
take.
F
You
could
certainly
take
it
instantly
because,
really
not
not
like
you,
don't
have
to
find
protocol
messages
for
it,
I
suppose,
but
I
think
that
goes
distinguish
between.
Like
from
a
from
from
a
sort
of
a
tree,
machinery
perspective
this
person
he
pulled
out
of
the
tree
from
a
formal
occasion
perspective.
You
know
station
about
to
tell
you
to
do
it
and
like
we
could
define
that
here.
We
could
not
to
find
that
here
and
that's
kind
of
like
a
separate
question
but
I
think
from
a
tree
perspective.
F
But
I
mean
but
like
but
I
mean
they
so
like.
Okay,
well,
I
get
because.
But
but
you
know
you
have
you
right
so
I
mean
the
I
mean.
Is
it's
complicated
right
but
yeah?
But
you
know
you
think
in
the
case
of
wire,
because
you
can
do
because
you
can't
roll
both
it
with
a
thick
messaging
server
and
the
end
up
a
channel.
It's
like
pretty
straightforward
right.
You
like
say,
like
you
know
the
update
channel.
You
say
like
look
at
this
level
at
this
point
like
pull
them
out
right.
F
I'm,
an
advocate
I,
don't
think
but
I
mean,
but
you
know
you
know,
like
even
a
delegate
is
you
know,
even
even
the
system,
which
is
a
more
open
system
that
has
like
a
but
has
some
central
group
manager,
sells
us
a
property
right
I'm,
just
saying
like
it
that
the
the
thing
is
the
thing
the
application
needs
to
know
is
like
someone
is
authorized
to
tell
me
to
do
this
told
me
to
pull
this
person
out
of
the
group.
K
M
Whoever
initiates
this
removal,
because
if
we
go
with
proposal,
one
that
and
we
actually
let
the
server
do
that,
then
we're
asking
the
surface
to
provide
that
entropy,
which
getting
gets
mixed
into
the
new
group
secret,
and
we
don't
want
that
I
mean
I,
don't
think!
That's
the
right
way
to
go!
I!
Think
it's
better!
If
that
entropy
comes
from
a
user,
so
I
actually
prefer
proposal
to
despite
it
still
rek,
you
know,
probably
being
better
to
have
cryptographic,
identity,
yeah.
K
M
Also
means
that,
even
if
we
have
a
way
to
synchronize
through
some
external
Channel,
and
so
everybody
in
the
group
realizes
okay
now
we
have
to
remove
fob,
there's
still
the
question
of
where
that
new
entropy
comes
from
and
I
think
the
only
source
that
makes
sense
to
me
is
somebody
who's
already
in
the
group
who,
privy
to
the
group
secret,
we
shouldn't
be
taking
entropy
from
outside.
Basically,
so
that's
why
I
like
proposal
too.
D
M
Should
come
from
members
of
the
group
is
because
in
a
PCS
scenario,
so
suppose
you
have
a
you
know
the
adversary's
corrupted
the
server
and
he
corrupted
one
of
them
group
members.
He
knows
the
state
now,
if
you
allow
the
server
to
also
add
the
entropy
during
the
update,
it
means
now.
The
adversary's
second
effectively
knows
both
inputs
to
the
KDF,
and
so
he
knows
what
the
new
state
is.
So
the
Refresh
didn't
do
its
job
of
cleaning
out
the
state
and
kicking
it
verse,
three
off
the
channel.
M
C
Yeah,
so
that's
a
good
point.
I
think
that
argue
is
pretty
strongly
for
for
proposal
to
here.
Having
us
be
done
within
the
group
by
a
group
member.
You
know
a
bit
on
the
author
is
a
question.
Question
III
granted
like
there
are
similar
authorization
problems
here.
It's
a
proposal
one,
but
actually
why
I
got
up
here
is
trying
to
argue
that's.
C
Even
those
authorization
issues
are
equivalent
to
a
previously
unsolved
problem
like,
namely,
if
you,
if
you
have
any
non-trivial
authorization
policy
on
remove,
you
know
any
policy
other
than
anyone
can
remove.
Then
there's
if
you
you're,
assuming
that
everyone
is
synchronized
on
that
policy,
or
else
you
have
this
fragmentation
risk
so
adding
one
more
bit
to
that
policy.
One
more
authorized
key
to
that
policy
doesn't
seem
like
something
super
tragic
in
addition
to
what
you
already
had
to
be
synchronized
on.
C
So
if
that
seems
like
a
tractable
problem
is,
it
seems
like
this
is
kind
of
the
protocol
modality.
I.
Think
that
raises
kind
of
the
raises
the
question
of
what
the
protocol
impact
here
is.
Do
we
need
to
define
the
remove
requests?
Dude?
We
need
to
define
what
this
capability
looks
like.
We
need
to
define
a
slot,
an
extension
point
where
it
could
go
so
my.
K
Assumption
so
far
was
that
the
remove
request
doesn't
mandate
any
specific
changes
to
the
protocol.
I
mean
we
might
still
want
to
write
it
up
as
a
guideline,
basically
of
how
things
could
be
done,
but
it
fundamentally
remains
an
application
layer
solution
and
since
we
don't
standardize,
those
I
saw
it
as
outside
of
the
scope.
But
okay.
C
C
D
N
Hale
I
completely
agree
with
observation
about
new
entropy,
but
I
want
to
say
one
comment
on
the
proposal
too.
I
think
we
changed
slides
there,
but
if
we
go
back
so
one
comment
about
the
proposal.
Two
is
that
the
server
cannot
actually
enforce
a
removal
of
any
group
member,
so
words
and
proposal
1.
They
can
that's.
N
K
That
is
also
true
for
proposal
1.
To
some
extent,
people
could
do
it
individually,
leading
immediately
to
partition,
obviously,
which
is
even
worse.
So
that's
a
very,
very
strange
threat
model
haven't
contemplated
yet
work.
Basically,
clients
do
whatever
they
want
and
they
don't
follow.
What
the
server
says
for
these
things,
so
I
see
that's
being
a
problem
in
both
proposals.
This
is
dkg.
K
K
What
is
connected
to
that
a
bit
is
that
my
proposal
number
two.
It
appears
to
not
be
in
real
time
because
it's
a
request,
that's
being
sent
out,
and
nobody
knows
really
when
that
is
going
to
be
enforced,
but
that
would
have
to
be
a
rule
on
the
application
layer,
essentially
that
you
don't
do
anything
before
you
haven't
honored
the
remove
request,
but
MLS
is
fundamentally
asynchronous.
There
is
no
real-time
element
in
it
by
design,
so
I,
don't
think
this
makes
much
of
a
difference.
B
K
K
L
K
It's
a
good
question,
I
mean
so
far.
We've
never
really
looked
into
how
manage
groups
with
different.
You
know:
policy
levels,
clearance
levels,
whatever
look
like,
because
simply
on
the
cryptographic
level,
everything
is
egalitarian,
as
catriel
said
earlier.
So
all
of
that
is
something
that
again
happens
at
the
application
there
yeah.
So
we
don't
have
a
precise
idea
about
that.
The
question
is
whether
we
need
to.
F
So
I
think
this
argument
about
the
forward
the
author,
the
forwarding
like
really
completes
authorization
with
PCs.
F
Et
I
understand
like
if
surfer
dinner
sheets
this
that
guarantees
don't
look
as
good,
but
people
are
gonna
key
update
and
then
they
guarantees
will
look
okay
again
and
so,
like
gate
wing,
the
deletion
procedure
on
you
know
some
group
member,
reflecting
it
just
like,
does
not
like
feel
like,
like
I'm,
like
a
non
brittle
protocols
on
much
rather
have
a
situation
where
everybody
immediate
he's
actually
on
a
deletion
and
then
there's
some
other
separate
operation,
which
is
job
it
is
to
like
fly
pcs.
The
family
should
just
to
fini
where
to
bring
the
system.
K
F
Need
partly
an
aesthetic
position,
it
just
feels
like
you're
like
taking
new
protocol
functions,
including
them
together
in
a
really
odd
way,
and
especially
the
fact
that,
like
I
mean
I
mean
like
the
that
in
in
when
Alice
forwards
it.
That
is
like
no
meaningful
semantics
about,
like
the
is
like
novena
semantics
kind
of
authorization.
I
K
L
Been
connect,
I
guess,
I'm
still
sort
of
confused
how
this
the
server
sends
a
message
and
everybody
acts
on
immediately.
It
would
work
because
I
mean
we
do
have
sort
of
a
synchronous
message,
delivery
and
doesn't
there
need
to
be
something
to
enforce
like
that
happens
in
the
same
a
POC?
Doesn't
the
external
thing
need
to
know
something
I.
K
H
C
Slightly
more
directly
like
if
the
the
users
in
the
group
chose
to
have
were
non-compliant
enough,
that
they
all
decided
to
boycott
not
either
not
do
the
remove
or
not
process
the
server's
remove
they
could
just
as
well
do
the
remove
and
back-channel
all
the
messages
in
the
group
to
the
guy
that
you
just
got
removed.
So
I
think
that
there's
an
argument
like
if,
if
the
users
in
the
group
are
sufficiently
bad,
then
there's
nothing,
you
can
do
to
stop
them
from
keeping
the
guy
in
the
group
virtually
even
yeah.
K
So
when
I
think
what
what
sticks
here
is
the
argument
of
synchronicity
of
how
that
can
be
achieved.
If
it
is
on
the
application
there
only
and
it
comes
as
an
instruction
from
the
server.
So
how
can
we
agree
that
everybody
removes
the
same
member
at
the
same
a
book
so
that
that
remains
an
engineering
problem,
yet
I
mean.
C
It's
worse
because
I
didn't
even
hear
it,
so
it
sounded
like
this
proposal
to
like
punting
it
entirely
to
the
a
player
can
be
done
without
protocol
changes
just
by
doing
some
authorization
stuff
in
the
a
player,
so
I
think
I'm
inclined
to
do
that
for
now
like
and-
and
maybe
you
know,
make
an
issue
on
the
architecture
graph,
this
is
to
describe
how
this
could
be
done
in
the
overall
framing,
but
leave
leave
the
protocol
draft
as
it
is
for
now.
You
know
that
that
has
the
advantage
that
you
know
nothing
changes.
C
K
M
K
C
Let's
put
it
this
way
like
this
server,
you
know
if
this
is
not
bound
into
it's,
not
that
in
MLS
the
server
can
add
or
remove
it
will,
which
means
that
you
could
have
an
implementation
architecture
where
some
of
the
the
client
is
commanded
in
the
server
just
adds
this
authorization
as
it
transits
the
server
which
seems
like
it
just
fine
architecture
to
me.
So,
like
I,
don't
really.
K
K
C
C
K
K
So
there
is
an
addition
to
the
draft
o4
and
it's
a
fairly
basic
one,
where
we
basically
mimic
what
we
do
with
surface
suits
and
so
clients
can
advertise
what
version
they
support
in
the
user,
init
keys
and
essentially
in
a
very
undemocratic
way.
The
group
initiator
decides
what
version
to
use
for
a
group,
and
then
everybody
sticks
to
that,
and
so,
whenever
a
user
in
a
key
is
retrieved
by
the
group
initiator
and
somebody
is
invited
in
the
Welcome
message,
the
initiator
indicated,
which
version
is
being
used
and
of
course
the
downside
from
that.
K
K
The
major
one
is
should
be
possibly
to
ever
upgrade
an
existing
group
to
a
newer
version
and
if
that's
a
no
than
the
discussion
ends
there,
of
course,
if
it's
a
yes,
then
the
question
is
how
and
should
that
happen
on
the
application
there.
Should
there
be
something
in
the
protocol
that
facilitates
that,
and
also
what
are
the
security
properties
when
you
do
that
which
is,
of
course
very
hard
to
answer,
because
we're
working
on
version
1
way
of
knowing,
if
there's
an
I
ever
gonna,
be
version
2,
and
what
it's
going
to
look
like.
I
I
Does
yes
and
then
the
other
question
I
have
is,
do
you
want,
in
addition
to
versions,
also
have
protocol
extensions
or
not
necessarily,
you
know
all
or
nothing,
but
you
know
we
support.
Also
this
additional
feature
which
may
be
you
know
either
you
know
up,
you
know,
comprehension,
optional
or
comprehension
mandatory,
possibly
having
both
like.
I
A
Feeling,
with
no
hat
on
though
I'm
sitting
up
here
is
that
it
should
be
possible
to
upgrade
at
this
vision
of,
like
a
long-term
group.
That's
for
a
large
corporation
and
and
like
new
version,
two
comes
out
and
you're
gonna
you're
gonna
send
out
a
new
message
to
everybody.
You're
gonna
make
everybody
in
that
company
like
they're
gonna.
Do
what
well.
C
M
G
C
F
Let
me
try
a
simpler
problem,
let
us
say
you're
perfectly
good
group
and
then
some
really
fast
new,
like
aad
algorithm,
comes
out
and
we'd
like
to
upgrade
to
that.
That
doesn't
require
changing
the
group
at
all
so
like
like.
Can
we
do
that?
We
could
do
that
yet
I
think
that,
because
I
think
like
even
that,
it's
like
some
sort
of
like
two
general
rules
problem.
Look
like
figuring
out
that
everybody
like
speaks.
You
know,
everybody
speaks.
F
You
know,
cha-cha
thirty,
so
like
I
would
suggest
someone
try
to
work
that
problem
first
and
then
like.
If
you
were
ever
worth
that
problem
successfully,
then
we
can
like
work.
The
problem
of
like
upgrading
the
group.
K
F
F
Means
like
great
okay,
so
fine,
if
you
own
it
that
way.
Okay,
like
we
I,
decide
I,
want
us.
I,
just
add
a
mood
I,
just
added
emojis
and
I'd,
like
everyone,
even
to
like
send
emojis,
but
I
want
to
send
a
movie
but
I
mode.
You
look
bad
like
when
I
send
a
people,
no
emojis,
so
I
need
to
know
everything.
The
group
supports
emojis
so
like
doing
head
us.
All
of
that
I
mean
I.
Think
we
may,
because
all
the
things
ordered
but
I'm.
F
Just
saying
like,
like
you
know,
that's
like
a
much
easier
problem
so,
like
maybe
something
write
that
down
and
then
we
can
Korean
like
how
you
upgrade
from
like
you
know,
or
you
know,
from
like
ASCII
text
to
like
mine
or
something.
F
H
F
Mean
maybe
but
I
mean
I
mean,
so
if
you
feel
in
context
is
like,
we
have
clients,
that's
true
for
your
Pokemon
stack
apps.
That's
not
true,
because
you
don't
know
people
if
update
or
not
so
yeah
so
like
even
then
is
a
little
is
like
non-trivial,
but
in
open
systems
is
like
much
less
trivial.
F
F
I
guess
I
guess,
but
maybe
not
but
I
guess.
My
point
is
like
if
you
can't
describe
how
you
solve
that
problem.
In
this
context,
you
can't
describe
figure
so
the
person
update
problem
this
context,
so
maybe
you're
gonna
write
down.
My
halves
are
all
under
Center
control
and
I
make
sure
they're
all
the
same
but
like
like
it
like
that,
but
write
that
down
them
because,
like
if
you're,
not
if
you're
not
going
to
tell
me
how
to
solve
that
problem,
then
you
can
tell
me
there's
all
this
one.
B
This
is
dkg,
so
cat
rola,
like
yes,
there
certainly
are
deployments
where
it
seems
possible.
I'm,
sorry,
my
back
is
to
you
just
because
of
where
the
microphone
is
not
I,
don't
mean
to
yeah.
I
could
just
talk
to
you
in
my
back.
There
are
situations
where
you
can
do
that
solution,
but
if
what
we're
saying
is
MLS
will
only
work
for
long
live
groups
in
scenarios
where
you
can
unilaterally
have
a
flag
day,
then
that
means
to
be
written
into
the
architectural
draft,
and
it's
currently
not.
B
Because
I'm
gonna
hear
you
that,
like
you,
don't
want
to
deal
with
the
open
world
problem
because
it's
really
hard
and
it's
what
we
struggle
hit
with
here
at
the
IETF
right.
If
you're
John
the
Senators
here
at
the
ITF,
then
either
we
need
to
say
by
the
way
you
need
to
be
sure
that
you
have
a
way
to
upgrade
all
your
clients
synchronously
or
we
need
to
say
that
we
have
some
idea
about
how
we're
gonna
do
an
upgrade
path,
or
we
can
say
your
your
conversation
is
good.
B
C
No
I
I
think
I
was
asking
an
even
worse
and
simple
question
than
that.
Like
I
was
going
back
to
the
not
upgrading
a
group,
that's
starting
a
group
at
all
right
in
TLS,
I,
think
in
quick
I'm
looking
at
Thompson,
because
I
think
quickest
thought
about
this
in
some
detail
is
question
of
version.
What
stays
constant
among
versions?
C
So
there's
this
question
of
like
what
stays
constant
across
versions
like
in
in
TLS
we've
like
tried
to
keep
compat
in
the
client
hello
right,
so
that
these
server
knows
what
versions
of
clients,
of
course,
and
could
do
proper
version
negotiation.
That
way,
so
one
could
imagine
writing
some
similar
invariants
here
and,
and
you
know
what
are
the
considerations
we
want
to
take
into
account
here.
Thomson.
Would
you
like
to
like
provide
some
background
from
the
TLS
quick
point
of
view.
J
And
so
everyone
who
understands
any
any
version
of
TLS
can
say
well
the
table
until
I
said
Clym.
Hello
is
always
this
shape
and
therefore
I
can
I
can
rely
on
that
fact.
Here.
That's
sort
of
a
second
order
protocol
consideration,
though
I
think
what
I
think
you
need
to
concentrate
on
is
what
what
are
the
states
that
you're
looking
at?
What
are
the?
J
What
information
exists
in
state,
1
and
information
exists
in
state
2
and
what
needs
to
be
carry
across
from
from
one
to
the
other
and
what
needs
to
be
changed
in
in
the
two
different
ones?
And
you
could
imagine
a
world
where
you
start
a
new
group,
because
you
wanted
to
change
the
color
of
the
pixels
that
were
rendered
right,
and
maybe
you
run
two
groups
in
parallel.
That's
at
that
point
and
they
have
some
constraints
on
how
group
membership
to
synchronize
will
have
you
I,
don't
really
know.
But
there's
there's.
J
D
K
D
K
E
K
J
The
is
the
way
this
works.
The
first
person
who
went
to
the
room
determines
the
version.
Is
it's
some
sort
of
negotiation
process?
What,
at
what
point
does
the
final
version
which
I
mentioned?
Is
this
thing
on
the
on
the
right
hand,
side?
What
version
point
is
that
committed
to,
because
you
can
imagine
a
scenario
where
one
person
joins
and
that
determines
the
version
and
then
basically
the
whatever
version
the
server
or
that
person
decides
right
so.
K
B
J
Yeah
Jonathan
Lennox
pointed
out
that
you
can
start
a
whole
new
group.
The
question
there
is
whether
there's
anything
that
this
group
needs
to
do
to
vote,
to
ensure
that
starting
a
whole
new
group
remains
secure
in
and
retains
all
the
properties
that
were
interested
in
retain
going
across
that
transition.
Those.
K
O
K
K
K
A
So
that's
all
that
we
had
scheduled
for
today.
Actually
it's
a
little
early,
but
that's
okay.
We
got
another
hour
and
a
half
on
Thursday
unless
there's
something
else
that
we
want
to
add
well,
I
could
like
revert
my
agenda.
A
C
M
C
C
We
have
this
group
state
object
that
gets
fed
into
the
key
schedule
and
then
used
to
confirm
that
agreement
right
now
that
group
state
object
includes
the
roster,
the
list
of
members
in
the
group
and
their
signature
keys
and
the
tree,
which
has
all
of
the
d-h
public
keys
involved
in
this
now.
Each
of
those
the
size
of
each
of
those
is
linear
in
the
size
of
the
group.
C
So
the
group
state
object
is
very
really
quite
large
when
you
have
a
large
group
and
that
the
upshot
of
that
is
that
whenever
you
do
a
draw
a
secret
operation,
which
is
the
core
operation
in
the
key
schedule,
you
need
to
now
hash
this
linear
size
thing,
which
is
a
lot
of
computation
to
do
so
that
that
has
made
some
people
have
friendly
faces
on
the
list.
We
had
some
discussion
about
this
outlined
a
couple
of
objectives
you
could
envision
here.
One
is
kind
of
trying
to
simplify
things
in
general.
C
You
could
try
and
have
a
smaller
coefficient
on
the
linear
size
amount
of
data.
You
could
come
by
pre
hash.
Some
things
make
them
smaller,
but
I
think
where
we,
where
is
probably
more
useful
to
go
here,
is
to
try
and
reduce
the
amount
of
hashing.
You
need
to
do
for
the
derived
secret
operation
this
and
get
it
down
to
a
more
log
like
things,
that's
more
more
parallel
to
the
amounts
of
operation
that
we're
used
to
in
things
like
updates
and
removes
I
am
proposing
that
we
not
take
this.
C
The
stronger
form
of
sub
linearity
here,
trying
to
enable
two
folks
to
get
along
with
a
sub
linear
amount
of
state
I.
Think
we're
still
going
to
the
proposal
here,
Institute's
that
each
member
will
still
be
required
to
keep
around
the
whole
tree
and
the
whole
roster,
but
they
won't
have
to
hash
all
of
it
every
time
they
do.
They
have
to
the
key
schedule.
They'll
have
to
hash
some
summary
of
it.
That
will
have
log
size.
C
Does
anyone
feel
real
strongly
that
we
should
be
aiming
to
allow
endpoints
to
get
away
with
a
log
size
state
and
see
Geralt
shaking
his
head?
Okay,
so
no
one's
leaping
to
the
mic
to
to
say
that
I
agree.
That's
it's
a
desirable
thing,
but
it
requires
a
lot
of
extra
information.
The
hikmah
so
I
got
a
summary
and
I.
B
C
So
I've
got
a
PRF
right
now,
which
sketches
out
as
a
solution.
Here
it
follows
the
the
Pellman
hash
approach
that
I'd
outlined
on
the
mailing
list
in
the
in
the
PR.
It's
called
a
tree
hash,
which
is
somewhat
less
colorful,
but
also
less
likely
to
run
into
trademark
issues.
C
Okay
and
well,
the
approach
here
is,
is
kind
of
Merkle
tree
like,
but
with
an
extra
input
in
the
intermediate
notes,
so
you
can
align
it
to
the
tree
structure
right
so
with
the
leaf
nodes,
we've
collapsed.
The
collapse,
the
roster
into
this
struct,
so
the
leaf
node
info
here
holds
both
the
leaf
public
key
as
well
as
the
credential
for
the
member
holding
that
leaf.
So
you
gather
all
that
input
together
and
put
it
in
to
the
the
leaf
hash
in
this
overall
hash
structure.
C
It's
optional,
obviously,
because
leaves
can
be
blank
if
they're
not
occupied
by
a
member.
So
that's
how
leaves
leaves
get
hashed
and
then,
when
you
have
an
intermediate
node,
you
have
its
left
and
right
children,
you
know
represented
by
their
hashes
and
you
then
feed
in
the
public
key
at
that
node
in
hash
form
as
well.
C
There's
an
error
in
the
PR,
because
that
should
be
optional,
because
you
can
also
have
option
blank
intermediate
nodes
just
have
to
figure
out
how
to
do
that
easily
and
TLS
syntax.
But
basically
you
do
this
in
code
and
hash
and
code
and
hash
dance
up
the
tree,
and
you
end
up
with
a
root
hash,
which
is
a
summary
of
the
whole
tree.
C
It's
a
commitment
of
the
whole
tree,
just
as
a
numerical
tree,
so
you're
committed
to
all
of
the
public
keys
in
the
tree,
as
well
as
the
credentials
of
the
leaves
kind
of
by
the
transitive
property
of
hashing
and
the
upshot.
What
that
lets
you
do
in
protocol
terms
is
that,
instead
of
having
the
group
state,
contain
the
roster
and
the
tree
and
have
this
big
linearize
thing
you
can
just
have
the
tree
hash,
which
is
a
single
hash
value,
and
so
you
have
a
constant
size.
C
Group
state
object
that
gets
fed
into
the
key
schedule,
and
it's
and
it's
all
much
faster
you.
You
do
have
to
keep
this
thing
up-to-date
as
you
change
the
group,
but
the
upshot
of
that
is
because
we've
aligned
the
the
hashing
to
the
tree
structure.
You
just
have
to
do
a
lot.
You
have
to
do
the
same
number
of
hashes
as
the
nodes
you
change
of
the
tree,
so
typically
log
worst-case
linear.
C
So
that's
the
proposal
on
when
it's
a
briefly
visit.
You
know
nobody
was
calling
for
a
ver
trying
gets
the
log
state,
but
if
you
were,
if
you
were
inclined
to
go
that
way,
here's
why
you
might
not,
and
the
reason
for
that
is
like
if
you're
going
to
try
and
a
lot
of
people
get
by
with
only
log
state,
then
you
have
to
provide
them
the
parts
of
the
tree
that
they're
not
seeing.
C
So
you
have
to
provide
the
hashes
of
the
the
alternate
children,
and
so
you
end
up
multiplying
the
size
of
your
handshake
messages
by
two
or
three
times,
which
seems
like
kind
of
a
lot
of
bloat
in
order
to
get
the
smaller
state
for
the
last
line
here
like
there
was
some
discussion
of
extension
a
little
while
ago.
Maybe
this
is
something
if
people
were
really
keen
on
this.
That
could
be
added
as
an
extension
point
in
the
in
the
handshake
messages.
So
you
could
say:
here's
your
public
keys.
C
You
need
to
update
the
tree
and,
as
an
extension
here
is
the
hash
values
you
need
to
update
the
tree.
Hash
could
be
there,
but
it
doesn't
sound
like
there's
a
whole
lot
of
energy
and
interest
in
the
room.
C
R
Gothic
by
going
from
India,
so
there
is
value
in
having
the
hash
of
the
tree
in
many
situations,
but
also
value
in
having
the
some
representative
of
the
transcript
of
all
the
operations
that
have
happened
so
far
and
they're
kind
of
related,
but
somewhat
different
ways
of
looking
at
it.
So
do
we
already
have
a
notion
of
the
transcript
and
where
is
that
getting
fair
and
well,
it's
getting
hashed
yeah.
C
That's
perhaps
a
good
discussion
have
right
now
and
in
parallel
with
this
I
think
the
current
PR.
Well
so
in
O
War,
as
in
the
previous
versions,
there
is
a
transcript
there
in
addition
to
the
giant
stuff,
I
think
in
the
PR.
It
just
takes
the
gigantic
stuff
and
collapses
that
down
to
a
tree
hash.
So
you
end
up
with
a
transcript
hash
and
a
tree
hash
and
the
transcript.
C
R
So
just
kind
of
abstractly,
if
it
were
the
case,
it
probably
is
that
if
you
know
the
initial
tree-
and
you
know
the
transcript,
if
you're
given
initially
maybe
on
the
transcript
and
deterministically,
you
should
be
agreeing
also
on
the
current
tree.
So
this
does
seem
to
be
somewhat
redundant,
perhaps
in
a
good
way,
perhaps
not
necessarily
where
we
have
these
two
representatives
of
essentially
the
same
state
where
the
transcript
actually
has
strictly
more
information.
It's
a
great
you
are
going
on.
Well,
you.
C
C
C
Well,
you
you
get.
You
get
information
from
the
transcript
in
purport
to
the
number
of
handshake
messages.
You've
seen
right,
so
you
can
verify
a
chunk
of
handshake
messages,
but
the
hash
itself
only
authenticates
messages
that
you
have.
So
if
you
don't
have,
if
you
come
into
a
group-
and
you
don't
have
the
history,
it
doesn't
give
you
anything
so.
O
C
M
R
Well,
Costigan
in
RIA,
so
from
the
transcript
hash.
The
thing
is
said
there
could
be
multiple
transcripts
that
lead
to
the
same
state.
It
was
potentially
possible
and
considering
that
one
path
might
lead
through
a
malicious
node
who
has
done
something
and
one
other
path
may
lead
through,
perhaps
only
non
malicious
nodes.
In
the
analysis,
it
actually
becomes
important
how
we
got
here
not
just
where
we
got
because
of
what
could
have
been
influenced
and
stuff.
R
So
for
the
analysis,
when
you
do
the
security
analysis,
you
certainly
I
think
would
prefer
to
have
more
information,
which
is
what
is
there
in
the
transcript.
So
one
way
of
dealing
with
is
to
say
that
the
transcript
house
should
contain
I
mean
every
the
way
you
update
a
transcript
hash.
Is
you
take
the
the
current
rehash
and
then
you
add
the
new
operation?
R
C
I
think
that's
maybe
one
step
too
far.
One
step
too
fancy
yeah
I,
don't
think,
there's
a
whole
lot
of
benefit
to
having
one
hash
to
set
up.
In
this
case
you
know
a
transcript
that
receives
us,
the
transcript
messages
and
the
tree
hash,
which
is
just
the
tree
and
those
two
get
combined
in
the
key
schedule,
but
yeah
I'm
happy
to
keep
the
transcript
around.
If
you
think
it
has
some
value,
it's
not
it's
not
expensive.
Really.
The
protocol
so
ok
sounds
like
folks
are
ok
with
this
tree
hashing
scheme.