►
From YouTube: IETF100-PERC-20171117-0930
Description
PERC meeting session at IETF100
2017/11/17 0930
https://datatracker.ietf.org/meeting/100/proceedings/
A
B
A
D
D
D
The
documents
were
working
on
the
the
framework
and
the
actual
signaling
drafts
they
expired,
but
I
assume
we
will
get
back
to
them
once
we
have
moved
the
the
biggest
problem.
The
double
actually
forward,
yeah
and
tunnel
and
hopefully
followed
double
agenda
for
today,
Richard
is
going
to
cover
the
ekt
and
double
I
will
present
the
one
slide
on
on
the
tunnel.
I'm,
not
sure.
If
we
we
can
convince
Paul
to
to
give
us
an
update
on
the
on
the
framework,
but
the
thoughts,
the
only
one
slide,
yeah
good
any
any
agenda.
D
B
B
D
B
Yes,
so
those
who
think
back
to
the
last
IETF
meeting
the
major
issue
is
kind
of
how
we
laid
out
the
inner
outer
and
ohb
components
of
the
devil
encryption
things.
So
we
read
jiggered
things
to
be
a
little
more
friendly
to
the
use
cases
that
sergio
and
company
had
in
mind.
That
is
still
the
major
outstanding
issue
here.
So
we've
made
some
progress
in
terms
of
you
know,
proving
out
the
the
base
transform
in
some
implementation,
but
we
still
need
to
figure
out
how
that
implements
with
the
art
r-tx.
B
In
fact,
stuff
has
Sergio's
mail
to
the
list
earlier
this
week
pointed
out
so
I
think
colon
has
that
PR.
If
they're,
explaining
how
things
work
review
on
that
and
comments
would
be
helpful
and
then
I
think
I've
got
an
action
to
work
with
Sergey.
It's
it's
kind
of
proofs
into
this
out
in
code
and
see
what
it
looks
like
other
than
that
I
think
we
just
need
to
get
Nils
as
review
address
the
comments
you
sent
and
get
the
document
wrapped.
B
So
once
we
get
the
recovery,
stuff,
read
and
r-tx
stuff
of
both
suspect
and
have
some
confidence
that
it
works,
I
think
this
will
be
pretty
much
done.
I
think
the
the
base,
the
basic
encryption
stuff
I,
think
is
pretty
solid
at
this
point
is
just
the
recovery
stuff.
We
need
to
to
flush
out
the
last
few
changes
and.
D
B
B
C
Had
one
quick
thing
on
back
on
double
we're
fully
closed
on
all
of
the
effect
and
r-tx
issues,
and
we
don't
know
if
anyone
having
outstanding
issues
with
the
salute.
What
the
solution
proposed
anymore
so
can
go
ahead
and
close
flex
fix
design
and
not
worry
that
we're
gonna
have
anything
else
to
revisit,
because
we're
about
to
push
that
to
work
with
plus
call
and
progress
that
oh,
the.
C
C
C
D
B
B
B
Clearly,
I
am
NOT
an
expert
in
all
of
these
areas.
Recovery
technologies
can't
even
tell
them
apart,
so
ekt
has
had
a
little
bit
more
dramatic
change.
You
know
there's
this
overall
flow
in
ekt,
where
the
client
and
server
negotiates
they
negotiated
key
encryption
key
and
then
they
churn
SRTP.
The
the
SRTP
keys
are
transmitted
unto
that
key
encryption
key.
Actually
sorry,
there's
there's
three
steps.
You
negotiate
a
cipher
that
you're
going
to
use
for
key
in
Cybermen.
Then
one
side
sends
a
key
encryption
key
to
the
other
and
then
an
SRT
P.
B
The
the
traffic
encryption
keys
are
sent
encrypted
under
the
key
encryption
key.
So
it's
kind
of
three
steps.
The
first
step
has
always
is
isn't,
has
always
been
done
in
a
TLS
extension,
because
it's
there's
there's
no
confidentiality
concerns
with
that.
The
third
step
is
and
always
has
been
done
in
SRTP
in
tags
appended
SRTP
packets.
The
the
motion
here
is
is
in
terms
of
where
the
key
encryption
key
is
sent
because
that
needs
to
be
encrypted
under
the
DTLS
key
negotiated
by
the
et
Ossa
handshake.
So
it
needs
to
happen
after
the
D
TLS.
B
So
I
think
in
the
last
rev
it
had
been
a
new
detail,
s
frame
type,
which
turns
out
to
be
a
kind
of
not
well
oiled.
Extension
point
in
in
TLS
stacks
handshake
messages
are
something
where
there
is
more
of
evolution,
especially
in
TLS,
1
3
in
detail.
That's
1
3
coming
up,
there's
going
to
need
to
be
some
changes
in
the
sax.
Do
that
anyway,
and
so
ended
up
with
a
pattern
here
that
basically
looks
like
a
pattern:
the
tls
one
three
uses
for
doing.
B
He
updates
post
handshake,
but
in
a
way
that
can
kind
of
be
back
ported
to
TLS
one
two,
so
we
don't
inherit
a
one
three
dependency
so
anyway.
The
overall
pattern
for
ekt
is
in
the
document.
Now
you
do.
You
negotiate
the
cipher
in
an
extension,
as
we
said
before,
you
finish
the
handshake
once
so
now
that
you've
got
transport
encryption
keys
for
the
TLS
layer,
then
the
key
distributor
sends
the
key
encryption
key
under
that
DTLS
key
to
to
the
other
side,
and
then
you
do
the
the
same.
B
B
Well,
there
wasn't
ambiguity
in
the
last
rivet
so
which
side
in
that
which
of
those
two
roles
could
send
a
key
encryption
key
with
ekt
thinking
through
this
with
following
Colin
the
it
seemed
like
the
simplest
thing
to
us
was
to
nail
it
down
to
say
that
the
side
that
sends
the
key
encryption
key
for
for
ekt
must
be
the
the
TLS
server
so
that
the
key
and
ekt
the
the
key
encryption
key
any
KC
is
always
sent
by
the
TLS
server.
So
that
has
some
implications
for
the
signaling
right.
B
You
need
to
always
arrange
that's
the
when
you
do
the
signaling
for
a
per
conference.
You
need
to
always
arrange
that
the
key
distributor
is
the
TLS
server
as
the
DTLS
server
in
that
interaction,
but
it
simplifies
a
lot
of
the
negotiation
kind
of
removes
the
race
condition
in
terms
of
who
sends
the
keys
for
to
have
that
that
restriction.
So
that's
that's!
What's
in
the
document
now
and
with
that
I
think
the
open
issues
we've
got
are
are
all
closed,
so
I
think
it
would
be
helpful
to
have
an
editorial
pass.
B
Someone
who's,
maybe
not
editorial.
What
kind
of
a
comprehensibility
pass
said?
I
get
some
fresh
eyes
and
someone
who
hasn't
been
in
this
document
a
whole
lot
already
to
see
if
it's
understandable
and
implementable
by
by
someone
who
hasn't
come
before
but
technically
I
think
the
the
open
issues
are
all
closed
and
there
are
some
draft
patches.
I
think
I
have
a
draft
patch
of
the
last
revision
for
OpenSSL,
but
there's
at
least
a
little
bit
of
work.
They
starting
to
be
done
in
terms
of
getting
this
interface
in
system.
E
Guess
that
support
is
very
dusty,
so
I
think
it
might
be
rip
it
out
and
survive
from
scratch.
It
could
be
so
I
mean
one
concern.
I
have
about
the
TLS
server
constraint
is
until
we've
done
of
the
mappings
to
the
various
protocols.
I
think
we
can't
necessarily
know
whether
there's
some
weird
corner
cases
where
there
might
be
a
problem
like
I
mean
if,
when
we
do
the
mapping
to
sipper
we're
gonna
discover
that
they're,
like
third
party,
call
control
cases
where
it's
ambiguous
who's
supposed
to
be
the
TLS
server
or
something
wacky
like
that.
B
E
E
B
Have
to
think
about
if
you've
got
some
ideas
for
how
to
keep
that
flexible
I.
The
trouble
is,
if
you
don't
have
some
negotiation
to
decide
who's
the
sender,
then
you
get
into
some
potential
conflicts
in
terms
of
what
the
key
encryption
key
applies
to
there
like
I,
think
the
reason
we
have
we
debit
designated
centers
so
that
one
side
can
set
the
key
and
it
can
apply
to
keys
going
in
both
directions.
E
Absolutely
agree
that
it
makes
sense
for
only
one
one
endpoint
to
be
the
key
distribution.
I
think
that
in
that
sort
of
inherent
door,
the
way
our
architecture
is
working,
but
probably
unless
the
CKD
has
meant
to
be
broader
than
just
perfect.
But
maybe
it
is.
But
we
were
sure
that
there
aren't
in
the
case
where
we
need
bi-directional:
P
distribution,
well,
I'm.
E
B
B
D
D
D
H
H
There
there
were
a
few
editorial
Corrections
I
made
to
the
framework
document,
such
as
changing
the
words
media
distributing
the
media
distribution
device
to
be
a
distributor.
There
were
a
few
places
that
they
weren't
changed
before
that
should
have
been
I,
updated,
some
references
in
particular
RFC
767,
because
it
used
to
be
a
draft.
That's
why
RC
I
clarified
some
of
the
language
relating
to
trusts,
in
particular
trust,
trust
and
innocence
of
Kirk
means
that
you
trust
an
endpoint
with
miggy's.
H
It
doesn't
have
anything
to
do
with
whether
or
not
a
device
actually
functioning,
as
it's
supposed
to
so
I
just
innocently
wish
to
clarify
that
I
also
moved
and
updated.
Some
of
the
text
related
key
exchange
with
some
primary
objective.
What
that
was
to
to
make
just
to
clarify
procedures.
It
wasn't
intended
to
change
procedures
that
are
certainly
welcome.
Any
input
on
those
changes
also
clarified
client-server
roles
when
they
appoint
communities,
distributor
and
that's
something
that
we
was
just
mentioned
a
moment
ago
that
the
clients
an
issue
connection.
H
It
is
the
it's
the
client,
not
the
server
in
the
detail.
Ss
or
the
exchanges
clarified
that
all
the
conference
participants
use
the
same
master
of
salts
and
that's
something:
that's
just
an
artifact
of
the
way
percs
design,
and
that
was
made
clear
and
the
framework
document
and
also
added
some
texts
saying
that
the
hop-by-hop
key
renegotiation.
If
it's
to
be
done,
it's
done
using
a
section
if
I've
got
two
of
our
c
5-7
6-4
and
I
think
that's
all
of
the
changes
in
the
text
and
that's
it.
That's
all
change.
D
All
right,
that's
all
what
we
had
for
today
on
the
agenda:
Creek
Creek.
Thank
you.
Everyone
for
for
next
steps,
I!
Guess
we're
going
to
wait
for
like
a
new
version
of
double
with
the
changes
and
we
get
the
the
reviewers
which
volunteered
here
to
submit
the
feedback
and
then
get
out
a
new
version
before
the
London
meeting
and
we'll
see
if
we
can
get
another
working
group
last
call
on
that
before
London
or
around
London,
and
so
no
for
pre-k
TR.