►
From YouTube: IETF108-SECDISPATCH-20200730-1100
Description
SECDISPATCH meeting session at IETF108
2020/07/30 1100
https://datatracker.ietf.org/meeting/108/proceedings/
A
A
So
these
are
a
list
of
useful
links.
There
is
the
jobber
there
the
minutes.
Thank
you
so
much
to
our
minute
taker,
dan
and
carrick.
You
have
a
link
to
the
slides
and
then
our
names
so
chairs.
My
name
is
francesca
palumbini
with
the
richard
barnes
and
kathleen
moyerty,
the
least
list.
A
Today
we
have
a
quite
good
agenda
so
for
this
intro
that
I'm
doing
now
we're
gonna
do
a
test
hum
then
we're
gonna
have
michael
presenting
the
idev
id
considerations,
the
strong
assertions
of
iot
network
access
requirements,
brandon
and
then
the
new
name
system,
martin,
and
we
have
20
minutes
of
any
under
business
of
or
openmic
so
next
slide.
A
A
For
today,
I
would
like
to
to
remind
the
dispatch
process,
so
the
ground
rules
are
the
exact
dispatch.
The
recommends
next
step
for
new
work,
but
does
not
adopt
draft.
So
please
keep
that
in
mind.
A
The
possible
outcomes
which
are
also
listed
in
our
charter
are.
This
are
listed
here
and
yeah.
I
I
see
that
there
is
one
yeah,
so
these
are
the
possible
outcomes.
Direct
to
an
existing
working
guru
propose
a
new
focus
working
group
or
both
redirect
to
a
ad
sponsorship
state
that
this
is
require
additional
discussion
or
community
development
is
required,
and
the
itf
should
not
work
on
this
topic
next
slide.
A
For
some
participation
guidelines,
since
this
is
the
first
time
using
this
tool
and
please
when
I,
when
you
are
at
the
microphone
state,
your
name
before
speaking,
keep
the
dispatch
question
in
mind
when
you
want
to
do
a
some
comments.
So
the
content
discussion
is
is
very
good,
but
we
want
to
get
to
this
patch
at
the
end
of
the
presentation
of
the
time
slot
and,
if
possible.
Please
keep
your
comments
to
2-3
minutes
so
try
to
go
to
the
point
and
also,
if
possible,
request
both
audio
and
video
when
joining
the
queue.
A
A
So
that's
the
hum
button.
If
you
can
press
it
and
I
will
start
a
new
hum
and
you
can
just
decide
if
you
want
to
hum
softly
or
loudly
or
also
not
hum,
that's
also
a
possibility.
A
A
Otherwise
we
can
start
with
the
first
presentation.
So,
yes,
michael,
you
can
request
a
screen
sharing
and
video
and
everything.
B
A
A
C
Okay,
so
I'm
here
to
talk
about
a
document:
that's
evolved
out
of
a
bunch
of
other
ones
and
just
a
little
bit
of
funny
background
1972,
my
dad
returned
from
london
with
a
baby
and
some
software
in
1975.
He
got
a
job
where
they
had
a
computer
and
he
let
me
play
with
it,
but
I
had
to
learn
to
read
first,
so
he
read
me
books
your
little
turtle,
especially
cat
in
the
hat,
comes
back.
We
read
it
enough
a
lot.
He
actually
wore
that
book
out.
It
actually
fell
apart.
C
C
If
you
remember
that
thing,
and
eventually
he
asked
questions
like
how
does
it
know
who
he
can
trust
and
here's
me
explaining
what
a
bios
is.
Here's
him
asking
some
very
intimate
questions
about
iot
devices
and
him
getting
pissed
off
because
he
doesn't
want
to
do
an
update
now
and
every
time
I
thought
I
convinced
him
what
was
going
on.
C
He
would
just
say:
well,
you
haven't
told
me
anything,
you've
just
added
a
turtle
and
there
was
a
stack
of
turtles
going
down
all
the
way
to
you
know
what
does
electrons
do
when
the
computer
first
goes
on
and
things
like
that
and
he
would
say,
look
you're
just
having
little
and
literal
and
littler
cats.
I
want
to
know
what
is
in
the
littlest
cat.
Can
you
tell
me
that?
C
Well
at
some
point
he
said
it's
got
to
stop.
There
must
be
something
down
there.
He
would
complain,
but
this
document
is
about
what's
down
there?
Okay,
it's
about
the
quality
of
the
turtles.
How
do
they
get
there?
How
can
they
be
trusted?
How
much
and
for
what?
Because
different
users
have
different
risk
mitigation
problems?
C
There
are,
as
far
as
I
can
see
three
methanol
ways
to
provision
initial
routes
of
trust.
You
generate
them
on
the
device
you
generate
them
in
the
factory
or
you
do
something
with
a
co-generation
with
a
common
key.
C
But
ultimately,
what
you
should
understand
is
that
the
software
update
trust
anchor
rules,
everything
because
he
who
gets
to
decide
what
software
you
run
decides
how
you
do
everything
else
and
that's
discworld
and
there's
a
some
elephants
on
a
turtle.
So
talking
about
elephants.
So
the
problem
I
discovered
is
that,
as
you
try
to
find
out
how
people
provision
different
things,
you
discover
that
none
of
them
will
talk
about
the
elephant
in
the
room
because
of
a
non-disclosure
agreement,
and
so
you
want
to
know
well
how
do
you
actually
do
this?
C
They
kind
of
mumble
that
they
can't
talk
to
you
about
that,
and
if
you
buy
enough
parts
they
could
maybe
sign
an
nda
and
then
life
will
be
good.
So
my
proposal
is
the
same
proposal.
We
always
do.
Is
we
add
a
layer
of
indirection
and
to
do
that,
we
need
to
have
some
terminology
that
an
auditor
who
could
sign
the
nda
could
return,
and
so
this
is
the
basic
model.
C
C
That's
an
about
audit
processes
and
a
bunch
of
other
stuff
and
says
nothing
useful
about
keys,
and
this
document
is
not
going
to
make
any
recommendation
as
to
appropriate
solution
in
a
given
situation.
This
is
not
a
if
you
have
this
risk,
then
you
should
have
this.
The
solution
this
document
is
here
are
some
solutions
in
their
properties.
C
C
So
the
history
of
the
document.
We
had
the
two
documents
in
anima
they
are
in
their
last
throws
of
being
published,
and
but
they
didn't
cover
everything
and
a
lot
of
there
were
a
lot
of
questions.
Well,
how
do
I
build
this?
How
do
I
build
that?
How
do
I
build
the
other
thing?
C
And
so
I
wrote
a
document
last
fall
on
the
registrar
considerations
and
it
includes
some
advice
on
writing
an
enterprise,
private
ca
and
I
wrote
a
document
about
manufacture,
and
that
includes
how
do
I
write
around
the
vendor
private
ca
that
I
need
for
idev
ids,
and
how
do
I
sign
the
vouchers
and
it
was
in
creating
this
document
that
I
ran
into
these
ndas
and
these
other
problems,
and
so
I
split
the
document
up,
and
so
we
have
this
document
that
you're
looking
at
now
and
the
other
die,
which
is
basically
intended
to
still
be
prescriptive.
C
So
what
to
do
this
supports
work
and
suit?
This
is
the
software
update
key
in
teep,
because
teep
uses
suit
in
rats,
because
rats
needs
an
idef
id
in
order
to
do
an
attestation
for
the
tester
to
run,
and
it
also
needs
a
bunch
of
other
trust
anchors
in
the
other
parts
that
need
to
be
provisioned
in
some
ways.
Obviously
this
supports
anima.
C
You
could
put
this
in
lamps
after
all,
revising
cmp,
which
is
in
fact
a
certificate
enrollment
protocol
there,
and
if
we
were
going
to
do,
we
did
some
work
on
est
as
well
in
there,
so
you
could
put
it
there
and
there's
a
bunch
of
other
working
groups
that
you
know
also
could.
But
again,
this
is
not
a
protocol,
I'm
not
writing
a
protocol
document.
This
does
not
say
anything
about
any
bits
on
the
wire:
it's
not
an
applicability
draft.
C
So
what
to
do
I
think
what's
left
is
you
could
do
it
in
sag,
but
it
would
need
a
lot
of
of
of
review.
It
could
be
any
sponsored,
but
I
don't
think
it
would
get
enough
for
review
questions.
D
Mohit
hi,
can
you
hear
me.
D
Yeah
hi,
this
is
muhit,
so
in
principle,
I
think
having
these
kind
of
recommendations
is
good.
What
I'm
worried
about
is
how
do
we
get
actual
people
who
are
in
like
in
the
supply
chain
business
and
have
seen
what
a
factory
floor
looks
like
and
what
like?
What
are
the
complexities
involved?
How
do
we
get
those
people
involved
and
those
people
to
actually
review,
because
I'm
worried
we
might
end
up
writing
something?
D
That's
absolutely
not
possible,
and
my
second
concern
is
like
again,
it's
kind
of
related
to
the
first
concern
that
these
things
are
way
more
complicated
than
than
what
they
seem.
C
Yeah,
I
think
your
concern
about
getting
the
right
people
is
absolutely
a
problem
on.
I
I've
been
passing
the
existing
documents
as
I
in
its
various
incarnations,
I've
been
trying
to
pass
it
into
other
places.
In
fact
I've
been
trying
to
say
yes,
I
understand
you
can't
answer
it,
but
maybe
you
can
pass
it
to
the
person
who
is
authorized
to
answer
this.
C
Maybe
they
can
answer
it
or
maybe
they
can
tell
me
what's
wrong
and-
and
I
agree
that
is
a
problem,
and
it
is
something
that
I
believe
that
a
little
bit
of
effort
and
a
a
fairly
large
amount
of
a
lot
of
a
lot
of
talks
and
presentations
that
will
get
the
right
people
to
review
this
and
contribute
it
to
it.
C
I
I
think
that
for
the
companies
and
the
manufacturers
that
do
do
have
spent
a
lot
of
stuff,
I've
heard
numbers
like
10
million
dollars
to
to
make
this
work
well
in
a
chip
fab
line
that
for
those
who
who
have
invested
that
money
rather
than
thinking.
Oh,
I
don't
want
to
tell
them
all
my
secrets.
I
would
say
that
maybe
the
message
is
well.
C
Wouldn't
you
like
to
force
all
of
your
other
competitors
to
do
something
at
least
as
as
complicated
and
we're
not
actually
asking
them
to
tell
us
their
secrets,
but
rather
what
are
the
results
that
we
can
depend
upon
afterwards.
E
A
few
people
after
me
in
the
queue
so
I'll,
try
to
keep
it
brief
and
high
level
sort
of
following
up
on
mohit's
point.
E
C
I
would
be
happy
to
not
give
them
guidance,
but
rather
to
to
listen,
and
they
would
say
well
I
made
one
that's
orange
and
someone
says
I
need
one.
That's
blue
and
we
would
say:
oh
okay,
so
you
have
a
blue
process,
and
that
means
that
when
someone
is
doing
an
audit
of
a
complicated
system
with
many
mcus
and
other
things
like
this,
that
they
would
say
well,
I
I
need
to
have
devices
that
are
at
least
all
in
that
same
category
right
and
how
they
achieve
it.
C
Not
our
problem,
that's
you
know
some
other
evaluation
process,
but
at
least
they
would
be
saying
to
us.
Well,
these
are
devices
of
a
particular
quality
and
and
they've
been
manufactured
with
a
particular
care
and
therefore
they're
suitable
for
your
stuff,
and
all
we
want
to
do
is
enumerate
what
those
different
categories
are
of
care.
A
F
There
we
go,
I
think
you
may
have
just
answered
my
question
michael,
so
I'm
just
double
checking.
So
the
thinking
is
that
we
effectively
have
a
reference
model
of
hypothetically.
How
people
should
do
it
and
then
manufacturers
would
attest
to
I'm
not
going
to
show
you
all
of
the
details.
But
I'm
I'm
number
two
out
of
section
two
of
this
document
or
if
you
had
an
auditor
drop
in,
they
would
come
back
and
say
yes.
F
Yes,
I
saw
all
the
all
the
stuff
behind
behind
the
door
and
they
really
do
conform
to
number
three
on.
F
C
Yeah,
so
I
think
that,
from
what
I've
heard
from
a
number
of
partis
of
people,
lawrence
lundbling,
for
instance,
has
said
a
lot
of
you
know
things
and
then
stopped
in
the
middle
of
a
sentence,
for
instance
as
oh
I
can't
say
that
and
and-
and
so
I
said-
okay
well,
it
would
be
nice
if
you
could
simply
smile
at
the
right
point
and
then
it
would
be
great.
So
I
think
I'm
in
the
right
place.
C
I
got
this
private
message
actually
about
this.
Makeup
may
interact
with
nist
800-63
and
that's
also
some
of
the
feedback.
I'd
like
to
get
is
there's
this
document
that
you
may
have
missed,
and
so
I
think
I
have
looked
at
that
document
and
I
think
it
was
specific
to
specific
things.
But
I'll
look
back
come
back
at
it
again.
G
Yeah
hi,
this
is
hank.
Audio
is
fine.
A
G
Excellent,
so
yeah,
I
think
there
are
a
lot
of
I
hold
on
a
lot
of
supply,
dynamic,
directed
psychographs
out
there
that
people
often
perceive
as
supply
chains
and
and
yes,
therefore,
I
think
it's
very
important
to
have
a
lot
of
people
involved
that
know
how
these
work,
but
at
the
same
point
it
is
very
important
to
guide
that
discussion
very
carefully
and
revisit.
G
I
don't
know
I
think,
as
is
the
problem
statement
that
is
the
heart
of
this
id
and
revisit
that
and
then
do
sanity
checks
on
it
and
then
still
align
with,
because
everybody
there's
there's
so
many
people
involved
in
this
that
this
might
be
a
never-ending
thing,
and
then
this
becomes
this
turtle
stack
itself.
So
I
think
we
have
to
have
a
very
precise
vision
problem
statement
that
we
revise
iteratively
like
a
mandating
milestone,
and
then
this
could
work.
I
think.
A
H
Okay,
this
does
seem
like
something
that
would
be
useful
to
have,
but
I
don't
really
think
it's
an
internet
question.
I
is
something
like
like
like,
like
the
way
that
certificates
are
public.
Private
key
certificates
for
cas
are
generated
and
handled
it's
important
to
us,
but
it's
not
really
our
thing,
and
this
is
even
less
our
thing
in
the
sense
that,
like
these
devices
are,
you
know,
are,
are
like
endpoints
that
have
specific
policies,
not
internet
visible.
H
I
also
don't
really
think
that
we're
going
to
be
given
the
difficulty
you
need
to
be
having
and
getting
people
to
to
directly
engage
the
the
idea
that
sort
of
the
ways
to
work
is
that
some
small
numbers
sort
of
go
back
and
forth
for
those
people
who
aren't
going
to
publicly
engage
and
and
and
like
watch
for
like
which
way
they
tilt
their
head
doesn't
seem
like
it's
gonna
work
out
real
well.
H
So
I
think
if
those
people
want
to
have
something
they
should
form
their
own
consortium
allah
and
figure
it
out
and
publish
some
stuff
like
the
brs
which,
by
the
way,
do
have
a
bunch
of
material
on
this,
which
runs
quite
long,
which
mostly
says
you
have
you
better
describe
something
in
your
c
in
your
in
your
cps?
So
I
I
think
that,
while
this
is
interesting,
we
should
not
do
it.
H
I
Ahead,
what
do
you
want?
So
I'm
not
arguing
against
this,
but
I
think
we
do
need
to
be
a
little
careful
that
people
don't
get
the
wrong
impression
from
it
just
because
you
have
sort
of
a
checklist
and
they
I
fall
into
this
bucket
doesn't
actually
mean
that
the
system
that
gets
generated
is
secure
right.
I
Like
your
example
of
the
largest,
the
cheater
probably
meets
a
whole
bunch
of
checklist
things,
but
the
ultimate
system
doesn't
work
well
and
there's
a
large
risk
that
auditors
don't
end
up
understanding
what
they're
doing
and
just
go
through
a
bunch
of
checklists
and
be
like
yes
did
this,
yes,
did
that,
therefore,
system
equals
good.
So
just
a
search
box
right.
J
Question
for
you,
michael
on
the
ndas,
and
what
you've
learned
about
them.
What
I'm
wondering
is
if
the
ndas
would
actually
prevent,
say
auditors
from
saying
what
color
it
is
in
others.
I
find
that
the
draft
is
actually
quite
useful,
but
the
question
is:
is
it
actually
such
that
nobody
would
be
allowed
to
use
the
draft
because
the
ndas,
or
can
you
say
anything
more
about
the
nature
of
the
ndas.
C
J
C
Yeah,
so
you
know
what,
if,
if
that,
if
we
went
down
that
road
a
little
bit
and
we
discovered
that
was
the
case,
then
I
would
agree
agree
that
we
should
just
abandon
it
and
that
the
only
way
forward
is
what
eckard
suggested,
which
is
that
the
relevant
industrial
for
are,
would
have
to
basically
repeat
this
work
in
each
in
each
of
those
places.
C
I
I
my
experience
is
that
they
look
those
fora.
They
look
to
us
for
the
the
the
fundamental
underlying
questions
and
that
you
know
determining
which
color
of
security
they
need
and
whether
the
cheeto
was
sufficient
is
something
that
they
actually
do
rather
rather
well,
and
and
they
do
it
with
their,
they
do
it.
They
do
it
with
their
own
risk
at
it
their
own
peril
right.
C
So
they
they
know
that
they're
gonna
have
to
live
by
these
rules,
and
things
like
this
so
but
at
the
same
time
they
do
come
back,
and
you
know
they
talk
about
5280
certificates
and
cms
and
s-e-p-s-s
s-c-e-p
and
all
this
kind
of
stuff.
But
they
fundamentally
look
to
us
for
the
f
for
the
building
blocks.
K
Hi
am
I
on
yeah,
I
guess
so.
I
think
this
is
kind
of
neat.
I
tend
to
not
like
architectural
block
diagrams
as
ietf
documents
and
to
answer
francesca's
question.
I
think
it's
premature
to
adopt
this
anywhere
short
of
having
some
part
of
industry
sign
on
and
agree.
I
suggest
maybe
go
to
something
like
the
trusted
computing
group,
which
has
a
track
record,
even
if
it's
only
one
instance
of
working
with
the
itf
for
the
suit
rats
keep
stuff.
Otherwise
this
is
going
to
land
with
a
thud.
K
L
K
C
M
You
can
hear
me
a
couple
of
points.
One
is
that
it
seems
you
know
in
terms
of
describing
what
color
is
this
or
classification
is
this,
you
is,
is
you
you
become
similar
to
certification
programs
because,
like
the
gp
general,
the
global
platform,
tee
certification
program
would
classify
do
some
of
the
classification.
M
The
fido
certification
program,
which
I
worked
on,
also
does
some
of
this
classification.
It
doesn't
specify
implementation
or
architecture
or
anything
like
that,
but
it
does
set
requirements,
so
you
can
kind
of
know
how
well
does
it
do
the
these
these
things?
So
there's
there's
in
some
way
there's
some
clues
in
the
certification
programs
and.
L
M
Terms
of
classification-
that's
that's
one
thing.
Another
thing
is
that
it
seems
like
a
lot
of
the
value
of
this
is
because
a
lot
of
people
want
to
know
yeah.
So
it's
it's
not
for
maybe
it's
not
because
the
we're
trying
to
drive
the
manufacturers,
it's
because
a
lot
of
us
want
to
know
what
they're
doing
and
the
third
one
about
the
tcg
is.
The
tcg
is
definitely
a
particular
architecture,
driven
by
some
particular
requirements
of
in
a
particular
way
there.
It's
not
a
general
solution.
It's
for
example.
C
So
a
lot
of
this
has
come
from
supply
chain,
auditing
problem
right
and
there
are
some
high-level
efforts
to
make
a
lot
of
this.
C
This
happen
in
a
number
of
other
places,
but
what
was
obvious
to
me
is
that
there
was
no
low
level
description
that
they
could
rely
upon
and
that
that,
as
the
number
of
parts
that
have
security
gu
in
them
increases
hundreds
of
mcus
in
an
automobile
that
the
ability
of
for
them
to
actually
go
and
investigate
each
one
becomes
less
and
less,
particularly
as
there's
multiple
layers
of
subsystems
involved,
and
this
is
where
some
of
this
effort
you
know
came
from
is
is
trying
to
make
something
that
people
could
point
to
at
a
higher
level.
A
Okay,
I
think
we
had
leaf
in
the
queue,
but
he
stepped
off
the
queue.
I
don't
know
who
wants
to
say
something.
C
No,
I
don't
have
a
lot
more
to
say.
There
are
some
links
that
I
put
in
the
slides
some
of
the
conversation.
If
you
want
to
catch
up
on
where
they
are,
and
if
you
don't
know
anything
about
turtles
or
cats
in
the
hats,
there's
some
something
you
could
watch
for
that
thanks.
N
Thanks,
michael
so
just
wrapping
up
a
bit
here,
I
think
what
I
was
hearing
from
the
feedback
from
the
floor
here
was
a
lot
of
feedback
that
this
seems
a
bit
of
field
from
where
the
ietf's
core
focus
is
and
that
we
need
to
get.
If
we're
going
to
do
something
here,
then
we
need
to
get
some
clear
indication
that
we're
going
to
have
the
relevant
folks.
N
Both
you
know
producers
of
devices
that
would
be
conforming
to
this
or
are
producing
things
that
would
be
categorized
according
to
this,
and
the
folks
would
be
consuming
that
you
know
showing
up
and
and
saying
that
they'd
contribute
to
this
work,
and
I
don't
think
we
quite
have
that
right
now,
or
at
least
especially
on
the
device
side.
I
think
we
may
have
some
consumers
here,
but
not
so
much
on
the
vendor
side.
N
So
I
think
this
sounds
to
me
like
it's,
it's
a
no
for
now,
but
maybe
could
come
back
if
we
had
some
of
those
the
vendor
involvement
and
people
saying
they
could
speak
to
those
architectures
a
little
more
directly
make
sure
we
had
the
right
taxonomy.
N
Does
anyone
want
to
stand
up?
I
don't
think
we
need
to
take
it
home
because
the
feedback
was
pretty
uniform
on
that
point,
at
least,
but
if
anyone
wanted
to
stand
up
and
say
that's
the
wrong
decision
like
that
was
the
time.
N
All
right,
I
think,
we'll
consider
that
dispatched.
Then
thank
you,
michael
for
bringing
this
up.
I
agree
with
some
of
the
folks
in
the
queue
this
is
you're.
Getting
these
sort
of
things
getting
some
taxonomy
would
be
useful.
We
just
need
to
make
sure
we
have
the
right
community.
O
Rights,
sorry,
it
takes
a
minute
to
turn
all
of
the
things
on
all
right,
the
well.
The
title
is
indicative
of
where
this
originated.
I,
I
guess
michael
you're,
a
tough
act
to
follow
all
of
those
all
of
those
turtle
references
I
don't
have
any.
Maybe
there
are
some
turtles
here
anyway.
So
the
big
question
that
I'm
trying
to
answer
is
who
is
actually
qualified
to
define
what
a
device
should
do
when
it's
connected
to
your
network?
O
So
the
the
problem
domain
here
is
essentially
around
where
mod
urls
come
from
and
how
they're
authenticated.
So
in
the
existing
mud
infrastructure,
we
have
both
unauthenticated
and
authenticated
ways
of
reporting
mud
urls,
I'm
assuming
that
people
know
what
mod
does,
but
on
the
off
chance
that
they
don't
I'll
just
quickly
say.
Mud
essentially
gives
network
infrastructure
policies
to
apply
to
individual
device
communication
so
for
the
unauthenticated
model.
O
I
don't
think
we
really
need
to
follow
that
through
very
much,
and
there
are
some
clear
problems
with
having
a
an
unauthenticated
reporting
mechanism
for
a
security
property.
So
I
think
that
really
what
I'm
comparing
against
here
is
the
802.1x
variant
of
mud,
reporting,
a
service
hosting
a
mud
uri
effectively
gains
the
ability
to
set
policies
on
what
your
network
does
and
and
those
policies
are
subject
to
change,
which
is
the
reasoning
behind
using
a
url
instead
of
doing
static
reporting
mud
signatures
are
also
a
way
of
locking
this
down.
O
So
the
the
section
in
rfc
8520
that
describes
this
specifies
that
mud
signatures
will
require
a
route
of
trust
and
particularly
an
audit
of
that
route
of
trust.
The
term
they
use
is
checking
web
reputation.
O
So
there
are
a
few
complexities
here.
If
a
device
reports
the
wrong
mud
url,
then
it
can
pretend
to
be
a
different
device.
Now,
that's
one
of
the
reasons
I
say
that
we
probably
only
care
about
the
8021x
equivalent
the
server
hosting
the
mud
url
like
I
said
it
gets
the
ability
to
set
network
policy,
so
it
requires
an
audit
and
probably
signatures
again.
O
Rfc
8520
says
use
web
reputation
to
evaluate
the
the
server
8520
also
calls
out
explicitly
the
possibility
of
a
rogue
ca
authorizing
a
rogue
mud
signer,
which
would
then
give
you
the
ability
to
arbitrarily
change
network
policy,
and
the
other
part
here
that
seems
concerning
is
that
device
communication
might
be
altered
by
plane,
configuration
not
actual
deep
changes
to
device
firmware
or
anything
like
that,
but
just
by
configuration.
O
So
I
want
to
look
at
simplifying
the
trust
model
and
the
the
way
that
I
see
doing,
that
is
by
binding
the
the
base
set
of
policies
that
a
device
has
to
the
entities
that
actually
know
about
that
device.
So
those
are
the
the
authors
of
firmware
and
the
the
entities
that
do
device
configuration
they're,
the
ones
who
know
the
most
about
these
devices,
so
they
know
how
they
should
behave
and-
and
what's
interesting
about.
O
O
The
idea
would
be
that
a
suit
manifest
could
specify
a
mud
file
and
there
are
a
few
interesting
properties
there.
The
first
is
that
you
obtain
a
mud
file
before
a
device
actually
needs
it,
and
what
that
does
is
it.
It
eliminates
any
latency
on
first
use
of
any
given
mud
file,
but
that's
probably
a
minor
thing.
The
more
important
one
is
that
it
might.
It
binds
the
firmware
and
configuration
to
a
particular
mud
file.
O
O
You
can
use
an
eat
token
to
deliver
the
information
that
that
actually
specifies
that
back
up
to
the
network
infrastructure,
so
in
an
attestation
use
cases
having
a
device,
a
test,
it's
mud,
url
mud,
digest,
signer
id
or
even
its
manifest
digest.
If
the
manifest
does
in
fact
contain
that
information
allows
an
alternative
to
802.1x
based
mod
url
reporting
and
that
can
make
the
mud
manager
into
a
relying
party
in
the
attestation
workflow,
which
allows
it
to
verify
correspondence
between
all
of
this
information.
O
So
that
gives
us
a
number
of
advantages.
It
reduces
the
number
of
actors
in
your
system,
you're
already
trusting
your
firmware
vendor
to
do
particular
things,
including
determine
how
your
device
behaves.
So
if
you're
already
trusting
that
party,
then
there's
an
argument
for
reducing
the
level
of
complexity
in
your
supply
chain
by
including
both
of
these
authorities
in
the
same
location
and
yeah
coming
down
to
a
single
audit
rather
than
multiple
audits.
O
It
also
makes
an
explicit
authority
or
chain
where
you
you,
don't
actually
need
to
bring
in
a
new
ca,
which
means
that
the
rogue
ca
scenario
drops
out
of
the
threat
model
and
it
removes
mud
file
hosting
from
your
threat
model
as
well.
If
you
deliver
the
mud
file
directly
in
your
firmware
updates,
if
you
don't
want
to
use
that
approach,
then
of
course
you
still
need
to
establish
whether
you
can
trust
your
mud
file
hosting.
O
There's
a
fairly
solid
argument
for
being
able
to
deliver
a
baseline,
essentially
a
definition
of
how
a
device
should
behave
with
specific
network
rules
that
are
delivered
from
a
different
party,
so
that
I
think
that
there
would
be
a
question
around
that
as
well.
O
There
there's
a
point
about
onboarding
flows,
it
raised
in
8520,
and
it's
specifically
around
tracking
how
mud
files
change
over
time
and
how
the
signers
of
those
files
change,
and
I
think
that
that
brings
out
a
requirement
for
an
onboarding
flow,
and
what
this
would
do
is
it
would
allow
you
to
automatically
verify
those
onboarding
flows.
O
So
yeah
it's
an
alternative
essentially
for
802.1x
mud,
url
reporting,
so
this
originally
came
up
in
suit
and
they,
the
chairs
of
suit,
did
say
at
the
time
that
they
thought
that
suit
would
be
a
good
home
for
this
or
out
a
home
for
it
and
they'd
be
happy
with
that.
But
they
felt
that
coming
to
set
dispatch
would
be
the
right
first
choice
and
that's
all
for
me.
A
F
F
A
Okay,
so
I
guess
the
question
is:
if
anybody
has
objections
to
getting
this
work
to
suit.
N
I
mean
for
me
personally,
rats
also
seemed
plausible,
but
I'm
not
really
involved
in
either
working
group,
so
open
the
feedback
from
folks
on
whether
the
mix
which
of
those
whether
the
default
suit
track
makes
sense
or
whether
rats
would
be
better.
L
Okay,
good,
you
can
hear
me
I
so
I
think
rats
might
be
good
and
another
consideration
is
that
this
could
also
be
an
extension
to
a
coast
with
right.
So
there's
a
few
ways
you
can
package
it
that
make
a
lot
of
sense
and
for
those
not
familiar
with
the
coast
width,
it's
a
a
software
identifier,
so
suid,
but
in
a
coset
format
or
cozy
format,
and-
and
there
are
extension
capabilities
that
way,
you
know
if
the
vendor
is
issuing
a
coast
with
anyway
that's
signed.
O
One
of
the
the
mechanisms
that
is
probably
relevant
there
is
that
suit
already
contains
a
mechanism
to
contain
a
coast
wood,
so
that
would
absolutely
fulfill
the
suggestions
that
I've
made
already.
L
Yeah
and
then
eat
can
too
so
yeah.
I
you
know,
I
I
think
we
probably
have
to
think
about
this
a
lot
more
in
terms
of
what's
going
to
be
most
practical,
what's
actually
going
to
get
deployed,
what
can
we
get
vendors
to
do
so
that
we
get
to
common
solutions
that
are
easy
to
integrate
and
digest
so
that
we
actually
achieve?
L
You
know
secure
hygiene,
posture
assessment,
and
so
it's
not
just
pushing
a
solution.
So
I'd
love
to
chat
more
yeah.
G
Yeah
exactly
hi
there
thank
you,
hi
brandon
yeah,
so
we
talked
about
this
a
lot
and
I
I
think
yes,
it
could
be
in
red.
Reds
has
his
own
muddy
rats,
so
this
is
a
muddy
suit
here
and-
and
we
have
muddy
rats
also
and
so
in
red,
it's
a
little
bit
of
an
egg
problem
or
call
it
should
be
red
because
you
have
to
create
evidence
about
the
resources
that
evidence
creation
requires.
So
this
is
again
michael's
topic
turtles.
G
I
think
it's
fine
in
suit
or
rats.
In
any
case,
I
think
both
everything
that
is
associated
with
the
security
context
of
mud
has
the
same
problem,
and
so
this
is
a
this
is
this
includes
a
generic
part
here,
and
that
is,
I
think,
the
vital
question
where
that
should
be
handled.
G
I
have
no
clear
answer
to
that,
but
I
wanted
to
highlight.
There
is
a
common
denominator
here
that
crosses
multiple
mud
efforts.
I
I
think,
and
also
I
love
this.
J
Taylor
as
one
of
the
suit
co-chairs
between
suit
and
rats,
I
would
argue
which
I
obviously
participate
in
both
of
those.
I
would
argue
that
it's
more
appropriate
for
suit
and
the
reason
for
that
is
it
it
does
do-
does
touch
on
both
right
between,
because
you
talk
about
your
attestation,
pains
and
so
on.
J
But
rats
has
a
model
that
was
modeled
after
things
like
a
dhc
which
says
we
do
the
core
stuff,
but
if
you
want
to
do
your
own
options
and
stuff
that
goes
in
the
other
working
group
and
we
review
it
right,
rather
than
rats
doing
claims
for
every
other
working
group.
Other
working
groups
that
need
attestation
claims
can
do
claims
just
have
rats
review
it
similar
to
the
dhc
model,
and
I
think
this
fits
in
that
category,
where
suit
doesn't
have
that
type
of
model
right.
J
L
F
Yeah,
I
mean
the
question
I
I
wanted
to
ask:
is
I
mean?
Is
there
potentially
work
kind
of
for
both?
My
read
of
of
kind
of
this
particular
draft
was
that
it
looked
like
we
were
making
an
extension
kind
of
pursuit
to
encapsulate
just
a
little
bit
of
information,
which
is
not
to
say
that
there
wouldn't
be
kind
of
additional
work
in
my
head.
That
was
in
rats
to
get
some
of
that
additional
attestation
information
in,
but
the
shim
we're
talking
about
here
is
actually
kind
of
very
narrow.
O
Yeah,
it's
it's
a
really
narrow,
shim
and-
and
it
comes
out
to,
I
think,
about
three
possible
information
elements
for
pursuit-
a
similar
number
for
rats
that
it's
not
already
handling.
And
I
would
imagine
that
if
we
were
to
put
an
extension
in
coswood,
it
would
be
similar.
A
Okay,
no
one
else
is
in
the
in
the
queue,
so
it
seems
that
there
is
pretty
much
agreement
that
this
belongs
to
suit
we've
heard
from
the
chairs
and
a.d,
so
I
think
you
can
go
ahead
and
this
is
dispatch
to
suit.
N
Actually,
martin
quick
question:
are
you
looking
for
me
to
drive
the
slides?
Would
you
like
to
present
your
own,
but
while
we
get
into
that
roman
in
general,
do
you
think
this
is
this
sort
of
you
know
new
work
for
a
potato
that
is
pretty
clearly
with
a
new
working
group?
Do
you
think
that
sort
of
question
should
come
to
discuss
in
general?
Should
work
in
group
chairs,
be
you
know,
ready
to
to
do
recharterings
that
are
pretty
close
to
their
current
scope?
More
directly.
F
Yeah,
I
mean
that's
a
fair
question
kind
of
richard.
I
don't
know
if
there's
a
one
size
fits
all
here.
I
think
what
we
just
did
was
very
healthy
to
figure
out
where
to
best
land
work
between
two
working
groups,
and
sometimes
I
could
imagine
a
circumstance
where
the
charters
might
fit
kind
of
both,
but
there's
a
better
way
to
do
the
work.
Q
All
right
there
you
go:
okay,
thanks
yeah,
thanks
for
putting
us
on
the
agenda
by
document
the
new
name
system.
We
are
basically
making
a
specification
of
our
current
implementation
of
the
new
name
system.
Q
My
co-author
ben
fix,
who
is
also
doing
an
alternative,
a
second
implementation
of
the
protocol
and
christian
who
is
actually
joining
me
today,
physically,
but
with
appropriate
distance.
He
may
jump
in
in
the
questions
later
on,
but
I'm
doing
the
presentation
yeah
you
can
find
the
the
draft
itself
in
the
link
next
slide,
please.
Q
So
before
I'm
going
on
to
the
the
action
states
of
the
current
draft,
I
just
want
to
give
a
very
brief
overview
of
what
the
new
name
system
is
without
giving
any
details
as
they
are
in
the
draft
anyway.
Next
slide,
please
so,
basically,
gns
tries
to
address
some
of
the
dns
issues,
especially
with
respect
to
the
points
that
are
written
here
like
traffic,
amplification
and
censorship
and
surveillance
that
are
not
already
addressed
by
existing
efforts,
such
as
dot
doh.
Dns.
Second
deprive
next
slide
piece.
Q
So,
in
a
nutshell,
the
new
name
system
is
a
fully
decentralized
name
system,
so
it
builds
on
the
peer-to-peer
model.
Names
are
also
not
global
in
gns.
It
does
support
global,
unique
and
secure
identification
and
features
query
and
response
privacy,
which
is
an
important
key
factor
in
dns
and
is
realized
cryptographically.
Q
It
is
designed
to
be
interoperable
with
dns,
and
it
is
also
designed
to
be
usable
in
the
sense
that
a
user
should
ideally
not
even
notice
whether
or
not
the
old
dns
encodes
is
used
or
dns.
So
we
have
done
usability
studies
in
this
regard.
Q
Q
I
itf
104
in
in
the
prg
irtf
working
group,
there's
also
secure,
which
is
planning
to
use
it
as
a
way
to
discover
social
places,
and
we
have
also
done
as
part
of
our
work
on
design
where
we
also
did
the
usability
studies
to
use
it
in
healthcare
and
iot
use
cases
in
this
case
accident
insurance,
and
we
were
also
using
it
to
basically
connect
iot
devices
to
to
web
services
without
actually
requiring
a
dedicated
iot
cloud
service,
for
example.
Q
So,
regarding
the
technical
overview,
as
I
said,
I'm
I
will
not
go
into
the
cryptographic
details
on
the
the
high
level
what
to
expect
from
when
you
read
the
draft
yeah
next
slide.
Please.
Q
The
naive
approach
would
be
to
to
just
think,
because
a
distributed
hash
table
is
basically
a
key
value
store
is
that
the
key
is
is
the
name
and
the
value
is
then
the
actual
resource
record
data.
Of
course,
this
is
not
how
it
works
next
slide,
please,
because
the
details
are
in
the
in
the
draft
regarding
cryptography,
but
what
gns
is
additionally
providing
is
query
privacy.
Q
So,
whenever
you
query
a
record,
a
privacy,
a
private
information
retrieval
scheme
ensures
that
an
outside
observer
cannot
see
what
record
is
actually
queried
or
what
name
is
queried
and
what
the
data
contains
unless
the
attacker
already
knows
what
he's
looking
for.
Q
So
the
queries
do
not
reveal
a
domain
name.
Records
are
encrypted
as
values
in
the
dht
as
a
consequence
of
that.
Actually,
the
zones
also
cannot
be
enumerated,
and
this
a
bit
depends
on
the
use
dht,
but
it
also
provides
censorship
and
ddos
resistance.
As
long
as
you
can
rely
on
certain
properties
of
the
dht
next
slide,
please.
Q
Now
this
is
just
an
as
an
example
to
see
the
equivalence
between
between
how
dns
works
and
how
dns
works
with
respect
to
delegation.
So
the
dns
record,
equivalent
in
gns,
is
called
a
p
key
record.
Q
A
p
key
record
simply
contains
the
public
zone
key
of
another
zone
and
basically
the
the
it
was
a
bit
different
than
for
dns
sec.
Basically,
the
the
pke
record
data
tells
you
where
to
look
next
in
a
delegation.
Q
Next
slide,
please
tell
them
for
a
very
simple
example:
let's
assume
that
an
administrator
that
is
managing
the
dot-com
zone
has
a
zone
public
key
of
5g
0z
and
bob
who,
who
has
registered
a
bob.com
as
a
as
a
zone
in
the
dot
com
zone,
which
is
7f5
t.
Q
Q
Q
So
now,
if,
if
any
other
user
wants
to
resolve
this
name
www.bob.com,
she
would
simply
first
try
to
discover
bob
in
the
dot
com
zone,
which
was
five
g,
o
z,
so
basically
a
a
get
query
from
the
dht
and
then
iteratively
query
the
dht,
just
like
an
iterative
name.
So
iteratively
query
name
servers
next
slide,
please
until
the
actual
record
value
for
www.bob.com
is
found,
which
is
the
ip
address
that
bob
stored.
Q
This
is
the
general
overview,
so
why?
Why
are
we
here?
Yeah
next
slide,
please,
and
why
did
we?
Why
did
we
do
this?
So
we
actually
have
been
at
itf
and
working
groups.
A
few
times
now
in
itf
93,
we
tried
to
register
a
special
use
domain
name
for
gns,
which
was
dot
new
as
part
of
a
document
that
tried
to
register
a
few
other
top-level
domain
names
as
well.
This
resulted
in
two
rfcs.
Q
One
of
them
basically
defined
a
subset
of
what
was
proposed,
but
not
that
new
and
another
document
that
basically
tried
to
to
clarify
this
process.
Q
Then
we
were
also
invited
to
present
our
work
at
w3c
and
I
an
iab
workshop
in
2014,
and
we
also
presented
the
current
state
of
gns
at
itf
104
at
dynaregi,
where
we
basically
also
showed
our
way
out
of
the
problem
that
we
encountered
in
itf
93,
which
was
to
simply
not
put
the
gns
namespace
under
a
special
top-level
domain.
But
instead
just
say
it's
it's
its
own
namespace
right,
it's
just
it
coexists.
Q
Last
year
I
was
also
presenting
gns
at
icam.
They
invited
us
as
part
of
their
emerging
internet
identifier
panels
next
slide
piece.
Q
So
who,
who
is
currently
working
on
it,
that's
the
minute
project,
so
it's
basically
me
and
christian
and
ben,
because
we
have
received
funding
from
an
elnet
to
actually
make
a
specification
of
gns,
including
a
second
implementation
for
it,
and
also
including
the
discussion
and
presentation
with
experts
such
as
the
iitf.
That
is
why
we
are
also
here:
reference
implementation
exists.
Gns
has
been
first
implemented
in
2012
has
changed
a
lot
until
now
in
the
second
implementation
is
actually
written
in
go.
Q
It
uses
some
of
the
components
of
bluenet,
for
example
the
distributed
hash
table,
but
apart
from
that
is
its
own
implementation,
according
to
the
specification,
so
we
can,
we
try
to
actually
make
a
specification
from
which
we
can
then
also
well
create
another
implementation
and
yeah.
We
also
uploaded
the
current
draft,
obviously
in
version
01
to
the
data
tracker
currently
at
this
point,
the
the
document
basically
documents
our
current
implementation
and
how
it
works,
which
is
why
we
currently
also
gave
it
the
informational
tag.
Q
But
of
course
that
is,
that
is
simply
because
we
have
to
give
it
some
kind
of
an
anti-file.
For
now,
we
are
basically
currently
looking
to
collect
feedback
and
improve
the
protocol
and
specification
development
next
slide
piece.
Q
So
next
steps
we
have
already
received
very
valuable
feedback,
especially
regarding
to
the
cryptography
which
we
are
planning
to
address
soon.
Most
importantly,
the
trust
agility.
So
at
the
moment
the
the
the
way
zone
keys
are
used
and
the
way
zones
are
created
is
very
static.
Q
But
we're
planning
to
make
this
more
agile
in
terms
of
what
kind
of
crypto
can
be
used
and
also
improve
the
symmetric
encryption
scheme
that
we're
currently
using
which
we
basically
inherited
from
older
code
in
the
current
unit
source,
which
should
be
updated,
and
we
agreed
to
that-
and
there
was
also
a
lot
of
other
feedback
that
we're
definitely
planning
to
to
incorporate
already
now
the
desired
next
steps
at
itf
or
why
we
posted
this
on
sac
dispatch
apart
from
receiving
more
feedback,
is
that
we
are
also
interested
in
whether
or
not
any
existing
working
group
in
itf
or
irtf
would
be
suitable
and
interested
in
adopting
this
document,
or
it
would
be
better
to
discuss
it
there
or
should.
Q
Or
can
we
create
a
new
working
group?
For
example,
we
have
been
in
discussion
with
the
the
people
from
met
up
who
have
aspirations,
maybe
in
creating
a
a
working
group
and
from
our
discussions
it
seems
like
we
have
yeah
very
complementary
goals
and
it
might
be
reasonable
also
to
to
integrate
their
protocols
and
ours
yeah.
I
think
that's
that's
my
point.
Thank
you.
A
Echo,
let's
see,
I'm
gonna
mute
you
just
while
I'm
talking
so
that
yeah,
okay,
so
from
the
mailing
list,
we
got
some
feedback
and
I
interpreted
it
as
probably
not
to
do
an
atf
or
if
you
do
need,
needs
more
discussion
and
should
probably
in
standard
track
rather
that
informational,
it
might
be
the
wrong
interpretation.
So
please
come
to
the
queue
and
state
your
opinion.
R
Hi,
so
thanks
for
bringing
this
you
know,
it's
really
nice
to
see
it
formally
documented
I've
been
I've
visited
I've.
Let's
listen
to
all
that.
I
think
the
presentations
you
listed
in
the
past.
I'm
certainly
said
that
the
ietf
and
icann
issues
have,
you
know
taken
way
too
long
to
come
up
with
a
reasonable
solution
for
a
top-level
tld
for
projects
like
this.
That
are
technical
and
that's,
you
know
unfair
a
couple
of
points
one.
R
You
know
you
say
that
you're
interoperable
with
the
dns-
and
I
I
wouldn't
say
that
that's
entirely
true,
just
because
it's
designed
to
be
not
designed,
conflicts
can
arise
and-
and
there's
a
you
know,
there's
a
preferencing
order.
So
it's
really
a
second
naming
system
that
is
parallel
and
there's
other
ones
too.
I
mean
the
dns,
isn't
alone
the
the
biggest
issue
that
I
have
of
where
you
know
this
might
go
would
be
you
know,
why
would
we
pick
gnu
dns?
So
it's
actually
of
all
the
distributed
technologies.
R
It's
my
favorite,
but
you
know,
which
is
the
right
model.
Technically
privacy
ease
of
use,
scalability,
not
sure
you
know
which
that
first
come
first
serve.
Is
the
right
model
here
so
which
is
sort
of
where
you're
at
so
one
of
my
other
a
couple
other
really
quick
questions,
one?
Why
do
you
look
like
the
dns
at
all
right
if
you're
going
to
do
something
completely
different,
you
might
as
well
just
deviate.
Why
are
you
using
similar
packet
formats
and
things
like
that?
R
Like
research,
resource
record
types,
you're
missing
an
integration
and
deployment
model
which
I
think
would
be
critical
if
we
were
going
to
see
this
deployed
so
to
me
it
still
seems
rather
researchy
right.
Why
would
we
do
this
instead
of
dns
ens?
Why
would
we
use
you
know
this
instead
of
some
of
the
other
technologies?
R
Why,
if
we're
going
to
do
a
completely,
you
know
replacement
of
a
globally
unique
naming
system
or
non-unique
naming
system,
as
you
claim
you
know,
certainly
it
seems
like
research
not
like,
like
a
working
group
and
so
d
d,
I
energy
is
probably
you
know
where
I
would
target
it.
I
would
worry
that
they'd
get
overwhelmed
if,
like
all
of
the
distributed
technologies
came
to
that
group,
but
that'd
be
my
choice.
S
Ted
hardy
speaking
from
google,
I
guess
I
have
three
questions,
one
of
which
is
procedural
and
the
procedural
question.
Is
you
understand
that
if
it
does
come
to
the
ietf,
the
change
control
shifts
to
the
itf
at
that
point
and
that
the
resulting
protocol
would
not
necessarily
resemble
the
existing
protocol
very
tightly?
And
I
think
you
said
at
the
beginning,
you
wanted
to
document
what
you
wanted
to
do
and
that's
a
different
goal.
Necessarily.
S
The
second
thing
is
I
I
look
at
this
and
I
I
feel
like
much
of
the
relationship
to
the
dns
is
described
in
ways
that
misses
the
fact
that
this
actually
doesn't
map
very
well
at
all
to
the
properties
that
dns
is
trying
to
give
you
it
maps
to
the
query
response
model
in
a
more
private
way
and
it
maps
to
some
of
the
the
packet
formats
much
more
directly.
S
It
gives
you
the
ability
to
mint
names
very
easily,
and
it
gives
you
the
ability
to
resolve
names
in
multiple
different
routes
and
especially
because
the
way
you're
mapping
it
into
the
dns
is
providing
a
dns
name,
and
it's
it's
actually
not
clear
from
the
zero
one
draft.
What
do
you
mean
a
label
or
an
fqdn,
but
you're
also
telling
it
what
server
to
to
ask
about
that
name:
you're
you're
you're,
getting
into
a
place
where
phishing
style
attacks
are
extremely
easy.
If
people
were
trying
to
build
something.
S
On
top
of
this,
that
looked
like
a
a
url
or
that
looked
like
most
applications
usage
of
the
dns
as
a
as
an
authority.
This
has
very
fundamentally
different
uses
as
an
authority.
So
I
I
almost
feel
like
the
the
cryptographic
stuff
in
here.
S
What
namespaces
do
you
need
to
build
this
for
because
some
of
the
ones
referenced
in
the
draft
like
user
identifiers
in
a
local
system?
This
actually
might
work
very
well
for
because
that
local
system
has
a
property
of
uniqueness.
That's
not
related
to
the
global
property
of
uniqueness
that
the
dns
has.
S
I
apologize
for
saying
you
should
dispatch
this
to
dispatch,
but
I'm
afraid
that
the
actual
answer
here
is
it's
really
not
about
whether
the
cryptography
works.
It's
about
what
the
identifier
properties
are
and
that,
I
think,
is
either
a
ball
for
a
dispatch
question
thanks.
A
H
Yeah
I'm
talking
now
yeah
I
mean
to
to
what
ted
was
saying.
You
know
this
isn't
rather
proper
that
are
destroying
to
those
of
the
dns
in
that
it
overlays
on
pieces
of
the
namespace,
so
you
have
inconsistent
results
and
also
so
that
seems
like
not
a
property
which
I
I
understand,
how
we're
gonna,
how
we're
gonna,
like
actually
document
an
itf
in
terms
of
dispatch
question.
I'm
sorry
thanks
different.
H
I
always
have
a
number
in
search
of
the
photography
of
someone
which
I
was
listening
on
on
on
the
chat
but
into
the
dispatch
question.
I
guess
I
don't
really
understand
what
it
is
you
want
if
you
wanna
document,
you
know
you
want
this
document
somewhere.
The
ise
is
where
you
go.
H
If
you
want
this
worked
on
somewhere,
this
seems
like
pretty
clearly
a
research
project,
so
the
energy
is
where
you
go,
and
if
you
want
this
standardized,
then
I
I
don't
see
us
doing
that.
So
I
guess
I
don't
understand
what
it
is.
You
want.
Q
Okay,
yeah.
Maybe
before
answer
that
question,
I
would
like
to
also
answer
the
questions
from.
I
think
it
was
ted,
so
I
I
said
that
this
was
informational
because
it's
implemented,
because
that's
that's
what
it
currently
is
right,
but
that
doesn't
mean
that
we
this
this
cannot
change.
What's
in
the
document
like,
we
are
not
married
to
the
current
implementation.
If
there
are
improvements
to
it,
if
there's
ways
you
can
do
it
better,
then
there
is
nothing
that
probably
cannot
be
changed
in
this
in
this
document.
Q
Regarding
the
the
the
single
root
issue,
let's
call
it
yet
behave
similar
to
hyper
local
dns,
so
you
you
most
likely
there
will
be
a
default
root
zone
shift
right,
so
most
likely
most
of
the
name
will
actually
be
globally
unique
for
the
regular
user.
You
you
only
always
have
the
option
to
overwrite,
just
like
with
the
hyperlocal
root
to
do
that.
Regarding
the
dispatch.
Q
I
don't
know,
that's
something
that
I
cannot
really
answer,
I'm
not
so
much
an
expert
enough
where
to
dispatch
it.
Where,
where
do
we
want
to
discuss
this?
This
is,
in
my
opinion,
also
open
for
discussion.
Obviously
gns
was
initially
a
research
project
and
it
partially
still
is,
but
at
some
point
we
do
want
to
graduate
from
that
right.
It
shouldn't
be
always
just
a
research
project
and
then
there
should
be
a
path
out
of
this.
Ideally
for
us.
H
A
P
So
I
think,
as
a
couple
of
other
people
have
pointed
out,
there
are
a
bunch
of
proposals
for
alternatives
to
the
dns,
including
things
that
I've
heard
of
our
ethereum
name
service,
namecoin,
handshake,
name
service,
and
I
think
that
one
of
the
things
we
have
to
recognize
is
that
it's
appealing
to
mint
alternatives
to
the
namespace,
because
then
you
get
to
define
who
the
root
is.
P
There's
there's
an
incentive,
all
else
being
equal
to
create
fresh
namespaces
over
and
over
again,
and
so
I
think
we
one
of
the
the
sources
of
caution
here
might
be
that
if,
if
we
allowed
gns
into
this,
if
we,
if
we
say
that
we
want
to
work
on
gns,
it
becomes
very
difficult
to
explain
why
it
is
that
we
would
work
on
gns.
P
P
It
seems
to
me
that
that's
the
logical
integration
point
in
order
to
interoperate
correctly
with
the
rest
of
the
dns.
So
if
you
want
to
have
things
that
look
like
dns
names,
then
they
should
chain
up
to
the
dns
route
through
a
name
that
you
control.
Anything
below
that
point
is
your
call
can
do
whatever
you
want,
including
gns.
P
A
Competitive
okay,
I
just
want
to
remind
you
to
please
state
your
name
so
rich.
K
You're
up
hi,
rich
sauls,
so
first
I
want
to
say
you
know.
Thanks
for
your
persistence,
I
mean
you
keep
coming
up
and
knocking
on
the
door.
I
think
at
the
beginning
of
your
conversation,
you
said:
well,
you
begin
your
presentation,
he
said.
Well,
you
know
we
have
an
existing
protocol.
K
We
want
to
get
that
documented
and
so
on
and
then
later
on,
that
became
or
later
on,
you
said
well
we're
still
it's
still
working
progress,
we're
still
looking
to
evolve
it
and
I
think
the
first
argues
against
any
kind
of
ietf
thing.
K
Unless
it's
a
historic
protocol,
we
tend
not
to
document
those
things,
but
the
second
is
real
important
and
I
think
the
second
is
interesting,
if
only
cause
of
the
nerd
sniping
of
all
the
cryptography
people
that
was
going
on
in
the
chat
room,
the
problem
is
or
a
problem
that
I
see
is
that
there's
multiple
places
where
this
could
go.
Is
it
a
deployed
project?
Is
it
a
research
project,
and
so
I
think
perhaps,
and
it's
awkward
until
we
meet
in
person.
K
You
know
above
to
get
people
together,
and
I
know
you
had
a
buff
before,
but
it
was
mainly
a
presentation.
You've
got
to
you,
know,
post
an
individual
draft
or
maybe
sec
dispatch
adopts
a
draft.
I
don't
know
if
that's
even
possible
and
you
get
people
say,
look
we're
interested
in
actually
working
on
the
next
version
of
this
protocol.
Who
was
interested
and
then
from
the
people
community
you
get
there
see.
Well,
is
it
can
you
know?
Is
it
a
research
group?
Is
it
a
you
know?
Is
it
tweaking?
Is
it?
K
Is
it
a
real
security
or
dns
group,
but
I
do
again
appreciate
you're
trying
to
come
here
and
get
a
community,
and
I
think
we,
the
problem
right
now
is
we
don't
quite
know
where
it
would.
A
Okay,
just
to
answer
your
question:
no
dispatch
does
not
adopt
drafts.
A
So
next
thing
q
is
warren.
I
Is
trying
to
use
this
as
a
name
space
for
things
like
hosts
if
it
was
a
new
namespace
or
you
know
the
system
being
used
for
user
identity
or
many
of
the
other
things
that
we
want
to
identify
on
the
internet?
I
think
that
would
be
a
good
idea,
but
having
it
conflict
with
something
like
the
dns,
I
think
leads
to
really
bad
outcomes
as
much
as
I
might
dislike
it.
I
Having
a
unique
www.facebook.com,
which
is
clear
to
the
user,
that
that's
the
one
they're
going
to,
I
think,
is
a
really
important
property,
I'm
largely
going
to
agree
with
ben,
where,
if
you
were
to
have
this
rooted
under
a
clearly
delineated,
actual
name
like
a
tld,
I
think
that
that
would
ameliorate
a
lot
of
the
concerns
and
sort
of
security
issues,
but
the
way
it's
designed
at
the
moment.
I
I
You
know
this
gets
back
to
the
zuko's
triangle,
thing
which
this
does
try
and
solve
in
some
interesting
ways,
but
I
think
it
still
runs
into
the
a
single
unique
way
to
look
up.
A
name
is
a
very
important
property,
at
least
in
the
way
that
users
understand
it
and
the
way
the
system
gets
used
at
the.
I
A
Okay,
wes
you're
up.
R
All
right,
so
I
have
one
request
of
you,
which
is
you
need
to
stop
referring
to
the
similarity
to
the
hyperlocal
route
and-
and
the
reason
being
is
that
you
are
making
claims
that
are
not
true.
The
hyperlocal
route
and
7706,
which
now
is
8806
specifically
says
that
is
the
root
just
distributed
in
a
different
way
and
you're
you've
stated
multiple
times
that
you
know
it
allows
users
to
make
changes
to
the
to
the
root.
That
is
not
true.
There
can
be
zero
modification.
R
Dns
protects
that
yeti
is
actually
a
little
bit
closer
because
they
actually
do
change
the
key
at
least,
but
even
they
say
that
they
are
not
changing
the
route.
You
know
you
are.
You
are
distributing
multiple
different
routes,
and
that
makes
sense,
but
but
this
you're
you're
misusing
the
hyperlocal
root
name
that
sort
of
has
been
coming
out
of.
I
can
so
please
stop
referencing
it
that
way.
Thanks.
Q
Thank
you.
I
would
actually
like
also
like
to
answer
both
okay
thanks
for
the
hyperloop
root
pointer,
but
regarding
the
the
use
for
for
the
name
system
for
other
things,
but
like
keep
it
separate
from
from
dns,
I
mean
the
the
technical
definition
of
the
protocol
and
how
to
resolve
the
records
and
and
how
the
delegation
works
is
completely
independent
from
the
actual
root
zone,
governance
right,
so
the
governance
of
the
names
is
not
does
not
hinge
on
on
on
the
technical
protocol.
That's
that's
underlying!
Q
So,
if
you
just
look
at
the
dns
specification,
there's
no
wording
of
how
the
root
zone
is
governed
right.
So
it's
just
a
technical
protocol
on
how
to
do
things.
So,
if,
if
that
exists-
and
it's
only
used
for
some
specific
applications
and
not
for
host
name
addressing,
that
is
still
a
technical
protocol
that
can
be
used
as
a
as
the
respective
directory.
A
Thank
you
and
go
ahead.
T
So
we
we
keep
talking
about
the
pros
and
cons,
but
I
want
to
get
back
to
sort
of
the
question
of
trying
to
figure
out
how
to
dispatch
it
like
what
what
is
your
ask?
I'm
not
100
clear
on
what
you
would
like
to
see
happen.
Martin,
that's
that's!
I,
I
think
that's
what
I'm
missing
here
in
trying
to
decide
how
to
deal
with
this
next.
Q
No
okay:
now
it
works.
It's
just
a
delay
always
until
that
actually
works.
Well.
Ideally,
we
would
like
to
to
see,
for
example,
met
up
stepping
up
and
maybe
become
a
working
group
and
adopting
the
the
draft,
for
example.
So
if
we
could
just
wish
for
something
right,
then
then
that
would
be
the
best.
Q
N
If
I
can
put
a
slightly
different
spin
on
that,
are
you
looking
to
document
existing
practice
here,
or
are
you
looking
for
feedback
from
a
broader
community
and
to
evolve
this
document
towards
something
that
would
be
perhaps
more
broadly
applicable
or
slightly
different
than
it
is
today.
N
All
right
thanks
for
that
clarification,
so
we
we've
drained
the
queue
here.
Speaking
as
your
chair,
what
I'm
hearing
from
the
floor
here
is
that,
if
this
is
going
to
get
work
done
in
the
ietf,
we
need
to
probably
have
a
full
buff
and
get
some
kind
of
simultaneous
feedback
from
across
a
few
different
groups
from
the
security
perspective
as
well
as
kind
of
some
folks
who
know
naming
in
kind
of
the
internet
area
and
probably
some
folks
who
rely
on
naming
in
the
applications
areas.
N
This
is
a
real
cross
area
review
problem
that
needs.
You
know
the
full
machinery
of
a
buff.
Obviously
the
decision
on
whether
to
grant
boss
is
up
to
the
chairs,
so
I
wanted
to
reopen
the
floor
briefly.
If
folks
have
guidance
to
the
chairs
as
to
whether
a
buff
here
would
be
appropriate
or
kind
of
under
what
circumstances
above
would
be,
would
make
sense.
L
Okay,
you're
off
the
couch
mailing
list,
may
make
sense
so
that
we
can
track
all
the
discussions
in
one
place
and
that
can
be
advertised
across
groups
and
that
might
inform
whether
a
buff
is
helpful.
You
know
when
it
gets
to
the
stage
of
requesting
a
buff,
assuming
that
is
the
direction
it
goes.
F
Q
A
P
To
send
audio
hi,
I
support
dispatch
to
din
rg.
You
know
I
just
checked
the
charter
for
din
rg
again
and
actually
they
explicit
explicitly
name,
check,
namecoin
and
ethereum
name
service,
in
addition
to
ipfs
as
examples
of
in
scope
items
for
them.
P
I
think
that
giannis
is
very
much
in
that
line,
so
I
think
that's
where
the
expertise
is
here,
and
I
also
think
that
correctly
reflects
the
level
of
maturity
here,
where
we
have
out
in
the
ecosystem,
a
proliferation
of
proposals
for
distributed
naming
systems
and
the
ietf
can't
really
get
started
on
a
standardization
effort
until
there's
some
some
emerging
consensus
about
how
that
should
work.
A
Okay,
is
there
any
dnrg
chairs
today
that
wants
to
speak
up,
please
jump
to
q
and
come
to
the
microphone.
N
E
I
believe
that
so
this
has
been
kadek.
I
believe
that
melinda
shore
will
be
sending
some
take.
Q
Some
time
the
audio
catches
up
again
and
the
the
no
we
have,
we
have
not
received
a
lot
of
feedback
from
them,
whether
or
not
they
want
to
adopt
it
like
we.
We
have
presented
it
at
ietf
104,
as
I
said,
but
oh
yeah.
No,
that
was
that
working
group,
but
we
have
not
received
any
any
kind
of
feedback
or
I
have
an
approach
to
to
work
on
it.
Yeah.
E
Yeah,
I
just
want
to
point
out
that
I'm
told
that
some
updates
from
the
dinar
g
will
be
sent
fairly
soon
to
the
sector's
batch
list
from
melinda.
So
we
can
get
some
already
put
from.
H
I
think
I
more
or
less
conquer
what
ben
said.
This
does
not
seem
like
it's
decision
of
maturity
to
be
to
have
a
buff
and
the
energy
is
placed
for
it.
If
you
want
it,
not
as
if
you
want
to
have
it
worked
on
you'll
get
feedback
and
if
you
just
want
it
published,
as
is
the
places
I.
A
See,
okay
and
wes.
R
So
you're
in
a
weird
place,
because
you
know
you-
you
actually
have
sort
of
articulated
the
problem
that
you're
trying
to
solve,
but
it's
not
fully
clearly
defined
in
terms
of
you
know
how
it's
going
to
address
scalability
and
uniqueness,
with
respect
to
the
fact
that
you're
increasing
privacy
and
making
distributed-
and
I
think
that
if
you
try
and
hold
a
buff
that
I
don't
think,
that's
the
right
choice,
because
I
think
it
would
be
a
a
pretty
big
failure
and
and
part
of
it
is
both
normally
shouldn't-
have
a
complete
statement
right.
R
It
should
be.
One
of
the
first
questions
is:
is
there
a
problem
to
be
solved?
Is
this
a
problem
that
the
ietf
can
solve?
And
I
think
that
the
answer
to
those
right
now
by
the
general
community
just
guessing
would
be
no,
and
it's
not
that
it's
not
important
or
it's
not
that
the
properties
of
your
system,
you
know
are
aren't
actually
solving
good
problems.
It's
because
of
the
conflict,
because
the
uniqueness
because
of
the
scalability,
concerns
it,
and
you
know
that
have
already
been
raised
today.
I
think
that
would
be
hard.
R
I
do
think
it's
a
fantastic
research
problem
and
I
think
dinrg
as
I,
as
I
think
said,
the
very
first
comment
I
made
is
probably
the
right
place
to
go,
but
you
need
to
ask
them.
You
know
just
giving
a
presentation
is,
isn't
you
know
essentially
good
enough
to
get
on
their
their
list
of
active
drafts?
You
have
to
say
look
I
want
to
make
this
a
an
active
draft.
That
seems
like
the
right
place
to
go
to
me.
N
Oh
all,
right
folks,
thanks
for
the
feedback
on
that
question,
so
it
sounds
to
me
so
rolling
back.
The
previous
summary
sounds
like
the
sum
right
here
is:
if
there's
going
to
be
any
ietf
work
on
this,
it
needs
a
full
bath
and
a
bunch
of
cross-area
review,
and
it
sounds
like
the
feedback
to
the
ads
on
approving
such
a
buff
would
be
that
we
need
some
deconfliction
with
dynargy
and
kind
of
an
understanding
of
how
this
fits
with
that
work.
N
F
Thanks
richard
that
that
seems,
that
seems
exactly
kind
of
right.
There
are
a
lot
of
equities
to
consider
here
in
the
itf.
We
could
only
get
that
by
assembling
assembling
kind
of
everyone
in
a
both-like
format
but,
as
you
said,
there's
there's
a
conversation
to
have
in
the
ir
irtf
that
would
inform
whether
we
could
pull
this
off.
N
N
A
N
A
So
since
no
one
else
seems
to
have
anything
more
to
bring
I'd
like
first
of
all
to
thank
our
minute
takers
and
everybody
for
a
very
useful
and
to
the
point
discussion.
This
is
the
first
time
that
since
I've
been
a
chair
that
we
finish
before
time
and
thanks
everybody
for
joining
and
see
you
soon
bye,
oh
roman,
did
you
want
to
say
something.
F
Yeah
francesca
I
just
wanted
to
put
in
the
final
word,
I
think
one
of
the
things
that
really
helped
us
facilitate
the
conversation
was
a
lot
of
prep
beforehand.
So
the
robust
conversation
on
the
mailing
list
on
all
the
documents
very
much
helps
this
process,
as
does
having
an
agenda
which
points
to
all
of
that
prior
conversation,
so
folks
that
did
not
participate
could
walk
in
with
all
of
that
background,
so
really
thank
you
to
the
chairs
for
for
doing
that
and
and
to
the
community.