►
From YouTube: IETF109-SFRAME-20201117-0900
Description
SFRAME meeting session at IETF109
2020/11/17 0900
https://datatracker.ietf.org/meeting/109/proceedings/
A
B
I'm
bobo
co-chair
here
with
martin
nice
to
see
everybody
and
thank
you
for
joining
us
thanks.
Martin.
A
Yeah,
so
here's
the
note
well,
I
think
everyone
should
be
familiar
with
this
one,
we're
being
recorded
this
time.
So
don't
say
anything
you
wouldn't
say
to
someone
else,
and
this
is
our
agenda
today-
we're
not
going
to
get
a
presentation
from
dr
alex,
who
didn't
give
me
any
slides
when
I
asked
for
them-
and
let's
say
it
doesn't
seem
to
be
online
anyway.
So
that's
fine
and
I'll
probably
put
emad's
presentation
together,
because
I
got
one
deck
and
that
means
can
take
the
first
first
use
cases
slot.
A
B
Yeah
sure
that
sounds
great
so
since,
as
martin
said,
since
this
is
our
first
meeting,
we
wanted
to
take
some
time
to
go
over
the
charter,
for
this
working
group
set
some
context
and,
of
course,
get
any
feedback
from
folks
here
that
have
any
to
share.
B
So
with
that
being
said,
the
primary
goal
for
s-frame
is
to
respond
to
the
growing
need
for
end-to-end
encryption
for
real-time
conferencing
sessions.
We
want
to
achieve
this
in
a
way
that
is
separated
from
the
transport
layer
and
will
have
exposed,
but
authenticated
media
metadata.
That's
useful
for
sfus,
also
known
as
rtp
switches.
B
And
so
the
the
goal
here
and
just
a
gentle
reminder
on
meeting
etiquette.
If
you
want
to
talk,
please
press
the
raise
hand
button
and
that
will
add
you
to
a
queue
that
martin
will
manage.
B
So
the
goal
here
is
to
define
a
secure
encapsulation
to
provide
authenticated
encryption
for
real-time
media
content,
independent
of
the
underlying
transport.
If
you
go
to
the
next
slide,
please
martin.
B
So
this
is
obviously
a
very
interesting
space
with
a
lot
of
interaction,
so
we
thought
it
would
be
useful
to
review
what
we
feel
is
in
and
out
of
scope
in
order
to
maintain
focus.
So
for
us.
In
this
working
group,
we've
set
out
of
scope.
B
The
motivation
here
is
that
these
webrtc
changes
in
particular
will
be
addressed
by
a
different
working
group.
The
avt
core
working
group,
so
they're
out
of
scope
for
us
go
to
the
next
slide.
Please,
martin
in
scope
for
us
are
to
define
guidance
for
how
s
frame
interacts
with
rtp,
especially
with
regards
to
packetization,
de-packetization
and
recovery
algorithms.
B
Martin,
finally,
we
anticipate
that
several
use
cases
of
s
frame
will
involve
its
use
in
contexts
where
keys
are
derived
from
an
mls
group
key
exchange
protocol.
So
we
consider
in
scope
defining
a
mechanism
for
doing
s-frame
encryption
using
these
keys,
but
obviously
this
does
not
preclude
other
sources
of
key
material.
B
Next
slide,
please
martin,
so
some
interesting
sort
of
details
about
the
encapsulation
and
what
we
hope
to
achieve,
as
we
mentioned
in
the
primary
goals,
slide
we'd
like
this
to
be
transport
independent,
so
it
can
be
applied
at
a
higher
level
than
individual
rtp
payloads.
B
And
what
this
lets
us
do
is
it
means
we
could
have,
for
example,
application
at
multi-packet
frames,
so
encrypting
entire
frames
that
span
more
than
one
packet
lets
us
amortize,
framing
and
authentication
tag
overhead
or
you
could
choose
to
encrypt
at
a
unit
of
intermediate
size,
for
example,
nalus
or
obuz,
to
allow
partial
frames
to
be
usable,
and
these
granularity
levels
are
to
be
determined
by
the
working
group
for
what
can
be
selected
in
the
protocol
next
slide.
Please.
B
Next
slide,
please,
martin,
there's
still
things
that
the
application
that
is
making
use
of
s
frame
has
to
declare,
for
example,
selecting
whether
s
frame
is
to
be
used
for
a
given
media
flow
specifying
which
encryption
algorithm
should
be
used,
provisioning
keys
and
key
identifiers
to
end
points
and
selecting
the
granularity
at
which
s-frame
encryption
is
applied,
if,
indeed,
multiple
options
end
up
being
available
next
slide.
Please
martin.
B
A
A
That's
an
amateur
move
on
my
part.
No,
there
was
not
pick
up
thanks
richard.
D
We're
also
get
I'm
also
seeing
the
chat
bernardo
but
cj
having
trouble
hearing
things.
So
I
don't
know
what's
going
on
there,
but
perhaps
you
have
a
bug
of
some
kind.
E
Okay,
so
we
started
looking
at
implementing
stream
browsers
and
we
we
come
to
some.
We
we
had
some
thoughts
and
questions
so
here
they
are
next
slide.
E
So
we
started
discussing
that,
and
there
are
clearly
some
advantages
to
native
implementations
like
javascript
does
not
need
real
access
to
media
content
it
if
it's
native,
if
that
frame
is
implemented
in
native,
you
no
longer
need
to
have
real
access
to
encryption
material,
which
is
a
nice
property
as
well,
and
in
addition
to
that
browsers,
if
they're
implementing
that
natively
can
apply
further
protection,
so
they
can
keep
control,
of
which
algorithms
to
use
which
might
be
good
in
the
future.
E
The
s
frame
transform
out
of
process
which
would
make
it
closer
to
something
like
ea
me,
for
instance,
and
also
there
was
this
proposal
called
isolated
streams,
which
is
a
way
for
the
javascript
to
never
get
access
to
varroa
media
content,
in
which
case
a
natives
transform
can
still
be
able
to
consume
such
protected
streams
as
well
as
produce
these
the
same
streams
so
based
on
those
discussions.
At
the
last
webrtc
meeting,
the
consensus
was
to
define
a
native
s-frame
transform
that
integrates
with
webrtc
for
audio
and
video
next
slide.
E
It
would
also
gather
the
keys,
generate
the
keys
and
set
up
the
give
the
keys
to
the
stream
transform
and
that
that
is
providing
some
good
level
of
security,
as
well
as
some
ease
of
use
from
for
web
developers
in
the
future.
E
It
could
also
be
used
with
a
native
key
manager
based
on
mls,
for
instance,
so
in
that
case
the
key
manager
would
generate
the
encryption,
keys
and
javascript
would
be
responsible
to
do
the
setup
of
the
pipeline
and
hand
over
the
keys
to
the
stream
transform
I'm
saying
in
the
future,
because
native
key
manager,
standardization
could
be
done
in
parallel
or
but
we
can
start
sooner.
The
sram
transform
some
deletion.
E
So
that
does
not
preclude
use
outside
of
webrtc,
though,
for
instance
with
data
channel
or
websocket.
I
saw
in
the
charter
that
s
frame
is
mostly
targeted
at
sfus
and
that's
another
question
I
will
have
at
the
end
of
the
presentation,
which
is
whether
we
should
scope
it
that
way
as
well
in
the
web
or
whether
we
we
should
anticipate
that
it
might
be
used
elsewhere
next
slide.
E
So
we
started
to
work
on
implementing
that
and
very
quickly.
There
were
obvious
issues
with
implementing
ads
frame
compatibly
with
sfus
or
even
existing
browsers,
especially
when
with
video
content.
E
E
One
alternative
that
is
mentioned
in
the
s
frame
draft
is
to
have
a
generic
packetization,
which
seems
nice.
An
alternative
would
be
like
to
try
to
do
a
post
transform,
but
that
would
be
code
specific,
so
it's
not
really
appealing,
but
anyway
it
should
be
mentioned.
E
So
I
wouldn't.
I
would
I'd
like
to
mention
that
the
generic
practicalization
might
be
useful
outside
of
this
frame,
because
the
in
several
instantable
streams
api
is
allowing
to
transform
and
create
content
before
going
to
the
network.
So
instable
streams
is
very
generic
and
might
also
need
to
use,
in
some
cases,
generic
practicalization,
so
that,
but
some
that's
something
to
keep
in
mind.
E
So
my
understanding
is
based
on
the
charter
that
I
that
was
described,
but
it's
not
an
activity
that
this
working
group
should
do
and
that
avt
core
should
do
it.
So
my
first
question
to
a
working
group
is
if
anyone
there
is
interested
in
if
anyone
is
working
on
it
or
if
anyone
is,
has
started
that
effort
already,
because
we
would
like
to
to
help
them
as
well.
F
Yeah,
so
I'm
very
interested
in
helping
with
that.
So
what
we
have
done
in
google,
we
used
some
version
of
vb8
packetization
initial
version,
which
seems
to
be
generic
enough,
but
yeah,
I'm
definitely
interested
in
helping
like
define
a
standard.
Generic
bacteria
format.
F
Yeah
so
yeah
and
searchable
stream
gives
the
possibility
to
do
anything.
You
would
think
would
for
him
right
now
that
use
case.
We
have
this
for
its
encryption,
but
could
be
other
use
cases
to
use
the
generic
optimization,
because
once
you
have
encoded
frequent
whatever
you
want
with
it
so
yeah
in
in
two
of
my
mind,
yes,
but
do
you
have
a
specific
use
case
we
we
can
discuss?
I
don't
have
something
specific
other
than
encryption
right
now:
okay,.
G
Thank
you
hi.
Can
you
hear
me
yes
good
so
I
mean
obviously
a
generic
packetization
can
be
defined
and
and
probably
fairly
easily.
It's
probably
something
for
the
avt
core
working
group.
If
it's,
if
it's
for
rtp
depends
how
how
this
is
being
done.
The
the
reason
we
haven't
defined
this
in
the
past
is
obviously
that
it
has
implications
for
the
robustness
and
if
you
just
chop
the
packets
arbitrarily,
then
you
know
you,
you
get
less
good
performance
in
the
case
of
loss,
so
I
think.
G
A
H
I
mean
it
is
not
I
mean
it
does
not
allow,
for
example,
partial
decodability
yet,
but
it
is
not
something
that,
for
example,
we
rtc
we
are
supporting.
So
probably
it
is
important
for
some
people,
but
at
least
for
webrtc
is,
does
not
seem
to
be
the
case,
but
anyway
we
will.
I
I
have
later
on
a
a
full
essay
presentation
on
on
video
formats
and
packet
testers,
so
we
can
try
to
to
move
the
discussion
for
later.
I
Yeah,
I
don't
know
if
this
is
going
to
get
answered
in
much
as
sergio's
just
mentioned,
but
just
to
be
clear.
This
generic
packetization
is
on
top
of
the
existing
packetization
for
the
codec
or
it
replaces
it.
H
I
don't
think
this
is
the
best
way
to
do
I
mean
if
we
can
have
something
that
we
work
with
all
codes,
and
we
don't
have
to
make
much
worth
recording
is
better.
I
mean
you
have
to
find
something,
and
then
you
have
to
redefine
it
or
how
it
does
it
apply
to
each
of
the
different
codex
past
and
future
is
like
having
a
specific
packetization
for
each
one.
C
Yeah,
I
think,
there's
a
trade-off
here
between,
as
scotland
pointed
out,
resiliency
features
and
alignment
with
the
codec
and
the
generality
you're
pointing
out.
I
think
the
question
for
this
group
is
how
we
navigate
that
and
get
the
right
level
of
flexibility
while
also
getting
these
reversals
properties.
C
I
would
also
wonder
at
what
level
we
need
to
define
that,
like
whether
the
s
frame
framing
could
be
defined
at
a
reasonably
generic
level,
and
then
map
to
different
packetization
schemes
is
appropriate.
J
Justin
wanted
to
comment
to
that
that,
like
I'm
not
sure
there
really
is
a
tension
here
between
resilience,
and
you
know
the
actual
frame
approach
it
comes
down
to
what
we
consider
to
be
our
independent
unit,
our
our
frame
per
se-
and
you
know
with
you,
know,
h.264.
J
You
know
you
can
have
like
a
frame
split
into.
You
know
two
different
slices
with
vp9.
You
can
have
it
split
into
different
tiles.
You
know
we
could
estrogen
could
be
applied
either
at
the
entire
frame
level
or
at
the
slice
slash
tile
level.
So
you
can
retain
some
of
the
resilience
benefits
you
get
from
slicing
or
tiling,
even
when
using
s-frame
a
small
trade-off
of
efficiency.
Because
you
have
then
you
know
multiple
encryptions
and
multiple
signatures,
but
I
think
we
can
retain
the
benefits
of
those
types
of
approaches,
even
when
using
s-frame.
E
J
Well,
we
explicitly
considered
you
know
supporting
tiles
when
we
designed
this
frame.
You
know,
I
don't
know
if
we,
if
that
is,
that
capability
is
actually
used.
You
know
in
the
implementation
to
date.
You
know
I,
I
would
probably
know
better
right
now,
but
we
we
explicitly
consider
this
and,
like
you
know,
I
I
think
it
should.
It
would
just
be
an
implementation
detail.
K
Yes,
so
as
an
individual
there,
I
I
think
what
colin
is
talking
about
robustness.
Is
that
actually
it's
about
how
to
map
to
a
large
degree,
you're
mapping
it
to
what
you
consider
in
rtps
streams
and
ssrs
etc,
and
that's
where
because
it
really?
I
don't
expect
most
of
you
to
do
this
really
stupid
trick,
but
I
mean,
if
you
leave
it
completely
open
people
are
going
to
shovel
multiple
codecs
into
one
structure
and
then
send
it
to
one
rtp
stream,
and
that's,
of
course,
has
implications.
K
So
I
think
that's
where
I
was
pushing
on
the
charging
stage
to
actually
try
to
get
this
description
and
especially
with
the
scalable,
codecs,
etc,
and
how
you
do
handle
those
substreams.
I
think
that's
where
a
large
part
of
this
discussion
is
needs
to
be
going.
That's
one
aspect
of
this.
The
other
is
okay.
What's
the
generic
meta
information
that
goes
on
the
side,
combined
with
that,
so
you
get
the
balance
between
what's
how
you
structure,
media
and
keep
track
of
its
timelines
and
then
relative
to
each
other,
etc.
A
M
L
A
Okay,
thanks
everyone.
Hopefully
we
have
some
notes
on
that
one,
and
we
can
continue
this
one.
When
we
talk
about
this
later,
you
and
you
want
to
continue
the
presentation.
E
Yeah
next
slide,
or
maybe
you
should
skip
it
actually,
because
it's
really
like
okay,
I
have
two
additional
questions
related
to
s-frame.
One
is
about
authentication
signatures,
so
as
an
as
I
understand
it,
the
goal
is
to
validate,
but
receive
content
is
actually
coming
from
a
given
user
from
the
rtp
stream.
E
That
sounds
like
a
good
idea,
but
when
trying
to
think
about
implementing
it
browser,
it
appears
quite
difficult.
It's
really
up
to
the
application
to
decide
what
to
do
when
signature
verification
fails
and
there
could
be
potential
breakage
with
network
intermediaries,
there's
additional
buffering
or
delay
requirements
that
are
not
easy
to
handle
well
as
well
in
browsers.
E
C
Yeah
richard
just
some
quick
feedback
is
this:
if
the
concern
here
is
purely
denial
of
service,
then
I
think
I'm
not
real
concerned.
If
it's
about
confidentiality
or
authenticity,
then
I
think
yeah.
We
would
consider
the
sfu
part
of
the
threat
model.
That's
kind
of
the
point
of
doing
this,
but
if
it's,
if
we're
just
worried
about
on
the
sfu
dropping
packets,
maybe
we'd
be
worried
about
revealing
more
information
to
them.
But
I
I
don't
think
that's
that
seems
pretty
secondary
in
any
case.
F
Yeah,
so
I
guess
the
third
model
was
mainly
malicious
user
impersonation,
like
someone
in
the
call
and
pursuing
some
another
another
person
in
the
call-
and
I
actually
had
the
exact
same
slide
in
my
presentation,
asking
document.
What's
the
signature
scheme,
should
we
sign
or
should
not
sign
because
in
the
current
respect
right
now
it's
basically
hand
wavy,
it's
very
complex
and
we
don't
have
an
idea
solution
for
it,
so
I
was
going
basically
to
suggest.
F
A
D
The
I
think
we
should
drop
this,
the
I
mean
it's
essentially
very
hard
to
do
with
any
reasonable
performance,
and
you
know
absent
like
so.
I
think
there's
like
there's
like
that.
D
You
know
it
depends
on
your
model
of
the
application,
but
if
you're
like,
while
the
application
is
like
the
dumb
version
where
there's
like
it
was
basically
like,
you
know,
like
a
single
monolithic
conferencing
system,
like
the
one
we're
on
here,
for
instance,
then
you
know
signatures
don't
actually
help
because
the
because
that,
because
that
what
it
shows
you
but
who's
speaking,
is
like
entirely
controlled
by
this
of
you
anyway,
at
least
for
rtc.
D
So
you
know
so
I
think,
like
you
know,
do
we
have
like
a
sort
of
much
saying
much
more
like
isolated
streams
and
an
identity
that
kind
of
thing.
I
don't
think
that
this
is
gonna
like
work
very
well,
and
so
I
think,
like
we
should
punt
that
put
this
until
we're
like
further,
along
with
the
rest
of
the
sir,
I
still
cook.
H
Yeah,
I
don't
think
that
we
should
drop
it.
I
mean
nothing
is
an
interesting
feature.
I
don't
know
how
complex
well.
I
know
that
it
is
complex
to
implement.
I
don't
know
if
it
is
enough,
but
I
don't
think
that
we
should
just
say
that
we
will
not
have
to
implement
it.
I
think
it's
a
very
nice
feature
and
it
is
something
that,
from
the
application
level,
I
would
like
to
have
it.
H
H
H
A
D
Question
is
the
crypto
to
make
this
work
in
a
like,
meaningful
way
that
doesn't
like
involve
like
it's
enormous
on
a
crypto
or
worrying
about
a
lot
of
packet
drops
as.
A
F
Yeah
I
want
to
just
take
what
eckhart
said:
it's
not
only
about
complexity.
It's
the
current.
The
car.
What's
in
the
expects,
is
not
complete.
It's
broken,
so
my
suggestion
for
removing
removing
until
we
have
a
complete
solution,
I'm
fine
getting
back
once
we
have
a
full
working
solutions,
but
as
of
today,
it's
it's
broken.
I
H
And
sergio,
I
also
remember
that
is
there
are
other
use
cases
that
are
not
broken
based.
I
mean
this
can
be
implemented
in
native
applications
and
we
have
clients
that
are
already
implementing
this,
and
this
is
a
feature
that
it
is
a
required
for
them.
I
mean
again,
I
am
I
don't
if
I'm
not
going
to
start
to
go
into
the
crypt
of
the
details,
but
if,
from
a
future
perspective,
it's
something
that
is
really
important.
A
C
Yeah,
I
think
my
biases
are
broadly
in
the
same
direction
as
accurately
mad,
but,
like
tim
said,
I
think
this
this.
This
is
an
area
where
I
think
we
understand
the
implications
for
conferencing,
but
there
are
other
use
cases
to
have
in
mind
here
and
so
I'd
like
to
understand
those
use
cases
as
well.
A
Okay,
so
what
I'm?
What
I'm
hearing
here
is
that
there's
some
question
mark
over
this
one,
but
let's
get
back
to
this,
when
we
start
talking
about
the
s
frame
draft
itself,
you
and
do
you-
have
much
left.
E
Just
one
question:
the
last
slide
is
it's
frame,
so
webrtc
is
surely
about
audio
and
video,
but
it's
also
about
data
channel
and
there's
also
like
website
webtransport
data
channel
can
be
used
to
transmit
real-time
data.
It
can
be
subtitles
anything
right
really.
So
my
question
is:
is
that
frame?
E
I
Tim
yeah,
I
think,
fairly.
Obviously
the
answer
to
that
from
my
perspective
is
yes,
I
think,
there's
some
very
interesting
things
you
could
do
with
with
having
encryption
an
extra
encryption
layer
on
the
data
channel
over
kind
of
multiplayer
games
and
things
like
that.
D
I
get,
I
guess
the
answer
is
I
don't
know
I
mean
I.
I
agree
with
him
that,
having
you
know,
multiple
observation
things
up
with
fair
games
is
interesting,
but
it
seems
like
all
the
data
is
like
being
sourced
by
javascript
and
so
and
so
like.
Why
not
just
do
that
crypto
in
javascript
before
you
shuff
it
down
this
before
you
shut
down
the
data
channel,
so
I
think
I
have
to
understand
like
what
the
threat
model
was
and
what
you're
trying
to
accomplish
before.
D
D
J
I
agree
with
eric.
It
seems
like
there
could
be
a
lot
of
interesting
things
here,
like
you
know,
there's
plenty
of
applications
that
are
offering
end-to-end
encryption
in
the
browser
for
text
messaging
and
similar
things,
and
at
least
would
benefit
from
having,
like
some
sort
of
you
know
place
where
the
actual
cryptography
is
being
done
inside
a
secure.
You
know
environment,
but
I
don't
know
how
you
solve
this
sort
of
issue
with
like
the
actual
input.
You
know
it's
still
back
in
the
untrusted
domain.
J
It
seems
like
if
you've
at
least
solved
the
crypto
part
of
it
then
you're
only
halfway
closer
to
that.
You
know
final
solution
and
it
seems,
like
you
know,
given
the
amount
of
usage
that
people
have
of
communicating
over
just
text
like
there
would
be
a
lot
of
value
if
you're
actually
come
up
with
some
form
of
solution
here.
So
I
I
think
we
probably
in
terms
of
like
our
use
cases
they'll
be
pretty
far
down
the
list,
because
it's
a
lot
more
complexity.
J
O
I
mean,
I
think
I
kind
of
feel
like
do
you
use
it
with
data
channel
as
the
wrong
level
of
question.
I
mean
it's,
you
know,
do
you
want
to
apply
it
to
things
other
than
audio
and
video
is
one
question,
and
you
know
that
maybe
then
the
answer
is
maybe
I
don't
know,
but
you
know
I
think,
that's
that
over
data
channel
on
our
website
transport,
you
know,
carrier
pigeons,
it's
sort
of
a
sep
is
a
separate.
O
Not
that
interesting
question
I
mean
I
think
that
there's
for
the
audio
and
video
creators
there's
also
interesting
things
like
you
know.
Maybe
you
want
to
do
s
frame
over
hls.
That
sounds
like
it
might
be
an
interesting
thing
to
do
in
some
use
cases,
but
that's.
I
think
that
what
you're
transporting
it
over
is
kind
of
not
the
right
level
of
question.
P
I
think
the
same
problems
that
we
have
with
audio
and
video
would
be
much
much
worse
with
data
channels,
because,
just
just
like
the
packaging
issue
raised
earlier,
the
sfu
is
doing
a
function
and
for
it
to
do
that
function
it
needs
to.
It
needs
to
see
some
part
of
these
frames
and
so
the
data
channels,
if
you,
if
you're,
just
taking
it
as
like
an
opaque
thing
that
you're
that
you're
trying
to
forward
around
then
you
still
need
some
sort
of
information.
P
You
know
to
the
sfu
about
why
each
of
these
data
channel
messages.
So
you
know
the
problems
with
packetization
audio
and
video
would
be
even
more
difficult
with
data
channels
because
they
can't
just
be
treated
as
opaque
blobs.
Otherwise,
what
is
sfp
really
doing
with
them?.
A
Okay,
thanks
john,
I
think
that's
the
presentation
you're
up
next
and
we're
talking
e
to
e.
F
I
guess
I'm
not
going
to
use
mostly
because
chairs
already
covered
overview,
remind
everyone
of
the
protocol.
I
might
jump
directly
into
site
number
five
in
the
format
yeah,
so
I
want
to
remind
everyone
with
the
wire
format,
because
I
hear
those
confusion
about
key
id.
So
this
is
basically
the
wire
format
of
encrypted
frames,
the
frame
which
has
encryption
header.
It
has
a
frame
counter
key
id
and
that's
the
end
of
ventilation
text.
So
one
thing
to
facilitate
here:
the
key
id
is
the
user
key
id.
F
A
F
Slide
so
the
first
one
I
want
to
talk
about
is
dependency
change
in
the
mobile
rtc
other
overclocking
groups,
what
they
need
to
define
for
forester
frames,
so
there
are
main
things
here
is,
as
everyone
mentioned,
signaling,
as
a
frame
like
other,
is
give
your
other
auto
plan
mechanism
we're
going
to
use
this
frame.
Then
we
need
to
find
a
new
pillow
type
for
encrypted
frames,
and
the
last
thing
is:
we
need
a
generic
rtb
header
extensions
that
holds
the
metadata
and
blendtec.
F
So
if
you
can
continue
to
work,
this
needs
to
force
them
between
the
beginning
of
the
frame,
the
end
of
the
frame,
all
other
frames-
data
like
resolution
volume,
level,
etcetera,
etcetera.
F
Okay
back
to
what
you
want
said
about
signatures,
so
to
be
clear,
I'm
I'm
saying
what's
what's
in
the
current
document
is
not
complete
as
an
example,
it
doesn't
define
how
often
the
signature
frame
should
be
sent.
What
happens
if
the
signature
packet
itself
is
lost?
F
Does
it
have
a
repair
mechanism
or
not
what
if
the
recipient
doesn't
receive
a
signature
bag,
it
should
chill
its
request
or
shouldn't
drop.
So
this
is
why
I'm
saying
what's
in
current
is
the
currency
is
not
complete?
I'm
suggesting
drop
it
until
we
have
a
complete
solution,
but
yeah.
So
this
is
basically
the
question
that
you
want
to
mention.
I
wanna
make
sure
we
with
whatever
conversation
here.
If
there
is
argument
to
keep
it
or
or
remove
it,.
N
D
I
think
I
think
we
should
pull
this
out
for
now.
I
think
if
someone
comes
back
with
like
a
clear
use
case
and
a
fully
baked
solution,
then
we
should
reconsider
but,
like
I
think,
having
something
that
is
kind
of
messed
up
in
this
back
isn't
good.
So,
let's
take
it
out
for
now.
H
Yeah,
I
think
that
well
maybe
a
bit
different,
but
I
think
that
I
think
that
signature
is
nice
and
and
we
should
not
move
it
even
if
it
is
something
that
it
is
not
a
restaurant.
I
mean,
obviously
I'm
not
a
great
guy,
so
I'm
I'm
biased,
but
I
think
that
being
able
to
identify
who
is
it
is
who
each
strat
belongs
to
is
an
important
feature
and
regarding
the
the
the
the
proposal
to
have
what
to
have,
I
prefer
to
have
something
that
it
is
not
or
not
completely
defined.
H
F
F
Q
So,
just
to
provide
a
little
bit
of
feedback,
we
phil
henke,
and
I
worked
on
an
implementation
which
that's
pretty
much
the
first
bullet
point
there
we
sent
the
signatures
of
the
previous
end
frames
and
then
sign
that
you
know
it
was
it's
complex,
makes
the
whole
thing
hard
to
maintain,
and
so
far
what
we've
seen
is
that
the
threat
model
is
complex
to
to
understand
you're
already
in
a
conference
with
with
people
who
have
exchanged
keys
with.
So
the
fact
that
someone
is
using
someone
else's
key.
Q
What
does
that
mean?
It's
not
very
clear
to
us
what
value
it
adds,
what
it
does
and
is
a
lot
of
overhead,
so
I
am
at
least
for
the
time
being
for
removing
it
until
something
which
has
a
clear
path
to
to
force
existence
to
be.
You
know
devised.
P
I
can
see
the
motivation
it'd
be
a
nice
benefit
to
the
users,
but
I
don't
see
a
practical
way
to
do
this.
That
has
any
any
sort
of
assurance
to
a
user.
This
essentially
means
that
you'd
have
to
have
perfectly
reliable
delivery
of
everything
which
makes
you
know,
robustness
incredibly
hard
to
achieve,
and
then,
if,
if,
if
things
weren't
fully
reliable,
then
how
do
you
deal
with
the
very
high
frequency
failure
of
this?
You
know:
how
do
you
expose
that
to
the
user?
You
know.
Is
it
a
flickering?
P
You
know
a
flickering
button
constantly,
it
seems
like
it
seems
like
this
is
fraught
with
with
user
interface
problems
for
it
to
be
meaningful.
E
And
you're
heavy
yeah
good
yeah.
I
would
like
to
to
drop
it.
I
think
that
at
this
point,
until
we
have
clear
use
cases
and
a
clear
path
to
fix
it,
then
it
should
be
removed.
If
we
keep
it,
I
feel
that
it
will
not
be
implemented.
It
will
stay
as
is
and
and
test
it
and
will
not
bring
value,
and
we
will
just
slow
down
the
progress
we
can
make.
I
Okay,
tim,
so
I
I
kind
of
don't
want
to
keep
it.
I
think
it's
looks
messy,
but
we
then
lose
one
other
attribute
of
of
signing
of
of
auth,
which
is
that
you're
filtering
out
like
bad
packets.
I
It's
a
way
of
in
implementing
my
implementation,
at
least
it's
a
way
of
deciding
not
to
deal
with
something.
That's
that's
bad
and
it
protects
the
other
layers
so
you're
losing
that
protection.
By
dropping
this,
don't
you
get
the
authentication
tag.
A
R
And
hi,
do
you
hear
me.
A
R
So
I
see
there's
a
lot
of
people
who
want
to
get
rid
of
it
and
maybe
that's
fine.
I
was
just
wondering
that,
at
least
in
in
in
the
previous
presentation
there
was
mention
of
using
case
derived
from
mls.
R
R
Sorry,
if
this
question
is
stupid,
but
I'm
following
this
working
group
from
the
sidelines
and
I'm
not
sure
if
how
these
signatures
relate
then
to
the
mls
keys,
I'm
going
to
let
richard.
C
Answer
that
one
yeah
yeah
just
real
briefly
the
symmetric
crypto.
That
is
just
if
we
don't
have
a
signature
feature
than
the
symmetric
crypto.
Even
if
you
get
the
keys
from
mls,
because
it's
symmetric
crypto,
any
receiver
can
generate
a
stream
for
any
sender,
and
so
they
can
be
freely
exchanged
and
spoofed.
You
don't
get
any
person
or
authentication.
Q
I
was
a
bit
confused
by
what
what
tim
said,
but
I
think
now
you're
clarified.
So
I
don't
think
removing
this
opens
you
for
fussing,
because
you
you
do
verify
the
aes
signature
tags
in
the
end,
when
you
don't
know
if
somebody
is
using
somebody
else's
symmetric
key
for
encrypting,
but
I
think
you
have
other
ways
to
to
know
this.
At
least
today
on
the
singleton
layer.
H
H
A
So
what
I'm
hearing
here
is
that
there's-
maybe
maybe
one
maybe
two
people
who
like
to
keep
this.
I
think
what
we're
going
to
do
here
is
take
this
to
the
to
the
list
and
confirm
that
this.
But
it
seems
at
this
point
that
there's
not
a
lot
of
enthusiasm
for
keeping
it.
One
thing
we
can
potentially
do
is
encourage
those
people
who
care
about
this
to
to
write
a
draft
and
put
out
a
design
that
doesn't
have
the
shortcomings
that
have
been
identified
with
the
existing
one.
So
you
feel
good.
F
Yeah
one
last
quick
side,
so
porsche
frames,
because
the
current
draft
started
as
only
focusing
on
frames.
Hence
the
name
is
frame,
but,
as
the
charter
mentioned,
we
won't
support
like
other
decodable
units
like
new.
Naturally,
it
should
be
supported
by
default,
because
there's
a
frame
all
the
backgroundization
happens,
offer
is
free
and
if
you're
going
to
encrypt
whatever
is
passed
to
it.
So
it's
either
right.
So,
therefore
frame
is
half
frame,
so
it
should
naturally
work.
F
F
And
with
that,
I
think,
okay.
C
Anyone,
okay,
richard,
has
a
comment
just
just
a
quick
question
for
you
matt.
I
was
wondering
whether
you
think
that
this
I
I
totally
agree.
This
is
something
we
should
do,
because
we
need
the
to
be
able
to
operate
on
subframe
units.
C
What
I
was
wondering
is
whether
you
think
that
the
s
frame
framing
needs
to
have
any
provisions
to
support
this.
For
example,
you
might
want
something
like
a
a
length
field
to
just
to
delineate
chunks
of
stream
encoded
data
if
you're
going
to
get
a
whole
frame
and
need
to
break
it
up
into
encoded
units.
F
I
need
to
think
about,
but
I
think
the
first
answer
to
my:
no,
because
all
these
things
should
be
in
the
for
robots.
It
will
be
in
the
frame
header
extension
or
this
metadata.
I
give
the
the
thing
is:
what
about
frame
counter?
What
frame
count
represents
in
this
case?
Just
another
counter
would
would
it
just
work?
I.
J
A
A
A
Done,
thank
you
very
much
and
oh
we're
doing
pretty
well
on
time.
We
might
might
be
able
to
get
dr
alex
and
some
time
on
the
agenda.
After
all,
let's
go
to
sergio
now
with
the
video
codec.
A
H
Yeah
next
slide,
let's
go
ahead,
and
what
I
was
trying
to
explain
in
this
in
in
this
setup
slide
is
how
the
current
the
current
codecs
are
used
within
this
frame
that
could
be
used
with
a
spring.
What
can
we
learn
from
that
when
we
apply
this
to
the
or
we
try
to
to
implement
the
generated
video
packet
education?
H
I
mean
this
does
not
work
out
out
of
the
box,
because
when
you
increase
the
full
frame,
there
is
some
part
that
that
is
in
in
in
the
encrypted
part
that
it
is
required
by
this
view
to
work
so
some,
and
so
what
you
then
create
the
the
the
whole
frame
with
this
frame.
H
Some
of
the
some
part
of
the
of
the
video
of
the
payload
is
encrypted
because
it
is
the
what
comes
in
the
video
frames,
but
the
the
packet
decision
adds
some
data
in
the
in
the
beginning
that
it
is
sending
clear
and
the
svu
use
some
of
this
content
that
it
is
sent
in
the
clear
section.
So
we
can,
you
can
work
on
it,
but
it
requires
also
some
parts
of
the
of
the
information
that
it
is
required.
H
It's
saying
in
the
encrypted
part
that
it
is
mainly
the
data
frame,
a
market
and
also
a
for
example,
chrome
requires
one
that
you
will
do
temporal
scalability
that
the
picture
id
that
it
is
also
sent
in
the
in
the
encrypted
part
is
it's
rewritten.
So,
in
order
to
overcome
this
overcome,
this
is
typically.
What
it
is
done
is
that
when
you
apply
this
frame
transformation,
you
just
skip
the
first
byte,
the
first
byte
that
belongs
to
the
bp,
the
bpa
8
payload
headers.
H
H
Bp9
is
different
because
all
the
information
required
by
the
svu
is
sent
in
the
payload
descriptor
that
it
is
sending
clear
so
like
bp8
this
fee,
you
can
work
with
the
with
the
complete
frame
encrypted
without
any
issues,
so
this
works
out
of
the
box,
and
you
can
just
use
a
s
frame
with
bp
night
without
having
any
kind
of
and
extra
things
to
in
in
the
in
the
packetization.
H
The
only
thing
is
that
when
you
impl
use
a
special
scalability
as
the
svu
can't
drop
any
of
this
of
the
special
expert
special
layer
that
is
sent
that
it
is
present
in
this
in
in
in
the
from
in
the
frame,
you
need
to
pass
each
of
the
of
the
layer
frames
individually
to
this
frame.
So
you
you
have
one
video
frame
that
has
three
special
layers.
H
S
H
Replaces
the
some
part
of
it,
especially
the
the
the
null
unit,
heather
knowledge,
headers,
and
we
replace
the
content
with
an
something
that
is
very
similar.
But
it
is
not
the
same.
So
if
you
encoding
the
extrusive
frame,
s264
frame
with
a
with
a
with
s
frame-
and
you
then
apply
the
rtp
package
sensation,
some
of
the
encrypted
parts
will
be
replace
it
and
with
the
rtp
packet
decision,.
H
Types
that
it
is
sending
clear
so
when
you
receive
it
and
your
unpacked
decision
a
bucket,
decide
it
and
you
will
have
some
missing
information
because
because
then
the
stuff
that
will
replace
it
from
the
encrypted
to
the
non-encrypted
part,
you
will
not
be
able
to
have
access
to
it.
So
the
only
way
to
solve
that
is
that
a
stream
must
work
with
null
units.
H
A
J
A
little
bit
of
avoiding
the
overhead,
you
know
one
approach
that
I
I
think
could
work
would
be
that
you
sort
of
insist
on
you,
know,
staff
type,
aggregation
and
then,
like
the
sps
pps,
you
know,
are
then
sort
of
clear
text
as
they
are
in
like
the
vp8
or
vp9
payload
header,
and
so
you
end
up.
Then,
in
the
situation
where
you
have
like
some
of
the
stuff
at
the
beginning
of
the
packet,
it's
clear
text
and
then
the
actual
payload
that
contains
the
you
know
the
irp
frames.
J
You
know,
then
it
becomes
encrypted
similar
to
the
vp8
or
vp9.
You
know
actual
encrypted
payload,
and
once
you
apply
that
sort
of
transformation
of
assuming
that
a
staff
type
aggregation
is
required,
then
you
can
think
about
it
in
the
same
sort
of
way
as
like
a
vp8
or
vp9
situation,
which
I
think
is
an
interesting
simplification.
H
J
T
Generally,
like
justin's
idea,
however,
there
is,
there
is
one
additional
thing
to
consider,
and
that
is,
I
think
many
h.264
based
h64
using
sf
use
also
look
into
the
slice
header,
which
would
be
the
encrypt
part
right
now.
T
So
if
I
were
designing
this
now,
really
speaking
of
the
top
of
my
head,
you
know.
Probably
what
you
want
to
do
is
to
send
something
like
just
just
doing
here:
the
single
value
in
it
packetization
thing
like
sending
the
first,
whatever
four
octets
of
the
null
unit
in
the
clear
that
would
give
you
access
to
the
slice,
header
and
some
random
microblock
data,
which
no
one
can
use,
and
that
would
be
compatible
with
how
how
h364
sfeu
is
work
with
my
understanding,
so
some
flexibility
there
is,
I
think,
warranted.
Thank
you.
O
Hello
yeah,
so
I
think
it's
it's
a
little
unclear
to
me
just
how
much
so
is
the
goal
here
that
we
should
be
able
to
do
this
with
the
sfus
being
completely
oblivious
to
the
fact
that
we're
doing
as
frame
or
is
the
goal
or
not,
because
if,
if
not,
then,
obviously
we
have
a
lot
more
flexibility
in
how
we
might
want
to
rearrange
these
these
packets.
O
I'm
also
a
little
concerned
with
you
know
how
hey,
how
much
standardization
works
is
going
to
be
decided
exactly
to
define
exactly
what
is
and
isn't
encrypted
in
each
packet,
because
I
feel
like
that's
something
that
needs
a
lot
of
deep
knowledge
of
each
codec
to
know
what
precise
bits
are:
aren't
privacy
sensitive,
which
seems
like
not
something
where
there's
a
lot.
You
know
where
the
expertise
is
necessarily
even
in
the
people
who
write
the
payload,
the
the
payload
formats,
because
it's
you
know,
I
have
a
blob
for
that.
O
H
But
I
don't
have
any
goal
when
putting
this
I
mean.
What
I'm
just
trying
to
describe
is
is
what
we
are
currently
doing
to
make
a
s
framework
with
the
current
payloads.
R
N
H
K
Is
here
I
mean,
I
think
this
is
a
great
example
why
you're
gonna
have
to
go
to
this
more
generic
decide
on
what
information
is
acceptable
to
expose
for
that.
This
kind
of
agnostic,
codex
forest
is
used
to
deal
with
and
then
and
then
basically
have
each
code
saying
yeah.
This
is
what
what
this
idu,
that
the
chat
has
been
talking
say
what
is
the
smallest,
independently
decodable
units
that
the
code
can
handle?
K
K
So,
I
think,
you're
ending
up
in
that
design
space
if
you're
gonna
really
solve
this
in
a
nice
way
which
actually
minimizes
as
if
you
impact
is
that,
yes,
you
do
one
s
if
you
style
style,
and
then
you
deal
with
this
okay,
how
what's
generic
information
we
need
to
deal
with
for
the
switching
operations
etc?
And
you
can
also
do
then
a
proper
security
review
of
those
particular
fields
and
not
have
to
deal
at
some
future
point
that
might
change
with
new
codex
essential
new
substructures.
But
at
that
point
by
the
bullet,
then.
P
Just
to
answer
magnus's
point:
we
try
to
do
that
with
frameworking,
as
he
well
knows,
and
it's
it
sounds
simple.
You
know
at
the
beginning,
but
as
new
payload
formats
evolve,
it's
difficult
to
capture
all
of
their
useful
semantics.
P
That
would
be,
you
know,
necessary
in
a
in
the
middle
box,
for
it
through
its
function
right,
so
that
this
you
know
the
concept
of
having
a
generic
genetic
scripture
for
all
of
these
paleo
types
while
very
attractive.
P
I
think
in
practice
we've
seen
that
it's
it's
pretty
hard
to
actually
pull
off
and
have
any
kind
of
life
current
in
the
market.
K
Yeah,
but
I
mean
that's
the
same
as
switching
up
of
individual
payload
formats
and
anyway
it's
the
same.
You
have
to
deploy
them
and
if
it's
not,
if
you
have
certain
unique
parts
and
and
certain
coding
specific,
you
still
have
the
deployment
aspects
of
setting
dealing
with
that.
But
I
think
you
need
anyway,
you
can't,
if
you're
going
to
you
end
up
in
a
route,
something
you
need
to
decide
for.
K
Each
payload
format
is
to
what
to
expose
to
be
able
to
do
the
switching
operation
and
that
needs
to
secure
the
analysis
to
not
leak
information,
that's
sensitive
and
and
so
you're,
not
getting
away
from
that
aspect.
I
think
it's
something
you're
gonna
have
to
deal
with
even
with
s
frames,
or
you
have
to
treat
them
completely
in
eric
and
and
and
put
the
logic
somewhere
else,
and
have
that
step
completely
separate
and
say
this
is
magic
number,
five
and
and
then
you
have
the
logic
telling
you
just
a
few
five.
A
H
Then
then,
I
like
to
also
speak
about
ab1,
because
ab1
has
one
one
feature
is
that
and
the
packet
designation
is
designed
to
work
with
the
end-to-end
encryption,
so
in
this
case
everything
goes
out
of
the
box.
All
the
frame
is
encrypted
by
this
frame.
This
er
equally
to
bp9,
as
the
svu
can
drop
any
special
layer
each
of
the
of
the
of
the
in
ab1.
It
is
called
frame
that
the
spatial
frames
say
within
this.
The
same
rtp
frame
has
to
be
encoded
differently
or
independently,
so
it's
they
can
be
dropped.
H
I
can
go
into
much
more
details
about
how
the
dependency
descriptor
works,
but
I'm
not
sure
if
it
is
in
the
scope
of
this
working
group,
but
I
can
provide
more
details
about
how
the
dependency
index
return
works,
how
the
what
are
the
properties
of
the
dependency
descriptor
so,
but
regarding
this
view,
the
svu
does
not
need
to
check
any
a
any
part
of
the
rtp
pilot
at
all.
H
One
thing
is
that
the
dependent
the
dependence
industry
or
the
header
station
can
be
authenticated
end-to-end
because
it
includes
the.
It
includes
the
one
thing
that
it
is
called
the
active
that
called
target
mass,
that
it
indicates
which
layer
has
been
for
what
they
bite
svu.
In
order
to
be
able
to
do
and
to
do
like
your.
H
Fast,
and
so
this
is,
can
be
changed
by
the
svu,
so
this.
So
this
is
why
the
dependencies
the
descriptor
can
be
authenticated
and
when
also,
I
don't
think
that
it
is
encrypted
authenticating.
This
method.
That
is
something
that
it
is,
should
be
done
and
the
dependency
descriptor
is.
It
can
be
encrypted
by
hub
by
hub
either
by
standard
fcc
904
or
by
the
new
expected
by
grid
text.
H
H
H
H
And
most
worrying
is
that
we
will
have
to
do
this
effort
for
it's
a
codec
that
has
a
specific
typicalization
by
past
a
future.
So
it
will
be
a
never-ending
and
process
when
new
video
friends
come
the
new
video
codecs
are
available
and
it
will
create
a
part
of
making
the
specification
work
much
harder.
It
will
also
have
create
a
huge
integrability
problems,
because
you
will
have
not
only
tests
and
strain
implementation
between
different
browsers,
but
you
have
to
will
have
to
test
each
of
the
codec
and
between
these
browsers.
H
I
would
like
to
have
a
solution
that
it
is
protocol
agnostic,
er,
at
the
same
as
we
have
with
the
spring,
that
it
is
meant
to
be
protocol
agnostic
if
we
can
have
some
solution
that
implement
this
packetization,
and
this
metadata
request
for
this
video
is
something
that
can
be
reused
in
other
protocols
that
are
not
rtp
based.
I
think
that
it
will
be
nice
to
have.
A
C
C
All
right
and
already
I
have
screwed
up
the
draft
name
here,
because
it's
actually
s
frame
mls.
I
got
distracted
by
dtlssrgp
which
put
cuts
the
key
exchange
first,
but
we're
doing
this
in
he
has
framework
in
group.
Instead
of
the
mls
working
groups,
the
s
frame
comes
first
in
draft
name.
I
put
the
asterisk
there
when
I
first
sent
martin
the
slides,
because
I
hadn't
submitted
the
draft
yet,
but
there
is
now
an
internet
draft
that
was
submitted
yesterday.
C
So
the
idea
here
is,
if
you
can
go
to
the
next
slide,
funny
that
we've
just
spent
a
few
little
while
discussing
the
hard
parts
around
how
we
choose
the
units
we
encode
from
the
crypto
nerds
perspective.
The
hard
part
is
always
the
key
management
and
not
the
choice
of
what
you
that
you
encrypt
so
usual
funny
disconnect
between
the
media,
folks
and
the
crypto
folks
here
right.
So
the
s
frame,
you
know,
framing
structure
defines
how
you
encrypt
a
media
payload
given
a
key.
C
You
know
in
the
identifiers
for
it
in
the
counters,
etc.
What
it
doesn't
define
is
how
you
get
the
keys
that
you
use
for
the
media
payload
and
the
security
properties
you
get
from.
The
encryption
obviously
depend
on
the
security
properties
of
how
you
got
those
keys.
C
You
know
the
usual
approaches
we
have
to
establishing
the
keys
for
things
like
srtp
are
things
like
sdes
or
dtlssrtp,
which
are
really
focused
on
one-to-one
cases
and,
as
you
heard
in
the
use
cases,
discussions
earlier,
a
lot
of
the
cases
for
what
we're
looking
at
for
s
frame
are
many
to
many,
especially
these
conferencing
cases
and
so
the
goal.
The
desire
here
is
to
have
a
key
management
system.
That's
that
can
address
this
group
use
case
and
you
know
get
you
good
security
properties
for
the
keys.
C
C
Originally,
you
know,
the
kind
of
driving
use
case
was
secure
messaging,
so
apps
like
wire
or
whatsapp
that
provide
secure
group
messaging
and
the
desire
there
was
to
provide
keys
for
those
messaging
systems
that
have
the
security
properties.
You
expect
so
you
have
authentication
of
the
party.
You
have
a
key,
that's
only
known
to
authenticated
parties
that
you
can
have
more
than
two
parties
there.
You
can
have
a
group
instead
of
just
a
one-to-one
connection
and
the
kind
of
more
interesting
properties
here.
C
The
continuity
property
here
is
interesting
because
with
these
messaging
groups,
as
with
conferencing,
participants,
people
can
join
and
leave
the
group
over
time.
So
mls
provides
a
way
to
refresh
the
keys
as
the
membership
of
the
group
changes,
so
that
if
someone
can't
decrypt
media
from
before
they
join
or
after
they've
been
removed
from
the
group,
it
also
provides
forward
security
and
post-compromised
security
so
that
you
kind
of
align
the
compromised
properties
with
that's
kind
of
what
you
expect.
C
Next
slide,
please
just
to
kind
of
give
a
shape,
a
feel
for
how
mls
works
as
a
protocol.
You
know
when,
when
someone
joins,
they
send
a
key
package
to
someone
who's
already
in
the
group
that
describes
their
their
capabilities.
C
The
joiner
gets
back
a
welcome
message
that
you
know
gives
them
the
crypto
material
for
the
group
and
then
the
the
person
who's
in
the
group
who's.
Adding
the
new
person
sends
a
message
broadcasts
a
message
to
the
group
with
an
ad
ad
message
and
a
commit
message
that
everyone
else
in
the
group
uses
to
update
to
update
their
state
to
a
new
key
that
the
joiner
also
has.
C
Then,
when
you
kick
someone
out
of
the
group,
you
just
send
a
remove
message
and
a
commit
message
that
updates
the
whole
group
so
that
they,
the
group's
keys,
are
no
longer
accessible
to
the
person.
That's
kicked
out.
That's
just
kind
of
giving
folks
a
flavor
for
for
what
mls
looks
like
as
a
protocol
doesn't
really
have
much
relevance
to
astrum
directly
next
slide.
Please.
C
So
if
you
think
about
what
an
s
frame,
implementation
is
going
to
be,
it's
gonna
need
you
know
when
it's
encrypting,
it's
gonna
need
a
way
to
figure
out
what
key
id
goes
in
the
s
frame
header
when
it's
decrypting,
it's
gonna
need
a
way
to
look
up
keys
based
on
the
key
ids
that
it's
getting
in
the
s
frame,
headers.
C
So
that's
that's
the
s
frame
inputs
in
terms
of
what
mls
produces.
I
mentioned
that
it
re-keys
every
time
you
do
a
join
or
a
leave.
C
It
can
do
batching
of
those,
but
that's
sort
of
secondary,
but
any
case
it
has
this
notion
of
epochs,
which
are
these
intervals
at
which
the
keys
are
rotated
and
for
avoidance
of
conflicts
for
avoidance
of
non-free
use.
We
need
to
produce
separate
keys
per
sender
in
the
group,
so
the
scheme
here
takes
kind
of
this
epoch
and
sender
id
and
packs
them
into
the
key
id
and
defines
a
way
for
deriving
these
sender.
C
Ikea
sender,
keys
from
the
the
crypto
data
that
mls
produces
for
an
epoch,
just
to
kind
of
tell
this
story
in
pictures.
Next
slide.
Please
mls,
like
I
said,
produces
these
at
the
sequence
of
epochs,
a
linear
sequence
of
things.
For
the
group
you
know
each
batch
of
joins
and
leaves
produces
a
new
epoch
and,
what's
in
the
draft
right
now,
is
at
each
epoch.
C
We
export
an
s
frame,
epoch
secret
from
the
group
secrets,
and
then
we
use
that
to
derive
the
base
keys
that
go
into
k
into
s
frame
by
kdf
in
that
epoch
code,
together
with
the
notion
of
the
the
sender's
index
in
the
group
and
I'll
say
as
well
since
we're
mls.
Another
thing
I
didn't
mention
about
mls
is
that
every
member
of
the
mls
group
has
a
specific
index
in
the
group.
C
So
a
side
effect
of
mls
is
that
if
you're
in
the
group,
then
you
know
a
unique
un-32
for
yourself.
That
defines
you
that
that
uniquely
identifies
you
within
the
group,
and
so
we
can
use
that
to
branch
off
sender
keys
from
the
the
group
secret,
so
the
the
yeah.
C
Now
these
epochs
in
mls
have
are
identified
by
an
eight
byte
counter,
which
is
you
know,
big
for
for
a
parsimonious
protocol
like
s
frame
so
for
compactness.
The
draft
says
you
can
truncate
this
epoch
to
a
number
of
bits
which
we
call
e,
which
basically
defines
your
reordering
window,
defines
how
many
epochs
you
can
have
in
play
at
a
given
time
as
your
your
potentially
rotating
keys
with
some
frequency.
C
My
guess
is
that,
like
having
four
bits
or
eight
bits
is
probably
going
to
work
in
most
cases
depending
on
the
dynamics
of
key
rotation,
this
is
a
parameter
that
the
much
like
you
know.
The
group
is
going
to
have
to
agree
on
the
participants
in
s
frame
encrypted
session
they're,
going
to
have
to
agree
on
what
encryption
algorithms
they're
using
and
that
they're
gonna
agree.
C
They're
using
this
scheme
at
all,
they're
gonna
have
to
agree
on
this
number
of
epoch
bits
as
another
parameter
to
agree
on,
but
then
the
the
the
key
id
encoding
scheme
is
pretty
simple.
You
use
you
stuff
the
epoch
in
the
low
order,
e
bits
and
then
the
remaining
bits
are
the
sender
index.
So
the
key
id
yeah,
it's
just
a
packed
truncated
epoch
and
the
sender
index
grows
as
the
the
number
of
senders
increases.
C
C
So
this
is,
I've
implemented
this
scheme
in
s
frame,
draft
implementation
that
we've
got
going
on
github
no
magic
here,
and
so
that
brings
us
to
the
last
slide,
which
is
you
know,
proposed
adopting
this
draft,
alongside
whatever
draft
we
adopt
for
the
base
s
frame.
Here
there
is
a
couple
questions
I
didn't
mention
here.
You
know
we
could
use
analogy
here
to
dtlssrtp
or
dtls
in
that,
in
that
compound
dtls
is
used
to
negotiate.
C
The
parameters
for
srtp
in
particular
negotiates
the
cipher
suite
that
you're
going
to
use
with
with
srtp.
We
could
do
the
same
thing
here
by
defining
an
mls
extension
to
negotiate
parameters
like
the
cipher
suite
or
the
the
size
of
the
the
epoch.
C
C
I
think
another
thing
that
raphael
noted
to
me
is,
as
we
were
preparing
this
is,
and
I
forgot
to
put
in
the
slide
is
that
mls
actually
itself
produces
per
sender
keys
for
encrypting
its
own
messages,
and
so
it's
got
us
a
scheme
that
is
a
bit
complex
compared
to
what's
defined
here,
but
provides
more
forward
secrecy
within
within
an
epoch.
C
We
could
use
that
internal
mls
secret
generation
scheme
here
it
would
require
a
bit
more
intimate
collaboration
between
mls
and
and
s
frame,
as
opposed
to
just
exporting
a
single
secret,
but
we
could
also
do
that.
It
would
get
you
on
slightly
better
forward
sequencing
properties.
F
So
they're
very
excited
about
this.
I
actually
put
myself
in
the
key
before
he
brought
up
your
last
point
about
using
personal
key,
I'm
actually
against
it.
I
prefer
using
the
root
red
key
for
simulation,
because
mls
presenter
key
is
allowed
ratchet
per
message
and
due
to
the
for
rtc
communication,
we
can't
have
registering,
because
some
some
backs
will
be
the
frames
will
be
lost
and
transit.
So
I
think
the
simplest
thing
to
do
is
just
run
the
root
secret
or
is
the
box.
F
I
guess
the
question
I
have
for
you
is:
I
didn't
get
the
slide
about
key
id.
Derivation
is
this
that
is
frame
key
id
or
another
key
id.
F
But
everything
else
is
would
be
completed
out
of.
F
C
In
this
session,
but
this
remote,
the
stream
header,
has
a
key
id
and
a
counter.
So
the
proposal
here
is
that
you,
the
counter
the
nonce
formation
works,
the
same
way
as
in
s
frame
in
general,.
J
E
J
C
I
think
I
might
disagree
with
that
assumption.
Just
because
of
the
way
it
requires
some
additional
coupling
between
the
s
frame
layer
and
the
application.
C
So
this
scheme
is
designed
so
that
the
key
id
space
is
shared
across
all
of
the
senders
and
the
you
know
when
the
s
frame
stack
gets
a
decryption
to
do,
it
doesn't
know
kind
of
which,
which
senders
which
user's
stream
it
came
from,
and
so
that's
why
you
need
to
include
the
sender
index
in
there.
Otherwise
you
could
just
encode
the
epoch.
D
D
D
Really
I
mean
this
seems
like
good
stuff.
We
could
call
out
the
details.
I
I
actually
found
myself
a
little
lost
in
that
colloquy.
You
just
have
with
mad
like
we
agreed,
the
packet
has
to
carry
the
back.
It
has
to
carry
some
indicator
of
which,
like
every
sorry,
everyone
has
to
use
their
own
key
space,
they're,
not
space
in
some
way
right.
Otherwise,
you
have
a
terrible
problem,
so
you
use
different
keys
or
you
need
a
big
ass,
not
spaces,
not
something
like
that.
Right.
C
Yep,
I
I
think
imad's
assumption
is
that
something
at
a
layer
outside
of
s
frame
can
indicate
who
the
sender
is,
and
then
the
key
id
can
distinguish
keys
within
the
sender's
sequence,
correct.
D
That
doesn't
that
seems
the
same.
We
definitely
have
to
resolve.
Yes,
if
it's
assuming
I
understand
this
issue
about
this
issue
is
assume
that.
D
The
ratchet
correctly,
I
agree,
I
doesn't
see
much
value
in
trying
to
use
the
the
more
more
closely
bladed
secrets
the
and
I
I
do
think
it'd
be
nice
for
mls
to
negotiate
the
this
effort.
The
cypher
suites
seems
like
otherwise
you're
going
to
have
like
a
palette
problems.
D
And
why?
Why
is
one
actually
one
thing
I
should
mention
is
that
the
you
want
that
also
because
you
want
to
know
why
why
you
you
want,
you
want
to
have
enough
context
to
know
why
you're
getting
what
you're
getting
when
you
play.
We
support
the.
D
A
Someone
captured
that
in
the
notes,
the
cipher
sweet
issue
and
we'll
go
to
jonathan.
O
Hello,
so
I
just
wanted
to
you
know,
bring
up
a
side,
conversation
martin
and
I
were
having
in
the
chat,
which
is
that
you
know
on
the
question
of
whether
the
epic
trent
truncation
needs
to
be
flexible.
O
I
think
he
commented
that
he
didn't
think
it
did,
and
I
my
response
was
that
I
think
that
if
we
were
only
talking
about
true
interactive
media,
where
you
know
you
have
you
know
the
level
of
of
you
know
interaction,
interactive
conversation
around
trip
time.
I
think
I
agree,
but
I
think
my
comment
was:
we
probably
need
to
make
sure
before
we
make
that
decision,
that
we
don't
have
any
use
cases
where
stored
media
would
be
useful
where,
obviously,
if
you
have
stored
media,
then
you
have
a
much
larger
history
of.
O
A
So,
just
in
response
to
jonathan,
I
that
in
the
case
that
you
have
stored
media,
you
will
still
have
a
progression
of
epochs
that
you
can
recover
from
a
low
bit
count
epoch
thing
and
in
particular,
for
stored
media.
You
probably
won't
have
periods
where
you
miss
multiple
epochs
such
that
you
lose
synchronization.
So
it
seems
to
me,
like
you,
could
probably
get
away
with
a
very
small
number
of
bits.
Even
there.
C
Yeah,
I
was
going
to
say
a
similar
thing,
which
is
that
store
stored
media.
Is
this
case?
I
don't
worry
about
here.
It's
really
the
desynchronization
problem.
That
is
the
reason
that
you
need
a
non
non-zero
number
of
bits
for
the
epoch.
If
everyone
were
in
sync,
if
everyone
were
coordinated
on
the
epoch
out
of
band,
you
wouldn't
even
need
to
signal
the
f
at
all.
C
O
H
We
should
be
able
to
support
any
kind
of
a
ski
management
system
into
interest
frames,
so
just
try
to
to
when
we
discuss
about
how
mls
should
be
integrated
into
a
strain
just
try
to
not
to
to
adapt
too
much.
This
frame
to
what
is
a
mls
requires,
especially
for
example,
and
or
taking
into
account
or
the
discussion.
H
C
Yeah,
I
think
we
have
a
pretty
clean
d
mark
here.
In
fact,
in
the
in
the
code
we
wrote
to
this,
there
is
there's
literally
a
separate
class,
a
separate
inheritance
boundary
that
separates
the
mls
based
keying
stuff
from
the
base
s
frame
stuff.
So
I
I
think
we're
pretty
good
if
you
think
that
there's
unnecessarily
entanglements
here,
please
speak
up.
I'm
happy
to
sort
those
out.
H
You
know
I,
I
think
that
the
question
is:
if
the
key
space
is
is
global
or
percentage
honey,
we
need
to
carry
a
center
index
also
in
spring
or
not.
I
think
that
is
my
main
concern
and
I
just
will
try
to
to
to
have
this
discussion
as
frame
and
if
mls
can
be
of
the
message.
This
would
be
much
better,
but
I
would
like
to
to
have
the
discussion
and
to
be
like
kind
of
kms
of
an
oxygen
as
nausicaa
will.
C
Yeah,
that's
a
good
point.
I
think
that
the
the
the
idea
that
the
key
id
needs
to
provide
distinct
non-spaces
per
sender
is
s
frame
generic
and
then
each
key
management
scheme
needs
to
assure
that
property.
They
need
to
ensure
that,
however,
the
keys
are
identified
that
you
end
up
with
separate
keys
per
sender.
S
C
C
Well,
because
we're
using
authenticated
encryption,
if
you
try
to
decompress
with
wrong
key,
the
the
encryption
will
actually
fail.
Okay,
modula
my
cryptographers
in
the
back
of
my
head
screaming
about
non-committing.
C
There
are
cases
like
exceptionally
rare
cases
where
you
can
decrypt
with
an
incorrect
key
and
the
decryption
will
succeed,
but
with
overwhelming
probability
the
decryption
will
fail.
C
And
so
so
you'll
know,
and
so
you
could,
you
can
recover
from
epoch
wraps
with
trial,
decryption.
A
So
I
guess
the
first
question
that
I'd
like
to
get
a
sort
of
indication
of.
Maybe
I
can
start
one
of
the
show
of
hands.
Things
is
how
many
people
have
read
the
the
s
frame
draft
from.
A
A
A
A
All
right,
based
on
this,
it's
probably
a
little
early
to
start
the
consensus
call
for
this
adopting
of
this
particular
draft,
but
we
might
want
to
talk
talk
about
the
adoption
of
the
the
core
s
frame
draft,
realizing,
of
course,
that
this
is
just
a
starting
point.
If
anyone
has
any
idea
that
they
might
want
to
propose
some
dramatically
different
approach,
now's
a
good
time
to
speak,
because
I'm
going
to
ask
people
to
raise
their
hands
in
favor
or
against.
A
If
you
do
not
raise
your
hand,
adoption
of
the
draft
amarra
s
frame.
B
Well,
martin,
just
a
gentle
quick
point
of
order,
there
is
a
request
to
relay
the
results
for
the
audio
recording.
For
the
first
question,
have
you
read
us
frame
out
of
44
participants?
16
raised
their
hand.
Six
did
not.
For
the
second
question,
have
you
read
the
short
s
frame,
mls
draft
that
was
just
presented
out
of
44
participants,
four
raised
their
hand.
18
did
not
thanks
all
right
thanks.
A
So
I'm
going
to
start
a
show
of
hands
now,
while
we're
voting
again
for
adopt
adopting
draft
omara
s
frame
I'll
have
to
get
a
better
name
for
that
when
the
time
comes,
because
it's
a
little
bit
a
bit
hard.
But
if
you,
if
you
think
we
should
adopt
this
draft,
raise
your
hand
if
you
think
we
should
not
do
not
raise
your
hand
if
you're
undecided,
I
suggest
don't
raise
your.
A
A
Fine
all
right
there,
there
are
three
people
who
think
we
might
not
want
to
adopt
this
draft.
Does
any
one
of
those
people
want
to
say
why.
A
I
see
echo
is:
are
you
raising
your
hand?
Because
you
want
to.
A
G
A
A
Okay,
so
what
I
suggest
we
do
here
is
we'll
send
around
an
email
asking
for
confirmation,
and
if
people
want
to
make
arguments
for
maybe
delaying
a
little
rather
than
accepting
a
zero
zero
draft,
then
that
is
perfectly
reasonable.
We
should
we
should
discuss
that,
but
the
chairs
will
talk
about
that
and
we'll
see
whether
the
list
agrees
with
with
the
vague
indications
that
there's
support
for
adopting
this
one
and
I'm
going
to
try
to
find
dr
alex's
slides,
which
is
probably
not
going
to
work
out
very
well.
For
me,.
A
A
V
All
right
great,
so
this
is
not
a
status
report
and
I
didn't
write
any
code
yet
see
that
more
as
a
declaration
of
intent
to
work
on
on
a
specific
problem
and
a
use
case,
but
I
think
sram
could
be
applied
to
and
provide
a
good
result
that
is
slightly
different
than
video
conferencing
next
slide.
Please.
V
So
I
took
that
from
perk,
but
I
think
it
applies
to
to
the
video
conferencing
in
general
in
terms
of
trust
model,
the
end
point
and
the
key
distributor
are
trusted
that
everything
else
is
actually
not
trusted
next
slide.
V
If
you
go
into
the
the
streaming
here
again,
the
end
cases
are
trusted
with
the
specific
case
of
the
web
application
where
the
javascript
and
the
browser
are
respectively,
entrusted
and
trusted.
V
V
V
V
So
it
raised
the
question
so
even
though
some
of
the
assumptions
that
were
used
when
do
streaming
technology,
what
you've
got
have
changed
a
little
bit.
For
example,
the
ingest
link
is
not
trusted
anymore.
We
see
more
people
moving
to
our
tmps
is
still
required
to
have
the
capacity
to
transcoding
to
the
media
server,
which
precludes
the
use
of
end-to-end
encryption.
V
V
So
I
think,
with
this
frame,
given
that
we
separate
the
media
encryption
itself
from
the
key
management
and
so
on,
there
might
be
some
opportunity
to
bridge
the
gap
right
and
allow
something
that
is
a
little
bit
smarter,
especially
for
broadcasting
infrastructure
that
deal
with
real
time
content
and
not
video
on
demand.
I
believe
that
video
on
demand
is
pretty
well
served
with
the
technology
there
is
today,
but
the
boundary
between
video
on
demand
and
real
time
with
people
being
stuck
at
home
and
wanting
to
participate
interactively
with
with
media.
N
V
And
the
key
management
system
that
the
encryption
is
happening
between
the
streaming,
endpoint
and
and
the
player
itself
with
sram
and
end-to-end
encryption,
we
could
have
the
capacity
we
could
have
the
capacity
to
not
have
to
trust
the
platform
we
sending
the
the
media
to
right
and
there's
there's
quite
a
lot
of
demand
there.
So
the
question
is:
can
we
avoid
to
do
that
in
a
specific
manner?
V
And
can
we
try
to
unify
it
looks
like
there
is
opportunity
to
unify
the
top
one
and
the
bottom
one,
so
we're
going
to
spend
some
time
investigating
this,
and
if
anybody
is
interested
in
the
same
question
that
that's
an
opening
for
anybody
to
come
with
us
and
join
in
and
participate
in
the
investigation.
At
this
point,
I
see
another
interest
for
the
sram
group
is
that
the
scalability
model
and
the
trust
model
being
different.
V
We
would
have
two
different
usage
of
this
frame
and
we
would
be
sure
that
s
frame
is
really
agnostic
to
the
use
case
and
that
we
said
we
got
the
right
boundary
around
the
media
encryption
and
we're
not
being
biased
by
using
any
kind
of
key
mechanism
or
key
management
mechanism
on
this
case.
V
Another
problem
so
next
slide.
Please
another
problem
in
specific
to
to
streaming
is
sometimes
you
can
have
a
single
source
and
two
to
ten
million
of
viewers,
and
so
there
are
some
limit
to
some
of
the
key
scheme
and
key
rotation
scheme
that
have
not
been
designed
not
only
for
the
one
to
n.
So
we
saw
that
richard
was
speaking
about
one
to
one
scheme
and
separately
end
to
end
now
we're
speaking
about
one
to
n,
with
n
being
very,
very
large.
A
I
Yeah,
I
think
this
is
this
is
interesting.
I
think
I
think,
there's
the
one
to
end,
there's
also
a
one
to
n,
where
n
is
a
relatively
small
number
and
I
think
so
kind
of
extending
that
somewhat,
and
I
think
there's
one
other
thing
which
is
potentially
kind
of
stored.
Ish
media
there's
some
interesting
stuff
in
in
that
space.
I
But
I
think
the
key
thing
that
we're
missing
here-
and
we
I
haven't
heard
yet-
is
that
actually
it's
not
in
a
lot
of
use
cases
you're
not
actually
worried
about
trust,
we're
interested
in
deniability
the
the
service
provider
wants
to
be
able
to
say
that
they
haven't
seen
your
the
pictures
of
your
baby
or
or
that
they
that
they
have
no
access
to
that
to
your
your
board
discussion,
and
so
it's
actually
it's
about
plausible
deniability,
rather
than
actual
trust
per
se.
V
Now
that's
a
good
point.
I
think
there
is
interest
for
the
platform
also
to
be
able
to
say
you
know,
even
if
the
government
asked
me
to
give
them
access
to
your
data
I
wouldn't
be
able
to,
because
I
do
not
have
access
to
the
data.
I
mean
there
are
incentives
for
all
the
parties
in
the
chain.
I
So
so
I'm
I'm
interested
in
in
following
along,
I
think
my
use
case
is
much
smaller
than
yours,
I'm
like
where,
for
me,
n
is
10
typically,
and
I
think
the
other
differentiator,
which
probably
doesn't
make
any
difference.
But
the
end
point
is
probably
a
lot
smaller,
like
the.
V
V
That's
when
n
becomes
bigger
than
1000
or
50
000
in
some
specific
case
m
s,
that
you
have
some
difficulties
that
I
do
not
have
a
practical
solution
to
the
end.
That
would
require
additional
work.
M
I'm
interested
in
in
at
least
observing
this
work,
I'm
unclear
of
what
the
benefits
are
to
doing
encryption
all
the
way
back
to
the
studio
or
the
camera,
particularly
when
we're
talking
about
n
equals
millions
or
where
the
kinds
of
content
are
effectively
public
domain.
Where
it's
it's
it's
it's,
the
content
of
which
doesn't
require
any.
V
Content
doesn't
need
to
be
secure
and
doesn't
need
to
be
confidential.
The
biggest
example
I
have
in
mind
is
public
debate
or
auction
houses
that
have
a
lot
of
participants.
This
work
doesn't
apply,
but
there
are
still
quite
a
few
use
case
where
you
would
like
to
unify
you:
high
latency
and
low
latencies
encryption
solution
and
advertisements.
V
Actually,
you
want
to
have
two
three
four
of
them
for
redundancy,
but
you
still
need
to
want
to
control
the
access
yourself
and
so
basically
that
secondary
key
because
become
the
token
people
buy
the
token
to
to
pay-per-view.
If
you
want
and
through
that
encryption
system,
and
that
puts
the
the
access
and
the
encryption
in
the
end
of
the
content
generation
and
not
the
distribution
platform
anymore.
A
Okay,
well,
I'm
going
to
suggest
that
we
we
wrap
this
up.
Is
there
any
other
business
that
some
anyone
would
like
to
bring
up
in
our
last
five
minutes.
O
U
I'm
going
to
share
this.
I
was
going
to
share
this
in
chat
just
now,
but
there's
another.
I
don't
know
if
this
is
necessarily
in
scope,
but
there's
a
project
that
is
doing
peer-to-peer,
video
conferencing
and
I
wanted
to-
I
guess,
just
at
least
make
people
aware
of
that
use
case
working
it
can
swap
between
direct
appearing
and
using
an
sfu
if
just
for
scaling
properties
or
as
chosen
by
participants
through
configuration
anyway.
A
Well,
thank
you
all
for
attending.
In
the
good
discussion,
we
will
follow
up
on
a
couple
of
issues
on
the
mailing
list
and
continue
the
discussion
on
those
drafts.
Thank
you
very
much
and
good
night
good
morning
good
evening.
Whatever
it
happens
to
be
where
you
are.