►
From YouTube: IETF95-PERC-20160404-1550
Description
PERC meeting session at IETF95
2016/04/04 1550
A
B
D
F
All
right
folks
settle
in
fasten
your
seat
belts.
Let's
get
started
here,
dr.
Jennings,
all
right,
so
this
is
percolating.
Note
well
noted
well,
report
your
IP
are
irresponsible.
Citizen
I
want
to
start
off
with
reviewer
on
milestones
that
September
one
is
sort
of
starting
to
come
into
view,
so
we
should
maybe
start
to
think
about
adopting
some
documents
for
that
and
the
others,
but
you're
not
too
much
farther
off
in
order
to
highlight
some
of
the
documents
we've
got
on
the
agenda
today
that
could
nap
against
them.
F
These
milestones
because
we
might
start
talking
about
adoption
at
the
end
of
this
meeting
or
shortly
after
the
ones
that
are
involved
there,
we're
going
to
have
specific
presentations
on
the
one
thats
a
knight
alex
is
probably
going
to
get
covered
in
general
and
some
of
the
stuff
that
I
was
going
to
talk
about
so
yeah.
Let's
think
about
those.
We
still
have
your
draft
here
there.
If
we
don't
have
any
drafts
right
now
and
sit
for
web
RTC
integration,
so
submissions
welcome.
It's
almost
to
do
some
work
on
that.
F
We
did
this
same
contact
setting
there.
So
we've
been
thinking
of
this
in
terms
of
layers,
doing
a
transform
at
the
SRS,
our
GPS
or
TCP
layer.
Doing
some
key
management.
We've
got
some
talks
about
that
today
and
then
some
signaling,
they
don't
it
all
together.
I
think
I
was
going
to
touch
someone
that,
but,
like
I
said
we
could
use
some
more
documents,
some
more
work
in
that
space
on
again
recapping.
F
That
can
read
some
fields
or
modify
some
fields,
but
can't
modify
or
read
everything
for
those
of
you
who
are
in
at
the
interims
brief
recap:
we
had
four
of
them
since
the
last
ITF
three
were
devoted
to
looking
at
what
we
want
to
do
with
srtp
and
figuring
out
exactly
what
capabilities
we
needed
for
the
MDD
to
have
at
the
SRT
peeler
in
terms
of
modifying
or
reading
fields.
There
I
think
what
we
came
down
to
was
that
you
needed
to
that.
F
The
mvd
needed
access
to
payload
type
and
sequence
number
and
some
extensions
and
not
much
else,
and
if
it
changed
anything
it
needed
to
keep
the
original
so
good
to
line
requirements
for
srtp
I.
Think
the
transformed
riflessi
today
should
be
pretty
clearly
addressed
to
those
requirements.
We
also
had
a
call
in
this
or
TCP,
where
we
basically
decided
we
weren't
going
to
do
anything
sr.
Tcp
because
it
was
too
complicated
the
details
of
those
discussions,
the
decisions
are
in
the
minutes
for
the
relevant
meetings
and
with
that
I
think
we're
over
to
Adam.
G
F
C
H
I
I
Okay
at
listed
up
here.
So
if
you
want
to
go
in
and
get
more
details
about
sort
of
how
all
this
plays
together,
these
are
the
documents
look
at
going
on
the
next
slide.
Okay,
so
fundamentally
we
have
two
sets
of
keys
right.
We
have
the
been
calling
outer
keys
or
the
hop
by
hop
keys
that
are
used
to
encrypt
information
at
protect
information
between
participants
and
the
mdgs,
and
if
we're
cascading
mdds
between
the
mdgs
themselves,
sorry
md
d
stands
for.
F
I
Distribution
device,
it's
basically
like
v,
it's
the
MCU
and
kirk,
effectively
right
packets,
which
I
don't
know
I.
Just
it's.
The
conference
focus
and
I
keep
looking
around
for
the
right
acronym.
Currently
MDD
is
the
right
thing
for
this,
and
we
also
have
these
end-to-end
keys
that
each
participant
generates
themselves
for
encrypting
media,
that
ascends
to
dmdd
to
then
send
to
everyone,
and
each
participant
has
its
own
one
of
these
go
on
to
go
to
the
next
one.
I
I
think
we've
show
that
a
bit
oh
right,
so
the
wave
these
Keys
get
set
up
in
the
first
place
is
when
the
whole
conference
is
being
set
up.
The
MDD
and
key
management
function
establish
a
ttls
tunnel
that
is
used
almost
exclusively
for
key
exchange
that
there
are
a
set
of
messages,
do
actually
I
have
it
down
here.
I
I
J
I
Because
functionally
what
the
participants
are
doing
is
they're
setting
up
a
TCL
s
connection
and
sending
it
basically
to
the
MDD
expecting
that
to
sort
of
be
the
end
point
as
it
work
right
we're
trying
to
modify
dtls
as
little
as
possible
and
that's
also
used
because
that's
used
for
you
detail
s
srtp
and
yes,
our
TV
is
going
to
the
MDD.
It
has
to
be
to
the
same
place
right.
So
what
the
MDD
can
do
very
mechanically
is
when
he's
receiving
SRT
from
the
disciplined
he's.
I
K
I
I
K
I
Say
he's
decay
of
it
he
could,
but
he
couldn't
prove
that
he's
the
identity
of
decay,
MF
right
when
I
attached
that
came
up
we're
going
to
have
a
certificate
exchange
and
I'm
going
to
know
who
he
is
right.
This
MDD
will
not
be
able
to
assert
that
he
is
that
entity.
So,
for
example,
if
this
MDD
were
hosted
cloud
service
and
the
kmf
a
part
of
my
enterprise
and
I
attached
to
that
kmf,
he
would
have
to
have
estetica
to
prove
that
he
is
part
of
enterprise
com,
not
cloud
service
com.
K
I
F
K
So
again
I
mean
you
need
to
be
some
way
to
protect
that,
because,
because
the
key
management
function
in
the
vm
ddr
separate
intercepted
on
once
and
but
on
the
other
hand,
they
have
to
no
one
about
the
other,
and
you
need
to
be
able
to
be
sure
that
nothing
happens
that
will
cause
because
they
there's
no
protocol.
That
established
this
relation
between
the
MVP
and
the
game.
K.
I
F
I
think
what
Adam
is
articulating
here
is
an
overall
vision
that
is
going
to
require
lots
of
moving
parts
to
set
up
so
the
transport
layer
stuff
we've
been
talking
about
with
us.
Our
TPS
rtcp
is
what's
going
on
along
those
lines.
What
the
mvd
is
changing
the
middle
we're
going
to
need
a
whole
bunch
of
signaling
stuff
as
well
to
arrange
this
will
need
a
tunneling
protocol
to
go
between
the
nzd
in
the
kml.
This
is
sort
of
an
overall
framework
that
will
have
different
parts
that
interoperate
to
make
it
happen
at
all.
K
I
I
That
is
exactly
the
same
as
if
it
was
a
non
hurt
conference
and
had
nothing
to
do
at
the
endpoints.
Don't
even
need
to
know.
That's
really
doubt
that
they're
forming
a
DTLS
connection
to
the
IP
address
that
they
found
in
the
sdp
ice,
blah
blah
blah
mess
and
they're
going
to
check
that
it
has
the
appropriate
fingerprint
of
certificate
that
only
the
kmf
will
have.
K
K
K
I
I
Okay
right,
so
one
of
the
things
is
established
there
is
these
hop-by-hop
keys,
I,
think,
actually
that
we
talked
through
the
snuff.
That
should
be
relatively
obvious,
but
just
visually.
You
end
up
with
three
different
associations:
hapa
help
Keys
a
B
and
C
between
participants,
a
B
and
C
and
the
MDD
respectively,
and
this
is
what
protects
the
information
that
the
MDD
has
access
to.
I
You
also
have
an
e
Katie
key
that
is
provided
during
that
TTLs
setup
and
subsequent
to
it
by
the
kmf
jewish,
the
participants,
and
they
share
this.
Everyone
has
the
same
ekt
key
during
the
course
of
the
conference.
This
is
what
they
use
to
encrypt
their
own
end-to-end
keys
when
they
send
media
to
the
other
participants
which
we
see
in
the
next
slide
right.
I
So
everyone
is
generating
their
own
end
end
key,
which,
although
this
is
initially
going
to
be
generated
off
of
the
dtls
exchange,
it's
going
to
very
quickly
change,
as
ekt
keys
are
pushed
out
the
participants
that
will
trigger
them
to
change
their
own
local
srtp
key
and
then
periodically
send
out
that
key
encrypted
with
EK
Tiki
appended
to
the
RTP
packet,
and
that's
how
everyone
is
able
to
decrypt
the
information
that
they
have,
but
because
idkey
TG
is
never
provided
to
the
MDD.
He
can't
access
the
media.
So
that's
how
the
magic
works.
I
I
Does
it
make
sense?
Okay
next
slide?
So
the
other
scenario
we
want
to
make
certain
we
can
support,
is
non
enterprise
type
use
where
you
have
services
out
on
the
internet
provided
by
third
parties.
You
know
things
like
Google,
Talk,
skype,
etc.
Where
the
MDD
you
know
providing
conference
services,
but
there's
not
necessarily
any
trusted
domain,
you
can
place
a
dedicated
server
in.
Under
these
circumstances,
what
you
need
to
be
able
to
do
is
co-locate
the
kmf
with
one
of
the
participants,
so
something
along
these
lines.
I
J
I
F
Yeah
I
agree:
that's
an
interesting
sort
of
requirements.
Discussion
to
have
later
as
to
a
just
without
the
camera.
Moving
at
all
you
have
sort
of
a
creator
of
the
conference
leaves
the
conference,
the
conference
shuts
down
sort
of
user
experience
and
if
we
don't
find
that
is
an
acceptable
constraint,
lots
of
design
some
extra
machinery
to
make
it
to.
L
L
Patrick
lynskey
Francisco
I
expect
that,
from
a
at
least
for
cisco's
use
cases,
we
would
rather
not
present
that
to
customers
our
users
tend
to
prefer
to
have
a
deterministic
kind
of
owner
of
a
call
so
kind
of
migrating
that
it's
kind
of
an
anti
future.
So
I,
that's
not
to
say
we
couldn't
standardized
how
to
do
it,
but
I
expect
that
and
I
don't
know
what
I
mean
true
brother
for
other
customers,
but
I
think
end.
Users
would
be
surprised
by
that
sort
of-
and
these
are
actually
cared
about.
L
I
I
L
I
K
Around
even
I
think
what
he
was
trying
to
say
is
that
you
won't
see
implement.
You
need
to
implement
the
scene,
an
endpoint
and
it
doesn't
see
people
implementing
this
Zener
endpoint
this
functionality.
So
that's
that's
the
issue
because
the
moment
I
mean
my
my
first
experience
was
doing
multiple
conferencing.
Is
that
and
every
time
you
try
to
put
some
conference
level
things
in
the
end
point
it
doesn't
happen
so
for.
I
Dedicate
endpoints
them
I
mean
this
may
or
may
not
be
an
important
thing.
The
thing
that
really
drives
this,
at
least
as
far
as
I
care
about,
is
where
these
participants
at
least
some
of
them
our
web
artsy
browsers,
and
my
anticipation,
is
that
when
we
get
around
to
writing
the
web,
RTC
document
will
talk
about
specifically
how
to
co-host
a
cam
up
with
an
end
point.
N
Precisely
if
you're
going
to
put
a
kmf
that
can
be
hosed
housed
at
a
participant
and
want
to
deal
with
the
backup,
I
think
it's
really
important
that
the
owner
of
the
call
to
use
the
previous
speakers
words
designate
to
the
backup
is,
as
opposed
to
it
becoming
arbitrary
person
with
the
lowest
IP
address,
or
so
so.
By
doing
that,
they
can
proactively
share
the
current
table
with
with
that
backup
and
if
they
fit
and
then,
if
the
primary
falls
off
it's
there,
and
that
makes
it
a
lot
simpler
and
the
trust
models.
Understandable
and.
P
Q
I
Able
to
crystallize
it
in
my
own
head,
it
was
kind
of
disparate
pieces
until
I
walked
through
the
upper
figuring
out,
where
everything
goes
all
at
once.
I
want
to
want
to
recall
flow,
real,
quick
to
make
sure
this
matches
what
everyone
has
in
their
head.
Everyone
who
sort
of
understands
the
keys
and
then
where
they
need
to
go
so
when
things
start
up
at
the
meaning
of
a
conference,
and
obviously
we
don't
have
the
call
level
signaling
in
here.
So
gonna
have
to
make
some
assumptions
about
that.
I
You're
going
to
have
dtls
Association
set
up
between
the
kmf
and
the
MDD
now
I
show
it
here
happening
in
one
direction.
I
think
that's
probably
going
to
depend
exactly
on
the
signaling
relationship.
We
have,
but
basically
message
once
you
forward.
Just
normal
TLS
set
of
mutual
authentication
is
important
here
and
then,
as
each
participant
joins.
So
like
participantes,
when
we
joined
first
and
message,
five
is
his
hello,
which
indicates
support
for
btls
srtp
aight
as
well
as
ekt,
and
this
is
tunneled.
I
K
O
O
I
F
K
I
Okay,
so
after
we
have
this
setup
and
after
this
penthouse,
the
keys
he's
going
to
use
towards
the
MDD
and
the
key
is
going
to
use
towards
the
other
participants,
we're
good
to
go
and
immediately
after
this
association
is
set
up.
The
km
f
is
going
to
if
he
has
already
generated
one
for
this
conference,
generate
a
new
apt
key
and
send
it
down
to
the
piston
using
the
tunnel
in
the
KT
CAC.
I
So
now
he
has
all
three
keys
that
he
needs
the
ETP
for
sending
his
hop
his
end
end
key
to
other
participants
and
as
he,
how
scared
he
needs
to
communicate
with
the
MTD.
Okay
next
slide
last
light.
Alright,
so,
basically,
as
other
Christmas
join,
you
have
the
same.
Exact
flow
happen.
They
could
be
vika
Tiki
and
you
end
up
with
Esther
to
be
being
exchanged
between
the
different
ends.
I
Be
can
actually
decrypt
the
information
being
sent
by
a
because
he
has
the
EK
Tiki
right,
make
sense
so
far,
just
normally
Katie,
basically
all
right
and
then
the
final
slide
just
shows
that
when
someone
new
joins
in
this
case,
participants
see
you
end
up
with
new
ekiti
sit
keys
sent
to
everyone
and
when
they
receive
that
they
change
their
own
local
key
that
they're
using
to
send
end
end
media
and
switch
over
to
new
ekt
key.
Now
there
is
an
open
question
here:
do
you
have
this
one
of
your
presentations?
I
Okay,
there's
an
open
question
here
about
timing
of
exactly
when
you
switch
over
to
the
new
key
that
we're
going
to
have
to
address
one
of
the
drafts.
I'm,
not
certain!
That
right
now
is
when
to
talk
about
that.
But
just
something
to
keep
in
the
back
of
your
mind
is
that
this
can't
really
be
instantaneous,
but
it's
going
to
be
very
close
to
instantaneous
on
the
order
of
like
a
second
or
less
and
that's
all,
I
have
so
who's
next,
a.
I
I
L
I
B
G
G
R
R
Question
is
if
this
models
can
be
used
to
improve
the
performance
of
immunities
to
share
a
common,
key
or
sample.
You
have
a
room,
ok
based
on
multiple
one
too
many
one
too
many,
so
you
can
sell
the
a
common
key
for
the
broadcasting
to
the
client
to
the
participants
in
a
room
with
this
model
be
used
in
this
case.
So.
F
R
F
I
R
R
I
G
C
F
I
I've
started
by
breaking
the
microphone
so
I'm
going
to
be
talking
about
a
double
which
is
a
way
of
using
srtp
to
have
these
hot
by
hot
keys
and
the
into
end
keys.
So
that's
one
draft,
there's
another
draft
I'm
going
to
talk
about
after
that
called
ekt,
which
is
about
how
we
get
everyone
to
have
the
same
Indian
keys
of
equipoise
next
slide
puts
so
you
know
what
what
Adam
was
saying
here.
You
know,
all
in
all.
I
I
So
it's
a
format,
sort,
security,
crypto
and
thinking
about
this
point
of
view,
where
we're
not
really
changing
things,
the
same
type
of
properties
we
have
today
from
the
point
of
view
of
integrating
internet
systems,
we're
trying
to
design
is
such
that
it
really
minimizes
the
impacts
on
the
participant,
endpoints
yep.
You
have
to
do
some
new
work
in
the
MVP
in
the
kmf.
We
all
want
to
build
that
stuff,
but
we're
trying
to
make
it
as
easy
as
possible
for
existing
endpoints
to
be
able
to
work
in
this
type
of
environment
next
slide,
please.
I
I
I
It
does
this
by
defining
new
okay,
so
finger
when
the
MDD
changes,
those
things
the
end-to-end
encryption
is
going
to
fail
or
off
a
confidentiality
check
is
going
to
fail
if
something
in
the
middle
change
them.
So
we
need
to
deliver
what
the
changes
were
and
what
the
original
values
were,
so
that
they
can
be
changed
back
by
the
receiving
end
point
before
this
authentication
check.
I
I
Next
slide
it
some
time
here
so
just
to
sort
of
walk
everybody
through
what
this
would
look
like.
Okay,
we're
going
to
start
on
the
endpoint.
We've
got
a
normal
RTP
packet
with
our
data
in
it
first
part
of
the
transforms
encrypting
it
with
the
end-to-end
key,
then
encrypts.
It
adds
in
the
original
header
values
or
whatever
things
that
no,
it
doesn't
messed
up.
Sorry,
it
encrypts
it
with
the
Aqua
hockey
and
then
not
on
every
packet,
but
on
a
packet
where
it
had
gotten
a
new
ekt
things.
I
C
I
Anything,
but
if
it
changes
some
things,
it
adds
in
some
extra
RTP
header
extensions
with
the
original
values
of
what
it
changed.
Rhian
Crips
the
hop
and
sends
it
on
to
be
e,
basically
reverses
that
takes
out
the
original
values
and
puts
them
back
in
to
check
that
nothing
was
tampered
from
the
original
int
impact.
So
that's
pretty
much
the
flow.
I
J
When
I
said
one
design
question,
why
do
you
I
mean?
Maybe
this
is
getting
too
much
into
the
weeds
by
their
buzzy
here?
No
sorry
I'm
going
to
walk
up
here
and
see
if
I
can
rebut
right.
Oh
yeah
fuzzy,
so
I
had
one
design
question
which
is
why'd.
You
decide
to
make
the
ohb
stuff
actually
had
our
extensions
as
opposed
to
just
parts
of
the
crypto
transform
format.
J
I
J
I
I
N
I
Integrity
protection
is,
is
here
computed
over
the
headers
and
the
payload,
just
like
normal
srtp,
when
we
do
that
a
second
time
exactly
the
same
thing
encrypted
over
a
protected
over
both
when
we
get
to
the
MDD,
it
is
going
to
recompute
the
hop
by
hop
one
with
the
integrity
over
all
the
RTP
header
extensions,
just
her
normal
srtp,
which
includes
these
new
ones.
We
added
okay,
so
when
we
go
to
decrypt
here
at
this
point
will
be
checking
integrity
across
this
whole
packet,
including
the
OHP.
Then
we
do
it
again.
I
So
one
thing
that's
been
discussed
is
some
people
proposed
well,
we
may
not
need
the
hop
by
hop
keys
or
encryption
integrity,
and
so
could
we
have
a
set
of
transforms
that
encrypted
in
the
end
and
integrity
and
Dan,
but
at
head
no
and
I
don't
know
what
you
want
to
speak
to
you
know
one
of
the
open
issues
doing
eat
these
or
not.
I,
don't
know
what
we
really
need
to
resolve
any
of
that
today.
It's
certainly
clear.
I
N
I
I
think
Magnus.
Do
you
wanna
speak
to
this
one?
At
all,
I
mean
this
was
I.
Think
Magnus
would
raise
the
case
not
where
there
would
be
no
integrity
for
these
packets,
but
they
would
be
provided
by
something
completely
separate,
like
you're
running
this
over
ipsec
hop-by-hop
in
the
3g
case,
or
something
or
so.
G
No
okay,
but
well.
What
do
we
talking
about
was
actually
using
like
plain
detail,
SMS
of
hope,
I
hope,
bank
analyst,
for
example,
to
protect
also
they
are
to
be
headers.
That
was
kind
of
the
point
of
proposal,
so
you
actually
get
the
confidentiality
and
integrity
by
all
delay
which
protects
the
whole
packet
and
not
reveal
the
start
of
your
header,
so
yeah
I
still
I
mean
I.
G
O
I
I
I
So
look
next
slide
here.
So
in
the
previous
thing,
with
double
were
what
I
was
talking
about.
You
know
what
we
were
going
to
do
with
these
keys,
but
now
we
need
to
figure
out
how
we
get
these
common
case.
So
the
initial
flow
that
Adam
talked
about
earlier
is
initially
a
forms.
This
DTLS
connection
up
to
the
kmf
and
negotiates
the
keys
negotiates
crypto
algorithm
when
it's
going
to
use.
We
double
in
this
case
and
negotiates
that
it
supports
the
sixth
engine
called
ekt
next
slide.
I
Now,
when
a
start,
sending
packets
to
be
a
takes,
the
srt
p
into
end
key
that
it
was
using
and
encrypts
that
with
this
common
ekt
key,
it
has
and
puts
this
in
this
ekt
field,
that
tags
on
the
end
of
the
packet
and
sends
it
over
to
be,
and
it
doesn't
need
to
do
this
for
every
packet.
You
can
think
about
it
happening
for
every
it'd,
be
fine.
If
it
did
it
very
back
and
other
than
make
them
all
bigger,
but
it
does
it
for
the
packets
early
on
when
the
key
changes.
I
If
a
participant
leads
the
conference,
a
new
key
ekt
cookie
gets
pushed
down
to
every
participant
and
everybody
starts
generating
new
sr
to
be
master
keys
that
bankrupted
everything
with
and
you
resend
thees
EES
again.
So
next
slide
the
media
receiver,
you
know
they
just
they
use,
they
got
pushed
the
same
akt
key.
They
use
it
to
decrypt
EKG
field
where
they
find
the
srtp
master
key
that
they
can
use
to
decrypt
the
BS
RTP
packet.
They
received
next
slide.
I
S
I
The
EK
tiki,
what
actually
the
details
of
what
actually
gets
sent
is
we
send
the
cypher
that's
being
used,
the
actual
key
value
we
also
send
some
math
srtp
needs
master
salt
for
all
for
the
various
transform.
We
send
the
salt
as
well,
so
everyone
has
the
same
salt
and
we
send
some
integer
we're
calling
SPI
right
now
that
uniquely
identifies
the
ekt
key
and
that
actually
you'll
see
later
gets
sent
unencrypted
in
srtp.
So
you
know
which
key
to
use
as
keys
revolve
change
from
one
to
the
next.
So
next
slide.
I
F
I
And-
and
you
know,
I'm
going
to
be
a
little
bit
inconsistent
here
of
sometimes
using
kita
means
specifically
the
key
and
sometimes
the
whole
field.
We
really
have
some
naming
problems
in
this
draft
and
I'd
like
that,
fix
that
too.
So,
on
the
ekt
field
that
we
attached
to
the
end
of
the
srtp
packet
to
deliver
to
the
other
side,
it
contains
an
encrypted
version
of
the
SSRC.
We
need
that
to
stop
some
cut
and
paste
attacks,
the
rollover
counter
and
the
srtp
master
key
that
we're
using
for
encrypting
that
media
flow.
I
So
it
encrypts
all
of
that
using
this
EKG
key
information,
and
it
takes
that
plus
the
SPI
which
it
adds
on
the
end.
So
we
can
in
a
fighh
it
that's
unencrypted
and
that
forms
the
whole
ekt
field
that
gets
put
to
the
end
of
the
packet
and
sent
to
the
other
side
that
can
be
used
as
decrypting
at
all
of
this
information
and
notice.
I
I
Actually,
having
seen
these
drafts
split
apart,
like
this
I,
like
the
idea
of
splitting
up
the
drafts
as
much
as
we
can
putting
the
base
ekt
stuff,
that
we
need
for
perk
in
one
draft
and
then
having
extension
drafts
that
rely
on
that
for
the
Mikey
stuff
and
SS.
If
anyone
wants
to
move
forward
with
those,
let's
just
split
these
up,
we
can
and
it
makes
it
much
easier
to
understand.
I
do
the
draft,
and
it
also
brings
up
the
question
of
where
we
you
know.
J
I
Next
slide:
ok,
Krypto
sizes
that
came
up
earlier
next
slide.
So
kick
transition
time.
This
problem
authorities
topics
in
this
thing.
Imagine
the
case
where
we
got
a
bunch
of
participants.
They've
all
got
the
same
ekt
key
about
media
flowing
between
everyone
and
somebody
leaves
the
conference
and
we
want
to
recue
the
conference.
So
we
send
down
a
new
ekt
key
to
everyone
and
everybody
who
receives
that
makes
a
new
srtp
master
key
and
starts
transmitting
their
data
with
this
new
key.
I
Any
media
that
was
sent
with
the
new
key
before
you've
gotten
the
key
to
receive
it.
You'd
have
some
sort
of
glitch
in
the
media.
So
there's
been
lots
of
talks
about
complicated
ways
to
ensure
that
everybody
has
the
same
key
before
you
start
using
it.
But
the
problem
is
really.
You
want
to
kick
this
person
out
of
the
conference
as
quickly
as
possible
and
you've
got
a
human
perception
time
of
how
long
it
seems
normal
to
get
rid
of
somebody.
I
So
my
proposal
here
is
just
say:
don't
use
the
new
ETA
T
key
to
encrypt
media
until
250
milliseconds
after
you've
used
it
and
if
it
takes
you
longer
than
250
milliseconds
to
get
the
new
ekt
key
yeah.
There
might
be
a
little
bit
of
lost
media
here,
but
this
is
really
easy
to
implement
and
all
the
other
schemes
look
really
complicated.
So
this
is
direction.
I'd
propose
going
on
this
I'm.
L
I
G
Wisdom
I
mean
one
thing
you
can
do
is
to
actually
use
the
ground.
She
tells
of
measurements
not
to
CP,
to
figure
out
kind
of
the
how
big
the
common
sense.
At
least
you
can
ensure
that
you
have
had
some
shells
to
getting
it
in
place.
Crossley
cap
it
at
the
maximum
value.
I
love
like
one
or
tuesday,
but
and.
I
So
the
data
road,
so
one
of
the
things
when
I
was
thinking
who
this
earlier
today
was.
If
we
put
this
in
the
spec
and
it's
implemented
in
client,
it's
kind
of
out
there
in
the
field
and
immutable.
If
we
go
down
the
path
that
I
know
we
were
discussed
in
the
past,
we
basically
have
a
synchronized
point
in
the
future
that
everyone
switches
that
is
communicated
by
the
server,
and
that
means
it
is
an
administrative
tasks
to
change
the
way
at
any.
Given
conference,
acts
and
I.
I
Think
that
probably
is
going
to
be
a
lot
more
flexible.
Allow
us
to
deal
with
a
lot
more
things
that
we
can't
anticipate
in
the
future,
so
I'm.
How
about
then
to
solve
that?
We
just
what
do
you
think
would
be
a
good
idea
than
two
in
the
when
we
deliver
the
ek
ek
from
the
kmf
to
the
participants
that
we
passed
in
that
same
record.
We
include
this
number
so
that
you
can
just
configure
in
the
cam
app
and
it
can
push
it
every
client.
Basically,
yes,
on
the
con
those
lines.
R
Hello
Miguel
bodies
of
cuento.
I
think
that
the
police
more
complicated
in
my
in
that
an
employee
a
and
create
a
packet
one
with
a
eight.
And
while
the
packet
is
internal,
call,
the
damn
phone
be
received
a
reiki,
the
new
key
and
how
they
am
going
be
and
now
that
they
are
get
one
from
a
sensitive
with
the
old
e.
I
So
this
is
the
opposite
thing
where
you
end
up
with
a
key
change.
Well,
there
are
still
media
packets
encrypted
in
flight
in
the
network
and
I
think
that
we
also
need
to
have
a
timing.
Delay
for
that
and
I.
Don't
have
a
slide
on
that,
but
we
do
have
that
in
the
drafts
of
using
the
old
being
willing
to
decrypt
packets
received
with
slightly
old
keys
for
a
small
amount
of
time
a
time
that's
consistent
with
network
delay,
not
as
something
that's
like
five
minutes
am.
I
I
Next,
one
okay,
this
john,
this
one
is
sort
of
a
semi-related
to
this
right
now
the
DSP
is
are
just
a
unique,
a
15
bit
identifier
and
if
they
at
least
increase
monotonically
I
think
it
helps
deal
with
the
replay
problems
because
you
know
which
one's
older
and
newer
so
I
don't
have
a
concrete
proposal
on
this
yet
and
it's
not
in
the
drafts,
but
I
think
that
we're
going
to
need
to
do
something
like
this
to
to
make
sure
to
really
simplify
thinking
about
replay
issues.
Now
these
are
only
Pat.
I
You
get
these
over
this
dtls
channel.
Where
you
have
a
real
positive.
You
know
I
properly
encrypted
thing
with
the
other
one
people.
So
it's
it's
hard
for
an
attacker.
You
know
attacker
that
doesn't
have
the
credentials
of
the
kmf.
Can't
really
reply.
One
of
these
to
you
at
the
giving
you
a
new
ekt
field.
I
I
N
I
I
Let's
go
look
at
whether
we
have
a
problem.
If
we
do
I
think
russ's
point
is
exactly
on
point
right:
we
need
to
include
one
over
any
integrity
on
in
the
integrity
check
and
make
it
like
so
well.
Yeah.
Let's
go
figure
that
out.
I
need
to
go
reread
the
mailing
list.
I,
don't
think
we
have
a
problem
on
this.
I
Ok
in
conferences,
there
are
often
things
that
are
robots
that
might
be
able
to
play
announcements
into
the
conference
like
a
new
person
joint
or
a
beep,
but
cannot
actually
hear
any
of
the
media
of
the
comp.
They
have
no
need
to
actually
be
able
to
listen
to
the
conference
or
the
media
of
the
conference,
so
one
of
the
proposals
was
well
could
quit
the
kmf
send
out
an
e
Katie
key
that
was
used
only
by
that
type
of
right.
I
Only
you
know,
contribute
only
devices
and
Mark
that
key
such
that
it
was
contribute
only
and
that
you'd
be
receiving
it
over
longer
periods
of
time.
So
if
we
go
down
this
path
that
moves
us
to
the
state
where
we
might
have
multiple
active
ekt
keys
at
the
same
time
for
long
time
periods,
not
just
when
you're
transitioning
from
one
to
the
other,
so
it's
a
it's.
Certainly
a
design,
that's
possible
here
and
we
need
to
think
about.
Is
it.
K
K
K
G
Real
question
is:
is
what
key
does
the
announcement
server
happy,
yeah,
so
Roni?
The
important
thing
is
to
say
the
mvd.
Should
the
one
control
him
you
should
be
able
to
game
the
conference
to
get
hold
of
the
key
and
as
soon
as
it
gets
hold
of
the
conference
keys,
it
has
control
over
all
the
media
streams
and
can
tap
them
as
they
wanted
to
do
so,
and
the
question
is
this
announcement
server
this
robot
trusted
if
there's
coming
from
the
LED,
which
have
this
kind
of
hold
function
cetera?
No,
it's
not
the
trusted
entity.
G
L
Think
it's
also
probably
worth
calling
out
explicitly
whether
we
you
know
kind
of
to
this
point
whether
the
fact
that
the
MDD
is
is
full
optimal
of
the
MDD
is
able
to
do
a
denial
of
service
attack,
there's
a
whole
bunch
of
different
venues
through
which
that
can
happen
and
I.
Think,
like
my
assumption
throughout
all
this,
has
been
that
that's
an
understood,
possibility
and.
I
L
L
O
O
I
Is
it
interesting?
We
are
thinking
about
Harold
here,
you're
right,
it's
from
security
point
of
view
it's
the
same,
but
it
would
mean
that
you
were
you
know.
Two
conferences
would
be
to
DTLS
connections.
This
would
be
one
details,
I
mean
it's
bit
be.
The
difference
will
be
only
the
optimizations
of
throwing
in
the
same
and
I.
Don't
know,
I
think
that's
a
good
way
of
thinking
about
it.
What
is
the
real
gain
of
this
perfect?
Okay?
So
let
me
just
back
up
to
the
whole
two
sets
of
documents.
I
just
talked
about.
F
Well,
for
example,
when
you
set
up
when
a
participant
joins,
it
does
a
detail
on
handshake
with
the
kmf,
and
then
the
kmf
is
supposed
to
hand
it
a
key
or
using
the
kmf,
then
hands
the
end
of
the
participant,
a
key
if
we're
using
a
Katie
Katie
for
that
hand
out
a
key
function.
That
means
that
the
kmf
has
to
send
an
SRT
p
packet.
F
I
S
Okay,
so
I'll
try
to
make
this
one,
let's
earthquake,
because
I
think
there's
still
some
other
stuff
you
need
to
get
through
on
the
agenda.
So
this
is
the
deep.
We
are
okay,
good,
alright.
So
this
is.
This
is
just
going
to
talk
about
the
dtls
tunnel.
Maybe
I
can
answer
some
of
the
questions
that
people
have
had
about
the
tunnel.
S
You
know
the
next
slide,
so
the
first
and
foremost,
we
tried
to
make
sure
that
the
you
know
with
the
whole
solution
using
the
tunnel
where
we're
trying
to
not
make
any
changes
to
dtls
or
detail
SSR
GP,
so
you'll
you'll
see
there's
no
court.
You
know
we
don't
have
to
go
change
any
of
those
specs
or
using
those
as
they
are
currently
defined,
the
MDD
and
they
came
back.
S
They
establish
a
dtls
association
with
each
other
and
that
is
called
the
tunnel,
have
a
picture
that
will
show
later
endpoints
and
the
kmf
they
that
they
established
the
dtls
association
with
each
other
by
way
of
that
tunnel.
So
so
that's
the
way
that
the
MPD
and
they
can
they
well
write.
The
MDD
will
fault
whether
this
is
just
the
DD
will
forward
to
pack
us
to
the
km
bath
and
kmf
wilson
and
back
by
way.
The
MPD
with
the
important
point
here
is
the
MTD
in
the
km
f
or
the
invoice
kmf.
S
Rather
they
established
the
dtls
association.
So
there
is
question
earlier
about
security
right
so
that
those
two
have
an
association.
The
other
thing
the
reliability
is
left
to
dtls.
So
you
tell
us,
you
know:
there's
there's
a
timeout.
If
you
send
a
message,
you
don't
get
a
response
assumption
as
you
send
it
again
right.
So,
for
example,
the
ekt
message
that
gets
set.
There's
an
e
katie
act
right,
so
I'm
assuming
betting.
If
it's,
if
you
don't
get
the
ekiti
key,
oculus
you'll
rescind
it
so,
the
reliability
mechanisms
are
left
to
ekt.
I'm.
S
Sorry
are
left
to
dtls,
so
we're
not
introducing
a
new
protocol
overhead
for
that.
The
KML
also
gives
the
EMP
DV
hop-by-hop
key
salt
values.
So
we
mentioned
that
earlier.
So,
let's
repeat
it!
So
if
you
want
to
go
to
that
next
slide,
so
this
was
real,
simple,
alright,
so
the
first
thing
that
we
do
and
and
I
think
it's
probably
clear
now
but
I
know
it
wasn't
clear
before
the
first
step
is
the
MDD
in
the
kmf
established
a
DTS
association
with
each
other,
and
that
is
called
the
tunnel
right.
S
So
that
is
a
detail.
Last
association
there
that
persists
and
there
can
be
one
or
more
DTLS
associations-
and
you
may
want
to
do
that
providing
reasons.
But
but
we
just
for
simplicity,
we
just
consider
there's
there's
one
next
slide,
so
whatever
Alice
joins
the
conference.
The
first
thing
that
happens
is
that
alice
is
going
to
try
to
establish
the
dtls
association
with
the
KML
and,
as
was
mentioned
by
Adam,
and
you
know
those
questions
raised
on
the
floor.
That
goes
through
the
mvd
up
to
the
camera.
S
So
the
the
end
point
just:
does
normal
dtls
srtp
type
signaling
just
is
it
if
we
were
doing
a
point
of
my
call,
it
doesn't
really
know
because
it
knows
it's
a
perk
conference
because
of
other
things,
but
but
at
least
this
part
of
the
code
would
be
exactly
the
same
as
if
it
were
point-to-point
call
sends
it
up
to
the
MDD
and
the
end.
If
that
establishes
the
association.
S
Now,
when
the
MDD
forwards,
it
there's
a
there's,
an
association
identifier,
we'll
get
into
the
protocol
bits
here
in
a
minute,
so
there's
an
association
that
then
a
fire
that
the
MPD
will
put
on
to
the
tunneling
protocol.
So
when
it
sends
the
dtls
message,
it
actually
wraps
it
inside
of
another
protocol,
a
tunnel
protocol
and
the
purpose
for
that,
of
course,
is
that
we,
the
MDD,
is
handling
lots
of
endpoints.
So
it
can't
just
forward
up
a
message.
S
It
doesn't
know
which
end
point
it
belong
to
and
when
it
gets
a
response
back,
it
doesn't
know
which
one
to
send
it
to
so
we
have
this
very
lightweight
following
protocol
and
the
mvd
also
advertises
which
security
profiles
of
support.
So
because
the
endpoint
does
this:
do
normal
DTLS
srtp
with
the
endpoint,
the
MDD
needs
to
be
able
to
tell
the
km
f
which
security
profiles
it
actually
supports,
so
that
that
that
we
can,
we
can
reach
an
agreement
on
which
encryption
cipher
suite
we're
going
to
use
actually.
S
You
know
it
could
be
a
nib
message
that
initiates
like
the
EK
teehee
message,
so
whatever
it
sends
a
message,
the
dtls
message:
it
puts
it
inside
the
tunnel
that
sent
it
out
of
the
MPD
and
includes
that
Association
identify
that
the
mvd
had
this
allocated
for
Alice
before
so
that
that's
used
to
identify
each
each
of
the
participants,
dmdd
them
forwards
at
over
to
Alice
next
Laye
alright.
So
this
is
the
very
high
level
view
that's
similar
to
what
Adam
had
in
his
presentation.
S
So
there's
a
detail:
s
handshape
that
goes
on
and
then
there's
the
tunnel
message
plus
the
profiles.
Now
it's
written
a
little
bit
odd,
but
there's
a
there's,
a
basic
tunnel
message
in
if
there's
any
extra
stuff
that
gets
appended
onto
the
end.
So
is
the
tunnel
message
plus
the
profiles
it
gets
sent
over
the
key
of
F
and
then
they
came
off
just
since
a
tunnel
message
back.
That
includes
whatever
it's
going
to
sin
and
it's
and
it
continues.
S
And
well
once
it
once,
it
finishes,
you'll
see
at
the
at
the
point
where
it
sends
the
key
info
at
the
very
last
step.
Once
once
the
the
handshake
is
finished,
it
sends
the
finished
message
over
to
to
the
end
point
k,
MF
and
when
it
does
that
it
includes
the
key
information,
that's
used
for
that's
what
the
key
info
is
here.
So
that
way,
the
MDD
has
the
key
information
that
needs
in
order
to
do
corporations
and
the
N
through
dtls
srtp,
which
is
inside
this
stuff.
C
S
So
this
is
just
the
tunnel
message
and
it
could
be
optimized
in
a
few
ways,
but
this
is
just
put
here
just
to
show
what
we're
trying
to
do,
but
there's
a
version
in
case.
We
want
to
reversion
it
and
it's
taking
too
long
cats
only
because
I
was
using
TLS
in
tax
and
I
converted
it
down
to
two
what
it
looks
like,
and
you
know
this
form,
so
it's
a
little
probably
larger
than
we
need
there's
an
association
identifier
that
was
intended
to
be
about
60
knock
pets.
S
Just
so
we
could
put
it
like
a
uuid
or
something
like
that
to
identify
the
association
and
then
there's
a
message
length
and
then
what
the
details
panel
data
is
so
that
that's
the
basic
tunnel
message.
So
every
ever
message
from
the
endpoints
are
from
the
MTD
up
to
the
km
a
from
the
kmf
back
then
the
MVP.
I
have
this
as
a
at
least
at
the
start.
S
Thanks,
like
an
all
messages
going
from
the
MDD
to
the
cave,
mouth
will
always
have
this
supported
profiles
and
the
reason
for
that
we
could
put
it
on
the
first
message.
But
if
the
first
measures
happiness
to
get
lost,
then
point
retransmits
a
handshake
message,
and
that
goes
up
with.
If
the.
If
the
kmf
doesn't
know
what
security
profiles
are
supported
by
the
MVP,
then
it
doesn't
know
what
to
go.
She
ate
with
the
endpoint
because
it
has
to
be
able
to
MDD.
S
Has
the
kmf
rather
has
to
take
into
consideration,
what's
supported
by
the
mvd
and
what's
supported
by
the
end
point
when
it
tries
to
determine
which
crypto
sweets
to
use
and
so
wow,
so
on
that
that
it
advertises
the
equip
the
security,
the
protection
profiles,
so
that
the
data
type
here
is
is
really
could
be
called
message
type.
But
I
felt
odd
putting
in
calling
message
type
and
it's
like
at
the
bottom
of
the
message,
and
the
message
is
the
tunnel
message.
S
C
S
S
This
is
the
the
more
complex
one
so
once
the
once
the
once,
the
the
entire
process
complete
the
the
kmf
needs
to
be
able
to
provide
the
MDD
with
with
with
all
the
the
the
key
material
that
that
have
that
you
know
that
it
generated
through
the
dtls
srtp
exchange,
because
the
diesel
SSR
could
be
exchange
happens
between
the
kmf
and
the
MDD
or
between
the
end
points
and
the
kmf,
the
acronyms
all
messed
up,
because
that
exchange
happens
there.
The
mvd
doesn't
have
access
to
it.
S
So
this
is
the
way
for
the
AMF
to
provide
the
MDD
with
that
key
information.
So
essentially,
this
block
that
you
see
at
the
bottom
is
exactly
what
gets
produced
out
of
the
detail:
SS
RTP
exchange,
so
we
have
the
client
right,
override
client,
read
and,
and
so
the
rewrite
keys
and
the
end
of
salt
values.
So
those
get
all
handed
down
to
the
MTD.
So
it
has
that
information
and
that's
it.
That's
that's
the
way
that
subtle
protocol
work.
E
G
V
G
G
S
Giving
the
MTV
MTU
size
is
something
to
consider
the
only
thing
if
we're
going
to
use
DTLS
we
have
to.
We
have
to
just
do
something:
to
ensure
that
endpoints
don't
send
those
large
messages
make
the
record
smaller
then
would
be
necessary
to
just
take
into
consideration.
Knows
it's
going
to
be
tunneled
out.
J
I
G
G
F
The
desserts
are
going
to
wash
everything
out
by
an
order
of
magnitude,
but
we
are
talking
about
you
know
if
you're
doing
256-bit
AES
you've
got
each
of
these
master
keys
is
sixty
four
octets
right
and
signs
four
of
them
is,
is
a
bunch
yeah.
So
that's
it's
a
non-trivial
addition,
especially
here
well
yeah.
So
they
say
you,
it's
not
implausible
that
you
run
into
any
issues
this
way,
but
I
think
the
general
points
probably
valid
that
it
might
be
worth
looking
at
alternative
transports
turn
the
tunnel
either
TLS
or
something
like
data
channel.
S
S
F
F
C
B
H
J
There
is
hard
to
talk
when
this
is
a
buzzy
there.
The
principal
I
mean
I
feel
like
that.
There's
often
been
the
principal
that
devices
pick
their
own
right
keys
because
they
trust
their
own,
our
energies
and
not
necessarily
other
people's.
So
this
whole
the
k
MF
x,
the
md
DS
hop-by-hop
keys,
makes
me
a
little
bit.
J
I
J
I
C
J
W
Be
you're
sitting
there
well
Jesus,
okay,
yeah
conceptually
I'm,
going
to
keep
running
up
against
similar
things
as
I
think
about
this
Jonathan,
and
it's
because
it's
so
hard
for
me
to
map
this
on
to
the
three
domains
of
applicability
that
I
imagine.
The
signaling
is
going
to
transpire
over
what
it
looks
like
an
RTC
web.
What
it
would
look
like
it.
S
W
Much
better
yeah,
so
I
think
what
does
it
say
about
that
was
just
that
yeah,
a
lot
of
the
confusion,
I
think
I've
heard
throughout
the
discussions
that
this
has
actually
been
along
those
lines.
Actually
the
lungs
out.
Why
do
you
trust
a
cat
that
right
and
you're
trusting
the
kmf?
If
you
think
it's
yahoo
com
depends
on
the
back,
there
are
some
signaling
solution
for
this
you're
imagining
that
is
behind
this.
That's
you
know
where
you
got.
You
have
reference
integrity
from
some
UI
that
right
was
originally
inputted
to
the
system.
H
W
That
guy
and
you
know,
I
looked
at
the
Charter
actually
and
I
saw
their.
These
deliverables
are
actually
like
kind
of
defining
using
verticals
for
this.
That
were
I
think
actually
before,
at
least
in
the
list
of
you
know,
deliverables,
not
necessarily
in
the
milestones
before
the
part
where
we
define
the
SRQ,
p
extensions,
and
so
long
for
this
and
I
I
guess
I
feel
like
having.
That
would
be
super
useful
to
helping
people
keep
straight.
W
Why
it
is
that
this
architecture
is
the
way
it
is
I,
think
it's
a
sound
architecture,
right,
I
think
it
actually
does
all
make
sense
and
that
you
can
go
forward
with
this,
and
it
will
actually
work
for
those
cases,
but
I
doubt
that
we're
going
to
be
able
to
get
much
consensus
to
establish
that
without
at
least
one
of
those
kind
of
you
like.
We
did
this
for
weber,
q
SE
and
I
said
okay.
W
C
V
Melissa,
daddy
I'm,
I
kind
of
agree
with
Jonathan.
This
is
a
rub
me,
the
wrong
way
for
yeah,
so
it's
for
seeing
it
and
I
I.
Just
wonder
not
because
of
the
aspect
that,
whether
or
not
you
trust
the
kmf,
but
just
from
the
pure
security.
You
know,
Prince
ilysm,
you
know
don't
do
things
that
necessarily
traditional
vulnerabilities.
Key
distribution
is
a
hard
thing
that
usually
introduces
vulnerabilities
and
having
to
distribute
keys
another
set
of
keys
that
are
independently
generated.
V
You
know
from
from
the
cave,
if
to
the
mvd
ads,
you
know,
potentially
some
some
security
vulnerabilities
that
that
you
can
eliminate
by
by
deriving
them.
You
know,
as
as
today,
independently
and
only
known
to
each
other,
so
I
I
do
kind
of
agree.
Even
if
you
fully
trust
the
kmf,
it
does
still,
you
know,
go
against
some
established
security
principles
to
do
key
distribution
to
it.
Instead
of
just
doing
a
symmetric,
you
know
key
gen,
independently.
F
J
Don't
like
so
many
other
point,
I
guess
I
might
make.
Is
that
you
know
on
the
principle
of
you
know,
give
everybody
that
you
know
least
knowledge.
They
need,
there's,
no
reason
why
the
ADF
should
need
to
know
any
other
half
I
up
key,
so
I
mean
I,
can't
think
of
a
threat
model
where
that
would
be
a
problem,
but
I
also
don't
see
any
reason
why
it
needs
to
know
them.
Oh.
F
J
C
T
F
If
you
don't
think
we
should
adopt
it,
please
come
now:
okay,
I
heard
several
in
favor
and
not
against
so
I'm,
going
to
call
that
and
we'll
confirm
it
on
the
list:
Oh
Miller
to
the
mic,
Matt
Miller
challenge
for
Randall.
He
also
approves
he
agrees
great.
So
what
will
confirm
this
on
the
list,
but
that
sounded
pretty
good.
Next
question:
hey
Ben
sounds
like
we
need
ekt
here
on
it's
currently
elsewhere.
What
would
you
think
about
us
taking
on
a
milestone
to
do
the
core
part
of
it
that
we
require
I.
K
J
F
F
But
assuming
that
revision
goes
well
when
people
feel
comfortable
calling
for
adoption
on
the
list
for
that
one,
seeing
nodding:
okay,
good
so
we'll
get
that
done
good
and
we'll
have
two
deliverables.
I
think
I
wrote
these
before
we
got
into
the
tunnel
discussion.
I
think
we've
got
some
good
feedback
on
tunnel
there's
some
of
the
right
stuff
going
on.
F
We
might
need
some
revision
the
transports
and
we
might
even
need
some
idea
of
what
the
signaling
looks
like
performing
nail
down
much
more
of
the
interactions
on
the
tunnel,
so
I
think
Paul.
We've
got
some
good
feedback
to
to
ponder
on
to
the
tunnel
draft
before
we
get
to
the
point
adopting
all
right
thanks:
everyone
that
was
productive,
yeah
Magnus.
What.