►
From YouTube: IETF114-DANCE-20220728-2130
Description
DANCE meeting session at IETF114
2022/07/28 2130
https://datatracker.ietf.org/meeting/114/proceedings/
A
All
right
welcome
to
dane
authentication
for
network
clients
everywhere
otherwise
known
as
dance,
I'm
wes
redeker,
one
of
the
chairs
joey,
unfortunately
can't
make
it
this
time,
and
just
so
you
know,
she's
done
a
ridiculous
amount
of
work
she
does
more
than
I
do.
I
let
her
push
all
the
buttons
because
she's
fairly
new
to
cheering
and
is
just
taken
on
with
enthusiasm,
so
I
miss
her
greatly
and
she's
awesome
back
in
ietf
87
way
back
in
berlin.
I
walked
by
this
infrastructure.
A
This
is
like
in
scaffolding
right
outside
the
ietf
hotel
room
and
for
those
in
the
back
that
can't
read
it.
The
little
yellow.
You
know,
banners
around
this
construction
says
time
to
dance.
I
thought
it
was
like
the
weirdest
thing
I
had
ever
seen,
so
I
took
a
picture
of
it
and
this
is
a
picture
of
it.
I
didn't
even
realize
until
you
know
two
or
three
iatfs
that
for
this
one
it
had
to
go
on
a
slide
right
and
clearly,
since
back
in
etf
87,
I
have
been
destined
to
you,
know
chair.
A
This
working
group
is
sort
of
my
takeaway,
for
it
people
love
it
and
it
was
a
horrible
shot
to
take.
There
was
no
good
angle
to
take
it
out,
but
I
did
the
best.
I
could
so
the
note.
Well,
you
have
heard
about
this
many
times
this
week,
you're
going
to
hear
about
it
again
because
it's
important
make
sure
that
you
understand
there
are
you
know
legal
ramifications
for
participating,
especially
under
your
sponsor
at
ihfs,
especially
with
respect
to
patents
and
disclosures,
and
things
like
that.
I'm
not
a
lawyer.
A
So
that's
my
10
second
summary
of
something
you
should
have
your
lawyers
look
at
there's
a
lot
of
information
about
the
notewells
stuff.
In
particular,
you
know
we
have
bcps
on
the
internet
standards
process
and
how
it
works,
the
working
group
process
and
how
it
works.
The
anti-harassment
procedures,
the
code
of
conduct,
the
copyright
and
patents
and
participation,
as
well
as
our
privacy
policy.
A
The
code
of
conduct
guidelines
are
specified
in
rfc,
7154
and
they're
important,
and
let's
treat
everybody
with
respect.
I
think
this
group
generally
has
done
that
because
we
dance
and
play
along
nicely
with
each
other
speak
slowly
and
limit
the
use
of
slang.
Disrupt
dispute,
don't
disrupt
ideas
that
was
horrible
dispute
ideas
by
using
reasoned
argument
and
not
other
type
of
slang,
use
your
best
engineering
judgment
for
the
whole
internet
and
then
contribute
to
the
work
of
the
ietf
I'll
remind
you.
A
I
actually
thought
that
there
was
a
mask
on
this,
but
there
isn't.
The
ietf
does
have
a
masking
policy.
We
should
all
be
wearing
masks
at
all
time
and
working
in
ietf
controlled
areas
which
are
venues
like
this,
and
it's
one
of
the
reasons
that
our
coveted
transmission
rate
is
so
low.
This
iutf
and
I
hope
to
go
home
without
code,
and
I
hope
you
do
too.
A
This
is
the
information
for
the
dance
working
group
there
is.
You
know
there
are
the
normal
information,
there's
a
purpose
or
mailing
list
how
to
subscribe
to
it,
and
then
we
have
three
working
group
documents
that
top
one.
Actually,
there
is
a
zero
zero
draft
and
because
my
mail
server
is
down,
I
haven't
been
able
to
click
on
the
stupid
email
link
in
order
to
approve
it,
but
it's
actually
there
and
it's
in
the
queue
waiting
for
me.
A
This
meeting
is
being
recorded.
I
think
everybody
knows
that
at
this
point,
it'll
be
live
on,
it'll,
be
on
youtube
later,
when
you
participate,
please
do
scan
the
qr
code
with
your
phone
or
click
on
the
link,
either
on
your
laptop
or
in
or
on
your
phone
version
of
the
agenda.
It's
important
for
a
participation
count.
So
even
if
you're,
not
planning
on
speaking,
please
click
on
it.
It's
also
where
all
the
fun
chatting.
D
A
For
today's
agenda,
we
just
went
through
the
chairs
introduction
that
was
most
of
it.
Tim
has
agreed
to
take
notes.
I'm
sure
tim
would
really
really
love
it.
If
somebody
else
would
watch
the
notes
and
type
when
he's
not
because
it's
a
tiring
job,
there's
a
note,
there's
a
note
taking
link
in
the
agenda
as
well.
There
isn't
a
discussion
about
the
call
for
adoption
results.
You
can
ignore
that,
because
we've
already
adopted
everything
the
working.
A
Is
still
kind
of
comes
in
small
spurts,
but
but
we're
actually
getting
stuff
done
anyway.
We'll
have
a
short
discussion
about
the
current
work
items
about
those
three
documents
in
particular,
and
then
we
have
two
interesting
dance
use
cases.
One
jacques
latour
is
going
to
talk
about
one
from
sierra
and
bob
moskowitz
is
going
to
talk
about
drip
and
how
dance
might
help
in
those
cases.
A
But
we
will
start
with
the
architecture.
Document
actually
did
conclude
in
may
and
actually
has
been
since
the
last
ietf,
and
so
there
was
a
three-week
call.
It
was
clearly
had
good
support,
so
we
did
adopt
it
and,
as
I
said,
the
zero
zero
was
coming
out
shortly.
A
This
is
all
of
the
mail
that's
gone
through.
You
can
see
it's
actually
ticked
up
a
little
bit
in
the
last
couple
of
months,
so
good
job,
everybody
nice
way
to
dance,
but
more
is
always
better.
This
is
still
a
fairly
low
volume
working
group,
but
I
think
a
lot
of
it
is
there's
not
much
contention
in
the
documents
with
that,
I'm
going
to
turn
it
over
to.
I
think
schumann
is
going
to
lead
the
slides
right
and
we'll
pull
your
slides
up.
A
F
Yes,
which
are
the
following,
so
the
first
one
is
the
dane
protocol.
That's
the
dane
tls
client
authentication
document
and
the
second
one
describes
the
tls
extension
used
by
the
protocol
for
signaling
the
use
of
this
mechanism
and
optionally
to
convey
the
domain
name
of
the
client
in
situations
where
that's
necessary.
F
The
you
know,
the
main
example
is,
if
you
using
raw
public
key
authentication.
So
so
I
think
these
protocols
are
largely
done,
or
maybe
even
done
at
this
point,
but
I
did
want
to
highlight
one
aspect
of
the
protocol
because
it
took
a
couple
of
implementers
slightly
by
surprise
when
they
found
out.
I
found
out
that
there
are
some
differences
in
where
the
protocol,
the
new
protocol
elements,
are
placed
in
tls,
1.2
versus
1.3.
F
So
in
1.2
we
really
don't
have
any
choice
but
to
place
them
in
the
client,
hello
in
the
server
hello
where
they
are
unencrypted.
That's
the
only
thing
that
can
happen
in
that
version
of
the
protocol
and,
as
you
might
expect,
there
was
some
pushback
from
security
and
privacy.
Folks
about
that.
So
we
addressed
that
in
the
tls
1.3
version
of
the
protocol
next
slide
by
moving
the
extensions
into
the
certificate
request
and
the
certificate
message
on
the
server
and
client
side
respectively.
F
Whereas
if
you
know
the
protocol,
those
things
are
encrypted.
One
other
thing
you
might
have
noticed
is
the
ordering
has
changed
so
in
tls
1.2.
F
There's
a
corresponding
advertisement
of
that
extension.
The
certificate
request
message
and
I
see
a
couple
of
people-
are
queuing
up
for
comments,
so
maybe.
G
Sure
I
attempted
to
address
this
topic
actually
at
the
end
of
the
utah
session,
by
asking
where
I
might
be
able
to
define
a
new
tls
extension
yet
another
one
that
would
ask
the
server
to
solicit
a
client
certificate
yeah
in
this
diagram,
the
server
you
know,
statically
solicits
one,
but
there
are
various
applications
where
that's
not
the
case,
and
so
even
in
tls
1.3
we
could
define
an
extension
with
no
no
privacy
payload
at
all.
It
just
says:
please
solicit
my
certificate
and
that
might
address
this
issue.
G
The
only
question
is
which
working
group
does
that
go
into
uta
this
one
or
tls,
I
don't
know
or
care,
but
somebody
should
have
an
answer.
Perhaps
paul
will.
G
Could
perhaps
go
into
this
one?
If
there's
no,
like
you
know
territoriality,
where
tls
will
say?
No,
no,
no,
we
want
to
define
it.
I
don't
know.
G
H
F
Why
support
it
at
all?
Is
that
what
your
question
is?
Yeah,
yeah,
that's
a
good
question,
so
I
think
one
of
the
ways
we
addressed
that
the
first
security
and
privacy
objection
was
by
saying
that
the
dance
protocols
is
probably
going
to
be
greenfield
applications.
So
maybe
everything
will
roll
out
with
tls
1.3
and
we
don't
have
to
care
about
tls
1.2.
F
F
H
So
there's
a
couple
of
other
things
that
I
didn't
see
in
the
draft
that
probably
do
need
some
consideration
here
in
relation
to
this
privacy
issue
that
you
have
essentially
what
you.
What
you
have
here
is
the
ts12
client
for
some
classes
of
servers
that
it
talks
to
essentially
just
publishes
to
the
world.
It's
its
identity
and
and
the
of
the
stuff.
H
F
H
It
does
give
you
confidentiality
for
the
for
the
client
authentication
pieces,
and
that
is
a
very
common
technique.
That's
used
for
people
who
are
doing
client
authentication,
particularly
in
those
contexts
where
it
is
potentially
sensitive.
Information.
F
H
The
other
one
to
consider
here
also
regarding
victor's
point,
is
we
have
post
handshake
authentication
into
ls
1.3.
We
also
have
exported
authenticators,
which
both
give
you
an
option
to
provide
information
about
client
identity
outside
outside
of
the
context
of
the
handshake.
So
you
can
have
something
at
the
application
layer
that
that
says.
I
need
this
information
and
then
you
can
sort
of
bootstrap
into
any
of
that.
H
F
F
You
know
complications
in
the
application.
That
was
probably
the
rationale,
but
I
guess
we
haven't
really
discussed
that
so
right.
A
G
G
Yesterday,
okay,
a
couple
of
comments:
one,
the
kind
of
clients
that
have
privacy
concerns
generally
don't
end
up
as
being
nodes
in
the
dns
tree.
This
was
the
primary
use
case
for,
for
this
originally
was
mta
to
mta.
You
know
smtp
and
obviously
it's
being
extended
to
all
kinds
of
other
client
scenarios,
some
of
which
may
have
privacy
concerns,
but
the
initial
ones
in
uta
right
there's
a
long
discussion
now
in
drafts,
where
uta
says
you
must
implement
tls
1.2
still
tls
1.2
is
not
a
dead
protocol.
G
If
you
read
you
know
many
of
the
wonderful
posts
by
peter
goodman,
tls
1.2
is
here
forever,
so
I
don't
think
we
can
ignore
tls,
1.2
and
perhaps
some
of
the
industrial
applications
if
they
need
this
would
would
stay
in
tls
1.2
for
a
very
long
time,
and
as
for
negotiation,
we
now
have
for
various
security
reasons
about
cpu
denial
of
you
know,
service
attacks
and
so
on.
Many
servers
now
turn
off
for
renegotiation
as
a
matter
of
policy.
G
It's
now
considered
best
practice
to
say
no
renegotiate,
so
there
are
all
kinds
of
barriers
to
doing
it.
The
privacy
way
in
many
scenarios
in
which
the
privacy
is
not
a
desirable
or
at
least
a
required
feature
and
unclear
whether
the
privacy
clients
would
find
themselves
published
in
dns,
with
their
tlsa
records
or
whatever.
A
F
Yeah
so
so
to
victor's
point,
so
I
agree
for
the
smtp
transport
client
case.
Clearly,
there's
probably
no
privacy
issue,
but
I
think
there's
a
bunch
of
emerging
danger
to
use
cases
where
probably
it
will
become
an
issue
right,
so
we
may
have
to
deal
with
it.
It's
a
general
purpose
protocol.
After
all,.
E
E
Now,
of
course,
there's
is
a
green
field
situation,
so
there
is
that
distinction,
so
you
should
undoubtedly
put
in
text
in
here,
as
for
the
justification
of
including
1.2
is
that
this
is
not
for
greenfield
use,
and
there
is
this,
this
large
community,
which
which
will
take
some
decades
to
go
away
so
include
tax
forward,
that
no,
why
the
1.2?
That's
why
I
came
to
say
it
not
to
vote
against
her
for
but
explain
why.
B
Okay,
so
I
wanted
to
follow
on
one
point
that
martin
thompson
raised,
and
it
goes
back
to
some
of
the
assumptions
made
in
this
in
this
design,
which
is
that
the
authentication
happens
within
the
tls
layer
in
the
handshake
and
not
after
the
fact,
and
I'm
I'm
wondering
first
of
all,
question
one
is
is
that
is
that
a
hard
requirement?
Is
that
or
is
that,
just
where
the
design
ended
up,
naturally
fitting?
And
if
it's
not
a
hard
requirement?
B
I
I
would
encourage
you
to
look
at
exported
authenticators
because
it
provides
a
unified
way
to
to
exchange
bits
of
authentication
from
client
server
and
and
back
that
is
compatible
with
tls
1.2
and
1.3.
Without
tpls
handshake
changes
as
you
sort
of
raised
at
the
microphone,
there
will
be
potentially
some
additional
changes
at
the
application
layer
to
support
this
exchange,
and
that
might
be
that
that
might
be
too
difficult.
B
But
if
we're
talking
about
legacy
systems
right
now,
modifying
old
tls,
1.2
server,
server
implementations
seems
like
it
might
be,
just
as
messy
as
having
protocol
specific
game-based,
authentication,
post
handshake
with
application
messages
and
exported
authenticators.
We
also
have
stronger
guarantees
of
the
security
model
there,
because
it's
based
on
tls
1.3
exclusively,
even
though
it
works
with
1.2.
F
F
Were
trying
to
make
it
so
that
we
reduce
the
burst
and
burden
on
application
protocol
we
can
just
plug
into
the
tls
layer
that
has
these
features
and
then
be
done
right,
so
asking
applications
to
do
a
lot
more
work.
I
don't
know
if
that's
going
to
work
or
not,
I
see
victor,
says
shaking
his
head.
Okay,.
F
As
I
said,
barring
that
discussion,
I
think
the
document
is
mostly
done.
There
were
a
couple
of
comments.
These
are.
B
F
F
F
Yes,
push
this
ahead
or
do
we
need
to
wait
for
that
document
to
be
fleshed
out
so.
F
Okay
and
and
yes,
michael-
will
fix
the
capitalization
of
iot.
I
think
I
have
one
more
slide:
okay,.
A
A
F
A
Here,
I'll
stop!
Okay
great,
so
I
think
it
sounds
like
one
of
the
documents
is
likely
fairly
well
done
and
the
other
one
sounds
like
after
today's
discussion
needs
a
bit
more
work
before
we
consider
going
to
last
call.
So
one
of
the
things
to
the
the
working
group
is,
I
really
want
to
know
you
know
what
other
outstanding
issues
are
there
before
we
go
to
last
call
for
the
documents
because
they're
they
have
been
not.
You
know
super
actively
edited
recently,
because
they're
already
fairly
complete,
so.
F
Yeah
I
mean
the
only
thing
is:
if
we're
going
to
go
down
the
route
of
looking
for
how
to
do
this,.
F
G
Just
in
terms
of
being
done,
I
I
do
think
we
need
to
figure
out
whether
the
please
solicit
my
certificate
is
sort
of
a
requirement
for
this
one
to
be
finished
or
not.
G
G
I
think
that's
a
the
wrong
thing
to
do
at
the
wrong
layer,
and
I
so
I
think
part
of
this
protocol
might
be
this
one
more
extension
that
would
go
into
it.
If
there's
no
major
objections,
we
could
add
it.
In
the
other
hand,
if
there
are
serious
objections,
we
should
figure
that
out
on
the
list,
perhaps.
F
F
G
Any
time
that
servers
selectively
solicit
client
certificates,
yeah
yeah.
F
G
Are
there
others,
anytime,
really
that
clients
don't
usually
have
certs
where
it's
not
anticipated
and
where
there
are
interoperability
concerns?
Because
when
you
request
certificates
from
clients,
some
of
them
will
blow
up
and
say
I
don't
have
a
certificate
game
over
it's
common
with
java
and
you
know
some
other.
You
know
systems
yeah,.
G
G
J
Hi
ben
kaydak,
so
I
came
up
to
basically
suggest
that
victor
write,
a
standalone
draft
about
the
please
solicit
my
client
certificate
extension
and
that
will
give
us
a
place
to
think
about
it,
write
down
some
security
considerations,
what
not
and
discuss
whether
it
actually
fits
better
in
this
document
or
in
a
standalone
thing
that
would
go
to
tls
or
wherever.
J
I
think
that
the
official
mit
web
server
like
15
years
ago,
if
you
spoke
https
to
it,
it
would
request
a
client
certificate
and
if
you
wanted
public
content,
it
had
to
be
http
only,
and
that
of
course
has
changed
since
then,
but
the
behavior
regarding
when
to
request
client
certificates
on
that
particular
web
server,
is
kind
of
interesting
and
I
think,
would
definitely
benefit
from
the
ability
to
say
I
want
to
get
the
authenticated
functionality
rather
than
the
public
functionality
and
there's
currently
some
hacks
in
place
to
approximate
that.
A
D
But
the
case
I
wanted
to
speak
about
actually
was-
and
this
is
why
I
was
thinking
it
did
belong
in
this
document
and
it
did
belong
in
its
working
group.
But
ben
has
now
convinced
me
otherwise
was,
I
think,
there's
an
awful
lot
of
really
crappy
tls
implementations
in
microcontrollers
that
in
iot
devices,
and
so
what
the
situation
would
really
be
that
there's
you
know
a
hundred
thousand
of
them
out
there
they're
all
going
to
crash.
If
the.
D
If
the
you
know
the
central
point
starts
asking
for
certificates
randomly,
and
so
this
actually
is
how
you
get
them
updated
and
when
they
get
updated
they
may
also
get
updated
for
1.3
and
a
bunch
of
stuff.
But
that's
not
going
to
happen
overnight.
It's
going
to
be
incremental
and
it's
probably
a
sufficiently
big
upgrade
that
you
know
this
may
actually
involve
more
for
more
more
more
code,
storage
and
stuff
like
this.
This
may
be
forklift
upgrades
to
to
get
rid
of
them.
D
D
So
for
those
reasons
I
really
would
like
to
have
this,
please
ask
for
my
certificate
that
would
be
really
lovely
and
yeah.
Please,
let's
have
another
document.
I
would
have
just
stuck
it
in
the
client
auth
document,
not
thinking
that
about
the
website
use
but
yeah.
Let's
have
another
document
and
then,
let's
argue
or
who
gets
to
publish
it,
yeah,
that's
good.
F
F
A
You're
done
yep.
Thank
you.
Thank
you
very
much
with
that.
We
will
move
on
to
the
use
case
presentations
who
were
both
hoping
for
plenty
of
time.
We
will
start
with
jacques.
C
Hello,
all
right,
so
I'm
joking
I'm
with
syrah,
and
I
guess
I'm
here
to
talk
about
how
we
can
leverage
the
nsx
and
digital
identity
and,
I
think,
there's
a
really
good
use
case
for
dance,
dane
tlsa
to
work
in
this
world.
C
A
C
C
That's
what
we're
working
on
so
based
on
the
digital
identity,
world,
there's
an
issuer
of
credential,
verifiable
credential.
In
our
case,
it's
the
iot
registry.
We
have
wallets
holders
of
credential
iot
device
and
an
asp
is
a
verifier
and
other
stuff.
So
I'll
start
with
the
credential
next
slide.
C
C
C
C
So
the
issuer
of
the
verifiable
credential
to
that
iot
device
publishes
in
the
dns
a
tlsa
record
for
that
iot
device.
So
it's
a
hash
of
the
serv
that
was
issue,
a
public
search
that
was
issued
to
the
iot
device
and
the
sand
of
that
record
matches
the
tlsa
label
here
and
then
you
can
verify
that
the
iot
device
is
who
they
say
they
are,
and
that's
the
cool
part
with
dance
this
this
work.
I
I
love
that
framework.
That's
great,
so
good
stuff
there.
C
B
C
Yeah
go
back
so
the
iot
device,
the
cert
is
signed
by
iot
registry
and
that's
what
we
need
to
to
figure
out.
So
we
need
the
tlsa
record
for
the
public
key
of
the
signer
available
in
the
dns.
So
you
can
verify
that
this
search
matches
the
tlsa
and
the
public
key
signing
it
to
the
designer
matches
with
that
tlsa
record.
So
this
we
can
do
today.
Next.
C
So
there's
two
ways
to
verify:
the
certificate
that's
issued
to
the
iot
device.
There's
the
certificate
itself.
That's
it's
signed
by
iot
registry.ca.
You
can
find
the
sub
certificate
in
the
trust,
store
somewhere
and
make
sure
it's
done
properly.
They
did
the
digital
world.
Digital
identity,
world
works
at
this
level
and
then
in
parallel
with
the
nsx
tlsc,
we
can
issue
the
lsa
record
for
everything
and
do
the
same
validation
so
that
works
today.
That's
something
we
can
do
next,
so
I'm
going
somewhere.
Don't
don't
worry
next
slide.
C
C
You
know,
and
then
the
wallet
the
iot
device
in
this
example
has
a
credential
signed
by
the
issuer,
the
iot
registry
and
then,
when
you
present
those
credentials
to
the
verifier,
the
application
needs
to
verify
that
you
know
what
in
the
digital
identity
world
it
goes
to
a
trust
registry.
C
The
wallet
says:
am
I
allowed
to
give
this
credential
to
that
verifier?
Do
I
trust
that
for
a
fire
and
the
verifier
says,
do
I
trust
this
wallet?
Do
I
trust
this
work
and
that's
there's
a
whole
lot
of
discussion
around
trust
registry.
Focusing
on
that
so
next
slide
and
the
question
is
it's
always
around?
The
famous
word
trust.
How
do
you
trust
something
in
the
digital
identity
world
and
they
they
have
human
layer,
trust,
institutional
trust,
legal
trust,
technical
trust,
so
I'm
focusing
on
technical
trust,
so
next
slide.
C
So
I've
been
watching
way
too
much
strange
world
thingy
show
on
netflix,
so
digital
identity
is
on
the
top
world
and
I
think
dns
the
nsx
can
be
in
the
under
world
the
upside
down
world
and
there
I
think,
there's
a
way
we
can
do
the
nsx
tlsa
to
support
this
environment,
so
human
legal
trust
in
the
front
technical
in
the
back
with
dns
and
the
question
is,
if
you
have
a
verifier,
how
do
you
find
the
right
trust
registry
that
recorded
that
those
digital
those
verifiable
credentials?
So
next
slide.
C
C
C
C
They.
They
have
a
tlsa
record
for
the
root
cert
that
they
use
with
the
public
key
and
they
have
a
tr
record
saying
you
know
what
iot
registry
is
registered
in
trustworth
registry
dot,
ca,
so
trust
registry.ca
is
the
entity
that
registered
iut
registry
based
on
its
governance
model
and
its
rules,
and
all
that
and
then
trust
registry.ca
publishes
a
tlsa
record
with
a
trustworthy
label
to
say
you
know
what
I
iot
registry.ca
dot
underscore
trust
registry
is
registered
inside
the
trust
registry
for
canada,
with
a
tlsa
with
a
hash
of
its
public
key.
C
So
if
a
credential
is,
if
somebody
looks
at
a
credential,
they
can
work
out
which
trust
registry
you
should
go
look
at
to
find
that
issuer
and
get
all
the
keys
to
make
sure
that
they're
signed
properly
and
all
that.
So
the
ability
to
do
this
in
the
digital
world
does
not
exist.
They
haven't
figured
out
how
to
do
that
part.
I
think
we
do
something
like
this.
It
facilitates
the
process
so
next
slide.
C
If
they
get
a
credential
issued
by
a
another
country,
how
do
they
go
back
to
that
country
to
figure
out
it
exists?
So
if
you
have
a
china
trust
like
this,
where
the
iot
registry.ta
is
registered
in
the
trustworthiness
without
ca
entity
and
the
trustworthiness3.ca
is
part
of
the
iana
trust
registry
and
the
infrastructure
registry
as
a
trust
anchor
in
the
root
zone,
then
with
the
nsx,
you
can
build
a
chain
of
truss
all
the
way
down.
C
C
So
this
is
about
building
trust
registries,
trust
registries,
being
part
of
other
trust
registries
and
having
a
chain
of
trust
from
iana,
and
I
think,
if
we
do
something
like
this,
it
would
enable
so
there's
there's
a
whole
lot
of
discussion
in
the
digital
identity
world
in
anchoring
all
the
digital
identity
documents
inside
blockchain-
and
my
my
hope
here
is
that
we
could
use
this
to
anchor
digital
identity
instead
of
blockchain
and
show
that
you
know
what
this
can
be
trusted
from
ayanna
up,
it's
kind
of
delegated
decentralized
model.
So
next
slide.
C
So
I
think
you
know
at
a
high
level
there's
a
good
story
alex
started
to
work
on
the
draft
for
did
dns03
to
link
did
to
dns,
so
you
know
for
them.
C
I
just
focus
on
the
dns
part
there,
but
there's
more
to
this
story
than
this,
so
we
have
a
repo
in
get
lab
with
dance
with
this
presentation
and
other
stuff,
but
I
think
in
the
end,
if
we
had
something
like
this,
it
would
be
good
value
for
the
digital
identity
world,
with
trust
over
ip,
with
w3c
to
anchor
with
confidence
the
dns
inside
the
digital
identity
world,
and
that.
A
Okay,
here's
the
deck
all
right
thanks
chuck,
certainly
interesting
case
with
lots
of
new
things
in
the
interest
of
time
to
keep
on
track.
So
we
have
more
time
for
another
presentation.
I'm
asking
clarifying
questions
only
if
you
have
you
know,
should
we
do
this
or
should
we
not
that
it
is
a
future
charter
item
and
should
go
to
the
mailing
list,
and
I
would
love
to
see
discussion
on
it.
Don't
get
me
wrong,
but
not
today,
on
the
mic
line.
Go
ahead.
K
Clarifying
question:
why
did
you
put
ayanna
in
there
other
than
the
fact
that
other
people
know
it
could
that
be
some
other
organization?
That
is
the
collector
of
trust
organizations?
Could
it
be
something
in
the
u.n
something
else
or
does
it
need
to
be
iana.
C
G
H
I'm
an
even
simpler
person
than
victor.
Why
do
we
need
a
new
rr
type
for
this.
C
C
A
C
E
Okay,
thank
you
very
much,
and
this
will
be
looking
at
identity
identifier
in
a
different
light
than
we
just
had,
and
how
I'm
looking
at
leveraging
dance
for
online
aircraft
communications
next
slide,
and
fortunately
I'm
dealing
here
with
the
green
field.
Most
communications
today
is
line
of
sight,
often
with
no
ap,
and
this
is
changing
the
r.
It
will
be
constrained
capacity
that
we
have
to
deal
with.
There
are
two
basic
types
of
communication
command
and
control,
typically
called
just
c2
between
the
unmanned
aircraft
and
the
ground
control
station.
E
The
other
one
is
network,
remote
id,
which
is
the
telemetry
from
the
the
unmanned
aircraft
to
the
unmanned
traffic
management
system.
Next,
even
autonomous
operations
need
communications.
E
There
is
the
c2
updates,
both
ways
but
less
traffic
than
non-autonomous
operations,
but
telemetry
is
always
we
always
must
do
telemetry
and
if
autonomous,
it
must
be
from
the
unmanned
aircraft
not
from
the
ground
control
station,
because
in
non-autonomous
operations
the
ground
control
station
gets
telemetry
anyway,
as
part
of
the
the
c2
and
may
do
the
forwarding
to
the
ut
to
the
utm.
E
Many
of
you
may
be
aware
of
the
manned
aircraft
adsb.
This
is
not
an
option.
We've
been
told
in
the
regulations
that
adsb
will
not
be
used
for
unmanned
aircraft
and
if
you
have
any
questions,
we
do
have
some
people
here
who
can
answer
that
directly,
but
you
can
take
my
word
for
it.
And
finally,
there
is
a
lot
of
talk
that
future
of
utm
rerun
directives
direct
to
the
ua,
so
how
the
utm
will
tell
the
ua.
E
E
Dtls
is
a
likely
choice
for
most
network
remote
id
because
it's
to
a
fixed,
known
network
mode
id
service
provider,
but
when
the
ua
is
on
multiple
interfaces,
there's
a
known
problem
with
current
dtls
code
that
it
can't
handle
changes
on
which
interface
is
coming,
but
that
should
be
fixable.
That
sounds
like
just
like
an
implementation
in
the
code
problem,
but
it
has
been
brought
to
my
attention
for
trying
to
do
this
when
the
the
ground
control
station
is
mobile.
E
Esp
is
more
likely
to
be
the
mole
ike
or
hip,
for
the
can
to
control
example.
That
is,
ups
is
proposing
that
the
ups
trucks
will
be
the
ground
control
system
with
with
the
the
ua
being
launched
from
the
the
the
the
the
truck
and
they
make
and
it's
making
delivery.
E
While
the
operator
is
going
to
the
next
place,
and
so
it
potentially
moves
around
the
network
and
so
esp
and
beep
mode
is
a
natural,
is
naturally
multi-homed
and
will
work
well
in
this
either
keyed
either
way,
and
all
this
is
in
my
draft
mosque,
which
secure
enrich
c2.
This
has
not
been
adopted
by
the
drip.
I
left
up
drip
in
there
left
that
out
by
the
drip
work
group
because
they
wanted
to
first
finish
the
broadcast
remote
id
before
we
tackled
the
network
remote
id,
but
it
is
current
work
for
the
group.
H
E
It
is
a
potential
I've
not
heard
discussed.
There
is
a
directive
from
iko
for
manned
aircraft.
Then
man
aircraft
will
be
dtls.
E
Okay
and
so
kind
of
fading
up
and
you're
right,
quick,
is
potentially
another
option
which
I've
not
delved
into
yet.
Okay,
okay,.
H
E
Yeah
now
the
ua
identities
are
defined
in
draft
ietf
drip
grid,
which
is
finishing
up
its
review
and
could
be
done
pretty
soon.
The
registry's
draft
needs
a
lot
of
work
still,
as
came
out
from
the
hackathon
this
past
weekend.
E
E
That's
because
it
gives
us
some
nice
size
characteristics
to
work
with
so
define
dns
fqdns
for
all
drip,
enabled
ua.
It's
very
easy
because
of
the
structure
there
to
set
up
that
that
the
the
debt
resolves
to
this
particular
fqdn,
and
if
the
debt
is
not
in
dns,
the
debt
was
revoked.
So
there's
no
revocation
process
in
here
other
than
if
you
can't
find
it,
it
was
revoked
and
if
you
have
authorization
you
can
ask
the
registry.
Why
was
it
revoked?
E
But
will
this
be
possible
for
zones
run
by
the
hcit
domain
authorities?
The
hda,
with
hundreds
of
new
debts
per
hour,
be
able
to
sign
zone
to
be
determined,
but
no.
If,
if
this
is
a
a
registry
which
is
supporting
a
delivery
service
which
is
requesting,
you
know
a
bunch
of
session
ids
for
each
delivery
operation,
there
are
going
to
be
millions
of
these
created
and
aged
out
quite
rapidly
and
will
dns
sec
be
able
to
deal
with
that.
Unfortunately,
now
I
say
attestation
here.
E
We
have
since
learned
that
in
rat
determination
it
should
be
evidence.
So
in
my
slides,
where
I
say
attestation
think
evidence
in
the
terms
of
rats,
so
the
registration
evidence
insert
resource
records
via
private
oid.
That's
just
how
you
can
put
private
oid
allows
you
to
put
any
object.
You
want
in
a
cert
resource
record,
see
the
registry's
draft
and
how
I'm
doing
that.
The
interesting
thing
is
this
is
provides
proof
of
registration
and
thus
trust
in
the
det
without
having
dns
set.
E
So
if
you
receive
the,
if
you're
able
to
pull
out
or
actually
receive
it
in
the
broadcast
message,
the
the
this
registration
evidence,
you
know
that
this
debt
has
been
registered.
E
E
E
These
are
the
servers
run
by
the
the
network,
remote
id
service
providers,
so
we're
not
talking
about
a
large
community
and
if
the,
if
drip
is
widely
adopted,
this
could
mean
millions
of
uas
in
the
coming
years,
feeding
telemetry
into
utm
even
via
the
ground
control
station,
and
note
that
that
c2
will
tend
to
use
pre-stored
on
ua
identity
for
dtls
authentication,
because
you
have
this
natural.
You
purchase
your
ua
with
your
ground
control
system
or
you
install
the
software
on
your
smartphone.
So
that's
like
a
closed
environment.
E
E
It
gets
a
little
more
complicated
for
what
they're
doing,
though
it
is
doable
for
them
as
well
next,
and
that
completes
my
slides
and
and
our
intent
here
that
I'm
looking
that
dtls
may
be
very
important
for
a
number
of
reasons
and
that
then
using
dance
for
how
the
identities,
how
how
they'd
like
to
just
pass
the
fqdn
in
in
the
handshake,
don't
have
to
pass
all
the
rest
of
it.
The
server
can
look
it
up
and
it
will
just
work
well
and
could
end
up
being
a
lot
of
it.
E
I
Hi
paul
speaking
as
just
an
individual,
I
just
wanted
to
remind
you
that
we
have
ways
of
storing
chains
of
dns
records
the
query
chain
and
you
can
use
them
to
offline
synchronize,
your
client
server
state,
if
you
pull
that
from
the
dns.
So
if
you're
offline,
you
can
keep
your
own
link
to
the
root
and
refresh
it
regularly
when
you're
online,
and
then
you
have
like
a
pretty
up-to-date,
valid
path.
You
can
send
to
the
other
side
of
the
tls
connection,
yeah.
E
When,
before
you
take
off
your
ua,
has
some
good
bandwidth
connection,
maybe
through
the
ground
control
system
to
to
do
that
pre-setup
or
takeoff.
But
then
I'm
dealing
with
for
for
like
cargo
delivery,
which
is
then
going
from
one
utm
space
to
another
utm
space.
How
do
we
do
the
handoff,
particularly
if
the
the
the
operation
that
was
filed?
You
have
to
change
it
because
of
whether
or
whatever?
And
so
then
that
may
get
exciting.
I
don't
have
an
answer
yet
how
to
do
that.
One!
E
That's
that's
still
tbd
and
looking
at
my
colleague
on
the
faa
side
and
he's
shaking
his
head,
because
he
has
the
same
class
of
problem
on
much
bigger
pieces
of
hardware
than
I
do.
A
So
one
you
know
thing
that
that
has
always
been
interesting
to
me,
with
things
like
dance
and
dane,
is
which
I
think
matters
to
you
more
than
anybody
else
is
bandwidth
savings.
So
have
you
done
any
measurements
to
determine
you
know
by
using
dan
and
dance
that
you
can
actually
reduce.
E
I
am
doing
bike
counting
and
I'm
looking
really
hard
at
chic
for
how
we're
going
to
be
compressing
this
and
why
I
want
chic
end
to
end
not
just
just
see
on
the
on
on
the
wires,
because
some
of
these,
the
avionics
that
you
may
have
an
an
ethernet
network
on
the
larger
uas
and
so
the
avionics
are
ethernet
connected.
They
don't
know
the
characteristics
so
wireless,
and
so
how
do
we
do
that?
E
A
Does
some
of
this
apply
to?
I
know
the
early
discussions
in
drip
had
to
do
with
sending
data
over
bluetooth,
which
is
a
pain
in
the
neck,
or
is
that.
E
A
E
G
E
That's
yeah,
and,
and
also
that's,
why
looking
to
dance,
that's
it
that
dan's
fqdn!
So
that's
sending
back
to
this.
Only
the
fqdn,
not
the
raw
public
key
in
terms
of
what
is
what
is
passed.
You
people
know
more
about
this
than
I
do.
I
may
be
stepping
my
foot
in
something
that
I
don't
know
I
stepped
into.
J
A
Thank
you
for
your
time.
Thank
you.
So
I'll
remind
everybody
that
you
know
the
use
case.
Some
of
these
use
cases
do
require
additional
drafts
and
protocols
and
stuff,
and
we
knew
when
we
started
dance
that
that
once
we
got
over
the
base,
you
know
a
couple
of
documents
as
well
as
how
it
was
all
going
to
fit
together.
If
you
remember.
I
A
The
very
first
you
know
danish
boss,
before
we
were
dancing
about
danishes.
You
know
there
was
a
lot
of
questions
about
how
all
these
things
were
going
to
fit
together,
and
you
can
see
some
of
these
use
cases
are
getting.
You
know
pretty
complex
and
out
there,
but
that's
how
it
started
from
the
beginning.
So
thank
you
everybody
for
coming.
We
if
it
looks
like
we're
close
to
to
getting
the
you
know
the
first
two
real
core
pieces
of
protocol
documents
done.