►
From YouTube: IETF108-SAAG-20200730-1300
Description
SAAG meeting session at IETF108
2020/07/30 1300
https://datatracker.ietf.org/meeting/108/proceedings/
A
Okay,
we
have
a
full
agenda,
shall
we
get
started
ben?
Yes,
let's
get
started.
B
A
A
Hello,
everyone:
this
is
the
security
area,
advisory
group
kind
of
sag.
We
have
a
kind
of
a
short
session
here.
This
is
room
and
dinner.
Speaking
with
my
co-chair
ben.
A
A
A
We
built
an
agenda
around
first
starting
off
with
what
is
the
work.
That's
happening
going
back
as
far
as
ietf106.
If
needed.
We
have
something
a
little
special
this
time,
because
we
haven't
had
a
chance
to
get
together.
We
wanted
to
highlight
work
that
is
nearing
completion
or
has
completed
so
we're
going
to
talk
about
some
of
the
things
recently
done
in
dots.
A
A
Agenda:
okay,
if
not
we'll
move
ahead
with
that
and
do
lightning
round
on
working
group
reports.
We
won't
talk
about
working
groups
that
have
set
reports
to
the
mailing
list
and
thank
you
for
all
those
that
did
it
and
in
terms
of
version
control.
This
slide
deck
is
as
old
as
the
reports
probably
made
about
15
minutes
ago.
So
ace
reported
acme,
cosy,
curdle
dots,
emu,
gnap,
i2,
nsf
ipsec
me.
Is
there
something
we
want
to
say
about
kitten.
B
I
thought
that
kitten
did
send
mail
yeah.
They
sent
me
out
so,
okay,
we'll.
A
It
makes
sense
ben
mls
oauth.
The
next
meeting
is,
I
believe,
on
monday,
as
an
interim
on
the
usual,
the
usual
drill
of
kind
of
doing
something
regularly.
But
if
her
father
hanus
want
to
say
something
at
the
end,
privacy
pass
rats,
sakum
sex
dispatch.
You
just
met
sec
event
if
dick
or
yarn
want
to
say
something
later
suit.
A
Keep
tls
toke
bind
if
john
or
leaf
want
to
say
something.
Trans,
melinda
or
paul
want
to
say
something,
and
here
we'll
pause
for
those
working
groups.
That
did
not
have
a
report.
If
someone
would
like
to
come
to
the
mic
to
talk
through
anything,
that's
happening
and
ben,
if
you
could
help
manage
the
queue,
I
actually
can't
see
what's
happening
since
I'm
flipping
yeah.
I.
B
I
will
drive
the
queue
so
your
own,
you
should
send
audio
as
well.
C
B
Great
and
just
a
note
or
reminder
to
everyone
that
sometimes
it
will
take
a
few
seconds
from
when
you
start
sending
audio
to
when
the
stream
is
actually
making
it
to
everyone.
So,
if
you're,
introducing
yourself
or
something
in
the
first
few
seconds,
when
you're
speaking,
that
will
help
make
sure
that
your
content
gets
through
all
right
paul
go
ahead.
E
D
Meet
there
is
we're
working
on
one
document
of
this
document
for
a
rfc
6962,
there's
three,
the
three
members
of
the
isg
have
discussed
items
open
and
it's
my
job
to
chase
them.
B
Well,
I
hope
you
can
find
them
in
gather
time.
I
don't
know
if
everyone
has
been
there,
but
it's
the
closest
substitute
for
the
the
hallway
that
we
have.
B
So
I
do
believe
we
got
some
other
reports
from
some
of
the
groups
listed
here.
I
think
utah
and
cfrg.
I
remember
seeing
and
of
course,
we're
hearing
a
little
bit
about
model
t
later
in
the
deck
karen
you're
up.
B
You,
okay,
I
think
that
is
probably
all
we're
gonna
get
from
the
the
reports.
So
let's
move
on
to
the
next
item.
Okay,
so
I
guess
this
is
mostly
me
so
just
some
other
things
that
happened
in
the
sec
area
to
call
out.
We
do
have
a
couple
of
80
sponsored
drafts
that
have
been
making
their
way
forward
after
perhaps
a
too
long.
He
is
my
document.
B
Cue
has
come
up
at
the
open
mic,
so
there's
the
security
txt
document
that
that
everyone
remembers
the
long
set
of
idf
last
call
comments
for,
but
we
are
working
our
way
through
those
and
I've
had
some
responses
and
feedback
from
the
authors
on
the
sag
list.
B
For
my
summary
of
those
comments-
and
it
looks
like
we're
going
to
be
able
to
move
forward
with
that
and
send
it
to
the
isg
pretty
soon
and
then
there's
also
the
numeric
id
set
considerations
document
that
I
won't
talk
about
right
now,
because
we
have
a
separate
item
later.
E
B
We've
seen
some
new
implementations
coming
up
and
interest
in
doing
specific,
interop
work
and
getting
the
algorithm
updates
in
place
that
we
had
tried
to
do
the
previous
time
around
and
we'll
also
just
highlight
this
link
on
the
slides
about
some
list
of
typical
security
related
issues
that
perhaps
room,
and
I
see
a
lot
when
we're
reviewing
the
documents
and
that
can
serve
both
as
a
guideline
to
say,
sector
reviewers,
but
also
as
a
guideline
to
authors,
to
be
on
the
lookout
and
hopefully
fix
things
before
we
see
them.
B
B
And
we
also
wanted
to
throw
a
big
thanks
out
to
the
sec
dear.
These
reviews
are
really
helpful
to
us
and
they
are
helpful
to
authors
as
well
to
get
some
feedback
a
little
bit
in
advance
of
the
actual
isg
tal
chat
and,
of
course,
the
earlier
feedback
is
always
good
to
get
the
documents
approved
before
more
people
see
them.
So
I
just
spend
a
moment
to
thank
everybody.
Hopefully
we
didn't
miss
anybody
and
not
put
your
name
on
the
slide.
B
If
we
did,
we
apologize
we're
not
trying
to
admit
anyone
just
to
make
sure
that
people
get
the
appreciation
they
deserve.
So
thank
you
again.
Next
slide.
B
All
right
so
teru
you
are
up,
do
you
want
to
join
the
queue
I
you
are
sending
audio,
so
we
should
be
able
to
hey.
G
Yeah,
hey
hello,
everyone,
I'm
thiru
I'll,
be
presenting
ddos,
open
threat,
signaling
overview,
it's
part
of
dot's
working
group
and
this
working
group
was
formed
around
six
years
back
and
we
have
made
tremendous
progress
in
various
specifications,
so
I
will
go
over
some
of
them
next
slide,
please,
before
I
jump
into
dots
and
what
does
this
dots
is
created,
especially
for
ddos
attacks,
as
many
of
you
may
be
aware
that
ddos
attacks
have
been
increasing
in
the
last
few
years.
G
G
And
nowadays,
if
you
see
just
like
software
as
a
service,
ddos
is
also
offered
as
a
service
for
attackers
and
they
leverage
millions
of
ports
across
the
globe
to
attack
a
specific
target.
Next
slide
is.
G
For
instance,
nowadays,
if
you
see
there
is
a
tremendous
growth
in
the
number
of
iot
devices,
and
many
of
these
iot
devices
unfortunately
have
vulnerabilities
and
malware
typically
take
advantage
of
these
vulnerabilities
and
infect
these
devices,
for
example,
mira,
is
a
very
popular
botnet
which
is
used
to
launch
ttos
attacks
on
targets
and
recently,
if
you
see
that
at
scale
has
reached
close
to
terabits
per
second
and
it's
it's
growing
every
year,
and
I
and
the
biggest
problem
is
that
many
of
these
owners
of
these
iot
devices
don't
even
know
that
these
devices
are
in
fact
infected
and
they
are
used
as
launch
pads
for
attacking
targets
in
the
internet.
G
Next
slide,
please
there's
hundreds
of
ddos
attacks,
I'm
not
going
to
go
all
of
them,
but
just
to
say
that
the
attack
happens
from
layer
3
to
level
7.
It
could
be
a
dns
amplification
attack,
taking
advantage
of
large
dns
responses.
It
could
be
just
a
simple
sinful
attack.
The
most
challenging
ones
are
the
ones
that
happen
after
the
tls
handshake
is
completed,
which
could
be
just
sending
garbage
data
or
sending
partial
requests
to
the
http
server.
G
What
is
the
problem
with
ddos
right?
Ddos
is
a
major
problem
because
of
the
strategies
that
are
used
by
the
attackers
to
target
different
victims
within
a
network
or
targeting
the
entire
network
itself,
and
there
is
a
need
for
automating
the
readous
attack
mitigation,
because
that
could
happen
at
any
time.
It
could
be
a
volumetric
attack.
G
It
could
be
targeting
the
entire
network
or
a
specific
resource
within
the
enterprise
network
or
content
provider
network,
and
there
is
a
need
for
automating
ddos
mitigation
so
that
immediate
remediation
could
be
taken
and
and
goods
traffic
and
good
traffic
can
still
be
processed,
while
bad
traffic
is
blocked.
G
Next,
like
this,
for
instance,
if
you
see
last
year
and
south
african
isp
was
bought
down
for
almost
a
year
and
there's
been
discussing
discussions
among
several
isps
for
the
need
to
automate
the
ddos
mitigation
strategy
so
that
they
can
effectively
sinkhole
the
bad
traffic
and
then
and
then
allow
allow
these
isps
to
function
for
their
customers
next
slide,
please.
G
What
was
the
need
for
dots
is
that
today,
if
you
see
many
ddos
mitigation
providers
and
security,
vendors
do
offer
tdos
detection
ddos
mitigation,
but
they're
all
using
proprietary
techniques,
for
instance,
if
an
enterprise
network
is
attack
getting
attacked
today
it
it's
it's
supposed
to
use
proprietary
protocols
to
talk
to
an
isp
or
a
third
party,
ddos
mitigation
provider,
which
creates
vendor
lock-in
and
the
existing
protocols
that
were
used
a
few
years
back
were
not
resilient
to
work
under
extreme
hostile
network
conditions,
for
instance,
a
scenario
where
there
is
a
large
scale,
ddos
attack,
the
entire
incoming
link
would
be
saturated
and
there
is
no
way
that
these
messages
would
read
the
dos
mitigation
provider.
G
So
the
working
group,
when
it
wa
got
created
the
we
went
back
a
step
to
decide
what
are
the
requirements
for
dots
protocols
to
function,
and
then
we
started
working
on
the
protocol,
so
it
took
a
while
for
us
to
figure
out
the
right
requirements
which
were
collected
from
various
isps:
security,
vendors,
ddos
mitigation
providers,
and
then
the
work
started
for
building
protocols
based
on
these
requirements.
G
Next
slide,
please,
okay!
So
what
is
dots?
Dot
stands
for
lido's
open
thread,
signaling.
It's
an
standard
based
approach
for
real-time
signaling
of
ddos.
G
G
B
G
Sure
so
dots
is
a
standard
space
approach
for
real-time
signaling
of
threat
in
related
information
between
the
target
network
and
the
ddos
mitigation
provider,
so
that
it
it
completely
automates
the
way
ddos
attacks
are
handled
today.
G
Before
I
jump
into
the
protocols,
we
thought
I
thought
it's
it's
good
to
explain
how
the
dots
architecture
looks
like
for
you
to
get
an
understanding
of
how
dots
entities
are
involved.
So
target
is
the
target
network
or
or
it
could
be,
a
target
server
that
gets
attacked.
Ddos
client
could
be
typically
your
ddos
mitigation
on-premise
detox
mitigation,
or
it
could
be
a
ddos
detector
which
detects
ddos
attacks
within
the
network
and
then
the
dot
server
is
the
one
which
actually
provides
you.
G
G
Slide
related
signaling
is
a
very
similar
concept
that
many
of
you
have
seen
it's
it's.
It's
uses,
dots
gateway,
dots
gateway,
it's
very
similar
to
sip
back
to
back
user
agent,
which
is
a
logical
concatenation
of
a
client
and
server
so
that
the
gateway
can
aggregate
the
requests
coming
from
dot
clients
and
relay
them
back
to
the
dot
server
next
slide.
G
So
if
you
see
a
traditional
setup
of
an
inbound
ddos,
an
enterprise
network
would
have
a
ddos
dots
client.
It
could
be
a
firewall
or
an
ips
or
a
ddos
mitigator.
That
is
there
deployed
on
the
enterprise
network.
When
the
attack
is
overwhelming
and
the
ddos
mitigator
cannot
handle
the
traffic
anymore,
it
can
send
a
signal
back
to
the
dot
server
in
the
isp,
saying
that
hey
it
needs
help
and
the
dot
server
basically
starts
programming.
The
ddos
mitigation
pro
mitigators
to
start
scrubbing
the
incoming
traffic.
G
As
you
can
see
on
the
left
side
of
the
screen,
there
is
a
home
network
and
cpe
and
there's
a
dot
client.
It's
an
interesting
scenario
that
nowadays
we
see
many
of
these
home
networks
also
getting
attacked
by
ddos
attacks,
and
I
will
go
over
home
network
scenario
in
couple
of
slides,
but
it's
interesting
to
see
that
even
nowadays,
home
networks
are
and
target
for
ddos
attacks
next
slide.
Please
recursive
mitigation
is
an
interesting
concept.
G
Imagine
imagine
if
the
attack
attack
grows
beyond
the
scale
of
the
isp
and
it
is
not
able
to
handle
the
attack.
Then
it
can
basically
signal
the
upstream
transit
provider
saying
that
hey,
you
need
to
help
me
out
and
you
need
to
start
scrubbing
the
traffic
and
then
the
transit
providers,
ddos
mitigation,
zetas
mitigators
kick
in
and
they
start
scrubbing
the
traffic
and
start
blocking
all
the
bad
traffic.
G
Next
slide,
as
I
was
saying
in
the
previous
slide,
home
network
is
an
interesting
case
that
home
network
could
be
both
could
be
attacked
and
home
networks
are
typically
used
as
launch
pads
for
launching
tdos
attacks
on
targets,
especially
because
of
vulnerable
iot
devices.
G
That's
where
we
have
an
interesting
draft
where
the
dot
server
in
the
home
and
the
dots
client
in
the
isp
can
coordinate
and
identify
the
actual
infected
device
within
the
home,
which
is
launching
this
attack
and
can
take
various
actions
like
isolating
the
device
informing
the
home
administrator
to
remediate
the
device
and
and
several
such
actions,
which
makes
it
quite
compelling
that
the
owner
of
the
device
is
now
aware
that
his
iot
device
is
infected
next
slide.
Please
coming
to
the
protocols,
I
mean
dots
has
two
primary
protocols.
G
One
is
the
signal
channel
protocol
and
the
data
channel
protocol
signal.
Channel
protocol
has
been
designed
to
work
under
extreme
network
conditions
when
the
network
is
congested
and
it's
it's.
The
primary
protocol
used
for
signaling
mitigation
request
to
the
dot
server
the
second
channel
is,
is
dot
dots
data
channel.
This
is
a
management
channel.
It's
an
optional
channel.
It's
used
for
creating
aliases
for
your
resources.
Let's
say
you
have
a
bunch
of
domain
names
rather
than
conveying
all
those
domain
names
or
ip
addresses.
G
During
your
attack,
you
can
create
aliases
so
that
that
short
form
of
alias
could
be
sent
in
the
mitigation
request.
It's
also
used
for
creating
acl
rules
within
the
dot
server.
For
example,
filtering
several
ip
addresses,
which
are
typically
used
as
launch
pads
for
attacking
the
target
server,
could
be
blocked
by
that
and
it
you
could
also
create
rate
limiting
filter
rules.
So
it's
relying
on
the
acl,
that's
already
defined
to
instantiate
those
acl
rules,
either
during
the
attack
time
or
during
the
peace
time.
G
So
dotsan
signal
channel
is
as
you
as
as
you
guys
can
understand
that
it
it's
supposed
to
run
during
a
constrained
scenario
where
the
network
is
congested
and
probably
the
client
may
also
be
resourced
out
because
of
the
attack
traffic
that
is
coming
in
so.
H
H
B
G
Hey:
hey,
sorry
again:
it
crashed.
So
it's
it's!
It's
it's
using
co-app
co-op
is
designed
for
iot
devices,
but
we
picked
the
protocol
because
it's
very
lightweight
it
can
run
on
both
udp
and
tcp.
Tcp
is
is,
is
just
picked
for
as
a
fallback
mechanism.
The
primary
protocol
that
it's
supposed
to
run
is
udp
because
of
the
network
conditions
it
it
mandates.
G
The
use
of
dtls,
for
security
and
and
and
the
way
we
are
using
co-app
is
to
use
its
non-comfortable
messages,
which
is
which
can
be
periodically
transmitted
and
don't
need
any,
doesn't
require
as
a
reliable
transmission
mechanism.
So
that
way,
periodic
signals
can
be
exchanged
between
the
dots
client
and
the
dot
server
next
slide.
Please.
G
In
addition
to
picking
co-app,
I
mean
the
data
model,
for
this
is
cbor,
consists:
binary
object,
representation.
It
was
again
picked
because
of
its.
It
keeps
the
message
size
really
small
and
the
message
need
not
be
really
fragmented.
So
that's
the
reason
in
addition
to
co-app
c
bar
data
representation
was
picked
next
slide,
please.
G
So
if
you
look
into
the
primary
operations
of
dot
signal
channel,
it's,
it
runs
both
during
the
ideal
time
and
in
the
attack
time.
Ideal
time
is
when
there
is
no
attack
on
the
network,
and
it's
it's
that
time
when
the
dot
signal
channel
is
established
between
the
dot
spears.
It's
also
used
for
negotiating
the
co-app
message.
Transmission
parameters
and
heartbeats
are
exchanged
to
keep
the
session
channel
alive
when
an
attack
happens,
and
if
the
dots
client
detects
that
it
needs
help
from
the
ddos
mitigation
provider.
G
It
sends
a
mitigation
request
for
specific
set
of
resources
within
the
network
that
needs
to
be
protected,
and
we
have
an
interesting
feature
called
it's
a
deadman
switch,
basically
which
which
triggers
mitigation
on
signal
loss.
So
if
the
signal
is
disconnected
between
the
client
and
the
server,
then
the
mitigation
is
triggered
automatically
and,
as
you
can
see
nowadays,
the
attackers
are
changing
the
way
they
attack
a
network,
they
target
a
specific
resource
and
then
change
the
ddos
attack
and
target
different
resources
within
the
network.
G
So
the
client
has
to
change
the
mitigation
scope
as
the
attack
evolves,
and
the
mitigation
also
has
to
adapt
accordingly
and
further,
the
cyrus
keeps
sending
the
mitigation
status
update
back
to
the
client
so
that
the
client,
operational
security
team
doesn't
know
what's
happening
at
the
server
side.
The
client
also
sends
feedback.
Basically,
the
efficacy
updates
to
tell
the
server
whether
it
is
capable
it
is
it
is.
It
is
able
to
block
the
bad
traffic
or
not
and
based
on
that,
the
server
can
change
rates,
ddos
mitigation
strategies.
G
Data
channel
dots
data
channel
is
based
on
rest
account.
Restaurant
is
based
on
netcon,
which
is
for
basically
configuring
network
devices
with
configuration
data.
We
are
using
that
for
creating
aliases
for
the
resources
in
the
in
the
network
and
for
installing
acl
rules
to
either
permit
deny
or
rate
limit
traffic
either
during
the
attack
time
or
during
the
peace
time.
G
Next
slide.
Please
dots.
Data
channel,
unlike
signal
channel,
is
designed
to
work
only
during
the
ideal
time
it
uses
tcp.
The
first
operation
is
for
it
to
establish
a
channel
with
the
dot
server
and
then
register
the
client,
and
then
the
client
discovers
the
acl
filtering
capability
of
the
server.
We
have
several
ways
where
to
synchronize
the
state,
with
the
dot
server,
to
remove
any
stale
entries
to
remove
any
stale
acls
or
any
stale
domain
names
that
were
created
for
which
aliases
were
created.
G
There
are
two
parts
of
the
management:
one
is
the
alias
management
and
the
acl
policy
management.
The
aliases
is
just
for
resource
creation,
creating
aliases
for
resources,
and
it's
just
a
crude
operation
to
create,
delete
and
update
or
read
those
aliases
that
were
created.
G
The
second
one
is
very
interesting
one
that
it
helps
to
create
acl
rules
across
administrator
domains
that
now
an
enterprise
network
intel
and
isp
to
block
a
specific
set
of
blacklisted
ip
addresses
which
are
targeting
the
enterprise
network,
and
it
can
do
a
very
similar
operation
to
create,
delete
and
update
these
acl
rules.
G
Next
slide,
please,
we
have
several
documents
in
the
working
group.
The
two
primary
protocols
have
recently
been
standardized.
The
dot
signal,
channel
and
data
channel.
The
dots
architecture
and
other
drafts
are
already
in
the
rsa
editor
queue.
We
have
a
requirements
draft
and
the
the
use
cases
draft
is
in
iseq
review.
The
open
source
of
dots
is
available
at
this
link.
So
if
anyone
wants
to
give
it
a
try,
they
can
explore
this
further
and
or
and
contribute
to
the
open
source
next
slide.
H
B
Yeah-
and
I
guess
if
there
was
one
question
now-
we
might
have
a
little
bit
of
time,
but
we
are
pretty
much
at
the
time
slot.
B
I
do
not
see
anyone
who
has
managed
to
find
the
join
the
queue
button
quite
yet
so
I
think
we're
going
to
say
that
our
questions
can
go
to
the
mailing
list,
as
you
said.
So.
Thank
you
again,
thanks
for
exciting
to
see
the
stuff,
okay,
all
right
so
roman.
Can
you
get
us
back
to
the
the
slides
and
looks
like
I
am
up
next.
B
So
I
had
started
a
bit
of
a
thread
about
this
on
the
the
sag
list.
It's
sort
of
the
trigger.
I
guess
we
should
go
to
the
next
slide.
B
The
trigger
was
a
an
nfs
document
actually
and
one
of
the
working
group
members
made
this
assertion
that
tls
fingerprint
printing
is
needed,
and
my
initial
response
was
that
I
didn't
really
think
that
that
was
the
consensus
position
of
itf
security
area,
but
I
also
didn't
really
have
something
that
I
could
point
to
to
back
me
up
for
that.
B
So
I
figured
I
should
come
here
and
ask
and
actually
get
a
better
sense
of
what
our
position
is
and
just
to
note
that
in
this
linked
message,
they
were
proposing
four
different
options:
that
all
implementations
should
be
required
to
support,
which
would
be
to
sort
of
manually
configure
which
key
fingerprint
or
certificate
fingerprint
to
use
to
do
the
sort
of
pinning
of
the
and
then
the
fingerprint,
but
also
ensure
it
change
up
to
a
trusted.
Ca.
B
And
to
have
just
a
sort
of
typical
pki
set
up
where
you've
got
one
or
more
cas
and
anything
that
changes
up
to
them.
You
accept
and
also
the
option
to
just
do
a
manual
config,
which
I
say
skipped
over
when
I
was
first
reading
them.
So
the
sort
of
overarching
question
that
I
have
for
the
group
is
like
is
this
true
or
when?
Is
it
true,
if
it's
only
sometimes
true
so
next
slide
and,
of
course,
to
just
explicitly
call
out?
B
This
is
not
just
about
the
web
for
nfsv4,
that's
not
expected
to
be
using
the
the
web
pki
with
the
cab
forum
and
whatnot.
So
please
keep
that
in
mind
as
we're
having
a
discussion
next
slide.
B
B
So
it's
important
to
call
out
the
manual
configuration
option
which
would
be
just
like
configuring,
an
entity
asymmetric,
key
or
potentially
even
a
symmetric
key
for
some
protocols,
and
you
could
do
that
directly
or
you
could
sort
of
do
the
trust
on
first
use
which
imports
it
into
your
configuration.
When
you
first
see
it,
I'm
going
to
talk
about
like
a
public
ppi,
which
would
be
something
like
the
web
dki,
where
there's
a
large
set
of
cas
that
are
sort
of
trusted
by
many
people
that
are
not
of
a
common
administrative
boundary.
B
You
can
also
have
sort
of
a
more
local
pki
or
enterprise
pki,
with
basically
like
one
ca
that
you
control
and
may
not
extend
beyond
the
administrative
domain
and
then
also
just
mention
that
you
have
the
dns
option,
which
is
not
really
going
to
factor
much.
I
think
into
the
rest
of
the
discussion,
but
just
to
list
it
there
next
slide.
B
So
I
try
to
summarize,
like
reasons
why
you
might
pick
the
the
broader
public
pki,
however,
perhaps
just
to
pick
out
in
general.
So
of
course
it's
a
scalable
option.
You
you
only
have
to
compare
the
anchors
and
then
anchors
can
sign
through
the
tree
structure,
many
things
and
you
don't
have
to
know
about
all
the
end
entities
in
order
to
be
able
to
have
a
secure
trust
path
to
them.
B
You
could
also
import
your
enterprise
ca
into
that,
but
it
does
have
the
problem
that
you
know
these
cas
are
sort
of
high
value
targets,
and
so
you
have
to
protect
that
and
depending
on
what
kind
of
local
deployment
you
have,
you
may
or
may
not
be
prepared
to
protect
the
high
value
secret
very
well
next
slide,
and
so
that
leads
to
some
of
the
other
options
like
if
you
just
do
a
manual
configuration
or
a
trust
on
first
use
setup.
It's
a
lot
simpler.
You
don't
need
to
have
these
third-party
cas.
B
You
have
to
trust.
If
there
is
an
enterprise
ca
in
play,
you
can
sort
of
bypass
its
ability
to
to
man
in
the
middle
of
you.
B
If
you
don't
want
that,
if
that's
the
sort
of
setup
that
you're
in
if
you're,
if
you're
in
a
pki
that
you're
obligated
to
have
the
enterprise
ca
in
but
there's
a
particular
application
that
you
don't
want
to
be
able
to
sneak
on
then
sort
of
the
manual
configuration
definitely
avoids
that,
and
your
revocation
story
is
different
in
some
ways,
perhaps
worse,
because
you're,
not
you,
don't
have
a
guaranteed
path
to
find
out
about
revocation
or
compromise,
but
the
scaling
is
not
so
great.
B
B
And
then,
based
on
the
the
new
taxonomy
that
we
came
up
with,
the
pinning
would
be
to
sort
of
have
generally
the
public
pki,
and
then
you
want
to
say
well
for
many
things,
I'm
going
to
trust
all
the
cas
in
the
public
pki.
B
But
for
this
particular
thing
I
want
to
pin
to
just
a
subset
of
the
cas,
because
in
some
sense
some
of
the
cas
are
less
trusted
than
the
others,
but
they're
trusted,
sometimes,
which
is
perhaps
a
little
bit
of
rude
setup,
and
I
don't
have
a
great
sense
for
for
how
common
this
is
that
you
would
need
this
sort
of
partially
trusted
state
outside
of
the
web
pki,
and
so
the
other
updates
that
came
out
from
email
are
that
we
generally
are
not
going
to
be
recommending
ping
to
the
end
entity
itself,
because
that's
kind
of
brittle.
B
I
have
this
note
about
rfc
7469
no
longer
recommended
that
maybe
came
out
of
the
thread.
If
it
really
is
normally
recommended,
we
might
want
to
have
someone
consider
writing
a
document
to
say
move
to
historic.
B
So
I
have
two
slides
of
questions
that
I
sort
of
want
to
get
resolved
by
the
group
or
to
see
the
discussion,
and
I
don't
know
that
we
have
to
cover
them
in
a
particular
order.
People
are
free
to
jump
into
the
cube
if
they
see
something
that
they
want
to
complain
about,
but
sort
of
the
overarching
question
is
relating
to
different
protocols
or
types
of
protocols,
just
to
say
like.
When
might
we
want
to
use
a
full
pki?
When
might
we
want
to
use
just
manual
config?
B
Probably
the
question
of,
if
pinning,
what
to
pin
I
sort
of
answered
on
the
previous
slide
and
jerome.
If
you
could
go
to
the
next
slide,
just
got,
I
think
one
or
two
more
questions
so
getting
back
to
the
original
inquiry.
Do
we
do
we
actually
want
to
be
saying
anything
at
all
to
require
or
encourage
particular
protocols
to
be
robust
in
terms
of
what
configuration
options
they
offer
do?
B
We
think
that
just
the
ability
to
have
a
local
pki
instead
of
a
public
pki
is
enough
or
do
we
just
want
to
say
this
is
this
is
just
implementation?
We
don't
need
to
say
anything
at
all
about
it,
so
that
is
how
I
want
to
see
the
discussion
it
looks
like
we
have.
Maybe
only
three
minutes
left
if
we
stick
it
straight
to
the
agenda,
but
hopefully.
I
So
to
answer
the
first
question
yeah,
I
think
you
know
I'm
always
in
favor
for
for
having
everybody
have
the
ability
to
you
know,
configure
their
crypto
and
and
so,
if
you
don't
do
that,
then
you're
not
helping
the
clueless
users,
but
going
back
to,
I
think
one
important
element
of
your
of
your
problem
is
that
you're
not
defining
who
is
doing
the
less
trusting,
in
other
words,
who
wants
pinning
and
who
wants
config,
because
it's
there's
very
different
parties
there
and
what
they
want
is
different.
Clueful
users,
of
course,
want.
I
You
know
absolute
control.
That
makes
sense.
Clueless
users
don't
have
any
idea
right,
they're,
letting
somebody
else
make
the
decision.
You
mentioned
that
os
and
browsers,
but
there's
two
other
big
parties,
the
cas,
don't
trust
each
other
they're,
all
they're,
all
the
best.
They'll
all
tell
you
that
they're
the
best
and
that
you
know
they.
You.
I
Anybody
else,
cert
owners,
also
don't
trust
things
right.
Shirt
owners
are
the
ones
that
want
the
pinning
but
want
to
be
able
to
move
too.
They
only
trust
their
ca
because
their
ca
is
the
best,
but
then
how
do
they
move?
So
if
you
take
this
problem
in
all
those
different
viewpoints,
you'll
get
very
different
answers.
I
think.
F
No,
that's
right,
no
problem,
yeah,
I'm
just
going
to
reiterate
what
I
said
on
the
list,
which
is
very
briefly
that
this
is
almost
not
a
protocol
issue.
If
you
look
at
like
tls,
mls
and
ipsec
various
other
protocols,
the
authentication
stack
is
pretty
loosely
coupled
to
what's
actually
in
the
protocol.
There's
you
know
tls,
for
example,
can
handle
both
raw
public
keys.
You
have
to
manually
configure
and
various
types
of
pki
so,
like.
F
I
think
the
question
here
is
whether
how
to
handle
protocols
that
try
to
explicitly
profile
themselves
down
to
only
supporting
one
of
these
and
there
it
seems
like
we
probably
don't
need
an
absolute
prohibition,
but
we
certainly
need
some
justification
of
how,
if
you're
going
to
constrain
yourselves
down
to
manual
provisioning,
how
you
why
that's
an
acceptable
option
for
something
that's
going
to
deploy
in
the
internet
like
how
are
you
going
to
deal
with
the
setup
problems,
the
trust
establishment
problems
around
provisioning
and
how
do
you
deal
with
revocation.
B
F
F
F
I
J
Sounds
good
so
yeah,
I
guess
a
few
points.
Richard
is
true
that
comstock
protocols
tend
to
be
agnostic
about
about
authentication,
but,
of
course
the
upper
lying
application
protocols
are
not
so,
for
instance,
you
know
http
specifies
how
you
want
to
do
sort
of
certificate,
authentication
the
I
think
part
of
the
question.
So
I
think
this
does
go
back
to
great
a
great
example
use
case,
which
is,
if
you
want.
J
I
mean,
as
I
said
in
my
note,
if
you,
if
you
like,
want
to
have
a
client
or
an
entity
which
can
talk
to
any
entity
in
the
universe,
you're
going
to
need
some
kind
of
public
pki,
because
or
or
or
dns
or
whatever,
some
sort
of
publicly
verifiable
namespace.
J
J
If
you
have
a
you
know
a
private,
private,
private
setup,
then
I
think
the
question
is:
how
many
you
know
how
many
entities
do
you
need
in
the
system
before
like
really
configuration
effectively,
you
know,
becomes
automatic
configuration
which
really
is
just
sort
of
a
goofy
form
of
pki
so
and
I
suspect
the
answer.
That
number
is
very,
very
small.
E
Thanks
this
is
dkj
just
wanted
to
observe
two
points
here.
One
is
that
I
believe
that
the
ietf
you
know
we
are
continue
to
skate
around
the
question
about
whether
we're
doing
apis.
This
looks
more
like
api
than
protocol
design,
but
I
want
to
state
my
support
for
it.
I
actually
think
that
thinking
clearly
about
what
the
api
should
be
gives
us
a
way
to
provide
really
good
guidance
towards
the
whole
implementation
community,
and
I
don't
think
we
should
stay.
E
Secondly,
I
wanted
to
note
that
the
term
pinning
has
a
history
of
multiple
uses,
including
not
just
I
want
to
constrain
to
this,
but
I
also
want
to
allow
additional-
and
I
think
it
I
I
think
it's
a
little
bit
unclear
whether
we're
saying
both
of
these
yeah.
I
I
tried.
J
J
E
Here-
and
I
I
you
know-
maybe
we
want
to
just
like
claim
that
we
own
the
word
pinning
and
we're
going
to
use
it
the
right
way
in
this
one
way,
but
there's
a
history
of
other
documents
that
use
it
in
other
ways.
So
it's
just
something
to
to
watch
out,
for
I
don't
have
a
specific
suggestion
for
how
to
fix
it.
B
Yeah
yeah,
I
was
trying
to
set
the
stage
for
what
we're
talking
about
today
and
not
trying
to
claim
any
claim
on
future
terminology
thanks.
K
Hi,
so
when
we
were
doing
hpkp
and
websec
all
these
many
years
ago,
we
initially
had
all
the
different
pinning
ideas
there
I
mean
to
identity
and
between
pspa.
And
finally,
we
got
to
the
conclusion
that
pinning
the
identity
is
the
wrong
thing
to
do,
because
the
keys
do
get
you
got,
do
have
to
be
replaced.
K
But
the
thing
you
want
to
pin
to
is
the
ca
end
entity
now
granted
this
info
was
coming
from
ryan
sleevy
was
working
at
google
and
when
they
say
something
doesn't
scale,
they
mean
something
different
than
all
the
rest
of
us,
but
still
end
entities
do
get
replaced
and
keys
get
replaced,
and
then
you
have
to
reconfigure
everywhere
where
it's
configured
and
you
don't
want
to
do
that.
B
All
right
thanks,
so
we
are
actually
five
minutes
over
time
at
this
point
for
the
topic
so
phil.
If
you
could
drop
your
comment
to
the
jabber
or
the
email.
B
Now
we've
got
a
couple
things
sort
of
in
flight
that
may
be
making
changes
or
updates
sort
of.
In
this
general
space,
we've
got
fernando's
document
about
the
security
considerations.
When
you
have
numerical
identifiers
in
your
protocol,
you
probably
saw
on
the
sag
list.
I've
been
having
a
little
bit
of
a
back
and
forth
with
my
evaluation
comments,
but
I
think
we
are
converging
onto
something
useful
and
I
just
I
want
to
have
a
bit
of
extra
visibility
to
tag
about
what
we're
actually
doing
in
the
document,
especially
with
the
big
questions
about.
B
Are
we
making
requirements
or
just
adding
to
the
list
of
things
to
think
about
in
terms
of
what
guidance
we
give
and
then
the
other
sort
of
high-level
question
relates
to
how
much
detail
we
go
into
in
the
document
if
we
just
need
to
sort
of
give
a
general
list
of
the
topics
to
consider
or
if
we
should
really
go
into
more
detail
and
give
examples
of
how
these
come
into
play,
or
we
should
leave
that
to
some
of
the
other
documents
that
are
in
progress,
so
please
go
pay
attention
to
the
email
thread
and
chime
in
there.
B
B
H
H
All
right
so
so
this
is
one
particular
aspect
of
this
broader
bcp
update
discussion.
So
just
the
model
t
part
of
it
at
two
slides,
I'm
just
gonna
cover
the
like,
what's
happening
in
model
t
and
then
talk
about
potential
updates,
and
the
model
t
of
course,
is
about
extending
the
set
of
threats
that
we
should
consider
more
carefully.
H
Basically,
because
we
had
great
success
in
deploying
some
security
technology,
and
now
the
threats
are
migrating
to
other
other
other
things,
or
I
mean
the
threats
were
or
vulnerabilities
were
always
there,
but
now
the
other
side
is
attempting
to
use
other
aspects
or
other
avenues
when,
when
we're
plugging
the
more
obvious
avenues-
and
of
course,
when
we
discuss
about
this
other
other
things,
we
are
not
trying
to
reduce
the
importance
of
communication
security
protection
in
any
fashion.
So
that's
probably
out
of
scope.
H
And
of
course,
since
we
have
an
iab
program,
we're
not
about
to
override
what
the
ietf
says
about
various
things
in
its
pcp,
so
we
might
make
some
suggestions
individually,
but
that's
that's
the
end
of
it.
So
we've
had
basically
two
kinds
of
discussions,
documents
and
a
discussion
that
talks
about
the
threats,
various
issues,
newer,
old
and
design
guidelines
at
various
levels
and
bunch
of
documents.
H
You
see
some
of
them
probably
missed
a
few,
but
you
see
the
list
of
drats
on
top
of
the
screen,
and
then
we've
also
talked
about
these
potential
suggestions
that
we
will
take
to
the
itf
at
some
point-
and
this
could
be
one
one
such
point,
so
some
additions
to
existing
pcps,
particularly
35,
52
or
7258,
and
then
one
that
I
would
like
to
highlight
today
is
the
first
one
to
go
to
the
next
slide
and
just
to
set
the
stage
a
little
bit
so
so.
H
This
is
something
that
we
or
some
of
us
at
least
feel
that
should
be
done.
H
We're
not
wedded
to
particular
set
of
words
in
any
fashion,
just
felt
that
we
should
write
some
words
so
that
we
can
get
criticizing
them
or
replace
them
with
better
words
or
whatever
the
process
is,
but
we
did
write
some
words,
suggestions
and,
and
the
the
draft
that
we
have
with
steven
does
add
a
few
pieces
of
text.
H
There's
like
the
high
level
thing,
that's
sort
of
highlighted,
with
the
yellow
in
the
middle
of
the
screen
and
then
there's
a
few
other
parts,
basically
one
paragraph
each
in
most
cases
at
least
further
on
in
in
the
in
the
document.
The
idea,
of
course,
is
that
the
bcp
72
it
shouldn't
be
like
your
kitchen
sink
guidelines
and
everything
that
you
ever
needed
to
know
about
protocol
design
and
security.
H
It
should
not
be
there,
but
you
should
perhaps
recognize
some
high-level
issues,
so
we
did
feel
that
it
would
be
useful
to
talk
about
the
other
endpoint
compromise
or
how
you
limit
the
effects
of
compromise,
how
you
could
potentially
force
or
remind
people
that
you
should
try
and
force
active
attacks
and
worry
about
traffic
analysis.
And
what
techniques
can
you
use
to
contain
the
compromise
of
those
trusted
parties?
H
The
details
are
in
the
in
the
draft.
I
don't
think
we
have
time
for
for
that
part
really
today.
Please
comment
on
the
list,
be
nice
to
get
some
feedback.
H
Indeed,
we
have
a
mailing
list
and
we
also
have
a
like
get
together
today
at
1610
utc
in
yeah.
I
don't
want
to
do
that.
Basically,
yeah.
H
Yeah,
yeah
and
and
the
coordinates
are
in
the
mail.
It's
if
you
look
for
model
t
model
dash,
t
maining
list
from
the
itf
main
lists,
you'll
find
find
the
relevant
emails
thanks.
B
It's
exciting
to
have
people
thinking
about
this
and
try
to
be
more
precise
about
what
the
best
practices
are.
I
think
we
should
probably
roll
any
questions
or
comments
about
this
into
the
general
open
mic.
So.