►
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Deep Dive: TUF What's New With TUF? - Marina Moore, NYU & Trishank Kuppusamy, Datadog
This talk will dive into exciting new and upcoming features in The Update Framework (TUF) specification, a framework for secure software updates that has been implemented across the could native space through the Notary project. The talk will discuss features that have been added to make TUF more flexible and usable to support new implementations, including adoption by the Python Packaging Index (PyPI). If you are interested in TUF or cloud native security, join us for some in-depth technical descriptions, security analysis, and to get involved in TUF.
https://sched.co/cpBE
A
B
Hi
thanks
thanks
thanks
marina,
so
I
used
to
work
at
nyu
on
tough
with
with
marina
too
and
with
our
advisor
justin
capos,
and
where
particularly,
I
did
my
research
on
a
fork
of
tough
call
update,
which
is
software,
securing
software
updates
for
ground
vehicles.
So
that
was
a
lot
of
fun
and
now
I'm
a
staff
security
engineer
at
datadog.
A
Okay,
so
let's
get
started,
I
think
we'll
get
started
with
a
bit
of
background,
brought
tough
and
then
go
into
kind
of
some
of
the
current
evolution
of
the
project.
So
here
we
go
go
so
first
of
all
go
a
bit
into
the
problem
that
tuff
is
solving,
so
software
updates
are
a
really
key
feature
for
security
of
applications.
A
So
the
goal
of
tough
is
to
provide
compromised
resilience.
It's
basically
impossible
to
prevent
every
single
repository
compromise
every
to
basically
to
close
every
single
security
hole
your
application
could
ever
have
so.
Instead,
what
we
try
to
do
is
have
compromised
resilience
so
that,
if
the,
if
and
when
your
repository
is
compromised,
be
able
to
detect
that
compromise
and
recover
from
it
in
a
secure
way
to
to
minimize
the
impact.
A
So,
to
do
so,
we
present
the
update
framework
are
tough,
so
a
bit
of
background
about
the
terminology
we'll
be
using
in
this
talk.
So,
first
of
all,
we
talk
about
this
thing
called
repository
and
repository
compromise,
and
what
what
we
mean
by
repository
is
the
entity
that
contains
your
images
and
metadata
and
in
the
context
of
oci.
This
is
actually
like
the
registry,
the
oci
registry,
rather
than
a
container
repository
in
that
context.
A
But
on
this
repository,
what
you
have
is
an
image
which
is
kind
of
the
smallest
unit
of
an
update.
This
is
the
thing
that
you
want
clients
to
install
and
and
run
on
their
on
their
program,
and
you
also
have
some
metadata,
which
is
kind
of
information
about
these
images
or
about
other
metadata
files,
and
this
metadata
can
contain
things
like
cryptographic,
caches
file,
sizes
version,
numbers
signatures.
A
Anything
like
that,
okay,
so
we're
going
to
present
the
update
framework
and
the
goal
of
this
framework
is
to
provide
authenticity
and
integrity
even
in
the
event
of
a
repository
compromise,
and
to
do
so
it's
based
on
a
variety.
It
uses
a
variety
of
design,
principles
that
are
baked
in
from
the
ground
up
in
order
to
achieve
these
goals
and
I'll
focus
on
a
few
of
these
in
the
next
few
slides
for
more
information
about
tough
and
the
kind
of
the
problem
that
it's
solving.
A
A
So
tuff
does
this
through
the
use
of
four
different
key
roles,
and
each
of
these
roles
is
responsible
for
signing
different
pieces
of
metadata
on
the
on
the
repository
so
I'll
go
through
each
of
those.
First,
we
have
the
targets
role,
which
is
if
this
contains
information
about
the
images
themselves.
So
this
is
what
you,
when
you
think
about,
like
cryptographic,
hashes
and
file
sizes
and
other
information
about
the
actual
images
that
you
want.
A
People
to
install
and
one
of
the
cool
features
of
tough
is
that
the
the
targets
role
can
actually
be
split
into
multiple
different
roles.
Each
one
can
delegate
trust
to
other
roles
so
that
there
isn't
even
a
single
entity
in
charge
of
signing
every
single
image
on
the
repository
that
can
also
be
further
separated.
A
A
It
tells
the
client
which
keys
to
trust
for
all
these
other
roles
and
it's
kind
of
the
root
of
the
security
for
the
system
and
because
of
the
way
this
is
all
separated
into
these
different
pieces.
The
root
role
can
be
protected
even
more
strongly
than
the
other
roles,
and
it
can
be
updated
less
frequently,
which
means
that
you
can
maintain
this
higher
level
of
security
yeah.
That's
the
those
are
all
the
different
pieces
that
come
together
to
get
the
separation
of
duties.
A
A
Finally,
we
have
minimizing
risk
through
the
use
of
offline
keys
so
because
of
the
separation
of
duties,
things
like
the
root
world
can
be
updated
less
often,
which
means
that
you're
able
to
assign
them
with
offline
keys
and
these
keys
can
never
be
stored
in
a
way
such
that
they
can
never
be
excess
accessed
on
the
internet.
So
you
can,
you
know,
use
them
offline
and
then
you
know
put
them
on
a
in
a
device
and
put
that
in
a
locked,
safe
somewhere.
A
A
And
finally,
tuff
supports
the
diversity
of
cryptographic,
algorithms,
which
means
that
you
can
use
first
of
all,
any
algorithm
that
you
would
like
in
your
system
and
also
multiple
different
algorithms
for
things
like
signing
and
hashing,
so
that
your
system
is
secure.
As
long
as
at
least
one
of
these
algorithms
is
secure,
which
is
very
likely
to
be
true,
and
this
even
allows
you
to
use
things
like
post
quantum
crypto
or
any
other
new
crypto
techniques
as
they
are
as
they
come
forward,
and
those
will
still
be
able
to
work
within
this
system.
B
Great
thanks
thanks
marina,
so
yes,
let's
talk
about
so
now
that
marina
has
presented
about
how
tough
roughly
works,
especially
in
the
context
of
container
image
registries
or
even
any
other
artifact.
You
like,
let's
talk
about
where
we
are
now
where
we're
going
next
next
slide.
Please
thank
you.
So
the
first
good
news
is
that
we
graduated
on
the
cncf
project.
We
were
accepted
into
it
in
2017
and
I'm
very
very
pleased
to
say
that
we're
the
ninth
project
to
graduate
after
so
many
other.
B
You
know
preliminary
projects
we're
also
the
first
one
to
get
the
best
practices,
cii
badge
for
silver
badge
and
we're
working
hard
to
get
the
gold
batch,
hopefully
coming
next,
a
huge
thanks
to
all
of
our
contributors.
We
could
not
have
done
this
without
you,
so
thank
you,
and
so
let's
talk
about.
Let's
talk
next
about
some
deployments,
all
and
new,
I
think
all
of
you
are
probably
most
familiar
with.
B
The
next
interesting
development
is
something
called
cloud
native
application,
bundles,
which
we
believe
will
interest
a
lot
of
you.
In
particular,
it's
a
package
format
to
facilitate,
facilitate
the
bundling,
installing
and
and
managing
of
container
native
apps
right
and
all
the
services
that
support
them
too.
So,
for
example,
you
you
could
bundle
your
application
as
a
bunch
of
related
images
such
as
your
web
app
and
your
database
images
and
so
on,
and
talk
about
how
to
install
them
on
azure,
google
or
amazon,
and
it's
the
same
application
that
that's
installed
everywhere.
B
Despite
superficial
cloud
differences
underneath
and
so
the
interesting
thing
is
that
uses
stuff
in
a
system
project
of
ours
called
in
dodo
to
secure
the
distribution
of
bundles
end
to
end
the
the
cnap
securities
pack,
I'm
very
happy
to
say,
was
merged
just
last
month.
Many
thanks
to
radu
made
and
ralph
kolache
and
microsoft
for
helping
us
to
push
this
along.
So
please,
please
visit
cnab.io
to
get
more
information
on
that.
B
The
next
interesting
development
is
that,
so
two
years
ago,
we
presented
a
kubecon
north
america
about
how
datadog,
so
first
of
all,
datadocs
is
sas
platform
that
some
of
you
may
know
that
analyzes,
your
infrastructure
metrics
and
your
application
performance
and
logs
for
your
devops
purposes
and
in
particular
we
have
something
called
the
agent
which
you
install
in
your
host
and
integrations
are
like
plug-ins
for
the
agent
and
let
it
collect
even
more
metrics
and
logs
and
events
and
so
on.
Now.
B
The
key
thing
that
you
need
to
know
is
that
we
use
stuff
and
our
system
project
in
doto.
We
believe
this
is
the
first
in
the
industry.
As
far
as
we
can
tell,
there's
no
trusted
hardware
here
along
well,
except
for
something
called
ub
keys
that
the
developer
use,
but
basically
we
can
build
our
agent
integrations
and
it
is
in
fact
happening
today
when
you're
using
the
agent
to
install
or
upgrade.
B
We
build
it
and
distribute
it
in
such
a
way
that
any
attack
anywhere
between
our
developers
and
end
users,
you
will
be
detected
and
prevented,
which
is
the
sort
of
compromised
resilient
resilience.
That
marina
was
talking
about
and
some
new
features
we
were
able
to
do
this
year
was
we
basically
using
tough,
very
easily
associate
different
software
supply
chains
with
different
packages
without
breaking
backwards,
compatibility
for
end
users
and
also
revoke
developer
keys
again
without
breaking
packages
for
users
who
want
those
old
packages.
B
B
B
Harbor,
which
is
a
sibling,
cncf
project
of
ours,
their
mission
is
to
be
the
trusted
cloud
native
registry
for
kubernetes,
and
the
interesting
thing
is
that,
besides
other
security
features
such
as
scanning,
your
images
automatically
for
cves
is
that
they
also
support
content.
Signing
with
docker
content,
trust,
a
variant
of
tough
out
of
the
box
and
the
good
news
is
they
graduated
from
the
cncf
just
last
month?
So
congratulations.
This
is
fantastic
news.
B
The
project
itself
is
now
looking
to
improve
the
usability
and
security
for
future
future
use
cases
that
notary
v1
does
not
support
out
of
the
box,
and
we
have
been
working
with
them
to
leverage
some
new
features
and
stuff
that
marina
will
be
talking
about
shortly.
Actually,
the
long
story
short
is:
please
join
us
on
the
note,
3,
v2,
channel
and
cncslack
for
more
information.
We
would
love
for
you
to
join
us,
particularly
people
from
the
harbor
community,
which
we
think
would
be
interested
in
this
development.
B
Last
but
not
least,
we're
very,
very
excited
to
inform
that
pep
458,
which
we
co-wrote,
marina
and
myself
wrote,
has
been,
has
been
accepted
into
the
python
package
index,
which
many
many
container
images
use.
What
this
basically
means
is
that
we're
building
the
first
stepping
stone
right,
which
is
to
secure
the
distribution
of
246
000
python
packages,
projects
it's
the
first
open
source
programming
language.
We
know
that
does
this
that
basically
uses
stuff
to
secure.
So
even
if
you
hack
by
bi,
the
damage
that
attackers
can
do
is
limited.
B
This
is
fantastic.
This
is
basically
another.
First
thanks
to
facebook,
research
for
funding
and
and
too
many
names,
unfortunately,
that
I
can
list
right
now
in
iba
and
vmware
that
are
helping
us
to
to
implement
this
as
we
speak.
Actually,
we
hope
they'll
be
ready
in
a
few
months,
so
please
visit
the
pap
for
more
information.
Thank
you
and-
and
please
take
it
away
from
here,
marina.
A
So
a
lot
of
these
new
features
are
presented
through
these
things
called
taps
or
tough
augmentation
proposals.
So
basically,
what
this
is
is
just
a
design
document
for
tough.
That
includes
a
technical
specification
and
a
detailed
rationale,
and
so
the
idea
is
that
you
can
document
new
features,
have
some
some
new
some
new
documentation
and
also
just
have
some
in-depth
discussion
and
consensus
building
before
something
gets
implemented
in
the
specification
and
all
of
our
implementations.
A
So
the
first
one
of
these
I'll
talk
about
is
tap
11,
which
is
using
poops
for
interoperability.
So
tuff
doesn't
mandate
specific
implementation
details
such
as
wireline
formats
or,
like
we
talked
about
before
the
cryptographic
algorithms.
We
allow
people
to
use
whichever
ones
work
for
their
system,
however,
because
there
are
so
many
different
implementations
of
tough.
Sometimes
these
different
implementations
want
to
be
able
to
interoperate
and
so
to
allow
for
that.
A
So
in
this
case,
what
they
can
do
is
they
can
define
their
own
top
level
targets
metadata.
That
replaces
the
one
on
the
repository
and
use
this
to
decide
which
images
they
actually
trust,
and
so
this
can
be
used
like
for
organization
to
decide.
You
know
we
trust
these
developers
and
the
images
they
make,
but
not
necessarily
every
single
image
on
this
repository
and
then
next
we
have
top
14,
which
allows
for
succinct,
hashed
bin
delegations,
so
tug
allows
for
this.
A
And
next
we
have
an
as
yet
unnumbered
tap
for
snapshot,
merkle,
trees,
and
so
the
idea
here
is
also
for
very
large
repositories,
which
is
kind
of
a
theme
in
these
new
features.
But
when
you
have
a
very
large
repository,
the
snapshot
file,
which
lists
the
version
number
of
all
of
the
different
images
can
get
really
large.
If
you
have
a
lot
of
different
images
that
you're
that
you're
listing-
and
so
what
this
proposal
does,
is
it
kind
of
separates
that
snapshot
file
out
into
a
different
file
for
each
image?
A
A
So
here
are
kind
of
the
key
ongoing
discussions
that
are
happening
right
now,
there's
the
maintenance
of
the
tough
specification
and
the
reference
implementation.
So
what
the
tarp
project
is
primarily
is
a
specification
that
describes
how
anyone
can
do
secure
software
updates,
and
we
also
maintain
a
reference
implementation
written
in
python.
That
kind
of
demonstrates
how
this
can
be
done.
The
reference
of
notation
is
used
in
practice
as
well,
but
we
also
support
all
the
other
projects
that
chuchung
was
talking
about.
A
A
A
So
it's
a
good
time
to
get
involved
and
have
your
ideas
be
heard,
and
so
there's
a
lot
of
discussion
happening
on
the
nerdy
v2
channel
on
the
cncf
slack
so
feel
free
to
join
there
and
contribute
and
finally,
on
this
list
there
are
many
other
options,
but
for
this
list
we
have
the
tough
integration
in
pip,
and
so
so
these
are
both.
There
are
two
kind
of
separate
things
that
have
to
do
with
the
use
of
tough
in
pipi,
so
with
pep
458.
A
What
we
had
what
happened
was
we
got
tough
into
pipea
itself,
but
pod
guy
is
just
kind
of
like
the
server
side
of
the
update
process.
It's
just
the
repository.
In
order
for
this
to
actually
be
useful
and
to
provide
increased
security.
We
also
need
tough
integration
in
pip
and
other
downloaders
that
use
pi
pi,
so
they
actually
do
those
verification
steps
that
are
allowed
because
of
the
metadata
provided
and
also.
This
is
other
pep
that
we
wrote
called
pep
480,
which
includes
what
we
call
the
maximum
security
model.
A
So
pep
458
is
kind
of
a
minimal
implementation
of
tough
to
kind
of
get
started
and
get
some
initial
security
features,
and
then
pep
480
provides
even
more
in-depth
security
features,
including
end-to-end,
developer,
signing
and
some
other
really
cool
things.
So
that's
another
place
where
you
can
get
started
and
those
are
very
in
the
early
stages,
so
good
things
to
get
going
on.
A
And
finally,
we
would
like
to
thank
a
lot
of
different
people
who
have
made
all
of
these
different
things
possible.
There
are,
of
course,
more
people
than
we
could
list
on
this
slide,
but
this
is
a
nice
sampling
of
all
the
people
who
have
helped
make
tough
possible
and
all
of
the
tough
projects
successful.
C
A
A
It
kind
of
automatically
provides
this
protection
and
clients
are
really
only
aware
of
it.
If
there's
a
problem
and-
and
you
know
the
error-
messages
come
up,
so
I
think
otherwise
it's
pretty
much
transparent,
and
so
because
of
that
we
tend
to
get
much
more
participation
from
kind
of
developers
and
people
making
the
the
software.
Does
that
answer
the
question
feel
free
to
ask
again
if
it
doesn't.
B
C
B
A
I'm
sure
so
I
guess
it
depends
a
little
bit
on
which
part
of
the
ecosystem
that
this
year
day
would
affect.
I
think
one
thing
that
tuff
is
very
helpful
with
is
providing
once
there's
a
patch
for
a
zero
day.
You
can
securely
provide
this
patch
to
all
your
users,
so
that
people
don't
stay
vulnerable
for
very
long,
and
so
I
think
that's
a
key
key
thing
that
this
offers.
A
B
Yes,
exactly,
I
think,
marina
did
a
very
nice
job
there.
In
particular,
you
want
to
use
something
like
tough
to
update,
to
fix
your
zero
day
right.
You
need
an
update
just
to
fix
security
exploits
in
the
first
problem,
but
what
do
you
want
to
do
is
make
sure
you
use
an
update,
a
time
tested,
update
mechanism
like
stuff
to
make
sure
your
update
mechanism
itself
doesn't
have
cve.
You
don't
want
that.
It's
a
bad
place
to
be
yeah,
so
so
next
question
from
brian
boo.
B
B
I
don't
know
I'm
not
aware
of
the
top
of
my
head
of,
although
you
might
be
able
to
use
datadock
for,
for
we
we're
we're
slowly
rolling
out
new
new
security
monitoring
features
that
you
might
be
interested
in
that
you
might
be
able
to
visualize
things
like
which
software
updates
have
been
applied
or
not.
So
I
don't
know
if
that
fully
answers
your
question,
but
that's
one
possible.