►
From YouTube: IETF114-IOTOPS-20220729-1630
Description
IOTOPS meeting session at IETF114
2022/07/29 1630
https://datatracker.ietf.org/meeting/114/proceedings/
B
C
C
C
There's
a
new
addition
to
the
to
the
mid
echo
tool.
You
can
see
a
qr
code
here
in
the
room
you
have
in
on
the
meet
echo
side,
this
new
cell
phone
icon.
That
is
how
to
raise
your
hand
inside
a
room.
That's
really
useful,
not
to
discriminate
the
remote
attendees
that
reaction
actually
or
the
line.
Please
use
that
you
can
also
still
use
the
full
meet
echo
and
raise
your
hand
there.
C
C
Yeah,
my
name
is
hank.
Alexey
is
unfortunately
missing
an
airport.
We
don't
have
yet
a
assigned
javascript.
Would
somebody
like
to
take
that
up
yeah?
That
would
be
awesome,
also
notes,
I
don't
think
it's
a
hard
thing
notes
can
be
reached
via
the
meet
echo
site.
There's
this
little
notepad
icon
on
there
next
to
the
iot
ops
item
on
the
session
thing,
but
it's
also
here
on
the
slide
and
michael
just
raised
his
hand.
Thank
you
for
that
yeah.
Well,
pretty
much.
C
Obviously,
if
your
items
today
are
mostly
that's
reporting
on
work
that
needs
some
cross
pronation.
So
that's
great.
I
think
we
have
a,
I
think,
a
very
interesting
new
item
on
authentication
methods.
Here,
a
report
of
snack,
that's
nice.
We
will
have
to
above
the
theft.
I
think
that
is,
I
think,
overall,
very
interesting
topic
there.
C
I
actually
have
not
read
a
lot
of
the
internet
exposure
analyzer
yet
so
I'm
I'm
really
curious
about
that
one,
but
I'm
also
such
a
so
I
heard
a
little
bit
and
then
we
will
talk
a
long
time
today.
It
will
probably
take
a
long
time
today
to
talk
about
what
we're
going
to
do
in
the
next
year.
So
there's
a
candidate
for
adoption
here
and
brent
will
talk
about
that,
and
that
will
require
that's
why
this
is
plus
20
minutes.
I
think
a
little
bit
of
finding
ourselves
there.
C
I
know
again
at
this
time
we
are
32
attendees.
That
is
not
the
best
situation
to
make
guiding
decisions
in
a
room,
but
I
think
we
can
have
tentative
discussions
on
where
this
journey
can
go,
and
I
want
to
give
the
opportunity
to
bash
the
agenda
right
now.
If
anybody
has
something
to
add
to
this,
please
speak
up
or
raise
your
hand
in
the
queue
or
whatever
right
here,
with
the
bike
going
once
going
twice
the
agenda's
fine
and
we
have
an
open
microsoft
and
everybody
changes
their
mind.
C
A
A
A
There
are
different
ways
that
people
think
they
should
be
sending
evidence
and
attestation
results
around
in
this.
In
this
for
the
background
check
model,
this
would
be
evidence
sent
from
the
desktop
to
the
relying
party
which
is
then
sent
to
the
verifier
and
the
result
comes
back
to
the
relying
party.
A
Okay,
that's
kind
of
the
the
state
of
affairs,
so
lots
of
different
activities,
so
that
sort
of
gives
me
a
little
bit
impression
that
there's
a
broader
sort
of
a
number
of
industry
players
being
interested
in
utilizing
at
the
station
information
that
is
provided
by
hardware
in
in
some
of
the
newer
platforms
and
make
it
available
for
all
sorts
of
different
use.
Cases
next
slide.
A
As
I
mentioned
like,
I
talked
about
the
dls
based
version,
and
that
was
an
initial
version
like
many
of
the
other
documents
or
solutions.
I've.
I've
briefly
mentioned
the
after
the
meeting.
Netsmith
came
to
me
and-
and
we
agreed
that
we
would
be
working
on
a
comparison,
because
there
are
subtle
differences
between
between
the
different
approaches.
So
it's
not
irrelevant
on
where
you
stick
information
in
and
how
you
do
that.
Sorry,
certain
use
cases
favor
one
approach
versus
the
are
probably
less
than
ideal
in
other
cases.
A
So
we
wanted
to
highlight
this
and
bring
this
to
this
group,
potentially
because
it
could
be
a
good,
I
think,
a
good
item.
It
doesn't
actually
fit
into
other
groups
per
se
like
in
rats
or
in
in
let's
say
the
dls
group
or
like
what
other
groups.
So
maybe
maybe
this
could
actually
be
a
home
for
such
a
comparison
document
that
then
points
to
the
other
documents
that
are
being
worked
on
in
the
idf.
A
One
other
thing
for
those
who
are
participating
in
the
confidential
computing
consortium,
which
you
by
the
way
can
you
can
join
the
meetings
even
without
being
a
member
of
the
consortium,
so
those
are
public
meetings
they
are
held
on
a
regular
basis.
So
if
you,
if
that
type
of
sort
of
technology
is
of
interest
to
you,
feel
free
to
join
and
they're
also
collaborating
on
projects.
A
Assuming
that
it
works
out,
you
will
hopefully
see
some
some
code
in
the
in
the
near
future.
You
can
play
with
and
yeah
with
that.
I
want
to
conclude
so
if
anyone
of
you
is
is
interested
in
any
of
this
would
like
to
try
out
implementations
which
work
in
the
group
somehow
want
to
be
involved
in
the
discussions.
Let
me
know.
D
Yeah
yada
yada,
so
first
I
want
to
support
this
work.
I
think
it's
important.
We
need
it
and
please
go
ahead.
I'm
I'm
certainly
personally
interested
in
this.
I
don't
have
a
huge
comment
on
on
this.
Like
the
new
details
of
the
different
variants,
which
one
is
the
right
one
and
so
forth,
you
know
you
guys
have
to
work
that
out,
but
we
have
to
work
that
together,
but
I
I
think,
based
on
my
experience,
at
least
when
we're
building
some
some
things
that
needed
this.
D
These
types
of
at
the
station
designs.
Then
it
was
our
preference
that
we
would
have
had
like
a
libraries
available
that
you
know
the
standard,
tls
library
we
enabled
to
do.
This
would
allow
us
to
do
that
based
on
our
requirements
and
so
on,
and
it
could
be
in
some
other
libraries,
but
but
it
like
it
felt
at
the
time,
at
least
that
there's
like
clear
need
for
this,
but
not
a
lot
of
standardization
or
available
implementations
in
the
different
toolkits.
D
A
I
wonder
whether
it
would
also
be
useful
to
maybe
at
the
next
idf
meeting,
maybe
hackathon,
to
actually
sort
of
play
around
with
some
of
that
software
stack,
because
it's
obviously
there's
a
lot
of
different
components
and
each
component
by
itself
may
be
fairly
simple
to
use.
But
once
you
glue
everything
together,
it
gets
complicated.
D
That's
that
I
think
that
would
be
useful
and
I
I
do
think
that
it
does
get
complicated
and
that's
also.
It
may
be
a
point
to
be
thought
of
when,
like
you
brought
up
this
that
there's
different
ways
of
doing
this,
and
when
we
have
15
different
options,
you
know
what
happens
to
interoperability.
So
that's
not
necessarily
great.
A
A
C
So
next
is
me
as
a
contributor.
So
no
hats,
I
like
that
your
title
site
is
called
attestation
and
that
you
think
you
know
what
that
means,
and
and
and
actually
as
a
contributor,
that
is
a
really
really
really
hard
thing
out
there.
So
I
will
put
something
to
the
chat
here
right
now.
That
is
a
link
I
I
saved
it
by.
We
were
preparing
this.
Actually
it's
from
nist
and
it
tells
you
what
attestation
is
and
it
is
not
what
you
think
it
is
okay,
it's
derived
from
iso.
E
C
And
this
is
this
is
a
whole
s-bomb
space.
So
I
think
when
you
compare
approaches
you
should
also-
and
I
actually
would
really
me
to
contribute
that
part,
because
I'm
like
a
broken
record
when
I'm
starting
a
sentence
with
I'm
like
sounding
like
a
broken
record
now,
people
start
to
laugh
because
they
already
know
what
I'm
going
to
say,
yeah,
because
this
is
an
overloaded
term
and
a
lot
of
people
mean
endorsement
with
this
there's
no
evidence
involved,
there's
nothing
in
this
diagram,
you're
short
involved.
C
It's
just
saying
I
have
some
opinion
about
the
software
and
I'm
signing
my
opinion
with
an
identifier
about
the
software
at
the
end,
so
that
is
very,
very
complicated,
and
this
is
really
making
people
talk
past
each
other.
So
such
a
comparison
is
also,
of
course,
I
think
somehow,
maybe
in
a
dimension
here
and
then
I
don't
know-
I
usually
I
see
net
on
this
on
the
slide.
That's
httpa
right,
yeah,
okay,
excellent,
because
that
would
perfectly
fit
into
this
comparison.
Okay,
yeah.
A
F
A
C
B
B
My
summary,
my
one
minute
summary
is
that
it
looks
like
we
will
have
a
working
group
formed
soon
and
that
the
charter
was
well
discussed
and
the
problem
statements
was
reasonably
well
understood
and
that,
if
you
weren't
involved
in
it,
you
probably
should
think
about
it
and
it's
pretty
relevant
to
connectivity
in
the
home
for
iot
networks.
So
that's
really
it
I
just
wanted
to
let
you
know-
and
I
have
no
official
standing
in
any
of
that
process
so,
but
I
thought
it
was
important
that
we
put
it
on
this
agenda.
Thank
you.
C
G
C
F
G
F
G
This,
of
course,
opens
big
risks
distributed
denial
of
services.
Only
one
a
lot
of
more,
I
think,
will
come
into
play
and
therefore
we
need
here
strong
access,
admission
control
and
a
strong
authentication,
and
this
is
what
we
had
on
this
next
slide,
that
we
say:
okay,
we
think.
Okay,
usually
we
have
some
kind
of
on
the
left
side,
industrial
iot
like
for
the
power
grid
and
for
vehiculars
and
for
industry,
and
so
on.
These
are
devices
which
are
normally
by
definition,
high-end
or
kind
of
platinum
devices,
with
a
very.
G
This
does
not
really
fit
for
this
use
case
and
therefore
we
provided
this
or
we
think
the
term
hardware-based
authentication
means
that
we
have
in
the
device
also
a
interface
for
detecting
or
sending
video
signals,
sending
led
light
or
audio
streams
or
something
which
the
device
the
access
point
can
detect.
And
from
that
authenticate
the
device
would
be
perhaps
a
good
idea
or
is
already
proposed.
Also
as
out
of
band
channel.
You
surely
know
eep
noob,
which
uses
this
and
it.
G
Fulfills,
this
two-factor
authentication
that
we
have
something
independent
of
the
communication
channel,
the
second
one
to
authenticate
that
we
think
for
this.
We
yeah.
We
should
think
about
this
procedure,
how
to
how
this
could
be
designed
or
what
it
would
look
like
and
yeah,
and
besides
this
video
audio,
there
may
be
also
a
detection
just
of
gestures
of
shapes
or
so,
and
this
is
on
the
next
slide.
I
think
then
yeah.
G
Yeah:
okay,
thank
you
that
these
dumb
devices-
perhaps
it
may
be
even
too
costly-
to
have
an
led
light
in
this
device.
So
but
there
are,
this
is
a
later
on,
but
in
the
beginning
we
said
we
have
kind
of
requirements
or
challenges
set
up
that,
for
instance,
the
user,
who
is
installing
the
device
and
the
device
themselves
are
separate
and
not
physically
connected.
G
The
user
has
not
to
be
there
to
do
the
installation
or
the
authentication
to
the
network,
and
also
then
there
may
be
a
unique
identity
for
the
user
and
all
his
devices
or
an
identity
where
the
identity
of
the
devices
can
be
derived
from.
So
that
is
more
easy
for
normal
users.
Like
me
to
install
this
at
home
and
of
course,
then
the
authentication
should
be
mutually
so
the
device
should
authenticate
to
the
access
network
and
vice
versa,
the
x
network
to
their
device.
F
G
Also,
not
a
device
identifier
should
be
pre-provisioned
by
a
fabrication
or
also
any
authentication
credentials,
and
that
this
second
device
a
second
input
output
interface
for
the
out-of-band
channel,
maybe
only
one
directional,
so
just
sending
some
light
or
sending
playing
a
melody
or
just
any
doing
some
activity
without
detecting
it.
And
yes,
as
I
said
this
additional
interface
like
led
or
audio
for
this
out-of-band
channel
may
be
a
cost
factor.
G
So
we
had
the
idea
or
the
we
found
that
there's
this
radio
signal
sensing,
which
is
both
done
at
the
ieee
with
wi-fi
sensing,
but
also
in
3gbp
for
5g
and
60
run.
They
have
these
studies
so
that
we
have
one
antenna
for
sending
and
receiving
the
signal
and
analyzing
the
signal
modification
by
the
environment
to
to
provide
the
second
channel
so
this.
G
We
have
not
so
much
information
or
not
so
much
thoughts
already
spent
on
which
parameters
could
be
provided
between
the
iot
device
and
the
access
point.
So
what
is
the
capability
of
the
exit
point
to
detect
which
kind
of
signal
or
what
the
device
can
provide
and
how
to
characterize
it?
How
to
categorize
it
or
a
general
nice
description
of
how
this
token
should
look
like?
G
So
this
is
all
which
has
to
be
maybe
specified
later
on
and
then
also
about
the
naming
of
the
device
and
perhaps
a
renaming
of
the
device
if
it
is
reused
in
another
environment
and
whether
how
this
could
be
combined
to
the
geospatial
information
on
where
devices
placed
they
may
be
standard
standard
parameters
to
to
be
used.
And,
of
course
also,
then
what
is
existing
already
for
with
the
sensing
access
points
by
ieee.
H
I
G
The
last
slide
I
have
then
now
this
is
now
the
o2
version.
We
had
done
some
improvements
since
the
zero
zero
version,
also
discussing
with
michael
and
others
and
yeah.
We
would
like
very
much
if
somebody
can
review
and
look
at
the
document
and
comment
on
it
whether
this
is
useful
within
this
working
group.
G
So
at
the
moment
it
is
more
a
problem
statement,
but
perhaps
it
can
point
towards
some
possible
solution,
space
and
yeah,
and
that
would
be
then
perhaps
in
the
question
later
on,
to
adopt
this
as
a
working
group
document.
If
you
think
this
is
interesting,
yeah
and
with
this
I
want
to
thank
you
and
questions
either
now
or
also,
we
can
be
contacted.
C
D
I
Yeah
hi,
so
I'm
I
I
haven't,
read
the
draft.
I
would
be
willing
to
read
it
and
especially
since
you
mentioned,
eat
noob
and
in
emu,
I'm
looking
into
ibnoob
and
I've
found
some
some
some
issues
with
it
and
I'm
currently
working
on
on
a
another
draft
to
to
redo
the
same
thing,
but
not
with
jason
but
with
sibo.
F
J
D
F
D
D
I
also
have
happened
to
have
worked
a
little
bit
on
the
sensing
space
and
I
sort
of
got
the
gut
feeling,
at
least
that
it's
it's
it's
a
little
far
at
the
moment,
from
like
practical
application,
given
that
we
don't
actually
know
the
details
of
accuracy
and
and
so
on,
so
it
yeah.
It
may
not
be
the
first
thing
to
to
focus
on
perhaps
that
that's
that's
my
gut
feeling,
at
least
that
some
of
the
other
things
are
more
readily
available
and
their
characteristics
can
be
better
determined.
D
I
also
think
that
your
security
consideration
section,
which
was
pretty
empty,
probably
need
some
considerations
because
I'm
I'm
guessing
there
are
some
some
actual
issues
like
how
do
you?
How
do
you
prove
that
yeah
there
actually
was
something
here
and
it
wasn't
in
some
other
place
and
can
someone
simulate?
D
D
Yeah,
I
I
don't
know
if
I'm
right,
it's
just
my
gut
feeling
that
the
the
using
sensing
as
the
out-of-band
channel
is
yeah.
It's
an
interesting
idea.
It
may
not
have
immediate
practical
applications,
given
that
the
stuff
is
still
sort
of
in
the
works,
and
we
don't
really
like.
We
can't
immediately
experiment
with
it,
whereas
the
some
of
the
other
techniques
are
more
readily
available.
G
Okay,
yeah
yeah.
Thank
you,
as
at
least
we
had
in
mind
to
be
more
general
now
so
not
only
focus
on
this
sensing,
but
on
also
on
the
other
methods
which
are
available
still.
The
best,
of
course,
would
be
to
have
some
overarching
concept
which
is
working
for
everything,
okay,
but
everything
is
again
too
much.
C
I
F
F
F
This
is
not
a
transport
protocol
that
is
meant
to
compete
with
tcp
or
quick.
It's
really
meant
for
limited
domains
like
we
encounter
a
lot
in
iot,
so
you
know.
Why
would
we
do
this?
So
we
thought
that
there
was
a
serious
unmet
need,
that's
very
difficult,
if
not
impossible,
to
meet
with
today's
transport
protocols.
F
Okay,
so
we
we've
already
know
that
requiring
device.
Enrollment
is
necessary
to
get
security
in
iot,
but
it
isn't
sufficient.
And
how
do
we
know
this?
That
lots
of
hackers
have
kindly
showed
us
this
and
if
you
don't
have
any
examples
that
you
can
come
up
with,
there
are
three
here
that
you
could
follow
the
links
for
later.
F
F
F
So
if
we
take
this
approach
and
this
approach
is
pushing
pub
sub
into
the
transport,
this
is
not
mqtt.
Now
we
get
some
benefits
that
go
beyond
security.
We're
now
communicating
with
topics
at
the
transport
level
instead
of
endpoints,
and
this
notion
is
inherently
broadcast
friendly.
So,
instead
of
having
this,
you
know,
pipe-based
end-to-end
type
communication,
we're
now
order
of
n.
We
don't
need
brokers
or
hubs,
so
we
eliminate
a
single
point
of
failure
attack
and
we
don't
need
endpoint
identities.
F
So
we
can
just
use
link
local
self-assigned
addresses,
we've
been
using
ipv6
and
now
security.
The
whole
security
game
completely
changes
from
what
we've
been
doing.
Can
I
have
the
next
slide,
so
there's
two
big
ideas
that
we're
making
use
of
in
gift
and
the
first
one
is
that
we're
taking
trust
management.
F
If
you
want
in
particularly
the
first
could
be
deployed
with
application
pub
sub
protocols
like
mqtt,
okay,
the
next
slide,
then
so.
Here's
kind
of
the
basics
of
defined
trust
communications
is
that
we're
going
to
always
start
with
the
configuration
or
bootstrap
and
just
use
any
reasonable
approach
or
a
lot
out
there,
and
this
is
how
we
do
enrollment,
so
enrollment
is
first
necessary,
but
now
what
we
enroll
with
is
a
little
bit
more
specific.
F
We
have
a
bundle
that
contains
the
trust
anchor
for
that
particular
trust
domain,
a
trust
schema
cert,
which
is
the
rules
compiled
into
a
binary
form
and
signed,
and
then
we
have
an
identity,
which
is
the
public
search
chain
which
is
signed
by
the
trust
anchor
at
the
top
of
the
chain
and
your
private
signing
key.
So
the
only
thing
there
that
needs
to
be
kept
secret
is
the
private
signing
key,
so
we're
assuming
locally
generated
trust
anchors,
but
this
isn't
required.
F
You
could
do
this,
I
suppose
with
non-locally
generated
trust
anchors
and
our
identities
are
distributed
as
chains
of
trust.
I
hope
that's.
The
right.
Plural,
for
chain
of
trust
and
death
contains
the
validation
methods
that
check
this
signing
chain
and
the
chain
is
where
we
keep
the
roles.
The
attributes
and
the
capabilities.
F
F
Tell
you
a
lot
about
what
each
role
can
do
you
can
you
could
make
it
as
simple
as
just
saying
that
an
enrolled
identity
signs
all
the
domain
communications,
but
you
can
certainly
go
beyond
that
to
fairly
fine-grained
rules,
which
is
the
kinds
of
things
that
we've
been
experimenting
with
and
we
have
self-configuring
privacy
once
you're
enrolled
via
aead
encryption,
and
you
can
update
the
trust
schemas
at
any
time
by
changing
the
rules
and
you
don't
have
to
change
your
code.
So
if
you
think
about
this,
you
don't
have
to
recompile
code.
F
F
F
What
you
want
to
do
is
you
want
to
get
your
site
policy,
and
then
you
want
to
get
rules
that
come
from
standards
like
what
does
a
light
bulb?
Do
what
does
a
light
switch
do,
and
we
have
very
nice
standards
that
lay
those
things
out.
You
put
those
together
into
trust
rules
in
a
in
a
particular
format,
and
then
these
go
through
a
compiler
which
comes
out
with
a
binary
version
of
the
trust
rules
for
a
particular
trust
domain,
and
then
these
are
signed
and
put
in
a
cert.
F
So
now
what
happens?
Is
we've
set
this
up
say
so
that
the
light
bulb
can
only
report
its
status?
All
it
can
do
is
say
I'm
on
or
I'm
off
I
mean.
Obviously
you
could
have
different
levels
of
on,
but
now,
if
somebody
puts
something
in
that
firmware
that
allows
them
to
say
activate
a
microphone
that
happened
to
be
on
the
chip
in
the
light
bulb.
There's
no
way
for
that
to
talk
to
the
outside
world,
because
that
publication
would
be
rejected.
F
F
Now,
let's
see
the
next
slide
on
the
next
slide.
I
want
to
go
back
to
what
we
were
saying
in
the
beginning,
about
enrollment
not
being
sufficient.
So
here's
what
we
do
right
step,
one
we
enroll
that
light
bulb
just
in
a
way
you
do
now,
except
that
we
use
that
bundle
that
I
described
earlier
in
step.
Two
that
enrolled
light
bulb,
is
going
to
join
the
trust
domain
and
it
doesn't
need
any
external
servers
or
routers.
F
It
doesn't
need
to
know
who's
already
in
the
domain
and
the
things
that
are
in
the
domain
already
don't
need
to
know
anything
about
the
light
bulb.
So
the
light
bulb
comes
in
by
saying
I
want
to.
I
publish
my
identity
to
the
cert
collection
for
this
domain,
and
I
subscribe
to
get
everyone
else's
and
what's
happening
over
here.
Is
we
have
a
device?
That's
our
key
maker
and
it
has
to
be
something
that's
always
on,
and
this
particular
device
won
the
keymaker
election
and
it's
going
to
get
this
new.
F
F
Maybe
it's
the
kitchen
sink
light,
or
it
can
listen
to
the
room
that
it's
in
kitchen
lights
or
it
can
be
everything
on
the
ground
floor
or
every
light
in
the
house,
but
that
light
can
only
report
its
status
and
it
can't
issue
any
commands
so
that
takes
care
of
that
light
bulb
hack.
That
was
back
on
the
earlier
slide.
That
was
the
checkpoint
published
on
that
a
couple
of
years
ago.
F
So
this
is
sort
of
my
final
notes
that
our
goal
for
this
draft
is
an
independent
submission,
informational
rfc,
but
we're
really
looking
for
feedback
on
the
draft
to
include
it.
I
mean
it's
just
been
a
small
number
of
us
working
on
this
and
it's
just
good
to
find
out
what
we
may
have
missed
and
what
other
things
could
be
important,
possibly
looking
for
collaborators
on
defined
trust
communications,
but
I'm
not
sure
what
that
would
look
like.
F
But
if
somebody
has
an
idea,
let
me
know-
and
the
other
thing
we
wanted
to
do
is
expose
some
of
these
new
ideas
about
transport
and
security,
because
we
thought
they
might
be
useful
in
other
ietf
work,
and
this
work
is
completely
open.
We
have
a
open
source
reference
implementation
that
that
also
has
tools
for
looking
at
what
you're
working
on
and
also
you
know,
examining
trust,
schemas
and
has
some
examples.
F
E
Hello
dave
taylor,
so
I
I
have
not
yet
read
the
draft.
So
thank
you
for
this
presentation,
since
I
didn't
know
about
this
before,
but
this
is
looks
great,
meaning
a
couple
things
that
I
really
like
about
this.
If
I
understand
right,
you're
using
a
trusted
execution
environment
or
your
slideshow
trust
zone,
and
so
the
use
of
tees
and
iot
is.
F
F
F
Right,
well,
we're
not
you
don't
we're
not!
We
don't
actually
require
that.
I
think
that
that
was
meant
to
show
how
you
could
really
get
extra
security
here
and
we're
a
little
less
concerned
with.
You
know
today,
state
of
the
art,
the
kind
of
thing
that
that
mud
was
really
meant
to
deal
with
and
kind
of
going
forward,
and
some
of
the
more
special
purpose
uses.
You
know.
One
of
the
collaborators
here
is
operant
and
you
know
they
can
use
trusted
execution
environments
and
the
things
that
they're
rolling
up
right.
So.
F
Yeah
yeah,
I
don't
I
don't
know
either,
but
I
just
want
to
make
that
clear
that
we
don't
require
them,
and
it's
just
that
if
you
really
want
to
harden
your
security-
and
I
think
if
you
did
read
the
draft,
you
can
kind
of
see
we're
not
really
requiring
it.
We
mentioned
that
as
a
way
to
deal
with
some
possible
security
issues,
and
you
know
we
clearly,
we
think
that's
a
good
place
to
go
going
forward
because
the
world's
just
going
to
get
you
know
nastier
in
terms
of
attacking.
E
Okay,
so
I'm
gonna
back
up
to
just
comments
and
then
I
actually
have
two
technical
questions
or
maybe
two
halves.
The
same
thing
question:
the
comments
were
about
the
things
that
I
really
liked
on.
Your
presentation
was
that
you
were
using
a
trusted
execution
environment
right.
You
showed
trust
zone
on
your
slide
in
iot,
and
I
wish
more
people
would
do
that.
Use
tees
the
since
you
mentioned
it
was
open
source
and
that
you
wanted
additional
review.
E
My
suggestion
was,
you
might
take
this
to
the
conference
computing
consortium
and
present
it
in
the
technical
advisory
council
meeting
by
the
way
I
chair
that
meeting,
so
I
can
make
sure
you
get
on
the
agenda
and
a
couple.
People
in
this
room
are
the
typical
attendees,
but
that
organization
sponsors
open
source
projects
and
since
you
have
one
they
would
be
very
interested
in
hearing
about
use
of
tees
and
environments,
and
I
think
this
would
be
very
appropriate.
So
anyway,
that
was
my
ccc.
F
F
E
Yeah
great
then
one
of
my
technical
questions,
because
you
mentioned
you
know,
what's
missing
or
what
didn't
you
talk
about
that
may
or
may
not
be
in
the
draft.
I
don't
know,
but
the
first
one
is
there's
a
number
of
iot
devices
that
roam
around
at
different
networks
like
things
that
I
carry
on
me.
So
how
do
you
know?
The
first
question
is:
how
do
you
know
that
you're
actually
in
the
limited
domain
versus
somewhere
else?
E
Okay-
that
was
the
first
question
and
the
second
question
is:
how
do
you
actually
do
discovery
and
setup?
Usually
in
a
transport
protocol
I
mean,
are
using
dns
or
do
you
have
some
discovery
mechanism
and
how
do
you
know
that
the
discovery
mechanism
isn't
going
on
and
then
the
non-limited
domain
and
so
on?
So
those
are
the
topics
that
I
was
more
interested
in
hearing
more
about.
So.
F
Yes,
so
we
have
we,
we
aren't.
That's
not
so
much
our
problem
space
right
now,
but
we
do
have
a
problem
space
where
we
connect
different
trust
domains
or
we're
sort
of
extending
them
by
putting
them
over
something
like
a
udp
or
tcp
connection-
and
I
believe,
there's
some
stuff
about
that
in
the
draft,
and
there
is
an
example
out
there
and
I
we
hope.
F
Eventually
we
have
some
ideas
about
like
roaming
around
within
a
a
building
where,
within
a
trust
domain
where
we
can
sort
of
mesh
devices-
and
I
think
a
little
bit
of
that
is
in
the
draft-
and
I
have
to
say
that's
more-
our
stuff
is
kind
of
on
the
edge
here,
we're
still
working
with
that,
but
so
far
we're
kind
of
encouraged.
I've
got
a
couple
little
examples.
F
I
think
that
we
have
a
lot
of
the
tools
to
do
it
as
to
the
other.
It
would
be
really
nice
if
van
would
answer
this,
because
he
can,
you
know,
sort
of
use
all
the
lingo
right
and
he
should
be
somewhere
there.
Then
could
you
answer
the
stuff
about
how
we're
kind
of
making
use
of
what's
in
the
link
local
ipv6,
but
we're
not
using
dns
or
anything
we're
it.
J
We
I
dave
long
time,
no
see
we're
using
ip6
multicast
for
rendezvous
because
it's
defined
to
have
exactly
the
semantic
we
want.
It's
link
local
self-assigned
addresses
guaranteed
not
to
loop,
and
so
because
it's
a
very
multicast
friendly
transport.
We
simply
advertise
in
the
appropriate
topic
that
we
have
this
information.
J
J
E
Great
thank
you
van.
As
I
understand
it.
If
I
understand
the
the
the
the
overall
answer
to
my
question,
thank
you
for
the
details
by
the
way
that
the
pr
that
the
protocol
itself
def
does
its
own
discovery.
It
doesn't
rely
on
some
external
mechanism
like
dns
or
mbns,
or
something
like
that.
Okay,
I
don't
know
how
much
time
we
have.
If
I
have
time
for
a
follow-up
question
or
oh.
E
Do
you
consider
as
being
within
the
threat
model,
and
you
consider
the
case
where
the
network
itself
is
untrusted?
In
other
words,
where
you
have
say,
two
entities
that
need
to
discover
each
other
without
revealing
that
they're
part
of
the
same
trust
domain
on
an
on
an
untrusted
network?
Is
that
part
of
the
threat
model
or
are
not
part
of
the
threat
model.
E
So
yeah,
I
can
explain
why
I'm
asking
the
questions
just
whether
there's
other
work
that
would
be
applicable
to
your
use
case
or
not
within
the
space
of
say
the
md
s
domain.
I
know
you're
not
using
that
right,
but
there
was
work
there.
That
said,
if
I
have
two
devices
you're
in
the
airport
on
an
untrusted
network,
can
they
discover
each
other
without
revealing
the
fact
that
they
are?
In
the
same?
E
If
you
care
about
that
in
your
trust
model,
then
you
might
be
able
to
have
similar
approaches
and
just
steal
them
from
the
other
protocol
work
that
was
done.
I
think
it
might
be
an
rfc
now
I
don't
know,
but
it
started
like
five
years
ago
or
something
yeah.
It
didn't
progress.
Okay,
you
well
christian
started
it,
but
then
somebody
else
that
was
a
researcher
and
then
took
it
over
from
there.
E
I
J
Has
extremely
limited
distribution
right,
it's
a
cert
that
you
made
up
at
home
and
that,
to
the
extent
that
the
domain
supports
ip6
multicast,
then
you
can
do
the
selective
rendezvous
and
then
pure
authentication,
so
some
sort
of
challenge
response.
If
you
you
want
to
validate
it,
so
look
at
this,
but
having
this
large
multi-cat
having
a
broadcast
rendezvous
and
then
a
large
address
space
that
you
can
play
with
to
filter
the
rendezvous
is
a
big
help.
E
Yeah,
I
agree
having
a
a
multicast
group,
that
is,
you
know,
a
hash
of
some
security
credential
that
you
know,
you're
rendezvouing
on
a
multicast
group
out
of
a
very
large
space,
actually
helps
the
problem
significantly
yeah.
That
makes
sense.
So
all
right,
I
see
brennan
is
in
queue.
Thank
you
for
letting
me
ask
you
a
bunch
of
questions.
C
K
F
K
F
I
don't
know
if
dan
has
anything
to
say
about
this,
I
would
just
say:
yeah.
We
hadn't,
we
hadn't
thought
about
this.
So
much
for
the
you
know.
If
you're
going
to
the
airport
type
thing,
you
know
that
you're
moving
around
and
the
mobility
that
may
you
know
when
you're
trying
to
find
out
the
patterns
of
the
person
who's
using
that
particular
trust
domain.
F
L
So
I
think
that
you
may
be
focusing
too
much
and
carsten
even
may
be
focusing
too
much
on
the
unlinkability
problem,
because
there's
actually
a
bigger
one
that
shows
up
first
and
that's
simply
traffic
analysis.
If
you
have
communication
partners
in
a
untrusted
domain,
then
you
can
link
them
regardless
of
discovery
simply
by
monitoring
their
traffic
and
seeing
challenge
response
patterns,
and
things
like
that.
L
So
it
doesn't
take
much
analysis
to
discover
that
unless
you've
got
an
extremely
noisy
network
that
prevents
you
from
doing
statistical
analysis
on
the
responses
of
devices
and
that,
I
think,
is
going
to
be
something
that
you
have
to
consider.
If
you
actually
want
to
make
it
visible
or
or
sorry
make
it
invisible
that
two
devices
are
talking
to
each
other.
L
The
the
handshake
is
only
the
first
step
and
if
you
can't
solve
the
second
one,
then
solving
a
handshake
doesn't
really
matter,
and
the
the
other
aspect
to
this
is
that
you're
going
to
need
to
deal
with
the
stalker
problem.
So
if
you
have
someone
who
visits
a
coffee
shop
once
in
a
while
and
they're
carrying
their
device,
that's
proudly
announcing
itself
at
the
coffee
shop
that
tells
everyone
who's
listening
with
a
directional
antenna
or
whatever
that
they're
there.
L
F
F
L
F
Mean
they
could
be
if
you
had,
I
guess,
but
you
I
mean
that's,
not
the
trust
domain
would
be,
for
example,
you
know
maybe
an
entire
factory
or
so
all
of
the
devices
that
are
in
it
are
in
that
trust
domain
and
when
things
publish
they
I
mean
you
know
you're
talking
about
two
devices
communicating
and
we
don't
really
think
so
much.
In
that
terms
everything
gets
broadcast
right.
F
So
I
guess,
if
there's
only
two
devices,
you
will
see
only
two
devices
lighting
up
with
that
trust
domain
as
their
you
know,
starting
bits,
but
if
there
are
multiple
devices,
what
you're
going
to
see
is
it
might
be
somewhat
random.
Who
is
responding
when
you
know
someone
is
sending
out
something?
That's
you
know
kind
of
looking
for
more
information
or
more
publications.
L
F
L
I
appreciate
that
sorry,
I
just
from
some
of
the
previous
discussion.
I
had
gotten
the
impression
that
trust
and
means
could
be
personally
unique.
There
was
a
comment
earlier
that
it
was
made
in
a
very
limited
scope,
for
example,
and
from
that
basis,
then
you
can
see
how
that
would
be
a
surveillance
vehicle.
So
the
the
point
here
is
definitely
do
not
make
individual
scoped
trust
domains,
because
that
constructs
a
surveillance
vehicle.
F
C
C
Okay,
good
that
that's
excellent,
also
what
I
just
heard
could
be
a
security
considerations
content.
So
if
you
scope
your
trust
domain
too
small,
it
might
be
a
problem.
So
so
what
you
just
discussed
with
brenton
the
the
what
would
say
the
surveillance
systems
you
might
be
involuntarily
just
reconstructing
there.
That
is
probably
a
part
that
could
be
discussed
in
the
security
consideration
part
of
the
document,
so
just
yeah,
I
want
to
ask:
are
there
more
questions,
but,
unfortunately,
the
time
is
a
little
bit
short
now.
C
C
F
H
Thank
you
very
much
again
hack
for
for
the
space
for
presenting
a
bit
more
about
the
draft
issue,
so
I
have
made
one
one
short
presentation
in
the
awp
session
and
during
the
morning
and
now
I'm
going
to
present
some
some
results
of
on
running
good
tests
that
I
may
do
during
my
research,
my
research
phase,
while
I
was
producing
this
this
draft
so
next
slide.
Please.
H
So
this
is
the
agenda.
I'm
going
to
introduce
you
about
what
I'd
like
you
to
call
in
vitro
experiment.
It
was
one
so
much
specific
environment
that
we
have
developed
with
a
running
code
test
with
issue.
I'm
gonna
show
you
the
experimentation
and
I
will
open
some
some
space
to
excuse
a
bit
more
about
some
other
domains.
I
have
the
domains
that
maybe
could
explain
the
concepts
of
history
and
then
talk
a
bit
more
about
the
next
steps.
Next
slide,
please.
H
We
have
built
a
network
communication
graph
by
using
the
the
mod
files,
the
28
mod
files
provided
by
magic
from
the
university
of
south
wales,
so
we
have
basically
four
replicas
from
each
modifier
that
was
was
describe
it
there
published
that
and
we
use
it
in
my
right
variant
and
in
like
the
next
slide,
we
start
to
excuse
the
results
for
next
slide.
Please!
H
H
This
experiment
in
three
kinds
of
protection
in
the
same
network,
the
natural
equipment
non-protection,
the
network
it
and
the
protection
provided
by
mud
itself,
the
rfc
8520
and
the
protection
provided
by
by
issue.
So
we
can
see
in
the
left
most,
for
example,
the
worst
enough
scenario
where
they,
it
was
possible
with
all
the
devices
and
the
network
infected
in
one
in
one
network
with
no
protection.
H
So
we
in
about
20
minutes,
and
even
I
think
that
it
was
five
or
four
rounds
of
of
the
attacks.
We
had
something
between
2.5
and
3,
millions
of
packets,
generated
and
transmitted
by
the
network
in
the
network,
with
known
protection
and
in
in
the
case
of
in
the
same
scenario
with
with
the
protection
of
mud,
we
had
a
little
less
than
1.5
million
packets
generated,
but
almost
non-transmitted,
because
what
has
a
good
protection
of
impacts
of
communication
with
whole
sites
outside
my
internal
network.
H
So
we
had
a
high
number
of
of
packet
generated,
but
almost
non-transmitted.
We
have
some
of
those
scenarios.
But
if
you
look
at
the
rightmost
side
of
the
of
the
of
this
chart,
we
will
see
all
the
scenarios
where,
where
we
use
it
issue,
so
we
could
not
identify
any
generation
or
transmission
of
the
dust
packets
in
the
scenario
that
they
have
experiment
experimented.
H
We
can
see
that
mods
still
allowed
some
some
devices
40
devices
from
the
112
devices
could
connect
to
the
to
the
permanent
control
server
and
then
could
generate
the
dust
traffic,
but
the
the
the
older
metrics
like
the
refraction
and
scanning
was
smaller
and
much
nerve,
but
in
issue
we
did
not
have
any
ddos
packet
generated
because
none
of
the
bots
could
be
controlled
even
when
infected.
We
did
not
have
any
any
new
infection,
and
also
it
did
not
have
navy
scanning
and
so
on.
H
H
Okay,
so,
besides
the
the
home
iot
scenario,
we
are
also
studying
some
other
scenarios
to
expand
the
issue
proposal.
So
the
first
one
that
we
are
thinking
about
throughout
also
with
we
tissue
is
in
the
scenario
of
smart
cities
where
we
have
similar
topologies
and-
and
there
are
unity
of
devices
we
have
the
same
scenario
with
a
small
stock
taking
care
of
big
infrastructures
and
well
different
from
the
home
home
iot
scenario
in
smart
cities.
We
can
consider
that
we
understand
better
the
running
applications.
H
We
can
understand
better
the
running
applications
inside
my
network
and
that
we
also
have
more
computer
power
available
and
a
second
branch
of
of
this
proposal
of
this
dispute
often
shoe
is
through
running
it
all
off
in
industrial
loyalty.
We
are
running
on
one
research
now
in
this
industry,
but
we
are
still
the
early
days
where
we
have
critical
system
system
running
and
if
we
have
the
full
understanding
of
the
end
model
of
the
running
applications.
This
means
that
we
understand
better
or
what
we
can
understand
understand
better.
H
What
kinds
of
traffic
that
we
can
block,
for
example,
how
it
will
affect
my
dose
to
my
my
industrial
plant,
so
this
this
can
give
us
more
control
about
also
the
decisions
made
based
on
in
issue
rules
in
issue
actions,
and
we
are
trying
to
do
it
in
top
of
modbus
or
profitable
networks.
So
we
are
staying
in
the
early
days,
but
we
think
that
here
we
can
may
maybe
have
something.
H
C
C
C
L
L
L
L
So
I
maintain
that
all
security
architectures
should
have
threat
models.
So,
since
I
didn't
have
one
I've
put
one
in
so
iot
nets
now
has
a
threat
model,
some
guiding
usability
requirements,
some
risks,
some
mitigations
for
those
threats
and
technologies
to
implement
the
mitigations,
and
this
was
an
attempt
to
approach
the
ask
that
eliot
lear
gave
me
after
the
initial
draft,
which
was
essentially
a
menu
of
technologies,
and
why
you
might
want
to
use
them
next
slide.
Please.
L
So
I've
covered
10
top
level
threats.
Some
of
them
have
a
few
sub
threats,
and
I
I
could
go
through
them
all
here,
but
honestly,
it's
better
to
go
through
the
draft
and
have
a
look
at
them.
The
important
thing
here
is
that
these
are
all
threats
that
probably
have
relevance
in
networks
containing
iot
devices
and
a
lot
of
them
have
to
do
with
threats
directly
against
the
devices.
Some
of
them
also
have
to
do
with
threats
against
the
network
next
slide.
Please.
L
L
L
The
technologies
that
we've
I've
covered
are
fairly
minimal.
There's
no
mention
of
transports,
for
example,
so
things
like
tls
dtls
coap.
None
of
that
is
in
this
draft
and
I'm
not
sure
if
it
belongs
there
or
not.
I'd
appreciate
feedback
on
that
and
there's
missing
guidance
on
non-security
aspects
of
iot
ops,
for
example.
Human
readable
formats
do
not
belong
on
constrained
nodes,
so
we
I
haven't,
put
anything
about
that
in
there.
L
L
L
So
please
contribute
and
please
let
me
know
if
you
would
like
to
add
to
this
and
with
that
in
this
you
know
30
seconds
I've
taken
to
go
through
my
slide
deck
I'd
be
happy
to
talk
about
anything
else
in
this.
If
there
are
any
questions
or
comments
or
things
that
are
obvious,
that
I've
missed
et
cetera,
et
cetera.
B
B
B
B
Without
criticizing
any
specific
part
of
the
document,
I'm
unclear
what
the
actionable
outcomes
of
this
for
the
reader
are
and
that
that's,
maybe
something
that
we
really
need
to
to
discuss
about
that
right.
So
I'm
I'm
I'm
happy
to
have
a
what's
the
right
word,
a
survey
document
of
itf,
specs
and
other
specs
that
are
important
and
that's
part
of
the
purpose
of
this
working
group.
B
So
I
I'm
not
saying
we
shouldn't
do
it,
I'm
just
saying
that
if
they're,
we
need
to
think
about
what
what
what
the
readers
next
step
is
when
they
get
this
document.
Okay,
and
that
may
take
a
little
bit
of
thinking
as
to
what
we're
really
doing-
and
I
I
guess
hank
we
were
supposed
to
have
a
what
are
we
doing
the
next
year
discussion
and
we
haven't
had
that
last
time
and
I
don't
think
we're
having
it
this
time.
Oh.
B
Okay,
well,
I
think
we
actually,
given
that
we
lost
one
co-chair
and
we
had
the
internet
go
down.
We
might
I
said
this.
I
said
this
last
time
actually
that
maybe
maybe
we
need
to
do
this
and
it's
friday
afternoon
or
probably
all
baked.
Maybe
we
need
to
do
this
as
a
virtual
interim,
where
we
can
actually
just
focus
on
that
one
topic
for
that,
and
I
think
this
document
actually
may
take
us
there
right.
So
so
they're,
not,
as
you
said,
unconnected
but
anyway,
thank
you
brandon.
B
I
would
definitely
contribute
more
more
things
to
it.
I
I
I
I
see
it
is
a
bit
thin
and
I
think
we
can
go
quite
extensively
on
some
of
the
items.
The
question
I
think
really
is
again
is
let's
figure
out
what
we're
trying
to
tell
people
here
and
what
the
conclusion
is
supposed
to
be.
Let's
write
the
conclusion.
First
right.
L
The
the
goal
was
to
be
a
landing
pad
document
for
iot
security
and
and
say
you
know
this.
This
is
a
a
broad
scope
of
different
things
that
you
may
encounter
as
a
iot
device
vendor
or
iot
network
vendor,
and
this
is
you
know
the
the
sort
of
things
that
you
may
encounter.
The
sort
of
concerns
you
may
have,
and
if
you
have
such
a
concern,
then
here
are
the
ways
that
you
get
around
it
here
are
the
solutions
to
the
problem
that
you
just
discovered.
You
have.
C
C
A
L
C
It,
but
I
think
this
one
I
would
encourage
actually
to
read
to
prepare
for
a
set
virtual
interim.
Yes,
we
are
all
back.
This
is
a
friday
zombie
slot,
but
still
I
think
that
was
something
I
wanted
to
know,
and
here
we
go
so
I'm
capturing
capturing
this
result
and
I
will
do
another
one
who
this
is
helpful
is
another
pop
quest,
so
who
will
probably
in
the
in
the
position
to
review
this
in
order
to
bring
it
in
shape.
C
C
Yeah,
so
I
wanted
to
set
these
four
hands,
otherwise
I
would
be
like
okay,
this
is
major
friday.
Okay,
get
in
contact
with
brandon,
we
can
chat
on
the
list
and
we
can
create
a
virtual
interim
for
this
kind
of
work.
We
can
co-locate
a
comparison
document
that
we're
talking
about,
but
there's
no
document
yet
so
that
might
be
a
little
bit
premature.
C
And
yeah,
this
is
basically
what
I
wanted
to
see
and
if
this
could
be
something
that
the
majority
of
the
working
group
has
a
consensus
with,
then
we
can
actually
start
adopt
our
first
document,
but
it's
important
that
we
actually
involve
the
people.
So
we
have
to
float
this
a
little
bit.
That's
on
all
of
the
here
and
the
group
right
now
who
can
hear
me
who
might
eventually
read
the
minutes
and
then
and
then
go
from
there.