►
From YouTube: IETF-LAKE-20230207-1700
Description
LAKE meeting session at IETF
2023/02/07 1700
https://datatracker.ietf.org/meeting//proceedings/
A
B
B
The
agenda
for
today
is
quite
straightforward.
We
will
be
going
giving
an
update
on
the
status
of
the
ad
hoc
draft
year.
Engine
drone
will
be
will
be
doing
this,
and
then
we
will
be
proceeding
with
the
Uncharted
items
for
the
discussion
on
retartering,
essentially
what
to
include
in
a
potential
recharger
of
the
of
the
working
group.
B
A
B
D
D
One
version:
18
was
posted
immediately
after
the
last
ITF
meeting
and
we
we
had
some
issues
where
we
which
we
resolved
during
the
meeting.
So
we
were
happy
to
make
and
make
an
update
and
I'll
say
a
few
words
on
that
in
the
next
slide,
and
then
we
have
the
sorry
please
go
back,
then
we
have
version
19.
D
as
well,
and
that's
been
now
going
through
we'll
take
it
in
the
comments
from
secretary
inter
tsvr
genart
and
the
Shepherds
review
by
militia
and
Stevens
well,
the
chairs
both
chairs,
did
went
through
through
the
draft
before
we
we
published
this
version
70.
so
90..
Sorry,
next
slide,
please
Okay!
So
so
this
was
already
in
in
November
version
18..
D
D
So
so
that's,
for
example,
for
padding.
You
may
have
multiple
ad
items
of
with
label
zero,
and
the
number
of
clarifications
from
the
working
group
plus
call
identify
a
representation,
as
usual
always
needs
to
add
some,
some
more
some
more
details
for
clarifying
that
authentication
credential,
you
should
say
rpk
or
public
key,
not
not
the
Ripple.
D
The
y
coordinate
of
the
ephemeral,
key
and
validation
of
FML
relation
of
public
is
so
those
were
clarifications.
Then
there
were
some
some
more
details
about
processing
how
to
handle
processing
after
the
protocol
is
completed
and
that
all
verification
should
be
made
available
to
the
application
to
form
the
decision.
D
The
relationship
between
adult
and
Oscar
identifiers
David
provided
to
us
with
this
table
to
the
right
bottom
right
here,
which
was
I,
think
it
was
very
simple
explanation
of
how
to
get
the
right.
The
relationship
between
connection
identifiers
and
and
the
other
identifiers
and
some
terminology
alignment.
What
do
we
mean
by
session
so
now
we're
using
that?
Consequently,
we
use
the
term
discontinu
instead
of
terminate
and
so
on,
updated
cddl,
some
additional
Unicode
encodings
in
the
document
and
the
large
number
of
needs,
so
that
was
version
18.
D
So
19
is
the
recently
updated
version
and
which
also
did
not
impact
the
which
which
did
not
impact
the
wire
format,
and
this
was
the
one
following
all
the
directorate
reviews,
some
some
clarifications
here:
a
relationship
to
Sigma.
That
was
actually
a
comment
by
Lloyd,
which
we
had
some
discussion
before
Christmas
the
role
of
static
TV.
E
D
Was
it
was
from
the
secretary
review,
the
roles,
the
limit,
theater
and
responder
was
one
of
the
directory
to
use
as
well
and
how
to
construct
Suites
I.
We
got
an
excellent
proposal
by
Donald
Eastlake
on
how
to
make
that
very
neat
and
compact
description
of
how
to
construct
suite's
eye,
which
we
took
verbatim
essentially
and
some
more
clarification
of
the
sweet,
the
negotiation
method,
processing,
padding,
EAD
processing,
how
to
hand
along
plain
text
so
so
additional
clarifications.
D
If
we
have
an
updated
Ayana,
section,
I'll
come
back
to
written
next
in
a
following
slide,
and
so
you
could
stay
on
this
slide
for
a
while.
Please
come
back,
yeah
I'm
still
ready.
So
there
was
also
something
about
clarifying
the
normative
text
in
appendix
a
because
there's
a
there's,
a
relationship
between
a
core
draft,
and
that
was
the
question.
How
does
this
normative
text
relate
to
that
draft?
D
And
finally,
some
updates
on
on
security
analysis,
and
there
is
a
new
appendix
on
state
machine
and
some
updated
references
now
next
slide,
please
so
yeah.
So
these
are
just
illustrations
of
what
I
said
before
there
is
now
an
example
of
a
state
machine
and
three
three
implementers
have
been
reviewing
this
and
are
happy
with
this
lesson
as
an
example
and
someone
to
change
their
implementation
when
they
found
this.
D
And
this
is
a
little
bit
about
the
terminology
in
appendix
A2,
where
we
say
the
use
of
co-openos
score
with
network
is
optional,
but
if
you're
using
Co-op
North
Korea,
then
there
are
certain
normative
requirements,
and
then
we
have
made
that
more
clear
in
that
appendix
and
we're
also
given
names
to
these
message
flows.
It's
called
now
the
message,
the
forward
and
the
reverse
message:
column,
foreign.
D
And
then,
finally,
there
are
some
Ayana
considerations.
We
got
some
comments
on
that
in
the
directorate
reviews,
so
we
tried
to
address
them
already
now,
instead
of
later
in
dialogue
with
with
Ayanna,
by
being
detailed
on
what
kind
of
registration
procedures
the
different
ranges
of
the
different
values
so
for
for
methods,
error,
codes,
EAD
and
Cypher
Suite,
essentially,
the
the
table
on
the
left
applies
and
23
is
reserved
in
all
registers
and
for
the
exporter
label
the
the
tables
on
the
right
apply
so
yeah.
D
There
is
there's
some
registration
of
labels
and
then
there
are
some
unassigned,
some
private
use
and
the
registration
procedure
I'm
happy.
If
someone
who
understands
this
better
than
I
do
can
have
comment
here,
but
we
had.
There
is
some
thought
at
least
around
what
should
be
easy
to
change
and
what
should
require
standard
section
and
what
you
require
specification.
D
F
F
D
D
But
it's
basically
you
don't
you.
You
proceed
according
to
the
messages
you
have
received
received
and
then,
if,
if
you
receive
something
which
is
not
in
line
with
that,
then
you
just
it's
an
error
and
you
so
the
first
thing
the
first
package
should
win.
I.
Think
yeah
I
mean
I,
don't
see
any
reason.
Why
not.
G
Yeah,
whichever
package
wins
will
be
the
first
to
be
processed
and
the
the
section
will
be
ignored.
What
could
Fork
is
if
you,
if
the
message
one
is
delivered,
duplicated
and
delivered
several
times,
then
that
would
be
a
fork.
That
would
be
then
be
two
two
instantiations
of
this
they
machine.
Maybe
it
would
be.
It
would
be
an
error
of
the
message
too.
The
second
time
there
also.
F
F
G
Every
doable
yeah
we
do
so
yeah,
so
an
attacker
can
can
mix
with
the
message
and
then
you
would
have
wasted
some
some
some
processing
and
messages.
So
it
would
be,
but
it's
it
wouldn't
it
wouldn't
be
a
long-term
denial
of
service.
You
would.
What
you
would
have
missed
is
a
couple
of
messages
so
like
the
two
or
two
messages,
and
maybe
one
receipt
instead
of
just
one
message
received,
but
then
you
would
have
to
restart
I
think
that's
the.
G
A
B
B
A
H
Okay,
so
basically,
the
motivation
of
this
discussion
is
coming
from.
We
were
defining
a
neat
method
called
ad
hoc,
which
uses
actually
at
Hargis
Authentication
Protocol
in
it
and
at
the
beginning.
We
didn't
think
about
this,
but
we
consider,
after
some
discussion,
adding
some
kind
of
resumption
capabilities.
Indeed,
method,
which
means
basically
trying
to
reduce
the
message.
H
So
after,
if
you
have
checked
the
mailing
list,
we
consider
like
four
options.
One
of
them
obviously
is
to
rerun.
Everything
at
all
is
lightweight
enough,
but
we
already
have
that
and
then
another
four
options
was
the
number
two
which
is
basically
used
psk
but
including
also
a
difficult
one
Exchange.
That
is
something
that
is
happening
TLS
and
also
to
re-key
the
ike
version,
2
security
associations
and
the
option.
H
Three
is
just
use
psk,
but
with
no
DV
Helm
package
change,
the
exchange
is
random
numbers
and
from
that
we
can
derive
new
key
material.
That
is
something
we
can
find
in
TLS
as
well
and
possibly
is
a
potential
part
of
in
the
in
the
ip6
sreek
riggy
and
the
number
four.
Actually
we
it's
another
option,
but
we
discarded
this
because
there
is
no
Randomness
at
all.
H
G
It's
a
little
bit
discussion
on
the
options
that
was
discussed
on
the
list
so
about
two
and
three
eliminates
all
the
external
things
you
have
everything
in
in
your
in
the
end
node.
Basically,
you
you
need
the
psk
and
that
you
have
stored
and
you
need
the
messages
you
receive.
Looking
at
asymmetric
operations
at
the
hook,
all
the
four
modes
take
three
asymmetric
operations.
Option
number
two
discussed
here:
take
one
asymmetric
operation
and
number
three
takes
zero
asymmetric
operations,
two
provides
better
security
against
the
key
compromised
and
so
on.
G
G
G
Re-Keying
could
be
specified
in
ad
host,
similar
to
TLS
resumption.
As
a
new
ad
hoc
method,
then
you
could
use
it
also
not
only
for
re-keying
and
resumption,
but
also
with
external
PS
case
that
you
have
got
done
somewhere
else.
If
that,
as
a
question
to
the
group,
whether
that
would
be
useful
next
slide,.
G
So
conclusion
is
it's:
probably
it's
definitely
worth
discussing
whether
there
should
be
some
in
done
in
Lake.
I.
Think,
there's
a
lot
of
things
at
least
some
of
the
options
talking
to
that
this.
These
things
are
probably
better
done
in
Lake
one
suggestion
that
would
be
to
register
a
new
method
for
that
uses,
an
psk
resumption
or
external.
G
B
Thank
you
John
and
Rafa.
So
in
the
interest
of
time
I
propose
we
we
take
the
questions
in
the
open
discussion
slot
and
we
continue
with
the
next
agenda
item.
That
is
the
guidelines
for
ad
hoc
implementations
by
Marco
and
since
Marco
is
our
Note
Taker.
We
will
I
guess
Stephen
said
he
could
fill
up
fill
in
for
him
while
he
is
presenting
here.
E
E
As
I
mentioned
London
already
during
the
development
of
the
at
the
Proto
from
the
in
the
main
specification,
the
number
of
points
were
kept
out
of
scope
and
I
believe
rightly
because
not
belonging,
strictly
speaking
to
the
actual
key
establishment
protocol,
but
practically
in
implementer
working
on
the
edoc
protocol,
possibly
as
a
library
on
on
application
using
adult
we'll
have
to
take
into
account
these
things
anyway.
So
I
thought
it'd
be
useful
to
have
written
down
somehow,
perhaps
as
an
ITF
document.
E
With
that
in
mind,
it
is
relatively
easy
to
handle
the
case
where
a
completed
adult
session
becomes
embodied
and
I
I
see,
as
main
reason,
the
authentication
credential
of
the
other
peer
being
invalidated.
Well,
in
that
case,
you
just
pushed
the
adaptation
on
whatever
is
left
of
it.
You
destroy
all
the
application,
Keys
derived
from
it,
and-
and
you
are
done
again,
you
should
do
that-
the
application.
Basically
it's
a
little
different
if
the
adult
session
is
still
all
fine,
but
you
have
a
problem
with
the
application
key
material.
E
For
example,
those
keys
expired
or
got
involved
because
you
use
them
for
such
a
long
time
that
you
reach
some
cryptographic
limits,
and
then
you
may
want
to
selectively
update
that
key
material.
That
can
happen
in
different
ways
for
sure
you
can
rerun
edoko
together,
but
there's,
for
example,
a
more
efficient
way
to
do
that
running.
The
key
update
protocol
for
Oscar
kudos,
but
that,
for
example,
implies
both
adult
peers
supporting
also
Kudos
and
I
argue.
E
If
that's
expired,
of
becoming
valid
you,
you
probably
just
need
to
trash
everything
and
get
a
new
access
token
first.
So
if
you
want
this
topic
is
about
different
ways
to
do
a
key
update
depending
on
what
you
have
available
and
what
exactly
has
happened
in
the
context.
You
are
next
slide.
Please
yeah.
The
second
topic
is
about
how
to
trust
new
authentication
credentials
learned
on
the
Fly
while
running
edoc.
E
If
the
authentication
credential
is
not
new,
meaning
the
peer
is
storing
it
already,
and
it's
pointed
to
the
credential
we're
running
edoc.
Well,
all
is
fine.
If
the
credential
is
stored,
it
means
it
is
trusted
because
it
was
trusted
at
the
moment
of
storing
and
it's
fine
to
use
it
as
long
as
it
is
still
valid
all
good.
E
But
what
to
do
if,
during
the
execution
of
edoc,
a
new
authentication,
credential
is
exchanged
and
typically
by
value
in
the
edoc
message,
and
it
seemed
to
me
that
the
attack
specification
considered
especially
two
extremes
of
the
spectrum
that
here
I
call
Trust
model
one
and
three
trust
model.
One
is
very
strict,
so
you're
fine
to
proceed
and
to
learn
this
well
credentials
specified
by
value
in
the
message.
E
Only
if
it's
not
you,
basically,
if
you
store
it
already-
and
you
know
it
already
as
trusted-
well,
On
The,
Other
Extreme
of
the
spectrum.
First
model
3.
Well,
you
are
fine
with
learning
really
anything
at
all.
That
is
new
as
long
as
it
is,
of
course,
also
valid
and
verifiable,
but
speaking
in
terms
of
trust,
about
learning
something
new
I
argue
that
there's
a
middle
ground
that
I
call
Trust
model
2
where
okay,
the
credential
is
new.
E
You've
never
seen
it
before,
but
you
are
fine
learning
it
as
long
as
it
is
valid
and
as
long
as
you
are
storing
at
least
a
trusted
identifier
that
can
be
associated
with
that
resource.
For
example,
the
credential
can
be
a
certificate
transfer
by
value
that
the
peer
has
never
seen
the
certificate
is
valid
and
the
peer.
A
E
Yeah
the
case
I,
imagine
there's
an
example
of
thrust
model.
2
would
be
transferring
a
new
certificate
by
value
in
that
message,
so
it's
new.
It
is
valid,
but
it's
fine,
because
the
peer
is
storing
already
trusted
identifier
of
that
certificate.
For
example,
a
hash
next
slide.
Please
right-
and
this
is
about
noting
that
if
you
want
to
implement
a
full
and
complete
processing
of
incoming
adult
messages,
the
process
can
be
not
exactly
linear,
especially
if
you
think
about
the
incoming
adult
message.
E
E
E
My
idea
was
to
document
these
guidelines
at
a
profit
level
detail
in
an
informational
draft
for
the
working
group
to
consider
possibly
based
on
on
the
decision
about
the
chartering,
the
result
of
rechartering
and,
first
of
all,
of
course,
I
I'm
interested
in
understanding.
If
this
is
a
scope
appropriate
and
if
any
other
aspects
that
I
haven't
talked
about,
I
haven't
mentioned
here
are
words
considering
anyway.
D
Yeah
I
had
a
comment
there.
Could
you
go
back
to
the
yes
one
of
the
slides
with
tofu
previous
previous
that
one?
Yes,
so
I
just
wanted
to
clarify
these
trust
models.
Three
here,
that's
it
sounds
sound
a
little
bit
like
you
were
saying
that
there
is
a
trust
model
where
you
accept
anything
which
I
suppose
is
a
possible
trust
model,
but
in
as
it's
phrased
in
the
in
the
draft,
it's
a
little
bit
like
you
accept.
D
C
D
Yes,
yeah
no,
but
I
think
this,
so
that
was
just
a
minor
comment.
I
just
I
think
this
is.
These
are
good
good
topics
and
it
would
be
interesting
to
see
other
implementers
views
also
on
this
and
and
one
way
of
getting
to
know.
That
is,
of
course,
that
you
start
writing
this
text
and
then
we'll
we'll,
try
it
on
others
and
see
if
they
have
the
same
or
other
proposals
for
how
for
implementation
guidance
in
this
yep.
Thanks
for
proposing
thank.
E
B
All
right,
thank
you,
Marco,
so
I
guess
we
can
move
to
the
next
agenda
item,
which
is
the
summary
of
the
discussions
regarding
EAD
items
that
were
happening
during
iitf
115
in
London.
So
let
me
stop
sharing
the
slides
first
I.
Don't
have
any
slides
to
share
for
this,
but
yeah
it
will
be
rather
quick.
B
The
idea
here
was
that
ad
hoc,
as
you
all
know,
ad
hoc
defines
the
external
authorization
field
for
third-party
applications
to
send
data,
and
we
have
seen
several
applications
so
far
come
up
that
are
using
these
fields.
One
of
these
applications
is
the
third.
The
draft
that
we
are
that
is
proposed
in
Lake
that
considers
third-party
authorization
of
for
enrollment
use
case
where
essentially,
actually
a
new
device
is
authorized
to
join.
A
new
domain
by
the
manufacturer,
authorized
signing
Authority
some
sort
of
a
lightweight
brewsky.
B
If
I
may,
if
I
may
say
that
we
have
been
pushing
for
some
time
now,
and
this
was
presented
during
ITF
in
London,
then
we
had
the
second
item
regarding
ocsp
stapling
and
certificate,
revocation
using
the
EAD
fields,
and
there
has
been
lately
also
the
discussions
on
remote
attestation
using
the
ad
Fields.
So
my
proposal
for
if
we
are
going
to
retractor
as
a
working
group,
would
be
to
include
a
paragraph
on
a
generic
EAD
items
that
can
come
up
later
in
future
that
we
could
process
as
a
working
group.
D
Just
wanted
to
add
to
to
this
one
of
those,
the
ocsp
stapling
that
we
John
and
I
had
a
meeting
with
with
the
thesis
student
Joseph
today
and
he
planned
to
submit
an
or
we
I
mean
he
would
be
driving
it.
But
we
will
be
co-authoring
the
a
draft
before
hopefully
before
the
cutoff.
So
so
we
might
have
some
new
material.
B
C
A
B
B
Year
so
at
the
moment
we
have
a
concrete
to
to
proposals
right
to
deter.
One
is
already
submitted
as
a
draft,
and
then
the
other
is
coming
up
from
what
yoran
is
saying
for
the
idea
for
the
London
for
the
Yokohama
cutoff.
So
if,
if
we
want
to
be
very
very
specific,
we
can
we
can
list
these
explicitly
in
the
charter
in
the
new
Charter,
but
I
there
are
all
there
have
been
also
ideas,
so
I
think
maybe
listing
these
three.
That
I
mentioned
would
be
a
good
starting
point.
D
D
Valid
question
Stephen:
what
what
sort
of
what?
What's
the
end
and
to
this
and
and
there
are
as
as
mentioned,
there
are
a
number
of
ideas,
how
to
combine
authentication
with
something
else
and
of
course
there
might
be
more
proposals
when
people
realize
that
this
how
this
works.
But
we
don't
need
to
include
everything
in
the
charter
we
could.
We
could
say
that
these
are
use.
A
B
A
A
B
B
C
B
A
A
F
B
A
Okay,
I
mean
we
can
you
know,
there's
only
13
people
here.
So
it's
not
like
there's
thousands
of
people
don't
want
to
do
stuff,
so
we
I
I
think
if
Malaysia.
If
you
draft
a
first
cut
at
a
possible
new
Charter
and
we
can
discuss
it
on
the
mailing
list-
I
mean
I.
Guess
we
could
so
we
can
request
a
slot
because
we
have
to
do
that
this
week.
B
B
Item
yeah,
but
so
whether
to
have
a
meeting
in
Yokohama,
so
I
think
it
would
make
sense
to
have
an
update
on
the
reviews
that
will
be
there.
I
suppose
we'll
have
ads
review
of
ad
hoc,
and
then
we
can
discuss
that
and
possibly
another
reviews
that
come
up
in
the
meantime
and
also
this
retargeting
issue
again.
I.
C
A
We
should
request
this
last.
Probably
an
hour
is
probably
enough
and
I
guess
you
know
if
it
turns
out
that
nobody
wants
to
actually
do
work
in
retireing
and
the
and
the
everybody
loves
the
ad
hoc
draft
as
it
is,
then
we
might
not
need
that
slot,
but
I
guess
you
know
most
likely.
We
will
have
some
reviews
and
we
we
hopefully
will
have
some
people
want
to
reach
harder.
A
F
A
D
D
G
D
F
Of
the
the
interesting
differences
between
TLS
and
dtls
is
that
TLS
connection
can
always
be
broken
by
by
anyone
by
breaking
the
underlying
TCP
connection.
While
it's
much
harder
to
break
a
dtls
connection,
and
that's
because
we
have
more
robust
ways
to
to
associate
packets
with
particular
connections.
D
A
A
Foreign
just
can
I
ask:
if
do
are
there
people
who
know
already
that
they
will
be
physically
present
in
Yokohama
or
or
know
that
they
won't
be
and,
and
or
you
know,
if
you're,
you
know
one
of
the
involved
people
and
you
can
let
the
chairs
know
they'll,
be
fine.
If
you
know
right
now,
that's
great
to
let
us
know.