►
From YouTube: IETF105-SAAG-20190725-1330
Description
SAAG meeting session at IETF105
2019/07/25 1330
https://datatracker.ietf.org/meeting/105/proceedings/
A
A
Alright
good
at
good
afternoon,
everyone
and
welcome
to
sag.
My
name
is
Roman
Jo
and
I'm
co-chairing
with
Benkei
duck.
So
why
don't
we
get
started
first
up.
This
is
the
note.
Well
you've
seen
this
in
other
meetings.
This
of
course
applies
to
the
session
we're
having
today.
If
you
have
any
questions
on
what's
there,
please
don't
hesitate
to
come
up
to
the
mic
and
we
can
have
a
conversation
about
it.
A
A
A
All
right
with
that,
let's
roll
thanks
to
all
the
work
groups
that
sent
their
information
to
sag
we're
gonna
quickly
skip
through
the
ones
that
have
reported.
If
you
want
to
follow
along,
you
could
obviously
go
to
the
sag
mailing
lists
archive
or
in
the
slide
proceedings.
You'll
see
a
URL
to
their
status
report,
so
we're
good
with
ace.
Acme
Kersey
curdle
did
not
meet
dots,
mu,
I
to
minus
f
IP.
Second
me
kitten.
Lamp
smile
MLS
is
meeting
on
Friday.
Is
there
anything
that
needs
to
be
said
there.
B
To
be
said,
at
the
mic,
we
sent
her
for
five
minutes
before
the
meeting,
so
it
is
out
there
now.
The
only
thing
that
we
could
add-
that's
not
in
there
is.
The
chief
working
group
has
consensus
to
take
a
dependency
on
the
suit
working
group
and
the
rats
working
group
for
that
matter,
and
so
that's
just
an
inter
working
with
the
may
be
of
interest
to
people
that
suit
and
breasts
out
have
a
customer
which
is
us
as
teeth,
perfect,
courageously
work
in
collaboration
across.
C
A
D
Hi,
this
is
Elliott
I.
Think
I
would
just
put
ops
Harry
working
group
on
the
list
in
terms
of
we're
doing
a
lot
of
mud
expansion
and
one
of
the
particular
pieces
of
work
that
we'll
be
looking
for
guidance
on
is
that
there's
a
mud
reporter
draft
out
there,
which
would
which
is
ARF
like
that
might
generate
reports
back
to
manufacturers.
There
are
obviously
privacy
considerations
throughout
all
this,
and
you
know
it's
a
very
nation
draft
we're
still
trying
to
figure
out
what's
going
on
and
so
over
time.
D
E
When
they
Seltzer
w3c,
we
will
send
an
update
and
if
you
were
in
the
paired
research
trip
yesterday,
you
heard
Pete
from
brave
speaking
about
some
work
in
privacy
considerations
and
specifications
between
w3c
and
IETF
I.
Invite
folks
who
are
interested
in
those
issues
at
the
web
application
layer
to
come
over
and
check
out
things
that
w3c
is
doing
in
our
privacy
interest
group
and
in
our
web
application
security
and
web
authentication
working
groups.
B
Thank
you
ever
under
external
related.
Another
organization
is
itu-t
study
group
17,
which
sent
a
liaison
or
a
sent
multiple
of
them
to
the
teeth,
working
group,
they're
doing
related
work,
and
fortunately
we
have
overlap
and
participants
wherever
the
editors.
If
the
documents
come
to
IETF
participate,
thank
you,
tuck,
and
so
right
now
we
believe
that
we
are
aligned,
but
it
is
an
external
activity
that
we
are
tracking
from
with
an
84
thing
group.
F
And
this
is
Linda
Deborah
from
future
way
for
the
external
related
to
work.
There's
the
Owen
ug
open
network
user
group.
There's
a
software-defined
security
services
is
related
to
security
service
for
the
hybrid
cloud
and
also
for
the
IETF
in
the
routing
area.
We
had
a
IDR
has
quite
a
few
contributions
related
to
how
to
do
controller
of
PGP
to
distribute
IPSec
parameters,
so
that
was
related
to
security.
G
Like
you
want
me
to
mention
the
Netcom
for
sure
actually,
okay,
rich
sauce
net
comp
has
got
a
draft
out
for
crypto
types
and
actions
and
monitoring
and
so
on
and
anyone
who's
implemented.
Any
kind
of
cryptography
will
look
at
it
and
Blanche
so
I
encourage
everyone
to
look
at
it
and
Blanche
or
expert
or
do
whatever
you
need
to
do.
I.
H
Want
to
mention
the
buff
that
we've
had
this
ITF
Lake
buff,
those
who
weren't
there
sure
there's
been
at
the
start,
was
quite
pessimistic
and
think
that
the
content
was
the
dirtiest.
We
have
a
group
of
people
wanting
to
work
on
this.
It's
about
creating
a
lightweight
authenticated,
key
exchange
for
using
IOT,
specifically
requirements
that
came
out
of
the
Oscar
working
group
and
well.
H
The
people
in
the
room
were
kind
of
split
among
people
wanting
to
do
something
very
narrowly
tailored
to
the
Oscar
working
group
and
people
who
wanted
to
do
something
more
by
burning
and,
of
course,
we
already
have
two
suggested
solutions
for
solving
this,
even
though
the
requirements
are
not
down
yet
so
since
that,
towards
enough
enthusiasts
in
to
form
a
working
group,
I'm,
not
sure
that
this
scope
is
hammered
down
enough
to
do
the
so
I.
Guess
that's
what
the
eighties
now.
A
Yeah,
yes
/
for
the
eighties.
Thank
you
you've
and
Steven
for
chairing
that
working
group.
We
were
excited
to
see
a
lot
of
enthusiasm.
The
the
problem
around
an
ache
is
understood
and
we
were
excited
to
see
enthusiasm
around
both
Oscar
and
a
broader
kind
of
solution,
but
we
have
some
kind
of
tough
choices
to
think
I've
had
about
how
to
actually
proceed
so
for
those
that
participated.
Kind
of.
Thank
you
for
the
input
to
stay
tuned
on
how
we're
gonna
do
next
steps.
I
Think
if
we
talk
about
identifiers
which
could
yeah
harm
the
users,
privacy
and
also
yes,
there
was
a
technical
linear
also
on
privacy
and
a
lot
of
activity,
and
the
sick
area
is
on
privacy
issues.
We
see
some
use
cases
where
this
should
be
especially
interesting
and
perhaps
may
come
up
more
than
in
past.
I
I
So
with
a
traditional
approach,
routing
between
two
IP
addresses
for
an
session
between
two
endpoints
identified
with
by
their
IP
address.
This
is
working
fine
in
entrant,
transparency,
more
or
less,
but
in
some
cases
Mittman
may
not
be
enough
efficient,
maybe
too
complex
too
much
encapsulation
and
decapsulation
and
tunneling
and
D
tunneling
and
things
and,
for
instance,
one
of
the
UK's
mobility
high
speed
mobility,
extreme
ability
with
the
IP
addresses,
or
they
point
of
attachments
changing
very
rapidly
and
the
session
above
cannot
survive.
Perhaps
the
change
of
the
endpoints,
so
some
applications
needed.
I
But
this
approach
generally
may
be
an
advantage
here
and
could,
as
these
help
to
survive
the
session.
So
yes,
this
is,
there
are
multiple
protocols
and
solutions
and
RFC's
available
only
to
mention
here
lisp
with
not
only
RFC
6830
3.
This
is
the
control
pain,
part,
but
there's
all
6830
for
the
data
plan
or
user
plane
part.
Then
we
have
Ireland
PE,
which
came
out
of
research
group
activities.
I
They
are,
for
instance,
our
C
6740,
and
then
there's
also
proposed
by
Tom
Abbott,
with
ila
identify
located
addressing,
which
is
in
draft
status,
and
they
all,
of
course,
care
for
their
security
and
privacy
by
themselves
and
have
solutions,
but
they
are
not
yet
or
not
deployed
in
a
large
scale.
Of
course,
they
are
experimental
or
also
least
was
going
for
sendeth
or
there
are
multiple
deployments
implementations.
I
They
are
and
small
scale
deployments
on
ila
also
for
for
databases,
but
yes,
there's
not
yet
an
operator
who
uses
this
approach
for
its
network
and
to
have
this
approach
largely
not
as
an
overlay
over
another
overlay.
Also,
it
would
be
I
think
kind
of
ideal,
a
solution.
Of
course.
We
need
something
purchase,
also
practical
and
that's
what
we
want
to
yeah.
I
That's
the
way
we
want
to
proceed
to
see
whether
there
is
something
on
common
ground
of
different
approaches,
perhaps
kind
of
a
more
alight
solution,
which
of
course
nevertheless
serves
the
same
advantages
for
this.
For
what
these
ID
lock,
approaches
have
been
proposed
so
to
reduce
the
burn
of
the
ipv6
or
ABI
address,
which
is
normally
handling
both
the
identity
and
the
location,
which
is,
for
instance,
for
the
virtual
machines
with
their
different
locations
for
the
same
identity
would
be
helpful
and
then
new
network
architecture
is
required
for
them
for
police.
J
I
These
are
all
areas
where
this
ID
location
would
apply
nicely
to,
but
also
again,
the
privacy
issue
has
to
be
solved.
It
has
to
be
considered
enough
so
that
there
is
no
new
privacy
risk
when
using
this
and
I
would
like
to
go
shortly
on
the
different
approaches
which
I
mentioned,
which
are
available.
So
the
list
protocol
is,
as
an
SOS
approach,
uses
an
extra
mapping
system
and
encapsulate
the
packets
Tunnel
set
between
list
domains
and
can
also,
of
course,
interact
with
non
these
demands.
I
But
the
new
list
architecture
course
could
be
a
burden
for
deploying
it
into
an
a
running
system.
Ok,
there
are,
of
course,
you
does
specified
new
entities
which
do
all
this
and
as
usual,
if
you
have
the
identifier
and
you
need
the
locator,
you
have
to
query
the
mapping
system,
but
only
if
it's
necessary,
of
course,
if
it's
not
changing,
you
need
not
vary
again.
So
that's
not
noted.
I
No
only
the
overhead,
if
you
guys,
is
required,
for
instance,
if
you
flow
is
transmission,
direct
formation
is
starting
or
if
the
locator
is
changing,
and
there
are
ok,
different
RFC's
and
updates
to
this.
Rfc's
now
are
under
ASG
evolution,
evaluations,
sorry,
as
proposed
standard
instead
of
experimental,
and
there
are,
of
course,
more
information
on
the
dispersed
net
for
existing
deployments
and
also
cost
for
the
least
working
group
information.
I
K
I
The
topology
and
issues
for
fathering
and
routing
and
the
identifier
is
the
notable
naming
the
note
which
may
be
physical
but
logically
note
and
normally
does
not
change
and
yeah.
What
is
the
advantage?
It
does
not
require
any
hooter
changes,
no
new
route
us
are
required
for
this
and
it
uses
ENS
the
existing
mapping
system.
But,
of
course,
this
is
perhaps
not
a
good
idea
if
we
have
very
frequent
queries
for
the
mapping
system.
I
The
identifier
edges
required,
and
this
has
been
deployed
and
commercially
already
on
IP
layer,
and
there
are
also
limitations
available.
You
know
it's
a
little,
so
it's
this
is
all
which
is
working
and
special
advantages
that
the
upper
layer
UDP
and
we
did
not
did
not
don't
need
to
change
when
using
ila,
and
there
has
been
in
one
coffin
il
a
worse
there's
more
information,
also
on
the
link
even
there.
So
that's
what
I
want
to
say.
I
You
need
to
know
it,
and
not
only
the
location,
but
also,
of
course,
the
movement
and
I
come
in
combining
different
information.
This
can
lead
to
two
new
risks
and
of
course
also
that
was
something
which
moody
party
CP
Marcello
pointed
out
that
if
we
have
multiple
paths,
that
is
also
the
privacy
risk,
because
there
are
multiple
informations
more
than
one
location
and
may
lead
or
result
in
more
precise
location
information
for
the
adverse
user
which
needs
should
not
do
it.
Yeah.
I
Okay,
we
there
have
been
as
a
set
of
solutions
proposals
already
for
and
and
they
have
their
own
solutions
as
well
in
this
person,
Island
P
and
also
for
ila
here
only
in
a
draft
status
moment.
But
the
question
is:
why
has
not
been
deployed
so
far?
Yeah?
The
question
is
privacy,
of
course,
may
be
one
of
the
reasons,
but
the
the
deployment
itself
that
ID
lock
systems
are
not
deployed
in
networks.
Today
is
some
other
reason
of
your
architecture.
I
You
need
of
new
components
you
need,
so
you
have
to
change
a
lot
and
operators
are
not
willing
to
change
something
if
they
are
not
true
about
the
positive
outcomes
out.
We
also
have
to
point
on
the
advantage
of
it,
of
course,
and
one
approach
may
be
that
the
mapping
system
perhaps
is
not
so
complicated,
so
looking
for
a
new
mapping
system
may
be
one
way,
but
we
are
not
not
yet
sure
about
this,
but
therefore
we
see
there's
a
lot
of
potential
work.
I
I
Time
for
a
few
questions,
yeah
and
then
the
other
slides
are
just
for
pick
up
I
available
in
the
Proceedings
of
you
can
look
it
up
there
and
you
can
join
the
mailing
list
there,
of
course,
and
and
review
our
drafts,
which
we
have
up
to
now
in
a
very
draft
status,
also
published
yeah
I,
understand
I
would
be
happy
to
answer
questions
or
get
feel
dangerous.
Oh
gosh.
L
:
is
there
a
reason
to
believe
these
problems
are
soluble.
L
I
N
N
I
I
N
But
one
one
of
the
thing,
one
of
the
things
I
remember
from
its
story-
was
that
you
could
have
a
femoral
hits
in
that
system
and
the
idea
was,
you
could
create
them.
So,
oh
and
now
bob
was
coming
to
the
microphone
I
think
he
was
the
originator
of
hip
anyway.
I
just
wanted
to
point
you
at
that
something
you
might
want
to
also
look
at.
I
O
Of
st.
Andrews
and
I
don't
think
I'll
NP
particularly
has
any
unique
problems
in
this
area.
The
same
techniques
in
RFC
49:41
that
are
used
to
generate
ipv6
privacy
addresses
those
same
techniques,
can
be
used
with
il
NP,
as
is
with
the
current
Island
PRF
CS,
and
with
the
current
aisle
and
P
implementations.
So
it's
unlike
slide
11
up
there
island
piece
just
leverages
the
solution.
Work.
That's
already
been
done
to
mitigate
these
risks
with
ipv6
and
we
don't
need
any
special
magic
sauce.
That's
Island
be
unique,
so.
I
P
Just
gonna
Thomas,
who
is
a
she
consulting
the
hipster,
except
when
I
can
hit
by
car
my
hip
I'm,
a
lurker
on
these
lists,
I
filed
along
doing
it
aspects
of
hip
and
hip
bone
are
very
similar
to
some
of
the
issues
being
done
here.
I'll
note
that
I
have
a
work
project
on
a
privacy
based
exchange
and
I
have
a
customer
who
wants
me
to
get
moving
on
it
already
and
a
few
other
things.
So
there
are
things
that
we
hit
with
it's
long
lived
identities
which
are
definitely
could
be
considered.
M
Thank
you,
Robin
Wilson,
I'm
glad
to
see
this
work
being
considered
because
the
more
we
think
about
privacy,
the
more
we
realize
the
importance
of
protecting
data,
that's
at
the
infrastructure
layer
and
is
very
hard
to
obfuscate,
so
that
the
fact
that
privacy
considerations
are
high
on
the
list
is,
in
my
view,
a
plus
point,
I
think
it's
also
valid
to
ask
whether
or
not
there's
a
solution
to
this
problem,
but
only
if
we
also
recognize
that
solution
is
not
necessarily
a
binary
thing.
There
may
be
degrees
of
mitigation
of
the
risks.
This
involves.
I
Q
This
is
science.
You
mentioned
that
some
of
those
solutions
are
being
used
in
the
IOT
space
and
industrial
IOT
and
I
was
wondering
whether
you
could
shed
some
light
on
on
this
topic,
shake
what
explain
what
your
experiences
with
that
IOT
or
deployment
of
those
technologies
in
the
industrial
IOT
space,
okay,.
P
Problem
is
really
really
hard,
because
sometimes
you
simply
transfer
the
prom
to
someplace
else.
Your
transport
numbers,
the
long-lived
ESP
spies
long-lived.
How
do
you
deal
with
those
things?
Yet,
if
you
address
you
fix
the
address,
you're
only
doesn't
remove
the
prompt
is
somewhere
else
and
some
other
layer
of
the
protocol.
So
there's
still
a
lot
of
work
to
be
done
here
and
looked
at
very
carefully
that
you,
you
think
you
solve
the
problem,
but
you
won't
evolve.
What
you
think
is
the
obvious
problem
and
there's
just
this
other
one
lurking
there
as
well.
R
S
S
So
if
you
look
at
35
52,
that
kind
of
describes
the
internet
an
internet
model
that
we
kind
of
used
when
designing
protocols-
and
the
interesting
part
says
two
things
the
first
one
essentially,
is
that
we
assume
that
an
attacker
has
complete
control
the
network
and
that
leads
us
to
generate
all
sorts
of
COMSEC
protocols
and
to
want
to
turn
on
concept
becomes
like
mechanisms
in
protocols.
The
second
thing
it
says
is
that
we
assume
the
end
systems
engaging
in
the
protocol
have
not
themselves
being
compromised
and
I
guess
what
we.
S
What
we
think
is
that
thing
one
is
still
absolutely
necessary.
We
shouldn't
consider
weakening
that
or
doing
silly
things
in
that
space,
but
thing
to
may
no
longer
be
sufficient,
or
maybe
it
doesn't
matter
yeah
anymore,
and
this
is
perhaps
something
worth
looking
at.
I
guess
I
mean
I
would
say
that
in
the
you
know,
in
defense
of
3552.
It
may
well
be
the
case
that
as
soon
as
you
go
beyond
what
it
says,
you
run
into
problems
that
are
so
hard
there's
very
little.
You
can
do
about
it,
so
this
may
be
a
problem.
S
That's
a
bit
too
hard,
or
maybe
there's
things
we
can
do
so
again,
looking
at
thing
two
and
thinking
about
comparing
it
to
the
current
reality.
If
we
get
better
COMSEC,
as
was
all
the
thing
one,
then
that
motivates
attackers
to
look
elsewhere.
So
they
you
know,
keys
under
doormats
kind
of
things
or
all
those
kind
of
stuff
surveillance,
I
think
has
been
an
issue.
We've
talked
about
from
from
the
point
of
view
of
three-letter
agencies,
but
also
in
the
real
world.
S
Today,
there's
this
kind
of
surveillance,
capitalism,
that
kind
of
generates
new
risks
because
of
the
breath
the
collection
of
information.
The
fact
is
that
this
is
essentially
unavoidable.
If
you're
using
the
Internet
today
and
family
wrote,
35
50
to
the
Internet
was
a
pretty
different
place.
I
think
it's
also
true
that
even
for
a
network
that
you
think
isn't
really
vulnerable,
even
if
that's
true
at
a
particular
point
in
time.
S
Some
short
time
later,
it's
probably
no
longer
true
so
people
who
have
thought
that
maybe
they're
designing
that
applications
or
protocols
in
the
ITF
who
think
I
have
this
bit
of
the
network.
That's
safe
over
here
and
nobody's
gonna
touch
it
because
it's
in
there
behind
a
perimeter
that
doesn't
seem
to
be
true
nearly
as
much
as
you
would
think,
and
certainly
that
doesn't
match
reality.
We
have
cases
where
we
see
competing
interests
involved
in
so,
for
example,
the
whole
debate
around
applications
doing
net
DNS
is
a
case
in
point
about
where
this
you
know.
S
S
These
days,
when
you
have
virtualization,
you
have
software-defined
networking
and
a
whole
bunch
of
other
things
that
are
really
not
what
we
would
considered
as
the
kind
of
host
requirements
which
is
I,
guess
that
the
mental
model
we
might
have
had
like
them
so
there's
an
argument
that
thing
two
is
no
longer
sufficient.
Ted
suggested
that
we
could
do
a
poetic
version
of
this
and
there's
two
poetic
versions,
one
that
this
is
one
they're,
really
horrible.
S
But
I
guess
all
we're
thinking
about
it'd
be
good
to
get
people
looking
at
this
problem
and
trying
to
consider
are
there
things
that
we
can
do
that
better
reflect
reality,
but
also
that
are
useful
for
people
doing
work
in
the
ietf
or
elsewhere
in
designing
protocols.
That's
kind
of
like
you
know.
One
of
the
nice
things
about
3552
is
the
threat
model.
Is
nice
and
simple
in
other
places,
in
the
ITF,
for
example,
there's
an
RFC
for
the
OAuth
threat
model.
S
S
The
four
of
us
we
all
have
to
be
on
the
IRB
at
the
minute,
but
it
is
not
an
IRB
thing,
necessarily
we're
looking
for
guidance
and
feedback.
We
think
there
could
be
some
useful
end
results.
So,
for
example,
we
have
in
RFC
69
73
some
privacy
guidelines
that
are
not
really
part
of
the
kind
of
ITF
process
formally,
but
that
are
useful
talking
about
things
like
data
minimization.
S
Maybe
we
can
think
about
the
fact
that
some
of
our
protocols
are
some
of
our
security
mechanisms
and
protocols
may
be
increasing
tendencies
towards
centralization
in
ways
that
we'd
be
better
off
not
doing.
We
may
have
some
design
process
issues
so,
for
example,
in
the
ITF
somebody
comes
along
and
says:
I
have
this
use
case,
I
want
to
do
and
they
invent
something
that
has
a
new
identifier.
That's
a
long
term
stable
identifier
that
gets
everywhere
and
that
causes
privacy
problems.
Maybe
we
should
be
considering
or
encouraging
people
to
think
of
abuse
cases.
S
So
how
can
the
thing
you
want
to
do
be
abused
and
build
that
into
the
design
process?
And
that
might
be
a
simple
a
little
bit
bit
of
guidance.
We
could
include
so
we're
not
proposing
right
now
to
do
a
3552
base.
I'd
have
tried
that
didn't
work,
I
think
what
we'd
like
to
do
is
get
a
bunch
of
people
who
are
interested
in
this
to
work
together.
Maybe
I
think
Taylor's
gonna
try
and
see
if
we
can
stead
of
a
mailing
list.
S
If
unless
people
say
this
is
all
crazy
and
you
shouldn't
do
it
and
we
could
just
kind
of
work.
The
problem
with
people
who
are
interested
in
us
and
perhaps
after
we've
done
that
to
see
if
there's
stuff,
that
can
be
said
and
then
see,
can
you
window
that
down
to
something
useful
that
could
apply
to
places
in
the
IETF
or
people
putting
this
kind
of
work?
S
Perhaps
after
that
we
might
want
to
come
back
and
look
at
some
kind
of
modification
to
the
process
and
BCPs
that
we
have
so
we're
not
proposing
that
the
client
dive
right
in
there,
yet
without
doing
a
better
preparation
work
and
we're
looking
for
feedback,
we're
looking
for
people
who
are
interested
in
being
involved
and
if,
if
people
don't
tell
us,
this
is
all
stupid
and
crazy.
You'll
probably
set
up
a
mailing
list
and
send
the
cord
that's
to
say.
S
T
Mohit
Erickson,
so
this
is
not
completely
crazy
or
stupid.
So
I
think
you
should
continue.
I
get
get
that
there
is
a
need
to
maintain
the
balance
that
if
we
open
open
up
saying
that
endpoints
can
be
compromised,
then
we
need
to
like
think
how
far
they
can
be
compromised
and
and
so
on,
like
we
are
not
here
to
like
protect
against
someone,
you
know
do
physically
threatening
your
things,
but
there
are
still
still
some
things.
T
We
can
definitely
look
at
so
for
couple
of
examples
that
that
came
to
my
mind,
miss
binding
attacks
are
at
least
I.
I
also
spoke
to
Acker
about.
This
is
something
where
one
of
the
nodes
participating
in
the
communication
is
compromised,
and
then
he
misleads
you
to
talk
to
some
third
party
and
if
you
have
a
server
database,
whether
you
are
using
a
symmetric,
fake
or
asymmetric
or
whatever
balance
imbalance
bake.
T
These
kind
of
things
do
make
affect
of
what
happens
when
one
of
the
nodes
get
compromised
and
perhaps
for
us
as
protocol
engineers,
when
we
are
designing
these
these
things,
we
could
a
better
choice
and
prepare
ourselves
for
for
the
case
when
one
of
the
the
parties
is
compromised,
then
again
like
we
don't
want
to
open
the
floodgates
and
let
everything
end
so
definitely
interested
and
would
like
to
see.
This
go
forward,
need
to
be
a
little
bit
careful
I.
U
U
As
you
know,
I
also
have
a
draft
which
is
a
new
threat
model,
smart
ski
for
this
particular
meeting,
which
you've
commented
on
as
well
so
I.
Very
much
look
forward
to
working
with
you
and
in
that
draft
I
do
go
through
quite
a
lot
of
threats
that
are
happening
in
the
most
recent
years,
in
particular
with
malware
botnets
and
data
breaches.
So
hopefully
we
can
fold
that
all
in
to
have
a
more
broader
perspective,
so
I
look
forward
to
working
with
you
thanks.
Thank
you.
B
Dave
Taylor,
thank
you,
I
didn't
know
about
the
workshop
either
until
this
ITF
but
I'm
interested
in
this
topic.
We
actually
have
two
working
groups
in
this
area
that
are
meant
for
cases
where
a
thing
too
is
not
true.
Those
two
working
groups
are
rats
and
teeth,
and
so
the
point
is
yes.
I
think
it
is
good
for
us
to
have
some
document
as
an
area
whether
it
comes
out
of
this
effort
or
something
water.
That
says
how
to
think
about
this
in
your
threat.
B
Modeling,
because
we
have
working
groups,
so
rats
is
trying
to
say
how
do
you
do
attestation
where
your
device
may
be
compromised,
but
your
device
may
have
multiple
different
sub
modules
in
it,
whether
it's
different
layers
in
a
secure
boot
chain
or
whether
it's
different
processor
context,
one
was
one,
is
secure.
One
is
normal
or
whatever,
depending
on
your
architecture,
and
so
rats
has
to
do
with
that
test
station
and
he
has
to
do
with
remediation.
How
do
you
get
out
of
that
state?
B
V
W
W
There's
one
of
the
drafts
talks
primarily
about
security,
while
the
other
draft
includes
both
security
and
privacy.
I'm
I
don't
have
a
strong,
I
don't
know
if
it
would
be
better
to
combine
them
or
separate
them.
I
suspect
the
W
we
see
has
interesting
things
to
say
about
privacy,
so
there
should
be
some
ways
on
with
them
sure.
So
when
you
refer
to
the
draft,
you
meant
the
ones
I
have
here
or
there
two
that
were
listed
on
this
session.
X
Ali
Rezai
key
Nokia.
Thank
you
very
much
for
making
this
presentation
and
I
look
forward
to
working
with
you.
I
think
it
will
be
very
important
to
get
the
definitions
right,
define
a
scope
and
also
look
into
use
cases
where
it
makes
sense
to
be
handled
by
the
IETF
here.
Thank
you.
I
look
forward
to
working
with
you
if.
Y
Y
One
page
to
be
reasonably
sure
that
it's
not
itself
compromised
so
that
it
can
set
up
at
rest,
environment
and
just
relationship
with
a
server,
for
instance
the
one
it's
loaded
wrong,
so
that
a
question
of
who
is
the
endpoint
and
who
is
it
that
we
are
assuming
these
are
being
secure,
jumps
around
a
lot
even
within
a
single
application,
so
I
think
assumption.
2
is
really
able,
but
you
have
to
shrink
the
definition
of
the
endpoint
down
from
everything
that
is
beyond
the
network
interface.
To
think
that
is
a
bit
smaller
than
that.
Y
Z
L
Right
Eric
rajala
yeah,
like
we
were
30
52,
we
weren't
like
unaware,
without
any
viruses
or
malware
or
like
she's,
got
compromised.
I
appreciate
that
people
are
fixating
on
this.
This
point
at
the
Internet,
throw
at
all
the
the
section
at
the
endpoints
being
compromised,
I'm
prepared
to
concede
it
may
be
in
artfully
written,
but
the
point
there
actually
a
still
stands,
which
is
that
when
you
want
to
build
a
concept
protocol,
if
you
assume
the
other
side
is
compromised
at
the
end
of
the
day,
you're,
not
in
a
very
good
shape.
L
That
doesn't
mean
that
you're
not
doesn't
mean
you
can't
be
talking
to
an
attacker,
but
it
means
that
it's
that
it's
very
hard
design
security
protocols
that
protects
you
in
the
face
of
the
actual
counterparty
you're
trying
to
talk
to
I've
been
compromised
and
worse.
And
it's
really
true
that
the
ideas
about
that
have
expanded
over
the
years
in
terms
of
P,
FS
and
PCs
and
stuff
like
that,
but
nevertheless
that
still
is
largely
correct.
So
I,
certainly
it
seems
like
interesting
work
and
you
know
certainly
I
think
we
could
try
to.
L
You
know
Easter,
as
we
discussed
a
lunch,
expand
some
of
the
notions,
the
endpoint
or
expand
in
some
cases.
Contracting
others
by
just
I
do
want
to
resist
the
idea
to
like
somehow
like
we
were
so
dumb,
but
we
didn't
understand
like
machines
to
be
compromised.
That's
really
not
the
case
and
there's
like
an
entire
section
about
DD
about
dose
and
D
us
in
here.
So
it's
something
about
the
case.
We
didn't
understand
that
you
could
have
a
compromised
machines
in
the
internet,
yeah.
S
AA
AA
Security
management
work
is
to
solving
these
broader
problems
and,
instead
of
actually
shrinking
the
definition
of
an
endpoint
I
think
we
should
actually
expand
the
definition
of
an
endpoint
to
ensure
that
we
are
providing
all
of
the
management
capabilities
that
can
provide
for
a
a
more
hardened.
You
know
internet
infrastructures
in
the
middle,
as
well
as
on
the
ends
near
to
some
degree.
This
is
about
getting
away
from
the
walled
garden
mentality
of
of
looking
at
you
know,
security.
J
J
Got
the
feedback
that
people
considered
that
security
should
only
be
done
on
the
inputs
of
the
communication,
so
we
said
why
don't
we
stop
on
that
and
try
to
understand
what
we
are
talking
about
sort
of
endpoints?
What
is
it
about
the
setup
model
and
we
made
an
internet
draft
called
capabilities
and
limitations
of
endpoint
security
solutions
with
the
intention
to
simply
codify
and
put
words
on
on
that?
That's
called
class
by
the
way
I
have
a
sign
meaning
at
4:00
p.m.
in
color.
J
If
people
want
to
go
there,
we
got
a
lot
of
feedback
and
and
and
the
thing
is
that
we
realized-
we
got
a
number
of
lessons.
First
of
all,
I
thought
that
this
was
not
good
value,
because
since
we
are
doing
endpoint
Security's
in
30
years,
everything
should
have
been
written
on
the
topic
so
first
surprise
one.
We
had
no
taxonomies
on
endpoints.
Second
surprise:
the
best
we
could
find
on
the
threat
models
was
my
tree
attack
and
we're
still
asking
ourselves.
Is
it
the
right
model
for
us
to
describe
what
we
need?
J
J
Do
you
ever
remodel
by
which
to
secure
the
endpoint?
You
need
a
nitro
computer
on
each
side,
so
we
have
to
answer
a
number
of
questions
here
as
well
in
your
in
your
draft.
First,
if
you
make
a
good
point
on
social
attacks,
and
so
the
question
is,
this
is
not
an
attack
on
the
device.
This
is
an
attack
on
the
brain.
So
do
you
include
the
person
in
the
endpoints
or
not,
because
this
will
matter
a
lot.
There
is
an
attack
on
the
brain
on
the
UX
even
before
you
are
so
anyway.
J
The
summary
is
that
we
have
done
some
work.
It's
expanding.
We
have
a
program
for
that.
We
discussed
this
afternoon.
We
think
it
makes
sense.
I,
don't
know
how
you
want
to
tie
it.
I
think
I
have
more
typhus,
Jerry's
work
because
I,
it's
more
aligned
with
what
I'm
trying
to
do,
and
maybe
it's
a
full.
So
we
are
happy
to
contribute
happy
to
continue
to
work
on
that
whatever
stuff.
So
please
keep
doing
so.
S
D
Stephen
Elliott
here,
first
of
all,
nice
presentation
and
a
couple
points
as
a
scientist
statement.
I
think
maybe
worth
still
reviewing
3552
to
see
if
there's,
if
it
should
be
dusted
off
and
and
some
stuff
being
looked
at
from
Security's
consideration,
standpoint
I
know
you're
growling
the
room,
but
yes,
you
know
they're.
Definitely
time
has
moved
on.
We
probably
should
at
least
take
a
stare
at
it.
D
Well,
here's
you
know:
here's
the
mess
we're
in
and
here
are
some
solutions
that
we
can
get
to,
which
leads
to
a
question
which
is
suppose
we
get
to
this
Internet
threat
model
and
let's
posit
a
world,
maybe
in
which
heap
and
rats
aren't
quite
there.
Yet,
what
sort
of
formalisms
would
you
envision
addressing
a
threat
model
that
you
would
propose
like?
Would
there
be
protocol
approaches
that
you
you
could
envision?
That
would
answer
some
of
the
threat
models
that
that
would
address,
and
how
would
how
would
you
envision
it
apply
to
the
IETF
and.
S
Mostly
I,
don't
know,
I
mean
I,
think
some
some
there
has
been
some
suggestion
and
chats
with
other
people
that
maybe
there's
there
needs
to
be
some
kind
of
descriptions
of
different
threat
models
that
might
apply
in
different
kind
of
protocol
contexts
in
terms
of
what
kind
of
formalism,
if
any,
like
formal
formalism
would
be
use.
I,
don't
know,
but
there's.
V
Your
nuts
could
be
si
yeah,
like
you,
just
kind
of
lit
it
to
you
with
different
threat
models
for
different
applications.
I
believe,
that's
basically
the
point
where
we
gotta
get
you,
because
what
you
asked
in
your
presentation
is
it
worth
to
get
to
one
consensus,
I,
believe
it's
not
quiet
because,
like
I
said
it's
incredibly
difficult
to
design
protocols
when
I
can't
trust
the
other
party
at
all,
and
that's
basically
the
case
when
the
other
party
is
arbitrarily
modified
by
anyone.
V
That's
not
on
my
control,
so
I
believe
it
would
be
awesome
to
have
such
a
thread
model,
but
I
believe
it's
also
worth
considering
to
have
like
multiple
steps
in
between
that
are
pretty
codified,
so
that
we
have
a
decent
way
of
talking
what
kind
of
threat
model
we're
building
against
and
where
I
have
a
common
language
on
deciding
what
we're
talking
about,
without
defining
a
given
threat
model
for
every
single
individual
protocol
and
standard,
but
still
getting
far
towards
multiple
use
cases.
Yeah.
L
L
In
other
words,
it
seems
to
me
that
across
the
IETF
over
the
past,
let's
say
five
years,
there
has
been
a
revolution
in
the
way
that
we
think
about
security
and
we've
seen
a
wide
variety
of
security
innovations
that
take
a
new
perspective,
one
one
that
is
apparent
to
me:
a
certificate
transparency.
It's
a
very
powerful
approach,
that's
very
different
from
the
way
that
I'm
used
I
was
used
to
thinking
about
security
five
or
ten
years
ago.
L
So,
rather
than
thinking
about
this
as
an
exercise
in
developing
a
new
threat
model,
I
think
it
might
be
more
conservative
but
possibly
easier
to
think
about
it
as
collecting
and
summarizing
the
new
threat
models
that,
as
a
community
we
are
and
in
harmonizing
the
the
new
threat
models
that
as
a
community,
we
have
developed
and
really
advanced
a
lot.
That's.
AB
I'm
lawrence
lund
blade
I
co
as
a
co-author
of
the
eat
draft
in
the
rats
working
group.
I
haven't:
read
your
drafts
just
so
I'm
just
going
off,
but
I've
heard
here,
but
a
lot
of
the
discussions
been
around
compromise
and
I
think
my
I
think
of
it
differently,
as
what
you
really
want
to
know
is
who
implemented
this
thing
and
did
they
do
a
good
enough
job
so
that
it
will
not
be
compromised
because
you
can't
really
detecting
compromise
and
trying
to
do
that?
AB
That's
kind
of
hard,
but
if
you
can
find
out
who
implemented
something
you
know
dedicate
the
the
implementer
find
out
and
think
will
nourish
trusted.
That
gives
you
a
leg
up
like
okay
I'm,
going
to
trust
talking
to
these
guys,
but
not
those
guys.
So
I
basically
trying
to
suggest
a
different
way
of
thinking
a
little
bit
way
of
thinking
there
and
really
what
that
is,
is
kind
of
a
definition
of
attestation.
I
think
lots.
AB
Z
Marty
so
Mountain
Thomson
I've
been
enjoying
watching
the
the
three
conversations
or
four
conversations
layered
on
top
of
each
other
here
and
I
wasn't
going
to
get
up.
Then
you
do
cuz
I'm
on
the
IV
and
we've
already
had
this
conversation,
and
you
don't
need
that
that
input,
but
I
think
it
would
be
helpful
for
this
conversation
here
to
sort
of
make
clear
that
there's
a
number
of
different
conversations
going
on
here.
Z
There
have
been
some
evolutions
in
the
way
that
we
understand
how
that
how
that
operates
such
that
we
might
want
to
put
balance
on
the
the
extent
to
which
we
believe
that
to
be
true
and
and
there
I'm
talking
about
things
like
the
Pearson
and
whatnot.
But
it
seems
to
me
that
the
discussion
that
the
workshop
and
the
drafts
is
is
pointing
out
is
something
else
which
is
that
we're
talking
about
alignment
of
incentives.
More
than
anything
else,
previous
speaker
talked
about
attestations,
which
is
another
thing
entirely,
which
I
hadn't
really
considered.
Z
Z
Without
that
information
once
they've
got
it
and
and
maybe
they're,
maybe
there
aren't
necessarily
any
alignment
of
incentives
between
what
I
want
and
what
they
want
to
do
with
that
information,
and
that's
one
of
the
major
failings
of
the
web
as
we
have
today
so
thinking
about
what
you
want
to
do
with
this
work
in
either
the
first
context
or
the
second
is
probably
what
we
need
to
do
and
being
very
crisp
about.
That
would
be.
M
Q
Q
What
I
don't
see?
Maybe
you
can
shed
some
light,
as
is
where,
with
the
idea
of
contribute
to
this,
because,
for
example,
Dave
Taylor
provided
some
examples
on
current
activities
that
don't
make
this
assumption
that
you
previously
cited,
and
on
the
other
hand,
it
very
much
makes
those
assumption
just
for
a
smaller
subset
of
in
point
like
talking
about
the
secure
world
being
secure
rather
than
the
rest,
and
the
OS
case
is
not
too
different,
and
so
the
IDF
is
in
a
business
of
providing
sort
of
protocols
for
interoperability.
Q
Q
Writing
things
up
is
like
write
a
book
about
it,
yeah
that
would
be
cool,
nice
pictures
and
everything
yeah,
but
that's
not
that's,
not
really
getting
anywhere
correct.
S
Q
S
S
Guess
we've
had
some
cases
taking
not
only
thinking
about
use
cases
but
abuse
cases.
For
example,
I
think
that
is
a
defensible
thing
that
you
could
say.
This
is
something
that
you
could
argue
that
should
be
part
of
a
PCP
in
the
IETF
somewhere
and
it's
a
good
exam,
but
maybe
more
maybe
it
maybe
just
will
fail.
I,
don't
know
Gary
I
guess.
Does
it
ago,
yeah.
AC
Yeah
so
I
just
wanted
to
into
tech
slightly
and
say
that
yeah
this
is.
This
is
really
hard.
What
Stephen
said
is
correct
that
we
need
to
move
forward
and
and
have
some
advice
that
would
actually
be
useful
for
for
ITF,
but
I
do
think
that
there
are
some
things
that
that
you
can
take
into
account.
So
I've
certainly
personally
done
that
in
in
recent
work,
you
know
adding
BFS
to
my
you
know,
protocols
that
don't
have
that
thinking
about
system
architectures,
where
I'm
spreading
some
information
for
too
many
nodes
when
I
could
have.
AC
You
know,
kept
it
to
need-to-know
basis
I,
you
know
looked
at
things
where
we
were
sending
information
to
centralized
parties
in
the
internet
where
we
perhaps
wouldn't
need
to
and
so
on.
So
there
are
things
that
we
can.
We
can
take
into
account
at
the
IETF
work.
Also,
at
least
that's
that's
my
experience
that
doesn't
solve
everything
under
the
Sun,
but
maybe
a
little
bit
helping
and
if
I
could
add
cuz
I.
A
Can't
get
one
of
us
has
to
be
up
here
so
I'll.
Take
my
privative
I
mean
it's
about
residual
risk.
It's
not
there
that
the
ITF
can
address
cut
of
all
of
those,
but
the
ability
to
kind
of
document
those
put
them
out
there.
Then,
when
folks
take
IETF
protocols
and
they
compose
them
with
other
things
that
we've
reminded
them
that
they
need
to
consider
this
in
the
integration
process.
AD
Daniel
can't
go
more
a
cou,
so
I'm
happy
that
we're
having
this
discussion
I'm
a
little
bit
concerned
about
the
idea
of
the
ITF
trying
to
figure
out
how
to
reach
into
the
endpoints
themselves
and
do
a
lot
of
stuff
on
the
endpoints,
because
I
think
we
haven't
been
very
good
at
doing
that.
It
doesn't
mean
that
we
maybe
shouldn't
try,
but
I.
AD
Would
I
can
imagine
folks
who
work
on
the
endpoints
being
territorial
about
that,
but
one
of
the
things
that
I
think
I
don't
think
it's
just
about
the
network
transmission
stuff
versus
the
endpoint.
Have
a
lot
of
sympathy
with
ecker
said
about
it's
difficult
to
design
a
communications
protocol
where
you
assume
the
other
party
is
malicious.
But
the
thing
that
I
think
is
missing.
There
is
the
sense
of
time,
perhaps
about
what
happens
outside
and
around
the
protocol.
AD
So
when
I
think
about
that
I
think
of
things
like
link
ability
right
where
the
where
I
may
want
to
interact
with
the
third
with
this
external
party,
but
I
want
to
make
sure
that
that
interaction
is
distinct
from
other
interactions
that
I've
had
with
that
same
party,
and
so
there
there
is
a
there's,
a
there's,
a
gap
there
and
I
think
thinking
about
it.
In
terms
of
time,
maybe
more
than
transmission
versus
endpoints
might
be
a
useful
frame.
Sure.
AE
AE
It's
very
critical
I
do
fully
support
it,
and
even
if
that
means,
at
the
end
of
the
day
that
COMSEC
protocols
have
a
section
in
there
on
risk
management
for
operational
security
to
help
illustrate
what
this
means
and
help
people
you
know
put
this
into
their
risk
profile
when
they're
doing
risk
management
in
a
large
enterprise
or
a
large
organization.
I
think
it's.
It's
really
important.
I
do
support
it
and
thanks
for
doing
the
work
you
know
for
you
and
Dominique.
Both
graphs
were
great.
Some
things.
D
We
may
not
need
to
try
and
reach
into
the
end
point
with
what
we're
doing,
but
we
could
think
about
you.
Maybe
there's
not
just
a
single
end
point
you,
maybe
there's
multiple
different
layers
on
the
end
point
with
things
that
have
different
layers
and
trusts
that
are
implemented
more
robustly,
that
you
are
potentially
more
susceptible
to
being
controlled
by
an
attacker,
and
we
might
want
to
think
about
things
in
time.
D
You
know
what,
where
the
broader
effects
of
what
we're
doing
over
time
and
and
just
to
sort
of
recognize
that
we
have
not
just
a
binary
black-and-white
situation.
We
might
be
talking
to
someone
who
we
trust
to
correctly
implement
their
software
and
to
correctly
in
from
the
protocol,
but
as
Marie
was
saying
to
house
a
misaligned
incentives.
So
you
know
it's
not
like
we're
talking
to
a
completely
adversarial
relationship
and
so
there's
some
things
that
we
can
do
with
them.
L
I've
been
said
of
number
of
things
that
I
wanted
to
say,
so
thank
you,
I
also
on
district
Oh,
wiki
tikis,
you
just
said
I
think
one
thing
35
seats,
you
just
quite
a
bad
job
of
he's
sort
of
on
privacy.
Now
it
wasn't
really
sort
of
like
being
at
the
time,
but
no
it
doesn't
do
a
good
job
at
all.
Recognizing
the
ways
in
which
our
protocol
is
great
privacy,
risks,
and
especially
the
way
in
which
sort
of
large-scale
use
of
these
protocols
crates.
L
You
know
the
addition
of
us
of
a
you
know,
a
very
small,
a
large
set
of
small
individual
privacy
risks
together
a
create
a
real
problem.
So
I
think
that
would
be
something
which
really
would.
L
Some
from
something
I'm
not
quite
sure
what
that
would
be,
but
if
there
you
know
I,
don't
think
we
really
had
the
notion
at
a
time
that
sort
of
high
dimension
high
dimensional
likes,
you
know,
sparse
data
sets
were
just
such
a
big
problems
that
turned
out
to
be
and
so
having
something
and
as
Arvind
remind
just
basically
yesterday.
So
that's
something
which
I
think
really
would
be
nice
to
him.
AG
Hurt
occur,
I
say
you
already
know
I'd
like
this
work.
If
you
had
that
conversation,
I
really
missed
the
days
where
I
could
open
a
socket
to
a
port
less
than
1024
and
know
it
was
going
to
be
secure.
That
was
awesome,
come
a
long
way
since
then,
and
and
been
said
exactly
actually
a
lot
of
what
I
was
gonna
say
and
that
the
in
society
we
have
this
notion
of
elevated
trust
and
and
as
we
negotiate
and
as
we
as
we
communicate
with
somebody,
our
level
of
trusting
them
comes
up.
AG
I
think
there's
a
few
AV
documents.
Gonna
come
up
talking
about
that
as
well,
but
we're
missing
that
in
the
protocol
space
and
and
yet
we
users
do
this
all
the
time
right.
When
you
log
into
a
website
frequently
you
don't
log
in
first
I
was
just
doing
some
United
searches
a
second
ago
right.
They
didn't
ask
me
for
my
password
and
talked
out
to
the
point
where
it's
time
to
commit
I.
Also,
remember
back
in
the
day,
is
read:
go
to
HTTP
sites
and
use
them
for
a
long
time.
AG
Then
it's
like,
you
had
to
submit
your
credit
card
and
a
lot
of
times.
They
didn't
even
put
the
submit
your
credit
card.
You
know
number
in
and
until
you
you
just
said
trust
me,
the
following
link
will
go
to
a
secure
site,
but
we
have
this
notion
and
people
have
this
notion
of
elevated
trust.
All
the
time
companies
ask
of
us
all
the
time
now.
AG
I
need
your
two
factor
authentication
before
it
didn't
why
we
don't
build
that
into
sort
of
even
more
based
protocols,
I
don't
know,
and
why
we
don't
assume
that
maybe
both
sides
need
some
swim
set
of
elevated
trust
because
they're
certain
sites,
I,
certainly
won't
give
a
credit
card
to
you,
even
though
I
may
go
browse
to
them.
I.
AH
You
STP
from
and
CSE,
so
thank
you
for
revisiting
this
topic.
I
think
it's
very
important
topic
generally
and
I've
heard
a
lot
of
discussion
in
the
my
client's
about
endpoint
security
and
considering
different
types
of
endpoints
and
classifying
them
and
stuff
and
I
would
just
like
to
highlight
again
the
class
draft.
That
is
an
individual
submission
at
the
moment
which
talks
about
the
capabilities
and
limitations
of
endpoint
security
solutions.
AH
So
before
we
read
you
that
work
I'd,
just
like
to
direct
people
to
that
and
and
I
would
also
say
that
sorry
I
mean
and
I
would
also
say
that
there's
another
draft
that
goes
with
that.
That's
also
got
class
in
the
name
that
talks
about
a
taxonomy
so
that
you
can
describe
these
endpoints
different
name.
Different
endpoints
have
different
characteristics,
and
so,
when
you
are
connecting
them,
you
can
expect
different.
Behavior
and
I
just
wanted
to
highlight
that
again
before
any
work
in
that
same
space,
just
gets
redone
under
a
different
name.
O
Paul
Turner
in
the
definition
of
thing,
1
and
thing,
2
and
I
understand
it
thing
to
now
is
in
flux.
Where
would
you
place
the
IETF
protocols
or
the
communication
mechanism
that
they
enable
being
used
as
an
attack
on
the
endpoint
to
compromise
an
employment?
So
so
you've
got
the
endpoint
assuming
to
be
compromised,
but
if
the
network
is
being
used
in
the
protocols
Europe
being
used
as
part
of
that
communication,
it
you
you
considered
that
as
part
of
the
money
well.
S
I
I
think
probably
mostly
not
unless
there's
some
technical
detail,
that's
kind
of
interesting,
but
you
know
I
can
send
you
an
email
that
that's
threatening
that
doesn't
mean
there's
anything
wrong
with
RCA
22
and
its
derivatives,
and
so
so
III.
My
initial
reaction
would
be
I,
can't
think
of
a
way
in
which
we'd
end
up
there,
but
maybe.
O
S
Clearly
I
mean,
if
you
know
if
90f
protocol
enables
a
better
DDoS
reflection
attack
because
of
packet
sizes
or
something
that
definitely
is
something
we
need
to
consider
and
I'm,
not
sure
as
to
whether
the
fact
that
we
turn
on
encryption
makes
things
bad
is
a
possible
thing
that
we
should
be
contemplating
here.
If
that's
what
you
meant,
but
maybe
it
wasn't
well.
O
No,
but
if
we're
thinking
about
the
point
that
the
endpoint
can
be
compromised
and
this
body
focuses
on
communications,
is
it
important
to
look
at
what
contribution
does
the
communication
have
to
compromising
at
endpoint
as
part
of
that
threat
one?
So
just
it's
again
something
they
to
consider
as
part
of
what's
been
a
pretty
broad,
you
know
view
which
I
appreciate
sure.
AB
Laura
and
slim
blade
thinking
about
maybe
breaking
thing
to
down
into
thing
to
a
and
thing
to
B
or
thing
to
a
is
the
equipment.
Software
and
implementation
is
to
do
something
and
thing
to
be:
is
the
service
or
the
the
entity
that's
actually
operating
stuff,
so
I
believe
the
attestation
and
what
we're
going
after
in
rats
and
eat
his
thing
to
a
it's
the
implementation.
AB
The
equipment
and
the
implementations
could
be
great,
but
the
guy
that's
operating
the
service
is
selling
it
out
the
back
room
to
somebody
else,
or
he
forgets
to
do
software
updates
or
something
like
that.
So
that's
really
more.
That
almost
seems
like
server,
auth
or
service
off,
which
is
I,
consider
quite
different
from
attestation
and
I
think
we're
gonna
I'm,
hoping
rats
and
eat
stays
away
from
the
service
part
and
just
sticks
to
the
implementation.
Part.
Okay,.
AI
Kakoton
I
just
want
to
try
and
attempt
to
and
clarify
about
all
the
previous
presenters
Ming
was
trying
to
say
I,
don't
think
necessarily
it
was
work
that
should
be
done,
but
probably
the
idea
is
that
here
we
have,
we
assume
the
end
system.
Engaging
protocol
is
not
being
compromised,
I
think
there's
like
a
third
assumption,
which
is
that
I
am
NOT
an
attacker.
The
person
sending
the
transmission
so
so
I
think
so
the
consideration
is
an
example.
You
said,
like
you
know,
why
would
you
think
encryption
is
a
bad
thing?
AI
I,
don't
think
anybody
wants
to
say:
hey,
encryptions,
bad,
let's
stop
doing
it,
but
then
it
does
has
negative
security
impacts
as
well
as
positive
I.
Think
yesterday,
they're
mentioning,
for
example,
researchers
can't
see
why
ot
devices
are
doing
because
it's
all
encrypted.
So
then
it
has
privacy
implications.
You
have
devices
now
sending
your
data
out
to
who
knows
where
and
you
don't
know
because
everything's
encrypted.
No,
that
doesn't
mean
we
should
stop
encrypting
things
doesn't
mean.
Maybe
even
we
should
think
about
this,
but
I
think
that's
the
general
concept
and.
Q
I
was
trying
to
get
in
there
because
I
feel
increasingly
uncomfortable
in
that
discussion,
because
it
started
off
with
to
me
like
okay,
there
challenges
with
endpoint
security,
but
I,
hear
people
saying,
oh
that
be
the
reason
why
we
then
man-in-the-middle
our
existing
protocols
to
make
things
even
worse,
but
I
I
would
like
to
offer
an
alternative
on.
As
you
know,
I
work
for
arm,
and
we
also
have
our
friends
from
Intel
in
the
room.
Q
We
constantly
increase
or
add
features
to
hardware,
providing
extra
security
features
and,
of
course,
it's
a
it's
a
race
against
lots
of
the
attackers
who
are
very,
very
motivated,
commercially
funded,
etc,
etc.
But
we
will
definitely
appreciate
support
from
also
from
this
community
in
making
use
of
those
hardware
security
mechanisms.
We
have
lots
of
open
source
projects
and
I
can
send
pointers
to
the
list
on
what
we
do
and
if
some
of
you
guys
who
care
so
much
about
security,
want
to
improve.
Endpoint
security
help
us
to
improve
some
of
the
operating
systems.
Q
S
AJ
I'm
Debbie
Cooley
from
NSA
I'm
gonna,
take
you
out
of
the
weeds
and
back
up
to
the
space
where
you
belong
here,
so
determining
what
threat
is
is
applicable
to
the
system.
You're
in
depends
on
what
you
have
purview
over
right,
so
you
have
access
to
this
space
and
you
need
to
consider
the
threats
that
are
applicable
against
that
space.
AJ
You're
begun
to
reach
into
the
endpoints
in
the
IETF,
where
you
perhaps
haven't
in
the
past,
and
so
the
endpoint
now
comes
into
the
into
the
purview
where
it
may
not
have
been
in
the
purview
before
so
you.
It
needs
to
be
a
holistic
look
at
threat
to
base
on
what
the
system
is.
The
attacker
is
always
going
to
be
one
up
on
you
always
right,
because
you
have
to
protect
everything
and
he
just
has
to
attack
the
thing.
That's
the
easiest
and
he
wins
right
at
that
point.
AJ
So
you
have
to
spread
your
resources
out
amongst
the
whole
thing
and
he
gets
to
pick
the
one
thing
that
you've
missed
right.
So
the
first
thing
you
need
to
decide
is
exactly
what
your
space
is.
What
part
does
the
ITF
have
the
most
ability
to
affect,
and
then
you
design
your
threat
documents,
your
threat
statement
of
threat
to
meet
that?
If
you
want
to
delve
into
the
endpoint
security
case,
which
you
have
already
started
to
do,
then
that
comes
into
it
and
then
thing
two
becomes
part
of
the
game.
Yeah.
S
AJ
AJ
S
So
one
of
the
things
in
discussing
this
we
we've
been
talking
about
but
haven't,
come
to
something
some
definition
of
is
maybe,
if
you
think
about
this
as
a
protocol
between
multiple
parties,
if
they're
all
compromised,
probably
it's
game
over,
but
if
one
of
them
still
isn't
maybe
there's
something
we
can
do
better
than
we're
doing
there.
So.
AB
AJ
S
J
So
today,
your
game
so
from
Symantec,
so
I
think
it's
very
clear
that
if
you
have
a
prime
of
just
naming
stuff,
so
somebody
said
what
is
the
common
language
to
discuss?
What
is
an
endpoints?
Actually,
it's
even
worse,
we
don't
have
a
long
way
to
describe
an
attack,
surface
internal
attack,
surface
external
attacks
from
other
forces.
We
don't
have
a
model
to
describe
the
attacks
and
then
back
to
the
gentleman
from
arm.
I.
Think
that
very
good
points
they
are
doing
stuff
on
the
yard,
where
people
are
doing
stuff.
J
J
What
does
it
mean
for
protocol
designers
I'm
too
young
here
to
discuss
that
the
only
thing
I
can
offer
so
the
work
we're
doing
with
mark
over
there
is
try
to
put
words
on
things
so
that
at
least
we
start
from
the
same
baseline
and
I
promise
you
it's
already
very
hard.
So
if
you
are
interested,
please
help,
but
at
the
same
time
please
you
and
Jerry
give
us
input
what
you
need
from
us.
I
don't
know.
Maybe
we
have
a
way
to
find
a
good
collaboration,
mother,
Thank,
You.
AK
AK
So
if
there's
some
sort
of
change
and
your
posture
assessment
or
system
hygiene,
whatever
phrase
you
want
to
use
in
the
sacrum
sense
and
that
can
be
signaled,
you
can
detect
and
then
thwart
an
attack
before
either
privilege
escalation
happens
or
lateral
movement
within
a
network
happens,
and
so
you
know
the
detection
piece
is
something
we
should
consider
right.
So
you
may
not
keep
your
system
completely
secure
but
being
able
to
detect
that
attacker
and
thwart
them
as
quickly
as
possible.
AK
You
can
look
at
like
Lockheed
Martin,
kill
chain
or
a
mitre
attack,
and
it
does
benefit
you
to
catch
them
early
and
and
that
work
has
has
made
a
lot
of
progress
in
recent
years
because
the
time
to
detect
the
tax
has
gone
way
down,
and
it's
it's
really.
You
know
detecting
change.
So
if
we
could
put
more
energy
into
things
like
stack
them
and
make
it
really
work
and
rats,
I
think
those
would
be
big
gains
and
would
help
against
you
know.
AK
AL
Just
following
the
previous
comment
about
ITF
workspace,
so
historically,
ITF
has
been
the
space
that
we've
been
focusing
on,
identifies
and
proof
of
possession.
So
all
the
way
from
ISO,
Camp,
Eggers
Iran,
then
Hawkins
doing
iv1
right,
IPSec,
everything's,
but
I.
The
only
way
I
can
prove
Who
I
am
is
possession
of
privacy
I
think
we
should
extend
that
to
proving
my
state.
So
if
I'm
talking
to
you
this
up,
besides
showing
you
showing
me,
your
proof
of
possession
show
me
also
proof
of
State,
and-
and
this
is
what
the
rats
people
are
doing.
AL
S
For
me,
it's
not
clear
how
broadly
applicable
some
of
these
things
are,
but
I
think
there.
Definitely
you
know,
inputs
that
need
to
be
looked
at
and
stay
and
yeah
there's
bits.
Probably
that
are
cropping
up
all
over
the
place
that
are
relevant
is
yeah
and
so
I
guess
we
have
a
mailing
list.
It
sounds
like
we
have
a
thousand
opinions
so.
A
Even
yari
Brian
Ted,
thanks
for
bringing
this
to
us,
we'll
continue
talking
it's
great
that
we're
thinking
and
taking
fresh
eyes
on
the
problem
and
Steven.
There
will
be
a
mailing
list
coming
where
we
can
continue
to
discuss
this,
we'll
post
something
to
sag.
So
we
can
continue
this
all
on
a
dedicated
vehicle,
okay,
so
timewise
we're
now
in
the
Open
Mic
portion.
Anything
you
want
to
talk
about
come
on
up.