►
From YouTube: LAKE WG Interim Meeting, 2021-06-01
Description
LAKE WG Interim Meeting, 2021-06-01
A
Okay,
so
now
we're
being
recorded-
and
I
guess
we
can-
we
can
kick
off.
Rickard-
is
been
kind
enough
to
help
with
notes
the
in
the
webex
chat.
I've
posted
the
etherpad
link,
so
please
go
there
and
put
your
name
into
the
roster
as
being
present,
and
I
guess
I'll
be
screen.
Sharing
and
malicious
will
be
doing
all
the
intelligence
during
today,
and
with
that,
I
guess
over
to
you,
unless
you
just
say
say
when
you
want
me
to
hit
the
next
button.
B
Yeah,
okay
sure
so
I
was
just
filling
in
the
names
for
the
in
the
in
the
notes,
but
if
people
could
do
it
themselves,
that
would
be
great,
so
welcome
everyone
to
the
lake
interim,
like
working
group
interim
meeting.
So
as
you
know,
this
is
the
last
meeting
that
we
will
have
before
the
itf
111,
and
today
we
scheduled
two
hours,
I'm
not
sure
if
we
will
need
all
that
time.
B
B
So
this
is
an
itf
meeting,
so
the
note
well
applies
if
you're
not
familiar,
please
go
and
read
these
bcps
that
are
listed
down
here
and
most
and
notably,
if
you
are
aware
of
any
intellectual
property
rights
that
are
being
discussed,
please
disclose
them
or
do
not
participate
in
the
discussion
next
slide.
Please.
B
B
C
Great,
this
is
a
short
report
of
the
latest
rounds
of
testing.
We
had
for
edoc
next
slide.
Please
yeah.
We
had
some
more
bilateral
tests
already
following
the
previous
intern
meeting
in
april,
but
then
we
also
had
the
main
actual
interrupt
event.
A
few
weeks
ago,
around
mid-may
and
overall,
we
consider
three
implementations.
C
So
it's
my
implementation
again
for
california,
christians
for
io,
co-op
building
on
team
of
this
implementation
and
lydia
again
with
her
implementation
for
contikien
g
and
overall,
putting
together
implementers
and
observers.
It's
roughly
10
people
that
participated
in
the
different
events.
As
usual.
You
can
follow
that
link
and
find
a
lot
of
resources
related
to
testing,
so
a
spreadsheet
where
we
cumulatively
collect
what
implementation
support
and
the
tests
overall
happened
with
what
configurations
and
then
for
each
pair
of
implementers.
C
I
don't
recall
who
exactly
stay
fun
next
slide,
please
yeah,
the
first
bunch
of
tests
and
the
largest
one
was
between
marco
and
chris
me
and
christian.
We
consider
especially
sevens
with
zero,
with
authentication
methods,
zero
and
three
both
directions.
Things
worked
then
services,
two,
all
authentication
methods,
both
directions,
everything
worked
and
services,
three
again,
all
authentication
method.
Due
to
lack
of
time.
We
went
for
one
direction
only
and
it
didn't
seem
any
way
that
the
other
direction
could
have
anything
useful
and
for
all
these
tests.
C
We
we
focused
on
the
credential
type
kid
next
slide,
please
and
yeah.
Finally,
lydia
had
also
the
opportunity
to
to
to
test
other
than
me,
also
with
christian
for
the
first
time
and
that
test
focused
on
what
lydia
exactly
support
with
her
accounting
implementation.
So
cyber
c2
and
exactly
with
authentication
method,
three
one
direction
was
tested
and
worked.
The
other
one
was
working
progress,
mostly
due
to
connectivity
issues
and
will
be
most
likely
tested
the
next
time
and
here
again
a
credential
type.
C
Kid
next
slide,
please
yeah
before
scheduling
any
other
actual
interrupt
event.
We
agreed
to
wait
for
version
8
of
the
draft,
with
number
of
changes
in
the
queue
and
hopefully
also
updated,
test
vectors
to
consider,
and
once
we
have
two
of
three
implementations
aligned
with
the
upcoming
version,
eight
we'll
we're
receiving
the
tests
and
we'll
likely
most
likely
set
up
also
an
actual
interop
event,
and
that
should
be
it
from
my
side.
Thanks.
B
Yep
thanks
mark
I
mean
this
is
great,
so
I
think
this
is
this
really
makes
sense.
I
think
I
was
just
going
through
the
issues
in
in
github
and
all
the
changes
that
happened
with
from
zero
six
to
zero
seven
and
the
test
factors
are
affected,
and
there
are
also
from
what
I
can
see
many
many
changes
that
are
coming
in
also
that
will
affect
the
implementations.
B
C
B
B
D
D
I
think
we
are
reaching
some
some
degree
of
maturity
in
this
work
we
face
today.
We
want
to
discuss
a
number
of
issues
that
relates
to
some
some
features
we
added
nine
months
ago,
which
we
want
to
take
out.
It's
a
little
bit
like
we've,
somehow
reached
some
degree
of
sort
of
reflections
on
on
the
on
all
the
things
that
we
are
doing.
D
So
I
think
we
are
we're
really
really
converging
now,
but
it's,
of
course,
would
be
nice
if
we
could
progress
always
in
the
same
direction,
but
so
here
we
are-
and
I
think
we
have
had
a
really
fortunate-
that
we
have
this,
this
good
discussion
with
implementers.
We
have
one
had
one
design
team
meeting
just
the
day
before
the
latest
interop
and
that
that
type
of
feedback
is
really
a
great
input
to
this
work.
So
but
let's
let's
get
started
next
time,
please.
D
So
these
were
the
changes
between
the
previous
version.
This
version
very
briefly
condensed
here.
The
reason
for
this
release
was
that,
essentially,
that
we
had
reached
so
many
changes
that
we
thought
this
is
time
to
make
a
drop
without
completing
the
all
the
changes
that
are
in
the
pipe.
So
there
are
some
that
we
should
discuss
today
as
well,
but
anyway,
this
this,
it
made
sense
to
me,
make
this
intermediate
version,
but
we
didn't
update
the
test
vectors.
D
D
Then
there
was
a
change
in
the
cipher
suite
definition,
so
there
were.
There
are
a
number
of
parameters
in
the
cipher
suite
and
the
particular
ethox
signature
algorithm
curve
should
probably
not
be
in
the
cipher
suite,
because
it's
determined
by
by
the
public
key
parameter,
so
so
that
was
removed
and
it's
essentially
duplicated
in
most
of
the
cipher
suites.
So
it
makes
sense
from
that
point
of
view
as
well.
I
don't
know,
do
you
want
to
add
more
about
that
john?
Why
exactly?
Why?.
E
D
Exactly
okay,
so
that
was
quite
a
simple
change,
but
still
and
remove
one
item
from
the
cypher
suite.
The
next
change
was
the
the
context
parameter.
There
is
a
new
application,
defined
parameter
called
context
in
the
end
of
exporter
and
the
purpose,
and
there
is
also
a
new
ayana
registry
where
these
contexts
are.
These
labels
are
registered
and
this
is
to
ensure
different
keys
for
different
contexts.
D
D
So
it's
there
is
previously.
There
was
in
section
seven
to
one
a
description
of
how
you
derive
the
master
secret
from
us
for
oscor,
based
on
the
advocacy
exporter,
which
is
defined
in
section
four,
and
we
have
this
other
draft
in
core
which
is
describing
how
to
use
ad
hoc
to
kiosk,
or
so
we
thought
it
would
make
sense.
We
also
checked
with
authors
of
that
draft,
to
move
this
this
part
of
the
key
derivation
from
from
this
draft
to
the
chord
draft.
D
B
Yeah,
so
maybe
I
can
comment
on
that,
I
didn't
I
didn't
really
that
tissue
and
github
kind
of
slipped
away,
so
I
didn't
see
it
when
it
was
merged.
My
first
comment,
when
I
was
going
through
this
through
this
list
of
changes-
and
this
particular
issue
that
you
were
discussing-
is
that
with
this
change,
we
are
kind
of
removing
the
link
between
ad
hoc
and
oscar
in
our
core
specification,
and
the
lake
charter
is
pretty
explicit
that
we
need
to
produce
an
egg
for
a
score.
B
So
my
concern
is
that
when
we
push
the
document
to
the
isg,
there
could
be
arguments
that
that
we
are
maybe
too
generic
or
that
we
are
not
really
meeting
that
charter
item
that
we
need
to
produce.
So
I
would
like
to
open
this
for
discussion.
Maybe
if
anyone
else
could
give
would
share
thoughts,
if
you
think
that
removing
this
particular
link
between
ad
hoc
and
oscorp
from
the
core
ad
hoc
specification
is
good
from
the
strategic
point
of
view
of
the
working
group.
E
Nobody
has-
maybe
I
can
give
some,
so
I
think
this
was.
This
discussion
was
probably
originally
started
by
me,
but
mostly
on
very
transport,
specific
porch,
specif
co-op
and
oscar
transp
transport,
specific
parts
that
started
at
some
point.
There
was
a
lot
of
very
core
specific
details
that
was
discussed
in
the
in
github
and
also
in
started
to
propagate
into
outside
of
the
co-op
and
oscore
sections
of
the
ad
hoc
draft,
and
then
I
suggested
to
that.
Maybe
some
part
should
be
moved
to
poor
without,
as
specifically
mentioning
the
key
derivation.
B
B
Ad
hockey,
yes,
ad
hockey
not
score
in
message.
Yes
in
message:
three
exactly
yeah
yeah,
so
so
I
guess
the
scope
there
got
extended,
but
I
mean
I
think
it
would
be
good
from
from
the
point
of
view
of
like
to
keep
this
link
on
the
derivation
of
the
oscar
master
secret
and
master
result
in
in
the
main
document.
B
A
C
F
C
Just
key
derivation
and
anticipating
possible
changes
in
edoc
about
connection
identifiers.
We
may
require
rules
for
translating
back
and
forth
between
edoc
identifiers
and
oscar
identifiers,
so
to
say
to
understand.
This
was
originally
possibly
all
for
redoc
and
all
for
lake.
It's
becoming
more
and
more
specific
to
co-op
and
dos
core,
where
it
kind
of
feels
like
appropriate
to
do
that
in
color.
At
least
that
part.
D
Actually,
so
there
are
other
discussions
related
to
I
mean
the
connection.
Identifiers
are
negotiated
in
ad
hoc
and
they
need
to
have
special,
there's
special
constraints
for
them
in
oscor
and
that
that's
that's
the
dependency
we
may
want
to
elaborate
on
in
in
the
other
draft
or
in
the
core
draft,
but
the
key
derivation
as
such,
I
think,
could
remain
here
if
people
think
that's
important.
E
Yeah,
I
I
think
key
derivation
could
go
in
either
drop
time.
I
would
be
perfectly
fine
to
moving
it
back.
I
think
the
the
reason
behind
this
change
was
not
in
any
way
to
make
ad
hoc
less
less
of
a
key
management
protocol
for
or
score,
but
but
he
has
to
make
sure
that
the
co-op
specific
interactions
like
maximum
amount
of
transmission
and
transmission
type
and
and
stuff
like
that
are
are
discussed
in
core
and
the
broad
and
the
scope
of
what
used
to
be
draft
colombian.
I
don't
remember
what
it's
called
today.
D
C
C
B
So
I
I
can
take
an
action
point
to
go
back
and
check
in
this
draft
and
maybe
propose
a
version
that
would
be
that
would
still
be,
let's
say,
compliant
with
the
lake
charter
and
that
we
are
very
specific
that
we
are
producing
and
a
naked
that
is
tailored
for
our
score,
that
works
with
oscar,
but
that
also
doesn't
take
into
account
all
the
core
specificities
and
details
into
this
document
yeah.
So
I
can.
B
B
D
Yeah,
okay,
yeah!
Yes,
please!
The
next
change
is
in
the
normative
language
on
failures
and
sending
errors.
Previously
we
stated
that
in
case
of
failure,
you
must
send
an
error,
and
that
is
now
in
light
of
potential
denial
of
service
attacks.
That
could
could
use
this
this
feature
or
this,
this
type
of
phenomenon.
E
D
Yeah,
although
I
thought
the
ops
feedback
was
to
use
non-negative
error
codes,
so
so
we're
somewhat
complying
with
their
recommendation
there,
but
we
don't
disallow
the
other
negative
yeah.
Any
more
comments
on
this.
We've
been
talking
about
error
codes
for
some
time,
and
this
is
the
latest
proposal.
We
don't
have
any
foresee
any
more
changes
at
the
moment
now,
but
yeah
there
we
are.
D
D
E
So
there
is
no
no
change
to
them
to
the
protocol.
It's
just
that
this
section
on
how
to
represent
the
point
has
been
made
a
little
bit
more
formal
in
its
own
section,
so
it
can
be
used
for
for
other
specifications.
I
think
it's
also
about
the
written
section
now
and
we
removed
the
before.
It
stated
that
the
the
the
receiver
could
choose
zero
of
or
one
for
the
sine
bit
of
the
y-coordinate,
which
is
secure,
but
it
seems
easier
to
just
fix
it
to
to
zero.
D
D
There's
been
this
constant
confusion
on
what
was
previously
called
application
data
and
then
auxiliary
data,
which
is
not
at
all
intended
to
be
arbitrary
application
data,
but
to
be
very
specifically
used
by
other
security
protocols,
in
particular
for
the
author
carrying
authorization
information
like
vouchers
and
access
tokens.
So
we
have
now
renamed
it
to
external
authorization
data
to
make
that
clear.
D
So
that's
renaming.
There
is
also
some
text
explaining
this,
but
there
is
no
change
to
the
protocol,
except
for
that.
We
also
added
this
external
authorization
data
for
to
message
four,
so
you
may
carry
that
in
message,
four
as
well,
and
it's
that
led
to
a
change.
The
message
four
was
previously
marked
because
there
were
nothing
to
encrypt,
and
now
there
is
an
encrypt
instead
of
a
mac.
D
E
D
D
D
Now.
The
second
group
relates
to
what
we
discussed
in
the
design
team
meeting
correlation
of
messages
and
how
that's
used
to
optimize
the
message
size
and
how
that
impacts,
the
message
format,
and
then
there
are
three
three
issues:
one
on
connection
and
key
identifiers
and
how
to
compactly,
represent
them
and
propose
change
there.
D
D
D
This
is
identifier
credential,
which
can
contain
the
identifier,
but
it
can
also
contain
the
actual
credential,
and
that
would
be
you
would
I
you
would
index
that
with
the
cosy
header
and
then
you
would
send
the
credential
so
and
how
would
you
do
this
for
republic?
That's
the
basically
the
question
and
before
we
go
into
that,
let's
note
that
we
have
a
related
problem
in
the
draft
and
that's
in
the
case
we
are
not
transporting
the
raw
public
keys.
D
So
that's
what
we're
using
today
to
ensure
that
raw
public
keys
are
the
same,
are
interpreted
the
same
credential
on
on
on
the
initiate
and
responder
side.
That's
also
something
that
we.
We
now
think
that
we
should
should
harmonize
with
with
something
that
we
define
as
a
real
public
key.
So
next
slide.
Please.
D
D
This
is
a
cwt
claims
list
containing
the
conf
confirmation,
cnf
confirmation
claim,
after
which
you
could
you
can
have
a
kosi
key.
That's
type
one
of
this
confirmation
claim,
and
then
you
have
the
actual
koseki,
and
here
you
can
also
insert
things
like
subject
names
and
key
ops
and
so
on
indicating
key
usage
so
that
that
would
be
one
version.
It
needs
to
be
deterministically
encoded
and
we
need
to
define
the
cosi
header
because
there
is
no
cosine
defined
for
keyboard
web
tokens.
D
D
D
A
D
D
And
on
the
topic
of
using
signed
objects,
we
could
use
the
self-signed
c519.
So
c509
is
this
newly
adopted
draft
in
cosi
about
a
seabor
encoding
of
x509
certificates,
and
that
is
so.
What
you
see
here
on
the
right
hand,
side
is
the
c509
with
which
essentially
doesn't
have
much
content.
It's
a
it
only
has
a
subject,
name
in
this
case
in
uic
64,
and
then
it
has
sort
of
the
things
related
to
the
key,
the
algorithm
and
the
public
key
and
the
digital
signature.
D
D
E
E
I
think
a
raw
and
a
cvt
claims
list
only
and
this
four
c
c
509
without
signature
would
be
about
the
same
size.
So
I
think
four
should
probably
not
be
designed.
I
think
three
would
be
like
claim
list
only
cwt,
plus
64
bytes,
and
that,
like
self-signed
certificates,
are
already
standardized,
how
you
transport
them
with
with
courses.
So
that's
already
supported
if
you
would
want
to
use
that,
but
I
think
cvt
is
probably
the
best
choice
here.
E
If
you
have
a
cvt,
a
full
cvt,
then
it
you
would
have
them.
I
don't
know
eight
more
bytes
for
a
tag
and
then
some
more
header
information-
I
don't
know
if
it's
10
or
12
bytes
or
16
bytes
more
than
the
rule.
I
think
the
overhead
is
maybe
10
10
by
it.
You
have
a
raw
public,
key
32
bytes,
then
maybe
10
bytes
overhead
for
for
the
rest,
and
then
maybe,
if
you
want
to
have
it
encrypted
encrypt
around
it,
maybe
10
more
bytes
or
12
or
something.
B
E
I
I
don't
know
if
it's
yeah,
I
think
somebody
should
calculate
some
more
numbers,
so
we
can
discuss.
But
after
seeing,
I
don't
know,
I
think
you
want
the
flexibility
that
cwt
supports
where
you
can
have
a
subject
and
you
can
have
a
key
ops
or
key
usage
part
and
other
things.
So
I'm
not
sure.
As
long
as
we
can
get
a
naked
like
claims
list
only
cwt,
I
think
there
is
no
reason
to
design
anything
more
more
more
lightweight.
E
D
B
D
E
A
E
E
F
E
E
A
D
D
So
we
had,
we
had
two
cases
in
the
previous
slide.
We
had
add
another
example
where
we
definitely
need
to
have
it
deterministic
and
that's
when
we
use
it
when
we
are
not
sending
it,
we
would
like
to
have
the
same
credential
to
be
used
for
when
we
not
sound
when
we
send
it,
and
then
I
definitely
mean.
F
D
D
D
E
F
E
D
D
E
E
A
D
D
E
Yeah,
I
guess
the
if
to
summarize
the
idea
is
to
define
a
head.
Cozy
have
the
parameter
for
cwt,
which
can
carry
either
one
parameter
that
can
carry
a
full
cwt
and
claims
list
only
cwt
or
two
different
header
parameters,
one
for
each
and
then
I
I
think
that
should
also
be
brought
up
in
the
cosy
working
group
for
discussion
and
see
whether
they
like
that.
E
So
so,
first
there
is
a
there
is
a
correlation
parameter
that
is
sent
in
message,
one
how
you
should
what
kind
of
correlate
underlying
correlation
you
have
in
the
transport
layer,
for
example,
are
you
using
co-op
request,
response
and
ins
in
in
that
case
in
who
is
the
client
and
who
is
the
server
there's
also
connection
identifiers
in
in
ad
hoc
in
each
package
in
message?
One
message,
two
message:
three
and
message:
four,
and
these
are
present
or
not
present,
based
on
the
correlation
and
they
had
the
hook,
adhoc
transport
and
negotiate
these
parameters.
E
One
has
been
that
is,
is
this
is
hard
to
understand
and
how
do
I
know
what
to
to
set,
and
then
earlier
version
of
the
draft
at
least
was
not
not
clear
on
how
you
were
presu,
definitely
not
clear
on
how
you
were
supposed
to
find
the
the
state
and
how
to
do
this
processing.
I
think
the
current
version
is
is
clear,
but
there's
still
a
lot
of
them
comments
about
to
have
identify
messages
with
them,
based
on
the
content
of
the
message
and
it's
unclear
whether
that
is.
E
Having
so
far,
these
changes
has
been
possibly
received,
moving
it,
making
it
clear
that
this
is
more
on
the
transport
layer.
The
application
has
some
benefits,
because
you
have
a
better
understanding
for
these
and
according
to
chris,
and
it
also
makes
the
it
much
easier
to
understand
when
you
get
rid
of
some
some
complexly
having
client
survey,
initiator,
responder
and
so
on.
Another
discussion
suggestion
was
to
just
make
all
these
mandatory
to
always
have
that
increases
the
message
size
where
it's
not
strictly
unnecessary.
E
So
I
think
these
are
all
very
much
transport
things,
but
the
reason
that
they
were
in
ad
hoc
was
to
try
to
simplify
things,
but
if
it
only
adds
complexity,
I
think
this
appendix
approach
might
be
better.
Do
you
have
anything
to?
I
think,
that's
where
we
are
right
now
we
have
a
pr
with
christian's
suggestion
that
needs
to
be
discussed
more.
F
B
I
agree
with
that
assessment.
John.
I
went
through
the
pr
before
the
meeting
and
I
think
well.
I
was
a
little
reluctant
on
doing
this
change
as
proposed
during
the
design
team
meetings
once
going
through
the
pr.
It
really
does
simplify
the
the
specification
so
in
terms
of
purely
editorial
and
the
understanding
of
the
specification.
I
think
this
is
a
good
change
to
make.
B
E
I
don't
think
so.
I
think
these
are
purely
transport
things
that
we
just
put
into
ad
hoc
to
as
a
hope
to
make
things
simpler
and
when
they
were
in
ad
hoc
they
were.
They
were
added
to
max
just
by
the
principle
of
adding
everything
in
the
adult
message
to
the
max.
I
I
don't
see
a
problem
to
removing
them,
and
it's
already
clear
today
that
with
some
of
the
correlation
parameters
like
siri,
I
don't
remember
if
it's
zero
or
three,
you
don't
send
any
connection
identifiers
at
all
and
it's
purely
a
transport
thing.
D
Protected
cryptographically,
this
is
what
yes,
it
is,
I
mean
they
they
are,
they
were
presented,
they
were
present
in
two
places
I
mean
they
were
present.
Both
both
we
have
the
actual
negotiation
of
connection
identifiers,
which
were
in
the
end
of
the
messages,
and
then
we
have
the
initial
the
message,
initial
connection
identifiers,
which
were
used
just
for
finding
sort
of
retrieving.
When
I
received
the
message,
I
look
at
the
initial
field.
B
Okay,
so
this
is
where
my
confusion
comes
from,
so
I
will
have
to
go
back
and
double
check
that
in
the
pr,
but
if
that
is
indeed
protected.
Okay,
I
mean
I
edit
in
edit
in
terms
of
the
editorial
readiness
and
clearness
of
the
pr.
It
looks
pretty
good
to
me,
okay
great,
so
that
would
be
my
personal
comment
on
that.
I
don't
know
if
anyone
else
has
had
a
chance
to
take
a
look
at
the
pr.
E
B
Yes,
my
comment
was
mainly
on
the
structure,
because
I
mean
obviously
when
you
see
the
pr
and
the
details
of
how
christian
had
envisioned
this,
it
makes
much
more
sense
than
to
just
generically
discussing
this
over
during
a
call.
So
that
was
that
I
was
referring
to
that.
So,
yes,
we
should
definitely
keep
it
open
for
a
little
bit
more
and
then
keep
the
discussion
going
on
the
on
the
pr.
D
B
D
B
B
D
D
I
mean,
I
mean
in
fact
we'll
come
to
that.
There's
a
discussion
about
identification
of
connection,
identifiers
and
and
key
identifiers,
which
is
also
somehow
impacting
single
bytes
or
messages,
and
then
that
led
us
in
the
design
team
meeting
led
us
to
the
discussion
about
what
what
kind
of
impacts
and
message
sizes
are
acceptable
and
we
then
had
to
go
back
and
recap:
what
were
the
target
message
sizes
and
where
are
we
in
our
in
our
byte
count?
D
So
as
you,
as
you
know,
the
the
protocol,
the
three
messages
message:
two
is
the
largest
message
currently
at
46
bytes
and
looking
at
the
benchmarks,
which
we
did
it's
now
two
years
ago,
I
think
for
which
was
based
on
on
narrowband
iot,
laura
one
and
sixties,
a
65
node
benchmark
the
most
severe
restriction
came
out
of
this
particular
benchmark.
It
was
45,
bytes,
downlink
and
then
malicia
went
back
and
revisited
those
calculations
and
I've
compiled
the
spreadsheet.
You
can
find
a
link
to
that.
D
If
you
want
to
take
a
look
in
issue
103.
and
it
I
mean
it's
clear-
that
there
are
a
number
of
assumptions
behind
this
45
bytes
and
there
are.
There
are
different
options
and
you
will
get
slightly
different
message
sizes
so
and
at
the
same
time
we
know
that
we
haven't
reached
the
optimum
message
size
in
terms
of
message
two.
We
can,
for
example,
concatenate
two
of
the
message
fields,
the
fmel
key
and
the
ciphertext
into
one
zebra,
byte
string,
which
would
save
one
byte.
D
D
So
that
led
us
then
again
to
the
discussion.
Are
we
really
right
on
on
these
benchmarks?
Should
we
interpret
them
exactly
on
the
byte
as
given
to
us
in
the
from
the
discussion
two
years
ago
or
what
is?
Are
we
happy
with
adding
single
bytes
in
the
interest
of
making
this
a
protocol
which
is
simple
to
amplify
it's
very
simple,
to
to
implement
in
in
constrained
devices,
which
is
actually
the
original
purpose.
B
Yeah,
so
maybe
I
can
comment
on
this
as
well,
since
this
is
mostly
relevant
to
the
six-thirds
benchmark
and
as
a
recap,
at
the
time
we
were
requested
to
give
some
hard
hard
limits
on
message
sizes
when
the
working
when
we
were
discussing
the
formation
of
the
working
group.
So
we
did
those
calculations
at
the
time
and
we
came
up
with
the
most
reasonable
assumption
or
in
terms
of
six-ish
multi-hop
networks
that
consider
five
five
notes
in
linear,
topology,
so
essentially,
four
hops,
four
hops
deep
network
in
in
the
drawing
setting.
B
So
the
bottom
line
is
that
the
five
node
benchmark
that
we
did
is
interesting,
but
this
is
by
no
means
a
hard
limit,
not
meeting
the
45
byte
in
message.
Two
would
simply
mean
in
succession
that
this
message
would
get
fragmented
when
traveling
on
the
la
on
the
on
this
particular
hop,
where
the
message
messages
to
is
too
large,
so
it
wouldn't
prevent
the
protocol
from
from
running
obviously,
and
it
would
a
little
bit
influence
the
performance.
B
B
So
I'm
a
little
split
in
terms
of
this.
What
what
to
give
is
the
guidance
here
because
I'm
very
familiar
with
the
sixties
network,
and
this
is
a
figure
that
we
gave
during
the
formation
of
the
working
group
45
bytes.
So
it
would
indeed
be
very
nice
if
we
could
fit
messages
into
those
into
those
limits.
A
B
So
this
is
definitely
not
a
hard
limit
in
terms
of
the
functionality
of
the
network.
This
is
a
hard
limit.
It
was
seen
as
a
hard
limit
during
those
discussions
that
we
had.
This
is
a
fact-
and
I
agree
that
if
we
now
change
this
and
we
consider
it
a
soft
one
that
it
could
raise
the
arguments
down
the
road
during
the
isg
evaluation
and
weather
everything
that
we
were
doing
all
makes
sense.
So
that's
why
I
said
that
I'm
quite
split.
E
E
B
D
Agree,
I
agree
so
no,
but
I'm.
I
think
this
is
a
good
discussion
and
I'm
I'm
I'm
a
little
bit
hesitant.
Also,
as
you
remember,
the
these
numbers
came
about
that
that
people
said
that.
Well,
you
need
to
have
a
strict,
a
sort
of
a
you
need
to
have
a
definite
target.
It's
saying
as
small
as
possible
is
not
an
engineerable
target,
so
you
need
to
have
a
limit.
D
So
that's
where
these
limits
came
from,
although
it's
always
known
that,
if
you
want
to
have
strict
limits,
you
make
a
lot
of
assumptions,
I'm
a
bit
hesitant
to
how
we
should
interpret
these
limits.
I
I'm,
I
think
we
don't
want
to
have
a
sort
of
a
discussion
where,
where
we
are
changing
limits
arbitrarily,
because.
D
Yeah
for
obvious
reasons,
but
but
I
think
that
I
think
that
changing
these
things
sort
of
adding
single
bytes,
I
don't
think
that
really
changes
the
argument.
We
are
still
quite
far
away
from
the
from
the
compressed
tls
sizes,
so
it
wouldn't
be
sort
of
it
wouldn't
be
the
bite
that
makes
the
difference,
I
think,
but
but
we
will.
We
might
expose
ourselves
to
that
discussion
and
we
might
not
want
to
do
that.
Yeah.
E
I
don't
know,
I
think
the
recent
discussion
has
been
that
maybe
we
can
these
things
that
was
the
the
byte
string
identify
that
has
been
identified
as
a
complex
way
to
do
save
a
few
bytes.
I
think
recent
discussion
has
more
been
that
we
can
actually
reformulate
this,
and
do
it
quite
simple
and
keep
the
bite.
E
E
E
B
B
That
was
used
as
an
argument
during
the
working
group
formation
with
the
tls
working
group
in
the
tls
guys,
then
we
can
finally
decide
if
we
want
to
make
this
to
incorporate
this
optimization
into
the
protocol
and
which
specific,
which
specific
optimization
to
reach
the
limit.
Would
that
make
sense.
D
Yeah,
it's
fine.
I
just
wonder
at
what,
when
do
we
I
mean?
Is
this
this
isn't?
Can
we
take
this
as
an
interim
meeting
and
does
it
matter
if
it's
an
entry
meeting
or
if
it's
an
official
idf
meeting,
because
we
would
like
to
have
a
decision
by
september,
I
suppose
so
that
we
can
that's
at
least
lose
target
for
for
completing
the
spec.
B
B
A
D
D
D
B
D
E
I
I
can
take
it.
I
guess
I
have
been
most
involved
in
this
discussion,
so
one
way
that
that
ad
hoc
saves
a
lot
quite
a
lot
of
bytes,
at
least
in
total,
a
one
to
two
per
message:
it's
to
to
transform
byte
strings
into
integers,
which
have
a
one
small
integers
which
have
a
one
byte
on
the
wire
representation
in
c
board,
and
this
is
used
in
the
document
for
the
connection
identifiers
as
well
as
id
cred.
E
So
these
one
byte
byte
strings
with
c
board
are
two
bytes
on
the
wire,
but
if
you
represent
them
as
a
small
integer,
they
have
a
one
byte
representation,
so
this
saves,
I
think,
five
bytes
in
total,
if
you
sum
up
the
messages,
but
this
has
also
been
pointed
out
as
the
biggest
over
optimization
in
in
haddock,
it
makes
the
there's
been
a
lot
of
questions
about
this,
and
also
people
in
companies
who
have
told
me
outside
is
like
wow.
Why
are
you?
Why
are
you
doing
this?
This
looks
really
strange.
E
Maybe
we
can,
instead
of
defining
that
kid
is
transformed
to
an
integer.
Maybe
we
can
either
expand
the
cosecant
to
include
byte
string
and
integer
or
define
a
separate
kid
parameter
that
allows
both
and
I
think,
that's
basically
more
or
less
the
whole
some
more
discussion,
then
in
the
design
meeting
these
were
discussed
and
it
was
identified
that
in
in
some
cases,
a
single
one,
byte
identifier,
which
could
be
the
empty
byte
string,
is
enough
because
this
server,
as
you
have
asymmetry,
you
have
a
lot
of
clients
and
maybe
one
server.
E
One
of
them
can
use.
One
side
can
use
the
one
byte
identifier,
which
would
be
in
message
two
and
you're
still
fine.
You
don't
need
to
have
this
integer
transformation
at
all
or
expand
anything,
but
that
might
only
be
true
for
the
connection
identifiers
for
the
for
the
kid
maybe
you
need
to
if
you
want
to
support
a
key
update
from
an
old
to
new
key.
E
D
Yeah
thanks
thanks
john
it
I
I
just
wondered,
so
we
need
to
progress
this
somehow.
There
is
a
pr
this
122,
which
is
doing
the
changes
and
is
also
indicating
what
happens
on
in
oscore,
because
roscore
we
are
using
the
connection
identifiers
as
sender,
identifiers
and
those
needs
to
be
byte
strings
and
those
needs
to
be
non-overlapping,
so
they
have
to
be
different
and
therefore
you
need
to
make
sure
that
what
that
the
mapping
you
do
between
byte
string
and
in
to
this
sender,
identifier
does
not
collide.
D
D
E
E
That
would
not
increase
the
the
that
would
not
increase
message
size
at
all
and
then
and
then
I
think
third
option
is
to
just
delete
the
integral
transformation,
and
maybe
it's
concluded
that
a
single
one
byte
is
actually
enough
and
then
it
would
also
not
increase
message
sizes.
So
I
don't
think
the
choices
are
keep
by
string
identifier
or
increased
message,
sizes,
you're.
D
F
Replacing
bistro
identifier
with
bistro
or
int
does
not
change
anything
because
booster
identifier
is
bistro
or
end.
So
the
the
question
really
is
whether
you
have
a
transformation
from
a
byte
string
with
a
single
byte
that
happens
to
be
less
than
than
48,
actually
less
than
49
into
an
inch
and
back
so
if
you
say
you
can
have
ins
there,
you
just
have
increased
the
the
space
of
potential
values
that
you
can
put
there.
D
F
All
the
all
the
protocols
that
want
to
use
ad
hoc
that
specify
what
they
put
in
there
have
to
make
a
decision
how
to
handle
this.
So
they
could
say
we
only
allow
end.
We
only
allow
byte
strings
where
they
could
say.
We
can
only
allow
byte
strings
of
seven
bytes
or
more
I
mean
they
can
define
that
in
any
way.
They
want.
D
F
E
E
D
E
D
D
D
This
is
again
a
simplification.
This
is
john's
insight
that
we
are
currently
defining
the
inner
max
based
on
cosy
encrypt
zero,
and
it's
it's
a
it's
a
it's.
It's
the
way
you
do
cause
encrypts.
You
have
to
define
all
all
the
things
that
are
part
of
it:
that
com
the
protected
header,
the
external
aed.
What
is
the
plain
text?
What
is
the
key?
What
is
the
nonce
etc?
E
E
The
main
part
where
ad
hoc
has
significantly
sick
ad
hoc
has
significantly
lit
smaller
max
than
than
tls.
I
think
that's,
maybe
the
most
biggest
difference
identify.
I
think
tls
might
have
a
bit
overkill.
There
will
extremely
large
mag,
but
erdog
might
have
a
little
bit
too
small
allowing
bigger
might
be
good,
so
this
would-
and
this
can
be
done
completely
without
increasing
message
size.
So,
instead
of
having
eight
eight
byte
mac
in
that
is
signed,
you
could
have
a
32-byte
mac.
E
That
is
signed
not
sure
if
it's
needed
for
security,
but
it
doesn't
hurt
also
in
the
current
ad
hoc
protocol.
The
tag
in
the
encryption
part
of
sigma
is
the
same
as
the
tagline
now
in
the
mac
part
of
of
sigma,
which
is
a
simplification,
but
might
not
allow
the
flexibility
that
you
want
to
by
replacing
a
cozy
mac
by
simply
using
the
hkdf
short
256.
E
E
D
B
D
E
It
increases
one
of
the
internal
security
parameters
in
the
protocol,
makes
it
much
more
aligned
with
tls
whether
it
affects
any
practical
security
of
the
like
outs
properties
of
the
protocol
itself.
In
the
end,
I'm
not
sure,
but
I
think
it
rather
strengthens
the
security
and
weakens
it
even
if
it's
simplification.
B
E
B
So
essentially,
this
is
a
past
implementation,
so
we
had
a
couple
of
joint
sessions
where
we
were
discussing
essentially
the
implementation.
How
can
we
best
organize
this
implementation
in
rust?
That
is
hackspec
and
then
during
these
sessions
I
mean.
Essentially,
while
we
were
working
out
the
details,
these
comments
came
out,
so
we
we
will
have
these
sessions
in
future.
I
cannot
tell
you
right
now
about
the
timeline.
I
mean
this
depends
a
lot
on
other
activities
that
we
are
having.
E
E
D
So
this
was
again
nikon
brought
up
in
the
design
team
discussion.
It's
very
good
input
was
the
question
about
the
the
currently
defined
cipher
suites.
So
so
we
there
are
four
ccm
based
cypher
suites.
There
are
no
charger
polycypher
suite,
so
that
was
two
of
the
comments
and
there
is
also
it
was
also
a
comment
about
whether
we
actually
should
allocate
one
byte
value
to
the
this
cnsa
cipher
suite,
which
is
really
for
high
security
settings
and
could
afford
another
byte
value.
D
E
I
think
it's
very
good
comments,
respect
christian,
I'm
not
sure
these
are
the
four
correct
one
or
that
we
even
need
so
many
ccm
based.
I
definitely
think
that
chachapoli
sufficient
should
be
added
and
yeah.
I
think
the
cnsa
can
probably
have
it
two
byte
identifying
that
has
a
lot
of
larger
overhead
anyway,
as
it
has
bigger
signatures
and
bigger
macs
and
tags.
D
B
Jericho,
obviously
yeah
I
mean
this
high
security
cipher
suite.
Definitely
I
don't
think
it
deserves
a
one
byte
value.
So
I
I
think
this
is
low
hanging
fruit.
Then,
regarding
chartra
20,
I
received
requests
from
the
developers
active
in
the
in
the
riot
space
in
for
the
riot
operating
system
about
the
use
of
chartrapoli.
B
If
ad
hoc
support,
so
I
referred
them
to
the
mailing
list
to
request
it,
I
don't
think
they
ever
did,
but
this
I
mean.
I
think
this
is
all
I
mean
that
we
should
add
chat
poly
to
the
to
the
cipher
suites,
I'm
just
not
so
you're
proposing
here
to
add
a
single
suite
with
chacha
poly
based
on
the
edwards
curve.
B
And
then,
regarding
the
ccm
we
have
the
on
our
side,
I
mean
the
ccn.
We
have
a
13
byte
non
ccm.
That
is,
that
is
supported.
So
this
is
the
one
that
we
care
in
terms
of
802.15.4,
because
we
have
those
hardware
accelerators
readily
available
and
then
for
the
others.
I
guess
we
should
keep
them
for
now.
E
I
think
it
was
not.
I
think
it
was
not
the
discussion
to
whether
it
was
the
right
variant
of
ccm
is
think.
Cozy
defines
like
eight
different
variants
of
ccm
or
something
I
think
edward
only
specifies
episodes
for
a
13,
byte
nonce
version.
I
think
that's
as
it
should
be.
I
think
the
question
is
these
four
combinations
of
ccm
with
the
other
algorithms.
Are
these
the
correct,
cyphers
suite
combinations,
and
does
it
really
need
to
be
four?
E
B
Okay,
okay,
it
would
be
helpful
if
you
had
listed
here
those
combinations,
so
I
don't
have
to
look
them
up,
but
I
suppose
this
refers
to
the
combination
with
the
13
byte
nouns,
that
is
the
mti's,
a
authenticated
decryption
algorithm
in
oscore,
with
the
edwards
curve,
with
the
nest
curve,
p2,
56
and,
and
then
two
others.
What
do
they
refer
to.
E
D
B
F
B
E
E
B
So
I'm
I
guess
what
what
is
important
there
from
my
point
of
view,
at
least,
is
that
the
cipher
suite
that
is
used
by
ad
hoc
self
contains
the
security
level
by
the
protocol,
so
that
the
cipher
suite
is
directly
affects
the
length
of
the
mac.
Even
if
you
use
the
kdf
there
just
to
make
the
I
don't
know
if
I
was
clear,
but
just
that
I
mean
the
goal
here,
is
that
the
security
level
is
fully
determined
by
the
chosen
cipher
suite.
E
Yes,
okay,
I
think
in
the
in
the
signature
case,
I
think
the
the
right
choice
of
mac
length
is
just
the
output
length
of
the
hkdf.
You
don't
need
to
truncate
anything
as
in
the
in
the
divi
helmet
case.
I
don't
know
if
you
should
define
it
as
a
separate
parameter
or
if
you
should
still
define
it
in
terms
of
like
the
tag
length
of
the
encryption
algorithm,
I
haven't
looked
into
what
could
make
most
sense.
B
B
B
B
B
B
Okay,
I
hear
none.
I
would
just
like
to
thank
rickard
for
taking
notes.
I
mean
this.
This
looks
absolutely
fantastic,
so
thank
you
so
much
for
jumping
in
and
yes,
I
see
steven
has
already
done
that
in
the
chat
thanks
steven
okay,
so
we
are
six
minutes
to
go
until
the
top
of
the
hour
with
none
discussion
items
left.
I
guess
we
can
conclude
the
meeting.