►
From YouTube: CORE WG Interim Meeting, 2021-02-18
Description
CORE WG Interim Meeting, 2021-02-18
A
This
is
the
last
core
entry
meeting
before
the
itf-110
main
meeting,
and
this
is
an
official
itf
meeting,
so
do
not
well
apply
if
you're
not
familiar
to
them,
find
some
time
to
become
familiar
with
them,
and
that
said,
the
main
topic
for
today's
agenda
is
some
ongoing
work
that
was
started
around
the
itf
online
meeting,
raised
as
an
element
of
interest
in
the
lake
working
group
about
limits
in
using
his
email
score
and
possibly
as
motivation
for
renewal
and
richard
has
prepared
some
slides
on
this
ongoing
work.
B
This
attack,
of
course,
also
affects
post-core
and,
like
martial,
like
marco
mentioned,
this
was
discussed
a
bit
during
the
itf
109
meeting
that
it
would
be
good
if
something
happens
related
to
cost
score
and
these
limits
and
it
could
happen
in
court
and
basically,
if
this
folder
attack
is
successful,
an
adversary
may
break
the
security
properties
of
the
aea.
B
The
algorithm
and
the
exact
details
and
more
information
on
this
can
be
seen
in
this
draft
would
see
for
the
aad
limits,
but
the
main
point
of
this
work
would
be
to
that:
there's
a
need
to
describe
the
relevant
limits
for
all
score
and
how
the
fourier
attack
and
the
limits
will
affect
those
core,
and
you
know
the
necessary
steps
to
take
during
message
processing
to
take
into
account
that
you
need
to
count
these
limits
and
have
kind
of
a
cap
on
them
and
also
what
should
you
do
if
the
limits
are
exceeded?
C
Record,
I
think
there
is
an
updated
version
of
the
draft.
It's
it's
adopted
and
there
is
a
zero
one
version.
B
C
B
There
may
be
and
I'll
check
the
latest
one
yeah,
probably
I've
shaved
it
at
some
point.
It's
just
that
like
when
I
cope
with
it.
I
put
the
old
version.
All.
C
B
But
they
will
point
to
the
point
yep
next
slide.
Please.
B
So,
basically,
the
limits
on
key
usage,
the
relevant
limits
and
things
you
need
to
count
as
defined
in
this
cprg
document,
is
the
q
value,
which
is
the
number
of
messages
protected
with
a
specific
key
meaning.
The
number
of
times
the
algorithm
has
been
invoked
to
encrypt
data
with
that
key,
and
you
have
to
also
keep
track
of
the
v
value,
which
is
the
number
of
folder
attempts
made
against
a
specific
key,
and
that
is
the
amount
of
failed
decryptions
done
with
the
algorithm
for
that
key.
B
So,
in
the
case
of
oscore,
you
use
the
sender
key
to
protect
outcome
messages
and
you
use
the
recipient
key
to
decline
and
verify
incoming
messages,
and
that
means
that
the
relevant
counters
for
all
score
will
mean
will
be
counting
the
number
of
times.
The
sender
key
has
been
used
for
encryption,
and
that
is
counting
the
q
value,
and
then
you
count
the
number
of
times
the
recipient
key
has
been
used
for
decryption
and-
and
you
know,
failing
to
decrypt,
let's
say,
and
that
would
be
the
v
value.
B
And
here's
an
example
based
on
on
the
limits
defined
in
that
c4d
document.
Again,
yes,
it
should
be
the
latest
version,
and
the
limits
depend
depends
of
course,
on
the
exact
algorithm
used.
So
in
the
case
of
oscorum,
it
can
use
a
number
of
aed
algorithms
and
the
default
one
is
this
aescm
1664
128,
and
in
that
case
they
define
these
two
limits
for
q
and
v,
and
that's
basically
saying
like
if
your
q
or
v
count
reaches
above
these
values.
B
You
may
not
use
these
keys
anymore,
because
then
you
may
compromise
the
security
properties
of
the
algorithm
and
the
way
to
calculate
these
depends
on
the
assumptions
you
make
on
the
probability
value
p
and
so
for
this
example.
I've
taken
the
p
values
as
defined
in
this
tls,
sorry
dks
1.3,
and
there
they
consider
yeah
one
probability
for
the
q
value
and
one
for
the
v
value.
B
And
if
you
plug
this
into
the
formula
together
with
message
length,
you
can
calculate
exact
limits
in
the
case
of
aesc
m16,
64
128.
So
what
you
basically
end
up
with
is
the
q
value
is
the
limit
for
q
is
2
to
the
power
of
23.
So
if
you
have
sent
and
degree
if
you
have
sent
an
encrypted
more
messages
than
that,
you
may
not
use
that
key
anymore
to
send
the
key,
and
so
that's
I
mean
that's
fairly
high
value.
B
It's
about
half,
I
suppose,
of
the
vertical
maximum
center
sequence
numbers
and
in
the
case
of
v
the
failed
decryptions.
Here
your
the
limit
you
reach
is
much
lower,
so
it's
more
likely
that
you
would
run
into
that.
It's
only
112
failed
decryptions
and
you
exhausted
that
key
and
you
need
to
re-key
yeah.
A
Thanks
like
this
just
for
note
on
the
values
of
pq
mpv,
when
this
was
discussed
in
november
at
itf
109,
I
remember
ben
keduk,
adding
on
jabber.
That
is
not
super
clear
in
details,
one
three:
either
why
exactly
those
values
ended
up
to
be
picked
up,
they're,
probably
safe
values
to
be
on
the
safe
side,
but
yeah
it's
a
bit
open
if
this
can
probably
be
relaxed
a
bit
and
indian
come
up
with
different
numbers.
B
Yeah,
that's
true
exactly
like
that's
the
assumptions
they
made
in
that
document
based
on,
I
guess
some
safe
margin,
but
definitely
more
considerations
can
be
put
into
what
are
the
relevant
probabilities
and
possibly,
if
you
know
it's
the
fact
that
it's
all
score,
you
know
if
that
can
can,
if
we
can
find
other
probabilities
that
are
different
and
maybe
reach
increase
these
limits
a
bit.
Of
course,
it
still
has
to
be
a
proven
that
it's
a
secure,
secure
probability,
secure
assumption,
so
there's
definitely
more
considerations
that
can
be
done
on
that
yeah.
C
Out
or
yeah
somehow
left
the
meeting,
and
I
think
there
is
a
plan
to
start
an
activity
on
this.
This
is
at
least
been
announced
something
to
do
in
in
lake
to
look
at
these
at
these
inequalities
because
they
are,
we
don't
really
know
whether
we
are
close
to
the
limit.
Presumably
not,
and
some
of
the
assumptions
are
really
arbitrary
in
this
already
in
this
model
for
tls.
So
so
there
might
might
be
other
assumptions
you
may
want
to
do.
B
C
B
Yeah
definitely
exactly
it's
relevant
for
both
yeah
okay.
Next,
like
this
and
then
there
are
some
open
points,
let's
say
one
of
which
is
that
yeah.
So
far,
only
the
limits
for
q
and
v
for
aesc
same
1664
128
have
been
calculated
as
part
of
this
work
based
on
those
assumed
probabilities
and
the
formulas
in
that
c4g
document.
B
B
Another
open
point
is
that
there
needs
to
be
a
smart
way
in
the
case
of
constrained
devices
for
efficiently
counting
qld,
because
the
problem
is
that
they
will
need
to
save
these
values
in
the
case
of
reboot
so
that
when
they
reboot
they,
they
still
have
those
values
available
if
they
wish
to
continue
using
the
the
same
security
context,
for
instance
with
appendix
d1
or
boscore.
B
B
B
D
In
the
case
of
storing
the
queue,
we
should
also
explore
whether
it
might
be
sufficient
if
both
parties
do
the
counting
whether
we
can
put
some
limit
on
qsaq
half
and
as
long
as
both
parties
only
count
their
sender
sequence
numbers
up
to
q
half
then
they
would
not
need
to
to
count
q
separately
because
there
can
be
no
mess.
I
mean
kind
of
adding
up.
B
B
Right,
that's
a
good
point,
that's
a
good
point,
and
we
also
had
some
other
odd
thoughts
on
more
efficient
ways
like
using
the
fact
that
you're
already
counting
and
saving
your
your
sequence
number
so
that
can
be.
That
can
also
be
so
there's
definitely
more
to
explore
on
the
you
know,
aspect
of
how
to
make
this
more
efficient
from
devices,
but
that
may
be
a
small
solution,
as
you
said,
to
consider
that
they
both
count
up
to
half
the
limit
yeah.
A
What
can
complicate
things
a
bit
on
focusing
just
on
qf
is
the
non-inclusion
of
the
partial,
even
most,
of
responses
right.
B
Yeah,
there's
also
that
consideration
that,
for
response
says,
you
do
encrypt
them
with
your
sender
key,
and
they
should
also
be
counted
as
part
of
queue.
So
it's
not
only
outgoing
messages
with
the
partiality.
You
also
have
to
count
a
lot
of
responses
where
yeah
they
do
not
have
a
partially
included.
D
That's
that's!
That's
exactly
my
point
here
as
long
if,
if,
if
the,
if
our
device
can
rely
on
the
other
party
to
only
produce
sequence
numbers
up
to
q
half,
then
we
send
at
most
a
few
half
responses
on
a
foreign
nonce
and
at
most
q,
half
responses
on
our
own
sequence
numbers,
and
thus
we
produce
only
up
to
q
messages
with
one
key.
B
A
D
A
B
Yeah
so
then,
if
there's
a
certain
few
value
for
a
certain
algorithm
that
can
be,
you
can
have
that
right
in
the
register
data
case
this
algorithm
and
it
has
this
associated
q
and
b
limits,
yeah
yeah,
but
you're.
Not
not.
If
the
probability
depends
on
the
exact
use
case,
because
then
you
can't,
you
can't
define
it
per
algorithm.
B
And
this
was
another
point
so
that
if
let's
say
you
consider
messages
that
are
replaced
now,
they
will
of
course
be
reacted,
because
simply
because
of
the
fact
that
they
are
replaced
while
if
they
had,
if
they
had
been,
if
that
a
decryption
attempt
had
been
made,
it
would
have
failed
and
it
would
have
shown
that
these
are
actually
forgery
attempts.
B
B
So
it's
actually
the
inverse
order
there
and
now
the
proposal
and-
and
the
intention
here
was
that
or
the
question
that
says
that
can
we
safely
not
increment
v,
if
the
message
is
a
replay,
so
basically,
if
the
replay
would
never
even
come
to
the
encryption
step
so
regardless,
if
it
would
have
failed
or
not,
we
don't
have
to
incrementally,
and
I
think
I
saw
christian-
do
a
thumbs
up.
B
Right
exactly,
then,
a
replay
would
not
contribute
to
the
counter
exactly.
It
would
just
be
reacted
as
a
replay
and
no
decryption
attempt
would
even
be
made
as
it
is
now.
Yes,
so
those
are
the
open
issues,
some
of
the
open
issues.
Let's
say
where
we
define
so
far
so
is:
does
anyone
see
any
other
say
you
know
open
issues
or
important
points
to
consider?
In
addition
to
this.
C
B
B
So
saying
that
yeah
there
will
be
some
deltas
with
the
message,
processing
and
things
you
have
to
take
into
account
now
for
accounting
and
also
what
actions
you
need
to
take
if
the
limits
are
reached
and
which
would
basically
be
that
you
have
to
rekey
any
full
score.
You
have
to
change
your
sender
and
recipient
keys
fundamentally
and
currently
there's
a
number
of
alternatives.
You
can
use
to
do
that
and
there
is
also
an
overview,
a
short
overview
of
the
current
alternatives
that
we
can
use
for
a
chemoscore
which
is
essentially,
you
have
endoc.
B
You
have
to
score
ace
profile
and
you
have
appendix
v2,
and
you
also
have
the
possibility
of
doing.
I
mean
manually
doing
everything
just
changing
the
the
context
keys
manually,
which
is
not
very
convenient,
let's
say,
and
then
next
steps
the
main
next
steps
or
what
points
that
need
more
work
is
yeah
again
adding
limits
for
further
aed
algorithms,
because
currently,
we've
only
considered
a
score
default
one
and
would
be
very
useful
to
have
a
yeah.
A
B
Try
to
add
more
or
ideally
to
try
to
add
for
every
aed
written
that
was
core
can
use,
and
the
other
point
is
like
we
discussed
a
bit
earlier
to
try
to
improve
the
solution
for
constrained
devices.
So
it's
not
a
burden
or
heavy
for
constrained
devices
to
use,
and
they
don't
have
to
do
excessive
this
usage
or
keep
a
lot
of
extra
stuff
in
memory
compared
to
say
the
vanilla,
current
oscar
implementations.
B
C
B
Because
that's
the
point
like
yeah
see
it
had
reached
the
decryption,
so
this
could
directly
be
a
four
day
attempt
and
if
it
had
been
decrypted
it
would
have
been.
You
know
the
the
counter
would
have
been
incremented.
It's
just
that
because
of
the
you
know,
replay
detection,
it
won't
reach
the
encryption
stage.
B
C
And
then
the
main
missing
part
is
actually
these
estimates
then
sort
of.
How
can
we.
C
C
C
A
A
B
C
It
sounds
a
little
bit
more
like
a
draft
to
me
that
you
have,
if
you
have
sort
of
you've,
updated
the
the
error
sort
of
what
you
think
is
the
relevant
errors
or
probabilities.
And
then
you
calculate
for
for
a
number
of
algorithms.
And
then
you
put
it
into
a
draft.
B
D
And
just
on
the
topic
of
dtls,
my
understanding
of
the
drafts
that
circulated
on
during
109
was
that
dtls
has
already
ditched
the
the
eight
byte
tag,
asccm
values.
So
possibly
they
already
made
updates
based
on
the
on
the
tls
numbers,
and
I
don't
use
them
anymore
at
all,
but
I'm
not
sure
that's
kind
of
what
I
remember.
C
Yes,
so
what's
up
in
the
draft
right
now,
at
least
from
tls
tls,
it's
it's
deprecated!
I
don't
remember
if
it's
for
dtls
as
well,
so
I
don't
know
I
we
have
to
look
it
up,
but
but
in
principle
the
what
the
estimates
here
is
not
necessarily
bound
bound
to
add
or
cross
course
more,
like
the
algorithms.
So.
B
D
That's
true:
this
is
the
the
current.
The
current
details
draft
still
allows
ccm8,
but
places
this
127
v
limit
to
to
the
number
of
fake
decryption
attempts.
127.
B
B
A
A
So
yeah
these
probabilities
here
are
mostly
as
background
information
at
this
point,
at
least
for
the
sake
of
core.
They
can
definitely
be
somewhere
else
more
generically
later
on.
D
True,
but
by
the
way,
just
just
kind
of
for
continuing
on
on
the
train
of
thought
and
under
text
details
in
the
current
draft
explicitly
says
that,
for
instance,
it
might
be
possible
to
set
a
different
target
for
the
advantage
and
attack
against
based
on
understanding
the
constraints.
So
this
is
about
what
we
are
about,
basically
about.
What
we
are
doing
here
understand
understanding
that
better
what
what
can
be
and
then
adjusting
the
numbers
right
right,
yeah
open.
There
is
still
two
yep
good.
A
Great,
so
this
was
the
the
only
main
discussion
topic
on
the
agenda.
Otherwise
I
I
could
see
echo
request
tag
proceeding
again
in
the
very
advanced
stages
now,
and
thanks
christian,
also
for
replying
to
john
and
madd
latest
revision.
On
your
review
of
new
block.
A
Well,
after
the
the
one
time
meeting
and
to
not
collide
like
we
are
doing
now
with
the
telechat
scheduling
of
the
isg,
which
is
on
on
thursdays
at
this
time,
we
think
to
move
it
back
to
move
the
core
interim
series
back
to
its
original
place,
which
used
to
be
wednesday
afternoon,
in
fact-
and
we
left
wednesday
afternoon
because
of
a
collision
of
cozy
that
so
far
hasn't
rescheduled
anything
yet
so
the
idea
is
to
move
back
to
every
other
wednesday
at
same
time
of
today,
which
has
always
been
the
same
time
for
a
long.
A
While
I
know
we
are
not
that
many
today,
any
big
objection
or
comment
on
that.
A
Then
I
think
we
can
go
for
that
slot,
but
we
think
of
resuming
second
half
of
april
after
easter,
so
essentially
about
two
months
from
now,
and
that
should
leave
space
for
six
interim
meetings
before
itf-111.
A
Okay,
so
I
think
we
covered
everything
we
had
in
mind
originally
for
the
agenda.
Anything
else
you
want
to
discuss
today.
Yes,
right.
E
A
In
the
particular
agenda,
110,
you
mean
yes,
as
you
suggested,
for
core.
We
can
have
all
the
security
related
topics
on
the
monday
session,
at
least
it
doesn't
collide
with
danish
yeah
yeah
yeah.
I
haven't
discussed
the
agenda
with
jaime
in
detail
yet,
but
I
I
did
some
simulation
already
and
all
should
fit
like
last
time.
I
think
oh.
A
Interesting,
I
realized
that
core
really
needed
that.
So
when
approaching
the
cut
of
weeks,
I
have
a
nice
spreadsheet.
As
far
as
I
have
a
spreadsheet,
where
I
start
listing
with
existing
documents
possible
ones
that
are
around
the
corner
and
the
likelihood
of
having
a
presentation
of
them.
E
Great
okay,
so
that
that
doesn't
help
the
the
people
who
actually
are
interested
both
in
in
core
and
in
security,
but
yeah,
don't
know
how
to
fix
this.
The
the
other
observation
is
that
we
have
yang,
ziba
and
and
sid
now
under
a
d
review,
but
we
are
not
quite
there
yet,
with
comai
and
and
I
sent
a
set
of
items,
we
probably
need
to
discuss
to
the
mailing
list
a
while
ago,
and
I'm
wondering
how
we
can
get
progress
on
this,
which
is
basically.
A
E
E
E
Well
for
comey,
I
actually
have
comments.
I
I
haven't
really
started
looking
at
yang
library
yet,
but
I
don't
expect
there
to
be
big
problems.
E
Me
then,
but
comey
had
some
so
a
few
things
that
actually
do
need
attention
and
yeah
the
with
the
id
deadline
coming
up
on
monday.
I'm
I'm
already
afraid
that
we
are
going
to
miss
it.
A
Right
I'll
ping,
evo
following
your
thread,
thank
you.
E
D
Speaking
of
the
upcoming
deadline,
assuming
that
we
are
now
in
other
other
people
taking
the
aob
up,
I'm
working
through
the
last
to
do
items
on
on
the
resource
or
resource
directory.
If
you
remember
correctly,
the
the
basically
the
isg
points
have
been
cleared
out,
but
we
still
promised
to
do
one
more
update
with
two
open
items
about
the
anchor
stuff
and
about
the
the
freshness
topic,
and
I
managed
to
do
those
in
time.
D
But
it
would
help
if
someone
familiar
with
the
topic
basically
before
it
gets
all
up
to
the
iesg.
Again,
I
could
have
a
look
at
what
I've
been
doing
before
I
hit
the
button
on
monday
evening.
So
I'll
I'll
write
up
down,
write
out
a
mail
on
that
to
the
list,
but
maybe
if
some,
if
someone
can
can
arrange
an
hour
an
hour
or
so
to
to
read,
probably
even
more
and
a
half
to
read
what
to
read
the
delta
that
I'll
be
pushing
with
that.
That
would
help
me
a
lot.
D
Muted
sorry,
I
mixed
that
up
with
the
with
the
the
pending
yang
topics,
if
that
was
a
comment
to
that,
no
no!
It
was
about
the
early,
so
the
there
there
are,
there
are
escos.
D
There
are
a
few
of
esco's
comments
unanswered,
but
that's
more
like
small
changes
to
the
examples,
the
the
the
real,
the
real,
the
things
that,
where
I'll
kind
of
change
more
than
a
few
lines
or
at
at
complete
subsections,
is
the
topic
of
freshness
and
the
topic
of
oh
yeah,
you're
right,
that's
the
topic
that
you,
the
the
anchor
thing
is
to
be
here
is
but
I'm
more
concerned
about
the
freshness
part
and
that's
something
that
yeah
and
possibly
you
could
have
a
look
at
from
the
from
the
echo
point
of
view,
for
example,.