►
From YouTube: IETF104-CFRG-20190327-1220
Description
CFRG meeting session at IETF104
2019/03/27 1220
https://datatracker.ietf.org/meeting/104/proceedings/
A
D
C
Good
morning,
everybody
welcome
to
see
FRG
at
ITF
104.
If
you
could
finish
up
your
conversations
and
take
your
seats
quickly
that
appreciate
it.
We're
already
a
few
minutes
behind
schedule.
The
boo
sheets
are
circulating,
please
sign
your
name
and
give
your
affiliation
as
usual,
we'll
collect
them
at
the
end
we
have.
Is
we
had
someone
volunteer
to
take
minutes
for
us
see
here.
Robin
is
Robin
Wilton
here,
I
guess
he's
not
I!
Guess
he's
forgot!
Oh
yes,
there!
Okay,
Robin!
You!
Okay!
Still!
Thank
you.
We
need
someone
to
monitor.
Jabbar.
C
E
B
B
B
B
B
B
B
B
B
G
H
Good
morning
mr.
Susman
chef
top
row
and
together
is
Cass
Kramer's
Luke
Garrett,
Nick
Saban
Christopher
Wooten
Delia
Nova
I'm
present
in
a
state's
update
of
real
improvements
for
security
protocols
document.
So
a
brief
overview
of
the
document,
since
all
security
mechanisms
rely
on
randomness
and
parent
G's
can
be
float,
can
be
back
door.
They
can.
You
can
have
some
box,
so
it's
better
to
have
a
safety
net
to
deal
with
these
potential
problems
and
the
range
before
the
horn
problems
are
really
difficult
to
detect.
H
So
it's
really
good
to
have
some
kind
of
safety
net
and
a
solution
to
improve
any
call
of
entropy
and
provide
such
a
safety
net
is
proposed
in
our
document.
The
construction
ins.
On
the
slide,
we
heard
two
minor
changes,
one
about
the
key
considerations
about
usage
of
this
key.
That
should
be
separate
key
and
some
minor
change
in
the
terms
doesn't
really
great,
but
we
had
two
major
steps
forward,
one
about
the
experimental
results-
and
the
second
is
about
here
descendent
so
about
the
experimental
results
thanks
to
Christopher
root.
H
Now
we
have
a
very
good
document
about
experiments
without
construction,
so
the
experiments
were
conducted
for
hkf
and
secretive,
as
I
will
conducted
in
conditions
when
signature
was
calculated
once
and
then
the
construction
was
used
in
a
loop
and
an
overhead
compared
to
the
basic
safety
ng
was
measured.
So
this
episode
the
code
of
what
was
done.
H
We
did
this
for
typical
lengths
of
output
randomness
that
are
typical
and
convenient
for
such
protocols
as
TLS,
so
these
are
their.
These
pictures
are
presented
in
as
a
a
print
paper
as
an
appendix,
so
we
can
look
at
them
closely
about
to
be
short
for
all
four
variants
of
lengths.
It
can
be
seen
that
starting
form
about
1,000
of
loops
ever
since
comes
to
an
asymptote
and
Sukhdev
and
H
KDF
works
rate
is
the
same,
so
there
is
no
sense
to
get
rid
of
H
KDF.
H
The
cost
is
from
nanoseconds
to
microseconds,
so
it's
minor
with
respect
to
T
latest
operations.
So
we
had
these
experiments
added
to
his
appendix,
and,
to
sum
up,
we
don't
think
that
anything
has
to
be
changed
in
the
construction
because
of
experimental
results
within
that
ever
since
fine
with
the
construction
regarding
the
performance
so
keep
it
as
it
is.
The
second
major
step
forward
was
the
security
assessment.
H
Last
time
in
Bangkok,
I
said
that
we
had
a
huge
assessment
published
in
any
print,
but
it
had
some
minor
problems
with
assumptions,
so
the
assumptions
for
basic
mechanisms
were
questionable
in
some
sense,
so
we
promised
to
improve
improve
this
and
we
we've
had
it
approved
now.
The
updated
version
in
is
ePrint.
H
Now
we
have
very
good
and
complete
security
proof
for
all
three
design
properties,
but
we
adversary,
who
can
read
the
output
of
basic
six
PNG,
but
can
not
control
this
for
as
adversaries
it
can
control
the
space
PRNG
the
security
and
also
has
some
questionable
assumptions
it's
made
in
animal
models.
So
to
address
this
issue,
we
understood
that
if
we
can
swap
the
inputs
of
as
I
stretched
function,
we
can
deal
with
this
issue
too.
H
So
we
can
strengthen
the
proof
if
we
swap
the
inputs
and
nothing
else
gets
worst,
so
we
can
deal
with
H,
make
no
tones
and
random
Oracle,
but
it's
in
a
most
honest
model,
so
we
really
can
do
better,
and
so
in
the
paper
we've
now
have
we
not
have
security
proof,
even
for
this
case,
so
for
case
of
open
as
inputs
of
a
search
function,
we've
proven
that
nothing
else
get
worse
and
this
property
gets
really
better.
Moreover,
this
change
also
helps
to
increase
performance.
H
So
it's
even
better,
but
of
course
we
still
need
to
revise
this
because
it
was
quite
recently,
and
so
this
seems
to
be
only
one
question
left
that
question
about
weapons
inputs
and
we
think
that
we'll
deal
with
this
really
soon
and
after
that
who
will
ready
to
go
to
the
plus
Cole
I,
think
that
we
could
do
this
before
me,
so
the
soul.
Thank
you.
Questions
stations.
C
C
I
Right
so
we
talked
about
their
signatures
and
both
agree,
and
this
is
a
drop
in
court
that,
with
them
forni
ceky
gorbunov
an
action
for
each
arm,
so
the
only
signatures
are
signatures
that
relies
on
our
pairing
friendly
cuffs.
These
are
very
efficient
signatures,
the
public
key
and
the
signature.
Essentially,
one
group
element
each
think
about
the
assembly
at
fifty
to
a
hundred
bytes
signing
a
verification
in
the
order
of
milliseconds.
What
really
distinguishes
beyond
signatures
is
that
they
are
every
dateable
in
the
following
sense.
I
You
have
4n
signatures
from
n
different
from
n
public
keys
and
honor
and
messages.
You
can
compress
this
n
signatures
inverse
single
signature
that
still
are
satisfied
basically
or
and
people
have
cyber
end
messages.
So
there
are
many
applications
who
have
in
mind
probably
niches,
one
probably
in
the
context
of
IETF
in
particular,
is
that
we
can
hope
to
use
beyond
signatures.
The
compressive
nature
change
in
our
public
key
infrastructures
or
in
the
security
protocol.
Another
one
that
come
up
quite
a
lot
recently
is
in
major
blotching
projects.
I
We
want
to
use
BRS
signatures
and
the
ability
to
aggregate
in
inches
to
reduce
a
bandwidth
and
storage
requirements
in
versions.
In
fact,
in
the
past
year,
or
so,
the
major
production
projects
like
uber
and
etherium
Z
cash,
a
chair,
I've,
been
sort
of
looking
into
providing
very,
very,
have
been
working
to
provide
production,
ready
and
very
efficient
open-source
implementation
of
this
obvious
images.
I
So
we
expect
to
see
deployment
of
the
signature
schemes
the
next
half
of
your
year,
and
so
this
seems
like
a
very
good
time
to
get
feedback
from
the
community
on
the
on
these
major
schemes
and
to
try
the
standardize
you
signature
schemes,
in
particular
many
of
the
of
this
different
signatures.
Many
of
the
existing
implementations
actually
use
slightly
different
underlying
algorithms,
so
we
would
like
to
have
some
standard
on
this
so
right.
I
So
there
are
two
are
related
drafts
on
this
on
this
and
this
topic,
which
I
will
drop
you
on
one,
is
the
drug
for
parent
friendly
curves.
Another
is
a
drop
on
our
hashing
of
the
curves,
so
I.
Would
the
signature
scheme
required
peripherally
curves
and
also
requires
the
ability
to
hatch
on
the
curve?
So
these
are
things
that
we
were
required
so
right.
I
So
I
would
take
this
opportunity
to
sort
of
highlight
some
of
the
issues
that
comes
up
in
embarrassing
inches,
something
that
will
address
you
now
in
each
iteration
and
also
to
take
this
opportunity
to
get
some
feedback
from
the
community
about
this.
So
one
issue
is
that
the
basic
BL
signature
scheme
is
actually
susceptible
to
a
so-called
ruski
attacks.
I
What
this
means
is
that,
if
I'm
an
evil
user,
I
can
register
a
public
key,
that's
correlated
with
the
public
keys
of
every
individual
in
this
room
and
then
later
on,
produce
a
approached
aggregate,
a
signature
saying,
for
instance,
everybody
is
supposed
adoption
or
draft,
even
though
none
of
you
has
actually
ever
sized
such
a
message
supporting
adoption
of
this
drug.
So
this
is
a
security
issue.
Unfortunately,
we
already
know
several
mechanisms
to
handle
this.
The
security
issue,
the
simplest
of
which
is
basically
when
you
are
using
the
basic
bio
signature
scheme.
I
Instead
of
just
signing
the
message,
you
sign
a
concatenation
of
the
public
key
and
a
message.
Another
mechanism
is
that
when
users
register
their
public
keys,
they
provide
a
so-called
proof
of
possession,
so
the
simplest
way
to
instantiate
this,
for
instance,
is
that
we
require
that
when
users
register
public
keys,
they
also
provide
a
signature
on
the
public
key.
A
third
mechanism
is
to
modify
the
basic
idea
as
verification
algorithm
for
verifying
aggregate
signatures,
so
that,
instead
of
just
multiplying
the
public
keys
together,
you
actually
take
some
carefully
chosen
linear
combination
of
the
public
keys.
I
So
each
of
these
three
different
mechanisms
have
different
trade-offs
and,
depending
on
the
use
cases
you
may
want
to
use
different
ones.
So
one
thing
we
want
to
get
back
on
is
the
use
cases
people
may
have
in
mind
and
sort
of
which
of
this
mechanism
should
we
adopt
and
to
the.
What
as
to
how
much
detail?
Should
we
be
specifying
this
mechanisms
in
our
trap?
The
other
is
the
issue
of
Santa
Fe's.
What
this
means,
of
course,
is
that
what
are
the
clothes
we're
going
to
use
for
our
will
be
our
signature
scheme.
I
So
most
of
the
major
are
implementations
right
now
you
spell
as
12
381.
This
is
one
of
the
curves,
that's
already
included
in
the
parody
draft
I
mentioned
earlier.
So
this
is
very
something
that
we
want
to
support
by
which
other
curves
do
we
want
to
support.
Also,
in
addition,
the
signature
scheme
uses
algorithm
hash
of
the
curve
so
which
car
matching
algorithms
we
want
to
support,
so
a
couple
of
them
have
already
been
laid
out
in
the
draft,
and
then
there
are
other
mechanisms.
I
For
instance,
the
most
naive
and
simplest,
one
which
is
basically
was
caught,
are
trying
incremented
rough
or
better
name
as
some
kind
of
a
fashion
test,
and
then
finally,
we
want
to
keep
our
civilization
issues.
So,
if
group
elements,
how
do
we
want
to
represent
them
as
based
on
the
way
all
right?
So
let
me
say
that
we
have
a
github
account.
I
C
J
Ben
kata
so
for
the
the
road
public
key
question
from
an
engineering
point
of
view,
it's
typically
best
for
us.
If
there
is
just
one
chosen
option
and
we
don't
have
choices
we
have
to
choose
between
between
and
of
those
three
just
off
the
top
of
my
head,
the
the
first
one
where
you
sign
the
concatenation
of
the
public
key
and
a
message
seems
the
most
robust.
In
that
you
know
all
the
participants
can
easily
confirm
that
it
was
done.
When
you
have
the
option
to.
J
I
Right
so
we
agree,
we
do
believe
also
that
the
first
mechanism
is
a
most
robust
and
in
that
you
solve
the
problem
in
most
use
cases.
The
main
drawback
of
the
press
that
the
meet
the
situation
for
which
the
first
mechanism
isn't
so
desirable,
is
in
a
situation
where
you
have
many
users.
Sadly
the
same
message.
I
K
Watson
lad
to
is
not
gonna
work
for
any
sort
of
to
will
not
work
for
any
sort
of
lock
chain.
There's
no
way
you
can
control
the
public
keys
that
people
are
giving
money
to,
for
instance,
there's
just
no
control
I,
don't
see,
I.
Think
if
you
use
one
you
should.
Actually.
You
can
also
use
three.
Why
not
have
one
and
three
together
if
three
is
cheap.
I
Right,
okay,
absolutely
there's
other
questions
in
there.
Let
me
address
the
last.
One
is
a
tree
isn't
completely
true,
because
you
need
is
a
stress
pronunciations
and
in
general
happen.
Is
that
the
way
you
do
this
is
pronounciation?
You
need
to
see
all
of
the
public
keys
that
you
want
to
agree.
Aggregate
first
before
you
hash
the
collection
of
this
public
keys
and
then
choose
these
opponents.
I
So
you
don't
have
this
ability
to
incrementally
aggregate
in
addition
to
the
additional
costs
of
doing
of
doing
this
verification,
so
tree
is
not
exactly
cheap
and
certainly
one
can
imagine
doing
to
entry.
At
the
same
time,
I
mean
let's
say
that
I
agree.
There
are
some
use
cases
where
two
is
no
option.
I
For
instance,
if
you
are
trying
to,
for
instance,
side
transactions
on
block
change,
you
really
want
to
be
able
to
have
transactions
even
before
people
register
their
public
keys,
so
that
I
agree
to
is
not
so
applicable,
but
in
the
transaction
setting
you're
really
signing
different
messages.
So
for
that
case
we
believe
that
one
is
the
most
it's
the
most,
it's
probably
the
best
scenario,
and
then
there
are
some
other
use
cases
for
block
chains
for
which
we
believe
do
is
applicable,
but
maybe
I
think
that
often
I
buy.
E
Hi
Nick
Sullivan,
just
as
a
reminder
for
your
hashing
into
curves
section.
There
is
a
draft
currently
at
CFR
G,
and
the
latest
version
of
the
draft
includes
methods
for
hashing
to
super
singular
pairing
friendly
curves.
So
hopefully
that
can
be
of
use
as
a
cipher
suite
for
as
part
of
a
cipher
suite
for
this
draft.
If,
if
you
were
willing
to
take
it.
I
Yes,
yes,
so
definitely
the
current
draft
forever,
that's
a
quite
formalized
frying
increment,
so
it
does
talk
about
it,
but
not
in
too
much
detail.
So
one
thing
we
like
to
know
is
where
whether
that's
to
also
include
try
increment
addition
to
the
other
hashing
algorithms,
that
already
in
the
current
Roth.
So
that's
one
of
the
things
that
we
want
to
understand.
E
If
you
can,
then
we
can
speak
about
that,
but
yeah
we
have
try
an
increment
to
find
vaguely,
but
as
it's
not
constant
time,
we
did
not
include
it.
So
if
there's
specific
use
cases
that
are
not
dependent
on
constant
time,
then
we'd
like
to
hear
that,
because
it
could
be
useful
to
include
in
the
draft
thank.
C
L
State
your
name
please
cousin
quarter.
One
use
case
that
I
wanted
to
bring
up
that
wasn't
rated
to
group
signatures
is
blinding
wispy
less
signatures.
You
can
also
blind
the
public
here
and
blind
the
signature.
That's
a
use
case
that
I
would
be
interested
in.
So
if
that's
in
scope
for
you,
that
would
be
interesting
to
also
have
in
particularly
Senate
I
sterilized
Hormats,
and
these
kind
of
things
for
the
blind
in
case
that
you
can
do
this
be
other
signatures.
Thank
you.
C
C
Okay,
thank
you.
Are
there
any
people
who
think
it's
a
bad
idea?
Are
there
people
who
are
willing
to
work
on
this
and
review
drafts?
Maybe
quick
show
of
hands
one
too
few
great,
quite
a
few
okay
good.
Thank
you
will
obviously
take
it
to
the
list
for
formal
ratification,
but
thanks
everyone
for
their
inputs
and
thank
you
we'll
take.
B
M
I
run
so
this
is
drafted
as
posted
to
the
list
a
little
while
ago.
You
know
kind
of
like
to
summarize
I
get
some
discussion
in
a
group
and
see
if
this
is
worth
adopting.
So
the
use
case
here,
you
know
that
the
kind
of
history
here
is,
we
had
a
few
IETF
working
groups
that
were
how
to
need
for
a
kind
of
encrypt
to
public
key
primitive.
M
This
came
up
in
MLS
the
message
security
working
group
where
we're
doing
a
we're
kind
of
building
multiple
multicam
multicam
out
of
a
base
Ken,
we
needed
kind
of
a
way
to
encrypt
to
public
keys
in
that
context,
also
come
up
in
the
AES
and
I
context.
The
the
TLS
encrypted.
That's
an
eye
discussion
where
you
want
to
encrypt
the
the
server
name,
indication
field
to
the
holder
of
some
private
key
John
Matson
put
it
on
the
list.
There
might
be
some
five
G
cases
and
one
thing
Karthik
pointed
out
as
we're
working
on.
M
This
is
what
there's
an
existing
software
libraries
that
provide
yes,
I
like
primitives,
that
they
could
I'm
sorry
provide
EC
IES
like
primitives.
That
could
benefit
from
some
further
review
and
a
more
standard
approach,
and
especially
around
some
of
the
extended
use
cases
and
usage
patterns
that
these
libraries
see.
So
what
would
have
been
done
in
the
MLS
and
the
sni
context
is
we'd
kind
of
invent.
M
It's
an
ad
hoc
EC
IES,
like
constructs
not
really
using
the
older
stuff,
several
standards
that
already
exist
because
they're
some
of
these
deficiencies
that
have
been
discussed
in
the
list.
Some
a
lot
of
these
existing
standards
are
tied
to
all
primitives,
there's
not
test
vectors
and
there's
not
coverage
for
some
of
the
use
cases
we
see
in
in
deployment
of
some
of
these
libraries.
M
M
M
If
we
can
generalize
from
that
to
something
that
uses
a
generalized
chem
as
the
underlying
primitive,
then
you
know
we
could
end
up
with
a
public
key
encryption
scheme
that
could
could
scale
forward
to
post
quantum
algorithms
better,
because
those
tend
to
be
more
chem
oriented
than
D
H
like
so
so.
The
proposal
here
is
in
the
dot.
Can
you
scroll
me
up
to
get
on
the
screen?
Yeah
so
I
mean
the
proposal
here.
M
It
got
a
little
complicated
in
0
1,
but
the
basic
idea
is
to
take
account
for
the
for
the
public
key
part
and
a
EAD
for
the
encryption
part
and
use
that
to
build
up
a
public
key
encryption,
so
very
much
like
not
trying
to
introduce
any
magic
here.
The
base
case
is,
is
really
really
basically
AEC
IES
with
clearly
defined.
You
know,
here's
how
you
derive
the
keys.
How
do
you
apply
HK?
Do
you
have
to
do
the
right
thing?
That's
that's
mostly.
M
The
mostly
where
the
interesting
stuff
is
is
how
the
how
the
elements
it
combines
together
to
to
derive
the
the
intermediate
values,
the
keys
and
nonces
you
use,
because
it
seemed
useful.
In
some
of
these
cases
we
added
PSK
and
authenticate
what
I
call
authenticated
modes
off
mode
where
the
originator
of
the
creator
of
the
objects,
the
the
person,
is
doing.
The
encryption
can
authenticate
that
they
propose
s
a
either.
M
The
private
key
is
an
asymmetric
key
pair
or
a
pre-shared
symmetric
key
that
that
asymmetric
case
is
it's
pretty
widely
deployed
right
now
in
in
Knakal
context,
with
this
box
api,
which
provides
us
I,
think
it's
the
phrase
it
gets
used
there.
A
sign,
Krypton
I've,
also
heard
the
phrase
designated
verifier
signature
in
terms
of
the
recipient
being
the
only
person
who
can
verify
this
signature,
but
that
that's
sort
of
authentication,
which
is
fairly
widely
deployed,
PSK
mode,
seem
like
a
kind
of
natural
analog
that
would
likely
have
similar
use
cases.
M
Finally,
the
last
bit
of
innovation
here
is
one
of
the
situations
you
see
frequently
and
uses
of
Knakal
is
people
wanting
to
do
effectively
what
is
effectively
a
streaming
mode?
So
you
normally
think
of
something
like
ec.
Ies
is
doing
an
object
encryption
where
you're
going
to
encrypt
a
thing,
but
people
wanted
to
kind
of
have
an
indefinite
length
encryption
and
be
able
to
use
multiple,
a
EAD
in
vacations
off
the
set
off
of
one.
M
You
know
key
encapsulation,
public
key
interaction,
and
so
we've
gone
ahead
and
defined
that
in
draft
oh
one
away,
you
can
set
up
a
context.
You
know
a
single
key
from
which
an
on
stream
Emin
emanates
and
use
that
key
and
stream
of
nonces
together
to
do
multiple,
a
ad
in
vacations
based
on
a
single
public
key
interaction.
M
So
he
kind
of
amortized
the
cost
of
the
public
key
interaction
over
multiply
a
des
encryptions,
so
that's
kind
of
the
overview
of
what's
in
the
draft
and
what
we
kind
of
like
to
to
get
firmed
up
and
specified
and
vetted
reviewed,
etc.
If
we
were
going
to
do
the
work
in
the
research
group
here
so
yeah
that
that's
it's
kind
of
what
we've
got
here,
then
we
posted
zero
zero
back
in
January
had
some
really
positive
list
of
this
discussion
and
some
good
suggestions.
I.
M
Think
that
the
the
strongest
note
we
had
in
that
discussion
was
folks
were
interested
in
moving
toward
a
CEM
construction.
I
think
the
first
draft
we
had
was
more
d-h
oriented
and
folks
thought
that
ken
would
be
an
interesting
approach.
So
you
know
one
we
did
convert
to
that
chem,
oriented
approach
and
added
all
these
other
modes.
I
mean
I
think
would
be
interested
in
feedback
about
whether
things
you
folks
think
these
kind
of
advanced
modes
did
whether
the
various
modes
are
useful.
M
Whether
the
streaming
stuff
is
useful,
I
think
that's
that
a
useful
scoping
discussion
to
have,
as
as
we
discuss
whether
this
makes
sense
for
the
research
group
but
I'm
hoping
we
can.
The
the
research
group
will
be
interested
here,
I'll
admit,
there's
a
little
bit
of
shipping
pressure
right
because
I
as
I
said
at
the
beginning,
there's
working
groups
who
need
something
like
this
and
they're
trying
to
get
their
protocols
done
on
so
I
think
we'd
be
looking
to
get
this
done
in
fairly
short
order,
so
yeah.
M
So
the
sort
of
there's
active
energy
to
contribute
to
this
and
get
some
some
good
work
done
and
also
pause
here
and
then
insert
thanks
for
the
several
people
have
helped
with
this
Chris
Wood
and
Benjamin
and
producer
in
particular,
provided
a
whole
bunch
of
good
comments.
In
addition
to
the
folks
here,
help
that
homeless.
That's
all
I
have
for
now
happy
to
take
questions
or
comments,
expressions
of
interests,
etc.
Thanks
thank.
H
M
G
Erika
scroll
on
it's
good
to
see
it
is
done.
Obviously
we
gave
uses
for
this.
I
think
my
isn't.
Maybe
maybe
this
is
just
the
standard
versus
the
research
on
situation
but,
like
you
seem
to
be
adding
all
the
features.
That's
not
clear
anybody
needs
so
I
think
I
would
be
kind
of
more
fitting
to
keep
it
simple,
but
you
know
maybe
the
chairs
think
that,
like
the
research
covers
a
wider
scope
than
what
needs
to
be
seen
as
immediately
so
but
I
I
know,
I'm
no
uses
for
anything
other
than
basically.
M
G
C
Yes,
I
had
a
question
about
streaming.
Actually,
so
what
was
your
security
target?
There?
Are
you
trying
to
give
guarantees
about
the
order
of
the
chunks
in
the
stream
or
the
totality
of
the
stream,
or
you
know
where
you
going
to
draw
the
line
in
terms
of
security,
because
it's
kind
of
complicated
topic
right,
we're.
M
My
co-author,
like
to
step
to
the
mic,
so
I
will
say
what
is
in
the
draft
right
now.
It
says
that
the
application
is
responsible
for
assuring
the
ordering
for
us
ensuring
things
which
show
up
in
the
right
order.
I
think
things
would
fail
if
you,
if
things
get
out
of
order,
but
I'm
not
sure,
like
what
exact
properties
we
have
around
that
so
Karthik
Karthik.
N
Markovin
Indiana
caught
on
this
draft,
so
he
called
it
streaming.
The
somebody
mentioned
that
keyword
in
the
in
the
discussion,
but
really
this
is
I
would
say,
repeated
use
of
the
CaMKII
over
in
aad
and
the
fact
that
and
we
have
hard-coded
a
counter,
so
you
can
distinguish
between
different
plaintext,
but
we
don't
think
of
that
as
necessarily
achieving
NSTA
or
some
such
definition
right
now,
just
it's
individual
packets,
but
then
many
packets
that
could
that
could
be
encrypted.
Now,
yes,
there
might
be,
you
could
go
further
or
less
so.
M
O
C
N
It's
what
what
do
you
focus
on?
The
current
draft
is
to
make
sure
that
there
is
enough
places
that
you
can
add
information
and
context,
both
during
the
encapsulation
phase
and
during
the
aad
phase,
on
top
of
which
you
could
then
build
in
a
bunch
of
these
things,
including
ordering
reliability,
end
of
stream
kind
of
messages
and
so
on.
But
we
don't
think
that
is
part
of
this.
This
document,
what
we
would
observe
is
that
it
looks
like
most
people
who
use
API
is
like
salt.
C
Thank
you,
and
so
we've
had
a
couple
of
expressions
of
support
and
interest
in
working
on
this.
Maybe
again
it's
worth
taking
a
show
of
hands,
so
you
asked
the
room
if
you
please
stick
your
hand
in
the
air.
If
you
think
this
is
a
good
idea
for
the
research
group
to
adopt
this
okay
I
see
a
lot
of
hands
up.
Any
any
people
think
would
be
a
bad
idea
for
the
research
group
to
adopt
this.
C
Okay,
I
don't
see
any,
and
we
had
a
couple
of
offers
of
support
to
work
on
it,
any
any
additional
people
in
the
room
willing
to
work
on
this
and
help
push
it
forward.
I
see
a
couple
of
hands:
that's
fantastic,
three,
four:
five:
excellent
good!
Okay,
thank
you
and
obviously,
we'll
have
to
go
to
the
mailing
list
to
to
ratify
any
any
a
call
for
adoption.
But
that's
it.
Thank.
P
O
Q
Okay,
so
plans
not
me
in
control
of
the
the
clicking
and
making
mistakes
right.
So
my
first
ITF
this
is
not
an
intelligent
presentation.
This
is
a
presentation
to
try
and
draw
the
intelligence
out
of
you
to
have
you
apply
for
the
next
generation
internet
funding
grants.
So
if
you
can
slide
up,
this
is
a
call
for
you
to
work
on
the
future
of
the
Internet,
the
next
generation
Internet.
There's
a
European
Union
open
calls
that
are
available
at
the
moment
that
can
fund
you
to
work
on
various
programs.
Q
Okay,
and
so
this
initially
started
with
a
no
net
foundation
and
Gartner
working
on
a
report
for
the
European
Commission
to
create
a
vision
for
what
the
next
generation
internet
would
be
and
to
create
an
Internet
of
human
values,
and
so
this
was
a
consultation
process
that
solicited
a
wide
array
of
people,
including
the
IT
effort.
At
one
point
in
time
and
created,
some
draft
topics
went
through
to
this
topic
analysis
and
at
the
moment
we're
in
this
pre
ngi
phase.
Q
You
can't
really
see
this
graphic
because
of
image
compression,
but
where
we're
currently
giving
some
money
or
available
that
will
flow
onto
a
larger,
our
flagship
project
later
on
and
so
part
of
the
ecosystem
that
was
consulted.
Is
these
groups,
including
jayanta
challengers,
the
association
of
research
networks
in
Europe?
Q
So
it's
a
built
on
infrastructure
as
well
as
has
some
pillars
in
order
to
create
this,
this
next
generation
Internet
and
actually
or
the
crypto
forum,
if
you're
building
pillars
and
you're
doing
it
with
poor
underlying
foundations,
then
you're
going
to
have
problems
at
some
some
point
in
time.
So
if
you
have
a
look,
one
of
the
things
that
came
out
of
the
study
was
engineering,
trustworthiness
and
one
of
the
experts
interviewed
I
said
that
we
need
trust
built
from
the
ground
up,
and
so
this
requires
the
you
know.
Q
Q
Ngo
data,
you
for
more
information,
I'm
involved
in
the
NGI
trust
open,
call,
there's
one
called
ledger
for
distributed:
ledger
technologies,
zero
discovery
from
Internet,
Foundation
and
privacy,
enhancing
technology,
and
also
from
that
internet
foundation,
and
so
two
of
two
of
these
open
calls
follow
the
similar
path,
the
deadline
for
the
NL
net
foundation.
Their
calls
are
1st
of
April.
That's
pretty
close
you're,
probably
not
going
to
make
that
unless
you
have
a
free
weekend
head,
but
these
other
open
calls
are
open
until
the
30th
of
April.
Q
So
people
asked-
although
this
is
a
European
initiative,
it
doesn't
exclude
the
rest
of
the
planet.
There's.
Actually,
these
two
specific
projects
explorers
and
think
Nexus
that
are
working
on
EU
u.s.
collaboration.
All
other
participants
need
to
be
European
or
associated
countries
of
Europe,
so
it's
best
to
find
a
partner
in
Europe
to
to
work
on
your
project
with,
unless
you're
already
involved
in
MV,
specific
collaboration
projects
and
they'll
be
more
during
the
lifetime
of
the
NGO
program
to
bring
in
more
countries.
Q
Often
Europe
has
specific
calls,
with
particular
funding
bodies
and
other
countries
to
support
this
sort
of
initiative.
But
at
the
moment
only
an
EU
US
program
exists
and,
and
one
focused
towards
Europe
and
for
the
benefit
of
Europe.
So
it
doesn't
necessarily
mean
it
has
to
be
a
hundred
percent
European
in
the
the
constitution
of
your.
N
Q
Q
The
actual
proposals
to
the
EC
close
very
soon
now
so
that
there
will
be
coordinators
for
three
more
projects
that
will
start
later
this
year,
and
so
the
two
in
green
are
coordinated
by
internet
foundation,
I'm
the
mustard-colored
one
and
there's
a
distributed
ledger
technology
group
spoke
again,
so
the
key
characteristics
of
these,
depending
on
how
much
money
you
want
to
get
and
how
in-depth
your
your
projects
are.
So
there's
only
three
competitive
calls
out
of
my
own
Sasa.
The
first
one
ends
30th
of
April,
we'll
be
running.
Q
Another
open
call
window
in
October
this
year
and
February
early
next
year.
There's
three
categories
of
projects,
viability,
execution
and
commercialization.
So
you
can
get
up
to
a
hundred
thousand
euros
for
the
viability
to
do.
Pilot
and
experimental
work
equally
in
our
net
foundation
have
a
project
where
you
can
get
between
5,000
and
50,000
euros
or
for
similar
work.
Q
The
execution
stage
is
a
co-financed,
a
project,
so
you
would
have
to
provide
or
find
funding
of
90
thousand
euros
to
match
the
ninety
thousand
euros
that
we
would
provide
and
for
the
commercialization
you
would
need
to
provide
two
hundred
thousand
euros
of
matching
funding
to
match
the
two
hundred
thousand
from
from
this
project.
We
don't
take
a
stake
in
your
business
as
a
result
of
that
right.
This
is
this
is
not
not
tied
to
equity
financing
this
one
and
yeah.
Q
This
is
the
other
two
projects
search
and
discovery
internet
foundation,
similar
conditions
that
focused
on
a
different
area
and
ledger
and
distributed
ledger
technologies
offering
up
to
two
hundred
thousand
euros
and
supporting
the
creation
of
a
business
and
of
the
result
of
your
of
your
ideas.
If
you
want
to
contact
me,
do
so,
I
can
put
you
in
touch
with
those
that
you
need
to
talk
to
or
visit
the
NGO
dot
EU
website.
Look
at
open
calls.
Thank
you.
C
Okay,
Thank
You
Brooke
so
see
Co
Brooke.
If
you
want
more
details
or
information
on
this
call,
so
we're
gonna
move
on
to
the
last
fun
presentation
of
the
session.
We
are
running
a
little
bit
behind
about
ten
minutes,
so
we're
going
to
steal
some
of
your
lunch
time.
We
think
this
is
an
important
topic,
so
please
stick
around,
but
obviously,
if
you
need
to
go
then
please
just
leave,
but
please
do
so
as
unobtrusively
as
possible
and
we're
gonna
hand.
Over
now
to
stanislav
he's,
gonna
talk
about
pigs
and
the
pigs
election
process,
hello.
H
Again,
Ozma
schlurf
and
just
a
short
disclaimer
that
it
is
not
some
result
of
some
study,
it's
more
of
a
potential
starting
point
for
our
possible
process
with
selecting
pig.
So
in
bangkok
there
was
an
announcement
of
a
selection
process
and
after
receiving
some
proposals,
as
I
was
an
initiative
to
announce
back
selection
process,
the
aim
is
was
to
select
one
or
more
bikes
for
usage
in
native
protocols.
H
So
a
very
a
very
general
scheme
of
a
very
typical
pack,
which
is
a
balanced
pack.
It's
a
three
phases:
key
exchange
with
protection
with
passwords,
so
the
adversary
that
can
intercept
and
modify
all
messages
cannot
do
anything
better
than
just
online
question
of
password
by
some
request
to
server
or
client
learn
some
key
derivation
phase
and
optional
explicit
kick
information
phase.
H
We
call
a
pack
bounce
back
if
server
and
client
have
the
same
password
stored
at
our
premises
and
augmented
pack,
if
server
side
stores
some
transformation
of
passwords,
so
it
can
be
used
to
protect
against
server
compromised
in
some
sense,
so
general
questions,
I
know
that
is
most
into
questions
for
all
purposes,
but
I
can't
miss
this.
Should
we
select
one
per
call
for
applications?
Can
we
select
one-size-fits-all
pack,
or
should
we
understand
some
distant
set
of
requirements
for
packs
and
then
and
try
to
find
the
one
for
each
set?
H
Two
simple
examples
here
for
augmentation
property
of
it's
great
when
a
pack
is
augmented
and,
moreover,
ways
secured
against
attacks
involving
reputations
as
a
pack?
If
we
talk
about
client-server
protocols,
but
if
we
are
talking
about
protocols
for
messengers
for
re
IOT
for
Wi-Fi
DPP
for
example,
then
the
augmentation
property
is
not
desirable.
There
it's
not
needed
there,
but
it
adds
some
complexity,
so
it
may
be
a
question
whether
we
need
this
property.
Always
second
question
here
is
about
the
information
stage
it's
great
and
desirable.
H
First
of
all,
about
requirements
of
our
RFC
8125
requirements
for
pact
protocols
by
image
it
doesn't
meet,
should
require
matones
protocol
and
what,
with
security
assessment
of
the
spec
is
security
proof
complete?
Is
it
doesn't?
It
have
some
questionable
assumptions
from
the
primitives.
Does
it
allow
you
to
be
sure
that
we
are
secure
for
typical
password
lengths,
so
our
security
bounds?
Okay,
if
it's
a
perk,
okay
for
two
primary
idea,
protocols
like
we
tell
it,
can
shake
basins,
properties
that
are
available
for
zone
for
the
pack.
H
Are
there
some
non-trivial
security
properties
that
must
be
treated
well
when
implement
in
a
pack,
for
example,
resistance
against
a
genetics?
What's
risky
agility
and
onesies
performance,
then
just
a
quick
overview
of
packs
in
cell
G,
starting
from
2013,
there
were
9
packs,
discussed
in
safer
G,
there's
more
pegs
elsewhere
and
sorry.
If
I
forgot
your
favorite
back
here
and
a
very
short
overview
of
all
packs,
then
a
fly
is
a
balanced
pack
that
has
now
a
security
assessment
that
has
its
own
FCAT
for
92,
infirmity,
farsi
of
usage,
India's
natural
parent.
H
In
the
slide
it
has
two
possible
issues.
First
of
all,
it
needs
a
method
of
deterministically
making
of
passwords
2
elements
of
circle
groups
and
secondly,
in
the
draft.
We
were
sorry
in
the
LC.
It
stated
that
an
elliptic
curve
group
must
have
a
factor
of
1.
That
is
a
requirement
that
is,
it
can
be
a
little
tight.
Spec
is
a
very
solid
and
well
study
protocol,
its
bones
protocol,
which
is
minimalistic
in
some
sense,
so
it's
only
one
exchange
in
one
side.
It
has
for
security
proof
in
deputies
paper.
H
This
protocol
doesn't
have
its
own
security
improve,
but
it's
based
on
the
ideas
are
assessed
in
this
people.
It's
also
addressed
in
the
draft
by
h-bombs,
so
it's
an
Augmented
protocol
that
has
some
partly
partial
to
the
proof.
It's
augmented,
but
not
secured
against
recommendation
attacks,
which
are
addressed
later
in
a
pact
protocol.
Suspec
is
basically
a
protocol
that
is
based
on
respect
to
ways
several
modifications,
plus
a
kick
information
stage,
and
it's
separate
security
and
assessment.
H
L
Peck
is
an
Augmented
Peck
that
first
the
proof,
but
has
some
issues
with
this,
so
security
proof
isn't
complete.
There
are
some
issues
with
security
bound.
So
if
we
look
at
our
solely
then
the
security
Pro
features
needs
to
be
repaired.
One
more
issues
here
that
pressure
key
is
generated
by
one
side.
So
it's
more
like
a
key
transport
pack,
not
a
glooming
pack
in
nutshell:
it's
inside
jay
Park
is
a
completely
different
protocol.
It's
based
on
zero
knowledge
proof.
It
doesn't
have
anything
in
common
with
any
other
packs
in
its
duration.
It
has.
H
H
Peak
X
is
a
protocol
that
is
defined
in
draft
Biden
Hawkins,
it's
a
balanced
pack
with
two
phases.
The
first
phase
is
based
on
spec
protocol.
Basically,
and
the
second
phase
in
is
a
very
interesting
phase
that
provides
an
ability
to
bind
the
identities
to
public
key
keys
and
using
this
idea
it
provides
some
good
mechanisms
to
provide
privacy
in
not
sure
it's
respect
to
plus
additional
phase.
H
We
don't
have
a
draft
of
F
for
this
protocol
in
idea
what
was
presented
about
three
meetings
ago
at
Zephyr
G,
but
it
is
not
secured
against
pre-computation
attacks.
In
contrast
with
or
pack
up,
work
is
an
Augmented
PAC
secure
against
permutations
with
golden
complete
security
proof,
it's
more
like
way
of
compile,
compile,
link
any
secure
information,
personation
secure
exchange
to
an
Augmented
page
using
a
believe
SPF.
So
we
take
security
with
both
secure
as
indicated
key
exchange
and
can
obtain
augmented
pack.
It
has
its
own,
so
here's
the
proof,
the
prophets
modular.
H
So
it's
it
applies
to
a
position
of
any
good,
oblivious
pearls
and
any
case
is
secure
exchange.
It
has
two
phases,
not
sure
the
first
phases
registration
phase
when
a
keeper
is
submitted
using
a
secret
obtained
from
oblivious
PRF,
is
impossible
and
then
a
syndication
phase
way
an
envelope
is
obtained
from
the
server
and
then
used
for
aesthetic
exchange,
and
we
have
just
by
Nick
Sullivan
of
usage
of
OPEC.
H
We
still
as
one
country
that
was
presented
yesterday
at
TELUS
working
group
session,
then
we
shot
about
requirements
and
his
protocols
so
point
one
is
about
balance.
Diverse
Augmented
for
all
these
protocols,
it's
clear,
only
aspect
to
Plus
Oak
Park
between
Peck,
indo-pak,
augmented
and
only
operators,
an
additional
security
skilled
against
reputation,
attacks,
it's
more
difficult
about
security
assumptions
or
security
assessments.
Its
noticed
that,
of
course,
all
this,
yes
and
no
must
be
verified
by
a
panel.
H
If
we
run
with
process
but
to
be
shot
for
most
pecks,
there
are
some
kind
of
security
proofs
for
some
of
them
they
are
partial
or,
as
your
project
said,
no
security
proof
for
someone
for
tickets.
We
don't
have
any
security
proof
and
for
all
augmented
pacts
except
OPEC.
We
have
security
proofs
with
model
that
it's
weaker
than
proposed
for
another
requirements.
They
are
more
about
the
document
not
about
the
pack
itself,
so
it's
about
next
slide.
When
we
select
one
or
more
pets,
we
should
do
something
with
the
next
steps.
H
What
we
should
do
with
the
documents
in
cipher
G,
if
you
create
a
new
sofa,
G
document
for
these
pets
or
just
recommendations,
usage
is
dish
not
blessing
crisis
effigy.
In
any
case,
we
must
dress
implementation
issues,
because
security
models
for
PACs
are
quite
difficult
and
quite
different
from
what
we
have
for
a
typical
exchanges.
H
For
example,
they
to
prefer
to
call
spec,
spec
and
pickaxe
require
a
third
set
up
as
a
category
since
must
be
unknown.
Otherwise
back
doors
or
backs
can
be
so,
and
resistance
for
such
a
no
debts
must
be
addressed.
So,
to
conclude,
three
key
questions
to
consider:
we
have
several
effects.
We
have
some
criteria
to
compare
from
and
we
can
give
some
recommendations
for
eg
protocols.
H
C
You
let
me
just
before
we
jump
into
questions,
just
say
that
we're
already
somewhat
behind
schedule,
so
we'll
try
and
maybe
have
about
five,
maybe
ten
minutes
max
of
Q&A
no
and
discussion
before
we
get.
In
fact,
let
me
say
the
say.
Thank
you
on
behalf
of
the
chairs
to
stanislav
for
putting
together
this
really
excellent,
a
detailed
presentation.
We
got
a
lot
more
than
we
paid
for
so
thank
you
very
much.
Okay,
Oh.
K
So
I'm
Watson
Lana
in
case
people,
don't
know
I'm
the
author
of
one
of
the
paid
graphs
I,
don't
want
to
go
into
the
details
of
the
very
comparative
area
space
here.
I
think
we
can
do
that
more
productively
on
the
list.
I
do
want
to
say
that
there
are
existing
applications
and
we
should
take
this
into
account.
Magic
wormholes
definitely
belongs
on
the
list
of
examples
where
balanced
fake
is
needed.
K
That's
really
my
other
quote
by
the
real
self
question.
Why
I
ask
you
is
more
procedural
and
is
the
idea
that
we
were
only
going
to
publish
one
of
the
ones?
That's
a
draft
in
Morocco's,
like
others,
we've
had
a
very
bad
history
to
see.
If
RG
with
a
conscious
like
thing
contests
are
not
something
the.
E
K
E
Dan
Harkins,
thank
you
for
this
regard.
Number
one
I
think
we
could
remove
peak
x
from
the
list
of
candidates
because
it's
not
really
a
raw
egg.
It's
kind
of
a
composite.
The
point
is
to
come:
parlez
a
shared
secret
into
a
trusted
public
key
and
the
result
is
entrusted
public
key
exchange,
and
it's
not
really
it's
different
than
all
the
other
ones
and
I
think
if
we
want
a
balanced
pack
or
augmented
peg,
PKK's
isn't
even
in
the
running
for
that's
luxury.
Thank
you.
R
B
Predates
the
process,
so
we
already
sort
of
committed
to
doing
it,
which
put
us
in
a
very
interesting
position.
I
think
that
any
other
is
not
really
well.
We
also
have
oak
back,
which
is
expired,
but
anything
else
is
not
accepted
by
not
adopted
by
CFR
G.
Yet
so,
hopefully,
we'll
can
narrow
down
on
comparison
first
and
then
we'll
adopt
whatever
matches,
or
you
know
maybe
a
couple
and
then
you
know
try
to
figure
out
whether
we
can
get
down
to
one
or
oh,
whatever.
B
F
R
B
C
P
I
think
in
general
that
it's
fair
to
say
that
bakes
have
been
tremendously
unsuccessful
in
deployments.
There
has
been
recent
interest
again
renewed
interest
from
IOT
environments,
and
so
I
I
would
also
suggest
to,
as
you
do
your
assessment
to
reach
out
to
some
of
those
communities,
because
there
seems
to
be
some
interest
there,
because
people
are
using
those
for
onboarding
and
have
maybe
additional
requirements
and
one
on
the
aspect
that
they
can
to
account,
because
we
are
already
a
few
years
interest.
P
Big
discussion
already
is
to
take
some
of
the
deployment
status
in
the
because,
for
example,
we
had
to
implement
and
stuff
and
now,
if,
like
things
public
and
it's
not
so
nice
to
just
the
random,
implement
other
things,
and
then
they
people
change
their
mind
on
a
regular
basis.
So
it
gets
a
little
annoying.
C
S
Grilling
one
yeah
from
are
we
International
yeah
fastest
things
for
the
initial
comparison
come
closer
to
the
mic:
yeah.
Okay,
sorry
so
yeah,
very
nice
comparison
already.
But
of
course
there
are
a
lot
of
technical
issues,
probably
need
to
be
discussing
in
more
detail,
but
this
came
into
later.
Of
course,
my
main
question
is
that
so
we
have
some
less
than
like
a
more
specific
schedule
and
the
time
time
there
lies
or
something
or
a
little
bit
more
relaxed
about
I,
don't
know
yeah,
so
so.
C
Jers
need
to
discuss
exactly
how
we're
going
to
do.
This
I
think
we're
acutely
conscious
that
when
we
did
all
the
work
on
elliptic
curves,
it
was
very
energy-sapping
and
we
would
like
to
avoid
that
kind
of
situation
again.
So
hopefully
this
may
prove
less
demanding
and
controversial
than
the
elliptic
curve,
but
clearly
we
need
to
put
together
some
kind
of
process
and
schedule.
Here's
the
chairs,
we'll
work
on
that
and
get
back
to
the
research
group
with
a
proposal
for
how
to
move
it
forward.
Okay,.
T
And
there's
definitely
interest
in
the
IPSec
community
there
to
have
a
way
to
log
into
the
VPN,
with
the
password
it's
better
than
what
we're
doing
now,
because
what
we're
doing
now
is
I
person,
one
with
the
Cisco
extension
I
caught
sorry
X
off,
which
is
worse
than
any
kind
of
thing
that
you
said
and
any
pic
is
an
improvement
over
that
so
yeah.
There
is
interest.
H
P
U
Selling
in
the
TLS
working
group,
we've
had
presentations
on
pigs
in
some
discussions,
but
we
really
have
never
had
a
groundswell
of
you
know.
This
is
a
specific
use
case
that
everybody
agrees
on
needs
to
be
solved
with
a
pig,
so
there's
interest,
but
not
you
know
it's
not
necessarily
something
that's
driven
through
the
working
group
right
now.
Perhaps
if
there
was
a
pig
that
that
would
come
up
but
I,
don't
think
we
have
a
set
of
requirements
there
working
group,
Corbett's
Joe.
C
U
J
U
J
Been
Caidic
in
the
kitten
working
group,
we
adopted
draft
to
use
a
spake
and
we
chose
it
because
it
was
balanced
and
because
it
had
the
low
message
count.
One
message:
each
way
we
needed,
which
was
balanced
because
you
know
we
have
to
cooperate
with
with
other
authentication
mechanisms
they're
already
in
use.
If
we.
V
C
Okay,
then
Alexei
will
say
something
about
what
happens
next.
Thank
you.
All
right
or
I
will
so
Cheers.
We
need
to
get
together
and
work
with
some
of
the
key
people
here
and
figure
out
what
the
the
process
and
the
timeline
should
be.
So
look
out
for
us
more
information
on
the
mailing
list,
soon,
bye
that
we
see,
we
hear
the
demand.
We
see
the
different
sets
of
requirements
that
people
have
and
so
obviously
we'll
keep
those
things
in
mind
as
we
move
forward.
C
So
thank
you,
everybody
for
your
contributions,
and
hopefully
this
will
be
a
fun
selection
process
for
everyone
concerned.
Okay
and
I
think
that's
the
end
of
CF
RG.
So
thank
you
for
indulging
us
with
your
some
of
your
lunch
time.
Thanks
a
lot
and
can
we
have
the
blue
sheets
back?
Please,
there's
114
around
somewhere
Thanks.