►
From YouTube: IETF100-SAAG-20171116-1330
Description
SAAG meeting session at IETF100
2017/11/16 1330
https://datatracker.ietf.org/meeting/100/proceedings/
A
A
A
Okay,
so
all
right
I
can
hear
it,
echoing
so
just
some
be
very,
very
close.
Alright,
so
we'll
run
through
our
usual
administrivia,
and
then
we
have
one
invited
talk,
and
this
is
by
min-suk
king
on
inter-domain,
DDoS
mitigation
potentials,
challenges
and
solutions,
so
that
will
be
right
after
the
administrivia
and
we're
gonna
run
through
our
working
groups,
and
thank
you
because
I
think
we
have
almost
all
of
the
reports,
so
we're
just
gonna
breeze
through
this
to
try
to
give
more
time
to
sec
dispatch
ace.
A
A
We
will
update
the
slide
yeah
good
job
Zack
thanks
second--
is
somebody
here
from
second
vent
that
could
get
up
at
the
mic.
I
think
that's
the
only
one
we
don't
have.
A
Second
en't,
going
once
going
twice,
I
will
make
sure
it
goes
out
to
the
list
TLS.
Thank
you
for
turning
that
around
so
quick
yep
I
took
line.
Thank
you
trans!
Thank
you
and
related
working
groups,
so
here
we'll
just
breeze
through
we
have
a
bunch
of
them
that
got
sent
to
the
list
already.
If
you
have
something
important,
you
think
should
get
shared
with
a
security
area.
If
you
could
please-
and
you
represent
one
of
these-
please
go
to
the
mic
and
I
can
say
them
in
case.
A
You
can't
see
them
so
anima
and
I
don't
care
what
order
I
just
have
to
restate
which,
which
related
working
group
anima,
Dee,
bound
dime
dispatch,
Demark,
deprived
HTT,
biz,
quick
net
comp
ntp,
perk,
radix,
cider,
TCP,
Inc
and
Utah
any
of
those
I
think
some
of
them.
We
should
get
some
reports
that
we
haven't
seen.
A
A
All
right,
I
guess
with
that
I
think,
let's
see
what
the
next
box,
so
we
had
to
and
I
believe
both
reports.
Oh
I,
know
we
have
a
report
for
suit
already,
so
thank
you
for
sending
that
and
and
the
t
p--
both
made
their
report
in
just
in
time.
Thank
you.
Alright
presentations,
min-suk.
If
you
could,
please
come
up
we'll
swap
over
to
your
slides
and
look
forward
to
your
presentation.
C
Okay,
hello,
can
you
hear
me
back
there.
C
Okay,
pink
box,
Thanks,
okay,
good
afternoon
everyone,
my
name-
is
min
su
Kyung
I'm
from
National
University
of
Singapore,
local
and
I'm,
also
a
first
attendee
of
the
IETF
I'm,
enjoying
this
first-time
event
for
me
and
today,
I'm
going
to
talk
about
our
ongoing
project.
Very
recent
ongoing
project
on
the
inter
domain,
DDoS,
mitigations
and
I'm
really
happy
to
discuss
this
with
you
guys
with
ITF
community,
because
I
believe
that
this
is
this
topic
is
especially
related
to
some
of
the
working
groups,
including
the
OTS
and
the
teep.
C
Is
it
working
okay,
cool
and,
as
I
said,
this
is
our
ongoing
work.
So
if
you
have
any
suggestion,
feedback-
and
you
know
anything
after
that-
the
talk
just
please
let
me
know
that
would
be
really
helpful
and
I
have
a
quicker.
So,
as
many
of
you
already
know,
you
know
large
scale.
Volumetric
attacks
are
so
common
these
days
and
they
often
congest
more
than
one
networks
and
they
on
the
internet
and
we've
seen
the
escalation.
C
Hello,
cool
thanks,
so
we've
seen
the
escalation
and
volume
of
ddos
attack
traffic.
You
know:
we've
seen
300
gig
in
2013
and
1.2
tera
last
year,
so
huge
increase
and
the
volumetric
attacks
often
flood
upstream
autonomous
systems
as
well.
According
to
a
recent
Arbor
networkers
report
and
worse
yet
there
has
been
couple
of
advanced
link,
flooding,
attacks
from
academia,
including
crack
or
melt
and
crossfire
attack.
The
claims
to
be
able
to
you
know
lunch
flooding,
attacks
against
the
links
they're
connecting
multiple
aliases
or
even
the
you
know,
links
inside
on
AES.
C
So
this
entire
domain,
DDoS
mitigation,
sometimes
becomes
really
necessary
for
large-scale
against
a
large-scale
volumetric
attacks
and
in
particular,
inter-domain
packet.
Filtering
operation
is
often
necessary
when
interes
links
are
flooded
because
and
and
then
they
you
know,
ejs
cannot
do
anything
about
it
and
large
portion
of
AES
is
just
flooded
and
they
have
no
capability
to.
C
So
when
you
talk
about
the
inter
domain
mitigation
for
DDoS,
actually
the
Holy
Grail,
really
the
holy
grail
of
the
inter
domain
mitigation
is
what
we
call
the
source
and
filtering
where
destination
AES
directly
talks
to
the
AES
that
are
actually
serving
those
potential
attack
sources.
By
directly
saying
that
hey,
please
drop
XYZ
packets,
and
then
you
know
so
say
yes,
okay,
okay,
I
will
set
up.
C
You
know
some
firewall
or
packet
filters
and
then
the
packet
are,
you
know,
dropped
at
the
source
AES
and
the
meeting
that
the
leaders
attacked
at
the
destination
is
mitigated,
and
this
is
actually
an
ideal
form
of
DDoS
mitigation
because
it
really
stops
the
the
attacks
earlier
by
outsourcing
the
filtering
to
the
source.
Aes
and
a
couple
of
examples,
including
you
know,
D
word
or
stop
it.
You
know,
in
terms
of
you
know,
academic
projects.
C
There
has
been
clear
advantages:
reduction
of
bandwidth
waste
because
you
stop
the
attack.
You
know
at
the
source,
not
at
the
destination,
so
you
can
save
lots
of
bandwidth
and
you
can
cut.
You
can
reduce
the
cost
and
also
some
resource
demanding
filtering
operations
like
complex,
complicated
rate
limiting
can
be
also,
and
we
you
know,
executed
at
the
source
is
because
source
a
is
is
not
under
attack,
but
destination
is
under
attack,
so
they
have
resource.
Also,
some
local
context
at
the
sources
can
be
used
can
be
utilized.
C
For
example,
the
source
is
may
know
some,
you
know,
user
suspect.
You
know
list
of
user
suspects
under
their
customer
networks,
so
it
can
be
actually
used.
So
this
source
and
the
filtering
looks
really
fine,
but
this
has
not
been
deployed
in
the
current
internet
due
to
the
lack
of
trust
between
aliases.
So
what
do
I
mean
by
this?
Is
simple
source
AES
and
destination
a
yes,
they
actually
mutually
untrusted.
The
reason
is
that
they
have.
C
There
is
no
direct
business
relationship
between
the
so
CAS
and
the
destination
is,
is
they
are
you
know
multiple
AES
hops
away
from
each
other?
They
are
basically
random
guys
on
tape
on
the
internet
and
there's
no
direct
agreement
between
the
two,
so
they
mutually
distrust
each
other,
and
this
these
mutually
under
untrusted
AES,
may
launch
attacks
to
each
other.
For
example,
the
source
a
is,
on
the
left
hand,
side
may
try
to
modify
the
requested
policy
from
the
destination
AES.
C
You
know
the
the
the
request
and
even
worse,
it
can
may
leak
the
requested
policy
from
the
destination
AES.
Also,
the
sources
may
not
have
any
strong
incentive
for
doing
this
for
the
source.
Aes
I
mean
yeah,
because
you
know
filtering
operation
at
the
source.
Aes
incurs
non
negligible
cost,
so
really
the
source
a
is
needs
a
strong
incentive
to
do
that,
but
we
don't
have.
We
don't
see
the
strong
incentive
for
this
and
worse.
Yet
there
is
a
risk
of
dropping
packets
for
the
source
on
behalf
of
others.
C
So
at
the
end
of
the
day,
the
source
is
helping
the
destination
at
AES,
which
is
you
know,
random
guys
on
the
internet
and
it
the
source
is,
may
be
blamed
for
dropping
its
own
customers
packet
at
the
end
of
the
day.
So
to
that
end,
we
believe
that,
in
order
to
actually
implement
this
source
and
filtering,
we
really
need
to
think
about
the
collaboration
rather
than
the
outsourcing.
So
what
that
means
is
that
source
and
the
destination
is,
is
collaboratively
determining
the
filtering
policies.
C
Let's
say
the
source
AES
has
some
premium
customer
or
mission-critical
service
that
he
really
wants
to
protect
when
there
is
an
attack
again
attacks
at
the
destination.
A
yes
and
now
the
source
has
a
opportunity.
Is
a
capability
to
express
that
and
really
enforce
that.
But,
as
we
try
to
really
implement
this,
you
know
pure
collaboration
operation.
We
immediately
faces
a
couple
of
security
challenges.
First,
how
to
really?
How
can
we
really
guarantee
the
fare
policy?
C
Competition
between
the
two,
you
know
so
say
yes
and
then
destination
a
is,
and
at
the
end
of
the
day
they
are
untrusted.
They
they
don't
trust
each
other.
How
can
we
do
it
in
a
fair
manner?
Second,
how
can
we
protect
the
sensitive
filtering
policies
from
each
other?
You
know
those
two
untrusted
AES
is
I
mean
their
own
policies
independently
created
policies,
and
it
is
combined
and
in
some
way
and
how?
How
do
we
guarantee
the
privacy
of
those
policies
and
the
third?
C
What
if
the
source
is
who's
actually
executing
the
the
filtering
operation
wants
to
bypass
stuff
packet
filtering
when
it
doesn't
like
the
decision
of
the
packet
filtering.
So
these
three
you
know,
security
concerns
are
really
the
major
concerns
we
discovered
and
we've.
We
just
summarized
that
I
know
a
couple
of
desired
properties
for
this,
so
first
property
we
really
need
to
have
here
is
what
we
call
the
verifiable
fairness,
so
that
is
policy
composition
of
the
two
must
be
fair
and
verified
by
both
source
and
destination
aliases.
C
So
again,
this
is
a
collaborate,
collaborate
on
platform,
not
the
outsourcing
platform.
So
the
fairness
really
is
the
key
between
the
two
untrusted
AES
and
by
fair.
What
we
mean
by
is
that
we
find
we
try
to
find
a
middle
ground
between
the
two
policies,
two
independent
policies.
So
in
this
very
simple
example,
on
the
left
hand,
side
there's
a
source,
a
s
source,
a
yes
may
have
four
policies:
I
mean
I'm,
sorry
for
flows
and
the
top
top
one
is
the
higher
pass
of
higher
priority,
and
the
bottom
one
was
has
a
low
priority.
C
You
know
for
one
ABCD
and
destination,
AES
may
have
different
policy
in
different
order.
I
mean
for
for
simplification.
We
we
assume
that
they
have
same
flow
definitions,
but
as
a
as
we
compose
those
two
different
policies,
we
may
come
up
with
compose
policy
that
is
roughly
in
the
middle
ground
between
the
two.
So
that's
the
roughly
the
idea.
Of
course,
we
have
a
you
know:
better
definitions
in
our
working
papers,
so
that
may
be.
C
The
more
important
part
is
that
the
2a
aces
should
be
able
to
verify
that
the
fair
competition
and
enforcement
of
their
policies
are
there
and
should
be
really
verifiable
by
the
two
untrusted
aliases.
So
that's
property
number
one
and
the
second
desired
property
is
that
filtering
policy
of
each
AES
must
be
protected
from
each
other
with
some
prop
privacy
guarantees.
The
reason
is
really
simple:
you
know
filtering
policies
are
inherently
sensitive.
C
For
example,
you
know
the
the
Preferences
of
the
filtering
rules
could
be
from
private
contracts
between
aliases
or
propriety,
algorithms
or
the
the
policy
rules
may
leak.
Some
of
the
attack
information,
for
example,
which
is
which
customer
is
actually
under
attack
or
you
know
it
may
leak
some
vulnerable
points
of
them
their
networks
also,
it
may
leak
some
intern
internal,
whitelist
and
blacklist
policies
of
their.
You
know
that
which
they
never
want
to
reveal
to
any
other
AES
in
the
world.
C
Lastly,
you
know
third
desired:
property
is
simply
just
to
make
this
bypassed
attack
impossible,
so,
in
other
words,
sources
may
want
to
evade
this.
This
filtering
policy,
but
we
need
to
have
this.
What
we
call
the
number
pass
ability
property
so
that
any
filtering
operation
must
be
invoked
for
all
packets
from
sources
to
the
destination
a
is
so.
To
that
end,
we
actually
built
a
design
and
build
this
middle
box
based
filtering
mechanism,
and
we
believe
that
this
is
a
really
practical
design:
choice
for
rapid
and
widespread
deployment.
C
So,
in
this
simple
diagram
on
the
left
hand,
side
there's
a
source,
a
is
on
the
right
hand,
side
destination
is
again,
they
are,
you
know,
far
away
from
each
other.
They
don't
trust
each
other,
of
course,
and
our
idea
is
that
we
put
the
middle
box
inside
the
source.
Ies-
and
this
can
be
very
I-
mean
right
next
to
the
egress
router
and
simply
they
it
receives
two
independent
policies
from
the
two
networks,
source
and
destinations
and
the
policies
could
be.
C
You
know
5-tuple
flow
definitions
and
with
some
priorities
it
could
be
some
other
things,
but
as
an
example,
that
could
be
a
policy
and
it
is
composed
into
the
common
policy
and
which
can
be
fit
into
the
classification
and
the
rate
limiters.
So
there
could
be
multiple
rate
limiters
for
each
traffic
classes,
and
so
what,
when
this
middle
box
receives
the
incoming
packets
from
the
source
and
to
the
destination
again,
the
destination
is
under
attack
and
this
nation
is
requesting
some.
You
know
packet,
filtering
and
based
on
this
composed
policy.
C
They
they
block
I
mean
they
drop
some
of
the
packets,
in
other
words
right,
maybe
some
of
the
packets
and
then
the
remaining
packs
will
go
to
the
destinations.
So
it
actually,
we
built
this
everything
with
a
commodity
hardware
and
we
could
achieve
multi
gigabit
per
second
throughput
and
the
two
major
functions.
C
I
mean
control,
plane,
functions
and
data.
Plane
functions
are
protected
within
the
trusted
execution,
environment,
so
trusted
execution,
environment
or
te
e
is
used
because
these
capabilities,
the
memory,
isolation
or
X,
isolated
execution
and
remote
attestation
would
be
really
really
useful
to
offer
security
properties.
For
that,
and
in
one
of
the
the
biggest
one
is
a
verifiable
control
and
data
plane
operations.
So
we
we
show
that
you
know
this
te
based
middle
box,
for
the
application
of
you
know,
collaborative
filtering
can
actually
satisfy
the
three
desired
security
properties.
C
If
you
remember
those
three
I
remind
you,
the
first
one
is
that
you
know
policy.
Competition
and
enforcement
of
the
of
the
two
policies
can
be
actually
isolated
and
verifiable
by
the
two
aliases,
because
every
you
know
you
know
the
executions
of
the
policy,
competition
and
enforcement
are
protected
by
trusted
execution
environment
and
also
this
is
is
now
can
negotiate
the
desired
level
of
privacy.
So,
for
example,
if
the
source
a
is
trying
to
learn
the
composed
policy
PSD
here,
then
he
can
actually
try
to
do
that.
C
We
actually
demonstrated
that
the
attack
is
possible
within
less
than
10
seconds,
but
we
also
found
that
there
is
a
trade-off
between
the
anonymity
and
the
fairness.
Privacy,
and
you
know,
fairness
and
buy-in
by
writing
down
the
exactly
what
level
of
privacy
is
is
required
by
the
two
untrusted
aliases.
We
can
actually
provide
the
desired
level
of
privacy.
C
Also
bypass
can
be
immediately
detected
and
with
a
secure
per
packing
logging
at
the
middle
box.
Also,
this
per
packet
logging
should
be
implemented
within
the
te
e
because
we
need
to
provide
authenticated
really
on
the
logging
information.
This
there's
a
little
bit
of
a
performance
issue
here,
because
in
order
to
do
that,
we
may
need
to
copy
all
the
packets
I
mean
the
line
at
a
line
rate
to
the
trusted
execution
environment.
C
So,
in
order
to
solve
that
problem,
we
we
propose
a
near
zero
copy
technique
that
copies
only
the
five
tuple
information
into
the
TE,
which
can
which
enables
us
to
achieve
multi
gigabit
per
second
performance.
So
we
actually
designed
and
implemented
this
middle
box
using
Intel
SGX
plug-in
in
the
Intel
SGX
platform
so
and
we
could
achieve
a
so
far.
1.8
gigabit
per
second
filtering
performance,
throughput
with
three
Intel
SGX
course,
so
we
actually
have
four,
in
course,
so
there's
a
room
for
improvement,
we're
actually
optimizing
it
and
we
used.
C
You
know
Intel
CPU
memory
and
network
interface
card
there.
They
are
all
you
know.
Commodity
devices
and
tcp
is
about
1.3
k,
source
line
of
code,
and
we
we
integrated
the
SGX
with
DP
DK
for
higher
packet
processing
and
imported
a
couple
of
libraries
to
the
SGX.
So
our
plan
is
to
scale
out
this
thing
with
securely
load,
balanced
load,
balancing
and
the
parallel
middleboxes
for
up
to
10,
G,
10,
gig
or
even
higher
throughput.
C
C
This
is
a
really
the
ideal
form
of
you
know,
defense
for
large-scale
DDoS
attacks,
and
but
there
is
a
challenge
you
know,
AES
is
do
not
trust
each
other
and
the
solution
is
that
we
need
to
really
you
know,
move
from
outsourcing
to
pure
collaboration,
and
in
order
to
achieve
this
collaboration,
we
need
as
one
solution
in
point.
We
proposed
a
te
based
middle
box
which
satisfies
the
three
security
properties,
that
is
verifiable
fairness
and
the
privacy
and
non
bypass
ability.
So
thank
you
for
listening
and
again.
This
is
a
really
an
ongoing
project.
C
E
D
E
F
C
F
Just
one
comment
related
to
the
zero
copy:
I
mean
you
know
sure
you
don't
incur
the
copy
costs
on
all
the
men
copies
and
stuff.
They
still
have
to
send
that
packet
somewhere.
There's
gonna
be
implications
to
the
PCI
bandwidth
of
your
system
and
the
other
interface
that
you
need
to
send
it.
Out
of
so,
you
I'm
not
sure
that
logging,
every
single
packet
that
gets
through
the
filter,
isn't
necessarily
a
good
idea,
because
that
itself
is
an
attack
vector
on
your
middle
box.
C
So
I
understand
you
have
concern
about
this
per
packet
logging
and
you
know
zero
copy
stuff.
So
yes,
exactly
that,
that's
really
the
the
biggest
part
of
our
performance
issue
and
then
we
try
to
minimize
that
using
near
zero
copy,
meaning
that
we
try
not
to
copy
anything
but
5-tuple
information,
and
we
believe
that
you
know
5-tuple
information
is
actually
necessary.
We
need
to
you
know
cop,
that
into
as
SGX
in
this
case,
because
we
need
to
really
detect
the
bypass
attack
and
that's
the
only
way
as
for
as
far
as
I
know,
thanks.
G
G
Don't
know
can't
go
more,
thank
you
for
the
presentation,
I'm
trying
to
understand,
get
my
head
around
a
couple
pieces
that
that
seemed
to
be
missing
to
me.
So
one
of
one
thing
is
that
the
bypass
ability
that
you
described,
if
the
only
input
to
the
trusted
execution
environment,
is
the
five
tuple
and
then
the
only
output
is
a
approve
or
disapprove
of
the
five
tuple.
Then,
how
does
that
produce
non-bio
possibility
right
so
I
I
learned
from
my
team
IDE
that
I'm
supposed
to
drop
this
on
the
floor,
but
I
don't
right.
G
So
how
is
it
not
by
passable?
It
seems
it
seems
eminently
by
passable
to
me,
because
the
actual
sending
of
the
packet
is
not,
of
course,
within
the
TE.
My
second
question
has
to
do
what
you
or
I
don't
know.
If
you
want
to
get
feedback
for
that,
or
my
second
question
has
to
do
with
you've
presented
this
in
a
in
a
two-party
scenario:
you
have
one
source,
a
s
and
one
destination
is
and
I'm
wondering
what
the
state
of
the
work
is
for
dealing
with.
G
C
C
But
our
goal
here
is
to
detect
the
bypass
between
different
cross,
the
traffic
definitions
or
traffic
classes,
so
in
other
words,
maybe
I
missed
that
we
skip
that
part,
but
the
our
middle
box
in
securely
logging,
all
the
packet
counts
per
traffic
class
and
the
destination
should
be,
should
be
counting
the
same
thing
per
packet
per
traffic
class
and
they
compare
at
the
you
know
infrequently.
So
if
some
packets
are
missing
where
some
packets
are
injected
within
the
package
class
traffic
class,
then
that
can
be
detected.
C
G
G
C
So
what
do
you
do?
So
if
you
detect
it,
then,
since
this
is
a
bilateral
relationship
only
only
between
the
source
and
destination,
so
if
destination
clearly
knows
that
source
is
trying
to
bypass
it,
then
their
temporal
contract
is
over
the
this.
This
collaboration
is
just
over
aborted,
so
that's
we,
we
believe
you
know.
Detection
might
be
sufficient,
because
it's
just
just
between
the
two,
a
ESS,
okay
yeah,
it's
something
we
knew
we
had
to
make.
You
know
this
design
point
is.
G
H
C
C
A
I
Is
Linda
Dunbar
I'm,
the
chair
of
the
working
group
interface
to
network
security
function,
which
is
to
standardize
the
policy
like
a
filtering
policy
and
in
our
working
group
we
have
a
domain
like
a
controller
and
then
the
function
so
there's
a
relationship,
but
for
your
case
I'm
just
curious
like
do
you
have
a
controller
to
consent,
the
policy
or
you
are
depending
on
just
between
a
STS
and
the
policies.
So.
C
I
Part
o
the
working
group
is
to
define
and
standardize
the
data
model
between
two
peers,
like
between
you
and
me.
I
want
you
to
filter
a
certain
packet,
so
we
standardize
those
kind
of
policies.
So
my
question
to
you
is,
as
earlier
person
were
asking,
do
you
have
kind
of
a
hierarchical
way
like
I,
have
a
controller
to
tell
all
the
Aces
of
the
policies
or
is
it
purely
distributed?
So.
C
I
C
J
E
J
C
That's
right,
the
mood
of
trust
about
the
operation
I
mean
the
execution
of
this
fairness,
and
the
enforcement
of
the
fare
policy
is
comes
from
the
manufacturer
in
this
case,
in
cell
in
case
of
Intel
SGX.
It's
it's
yeah.
If
you
use
te,
is
there
something
you
need
to
assume?
Yes,
vanadium,
soonest,
III.
K
Can't
I'm,
sorry
to
say,
I
can
see
this
working
ever
ever
ever
and
ever
BGP
is
not
technology,
baby
piece
politics
right,
so
you
people
setting
their
policies.
People
are
making
money
on
on
often
DDoS
attacks
too.
So
I
don't
see
anyone
using
a
box
like
this,
because
you
won't
put
your
trust
in
someone
else
and
and
and
again
back
verifying
who
are
using
it
and
who
are
not
using
it
III.
K
C
K
A
K
K
K
C
L
K
C
C
You
know
the
destination
would
determine
which
packet
should
be
dropped
or
not,
and
now
it
enables
the
so
CAS
or
CAS
to
express
certain
level
of
policy
and,
at
the
same
time,
the
destination
AES
will
benefit
from
from
this
mechanism
because
it
can
sort
of
outsource
the
the
packet
processing
to
the
source.
A
is
so
so
I
mean
my
argument
is
this
is
a
win-win
situation.
A
N
O
Hi
I'm
Jim
Fenton
I've
been
reviewing
a
few
internet
drafts.
Lately
that
have
some
thing.
The
security
considerations
aren't
quite
what
I
would
like
them
to
be.
In
particular,
people
seem
to
be
putting
a
lot
of
normative
content
there
and
I'm
concerned
that
having
it
there
in
security
considerations,
which
I
consider
to
be
more
of
a
discussion
of
the
characteristics
of
what
was
said
earlier
is
is
kind
of
the
wrong
place
and
people
implementers
are
likely
to
miss
content.
That's
there.
O
A
You
should
ask:
we've
tried
so
so
there's
a
few
things
to
respond
to
there.
There
is
no
strict
guidance
on
how
we
structure
the
security
consideration
sections.
There
have
been
experiments
where
people
have
done
a
security
requirement
section
and
a
security
consideration.
Section
I
haven't
seen
one
of
those
in
a
while
and
that's
a
case
where
you
would
separate
out
any
musts
you
didn't
have
before
and
put
them
in.
So
no,
we
don't
have
any
strict
guidance
on
that.
If
you
do
see,
problems
in
you
can
think
you
could
clarify
documents.
A
You
know,
so
your
reviews
are
much
appreciated
to
get
to
a
revision
of
three
five
five.
Two.
We
need
feedback
right,
so
we
yo
have
had
graciously
volunteered.
He
had
brought
up.
He
had
done
a
presentation
with
a
prior
volunteer.
I
think
I
want
to
say
it
was
like
Berlin
that
might
have
been
one
of
the
meetings,
but
he
got
up
here
and
we
gave
overviews
at
several
meetings
several
sag
meetings.
He
requested
feedback
at
the
mic.
We
had
discussions
on
it
even
just
two
meetings
ago
asking
for
feedback.
O
A
You
and
you
could
just
post
if
anyone's
interested
post
to
the
SAG
list,
we'll
see
if,
if
there
is
enough
interest
and
if
there
is
we'll,
go
forward
with
it,
it
would
be
a
good
thing
to
do
anything
else.
Okay,
so
now
we
will
switch
over
to
sect
dispatch
and
if
you
have
feedback
from
the
sect
dispatch
experiment,
please
send
that
to
ekor
I
on
the
chairs,
Tim
and
Nancy.
E
Q
Yeah,
well,
we
we
are.
We
are
really
organized
trust
me
so
welcome
to
the
experimental
security
dispatch.
So
we
are
trying
this
for
the
first
time
so
bear
with
us
real,
quick
I'm
not
going
to
go
through
the
note.
Well,
hopefully,
you've
been
through
enough
sessions.
You
know
what
it
means,
what
I
want
to
say
first
and
why
I'm
circulating
two
cards
is
originally
we
had
slated
for
US
House
Lee
to
be
my
co-chair.
Unfortunately,
he
was
taken
ill.
Q
The
good
news
is,
he
is
out
of
surgery,
so
we
want
to
wish
him
well
we're
circulating
to
get
well
card,
so
please
feel
free
to
sign
them,
but
please
make
sure
I
get
them
back
at
the
end
of
the
session,
so
very
important,
so
he
gets
it
and
I
do
want
to
thank
Tim
for
stepping
in
at
the
12th
hour.
Really
so
with
that,
given
the
experimental
nature
of
this,
what
we're
doing
is
we're
mimicking
the
process
that
is
being
done
by
the
arc
dispatch.
Q
So
that
said,
we're
here
really
to
help,
as
the
group
is,
namely
apt
to
dispatch
the
work.
So,
given
the
full
agenda,
and
typically
in
the
art
dispatch,
the
presentations
are
given
about
ten
minutes
really
more
like
five
to
seven
minutes
for
them
to
present
we
discuss,
and
then
we
ask
the
question
to
you
whether
it
is
something
that
the
IETF
should
do.
If
it
is,
we
get
to
discuss
whether
there's
a
home
within
the
IETF
and
if
there
is
great
we'll
make
sure
that
those
chairs
are
aware.
Q
If
not,
then
we
ask
the
for
the
question
as
to
whether
we
should
form
a
new
working
group
or
whether
we
should
ask
one
of
our
security
area
directors
to
sponsor.
So
hopefully
there
are
no
questions,
but
maybe
we'll
we'll
say
one
minute.
If
there's
any
questions
clarifications
quickly,
going
once
going
twice,
good,
we've
got
a
full
agenda
so
with
that
with
that,
we've
got
five
presentations
and
if
time
allows
there's
potential
for
61.
Q
R
Everyone
well,
first
of
all,
I'd
like
to
wish
rust
speedy
recovery
because
he's
the
one
who
first
contacted
me
about
this,
and
thank
you
to
the
sac
chairs
and
thank
you
for
Nancy
and
Tim
for
hosting
this
session
today.
I'm
here
I
know,
I
only
have
five,
maybe
or
seven
minutes,
but
I'll
go
through
it
really
fast.
So
today,
this
presentation
is
about
an
open
GP
extension
for
the
OS
CCA
algorithms.
So
if
we
can
go
to
the
next
page,
I'll
explain
to
you
what
OS
CCA
is
so
in
China.
R
Our
extension
extends
openpgp
to
allow
these
three
algorithms
to
exist
in
the
protocol,
so
people
in
China
could
use
encrypted
emails
through
open
PGP.
So
this
draft
defines
the
usage
of
these
three
algorithms
within
open,
BGP
and
also
an
additional
profile
on
just
like
the
NSA's
be
sweet.
We
call
it
the
Oscar
SM
2
3
4
as
a
profile
for
open
BGP
usage.
R
The
first
would
like
to
explain
is
the
sm2?
It's
an
elliptic
curve
cryptography
and
the
standards
that
were
just
published
and
actually
just
went
active
earlier
this
year
in
March.
This
is
the
family
or
standard
called
the
gbt
three
to
nine
one,
eight
from
part,
one
to
part
five
different
parts
of
this
standard
define
different
parts
of
this
algorithm.
So
this
is
an
ECC
that
contains
three
separate
algorithms.
It's
a
digital
signature,
algorithm,
a
key
exchange
protocol
and
also
a
public
key
exchange.
Sorry,
a
public
key
encryption
algorithm.
R
The
last
part
part
five
defines
the
sm2
curve
that
is
recommended.
So
the
sm2
algorithm
uses
a
5-1
two-bit
public
key,
a
256
bit
private
key
for
more
details
of
the
algorithm.
You
could
have
a
look
at
this
draft
traction
sm2,
blah
a
short
history
of
this
algorithm.
It
was
first
published
in
2010.
It
was
standardized
as
a
commercial
cipher
in
China
in
2012
it
was
included
in
an
ISO
standard,
2015,
formally
standardised
as
a
national
standard
in
2016
and
this
year.
R
R
R
R
R
It's
a
brief
history
is
that
it
was
first
published
again
in
2010
standardized
in
2012,
published
as
a
national
standard
in
2016
and
this
year
again,
just
a
couple
months
ago,
it's
now
included
as
an
international
standard
in
open
PGP.
We
use
it
as
one
of
the
registered
hash
algorithms,
so
sm-3
could
be
used
together
with
other
public
key
algorithms,
such
as
RSA,
sm2
and
so
forth.
R
The
next
slide
will
give
us
M
4,
which
is
a
128-bit
block
cipher.
It
uses
an
8-bit
Xbox
with
32
rounds
of
processing
for
more
information.
You
can
look
at
this
draft
at
the
second
point.
The
sm4
algorithm
goes
back
to
2003,
where
it
was
standardized
in
this
GB
standard
for
wireless
LAN.
It
was
designed
for
wireless
LAN
encryption
and
therefore
it's
a
short
block.
Cipher
that
is
has
supposed
to
have
excellent
relied.
R
Realizability
in
in
simple
hardware,
so
it
was
published
in
2006
as
by
the
Oscar
standardized
in
2012,
published
in
2016
as
a
national
standard
and
2017
a
couple
months
ago
it
was
added
into
ISO
one
eight
zero,
three
three,
which
is
a
document
for
block
ciphers
in
open
PGP.
We
use
it
as
a
selectable
symmetric
encryption
algorithm
as
an
alternative
to
AES
128,
and
the
last
I
would
like
to
show
you
is
that
SM
2s
and
3s
m4.
R
The
implementations
are
already
provided
in
Bolton
in
open
SSL
support
in
MPLS
&
Liber
SSL
is
coming
when
number
of
processes
today
already
implement
sm-3
and
SM
for
including
Intel
chipsets
and
upcoming.
The
arm
v8
course
our
own.
We
we
have
our
own
implementation
of
open,
PGP
called
our
NP.
We
already
support
all
these
algorithms
and
in
terms
of
Kahn
security
considerations.
There
are
no
feasible
attacks
against
SM,
SN,
3
and
SM.
R
For
today
for
more
details,
you
could
have
a
look
at
the
IETF
drafts
so
proposing
to
move
forward
this
document,
given
that
the
open
PGP
workgroup
has
recently
encountered
some
turmoil,
we
would
need
security
area
director
for
sponsorship.
We
would
like
to
request
three
extra
whole
points
in
the
Ayana
PGP
registry,
which
is
listed
here
for
the
document.
We
would
like
to
add
more
examples,
and
we
would
be
very
happy
if
anybody
could
provide
some
constructive
feedback
and
reviews
of
the
documents.
Thank
you
very
much.
P
Thank
you
Ron
just
add
a
little
bit
to
that.
So
to
actually
use
those
algorithms
with
open
PGP
will
require
those
code
points
being
assigned.
Those
code
points
have
to
be
assigned
under
IETF
review.
Yes,
Ron
already
did
some
of
it
did
get
half
the
you
know
did
ran
the
algorithm
open
PGP
would
have
been
the
obvious
home
for
this
work.
It's
closed.
I,
don't
see
a
new
working
group
opening.
So
the
question
is
really
whether
this
work
is
important
enough
to
move
forward
under
AG
review.
G
You
hi
this
is
Daniel
con
Gilmore
xi2,
chair
of
the
HP
working
group.
Thank
you
for
bringing
this
up
so
I'm
sort
of
curious
about
why
you're
proposing
it
now
when
it
looks
like
these
things
of
around
for
several
years,
I
was
looking
at
the
looking
at
the
drafts.
There's
a
there's,
a
sort
of
strange
chain
of
when
the
drafts
were
formed.
This
would
have
been
a
good
thing
to
mention,
probably
in
the
open,
BG
working
group
when
it
was
open,
so
I'm
sort
of
curious
about.
Why,
like.
Why
is
that
like?
R
So
I
was
actually
previously
in
contact
with
Barry,
and
he
suggested
to
me
that
the
open
PGP
working
group
was
only
going
to
deal
with
the
revision
of
four
eight
eight
zero
and
right.
G
E
R
R
I
was
specifically
referred
to
this
draft
when
I
talked
to
Barry
and
Barry
suggested
that
I
contact
the
security
area
directors
directly
rather
than
going
to
the
group,
because
the
group's
the
Charter
of
it
was
specifically
just
to
revise
for
a
dado.
For
you
know
what
were
problems
people
had
with
it,
so
we
suggested
that
we'd
bring
this
directly
to
the
area
directors
to
not
disturb
the
work
of
the
group.
Okay,.
S
Hi
Sean
Turner
I'm,
probably
not
getting
nearly
as
entertaining
as
deg.
Why
we're?
Here,
though,
right
is
because
the
Ayana
registries
are
set
up
as
IETF
reviews,
so
you
can't
get
a
crook.
You
can't
get
a
co
point
unless
you
get
Haiti
sponsorship.
So
another
solution
to
this
is
to
update
the
registries.
To
allow
other
specification
types,
then
you
can
get
a
registration
and
go
either
through
an
area
director
or
to
the
ISC.
It's
your
call,
but
that's
a
different.
S
R
M
Stephan
Pires
just
to
come,
actually
me
not
constructive,
sorry
and
so
I
I
think.
Having
specifically
supporting
sweet
beer
was
a
mistake,
I
think
adding
other
national
algorithms
would
be
a
mistake.
I
don't
think
we
should
do
any
of
that.
If
we
want
new
algorithms,
it
should
be
because
they're
better,
not
because
they're
you
know
come
on
to
some
geography.
T
T
U
Sean
Leonard
and
anger
Inc,
just
for
my
edification
as
well
as
I,
was
in
the
group.
What
is
the
status
of
implementation
as
well
as
specification
in
the
asn.1?
You
know
s/mime
CMS
certificate
realm,
because,
unlike
the
registry
issue,
that
we
have
with
open
PGP
where
it
requires
IETF
review,
you
or
you
know,
whoever
can
just
assign
an
OID
and
by
agreement
start
using
it
right
so,
but
I
don't
I.
Could
you
address
that
all
right.
R
So
open
PGP
doesn't,
unfortunately,
it
doesn't
directly
utilize
all
IDs
in
the
selection
of
algorithms.
R
It
was
like
that
for
I
guess
a
long
time
so
I
it
boils
down
back
to
you,
know
the
the
Co
coin
registry
issue
that
you
know
for
open
PGP
to
work
with
these
algorithms.
It
is
necessary
to
update
that
without
actually
changing
the
protocol
for
the
SM
algorithms
sm2,
specifically,
is
actually
already
used
in
the
certificate
standards.
However,
those
are
standards
within
China,
so
those
are
only
national
standards
that
apply
SM
2
and
the
usage
of
SM
3
as
a
hash
algorithm
within,
for
example,
SSL
Certificates,
so
that
is
already
in
use.
R
I
would
say
you
know
it
would
definitely
be
beneficial
if
there's
actually
an
official
specification
that
is
at
the
ITF
I
think
that
would
be
very
helpful.
At
least
you
know
for
the
IETF
community.
So
I
would
like
to
answer
one
more
question
about.
You
know
why
this
is
the.
Why
do
we
propose
this
now?
Is
that
because
SM
to
sn3
and
SM
for
has
just
been
standardized,
they
actually
just
became
active
earlier
this
year
and
in
fact
the
SM
to
curve
is
not
yet
active,
it
will
be
active
in
early
2008.
U
Yeah
from
my
perspective,
I
think
that
it
I,
don't
my
personal
view-
is
I,
don't
see
it
as
harmful
to
have
more
definitions
of
cryptographic,
algorithms
and
using
them,
because
I
believe
in
cryptographic.
Diversity,
in
contrast
to
some
of
my
colleagues
wherever
basic
I,
don't
believe
in
the
Sith
rule
of
to
a
sequence,
algorithm
I,
think
more,
defining
more
is
better
choosing
whether
to
use
them
is
a
very
important
issue,
but
that's
sort
of
orthogonal
together.
That's.
G
R
So
SM
2
3
4
are
cryptographic
algorithms.
So
what
that
point
meant
was
just
that
these
algorithms
are
already
available
if
any
implement
I
wanted
to
use
them.
So
in
terms
of
implementation
of
this,
our
own
of
them
called
RNP,
which
you
could
find
on
github,
it's
an
open
source
project.
It
already
supports
the
usage
of
SM
to
SM,
3
and
SM
for
in
open
PGP.
So
right
now
we
utilize
experimental
code
points.
But
if
you
know
we
get
to
get
a
registry
to
insert
our
code
points,
then
there
would
be
already
a
standardized
implementation.
G
G
G
R
G
Q
Okay,
so,
based
on
the
comments
and
discussion,
it
feels
like
there's
a
couple
of
paths
as
Shaun
suggested
and
I
can
remember.
Oh
there's
three
okay
yeah,
so
the
first
one
is
we.
We
don't
need
to
do
anything
here
or
we
don't
want
to
do
anything
here.
The
second
one
is
as
proposed
here
we
find
an
ad
to
sponsor
I,
don't
know
where
Eric
went
well,
Kathleen's
on
her
way
out
so,
and
the
third
option
is
suggested
by
Sean.
We
really
don't
need
to
go
through
the
draft.
Q
D
Q
P
B
Think
is
before
yourself,
but
I'm
not
gonna,
even
sponsor
a
document
that
as
a
Co
point
for
this
I'm,
not
gonna
ad,
sponsor
or
docx.
You
ate
that
it's
a
Co
point
for
this,
because
I
think
that
having
it
is
the
precise
purpose
of
lighting
the
precise
purpose
of
like
having
sex
dispatch
was
not
to
have
a
bunch
of
algorithm.
B
They
had
a
good
RFC,
so
we
could
8380
spots
of
them,
so
they
could
have
Co
point
assignments,
so
I'm
happy
to
have
I
wouldI,
sponsor
that
the
things
I
won
suggested,
which
is
loosing
the
registry
and
and
then
they
can
do
whatever
they
want
less
tedious
parts.
That's
her
choice
but
I'm
not
a
any
sponsor
like
a
draft
that
does
there's
basically
a
document.
Is
it
solely
for
a
co-payment,
so
don't
as
useful.
So.
P
Do
people
think
that
we
should
pursue
that
doesn't
mean
we
will
actually
do
it.
We
would
pursue
a
change
to
the
I
Ana
review
policy
for
open
PGP
so
that
future
algorithms
can
be
done
without
being
something
that
has
to
be
done
through
the
group.
I
think
we
we
should
do
a
hum
on
that.
We
were
out
of
time.
So,
let's
start
with
that,
how
many
people
think
that
that
is
I'm.
Sorry,
sir,
the.
W
Community
one
comment
actually
there's
a
curtal
working
group
that
is
working
on
adding
things
and
so
on,
and
it
doesn't
list
a
PGP
open
PGP
because
of
an
PGP
working
group
or
other
live
at
that
point.
But
it's
not
anymore.
So
actually,
we
could
add.
Add
this
to
curdle
charter.
That's
something
that
ladies,
could
tend
to
charge
tariff
to
curdle
were
contributing.
P
X
Kate
it
could
go
to
curdle
I
think,
but
the
thing
it
doesn't
solve
the
long-term
problem:
okay,
which
is
a
pretty.
Y
P
Three
options:
the
number
one
option
is
that
we
would
do
nothing
where
the
documents
is
something
we
don't
want
to
pursue
the
number
two
option.
These
are
not
in
order.
These
are
just
the
three.
The
second
one
would
be.
We
revised
the
IANA
policy
for
open
PGP,
and
the
third
is
that
we
asked
Ron
to
take
this
to
curdle
and
see
whether
curdle
is
willing
to
take
it
on
as
a
working
group
item
before
that
I'm
channeling
PHP.
G
G
So
the
registries
I
believe
that
we're
talking
about
are
one
octet
registries
right
and
we're
talking
about
changing
the
Ayana
registration
policy
for
a1
octet
registry
that
currently
is
set
up
with,
depending
on
which
one
there's
between
ten
and
twenty
ten
and
twenty
four
points
assigned
out
of
the
two
hundred
to
six,
with
a
range
of
ten
reserved
for
private
experimental
and
nothing
explicitly
assigned
above
128.
So
we're
talking
about
changing
IANA
registration
policies
for
relatively
small
registries.
G
P
You
that
is
a
really
great
clarification.
Thank
you
for
pointing
that
out
with
that
we're
gonna
still
back
to
the
three
hums,
which
is
don't
think
the
IETF
should
pursue.
This
number
two
would
be
change
the
IANA
policy,
in
spite
of
it
being
a
scarce
resource
and
the
third
one
is
asked
Ron
to
first
confer
with
CFR
G
and
then
take
it
to
curdle.
P
P
Okay,
how
many
people
think
that
the
Ayana
policy
should
be
revised
so
that
I
hf
review
is
not,
is
no
longer
required
for
the
open,
PGP
registries
a
little
more?
How
many
people
think
that
it
should
go
to
that?
Ron
should
take
this
to
see
FRG
and
then
request,
assuming
that
goes
well
request
that
the
kernel
group
take
this
on.
P
Well,
well,
we
we
will
continue
that
the
discussion
of
number
two
but
I
think
number
three
was
clear
enough
to
say
Ron,
that
what
we
would
like
to
do
is
because
there
aren't
any
other
SM
series
algorithms,
you'd
use
in
now
in
the
IETF
we're
sending
those
to
the
C
FRG.
If
the
C
FRG
is
comfortable,
which
I
would
you
know,
then
then
you
would
take
this
to
the
kernel
group
to
see
whether
or
not
this
is
something
you
want
to
move
forward
right.
R
I
just
like
to
make
a
clarification
that
it's
not
only
the
requestion
of
the
requesting.
The
col
point
is
that
the
the
algorithms
inside
there
are
some
specific
things
that
need
to
be
done
to
use
SM
two
three
and
four
in
that
is
documented
in
the
document.
So
it's
more
than
just
a
a
call
request,
but
echo
my
request
is
necessary
right.
R
B
R
AB
X
Well,
the
client
establish
a
chalice
session
with
an
attacker
except
of
the
GLS
legitimate
server,
so
both
the
client
and
the
server
our
victim
of
this
attack
and
most
of
the
times
they
don't
even
notice.
They
have
been
a
victim
on
that
next
slide.
So
what
we
propose
is
a
an
extension
for
a
TLS
1.3,
which
is
a
second
factor
authentication,
so
basically
what
it's
it's
a
trust
on.
First
use
mechanisms,
and
basically
what
we
do
is
that
when
we
you're
connected
to
a
server,
so
let's
say
dot
example.com,
you
want
to
be
sure
you.
X
We
want
to
check
that
the
identity
of
that
server
is
the
same
as
when
you
you
were
doing
a
session
with
that
server
previously,
so
it
didn't
change
the
identity
so
next
slide.
So
how
does
it
work?
So
that's
the
first
session.
You
have
nothing
so
you
you
have
performed
your
TLS
handshake.
So
that's
why
it's.
The
10th
occasion
has
been
done
and
what
you're
asking
for
from
the
server
is
a
ticket
and
the
ticket
is
basically
an
encrypted
secret
based
on
the
TLS
handshake.
X
X
Sorry,
that's
the
first
exchange,
so
you
just
get
a
secret
now,
okay,
so
we
can
go
to
the
second
step
so
that
how
you
get
a
ticket
and
basically
you
are
able
to
generate
what
we
call
the
defining
secret
from
the
TLS
exchange
and
you
have
a
ticket
from
the
server.
So
the
next
session
next
slide
when
you're
you
perform
the
TLS
exchange,
and
what
you
want
to
make
sure
is
that
the
server
you
you
are
actually
connected
to
is
the
same
as
you've
been
connected
previously.
X
So
once
you
have
that
proof
the
other
side,
the
client
can
also
generate
that
proof
and
you
can
checks
that
the
proof
sent
by
the
server
corresponds
to
the
proof
it
has
locally
generated
and
because
you
have
a
binding
between
the
secrets
and
you
can
make
sure
that
the
server
is
able
to
decrypt
the
secrets
and
has
the
same
and
situations
as
you
have.
So.
Basically,
that's
the
same
server
you're
connected
to
now,
as
previously.
X
P
X
So
HP
KP,
the
main
difference,
is
that
it's
a
second
factor,
so
we
did
not
h.
P
KP
can
be
seen
as
a
you
use
HTTP
as
a
side
channel
to
configure
the
TLS
authentication
began
terms,
but
just
by
saying
this
is
this.
So
if
you
get
that
has
to
be
used
for
the
TLS
authentications,
we
do
not
use
that.
We
use
a
second
factor,
which
means
it's
a
it's
not
associated
it
does
not.
It
does
not
have
any
impact
to
the
TLS
authentication.
X
The
second
difference
is
that
it's
a
TLS
extension,
so
it's
not
only
for
HTTP
over
TLS
and
well
because
it's
a
second
factor.
We
have
absolutely
no
impact
when
you
change
your
key
for
the
TLS
authentication,
so
because
a
lot
of
the
difficulties
for
HP
KP
camps
from
that
you
were
actually
bind
to
the
key
used
for
the
ETLs
authentications.
So
we
removed
that
change
and
that's
a
well.
We
believe
that,
well,
you
don't
have
backup
key
also
to
handle,
so
we
we
think,
that's
it's.
X
P
At
this
point,
we
need
to
go
to
the
mic
and
I
want
to
remind
people
that
what
the
decision
that
we're
making
here
is
and
strictly
on
the
bits
and
the
bytes
up
level
it.
This
is
a
is
this
work,
something
that
we
need
to
be
pursuing
in
the
IETF,
and
if
so,
then
we
have
to
figure
out
where
the
right
home,
for
it
is
so.
Okay,
I
think.
J
X
J
G
This
is
dkg.
You
asked
for
questions
on
the
mechanism
and
I
actually
on
policy,
so
I
hope
that's
okay,
yeah,
but
I'm
curious
as
to
what
you
think
the
client
should
do
if
the
server
does
not
produce
the
new
pinning
proof.
So
what
what
do
you
expect
to
happen
on
the
client-side
if
the
new
pinning
proof
is,
for
whatever
reason
doesn't.
X
G
G
That's
so
so
I
think
one
of
the
things
that
made
it
difficult
for
people
to
adopt
pkp
is
that
there
was
no
document
that
provided
guidance
on
or
and
no
implementations
that
provided
some
simple
implementations
of
key
rotation
schedules
and
how
you
couple
that
with
pkp
headers
right
the
way,
the
way
that
we
could
have
gotten
pkp
to
work
better
would
be
to
say
here
is
a
standard
policy
that
you
can
adopt
for
your
server,
and
here
are
a
couple
of
implementations
that
implement
that
policy.
Yeah.
X
G
X
G
E
G
You've
added
a
new
secret
to
my
store
right
now.
I
have
to
protect
that
secret.
If
I
lose
it
I
cause
hard
fail
on
all
of
the
clients
who
visited
me
in
the
past.
Right,
yeah
and
and
I
need
to
have
some
policy
for
if
I
accidentally,
so
I
have
two
ways:
I
can
lose
it.
One
is
I
can
lose
track
of
the
bit
so
I,
don't
know
it
anymore
and
the
other
is
I.
Can
accidentally
publish
it
right
yeah.
P
G
S
S
S
And
you
need
a
go
point
and
that
Co
point
is
still
the
whole
standard
track
thing.
We're
changing
that.
So
in
TLS
we
said
we're
gonna
check,
we're
gonna,
open
up
the
cipher
suite
or
the
registry
for
extensions
to
be
spec
required.
So
once
we've
done
that
in
the
next
two
weeks
month
or
whatever
it'll
be
available
for
you
to
take,
this
will
draft
to
the
ISE
and
get
a
Co
point.
S
P
T
Q
T
Richard
Richard,
Barnes
and
I
guess
since
I'm
the
last
in
line
I'll,
take
the
privilege
of
proposing
resolution
here,
I
think
we
following
kind
of
following
where
the
direction
Sean
was
but
I,
think
we
should
not
do
any
work
on
this
I
think
it's
something
that
can
clearly
be
done
outside
the
IETF
process,
with
the
new
registration
policies
and
I
think
it
actually
is
pointed
in
a
direction
that
is
not
really
direction.
At
least
the
web.
T
That's
headed,
hpk
P
support
is
being
rolled
back
in
a
bunch
of
browsers
now,
and
so
because
people
had
exactly
the
problems.
The
dkq
is
mentioning
and
deployability,
so
I
don't
think
there's
really.
This
is
really
something
it
is
in
tune
with
what
I
understand
to
be
the
direction
that
the
internet
is
headed
and
if
there's
alternative
channels
for
realizing
so
I,
don't
think
the
IETF
needs
to
do
any
work
for
it.
So.
P
I
think
that's
straightforward,
that
from
what
what
you
and
Sean
have
said,
it's
going
to
become
specification
review,
which
will
which
will
allow
you
to
get
the
code
point
that
you
need,
and
there
probably
is
not
interest
in
the
right
working
group
to
pursue
it.
So
we
really
suggest
that
that
be
how
you
prove
a
percent
or
proceed
or
yeah
yeah
as
independent
submission.
It
is
there
anybody
who
thinks
that
that's
a
bad
summary
hum
now.
T
B
Right
yeah
so
I
mean
so
the
point,
the
point
of
the
of
the
complaint
reassignments
in
TLS
right
or
to
avoid
having
to
make
decisions
on
documents.
If
you
look
for
any
Co
point
assignments
and
we're
I,
don't
have
any
position
on
the
event
submission.
It's
like.
Don't
do
it
here.
This
is
how
you
get
a
core
points
out
of
it.
M
P
Q
AD
E
AD
AD
Okay,
so
the
general
problem
we're
trying
to
solve
here
is
system
level
randomness
failures,
if
you
think
back
to
the
Debian
bug
and
other
sort
of
things
where
the
system
itself
can't
seed,
the
pseudo-random
number
generator
with
an
unpredictable
data.
This
can
happen
on
different
operating
systems
and
can
end
up
impacting
quite
a
lot
of
implementations
of
protocols,
especially
in
the
case
of
ephemeral,
tiffin,
where
keys
are
generated
on
the
fly
or
for
connections.
AD
AD
There
have
been
general
solutions
proposed
to
this
sort
of
issue
before
the
idea
is
to
take
a
long
term
secret.
That's
specific
to
this,
the
application
or
the
connection
and
mix
that
in
with
the
randomness,
this
is
specifically
presented
as
the
Naxals
trip
in
a
paper
by
LaMacchia,
Lauder
and
Michigan.
AD
The
idea
is,
you
have
the
private
key.
This
is
a
long-term
secret
in
TLS,
for
example.
This
could
be
the
private
key
of
your
certificate.
You
can
hash
this
into
the
RNG
pool.
So
if
there's
a
systemic
failure
on
your
operating
system,
at
least
your
connection
will
not
will
have
the
entropy
of
the
secret
key
mix
into
it.
The
issue
with
this
is
that
sometimes
the
private
key
is
not
available,
whether
it's
in
an
HSM
or
or
other
other
places.
AD
The
proposed
solution
here
is
very
simple:
is
given
a
long-term
asymmetric
key
you
sign
or
encrypt
a
static
value
with
this
long-term
key
and
then
mix
that
result
into
the
random
number
generator
before
using
it
for
generating
ephemeral,
diffie-hellman
key.
We
have
an
example
of
how
to
do
this
in
the
TLS
draft
and
a
formal
security
proof
that
came
along
with
this
from
my
co-authors.
M
Steam
power,
yeah
I,
think
it's
a
good
idea
for
somewhere
I
mean
III
would
ideally
like
to
see
somebody
update,
40
86,
but
I.
You
know
I
can't
force
you
to
do
more
work
than
you're
willing
to
do
so.
If,
if
you're
not
happy
to
update
40
80
we're
a
bit
divided,
if
you're
not
and
I
think
doing
this
somewhere
will
be
fine
and
it
could
be
eight
I.
AE
AD
Should
work
with
either
deterministic
or
randomly
generated
signatures,
the
only
the
important
part
is
that
the
resulting
value
is
signed
by
something
that
is
an
unpredictable
long
term
secret
and,
for
example,
if
you
were
to
in
in
TLS,
if
you
have
an
RSA
key,
you
can
assign
a
value
to
terminus
tically
with
ECDSA.
You
can
sign
non-deterministically.
AD
The
signature
itself
is
not
predictable,
which
is
the
important
part,
and
you
can
take
this
signature
and
sort
of
share
it
along.
You.
Don't
have
to
actually
do
this
for
every
single
connection.
You
can
kind
of
do
it
once
per
long-term
secret
as
long
as
that
piece
of
those
bits
are
fed
into
the
RNG
everywhere,
you
should
have
protection
from
this
systematic
failure.
AD
B
And
if
this
is
a
subtle
question,
which
I
think
under
the
editorship
and
I
would
for
a
double
check,
avi,
as
you
know,
on
ECDSA
in
non
deterministic
mode
requires
a
random
K
and
having
a
non
random.
K
is
bad.
So
if
you
have
a
so
now
we
have
it,
we
have
a
chicken-egg
problem.
If
we
have
a
weak
PNG
that
we
use
to
generate
the
k,
is
that
caused
a
problem
or
is
the
fact
that's
being?
B
AD
AF
Curious,
have
you
done
any
testing
on
this
a
Linux
system
orangie
and
see
what
kind
of
results
you
get
from
from
the
resulting
entropy
after
you
sort
of
cold
start
it
sir?
Can
you
written?
Can
you
repeat
which
one
so
did
you
try
this
out
would
say
the
Linux
system
or
in
you
and
say,
comb
started
it
and
just
edit
this
and
see
where
you?
How
much
entropy
did
you
actually
wind
up,
but
it's
very
difficult
to
measure
entropy
well,.
AD
AD
Can
do
statistically
if
the
system
RNG
is
is
random.
This
will
be
random
as
well.
Any
any
public,
key
signature
or
encryption
algorithm
of
a
static
value
will
imbue
upon
the
results
as
much
entropy,
as
is
the
key
length
or
the
key
strength,
and
if
not,
then
that
signature,
algorithm
or
encryption
algorithm
is
is
weak
right.
AF
AF
AG
P
I
mean
there
is
no
code
point
or
anything
that
he's
needed.
So
there's
no
reason
who
couldn't
go
through
the
CFR,
G
and
I
think
we're
having
enough
questions
that
it
might
be
something
that
just
going
through
CFR
G
would
actually
make
people
feel
more
comfortable
about
using
it
as
well.
So
that
would
be
certainly
an
option
there.
Did
you
actually
consider
that,
or
is
that
yeah.
AD
P
T
Yeah
personally,
I
think
this
is,
it
does
seem
to
be
like
a
little
higher
level
up.
The
stack
then
see
if
our
G
typically
deals
both
side
I
think
it
seems
like
a
useful
bit
of
MEC.
You
know
both
in
the
fact
in
the
sense
of
being
sort
of
a
construction
built
out
of
cryptographic
primitives
as
opposed
to
permit
itself
and
in
a
sense
of
being,
you
know
closer
to
a
mechanism.
You
would
you
would
leverage
in
a
protocol
as
opposed
to
a
generic
primitive.
T
T
One
of
the
things
changing
hats
over
to
former
Rai
area
director,
one
of
the
things
we've
done
in
the
RAI
area
with
dispatch
is,
if
there's
a
document
that
needs
a
little
bit
of
work,
needs
some
review
things
like
that.
You
can
spit.
You
can
spin
up
a
working
group
to
focus
just
on
that
documents.
So
we've
had
some
some
documents
come
through
ride,
dispatch
that
had
a
small
workings
that
lasted.
You
know
it's
three
or
six
months
just
to
deliver.
One
document
so
fairly
focused
fairly
quick
hit
and
then
shut
down.
T
AE
Well
meant
to
say
about
effigy
is
that
these
kind
of
solutions
are
used
in
some
system
I'm
aware
of,
but
they
used
these
time
stamps
as
part
of
an
input
of
signed
data
for
mation
into
the
apparent
G
and
I
think
that
kind
of
techniques
can
be
used.
Well,
no
other
good
choices
are
left,
but
they
must
be
analyzed.
So
maybe
this
is
good
for
work
for
safer
G.
Thank
you.
H
P
But,
and
actually,
if
there's
other
techniques,
that
would
be
another
reason
to
spin
up
some
larger
effort
that
somebody
might
want
you
to
do
so.
Okay,
so
I
think
we
have
three
options:
will
do
a
quick,
hum,
I
think
the
three
options
as
I
as
I
understood
them-
would
be
pursue
this.
Take
this
to
the
C
FRG,
actually
spin
up
a
working
group
to
actually
look
at
other
possible
ways
to
do
the
same
kind
of
thing.
P
B
Just
want
to
know
that
a
little
bit
I
like
I,
think
what
I'd
like
to
hear
from
this
group
is.
Do
you
think
this
is
suitable
for
80
sponsorship
and
then
Kathleen
like
another
conversation,
or
that
we'd
like
to
do
so?
I?
Don't
but
I
I,
don't
want
to
get
him
pointed
that
the
the
the
working
honey
on
like
whether
we
sponsor
stuff.
P
P
How
many
people
think
that
this
merits
spinning
together
a
BA
force
more
or
maybe
going
directly
to
us
to
a
working
group
to
work
on
something
fairly
focused,
but
in
this
area
hum
now,
okay,
I.
Think
that
we'd
like
you
to
take
this
to
the
CFR
gia
it
seemed
like
there
was
a
lot
of
interest,
but
a
lot
of
people
thought
it
ought
to
go
to
the
CFR
gee
I.
Don't
think
we
need
to
do
that.
Do
we
need
to
do
the
third
one?
How
many
people
think
this
should
just
be
ad
sponsor?
P
AH
Hi,
okay,
max
Paula,
CableLabs
and
open
sea
I'm
here
to
talk
about
the
simple
idea
OCSP
over
DNS,
it's
been
around
for
a
while
next
slide,
so
the
idea
is
very
simple:
enable
DNS
has
a
turtle
mechanism
for
SP
responses,
and
this
is
all
it
is
as
a
proposal
next
time.
This
comes
with
some
benefits
and,
most
importantly,
and
increase
availability
for
a
replication
information,
so
birthday
certificate
most
because
of
the
nature
of
DNS.
The
data
is
closer
to
the
user
and
the
cache
the
caching
system
of
the
name
DNS.
AH
My
actually
helped
me
in
reducing
the
cost
of
running
verification
or
providing
a
location.
Information
for
large
infrastructure
also,
there's
other
added
benefits,
for
example,
if
where
the
NSX
is
deployed,
you
can
actually
address
the
problem
that
we
have
today
we'll
be
submitting
and
disappearances
over
HTTP.
Mostly
time
is
HTTP
not
https,
distributed
through
CD
ends.
This
comes
with
costs,
but
also
comes
with
the
possibility
for
man-in-the-middle
attacks
to
prevent
you
from
reaching
the
delicate
information,
and
on
top
of
that
he
does
is
it
doesn't
suffer
from
the
synchro
reference
of
okay.
AH
I
want
to
use
the
LS,
so
I
have
to
validate
the
TLS
connection.
This
is
either
because
it
uses
a
different
set
of
keys
and
other
benefits
that
come
from.
This
is
that
you
know
in
some
environments,
think
about
some
devices
that
comes
online
in
a
network
and
before
we
actually
allowed
to
perform
any
real
action
or
even
access,
HTTP,
HTTPS
resources.
They
need
to
provide
some
form
of
authentication
or
authenticate.
AH
Some
servers
that
they
need
to
connect
to
DNS
might
provide
a
way
to
actually
validate
the
validity
of
the
certificates
presented
by
other
parties
could
be
IOT
devices,
communicating
between
each
other
or
communicating
with
the
controller,
or
even
you
know
the
device
fetching
their
own
SP
responses
and
embedding
them
in
the
TLS
session,
with
other
devices
stapling
that
and
of
course
this.
You
know
it's
just
a
DNS
query,
which
is
fairly
simple
for
application
to
do
that
they
don't
have
to
be
SP
requests
next
slide.
So
the
draft
is
very
simple.
AH
Technically
is
there's
two
things
that
we
define.
The
one
is
record
for
the
Aussie
SP
response
data
in
the
DNS.
It's
just
the
binary
representation
of
the
of
the
hospi
response.
The
draft
doesn't
propose
to
do
any
changes
there
and
the
use
of
DNS
your
eyes
in
the
eye
DN
a--
in
their
certificates,
so
that
applications
can
actually
use
that
and
fetch
the
the
the
SP
response
related
to
the
entry
that
is
in
the
certificate
self
next
time.
AH
AH
So
this
is
all
this
is
all.
It
is
there's
very
simple
proposal,
as
I
said
definition
of
the
record
for
in
DNS.
We
provide
some
example
on
how
you
how
it
ca
can
actually
build
this
target
for
the
DNS
by
using
maybe
the
serial
number
of
the
certificates.
But
since
we
don't
mandate
a
specific
format,
because
you
want
a
and
the
client
application
to
be
very
to
be
very
easy
particle
application
to
just
get
the
target
from
the
certificate
and
just
made
the
query,
we
don't
want
it
for
any
particular
way
to
construct
this
URI.
AH
And
as
I
said
before
before
this,
you
know
some
advantages
that
come
from
the
nature
of
the
DNS
itself,
there
is
a
bit
of
cash.
Global
is
really
cash
that
my
help
in
reducing
the
cost
of
providing
replication
information
and
in
some
person,
in
some
environments
like
OCF
or
CMI,
where
we're
introducing
actually
strong
authentication
for
devices.
This
might
be
a
way
to
improve
the
security.
The
overall
security
of
the
system
we're
shortly
certificates
is
not
really
an
option,
and
that's
it
that's
all.
It
is
so
questions.
AC
M
AH
B
response,
so
for
servers
right
for
servers
is
easy
for
client
might
not
be
as
easy
as
just
I'm,
not
saying
that
it
is
a
replacement
for
you
know
the
way
that
you
do
today.
If
you,
if
you
can
do
vs.
PC,
it
also
be
stapling
for
TLS
sessions,
but
really
fine,
there's
many
other
use
of
certificates.
That
might
not
have
that
option,
and
so
it's
just
any.
In
addition,
not
a
replacement
for
what
it
is
today.
If,
today
your
application
just
works,
fine,
you
support
OCSP
stapling,
that's
great!
AC
Doesn't
really
I
don't
find
that
it
all
persuasive
the
other
thing?
The
other
point
that
I
would
make
here
is
that
you
you.
You
said
that
this
would
reduce
the
revocation
the
cost
of
providing
revocation
services.
I.
Don't
think
that's
true,
because
most
of
the
cost
is
in
signing
as
someone
points
out
behind
me
and
what
you've
done
is
you've
created
an
extra
now
now
the
DNS
is
responsible
for
holding
all
this
information
and
there
it
doesn't
need
to
hold
it
in
every
single
recursive
resolver.
That's
ever
been
touched
by
this.
AC
AI
AI
AH
For
the
cost
of
providing
notification,
infrastructure,
you're
right,
there's
a
cost
associated
with
signing
those
responses,
but
most
of
the
time
now
many
large
CAS
they
just
pre
compute.
Those
and
put
it
on
CD
ends
accessing
their
access
to
see
the
ends.
Citians
are
you
have
to
pay
for
that?
So
that's
that's
the
cost
that
might
be
reduced
in
case
of
you
have
large
number
of
clients
connecting
directly
via
HTTP.
AH
AI
I'll
be
real
fast,
two
things
one,
you
can
request
a
dienes
or
a
type,
because
it's
all
pretty
straightforward
without
any
sort
of
expert
review
or
anything
like
that.
Just
go
to
Ino
and
felt
the
form,
and
you
can
get
that
r-type
right
away.
Second,
I
think
the
N
on
top
will
sort
of
give
you
the
advice
that,
of
course,
you
should
use
text
records
right.
So,
okay,
exactly.
T
I
was
gonna
say
that
new
aura
types
do
not
deploy
on
the
internet
and
DNS
SEC
has
kind
of
the
same
property.
Here.
That's
not
going
to
make
anything
better
because
there
is
no
circular
dependency
on
any
other
transport
security,
because
the
OCSP
requests
themselves
are
signed
and
so
that
addresses
the
security
concerns.
You
have.
E
T
E
T
AJ
Beyond
one
store
for
Apple
I
have
a
couple
of
questions.
I
think
my
first
question.
Actually,
let
me
address
the
OCSP
stapling
comment
from
I.
Think
Martin,
OCSP
stapling
is
well
one
disadvantage
of
all
seeming
stapling
is
that
it's
always
sent
by
the
server
on
any
new
handshake
basically,
and
that
might
not
be
needed
because
the
next
update,
for
it
alone,
says
P.
AJ
The
request
is
typically
in
the
timeframe
of
weeks,
so
it's
just
just
additional
bytes
that
are
not
really
needed,
so
there's
out-of-band
fetching
where
actually
it's
in
the
request
path,
but
this
fetching
from
either
DNS
or
CDN
as
it's
done
right
now,
it's
probably
still
a
ballot,
but
it
thing
to
do
my
other.
My
question
is,
though,
that
you're
I
just
looked
at
the
RFC
for
CSP,
and
it
seems
to
be
that
the
request
payload
needs
to
carry
a
little
bit
more
than
just
the
serial
number.
AJ
P
U
Hi
Sean
Leonard,
so
overall
I'm
in
favor
of
this
work,
it's
not
the
first
time
that
OCSP
over
DNS
has
been
presented
and
I
think
that
the
time
has
come
to
give
it
a
try.
I
did
read
the
draft,
it
is
experimental
and
whether
it
becomes
experimental
or
not
when
it's
published
I
think
that
a
working
group
approach,
because
there
are
they're
dragons
here,
there's
implementation
details.
AB
So
I
mean
I
kind
of
reflect
what
Martin
said,
but
also
I
mean
so
this
is
to
you
know,
get
around
possibly
over
caching,
on
on
the
CDN.
What
about
the
caching
proliferation
that
happens
with
various
DNS
caching
resolvers,
like
I,
don't
think
this
is
going
to
make
the
problem
any
better.
It
could
actually
make
it
a
lot
worse.
P
B
P
P
Q
P
AK
Right,
hi
guys
I
have
three
things
to
say
this
will
be
short,
I
think
all
of
them
are
around
EAP
that
the
idea
started
working
on
in
the
early
2000s
more
extensively.
We
defined
the
framework
and
multiple
different
out
in
the
case
of
methods,
including
APC
many
APA
ké.
This
presentations
is
around
EAP
aka
and
that
has
been
actually
fairly
widely
or
very
widely
implemented.
AK
If
you
have
a
2g
3G
4G
network
you're,
using
a
native
aka
authentication
scheme
and
a
3gpp
protocol
to
do
that,
the
ultimate
and
EAP
is
only
used
if
you
were
to
access
a
wireless
LAN
with
your
operator
credentials,
but
in
5g
this
may
actually
change,
because
the
5g
signaling
mechanisms
will
allow
use
of
EAP
to
authenticate
phones
that
connect
to
the
5g
radio.
So
that's
the
information
piece
next
slide.
AK
Please
so
I
have
two
drafts
around
this
topic,
and
one
is
a
very
simple
update
of
the
existing
latest
RFC
5448
on
EAP
aka
prime,
which
is
a
further
development
of
the
original
aka
draft,
and
this
minor
update
relates
to
actually
just
one
reference
in
in
the
old
RFC
points
to
a
version
of
the
3gpp
spec.
That
gives
a
table
of
how
you
bind
certain
contexts
where
you
do
this
authentication
into
the
keys
of
the
authentication
method,
and
that
is
planned
to
be
changed,
because
now
there
will
be
other
context,
namely
the
5g
context.
AK
So
if
you
ought
indicate
with
you
know,
within
the
5g
network,
you
will
use
a
different
string
to
mix
with
your
euro
key
and
that's
a
really
like
the
smallest
possible
reason
for
updating
an
RFC,
but
I
actually
happen
to
believe
that
if
you
haven't
even
the
smallest
issue
in
an
RFC
used
to
fix
it
and
I
think
the
idea
should
be
able
to
do
that
sort
of
thing.
So
that's
that's
the
update
piece
we
and
I
there's
no
idea
of
updating
anything
like
you
know,
adding
new
functionality
or
anything
like
that.
AK
Of
course,
you
could
consider
adding
security
considerations
if
you
learn
some
new
things
and
you
actually
have
learned
some
new
things.
I
didn't
do
any
of
that
for
this
verse
and
take
a
look
at
the
draft
and-
and
please
provide
your
your
comments
next
slide,
please.
So
the
other
draft
actually
relates
to
attacks
and
relates
to
pervasive
surveillance
concern.
So
after
the
Snowden
revelations,
some
of
the
on
Revelations
we're
actually
quite
interesting
from
the
point
of
view
of
the
mobile
networks
and
and
SIM
cards.
AK
So
we
had
the
story
in
the
newspapers
around
some
intelligence
agencies
breaking
into
the
systems
or
the
organizations
of
SIM
card
manufacturers
that
manufacture
these
by
the
millions
or
hundreds
of
millions
and
and
deliver
them
to
operators,
and
you
know
basically
saying
that
you
know.
In
some
cases
the
agencies
have
been
able
to
get
to
the
sim
the
smart
card
manufacturers.
You
know
the
actual
data
in
the
card
through
the
manufacturing
or
provisioning
process
and
there's
nothing
to
do
with
the
actual
technical
means
of
you
know
actually,
even
though
the
cards
or
the
authentication
protocols.
AK
This
is
like
a
other
level
of
attack.
If
you
have,
you
know
national
security
letter
or
you
blackmail,
the
guy
who
you
know,
does
the
manufacturing
process
or
or
you
know,
have
a
point-
a
contour
person.
You
will
get
some
key
material,
no
matter
what
what
the
technology
is
underneath,
but
it
does
point
to
sort
of
changes
in
this
security
situation
or
threat
situation.
So
we
should
assume
that
you
know
some
of
this
well
could
be
happening
next
slide.
Please.
AK
Now
that
the
whole
process
like
okay,
gets
access
to
to
the
the
manufacturing
process
and
and
and
their
technical
tools
and
how
they
communicate
the
keys
between
the
manufacture
and
the
operator
authentication
Center,
but
nevertheless,
I
don't
think
we
can
rule
out
that
some
vulnerabilities
remain
so
this
other
draft
I
won't
go
into
the
technical
details,
but
the
basic
idea
is
provide
perfect
forward
secrecy
which
we
didn't
have
in
the
original
ABAP
a
cavers
and
and
with
peer
fruitsy
for
secrecy.
Of
course
you
can
get.
You
know,
protection
against
passive
attackers.
AK
If
the
agencies
get
the
keys,
then
they
don't
necessarily
get
the
data
of
the
the
users
traffic
details.
You
can
look
at
the
draft
there's
no
current
officer
requirements
for
this
from
3gpp
or
anybody
else,
but
I
thought
this
would
be
prudent.
Technical
move
on
our
part
next
slide.
So
next
steps
happy
to
get
feedback
if
we
could
get
some
of
this
into
the
work
program
of
the
IETF
I'd.
AK
Be
really
happy
should
point
out
that
there's
some
coordination
going
on
with
IETF
and
3tp
and
various
topics
on
the
EAP
space
there's
actually
more
than
this
particular
topic
that
I'm
talking
about
now
and
I'm,
keen
on
updating
the
existing
RFC's
that
that
they
are.
You
know
up
to
the
current
situation
and
I'm,
also
keen
on
worrying
about
threat
situation
with
regards
to
intelligence
agencies
and
and
pervasive
surveillance.
AK
So
that's
it
when
you
know,
maybe
one
more
thing
that
you
know
if
you're
thinking
about
EAP
in
general,
there's
also
some
other
drafts
in
this
space
that
we're
not
talking
about
here
now
but
but
that
that
may
factor
into
like.
If
we
put
some
work
somewhere,
do
we
want
to
do
it
where
so
that's
it.
Thank.
P
AK
A
A
List
is
still
actively
used,
but
when
I
just
tried
to
get
to
it
for
the
eat
list,
you
just
wind
up
with
a
login
page.
So
maybe
those
subscribed
are
still
happily
getting
their
eat
messages
but
might
be
difficult
for
people
to
join
so
I
think
we
have
to
straighten
that
out
and
also
find
out
the
larger
interest
in
this
space,
and
maybe
just
use
this
new
reap
list.
A
A
Q
AA
My
name
is
hi
Graham
drama,
wowie,
Thank,
You,
America
communication.
Actually,
I
myself
is
about
contributor
to
the
5g
security
standing
in
3gpp
and
yeah
I
I'm
a
quite
agree
with
this
proposal
here,
because
recently
there
are
some
new
attacks
for
the
ipiria
for
the
telecom
networks
and
so,
and
the
five-year
top
the
EAP
framework
for
authentication
and
so
I
think
it's
necessary
to
enhance
the
EAP
message
for
the
future
use
great.
AE
AA
S
L
P
E
V
P
So
I
think
we're
gonna
move.
Let's
do
a
quick
hum
either,
so
the
choices
are.
Do
you
think
that
these
that
EEP,
these
two
drafts,
and
perhaps
others
in
the
area
of
EEP,
are
important
enough
that
this
the
security
community
should
spit
up
some
new
work
and
take
this
on
uh-hum?
Now,
if
you
think
we
should
do
that,
how
many
people
think
that
that
we
should
not?