►
From YouTube: IETF111-SAAG-20210727-2130
Description
SAAG meeting session at IETF111
2021/07/27 2130
https://datatracker.ietf.org/meeting/111/proceedings/
B
Help
all
right,
so
we
have
located
our
minutes
taker
and
I
guess
I
will
attempt
to
watch
the
jabber,
but
if
someone
else
is
willing
to
watch
the
jabber
as
well
and
bring
anything
to
the
audio
stream,
that
is
appropriate
for
that.
That
would
be
great,
but
I
think
we
should
get
started
so
hello.
Everyone
welcome
to
sag,
I
am
ben
kaydock
and
room
dangloo.
B
My
co-id
is
also
sending
video
so
welcome
everyone
and
we
will
get
started
so
I
will
attempt
to
advance
the
slides
and
we
see
the
noel,
which
hopefully
is
not
new
to
you.
Normally.
This
tag
is
meeting
on
thursdays,
so
it's
almost
certainly
not
new,
but
we
are
earlier
in
the
week
this
time
and
just
noting
the
ipr
regime
under
which
we're
operating
all
of
the
key
information
is
in
the
bcps.
B
The
meeting
is
being
recorded,
of
course,
and
the
attendance
will
be
generated
automatically
from
the
data
tracker
data
so
to
the
agenda.
We've
got
the
usual
working
working
group
reports
and
80
reports
lined
up
and
then
michael
richardson
will
talk
a
bit
about
a
topic
that
was
actually
discussed
at
a
previous
sag
meeting,
and
then
we've
allocated
a
big
chunk
of
the
rest
of
the
time
to
sort
of
this
broader
topic
of
how
the
ietf
should
approach
post
quantum
security.
B
Of
course
we
are
on
tuesday
upon
us
asked
to
send
a
screen.
I
guess
I
got
retracted
so
since
we're
on
tuesday
there's
only
a
small
number
of
groups
that
have
actually
met
already,
so
I
put
those
broken
out
separately,
so
gene
app
maps
and
such
report
has
did
ipsec
me
and
lamps
and
droughts
and
sakum
and
of
course
the
cherry
slides
are
uploaded
in
the
data
tracker,
so
the
clickable
links
are
available.
If
you
retrieve
the
slides
from
there
and
suck
dispatch
as
well.
B
Of
which
already
sent
in
their
reports
as
well
in
advance,
so
thank
you
for
that.
I
was
not
expecting
somebody
reports
in
advance,
but
of
course,
for
everybody
else
once
the
group
has
met
or
if
you
meet
and
something
unusual
will
happen,
please
go
ahead
and
send
the
updated
report
or
the
actual
report
after
the
fact
as
well,
and
you
will
enjoy
seeing
those
on
the
email
list
and
then
there's
just
a
couple
more
later
in
the
week,
there's
also
some
groups
that
are
not
meeting.
B
We
also
got
some
reports
from
a
few
of
those.
So
thank
you
as
well.
I
guess
we
got
trans
just
before
the
meeting
and
then
stephen
reports
lake
as
well,
which
did
not
make
into
the
slides.
The
trans
report,
of
course,
is
roughly
just
saying
that
the
working
group
is
going
to
close,
which
is
always
exciting.
We
can
declare
victory
and
there's,
of
course,
plenty
of
related
topics
that
are
not
officially
in
the
security
area.
B
We
had
the
danish
buff
just
in
the
previous
session,
which
it
was
interesting
and
it
looks
like
we
will
have
some
discussion
on
the
email
list
about
what
the
actual
charter
would
look
like,
and
I
think
we
got
some
emailed
reports
for
at
least
a
couple
of
these
as
well.
I
think
I
saw
utah
and
the
nist
lightweight
crypto.
B
D
B
E
B
Okay,
I
think
the
queue
is
empty,
so
let's
go
to
the
sort
of
80
status
report,
so
we
currently
have
four
drafts
that
are
being
sponsored
and
a
two
and
two
split.
So
I
have
two
one
of
which
I
was
just
sent
to
the
rc
editor
within
the
past
week
or
two,
and
I
have
another
one
that
went
through
the
itf
last
call
and
got
a
lot
of
comments.
Many
of
the
comments
were
not
actually
in
the
form
of
direct
actionable
changes
that
could
be
made
to
the
text.
B
So
there's
been
a
bit
of
work
between
me
and
authors
to
try
and
interpret
these
comments
into
an
actionable
form
and
see
what
changes
we
commit
to
the
text
and
what
that's
going
to
evolve
into
so
there's
not
a
whole
lot
of
progress
there
and
then
roman
has
sort
of
picked
up
a
couple
of
these
relatively
more
recently.
So
did
you
want
to
say
anything
about
them?.
A
Yeah,
I
just
wanted
to
mention
that
the
first
three
documents
we
ran
through
sex
dispatch,
so
everyone
should
be
aware
that
we're
ad
sponsoring
just
that
last
one
is,
is
a
new
addition
to
my
queue,
we're
doing
some
coordination
with
w3c
on
on
updating
some
of
the
identifiers
for
xml
sect.
So
given,
given
the
coordination
with
another
sdo,
we
didn't
actually
run
that
through
set
dispatch.
I
picked
that
up
just
outright
we're
going
to
need
some
eyes
on
it.
B
Okay,
I
hear
some
reports
in
the
chat
that
maybe
I'm
too
quiet,
so
I
can
try
to
adjust
my
my
volume
a
little
bit
and
we
didn't
have
any
particularly
noteworthy
new
highlights
to
to
call
out
here,
but
we
have
sort
of
the
usual
couple
of
things
where
we
have
this
list
on
the
wiki
of
typical
issues
that
come
up
in
security
reviews,
which
we
encourage
many
people
to
look
at.
It
was
originally
written
actually
with
our
fellow
ads
as
the
audience,
but
certainly
working
group
chairs
document
shepherds
are
encouraged
to
look
at
it.
B
A
F
F
F
Traditionally,
it's
man
in
the
middle,
but
many
people
have
replaced
it
with
mallory
at
this
point,
is
intercepting
all
the
traffic
and
can
do
things,
and
this
is
the
typical
I'll
say
the
name,
doylov
yao
attack,
mallory
can
add
messages,
delete
messages,
modify
messages
and,
of
course
view
them
along
the
way,
and
so
this
is
pretty
clear,
and
if
this
is
what
you
mean,
then
it's
pretty
easy
to
understand,
but
there's
some
variations.
That
really
are
important.
F
So
next
slide,
please
one
of
them
is
mallory,
can
observe
but
cannot
delete,
cannot
insert
and
cannot
modify,
and
in
this
case
you
know
that
can
observe
so
our
traditional
defense
against
you
know
historical
20,
plus
year
old
sin,
spoofing
attacks.
If
you
can
observe
this
thing,
then
you
actually
get
to
defeat
the
sin
spoofing
attack,
because
you
can
see
the
magic
secret
sin
numbers
that
are
being
transmitted
and
therefore
do
things,
and
this
is
sometimes
people
think
this
is
a
non.
F
Have
called
as
an
on
path
attack
and
sometimes
they
haven't
and
that's
the
purpose
of
this
discussion
is
to
figure
out
what
to
call
this
next
slide.
Please
so
there's
another
kind
of
attack
which
people
think
of
okay
mallory
can
insert
messages,
can't
view
them
can't
delete
them
and
can't
view
the
I
said,
can't
view
them
there,
but
can
send
me
traffic
to
bob
and
attempt
to
attack
them
because
they're,
you
know
everyone's
on
the
internet
apparently
and
can
communicate
next
slide.
Please.
F
Actually
it
would
get
the
legitimate
message
from
alice.
This
is
not
such
a
crazy
attack.
Most
of
the
bent
fiber
attacks
could
probably
do
this
and
we've
seen
a
lot
of
attacks
involving
bgp
and
other
things
like
this.
Where
attackers
essentially
could
divert
traffic
through
their
network
and
if
their
network
was
faster
than
another
network,
they
can
do
things
so
next
slide,
please!
F
F
So,
as
I
said,
many
people
are
quite
happy
with
the
concept
that
we
would
replace
the
word
man
and
man
in
the
middle
with
mallory,
and
so
we
retain
the
acronym
mitm
there
and
the
mitm
attack
is
usually
the
dolo
of
yao
attack,
but
not
always
so.
The
other
recommendation
suggestions,
I've
seen
is
on
the
side
in
the
rough
and
I've
seen
a
couple,
people
say
well,
what
does
rough
mean
and
it's
a
golf
term.
F
That
means
that
you're
not
on
the
fairway
you're
out
in
the
in
the
in
the
woods
somewhere
and
that's
the
case
where
you're
not
actually
in
the
on
the
on
the
connected
at
all
next
slide,
please
so
from
quick.
We
have
on
path
limited
on
path.
That's
really
confusing
to
me
an
off
path.
Attack.
Alan
decox
suggests
the
council
of
attackers
the
malicious
messenger,
the
oppressive
observer,
which
are
designed
to
be
both
terms
to
be
literate,
alliterative
and
off
path.
Attacker
and
next
pa
slide.
I
think
that's
the
last
one
yeah.
F
So
do
we
need
to
do
anything?
Okay,
so
I
would
like
to
have
terms
that
I
could
think
we
agree
with
and
there
was
a
interaction
I
had
on
one
mailing
list
about
two
weeks
ago.
When
I
had
to
say
well,
wait:
did
you
mean
type
one
attack
or
type
two
attack,
because
there's
two
different
effects
of
this
and
well?
The
answer
is,
it
was
unclear
and
that's
why
I
think
we
need
to
just
pick
some
terminology
and
stick
with
it.
F
Some
some
questions,
lots
of
things
go
by,
I
guess,
come
to
the
microphone
right,
can't
pick
anything
steven
asked
about
the
reflection
attack
and
I
don't
know
if
that
is
that
a
new
kind
of
attack-
that's
not
clearly
done
by
something
that
is
either
on
the
side
or
in
the
middle
yeah.
As
ted
hardy
says,
bike
shed
once
and
for
all.
F
F
G
This
is
daniel
kahn
gilmore.
So
I
appreciate
the
concern
that
we
don't
seem
to
really
have
a
great
set
of
standardized
terms.
I
am
really
reluctant
to
settle
on
terms
like
mallory.
It
creates
a
kind
of
an
in-group
game.
I
mean
it's
fun
to
play
that
game
like
oh,
we
all
know
who
eve
is.
We
all
know
who
mallory
is.
I
I
don't
think,
that's
particularly
useful,
because
I
think
it
actually
alienates
people,
and
what
we
want
here
is
to
be
communicating
with
more
people.
So
I
think
I
agree
with.
C
G
G
H
Hi
is
the
mic
on
yes
great
yeah.
I
went
to
machine
in
the
middle
as
well
and
then
it
struck
me
that
actually
the
problem
in
that
one
isn't
the
first
m.
It's
the
second
m
because
in
the
middle
refers
so
clearly
to
that
first
positioning
of
mallory
between
alice
and
bob,
and
it's
a
it's
a
much
less
clear
description
of
the
off
path
attack.
So
the
the
passive.
H
What
is
sometimes
proposed
as
a
ghost
protocol
where
the
attacker
is,
is
not
actually
directly
interfering
in
the
past
but,
for
example,
gets
a
copy
of
alice's
keys
right
yeah.
So
I
do
favor
the
descriptive
the
descriptive
labels
and
I'm
not
quite
sure,
then
what
we
do
about
either
of
the
m's
in
mitm.
H
H
H
B
E
E
I
would
caution
about
sort
of
the
more
limited
wintry
scenarios.
These
are
not
realistic,
I
think,
because
you
have
the
ability
to
elevate
them.
If
you
can't
intercept
packets,
that's
fine,
just
jam
the
shared
medium
whenever
a
packet
that
you
want
to
interrupt
can
happen
and
thanks
to
the
way
error,
detection
works
and
wi-fi
you
have
enough
microseconds
to
do
this,
so
it's
important
that
we
maintain
the
same
security
goals
as
we
always
have
going
back
to
whatever
the
current,
wherever
the
rfc
number
it
defines.
H
H
D
C
B
B
A
We
have
a
couple
slides
for
facilitation,
so
if
you'll,
let
us
get
through
the
tee
up
of
those
three
kind
of
slides,
we'll
then
open
up
the
mic
line,
and
we
really
want
to
hear
your
kind
of
perspective
on
what
other
framing
we
should
be
doing
and
some
of
the
things
that
we
we
may
or
may
not
want
to
be
advancing
forward
with
so
next
slide.
Please.
A
Okay,
so
to
greatly
oversimplify
a
highly
technical
and
nuanced
topic,
the
threat
as
we
see
it,
is
that
eventually
there
will
be
a
quantum
computer
of
sufficient
size.
That's
going
to
create
problems
for
the
current
choices
we're
making
for
for
various
crypto
algorithms.
You
know
it
may
be
a
matter
that
the
existing
primitives
we
have
may
be
weakened.
It
may
be
the
case
that
they
are
outright
kind
of
broken,
so
we
believe
that
the
desired
outcome,
given
that
threat
is
to
take
th
all
the
various
work.
A
Now,
there's
a
lot
of
unknowns
kind
of
here
and
I
think
in
the
discussion
we're
going
to
have
we're
going
to
solve
none
of
them,
but
we
wanted
to
enumerate
them
because
they
may
influence
how
you
know
how
we
have
how
we
have
the
conversation.
Even
if
we
don't
necessarily
know
the
answers
so
just
to
be
fully
kind
of
upfront.
We,
of
course,
don't
know
when
we're
going
to
have
the
advent
of
said
quantum
quantum
computer,
that's
going
to
undermine
the
crypto.
A
We
have
some
historical
precedence
for
prior
crypto
migrations.
What
we
know
is
you
know
it
takes
a
long
time
to
do
the
design,
the
implementation
and
even
longer
to
do
the
the
modernization
which
is
to
swap
out
the
old
way
with
the
new
way
and
that's
probably
measured
in
minimally.
You
know
minimally
a
decade
probably
longer
to
do
an
algorithm
kind
of
swap.
A
If
that
exists,
we're
all
ears-
and
we
want
to
know,
but
the
exact
scope
of
even
what
we'd
want
to
tackle
in
the
itf
isn't
so
clear
and
also
the
research
to
develop
some
of
those
quantum
resistant
approaches
or
at
least
publicly
kind
of
vet
them
isn't
done
either.
But
we
know
that
once
we
even
had
a
list,
it's
probably
not
going
to
be
a
straight
swap
because
the
form
and
fit
might
be
different
of
those
perimeters.
A
So
no
good
kind
of
answers
on
those
unknowns,
but
what
we
want
to
talk
about
is
given
those
unknowns
and
given
that
desired
outcome,
if
that
is
indeed
the
outcome,
the
community
feels
feels
we
need
to
be
heading
down.
How
do
we
tackle
that
so
next
slide,
please
so
a
bunch
of
early
thoughts
on
it
and
first
just
to
really
motivate.
Why
are
we
talking
about
it
here
in
sag?
And
you
know
why
didn't
we
talk
about
it?
A
While
we
have
a
bunch
of
unknowns,
a
couple
of
things
are
fairly
clear
to
us.
The
first
one
is
that
whatever
we
decide
to
do
whatever
is
the
scope
of
the
work
it's
going
to
be
cross-cutting,
it's
not
going
to
just
happen
in
sec
and
kind
of
more
broadly,
it's
going
to
happen
in
partnership
with,
with
folks
outside
of
the
ietf.
I
mean
we're
going
to
be
in
the
business
of
the
standardization,
but
in
terms
of
core
algorithm
development
and
vetting.
A
While
we
may
not
know
exactly
the
amount
of
work
it
is
or
what
the
natural
clusters
of
that
work,
our
feeling
is,
there
is
going
to
be
some
work
to
do,
and
it's
going
to
exceed
the
bandwidth
of
doing
something.
That's
80,
sponsored
so
kind
of
saying
we
have
a
doc
all
right,
ben
and
roman
are
the
future
ads.
You
take
that
it's
it's
likely
not
that
the
pipeline
is
going
to
be
too
big
to
reasonably
do
kind
of
turn
around.
A
Post-Migration
topics
next
slide,
please,
okay,
so
giving
that
tee
up-
and
this
is
kind
of
the
last
slide,
because
before
we
really
really
so,
your
feedback
is,
as
we
think
about
that
approach.
There's
at
least
five
questions,
maybe
more.
Please
do
kind
of
share
about
that.
We'd
be
interested
in
in
getting
some
feedback
on
so
kind
of.
First,
what's
what's
the
way
we?
What
is
the
way
we
want
to
have
a
conversation
about
it?
So
how
do
we
come
up
with
the
plan
to
the
plan
and
there's
a
continuum
of
options?
A
I
mean
some
of
you
may
feel
we'd
be
interested
to
hear
that
you
know
we're
talking
about
it
enough.
Nothing
more
is
required.
We
could
talk
about
mailing
lists,
all
the
way
up
to
something
highly
formal,
which
is
what
I
call
a
mop
style
working
group.
So
for
folks
not
aware
the
ops
area
created
the
media
operations
working
group
because
the
vtc
operators
wanted
to
have
a
standing
place
to
talk
about
things
with
and
of
industry.
A
We
also
like
to
hear
about
what
you
think
is
the
scope
of
the
problem
that
ietf
should
be
tackling
you
know
listed.
There
are
a
number
of
what
we
consider
orphan
protocols
that
don't
have
easy
and
easy
maintenance
maintenance
path,
but
probably
will
need
crypto
agility
in
the
post
quantum
case.
We're
also
interested
to
hear.
How
do
you
want
that
work
to
be
done?
I
just
previously
talked
about
set
dispatch.
A
You
know
the
other
pendulum
is
pulling
on
the
experience,
the
closest
experience
we
have
at
least
to
the
last
time
we
tried
to
do
a
wholesale
shift
of
crypto,
which
was
with
curdle,
where
we
had
a
number
of
protocols
that
we
wanted
to
imbue
with
elliptic
curve
and
aead
kind
of
functionality,
and
so
we
had
a
catch-all
last
resort
working
group.
We
could
do
that
for
post
quantum
as
well
and
we
have
a
draft
kind
of
charter.
A
That's
not
certainly
not
ready
for
prime
time
but
gives
you
a
sense
of
what
a
template
of
that
would
look
like
and
we're
equally
interested
to
kind
of
understand.
Almost
irrespective
of
the
answers
to
the
questions
before
you
know,
when
do
we
start
do
we
need
to
start
now
or
are
there
gating
functions
that
you
perceive?
A
We
need
to
be
thinking
hard
about,
and
and
finally
you
know,
do
we
have
the
right
folks
in
the
itf
to
kind
of
tackle
that
or
do
we
need
to
start
thinking
about
who
else
we
would
need
to
kind
of
bring
in?
So
that's
a
big
kind
of
mouthful
before
we
turn
over
the
floor
ben.
Do
you
want
to
comment
a
little
bit.
H
If
they
get
a
quantum
computer
in
10
years
time,
they
can
still
decrypt
traffic
from
today,
whereas
authentication
that
has
to
be
sort
of
online,
or
rather
until
someone
has
a
quantum
computer.
Now
they
can't
break
anything.
So
one
of
those
things
is
super
urgent
and
needs
to
be
dealt
with
asap
and
one
of
those
things
like
we
can
leave
until
you
know
we
actually
know
what
algorithms
we
want
to
use.
For
example,.
I
Paul,
so
I
would
love
to
repeat
what
jonathan
said,
but
even
more
emphatically,
which
is,
if
you
think,
about
cas
and
such
like
that
they
have
keys
that
might
be
valuable
for
20
years
or
so
that
they
don't
want
people
using
encryption
will
always
be
more
valuable
than
signing,
because
you
can
change
your
signing
key
easily.
You
can't
change
your
encryption
that
you
did
before,
so
it
would
be
extremely
valuable
for
us
to
split
those,
but
also
related
to
that.
I
One
of
the
things
you
ask
in
this
last
slide
is
nist
pq
round
three.
At
this
point,
nist
is
not
assuming
that
they're
going
to
have
any
signature,
algorithms
very
anytime.
Soon
and
at
least
what
they've
said
so
far
for
signature
algorithms
is
they
may
have
multiple
when
they
finish
their
first
round.
There
is
some
for
those
of
you
who
are
not
following
the
nist
post
quantum
mailing
list,
which
is
probably
most
people.
There
are
a
number
of
people
who
are
are
also
arguing
for
multiple
outputs
for
encryption.
I
I
This
makes
things
very
hard,
particularly
because
we
truly
don't
know
when
we
are
going
to
need
these.
There
are
many
cryptographers
and
engineers
who
believe
that
we
may
never
need
them.
I
mean
we
certainly
want
to
be
prepared
and
all
of
that,
but
there
are
a
fair
number
of
people
who
believe
we
will
never
get
exact
quantum
computers.
I
J
J
So
finding
a
good
version
of
that
is
what
is
going
to
be
take
more
time
and
actually
thinking
what
impact
is
going
to
be
to
the
latency
and
to
the
traffic
and
to
the
different
network
protocols.
Right
now,
we're
currently
doing
some
work
on
tls,
specifically
to
see
how
we
can
actually
change
the
signature,
algorithms
and
if,
indeed,
using
simply
doing
the
change
of
using
those
quantum
signatures
is
enough
or
is
going
to
really
have
a
big
impact
in
the
network
itself,
and
I
think
that
consideration
has
also
to
be
for
dns
for
ip.
B
F
My
understanding
is
that
the
problem
with
privacy
and
encryption-
it
fundamentally
goes
down
to
whether
or
not
someone
can
break
the
key
agreement.
Algorithms-
and
I
don't
I
mean
I
don't
complain-
I
don't
think
I
really
understand
all
of
that,
but
a
lot
of
that
situation
to
me,
as
someone
said,
is
you
know
a
lot
of
that?
I
think,
is
slightly
fungible
in
the
sense
that
it's
pretty
easy
to
switch
with
a
little
bit
of
leeway.
I
mean
like
it.
F
I
actually
think
that's
critical
path
for
everything
else.
I
think
it
should
probably
be
left
where
it
is,
and
once
we've
kind
of
solved
that
and
have
a
little
bit
of
running
code,
then
I
think
that
a
kernel-like
working
group
is
the
right
way
to
go
after
that,
and
I
also
I
wonder
whether
or
not
some
of
the
algorithms
that
we're
going
to
get
may
actually
have
some
interesting
attributes
such
that
wow.
We're
like
well,
actually
it's
better
for,
even
if
we
never
get
to
post
quantum.
F
B
C
C
C
Second
point
I'd
like
to
make
is
that
somebody
mentioned
dividing
confidentiality
and
or
integrity.
I'd
also
like
to
suggest
that
we
have
a
divide
between
post-quantum
algorithm
approaches
and
other
remediation
approaches.
One
of
the
things
in
lamps
is
russ's.
Draft
sticking
a
symmetric
key
into
an
s
mine
into
a
cms
package,
so
that
you
have
a
second
key
that
you
have
to
get,
and
that
makes
it
quantum
resistant.
C
I
think
that
there
may
be
much
more
interesting
approaches
in
that
area
that
we
can
get
deployment
on
sooner
rather
than
just
saying:
oh
well,
the
post
quantum
algorithms
are
going
to
sort
it
all
out.
They
probably
won't
because
they're
not
going
to
exactly
match
what
we
expect
from
public
key
cryptography.
K
Thank
you
and
I
I
fully
support
this
work
and
I
really
enjoy
the
distribution,
so
I
I
just
want
to
make
the
point
on
signature.
So,
of
course
we
all
understand
the
that
journal
and
decrypt
later
issue
with
the
exchange,
but
still
signature
are
also
important
because
they
are
used
for
legal
documents.
So
some
of
the
documents
stein
with
this
digital
signature
must
be
valid
for
30
years.
So,
of
course,
you
can
update
at
some
point
the
signature
it's
easy,
but
we
are
speaking
of
billions
of
documents
sign
it.
L
You're
next,
so
this
is
actually
just
a
quick
point
on
your
last
question.
Who
do
we
need
to
engage
beyond
the
current
itf
community
and
to
suggest
that
maybe
orphan
protocols
as
a
category
may
need
to
be
broken
down
a
bit?
There
are
certainly
some
protocols
that
were
produced
in
the
itf,
which
are,
in
fact
no
longer
under
active
implementation.
So.
C
L
Might
not
be
dead
in
the
fact
that
there
are
there's
active
traffic
on
the
network
about
them,
but
there's
no
developer
community
to
go
to
and
ask
for
changes
of
this
scale
or
type.
So
there
are
classes
of
traffic
like
that,
and
we
need
to
separate
those
out
from
those
in
which
there
is
an
active
set
of
developers
and
implementers
that
we
could
reach
out
to
within
that.
L
I
think,
there's
there's
kind
of
two
classes,
one
in
which
they're
they're
here
at
the
ihf
to
some
degree
and
need
to
be
gathered
into
a
working
group
and
those
where
they're
not
at
the
itf
at
all
anymore,
where
it's
it's
basically
moved
out.
So
I
think
there's
a
triage
element
to
this,
where
you're
basically
going
to
end
up
saying
that
there's
no
developer
community
for
this
protocol
anymore
and
even
if
we
wrote
a
spec,
it
would
never
get
deployed.
L
L
If
you're
going
to
go
that
direction
and
the
last
one
is
going
to
be
the
hardest
where
there
is
a
working
set
of
developers,
but
they've
left
the
itf
for
somewhere
else
and
there
we're
going
to
have
to
give
up
change
control.
So
I
think
that's
going
to
be
a
bit
problematic.
But
that's
really,
I
think,
an
isg
decision
to
figure
out
which
ones
are
in
which,
when
it's
setting
up
the
charters
for
either
the
individual
groups
or
the
or
the
omnibus
group,
thanks.
M
B
N
It's
clear
that
if
we
try
to
be
proactive
on
approaching
this
possible
and
upcoming
security
threats
or
protocol
threats
or
vulnerabilities,
that
will
come
up
post
quantum,
it's
clear
that
if
we
try
to
be
proactive,
we
might
not
approach
the
solutions
in
the
most
effective
way.
All
right.
I
get
that.
B
O
Back
when
I
was
security
area
director,
we
thought
we
could
do
that
in
five
years
and
we
were
way
wrong.
We
could
get
the
rfcs
done
in
like
18
months,
but
10
years
later
the
transition
was
still
going
on.
So
just
even
looking
at
this
swapping
diffy
helmet
for
the
kem
is
something
we
need
to
it's
going
to
take
us,
probably
more
than
18
months,
to
get
the
rrc's.
D
P
So
it's
probably
worth
noting
that,
like
different
things,
proceed
on
different
time
scales
right,
I
mean
that's
obvious
but
like,
but
just
to
just
to
recap:
you
know
if
you
know
if
we
had
an
algorithm,
if,
if
we
had
like
a
post-confidential
algorithm
and
a
post
quantum,
you
know
a
key
exchange
algorithm,
we
all
agree
was
good
right.
You
know
that
could
be
landed
in
you
know
you
could
land.
P
Maybe
it's
worse.
I
guess
it's
also
worth
noting,
as
I'm
sure
some
people
noted,
that
the
value
proposition
of
each
of
these
is
somewhat
different,
which
to
say
that
you
get
value
by
doing
the
key
exchange
like
soon,
but
you
can
value
by
doing
the
authentication
only
when
you
stop
accepting
the
logarithm
so
like
that's
actually
quite
a
bit
down
the
line,
so
I
I
guess
I'm
sort
of
like
somewhat
enthusiastic
about
trying
to
like
get.
P
You
know,
get
these
post
quantum
key
establishment
things
in
as
long
as
it's
not
too
expensive
and
I
think,
even
trying
about
contrary
composition
in
jabber.
I
don't
think
it's
a
problem
to
try
a
couple
of
them.
You
know
we
could
get
some
some
sense
of
where
I
thought
that
the
points
are
for
what
produces
unacceptable
performance
degradation.
I
I
think
I'd
like
really
like
to
hold
fire
on,
like
all
these
al,
all
the
pki
stuff.
P
G
G
B
G
Mls
is
kind
of
in
that
boat,
but
it's
not
as
store
and
forward
as
other
things
like
s
mine.
So
I
just
wanted
to
point
out
that,
when
we're
thinking
about
the
the
confidentiality
case,
it's
not
all
as
easy
to
roll
out
a
new
algorithm
as
it
is
to
roll
out
an
update
to
tls,
not
that
that
was
ever
easy,
but
it
might
even
be
harder
and
stronger.
B
I
Since
we
have
a
bit
more
time,
one
of
the
other
things
to
remember
is
that
quantum
computers,
as
they
start
to
be
being
built
if
they
are
ever
successfully
built
to
you,
know
the
large.
The
large
enough
size
are
going
to
be
exceptionally
expensive
per
per
instance
to
break
so
current
estimates
are
that
it
might
cost
literally
a
hundred
million
dollars
to
break
a
single
key
pair.
That
will,
of
course,
get
cheaper
over
time,
assuming
that
the
engineering
gets
better
over
time.
I
But
given
that
an
attacker
and
the
early
attackers
who
might
own
these
things
will
certainly
most
likely
only
break
key
pairs
that
have
high
value
and
the
highest
value
ones,
of
course,
are
going
to
be
confidentiality
not
and
not
signatures.
Even
if
you
could
break
the
signature
break,
for
example,
a
ca's
private
key,
you
would
only
have
a
very
limited
number
of
times.
I
I
First,
not
only
should
we
be
thinking
about
who
are
the
people
who
would
be
most
affected
by
previous
keys
being
broken,
but
also
what
will
the
attackers
want
to
break
and-
and
I
sincerely
think
that
they'll
want,
that
they
already
know
which
messages
which
encrypted
messages
they
very
much
would
like
to
see.
The
inside
of
thanks.
C
Yeah
I'd
just
like
to
say
that
I
think
that
we're
going
to
be
seeing
a
different
character
to
the
way
that
we
use
crypto,
particularly
for
authentication
in
that,
in
the
way
that
we're
using
encryption
authentication
today,
you
know
we
do
a
public
key
authentication
and
just
throw
it
away.
We
just
don't
think
about
it.
C
On
the
other
thing
thing
about
confidentiality,
this
is
one
of
the
few
things,
the
very
few
things
that
blockchain
is
actually
good,
for,
if
you
take
a
document,
you
put
it
in
a
blockchain.
You
know
that
it
went
in
there
at
that
time,
and
so
maybe
what
we
need
to
think
about
is
one
of
those
pro
tem
measures
is
an
open
spec
that
doesn't
involve
crypto
or
criminal
currency
ideology
as
a
way
of
solidifying.
Our
signatures.