►
From YouTube: IETF110-CORE-20210308-1600
Description
CORE meeting session at IETF110
2021/03/08 1600
https://datatracker.ietf.org/meeting/110/proceedings/
A
Okay,
welcome
everybody
to
this
first
co-working
group
session
at
the
itf
110
meeting
charizard
marco
tilocami
and
jaime
jimenez,
who
couldn't
be
here
for
this
meeting,
and
we
have
the
next
slide
to
give
a
hint.
Why
next,
please.
A
So
jaime
is
happily
busy
again
with
his
newborn
son
and
as
we
like
to
think
training,
future
working
group
chairs
and
this
place
we
haven't
standing
chair
for
this
meeting
carson
bormann.
Thank
you
very
much
for
kindly
being
supportive
in
in
this
occasion,
and
congratulations
again
to
jaime
next,
please
yeah,
a
bit
of
practicalities.
Of
course,
as
usual,
we
assume
people
attending
the
session
to
have
read
the
documents
discussed
today.
A
We
are
trying
to
make
good
use
of
the
time
during
this
meeting
to
solve
open
issues,
especially
the
note
well
applies
more
on
that
on
the
next
slide
and
as
a
reminder,
blue
sheets
are
automatically
compiled
in
this
myth
echo
mythical
meetings.
I
will
be
jabra
scribe
for
this
session
and
I
understand
we
have
michael
richardson
as
minion
taker
confirmed,
michael.
A
A
Very
much
I'll
also
help
otherwise
not
well
apply
as
usual.
Please
get
familiar
with
us
if
you're
not
already
it's
not
only
about
ipr
and
payments,
it's
just
it's
also
about
a
code
of
contact
so
be
polite
and
nice
with
each
other.
A
Next
slide.
Please,
okay!
Please
use
the
key
request
feature
on
miteiko
to
enter
and
leave
the
queue
the
hand
on
the
top
left
of
the
window.
You
can
just
jog
there
I'll
be
described.
I
can
relay
your
comments
or
questions,
and
this
meeting
is
recorded
and
again
no
need
to
fill
any
attendance
list
explicitly
next,
please
all
right
and
more
nice
news.
For
today
we
are
again
changing
aed,
the
leaving
aid
very
labor.
A
Right
now
and
during
the
week
there
will
be
the
the
formal
end
of
to
francesca
palumbini's
new
id
in
the
earth
area
and
responsible,
especially
for
core.
So
thanks
to
barry
again
and
welcome
francesca,
and
if
you
two
want
to
say
something:
please
do.
D
Okay,
I
hesitated,
I
saw
francesca,
try
to
jump
in
hi
everybody
thanks.
Thanks
for
the
support
you
guys
have
given
me
over
the
time
and
thanks
for
being
an
easy
working
group
to
manage
and
getting
a
lot
of
work
done.
So
you'll
still
see
me
around.
A
Next
slide,
please
right.
This
is
the
agenda
for
today,
which
is
essentially
including
all
the
security
related
works,
also
to
avoid
a
collision
with
the
danish
buff
on
friday,
and
we
start
with
group
communication
documents
continuing
on
other
security
works
and
cachable
score
and
combining
oscar
with
edoc
and
the
recently
work
on
cypher
limits,
especially
apply
to
the
oscore
protocol.
A
Next
slide,
please
yeah,
anticipating
the
agenda
for
friday,
we'll
discuss
something
points
on
one
of
the
core
comp
documents
currently
under
shepard
write
up
and
look
at
the
advanced
twos
and
ml
documents
now
active
same
for
new
block
and
dialing.
These
are
all
working
group
documents
and
we
conclude
another
two
documents
on
resource
directory
extensions
and
a
new
proposal
on
data
centric
deployment
for
co-op.
A
A
Just
done
that
so
next
and
next,
so
I
think
in
january,
8974
was
published
as
an
rfc
used
to
be
the
core
stateless
document.
Thank
you
very
much
to
klaus
and
michael,
especially
in
the
final
stages
and
to
the
whole
working
group
for
this
achievement.
A
And
then
we
have
a
bunch
of
almost
there
documents.
Dave
urn
is
already
in
the
editor
queue
and
for
the
resource
directory.
A
We
could
finally
see
that
day
yesterday
when
it
was
formally
approved,
and
there
are
other
working
groups
and
documents
that
have
as
many
reasons
to
celebrate
about
this,
like
especially
one
document
in
in
l
week,
echo
request
tag
also
requires
some
final
editing
from
christian,
if
I
remember
correctly,
to
address
comments
from
from
ben
and
roman,
otherwise,
it's
also
very
close
to
to
take
the
final.
The
final
step
thanks
a
lot
for
all
this
work.
A
Next
slide.
Please
right.
We
have
two
of
the
four
core
conf
documents,
meaning
young
sieber
and
seed-
that
are
right
now
in
las
colon
till
mid
next
week
and
as
francesca
suggested,
we
also
requested
for
both
of
them
a
review,
an
additional
review
from
from
young
doctors.
A
Right
as
to
the
other
two
qr
code
documents
they
are
under
shepard
right
up,
young
library
seems
to
be
essentially
done
while
there
have
been
new
open
points
raised
during
the
write-up
for
the
comic
document,
and
they
will
be
discussed
also
with
eva
law
in
the
friday
session.
A
A
Two
more
open
points
to
work
on
sentimental
data
ct
has
just
incorporated
working
groups
called
comments
and
with
a
little
synchronization
about
the
content
of
another
document
that
was
also
discussed
in
dispatch
today
is
possibly
ready
to
move
forward
and
and
same
for
the
new
block
draft
that
has
also
incorporated
working
plus
comments
and
is
also
in
the
agenda
for
the
friday
session
next
slide.
Please,
though,
I
think
that
was
all
for
the
summary.
E
A
F
B
B
Not
talking
my
usual
way
of
showing
slides
in
chrome
doesn't
work,
so
I'm
using
a
different
thing
and
that
of
course,
doesn't
always
work
either.
So
just
go
ahead
and
talk.
F
Meanwhile,
the
slides
are
visible
great,
so
we'll
skip
this
one
because
we've
presented
it
a
number
of
times.
It's
just
a
reminder
of
the
scope
of
the
document
so
currently
focused
on
any
udp
multicast
based
group
communication
for
co-op,
so
the
general
updates.
I
will
now
go
through
them,
so
we
have
adapted
the
text
to
allow
this
thing.
F
F
F
Let's
see
yeah,
so
the
reverse
proxy
can
basically
do
the
group
request.
So
the
client
will
do
a
unicast
request
to
the
proxy.
The
proxy
will
do
a
group
request.
The
proxy
can
also
handle
following
unicast
requests,
so.
F
Yeah,
that's
basically
a
reverse
proxy
and
it's
made
to
look
like
a
normal
server
basically,
and
we
now
also
reference
specifically
a
signaling
protocol
for
proxy.
So,
as
we
listed
before
a
number
of
issues
for
forward
proxies
and
reverse
proxies,
we
now
have
this
reference
to
drafty
loca
core
group
proxy-
that's
authored
by
marco
and
me-
and
it
also
has
a
signaling
protocol,
as
will
be
explained
later,
to
address
these
issues.
F
Now
one
major
addition
is
the
caching
model,
so
we
already
have
the
clash.
Caching
at
the
client
side,
of
course,
responses
and
now
we
basically
add
the
caching
in
the
proxy
as
well
so
for
proxy's.
Caching,
we
did
at
least
marco
did
a
quite
thorough
analysis
on
that,
and
it
turns
out
you
have
to
work
with
two
types
of
cache
entries.
So
one
is
the
individual
cache
entry
for
a
single
response
from
a
single
server.
F
F
F
Also,
the
responses
get
added
to
a
list,
l
and
that
list
l
will
basically
later
be
used
to
make
an
aggregated
cache
entry
that
collects
all
the
responses
for
that
particular
request
and
at
the
bottom
of
the
slide
you
can
see.
There's
some
lifetime
handling
also
to
be
done
for
the
cache
entry.
So
it
looks
at
the
max
age
of
all
the
responses
to
compute
combined
max
h
or
the
aggregated
cache
entry.
F
Yeah,
the
caching
model
continues.
So
basically,
your
unicast
request
can
also
be
sent
to
the
proxy,
and
then
it
can
receive
a
response
from
the
server
to
that.
So
the
response
is
forwarded
and
then
it
creates
an
individual
cache
entries
or
updates
the
existing
one,
and
it
also
will
look
in
the
aggregated
cache
entries.
Basically.
F
Yeah,
it
can
also
basically
update
the
aggregated
cache
entry
with
an
individual
response
and
also
that
may
influence
the
lifetime,
so
we'll
basically
scan
all
the
entries
again
and
correct
yeah
the
lifetime.
So
the
lifetime
of
an
aggregated
entry
is
always
the
minimum
of
the
lifetimes
of
all
the
entries
that
are
in
there.
F
Okay,
let's
go
to
the
next
slide,
so
also
the
validation
model
is
a
separate
section
from
caching
yeah.
So
in
the
code
rfc,
this
was
not
addressed
in
detail.
Now
we
try
to
do
that,
so
the
validation
works
between
client
and
servers,
and
for
that
we
introduce
a
new
option.
The
multi
etac
option-
and
this
can
only
be
used
for
group
requests,
so
it
will
basically
yeah
be
like
an
e-tag
only
that's
in
the
e-tag.
F
And
the
nice
thing
of
this
is
that
at
the
server
side
the
the
server
doesn't
have
to
think
about.
Okay.
What
kind
of
e-tech
should
I
generate
so
that
clients
can
can
distinguish
between
all
the
possible
servers,
but
it
just
generates
an
etag
as
usual,
and
the
client
can
use
this
option
to
basically
pick
big
responses
that
it
has
cached
and
to
validate
if
they
are
still
correct.
B
F
Yeah,
the
existing
option
is
to
target
one
particular
server
in
the
group
and
it
has
an
basically
a
sequence
of
etag
elements
in
there.
So
that's
for
this
particular
server.
If
you
wanna
address
multiple
servers,
so
you
say
tag
one
on
server
one
and
tag
three
on
server.
Two,
for
example,
then
you
need
two
of
these
options,
so
that
does
not
fit
in
one
option.
In
the
current
definition.
F
Okay
yeah,
so
this
was
between
client
and
proxy,
so
that's
basically
only
meant
to
address
these
aggregated
cache
entries
that
are
newly
introduced,
so
you
can
basically
validate
an
entire
group
response
as
a
client
and
in
case
yeah
in
case
that
is
still
fresh.
You
can
basically
get
the
validation
confirmation
from
the
cache
like
okay.
This
is
still
a
fresh
group
response.
You
can
use
the
entire
thing
and
there's
no
need
to
do
a
new
group
request
in
this
case,
but
it
can
be
used
in
get
and
fetch
group
requests.
F
And
yeah
it
works
quite
for
the
rest,
quite
similar
to
the
normal
co-op
validation.
So
using
the
group
e-tec
option:
yeah.
Okay,
let's
go
to
the
next
one,
taking
the
time,
there's
also
the
security
question.
Of
course,
what
we
have
discussed
so
far
is
without
security,
or
at
least
without
end-to-end
security.
F
We
also
consider
it.
What
can
we
do
going
through
a
proxy
with
end-to-end
security?
Can
we
still
cash?
Well,
it
turns
out
it's
not
that
straightforward,
but
it's
possible
by
using
the
deterministic
requests
that
are
introduced
in
this
draft
ralph
hamsu's
core
cacheable
score
and
it's
limited
to
restful,
safe
requests
that
have
no
no
side
effects
on
the
resource
at
the
server
as
like
a
guest
and
a
fetch,
for
example,.
F
So
the
client
has
to
prepare
this
specific
deterministic
request
to
be
able
to
do
this
and
response
revalidation,
that's
not
not
possible
in
all
cases.
So
we
have
listed
a
couple
of
cases
below
it
is
possible
between
origin,
client
and
origin
servers
using
the
multi-etag
option,
but
there
are
some
complications
when
doing
data.
So
if
you
change
the
request
only
a
little
bit,
then
it
means
oh,
I
have
to
use
a
different
deterministic
request,
so
it's
gets
into
quite
a
lot
of
complexity.
F
To
do
this,
so
that's
what
we
basically
yeah
try
to
provide
an
overview
of
what
you
can
do
and
what
you
cannot
do.
Okay
next
slide,
please.
F
So
we
have
an
open
point,
one
of
several
actually
in
github.
I
think
that's
the
question:
what
is
the
most
appropriate
place
for
these
new
items
that
we
introduced?
F
So
that's
basically
for
a
client
to
be
able
to
validate
individual
responses
from
a
group
of
servers
that
looks
like
it
could
also
be
yeah
in
separate
dedicated
documents,
because
it's
really
a
new
new
thing
here
and
not
yeah,
not
something
existing
in
co-op.
That
we
want
to
explain
in
the
group
communication
context.
But
it's
really
a
new
new
feature.
F
Personally,
I
think
we
could
also
add
maybe
how
the
normal
e-tec
option
can
be
used
in
group
communication
scenarios,
because
that's
also
still
possible,
with
some
limitations,
of
course,
and
then
number
three
is
the
group
etec
option?
So
that's
basically
specifically
validating
a
group
of
responses
at
the
proxy
that
could
go
typically
also
in
the
group
com
proxy
document.
That's
what
it's
about
or
maybe
it
can
stay
in
group
combis.
F
G
H
Yeah
hi
esco.
Yes,
just
a
few
questions
on
this
and
I'm
trying
to
understand
the
multi
e
tag
and
the
group
beta
do
you
have
do
you
have
any
simple
examples
for
when
I
would
like
to
use
one
or
the
other
option
here?
H
F
Yeah,
so
that's
yeah,
I
don't
have
any
real
concrete
example,
but
you
could
say
that
suppose
you're
reading
status,
information
of
a
group
of
devices
and
yeah,
like
one
of
these
devices,
for
example,
has
a
particular
large
status
report
that
I
already
got
last
time,
and
I
maybe
don't
want
to
get
it
next
time,
so
you
can
basically
put
it
multi-etec
in
yeah,
just
stating
okay,
I
have
this
version
of
your
status
report.
Yeah,
don't
yeah,
don't
send
it
if.
H
Okay
and
the
security
for
that
there
was
some
part
of
the
antenna.
Security
was
not
possible.
I
mean
that
that's
definitely
proxy
to
origin
server
so
that
that's
not
an
end-to-end
security
secured
option
right.
F
A
A
Right
now,
this
is
mimicking
the
etag
option
in
tesma
properties,
so
you'd
be
processed
in
the
same
way,
and
this
would
be
the
result.
A
G
H
Right:
okay,
good
well,
yeah,
I
can
think
more
of
it.
We
don't
need
to
stop
stop
the
presentation
now,
please
thank
you.
G
F
We're
very
quiet,
so
the
next
steps
for
this
draft.
We
have
review
comments
received
from
john
still
to
be
addressed.
I
think
there's
quite
some
good
comments,
including
okay.
Can
we
yeah?
I
think
that
was
one
of
the
questions
too,
to
make
it
more
generic
as
or
not
only
target
co-op
group
communication
over
udp
multicast,
but
also
consider
which,
which
part
could
be
applicable
to
yeah.
Another
transport
layer
like
a
ip
group
cast
for
co-op
and
more
reviews,
would
always
be
good.
F
I
From
from
the
levels
of
maturity
between
the
the
e-tags
and
the
the
e-pads
that
and
the
rest
of
the
of
the
group
compass-
and
I
think
it
might
be
a
good
idea
to
to
treat
the
etag
into
more
in
something
like
the
proxy
document
that
doesn't
that
has
no
ambitions
to
progress
in
the
same
pace
as
the
group
of
other.
The
group
companies,
because
I
think
that
the
the
group
com
is
get
getting
good
compass
out
is
valuable
and
the
and
the
e-text
thinks
things
are
valuable.
F
I
It's
not
proxy
related,
but
it's
related
to
the
to
the
transport
address
stuff
that
up
in
the
proxy
document.
So
maybe
it
could
still
look
there
because
it
has
commonalities
there.
F
F
A
A
All
right,
this
latest
version
was
mostly
about
addressing
a
very
good
and
useful
review
that
we
got
from
christian
on
version
10.
Thank
you
very
much
for
that
and
a
number
of
other
points
we
discussed
and
agreed
on
at
the
november
meeting
last
year,
following
that,
we
think
we
have
still
two
open
points
that
I
will
overview
shortly
later.
One
discussed
with
christian
during
the
hackathon
about
admitting
the
recycling
of
group
ids
in
the
same
group
and
one
related
to
a
comment.
A
We
got
from
ben
cadoc
on
the
list
about
the
current
usage
of
identity
keys
for
both
signing
and
diffie-hellman
operations.
Next
slide,
please
right.
First
of
all,
we
eventually
converge
to
a
single
and
simpler
format
of
external
led
to
be
used
both
for
the
encrypting
and
designing
operations
and
in
simplifying
it.
We
remove
the
used
to
be
par
counter,
sign
key
as
inner
inner
element
describing
the
algorithms
used
in
the
group
or
actually
the
property
of
the
key
type,
and
this
is
also
a
much
more
consistent
and
aligned
with
the
common
context.
A
So
this
is
what
the
document
body
says
and
it
works
right
away
with
all
the
algorithms
we
have
registered
in
cozy
today,
but
also
based
on
the
discussion
at
the
november
meeting,
we
added
a
new
appendix
providing
a
general
template
to
follow
to
build
the
par
counter
sign,
parameter
in
the
external
led
and
the
corresponding
parameter
in
the
common
context
for
the
future
case,
when
possibly
more
cosy,
algorithms
will
be
registered
with
zero
or
more
than
one
capabilities,
so
it's
essentially
just
a
future
friendly
to
be
followed
and
if
you
take
it
and
use
it
today
with
the
algorithms
registered
today,
you
end
up
with
the
main
definitions
that
are
already
in
the
document
body
next
slide.
A
Please,
okay,
then
we
also
realized
that
it
was
possible
to
optimize
a
little
bit
response
messages
by
not
necessarily
including
the
kid
in
the
oscar
option
of
such
messages.
The
kd
must
still
be
included
in
the
response.
A
If
the
respond
is
intended
to
a
request
that
was
protected
in
group
mode,
because
the
responder
could
be
any
of
the
server
in
the
group,
but
otherwise
the
exact
mode
used
to
protect
the
response
doesn't
really
matter
and
that,
especially
when
the
pairwise
mod
is
used,
allows
the
save
pretty
much
buys
on
the
wire,
and
we
also
relaxed
the
rules
that
were
previously
preventing
recycling
center
ids
all
together
in
the
group.
A
Well,
now
it's
forbidden
only
under
the
same
group
id
if
that
changes,
because
of
the
group
ranking
it's
possible
to
reuse
sender
ids
under
the
new
group
id
and
according
to
all
the
changes
I
mentioned
so
far.
We
have
also,
of
course,
updated
the
examples
of
protected
messages
in
the
draft.
A
We
we
try
to
improve
also
the
reasons
why
there
there
may
be
a
loss,
even
if
partially
of
a
security
context
in
case
due
to
memory
limitation,
eventually
a
node
in
the
group
which
is
the
maximum
amount
of
recipient
contexts
that
it
can
have.
So
if
one
more
has
to
be
created,
it
has
to
to
delete
an
old
one
to
to
leave
room
for
the
new
one,
but
the
moment
this
happens
from
now
on
any
newly
created
recipient
context
will
be
created
with
an
invalid
replay
window
that
has
to
be
fixed.
A
Assuming
replay
checks
are
still
important
and
they
are,
and
in
order
to
do
that
well
either.
The
node
in
question
participates
to
a
group
for
king
which
of
course
results
in
changing
its
sender.
Id
sorry
is
sequence
number
reset,
or
it
has
to
run
a
proper
exchange
like
with
the
echo
option,
as
with
defining
appendix
e
and
as
a
positive
side
effect.
You
also
get
a
freshness
of
the
just
received
request
that
that
was
resulting
into
the
university
and
context.
A
This
was
also
an
opportunity
to
make
it
even
clearer
that
remaining
able
or
becoming
again
able
to
enforce,
anti-replay
and
achieving
freshness
are
a
few
different
things
and
freshness
is
the
one
related
to
achieving
synchronizations
with
the
sequence
number
of
clients
which
can
be
achieved
using,
for
instance,
the
the
echo
exchange
next
slide.
Please
right.
Some
editorial
changes
is
still
pretty
major
I'll
say
we
reorganized
a
lot.
The
section
discussing,
in
fact,
the
loss
or
partial
loss
of
security
context
trying
to
to
express
in
a
much
clearer
way.
A
The
pattern
cause
effect
causes
can
in
fact
be
a
loss
of
mutable
security
context
because,
for
instance
of
rebooting,
because
the
the
maximum
number
of
recipient
contacts
have
been
reached
or
the
exception
or
send
the
sequence
number,
and
the
effect
would
be,
of
course,
to
request
new
key
material
for
from
the
group
manager.
That
can
just
be
end
up
in
getting
a
new
sender
id,
but
in
a
way
or
another,
this
node
will
reset
its
sender.
A
Sequence
number
anything
will
be
adjusted
again:
section
nine,
defining
the
pairwise
mod
was
essentially
rewritten,
of
course,
to
keep
the
same
mechanics.
A
But
now
it's
written
as
a
delta
from
the
oscar
rfc,
as
christian
also
requested,
adding
also
a
small
number
of
things
picked
up
from
this
document
again
and
it's
group
mode,
especially
when
it's
about
support
for
observe
and
for
synchronization
and
achieving
freshness.
Now
we
have
only
the
echo
exchange
approach
as
appendix
c,
while
we
just
removed
the
other
previously
included
approaches,
as
they
simply
became
when
thinking
more
more
about
them.
A
Next,
please
all
right.
The
first
of
the
two
open
points.
First
of
all,
as
related,
we
realized
something
we
intended
all
along
is
not
explicitly
mentioned,
and
it
should
even
odd
rejoins
the
group
and
when
doing
so
of
course
it
gets
a
new
sender
id.
It
must
explicitly
terminate
all
the
observations
it
has
ongoing
and
just
as
a
reminder,
in
fact,
observations
are
supposed
to
survive
a
change,
a
change
of
group
id
you,
for
instance,
to
to
a
king
in
the
group.
A
So
so
far
we
were
forbidding
the
recycling
of
group
ids
all
together
in
a
group,
meaning
that
groups
cannot
live
forever
and
that
was
forbid
the
forbidden,
especially
to
avoid
a
possible
problem
with
long-living
observations.
In
fact,
so,
for
instance,
you
can
have
a
a
client
see
one
that
starts
an
observation
with
that
tuple
current
gid,
kid
of
the
client
partially
one
so
to
say
later
on,
for
some
reason
that
same
client
gets
a
new
kid
totally
fine.
The
observation
continues
with
the
same
original
tuple.
A
Then
the
group
is
rekeyed
several
times
the
gid
changes
because
of
that
and
eventually
the
gid
drops
and
gets
back
to
gd1
still.
Fine
problem
is
if
a
new
client
gets
accidentally
the
same
kid
that
c1
had
when
he
started
the
observation
and
by
really
bad
luck.
That
second
client
starts
totally
legitimately
any
observation
with
the
same
tuple
and
now
you
have
troubles
because
you
can
have
one
notification
that
matches
either
observation,
which
is
bad.
A
So
we
had
to
solve
this
problem
to
admit
recycling
of
group
ids
and
next
slide.
Please
we
discussed
about
this
during
the
acaton
and
we
found
a
way
to
to
fix
this.
It's
sufficient
to
introduce
a
little
more
logic
on
the
group
manager.
A
Basically,
when
a
node
joins
and
gets
back
from
the
group
manager,
the
group
id
to
consider
in
the
group.
At
that
moment
the
group
manager
stores
for
long
term
that
group
id
as
the
perth
gid
of
that
node
and
same
for
other
journey
nodes,
so
say
at
some
point.
The
group
manager,
for
whatever
reason,
has
to
rekey
the
group
and
distribute
a
new
gid.
A
The
group
manager
checks
if
any
current
group
member
has
as
its
birth
g
id
the
new
gid
to
be
assigned
to
the
group.
If
that's
the
case
well,
the
group
rakhine
that
the
group
manager
is
going
to
perform
will
take
that
into
account
and
it
will
rekey
the
group
in
a
way
that
those
nodes
are
excluded.
A
A
Eventually
they
will
rejoin
and
if
they
do
so,
they
get
a
new
sender
id
and
they
reset
their
certain
sequence
number
and
they
have
to
kill
their
ongoing
observations
and
the
original
problem
that
forced
us
to
forbid
group
id
recycling
would
be
gone
and
bottom
line.
Then,
with
this
little
addition
on
the
group
manager,
groups
can
live
forever.
A
H
What
are
you
saying
is
that
you
actually
keeping
track
of
group
members
for
the
purpose
I
mean
in
in
terms
of
the
birth
gid,
then
for
the
for
the
purpose
when
they
later
rejoin,
if
they
are,
if
there
are
conflicts,
so
you
you
can
handle
those
later
or
what
or
how
does
this.
A
A
Okay
next
slide,
please.
A
Second
and
last
open
point,
not
at
all
less
important.
This
was
raised
by
ben
keduck
on
the
list
supporting
the
pairwise
mode.
Here
we
are
essentially
using
the
same
identity
key
for
two
for
two
possible
usages.
One
is
well
signing
messages
in
group
mode
and
one
is
deriving
a
different
man
secret
to
be
used
to
generate
the
pairwise
keys
and
overall,
it's
all
about
the
same
single
policy.
A
Protected
communication
in
the
group
with
the
value
security
context,
but
still
this
this
double
use
is
not
exactly
a
common
best
practice.
So
if
you
go
for
it,
you
really
need
to
to
to
prove
that
what
you
are
doing
is
secure
and
there
is
in
fact
ongoing
work
to
prove
that,
possibly
with
some
minor
minor
addition
in
in
the
exact
derivation
step.
This
is
in
fact
secure
at
least
for
group
of
score
and
the
the
ongoing
proof
is
trying
to
be
built
on
the
paper
we're
already
referring.
A
That
was
focusing
on
the
ecis
settings,
although
it
was
not
limited
to
that,
so
that
proof
can
in
principle
be
readapted
to
be
valid.
For
for
a
group
of
score
and
just
as
a
note,
the
the
pairwise
mod
per
se
is
actually
all
fine.
The
the
comment
here
is
on
the
actual
double
use
of
the
same
key
in
the
process
of
key
derivation,
so
just
to
be
on
the
safe
side.
A
There
would
be
an
alternative,
although
inconvenient,
to
make
this
a
key
provisioning
problem
and
just
go
for
two
separate
keys,
one
for
signing
and
one
for
defeatment,
but
they
would
be
just
inconvenient
and
the
last
resort,
because
you'd
mean
more
provisioning
and
more
storage
overhead
with
the
provisioning
most
likely
to
happen
in
the
ace
document
defining
the
joining
and
the
key
provisioning
with
the
group
manager.
A
Okay
next
slide,
please
we
should
really
be
the
rope
up
yeah
next
steps
are
addressing
both
two
open
points
in
version
12
submitted,
hopefully
having
addressed
both
of
them
in
a
good
enough
way
and
most
likely.
That
version
would
be
a
candidate
to
be
considered
to
be
stable,
to
move.
G
H
Yeah
yeah,
I
was
talking,
so
how
is
how
is
this
draft
aligned
with
the
co-op
group
com?
Is
there
any
reason
to
to
move
this
before
the
sort
of
co-op
group
commission
the
same.
A
H
Or
less
so
it
will
be.
This
draft
will
sit
and
wait
in
in
in
the
working
group
before
until
the
other
draft
is,
is
ready.
A
Yeah,
the
same
can
can
be
true
for
the
other
one,
depending
on
which
one
is
finished.
First,.
H
Okay,
so
what
do
you
mean
by
ready
to
move
on?
What
is
the
meaning
of
that?
H
Okay,
but
will
you
do
that
before
the
before
the
group
come
is
in
the
same
state.
F
Yeah,
I
just
question
you
you
mentioned
doing
the
the
proof
for
this
usage
of
the
key
for
two
purposes.
F
Are
you
going
to
wait
basically
until
that
paper
is,
for
example,
accepted
and
reviewed
before
moving
on
this
draft,
or
is
it
kind
of
independent.
A
It's
in
between
it's
an
ongoing
research
effort
and
ericsson.
Actually,
so
probably
euron
can
give
more
details.
H
So
there
is
already
a
a
draft
of
a
paper
which
is
intended
to
be
a
pre-print.
This
is
a
colleague
of
mine,
who's
been
working
on
that
and
whether
that's
going
to
be
a
published
paper
or
just
a
sort
of
a
preprint,
it's
it's
basically
building
on
other
papers
and
putting
things
together.
So
so
it's
that
I
mean
this
particular
researcher
asked.
If
is
this,
do
we
really
need
to
publish
this,
or
is
it
just
do
we?
H
Could
we
have
this
as
a
as
a
note
basically,
but
it's
obviously
good
if
we
get
some
some
review
on
that
on
that
proof,
so
I
think
that's
that
should
be
an
ambition,
but
I
don't
think
the
working
group
I
mean
it's
sufficient,
probably
that
someone
from
from
the
itf
community
reviews
that
it
doesn't
have
to
be
a
sort
of
a
presented
paper,
at
least
not,
I
don't
think
that's
necessary
for
for
progressing.
G
A
I
So
this
is
about
how
can
how
can
a
device
that
is
supposed
to
be
in
a
group
discover
all
the
details
that
it
needs
to
join
the
group
just
next
slide,
please
giving
a
brief
recap:
the
device
may
only
know
the
the
key
material
or
may
not
only
know
something
about
the
group
manager,
but
not
the
full
joining
resource,
and
the
group
manager
may
not
even
be
here
yet.
I
So
this
is
using
the
regular
mechanisms
we
have
in
co-op
with
a
focus
on
the
resource
directory
that
makes
the
whole
process
more
efficient
throughout
research
lookup.
It
receives
where
the
where
the
particular
joint
joint
joining
node
is
on
the
group
manager
to
join
that
to
join
that
to
join
that
group
next
slide.
Please
we've
updated
the
document
recently
to
reflect
to,
lastly
reflect
changes
in
in
other
parts
of
the
ecosystem.
I
It's
now
well
aligned
with
with
all
most
of
the
documents
that
it's
referring
to
the
there
are
a
few
new
target
attributes
that
are
that
allow
the
joining
node
to
identify
in
advance
the
possible
groups
that
it
could
join
and
to
see
how
it
would
join
them
so
making
the
drawing
processing
itself
more
efficient.
I
I
Our
examples
are
now
up
to
date,
with
both
the
link
format
and
with
coral
and
during
the
before
and
during
the
hackathon.
We've
had
this
running
on
an
off-the-shelf
resource
directory
and
michael
performed,
basically,
all
the
single
steps
that
are
involved
in
this
in
this
process
against
the
resurrectory,
and
I
could
in
parallel,
see
how
things
work
from
there.
So
it's
tested
and
it's
tested
to
an
extent,
although
not
from
interoperability
between
one
group
manager
from
here
and
another
part
from
there
next
slide.
I
So,
of
course,
a
resource
tractor
that
is,
that
is
not
fully
trusted,
can
do
all
basically
can
all
do
all
those
things
that
it
can
do,
that
is,
it
can
hide
the
presence
of
a
group
it
can
give
wrong
addresses,
because
everything
that's
happening
on
on
the
on
the
oscore
side
is
agnostic
of
the
of
the
addresses,
so
traffic
could
be
redirected,
even
though
the
the
encryption
itself
would
not
be
endangered
and
that's
probably
the
worst
of
those,
and
we
are
still
looking
into
how
this
is
best
addressed
and
which
attributes
this
needs
to
be
addressed.
I
False
information
obtained
by
the
client
could
lead
to
it
using
a
non-preferred
cypher
suit,
and
this
definitely
needs
to
be
addressed
more
clearly.
Let's
start,
please
other
than
that.
It
needs
a
bit
of
a
bit
of
updates,
referring
with
respect
to
the
examples
with
the
latest
resource
directory
changes,
but
most
of
those
are
really
on
tasks
that
can
be
done
in
in
the
course
of
time.
So
for
us,
it's
really
really.
I
The
next
step
would
be
to
get
a
bit
more
comments
from
the
working
group
as
to
is
this
now,
something
that
the
working
group
could
see
could
could
see
is
useful
to
to
have
inside
the
working
group
or
what
do
we?
What
kind
of
comments
do
we
need
to
expect
when,
when
this
is
moving
forward
in
general,
next
slide?
Please
so
that's
it
from
my
side.
Thank
you.
Questions.
A
And
nothing
on
jabber
either,
so
we
can
move
to
the
next
one.
On
multicast
notifications.
I
Which
which,
like
the
like
the
q
group
communication,
is
something
that
I've
repeatedly
presented
here
so
I'll
cut.
The
recap
short
again
use
case,
so
the
group
communication
documents
we've
talked
about
so
far
are
all
about
the
case
where
request
goes
out
to
multicast,
and
the
responses
have
so
far
always
been
unicast.
Only
with
this.
I
We
describe
next
slide,
please
how
responses
can
be
multicast
and
where
this
could
be
useful,
which
is
primarily
when
a
lot
of
parties
regularly
request
something
and
want
this
to
have
this
new
in
an
observation
where
they
can
all
share
the
data
and
don't
have
to
re
to
register
separately
next
slide.
Please
mechanically.
I
This
happens
by
having
a
took
having
a
token
that
the
server
that
they
agree
on
and
the
point
and
the
and
the
party
that
makes
the
final
decision
is
the
server,
because
it's
the
best
point
we
can
come
up
with
with
all
score.
This
also
means
that
they
have
to
have
a
particular
request
that
they
all
refer
to,
because
otherwise
the
unprotection
would
simply
not
work
next
slide
please.
I
This
is
all
these
details
are
all
communicated
in
an
error
response
which
contain
which
tells
the
client
that
I
won't
answer
this
particular
request,
but
you
can,
if
you
had
sent,
if
you
were
sending
this
request,
then
you
could
be
observing.
You
could
receive
the
notifications
on
this
particular
token
sent
to
that
particular
multicast
address
and
in
the
protected
case,
with
this
particular
external
aad.
I
So
what
changed
in
since
dash
of
five
since
dash
o5?
Well,
not
so
since
before
in
the
latest
revisions,
is
that
the
format
we
have
is
now
a
bit
more
well
defined
and
also
aligned
with
the
other
work
we've
talked
about
earlier
with
about
transport
addresses,
as
they
would
be
used
in
proxies
for
group
communication,
which
is
which
really
need
parts
of
the
same
data,
so
aligning
this
makes
it
easier
for
implementers
to
to
use
code
here.
I
So
what
it
contains
is
the
information
the
the
ad
the
server
address,
the
the
group
address
the
token
and
then
a
request
that
would
the
client
would
have
needed
to
send
and
possibly
a
response.
So
if
that
last
notification
is
not
present,
this
behaves
like
in
regular
co-op
an
observation
with
an
empty
act.
I
I
That
array
is
just
like
in
the
processing
case,
also
extensible.
So
if
the
currently,
there
is
only
one
transport
that
can
handle
multicast,
that
is
code
over
udp,
which
is
something
that
involves
a
server
host,
a
server
port,
a
client
host,
a
client
port
and
a
token
if
we
ever
have
any
other
transports
that
behave
completely
differently.
I
We
have
the
extension
point
there
to
say
protocol
say
two
is,
or
probably
some
higher
number,
because
proxying
would
might
take,
might
take
different
use,
different
numbers
as
well.
That
number
is
co-op
over.
I
We
are
now
more
explicit
in
that
we
do
not
negotiate
for
this
feature.
This
is
something
we
had
in
very
very
early
drafts,
but
removed
it,
because
the
use
cases
that
we
see
are
the
ones
where
it's
not
feasible
to
cater
for
an
individual
client's
request.
I
So
if
you
do
have
use
k,
if
you
do
see,
use
cases
where
some
clients
might
be
observing
resources
individually
and
others
might
just
switch
to
the
large
pool
of
multicast
recipients,
please
tell
us:
let's
talk
about
it,
and
then
we
can
figure
out
whether
this
is
something
just
specify
right
here
or
whether
this
is
something
that
still
can
be
addressed
in
a
in
an
add-on
document,
either
way.
The
server
can
announce
its
support
for
these
group.
I
Observations
within
within
with
the
target
attribute
that
we
now
describe
other
than
that,
we've
updated
all
the
examples
to
work
correctly
with
the
text
that
we
have
next
slide
please
and
also
cover
how
this
could
still
be
improved
by
using
a
deterministic
request,
as
a
phantom
request
thing
is
thinking
back
to
the
to
the
examples
when
you
compare
them.
It's
like
such
a
such
an
exchange
for
the
unprotected
case
and
such
an
exchange
for
the
protected
case.
I
This
really
doesn't
go
well
with
the
story
that
we'd
like
us
to
have
all
score
as
something
that
you
can
just
tag
on
to
co-op
and
then
with
a
minimal
overhead.
That's
cryptographically
feasible.
Do
all
your
exchanges,
but
do
them
in
in
a
protected
way
by
using
deterministic
requests.
I
We
can
get
this
whole
litany
of
exchanges
down
to
the
complex
form
that
we
have
in
the
unprotected
case
and
just
not
to
forget
the
point
another
update
we
did
was
we
now
describe
better
how
a
group
meant
how
a
device
can
act
as
its
own
group
manager
for
those
very
simple
cases
where
there
is
no
pre-existing
infrastructure
around
next
slide.
Please
so,
there's
still
a
bit
work
to
do
in
giving
concrete
examples
for
these
deterministic
cases
and
in
exploring
a
bit
further.
I
How
that
would
work
in
in
a
reverse
proxy
case,
which
might
to
some
extent
also
relate
to
the
to
the
reverse
proxying
work
ongoing
in
the
with
the
prop
with
the
general
co-op
multicast
proxying
document.
I
But
as
with
the
other
document,
we
are
at
a
point
where
we
can.
We
can
still
improve
things,
but
we
would
be
improving
those
parts.
Can
we
start
improving
on
details
where
I
think
this
can
profit?
This
could
profit
a
lot
from
more
interaction
with
the
working
group
and
for
people
reviews,
possibly
in
the
in
the
course
of
a
working
group.
Adoption
yeah
next
slide,
please
so
this
this
summarizes
what
changed
here
and
also
how
we
could
how
we
would
like
to
have
more
input
from
you.
Thank
you.
F
Go
yeah
just
the
question
on
the
appendices,
so
there
seem
to
be
quite
quite
some
appendices
now.
Are
these
then
intended
to
be
just
examples
or
clarifications,
or
also
something
normative.
I
The
the
part
about
the
the
deterministic
requests
is
really
just
illustrating
how
those
things
interact,
so
that
there
is
no
need
for
normative,
inter
for
any
normative
additions,
but
more
like
more
explanation
and
implementation
guidance,
especially
with
deterministic
requests.
It
helps
a
lot
to
if
you,
if
you're
in
the
right
mindset,
then
you
understand
why
this
all
works.
If
you,
if
you're
viewing
it
from
the
wrong
angle,
then
it
sounds
awfully
complicated,
and
this
is
more
to
more
to
get
you
on
the
right
track.
H
So
what
are
the
main
things
you
think
are
missing
here,
except
from
I
mean
reviewing
and
and
testing
this
scenario?
What
what
is
that
is?
This
are
all
the
components
in
place
now.
Do
you
think.
I
Like
many
group
communication
documents,
this
is
all
assuming
that
the
groups
are
set
up
and
that
we
are
starting
in
this
from
a
situation
where
everyone
knows
which
group
to
be
in
etc,
etc.
So,
possibly
there
could
be
enhancements
there.
Frankly,
I
don't
know
all
the
documents
that
are
in
progress
around
that
well
enough
to
see
whether
there
are
maybe
things
already
there
that
we
could
just
reference.
H
Okay,
so
I
mean
so
looking
at
this
from
this
particular
piece
of
handling
handling
the
the
multicast
notifications,
then
that
this
is
this
is
fairly
complete
in
your
view,
except
for
for
details
and
and
reviewing
and
testing
okay.
Thank
you.
B
Yeah,
so
we,
this
is
a
document
that
is,
in
version
08,
sorry
for
already
putting
up
the
next
set
of
slides,
and
there
is.
B
Yes,
sorry,
okay,
I'm
very
confused
here
yeah,
so
the
the
multicast
notifications
has
been
discussed
for
a
while
and
it's
it's
a
version
of
five
and
what
we
have
to
decide
as
a
working
group
is.
Is
that
something
that
we
want
to
work
on
and
is?
Is
the
the
draft
actually
doing
the
the
right
going
into
the
right
direction?
Not
is
everything
already
exactly
like
it
needs
to
be
so
I'm
going
to
start
a
poll
on.
B
B
B
Increasing
okay,
so
that
looks
like
a
pretty
good
in-room
consensus
and,
of
course
the
the
question
is
who's
going
to
provide
reviews
of
this
document.
Can
you
just
use
the
the
shower
fan
q
thing
to
indicate
if
you
are
interested
in
providing
reviews,
esco.
B
B
B
B
Yeah,
okay,
but
that's
not
a
prerequisite
to
to
adopting
the
document,
so
we
do
have
energy
implementing
this.
But
again
it
would
be
nice
to
have
implementers
outside
the
the
author
group,
but
then
one
one
problem
we
often
have
is
that
people
to
who
implement
something
are
being
sucked
in
as
authors,
and
so
we
we
never
get
somebody
who
is
not
an
author
as
an
implementer
okay.
So
we
need
to
validate
this
consensus
on
the
mailing
list.
But
this
looks
like
a
pretty
strong
result
for
in-room
consensus
for
adoption.
F
So
well
the
examples
I
think,
because
that
takes
some
quite
some
time
to
go
through
okay,
now
about
the
proxy
operations
for
gore
group
communication
in
the
next
slide,
please
so
as
an
overview.
Well,
we
have,
of
course,
group
communication
and
co-op,
and
this
document
contributes
basically
what
a
proxy
could
mean
in
doing
group
communication
facilitating
group
communication
and
its
aim
is
to
also
address
the
issues
that
were
found
well
already,
a
couple
of
years
back
and
now
also
written
up
again
in
the
group
combis
document.
F
F
So
we
can
take
a
look
at
the
picture
to
see
how
it
works,
so
the
client
sends
a
new
cast
request
to
the
proxy
and
basically
should
indicate
there
in
an
option
that
it's
interested
in
handling
multiple
responses.
Coming
back
from
a
group
request.
Also,
it
should
indicate
how
long
this
proxy
should
collect
and
forward
responses.
F
So
we
assume
here
a
proxy
might
be
a
generic
one
that
doesn't
know
how
long
the
client
wishes
to
collect
responses.
So
it
can
basically
signal
that
using
multicast
signal
link,
the
proxy
will
remove
this
option
and
then
send
out
a
normal
group
communication
multicast
request
to
the
servers
and
when
the
responses
come
back
in
the
proxy
can
basically
see
from
what
server
the
responses
are
coming
and
it
can
add
this
information
in
a
new
option.
So
this
is
the
response
forwarding
option.
F
F
So
the
updates
that
we
did
yeah
so
we
have
now
a
new
yeah.
I
think
a
new
format
format
change
for
response,
forwarding
option
so
yeah.
We
basically
have
this
alignment
in
the
format
that
christian
also
showed
before
sort
of
a
specific
transport
information
encoding
where
we
use
the
value
one,
for
example,
to
denote
udp
stands
for
protocol
and
also
the
iep
address
where
the
server
was
located
and
optionally
also
port,
if
needed,
so
that
yeah
information
is
then
communicated
back
to
the
client.
F
So
also
there
is
this
registry
that
is
being
used,
so
I
already
explained
the
value
1
being
udp.
There
can
also
be
other
values
there,
so
that
are
encoded
here
in
the
table.
So
that's
what
we
want
to
add
to
this
transport
information
registry,
so
you
can
have
things
like
udp
dtls,
secured
co-op,
co-op
over
tcp
co-op
over
tls
web
sockets
and
then
also
web
sockets
with
tls.
F
Yeah
this
can
normally
you
could
say,
the
value
is
always
one
there,
because
the
yeah
the
server
responds
back
in
udp
unicast.
So
that
would
be
the
transfer
protocol
one,
but
there
are
some
specific
cases,
for
example,
with
re
reverse
proxies,
in
which
other
transport
protocols
could
be
defined.
Also
for
the
responses.
F
Yeah
one
new
thing
is
that
now
also
reverse
proxies
are
considered
before
we
had
explicitly
only
the
forward
proxy
scope,
but
since
many
things
apply
also
to
reverse
properties,
we
can
take
that
in.
I
think
yeah
there's
one
item
here
that
I
added
a
note
that
could
still
be
on
the
discussion.
So
the
initial
idea
we
have
is
that
the
client
basically
must
be
aware
of
that.
The
server
it's
contacting,
which
is
the
proxy
in
fact,
that
it
is
reverse
proxy,
and
it
also
must
use
the
multicast
signaling
option
to
signal
that
yeah.
F
F
Furthermore,
for
the
rest
for
the
reverse
proxy,
the
client
x
acts
similar
to
the
case
of
the
forward
proxy.
It's
only
that
the
encoding
of
the
request
is
a
little
bit
different.
F
F
Okay,
that's
new!
Go
to
the
next
one
see
we
have
some
more
updates.
Oh,
this
is
the
example,
so
I
would
like
to
just
go
over
that
because
I
think
it
takes
quite
some
time,
but
you
can
read
it
in
a
slight
material.
It
shows
basically
what
is
added
there
and
also
what
the
values
are.
In
this
example
case,
there's
a
forward
proxy
and
a
reverse
proxy
example.
F
So
now
for
the
security.
Of
course,
we
again
depend
on
oscore
group
communication
security
yeah,
so
we
can
have
score
between
client
and
proxy
co-existing.
As
I
said
in
the
beginning,
with
group
cost
oscar
end-to-end
between
client
and
servers,
and
then
there
are
some
well
intricate
things
about
the
options
class:
u
and
class
e,
so
the
proxy
will
have
to
treat
some
class.
U
options
as
if
it
was
class
e
to
make
that
all
work,
of
course
yeah
there.
The
point
is
what
about
future
options
that
that
will
come
in
co-op.
F
So
do
we
already
know
how
the
proxy
should
treat
those?
So
for
that
we
have
a
more
general
rule
added
still
a
question:
if
this
this
rule
is
yeah,
accurate
or
simple
enough
to
understand.
F
Yeah,
I
think
it's
also
written
there
in
text.
So
what
is
the
general
rule
for
that?
Not
your
marker
that
you
want
to
discuss
that
now
or
take
it
at
the
end.
Maybe.
A
F
Yeah
this
is
about
the
nested
oscora,
so
the
idea
is
to
have
end
to
end
or
score
to
the
servers
and
also
was
scored
between
client
and
proxy
independent
from
that
so
before
it
was
actually
forbidden
to
do
that.
So
because
there
was
no
no
use
case
and
it
seemed
complex,
so
yeah,
that's
why
it's
not
supported
at
the
moment
in
oscorp,
but
now
we
have
a
use
case.
Basically,
so
at
least
we
see
that
can
work,
work
well
in
principle,.
F
Yeah
then,
the
question
is,
of
course,
what
what
to
do
with
this
as
a
next
step.
So
now
we
have
it
in
an
appendix
and
it
takes
quite
some
explaining,
I
think,
to
to
to
get
it
right,
how
how
everything
works
with
nested
or
score.
So
I
think
the
question
is:
should
it
be
maybe
going
to
a
separate
document
that
explains
this
like
an
update
to
the
rc.
H
The
reason
why
this
was
not
defined
was
we
didn't,
have
a
good
use
case
and
and
that
all
these
considerations
around
up
the
class
human
class
e
options,
whether
how
that
changes
when,
when
you,
when
you
designate
certain
information
for
the
proxy,
I
had
one
question,
though
about
what
is
so
so
I
mean
there
is
also
always
the
option
that
you
can
have
a
separate
communication
with
the
proxy
sort
of
one
or
score
communication
with
the
proxy
one,
one
with
the
with
the
other
endpoint.
So
what?
H
H
A
The
idea
was
that
you
want
to
reach
the
the
outer
servers
or
server
in
the
first
place
through
the
proxy
for
different
reasons,
and
you
want
to
protect
and
to
end,
but
still
the
proxy
has
to
identify
the
client
in
order
to
proceed
with
the
forwarding
in
the
first
place.
H
Okay,
I
I
think
this
should
be
defined
separately
rather
than
built
into
this.
H
This
document
and
and
the
analysis
of
the
of
the
the
different
values
of
the
options
should
should
then
go
into
that
document.
I
think
that
that
makes
sense
there.
Also.
The
question
is:
is
this
something
we
should
define?
H
H
We
need
to
think
about
message:
expansion,
if
you
add,
if
each
proxy
or
each
for
each
proxy,
you
add
a
tag,
for
example,
and
the
message
grows.
C
I
I
think
this
collision
issue
will
turn
out
to
be
much
less
of
an
issue
than
it
seems
because
the
messages
in
which
the
the
messages
that
are
sent
all
have
their
routing
information
to
wind
up
at
the
right
device
and
information
that
that
targets
different
device
will
only
be
forwarded
from
there
and
not
arrive
there
we'll
see
when
implementing.
But
I'm
pretty
confident.
This
is
not
really
an
issue.
F
So,
in
summary,
we
have
yeah
defined
proxy
operations
for
communication
with
an
explicit
signaling
protocol
using
these
two
new
co-op
options
and
yeah
as
a
next
step.
F
F
So
then
the
client
can
talk
to
a
co-op
group
in
that
way,
so
that
can
actually
build
on
the
previous
work
of
the
http
to
co-op
mapping
proxy,
that's
already
in
rfc,
and
there's
also
a
couple
of
other
issues
listed
on
the
gitlab.
So
we
also
need
to
continue
with
that.
F
A
Okay,
next
in
the
list,
is
christian
again
with
casual
law
score
just
to
set
my
pace.
How
are
we
on
time?
Because.
I
Okay,
then
I'll
try
try
again
to
make
it
sure
topic
of
the
topic
of
this
is
kashuk
is
deterministic
requests
as
a
means
to
obtain
cash
and
loss
core
next
slide.
Please
stop
what
thing
is
so
why
do
we
want?
Caching,
basically,
for
the
same
reasons
we
wanted
in
general
in
particular,
here
firmware
updates
are
something
where
we
can
reduce
the
amount
of
traffic.
We
can
also
hide
how
many
devices
are
behind
the
proxy
if
they
just
produce
cache
hits
and
we've
in
research
work
shown.
I
That
kind
of
this
greatly
increases
the
reliability
and
latency,
as
is
to
be
expected,
and
last
but
not
least,
this
greatly
enhances
multicast
notification
next
slide,
please.
The
reason
this
is
not
trivial
is
for
one.
I
Oscar
requests
are
designed
not
to
be
cachable
because
generally
they
can't
be,
they
can
be
useful
to
to
another
client
and
even
if
we
could
magically
produce
a
cash
hit,
the
client
would
still
need
to
know
some
data
of
the
original
request,
like
the
kid,
the
partial
of
e,
and
even
if
it
knew
that
it
couldn't
verify
that
the
original
client
really
sent
that
request
and
it
was,
and
it's
not
handing
you
another
request,
just
hand
so
that
you
interpret
the
server
as
a
good
response
to
that.
I
So
that's
the
the
rough
setup
set
the
rough
problem
area
where
this
is
coming
from
next
slide.
Please
the
mechanism
that's
proposed
and
I'm
including
parts
of
the
upcoming
o2,
because
those
things
just
became
apparent
in
the
in
the
plug
test,
and
I
think
now
this
is
the
best
way
to
go.
I
But,
lastly,
is
unchanged:
is
there
is
a
deterministic
client?
That's
a
role
inside
the
group.
We
define
that's
not
pertaining
to
a
particular
host,
but
every
group
member
can
take
that
role
and
generate
requests
from
there
to
make
sure
that
these
requests
are
not
do
not
collide
on
anything
accidentally
and
thus
commit
nones
reviews
and
thus
make
all
the
crypto
stuff
go
boom.
We
introduce
the
request
hash,
which
is,
which
is
the
hash
of
the
send
the
sender
key,
the
external
aad
and
the
plain
text.
I
This
hash
is
then
fed
into
a
key
derivation
mechanism
that
is
very
similar
to
the
one
that
we
use
for
pairwise
and
generally.
The
mechanism
is
very
light
very
much
like
a
pairwise
request
sent
from
the
deterministic
client
to
the
to
the
respective
server.
I
How
this
is
done
in
particular,
is
still
open
to
discussion,
because
you
haven't
already
gave
very
good
feedback
on
this,
and
this
just
needs
to
be
evaluated
and
made
into
complete
concrete
steps.
The
server
then
recognizes
the
sender
key
id
obtains
the
key
material
and
latest
there
notices.
Oh,
that's,
not
a
regular
client,
that's
the
deterministic
client!
I
It
can
use
that
hash
that
is
sent
along
with
that
message
to
reconstruct
the
key
material,
verify
that
it's
it's
a
correct
that
the
authenticated
decrypt
encryption
works
out
and
verify
that
this
hash
really
matches
the
sender
key
aad
and
plain
text
that
it
that
it
finds.
So
we
have
additional
protection
against
all
those
things
that
we'll
hear
about
in
10
minutes
next
slide,
please
that
leaves
open
the
question
of
how
does
the
client,
when
receiving
the
response,
verifies
that
the
response
is
good,
because
so
we
can't,
we
can't
have
pairwise
responses.
I
We
have
to
have
the
response
from
the
signed
by
the
server
so
that
every
client
that
receives
the
cash
request,
cash
response
can
be
sure
that
it
is
really
from
the
server
and
not
just
from
someone
else
who
is.
Member
of
the
group,
for
that
the
current
way
to
go
is
to
have
a
class.
I
option
that
includes
a
request
hash.
This
does
not
necessarily
need
to
be
sent
on
the
wire.
In
fact,
it's
recommended
not
to
send
this
because
it's
redundant,
but
it's
placed
in
the
co-op
message
before
it's
get.
I
It
gets
handed
to
us
core,
and
thus
we
get
this
strong
message.
The
binding
between
the
request
and
the
response
and
the
client
that
produced
the
request
can
be
sure
that
the
response
it
gets
is
for
that
response
and
by
verifying
the
signature
that
is
coming
from
the
server
next
slide.
Please
there
are
a
few
limitations
on
this.
Of
course
thing
is.
We
are
trading
this
for
that,
so
no
new
features
without
giving
up
something.
This
only
works
for
safe
requests.
I
Kind
of
I
mean
it's.
It
needs
to
be
casual,
so
it
can't
just
be
you
know,
process
blah
and
then
the
result
is
different.
Every
time
it
only
works
for
things
that
don't
have
additional
access
control
based
on
social
authentication,
because
we
lose
source
authentication,
deliberately
we're
limiting
the
set
of
algorithms
a
bit
we
lose.
The
chronological
seek
the
the
basically
the
freshness
guarantees
that,
usually
you
know
score
request
gives
you,
because
we
want
to
get
responses
that
were
created
before
the
particular
client
even
created
the
request.
I
We
lose
on
request
confidentiality,
because
we
want
a
proxy
to
be
able
to
collate
different
requests
for
the
same
for
the
very
same
answer
into
the
same
bucket
and
we
do
lose
replay
protection
because
that
which
is
which
is
which
is
okay,
because
we're
only
talking
about
safe
requests.
I
Next
slide,
please.
So.
During
the
hackathon
last
week,
marco
and
I
interoperated
to
the
point
where
we
could
decrypt
each
other's
deterministic
requests
and
if
we
do
a
few
more
steps,
I'm
very
confident
that
we
can
even
pass
the
response
for
that.
We
have
comments
already
from
yarn
that
we
are
still
reviewing,
but
once
that
we
are
still
incorporating
into
the
document,
but
once
they're
done,
it
would
be
really
good
to
get
get
a
get.
F
Yeah
just
question
so
for
the
details:
deterministic
request.
Basically,
you
cannot
really
determine
the
order
right
in
which
request
for
sends
or
yes,
you
cannot
prove
this.
One
was
sent
later
than
the
other
one.
I
F
I
So
I'm
not
sure
that's
the
the
ordering
of
the
server
responses
is
still
good,
and
thus
you
can
still
use
it
for
observations
and
see
what
the
latest
is.
But
you
cannot
know
that
the
response
you're
getting
on
that
observation
is
really
later
than
the
request
that
you
just
said.
G
G
A
Okay,
thank
you
very
much.
Next
in
the
list
is
ricard
presenting
a
combination
of
adult
and
oscar.
E
Yes,
so
just
to
recap,
what
this
work
is
about:
it's
about
an
optimization
for
combining
ad
hoc
over
co-op
with
oscore,
and
this
means
that
you
want
to
combine
the
edward
message
3
and
the
first
subsequent
oscar
request
in
a
single
co-op
request
transporting
both
and
the
basically
the
point
of
doing
this,
that
it
reduces
number
of
round-trips
round-trips
required
to
set
up
telescope
context
and
also
to
complete
the
first
score
transaction
with
that
context.
E
And
the
point
is
that,
after
a
client
has
received
the
end
of
message,
two,
it's
already
in
a
position
to
derive
the
actual
score
context.
So
that
point
the
client
can
send
an
oscar
request,
and
we
want
to
combine
that
with
the
ad
doc
message
3
from
the
client
and
the
exact
contribution
that
we
propose
is,
first
of
all
how
to
signal
that
what
you're
getting
here
is
a
combined
request,
a
combined
message,
also
the
format
and
the
processing
of
the
edoc
cluster
request,
and
we
also
show
an
example
of
the
data
here
there.
E
E
Right
so
basically,
this
is
the
original
way.
If
you
would
do
enough
first
end
of
message:
one
end
of
messages,
two
doc
message:
three
and
then
you
derive
those
core
security
context
and
then
you
do
the
actual
score
request
and
response
right.
So
that's
that's
the
original
way.
Without
this
optimization,
we
propose
next
slide.
Please.
E
And
then
you
can
see
here
the
the
optimized
way.
So
basically
the
client
sends
setup
message
one
and
gets
adopt
message
two,
but
at
that
point
it
can
already
derive
those
core
security
context
on
its
side
and
at
the
same
time
it
can
improve.
E
It
can
produce
add-on
message,
three
which
it
does
so
then
it
would
send
one
single
request
here:
combining
add-on
message
three
and
that
oscar
request
and
then,
when
the
server
receives
that
it
can,
you
know,
take
care
of
message
three
and
derive
the
score
security
context
and
then
actually,
let's
say
decrypt
the
old
score
request
and
then
provide
an
oscar
response.
E
So
basically,
the
updates
now
to
this
latest
version
is
that
we
decided
on
a
single
method
for
how
to
signal
the
combined
message
and
that
method
is
basically
using
an
option.
A
new
option,
which
is
a
serial
length,
option
class?
U
for
score
and
its
intended
use
is
only
for
this
end
of
class
oscar
request.
So
when
you
get
such
a
request,
you
can
you
can
understand
that?
Okay,
this
is
a
com
combined
erdogan,
oscar
request
by
the
presence
of
that
option
and
the
reason
we
chose.
E
This
is
partly
because
of
preference
expressed
during
the
itf
109
meeting,
but
also
feedback
from
implementers,
because
we
have.
We
also
have
an
implementation
of
this
and
got
some
feedback
from
the
person
implementing
that,
and
we
also
propose
in
in
the
draft
as
suitable
option
number
13,
because
we
want
to
keep
the
size
of
the
option
to
be
one
byte
right
and
the
idea
is
that,
like
I
said,
the
is
a
zero
length
option
and
we
assume
in
in
this
combined
request
the
oscar
option
will
always
be
there.
E
So
we
know
that
you
know
if
we
pick
option
number
13,
the
delta
here.
For
that
option
will
be
less
than
12,
and
in
such
case
it
will
be
a
one
byte
option
and,
as
a
note
option,
number
21
would
be
another
suitable
value
that
could
be
taken
next
slide.
Please.
E
So
here
is
basically
an
example
of
this
combined
edu
class
oscar
request
and
where
you
can
see
in
the
top
box,
the
blue
box,
yes
kind
of
the
structure,
how
it
would
look,
so
you
have
the
normal
header
there
with
the
oscar
dummy
method.
You
have
on
the
oscar
option,
which
is
with
its
normal
content.
Then
you
have
this
zero
byte
add-on
option
and
following
that
you
get
the
actual
add-on
payload
and
then
also
the
oscor
ciphertext.
E
E
E
We
also
have
a
better,
step-by-step
description
of
the
message:
processing
where
you
can
see
detailed
steps
on
exactly
what
to
do
on
the
client
and
server
side,
so
as
a
kind
of
an
overview.
What
you
would
do
on
the
client
side
when
you
are
the
initiator
and
you
would
prepare
end
of
message
three
and
an
also
request,
combine
those
two
as
shown
earlier
and
send
that
to
the
server
side
and
on
the
server
side
you
receive
this
combined
request.
E
And
we
did
also
another
optimization
because
there
was
some
redundant
data,
as
things
were
in
the
previous
version,
and
the
redundancy
is
due
to
the
fact
that
the
the
sender
id
of
the
client
is
actually
present
in
two
places
in
this
combined
message.
As
things
were,
it's,
it
was
both
presence
in
present
in
the
cr
in
the
end
of
message,
three
and
in
the
kid
field
of
the
oscar
option,
because
those
are
basically
the
yeah,
the
sender
id
of
the
client
essentially
the
same
value
there.
E
So
we
thought
that
yeah
we
could
avoid
this
redundancy
in
a
clever
way.
So
the
basically
the
the
combined
record
we
request,
we
send
only
has
a
porsche
badok
message:
three,
that
does
not
include
the
cr,
but
only
the
ciphertext
three
as
a
silver
buy
stream,
and
this
optimization
can
actually
save
two
to
four
bytes
on
the
wire.
E
So
the
point
is
that
when
the
server
then
gets
this
request,
since
the
endometriosis
doesn't
include
cr,
it
needs
to
get
that
value
from
somewhere,
but
that
same
value
exists
in
the
oscar
option
in
the
kid
field.
So
it
can
simply
take
it
from
there
encode
it
as
a
bisting
identifier
and
revealed
the
full
edoc
message
tree
as
it
would
have
initially
been
created
on
the
client
side.
And
then
we
can
process
that
as
a
normal
end
of
message.
Three.
D
E
Right
and
and
for
the
updates,
we
improved
the
error
handling
on
our
points
on
the
server
side.
So
basically
we
detailed
exactly
what
should
happen
when
the
ad
doc
part
of
the
processing
fails,
and
this
included
suggestions
for
what
error
code
to
respond
with
and
the
fact
that
the
error
should
have
a
content
format
to
help,
because
you
have
to
disambiguate
in
a
sense
between
the
failure
on
an
oscar
processing
and
failure
on
an
end
of
processing.
So
we
added
some
some
considerations
on
that
can
be
made
easier.
E
E
So
here
to
be
consistent
with
those
correct
see,
you
should
use
cop
error
codes
like
for
sale,
zero,
five,
zero,
zero,
for
instance,
and
it
should
also
have
the
content
format.
Application
adapt
like
I
said
to
distinguish
it
from
all
score
errors
and
but
as
far
as
oscar
processing
is
exactly
as
in
the
oscar
rc
8613
next
slide.
Please.
E
And
yeah
next
steps
we
have
planned,
so
the
first
one
is
basically
to
keep
in
sync
with
the
main
add-on
document.
There
was
some
discussions
on
what
points
fit
better
in
the
end
doc
document
and
what
points
fit
better
in
this
edit,
combined
with
oscar
document,
for
instance,
some
things
specifically
about
co-op
anal
score
may
fit
better
in
in
this
draft
here,
rather
than
the
main
add-on
documents.
E
So
we
should
think
a
bit
with
with
the
work
on
the
main
add-on
document
and,
of
course
any
further
feedback
is
welcome
that
they
want
anyone
wants
to
provide
and,
as
the
last
point
yeah,
we
got
good
feedback.
I
think
from
the
from
the
last
meeting
and
also
good
feedback
from
implementers,
so
yeah
from
our
point
of
view,
it's
it's.
It
should
be
ready
for
working
group
adoption
at
this
point.
E
E
F
Yeah
just
quickly,
maybe
you
could
recap
so
what's
the
yeah
the
purpose
of
ad
talk
about,
because
maybe
not
everyone
knows
on
this,
call,
what
what
it's
doing
and
what
it's
for
and
the
combination.
E
Yeah
I
mean
the
purpose
of
that
look
is
basically
establishing
keys
for
oscore
in
in
a
secure
way,
and
the
point
of
this
optimization
is
just
to
reduce
the
round-trip
times
and
because
you,
you
have
an
opportunity
to
combine
the
last
basically
out
of
message
three
with
an
actual
first
oscar
request,
so
you
reduce
the
round-trip
times
rather
than
doing
ad
doc
and
then
all
score.
You
do
adult
and
you
combine
one
of
the
messages
with
those
core
and
you,
basically,
you
can
yeah.
E
F
E
B
Yeah,
I
think
we
we
need
to
do
a
formal
poll
here
again.
So,
first
of
all,
a
quick
sanity
check.
B
Yes,
I
think
we
can
do
this
in
the
car
working
group
because
it's
not
actually
changing
the
security
content
of
ad
hoc,
it's
just
transporting
the
attack
message
in
a
corrupt
message
and
that's
within
our
purview.
So
I
think
that
that's
an
important
observation,
and
so
I
asked
the
question:
should
we
adopt
what's
called.
B
B
F
I
can
maybe
explain
that
so
I
thought
yeah.
There
should
also
be
someone
not
not
raising
their
hands,
basically
yeah,
that's
because
I
wasn't
quite
sure.
F
B
Okay,
so
we
seem
to
have
a
strong
non-opposition
to
adopting
this
so
again,
this
is
in
room
consensus
and
we
need
to
take
this
to
the
list.
Thank
you.
So
we
are
seven
minutes
late.
B
A
E
Yeah
there
we
go
yes,
so
again,
record
again
so
I'll
be
presenting
here.
I
work
on
aad
key
usage
limits.
You
know
score
next
time.
Please.
E
So
basically,
this
work
started
or
discussions
about
this
started
in
earlier.
Meetings
like
ifta
itf109,
also
related
to
lake,
and
basically
the
overview
here
is
that
the
oscar
uses
aad
algorithms
to
provide
security
properties.
E
But
there
is
this
forgery
attacks
against
a
aea,
the
algorithms
that
have
been
described,
for
instance,
in
this
cfrg
draft
that
you
can
see
there,
and
the
point
is
that
adversaries
may
break
under
certain
circumstances
the
security
properties
of
the
aed
algorithm
and
there's
a
need
in
the
case
of
boscore,
to
consider
how
this
attack,
you
know,
impacts
the
score.
Basically,
how
does
this
fourier
attack
and
the
limits
a
factor
score
and
what
steps
should
you
take
during
message
processing
to
consider
these
findings
next
slide?
Please.
E
Certain
things,
so
you
need
to
count
this
q
value
and
the
q
value
is
the
number
of
messages
protected
with
a
specific
key,
and
you
also
need
to
count
the
v
value,
which
is
the
number
of
4g
attempts
that
have
been
made
against
a
specific
key,
which
means
the
amount
of
failed
decryptions
done
with
this
key
and
for
all
score.
There
will
be
essentially
two
relevant
counters
the
number
of
times.
You
use
your
sender
key
for
encryption
and
the
number
of
times
you
use
your
recipient
key
for
decryption
next
slide.
Please.
E
And
this
is
a
an
overview
of
how
you
could
calculate
these
limits
for
aes,
ecm
1664
128
algorithm,
and
some
of
these
depends
on
what
probability
values
you
chose
and
we
chose
the
same
as
in
the
dtls
1.3
document.
You
see
linked
there
and
by
applying
these
formulas
and
inputting
certain
probabilities,
it
will
give
you
a
cap
like
a
limit
on
the
q
and
b
values,
and
essentially,
what
it's
saying
is.
E
H
E
Next
slide:
listen,
yes,
we
can
proceed
so
this
is
just
overview.
What
you
should
introduce
in
those
core
security
context
like
I
said
you
need
basically
a
counter
for
q
and
a
counter
for
v
and
associated
limit
for
q
and
associated
limit
for
v,
and
if
these
limits
are
reached,
you
must
stop
using
that
security
context,
and
you
must
rekey
so
and
also
by
the
way,
this
updates
rfc
8613
del
score
rfc,
because
he
introduces
these
new
things
in
those
core
security
context.
E
Okay
and
also
the
draft
goes
over
existing
methods
for
a
keying
of
score,
and
presently
you
basically
have
four
methods,
which
is
the
appendix
p2
of
score.
You
have
the
oscar
profile
of
ace,
you
have
the
end
of
protocol
and
you
also
have
manual
reconfiguration
of
the
nodes,
which
is
not
practical
and
in
the
draft.
There
is
a
brief
description
of
each
of
these
methods
and
what
benefits
they
bring
next
slide.
Please
open
points.
E
One
point
is
if
we
now
produce
more
limits
for
further
algorithms,
which
our
intent
is,
what's
the
best
location
to
add
this,
is
it
in
this
document
or
is
it
in
even
some
higher
level
document,
because
this
could
be
general
per
algorithm
or
it
could
possibly
also
be
a
per
use
case
like
specifically,
for
you
know.
E
Second
point
is
what
about
these
probabilities?
We
assume
would
they
be
different
in
the
case
of
a
score,
as
you
know,
what
etls
1.3
will
define,
and
the
third
point
is:
is
there
a
value
in
adding
an
expiration
time
to
the
oscore
security
context,
meaning
an
actual
time
limit,
saying
that
when
this
many
seconds
has
elapsed,
this
security
context
is
no
longer
valid
to
use
the
similar
to
the
exercise
parameter
in
ace
and
by
the
way?
Grouposcore
also
does
something
similar
to
this.
E
E
Yeah-
and
this
is
our
plan
next
step,
so
basically
the
summaries
we're
introducing
counting
of
q
and
b
values
cross
score.
You
have
to
stop
breaking
if
the
limits
are
reached
and
we
provide
an
overview
of
current
your
keying
methods.
Next
steps
need
to
cover
more
aad
algorithms.
We
only
cover
one
which
is
the
default
and
mandatory
to
implement
now.
So
we
focused
on
that,
and
it
also
has
a
short
text,
so
we
felt
it
was
more
relevant.
E
C
Yeah-
let's
see
if
I
can
summarize
this
in
five
minutes,
so
this
is
more
review
of
the
process
that
was
used
for
dtls,
tls
and
quick
and
the
findings
based
on
that,
especially
how
it
relates
to
oscore
and
next
slide.
C
So
I
think
that
has
been
summarized
but
rickying
also
have
a
lot
of
other
benefits,
so
I
think
you
should
always
do
breaking
with
forward
secrecy
if
you
can
next
slide.
So
basically,
this
a80
work
in
tls
and
c4d
and
quick
has
four
parts
you
can
see.
It
starts
with
inequalities,
and
these
are
inequalities
they're,
not
tight.
It's
they
illustrate
the
worst
case.
C
C
C
First,
I
think
this
is
just
they
are.
Aes
is
basically
assumed
to
be
perfect,
a
perfect
fermentation
in
all
these
inequalities,
but
cha
cha
20
is
given
a
horrible
limit.
C
C
Then
analysis
of
the
step
this
the
process
yesterday
used
in
etls,
leads
to
a
lot
of
strange
things,
for
example,
that
you
should
re-key
the
ideal
mac
like
the
perfect
mac,
which
doesn't
make
sense.
It
also
gives
the
image
that
you
can
with
frequent
re-keying.
You
can
reach
arbitrary
high
security,
which
is
not
at
all
the
case.
In
fact,
some
of
these
inequalities
does
it
doesn't
benefit
to
re-key
at
all.
Next
slide.
C
And
you
can
basically
see
that
very
easy
from
there
from
the
inequality
of
its
benefits
to
reiki.
If
it's
linear,
then
there
is
no
benefit
to
re-key.
You
can
press
down
the
advantage
per
key,
but
that
doesn't
really
matter
it's
the
wrong
thing
to
measure.
If
you
have
quadratic
or
super
linear
inequalities
in
general,
then
there
is
a
benefit
to
reiki.
C
C
C
So
here
are
some
graphs
in
general
and
you
can
see
security
level,
the
security
level
you
need
to
re-key
before
these
graphs
drop
down
to
too
low
security
level,
but
in
general,
the
security
level
is
the
minimum
of
all
the
allowed
values
on
the
x
axis
and
the
different
colors
here
blue
is
the
dtls
values
and
purple.
Here
above,
is,
if
you
reduce
these
numbers
a
bit
so,
for
example,
to
q,
equals
2
to
the
power
of
20
and
l
equals
2
to
the
power
of
8.
and
notice
that
all
these
are
inequalities.
A
Yeah
we're
just
on
the
clock
in
case
considered
to
skip
to
the
conclusive
slide,
we'll
go
back
to
this
during
interim
meetings
for
sure.
C
A
Those
who
can
stay
couldn't
we
stay.
It's
mostly
me
takeo
that
can
close
the
session
in
a
few
minutes,
but
as
long
as
we
can
stay
sure.
C
Then
I
let's
go
back
two
slides.
C
C
This
is
maybe
now
the
two
more
interesting
slides
for
for
core,
so
this
is
ccm8
and
to
the
left,
you
see
the
security
level
using
the
dtls
values.
You
can
see
that
ccm8
deviates
a
bit
for
low
values
of
v.
That's
for
your
attempts
and
also
for
high
values,
but
in
the
middle
it
it
works
like
a
perfect
64
bit
tag.
It
couldn't
be
better.
C
C
C
Reeking
is
also
good
for
other
things.
Ccm8
is
perfect
as
long
as
you
can
accept.
64-Bit
tags
and
64-bit
tags
should
then
can
be
accepted,
basically,
especially
for
constrained
iot,
to
produce
a
signal
for
you.
You
basically
need
to
send
4.3
billion
messages
per
second
for
68
years,
and
this
is
very
infeasible
in
constrained
radio.
C
I
think,
should
consider
using
some
smaller
values
for
q
and
l.
Then
you
get
the
then
ccm8
starts
behaving
for
a
long
long
time
has
the
perfect
mac
and
then
last
down
on
this
slide.
Some
some
suggestions
either
to
do
a
little
bit
different
values
for
the
different
algorithms,
for
example,
2
to
the
power
of
20
for
gcm,
ca
and
asccm.
C
But
you
could
allow
v
equals
30
for
csm8
without
problem
at
all.
Even
a
bit
higher
or
should
oscar
do
something
simple
and
some
simply
say.
Q
and
v
is
2
to
the
power
of
20
for
all
algorithms
and
then
also,
I
think
the
message
sizes
should
be
lowered
a
bit
maybe
to
l
2
to
the
power
of
8,
which
is
4k,
which
would
be
instead
of
the
16
k
in.
H
Yeah,
we
probably
don't
have
time
to
to
discuss
details
here,
but
I
think
we
need
to
think
about
where
so
what
what
what
work
goes
where
and
and
where
we
would
put
this
type
of
if
this
would
analyze
some
separate
documents.
Do
you
have
any
idea,
john
on
where
this
work
would
be
published
and
how
it
would
be
published,
which
working
group
and
so
on.
C
I'm
not
sure
it
should
be
need
to
be
published
here
is
to
give
input
to
how
oscar
chooses
it
its
limits,
and
also,
I
think
one
conclusion
is
that
I
don't
think
the
dtls
process
should
be
published
by
cf
audience
recommendation.
I
think
it's
quite
flawed
and
the
actual
values
that
are
used
in
gtls
and
tls,
on
the
other
hand,
are
are
quite
good
and
improved
security,
except
for
ccm8,
where,
where
I
think
the
process
starts
to
have
limits.
A
But
the
actual
process
updating
is
not
really
something
for
the
documentary
card
presented
right,
something
for
somewhere
else.
I
guess
yeah.
C
A
No
okay,
then,
with
seven
minutes
over
time.
I
I
think
we
can
adjourn
the
meeting.
Thank
you
everyone
for
attending
today
and
the
discussion
we
have
a
concession
on
friday
at
12
utc
enjoy
the
rest
of
the
week.
Thank
you.
Everyone.