►
From YouTube: MLS WG Interim Meeting, 2020-10-06
Description
MLS WG Interim Meeting, 2020-10-06
A
All
right
off,
we
go
off
and
running,
stop
that
go
away
well
again.
Welcome
to
the
mls
interim
some
links
on
here.
Basically,
you
can
turn
your
video
on.
If
you
want
I'm
not
because
my
signal
here
is
a
little
worse
than
it
should
be.
Please
might
your
me
me:
please
mute
your
microphone
unless
you're
speaking,
try
to
use
a
headset,
to
avoid
echo,
add
your
name
to
the
affiliations
to
the
blue
cheek,
which
I'll
drop
in
chat
in
a
second
so
yeah.
A
A
That
knows
what
this
is
but
go
ahead
and
go
over
it
anyways,
basically,
that
we
have
a
lot
of
policies
in
effect
when
we're
having
an
iota
meeting-
and
this
is
actually
an
official
iitf
meeting-
you
know
about
participating,
you
agree
to
follow
the
rules.
You
know
obviously
we're
recording
this.
As
we
talked
about
the
big
deal
here
is
that
if
you
have
any
ipr
related
to
this
work,
that
you
disclose
it
and
all
that
good
stuff
and
the
other
thing
is
like
to
behave
professionally.
A
A
B
Sure
yeah,
thank
you.
Sean
yeah
we've
been
saying
that
we
wanted
to
come
to
a
preliminary
conclusion
sometime.
This
fall
and
there
was
this
rough
consensus
that
we
would
chew
through
all
the
issues
and
prs
and
github
until
everything
is
done
and
now
with
itf
109
coming
closer,
the
idea
was
to
put
up
a
tentative
roadmap
to
see
what
that
means
in
more
detail.
B
B
Once
we
have
that,
we
can
call
what
we
call
the
last
call
number
one
in
early
november,
just
before
it
of
109,
and
then
we
could
present
that
at
the
plenary
and
then
discuss
and
collect
some
feedback.
If
there
is
any
that
we
receive
during
the
the
last
chord
number
one
and
and
if
there
is
any,
we
can
issue
another
draft
11
in
that
case.
A
So
raphael
from
my
perspective,
if
you
think-
and
everyone
else
thinks
that
we
can
actually
get
through
all
of
the
open
issues
and
pr's
and
issue
a
drop
by
the
end
of
october
and
you're,
showing
you
know
that
the
two-week
working
group
last
call,
which
you
know
for
most
people
is
as
a
wave
the
flag
like.
Okay.
Now
it's
really
time
to
read
the
draft
and
provide
comments.
I
think
that'll
work
and
then
whatever
comments,
we
get
it's
exactly
the
right
use
of
the
time
at
iatf
109
to
resolve
any
of
those.
A
Basically,
I
I
look
at
kind
of
working
groups.
Last
call
there's
there's
not
there's
not
usually
just
one,
sometimes
there's
more
than
one
and
this
the
first
one
just
basically
kind
of
flushes
out
any
major
issues
that
people
haven't
really
felt
the
need
to
voice,
or
you
know,
haven't
gotten
around
the
chance
to
read
it
and
it
brings
other
people
that
are
interested
peripherally,
but
not
super
involved
in
this.
To
kind
of
you.
B
B
B
So
yeah
post,
itf
109,
potentially
we
issue
a
new
draft
depending
on
the
feedback.
But
then
the
important
part
here
really
is
that
we
have
a
feature
freeze
for
some
time.
So
during
that
phase
we
want
to
focus
on
implementation
and
also
an
analysis
and
the
goals
for
that
period
is
to
really
have
multiple
implementations.
So
I
think
this
working
group
is
lacking
a
little
bit
behind
in
the
general
idea
of
rough
consensus
and
working
code.
B
So
we
have
some
code,
but
it's
fair
to
say
that
none
of
that
is
currently
really
interoperable.
So
we
really
need
to
get
there.
I
think
there
is
a
lot
of
confidence
that
it's
gonna
work
and
just
a
matter
of
figuring
out
some
details,
potentially
touching
the
draft
again
for
that,
and
then
of
course,
because
mls
is
meant
to
be
a
secure
protocol.
We
need
to
leave
some
time
for
security
analysis
and
particularly
because
we've
been
doing
a
lot
of
changes
in
the
protocol.
B
A
B
D
D
B
I
think
it
would
actually
be
very
helpful
if
somebody
from
the
academic
community
could
give
an
overview
of
what
kind
of
analysis
is
going
on
who's
doing
what
what
time
they
project
they
they
would
need
for
that.
I
think
that
would
be
very
helpful
to
to
get
a
better
understanding
of
how
much
time
we
need
to
factor
in.
For
that.
A
I
mean
so
probably
because
we'll
get
more,
we'll
get
more
people
at
ietf
109.
If
we
have
a
draft
of
it
for
the
next
interim
and
then
if
you
could
be
prepared
to
talk
about
it
at
the
ietf
109
meeting,
whenever
that's
going
to
end
up
or
somebody
will
be
available,
because
I
think
that'll
it'll
be
better
to
give
a
broader
community
a
sense
that,
where
we're
going
to
give
us
a
warm
and
fuzzy
as
we
progress
forward.
E
Okay,
I
guess
I
so
I
have
some
insight
into
what's
going
on
in
the
analysis
part,
but
I
guess
brita
if
you
could
help
me
figure
out,
what's
going
on
on
your
end
as
well,
and
if
you
know
of
any
other
groups
that
are
doing
analysis,
that
would
be
useful
and
then
I
can
try
and
put
together
a
summary
and
by
next
interim.
I
should
know
if
I've
got
enough
to
you
know
to
to
actually
have
a
useful
summary
or
not.
Does
that
sound
okay.
A
So
from
from
a
working
group
share
perspective,
that's
perfect!
You
guys
talk
about
it.
We
talk
about
it
briefly
to
try
to
you,
know,
match
it
together
and
then
give
us
a
couple
of
weeks
to
put
things
together
and
figure
out.
If
there's
anything
else,
we
could
put
open
calls
out
on
the
mailing
list.
If
we
need
to.
F
Yeah
I
I
talked
to
I
have
to
be
talking
about
with
karl
think
about
something
else,
and
we
discussed
having
a
call
you
know
like
once.
We've
got
the
next
draft
out
that
we
think
is
pretty
much
complete,
just
like
having
an
open
call
for
whatever
academics
are
interested
to
kind
of
bring
people
up
to
speed
on
the
latest
stuff
as
a
way
to
kind
of
kick
off.
The
last
round
of
analysis.
B
E
Yeah,
I
can
do
that
so
basically
I'll
formulate
an
email,
that's
sort
of
is
a
call
to
you
know
anybody
doing
analysis,
we're
trying
to
compile
a
an
overview
of
what's
being
done.
What's
being
done
and
what's
going
to
be
done
and
anybody
who
can
contribute.
Please
hit
me
up.
That's
basically
what
it'll
say.
E
B
So
I
tried
to
categorize
the
the
changes
into
two
categories.
One
is
breaking
changes,
meaning
clients
wouldn't
be
able
to
interpret
anymore.
The
protocol
would
effectively
change
and
non-breaking
changes.
So
non-braking
changes
are
not
a
problem
during
that
phase,
so
try
to
put
down
some
examples
like
editorial
changes,
obviously
functional
changes
that
don't
affect
the
protocol
directly
and
also
extensions
if
they
do
not
touch
the
how
the
core
protocol
works
and
breaking
changes.
This
is
where
we
have
to
tread
more
lightly.
B
So
that's
quite
obvious
when
it
comes
to
improvements
of
security
that
it's
probably
something
we
should
discuss,
whether
that
should
constitute
a
breaking
change
or
not,
and
then
on
the
implementation
side,
we
have
to
see
how
easy
it
is
to
implement
all
of
that
efficiently
or
whether
it's
possible
at
all.
In
the
past,
we
had
a
few
situations
where
things
were
actually
not
we're
not
able
to
implement
things.
B
F
F
A
A
A
F
I
have
an
easy
one
to
start
with,
which
is
I'm
going
to
propose
not
doing
stuff,
I
think
number
349
on
using
opaque
epoch
ids,
I'm
going
to
propose
we
just
close
that
because
that's
been
around
for
a
while
some
folks.
You
know
we
got
to
the
point
where,
like
it
doesn't
really
matter
which
side
of
this
we
end
up
on
and
there's
some
operational
simplicity
to
having
things
the
way
they
are.
So
it
doesn't
seem
like
there's
a
real
slam,
dunk
argument
to
make
this
change.
F
F
E
F
I
think
I
agree
with
with
you
in
principle,
but
syntactically.
It
seems
awkward
to
put
that
up
in
the
well.
Maybe
it's
not
oh
yeah.
It's
it's!
It's
a
bit
awkward
to
put
that
up
with
the
membership
tag
up
with
the
proposal,
because
I
think
the
idea
was
the
membership
tag
would
be
the
first
thing
you
verify
so
in
the
spirit
of
kind
of
verifying
from
the
outside.
In
you
know
having
to
reach
in
and
get
the
first
thing
you
verify
seems
you
know
you're,
then
parsing
data.
That's
that's
not
verified.
C
F
F
E
Sure
I
think
it
doesn't
harm
security
to
include
it
also
for
commit.
I
think
it's
just
it's
a
pity
for
the
bandwidth
and,
however,
you
guys
think
is
you
know
the
most
elegant,
like
from
engineering
perspective,
to
solve
that,
whatever
that
yeah
that
works
for
me
yeah,
it's
really
just
it's
not
a
problem
to
include
it
with
these
messages
or
to.
E
F
C
E
C
A
B
C
B
F
A
F
C
F
G
I
think
it's
a
bit
optimistic
regarding
the
fs
guarantees
the
psp.
Well,
not
the
pcs
guarantees,
I
think,
but
oh
yeah,
it's
not
incorrect.
I
think
it's
just
the
way
you
kind
of
how
you
want
to
how
careful
you
want
to
be
when
you
phrase
it,
but
then
again
we
could
leave
this
in
as
a
kind
of
general
thing
as
brendan
proposed
and
then
be
more
precise
in
the
architecture
document.
I
think
that
would
be
okay.
C
C
G
Well,
it's
I
think
it's
just
about
the.
Why
and
then
about
the
when
so
I
mean
mls
is
very
intricate
with
regard
to
forward
secrecy,
so
kind
of
you
can
be
arbitrarily
kind
of
detailed
about
when
you
get
which
kind
of
forward
secrecy
under
which
circumstances
so
in
the
architecture
document.
I
think
we
should
be
very
detailed
about
this,
or
at
least
not
kind
of
overstate
it
and
be
conservative
about
our
statements,
but
here
yeah,
I
don't
know
as
long
as
there's
a
link
to
the
architecture
document
for
kind
of
more
precise
information.
F
F
G
So
I
don't
propose
changing
the
basic
credential
or
x509
or
anything
just
kind
of
just
propose
to
phrase
it
in
such
a
way
that,
if
there's
a
certificate
that
contains
multiple
signature
schemes
and
multiple
key
pairs,
you
should
pick
the
one.
That's
corresponds
to
the
surface
of
the
group
and
then
use
that
one
essentially.
G
F
Yeah,
I
think
I
removed
the
signature
scheme.
You
know
when
we
decided
that
signature
schemes
were
going
to
be
part
of
the
cipher
suite,
because
if
within
the
scope
of
mls,
you
could
infer
it
from
the
enclosing
key
package
so
rather
than
allowing
a
potentially
conflicting
indicator,
I
decided
to
infer
it,
but
I
I
wouldn't
object
to
adding
it
back
your
point
about
the
the
idea
that
these
credentials
might
exist
elsewhere
seems
seems
compelling,
and
it's
really
just
really
just
reusing
an
enum
from
from
tls.
So
it's
it's
pretty
low
low
complexity.
G
C
I
think
that's
a
point
that
we
wouldn't
want
to
allow
conflicting
indications
between
the
key
package
and
the
credential
like
I'm,
it's
not
clear
to
me.
The
credentials
would
well
so
I
guess
they
they
might
be
shared
between
several
key
packages,
but
if
you
ever
like
get
a
credential
specifically,
it
does
have
to
be
clear
already
what
signature
scheme
you
need
to
use.
D
So
there
is
one
a
case
where
you
can
have
multiple
schemes
inside
of
that
credential
and
that's
if
you're
hybridizing
certificates
in
any
way-
and
we
talked
about
by
writing
post
quantum
and
standard.
But
I
also
haven't
seen
that
like
this
within
the
standard
world,
then
they
actually
were
looking
at.
D
So
what
conor
is
proposing
is
that
this,
the
group
can
only
handle
the
standards
and
right
that
that's
the
one
that
everyone
has
to
use
in
group,
but
at
least
you
can
see
them
the
certificate
and
maybe
that
certificate
can
be
used
across
a
couple
groups,
and
maybe
a
different
group
is
able
to
handle
those
quantum.
It's
just
one
use
case
example.
F
G
F
So,
okay,
fair
point,
but
you
know
if
you're
talking
about
a
certificate,
now,
there's
a
single.
You
know
this.
The
subject:
public
key
info
has
a
single
algorithm
identifier
on
the
key,
so
even
in
that
case,
the
key,
even
if
it's
a
compound
key,
has
a
specific
signature
algorithm
that
it
indicates.
F
A
A
F
F
B
F
G
Right
but
then
the
so
okay,
we
have
the
behavior
that
extensions
can
change
without
the
spec
does,
but
it's
not
like
the
way
that
credentials
are
kind
of
extensible
in
quotes
is
that
you
can
add
new
credentials,
but
that
doesn't
mean
you
can.
Actually
they
can.
I
can
somehow,
by
introducing
a
credential,
I
can
somehow
change
the
spec
for
that
I
would
have
to
have
an
extension
which
goes
into
the
group
which
changes
the
behavior
of
the
spec.
So
it's
not
clear
to
me
how
that
would
be
mandated
well.
F
F
So
you
know
as
long
as
it's
clear
for
a
given
type
of
credential
how
you
get
a
public
key
out
of
it
for
the
for
the
context.
You
know
for
a
given
mls
session
right.
That's
just
how
you
process
that
type
of
credential
and
they're.
You
know
the
implementation
is
going
to
have
to
have
logic
for
processing
that
kind
of
credential.
In
any
case-
and
this
is
just
an
aspect
of
that
processing.
G
G
F
I
see
what
you
mean
yeah,
so
I
think
we
could
revise
that
to
be
to
be
clear
that
to
say
that
you
know
each
type
of
credential
had
its
main
function
is
to
provide
a
public
key
for
use
in
verifying
messages,
and
it's
up
to
the
credential
type
to
say
how
that
public
key
is
derived
in
basic
credential.
It's
just
listed
out
there
in
x,
509
credential.
You
have
to
parse
it
out
of
the
leave
certificate.
G
E
While
we're
on
the
subject,
I
have
a
just
a
high-level
question,
maybe
maybe
someone
can
answer?
I
was
wondering
how
the
setup
would
look
the
ideas
for
mls
to
be
federated
suppose
one.
You
know,
one
server
is
an
organization
where
everybody
wants
to
use
these
curve.
Two
five,
five
one
nine
and
the
other
one
is
like
nist
curves
and
then
the
third
one
is
post
quantum.
E
I'm
I
want
to
prepare
key
packages,
so
anyone
any
person
on
any
one
of
these
servers
can
invite
me
to
a
conversation
from
the
get
go.
But
I
how
does
how's
that
envisaged
like
do
I
do
do?
I
have
key
packages
for
curve
credentials,
other
key
packages
for
post
quantum
ones
and
third,
one
key
package
set
of
key
packages
and
they're
all
hosted
on
my
aes
or
so.
B
So
in
order
to
have
some
partial
prevention
of
downgraded
tanks,
but
you
would
still
have
to
have
a
dedicated
key
package
for
every
cypher
suite
sorry,
so
you
would
have
to
publish
multiple
key
packages
for
that,
which
is
just
just
more
work
at
that
point.
But
then
the
the
plus
is
that
the
key
packages
are
going
to
be
smaller.
So
I
think
the
idea
was
that
you
can
request
them
from
the
server
by
saying.
Okay,
I
want
to.
B
I
want
to
have
a
key
package
for
this
client
supporting
that
cypher
suite,
and
so
it
would
just
give
you
the
right
key
package,
but
then
yeah
regarding
the
credential
here.
It
would
be
awkward
because
of
the
different
cipher
suites.
If
you
have,
if
you
had
different
credentials
that
effectively
belong
to
the
same
client.
E
G
Happened
it
is,
I
don't
know
you
would
yeah.
So
the
idea,
if
you
actually
had
one
credential,
that
that
supports
all
your
keys,
that
you
have
that
all
your
identity
keys,
then
you
can
have
just
one
pool
for
each
cipher
suite.
If
we
don't
have
that,
then
you
would
have
to
have
like
for
each
signature
scheme
that
you
support.
You
would
have
to
have
all
these
pools
again.
B
B
G
G
B
Yeah
so
take
that
on
yeah,
so
the
the
general
feedback
I've
been
receiving
so
far
is
that
the
the
mechanism
is
a
useful
one
and
that
it's
something
we
should
look
into
doing,
and
so
I
updated
the
pr
just
ever
so
slightly
and
brendan
your
comments
are
spot-on.
So
there's
still
one
big
part
missing
here,
and
that
is
what
we
do
with
the
unit
secret.
So
in
the
initial
proposal
I
said
we
leave
it
empty
completely.
B
As
a
mechanism,
so
the
the
question
here
is
in
in
security
terms,
what
can
we
improve
and
the
idea
with
that
is
that
if
we
leave
the
init
secret
empty,
then
an
attacker
who
wants
to
get
into
the
group
just
needs
to
know
one
of
the
node
secrets
that
are
relevant.
So
the
new
member
is
going
to
come
when
you
commit
secret
to
one
of
or
to
several
nodes
in
its
co-path.
B
B
C
F
F
F
It
doesn't
add
anything
in
the
internal
commit
case
and
it
creates
an
opportunity
for
an
additional
thing
that
could
leak.
So
this,
the
ephemeral
stuff
that's
generated
for
the
hpke
encryption,
you
know,
could
be
a
a
key
that
is
passed
to
someone
else
or
accessed
by
some
attacker
that
wouldn't
otherwise
be
involved.
So
it's
not
adding
anything
and
it
creates
another
thing
that
can
leak,
so
I'm
kind
of
inclined
not
to
do
it.
For
the
internal
case.
C
Well,
my
point
is
that
it's
a
lot
simpler
for
the
implementation,
if
there's
only
one
major
flow
or
handling
commands
versus,
if
you
have
to
handle
internal
and
external
commits
separately.
That
indicates
to
me
that
there's
going
to
be
some
sort
of
security
difference
between
the
two
commits,
which
we
don't.
E
D
C
What's
the
value
in
somebody
who
doesn't
know
the
current
key
schedule,
I
mean
proving
that
somebody
does
like.
Does
that
tell
anything
to
the
application
of
the
end
user,
because
I
know
that
another
thing
that
we're
working
on
is
allowing
people
to
bootstrap
themselves
back
into
a
group
after
they've
like
lost
their
state
or
something.
So
that's
also
something
that
we
want
to
allow
people
to
rejoin
without
knowing
the
current
state.
E
So
currently,
our
commits
have
two
ways
in
which
the
authenticate
december
right,
the
signing
keys
and
the
fact
that
you
know
the
current
group
schedule.
We
do
that
with
various
different
mechanisms
like
the
transcript
hashtag
confirmation
tag
and
now
the
matching
and
the
plain
text
with
this
external
commit.
We
no
longer
have
that
second
guarantee.
We
effectively
are
nothing
more
than
what
the
signature
provides
us,
so
we
can
drop
a
whole
ton
of
other
stuff.
If
that's
all
we
care
about,
then
there's
all
kinds
of
simplifications.
We
can
make.