►
From YouTube: IETF111-LAKE-20210729-1900
Description
LAKE meeting session at IETF111
2021/07/29 1900
https://datatracker.ietf.org/meeting/111/proceedings/
A
Are
all
the
presenters
there
is?
There
is
marco,
there
is
john,
I
don't
see
euron.
A
A
And
I
see
euron
I
see
ben,
I
see
francesca,
it
seems
we
are
the
critical
mass
is
here
so
stephen.
I
propose
we
get
started
yep
so
good
evening
good
morning,
good
afternoon,
everyone.
So
this
is
the
lake
working
group
meeting
at
itf
111.
A
We
are
already
on
thursday
the
itf
week,
so
you
should
be
very
familiar
with
the
note
well
that
covers
this
itf
meeting,
notably
if
you're
aware
of
any
ipr
issues
that
are
discussed.
Your
request
kindly
requested
to
disclose
this
during
the
the
meeting
and
of
course
there
are
different
bcps
that
cover
code
of
conduct
and
other
important
policies
of
the
itf
that
cover
this
meeting
so
far.
We
have
never
had
any
issues
with
the
code
of
conduct
and
I
don't
expect
that
to
change
with
this
meeting.
A
A
We
are
in
the
state
that
the
main
deliverable
of
this
working
group,
the
ad
hoc
protocol,
has
been
implemented
in
seven
different
in
seven
different
implementations
that
were
tested
in
different
ways
mark
will
tell
us
more
about
that
during
the
interop
activity
slot
and
since
itf
110,
we
had
three
published
versions
of
the
ad
hoc
draft,
with
the
additional
version
pending
to
my
to
my
understanding.
A
A
We
have
a
milestone
that
we
previously
agreed
upon
to
ship
to
attempt
to
ship
the
ad
hoc
draft
to
isg
by
march
2022.
This
still
seems
plausible.
We
will.
I
would
like
to
discuss
this
during
the
next
step
slots,
how
how
the
auto,
how
the
author
team
sees
this
deadline,
especially
what
we
need
to
take
into
account
is
the
delay
for
formal
verification
once
we
declare
the
specification
in
stable
enough
state.
A
So
let
me
go
ahead
with
the
proposed
agenda
for
today.
Yes,
so
this
slot
covers
the
administrivia
and
the
gender
bash.
We
have
the
interrupt
activity
overview
led
by
marco,
followed
by
the
ad
hoc
slot
that
will
be
led
by
joran
and
john,
covering
both
the
the
current
status,
the
diffs
that
were
the
the
changes
that
were
done
since
I
tf-110,
as
well
as
the
overview
of
open
issues
and
how
the
author
team
sees
the
next
steps
in
terms
of
the
specification.
A
A
I
don't
hear
anyone,
so
I
I
guess
we'll
be
proceeding
with
this
agenda.
So
there
is
your
your
is
in
the
queue.
Yes.
A
It
looks
okay,
thank
you.
So
then
I
propose
I
hand
it
over
to
marco
with
who
is
leading
the
slot
on
the
interrupt
activity.
So
I
will
stop
sharing.
Let
me
see
how
that
works.
Stop
sliding.
A
C
Thank
you.
So
this
is
a
short
recap
of
the
current
status
for
implementations
and
interops.
We
had
recently
about
the
dialog
protocol
and,
as
malisha
mentioned
before,
I
could
count
seven
available
and
tested
implementations
that
were
lately
aligned
to
version
6
of
the
draft,
so
there's
rice,
implementation
in
californium
team,
ot
provided
two
implementations,
one
in
python
and
one
in
c
and
christian,
also
one
in
python,
building
on
timothy
p,
terency,
stefan
also
in
c
and
in
libya
from
isi
income
tng.
C
I'm
aware
also
some
more
implementations
that
still
have
to
participate
at
least
the
plenary
interop
sessions.
I'm
thinking
of
michelle
beget
michael
richardson,
and
I
learned
today
actually
of
one
more
from
indriya
malaysia.
Perhaps
you
want
to
say
some
more
detail
about
this.
One.
A
Maybe
so
I
can
just
fill
in
this
is
this
is
another
implementation
that
is
currently
led
by
indriya,
where
we
attempted
where
we
attempt
to
implement
ad
hoc
in
rust
and,
more
specifically
in
hackspec,
which
is
a
subset
of
rust,
with
the
main
goal
of
formally
verifying
the
c
implementation
for
microcontrollers
that
was
developed
by
timothy.
So
I
mean
this
will
be
a
fully
featured
rust
implementation
that
can
interrupt
and
we
expect
to
in
to
participate
in
the
interrupt
test
with
this.
C
Looking
forward
thanks
so
some
point
worth
noting
on
two
of
the
seven
implementations
tested
already,
the
implementation
from
from
an
offer
also
underwent
an
experimental
evaluation,
and
a
paper
was
was
published
about
that
with
results.
Considering
multiple
other
architectures
and
stefan
also
presented
those
results
at
the
interim
meeting
in
april,
and
the
implementation
in
contiki
from
lydia
was
also
run
during
the
intro
test
over
constrained
devices
and
their
local
setup
considered
rpl
over
an
ipv6
mesh
network,
and
it
worked
pretty
fine
while
interrupting
over
the
internet.
C
So,
since
atf
110,
we
had
a
number
of
bilateral
spontaneous
tests
between
implementers,
but
otherwise
we
had
two
more
official
interrupt
events,
one
in
april
for
version
five
of
the
draft
involving
five
implementations
list
here
and
the
results
were
reported
at
the
april
lake
interim
and
then
shortly
after
in
may,
we
had
another
round
of
interrupt
tests
on
version
six
of
the
draft
with
these
three
implementations
and
results
were
also
reported
at
the
june
interim.
So.
C
C
And,
as
usual,
we
are
keep
collecting
results
configurations,
any
information
about
these
tests.
In
that
google
drive
where
we
have
a
spreadsheet
detailing
which
implementations
we
have
supporting
what
and
which
implementation
was
tested
against
each
other
implementation
and
for
each
pair
of
implementers.
We
also
keep
a
dedicated
google
docs
with
more
details
and
raw
results,
like
even
console
output.
C
C
Another
configuration
with
services,
zero
sign,
sign,
authentication
and
x5
tsq
initial
type
was
covered
by
two
and
and
many
more
were
covered
by
one
implementation
pair,
not
exactly
the
same
one.
Of
course.
So
we
covered
as
a
pretty
huge
range
of
configurations.
C
And
seen
from
another
perspective,
we
overall
consider
six
test
implementation
pairs,
so
it
was
me
against
peter
stefan,
lydia
and
christian,
then
timothy
and
christian
and
lydia,
and
christians
and
half
of
these
pairs
were
actually
tested.
Reversing
the
diadoc
roles
among
co-op,
client
and
co-op
server.
C
As
a
next
step,
well
now
we
really
have
to
align
our
implementations
with
version
8
of
the
draft.
Here
I
just
quickly
list
the
the
major
things
I
I
could
identify
that
require
alignment
from
what
it
was
version,
6
or
7,
and
once
that
is
done,
we
plan,
of
course,
more
tests.
I
think
during
the
often
already
definitely
we
need
first
to
test
again
what
we
tested
before.
So
the
successful
protocol
completion
and
the
derivation
of
a
security
context
for
all
score,
then
you'd
be
good
to
test
something
more.
C
I
think,
like
the
possible
optional
use
of
message,
four
and
external
authorization
data
and
and
even
better,
to
intentionally
trigger
some
error
condition
on
the
other
peers,
so
that
error
messages
are
also
used.
B
So
you're
on
here
I
just
want
to
add
to
what
you're
saying
mark
on
this
test:
test
activity
about
different
error,
test
cases
and
also
the
corner
cases,
and
so
on.
That's
something
that
I'm
also
highlighting
that
we
might
need
some
help
with
setting
up
that.
So
we
had
we've
had
that
previously,
with
with
other
specifications,
sort
of
a
number
of
good
error
cases,
which
is
that's
not
yet
covered.
So
I
think
that's
good
to
highlight
that
too.
B
A
Okay
sounds
good.
Do
we
have
any
other
questions
to
mark.
A
On,
if
not,
I
propose
we
get
started
with
the
main
agenda
item
for
today,
and
this
is
the
discussion
on
the
status
of
the
ad
hoc
draft
and
the
open
issues.
So
we
have
a
consolidated
slide
deck
for
these
two
agenda
items.
Joran.
Will
you
be
leading
these.
B
A
E
E
B
Okay,
so
let's
get
started
so
this
is
the
status
and
and
open
issues
consolidated,
slides
as
malicious
pointed
out,
and
we
like
to
go
through
the
main
changes
since
last
meeting,
so
we've
had
a
number
of
interims
already,
but
we'll
repeat
some
of
the
outcomes
from
that.
B
We
also
made
some
changes
after
this
latest
version
and
so
that
we
like
to
present
and
then
there
is
a
a
separate
text
on
security
levels
and
design
goals,
one
item
and
one
thing
to
discuss
and
then
finally
open
issues
and
next
steps.
B
B
There
is
we
removed
the
optional
convention
connection
identifiers
from
the
the
messages,
so
we
still
retain
the
the
negotiation
of
connection
identifiers.
But
then
the
use
of
them
in
ad
hoc
is
is
now
deferred
to
transport.
I'll
talk
more
about
that
in
a
second,
and
we
have
renamed
auxiliary
data
external
authorization
data
because
of
a
confusion
with
application
data.
So
people
thought
that
these
fields
were
general
application
data.
B
You
could
put
anything
you
like:
that's
not
the
intent,
so
that's
there
is
the
renaming,
and
there
is
also
an
other
clarification
to
to
the
text.
B
Here
is
the
table
of
contents
after
the
changes,
the
method
and
correlation
since
correlation
is
out.
This
is
replaced
by
a
number
of
other
sections
detailing
connection,
identifiers
and
transport.
The
auxiliary
data,
as
I
mentioned,
is
being
changed.
The
applicability
statement
previously
in
appendix
is
now,
in
section
three,
a
subsection
of
section
three.
B
B
Slides,
as
I
mentioned,
core
is
removed
and
you,
as
you
remember
core,
that
was
an
identifier
to
signify
the
the
correlation
of
the
transport
and
the
purpose
of
that
was
to
to
be
able
to
so
you
could
compensate
for
for
when
tran,
when
correlation
was
not
available
in
co-op
and
you
could
add,
optional
connection
identifiers.
B
So
there
was
a
lot
of
issues
related
to
core
and
related
to
these
optional
fields,
and
that
was
complicated
and
at
the
end,
we
it
was
even
a
proposal
to
remove
it
and
then,
at
the
end,
we
actually
went
for
a
pull
request
by
christian,
which
moved
all
the
complexity
out
of
ad
hoc
and
then
specified
for
the
specific
transport
how
to
handle
in
this
case
co-op.
B
So
how
co-op
uses
connection
identifiers
is
very
straightforward
and
we
hand
it
it's
easy
to
describe
it
there
and
for
particular
transport
rather
than
in
general,
with
this
core
parameter.
So
we're
happy
with
that
change.
I
think
that
simplified
the
protocol
in
the
in
a
similar
spirit.
We
have
removed
the
by-string
identifier,
which
was
also
considered
an
over-engineering
of
of
use
of
seabor
seaboard,
byte
string.
B
So
we've
replaced
it
so
the
connection
identifiers
can
now
be
either
byte
strings
or
or
c
or
imps,
and
there
is
then
the
complication
of
which
was.
The
reason
for
introducing
this
in
the
first
place
is
that
you
need
to
map
connection
identifiers
to
all
score
sender
ids,
which
are
byte
strings,
and
that
needs
to
be
done
in
a
unique
way
which
avoids
collisions,
but
by
introducing
this
mapping
now
so,
instead
of
the
pi
string
identifier,
we
have
a
mapping
from
connection
identifiers
to
oscar
sender
ids.
B
So
you
could
verify
what
oscar
sender
id
will
get
and
you
can
avoid
collisions.
So
that's
how
it
was
handled
with
connection
identifiers
by
string.
Identifier
was
also
used
for
key
identifiers
and
that
we
have
addressed
by
introducing
a
new
cosi
header,
kid2
of
which
can
have
either
byte
string
or
or
enter
as
value
and
there's
a
separate
slide
on
k2.
So
I'll
get
back
to
that.
B
B
Then,
when
it
comes
to
security
processing,
there
is
the
this
change
of
trans
transcript
hash,
which
was
an
input
from
implementers
to
simplify
what
you
need
to
store
between.
You
have
sent
the
previous
value
and
receive
the
next
so
that
match
that
sort
of
takes
into
account
with
the
definition
of
the
transcript
hash
and
there
is
a
new
application
defined
parameter
context
in
the
adwords
exporter
also
feedback
from
this
time
from
the
formal
verification
guys
that
pointed
out
the
need
for
uniqueness
in
terms
of
keys
export
keys.
B
There
are
some
more
details
on
compact
representation
of
ephemeral,
public
key,
so
how
the
y
value
is
encoded.
There
are
new
cipher
suites
based
on
churchill,
20,
poly
1305,
also
on
request,
and
then
there
are
some
changes
to
normative
language
like
for
for
failure,
whether
you
should
what
what
whether
you
must
or
should
send
an
error.
So
now
it's
a
recommendation
and
to
consider
potential
denial
of
service
attacks,
and
there
is
also
whether
the
send
errors
should
be
a
successful
request
and
response
or
not
that's,
that
recommendation
is
removed.
B
Same
topic
so
yeah,
we
also
some
terminology
changes.
I
only
mentioned
all
we
already
mentioned
auxiliary
data.
There
is
this
protocol
instance,
which
is
now
called
session
to
get
harmonized
terminology
quite
a
few
clarifications,
so
sibor
now
always
reverse
the
deterministically
encoded
sebor,
that's
quite
clear
that
we
wanted
well,
it
wasn't
spelled
out.
B
There
are
distinction
between
the
different
uses
of
the
connection
identifier
for
for
us
for
ad
hoc,
and,
as
I
mentioned,
that
we
need
to
the
external
authorization.
Data
requires
specification
and
registration
of
the
aad
type.
So
it's
not
any
type
of
application.
Data
ead
4
was
not
was
only
marked
and
now
it's
encrypted
as
well.
That's
on
request
from
an
implementer
and
a
number
of
other
comments
by
marco
malicia
and
peter.
So
we're
very
grateful
for
those
there
are
six
new
appendices.
B
I
already
mentioned
a
b
is
on
compact
representation
of
elliptic
curve
points.
So
as
a
general
text
on,
for
example,
when
you
use
diffie-hellman.
B
So
that's
something
that
can
be
referenced
from
from
other
specifications
is
needed
if
needed.
The
cddl
definitions
have
got
one
section
of
their
own
compiled
that's
on
request
from
an
implementer
message
deduplication.
We
talked
about
that
last
itf,
meeting
that
this
is
now
completed.
There
is
a
description:
how
to
handle
transport,
which
does
not
support
message
deduplication
and
without
make
causing
a
security
issue
and
g
describes
transports,
not
natively
provided
correlation,
where
appendix
a
is
one
example
and
how
you
do
it
over
co-op
and
then
there's
a
change
log
upon
this
as
well.
B
B
There
are
a
request
to
register
cosi,
header
parameter
for
zebra
web
tokens
or
for
uccs,
which
we
come
to
in
next
slide,
and
there
is
this
kid2
cosy.
Header
parameter,
updated
references
and
additional
security
considerations.
So
that's
about
it.
What
we
did
in
in
version
8.
B
So,
unless
there
are
any
questions
on
this,
particularly
I
I
move
on,
there
is
one
more
slide,
and
this
is
what
we've
done
since
post
since
version
eight
yep
go
ahead.
D
Yes,
I
did
have
a
question
so
earlier
on.
You
had
mentioned
that
the
connection
ids
were
removed
from
the
ad
hoc
messages
themselves,
other
than
just
transporting
them,
with
the
idea
that
the
underlying
transport
would
be
able
to
use
those,
and
I
was
just
wondering
if
we
somehow
include
the
connection
ids
in
the
cryptographic
bindings
to
the
connection
like
so
that
the
the
result
of
our
our
crypto
ties
us
to
that
connection.
So
that's
it
sounds
like
no
okay.
B
Yeah,
no,
I
maybe
don't
want,
wants
to
fit
in
here,
but
my
answer
would
be
no.
The
connection
identifiers
are
are
they
are
negotiated
for
the
purpose
of
being
so
that
you
could
make
them
unique,
but
when
they
are
used
by
transport
or
by
someone,
you
know
someone
later
that's
sort
of
up
to
them,
but
they
need
to
comply
with
the
security
requirements
of
the
application.
They
are.
They
don't
have
a
security
function
in
you
know
sure.
D
E
Yeah
and
I
think
the
connection
and
how
you
look
up,
the
connection
is
also
the
processing
is
better
detailed
now,
but
if
you
have,
I
think
the
cryptographic
protection
was
added
just
because
these
parameters
were
a
part
of
of
ad
hoc
and
then
you're
supposed
to
predict
everything.
That's
part
of
ad
hoc
but
yeah.
If
you
have
any
comments
on
on
the
current
draft,
we're
hoping
to
receive
them,
but
right
now,
they're
not
protected,
and
we
don't
need
think
they
need
to
be
protected.
A
So
I
mean
I
had
the
same
question
in
github
while
we
were
discussing
this
issue,
so
I
I
guess
one
thing
worth
noting
is
that
we
are
removing
the
optional
connection:
the
transport
of
optional
connection,
identifiers
from
the
wire
where
the
mandatories,
the
connection
and
the
identifiers
are
still
there
and
they
are
included
in
transcript
transcript
cache.
Is
that
correct?
Your.
B
B
I
think
that
I
mean
it's
a
good.
It's
a
good
discussion.
We
have
thought
about
it,
but
we
might
have
thought
wrong.
So
please,
please
check
it
out
and
see
if
you
agree
with
the.
A
B
That's
a
good
good
point.
Okay
would
would
you
like
to
do
that
malisha,
do
you
have
them
or
should
I
do
it.
B
Then
we
go
to
the
the
very
late
changes,
which
is
what
happened
after
submission.
We
wanted
to
fit
this
in
as
well,
because
we
think
the
issue
is
from
from
a
working
group
point
of
view.
We
have
discussed
this,
so
we
think
we
have
resolved
it,
but
we
didn't
have
time
to
to
put
it
into
the
draft
before
submission
deadline.
B
So,
but
now
there
is
this
part
as
well,
which
is
dealing
with
and
how
to
handle
raw
public
keys
by
value
and
the
format
of
credits,
and
this
was
based
on
a
discussion
in
an
interim
where
we
got
well
like.
Basically,
we
had
a
number
of
proposals
for
for
how
to
identify
and
carson
pointed
us
out
to
this
work
on
unprotected
cvt
claim
sets.
B
So
so
there
is
something
called
an
unprotected
cbt
claims
that
cwt
is
the
zebra
web
token,
and
if
you
just
take
out
the
cosi
wrapping,
you
get
the
unprotected
claims,
which
is
a
map
seabord
map
and
that
that
is
actually
a
very
natural
format
for
defining
raw
public
keys.
So
that's
what
we're
using
and
we
have
added
in
section
35,
the
analogous
use
cases
to
using
cwts
instead
of
certificates.
B
We
also
replaced
the
example
with
the
credential
was
for
a
row
public
key
with
the
credential
of
a
uccs.
So
that's
the
picture
on
the
right
here.
Where
you
see
there
is
there
is
this
claims
for
for
subject?
Subject
number
two
here
can
use
to
specify
an
identity,
and
the
confirmation
claim
has
a
subclaim
coaster
key
which
we
could
use
to
carry
the
key,
so
it's
very
well
suited
for
for
the
purpose,
so
that
and
that,
in
connection
with
that,
we
made
a
lot
of
editorials
in
section
three
five.
B
So
we
hope
you've
resolved
three
issues
here:
120,
515
and
88.
Also
the
opportunistic
use
case.
Please
have
have
a
a
look
on
the
master
branch
currently
and
then
we
will.
If
you
are
no
comments,
then
we
will
close
those
issues
after
version
8,
we
also
did
some
clarifications
to
be
able
to
close
a
number
of
of
issues
and
and
particularly
one
where
the
terminology
is
changed.
We
are
not
using
the
term
null
which
may
be
misunderstood
and
using
the
term
nil,
which
may
be
used
in
the
cyborg
or
cddl
context.
B
B
In
addition
to
the
specification,
there
was
a
request
from
the
people
working
on
formal
verification
of
ad
hoc
to
provide
input
on
what
are
the
intended
security
levels
and
design
goals
of
ad
hoc
and
john
has
written
a
short
text
about
that.
That's
currently
uploaded
to
the
github
and
comments
are
welcome.
Do
you
want
to
say
anything
about
this?
John.
E
Yes
sure
and
then
maybe
malaysia
can
fill
in.
So
I
I
wrote
there
was
some
discussion.
There
was
a
request
from
karthik
and
it
was
some
discussion
on
the
list.
I
sent
some
preliminary
discussion
on
the
list
and
then
I,
after
thinking
a
little
bit
more,
I
filled
in
some
more
detail
and
then
published
it
as
a
text
format.
I
hope
it
fulfills
base
more
or
less
what
character
wants.
The
the
the
discussion
makes
a
lot
of
comparison
to
tls
1.3,
which
is
a
quite
similar
application.
E
Layer,
sigma
based
protocol
and
now
militia
has
suggested
that
we
should
write
this
up
in
a
more
academic
paper
form
or
a
letter
and
publish
it
to
a
pre-print
and
hopefully
also
to
some
somewhere
else.
Maybe-
and
that
seems
like
a
good
array
malicious.
Maybe
you
won't
want
to
take
over.
A
A
Is
this
is
really
a
preliminary
idea
I
had
while
going
through
the
slidex
today?
So
essentially
I
mean
my
goal
here
is
to
really
attract
the
the
crypto
guys,
the
formal
analysis
community,
to
look
at
the
protocol
once
we
declare
it
as
stable,
and
I
think
formally
publishing
publishing
this
in
a
letter
or
in
some
academic
format
in
a
workshop,
maybe
would
would
permit,
would
would
help
toward
to
reach
that
goal.
So
I
mean
obviously
we
can
discuss
this
further.
A
B
Okay
sounds
good
to
me.
I
think
that's
excellent.
This
I
mean
this
text.
Certainly
well,
I
mean
could
end
up
in
the
draft,
but
I
think
it's
better
not
kept
in
the
draft.
It's
really
has
a
separate
purpose,
so
so,
instead
of
feeling
feeling
the
draft
with
this
type
of
information,
I
think
it's
excellent
if
this
could
be
published
in
some
other
way,
and
this
is
a
really
good
start.
I
think-
and
people
are
welcome
to
to
comment
and,
I
suppose,
join
the
activity
as
well.
If
they
want
to
isn't
that
right.
B
B
A
B
If
you're
interested
join,
join
the
relevant
interim
for
the
discussion.
A
B
Great
okay,
so
then
move
over
to
the
open
issues.
B
So
here
are
the
open
issues.
As
of
monday,
I
think
I
tried
to
classify
them
into
minor,
straightforward
issues,
the
green
ones,
those
which
are
somewhat
independent
from
the
specification
and
those
which
we
need
at
some
point
to
take
a
decision
on
and
well
the
straightforward,
that's
straightforward.
I
suppose
we
need
to
just
do
it
and
the
the
blue
ones
is
basically
the
items
where
we
could
publish
without
solving
them.
B
But
if
there
are
solutions,
then
we
can
add
that
to
the
document
and
in
particular
here
we
have
the
test
vector
issues
I
mentioned
previously
in
in
conjunction
with
marco's
presentation
that
we
need
to.
We
have
a
request
for
json
test
vectors.
We
have
a
proposal
for
a
a
a
format,
but
we
haven't
really
completed
on
that.
So
that's
something
we
started,
but
we
haven't
really
completed
on.
We
have
basically
prioritized
the
spec
instead
of
making
a
lot
of
inputs
around
test
vectors.
B
There
is
also
a
issue
47,
which
has
a
number
of
requests
on
test
vectors
which
we
haven't
been
able
to
comply
with.
That's
probably
helpful
when
we
have
the
final
specification
to
have
to
to
easily
make
test
your
your
implementation
against
those.
So
that's
something
that
that's
really
good,
but
not
not
strictly
necessary
for
completing
the
specification
and
when
it
comes
to
the
black,
the
I
don't
say
blacklisted,
the
black,
the
black
issues
here
they
are
have
a
separate
issue,
each
a
separate
slide.
So,
let's
go
to
to
those.
B
E
Take
this
I
have
within
these
seers,
so
this
is.
This
is
an
issue
and
a
couple
of
crs.
So
the
idea
here
is
to
simplify
the
mac
calculation.
The
mac
is
now
and
with
mac,
it's
the
mac
in
in
the
sigma
protocol
which
is
later
signed,
and
currently
the
mac
is
calculated
with
an
a80,
and
we,
the
idea
here,
is
that
we
simplify
the
mac
calculation
by
calculating
it
with
a
hmac
is
basically
takes
away.
I
think
one
page
or
one
and
a
half
from
the
specification,
and
it
also
have
other
advantages
right
now.
E
I
think
that's
fine
security,
wise,
but
in
the
signature
case
the
the
mac
could
be
much
larger,
like
32
bytes,
which
is,
for
example,
is
in
tls
103.
So
without
any
additional
overhead
it
doesn't
cost.
Anything.
Association
here
is
to
change
the
a80
to
hmac
using
the
ad
hoc
kdf.
This
allows
us
to
have
larger
macs.
It
seems
much
simpler
in
the
specification
and
in
implementations,
and
it
also
allows
us
to
separate
the
encryption
part
from
the
mac
part
yeah.
E
I
think
there's
still
some
there's
some
there's
an
issue
open
under
some
discussion
here
we
got
some
earlier
comments.
I
think
it
would
be
very
good
to
get
more
comments
from
implementer.
I
think
the
cryptographic
things
are
fine,
but
we
would
like
very
much
like
more
some
more
new
comments
from
implement
what
is
easy
to
implement
here.
E
A
Would
really
like
to
hear
the
work
group's
opinion
on
this.
This
seems
like
a
good
change.
Based
from
what
I
read
in
the
issue,
description
of
john
that
you
made.
Maybe
you
could
comment
on
the
point:
improved
security
that
you
make
while
using
the
kdf
instead
of
a
mac.
How
does
this
play
cryptographically.
E
E
Yeah,
I
I
don't
think
there
was
a
problem
with
the
old
construction,
but
this
is
clearly,
I
think,
equally
secure
or
more
yeah,
and
it's
also
much
more
flexible
and
simple.
So
I
think
this
is
something
we
should
do,
and
this
is,
I
think,
if
everybody
agrees,
this
will
be
merged
in
in
some
weeks
and
then
we
can
produce
new
test
vectors
and
have
some
hopefully
some
interrupt
with
this.
This
is
the
as
far
as
I
know,
the
last,
the
last
current
issue
that
will
change
test
vectors
and
interrupt.
A
F
E
I
think,
since
since
the
slides
have
been
done,
we
I
realized
that
the
ex
these
are
only
the
the
kdft,
the
p,
that
the
exporter
should
probably
stay
as
a
byte
string,
because
that's
like
an
external
interface.
But
what
you
say
is
that
you
want
the
kdf
to
be
a
sequence
rather
than
an
array.
G
B
H
Yeah,
just
two
things
one
is:
I
think
that
I
think
this
change
seemed
okay
and
if
it
wasn't,
I
guess
that
would
we'd
find
that
out
in
the
wash
when
we
do
the
crypto
analysis
later
on.
I
guess.
Secondly,
the
other
thing
I
want
to
say
is
we're
at
15
minutes
to
go.
A
B
A
B
Think
john
supposedly
is
good.
Let's,
let's
do
it,
and
I
I
mean
candidate
one
here
is
is
is
a
good
start.
We
try
that
we
put
that
as
an
implementation
version
and
we
try
out
the
implementation.
Then
we
get
the
feedback,
so
I
think
that's
the
right
way
to
go
and
we
can
do
that
fairly
soon.
I
think.
A
Sounds
good,
so
that
means
merging
the
pr
and
yeah
integrating
it
with
the
next
version
of
with
the
next
published
version
of
the
draft.
B
B
Okay,
great,
let's,
let's
move
on
then
so
we
have
time
for
the
next
steps,
and
so
there
were
two
other
issues
highlighted
as
need
feedback
from
the
working
group
and
both
of
those
we
don't
want
to
discuss.
So
that's
why
I
I
put
them
at
last:
no,
no,
I'm
just
okay.
So
this
is
things
that
we
have
discussed
for
for
length
and
we
just
want
to
fix
the
time
when
we
when
we
should
finish
them
off.
So
this
is
based
on
a
on
the
general
question
about
this
issue.
B
103
is
based
on
the
general
question.
What
is
the
right
level
of
message
optimization
now?
You
can
somehow
always
squeeze
in
another
byte
or
at
least
to
some
extent,
but
we
are
doing
a
protocol
for
for
constrained
settings
and
we'd
like
to
have
small
message
sizes
as
well
as
simple
processing,
and
there
is
a
trade-off
there
so,
but
we
do
have
a
target
message
size
of
course,
from
the
requirements
work.
B
We
derived
sizes
of
of
the
messages
from
the
benchmarks
in
arab
and
iot
six
station,
laura
one-
and
this
was
two
years
ago.
There
is
a
more
detailed
estimate
of
overhead
of
six
dish
available
from
this
link,
and
also
you
can
it's
linked
from
the
issue
in
the
github
and
the
actual.
The
reason
for
this
discussion
now
is
that
the
current
message
is
they
comply
with
the
lake
requirements,
except
for
one
message,
which
is
one
byte
too
large.
B
So
that's
message
two
and
we
can
fix
this.
For
example,
we
could
use
known
lengths
of
we
have
the
the
ephemeral
key
of
the
responder
and
we
have
the
cipher
text
in
message.
Two
and
those
are
both
individually
encoded
as
c-bor,
but
there
are
known
lengths,
so
we
could
concatenate
them
and
put
them
into
one
supervisory,
so
that
would
fix
the
formally
against
the
lake
requirements.
B
But
it's
not
so
nice
because
we
sort
of
go
beyond
the
seaboard
and
then
this
the
question
we've
had
and
we
have
discussed.
Should
we
do
this
or
shouldn't
we
do
this?
We
do
want
to
comply
with
requirements,
but
looking
at
the
impact
here,
it
wouldn't
have
any
impact
on
lorawan,
no
impact
on
narrowband
iot
and
for
sixties.
The
particular
use
case
was
a
five
node
network
with
four
hops
and
one
of
those
hops.
There
would
be
fragmentation,
so
is
that
is
it
worth
it?
Maybe,
and
it
doesn't
really
matter
for.
B
I
don't
think
it
matters
a
lot,
whether
we
do
it
to
change
or
whether
we
don't
do
it,
but
we
still
need
to
have
an
opinion
about
this.
So
in
the
interview
meeting
we
agreed
that
we
should.
We
should
revisit
the
issue
of
course,
but
we
wait
until
we
are
done
with
the
rest
of
the
messages.
So
so
we
know
exactly
what
we,
what
type
of
trade-offs
we
are
making.
B
A
Alicia
researcher
cut
off,
obviously
so
yeah.
I
would
just
like
to
comment
on
the
on
the
six-ish
use
case
there.
At
the
time
before
the
lake
working
group
formation,
we
were
requested
to
cover
to
to
create
a
use
case
for
sixth
dish
and
to
come
up
with
those
numbers.
Those
numbers
are
valid,
and
now
they
have
been
more
detailed
in
this
overhead
estimator
that
euron
included
in
this
slide.
A
So
I
would
just
like
to
clarify
that
the
current
numbers
of
ad
hoc,
the
message
sizes
do
not
fit
in
one
particular
use
case
when
the
initiator
or
when,
where
the
ad
hoc
initiator
is
the
six
dish.
Sixties
pledge
the
node
that
is
trying
to
join.
If
we
reverse
these
roles,
I
mean
this.
A
This
is
better,
but
still,
I
think
it
would
be
good
if
we
could
achieve
if
we
could
meet
those
hard
limits
that
we
discussed
when
we
were
when
the
working
group
was
formed
and
that
we
had
in
the
discussions
during
the
adoption
process
of
the
of
the
draft.
B
D
B
A
B
Not
right,
okay,
looking
at
the
clock,
so
we
have
also
another
issue
of
the
similar
kind,
which
is
the
mandatory
to
implement
cipher
suite
something
that's
issue
number
22.
We
have
discussed
it
at
multiple
meetings,
multiple
interims.
B
We
have
a
resolution,
a
potential
resolution
in
the
draft
which
we
thought
we
were
happy
with
we
closed
that
and
then
there
was
a
question
about
how
did
we
really
motivate
this
and
that
was
not
documented
sufficiently
so
we
reopened
the
issue
and
john
had
written
a
summary.
This
is
done
in
mail
in
may.
I
think
this
mail-
and
we
have
not
had
any
comments
so
far
on
this,
but
the
proposal
is
still
that
we
we
keep
this
open
the
discussion
of
mti
will
we
might
not
be
able
to
find
a
solution.
B
Everyone
is
is
perfectly
happy
with
at
least
at
least
if
we
are
going
to
select
a
specific
suite.
So
but
we
have
a
proposal,
we
keep
that
open
and
unless
there
are
any
complaints
before
working
group
last
call
we
just
closed
this
issue
and
if
there
are
complaints
well
then
we
probably
have
to
make
a
vote
for
if
we
want
to
have
this
formulation
or
if
we
want
a
specific
suite.
H
So
yeah
just
to
note
we
don't
vote,
but
the
chairs
will
figure
something
out
if
we
get
to
that
position.
Okay,.
B
B
B
Minutes
is
enough:
five
minutes
enough.
Okay,
so
there
is
actually
one
issue.
I
should
have
brought
up
a
little
bit
earlier,
typically
anyway,
so
we
have
the
kid
too,
as
well
the
new
kid
on
the
block-
and
this
is
something
we
actually
also
want
technical
input
on,
and
so
the
background
is
that
we
kid
is
only
a
sport,
does
only
support
byte
stream,
which
has
the
property
seaboard
bite,
sting
which
is
a
nice
construct,
but
it
has
only
one
one
byte
value
we'd
like
to
have
more.
B
We
think
we
need
more
key
identifiers
with
one
byte
values
and
seabor
ins
has
of
the
order
of
50,
and
this
was
the
original.
The
reason
for
set
for
the
byte
string,
identifier-
construction,
as
you
remember,
and
the
different
solutions
to
handle
this
is
that
we
either
extend
the
key
identifier
to
include
integer
just
with
it,
as
we
did
for
connection
identifier,
and
that
might
be
a
backward
compatibility
issue.
B
And
that's
basically
the
question
that
we
would
like
to
throw
out,
and
maybe
we
don't
have
to
discuss
time
to
discuss
this
now
any
quick
comments:
are
you
happy
with
the
kid
too,
or
should
we
try
try
any
one
of
any
of
the
other,
and
what
do
you
think
of
that?
Whatever
we
come
up
to,
we
will
bring
to
cozy,
of
course,
and
try
to
get
there
appraisal.
D
B
B
Okay,
so
please
provide
any
input
on
that
next
steps
very
quickly.
You
need
to
close
the
simplify
mac
that
we
can
do
resolve
the
kid
2
discussion,
I'll
wait
for
input,
we
submit
the
version
09
and
unless
there
is
any
any
substantial
changes
for
seeing,
that
would
be
the
next
implementation
version,
which
we
think
we
would
like
to
test
in
the
autumn.
B
A
No,
no,
that's!
Okay,
that's
that's!
I
mean
the
most
important
part,
anyways
yeah,
so
yeah.
So
there
was
a
small
discrepancy
because
marco
in
his
presentation,
stated
that
the
08
version
will
be
implemented
in
fall
for
the
interrupts.
So
I
guess
the
own
we're
look.
We
are.
We
will
be
waiting
for
09
to
implement
it
and
then
to
have
interrupt
tests.
So
I
guess
the
timeline
we
are
looking
at
because
we
are
right
now
in
the
summer
break,
so
we're
looking
at
september
october
timeline.
I
suppose,
for
the
interrupt
events.
A
Do
we
have
any
approximate
date
here
both
on
publishing
the
09
and
on
the
interrupt
date,
marco
iran.
B
I
think
we
hope
to
get
online
out
around
the
10th
of
august,
but
it
depends
on.
G
E
E
B
A
C
During
the
summer
period,
but
on
the
good
side,
I
think
many
things
introduced
in
version
8
already
can
be
done
already
now
in
in
parallel
and
maybe
should
be
done
to
not
have
too
much
to
do
in
in
too
little
time,
especially
the
news.
The
new
integer
by
string
identifiers
would
better
be
done
already
now,
as
an
update.
A
A
So
so
so
should
we
then
schedule
an
entry
meeting?
When
would
you
like
to
have
the
next
entering
meeting
then
for
should
this?
Should
we
have
one
maybe
in
end
of
september.
A
I
guess
the
best
would
be
to
catch
up
on
all
this
after
the
summer
break
and
then
this
side.
So
we
also
have
the
pending
point
about
formal
analysis,
because
I
would
like
to
issue
as
discussed
the
formal
call
to
the
to
the
crypto
community
and
formal
analysis
groups.
A
Academic
groups,
for
that
karthik
from
indriya
is,
is
a
good
contact
point.
So
I
will
take
as
an
action
point
to
reach
out
to
karthik
and
see
what
will
be
the
best
way
forward
to
trigger
that
activity
such
that
different
teams
are
kind
of
ready
for
for
for
the
draft
to
be
declared
stable
by
the
working
group.
And
then
we
previously
discussed
leaving
up
to
six
months
to
the
different
academic
teams
to
provide
feedback
to
the
group
before
we
ship
the
drive
to
the.
E
B
Even
had
a
comment
about
size
of
the
t
of
the
spec
and
and
yeah,
so
there
is
a
there's,
a
lot
of
test
vector
which
doesn't
have
to
be
in
the
text.
If
we
think
this
page
is
page
number
is,
is
an
issue
I
think
we
should
remove.
We
should
move
out
the
test
vectors
to
some
other
stable
reference.
I
don't
know
where
what
is
good
to
have
a
github
examples.
H
A
Oh
yes,
so
I
rickard
do
you
want
to
say
a
few
words
about
your
draft
literally
a
couple
of
sentences?
Yes,
yes,.
I
Let
me
say
very
quickly:
yeah
had
some
offline
discussions
and
we
said
it
may
be
worth
mentioning.
There
is
work
on
another
draft
about
that
is
called
key
update
for
all
score.
That
defines
limits
for
key
usage.
I
You
know
score
and
the
fact
that
you
have
to
rekey
after
these
limits
are
reached,
and
it
also
defines
a
way
to
re-kill
score
that
is
compatible
with
the
usage
of
the
add-on
exporter
if
the
original
context
was
created
by
running
ad
hoc,
so
he
said
that
it
may
be
worth
mentioning
this
draft
also
during
this
session
and
make
people
aware
of
its
existence,
because
it
relates
to
freaking,
oscar
and
also
yeah
usage
of
the
end
of
exporter,
and
I
can
put
a
link
in
the
chat.
Thank
you.
A
A
Yes,
so
we
are
already
two
minutes
past
the
hour.
I
really
apologize
for
being
late
with
this.
I
would
like
to
conclude
the
meeting
we
will
be
look.
We
will
be
scheduling
a
meeting
for
beginning
of
october
or
end
of
september
as
an
interim
meeting
of
the
work
of
the
working
group
and
with
that
I'll,
let
you
go.
Thank
you
so
much
for
attending
and
let's
keep
up
the
discussions
on
on
github.
G
H
Okay,
so
melissa,
if,
if
you
want
to
polish
the
minutes
and
send
them
that's
fine,
otherwise
I
can
do
it
but
it'll
be
tomorrow.
H
A
On
monday
for
monday,
I'm
on
pto,
but
I
will
try
to
get
them
done
by
tomorrow.
Otherwise,
they're
going
to
wait.
H
A
No,
no,
no
ways
it's
on
me.
Are
you
great
okay,
yeah
yeah,
so
yeah.
G
A
Seemed
really
good
the
minutes
so
so
that
was
marquez
was
taking
marco.