►
From YouTube: MLS WG Interim Meeting, 2021-05-26
Description
MLS WG Interim Meeting, 2021-05-26
A
This
is
the
itf
notewhale,
basically,
rules
and
procedures
and
stuff
for
participating
in
the
meeting
a
lot
of
it
has
to
do
with
ipr.
Please,
if
you
know
something
say
something:
basically,
some
third-party
artists
acquired
disclosures
haven't
made.
What
else?
Also,
please
be
professional,
all
that
good
stuff?
If
you
have
any
questions
you
can,
you
can
ask
the
chairs.
A
A
I
don't
agree
richard.
I
appreciate
that.
I
don't
know
that
we
actually
use
java
this
much
in
this
session,
but
if
there
is
somebody
that's
in
jabber,
if
somebody
does
say
something
and
would
like
to
get
it
spoken
at
the
microphone
or
into
the
audio
feel
free
to
do
that.
For
me,
and
I
really
appreciate
it,
we
got
a
couple
of
requests
for
things
to
work
on.
A
I
know
that
joel
had
a
thing
for
improving
entropy
that
we
want
to
do
at
the
beginning,
because
he's
got
a
drop
at
the
top
of
the
hour.
I
know
we
have
kind
of
outstanding
issues
that
I
think
we're
going
to
walk
through
the
github
repo
and
the
protocol,
as
well
as
the
architecture.
Draft
karthik
has
a
presentation
that
you'd
like
to
talk
about
some
informed
suggestions
and
comments
based
on
some
implementations
of
f,
sharp
and
then
mallory
asks
for
about
five
minutes
to
talk
about
the
end
definition.
A
A
A
Maybe
after
we
get
the
protocol
document
kind
of
nailed
down
a
little
bit
more,
the
timeline
is
still
the
same
as
last
time.
We're
still
kind
of
in
this
feature
freezing
analysis,
I'm
hoping
that
we
can
get
through
the
stuff
that
the
set
of
suggestions
and
changes
that
we've
got
now,
which
may
probably
result
I
think
in
another
working
class
call.
But
you
know
that's
that's
tbd,.
B
Sean,
if
I
could
comment
just
briefly
on
a
couple
of
milestones
or
not
milestones
in
progress,
we've
made
it
in
implementation.
The
mlspp
and
openmls
teams
have
been
doing
a
little
bit
of
interrupt.
Work
have
made
some
reasonable
progress
because
we
think
we
are
interoperating
on
pretty
much
all
of
the
test
factors
now
and
we
just
haven't
gotten
around
to
doing
the
actual
protocol
operations-
that's
kind
of
next
verizon,
so
we
are
getting
pretty
close
to
interoperability
on
draft
11
plus
a
couple
of
nits
we
found.
B
D
A
C
I
don't
really
either
and
I'd
also
like
to
preface
this
by
saying
it's
conrad
and
and
me
so,
okay,
in
fact
so
conrad,
please
feel
free
to
jump
in
at
any
time
and
say
things
help
or
if
you
feel
like
it,
you
can
just
lead.
Otherwise
I
would
just
sort
of
give
the
intuition
behind
what
this
pull
request
does
sort
of
some
pros
some
cons
around
doing
it.
This
way
kind
of
addressing
the
main
criticism.
C
G
C
Okay,
good
well
all
right,
so
so
here's
the
deal.
The
idea
is
that
we
want
to
introduce,
with
this
pull
request
a
couple
of
ways
of
hardening
the
protocol
against
situations
where
your
operating
system
or
your
operating
environment,
whatever
is
giving
you
bad
or
no
entropy
or
the
adversary,
is
learning
about
your
random.
Your
rng
state
and
you
know,
there's
different
ways
of
saying
the
same
thing
really.
C
C
So
that's
in
terms
of
compatibility
at
the
high
level.
How
does
this
work?
Well?
So
a
client,
that's
implementing
this
pr
will
have
what
would
be
called
an
entropy
pool.
It's
it's
really
just
a
big
stream.
Okay,
it's
like
whatever
256
bits
or
you
went.
I
don't
know
I
forgot
what
we
call
32
bytes
or
something
anyway.
That's
what
the
entropy
pool
is.
Okay
and
the
idea
is
there's
two
ways
this.
C
This
pool
gathers
entropy
for
the
client
and
there's
two
sources
of
entropy
that
you
mix
into
this
pool
and
then
every
time
the
protocol
needs
entropy,
because,
basically
because
you're
generating
keys
right,
that's
kind
of
the
main
times
when
you
there's
also
these
nonce
sort
of
this
non-thing
that
that's
the
other
time.
I
think
you
need
entropy
so
overall
the
way
that
the
whole
thing
works
is
the
client
will
periodically
mix
in
entropy
into
this
pool
and
it
sort
of
it
accumulates
inside
this
pool
and
whenever
the
protocol
says
oh
shoot.
C
I
need
entropy,
because
I
got
whatever
sample
a
key.
Then
it
extracts
entropy
from
the
pool
okay.
So
that's
sort
of
the
overall
way
that
this
works
in
terms
of
implementation.
It's
actually
real.
It's
really
quite
simple,
because
it's
just
calling
hkdf,
that's,
I
don't
think,
there's
anything
more
to
it.
You
just
call
hkdf
both
when
you're
in
entering
when
you're,
inserting
entropy
absorbing
it
into
your
pool
and
when
you're
extracting
entropy
from
your
pool
they're,
both
just
hkdf
calls
with
the
right
parameters.
C
Obviously,
okay,
so
there's
no
new,
crypto,
primitives
or
anything
being
being
introduced
here
you
can
now
in
you
can
get
entropy
from
two
sources.
I
think.
Did
we
settle
in
the
end
on
the
terminology
of
internal
external?
Well,
in
any
case,
you
can
get
entropy
either
from
the
outside
of
the
whole
mls
session
and
everything
which
essentially
means
it's
from
your
os
or
your
crypto
library
or
whatever
you
normally
get
your
entropy
from
so
that's
one
place.
C
The
client
can
import
entropy
into
the
entropy
pool,
but
the
other
place
that's
kind
of
more
interesting.
Maybe
these
to
me
personally
was
this
great
idea,
conrad,
which
is
that
you
can
also
extract
entropy
from
an
existing
session
right.
So
if,
if,
whenever
there's
a
commit
right,
we
get
a
new
application,
key
schedule
and
what
this
pr
introduces
is
an
extra
a
new
secret
that
we
derived
off
of
this
application
key
schedule,
which
you
can
then
feed
back
into
your
entropy
pool.
C
So
the
idea
is
this
is
a
mechanism
that
allows
one
client
who
currently
is
in
a
state
where
their
os
is
not
providing
them
any
entropy
to
refresh
their
entropy
pool
using
entropy.
That
is
essentially
coming
from
other
clients
in
a
session
via
the
session
to
this
to
this
client
right.
So
this
this-
and
this
is
kind
of
important,
because
it's
going
to
play
into
this
discussion
around
whether
we
should
be
really
doing
this
pr
in
this
way
or
not.
C
G
No,
I
think
I
think
you
covered
it
all
pretty
nicely.
Maybe
just
one
thing:
the
construction
is
essentially
the
same
as
the
key
schedule.
So
really,
if,
if
there's
a
bug
in
the
construction,
there's
a
bug
in
the
key
schedule-
and
it's
really
as
simple
as
it
can
be-
and
it's
also
conceivable
to
not
just
include
entropy
from
the
os
but
also
other
sources,
for
example,
I
think
for
tls.
G
That
was
the
proposal
made
that
you
could
get
entropy
from
by
like
signing
a
bit
string
using
an
hsm
and
then
putting
that
into
the
pool.
So
essentially
the
pool
is
pretty
open
as
to
where
the
randomness
can
come
from,
so
it
can
be
extended
in
that
way,
and
also
like.
It
should
be
noted
that
the
the
randomness
that
that
the
pool
gets
from
the
individual
sessions
is
kind
of
a
best
effort
approach,
because
essentially
what
it
does.
It
gets
a
value
from
the
key
schedule
and
injects
it
into
the
pool.
G
C
Getting
good
randomness,
that's
kind
of
pcs
analogy
here
and
the
forward
secrecy
analogy
is:
if
you
extract
a
bunch
of
random
randomness,
so
you're,
basically
generating
a
bunch
of
keys
like
new
signing
keys
and
new
seeds
for
doing
update
paths
and
all
that
stuff
and
then
after
you've
done
that
stuff,
the
adversary
learns
your
entropy
pool
all
that
stuff
you
extracted
is
still
secure.
So
that's
like
the
foreign
secrecy
analogy
here,
so
we
get
both
forward
secrecy
and
pcs
on
this
whole
entropy
thing
in
line
with
what
we
expect
from
all
our
privacy
guarantees.
C
C
C
C
I
I
feel,
like
the
complexity
argument,
is
relatively
for
me,
relatively
straightforward
sort
of
to
to
to
to
counter,
because
in
terms
of
actual
implementation
cost
as
combat
was
saying,
I
mean
this.
Is
it's
really
very,
very
simple?
It's
a
couple
of
extra
calls
to
hkdf
that
mirror
exactly
the
way
already
that
our
key
schedule
works.
C
C
My
point
of
view
is
the
complexity
of
the
implementation
shouldn't
be
so
much
of
a
hurdle.
The
more
basic
argument
against
is
this
idea
that
you
know
we
should
be
not.
We
should
just
let
the
os
deal
with
randomness
now,
maybe
there's
an
argument
to
be
made
there.
I
I'd
like
to
sort
of
have
my
counterpoints
to
that
argument.
I'd
like
to
state
those
here,
the
first
being
another
principle
of
good
design.
C
There
can
be
phases
where
the
os
doesn't
give
you
any
good,
entropy
or
very
low,
entropy
or
whatever,
and
with
the
pr
you
remain
in
secure
sessions
and
without
the
pr
you
could
end
up
in
an
insecure
session
right.
So
this
is
all
one
way
to
view
what
this
pr
is
doing
is
to
minimize
the
expectations
of
the
environment
that
the
mls
session
operates,
that
the
client
operates
in
better.
That's
one
thing:
the
other
argument
against
the
separation
between
the
other,
you
know
who
deals
with
entropy
should
be
only
the
os
or
not.
C
C
If
you
want
to
say,
hey,
I'm
going
to
outsource
all
of
this
to
the
os
or
or
my
crypto
live
or
whatever
I
don't
see
how
the
os
is
even
going
to
do
that,
and
if
it
is
it's
going
to
be,
you
know
it's
going
to
be
involved,
and
maybe
it
involves
like
polling
or
or
you
need
your
client
now
to
export
every
time
that
a
commit
happened
in
a
session
so
that
the
os
no
knows
okay.
That
means
I
need
to
pull
entropy
from
the
client
to
mix
into
the
rng.
C
I
don't
think
that
that's
really
something
people
are
going
to
do,
which
means
that
if
we
just
say
we're
going
to
push
this
to
the
os,
I
feel
like
we're.
Just
not
people
are
just
not
going
to
do
this,
we're
just
going
to
lose
that
security
advantage
which
the
pr
gives
us.
So,
even
if
we
subscribe
to
the
notion
that
it
should
be
the
os's
job
to
handle
entropy,
it's
still
not
clear
to
me
how
you
go
about
implementing
something
that
gives
us
the
equivalent
security
properties
that
this
does.
A
C
H
So
when
I,
if
I
were
to
do
this,
what
I
would
do
is
probably
separate
this
from
the
protocol
and
say:
oh
the
protocol.
By
the
way,
if
you
have
such
a
mechanism
available,
please
use
it
and
specify
that
in
something
like
a
cfrg
rfc,
because
this
is
the
you
know,
it's
like
it's
a
it's
a
it's
a
mechanism
that
can
be
useful.
Actually,
I
think
it's
very
clever
and
we
should
probably
have
that
somewhere,
but
you
know
it
doesn't
really
make
sense
for
it
to
be
in
mls
right.
H
H
Yeah,
so
I
mean
again:
that's
that
that's
pretty
I
mean
I
don't
see
too
much
problems
there
I
mean
if
you
have
such
a
mechanism,
you,
you
just
output,
some
at
some
specific
points
in
the
mls
protocol.
You
use
the
the
key
schedule
to
extract
some
entropy
and
give
it
to
that
that
function,
and
you
can
do
you
can
actually
do
it
at
any
time
right.
I
I
would
point
you
to
rfc
8937,
which
is
what
we
did
at
the
r
at
the
cfrg
about
this
it.
It
covers
the
randomness
improvements
extracting
from
either
symmetric,
shared
secret
or
a
asymmetric
share
secret.
I
don't
think
this
covers
everything
that
joel
presented
joel
presented
the
idea
of
having
kind
of
an
entry
pool
which
is
a
little
bit
beyond
this.
This
this
covers
just
the.
How
do
you
safely
take
an
existing
secret
and
generate
entropy
from
it?
A
B
I
I
have
a
bit
of
a
point
of
order
here
in
that
the
mls
protocol
draft
is
an
interop
specification
and,
as
I
think
joelle
mentioned
at
the
beginning
of
his
discussion,
this
is
something
that
doesn't
affect
it's
kind
of,
not
externally
observable.
It
doesn't
affect
interoperability,
it's
purely
about
what
an
implementation
does
internally
to
make.
You
know
greater
or
lesser
demands
on
its
platform's
randomness.
B
So
while
I
think
this,
so
I
think
where
that
points
is
just
that
this
doesn't
I
I
don't
see
this
being
a
required
component
of
the
protocol.
I
think
we
can
recommend
it
as
something
for
implementations
to
do,
but
I
don't
think
it
rises.
It's
clearly
not
an
interoperability
requirement,
and
so
I
would
hesitate
to
make
it
mandatory.
B
With
regard
to
the
cfrg
question,
this
seems
like
a
small
enough
thing
that
I
might
not
go
to
the
effort
of
spinning
up
a
new
draft,
so
I
think
my
preferred
outcome
here
would
be
to
capture
this
as
a
recommendation,
either
in
the
protocol
or
architecture
documents
as
an
optional
recommendation
and
just
capture
it
in
these.
These
draft
these
documents
here.
E
Yeah,
so
I
think
my
points
have
already
been
mostly
covered,
but
I
guess
the
my
feeling
when
we
formalize
the
spec
is
that
the
mls
spec
is
has
too
much
implementation
detail
already.
In
fact,
I
would
like
to
remove
some
implementation
specific
detail
from
it
and
make
it
more
kind
of
implementation
diagnostic
more
like
a
protocol
level.
Spec
would
be
ideal.
E
Actually
so-
and
this
is
like
richard
was
saying-
I
think
it's
a
very
useful
thing,
but
I
wonder
if
there
is
actually
room
for
a
third
rfc
in
the
in
the
in
this
working
group,
which
actually
is
a
list
of
implementation
recommendations,
because
I
think
we
have
a
bunch
of
them
that
are
now
starting
to
pollute
a
little
bit
the
the
rsc.
I
mean
one
of
the
concerns
for
examples
that
I
brought
up
a
little
while
ago
with
the
hpke
authors,
which
I
felt
had
an
impact
on
mls.
E
Is
that
the
way
we
are
doing
the
way
we
are
using
hpke
in
in
mls,
we
in
the
worst
case
might
be
generating
up
to
n
or
n
minus
one
keys
in
a
for
every
update,
assuming
a
completely
empty
tree.
For
doing
the
hpk
n
minus
one
ephemeral
keys
and
we
have
a
result
locally
here,
we
can
prove
that,
in
fact,
you
don't
need
to
do
that.
You
can
reuse
the
same
ephemeral
key
for
all
the
hpk's
that
you're
doing
in
a
single
update.
E
Now
this
breaks
in
some
sense
the
abstraction
of
hpk,
and
so
it's
kind
of
not
a
great
thing
to
do
at
this
stage,
because
hpk
is
already
pretty
much
standard.
However,
if
you
observe
it
a
bit
from
a
bit
further
away,
this
can
be
done
by
any
implementation.
As
long
as
you
have
a
nice
proof
that
this
is
actually
a
a
good
way
of
implementing
it
of
implementing
mhpk
multiple
recipe
and
hpke,
so
this
could
be
done
in
an
implementation
without
breaking
interoperability.
E
So,
in
a
way
I
did
not
even
propose
it
on
the
list,
because
I
felt
you
know
what
this
is
the
kind
of
thing
that
should
go
into
an
implementation
recommendation
section.
We
shouldn't,
pollute
the
spec
with
something
that
actually
doesn't
need
to
be
there,
but
it
would
be
nice
for
an
implementation
to
do
it
for
efficiency
purposes
or
in
some
cases
like
in
this,
in
this
particular
pr
for
security
purposes.
E
A
A
E
And
the
last
kind
of
point
in
some
sense
here
is
that,
yes,
there
is
this
rfc
at
the
cfrg,
which
seems
to
cover
some
things.
It
doesn't
seem
to
allow
us
to
add
external
entropy
in
as
an
entropy
pool.
It
seems
unfortunate,
I
mean
it's
sort
of
if
it
had
been
anticipated
and
so
on,
but
I
can
totally
imagine
in
a
system
that
we
should
recommend
that
people
that
okay
mls
is
an
entropy
source.
It
can
actually
produce
entropy
every
epoch
and
we
should
use
it
and
put
it
into
a
pool.
E
But
maybe
there
are
tls
connections
happening.
Tls-13
connections
happening
in
the
same
machine,
and
maybe
the
tls
exporters
could
be
a
good
entropy
source
too.
Why
should
we
restrict
ourselves
to
mls?
You
know
in
a
in
a
way
this
is
a
very
powerful
and
useful
construction
which
I
think
should
mix
an
entropy
from
multiple
sources
and
we
should
allow
it
to
mix
multiple
sources
to
get
the
best
possible
entropy
in
this
particular
system.
D
Yeah,
my
plans
have
been
covered
as
well.
I
just
wanted
to
add
one
more
small
thing:
roy
you
said
that
this
would
potentially
allow
us
to
have
a
different
definition
of
what
kind
of
quality
of
entropy
we
need
for
mls,
and
I
don't
think
that
that's
entirely
true,
because
in
practice,
when
you
bootstrap
a
client,
what
really
happens
is
that
that
client
needs
to
generate
signature,
keys
first
and
then
probably
a
bunch
of
key
packages,
and
at
that
point
you
don't
have
any
mls
session.
So
you
start
with
whatever
entropy
the
system
gives
you.
D
Of
course
you
can
improve
it
over
time,
especially
for
key
packages.
You
can,
as
you
do
updates,
then
you
can
profit
from
this
entropy
pool
for
signing
keys.
That
really
depends
on
whether
the
application
rotates
signing
keys
or
not,
but
for
the
initial
phase
it
doesn't
really
lower
the
requirements
you
have
with
respect
to
the
quality
of
what
your
operating
system
gives.
You.
C
Yeah,
I
I
also
think
for
the
initial
phase.
It
doesn't
it's.
It
helps
in
scenarios
where
you
have
entropy
and
then
you
lose
entropy.
I
think
that's
more
like
the
scenario
where
you
can
still
expect
security,
despite
having
lost
entropy
and
generating
keys
in
this
period,
when
you
don't
have
entropy.
C
To
be
fair,
it's
a
subtle
difference
between
what
the
good
that
you
need
without
the
pr
and
the
good
that
you
need
with
pr.
I
completely
agree:
it's
not
a
straightforward
thing
where
you
can
just
say:
oh,
I
don't
need
entropy
from
the
environment.
That's
not
true.
There
are
times
where
you
still
need,
in
particular
the
one
you
pointed
out
when
you
initialize.
C
If
you
can
never
generate
a
secret
from
the
get-go,
then
you
can't
get
secrecy
in
your
session,
which
means
also
the
entropy
you
import
from
your
sessions
will
not
be
random
for
the
adversary
and
so
you're,
not
actually
importing
entropy.
So
you
at
some
point
need
to
be
able
to
establish
confidentiality,
but
after
you've
established
confidentiality,
you
could
lose
entropy
in
your
environment
and
you
can
still
be.
C
D
A
Okay,
so
we
seem
to
have
drained
the
cue,
so
it
sounds
to
me
like
everybody's,
on
board
that
thinks
that
this
is
important.
The
question
is
where
to
put
it-
and
I
personally
prefer
that
we
actually
keep
the
dot,
keep
this
information
somewhere
in
this
document
until
we
figure
out
another
landing
place
for
it
as
opposed
to
just
kicking
it
out
completely.
B
I
I
would
be
okay
with
that.
If
we
were
not
trying
to
finalize
this
the
protocol
drafts,
so
I
mean
it's
easy
enough
to
spin
up
a
new
draft.
I
would
say:
let's
just
start
up
a
new
draft
put
it
in
there,
and
then
I
mean,
or
even
just
like
the
pr
will
continue
to
exist,
even
if
it's
closed,
and
so
the
text
won't
be
there.
So
I'm
not
worried
about
losing
track
of
this
of
this
proposal.
C
A
Yes,
so
I
was,
I
was
thinking
at
one
point
that
the
architecture
document
would
actually
have
some
of
these
kind
of
implementation
hands.
But
if
we're
not
going
to
put
those
in
there
we're
going
to
put
more
specific
details
in
another
document,
we
can
just
start
another
document
start
it
just
starts
out
as
an
individual
draft,
and
then
we
have
to
do
like
the
process
of
adopting
it.
H
I
I
think
sean
is
suggesting
something
more
general
in
particular
not
specific
to
this.
This
randomness
improvement
strap,
but
just
in
a
protocol
implementation
considerations,
draft
for
mls
in
total,
and
then
some
of
the
protocol
draft
could
be
completely
extracted
as
it
as
karthik
pointed
out
yeah.
But
you.
H
Know
I'm
exactly
saying
that
I
mean
it
doesn't
prevent
the
other
rights
we.
We
can
still
do
that
for
things
like
kartik
mansion.
We
can
have
this
implementation
thing,
but
again
I
don't
care
in
the
end,
if
it's
not
used,
if
people
have
to
point
to
the
ml
to
an
mls
object,
that's
fine,
but
to
me
it
makes
more
sense
to
have
it
at
cfrg.
H
H
H
E
Yeah
and
just
to
clarify
the
proposal
that
I
was
making
earlier
was
that
I
have
a
feeling
that
the
various
implementers
of
mls
together
have
already
got
several
things
that
they
would
like
to
document
on
the
right
way
of
doing
various
things,
and
we
don't
want
to
pollute
the
protocol
document.
So
I
suspect
that
we
there
is
going
to
be
quite
enough
for
an
implementation
draft,
including
some
of
the
pr's
we'll
discuss
later.
I
think.
B
If,
if
we
wanted
to
have
a
smaller
pr
on
the
protocol
document,
just
expressing
the
requirements
around
entropy
and
saying
you
know
this,
this
protocol
does
a
lot
of
it
requires
a
lot
of
entropy
at
various
points
and
produce
can
produce
entropy
that
could
be
fed
back
into
something
like
a
pool.
I
think
that
that
would
be
a
fine
thing
to
have
in
security
considerations.
G
G
A
E
Yeah,
I
can
see
them.
I
think
people
should
be
able
to
see
them
too
all
right.
So
this
is
work
that
you've
been
doing
at
indriya,
and
I
wanted
to
give
you
a
little
bit
of
an
update
on
where
we
are.
We
are
going
and
stuff
like
that.
It's
a
bit
rambly!
So
I'm
going
to
hard
stop
myself
it's
at
the
hour,
let's
say,
and
if
we
still
have
more
time
we
can
go,
go
over
it
at
the
end.
E
This
is
just
some
observations
that
we
came
up
with
and
raised
some
questions,
so
we
want
to
kind
of
bring
it
up
with
the
group.
So
sean
next
slide,
please
all
right.
So
what
have
you
been
doing?
You've
been
very
quiet
for
a
while.
So
let's
remind
people
that
what
in
our
group,
what
we've
been
trying
to
kind
of
answer
is,
can
we
give
a
security
proof
or
a
comprehensive
model
of
mls
as
in
something
that
is
a
proof
that
it
works
for
all
the
details
of
the
corner?
E
Cases
of
mls,
including
you
know,
at
the
byte
level,
so
our
approach
has
been.
We've
we've
been
trying
to
build
and
we
have
now
built
an
executable,
interoperable
model
of
mls
and
star
so
to
add
to
richard's
notes
about
interop.
We
now
have
a
third
interrupting
implementation,
which
also
interrupts
with
openmls
and
passes
the
test
vectors.
E
So
that's
cool
and
the
idea
was
that
we're
going
to
define
all
the
security
goals
using
typed
in
variants
and
fstar
prove
not
just
security,
but
also
functional
correctness,
so
make
sure
that
the
parsing
and
everything
is
unambiguous
and
the
the
state
machines
can
be
implemented
correctly
and
so
on,
and
so
you
have
a
finally
a
security
proof
at
a
byte
level.
Precision
of
what
the
spec
actually
says
and
of
course
that's.
The
last
step
which
you
are
always
interested
in
is
where
can
we
link
this
verified
spec,
which
is
executable?
E
So
it's
really
like
a
reference
implementation
to
an
optimized
implementation
and
see,
and
that's
the
kind
of
thing
that
we
it
was,
was
our
approach.
Okay,
so
next
slide
sean
and
what
we
did
was
well.
We
went
quite
far
so
we
wrote
a
research
report.
It's
on
that
url
up
there
and
benjamin
finished
his
phd
thesis.
E
So
this
was
okay,
but
you're
not
entirely
satisfied
with
this,
because
in
order
to
actually
formalize
the
notion
of
our
secrecy
and
post-compromised
secrecy,
in
fact,
the
existing
models
in
extra
were
not
adequate
because
they
didn't
actually
allow
us
to
speak
very
precisely
about
the
trace
and
the
sequence
of
events
that
were
happening.
So
we
ended
up
inspired
by
this
development,
actually
doing
a
completely
new
symbolic
verification
framework
in
a
star
that
can
actually
cleanly
handle
things
like
forward
secrecy
and
pcs
and
so
on,
and
that
became
its
own
beast.
E
So
what
we
ended
up
doing
was
building
a
full
verification
framework
called
dystar
for
doing
symbolic
proofs
in
f-star.
This
is
published
at
euro
smp
this
year
and
the
link
is
over
there.
You
can
go
stare
at
it
and
what
this
is
is
a
new
framework
for
symbolically
verifying
cryptographic
protocols
and
their
implementations
in
a
star.
E
Its
design
was
heavily
influenced
by
mls,
but
it's
more
applicable,
more
generally,
of
course,
and
it
has
its
novel
trace-based
semantics
which
is
built
in
so
it's
a
completely
new
way
of
proving
things
in
a
star,
and
the
nice
thing
is
of
course,
since
we're
doing
type
checking
the
proofs
are
all
modular.
So,
however,
large
the
code
gets,
the
proofs
tend
to
be
quite
very,
very
much
scalable
and
they're.
All
machine
checked
right
and
the
soundness
of
this
verification
method
itself
was
proved
in
a
star.
E
So
this
is
what
we've
been
doing
for
the
last
few
months,
so
teophil
wallace,
who
will
speak
in
a
little
while
there
was
a
new
phd
student
who
joined
the
group
and
took
the
patent
from
from
beijing
and
he.
So
what
he's
been
doing
is
all
three
of
us
have
been
doing
is
to
build
an
interoperable
model
of
draft
eleven
and
f
stars.
It's
it's
more
or
less
complete.
E
Let's
say
it
misses
some
features,
but
it
passes
all
the
test,
vectors
from
open
mls
and
it's
it's
modular
in
the
sense
that
it's
broken
down
into
several
sub
protocols,
and
this
is
something
you'll
want
to
speak
about
in
a
minute
and
all
the
underlying
cryptography
uses
specs
from
hecklestar
and
eventually
we'll
use
actual
verified
code
from
star.
So
it's
all
built
on
on
sound
foundations
and
just
to
give
you
an
idea
right
now.
This
spec
is
about
2000
lines
of
restaurant.
E
We
think
we
might
be
able
to
keep
it
at
that
size,
even
as
we
go
forward
and
finish
all
the
corners.
Okay
it'll
be
about
two
thousand
lines
if
you've
started
it.
Of
course,
this
is
just
a
spec,
but
it's
executable.
It's
testable,
but
it's
a
spec,
so
the
next
step
is
obviously
to
encode
the
security
goals
and
prove
them.
E
So
we
hope
to
take
all
the
work
that
we
did
before
on
art
and
mlhd
game
and
so
on
and
adapt
it
for
this
new
model
and
do
this
proof,
so
that's
going
to
be
our
task
for
the
next
few
months
and
we
hope
to
have
something
concrete
released
and
both
the
implementation
and
the
proof
in
in
a
few
months.
Okay,
so
that's
that's
where
we
are
right
now,
so
for
the
the
purpose
of
this
talk
is
I'll.
E
Tell
you
where
we
are
and
to
also
give
some
feedback
based
on
what
we
found
during
this
formalization
step.
So
there's
four
things
we'd
like
to
mention
and
time
willing,
whatever
we
can
either
mention
them
today
or
we
can
discuss
them
some
of
the
time
and
I'm
going
to
start
by
this
idea
of
decomposing
mls
into
sub
protocols,
which
is
what
we
did
in
our
spec.
E
E
So
when
you
try
to
write
down
the
formal
spec
of
mls,
we
we're
kind
of
getting
scared.
Now
because
it's
getting
to
be
a
pretty
large
protocol,
I
think
it's
not
so
easy
to
say
I'm
going
to
take
a
fragment
of
this
protocol
and
prove
it
anymore,
because
the
dependencies
are
all
over
the
place
and
in
a
way
it
doesn't
have
to
be
that
way.
E
Okay,
so,
but
the
way
it
has
evolved
is
that
we
have
added
things
and
features,
and
so
now
there
is
a
little
bit
of
a
monolithic
thing
going
on
in
the
current
spec,
which
I'm
hoping
the
next
rewrite.
We
can,
at
least
without
changing
anything
technical.
We
can
at
least
like
separate
out
the
components
a
little
bit
better
without
affecting
the
the
technical
details
of
the
protocol.
So
the
way
mls
has
evolved
is
that
well
it's
doing
dynamic
group
membership,
but
it's
also
doing
group
key
distribution.
E
It's
doing
application
data
encryption
and
then
there
are
exceptional
features
for
preventing
insider
attacks
and
some
optimizations
like
converge
leaves-
and
all
of
these
are
like
mixed
together
in
the
ratchet
tree,
and
this
makes
it
pretty
hard
to
specify
and
to
prove
so.
Here's
next
slides
shown
so
here's
a
decomposition
that
we
are
using
in
our
spec
and
we
wonder
if
this
is
not
more
useful
generally,
so
I
think
mls
naturally
breaks
down
into
three
sub
protocols
which
I'm
calling
tree
sync
tree.
Chem
and
freedom.
E
H
E
Spec
actually
talks
about
tree
synchronization
separately,
but
if
you
think
about
it,
the
street
synchronization
protocol
does
not
need
to
care
at
all
about
what
is
the
content
that
is
stored
in
each
node
in
each
leaf.
The
fact
that
they
are
public
keys
or
cipher
tags,
or
whatever
is
actually
not
important.
All
we
are
trying
to
do
is
replicate
this
data
structure
across
all
group
members
and
keep
them
synchronized.
E
Okay,
and
so
this
is
the
protocol
that
ensures
fs
and
pcs
for
the
node
secrets,
epoch,
secretary
secrets
and
so
on,
and
this
needs
to
use
hpk
and
kdf,
but
this
doesn't
really
need
to
use
any
signatures
or
ead
or
any
of
that
stuff
right
and
the
third
part
which
we
call
message
framing,
I
guess
in
the
in
the
spec
or
application
data
protection
is
street
m
is
what
you're
calling
treatment.
It's
nothing
surprising.
E
Once
you
have
the
epoch
secret,
then
you
can
derive
keys
for
encrypting
each
message,
and
so
this
is
taking
care
of
the
application
data
encryption
protocol.
So
all
three
of
these
are
tree
based
protocols.
They
all
share
the
commentary
data
structure,
but
they
are
really
trying
to
do
very
different
things
and
it's
by
collapsing
them
all
into
one
ratchet
tree
or
in
one
conceptual
space.
I
think
we
are
kind
of
confusing
things
and
making
proofs
and
harder
and
the
properties
harder
to
understand
so
so
this
is
how
we
have
structured
our
our
spec.
E
We
are
separating
out
these
three
components
and
there
are
benefits
to
this.
So
suppose
you
take
the
tree
cam
protocol
or
whatever
the
mls
protocol,
and
you
separate
out
this
tree
sync
component.
What
are
the
benefits?
Well,
treesync.
Doesn't
care
about
encryption
at
all?
Doesn't
care
about
anything.
Nothing
is
secret.
Interesting
everything
is
public
data
structure,
okay.
Well,
we
could
and
we
could
think
of
it
as
not
being
public
in
the
sense
of
privacy,
but
really
for
for
the
security
guarantees
of
mls.
It's
all
public
data
structures.
There's
no
key
derivation,
there's
no
secrecy.
E
There's
no
encryption!
You
can
express
the
create,
add,
remove
operations
directly
in
freesync
for
update.
You
can
still
express
update,
but
the
contents
of
the
update
are
opaque,
byte
strings
they're,
not
they're,
not
cipher
text
they're,
not
public
keys,
is
opaque
by
string
from
the
viewpoint
of
tracing
you're.
Just
updating
a
path
in
the
tree
you
can
even
express
the
notion
of
unmerged
leaves
parent
hashes.
All
of
this
doesn't
require
any
consideration
of
of
key
derivation,
okay
of
how
the
keys
work.
E
Instead,
what
you
do
is
you
focus
on
this
in
protecting
the
integrity
and
authenticity
of
this
tree
data
structure
against
both
outsiders
and
insiders.
You
can
actually
state
what
the
double
join
attack
means
directly
on
the
treesync
protocol,
without
even
thinking
about
hpke
encryption
secretary
secretary,
you
don't
even
have
to
think
about
it.
E
The
double
joint
protocol
can
directly
be
expressed
on
the
treesync
protocol
and,
if
you
think
very
at
a
high
level,
what
is
nice
is
that
in
the
mls
spec,
we
already
have
a
good
understanding
of
what
treecam
is
supposed
to
achieve,
which
is
a
secrecy
invariant
that
we
state
in
the
spec.
But
in
fact,
treesync
has
an
equally
nice
property,
which
is
an
authentication
invariant
that
it
enforces.
E
So
what
is
the
authentication
in
variant
of
presync,
which
is
it
is
that
the
content
that
you
have
at
any
non-blank
node
m
must
have
been
written
by
one
of
the
members
under
this
node.
So
it's
a
right
policy
that
we
have
here,
not
a
read
policy.
So
we
say
that
this
content,
we
don't
care
what
the
content
is
it's
opaque,
but
this
content
should
have
been
authored
in
some
update
by
one
of
the
leaves
underneath
this
node
okay
and
so,
which
means
that
basically,
every
update
is
signed.
E
E
Conversely,
there
is
also
benefits
to
trees
tree
cam.
Once
you
remove
the
tree
sink
part
of
it,
it
actually
becomes
very
simple.
Okay,
all
your
all
tree,
cam
is
doing,
is
sort
of
like
the
original
art
paper
already
had
this
idea,
but
the
original
art
paper
was
only
doing
key
distribution,
didn't
worry
about
signatures
and
so
on,
and
this
this
is
what
you
get
out
of
tree
cam.
E
You
basically
get
to
do
just
updates
and
treat
a
key
key
derivation
for
each
node
and
and
that's
it
and
you
of
course
manage
the
transcripts
and
so
on.
Maybe,
but
but
you
can
actually
remove
a
lot
of
the
tree
management
stuff
out.
Okay,
we
don't
care
about
signatures.
Authentication,
parent
hash
is
not
part
of
trick,
and
you
don't
have
to
worry
about
any
of
that.
Instead,
you
just
focus
on
key
derivation
and
you
think
about
it.
E
You
what
cam
is
doing
is
enforcing
the
read
access
control
policy,
which
is
already
documented
in
the
mls
spec,
which
is
a
tree
secrecy
invariant
that
the
node
secret
in
any
non-blank
node
can
only
be
read
by
one
of
the
members
underneath
it
okay.
So
so
that's
sort
of
it's
there's
benefits
to
both
sides
by
kind
of
factoring
these
out,
at
least
in
the
specification
next
slide.
E
All
right,
so
what
did
we
do?
We
kind
of
divided
up
the
protocol
into
these
three
parts
and
you
find
that
they
get
kind
of
quite
equally
separate
out.
So
three
sync
and
f-star
is
about
400
lines.
Streak
is
about
350
lines.
Three,
damn
will
be
about
200
to
250
lines.
We
haven't
completed
the
freedom
part,
but
we
did
most
of
it
and
we
expect
that
these
can
also
be
because
we
have
separated
out
the
crypto
components.
E
E
My
question,
I
guess
for
this
part
of
the
of
the
of
the
development-
is
that
we
can
either
take
this
what
I've
said
so
far
in
two
ways:
one.
Maybe
this
is
a
good
way
for
implementations
to
structure
themselves
and
something
like
a
recommendation
of
decomposing.
The
protocol
into
these
sub
protocols
should
be
part
of
something
like
an
implementation
document.
E
Alternatively,
maybe
this
also
points
away
as
to
maybe
we
should
rewrite
a
little
bit
or
restructure
or
the
the
mls
protocol
rfc
in
a
way
that
makes
this
separation
a
little
bit
more
explicit
would
be.
May
perhaps
a
nice
thing
to
do,
and
I
don't
know
I
don't
know
what?
What
without
change,
because
none
of
what
I
have
said
right
now
is
actually
changing
the
spec.
It's
mostly
about
how
to
separate
out
the
different
components
of
it.
E
There
is,
of
course,
an
issue
which
is
that
not
the
separation
is
always
not
not
always
super
clean.
I
pretended
that
it
was,
but
in
fact
there's
at
least
one
or
two
places
where
separating
our
tracing
and
tree
cam
was
a
bit
of
a
pain,
and
one
of
them
is
the
parent
hash
construction,
because
the
parent
hash
construction
currently
depends
on
the
tree
resolution
of
the
sibling.
So
it
actually
tree
resolution
for
us
belongs
in
tree.
Cam
and
parent
hash
belongs
in
tree
sync,
so
this
separation
was
a
cause.
E
Some
is
causing
some
ugliness
in
our
specs,
but
if
we
accept
that
this
is
actually
a
worthwhile
separation
to
have,
then
it's
not
so
hard
to
to
remove
this
kind
of
a
dependency
for
very
specific
components
for
parent
hash.
Instead
of
using
the
tree
resolution
of
the
sibling,
I
think
we
could
use
a
tree
hash
on
the
sibling,
for
example,
and
that
would
kind
of
break
this
dependency,
but
that's
only
worth
it
if
we
decide
that
even
in
the
protocol,
maintaining
the
separation
is
a
worthwhile
idea.
E
C
Has
his
hand
up
first,
I
I
just
have
a
it's
a
really
short
question.
There
was
a
couple
slides
back.
We
were
talking
about
treesync
you
you
had
this
comment
that
double
joins
can
be
demonstrated
on
treesync
legendary
yeah.
What
does
that
mean?
Because
to
me
double
join
is
also
it's
mainly
a
privacy
thing
and
I'm
understanding
is
true.
Sync
doesn't
deal
with
privacy.
E
How
do
I
interpret
that
sentence
exactly
so?
I
think
you
interpret
it
as
double
join.
What
it's
doing
is
actually
violating
the
tree.
Authentication,
invariant,
okay,
and,
as
a
corollary
of
that,
then
it
violates
the
privacy
of
of
of
the
of
the
of
the
keys
at
that
node.
But
that's
that's
a
separate
point.
E
C
Yeah,
the
other
comment
I
had
is
well.
We
I'm
super
love
to
see
this
in
in
more
detail
the
street
this
this,
how
you,
how
you
guys,
define
these
three
modules-
we've
been
matt
and
I've
been
working
on
on
some
modularization
ourselves,
and
I'm
hopeful
that,
at
the
very
high
level
that
I've
understood
from
the
slides,
I
think
it
should
work
in
the
proofs
too.
We're
we're
because
we're
also
ending
up
in
not
completely
different
way
of
modularizing
things
and
we're
actually
doing
it
for
the
purpose
of
proofs.
E
Joel
so
we
have
been
highly
inspired
by
the
series
of
papers,
you've
written
as
well,
and
we've
been
looking
at
the
proofs,
for
example,
for
the
insider
tax
paper
and
saying
well,
could
you
have
done
this
kind
of
proof
without
worrying
about
you
know
some
aspect
of
the
protocol?
Could
you
remove
suspicious
particular
protocol
and
still
do
the
proof
and
that's
the
kind
of
thing
I
mean
looking
at
your
work
is
what
is
also
inspiring
that
maybe
some
modularization
would
help
in
in
doing
the
full
big
beast
in
the
end.
You
know.
A
B
C
H
E
So
at
this
stage,
I
guess
the
the
best
one
could
hope
for
is
to
have
the
conceptual
components
described
in
the
introductory
text
and
maybe
use
some
kind
of
terminology
to
cleanly
separate
out
the
the
section
headings.
Basically,
that's
basically
at
most,
I
think
you
can
do
and
if
there
are
some
subsections,
that
should
become
full
sections
or
whatever
this
kind
of
change
is
not
really
a
full
rewrite
is
inconceivable.
I
think.
B
E
Because
if
you
think
about
it,
we
already
do
this
with
the
ratchet
tree
description,
where
we
don't
really
see
exactly
how
it
is
to
be
how
it
is
specified.
We
actually
say
this
is
the
conceptual
ratchet
tree.
What
I'm
showing
here
is
actually
saying
that
the
ratchet
tree
is
actually
three
trees
and
they
are
for
different
purposes,
and
you
know
what
we
are
explaining
in
the
in
the
spec.
E
H
H
D
Yeah,
I
mean
from
a
practical
point
of
view,
we
still
have
a
bunch
of
open
questions
on
the
current
specs,
so
I
mean
it's
great
if
you
want
to
start
a
rewrite,
but
we
will
be
struggling
with
addressing
the
open
questions,
because
I
think
we
will
not
address
all
of
them
today.
So
keep
that
in
mind
at
some
point
you
know
if
your
rewrite
is
successful
in
the
sense
that
we
all
agree
that
we
shouldn't
switch
to
that.
H
E
Okay,
so
sean,
I
promise
to
stop
at
the
top
of
the
hour
and
I
think,
there's
a
bunch
of
pr
issues
to
go
through.
Yes,
so
maybe
we
split
now
we
can
we
go
on
to
the
other
two
topics
and
if
there
is
some
time
left
at
the
end,
theofield
could
address
could
discuss
some
of
the
other
suggestions.
That
came
out
of
our
analysis.
I.
A
H
H
So
there
are
only
a
few
remaining
topics
that
we
want
to
to
to
handle
for
that.
For
that
document
plus
the
few
there
are
very
few
open
issues
in
the
documents,
but
there
is,
there
is
still
a
lot
of
contributions
that
that
people
want
to
make.
So
the
main,
I
think
thing
that
we
have
to
improve
on
the
document
is
the
expected
type
of
deployments.
H
H
Making
the
language
agnostic
for
the
deployment
is
quite
difficult,
so
conrad
britain
has
actually
made
some
suggestions
on
and
contributions
on,
prs
where
they
suggested.
Some
changes
to
make
sure
that
we
say,
for
instance,
that
the
authentication
service
provides
certain
properties
such
as
credential
authentication,
message,
authentication
and
actually
like
give
a
bit
more
detail
and
the
the
the
rest
of
the
draft
is
like.
There
is
a
huge
fraction
that
has
not
been
there
before
about
security
considerations,
where
the
idea
is
to
go
from
the
smallest
compromise
to
the
biggest
compromise.
H
So
in
some
sense
like
what
happens,
if
you
compromise
an
hpk,
what
are
the
guarantees
that
the
protocol
should
aim
at?
If
you
break
you
know
the
secrecy
of
the
signature,
private
key
when
you
get
et
cetera
and
I
grow
and
grow
and
grow
with
stronger,
stronger
attackers
up
to
the
point
where
you
get
a
full
full
state
compromise
for
for
for
one
of
your
clients
and
what
are
the
consequences?
And
things
like
this?
H
H
H
H
What
we
really
want
is
to
have
contributions,
issues
opened
on
what
you
think
is
missing
from
the
document,
so
we
under
like
most
of
them,
have
been
already
handled.
Many
of
them
have
been
handled,
but
you
know
we
have
a
lot
more
things
to
actually
say
in
that
document
that
we
can
like.
We
have
infinite
topics
in
some
sense,
so
if
you
think
that
there
is
something
missing
or
that
there
is
something
incorrect,
that's
the
value
for
the
architecture
document
right
now.
H
H
H
A
H
No
not
specifically,
and
most
of
the
issues
are
usually
editorial,
so
so
there
is
one
which
might
be
interesting
that
we
never
discussed.
Actually
we
discussed
it
at
the
very
beginning
of
the
of
the
working
group
is
whether
we
should
actually
provide
recommendations
for
key
updates
in
terms
of
amount
of
time,
I'm
pretty
much
against
it,
because
it's
very
difficult,
depending
on
the
use
case
and
the
infrastructure
and
the
device
on
which
you
run
the
protocol
to
to
ask
or
to
require
any
kind
of
specific
time
frame
for
commit
for
making
commits.
H
H
A
C
C
D
H
G
H
All
right
go
on
one:
okay
going
twice
sold,
so
I
guess
you
can
close
it,
but
yeah
really.
What
we
need
now
is
more
readers,
more
readers
and
opening
issues
to
make
sure
that,
basically,
the
concern
that
we
have
is
to
make
sure
that
when
we
go
to
last
call
or
something
like
this,
we
don't
miss
too
much
things
that
we
want
to
discuss
things
that
we
that
we
think
might
be
important
to
discuss.
H
A
K
A
K
K
Great
yeah,
thanks
for
your
time
today,
there's
a
draft
in
the
data
tracker.
It's
right
now
on
its
own,
no
working
group,
but
I
did
send
it
to
you
all
on
the
list.
Maybe
a
couple
weeks
ago.
The
title
is
definition
of
end
encryption.
Some
of
you
have
seen
this
and
initially
before
it
was
in
the
data
tracker
I
asked
around
about.
K
You
know
where's
the
best
place
in
the
iecf
for
this,
and
I
think
the
reason
why
I
sent
the
one
and
so
the
oh,
the
the
original
version
was
just
that
it
appears
there.
May
it
may
actually
be
applicable
because
we're
not
just
talking
about
messaging
apps,
there's
lots
of
applications
for
what
protocol
you
are
all
designing,
so
I
think
it
actually
fits.
So
let
me
get
into
it.
I'm
co-authoring,
with
fred
baker,
olaf,
kolkman
sophia
who's,
a
contributor
to
this
working
group
and
gershabad
grover.
H
K
Really
good
drafts
out
there
that
use
end
encryption
and
therefore
have
done
an
elegant
job
of
describing
what
is
it
in
their
context?
But
there's
nothing.
That's
really.
Overall,
I
feel
like
there's,
that's
like
a
nice
big
gap
in
the
ietf,
so
the
outcomes
we're
hoping
for
with
this
draft
we're
seeing
definition
creep
in
mostly
like
public
relations
and
like
political
debates,
things
being
called
into
end
encryption
that
are
not
just
straight
up.
It's
not
great.
K
So
we
also
want
this
to
be
a
helpful
place
to
put
things
that
maybe
don't
as
easily
fit
in
the
architecture
of
the
protocol
draft
as
a
way
of
sort
of
offloading
sort
of
long-winded,
conceptual
definitions
of
things,
and
then
the
last
thing
we
want
is
that
we
want
to
drive
the
definition
with
principles
and
norms,
but
then
also
that
should
influence
the
way
implementations
work
so
that
you
have
different
ways
of
articulating
the
things.
These
are
things
we
don't
want
to
do.
K
Another
reason
why
we
hesitated
to
get
this
draft
into
mls.
We
don't
want
to
define
it
by
what
it
isn't
like
saying,
for
example,
like
an
an
encrypted
app
that
traces
all
of
its
messages
is
not
end
to
end
encrypted.
We
we
wanted
to
avoid
all
the
things
that
we
feel
like
are
sort
of
deviations
from
solid
e2e.
K
The
second
thing
we
wanted
to
avoid
is
by
directly
invoking
threat
models.
We
did
that
on
purpose,
although
I
think
we,
in
speaking
with
others
like
stephen
farrell
and
so
on,
like
it's
going
to
be
useful
to
use
threat,
modeling
to
potentially
figure
out
holes
and
gaps
in
the
way
that
we
define
it,
but
we
don't
want
to
rely
again.
It's
like
we
don't
want
it
to
be
an
anti-definition
and
then
the
last
thing
is.
K
If
there's
a
whole
lot
of
dissent
or
disagreement
about
fundamental
requirements,
then
that
could
actually
be
harmful
to
a
crisp
and
clear
definition
of
what
is
e2e
and
what
is
not
right.
So
the
draft
itself.
It's
really
breaking
into
three
pieces
because
we
felt
like
one
approach
to
defining.
It
wasn't
quite
good
enough,
so
the
three
different
approaches
to
defining
it
are
meant
to
complement
one
another.
So
the
first
is
just
like
a
straight
up.
Formal
definition
like
can
we
just
define
the
building
blocks
the
relevant
pieces
of
it?
K
The
second
is
definition
by
features
so
trying
to
functionally
define
it
and
then
the
last
one
we
felt
was
important
to
include
around
you
know
when
a
user
is
told
that
a
system
is
end
and
encrypted,
what
do
they
expect
so,
hopefully,
those
three
perspectives,
kind
of
give
one.
You
know
a
full
picture
of
what
e2e
is
without
being
too
long-winded
so
very
quickly.
K
The
only
major
change
from
the
initial
draft
to
the
o1
is
that
we
added
a
subsection
around
endpoint
because
there
seemed
to
be
we
had
in
the
end-to-end
principle
section,
but
there
seem
there
is,
and
it's
actually
really
critical
to
figure
out
where's
the
end
in
a
device.
Is
it
the
application?
Is
it
the
operating
system?
Is
it
the
person
operating
it?
You
know.
How
do
we
do
that?
So
we
created
a
section
for
that.
K
Take
things
out,
put
them
elsewhere,
like
sort
of
use
it
as
sort
of
a
scratch
pad
for
a
while
for
things.
So
to
that
end
wondering
if-
and
we
can
discuss
after
my
next
slide,
if
there'd
be
appetite
for
a
working
group,
adoption
now
or
a
future
point
something
that
you
want
to
want
to
think
about
and
then
yeah
that's.
This
is
just
the
link
directly
to
it
and
github.
If
you
want
to
check
it
out,
do
reviews
pull
requests
and
it's
obviously
in
the
data
tracker
as
well.
K
E
Hi,
that's
it's
a
very
interesting
idea
to
do
a
definition
like
this.
I'm
wondering,
if
I
mean,
is
it
a
black
and
white
thing
or
are
there
levels
of
e3
right?
So,
for
example,
if
a
server
were
to
like
an
mls
scenario,
were
to
manage
the
groups,
as
it
knows,
the
membership
of
the
groups
and
and
so
on.
This
is
what
is
one
of
the
possible
deployment
scenarios
for
another
site?
It's
actually
so
it
does
know
a
lot
of
metadata.
E
K
Totally
agree,
that's
exactly
why
I
think
we
want
to
write
this
down
so
that
it's
there
is
clarity
around
that
precise
question.
So
I
don't
I'm
not
going
to
say
I
know
the
answer,
but
I
think
from
the
from
the
document
it
sort
of
takes
a
principled
approach
and
then
a
feature
approach,
and
I
think
where
you're
talking
about
is
maybe
the
feature
approach
and
obviously
you
know
we're
defining
anonymity
within
there,
not
because
we
think
that
every
system
is
going
to
have
perfect
anonymity
for
people,
that's
just
probably
too
hard
and
too
absurd.
K
The
way
that
implementers
like
try
to
address
these
hard
problems
and
trade
off
various
features
to
achieve
a
system
that
happens
elsewhere.
That
happens
in
other
drafts,
but
here
you've
got
sort
of
it's
almost
like
a
menu
of
of
different
options,
and
I
think
it's
going
to
help
a
lot
in
answering
exactly
that.
Question
like
are
we
comfortable,
calling,
you
know
a
system
that
maybe
has
more
metadata
than
others
like
still
and
what's
the
line
right.
C
Jwell,
hey,
I
was
just
wondering:
do
you
envision,
pgp
and
and
systems
like
that
to
be
included,
or
do
you
like,
under
this
definition
essentially
or
do
we
need,
because
you
did
mention
forward
secrecy?
Do?
Would
you
like
the
definition
to
draw
the
line
at
sort
of
updating
security
like
pcs,
fs
or
could
it
also
include
pgp.
K
You
know
group
as
well
like
to
ask
for
reviews,
because
I'm
not
well
one
is
to
ask
for
reviews,
but
then
two
to
ask
this
larger
question
of
like
where
does
this
belong,
because,
ideally
it's
it's
highly
applicable
to
everything,
that's
using
end-to-end
encryption,
but
at
the
same
time
yeah.
I
I
don't
really
know
like
I.
K
I
felt
more
confident
that
mls
is
doing
more
than
initially
you
know
had
had
set
out
to
do
by
going
beyond
just
you
know,
messaging
systems,
but
maybe
it
gets
us
a
little
bit
closer
to
having
an
answer,
but
there
are
other
ways
of
doing
this.
I
mean
yeah.
Somebody
suggested
like
putting
it
in
model
t.
I
thought
that
was
a
interesting
idea,
but
maybe
not
a
great
one,
because
I
think
yeah
model
it
would
be
like
the
anti-definition
problem
right
anyway.
C
That's
okay,
so
let
me
just
I
just
before
I
pass
on
the
token
or
whatever
we're
calling
it
I
just
wanted
to.
Why
did
I
ask
that
question
because
to
me,
pgp
is
end
to
end,
but
it's
from
an
older
generation
of
end-to-end
cryptography
and
since
then,
we've
moved
on.
You
know
double
ratchet
mls
all
these
things,
but
the
distinction
to
me
is
really
a
matter
of
the
security
they
go
for
rather
than
the
notion
of
what
is
an
endpoint
and
what
is
encrypting
to
the
endpoints.
C
And
so
I
don't
see
a
natural
way
to
distinguish
between
these
generations
of
these
technology
without
getting
into
security
definitions,
which
I
feel
is
almost
a
quagmire.
It's
it's.
It's
going
to
be
very
hard
to
clearly
define
this
in
a
way
that
we
can
talk
with
non-technical
people
about
these
notions
and
get
the
sound
bites.
So
that's
why
I
was
sort
of
asking
what
the
scope
is,
because
I
think
it's
easier
to
just
do
end-to-end.
C
C
K
No,
I
think
it's,
I
think
it's
an
interesting
one.
I
don't
really
see
like
from
a
user
perspective,
I'm
not
sure
we
have
to
get
too
precious
about
the
difference
between
the
generations.
I
mean.
Surely
so
yeah
I'd
just
like
to
to
tease
that
out
a
bit
like
what
would
be
the
goal
of
trying
to
make
a
distinction
when
potentially
they're
just
seen
as
yeah,
like
you
said
generations,
and
that
maybe
it's
a
good
thing
that
a
definition
could
encompass
both
considering
there
may
be.
K
J
K
Yup,
I
think,
that's
a
fair
question.
I
think
that
that's
obviously
something
that
would
need
to
be
in
this
definition-
and
I
think,
is
but
wouldn't
necessarily
be
part
of
what
mls
does.
I
don't
think
that
that
means
you're
completely,
avoiding
invoking
it
right.
So
I
imagine
in
the
architecture,
draft
there's
going
to
you're
going
to
be
signposting
to
implementers
like
how
the
protocol
fits
in
with
a
larger
system,
so
you
may
be
using.
K
You
know,
keywords
that
we
would
want
to
define
in
this
draft
and
actually
it's
a
really
good
use
of
this
draft
so
that
you
don't
have
to
spend
a
whole
lot
of
time
talking
about
technology.
That's
not
part
of
the
mls
protocol.
You
can
put
it
in
the
definition
draft
and
then
you
just
sort
of
point
to
it.
A
So
I
think
that
we
have
to
figure
out
what
we
would
do
with
this
going
forward.
I
think
in
the
short
term,
I
think
that
this
probably
needs
to
go
to
set
dispatch.
I
know
I'm
like
giving
you
another
working
group
to
go
to,
because
I
do
see
that
it's
more
broadly
applicable
and
that's
the
group
that
that
kind
of
says
which
working
group
to
go
to
and
whether
an
ad
should
sponsor
it.
So
it
kind
of
shows
you
the
paths
for
where
you
could
go.
A
I
want
to
draw
your
attention
to
rfc
4949,
which
is
loved
and
hated,
but
it's
365
pages
of
definitions
of
security
terms,
including
end-to-end
encryption
and
points
and
systems
a
whole
bunch
of
stuff.
It's
it's
pretty
it's
encyclopedic,
and
but
it's
much
it's
much
like
a
it's
more
like
a
dictionary
and
so
there's
less
prose.
K
K
And
I
think
that
you
know
this
wouldn't
at
all,
replace
what's
in
4949,
with
respect
to
indian
encryption,
it's
just.
This
is
a
way
more
verbose
approach
to
it
that
I
think,
provides
space
for
nuance
and
for
different.
You
know,
like
I
said.
The
ways
in
which
we
define
things
formally
can
be
very
useful,
but
they
are
limited
and
so
yeah.
I
I
think,
you're
right
that
sec
dispatch
needs
to
probably
handle
this
so.
A
Because
I
could
see
how
we
could
weigh
in,
but
then
I
could
see
the
open,
pgp
and
lamps
people
being
like
hey
what
about
us
too,
and
then
you
have
to
put
the
subtle
nuance
on
it.
So
I
think
it
seems
to
me
it
seems
to
make
more
sense
going
to
some
place
where
you're
going
to
get
broader
input
and
review.
Basically.
K
True,
true-
and
you
know,
dkg
and
stephen
know
about
this
draft
for
sure
they've
seen
early
copies
of
it
and
I
think
dkg
is
involved
in
lamps,
so
that
would
covered
that.
But
anyway,
in
any
case
it'd
be
I
mean
if
nothing
else,
I'd
like
the
opportunity
to
tell
more
people
in
the
security
area
about
this
work,
and
so
that
is
a
that's
a
good
use
of
that
space.
So
we'll
we'll
do
that.
D
D
D
A
D
D
G
G
D
A
D
L
Data
authenticated
data
yeah,
I
sort
of
snuck
that
in
because
it
was
a
tiny
change
and
I'd.
I
talked
to
richard
about
that
and
he
said
that
yeah
that
should
have
been
added
so
rather
than
creating
two
pr's
I
sort
of
snuck
that
in,
but
if
I,
if
it
should
be
two
different
pr's,
then
I
can
split
it
out.
D
L
L
So
the
the
rest
of
the
editorial
changes
are
a
big
chunk
of.
It
is
because
I
noticed
there
was
a
discrepancy
between
two
different
sections,
and
so
I
tried
to
make
them
both
agree
with
what's
implemented
in
the
mlspp
library,
and
I
think
I
managed
to
do
that
if
I've
read
the
ms
mlspp
library
correctly,
but
yeah,
I
think
someone
should
make
sure
that
I
actually
did
that
correctly.
D
D
D
H
Some
concerns,
no,
it's
okay.
I
mean
we
discussed
it
pretty
softly.
I
mean
as
long
as
there
is
some
input,
that's
fine,
so
we
could.
It
could
be
like
or
zero
input
in
the
case
where
you
you
don't
like,
you
have
an
empty
list
or
something
and
it
doesn't
impact
security.
So
your
proposal
works.
Fine,
okay,.
G
D
D
D
A
D
B
G
It
it
is,
but
I
had
a
longer
discussion
with
raphael
that
came
up
also
while
implementing
and
we
created
a
new
issue
regarding
extension.
So
it
probably
makes
sense
to
just
leave
this
for
now
and
first
discuss
the
greater
issue
about
extensions
and
then
figure
out.
If,
if
if
this
is
not
like,
if
we
don't
need
a
bigger
rewrite,.
A
F
D
B
L
D
B
So
I
think
these
have
already
been
integrated
in
the
interrupt
branches
of
the
sensations
and
really
yeah
so
yeah.
I
think
this
is
just
addressing
some
kind
of
alignment
stuff
between
what's
authenticated.
If
you
look
at
the
authenticated
data
and
confirmation
tag
lines
and
then
adding
a
missing
definition
of
parent
hash
and
allowing
for
big
extensions,
nothing,
nothing!
We're
majoring
in
this.
D
B
D
B
D
D
D
A
D
So
connor
and
I
came
across
some
issues
when
we
looked
at
how
extensions
currently
work
and
so
well,
it's
all
described
in
the
in
the
details
there,
but
the
gist
of
it
is
that
it's
not
entirely
clear
what
a
group
context
extension
actually
is,
so
we
have
extensions
that
go
into
the
key
packages.
Those
are
somewhat
well
understood
in
the
sense
that
we
have
examples
of
them,
they're
even
mandatory.
D
D
But
there
is
no
example
of
such
an
extension
and
on
how
it
would
behave.
Instead,
there
is
some
sort
of
a
counter
example,
which
is
a
registry
extension
which
is
similar,
but
it
does
not
go
into
the
group
context
specifically
because
we
don't
need
it
there.
It
would
also
be
slow,
so
it's
uncontroversial
that
it
doesn't
go
there,
but
the
question
is
what
actually
goes
there
and
how
do
these
extensions
manifest?
So
on
one
hand,
I
think
the
language
should
be
a
little
more
precise.
On
the
other
hand,
we
need
a
proposal
here.
D
To
actually
introduce
a
mechanism
to
update
extensions
by
having
a
new
proposal
type
and
that
way
members
can
initially
share
extensions
through
a
welcome
message,
which
already
has
a
feud
for
that.
Just
like
the
ratchet
tree
extension
and
then
later
on,
they
can
also
update
them,
and
the
update
mechanism
is
synchronized
with
epoch
changes
so
that
every
member
knows
exactly
what
to
put
into
the
group
context,
which
right
now
is,
is
not
clear
what
members
should
put
in
there
at
all.
C
D
So
this
is
what
the
spec
currently
alludes
to
and
introducing
this.
This
anim
here
simply
makes
it
clear
that
you
know
this
is
what
we
actually
want
to
achieve
if
it's
not
what
we're
going
to
achieve
with
the
changes
back
so
yeah.
The
proposal
here
is
to
clarify
that
they
are
indeed
really
different
kinds
of
extensions.
H
B
Clarification
here,
it
seems
like
basically
where
you're
headed
with
this
is
to
kind
of
declare
two
different
logical
classes
and
extensions
on
the
key
extensions
that
go
in
key
packages
and
the
extensions
that
go
into
the
group
context
and
the
extensions
in
the
group
context
would
be
set
by
the
creator
and
then
updated
if
at
all,
by
this
proposal.
You're
talking
about
is
that.
D
Accurate
understanding
of
where
you're
going
here
yeah-
that's
that's
pretty
much
it
exactly
so.
The
the
key
package
extensions
is
the
one
category
and
essentially
it's
completely
standalone
in
that
sense,
because
they
only
live
in
key
packages
and
in
the
second
category
there
is
a
slight
nuance
between
the
ones
that
do
go
into
the
group
context
and
the
ones
that
don't
because
we
have
this
registry
extension
so
either.
D
We
say
this
is
a
complete
exception
and
we
treat
it
as
such
and
maybe
that's
fine
or
we
generalize
this
and
say
as
part
of
a
welcome
message
you
you
can
send
a
bunch
of
different
extensions,
but
you
must
specify
which
ones
of
them
you
want
to
have
in
the
group
context.
So
having
them
in
a
group
context
means
the
group
actually
agrees
on
the
content
of
the
extension.
So
it
sounds
like
a
very
powerful
mechanism
to
have.
D
B
B
So
I
wonder
if
the
way
to
resolve
that
is
just
to
have
two
buckets
in
the
welcome
and
explicitly
say
here
are
the
extensions
that
go
in
the
group
context,
and
here
are
the
other
extensions
which
are
you
know.
Things
like
things
like
the
the
ratchet
tree
extension
would
go
in
that
you
know
local
to
the
welcome
extensions
bucket.
D
D
D
D
G
So
yeah
just
to
be
clear,
so
this
essentially
allows
implementations
not
to
rely
on
an
outside
caller
or
the
spec
to
say
what
should
go
into
the
group
context
as
opposed
to
what
doesn't
in
a
welcome
message,
but
rather
kind
of
it
can
rely
on
the
message
type.
But
then
again
I
mean
richard
if
we
go
with
the
two
buckets
that
you
proposed,
and
that
would
be
explicit
as
well,
so
that
would
at
least
partially
kind
of
make
that.
D
B
D
G
D
A
Yeah
I
gotta
run
in
about
a
minute.
I
don't
know
richard
if
you
can
richard
or
nick,
if
you
guys
want
to
job
as
well,
but
I
think
we
need
to
pick
this
back
up.
We're
obviously
going
to
make
a
request
for
a
meeting
session
for
the
itf
online.
We
may
have
to
have
another
knitter
in
the
middle
before
that
to
see.
Maybe
we
can
move
stuff
along.
I
don't
know
how
people
feel
about
that,
but
it's
something
we
should
discuss
on
the
list.