►
From YouTube: IETF105-MLS-20190726-1000
Description
MLS meeting session at IETF105
2019/07/26 1000
https://datatracker.ietf.org/meeting/105/proceedings/
A
A
A
Yeah
come
by,
but
the
note
well,
which
brings
us
to
the
next
thing:
they
don't
well
it's
Friday
morning.
You
should
have
seen
this
already
a
bunch
of
times,
but
basically,
if
you're
here,
you
and
your
here
to
participate,
you're
gonna
follow
the
acting
process
and
rules.
There
are
stuff
about
IPR.
If
you
know
things
about
something
like
and
you're
here,
you're
supposed
to
disclose
them,
you
will
be
recorded,
please
be
nice
and
all
that
good
stuff.
A
If
you
want
some
more
information,
there's
a
bunch
of
BCPs
up
there
and
a
bunch
of
links,
you
can
read
them.
Sorry,
I'm,
Sean
Turner!
This
is
Mikkel
oven
where
the
chairs
requests
minute
takers,
I,
think
I
know
like
almost
everyone
in
this
room,
so
hopefully
some
of
the
volunteer
before
I
pick
them
going.
What's
going
twice,
anybody
anybody!
Anybody,
hey
I,
thought
you
were
going
to
the
microphones,
but
that's
gonna
be
awesome.
E
G
A
Jabra
scribe
is
anybody
in
the
gentleman
alright?
Thank
you
very
much.
The
blue
seats
are
going
around
police
line
up
when
you're
at
the
microphone
can
state
your
name.
Basically,
that's
for
the
minute
takers
try
to
speak,
as
you
know,
not
too
quick
of
a
cadence
I
have
the
same
problem.
Some
others
do
it.
Well,
let's
keep
it
professional
at
the
mic.
This
working
group
has
not
suffered
that
problem
forever.
Actually,
so
thank
you
very
much.
Our
agenda
we
cancelled
Thursday.
We
have
a
very
intimate
group
here
on
Friday.
A
Basically,
we
want
to
talk
through
is
administrivia
Berta
has
some
user
authentication
within
groups
that
she
wants
talk
about
and
Richard
I?
Guess
it's
just
Richard
and
Rafael's,
not
here
as
a
bunch
of
oh
and
Benjamin
are
gonna
talk
about
the
protocol
and
they
have
a
lot
of
slides.
So
while
this
looks
a
little
late
and
there's
a
chance
that
we
might
actually
go
the
full
two
hours
based
on
the
number
of
slides
and
then
at
the
end,
we're
going
to
try
to
figure
out
what
we
might
do
at
the
next
interim.
G
H
Okay,
so
I'm
gonna
get
straight
to
the
point
and
give
you
the
motivation
for
all
of
this
afterwards.
This
is
about
getting
user
authentication
within
the
group
right
now,
as
it
stands
in
the
current
spec,
we
have
essentially
that
we
can
trust
the
signature
keys.
If
you
can
trust
the
signature
keys,
you
can
get
authentication
and
what
do
we
do
if
not
is
an
open?
So
this
is
about
okay.
We
need
to
start
considering
that
next
step
to
get
straight
to
the
point.
H
In
case
you
can
get
lost
in
the
motivation
along
the
way,
I'm
essentially
proposing
that
we
need
to
consider
adding
one
more
extra
key
duration
inside
here,
they'll
be
used
for
the
key
authentication.
If
we
get
to
that,
if
we
actually
want
to
allow
us
indication
okay,
so
let's
get
the
motivation
behind
all
this.
So
this
work-
or
this
question-
comes
out
of
a
project
that
I've
been
working
on
with
Benjamin
Dowling
on
the
authentication
of
the
signal
protocol
and
I.
H
Don't
want
into
the
issues
that
we've
done
there
number
of
them,
but
more
of
how
they
do
it
and
the
fixes
we
found,
because
if
we're
going
to
be
proactive
in
MLS
to
not
have
issues,
then
maybe
we
should
consider
those.
So
in
signal
we
use
a
QR
code
or
numeric
comparison,
and
these
are
essentially
computed
over
the
long
term
keys
as
a
short
version,
so
computer
over
the
long
term,
Keith
they're
static,
the
user
can
cross,
compare
them
or
do
your
code
verification
what
this
doesn't.
H
Allow
is
epoch
level
authentication
so
in
terms
of
MLS
or
in
other
protocols
that
are
dealing
with
or
hoping
you
deal
with,
proposed
compromise
security.
This
doesn't
meet
the
requirement.
Essentially,
if
you
compromise
a
user,
you've
lost
everything,
and
this
is
even
more
particular
when
you
allow
things
like
this
user
to
user
authentication.
Now
this
seems
like
it's
on
the
API
level,
but
the
fix
that
we
found
is
that
if
you
had
derived
a
key
actually
in
the
key
exchange
that
can
be
exported,
that's
separate
from
all
other
keys.
H
You
can
get
this
better,
that
you
that
you
can
actually
get
an
epoch
level
authentication,
so
the
users
cross,
compare,
say
QR
codes
at
some
point,
then
we
actually
have
not
only
authentication
for
who
are
talking
into
the
beginning
that
all
the
epochs
previously
now
yes,
I
see
you
accurate
right
hold
on
one
sec,
sir.
Please
now!
If
we
don't
have
this
and
only
have
the
user
level
like
I
the
beginning
to
say
all
right,
we're
only
talking
about
identity
keys,
we
have
a
serve
deniability,
but
in
reality
that
doesn't
give
us
anything
like.
H
I
The
security
property
were
trying
to
achieve
here
and
they
you're
gonna,
get
to
this,
in
which
case
tell
me
to
sit
down,
but
so
in
in
signal
straight
forward,
because
only
two
participants
right,
but
in
a
MOS
when
they're
in
participants,
are
we
trying
to
ensure
that
a
cannot
pretend
to
be
B
to
C
or
merely
try
to
prevent
it.
Sure
that
someone
noted
some
that
attacker
cannot
pretend.
Even
when
I'm
a
group
member
an.
H
Attacker
like
yeah,
so
which
actually
will
get
to
right
at
the
end,
because
there
could
be
both
cases
if
we
consider
it
but
really
I'm
talking
about
if
the
attacker
comes
in
from
outside
the
group.
So
if
we
can
say
here
was
in
a
group,
will
do
cross
comparison
so
how
this
serve
works,
just
a
quick
fix
if
we
were
looking
at
signal.
H
J
H
So
a
big
picture,
well
we're
coming
out
with
with
it
within
the
terms
of
security
modeling.
This
is
first
signal.
If
you
do
not
do
this,
then
essentially
you
get
red
checkmarks
right
across
the
front
of
this
cross
comparison
with,
depending
on
what
you
compromise,
you
compromise
the
device
or
user,
or
if
you
have
an
e
star
on
this
channel,
what
can
be
achieved.
Hence
the
achievable
guarantees
depends
on
what
Keys
you're
pulling
and
when
and
how
you
cross
them
here
now.
H
These
are
not
achievable,
as
I
said,
if
we
don't
have
something
dried
from
the
current
epoch,
if
it's
only
a
general
ecstatic
state
so
in
terms
of
MLS,
that
brings
us
back
to
this
picture
now.
This
again
is
group
level,
so
you'd
be
pulling
a
key
s
within
a
group,
and
you
would
only
cross
compared
with
in
the
group,
if
you
think,
of
a
bunch
of
users
that
might
not
be
realistic
over
all
that
you
always
want
to
cross.
Compare
only
one
group
at
a
time,
so
we
can't
begin
to
go
into
those.
H
Should
we
be
pop
only
or
group
only
motivation
if
we
do
group,
this
kind
again
goes
for
its
API
and
thus
of
our
scope.
But
if
we're
going
to
allow
that
eventually
for
some
applications,
we
need
to
be
allowing
them
to
derive
the
keys
now
at
this
level
within
the
protocol.
That's
the
motivation.
So
if
we
have
for
a
group
that
means
of
driving
for
them
relate
to
the
group
context.
As
I
pointed
out,
here's
a
question
from
the
ekor
was
saying
what
about
if
it's
a
entity
within
the
group?
H
However,
there
is
a
fix
for
this
as
well,
which
actually
came
up
at
the
last
interim.
If
we
allow
rationing
for
signature
keys-
and
there
were
some
motivation
for
that
that
it's
outside
of
this
context,
but
if
we
are
going
to
allow
ratcheting
for
signature
keys,
we
can
get
around
this
issue.
So
basically
our
situation
comes
down
to
a
few
variants
of
what
we
can
choose.
H
We
can
say
outside
the
scope
of
unless
at
all,
in
which
case
we
basically
say
you
have
to
trust
the
signature
key
permanently
as
a
static
signature,
key
which
we're
not
even
doing
for
regular
keys,
or
we
can
say
yes
we're
going
to
ratchet
the
signature.
Kinky
allow
use
authentication
within
that,
and
we
don't
even
have
to
derive
an
authentication
key
separately,
or
we
can
say
maybe
within
the
groups
that
we're
going
to
allow
the
derivation
of
an
authentication
key.
H
K
Hi,
daniel
ganc,
domore
aclu,
so
I
appreciate
that
all
the
thought
that's
gone
into
this
and
I'm
having
a
little
bit
of
trouble
getting
my
head
around
what
the
expected
user
experiences
of
doing
this
kind
of
verification.
So
here
you
can
we
zoom
out
from
the
protocol
details
for
a
second
and
talk
about
what
sort
of
cadence
we
expect
users
to
play
the
QR
code
scanning
game
at
and
and
like
dude.
Do
we
have
any
any
evidence
that
users
are
interested
in
doing
anything
like
that?
Well,.
H
I
mean
you've
got
some
users
are
interested
at
least,
and
we've
seen
that
already
with
a
very
signal
and
the
other
applications
of
it
that
some
of
us
actually
do
like
to
compute
impaired,
QR
codes
or
numeric
impaired,
so
I'm
trying
to
know
who
we're
talking
to
you
right.
So
we
have
some
motivation
at
some
level.
Now
we
could
say
no
we're
going
to
trust
only
the
server
to
verify
these
signature
keys.
H
Okay,
then
we
don't
need
to
involve
the
user
to
this
experience,
if
we're
going
to
say
no,
we
want
to
allow
deniability
and
get
around
this
in
some
other
way
where
this
users
can
cross,
compare
afterward
sure
not
everyone's
going
to
care
about
that.
But
someone
is,
and
if
we
do
that,
can
we
allow
it
so
that
you
maybe
only
have
to
do
it
once
or
when
you
do
do
it.
You
get
your
verification
for
all
previous
communication
that
you
know
that
you've
been
talking
to
the
same
person
the
whole
time.
Yes,
various
ways:
yeah.
I
In
discussing
my
question
as
well,
which
I'm
trying
to
figure
out
what
guidance
we
give
the
user,
so
you
say
like
great
using
unless
outstanding
you
know
what
do
we
tell
them
about
what
you
want
to
do
to
be
safe,
using
it
or
less
if
you're
concerned
about
compromise
I
think
they
think
like?
I
Maybe
this
is
a
separate
question
and
me
and
me
sounds
like
men,
posing,
is
actually
very
straightforward
for
the
protocol.
So
we
can
like
give
a
lot
problems
later,
but
yeah,
but
he
could
be,
will
be
important
if
we
add
just
the
protocol
and
if
we
say
I
mean
if
all
we
do
is
like
that
and
do
like
limitations
like
a
new
generations-
age,
fine.
I
But
if
we
actually
have
to
turn
on
the
protocol
about
ten
occasion,
codes
or
whatever
you
wanna
call
them,
then
that
has
to
come
I
think
with
some
guidance
about
how
you
would
use
that
mechanism.
It's
I
guess
if
you
thought
like
what
you
would
say
like
if
you
know
a
user
of
this
vertical,
how
how
how
it
can
behave.
H
Oh
sure,
yeah
definitely
give
way
of
saying
here's
to
verify
users
if
you
want
to
do
across
comparison
with
QR
codes
and
how
to
do
that
correctly.
That's
what
we
come
been
seeing
out.
A
signal
analysis
is
that
there's
actually
correct
way
to
do
that
in
a
way
that
breaks
basically
everything
so
yeah.
We
can
give
that
we
can
give
that
if
we
want
to
give
that
recommendation,
it
seemed
a
little
bit
outside
the
unless
protocol
scope,
but
actually.
H
Currently,
if
we
do
a
user
to
user
compare,
we
can
say
that
if
you
do
it
once
you
can
verify
for
every
all
previous
epochs.
There
is
some
work
being
discussed
at
the
moment
of
how
you
can
do
it
once
and
then
you
rely
on
an
untrusted
server
to
actually
keep
being
able
to
compare
it
after
you've
done
the
one
user
to
user
comparison,
so
there
may
be
some
possibilities
coming
forward.
Thank
you.
C
Joe
Hall
CDT,
I'm,
gonna
descent
from
the
past
two
comments
and
say:
I'm,
not
as
concerned
about
user
level
issues
here,
like
with
group
conversations
and
signal
right
now
it
was
static.
You
know,
identity,
it's
very,
very
high.
You
know
cabin
the
group
membership
in
a
way
that
using
like
the
equivalent
of
safety
numbers,
you
can
kind
of
bootstrap.
That
kind
of
thing-
and
you
probably
know
way
more
about
this
in
practice
than
I-
do
I.
Think.
C
H
C
C
H
Serve
about
allowing
the
option,
because
if
we
don't
allow
it
now,
then
we're
going
to
run
into
it.
You're
absolutely
right
about
that.
If
I
want
to
say,
if
I'm
going
to
do
group
level,
key
authentication,
key
generation
and
then
cross
compare
that
with
some
user
and
there
we
have
in
shared
groups-
and
that's
might
be
a
lot
comparison
now.
I
couldn't
get
around
that
with
ratcheting
the
signature
key.
So
that's
going
to
be
a
lot
easier
in
many
ways,
but
there's
challenges
there
too.
So.
H
L
It's
Mike
Lee,
yes,
sure
Oh,
circuitry
burns
yeah.
This
is
this
idea
of
taking
the
set
of
groups
in
which
two
devices
or
users
overlap
and
committing
that
one
comparison
sounds
appealing.
That's
probably
a
little
bit
beyond
the
scope
of
what
we're
talking
about
here,
because
an
operation
level
trying
to
understand
that
protocol
impact
here
is
the
proposal
here
basically
to
generate
some
new
stuff
off
of
the
key
schedule
that
would
go
into
this
comparison,
and
maybe
you
could
could
I
may
have
misunderstood
some
time
previously.
H
So
that's
basically
what
I'm
saying
is
if
we
want
to
have
a
group
level
authentication,
so
there's
different,
like
a
preparing,
allow
authentication
for
all
the
groups
you're
in
or
it's
just
I
know
that
who
the
user
is.
Those
are
those
are
different
questions
and
tamenund,
all
that
you
wanna
say
the
group
level
key
or
under
signature
key.
So
this
is
a
choice
issue.
If
we
want
to
allow
the
group
level,
then
all
I'm,
suggesting
is
yeah,
drive
one
more
key
here.
So
we
have.
We
have
a
drive
secret
for
the
handshake,
etc.
L
H
Essentially
that
so
here's
the
options
that
we
were
finding
my
signal
now,
if
you
don't
do
this,
then
the
only
way
to
talk
about
current
epoch
that
we're
in
is
by
using
keys
such
as
the
group
key,
which
means
that
you
will
necessarily
have
to
keep
at
least
two
keys
in
memory
from
previous
epochs.
Okay.
So
now
we're
come
fire
lighting
for
secrecy.
So
if
we're
wanting
to
get
around
that
then
yeah
we
have
to,
we
wanted
to
rev
it
off
in
case
you
keep
it
separate
sure.
H
If
we're
comparing
devices,
we
both
have
to
be
able
to
drive
the
same
authentication
key
unless
you're
dealing
with
signatures,
which
is
good
since
the
ratcheting
signatures
to
cross
compare.
What
we
found
is
that
you
need
to
have
a
essentially
mismatch
between
the
devices.
So
you,
the
two
QR
codes,
cannot
be
the
same.
That's
a
very
important
actually
and
so
the
background
within
the
protocol.
That's
okay!
It's
okay!
If
I
have
scan
your
QR
code
and
it's
simply
computed
that
we
had
the
same
authentication
key
to
the
slides,
oh
yeah
here.
H
So,
for
example,
if
we
have
the
same
authentication
key,
that's
coming
for
the
group,
so
we
both
know
it
and
we
just
have
different
roles.
This
could
be
identities
as
well,
so
long
as
that's
going
into
the
computation
and
there's
a
disconnect
there.
Now
we
can
both
compute
it,
but
what's
coming
out
invisible
to
the
user,
it's
important
that
there
is
a
mismatch
so
for
us
to
be
cross.
Comparing
the
QR
codes.
Okay,.
L
Yeah
I
mean
this
seems
useful
I
mean
I'd,
be
glad
to
to
take
a
look
at
a
PR
for
this
actually
one
more
question.
One
thing
some
of
these
authors
have
been
discussing
is
doing
kind
of
an
exporter
roll
off
the
keychain
so
like
in
TLS,
we
have
there's
an
exporter
secret,
that's
that's
generated
which
is
used
to
develop
other
things
yeah,
something
like
that.
Could.
H
L
E
L
This
is
about
the
protocol
draft,
which
is
probably
why
most
of
you
are
here.
This
is
all
the
interesting
stuff,
so
basically
the
overall
structure
here
we've
got
like
45,
slides
or
something
it's
gonna
be
split
between
the
invention.
We've
got
a
review
of
what's
been
happening
lately
since
the
last
interim
meeting,
and
then
we've
got
a
bunch
of
ideas
which
didn't
you
know
you
know
not
getting
things
done
in
advance.
L
Are
don't
have
PRS
to
go
with
them,
but
we've
tried
to
explain
them
clearly
in
the
slides
hearing
to
get
feedback
so
that
we
can
then
have
some
PRS
in
the
next
few
weeks
and
have
some
discussion
on
the
list
about
in
what
form
we
should
lay
in
these.
So
right
now
we're
just
me
talking
about
kind
of
directions.
Does
that
we've
tried
to
characterize
the
trade-offs
and
protocol
impacts
of
these
various
proposals
to
try
and
get
a
sense
of
the
group
of
whether
the
trade-offs
seem
worthwhile
in
these
in
these
various
cases.
L
So
going
back
through
the
history
of
the
last
couple
versions,
I
think
our
objective
was
to
have
draft.
Oh
six,
as
a
plausible
version
for
analysis
to
actually
knows
our
objectives,
have
a
five
I
think
as
an
analysis
target.
We
discovered
that
we
had
some
bugs
in
it
that
made
it
unimplemented,
and
thus
you
know
difficult
to
analyze.
So
we
branded
we
sponge
draft.
Oh
six,
after
the
interim
that
incorporated
the
the
bug
fixes
and
a
couple
of
ideas
from
that
came
up
at
the
interim.
L
So
there's
some
terminology
changes,
there's
some
bugs
bug
fixes
to
the
key
schedule.
I
think
the
big
thing
we
made
a
big
change
in
draft:
oh
five,
to
introduce
this,
this
common
framing
layer
where
we
have
a
common
encryption
and
signing
there.
That's
used
for
both
handshake
messages
and
application
content
and
in
the
process
of
introducing
that
it
affected
the
transcript
computations
and
we
just
screwed
up
that
translation
and
so
I
think
it's
implementable,
now
I
think
we
may
have
more
than
one
implementation
at
this
point.
L
So
we've
we
fixed
that
in
O
six
and
then
did
this
this
reordering
of
blanking,
an
update
in
remove
that
Karthik
noticed
was
causing
unnecessary
breakage
under
Sri
fragmentation
in
the
tree.
So
that
gets
us
a
little
bit
more
yeah.
We,
the
general
rule
in
MLS,
is
that
the
more
blanks
blank
nodes
you
have
in
the
tree,
the
less
efficient
your
operations
are,
so
we
generally
try
and
keep
the
tree
more
completely
populated
and
a
few
less
blank
so
that
things
stay
more
efficient.
L
This
change
maintains
that
efficiency,
so
draft,
oh
six,
I
think,
is
the
major
analysis
target
now
focus.
You
know
seven
was
doing
optimizations
that
make
the
protocol
work
better,
but
don't
really
affect
the
security
analysis,
so
I
think
we
I
think
that
first
bullet
may
actually
be
wrong.
I
need
to
check
the
PRS,
but
we
have
a
few
more
bug
fixes
here.
L
Well,
an
implementer
noticed
that
we're
hitting,
if
you
encrypt
the
ad
message,
then
the
welcome
message
that's
provided
to
the
new
joiner
doesn't
actually
wouldn't
enable
them
to
decrypt
the
ad
which
they
also
need
to
join
the
group.
So
you
couldn't
actually
add
someone
to
the
group
with
while
encrypting
handshake
messages.
So
again,
yet
another
bug
fix
I
could
define
those
I
was
one
we've
found
in
several
cases
here
that
having
implementers
have
helped
us
find
these
sorts
of
things.
The
the
biggest
thing
we
landed
was
this
tree
based
application.
L
As
you
receive
messages,
you
want
to
delete,
make
sure
you
delete
things
so
that
you
get
forward
secrecy
as
you
move
that
ratchet
for
and
so
joelle
came
up
with
a
very
nice
phrasing
for
how
you
have
the
rules.
You
should
apply
to
to
make
it
the
maximum
forward
secrecy
you
can
in
that.
In
that
framework
we
also
had
a
message
which
is
kind
of
a
summary
yeah.
L
I
think
it
was
yeah,
so
just
to
overview
this,
this
application
secret
tree
stuff
right.
When
you
update
into
a
new
epoch,
you
generate
a
new
application
secret,
which
is
the
thing
you're
going
to
use
for
generating
encryption
keys
for
the
whole
group
and
you're
gonna
KDF
off
of
that
individual
secrets
for
the
members
of
the
group,
which
said
it
the
leaves
of
this
tree,
you
might
notice.
This
is
the
same
tree
structure,
we're
using
for
the
the
ratchet
tree
right
for
encrypting
stuff
to
the
group,
but
we're
I
kind
of
feel
like
that.
L
That
tree
tends
to
move
bottom-up
in
terms
of
generating
secrets
up
the
tree.
This
one
moves
to
top
down
and
we
seed
it
with
an
application
secret,
and
then
we
ktf
down
the
tree.
So
when
we
start
a
new
epoch,
we
populate
the
root
node
of
this
tree
and
that's
all
we
need
to
do.
There's
in
earlier
versions,
you
had
to
do
a
linear
size
number
of
kts
as
soon
as
you
updated
the
epoch,
so
you
could
receive
from
somewhere
you
as
soon
as
you
received
in
order
to
get
forward
secrecy.
L
You
generate
the
other
secrets,
so
I
guess
I
should
have
highlighted
the
the
status
quo
ante,
but
before
you
would
have
had
to
generate
all
of
these
lief
secrets
to
get
forward
secrecy
in
this
context,
whereas
here
you
just
have
to
keep
around
these
dark
outlined
secrets,
so
that's
kind
of
they
and
the
ideas.
Then
you
know,
as
you
know,
if
say,
L
were
to
send
something.
No
next!
L
You
would
you
know
KDF
down
from
this
point
and
keep
around
some
these
other
notes,
so
you
gradually
build
up
to
where
you
have
all
the
leads
populated
if
everyone
sends,
but
you
only
generate
when
someone
sends
a
message
into
the
group,
and
so
you
have
a
you
know,
you
react
a
little
better,
a
little
more
conservatively.
You
don't
do
as
much
work
upfront,
one
or
not-
also
highlight
this.
This
consumption
of
yeah
Benjamin.
B
B
L
L
Sometimes
yeah
things
fall
through
the
cracks.
The
other
thing
I
wanted
to
highlight
here
from
from
Chapter
seven
was
this
consumption
rule
the
rule
here
is
that
a
secret
is
consumed
if
it
is
used
to
decrypt
a
message,
so
in
this
example,
we've
received
a
sec.
The
second
message
encrypted
with
the
second
generation
of
keys
from
E
and
to
tolerate
reordering.
We
want
to
keep
around
than
the
keys
from
the
first
generation
so
that,
if
that
first
generation
message
shows
up,
we
can
decrypt
it,
but
by
these
consumption
rules,
we've
had
to
delete
these.
L
This
key
and
nonce
will
delete
these
as
soon
as
we
have
decrypted
the
message,
because
now
they're
no
longer
needed,
because
we
should
never
get
a
second
generation
message,
and
the
second
rule
here
is
that
if
we
you,
if
I,
consume
the
secret
derived
from
a
secret,
then
we
have
to
consume
that
secret
as
well.
So
basically,
these
this
consumption
rollback
propagates.
L
So
when
we
decrypted
this
second,
this
generation
2
message
here-
we
now
have
to
consume
this
secret,
this
secret,
this
secret
and
so
on
up
the
chain,
and
so
you
can
kind
of
see
how
this
leads
to
forward
secrecy,
because
now
you've
deleted
anything
that
could
possibly
be
used
to
regenerate
the
secret
you
just
used.
So
if
there's,
if
there's
compromise
from
this
point
forward,
then
you
can't
go
back,
you
can't
reconstruct
the
stuff.
You
just
use
yeah
you.
B
Have
a
question
about
that?
My
expectation
is
that
when
you
derive
key
and
then
not
when
you
consume
them,
you
you
will
keep
the
secret
that
generated
them.
So
to
me,
it's
like
the
last
the
last
cross
yeah
you
you!
You
raise
that
secret
as
soon
as
you
derive
KN
and
the
next
secret,
so
that
you
never
have
any
problem
in
case
it's
equal.
So.
L
L
M
Wahby
yeah,
what
question
would
it
make
sense
to
just
define
an
API
that,
for
example,
takes
the
leaf
node
there
and
returns
km
and
a
new
leaf
node
and
deletes
the
input?
And
then
that's
the
only
API
that
is
used
to
operate
on
those
sort
of?
Obviously
that
only
works
for
the
leaf
nodes.
It
doesn't
work
inside
of
the
tree,
but
it
may
be
that
defining
it
in
terms
of
an
API
and
makes
extremely
clear
it.
L
Could
be
yeah
I
mean
just
yeah
that
might
be
in
like,
if
you'd
like,
to
take
a
look
at
how
to
write
that
down
that
I'd
be
interested
to
kind
of
see
that
written
as
I
think
yeah
I've
certainly
thought
into
implementation
terms
of
like
creating
a
secret.
You
know
C++
class
that
tracks
its
dependencies
and
automatically
back
propagates
that
deletion.
You
can
do
some
clever
things
in
implementation,
like
that
I
I'm,
not
totally
sure
that
there's
specification
I
ways
to
do
that,
but
it
might.
L
You
should
talk
and
I
get
this
gonna,
PR,
ok,
I
think
think.
That's
the
main
backward
looking
stuff
in
terms
of
where
we're
going
with
the
spec
I
think
we've
been
trying
to
kind
of
match
spec
versions
to
meet
ups.
You
know
interims
or
IETF,
and
we've
been
doing
interims
roughly
every
you
know
once
in
between
every
pair
of
I'ts.
L
Yes,
so
I
think
we'll
discuss
this
later
in
the
meeting,
but
I
think
roughly
late-september
as
the
target
for
the
next
interim,
we'll
probably
try
to
have
draft
Oh
8
ready
for
that,
based
on
the
proposal
we're
talking
about
in
this
meeting-
and
you
know
anything
else
that
comes
up
as
we
try
and
your
implementation.
My
hope
we've
had
a
little
bit
of
this
I,
think
of
divergence
and
the
implementations
we
still
have.
L
You
know
four
or
five
implementations
going,
it's
seven
most
most
of
which
I
think
are
open
source,
maybe
a
couple
of
closed
source
ones
as
well,
but
I'm,
hoping
that
as
we
get
a
little
more
stability
in
the
API
are
in
the
in
the
spec
over
the
second
half
of
this
year.
We
can
start
to
get
a
little
bit
more
aligned
than
plantations
drafts
are
nine.
It
was
obviously
farther
out
in
the
future
a
little
more
uncertainty.
L
Hopefully
would
you
know,
get
feedback
on
o8
at
the
interim
and
and
do
doooo
a
nine
for
the
IETF
I'm,
hoping
that
bio
nine
will
start
soon
be
making
smaller
and
smaller
changes
and
start
to
stabilize
as
we
get
to
the
IETF
and
to
the
end
of
the
year.
So
this
is
kind
of
my
my
view
of
the
glide
path.
I
feel
like
we're.
L
We
have
a
good
conceptual
framework,
we're
doing
some
optimization
work
now
to
make
the
performance
a
little
better
but
I
think
as
as
we
get
some
security
analysis
results
coming
in
and
as
we
get
some
confidence
in
the
the
usable
performance
of
this,
we
should
be
able
to
start
stabilizing
about
the
end
of
the
years.
That's
kind
of
my
you
know
rough.
A
Prediction
of
the
future,
so
some
of
this
so
some
of
the
reason
why
we
set
up
in
Las
Vegas
to
kind
of
mirror
what
TLS
did
and
have
in
terms
of
implementations
and
the
like.
Are
you
seeing
that
I
know
the
answer
I'm
giving
you
a
softball
question,
so
everyone
else
will
know
the
answer
how
the
implementations
are
coming
along
and
whether
they'll
be
somewhat
aligned
with
draft.
L
So
obviously,
these
specs
that
the
implementations
tend
to
lag
the
specs
by
a
little
while
right.
So
so,
oh
nine
drops
and
say
early
November
it'll
take
a
little
while
for
the
implementations
to
catch
up.
Maybe
we
can
use
the
hackathon
IETF,
whatever
106,
to
catch
people
up
I,
don't
know
if
there
are
implementers
in
the
room
who
want
to
comment
on
this
Benjamin
I
think
you've
got
a
stack
going.
How
close
are
you
to
the
spec
right
now?
B
Efficient
implementation,
typically
the
formal
spec,
the
cons,
I'm,
basically
as
a
to
date,
as
I
can
I.
Think.
The
only
thing
that's
slightly
different
is
the
I:
don't
have
exactly
the
same
application
key
schedule
because
we
learn
delete
so
just
like
a
few
enemy
need
to
do
the
proof
that
it
that
it
meant
send
the
secret
in
violence
know
that
stuff
before
I
can
claim
that
I'm
up
to
date
with
the
draft.
So
there
is
like
you,
we
have
like
multiple
implementations
right.
We
have
the
formal
spec
that
completely
inefficient
idea.
B
L
B
We
have
two
implementations,
one
which
is
I
love
all
using
recursive
data
types
for
three
six.
It's
very
compact,
that's
the
few
hundred
lines
of
code
that
shine
referred
to
and
we
have
multiple
thousand
lines
of
code
that
is
efficient
and
reasons
like
is
an
inci,
and
this
one
is
stalled
away.
I
think,
but
for
Interop
I.
Think
this,
the
formal
spec
which
enforce
the
security
hoof,
which
means
secrecy
environments.
All
these
things
is
quite
close,
I
think.
A
B
L
That
may
be
something
to
discuss
as
a
target
for
the
interim.
Maybe
we
can
get
a
draft
of
eight
out
and
have
been
in
bands
of
the
interim
so
that
people
can
have
some
time
to
implement.
Maybe
do
some
Interop
testing
alongside
that?
That's
a
good
idea,
so
it's
a
try
and
keep
up
a
little
bit
better
yeah
all
right
now,
that's
that's
current
current
spec
status.
Any
any
further
comments
on
that
questions
about.
L
Rafael
described
this
a
lot
in
in
terms
of
bringing
a
new
device
online.
So
when
I
bring
a
new
device
and
log
into
a
new
device,
it
has
to
join
all
of
the
groups
I'm
in
and
if
it's
got
to
do
a
whole
bunch
of
d-h
operations
for
each
of
those
groups
like
this
to
be
very
heavyweight,
especially
if
I've
got
a
lot
of
groups
going
on.
L
The
observation
I'll
start
from
here
is
that
the
secrets
shared
by
the
group
only
need
to
be
updated
if
there's
messaging.
So
if
I've
got
a
group
and
I've
added
15
people
have
removed
another
five
people
on
the
other
side
and
30
people
have
updated
their
keys.
All
of
those
changes
have
no
significance
if
there's
no
messaging,
so
the
the
underlying
approach
here
is
to
take
all
of
the
crypto
math.
L
You
would
need
to
do
to
update
the
key
and
defer
that
until
a
message
needs
to
be
sentenced
to
the
group,
we're
not
doing
that
right
now.
Every
time
you
do
an
operation
every
time
you
add
someone
or
remove
someone
or
update
a
key,
you
have
to
do
all
the
d-h
operations
to
update
the
group
secret.
Even
if
there's
there's
no
messaging
going
on
yeah
ekor.
I
L
I
think
maybe
part
of
this
concept
would
be
kind
of
an
initiative
sub
a
pox
right.
So
if
these
things
don't
only
change
the
tree
and
don't
change
the
group's
secrets,
it's
possible,
you
could
keep
encrypting
the
group
messages
under
the
same
epic
keys.
That
gets
big.
That's
part
of
your
stance.
It
seems
to.
I
L
Absolutely
yeah,
and
so
in
the
ad
case
yeah,
you
may
be
able
to
just
hash
things
forward
as
long
as
you
can
get
the
right
stuff
to
the
new
joiner,
yeah
yeah
so
write.
The
proposal
here
is
to
do
cheap,
stuff
upfront
and
modify
the
tree
right,
modifying
the
trees
chief
you're,
just
emplacing
you're,
storing
public
keys
and
then,
when
you
before,
you
send
a
message
to
the
group
you
encrypt
to
the
tree.
L
You
quips
a
new
entropy
to
update
the
the
group
secrets
and
that's
what
then
you
incur
the
cost
of
all
the
D
H
operations,
so
I.
Think
of
this
kind
of
as
a
rearrangement
of
the
operations
we're
doing
thanks.
It's
nice
that
we
kind
of
got
things.
We
understand
that
have
a
taxonomy
here
we
can
just
rearrange
things.
So
if
you
look
at
the
way
you
know
the
current
operations
are
structured.
L
When
you
update
likewise,
we
reset
the
leaf-
and
you
encrypt
some
fresh
entropy
to
the
group
that
refreshes
the
group
secret.
When
you
remove
it's
kind
of
like
a
mash
up
of
about
an
update,
you,
you
reset
the
the
removed
members
leave
to
blank.
You
kick
them
out
of
the
group
and
you
reset
their
their
direct
path
to
blank.
You
don't
clip
some
fresh
entropy
to
the
group
that
so
that
they
no
longer
know
the
group
secret.
So
really,
the
idea
here
is
to
take
the
expensive
stuff
so
like
hashing.
Is
that
isn't
that
expensive?
L
But
maybe,
but
you
have
these
these
encrypting
fresh
entropy
to
the
group
involved.
You
know
logs
log
size,
th
operations,
those
those
the
expensive
things
if
you,
especially
if
you
have
to
do
them
across
a
whole
bunch
of
groups.
So
the
the
proposal
here
in
kind
of
protocol
syntax
terms
is
to
take
the
add,
update
and
remove
operations
and
chop
off
the
expensive
parts
right
resetting
leaves
and
blanking
paths.
Those
are
just
changing
bits
in
a
data
structure.
L
C
L
Forgot
to
make
the
illustration
here
that
I
made
a
note
for
yeah
there's
a
corollary
to
this,
that
you
need
to
have
a
rule
and
Rafael
gets
units
and
one
sec
if
you're
gonna
split
things
out
this
way,
you
need
to
make
sure
that
this
ratchet
operation
happens
before
you
send
a
message
right,
so
the
ads
and
and
updates
and
removes,
have
been
reflected
in
the
tree,
but
they're
not
reflected
in
the
group
state.
Yet
until
you
do
a
ratchet.
L
L
N
Alright,
so
on
the
update
line,
I
think
what
you
we
never
said
that
so
explicitly,
but
we
also
plant
the
direct
path
when
you
send
a
normal
update
and
then
you
override
it
with
new
values.
So
in
that
sense
the
update
is
equivalent
to
the
and
remove
right
now
it
looks
visually
looks
as
if
it
was
different.
N
L
L
L
It
may
actually
end
up
a
bit
simpler
because
we'll
only
have
the
the
tree
updating
logic
in
one
place
instead
of
spread
across
three
different
operations,
so
could
be
useful
just
to
highlight
the
trade-offs
here.
Add
this
I
mean
as
we
set
out
to
do.
We've
made
the
modifications
to
the
group
happened
in
constant
time
before
you
send
a
message.
So
if
you've
got
a
group
is
not
doing
any
messaging
they're
just
sitting
there,
maintaining
the
group,
you
incur
very
little
costs
to
keep
the
tree
up-to-date.
L
L
The
next
message
is
sent
at
that
point
because
you,
as
Raphael
pointed
out
you
have
to
blank
when
you
update,
you
now
have
a
tree
that
is
only
populated
at
the
so
when
you
send
finally
send
that
ratchet
operation,
it
has
a
linear
number
of
D
H
operations
to
encrypts
to
each
of
those
leaves
and
individually.
So
there's,
there's
kind
of
a
lifecycle
to
the
group.
L
Now
that
you
know
when
you
the
as
it
sits
there
and
is
inactive
the
tree
kind
of
degrades
and
it
becomes
less
populated,
as
updates
happen,
that
blank
out
parts
the
tree
and
then
it
gets
reconstituted
as
people.
Do
you
messaging
and
send
rachet
messages
in
the
that
repopulate
sit?
So
I
mean
this
right.
So
if
people
don't
do
these
ratchet
operations
very,
very
often
they
could
be
quite
expensive
because
the
longer
you
go
between
them,
the
more
expensive
they
are
to
do.
L
L
The
server
initiated,
remove
some
noise
server
initiated
remove
is
very
straightforward
in
this.
You,
you
mark
a
server
as
the
server's
public
he's
authorized
to
sign
and
that
that
server
can
then
send
you
a
remove
message
that
says
blank
out
this
path
and
it's
blanked,
and
it's
realized
when
the
next
member
of
the
group
ratchets
the
group
forward.
So
it's
a
much
cleaner
way
of
thinking
about
these
server
initiated
operations.
I
think
the
major
risk
here.
L
Besides
that,
the
cost
of
doing
the
ratchets
in,
if
we,
if
we
adopt
this,
the
major
risk
I
think
is
there-
is
the
risk
of
this.
This
timing
of
the
ratchet
operations
that
you
really
need
to
have
a
ratchet
happen.
Ratchet
operations
sent
before
any
messaging
is
done
before
anyone
uses
the
group
secrets
to
take
all
the
changes
that
have
been
bunched
and
apply
those
and
and
RIA
an
update
that
the
group
secrets
that
they
reflect
the
current
state
of
the
group.
L
So-
and
this
is
kind
of
the
trade
off
space
I
mean
what
do
people
think
does
it
seem
like
useful.
These
seem
like
worthwhile
trade-offs
seem
like
we
could
stay
away
from
this
I
guess.
I
should
add
to
this.
The
point
echo
made
about.
We
need
to
figure
out
how
this
interacts
with
encrypted
handshake
messages,
but
my
general
impression
this
seems
worthwhile,
but
if
people
are
concerned
about
some
of
the
costs
here,
let
me
discuss.
C
A
little
closer
to
the
mic
jumps,
oh
hello.
So
if
you
have
a
team
that
does
not
message
a
lot
but
needs
to
get
up
to
speak,
really,
quick,
you're
gonna!
It's
a
big
team!
Your
that
first
message
is
gonna,
be
sit
there
staring
at
something
for
a
little
bit,
and
so
it
might
be
either
this
isn't
going
to
be
appropriate
for
those
uses,
or
we
might
want
those
folks
to
be
able
to
I,
don't
to
use
the
word
heartbeat,
but
whatever
I
just
did.
L
That's
a
good
point
like
you.
I
will
point
out
that
what
the
the
balance
here
is
between
how
often
you
ratchet
and
how
often
you
update.
So
if
you
ratchet
seldom
but
update
a
lot,
then
the
updates
will
blank
out
the
tree
and
your
ratchets
will
become
expensive.
If
you
ratchet
every
time
you
update,
then
you
don't.
L
Your
tree
is
not
degrading
so
to
some
degree
we're
like
punting,
a
choice
to
the
application
there
we're
offering
an
additional
complexity,
not
an
additional
knob
to
the
application
there
to
control
the
state
of
the
tree
in
your
kind
of
first
responder
case.
It's
an
interesting
one
so
like,
if
you
imagine
that
you
know
everyone's
been
quiescent
for
a
while,
but
they've
been
sending
updates
because
of
for
PCs
there.
There
is
kind
of
a
warm-up
phase,
as
we
have
with
with
a
new
group.
N
Yeah
I
just
actually
wanted
to
comment
on
exactly
the
same
thing.
So
I
think
you
already
said
said:
it
was
important
just
one
more
thing
for
context
when
I
first
thought
about
it,
I
wanted
to
defer
the
hard
computational
work
and
payload
costs
from
the
device
that
is
being
added
to
an
account
or
group,
but
I
mean
nothing
precludes
this
device
from
paying
the
cost
later
at
this
point
or
another
device
from
the
same
account,
for
example,
that
would
do
that.
If
there
was
enough
time.
H
N
K
This
is
Daniel,
cart,
Gilmore,
I,
guess,
I
have
two
one
one
concern
and
one
question:
the
question
is
just
if
you
could
elaborate
on
the
asterisk
there,
because
I
don't
if
you
mentioned
that
I
didn't
catch
it,
and
my
concern
is
that
it
seems
like
you're
saying
taking
this
approach
or
requiring
this
approach
is
what
permits
this
can
be
sent
by
any
authorized
party
thing,
but
it
permits
server.
Ad
I
mean
if
we
don't
do
this,
there's
no
way
for
servers
to
do
dynamic
like
to
do
server,
initiated
ads
or
nodes.
L
I'm
sorry
I'm
struggling
to
follow
the
changes
yeah.
So
so
did
these
are
constrained
so
the
asterisk
on
the
ad,
that's
the
as
a
server.
You
know,
a
non-member
of
the
group
can
create
an
ad
message
and
to
tell
the
group
to
add
someone
to
the
tree,
but
even
with
this
change
the
server
can
generate.
This
is
actually
the
next
topic.
The
server
can't
generate
the
welcome
message
that
provisions
the
new
joiner
with
the
secrets
for
the
group,
because
the
server
doesn't.
H
L
K
L
Well,
actually,
Tiger
won't
one
quick
response
to
dkg
I
think
just
to
put
some
bounds
on
this
I
think
to
the
degree
that
server
initiated
stuff
is
possible
here,
I
think
the
there's
pretty
good
agreement
across
the
group
that
it
will
be
explicitly
authorized
you'll
have
clear
authorization
for
whose
authentication
of
the
sender
of
these
the
originator
of
these
things,
and
they
will
not.
They
will
have
the
same
authentication
properties
as
a
fork
for
the
joint,
the
added
user,
as
as,
if
they
had
been
added
by
you
know
some
who's
already
in
the
group.
L
So
I
agree
that,
depending
on
all
sorts
of
UI
considerations
won't
have
you
like.
There
is
there's
risks
of
things
going
unnoticed,
but
at
least
at
the
cryptographic
layer.
There's
not
a
between
the
you,
the
device
of
the
member
authentication
in
the
server
initiated
case
and
the
the
member
initiated
case,
but
happy
to
discuss
this
more
yaker.
L
I
I
Let's
say
there
are
other
cases,
but
my
understanding
was
like
going
back
to
them
like
there
is
no
requirements
here
were
about,
like,
as
I
recall,
had
the
property
that
like
say
my
device.
Khalida
story
not
want
to
rejoin.
What
do
I
do
right
and
my
understanding
was
a
server
initiated
was
the
answer
to
that
question
now.
I
Eike
absolute
arose,
deg
points
out
that,
like
that's
like
a
huge
technology,
but
like
it's
important,
understand
what
right
and
meet
something
we
like
said
when
we
say
like
I,
don't
want
that
functionality
right,
but
I
think
as
far
as
understand.
That's,
if
you
don't
have
to
initiate
that's,
we
would
not
this
basically
there's
an
when
I
want
to
want
when
I
want
to
buy
lose
my
device
which
screwed
yeah.
L
I
Think
just
trying
to
think
about
there,
like
there's
a
general
equilibrium,
the
facts
of
this.
My
suspicion
is,
you
know,
environment
that
does
not
have
sort
of
initiated.
Add
what
will
happen.
Is
anybody
anybody
who
operates
a
big
service
or
base
that
we
implement
server-side
key
escrow
for
the
signing
keys.
L
Or
will
initiate
what
will
basically
have
an
API
by
which
the
server
can
request
that
any
device
that's
online,
do
the
add
of
donuts
behind
I,
don't
see
how
that's
actually
materially
different
from
server
and
show
you
that
don't
do
you
know?
Okay,
no!
It's
different
in
protocol
terms,
yeah,
it's
not
different
in
functional
terms,
but.
L
I
I
I
L
I
It
seems
like
obviously
materially
worse,
I,
think
the
question
I'm
interested
in
is:
is
there
any
material
security
difference
between
soar,
initiative,
add
and
server
like
solicited,
add
or
whatever
you
want
to
call
it
right
and
I,
don't
know,
I
haven't
had
time
to
reason
about
it.
So
I
can't
answer
that
question
I.
Think.
L
I
think
there
are
noticeable
difference,
I,
don't
know
if
their
material
material
differences,
but,
for
instance,
in
the
in
the
case
where
it's
in
the
protocol,
it
you
have
the
the
signatures
by
the
third
by
that
the
server
in
the
transcripts
and-
and
you
know
clearly
and
agreed
on
by
the
group-
and
so
there's
seems
like
there's.
There
is
extra
accountability
in
that
approach
that
you
don't
get
in
the
orchestration
approach,
so
it
says
just
just
keeping
track
of
yeah
the
agenda
here
I.
L
H
O
L
Well,
I
well
actually
yeah.
Well,
let's
do
that.
Let
me
make
the
proposal
like
make
the
proposal
FRA,
how
I
think
we
can
do
it
and
then
we
can
discuss
whether
we
want
to
alright.
So
not
hearing
huge
concerns
about
that
about
this,
except
for
the
server
initiated
part.
It
sounds
like
you
know.
We
are
Mille
Joe.
Your
observation
that
we
are
kind
of
opening
up
more
a
little
bit
more
complexity
for
apps
to
have
to
manage,
as
we
write
PRS
here,
we'll
have
to
think
about
how
to
talk
about
that.
Yeah,
yeah,
Rhian,.
M
Wahby
quick
question:
do
you
have
a
sense
for
what
the
range,
so
it
seems
like
the
point
here-
is
different
groups
with
different
use
cases
will
have
sort
of
a
different
optimality
point.
You
give
a
sense
for
what
the
range
of
those
optimality
points
is.
Is
it
sort
of
gigantic,
or
is
it
rather
narrow?
I,
don't
know?
That's
a
very
that's
a
very
open-ended
question,
but
the
point
is
like
if
you
could
imagine
that,
like
if
two
different
groups
have
some
setting
that's
off
by
orders
of
magnitude,
then
intuitively
it
feels
like
having
this.
M
This
tweak
must
have
been
important.
Why
else
would
be
this
setting
be
off
by
orders
of
magnitude?
But
if
the
optimality
point
is
relatively
flat,
then
maybe
it's
okay
to
pick
one
number
and
say
yeah:
it's
not
perfect
for
everyone,
but
good
enough,
and
then
at
least
you
get
rid
of
the
possibility
of
miss
configuring
it.
So
it
might
be
useful
in
terms
of
making
a
decision
just
to
understand
how
big
that
ranges
and
how
steep
the
trade-off
Curtis
yeah.
L
Yeah
I
think
there's
enough
variability
in
the
considerations
here,
as
you
heard,
there's
a
couple
of
different
motivations
for
for
how
you
arrange
this.
It
might
not
be
quite
a
linear
scale,
but
yeah
they're
happy
to
have
some
considerations
around
I.
Think
yeah
inevitably
will
have
some
guidance
text
around
yeah.
Well,
we'll
have
a
hard
boundary
and
say
you.
L
You
must
send
this
ratchet
message
before
you
before
you
message:
there's
any
changes,
but
you
you
can
send
it
at
other
times
as
well,
and
we
can
phrase
some
some
explanatory
text
or
guidance
texture
on
that
sure.
Okay,
so
I
think
I'm.
Getting
the
feeling
here
that
this
is.
This
is
okay
with
folks
I.
Think
I'm
interested
in
this
Raphael
is
as
well
so
I
think
well,
we'll
go
ahead
and
start
working
up
some
some
PRS
now
server
initiated
ad.
Since
this
is
you
know,
clearly
an
important
thing
that
people
everybody
wants.
L
So
if
we
were
going
to
go
toward
this
lazy
framing,
where
we
have
the
ad
just
in
placing
a
key
and
in
blanking
its
path
and
someone
else's
ratchet,
will
merge
it
into
the
group.
Server
can
synthesize
an
ad
like
I
said,
but
not
the
welcome.
Welcome
contains
the
in
its
secret
for
the
group
that
initiates
the
the
new
user
into
the
group's
secrets
and
server
doesn't
have
that
secret
so
earlier,
in
the
very
very
early
dress,
I
think.
Maybe
not
even
working
group
dress.
There's
the
individual
dress.
L
L
So
now
you
would
have
a
user
initiated
into
the
group
secrets
without
having
to
explicitly
you
know,
hand
the
secret
to
them
in
a
welcome
message
and
so
that
you
open
up
the
set
of
people
who
can
generate
that
welcome
message,
because
you're
only
distributing
public
information
or
non
secret
information,
at
least
in
that
welcome
message:
syntactically
you
that
this
slot
used
to
be
the
init
secret.
You
just
replace
it
with
the
public
key
that
was
mentioned
in
the
previous
slide
other
than
that.
L
The
this
this
would
merit
some
thought
again.
Attackers
earlier
point
when
you're
doing
this.
All
of
this
in
the
in
the
case
where
you're
encrypting
handshake
messages
is
a
little
squirrely.
This
this
would
probably
have
to
be
yeah,
but
we
have
to
we'd
have
to
figure
out
how
this
interacts
with
handshake
message
encryption,
but
at
least
in
terms
of
managing
the
key
scheduler
managing
the
group
secrets.
You
no
longer
have
the
init
secret
here.
L
L
Open
debate
on
that,
so,
on
the
one
hand,
one
of
the
things
that
was
unpleasant
about
the
the
earlier
versions
of
this
is
that
we
had
two
flavors
of
add.
We
had
a
user
initiated
and
a
group
initiated
and
I
think
if
we
were
gonna
do
this
we
would
just
move
all
add
operations
over
this
asymmetric.
Framing
so
we'd
have
one
add
path
that
was
accessed
that
was
used
for
both
both
of
those
cases.
L
You
know
it,
it
is
useful
in
that
it
realizes
the
server
initiated,
add
feature
if
we
want
to
have
that
feature.
I
mean
I,
think
it's
it's
there,
there's
kind
of
some
intuitive
appeal
and
that
you're
know
long
directly,
handing
out
secrets
you're
doing
it
feels
uncomfortable
to
kind
of
extract
that,
in
its
secret
from
where
whatever
container
you
had
it
in
and
send
it
out
over
the
wire,
and
so
here
you
avoid
doing
that
and
you
still
end
up
unable
to
initiate
someone
into
the
group.
I
seem
to
that
makes
me
feel
better
about.
L
You
know
the
ability
to
say
do
this
in
a
fifth
validated
context
where
you
might
have
requirements
around
the
storage
of
the
secrets
required.
The
store,
they've
been
non
recoverable
storage.
All
right,
so
you
say
you
could
this
might
open
up
some
additional
deployability
of
this
protocol
by
not
having
a
passed
around
secrets.
L
On
the
other
hand,
there's
there's
more
complication
to
the
authorization
story
if
you're
going
to
allow
the
server
to
initiate
things
so
right
now
the
signing
the
signing
structure
we
have.
Is
it
just
as
a
pointer
to
a
leaf
in
the
group,
and
you
just
have
to
look
up
the
leaf
there.
This
would
presume
some
additional.
You
know
externally,
imposed
externally
authorized
keys.
That
could
generate
these
messages
into
the
group,
and
you
have
to
posit
something
about.
L
How
do
you,
how
you
manage
those
how
you
refer
to
them
when
you're
generating
messages
I
think
it's
a
solvable
problem,
but
it
is
more
complexity
that
possibly
cryptographically
interesting
bit
of
this
is
right.
Now
are
all
of
our
asymmetric.
Cryptography
is
hpk,
it's
it's
encrypting
to
a
public
key
and
that
allows
us
to
use
chem
constructions
at
that
level
of
generalities.
L
So
that's
nice
because
you
can
realize
a
CEM
with
D
H,
but
you
can
also
realize
it
with
with
pure
Kem's
that
and
there's
a
lot
of
post
quantum
one
more
post
quantum
work
on
chem
like
things
than
on
D
H,
like
things
so
there's
some
kind
of
post
quantum
niceness
to
operating
this
kin
framework
and
not
depending
on
D
H.
If
we
were
going
to
go
down
this
path,
it
would
lock
us
into
having
a
D
H
like
primitive.
L
Now
there
are
post
quantum
options
there,
but
my
impression
is
that
you
know
the
other
key
folks
are
more
familiar
with
literature,
as
my
impression
is
that
there
are
fewer
choices
there
and
at
this
stage
at
least
less
validated
than
the
chem
options.
So
if
we
were
going
to
go
this
path,
we
would
be
kind
of
locking
into
a
D
H
dependency,
which
you
know
might
limit
our
post
quantum
options
down
the
road.
So
that's
I
think
the
last
slide
on
this
topic.
K
K
You
would
recommend
you
had
said
that
you
thought
that
the
server
ad,
which
was
part
of
the
official
transcript,
provides
more
accountability.
I,
don't
think
it
provides
more
accountability
than
a
server
invite
if
we
formalize
a
way
for
a
server
to
do
an
invite
and
then
expect
someone
from
the
group
to
do
an
authorization
or
something
I
think
the
same
level
of
accountability
is
present.
In
that
case
too,
of
course,
if
there's
an
out-of-band
server,
invite
there's
nothing.
K
My
device
had
like
a
new
one,
it's
very
hard
to
see
what
recourse
other
users
have
other
than
a
regular
message
that
says:
hey,
Richard
Barnes
got
a
nuke,
got
a
new
device
which
doesn't
mean
there's
a
new
listener
involved
on
this
channel
yeah,
and
it's
very
difficult
to
sell
how
you
would
explain
that
to
the
user
that
that
an
otherwise
unauthorized
listener
has
been
added.
So
I'm
very
wary
of
us
building
mechanism
that
supports
that
kind
of
wiretap
yeah.
D
In
order
to
give
me
this
capability,
I
mean
I
can
always
add
the
server
as
a
member
of
the
group
and
basically
just
use
my
amount
as
clients,
I
construct
my
MLS
clients,
as
when
I'm
a
when
they're
in
a
way
not
simply
not
to
display
the
server
and
then
I'm
in
the
use
case.
That's
pretty
terrible
because
now
I'm
misusing
the
protocol
in
order
to
get
this
use
case,
I
really
want
so
I'd.
D
L
So
yeah,
let
me
just
note
a
kind
of
tedious
point
earlier
about
the
the
invite
the
server.
What
was
a
phrase
you
used
server,
sir
solicited
this
I
think
there,
the
server
solicitation,
if
you
include
the
solicitation
in
the
transcript
and
it's
clear,
it's
bound
into
the
session
I-
think
there's
similar
properties
in
terms
of
I
agree.
There's
similar
properties
in
terms
of
accountability
to
having
it
having
server
actually
generate
the
add.
L
It
seemed
like
the
main
difference
between
those
two
approach,
totally
open
having
discussion
about
whether
which
of
those
two
approaches
makes
sense
here,
I
think
we
probably
want
to
do
one
of
them.
For
the
reasons
John
mentioned,
it
seems
like
one
thing
that
the
server
solicited
ad
doesn't
it
has
doesn't
address,
is
a
case
where
you
have
a
group
where
the
existing
members
are
all
offline,
and
you
want
to
enable
someone
to
join
and
immediately
transmitted
into
the
group
right.
L
H
H
If
we
want
to
have
a
server
initiated,
then
there
could
actually
be
a
middle
ground
here
that
isn't
being
considered
or
it
doesn't
lock
us
into
th,
where
you
actually
might
say:
okay,
we'll
have
a
server
initiate
under-served
eh
and
look
at
it.
We'll
probably
add
some
sort
of
complication
to
the
construction
and
more
overhead,
but
to
find
a
way
where
the
main
group
is
still
working
with
Kem's
and
the
initiation
isn't
there
could
be
something
there,
but
it
will
mean
a
lot
more
overhead.
Okay,.
I
Yeah
I
mean
sue,
there's
some
variant
to
this,
where
the
as
each
epoch
produces
effectively
a
public
key
that
you
can
say
for
and
then
you
can
as
then
yeah.
You
split
the
difference
in
send
and
receive
where
you
can
send,
but
without
anybody
being
aligned,
but
you
can
only
receive
when
somebody
is
online
right,
that's
possible!
Oh
that's
a
possible
way
to
the
back.
Get
you
out
of
this
th.
It's
this!
I
This
DHT
kind
of
structure
but
I
think
I
went
back
to
first
principles,
which
is
like
when
we've
to
the
people
who've
built
numbery
systems.
It's
clear,
they're
gonna
build
some
kind
of
something
that
looks
like
super
initiative
added
at
the
application
level
and
the
question
and
so
I
think
we
have.
You
know
we
have
a
hint
of
Li
three
options.
One
is
build,
no
constructs
whatsoever
that
per
minute.
I
The
second
is
build
constructs
which
you
know
from
which
sir
tacitly
permit
it,
but
don't
like
really
support
it,
which
I
think
is
what
you
probably
call
service.
Listen
to
dad.
You
know
I
mean
they're
like
basically,
what's
the
supporting
material
I
think
you
know,
there
are
two
versions
there's
one
of
this,
one
of
which
is
like
the
ad.
We
just
like
add
like
an
additional
authenticated,
need
a
block
to
like
every
every
ad
invite
and
then
they
could
just
like
shove
it
in
there.
L
I
Thing
right,
but
I
mean
you
can
imagine
not
felt
not
verifying
that
imagine
of
saying
like
well.
He
just
says
this
true
and
then
you
know
later
it
turns
out
like
two
or
two
years
later,
who
knows
you're
just
lying,
but
like
nobody,
checks
at
the
time
right
and
be
unfortunate,
and
then
the
third
option
is
to
actually
build
a
capability
and
I.
Don't
like
it's
hard
from
you
know
where
the
best
one
of
these
things
is
is
obsolete.
But
that
is
the
idea
that
light
feels
bad
to
like
be
designing
a
system.
I
You
know
like
we're.
We
it's
like
it
has
like
a
misuse
vector,
but
I
think
you
know
it's
not
for
ourselves
that
the
let's
not
fool
ourselves,
that
in
let's
not
fool
ourselves,
that
in
the
the
vast
majority
of
systems,
the
the
the
other
usual
to
anything
other
than
the
other
user
of
clients
would
any
of
the
robotically
like
do
whatever
the
server
asks
them
to
do
right
and
similarly,
it's
possible.
And
similarly,
you
know
it's
possible
in
a
system
which
didn't
want
so
initially
added.
Simply
ignore.
I
Listen
simply
ignore
the
server's
message
that
effect
right
and
I
think
that's.
It's
like.
Let
me
offer
sort
of
a
counter-argument
to
the
implicit
thing
that
we're
building,
something
which
we
expect
to
be
misused,
which
is
that
that
if
you
want
a
little
system
where
you
don't
want
some
initiate
ad
right
like
are
you
better
off?
Are
you
are
you?
I
Are
you
better
you
better
off
in
a
world
where,
like
you
want
the
other
clients
to
omit
the
OD
respondents,
location
or
you
better
from
the
world,
were
you
yourself
ignore
all
the
you
know
yourself
ignore
that
ignore
the
ads
and
I
don't
know
I?
Think
I.
Imagine
the
argument
goes
both
ways
and
I.
Think
like
like
so
here's
like
here's,
like
my
my
hypothetical
bad
argument
right,
so
you
say
you
have
like
you
know
all
the
best
rating
system.
I
We
have
now
basically
how
high
captive
client-server
systems
right,
where
I
think,
where
the
client
and
the
server
and
let
same
people
right
but
imagine
a
world.
We
had
an
open
system
right
and-
and
so
now
you
have
a
system
in
people
and
and
everybody
brings
their
own
client
in
the
clients,
are
varying
qualities
right
and
so
now,
when
I
join
I
accidentally
misconfigure,
my
client,
so
it's
not
designed
to
not
or
doesn't
refuse
to
respond
to
server
server
solicitations
right.
So
now,
there's
not
well
in
the
protocol.
I
Those
little
stations
are
manifest.
Then,
like
you,
didn't
whole
system
screw
right,
whereas
by
contrast,
the
the
system
where,
where
I
could
fit,
where
I
could,
where
people
can
individually
configured
our
clients
to
ignore
the
server
solicitation,
then
you
get
a
break
instead
of
getting
a
instead,
if
you
get
a
precision
instead
of
getting
instead
of
getting,
this
is
being
screwed.
I
So
I
think
that's
really
a
very
strong
argument
against
not
having
any
feature
and
here
for
this,
because
because
because
it
because
then
like,
if
the,
if
this,
if
the
response,
this
notation
is
just
to
blindly
find
the
echo
it
and
not
to
have
any
enforcement
that
the
server
actually
initiated
it,
then,
if
there's
very
high
probability
that
any
that,
if
you
have
a
client
which
is
perky
participating,
either
non
server,
initiated
or
sovereign
nation
and
networks
that
you'll
get
cross-wired.
I
Whereas
if
you,
if
you
force
the
manifest,
then
that
can't
happen
because
then
at
least
then
then
this
it,
then
what
happened
will
be
that
the
that,
when
I
programmed
my
system
not
to
accept
our
worship,
service
service,
low
set
of
ads
and
we're
gonna
purchase
it
again.
So
I
think,
like
you
really
wanna
the
property
that,
like
one,
this
configure
planks
can't
screw
everybody
over.
I
K
I
I
We
have
clients
which
are
configurable
which
are
configurable
to
like
operating
either
a
server,
an
issue
ad
server
like
operate
either
in
environments
where
servers
are
supposed
to
be
adding
or
not
right,
and
and
so
if
and
because
there
are
it's
like
you
know,
we
have
network
a
which
has
server
initiated
and
their
servers
listed,
add
never
compete,
which
is
not
right,
and
so,
if
I
have
a
fight,
if
I
take
my
client.
I
So
if
I
have
a
client
which
will
forward
which
will
actually
respond
to
server
solicitations,
right
and
I
joined,
be
where
I'm
not
supposed
to
happen,
if
that
client,
for
some
reason
doesn't
does,
is
incorrect
and
will
respond
to
server
solicitations.
That
client
basically
represents
a
threat
to
everybody
else
on
so
on
no
B,
even
though
it's
a
perfectly
valid
on
network
right,
and
so
if
we
force
the
responsible
cetaceans
to
come
with
a
whole
lotta
station
chain,
then
the
runs
are
cut
by
the
way.
I
Then
then,
everyone
that
if
anyone
else
on
node
be
properly
checks
the
chain,
then
that
misbehavin
client
is
detected
as
opposed
to
just
like
blindly
adding
you
yeah
all
right,
I'm,
not
loving
any
of
this
at
all.
That's
pretty
bad
right,
yeah.
C
I
C
L
Yeah
I,
don't
think
any
of
this
was
to
say
that
you
know
we
wouldn't
have
self
managing
groups,
but
it's
also
a
lot
external
right.
Well,
okay,
thanks
for
the
feedback,
I
will
continue
to
think
if
we
can
address
some
of
these,
but
it's
useful
having
this
this
framing
of
how
do
we
guide
things
properly,
so
I'll
take
another
shot
at
this
Thanks.
B
Three
decks
in
35
minutes,
man,
terrible
okay,
so
we
have
less
things
to
discuss
now.
Typically,
there
is
one
thing
that
has
been
occurring
of
other
SG
meetings
is
hpk,
so
right
now,
when
we
do
public
key
encryption
to
in
within
a
tree
or
actually
to
a
specific
new
member,
that's
gonna
be
added
to
hope.
When
you
want
to
send
him
some
pubic
information
encrypted
and
OSP
bleakie
yeah,
you
are
using
it
HBK.
B
So
there
is
a
draft
from
Richard
that
is
known,
ITF
out
walking
up
laughs
and
progress,
and
the
current
state
of
the
things
is
that
basically,
when
we
encrypt
to
a
subgroup
ultralift
directly,
we
use
HP
k.
Io
is
basically
HP.
Kayo
is
basically
no
PS
k,
so
in
HP
k,
no,
we
have
a
mode
that
supports
PS
k.
B
B
But
what
we
do
is
that
we
mix
the
anti
of
pubic
tree
actually
of
the
of
the
person
that
actually
sends
so
that
there
is
agreement
at
all
times
between
the
the
the
person
that's
encrypts
and
the
person
that
receives
the
encryption
about
the
public
tree.
It's
only
due
to
those
two
right:
it's
not
the
entire,
the
members
of
the
tree,
that
angry,
but
at
least
for
the
person
that
receives
you
in
nosy
as
yes,
the
same
view
as
the
as
the
as
the
participant
that
encrypted.
B
The
the
current
state
is
that
we
bound
anyway,
the
ciphertext
are
bounded
to
the
sub
trees
and
because
you
use
the
public
keys
if
I'm
on
a
static
key
of
the
of
the
work
group
and
for
the
hpk
now
is
there
any
specific
reason
to
add
a
PS
gain?
They're,
not
sure
it's
actually,
that's,
not
something
that
we
are
doing.
It
seems
that
mixing
information.
The
context
is
enough
to
ensure
that
there
is
agreement.
B
L
B
So
that's
it!
So
that's
an
intense,
we'll,
try
to
add
more
more
context
inside
the
key
derivation
exit.
If
you
have
any
concerns,
I
think
it's
an
interesting
point,
especially
on
the
PSK
point.
If
you
see,
if
you
have
like
use
cases
that
might
need
to
place
casing
to
be
interesting
to
know
another
topic
that
we
discussed
and
key,
we
talked
about
non
this.
What
we
call
non-destructive
are
ad,
which
is
basically
the
fact
that
when
we
we're
doing
has
currently,
we
were
blanking
so
to
echo.
B
B
So
you
came
two
times
so
if
you
take
more
subtly
more
complex
example,
it
reflects
a
bit
more
why
it's
efficient
it's
more
efficient.
So
imagine
you
have
a
full
tree.
You'll
remove,
see,
EF
and
L
so
know
you're
in
the
states
where
you
have
six
heads
those
those
blackheads
and
you
need
to
encrypt
to
all
of
them
right
in
imagine.
Someone
like
a
adds
and
recovers
basically
is
full
pass
up
to
the
woods.
So
in
that
case
you
just
have
to
encrypt
to
that
guy
right.
B
If
now,
you'd
escape
the
destructive,
add
and
add
C,
you
would
kill
all
those
previous
knows
that
you
feel.
So.
Basically,
you
kill
the
efficiency
that
you
just
restored
by
having
an
update,
so
it's
quite
bad
in
some
sense,
because
you,
you
completely
destroy
the
efficiency
of
the
of
the
group.
Well,
if
you
do
the
non-destructive
ad,
basically,
you
are
just
adding
you're
keeping
the
previous
nodes
and
you're
adding
one.
B
So
basically,
you
have
two
heads
the
existing
one,
which
is
on
the
left
basically
and
the
new
one
which
is
C,
so
you
do
two
cans
instead
of
doing
six,
seven,
sorry
and
it
maintains
the
secrecy
invariant.
The
costs
is
simply
that
no,
you
had
a
bit
more
complexity,
I'll
get
back
to
that
in
the
end,
but
it
doesn't
seem
too
bad.
The
protocol
impact
is
just
that
you,
you
keep
basically
a
list
of
for
each
intermediate
node
you
key
and
you
keep
the
index
of
the
of
the
node
that
hasn't
been
made.
B
B
At
least
and
one
more
efficient
group
operation
that
follows
the
ad,
so
it's
it's
it's
actually
quite
good.
There
is
something
that
we've
been
discussing
a
while
back.
Is
that
hopefully,
the
stats
that
we
are?
Maybe
you
can
confirm
this
Richard
is
that
the
numbers
of
adds
and
removes
in
groups
actually
very
similar
in
terms
of
the
frequency
of
add
and
removes,
are
actually
very
similar.
B
It's
not
like
there
is
a
large
difference
between
updates
and
at
remove,
but
the
number
of
add
and
removes
in
a
group
is
roughly
the
same
along
your
life
of
the
group.
It
depends
because
at
the
very
meaning
of
obviously
you
have
like
more
ads,
but
as
group
keeps
going,
it
stabilizes
and
you
have
lots
of
I,
don't
know
moves,
but
in.
B
L
Richard
burns
that
yeah
I
think
we
should
just
do
this
I
think
the
complexity
is
manageable.
There's
a
little
bit
of
weirdness
and
remove,
but
I
think
it's
it's
not
a
whole
lot
of
code.
You
say
to
keep
all
this
information
around
and
keep
it
live
so
and
I
think
the
the
performance
benefits
merit
they,
the
extra
record-keeping.
K
G
K
G
B
B
K
K
B
B
All
the
rest,
so
in
some
sense
you
tied
you
already
have
a
list
of
keys.
You
have
to
encrypt
to
it's
just
that
you
try
to
maintain
a
list
of
people
of
people
that
have
not
been
yet
merged
in
the
sub
tree
so
that
you
only
have
to
send
to
them.
Instead
of
instead
of
you
can
use
the
previous
route
of
the
sub
tree,
that's
one
encryption
and
then
the
list
of
people
that
haven't
been
merged
yet,
but
that's
no
worse
than
the
producers
right
now.
I.
K
Don't
know
I
haven't
looked
at
what
the
overall
numbers
are
and
what
the
what
the
balance
is
for
in
terms
of
how
many
keys
you're
managing
over
time
and
how
expensive
the
adds.
Sorry,
I,
don't
I'm!
Sorry
I,
didn't
understand
just
films,
presentation
but
I,
don't
understand
how
we
judge
that
without
seeing
some
numbers
about
what
the
actual
amount
of
trade-off
is
in
terms
of
storage
and
in
terms
of
how
complicated
ooh
yeah.
G
Matthew
Miller
so
I
mean
for
me
I'm
looking
at
this.
This
actually
looks
great,
not
so
much
from
the
frequency
side,
but
from
the
size
of
the
tree
like
if
you've
got
a
very,
very
large
tree.
This
could
actually
be
quite
efficient
for
ads
I
mean
when
you've
got
a
really
really
large
tree,
you're,
usually
only
getting
a
few
ads,
at
least
that's
what
I've
seen
from
my
experiences.
So
this
would
greatly
simplify
things.
I
think.
Can
you
comment
on?
G
B
L
N
B
So
it's
thinking
about
it
I
think
it
doesn't
I'm,
not
afraid
about
the
complexity,
because
I
do
informal
letters
and
I
could
and
I
can
prove
that
I
do
what
the
thing
is
supposed
to
do.
But
I
can
understand
why
people
would
would
be
scared
about
having
this
additional
complexity
there,
so
that
something
to
is
to
discuss.
B
In
a
subtree
like
this,
in
triplets,
you
have
like
left
subtree
right,
subtree,
the
current
the
country
in
which
you
have
a
value
which
is
the
secret,
sorry
and
hash,
which
is
basically
combining
the
ash
of
the
subtree
so
that
you
have
agreements
in
the
entire
tree.
I
mean
you
know,
what's
under
the
what's
under
the
the
left,
subtree
in
the
right
subtree,
and
if
you,
if
you
have
the
entire
pubic
stage,
you
can
recompute
the
hashes
and
be
sure
that
the
view
is
consistent
with
the
ash,
that's
in
actually
in
the
old
node.
B
But
of
course,
if
someone
lies,
they
can
tamper
with
the
intermediate
nodes
and
send
you
a
tree.
That's
actually
consistent
right!
You
you,
you
have
a
public
tree,
that's
consistent
because
should
take
the
the
ashes
of
the
sub
trees.
You
mix
them
in.
You
have
a
wood
ash,
that's
correct,
but
actually
all
those
intermediate
ashes
could
have
enforceable.
B
So
if
you
are
able
to
verify
that
the
signatures
on
the
other
sub
trees
are
valid
signatures,
except
if
the
one
exactly
the
people
that
emitted
the
signatures
of
you
sees
is
a
Josiah
as
well.
You
know
that
at
least
with
this
person,
you
have
the
same
view
of
the
tree.
So
it's
certain
some
sense.
It's
just
like
giving
you
some
more
guarantees
and
like
basic.
We
can
incremental
e
build
the
fact
that
oh
yeah,
by
the
way,
he
knows
that
this
so
F
doesn't
update
he
signs
this
updated,
node
and
sex
out.
B
If,
b,
if
b,
actually
sounds
you
garbage,
you
can
check
that
the
signature
that
has
been
emitted
by
e
is
the
node
is
actually
the
correct
one
for
e
increment
re.
You
can
build
that,
meaning
that
if
F
successfully
sent
you
an
update
after
you,
you
inherit
the
fact
that
oh,
both
E
and
F
actually
agree
with
the
sander
of
the
initial
ad
that
this
was
the
cognate
entry.
B
It's
not
like
a
union
union
that
they
are
a
blessing,
that
it's
a
unilateral
blessing
that
the
current
state
that
you
have
is
this
one,
but
until
people
updates
you
don't
get
any
guarantee,
like
only
the
only
guarantee
you
get
is
when
someone
actually
successfully
updated
the
tree,
because
you
know
that
in
that
case
they
have
the
same
view
as
you
as
well.
So.
I
If
I'm
reading
this
correctly,
the
nose
with
question
marks
on
them
or
the
ones
that
are
actually
untrustworthy
so
ideal,
Antigua
and
I'm
reading
this
correctly,
the
nodes
of
question
marks
on
them
are
the
ones
that
are
wrong.
She
didn't
tell
you
if
I'm
reading
this
correctly,
the
nose
with
question
marks
on
them
are
the
ones
that
are
wrong.
They're
lies,
yes,
it
can't
be.
Those
can
be
a
I'm
assuming
the
B's
right.
So
I
don't
feel
like
super.
I
What
a
lot
warmer
about
any
situation
where,
like
the
route,
is
wrong,
but
their
leaves
are
right
in
terms
of
security
objectives.
I'd
really
be
much
more
interested
in
detecting
lying,
but
I
am
about
containing
it,
namely
I'd
be
much
more
interested
thing.
I'm
interested
in
is
when
is
once
we
discover,
there's
a
partition
being
able
to
prove
who
made
the
partition.
I
I
I
guess
I
guess
what
I'd
like
to
be
able
to
do.
I
mean
like
let's
just
talk
about
like
like
the
outcome.
We
will
hunt
forget
ingrained
technology
for
a
second
right,
the
best
case
scenario.
It
would
not
be
possible
to
end
as
a
partition.
Maybe
we
don't
have
a
second
base
case
scenario.
It
would
pass
it.
The
situation
I
want
is:
is
that
when
I
detect
there's
a
partition,
I'm
able
to
determine
who
created
the
partition
report
them
that
haven't
thrown
about
a
grip
on?
I
I
Yeah
but
then
well,
then,
I
need
to
prove
to
the
groom
in
here.
The
server
so
like
I
think
that's
I
mean
I.
Just
understand,
like
a
situation
where
I
have
like,
like
this
just
seems
like
a
situation
where
it's
going
to
be
a
sort
of
like
really
hard
as
a
as
a
as
a
system
operator
like
dealing
with
a
problem
like
half
the
people,
gonna
be
the
message
in
half
can't
it's
gonna
be
like
incredibly
hard
to
manage,
yeah
and
so
I.
L
H
I
L
I
B
What
I
can
foresee
is
that
when
you
had
added
to
a
group,
we
could
know
that.
That's
I,
don't
know
people
uniform
ethos,
an
update
to
to
to
you,
because
in
some
sense,
when
you
receive
an
update,
it
means
that
you
are
the
same
pubic
tree
as
the
as
the
person
that
sends
you.
So
as
soon
as
you
are
like
a
certain
amount
of
confirmation,
especially
if,
if
you,
if
you,
if
be
added
C
and
D
updates,
it
knows
that
D
has
the
same
view
as
it
does
right
of
the
entire
tree.
B
K
Dkg,
so
I'm
not
exactly
sure
what
these
dotted
line
signatures
concretely
describe
what
is
signed,
for
example,
but
whenever
I
see
signatures
thrown
in
as
a
answer
to
solve
this
problem,
I
worry
that
I
worry
about
transplanted
signatures
yeah.
That
is
like
imagine
that
you've
got
two
group
conversations.
B
Catholic,
so
this
is
Catholics
proposal.
Is
that
in
the
formal
model
we
have,
we
keep
track
of
the
actor
of
each
action
in
within
the
tree.
So
when
a
o
dates
for
each
node,
we
mark
that
a
updated
the
tree
and
the
we
have
a
pubic
ash,
which
is
we
have
the
pubic
ash
of
the
subtree.
That
gives
you.
That
here
is
the
new
state
of
the
sub
tree.
B
Here
is
the
actor
that
actually
made
the
change,
and
you
can
sign
the
entire
thing
which
gives
you
that
I
did
a
modification
here
is
the
state
of
the
sub
tree
that
I
modified
and
know.
You
know
that
it
is
this
tree
and
in
some
sense,
if
that's
only
what
it
gives
you
right,
because
there
is
no
consistency
or
secrets
at
all
in
that
story,
because
you
cannot,
you
cannot
enforce
the
fact
that
you
have
the
same
secrets.
B
You
don't
have
knowledge
of
the
other
secret,
so
you
can
never
say
anything
about
the
private
part
of
the
tree,
but
the
pubic
one.
You
can
always
say.
Oh
yeah
here
is
the
current
state.
That's
oh
I
left
it
and
now,
if
an
attackers
gives
you
the
current
state,
which
is
not
the
same
as
mine
as
soon
as
I
updates,
you
will
know
that
that
this
is
different
and
they
are
not
having
the
ability
of
forging
my
signature
can.
Actually
you
cannot
do
anything
right,
so
my
concern
is
not
about
forging.
K
L
B
Actually,
the
entire
subtree
of
the
people
you
talk
to
are
is
is
mixed
in
the
kiddie
relation,
so
you
would
not
be
able
to
generate
a
new,
a
fudge,
cope
with
different
people
and
get
the
same
copy
notifier
on
some
keys.
So
they
would
immediately
know
that
section
in
the
same
group
and
they
would
immediately
immediately
know
because
you
have
to
give
the
public
keys
of
the
people
that
are
in
the
new
group
to
get
that
secret.
You
immediately
know
that
here
is
the
list
at
all
times.
L
L
Sorry,
yeah
I
was
gonna,
try
and
I.
Think
ecers,
argument
I
think
is
pretty
convincing
to
me
that
this
is
not
really
a
useful
approach
here
that
we
would
do
better
by
doing
a
kind
of
state
confirmation
approach
this.
This
thing
presumes
that
you
are
accepting
the
adder
as
your
sole
source
of
juice.
I.
Think
ecers
approach
is
probably
a
little
bit
more
practical
in
the
sense
of
taking
some
statement
of
the
state
of
the
group
which
we
already
have
several
you.
L
B
Find
it
completely
fine
within
something
else,
I
think
this
is
like
80
ways
in
some
sense
yeah,
and
if
we,
if
we
can
have
like
a
few
few
non
adversarial
members
of
the
tree,
to
confirm
the
current
state,
it's
fine!
It's
enough!
Actually,
the
the
question
is:
how
many
members
do
you
need
to
be
able
to
get
this
pubic
tree
to
agree
on
this
baby
tree
because
I
mean
in
the
setting
where
you
don't
care
about
address.
Are
your
numbers
at
all?
B
You
don't
care,
but
in
that
scenario
you
the
group
might
be
small
and
the
attacker
might
collude
with
other
keys
and
other
party
within
the
group
and
as
soon
as
you
have
adversarial
partisan
group
anyway,
it
gets
messy.
So
those
alternative
would
be
fine,
I
think
to
just
as
explicitly
the
other
people
in
the
tree
to
acknowledge
the
fact
that
the
pre
victory
that
you
received
as
a
new.
P
P
B
P
E
P
We
need
a
sense
of
what's
gonna
what
actually
needs
to
to
be
talked
about,
and
we
do
have
quite
a
few
issues
as
well.
As
the
authors
have
been
doing.
A
good
job
tracking
milestones
on
github,
so
take
a
look
at
the
open
issues
and
and
we'll
discuss
whether
or
not
one
or
two
days
is
that
it's
necessary
can.
H
A
P
A
Official
I
have
an
official
meeting
where
we're
gonna
meet
in
person.
We
have
to
give
four
weeks
notice,
so
what
I'm
doing
right
now
is
trying
to
see
if
the
authors
can
tell
me
when
they're
available
and
we'll
work
from
there,
because
it
would
be
weird
to
have
a
meeting
where
none
of
them
could
show
up.
So
that's
that's
the
triage
on
how
we're
doing,
but
we're
definitely
gonna
get
you
guys
the
info
as
soon
as
possible,
Thanks
and
I
believe
that
concludes
the
meeting.
Thank
you
very
much.