►
From YouTube: IETF-T2TRG-20230524-1300
Description
T2TRG meeting session at IETF
2023/05/24 1300
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
Ari
is
still
stuck
in
a
family
of
event
and
it
probably
will
join
us
in
a
few
minutes.
If
you
wonder
where
he
is
so.
This
is
an
irtf
meeting,
so
the
irtf
node
well
applies
and
the
short
form
of
it
is
you
maybe
record
it
or
you
will
be
recorded.
Actually
we
are
all
trying
to
be
nice
to
each
other
and
and
professional
whatever.
A
A
So
just
a
quick
reminder:
this
is
not
a
standards
development
meeting.
This
is
a
research
group
meeting.
The
the
point
of
the
research
group
is
to
have
a
longer
term
view
on
the
issues
which
which,
in
the
end
of
course,
do
impact
on
on
standardization.
But
we
are
not
doing
standards
here
and
there
are
a
number
of
media
that
are
helping
us
doing
this
thing.
A
A
So
I'm
not
going
to
do
these
slides
here
in
detail.
They
are
just
in
the
slide
deck
for
reference.
You
can
get
at
the
slide
deck
at
the
link
where
that
I
sent
around
an
hour
ago
on
the
mailing
list,
and
the
same
is
true
about
the
the
interesting
relationship
that
this
research
group
has
with
various
iitf
groups
that
are
kind
of
the
the
both
the
parents
and
the
children
of
activities
that
have
happened
in
the
wizard
hoop
assembly
are
simply
related
to
it.
A
Okay,
so
today's
meeting
is
is
a
short
one
hour
work
meeting
and
we
want
to
focus
on
the
subject
of
security.
We
have
three
active
research
group
drafts
on
security
issues
which
we
are
discussing
today,
and
we
also
have
one
potential
field
of
new
work
where
I
want
to
gauge
what
the
the
level
of
interest
in
this
group
is.
A
Whether
people
would
be
interested
in
contributing
to
to
some
additional
work,
so
the
the
resulting
agenda
has
John
starting
in
minus
13
seconds,
on
amplification
attacks
mood
and
then
about
the
terminology
and
processes
for
initial
security,
setup
and
Michael.
On
the
taxonomy
for
for
keys
for
manufacturer,
install
keys
and
Trust
anchors,
we
don't
really
have
the
time
to
do
all
four
items
in
15
minutes,
so
we
will
compress
the
the
discovery
discussion
at
the
end.
If
we
need
more
time
so
Michael,
you
don't
have
to
to
feel
like
you.
B
Yeah
I
do
yeah,
so
this
is
about
the
amplification
attack.
Droughts,
I
think
it
has
been
updated
three
versions
since
it
was
presented
in
thing
to
think
orgy
last.
It
has
also
been
adopted
by
the
working
group
research
group.
Since
then,
most
of
the
changes
are
based
on
comments
from
aching,
Krauss
and
discussing
with
Sultan.
B
Then
observers
made
a
separate
figure
based
on
a
comment
from
Achim
at
the
text.
As
the
the
draft
does
not
suggest
that
Co-op
is
more
vulnerable
to
amplification
and
text
than
other
protocols.
Maybe
it
is
maybe
it
isn't,
but
we
we
don't
state
that
some
readers
got
that
impression
before,
even
if
that
was
not
stated,
I
added
that
post,
Focus,
post
and
put
is
only
possible
if
supported
and
same
same
with,
conditional
attributes.
B
Typically,
these
things
are
maybe
not
supported.
Remove
the
whole
section
about
actual
amplification
attacks.
There
was
a
lot
of
discussion
seems
like
there
happened,
actual
amplification
attacks
using
Cooper,
but
all
the
description
of
these
attacks
are
so
bad,
so
you
cannot
really
do
any
conclusion.
What
actually
happened-
or
maybe
even
if
it
happened,
done
a
lot
of
clarification
in
the
figures
with
client
was
changed
to
victim
and
server
to
servers,
and
we
made
SVT
out
of
everything.
B
Here's
an
example
of
the
new
figures
where
it
used
to
be
a
client.
It
used
to
be
single
server.
It
used
to
be
no
Gateway
and
after
discussion
with
Sultan
that
didn't
understand
the
attacks.
I
think
this
is
now
and
him
complaining
that
this
attack
was
not
realistic.
I
think
the
name
changes
here
and
the
addition
of
the
Gateway
makes
everything
much
clearer.
How
they
attack
is
actually
dumb,
I
think
there's
basically
no
changes
to
the
text.
B
B
This
draft
to
include
before
it's
published,
I
hope
we
will
publish
it
at
some
point.
I
think
these
are
the
four
points
that
was
discussed
in
an
earlier
session.
I
think
the
draft
does
already
now
raise
awareness.
It
has
some
mitigation
that
in
common
that
the
mitigation
sections
are
quite
slim,
I
agree.
There
should
be
more
mitigation,
sec
sections
to
a
reasonable
level.
B
C
A
B
Yeah
I
I
think
that
maybe
needs
some
analyze.
Some
trying
to
write
I
I
guess
first
point
is
to
point
to
existing
and
then
maybe
in
some
some
cases,
these
mitigations
are
too
soft.
So
maybe
the
draft
should
recommend
to
break,
have
a
bit
stricter
things
or
maybe
in
some
cases
there
are
no
descriptions
and
then
the
draft
might
have
to
describe
new
things,
but
I
think
when
I
started.
This
draft
was
very.
There
was
not
so
much
written
about
multicast.
A
A
I'm
asking
because
there
is
a
danger
that
we
are,
we
are
writing
in
BCP
here
and
that
that
is
not
the
intention
of
a
research
group,
the
document.
So
we
we
should
document
the
state
of
the
art
and,
of
course
the
state
of
the
art
includes
specifications
that
are
already
out
there
and
considerations
for
for
potential
future
specifications.
But
I
don't
think
we
should
be
recommending
stricter
limits
for
something
we.
We
might
very
well
note
that
that
stricter
limits
might
have
more,
but
I
think
we.
A
B
B
D
B
D
D
Guess
I,
wouldn't
mind
if
the
terminology,
the
names
of
them
were
a
little
bit
more
unique
as
opposed
to
application
application
application
using
using
something
so
I,
don't
know,
that's
just
useful
I
think
that's
the
utility
of
having
this
is
that
we
now
now
have
a
common
understanding
of
the
different
kinds
of
attacks
and
we
can
talk
about
in
when
someone's
using
Co-op.
They
can
talk
about.
Oh
and
this
isn't
a
problem.
This
kind
of
attack
isn't
a
problem
or
whatever.
B
B
And
we
are
here
are
so
initial
high
level.
Cs
string
is
to
have
some
general
mitigations
assumption.
Then
you
probably
you
might
need
to
separate
the
direct
mitigations
in
whether
when
you
use
a
security
protocol
and
when
you're
not
using
security
protocol
and
when
you
have
identified
verified
the
address
of
the
destination
and
when
you
have
not,
and
then
here
is
just
very
high
level
sum
of
the
mitigations
that
have
been
discussed
in
this
draft
and
in
other
drafts.
I
think
the
plan
is
to
add
some
more
information
about
this
mitigation.
C
C
The
the
this
actuator
attacks
that
that
you
have
maybe
I
had
been
using
that
document.
Quite
a
lot
for
for
describing
some
of
these
attacks
against
actuators
I
wonder.
Is
there
like
some
consideration
about
this
resource
directory
where,
like
the
responses,
might
be
much
larger?
Let's
say
if
you
do
some
some
Rd
lookup
or
observe
things
in
RDS,
there's
some
special
considerations
that
apply
to
those
kind
of
scenarios
that
is
worth
covering
in
this.
In
this
amplification
attacks
document.
B
I,
would
you
would
it
be
possible
for
you
to
open
an
issue
and
describe
a
little
bit
high
level,
how
you
are
how
you,
what
you're
thinking?
Yes,
why
this
might
be
a
problem,
and
then
we
could
then
I
can
help
analyze
and
see
if
we
can
find
some
something
specific
for
for
that
scenario,
that
should
be
described.
A
A
C
I
do
have
so
yeah
good
to
join,
join
some
of
your
virtually
after,
let's
say,
short
Gap,
so
this
is
work
done
together
with
Gadget
and
and
Dan.
Who
is
also
on
the
call.
This
draft
has
existed
for
a
while
and
there's
been,
let's
say
some,
some
lack
of
also
action
from
the
authors
for
various
reasons
that
have
been
busy,
but
at
least
now
now
some
of
us
have
have
time
to
do
hopefully
finish
off
the
draft
so
quickly
to
to
kind
of
summarize
what
has
changed
since
the
last
time.
C
This
was
presented
in
t2trg
by
then
actually
nothing
much,
except
maybe
the
the
title
of
the
document
itself.
So
at
some
point
we
changed
the
let's
head
title
from
secure
bootstrapping
survey
to
a
survey
of
initial
security,
setup
techniques
for
iot
devices,
but
we
never
really
changed
the
document
name
to
match
the
title
and
I
guess
that
was
raised
as
as
feedback
during
the
last
presentation.
So
now
now
that
is
done.
C
Also,
we
received
some
off
list
feedback
from
Jaime
on
on
specifically
about
Oma.
We
haven't
addressed
this,
but
but
we
do
plan
to
address
it
in
in
the
next
version
when
we
submit
the
draft
so
in
case
there's
someone
who
doesn't
know
what
this
draft
is
about.
A
very
quick
recap.
So,
basically,
this
draft
is
trying
to
capture
different
terminologies
that
are
used
in
in
protocols
for
doing
this
initial
security
setup
of
iot
devices
and
then
see
if
there
is
some
common
patterns
in
in
terms
of
the
terminology
used.
C
C
I
have
example
of
Omar
then,
and
have
some
questions
for
you
in
the
audience
on
how
exactly
to
structure
this,
because
it's
actually
a
little
bit
challenging
when
reading
the
different
protocols.
How
what
exactly
are
the
players
and
and
processes,
but
the
the
protocols
that
we
have
reviewed
so
far
are
listed
on
on
this
slide.
I,
don't
think
we
have
received
any
requests
for
adding
new
ones
or
or
removing
once
from
this
list,
but
if
you
have
feedback
on
that,
that's
always
welcome.
C
C
So
if
you
have
any
feedback
on
whether
there
should
be
some
added
or
some
removed,
then
that's
always
welcome
and
yeah
I
think
we
already
mentioned
that
we
try
to
then
compare
protocols
based
on
what
terminology
players
processes
they
have
and
I
guess
the
document
is
is
not
complete.
We
obviously
have
lots
to
improve.
We.
We
also
look
forward
to
you,
know
your
reviews
and
feedback.
C
But
let's
say
we
would
like
the
next
version
of
the
document
to
be
a
little
bit
major
revision
to
at
least
to
get
in
the
direction
where
we
feel
it's
starting
to
go
to
look
finalized.
It's
it's
not
not
there
yet,
but
before
we
do
this
major
revision,
I
thought
it
was
good
to
take
some
feedback
from
the
research
group
on
how
what
exactly
is
is
useful
and
and
we
would
like
to
make
the
current
document
much
better
than
than
it
is
currently.
C
Sometimes
there
are
protocols
that
support
both
when
there
is
some
Factory
provision
credentials
and
and
some
protocols
that
that
work
in
both
scenarios
when
the
device
is
completely
blank
and
when
there
is
some
credential
so
DPP
would
be
one
example
which
supports
both.
So
so
you
can
have
DPP
running
on
on
a
device
that
can
support
some
kind
of
UI,
which
is
completely
blank.
But
then,
if
it's
a
thermostat
which
doesn't
have
any
UI,
then
it
can
come
provision
with
some
keys.
C
So
there's
always
this
challenge:
that
protocols
have
variance
and
and
trying
to
cover
all
the
different
variations
becomes
challenging,
but
still
from
a
beliefs
point
of
view.
It
is
relatively
easy
to
distinguish
protocols
that
assume
whether
something
is
initially
provisioned
or
or
not,
and
what
happens
when
the
protocol
is
is
finished.
What
becomes
more
complicated
is
the
terminology
because,
let's
say
there
is
no
golden
standard
and
and
commonality
on
how
these
different
standards
use
these
these
terms.
C
So
currently
in
the
draft
we
we
list
bootstrapping
provisioning,
initialization
configuration
and
registry,
but
this
is
basically
a
dumb
grip
of
the
standard
for
these
terms
and
then,
if
the
standard
has
used
that
term,
then
it's
in
this
list.
I'm
not
sure
if
this
is
the
best
approach,
so
I
I
noticed
that
the
standard,
also
or
actually
Jaime
pointed
out
that
the
standard
also
uses
the
term
Discovery.
C
Then
you
discover
what
objects
can
be
provisioned
and,
and
you
write
to
those
objects
or
your
provision
to
those
objects.
So
it's
a
question
for
the
research
group
whether
it
would
make
sense
to
to
not
just
blindly
grab
the
standards
for
this
terminology
and
only
list
the
one
where
they
actually
make
sense
so
in
in
that
case,
we
would
remove
initialization
from
from
Oma
as
an
example.
A
A
So
we
can
say
how
things
like
like
provisioning,
initialization
and
so
on
are
being
used,
and
the
problem,
of
course,
is
that
that
terms
like
initialization,
also
have
a
general
computer,
science
or
even
English
sense,
and
it's
sometimes
necessary
to
find
out
which
of
the
the
meanings
is
actually
used
so
same
thing
for
configuration,
for
instance,
while
provisioning
is
often
a
very
specific
item
that
that
we
can
find
out
how
the
document
is
using
that.
So
this
would
be
a
little
bit
of
a
dictionaries.
I
think
that
that
we
would
be
doing
here.
C
Okay,
so
I
understand
that
for
each
of
these
standards
we
should
list
the
the
terms
and
then
in
what
context
or
what
is
the
meaning?
What
are
they
trying
to
imply
with,
with
the
usage
of
that
terminology,
sure
I
think
it
will
just
make
it
a
little
bit
longer,
but
hopefully
more
useful
document.
I.
Think
that
makes
sense
the
same.
C
Let's
say:
challenge
I
I
noticed
was
with
the
processes
section
so
I
mean
there
is
obviously
some
benefit
of
explaining
how
each
protocol
works
and
is
that
what
we
want
from
the
processes,
or
should
we
only
focus
on
what
are
the
processes
expected
from?
Let's
say,
an
end
user
or
a
network
administrator?
C
Does
the
protocol
require
you
to?
You
know,
have
some
server
running
in
the
cloud
from
a
service
provider
or
or
do
you
do
you
think
it
would
actually
make
sense
to
have
like
a
detailed
explanation
of
how
each
protocol
actually
works?
So
how?
How
does
Oma
work
in
my
opinion
is,
is
less
useful?
I
would
rather
find
it
more
useful
to
to
explain
what
is
expected
from
the
user
and
there
again
it's
not
clear
in
the
standard.
C
What
is
expected
from
the
user,
but
I,
guess
or
or
the
owner
I
would
think
it's
more
like.
They
need
to
configure
the
location
of
their
lightweight
M2M
server
on
the
bootstrap
server
and
maybe
at
the
end
of
the
process,
verify
that
the
device
actually
shows
up
on
on
the
server.
But
these
are
not
then
explicitly
listed
in
in
the
standard,
as
as
processes.
C
C
I
would
think
that
it
would
be
easier
to
distinguish
protocols
based
on
whether
they
require
some
involvement
from
the
manufacturer
or
not,
and
whether
they
require
like
some
kind
of
a
server
or
a
service
provider
running
a
server
or
or
the
user
running
a
server,
but
but
certainly
not
listing
like
every
every
player
mentioned
in
in
the
standard.
So
we
would
try
to
trim
down
the
the
list
unless
the
research
group
thinks
otherwise.
A
Yeah
I
think
processors,
players
and
beliefs
are
really
the
the
triangle
that
needs
to
be
discussed
together.
So
the
the
point
about
a
player
is
well
there's.
Another
word
that
we
are
often
using,
which
is
party
which
is
related
to
player,
but
a
party
may
be
actually
comprised
of
multiple
players
which
have
different
states.
They
are
going
through,
while
together
being
that
that
party,
so
who
controls
something
is,
is
one
aspect
of
of
party,
but
also
the
connect
collected.
Knowledge
of
of
the
players
in
in
the
party
and
I.
A
Think
the
the
interesting
thing
here
about
the
players
is
not
so
much
what
are
the
detailed
processes
and
and
how?
How
does
the
document
with
a
relatively
complicated
set
of
players
actually
Define
the
the
individual
processes?
But
the
point
is
that
before
something
the
the
device
or
the
application
can
can
do
something
useful,
certain
beliefs
need
to
be
created
instilled
and
these
beliefs
are
in
specific
players.
So
it's
not
not
useful
to
have
a
belief
that
that
is
freestatting.
A
A
C
So
in
case
of
oma,
what
would
be
like
I
at
least
I
listed
these
as
the
players,
but
Maybe
I?
Don't
know
we
probably
are
running
out
of
time,
so
we
can
also
continue
the
discussion
on
on
the
mailing
list,
but
I
think
having
like
example
for
one
specific
protocol
would
then
help
make
it
easier
for
for
other
protocols.
A
C
Okay,
I
won't
take
much
more
time
so
well,
I
think
this
research
group
has
experts
on
different
protocols
that
we
are
trying
to
to
cover.
So
if
you
want
to
help
us
identify
these
players,
processes
parties,
beliefs
for
any
of
them,
we
we
look
forward
to
comments
whether
it's
on
on
the
mailing
list
or
or
pull
request.
C
E
D
D
D
Is
that
if
someone
is
happy
with
the
Cheetos
keeping
their
their
storage
unit
closed
because
that's
all
the
security
they
require,
then
they
should
be
able
to
express
that
fact
that
that's
the
level
of
security
they
have
and
that's,
okay,
and
but
on
the
other
hand,
if
you
want
something
stronger,
then
you
should
be
able
to
express
that,
and
we
should
be
able
to
talk
about
in
a
reasonable
term
and
reasonable
words
as
to
what
it
is
that
you're
actually
doing
foreign.
So
some
changes
some
interesting
things
that
have
come
forward.
D
There
is
a
requirement
from
last
year
from
the
the
certification
Authority
and
browser
Forum
known
as
the
cab
Forum,
not
always
with
the
slash
in
it,
and
they
basically
are
a
group
that
allows
the
cas
and
the
browsers
to
decide.
Basically
what
trust
anchors
wind
up
in
your
browser
and
they're,
for
which
certification
authorities
can
do.
What
so
they've
decided
that
I
think
in
in
as
a
result
of
the.
D
What
is
the
overall
effect
of
this
is
that
we
had
in
this
document
a
bunch
of
questions
as
to,
for
instance,
how
is
the
key
generated
with
you
know?
A
couple
of
internal,
you
know
views
so
that's
kind
of
now
I'm
going
to
expand
it
out
into
some
of
the
terminology
that
the
the
design
team
in
lamps
has
has
discussed
and
they're
going
to
figure
out
how
to
encode
this
into
a
attestation.
D
D
C
D
D
So
if
you're
going
to
put
a
trust
anchor
into
the
device,
then
you
have
to
also
know
something
about
how
does
the
management
of
the
private
key
work
out?
So
that's
why
that's
the
relationship
and
the
useful
thing
is
the
set
of
terminology
that
those
that
that
attestation
has
to
go
with.
So
let's
have
some
common
terminology
between
this
and
the
other,
the
other
areas
where
the
it's
the
terminology
is
being
used.
D
D
Well,
that
would
be
a
device
generated
key
now,
if
you
generate
it
in
the
device
and
store
it
in
a
puff
based
on
the
puff.
That
may
actually
be
a
symmetric.
Key
based
thing
depends
on
how
you
use
the
the
you
said
puff,
so
that
typically
means
that
you
have
some
symmetric
key
that
comes
out
of
the
air,
but
that
means
that
the
key
is
generated
in
the
device.
C
C
D
D
D
A
Yes,
so
thank
you
for
for
this
presentation
and
for
giving
us
a
timeline.
I
think
this
is
a
useful
document
because
it
gets
some
communication
going
there
that
wouldn't
happen.
Otherwise,
so
I
think
this
is
a
valuable
result
and
yeah.
We.
We
need
to
look
at
the
the
definitions
of
the
terms
and
find
out
whether
they
are
useful
in
our
respective
corners
of
the
world
and
then
come
into
that.
A
We
want
to
automate
our
setup
processes
as
much
as
possible,
both
because
of
limited
user
interfaces
in
the
devices
and
because
we
have
so
many
of
these
devices
that
we
can't
attend
to
each
of
one
like
like
to
a
pet,
and
we
also
have
different
kinds
of
Discovery
and
I
I
listed
two
year.
One
is
network
discovery
and
the
other
one
is
resource
Discovery,
and
they
come
together
in
various
models
or
separate
in
other
models
and,
of
course,
how
this
is
structured
influences
what
we
can
do
on
the
security
site.
A
A
We
have
confidentiality
which
is
adversity,
cannot
learn
things
that
shouldn't
learn.
Integrity
and
adversity.
Adversary
cannot
inject
information
or
smooth
information
that
that
what
could
be
used
to
violate
other
security
objectives
and
finally
availability.
So
there
there
is
no
way
for
an
adversary
to
disrupt
functioning,
and
we
can
look
into
a
little
bit
more
detail
here.
So
why
do
we
need
confidentiality?
A
So
the
the
the
the
the
Privacy
requirements
may
maybe
somewhat
surprising,
don't
do
not
necessarily
come
directly
from
the
the
function
of
the
devices
and
even
the
simple
use
of
stable
identifiers
creates
linkability
issues
with
which
is
being
worked
on
and
we
have
a
whole
working
robot
in
us
to
actually
handle
the
the
fallout
of
of
this
upgrade
so
that
that's
one
aspect.
Privacy
and,
of
course
privacy
is
not
just
personal
privacy.
A
It's
also
privacy
of
business
information
that
has
similar
properties,
but
also
we
want
to
avoid
disclosing
things
that
would
increase
the
attack
surface,
like
the
the
exact
version
of
software
that
runs
on
a
device
should
not
necessarily
be
available
to
everyone.
It
should
certainly
be
available
to
the
manager
of
the
network,
but
not
necessarily
to
to
somebody
to
render
randomly
is
in
the
vicinity.
A
So
in
the
past,
in
the
past
we
have
often
just
Fallen
back
to
network
security
or
subnetwork
security.
Just
assuming
that
our
Discovery
is
secure
because
we
we
can
can
confine
it
into
this
space
and
that,
of
course,
becomes
difficult
in
an
IP
environment
for
resource
Discovery,
and
we
talked
about
resource
directory.
A
A
So
that
that's
one
aspect,
and
that
that
requires
thinking
about
partial
authentication,
partial
authorization
and
one
thing
that
we
have
already
discussed
in
vishi
in
2017
is
that
it
would
be
nice
to
have
secret
handshakes,
which
are
mutual
authentication
procedures
that
that
actually
complete
before
anything.
Is
this
close
to
a
non-authorized
party,
and
that
seems
to
be
a
critical
building
block
to
to
get
secure,
Discovery
going.
A
So
the
point
of
this
talk
was
to
to
raise
questions,
and
what
I
would
like
to
find
out
is.
Are
these
interesting
problems?
Are
these
important
problems
we
should
be
solving
or
we
should
try
to
get
researchers
to
solve,
or
we
should
simply
try
to
document
the
state
of
the
art
and
and
potential
gaps,
and
if
we
think
so,
who
would
be
interested
in
in
doing
something
about
this?
Should
we
try
to
write
some
of
this
up
and
yeah?
If,
yes,
maybe
you
should
allocate
time
for
a
meeting
of
interested
people?
E
Tication
was
a
bit
like
if
you
don't
know
you
authenticate
to
why.
Why
does
it
matter,
except
if
you
want
to
conceive
to
others,
of
course,
but
I
have
a
question
first
question:
is
we
have
the
resource
discovered
the
core
resource,
Discovery,
RFC
and
I?
Suppose
some
of
these
things
are
are
considered
in
that
and
when
it
comes
to
Discovery,
how
does
this
position
itself
to
that
I
mean,
of
course,
it's
not
specifically
for
the
resource
directory,
but
isn't
isn't
the
same
type
of
security
problems
that
should
have
been
answered
in
that
RC.
A
So
it's
already
an
advanced
phase
of
Discovery.
So
the
the
the
approaches
in
that
document
do
not
necessarily
transfer
to
early
discovery
and
early
Discovery,
the
the
part
that
would
actually
benefit
from
a
secret
handshake
that
that
definitely
cannot
expect.
That
authentication
already
has
been
done
at
the
time
when
the
test
decided
whether
to
disclose
some
information
or
not.
A
A
Don't
have
a
way
to
authenticate
to
the
resource
directory,
it
is
going
to
give
you
only
limited
information,
and
that
is
an
authorization
model
that
I
think
is
reasonably
well
understood.
Less
understood
less
well
understood
is
whether
that
information
is
enough
to
actually
get
you
going
into
a
state
where
you
actually
can
can
authenticate
to
the
resource
directory.
A
D
So
this
is
all
very
interesting
and
I
I
I
I
I
would
love
to
have
more
conversations
about
it,
but
I
don't
know
what
we
do
with
it
and
I
guess:
I'll
say
that
like
I,
don't
know,
I,
don't
know
in
the
end.
I,
don't
know
what
the
body
of
work
that
you're
proposing
is,
if
it's
more
than
just
talking
about
naming
and
discussing
the
or
writing
down
the
attacks,
but
I
guess
I'll
say
that
Christian
redema
tried
to
do
the
secret
handshake.
D
You
know,
I
can't
tell
you
whether
I
exist
until
I
know
whether
or
not
you're
supposed
to
exist
in
dnsse
what
it
was
about
eight
years
ago,
maybe
2015
or
something
I
think
it
was,
and
I
was
sad
that
it,
the
work,
didn't
go
anywhere,
partly
because
I
don't
think
anyone
was
quite
ready
for
the
for
the
concept
we
just
don't
have
broadly
interoperable
iot
networks.
Yet
such
that
I
really
could
wander
down
the
street
and
learn
whether
or
not
there
are
insulin
pumps
to
steal
or
not.
D
A
A
A
F
A
But
one
one
interesting
thing
about
Bluetooth
networks
is
that
that
the
various
products
that
are
out
there
usually
need
a
manual
step
to
actually
set
up
some
initial
security
and
the
the
cases
where
that
is
not
the
case.
Discovery
is
really
awful,
so
I
have
to
be
really
careful
in
my
apartment
not
to
send
music
to
the
the
TV
of
the
guy
living
upstairs
to
me,
it's
really
hard
to
avoid,
because
my
systems
discover
that
thing
and
and
start
sending
audio
to
it.
Yeah.
E
F
F
Know
I
was
referring
to
both
of
connecting
my
own
devices
to
stuff
that
work
here,
so
that
I
can
see
some
neighbors
devices
which
can
be
used
for
entertainment.
If
you
want
to
block
some
annoying
music
to
them,
but
in
general
it
seems
to
work.
Obviously
the
devices
that
are
in
proximity
of
each
other,
which
may
or
may
not
depends
on
how
you
define
it
the
case
for
what
you
are
doing,
but
it
definitely
works
for
my
stuff.
F
A
F
A
G
Yes,
hi
I
think
it's
an
interesting
topic
and
I
confess
I'm,
not
just
by
the
model
considered
in
the
resource
directory.
I
tend
to
forget
about
any
early
Discovery
issues
but,
like
Milan,
said,
I
think
we
should
first
understand
the
scope
better
and
maybe
a
first
starting
point
can
be
defining
a
taxonomy
of
trust
models
for
the
early
Discovery
phase
and
like
kickstarting.
That
can
be
a
topic
for
a
follow-up
meeting.
For
example,.
G
A
Great,
thank
you.
Thanks
yeah.
We
have
six
minutes
over
time,
so
I
think
we
are
done
with
a
queue
and
I
think
it's
very
good
feedback
that
we
have
to
think
about
scope.
I
deliberately
presented
this
as
a
very
wide
open
thing,
but
of
course
we
we
have
to
focus
and
I
think
that
that's
one
of
the
things
we
should
do
in
that
list
discussion
and
maybe
first
meeting
so
thank
you
for
your
input
and
I
think
we
are
pretty
much
done
with
the
agenda.
A
Let's
oops
go
to
the
agenda
yeah
we
are
done
so
I
expect
we
will
have
further
Point
meetings,
work
meetings
in
in
the
next
few
months,
maybe
at
the
Cadence
of
about
one
per
month.
So
if
you
are
interested
in
having
a
meeting
like
today
on
a
specific
topic
or
set
of
topics,
please
talk
to
the
Jazz,
and
apart
from
that,
thank
you
for
joining
this
meeting
and
see
you
on
Meet,
echo
or
physically,
as
an
IDF
later
this
year,.