►
From YouTube: IETF114 LAKE 20220727 1730
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Great,
I
think
we
marco's
kindly
agree
to
take
note.
So
thank
you,
marco.
We'll
keep
an
eye
on
the
chat
ourselves
as
chairs.
A
Okay.
So
there's
the
note.
Well,
I
guess
you've
seen
this
before
during
the
week,
have
a
quick
read
and
enjoy
it
additionally
we're
as
a
hybrid
meeting.
We
need
to
kind
of
pay
attention
to
remote
people.
So
if,
if
you're
a
remote,
please
keep
your
audio
and
video
muted.
Unless
you
need
to
speak
if
you're
here
and
you
want
to
go
to
the
mic,
please
join
the
queue
if
you
can,
but
we
don't
have
thousands
of
people.
So
that's
it's
probably
quite
manageable,
but
no
harm
no
harm
to
join
the
queue.
A
If
you
can
do
so
before
going
to
the
microphone
and
if
you
go
to
the
microphone,
please
also
state
your
name.
You
need
to
click
onto
the
data
tracker
somewhere
or
scan
the
qr
code,
as
paul
is
doing
in
order
to
sign
into
the
meetings
for
record
keeping.
So
please
do
that
too.
A
So
there's
some
links
in
case.
You
need
to
do
a
bit
of
clicking
and
here's
our
agenda
for
today
so
administrator.
We're
doing
then
we'll
have
mark
we'll
talk
about
some
computational
analysis
as
then
we'll
baptised.
So
the
main
kind
of
goal
of
today's
meeting
is
to
get
this
feedback
from
people.
Who've
been
doing
analysis
of
the
protocol,
then
john,
I
think,
will
give
us
an
update
on
the
draft
and
traces
and
so
on
and
marco
has
a
quick
report
on
the
hackathon
and
then
we
have
one
other
thing
malicious.
B
Yes,
so
we
received
one
request
on
from
marek
to
give
an
update
on
the
his
work
on
test
factors,
but
I
don't
see
mark
in
the
participants
list
so
with
that.
I
guess
if
we
can
just
do
the
regular
gender
bashing
see
if
anyone
else
has
any
proposals.
C
B
Yes,
so
I
wanted
just
to
give
a
brief
update
on
the
status,
so
essentially,
as
as
steven
noted,
we
are
kind
of
wrapping
up
the
formal
analysis
stage
of
the
protocol.
During
the
previous
itf-113
meeting,
we
had
the
symbolic
analysis
presented
of
all
ad-hoc
meta
authentication
methods.
B
Right
in
this
meeting,
we
will
have
two
presentations
on
computational
analysis
of
method,
0
and
method
3
by
mark
and
baptist
respectively.
So,
as
you
can
see,
we
have
kind
of
all
almost
all
parts
of
the
protocol
covered,
which
is
great
on
the
implementation
security
side.
I
won't
be
giving
an
update
as
due
to
the
lack
of
agenda
time,
but
we
made
some
good
progress
on
that
and
completed
the
hacks
back
implementation
that
I
mentioned
during
the
previous
ietf
meeting.
B
B
So
one
note:
we
created
the
page
lake
workinggroup.org
lake
wwg.org,
where
we
are
keeping
track
of
the
different
activities
around
the
the
working
group,
mainly
interoperability,
testing,
formal
analysis,
some
informal
presentations
of
the
protocol
like
key
schedule,
so
just
something
that
facilitated
the
formal
analysis
in
the
past
so
give
this
a
a
look,
and
we
welcome
any
feedback
if
you
have
any
on
on
this
particular
page,
that
would
be
pretty
much
it
on
this
slide.
B
One
one
more
aspect
that
I
forget
forgot
to
mention
previously:
the
external
people
have
people
external
to
the
working
group
have
mostly
been
referring
to
this
to
the
protocol
as
a
lake.
So
we
as
chairs
we
wanted
to
kind
of
brief
kind
of
paul.
The
working
group
on
the
on
the
question
whether
renaming
ad
hoc
two
lake
makes
sense,
and
we
will
be
doing
this
in
the
next
days
on
the
on
the
mailing
list.
B
A
D
D
Right
so
hello,
everyone
so
in
this
short
presentation,
is
about
our
work
on
a
computational
analysis
of
adopt
six
sick.
The
work
was
done
in
the
context
of
my
master
thesis,
which
is
being
supervised
by
felix
gunter
at
zurich.
Given
the
time
restriction,
I
will
only
focus
on
the
most
interesting
part,
insights
of
our
analysis.
A
detailed
write-up
should
be
available
once
the
thesis
is
completed
in
a
few
weeks
time,
actually
in
a
week.
D
The
main
takeover
message
from
our
analysis
is
that
the
educ
is
structurally
sound
and
secure.
We
targeted
key
secrecy,
we
analyze
explicit
authentication
and
the
four
secrecy
guarantees
of
adopt
six
sig
for
our
security
model.
We
analyzed
edoc
in
the
multi-stage
exchange
model
that
I
will
briefly
explain
later.
D
However,
a
caveat
or
analysis
that
I
should
state
is
that
our
bound
is
not
tight,
however,
belief
that
the
recent
work
of
davis
etal
on
tls
1.3
should
be
a
good
opportunity
there
to
provide
the
better
tighter
security
analysis
of
edoxing
along
the
way.
In
this
analysis,
we
also
gained
some
insight
into
the
market
and
signed
protocol
that
we'll
share
as
well
in
hope
that
it
helps
with
potential
further
development.
D
So
let
me
then
start
by
explaining
our
security
model.
As
mentioned,
we
analyze
edoc
in
the
multi-systec
exchange
model.
We
closely
follow
the
work
of
doling
a
tile
on
analyzing
the
ts,
1.3
and
check
protocols.
So
in
the
msk
model
we
consider
a
key
exchange
protocol
here
denoted
by
pi.
That
can
be
used,
for
example,
to
establish
a
key
to
communicate
over
an
insecure
channel.
Furthermore,
users
will
run
typically
multiple
concurrent
instances
of
the
protocol
that
we
call
sessions.
D
D
A
closer
look
at
edoc
shows
that
edoc
is
not
just
a
protocol
that
derives
a
single
session
key,
but
there
are
actually
multiple
stage
keys
that
are
derived
throughout
the
protocol,
in
particular
four
in
our
model,
so
just
the
msk
model
is
adapted
to
edoc,
so
in
particular,
multi-stage
protocols
may
introduce
dependencies
between
stage
keys
that
are
potentially
unwanted,
and
so
the
sql
model
allows
us
to
capture
such
issues,
and
it
also
enabled
fine-grained
analysis
of
the
stage
keys,
thereby
giving
an
overall
security
proof.
D
Explicit
authentication
was
of
particular
interest
in
our
analysis,
and
this
will
be
the
the
subject
of
the
reminder
of
my
of
my
talk
very
informally,
explicit
authentication
captures
the
fact
that
for
authenticated
stages,
only
the
peers
knows
about
the
stage
keys
and
they
also
demonstrated
actively
knowledge
of
that
key.
D
However,
in
edoc
we
particularly
looked
at
the
specification
for
credential
identifiers
and
the
possibility
that
they
may
be
non-unique.
There
is
sort
of
an
ongoing
discussion
going
about
this,
and
what
we
did
is
that
we
took
a
very
conservative
approach
and
we
modeled
this
aspect
by
assuming
that
all
identity,
I
don't
all
credential
identifier-
may
be
non-unique
and
furthermore,
in
our
model
we
actually
allow
the
adversary
to
choose
these
these
identifiers
arbitrarily.
D
D
So
here
we're
saying
that
again,
I've
sort
of
simplified
edit
by
showing
that,
in
the
second
message,
the
receiver,
the
responder
would
send
sort
of
a
key
identifier,
a
signature
and
then
some
message.
Obviously,
the
message
is
not
really
sent
in
edok.
As
we
know,
only
sort
of
partially
and
interesting
observation
is
as
well.
That's
the
message
that
the
the
actual
responder
sends
is
always
different
than
the
one
that
will
be
verified
for
the
malicious
key.
This
is
because
the
credentials
are
signed.
If
you
recall
the
run
of
edoc,
the
credentials
are
signed.
D
Therefore,
the
message
always
different,
so
the
natural
question,
then
here
was
what
type
of
security
guarantees
do
we
need
from
the
signatures?
Well,
we
realized
that,
in
fact,
we
need
more
than
the
normal
unforgeability
that
is
usually
sort
of
the
minimal
required
guarantees
in
the
previous
attack.
Actually,
the
transcript
hashes
as
you've
seen
the
adversary,
never
changes
the
communication
transcript,
so
the
transcript
ashes
nor
the
keys
will
are
modified.
D
Therefore,
the
protocol
runs
through
without
error,
so
this
inside
the
fact
that
we
need
besides
forgivability,
we
need
a
notion
of
exclusive
ownership
of
signatures
and
in
particular
because,
as
we
said,
the
messages
are
different
for
different
users
who
are
authenticating
themselves.
We
need
the
minimal
required
security
guarantee
would
be
destructive
exclusive
ownership.
D
Interestingly,
the
macdon
sign
protocol
would
also
be
vulnerable
to
a
similar
attack
if
the
signature
scheme
would
contain
weak
keys,
and
additionally,
we
also
saw
that
the
ambiguous
and
ambiguous
nature
of
sebor
and
when
it's
encoded
also
prevented
some
issues.
That
would,
for
example,
come
from
concatenating
but
by
strings,
as
is
done
in
the
computation
of
the
mach
2
for
it,
for
instance.
D
So,
fortunately,
we
could
show
that
the
signature
scheme
in
adult
six
sig
provider
required
exclusive
ownership
guarantees,
so
in
particular,
edwards
25519
is
known
to
provide
universal
exclusive
ownership
for
scdsa.
It's
not
really
the
case.
However.
The
fact
that
the
public
key
is
also
signed
is
enough
to
provide
the
security
guarantees
that
we
need,
namely
exclusive
ownership.
However,
this
requires
that
there
are
no
weak
keys
and
also
inside
the
fact
that
the
implementation
must
be
must
perform
all
the
checks,
as
we've
seen.
D
It's
not
always
the
case
with
the
recent
cv,
for
example,
on
such
psychic
signatures
and
beside
exclusive
ownership.
Our
proof
we
also
required
strong
enforceability
instead
of
just
the
existential
unforgivability
of
signatures.
D
This
is
because,
in
contrast
to
tls
103,
the
magnet
sign
the
mac
is
under
the
signature
and
not
it's
not
the
other
way
around,
where
the
mac
also
covers
the
the
signatures.
Without
that,
the
consequence
is
that
an
initiator,
for
example,
would
accept
a
second
message,
even
if
it
was
modified
by
sgfcm
attack.
D
The
consequences
here
are
probably
not
interesting.
It's
not
clear
what
practical
issue
will
happen
here,
but
it's
it's
it's
good
to
be
aware
of
this,
and
as
for
the
signature
schemes
well
for
edward
2019,
while
this
is
not
to
provide
it's
not
to
be,
it
is
known
to
be
src
may
secure.
Obviously
it
has
to
be
the
itf1
as
it's
been
shown,
that
the
original
air2519
is
actually
not,
as
you
have
cma
secure
and
for
ecdsa
again
there
are
ways
to
modify
the
signatures
in
a
way
that
breaks
your
cma.
D
So
to
this
effect,
we
we
suggested
two
modifications
to
strengthen
exclusive
authentication,
although
we
could
already
prove
it,
namely
this
is
to
add
the
credentials
to
the
transcript
hashes
as
as
shown
there.
The
benefit
is
that
an
attempt
to
identify
spinning
attack
as
I've
shown
before,
will
lead
to
diverging
transcript
hashes,
which
then
sort
of
stops
the
protocol
and
leads
to
a
termination,
of
course,
assuming
with
some
collision
resistance
assumption
on
the
hash
function.
D
So
with
all
that
being
said,
how
many
theorem
is
essentially
an
upper
bound
on
the
advantage
of
an
msk
adversary,
so
the
msk
being
the
security
model?
Again,
I
can't
really
go
home
into
the
details
now,
but
essentially
what
it
shows
is
that
we
can
reduce
the
security
of
edox
66
to
its
main
components,
namely
collision
resistance.
Hash
function
strongly
unforgeable
signature
scheme
that
also
provides
exclusive
ownership,
a
prf
function,
which
is
the
expand
on
the
prf
assumption
on
the
expand
function
and
the
prf
odh
assumption
on
the
extract
function.
D
D
This
obviously
made
really
easy
to
prove
security
and
to
have
sort
of
a
clean,
indistinguishability
proof,
and
so
by
that
I
mean
secrecy,
proof
for
the
prk
out,
which
is
now
the
sort
of
final
session
key
and
computing
transcript
hashes
over
the
plain
text
was
our
second
suggestion
and
that
also
simplified
our
proof
in
the
sense
that
we
did
not
rely
on
some
potentially
non-standard
assumption
on
the
encryption
schemes.
D
A
Great
and
thanks
for
all
the
work,
I
think
we
have
john
on
the
left.
E
Yeah
john
here,
thanks
for
all
this
work,
you
really
really
great
the
the
pre,
yes
pointing
out
the
previous
recommendations
have
been
included
in
the
latest
version
for
the
update
of
three
and
th
four.
There
is
already,
and
pr
there's
also
ongoing
discussion
between
different
teams
here
in
the
issue
right
now,
but
it
seems
like
a
very
it's
a
very
simple
change,
but
please
look
into
the
issue
and
the
pr.
A
A
G
G
F
Okay,
so
thank
you
all
on
the
computational
analysis
of
the
ad
doc
protocol
in
the
stat
stat
method.
So
first
represent
some
equations.
We
made
some
notations,
so
pi.
A
single
pi
will
be
the
one
time
encryption
scheme,
while
the
pi
prime
will
be
an
authenticated
encryption
scheme,
the
a
will
be
not
an
adversary
and
g
is
a
secret
group
of
order.
P.
F
F
F
F
F
So
we
have
the
injectivity
so
for
any
key
in
the
space
of
keys,
two
encryption
of
different
message
with
the
same
keys
will
result
in
if
you
have
an
equality
in
two
encryption
of
two
messages
with
the
same
key,
it
means
the
message
are
equals
also.
We
have
in
the
one
time
the
undiscussibility
so
for
an
adversary.
F
F
We
also
have
the
invaluability
of
the
auto
ticket
authenticated
encryption.
So
here
again
the
baby
has
an
access
to
the
encryption
and
decryption
records.
You
have
to
generate
a
valid
cipher
text
and
the
advantage
is
denoted
as
the
as
the
capacity
to
for
the
srv
to
afford
to
further.
Well,
it's
a
text
with
chosen
messages.
F
So
her
results,
so
we
use
a
queue
arrow
to
the
number
of
queries
to
the
random
records
and
sigma
to
denote
the
number
of
running
sessions,
capital,
n,
the
number
of
users
and
ash
is
the
length
of
the
hd
and
lmac.
Is
the
mac
digest
length
so
for
the
carry
the
key
privacy?
F
F
F
This
is
the
similar
for
the
initiator,
explicit
authentication.
So,
however,
you
even
if
the
initiator
use
an
authenticated
encryption
this.
This
has
no
impact
on
the
on
the
security,
as
this
is
the
it
is
encrypted
using
the
key
sk3
that
any
imposter
can
compute
so
that
that
does
not
give
any
security
for
the
authentication
initiator.
F
So
in
the
summary,
so,
if
you
consider
the
cypher
suits
0
and
2.,
we
use
a
tag,
mac
tag
of
length,
64
bits
and
we
have
a
key
privacy,
security
of
128
bits
and
another
protection
for
both
the
initiator
and
the
responder
of
128
bits
and
for
the
authentication
we
have
a
64-bit
security
each
so
and
in
the
protocol
as
a
defined
protocol.
We
make
the
use
of
the
authenticated
encryption,
but
that's
used
in
the
point
of
view
of
the
security
as
sk.
F
F
So,
as
sk3
is
independent
of
xs
and
as
the
mac
is
128
bit
length,
we
have
128bpt
for
the
authentication.
So
it's
simply
the
idea
to
replace
the
authenticated
encryption
with
one
type
encryption,
as
there
is
no
impact
on
security.
F
F
F
F
So
the
solution
was
to
compute
two
encryption,
so
the
first
encryption
with
the
key
is
key
sk3
that
will
encrypt
ide
and
external
data
with
the
symmetric
key
once
the
responder
decrypt.
This
message
he
has
the
information
to
compute
the
key,
the
key
before
that
depends
of
xs
and
in
the
message,
the
initiator.
F
So
before
trying
to
fold
a
tag,
the
adversary
will
have
to
forge
the
valid
surface
text,
and
so
the
security
are
multiplied
and
we
have
a
security
that
is
around
128
bits
and
about
the
length
of
the
message
three.
It
depends
on
the
length
of
the
plain
text
3a
so
ide
and
e3,
because
if
this
message
is
smaller
than
64
bits,
modulo
128,
we
have
a
longer
message,
and
if
this
is
not
the
case,
we
have
a
shorter
message.
F
This
is
due
the
fact
that
t4
t33
will
be
a
64-bit
message
that
will
be
encrypted
under
128
bits
block,
so
we
lose
in
some
kind
of
los
64
bits
and,
depending
on
the
length
of
the
text,
we
have
a
either
shorter
or
longer
message.
F
And
we
can
use
the
similar
idea
for
the
message
too,
so
to
increase
the
responder
authentication
where
you
would
send
is
a
in
the
information,
key
stream
ciphertext
and
use
the
authenticated
encryption
for
better
authentication
security.
But
this
will
this
will
lead
to
a
higher
bigger
message
too,
but
better
security.
So
there
may
be
some
compromise
to
do
here.
F
F
F
F
The
last
minor
improvement
is
that,
in
all
our
terms,
we
have
n
sigma
times
a
q
airport,
and
this
comes
from
the
fact
that
the
key
pr
key
to
e
is
computed
according
to
an
empty
string
and
because
of
the
empty
string.
When
the
adversary
make
a
query
to
the
random
oracle,
it
can
find
a
match
with
any
of
the
sessions.
So
if
you
have
a
10
session,
a
second
query
can
generate
a
collision
with
any
other
10
sessions.
F
The
idea
to
to
protect
from
this
is
simply
to
use
th2
as
the
input
string
of
the
computation
of
player
key
to
e,
as
in
this
case,
each
th2
is,
is
related
to
a
single
session.
F
F
E
We
made
some
there's
been
recent
issues
created
for
these
things
and
for
the
th2,
the
th2s
yes,
and
have
had
an
issue
and
a
discussion
ongoing
whether
these
extra
factories
is
needed
or
or
not
very
recently,
a
few
days
ago
made
a
pr
turns
out
that
adding
three
also
simplifies
the
specification,
because
each
kdf
has
some
strange
behavior
with
the
empty
string,
so
we
needed
so
we
could
actually
remove
text,
so
it
might
be
worth
doing
just
for
for
that
alone.
E
Joram
made
this
morning,
I
think
an
issue
for
the
other
and
also
started
looking
at
how
how
it
would
affect
the
implication.
I
think
it
would
increase
in
many
cases
the
message
tree
with
a
single
bite
to
do
this,
but
I
think
that
needs
some
more
more
discussion
and
analysis
on
github.
B
Yes,
john,
so
what
I
hear
from
you
is
that
we
are
tracking
the
improvements
suggestions
that
are
proposed
by
baptist
and
that
we
have
the
ongoing
discussion
on
github
around
these,
which
is
very
important
as
and
please,
let's
keep
on
doing
that.
I
think
we
have
mark
in
the
queue
mark.
Did
you
want
to
comment
on
something
or.
G
F
Yes,
so
it's
still
a
draft,
but
we
are
working
with
david
poncheval
and
I
think
soon
depends
on
on
the
conversation
or
how
it
will
evaluate.
But
yes,
there
is
a
paper
that
may
be
soon
be
a
preprint
and
why
not
be
a
submit,
but
yes,
there
is
a
ongoing
paper.
A
Great
thanks,
baptiste,
thanks
again
for
all
the
work-
and
I
think
next
is
john.
E
Yeah,
so
we
can
today's
presentation
about
all
the
updates
and
ongoing
issues.
This
is
an
overview,
so
version
13
was
just
a
resubmission
and
then
quite
major
changes
in
14.,
but
we
waited
with
submitting
that
to.
E
Yeah
much
better,
so
this
is
an
overview
of
the
submitted
version.
We
waited
with
14
for
a
long
time
to
have
a
stable
version.
Now
I
guess
the
slides
disappeared.
E
And
then
there
was
a
recent
update
of
the
traces
aligning
with
1450
1415
has
the
same
buyer
format
and
then
very
recently,
just
a
few
days
ago,
zero
two
traces
was
submitted
with
a
correction.
I
think
the
oscar
master
salt
was
wrong
in
the
draft
version
and
then
we
can
go
to
the
next
slide.
E
And
then
a
major
rewrite
of
ead,
section
yeah
and
some
technical
change.
The
ad
value
is
now
a
bit
string,
quite
a
lot
of
changes
to
the
adhoc
key
derivation
and
key
schedule
based
on
comments
from
the
formal
verification.
E
E
Also
changes
to
the
identifier
encoding.
This
has
been
an
ongoing
discussion
with
different
solutions,
all
pretty
same
strong
conclusion
in
the
group
that
we
need
to
have
this
one
byte
encoding
but
unclear.
How
now
we
have
gone
back
to
before
it
was
in
discussed
to
have
integer
kids
in
cosi.
That
has
now
been
scrapped
and
it's
specified
as
there
are
byte
strings,
but
they
are
encoded
as
integer.
This
is
similar
to
the
solution
before
but
presented
it's
a
new
solution
which
is
much
simpler.
Hopefully
so,
hopefully,
this
is
the
last
version
of
that.
E
E
Here
is
a
new
dramatic
of
the
key
schedule,
yeah
and
as
before,
major
change,
more
key
derivations,
there's
also
a
new
key,
the
prk
exporter.
There's
a
new
session
key
called
prk
out
to
have
a
very
well-defined
session.
Key
formal
verification
typically
wants
to
have
a
very
formal
session
key.
That
is,
you
can
state
properties
with
next
slide.
E
E
E
So
there's
some
new
now
we're
coming
to
more
discussions.
There's
a
few
remaining
discussions
and
issues
left
in
15
there's
a
new
section
on
authenticated
operation.
This
was
previously
an
empty
trust
on
first
use
section,
but
we
realized
it
can
be
included.
You
can
there's
more
options
here,
there's
been
more
generalized
yeah,
then
there's
a
lot
of
clarifications.
E
A
security
concer
can
take
next
slide.
So
now
we're
coming
to
ongoing
discussions
and
some
changes
to
the
ead.
Based
on
the
item
issue
created
by
christian
amsas,
I
think
about
encrypted
client,
hello
types
of
use
cases,
but
one
of
the
things
that
popped
up
there
was
that
it
would
be
good
to
have
a
critical
non-critical
flag
for
the
ead,
and
this
has
already
been
included
in
the
latest
version.
I
think
and
negative
values
are
now.
E
E
E
Open
issues,
so
this
has,
I
guess
most
of
this-
has
been
inc,
already
discussed
the
tree
first,
as
are
based
on
the
formal
verification
that
is,
I
think,
already
discussed,
except
this.
One
remaining
issue
is
that
it
was
realized
that
the
hkdf
has
a
length
limit
depends
on
the
hash
algorithm
used,
but
when
you
use
char256,
the
maximum
output
is
8160.
E
E
So
you
only
need
to
change
your
implementation.
If
you
actually
use
low
messages
and
h
and
hkf
expand
piece
here
would
be
hkdf
with
a
16-bit
value.
Instead,
it
was
it's
still
hkdf,
according
to
the
academic
paper,
but
not
hkdf
according
to
the
rfc.
E
E
E
E
G
E
So
this
has
been
updated,
aligning
with
ad
hoc
14
and
then
there's
some
embark
was
fixed
in
zero.
Two
there's
been
very
recently
a
new
bug
just
submitted,
so
I
think
there
will
come
a
new
version
of
traces
fixing
that
next
then
next
steps.
I
guess
that
we
will
discuss.
Are
there
any
questions?
So
we
have.
G
H
H
We
consider
the
previous
acaton
and
in
vienna
and
in
fact,
we
considered
exactly
the
same
setup
with
malicious
initiator
and
me
as
responder
and
well
the
the
most
effective
configuration
if
you
want,
because
that's
the
one
really
bringing
you
to
the
smallest
possible
message
to
you,
which
is
45
bytes
and
we
specifically
considered
the
cypher
c2
method,
three,
both
peers
with
ccs
and
kids
as
credential
identifiers,
with
a
kid
such
that
and
call
it
as
an
integer
on
the
wire
and,
yes,
everything
eventually
succeeded.
H
C
On
yeah,
I
just
wanted
to
add
to
what
mark
would
said.
We
have
a
confirmation
from
stephan
ristof
that
he,
his
implementation,
is
also
updated
to
version
15
and
marek
who
couldn't
be
here
has
made,
has
updated
the
test
vector
code
also
to
version
15,
and
there
are
now
test
vectors
for
ecdsa
and
eddsa
in
a
folder
in
the
github
called
something
like
test
vector,
15.
C
A
Great
so
so
I
think
we
have
a
about
seven
minutes
left.
I
think
that
the
topic
that
we
position
I
would
like
to
cover
is:
how
do
we
get
done?
What's
the
next
things,
obviously
there's
some
outstanding
prs
and
things
that
need
to
be
discussed,
but
what
else
is
needed
now
that
we
kind
of
have
some
of
the
analysis
done
before
we're
ready
for
working
group
last
call,
so
I'd
appreciate
your
thoughts
on
that.
E
Yeah,
I
think
I
would
say
nothing
more
unless
something
pops
up,
but
we
need
to.
We
have
some
current
issues,
there's
nothing
coming
in
very
much
more
issues,
so
I
think
we
fix
these
issues,
publish
a
new
version.
Then,
of
course
we
need
some
implementation,
but
after
that
I
think
we
are
ready
for
working
group
last
call.
We
already
had
very
substantial
reviews
before
yeah.
B
So
maybe,
as
a
reply
to
john
I
mean
it
seemed
that
yes,
so
the
suggestions
proposed
by
baptist
will
also
affect
the
key
schedule
and
therefore
also
affected
the
traces.
B
So
they
still
seem
to
be
kind
of,
not,
I
won't
say
substantial,
but
important
as
they
affect
the
security
level
of
the
of
the
static
static
mode
right.
B
So
we
want
do.
We
need
an
interim
to
discuss
those,
or
should
we
call
it
a
break
now
for
the
summer.
Do
what
are
the
people's
thoughts
on
this.
C
C
Maybe
we
could
have
a
meeting
with
the
some
of
the
teams
I'll
reach
out
to
webtest
here
after
the
meeting
see
if
we
can
have
a
short
meeting
and
and
discuss
the
latest
input,
and
then
we
need
to
do
the
to
the
prs
and
then
the
specifications
should
be
fine
and
we,
of
course
we
need
to
update
implementations
also.
But
this.
D
C
A
Sure,
okay,
so
I
think
what
I'm
hearing
is
we
you
know
depending
if
we
might
or
might
not
want
to
organize
an
interim
around
october
time
but
other
than
that
we'd
like
to
hopefully
get
to
start.
The
working
group
last
call
before
the
november
ietf
meeting
so
that
the
working
group
last
call
ends.
Just
as
that
meeting
happens,
or
something
perhaps
does
that
sound,
reasonable.
A
Okay,
so
nobody
seems
to
be
screaming
and
objecting,
which
is
very
nice,
so
I
think
that's
the
plan,
we'll
try
and
aim
to
wither
without
an
intro
and
get
to
working
past
call
completed
before
november
seems
that
seems
feasible
to
me.
I
think,
given
where
we
are
so
it's
good
and
thanks
all
for
the
work,
I
think
we're
at
the
kind
of
any
other
business
part
of
the
agenda
where
we
have
a
couple
of
minutes.
If
there
is
any
other
business.
A
Don't
yes
paul?
Our
id
is
jumping
up.
G
Sorry,
I'm
just
on
the
preview
topic.
You
could
maybe
do
an
early
sector
review
if
you're
anywhere
in
a
sort
of
lull
where
there
aren't
any
big
changes
happening.
It
could
perhaps
be
useful.
A
A
And
with
that
I
think
militia
anything
else.
B
G
C
Actually,
I
have
a
final
request
now
we
are,
I
mean
if
we
follow
a
proposal
from
baptist
and
and
and
david,
we
are
making
changes
and
it
would
be
great
if
those
teams
who
have
been
analyzing
the
protocol
could
make
another
round
and
see
that
we
don't
mess
up
things
when
when
we
make
those
final
changes.
A
Sure
yeah,
we
should
definitely
ask
I
mean
you
know,
can't
expect
too
much
effort,
but
it's
definitely
worth
asking
okay.
So
with
that,
I
think
we're
we're
done
for
today,
thanks
for
coming
thanks
for
all
your
work,
thanks
again
to
the
people
doing
the
formal
analysis
that
was
really
good
and
we
might,
we
may
well
meet
next
time.
I
guess,
depending
on
if
working
group
last
call
has
any
comments.