►
From YouTube: LAKE WG Interim Meeting, 2021-04-22
Description
LAKE WG Interim Meeting, 2021-04-22
A
A
A
A
A
D
D
D
We
had
also
a
new
one
from
peter
van
der
stock,
so
they're
all
10-ish
people
attended,
testers
or
observers,
and
we
kept
on
building
on
the
same
set
of
documents
on
the
google
drive,
so
a
cumulative
spreadsheet,
where
we
keep
track,
of
which
implementation
from
whom
supports
what
and
what
they
tested
with
what
configuration
settings
and
together
with
that,
we
have
also
for
each
pair
of
implementers
a
text
document
collecting
the
the
settings
they
especially
tested
and
the
detail
result
next
slide.
Please.
D
So,
a
bit
more
info
on
different
tests.
I
had
some
we
bit
of
understock
an
implementation.
As
I
mentioned,
we
focused
on
cypher,
suites
qn3
and
for
both
of
them
we
tested
all
four
authentication
methods,
but
focusing
on
certificates,
x-fi
chain,
and
especially
real
x,
509
certificates.
This
case,
and
notably
to
the
best
of
my
knowledge.
It
was
the
first
time
that
two
implementations
ever
could
test
those
particular
features
list
here
as
bullets,
so
cyprus,
three,
the
two
methods,
one
two
and
x
five
chain,
not
to
mention
real
certificates.
D
D
D
Next
slide.
Please
and
finally,
we
we
converge
with
implement
implementations
from
christian
timothy
and
me
focusing
on
surface
with
zero
authentication
method.
Three,
there
were
earlier
tests
between
me
and
christian
with
authentication
method,
zero
and
kid
again,
so
timothy
and
christian
can
actually
test
in
both
directions
for
lack
of
time
chris
and
I
could
test
this
particular
configuration
all
in
one
direction.
D
D
Yes,
they
said
the
things
you
learn
from
implementation,
especially
testing.
That
was
the
occasion
to
also
build
up
feedback
that
resulted
into
more
uses
for
the
drafts
we
plan
to
have
some
more
spontaneous
bilateral
testing,
especially
christian
timothy
and
me
in
the
coming
weeks.
Otherwise,
the
plan
is
to
have
another
two
hours
to
event
around
mid
mid
may
second,
half
of
may
we
will
surely
start
a
doodle
for
that,
and
that
was
all
from
my
side.
A
Thank
you,
marco,
so
I
have
a
maybe
a
question
or
two
just
regarding
some
understanding.
I
always
like
to
point
out
new
new
implementations,
and
my
understanding
is
that
peter's
implementation
is
has
been
tested
for
the
first
time
during
the
entropy
events.
Is
that
right,
yeah,
okay,
so
was
this?
Is
a
pete
is
peter
with
us?
I
think
I
saw
his
name
yeah.
B
A
A
D
A
C
A
F
F
So
generally
we
have
two
ad
hoc
implementations,
one
for
regular
microcontrollers
and
also
linux
capable
devices.
So
this
is
the
implementation
which
I
use
during
all
the
interoperability
testings,
and
we
also
have
one
second
implementation,
which
is
for
microcontrollers
with
a
trusted
execution
environment
such
as
trust
zone
and
next
slide,
please
so
for
the
for
so
our
ad
hoc
library
for
microcontrollers
with
a
trusted
execution
environment.
F
So
here
on
the
right
side,
you
see
the
separation
of
this
library.
So
generally,
we
cons
consider
as
critical
all
ad
hoc
keys
and
all
cryptographic
operations
which
we
execute
in
the
secure
world
and
in
the
non-secure
world
is
basically
the
complete
logic
of
the
protocol
and
when
we
have
a
call
from
the
non-secure
in
the
secure
world,
we
just
have
reference
to
the
key
which
should
be
used
next
slide.
Please.
F
F
F
F
F
F
F
So
next
slide
please,
on
this
slide,
we
see
the
same
for
the
implementation
with
a
trusted
execution
environment
so
on
the
top
are
the
flash
requirements
which
are
separated
first
for
flash
requirements
in
the
secure
world
for
fresher
comments
in
the
non-secure
world
and
then
the
sum
of
both,
which
is
the
the
first
group
of
bars
from
the
top
and
then
in
the
last
group.
We
have
the
case
when
we
don't
have
a
trusted
execution
environment.
F
F
So
here
we
see
that
we
have
some
increase
in
the
ram
requirements.
This
is
due
to
the
fact
that
when
we
have
a
trusted
execution
environment,
we
have
generate
two
virtual
processors
with
two
separate
stacks,
and
this
is
why
the
ram
cannot
be
reused
so
efficiently,
but
at
the
end
the
numbers
are
really
very
very
low,
and
this
is
not
not
a
problem
for
any
state
of
the
art
microcontroller.
F
F
A
Okay,
thank
you.
Thank
you,
stefan
so
yeah.
So
this
is
very
interesting.
Thank
you.
Thank
you
for
presenting
this
to
the
working
book.
I
believe
this
is
the
first
exhaustive
performance
study
of
an
ad
hoc
implementation
that
we've
seen
and
it's
really
good
to
have
this
quantified.
So
I
don't.
I
have
a
couple
of
making
one
question
I
was.
I
was
struck
by
the
by
the
figure
that
you
gave
of
30
seconds
computation
time
for
the
signature
operation,
so
that
was
done.
A
F
So
this
is
the
car.
This
is
a
cortex
m0,
okay,
so
this
is
really
very
weak
microcontroller,
which
runs
at
16
megahertz
and
we
are
using
a
software
implementation.
So
this
microcontroller
especially
does
not
have
a
extern
accelerator
for
asymmetric
operations,
and
this
is
something
which
takes
a
lot
on
this
small
device.
A
A
F
G
F
Crypto
crypto
crypto
so
note
that
the
scale
of
the
x
axis
is
logarithmic,
so
the
the
blue
bars,
if
you
look
at
the
blue,
bars
they're
many
thousand
times
shorter,
for
example,
for
the
cortex
m0.
In
the
certificate
case
we
have
1.3
milliseconds
for
the
logic
and
then
more
than
30
seconds
for
the
crypto.
A
Yeah
this
I
mean
this
is
kind
of
expected
right,
but
still
I'm
surprised
by
the
figure
the
trigger
it's
a
lot.
I
mean
I'm
especially
thinking
in
the
context,
for
instance,
of
the
six-digit
networks
and
the
open
ws
stack
where
we
don't
have
a
support
for
multi-threading.
This
would
throw
the
any
nodes
out
of
sync
with
the
rest
of
the
network.
So
but
we
I
mean
this.
A
B
A
H
H
I
I
I
C
Okay,
so
yes,
next
slide,
please,
we
are
now
in
version
six
of
the
draft
and
I
think
the
the
probably
best
reason
for
having
these
in
rooms
is
that
it
drives
us
to
submit
new
versions.
The
current
version
was
published
yesterday
and
it's
it's.
I
mean
it's
basically
following
the
process,
resolving
issues,
clarifications
and
so
on,
and-
and
we
need
to-
I
think,
if
we
didn't
have
this
interim
meeting,
we
might
have
just
gone
on
on
the
github
and
it's
good
to
to
make
these
new
new
versions
from
time
to
time.
C
So
we
have
a
this
new
section
outlining
the
message
processing,
which
was
not
sufficiently
detailed
in
the
previous
version.
We
have
an
optional
initial
byte
in
message.
One
the
null
byte,
which
we
discussed
at
itf
110,
is
now
included,
and
the
presence
of
this
is
depends
on
the
agreement
between
the
initial
agreement
between
initiator
and
responder.
C
This
has
been
discussed
in
a
number
of
previous
mail
threads
and
and
in
this
issue,
so
we
don't
think
that
we
should
actually
recommend
that
that's
that's
for
different
applications
to
recommend
what
what
kind
of
how
to
transport
error
messages
test.
Vectors
are
unchanged
just
by
assuming
that
c1
is
not
present.
C
And
now
we
have
this
applicability
statement,
which
is
still
a
topic
for
discussion.
The
sort
of
the
role
of
this
purpose
is
to
to
harmonize
the
agreement
somehow
between
or
the
expectations
between,
initiate
and
responder,
and
we
had
two
parts
of
text.
One
was
in
in
section
three,
seven,
one
in
appendix
c,
so
now
we
merged
it
into
essentially
everything
into
three
seven,
except
for,
for
example,
which
remains
in
appendix
c,
and
we
change
the
title
so
same
content
but
merged
deterministic
cbore
is
this
is
just
a
clarification.
C
That's
always
used
it's
supposed
to
be
always
used
in
particular
for
for
credentials
when
the
credentials
are
encoded.
We
refer
to
deterministic
encoding,
three
new
appendices,
one
on
message
deduplication,
which
address
the
this
item,
potency
issue,
which
we
are
coming
back
to
it
turns
out.
So
this
is
a
result
of
this
small
design
team
working
on
that
issue,
and
it's
actually
not
an
item
potency
solution,
it's
more
how
to
handle
duplicate
messages
without
duplicating
processing.
C
C
G
So
there's
been,
we
have
actually
been
noting
quite
a
lot
of
new
issues,
which
is
great
means
that
people
are
a
lot
of
people
are
implementing
and
analyzing
the
error
protocol,
and
there
is
no
no
major
issues.
I
think
all
issues
are
mine,
smaller
optimization
and
a
lot
of
how
to
interact
with
transport.
A
G
A
G
G
A
G
Yes,
that
also
so
two
parts
an
attacker
can
can
forge
message
three
or
message
four,
like
far
down
in
the
ad
hoc
processing.
Let's
say
they
forge
message:
four,
they
ascend.
They
don't
even
need
to
try
to
forge
it.
They
are
send
a
random
byte,
which
is
would
be
an
invalid
message
for
and
then
the
protocol
would
terminate
and
similarly
they
could
send
a
false
ad
role.
And
then
I
also
think
in
some
place
at
hog
says
that
if
you
receive
an
error,
you
must
terminate.
A
C
G
A
G
Then
you
can
vary,
it
would
not
be
possible
to
then
we
would
end
up
in
something
like
tls.
So
in
the
beginning,
tls
error
messages
are
not
cryptographically
protected
and
later
on.
Some
of
the
error
messages
are
cryptographically
protected.
So
then
you
can
verify
that
every
message
actually
come
from
from
the
other
party.
I
Just
a
question-
and
apologies
if
this
is
stupid
might
well
be
so
so
there's
a
difference
between
tls
and
ipsec.
In
that
ipsec,
you
may
get
unexpected
traffic
at
the
same
interface
as
you
would
expect
encrypted
traffic
with
tls.
Generally,
you
only
expect
the
traffic
that's
part
of
the
tls
session
because
of
the
transport
issues
for
ed
hook
up
our
applications
using
ad
hoc.
G
I
G
Yeah,
I
guess,
if
you
see,
if
you
see
stun
and
turn
it
as
we
have,
we
have
very
to
save
space.
We
have
very
small
identifiers
minimum.
So
it's.
If
you
start
sending
your
random
data,
it
will
be
quite
likely
that
you
will
not
unlikely
that
you
will
get
the
collision
pretty
soon
like
and
an
attacker
can,
of
course,
observe
the
connection
identifiers
and
send
something
that
will
be
processed
as
message
tree
or
message
for.
J
J
I
J
A
G
G
So
this
is
awesome
me,
I
commented
my
old
recognition
of
the
applicability
statement
when
it
was
first
great,
was
that
it
was
an
appendix
listing
things
that
you
need
to
agree
on
otherwise
yeah
or
you
need
to
at
least
support
the
same
things
other
things.
Otherwise,
obviously
things
will
not
work,
then
in
at
least
in
the
pre-version
six
version.
G
This
had
changed
to
a
to
basically
a
policy
framework
where
you
were
required
to
always
verify
that
the
cypher
suit
and
the
type
of
credentials,
and
so
on,
is
was
allowed
for
the
party
you
were
talking
to
and
that
that
made
me
a
bit.
I
don't
think
that
might
be
a
good
idea
to
mandate
this.
This
seems
like
policy
functionality.
That
is,
for
example,
not
included
in
tls,
which
might
be
done,
but
is
probably
not
a
mandatory
thing
to
down.
J
Bit
you
think
it's
important
to
to
actually
get
the
assurance
level
you
need.
So
in
the
end,
what
what's
said
in
the
sentence
needs
to
be
true,
but
that
sentence
of
course
needs
can
be
interpreted
in
a
rather
draconian
way.
I
mean
all
tls
implementations
allow
you
to
switch
off
certain
cipher
suites
for
your
application,
and
I
would
expect
an
ad
hoc
implementation
to
allow
that
as
well.
E
J
B
E
B
E
C
Yeah
yeah,
I
think
I
think
I
mean
this
is
really
good-
that
we
have
this
discussion
now.
This
is,
I
think,
the
proposal
of
adding
a
byte
to
message.
One
is
it's
a
little
bit
contradicting
to
what
the
direction
john
is
proposing
in
this
issue
here
is
to
make
it
I
mean
to
make
it
less
of
a
well.
You
can
correct
me
I'm
wrong
john,
but
I
I
get
the
impression
that
this
is
more
like
we
need
to.
C
It
needs
to
be
clear
that
certain
things
are
agreed
between
initiator
and
responder,
but
having
an
extensive
or
exhaustive
list
of
what
that
exactly
is
and
and
how
those
are
configured
may
not
be
in
the
scope
of
this
document
or
the
purpose
to
transport
information
about
that
in
the
protocol.
But
that's
I
mean
this
is
the
discussion.
G
My
comment
was
mostly
that
this
had
had
the
applicability
statement
had
grown
in
a
direction
that
I
don't
think
was
was
we
it
has
grown
and
become
bigger
than
what
it
was
when
we
agreed
to
have
these
appendix
at
some
point
ago.
I
I
don't.
I
don't
have
any
strong
feelings,
what's
the
right
thing,
but
I
think
we
should
be
careful
to
when
I
read
this.
It
seemed
like
you
need
to
implement
some
big
machinery
and
do
a
lot
of
checks,
and
that
seemed
expensive
in
terms
of
code
and
memories.
G
C
I
would
regard
your
question
feature
about
c1
there,
whether
it's
present
or
not.
The
basic
assumption
with
the
applicability
statement
is
that
it's
somehow
understood
from
the
transport
I
mean.
Maybe
it's
the
the
port
number
uri
or
something
you're
using
that
that
should
from
that,
from
which
it
should
be
clear.
What
what
is
the?
C
What
are
the
different?
How
are
the
different
parameters
set?
So
you
should
know
that
when
you
receive
message,
one
first
of
all
this
is
a
this
is
this
is
an
add-on
message
right
and
then
this
is
message
one
which
has
these
application,
where
the
applicability
statement
says
that
knowledge
should
not
be
present
or
something
like
that.
E
Yeah
I
understand,
but
what
I
see
is
that
now
I
have
a
state
machine
which
looks
at
the
different
messages
that
can
come.
But
if
one
message
gets
in
is
delayed
for
an
interminable
time
and
then
all
of
the
sudden
comes
in
while
the
whole
connection
has
been
forgotten
forgotten,
then
I
don't
know
what
to
do
is
the
message.
I
don't
know
if
it's
a
message:
zero
or
a
message
one
or
if
it's
a
message
three,
I
mean
it's
very
difficult
to
decide.
E
G
Yeah,
yes,
this
to
add
more
more
to
message.
One
seems
to
go.
It
is
just
adding
more
to
message
one,
and
we
recently
got
the
comment.
I
think
it
was
from
malaysia
to
try
to
remove
correlation,
which
is
one
thing
that
is
coded
in
message
one
already,
so
it
seems
to
be
a
bit
different
ideas.
I
think
we
need
definitely
need
more
discussions
on
on
this.
A
So,
regarding
the
so
regarding
the
correlation
parameter,
I
mean
draw
my
point
on
that
issue
was
that
I
was
just
probing
for
consensus
if
we
wanted
that
complexity
at
the
cost-
one
extra
byte
in
message
to
a
message
three,
because
the
complexities
seemed
extensive
to
me
for
for
so
I
wasn't
sure
if
we
wanted
to
include
that
in
the
protocol.
So
that's
kind
of
separate
from
this
discussion.
A
I
don't
see
the
connection
with
this,
but
yeah.
So
stephen
is
posting
on
the
chat
that
yeah
we
have
seven
minutes
to
go
so
regarding
regarding
this
particular
issue,
I
do
not
hear
consensus.
A
clear
consensus
is
too
much
forward.
I
I
propose
we
continue
discussing
this
on
the
on
the
github
page
and
because
there
are
no
comments
so
far,
so
I
invite
both
carsten
and
peter
to
leave
their
comments
on
this
on
this
issue.
Does
that
work
for.
A
G
Yeah
sure
so
this
was
a
comment
from
malicia
and
certificate
and
timothy
that
that
ad
hoc
does
not
give
any
recommend
requirements
or
guidance
on
how
to
use
this
label
in
it
that
it
should
be
forbidden
to
use
it
twice.
And
then
I
tried
to
discuss
a
little
bit
more.
What
should
be
for
me
than
not
like
a
single
application.
G
Then
we
might
want
to
have
still
let
the
application
add
things
to
the
label
and
then
two
different
options.
We
make
ayana
register
for
labels
and
then
we
add
a
context
parameter
to
the
exporter.
That
would
be
a
technical
change
or
we
make
an
ayana
register
for
prefix
labels
and
we
let
the
application
add
any
append
anything
to
the
label.
This
has
both
of
these
approaches
has
recently
been
discussed
in
emu,
but
we
did
not
do
the
prefix
solution,
because
tls
labels
are
not
prefixes
problem
with
context.
G
A
So
I
think
we
agreed
that
this
is
the
problem
that
we
need
to
solve.
Both
in
my
understanding
is
that
both
proposed
solutions
work
and
it's
more
in
in
terms
of
usability
where
the
challenge
arises.
So
I
propose
we
keep
discussing
this
on
github.
I,
my
personal
opinion
with
hats
off.
Is
that
a
context
parameter
a
separate
parameter
would
make
more
sense,
but
this
is
just
purely
usability.
G
A
Yes,
I
understand
that
this.
I
think
this
is
perfectly
acceptable,
so
we
define
labels
in
a
registry
for
different
applications,
so
this
is
hardcoded
kind
of
in
the
registry,
and
then
we
still
let
the
applications
decide
on
their
per
need
basis.
How
if
they
want
a
different
case
with
the
given
with
the
given
ad
hoc
session,
which
which
context
parameter
allows
them
to
do
so
to
me
that.
A
A
C
Have
a
proposal?
Yes,
so
it
seems
that
I
mean
there
is
a
number
of
issues
that
we
sort
of
that
relates
to
each
other
that
we
always
run
into.
I
mean
at
this.
At
this
stage
we
have
run
into
the
things
related
to
applicability,
statement,
the
correlation
factor
and
what
and
the
optional
elements
in
the
protocol
and
the
message
size
targets.
A
C
G
A
Okay,
I
agree
so
then
I
propose
the
next
step.
So
first,
maybe
we
should
plan
for
an
interim
early
june.
I
propose
and
then
or
end
of
may
and
then
so
that
we
can
have
both
the
interrupt
report
and
the
design
team
meeting
reported
for
that
interim
and
in
parallel,
just
after
the
meeting,
we
can
coordinate
your
own
on
forming
the
design
team
and
it
would
be
useful
if
you
could.
C
G
Yeah
just
want
to
point
out
two
things:
two
of
the
they're
already
pull
requests
for
two
of
the
issues.
One
is
this
suggestion
from
malaysia
to
change
the
transget
hash
format,
so
to
have
some
intermediate
values:
to
make
it
simpler
and
save
memory.
There's
always
already
a
pull
request
for
that
and
the
other
pull
request
is
a
suggestion
from
christian
related
to
an
issue
to
change
the
connection
id
encoding
to
a
simpler
format
and
reduce
complexity.
G
I
think
both
of
these
are
great
and
basically
ready
to
merge,
as
is
if
people
agree
then
for
for
the
future,
I
think
now
we're
discussing
bite,
sizes
and
optimization
for
for
the
near
future.
We
should
decide
what
exact
levels
we
are
optimizing
for
when
in
the
requirements
phase
a
year
ago,
we
decided
that
45
was
the
number
of
bytes
for
five
hopes,
six
dish
that
we
would
should
should
meet.
G
We
are
currently
at
46
bytes,
so
we
would
actually
have
to
optimize
at
least
one
more
byte
to
meet
that,
but
we're
also
seeing
discussion
that
some
of
the
optimization
is
already
a
bit
too
complex
and
people
would
rather
have
a
protocol
with
like
47
48
bytes
just
give
some
complexity.
I
think
that
we
should
decide
on
in
the
next
half
year
or
something
because
that
will
lead
to
technical
issues.
A
Changes
yeah,
yes,
john.
I
see
a
point,
so
this
was
one
of
the
inputs
to
the
working
group,
essentially
the
limits
on
message
sizes
coming
from
different
use
cases
where
red
hockey
is
expected
to
be
used.
One
of
this
is
six
dish
where
we
considered
the
use
case
with
five
hops
and
the
the
limiting
message
size
were
there.
There
was
in
case
of
the
downward
traffic,
and
we
made
some
assumptions
two
and
arrived
at
a
figure
of
45
bytes,
so
we
can.
A
A
I
hear
none
so
as
action
point
for
the
chairs.
We
will
schedule
the
next
interim
for
the
end
of
may
beginning
of
june,
we
will
coordinate
with
joran
and
john
on
forming
a
design
team
to
tackle
a
set
of
issues
that
are
pending
and
important
for
the
progress
of
the
implement.
Oh
for
the
progress
of
the
specification.