►
From YouTube: IETF104-MLS-20190328-0900
Description
MLS meeting session at IETF104
2019/03/28 0900
https://datatracker.ietf.org/meeting/104/proceedings/
A
Well,
welcome
again,
the
blue
sheets
are
going
around
as
I
said
earlier.
This
is
the
MLS
session
of
ITF
104
you're
in
the
wrong
place,
I'm
here
to
stay
and
learn
a
little
bit
or
take
off
your
call.
The
chairs
were
nikkor
myself
and
the
secretary
of
control
I
see
you
had
to
take
off
to
go
back
home,
but
he'll
be
watching
I'm
sure
listening,
here's
the
note!
Well,
it's
Thursday,
hopefully,
you've
seen
it
by
now.
Basically,
anything
he's
saying
to
you
will
be
used
against
you.
A
You're
gonna
be
recorded,
get
to
the
microphone
to
talk.
If
you
know
about
IPR
supposed
to
disclose
it
there's
any
kind
of
problems
you
can
talk
to
Bo
buds
team
and
there's
a
bunch
of
BCPs
to
tell
you
about
how
the
internet
standard
process
works,
codes
of
conduct
and
all
kinds
of
things.
If
you
have
any
questions,
you
can
ask
us
or
followings
that
are
in
the
know,
well,
requests.
A
We
need
a
minute
taker
and
a
jabber
scribe
before
we
can
proceed
what's
nice
about
being
around
for
here
for
a
long
time,
as
you
know,
a
lot
of
people's
faces,
and
so
you
can
basically
wait
and
for
a
couple
minutes
and
then
you
just
pick
someone
so
again
minute
taker.
All
we
need
to
know
is
decisions.
A
A
Shawn,
the
blue
sheet
says
they're
coming
around
obviously
to
the
microphone.
Please
state
your
name
at
the
mic,
depending
upon
the
mic,
you
may
have
to
eat
the
mic,
so
don't
be
offended
if
somebody
says
eat
the
mic
that
just
need
to
get
closer.
Let's
keep
it
professional
at
the
mic.
So
our
agenda
for
today
it's
on
the
right.
So
the
protocol
we're
gonna
start
with
the
issues
within
the
protocol
draft.
A
We
actually
discussed
the
simplified
key
schedule
and
I
don't
know
if
you
think
we
need
to
redo
it
today
because
of
odds
here,
Richard
or
or
what,
but
we
can
the
other
issues
that
we're
going
to
talk
about
our
common,
framing
and
lazy
updates
and
then
Ahmad
and
Rafi
on
some
stuff
on
Federation,
which
we
talked
about
it
at
the
interim
and
then
Sophia
is
going
to
talk
about
some
deniability
that
we
can
do.
Karthus
gonna
give
us
a
formal
security
analysis
update
and
then
we're
gonna
try
to
do
some
next
interim
planning,
Richard.
C
All
right,
Zoey
we're
going
to
start
with
common
framing,
which
is
something
that
we've
been
discussing
for
a
while.
Another
is
a
at
least
one
concrete
proposal
so
to
give
a
bit
of
context
and
also
to
state
clearly
what
problem
we're
trying
to
solve
on
the
security
and
privacy
level,
the
idea
is
to
find
a
common
format
to
encrypt
handshake
and
application
messages.
C
The
reason
behind
that
is
that,
for
example,
add
messages
and
remove
messages
can
leak,
information
about
who
has
been
added
to
the
group
and
who
has
been
removed.
In
particular,
add
messages,
have
the
identity,
the
credentials
of
the
members,
and
so,
if
handshake
messages
are
not
encrypted,
that
information
lives
in
these
messages
in
clear
text
and
since
handshake
messages
have
a
certain
lifetime,
you
expect
them
to
be
stored
on
a
server
for
a
certain
time
until
they're
finally
being
delivered
to
the
client.
C
C
There
are
some
conflicts
when
you
start
encrypting
handshake
messages.
One
of
them
is
that
in
the
past
we've
been
discussing
the
concept
of
server
assist
where
the
server
could
provision
new
clients
with
public
keys
in
a
tree.
So
the
server
would
basically
maintain
a
view
of
the
public
keys
of
the
ratcheting
tree
so
that
new
clients
wouldn't
have
to
get
that
information
from
existing
clients,
and
it
would
simply
be
more
efficient
if
that
could
be
retrieved
from
the
server.
So
this
becomes
impossible.
C
Of
course,
if
you
completely
encrypt
and
check
messages
at
IETF,
103
I
think
occurr
made
the
point
that
the
best
strategy
would
be
to
first
encrypt
handshake
messages
and
I
like
to
think
of
what
needs
to
be
leaked
to
the
server
in
order
to
build
the
trees
of
public
keys.
So
this
is
essentially
what's
happening.
Now
we
are
encrypting
first
and
then
we
can
selectively
additionally
leak
some
information
to
the
server.
C
The
other
thing
is
that
encrypting
handshake
messages
mostly
only
makes
sense
in
a
scenario
where
the
server
shouldn't
know
what
the
roster
is.
So
just
as
a
reminder,
the
russa
is
the
list
of
members
in
a
group.
If
it's
the
requirement
that
the
server
should
know
what
the
roster
is-
and
it
probably
needs
to
be
some
mechanism
how
the
server
gets
updated
on
that
as
well
and
then
encrypting
handshake
messages
might
not
be
necessary
or
even
be
counterproductive.
C
So
we
were
looking
for
a
common
framing
for
both
handshake
and
application
messages,
so
the
the
struct
on
the
left
here
has
a
header
with
some
metadata,
the
the
group
ID.
So
every
message
paid,
handshake
or
application
pertains
to
a
certain
group,
a
certain
epoch
of
that
group
and
comes
from
a
sender
which
is
a
member
of
that
group.
In
addition
to
that,
we
distinguish
between
different
content
types,
which
at
this
point
in
time,
is
only
a
handshake.
C
C
C
C
That
is
now
the
the
encrypted
message,
but
you
will
notice
that
the
group
ID
the
epoch,
the
sender
and
the
generation
are
still
in
the
clear
in
the
header
of
that
ciphertext.
So
the
ciphertext
is,
is
the
MLS
inner
plaintext
from
the
left
and
just
as
a
reminder.
So
the
generation
is
for
a
given
sender
in
the
application
key
schedule.
C
So
what
we
do
here
is
on
the
lower
left
side.
We
see
the
alternative
2
for
the
MLS
cipher
text
struct.
So
what
we
still
have
in
the
clear
is
a
group
ID
and
the
epoch,
and
there
is
no
way
to
properly
allocate
that
at
this
point
we
also
have
the
content
type
and
the
clear
so
that
we
can
distinguish
between
handshake
and
application
messages,
and
this
is
important
because
for
now
we
assume
that
with
tree
can
we
need
strong
ordering
for
our
handshake
messages.
C
Maybe
not
update
messages
but
add
and
remove
messages
for
another
require
strong
ordering,
whether
whereas
application
messages
do
not
have
that
requirement.
So
if
we
conflate
the
two
in
a
common
struct,
it
shouldn't
be
a
requirement
that
application
messages
now
also
inherit
this
property
of
being
strongly
ordered
the
server
side,
because
that
could
be
problematic.
C
Since
we
expect
to
be
there
to
be
many
more
application
messages
than
handshake
messages
and
that
could
lead
to
problems
like
starvation,
if,
if
the
server
needs
to
tell
clients
that
they
have
to
re-encrypt,
because
the
epoch
is
change,
so
we
expose
this
in
the
clear
and
then
the
sender
data
which
we
see
on
the
upper
right,
the
sender
and
the
sender
generation.
That
will
then
be
be
encrypted
under
a
group
key.
It
cannot
be
a
sender
specific
key,
because
we
don't
know
who
the
sender
is
at
that
point.
C
C
And
in
terms
of
authentication,
so
we
have
the
a
Eid
authentication
that
certains,
that
is
certain
sender,
is
part
of
the
group.
Then
the
whole
message
is
signed
such
so
once
we
know
who
the
sender
is.
We
can
also
verify
that
signature
and
then
then,
with
the
confirmation
key
that
comes
out
of
the
the
group
key
schedule.
C
Yeah.
That
concludes
that,
in
the
end,
we
have
some
open
questions.
So
one
of
the
questions
is:
is
it
fine
to
review
the
content
type?
So
just
as
a
reminder,
that
is
what
is
in
the
clear
now
so
that
we
can
distinguish
between
application
and
handshake
messages.
Do
we
leak
some
information
that
we
shouldn't
leak
by,
revealing
that
the
other
option
is?
C
The
other
question
is:
is
it
worth
encrypting
the
center
and
the
generation
I
mean
there
is
no
cryptographic
identity
in
the
sender.
It
is
it's
really
just
an
index,
so
you,
if
you
don't,
have
the
roster.
You
cannot
clearly
say
who
the
sender
is,
but
just
looking
at
one
handshake
message,
but
you
could
still
aggregate
that
data
and
get
a
better
view
and
what's
happening
in
the
group
and
then
for
academia.
The
question
is
whether
we
find
with
switching
the
order
of
signature
and
Mac
as
opposed
to
TLS.
D
So
I
don't
live
in
a
payment
for
loss
point.
My
understanding
from
reading
Sigma
is
that's
technically
okay
but,
like
other
words,
a
good
idea
like
I
leaved
people
who
know
these
protocols
better.
I
mean
I
germany
aimed
towards
cooking
as
much
as
I
can
also
have
to,
as
I
think
was
I
apparently
I
said
last
time
that
I
don't
recall
so
the
with
a
content
I
used
to
me
that,
with
the
content
type,
we
have
a
somewhat
difficult
problem,
which
is
that
we're
trading
off
two
values.
D
One
is
key
separation
between
the
handshake
and
the
and
the
content
data
which
otherwise
it
was
otherwise
nice
to
have
for
analysis
reasons,
and
the
second
is
revealing.
The
kind
of
type
now
is
leaking.
The
information
now
they're
sort
of
like
an
abstract
reason
left
like
that,
because
you
know
just
general
a
leaking
phrase
you
want
to
have
is
not
good
but
there's
actually
a
so
not
like
fantastic
but
like
sort
of
concrete
attack.
That
is,
is
a
lot
of
our
building
content
type.
And
it's
this.
If
the.
D
If
you
don't
force
Quincy,
it
is
basically
that
it
allows
the
attack
that
the
message
delivery
service
maliciously
to
basically
gag
updates
from
giving
client
by
basically
just
not
sending
them
by
just
removing
the
from
the
message
stream.
Unless
you
have
for
sequencing
between
them,
then
that
menu
our
problem.
Now,
maybe
you
could
have
forced
sequencing
and
that'd
be
fine,
I
think
the
the
idea
is
like
that
I
shouldn't
be
like.
Obviously
you
can
just
take
me
out
of
the
group
I.
D
Don't
let
me
send
messages
right,
but
what
you
shouldn't
be
able
to
do
is
a
lot
of
my
messages
to
get
through,
but
not
let
me
Rika,
and
so
so,
if
I
think
when
I
talked
to
you
earlier,
you
said
that
you
know
it
wasn't
important
to
have
those
sequenced,
but
it
potentially.
E
D
Because
otherwise,
well
happen
potentially
happens.
Is
this
attacker
says?
Well,
it's
fine.
If,
like
Ben
talks,
the
group
but
I
want
to
let
him
Riki's
or
if
I'm
gonna
see
a
handshake,
Meister
I
just
drop
it
on
the
floor.
So
now,
so
obviously
only
kind
of
never
revealed
makes
that
easier.
They'll,
potentially
be
stall,
sequence,
numbers
and
they'll
be
fine
on
the
it's
also
the
case,
obviously,
that
you
learn
more
about
the
group
structure.
You
know
if
you're,
if
your
server
by
picanha
types,
awake
right.
C
C
What
to
the
point
that
the
content
type
might
revealed
some
information
there?
The
plan
has
been
made
that
this
could
also
be
revealed
by
just
looking
at
traffic
patterns,
because
handshake
messages
have
a
certain
size
and
they're
the
they're,
not
necessarily
indistinguishable
on
the
network
from
application
messages.
That's
the
planet
for
that
earlier,
yeah.
D
It's
certainly
true
I
think.
Obviously
we
could
go
to
some
effort
to
make
them
out
the
case
that
we
have
padding
and
those
kinds
of
things.
I
think
you
know
I
don't
feel
like
as
a
matter
of
principle.
I
guess
I
prefer
not
that
not
to
have
it
this
way,
but,
like
maybe
it's
have
to
it's
I
guess
there
is
one
bother.
You
know
when
we
looked
at
this
in
TLS.
D
You
just
do
application
travel
occur
from
that
you
and
then
you,
you
know,
use
the
handshake
even
fails
since,
like
again,
I
don't
know
if
this
is
like
kind
of
the
wall
tracked
before
I
like
sign
known
for
traffickers,
I,
wonder
if
I
reverse
say
it
was
okay,
yeah.
C
F
Yeah
one
is
also
another
active
point
that
so
so
I
want
to
echo
what
Eric
just
said,
which
is
that
it
in
and
point
out
that
these
choices
that
are
proposed
here
and
least
in
these
slides
are
pushing
us
in
the
direction
of
turning
over
significantly
more
information
about
group
structure
and
good
and
and
traffic
analysis
to
the
delivery
server
and
those
are
significant.
Architectural
changes
that
grant
the
delivery
agent
significantly
more
power.
F
In
this
context,
and
if
that's
what
we
just
that
we
want
to
do,
then
we
need
to
make
that
pretty
clear,
I
think
in
the
architecture
document,
because
I'm
not
sure
that
the
architecture
document
currently
acknowledges
how
much
power
the
delivery
server
has.
This
is
I
believe
this
isn't.
This
is
a
significant
increase
in
the
power
of
the
delivery
server.
I'm,
not
happy
about
that.
I
would
like
this
scheme
to
have
to
put
less
power
in
the
hands
of
whatever
centralized
agents
we
actually
have
to
put
up
with
which.
F
C
B
In
the
pr
we
have
up
right
now
exposes
all
of
this,
and
so
the
additional
proposals
base
to
protect
the
generation
said
there.
That's
why
we're
reacting
kind
of
puzzled
by
your
comment,
because
we're
increasing
relative
to
what's
in
the
pr
right
now?
The
only
thing
is
that
we're
we're
still
revealing
the
content
type,
so
I
think
we're
aligned
on
protecting
the
sender
and
generation
that
those
aspects,
it's
just
the
question
of
whether
these
questions
about
ordering
or
sufficient
to
justify
the
content
site.
Okay,
so.
F
H
Been
Caidic
all
know
that
in
our
Charter
we
are
not
explicitly
chartered
to
like
encrypt
as
much
as
possible
in
the
way
that
TLS
was
you
know,
TLS
has
explicitly
charted
to
encrypt
as
much
as
possible
Jake,
but
we
are
charted
to
learn
from
the
lessons
in
other
protocols.
Like
you
know,
OTR
double
ratchet
and
whatnot
and
I
would
certainly
lend
to
support
in
general
the
idea,
if
it
as
much
as
we
can,
which
I
think
has
been
mentioned
a
couple
times
already.
Maybe.
C
I
Kartik
Pergamon
Andrea
so
related
to
the
question
masked
they're,
switching
Giotto,
signature
and
Mac,
usually
not
a
problem.
In
fact,
at
some
point,
I
suggested
in
TLS
one
three
that
you
should
switch
the
order.
Unfortunately,
the
Mac
is
called
the
finished
message,
so
it
would
have
been
weird
for
it
not
to
be
the
last
message,
so
we
didn't
do
that,
but
I
didn't
propose
that,
but
you
could
actually
in
some
cases
it
helps.
So
we
can
look
at
it,
but
I
think
be.
Okay.
I
Second
thing
is
that
we
really
do
want
the
likies
used
for
uncheck
to
be
different
from
the
keys
use
for
the
application
later
also
because
for
for
compositionality
improves
its
it's
critical,
but
more
practically.
You
want
to
think
about
it,
as
suppose,
when
decrypting
the
handshake
message,
you
then
look
at
the
format.
I
You
leaked
something
somehow,
okay,
so
the
decryption
of
the
hand
clip
message
leaked
something
we
do
not
want
that
to
affect
the
leakage
of
application
data,
because
an
attacker
will
take
an
encrypted
application
yet
and
it
doesn't
handshake
it
see
if
you
managed
to
decrypt
it
and
then
see
what
what
comes
out
of
it
and
if
it
comes
out
and
says.
Oh,
this
is
not
a
valid
handshake
message,
its
revealing
something
about
the
application
did
I
miss
it.
I
sent
you
so
you
have
to
be
careful
about
this,
as
I
will
really
love
key
separation.
I
I
really
highly
support
that
also.
Yes,
we
should
try
to
encrypt
sender
and
generation
for
the
content
type.
The
only
point
I
would
say
is
I.
Don't
see
a
very
strong
reason
for
hiding
it,
but
the
motivation
you
came
up
with
was
that
the
handshake
messages
are
ordered,
but
the
data
messages
are
not,
but
the
ordering
there
is
not
I,
think
sort
of
sufficient
motivation
in
some
sense,
because
even
the
data
messages
have
a
causal
ordering.
So
you
can
think
that
suppose
every
message
instead
of
saying
I,
am
message:
number
I.
I
D
J
F
This
is
dkg
and
sorry
youyou,
you
said
a
phrase,
that's
kind
of
I,
don't
know
if
I
could
call
it
a
pet
peeve
of
mine
or
whatever,
but
you
said
personally
identifiable
information.
We
want
to
hide
it
personally.
I
didn't
I,
don't
know
whether
that's
actually
in
the
Charter,
if
it
is
I,
missed
it
and
who
do
the
actual
dog
put
up.
My
okay.
F
Identifiable
information
is
a
legal
fiction
and
it
is
far
more
fiction
than
anything
else.
The
history
of
re-identification
and
D
anonymization
and
all
the
other
kinds
of
research
that
have
gone
on,
make
it
quite
clear
that
personal
identifiable
information
is
not
a
coherent
category
and
there's
much
more
important
things
beyond
personally
identifiable
information
that
can
have
concrete
harms
when
you
expose
them.
F
So
I
want
to
make
sure
that,
as
a
group,
we
aren't
just
thinking
that
what
we
need
to
protect
is
personally
identifiable
information,
because
that
particular
term
is
something
that
lets
people
get
to
sort
of
miss
the
forest
for
the
trees.
Right,
it's
very
easy
to
say:
oh
well,
that's
a
social
security
number
or
that's
a
bank
account.
Let's
ignore
it.
Let's
protect
that,
but
the
rest
of
the
stuff
isn't
that
important.
This
is
messaging.
The
content
of
my
message
is
not
PII,
but
we're
trying
to
protect
it
too.
F
D
D
So
so
is
it's
fine
to
have
like
some
sort
of
partial
ordering
of
messages,
but
it's
got
to
be
the
case
that
basically,
that
the
receiver
can
see
that
there's
like
a
missing
message
out
of
my
out
of
my
out
of
my
flow,
there
was
like
a
hamshank
message
that
it
no
longer
there
on
now
you
can
get
that
you
can.
You
can
get
that
by
just
having
one
set
of
sequence:
numbers
effectively
expand
both
keys.
I
have
no
idea
like
what
that
doesn't
any
kind
of
keys.
Approching
guarantees.
D
Are
we
fine
but,
like
you
guys,
really
get
that?
So
it's
only
not
trying
to
say
you
have
to
have
to
exclude
the
content
type
in
order
to
get
that
in
rates
babe
or
or
and
have
to
you
know,
could
encrypt
the
content
Mary
at
this
behavior,
but
I'm
just
saying
like
that's
the
property,
you
need,
if
you
want
threads
attack-
and
you
can
also
just
say
like
this-
is
a
dumb
attack
and
like
I'm
care
about
I,
don't
feel
true,
but
one
could
say
that.
B
So,
just
in
the
interest
of
making
progress,
I
might
make
a
suggestion
for
how
to
move
forward.
Here.
It
seems
like
there's
pretty
good
consensus
that
we
should
be
protecting
the
sender
and
generation.
We
should
do
that
that
bit
of
things
but
less
certainty
around
this
content
type
thing
like
we,
there
may
be
some
attacks
here.
B
There
may
be
significant
strains
that
make
ordering
hard
so
I'm
kind
of
I
think
what
I
might
propose
is
like
let's
go
ahead
and
do
basically
what
we've
done
on
the
slide
here,
expose
the
content
type
for
now,
but
kind
of
file.
A
new
issue
continue
to
think
about
this
or
in
question.
Think
about
whether
we
can
also
hide
this
constants
I've
been
in
a
future
version.
Does
that
seem
like
a
plausible
just
like
incremental
work
strategy
here.
D
Well,
I,
guess
we're
not!
You
know
we're
not
quite
at
the
quick
stage
where
we're
like
you
know,
having
to
you
know,
have
like
after
Congress
in
order
to
file
a
new
issue,
so
I
think
I'd
certainly
like
to
keep
that
question
know
whether
we
can
improve
the
content,
type,
open
and
I.
Think
the
question
but
I
think
that
he'd
the
question
of
whether
or
not
we're
trying
to
prevent
you
know
sort
of
a
suppression.
D
You
guys
grappa
woods
so
I
think
you
know
that
I,
don't
think
you
can
punt
I'm
happy
to
sort
of
like
Anna
faking
progress.
Take
this
take
this
this
PR
and
then
they
have
an
issue
for
the
pipe
that
we
can
get
with
later,
as
you
know,
maybe
dkj
and
I
and
others
who
care
about
this
can
sit
down
and
try
to
like
a
reason
about
a
better
way
to
do.
D
B
Yeah
I
think
the
subtext
is
that
proposal
is
I,
think
we're
trying
to
get
in.
You
know
the
next
few
weeks
to
a
person
that
where
we
can
start,
you
know,
have
a
bit
of
stability
and
a
bit
of
Interop
and
a
bit
of
analysis
and
so
like
if
we
could
go
ahead
and
address
the
sender
and
generation
privacy
in
that
version
and
then
like
in
the
next
next
version.
B
I
I
J
You
can
sort
of
answer
that
question
I.
Think
the
original
thing
of
the
common
framing
is
not
to
encrypt
the
message.
It's
just
like
to
keep
everything
and
all
the
same
message
formats,
and
the
idea
is
that,
while
we
audit,
we
might
actually
be
good
into
protecting
that
stuff,
instead
of
just
leaving
it
in
a
clear,
that's
it.
So
the
it's
actually
a
confidentiality
argument
for
the
group
for
the
group
message.
If
I
can
touch
it,
yeah.
K
So
whether
we
encrypt
it
or
not,
that's
going
to
be
the
case,
so
the
price
that
we
pay
for
encrypting.
It
should
probably
take
into
account
that
we're
probably
going
to
leak
out
information
in
a
lot
of
implementations
anyway
or
last
at
least
use
cases.
So
it's
not
clear
to
me
that
the
price
is
worth
paying.
F
This
is
dkg
just
to
respond
with
my
typical
traffic
analysis
response
here
at
the
IETF
you're
right
that
we
do
currently
tend
to
leak
quite
a
bit
of
information
in
terms
of
traffic
analysis.
If
we
go
ahead
and
make
decisions
that
say:
oh
well
too
bad
so
sad
we
might
as
well
not
bother.
Then
we
have
no
way
to
actually
push
for
doing
countermeasures
to
traffic
analysis
in
the
future,
because
they'll
say
why
bother
there's
nothing
to
protect?
F
It's
all
in
the
clear
we
there's
a
research
agenda,
that's
growing
right
now
in
academia
and
in
other
places
to
try
to
do
effective
countermeasures
to
traffic
analysis.
That
may
be
a
fruitless
project.
We
don't
know,
but
if
we
define
our
protocols
in
such
a
way
that
traffic
analysis
that
you
can't
do
a
job
counter
measure,
because
data
is
in
the
clear
then
we've
just
sort
of
voided
that
work
and
so
I
want
to
I
want
to
caution
us
against
saying
too
bad.
So
sad
traffic
analysis
wins
because
we
did.
J
Okay,
to
make
a
point
here,
I
think
the
main
problem
is
that
we
could
encrypt
everything,
Thailand
decrypt,
the
content-type,
specifically,
if
you
want,
but
at
the
cost
of
adding
to
pad
the
application
messages
at
the
same
size
as
the
maximum
size
for
check
messages,
which
is
probably
to
me
it's
unrealistic.
So
I
think
we
should.
My
point
is
that
we
should
move
to
like
as
a
first
step
at
least
move
to
just
stay
with
the
contact
in
nuclear
and
keep
the
sender
and
generation
and
do
an
extra
non
trying
to
encrypt
ethnic
sense.
F
J
F
So
I'm
saying
we
should
try
to
encrypt
it.
We
should
try
to
interpret
from
the
outset.
It
was
a
pain
in
the
ass
to
get
excuse
me
for
to
get
the
content
type
to
be
encrypted
in
TLS
and
I.
Think
it
was
worth
it
that
that
we
worked
on
that
and
I
don't
want
to
go
through
that
same
thing
again.
If
we
can
get
it
right.
The
first
time
here
so.
L
If
it
includes
update
my
concern,
if
always
want
it
to
patch
update
with
actual
user
data
message,
so
this
should
hey
was
traffic
analysis.
So
if
you
want
to
add
and
remove
only
in
this
case,
to
reveal
the
quanta
type
I'm
fine
with
this,
if
you
can
patch
update
or
merge
update
with
actual
user
data
message,
I
mean.
C
Through
that
entry,
cam
I
think
currently
update
messages,
don't
have
to
be
strongly
ordered,
yeah
I,
don't
know
how
confident
we
are
that
that
actually
works
at
this
point.
So
in
that
sense,
yes,
we
could
keep
update
messages
out
of
the
scope
of
handshake
messages,
yeah
but
again,
I'm,
not
confident
that
that
works
as
advertised.
This.
K
Is
Joelle
when
again
so
maybe
a
compromise
would
be
to
make
it
an
extension
so
that
people
who
want
to
also
go
ahead
and
implement
further
traffic
analysis?
Defenses
can
then
use
that
extension
and
the
people
who
don't
want
to
do
that.
Don't
have
to
pay
the
price
for
encrypting
content,
which
is
you
know,
only
a
partial
solution
to
a
problem.
So
maybe
that's
a
good
compromise
know.
D
What
wasn't
I
think
I
think
I
liked
Rich's
proposal,
which
is
people
this
topic
for
a
little
bit,
I
mean
we're
going
to
get
shot
on
a
chaton
wire
about
there
other
ways
to
attack
this
problem.
That
might
actually
give
you
both
favors.
You
want
so
I
think
like
this,
like,
like
the
so
like
well,
I
would
just
is
like
we
take
mrs.
D
ringing,
one
which
is
like
clearly
like
easier
to
execute
on
and
least
the
content,
nuclear
and
because
I
don't
think
this
is
the
way
I'd
probably
want
to
encrypt
it
on
the
type
or
you
want
to
you
want
say
you
want
to
you
want
to,
but
you
boil
the
can
type
be
the
clear
right:
okay,
I
guess:
resumes
you're
right,
you're
right!
Sorry,
my
mistake,
you're
right!
Sorry,
it's
a
lot
along
with
long
night,
so
yeah
I
mean
I.
Think
like
like,
given
the
new
census
and
crooking
these
things.
D
Let's
go
ahead
with
this
and
I'm
like.
If
we
figure
out
good
way
to
do
the
content
type,
then
we
can
definitely
do
it.
If
we
don't
forget
a
good
way
to
kind
of
type
them
like
we
can
fight
about
whether
the
bad
way
is
better
than
like
the
thing
we
got
but
like
I
I
guess
you
know
that
commitment,
you're
making
is
like
we're.
Gonna
keep
this
thing
up
an
issue
or
we
examine
it.
Not
just
we're
gonna
like
front
of
the
floor,
but
I'm
like
happy
to
do
that.
A
C
So
this
is
something
that
we
started
discussing
at
ITF
103
specifically,
this
only
has
to
do
with
performance.
That's
a
reason
here.
What
we're
trying
to
improve?
It
is
not
to
increase
security
or
privacy
at
this
point,
and
so
what
was
identified
is
a
bottleneck
situation
where,
in
a
multi-device
context,
device
is
being
added
to
an
account
and
then
has
to
be
added
to
all
of
the
groups
of
that
user.
C
So
as
a
reminder,
typically
messaging
systems
that
are
being
actively
used,
there
are
many
groups
and
most
of
these
groups
they're
inactive,
because
at
some
point
people
were
added
to
the
group.
They've
interacted
a
bit
and
then
the
group
dies
after
a
while
and
there's
typically
no
particular
recycling
around
that,
but
so
we're
in
a
position
now
where
we
keep
up
the
stage
of
the
crypt
around
that
group.
C
So
one
proposal
that
has
been
made
is
that
we
could
cryptographically
shut
down
groups
that
are
in
inactive
after
a
while
and
just
keep
them
on
the
clients,
basically
and
and
reactivate
them,
if
necessary.
So
that
is
one
way
of
solving
that
problem,
but
that
inherently
means
that
MLS
is
not
really
capable
of
having
many
open
groups
at
the
same
time
in
a
messenger.
C
How
does
it
work?
A
regular
update
has
the
whole
direct
path
in
it,
where
it
Kem's
the
value
of
the
parent
to
its
sibling
for
every
level
of
the
tree
in
a
lazy
update,
really
only
the
leaf
node
of
the
sender
would
be
replaced
and
we
only
send
a
public
key
to
the
group
so
to
make
that
more
clear
visually
on
the
right.
C
C
So
what
is
the
immediate
net
result
of
that
is
that
actually
no
crypto
is
done
other
than
creating
that
leaf
node.
So
this
is
a
very
fast
operation,
because
you
don't
have
to
do
multiple
defilements
and
potentially,
we
can
even
reuse
a
leaf
node
across
different
groups.
So
this
remains
to
be
seen
in
analysis.
C
What
the
consequences
are,
if
you
do
that,
and
so
this
new
leaf
node
can
be
used
by
everybody
else
in
the
group
for
hpk,
so
you
can
can
values
to
it,
but
it
needs
to
be
quite
clear,
so
we
don't
have
any
security
around
that
yet
because
we
haven't
changed
the
keying
material
at
all.
These
cutters
are
still
the
same,
so
we
don't
have
any
for
secrecy
and
we
certainly
don't
have
any
pcs.
C
L
And
this
is
exactly
what
I
was
saying
earlier.
If
you
can
batch
update
was
through
with
a
message,
because
you
are
fine
as
long
as
no
one
is
sending
anything
to
keep
the
state
as
with
you
updates,
but
you
need
to
regular
updates
once
someone
send
a
new
data,
so
in
this
case
it
makes
more
sense
to
merge
post
messages
in
one
big
message
like
update
and
the
new
message
data.
If,
if
you
can.
L
C
Mean
an
update
combined
with
an
application.
My
subject:
ok,
yeah
I
mean
this
would
indeed
be
the
case.
So
if
we
imagine
a
scenario
where
we've
had
a
number
of
lazy
updates,
because
a
group
is
completely
inactive
and
then
somebody
wants
to
send
a
message,
an
application
message,
then
that
client
has
to
first
issue
an
update,
that's
true
so
looking
at
the
cost
of
it.
C
So
the
regular
update
is
at
least
as
expensive
as
it
would
have
been
had
it
been
issued
initially,
instead
of
the
lazy
update,
potentially
a
little
more
expensive,
because
the
tree
is
more
fragmented
now,
but
the
the
difference
is
this
can
be
paid
by
anyone.
So
now
we
can
make
it
about
what
client
or
what
member
has
better
resources
so
practical
terms,
a
desktop
PC,
but
really
and
a
good
internet
connection,
has
fewer
problems
to
do
that
than
say
no
to
Android
device.
C
Of
course,
it
comes
with
a
number
of
security
implications
that
we
would
have
to
look
at
very
carefully,
so
Lacey
update,
introduces
state
that
is
in
between
epics,
because
the
old
epic
is
no
longer
valid,
so
lazier
pet
could
mean,
for
example,
that
device
has
been
removed
from
a
user
account.
So
we
shouldn't
use
any
key
material
from
an
epoch
anymore,
but
we
don't
have
a
new
epoch
yet
so
we're
in
this
void
between
two
epochs.
C
K
C
Device
mode
where
you
have
a
virtual
client
that
basically
has
a
subtree
with
origin
devices.
If
you
remove
the
device
from
that
account,
it
leads
to
change
in
the
subtree
which
one
gets:
a
new
root
root,
node
value
which
triggers
an
update
in
whatever
group
that
user
is
in.
So
when
you
see
a
lazy
update,
you
don't
know
whether
it
is
because
somebody
has
added
a
device
or
removed
a
device.
You
have
to
assume
the
worst
case,
which
is
somebody
has
removed.
C
So
a
little
more
context
here,
Alessia
players
are
very
similar
to
ads.
The
structure
is
similar.
We
don't
need
an
index
because
we
lazy
app.
That
really
only
can
be
done
for
yourself,
so
the
sender
is
implicit
here
and
the
difference
is
also
what
I
just
said
so
ads
don't
really
require
PCs.
We
said
that
it's
good
enough
to
afford
secrecy.
If
our
group
agrees
on
ratcheting
the
the
existing
key
matter
material
forward,
we
don't
need
any
new
freshness
for
ads,
but
since
lazy
updates
are
not
necessarily
only
ads,
that's
what
breaks
the
security
promises.
C
Yeah
and
then
there
could
also
be
a
lazy
remove
that
works
in
a
similar
fashion.
I'm,
not
true
a
particular
problem
that
would
solve
right
now,
but
at
the
very
least,
it's
something
that
could
be
considered
if
it
makes
sense
so
there.
We
would
basically
tell
the
group
to
remove
a
certain
participant
in
a
certain
spot
in
the
roster,
and
then
the
direct
path
of
that
leaf
is
also
being
blanked.
But
there
is
no
new
freshness
until
an
update
is
being
issued.
C
When
I
come
to
the
questions,
so
the
the
first
question
is:
are
there
better
ways
to
address
bottlenecks?
I
mean
this
is
one
proposal.
Maybe
there
is
much
better
one
and
in
case
we
wanna
investigate
this
further.
What
are
the
security
implications?
Do
we
understand
them
well
enough
at
some
points
to
to
be
confident
here.
I
I
One
thing
that
was
true
in
the
original
ERT
proposal
and
we
would
like
to
preserve
I
think
as
we
go
and
do
modifications
and
the
protocol
is
that
we
should
have
a
pretty
easy
to
understand,
invariants
that
are
true
for
the
tree
at
any
point
in
time
whether
we
are
in
an
intermediate
state,
after
lazy
update
or
at
the
end
or
whatever,
and
the
more
intermediate
states
like
this,
where
somebody
has
updated
their
key
but
not
yet
updated
the
good
key.
We
have
the
more
delicate
those
invariants
become.
I
I
Think
at
any
point,
if
I
take
the
state
of
the
group
that
I
have
in
my
device,
if
I
can
say
something
about
it,
that
it
is
somehow
consistent
internally,
that
actually
gives
me
a
much
stronger
basis
for
reconciling
and
things
go
wrong,
and
there
are
too
many
cases
here
which
you
will
have
to
think
about
carefully
about
how
different
people
with
different
intermediately
the
update,
States
interact
and
whether
we
can
actually
practically
prevent
them
from
making
actions
between
these
two
states,
which
I
don't
understand.
Well
enough.
At
this
point,.
C
Okay,
yes
I
think.
The
conclusion
is
here
is
that
at
ITF
103
we
raised
some
awareness
about
potential
bottlenecks
in
general.
Now
we
have
a
concrete
proposal
here,
but
more
work
needs
to
be
done,
particularly
on
the
analysis
side
to
move
forward
with
that.
But
nonetheless
we
have
this
proposal
now,
and
that
is
something
that
can
be
kept
in
mind
when
proposing
other
changes
to
see
and
to
what
extent
would
be
compatible
with
that
yeah.
B
B
I
do
think
that
there
is
sort
of
a
potential
like
refactoring
of
the
the
algebra
of
these
things
like
it
seems
like
you
could
express
an
add,
as
lazy,
add,
plus
update
for
instance,
or
remove
as
lazy,
remove,
plus
update
so
I
mean
there
may
be
some
conceptual
simplification
to
be
had
here,
for
you
tease
out
those
primitives
I'm,
just
not
sure
the
complexity.
You
know,
as
it's
currently
expressed,
don't
quite
understand
what
the
complexity
implications
are
right.
G
A
Right
thanks
mom
you're
next,
so
this
is
an
individual
submission
draft
that
we
a
mod
brought
this
idea
up
in
the
interim.
This
is
an
individual
submission
draft
that
essentially,
is
not
gonna,
hide
it
or
considering
we're
doing
a
working
group.
Adoption
call
so
think
of
this.
This
presentation,
in
that
vein,
Thanks.
L
Okay,
listen
tomorrow.
We
approach
this
up,
doing
venture,
not
June,
and
there
was
some
support
for
it.
Since
then,
Raphael
and
I
submitted
this
draft
and
we're
looking
for
I'll
go
through
today
during
the
use
cases
for
Federation's
summit
challenges
and
I'm,
not
looking
for
any
solution
for
these
changes.
Just
if
there
is
interest
in
this
talk
we'll
try
to
solve
it
together
later,
but
not
today,
so
the
goal.
L
L
So,
in
this
case,
MLS
would
be
implemented
in
the
browser
and,
if
you
communicate
through
the
app
through
the
JavaScript,
API
and
Emily
since
the
process
just
committed
to
deliver
service
to
retrieve
kids,
a
more
concrete
use
case
is
using
MLS
in
the
product
set
up
into
indicated
conference
calls
like
what
we
call
MLS
a
subsidy.
If
you
have
something
like
this
can
easily
keeps
change,
multiple
use,
MLS
to
bootstrap
the
calls
and
key
updates
when
we
will
join
unrolls.
Of
course,
another
use
case
is
different.
L
So
in
this
example,
we
have
like
group
of
four
people
ABC,
and
there
are
two
clients
from
their
service
B,
so
on
be
one
shot,
send
message
to
the
group.
If
it
does
client
found
out,
it
has
to
contact
all
delivery
service,
including
itself,
and
then
HTTP
service
will
just
connect
it
to
their
client,
so
he
will
send
them
at
the
river
service
a
and
B
and
C,
and
in
every
service
we
just
forwards
a
message.
This
might
not
scared.
L
On
the
other
hand,
server-side
sign
is
the
same
scenario.
P
will
just
send
some
message
to
its
deliver
service,
which
proxy
all
deliveries
for
other
devices
levels
so
be.
The
recipe
was
different,
a
message
to
be
to
user
and
to
later
service
a.m.
and
see
which
there
is
a
message
to
the
user.
So
what
does
call
is
this
world,
so
we
are
only
focusing
with
the
crepe
to
layer,
some
other
stuff
without
scope
for
now.
So
it's,
for
example,
mapping
between
user
ID
and
watch
TV
series
to
talk
towards
their
eluded
exhibits.
L
So
the
requirements
we
see
for
now
is
to
define
the
message
for
receiving
user
and
it
gives
an
identity.
Kids.
What's
request:
what's
our
format
of
the
request
and
the
response,
so
the
request
should
have
the
remove
user
ID
and
what,
while
my
local
support,
is
separate
sweets
as
symbolizes
the
response
would
be,
a
list
of
user
need
keys,
you
want
for
each
device
and
h8
key
would
also
have
a
long-term
identity
key
again.
This
is
the
change
we
see
right
now
and
I.
L
Don't
I'm,
not
looking
for
an
institution
for
them
today,
but
I
just
setting
them
up
like
was
most
well.
Most
of
them
are
actually
coming
from
multiple
service
areas
or
even
singles
every
service.
Most
of
them
are
it's.
It's.
Ok,
it's
the
same
ones
we
have
today,
but
when
wants
whatever
service
distance
becomes
much
more
complicated,
like,
for
example,
how
to
do
version
cipher
Suites.
Should
we
do
another
version
musician
beside
what
we
have
today,
neither
any
keys
I.
L
We
might
end
up
doing
so
because
they
don't
currently
what
working
each
each
provider
has
and
again
handshake
message
or
drink
better
of
water.
I
was
singing
like
if
we
really,
if
chicken
look
really
requires
handshake
message
ordering
how
this
can
be
achieved
with
multiple
service
at
how
we
synchronize
the
whole
time
meter
data
sharing
like
if
the
state
served
in
the
diversity
of
its
like
rooster
or
any
Lube
state.
L
If
you're
really
mostly
raised
here,
it's
how
this
can
be
seen,
cries
across
all
of
them
and
lost
one
multi-device
like
if,
like
after
you
start
a
group
and
one
device
is
removed
from
provided
provider
a.
How
do
you
identify
other
providers
in
the
group
like
this
device
has
been
removed
or
added,
etc,
etc,
and
that's
it
so.
The
question
is:
are
we
will
interested
in
Federation
is
given
general
and
work
together?
So
I
can
just
speak
for
myself
and
and
I'm
representing
Google
and
refer
everything
to
choir
or
Haiti
interested
in
system.
D
D
F
A
So
Daniel
on
that
point,
the
the
Charter
is
written
to
preclude
Federation
of
the
application
layer,
but
it
is
open
to
doing
stuff
with
the
crypto
layer.
So
technically
it's
in
scope,
we've
kind
of
talked
with
Ben
about
whether
or
not
it
would
work
but
I
guess.
Your
point
is
whether
we
should
do
this
now
or
later,
or
what
right
I
mean.
F
M
N
Basically,
you
you
end
up
having
to
I,
have
thought
about
this
quite
a
lot
and
you
sort
of
end
up
having
to
create
channel
bindings
that
are
consistent
and
holds
a
lot
of
states
just
because
otherwise
you
can't
actually
prove
that
everyone
agrees
on
which
MLS
session
is
being
used
in
the
later
protocol.
So,
if
you're
running
a
some
sort
of
voice
chat
protocol
separately
over
the
top
of
this,
it's
you
can't
just
say
yes,
we're
using
this
group
ID
and
assume
everything
will
be
fine,
that
it's
it's
quite
complicated.
O
So
:
James
I
think
it's
really
interesting
and
we'd
be
interested
in
using
it
sort
of
you
know
said
we
would
probably
build
products
that
took
advantage
of
this.
We've
been
going
down
that
path
already
with
not
in
a
browser
case
which
doesn't
require
any
standardization
for
almost
every
use
case
you
can
think
about,
but
as
soon
as
you
want
to
do
it
in
a
browser,
I
think
we
need
standardization
of
how
that
would
all
work.
So
we'd
be
very
interested
in
seeing
that
before.
B
Observation
in
question:
you
know,
observations
like
I,
think
they're
thinking
about
the
right
time
in
the
lifetime
of
the
group
to
do
this
work.
It
seems
like
for
this
for
work
like
this.
To
make
sense,
you
need
to
have
kind
of
the
API
of
the
underlying
protocol
be
stable.
You
need
to
know
like
what
needs
to
be
sequenced.
You
need
to
know
like
when
you
need
user
Niki's
and
how
those
what
those.
B
On
I
think
the
good
news
I
think
we
do
have
that
pretty
stable
at
this
phase
of
the
protocol.
So
I
think
this
is
it's
an
appropriate
time
to
start
looking
at
this
sort
of
work,
the
question
I
had
is
like
what
degree
of
kind
of
concreteness
of
protocol
are
you
looking
at
thinking
about,
like
is
this
kind
of
a
general
abstract
protocol
that
you
might
implement
in
different
ways
in
different
context?
You
thinking
about
making
like
an
actual
concrete
definition
of
how
you'd
handle
this
stuff
room
so.
F
Them
this
is
dkg
I
just
want
to
clarify
my
earlier
comment,
because
I
realized
I
might
have
displayed
enthusiasm
for
some
parts
that
I'm
actually
not
enthusiastic
about.
So
there's
these
two
different
there's,
these
two
different
use
cases
that
you've
got
here
right.
You
got
this
this
one
up
here
this
on
the
screen
right
now
and
then
and
then
you've
got
right.
F
So,
if
anyone's
listening
to
the
audio
channel
I'm
much
more
excited
about
the
other
one,
the
one,
that's
not
on
the
screen
right
now,
I'm
more
excited
about
the
idea
of
different
clients
in
different
delivery
services
that
I
am
about
the
operations
in
the
browser.
I'm,
not
saying
that
it
shouldn't
happen.
The
browser,
but
I
want
to
point
out
that
we
have
done
it's
been
very
difficult
for
us
to
get
browsers
to
the
point
where
users
have
some
sense
of
who
they're
talking
to
in
the
browser.
Yes,.
F
Tnt-
and
we
have
this
regular
fight
in
TLS
I'll-
keep
trying
to
keep
TLS
a
two
party
protocol
and
if
we
decide
to
try
to
make
some
sort
of
standard,
MLS
multi-party
protocol
in
the
browser,
I
think
that
the
security
model
for
what
people
think
is
happening
in
the
browser
will
be
even
more
disastrous
than
it
currently
is
a
grass.
Is
it
possible
to
be
even
more
disastrous
than
the
current
browser
security
model?
Yes,
it
is,
and
I'm
warning
us
like.
Let's
make
sure
we
don't
make
it
worse
sure.
L
I
Karthik
alcaman
India,
so
in
general
the
I
mean
I
think
this
is
a
desirable
feature
to
have
one
thing
that
I'm
a
bit
concerned
about
and
like
to
understand
better
is
that
in
standard
MLS
every
member
actually
knows
the
full
membership
of
the
future
roster
full
group
stated
stuff.
Federation
will
naturally
lead
a
fear
to
cases
where
one
organization
would
like
to
hide
some
part
with
free
from
the
other,
so
I
mean
just
as
a
maybe
of
composing.
I
These
things
you
may
not
actually
want
to
transfer
the
whole
tree
state
between
the
two
now
I
think.
The
proposal
here
is
actually
we
do
actually
it's
completely
transparent,
it's
just
going
from
multiple
delivery
services,
but
that's
not
how
other
federated
systems
what
they
do
hide
things
underneath
sub
trees,
yeah.
L
I
The
moment
we
kind
of
expand
out
those
kinds
of
use
cases
and
if
one
of
them
actually
becomes
the
standard,
one
I
think
the
the
security
analysis
becomes
much
more
interesting
and
we
need
to
think
more
about
it
because
also
so
far,
we
have,
since
with
one
delivery
service,
you've
actually
said,
there's
very
little
trust
in
the
delivery
service.
There's.
I
The
authentication
service,
but
not
much
in
the
delivery
service
and
with
multiple
authentication
services
and
in
delivery
services.
We
will
have
to
think
more
closely
about
what
subsets
of
things
could
get
compromised
and
what
guarantees
we
get
and
so
on
I,
as
such
I
think
we
just
are
assuming
that
all
of
them
are
are
trusted,
and
that
would
be
the
only
default
case
we
would
have.
So
this
is
not
giving
a
central
decentralization
for
sure
it's
the
Magus
Federation,
but
we
don't
get
any
yeah.
That's
correct!.
B
Richard's,
just
just
to
be
clear,
I
would
expect
whatever
federated
thing
we
end
up
with
here,
to
have
the
same
security
properties
in
terms
of
authentication
invisibility
that
the
base
protocol
has
right.
This
is
just
talking
about
how
you
tie
together
multiple
delivery
services
and
like
distribute
that
crypto
conversation
over
multiple
delivery,
like
it's
just
a
change
of
transport.
F
This
is
you
just
want
a
second
Richards
point
there.
In
fact,
the
assumption
right
now
I'm
actually
a
little
bit
concerned
that
we've
just
made
the
assumption
that
all
devices
will
be
exposed
to
the
delivery
service
because
I,
my
understanding
was
that
we
have
this
ambiguity
in
the
protocol
that
I
actually
prefer,
which
is
that
I
don't
need
to
expose.
My
devices
I
can
potentially
use
my
own
EMA
internal
MLS
session
so
that
my
own
devices
can
share
can
can
produce
a
key
that
then
becomes
one
key.
That's
part
of
an
MLS
session.
F
I
actually
I
actually
think
that,
if
we're
making,
if
we're
gonna,
make
an
architectural
decision
that
explicitly
says
all
devices
need
to
be
exposed
directly
to
the
livery
service.
I
think
that's
a
mistake.
I
don't
want
to
run
this
in
that
operation,
and
so,
if
you
think
that
the
cryptographic
analysis
changes
significantly
when
we've
got
subtrees
I
want
to
know
I
want
to
know
what
those
differences
are,
because,
to
my
mind,
that
metadata,
hiding
is
actually
a
useful
thing
and
I
would
I
would
hope
that
people
would
push
for
that
to
be
the
default
sure.
L
I
would
literally
responses.
I
know
he's
working
multi
devices
story,
but
what
the
architecture
doctor
draft
has
to
date,
assuming
all
devices
are
exposed
like
issued,
but
has
its
own
identity,
which
you
can't
change,
but
I
don't
want
to
like
limit
the
Federation
conversation
to
the
multi
device,
a
story
we
can
just
take
like
a
response
from
people
like
spin
I,
don't
reverse
the
topic,
but
I
know
like
Rafael
and
I
are
working
on
like
on
multiple
story
and
I
can
respond
it
into
more
decades.
L
C
Just
like
to
answer
that
that
I'm
currently
in
the
process
of
writing
up
something
and
then
others
which
I
mean
as
well
to
clearly
document
how
the
to
multi
device
modes
we've
been
thinking
about
actually
work
and
also
so
that
we
can
then
see
how
that
works.
Security
wise
in
terms
of
analysis,
because
for
now
we've
been
floating
these
have
years,
we've
been
saying
we
can
hide
devices
of
a
certain
user
account
under
a
private
subtree,
but
we've
never
really
written
it
up.
We've
never
thought
about
all
the
consequences
of
that.
C
So
this
is
something
that
is
going
to
happen
now
and
that
becomes
even
more
relevant
in
the
context
of
Federation.
Of
course,
so
I
don't
really
see
how
it
is
mandatory
that
all
devices
are
exposed
in
the
sense
that
if
we
are
confident
with
the
mode
where
devices
are
hidden
behind
a
virtual
client,
that
is
something
that
can
absolutely
be
used
in
Federation
and
then,
therefore,
nothing
is
leaked
around
individual
devices.
I
To
clarify
what
I
was
saying
earlier,
I:
don't
think
that
all
devices
are
exposed
to
the
delivery
service,
but
I
think
all
devices
are
exposed
to
all
other
members
of
the
group.
That's
where
the
same,
so,
in
our
analysis,
actually
one
of
the
architectural
goals
was
that
when
I
receive
a
message,
I
know
who
the
rest
of
the
members
of
this
group
are,
and
this
members
is
an
abstract
thing
right
now,
it's
clients,
maybe
one
day
to
be
users
or
whatever.
Now
hiding
devices
is
actually
a
great
idea.
I
But
if,
as
long
as
we
were
saying
that
we
are
hiding,
all
the
devices
belonging
to
a
single
user,
I
could
still
kind
of
get
away
with
it.
Best
thing
are
the
member
is
actually
the
user
who's
hiding
his
devices.
Underneath
now,
if
you're
gonna
say
that
oh
the
members,
what
I'm
gonna
hide
is
actually
a
group
of
all
Google
members,
I
hidden
actually
from
all
Facebook
members.
A
So
it's
great
that
the
draft
doesn't
answer
all
the
questions.
There's
actually
some
work
to
do,
which
is
what
the
working
group
would
do.
So
what
I
want
to
know
is
there?
Would
there
be
anybody
that
would
be
in
violent
objection
of
adopting
this
as
a
working
group
draft?
Okay?
So
with
that
said,
and
since
it
only
came
out
like
two
weeks
ago,
I
think
what
we'll
do
is
we'll
take
the
working
group.
Adoption
call
to
the
list,
and
so
like
I
said
that
seemed
like
there
was
support
here.
A
I
will
note
that
in
the
message
that
we
simple
list,
then
people
can
chime
in
there
so
that
we
can.
We
can't
we
can
do
our
consensus,
call
from
based
on
that
all
right.
Thank
you.
Thank
you
very
much
month
and
next
we
have
deniability
so
hopefully,
Sophia
is
there
online
I
see
her
now,
hopefully,
she'll
hit
the
button.
P
P
Nice
there's
no
question
when
I
want
to
change
this
light.
I
have
to
say
next
right:
yes,
okay,
awesome,
so,
okay,
hi,
my
name
is
Sofia
and
I'm,
going
to
present
about
an
ability
in
a
group
shot
setting
just
a
little
bit
exclaim
around
here.
This
came
up
because
we
were
doing
a
review
of
the
from
from
the
OTR
world.
We
were
doing
a
review
of
the
current
drops
of
MLS
and
we
noticed
in
certain
parts
there
was
some
references
to
unlink
ability
and
repeatability,
so
we
were
wondering
the
in
deniability,
repeatability
or
unlink.
P
Ability
was
actually
something
that
MLS
wanted.
So
I
wanted
to
make
this
presentation
to
see
if
people
actually
want
an
ability
in
it
or
not,
or
what
limitations
do
they
want
so
yeah?
Next,
okay,
so
just
a
little
context.
That
is
sure
that
everybody
or
almost
everybody
in
the
room
already
know.
Of
course,
an
ability
come
from
the
first
proposal
of
OTR,
a
messaging
protocol
in
which
it
was
proposed,
the
idea
of
secure
communication
and
having
a
secure
way
in
which
messages
and
encrypted
unsigned.
P
But
at
the
same
time
that
you
have
this
identification
through
the
use
of
usage
of
signing,
you
will
also
have
a
deniable
way
of
actually
authenticated
a
participant
into
a
conversation,
and
this
came
from
the
idea
when
OTA
was
first
proposed
that
secure
communication
over
the
digital
world
should
actually
mimic
what
is
action.
What
is
often
referred
as
real
casual
war
conversations
and
in
real
culture
war
conversations
you.
P
The
people
often
have
deniability
in
the
sense
that
and
no
one
can
actually
prove
to
anybody
else-
that
someone
participated
into
a
real
conversation
or
said
something
in
the
conversation
or
sometimes
even
that
the
conversation
actually
took
place.
Other
protocols
took
in
pure
inspiration
from
OTR
for
these.
The
the
signal
protocol
took
inspiration
from
these
their
own
protocol.
P
Okay.
So
basically,
what
is
the
nobility
I'm
sure
that
most
of
the
people
here
know
it's
basically
the
property,
but
anyone
can
actually
deny
having
said
something
and
go
in
a
conversation
or
have
been
participated
into
a
conversation.
This
is
often
accomplished
by
the
use
of
for
ability
of
malleability
inside
of
protocols.
What
the
nobility
is
not
is
that
it
doesn't
prevent
from
someone
knowing
that
a
conversation
took
place.
The
only
thing
is
that
there's
no
link
between
the
identity
of
someone
and
the
fact
that
the
conversation
took
place
next.
P
Okay,
okay,
so
I
also
wanted
to
give
a
little
overview
of
the
different
properties
that,
in
general,
secure
messaging
protocols
have,
and,
of
course,
this
is
defined
by
a
very
well-known
paper
that
was
written
by
Ugarit
al,
in
which
there
was
this
little
bit
of
listing
of
the
properties
that
a
secure
messaging
protocol
should
have,
of
course,
there's
arrays
and
properties.
That
I'm
sure
people
know
here,
but
important
was
in
terms
of
deniability
is
of
course
identification.
P
Something
that
iam
Cobra
has
defined
in
terms
of
identification
is
that
it
should
be
entity
identification,
meaning
that
if
someone
proves
that
that,
in
order
to
prove
the
proof
that
our
public
key
actually
belonged
to
someone,
you
have
to
prove
knowledge
of
the
secret
key
related
to
that
and
origin
authentication,
in
the
sense
that
you
will
also
have
to
prove
that
there's
a
well-defined
search
from
which
a
message
come
from.
Of
course,
in
terms
of
group
shots,
something
that
is
very
very
important
is
to
have
good
participation.
P
Participation
Sisseton
see
that
some
people
have
already
talked
here
in
the
room
s
PP
speaker,
consistency
tells
us
how
solid
seven
and
a
global
transcript,
and
these
properties
are
actually
very
important
when
talking
about
the
nobility,
because
some
of
these
properties
gets
limited
because
of
actually
pushing
some
deniability
properties.
So
next.
P
P
Basically,
these
two
properties
are
actually
called
message:
deniability,
because
this
actually
talks
about
the
fact
that,
if
you
are
having
a
conversation,
you
can
deny
having
silence
that
message
and
there's
another
property
related
to
that
to
this,
which
is
participation
deniability,
which
actually
says
that
someone
should
candy
and
I
haven't
participated
into
a
conversation.
This
other
properties
that
are
actually
also
related
to
deniability
and
I
related
to
the
fact
that
the
nobility
properties
are
pushed
into
groups
out
there,
for
example,
trust
equality.
Why?
P
P
Next
and,
of
course,
there's
all
the
additional
properties
that
are
fundamental
to
group
chat
like,
for
example,
out
of
order,
resilience
and
drop
master
resilience,
I'm
sure
that
is
something
that
MLS
actually
wants,
because
one
of
the
goals
that
I
heard
that
MLS
wanted
in
the
real
world
crypto
from
presentation
is
that
they
wanted
to
be
protocol.
That
is
asynchronous.
So
this
is
basically
a
property
of
a
synchronous
module.
Next.
P
Okay
and
now
to
talk
about
the
new
ability
properties-
and
this
is
something
that
we
have
been
pushed
forward
in
version
4
of
ogia.
As
I
said
in
the
past,
there
was
dis
terms
about
repeatability
and
linked
to
ability
right
now
in
the
current
papers
and
academia,
small
often
refer
only
as
deniability
and
then
I
ability
now
is
Austin
results
in
terms
of
George,
a
person
that
is
judging.
P
There
should
be
in
a
way
to
provide
evidence
of
participation
rather
than
someone
said,
a
message
in
the
conversation
and
of
them
offline
deniability,
which
is
often
the
one
that
we
often
think
about,
because
it
is
the
one
that
we
explain
when
when,
after
the
fact
that
that
conversation
happened,
if
you
have
a
transcript
someone
or
anyone
could
have
generated
that
transcript
next,
ok
and
what
work
has
been
already
done.
The
first
work
that
was
already
done
was
by
buying
at
Al,
and
it
was
the
first
working
working
which
there
was
this.
P
These
trust
on
a
server
to
actually
to
actually
create
a
group
chat
and
give
deniability
property
sweet,
but
it
was
proven
by
a
young
Goldberg
at
our
that.
Well,
it
was
actually
another
good
construction
because
he
put
a
full
trust
on
the
server
because
of
this
I
incorporated
I'll
propose
the
first
multi-party
of
the
record
messaging,
but
it
has
also
been
proven
that
he
didn't
give
all
the
deniability
properties
that
they
that
it
was
wanted
and,
of
course
he
didn't
give
forward
secrecy.
P
What
I
did
in
ability
properties
of
the
signal
protocol
in
the
terms
of
our
group
shot
so,
for
example,
the
new
properties
of
the
mobility
of
like
on
land,
reliability
and
also
in
the
nobility
have
not
been
proven
in
in
this
kind
of
charge.
There
has
been
some
other
research
is
currently
happening,
especially
late,
but
Nikolas
Cooper.
That
is
actually
trying
to
push
these
new
properties
of
the
nobility
into
a
group
chat
session.
P
Next,
of
course,
then,
just
to
briefly
say
about
the
limitation
just
to
people
know,
of
course,
there's
no
clear
still
today,
no
clear
understanding
which
properties
I
can
actually
be
achieved,
but
a
group
shot
setting
in
terms
of
deniability
because
him,
because
there's
no
good
understanding
of
hub
offline,
the
nobility,
and
only
in
deniability.
We
look
in
a
group
shot
setting,
there's
also
another
good
analysis
of
what
types
of
the
nobility
have
been
actually
given
by
the
protocols
that
I
just
referred
to.
P
There's
only
one
table
of
comparison
that
has
been
done
by
Nicholas
Hooper
at
all,
so
there
has
not
been
a
really
good
analysis
of
it
and,
as
I
said,
there's
no
inclusion
with
the
new
definitions
and
deniability.
The
new
definitions
are
just
being
pushed
forward
in
the
last
few
years,
so
yeah
so
in
terms
of
MLS
I
will
say
this
can
be
something
to
be
pushed
forward.
P
But
if,
for
example,
the
working
group
decides
that
I
only
want
some
kind
of
the
nobility
properties
that
were
already
defined
in
the
past,
that's
also
that
can
be
done.
But
the
limitations
are
very
good
will
really
be
because
in
the
sense
that
there
has
not
been
a
real
analysis
of
what.
How
can
the
nobility
properties
will
look
like
in
a
group
chop
setting
next
yeah
and
that's
all
I-
try
to
keep
it
very
short,
because
I
didn't
have
a
lot
of
time
and
there
is
the
reference
if
people
want
to
read
it.
But
thank.
P
C
So
just
want
to
bring
up
that.
There
have
been
some
discussions
about
a
relatively
cheap
version
of
deniability
that
could
be
combined
into
MLS.
That
would
probably
give
you
message
deniability
and
that
will
essentially
work
like
sender,
keys,
with
signal
where
the
signature
key
would
be
delivered
out
of
band
over
a
deniable
channel
so
that
when
the
message
is
assigned
with
that,
you
cannot
directly
tie
that
to
an
identity.
But
it's
not
a
very
strong
norm
of
deniability,
but
it's
something.
C
P
I
so
because
there
was
a
response
to
an
email
around
that
and
I
saw
about
that.
It's
just
what
you
want
to
tane
about
the
inability,
because
it's
completely
fine,
if
a
protocol
in
its
security
property
says
something
like
we
only
achieve
weak
message
deniability
in
this
sense.
That
is
completely
fine,
but
I,
don't
know
if
that
is
something
people
will
want
to
attain
in
the
working
with.
E
Nalini
organs
inside
products,
I
think,
if
we
do
something
like
this,
it
should
be
optional
because,
for
example,
a
lot
of
our
enterprise
customers.
If
they
want
their
there,
you
know
they're
mandated
to
you,
know,
watch
certain
trades,
certain
customer
interactions,
and
so,
if
we
transparently
tell
them
that
we're
monitoring
your
call
for
you
know,
service
or
whatever,
and
then
later
we
can't
prove
that
we
did
that.
That
gets
us
into
trouble
with
regulators.
P
Yeah
I
think
I
will
agree
on
that.
There
was
I
did
have
issue
that
the
work
you
hard
about
if
they
wanted
to
have
like
completely
deniability,
no
deniability
or
like
optional
deniability.
Maybe
something
that
would
be
nice
is
actually
giving
us
optional,
because
they
will
give
users
of
the
a
choice
between
what
they
actually
want
to
eat.
This.
F
Is
Daniel
Carr
Gilmore
I
just
want
to
observe
that
anybody
who's
doing
current
to
left,
knee
or
sms-based
customer
service
has
already
has
this
problem
with
deniability,
because
those
protocols
don't
offer
any
cryptographic
assurances
whatsoever.
So
if
we
think
that
regulators
are
going
to
take
issue
with
lack
of
cryptographic,
verification
which
is
what
we're
talking
about
here
for
deniability,
then
those
regulators
are
severely
under-resourced
at
present.
Q
Halawa
strong,
just
one
thing,
I,
don't
understand,
might
be
obvious
when
you
say
to
my
ability:
do
you
mean
deny
towards
anyone
who
was
who
was
not
a
member
of
the
group
at
the
time
or
deny
including
two
members
of
other
group
of
members
the
way
and
the
group
at
the
time?
Okay,.
P
When
you
are
having
a
conversation
with
some
group
members
of
the
chart,
you
will
have
two
that
the
people
on
the
group
channel
will
actually
have
to
know
that
they
are
talking
with
the
right
person.
That's
why,
in
the
terms
of
deniability
often
code,
then
I
will
authenticate
it,
because
the
people
that
is
actually
talking
through
the
child
with
do
need
to
know
that
they
are
talking
to
the
right
person
to
the
authenticated
person,
but
anyone
actually
looking
from
their
side
after
the
conversation
happen
should
not
be
able
to
provide
proof
of
that.
P
Q
B
B
That
said,
I
think
it
would
be
interesting
to
look
at
kind
of
some
cost-benefit
trade-offs.
Here
sounds
like
you
know,
there's
these
various
flavors
of
deniability.
You
know
I
think
it
would
be
interesting
to
see
what
are
some
of
the
approaches
that
one
might
take
to
adding
this.
As
a
an
optional
feature
of
the
protocol,
we've
discussed,
as
Raphael
pointed
out
some
kind
of
exterior
versions
where
you
could
kind
of
set
the
the
inputs
to
the
protocol
to
things
that
would
be
deniable
and
there
might
be
some
other
more.
B
P
A
Thanks
a
lot
for
this
presentation,
my
summary
is
that
we
should
explore
this
idea
of
deniability,
maybe
thinking
about
it
as
an
optional
feature,
but
trying
to
figure
out
what
the
bounds
are
and
what
properties
we'd
actually
be
looking
for.
So
thanks
a
lot
for
that
all
right,
Karthik
you're
up
for
analysis!
Well,
you're,
not
the
bit
we're
going
to
beg
your
indulgence,
working
group
participants
because
we're
a
little
bit
over
time,
so
you're
losing
time
on
cookies.
I
All
right
so
I'll
keep
this
pretty
quick.
I
thought
it
was
important
to
give
a
get
the
working
group
a
little
bit
of
an
update
on,
what's
going
on
what
we're
doing,
and
also
for
me
to
be
able
to
collect
information
from
others
whose
work
I
may
not
be
aware
of.
So
it's
just
a
brief
update
on
what's
happening
in
the
security
analysis
wrong.
I
So
the
first
thing
to
realize
is
that
MLS
already
is
going
to
be
a
pretty
big
protocol
and
many
many
key
components
and
people
are
looking
usually
at
one
or
two
of
these
components,
but
not
everything
and
this
you
should
expect
so
then
the
papers
that
will
come
out
and
MLS
will
be
on
one
of
these
components,
assuming
a
lot
of
things
about
the
others
and
not
about
the
whole
thing,
at
least
for
a
while.
So
we
all
are
aware
of
the
key
exchange
bits.
This
is
the
most
studied
part.
I
There
was
the
ERT
proposal
in
draft
Syria,
which
has
a
nice
paper
edge
to
it.
There
was
a
freaking
proposal
draft
one
and
now
we
are
three
Kemp
plus
blank
nodes,
and
there
are
new
proposals
coming
through
as
well,
including
some
which
you
have
heard
of
today.
So
there's
a
lot
of
activity
in
this
zone.
There's
also
been
some
proposals
on
how
to
do
authentication.
I
What
the
credentials
should
look
like,
what
how
to
compose
signatures
and
max
to
do
the
right
thing,
and
this
had
some
analysis,
but
not
too
much,
because
this
is
still
kind
of
a
moving
area,
and
there
has
been
some
work
on
message:
protection
which
was
presented
last
idea,
if
you're
in
the
interim
and
so
on,
on
what
the
key
schedule
should
look
like
how
application
messages
and
handshake
messages
should
be
protected
and
so
on.
And
this
again
has
it's
very
recent
and
there's
a
lot
of
work
to
be
done
here
and
not
enough.
I
I
There's
a
bunch
of
people
who
have
been
doing
symbolic
analysis,
including
us,
and
profess
a
couple
of
Tamaran
models,
one
that
was
for
a
or
T
in
one,
for
that
richer
has
been
working
on
for
some
of
the
other
components
on
the
crypto
side
on
the
crypto
proofs,
I
know
at
least
that
Joelle
and
I
have
Kenny
and
so
on.
I'm
working
on
something
and
I
know
there
is
something
else
coming
out,
maybe
from
konradin
and
so
on.
I
I
I
showed
you
before
not
so
much
analysis
so
far,
but
in
a
way
one
of
the
issues
I
think
when
I
have
been
speaking
to
academics
and
trying
to
get
them
interested.
In
doing
this
analysis
is
that
the
process
seems
to
dynamic,
so
people
don't
know
where
to
analyze
and
what
to
analyze.
So,
in
particular,
we've
been
doing
lots
of
comments
on
github
and
then
some
of
them
making
two
drafts
just
before
ATF's.
But
we
don't
really
I
mean
a
lot
of
people.
Don't
have
a
I
mean
I
am
very
involved
here.
I
So
I
do
have
a
reasonable
idea
what's
going
on,
but
a
lot
of
people
don't
know
whether
it's
stable
enough
to
analyze
what
they
should
analyze.
What
will
suddenly
change
under
their
feet,
because
each
analysis
takes
a
significant
amount
of
time
and
effort,
so
I'm
going
to
make
two
process
proposals
and
we'll
take
I'll,
take
it
on
the
list.
I
Six,
seven
draft
sections,
so
I
would
like
to
have
that
sort
of
more
big
in
here,
so
that
when
we
are
publishing
a
new
draft,
we
also
publish,
along
with
it,
maybe
in
an
appendix
saying
which
sections
which
think
are
now
ready
for
analysis
so
that
I
can
mix,
can
publish
papers.
Saying
you
analyze,
MLS
draft
0
5,
which
the
author's
told
us
this.
These
five
sections
were
ready.
Finale'
says,
and
this
is
here's
a
contribution
to
the
process,
so
those
sections
should
be
designated
as
ready
for
analysis.
I
Other
sections
should
be
designated
as
don't
look
at
it,
don't
bother,
because
we
will
change
this
right
now.
So
it'll
be
a
waste
of
time
and
of
course
we
can
change
minor
details
like
wire
formats
and
whatnot.
But
what
you
should
promise
is
that,
at
least
for
a
few
drafts
to
come,
maybe
for
at
least
for
one
ITF
cycle,
if
not
for
two.
I
P
I
Second
thing
that
I
would
note
already,
which
is
true
for
TLS,
is
true
here
and
here's
even
more
so
because
a
completely
new
security
model
is
that
a
lot
of
the
work
we
are
doing
is
just
trying
to
get
the
definitions
in
place,
trying
to
understand
what
the
assumptions
are
on.
Who
is
compromised
who's?
Not
what?
What
do
we
care?
What
kind
of
privacy
guarantees
you
want?
Confidentiality
Gant
is
one,
and
it's
been
quite
painful
already
for
the
basic
protocol.
I
It
will
be
more
painful,
as
we
add
more
features,
so
for
now
we
are
taking
I.
Think
all
of
the
groups
are
working
on.
It
are
taking
what
the
architecture
state
says
go
through
the
protocol
as
a
starting
point,
and
we
will
try
to
formalize
them
as
well
as
we
can
be,
can
all
debate
what,
whether
we're
doing
it
right
or
not,
but
let's
assume
that
that's
done
so,
at
least
for
the
new
features
that
are
coming
and
anybody
proposing
a
new,
a
change
to
the
protocol,
a
new
proposal.
I
I
You
know
up
front
as
why
the
person
proposing
this
change
thinks
this
and
I
think
if
we
can
put
major
pull
requests
with
these
with
these
documents
in
them
just
text
right,
it's
just
informally,
but
we
don't
even
understand
them
right
now
why
certain
changes
happen,
I
mean
I
have
been
quite
involved,
so
I
might
be
able
to
help.
Some
people
understand
why
you
make
certain
changes,
but
a
lot
of
people
don't
understand
why
this
happened.
Why
that
happened?
I
think
it's
nice
to
be
explicit
about
these
things.
That's
all
I
have
here
yeah.
R
Mam
Thompson,
quick,
quick
question
for
the
working
group,
I
think
based
on
Karthik's
request
here,
which
I
think
at
some
point
it's
reasonable
to
have.
Does
the
working
group
think
that
the
protocol
is
sufficiently
stable
that
having
this
sort
of
process
is
appropriate?
One
of
the
things
we
found
in
quick
recently
was
that
we
had
to
make
the
decision
to
move
to
a
processes
much
more
like
this
one.
R
In
the
sense
you
have
to
demonstrate
that
you
have
much
stronger
evidence
for
changes
than
than
otherwise
much
much
greater
support,
and
that
does
or
can
slow
things
down,
and
so
the
question
is:
does
everyone
think
that
this
is
appropriate
is
that
is
the
protocol
commence
is
sufficiently
complete?
That
moving
to
something
a
little
more
rigorous
is,
is
appropriate.
This.
I
R
I,
don't
think
there's
other
things
really
the
the
problem
here.
Obviously
you
can
you
can
ratchet
this
up
even
higher
than
what
you're,
requesting
and
and
I
suspect
it'll.
In
a
lot
of
cases,
people
are
making
these
arguments
that
you're
talking
about
you're,
just
asking
them
to
be
made
a
little
clearer
and
more
formally
and
I.
Think
that's
that's
original
request,
but
you
you
have
to
understand
the
costs.
Okay,.
S
B
Just
a
quick
+1
here
we've
also
been
feeling
this
pain
in
terms
of
interrupts
testing,
like
the
evolution
that
causes
pain
there
as
well
yeah,
which
version
you
targeting
either
off
so
yeah,
and
definitely
I
keen
on
having
a
bit
more
stability.
I
think
that
the
upcoming
0-5
version
will
naturally
have
a
bunch
of
stuff
that
is
naturally
coming
to
a
stable
point
and
so
I
think
we
should
be
able
to
do
both
this
conversation,
about
which
things
are
ready
for
analysis
in
which
ready
for
neural
testing,
okay,.
S
So
the
last
point
on
the
agenda
was
talking
about
the
next
interim,
so
there
is
going
to
be
a
secure
messaging
workshop
and
yura
crypt
in
mid-may
and
we'll
be
putting
a
poll
on
the
list
with
respect
to
whether
or
not
we
want
to
have
something
before
or
after
likely,
in
Germany,
as
well
likely
at
the
at
the
wire
headquarters.
So
we'll
take
this
to
list
thanks.
Everyone
for
for
coming
to
MLS.