►
From YouTube: IETF-MLS-20221208-1500
Description
MLS meeting session at IETF
2022/12/08 1500
https://datatracker.ietf.org/meeting//proceedings/
A
Hello.
Welcome
to
those
who
showed
up
on
time.
We're
gonna
give
people
a
couple
minutes
to
dial
in
it's.
Usually
we
start
a
little
bit
later
book
five
after
so
thanks.
A
A
Yes,
fine,
the
one
thing
to
note,
usually
in
meat,
Echo,
there's
a
bit
of
a
delay.
So
when
you
click
the
button,
you
know
wait
a
second
or
two
before
talking
before
start
talking,
because
there's
there's
just
a
delay.
A
We
we
do
need
a
minute
taker
oftentimes.
We
stick
Richard
with
this,
but
we'll
see
he's
not
here
yet
so
start
thinking
about
volunteering,
because
I
gotta
I'll
probably
be
running.
The
show
here,
it'll
be
pretty
hard
for
me
to
take
notes.
You'll.
Do
it
run
great
there's?
Actually,
no
he's
just
saying
hello.
A
If
you
know
that
there's
a
there's
a
button
in
the
upper
right,
which
is
a
note
taking
tool,
you
can
take
it
there
as
well
and
then
others
can
join
and
try
to
help.
Oh.
C
E
Richard
you're
looking
a
little
a
little
sleepy
there,
how
you
doing.
D
A
To
try
to
impose
the
we're
not
going
to
try
to
impose
the
mic
line
and
all
that
stuff
here,
so
people
can
feel
free
to
jump
in
and
just
you
kind
of
use
your
mute.
You
know
mute
locally
as
best
as
possible.
D
A
All
right,
well,
maybe
we're
close
enough
to
the
I,
see
that
most
of
the
usual
suspects
are
here.
That's
great!
Thank
you
for
coming
to
the
MLS
interim
meeting
in
December.
This
is
an
official
meeting,
so
I
need
to
show
the
note.
Well,
you
know
this
not
have
much
of
a
problem
with
this,
but
a
lot
of
this
is
about
IPR
and
policy
and
conduct
IPR.
A
If
you
know
something,
you
need
to
submit
something
as
it
turns
out,
I
guess:
I'm,
the
one
person
that
submitted
a
third-party
IPR
statement
we
checked
actually
through
the
iitf
last
call
Process
whether
anybody
thought
that
the
third
party
IPR
would
causes
problems
that
we'd
have
to
work
around
it.
We
didn't
get
any
any
any
input
on
that
and
that
was
okay,
so
I
filled
that
out
in
the
you
know,
the
write-up
that
we
have
to
give
to
the.
A
Of
the
process
and
it's
it's
off
and
running
so
I
think
we're
pretty
good
getting
to
there.
The
next
part
is
the
wrong
way
come
on.
These
are
old,
slides,
so
don't
actually
the
whole
code
of
conduct
thing.
Luckily,
this
group
doesn't
have
any
of
these
problems
so
I'm
just
throwing
it
up
here
for
the
recording.
A
Basically,
you
know
should
treat
everybody
with
respect.
Try
to
speak
slowly,
I
feel
like
this
one
is
that
one
was
aimed
at
me.
You
should
dispute
ideas
by
using
reason
to
argument
you
know,
use
your
best
engineering
judgment
find
the
best
solution
for
the
whole,
the
internet
contribute
to
the
ongoing
work.
The
ITF-
and
you
know
basically
do
both
of
these.
You
know
here,
I
guess.
A
The
kind
of
plan
here
was
to
kind
of
go
through
the
protocol
and
architecture
document
as
best
we
could,
as
well
as
the
extension
document.
My
my
understanding
is
that
we
should
probably
start
with
the
protocol
document
because
I
there
was
a
flurry
of
activity
in
the
last
week
and
a
half
or
so,
and
so
Pastor
Richard,
to
kind
of
tell
me
where
to
go.
D
A
D
About
it
or
after
ad
review
before
last
call
yeah.
A
So
I
guess
that'll
work
here.
So
basically
the
idea
is
that
you
know
to
get
through
the
process
like
the
working
group
does
its
thing
and
then
to
leave
the
working
group.
The
chairs
basically
give
it
a
review
and
kind
of
like
okay,
we're
good,
and
then
we
pass
it
off
to
the
area.
A
Look
some
respects
unless
they've
been
actively
involved
and
they
haven't
and
so
Paul's,
given
a
bunch
of
comments,
I
guess
on
the
architecture
drop,
but
we
don't
haven't
seen
his
protocol
comments
yet
right,
yeah.
D
That's
the
reason
for
the
flurry
of
activity
on
the
protocol
documents
to.
A
I
was
gonna
say
that,
basically,
these
are
comments
you
kind
of
have
to
deal
with
because
he's
the
one
that
personally
has
to
put
it
and
like
press
the
buttons
and
make
it
go
forward.
So
we
kind
of
have
to
answer
and
it's
a
back
and
forth
and
if
any
of
the
major
changes
any
any
big
changes
happen
that
we
think
are
big
enough
to
go
back
to
the
working
group.
We
basically
redo
a
working
group
last
call
and
then
so.
We
would
like
kind
of
bounce
back
here
to
the
working
group.
A
The
working
group
last
call
and
then
there's
no
real
Ada
review
just
kind
of
goes
into
the
next
step,
and
so
luckily
you
all
being
here
will
help
Grease
the
skids
so
to
speak.
If
we
have
to,
if
we
end
up
having
to
do
another
working
group
last
call
at
least
we'll
kind
of
have
consensus
among
this
group
to
proceed
forward,
and
then
we
go
off
so
they'll
do
an
ITF
last
call
after
hopefully,
after
this
it's
two
weeks
and
then
it
goes
on.
A
What's
called
the
ISD
review,
which
is
where
they
put
it
on
the
telechat
and
then
all
the
other
area
directors
from
the
other
areas.
We'll
look
at
the
draft,
and
so
they
kind
of
look
at
it
with
their
particular
lens,
like
transport
or
the
int
area,
or
you
know
like
that
happens,
and
then
a
bunch
of
directorates
start
looking
at
it.
So
like
the
DNS
director
will
look
at
it
for
DNS
impacts.
The
security
review
will
happen
where
another
independent
person
will
get
we'll
get
to
review.
A
That's
just
kind
of
the
whole
process,
so
I'm
cautiously
optimistic
that
if
we
get
through
here
and
don't
have
any
major
changes
to
either
one
of
the
documents
you
know
we
could
maybe
get
a
last
call
going
to
be
in
the
beginning
of
the
new
year,
with
the
with
the
holiday
season
coming
up,
I
just
I'm,
not
confident
that
Paul's
gonna
press
the
buttons
and
like
they're,
not
gonna
like
have
a
working
or
an
ITF
last
call
that
ends
like
in
you
know,
late
December
and
then
slapping
on
the
telechat.
A
D
Here
was
to
get
most
of
the
most
everything
sorted
on
the
protocol
document.
At
least
Benjamin
says:
he'll
need
a
couple
more
days
on
the
architecture
document,
but
I
think
we
can
probably
get
the
protocol
document
mostly
sorted
today,
and
there
may
be
a
couple
things
that
need
another
day
or
two
of
discussion,
but
yeah
I
think
we
could.
Hopefully
we
can
drop
into
last
call.
Intf
last
call
pretty
soon.
A
Here
well,
that'd
be
great
and
then
so
the
deal
is
after
it
goes
through
ISU
review,
that's
where
it
gets
approved,
but
then
it
goes
into
this
other
process
where
the
RFC
editor
takes
over
and
that
just
takes
depends
on
how
how
many
documents
are
in
front
of
this
and
whether
we're
part
of
a
queue
I
think
this
one
actually
is
Standalone
and
won't
be
pointing
to
anything
else,
and
so
it
just
takes
like
an
actual
like
month
month
and
a
half
two
months
to
actually
get
a
number
and
pop
out
the
door.
A
So
I
mean
I'm,
hoping
if,
if
the
timeline
is
right
and
we
actually
started
at
intf
last
call
like
say
next
week
before
iatf
116,
we
should
be
out
the
door
with
a
number
yeah.
That's
what
I'm
hoping
for
so
that
that'd
be
great.
So
all
right,
I
will
bounce
back
over
to
the
repo
we
will
drop
into
the
protocol.
D
D
So
the
first
two
here
are
so
we've
got
a
couple
here
that
we're
going
to
consider
together
so
751
and
752
go
together,
so
this
one
adds
the
epoch
in
which
a
leaf
was
changed
to
the
leaf
and
752
removes
unmerged
leaves
because
you
can
compute
the
unmerged
leaves
based
on
the
epochs.
D
You
may
have
seen
some
list
traffic
mailing
list
traffic
on
this
yesterday
between
Taylor
field
and
I.
Basically,
this
you
know
it
gives
you
a
little
bit
more
rigidity
in
things.
You
know
you
have
some
cross
check
to
make
sure
the
path
Ash
chaining
is,
is
going
correctly
at
the
cost
of
a
little
bit
more
complexity
and
as
as
Joel
points
out
in
that
comment,
there
a
little
bit
more
information
revealed
to
the
DS.
D
If
you
know
the
DS
is
storing
the
tree,
as
I
said
on
the
mailing
lists
yesterday,
I
think
my
inclination
here
is
to
just
close
these
and
be
you
know
largely
because
this
can
be
done
in
a
clean
extension
pretty
cleanly
in
an
extension,
so
I
think
the
action
I
would
propose
on
these
is
to
close
these
PRS
on
the
base.
Spec
and
I'll
look
at
doing
some
work
in
the
extensions
documents
to
add
this,
because
I
think
this.
D
This
will
be
helpful
for
decentralized
MLS
cases
where
you
need
to
to
know.
You
know,
which
was
the
latest
updated
version
of
a
leaf,
but
I
don't
think
it
doesn't
seem
critical
for
for
the
base
spec
and
it's
it's
a
pretty
non-trivial
change
field.
Did
you
did
you
want
to
stand
up
and
say
we
really
need
to
do
this
in
the
in
the
base.
Spec.
G
Obviously,
Alexis
changed
but
I
mean
I.
I
can
live
without
it,
so
I
think
I'm,
fine,
just
tracing
them
and
do
it
in
an
extension.
H
I
have
a
question
actually
for
those
who
are
working
on
implementing
various
DS
How
likely.
Is
it
in
the
current
yes,
implementations
that
this
type
of
metadata
is
being
tracked
Anyway
by
the
DS,
because
it's
great
to
minimize,
but
it's
something.
I
C
Yeah,
it
depends
a
little
bit
so
assuming
that
you
have
what
you
think
we
are
now
going
to
call
public
messages,
formerly
known
as
the
the
DS
can
be
tracked,
that
if
it
wants
to
normally
it's
not
terribly
useful
in
the
sense
that
the
only
thing
so
far
that
that
we've
been
thinking
of
is
that
a
DS
Knight
flag
members
that
haven't
done
an
update
in
a
while
and
therefore
might
be
a
risk,
strictly
speaking,
that's
more
of
a
timestamp
than
a
precise
Epoch
number.
C
C
We
discussed
that
very
early
on
I
think
I
can't
2019
if
I
remember
correctly,
with
Benjamin,
and
so
one
of
the
downsides
of
having
that
metadata
persisted
is
porn
attacker.
Who
can
look
at
the
public
tree
it?
This
gives
an
indication
to
the
attacker
what
the
juiciest
Target
would
be
to
compromise,
and
the
juices
targets
is
one
of
the
oldest
Epoch
number,
because
if
you
compromise
that
one,
that's
where
you
you
would
have
the
biggest
windows
other
than
that
in
in
terms
of
privacy.
I,
don't
think
this
is
particularly
sensitive
metadata.
H
C
Going
to
be
a
timestamp,
because
we
we
don't
know
how
often
epics
would
rotate
it
can
rotate
very
quickly
in
a
short
amount
of
time,
or
it
can
take
days
almost
depending
on
the
original
group
activity
and
policy.
So
it's
it's
probably
less
meaningful
than
timestamps
to
understand
how
big
a
window
of
compromise
is.
E
I'll
give
a
short
version
from
from
our
perspective,
which
is
that
we
have
we're
we're
assuming
plain
text:
MLS
plain
text
handshakes,
and
so
we
could
store
this
information.
But
we
don't.
You
know
it's
not
particularly
useful,
there's
a
lot
of
other
metadata
that
we
have.
That
is
more
useful,
so
it
we,
we
already
have
basically
more
useful
information
that
could
be
used
for
more
more
attacks
than
this
because
we're
using
from
less
plain
text.
J
The
data
that
we
are
now
adding
is
actually
signed
by
the
participants,
so
whatever
the
DS
is
collecting
is
not
going
to
be
signed,
so
I
mean
at
least
he
can't
convince
someone
else
right.
D
Just
just
for
completeness
WebEx
does
not
track
any
of
this
stuff.
We
do
use
and
unencrypted
commits
so
that
the
server
can
help
distribute
the
tree,
but
we
don't
track
the
we
don't
keep
around
any
data,
so
yeah
I
think
the
Privacy
benefit.
Pluses
and
minuses
here
are,
are
not
huge,
I'm
more
a
little
bit
more
concerned
about
the
complexity
of
implementation
and
and
the
kind
of
bigness
of
change
at
this
stage,
which
I'm
inclined
to
cannot
say,
call
again
that
it
can
be
done
pretty
cleanly
in
an
extension.
D
So
unless
someone
thinks
it's
really
important
to
have
this,
this
information,
which
it
doesn't
really
sound
like
I,
think
we
should
go
ahead
and
close.
This.
D
A
Pretty
he
pretty,
you
took
the
words
right
out
of
my
mouth.
That's
I
think
an
excellent
point
in
the
fact
that
via
file
is,
you
know
going
in
the
grand
Spirit
of
consensus,
which
is,
it
can
be
done
later
and
that'll
work.
Let's,
let's
go
ahead
and
go
with
that.
A
So
thanks,
so
Richard
I'll.
Let
you
take
care
of
closing
the
stuff
out.
D
Already
yeah
I
can
push
the
button.
Sure
Raphael
note
that
this
is
one
more
for
the
extensions
document.
All
right,
I
think
the
next
one
is
754.
D
So
I
forget
who
raised
this
issue.
Someone
noted
that
technically
you
don't
really
need
to
send
you
know
so.
The
spec
before
says
when
you
make
a
commit,
you
make
one
commit
message
and
one
welcome
message
that
goes
to
all
of
the
new
joiners
and
segment
that
doesn't
need
to
be
the
case
you
could
make
anywhere
between
one
and
end.
Welcome
messages
or
n
is
the
number
of
new
joiners
I.
Guess
you
can
make
more,
but
that
wouldn't
be
very
useful.
D
So
this
PR
just
encodes
that
and
basically
changes
all
the
instances
where
it
says,
make
a
single
welcome
message
to
say
make
as
many
welcome
messages
as
you
want.
As
long
as
you
cover
all
the
new
joiners.
C
I
think
it's
a
useful
addition.
The
the
only
thing
I
was
wondering
about
was
in
the
motivation,
for
it.
I
think
she
would
mentioned
that
for
larger
groups,
where
it
comes
can
be.
Hundreds
of
kilowatts
and
I
was
wondering
how
large
exactly
those
groups
are,
because
it
seemed
fairly
large
for
a
welcome
unless
you
go
to
the
hundreds
of
thousands
or
tens
of
thousands
of
members,
but
I
didn't
properly
calculate
it
so
I
totally
wrong.
D
Oh
I,
actually
just
to
give
you
some
like
real
world
numbers.
You
know
we,
we
run
MLS
groups
pretty
regularly
in
WebEx
of
up
hundreds
of
members
and
because
we
had
certificates
in
the
in
the
tree.
They
get
very
large
very
quickly.
D
That's
true
yeah.
If
you
were
right,
if
you
were
Distributing
the
tree
in
the
welcome
message,
it
would
get
big,
but
that's
correct.
If
you
have
an
off-board
tree,
then
it's
not
clear
that
a
welcome
would
be
super
huge.
D
It
actually
occurred
to
me
that
there's
a
bit
there
may
be
a
bit
of
a
privacy
motivation
for
this
in
that
well,
I
yeah,
we'll
skip
that
thought,
because
I
have
some
further
out
thoughts
on
that
foreign.
F
I
was
the
one
who
raised
the
issue
and
the
reason
I
ran
across
it
was
I
was
running.
Some
performance
tests
on
MLS
and
I
was
I
was
adding
several
thousand
users
to
a
group
at
the
same
time,
so
that
that
was
the
type
that
was
the
size
of
groups
that
I
was
looking
at.
F
So
it's
not
necessarily
something
that
might
happen
in
sort
of
normal
use
cases,
but
yeah.
It
was
just
something
I
ran
into
when
I
was
doing
performance,
testing.
C
F
C
D
Well,
you're
gonna
public
key
I've
ever
had
for
each
Niche,
Joiner
and
actually
you're
going
to
encrypt
the
past
Secrets.
Let's
say
you've
got
you
know,
64
bytes
or
so
for
each
Joiner.
We.
E
Had
we
had
314,
we
had
314
bytes
per
per
member.
C
B
D
Well,
I
mean
that
just
implies
the
the
speed
at
which
these
things
get
big.
So
if
you're
using
post,
Quantum
public
Keys,
then
you'll
have
bigger
bigger,
welcome
messages
because
you're
doing
public
key
encryption,
although
I
you
won't
have
public
keys
and
you'll
have
encapsulated
keys
and
I,
don't
remember
how
those
how
big
those
get
those.
C
Also
grow
so
the
the
chem
grows,
but
there's
only
one
camper
participant,
but
the
the
past
secrets,
for
example,
don't
grow
bigger
in
that
case,
so
it
literally
just
for
camps
so
yeah.
It's
the
linear
growth,
that's
proportional
to
the
size
of
a
cam
which
typically
is
going
to
be
I.
Don't
know
hundreds
of
bytes,
probably
100,
kilobytes
I'm,
not
sure
what
fiber
does,
though,.
E
It's
about
6K
per
per
per
participant
for
kyber,
if
I.
If
memory
serves.
B
H
D
D
I,
don't
this
actually
changed
the
processing
of
well
messages?
You
know,
as
someone
is
you
know,
a
sender
of
a
commit
is
free
to
make
one
just
as
before.
It
just
adds
the
option
to
produce
multiples.
A
Yeah
I
think
we're
gonna
go
with
that.
If
people
were
really
going
to
object,
I
think
they'd
be
throwing
Flags.
So
let's
go
ahead
and
get
this
one
merged.
D
Okay,
now
I'll
push
the
button
on
that
and
I
think
the
next
is
going
to
be
755
and
756
together,
Franciscus
and
I
believe
Brendan.
Both
noticed
that
we
talk
about
basic
credentials
as
if
they
contain
keys,
and
they
no
longer
do
so.
I
think
the
right
ones
emerge
here
is
756
I'm
going
to
scroll
in
that
one.
E
Basic
in
in
quotes
is
still
in
Indiana
registry,
and
so
the
the
language
in
in
756
is
that's
still
consistent
with
what's
in
the
document
right,
but
the.
But
there
are
references
to
basic
in
the
grammar
and
in
the
Ina
registry
I,
don't
for
755.
E
E
I
Yeah
I
was
just
gonna
say
that
755
I,
don't
think
that
we
need
it,
because
it's
trying
to
add
a
binding
between
the
basic
credential
ID
and
the
signature
key,
which
is
not
something
that
we're
trying
to
go
for.
D
D
So
756
just
changes
based
the
phrase
basic
credential
to
basic
in
quotes.
Credential.
B
So
the
only
note
that
I
had
with
this
was
that,
if
the
credential,
the
basic
credential
essentially
just,
doesn't
really
contain
anything,
what
does
it
mean
for
like
the
as
validates
the
credential
yeah
like
we?
We
assume
that
the
as
somehow
validates
The
Binding
between
the
key
and
whatever
else
is
in
the
identity
right.
So
it's
pretty
meaningless
to
have
as
validation
on
something
where
there's
nothing
like
the
public
key
is
not
in
there.
E
So
Conrad
I
think
one
way
of
looking
at
this
is,
if
you
have,
if,
if
you
had
an
implementation,
where
there
was
some
type
of
linkage
between
the
DS
and
the
as
it
would
be,
you
could
you
could
enforce.
You
know,
to
the
extent
that
you
can
do
anything
with
a
basic
credential,
you
could
the
the
as
could
ask
the
DS
to
you
know
only
only
pass
a
past,
something
that
contained
an
expected
value
in
the
in
the
identity
string
of
a
basic
credential,
I
bet
I,
don't
think
it's
that
I.
E
Don't
think
it's
that
important
I
mean
I.
Think
that
I
I
think
that
what
the
the
text
in
756
is
fine
and
it
like
to
the
extent
that
we
accept
that
there
may
that
there
might
that
somebody
might
use
basic
credential
I.
Think
that
it's
just
you
know
it.
We
have
put
as
much
text
around
it
as
we
can
for
a
thing
that
was
designed
to
to
be
the
the
thing
that
you
use
for
testing
and
for
sort
of
you
know.
Private
implementations.
B
E
B
D
I
so
I.
D
Conrad
I
think
we
might
need
to
clarify
this
yeah,
maybe
in
the
kind
of
credential
validation
section,
to
make
clear
so
what
we
I
think
this.
This
came
up.
We
ended
up
in
this
situation
because
we've
made
this
change
a
little
while
to
go
to
pull
the
signature
key
out
of
the
credential
so
that
you
always
have
it
and
you
can
always
process
with
it.
D
B
Sure
so.
E
Conrad
there
there
was
there's
some
text
for
just
discussing
basic
credential
and
why
you
shouldn't
use
basic
credential.
If
you
care
in
the
architecture
document
that
I
added.
E
May
be
that
it
may
actually
be
that
this
isn't
one
of
the
PRS
that
has
been
languishing
for
the
last
since
August.
Here.
E
Okay,
I'm,
looking
in
the
I'm
looking
in
the
pr
that
I
the
PRS
that
I
submitted
here.
H
I
And
I'm
also
looking
in
the
protocol
spec
in
section
five
three,
we
say
that
this
credential
doesn't
protect
the
public
key
and
for
x700
credential.
We
say
that
they
do
have
to
be
bound,
so
there
is
text
in
the
protocol
document
that
protects
that.
E
We
don't
have
a,
we,
don't,
have
a
text
chat
in
medeco
right.
D
B
Okay,
okay,
I
mean
I,
can
take
a
look
at
the
architect
document
and
Brendan.
Thank
you
for
the
the
pointer
I'll
look
at
the
spec
as
well
again
and
then
report
back
in
the
pr
does
that
work,
or
do
we
really
want
to
merge
it
right
now.
D
D
J
Yeah
I
actually
thought
it
was
I
see,
I
have
a
different
solution,
so
this
kind
of
way
of
the
Joiner
Computing,
the
interim
transcriptase
or
the
confirmed
transcriptase
for
the
from
the
interim
transcript
transcript
hash
and
the
confirmation
tag
in
the
group
info.
This
doesn't
work
in
the
first
Epoch.
J
So
when
you
want
to
externally
join
to
the
first
Epoch,
this
kind
of
algorithm
doesn't
make
sense,
because
there
is
no
confirmation
type
from
the
old
book,
and
currently
we
say
that
in
the
first
book
the
interim
hash
is
is
empty
and
so
yeah.
One
way
to
do
this
is
to
say
that,
which
is
what
I
did
here
is
to
say
that
in
the
first
Epoch
the
the
Joiner
just
takes
an
empty
hash,
but
yeah.
So
so
that
that's
that's!
That's
a
that
one
I
don't
know
any
any
thoughts
about
that.
J
J
Work
for
the
for
the
Creator.
It
is
not
right.
D
C
J
J
D
Yeah
I'm
worried
we
have
an
interop
problem.
If
there's
ambiguity
about
how
the
first,
you
know
how
Epoch
ones
Epoch
secret
is
computed
right
because
that's
going
to
include
the
outputs,
the
the
same
outputs.
You
should
go
through
here
right,
because
it's
also
a
commit.
J
D
Well,
isn't
the
epoch
secret
computed
based
including
the
transcript
hash
and
so.
J
E
E
Yeah
so
I,
both
both
Marta
and
Richard,
proposed
a
concrete
way
to
do
this.
We
need
to
pick
one
and
document
that,
whether
whichever
one
we
do,
we
need
to
document
what.
H
J
J
So,
for
example,
it
says
there
is
a
transcript
touch
but
doesn't
say
like
set
it
to
or
there
is
a
confirmation
type,
but
there
is
no
instruction
use
the
confirmation
tag
from
the
last
commit,
and
then
there
is
this
corner
case
where
there
is
no
last
commit
and
I
guess,
we
would
have
noticed
if
we
had
such
a
text.
Maybe.
J
D
Yeah
I
I
actually
looked
at
the
code.
That's
in
my
implementation
this
morning
to
to
confirm
how
I,
how
did
I
set
that
field
and
we
actually
computed
on
the
Fly.
You
know
by
with
the
confirmation
key
for
the
current
Epoch
and
the
confirmed,
transcript
hash
for
the
current
Epoch,
which
seems
like
you
could
specify
that
behavior.
J
D
Well,
yeah
I
think
we
should
say
that
in
any
case,
the
question
is:
what
is
the
interim
transcript
hash
that
you
use
here?
Is
it
empty
or
is
it
the
confirm
the
empty
confirmed,
transcript
hash,
plus
the
confirmation
tag
and
actually
I,
don't
know?
Maybe
we're
not
ambiguous
here,
because
I
think
the
empty
interim
transcript
hash
is
just
the
interim
transcript
attachment
before
that
confirms.
D
It's
stated
and
I
think
at
least
the
way
mustache
interprets
things
is
that
the
interim
transcript
tabs
that
you
use
to
initialize
epoc1
is
the
confirmed,
transcriptation
group
info
plus
the
confirmation
tag
in
the
group
control
and
that
becomes
the
new
term
transformation.
E
Well,
okay,
so
we
have
some
concrete
texts
in
front
of
us
that
Marco
wrote
that
I
think
everybody
agrees
that
it
would
work
and
the
objection.
The
main
objection
is
just
that
it
creates
this
special
case
during
epic,
zero
and
then
you've
kind
of
descript,
Richard,
you've
described
a
few.
You
know
a
way
in
which
you
can
do
this.
That
doesn't
have
a
special
case
but
require
you
know,
has
a
bunch
of
assumptions
that
are
not
obvious.
D
Two
people's
I'm
not
sure
that
this,
what
we
have
in
front
of
us
is
actually
a
concrete
or
let
me
let
me
push
on
some
specifics
here
so
Marta.
What
do
you
mean
when
you
say
the
Joiner
uses
the
empty
Trend
interim
transcript
hash.
I
So
I
was
looking
at
section
11,
where
groups
are
created,
and
it
says
that
when
you
initialize
a
group,
you
always
have
to
do
a
connect
after
you
initialize
it
does
that
help.
If
we
don't
have
that
Epoch
zero.
J
Yeah
that
will
help.
It
doesn't
actually
say
that
I
didn't
see.
D
Yeah,
but
that's
in
this
a
little
over
the
top
yeah
I
think
the
way
that.
D
I
think
the
way
section
12
is
written
right
now
it
sounds
like
it
doesn't
have
a
way
to
to
create
a
one-member
group.
I,
don't
think
there's
all
you
always
want
to
create
a
group
with
more
than
one
member.
D
Well,
so
I'm
still
actually
worried
about
anything.
Yet
here
so
Marta.
Could
you
maybe
clarify
what
you
mean
with
using
the
NT
transcript
interim
transcript
hash
here.
J
D
B
B
Any
sense
for
the
like
an
empty
and
you're
just
using
an
empty
transcript
hash.
J
B
D
D
Okay,
so
I
think
I
I'm
coming
around
to
this
solution,
but
I
think
we
should
probably
file
an
issue
for
what
Brendan
pointed
out
in
terms
of
making
clear
that
you
can
create
a
one-member
group
and
you've
not
had
anybody.
J
I
mean
I
I,
don't
see
why
not
to
be
honest,
yeah
we
we
clarified
that
the
confirmation
tag
in
the
first
group
info
is
empty
because
there
was
no
confirmation
tank
before
and
with
this
one
I
I
think
we
still
need
to
special
case
somehow
because
well,
okay,
to
fix
another
fix,
for
this
is
for
the
first
interim
transcript
hash
to
be
actually
the
hash
of
an
empty,
confirmed,
transcript
hash,
an
empty
confirmation
tag.
We
can
also
fix
it
like
this.
J
D
D
Yeah,
that
sounds
right.
So
let
me
put
this
comment
in
pull
request.
B
D
What
I'm
writing
here
is
that
epoch0
group
info
has
an
empty
confirmation
tag
and
then
the
interim
transcript
initial
interim
transcript
hash
must
be
the
empty
confirmed,
transcript
hash,
plus
the
empty
confirmation
tag.
J
Neck
of
the
attack,
it's
the
hash
of
empty
tag
and
empty
confirmed
hash.
D
D
All
right,
I
think
we've
got
a
good
path
on
that,
so
Martha
just
I'll
keep
an
eye
out
for
your
changes.
D
All
right
thanks
next
I
think
these
are
just
a
bunch
of
nits
from
Paul's
review.
Brendan
already
approved
these,
so
you
can
probably
just.
A
D
Oh
I
think
the
one
one
thing
that
might
be
a
small
interest
is
that
very
first
change
there.
H
D
The
question
is
how
you
say
that
so
before
we
set
it
by
reference
to
this
SEC
G
non-itf
kind
of
random
group
of
vendors
who
got
together,
spec
Paul
flagged
that
and
I
went
over
and
looked
at
the
TLs
spec
8446
and
realized
they
had
defined
their
own
description
of
this.
So
TLS
has
a
description
that
basically
is
a
TLS
stroke
that
says:
zero,
four
octet
x,
coordinate
y,
coordinate
and
so
I
think
we
can
just
borrow
that
and
use
it
here.
D
A
I
actually
missed
that
in
my
review
and
I'm
completely
with
Paul,
we
shouldn't
point
to
that
spec.
If
we
can
get
away
with
it,
we
should
just
let
it.
D
C
C
So
it's
interesting.
What
you
mentioned
Richard
to
do
is
Greece
thing,
which
seems
to
be
a
good
practice.
So
that's
a
way
to
prepare
that
and
yeah
for
consistency.
I
would
propose
to
do
the
other
ones
as
well,
because,
while
the
same
logic
applies
to
them
and
specifically
for
the
content
type,
we
already
introduce
a
new
one
in
one
of
the
extensions
now,
and
it
might
very
well
be
the
case
that
you
want
to
introduce
more
and
then
eight
bits
into
little
bit
smaller.
C
If
you
want
to
evolve
through
this,
given
that
this
is
not
something
I
rewrite
it
like,
it's
not
going
to
be
in
any
registry.
C
So
I
know
we
want
to
keep
the
wire
format
as
small
as
possible,
but
I
think
it's
tolerable.
If
we
also
make
an
English
content,
type
and
wire
format,
don't
remember
what
I
commented,
but.
B
D
We
included
in
a
bunch
of
the
Macs
for
domain
separation.
Okay,.
G
B
C
Yeah
I
mean
this
would
be
like
for
a
completely
preparator
or
a
lot
of
them,
for
example,
and
we
discussed
that
previously,
you
know
four
run
outs
that
are
pre-rfc
that
might
want
to
have
a
different
version
number
so
that
you
can
upgrade
okay.
Maybe
this
is
not
going
to
be
such
a
huge
issue
anymore.
C
Now
that
we're
closer
to
RC
but
stuff
like
that,
but
you
need
for
consensus.
Obviously
I
mean
this
is
not
aimed
at
interrupt.
B
E
B
E
You
can
always
make
an
extension
to
Define
more.
If
you
need
to
I'm
curious
Brita,
do
you
do
you
have
any
size
concerns.
H
No,
no
delay
forgot
to
wait
before
talking.
I.
Don't
have
any
particular
concerns
on
this
I
think
we'll
be
okay.
On
our
end,.
A
C
You
said
you
can
make
a
new
extension,
but
that's
not
really
practical,
though,
because,
like
literally
right
now,
we
already
do
that
for
targeted
messages.
We
introduce
let's
inquiry
from
it,
so
assuming
we
we
wanted
targeted
messages
and
then
we
would
have
to
completely
lose
the
compatibility.
C
D
C
A
Yeah
I
guess
what
I'm
trying
to
figure
out
is
like
you
know,
is
this
something
that
we
think
we
can
live
with
and
if
it
is,
then
maybe
we
should
just
merge
it
there's
ways
to
carve
up
the
registry
in
the
Ayana
consideration
section
to
say
you
know
this
is
a
huge
registry,
the
first
you
know
certain
number
or
reserve
for
the
working
group
and
then
like
the
last
I,
don't
know
50
or
64
or
whatever
is
like
you
know,
private
use.
You
can
do
whatever
you
want.
A
I,
don't
know
that
we
need
to
do
that
at
the
idea.
That
was
that
we're
trying
to
grease,
which
you
know
the
idea
of
people
don't
know
the
idea
is
that
it
stop
middle
boxes
from
ossifying
on
a
particular
number,
so
it
kind
of
makes
them.
You
know
a
little
a
little
bit
more
agile,
so
I
guess
I'm
coming
to
the
conclusion.
I,
don't
really
love
this
I.
Don't
really
think,
there's
ever
going
to
be
that
many
versions
but
like
if
there's
not
really
a
concern
about
size
constraint.
D
I
would
note,
by
the
way
that
everything
we
have
in
Iana
emergency
report
is
already
two
bytes.
D
Maybe
we
should
have
more
things
in
Registries
like
maybe
the
wire
formats
need
to
go
into
registry,
but
yeah
we're
already
with
two
bytes
for
everything.
That's
Diana
registerable.
C
C
But
if
folks
agree,
then
maybe
we
should
include
wire
format
into
that
as
well.
K
D
C
C
D
D
Version
I
think
I
would
do
I.
Think
I
would
not
do
Ayanna
for
protocol
version,
but
I
would
would
do
it
for
wire
format.
D
D
D
All
right,
good
I
think
we
got
a
resolution
there.
8
22,
please.
D
All
right,
this
is
just
increasing
the
amount
of
Inner
Space
from
eight
bits
to
12
bits.
D
It's
easy
823.
D
You
know,
obviously,
if
you're
using
things
like
credentials
for
certain
things
like
x509
certificates
for
credentials,
they
can
expire
or
I
would
point
out
the
revoked.
In
any
case,
their
validity
status
can
change
over
time.
D
I
think
Rowan
hit
on
on
my
ideal
stage
in
the
in
the
issue.
Discussion,
which
is
like
the
application
operationally
should
arrange
for
the
credentials
to
be
valid
at
all
times
so
that,
if
someone
joins,
they
can
develop
verify
anything.
They
don't
have
invalid
credentials
hanging
around
them
to
do
some
of
the
error
conditions
for
them.
D
Obviously,
that's
an
ideal
and
I,
don't
think
you're
going
to
be
able
to
maintain
a
double
times,
but
I
think
the
high
level
point
is
that
it's
the
application's
job
to
assure
that,
and
we
should
Point
them
toward
that
and
recommend
how
you
do
it,
but
not
have
hard
requirements
about
it.
So,
out
of
this
section
to
provide
that
guidance.
D
K
So
yeah
originally
I
was
looking
for
a
harder
requirement,
but
I
think
throughout
the
discussion.
I
came
around
to
the
idea
that
what
you're
proposing
here
actually
does
make
sense
in
terms
of
a
compromise,
because
you
can
just
leave
it
up
to
the
application
and
we
have
already
discussed
ways
of
implementing
this
as
an
optional
thing
and
I
I
think
that's
totally
reasonable.
J
My
biggest
kind
of
confusion
is
the
kind
of
catch-up
scenario.
If
that
makes
sense,
like
I
was
invited
in
in
the
group
into
a
group
when
I
was
on
vacation
right,
I'm
joining
I'm,
validating
credentials
and
well,
they
expired,
but
they
were
perfectly
valid
when,
when,
at
the
time
the
comments
were
issued
so
I
mean
your
text
is
mostly
mostly
about
sending
and
committing,
and
in
this
case
I
think
this
is
clear.
This
is
fine
and
you
should
check-
and
this
is
all
good.
J
The
kind
of
contentious
part
is
like
when
you're
catching
up,
and
we
have
text
right
above
this
text
saying
that
you
must
validate
credentials
when
there
is
an
ad
proposal.
But
there
is
an
ad
proposal
that
was
sent
like
weeks
ago
and
it
kind
of
a
mismatch
here.
So.
E
G
J
You're
not
really
validating
a
credential
you're
validating
a
credential
against
a
time
stamp,
but
these
timestamps
don't
don't
exist
in
the
in
the
RFC
right
now
and
then
this
is
like
you,
you
should
be
validating
the
credential
against
the
timestamp
of
when
the
commit
was
made.
If
you
know
it
somehow,
from
somewhere.
I
K
D
Would
do
it?
We
had
a
similar
issue
with
lifetimes
of
key
packages
where
we
say
You
must
validate
them
when
you
do
an
ad,
because
you
must
validate
that
it's
valid
right
now
doing
you
do
an
ad,
but
you
probably
you
you
might,
but
you
probably
shouldn't
when
you
receive
it,
because
it
might
have
been
delayed.
J
K
J
Yeah,
it's
still
still
doesn't
agree
with
with
how
the
says
that
whenever
I
receive
an
ad
proposal,
I
must
validate
the
credential,
but
against
what's
time.
D
I
mean
you
could
say
something
like
so
since
in
in
principle,
like
expiring
credentials,
you
know
the
credentials
with
time
varying
validity.
Are
it
doesn't
cover
all
credentials?
You
could
say
something
here
like
you
could
validate,
except
for
the
time
varyings,
that's
a
right,
so
you
could
validate
ignoring
probability
or
ignoring
revocation
until
you're
back
in
a
reasonably
current
state.
H
C
H
I
was
gonna
say
there
seems
to
be
a
bigger
aspect
here.
So
going
back
to
some
of
the
earlier
discussion
on
DS
I,
recall,
I,
think
Raphael,
you
mentioned
you
were
dealing
with
time
stamps
instead
of
epoch
numbers
for
tracing
the
updates,
and
that's
essentially
what
the
issue
that
this
is
what's
going
on.
Is
that
we're
not
associating
epochs
to
any
particular
time
and
therefore
we
can't
associate
the
credential
to
a
particular
time
to
a
particular
Epoch
for
taking
updates.
So
one
solution,
side
of
this
is
saying
all
right.
H
We
associate
epochs
to
timestamps
in
some
way.
That's
not
really
ideal
as
a
generic
case,
there's
another
variant
where
we
say
we
put
on
the
DS.
The
DS
actually
has
to
associate
some
sort
of
time
step
to
updates
so
that
when,
if
someone
is
out
of
time-
and
that's
really,
the
case
Marta
is
looking
at
here-
is
someone's
coming
online
after
the
fact
and
is
pulling
old
updates.
So
there's
some
sort
of
time
stamp
Associated
to
those
epochs
that
they're
pulling
from
an
older
State
as
a
building
credential
to
say.
H
J
C
So
I
agree,
it's
generally
very
complex.
The
question
is,
though,
what
you
said:
Marta
and
I
agree
with
it,
but
it's
not
really
part
of
Richard's
PR
and
the
fact
that
credential
must
be
validated
right.
C
J
C
Yeah
I
fully
agree,
but
maybe
if
we
can
already
get
consensus
on
the
pr
I
I
do
have
one
remark
specifically
about
the
piano.
That's
the
third
paragraph
where
you
say
that
foreign
vague.
C
D
C
A
concrete
proposal
I'm
just
saying
that
this
could
be
potentially
problematic,
depending
on
how
you
interpret
it
because
it
remembers
rotary
yeah.
You
could
also
interpret
it
in
a
way
that
you
say:
okay
in
any
case,
members
are
allowed
to
do
that,
regardless
of
their
power
level
within
the
group,
and
then
you
have
a
conflict
with
that.
E
E
I
mean
that's,
that's
a
dsas
issue
right,
that's
so
that's
kind
of
out
of
scope
of
the
protocol
document,
and
that
would
be
the
kind
of
thing
that
we
would
need
to
talk
about
in
the
architecture
document
right.
C
Well,
no,
not
exactly
because
the
the
spec
here
you
know,
introduces
something
that
so,
while
we
don't
have
any
sort
of
hierarchy
within
the
group,
it
seems
to
stipulate
that
it
is
okay
that
in
a
very
specific
condition,
one
member
removes
another
member.
E
This
is
so
the
the
spec
already
says
that
the
spec
allows
people
to
send
any
valid
proposal
any
valid
commit
at
any
time,
and
this
is
just
saying
right.
Maybe
one
of
the
things
you
would
do
is
issue
a
remove.
That
removes
the
member.
If
you
detect
this,
so
it's
just
it's
just
saying
something
that
you
can
you
know
it.
C
So
assuming
you
have
a
well-defined
extension,
you
know:
that's
categorizes
members
into
two
group,
admins
are
not
allowed
and
and
that
in
itself
is
completely
sane.
C
G
D
D
So
the
second
paragraph
here
talks
about
that
a
little
bit
right,
so
it
talks
about
accepting,
updates
and
commits
so
that
from
invalid
credentials,
so
that
someone
can
update
and
get
out
of
that
state.
So.
J
D
Yeah,
so
what
I
was
thinking
was
you
know
you
could
say
something
like
you
could
generalize
that
last
sentence
in
the
second
paragraph
and
say
something
like
you
know
you,
if,
if
a
client
is
in
a
state
where
it's
processing
old
messages,
it's
May
choose
to
accept
any
any
proposal
or
commit
issue
from
an
invalid
from
an
expired.
D
Credential
probably
distinguish
time
invalid
from
generally
invalid
from
an
inspired
credential
until
it's
back
in
a
reasonably
current
state
and
that's
still
pretty
soft
guidance,
but
I
think
it
would
kind
of
add
the
right
caveat
to
the
the
general
requirements
you're
talking
about.
J
Yeah,
maybe
that
would
work
I'm,
also
a
bit
concerned
about
the
previous
section,
which
says
that
you
must
validate
credentials
in
in
a
bunch
of
cases
and
now
we're
saying
well
not
really,
if
you're,
not
if
you're
in
this
catch-up
state.
So
maybe
we
should
relax
the
previous
section
instead
saying
You
must
validate
the
credential
is
valid
or
if
you're
catching
up,
maybe
you
don't
have
to
or
something
like
that.
J
But
see
my
point
is
that
I
I
do
care
about
expiration,
though
when
I,
when
I
commit,
for
example,
but
there
is
only
one
procedure
to
validate
and
it's
executed
when,
when
you
send
a
new
X
and
it's
executed
when,
when
you
receive
so
how
do
I
Implement
my
as
to
actually
have
this
one
procedure
that
takes
care
of
the
expiration
time
like
it's
saying
now,
it's
expired
or
now
it's
valid
and
make
it
not
fail
when
I
catch
up,
but
still
reject
bad
credentials.
When
I
try
to
send.
E
E
E
But
but
what
Tom
said
is
correct
and
that
it
doesn't
Define
emulence
doesn't
Define
everything
that
constitutes
valid
or
invalid,
and
this
so
this
language
basically
allows
for
you
to
have
both
you
know
in
this
context.
This
is
valid
in
this
context.
This
is
valid
in
addition
to
the
things
that
the
MLS
spec
says.
These
are
definitely
not
valid,
but
all
the
other
things
like
all
that
other
detail,
that's
more
application
layer
of
that
validity.
That
stuff
is,
is
left
to
the
application
and
to
the
context.
H
So
that
second
paragraph
there
is
something
so
there's
two
things
about
that
that
I
would
raise
some
concern
about.
One
is
minor
or
fairly
minor,
where
it
says
the
members
should
accept,
update
proposals
and
commits
issued
by
members
with
invalid
credentials
if
the
credential
in
the
updater
commit
is
valid,
and
that
makes
some
sense
if
the
we're
talking
about
proposals
in
the
first
clause
and
the
actual
commit
in
the
second
Clause.
H
But
as
read
it's
saying
on
the
commit
part
that
it's
a
contradictory
statement
that
we
should
accept
the
commit
if
the
credentials
are
valid,
if
the
commit
is
is
the
credential
in
the
commit
is
valid.
H
You
can
see
where
that
conflict
is
so
there
might
be
some
refinement
on
wording
there
as
a
bigger
comment
on
this
one
or
on
that.
Second,
paragraph
I,
think
that
we're
addressing
this
Edge
case
or
or
a
very
kind
of
segment
in
time
and
that
it
needs
to
be
addressed
so
I
think
that
this
should
apply.
But
we
should
also
clarify
there
needs
to
be
addendum
here
to
clarify
the
limits
on
this,
because
we
could,
as
taking
this
paragraph,
does
allow
for
something.
H
Let's
say
someone's
compromise
in
their
credentials
revoked,
and
this
is
explicitly
allowing
that
invalid
credential
to
then
commit
a
new,
valid
credential
under
Alice's
name
and
there's
nothing
that
stops
up.
So
we
have
an
allow
here
and
a
good
reason
to
allow
it.
But
we
also
need
some
text
that
says
how
not
to
extend
this
to
other
breaks.
D
Yeah
right
so
I've
I've,
been
writing
notes
in
the
TR.
Now
like
one
of
the
notes,
I've
got
is
to
distinguish
time
and
valid
I'm
calling
insulate
expired
or
remote.
Maybe
maybe
we
included
in
there
from
generally
involved,
like
not
signed
by
a
real
Authority
or
something
like
that.
E
And
I
guess
the
other
question
is:
if
we
have
if
a
member
finds
credential
is
invalid
or
will
be
soon
so
we'll
be
soon,
if
not
doesn't
isn't
an
issue
for
this
bit
tradition
update
or
commit,
but
if
it
finds
that
it's
that
it
is
actually
invalid,
then
it
could
just
go
and
do
an
external.
You
know
an
external
commit
or
an
external
proposal
to
go
and
add
itself
and
remove
its
old
incidents.
C
D
B
D
So
so
the
notes
notes,
I've
got
here,
are
one
distinguished
time
indulge
from
invalid
and
then
the
other
as
I've
got
a
note
about
the
general
issue
that
Martha
raised
about
having
messages
that
were
from
Members,
whose
credentials
were
valid
when
the
message
was
sent
but
then
have
since
expired
before
you
caught
up
and
the
the
resolution
that
I've
got
in
my
notes,
Here
is
to
recommend
that
when
you're
catching
up,
the
as
male
May
accept
message
credentials
as
valid
that
were
sent
that
that
are
that
as
the
time
invalid.
D
Sorry,
let
me
just
read
you
what
I
wrote.
The
bullet
points
in
my
head
says,
recommend
accepting
messages
from
Members
with
time
and
valid
credentials
when
catching
up.
D
A
D
A
So
why
don't
we
go
ahead
and
we
can
if
we
were
to
go
next
Friday
from
like,
in
the
same
time,
from
10
to
12
at
Eastern.
D
G
A
Maybe
we
could
get
Paul
I,
don't
know,
I,
don't
know
when
they
start
the
clock
for
a
week
is
my
concern,
so
they
might
feel
like
it
should
have
been
done
Wednesday.
So
that's
why
I
said
Friday.
B
All
right
one
last
question
regarding
this
PR,
so
the
concept
was
to
merge
the
CR
and
we're
going
to
do
a
follow-up
with
more
Tattoo
review
that
sound
right.
D
E
A
Yeah
I
think
it's
we'll
go
ahead
and
do
that
I
will
go
ahead
and
throw
a
an
interim
in
for
next
Friday
this
afternoon.
Just
in
case
we
need
it.
We
can
always
cancel
it
if
not
and
again
I.
Thank
the
people
that
get
up
early
or
stay
up
late
to
do
that.
A
So
the
question
now
is:
we
don't
have
Benjamin
on
the
call
unless
he
slipped
in
here
to
talk
about
the
architecture
draft
but
I
do
think
it's
worth
at
least
looking
at
the
pull
requests
that
are
here,
because
some
of
these
are
getting
a
little
long
in
the
tooth,
because
I
know
Rowan
put
a
bunch
of
these
in
over
time
has
is:
is
there
any
like
Grand
objection
to
any
of
the
other
proposals
that
have
they've
been
put
forward,
but
I
guess
I'd
kind
of
you
know:
I,
don't
I
don't
want
to
go
through
them
individually,
but
like
are
there
any
of
these
that
other
people
have
read
and
they're
like?
A
A
Okay,
so
I'm
hoping,
if
you
guys,
could
take
a
chance
to
review
this
because
again,
like
I,
just
I'm,
very
concerned
that
if
we
don't
I
want
to
pass
documents
forward,
that
don't
have
outstanding
PRS
and
I
Roa
did
put
some
of
these
in
I.
Think
during
working
with
last
call.
So
we
do
need
to
make
sure
that
they
get
addressed
and
if
they're,
if
they're
open
issues-
and
we
try
to
give
it
to
the
isg
they're
going
to
be
all
over
us.
So
we
need
to
make
sure
that
we
review
these.
A
Unfortunately,
I,
don't
think
we're
gonna
be
able
to
do
much
more
than
on
this
document
than
that
to
get
people
to
review
and
if
you
think,
they're
fine
thumbs
up
is
really
the
best
way
forward
right
and
to
go
from
there
and
I
know
that
the
the
Paul's
ad
review
of
the
architecture
document
is
basically
being
worked.
That's
why
there's
you
know
a
bunch
of
issues
in
the
document
that
Benjamin's
gonna
get
to
and
I'm
hoping,
maybe
switching
to
Friday.
E
Yeah
and
I'm
just
going
to
point
out
one
other
thing,
which
is
there
were
at
least
three
issues
that
Paul
brought
up
on
the
art
on
the
protocol
document
that
were
addressed
by
by
changes
that
I
put
in
the
PRS
ly,
and
it's
like
well,
here's
here's
a
section
in
this
in
this
unmerged
PR
that
deals
with
that
issue
that
you
commented
on
right.
So.
A
It
was
actually
funny
because,
when
Paul
was
doing
that
he's
like
yeah,
you
can
send
me,
you
can
send
me
the
document
even
with
outstanding
PRS
and
I,
was
like
make
sure
to
read
those
when
you're
doing
your
comments
and
I
guess
he
just
missed
those
so
I
don't
know
it's
kind
of
nice
to
see
that
we
we,
you
know
we
were
ready
to
go.
Basically.
A
E
E
But
the
rest
of
them
there
were,
you
know,
minimal
comments
and
in
some
of
the
cases
they
were
just
like
yeah,
like
I
changed.
You
know,
I
fixed
the
I
fixed,
the
you
know
the
the
references
for
the
the
security
analysis
right.
It's
like
there's,
no,
there's
no
like
I,
don't
think
anyone
is
gonna,
have
any
objection
to
those.
But
but
this
one
is
the
one
that
probably
needs
some
attention.
A
I've
typically
kind
of
left
that
to
the
author,
so
I'm,
hoping
that
when
he
gets
to
this
other
stuff,
he'll
do
it
and
if
he
doesn't,
then
we
can
I
can
I
can
press
buttons,
so
I'm
gonna
try
to
see
if
we
can
leave
it
to
get
those
done
when
he's
going
through
the
ad
review
comments,
as
opposed
to
kind
of
overriding
it,
but
if
it
goes
any
longer,
then
yeah,
I'm
gonna,
because
these
are
kind
of
old,
okay,
yeah.
A
I
I
Here
the
policy
on
Cipher,
Suites
and
extensions,
which
doesn't
necessarily
make
sense
to
me
because
these
are
negotiated
so.
I
And
broken
brings
up
that
there
may
be
compliance
aspects
so
like
fips.
If
you
require
a
certain
thing,
so
that
would
be
a
policy
but
I'm
not
sure.
E
So
yeah,
so
the
the
distinction
that
I
wanted
to
make
is
the
difference
between
I
have
an
implementation
which
can
do
you
know
all
sub,
all
seven
Cipher
Suites
or
five
of
the
seven
Cipher
Suites.
But
then
then,
in
a
particular
deployment.
E
I
E
E
Just
it's
it's
it's
like
what
we
do
in
TLS
today,
where
I
can
go
and
configure
my
server
where
I
say:
okay,
The
Cypher
Suite
list
here
is
the
cipher
Suite
list
of
among
the
ones
that
are
supported
by
by
open
SSL,
where
I've
removed,
I've
pared
down
the
list
to
only
support
these
and
then
of
those.
Then
you
negotiate.
H
E
I
mean
if
you're
setting
up
a
policy,
presumably
you're,
setting
it
up
in
a
consistent.
It's
your
responsibility
when
you
make
a
policy
to
do
it
in
a
consistent
way
for
your
contacts.
So
if
my,
if
my
context
is
I'm
doing
it
for
Mimi,
then
interoperability
is
a
strong
consideration
and
I
want
to
make
sure
that
I
have
the
broadest
interoperability
possible
in
the
instant
messaging
context.
E
If
I'm
doing
one,
for
you
know,
government,
inter-government,
private,
Network
things,
then
I'm
going
to
have
a
different
set
of
interoperability
concerns
there
and
I
need
to
make
sure
that
my
policy
is
self-consistent
with
that.
E
Sorry
so
if
I
I
I'm,
not
sure
I
completely
understood
what
you
meant
but
like,
if
I
was
taking
the
case
of
Cipher
Suites,
if
I,
if
I
had
an
implementation
that
can
do
all
seven
Cypher,
Suites
and
my
policy
said
I,
don't
allow
Cipher
Suites,
that's
due
Cha-Cha
poly,
then
the
negotiation
would
occur
using
the
five
Cipher
Suites
that
don't
contain
Cha-Cha
poly.
H
C
E
The
the
policy
is
I'm
not
going
to
ever
give
you
I
mean
I'm
not
going
to
in
this.
In
this
context,
I'm
not
going
to
allow
the
usage
of
those.
Now
you
could
go
and
send
me
send
me
a
key
package
that
contains
Cha-Cha
poly
I'm
going
to
say
that's
great
thanks,
I'm
not
going
to
hand
this
out
to
anybody
or
I'm
not
going
to
use
this.
None
of
my
clients
are
going
to
use
this
this
key
package.
H
This
could
occur
if
you
have
say
messaging
implementation
that
is
supported
in
either
various
companies
or
or
a
person
has
a
private
version
on
an
application,
as
well
as
a
company
version,
and
so
what
they
support
in
that
negotiation
is
everything
in
your
implementation.
So
you
have
this
list
of
say
five
cyber
Suites,
but
company
policy
only
allows
you
to
use
one
of
say
two
of
these.
So
when
you
are
in
groups
inside
that
company,
you
not
only
have
to
negotiate
and
satisfy
this
policy.
H
C
Yeah
yeah
I
understand
that
part,
but
in
very
practical
terms,
like
the
the
end
bit
of
the
negotiation
is
done
by
the
group
Creator
who
decides
on
disciplesweet.
C
So
in
that
specific
case,
that's
exactly
when
the
company
policy
would
interfere
with
that,
and
so
you
cannot
create
a
group
without
Cypher
Suite.
B
G
C
C
Chicago
yeah
I,
don't
know
it's
weird
that
you
know
in
that
particular
constructed
example
that
that
you
know
an
outsider
to
the
company
of
Italy
with
a
misbehaving
client
can
create
a
group
that
then
belongs
to
the
company.
Maybe
the
example
is
not
the
best
one
attitude
to
clarify
what
you're
after.
E
Okay,
I
I,
guess
I'm
not
seeing
why.
This
is
why
this
is
this
seems
so
unusual
to
people
I
mean
we,
we
do
TLS
implementations.
Do
this
all
the
time
right.
We
have
an
implementation,
it
does
this
this
big
list.
We
have
a
policy
that
says
we're
going
to
do
this.
These
are
allowed
and
then
we
negotiate
something
inside
of
the
subset
of
the
intersection
of
those
two
lists
right
in
this
case,
the
fact
that
you
have
a
policy
it
doesn't
mean
that
we
have.
We
have
defined
a
protocol
mechanism
for
conveying
that
policy.
E
It
just
means
that
that
policy
exists
and
is,
can
and
is
somehow
configured
across
the
across
the
MLS.
You
know
scope
of
of
implementations
that
are
participating
so
like
when
you
say,
but
you
know,
but
the
foreign
somebody
who
goes
to
create
a
group
they
they're
going
to
at
the
time,
they're
they're
only
going
to
go
and
add
users
that
comply
with
the
policy.
It's
like,
yes,
they're
only
going
to
comply
with
the
policy.
E
How
did
they
find
out
about
the
policy
you
needed
to
you
needed
to
have
a
policy,
and
so
that
all
this
is
saying?
Is
that?
Yes,
this
is
one
of
the
things
that
this
is
one
of
the
policy
considerations
that
you
need
to
put
into
making
to
put
into
consideration,
and
this
is
exactly
what
Paul
asked
for.
E
That
is
the
protocol
of
concern,
but
in
terms
of
operational
consideration
sections
our
operational
considerations,
this
section
is
supposed
to
enumerate
all
kinds
of
things
that
that
one
might
need
to
keep
into
consideration
in
order
to
run
a
network.
C
Yeah,
okay,
now
I
mean
I.
Think
fundamentally,
I
agree
with
you
the
it's
the
example
that
I
didn't
agree
with,
but
I
can
see
where
this
is
needed
when
you
actually
generate
key
packages,
because
clients
need
to
know
what
Cipher
Suites
to
include
besides
the
one
that
they
actually
cryptographically
support,
so
that
that's
exactly
the
point
where
you
were
saying
clients
need
to
know
about
the
policy.
C
I
Yeah,
so
I
guess
my
objection
at
this
so
far
has
been
that
I've
been
trying
to
keep
this
list
just
to
what
our
interoperability
requirements
in
a
pretty
pure
sense
like
just
what
is
what
is
going
to
help
the
group
work
together,
assuming
that
there's
not
like
some
sort
of
outside
issue
like
part
of
this,
is
that
you
are
putting
it
in
the
context
of
being
like
in
a
corporation
or
maybe
the
corporation
requires
FEPS,
and
so
that
seems
sort
of
like
an
outside
concern
to
me
where
the
corporation
could
enforce
basically
any
requirement
that
it
wants,
but
I
can
I
can
see
if
this
is
a
common
enough
concern
that
we
could
could
reasonably
include
it.
E
Yeah
I
I
think
we
just
disagreed
about
what
this
was.
What
this
was
useful
for
and
I
think
that
the
the
thing
that
I
am
thinking
that
this
section
is
useful
for
is
exactly
the
kinds
of
things
that
you
know.
Paul
asked
well
what
about
this,
and
we
say
yeah
here
in
this
section,
it
says,
like
he's,
he
was
asking
for
exactly
this
kind
of
thing
and
that's
why
I
wanted
this
to
be
as
inclusive
and
possible
as
possible
in
the
in
the
broader
sense,
and
not
just
in
the
protocol
and
operability
sense.
I
Okay,
so
moving
on
to
I
think
line
832,
there's
sort
of
a
similar
issue
where
the
line
is
a
policy
of
when
members
should
commit
pending
proposals
in
the
group.
So
this
is
already
discussed
in
the
protocol
document,
basically
saying
that
there
are
some
rules
that
you
have
to
send
the
commit.
If
you
want
to
send
an
application
message-
and
there
are
uncommitted
proposals
into
these
things-
it's
not
specified
in
the
protocol
Doc.
It's
also
not
necessary
for
interrupting
that
sort
of
pure
sense.
That
I
was
talking
about.
E
In
the
same
kind
of
way,
if
you
have,
if
you
have
a,
if
you're,
if
you're
concerned,
that
you
have
a
a
network
set
up
where
you
have
a
lot
of
very
large
groups,
you
have
groups
of
you
know
ten
thousand
hundred
thousand
members,
then
you
don't
want
every
member
to
commit
every
pending
proposal
to
try
to
commit
every
pending
proposal
immediately,
all
at
the
same
time
and
so
having
a
policy
of
like
this
is.
E
This
is
the
order
in
which
you
know
that
this
is
who
should
try
to
commit
pending
proposals
immediately,
and
this
is
who
should
wait?
The
the
other
thing
is:
if,
if
nobody,
maybe
you
have
the
the
opposite
problem,
which
is
you
want,
pending
proposals
to
be
committed
promptly,
because
you're
also
supporting
external
commits-
and
in
that
case
you
you,
you
don't
want
all
the
clients
that
are
not
sending
anything
to
just
sit
around
and
say
not
my
problem,
I'm
going
to
wait
for
somebody
else
to
commit
so
in
aggregate.
E
C
C
E
So
it
if
somebody
wants
to
send
some,
you
know
anyone
wants
to
propose
a
alternate
phrasing
of
this
feel
free,
but
I
think
everybody
understands
what
I
meant
at
this
point.
E
Okay,
Brendan
I
think
your
next
comment
was
on
line
833.
I
For
that,
it's
not
I,
think
you
put
it
here
as
a
policy,
but
we
have
basically
like
a
generic
unspecified
mechanism
for
sharing
the
group
info.
E
What
is
the,
what
is
the
the
generic
mechanism
for
sharing
group
info?
We
have
a
structure,
but
we
don't
have
a
there's
not
like
a
protocol
foreign.
E
Okay,
so
I
guess
the
the
only
thing
that
I
would
be
concerned.
E
Yeah
so
it'd
be,
if
you're
there's
nothing
in
there
about
I,
don't
see
anything
about
how
you
how
you
fetch
it
necessarily,
but
the
the
sort
of
the
policy
aspect
that
I
was
concerned
about
is
basically
you
know
in
our
environment,
the
DS
is
distributed
across
domains,
and
so
just
sharing
this
group
info
we
want.
We
want
to
do
sort
of
an
additional
end
to
Middle
encryption
in
some
cases
to
make
sure
that
it's
the
group
info
isn't
shared
with
with
intermediate
servers,
which
are
part
of
the
same
DS.
I
I
was
gonna,
say
you
don't
feel
that's
a
concern
that
the
the
group
info
has
handled
a
specific
way,
isn't
addressed
just
by
the
design
and
Implement
implementation
of
the
mechanism
for
sharing
the
group
info.
E
So
I
I
would
think
of
the
of
seven
seven
seven.
The
other
line
as
being
like
I
would
I
would
write
up.
You
know
this
is
the
rest
endpoint
that
you
use
for
accessing
the
group
info
and
I
might
have
the
ability
to
to
upload
it
and
fetch
it
unencrypted
or
encrypted,
and
then
the
policy
would
be
do
I
require
that
it
has
to
be
encrypted
in
this.
In
this
context,.
C
C
But
then
the
question
is:
how
does
the
DS
make
it
available
to
potential
new
joiners?
Where
you
have,
you
might
have
an
access,
controlled
situation
that
has
nothing
to
do
with
the
way
you
uploaded.
It
initially
might
be.
Disjoint.
I
I
D
F
B
A
All
right,
we
got
four
minutes
left.
What
do
we
think
we
should
go
to
next.
I
About
making
sure
to
use
basic,
credential
correctly
or
securely
and
I'm
curious,
if
people
intend
to
actually
use
basic
credential
in
production
or
if
this
is
just
a
testing
thing.
A
A
A
C
Answer
I
guess
our.
E
Then
the
version
that
they
were
planning
to
go
to
that
they're
planning
to
go
to
production
with
is
gonna
have
credentials
real
financials
is.
Is
there.
A
Sorry,
just
clearing
my
throat
there
is
there
any
harm
in
actually
just
saying
that
basic
is
for
test.
A
E
D
C
Why
I
could
see
this
being
used
is
in
a
in
a
scenario
where
you
don't
care
about,
interrupt
to
start
with
and,
and
things
are
fairly
minimal.
I
think
Richard
said
that
earlier,
like
signal
protocol
doesn't
have
a
concept
of
credentials
as
such,
and
so,
if
we
want
MLS
to
replace
the
signal
protocol
in
in
some
of
the
setups,
then
it
might
make
sense
to
have
that.
That
being
said,
it
doesn't
have
to
be
in
the
Speculator.
C
It
could
also,
you
know,
be
an
extension
because
we
have
the
Ayana
thing
there,
so
we
can
put
that
in
the
extension
dock,
because
it's
going
to
be
Niche,
it's
either
testing
or
obscure
setups
wow.
A
Yeah
I
think
that
I
I
just
wonder
whether
we
should
have
like
a
big
warning,
like
you
know,
TLS,
with
zero
rtt
there's
like
pages
on
like
it's
replayable,
don't
do
it.
Unless
you
do
certain
things.
Maybe
we
should
bolster
the
texture
to
make
it
a
little,
not
not
to
say
that
it's
specifically
used
for
test,
but.
B
A
C
C
E
E
C
E
Was
thinking
that
in
this
case
you
could
have
an
MLs
client
that
you
know,
or
at
least
like
an
MLs
stack
that
implements
that
implements
basic
that
is
just
influence.
The
base
protocol
that
works
with,
say,
I,
don't
know,
ring
Central's
implementation
that
uses
out
of
band.
You
know
out
of
band
verification,
identity,
verification
that.
B
S
so
I
just
want
to
remark
we're
going
moving
to
the
extension.
Talk.
I,
don't
think,
that's
a
great
idea,
because
we
need
it
for
interrupt,
so
it
should
stay
in
the
spec
if
only
for
testing
and
also
yeah
I
think
it's
I
think
we
should
let
it
in
there
and
just
leave
it
in
there,
because
Rafael
said
there
are
some
scenarios
that
people
might
want
to
use
it
in.
B
Is
it
like
a
really
really
basic,
essentially
non-existent,
as
which
might
be
useful
in
some
cases,
but
we
should
add
like
recommendations
on
how
to
use
it
properly,
as
we
wanted
to
do
anyway,
with
the
whole
discussion
on
the
basic
credential,
which
is
not
completed.
I
think
also
I
mean
I
mean
we're
over
time
now.
So
maybe
we
should
just
dedicate
this
discussion
too.
Yeah.
A
A
Do
that
I'll
I
will
I'll
send
out
a
meeting
request
thanks
all
again,
thank
you
very
much
Conrad
for
taking
notes
and
we'll
see
y'all
next
week.