►
From YouTube: IETF114 SECDISPATCH 20220726 1400
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).
B
A
C
A
D
E
B
So
you
could
use
share
slides
so
then
I
can
yeah.
B
B
I
do
great
so
here's
the
note.
Well,
please
take
note
of
the
note
well
and
Richard.
Barnes
is
remote,
as
my
co-chair
he'll
be
helping
with
a
few
a
few
very
important
functions
like
helping
to
keep
this
on
track
in
the
the
summary
outcomes
and
anything
else,
I
miss.
So,
let's
see
meeting
tips
in
person,
participation
so
from
the
working
group
chairs
yesterday,
there's
an
emphasis
on
make
sure
you're
wearing
your
mask
in
the
room.
B
If
you're
up
at
that
mic,
you
also
wear
a
mask
the
only
time
you
don't
need
to
wear
a
mask
if
it
is.
If
you
are
the
presenter,
please
use
the
meat
Echo
to
join
them,
IQ,
even
if
you're
in
the
room,
so
that
we
can
keep
things
fair
in
between
remote
and
local
participants.
B
And
let's
see
code
of
conduct
make
sure
you
respect
your
colleagues
and
move
on
I
hope
people
know
this
by
now.
So
now
the
SEC
dispatch
process.
B
Sec
dispatch,
is
here
to
recommend
next
step
for
work
as
an
aide
to
the
area
directors.
In
terms
of
how
documents
get
Shepherd
shepherded
on
you
know,
they
have
several
possible
outcomes,
and
this
meeting
is
to
help
steer
those
outcomes
by
each
of
you
reviewing
the
documents
and
providing
feedback
listening
to
the
presentations
and
helping
to
determine
the
possible
Direction.
So
it
could
be
that
we
direct
it
to
an
existing
working
group.
If
that's
possible,
that's
ideal
propose
a
new
focused
working
group.
B
If
it's
a
small
body
of
work
and
there
there
could
be
a
recommendation
for
a
mailing
list
or
a
buff
A.D
sponsorship.
If
it's
an
individual
draft
and
doesn't
have
the
need
for
a
larger
format,
it
might
be
that
the
draft
requires
additional
discussion
and
so
that's
a
possibility
and
there
could
be
a
mailing
list
just
for
that
or
continuing
on
the
SEC
dispatch
list,
and
then
also
that
the
ietf
may
not
work
on
some
something
as
the
outcome.
B
All
right
great,
so
we
will
go
through
each
of
the
three
items
submitted
today.
Each
have
15
minutes,
including
discussion,
so
10
minutes
to
present
five
minutes
for
discussion,
and
with
that
we
can
begin
with
the
terminology
for
post
Quantum
hybrids
and
I'll.
Get
those
slides
up.
Richard
did
I
miss
anything.
Are
we
good.
D
I
have
one
last
thing
for
our
chair
session
here,
which
is
that
we're
having
a
bit
of
change
in
leadership,
so
Mohit
has
resigned
his
chair
to
take
advantage
of
some
other
opportunities.
D
I
just
wanted
to
take
a
minute
here
to
thank
Rohit
for
his
service
here,
Round
of
Applause
for
Mohit
and
thanks
for
his
his
work
as
our
as
our
second
dispatch
coach
here.
So
thanks
to
God.
G
Hi
everyone
I'm
Floyd,
Driscoll
and
I'm
here-
to
propose
this
draft
on
terminology
post
Quantum,
traditional
hybrid
schemes.
So
next
slide
please.
So
the
background
to
this
is
as
I
suspect.
Most
people
in
this
room
know
given
the
development
of
a
sufficiently
large
quantum
computer,
a
lot
of
the
algorithms.
Well,
the
algorithms
that
we
use
for
asymmetric
cryptography
at
the
moment
will
be
vulnerable
to
the
quantum
computer.
G
Now
it's
kind
of
it's
important
to
mention
that
we
don't
actually
know
that
such
a
computer
is
ever
going
to
exist,
but
we
have
to
act
as
if
it
will-
and
there
were
quite
a
number
of
presentations
yesterday
about
the
kind
of
the
transition
of
algorithms,
the
algorithms
that
missed
are
going
standardize.
G
G
So
during
the
algorithm
transition
period
there
might
be
a
desire
or
there
is
a
desire
for
protocols
which
use
both
post,
Quantum
and
traditional
algorithms,
so
so-called
hybrids,
although
so,
unsurprisingly,
there's
a
terminology
draft.
So
that's
under
discussion
there's
already
a
lot
of
ongoing
work
to
standardize
these
constructions,
but
well
both
ongoing
and
completed
work
in
lamps
in
ipsec
in
TLS
and
drafts
on
terminologies
have
been
drafts
on
terminology
have
been
suggested
a
few
times,
but
specifically
at
the
lamps
interim
in
April.
It
was
discussed
so
next
slide.
Please.
G
There's
actually
quite
a
few
reasons
for
this
and
I've
tried
to
separate
into
some
bullet
points,
but
I
suspect
people
can
come
up
with
more
so
the
first
is
we're
using
a
lot
of
different
words
in
different
places.
So
you
see
the
word
hybrid.
You
see
dual
multi-key
multi-algorithm
composite
non-composite,
sometimes
we're
using
these
as
synonyms
and
sometimes
we're
using
them
to
mean
subtly
different
things
like
one
will
be
a
subset
of
another,
and
it
actually
varies
from
draft
to
draft
how
these
words
are
being
used.
G
So
it
would
be
really
useful
if
we
could
decide
on
a
set
of
words
and
then
use
them
consistently.
That's
both
nice.
It
makes
it
easier
to
read
drafts,
but
it's
also
security
critical
because
it
allows
us
to
discuss
so
we're
not
not
described,
discuss
things
across
purposes,
so
that
makes
analysis
easier.
It
makes
comparison
easier.
B
Before
I
go
on,
I
forgot
to
check
if
we
have
minute
takers
so
can
we
get
a
volunteer
I
know
we
have
Richard,
noting
the
outcomes,
but
more
detailed
minutes
would
be
nice.
G
Olsen
so,
secondly,
there's
multiple
types
of
hybrid
constructions,
so
the
the
big
difference
that's
been
discussed
in
lamps.
Quite
a
lot
is
the
difference
between
composite
and
non-composite
constructions.
It
would
be
really
useful
to
have
a
reference
for
what
we
mean
by
this
and
there's
probably
other
things.
I
haven't
thought
of
there.
G
Thirdly,
if
we're
talking
about
functionality-
oh
sorry,
different
hybrid
schemes
aim
to
achieve
different
properties.
G
Some
of
these
have
kind
of
I
guess
come
equivalent
elsewhere
in
cryptography,
so
things
like
backwards
compatibility,
crypto,
agility,
but
others
don't
so
hybrid
confidentiality,
hybrid
authentication,
I'm,
not
actually
100
sure
what
we
mean
by
hybrid
authentication
so
probably
good
to
discuss
it
again
like
with
sort
of
the
earlier
point.
It
would
be
good
to
have
a
reference
for
these.
It
makes
analysis
easier.
It
makes
comparison
easier.
G
And
thirdly,
the
word
hybrid.
Is
you
already
used
in
cryptography
to
mean
a
combination
of
symmetric
and
asymmetric
algorithms,
so
for
an
EG
and
hpke
doesn't
matter
that
we're
overloading
the
word
hybrid?
Some
people
think
it
does.
Some
people
think
it
doesn't.
It
comes
up
quite
a
lot.
It
would
be
good
to
decide
and
then
move
forward
in
the
next
slide
please.
G
So
the
proposal
is
an
informational
draft
to
standardize
a
glossary
for
post
Quantum,
traditional
hybrids,
everything's
up
to
for
discussion.
So
that's
the
phrasing
I'm
using
at
the
minute,
but
that
can
change.
The
aim
is
to
ensure
consistency
across
different
protocols,
different
standards
and,
hopefully
different
organizations.
G
Next
slide.
Please.
G
Why
we
need
this
is
I
suppose,
basically
what
I
discussed
two
slides
ago
it's
to
make
it
clear
what
security
properties,
a
particular
hybrid
construction
claims
and
then
to
be
able
to
assess
if
it's
achieving
those
security
properties
it's
to
enable
easier
comparisons
and
solutions.
That's
both
within
working
groups,
but
also
across
working
groups,
because
it
would
be
really
useful
to
be
able
to
pull
our
knowledge
and
to
transfer
solutions
that
work
from
one
setting
to
another
where
that's
appropriate
and
then.
G
G
G
I
think
on
the
list
there's
been
discussion
of
the
idea
of
some
sort
of
new
group
for
post
Quantum
migration.
If
such
a
group
existed,
this
would
fit
really
well
there,
but
it
relies
on
the
group
existing,
otherwise
cfrg
might
make
sense.
This
is
really
more
about
the
protocols
and
the
kind
of
the
engineering
part
than
the
algorithms.
So
I,
don't
know
how
that
fits.
Lots
of
work
like
this
has
happened
in
lamps,
but
again
it's
not
just
about
certificates
or
maybe
I.
G
Don't
really
know
how
ad
sponsorship
works,
but
maybe
it
fits
there,
but
I'll
leave
that
to
this
room
to
decide
and
that's
basically,
everything
I
had
to
say
if
this
is
dispatched,
really
really
Keen
to
work
with
people
on
it,
discuss
it
with
people,
make
any
changes
that
kind
of
the
ITF
wants.
This
is
essentially
useless.
If
it's
just
me
writing
down
a
list
of
words,
but
if
we
can
kind
of
all
agree,
then
I
think
it
could
help
us
move
forwards.
G
That
next
slide
has
a
link
to
the
draft
on
it.
Whatever
slide
people
want
up,
is
good
cool,
so
yeah
any
questions
or
discussion.
H
Paul
Hoffman
I'm
concerned
about
a
single
draft
that
is
doing
the
terminology
both
for
key
exchange
and
for
signatures.
I
think
it's.
It
would
be
nice
if
we
could
pull
them
all
together.
I
think
that
that's
going
to
be
very
challenging
for
you
and
we
need
to
have
hybrids
for
both,
but
I
think
trying
to
do
them
all
at
once
and
as
you've
seen
with
hpke
and
such
I
think
you're
going
to
have
a
terminology
mismatch
there.
So
I'm
just
suggesting
to
make
your
life
easier.
Do
key
exchange.
G
Foreign
yeah,
that's
a
that's,
a
very
reasonable
Point.
At
the
moment,
there's
yeah
signatures
are
more
difficult
than
key
exchange.
Yeah,
that's
a
reasonable
Point.
All.
I
Right
yeah
preliminary
question:
do
you
know
how
much
the
research
Community
is
converging
on
terminology
here.
G
So
I've
not
read
something
which
kind
of
defined.
This
is
how
it's
going
to
work
everywhere:
Jenna,
for
example,
NIS
just
Define
it
in
their
FAQs.
How
they're
going
to
use
hybrids
terminology
I
think
there
are
two
differences
between
the
ITF
and
the
research
Community
one
is.
G
This
is
the
only
place
I've
heard
there
be
concerns
about
the
use
of
the
word
hybrid
at
all,
so
elsewhere,
people
just
sort
of
use
it
and
assume
that
it's
going
to
be
understood
what
it
means
in
context,
and
the
second
is
that
there
is
language
here
which
is
specific
to
kind
of
IDF
protocol
development.
So
in
the
protocol
space
rather
than
the
algorithm
space.
I
I
mean
I
guess
so,
where
I
was
going
with,
that
is
I
prefer
not
to
see
us
develop
a
duplicate
terminology
to
what
the
academic
Community
is
using.
That
seems
like
very
confusing,
so
the
sense
of
which
we
can
hoist
theirs
the
better.
If
we
can't,
then
that's
unfortunate
I
suppose
that
suggests
to
me
to
going
through
these
examples.
I
I
think
it
is
much
is
a
bad
choice,
because
if
the
intention
is
that
people
we're
going
to
ask
everybody
uses
internology,
then
these
projects
just
doesn't
get
the
kind
of
review
quite
across.
You
know,
cutting
review
and
agreement
that
we
want
I,
think
that
was
kind
of
frankly.
I
I
understand
how
the
glossary
happened,
but,
like
I,
think
it's
kind
of
an
anti-pattern
I
think
so
on
my
sense,
given
sort
of
my
bias
towards
agreeing
with
the
academic
Community,
but
it
is
in
cr4g,
which
is
our
best
relationship
with
them.
I
I,
don't
think
you
know
I
guess
if
we
had
a
new
PQ
group
that
might
be
okay,
but
we
don't
out
of
things
again,
doesn't
get
the
kind
of
cross-cutting
review
that
you'd
need
for
that.
So
I
think
I
always
say
either
a
new
group
or
cfrg.
I
And
I'm
sure
you'll
you'll
I
do
I,
do
generally
approve
of
creating
one
form,
one
attractive
nuisance,
to
gather
all
the
discussions
about
terminology
and
it's
a
good
choice.
Foreign.
J
Just
said,
I've
worked
in
some
groups
in
ISO
that
were
doing
terminology
documents
and
they
can
take
years.
They
we
we've
had
two-hour
conference
calls
on
what
the
meaning
of
the
term
node
and
in
the
two
hours
we
did
not
come
to
consensus
on
what
the
definition
was.
So
it's
a
mess
and
it's
definitely
not
an
ad
sponsorship
thing.
J
B
K
Sorry
Sophia
Philly
from
Brave,
please
thank
you
very
much
for
doing
this.
It's
really
it's
really
great.
The
second
thing,
maybe
addressing
a
little
bit
about
the
research
community,
that
I'm
from
there's
not
much
enough
unification
actually
of
terminology
it.
There
is
some
for
the
key
exchange
part,
but
mostly
because
of
the
standards
from
nist
and
also
from
the
federal
documents
from
this,
and
maybe
just
addressed,
and
also
to
kind
of
support
of
what
Paul
was
saying.
K
Indeed,
it
will
be
really
valuable
to
have
two
different
documents,
one
for
the
key
exchange
processes
and
one
for
the
authentication
as
last
signature
process,
because
indeed
it's
a
little
bit
more
complicated.
The
terminology
or
those
two
terminologies
are
dependent
on
whatever
value
they
are
giving.
So
that
would
be
great
to
have
it
specifically
too.
If
you
want
a
little
bit
of
a
unified
terminology
for
the
hybrid
signatures.
What
this
recommends
is
to
use
dual,
but
we
can
take
that
indeed,
for
the
list
and
I
support.
K
This,
indeed,
is
far
more
from
the
research
area
of
the
iitm,
maybe
cfrg,
but
I
would
like
also
that
maybe
post
Quantum
A
specific
group
might
be
created
and
thank
you
very
much.
L
Daniel
Khan
Gilmore
ACLU,
so
thanks
for
bringing
this
work,
I
want
to
Second
pretty
much
what
other
people
seem
to
be
saying,
which
is
that
a
new
group
is
probably
the
best
bet.
Cfrg
is
really
getting
congested
right
now
and
I'm
I
mean
I.
Guess
the
cfrg
chairs
could
speak
to
this,
but
I
wouldn't
want
to
load
more
on
them,
especially
something
that
might
be
contentious
about
terminology
and
I.
L
I
want
to
Second
the
idea
that
you
need
different
drafts
for
signatures
and
encryption,
not
just
because
of
the
technological
difference,
but
because
the
actual
use
cases
are
quite
different,
so
separating
them
up
means
that
if
one
of
them
turns
out
to
be
easier
to
solve
than
the
other
you're
not
blocking
thanks.
D
And
tkg,
while
you're
there
so
folks
think
a
new
working
group
would
be
handy,
I,
I.
Think
one
of
the
questions
here
is,
as
the
speaker
raises,
whether
there's
other
post
Quantum
migration
issues
that
would
go
in
this
working
group
or
whether
you
think
a
terminology
draft
would
be
a
sufficient
Charter
to
get
a
new
working
group
spun
up.
L
M
Baker
yeah
I
think
another
group
is
probably
best
simply
because
the
way
that
I
would
expect
that
a
lot
of
this
work
is
going
to
go
is
people
who
are
building
stuff
are
going
to
come
along
and
say
what
do
I
call
it?
You
know
what
terminology
do
I
use
and
yes,
cfrg
does
algorithm
stuff,
but
algorithms
and
pro
and
cryptographic
Protocols
are
not
the
same
thing
as
wire
protocols.
M
B
E
So
let
me
do
take
my
ad
prerogative
before
I
talk
about
ad
kind
of
wrap
up,
so
the
first
I
like
the
there's,
a
lot
of
energy,
around
kind
of
post,
Quantum,
I,
personally,
Edie
hat
off,
would
love
for
us
to
be
able
to
talk
about
it
in
a
consistent
way.
So
the
appeal
of
having
a
terminology,
graphic
kind
of
is
exciting.
E
For
me
all
right,
break,
Ed,
ad
hat
on
I
think
we
need
to
talk
we'll
talk
with
cfrg
and
I
think
we
need
to
have
a
community
conversation
about
what
would
be
the
energy
around
this
other
post,
Quantum
working
group
we've
had
a
few
kind
of
proposals.
The
Gap
has
been.
We
want
more
work
in
it.
The
new
piece
that
I'm
hearing
here
is
maybe
just
talking
about
like
terminology,
is
a
sufficient
start
to
that.
E
D
Roman,
if
I
could
just
an
additional
level
of
detail
there,
it
sounds
like
what
we've
gotten
out
of
discussion
here
is
that
the
The
Landing
place
yeah.
We're
gonna
have
a
discussion
about
where
this
should
land,
but
it
seems
like
the
landing
place,
is
either
somewhere
close
to
cfrg
and
cfrg
or
in
a
in
a
new
dedicated
group
here.
Does
that
sound
like
what
you're
hearing.
E
Yeah
I
think
that's
exactly
right
and
I
think
there's
some
feedback
to
unpack
around
splitting
this
focusing
this
and
the
rest
of
it,
but
I
I
would
what
I
hear
is,
since
it
was
spread
all
over
the
place
about
how
you
should
do
that
and
you've
got
conflicting
advice
wherever
it
lands
would
be
the
place
to
adjudicate
that
thanks.
N
Stefan,
yes,
hello,
I'm
on
the
remote
second,
billions
really
yeah,
so
hello,
everyone,
I'm,
Stephanie
and
I.
Am
president
in
the
draft
celebrated
till
that's
authentication
next
slide,
please
yeah.
So
that
is
and
tell
us
this
notification
based
on
mutual
feelings.
It
provides
a
seclusion
which
cannot
be
broken
between
client
and
server
to
not.
N
Rely
on
on
web
pki,
we
locked
the
PS
authentication
keys
by
pinning
information
about
the
entities
in
the
Federation
are
published
in
the
Federation
metadata
document.
This
is
assigned
Json,
which
claims
describing
the
entities
and
points
to
enable
self-signed
certificate.
It's
possible
to
publish
trust
Anchorage
issues
for
this
in
the
metadata.
N
N
Background
for
this
is
I
work
for
the
switch
in
the
foundation.
That
is
an
independent
Foundation
that
works
for
the
positive
development
of
the
internet.
We
are
responsible
for
the
CC
top
level
domain.sn.nu
the
profit
from
from
selling
domains
finances,
among
other
things,
running
federations
for
the
school
sector
and
health
sector
in
Sweden
in
the
Federation
for
the
school
sector,
there
was
a
great
need
to
be
able
to
translate
the
secure
using
Open
Standards.
That
was
where
the
idea
of
fed
TLS
was
born.
D
N
Stakeholder
is
the
Swedish
national
Agency
for
Education,
which
will
use
fed
Telus
for
user
life
cycle
management
for
the
digital
National
tests.
Today
there
is
a
steady
increase,
if
remember
both
schools
and
service
providers.
They
understand
our
delivering
identity
and
access.
Management
Solutions
for
federations
has
also
started
to
implement
the
TLs
I
think
we
would
probably
see
a
more
rapid
acceptance
if
the
specification
was
stable
today.
As
far
as
I
know,
there
are
three
open
source
implementations
and
the
first
one
is
a
client
and
the
other
two
are
servers
next
slide.
Please.
N
So
how
does
all
this
works
and
a
client
and
server
exchanges
submitted
data
with
the
Federation
and
decline
pins
the
service
public
key
pins?
Then
the
client
establishes
a
connection
with
the
server
using
the
base.
N
If
it's
valid,
the
connection
is
accepted
otherwise
terminated,
for
example,
the
local
military
that
can
be
stored
in
a
redis,
the
proxy
cambian
and
genetics,
Apache,
F5
or
h,
a
proxy
server
and
the
client
can
be
Linker.
Libker
can
do
pinning
out
of
the
box.
So
next
slide.
Please.
N
N
So
more
questions
and
then
dispatching
this.
I
So
Eric
for
school,
yeah
I'm
just
trying
to
like
I'm,
not
hearing
like
a
lot
of
room
interest
in
this,
and
it
doesn't
sound
to
me
like
there's
a
lot
of
like
other
people
doing
this.
So
as
I
understand
this
is
like
for
the
receptive
of
TLS.
This
is
a
code
Point
registration,
so
I
guess,
like
you,
can
do
a
co-point
registration
with
no
RFC
at
all.
I
So
I
guess,
like
you
know,
I
guess:
I
turned
this
back
on.
You
is
like
why
don't
you
publish
take
the
ID
and
do
a
couple
magician
and
we'll
all
be
happy?
Will
that
satisfy
you.
P
I
assume
yeah,
yeah,
I,
guess
I
kind
of
give
you
a
record.
Also
I,
don't
I
admit
not
having
not
having
read
the
draft
I
guess
but
I
don't
have
enough
information
to
recommend
a
dispatch
outcome
based
on
today.
Q
Hi
just
a
quick
question
on
it
or
do
the
devices
in
the
machine
to
machine
sides
of
this
need
to
parse
this
metadata.
N
Q
N
R
N
S
N
B
Okay,
so
I
think
I
think
that
wraps
up
the
queue
it
sounds
to
me
that
more
work
is
needed
and
it
might
be
possible
to
accomplish
this
without
A
dispatch
option
so
Stefan.
If
you
want
to
do
an
update
or
work
on
the
list
and
do
the
ads
have
any
comments.
B
T
B
Good,
so
don
Eastlake
is
our
last
presenter.
U
U
So
it's
very
simple:
it's
widely
used,
it's
a
non-cryptographic
hash
function,
so
it's
commonly
used
for
things
like
calculating
something
which
you
use
to
get
an
index
into
a
hash
table,
or
something
like
that
provides
good
dispersion,
even
with
short
inputs
that
have
only
a
few
bits
of
difference.
Stuff
like
that,
and
the
purpose
of
the
document
is
to
provide
a
stable,
permanent,
fnv
reference
document.
U
U
U
Well,
you
can
use
other
values
and
then
you
take
the
data
and
you
would
go
through
successfully
taking
each
octet
of
data
xored
into
the
bottom
of
the
hash
and
multiply
by
the
magic
fnv
Prime,
that's
appropriate
for
the
length
of
the
hash
that's
currently
defined
for
for
the
32
to
a
1024
bits
not
really
defined
for
shorter,
because
that's
not
very
high
quality
and
not
defined
for
larger,
because
it's
unclear
if
that
would
really
be
useful
and
the
Criterion
for
picking
the
prime
gets
more
complicated
and
this
and
that
next
slide.
Please.
U
So
this
is
how
the
prime
is
selected.
I
don't
actually
understand
why
this
is
good,
a
good
way
to
pick
the
prime
because
I'm,
not
the
person
who
invented
this
and
haven't
done
the
the
analysis
that
the
the
authors
have
done.
It
is
the
case,
as
mentioned
at
the
bottom
here,
that
the
result
is
the
fnv
prime
will
have
only
six
or
seven
one
bits
in
it.
So
for
certain
types
of
implementations
it
may
be
more
efficient
to
do
some
form
of
Shifting
and
adding
rather
than
the
general
multi-precision
multiplication.
U
Next
slide
is
a
couple
of
examples,
so
the
fnv
Prime
in
HEX
for
32
and
64-bit
cases.
In
all
cases,
the
FMV
Prime
has
four
or
five
bits
being
one
in
the
bottom
eight
and
has
the
ninth
bit
on
and
has
one
other
bit
on
higher
up
in
the
prime.
U
If
you
want
some
other
power
of
two
bit
or
other
length,
you
can
just
do.
Xor
folding,
where
you
xor,
some
of
the
top
of
the
next
larger
fnv
result
into
the
bottom
bits
to
get
a
different
length
and,
of
course,
for
most
hash
table
uses.
You
just
have
a
probably
a
prime
length
hash
table
and
you
divide
by
that
and
use
the
remainder
and
that
sort
of
usual
stuff
next
slide,
please.
U
So
it's
used
lots
of
places.
For
example,
it's
currently
used
in
IEEE
standard,
802.1,
qbp,
2014,
and
probably
because
of
the
lack
of
a
permanent
reference
document
there
that
says,
use
fnv
and
then
gives
the
explicit
instructions
how
to
do
it
in
the
actual
computational
instructions
there
have
been
have
been
two
standards
track:
rfcs
that
used
fnv.
One
of
them
has
since
been
obsoleted,
there's
a
sort
of
dense
line
there
listing
a
zillion
cases
which
are
all
kinds
of
things
where
basically,
it's
used
to
calculate
indexes
into
hash
tables.
U
There
is
no
further
there's
two
URLs
one
is
to
a
paper
I
believe
Brian.
Carpenter
is
one
of
the
co-authors,
which
suggests
using
it
to
calculate
IPv6,
FL
flow
identifiers,
and
it's
currently
suggested
in
a
document
in
the
BFD
working
group,
so
there's
actually
a
great
website
for
it.
It's
listed
at
the
bottom
there.
The
website
has
some
code,
including
even
x86,
assembler
code
for
it
and
things,
but
there's
no.
You
know
published
document
as
such
next
slide,
so
I
would
suggest
I
think
the
document
is
in
reasonable
shape.
U
That
ad
sponsor
would
be
a
reasonable
way
to
go,
and
one
other
piece
of
information
is
that
Paul
Hoffman,
who
is
in
the
room
would
be
available
to
be
document.
Shepard.
B
Thank
you
to
shorten
this
Roman
or
Paul.
Do
you
wanna
I
mean.
V
Paul
speaking
so
I
don't
mind,
80
sponsoring
it.
If
we
don't
find
another
home,
if
like
I,
would
prefer
if
it
would
see
more
View
and
and
find
a
home,
but
if
not
then
I'm
willing
to
sponsor
it.
I
So
I
actually
sent
a
list,
but
I
think
we
didn't
close
in
it.
So
I
understand
it.
There's
no
changes
proposed
to
this
document
to
this
specific
sorry
algorithm
anyway,
namely
we're
simply
taking
a
fixed
algorithm.
We
are
writing
it
down.
Correct,
yes,
okay,
so
like
that
seems
like
a
very
like
a
little
different
from
our
usual
thing.
Where,
like
this
is
not
actually
yeah,
the
ITF
is
not
like
endorsing
this,
and
it's
not
like
reviewing
it
and
we're
not
changing
it.
I
I
Didn't
you
say
that
one
didn't
you
say
it
was
a
document
already
that
already
had
this
written
down
in
it,
which
document
I
thought.
You
said
one
of.
U
The
one
of
the
the
IEEE
standard
has
the
computational
instructions
for
one
specific
length,
I
believe
the
32-bit,
the
smallest
size
of
FMV
function.
But
you
know
it's
in
the
middle
of
this
gnarly.
U
I
H
The
answer
that
so
Paul
Hoffman,
the
fact
that
this
is
already
used
in
a
standards
track
document
would
make
it
inappropriate
for
the
ISC
that
is,
the
ISE
is
saying:
here's
an
algorithm
that
is
already
in
use
in
a
standards
track
document.
It
seems
just
as
easy
to
get
80
sponsored
and
such
and
it's
actually
widely
used.
This
is
DNS
cookies.
H
It's
widely
used
the
implementers
were
able
to
figure
out
by
reading
Don's
draft.
It
should
just
be
something
that's
an
RFC.
So
really
the
question
is:
how
do
we
instantiate
this
as
an
RFC.
U
I
would
say
that
the
consensus
was
that
this
document
correctly
documents
and
describes
the
function,
including
in
the
security
considerations,
exactly
why
it
would
probably
not
be
considered
cryptographic.
The
security
considerations
explains
why
that's
the
case.
Yeah.
M
I
I
was
about
to
say
security
considerations
is
this
is
going
to
need
serious?
Oh
sorry,
philhan,
Baker,
yeah,
yeah,
serious
security,
consideration
saying
when
to
use
it
and
when
not
to
use
it,
and
there
are
some
good
applications
within
security
protocols,
for
example,
if
you're
going
to
use
a
bloom
filter
a
while
back,
we
showed
using
myself
and
Rob
stradling
commode
I
should
using
Bloom
filters
as
a
way
of
speeding
up
for
crls.
M
You
don't
want
to
use
a
cryptographic
cache
for
that,
it's
too
slow
and
if
you're
going
to
be
throwing
it
into
a
bloom
filter,
collisions
don't
matter
anyway,
and
so
it's
very
important.
The
other
thing
is
I,
do
have
an
IPR
thing.
I
should
probably
mention
back
in
the
day
that
there
was
a
guy
who
was
who
was
claiming
to
own
the
use
of
a
cryptographic
cache
for
nothing
cryptographic
purposes.
U
Should
mention
that
the
authors
have
tried
as
hard
as
they
can
to
make
sure
there
is
no
IPR
or
patent
restrictions
on
this.
They
invented
it
and
published
it
and
and
didn't
apply
anywhere,
and
nobody
else
has
ever
said
anything
about
the
any
of
these
uses,
so
I'm
pretty
sure.
There's
no
rpr
problems.
Okay,.
B
So
I'm
next
in
queue,
no
hat
and
then
I
have
Ted
Hardy
after
that.
So
you
might
want
to
add
yourself
to
the
queue
so
I
see
no
reason
to
not
publish
this
through
the
ad
stream.
This
is
a
typical
kind
of
document
that
gets
published
there
and
then
can
go
in
as
a
down
rough
as
needed
for
references
for
other
documents.
W
Thanks
I
just
wanted
to
ask
a
clarifying
question
which
I
believe
Paul
might
know.
The
answer
to
I
I
took
from
what
he
was
saying
that
the
ISC
had
rejected
this
document
on
the
basis
of
the
fact
that
there
were
standards
track
documents
which
were
referred
to
it,
which
seemed
quite
odd
to
me,
and
I
I
wanted
to
confirm
my
understanding.
No.
H
W
H
W
X
Yeah
thanks,
so
we
already
have
a
non-cryptographic
hash
function,
it's
md5
and
there's
already
an
RFC
for
it
and
there's
there's
some
optimized
assembly
for
there's,
probably
even
hardware,
for
it
that
exists
in
the
wild.
So
is
there?
Is
there
a
reason,
as.
U
I
said
at
the
beginning,
one
thing
I'd
really
like
to
avoid
is
rat
holding
on
comparing
hash
functions
and
I
could
say
why
I
think
there
are
applications
for
which
this
is
better
than
the
hash
function.
You
just
mentioned,
which
I
won't
mention
the
name
of,
but
I
don't
want
to
mention
and
start
mentioning
names
of
hash
functions
and
getting
rat
hold.
V
So
I
guess
I'm
hearing
that
it's
probably
80
sponsorship
is
the
best
route,
since
nobody
else
would
want
to
pick
it
up.
So.
D
Well
I,
it
seems
to
me,
like
there
was
a
blend
of
comments
here
between
maybe
sponsorship
and
on
the
one
hand,
and
maybe
the
itself
taking
new
action
and
an
apology
is:
are
you
inclined
given
given
the
feedback?
It
may
not
make
sense
as
an
ETF
document.
Are
you
still
inclined
to
any
sponsors.
E
Yeah
yeah
I
think
process
wise.
What
the
Finesse
is
talking
with
Paul
is
we're
going
to
pick
it
up
as
ad
sponsorship
and
then
we're
going
to
continue
to
have
this
conversation
that
we're
having
if
we
can
find
kind
of
consensus
to
have
it
on
the
stream
and
we'll
hammer
out
there.
D
And
should
be
back
yeah
just
recap:
our
this
year
we
had
three
items
on
the
agenda
here
for
the
Post
Quantum
hybrid
terminology
work.
The
outcome
we
came
to
was
to
either
go
to
the
FRG
or
during
the
work
here
from
the
security
area.
The
80s
have
the
action
to
lead
that
discussion
to
the
conclusion,
and
please
are
going
to
do
an
agenda
bash
and
sag
on
our
next
session
on
the
Federated
TLS
work
I.
Think
there's
no
action
off
the
ITF
here.
D
As
Ecker
pointed
out,
the
authors
can
get
code
points
to
kill
us
without
having
an
rfcs
through
many
services
for
that
path.
First,
and
as
we
just
discussed
on
and
we
the
80s
are
planning
to
take
us
forward-
is
80
sponsored
and
we'll
get
that
focused
on
kind
of
what
what
areas
of
review
are
desired
from
the
ITF
community.
D
So
that's
what
I
have
in
my
notes,
I
think
that's
the
end
of
the
dispatch
session
is
that
right.
B
P
I'm
sorry,
Stephen
I
didn't
join
the
queue,
but
somebody
else
is
here:
I
hope
it's.
Okay,
just
I
I
think
this
sector
thing
is
not
working
as
well
as
hoped
in
some
respects.
P
Just
if
you
take
today
personally,
I
I'm,
not
sure
the
summary
is
reflected
how
I
heard
the
discussion,
maybe
I'm
wrong.
That's
fine
and
I
think
on
the
for
a
and
c
and
for
B
I
think
that
should
have
been
a
discussion
on
the
TFS
list
and
not
brought
to
a
dispatch
process
at
all,
because
I
think
we're
just
wasting
time.
By
doing
such
things,
so
I'd
ask
that
we
think
again
about
the
possibility
that
somebody
suggests
something
to
TLS,
for
example,
and
when
they
get
a
no
or
a
negative
or
no
response.
L
Daniel
Khan
Gilmore
I
also
failed
to
get
in
the
queue.
Apologies,
so
I
actually
I
feel
like
I,
didn't
use
SEC
dispatch
well
because
I
didn't
mention
to
SEC
dispatch
that
I
have
this
dangerous
labels
draft,
but
I
would
have
actually
been
useful
to
do
here.
So
part
of
the
fact
that
it's
not
useful
I
think,
maybe
is
people
aren't
bringing
stuff
here
and
I'm
guilty
of
that.
L
If
you
haven't
seen
my
dangerous
labels
draft,
it
basically
says
here's
a
list
of
DNS
labels
that
you
might
be
surprised
if
you
let
people
register
them
within
your
Zone,
because
they
have
other
consequences
and
here's
a
list
of
other
of
email
address
local
parts
that
you
also
might
be
upset
by
because
they
might
have
security
consequences
if
you
happen
to
have
registered
so
I
have
no
idea
where
that
lands.
L
The
the
some
examples
are
things
like
mta-sts.
If
you
let
somebody
register
that
within
your
domain,
you
have
some
surprising
security
properties,
the
email,
local
Parts,
the
classic,
SSL
admin.
L
Things
like
that,
so
I'm
trying
to
collect
like
this
document
as
basically
a
Wall
of
Shame
and
to
remind
people
that,
if
they
specify
something
that
does
something
like
this,
they
get
to
go
on
the
Wall
of
Shame.
It's
not
supposed
to
endorse
this
practice
and
it's
trying
to
divert
people
towards
things
like
dot,
well-known
and
underscore
prefix
DNS
labels
I
have
no
idea
where
this
would
live
in
the
ITF.
D
Dkg
that
that
seems
like
it
could
be
if
you
could
bring
that
up
on.
The
list
seems
like
it
could
be
a
good
use
case
for
seeing
if
we
can
do
some
dispatching
between
meetings.
G
B
A
E
Hello,
everyone
Thanks
for
thanks
for
your
patience
here
as
we
do
the
administrative
pivot.
We
are
splitting
the
SEC
dispatch
into
what
we
just
completed
was
the
dispatch
process
and
we're
just
going
to
run
into
the
security
advisor
area
Advisory
Group
kind
of
sag.
My
name
is
Roman
delu
I'm,
one
of
the
seconds
and
I'm
here
with
my
co-coad.
V
Hi
I'm
Paul
Vargas
I'm
fairly
new
to
this,
so
please
feel
free
to
reach
out
to
me
if
I
can
reach
out
to
you,
but
I'll
also
try
to
reach
out
to
the
people.
I
haven't
managed
to
reach
out
to.
E
Me
all
right.
Administratively,
we've
talked
about
the
note
well,
but
we're
rebroadcasting
here
everything
we
said
for
SEC
dispatch
directly
applies
here
and
always
reiterating
year
that
we
want
to
live
the
Dakota
conduct,
and
these
are
the
basic
tenants
and
principles
of
what
we
expect
for
all
iitf
participants,
just
kind
of
visual
meeting
tips
everything
we
did
before
for
SEC
dispatch.
Let's
continue
doing
that
for
for
this
meeting
agenda
wise
as
we
put
on
the
list,
we
were
hoping
to
have
a
little
bit
more.
E
Unfortunately,
some
of
the
the
more
media
items
kind
of
fell
through.
So
what
we
primarily
have
prepared
is
the
scanning
agenda.
The
other
thing
we're
going
to
bash
the
agenda
with
is
we
heard
some
interest
in
a
new
direction
that
we
hadn't
previously
heard
around
a
post,
Quantum
kind
of
working
group?
So
we're
going
to
talk
about
that
after
the
ad
report,
we're
going
to
pause
here
to
say:
would
anyone
like
to
bash
the
agenda.
V
So
so
one
thing
that
I
I
notice
is
that
our
pool
of
working
group
chairs
is
fairly
low
and
some
people
might
not
realize
that
we
are
looking
for
for
both
experience
and
inexperience
for
group
chairs,
just
to
sort
of
know
that
we
have
people
that
we
can
reach
out
to
once.
You
have,
like
you,
know,
a
chair
resigning
or
a
new
worker
group
forming.
So
please
don't
think
that
you
need
to
be
like
a
10
year
old
iitfer
before
you
can
be
considered
for
a
worker
group
chair.
V
So
if
there's
something
you
might
be
interested
in,
please
reach
out
to
us,
or
we
at
least
know
that
you
know
we
have
a
few
names
of
people
that
that
we
could
call
upon
once
an
opening
comes
up.
So
please
do
that.
Second,
even
better.
If
you're,
if
you're
a
newcomer-
and
you
really
want
to
learn
more
about
the
process
within
ITF
becoming
a
document.
V
Shepard
is
actually
a
really
great
way
of
learning
more
about
the
process
and
in
addition,
you
will
help
us,
because,
unfortunately,
because
of
the
shortage
of
shepherds,
we
have,
who
usually
or
too
often
have
chairs
doing
that
work
themselves
or
document
offers
doing
most
of
that
work
instead
of
having
you
know,
an
objective
external
person
doing
this
work.
V
So
if
you
want
to
read
up
on
what
a
Shepherd
is,
if
you
want
to
talk
to
one
of
us
about
about
what
it
involves,
please
yeah,
please
let
us
know
it's
a
it's
a
really
great
way
for,
for
you
to
to
get
to
know
the
ITF
a
little
bit
better
and
then
number
three.
V
N
V
Is
is
correct
or
not,
there's
a
lot
of
work
on
on
that
we
have
a
pretty
big
backlog
and
one
of
my
goals
as
a
new
Fresh
ad
with
too
much
energy,
is
that
I'm
going
to
try
and
push
the
working
groups
into
doing
a
little
bit
more
focused
Errata
handling,
so
you'll
see
on
the
slides
for
the
working
groups
that
are
following
that.
We
are
listing
the
amount
of
erratas
that
you
have
unresolved
in
the
hope
that
you
will
be
ashamed
to
solve
them.
D
Yeah
I'm
just
going
to
thank
the
ads
for
for
helping
develop
talents
in
our
area.
I
think
this
is
a
great
idea.
I
was
going
to
offer
a
friendly
Amendment
for
folks
who
might
be
experienced
chairs
if
you
happen
to
be
an
experienced
chair
and
your
co-chair
is
also
an
experienced
chair,
I
kind
of
think
you're
doing
it
wrong.
D
So,
if
you're
an
experienced
chair,
I
would
suggest
talking
to
the
ideas
about
getting
an
inexperienced
here
to
work
with
to
help
develop
this
talent
pool
and
build
a
build
up
more
leadership
in
our
space.
Thanks.
D
I
I
have
tried.
We
have
tried
to
bring
in
you
know,
folks,
in
this
role,
I
think,
let's
move
its
vacancies
like
dispatch.
We
have
an
opportunity,
so,
if
you're
a
newcomer
and
would
like
to
do
things
like
this
type
of
stuff
reach
out
to
ads
reach
out
to
the
the
SEC
dispatch,
cheers
we'd
love
to
talk
to
you.
E
All
right,
so
the
next
standing
item
we
have
here
are
working
group
summaries
and
due
to
Paul's
kind
of
hard
work,
we
have
a
slightly
more
informative
format,
given
that
we
are
very
very
early
in
the
week.
Historically,
we
do
this
much
later.
In
the
week,
many
of
the
working
groups
have
not
yet
met
as
we
bring
kind
of
things
together
if
any
of
the
chairs
or
working
group
participants
want
to
come
up
and
talk
into
the
mic,
we'll
move
at
a
slightly
slower
Cadence.
O
I
you
have
near
Couture
effectney,
so
yeah
we've
got
a
couple
of
documents.
Just
finishing
working
group
last
call
a
whole
bunch
in
various
isg
processing
State
and
a
couple
considering
adoption
perfect
thanks.
E
E
E
My
two
NSF,
these
are
readable,
slides
we'll
go
quickly
that
if
folks,
you
want
to
make
some
comments
here,.
C
E
Y
Right
Sean,
Turner
I'm,
going
to
shamelessly
plug
MLS.
Both
the
protocol
draft
and
the
architecture
draft
have
been
through
working
group
last
call.
The
protocol
draft
actually
went
through
multiple
working
group
last
calls
but
they're
good
to
go.
If
you
remember,
when
we
started
this,
it
was
a
little
bit
like
the
TLs
development.
Y
We
wanted
to
make
sure
that
we
had
some
buying
from
the
security
community
and
in
during
the
working
group
last
call
like
we
got
Karthik
and
others
and
like
Brita
Hale,
to
like
put
their
thumbs
up
on
the
draft,
so
that'll
be
coming
your
way
Paul
shortly.
Basically,
I
just
need
the
architecture
draft
to
get
reposted.
Y
Z
Hello
Siobhan
said
co-chair
of
Ojai
just
wanted
to
say
that
I
think
we're
almost
ready
to
go
with
the
main
protocol
draft
We'll
be
asking
for
last
call
soon
and
there's.
AA
Yeah
I'll
give
a
plug
for
privacy
preserving
measurement.
We
have
a
small
Core
group
of
people
working
on
the
one
adopted
draft
I
would
love
to
have
more
eyes
on
it
and
a
wider
group
of
people
looking
at
it.
We
also
have
one
new
proposal
and
I
won't
say
new,
because
it
was
presented
at
Vienna
that
might
become
up
for
adoption.
E
E
We
have
skit
coming
up
this
Thursday
and
we
have
Sac
P
that's
later
later
this
afternoon,
so
skid
is
focused
on
what
can
the
ITF
do
around
certain
elements
of
the
supply
chain
and
sap
is
focused
on
distributed
ledgers
and
how
we
can
Bridge
some
of
those,
so
we're
going
to
need
some
sharp
eyes
to
help
us
figure
out
what's
right
on
the
scope
there?
What
we
want
to
do
here
and
we
of
course
need
to
answer-
do
we
have
the
energy
to
work
on
those?
E
So
we
do
request
that
the
community
kind
of
come
and
kind
of
help
us
figure
out
what
the
way
ahead
is
on
two
bodies
of
work
and
there's
this
kind
of
standing
practice.
We
have
a
lot
of
other
security
areas,
things
that
are
related
to
security
happening
both
in
the
ITF
and
the
re,
the
irtf
plus
in
other
places
in
the
community.
If
someone
wants
to
come
to
the
to
the
mic,
this
is
the
The
Collection.
That
I
believe
we
are
roughly
tracking,
but
we
welcome
commentary
not
only
just
on
these,
but
on
others.
J
Yeah
this
is
Barry
Lee,
but
chair
of
dmarc
we're
meeting
on
Thursday
and
the
primary
bit
of
discussion
will
be
the
issue
we
have
now
with
identifying
the
correct
organizational
domain
in
some
cases
where
we
are
looking
at
replacing
the
use
of
the
public
suffix
list
with
instead
a
tree
walk
and
an
additional
dmarc
tag,
and
that's
been
quite
a
lot
of
controversy
on
the
list.
So
that's
that's
the
main
discussion
this
time.
T
I,
don't
see
tigers
up
there,
but
or
maybe
I
do
anyway.
Tigress
is
a
credential
transfer
protocol
and
has
definitely
it's
in
the
art,
but
it
has
obvious
security
implications,
so
it
would
be
great
to
get
a
little
bit
more
people
from
the
security
area
and
that
working
group
to
help
review
and
look
at
document
stuff
like
that
contribute.
E
Thanks
for
mentioning
Tigers,
so
for
those
that
have
been
following
along,
we
had
the
secret
life
before
ietf
13..
There
was
obviously
Community
feedback
that
that
name
was
not
super,
so
that
work
turned
into
tigers,
that
that
was
just
mentioned,
and
there
was
some
back
and
forth
during
that,
which
is
this
a
sex
thing.
Is
this
an
art
thing
it's
somewhere
in
between,
so
the
way
that
got
negotiated
out
is
it
will
remain
in
art,
but
it's
going
to
have
a
sec
ad.
So.
T
T
So
so
coming
up
and
be
nice
to
the
contributors
they're,
they
are
very,
very
new
to
the
iitf
community
and
kind
of
well
need
help,
and
we
should
be
nice,
then.
So.
Thank
you
by
the
way,
I
have
a
co-chair
in
that
prachi
Lane
you'll
be
seeing
a
lot
more
of
her
she's
very
new,
but
she's
probably
going
to
be
the
one,
the
one
most
visible
on
that.
Thank
you.
W
AB
AC
In
the
drip
warp
group,
the
drip
off
draft
is
in
work
group
last
call
and
we
do
need
reviewers
of
it.
It's
been
just
really
only
internally
reviewed
and
our
chairs
have
caught.
Can
we
have
please
have
reviewers
of
the
draft,
so
we
complete
the
last
call
within
the
work
group.
So
the
auth
graph
is
all
about
authentication
of
these
messages
in
an
extremely
constrained
environment
of
basically
payload
of
200.
AC
Bytes
got
to
do
it
in
that,
so
we
do
welcome
and
request
that
the
largest
community
look
at
what
we're
doing
there
in
that
draft.
If
you
need
you,
unfortunately,
there
is
a
lot
of
background.
You
need
to
know
why
we're
doing
the
way
we
are
but
we're
available.
The
authors
are
available
for
for
giving
that
context,
so
invite
reviewers
of
the
drip
off
draft.
Thank
you.
AD
Yes,
I
was
having
problems
getting
up
getting
booked
it,
but
my
name
in
the
queue.
So,
if
so
I,
if
it's
okay,
I.
AD
Is
Sam
is
Dave
Taylor
in
the
rats
working
group
this
week
there
was
a
presentation
from
Carl
about
a
format
for
configuring
trust
anchors
in
a
trust,
anchor
store
right,
not
a
protocol,
but
a
way
to
encapsulate
a
set
of
trust
anchors
to
configure
on
a
particular
machine
that
can
be
carried
in
other
protocols.
AD
Rats
would
make
use
of
this,
but
it
was
pointed
out
to
the
meeting
by
me
and
others
that
other
working
groups,
including
suit
which
I
coach
here
and
teep,
where
I
author
documents
both
need
the
same
thing,
and
so
the
question
was:
maybe
it
shouldn't
go
into
the
rats
working
group
because
it's
more
of
a
general
mechanism,
not
sure
where
it
should
go,
but
I
told
them
that
maybe
this
is
the
sort
of
thing
that
should
come
to
SEC
dispatch
or
something
in
the
future.
AD
E
In
the
jabber
that
there's
some
interest
in,
if
someone
can
talk
about
Mimi-
oh
no
I'm,
not
saying
I'm
going
to
talk
about
it,
Stephen.
If
you
were
going
to
talk
about-
maybe
oh
you're
asking
so
if
someone
can
tell
us
a
little
bit
more
about
Mimi
I
was
conflicted
and
was
unable
to
attend.
Please
feel
free
to
come
up
to
them
like
now
or
comment
on.
E
Okay,
I
think
I
think
that's
it
for
the
for
the
wrap
up
for
in-flight
activities,
so
we're
gonna
roll
straight
into
Paul
and
I
are
going
to
tag
team
a
little
bit
on
the
on
our
ad
report.
E
So
just
to
give
everyone
a
bit
of
a
heads
up,
we
are
holding
a
couple
of
documents
that
are
in
flight
for
ad
sponsorship,
phenomenal
news.
Since
the
last
time
we
talked,
we
have
two
new
rfcs
on
security.txt
and
on
the
XML
SEC
identifiers,
and
you
can
see
it's
kind
of
behind
us
where
we
are
a
little
a
little
earlier
in
the
life
cycle
on
the
two
other
Ed
sponsored
minutes.
E
These
are
a
few
standing
pointers,
but
these
are
repeated
questions
that
that
Paul
and
I
get
which
are
what
is
what
are
you
working
on?
What's
in
the
queue
kind
of
what's
hot?
Why
have
you
not
looked
at
my
document,
so
anyone
that
wants
to
kind
of
understand
where
we
are
in
status
and
where
your
document
might
be
in
our
review
queue.
E
Please
do
dereference
those
that
middle
block
of
URLs
behind
us
another
piece
another
another
pointer
we
wanted
to
actively
share
is
that
Paul
and
I
and
previously
been
discussed
on
a
lot
of
common
issue
common
issues,
so
we
would
see
them
recurring
in
a
recurring
fashion
during
our
Ed
review.
We
want
to
highlight
what
those
are
and
we
we
took
the
time
to
document
it
on
that
first
URL.
So,
if
you
are
you,
as
you
are
going
into
working
from
class
Paul
in
your
document,
that's
a
great
place
to
kind
of
check
you
know.
E
Did
we
think
about
these
particular
issues
before
things
would
exit
exit
the
working
group
and
in
other
pointers
just
to
bring
you
know,
make
sure
we
have
cross
visibility
on
where
we
stand
with
things?
We've
had
some
movement
on
working
groups.
You
know
starting
early
in
the
life
cycle.
This
is
the
most
boss
we've
had
in
recent
every
in
the
SEC
area.
Again,
please
do
join
skit
and
sat
P
later
in
the
week
and
we're
going
to
continue
the
jwp
conversation
on
the
Jose
list.
E
We
chartered,
as
we've
told
us,
Tigris
and
last
week.
We
closed
second
problems
and
we
really
do
have
an
older
set
of
slides
here.
So
so
we've
had
some
some
motion
on
working
group
changes,
so
I
think
I
saw
Mohit
come
in
in
the
end.
If
my
eyes
are
kind
of
correct,
maybe
not
is
he
in
the
back
of
the
room?
E
Maybe
he's
not.
So
we
want
to
kind
of
thank
him.
He
is
exiting
his
leadership
role
in
Ebu
and
SEC
dispatch.
So
huge
kind
of
thank
you.
We
have
Peter
coming
in
to
help
to
help
with
emu.
So,
thank
you
for
doing
kind
of
that.
Prachi
and
leaf
are
spearheading
tigress
and
in
the
data
tracker
we
have
a
new
version
of
those
slides
and
big
thanks
to
Robbie
Harwood,
who
was
long
time
co-chair
of
kind
of
kitten
and
Ben
who
is
remotely
connected.
E
Vincated
is
gonna
jump
in
to
to
be
the
the
other
co-chair
of
of
Kit.
As
Paul
said
from
the
kind
of
the
beginning,
we
are
always
looking
for
those
that
might
be
interested
in
ship
roles
and
working
groups,
or
certainly
being,
if
that's
a
little
too
much
being
documented
Shepherds.
If
you
are
interested
in
being
working
group
chair
experience,
not
experience.
Signaling
that
to
us
is,
you
know,
is
always
of
Interest.
E
I
I,
don't
think
I
need
to
plug
it
here,
but
one
of
the
things
that
we
have
realized
that
some
of
our
non-working
group
mailing
lists
don't
get
visibility
after
the
second.
We
create
them.
So
we
want
to
make
sure
we
highlight
them
here:
the
pqc
mailing
list,
that
is
a
non-working
mailing
list
to
discuss
whatever
the
community
would
like
around
post,
Quantum
post,
Quantum
Computing.
We
have
created
that
pleased
to
use
that
mailing
list.
If
there
is
not
one
appropriate
to
the
working
group,
would
you
like
to
handle
lorata.
V
I
talked
already
a
little
bit
about
the
aradas.
It
is
really
important
that
we
get
them,
get
them
reduced.
There's
some
working
groups
that
that
have
a
lot
of
them
and
additionally,
a
somewhat
harder
one
that
falls
down
between
the
cracks.
V
Even
more
is
the
ones
for
on
documents
that
have
no
longer
any
open
working
group
and
nobody
is
looking
at
those
erratas,
and
so
so
so
I
didn't
even
actually
count
them
I'm,
not
even
sure,
if
they're
counted
in
in
the
numbers
that
are
on
the
current
slide,
because
we
kind
of
look
at
the
working
group.
So
if
anyone
wants
to
to
volunteer
to
spearhead
any
of
these
efforts,
then
please
let
us
know.
Otherwise
we
will
continue
bugging
people
about
solving
around
us.
E
Yeah
I
mean
I
think
the
bottom
line
to
point
out
is
we
started
highlighting
this
last
time
and
we
are
in
fact
losing
ground.
So
while
we
we
closed
some
Parada,
we
got
a
whole
bunch
more,
and
so
we
have
a
little
more
than
we
had
last
time.
We
would
really
ask
that
those
working
groups
highlighted
kind
of
at
the
bottom
there.
Those
are
I
think
the
the
vast
majority
of
where
we
have
inrata
in
open
work
groups.
E
If
you
could
please
kind
of
take
that
up
and
we
will
work
on
on
handling
and
trying
to
Federate
support
and
review
of
the
ones
that
do
not
have
accurate.
S
Yeah
that
brings
up
rich
Saul
sock.
My
that
brings
up
a
probably
is
the
answer
to
the
lamps
one,
because
from
what
I've
seen
Russ
is
really
diligent
about
that.
So
these
old
P
kicks
5280
yeah.
E
That's
right
so
thank
you
kind
of
for
finessing
that
when
we
made
that
work
group
list,
that's
not
directly
bound
to
the
necessarily
the
working
group,
it's
a
little
bit
about
the
technology
associated
with
it.
So
some
of
the
ones
for
lamps
are
indeed
a
lot
of
old
Peaks.
Thanks
absolutely.
H
Paul
Hoffman
wearing
a
very
different
hat,
I've,
actually
been
reviewing
a
lot
of
Errata
and
updates
for
not
for
security
stuff.
One
thing
I've
found
is
that
in
fact,
as
I
tell
people
I'm
working,
you
know
like
going
through
Errata
I
hear
from
many
software
developers
of
oh,
my
God
I
wish
I
had
known
that
this
Errata
had
been
reported,
but
not
included
in
this
RFC.
That
I
implemented
implemented
wrong
and
was
laughed
at
by
other
developers
who
knew
that
the
Errata
had
been
reported.
H
So
it's
not
just
I
mean
I,
think
people
think
Errata
is
often
grammatical,
which
some
of
them
are,
but
there
are
some
significant
things,
including
wrong
check
sums
in
in
Sample
code
and
such
like
that
that
really
have
an
effect
on
on
implementers.
So
the
fact
that
some
of
the
working
groups
are
so
far
behind
actually
impedes
the
implementation
of
their
standards.
H
J
The
sparity,
but
following
up
on
that,
the
I
believe
the
RFC
editor
has
agreed
to
try
to
handle
it.
Any
new
era
that
come
in
that
are
purely
editorial
and
the
RFC
editor
is
supposed
to
handle
those.
So
we're
really
looking
at
the
new
era
and
well
and
existing
Errata
that
are
technical
in
nature
and-
and
there
are
far
too
many.
E
Okay,
so
again,
General
call
here
the
other
thing
we
we
want
to
make
sure
that
we
say
a
huge
kind
of.
Thank
you
for
is
one
of
the
things
that
Paul
and
I
have
to
do
is
bring
forward
the
various
documents
to
the
to
the
isg
for
advancement
or
to
do
community
to
review
the
things
coming
from
the
rest
of
the
community
and
that
workflow
is
directly
enabled
by
the
people
that
you
see
broadcasted
there.
Thank
you.
Thank
you.
E
So
much
to
the
security
kind
of
director,
your
reviews
are
directly
impacting
quality
of
the
things
we
publish
they're,
directly,
making
sure
that
we
don't
publish
things
here
in
the
ietf
that
have
security
security
implications
and
that
will
break
things
on
the
internet
and
they
are
a
tremendous
help
personally
to
both
Paul
and
I,
as
we
continue
to
do
those
reviews.
So
thank
you
to
the
team
kind
of
back
there,
and
also
thank
you
for
Teru
for
facilitating
the
assignment
of
those
reviews.
It
really
makes
the
magic
happen.
E
Okay,
so
we
have
plenty
of
Open
Mic
time,
but
before
we
were
going
to
run
into
the
open
mic
time,
we
wanted
to
Pivot
back
in
the
agenda
bash
that
we
promised,
during
kind
of
SEC
dispatch,
to
revisit
this
idea
of
what
is
the
threshold
for
which
we'd
want
to
set
for
a
post
for
Quantum
working
group,
whatever
that
might
be
to
level
set
here,
because
I'm
doing
this
entirely
kind
of
on
the
Fly.
E
Since
we
brought
this
up
at
SEC
dispatch
I
believe
we
had
a
conversation
at
ITF
111,
where
the
notion
was
floated,
listen,
post,
Quantum
things
are
coming.
We
have
working
groups
that
that
are
open
and
if
they
are
open,
they
will
be
best
positioned
to
to
me
kind
of
the
challenges
of
post
Quantum
agility.
That's
going
to
come!
What
we
didn't
have
our
head
wrapped
around
is:
there
will
likely
be
all
sorts
of
protocols.
We
want
to
think
about
that.
E
Perhaps
don't
have
active
work
groups
and
there's
no
ready
way
to
do
maintenance,
and
so
the
proposal
at
the
time
at
111
was
hey.
Why
don't
we
spin
up
a
post,
Quantum
agility,
working
group?
That
would
be
the
home
to
house
these
for
lack
of
a
better
term
orphan
kind
of
specifications,
so
we
could
treat
them
as
a
one-off.
We
got
all
sorts
of
kind
of
feedback.
The
feedback
roughly
was
hey.
Are
you
confident
that
you
would
have
the
expertise
in
this
working
group
to
pick
up
one
of
those
orphaned?
E
One
of
those
orphan
working
group
and
kind
of
the
pros
and
cons
are
maybe
maybe
not
the
it's
a
bit
of
a.
It
was
a
bit
of
a
scalability
argument
that
if
we
can
do
it
in
one
place,
it
might
reduce
pressure
friction
for
the
agility.
The
other
piece
of
feedback
was
well
okay.
In
theory.
We
understand
the
the
thinking
on
this
working
group,
but
what
would
be
the
first
bodies
of
work
that
you'd
want
to
run
through
this
process,
and
that
was
a
place
where
we
did
not.
E
We
got
a
little
bit
of
feedback,
but
not
a
lot
of
feedback
of
what
protocols
were
dropping
there
and
then
the
last
set
of
feedback
was.
Can
we
in
fact
move
forward
without
algorithm
recommendations
on
what
we
would
drop
for
to
do?
Post
Squad
and
pedophageality,
and
the
push
was
primarily
can
we
do
this
without
miss
making
some
decisions
out
of
kind
of
round
three
so
coming
out
of
111,
we
roughly
left
that
that
notion
of
a
working
group.
We
have
a
template
for
it.
We
can
continue
having
it.
E
The
interesting
development
I
heard
today
kind
of
talking
was
that
there
is
quite
a
lot
of
interest
and
momentum
to
continue
this
conversation,
and
perhaps
it
might
be
sufficient
that
the
threshold
for
having
such
a
forum
is
actually
just
being
having
a
place
to
talk
about
it
and
get
our
heads
around
what
that
terminology
terminology
might
be
and
I'm
going
to
start
I'm
going
to
kind
of
stop
talking
and
say
kind
of
discuss.
Do
we
think
that
that's
a
sufficient
kind
of
threshold?
What
are
there
things?
I
I
mean
this
was
sort
of
the
concept
behind
curdle
when
we
did
it
before
right,
I
mean
I,
guess
I
think
this
may
be
a
little
premature.
I
We
literally
just
got
the
recommendations
like
what
two
weeks
ago,
so
maybe
we
should
like
try
to
do
some
of
the
protocols
that
we
actually
know
and
like
are
being
heavily
maintained
and
get
some
of
those
beaten
down
a
little
bit
and
then
and
then
and
then
try
to
take
those
learnings
and
and
try
to
do
the
ones
that
are
maintained.
I
mean
by
definition
the
ones
that
are
maintained
are
like
the
ones
that
are
sort
of
like
less
less
actively
developed.
So
I
think
you
know
anything.
I
I
You
know
x59
and
and
one
of
the
you
know,
and
then
you
want
to
messaging
formats
and
then
we'll
see
that
then
we'll
have
a
template
between
the
rest
of
them,
but
I
think
try
and
do
them
all
at
once.
It's
probably
not
gonna
work
out
super
well.
E
Great,
thank
you
and
then
in
terms
of
scope
again,
I
think
we
have
two
things
to
talk
about
is
both
the
the
maintenance
piece
and
if
those
folks
think
that
they
need
a
working
group
to
have
continued
kind
of
conversations,
there
is
kind
of
some
precedent.
Other
areas
in
the
ITF
to
kind
of
spin
something
that
up
or
to
talk
about
terminology
or
frameworky
kinds
of
things,
so
I
think
everything's
on
the
table.
Sure
I.
I
Think,
as
I
said,
by
put
for
the
terminology,
is
cfrg,
so
so
I
guess
I'm
just
really
creating
another
group
with
like
kind
of
like
an
unbounded
Charter
so
like
I,
said
I,
think
I
think
I
would
like
be
a
little
bit
downward
and
say:
let's
see
nothing
just
for
the
moment.
R
My
I
have
two
points
here:
one
is
plug
for,
like
centralization
I
think
all
Protocols
are
going
to
have
to
answer
all
of
the
same
problems.
Do
we
hybrid?
Do
we
Flag
Day?
What
about
size
which
are
the
parameter
sets
like
every
group
is
going
to
have
to
Grapple
with
these,
let's
grapple
with
them?
Once
let's
have
one
group
that
can
say
hey,
why
don't
you
do
it
TLS
day?
Why
don't
you
do
what
ipsec
did
like
so
just
centralization
of
trying
to
not
repeat
the
same
debates
over
and
over
and
over
again
everywhere?
R
Second
point
I
want
to
make
is
I'll
credit.
This
idea
to
Ali
Becker
and
Rebecca
gutri
that
there's
going
to
be
protocols
that
are
forgotten
that
don't
have
a
home
so
a
place
to
sort
of
drag
up
all
this
stuff
that
needs
to
be
updated,
but
no
one's.
Looking
at.
X
M
Phil
Phil
hamburger,
yeah
I,
don't
understand
the
post,
Quantum
algorithms
and
I
suspect
that,
yes,
that
was
going
to
be
my
point.
You
know
I
I
suspect
most
of
us
that
aren't
from
the
point
of
view
of
how
do
we
apply
them
to
a
protocol
existing
or
past
I?
Don't
think
that
we've
actually
got
that
knowledge,
yet
I,
don't
think
it
exists,
because
you
know
you
have
the
algorithms.
You
have
the
cryptographic
protocols,
you
have
the
wire
protocols,
you
know,
pki
is
not
the
same
as
public
key
cryptography.
M
What
I
think
we
probably
need
is
probably
something
that's
kind
of
like
an
irtf
working
group
in
that
we
need
to
do
a
bit
of
education
and
a
bit
of
leveling
up
of
everybody
and
explaining,
what's
going
on,
we've
got
to
have
a
bit
of
people
bringing
in
the
thing
that
they've
developed
in
their
basement
and
showing
it
off,
and
we've
probably
got
to
do
that
for
quite
a
few
years
before
we're
really
going
to
understand
this
area.
But
the
good
news
is
I've.
Also
got
this
degree
in
nuclear
physics.
M
You
know,
I
did
experimental
in
nucleophysics,
I
can
spot
a
science
project
when
I
see
one,
and
you
know
looking
at
where
Google
and
IBM
are
today.
I
am
not
worried
about
a
quantum
computer
arriving
in
the
next
five
years.
Yeah
I'm
not
desperately
worried
that
we're
going
to.
We
have
to
do
this
on
a
an
emergency
basis.
There
is
time
to
do
it
right,
and
so
maybe
something
in
the
irtf
asking
them
to
spin.
Something
up
would
be
the
way
forward.
I
mean
yes,
they
have
a
post-quantum.
M
AE
Hi
Michael,
Richardson,
I,
guess
I'm
largely
agreeing
with
others,
I
I,
don't
think
we
need
to
run
around
building
a
group
for
orphaned
protocols.
I
think
that
we
need
to
do
it
we
need
to.
We
need
to
do
it
for
the
protocols
that
we
know
already
and
I
think
that
that,
for
those
orphan
protocols
that
might
be
out
there,
I
suspect
that
for
many
of
them
the
correct
answer,
I
I,
don't
know
what
they
are,
but
I
suspect.
AE
The
correct
answer
is
uplift
to
TLS
or
something
like
that
and
that
that's
as
much
work
as
fixing
whatever
they
had
out
there.
AE
Okay,
so
I
think
that
that's
what
one
thing
thing
the
other
part
of
it
is
that,
although
we
have
a
bunch
of
certificate
post,
Quantum,
hybrid,
whatever
that
means
protocols
in
in
lamps
I,
don't
feel
very
confident
that
we
have
any
idea
really
where
we're
going
that
way,
and
that
is
really
the
signed
data
at
rest
problem,
which
is
very
different
from
the
ipsecond
TLs
negotiation
problem
and
I,
and
we
could
actually
solve
I
think
we
could
actually
solve
those
things
in
either
order
right.
AE
We
could
replace
the
the
diffie-hellmans
on
the
protocols
with
post
Quantum
versions
and
we
could
replace
the
certificates
with
post
Quantum
certificates
signatures
and
we
actually
could
do
those
in
either
order.
I
mean
it
would
make.
Don't
you
don't
you
don't
get
any
any
success
until
you
have
both,
but
from
a
point
of
view
of
how
do
we
test
deployment
and
how
do
we
do
other
things?
I
suspect
it
really
doesn't
matter
and,
as
I
agree
with
Phil,
that
we
probably
have
a
little
bit
of
luxury
of
time
here
so
I
would
say.
C
Thanks
Scott
Scott
Fleur,
Cisco
Systems
one
point:
people
have
noted
that
we
have
plenty
a
lot
of
some
amount
of
time
to
solve
this
problem.
I
would
like
to
to
disagree
with
the
idea
that
it's
too
early
to
get
started.
We
have
plenty
of
time.
However,
this
is
a
big
task
in
front
of
us.
At
the
very
least,
you
know.
If
we
have
both
next
ietf
115,
we
might
have
a
working
group
starting
at
116..
That's
that's
eight
months
right
there
plus.
C
Then
they
have
a
bunch
of
time
working
on
the
various
deciding
what
to
do
and
and
actually
designing
the
the
updated
protocols
that
can
two
up
a
significant
amount
of
time.
I
would
yeah
and
and
then,
and
then,
as
Michael
mentioned
deploying
the
plane
is
even
worse,
so
I
would
recommend,
considering
to
starting
above
next
ITF
Ace.
H
Paul
Hoffman,
so
many
people
in
the
room
might
remember
Hillary
Orman,
who
was
very
active
in
the
ITF.
She
wrote
a
academic
document
towards
the
end
of
last
year.
This
is
this
comment
is
mostly
about
with
people
saying
how
soon
do
we
need
it
or
not?
Looking
at
the
state
of
quantum
computers
when
we
need
to
worry
about
them
specifically
for
cryptography
such
like
that
I
then
wrote
up
a
document.
H
If
you
want
to
look
it
up,
it's
called
octo031
about
post
Quantum
for
the
DNS,
just
you
know
locally
for
the
DNS,
but
we
do
have
both
things
where
we
use
signatures,
and
you
know
we
run
under
TLS
I'm,
simply
plugging
those
now
for
the
people
who
say
I,
you
know
like
I've,
been
following
the
news
and
I
think
quantum
computers
will
be
available
when
or
not
there.
There
is
actually-
and
there
are
plenty
of
other
academics
who
are
writing
this
up.
H
If
you
want
that
kind
of
thing
to
inform
your
decision
on
how
quickly
to
go,
please
look
at
the
document
or
wrote
or
come
talk
to
me
or
even
better.
If
you,
you
know
our
academic
look
at
Hillary's
document,
it's
very
very
you
know
it
goes
into
great
detail
and
such
like
that.
My
personal
belief
is
that
you
know,
especially
for
the
people
who
aren't
following
in
this
competition
when
we
say.
Oh,
let's
just
start
on
the
signatures.
H
Now
to
me,
that's
an
indication
you're
not
following
in
this
competition,
because
within
this
competition
just
came
out
saying
is
we
have
a
much
better
idea
about
about
the
key
exchange
than
we
do
about
signatures
and
they
pretty
much
punted
signatures
down
the
road
to
do
it
longer.
So
my
feeling
is:
if
you
want
to
be
doing
something
now,
you
should
be
looking
at
the
key
exchange.
E
K
Yes,
thank
you
so
just
to
maybe
comment
on
some
of
the
comments
that
have
been
post.
So
one
of
the
things
that
was
said
is
about
indeed,
if
quantum
computers
are
coming
and
how
urgently
is
indeed
to
migrate-
and
it
is
true
that
the
majority
of
the
research
that
has
been
recently
presented
states
that
a
quantum
computer
is
not
going
to
be
coming
sometime
soon
in
the
sense
that
it's
not
going
to
be
available
tomorrow.
But
that
doesn't
mean
that
traffic
is
not.
K
The
traffic
is
not
targeted,
meaning
that
someone
could
be
recording
right
now.
The
traffic
and
the
menu
that
are
powerful
quantum
computer
comes
available.
They
will
be
able
to
decrypt
that
path
traffic,
so
it's
not
only
about
the
future
traffic,
but
also
about
any
of
the
past
one.
So
the
threat
is
not
only
about
the
future,
but
also
anything
of
the
past.
I
really
like
some
also
some
of
the
comments
that
were
just
stated
that
this
is
not
only
about
the
cryptography
itself,
but
also
how
it
integrates
into
the
different
protocols.
K
So
the
challenge
that
right
now
in
this
is
is
actually
posing
to
us.
It's
not
about
selecting
an
algorithm
anymore,
specifically
in
the
key
exchange
each
part,
because
this
has
already
been
a
Sunday,
or
at
least
it's
a
signal
that
there
will
be
a
standardization
from
these.
So
if
we
just
standardize
at
the
IDF
level
the
same
algorithms,
we
will
just
be
repeating
the
same
work
that
this
is
doing,
but
the
actual
challenge
is
actually
how
to
put
in
them
into
the
networks
and
protocols.
Some
protocols
will
be
easy.
K
K
While
this
is
very
important,
but
we
should
also
not
not
do
the
work
of
just
repeating
what
one
working
group
is
doing
in
adult
day,
but
actually
have
maybe
a
centralized
place
where
we
actually
discussed
so
I
do
like
awesome
a
lot
of
the
idea
of
maybe
having
an
iitf
working
group,
because
this
might
be
something
that
is
more
related
to
research,
but
apply
research
in
that
it
put.
It
touches
a
lot
of
the
networks
and
protocols.
G
I
think
I'm
going
to
basically
agree
with
a
lot
of
what
Sophia
just
said.
So
yeah
I'd
like
to
Second
the
point
or
third
I,
think
now
the
point
about
there
being
value
and
having
a
central
location
to
have
these
communication
conversations
so
absolutely
agree
that
the
details
of
how
Protocols
are
developed
should
be
happening
in
TLS
in
ipsec
wherever,
but
at
the
minute.
It's
all
very
distinct
and
so
having
some
central
place
where
we
can
learn
from
what's
happened
elsewhere.
What
has
and
what
hasn't
worked
would
be
really
valuable.
G
E
F
Hi
yeah
I'm
John
Gray
from
entrust
and
I'm
putting
on
my
customer
hat
right
now,
because
that's
an
implementer
of
pki
and
cryptographic
solutions.
We've
been
asked
about
the
post
Quantum
area
for
many
many
years
we've
been
prototyping.
Not
actually
we
started
with
signatures
right
because
that's
how
pique
sorry
John?
Can
you
get
a
little
closer.
F
Better:
okay,
sorry
about
that
yeah.
So
as
a
putting
on
my
customer
hat,
I
was
saying
that
we've
been
prototyping
pqi
based
Solutions
with
these
post,
Quantum
algorithms
and
especially
signatures
so
I
mean
this
is
a
very
this,
isn't
something
that
I
think
can
wait
any
longer.
I
mean
it's
it's
something
that
comes
up
actually
weekly
for
us,
so
we've
already
implemented
certificates
and
have
has
customers
actually
wanting
to
use
them.
So
so
I
don't
think
it's
the
time
to
wait.
F
I
think
now
that
nist
has
actually
come
out
with
the
what
the
first,
what
they're
going
to
standardize
I
think
it's
actually
making
it
even
more
vital
that
this
move
forward.
So
I
just
wanted
to
make
that
point.
AF
So
when
we
were
faced
with
the
transition
from
sha-1
to
sha-256,
it
was
me
and
Steve
bellovan
up
there
trying
to
figure
out
how
to
orchestrate
that
across
a
whole
bunch
of
groups
and
the
lesson
learned
there
was
you're
wrong.
It's
going
to
take
way
more
than
that.
Okay,
we
thought
the
transition
would
take
five
years.
AF
There
are
still
Corners
today
that
are
using
child
one.
So
this
is
a
much
bigger,
more
pervasive
kind
of
a
thing.
Yes,
we
have
time,
but
we
have
to
worry
about
the
traffic.
If
that's
recorded
today
and
broken
when
the
quantum
computer
comes
along.
What's
the
lifespan
of
your
Children's
Health
Care
records,
let's
get
started
it's
going
to
take
a
long
time.
E
E
I
Yeah
a
few
points,
I
mean
first
I
think
just
like
to
get
clear.
Some
like
factual,
underbrush,
like
the
signature
stuff,
isn't
ready.
I
think
we
all
know
that,
and
so
like
the
best
we
can
do
really
is
like
kind
of
like
try
to
get
the
key
to
help
with
some
stuff
working
in
a
reasonable
way
and
then
hope
this
stuff
improves
or
people
get
a
better
understanding
of
it.
But
like
we
saw
a
presentation
TLS
yesterday
about
like
the
size
of
signatures,
and
it's
just
like
it's
going
to
be
big
problems
right.
I
I
I
I'm
generally
like
synthetic
to
this
argument
that
you
know
doing
something
out
of
traffic
protection
is
important
because
of
the
recording
recording
problem,
though
I'd
remind
people
like
you
know,
we've
been
sending
this
data
for
like
20
years
with
these
algorithms,
so
we
already
have
like
20
years
this
day
of
being
transmitted
around.
So
like
you
know,
another
10
minutes
may
not
be
a
deal
against
the
background.
I
A
lot
of
people
think
but,
like
it's
still
important
to
do
the
you
know
so
so
my
argument
is
not
that
we
should
do
nothing.
I
My
argument
is
that
we
have
a
sort
of
limited
amount
of
bandwidth
in
this
organization
and
a
number
of
people
who
know
how
to
work
with
these
algorithms,
who
are
which
are
new
and
have
properties
that
are
somewhat
unfortunate
in
some
ways
and
that
it
would
be
good
to
like
before
we
try
to
generalize
the
problem,
try
to
actually
solve
the
problem
once
or
twice
and
I
think
we
mostly
sold
I.
Think
TLS
actually
has
gotten
fairly
far
thanks
to
my
my
work,
but
like
Doug
Stabila
and
people
like
that,
and
so
like
I.
I
Just
like
to
see
us
nail
a
couple
of
them
down
and
then
try
to
generalize
out
that'll
mean
that
the
things
aren't
uniform
across
the
system
but
like
trying
to
make
it
uniform
will
mean
that
the
protocols
that
really
do
need
it
very
very
badly
right
now
will
not
get
it
actually
waiting
for
the
uniformity.
So
like
I
guess.
I
E
So
thanks
so
that
drains
our
cue
on
this
particular
topic.
We
appreciate
the
community.
You
know
feedback,
the
recurring
thing
you
know
we
do
here
when
we've
asked
this
time
and
we've
previously
asked
in
this
kind
of
temperature
check.