►
From YouTube: IETF110-LAKE-20210309-1200
Description
LAKE meeting session at IETF110
2021/03/09 1200
https://datatracker.ietf.org/meeting/110/proceedings/
A
So
we'll
give
militia
a
minute
to
try
and
start
at
his
upgraded
mac,
and
it's
probably
started
about
two
minutes
past
or.
A
D
B
So
we
have
a
note
taker
timothy
will
be
taking
notes.
Would.
A
Somebody
will
be
willing
to
help
him,
so
christian
has
volunteered
already
and
robin
is
going
to
help
with
javascribing.
So
I
think
we're
sorted.
Okay,
perfect.
B
Welcome
everyone:
this
is
the
lake
working
group
meeting
during
the
itf
110.
My
name
is
malicia
and
my
co-chair
is
stephen
farrell.
So
I
will
briefly
go
over
the
agenda
for
today
and
before
that.
As
a
reminder,
this
is
an
itf
meeting
and
the
note
well
applies
most
notably
if
you
are
aware
of
any
patent
application
to
the
patents
that,
during
the
discussions
that
we
have,
it
is
important
that
you
disclose
those
or
not
participate
in
the
discussion.
B
So
here
is
the
proposed
agenda.
For
the
day
we
will
have
a
short
report
on
the
hackathon
and
interrupt
testing.
That
happened,
an
update
on
formal
verification
of
one
implementation
of
echo
spec,
and
then
we
will
proceed
with
the
updates
on
the
ad
hoc
can
be
open
issues.
Does
anyone
want
to
bash
this
agenda.
B
I
hear
none,
so
we
will
be
going
through
with
this
agenda
and
then
before
giving
the
floor
to
the
presenters,
I
would
just
like
to
bring
up
one
one
point
that
was
discussed
with
with
then
our
id,
and
that
relates
to
the
administrative
side
of
the
working
group
and
specifically
the
milestone
on.
B
The
ad
hoc
specification
to
the
isg,
so
currently
this
milestone
is
set
for
september
2020,
which
is
passed,
and
this
was
initial.
This
was
an
initial
estimation
right
at
the
time
of
the
chartering
of
the
working
group.
So
right
now,
I
would
like
to
open
the
discussion
on
the
best
date
to
have
to
agree
on
a
date
that
we
we
should
aim
for
to
ship
ad
hoc.
B
There
are
around
36
issues
that
are
still
open
on
the
github
issue,
tracker.
That
is
one
data
point,
and
then
another
data
point
is
that
we
want
that.
We
will
be
doing
the
formal
analysis
work.
B
So
I
would
like
to
ask
for
feedback
from
the
authors,
if
maybe
two
itf
meetings
are
enough
to
to
resolve
the
issues
and
consider
the
specification
as
as
in
good
shape,
and
from
that
moment,
which
would
be,
we
should
count
on.
I
would
say
six
months
for,
on
formal
analysis,
work
to
complete
before
shipping
the
work
to
the
isg.
B
So
you're
on
drone,
yes,
so.
D
D
C
Yeah
this
is
I
I
don't
know
how
to
predict
this
really.
Maybe
someone
else
has
better
experience
and
can
do
it,
but
perhaps
perhaps
we've
fixed
all
the
issues
by
by
the
end
of
the
summer,
and
then
I
mean
we
so
looking
at
the
state
of
the
protocol.
It
hasn't.
It
has
hardly
changed
during
the
last
12
months,
so
it's
been
really
stable
with
some
some
really
minor
change
in
version
four
and
and
now
for
for
discussion.
C
Today
we
are
proposing
a
a
change
so
which
is
also
minor
change,
but
still
a
change.
So
resolving
the
issues
doesn't
need
to
change
much
of
the
protocol,
processing
and
and
message
format,
but
but
we
are
in
we're
still
changing
things
right
now,
so
we
can't
say
we
are
are
stable
in
that
sense,
I
don't
know
anyone
else.
D
F
Sounded
good,
maybe
a
half
a
year
to
address
the
issues
and
half
a
year
to
for
the
formal
verification,
maybe
so
maybe
set
the
deadline
for
them.
I
don't
know
much
meeting
next
year
or
something
ish
yeah.
F
Yeah,
I
agree
with
your
and
that
the
current
issues
will
probably
be
resolved
after
summer.
I
don't
see
any
big
changes,
but
they
keep
popping
up
small
implementation,
things
that
are
a
bit
confusing
or
could
have
been
a
little
bit
better.
So
in
the
like
corner
cases
and
so
on,
and
I
would
not
be
surprised
if
there
pops
up
more
when
during
the
interrupt
testing,
it's
great
to
have
interrupt
test
and
we
need
to
wait
until
we
have
addressed
all
of
this.
B
So
unless
there
are
any
objections,
then
I
would
propose
to
ben
to
update
the
milestone
to
march
2021
as
a
rough
estimate
of
when
we
would
ship
the
the
spec
to
irg.
That
would
give
us
so
essentially
six
months
to
resolve
the
issues
in
six
months
for
the
glorification
work
that
we
discussed
with
kartik
and
his
team
with
parts
of
these
two
that
could
probably
overlap
if
there
are
some
editorial
issues
that
do
not
impact
the
formal
analysis.
F
I
think
there
has
been
basically
no
changes
the
last
time
that
would
affect
celtics,
formal
verification,
and
I
don't
see
any
future
changes
that
would
affect
that
either.
I'm
not
an
expert
in
formal
verification,
but
I
think
that
could
start
or
could
have
started
already
in
parallel.
B
Yeah
but
then
it
changed
the
process
called
john
woods
would
impact
those
right.
So
I
mean
ideally,
we
would
like
to
freeze
the
protocol
and
the
format
once
this
work
starts.
That's
how
I
see
it.
F
B
B
Yeah,
so
I
don't
think
I
think
on
the
call
so,
but
we
can
probably
ask
his
input,
but
so
do
you
propose
then
an
earlier
deadline
for
this
john
or
you're
happy
with
march
2022?
F
F
B
E
B
All
right
thanks,
so
that
would
be
all
on
the
chair,
slides.
I
I
will
give
the
floor
now
to
our
first
presenter
who
marco
yes
mark
is
already
on
the
in
the
presenter's
queue
hi
marquez.
H
Okay
thanks:
this
is
a
short
report
of
the
slice
disappeared.
Oh
there,
it
is
thanks.
This
is
a
short
report
of
the
tests
we
ran
during
the
hackathon
last
week
and
it's
essentially
the
third
interrupt
test
overall
that
we
had
for
dog
next
slide.
Please.
H
Right
so
we
had
test
scatter
throughout
the
the
whole
week
and
we
considered
in
total
three
implementations
mine
for
eclipse
californium,
one
from
libya,
isi
and
contikien
g,
and
one
from
christian
in
io
co-op
rebuilding,
mostly
on
the
pya
doc
implementation
from
timothy
that
we
tested
in
past
occasions,
and
I
think
it
was
the
first
time
that
we
were
testing,
especially
lydia's
in
christian's
code
and
overall,
considering
also
well
interested
observers.
H
We
gather
roughly
10
people
around
this
and
it
was
also
the
opportunity
to
build
a
better
framework
to
to
track
which
implementation
supports,
what
features
and
what
tests
were
successful
or
were
failing.
So
you
can
find
this
kind
of
material
together
with
detailed
notes
in
that
shared
dry.
Folder.
H
Next
slide,
please
right.
So
the
the
first
pair
of
testers
were
me
and
lydia,
and
notably
lydia,
had
a
constraint
set
up,
including
a
soul
constrained
device
as
part
of
an
ipv6
mesh
network
using
rpl.
H
We
consider
server,
suite
2
and
authentication
method
3
and
we
actually
tested
two
different
credential
types,
kd
and
x5t
and
of
course
the
female
keys
were
generated
differently
at
runtime.
Each
time
we
tested
both
directions
and
and
both
combinations
of
roles-
and
it
worked
fine
next
slide-
please
yeah.
H
The
other
pair
was
chris
and
me
this
time
we
consider
surface
with
zero
and
method,
zero
with
credential
type
x5t,
and
we
followed
pretty
close,
essentially
the
test
vectors
in
appendix
p1
of
the
draft
using
those
same
identity
keys
and
the
same
no
real
certificate
advice
that
you
have
there
and
again
we
generated
the
female
keys
at
runtime,
and
this
also
worked
in
both
direction
and
both
combination
of
roles.
So
I
actually
don't
have
any
failed
test
to
report
next
slide.
Please
yeah!
You
learn
a
lot
during
this.
H
In
fact,
we
were
already
able
to
to
provide
some
feedback
out
of
this
experience
to
to
document
authors
mostly
related
to
to
the
message
format
and
how
to
handle
possible
error
situations,
and
we
plan
to
run
some
more
spontaneous
interrupts
in
the
coming
weeks,
but
other
than
that
we
are
trying
to
set
up
another
actual
fourth
interop
event
about
a
month
from
now.
During
that
week
we
have
a
doodle
for
that.
So
please
cast
your
vote.
H
If
you
are
interested
to
participate
for
actual
testing
or
even
just
for
observing,
and
that
should
be
it
from
my
side,
thank
you.
B
Okay,
thanks
marco,
it's
great
to
see
new
implementers
joining
the
interrupt
testing,
and
especially
as
I
as
I
understand
this-
was
the
constrained
implementation
of
fba
in
quantity
ng
running
in
a
mesh
network,
so
I
mean
seeing
that
think
that
code
run
is
really
great.
We
also
had
have
another
implementation
that
timothy
lead
in
open,
wsn
and
riot,
which
was
tested
with
the
python
implementation.
B
But
to
my
understanding,
this
timothy
hasn't
participated
in
the
interrupt
in
the
interrupt
testing
with
the
s
hawks,
the
implementation
so
far,
but
he
will
give
us
a
brief
update
on
this
implementation
and
the
formal
verification
work
that
is
going
in
parallel
as
the
next
presenter.
C
B
Can
you
hear
me?
Yes,
yes,
we
hear
you,
so
I
think
that
was
joran
was
in
the
queue
jordan.
Did
you
want
to
say
something
or.
C
H
I
I
And
malaysia
already
said
that:
okay,
we
have
a
python
implementation,
but
we
also
have
a
c
implementation.
That's
targeting!
Can
you
go
to
the
next
slides.
Please.
I
Slowly,
okay,
great
so
the
c
implementation
of
ad
hoc
is
targeting
also
constrained
devices
and
contains
constraint
settings.
So
the
goal
is
from
this:
implementation
is
to
have
all
authentication
methods
supported,
and
at
least
the
first
four
cypher
suites.
Currently
it's
a
standalone
application
that
you
can
just
build
and
run
on
linux,
but
the
final
goal
is
to
integrate
it
in
riot
and
and
open
wsn,
and
then
openwsn
will
be
tested
over
six
dish,
so
over
constrained
wireless
sensor
networks.
I
Currently
I've
not
like
malicious,
had
not
really
participated
with
this
implementation
and
the
and
the
interrupts.
But
I've
been
testing
it
against
the
python
implementation,
which
has
been
participating
in
the
end,
drops
all
previous
interrupts.
Basically,
what
is
currently
implemented
is
all
authentication
methods
and
cypher
suites
zero
and
one.
Although
I've
only
tested
signature
paste
and
cypher
suite
zero,
and
we
started
some
initial
integration
work
in
riots
with
francisco.
I
So
there's
a
pr
ready,
but
I
think
we're
still
gonna
wait
a
little
bit
before
we're
gonna
merge
this
into
riot
to
make
the
implementation
a
bit
more
robust
and
and
integration.
Open.
Wsn
is
also
upcoming.
I
This
week
or
next
week,
next
slide,
please
so
the
work
with
the
right
people
is
part
of
a
bigger
collaboration.
I
It's
a
project
called
write
fp,
where
we
are
trying
to
build
a
future
proof
more
hardened
version
of
riot
and
within
this
project
we
also
work
with
the
prosecco
team
at
inria,
which
is
led
by
karthik
and
as
a
work
package
within
write
fp.
We
want
to
formally
verify
the
ad
hoc
implementation,
so
the
goals
of
this
formal
verification
is
to
have
an
implementation,
that
is,
that
has
memory
safety
that
has
mitigations
against
side
channel
stuff
and
in
general,
which
is
just
functionally
correct.
With
respect
to
the
to
the
specification
of
ad-hoc.
I
Next
slide,
so
we've
had
two
meetings
so
far
with
karthik.
I
The
first
meeting
was
basically
a
meeting
where
we
looked
at
the
ad
hoc
c
code
and
we
got
some
remarks
from
kartik
on
how
we
should
structure
the
code,
so
it
would
be
easier
for
us
to
do
the
formal
verification.
I
So,
basically,
we
have
a
user
api
that
will
be
used
by
applications
using
the
ad
hoc
library,
and
then
there
are
a
bunch
of
internal
apis
that
can
be
formally
verified
individually.
So
we'll
have
a
message:
a
processing,
api,
a
formatting
api,
a
crypto
api
which
can
be
mapped
to
a
different
backends.
I
So
so
far
I've
been
using
a
wolf
ssl
as
a
backhand,
but
there's
also
support
for
hackl,
which
is
a
project
also
led
by
prosecco.
It
provides
a
high
assurance,
cryptographic,
library,
it's
a
library
where
all
the
cryptographic
protocols
are
formally
verified
and
there
would
also
be
a
credential
api,
so
each
api,
each
api
can
be
formally
verified
separately.
I
So
what
we'll
have
to
do
now
is
build
two
implementations,
so
we'll
have
to
build
a
high
level,
obviously
correct
version
which
will
be
written
in
hexback.
I
I
So
will
be
interesting
once
this
work
is
done
to
see
the
performance
of
this
code
on
constrained
hardware
and
see
what
the
tradeoffs.
B
B
So
as
a
reminder
in
the
last
interim,
apart
from
discussing
the
formal
verification
of
the
implementation,
we
also
had
a
tick
joining
us
who
discussed
the
science
of
his
team
and
also
doing
the
analysis
of
the
protocol
itself,
and
that
is
the
activity
going
on
in
parallel
in
the
in
the
prosecco
team,
where
we
also
expect
inputs
useful
for
the
working
group.
B
Timothy,
I
hear
none.
A
So
I
propose
that
we
might.
A
A
quick
questions
just
on
the
the
goals
of
verifying
the
implementation,
which
do
you
have
a
pointer
to
a
description
of
some
other
instance
of
doing
this
work.
I
So
they
have
their
there's
a
paper.
I
think
at
least
one
paper
on
the
hackle
implementation,
where
they
do
the
same.
The
same,
the
same
work
so
where
the
heckle
implementation.
Also,
I
can
maybe
look
it
up.
Also
as
memory
save,
has
some
mitigations
against
side
channels
and
support.
B
B
And
so
here
we
have
consolidated
slides
for
the
next
two
agenda
items
which
are
the
changes
in
ad
hoc
version,
five
and
the
open
issues.
B
So
this
will
say
I
suppose
the
majority
of
the
meeting
time
euron
will
you
be
presenting
the
issues
or
will
or
john
is
presenting
the
next
part.
B
C
So
yes,
as
malicious
said
here,
the
three
three
parts
of
this
well,
there
are
three
parts
of
this
presentation:
there's
the
changes
in
last
version
and
then
the
open
issues,
but
there's
a
focus
on
error
messages
which
we
hope
to
resolve
this
meeting.
And
then
there
are
some
like
selected,
open
issues.
Next
slide.
C
So
there
are
three
main
main
comments
that
has
resulted
in
changes
in
the
in
the
specification.
One
is
regarding
the
the
optional
subject:
name
in
credits,
so
so
for
cosy
key,
which
is
a
map.
We
need
to
define
a
canonical
credential
to
be
verified,
since
that's
not
necessarily
passed
and
in
that
format
of
the
credits
that's
dependent
on
the
coordinates
used
and
that
that
also
contains
an
optional
subject,
name,
which
is
the
which
is
the
placeholder
for
an
identity
that
may
be
used,
withdraw
public
keys.
C
So
so
that's
that
was
that's
missing
and
that's
included
now,
and
there
was
also
from
that
was
from
michelle
by
the
way.
The
first
comment
from
peter
had
a
comment
about
transport
on
certificate
and
we
now
put
in
some
text
referencing.
Basically
the
code,
cx509
draft
and
finally,
marco,
had
some
comments
on
the
os
core
secret
and
salt.
The
length
of
those
were
hardcoded,
and
now
we've
introduced
that
configurable,
but
with
default
values.
C
So
those
were
the
changes
that
was
proposed
and
then
we
also
made
another
change,
which
was
basically
the
end
now
of
a
sequence
of
name
changes
to
this
key
update
function.
So
now
it's
simply
called
called
ad
hoc
key
update
and
it
takes
us
a
parameter,
announce
and
it's
basically
a
straightforward
application
of
the
extract,
primitive
with
nonce
and
key.
C
So
that's
very
simple:
now
we
made
some
clarifications
to
error
messages
and
where
the
second
example
is
now
a
little
bit
more
elaborate
than
the
just
simplest
case.
To
illustrate
how
the
cypher
suite
negotiation
works,
security
considerations
were
updated.
Target
security
level
was
discussed
in
an
interim
meeting.
There
are
more
details
about
that
now.
Key
confirmation
is
also
in
relation
to
message.
Four
we'll
come
back
to
that
in
the
issues
and
some
crypto
algorithms
that
should
not
that
must
not
be
used
with
ad
hoc
is
included.
C
And
finally,
there
were
some
updates
to
the
appendices
to
appendix
on
test
vectors,
which
is
now
actually
a
test
vector
for
the
specification
and
including
what
was
in
zero,
four
and
now,
and
also
the
updated
text
on
applicability
statement
more
of
that
later.
C
C
So
this
is
the
work
we've
done
since
it's
109
and
I
will
show
a
sequence
of
of
of
things:
we've
done
try
to
find
out
what
what
needs
to
be
standardized
and
sort
of
how
we
come
back
to
almost
what
we
had
in
the
beginning.
But
anyway,
let's,
let's
take
the
detour
here
around
how
we
how
we
worked
on
this.
We
we
looked
at
other
protocols
and
error
messages,
so
here
are
tls
error
alerts
and
try
to
group
them
into
these
seven
different
classes
and
some
non-applicable
next
slide.
C
Please
so
that
and
that
became
sort
of
the
basis
for
candidate
error
classes
railhawk,
and
it's
very
simple
to
describe
it's
first
one
is
related
to
psychosuite
negotiation,
second
about
syntax
and
semantics
third
about
credentials.
Fourth,
about
intake
integrity,
verification,
fifth,
about
extensions,
six
about
authorization,
but
authorization
and
seven
about
internal
errors,
things
not
related
to
the
protocol,
and
then
we
map
that
to
the
protocol
execution
processing
next
slide,
please!
C
So
it's
it's
fairly
simple
to
see
how
the
various
steps
map
to
to
the
error
codes
in
red
here
for
the
receiving
side
and
next
slide
as
well.
C
So
so
that
seemed
I
mean
that
was
sort
of
from
from
the
specification
point
of
view,
seemed
to
be
the
right
level
of
error
codes,
and
then
we
asked
iot
ops,
which
is
this
new
working
group
working
on
iot
operations.
What
kind
of
error
codes
should
we
standardize
so
next
slide?
Please.
C
And
they
were
very
inspired
and
provided
a
lot
of
good
input.
So
I
think
so.
You
see
here
there's
more
into
the
if
you
look
through
the
thread,
starting
with
the
link
at
the
bottom,
but
it's
basically
a
lot
of
input
saying
that
yes,
error
codes,
you
could
encode
them
as
integer
values,
use
a
symbolic
label
reserve
one
status
code
for
success
to
avoid
complexity.
Allow
high
level
codes
with
not
too
much
detail,
but
those
implementations
that
can
afford
more
complexity
can
have
detailed
diagnostics
can
have
sub
codes.
C
These
codes
could
also
be
standardized
later
on
and
then
an
obvious
thing
about
security
that
you
too
much
error,
reporting,
reveals
information
for
an
adversary
and
an
error
message.
There
was
a
comment
about
an
error
message
related
to
intermediate.
Progress
was
missing
in
this
list
of
of
different
errors,
comment
about
creating
a
registry.
C
It
seems
like
a
straightforward
way
to
do
to
do
the
extension
and
and
several
comments
stating
that
as
few
as
possible,
different
messages
and
the
difference
in
the
in
the
error
messages
should
reflect
actionable
next
steps,
which
is
fairly
obvious,
but
a
little
bit
difficult
to
to
realize
what
what
is
actually
actually
actionable
next
step-
and
I
come
to
counter
that
later.
C
But
basically,
if
there's
no
difference,
then
diagnosis
should
be
the
same
and
best
diagnostic
would
require
pronational
experience,
and
there
is
currently
no
operational
experience
about
adhoc,
at
least
but
other.
Perhaps
other
related
protocols
could
be
used
and
an
interesting
proposal
for
the
type
of
error
message.
It
could
actually
be
like
the
last
bullet
here
saying
only
my
admin
can
help.
Here's
your
ticket,
though
so
next
slide.
Please.
C
So,
apart
from
this
comment
about
intermediary
progress,
there
were
not
many
detailed
comments
about
these
particular
error
classes
which
we
listed.
C
So
we
brought
this
to
the
implementers
during
hackathon
and
we
had
a
couple
of
sessions
discussing
this
and,
as
it
turns
out,
I
mean
the
only
actionable
error
message
from
the
from
the
point
of
view
of
the
implementation
is
actually
number
one
which
we
already
have
specified
how
to
handle
and
the
other
messages
they
need
some
involvement
of
an
administrator,
so
so
that
that's
sort
of
it's
not
really
clear
that
do
we
really
need
to
make
these
distinctions
from
the
point
of
view
of
the
product
this
this
protocol,
for
example,
number
two
might
not
even
be
possible
to
to
send
at
all.
C
If
you
have
a
syntax
error,
you
don't
know
who
you
what
the
connection
identifier
is
number
three
might
on.
On
the
one
hand
side
too
in
specific,
because
you
can't
you
could
confuse
it
with
number
four,
for
example,
but
on
the
other
hand,
if
you
really
want
to
to
analyze
this
error,
you
need
to
be
even
more
specific.
C
So
is
this
the
right
right
level
and
number
five
and
six
relates
to
things
that
can
only
can
be
determined
by
an
application
and
number
seven
while
it
could
be
good
to
have
a
message
like
an
internal
error,
it's
my
fault.
Try
again
that
type
of
error
that
could,
alternatively,
be
handled
by
transport.
So
it's
not
necessarily
needed
to
have
an
ad
hoc
error
for
that.
C
So
finally,
slide
next
slide.
Please
so
that
leads
us
back
to
the
beginning.
What
what
should
we
specify?
What
should
we
mandate?
Who?
Who
should
for
whom?
Should
this
be
actionable,
and
we
don't
want
to
add
complexity
if
it
doesn't
add
value?
C
Diagnostic
information
should
not
simplify
an
attack
and
may
use
transport
error
messages
and
diagnostics
instead,
and
certainly
you
know,
I
mean
rely
on
that
in
certain
cases
so
that
talks
in
favor
of
perhaps
we
should
group
the
non-actionable
errors
into
one
class
and
allow
applications
to
define
error
message.
Content
and
the
proposal
coming
up
of
the
hackathon
discussion
is
what
you
can
see
on
this
slide.
C
So
we
propose
a
minor
change
to
the
error
message
where
we
introduce
an
error
code
which
is
an
int
and
an
error
message
content
depending
on
the
code,
and
we
propose
to
make
an
iana
register,
but
only
mandate
initially
at
least
two
error
codes,
one
for
an
unspecified
error
and
one
which
could
I
could
build,
let's
say,
number
zero
and
with
the
diagnostic
message
and
one
for
the
selected
cypher
suite
not
supported
the
error
which
we
described
carefully
today,
which
also
includes
the
sweet,
the
sweet
supported
by
the
responder
and
potentially
also
define
an
application,
dependent
error.
C
So
that's
where
we
are
today
and
now
I
I
talked
a
lot.
Please
comment:
what's
your
view?
Is
this
good
enough?
Do
you
want
something
else.
B
B
Which
is
in
terms
of
security,
in
my
understanding
of
and
in
terms
of
the
revealing
the
information
to
the
attacker,
the
best
but
in
terms
of
diagnostics
and
debugging
would
leave
many
implement
many
options
to
the
implementers
to
decide
what
they
want
to
implement.
This
correct.
F
C
Yes,
so
we
could
add
a
code
for
that
as
well.
That's
that's
correct.
Thank
you
for
reminding
me
so
that
should
be
added.
I
I
don't
really
see
I
mean,
then
again,
I
don't
really
see
yeah
we.
I
thought
that
was
a
good
good
comment,
but
I
didn't
see
the
actionable
part
of
that.
So
I
think
that
was
somehow
contradicting
the
actionable
part
and
what
what
there
are
if
it's
success,
then
you
would
use
that
for
with
a
normal
message.
I
suppose.
E
Go
ahead
right,
my
understanding-
and
this
is
of
course
second
or
third
hand,
but
my
understanding
was
that
it's
very
useful
to
be
able
to
have
like
a
single
data
structure
element
in
your
application.
E
C
E
C
Okay,
yeah
we've
been
struggling
with
this
as
you
as
you
hear,
and
I
think
that
if,
if
you're,
okay
with
this-
let's,
let's
take
this
as
a
starting
point
and
when
people
can
provide
actions,
sort
of
actionable
action,
things
that
actions
that
you
could
do
when
you
get.
When
you
get
some
some
other
error,
then
we
add
that
error
to
the
register.
So
I
think
it's
flexible
enough
to
to
change
and
we
could
we
could
add
all
the
I
mean
in
this
allocation.
We
could
add
the
others,
the
other
five.
C
Sorry
other
six,
probably
errors
that
we
have
already
worked
upon.
If
they
are
are
needed
and
if
not
well,
then
applications
has
to
decide
how
to
use
it.
C
So
yeah
here
are
yeah
next
slide,
a
few
of
the
selected
a
few
of
the
issues
we
are
working
on,
the
there
is
a
dependence
along
among
several
of
the
issues,
and
one
thing
that
several
depends
on
is
this
notion
of
applicability
statement?
C
So
I
put
this
first
here,
although
that's
perhaps
not
the
most
urgent.
So,
as
you
recall,
the
applicability
statement
is
a
list
of
parameters
that
needs
to
be
agreed
between
initiate
and
responder
for
a
particular
use
of
ad
hoc,
and
this
this
could
be,
for
example,
how
you
detect
an
ad
hoc
message.
C
C
What
is
the
type
of
identifier
of
the
credential
is
message,
four
used
and
so
on,
and
it
seems
that
so
this
seems
to
be
a
good
start,
but
we
need
to
make
further
clarifications
and
to
address
the
case,
for
example,
that
one
endpoint
support
different
applicability
statements
and
the
reason
why
this
is
needed
is
because
the
ad
hoc
engine
depends
on
being
able
to
associate
a
a
protocol
execution
to
this
applicability
statement,
because
there
are
a
number
of
decisions,
for
example,
for
example,
the
message
format
and
other
things.
C
C
C
So
here's
one
one
case
where
this
is
useful,
so
assuming
that
we
have
this
applicability
statement
in
place,
so
the
question
has
been
around
what
how
do
we
distinguish
received
messages
and
the
proposal
for
changing
message?
One,
and
the
reason
is
that
currently
we
we're,
as
you
know,
try
to
minimize
the
number
of
bytes
sent.
E
C
In
in
the
received
message,
and
when
you
process
that,
then
you
can
you
process
that,
according
to
the
security
context,
so
you
know
which
message
field
you
expect,
and
then
you
get
either
an
error
or
you
get
a
success
so
that
type
of
processing
we
think
is
that
is
missing
and
we
think
we
need
to
be
clarified
better,
and
so
that
should
lead
to
this
to
more
simpler
ways
to
disambiguate
to
distinguish
the
different
messages
just
to
be
clear
here.
C
There
should
be
no
need
to
a
priori
restrict
the
connection
identifiers
to
certain
spaces,
not
even
if
the
endpoint
is
initiated
and
responded
in
multiple
connections,
and
there
should
not
not
be
any
need
to
parse
the
entire
message
to
retrieve
the
context,
and
it
should
work
for
for
all
messages,
including
the
error
message.
So
next
slide
no
next
slide
piece.
C
So
this
is
the
result
of
the
discussion.
So,
in
addition
to
this,
the
clarification
of
that
you
need
to
have
the
applicability
statement
available
to
be
able
to
distinguish
to
understand
what
what
is
the
message
format.
For
example,
we
also
propose
to
add
one
byte
to
message
one,
and
this
is
to
to
simplify.
We
can
disambiguate
with
the
current
messages,
but
we
wanted
that
to
be
more
simple,
simplified
and
more
robust,
and
that
would
be
adding
a
null
byte
seaborn
null.
C
This
is
only
needed
for
message,
one
because
all
the
other
messages
have
a
connection
identifier
and
by
the
applicability
statement.
You
know
whether
it's
present
or
not,
so
that
that
would
be
the
simple
distinction
and
yeah.
So
this
is
a
result
of
a
long
discussion.
I
don't
know
if
this,
if
there
are
any
other
comments
on
this,
otherwise
we
just
add
it
and
everyone
all
the
implementer
seems
to
be
happy
with
this
change
anyway.
C
C
Here
are
a
couple
of
slides
on
message.
Four.
C
So,
as
you
remember
message,
four
was
introduced
for
for
key
confirmation
in
the
cases
where
the
responder,
where
the
initiator
does
not
receive
any
message
from
the
responder,
and
this
is
basically
a
a
mac
over
a
transaction
hash,
a
transcript,
transcript,
hash,
sorry
and
that
now
there's
been
a
request
from
from
one
of
the
implementers
to
support
auxiliary
data
message.
For
so
that's
the
reason
for
that
is
they
had
some
use
case
where
they
wanted
to
provide
a
response
for
data
provided
in
in
message.
C
C
C
So
what
we
the
actual
text
about
key
confirmation-
or
it
is
like
this-
it
says
that
in
deployments,
where
no
protected
application
message
is
sent
from
responder
to
the
initiator,
the
responder
must
send
message
for,
and
then
there
has
been
a
number
of
questions
about
what,
if
not-
and
in
this
case,
what,
if
message,
four
not
reaches
the
initiator,
for
example,
a
lost
co-op
non-confirmable
and
then
the
lower
layers
may
in
initiate
the
resending.
And
how
does
the
responder
then
act
to
another
message?
C
Three,
and
we
could
make
it
simple
for
ourselves
and
say
that.
Well
we
assume
that
the
duplication
will
handle
this,
and
this
will
never
happen
or
that
the
lower
layers
will
I
mean
the
lower
layers
will
take
care
of
it.
C
But
it
turns
out
that
not
all
co-op
implementations
support
deduplication,
because
it's
it's
a
complication
for
constrained
implementations
and
then
there
is.
It
was
a
newly
proposal
recently
a
proposal
and
that's
issued
85
on
stating
item
potency.
C
C
So
christian,
do
you
want
to
say
something
about
this?
Did
I
represent
your
proposal.
J
C
Hello,
can
you
hear
me?
Yes,
yes,
we
heard
it
well.
Oh
sorry,
yeah
something
was
wrong
on
my
side,
I
I'm
echoing
says
christian.
Am
I
still.
B
C
Okay,
so
christian
is
happy
with
my
my
my
statement.
I
can
ask
if
there
are
questions
and
the
question
from
stephen,
why
would
a
why
would
ad
in
message
4
be
conflicting.
F
I
think
yeah
auxiliary
data-
and
I
said
four-
is
not
different
than
auxiliary
data
in
the
other
messages,
but
I
think
formulating
this.
The
correct
way
is
this:
I
ident
potency
is
probably
will
take
a
while,
and
probably
we
need
christian
here
to
to
help
to
formulate
what
is
actually
required
here.
I
think
there's,
no,
we
don't
intend
to
change
any
security
aspects
at
all,
but
it's
to
make
sure
that
it's
easy
to
implement
on
constrained
devices.
A
Yeah
so
I
mean
basically
I
I
just
have
a
concern
that
you
know
if
you
look
at
the
web
and
http
get
it
supposedly
is
item
potent
but
reality
is
different.
So
that's
just
a
concern
that
if
we
assume
item
potency
it
might
not
be,
it
might
not
match
reality.
Well,.
F
F
Maybe
in
the
end
we
will
not
use
the
word
item
potent
but
write
something
else.
I
think
whatever
we
write
should
be
correct,
but
I
think
we
are
not.
This
was
suggested
by
christian
last
week
or
this
week
yeah
last
week,
so
I
don't
think
anybody
has
thought
about
the
details
that
much
maybe
christian.
A
A
K
So
I
think
this
is
better
addressed
by
placing
strict
bounds
on
what
we
can
have
in
the
ad
than
by
requiring
that
everything
be
handled
on
the
lower
layers,
because
the
lower
layers
we
have
planned
for
this
typically
do
not
cannot
do.
This
cannot
perform
the
deduplication
that
would
be
needed
and
would
thus
let
the
protocol
run
out
of.
C
Sync,
okay,
so
so
we
need
to
definitely
specify
this
carefully
and
make
sure
that
it
doesn't
create
these
type
of
effects,
or
else
we
need
to
yeah.
I
mean
that's.
Basically,
we
have
something
we
need
to
to
work
on
any
any
other
comments.
What
this?
Let's
not
call
it
safe.
Yes,
that's
agreed
ben.
Anyone
wants
to
comment
on
that.
F
Comment
from
me,
you're
on
a
there's,
a
lot
of
talk
application
data,
but
I
think
we
have
said
that
80
is
not
application
data.
It's
auxiliary
data
yeah.
B
Yeah,
I
guess
the
point
here
is
that
we
have
no
control
over
what
we
carry
in
the
auxiliary
data
and
that
we
cannot
guarantee
either
possibility
on.
F
C
C
L
Hi
yeah,
I
mean
stephen-
gave
the
example
earlier
that
this
this
might
be
an
instruction
to
a
light
switch
say,
which
obviously
is
an
end
point
with.
I
don't
know.
In
most
cases,
binary
state
yeah,
so
in
potency,
really
makes
some
kind
of
sense
there,
but
I
think,
given
that
you
don't
know
whether
this
is
going
to
be
used
for
that
kind
of
binary,
toggle
or
for
other
kinds
of
application.
L
C
B
C
D
C
The
previous
slide
was
not
strictly
message
four,
but
it
was
not
initiated
by
the
message
for
discussion.
This
is
also
related
to
message
four,
but
this
is
instead
on
the
initiate
sorry
on
the
initiator
side.
C
It's
the
applicability
statement
that
states
that
we
should
use
message
four
or
that
we
should
get
key
confirmation
in
some
some
other
way
and
what
what
should
the
initiator
do
when,
if
not
receiving
key
confirmation-
and
that's
I
mean
this-
is
basically
to
the
border
line
of
transport-
the
transport
issue,
but
it's
it's.
We
still
need
to
have
a
have
an
answer
and
we
cannot
in
general
say,
for
I
mean
the
questions
in
this
issue.
Are
things
like
for
how
long
shall
it
retransmit?
C
When
shall
it
clear
the
security
context,
and
I
think
we
should
need
to
be
clear
that
in
general,
edo
cannot
answer
those
questions.
This
needs
to
be
application
input
and
we
have
so
we
need.
We
need
to
make
this
clear
somehow-
and
this
is
sort
of
I
think
the
result
of
these
issues
will
be
some
additional
clarifications.
C
It's
just
one
thing
to
note
that
the
key
confirmation
really
coincides
more
or
less
with
reachability
here
that,
if,
if
the
initiator
can
verify
the
protected
message,
it
means
that
the
message
has
reached
the
other
end
point
and
the
right
key
was
used
by
the
responder
so
and
vice
versa.
So
it's
essentially
as
long
as
the
message
has
not
arrived,
the
initiative
cannot
really
tell
either
and
the
current
text
is
then
saying
that.
M
C
C
That,
yes,
it
might
be
that
ad
hoc
has
has
completed
successfully,
but
but
the
initiator
has
not
received
the
final,
a
key
confirmation.
What
and
the
actions
is
basically
based
on
on
on
what
what
is
expected
from
the
application?
C
H
C
Yeah
or
if
that
is
some
something
something
more
application,
I
don't
know
if
that
is
the
part
of
the
application
statement,
but
that's
one
way
of
solving
it:
okay,
okay,
thanks
marco,
for
the
input,
I
just
wanted
to
check
if
anyone
has
a
better
idea.
Otherwise
we
try
to
clarify
things
in
the
way
I
proposed
here.
C
So
please
move
on
to
the
next
slide,
and
now
it's
a
couple
of
slides
on
on
test
vectors,
so
there's
been
requested
to
have
test
vectors
in
json
and
that's
already
used
by
by
inria,
and
I
was
going
to
ask
who
will
be
involved
in
making
a
template
and
then
timothy
already
sent
some
something
today
I
haven't
looked
at
it.
Could
you
please
tell
me
what
you've
done
timothy.
I
Yes,
can
you
hear
me?
Yes,
okay,
great
yeah,
I've
just
uploaded
in
a
comment
what
I've
done
so
far,
so
I've
just
put
all
the
test
vectors
and
from
the
test
factor
file
and
adjacent
format.
I
Where
I
have
three
keys,
I
have
an
initiator
key,
a
shared
key
and
a
responder
key,
and
basically,
all
the
all
the
messages
or
all
the
computational
values
that
are
being
computed
by
both
sides
are
structured
under
the
shared
key
and
the
json
map
and
the
inputs
that
are
really
specific
to
the
initiator
or
the
responder
are
under
those
keys
in
the
into
json
the
json
map.
But
it's
probably
clear:
if
you
just
have
a
look
at
the
at
the
file
I've
shared
and
the
in
the
issue,
then
we
want
to
explain.
C
I
I
I
think
it
can
be
done
for
all
the
test
factors.
I've
been
using
this
type
of
template
for
for
the
different
dust
vectors
that
are
in
the
test
vector
file.
So
I
don't
really
see
any
issues
with
the
different
types
of
authentication
methods
or
different
types
of
of
of
cypher
suites.
I
guess
the
only
thing
we
need
to
be
clear
about
is
the
name
of
different
names
of
the
keys
in
the
json
map,
so
it's
easy
for
people
to
parse
it,
but
otherwise
I
don't
see
any
issue.
C
Good
thanks
very
much
for
this,
so
so
then
I
propose
that
we
actually
start
using
those
and
and
so
what
we
have.
We
have
had
a
problem
with
actually
creating
we'll
come
to
that
in
the
next
slide
to
spend
more
times
on
test
vector.
So
we
are
we're
happy
if
anyone
else
wants
to
be
involved
and-
and
this
is
an
excellent
input
here,
so
we
should
go
in
this
direction
and
and
yes
thank
you
very
much
for
your
input,
I
think
I
hear
someone
typing
its
probability
more
next
slide.
Please.
C
Another
slide
on
test
vectors,
so,
as
I
mentioned,
this
is
mainly
the
work
done
by
john
on
on
test
vectors
started
off
with
francesca
and
then
john,
and
we
realized
now
that
the
most
wanted
parts
here
is
to
to
add
real
certificates
and
also
new
cypher
suites,
and
that
is
actually
the
what
is
also
most
consuming
here.
C
So
again,
we'd
like
to
ask
if
anyone
is
interested
in
in
helping
out
and
provide
the
first
run
of
either
with
certs
or
with
suite
two
and
three
two
or
three,
in
which
case
we
could
have
that
as
the
starting
point,
and
then
we
can
make
interrupt
tests
and
then
we
can
augment
them
to
two
test
vectors
once
they
have
been
verified.
C
So
the
the
easy,
the
the
three
sub
bullets
here
at
the
bottom.
We
we
think
we
can
provide
but
we'd
like
to
have
some
help
with
with
the
two
bullets
which
are
still
unticked.
Anyone
that
is
interested
in
helping
out.
H
C
Who
did
cyphers
with
three?
Was
that
michelle,
or
or
who
was
working
on.
H
I
C
Okay,
good,
but
great
great
input,
marco,
so
we'll
we'll
try
to
make
use
of
of
of
the
results
of
last
week's
hackathon
and
and
pulled
this
together
to
another
test
suite
what
about
certificates?
Is
there
anyone?
C
I
think
that
stefan
made
some
certificate
wrong.
He
said
he
was
interested
in
this
difficult
run.
I
don't
know
if
he
is
stefan
rusty,
so
he's
not
in
the
meeting.
I
I
don't
see
him
here.
C
Okay.
This
was
just
an
open
call,
see
if
there
are
people
available
that
wants
to
want
to
to
help
here.
How
do
we
use
the
json
format
now
can?
Can
we
copy
it
over
directly
to
json,
or
is
anyone
interested
in
helping
out
with
that.
I
Okay,
copying
to
the
json
format.
If
we
agree
on
the
format
of
the
json
file.
C
Oh,
that's
excellent!
Thank
you
very
much
so
so
we'll.
What
we'll
do
is
that
we'll
have
a
look
at
your
your
template.
We
have
a
discussion
either
yeah,
perhaps
on
the
mailing
list,
and
then
we
agree
on
that
one
and
then
it's
great
that
you
could
help
us
to
copy
over
the
text
files
and
then
we'll
we'll
start
filling
in
in
the
json
format.
Excellent.
Thank
you
very
much.
Next
slide.
B
So
I
just
have
a
clarifying
question
on
this
slide
related
to
the
cyber
native
certificate.
Could
you
update
us
on
the
status
of
this
draft?
Is
this?
Is
a
draft
standardizing
cozy
right.
F
Yeah
yeah,
so
that's
correct,
it's
in
version
eight
or
something
now
there
has
been
a
lot
of
discussion
in
cosy,
so
this
has
not
been
working
group
adopted
yet
because
the
charter
needs
to
change.
There
have
been
several
requests
from
non-authors
to
from
several
different
non-authors
to
working
group
adoptes,
and
several
of
the
codes
in
the
reams
have
been
completely
taken
by
this
seaboard
certificate.
F
Right
now,
but
I
think
it's
it's
moving
ahead
quite
well,
but
it's
it's
probably
a
bit
off
behind
ad
hoc
in
maturity
yeah,
but
it's
I
think
it's
starting
to
be
quite
stable.
D
E
I
I'm
the
ad
for
both
lake
and
cozy,
so
cozy
is
currently
in
the
rechartering
process.
So
there's
going
to
be
two
rounds
of
isg
review
and
there's
a
public
last
call
period
in
between
the
two
and
so
we're
currently
doing
the
first
round
the
internal
review
with
isg
and
iab
for
the
new
cozy
charter.
That
will
allow
us
to
work
on
the
compressed
certificates.
E
But
I
don't
know
of
any
obstacles
to
us
doing
that.
B
C
Just
a
final
comment
from
my
side
on
on
the
certificate,
so
there
was
actually
two
implementers
requesting
certificates,
as
I
remember
steve,
stefan
requested
cbor
certificates
and
peter
requested
ordinary,
dar
encoded
certificates.
So
there
is
actually
a
request
for
both,
but
we'll
we'll
see
what
what
people
can
provide
here
and
help
out
with,
but
eventually
we
should
have
a
both
okay.
Sorry,
next.
C
Slide:
okay,
how
are
we
time-wise?
I
think
there
are
two
slides
left
essentially
of
the
main
slide.
We.
C
We
are
good
on
time,
okay,
good,
so
here
is
another
pretty
specific
issue,
but
still
still
might
be
worth
having.
I
mean
open
up
for
a
discussion
if
there
is
anyone
that
has
a
a
opinion.
C
So
so,
as
you
as
you
remember,
there
is
this
by-string
identifier
type
defined
in
ad
hoc
to
make
a
compact
encoding
of
short
byte
strings
and
relying
on
the
the
use
of
seabor
ins,
which
can
be
only
one
byte
long,
but
it
needs
to
be
mapped
back
to
a
byte
string,
since
this
is
used
for
connection
identifiers
and
connection
identifiers
are
used
as
oscar
sender
ids,
which
are
byte
strings.
C
C
One
is
to
to
use
the
same
trick
for
efficient
coding
of
longer
byte
strings,
so
not
only
one
byte
zebra
objects,
but
two
by
zero
objects
as
well,
and
since
we
anyway
have
a
mapping
step
that
that
wouldn't
necessarily
make
this
more
complicated.
C
Although
this,
this
is
a
origin
or
already
a
complication,
and
the
second
idea,
which
is
kind
of
independent,
I
think,
is
that
we
would
decouple
the
ad
hoc
type
from
from
the
oscar
sender
ide
in
the
sense
that
we
would
allow
adult
to
just
use
either
in
or
or
byte
strings
and
then
make
the
mapping
at
the
point
when,
when
we
do
the
rest
of
the
oscar
context,
establishment,
which
would
then
be
more
more
flexible
in
an
ad
hoc
and
and
simply
in
the
adult
setting
but
complicate
things
when
you,
when
you
do
the
mapping
tool
score,
I
mean
you're
just
pushing
the
problem,
but
but
they
would
maybe
be
simpler
in
the
ad
hoc
setting.
C
So
so
that
was,
that
was,
if
I
understand
the
proposal
christian,
do
you
want
to
add
something.
F
C
C
This
was
this
is
the
final
slide,
where
I
sort
of
highlight
issues,
and
then
there
is
this.
There
is
a
last
slide
on
on
some
some
other
open
issues,
but
this
slide
is
on
the
mandatory
mandatory
to
implement
cypher
suite,
which
we
have
been
discussed
for
quite
some
time.
But
it's
still
a
final
comment
here,
which
we,
I
think
we
should
just
bring
up.
C
So
if
you
remember
the
outcome
of
the
previous
discussion,
we,
which
was
basically
the
problem
with
supporting
both
ecdsa
and
eddsa
in
constrained
endpoints
and
the
result
of
that
discussion
was
that
we
said
that
the
constraint
endpoint
should
implement
either
sweet
0
or
sweet
2,
corresponding
to
eddsa
or
ecdsa
respectively,
whereas
less
constrained
devices
should
implement
both
and
now
malicia
had
a
comment.
Why
it's
sort
of
reiterating?
Why
again
did
we
not
mandate
sweet
too?
C
The
previous
considerations,
maybe
at
least
when
it
comes
to
performance,
were
probably
not
not
accurate,
so
processing,
time,
code,
footprint
and
message
overhead
is
is
not
is
more
advantageous
from
from
an
ecd
sa
point
of
view
according
to
militia.
Maybe
you
want
to
add
something
here:
malisha.
B
So
yeah,
maybe
just
a
general
remark
when
I
was
going
through
this
issue.
My
feeling
was
that
people
were
mostly
giving
preferences
not
really
based
on
technical
arguments
behind
their
preference.
B
So
I
was
trying
to
steer
up
the
discussion
in
the
direction
of
really
discussing
the
details
of
both
aspects
that
both
performance
and
security.
B
So
my
argumentation
was
related
to
these
three
points
that
you
can
see
on
the
slide
so
processing
time
code
footprint
where
ecdsa
is
seems
to
be
favored
over
edsa,
and
I
was
asking
for
more
input
on
specific
attacks
and
where
how
do
those
attacks
on
ecdsa
reflect
on
start
on
constrained
devices
and
the
hardware
accelerators
that
are
typically
present
on
those.
C
So
yeah,
yes,
you
are
yes,
I
hear
you
so
that
yeah
great,
thank
you
and
I
well.
I
mean
for
my
from
from
my
understanding.
We
we
had
a
discussion
about
security
properties.
Maybe
john
can
fill
in
exactly
what
was
what
was
the
reason,
but
but
I
I
also
remember
the
different.
C
I
mean
having
talked
to
different
implementers
and
different
companies
here
and,
and
there
is
a
clear
preference
for
eddsa
in
certain
settings
and
what
that
is
based
on.
I
I'm
not
I
mean.
There's
obviously
is
I
mean
initially,
there
was
at
least
the
security
and
performance
argument.
I
don't
know
exactly
what
what
is
the
state
of
matters.
B
So
that
was
precisely
my
point:
I've
seen
preference
being
given
on
the
on
the
thread,
but
not
exactly
technical
argumentation
behind
that
preference,
and
I
would
really
like
to
understand
if
these
are.
I
would
like
to
avoid
having
religious
kind
of
preferences
and
really
focus
on
the
technical
ones,
and
that's
the
reason
why
I
jumped
into
this
discussion
trying
to
steer
it
in
this
way.
Stephen
did
you
want
to
say.
A
Something
yes,
so
I
mean,
I
think,
I'm
not
sure
religion
is
available
here.
It's
not
really
a
religion,
it's
more
what
tools
are
available,
but
what
I
really
want
johnny
cube
to
say
was,
I
think,
at
the
interim.
We
had
back
in
january.
A
Renee
stroke
raised
this
issue
again
and
if
I
remember
the
red
you
know,
the
discussion
was
that
we
were
going
to
have
a
discussion
on
the
mailing
list
about
this.
I
can't
remember
if
renee
was
supposed
to
start
it
or
if
we
were
supposed
to
start
it
as
chairs,
but
we
didn't
have
it.
B
A
Right
so
I
guess
the
bet
yeah
probably
better,
is
that
we
take
the
action
as
chairs
to
kick
that
discussion
off.
Maybe
it
was
just
ambiguous
as
to
whether
it
was
renee
or
us
who
were
supposed
to
do
it
last
time.
So
that's
all
that's
what
I
wanted
to
say.
We
should
start
that
next
week
or
something
sounds
good.
A
F
Yes,
following,
I
think
some
of
the
companies
wanting
to
have
eddsa
express
that
offline
and
not
on
the
github.
So,
but
I
think,
depending
on
what
architect
you
have,
there
is
definitely
if
you
have
hardware
acceleration
for
easy
dsa
that
is
faster.
If
you
don't
have
that,
then
probably
eddsa
is
much
faster
in
at
least
in
some
implementation
seems
quite
tricky
to
compare
renee
stating
that
ecdsa
with
the
random
random
noms
is
much
more
secure
and
then
there's
definitely
security
properties
with
eddsa,
which
is
much
nicer.
It's
much
harder
to
make
something
wrong.
F
B
Okay,
thank
you.
So
could
I
ask
you
to
to
send
an
email
to
the
mailing
list
summarizing
these
arguments
that
you
just
mentioned
in
an
attempt
to
restart
this
discussion
to
converge
on
it.
B
B
B
Okay,
so
jordan,
do
you
have
any
more
slides
yeah?
Do
you
think
there
was.
C
Something
I'm
reading
the
issues.
Sorry,
I'm
reading
the
comments
on
in
the
in
the
jabber
here.
C
So
there's
a
question
about
the
type
I
don't
know.
If
there's
a
typo
here
this,
I
think
this
is
and
then
there's
a
question
about
a
used
for
threshold.
Yes,
that
was
what
I
think
that
was
what
john
stated.
Is
there
some
confusion
about
that.
C
M
M
First
of
all,
I
wondered
if
that
was
that
was
a
typo
for
edd
sa,
so
I
can
imagine
it
has
a
negative
if
you
go
to
edd
sa
it
has
negative
consequences
and
performance,
because
it's
not
on
hardware,
but
I
can't
understand
ecdsa
has
negative
consequences
on
performance,
since
it's
usually
in
hardware,
as
the
next
point
makes
in
la,
but
the
security
people
have
suspicion
about
certain
curves.
So
I'm
I'm
is
that
what
part
of
that
comment
is
based
on?
I
just
maybe
we
could
have
some.
B
So
maybe
I
can
quantify,
maybe
I
can
clarify
so
this
was
precisely
the
comment.
The
first
comment
describing
the
issue
that
I
reacted
to
regarding
the
performance
of
ecdsa,
because
it
seemed
to
be
like
an
underlying
argument
that
edds
safer
is
both
performed
better
and
is
more
secure,
which
is
I
brought
this
up
again
so.
B
Edwards,
that's
yes,
that
the
adwords
ed
dsa
that
performs
better
and
has
has
better
security.
So
in
response
to
that,
I
I
restarted
the
thread
on
github,
giving
the
arguments
on
performance
and
essentially.
B
The
threads
saying
that
I
mean
most
summarizing
that,
since
most
of
the
devices
have
hardware
acceleration
for
ecdsa
the
performance,
the
the
statement
on
performance
does
not
hold.
So
this
is
just
a
quote
of
the
old
of
the
old
previous
consideration
that
that
yaran
noted
and
then
as
to
the
security
aspects.
My
understanding
is
that
I
mean
there
are
speculations
on
on
the
security
of
the
underlying
curve
of
the
ecdsa,
the
the
nist
curves,
but
the
to
my
understanding.
B
These
are
still
speculation
and
there
are
attacks
to
my
knowledge,
mostly
implementation,
attacks
on
the
ecdsa
signature
algorithm,
which
we
might
or
might
not
be
concerned
with.
So
I
was
trying
to
point
the
the
discussion
in
the
direction
of
understanding
better
those
attacks
of
ecdsa
for
the
devices
that
we
target.
B
Yes,
that
is
correct,
and
there
is
a
draft
that
is
led
by
rene.
That
explains
how
to
do
it:
how
to
represent
the
edwards
curve
in
virus,
transform,
if
I'm
not
mistaken,
and
implement
and
accelerate
it
with
these
genetic
accelerators
that
provide
genetic
parameters
for
the
for
the
virus
transform.
But
this
is
not
widely
available.
M
B
Okay-
I
guess
not
so
yes,
so
I
propose
we
move
move
on
with
this
on
the
mailing
list,
because
it
is
an
important
issue
that
we
should
carefully
discuss
and
having
the
mdr
in
the
archives.
B
B
No,
I
hear
none,
you
don't
do
you
want
to
move
on.
Yes,.
C
We
can
briefly
talk
about
these
if,
if
we
have
the
time
or
we
don't
have
anything
else,
we'd
like
to
bring
up,
I
think
that
we've
gone
through
the
main
issues
already
now
so,
and
I
think
we
have
good
way
forward
for
for
those
so
yeah,
I'm
optimistic
that
we
can
close
a
lot
of
a
lot
of
issues
in
the
next
period
here,
but
there
are
there's
been
raised,
some
some
new
ideas
and
new
issues,
and
there
is
also
some
old
ones
which
we
want
to
fix.
C
So
one
is
related
to
opportunistic
use
case
the
opportunistic
use
of
of
ad
hoc.
I
didn't
bring
up
the
issue
here.
Do
you
want
to
elaborate
on
that
christian.
K
F
I
think
there's
been
similar
comments
offline
from
a
company
wanting
to
use
ad
hoc
with
raw
public
key
by
value.
So
basically
optimistic
you,
you
don't
authenticate
the
first
time
like
ssh,
you
send
the
keys
first
time
and
then
you,
the
second
third
time
you
and
all
the
for
the
future
times.
You
verify
that
you
have
the
same
talking
to
the
same
device
that
you
talked
first
time
so
there's
there's.
K
Mentioned
with
sending
the
raw
public
key
by
value,
that's
what
ssh
would
do
and
that's
that
this
is
clearly
a
value
and
might
and
would
also
apply
for
the
application
to
resource
directory
where
devices.
I
have
this
key,
and
let
me
in
again,
if
I
can
buy
this
team,
but
something
that
a
device
could
also
do.
K
Is
I'm
nobody
and
don't
even
try
to
remember,
be
me
because
next
time
I'll
be
using
a
different
primary
key
and
won't
say
anything
and
for
those
cases
it
would
be
more
interesting
to
not
send
an
additional
raw
public
key
at
all,
but
explore
whether
it's
my
suffice
to
just
use
the
the
ephemeral
key
and
not
use
anything
in
addition
and
whether
that
fmel
key,
that's
already
being
sent,
can
also
be
used
to
do
this
kind
of
non-authentication.
To
just
say
I'm
this
entity,
but
nothing
more.
B
So
to
me
this
is
a
bit
extending
the
scope
that
we
agreed
on
in
the
requirements
draft,
where
I
think
we
explicitly
agreed
on
tackling
a
mutually
authenticated
case
explicitly.
B
So
I
don't
have
anything
against
extending
that
scope,
but
this
this
should
be
discussed
in
detail.
A
K
A
B
A
So
that
that
is
what
I
was
referring
to
yeah
right
and
that
was
kind
of
hard
one
now
it
just
happens
that
all
of
the
people
who
might
argue
deeply
about
that
happen
to
be
off
in
the
deprived
working
group
now
arguing
deeply
about
deprived.
But
again,
if
we
bring
this
up
again,
we
may
end
up
with
a
large
discussion,
so
it'd
be
a
little
bit.
I
think
about
it
ahead
of
time.
First.
F
C
Yeah,
I
I
if
I
make,
I
think
I
mean
if
you
look
at
the
two
cases
that
christian
outlined
here,
I
think
the
the
the
passing
passing
publicly
by
value.
That
seems
to
be
well
founded
and
that's
that's
issue
82,
actually
that
we
like
to
have
a
cozy
header
map
for
public
key,
because
that's
not
there
is
no.
C
No,
there
is
no
header
map
actually
defined
for
that,
but
the
other
case,
where
you
actually
you're
you're,
not
sending
a
key
and
just
reusing
in
a
female
I
mean
you're
using.
That
seems
a
little
bit
more
speculative
in
my
mind,
so
I
I
would
like
to
keep
half
of
the
this
case
here,
but
but
perhaps
not
everything
in
this
issue.
C
And
there's
some
ongoing
yeah
okay,
so
that's
just
michael
and
christian,
then
next
deterministic
seaborn
encoding
john.
Do
you
want
to
say
something
about
that.
F
Yeah,
so
this
was
brought
up
in
a
discussion
with
a
company
implementing
this
and
they
started
ask
question
about
the
terminus
and
we
thought
I
opened
an
issue.
I
think
we
should
go
through
the
protocol
and
see
if
there
are
any
places
where
things
are
not
deterministic.
I
think,
for
example,
the
integers
are
probably
not
specified
currently
that
they
are
encoded
in
the
smallest
possible
way,
even
if
that
was
the
intention
when
we
wrote
the
draft-
and
I
don't
think
sieber
forces
you
to
do
that
by
default.
F
F
B
Yeah,
so
I'm
not
aware
of
those
details,
it
would
be
maybe
good
to
have
someone
on
the.
If
there's
someone
who
is
familiar
with
seaboard
details,
comment
on
this,
we
have
michael.
M
Hi,
michael
richardson,
so
seaborg
does
your
you're,
absolutely
right.
John
seaboard
doesn't
say
this.
It
actually
says
that
it's
up
to
us
as
a
seaboard
protocol
that
we
need
to
specify
this.
I
guess
there's
two
issues.
I
think
with
these
integers
one
is
that
it's
stupid
to
take
more
bytes
than
you
need
to.
M
However,
that's
a
a
that's,
a
sender,
stupidity,
okay,
and
if
they
wish
to
shoot
themselves
in
the
foot,
then
I
think
that's
okay,
but
we
just
have
the
signature
verification
issue
and
then
I
think
that
we
need
to
specify
that
you,
you,
you
sign
and
verify
what
you
what's
on
the
wire,
not
what
you
reconstructed
so
that
gets
rid
of
any
canonization
issues
and
and
then
we
need
to
simply
say
what
you
just
said:
that
that
integers
are
always
encoded
in
the
shortest
or
should
be
encoded
in
the
shortest
value
possible,
and-
and
that's
our
business,
our
at
our
it's
on
us
to
do
this
as
a
user
of
seabor
and
any
other
things
that
we
want
to
say,
like
you
know
such
and
such
can't
be
a
map.
F
Yeah,
I
agree,
I
think,
there's
a
might
be
security
aspects
of
having
a
signal
encoding.
Also,
I
don't
see
any
direct
attack,
but
if
in
protocols
where
you
have
a
weakness,
then
it's
bad
if
an
attacker
can
have
a
lot
of
different
choices,
how
to
choose
things
so
typically,
you
want
deterministic
encoding
and
security
protocols.
B
Yeah,
so
I
think
that's
a
that's
a
good
point
and
ben
commented
in
the
chat
giving
a
pointer
to
the
draft
that
takes
rules
from
rfc
189
49,
which
is
receiver.
I.
B
C
C
F
C
F
Yeah
so
right,
I
guess
some
background
also,
but
right
now,
the
way
you
can
identify
a
certificate
in
cosi
is
either
by
sending
it
with
by
value
or
with
a
uri
or
with
a
hash
and
hash
takes.
Eight
bytes
has
been
suggested
both
discussed
in
both
lake
and
in
cosi
recently
that
it
would
be
good
to
be
able
to
identify
a
certificate
with
a
kid.
F
Currently
you,
you,
cosi,
doesn't
really
forbid
it,
but
it
doesn't
specify
how
either
I
would
say
it's
you
have
to
do
it
yourself
and
assign
a
kid
to
a
certificate
and
do
it.
I
think
kosovo
discussed
this
recently
and
there
seemed
to
be
agreement
that
this
might
be
good,
but
not
exactly
how
how
to
do
that.
I
think
that
is
discussion.
It
has
not
been
any
more
discussion,
then.
B
So
I
remember
having
the
discussion
in
lake
and
I
believe
the
comment
from
michael
was
that
I
mean
with
this
with
this
proposal.
Essentially
we
are,
we
are
making
certificates
a
sort
of
pro
public
key
and
from
what.
B
He
did
not
see
much
value
in
that,
michael.
Maybe
you
can
confirm
if
you're
online
do
we
have
a
use
case
where
the
where
that
would
what
this
would
be
useful.
B
So
I
was
recalling
a
discussion
in
a
lake
on
the
proposal
to
reference
a
certificate
with
the
key
id
where
I
remember
you
objecting
to
this
change,
essentially
saying
that
this
makes
the
certificate
a
sort
of
federal
public
key.
B
M
M
If,
if
the
endpoint,
the
other
end
can't
identify
can't
validate
the
certificate,
then
it's
just
a
container
for
a
raw
public
key.
Yes,
I
would
agree
with
that
statement,
but
I
think
I
need
more
context
for
what,
when
we,
when
we're,
why
we
are
going
to
do
that,
but
I
guess
I'll
just
repeat
that
yeah,
so
why
send
the
whole
certificate?
If
you
can't
validate
it?
I
guess
the
point.
F
Either,
to
save
bytes
or
to
not
have
to
extend
cozy
key
with
subject
name
to
comply
with
sigma,
I
would
say:
use
a
raw
public
keys
without
identify
might
not
be
100
compliant
with
the
sigma
academic
paper,
but
I
think
that
could
also
be
done
after
the.
I
agree
with
michael
that
there's
an
overlap
with
the
raw
public
key,
and
I
think
I'm
not
saying
we
should
do
this,
but
I
think
it
should
be
discussed
after
the
late
discussion.
F
This
was
discussed
in
cozy
with
several
persons
includes
it
was
so
yes,
I
don't
remember
who
suggested
it
kusi
not
me.
I
don't
know
if
it
was
for
an
ad
hoc
use
case
at
all,
and
there
were
several
people
in
cosi,
seeming
positive
to
the
idea
and
closely
discussed
how
to
do
this
without
reaching
any
agreement.
B
Waiting
for
kusi
to
do
this,
okay,
so
I
guess
in
the
context
of
this
discussion
we
would
as
a
working
group
we
would
need
a
little
bit
more
context,
and
I
guess
this
wasn't.
This
was
just
a
hint
to
what
could
be
discussed
if
there
was
time-
and
it
is
indeed
the
case,
so
I
propose
that
we
keep
this
issue
open
and
maybe
present
it
in
more
detail
during
one
of
the
next
meetings
of
link.
B
C
Think
yep,
I
think
we
reached
the
end
the
list
of
of
the
of
the
hard
open
issues
and
then
there
are
other,
perhaps
more
editorial
so
yeah.
I
think
that's
that's
where
we
are
basically
in
in
the
work.
B
Okay,
thank
you.
Thank
you
for
presenting
the
issues
and
leading
the
development
of
this
pacquiao
and
tron
and
francesca.
So
maybe
we
could.
I
think,
that
the
next
item
in
the
agenda
we
have
the
next
steps.
Where
we
have,
I
mean
I
could
maybe
just
summarize
what
we
plan
on
doing
in
the
future
period.
B
So
I
recall
from
the
first
presentation
by
marco
that
we
will
have
an
interrupt
event
in
april
and
where
we
will
be
testing
additional,
implement,
we'll
be
testing
the
implementations.
B
So
please
continue
with
this
work
and
also,
it's
all
great,
to
see
these
reports
coming
to
the
working
group.
This
is
very
useful.
On
the
formal
verification
front.
Timothy
is
leading
the
ad
hoc
c
implementation
that
and
in
collaboration
with
kartik's
team
at
indriya.
This
verification
is
being
formally
verified
for
correctness,
so
that
is
one
one
direction
that
we
are
headed
towards
and
then
the
second
one
is
on
the
formal
analysis
of
the
protocol.
B
What
kartik
mentioned
during
the
last
interim,
where
we
will
hopefully
have
some
updates
for
the
next
meetings
I
will
be
coordinating.
I
will
take
an
action
to
coordinate
with
kartik
on
on
this
work
and
update
the
working
group
as
needed
other
than
that.
Do
we
want
to
organize
interims
in
the
next
period?
Do
you
have
any
proposals.
C
Yeah,
I
think
we
should.
I
mean
interns
are
good.
We
basically
take
it,
take
the
extra
effort
to
prepare
for
the
interim
meeting
and
that
we
close
a
number
of
issues
and
so
on.
So
I
think
that's
that's
a
means
of
progressing
and
it's
also
a
good
feedback
channels
for
for
people
and
people
to
comment
and
and
provide
new
input
and
so
on.
So
yes,
I
think
we
definitely
should
arrange
injury
meetings
should
we
aim
for
one
interim
or
two
interims.
C
B
C
Yes
sounds
good
and
there
is
one
the
interrupt
the
intro
yeah
I
think
mark
was
going
to
say
something
about
the
interrupt.
Sorry
go
ahead.
Marco.
H
Yeah,
I
think,
for
april.
The
second
half
is
ideal
for
sure.
After
that
interop
session
we
take
at
least
we
can
report
about
that,
and
possibly
I
think,
a
bit
of
issues
that
that
can
come
up
after
those
tests.
So
second
half
of
april
round
end
of
april
will
be
ideal.
I
think.
B
Okay,
perfect
so
yeah,
so
a
sheriff
will
take
the
action
to
to
schedule
the
next
interim
for
after
the
the
next
interrupt
event,
and
then
we
will
just.
We
won't.
C
So
there
is
your
run.
Yes,
I
just
wanted
to
say
that
we
are
really
fortunate
about
this.
This
input
process
from
the
implementers
we
don't
have
so
much
input
from
people
or
not
implementing.
So
if
someone
would
interest
just
read
the
specification
or
or
have
some
specific
comments
that
would
be
fantastic,
you
could
either
send
bails
directly
to
the
authors
or
even
better
to
the
lake
mailing
list.
So
yeah
even
more
comments
are,
are
welcome.
C
B
A
D
B
Okay,
so
I
guess
I
guess
that's
it
for
the
late
meeting.
Thank
you
everyone
for
for
attending
today
and
let's
keep
the
discussion
going
on
github
and
on
the
mailing.