►
From YouTube: IETF-MLS-20221216-1500
Description
MLS meeting session at IETF
2022/12/16 1500
https://datatracker.ietf.org/meeting//proceedings/
B
C
D
C
C
C
D
B
A
D
A
C
A
Again,
thanks
for
dialing
in
at
whatever
hour,
it
is
where
you
are.
This
is
an
official
meeting
of
the
ITF,
so
it's
an
ITF
MLS
meeting
I
just
want
to
do
the
no
well.
A
lot
of
this
is
about
IPR
I.
Think
I've,
I
think
I've
seen
everyone
at
one
of
these
meetings
before
so
you
shouldn't
be
new.
This
is
one
of
those
deals.
A
If
you
say
something
you
got
to
submit,
if
you
don't
and
I
find
out
about
it,
I
will,
which
is
actually
what
I
did
in
the
past,
there's
also
some
stuff
about
personal
conduct
Etc.
Luckily,
this
working
group's
not
had
any
of
those
problems,
so
that's
good,
but
if
you
want
to
know
anything
about
these
feel
free
to
click
on
these
I'll
put
them
in
the
meeting
repo.
A
At
some
point,
if
you
have
any
other
questions,
you
can
also
ask
me
all
right
what
is
next
status
code
of
conduct?
This
is
all
true
everybody
with
respect.
Try
to
speak
slowly,
limit
the
use
of
slang.
You
know
just
beat
ideas
by
using
reason:
argument
best
engineering
judgment,
the
best
solution
for
the
whole,
the
internet
and
contribute
all
right.
A
What
else?
Let's
do
the
whole
thing
we're?
Basically,
here
still
the
whole
timeline.
We
had
a
feature
freeze
with
a
working
bus
call,
the
80s
done
some
review
and
then
we're
kind
of
here
and
we're
basically
kind
of
at
the
same
point
with
both
the
protocol
and
the
architecture
document
and
we're
about
looking
like
we're
going
to
be
ready
to
send
a
clean
document
forward
to
iitf
last
call,
which
typically
lasts
two
weeks
because
of
the
holidays.
I
suspect
it
might
go
four.
A
F
A
A
G
G
It
was
actually
not
a
device
level
authentication,
but
it
was
a
client
level
application,
so
I
fixed
that.
But
apart
from
that,
it's
basically
a
very,
very
simple
thing:
I
also
added
the
accommodation,
that's
on
the
bottom
right
below
the
the
comment
resolved,
which
is
to
avoid
sharing
cryptographic
State
as
much
as
possible.
We
could
basically,
if
you
do,
that,
you
are
putting
yourself
in
the
you're
shooting
yourself
in
the
foot,
because
people
you
know
another
Cricket
has-
can
have
control
over
one
device
and
then
give
itself
a
good.
G
However,
the
keys
of
other
devices.
So
that's
that's
pretty
bad.
Apart
from
that,
like
you
can
read
the
text,
it's
very,
very
Uncle
commercial
and
generally
I
mean
all
the
changes
are
requested
by
Paul
were
mostly
traffic
editorial
clarification,
since
there
is
no
nothing
actually
normative
in
that.
In
that
document
it's
also
much
easier
to
actually
solve
those
problems.
Yeah.
A
G
I
mean
it's
probably
a
like
a
long
like
you
know,
you
could
read
that
document,
so
I'm
gonna.
What
I'm
gonna
do
is
that
I'm
gonna
do
another
full
pass
over
the
entire
document,
because
sometimes
we
like
with
those
many
editorial
changes,
we
actually
introduce
duplications
or
things
like
this,
but
there
isn't
there
is
going
to
be
anywhere
and
nothing.
A
Yeah
I
mean,
if
there's,
if
there's
minor
things
that
you
note
just
fix
them,
if
it's
any
again
I
I
kind
of
trust.
Your
judgment
that,
if
anything
kind
of
raises
the
level
of
like
hey
I,
need
to
double
check.
That'd,
be
great.
Just
ask
for
a
review
from
somebody
that
that'll
work
too.
But
if
it's,
if
it's
simple
editorial
stuff,
just
fix
it.
A
G
B
B
A
Mean
I
I
would
I.
I
would
say
that
there
there
are
some
other
people,
that'll
catch
duplications
in
the
lake
forest,
but
feel
free
to
if
we
do
publish
at
Benjamin
I
think
it's
okay,
that
you
have
another
working
version
that
that,
like
you,
don't
publish
yet
you
can
point
that
more
more
and
more
reviewers
are
becoming
more
and
more
Savvy
about
GitHub
and
we'll
note
that,
like
oh,
you
know,
the
editors
already
got
one
rolling
and
they
fix
it
over
here.
A
E
G
B
C
B
A
B
B
You
know
disambiguate
signatures
from
different
contexts.
They
don't
overlap
when
he
pointed
this
out
I.
Maybe
the
the
analogy
occurred
to
me
of
exporter
labels.
Tls
has
an
Explorer
label
registry
I
checked
with
Hecker,
to
say:
hey
was
that
an
accident
or
like?
Is
that
something
you
do
again?
If
you
had
the
chance
I
mean
he
said
this
is
a
good
thing
to
have
so
I
added
an
exporter
label
registry
as
well.
So
this
just
makes
two
two
new
Registries
points
to
them
from
the
text.
B
Oh
the
other
change
here,
I
did
you'll
notice.
These
recommended
changes
in
all
the
other
registries.
All
the
Registries
were
copying
and
pasting
the
recommended
text
from
sniper,
Suites
and
so
I
just
made
it
point
back
to
that
section
instead
of
copying.
So
hopefully,
that's
okay,
the
only
thing
that
seemed
like
it
might
be
interesting
or
controversial
on
the
Registries
themselves
is
I
put
a
provision
in
here
for
private
use.
A
I
mean
some
people
are
gonna,
love
it.
Some
people
are
going
to
hate
it,
it's
something
we
could
bike
on
for
a
while,
but
if
it's
a
functionality
we
need
or
want,
then
I
think
we
just
have
to
be
like
all
right.
Well,
you
tell
us
what's
the
way,
what's
the
the
quote-unquote
right
way
to
do
it
and
we'll
do
that?
This
is
just
our
suggestion.
So
I
don't
think
you're
looking
you're,
not
looking
for
a
hill
to
die
on
here,
you're,
just
looking
for
a
mechanism
right,
so
yeah
yeah,
you
gotta,
be
fine.
F
E
If
you
you
know,
if
you
wanted
to
have
so,
if
you
really
wanted
people
to
go
and
expected
people
to
do
stuff
in
in
a
private
space,
you
could
ask
them
to
use
the
reverse
domain
name,
but
I
don't
have
a
strong
feeling.
I
I
think
this
is
fine.
I'm,
not
sure
that
saying
you
know
begin
with.
Private
colon
is
necessary,
but
the
the
problem
that
we've
had,
though,
is
when
we
when
somebody
started
off
and
did
something
that
was
private
and
that
it
became
something
that
was
standard.
E
B
D
B
I
think
the
the
other,
the
other
thing,
the
contrast
with
this,
these
strain
values,
as
opposed
to
integers
with
finite
size,
is
that
these
aren't
really
contentious
right
like
if
someone
gets
you
know,
X
forwarded
for
or
just
defines
forwarded
for.
You
can
Define,
you
know
forward
and
on
behalf
of
or
some
some
like
language
variant
of
it.
A
So
I
will
note
that
in
the
most
recent
discussion
about
exporters
in
TLS
was
that
a
discussion
about
making
the
registry
specification
required,
so
the
designated
expert
can
so
there's.
There's
there's
no
need
and
they
actually
don't
have
that
for
exporters
right
like
I,
don't
think
they
actually
have
a
private
label
in
the
front.
So
maybe
I
don't
know.
A
B
A
A
I
mean
I.
Just
again,
like
you
said
it's,
you
know
we're
we're
gonna.
You
know
we're
gonna
spell
the
name
wrong
and
be
cool
right
on
purpose
like
that
to
to
differentiate
it.
So
if
it's
not
a
resource
constraint,
I
feel
like
maybe
we
can
just
drop
it
granted.
This
is
probably
opening
us
up
for
a
gen
art
comment,
but
you
know
at
least
we've
talked
about
it
now.
So
I
think
that
will
happen
either
way
correct.
A
B
Yeah,
okay,
I'll.
Remove
that
one
other
thing
to
note
here:
if
you
scroll
down
in
the
exporter
label
registry
definition,
there's
nothing
there
in
the
initial
contents,
there
are
no
initial
Contents
I,
don't
know
if
that'll
trip
anything
up
and
I'm
Sean.
Do
you
remember
having
issues
with
defining
empty
Regis
Registries
that
are
empty
to.
A
A
H
B
A
A
B
A
B
B
B
I
noticed
this
morning
that
so
there
is
I
think
brought
a
pretty
broad
agreement
on
that
mapping
in
the
p
in
the
issue,
yeah
the
one
people
seem
to
be
unhappy
with
his
group
content,
so
Conrad
suggested
message.
Contents
I
think
Benjamin
suggested
frame
content
a
little
lower
I,
it's
just
a
name:
I,
don't
care
so
who
wants
to
fight
it
out.
G
G
G
G
B
D
H
C
Well,
I
mean
this.
The
encrypted
message
is
also
assigned
so
right,
but
yeah
I
don't
have
a
preference
like
either
message
or
frame,
not
a
huge
fan
of
the
group
content,
maybe
also
because
it
sounds
a
bit
more
like
group
context.
But
then
again
that's
maybe
it's
it's
not
bad
that
bad
in
terms
of
confusing
myself.
B
B
C
B
Okay,
on
Rowan's
point
about
public
private
yeah,
I,
I
kind
of
enjoyed
the
ambiguity.
The
public
and
private
gave
you,
because
you
know
it's
as
Conrad
points
out,
it's
a
little
tough
to
get
into
specifics
and
still
be
concise,
so
I'm
kind
of
inclined
to
keep
public
and
private.
So
anyone
else
kind
of
share
around
his
concerns
there
or
have
different
suggestions.
G
A
B
B
So
I'll
open
it
out
that
we
have
this
Center
data
construction,
where
we
grab
a
sample
of
the
ciphertext
and
use
that
to
create
the
key
and
notes
to
encrypt
the
sender
data,
and
you
know
that
correctly
set
off.
You
know
some
flags
for
him,
because
there
wasn't
much
analysis
showing
you
know
of.
Why
that
you
know
taking
a
sample
of
the
subvertext
is
secure
like
what
the
ciphertext
is.
You
know
non.
It
was
maliciously
crafted
to
have
a
specific
prefix.
B
B
So
the
quick
this
is,
this
section
is
effectively
just
a
copy
pasted
into
adaptation
of
the
text
in
RFC
9001
kind
of
pointing
out
how
this
Maps
over
to
to
that
paper
and
its
analysis,
and
that
you
know
the
paper
analyzes
this.
This
hn1
construction,
which
is
which
is
effectively
what
we're
doing
here
and
shows
that
if
the
primary
aad
is
indistinguishable
from
random
data,
then
the
the
sample
and
derive
key
and
and
obviously
the
sender
data
scheme
also
protects
the
sender
data.
B
B
B
H
A
I
G
H
C
Guess
the
thing
to
know
is
that
we're
not
exactly
doing
what's
in
the
paper,
but
we're
do
you
like?
We
are
dividing
a
bit
and
that
we
don't
like
in
the
paper
they
use
soar,
we
use
aad
and
then
the
paper
they
use
the
ciphertext
to
like
as
the
nons,
and
we
only
use
the
ciphertexts
to
as
as
kind
of
as
context
input
to
a
prf
that,
in
addition
to
a
proper
key,
derives
the
nouns
and
the
key.
C
I
B
All
right
so
I'll
go
I've
got
that
marked
as
ready
to
merge
in
the
notes.
So
thanks
for
the
for
folks
taking
a
look
all
right.
So
that
brings
us
to
the
last
two
here:
seven,
eight
thirty,
seven,
eight
thirty
eight,
which
are
results
of
a
suggestion
from
Tiff.
You
know
actually
Sean.
You
want
to
click
over
to
the
issues
for
a
second.
D
D
B
Well,
I
think
we
may
have
lost
Airfield
if
I
could
I'll
try
and
pick
up
where
he
was
leaving
off
I.
Think.
The
idea
of
this
idea
is
that
we
have
this
unmerged
construct
and
we
use
it
when
we
add
new
members,
but
it
can
actually
be
used
at
remove
time
as
well,
in
the
sense
that
if
a
leaf
is
unmerged
at
a
parent
node,
that
means
that
the
leaf
holder
doesn't
know
the
private
key
for
that
parent
node.
B
Raphael
noted
in
the
issue,
though,
that
unmergedly
the
Integrity
of
Technology
Mercedes
consistent.
It
could
be
so
a
malicious
Adder,
so
he's
adding
some
a
new
member
to
the
group
could
construct
a
tree
that
has
unmerged
leaves
that,
where
you
know
a
leaf
that
is
marked
as
unmerged
when,
in
fact
it
actually
knows
the
private
key.
B
And
so,
if
you
followed
the
logic
here,
you
would
remove
them
from
the
emerged
leaves
and
the
about
the
number
would
still
be
joined
if
effectively,
because
they
know
the
private
key
for
the
node
and
that
nerve
would
still
be
in
the
tree.
I
think
with
some
additional
validation
rules
we
can.
We
can
get
to
where
that's
not
an
issue,
but
you
know
we
need
to
have
those
validation
rules
and
the
curves
that
they
actually
accomplish
the
properties
we
need
here.
B
B
So
in
light
of
that,
I
went
ahead
and
wrote
up
two
PRS,
one
of
which
adds
some
validation
rules
to
the
the
tree.
Validation,
the
Integrity
validation
that
incorporate
that
enforces.
Some
stricter
rules
on
emerged
leaves
and
I
also
wrote
a
PR
that
implements
this
in
terms
of
removing
from
unmergedly
it's
effectively
the
stiff,
I
posted.
F
F
That
is
not
quite
the
same
as
if
you
had
done
the
update
so
and
then
so
you
only
get
an
optimization
when
a
new
journalists
that
haven't
done
the
update
are
being
removed,
and
my
question
is
How
likely.
Is
that
ever
to
happen
in
some
very
specific
scenarios
it?
It
could
be
more
frequent
where
a
lot
of
people
constantly
join
and
a
lot
of
them
get
removed
by
somebody
else,
but
in
general
this
is
not
likely
to
happen
at
all.
F
G
This,
this
exact
thing
was
actually
discussed
when
I,
don't
remember
if
you
I'm,
not
sure
if
you
remember
when
I,
when
I
was
a
dhff
just
introducing
the
the
unmerged
leaves
and
passing
with
Gothic
that
that's
the
exact
discussion
that
we
are
like
on
the
first
day
when
we
introduced
emerges
like
because
we
can
remove
that
as
fast
as
we
add
them.
Basically,
but
that
said,
I
do
agree
with
you
that,
from
my
point
of
view,
it's
not
really
the
theoretical
problem
that
that
that
can
occur
in
terms
of
security.
G
It's
like
it's
quite
good,
but
I'm,
not
sure
if
it
if
it
was
doing
simply
because
of
the
of
the
additional
complexity
of
the
bookkeeping
of
making
sure
that
you,
you
keep
tracker
by
saying
that
someone,
you
know
if
you
lose
State.
What
does
that?
What
what
happens?
If
you
look
at
the
wrong
node
in
the
chain,
you
say:
oh
maybe
you
know
there
is
no
animals
live
there.
So
there
is
no
mercy
anywhere,
but
maybe
that's
wrong.
G
F
I
Yeah
I
was
just
going
to
say
that
I.
That
was
also
my
suggestion
to
make
it
an
extension,
maybe
because
I
I'm-
it's
really
not
clear
to
me
at
this
point.
How
secure
this
thing
is.
It's
like
can
like
I
I,
don't
really
fully
understand
why
some
malicious
member
can't
undo
remove
off
of
himself.
Somehow
I
would
have
to
look
at
this
like
much
stronger
and
none
of
the
existing
analysis
has
this
they're
not
going
to
be
updated,
so
I'm
a
bit
reluctant
to
make
it
part
of
the
standard
extension
is
fine.
G
A
B
B
D
B
This
just
adds
the
additional
check
that
everything
between
the
parent,
node
and
any
non-blank
I
should
add
non-blank
to
the
intermediate
notes,
but
everything
between
the
parent
in
question
and
the
leaf
node
also
has
the
leaf
node
as
as
unverged,
which
is
a
property
that
you
have
in
all
the
real
cases
of
on
merged
leads,
so
anything
that
violated
this
invariant
would
be
synthetic
and
maliciously
crafted
and
not
something
that
came
about.
Naturally,
right.
H
Checks
seem
seem
to
make
sense
to
me.
My
take
is
you
know,
we're
not
going
to
harm
anything
by
introducing
more
checks
as
long
as
we're
not
breaking
correctness,
and
they
don't
seem
to
break
correctness.
So
unless
there's
you
know
counter
arguments
in
terms
of
oh,
this
imposes
a
lot
of
whatever
computation
or
something
like
that.
It
seems
like
pretty
clear
sailing
for
me.
That's
my
initial.
Take.
F
F
B
F
B
Little
there's
a
little
bit
of
redundancy
in
that
the
the
parent
hash
rules
check
this
property.
This
you
know
the
continuity
property,
a
downward
continuity
property
within
a
parent
hash
chain,
but
if,
if
it
crosses
it,
doesn't
the
parent
has
chain
validation,
it
doesn't
enforce
this
property
across
parent
hash
chains.
So,
if
you're
at
the
bottom
of
a
deep
tree-
and
you
know,
there's
Crossing
chains
above
you-
this
adds
an
explicit
check.
H
H
B
H
F
I
I
I
B
Cool
all
right,
yeah,
no
I
I
encourage
you
all.
That's
it's
a
good
good
point
that,
like
I,
don't
think
this
Harm's
correct
it's
it's
not
super
inefficient
and
I,
don't
see
how
this
could
harm
security
so
yeah.
That
seems
like
pretty
clear
argument
for
going
and
merging
right
any
thoughts
here
since
you
just
popped
up
on
video,
okay
thumbs
up
all
right.
I
think
this
is
ready
to
merge
them.
B
B
A
A
F
So
I
think
at
some
point,
tearfield
started
looking
also
into
the
security
of
the
targeted
messages,
but
there
was
some
some
part
missing
at
the
time,
so
that
should
be
there
now
yeah,
then
I
think
the
only
other
thing
that
needs
discussing
in
general
is
Ron's
PR
that
so
the
context
is
either.
We
add
that
here
in
the
extensions
document,
or
we
make
it
a
separate
document
that
was
an
open
question
and
I
think
the
idea
was
to
discuss
it
at
the
mentoring.
D
H
H
H
You
can't
use
ciphertext
from
one
like
generated
in
one
setting
and
plug
it
in,
and
it
gets
decrypted
successfully
in
the
other
setting
that
that
wouldn't
be
good
right,
that
that
leads
to
problems,
and
indeed
it
doesn't
it's
not
possible,
but
it's
not
possible
kind
of
almost
as
a
side
effect
of
how
the
psk
thing
works
in
hpke,
which
I
don't
I,
don't
feel
like.
That
was
really
the
intention,
and
so,
for
example,
one
thing
one
could
do
is
one
could
create
an
extension
that
says.
H
Oh
I
want
to
do
psks
in
MLS,
because
whatever
I'm
worried
about
post
Quantum
I
have
some
external
post,
Quantum,
secure,
psk
and
the
way
I'm
going
to
do
it.
Why
not
I'm
going
to
use
psks
into
hpk
ciphertext
as
well,
like
whatever
I'm
I'm?
What
I'm?
What
I'm
showing
with
this
is
suddenly
this
extension
that
you've
defined
for
targeted
messaging
is
no
longer
secure
if,
depending
on
how
that
psk
extension
is
written
because
there's
an
interplay
there
with
the
psks.
H
I
C
H
I
So
it
it's
good.
You
mentioned
the
labels
in
signatures.
Actually,
that's
why
it's
okay
to
reuse
the
signature
key,
because
we
use
labels,
we
separate
everything
by
this
label.
So
that's
why
we're
not
so
concerned
about
reusing
the
signature
key
in
the
lead
for
that
for
this
extension.
But
we
should
do
something
similar
for
hpke
somehow,
but.
F
F
C
I
Yeah
I
think
we
could,
but
we
would
have
to
write
the
protocol
in
a
way
that
it
allows
reuse
of
its
key
to
for
different
purposes.
As
long
as
the
info
is
different,
it
would
have
to
be
explicit
in
the
protocol
as
well.
I
think
it's
now
explicit
for
signatures.
That's
you
know
your
giving
all
these
labels
so
that
if
an
extension
wants
to
use
the
signature
key,
it
can
as
long
as
it
uses
a
different
label.
I
F
I
H
F
I
I
F
To
me,
I
mean,
first
of
all,
you
know
thanks
for
bringing
it
up.
I
think
it's
a
very
valid
point,
but
it
feels
like
we
have
a
chance
to
to.
You
know
fix
this
in
a
better
way,
because
if,
if
we
have
this
ambiguity
in
the
protocol,
maybe
now's
the
the
time
to
fix
that,
since
we
already
have
that
for
the
signatures
one
or
two
here,
this
might
not
be
the
last
extension
that
wants
to
reuse,
hpke,
keys.
G
We
should
still
fix
the
we
should
still
fix
the
problem
and
by
like
disavigating,
somehow
the
the
use
case
of
that
key
with
an
explicit
level.
It
doesn't
solve
that
problem
right
because
you
know
it's
an
Insider
attack
anyway,
but
the
I
think
it's
it's
worth
thinking
about
it,
at
least
because
we
could
make
sure
you
know
like
we
have
a
differentiator
for
mistakes
more
than
for
active
managers.
Insiders,
you
know,
like
some
external
protocol,
is
gonna
use
that
key
for
something.
G
H
I
think
your
suggestion
works,
it's
I
think
it
would
work,
it
could
be
made
to
work.
I
think
right
now,
the
only
time
we're
putting
in
a
label
in
the
extension
that
specifies
oh,
this
is
actually
a
targeted
message
that
goes
into
the
psk
derivation
part,
but
not
into
the
hpkey
I.
Think
you're
right.
If
we
put
in
more
context
that
specifies
the
purpose
of
the
ciphertext,
it
probably
would
address
the
problem.
G
It
no
I
mean
I
completely
agree
with
you
with
you
on
that
we
should
probably
use
different
Keys
I
mean
it's
more
storage
for
sure,
but
so,
let's,
let's
see
what
we
could
do
like
for
our
image
problem
is
to
add
this
label
thing
and
think
later
of
whether
we
want
to
allow
or
not
allow
the
ReUse
of
the
keys.
My
take
would
be
would
be
to
have
an
extension
and
I
have
a
different
key,
but
we
can
think
about
it
later
in
some
sense
like
this.
I
It
make
sense
to
say
in
the
protocol
that
in
the
protocol
document
that
the
key
should
not
or
must
not
be
reused
if
we
decide
that
it
shouldn't
be,
like
just
add
an
explicit
text,
because
we
so
at
least
I
always
assume
that
it's
not
reused,
it's
just
for
MLS
and
then
no
one
should
use
it
for
any
other.
Other
purpose.
H
Indeed,
and
the
analysis
take
that
into
account,
but
that
is
the
only
thing
like
the
analysis
works.
If
you
exactly
quantify
or
or
you
know
it
make
explicit
how
this
key
is
going
to
work
and
you're
right
that
it
does
get
used
for
different
update
secrets,
but
it
doesn't
get
used
for
something
completely
different.
H
So
I'm
saying
I
think
it
would
work,
but
if
we
open
the
door
to
people
allow
allowing
the
construction
of
extensions,
the
definition
of
extensions
that
use
this
hpke
key
forevermore,
we
will
have
to
worry
that
every
such
extension
actually
does
good
domain
separation
with
all
existing
applications
of
this
key,
because
otherwise
they
might
start
breaking
existing
applications
and
that's
the
door
we're
opening
here
and
so
for
this
extension,
it
could
work
you're
right.
We
could
make
it
work
without
introducing
a
new
key.
It's
just
that's!
That's
the
that's!
What
makes
me
uneasy!
C
Sorry
can
I
make
a
make
a
proposal.
I
think
I,
understand
your
concern
now
and
I
agree
that
there
should
be
like
a
clear
boundary,
because
between
protocol
and
extensions
and
yeah,
maybe
we
should
add
another
key.
One.
Alternative
approach
would
be
akin
to
the
signature
approach,
have
a
kind
of
encrypt
to
leave
key
function
that
must
be
used
if
you
want
to
encrypt
to
the
leaf
key,
even
by
extension,
so
extension,
so
that
you
cannot
use
the
key
directly.
C
C
H
F
The
thing
is
we,
we
probably
cannot
guarantee
absolutely
everything,
but
if
we
don't
do
anything
about
it,
then
there's
a
high
likelihood
that
people
will,
you
know,
come
to
existing
hpk
public
keys
without
any
guidance
whatsoever
and
then
effectively
damage
the
core
protocol.
Whereas
here
we
have
a
chance
to
give
as
much
guidances
as
humanly
possible.
H
The
reason
I
said
before
this
changes
the
interface
to
the
protocols,
because
up
till
now,
I've
always
thought
about
this
key
being
the
internal,
an
internal
secret
to
the
protocol.
State,
it's
like
you.
It's
like
saying
we're
gonna
pick
some
Secret
inside
TLS,
that's
at
some
point
in
the
key
schedule
and
start
doing
things
with
that.
The
TLs
never
considered
like
yeah
people
might
do
that.
But
that's
really
not
what
you're
supposed
to
do.
H
I
H
C
H
F
F
B
So
I
mean
it
sounded
to
me
like
and
I'm.
Clearly,
not
the
expert
here
like
either.
What
we
should
do
here
in
the
main
document
is
say
that
these
hpk
Keys
must
not
be
reused,
especially
in
the
leads
I
I
think
I'm
I'm
probably
inclined
to
play
whatever
the
provision
is
uniformly
to
the
leave
keys
or
the
intermediate
keys
either
they
must
not
be
used
or
we
need
to
have
some
sort
of
separator
of,
like
you
know,
encrypt
with
label
like
sign
with
label.
G
D
B
F
B
B
F
Okay,
it
sounds
like
we
have
consensus
on
on
that
part
for
the
MLS
protocol
and
then
it's
still
an
open
issue,
whether
we
use
new
keys
for
targeted
messages
or
we
we
have
another
input
like
I
mean
I,
clearly
understand
Jordan
martyr.
You
lean
towards
introducing
separate
keys
for
that,
but
for
the
sake
of
discussion,
that
is
then
a
separate,
open
issue
right.
F
H
No
sorry
that
wasn't
for
targeted
messages
that
was
just
a
another
extension.
We
had
an
idea.
We
wanted
to
I.
Guess
I
just
wanted
to
run
it
by
you
guys
by
everybody
to
just
know.
If,
if
there's
interest
in
this
or
not
in
a
nutshell,
it's
send
send
to
group,
but
from
external
and
the
core
ideas
exporter
key
use,
the
exported
key
to
derive
a
chem
key
pair.
That's
sort
of
a
group
chem
key
specifically
for
the
purpose
of
external
people,
will
want
to
send
application
messages
to
the
group.
H
F
I
F
B
A
E
E
A
That
and
at
some
point
we
have
to
be
like
all
right.
We
got
six
we're
done
like
We're
Not,
Gonna
Leave,
the
document
open
forever
right
at
some
point.
You
have
to
decide
all
right
now
we're
going
to
publish
so
that's
the
other
thing.
You'd
have
to
think
about.
I,
don't
know
so,
if
you're
to
your
point
about
the
varying
deployment,
deployability
or
deployment
status
of
the
various
extensions
I,
don't
know
if
that
matters
as
long
as
everybody
thinks
that
they're
not
affecting
security.
A
If,
if
there's
some
need
there
and
there's
like
two
or
more
people
that
are
willing
to
do
it,
then
maybe
we're
like
two
people,
then
maybe
we're
good
I
I,
don't
know
what
do
others
think
about
just
because
I
don't
want
this
just
to
be
a
bucket
where
everything
goes
right.
We
have
to
have
some
kind
of
like
you
know
litmus
test
for
like
why
something
got
in
here
and
like
is
there
general
interest
would
more
than
a
couple.
People
use
it
even
if
they're,
just
using
it
internally
in
their
own
implementations,.
H
I
I,
don't
know
it
well
enough,
I'm
not
familiar
enough
to
be
able
to
say
that
I
do
want
to
just
add,
though,
that
one
by
one
analysis
is
not
enough.
Any
kind
of
actual
security
analysis
will
always
have
to
be
with
exactly
the
set
of
extensions
that
are
all
being
used
at
the
same
time.
It's
not
enough
to
analyze
them
one
by
one.
They
have
to
be
analyzed
together
with
all
everything
else,
that's
getting
used
because
they're,
because
we
have
no
restrictions
on
what
an
extension
can
do
so
I
do
I
I.
G
So
I
have
a
more
general
question,
so
I'm
going
to
dive
out
slightly
but
I'm
going
to
go
back
to
the
content,
I
promise.
So
should
we
actually
use
the
document
to
exactly
and
show
what
you
said
like
to
like
have
one
document
where
we
have.
We
can
basically
socialize
the
main,
the
most
important
extension
for
functionality
that
don't
affect
the
security
of
the
Corp
protocol,
and
you
know
like.
G
G
Now
we
should
put
in
that
document.
I
don't
know
so
maybe
you
should
have
this
discussion
later
and
back
to
the
content.
Advertisements,
I
I,
don't
I,
don't
have
a
strong
opinion,
I
guess
I
would
say
Juan.
Do
you
think
we
need
to
change
that?
Always
how
much
do
you
think
we
should
change
the
document?
How
much
will
it
require
updates?
So
if
it's
something
that
is
you
know,
pretty
stable,
I
would
say,
I
would
I
think
it
would
be
fine
to
have
it
in
the
core
in
the
core
extension
document.
G
If
it's
something
that
we
want
to,
you
know
update
with
nfcbs
who
is
like
whatever
like
something
that
we
are
posted,
we
updates,
or
at
least
a
few
times,
maybe
that's
worth
having
its
own
document
that
we
can
refer
to
in
the
extensions
document.
I,
don't
know,
I,
don't
particularly
mind
right.
So
in
the
architectural
document
we
do
refer
to
the
external
graph
funnel.
So
do
you
think
it?
You
know
it
will
change
much
or
do
you
anticipate
something
like
this.
E
E
A
A
E
No
I
mean
the
Mimi
Charter,
which
was
reviewed
on,
which
was
reviewed
yesterday.
I
think
it's
I
think
they're
ready
to
send
it
off
to
ITF.
For,
for
you
know
the
two
week
review
or
whatever,
but
the
the
the
there.
It
says
specifically
in
the
charter
that
no
MLS
extensions
will
be
done
in
Mimi,
like
MLS
extensions
will
be
done
in
MLS.
E
E
So
the
the
main
open
issue,
which
can
be
done
and
can
be
done
separately,
is
do
we
have
a
way
to
do
the
equivalent
of
multi-part
multi-part
alternative
that
people
like
and
so
the
appendix,
which
was
the
one.
You
know.
One
of
the
major
changes
in
this
in
this
document
from
the
last
version
is
a
TLS
presentation.
Language
sort
of
you
know
Syntax
for
effective
for
the
same
semantics,
almost
the
same
semantics
as
multi-part
alternative
that
just
doesn't
rely
on
having
to
use
boundary
markers
it
uses.
You
know,
sizes.
E
So
if
you
want
I
mean
I
like
it
might
be
easier
to
look
at
the
document,
it
formatted
in
the
the
Standalone
document,
which
I'm
pasting
a
link
into
the
chat.
But
you
know
right
now:
I
can
go
and
send
an
HTTP
message.
An
HTTP
post
or
get
with
with
two
different
formats
and
I
can
and
I
can
enclose
them
in
a
multi-part
alternative,
and
you
know
the
the
semantics
of
that
is
clear.
E
F
Thank
you
so
how
about
the
following
compromise?
We
get
this
started
in
the
extensions
document
which
I
think
is
going
to
be
left
open
for
a
while
anyway,
because
we
need
people
to
give
a
chance
to
add
more
things
as
they
integrate
MLS
into
their
applications
and
realize
something
is
missing
and
after
a
while,
then
you
would
have
a
better
feeling
Ron
if
that's
really
finalized
or
not,
and
if
there's
a
chance
it's
not,
then
you
can
always
make
it
a
separate
document.
G
Actually,
what
you
said
that
makes
me
think
we
should
do
the
reverse,
because,
like
you
know,
we
have
the
core
protocol
now
and
the
ex
the
the
you
know,
Juan's
in
the
craft
could
be
done
no,
basically
right,
so
people
could
already
use
that.
That's
also
like
having
it
in
the
in
the
extension
document
actually
forces
us
to
wait,
which
is
not,
is
a
super
great,
so
so
I'm
like
ping-ponging
between
the
two
positions
but.
A
E
D
E
With
you
know,
after
protocol
and
after
protocol
and
architecture
and
Federation,
you
know
maybe
like
at
the
same
time
as
Federation
or
something
right
and
it's
something
that
will
be
there'll,
be
a
dependency
in
Mimi.
It's
also
referenced
in
architecture
that
can
be
if
that
changes
that
can
be
fixed
in
in
our
in
in
auth
48,
but
it's
sort
of
nicer.
If
it's
already,
you
know
if
it's
already
a
stable
reference.
If
you
know
that
that's
the
reference
it's
going
to
be.
G
I
F
G
G
I'm,
like
I'm,
largely
thinking
that
we
should
have
the
extension
document.
That
basically
says
here
is
what
you
can
a
guidance
for
all
the
other
extensions
saying.
You
know
this
thing,
you
cannot
touch,
because
if
you
touch
it
that
involves
security.
That
thing
you
can
do
whatever
you
want,
but
but.
G
You
know
in
some
sense
in
that
document
things
should
be
in
my
mind,
it
should
be
yeah.
It
should
be
like
thing
that
everyone
will
use
basically,
so
if
we
have
good
use
cases
for
that,
we
should
put
them
in
there,
but
if
we
don't
have
good
good
cases
for
that,
we
should
just
like
you
know,
be
a
guidance
document
and
have
separate
documents
for
the
for
those
things
that
people
will
use.
Sometimes.
F
G
A
The
other
idea
is
that
we
just
go
all
right.
We
got
three,
we
think
these
are
good,
we've
actually
got.
We
got
some
general
consensus
to
ship
these
things,
do
it
and
then
yeah
other
ones
come
along,
they
can
get
added
and
you
can
update
this
document
or
you
know
whatever
to
to
add
them
in
is
the
you
know
the
core
extension
so
to
speak.
A
So
there's
there's
multiple
ways
to
handle
this
I'm.
Just
kind
of
the
sense
is
if
we
have
like
a
couple
that
are
good,
that's
great.
We
don't
necessarily
have
to
stay
open
like
leave.
The
document
open
for
others
to
get
added.
I
do
feel
Raphael's
point
about
as
this
stuff
as
MLS
gets
integrated
more
into
applications,
they're
going
to
be
people
showing
up
being
like
we
need
this
and
it
could
be
broadly
applicable.
The
question
is:
how
long
would
we
wait,
and
maybe
we
don't?
Maybe
we
don't
need
to
wait
that
long.
A
Yeah
I
mean
like
I,
mean
like
again,
because
it's
like
you
know
how
long
do
you
wait
and
it's
it's
going
to
cause
problems
because
Rowan
needs
this
and
the
Mimi
people
are
going
to
be
beaten
down
like.
Why
are
we
waiting
for
those
guys
you
know
like?
So
if
we
can
solve
some
problems?
Maybe
we
just
merge
this.
Maybe
we
merge
this
content,
one
in
and
just
be
like
all
right.
You
know
how
do
people
feel
about
just
progressing
it
with
the
the
few
that
we
have
now.
A
F
E
A
Group
I
think
maybe
what
Raphael's
getting
at
is
Mimi's
not
going
to
be
done,
quick
right.
So
the
idea,
like
I,
think
you
can
get
down
the
like.
If
you
want
to
do
the
use
case,
requirements
thing
like
you,
could
throw
out
the
use
case
document
pretty
quickly
like
get
it
through
the
door
and
get
it
published,
but
like
the
actual
protocol,
spec
is
probably
not
going
to
happen
in
a
year
right.
It's
going
to
take
a
bit
unless
you've
got
magic,
pixie
dust
that
I
don't
know
about
Rowan,
it's
gonna
take
a
while.
A
A
Do
I
do
resonate
a
little
bit
with
his
statements
about
you
need
to
kind
of
put
guard
rails
and
security
considerations
in
about
each
one
of
the
extensions
and
I'm
good
to
see
I'm
glad
to
see
you
did
that
rolling
with
yours
right
away,
and
then
motherhood
and
apple
pie
in
the
beginning.
Part
of
the
document
is
needed
as
well,
but
I'll
be
honest.
I
haven't
read
it
in
like
in
a
little
while
so
okay.
E
What
one
last
thing
that
I
just
wanted
to
mention:
it's
just
that
in
terms
of
a
structure,
the
extensions
document
it
has
security
considerations
underneath
targeted
messages,
but
I
think
that
there
should
be
a
Securities
consideration
section
that
has
subsections
that
talk
about
the
individual
extensions
security
considerations.
Yeah.
A
E
A
F
F
G
G
I
think
we'll
have
I'm
not
sure
where
to
put
the
Privacy
thing,
those
the
way
I
see
it.
We
left
the
delivery
like
the
the
authentication,
Service
and
the
delivery
service.
We
actually
made
them
pretty
abstract,
even
in
the
architecture
documents
so
that
you
know
we
can
have
different
variations
about
those,
but
we
need
at
some
point
to
speak
about,
like
the
state
of
the
art
of
of
or
do
you
make
delivery
service
private
or
how
do
you
make
it.
G
Authentication
Service
private,
especially
in
the
context
of
federation,
because
in
the
in
the
Federation
case,
basically,
you
know
you
need
to
transfer
some
information
about
about.
You
know
the
users
that,
under
your
umbrella,
to
the
others,
to
and
talk
to
the
other
to
the
other
users
that
are
in
a
different
envelope
so
like
what
do
each
system
do
and
basically
there
there
is
like
a
very
big
privacy
Gap
that
we
didn't
solve
anywhere.
G
F
Yeah
I
think
you
bring
up
a
good
point
because,
as
you
said
in
the
architecture
document,
we
were
very
vague
on
purpose,
but
then
with
Mimi.
We
want
to
be
very
concrete
on
purpose.
Otherwise
we
don't
get
interrupt
so
yeah.
We
could
definitely
extend
the
Federation
document
in
that
sense,
to
talk
about
MLS,
specific
things
and
be
much
more
concrete
than
we
are
in
the
architecture
document
I
mean
there
is
some
start
for
the
delivery
service
that
is
not
fleshed
out
at
all.
G
So
my
intuition
is
that
we
actually
need
another
document
which
should
be
like
you
know.
Here
is
the
best
thing
that
you
can
actually
achieve,
and
here
are
the
secretion
privacy
goes
for
that
thing
and
then
on
the
Federation
document
you
say,
oh
by
the
way,
you
need
to
relax
that
spot,
that
particular
poverty
because
for
Federation
you
are,
you
know
interacting
with
another
device
or
another
authentication
Service,
that's
my
intuition,
but.
F
I
mean
I
I
agree
with
the
idea.
The
thing
is,
the
most
privacy
programs
are
to
be
expected
with
the
delivery
service,
not
so
much
with
the
authentication
Service,
and
so
what
you
just
described
ideally
will
be
in
the
Mimi
delivery
service
document
as
well.
It's
not
there!
Yet
it's
just.
You
know
alluding
to
that.
It
needs
to
be
fleshed
out.
F
Obviously,
but
since
that
document
describes
how
a
privacy
preserving
delivery
service
can
work,
we
need
a
lot
of
meat
in
there
anyway,
with
security
concerns
and
and
privacy
considerations
and
whatnot,
and
for
the
stuff
that
we
cannot
have
in
there.
We
could
still
have
that
in
the
Federation
document,
but
now
we're
talking
more
about
the
Mimi
document
and
about
the
the
MLS
document.
G
G
F
G
Would
say
you
know
this
property,
you
got
all
it
because
you
need
that
functionality
basically,
and
you
know
so
here,
is
how
you
do
it
in
the
context
of
interoperable
things
or
Federation,
or
you
know,
but
like
the
strongest
thing
is
really
related.
Is
like
unrelated
to
me
really
it's
like
about.
Oh,
you
actually
implement
the
delivery
service.
Implement,
like
you
know,
we
do
design
a
deliverable
service,
so
I
think
that
should
be
in
the
EMS
working
group,
but.
F
G
G
G
F
F
F
F
G
So
is
there
something
that's
for
sure
not
going
to
be
covered
by
Mimi
is
the
Federation
of,
like
you
know,
in
Mimi.
Typically,
the
authentication
services
are
from
different
providers,
which
is
not
the
case
from
the
Federation
from
the
base
case.
Federation
document
so
I
think
it's
yeah,
it's
not
clear.
Well,
we
should
do
that.
A
G
A
To
get
the
information
written
down
and
if
we
gotta
rip
it
out
later,
we
do
that.
That's
that's!
That
might
be
better
because
we
have
this
document
and,
if
you're
willing
to
write
the
text,
it
helps
right,
as
opposed
to
like
hey
Raphael,
go
off
and
think
about
this
and
write
a
bunch
of
text
and
stick
in
the
documentaries.
A
A
A
And
hopefully,
we'll
be
wrapping
up.
My
hope
is
that
if
we
get
done
with
an
ITF
last
call
and
directorates
Richard
and
Benjamin,
if
you
guys,
are
like
kind
of
not
going
to
disappear
for
like
January,
we
ought
to
be
able
to
get
through
the
comments
that
we'll
receive
anything.
That's
discussed
worthy,
that's
where,
like
it's,
it's
better
to
get
on
it
early
than
it
is
to
let
it
Fester,
because
the
ads
will
lose
State
and
they
will
not
remember
what
they
said.
A
A
If
we
can,
you
know,
respond
as
quickly
as
possible
because
that
that
Smooths,
the
process
of
getting
through
the
through
the
process
better
like
if
you
let
it
faster
and
it
takes
six
months-
they're,
not
gonna,
remember
what
they
said
and
they're
going
to
re-review
the
document,
and
it's
just
going
to
be
more
painful,
so
but
I'm
I'm,
looking
forward
to
the
possibility
of
wrapping
this
up
in
the
first
quarter.
Actually
getting
numbers
assigned
to
these
rfcs
in
the
first
quarter,
2023
be
nice.
E
A
All
right,
thank
you
very
much
Richard
when
you
have
a
chance
shoot
me,
your
notes,
Conrad
I,
see
that
you
were
going
to
send
me
some
notes.
I
think
you
could
see
some
stuff
that
I
couldn't,
which
was
weird
but
I'll,
get
those
uploaded
and
again,
thank
you.
We'll
see
you
next
time
have
a
safe
and
happy
set
of
holidays
whatever
it
is
that
you
celebrate.