►
From YouTube: IETF112-LAKE-20211112-1430
Description
LAKE meeting session at IETF112
2021/11/12 1430
https://datatracker.ietf.org/meeting/112/proceedings/
C
Okay,
so
I
guess,
since
we
have
an
hour,
we
might
get
going,
you
know
more
people
they'll
miss
the
untrolling
first
couple
of
minutes,
so
we
do
the
adventist
review
so
welcome.
This
is
the
lake
meeting
at
age
f-112.
C
So
they've
got
some
links
if
you
meet
them,
they're
not
well.
This
is
friday
of
the
night
effect
you've
seen
this
a
lot
of
times.
You
should
be
aware
of
it
and
in
addition,
people
you
know
like
to
behave
well
so
doing
that
is
good
again.
If
you
kind
of
keep
an
eye
on
the
code,
you
know
bear
in
mind
the
code
of
conduct
and
behave
appropriately,
but
I
don't
think
we've
had
a
problem
in
this
group.
C
So
here's
our
agenda
minnesota
we're
in
the
middle
of
that
there's
a
an
update
on
the
on
the
kind
of
you
know
the
way
we
want
to
try
and
interact
with
the
academic
cryptographic
community
to
get
kind
of
analysis
done
this
year,
we'll
cover
there's
the
new
draft
on
traces
that
we
had
consensus
on
adopting,
I
think
militia,
and
I
are
not
entirely
clear
on
on
what
final
destination
people
really
want
for
that
in
our
exact
scope.
C
So
there's
a
couple
questions
on
that
and
then
they
will
hand
over
to
john
for
handling
issues
with
the
main
spec
of
ed
hock
and
next
steps
planning,
whether
we
want
another
interim
before
the
holidays,
etc.
C
Take
that
as
a
no,
we
have
a
minute
taker
thanks
timothy
and
in
jabber,
myself
and
militia
will
keep
an
eye
on
that.
So,
if
you
want,
if
you
have
audio
issues,
then
you
can
feel
free
to
type
into
jabber
and
we
will
be
able
to
bring
your
comment
to
the
microphone
okay.
So
with
that
we'll
move
on
and
militia
over
to
you,
I
think
you're
going
to
share
a
screen
right.
A
Yes,
I
will
so
we
I'll
just
give
a
brief
update
on
this.
So
as
we
agreed
during
the
last
itf
meeting,
we
will
launch
a
formal
call
for
formal
analysis
of
the
specification,
as
it
is
now
in
a
pretty
good
shape,
and
we
feel
confident
that
it
is
ready
to
go.
I've
been
working
with
karthik
and
the
co-authors
of
the
ad
hoc
draft
on
writing
up
a
letter
or
like
a
short
paper
summarizing
ad
hoc.
A
That
would
be
like
the
first
point
of
entry
for
people
who
were
not
familiar
with
the
ad
hoc
standardization
process,
mainly
targeting
the
the
crypto
community,
and
so
essentially
this
I
was
hoping
to
have
this
published
for
the
today's
meetings.
We
received
some
comments
from
critique
that
I
wanted
to
address
before
putting
this
online,
so
I
will
just
go
skim
through
like
what
this
is
all
about.
This
is
right
now,
like
a
six
page
letter
in
ieee
format
that
summarizes
the
protocol.
A
It
mainly,
as
I
said
it
like
it,
tries
in
a
pedagogical
manner
to
describe
the
protocol
to
give
a
summary
of
the
different
things
that
are
relevant
for
security
analysis
and
one
of
the
big
parts.
There
is
essentially
the
security
goals
requirements
that
we
agreed
on
as
the
first
step
during
the
working
of
the
standardization
process
in
lake,
so
these
are
noted
here
and
then
so
yeah.
So
let
me
take
a
step
back.
So
essentially,
the
document
is
split
in
three
parts.
A
First,
one
is
like
the
security
requirements
that
we
agreed
on
in
the
in
the
requirements
draft.
The
second
part
is
the
protocol
design,
essentially
introducing
ad
hoc
to
the
first
comers.
A
A
So
this
is
nearly
done.
I
am
main,
I
hope,
to
be
able
to
publish
this
on
mon
beginning
next
week.
Essentially,
what
is
right
now
pending
is
is
a
table
that
we
want
to
where
we
want
to
summarize
essentially
translate
between
the
different
security
goals
agreed
in
the
requirements
document
and
then
map
this
to
the
papers
that
have
already
done
some
formal
analysis
on
the
specification
improved
the
different
properties.
So
it
is
this
table.
A
So
essentially
we
reference
here,
the
properties
that
were
approved
and
what
we
would
like
to
see
proven
during
this
six
month
period
that
we
will
trigger
that
once
we
agree
that
this
specification
is
ready
and
good
to
go,
and
then,
of
course,
there
are
a
bunch
of
tables
summarizing
the
the
algorithms
that
are
used
like
everything
that
people
can
find
in
one
place
not
to
have
to
go
through
the
different
specifications
in
the
itf,
but
obviously
the
any
itf
documents
have
precedence
if
there
are
any
inconsistencies
with
the
document
and
the
id
of
specifications,
but
we
make
every
attempt
not
to
be
any
so
that
would
be
it.
A
As
I
said,
I
will
give
it
a
go
and
publish
this
on
open
archives
during
the
next
week
and
send
send
an
email
essentially
to
the
mailing
list,
inviting
the
formal
verification
community
to
to
start
the
analysis
in
the
following
period,
and
we,
as
I
said,
we
are
doing
this
in
coordination
with
karthik
who
will
help
us
to
reach
the
teams
around
the
world
who
are
who
have
expertise
in
this
kind
of
studies.
A
So
that
would
be
it
on
on
my
side.
Regarding
this,
this
item,
do
we
have
any
questions.
C
So
yeah,
I
guess
it's,
you
know
it's
a
good
time
to
jump
on
the
queue.
If
you
have
questions,
I
I
have
a
couple
yes
so
so
I
think
I
think
this
is
great
work
and
it's
a
really
good
idea
to
try
and
lay
it
out.
This
way,
that's
friendly
for
people
who
want
to
do
the
work.
That's
that's
really
a
good
idea.
C
C
A
Yeah,
so
my
goal
is
essentially
yeah.
I
will
put
this
online
or
like
next
week,
hopefully
like
monday
tuesday,
and
then
I
mean
we
can.
This
will
be
published
in
open
archives.
For
the
time
being,
we
can
just
like
iterate
and
great
yeah.
C
So
so
I
I
think,
that's
perfect,
so
so,
if
we
yeah,
if
you
guys
finish
this
open,
I
think
it's
a
great
piece
of
work
and
I've
got
a
really
good
idea
and
then
maybe
invite
people
to
comment
on
it
and
issue
updates,
as
as
clarifications
are
needed
or
whatever.
That
would
be
super
cool.
So
my
second
question
was:
you
said
six
months:
how
do
we
know
that
that's
the
the
right
period.
A
C
That's
useful
information
to
have
so
I
mean
I
guess,
as
chairs
we
probably
will
put
this
out
there
and-
and
the
suggestion
is
that
we'll
kind
of
you
know
wait
six
months
to
see
what
happens
as
a
default.
Hopefully
something
happens
and
then
we
don't
have
to.
We
can
stop
waiting,
but.
A
A
C
E
Six
months
is
like
first
shot,
then
we
before
this
the
document
processes.
We
always
have
to
have
a
discussion.
So
if,
if
the
working
group
thinks
something
is
worth
waiting
for
or
not,
we
can
decide
that
later.
C
Okay,
so
everybody
seems
happy
with
six
months.
I
assume
everybody
is
happy
with
it
with
the
idea
of
this
document.
It
seems
obviously
a
good
idea
to
me
anyway.
If
anybody
has
any
comments,
now's
a
good
time
before
we
move
on.
A
C
A
A
Can
you
go
to
the
next
slide,
so
we
launched
the
working
group
adoption
call
and
on
18th
of
october,
for
two
weeks
after
the
initial
agreement
during
the
last
interim,
we
got
feedback
from
three
implement
so
essentially
from
marco
stefan
sean
and
john,
who
is
also
a
co-author
general
feedback
we
received
is
that
people
support
adoption
there
is
there
were
no
opinions
that
this
should
not
be
adopted
and
people
support
the
publication
as
an
informational
rfc.
A
A
A
There
was
interest
expressed
for
the
nest
curve
p256.
We,
I
think
marco
and
stefan
raised
interest
around
having
test
vectors
on
cypher
suites,
two
and
three
specifically.
So
what
we
would
like
to
hear
now
from
the
working
group
is
what
are
your
opinions
on
this?
I
mean
first,
if
you
object
to
this
document
being
published
as
an
rfc
and
then
second,
what
are
your
thoughts
on
the
exact
scope?
Should
we
be
exhaustive
and
cover
each
method
with
all
the
cipher
suites
that
are
defined?
A
So
essentially,
we
select
a
set
of
cipher
suites
like,
for
instance,
zero
and
then
two,
which
would
cover
the
nist
curve
and
the
edwards
curve.
A
Or
just
be
selective
and
do
with
the
different
methods
like
as
john
proposed
on
the
email
mailing
list,
so
yeah.
D
F
So
I
don't,
we
will
still
have
like
a
github
page,
where
we
have
a
lot
of
other
test
factors,
and
I
I
don't
think
we
should
be
exhaustive
and
in
the
draft
and
just
have
them
as
additional
support
and
then
on
the
github
page.
We
can
have
much
more
test
factors
and
be
much
more
exhaustive,
but
it
would
be
difficult
to
have
an
exhaustive
list
of
all
the
combinations
in
the
drafts.
A
A
It's
I
think.
F
I
heard
this
comment
during
the
last
interim
and
I
I
can't
remember
who
said
it,
but
it's
difficult
to
decide
like
where
to
stop.
Of
course,
this
could
be
the
discussion
we're
having
right
now
is
what
should
we
include
and
whatnot.
F
A
E
My
idea
would
be
that
they
have
a
lot
of
test
vectors,
basically
no
limitation
in
json
format,
on
github
and
then
my
proposal
would
be
to
select
quite
few
for
the
drafts
with
a
lot
of
explanations.
I
think,
if
you
want
to
check
your
implementation
against
something,
you
probably
do
that
with
a
json-based
test
vector.
If
you
want
to
understand
more
about
why
things
are
like
there
is
and
walk
through
test
vectors.
E
Then
you
look
at
the
draft,
so
I
think
beyond,
like
two
three
traces,
I
think,
there's
you
don't
get
increased
understanding
if,
with
the
with
the
explanations
in
the
draw,
so
I
think
for
correctness
case,
I
would
say
two
to
three
traces
and
focus
on
making
this
correct.
C
So
yeah
I
mean,
and
it
also
reflects
that
the
comments
in
jabber
there
so
that
you
know
that
sounds
like
a
plan
that
people
are
happy
with.
I
guess
the
action
would
be
to
create
a
place
in
github
for
traces
to
be
posted
and
then
to
at
some
point
select
from
those
to
which
goes
into
the
draft.
C
C
Of
them
are
in
the
traces
okay,
so
so
we're
inviting
people
to
submit
prs
with
with
new
ones
is
that
right.
G
Yes,
we
actually
have
a
new
contributor
who's
going
to
do.
Cypher,
sweet
two
and
three
and
we'd
also
be
becoming
a
new
co-author
of
the
tracy's
draft
great.
So
that's
marek
sirafin
from
assam
block
good.
D
Yeah
hi
for
the
draft.
I
personally
find
ideal
a
compromise
between
what
timothy
said
basically
and
what
is
in
the
slide
now
as
as
selective,
so
basically,
methods,
zero
and
three
for
both
ciphers
with
zero
and
two
but
yeah.
Just
my
preference,
and
I'm
just
reiterating
what
I
wrote
to
the
list
a
few
weeks
ago.
D
G
Okay,
let's,
let's
take
an
action
on
on
making
a
concrete
proposal
based
on
this
input
and
then
get
back
to
the
main
list
with
that
great.
C
Okay,
we're
we're
only
a
couple
of
minutes
behind
time,
so
that's
that's
pretty
good,
so
I
think
we're
we're
ready
to
move
on
to
the
next
agenda,
which
is
john,
I
guess
so
john.
If
do
you
want
to
hit
the
share
slides
button?
C
So
if
you
hit
the
the
the
piece
of
paper
thing
to
the
left
of
the
join,
the
cue
button
at
the
right
is
joining
the
q
button.
Then
we
can
give
you
permission
just
to
control
the
slide
deck
yourself.
E
E
E
E
Then
some
changes
and
simplifications
to
the
negotiation
of
cypher
suites
added
the
mac
length
to
the
ciphers.
Instead
of
relying
on
the
siphon
aad.
E
E
Cwt
and
ccs
was
added
support
for
these.
They
are
named
k,
cvt
and
kccs
to
indicate
that
these
are
cyborg
web
token
and
symbol
claims
that
with
a
key
inside
them,
they
work
like
certificates,
main
changes
to
the
ead
type.
E
E
Then
there
was
a
discussion
of
pqc,
so
it
was
added
a
clarification
to
the
document
that
pqc
chems
could
be
added
later
to
method,
0.,
no
technical
change.
This
cannot
be
used
straight
away
at
the
moment,
then
the
clarification
that
all
cozy
signatures
are
supported.
The
current
plan
is
that
the
adhoc
supports
all
signatures
from
cosi.
That
includes
hash
based
rsa
and
wall.
Not
not.
I
don't
know
if
anybody
wants
to
use
them,
but
they
the
plan,
is
to
support
the
whole
future.
E
There's
some
clarification
about
cypher
c
suite
we
made
updates
to
the
mti
section.
It
was
based
on
the
discussion
in
the
year
in
the
interim.
Basically
must
support
kid
for
the
other
parameters
that
was
to
do.
We
just
added
that
it's
up
to
the
implementation
to
support
whatever
they
want.
This
aligns
with
the
other
parameters
of
this
type.
Then
the
cozy
processing
was
moved
to
an
appendix
to
shorten
the
body
and
then
there's
some
internal
references
that
was
fixed.
E
Then,
according
to
the
agenda,
we
have
50
minutes
four
issues.
I
think
there's
12
left.
So
this
is
a
short
list
of
all
the
open
issues,
excluding
test
vectors
and
the
reviews.
E
E
Other
clarification
that
the
norms
also
provide
a
binding
between
the
kt
update
and
the
message
that
triggered
the
key
update,
or
it
can
do
that
and
then
an
explanation
why
ad
hoc
is
not
using
a
running
hash
and
the
reason
for
that
is
that
that's
not
supported
on
many
constrained
platforms,
a
new
issue
on
adding
privacy
consideration
based
on
the
model
t
discussions
and
the
link
here
is
documented
by
yellow
article
and
stephen
farrell.
E
Then,
in
issue
193
question
about
adding
hp
e
algorithm
for
method
0.
As
I
said,
there
was
a
clarification
that
this
could
be
done
later,
after
that
there
is
a
new
draft
in
cosi
that
adds
hpk
e
algorithms
there's
discussion
in
cosy
whether
this
will
just
register
as
subset
of
algorithms
or
if
it
will
support
all
future
hpk
algorithms
and
also
discussion
whether
this
is
the
way
to
do
key
derivation
in
cosi
in
the
future
or
if
it's
one
way
to
do
key
iteration
in
the
future.
E
I
think
the
only
reason
to
do
this
now
would
be
if
cool
c
already
now
decides.
That
hpke
is
how
we
will
use
pqc
chems
in
the
future.
Then
it
would
be
worth
adding,
and
this
would
not
be.
It
will
not
change
any
of
the
current
methods
or
test
vectors.
It
would
be
gx
and
gy.
You
would
put
a
different
byte
string
in
these
when
you
use
a
pqc
chem,
but
currently
that
is
not
specified.
That
will
require
some
some
new
draft
in
the
future.
E
E
This
is
similar
to
I,
I
think,
as
the
the
information
is
encrypted
in
ad
hoc
in
tls
102,
the
thing
the
signature
is,
I
don't
in
some
protocols
you
can
prove
it
by
just
looking
at
the
information
on
the
wire
in
ad
hoc.
The
other
part
needs
to
save
things.
It's
not
visible
from
the
wire
and
then
we
have
an
issue
about
optimal
padding.
That's
blue,
because
I
have
a
separate
slide
on
that.
E
186
is
a
discussion
about
the
ead
internal
structure
and
the
api.
This
was
based
from
comments
from
implementers
where
this
seaboard
encoding
should
be
done
and
how
and
also
a
bit
unclear
still
how
other
protocols
will
will
use
the
ead
interface.
E
My
reflection
for
this
discussion
is
that
we
probably
need
to
specify
it
as
we
cannot
have
any.
We
need
to
specify,
as
a
byte
string,
to
make
sure
that
the
data
is
correct.
Cyborg,
it
does
not
affect
the
security
of
adhoc
as
such,
but
you
could
imagine
that
some
other
application
assumes
that
it
actually
is
correct,
seaborn
and
then
it
should
be.
But
I
think
this
this
needs
more
discussion
and
then
there
is
security,
consideration
for
two
fiances
that
done
in
ad
hoc
or
in
cosi,
and
too
many
words.
E
There
is
regarding
compact
representation.
There's
a
draft
in
cfrg
that
suggests
that
for
hpke
don
said
he
didn't
get
any
did
not
get
positive
feedback
for
that.
I
wasn't
there
when
he
presented,
but
I
sent
the
mail
to
cfrg
asking
if
there
was
any
need
to
do
any
alignment
if
see
if
audrey
thinks.
So
I
guess
we
will
do
that.
Otherwise,
probably
not,
then
we
have
effect
of
limited
randomness.
E
E
See
that
we
have
here's
a
slide
about
optimal
padding.
The
issue
here
is
that
ad
hoc
security
consideration,
so
privacy
consideration
doesn't
currently
does
not
say
that
adhoc
reveals
the
length
of
your
identity
and
also
the
length
of
ead.
E
I
mean,
and
there
is
an
appear
that
I
have
written
190
that
adds
security
consideration
for
this,
and
it
also
had
a
padding
mechanism
tls,
and
I
cast
padding
mechanisms
for
this
unclear
how
much
they
are
used.
But
my
proposal
would
be
that
we
add
this
as
an
optional
feature.
You
don't
have
to
implement
it
if
you
don't
want,
but
we
can
and
padding
would
not
be
needed
for
several
of
the
identities.
E
You
can
choose
a
fixed
length
identifier
instead,
but
I
think
this
is
a
useful
feature
to
have
and
it
doesn't
affect
anything
else.
If
you
don't
implement
it,
you
can
ignore
it.
C
Resolutions
for
most
of
these,
what's
the
best
way
to
close
a
bunch
of
them
that
we
think
are
ready
to
close
just
maybe
send
one
mail
to
the
list
with
a
you
know,
listing
all
of
the
issues
you
propose
to
close
and
then
just
giving
a
giving
people
a
few
days
then
going
ahead
and
doing
it
yeah.
C
E
So
if
you
have
any
comments
on
any
of
these
issues,
please
please
be
active
on
github
or
send
an
email
to
the
list.
Of
course,
good.
Then
there's
issues
about
test
factors.
I
think
these
we
have
already
discussed
earlier
in
the
meetings.
E
At
least
167,
the
content
of
the
traces
document,
188
is
an
issue
about
it
says
missing,
suits
are,
but
what
is
proposed
is
to
have
a
list
of
supported
the
cipher
suites,
both
in
the
initiator
and
the
responder.
E
This
would
be
something
different
suits,
eye
and
suits
are
only
have
meaning
in
the
actual
messages
they
might
be.
They
they
might
be
truncated
from
the
full
list
of
supported
ciphers.
E
E
It's
probably
worth
giving
this
shot
again
and
add
such
a
list.
Another
consideration
is
whether
we
should
add
test
vectors
for
a
message
flow
with
an
error,
so
message
one
and
then
an
error.
I
don't
support.
I
don't.
I
support
a
better
cipher
suit
and
then
message
one
two
three
again.
That
would
probably
be
useful,
but
it's
also
work,
of
course,
but
that
would
probably
be
good
to
do.
E
Yeah
thunder
suggestion
to
have
a
table
of
content
in
the
test
vector
document-
I
don't
know
if
it
was
for
the
traces
or,
but
it
should
definitely
be
there
for
the
json
test
vectors
there's
there
are,
I
don't
know,
probably
more
than
10
test
vectors
and
there's
no
information
what
what's
in
them,
so
it
unless
you
look
at
the
source
code,
so
there
are
a
table
illustrating
that
what
is
definitely
very
needed,
and
I
think
we
will
add
that
and
there
is
more
sweets
I
think
we
already
discussed.
E
I
think
everybody
agrees
at
least
that
we
should
have
the
p256
ecdsa
yeah
and
that's
ongoing.
There's
all
there
is
test
vectors
coming
very
soon.
For
that
I
think
that's.
E
This
is
the
general
issue
about
test
vectors
editions
12
of
the
twenty
ten
of
the
twelve
things
are
done
here
might
need
to
update
this,
but
you
should
also
have
the
real
certificates
right
now,
they're,
just
a
sequence:
zero
one,
two
three
four
five:
they
should
definitely
be
a
real
certificate
with
real
public
and
private
key
that
you
can
test.
This
will
also
be
added
quite
soon.
I
hope
in
the
coming
months.
E
So
at
the
I
think
it
was
at
the
interim.
There
was
a
request
from
the
cheers
and
also
from
the
authors
that
to
get
people
to
review
the
document,
because
we
feel
that
we
are
getting
closer,
at
least
to
the
finish
line
yeah
and
we
have
gotten
four
reviews.
That's
excellent
and
all
the
the
four
reviews
has
been
added
as
their
own
issues
in
github.
E
So
it's
easier
to
see
and
discuss
them.
I
think
the
plan
is
to
fix
all
the
editorial
issues
in
them
and
then,
if
some
and
as
much
technical
things
also
and
if
something
we
need
more
discussion,
let
me
open
a
new
issue
for
that
topic
and
maybe
close
the
general.
E
Big
thanks
to
everybody
that
has
reviewed.
I
think
the
comments
are
general
positive,
quite
a
lot
of
small
editorial
things
and
and
some
technical.
So
these
discussions
are
only
the
bigger
technical
things
that
or
might
be
worth
discussing.
Marco
is
not
here
because
I
think
all
his
comments
were
more
editorial.
I
think
a
lot
of
them
has
already
been
addressed
so
comments
by
stefan.
E
Ead
who
is
supposed
to
encode
the
code,
erd
application
or
implementation,
and
my
high
level
answer
right
now.
I
think
I
think
the
api
needs
to
be
changed.
I
think
it
needs
to
be
in
them
by
string
and
then
they
probably
the
ad
hoc
application,
do
a
simple
encoding
of
the
int
and
the
byte
string,
but
in
the
under.
I
think
the
ad
hoc
specification
should
not
not
specify
exactly
how
this
api
looks
like
that's
up,
for
the
application
might
look
a
bit
different
in
different
programming
languages
and
so
on.
E
Then
error
handling
steve
asked
why
a
success
error
is
needed.
He
doesn't
see
a
useful
one
and
he
says
he
does
a
lot
of
logging,
but
it
doesn't
have
eq.
So
success
was
some
suggestion
from
iot
ops.
I
think
that
was
one
of
the
clearest
suggestion
they
had.
E
E
Then
mandatory
mti
cipher
suite
this
we
have
discussed
and
agreed
to
discuss
later
steve
found
suggest
that
we
should
change
the
text
from
zero
and
two
to
zero,
slash
one
and
two
slash
three.
He
doesn't
think
it
makes
sense
to
make
a
difference
between
the
truncated,
ccm
and
the
full
ccm.
That's
the
only
difference
between
these
episodes.
I
think
we
can
discuss
that
when
we
discuss
the
mandatory
to
implement
cypher
suit
sweet
question
later
that
we
said
we
do
when
we
have
a
working
group.
E
And
then
it's
should
what
you
should
do
here
and
what
you
can
do,
and
I
think
current
answer
is
that
airtalk
doesn't
give
much
guidance
regarding
this.
You
can
use.
If
you
use
x509,
you
can
use
crl
and
you
can
use
ucsb.
E
You
cannot
use
ucsb
stapling
because
it
does
not
support
ocsp
stapling
at
the
moment,
if
somebody
wants
ucsb
stapling
and
that
was,
for
example,
suggested
by
dkg
during
the
cozy
meeting
that
that
might
be
a
good
idea
to
have
it
mass
staple,
then
we
would
either
have
to
introduce
it
in
cosi
or
in
in
ad
hoc
would
be
possible.
E
And
she
asks
what
documentation
is
required
and
if
we
should
also
have
specification
required
this,
we
discussed
that
in
the
ream.
I
think
it
was
happy,
but
I
don't
think
there
was
a
lot
of
comments.
So
this
might,
if
I
think,
if
people
think
we
should
have
specification
required
instead
do
that.
Otherwise
there
might
be
a
need
here
to
explain
what
the
documentation
is
required
to
more
guidance
to
the
experts.
E
E
C
I
Hi
there
I
think
I
can
send
audio
yeah.
I
was
just
suggesting
that
having
too
many
options
leaves
implementers
in
a
position
of
having
to
make
decisions
that
they
generally
don't
know
how
to
make
so
the
clearer
we
can
give
guidance
the
better.
I
It
sounds
from
the
discussion
on
the
chat
that
the
strongest
reason
for
including
p2v6
and
ecdsa
is
hardware
implementations
or
constrained
devices
that
want
to
you
know
they
have
that
have
a
hardware
constraint,
and
so
maybe
we
could
just
add
some
guidance
to
the
document
that
says
you
know
use
255.19
unless
pre-existing
hardware
constraints
force
you
into
using
ecdsa
or
something
like
that.
I
E
Yeah,
I
think
there
are
already
something
something
similar
to
what
you
suggest
that
was
suggested
by
stephen
farrell,
but
I
think
some
some
more
guidance
might
be
good
might
also
be.
It
might
also
be
good
to
give
some
more
explanation.
What
what
the
difference
between
different
options
would
be.
I
E
I
think,
let's
try
to
add
that
so
moving
on
to
steven's
comments,
so
first
connection
identifiers
and
stephen
as
that
you
might
be
able
to
track
a
client
if
you
look
at
this
and
he
asked
whether
they
could
be
derived
in
another
way,
and
if
this
has
been
considered-
and
this
has
been
considered-
I
think
we
have
an
earlier
version
of
the
draft
degenerate
these
in
a
random
way.
But
then
you
also
need
to
have
a
much
longer
due
to
collisions.
E
So
it
has
that
was
moved
right
now,
it's
up
to
the
clients,
initiator
and
responder
to
choose
them
in
any
way
that
party,
so
you,
you
can
implement
any
way
but
they're
not
hidden
in
any
way
they're
sending
clear
text
and
you
want
to
add
anything.
Stephen.
C
Yeah
and
again,
I'm
not
entirely
sure
what
the
potential
value
here
might
be,
because
connection
identifiers
could
be
a
connection
could
be
obvious
to
somebody
looking
at
the
traffic
anyway,
you
know
we
do
have
the
issue
with
threats
like
if
you
have
a
a
light,
switch
that's
activated
when
a
person
enters
a
room
just
being
able
to
detect
that
the
packet
comes
in,
that
light.
C
Switch
is
probably
revealing,
regardless
of
any
encryption,
and
if
my
concern
is
that
these
connection
identifiers,
if
they
kind
of
leak
over
to
something
else
into
other
protocols
like
and
if
there's
some
kind
of
proxying
going
on
or
multiplexing,
then
these
these
could
allow
that
kind
of
attack
to
happen.
C
So
yeah,
I'm
not
sure
if,
if
doing
better
with
connection
identifiers
in
ad
hoc,
would
enable
a
good
solution
for
that
or
would
be
window
dressing.
But
it's,
I
think
it's
a
concern.
If
you
can,
you
know
if
you
can
just
correlate
the
the
key
exchange
with
the
with
all
the
later
packets,
that's
that'll
label,
some
trend.
E
Yeah
right
now,
the
idea
is
to
use
the
same
identifier
in
ad
hoc
as
in
scores.
You
would
be
able
to
see
that
this
it's
the
same
client
sending
these
things.
Typically,
you
would
be
able
to
do
that
anyway
from
the
lower
layers.
I
don't
know
two
options
here,
maybe
they're
more
guidance
or
considerations
to
add
and
maybe
there's
something
smart.
We
can
do
technically.
It
would
be
happy
to
see
any
contribution
on
that,
but.
C
I
yeah,
and
I
get,
I
think
the
answer
probably
also
depends
on
how
likely
we
think
a
configuration
would
be
where
changing
makes
a
difference.
So,
as
you
say,
if
you
can
always
tell
from
a
mac
address
which
which
packets
come
from,
which
light
switch
yeah
changing
the
connection,
id
wouldn't
make
much
difference.
But
if
we
do
think
that.
C
Links
on
which
most
packets
will
be
multiplexed
from
many
devices
will
be,
you
know,
will
be
common,
then
the
connection
identifier
would
be
what's
allowing
an
attacker
to
identify
the
traffic
as
being
from
one
specific
source,
yeah
and
that
seemed
undesirable,
but
yeah.
But
I
personally,
I
just
don't
know
what
the
common
topologies
for
deployments
might
be
like.
E
I
think
I
think
there's
definitely
would
be
good
with
some
more
consideration
to
spell
out
that
if
you
use
the
same
connection
identifier
in
different
places,
for
example,
you
can
be
tracked
and
then
a
simple
solution
would
be
to
run
adhoc
again,
if
you
change
like
if
you
change
your
access
network,
for
example,
and
negotiate
a
new
connection
identifier
and
you
cannot,
then
you
cannot
trace
the
client
between
these
two
networks.
C
Yeah,
I
I
that
that's
true
and
definitely
worth
pointing
out.
I
guess,
though
I
have
heard
a
number
of
times,
people
saying
that
they
only
want
to
do
the
expensive
protocol
like
ad
hoc,
very
rarely,
and
that
might
be
just
when
you
unbox
a
device
or
after
a
power
cut
or
something.
So
it's
a
concern
again,
maybe
if
it
doesn't,
if
it
doesn't
resonate
with
people,
that's
fine.
If
people
think
it's
it's
worth
addressing
one
way
or
another,
that's
also
fine.
C
E
Yeah,
so
I
think
for
now
at
least.
E
C
Yeah,
I
I
think
that's
fair
yeah
personally,
I
mean,
I
think,
what
I
was
when
I
was
looking
at
this.
I
thought
you
could
maybe
come
up
with
a
scheme
where
you
send
an
identifier
at
the
end
in
message
in
the
first
message
and
then
derive
have
a
way
of
deriving
a
more
stable
identifier
from
that,
but
that
you
only
need
this
visible
identifier
in
one
single
message
and
the
rest
of
them
could
be
derived.
C
I
think
it
should
be
possible
to
do
it,
but,
yes,
having
a
concrete
proposal
seems
an
entirely
reasonable
request.
Yeah.
E
E
Yeah
sounds
great,
then
terminology
stephen
asked
if
cdl
or
english
language
is
normative,
there's
a
mixture.
I
think
the
answer
is
that
the
problem
needs
to
be
a
mixture.
I
think,
but
it's
not
clear.
I
think
it
needs
some
clarification.
I
think
all
the
cddl
is
normative,
but,
yes,
the
cddl
is
not
enough.
You
need
some
normative
english
text.
E
E
My
my
idea
would
be
that
we
support
everything
that
courses
approach
a
doctor
and
also
support,
for
example,
walnut
dsa,
which
is
not
recommended
and
rsa,
which
would
be
very
large,
but
the
hash
base
will
also
be
large.
I
guess
the
change
in
the
recent
version
is
that
those
questions
are
pqc
and
we
added
a
note
that
hash
basics
can
be
used.
C
Any
comments
I
think,
yeah.
I
agree
with
you
that
they're
unlikely
to
be
interesting,
but
they
do
have
a
different
property
of
being
stateful
that
you
you
only
get
so
many
signatures
and,
in
the
context
of
you,
know,
long-lived
devices
that
if
some
device
is
long-lived
and
does
ad
hoc
frequently,
then
you
might
run
into
an
issue,
but
it
seems
unlikely,
but
it
also
seems
a
bit
unrealistic
to
claim
it's
really
supportive
ben
you're.
The
cube.
B
At
least
my
understanding
is
that
when
you
have
an
application
that
uses
cozy,
you're
sort
of
assumed,
like
the
cozy
authors,
are
sort
of
assuming
that
your
application
will
be
profiling
things
down
and
that
there
may
be
some
algorithms
and
cozy
that
just
don't
make
sense
for
you,
and
so
we
probably
don't
want
to
assume
that
anything
that
has
a
code
point
in
cosi
is
going
to
make
sense
for
ad
hoc.
That's
a
slightly
different
question
from
the
specific
question
of
whether
or
not
hash
based
sigs
may
question
make
sense
for
ad
hoc.
E
E
Then
it's
seven
discussion
about
using
kdf
to
derive
public
output.
I
think
that
should
should
be
added
a
consideration
regarding
that.
I
think
nist
is,
has
very
strict
rules
regarding
this,
but
I
also
see
in
a
paper
by
krakchuk
where
he
says
that
very
much
complains
about
this
nist
requirement
and
says
it
doesn't
make
any
sense
unless
nist
have
very,
very
low
trust
in
their
cryptographic
constructions.
But
I
think
I
think
it
depends
on
how
much
public
information
you
derive
having
some
considerations
on
this
could
be
good
along.
C
Great
thanks,
I
don't
know
militia.
I
think
it
was
having
some
audio
issues,
I'm
not
sure.
If
this
are
they
sorted
or
it
should
be
good.
Now
it's
yeah,
that's
working
there.
Okay.
A
Yeah,
sorry
about
that,
but
yeah,
thank
you
john.
So
we
only
have
three
minutes
to
go.
So,
let's
maybe
just
briefly
discuss
the
next
step.
Stephen
and
I
guess,
having
an
interim
in
the
next
couple
of
weeks
before
the
christmas
holidays,
would
make
sense
to
does
the
group
have
opinion
on
this.
C
Well,
yeah,
so
so
that
I
think
opinions
of
that
would
be
welcome
also,
but
I'm
assuming
the
answer
will
probably
be
yes,
because
people
always
like
interims,
but
I
think
also
to
be
useful
to
get
opinions
from
those
who
are
not
authors
about
whether
they
think
we
should
begin
to
think
about
working
group.
C
Last
call
because
I
know
the
authors
are
keen
that
we
start
doing
it
on
that
line,
and
so
I'd
be
keen
to
have
input
from
from
other
participants
on
the
now
are
on
the
working
group
list
as
to
where
they
think
we
should
be
heading
towards
working
with
glass
calls
soon,
because
we
are
getting
close.
I
think
so.
A
C
Sure,
but
now
we
yeah,
we
did
have
to
ring
promises
to
do
reviews
out
of
people
at
the
last
interim,
though
so
we,
we
kind
of
said
he
forced
him
a
bit,
but
that's
okay,
again,
if
there's
other
people
who
are
not,
who
haven't
expressed
an
opinion
yet
about
how
close
they
think,
we
should
be
to
the
working
robust
call.
That
would
be
useful
input.
I
know
the
authors
and
the
team
essentially
behind
that
are
keen
that
we
start
a
working
blast
call
soon.
G
You're
on
good,
no,
I
don't
have
a
strong
opinion
here.
I
I
think
that
this
is
great,
that
we
got
these
reviews.
Thank
you
very
much
everyone
for
for
contributing,
and
we
have
a
good
had
a
good
discussion
today.
I
think
I
I
would
imagine
that
this
this
would
trigger
even
more
abuse.
G
If
we
do
the
working
group
last
call
in
january
or
yeah,
something
like
that,
so
that
would
be
a
way
of
pending
the
did
the
potential
crypto
reviews,
or
I
mean
we
know
that
there
will
be
some
crypto
reviews
coming
up
to
get
some
input
in
the
in
the
meanwhile,
which
probably
won't
be
overlapping
with
the
crypto
review.
I
think
if
we
ask.
C
Yeah-
and
I
mean
if
there's
if
we
assume
that
other
cryptographers
are
going
to
spend
effort
on
this,
we
kind
of
owe
it
to
them
not
to
keep
changing
the
thing
during
that
period.
So
that's
another
reason
to
have
a
relatively
stable
for
that
period.
C
So
I
like
the
way
you
implicitly
suggested
we
did
working
through
class
call
in
january,
so
that
was
nicely
snuck
in
there
and
so-
and
you
know,
I'm
guessing
that
that's
the
kind
of
thing
that
seems
to
make
sense
if
we
have
an
interim
before
the
holidays,
try
and
tie
down
to
as
few
open
issues
as
possible
and
then
kick
off
a
working
group.
Last
call
that
would
seem
to
me
like
a
sensible
plan
and
but
we
could
do
you
know
we'd,
be
happy
to
get
comments
and
input
on
that.
C
I
guess
we're
out
of
time
so
send
those
comments
to
the
list
unless
you
want
to
jump
into
the
jabber
room
where
it'll
still
be
recorded
thanks
for
your
time.
Well,
I
guess
we'll
schedule
an
interim
for
some
time
in
early
mid
december,
but
we'll
discuss
some
of
this.