►
From YouTube: IETF-MLS-20230209-1500
Description
MLS meeting session at IETF
2023/02/09 1500
https://datatracker.ietf.org/meeting//proceedings/
A
Thanks
to
all
that
showed
up
early
and
on
time,
we're
going
to
give
people
a
couple
minutes
to
dial
in.
A
All
right
meet
Echo
is
telling
me
I
can't
send
video,
so
I'm
not
going
to
so
apologies
you're
only
going
to
hear
my
voice
today
and
see
the
screens.
A
A
The
plan
here
today
is
to
kind
of
go
through
those
and
see
how
far
we
can
progress
these
one
of
the
overriding
factors
here
is
that
we'd
like
to
get
these
done
so
that
when
the
new
isg
gets
seated
in
gets
next
month
during
the
iitf
meeting
that
we
don't
have
to
redo
this
again,
so
there's
a
little
bit
of
a
time
crunch
here
to
see
if
we
can
get
these
resolved
before
the
end
of
March
I,
don't
think
that's
going
to
be
a
problem,
but
that's
just
something
to
keep
in
mind
again.
A
This
is
an
official
iitf
meeting.
We
have
a
note
well,
which
is
policies
procedures
that
we
need
to
follow
during
the
meetings
a
lot
of
them
relate
to
IPR.
A
Basically,
if
you
know
something
say
something:
if
you
have
any
questions
about
that,
I
can
fill
you
in
there's
a
place
to
do
third
party
IPR
disclosures,
Etc,
there's
also
an
Annie
harassment
procedures
and
code
of
conduct
and
all
that
stuff.
And
luckily
this
working
group
has
it
none
of
those
problems,
but
I
do
feel
compelled
to
talk
about
them
all.
A
Next
slide
code
of
conduct
guidelines
right
treat
colleges
with
respect,
speak
slowly
and
limit
the
use
of
slang
dispute
ideas
by
using
by
using
reasoned
arguments,
use
best
engineering
judgment,
find
the
best
solution
for
the
whole
the
internet
and
contribute
to
the
ongoing
work
of
the
group
and
the
ITF
and
be
keep
that
in
mind
that
we
need
to
do
it
both
here
in
Meet,
Echo,
zulup,
I,
guess,
I
need
to
change
my
slide
and
when
you're
on
the
call
all
right.
A
C
So
I
have
one
PR
so
think
on
the
protocol
document
we're
pretty
good
to
go.
There
was
one
PR
I
put
in
yesterday,
I'd
like
to
discuss
before
we
dive
into
the
documents,
though,
while
you're
pulling
it
up.
C
I
wanted
to
make
a
brief
mention
that
there
is
some
interop
testing
going
on
so
between
mlspp
and
open
MLS
and
the
Wicker
stack.
We
may
even
get
participation,
oh
and
the
inria
static
and
the
meaning
of
participation
from
RingCentral.
C
We
are
doing
some
testing
to
make
sure
all
of
those
stocks
are
implementing
the
same.
You
know
processes
implementing
everything
in
the
spec.
The
same
way,
we've
already
found
a
whole
bunch
of
bugs
where
people
were.
You
know
using
one
byte
for
two
byte
fields,
and
things
like
that.
C
C
There
also
I'll
pay
attention
to
that,
and
we
also
have
a
channel
in
the
ietf
slack
instance
ietf.slack.com,
where
we're
doing
some
coordination
I'll
send
a
note
to
the
list
after
after
this
monologue
with
much
of
these
details,
but
feel
free
to
ping
me
if
you'd
be
interested
in
participating
in
interop,
stuff
and
I,
think
that
you
would
happy
to
have
more
implementations
there.
A
One
other
thing
that
I
forgot
to
do
again
is
to
request
a
scribe.
I
was
hoping
someone
can
take
some
notes
for
me.
A
That
would
be
great
again.
It's
only
like
kind
of
the
high
points
and
you've
done
it
before
and
then
it'd
be
great,
so
I
can
actually
put
something
in
the
official
record,
fantastic,
so
without
further
Ado,
or
should
we
dive
into.
C
C
So
this
came
up
in
well
in
the
process
of
interrupt
testing,
but
not
because
we
had
interop
bugs
just
because
we
were
looking
at
the
right
part
of
the
spec
looking
at
the.
If
you
could
flip
over
to
the
diff
view,
I
think
that's
probably
better.
So
the
the
Salient
part
here
is
is
the
top
part.
The
old
transcript
hash
description
didn't
actually
tell
you
how
to
initialize
things.
C
It
I
I'm
surprised
like
the
initialization
condition
there
at
the
top
says,
Epoch
and
not
zero,
so
it
didn't
actually
tell
you
how
to
initialize
things
in
particularly
didn't
tell
you
how
to
initialize
the
interim
transcript
hash.
So
this,
the
updated
version
says
that
you
initialize
both
the
trans
interim
and
confirmed
to
zero
length
strings,
and
then
you
you
roll
forward
in
the
in
the
way
discussed.
C
So
this
doesn't
change
the
behavior
I
think
it
just
describes
it
more
clearly.
I
think
there
was
no
disagreement
about
what
the
correct
Behavior
was.
It's
just
a
clarification
in
the
description.
It
also
adds
a
figure
that
tries
to
you
know,
show
a
timeline
view
of
what
goes
into
which
transcript
hashes.
That
this
kind
of
pointed
out
is
a
little
hard
to
capture
with
exactness,
but
you
know
may
be
helpful
in
helping
people
understand.
C
What's
going
on
here,
yeah
the
better
view
of
the
figures
on
the
on
the
overview
where
I
put
the
screenshot
in.
So.
If
you
have
any
comments
on
this,
this
is
mainly
a
clarification,
not
a
behavior
change.
So
it's
not
a
huge
deal,
but
the
folks
have
new
thoughts
or
comments
on
this.
Once
once
Conrad
and
I
get
happy
about
the
figure
we
can
I
think
we
can
probably
do
screw
and
immersions.
Unless
there's
any
comments
here.
D
Yes,
about
two
seconds
of
Silence,
first
yeah
I
think
it's
worth
noting
that.
As
you
said,
this
was
not
an
interrupt
problem
because
we
have
been
interrupting
for
a
while
around
that
part
of
the
spec.
D
A
Well,
we're
not
here
in
any
major
objections,
I'm
thinking
we
we
let
this
right,
Brandon
good.
E
Go
ahead:
oh
hi,
I
was
gonna.
Ask
if
there
was
any
concern
about
the
graph
being
too
wide
to
render
properly,
because
if
you
look
at
the
spec
rendered
as
like
a
just
text
document,
this
graph
is
about
twice
as
wide
as
basically
everything
else.
C
Yeah
in
the
HTML,
rendering
it
it
conveniently
shrinks
the
SVG
down
to
be
the
appropriate
width,
but
yeah
the
sex,
rendering
would
be
unhappy.
I,
don't
know,
I
might
fiddle
with
it.
Maybe
like
render
it
vertically.
So
it's
a
good
to
help
with
that.
B
C
I'm,
not
sure
I,
don't
think
it's
a
necessarily
a
deal
breaker
to
screw
up
the
texture
engine,
because
the
official,
the
official
thing
nowadays
is
XML
and
HTML.
So
I
don't
know
if
we'll
be
forbidden
from
publishing.
If
we
have
too,
why
not
too
wide
diet,
but
we
can
always
trim
it
back
to
one
or
two
epochs.
If
we
need
to
be
narrower.
A
F
A
Great
so
I
guess
what
we'll
do
is
we'll
basically
say
that
this
we
have
tentative
agreement
to
go
ahead
and
merge
this,
the
modulo,
the
two
of
you
making
sure
you
get
comfortable
with
the
graph
or
if
anybody
else
wants
to
chime
in.
C
C
So
then
I
think
that's
the
only
one
that
needed
discussion
on
the
protocol
draft
unless
anyone
else
wanted
to
look
at
any
of
those
other
issues.
F
F
Wow,
oh
there
it
is
yeah,
it's
844.
clean
up
after
playing
text
and
side
effects
from
naming
we'll
just
minor
stuff,
but
it's
names
of
labels.
So.
G
Hey
yeah
I
I've
had
a
problem
with
my
data
tracker
account
because
it
was
merged.
There
were
two
accounts
which
were
merged
and
so.
C
A
Let's,
so
we
just
got
through
two
on
the
we
did
855
and
844,
and
the
rest
of
them
are
I
think
all
just
kind
of
dealing
with
whatever
comments.
We
got
right,
reasonable.
G
Yeah,
if
you,
if
you
look
at
the
there's
one
you're
still
on
protocol
right,
yeah.
A
Yeah,
so
I
was
just
clarifying
that
we
did
a.
We
talked
about
a55
and
it
looks
good
to
go
long
as
Richard
and
Raphael
agree
to
the
figure
at
8.
44.
Conrad
said
don't
forget
about
this.
One
and
Richard
said
he
just
forgot
to
hit
the
button,
so
the
rest
of
them
are
all
I.
Think
between
844
and
855
are
all
basically
just
dealing
with
various
things
from
the
isg
review.
C
G
G
Okay,
so
with
let's
just
let's
just
start
with
182-
that's
the
bottom
one.
G
So
this
was
basically,
there
was
one
comment
about
there,
not
being
enough
explanation
of
what
is
in
of
what
these
various
terms
are
that
are
used
in
architecture
that
are
defined
in
protocol.
So
if
you
go
to
files
changed,
you
can
see.
I
initially
did
this
as
a
glossary.
Ecker
said
he
didn't
like
that:
I
rewrote
it
in
a
narrative,
style
and
I
liked
it
better
as
well
and
I
think
there
was
one
comment
by
by
Brita
about
how
we
want
to
how
we
want
to
describe
a
leaf
package.
G
G
G
H
The
only
reason
for
this
suggestion
is
that
come
implying
some
sort
of
time
scale
to
this,
so
that's
not
just
a
static
I
could
see
where
someone
could
read
the
spec
and
see
including
its
Leaf,
known
as
if
it
was
ecstatic
across
multiple
initiations
or
the
various
ways.
This
could
be
misinterpreted,
so
I
just
propose
that
we
have
some
sort
of
initiation
there.
Other
start
point.
C
G
Yeah
I
just
wanted
to
make
sure
that
it's
clear
like
that
someone.
It
doesn't
cause
more
questions
than
it
answers
if
other
people
think
that
that
looks
good,
then
I
will
I
will
go
ahead
and
make
that
make
that
change
and
and
I
need
some,
but
we'll
need
somebody
else
to
click
the
button.
A
G
Right
so
I
just
I
just
commit
I
just
committed.
G
G
Okay,
all
right,
so,
let's
move
to
183.
B
G
A
The
the
background
here
is
they
were,
we
were
getting
a
lot
of
bounces
and
I
always
get
a
lot
of
hate
mail
from
the
isg,
so
I,
basically
just
rummaged
through
my
emails
to
find
ones
that
were
were
fixable
and
fix
them.
That's
probably
past
the
point
of
pain,
but
I
think
we
should
go
ahead
and
fix
them
where
we
can.
G
E
A
G
Okay,
so
the
so
on
180th
on
183,
if
you
open
up
files
changed.
There
are
quite
a
few
quite
a
few
changes
in
here,
but
they
are
all
related
to
one
of
three
one
of
three
Ade
reviews
and
if
you'd
like
we
can,
we
can.
We
can
look
first
at
the
discusses
or
we
I
can
just
walk
through
these
one
at
a
time.
G
So
if
we
start
at
the
very
beginning
here,
there
was
a
comment
about
about
using
for
key
transparency,
about
having
a
reference
to
something
generic
and
so
Richard
recommended
this
paper
on
Connex
and
they're.
G
G
Then
we
can
skip.
Most
of
these
are
just
rewording,
changes.
There
was
a
question
about
the
scale
about
being
consistent
on
scale,
so
in
line
272
and
in
every
other
place,
I
used.
Tens
of
thousands
is
everybody.
Okay
with
that
scale
in
the
architecture
document.
D
Those
airports,
it
doesn't
work
at
all
so
you're,
going
back
to
the
intern
security.
That
would
actually
be
the
place
where,
ideally,
we
would
plug
in
this
ITF
definition
of
antenna
encryption
but
I
don't
think
I
can
finalized,
yet
the
one
from
Mallory
and
CPM.
D
Maybe
it
was
checking
it's
Sean
from
a
former
perspective.
We
cannot
reference
anything
that
is.
A
So
it
depends
if
it's
informational,
we
can
so
if
it's
a
if
it's
a
normative
reference
and
it's
informational
or
if
it's
a
normative
reference
and
it's
not
an
RFC,
then
we
have
to
wait
for
that
other
one
to
get
published.
But
if
it's
informational,
then
we
can
proceed.
A
D
Okay,
that's
a
good
point:
I'm
gonna
check
on
that
and
then
I
can
comment
on
the
pr
and
to
your
point,
Ron
the
we
have
this
number
of
50k
so
far,
I
think
it's
even
in
the
charter,
if
I
remember
correctly
and
it's
completely
arbitrary
I
think
John
Millican
made
it
up
at
the
time.
So
in
that
sense
there
is
no
no
good
reason
to
stick
to
that
particular
number.
A
As
we're
consistent
and
everybody
kind
of
agrees,
and
if
people
are
actually
already
testing
at
that
level,
then
I
think
you
know
the
proof's
in
the
pudding
so
to
speak.
D
And
yeah-
and
maybe
that's
a
good
occasion
to
settle
on
that
wording
in
general,
because
it's
something
that's
been
coming
back
as
a
question
for
years
now
like
how
many
like
how
big
can
a
group
be
with
MLS.
D
G
G
You
know
it,
everybody
I
think
everybody
is
comfortable
with
saying
that
we
want
to
do
at
least
that,
and
if
people
want
to
say
you
know,
this
is
what
we.
This
is
what
we
envision.
This
is
what
we
thought
of,
but
if
we're
going
to
go
bigger
than
that,
there's
probably
additional
they're,
almost
certainly
additional
things
that
we
would
need
to
do
that
are
not
in
the
protocol
yet,
but
we
could
add
them
yeah.
So
I
think
this
is
a
safe.
This
is
a
safe
place.
G
Just
says,
moving
on
line
308
public
key
infrastructure
was
trying
to
convey
that
this
was
answer
in
answer
to
a
question
about
what
are
various
servers,
so
various
servers
on
the
pka
context
would
be
existing
PKA
roles
like
a
certificate
Authority.
G
Please
stop
me
at
any
point.
If
I'm
you
know
skip
over
something,
that
is
that
someone
is
specifically
worried
about
442
is
where
I
changed.
The
link
from
the
some
expired
Google
key
transparency
project
to
this
paper
called
conics.
G
G
G
This
was
talking
about
the
security.
The
safety
of
the
users
of
MLS,
so
I
used
provide
both
performance
and
security,
EG
integrity
and
confidentiality
to
its
users.
F
A
Think
that
that's
that's
probably
a
better
description.
B
G
G
H
Was
this
to
clarify
that
internal
group
messages
versus
like
external
to
a
group
message
or
am
I
reading
more
into
this
and
intended
I.
G
Think
you're
reading
more
into
it.
It
was
that
people
who
said
that
they
wanted
to
have
you
know
that
they
were
trying
to
understand.
Are
you
sending
the
message
to
a
group?
Are
you
sending
users?
You
are
sending
it
to
you
to
individual
members,
they
didn't
really
understand
and
it's
as
like.
The
purpose
of
the
DS
is
to
deliver
messages
which
are
addressed
for
a
specific
group
and
send
them
to
the
individual
members.
That's
the
function
that
DDS
is
offering
and
that's
why
I
changed
the
article
because
they
were
confused.
G
All
right,
there's
another
little
minor
privacy
wording
change
in
1056
here,
MLS
is
designed
under
the
assumption.
The
transport
layer
is
present
to
keep
metadata
private
from
Network
Observers,
while
the
MLS
protocol
provides
confidentiality,
integrity
and
authentication
guarantees
for
the
application
data
which
could
pass
through
multiple
systems.
G
G
Okay,
hearing
no
objections
here:
okay
and
1099
changed
MLS
ciphertext
to
private
message
and
then
also
1102.
G
This
is
where
we're
talking
about
using
Anonymous
credentials
and
Roman
had
an
allergic
reaction
to
Anonymous
credentials,
because
it's
it's
not
defined,
except
in
a
U.S
government
document.
According
to
him,
so
I
put
use
credentials
uncorrelated
with
specific
users
to
help
prevent
dos
attacks
in
a
privacy,
preserving
manner.
Actually
I
think
somebody
asked
to
change
this
to
you
just
to
prevent
us
yeah
to
prevent
dust
attacks
in
a
privacy
preserving
manner.
I
G
That,
basically,
if
you,
if
you
don't
use,
if
there
are
no
credentials
required,
then
then
it's
easy
to
do
DOS
attacks,
because
you
can
claim
you
know
you
you
can
you
can
issue
as
many
requests
as
you
want,
but
if
you
use
credentials
in
order
to
authenticate
yourself,
then
you
can
do
limiting
of
the
number
of
requests
per
authenticated
user,
but
if,
but
that
can
reveal,
privacy
can
reveal
private
information.
G
So
if
you
use
anonymous
credentials,
then
you
get
the
property
that
it's
you
have
to
have
an
authentication
credential,
but
you
are
still
remaining
Anonymous.
So
in
this
case
this
is
credentials
which
are
uncorrelated
with
specific
users.
Is
the
property
that,
in
the
context
of
this,
the
section
that
comes
slightly
before
this.
G
So
if
you
click
there's
a
little
there's
a
little
blue
line
here,
hang
on
a
second
there's.
There
we
go
in
the
centralized
setting.
Dos
prevention
protection
can
typically
be
performed
by
using
tickets
or
cookies,
which
identify
users
to
a
service
for
a
certain
number
of
connections.
G
It's
a
little
weird
like
this
is
one
of
the
places
where
the
document
is
a
little
bit
weird,
because
we
have
where
you
know,
we
sort
of
talk
about
things
that
a
lot
of
folks
do
and
and
then
we
we
talk
about
about
adding
a
bunch
of
extra
privacy
protections
that
many
systems
do
not,
and
here
we're
talking
about.
You
know,
sort
of
trying
to
merge
those
two.
Those
two
needs
together
in
a
single
recommendation.
G
I
I
H
B
B
G
So
moving
down
to
deniability
line
1251.
G
So
we
have
we're
basically
saying
two
contradictory
things
in
the
same
paragraph.
So
roughly
speaking,
deniability
is
the
opposite
of
non-repeviation,
that
a
property
that
isn't
possible
approved
to
a
third
party,
then
Master
goes
set
by
a
given
sender,
so
I
reworded.
This
too
deniability
is
not
currently
provided
by
the
mrf
protocol,
but
the
protocol
avoids
constraints
that
would
make
it
impossible
to
add
deniability
properties
for
the
extensions
defining
the
specific
requirements
and
resulting
Notions
of
deniability
requires
further
analysis.
D
I
think,
plus
the
first
sentence
is
a
little
bit
problematic,
simply
because
I've
been
going
through
a
world
of
pain
regarding
the
ability.
So
it's
not
it's
not
clearly
defined.
What
deniability
actually
is,
and
so,
if
we
start
with
saying
deniability
is
not
currently
provided.
It
implies
that
there
is
a
crisp
definition
of
what
it
is,
whereas
before
it
was
a
lot
more
vague
and
that
worked
better.
C
C
D
G
Yeah
yeah
there's
a
there
were
actually
I
can
go
dig
out.
G
Why
don't
does
one
of
either
Raphael
or
Richard
do?
One
of
you
want
to
go
look
for
that
comment
while
I
carry
on
and
we
can
come
back
to
this
one.
C
G
Well,
check
Eric
Eric's
comments.
G
In
any
case,
I
can
revert
this
if
I
need
to
okay.
Most
of
these
next
ones
are
very.
D
I
assume
that
some
thought
has
gone
into
this
and
the
decision
was
made
not
to
provide
this
as
a
core
feature
actually
due
to
the
latest
usefulness
and
example:
even
the
court
system
or
log
messages,
deniable
or
not
are
recovered.
I
assume
it
was
not
easy
to
add
this
property
and
it
was
there
for
mostly
left
out
because,
of
course,
it
would
be
nicer
to
have
it
done
to
have
it,
but
I
also
vaguely
remember
Richard
replying
to
that
on
list.
D
D
Well,
I
think
there's
some
consensus,
at
least
for
the
beginning
of
the
change
and
let's
look
at
the
rest,
foreign.
A
G
G
Those
are
pretty
I
think
this
should
be
pretty
yeah,
pretty
easy
to
address.
Okay,
1462.
G
Recommendation
if
the
threat
model
of
the
system
is
against
an
adversary
that
can
access
the
messages
on
the
device
without
even
needing
to
attack
MLS,
the
application
should
delete
plain
text
messages
and
ciphertexts
immediately
after
encryption
or
decryption.
I
changed
this
to
as
soon
as
practical
after
encryption
or
decryption.
The
comment
was
they
basically
that
this
is
like?
You
know
you
decrypted
the
message
and
deleted
before
we
display
it
to
the
user.
You
know.
G
G
So
I
changed
this
to
not
note
that,
with
a
legal
request
to
ask
the
service
provider
for
the
push
token
associated
with
an
identifier,
it
is
easy
to
correlate
the
token,
with
a
second
request,
to
the
company
operating
the
push
notification
system
to
get
information
about
the
device
which
is
often
linked
with
the
real
identity.
Etc.
G
All
right,
moving
down
to
1619
Brendan,
suggested
changing,
centralized
server
to
Central
server
I
accepted
most
of
his
comments,
but
this
one
I
left,
as
is
because
there
are,
there,
were
at
least
half
a
dozen
or
more
references
uses
of
centralized
and
I
didn't
want
to
have
to
unnecessarily
go
back
and
change
all
of
them
and
make
sure
they
still
made
sense
any
any
heartbreak.
If
I
leave
it
as
centralized
Brendan.
E
G
I
think
I
can
just
just
not
add
it
in
it.
If
somebody
pushes
the
button
to
converge,
then
it
just
gets
merged,
even
though
that
wasn't
the
result.
Oh
resolve
conversation,
okay,
resolve
there.
Okay.
G
G
D
Wasn't
that
something
Ecker
chimed
in
on
on
the
list?
Also,
like
you
don't
need
to
do,
you
want
to
be
online
to
verify
online
these
days,
I'll
do
a
completely
misremember
that.
C
Yeah
or
what's
on
the
screen
right
now,
yeah
so
browsers.
Nowadays
they
sync
revocation
information
from
CA,
so
there
is
Network
traffic
at
some
point,
but
not
necessarily
at
verification
time.
E
And
also
like
to
comment
about
why
this
was
changed.
I
saw
it
earlier.
It
was
on
the
screen
from
Nat.
Was
it
says
that
this
can
be
performed
autonomously
in
the
ad
was
confused
about
the
meaning
of
autonomous
and
I?
Think
in
the
context
of
the
document,
autonomous
was
meant
to
mean
requiring
no
interaction
from
the
user,
because
the
sense
afterwards
is,
in
contrast,
you
can
require
the
user
to
have
to
do
something
to
verify
the
credential
or
you
can
use
like
x19,
which
doesn't
require
the
user,
interaction
and
I.
E
Think
that's
what
the
texture
should
have
been
updated
to
say
instead
of
saying,
x5n
doesn't
require
Network
traffic,
it
should
say:
x509
doesn't
require
user
action.
G
Sounds
good
to
me:
okay,
I
can
I
can
change.
That
I
was
under
the
impression
that
this
was
basically
in
regards
to
a
that.
They
were
looking
at
the
diagram
and
wondering
you
know
wondering
why
there
was
not
a
connection
of
some
line
between
the
client
and
the
as
for
verification
of
credentials.
G
I
do
I
do
not
recall,
but
since
it
was
only
a
comment,
I'm,
okay,
with
I'm,
okay,
with
leaving
that
out
and
I'm
also
okay,
with
changing
this
for
autonomously
EG.
Without
you
know,
without
additional
user,
without
a
user
interaction,
because
I
think
that
that
is
more
important.
A
Exactly
automatically
covers
it.
A
Yeah
I
think,
if
you,
if
you
take
Brennan's
I,
think
it
kind
of
addresses
all
the
points.
Okay,.
G
B
G
Okay
line
1700
key
transparency
was
mentioned
twice
in
two
different
recommendations
and
in
this
one
I
just
changed
it
to
provide
one
or
more
out
of
band
authentication
mechanisms
to
limit
the
impact
of
an
authentication,
Service
compromise
and
I
didn't
specify
key
transparency.
Are
you?
Okay,
with
that
Brendan.
G
All
right
and
then
last
one
1736
recommendation.
Instead
of
always
using
Cryptid
group
operation,
messages
to
limit
privacy,
risks,
I
said
use
encrypted
group
operation,
messages
to
limit
privacy
risks
whenever
possible,
and
that's
specifically
because
we
have
a
lot
of
people
who
are
who
are
using
encrypted.
You
know
unencrypted
group
operation
messages
for
for
legitimate
purposes
and
we
have
a
different
recommendation
that
says,
if
you
do,
that,
do
it
inside
of
an
encrypted
transport.
B
I
A
Nerds
is
to
James
certificate
authorities
to
certificate
certification
authorities.
G
Changed
awesome
all
right,
so
that's
the
pull
requests.
So
let's
go
going
back
to
the
issues.
I
think
that
this
substantially
deals
with.
Oh,
it
deals
with
all
of
the
discusses
those
two,
those
two
PRS
deal
with
all
of
the
discusses,
except
for
zahad
dusaman
sarker,.
G
And
so
he
has
a
discuss
for
whether
we
want
to
have
an
explicit
recommendation
for
using
secure
transport
for
MLS
I'm,
totally
comfortable
with
saying
that
when
you're
using
MLS,
you
should
just
you
know,
just
use
a
secure
transport,
but
we
have
other
places
where
we
basically
say
you
can
use
it.
G
What
you
know
we
don't
make
a
comment
about
that,
and-
and
we
only
say
you
know
the
only
the
only
thing
we
say
is
that
if
you
want
privacy
you
should
use
a
secure
transport
and
if
you're
using
unencrypted
handshakes,
you
should
use
a
secure
transport.
G
So
I
particularly
was
thinking
of
brita's
application.
Here
you
know
if
there's
I
don't
know,
if
anybody
has
any
heartburn
with
saying
you
know,
I
thought
that
just
saying
just
just
stick:
MLS
inside
of
TLS
or
or
quick
is
pretty
non-controversial
in
this
group,
but
I
didn't
know.
If
there
was
anybody
who
and
and
I
wasn't
also
really
sure
exactly
where
to
where
to
put
this.
H
Speaking,
we
have
some
applications
where
it
would
be
very
problematic
to
put
inside
of
TLS
or
quick
and
there's
various
other
solutions
for
trying
to
ensure
that
transport
I
think
part
of
this
issue.
Here,
we've
just
we've
described
what
we
mean
by
secure
transport.
I
went
back
to
other
doc
to
ensure
meaning
there,
because
we're
not
really
saying
it
providing
a
lot
of
security.
G
Yeah
so
I
guess
the
first
question
is:
do
you
care
if
the
architecture
document
says
you
know
in
general,
you
should
go
and
do
this
thing
you
don't
do
it
and
if
you
write
an
ITF
document
doing
something
different.
You
have
an
extra
paragraph
in
your
document
explaining
why
it's
safe
that
you
do
the
thing
differently
than
the
recommendation
and
architecture.
C
H
C
H
Yeah
I
think
if
we
were
saying
and
make
it
explicit
that
is
said
as
an
advisory
Note
versus
a
should
and
I
know
those
two
things
very
similar,
but
kids
are
actually
interpreted
more
broadly
as
a
this
is
fundamental
to
the
security
of
MLS,
and
that's
not
what
we're
really
saying
we're
saying
that
it's.
It
helps
improve
the
overall
security
and
it
also
gives
this
reliability
of
the
transport.
There's
two
different
properties
there
that
we're
getting
from
containing
it
inside
of
TLS
or
quick
or
something
one
is
the
meditating.
H
The
other
is
reliability,
and
if
we're
explicit
about
those
goals
and
say,
if
you
do
this
inside
of
TLS-
and
do
this
in
kind
of
quick,
then
you
get
the
properties
you're.
Looking
for
and
just
advise
that
that's
a
easy
solution,
then
I
think
it's
that's
probably
the
best
way
forward.
If
the
wording
sounds
like
this
should
be
done,
and
it's
recommended
as
the
main
way
forward,
then
I
think
we're
going
to
run
into
issues
because
then
it
kind
of
does
sound,
like
it's
locked
in
the
design
to
that
place.
G
A
Done
in
other
drafts,
where
it
says
you
could
use
secure
transport
example,
TLS
or,
and
then
what
you
have
in
the
next
sentence
is,
and
if
you
don't,
then
you
need
to
explain
what
it,
how
you
provide
these
features,
so
I
think
there's
a
way
out.
A
Foreign
basically
I
think
avoid
British
concern,
which
is
it's
basically.
If
the
document
basically
says
to
do
this,
you
got
to
do
one
of
these
two
transports
and
they
might
use
something
else.
That's
what
I'm,
what
I'm
inferring.
A
I
C
All
right
so
I'm
gonna
try
and
share
just
an
editor
window.
Oh
let's
see
if
this
works,
foreign.
D
C
So
like
that
would
be
my
Baseline
starting
point.
Would
you
rather
be
like
elaboration
you'd
want
to
put
on
top
of
that.
H
Would
suggest
a
slightly
rewarding
here,
maybe
that
we
should
use
for
one
clarification?
Maybe
you
secure
transports
that
provide
reliable
delivery
and
protect
metadata
whenever
possible,
such
as
input
the
TLs
or
quick
at
the
end
you're,
using
the
Ed
option
like
that,
before
I'm,
putting
it
less
front
and
center
as
those
are
the
distance
and
more
as
a
the
solution
needs
to
provide
these
things.
G
Great
okay-
and
we
and
of
course
before
you,
submit
this
as
a
real
PR,
we
need
it.
References
for
qls
and
quick
all
right.
B
C
G
G
So
MLS
is
designed
to
consider
the
following
threat
model
attacker
can
read,
write
and
delete
arbitrary
messages.
This
departs
from
most
threat
models,
because
blah
blah
blah
main
use
of
secure
transport
layer
is
to
provide
the
already
limited
amount
of
metadata.
Okay
after
that,
right
after
there.
B
B
G
G
B
A
Yeah
I
mean
like
at
the
end
of
the
day.
What's
gonna
happen,
is
we're
going
to
publish
and
they're
gonna
tell
us
whether
they
think
that
we've
done
it
or
not
right?
So
it's
it's.
If,
if
you,
you
know
if
this
was
your
first
rodeo
Rowan
I
might
be
a
little
worried,
but
it's
not
so
if
you
think
you're
you
think
we
addressed
them,
then
I'm
gonna
go
with
that
and
then
we'll
just
have
to
see
that
we've
addressed
them
to
the
satisfaction
of
the
people
that
all
the
discusses.
A
I
appreciate
you
guys
getting
through
this
so
quickly,
because,
typically,
what
happens
the
longer
you
wait,
the
more
vague
everyone's
memory
is
get
and
then
they
can't
remember
why
they
made
the
comments.
So
I
really
appreciate
you
guys
plowing
through
this.
G
A
A
All
right,
cool,
the
I
guess
what
I
wanna
that's
great,
it's
been
a
new
version.
Do
whatever
I
do
know
that
Nick
said
he
had
some
comments.
They
were
all
readability,
so
they're,
not
big
issues.
We
can,
you
know,
do
them
later
or
whatever
or
during
off.
48.
A
C
A
Sure
I'm
I've
I've
I've,
let
known
I've,
let
Nick
know
he
needs
to
get
them
in.
A
Yeah
so
I
guess
that
brings
this
to
a
close-up.
We
will
be
done
with
this.
If
not,
we
can
always
set
up
another
meeting
to
go
over
whatever's
left
if
something
comes
back
up,
I'm
hoping
I'm,
hoping
not,
but
apparently
these
apparently
these
two
drafts
brought
a
lot
of
interest,
so
I
think
that's
good,
actually
any
event.
A
Okay,
so
I
guess
I
have
an
administer
trivia
question
I
have
not
yet
requested
a
session
for
iatf
116
thinking
that
there
won't
be
a
a
lot
of
people
there
and
it
would
mostly
be
remote,
most
mostly
be
remote
participants,
and
if
we're
going
to
do
that
because
of
the
meeting
venue
and
scheduling
and
all
that
stuff
I'd
rather
just
have
an
interim.
A
D
I'm
I'm
gonna,
be
there
most
likely
at
least
for
some
of
it.
Maybe
Sean
you
can
explain
like
it
seems
that
we
are
pretty
much
at
the
end
of
the
process.
Now
like
what's
left
between
yes
and
an
RFC.
A
Yeah
so
basically,
after
these
documents
get,
you
know
formally
approved
by
the
isg
they're
essentially
put
in
the
RFC
What's
called
the
RC
editor's
queue,
and
then
what
happens
is
mostly
just
copy,
editing,
they're,
going
to
make
sure
that
we
did
our
references
right.
You
know
that
the
commas
are
in
the
right
place
like
they're,
going
to
do
a
lot
of
copy
editing
and
then
the
kind
of
document
goes
through
if
any
other
large
changes
get
proposed.
A
That
comes
back
to
the
working
group
and
we
can
make
those
changes
we'll
have
to
discuss
those
changes
before
we
put
them
in
the
document,
and
if
there
are
any
big
enough
changes,
we
have
to
start
this
whole
process
over
I.
Don't
think
there
will
be,
but
once
it's
in
the
RFC
editor's
queue
it'll
probably
take
two
to
three
months
before
it
pops
out
with
an
actual
RFC
number
and
at
the
end
is
the
editors.
All
you
really
need
to
do
is
like
start
reading
your
email.
A
G
So
there
are
two
things
that
I
want
to
bring
up.
The
first
is
that
two
to
three
months
in
the
RC
editor
queue
is
not
going
to
happen,
because
we
have
a
dependency
on
MLS
extensions
in
for
architecture.
G
So
I
think
that
if
for
no
other
reason
than
to
demonstrate
that
we
are
still
that
we
are
not
a
moribund
group,
if
everybody
for
transparency
that
we
should
request
a
meeting
and
talk
about
MLS
extensions
just
so
that
we
have
the
you
know
the
minimal
process,
you
know
place
where
somebody
can
come
and
ask
questions
they
can
find
out.
Who
you
know
there
will
be
people
there,
there
will
be
Outsiders.
This
is.
G
This
is
a
useful
thing
for
Outsiders
to
be
able
to
come
and
find
out
about
MLS
and
at
the
end
of
this
month,
there's
going
to
be
a
workshop
on
the
digital
Market
markets,
Act,
where
people
are
going
to
be
talking
about
interoperability
in
MLS,
and
things
like
that
and
they're
going
to
be
a
lot.
There's
going
to
be
a
lot
of
sort
of
Outsider
interest,
we
need
a
place
where
people
can
find
us
in
that
way.
Who
are
not
the
people
that
normally
attend?
These
calls.
G
D
A
D
A
Go
ahead,
Sean
I
was
just
going
to
say
that
I
do.
If
extensions
is
not
normative,
it
can
it'll
be.
It
won't
have
to
get
stuck.
D
Well,
that's
actually
a
good
question.
I
mean
right
now:
it's
information,
yeah.
A
They're
informational,
so
if
it
goes
in
the
RCA
I
just
keep
rolling,
it
will
get
published
with
an
informational
reference
to
a
non-standards
track
document.
D
That's
doable,
but
the
question
is
whether
we
want
that
in
the
long
run,
for
extensions
to
only
be
informational.
Is
that
a
decision
we
have
to
take
now
or
can
we
like?
Can
we
leave
it
as
informational
for
for
the
time
being
and
then
make
it
normative?
We.
C
The
whole
purpose-
there's
there's
two
informational,
informative
things
running
around
here.
The
document
can
be
standards
track.
The
critical
thing
for
the
blocking
at
the
our
theater
level
is
whether
it
be
reference
from
the
architectures.
The
extensions
is
a
normative
reference
and.
C
D
So
yeah,
maybe
to
give
some
perspective
on
that.
There's
been
some
low-key
I've
heard,
with
royal
and
Marta
regarding
Conrad
and
I
regarding
the
extensions
document
to
come
up
with
yeah,
some
at
very
some
guidelines
on
how
to
develop
new
extensions
so
that
they're
safe
and
then
they
don't
jeopardize
the
core
protocol
Etc.
So
that's
still
ongoing
and
it's
obviously
going
to
be
a
while
and
the
document
is,
is
going
to
be
open
for
a
while.
D
So
yeah
just
wanted
to
give
you
that
perspective,
also,
not
something
that
we
need
to
discuss
at
or
present
actually
at
ipf
117,
that's
probably
going
to
be
too
early.
So
aside
from
what
Ron
brought
up
I
think
another
for
the
protocol,
all
the
extensions
or
the
Federation
documents
for
that
matter.
G
A
So
it's
it's
no
skin
off
my
nose.
It's
one
button
and
I'm
already
going
to
be
there
it'd
be
great
if
more
than
three
people
showed
up
in
person,
but
so
I'll
I'll
leave
it
to
the
group,
because
I
I
know
that
I
don't
think
Richard's
gonna,
be
there.
Raphael
I
think
you're
going
to
be
there,
but
only.
D
Exactly
that's
the
thing
so
there's
still
like
one
hour
and
a
half
apart,
the
two
venues
so
I
can
try
to
be
there,
but
no
guarantee.
A
Oh
I
can
definitely
do
that.
I
can
swing.
They'll
they'll,
probably
love
that
actually,
so
all
right
so
I
mean
unless
I'm
hearing
any
violent
objections.
I
don't
really
have
a
problem
putting
in
in
our
request
and
they'll
Friday,
and
it
will
be
probably
Friday
afternoon,
but
it
it'll
it'll
work.
Yeah.
A
Okay,
I'll
go
in
I'll,
go
ahead
and
do
that
then-
and
you
know
just
be
I-
guess
Raphael.
The
thing
is
that
we
just
have
to
make.
We
have
some
presentations
or
Rowan
you're
gonna
have
to
do
it
yourself
to
carry
the
weight.
So
that's
fine,
that's
fine!
That's
what
I
figured
all
right!
All
right,
cool
I
will
go
ahead
and
put
that
in
and
I
think
that
might
be
it
for
today.
Unless
anybody
has
anything
else.
G
I
have
one
more
thing
which
I
so
we
did
not
address
the
comments
from
the
art
area,
on
an
architecture
and
so
I
think
that
those
are
those
are
worth
having
a
quick
look
at.
So
there
are
three
issues:
right
extensibility.
G
G
I
think
this
will
this
will
come
out
in
Mimi
when
we
start
to
propose
a
specific
MLS
profile,
but
I
think
we
do
want
to
get
ahead
of
this
at
some
point,
and
so,
if
anyone
would
like
to
collaborate
on
a
doc
on
a
draft,
a
non-working
group
draft
about
this
I
would
be
happy
to
do
this
for
the
for
in
the
next
80
up
and
then.
G
Finally,
the
the
inability
of
a
client
to
remove
itself
I
was
waiting
for
basically
us
to
get
isg
approval,
but
I
talked
with
Richard
about
some
ideas
of
how
to
improve
client
removal,
because
it's
it
really
is
a
pain
in
the
butt
it's.
It
is
like
not
it's
not
a
great
thing
that
the
protocol
is
it's
so
hard
to
remove
yourself.
C
G
G
If
somebody
disagrees
and
thinks
that
we
should
stick
this
in
the
architecture
that
we
should
talk
about
these
in
the
architecture,
document
I
could
go
and
do
three
separate
PRS
on
these
or
two.
You
know
if
you
have
specific
one
or
two
of
these
that
you
think
are
important.
I
could
do
a
PR
for
them.
G
So
yeah
like
say
you
know,
speak,
speak
now
or
send
me
an
email
in
the
next
week
or
two.
If
somebody
thinks
we
need
a
PR
for
these
for
for
architecture,
but
FYI.
A
G
Yeah
I
mean
I
I
am
I
was
shocked
that
this
that
these
did
not
come
up
as
as
discusses,
and
also
very
grateful.
A
She's,
not
she's,
not
new,
all
right
cool,
so
I
think
what
we're
gonna
do
is
we're
gonna.
The
way
I
would
probably
try
to
address
is
that
we,
you
know
collectively,
don't
think
they
need
to
be
specifically
addressed
here
in
the
architecture
document,
but
they're
that
it's
given
us
food
for
thought
for
other
documents.
A
Okay,
that
brings
us
to
a
close
thank
you
Richard
for
taking
notes.
Thank
you
for
authors
and
everyone
who
showed
up
at
early
and
late
times
to
get
this
done
again.
Thanks
for
your
continued
efforts,
and
hopefully
we'll
get
this
all
knocked
out
and
get
this
approved
announcement
sent
as
soon
as
possible.
Awesome
all.