►
From YouTube: IETF111-CFRG-20210730-2300
Description
CFRG meeting session at IETF111
2021/07/30 2300
https://datatracker.ietf.org/meeting/111/proceedings/
A
B
B
Great
so
welcome
everyone.
This
is
been
long
iatf
and
welcome
to
the
last
session
of
the
of
the
the
whole
event.
So,
if
folks
aren't
aware
this
session
is
being
recorded,
there
is
a
minute
taker
in
cody
md.
Thank
you,
rich
sols
for
doing
so,
jabber
relay
the
jabber
should
be
connected
directly
through
to
the
chat.
So
it's
it
should
be
all
integrated.
If
there's
something
in
jabber
that
doesn't
end
up
there,
please
raise
it
in
the
chat.
B
Here's
the
participant
guide,
blue
sheets
are
automatically
generated.
So
if
you're
logged
in
and
you're
in
here,
you're
in
the
blue
sheets,
nothing
manual
to
do
this
should
be
all
familiar.
This
is
the
last
meeting.
Here's
the
note.
Well,
this
is
the
ietf
ipr
disclosure
rules.
This
is
this
the
same
one
across
all
of
the
ietf
and
irtf.
Every
meeting
you've
attended
should
be
the
same,
so
everyone
should
be
familiar
with
this.
If
there
is
ipr,
please
raise
it
and
the
details
are
here.
B
B
B
B
Does
anybody
have
any
agenda
bashing?
This
agenda
should
be
published
on
online
and
everyone
should
have
seen
it
before
going
once
going
twice.
Yeah,
we'll
we'll
step
through
this.
All
the
way
through
we've
got
a
very
packed
agenda.
So
please
presenters,
try
to
stay
on
time,
we'll
be
using
the
clock,
meat,
echo
mechanism
to
to
give
you
guys
everyone
here,
who's
presenting
a
counter.
B
So
first
research
group
document
status.
We
have
quite
a
few
active
ongoing
documents
here
in
the
group
and
they
are
in
various
states.
So
first
argon
2
is
in
the
rfc
editor's
queue.
Iasg
review,
nothing.
The
irsg
review
we
have
hpke,
which
we'll
have
a
quick
update
at
the
very
end
of
this
presentation
about
speak
to
is
on
draft
20..
This
is
updated
and
the
research
last
call
is
done
on
this
active
drafts,
we'll
be
going
over
quite
a
few
of
these
in
different
presentations.
B
B
So
take
a
look
on
the
on
the
list,
if
you're
interested
in
vrf
that
there
should
be
something
on
the
list
coming
on
coming
soon
about
potentially
a
second
research
group
last
call
there
kangaroo
12
has
been
updated
after
the
second
research
group
last
call
vo
prf,
updated
aead
limits,
updated
you'll,
see
an
update
on
both
of
those
opaque,
updated
cpace.
We
are
on
draft
one
here.
All
three
of
those
will
see.
Updates
in
this
meeting.
Frost
is
unchanged:
rsa
blind
signatures.
B
It
has
recently
been
adopted
and
we'll
see
a
presentation
about
that.
Some
of
the
adopted
documents
that
are
newly
expired
and
need
an
update
here
include
pairing,
friendly
curves,
which
has
been
updated
but
is
currently
expired.
Bls
signatures
and
restreto
decaf
expired
drafts.
These
are,
these
are
the
ones
in
the
queue
the
ones
in
the
list
that
that
are
not
newly
expired,
but
that
were
expired
last
time.
B
We've
had
several
radas
that
were
opened
over
the
last
couple
months,
three
of
which
have
been
verified
since
the
previous
update
and
a
number
of
new
eradas
have
been
opened,
and
so
these
are
in
the
queue
for
the
chairs
to
validate
it's
mostly
against
80,
32
and
84
35.,
and
with
that
we
will,
I
guess
continue
with
the
rest
of
the
presentations
here.
Again
is
the
agenda
again.
I
want
to
open
it
up
again
any
other
agenda
bashes.
Otherwise
we
will
hand
it
over
to
dan
harkins
dan.
C
D
B
C
A
C
C
Okay,
all
right
thanks!
So
next
slide,
please!
So
I
really
like
hpke.
I
think
it's
it's
great.
It's
very
well
defined
and
it's
complete
but
like
with
most
effusive
statements
these
days
it's
qualified,
so
one
of
my
qualifications
is.
It
has
some
bloat
and
that's
when
using
the
nist
curves,
it
uses
the
sec
uncompressed
form
of
serialization,
which
makes
the
public
key
more
than
twice
as
large.
C
So
what
I
want
to
do
is
you
know
if
we
we
can
observe
that
hpke
uses?
What's
what
rfc
1690
calls
compact
output,
where
the
diffie-hellman
shared
secret
is
the
x-coordinate
of
the
the
elliptic
curve
point
that
gets
derived
as
a
result
of
the
ecdh
function?
And
if
the
sign
doesn't
matter
for
the
secret,
then
it
doesn't
matter
for
the
public
keys
that
went
in
to
create
the
secret.
C
C
C
So
that
means
that
if
you
receive
a
a
packet,
you
have
no
idea
what
the
nonce
was
used
to
encrypt
it,
which
wouldn't
be
a
problem
with
guaranteed
order
delivery.
But
if
there
is
a
loss
or
reordering,
then
things
are
going
to
stop
working
pretty
suddenly
and
there's
no
way
to
to
resynchronize
the
context
if
they
do
get
out
of
order.
So
it's
basically
a
tragic
occurrence
which
again
won't
be
a
problem
if
you
have
guaranteed
in
order
delivery,
but
that's
not
the
internet
so
next
slide.
Please.
C
So
I
don't
want,
I
want
to
fix
this,
but
I
don't
want
to
change
the
hpke
apis.
I
think
it's
good
that
users
don't
pass
nonces
through
the
apis.
I
think
it's
good
that
they
don't
have
to
care
about
the
nonsense.
I
just
want
to
make
sure
that,
in
the
event
of
loss,
we're
reordering
that
things
don't
don't
become
tragic
and
the
way
to
do
that
is
to
add
cipher
modes
that
support
deterministic,
authenticated
encryption
so
with
them.
C
C
You
want
outside
of
hpke,
and
the
reason
I
don't
want
to
is
because
I
like
hpke,
as
I
said
at
the
start,
I
think
it's
really
cool
and
I
want
to
use
it
and
I
don't
want
to
reduce
it
down
to
just
the
static
ephemeral,
difficult
key
exchange.
If
I
wanted
one
of
those,
I
would
of
course
use
one,
but
I
want
to
use
hpke
next
slide.
Please.
C
So
I
want
to
do
I
want
to
add
some
dae
ciphers
and
there
is
a
security
there's,
a
paper
that
talks
about
deterministic
authenticated
encryption.
It's
this
robo
wins
shrimpton
paper
referenced
here
from
eurocrypt
in
2006..
It
has
the
security
proof.
If
you're
into
that
sort
of
thing,
it
talks
about
deterministic,
authenticity
and
deterministic
privacy,
and
then
it
has
a
combined
all-in-one
notion
of
deterministic
security.
So
you
know
briefly,
the
the
notion
of
authenticity
is
that
the
adversary
is
unable
to
produce
a
non-trivial
forgery
and
for
privacy.
C
It's
that
the
adversary
is
unable
to
determine
whether
the
output
from
the
oracle
is
the
message
he
sent
or
it's
random
bits
and
he's
barred
from
from
doing
the
trivial
way
of
figuring.
That
out.
The
trivial
way,
of
course,
is
to
ask
the
same
query
twice
because,
as
the
name
implies,
this
is
deterministic,
so
we
can't
conceal
whether
a
given
plaintext
aad
combination
was
encrypted
twice
in
a
sequence
of
of
ciphertext.
C
So
this
is
a
different
security
guarantee
than
the
existing
hpke
authentication
or
aed
modes
provide.
So
there
are
some
security
considerations
to
think
about
for
some
use
cases.
This
won't
matter.
If
the
messages
they're
encrypting
are
item
potent
or
they
can
figure
out
how
to
handle
replay-
or
you
know,
they
just
want
authenticated
encryption
in
their
with
their
lossy
medium.
This
should
be
fine
for
other
cases.
C
So,
of
course,
if,
if
these
security
considerations
are
not
applicable
for
you
and
you
still
have
velocity
network,
you
could
of
course
use
the
hpke
apis
in
the
one-shot
mode.
But
that's
that
would
be
very
wasteful
and
kind
of
a
pain
in
the
ass.
So
I
think
this
is
a
reasonable
approach
to
obtain
resistance
to
packet
loss
and
reordering
next
slide.
C
C
In
the
excuse
me,
the
deterministic
authenticated
encryption
mode,
so
there's
no
nonce
used
and
there's
no
nonce
generated
next
slide.
Please,
so
I
did
write
it
up
as
a
draft,
and
this
is
the
draft
here.
Please
take
a
look
in
the
interest
of
running
code.
I
did
implement
it.
I
added
it
to
my
implementation
of
hpke,
which
is
compliant
with
version
10,
the
latest
and
greatest.
C
So
my
code
can
pass
all
the
test
vectors
for
hpke
in
addition
to
compass,
test
vectors
that
I've
created
that
implement
the
compact
representation
and
the
dae
ciphers.
So
that's
the
running
code.
So
in
the
interest
of
rough
consensus,
I'm
wondering
if
there
is
interest
in
adopting
this
draft
as
a
cfrg
work.
E
C
Yeah,
so
that's
what
I'm
trying
to
to
address
that.
If,
if
that
is
a
concern,
then
you
would
probably
have
to
try
and
either
add
it
as
aad
or
add
it
as
a
tweak
into
the
plain
text,
but
not
all
uses
would
pair,
for
instance.
But
if
you
do,
then
I'm
just
trying
to
give
a
giveaway
to
use
hpke
in
a
lost
unit.
Velocity
network,
which
we
don't
have
today.
F
G
F
You
know
passing
around
the
nonsense
with
the
packets
which
the
slide
before
this
seemed
to
say
you
didn't
want
to
do
so.
It
seems
to
me
like,
like
I'm,
not
really
getting
like
I'm,
not
I'm
not
getting
the
rationale
here
either
we
say
this
is
for
folks
who
really
don't
who
really
do
have
item
potent
messages
that
top
bullet
right?
F
F
F
C
F
F
F
C
So
right,
you're
you're
you're,
adding
something
new,
but
the
packets
can
still
be
reordered
or
lost
and
you're
still
able
to
to
decrypt
a
packet
in
c2
which
you're
not
able
to
do
with
hpke.
Now,
the
only
and
the
way
to
get
around
that
to.
If
we
wanted
to
require
people
to
to
add
nonsense
in
the
in
the
as
aad
it
would
require
us
to
change
the
hpk
apis
and
that
you
know
that's
another
thing
that
I
really
don't
want
to
do.
C
A
H
The
least
appropriate
analogy
here
I
think
I
I
agree
with
dkg
on
this.
I
think
that
there's
probably
a
case
here
for
modifying
the
hpke
interface,
so
that
you
could
say
skip
or
take
the
the
messages
out
of
order.
I
think
that
I
think
you've
made
the
case
for
that
reasonably
well,
I
think,
and
that
would
be
the
the
model
that
dkg
is
talking
about,
and
I
I
have
less
opinions
about
the
item.
H
A
A
A
I
I
I
This
is
something
which
I'm
sure
we
all
already
understand,
but
my
thesis
with
this
internet
draft
is
that
our
intuitive
and
slightly
differing
understandings
are
no
longer
politically
fit
they.
They
do
not
help
us
in
technical
policy
related
debates,
and
so
I
would
like
to
address
this
specific
problem
that
is
well
there's
a
saying
in
business
that
if
you
want
to
change
something,
you
first
must
be
able
to
measure
it.
I
Therefore,
if
you
want
something
to
not
change,
you
must
also
be
able
to
measure
it
in
order
to
determine
that
it
has
not
changed
and
there
are
a
lot
of
people
who
want
to
change
end-to-end
security.
Three
examples,
for
instance,
include
unicef,
who
are
in
a
recent
paper,
were
discussing
the
potential
benefits
of
detecting
abusive
content
that
was
being
shared
over
end-to-end
messengers
by
putting
filters
on
people's
devices
on
people's
clients.
I
I
One
possibility
is
that
we
could
try
and
define
end-to-end
security
and
to
end
encryption
by
saying
what
algorithms
do
we
expect
it
to
deploy.
What
features
do
we
expect
it
to
have?
Who
are
the
actors?
Who
are
the
people
who
will
be
using
it
and
what
will
the
expectations
of
those
people
be?
And
this
is
very
much
the
method
being
employed
by
draft
nodal,
e2e
definition,
it's
another
internet
draft.
It's
got
potentially
complementary
goals
to
this
one,
and
it
specifically
is
looking
at
end-to-end
encryption
rather
than
more
narrow.
I
I
For
instance,
if
we
look
at
section
4.3,
it
makes
commentary
about
private
communications
which
are
intended
to
be
sent
to
intended
recipients
without
making
explicit
the
fact
that
the
recipients
are
the
ones
who
define
the
intention,
as
opposed
to,
for
instance,
and
some
other
interpretation
law
enforcement
deciding
that
they
should
be
intended
as
well.
It
also
talks
about
formally
interfering
with
channel
confidentiality
as
being
a
some
character
of
the
management
of
the
data
as
it
passes
through
the
algorithms
and
the
systems.
I
I
don't
actually
know
what
that
means.
I
posted
it
to
twitter
and
I
wound
up
with
five
or
six
different
interpretations,
two
of
which
interpreted
it
as
a
means
to
enable
law,
legal
access
or
legally
allow
permitted
access,
and
then
there's
also
the
matter
of
it
being
reliant
upon
expectations
and
violation
of
these
expectations
without
actually
saying
what
the
consequences
of
violating
these
expectations
are.
I
So
I'd
like
to
propose
an
alternative
which
is
rather
than
whether
it
looks
like
end-to-end
secure
messaging,
does
it
quack
like
end-to-end,
secure
messaging,
and
so
we
have
to
develop
a
test
for
end-to-end,
secure,
messaging
and
there's?
Fortunately,
three
really
big
hints
in
the
name.
Firstly,
it's
got
to
be
end
to
end
secure
messaging.
This
implies
that
there
are
ends
and
we
should
respect
them
for
a
first
cut.
I
will
just
sort
of
say
ends.
We
will
assume
are
participants
which
might
mean
a
sender
or
a
recipient.
I
Secondly,
it's
messaging
and
by
messaging,
what
I
mean
is
a
system
where
each
individual
message,
the
sender,
composes
and
sends
dispatches
and
at
that
point
is
frozen
into
it.
A
complete
and
immutable
set
of
recipients
whom
the
message
is
readable
or
accessible
by
this
is
distinct
from,
for
instance,
forum
type
software,
where
new
joiners
in
a
group
would
be
able
to
look
at
retrospective
previously
sent
content.
I
What
I'm
getting
at
here
specifically
is
forward
secrecy,
sort
of
things,
but
as
a
surprise,
plot
twist,
we
then
define
recipients,
not
critical
participants.
What
we
do
is
we
say:
a
recipient
is
any
entity
that
can
determine
one
bit
of
plain
text
with
more
than
50
certainty,
and
the
reason
for
doing
it
like
this
is
that
one
can
then
say
that
if
any
recipient
was
not
known
to
the
sender,
at
the
point
of
message,
composition
or
sending
the
system
does
not
implement
end-to-end
security.
That's
it
that's
the
whole
test.
I
It's
there
are
some
sort
of
contextual
things
which
I'll
get
into
in
a
second,
but
it's
very
simply
a
falsifiability
test.
This
also
provides
us
a
obvious
definition
of
backdoor
a
backdoor
is
any
mechanism
which
leaks
bits
to
a
non-recipient,
irrespective
of
whether
it
is
intentional
or
unintentional.
It's
basically
the
logical
inverse
of
a
recipient,
a
legitimate
one.
I
It
also
means
that
we
can
do
surveillance
or
management
or
moderation
or
helper
bots
or
compliance,
or
something
like
that
so
long
as
they
are
over
participants,
rather
than
the
gchq
ghost
scheme,
with
invisible
spooks.
What
we
actually
wind
up
with
is
gchq,
evidently
being
there
for
your
own
safety
or
your
local
police
force
or
whoever
it
might
be.
The
the
platform
safety
team
of
the
platform
that
you're
using
just
so
long
as
it
is
overt.
It's
fine,
nitpicks
and
edge
cases
I'll
go
through
these
really
quickly.
I
Firstly,
there
is
some
metadata
which
is
sensitive
and
needs
to
be
protected,
for
instance,
content
lengths.
We
should
protect
it.
Secondly,
there
is
some
metadata
which,
regrettably,
is
outside
of
the
scope
of
protection
or
just
hasn't
been
implemented.
That's
kind
of
okay,
so
long
as
it
doesn't
leak
anything
about
the
content,
it's
an
old
problem,
thematic
metadata,
rather
than
descriptive
metadata.
I
Thirdly,
encryption
of
the
messages
is
not
actually
necessary.
Some
growing
set
of
new
messenger
solutions.
Don't
actually
do
content
encryption,
they
don't
encrypt
the
messages.
This
is
why
we
call
it
secure
messaging
rather
than
encrypted
messaging
things
like
ricochet,
which
just
pass
messages
direct
point
to
point
over,
admittedly
end-to-end
encrypted
tour
on
your
network
links,
but
they
don't
bother
with
message
encryptions,
which
makes
it
somewhat
distinct.
I
Fourthly,
the
set
of
recipients
varies
between
centralized
and
decentralized
solutions.
This
is
a
technical
knit
for
when
you're,
using
something
like
email
or
ricochet.
You,
as
the
sender,
is
the
person
who
defines
who
the
recipients
are
at
the
point
of
composition,
literally
when
you're
using
something
like
signal
or
whatsapp.
There
is
a
shared
context
of
group
membership,
and
that
is
what
gets
used
to
generate
the
set
of
recipients.
I
Five
groups
should
not
be
allowed
to
have
people
injected
into
them;
they
should
be
enclosed
unless
they
open
themselves
up
for
public
subscription
six,
you
can
cut
and
paste
and
forward
and
quote
and
cite
old
messages.
This
is
an
exception
to
the
fact
that
you
can't
see
retrospective
content.
If
it
gets
re-upped
reboosted,
then
yeah
you'll
see
it
seven.
I
This
is
a
technical
niche
about
self-referentiality,
which
is
that
if
a
participant
is
also
a
platform,
they
have
to
not
cheat
if
they
have
a
mitm
capability
to
see
plain
text
without
acting
as
a
participant
in
the
protocol,
they're,
cheating
and
that's
wrong,
and
then
eight.
Finally,
this
is
the
big
question
and
actually
doesn't
just
mean
participant.
It
means
trusted
computing
base.
I
If
people
are
old
enough
to
remember
the
orange
book,
it's
actually
the
set
of
systems
which
the
user
deems
are
in
their
trusted
path
are
things
that
they
can
rely
on
and
depend
upon.
There's
a
marvelous
paper
which
goes
into
this
from
2011
by
sorry
forgot
the
names
for
the
moment,
clark
and
blumenthal
called
the
end-to-end
argument
and
application
design
the
role
of
trust.
I
It's
a
fantastic
paper
and
talks
about
trust's
trust,
trust
zone,
to
trust
zone
being
the
model
for
end-to-end
going
forward,
and
it's
I'm
surprised
that
it
hasn't
been
referenced
more
in
other
research.
This
means
that
when
alice
accesses
her
messenger
over
rdp,
it
is
not
a
failure
of
the
end-to-end
security.
If
bob
has
a
hacked
app,
it
is
not
a
failure.
If
carol's
phone
storage
is
forensically
analyzed
at
rest,
it
is
not
a
failure
if
dave's
keyboard
or
grammar
app
is
leaking
the
keystrokes
to
local
authorities.
That
is
also
not
a
failure.
I
I
Also
from
that
paper,
I
am
delighted
to
have
rediscovered
rfc
2804
plays
out
the
itf's
position
about
wiretapping
that
the
ietf
does
not
consider
requirements
for
wiretapping
as
part
of
standards,
development
and
that's
great,
even
though
we
are
now
moving
from
the
world
where
wiretaps
were
done
centrally
to
where
they
are
being
and
placed
at
the
ends
on
client
device
devices.
It's
not
something
for
us
to
worry
our
heads
about.
We
should
focus
instead
on
delivering
standards
regarding
what
is
and
is
not
or
how
things
should
work.
I
Where
I
would
like
to
go
with
this
test
is
I
would
like
to
go
for
cfa
I
I
would
like
to
get
it
accepted
and
then
refine
it
to
through
rough
until
we
achieve
rough
consensus,
get
it
thoroughly
battle
tested
and
ship
it
as
an
rfc,
not
the
rfc,
but
one
falsifiable
test
for
assertions
regarding
the
end-to-end
security
of
a
system
and
anything
that
fails
to
meet
that
test
would
just
be
not
compliant
with
this
rfc
there
may
be
other
rfcs.
There
may
be
other
tests.
I
J
I
I
A
I
Secure,
messaging
ricochet
was
the
thing
which
twisted
it
for
me
that
it,
the
messages
are
not
encrypted,
so
calling
them
end
to
end
encrypted
seemed
odd,
even
though
you
and
I
both
deeply
know
that
this
is
going
over
tour
and
that
there
is
end-to-end
transport
encryption.
But
if
we
start
looking
at
transport
layers,
then
we
could
tie
ourselves
up
in
knots
by
saying
is
signal
running
over
tor
the
same
as
signal
running
over
non-tor,
because
we
have
changed
the
transport.
I
It's
a
layer,
boundary
issue
which
I
think
is
maybe
I'm
just
being
overly
uniform
being
a
little
bit
anal
about
it.
But
I
think
it's
clearer
this
way.
It's
regrettable
that
there's
diversity
of
opinion,
maybe
seeing
as
we
are
trying
to
build
various
standards,
but
this
this
is
just
a
test
to
achieve
a
specific
goal,
and
I
have
have
not
yet
come
to
come
to
the
sensation
of
there.
I
From
my
previous
existence
at
sun
microsystems
ps,
I
have
seen
systems
with
extremely
secure
networks
implemented
by
burying
six
foot
of
armored
conduits
under
a
london
major
road
and
no
encryption
either
end
because
of
latency.
It
turns
out
you
don't
always
need
encryption
to
achieve
it.
Although
it's
terribly
helpful.
H
Miss
alec,
I
agree
with
matthew
about
the
the
scope
I
I
do
think
this
applies
to
the
ricochet
exactly
as
you
have
proposed
it.
I
think
it
applies
to
a
number
of
different
protocols,
exactly
as
you
have
proposed
it,
and
using
end-to-end
encryption
as
the
thing
that
you're
attempting
to
to
define
would
be
far
more
useful
than
trying
to
come
up
with
a
new
term,
because
that's
the
term
that
people
use.
I.
H
I
That's
something
I'm
open
to
discussion
on
that,
but
I
I
was
taking
sort
of
some
advice
from
rich
and
a
few
other
people
and
I'm
open
to
sort
of
discussion
about
this.
I
I
don't
know
where
it
should
land
myself,
but
I
looking
at
the
charter
of
cfrg
the
idea
of
shipping
informational
rfcs
in
the
tradition
of
rfc
1321.
F
F
As
far
as
the
ricochet
versus
the
other
messages,
I
think
what
you're
pointing
out
here
is
just
that
story
and
forward
versus
online
connectivity
is
irrelevant
to
the
definition,
and
I
think
that's
fine.
I
think
I
think
it's
it's
a
nice
property
that
that
falls
out
of
the
way
you've
defined
it.
My
concern
with
the
the
term
end-to-end
encryption
is
that
it
doesn't
encompass
all
the
other
cryptographic
properties
that
we
want
besides
encryption,
but
I'm
also
aware
that
the
term
ended.
G
F
I
A
L
Okay,
hello,
my
name
is
armando
faz,
I'm
gonna
present
the
status
update
of
the
boprf
document
yeah.
So,
first
of
all,
let's
this
is
a
brief
reminder
about
what
oprf
is.
This
is
like
the
oblivious
computation,
the
computation
of
the
oblivious
of
the
random
function.
Basically,
this
is
a
two-party
protocol,
where
the
client
interacts
with
a
server
in
order
to
compute
a
sort
of
random
function
under
a
private
key
that
is
hauled
by
the
server.
L
L
So
in
that
case
that
the
client
can,
after
verify
that
this
proof
actually
holds
well
with
this
in
mind.
So
so
what
is
new
from
the
latest
version
of
the
draft
from
the
previous
meeting?
So
basically,
how
does
the
server
compute
this
prf?
There
is
a
blind
mechanism
for
the
client
in
order
to
to
send
the
information
in
order
to
hide
that
information.
So
we
there
are
two
main
methods
for
blinding
this
information.
One
is
multiplicative
blending
or
additive
blending.
L
L
L
We
also
have
the
generalization
of
the
sierra
knowledge
proof,
double
discrete
logarithm
equality
and,
and
then
this
can
be
useful
for
other
protocols.
Finally,
we
update
this
vector
and
made
some
editorial
changes
with
this
in
mind,
so
there
they're
reminding
what
issue
related
to
metadata
and
for
that
I
invited
sufficiently,
which
will
be
explaining
us.
What
is
this
new
approach
about
using
metadata
in
vio
pref,
so
sophie
had
it
over
yeah.
G
Yes!
So
right
now
there
is
a
proposal,
a
pull
request
open
against
the
draft
in
the
github
repository
how
to
add
public
metadata
into
the
protocol.
What
will
be
one
to
be
adding
public
metadata
into
the
underlying
primitive
is
because
certain
applications
of
the
voprf
are
using
are
trying
to
use
metadata
in
order
to
prevent
certain
attacks
or
in
order
to
solve
certain
implementation
blocks
that
might
exist.
G
So
the
proposal
to
actually
add
public
metadata
into
the
peer
prff
is
called
a
peer
peer
and
it
has
defined
in
this
paper
that
has
been
recently
published
on
the
eprint,
and
you
can
read
it
if
you
want
to
find
more
information
about
that
construction,
it
uses
the
same
the
same
specific
functions
for
the
for
the
api
as
the
via
prf.
As
you
can
see
here,
the
only
other
thing
is
that
you
have
a
metadata
that,
in
this
case
of
this
graphics
is
labeled
as
t
you
add
it
to
the
blinding
function.
G
G
Thank
you.
So,
from
a
practical
perspective,
this
is
how
it
looks
like
the
server
and
the
client
input
their
own
metadata.
This
metadata
can
be
of
any
length
and
it
can
be
optionally
added
by
the
client
and
the
server
the
currently
how
we
have
written
in
the
pr
for
the
cfrg
draft.
It
is
that,
even
if
the
client
or
the
server
or
not
the
metadata
is
completely
fine
because
there's
the
mode
in
which
no
string
of
metadata
is
added
and
therefore
an
execution
of
the
critical
runs
without
this
metadata.
G
So
it's
not
bounded
for
you
to
have
into
a
metadata.
So,
as
you
see
here,
the
server
and
the
client
will
be
the
ones
that
in
the
metadata
either
party
cannot,
or
neither
of
them
them
cannot
exceed
like
please
and
just
to
kind
of
give
you
some
a
small
consideration.
So
the
consideration.
What
I
already
said
some
time
ago
is
that
the
metadata
can
be
of
any
length,
but
this
should
be
actually
considered
by
any
application
that
is
going
to
be
using
it.
G
That's
what
armando
just
said
at
the
beginning
of
the
presentation
that
right
now
we
were
adding
additive,
blinding
into
the
vipre
of
construction
and
prprf.
This
notion
of
adding
public
net
data,
that
is
new
construction,
does
not
work
with
additive
blinding
because
it's
not
only
using
the
public
key
for
the
for
the
evaluation,
but
it's
actually
using
a
generator
that
is
raised
to
the
secret
key
plus
the
hash
of
the
metadata.
L
D
D
All
right,
so
this
is
just
a
quick
update
for
opaque.
It
should
be
significantly
less
than
15
minutes.
I
hope
so.
For
those
who
don't
know
opaque
was
the
selected
asymmetric
peak
from
the
the
the
competition
that
was
held
recently,
I
forget
exactly
when,
at
a
very,
very
high
level,
it
basically
takes
a
bunch
of
different
cryptographic,
protocols
and
primitives
and
then
stitches
them
together
in
such
a
way
that
you
have
an
apex
that
falls
out
in
the
other
end.
D
The
protocol
effectively
runs
in
two
phases:
there's
an
offline
registration
phase,
wherein
the
client
basically
takes
their
username
password
pair
and
sort
of
registers,
a
set
of
credentials
with
the
server
storing
those
credentials
on
the
server,
and
then
there
is
an
online
phase
wherein
the
client
uses
its
password
to
effectively
recover
the
credentials
like
recovering
them,
decrypting
them
rederiving
them.
What
have
you
and
then
using
those
credentials
and
a
mutually
authenticated
ake,
wherein
they
effectively
demonstrate
possession
of
the
password?
D
So
if
you
know
the
username
and
password,
you
can
run
the
login
flow
and
authenticate.
If
you
don't
know
that
you
can't
that's
effectively
the
gist
the
document,
because
opaque
is
so
generic
in
terms
of
its
shape
and
structure,
you
could
really
instantiate
it
in
a
number
of
different
ways,
using
different
oprs
using
different
akes.
D
Rather
than
have
a
sort
of
collection
of
options,
we
decided
to
pick
exactly
one
ake
and
pin
down
a
couple
different
algorithms
correspondingly
to
instantiate
it.
So
this
particular
variant
we
call
opaque
3dh
and
that
is
what's
specified
in
the
document
currently
and
there's
some
sort
of
text
in
the
appendix
which
just
describes
if
you
wanted
to
move
towards.
You
know
something
more
like
sigma,
where
you're
using
signatures,
rather
than
key
shares
to
authenticate
here's,
how
you
would
do
so,
roughly
speaking,
it
also
has
accommodations
for
hmqv.
D
Should
you
want
to
go
down
that
route,
tls
1.3
being
a
sigma-like
construction
as
well?
That
is
also
applicable
here
so
between
the
last
meeting
and
this
meeting,
some
pretty
substantial
updates
went
into
the
draft
in
particular
now
there's
this
notion
of
sort
of
internal
external
mode
for
the
the
protocol-
and
this
relates
to
how
credentials
are
what
credentials
are
actually
input
to
the
protocol
and
then
stored
on
the
server
in
the
external
mode.
D
Rather,
what
happens
is
that
the
the
username
password
pair
is
used
to
derive
a
public
private
key
pair
during
the
online
flow
and
then
authenticate,
and
so
these
just
differ
in
terms
of
what
are
the
sort
of
assumptions
about
what
the
client
has.
What
the
interface
looks
like
for
implementations
and
so
on,
the
internal
mode
is
certainly
much
easier
from
an
api
perspective.
D
So
the
protocol
now
accommodates
that
by
basically
making
the
the
server's
response
during
the
login
flow
effectively
randomized
such
that,
if
you
have
the
right,
password,
you're
able
to
sort
of
you,
know
de-randomize
the
server's
response
and
process
it
accordingly.
If
you
don't
have
the
right
password,
all
you
see
are
random
bits,
so
the
server's
response
leaks,
nothing
about
whether
or
not
the
username
happened
to
be
registered
with
the
particular
server.
D
Of
course,
there's
some
obvious
caveats
here,
like
the
you
know,
timing
side
channels
with
respect
to
how
long
the
server
takes
to
actually
compute
the
response
are,
are
applicable
and
relevant,
and
the
draft
has
some
text
and
gives
some
guidance
in
terms
of
how
to
avoid
those
side
channels.
So
implementations
need
to
be
careful
with
respect
to
how
the
servers
hide
responses
generated,
but
in
general
it's
not
too
bad
and
to
help
sort
of
validate
that
you
know
this
particular
code
path
is
tested.
D
There
are
what
we
call
fake
text
factors
in
the
document
at
the
end,
such
that
you
can
make
sure
that
that
particular
code
path
is
hit
and
and
working
correctly,
though,
the
last
big
change
that
we
made
was
sort
of
in
the
ake
phase,
the
3dh
in
particular,
we
used
to
have
slots
from
the
client
to
the
server
and
from
the
server
to
client
for
applications
to
sort
of
plumb
in
sort
of
arbitrary
application.
Specific
info.
You
might
think
of
this,
like
extensions
in
the
world
of
tls.
D
D
But
it's
not
included
in
the
protocol
messages
sent
over
the
wire,
which
has
the
same
effect
as
you
know,
allowing
the
client
server
to
specify
additional
information
for
the
ake,
but
has
the
benefit
of
not
inflating
or
you
know,
changing
anything
on
the
wire.
So
now
everything
is
a
fixed
length
during
the
ake
and
should
it's
really
quite
simple
to
implement,
especially
if
you
use
one
of
the
recommended
configurations
along
with
sort
of
these
major
updates.
D
There
are
a
number
of
minor
updates
as
well
documenting
sort
of
what
the
trust
boundary
was
between
that
you
know
and
receiving
messages,
potentially
untrusting
messages
on
the
wire.
What
sort
of
validation
you
should
do
on
those
particular
messages,
and
so
on?
Also
alignment
with
the
latest
updates
the
vo
pref
draft
to
make
the
test
factors.
You
know,
fall
on,
fall
into
place
and
then
just
general
of
course,
editorial
improvements.
D
We
think
they're
improvements.
They
may
not
be
actually
some
next
steps.
I
basically
think
we're
you
know
we're
at
a
point
now,
where
we
we
consider
ourselves
to
be
feature
complete,
be
great.
If
we
have
more
implementations,
we
have
summon
go
some
rust,
adding
some
in
cnc
plus
bus,
especially
if
you
know
tls
stack
integrations.
Are
you
know
a
a
a
a
future?
You
know
trajectory
for
this
particular
protocol
would
be
useful,
built
on
openssl
boring
a
cell.
D
What
have
you
there's
also
been
requests
for
sort
of
node
or
typescript
javascript
implementations,
so,
having
sort
of
a
you
know,
a
pile
of
implementations
that
are
you
know,
safe
to
use
would
be
would
be
great.
At
this
point,
we
think
we
need
just
additional
review
specifically
review
from
the
crypto
review
panel.
I've
been
discussing
with
the
chairs
what
the
procedure
is
in
terms
of
making
that
happen.
A
D
So
the
the
text
around
here
was
basically
to
say:
you
know
if
you
get
something
centered
with
a
wire
that
was
like
the
identity
helmet,
you
just
drop
it
on
the
floor
and
return
an
error
because
by
the
spec,
the
client
should
never
send
the
identity
element
as
it's
it's
opr
message.
So
that's
that's
kind
of
what
I
mean
about
or
what
kind
of
what
I
mean
about
the
trust
boundaries
so
has
no
effect
on
the
proofs.
A
A
D
To
my
knowledge,
everything
is
done.
The
only
interesting
bit
is
in
the
in
the
existing
uc
formalization
for
the
opaque
paper.
The
the
registration
step
is
the
registration
functionality
is
not
interactive.
It.
It
just
sort
of
assumes
that
the
server
creates
like
the
the
client's
envelope
or
the
encrypted
credentials
honestly
and
like
and
stores
it,
whereas
in
this
particular
protocol
of
course,
we
use
like
an
interactive
protocol
between
client
server
to
run
the
opr
to
encrypt
the
credentials
and
store
them
on
the
server.
D
A
D
A
The
next
obvious
step
is
another
critical
panel
review
to
check
that
all
questions
that
were
raised
during
the
pet
selection
process
have
been
addressed,
and
I
think
that
we
can
start
it
very
soon.
So
please,
let
us
discuss
this
with
alexa
nick,
maybe
next
week
or
in
two
weeks,
and
then
I
think
we'll
start
call
for
crypto
panel
reviews
and
then
after
that,
we'll
have
some
more
questions.
And
after
that
we'll
be
very
close
to
your
costco.
A
D
D
D
So
the
client
inputs,
server,
public,
key
and
message
run
some
blind
function
to
produce
some
output
by
message
and
some
inverse
sends
the
blind
message
over
to
the
server
server.
Does
some
evaluation
on
that
message
sends
back
a
a
blind
signature
and
then
the
client,
finalizes
or
effectively
unblinds
and
internally
verifies
that
the
signature
is
correct,
using
the
the
corresponding
public
key
and
if
all
that
works
out
just
fine,
then
an
out
a
signature.
D
There
was
a
request
to
be
able
to
support
the
full
domain
hash
variant
alongside
the
pss
encoding
invariant
and
our
our
sort
of
response
to
that
was
to
just
just
support
pss,
but
allow
the
salt
length
to
be
zero,
which
is
currently
valid
for
pss,
where
in
the
salt
length
as
a
parameter,
and
we
we
so
we
added
a
test
factor
for
that
particular
variant.
Where
salt
length
is
zero,
you
still
use
the
pss
encoding
function
and
we
added
some
api
guidance
around.
D
So,
for
example,
a
recent
change
that
was
added
was
on
the
server
side
when
you
get
a
message
over
the
wire
that
doesn't
happen
to
be
sort
of
a
valid
representative
of
a
message
that
I
can
sign.
So
it's
not
you
know
an
integer
between
zero
and
n
minus
1.
Where
n
is
the
rsa
modulus,
you
just
abort
that
the
client
for
the
protocol
should
never
send
such
a
message.
D
D
D
So
that
and
given
its
sort
of
strong
connection
to
the
literature,
our
proposal
to
sort
of
leave
it,
as
is
the
the
second
open
issue,
is
to
whether
or
not
we
should
extend
this
to
support
partially
blind
signatures.
So
it
is
possible
to
do
this
with
rsa,
but
it's
sort
of
funky.
The
the
basic
idea
is
you,
you
know,
sort
of
pin
the
modulus
and
then
from
that
you
you,
you
try
to
derive
different
public
private
key
pairs.
D
D
But
it's
also
sort
of
problematic
from
a
performance
perspective,
because
it
means
with
very
high
probability
that
the
public
exponent
is
not
going
to
be
three,
which
is
typically
done
for
performance
reasons.
You're
likely
going
to
have
exponents
that
are
significantly
larger,
so
actually
doing
the
rsa
operations
is
going
to
take
a
a
much
longer
amount
of
time.
D
So
basically,
given
that
this
is
sort
of
awkward,
not
a
a
common
practice,
it
probably
needs
additional
security
analysis
in
terms
of
whether
or
not
it's
safe,
given
that
the
analysis
was
done,
sort
of
early
2000s
and
and
is
a
bad
performance.
I
can't
remember
if
I
said
that
already
I
I
think
the
the
editors
would
propose
that
we
just
closed
this
as
well
with
no
resolution.
D
A
Thanks
a
lot
chris,
I
would
share
my
opinion
that
I
understand
that
the
current
status
of
analysis
of
rsa
blind
signatures
made
by
and
the
previous
works
the
status
is
quite
stable.
So
this
is
quite
a
mature
set
of
results.
In
contrast
to
a
lot
of
ecdsa
engineer
based
blood
signatures
where
there
is,
there
are
a
lot
of
schemes
that
have
been
broken
in
a
couple
of
years
after
being
created.
D
A
G
D
D
I
can
certainly
confirm
with
him,
but
as
far
as
I
know,
yes,
they've
all
been
tested
for
interrupt
because
the
output
is
just
like
a
signature.
That's
you
know
verifiable
with
any
pss
stack,
so
it's
really
just
the
you
know.
Can
you
can
you
produce
given
these
random,
given
these
inputs
on
the
client
side,
this
expected
signature
on
the
output
side.
G
F
D
So
since
the
last
version,
there
hasn't
been
a
lot
of
change,
though
martin
did
a
lot
of
work
in
revisiting
some
previous
some
previous
papers
and
adding
analysis
for
aads
that
are
useful
or
used
in
the
context
of
tls
1.2,
specifically
those
aads
gcm
variants
that
don't
do
nonce
randomization,
as
is
done
with
the
ls
1.3
previously
we're
just
assuming
that
sort
of
you
know
these.
These
blessed
ciphers
that
we
use
in
very
tls
and
quake
are
those
that
we
want
to
include
in
the
analysis.
D
But
I
forget
where
the
request
came
from
for
the
tls
1.2
variant,
but
regardless
it
came,
it
was
a
reasonable
request
and
martin
did
the
work
to
add
it.
So
thank
you.
Martin
also
added
some
limits
in
the
draft
based
on
you
know.
You
know
reasonable
parameter
sizes
like
reasonable,
fixed
packet
sizes,
reasonable
bounds
for
the
advantage
of
whatnot.
D
So
if,
if
you,
you
know,
if
you're
using
this
sort
of
document
as
a
consumer,
you
just
kind
of
want
to
know
what
is
the
content
that
I
plug
into
my
protocol?
Hopefully
that
table
will
help
you
and
then
there
was
also
some
some
various
editorial
cleanup
and
the
next
revision,
which
we
hope
to
come
soon.
We're
going
to
fix
some
issues
that
we
both
missed
in
the
tl
1.2
numbers
felix.
D
Our
resident
expert
did
a
more
careful
pass
than
we
did
and
he
has
a
pr
up
that
we
just
need
to
land.
They
also
have
a.
They
also
did
an
analysis,
felix
and
some
other
student
analysis
of
joshua
paulie
in
the
multi-user
setting
and
are
going
to
send
a
pr
to
the
draft,
adding
those
limits
alongside
the
gcm
ones,
when
it's
available,
so
we're
sort
of
waiting
for
that
to
come
to
sort
of
complement
the
existing
gcm
limits
that
we
have.
D
So
the
the
other
issue
is
on
siv.
There
is
a
there's,
a
request
to
add
it,
and
basically
it's
an
action
item
that
needs
work,
given
that
it's
it's
not
currently
employed
by
any
of
the
the
sort
of
major
ietf
protocols.
Sort
of
our
conclusion
would
be
to
close
this
and
punt
it
to
a
future
draft.
Should
someone
feel
inclined
to
do
that.
Initial
analysis
extract
it
from
the
relevant
work
and
and
document
it
in
the
same
sort
of
context
we've
done
here.
D
Alternatively,
we
very
much
welcome
someone
to
contribute
a
pr
that
actually
adds
these
limits
on
our
behalf.
We
just
haven't
had
the
time
to
get
to
it
yet
quickly.
Looking
at
the
chat,
thank
you,
martin
for
filling
those.
Yes
dkg
was
asking
about
adding
ocb
or
ax
or
any
other
any
other
modes
and
yeah.
D
D
B
B
M
M
And
since
then,
we've
been
I've
been
working
with
bjorn
and
julia
on
the
secure
analysis
in
which
we
provide
analysis,
not
only
the
basic
version
of
cpas
but
actual
the
actual
variants
that
are
being
implemented,
so,
in
particular
the
current
space
protocol
variants,
they
we've
been
able
to
show
that
they
provide
strong,
secure
guarantees.
In
particular,
they
we've
been
able
to
show
that
they,
they
are
securing
their
universal
composibility
model
and
they
actually
achieve
adaptive
security
under
a
variant
of
the
of
the
computational
development.
M
Assumption
is
actually
known
as
the
simultaneous
development
assumption
and
in
the
analysis
we
also
have
been
able
to
show,
as
julia
mentioned
in
the
last
meeting,
instead
of
analyzing
the
map
to
point
function
as
an
ideal
as
a
random
arc,
we
actually
try
to
separate
that
in
into
the
map
to
function
from
the
the
hash
of
the
password,
so
we
actually
the
way
we
compute.
The
generator
is
a
map
to
function
of
the
hash
of
the
password.
M
M
So
one
thing
that
has
become
that
we
tried
to
clarify
more
recently
has
been:
they
rely,
the
the
way
we
rely
on
their
session
identifiers,
in
particular,
since
we're
working
in
the
uc
model.
We
assume
that
before
cpas
starts,
the
the
application
has
to
provide
a
unique
session
identifier
to
start
the
session
which,
which
is
required
for
composibility
for
multi-session
security,
and
this
is
a
so.
We
try
to
clarify
this
now
in
the
in.
M
The
current
version
of
the
draft
of
the
paper
which
currently
has
been
is
under
submission
to
asia,
crypt
and
in
this
new
version.
So
we,
as
I
said
beside
the
main
change,
has
been
clarifying
the
the
role
of
the
unique
session
identifiers
and
we
also
use
the
opportunity
to
clarify
the
proof's,
improved
readability
and
the
security
definitions.
M
But
regarding
the
session
identifier,
as
I
said
that
which
is
so,
they
are
required
for
composibility
guarantees
and
they
because
of
that,
they
need
to
be
added
for
as
input
to
all
the
hash
functions
that
we
use
in
our
protocol
and
they
need
to
be
established
before
running
c
pays.
So,
and
this
is
one
of
the
issues
that
I
think
feng
hao
mentioned
in
his
recent
paper
on
knee
print.
M
M
One
of
the
next
steps
that
we're
going
to
provide
is
actually
a
game
day
secure
analysis
without
the
session
identifiers,
and
the
idea
is
that
suppose,
now
that
you
don't
have
this,
this
session
identifiers
are
not
available.
We'll
see,
pace
remain
secure
and
similar
to
the
other
cfrg
candidates,
like
aspect
2
or
jpeg.
M
We
can
also
provide
a
game
based
proof
for
for
cpace,
which
does
not
rely
on
the
session
identifiers
and
in
terms
of
guarantees.
The
guarantees
would
be
essentially
similar
to
that
of
the
other
product,
the
non-uc
particles,
so
in
particular
like
in
the
proof
of
aspect
2,
we
can
provide
a
proof
of
weak
forward
security
for
cpas
if
we
don't
consider
the
sids
and
this.
M
So
but,
as
I
said
yes,
session,
ids
can
be
more
details.
Perhaps
this
is
one
of
sometimes
when
we
provide
the
protocol
that
are
secure
in
the
uc
environment.
We
always
assume
that
these
session
identifiers
are
provided
by
the
application
and
we
don't
pay
too
much
attention
to
it.
But
I
think
one
of
the
important
points
of
the
sea
based
traffic
is
to
try
to
clarify
the
situation
so
in
by
that
and
that's
why
we
we
want
to
make
sure
that
we
have
a
version
of
the
secure
analysis
with
and
without
session
ids.
M
N
Thank
you
very
much
for
your
presentation.
It
seems
that
there's
a
broader
issue
behind
the
draft
here,
because,
during
the
the
speak
comp
or
during
the
take
competition,
one
of
the
main
things
that
brought
up
was
the
importance
of
the
uc
proves
important
to
use
the
proofs,
and
now
we
learn
at
the
end
that
actually,
no
you
can't
you
can't
implement
and
deploy
it.
We're
going
to
use
a
game
based
proof
for
the
winner,
and
this
depends
on
hash
to
curve
as
well.
N
So
you
know,
do
we
need
to
reconsider
the
the
compass
realizing
that
okay,
we
actually
need
game-based
proofs.
We
need
to
assume
we
need
to
change
the
number
of
rounds
to
have
to
incorporate
this
id
if
that's
being
used
or
do
we
just
go
on
and
publish
this.
We
understand
that
okay,
it
is
what
it
is.
I
I
still
support
publication,
but
I
think
that
that
raises
a
question
about
how
we
run
how
we
run
this.
Our
contest
in
the
future.
M
M
M
M
Jpeg
uses
a
version
of
this
square
defilement
assumption,
but
these
are
like
those
are
all
similar
assumptions
in
the
in
the
underlying
group
in
terms
of
session.
Ids
is
a
matter
if
you
want
a
security
analysis
with
in
the
uc
model.
The
all
of
these
particles
will
require
an
additional
that
the
application
provides.
This
unique
id
session
id
so
doesn't
matter
if
we're
talking
about
aspect
2
or
cpase
or
jpeg,
so
they
all
would
need
that
and
once
the
so,
if
you
consider
uc
security,
you
have
more
or
less
you
would.
M
M
E
E
I
also
wanted
to
suggest
that
there
we
should
we
need
to
coordinate
on
the
sid
story
across
both
drafts.
I
think
because
I
think
this
is
theoretically
an
issue
for
both.
I
guess
different
camps
of
people
disagree
on
what
the
sid
means
in
the
uc
model
and,
like
you
know,
what
does
it
come
from?
Does
it
come
from
the
environment,
or
does
it
come
from
something
else,
but
in
any
case,
I
think
I
think
the
story
is
theoretically
the
same,
so
I
think
there
needs
to
be
some
coordination.
D
Yeah
just
one
I
guess
one
could
follow.
Well,
I
mean
I'm
not
the
uc
expert.
So
certainly
we
talk
with
hugo
and
others
to
see
to
what
extent
sort
of
the
sid
needs
to
be
accountable
or
coordinated
with
cpace,
but
on
the
the
game
based
proof
requirement.
Chris,
were
you
suggesting
that
we
also
block
opaque
pending.
E
We
block
on
anything
like
I
think
it's
it's
I
I
doubt
I'm
I
it's
there's
pr,
there's
not
going
to
be
an
attack
in
a
game
based
model
on
against
opaque.
It
seems
really
really
unlikely.
I
just
think
that
I
I
wouldn't
block
on
it.
I
just
think
it's
a
really
good
idea
for
both
protocols,
not
just
cpas.
D
I
see
yeah,
I
mean
it's
interesting
that
the
the
sad
problem
is
not
sort
of
manifested
in
the
same
way
in
the
development
of
opaque.
I
I
I'm
like
completely
oblivious
to
it.
If
it
has
so
I
I
I
don't
understand
why
that
that
is
the
case,
but
anyways
it's
subtle
enough
to,
though
it
probably
warrants
further
investigation
discussion
with
hugo
and
michelle
another,
so
we
can
take
it
to
the
list
or
offline
or
whatever.
B
B
B
D
All
right,
so
this
is
this-
should
be
fairly
quick.
This
is
just
responding
to
an
issue
that
francis
gets
raised
on
the
list.
It's
sort
of
an
unfortunate
issue,
so
as
a
reminder,
hpe
has
in
it
a
number
of
different
dependencies,
one
of
which
is
a
cam,
one
of
which
is
the
kdf
and
the
other,
which
is
an
aad,
and
there
is
a
registry
created
and
maintained
by
this
document
for
each
different
type
of
algorithm.
D
We
did
not
realize
at
the
time
that
there
exists
already
a
registry
for
aad
algorithms
that
is
already
maintained
by
anna.
That
is
the
first
link
here,
and
this
was
pointed
out
to
us
from
franciscus
on
the
list.
The
registry
that
is
in
that
is
already
in
there
or
already
on
iana,
and
that
is
in
the
hpe
document
are
somewhat
different,
though,
for
starters,
the
hp
registry
requires
that
each
algorithm
specify
the
length
of
the
key
and
the
length
of
the
nonce
as
distinct
parameters.
D
D
These
are
the
two
most
obvious
ones,
at
least,
first
of
which
is
to
just
continue
using
the
hpd
registry
and
use
that
definitely
going
forward,
the
second
of
which
is
to
switch
over
to
the
existing
registry,
extend
it
with
hpk
specific
parameters,
potentially
adding
in
you
know,
fields
indicating
whether
or
not
the
algorithms
are
recommended,
or
they
meet
the
security
that
the
security
bar
the
ind
cca2
requirement.
That
hpk
requires
this
is
sort
of
problematic,
in
that
it
would
be
a
breaking
change.
D
That
would
be
good
to
know.
Basically,
my
our
proposal,
after
speaking
with
the
editors,
is
to
go
with
option.
One
continue
with
way
things
are,
and
just
sort
of
ignore
that
this
regis
existing
registry
is
out
there,
and
that
seems
like
it
would
be
the
the
simplest
thing,
though,
at
this
I
mean
I
would
like
to
hear
what
others
think.
H
D
D
We
I
I
did
look,
but
I
did
not
see
anything.
That
does
not
mean
it's
not
there,
but
I
mean
if,
if
we're
gonna
stick
with
this,
if
the
registries
are
similar
to
the
the
ada
one
that
we
have
here
and
if
we're
gonna
stick
with
the
hpk
option,
I
imagine
we
would
stick
with
the
hp
options
for
those
two
algorithms
as
well
for
similar
reasons.