►
From YouTube: IETF102-MLS-20180719-0930
Description
MLS meeting session at IETF102
2018/07/19 0930
https://datatracker.ietf.org/meeting/102/proceedings/
A
A
A
As
usual,
we
would
like
everyone
to
be
able
to
understand
who's
who's
saying
what
at
the
microphone.
So
you
come
up
to
the
microphone
state,
your
name.
This
is
not
only
for
the
people
in
the
room,
but
it's
for
the
remote
participants.
We
have
at
least
six
Omnitech,
though
right
now,
so
please
keep
it
professional
and
let's
move
on
to
the
agenda.
A
A
A
A
Anything
that
people
use
MLS
work
and
can
use
share
code
basically,
and
the
goal
is
not
to
enable
full
interoperability
or
Federation
beyond
the
key
establishment,
authentication
and
confidentiality.
So
we're
really
looking
at
the
crypto
here,
we're
not
looking
at
making
sure
that
different
messaging
protocols
from
a
high
level
can
interoperate
we're.
Looking
at
standardizing
the
crypto
and
another
point
is
that,
while
authentication
is
a
key
goal
of
the
group,
it's
not
the
objective
to
develop
new
authentication
technologies.
A
Hopefully
what
the
result
of
this
working
group
will
be
documents
in
which
you
could
use
x.509
or
other
authentication
techniques
and
and
plug
them
in
similar
to
how
TLS
does
not
define
which
specific
authentication
technologies
are
used
in
okay,
without
will
do
an
arc.
The
architecture
review,
slides
I'm
on.
B
Okay,
hi
everyone,
I'm
ed
Amara
from
Google,
so
big
here
I,
will
cover
tooth
presentation.
Today's
architecture
and
message
ordering
both
of
them
are
basically
overview
of
what
we
have
today
in
the
drafts,
followed
by
a
list
of
open
questions
to
the
group
not
necessary
to
get
answered
all
of
them
today,
but
just
only
the
discussions.
Often
you
get
some
answer
to
most
of
them,
so
this
is
the
same
as
I
go
through
like
a
Chinese
above
because
nothing
has
changed
since
then,
but
you
could
get
through
this
in
slides
again.
B
So
this
is
what
a
typical
imaging
system
looks
like
server
side,
the
client
side
several
to
services,
most
of
the
time
to
return
to
the
same
service,
which
is
authentication,
delivery.
Clients
are
the
members
each
member
has
a
bunch
of
voices.
Each
device
in
MLS
is
actually
a
separate
client.
Each
has
long
term
identity.
Key
in
this
picture
there's
a
group
of
a
BNC.
He
has
three
devices
vs
2
ones.
He
had
one.
B
Okay,
what
syndication
service,
basically
storage,
mapping
between
long-term
identity,
keys
between
user
name,
ID,
even
long-term
identities
like
email
phone
numbers
to
identities,
the
other
service
ensures
reliable
in
order
delivery
for
a
message
and
attachments
store.
The
init
keys
which
are
signed
by
that
indicates
and
option
is
to
grow
membership.
So
everything
has
a
straight
core
story.
Here
is
one
of
the
open
questions
we'll
discuss
event
so
store.
Bro
membership
is
one
of
the
hoenn
questions.
Also,
the
reserved
responsible
for
affecting
long-term
passive
user
is
to
ensure
this
year's
client.
B
Yes,
this
is
a
typical
client
operations,
st.
John
group,
etc.
Since
devices
are
presented
established
client
so
basically
invite
member
advice,
all
the
simulation
scene
for
remove
member
or
remove
device
orgasm
operations.
So
in
this
picture
a
one
tries
to
create
a
group
with
DNC,
so
a
one
daily
request
in
each
case
for
a
2,
a
3,
B,
1,
B,
2
and
C
1
verify
the
signature
in
this
key
is
created
secret,
encrypted
message.
B
Then
they
want
me
to
and
see
one
receive
the
message
we
create
the
same
chip,
shared
secret
and
decrypt
a
message
function.
Requirements,
scalability
obviously
supports
large
groups.
The
number
came
up
with
57
clients,
a
synchronous.
All
aggression
can
be
done
without
having
the
call
devices
to
me
online.
Most
of
all
devices
should
be
supported,
natively
because
again
voice.
It
just
say.
First
client
storing
history
is
met
requirements
by
the
protocol,
but
again
the
application
can
support
this
client
set
recovery.
B
If
the
client
was
staged
to
be
able
to
restore
the
state
without
corrupting
the
entire
group
mitigate
the
collection,
this
is
for
protecting
the
privacy,
so
the
both
EDR
years
and
years
should
be
collected.
The
minimum
yes
I
needed
to
deliver
the
message
Federation
as
I
mentioned
in
what
we
discussed
earlier,
is
that
wouldn't
expect
introverts
application
layer
like,
but
most
of
ammunition
should
be
able
to
integrate
versioning
I'm
going
to
talk
more
about
this
at
the
end,
but
we
should
really
support
version
negotiation
and
have
mitigation
for
downgrade
attacks
security
requirements.
B
Of
course,
message:
secrecy
in
terms
of
medications.
Message
should
be
decrypted
by
only
existing
with
the
group,
and
only
existing
members
can
send
this
message.
Another
asterisk
in
your
message
appearing
to
prevent
traffic
analysis.
So
this
is
optional
for
secrecy
and
post
command
security
to
refresh
our
minds
forward
secrecy.
It
means
if
the
attacker
has
all
traffic
history
and
key
k1
should
not
be
able
to
decrypt
any
messages
before
key
one
would
scheme
would
be
for
k1.
B
The
other
way
around
is
pcs
is
if
taker
has
k1
and
some
encrypted
traffic
and
in
the
time
time,
T
Prime.
The
key
has
to
Quito
shouldn't
be
able
to
decrypt
any
traffic
after
Quito
little
membership
Secotan,
who
all
never
should
have
the
same
thing
of
group
members.
This
can
be
done
by
using
merkel,
cheese,
proof
commitments.
B
Client
who
joins
the
group
should
not
be
able
to
decrypt
any
message
before
joining
clients
from
removed
from
the
optional
be
able
to
encrypt
messy
after
leaving
attachment
security
should
have
all
the
security
semantics
of
any
message,
except
the
encryption
key.
She
tends
to
be
longer
because
of
that
attachment.
Netta
origin
authentication
means
new
impersonations,
so
Alice
can't
impersonate
pops
in
the
message
as
pop
this
usually
done
by
having
signature
and
every
message.
B
B
If
authentication
services
compromised
our
it's,
it's
it's
more
serious
because
it
can
allow
impersonations
so
a
condition
in
encrypted
engines
and
concerns
pretty
loving
or
something
like
it,
transparency
to
do
so,
if,
if
this
client
compromised,
this
is
the
worst
case,
because
attacker
will
be
able
to
encrypt
and
decrypt
messages,
but
it
can
be
defeated
after
the
compromised.
Client
has
been
updated
that
give
material,
but
it
should
not
be
able
to
do
any
newest
attacks
again.
It's
other
beers
in
the
world
I
gave
this
is
a
list
of
open
question.
B
B
C
D
C
Think,
oh
there's
nothing!
We
can
do
with
the
voluntary
standard.
Yeah
I'm
elaborating
here
so
I
think
we
should
both
provide
guidance
on
the
frequency
of
key
update
but
be
realistic
about
how
tightly
constrained
applications.
So,
for
instance,
we
might
say
we
really
strongly
recommend
that
you
have
a
do.
You
update
your
key
at
least
once
per
day,
but
they're
gonna
be
things
that
are
offline,
that
are
gonna,
miss
that
budget,
and
so
it's
gonna
be
up
to
the
applications
and
to
make
their
best
effort
to
meet
virtually.
C
E
F
Regarding
the
question
whether
the
server
can
be
trusted
to
store
the
group,
membership
I
think
in
a
number
of
vacations,
this
wouldn't
be
an
issue,
but
there
are
some
applications
where
it
would
be
an
issue.
So
I
think
it
would
be
a
good
idea
to
have
it
optionally
work
in
a
way
that
the
server
cannot
infer
who
the
group
members
are
from
persistent
data.
F
A
D
D
So
I
think
the
recommendation
from
from
Richard
seems
a
good
idea
to
me
like
when
updating
the
key,
the
GUP
key
one
per
day.
The
coop
secrets
once
per
day
seems
like
a
reasonable
recommendation
to
me,
especially
because
some
security
properties
will
actually
depend
on
that
secret
and
maybe
I'll
come
back
to
it
a
bit
later
in
the
message
protection
part,
but
typically
depending
on.
D
B
H
Feature
that
we
should
add
some
guidance
about
what
to
do
with
it
and
I
think
that
there
are
a
lot
of
techniques
that
you
may
know
that
in
Safari
we
have
a
document
about
regime
that
is
close
in
to
is
G
period,
that
there
can
be
some
key
Iraqi.
That
key
can
be
changed,
for
example,
once
a
day
and
the
session
keys
can
be
changed
frequently.
But
yes,
I
totally
agree
that
we
should
add
such
issues
in
the
draft.
H
The
document
may
be
as
a
guidance
or
as
best
practices,
but
we
should
address
this
issue
because
we
know
some
examples
of
messengers,
for
example,
which
care
of
this
problem
with
keys
that
are
not
being
changed.
So,
yes,
this
must
be
addressed
in
my
opinion
and
second
question
I
have
here:
do
we
address
authentication
techniques,
indication
methods
as
part
of
the
key
texture
or
as
completely
independent,
separate
document
and
separate
since
this
to
discuss
so.
B
I
D
I
No
stops
but
on
which
is,
you
know,
wikis,
that's
probably
not
really
an
issue
in
this
case.
You
know
you.
If
you
know,
if
you,
if
you
rotate
your
keys,
you
know
like
once
a
day
you
basically
get
here.
You
get
said
you
get
something
like
you
know
like
four
or
five
extra
bits
of
security.
That's
really
get
you
very
much,
but
the
reason
is
to
do
it.
Our
four
key
exhaustion
in
terms
of
aes
keys
is
GCM
keys
and
also
for
PFS
and
pcs.
I
I
I
Yeah
more
seriously,
I
think
would
be
good
if
it
was
able
to,
but
I
don't
think
it's
I,
don't
think
that
there
seem
to
be
some
seem
to
be
a
bunch
of
I
get.
The
problem
is
that
well
that'd
be
a
nice
feature.
It
comes
along
with
a
lot
of
package,
so
if
they
analyze
with
that
packages
and
whether
that
baggage
so
I
guess
you
want
to
where
my
sense
from
current
analysis
is,
it
is
not,
but
it's
not
just
a
yes/no
kind
of
question
with
regard
to
the
server
being
trusted
store.
I
Group
membership,
I'm
actually
again,
two
issues
here
right,
one
is:
is
this
her
trusted
to
accurately
report
group
membership
and
the
second
is
the
server
trusted
to
know
group
membership.
The
the
server
should
not
be
trusted
to
act.
The
group
membership
for
obvious
reasons,
and
that
should
be
pretty
easy
to
cryptographically
fix
in
terms
of
sorts
or
be
entrusted
to
know.
I
Group
membership
G
would
sure
be
nice
if
we're
able
to
bolus
system
that
didn't
require
that,
but
I
suspect,
when
a
system
practice
will
end
up
having
that
information
any
case
on
so
again,
we
have
to
figure
out
the
baggages
their
motor
systems
on
familiar
with
on
as
a
practical
matter.
If
you
know,
group
membership
anyway,
so
doesn't
make
that
much
difference.
Finally,
the
guard
traffic
analysis
mitigation
on
I
think
we
should
not
do
anything
here.
I
I
think
there
should
be
a
like
a
section
that
says
like
this
is
like
a
huge
source
of
like
information
leakage,
but
like
every
time
I've
seen
anybody
tried
is
it
turns
into
enormous
rathole,
so
I,
don't
think
we'd
actually
do
anything.
Separate
traffic
analysis
on
mitigation
document
that'd
be
fantastic
and
I'm
kind
of
hoping
that
hair,
RG
or
whatever
they're
called,
will
actually
give
us
some
help
here,
but
I
think
we
shouldn't
like.
We
think
like
that's,
that
that
could
show
a
lot
of
working
your
time
for
not
much
value.
Let's.
A
J
D
B
J
B
K
And
this
is
Daniel
Caine
Gilmore,
so
I
do
believe
that
the
draft
needs
to
specify
strong
recommendations
for
key
update.
We
have
experience
of
not
recommending
key
update
schedules
and
other
protocols
and
people
done
don't
implement
them
at
all.
Maybe
they
won't,
even
if
we
recommend,
but
if
we
recommend
that
we
give
him
a
chance,
I
recommend
framing
it
as
a
minimum
and
maximum
key
update
range,
because
you
want
a
maximum
and.
K
Period,
but
if
people
read
it
too
fast,
then
we
get
that
we
run
into
this
problem
that
that
John
describes
and
if
they
update
you
slowly,
then
we
know
that
the
PCs,
but
we
should
put
in
a
concrete
recommendation
and
I
agree
with
John
that
thinking
about
how
we
frame
that
with
regard
to
number
of
groups,
is
important
as
far
as
hiding
the
user
devices.
I've
mentioned
this
on
list
the
current
arrangement,
where
we
are
currently
saying
well,
you
know
multiple
members
and
each
have
multiple
devices
and
the
devices
are
visible.
K
That
is
a
strict
superset
I.
Think
of
what
we
minimally
need
to
do
minimally,
we
need
one
device
per
user
and
the
user
could
do
something
like
MLS
between
their
own
devices
to
synchronize,
whatever
key
storage
and
state,
they
need
to
synchronize.
If
the
user
doesn't
do
that,
then
they
end
up
showing
up
as
multiple
devices.
The
reason
I
think
we
should
avoid
trying
to
get
too
deep
into
the
weeds
of
a
multiple
in
the
multi
device
case,
aside
from
it
being
more
than
we
need
to
do
to
get
something.
K
K
Do
you
want
to
expose
that
you
have
multiple
devices
or
do
you
want
to
just
pretend
to
have
one
right,
I
think
that's
a
that's
a
bad
question
for
user
interface
and
we
don't
want
to
give
users
the
choice
of
switching
in
between
there,
and
the
second
reason
is
because,
once
your
keys
are
being
updated
like
that,
and
it
appears
that
you
have
a
new
device.
You're
gonna
increase
the
number
of
notices
that
new
devices
show
up
or
you'll
start
removing
those
notices
because
they
just
get
in
the
way
and
so
in
the
fourth.
K
In
the
first
case,
you
end
up
with
security
fatigue,
which
means
you
don't
notice
the
actual
big
devices
where
a
user
gets
read,
which
is
the
wiretap
scenario
and
in
the
second
case,
where
it's
all
hidden,
you
can't
notice
it
so
I
think
that
when
we,
if
we
go
into
the
point
of
exposing
multiple
user
devices,
it
leaks
privacy
and
it
increases
the
problem
that
the
the
ease
of
inserting
an
additional
key
for
a
wiretap
scenario,
which
I
think
we
should
be
avoiding.
We
should
be
avoiding
making
this
wiretap
facilitation
scenario.
K
I
will
not
comment
on
the
third
one,
but
on
the
fourth
one
we
need
to
include
a
mechanism
for
traffic
padding.
We
do
not
need
to
specify
exactly
how
to
pad,
but
for
the
protocol
messages,
in
particular
all
of
the
stuff
that
I've
seen
across
the
ITF.
The
application
layer
is
what
knows
best
how
to
pad,
and
so
somebody
who
wants
to
write
a
draft
should
be
able
to
do
that
at
the
layer
of
MLS.
But
we
don't
need
to
include
the
specific
advice
in
the
first
round
here.
K
M
Lucia
Ballard
from
Apple
just
a
comment
on
the
first
point.
I
think
having
the
recommendation
here
would
be
really
useful.
Having
a
strict
requirement
would
potentially
be
a
hurdle
to
adoption
or
if
you
go
with
the
minimum
maximum
idea
and
making
sure
that
minimums
pretty
generous
just
because
I'm
thinking
potential
clients
adopting
this
are
in
the
very
hugely
in
their
expected
group
size
in
their
sort
of
expected
connectivity
for
group
participants
and
in
the
amount
of
already
deployed
infrastructure
at
scale
that
they
have
to
deal
with
so
making
sure
that
there's
some
flexibility
there.
N
Bob
Mascis
HT
consulting
I'm,
going
through
the
list,
I've
seen
so
many
scenarios,
but
ripping
the
IOT
arena
where
I
think
good
guidance
in
different
classes.
Scenarios
will
be
very
good
because
one
community,
we
may
be
very
insular
and
not
being
able
to
think
really
out
of
their
own
box
of
what
they
may
be
doing.
So
they
can
see
how,
in
this
particular
case,
a
different
key
update
method
will
maybe
use
may
open
their
eyes
to
a
broader
view
of
it.
N
But
in
IOT
arenas
with
some
multi-class
case,
I
seem
like
you're,
not
gonna
get
key
exhaustion
for
a
few
years,
and
devices
are
not
going
to
be
updated
for
even
maybe
more
years
than
that.
So
they
don't
even
talk
about
key
update
in
those
arenas
because
of
that.
But
but
even
so
those
people
should
still
think
about
some
of
the
other
cases.
So
good
guidance,
I
think
is
what's
needed
in
the
key
update
arena
and
and
strong
recommendations
in
certain
for
certain
scenarios.
N
Also
in
many
again,
it
depends
on
the
multicast
cases,
whether
you
can
really
can
not
store
the
group
membership,
so
that's
really
related
to
what
you're
doing
with
with
multicast
and
and
so
how
does
MLS
or
have
really
anything
to
say
to
the
group
about
what
they're
doing
in
terms
of
group
memberships
store.
So
I
think
that's
out
of
scope
for
MLS
and
on
the
last
one
I
assume
you're
talking
about
traffic
analysis
of
MLS,
not
traffic,
analysis
of
how
those
keys
are
used.
A
O
C
Thanks
Karthik
this
Richard
Bruns,
again
I
spoke
about
the
first
one
already
I'll
just
cover
the
other
three
briefly,
which
is
largely
plus
one
of
those.
Some
other
folks
have
said
too,
with
regards
to
Bob's
question
about
hiding
devices.
I
think
the
flavor
of
hiding
we've
discussed
here
is
a
John.
John
Milliken
came
up
with
phrase.
Pre
trees,
where
you
might
have
a
leaf
node
in
the
mls
tree,
actually
represents
a
whole
subtree
of
devices
that
belong
to
a
user's
perspective
of
the
overall
group.
C
You
would
just
see
the
user
as
one
node
in
the
cryptographic
State,
even
though
there
might
be
that
no,
it
might
be
a
compound
with
other
ones.
That's
kind
of
I
think
what
ml
d
kg
was
referring
to
take
your
three-letter
acronym
Dicky
was
referring
to
you
when
I
was
talking
about
running
the
protocol
among
your
own
devices,
which
I
think
is
exactly
the
right
way
to
think
about
this
I.
Don't
think
we
really
need
to
get
into
the
details
of
how
you
might
go
about
hiding
things.
C
We
might
you
know,
use
the
the
server
as
a
cache
of
some
information,
but
not
require
it
to
store
the
whole
membership
of
the
group.
So
you
might,
you
know,
trusted
the
store.
You
know
a
collection
of
public
keys
for
nodes
in
a
cryptographic
state
but
divorced
from
identity.
Information
about
the
participants
and
I
think
John's,
nodding,
I
think
that's
sort
of
already
saying,
so
we
might
trust
the
server
to
cache
some
stuff,
that's
kind
of
not
identifying
a
participants
and
so
not
sensitive,
but
I.
C
Think
the
general
requirement
here
is:
let's
just
think
about
how
much
we
require
the
server
to
cache
versus
what
would
be
useful
for
it
to
cache
in
terms
of
distributing
information.
Finally,
traffic
analysis
mitigation.
It's
a
Bob's
point
about
what
we're
talking
about
mitigating
I,
think
the
intent
here.
I,
don't
think
anyone
at
least
I've
been
chatting
with
Alice
has
been
thinking
about
protecting
the
MLS
key
exchange
method
messages.
I
think
we
weren't
even
thinking
about
encrypting
those.
So
those
those
are
just
like
handshake
messages
that
the
system
can
see.
C
I
think
the
concern
here
is
traffic
analysis
mitigation.
With
regard
to
the
messages
that
would
be
protected
by
a
message:
protection
scheme
that
Benjamin
is
going
to
talk
about
in
a
couple
presentations
and
I
think
the
answer
is
roughly
what
I
forget
prior
person
said
that
we
should
have
some
padding
mechanism
in
here,
but
leave
it
to
the
applications
to
decide
how?
How
do
you
so.
B
To
summarize,
we
almost
all
agree
that
we
have
some
guidance
for
the
first
question
like
min
and
Max
style
should
prefer
other
devices.
I
guess
we
might
add
option
for
this,
but
I
still
continue
discussion.
For
this
part,
its
server
trust,
stewardship,
I
guess
our
conclusion
adjust
may
be
optional,
but
don't
require
per
se
and
the
last
one
we
should
include
some
include
some
can
even
but
it
leave
it
to
that
aside,
how
to
do
it.
Correct,
okay,
so.
P
P
What
we'd
like
to
do
is
do
a
working
group
adoption
hum,
so
if
you've
never
done,
this
I'm
gonna,
like
Nick,
do
the
actual
hum.
But
the
idea
is
that
we
have
an
individual
draft
now
and
we're
gonna
make
it
a
working
group
top
so
that
we
can
take
it
I
think
it
was
good
that
we
have
these
open
questions
because
it
shows
we've
got
work
to
do
so.
It's
not
fully
baked.
So
that's
that's
perfectly.
Okay,
but
we've
got
a
good
basis
of
a
place
to
start
there.
P
A
P
B
This
is
physically
specified
in
that
protocol.
Draft
I'm
gonna
quickly
explain
the
problem
and
the
solution
described
in
the
draft
and
again
open
question
then.
So
what
are
the
handshake
messages?
They
are
any
messages
change.
The
group
stays
like
group
in
each
other
ad
group.
Add
remover
update.
Each
handshake
message
is
based
on
the
current
groovy
state.
I
will
choose
a
pop
field
for
this.
Of
course,
conflicts
can
happen
if
two
or
more
clients
issue
a
same
handshake
message
on
the
same
group
state.
B
Usually
this
can
be
solved
using
server-side,
enforcing
or
client-side
enforcing,
in
both
approaches
that
might
call
the
starvation's.
So
a
given
client
may
not
be
able
to
send
handshake
message
because
it's
always
get
rejected,
so
we
understand
art
forces
Tekin.
However,
you
know
correcting
the
difference
more
in
the
next
presentation.
B
The
way
underst
client
first
identified
correct
me
if
I'm
wrong
it
spins
in
two
steps
we're
at
sea.
This
is
how
its
described
today
is
the
critical
draft.
The
client
proposes
the
update
first
and
since
update
if
it
gets
fifty
plus
percent
by
other
clients.
It's
a
question.
You
know
what,
if
most
of
the
clients
are
offline,
like
fifty
percent
from
the
online
user,
which
is
a
security
issue
or
how
it
works.
B
So
these
are
the
three
open
questions
about
this.
The
first
one
should
this
section
be
moved
to
the
optical
dock
instead
of
the
protocol
like
covering
this
message
or
drank
the
problem,
is
this
only
specific
for
any
protocol
that
has
shared
will
be
state
if
or
even
something
like
sender,
kids,
they
will
not
have
this
issue
so
the
question:
should
we
this
PR
overall,
in
the
pressure
block
or
not
again
back
to
the
server
the
server
divisive
is
Trust?
Is
the
delivery
service
trusted
to
enforce
our
drink?
C
So
yeah
I
think
it
would
be
good
for
the
architecture
document
to
have
a
very
clear
statement
on
this.
The
the
question
here
is
what
assumptions
the
protocol
document
can
rely
on
if
the
protocol
can
basically
assume
that
clients
are
presented
with
a
linear
sequence
of
handshake
messages,
that
dramatically
simplifies
the
client
logic
you're
going
to
have
to
put
put
into
your
into
your
stack
so
I'm
very
much
in
favor,
of
making
a
clear
statement
in
the
architecture
that,
whatever
the
delivery
service
is.
That's,
do
it
that's
providing
delivery
for
this
protocol.
C
It
ensures
that
all
of
clients
receive
handshake
messages
in
the
same
order,
and
that
frees
us
up
at
the
in
the
protocol
document
from
having
to
do
anything
about
what
happens
when
things
arrive
in
different
orders
at
different
clients.
This
is
a
simultaneous
at
or
simultaneous
update
question.
So
you,
okay
with
a
set
of
our
trusting
yeah
I,
am
comfortable
with
trusting
the
server
to
enforce
ordering.
C
I
I
would
be
comfortable
pushing
forward
with
a
solution
that
had
some
risk
of
starvation.
Doing
some
prototyping
dropping
again
getting
some
experience
in
real
ish
environments,
and
then
you
know
if
starvation
looks
to
be
a
problem
in
some
cases.
Looking
for
some
methods,
we
could
use
to
try
and
address
that
as
an
addition
to
a
baseline
protocol.
That's
linearly
oriented.
B
I'm
going
to
comment
that
the
concern
I
have
it
with
several
cross
to
death.
The
server
might
reject
a
specific,
a
bid
for
a
specific
client,
so
which
means
risk
is
the
PCs
for
specific
clients,
but
if
we
have
like,
if
we
do
like
bundles
update
with
the
message
itself,
this
means
that
mass
will
not
be
accepted
on
slaves.
Objects
is
accepted.
Okay.
This
is
just
an
idea.
K
This
is
d
kg
so
on
the
security
considerations,
side
back
on
14
and
says
modified
reordered
or
replayed
messages
must
be
detected
by
the
clients
in
the
event
of
delivery
service
compromised.
So
I
think
that
goes
to
what
Richard
was
saying
that
there
needs
to
be
a
detection.
I
confess
I'm,
not
sure
that
I
know.
B
K
So
I
confess
I
am
NOT
in
sure
that
I
understand
what
reordered
means
in
a
distributed
messaging
system
like
what
does
it
mean
to
say
that
the
that
the
server
if
the
server
reorders
the
message,
that's
detectable
by
the
clients
when
we're
talking
about
a
messaging
system
where
there
is
no
canonical
source
of
truth
about
when
the
message
was
originated?
Well,.
B
C
C
Think
the
risk
here
is
that
the
key
update
messages
are
premised
on
a
given
state,
and
so,
if
those
are
delivered
in
a
you
know,
in
an
order
that
doesn't
correspond
to
a
linear
evolution
of
states
and
or
if
they're
delivered
in
different
orders
to
different
clients
that
can
cause
clients
to
end
up
in
inconsistent
states
and
so
I
think
that's
the
type
of
reordering.
That's
the
concern
here
is
that
there's
not
a
consistent
ordering
in
terms
of
sorry,
if
all
clients
don't
receive
key
exchange
messages
in
the
same
order.
B
K
I
Obviously
word
of
them
in
anyway
of
leases
so
like
unless
you
men,
ISM
news
to
go
dater
because
I'm,
not
aware
of
so
so
so
I
mean
the
best.
In
that
respect,
what
we
can
do
is
we
can
guarantee.
Is
we
can
guarantee
that
the
messages
within
a
client
or
say
are
delivered
in
the
right
order?
Handshake
or
not
handshake
on
the?
Similarly,
like
the
server
can
obviously
suppress
that
you
know,
the
server
can
obviously
suppress
messages
from
any
client
it
chooses,
and
so
what
I
think
the
I
was
over?
I
Is
you
can't
selectively
suppress
handshake
messages
while
delivering
application,
their
messages
and
in
terms
of
being
able
to
detect
reordering
and
resolution,
then
that's
what
that
gives
you,
which
is
to
say
that
if
you
have
consistency
with
if
your
consistency
within
a
client
and
I
receive
like
you
know,
messages
two
three
and
five
and
they're
all
messages
and
then
Irish
I'm,
missing
message
for
that
I
know:
I
know
that's
been
deleted
and
and
then
you
have
to
like
come
with.
Why
did
the
server
not
delivered
that
now?
I
I
You
can
do
I
do
think
by
the
way
that,
on
to
Richard's
point
that
I
think
that's
totally
reasonable
at
this
point
to
say
we're
not
effect
if
we
trust
the
server
to
do
this
properly
and
then
attempt
to
detect
when
it
fails
to,
rather
than
try
to
build
a
system
which
operates
properly
in
the
face
of
an
arbitrary,
malicious,
all
right,
nobody
difficult!
Thank
you.
F
F
Asynchronously
sounds
a
bit
contradictory
happy
to
be
proven
wrong
there,
but
sounds
like
a
tough
problem
to
solve,
especially
if
you
don't
want
to
add
a
lot
of
overhead
and
the
other
option
would
be
if
ordering
is
not
really
that
necessary.
So
this
comes
down
to
art
or
tricking,
which
I
think
John
will
mention
later
so
for
art,
orderings,
absolutely
necessary
and
for
trick
em.
You
have
a
little
bit
of
flexibility,
some
messages
because
some
stuff
can
be
merged,
but
it's
it's
still
not
very
flexible,
so
I
think
in
practice.
F
The
the
best
solution
right
now
would
be
to
trust
a
server
for
that
and
regarding
the
starvation,
this
really
comes
down
to
the
scope
and
and
the
amount
of
messages
you
have
at
the
end
of
the
day.
So
this,
if
the
scope
is
really
only
the
handshake
messages,
personally
I,
don't
think
we
could
ever
run
into
starvation
frequently,
because
if
we
have
so
many
handshake
messages
that
many
participants
and
devices
send
them
out
at
the
same
time
constantly,
then
we
have
a
general
problem.
I
think.
L
Jonathan
I
was
just
think,
I
mean
I.
Think
the
question
with
starvation.
Is
you
want
to
make
sure
that
clients
can
distinguish
genuine
starvation
from
you
know
some
malicious
server
or
potentially
even
malicious?
Other
group
members
fault,
you
know
falsely
making
you
think
you're
being
starved
and
locking
you
out
of
the
column,
and
you
know
I,
guess
it's
it's
kind
of
the
same
DDoS
attack
you
just
you
know
denial
of
service
attack
just
by
dropping
the
that's
malicious
server,
but
I
want
to
make
sure
that
you
can
tell
a
malicious
server
from
genuine
starvation.
N
Bob
Moskowitz,
perhaps
I'm
showing
my
age
but
where's
the
state
machine.
They
were
talking
about
reordering
the
rest
being
important.
There
must
be
a
state
machine
here,
someplace
and
the
state
machine
should
handle
all
cases.
My
professor
way
back
when
forty
years
ago,
whatever
wouldn't
know
more
than
that,
would
not
let
me
do
anything
like
this
without
including
the
state
machine.
N
So,
if
we're
concerned
about
it,
we
should
be
able
to
talk
about
that
and
again
maybe
I'm,
just
showing
my
age
on
that
and
and
so
the
state
machine
would
then
tell
us
whether
we
can
trust
the
ordering
the
rest
of
it.
So
that's
why
I
say
about
that:
starvation.
That's
Doss
attacks,
so
he
has
a
real
problem
and
it
will
occur
so
again.
It's
how
do
you
recognize
and
understand
that
and
again
the
state
machines
just
show
that
again
showing
my
age.
Sorry,
thank
you.
J
John
Milliken
again
so
I
think
I
think
my
my
take
on
questions
two
and
three
is
one
of
it
would
be.
It
would
be
lovely
and
I,
don't
know
if
it's
possible
every
lovely
it
could
you
get
to
a
state
where
the
server
can
do
nothing
to
the
security
properties
without
actively
blocking
blocking
people's
messages.
J
So
obviously,
if
one
person
can
never
send
a
message
on
then
put
pcs
with
respect
to
that
user
is
is
going
to
be
compromised,
but
if
we
can
get
to
a
situation
where
so
long
as
everyone
in
intermittently
get
messages
through
global
pcs
can
advance,
then
that
would
be
that
strikes
me
as
the
property
that
we
should
probably
be
aiming
for
with
respect
to
them.
Okay,.
C
The
the
important
thing
to
preserve
is
the
order
at
which
messages
are
received
by
the
participants
and
that
you
can
easily
enforce
that
with
things
like
two-phase
commit
so
that
it's,
you
know,
there's
a
variety
of
mechanisms
where
you're
well
known.
We
can
use
to
preserve
that
property.
So
we
regard
to
starvation.
C
I
think
something
that
might
be
useful
to
do
here
is
to
have
kind
of
a
starvation
consideration
section
here,
because
another
thing,
I
might
trust,
did
the
server
did
you
Jonathan
mentioned
malicious
other
clients
trying
to
omit
a
lot
of
update
messages
so
that
no
one
else
can
advance
pcs,
and
that
is
something
where
you
could
have.
The
server
do
some
some
stuff
to
help
like
it
could
it
could
recognize
especially
active
clients,
or
it
could
recognize
that
you
know
this
client
hasn't
had
a
chance
to
update
in
a
while.
C
C
Finally,
I
wanted
to
end
with
a
question
the
thing
that
I'm
actually
surprised
hasn't
come
up
yet
is
Federation,
because
these
this
consistent
ordering
are
super
easy
to
implement
in
a
single
server
system.
You
just
have
a
lock,
and
you
know
you
wait
to
get
the
lock
a
free
transmit,
but
it's
harder
to
implement
in
federated
systems
where
you
might
need
collaboration
among
domains
to
synchronize
when
messages
can
be
transmitted.
So
I'd
be
interested
to
hear
from
folks
who
are
interested
in
that
use
case.
S
No
I
can't
ask
you
mara,
4:17
G
for
them.
Speaker
I
may
have
misunderstood
the
problem,
so
apologies
ahead,
but
with
respect
to
messages
and
ordering
when
we're
talking
about
end
to
end
and
I,
guess
that's
what
we're
trying
to
achieve
here.
Server
here
is
strictly
to
facilitate
certain
things.
So
when
we
talk
about
security
and
it's
the
service
roles
in
all,
this
is
to
harden
the
model
not
necessarily
to
make
it
secure.
S
And
therefore,
when
we
talk
about
the
order
of
messages,
I
see
two
types
of
messages:
messages
that
are
specific
to
a
state,
in
which
case
like
the
gentleman
mentioned,
a
state
machine
or
crypto.
A
cryptographic
binding
to
that
state
is
important
and
that
solves
the
problems
of
server
trying
to
mess
around
over
the
order
with
messages
that
don't
really
affect
the
ordering
just
need
to
get
there.
S
That's
a
different
problem,
so
I
think
it's
important
to
separate
the
space
of
the
type
of
messages
go
through,
because
some
messages
need
to
tie
to
our
specific
to
state.
Some
are
not,
and
those
are
are
tied
to
speak
to
a
state
need
to
be
somehow
bound
to
that
site.
Either
cryptographically
on
earth
rather
means
so
you're.
Sort
of
this
is
to
the
point
where
the
server
is
just
facility
and
transfer
instead
of
an
insurance
and
security
properties.
T
All
right,
if
you
want
so
I,
was
thinking
about
your
question
about
federated
the
case
and
I'm
wondering
whether,
since
this
is
human
communication,
whether
it
might
be
enough
to
to
be
able
to
inform
the
user
that
there
is
sort
of
that
the
various
end
points
who
don't
agree
on
the
on
a
particular
message
order.
And
so,
if
you
can,
if
you
can,
even
if
you
can
show
that
right,
we're
and
that
might
be
enough
in
the
Federated
case
right
I'm,
not
entirely
sure
you
have
to
force
ordering
in
for
every
case.
T
But
as
long
as
the
user
knows
that
there
is
contention
contention
in
a
perfect
particular
case
about
a
pair
of
messages.
Right
this,
your
your
the
whoever
used
your
chatting.
We
believe
that
they
are
actually
in
the
different
order.
You
may
have
to
work
that
out,
but
since
this
is
human
to
human,
maybe
your
config,
maybe
that's
enough.
S
So
my
talks
in
one
more
comment:
respect
servation
is
I
may
be
wrong,
but
there's
not
much.
You
can
do
them
in,
depending
on
the
capabilities
of
your
attacker
and
adversary
right.
If
they
can
control
the
network,
they
can
potentially
compromise
the
server
because
the
server
is
sort
of
less
trusted.
I
was
just
mentioned
that
probably
one
includes
a
mechanisms
where
a
client
understands
that
he
was
not
able
to
participate
in
their
ecosystem
for
a
period
of
time,
at
which
point
he
refuses
to
participate
at
all.
S
To
say
that
you
know
what
I
wasn't
able
to
persuade.
Therefore,
I
have
no
trust
in
the
system
anymore
and
I'm
gonna
back
out
until
some
recovery
mechanism
is
in
place.
So
this
is
to
say
that
you
can't
control
the
world,
but
the
client
can
say
you
know
what
I'm
gonna
be
defensive.
I'm
not
gonna,
participate
if
it
doesn't
play
by
the
rules.
U
Brian,
why
is
cisco,
so
traditional
group
security
systems
do
tend
to
trust
servers
and
have
a
lot
less
trust
in
the
clients,
and
I
sense
from
this
effort
that
it's
all
the
way
just
flipped
around
they're
the
direction,
we're
trying
to
trust
clients
and
not
the
servers
and
I
think
that's
not
clear
at
all
in
the
architecture
and
even
not
in,
for
example,
the
second
question
here:
I'm,
sorry,
don't
trust
anybody,
so
so
I
think
that's.
That
is
even
more
important
that
the
architecture
itself
needs
to
take
that
statement
and
make
bounced
around
around.
U
J
John
Milliken
again
just
in
response
to
Michael's
point
about
clients
deciding
that
they
have
been
locked
out
for
long
enough
and
they're
gonna
stop
responding
I
think
some
of
the
offline
discussions
I've
had
with
people
about
this
in
discussing.
Maybe
if
the
protocol
can
automatically
expire,
clients
which
have
been
silent
for
long
enough
can
so
rather
than
the
client
deciding
that
it's
going
to
kick
itself
out.
Everyone
else
decides
that
they're
going
to
keep
the
client
tabs
for
the
purpose.
I.
B
Mean
that's
why
this
cool
okay,
so
that
we
understand
the
answers
are
its
yes.
For
the
first
question
for
the
second
question:
the
server
is
trusted
to
do
the
functional
delivery
or
the
function
Orion,
but
to
the
security
semantics
so
and
if
there
is
any
compromised
from
the
server
should
be
taken
by
the
client
it
was
ever
did
anything
with
this.
The
client
should
be
able
to
detect
it
somehow
to
understand
correct.
B
Starvation,
when
I,
when
I
mentioned
summation
here,
I
meant
innocent
distillation,
like
functionary,
should
not
attack
voiceover
attack
by
the
by
other
means,
because
both
of
them
are
at
the
addressed
in
succession.
Dr.
Beane's
cannot
deal
with
other
peers
and
was
the
idea
we
have
with
minimum
and
Max
and
the
update.
This
should
solve
this
problem.
You
can't
really
actually
issue
up
this
all
the
time.
B
C
I
was
just
gonna
say
as
author
of
the
protocol
document,
which
is
not
yet
adopted,
but
maybe
in
the
future
the
less
is
the
takeaway
I'm.
Getting
here
is
that
you,
the
architecture,
is
going
to
document
this
requirement
that
the
delivery
service
provide
a
consistent
delivery
order
for
handshake
messages
to
clients
and
I'm
going
to
rely
on
that
in
the
protocol
document.
Yeah.
C
S
C
J
Cool
so
I'm
just
gonna
talk
about
that.
The
big
open
question
of
what
should
lay
at
the
heart
of
the
protocol
we've
got
two
proposals
at
the
moment
are
tan
and
tree
kam,
and
this
whole
thing
is
an
open
question,
rather
than
the
specific
specified
open
questions
at
the
end
of
em
had
slides,
please
pop
up
and
ask
questions
at
any
point,
so,
first
to
just
kind
of
refresh
us
on
what
the
various
operations
be
able
to
support
at
so
we've
got
group
states
stored
in
somewhere.
J
Both
the
proposals
at
the
moment,
own
key
trees
of
various
forms
and
every
participant
cache
is
some
view
of
the
tree
and
then
the
operations
that
we
have
to
have
are
being
able
to
create
a
group
at
users.
Users
add
themselves
to
the
group:
users
update
their
own
keys
in
the
group
and
being
able
to
remove
users
from
the
group.
So
this
is
just
the
key
exchange
protocol.
It's
somewhat
divorced
from
the
messaging
itself,
so
the
first
protocol,
but
to
borrow
my
slides
from
the
buff,
is
called
asynchronous.
J
J
We
have
proofs
in
the
paper
linked
of
the
confidentiality
of
the
group
keys
in
this
setting
only
for
static
groups
this,
but
this
paper
does
not
fully
prove
art,
as
used
within
the
MLS
protocol
doc,
but
it's
partway
there
and
within
MLS
we've
actually
defined
some
things
that
were
left
out
of
scope
in
the
original
paper.
So
we
have
additional
constraints
and
the
tree
structure.
J
This
is
just
an
example.
We
do
not
recommend
this
in
practice
to
know
terminology
here.
So
with
respect
to
see,
we've
got
a
bunch
of
terms,
so
we
have
obviously
the
roots
of
the
tree.
We've
got
the
direct
path
which
is
in
bold,
so
that's
C
and
all
of
its
ancestors.
We
have
the
KO
path,
which
is
the
sibling
of
all
of
Steve's
ancestors
and
then
the
frontier,
which
would
be
the
siblings
of
all
of
the
ancestors
of
a
hypothetical
Mew
key
to
be
added
to
the
tree.
J
J
So
the
tree
root
is
KDF
t'
in
to
the
existing
group,
ratchet
etcetera,
etcetera.
So
we
don't
just
require
the
correct
tree,
but
we
require
the
correct
order
of
trees
as
well,
so
the
first
operation
create
group
is
very
little
to
talk
about
this.
A
has
a
different
key
and
that's
pretty
much
it
in
the
art
paper.
We
defined
this
as
starting
with
a
pre-existing
group
in
MLS.
We
don't
do
that,
yet
we
just
assume
it's
the
one
member
groups,
that's
very
difficult
to
talk
about
this.
J
J
At
this
point,
they
take
an
init
key.
These
are
also
known
as
pre
keys
and
of
the
protocols
which
has
been
pre
published
by
the
user.
That's
going
to
be
added,
they
generate
a
difficult
and
key
which
they
then
publish
alongside
the
init
key
and
from
this
the
user
can
generate
the
the
rest
of
the
tree,
so
they
also
have
to
publish
the
path.
J
J
The
next
option
is
the
user
initiated
add.
So
this
is
d
adding
themselves
to
the
group,
as
the
the
frontier
has
already
been
published,
all
D
has
to
do
is
perform
the
the
diffie-hellman
with
its
own
key,
it's
fairly
straightforward
for
PCs.
This
is
when
someone
wants
to
rotate
their
key
pcs
being
post
compromised
security.
J
This
has
some
intricacies
that
have
admitted
from
this
slide,
but
we
essentially,
we
have
a
double
join
problem
where
you
now
have
whoever's
evicted.
The
other
member
now
knows
some
of
it,
some
other
node
in
the
tree.
So
if
they
were
to
be
removed,
they
would
still
have
access
to
some
state
of
the
tree.
In
the
protocol
dock,
we
talked
a
bit
about
how
we
can
address
this,
so
as
an
alternative
to
this
bonds
occur
and
Karthik
came
up
with
this
alternative
approach.
Tree
can
so.
J
This
is
a
new
primitive,
as
opposed
to
the
diffie-hellman
key
tree
which
we
were
used
in
art,
whereas
art
used
diffie-hellman
x',
which
are
contributed.
They
require
both
of
the
children
to
contribute
something
to
the
key.
This
is
non
contribute
'iv,
so
every
node
or
every
parent
node
is
derived
from
just
one
of
its
children.
J
This
tree
structure
is
the
same,
but
we
have
a
couple
of
potential
big
improvements,
one
of
them
and
which
I
think
was
the
main
motivation
behind
this
design
is
that
multiple
updates
can
now
be
potentially
merged
without
conflicts,
because
the
non
contributor
bertie
means
that
no
one
needs
to
know
one
of
the
two
children's
private
keys
to
update
any
given
parent
and
also
because,
as
I
will
cover
in
a
sec,
the
keys
are
derive
by
hashing
one
of
the
children
keys.
Once
you
know
one
of
the
private
keys,
it's
pretty
much
an
o1
operation.
J
So
the
way
this
works,
we
have
a
new
derived
key
pair
operation,
which
mats
a
random
bit
string
to
a
public
key
pair.
But
this
is
a
public
key
to
use
for
encryption,
rather
than
key
exchange
could
still
be
difficult,
and
that
doesn't
have
to
be.
We
have
a
strapped
away.
The
specific
algorithm
and
so
you'll
see
here
that
you've
got
this.
The
parents
is
hash
of
a
B.
P
doesn't
come
into
a
digital.
J
So
this
is
what
the
tree
looks
like.
The
various
definitions
are
exactly
the
same,
but
you'll
see
that
you've
just
got
different
values
here
so
see
in
this
instance,
was
the
most
recent
person
to
update
so
C's
key
is
represented
at
the
top
was
at
each
stage
of
the
tree
you
have.
The
node
was
derived
from
one
of
its
children,
I
think
I
just
always
went
for
leftmost
apart
from
see.
Example.
J
J
So
in
this
instance
to
have
a
group
initiated
add
you
generate
an
add
key.
This
is
just
a
random
sequence
of
bits.
You
encrypt
that
add
key
to
the
new
user
using
that
init
key.
So
that's
this
ciphertext
add
key
in
the
structure.
You
calculate
the
sequence
of
private
keys
and
public
keys
up
up
its
path,
and
then
you
publish
all
of
the
public
keys
in
the
path
keys.
J
Sorry,
you
publish
all
of
the
private
keys
in
the
path
keys,
having
encrypted
them
to
their
sibling.
So
in
this
example,
Javad
key
is
encrypted
to
cv
and
hash.
Squared
of
ad
key
is
encrypted
to
the
hash
of
a
is
public
key,
and
this
allows
everyone
to
calculate
that
calculate
the
route
with
just
one
single
decryption.
J
So
the
next
operation,
the
user
initiated
out
this-
is
again
pretty
similar
to
art.
So
it's
just
deers
adding
themselves,
so
they
take
their
own
randomness
hash
it
up
the
tree,
encrypts
the
relevant
hashes
to
the
private
so
to
the
public
keys
of
the
other
children
and
DS
key
is
now
at
the
root
of
the
tree
for
an
update.
J
So
if
we
imagine
in
this
situation
that
a
had
had
been
the
most
recent
person
to
update
at
the
point
that
B
now
sends
their
update
again,
the
root
to
the
path
is
just
completely
rewritten
completely
unrelated
to
what
it
was
then.
Finally
remove
we're
looking
at
exactly
the
same
processes
in
art
just
send
out
an
update
for
someone
else's
key.
J
So
the
key
comparisons
here
are
so
first
in
the
update
complexity.
So
where,
as
art,
every
update
is
essentially
a
log
in
operation.
Pretty
much
everything
in
art
is
log
n
tree
cam
updates
a
log
n
for
the
updater,
but
they
are
just
there.
Oh
one
in
terms
of
expensive
operations
for
everyone
else
in
terms
of
concurrent
updates
because
of
the
non
contribute
ility,
it's
much
easier
to.
Imagine
multiple
updates
being
handled
at
the
same
time
and
having
some
decision
to
which
wins
without
having
to
discard
any
in
its
entirety.
J
We've
got
a
bit
a
best,
slightly
better
idea
of
arts
properties,
but
that
is
incoming
for
Trika
I
believe
open
issues
with
both
this
is
the
same
as
it
was
with
art,
so
we've
got
to
prove
the
various
operations
security
within
the
model
that
we
want
figure
out.
The
logistical
details
around
removing
massive
sequencing
mess,
various
other
topics
which
have
been
covered
earlier
or
will
be
covered
later
today,
also
attachments.
J
C
Yes,
I
think
the
salient
question
for
the
for
the
moment.
You
know
what
we
need
right
now
in
order
to
keep
the
protocol
moving
forward.
Just
a
kind
of
tea
at
the
discussion
for
everyone
is,
we
need
to
decide,
you
know
which
of
these
or
both
we
want
to
move
forward
with
so
in
the
the
rev
of
the
drought.
C
With
the
protocol
draft,
we
we
produced
for
this
meeting
I
just
put
in
a
switch
and
said
you
can
do
either
of
these
as
the
inner
loop
of
your
MLS,
you
know
either
you
can
have
an
MLS
route
based
on
here.
It's
here
you
can
have
one
based
on
on
Sri,
Kim
and
I'm.
Guessing
that's,
probably
not
the
optimal
outcome,
so
I
realize
we
might
need
to
do
some
more
verification
about
the
the
properties
of
some
of
these
algorithms,
but
I'd
like
to
know
like
it
seems
like
these
are
pretty
easily
swappable.
C
So
maybe
we
can
proceed
with
one
while
we
do
that
verification,
so
I'd
be
interested
to
hear
you
know
whether
people
think
we
should
pick
one
or
keep
both
and
if
we
should
pick
one
which
one
we
should
operate
with
for
the
moment.
So
personally,
a
back
on
your
you're
sailing
a
comparison
points
slide.
I
am
less
concerned
about
the
concurrent
update
benefits.
Now,
given
the
last
discussion
we
had.
C
You
know
language
to
say:
here's
the
set
of
updates,
I
have
merged
and
I'm
using
that
for
this
epic,
so
I
think
it
introduces
a
lot
of
complexity.
So
I
think
the
the
primary
advantage
to
me
here
is
in
the
the
performance
difference
and
that
that
even
that
I
think
comes
with
a
cost,
because
tree
cam
requires
several
more
primitives
having
your
code
you're,
not
just
doing
d-h.
You
also
need
a
public
key
encryption
primitives,
so
it
seems
like
there's
some
drop
back
there
too.
C
J
H
Laughs
laughs.
Thank
you.
I
really
think
that
both
constructions-
worse
considering
I'll
just
want
to
at
one
point
that
tree
came
if
we
could
be
sure
that
it's
really
secure
regarding
assess
properties
has
one
more
advantage.
It's
much
easier
to
build
implementations
as
it
is
resistant
to
side-channel
attacks,
because
we
really
have
much
less
public
equations
in
some
points
that
can
be
quite
frequent,
so
I
think
we
really
need
to
try
to
evaluate
and
assess
tree
campuses.
I
think
that
may
be
safer.
H
Gee
I
can
help
asserted
that
can
be
pushed
to
safer,
G
and
personally
I'll
be
happy
to
try
to
calculus
and,
as
it
was
mentioned,
both
constructions
seem
to
be
more
or
less
equivalent
it
in
the
set
of
interfaces.
So
we
can
proceed
with
without
choosing
one
or
another
one
right
now,
but
if
we
could
prove
all
properties
of
chicken
really
personally
I
prefer
it
as
construction,
Thank,
You
pecker,
let's
go
to
Benjamin
Karthik
and
what
are.
A
D
Everyone
I
guess
it's
I,
don't
know.
Can
you
hear
me
this
time?
Yes,
okay,
so
I
actually
I,
don't
think
I
agree
with
with
Richard
on
this
I
think
we
we
should
actually
keep
both
constructions
in
the
spec
right
now,
because
it's
we
still
need
a
lot
of
analysis
right,
busan,
art,
because
it's
been
studied
only
for
static
groups
and
for
trick
em
and
I
don't
see
an
actual
drawback
in
keeping
both
in
the
spec
at
the
same
at
the
moment,
that's
it
Thanks.
O
O
D
I
I,
despite
the
fact
they
the
system
requires
consistency,
it
doesn't
require,
doesn't
require
complete,
lockstep,
behavior
and
so
the
impact
of
having
the
one
at
a
time
updates
of
art
is
going
to
be
an
enormous
number
for
any
large
grouping.
An
enormous
number
of
rejected,
updates,
they're
predicated
on
the
previous
crypto
state
that
they
give
bounce
back
and
figure
any
significant
message:
latency
and
a
significant
rate
of
rate
of
key
Church.
I
What's
difficult,
there's
knowing
when
you
can
discard
the
keys
that
are
that
required
to
basically
it
against
the
next
a
buck.
So
you
know
I'm
at
box
zero,
and
you
know
that
includes
and
then
includes,
basically
updates,
ABC
and
D.
Then
at
some
point,
I
say
well
I'm
in
order
to
process
a
you'll
get
a
and
you
have
to
keep
that
you're
like
epic,
zero
plus
a
and
you
know,
and
then
in
order
to
process
B,
you
have
to
have
the
zero.
I
I
On
the
other
hand,
we're
also
not
frozen
ship
to
protocol
today,
so
ho-hum
I
think
we
ought
to
do
is
operating
the
assumption
that
both
of
these
are
secure,
which
may
be
false
but
operated
as
a
moment
on
and
attempt
to
attempt
to
sort
of
work
out
as
soon
as
possible.
What
this
our
operational
details
of
each
one
of
them
is,
and
if
we
convince
ourselves
that
which
one
ever
only
thing's
operational
superior,
we
should
like
cross
the
other
one
on
the
draft
and
put
it
in
some.
J
V
Binky
doc,
as
responsible
ad
just
I,
want
to
point
out:
please
do
not
send
the
document
to
Dyess
today
is
GE
that
has
both
options
in
it.
Unless
you
have
some
like
compelling
difference
between
them,
that
would
cause
even
want
to
pick,
and
you
know
if
that
means
keeping
both
in
the
document
and
it's
low
per
coin
after
work
last
call
I'm
totally
fine
with
that.
F
Raha
Robert
again
so
just
want
to
emphasize
the
update
complexity
and
the
last
slide
here
so
particularly
for
passive
participants,
which
is
all
of
them
except
the
sender.
There
is
a
huge
performance
difference
between
art
and
tree
cam,
and
we
were
saying
earlier
that
we
might
want
to
have
some
recommendation
on
how
frequently
keys
should
be
updated
so
in
large
groups,
and
we've
been
talking
about
up
to
50,000
so
far.
That
will
lead
to
a
lot
of
handshake
messages,
a
lot
of
updates
that
all
need
to
be
processed
by
all
participants.
F
All
the
time
before
you
can
actually
even
decrypt
the
next
message.
So
that's
a
very
high
load
during
an
idle
time.
Basically,
even
if
nobody
is
really
writing
anything
so
trinka,
Muses
hashes,
which
are
incredibly
fast
compared
to
public
key
operations
or
diffie-hellman
operations
like
in
art,
so
I
think
this
is
something
we
should
absolutely
keep
in
mind.
And
right
now,
a
tree
can
on
the
performance
side
seems
to
stand
out
quite
a
bit.
Absolutely.
C
So,
just
to
compound
the
issue:
Zekrom
ention,
this
is
Richard
Barnes.
In
addition
to
the
when
do
I,
throw
away
state
question,
if
you
allow
concurrent
updates,
you
also
have
a
question
of
what,
when
I
want
to
update
myself,
what
state
do
I
build
on
top
of
I
mean
in
in
the
worst
case
here
you
can
imagine
this
branching
tree
of
states
that
everyone
has
to
has
to
maintain.
I
C
I
C
C
Yes,
and
so
you
know,
you
do
have
to
have
kind
of
a
convergence
algorithm
to
decide
on
which
of
those
states,
because
you
need
for
them
to
choose
consistently,
or
else
you
get
ramification
so
that
that's
one
observation
I
had
another
one,
but
I've
forgotten
it.
The
way
forward
I
was
going
to
propose.
Is
that
I
think
we're
going
to
propose
at
the
end
of
meeting
we
get
together
in
September
and
talk
about
things?
C
I
think
one
thing
it
might
be
useful
to
do
is
kind
of
keep
this
ambiguous
until
then
and
like
try
and
do
some
initial
code
see
how
big
the
performance
difference
is
see.
How
big
the
message
size
differences
are,
and
so
we
can
kind
of
take
some
quantitative
measurements
to
see
how
the
different,
how
bad
the
differences
look
and
I've
just
remembered.
The
other
point
I
was
going
to
make,
which
is
I.
C
Think
one
I'm
not
sure
if
you
mentioned
this
or
you
mentioned
they
have
the
same
underlying
tree
structure,
which
seems
to
indicate
that
they
can
be
hybridized,
which
is
probably
pissing
off
catriel
and
Karthik
even
more
than
they
already
are.
But
you
know,
if
we
see
that
say
you
know,
updates
are
going
to
be
super
frequent,
and
so
we
want
them
to
be
performance
and
we're
willing
to
take
message
overhead,
for
that.
Maybe
we
use
tree
CEM
for
update
messages,
but
for
adds
and
deletes.
C
We
use
a
rt4
because
we
want
them
to
be
small,
I
mean
I.
Don't
have
a
preferred
solution
here,
but
I'm
just
wanted
to
point
out
that
that
those
solutions,
I
believe,
are
possible.
If
we
can,
you
know
dot
the
I's
and
cross
the
t's
and
you
know
convince
the
a
week
we
get
assurance
from
the
academics
that
it's
okay
to
do
that.
So.
C
B
B
J
A
D
Good,
okay,
sorry,
okay,
so
right
now,
so
I'm
gonna
discuss
a
bit
of
message:
protection
which
is
currently
not
in
the
draft
next
slide.
Please
again,
please
thank
you.
So,
right
now
in
the
in
the
the
protocol
document
are
basically
nothing
about
message,
protection,
which
is
obviously
a
big
part
of
what
we
want
to
achieve
here.
D
So
there
are
multiple
possibilities
about
that.
We
could
actually
to
include
the
message
protection
part
inside
the
protocol
spec
or
we
could
do
it
with
side.
My
personal
opinion
is
that
we
could.
We
could
put
that
in
the
photo
calls
back
because
it
sort
of
makes
sense,
but
we
need
to
define
anything
so
the
the
main
point
of
message
protection
right
is
to
go
from
the
unshaken
schedule.
D
That's
been
shown
by
many
people
before
to
go
to
the
let's
say:
let's
call
it:
the
applications
be
scheduled
so
basically
going
from
the
epic
secret,
the
group
epoch
secret
to
the
encryption
of
application
messages,
and
to
do
that.
We
did
this
schedule,
this
application
key
schedule
and
we
need
a
set
of
algorithms
and
to
define
the
objects
with
that.
We
really
want
to
encrypt
right.
D
Next
site,
so
that's
the
current.
That's
what
he's
currently
in
the
protocol
spec
right
on
shaky
schedule.
So
basically
it's
does
work
for
both
after
and
3
km.
It's
completely
sort
of
separated,
because
the
update
secret,
as
you
see
on
the
left,
is
generated
from
the
hood
secret
of
the
trick,
M
or
arteries.
D
Then
you
derive
a
goopy
goopy
pop
secret,
which
is
basically
the
most
important,
the
most
important
part
of
the
protocol
of
the
of
the
secret,
because
everything
in
the
Hoopoe
Park
is
going
to
be
based
on
that
thing.
So,
depending
on
the
security
properties
that
wants
we'll
need
to
keep
that
around
or
not
for
a
certain
time.
It's
it
on
right.
Now
the
message
master
secret,
which
is
which
I
called
the
application
secret,
because
it's
it's
at
the
moment,
used
to
to
compute,
keys,
etc,
is
the
most
important
parts.
D
Most
application
messages
is
obviously
dependent
of
the
of
debug
secrets
in
terms
of
security.
Next
slide,
please
so
from
this
application
secret
we
could.
There
are
too
many
ways
of
deriving
keys
right.
We
could
do
many
things.
We
could
directly
hatch
this
application
secret
or
we
could
expand,
extract
and
explain
this
this
secret
to
get
a
Adi
GG's.
D
You
could
even
directly
imagine
instead
of
having
this
application,
this
application
secret
hack
tatted.
You
could
imagine
instead
having
directly
expanding
all
the
entries
for
the
end
participants
at
that
point
and
I'll
explain
why
it's
actually
a
different
approach,
which
has
different
security
properties.
So
if
you
consider
that
you
have
this
application
secret,
there
are
multiple
ways
of
going
right.
You
can
directly
who
hatch
at
this
group
secret
this
application
secret
in
two
ways,
either
in
interleaving,
thus
under
contribution
or
in
parallel,
meaning
that
you
can
either
for
this
application.
D
If
you
had
one
forged
client
and
an
hard
set
independently
these
this,
these
secret
chains-
or
you
can
ask
for
each
a
participant
to
each
sender,
to
Hajj,
set
its
next
message.
Key
from
that,
from
the
same,
who
touch
it
and
those
are
very
different,
very
different
properties
in
terms
of
the
security
properties
as
some
sort
of
the
same,
but
the
forward
secrecy
is
not
exactly
the
same
because
you
need
to
keep
around
more
more
things
in
the
case
where
you,
your
watch,
set
per
participant.
D
So
here
is,
for
example,
it's
a
completely
example.
Nobody
thing
is
in
the,
but
nothing
is
set
yet
and
we
discussed
there
are
many.
There
are
basically
as
much
as
as
much
as
many
different
key
schedule
as
you
want,
but
there
are
basically
these
two
categories
of
person
who
had
set
of
box
on
the
hatchet,
so
it
is
an
example
of
who
pockets.
D
You
have
like
the
initial
application
secrets
from
which
you
derive
the
sender,
authorize
an
AGP
and
unknowns,
and
this
application
secrets
is
going
to
be
hot
shattered
in
a
way
that
each
sander
is
going
to
contribute
to
that
hatchet.
So
this
is
this:
is
nice
because
it
so
loose
to
group
each
participant
to
keep
one
who
project,
but
it's
actually
bad,
because
it
it
forces
sequentiality
of
the
of
the
updates
right.
So
in
some
sense
it's
a
it's
not
good
for
for
parallelism,
and
it's
actually
it's
very
wrong
for
for
out
of
order.
D
You
can't
really
do
it
about
messaging
out
of
this
thing
next
slide,
please,
and
then
you
have
the
the
per
participant
case,
so
you
can
next
slide,
please,
where
you
could
actually
from
the
initial
group
application
secrets,
derive
many
applications,
initial
application
secrets,
one
top
participant
and
Hutch
said
this
participant
application
see
catch
instead,
meaning
that
is
no
completely
independent.
It
sits
under
as
it
one
hot
shot.
Basically,
what's
mostly
what
is
done
in
current
protocols
right
you,
you
had
set
independently.
D
Of
course,
we
don't
have
the
experience
of
multi-party
but
large
experience
of
beauty,
a
large
number
of
participants
in
in
groups,
but
the
for
that
scenario.
The
drawback,
the
benefit
is
that
you
can
actually
encrypt
in
in
parallel
and
send
messages
in
parallel
out
of
order,
even
if
you
skip,
if
even
if
you
here,
there
are
two
messages
from
the
same
sender
as
long
as
you
keep
the
key
n
minus
1,
you
can
recompute
n,
n,
plus
1
and
plus
2.
D
The
the
obvious
thing
is
that
this
is
for
what
you
could,
but
this
is
not.
This
does
not
have
pcs
right
because
you
are
sitting
forward,
doesn't
give
you
pcs
only
changing,
and
in
that
way,
if
you
want
pcs
for
messages,
you
only
can
hatch
at
the
you
need
to
update
the
group
secret
deepak
secret,
so
that's
very
different.
So
there
are
three,
basically
the
very
different
approaches.
D
D
You
can
basically
have
forward
secrecy
for
the
keys
of
the
the
keys
for
messages,
but
you
don't
have
pcs
until
you
refresh
to
group
secret.
That's
that's
my
understanding.
Next
next
slide,
please
so
that
so
the
study
I
showed
before
was
basically
TLS,
based,
meaning
that
there
is.
Can
you
go
back
sorry
and
there
is
a
from
the
application
secret.
You
actually
F
expand
level,
an
AGG
and
an
HIV.
So
that's
really
useful
because
it's
a
it's.
It's
good
for
misuse!
D
D
So
that's
very
TLS
based
because
it's
a
it
has
like
the
right
key
and
the
right
AV
that
are
mixed
in
back
into
the
application
secret
ratcheting
chain,
and
there
is
the
the
next
slide
and
there
is
a
proposal.
That's
been
done
that
boost
proposals
are
actually
input,
requests
right
now
on
the
on
the
repo.
This
is
a
proposal
from
alexei
that
basically
is
very
similar.
It's
a
powerful
participant
hatchet,
where
small,
like
signal
in
some
sense
why
you
expand
both
the
change
secret
message,
key
nonce
and
you
change
the
chain
secret.
D
D
Next,
please
so,
as
I
said,
basically
to
balance
and
I,
don't
see
any
good
way
of
solving
that
problem
now.
So
it's
it
needs
a
lot
of
description.
I,
don't
think
it's
ready,
but
I'm
pretty
sure
we
can
do
something
that
works
and
I
think
everybody
is
convinced.
After
the
discussions
we
had
with
each
other
informally
that
we
can
make
it
using
any
of
those
ways,
but
it's
unclear
what
the
exact
security
properties
are
at
the
moment.
D
So
we
need
to
define
them
more.
So
goes
group
hatching
you
reduce
complexity,
you
improve
so
for
what
secrecy,
in
the
sense
that
you
don't
keep
around
application
secrets
per
participants.
If
you
don't
use
them
because
you
watch
it
everything,
so
you
only
one
such
application
secrets-
that's
that's
updated
frequently,
but
it
doesn't
handle
out
of
order
and
it's
the
opposite
for
the
perversion
or
the
profit
thing.
D
One
we
can
forward
secrecy,
okay,
so
that's
a
sort
of
abusive
term
saying
that
you,
you
are
for
what
secret,
but
the
the
the
the
duration
in
time
where
you
keep
the
keys
is
different.
If
you
keep
the
keys
for
like
two
weeks
without
updating
the
group
secret
or
like
two
years
or
whatever
you,
you
still
have
for
you
as
long
as
you
are
for
what
you
cut,
it's
fine,
but
the
way
you
have
to
store
the
keys,
you
have
to
keep
them
for
a
long
time.
I
I
D
I
Keys
which
don't
used
to
encrypt
anything
so
I
think
keep
them
around
is
probably
ok,
I,
guess
that
maybe
was
some
formal
property
referring
to
but
I'm,
not
following
with
actual
security
property.
You're
trying
to
talk
about
it
so
maybe
be
able
to
I
mean
III.
Guess
it's
probably
not
practical
to
do
at
this
particular
point.
Ok,.
D
Mean
anyway,
I
do
agree
that
the
participant
1
is
the
abuse,
is
a
preferable
choice.
I
mean
in
my
opinion,
but
I
didn't
say
that
ok
can
I
go
on
a
you,
have
one
more
slide
and
then
ok
can
you
go
to
slide
11
next,
one
again
the
getting
the
next
one
again,
please,
oh
yeah,
this
one.
Okay,
so
there
are,
as
I
said,
there
are
two
to
pass.
We
need
to
handle
the
application
fee
schedule
and
the
message
protection
itself
yeah
the
encryption
I
think
for
for
for
the
message
inscription.
D
We
can
use
very
straightforward
things
like
AIG
encrypted
voicing
as
discussed
before
in
emerge.
Talk
I.
Think
there
is
the
padding
issue,
so
I
wrote
some
initial
text
in
a
pull
request
and
I'm
in
favor
of
as
I
said
before,
I'm
in
favor
of
patting
I
mean
I'm
in
favor
of
MLS,
providing
a
mechanism
and
leave
it
to
the
application
to
decide
all
to
use
it.
But
my
point
is
that
we
should
not
like
lick
the
length
of
the
application
they
suggest
to
everyone
for
which
for
4h
encryption
and
then
they
are
depending
on.
D
Oh,
you
want
auntie
Kate.
Currently
the
the
authentication
is
done
by
using
signatures,
depending
on
oh
you,
authenticates.
There
are
things
that
you
should,
but
inside
the
ciphertext,
or
not
typically
right
now
having
the
signature
for
authenticating
the
participant
strongly
meaning
knowing
which
educating
the
specific
parties
a
specific
center
to
other
parties.
Members
of
the
group
is
done
using
signatures
in
the
current
setting.
D
We
can
actually
encrypt
that
signatures
in
patches
inside
the
ciphertext
and
it
could
be
safe
because
we
have
an
implicit
or
education
for
party
on
the
fact
that
if
you
can
decrypt
the
ciphertext,
it
means
you
have
the
idea,
the
IAD
keys
to
decrypt
the
ciphertext
meaning
you
are
a
member
of
the
group
and
that's
all
next
next
slide.
I
think
so
in
a
way
to
move
forward
is
I.
Think
since
now
we
have
nothing
in
the
in
the
text.
D
Safe
approach
would
be
to
defeat
to
define
an
initial
message:
protocol
protection
text,
where
we
use
something
very
straightforward,
that
I
think
people
can
reasonably
agree
on
typically
having
like
per
participant
purchasing
scheme
using
ahd,
ciphers,
optional,
padding
and
optional
signature
of
the
of
the
plaintext.
In
the
ciphertext-
and
there
are
basically
two
pull
requests
on
the
on
the
on
the
specs.
That
Poe
is
that
and
I
see
cam
done.
C
C
Could
we
skip
back
to
that
slide
as
I
figure,
it's
probably
going
to
be
nope
forward
the
comparison
one
that
one
for
me,
the
kind
of
killer
app
for
the
group
ratcheting
is
the
reduced
storage.
If
I'm
in
a
10,000
person
group
in
order
to
get
any
forward
secrecy,
I
have
to
generate
and
store
10,000
keys.
C
Constrained
devices
and
wave
and
wave
I
mean,
but
also
these
divine
Yahoo
I've
got
a
an
account.
Then
you
know
an
app
that
has
you
know
it's
in
2,000
groups,
maybe
so
I
think
that
that
complexity
advantage
seems
to
me
worthwhile
to
do
the
group
ratcheting
the
thing
at
least
to
try
it
I,
don't
think
the
out
of
order
thing
is
going
to
be
a
big
deal,
but
I
think
that's
something
where
experience
will
be
helpful
in
determining
whether
it
is
actually
empirically
a
big
deal.
C
I
think
much
like
the
the
a
RT
versus
tree
came
here.
I
think
what
we
should
probably
do
technically
is
pick
one
of
these
go
with
it,
but
keep
the
other
one
in
the
back
pocket
if
we
need
to
switch
it
out.
I
think
this
is
a
component
that
can
be
fairly
modular
lease
with
the
swamp
and
swapped
out
in
the
future.
One
other
thing
I
would
push
back
on.
The
last
slide
is
the
this
idea
of
optional
signatures.
C
I
think
we,
my
assertion
here,
is
that
we
always
want
to
know
where
who
a
message
is
coming
from
I.
Don't
have
any
use
cases
for
generally
getting
message
that
came
from
someone
in
this
group
and
I.
Don't
so
I
would
propose
that
we
make
the
signature
field
mandatory
built
in
always
they're
part
of
the
message
protections.
My.
D
C
C
K
F
Yeah
refer
over
it
again.
Can
we
go
back
to
the
comparison
slide
so
initially
at
the
same
reaction,
then
Richard
when
I
sort
of
all
the
state,
but
then
and
more.
We
take
her
when
you
really
think
about
that.
What
that
means?
It's,
we
we
talk
about
kilowatt
and
it's
also
not
clear
if
we
have
to
keep
all
of
it.
Potentially,
this
is
only
between
two
group
stages
and
where
we
have
to
keep
stuff,
we
don't
have
to
keep
things
for
passive
participants
in
very
large
groups.
It's
potentially
still
not
a
lot
of
state.
F
We
have
to
keep
so
my
opinion.
This
strongly
strongly
favor
the
second
one
for
the
participant
ratcheting,
because
the
other
one
means
that
we
might
again
run
into
the
servation
problem
if
we
conflate
that
with
handshake
messages,
so
we
typically
would
expect
text
message
to
be
relatively
high
frequency
compared
to
a
handshake
messages,
which
means
that
there
is
a
real
risk
of
starvation
there,
which
we
don't
really
have.
If
we
have
a
per
participant
ratchet.
K
This
is
a
decay
cheap
rock
scene
for
Karthik
Karthik
asks
it
is
unclear
what
the
security
guarantees
of
application
key
ratcheting
are.
It
only
provides
forward
secrecy
against
a
very
weak
attacker
and
only
if
all
receivers,
including
passive
receivers,
regularly
delete
all
the
application
keys.
So
a
question
is:
do
we
even
need
application
key
ratcheting
as
long
as
the
group,
epic
secret,
is
frequently
enough,
updated.
D
Exactly
so,
that's
the
that's.
The
thing
I
mentioned
at
the
beginning,
at
the
very
beginning
of
a
PCS,
about
directly
extracting
one
set
of
n
keys
for
son,
dr
epoch
secrets
directly
at
the
beginning
and
depending
on
the
exact
Prakash's
we
want
that
might
actually
do
a
new
one
of
the
only
way
to
get
the
PCs
for
the
check
message
for
the
application
is
interesting,
and
maybe
so
maybe,
while
you
are
a
child
here,
you
can
talk
about.
I
didn't
mention
the
the
new
three
bays.
D
C
Now
so
you
could
build
a
structure
where
you
had
started
with
an
application
secret
and
you
know
hashed
it
in
two
directions
to
cover
halves
of
the
group
and
then
so
on
out.
So
you
have
to
the
leaves
to
seed
out
those
roots,
and
that
way
you
could
only
store
intermediate
nodes
in
the
tree
and
an
opportunistic
the
generate
things
as
people
transmit.
It's
a
mild
optimization
over
the
person.
They're
ratcheting
I
wanted
to
come
up
and
respond
to
eckers
notes
about
reordering
I
expect
on
this
topic.
C
We
actually
don't
disagree
about
lockstep,
penis,
I'm,
fully
I,
don't
think,
there's
any
need
to
assume
lockstep
for
messages.
I
think
there's
a
sort
of
reorder
in
here
we're
gonna
have
a
reordering
window
in
the
receiver
and
I
I.
Think
that
actually
argues
for
the
grouped
ratcheting,
though,
because
if
I've
got
a
buff,
you
know
a
fixed-size
buffer
for
real
for
maintaining
keys
for
reordering
in
the
person
they're
ratcheting
I've
got.
C
I
I
But
if
you
want
to
be
able
like,
if
you,
if
you
mean
look
to
the
math,
if
you
have
a
group
that
has
you
know
your
group,
that
has
you
know
the
ten
messages,
a
minute
which
is
an
uncommon
and
you're
offline
for
ten
minutes,
you're,
not
looking
you're.
Now
looking
at
like
a
hundred
messages
wearing
window.
My
ten
minutes
like
easy
right
am
it's
like
is
a
different.
You
know
your
cargos
in
the
tunnel
or
you
know
you're
you
go
in
the
elevator,
and
so
so
II
was
just
uncomfortable,
but.
C
I
Depending
on
like
how
much
were
in
really
tolerate
I
mean,
like
I,
seen
slack
messages
ruler
for
hours,
two
days,
someone
you
know,
so
he
was
an
airplane
right
on,
but
more
generally,
you
also
don't
need
to
retain.
Like
you
also
don't.
The
only
reason
is
that
the
only
reason
that
you
think
you
need
to
retain
on
like
a
long
ass,
a
long
wind
like
that
is
it's
like
the
research
is
a
strike
right,
mister
right!
I
C
I
Suffolk
a
material
so
like,
unless
you
can
demonstrate
that
light.
You
know
it's
like,
like
is
like
I,
want
to
see
an
argument
that,
like
use
the
store
like
mounds
of
data
that
are
comparable
to
like
you,
know
the
size
of
like
the
photos
of
your
iPhone
before
I'd,
actually
can
throw
this
being
an
issue.
X
Matthew
Miller
I
think
at
the
end
here,
I'm,
basically
just
agreeing
with
that
career
and
I
think
it
is
important
to
remember
like
when
we're
talking
about
high
transmission.
You
know
high
frequency
of
transmission,
sometimes
groups
get
super
super
SuperDuper
active
and
trying
to
deal
with
that
kind
of
problem.
I
mean
I've
seen
this
in
the
past
with
other
clients,
where
per
per
message
ratcheted
keys
are
in
use
and
there's
been.
Essentially,
the
group
becomes
unusable
for
a
people
for
a
period
of
time
until
everybody
finally
sinks
back
up.
B
Next
presentation
tomorrow,
I
agree
with
a
correct
story:
local
authorities,
at
least
concerning
this
protocol,
like
whatever
lies,
how
to
design
this
so
III
disagree
with
supporting
their
it
points
at
how
come
this
historic
is
an
issue
for
person
directing
I
also
think
the
other
one
as
the
course
it
is
wrong.
So
I
guess
there
is
no
red,
actually
things
with
person
directly
I
think
it's
it
for
me.
It's
intuitive.
It
makes
more
sense.
J
John
Milliken,
so
I
I
just
wanted
to
respond
to
a
kiss
point,
but
I
I
do
broadly
agree
with.
Actually
that
I
don't
think.
We
need
to
worry
too
much
about
storage
space,
but
I
like
to
be
careful
that
we
don't
build
for
modern
iPhones
and
we
build
for
low-end,
circa
2012
devices
or
something
because
we
still
support
them
in.
L
C
Okay,
that's
what
I
was
hearing
a
little
bit.
Likewise,
when
we
have
when
we
send
handshake
messages,
we
include
a
signature
by
the
identity
key
and
a
proof
of
inclusion.
One
thing
we'll
need
to
keep
an
eye
on
as
we
go
forward,
is
that
you
know
the
authentication
we're
running
it
and
long
run
is
going
to
be
about
identities.
C
You
know
email
addresses
or
usernames
or
something
like
that,
not
public
keys
and
so
we'll
need
to
add
credentials
at
some
point
which
we
don't
have
in
the
current
draft
so
want
to
step
back
briefly
and
think
about
requirements
for
authentication.
What
do
we
want
to
verify
at
one
now?
This
is
again
to
the
academics.
This
is
not
the
precise
definitions,
it's
kind
of
taking
a
functional
view
of
what
does
you
know
a
participant
in
a
group
want
to
verify
at
different
points
in
the
life
cycle.
If
it's
it's
interaction
with
the
group.
C
So
when
a
client
connects
to
the
group,
it's
going
to
want
to
verify
who
the
other
members
are
in
the
group,
so
it
knows
who
its
encrypting
to
when
it
encrypts
to
the
group.
So
this
is
something
in
which
I
think
Karthik
and
Benjamin
might
disagree
on,
because
there's
some
ideas
that
you
might
just
want
to
know
that
when
you
receive
something
it's
from
the
group,
and
so
you
might
not
care
about
who
the
other
members
are
in
the
group.
C
C
It's
kind
of
update
the
roster
we
have
the
raw,
so
the
client
has
the
idea
the
client
has
of
who's
in
the
group
and
when
we
remove
the
interesting
case
here,
one
that's
different
from
the
others
is
that
removal
requires
knowing
a
co
path
for
another
node.
So
this
is
different,
because
it's
not
about
identity
verification.
It's
about
verifying
that
you
have
the
same
crypto
state
as
the
rest
of
the
group.
So
just
to
graph
that
out.
C
If
we
imagine
the
case
where
a
node
F
in
this
industry
wants
to
evict
node
J
as
John
was
detailing
earlier,
F
needs
to
generate
an
update
for
J,
which
means
it
needs
to
generate
those
or
solid
orange
nodes
on
the
paths
from
J
to
the
root
and
in
order
to
generate
those
nodes
with
a
new
leaf
value
for
J.
That
J
doesn't
know
it
needs
to
have
those
orange
outlined
boxes
on
one
of
those
labeled
I
and
there's
other
an
arrow
pointing
to
the
other
but
F
under
normal.
C
But
but
more
importantly,
eff
needs
to
be
able
to
verify
that
when
it
gets
these
Co
path,
nodes
from
some
source
that
they're
the
right,
Co
path
notes-
and
if
you,
if
you
want,
have
to
be
able
to
evict
anyone
else
in
the
tree,
then
it
needs
to
have
the
whole
state
of
the
tree
needs
to
have
the
co
path.
For
every
note,
which
means
it
needs
to
have
the
public
keys
for
every
node
in
the
tree,
and
so
we
need
some
channel
for
authenticated
effectively
authenticated
distribution
of
the
tree.
C
C
You
have
points
where
you
are
already
a
member
of
the
group
and
you're
trying
to
authenticate
something
about
the
group,
so
I'm
an
incremental
change
about
the
group,
and
you
have
the
initialization
step
where
you're
joining
the
group
and
you
need
to
initialize
your
state
with
the
authenticated
roster,
so
I
kind
of
treat
that
on
connect,
initialization
question
as
separate
from
the
once
you're
connected
to
the
group
cases,
so
I
think
these
post
Connect
cases
are
a
little
bit
easier
in
particular
message.
Okay,
authentication
is
is
really
just
a
signature.
C
Vendor
might
want
to
make
it
optional,
but
I
think
we
should.
We
should
require
this
in
the
current
draft.
We
include
a
signature
together
with
a
membership
proof.
You
know
that
proof
that
the
identity
key
that
signed
the
message
is
recognized
or
part
of
the
Markel
tree
of
identity
keys.
That
was
committed
in
the
group
init
key.
That
kind
of
defines
the
group,
that's
handy.
C
If
you
only
want
to
cache
on
the
endpoints
that
commitment,
the
head
of
the
Merkel
tree
and
not
worry
about
storing
the
entire
list
of
identity
keys,
but
you
know
maybe
we're
not
worried
about
storing
a
ton
of
stuff
and
we're
willing
to
cash
all
the
identity
keys.
In
that
case,
you
don't
need
the
membership
person
we
can
leave
them
out
of
the
protocol
and
as
Benjamin
just
presented
there
was,
you
know,
he's
got
some
stuff
in
his
pea
about
how
exactly
to
encode
the
signature.
C
It's
not
you
know,
there's
no
magic,
it's
just
a
signature
ever
the
message
to
authenticate
that
it
came
from
this
public
key
for
authenticating,
new
joiners
I.
Think
it's!
Similarly
pretty
simple.
It's
going
to
be
about
signing
this.
The
user
init
key,
that's
presented
as
part
of
a
group
initiated
ad
or
the
user.
Add
message:
that's
presented
as
part
of
a
user
initiated
ad
signing
that
those
the
content
of
those
messages
with
the
identity
key
and
presenting
a
credential
at
that
stage.
C
C
Initialization
is
a
little
more
challenging
because
it's
linear
size
and
Linear's
not
a
word.
We
really
like
around
this
group.
You
really
prefer
log
or
constant
things,
but
you
know
when
you're
talking
about
the
list
of
members
in
a
group,
that's
kind
of
irreducibly
linear
size.
You
have
to
talk
about
and
things
and
when
we're
talking
about
also
authenticating
the
tree,
you
have
to
n
intermediate
tree
nodes
roughly
give
or
take
you
know,
plus
or
minus
one
or
two
notes.
C
C
One
observation,
I
think
is
useful.
Here
is
that
handshake
messages
that
are
exchanged
in
the
course
of
the
protocol
carry
a
lot
of
the
information
we're
interested
in
here.
So
whenever
a
node
sends
out
say
an
update
or
a
user
add
they
are
sending
out
the
public
keys
along
their
direct
path
to
the
root.
And
so,
if
you
watch
the
activity
of
a
group
over
time,
you
can
build
up
the
state
of
the
tree.
C
In
particular,
if
you
observe
the
last
message
sent
by
each
participant
in
the
group,
you
can
kind
of
stack
those
on
top
of
one
another,
and
then
you
have
the
you
know
the
the
state
of
the
tree.
At
the
end,
this
is
kind
of
nice
and
if
you
have
the
authentication
and
then
the
information
you
need
to
authenticate
that
those
are
from
real
members
of
the
group.
You
have
an
authenticated
copy
of
the
tree
and
you
know
the
identities
of
the
participants.
So
this
kind
of
suggests
that
we
could
use
messages
themselves.
C
The
handshake
messages
that
have
been
sent
within
the
group
as
a
way
to
distribute
the
tree
and
to
distribute
the
roster
so
like
I,
said,
if
you
see
the
tree
or
if
you
download
it
from
somewhere
or
if
you
see
these
handshake
messages
or
if
you
download
it
from
somewhere,
you
can
reconstruct
the
true
the
public
state
of
the
tree
as
it
is
agreed
by
the
participants.
Now
it's
you
know,
I
said
we
hated
linear
stuff
is
even
worse
than
linear.
C
Now
we
have
n
log
n
things
to
download,
but
again
I
think
that's
it's
not
unavoidable,
but
it's
better
than
some
alternatives.
You
can
imagine
one
challenge
here
is
that
if
we,
if
you're
going
to
take
this
approach
of
using
the
messages,
you
need
to
verify
that,
so
you
want
to
make
sure
you've
got
the
latest
message
from
each
participant
and
that
the
server
has
it's
kind
of
injected
a
message
in
sequence
or
omitted,
one
injection
being
a
bigger
risk.
C
So,
in
this
case
you
know,
see,
updates
and
then
APA
and
then
B
and
a
update
at
the
very
end,
and
so
you
need
in
order
to
get
the
tree.
You
need
those
messages
from
a
B
and
C,
but
in
order
to
trust
that
those
are
the
correct
messages
for
you
to
build
your
tree
off
of
you
need
some
information
about
all
of
those
messages
in
the
middle
and
so
now
we've
gone
from
linear
to
law
and
law.
Again
now
we're
at
you
know,
lower
bounded
by
n
log
n.
C
We
may
need
more
I
think
we
can
do
a
little
bit
better
than
n
log
n,
though
we've
already
said
that
we
need
some
degree
of
hash
of
transcripts,
recording
we'll
need.
You
know
transcript
hashes
to
do
this
signal
like
stuff
and
so
we're
already
kind
of
it's
kind
of
hints
at
building
a
hash
chain
out
of
handshake
messages.
So
at
the
bottom
here
I've
got
kind
of
a
cartoon.
You
know
you,
you
initialize
off
some
hash
and
then,
whenever
you
send,
they
have
a
handshake.
C
You
hash
it
together
with
the
previous
handshake,
hash
and
and
has
shane
along
in
that
way.
So
you
can
imagine
you
know
distributing
these.
The
the
handshake
messages
that
you
need
in
toto
to
build
the
tree
along
with
basically
the
sequence
of
hashes
that
demonstrate
that
there
is
a
sequence.
There
is
a
sequence
of
handshake
messages
in
the
middle
of
the
connects
these,
so
you
at
least
know
that
you've
got
a
subset
of
subsequence
of
the
the
actual
sequence
of
handshake
messages.
C
Likewise,
one
thing
Rafael
and
I-
discussed
that
at
the
hackathon
last
time,
when
we
first
realized
we
had
this
tree.
Authentication
problem
is
that
you
could
encode
in
the
in
the
group
in
a
key,
a
commitment
to
the
current
state
of
the
tree,
and
you
know
we
like
to
use
Merkel
trees
for
commitments
because
they
compress
you
down
to
one
hash
value,
and
so
the
figure
on
the
right
here
is
a
tree
on
a
tree.
C
Nice
thing
about
the
tree,
stroker
we're
using
is
that
it
can
very
easily
be
mapped
to
a
flat
list
of
nodes,
and
so
you
could
take
the
actual
ratchet
tree
at
the
bottom.
Not
those
nodes
up
into
a
list
and
then
build
a
Merkel
tree
on
top
of
that.
That
would
give
you
a
commitment
to
the
tree,
and
so
now
you've
got
assurance
that
the
message
of
the
handshake
messages
you're
getting
are
correctly
from
the
sequence
of
handshake
messages.
C
So
this
is
very
much
kind
of
how
should
we
do
things
forward?
This
should
really
have
been
in
the
draft
if
I
were
doing
this
that
properly.
But
this
is
basically
my
rough
proposal
for
what
I
think
we
should
be
doing
to
build
out
an
authentication
infrastructure
in
the
next
groove
of
the
draft.
It's
obviously
needs
a
lot
more
detail
in
order
to
be
implementable
in
the
room,
be
really
protocol,
but
I
thought
I'd
presented
here
too
to
see
if
it
was
looking
plausible
to
folks.
C
The
will
take
the
approach
of
using
the
the
messages
themselves
as
the
distribution
channel
there.
As
the
things
we
expect
to
be
passed
around
by
the
distribution
by
the
was
a
delivery
service.
You
know
somehow
that
the
delivery
service
will
range
from
this
much
stuff
to
get
passed
around
so
that
endpoints
can
members
of
the
group
can
you
know
verify
that
they've
got
the
right
sequence.
They
can
build
up
the
tree.
They
can
verify
the
identities
that
have
sent
these
messages.
So
at
this
point,
I'll
just
open
up
for
discussion.
Does
this
look
good?
J
John
Milliken,
so
a
couple
of
points.
One
is
that
in
in
the
situations
where,
where
clients
do
have
a
full
list
of
the
people
involved
in
the
conversation,
why
so
for
the
remove
case?
Why
not
just
store
the
entire
tree
on
the
client?
Because
that's
it's
still,
it's
only
double
the
size
right.
It's
there's!
No
order
of
magnitude.
Difference,
yeah,.
C
J
J
C
So
Rafael
and
I
were
talking
about
this
yesterday
and
one
of
the
things
he
observed
was:
if
you
have
this
commitment
to
the
the
tree
over
the
tree,
then
the
server
could
you
know,
cache
the
tree
and
deliver
that
to
people
safely
and
the
server
could
strip
out
the
identity
information
of
messages.
It
only
needs
to
keep
the
tree
bits
of
the
messages
show
and
not
the
identity.
But
so
you
could
reduce
the
amount
of
metadata
that
way.
J
O
O
O
Read
I
suspect
if
we
end
up
update,
because
yes
and
if
this
is
all
compromised,
then
we
can't
just
say
that
we
got
your
key
indicating
voltage
we
want
to
roll
to,
which
means
we
need
student,
fresh
signature
and
somehow
he
and
so
on.
So
I
think
it's
a
bit
more.
You
want
come
from
security
code,
signature
and
then.
C
That
was
a
little
bit
garbled
here.
The
thing
I
was
nodding
about
at
the
end
was
that
a
and
I
thought
I
heard
Karthik
saying
that
it's
difficult
to
get
post
compromised
security
with
regard
to
signature
keys,
as
well
as
the
the
contributory
leaf
leaf
secrets,
we're
talking
about
here
of
the
confidentiality
keys
yeah.
So
that
is
a
property
of
the
proposal.
I'm
making
here
is
the
identity.
Keys
are
long
lived,
and
so
this
doesn't
this.
This
game
overall
doesn't
provide
pcs
with
regard
to
the
signature,
keys,
I,
think
I.
C
Think
Benjamin
has
thoughts
about
how
you
might
do
that
by
say,
initializing
with
proof,
by
with
a
long
term
key
and
then
doing
future
signatures
with
a
different
key
authorizing
a
different
key
that
could
do
future
signatures
that
personally
I'm
less
worried
about
these
authentication
keys
than
the
confidentiality
keys.
Although
I'm
not
sure
why
I
say
that
would
be
interested
in
people's
thoughts
about
whether
it's
worthwhile
the
to
aspire
to
piece
some
sort
of
pcs
with
regard
to
signature,
keys,
I.
M
D
C
M
C
C
D
C
The
way
I
would
be
tempted
to
think
about
that
the
simplistic
way
it
would
be
in
kind
of
a
fast
forward
context
where
I,
the
the
the
simple
long
way
you
might
think
about
building
is
to
have
the
server
cache
the
handshake
transcripts.
And
then,
when
someone
comes
online
after
a
long
time,
they
just
Elmo
does
as
the
fast-forward
version
of
the
handshake
transcript,
which
means
you
gotta
read
forward,
but
you're
gonna
have
to
do
that
anyway,
so
that
you
have
them
the
confidentiality
keys.
D
Okay,
so,
regarding
your
last
point,
deniability
the
original
so
tired-
and
that's
why
I
said
optional
signature
in
my
when
I
discussed,
it
is
because
I
I
don't
like
I
personally,
don't
like
the
idea
of
signing
everything
with
the
long
term
identity
key,
but
that
doesn't
mean
we
can't
get
better
privacy
out
of
it.
As
you
mentioned
we
could.
D
My
thinking
is
that
we
could
actually
use
ephemeral,
signature
of
keys
for
get
to
at
least
you
get
FS
for
signature
keys,
I'm,
not
sure
about
pcs,
but
at
least
you
get
FS
and
the
general
deniability
point
is:
if
you
you
could
I'm,
not
sure
we
might
get
in
a
be
able
to
get
deniability
if
we
rapture
the
link
between
the
initial
ethanol
signature
key
from
the
long-term
identity.
Key
by
let's
say
the
user
is
establishing
one-to-one
deniable
channel
to
send
is
own
private
initial
XML
signature
key.
D
C
So
what
I
wondered
is
kind
of
in
terms
of
order
of
operations?
It
seems
like
these
schemes
for
forward
secrecy
and
signature
keys,
which
maybe
adds
up
to
deniability,
are
sort
of
additive
yeah,
in
the
sense
that
you
could
take
a
scheme
that
doesn't
have
that
property
and
add
on
to
it
a
mechanism
for
authorizing
short-term
scientist,
ease,
so
I
think
I
wonder
if
we
should
go
ahead
under
the
assumption.
C
For
now
that
we
have
long
term
identity
keys,
and
then
we
can
consider
later
how
that
might
be
extended
to
have
short
term
kind
of
signature,
key
rotation.
Okay,
that
would
be
my
operating
concept.
Almost
you
think
that
that
would
be.
That
would
make
it
too
difficult
to
address.
It
wasn't
clear
to
me:
it.
H
Think
it's
awesome.
Chef
yeah
I
think
that
if
we
have
that
basic
assumption
of
identities
that
being
more
trusted,
then
this
is
a
good
good
start
to
go
and
we'll
refine
delicious.
If
that
start
with
Sigma,
like
protocols,
have
some
issues
and
I
have
maybe
some
basic
equation,
which
is
continuation
of
one
of
previous
equations?
H
Do
we
want
to
give
some
exact
combinations
about
the
users
that
really
want
to
be
anonymous,
but
that
want
some
mechanisms
that
may
be
outer
Bank
mechanisms
so
that
they
are
direct
receivers
of
messages
or
senders
to
them
can
verify
their
identity,
but
should
we
provide
some
out
of
bed
mechanisms
for
that,
or
should
we
just
if
some
recommendations
have
to
do
it?
So
if
I
am
the
new
user,
I,
don't
know
anyone
in
the
group
and
no
one
knows
me,
but
I
know
someone
in
personal
and
I
want
someone
to
trust
me.
H
What
is
the
mechanisms
for
me
to
be
able
to
prove
that
I
am
program?
There
are
a
lot
of
techniques
in
existing
messengers,
for
example,
in
Vicker
such
that
video
call
is
just
pronounced
in
your
public
key.
There
can
be
some
techniques
based
on
Peck,
for
example,
if
you
just
transmit
as
short
as
four
times
and
uses
just
indicates
a
shortened
session,
those
indicator
of
your
public
key.
So
there's
a
lot
of
variety
of
options.
C
So
I
think
I've
I've
as
I
think
in
my
head
mentioned
I
think
for
to
a
large
degree,
the
authentication
service
itself
is
fairly
separate
from
this.
We
need
to
have
an
integration
point
which
I've
called
credential
here,
but
I
think
we
can
keep
that
integration
point
fairly
abstract,
so
you
can
think
of
it
as
a
certain.
You
know
normal
x.509
certificate
if
you
want,
but
you
could
also
insert
something
it's
like.
C
If
you
want
to
do
a
fake
thing,
you
could
put
something
in
there
that
would
say
commit
to
a
fake
output
as
the
identity
value
there.
The
important
thing
is,
you
need
to
identify
to
bind
the
identity,
which
is
the
thing
you're
going
to
use
in
the
authentication
system
to
the
public
key
with
that
you're
going
to
use
it
in
this
system.
Yes,.
H
And
I
take
point
that
really
it's
maybe
unrelated
to
your
current
presentation.
You
have
a
point
of
integration
and
it's
all,
but
regarding
the
group
at
all,
maybe
your
slides
are
more
related
to
the
things
that
any
other.
So
should
we
think
of
putting
some
black
text
to
secure
considerations
about
recommendations
or
techniques
for
initial
authentication,
because
I
think
that
it's
one
the
crucial
point
for
practical
security,
for
example.
H
If
you
know
a
lot
of
strange
stories
with
telegram
in
Russia
and
ways,
fight
between
enemy,
anonymity
of
the
users
and
the
mechanisms
to
protect
this
I
think
that
it
will
be
really
good
to
add
some
recommendations
about
how
to
protect
privacy,
but
to
be
able
to
trust
the
US
we
want.
Maybe,
as
a
new
group
that
has
been
developed
in
IR,
AF
PRG
will
be
a
good
place
to
discuss
this
issue.
Yeah.
C
F
Rafa
Robert
again
I
try
to
be
brief,
two
things,
so
one
is
both
compromised
security
and
there
it
was
mentioned
that
there
is
a
bit
of
a
gap
between
the
signature
key
and
their
group
secret
and
so
I
know
privilege
setting
you
can
compromise
both
if
an
attacker
has
access
to
the
local
storage
of
a
device,
but
there
might
be
other
ways
of
compromising
the
group
secret
where
pcs
is
relevant.
For
example,
when
there
is
flaw
in
the
crypto
level
in
the
and
check
messages.
F
Basically,
you
can
get
access
to
the
group
secret,
but
in
that
case
you
still
don't
have
access
to
the
signature
key.
So
in
that
sense,
your
gut
feeling
is
sort
of
justified
there
that
the
signature
keys
are
actually
better
protected
because
they're
not
being
negotiated
over
any
protocol.
The
other
thing
is
the
last
point
on
your
last
slide
and
that
is
deniability.
So
I've
had
a
number
of
offline
discussions
with
a
number
of
people
and
the
really
the
only
common
denominator.
There
is
that
everybody
feels
about
it
very
strongly.
F
Some
of
them
are
in
favor
of
it.
Others
are
absolutely
opposed
to
it
and
they
don't
seem
to
be
any
meaningful
common
ground
there
for
some
consensus
of
what
could
be
done
so
I
think
personally,
the
the
only
way
of
going
forward
is
to
have
optional
deniability,
and
the
practical
proposal
here
has
been
that
we
use
this
Sigma
like
mechanism
to
distribute
an
ephemeral
signing
key
in
a
one-to-one
way.
So
this
would
practically
work.
Unfortunately,
it's
quite
expensive,
so
it
would
be
fantastic.
F
K
P
I
think
the
key
point
here
is
that
we
know
that
there's
a
lot
of
open
issues
in
the
protocol
draft
and
I
think
that
that's
perfectly
fine,
because
otherwise
we'd
be
done
in
one
meeting
right.
That's
not
really
the
goal,
but
I
would
like
to
get
the
working
group
process
started
and
actually
get
that
document
adopted
into
the
into
the
working
group.
I
see
a
show
of
hands
who's
read
the
protocol
document
good,
a
large
number.
We
are
now
going
to
hum
for
working
group
abduction.
P
P
P
Thanks
so
notes
up
here,
some
other
things
that
we
obviously
have
to
talk
about.
We
are
planning
an
interim
since
we
kind
of
ran
at
a
time
here.
We
think
we
could
deal
with
some
real
head-to-head
time
for
like
a
day
or
two
we're
not
quite
sure
when
that's
gonna
happen,
but
right
now,
the
Nexus
of
people
that
really
are
working
on
this
or
in
San,
Francisco,
Berlin
or
London,
so
think
about
that
NDC.