►
From YouTube: IETF109-LAKE-20201116-0500
Description
LAKE meeting session at IETF109
2020/11/16 0500
https://datatracker.ietf.org/meeting/109/proceedings/
A
B
I'm
just
seeing
if
I
could
pipe
youtube
out
back
through,
so
I
could
play
some
elevator
music.
A
B
A
So
militia
is
your
audio
up
and
running?
Can
you
hear
me,
can
you
confirm
that
you
can
hear
me?
I
can
hear
you
that
sounds
good.
Thank
you.
Okay,
perfect!
All
right,
we'll
give
it
the
traditional
extra
minute
or
two.
A
I
don't
know
that
we
have
two
hours
worth
of
discussion
this
morning
or
this
afternoon
or
this
evening,
wherever
you
are
so
we'll
start
at
two
going
on
for
three
past
the
hour.
B
A
A
Great,
so
we
have
the,
let
me
just
go
over
here,
so
you
can
see
the
working
group
character,
link
to
the
main
list,
jabber
room,
if
you're
in
jabber.
Otherwise,
then
in
mid
echo,
you
take
a
link
and
the
ether
pad
for
where
meeting
notes
can
be
collaboratively.
Taken
and
michael
has
michael
richardson
has
volunteered
to
take
notes
in
the
pad.
Michael.
Is
that
correct.
A
Excellent.
Thank
you
with
that.
All
right.
We
have
the
note.
Well,
it's
I
guess
the
first
time
this
week,
you'll
be
seeing
this
for
some
of
you
at
least
it's
a
reminder
that
atf
policies
apply
this.
This
slide
itself
is
not
those
policies,
you
should
go,
read
those,
but
by
participating.
You
agree
to
these
policies.
A
Here's
our
agenda
and
we're
at
point
zero,
we'll
be
talking,
john
we'll
be
talking
about
ad
hoc
and
the
issues
we
have
with
that
and
then
francesca
has
a
slot
afterwards,
and
then
we
have
one
aob
item
which
I
think
was
also
john.
Was
this
militia
sorry?
I
don't
recall
right
now
I'll
go
ahead.
Sorry,
so
we
have
one
arb
item
at
the
end,
which
is
to
discuss
relationship
with
kosei
and
so
on.
D
A
Yeah,
so
assuming
that
means
that
we
have
nothing
else
in
the
agenda,
I
did
have
one
piece
of
administrator
to
check
and
we'll
com
we'll
go
to
the
list
with
this
as
well.
I
just
wanted
to
note
that
there's
been
a
bunch
of
discussion
in
the
github
repo
issues,
which
is
a
fine
thing
and
something
that's
entirely
okay
for
a
working
group
to
do,
but
it
you
know
for
some
people,
it
suits
them
well
to
work
that
way
for
other
people
less
well.
A
So
I
just
wanted
to
check
if
anybody
has
a
problem
with
that
or
if
everybody's
okay
with
it
and
again
we'll
confirm
this
on
the
list
that
we
there's
a
kind
of
process
for
saying
that
discussion
in
on
github
issues
is
a
fine
thing
to
do.
It
does
mean,
of
course,
that
anything
substantive
gets
brought
to
the
mining
list,
but
if
that's
a
thing,
somebody
has
a
comment
on
or
wants
to
talk
about.
Now
is
a
good
time.
B
A
Sure
we
can
try
to
I've
seen
those
in
other
working
groups
and
I
find
them
useless
myself.
But
if
people
wanted
sure
we
can
do
that.
B
I
I
find
that
it's
useful
for
the
simple
reason
that
it
goes
in
the
archives.
It
links
back
to
the
issues
which
are
now
closed,
and
so,
when
you
go
back
to
the
archives
to
find
out
what
happened,
you
see
that
message
and
you're
like.
Oh,
the
discussion
was
over
there
and
that's
why
you
didn't
find
it
in
the
archive.
A
Fair
point:
okay,
so
we'll
take
an
action
for
one
of
the
chairs
to
tweak
that
button
and
github.
Somehow
and
again,
we
will
bring
this
up
on
the
list,
with
a
pointer
to
the
right
reference
for
in
the
the
guest
working
group
that
they
have
a
document
about
this,
so
we'll
bring
that
to
the
list
shortly.
E
Thank
you
by
by
the
way,
do
we
have
should
do
people
raise
hands
or
they
just
talk
or
when
they
want
to
say
something.
A
People
can
raise
their
hands
inside
of
meet
echo,
but
I
guess
if
you,
if
you
give
people
a
chance
and
say
you
know,
that's
a
good
time
to
ask
questions
as
you
go
through
the
new
slides.
That
would
be
fine
too.
E
The
changes
from
zero
zero
to
zero
one
was
removal
of
the
psk
method,
because
it
was
agreed
that
the
asymmetric
method
was
fast
enough
and
there
was
basically
no
difference
in
message.
Size
then
there's
removal
of
examples
with
certificate
by
value
and
some
editorial
changes
and
then
changes
from
zero
one
to
zero,
two,
which
was
submitted
two
weeks
ago,
also
not
so
many
changes.
E
E
There's
new
text
on,
and
also
that
was
requested
by
the
people.
Doing
formal
verification
then
add
the
text
on
key
confirmation
and
there's
a
now
as
a
recommendation
that
the
responder
had
have
received
explicit
key
confirmation
of
the
key
prk
4
3m
before
storing
the
long
key
material.
Long
term
can
still
send
messages,
but
should
probably
have
key
confirmation
before
storing
it
and
these
identities
and
give
confirmation
will
we
will
come
back
to
in
the
issues.
F
E
F
Yeah,
I
just
wanted
to
add
that
we'd
start
this
new
subsection
on
bitstring
identifiers.
There
was
still
some
some
confusion
around
that,
so
steven
risdysoff
has
provided
feedback
and
we're
trying
to
make
it
even
more
clear
what
what's
the
purpose
of
this,
and
maybe
you
should
say
a
few
words
about
that.
E
Okay,
yeah.
I
have
not
seen
that
discussion.
Yeah,
that's
good!
Just
point
out
that
bit
string
the
encoding
of
b
string
identifier
is
absolutely
needed.
It's
like
saves
four
bytes,
which
is
essential
to
get
it
to
fit
in
lorawan
and
five
hop
sixties.
E
So
the
the
rest
of
your
presentation
are
is
open
issues
and
most
of
them
are
quite
old,
but
there
was
now
with
the
latest
mails.
It
has
increased
the
discussion
on
github,
which
is
great.
It
has
also
spawned
some
new
issues,
so
my
plan
is
to
go
through
them
one
by
one
and
allow
all
the
discussion
we
need
to
have
on
them
and
if
we
don't
have
time
with
all
of
them,
I
would
suggest
that
we
have
an
interim
meeting
somewhere
after
this
meeting.
E
E
So
agreement
the
negotiation
of
parameters-
this
is
issue
11
and
23,
and
this
is
more
check
that
to
so
that
this
has
been
properly
discussed
and
agreed.
Otherwise,
this
is
not
part
of
some.
E
And
all
of
these
have
different
trade-offs.
Agreeing
beforehand,
of
course
reduces
flexibility.
We
of
course
make
sure
that
it's
a
very
easy
solution.
Negotiation
might
increase
message,
sizes
and
round
trips,
letting
the
parties
choose
things
inside.
The
protocols
may
allow
an
own
path
attacker
to
to
deduce
things
from
the
messen
site
and
block
things,
and
also
you
might
run
into
problem
where
something
is
not
supported,
and
the
discussion
on
github
so
far
is
a
comment
that
people
that
person
was
happy
with
the
current
configuration.
F
F
G
B
In
other
words,
you
better
put
them
in
your
document
that
uses
ad
hoc
as
as
to
what
you
intend
to
do
for
those
and
so
that
people
don't
forget
something
as
a
kind
of
a
proto
applicability
statement
block,
maybe
also,
as
we
add
things
or
subtract
things
or
to
change
our
mind,
then
at
least
we'll
know
what
what
we've
we're
supposed
to
say.
E
Yeah,
that
sounds
like
a
good
idea.
I
think
I
think
every
it
is
mentioned,
but
it's
probably
a
little
bit
spread
out
in
the
document.
So
having
easy
to
find
list
is
probably
a
very
good
idea.
E
D
Time
yeah,
that
sounds
like
a
good
plan.
Let's
start
with
an
action
point
that
essentially,
we
add
a
subsection
on
or
clarifying
what
these
negotiated
parameters
negotiated
than
the
great
parameters
from
before
so
add
this
in
the.
E
E
E
If
audi
is
currently
working
on
a
document
specifying
equations
to
calculate
aad
limits,
you
might
have
seen
the
document
or
the
previous
discussion
on
lake
when
this
was
brought
up
or
the
discussion
in
tls
or
quick,
and
basically
the
questions
that
you
put
limits
on
the
number
of
encryption
operations
and
the
number
of
four
jury
attempts
that
you
allow.
So
these
are
the
different
parties.
E
E
E
And
here
you
get,
you
can
have
higher
limits
if
you
have
smaller
messages
and
you
accept
a
lower
probability,
having
strictly
necessary
is
not
a
problem
at
all.
If
re-keying
is
easy,
if
requiring
is
not
easy,
it
might
cause
problems.
E
E
B
Good,
so
I
I
guess
I
can't
understand
this
is
not
specific
to
ccm8
it's
just.
We
use
it
a
lot,
there's
lots
of
other
algorithms
that
have
limits
where
you
must
re-key
it
going
back
to
3ds.
Does
that
so
I
don't
understand
and
everything
else
in
detail
in
tls
and
ipsec,
and
all
this
stuff,
we've
always
just
had
run
the
re,
the
keying,
the
keying
protocol
again
to
re-key.
B
It
we've
never
done
this
at
the
so-called
transport
layer,
so
I
don't
know
why
this
would
be
different
in
os
core
and
ad
hoc
there,
and-
and-
and
I
don't
know,
if
you're-
if
it's
really
specific
for
ccm
or
that's
just.
We
have
some
advice
right
now
about
that.
E
I
think
the
reason
why
you
might
start
want
to
want
want
to
do
things
on
the
record
layer
or
the
oscar
layer
is
that
if,
if
you
set
this
re-keying
a
period
so
short
that
it
starts
to
get
a
problem
to
rerun
the
handshake,
at
least
for
very
constrained
iot
devices-
and
I
think
basically
the
the
equations
here
are
not
specific
for
ccm8
it's.
I
think
they're,
quite
generic
for
any
algorithm
with
the
64
bit
tag
and
if
you
then
put
forgery
probability
as
what
is
it.
B
Bytes
that
wasn't,
I
I
understood
all
that,
but
that
didn't
tell
me
why
we
should
do
it
in
os
core,
rather
than
I
didn't
understand
why
I
mean
either
way
right.
It's
gonna
involve
the
same
crypto
operations.
Unless
I
don't
understand
so
I
don't
unders.
I
guess
I
don't
don't
know
what
would
be
the
advantage
of
doing
an
os
core.
E
Yeah,
no,
no,
it
might
not
at
all
involve
the
same
crypto
operation.
I
think
in
on
the
ad
hoc
level.
Everything
is
already
done.
You
can
just
if
you
want,
you
can
rerun
ad
hoc,
and
that
would
solve
the
problem.
What
you
can
do
on
the
record
layer
is
that
you
can
do
things
without
asymmetric
crypto.
So
one
option
is
that
you,
you
have
a
master
key
and
periodically
you
derive
like
you,
have
the
oscar
master
key
and
periodically.
You
derive
send
new
sender
key
from
that
key.
E
E
A
So
I
I
I'm
assuming
michael's
questions
finished
with
they've
not
jumped
back
in
michael,
so
I
had
a
just
a
comment
last
question:
is
it
documented
somewhere
in
a
way
that
would
be
friendly
for
a
developer
of
a
let's
say,
a
small
device
that
is
going
to
be
deployed
for
a
long
time?
Well,
I
I
don't
think
that
should
be
an
ad
hoc,
probably,
but
is
there
text
somewhere
that
such
a
developer
could
read
and
know
what
to
do.
E
Not
right
now
right
now
they
would
have
to
read
the
see
if
rga
aad
limits
documents
and
there's
no
reference
to
that
from
os
core,
but
that
would
presumably
be
the
outcome
of
the
core
discussions.
A
Okay,
so
as
a
suggestion,
I
think
it
would
be
good
if
somewhere,
there
was
a
developer
friendly
reference
here,
because
a
lot
of
people
won't
understand
all
these
details
and
will
either
never
change
keys
or
change
them
all
the
time.
So
if
somebody
was
happy
to
write
some
text
like
that,
that
would
be
great
and
I'm
sure,
if
a
home
for
it
could
be
found
somewhere.
E
A
H
Roughly
getting
back
to
michael's
point
in
terms
of
you
know,
is
this
something
specific
to
ccm8?
Is
this
something
specific
to
oscar
or
ad
hoc
and
like?
Yes,
this
is
a
fairly
generic
topic.
H
That
is
not
really
going
to
be
effective.
So
the
the
way
that
this
analysis
would
sort
of
take
form
would
presumably
be
to
say.
Well,
yes,
maybe
we
can
accept
the
lower
security.
Your
attack
success
probability
in
some
of
these
cases,
and
maybe
it
depends
on
how
strongly
we
care
about
the
particular
data
in
question,
but
I
think
that
probably
oscor
is
going
to
have
to
you
know.
H
Look
at
the
formulas
and
figure
out
what
is
actually
appropriate
for
the
iot
environments
in
order
to
save
that
we
could
use
this,
and
I
think
michael
was
sort
of
talking
and
typing
into
the
chat
about
how.
Yes,
we
shouldn't
be
rerunning,
ad
hoc
every
time,
and
I
agree:
that's
the
right
way
to
go.
I
think
john
had
also
mentioned
that.
B
Okay,
so
ben,
so,
if
I
understand
what
you're
telling
me
is
that,
because
the
limits
of
ccm8
are
quite
low,
that
tls
is
saying
we
will
solve
this
problem
by
just
not
using
that
algorithm
and
that's
simply
not
an
option
here
right.
Should
I
get
that
correct?
Okay?
B
So
that's
very
interesting
to
to
understand
so
so
I
don't
know
what
that
would
mean
if
I,
if
I
do
dtls,
to
set
up
an
os
core
oscore
context
and
then
there
was
no
way
to
well,
I
guess
you'd
have
to
run
the
re-key
algorithm
there.
So
all
I'm
really
saying,
though,
is
that
it
just
seems
it
seems
bizarre
to
me
to
put
a
re-key
whether
john
suggested
no,
we
can
do
master
keys
and
all
sorts
of
other
stuff.
B
B
Maybe
I
do
care,
but
but
it
just
seems
to
me
that
we
should
we
should
write
that
down
in
the
key
agreement
process,
not
in
the
other
part,
unless
there's
some
strong
reason
to
do
it
another
way,
I
don't
understand
why
that
would
be.
H
Okay,
I
mean,
I
think
it
comes
up
in
dts,
because
dtls
is
both
the
key
exchange
and
the
record
protection
algorithm,
and
I
guess
I
had
been
seeing
it
as
saying
if,
when
you're
using
the
record
protection
algorithm,
you
need
to
do
the
key
update
mechanism,
which
is
a
in
protocol
message
for
dtls
after
however
many
records
and
for
ad
hoc
and
oscar.
We
of
course
have
the
key
agreement
and
the
record
protection
in
separate
documents,
and
so
it
actually
becomes
more
important
to
think
about
which
one
it's
attached
to
in
the
documentation.
F
E
Good
any
more
comment
on
this,
or
should
we
move
to
the
next
issue.
E
Yeah
yeah,
that's
good!
Now
we
only
talked
about
the
second.
Where
to
do.
I
think
the
my
I
guess,
jonathan's
comment
here,
discuss
about
the
yeah
I
I
agree
that
lake
would
be
a
better
place
to
have
discussion
about
this,
the
crypto
and
security
parts
of
these
equations
and
what
they
mean-
and
this
is
not
only
oscar-
I
guess
ccm8-
is
used
in
most
constrained
iot,
so
it
would
be
good
to
have
a
more
general
discussion
about
that.
E
E
E
E
E
And
there
is
a
question
from
sean.
How
well
why
the
implement
the
kmac
is,
I
don't
really
know
shake
is,
I
feel,
is
having
quite
quite
some
implementation
and
growing.
E
E
E
F
E
A
F
D
I'm
having
some
little
issues
with
with
I'm
using
my
mic.
Sorry
about
that.
So
essentially
what
I
wanted
to
say.
I
want
to
judge
john,
that,
based
on
the
understanding
of
this
issue,
adding
kmac
would
mean
adding
another
element
in
the
cypher
suit,
with
which
we
would
be
increasing
the
complexity
right.
So
I
have
a
question.
I
have
a
question
whether
it's
possible
to
do
hkdf
with
shake
and
what
are
the
disadvantages
of
this.
E
E
The
plan
was
to
instead
of
having
hkdf,
expand,
to
use,
expand
and
extract
and
then
have
a
line
saying
that
if
you
have
short
2,
then
you
use
h,
hmac
hkdf,
and
if
you
have
shake,
then
you
use
kmac
and
give
give
formulas
like
the
ones
here.
How
you
do
that?
That
will
not
be
something.
People
need
to
need
to
implement.
D
D
So
we
have
stephen
and
timothy
in
the
queue.
E
E
Otherwise,
I
I
think
I
think
one
difference
is
that
hpk
was
very
far.
I
actually
commented
on
this
a
long
time
ago,
but
then
the
authors
did
not
do
anything.
Then
there
was
a
comment
now
when
they
are
very
late
in
the
process,
and
they
did
not
want
to
add
any
new
formulas,
but
they
said
it
was
general.
A
A
D
So
there
is
an
army
button
in
the
in
this
in
in
the
upper
left
corner.
J
That
you
should
hit.
Can
you
hear
me
now?
Yes,
okay,
sorry
yeah!
I
was
only
wondering
if
there
was
a
substantial
difference
between
a
shake
software
implementation
and
the
sha
software
implementation.
E
Later
comment
on
michael's
commentary
so
so
both
shot
two
and
shake
are
currently
possible
to
use
in
hedok
as
they
are
registered.
Cozy.
E
F
Just
understanding
christian's
comment
here
when
he
says
I
understood
it
already
be:
a
choice
of
charter
with
hkdf
shake
with
kmac
and
so
on,
so
that
I
mean
the
so.
The
the
difference
would
be
that
if
you
decide
to
implement
shake
then
or
if
the
cypher
suite
says
shake,
then
you
need
to
have
kmac
and
yeah
so
yeah
and
that's
well,
it's
a
good
question
is
that
is
that
too
complex
thing
to
have?
Is
it
obvious?
Is
it
better
that
we
stick
to
hkdf.
E
E
E
E
Okay,
good,
then
we,
I
guess
the
the
plan
is
to
move
ahead
with
this
then,
but
let's
discuss,
let's
keep
the
issue
open
on
the
github.
E
Let's
move
to
the
next
slide,
maybe
unless
there's
any
more
so
this
is
a
different
issue
under
the
future
proofing
ad
hoc.
E
E
Therefore
it
might
be
a
good
idea
to
specify
ad
hoc
in
terms
of
key
encapsulation
methods,
so
it's
prepared
to
be
used
with
future
chem
algorithms
for
divi
hellman.
I
think
this
would
be
a
purely
specification
change,
depending
yeah,
depending
a
bit
on
exactly
what
you
do
there
was
would
definitely
not
be
a
change
to
message.
Size
cfrdhpe
is
the
has
done
a
great
job
of
defining
exact
interfaces
for
both
un
authenticated
and
unauthenticated
chem.
E
E
E
And
reading
up
about
this
after
the
issue
was
created,
it
seems
very
likely
that
future
camps
will
adhere
to
the
general
keeper
and
captain
d
cab,
but
maybe
not
as
clear
that
they
would
adhere
to
the
cfrt
hpk
authm
cap.
E
Auth
dcap
interfaces
seems
to
be
an
open
research
question
at
this
time,
but
I'm
not
sure
a
problem
is
that,
while
the
ephemeral
key
is
only
used
one
time
in
this
auth
end
cap
inside
what
end
cap
function,
it
basically
needs
to
be
done
used
twice
for
encapsulation,
which
does
not
necessarily
work
with
all
the
pqc
algoriths
comments
on
github
was
generally
positive,
but
I
think
if
we
are
sure
that
if
this
will
lead
to
that,
we
can
just
plug
in
pqc
algorithms,
and
I
think
this
is
a
good
thing
to
do.
E
E
F
F
So
so,
just
just
one
comment
that
we
in
the
requirements
document
for
lake.
We
actually
said
that
public
that
post
quantum
is
out
of
scope,
so
it
doesn't
mean
that
we
don't
have
to
take
take
it
into
account
in
this
way.
But
we
are
not
obliged
to
to
support
that
in.
In
this
version
of
the
of
the
document.
E
E
A
So,
just
a
clarification
question
ignoring
post
quantum.
Is
the
proposal
to
make
ad
hoc
apis
look
more
like
hpke?
Yes,
okay!
I
I
think
that
sounds
like
a
quite
a
good
idea,
because
it
seems
that
people
seem
to
like
the
the
interface
in
hpk.
So.
A
E
Would
you
then
suggest
just
using
the
same
api
or
using
the
seder
code
also
that
hpka
are
providing
for
authencap
and
old
decap?
I
think
that
would
be
very
possible
to
do,
but
it
would
definitely
change
the
test.
Vectors.
A
I
I
guess
I'm
neutral
so,
but
I
I
the
more
like
these
things
are.
I
guess
that
would
that
would
help
people
implementing
to
some
extent,
but
again,
I'm
neutral.
So.
E
F
C
Can
you
hear
me
now
yeah,
yes
yeah,
so
so
I
I
mean
ip
second
secret
cell
and
so
on.
We
had
this
issue
with
aid
algorithms,
because
early
early
days
we
have
a
separate,
you
know,
authentication
and
separate
encryption
algorithm.
I
did
cause
some
problems
later
when
we
every
now
everything
is
aad
algorithms,
for
example.
Last
ever
sorry,
secret
cell,
there
was
lots
of
issues
because
the
interfaces
don't
really
support
the
aad
algorithms
that
are
used
now.
Don't
really
support
the
way
that
the
security
is
doing
things.
C
C
E
C
It
would
have
been
easier
if
you
had
adopted
that
in
earlier
in
about
yeah
good,
because
we
didn't
do
that.
We
ended
up
problems,
but
we
then
started
you
know
start
to
form
things
in
this
way,
and
then
we
realized
that
oh,
we
are
doing
some
things
that
we
can't
actually
do
there
with
that
framework
and,
for
example,
the
secure
cell
was
having
did
that
they
actually
encrypted
the
length,
which
means
that
before
they
can
actually
record
the
pocket,
they
have
to.
C
You
know
decrypt
the
first
first
block
before
they
can
actually
verify
the
hash
and
aad
algorithms
doesn't
allow
that
to
be
done
very
easily
and
that
kind
of
we
ended
up
in
some
issues.
There.
E
Good
christian
had
a
a
question
here
on
the
chat,
how
this
would
affect
cozy
apis
with
this
use,
then
hpk
apis
rather
than
encodes
the
apis.
That's
that's
a
good
question
which
I
don't
have
an
answer
to
right
now.
I.
E
D
E
E
E
E
But
if
a
raw
public
key
in
ad
hoc
can
be
identified
by
a
kid,
as
said,
the
certificate
should
as
well.
There
is
no
real
differences,
so
the
suggestion
is
to
specify
how
that
certificates
can
be
identified
with
a
kid
which
would
lead
to
certificates.
E
By
reference
could
be
as
small
as
rpk,
making
them
15
51
by
laura
bond
and
five
hope
sixties.
The
the
other
thing
with
cosy
certificates
would
have
to
wait
until
and
if.
B
B
But
of
course
all
the
clients
need
to
know
which
byte
to
send,
because
it's
arbitrary,
because
you
need
to
pack
them
there,
at
which
point
I
think,
you've
done
so
much
work
that
you
would
have
no
use
for
using
certificates.
Anyway,
you
have
such
a
small
number
of
devices
and
you've
touched
them
all
to
tell
them
what
key
id
to
use
that
there's
not
really
a
lot
of
point
in
trying
to
do
this
with
certificate
as
well.
B
So
I
just
don't
think
it's
a
realistic
kind
of
thing
to
say
there
and
I'm
sure
you
know
the
off
the
ace
off
of
common
you're
on
how's.
It
pronounced
again
that
the
document
that
we've
been
working
on,
which
does
reference
certificates
out
of
band,
so
I
I
don't
think
this
is
a
terribly
useful,
optimization
in
practice.
F
So,
michael,
that's
the
ace
ache
authorization
you
were
referring
to
and
I
think
I
think
that
it
actually
can
be
useful
in
in
the
sense
that
you
are
not
actually
transporting
the
certificates.
So
it
still
still
means
that
you
need
to
understand
what
this
byte
or
a
few
bytes
mean.
But
not
all
devices
will
will
need
to
have
an
encoding
for
all
certificates,
so
it
could
still
make
sense
to
have
just
a
few
bytes
identifiers
instead
of
well
14
or
whatever.
H
H
Because,
as
you
said,
not
all
devices
will
need
to
know
about
all
of
the
certificates
and
by
the
point
that
you
are
already
giving
a
customized
configuration
to
each
device,
it
seems
like
the
the
benefit
from
using
a
certificate
as
compared
to.
If
I
understand
correctly,
just
a
raw
public
key
is
very
minimal
because
you
still
have
to
manually
give
custom
configuration
to
each
device
and
the
general
point
for
using
certificates
is
that
you
don't
have
to
give
custom
configuration.
You
can
have
the
pki
sort
of
relay
the
necessary
information
down.
E
Would
there
be
a
benefit
if
devices
does
not
need
to
support
raw
public
key
raw
public
key
and
the
self
science
setting
is
basically
the
same?
So
if
you
want
to
use
you
might,
maybe
some
implementation
want
to
support
pki
certificates
and
self-signed
certificates
and
would
not
have
to
support
a
special
specific
encoding
for
raw
public
keys.
B
So
so,
on
the
device
and
on
the
sender
side,
the
device
has
to
have
access
to
its
private
key
to
sign
things,
and
it
really
has
really
has
doesn't
have
any
clue
or
care
how
the,
whether
it's
actually
using
a
raw
public
key
or
a
self-signed
certificate
or
certificate
device,
just
signs
with
its
private
key
right.
So
there's
not
actually
any
code,
except
for
whether
I
initialize
the
nx5t
with
some
blob
or
a
kid
with
some
other
blob
in
either
case
that
blob
is
doesn't
have
to
be
interpreted
or
created.
B
It
doesn't
have
to
speak
asn
1
to
do
that.
It's
the
other
end,
it's
the
responder
that
has
to
do
that
and
if
that
other
guy
has
got
internet,
and
it's
not
constrained
that
it's
less
of
an
issue.
So
so
I
don't
see
a
difference
between
the
two
of
them
for
the
the
constrained
side
of
the
set
of
the
in
that
device.
It's
again
like
how
do
I
put
the
right
thing
in
it?
B
If
I've
provisioned
a
certificate
into
the
device,
somehow
at
the
factory,
then
yeah
the
device
could
actually,
you
know,
figure
out
what
to
put
into
the
x5
t
on
its
own,
perhaps
compressing
it
etc.
So
maybe
it
does
need
some
code,
but
again
that
can
be
actually
calculated
ahead
of
time
and
put
in
the
right
place.
B
F
Michael
going
in
the
other
direction,
when
the
device
is
going
to
authenticate
to
a
non-constrained
network
node,
it
would
be
a
good
thing
if
it
doesn't
have
to
send.
I
mean
it
actually
doesn't
have
to
send
anything
right.
It
could
basically
just
point
to
repo
that
would
be-
and
I
mean
provide
an
identifier
and
point
to
a
repo.
B
F
F
B
B
Right,
no,
no,
and
I
think
that
the
representation
we
got
was
better
and
and
had
better
privacy
implications
too.
Although
the
fact
that
you
have
to
point
to
the
repo
probably
costs
you
around
14
bytes
anyway,
I
mean
it
could
be
seven
or
something.
If
you
really
push
it.
F
Right
right,
but
then
you
don't
need
the
additional
hash
of
the
of
the
certificate
so
so
having.
B
Sure
it
depends
on
how
you
construct
the
key
identifier
right,
because
it's
got
to
be.
You
have
the
pointer
to
the
repo
and
you
have
the
key
identifier.
Then
you
either
have
to
someone
has
to
decide
what
that
what
that
value
is,
and
that's,
okay.
But
but
my
point
is
that
it's
not
going
to
be
one
bite.
I
think
that
was
the
point
I
was
trying
to
get
at.
B
B
Again,
yes,
I
agree,
provided
that
you
walk
up
to
every
device
before
you
turn
it
on
plug
in
a
cable
or
something
and
tell
it
which
three
byte
key
id
identifier
to
use
right.
I
some
way
you've
got
to
tell
it
that
thing
right,
at
which
point
you
could
just
as
well
pull
the
certificate
out
and
have
it
use
a
raw
public
key
and
put
that
in
your
database,
because
you've
got
to
have
a
database
to
identify
to
map
the
two
things
together
right.
So
all
I'm
saying.
B
B
F
B
This
point
of
view
more
scalable
to
do
that,
and
so,
if
you
can,
I
I
it's
probably
more
scalable
but
but
most
of
the
advantages
of
the
the
certificate
which
is
like
that
you
could
change
the
public
key
or
something
like
that
or
you
can
resign
it
or
you
can.
You
can
put
a
crl
out
saying
that
the
thing
is
died
right.
B
F
F
E
E
Is
there
anybody
that
wants
to
discuss
any
particular
of
the
remaining
issues?
Then
we
could
prioritize
that
issue.
F
Remaining,
I
think
verification
of
intended
peer
is
good
and
we
should
probably
get
into
the
cipher
suite
sha
512
and
the
forward
backwards
secrecy.
So
the
last
three
ones
is,
I
think
we
should
discuss
and
and
verification
of
intent
appear.
That's
and
perhaps
the
key
confirmation
delivery
of
receipt.
E
F
E
E
E
E
I
identity
is
in
the
sigma
protocol,
which
this
is
very
tied
to
pki
and
a
person
which
might
or
might
not
be
applicable,
applicable
directly
to
iot
setting
where
you
have
devices
and
not
persons,
and
also
it's
not
clear
that
these
devices
or
services
inside
devices
have
identities
in
the
same
way
as
humans
have
names.
E
E
E
So
the
questions
here
is
first,
is,
I
think
the
feedback
has
been
that
this
is
from
the
formal
verification
is
that
this
is
a
very
good
idea.
The
question
is:
will
there
always
be
a
subject
name
available,
for
example
the
ui
64?
E
Should
we
recommend
to
use
the
subject
name
with
the
raw
public
key
to
even
mandate
using
a
subject
name?
But
that
depends
if
the
subject
name
is
always
available
advice.
I
think,
should
not
mandate
that
the
document
would.
Authors
would
also
want
more
feedback
on
from
people
operationally
doing
constrainability
how
they
see
identities.
E
B
E
C
So
this
direction,
can
you
hear
me
yeah
all
right,
so
I
think
the
15-4
doesn't
have
any
plans
of
doing
any
kind
of
you
know.
Privacy
addresses
yet
so
so
the
l2
addresses
are
going
to
be
same
in
most
of
the
environments.
What
they
are
doing
for
there
is
actually
it
doesn't
matter
for
some
cases
they
actually
they
already
do,
have
the
16-bit.
C
You
know
this
local
address
or
short
addresses
which
they
can
use
for,
for
example,
if
you
have
a
already
formed
network,
for
example,
a
personal
area
network
that
could
use
the
you
know
short
addresses,
but
it
doesn't
help
that
if
somebody
is
there,
when
you
actually
register
or
join
the
network,
then
they
can
see.
The
l2
address
is
the
full
64-bit
addresses
and
I
have
no
idea.
I
have
no
knowledge
that
anybody
would
be
actually
thinking
about
doing
any
work
on
that
chasing.
C
E
Identity
from
there
was
previously
a
lot
of
comments
about
identities
in
ad
hoc
from
several
tls
people.
The
authors
would
like
to
have
subject
name
in
law.
Public
is
at
least
optional.
Otherwise
you
don't
protect
against
these
attacks.
That
sigma
try
to
protect
against
then,
if
whether
they
are
realistic
in
iot
scenario
or
not,
can
be
discussed.
E
So
next
is
resumption
and
that's
also
a
synergy
check.
So
previously
the
protocol
had
resumption.
Then
it
was
decided
to
remove
the
psk
method,
which
also
removed
the
resumption.
But
I
my
understanding
is
that
there
was
no
real
discussion,
whether
to
remove
resumption
or
not.
They
just
followed
from
removing
the
psk.
E
So
this
issue
brings
this
up
just
to
take
a
decision
that
we
don't
need
resumption
or
that
we
need
resumption.
So
is
there
any
need
for
resumption
resumption
allows
you
to
minimize
state.
If
you
don't
know,
if
you
will
ever
see
the
other
party
again,
you
also
get
forward
secrecy
and
and
freshness,
but
these
you
can
probably
get
in
a
cheaper
way
and
iot
connections
are
long-lived
so
typically
having
a
resumption
mechanism
probably
and
doing
a
new
handshake,
probably
cost
more
than
not
doing
this.
I
I
Then
I
don't
see
like
I
I
I
don't
have
strong
opinion.
It's
a
little
bit
sad
if
you're
going
to
lose
resumption,
but
I
think
this
is
natural
consequence
of
then
not
supporting
psk
mode.
E
I
Like
I
don't
know
where
and
like
where
all
edoc
will
be
used,
hopefully
in
many
places,
and
if
later
we
find
out
that
there
is
some
people
who
do
more
frequent
handshakes
and
don't
want
to
do
the
full
full
handshake
every
time,
but
maybe
in
in
this
case
the
full
handshake
is
not
such
a
big
performance
degradation
that
performing
a
full
handshake.
Every
time
is
not
such
a
big
issue
so
yeah,
I
yeah.
I
I
I
think
it's
it's
fine
to
get
rid
of
it
in
most
situations,
and
if
someone
comes
up
later,
then
we
will
see
it,
but
I
can't
think
of
some
specific
use
case
where
we
would
need
frequent.
K
I
resumption
we
should.
We
should
consider
what
is
coming
out
of
the
australian
session
of
discussions
about
how
we,
how
we
re-key
and
whether
we
can
re-key
inside
our
score.
If
that
is
turning
out
that,
if
it's,
if
the
decision
there
is
that
we
can
re-key
easily
on
the
quote
a
record
layer,
then
we
don't
they.
Then
we
don't
get
a
requirement
for
assumption
there.
But
if
oscar
says
that
yep,
please
hire
layer,
pl
do
something
for
us,
then
resumption
should
still
be
an
option.
E
D
Go
for
until
45
past
okay,
then
we
can
the
slides
of
francesca
and
euron
and
move
on
all
the
other.
On
the
all
the
pending
issues
to
the
inter
meeting
yep,
okay.
F
I
think
you
could
go
even
to
ten
two
francesca
asked
for
one
minute
and-
and
I
I
can-
I
can
easily
do
with
five
minutes.
E
Good,
so
next
issue
is
distinguish
error
message,
and
this
was
raised
by
a
implementer.
I
maybe
your
unreme.
I
don't
remember
exactly
who,
but
the
question
was:
how
do
you
distinguish
that
you
get
the
error
message
and
not
a
message,
two
or
three
or
maybe
even
a
new
message?
One,
and
this
is
not
really
discussed
in
the
draft.
E
E
E
F
E
E
J
D
I
meant
I
meant
the
letter
the
letter
so
essentially.
J
D
E
There
is
therefore
no
need
to
have
in
cca
encryption,
I.e,
encryption
with
integrity
of
this
identity,
it's
enough
to
only
have
encryption
in
cpa,
encryption
encryption
without
integrity.
In
this
case,
and
just
as
a
note,
everything
in
the
message
is
integrity
protected
by
the
inner
mac,
which
is
also
an
aad
without
it's
an
a80
without
plain
text,.
E
So
that
was
the
reason
that
I
think,
ad
hoc,
two
or
three
versions
ago,
removed
the
integrity
tag
in
message
2
on
the
outer
encryption,
because
it
had
no
purpose
and
the
specific
ad
hoc
specification
today.
The
solution
is
that
it
generates
a
long
encryption
key
and
then
form
a
sore
cipher.
E
It
source
the
long
key
with
the
plain
text-
and
this
has
the
benefit
that
it
is
independent
of
the
encryption
algorithm,
but
it
led
to
comments
both
from
the
people
doing
formal
verification
which
has:
why
are
you
using
source
cipher,
and
they
also
said
that
they
got
comments
from
the
reviewers
of
their
paper
saying.
Why
is
this
using
source
iphone
which
brings
to
this
issue?
So
how
should
we
do
this
encryption
without
integrity,
so
option?
One
is
to
do
like
today.
E
I
think
this
works
for
the
current
cosal
grids,
but
it
in
general
it
does
not
work
for
an
aad
that
does
not
have
a
well-defined
tag.
There
are
some
such
algorithms,
but
none
of
them
defined
for
cosi
third
option
would
to
basically
make
a
table
where,
for
each
coca,
the
algorithm
you
assigned
encryption
algorithm
without
integrity,
so
for
ccm
and
gcm
you
would
use
asc's
tr
and
for
cha
cha
poly
1305,
you
use
cha-cha,
and
these
have
then
the
disadvantage
that
you
need
to
specify
something
for,
if
course,
is
specified
a
new
ada.
E
Algorithm
and
my
feeling
is
that
to
fit
in
laura
1
and
60s
we
need
to,
we
cannot
introduce
the
integrity
tag
again.
It
fills
new
purpose
and
these
are
the
three
different
solutions
that
I
could
come
up
with.
They
all
have
the
benefits
and
disadvantages.
E
E
E
B
E
E
D
Okay,
so
I
propose
that
we
continue
discussing
this
on
the
on
the
github
page
and
we
stop
here
because
it's
already
nine
till.
E
D
Yes,
so
I
invite
everyone
to
to
comment
on
the
github
issues
with
the
comments
you
might
have
in
chat,
and
with
that
I
would
we
should
move
on
to
the
next
agenda
item,
which
is
the
interrupt
planning
so
front
stephen.
Can
you
present
the
slides.
D
D
G
G
G
Keys
and
using
the
x5t
hash
value
to
identify
the
certificate
and
then
method
three
which
is
adopt
authenticated
with
static,
difficult
keys
and
raw
public
keys
encoded
as
kosike
with
a
key
id
used
to
identify
the
credential,
and
we
also
have
a
way
more
extensive
set
of
test
vectors
on
github.
At
this
link
and
yeah.
Implementers
should
be
aware
that
these
exist
and
that
you
can
check
them
out
and
the
one
in
the
document
in
appendix
b
of
the
draft
are
actually
should
give
you
more
guidance
about
how
things
are
built
and
and
constructed.
G
G
We
are
starting
to
think
about
interop,
so
we've
talked
about.
G
We
have
contacted
several
people
that
showed
interest
and
that
showed
that
they
had
maybe
some
implementation
available
and
we
are
looking
for
more
people
to
participate.
So
if
you
are
planning
to
implement
or
you
have
an
implementation
and
you're
interested,
please
let
us
know
right
in
the
mailing
list-
contact
us
and
hopefully
we
can
have
something
going
for
december,
depending
on
availability
of
implementers
as
well,
and
we
are
also
starting
to
think
about
the
the
test
suite
which
will
be
based
on
the
test
vectors,
so
yeah.
G
D
Okay,
thanks
francesca,
so
we
should
follow
up
on
this
on
the
mail,
english.
Definitely,
this
is
an
interesting
topic,
but
since
we
are
very
close
to
the
end
of
the
meeting,
I
propose
we
move
on
with
the
slides
that
euron
had
prepared
on
related
work.
Stephen,
could
you
present
that.
E
F
Yep,
can
you
hear
me?
Yes,
yes,
okay,
so
yeah,
this
is
just
just
information.
Lake
meeting
is
almost
over,
but
there
are
more
topics
related
to
lake
at
this
meeting,
so
the
cozy
meeting
falling
right
after
the
break
will
speak
about
seaborne
coding
of
x519
certificates
and
identification.
As
we
mentioned,
we
discussed
this
previously.
F
It's
not
decided
whether
it's
relevant
or
not,
but
if
you're
interested
that's,
that's
the
that's
the
slot
for
for
that
topic.
On
tuesday
there
is
a
slot
descri
in
the
core
working
group.
F
F
The
two
drafts
are
related
to
how
to
use
ad
hoc
for
authorization
to
add
authorization
to
ad
hoc
and
also
to
add
certificate
enrollment,
and
there
is
a
charter
discussion
where
one
of
the
topics
for
potential
new
work
items
is
around
authorized
access
to
raw
public
keys
using
the
authorization
framework,
so
that
would
be
a
way
of
of
kickstarting
ad
hoc
next
slide.
Please.
F
F
F
So
this
is
with
this.
This
is
what
I
think
a
little
bit.
What
michael
was
mentioning
referring
to.
We
have
the
authentication
in
blue
here,
that's
the
ad
hoc
messages123.
F
There
are
the
black
messages,
which
is
the
oscar
request
response
and
they
contain
the
est
payloads,
which
are
in
this
case
it's
a
significant.
This
is
a
simple
enrollment
method,
so
it's
the
sen
and
it's
the
request
is
a
cbor
encoded
certificate,
signing
request
and
you
get
back
a
c
board
certificate
or
a
reference
there
too,
as
described
in
this
green
green
reference
and
the
combination
of
oscore
and
ad
hoc
is
that's
the
yellow
box
and
the
third-party
optional
third-party
assisted
authorization
is
the
red
red
blob.
F
D
Okay,
thank
you
so,
just
before
wrapping
up,
we
are
on
top
of
the
hour,
but
I
would
just
like
to
discuss
the
next
steps
and
since
we
did
not
cover
all
the
issues
in
the
today's
meeting,
I
propose
that
we
have
an
interim
meeting
so
now.
The
question
is
whether
we
would
like
to
have
the
meeting
before
or
after
the
holidays.
D
So
joran
would
like
committing
before
the
holidays.
Marco
agreed
to
that.
D
Michael
agrees
with
that
as
well,
so
it
seems
we
okay
and
john
okay,
so
it
seems
we
have
consensus
that
we
should
have
an
interim
meeting
before
the
holidays
after
the
u.s.
Thank
giving
as
michael
proposes
so
essentially
beginning
mid-december,
from
what
I
can
gather.
So,
let's
make
it.
Let's
make
an
action
point
for
chairs
to
to
schedule
this
meeting
soonish,
and
with
that
I
would
like
to
thank
you
for
attending
the
today's
meeting.
D
So,
thank
you.
Everyone
thank
you
for
attending,
see
you
on
the
for
the
rest
of
the
week
and
talk
to
you
on
the
mailing
list
and
github
pages.