►
From YouTube: IETF110-DANISH-20210312-1200
Description
DANISH meeting session at IETF110
2021/03/12 1200
https://datatracker.ietf.org/meeting/110/proceedings/
A
A
A
C
E
Yeah
well
have
a
hangover
from
the
party
the
night
before,
which
is,
you
know
like.
A
All
right
well
welcome
everybody
to
the
danish
authentication
for
internet
of
things,
service,
hardening
or
danish.
I
hope
you've
all
had
danishes
for
breakfast
for
those
of
you
that
are
in
the
earlier
coasts
and
it's
not
afternoon
yet
I'm
wes
hartaker
and
I'm
here
with
michael
richardson,
and
we
are
just
going
to
turn
this
over
in
a
few
seconds
to
the
real
content
the
mailing
list
is
down
below
and
I
think
it's
also
on
one
of
the
next
slides.
I
hope
everybody
is
familiar
with
the
note.
A
Well,
you've
probably
seen
a
bunch
of
these
before
now
we're
not
lawyers
so
you're
on
your
own
for
interpreting
it,
but
it
is
important
and
you
should
follow
its
instructions,
there's
a
lot
of
helpful
information
on
the
third
slide.
If
you
want
to
download
the
slides.
This
is
a
couple
of
starting
items.
This
is
a
non-working
group
formatting
forming
buff.
We
will
still
be
asking
some
sort
of
working
group
forming
buff
questions
at
the
end,
but
we're
not
going
to
be
discussing
the
charter
and
other
things
like
that.
A
That
will
be
done
at
the
future,
but
we
do
want
to
discuss
the
problem
space
and
figure
out
if
it's
in
the
ietf
interest
to
to
take
this
problem
of
space
on.
There
are
three
drafts
at
the
bottom.
Hopefully
some
of
you
have
read
them.
The
top
two
were
actually
posted
by
the
draft
deadline.
The
third
one
only
appeared
this
week
and
and
then,
of
course,
there's
a
mailing
list
and
you
can
subscribe
to
that
as
well.
A
A
Today,
come
on,
somebody
can
take
minutes,
it's
easy.
We
don't
need
extensive
minutes.
You
know,
there's
a
recording
and
everything,
but
at
least
a
list
of
who
agreed
to
do
what
and-
and
things
like
that
would
be
highly
helpful.
A
List
todd
you
rock
todd,
we'll
do
the
minutes.
We
can
go
beyond
the
agenda
slide.
Thank
you.
Thank
you.
Todd
appreciate
it.
So
the
we'll
start
with
a
couple
of
things
we'll
start
with
defining
the
problem.
Space
and
ash
will
go
over
sort
of
what
the
problem
is,
that
they
want
to
tackle
we're
going
to
sort
of
go
a
little
bit
out
of
order,
because
there
is
a
presentation
on
sort
of
one
future
low
case,
which
is
for
loron
that
we
will
do
early
normally.
A
We
would
have
done
that
in
the
outer
scope
area
at
number
five,
but
he
had
a
conflict,
so
we
are
going
to
let
him
go
first
and
then
do
this
slightly
out
of
order.
A
So
then
we're
going
to
go
into
initial
work
areas
and
that's
the
longest
section
of
the
presentation,
that'll
explain
sort
of
the
proposal
for
going
forward
and
you
know
what
they
want
to
tackle
in
in
sort
of
stage
one
of
the
working
group
and
then
we'll
go
into
some
other
out
of
scope,
use
cases
that
are
sort
of
beyond
future
thinking.
A
If,
if
the,
if
the
working
group
succeeds
in
getting
through
its
initial
items
and
at
the
end,
we'll
have
an
open
mic,
where
people
can
talk
about
what
they
think
about
the
problem
and
things
like
that,
there
are
clarifying
q
a
points
along
the
way,
we're
hoping
not
to
do
a
huge
amount
of
discussion
and
get
through
the
content.
Before
we
dive
into
real
back
and
forth.
You
know
later
in
open
mic
and
as
as
always,
we
want
to
know.
Do
we
understand
the
problem?
A
Is
this
problem
space
worth
solving
within
the
ietf
and
is
there
a
good?
Is
this
a
good
starting
set
of
document
who
wants
to
help
with
the
effort?
And
that
is
the
same
thing
so
with
that?
I
will
turn
it
over
to
ash.
Who
is
going
to
start
the
presentation,
I
think
ashley
said
you
wanted
us
to
display
the
slides.
Is
that
correct.
A
A
F
All
right,
hello,
so
jumping
right
into
where
we've
received
the
the
challenges
to
be
with
iot
device
identity.
Private
pki
is
everywhere.
That
seems
to
be
the
going
theme
and
establishing
trust
across
private
pki
is
really
challenging.
You
know
this
is
something
that's
been
solved
in
the
web,
using
the
browser
bundle,
but
we
have
no
such
you
know.
No
such
thing
in
the
in
the
iot
world
to
help
us
establish
trust
across
private
pki.
F
You
know,
there's
really
no
good
technical
control
to
ensure
that
you
don't
have
naming
collisions
across
private
pki,
even
if
you
exchange
ca
certificates.
So
that's
that's
another
challenge.
The
discovery
mechanism
by
which
you
can
you
know
automate.
The
process
of
shipping.
Around
ca
certificates
usually
involves
some
sort
of
proprietary
api
operated
by
the
certificate
authority,
and
so
all
of
these
things
kind
of
drive
toward
you
know
getting
around.
These
challenges
usually
involves
consolidating
onto
a
single
pki
like
an
organizational
pki,
but
this
doesn't
really
solve
the
problem.
F
It
just
kind
of
you
know
makes
that
island
of
trust
even
bigger,
but
very
often
times
you
still
need
to
traverse.
You
know
from
your
island
of
trust
to
another
organization's
island
of
trust
and
and
then
you
still
get
the
same
problems.
So
you
know
an
example.
This
might
be
a
decoupled
application
where
devices
from
one
application.
F
You
know
placing
telemetry
in
a
store
and
forward
system
like
a
message
broker
and
the
trust
becomes
implied
on
the
message
broker
to
honestly
represent
the
identity
of
the
sending
system,
and
then,
of
course,
if
you're
not
attaching
identity
to
the
message
itself
in
a
decoupled
system,
then
the
identity
of
the
sender
ends
up
being
sort
of
you
know
the
trust
is
assumed
based
on
the
integrity
of
the
middleware
and
so
getting
away
from
assumed
trust.
Let's
change
slides,
please.
A
Interrupt,
could
you
turn
off
your
videos,
use
a
requesting
you
do
and
then
you
typically
have
just
one
video
per
presenter
and
then
schumann,
you
have
your
hand
raised.
Did
you
actually
mean
to
do
that.
H
I
did
not.
I
was
just
trying
to
insert
myself
into
the
participants
like
ash,
but
maybe
I'll
do
that
later.
So.
F
Okay,
thanks
ash
go
ahead;
okay,
let's,
let's
go
to
the
next
slide.
Please
looks
like.
F
Four,
so,
in
order
to
sort
of
alleviate
these
challenges,
we
think
that
a
lot
of
this
can
be
solved
by
having
a
broadly
useful
discovery
mechanism
for
private
pki,
and
the
features
of
such
a
system
would
be
that
it
needs
to
work
across.
You
know
private
pki
pretty
easily.
That's
to
you
know
for
things
like
enabling
mutual
tls
authentication
between
devices
in
the
field
that
might
belong
to
different
pki.
F
It
should
work
for
asynchronous
applications,
object,
section
the
store
and
forward
use
case.
It
should
prevent
naming
collisions
and
it
should
ideally
make
credential
rotation
easier.
That's
another
challenge
that
we
see
in
the
space
and
then
it
should
also
work
well
for
constrained
platforms.
F
F
So,
like
I
mentioned
a
moment
ago,
the
ca
bundle
is
really
what
makes
web
pki
web
pki
right.
That's
what
makes
pki
work
well
for
browsers,
but
web
pki
without
the
browser
bundle,
would
feel
an
awful
lot
like
we
have
in
iot,
and
so
you
know
the
we
can't
really
use
web
pki
effectively
for
iot
the
challenges
that
come
along
with
that
are
not
the
least
of
which
are
cost.
F
So
I'm
getting
an
agreement
on
routes
of
trust.
You
know
for
iot
applications
and
especially
when
applications
seem
to
communicate
with
one
another.
F
You
know,
like
I
said
on
the
previous
slide:
that's
certain
distribution
or
consolidation,
and
then,
when
you
have
multiple
cas
in
play,
if
you
don't
have
some
sort
of
anchoring
system
for
the
name,
then
you
can
end
up
with
naming
collisions.
That's
you
know
intentional
or
otherwise
you
end
up
with
device
impersonation
and
that's
what
drives
people
toward
consolidation
and
yeah.
So
let's
go
to
the
to
the
next
slide.
F
So,
let's,
let's
look
at
a
visual
of
what
we
think
is
a
sub-optimal
information
flow
on
a
lan.
We
might
have
a
sensor
and
an
actuator,
and
the
sensor
is
producing
information
that
the
actuator
acts
upon,
and
you
know
very
often
times
we
see
patterns
like
this,
where
it's
a
platform-based
interaction.
The
sensor
will
send
telemetry
up
to
the
platform
the
platform
will
reach
out
to
the
forum
and
then
get
the
information
down
to
the
actuator.
This
is
next
slide.
Please.
F
This
is
a
pattern.
We
call
tromboning
and
this
is
sub-optimal.
You
know
you're
you're
spending
what
is
usually
more
expensive
bandwidth
to
do
something
that
you
should
be
doing
on
the
local
network
next
slide,
and
this
is
what
we
really
want:
there's
nothing
wrong
with
the
device
reaching
up
to
its
owning
platform.
You
know
for
things
like
telemetry
and
configuration
management,
but
we
would
like
for
information
to
flow
from
the
sensor
to
the
actuator.
F
You
know
on
the
local
network.
This
is
where
we
end
up
with.
You
know
the
challenges
of
getting
pki
around
so
that
you
can
establish
trust
safely
between
those
devices
and
the
reason
this
doesn't
happen.
More
is
because
of
the
challenges
with
dealing
with
private
pki
next
slide.
F
F
For
you
know,
even
if
you
have
ca
certificates
shipped
around,
you
know
which
are
fine
for
establishing
trust
between
entities
right,
so
the
device
on
the
left
can
establish
a
tls
session
with
the
middleware
in
the
middle,
and
each
of
them
is
as
confident
of
the
identity
on
the
other
side
of
the
connection,
but
the
system
on
the
right
has
no
way
of
establishing
a
direct
tls
session
with
the
device
on
the
left,
and
so,
while
it's
completely
confident
of
the
identity
of
the
middleware,
it
just
has
to
trust
that
the
middleware
is
honestly
representing
the
the
identity
of
the
sender
and
so
next
slide.
F
F
If
we
want
to
get
to
a
state
where
we
can
authenticate
the
message,
then
the
message
needs
to
bear
a
signature
as
well
as
the
some
indicator
of
the
identity
of
the
sender
and
then
on
the
recipient
side.
The
the
application
processing.
The
message
needs
to
be
able
to
retrieve
the
ca
certificate.
This
is
where
we
usually
see
a
proprietary
api,
a
ca's
api
coming
into
play,
so
you
have
to
tie
your
application.
F
You
have
to
have
a
certificate
discovery
process
in
place
whereby
you
can
go
to
the
ca.
You
can
grab
the
certificate.
That's
used
to
authenticate
the
message,
so
there
is
some
compute
overhead
that
comes
along
with
this
on
the
service
side,
and
then
you
also
have
some
complexity
overhead
as
well,
because
now
you
have
to
have
a
system,
that's
going
to
manage
those
entity
certificates,
not
just
the
ca
certificates,
but
a
certificate
for
every
single
sending
entity,
and
this
becomes
even
more
complex.
F
When
you
have
multiple
certificate
authorities
in
play,
then
you
have
another
api
to
tie
off
to
that.
You
use
to
retrieve
your
certificates
and
it's
and
it
gets
even
more
and
more
complex
from
there
trying
to
assign
identity
to
the
sender.
F
In
some
cases
you
the
certificate
being
sent
inside
the
payload,
but
that
play
for
iot
represents
some
can
represent
some
significant
overhead
for
the
you
know,
for
the
protocol
itself
and
iot
is
very
often
times
constrained,
and
so
you
end
up
doing
some
really
interesting
acrobatics
trying
to
keep
your
message
payload
size,
small,
especially
when
you're
you
know,
including
a
public
key
or
certificate
in
that
next
slide,
please
so
looking
at
what's
already
out
there
in
the
ecosystem,
you
know
what
we're
really
looking
for
is.
F
Do
we
have
open
standards
that
already
exist
that
we
can
repurpose?
You
know
with
sort
of
favoring.
You
know
what
would
represent
a
very
easy
integration
path,
we'd
love
for
existing
pki
to
just
work
better,
and
you
know-
and
maybe
something
with
a
gentle
adoption
curve
where
you
don't
just
have
to
flip
a
switch,
and
you
know,
jump
up
a
cliff
face
to
to
get
to
a
better
state
next
slide.
Please.
F
We
might
look
at
you
know
how
accessible
it
is,
which
is
an
aspect
of
the
entire
system
right,
and
this
is
from
an
integration
standpoint.
How
widely
recognized
is
it
might
be.
An
aspect
of
federation
also
has
to
do
with
the
name
component.
So
within
an
identity,
you
have
three
general
properties
right.
You
have
a
name
and
a
method
of
proving
possession
of
the
name,
and
then
you
have
metadata
attached
to
it.
This
conversation
will
center
primarily
around
name
and
proof
of
possession.
F
You
know
how
resistant
is
the
name
to
naming
collision
and
with
you
know,
bki.
This
is
the
challenge
we
talk
about
when
moving
between
private
pki,
the.
How
resistant
is
it
to
credential
theft?
Compare
a
password
to
to
a
private
key
private
key.
You
can
protect
with
hardware
a
password,
you
know
as
a
text-based
credential,
that's
a
little
more
challenging
to
protect
from
a
physical
aspect
and
then
the
level
of
effort
for
credential
rotation.
That's
an
aspect
of
hygiene.
F
You
know
we
have
standards,
we
can
look
to
for
guidance
on
that,
but
it's
still
a
pretty
big
challenge
with
a
lot
of
systems.
Next
slide,
please,
when
we
look
at
traditional
pki
accessibility
is
sort
of
challenging
we're
oftentimes
dealing
with
a
proprietary
api
with
the
certificate
authority.
F
How
widely
recognized
is
it-
and
you
know
well,
which
pki
are
we
talking
about?
The
the
resistance
to
naming
collisions,
is
guaranteed
only
within
the
same
certificate
authority,
but
you
can
get
hardware
support
for
protecting
the
private
key
and
the
level
of
credential
rotation
can
be
high,
because
this
is
a
the
challenge
with
these
is
the
distribution
of
key
material.
F
Blockchain
and
public
key
is
a
step
in
the
right
direction.
We
have
standards
emerging
to
make
this
more
accessible
from
an
api
standpoint.
W3C
is
very
involved
in
that.
How
widely
recognized
is
it
well,
which
blockchain
are
we
going
for?
F
You
know
how
resistant
as
its
naming
collisions
pretty
resistant
within
the
same
blockchain
or
distributed
ledger
resistance
could
to
credential
theft
carries
over
from
pki
and
it
can
be
hardware
supported.
A
level
of
effort
for
credential
rotation
can
also
still
be
high
here.
F
Next
slide.
Please
using
dns
and
pki
is
not
a
new
idea.
We
do
that
in
email,
and
we
have
other
standards
to
support
this.
F
So
using
dns
as
the
api
for
pki
discovery
actually
works
pretty
well.
This
is
something
that's
already
in
the
operating
system
and
and
how
widely
recognized
is
it
I
mean
there's
only
one
dns.
You
know
if
you
say
that
you
have
your
identity
in
dns,
nobody
asks
which
dns
it's
the
dns.
F
F
You
know
hardware
to
protect
your
private
key
and
level
of
effort
for
credential
rotation
is
substantially
lower,
and
the
reason
for
this
is
because,
once
a
public
key
is
published
in
dns,
then
it's
accessible
via
discovery,
and
it's
not
something
you
don't
have
to
distribute
it's.
It's
not
a
distribution
model
where
you
have
to
copy
these
things
out
to
the
the
parties
that
need
them.
It
becomes
a
discovery,
operation
and
everybody's
agreeing
on
the
name
space.
It
makes
it
a
lot
easier
to
discover
new
certificates
when
they're
published.
A
Yeah,
let
me
interrupt
for
one
second,
please,
which
is.
We
did
say
that
we
would
take
any
clarifying
q
a's.
Does
anybody
have
questions
for
ash
before
we
go
on
to
the
laurent
or
one
case?
B
Okay,
thank
you.
So
it's
actually
lauravan,
not
lauren.
Lauravan
is
long-range
wide
area
network.
So
yeah,
sorry
about
that.
B
That's
the
objective
for
the
presentation
here
is
to
demonstrate
a
real
use
case
in
iot
for
dns
plus
pke.
So
that's
where
we
have
obtained
next
slide
piece.
So
this
is
the
basic
architecture
of
lorawan.
Where
you
have
a
end
device.
It
is
end
device
and
it
is
connected
to
laura
fee.
That
is
a
proprietary
protocol,
radio
frequency
to
a
radio
gateway
which
talks
both
laura
fee
as
well
as
ip.
B
So
it
receives
information
from
the
end
device
and
then
it
transfers
it
to
ip
and
sends
it
to
the
back-end
information
servers
which
we
call
grouped
together
as
back-end
network
elements
and
the
connection
between
the
radio
gateway
and
the
back-end
network
elements
are
normal
ip.
It
could
be
3g
ethernet
anything
normal
as
in
the
internet.
B
B
Lorawan
is
one
of
the
major
technologies
under
the
lp
1
category,
and
there
are
a
lot
of
use
cases
for
lorawan
because
it
is
like
the
internet
where
you
have
the
ecosystem.
It
is
quite
free,
except
the
laura
fee
technology.
B
Anybody
can
be
part
of
the
lorawan
network,
even
the
networks.
There
are
different
types
of
networks
like
private,
public
and
community-based
networks.
So
that's
where
it
is
interesting
for
from
the
iatf
perspective,
so
coming
back
in
lorawan
as
per
the
specifications,
dns
infrastructure
is
used
in
two
cases.
One
is
for
we
call
it
ota
over
there
activation
in
the
ietf
technology.
It
is
device
onboarding
or
bootstrapping
and
for
another
use
case
that
is,
for
roaming.
B
So
these
are
the
two
use
cases
where
dns
infrastructure
is
used
as
per
the
specifications,
but
in
normal
use
there
is
no
use.
So
as
when
I
say
nobody
is
using
it.
It's
just
in
the
specification
and
the
use
cases
currently
in
lorawan
are
using
a
a
telecom
infrastructure
like
the
hub,
where
everybody
has
to
come
and
register
to
the
hub
to
have
either
over
there
activation
device
on
boarding
when
you
are
in
a
foreign
network
as
well
as
for
roaming
next
slide,
please.
B
So
this
is
the
dns
hierarchy
in
the
laura
alliance,
the
alliance
of
industries
and
the
institutions
which
developed
the
lorawan
specifications.
B
We
have
two
zones,
one
is
netids.lorawan.net
and
another
is
join
uis.lorovan.net,
so
join
uis
is
focus
on
the
over
there
activation,
that
is
device
onboarding
and
net
ids
focus
on
roaming
category.
So
next
slide
please.
B
So
if
you
could
see,
in
the
left
hand,
the
join
ui
is
a
ieee
64
identifier,
which
is
converted
to
a
domain
name
as
you
could
see,
and
it
is
being
a
connected
to
a
server
and
similarly,
the
net
ids
is
a
net
id
where
the
laura
alliance
owns
that
registry.
So
if
you
want
to
get
a
net
id
for
roaming
case,
you
have
to
go
to
the
laura
alliance
to
get
this
identifier,
so
that
is
used.
B
B
So
this
is
how
the
ota
that
is
over
there
activation
flow
is
done.
The
important
part
that
we
have
here
is
between
the
ns
and
the
dns
and
the
js.
So
when
a
device
is
roaming
or
when
a
device
comes
first
to
a
network,
the
network
server
needs
to
know
the
joint
server
the
joint
server
in
idf
technology.
It
is
aaa
server,
so
it
needs
to
know
the
join
server
to
create
the
credentials
for
a
secure
connection,
so
to
identify
the
join
server
in
the
request
that
is
coming
from
the
end
device.
B
B
So
in
the
roaming
use
case,
I'm
not
go
completely
because
of
time
constraints.
Similarly,
if
the
device
is
roaming
outside
your
network,
so
it
is
called
the
foreign
network
server.
It
has
to
identify
using
the
dns
and
in
the
incoming
packet.
You
have
the
net
id
use
the
net
id
and
resolve
to
the
dns
zone
of
the
net
id
to
identify
the
home
network
server
for
the
device,
so
that
is
where
dns
is
used
in
lower
case
next
slide.
Please.
B
So
the
idea
is
to
just
give
a
brief
introduction
where
dns
is
used
in
the
case
of
provisioning
and
resolution.
Now
we
will
see
what
is
the
issue,
for
example,
if
you
see
between
the
end
device
and
the
joint
server
for
ota,
let's
take
the
ota
case.
B
B
Similarly,
in
between
the
end
device
and
the
application
server,
there
is
a
root
key
called
app
key,
which
has
to
be
pre-shared.
So
this
is
an
issue
because,
as
as
I
said
in
the
beginning,
if
the
ecosystem
is
like
the
internet,
anybody
can
have
a
network.
Anybody
can
be
the
network
server.
Anybody
can
be
the
aaa
server.
The
issue
of
sharing
the
keys
before
establishing
a
connection
is
a
problem,
so
unless
and
otherwise,
there's
a
proprietary
network,
the
sharing
becomes
difficult.
B
B
So
that
is
the
communication
between
the
end
device
and
the
backend
network
elements.
Now
what
we
see
is
that
the
communication
between
the
backend
network
elements
the
communication
between
the
backend
network
elements,
so
once
the
resolution
is
done
once
you
know
that,
for
example,
in
ota,
which
is
the
join
server
by
the
network
server,
then
it
has
to
communicate
between
the
network
server
and
join
server
using
mutual
authentication.
B
So
currently,
as
per
the
laura
lauravant
specifications,
backend
specifications,
it
is
not
normative,
so
the
implementer
could
do
as
they
want.
So
that's
where
I
think
we
could.
It
would
be
useful
if
we
could
have,
since
the
resolution
is
done
by
dns,
and
we
could
add
the
pke
path
where
we
have,
for
example,
dnsx
plus
dain.
B
The
issue
of
what
I
say
is
that
you
don't
need
a
certificate
authority
here.
You
can
use
a
self-signed
certificate
and
the
client
and
the
server
authentication
which
is
being
developed
in
the
day
in
drafts
could
be
useful
next
slide,
please.
B
So
here
I
have
a
resume
of
some
other
some
other
standards
which
are
using
iot
use
case,
which
are
also
using
dns.
For
example.
Here,
epc
is
electronic
product
code,
which
is
used
in
the
supply
chain.
Industry
and
the
standardization
organization
is
js1.
They
use
a
a
standard,
called
ons
object,
naming
service
which
is
based
on
dns.
So
if
we
see
in
the
iotn,
if
we
want
to
have
a
global
structure
for
the
resolution,
part
dns
is
needed,
but
what
happens
is
that
there
are
standards,
but
there
is
no
implementation.
B
B
So
from
from
my
perspective
from
the
lower
man
perspective,
what
I
think
is
that
the
mutual
authentication
between
the
backend
network
elements
is
the
first
step
to
solve,
because
we
could
use
it
directly
with
the
existing
dns
plus
pke
infrastructure,
but
the
other
case
where
we
have
to
have
end
to
end
between
the
end
device,
which
is
communicating
via
the
law
of
fee,
the
radio
frequency
and
the
ip
part
is
going
to
be
difficult
because
there
are
constraints.
B
Now
is
a
smaller.
I
think
a
minimum
packet
size
for
laura
is
like
52
bytes,
so
having
a
pke
certificate
or
a
key
into
these
52
bytes
is
going
to
be
difficult.
So
I
know
that
in
iedf
there
are
other
working
groups
working
on
to
compress
the
the
cryptographic
key
so
that
it
could
be
used
in
the
iot
constrainedness.
B
A
Great
awesome,
so
I
know
you
have
to
go
to
a
conflicting
meeting.
Is
there
anybody
with
questions
about
that
again?
That
was,
that
was
a
goal
of
discussing
a
possible
future
item
that
was
not
in
the
original
list
of
things
that
we
might
put
on
a
charter.
Of
course
that's
up
to
the
community
side,
but
any
questions.
A
H
So
I'll
give
a
summary
of
what
we
expect
to
be
the
initial
areas
of
work,
or
at
least
the
protocol
mechanisms
that
we
see
are
the
building
blocks
for
this
work.
If
there
is
a
successful
outcome
of
this
buff,
so
we
were
advised
by
the
chairs
not
to
assume
that
everyone
in
attendance
is
necessarily
conversant
with
dane.
H
So
let
me
start
with
some
very
quick
background,
but
any
of
this-
if
any
of
this
is
too
basic,
please
yell
at
me,
chairs
and
I'll-
go
faster,
so
dane
stands
for
dns
based
authentication
of
named
entities
and
is
defined
in
rfc,
6698
and
7671,
and
it's
a
protocol
that
uses
signed,
dns
records.
H
H
Okay,
all
right,
so
I
will
continue
so
it's
a
protocol
that
uses
signed,
dns
records
or
dns
sec
to
authenticate
x-509
certificates
and
public
keys.
So
today,
dain
is
used
primarily
to
authenticate
tls
servers.
H
There
are
some
additional
specifications
listed
here
that
define
how
it's
employed
for
specific
applications
like
smtp
transport
security
and
for
applications
that
employ
dns
srv
records
next
slide.
Please
so.
Here's
an
example
of
a
real,
dane
record
in
the
wild,
and
this
is
the
proton
mail
service
that
has
published
a
dane
record
that
allows
you
to
authenticate
the
server
certificate
for
the
mail
exchanger
for
that
domain.
The
mx
server
and
the
dane
record
type
itself
is
called
tls8.
That's
highlighted
in
red
and
below
the
record
itself
is
the
dns
signature.
H
H
So
all
the
way,
sorry
one
I
think
you
may
have
skipped
one
slide:
can
you
go
back
right
yeah?
So
all
the
way
at
the
end
is
the
data
associated
with
the
certificate
or
or
public
key
for
this
service,
and
the
precise
nature
of
that
data
is
defined
by
the
three
numbers
that
precede
it
next
slide.
H
H
The
second
number
is
the
selector
parameter,
and
this
tells
you
whether
the
data
corresponds
to
the
entire
certificate
or
only
the
public
key,
and
the
third
number
is
a
matching
type,
and
that
tells
you
if
the
data
is
the
full
certificate
or
the
full
public
key
or
whether
it's
a
cryptographic,
hash
of
it,
and
there
are
two
possible
hashes
defined
sha,
256
and
sha
512
next
slide,
so
putting
this
example
together.
What
this
record
is
saying
is
that
this
is
a
dane
ee
certificate.
H
H
So
I
want
to
switch
over
to
the
part
of
dane
that
is
most
relevant
to
our
topic
today
and
that
is
using
dane
for
authenticating
clients.
Also,
two
itf
drafts
we've
developed
address
this
topic.
The
first
one
specifies
how
to
do
dane
client
authentication
in
tls,
and
the
second
one
defines
a
new
tls
extension
to
convey
a
client's,
dane
identity.
Basically,
the
the
dns
name
that
identifies
the
client.
H
H
So
a
point
I
want
to
make
is
that,
although
this
buff
is
iot
focus,
we
would
like
to
ensure
that
whatever
we
do
with
these
drafts
to
make
the
iot
case
work
well,
we
still
want
them
to
be
general
purpose
enough
for
adoption
by
other
applications.
That
may
want
to
consider
dane
for
client
authentication
next
next
slide.
Please
so
I'll
give
you
a
quick
protocol
sketch.
H
Basically,
the
tls
client
is
expected
to
have
a
an
identity
in
the
form
of
a
dns
domain
name
and
a
public
private
key
pair
and
a
certificate
binding
the
public
key
to
the
domain
name,
and
there
is
a
corresponding,
dane
tlsa
record,
published
in
the
dns
on
the
tls
server
side.
What
happens
is
the
server
sends
a
certificate
request,
request
message
in
the
tls
handshake,
the
client
sends
its
certificate
message
and
a
new
extension.
The
dane
client
id
extension
which
I
will
get
to
in
the
next
slide,
so
bear
with
me
a
little
bit.
H
So
there
is
also
a
proposed
new
tls
extension
for
conveying
a
client's,
dane
identity.
Now,
generally
speaking,
the
tls
server
could
find
the
client
name
in
the
client
certificate
itself.
So
you
might
be
asking
why
we
would
need
this
well.
It
has
a
couple
of
purposes
so
first
to
act
as
a
signal
for
support
of
this
protocol,
which
can
be
done
simply
by
sending
an
empty
extension.
H
Both
the
server
and
client
can
signal
the
support,
but
it
is
particularly
useful
for
the
client
to
do
so
because
that
communicates
to
the
server
that
it
actually
has
a
dane
record
that
it
wishes
to
be
authenticated
with
and
in
environments
that
may
support
a
mixture
of
clients.
We
can
ensure
that
the
tls
server
attempts
to
perform
dane
authentication
only
for
clients
that
are
suitably
configured
to
make
that
possible
and
the
second
reason
is
to
convey
the
actual
client's
dns
identity
in
cases
where
it
might
be
required.
H
H
So
in
that
case
there
is
no
certificate
at
all
from
which
the
client
identity
can
be
extracted.
So
you
need
some
other
mechanism
to
convey
this
identity,
and
this
tls
extension
can
be
used
to
accomplish
that.
So
you
know
one
question
I
actually
have
to
the
iot
system.
More
generally
is:
is
7250
actually
used
anywhere
in
this
ecosystem.
H
To
me,
it's
always
seemed
like
a
natural
fit
for
constrained
devices,
but
I
I
don't
actually
have
any
confirmed
knowledge
that
it
is
being
used
anywhere,
but
our
kind
of
the
draft
makes
sure
that
we
cover
that
use
case
if
necessary.
H
So
another
case
where
this
extension
is
useful
is
if
the
client
certificate
has
multiple
identities,
and
we
want
to
tell
me
you
know:
maybe
not
all
of
them
have
an
associated
dane
record
and
we
want
to
specifically
tell
the
server
which
specific
identity
has
the
dane
record
associated
with
it
to
minimize
the
amount
of
work
the
server
has
to
do
to
perform
successful
authentication.
Otherwise
you
know
it
might
try
all
of
them
many
potentially
unnecessarily
so
I
want
to
did
I
mention
this
in
this
slide.
Oh.
H
Privacy
question:
I
also
want
to
make
a
quick
note
about
the
privacy
implications
of
this
extension
if
it
is
being
used
to
send
the
actual
client
identity
in
as
currently
specified
in
tls
version
1.3.
This
extension
is
intended
to
be
carried
in
the
certificate
request
and
certificate
messages,
both
of
which
are
encrypted,
so
there
is
no
privacy
leakage.
H
However,
you
know
I'm
assuming
we'll
have
to
support
a
kind
of
deployed
field
of
tls
1.2
as
well,
so
the
tls
1.2
version
of
the
specification.
The
client
has
to
send
this
in
their
first
flight
client,
hello
extension.
H
So
this
cannot
be
protected
today
without
further
enhancements
to
that
version
of
the
protocol,
and
you
know
you
might
be
wondering
about
ech
but
as
far
as
I've
been
told
that
is
not
being
defined
for
1.2
so,
depending
on
the
application,
this
privacy
leakage
may
or
may
not
matter
to
you,
but
we
advise
using
tls
1.3
if
possible.
H
All
right,
so,
let's
talk
about
the
client
dns
naming
formats,
so
the
tls
record
format
here,
the
r
data
format
to
use
dns
protocol
terminology
for
client
authentication
is
exactly
the
same
as
specified
in
rfc
6698
no
changes
there.
The
only
thing
that's
different
is
the
format
of
the
owner
name,
the
record
name
format,
and
that
has
to
be
adapted
to
something
more
suitable
to
client
names.
H
H
So
the
first
format
is
the
the
one
with
that
we
called
service,
specific
identity
and
it
allows
for
the
same
client
to
have
different
credentials
for
different
services,
and
it
does
that
by
encoding
the
application
of
the
service
name
into
the
first
label
of
the
domain
name.
It
also
accommodates
wildcards.
If
the
client
uses
a
say
a
common
credential
across
many
or
all
applications
next
slide,
please.
H
So
the
second
format
is
what
we're
calling
iot
device
identity
and
it
proposes
organizing
iot
device
names
under
a
common
suffix,
using
what
we're
calling
an
identity
grouping
label.
So
that's
the
underscore
device
label
that
you
can
see
in
the
middle
of
the
domain
name
here
and
this
scheme
permits
an
organization
if
they
wanted
to
to
delegate
the
management
of
the
entire
client
device
tree
to
a
you
know.
H
A
to
a
third
party
to
the
left
of
the
underscore
device
is
the
device
name
which
could
be
composed
of
a
number
of
labels
and
to
the
right
is
the
organizational
name
which
may
include
other
labels
within
the
organization,
not
just
the
top
level
zone
of
that
organization.
B
H
Up
of
what
an
iot
client
dane
record
might
look
like,
so
I'm
going
to
skip
over
that
because
I
don't
think
I've
explained
all
the
details
already
next
slide.
Please
and
here's
a
general
diagram
of
the
protocol
flow,
which
I
think
I
already
described
verbally
in
in
one
of
the
previous
slides.
But
basically
it
involves
just
some
relatively
minor
enhancements
to
the
typical
tls
client
certificate
authentication
flow.
H
So
I've
pointed
out
the
main
deltas
here
in
red,
and
that
is
that
the
dane
client
signals
support
of
this
extension
or
perhaps
relays
its
actual
identity
in
this
new
tls
client
extension
and
the
tls
server
needs
to
perform
a
lookup
of
the
client
stain
tlsa
record
and
validate
the
client's
certificate
and
or
public
key
against
the
contents
of
the
record
and
next
slide.
Please.
H
And
just
to
dig
into
a
little
bit
more
detail,
I
just
grabbed
the
tls
1.3
handshake
message,
diagram
from
from
the
rfc
and
I've
annotated
here
with
the
new
protocol
elements
in
bold,
so
on
the
tls
server
side.
The
server
optionally
signals
support
for
this
extension
in
the
certificate
request
message.
H
The
client
signals
support
for
this
extension
alongside
the
certificate
message
that
it
sends
back
and
finally,
the
tls
server
has
to
perform
dain
authentication.
H
And
I
think
that
covers
this
slide.
Let's
move
on
to
the
next
slide,
please,
okay!
So,
as
you
all
know,
dain
authentication
is
dependent
on
dns
sex
so
that
you
can
securely
authenticate
the
contents
of
the
dane
records,
and
that
is
the
end
game
we
hope
to
achieve.
H
However,
dnsec
is
not
yet
universally
deployed
and
we'd
nonetheless
like
to
be
able
to
use
dane
or
dane-like
mechanisms
even
before
dnsec
is
fully
present
in
the
relevant
pieces
of
the
dns
infrastructure
that
houses
the
client's
domain
name.
So
we
actually
have
an
interim
proposal
to
achieve
that
goal,
and
that
involves
the
specification
of
an
additional
tlsa
usage
mode
that
allows
the
certificate
data
to
be
authenticated
solely
with
pkx
and.
H
I
Okay,
great,
so
the
question
I
have
is
the
the
dns
records
that
we're
proposing
here
for
iot
devices.
I
understand
that
they're
going
to
contain
the
the
dane
records,
but
what
other
information
would
be
in
that?
Does
it
go
as
far
as
the
ip
address
of
said
device.
H
It
does
not,
so
it
is
only
the
domain
name
of
the
iot
device.
Is
there
a
specific
need?
You
are
envisioning
for.
I
Specific
anti-pattern
advertising
that
much
information
about
the
even
all
those
device
ids
under
a
given
organization
is
already
an
attacker's
dream
for
profiling.
A
target
and-
and
I
was
just
worried
that
you
were
also
including
a
specific
ability
to
connect
to
said
devices.
H
All
right,
no,
so
it
includes
no
information
about
the
network
layer,
identity
of
the
client.
If
that's
what
you're
asking
so,
they
won't
be
able
to
obtain
that
information
from
the
dns
record.
H
Interim
proposal
to
achieve
this
goal
of
using
you
know,
daneline
mechanisms
even
before
dnsec
is
completely
deployed,
and
that
involves
the
specification
of
an
additional
tlsa
usage
mode
that
allows
that
to
happen
and
there's
a
secondary
goal
of
expanding
the
scope
of
dane
for
iot
work
to
nodding,
not
only
include
sort
of
channel
security
mechanisms,
but
object
security.
More
generally.
So
there's
a
new
draft.
That's
recently
been
written
to
cover
this,
which
we'll
also
talk
about
today.
It's
very
new
and
certainly
needs
input
and
discussion,
but
I
think
I'm
gonna.
H
J
So
the
earlier
question
inspired
me
to
to
make
one
just
comment
in
terms
of
privacy,
and
you
know,
devices
being
either
visible
or
not
visible.
One
of
the
things
that
you
can
do
with
dane
is,
of
course,
issue
certificates
privately
without
going
through
any
public
ca,
and
what
that
helps
you
with
is
that
then
you're
outside
the
scope
of
certificate
transparency
logs,
which
today
disclose
the
identities
of
everybody
who
has
a
certificate
essentially
right,
you
can
download
the
entire
log
and
learn
about
every
server
on
the
internet.
J
If
a
client
is
using
dane,
then
the
certificate
is
not
logged.
It's
generated
privately.
The
tlsa
record
has
the
certificate
fingerprint,
but
even
the
tsa
record
may
be
hard
to
find
unless
you
know
its
name
a
priori,
you
don't
know
which
dns
name
to
query
so
there's
actually
an
advantage
here
that
just
occurred
to
me.
H
H
A
Yeah,
that's
a
good
point:
let's,
let's
do
hold
the
sort
of
technical
back
and
forth
discussions
until
after
the
presentation
and
and
schumann
and
ash.
Both
do
note
that
we
are
running
over
schedule
a
little
bit.
We
have
plenty
of
time
in
the
agenda
but
to
make
sure
that
we
get
the
q
a
let's
do
speed
forward.
F
This
is
a
little
bit
different
use
case
for
certificate
discovery,
and
so
this
is
using
dane
records
exactly
as
they're
formatted
now
adding
usage
type
four
and-
and
so
this
is
to
address
two
sort
of
gaps
right.
So
this
is
for
entity
certificate
discovery
like
we
discussed
earlier,
with
the
store
and
forward
use
case
and
the
challenge
of
integrating
with
private
or
proprietary
apis
that
are
on
a
ca
by
ca
basis.
F
F
So
we're
proposing
certificate
usage
mode,
4
and
calling
it
p
kicks
cd,
and
this
is
where
the
entity
certificate.
We
authenticate
the
entity
certificate
using
a
ca
certificate
which
is
securely
discovered.
The
ca
certificate
can
be,
you
know,
probably
should
be
private,
pki
right
and
so
limited
or
scoped
to
the
zone
that
it's
that
it's
protecting,
but
the
discovery
of
that
private
pki
is
protected
by
web
pki.
F
F
F
You
know
that's
stored
in
the
dns
record,
the
the
device
identifier,
I
think
we've
already
covered
this
earlier,
but
the
device
identifier
in
this
case
is
abc
identity.
Grouping
label
is
underscore
device
and
then
vendor.example
is
the
domain
name
we're
working
with
further
breaking
it
down.
Let's
get
to
the
next
slide,
please.
F
F
So
we
take
the
identity
type
which
is
device
we.
Basically
we
we
take
off
the
the
preceding
underscore
from
the
identity
grouping
label.
We
plug
that
into
the
url.
We
take
the
organizational
domain
which
in
this
case
is
vendor.example,
and
then
we
construct
a
well-known
path
after
that,
using
the
authority
key
id
from
the
discovered
entity
certificate
and
so
using
this
and
requiring
that
that
https
connection
be
protected
by
web
pki.
F
You
can,
of
course,
apply
further
constraints
on
that
as
to
type
a
certificate
if
you
really
want,
but
we
get
a
a
secure
delivery
method
and
a
well-known
uri
whereby
you
can
discover
the
certificate.
That's
used
to
sign
the
or
that's
used
to
verify
the
entity
certificate
that
you're
retrieving
using
traditional
dns.
F
F
F
Web
pki
does
not
permit
the
use
of
underscores
in
host
names,
so
this
actually
gives
us
a
way
of
placing
the
the
ca
certificate
discovery
mechanism,
which
is
essentially
this
is
like
content,
addressable
storage,
but
that
web
server
that's
providing
us
this
content,
addressable
storage
based
on
the
hash
of
the
public
key,
is
in
a
separate
zone
apart
from
the
device
certificates,
and
so
that
gives
us
you
know
you
can
have
different
access
controls
placed
on
those
too.
F
We
compartmentalize
failure
zones
so
that
if
you
want
to
compromise
the
system
and
start
presenting,
you
know
false
device
identities,
then
you
have
to
compromise
both
zones
or
at
least
the
web
server
and
start
injecting
bad
ca
certificates.
So
it's
a
it's
intended
to
provide
a
you
know
the
the
path
to
compromise.
This
is
intended
to
be.
You
know
intentionally
difficult
to
compromise.
F
The
caveats
with
this:
this
is
a
little
bit
more
complex
than
using
traditional
dane.
So
you
have
to
assure
that
there
is
a
name
alignment
between
the
dns
query
and
the
contents
of
the
certificate
right
and
that's
to
mitigate
same
domain
impersonation
so
that
you
don't
have
you
know
so
that
you're
not
having
issues
with
device
impersonation
within
the
same
domain,
cross-domain
impersonation.
F
In
order
to
prevent
that
you
have
to
ensure
that
the
entity
name
is
following
through
with
pki
presented
under
that
domain.
If
you
don't
have
a
way
of
anchoring
on
the
on
the
authenticating
side,
you
know
the
relationship
between
the
entity
certificate
and
the
and
the
ca
certificate
that
signed
it
from
the
correct
domain.
F
Then
you
can
have
cross-domain
impersonation
and
then,
of
course,
you
have
to
ensure
the
uniqueness
of
the
the
distinguished
name
and
the
ca
certificates,
because
sometimes
you
know
in
the
absence
of
an
aki-
and
this
was
in
some
testing
that
I
did
with
with
radius.
It
can
get
a
little
bit
confusing
depending
on
the
implementation.
F
So
there
are
still
a
lot
of
you
know.
Like
truman
mentioned,
this
is
a
really
new
draft
and
there's
still
a
lot
of
tons
of
unanswered
questions,
and
you
know
a
couple
of
them
are,
you
know,
is:
is
the
dns
name?
F
You
know
field
in
the
certificate
really
the
best
place
for
for
establishing
name
alignment?
You
know
where
you
know,
there's
a
movement
or
at
least
an
initiative
to
sort
of
deprecate
the
the
common
name
right
so
is
dns
name
the
best
place.
To
put
that,
should
we
use
other
name
and
the
reason
this
is
kind
of
coming
up.
You
know
we
should
address
this
early
is
because
you
know,
there's
a
there's,
a
push
with
you
know
web
pki
to
eliminate
underscores
in
the
dns
name
right.
F
But
what
are
the
implications
for
you
know
having
underscore
names
within
you
know
the
dns
name
field
and
then,
of
course,
you
know,
should
we
be
using
name
constraints
within
ca
certificates
and
make
that
requirement
the
discovery
process
sort
of
as
insurance
with
that
you
know
that
pkix,
you
know
if
you're
discovering
you
know
the
trust
chain,
you
know,
then
you
can
make
that
an
additional
validation
step
to
make
sure
that
you're
discovering
a
a
ca
certificate,
that's
bound
to
a
very
specific
zone
in
dns.
F
So
the
object
security
use
case
you
know-
has
the
senders
certificate
discoverable
in
dns.
You
know
the
message
would
contain
the
sender's
dns
name
and
then
the
message
is
protected
by
a
signature
generated
using
the
sender's
private
key
and
then
the
recipient
can
use
a
cinder's
dns
name
to
then
discover
the
certificate
which
contains
a
public
key
that
can
be
used
to
authenticate
the
message
and
then
the
you
know.
F
So
for
a
visualization
of
this
right,
so
we
have
messages
flowing
from
the
left
to
the
right
through
you
know
at
least
one
middleware
layer
on
the
way
to
a
service
side.
That
is
that's
processing.
This
next
slide.
F
So
the
the
recipient
extracts
the
name
of
the
of
the
sending
entity
from
the
message
right,
so
123.
underscore
device.vendor.example
and
it
uses
that
to
retrieve
the
the
certificate
from
dns
next
slide.
F
It
extracts
the
authority
key
id
from
the
entity
certificate
that
it
just
discovered.
It
uses
that
authority
key
id
then
to
build
the
the
far
right
portion
of
the
url
next
slide.
Please,
which
looks
like
this
so
using
the
device,
the
identity
type
and
the
domain
name.
We
can
then
construct
with
the
authority
key
id
a
url
where
we
should
find
exactly
one
pin
file
with
a
you
know,
containing
the
ca
certificate
that
was
used
that
can
be
used
to
validate
the
the
entity
certificate.
F
Slide
so
in
the
process
of
validating
entity
certificates,
we
have
also
discovered
a
traditional
pki
trust
chain.
Building
on
this,
we
can
use
that
trust
that
trust
anchor
to
facilitate
traditional
tls
between
entities,
mutual
authentication.
F
And
so
what
this
kind
of
feeds
into
is
a
is
a
network
access
use
case
and
for
this
let's,
let's
kick
to
the
next
slide,
please.
F
So
if
we
look
at
how
this
plays
out
say
with
with
eaptls
and
radius
next
slide,
please
using
dane
with
p
kick
cd
right.
So
this
is.
This
is
dane
without
the
benefit
of
dns
sec
and
then
here
in
just
a
moment,
I'll
show
how
that
changes
for
dean
for
true,
dane
and
dnsec
for
mutual
tls,
but
first
starting
with
dane
without
dns
sec.
F
F
The
challenges
for
this
that
we're
seeking
to
mitigate
are,
you
know,
on-boarding
devices
and
issuing
them
organizational
pki
identities
right,
that's
a
manual
process
and
avoiding
the
hands-on
stuff
sure
would
be
nice.
Authorization
gets
complicated
when
you
have
multiple
pki
naming
conventions.
That's
why
we
oftentimes
consolidate
to
organizational
pki,
and
then
we
want
to
prevent
impersonation
across
routes
of
trust
and
using
pick
xcd
and
etls
allows
radius
to
perform
authorization
beyond
peak's
authentication.
There
becomes
an
authorization
step
of
making
sure
that
it's
mapped
to
the
right
trust
chain.
F
And
sort
of
looking
at
the
way
it
roles
and
responsibilities,
the
supplier's
responsibility.
The
hardware
supplier
is
to
publish
a
tlsa
record
for
the
device
that
contains
a
certificate
with
the
authority
key
id
in
it,
and
then
they
have
to
publish
the
you
know,
maintain
the
authority
server,
which
contains
the
ca
certificates
right.
F
F
There's
an
automation
portion
that
happens
on
the
radius
side
to
periodically
update
the
mapping
of
the
dane
identity
to
the
authority
key
id,
but
given
that
those
certificates
will
will
not
frequently
rotate,
this
still
becomes
sort
of
a
discovery
process
right
where
you
you
periodically,
go
out
and
just
check
to
make
sure
that
the
certificate
hasn't
been
updated
and
then
a
picture
mapping
locally.
F
If
it
has
and
then
a
periodic
out-of-band
ca
certificate
synced
to
to
enable
the
use
of
of
a
traditional
tls
mutual
authentication
for
etls
radius,
then
you
know
performs
authentication
using
traditional
pki
and
authorization
happens.
Based
on
the
mapping
of
the
dane
id
to
the
you
know
whether
or
not
the
dane
id
is
allowed
and
mapped
to
the
authority
key
id
in
the
ca
certificate,
that's
cached
in
the
pkxctd
discovery
process.
F
This
is
better
conveyed
using
an
illustration.
So
next
slide,
please
so
using
pcxcd
the
supplier
places
the
the
ca
certificates
right
in
the
box.
You
know
that
we
see
for
web
device.vendor.example.
F
F
Radius
can
then
discover
the
device
certificates
and
it
uses
those
device
certificates
to
in
the
process
of
getting
those
device
certificates.
We
get
the
trust
anchors
that
are
used
to
verify
those
identities,
so
it
caches
the
trust
anchors,
a
reference
to
those
trust
anchors
alongside
the
names
that
are
placed
in
the
the
radius
configuration
next
slide.
F
So
when
a
device
attempts
to
authenticate
to
the
network,
then
radius
then
performs
traditional
authentication
using
mutual
tls,
and
so
because
it
has,
you
know
this
trust
store.
You
know
that's
comprised
of
all
of
the
all
of
the
appropriate
ca
certificates
it
can.
It
can
do
mutual
tls
authentication
for
each
tls
and
as
an
authorization.
You
know
making
sure
that
the
the
certificate
is
issued
by
the
right
authority.
F
Then
it
does
that
authority
key
id
mapping
and
it
makes
sure
that
the
that
the
entity
certificate
is
tied
to
the
correct
ca
certificate
and
then
it's
allowed
if
it
is,
and
if
it's
not,
then
you
have
a
cross
domain
impersonation
issue
and
then
it's
access
is
denied,
but
this
is
how
it
works,
for,
if
you
don't
have
dns
sec,
then
this
is
how
you
can
do
mutual
tls
authentication
for
each
tls
using
radius.
F
Now,
let's
shift
gears
and
look
at
how
this
plays
out
if
you're
using
dane
for
client
identity
next
slide,
please
so
the
desired
behavior
is
the
same.
You
want
to
avoid
supplier
lock-in
and
have
your
suppliers
provide
identities
for
the
devices
so
that
you
don't
have
to
operate
a
massive
organizational
pki
getting
away
from
the
manual
onboarding
of
all
of
these
devices.
F
You
know
the
challenge
with
authorization
and
different
pki
naming
conventions
and
then
preventing
across
ca
impersonation.
The
goals
are
still
the
same,
but
when
we
use
dane
for
client
identity
and
with
tls,
then
radius
performs
authentication
and
authorization
based
just
on
the
list
of
allowed
dns
names
because
dane
is
actually
baked
into
the
process
of
establishing
that
tls
connection.
F
And
so
this,
this
is
what
it
begins
to
look
like
the
supplier.
Then,
if
the
zone
is
protected
by
dns
sac,
the
supplier
really
just
has
to
publish
tlsa
records
for
those
devices.
The
implementer's
responsibility
is
then
to
just
maintain
a
list
of
names
and
radius
of
authentic
of
authorized
entities
and
the
radius.
The
server
side
of
the
radius
authentication
can
happen
via
you
know.
F
Still
it
might
be
that
manual
process
of
installing
the
ca
certificate
onto
the
device
itself
right
so
that
it
can
authenticate
the
the
authenticating
server,
the
radius
server
or
there's
another
draft
that
we'll
discuss,
maybe
in
more
detail
it's
at
least
referenced
at
the
end
of
the
presentation
on
the
dns
sick
chain
extension
for
tls,
which
allows
the
delivery
of
a
dns
set
chain
so
that
the
record
can
be
authenticated
using
dane
before
you
have
ip
connectivity,
and
so
this
allows
this
could
allow
mutual
dane
authentication
in
the
eptls
authentication
process
before
network
access
and
ip
connectivity
are
granted,
and
so
that's
that's
still
in
draft
state.
F
But
it's
this
presents
a
very
interesting
use
case
for
that
and
the
radius
of
automation,
part.
You
don't
need
to
authenticate
or
to
automate
anything
on
the
radius
side,
since
this
all
happens
in
the
tls
negotiation
process
and
then
authentication
and
authorization.
F
You
know,
as
I
said
happen
within
the
tls
negotiation,
and
you
don't
have
to
do.
You
know
deal
with
the
sort
of
mapping
to
the
pki
trust
anchor
and
all
of
the
other
stuff
that
comes
along
with
that.
F
So
now
we
just
have
a
dns
zone,
underscore
device.vendor.example,
where
they
publish
device
certificates.
The
supplier
then
ships
the
devices
to
the
implementer
next
slide,
the
implementer
configures
names
in
the
radius,
server
and
next
slide,
and
then
the
mutual
tls
authentication
happens.
Using
dane,
you
know,
just
by
a
comparison
against
the
dns
record
in
the
authentication
process,
and
so
this
becomes
a
lot
more
sort
of
straightforward
of
a
process
from
the
from
the
radius
server
perspective.
Once
you
have
an
updated,
tls
library
that
supports
this
next
slide,.
F
And
so
what
you
get
with
dane
and
dnssec
is
that
you
know
you're
able
to
are
really
just
using
dane
in
general,
either
way
you're
getting
a
you're
getting
manufacturer
issued
identity
that
can
be
reasonably
used
for
pki
best
network
access.
It
works
with
or
without
dns
set,
depending
on
whether
using
pcxcd
or
regular,
dane
for
client
and
server
authentication,
pcd
sort
of
represents
the
first
step
into
dane
and
it's
using
web
pki
in
the
absence
of
dns
sec.
F
But
this
is
sort
of
our
like.
You
know.
This
is
our
way
of
just
kind
of
making
the
adoption
curve
for
dane
a
little
a
little
gentler
and
so
using
dane
for
client
authentication
using
pick
cd.
If
you
sign
the
zone
with
dns
sec,
dns
sec
actually
makes
things
easier,
and
I
feel
like
that
that
doesn't
happen.
F
Very
often,
dnsec
can
be
a
little
bit
intimidating
from
an
implementer
standpoint
and
it's
really
not
as
widely
used,
but
this
sort
of
incentivizes
the
move
to
dns
sect
because
it
actually
makes
you
know
stuff
a
little
bit
higher
in
the
stack,
easier
and
more
straightforward.
A
Okay.
Okay,
so
I
think
unless
the
the
authors
object,
it's
probably
about
time
to
take
a
discussion
period
and
ask
if
there's
any
a
clarifying
questions
first
and
then
see
what
people
think
about
the
scope.
To
date,
we've
gone
through
a
lot
of
stuff
and
there
are
some
other
problem
spaces
that
you
know
can
be
addressed
in
the
future,
but
we're
through
sort
of
the
ones
that
are
likely
candidates
for
early
targeting
correct
ash,
yeah.
A
Okay,
honest
go
ahead.
E
Hey
yeah,
I
looked
at
the
the
two
documents
that
were
mentioned
initially
in
the
earlier
part
of
the
session,
which
was
the
the
day
inclined
cert
in
particular,
and
I
liked
that
approach-
and
I
looked
quite
easy
and
accomplishable
to
me
not
so
sure,
but
in
the
later
later
part,
maybe
it's
useful
to
start
kind
of
simple
and
to
see
how
that
works
and
and
gain
some
implementation
experience
and
then
take
the
next
steps.
E
J
I
noticed
that
the
peaks
cd
proposal
has
the
the
web
server
over
web
pki
delivering
certificate
chains,
and
it
occurred
to
me
that
that's
rather
redundant
once
you
have
a
secure
channel
to
the
server
that's
going
to
deliver
trusted
content.
J
It's
suffices
for
it
to
deliver
a
tlsa
record
if
it's
really
a
substitute
for
what
otherwise
would
be
dnssec,
it
can
deliver.
Just
you
know,
just
a
hash
of
a
trust
anchor
and
the
client
behaves
the
same
way,
whether
it's
pkxcd
or
or
da
or
picx,
ca,
and
so
on.
It
delivers
its
chain
and
the
serve.
The
the
other
side
is
responsible
for
securely
obtaining
the
dainty
lsa
record,
either
over
dnsec
or
over
some
web
mechanism
that
delivers
exactly
the
same
data.
J
J
In
the
network
access
case,
it
occurs
to
me
that
the
client
would
probably
want
to
switch
identities
fairly
early
on
in
its
life
cycle
right,
the
manufacturer
might
sell
you
a
price
and
then
go
out
of
business
90
days
later
or
something
so,
while
you
might
initially
use
the
manufacturer,
provided
identity
and
certificate
chain
and
so
on,
to
get
the
device
in
your
network.
It's
probably
not
a
good
idea
to
expect
it
to
be
stable
over
the
lifetime
of
the
device.
F
Sure
yeah,
you
can
definitely
you
know.
We
have
protocols
like
brewski
to
allow
the
migration
between
manufacturer
issued
identity
and
organizational
identity,
but
we
think
that
there
may
be
use
cases
where
the
manufacturer
issued
identity
might
be
sufficient
ongoing
and
so
the
manufacturer
might
even
facilitate
certificate
rotation.
You
know
using
something
like
est.
F
You
know
for
updating
the
the
certificate
periodically
and
then
republishing
the
new
one
in
dns
and
if
there's
a
discovery
process
you
know,
especially
with
with
dns
second
dane
within
the
tls
negotiation
process,
that
certificate
can
change
over
time,
but
it's
still
associated
with
the
same
name.
So
the
name
becomes
the
anchor.
F
H
I
I
was
going
to
mention
that
our
protocols
are
designed
to
work
sort
of
in
conjunction
with
existing
iot
provisioning
mechanisms
like
whisky
and
stuff
right,
so
they
could
certainly
plan
to
work
with
those
mechanisms.
A
A
D
And
then
we
end
up
with
a
solution
in
its
space,
which
has
got
no
validity
in
the
outside
world,
because
nobody
uses
or
cares
about
it-
and
I
think
we've
got
to
be
very
very
careful
here
about
the
actual
use
of
this
technology,
then,
is
really
quite
hard
to
do,
because
it
relies
on
dns
sec,
which
is
also
quite
hard
to
do.
D
And
the
point
I
was
making
in
the
chat
I'll
run
about
this
is
that
we
don't
see
a
lot
of
uptake,
quite
frankly,
of
either
dns
sec
or
dean
as
it
is
today,
and
that's
amongst
people
are
reasonably
careful
in
terms
of
running
sizable,
email
installations
and
stuff
such
like
such
stuff,
like
that.
So
if
those
kind
of
clueful
organizations
struggle
to
see
the
benefits
of
using
dane
when
there
clearly
are
benefits,
how
do
we
think
this
is
going
to
translate
into
an
iot
ecosystem
for
vendors
and
everybody
else
in
that
space?
F
That's
a
good
point
thanks
for
that.
We
definitely
want
to
do
this
with
as
much
industry.
Involvement
as
we
can
bring
in
the
interest
from
the
lorawan
side
was
very
encouraging,
because
it's
a
really
strong
use
case,
and
if,
if
that
community
says
that
it
that
it
needs
something,
you
know,
we
think
that
the
sort
of
the
breadth
of
that
ecosystem
would
be
very
you
know,
would
have
sort
of
an
elevating
effect
on
this
effort.
D
Yeah,
I
agree,
but
I
think
the
problem
is
there
will
be
other
chunks
of
this
iot
system
were
not
part
of
the
waterway
efforts.
How
can
we
reach
out
to
them?
How
will
they
become
aware
of
what
might
be
happening
in.
H
Point
yeah
so
jim.
I
think
we
are
doing
that
in
the
background.
So
I
think
we
can
talk
more
about
that
later,
but
I
I
I'll
tell
you
when
I
originally
was
working
on
the
drafts
we
were
talking.
This
was
a
previous
job.
We
were
talking
actively
with
iot
companies
that
were
interested
in
deploying
the
stuff
right.
So
then
there
was
a
little
kind
of
that
effort,
kind
of
fizzled,
and
then
I
changed
jobs.
H
But
it's
come
up
again,
so
I
I
think
those
companies
are
still
out
there
and
where
the
plan
is
to
to
reach
out
and
re-engage
them.
D
A
A
K
K
So
we
built
a
registry
system
to
provision
iot
device
that
have
e-sims
and
the
good
thing
about
esim.
It's
it's
a
crypto
engine.
It
can
create
keys
and
we
build
a
system
with
iot
safe
so
that
the
registry
signs
the
keys
that
are
created
on
the
esim.
They
have
a
unique
id
and
then
we
use
a
dns,
the
sort
for
now.
So
we
have
cert
entries
for
every
iot
device,
with
a
hash
of
the
keys
on
the
iot
device,
so
that
we
can
map
one
to
one
so
we're
basically
starting
this
process.
K
Now
what
we
need
our
standard
around
this,
so
I'm
late
to
this
the
initiating,
but
I
think
it's
really
great
to
see
where
it's
going
and
I'd
like
to
map
this,
to
making
sure
that
the
solution,
we're
building
is
standard
and
it's
secure
and
it
meets
the
requirements.
A
So
jacques,
can
I
read
that,
as
if
this
does
go
forward,
you
would
likely
deploy
it.
K
Yes,
but
it's
you
know
the
the
lessons
learned,
we've
done
so
far.
At
the
very
very
beginning,
for
example,
we
tried
to
get
the
mqtt
provider
solus
to
change
their
system,
just
to
validate
the
to
do
a
dns
query
to
validate
the
iot
device
with
a
cert,
and
that
was
a
whole
lot
of
work
for
them
to
take
on
so
just
doing
a
sim
like
an
assert
is
simple.
If
we
need
to
implement
the
tlsa
that
I've
seen,
it
seems
a
little
bit
complex.
F
Okay,
so,
as
far
as
making
it
simple,
what's,
what
do
you
think
is
the
best
way
to
get
to
sort
of
flatten
the
curve
into
and
to
make
that
easier,
would
helper
libraries
make
that
easier
is,
is
the
is
the
complexity
around
record
formatting
or
is
it
around
sort
of.
K
You
got
to
think
low-powered
iot
device
which
have
limited
bandwidth
and
limited
crypto
capabilities.
So
the
first
thing
we
learned
is
on
lte
cat
lte
like
low
powered
lte4
bandwidth.
There
was
not
enough
bandwidth
to
the
iot
device
to
validate
to
get
all
the
dns
packets
to
go
through,
oh
all,
right
validation.
K
So
that
was
the
first
thing
we
learned
in
the
usk.
So
how
do
we
simplify
this?
So
so
there's
it
started
the
iot
device
with
having
a
resource
limitation
with
the
nsx
validation.
K
But
on
the
other
side
we
did
get
the
mtls.
I
like
that
acronym,
so
the
mutual
tls
to
work
with
any
sim.
So
we
modified
the
the
iot
device
to
use
the
esim
to
do
the
tls
challenge,
authentication
using
the
cert
there
and
then
validate
the
client
identity
to
the
dns.
So
at
a
maybe
the
way
we
did,
it
is
ugly
and
not
standard
I'd
like
to
standardize
it,
but
there's
huge
value.
I
think
in
making
all
of
this
work.
A
Great,
thank
you
all
right,
thanks
chuck
and
I'm
glad
you
showed
up
today
we
were
talking
late
last
night.
All
right.
I
see
nobody
else
in
the
queue.
So
I'd
like
to
ask
sort
of
the
following
question
for
comments.
If
anybody
wants
to
join
the
cube
to
answer
it,
which
is,
you
know,
is
the
problem
space
understandable,
but
based
on
the
discussion
in
jabber,
which
I
think
michael's
been
following
better
than
I
and
based
on
the
comments
of
the
microphone,
it
seems
like
the
problem.
Space
has
been
well
defined
and
everybody
understands
it.
A
If
you,
if
you
disagree
with
that
and
you're
confused,
do
let
us
know-
and
so
the
next
question
then
is
you
know,
is
the
problem
space
worth
solving
within
the
etf?
It
seems
like
there
is
general
support
for
that,
and
I'd
like
to
hear
if
anybody
you
know
thinks
that
this
isn't
something
that
the
ietf
should
take
on
in
general
and
as
long
as
nobody's
joining.
For
that
we'll
also
say
you
know
of
the
three
starting
documents
there
are.
There
are
three.
A
I
don't
know
how
many
people
have
read
the
third
one,
because
it
appeared
on
monday,
which
was
beyond
the
normal.
Mandatory
must
read
documents
to
participate
in
the
discussion.
Do
does
it
seem
like
those
three
documents
are
a
good
direction
or
a
good
place
to
start.
E
A
question
you
said
three
documents,
which
are
the
three
I
remember
the
first
two
and
then
what
which
one
was
the
third.
A
I
had
some
are
these
three,
so
the
the
pickaxe
cd
is
the
third
one
and
that's
the
one
where
there
was
there
was
more
discussion
in
the
jabber
room.
I
think
about
whether
that
approach
was,
I
think
it
might
have
been.
You
actually
han.
That
said
that
the
first
two
were
likely
a
good
starting
place
and
the
third
one,
the
pkx
cd
idea,
maybe
should
be
tabled
for
future
charter
items.
Well,.
E
A
Yeah
so
thoughts
on
on
you
know
is
this
an
acceptable
starting
place
for
the
aetf
to
focus
on
with
especially
the
first
two
drafts,
as
you
know,
possible
charter
items
to
consider
once
we
get
to
the
point
of
writing
the
charter
again,
this
is
a
non-working
group
forming
boss.
At
this
point,.
H
A
It
looks
like
there's
more
more
dialogue
going
on
in
the
chat
that
that
seems
to
back
that
up.
So
that's
good
starting
points.
Thank
you.
Jim
go
ahead,
so
I've
just
got
a
question
on
next.
A
C
Hi,
so
this
is
roman,
I
mean
it's
a
that's
a
great
kind
of
process
question
it
all
really
depends
if
we
are
at
the
point
where
we
feel
like
we
understand
the
problem,
we
have
concurrence
that
this
is
something
we
want
to
solve
and
we
have
a
reasonable,
reasonable
agreement
on
part
of
the
starting
point.
It
seems
like
the
next
step
would
be
to
polish
a
charter.
C
If
we
can
polish
that
charter
to
the
point
that
there
is
agreement
across
this
community
of
discussion,
we
could
directly
go
to
trying
to
form
a
working
group
without
having
another
boss.
If
we
think
that
the
conversation
around
the
chartering
in
the
scope
would
require
a
buff,
we
could
absolutely
do
that.
So
we
have
the
option
for
both
we've
done
it
both
ways
in
security.
A
Thanks
for
the
answer,
roman
harness.
G
Sorry,
if
I
could
just
jump
in
and
I
would
add
a
little
bit
roman-
we
definitely
do
not
want
to
wait
to
have
the
discussion
to
have
a
second
bath.
We
should
definitely
continue
to
have
the
discussion
and,
I
think,
roman,
your
your
comments
are
predicated
on
the
fact
that
we
we
have
the
discussion
to
understand
what
we
do
or
do
not
agree
on.
C
Yeah,
I
mean
absolutely,
we
should
not
do
a
halting
function
that
the
next
time
we
talk
is
the
next
ietf
meeting.
We
should
roll
this
into
the
mailing
list.
We
should,
if,
if
that
it
looks
like
where
we're
heading
is
we
want
to
talk
about
charter?
We
should
start
dropping
some
charter
in
the
mailing
list
and
iterate
through
it,
and
you
know
shoot
for
not
even
needing
a
new
bot.
C
Then,
if
there's
that
much
interest,
okay,
one
of
the
key
ingredients
to
get
us
across
that
finish
line,
I
will
say
beyond
making
sure
we
understand.
The
task
is
having
a
conversation
about
question
number
four,
which
I
think
wes
is
going
to
lead
us
to
shortly,
which
is
who
exactly
is
going
to
kind
of
work
on
this,
and
do
we
have
a
sense
for
who'd
be
willing
to
take
it
who'd,
be
willing
to
kind
of
review
edit
implement
et
cetera.
H
A
Yeah
so
honest
go
ahead,
the,
but
anybody
that
wants
to
participate
as
we're
doing
q
a
please
do
feel
free.
While
you're
talking
and
posing
your
question
or
discussion
item,
you
know
feel
free
if
you're
interested
in
helping
us
at
the
same
time.
E
I
was
wondering
whether
there's
room
for
an
architecture
document
in
the
group
as
well
like
the
the
two
documents,
are
more
like
really
the
protocol
specifications
on
the
first
two
and
the
reason
is
because
there
obviously
some
architectural
aspects
here
in
this
work
and
in
my
experience
from
the
su
deep
rats
groups
and
the
architecture,
documents
have
been
extremely
helpful
in
understanding
how
the
different
pieces
fit
together
and
identifying
like
who
actually
needs
to
be
involved
in
in
making
work
successfully.
H
Yeah,
so
this
is
schumann,
so
harness
thanks
for
that
comment,
I
I
think
that's
a
great
idea.
I've
actually
thought
of
the
same
thing
myself,
but
thanks
for
proposing
it
I
mean,
if
the
participants
think
that
would
be
a
useful
document
to
add
to
this
basket
of
work.
I
think
I
think
we
would
be
willing
to
take
it
on
and
receive
help
from
you
or
anyone
else
who
would
like
to
help
us
flesh
out
that
document.
C
I
wanted
to
endorse
hottest's
proposal.
I
think,
based
on
the
conversation
we
saw
in
jabber,
where
it
seemed
like
there
was
a
lot
of
discussion
about
how
this
domain
is
different
than
another
domain
and
all
the
clarifications
we
needed
to
have.
I
think
this
that
kind
of
preamble,
of
having
an
architecture
document
kind
of
scoping.
The
insertion
of
the
scope
that
appears
to
be
in
those
two
documents
would
be
exceedingly
helpful.
H
A
All
right,
I
see
no
more
participants
in
the
queue
if
people
are,
you
know
wanting
to
help.
Of
course,
signing
up
to
the
mailing
list
is
the
first
step
to
do
that,
as
well
as
reaching
out
to
the
authors
and
reading
the
documents
and
complaining
wildly
on
the
mailing
list
or
giving
wild
advocate
support.
A
Why
don't
we
shift
now
into
since
there's
still
nobody
in
the
queue?
Why
don't
we
shift
now
into
the
other
problem
spaces
that
could
be
potentially
adjusted
in
the
future?
That
again,
these
are
slides.
That
will
be
discussing
things
that
are
likely
out
of
scope
for
the
beginning,
but
just
to
see
other
areas
where
this
sort
of
technology
might
help.
Does
that
work?
For
you
guys.
F
You
all
right,
so,
let's,
let's
walk
through
a
a
thought,
experiment
of
how
multicast,
dns
and
dane
might
work
together
next
slide,
please!
F
So,
let's,
let's
just
say
that
there
is
a
taxi
service
and
in
order
to
remain
compliant
with
their
with
their
insurance
company,
they
have
to
retain
a
certain
number
of
days
of
you
know,
forward-looking
dash,
cam
records
and,
and
so
the
constraints
involved
in
implementing
such
a
thing
is
that
you
know
if
you,
if
this
is
on
the
order
of
months,
then
it
might
be
very
expensive
to
put
that
kind
of
storage
in
every
single
car.
F
F
So
as
a
as
a
solution,
you
know,
maybe
we
want
to
have
the
the
vehicles
only
have
to
retain
about
a
day's
worth
of
video
right,
and
so
when
they,
when
they
pull
back
into
the
station
at
night,
then
these
would
flush
up
to
you
know
the
storage
system
in
the
you
know
at
the
garage
and
so
using
office,
wi-fi
for
that
gets
around
bandwidth
problems
and
and
having
video,
you
know
these
video
files
with
a
signature.
F
F
Vendor.Example
is
the
domain
that
owns
the
identity
for
the
for
the
dvr
system
or
video
storage
system
at
the
at
the
garage,
and
then
you
have
another
vendor
that
produces
dash
cams
for
taxis
and
that's
taxi.example.
F
You
have
a
dns
record
for
the
dvr
system
and
the
dvr
system
has
a
local
ip.
That's
advertised,
you
know
use
taking
the
the
leftmost
label
from
the
dvr's
dns
name.
Then
we
have
an
advertised
ip
address
as
well
as
https
service
advertised
on
multicast,
dns
and
then
car
54.
F
You
know,
has
you
know
the
dash
cam
identified
by
car
54
underscore
auto.taxi.example
has
a
tlsa
record
in
in
dns,
and
so
the
first
step
is
when
the
car
gets
back
to
the
garage.
Then
maybe
it
connects
to
the
network
using
etls
in
a
way
that
we
described
earlier
in
the
conversation
which
might
be
dane,
enabled,
and
so
the
next
step
next
slide.
Please.
F
The
car
knows
beforehand
the
dns
name
of
the
dvr
device
right,
which
is
where
the
tlsa
record
can
be
discovered.
So
breaking
that
identity
apart
we
can
take
the
leftmost
label
and
we
get
the
mdns
instance
name,
and
so
the
mdns
service
query
becomes.
You
know
we're
looking
for
https
services
on
the
local
network
for
recorder
5.6.
F
We
can
use
that
to
you
know,
get
the
the
local
ip
and
port
you
know,
and
so
now
next
step
or
next
slide.
Please
then
we
can
begin
a
tls
handshake
right,
so
we
have
the
ip
and
the
port
discovered
via
multicast
dns,
and
then
we
have
the
proper
dns
name.
F
That's
taken
from
the
you
know
what
the
car
knew
beforehand.
As
far
as
you
know,
this
is
where
the
identity
is
in
the
dns.
You
know
with
the
tlsa
record,
resides
and
so
the
car
then
begins
a
tls
negotiation
with
the
dvr
system.
Saying:
okay,
my
dain
client
id
is
car,
54.
dot,
underscore
auto
taxi.example
and
that's
and
then
the
dns
name
of
the
you
know,
recorder,
5.6
underscore
dvr.vendor.example
is
used
in
the
sni
for
establishing
that
in
the
tls
handshake.
Next
slide.
F
And
so
the
the
server
certificate
is
then
matched
against
the
the
dns
record
for
the
dane
dns,
the
tlsa
record,
rather
for
port
443
tcp
recorder,
5.6
underscore
dvr.vendor.example.
F
This
follows
the
pattern
for
the
existing
dane
standard
for
server
authentication
right,
and
so
this
is
already
sort
of
codified
next
step
next
slide,
and
then
we,
the
cars
dash
cam,
presents
a
client
certificate
to
the
server
next
slide.
F
And
then
the
servers,
the
the
server
then
verifies
the
certificate.
That's
presented
against
the
the
record
in
dns
for
car
car54.underscore
auto.taxi.example,
and
that's
how
we
complete
the
mutual
tls
authentication
with
the
dvr
system
on
site
next
slide,
and
then
we
can
upload
the
signed
dashcam
footage
to
the
dvr
system.
We
have
identity
attached
to
the
object,
that's
being
uploaded
via
the
signature
and
a
and
of
course
you
probably
include
the
name
of
the
signing
entity
in
that
as
well.
F
The
and
all
of
this
happens,
and
if
we
think
about
the
way
that
trust
would
be
described
in
this
application,
then
for
network
access.
You
would
have
the
name
of
the
dash
cam,
as
this
is
an
allowed
entity
for
the
network
for
establishing
trust
between
or
and
allowing
authentication
authorization
between,
the
dash
cam
and
the
dvr
system.
F
The
dvr
system
needs
to
know
the
names
of
the
allowed
entities
that
are
allowed
to
to
authenticate
and
to
upload
videos
and
that
the
dash
cam
only
needs
to
know
the
dns
name
of
the,
where
the
tlsa
record
resides
of
the
sorry
lots
of
words,
lots
of
coffee
of
the
dvr
system
in
dns
and
so
beginning
with
those
two
dns
names.
We
can
then
compose
the
multicast
dns
queries
for
locating
those
resources
locally
and
then
performing
authentication
and
and
so
yeah.
F
So
that's
you
know-
and
these
are
probably
the
newest
slides
in
the
in
the
whole
deck.
So
I
you
know
we
can
definitely
take
questions
on
how
this
use
case
might
work.
F
Yeah,
so,
let's,
let's
bump
two
slides
scope
of
work,
the
core
objectives
are
the
are
sort
of
getting
getting
these
three
drafts
established,
and
so
the
the
first
two
are
what
those
are
the
2015
drafts
for,
the
tls
negotiation
using
dane
and
dnsec,
and
the
third
one
is
dane
without
dns,
using
the
using
a
web
pki
the
peripheral
objectives
beyond
this,
but
still
sort
of
within
scope.
F
Next
slide,
please
is
that,
in
order
to
get
adoption
on
the
server
side,
it
would
be
very,
very
useful.
We
think
to
have
this
supported
by
standardized
proxy
headers
for
http
and
lower
level.
F
Tcp
proxies
so
getting
as
well
as
the
you
know,
email
ecosystem
already
uses
dane,
and
this
would
be
a
great
place
to
to
go
ahead
and
use
stain
for
client
identity,
but
this
involves
you
know
seeing
how
this
plays
into
start
tls
and
then,
of
course,
the
object
security
use
case
for
osean
and
cozy
updating
the
x59
field
usage
to
cover
that.
A
So,
michael,
I
assume
you're
in
the
queue
without
a
hat.
Is
that
correct?
A
That's
a
good
question
so
when
you
say
http
you're
talking
about
like
brian
campbell's,
this
is
for
a
document
that
didn't
go
anywhere
on
carrying
the
client
certificate
in
across
the
framework.
Is
that
what
you're
talking
about.
F
This
is
a
little
bit.
This
is
like
that,
but
a
little
bit
different.
I
would
the
way
I
sort
of
envisioned
this
happening
is
just
the
client
name,
just
the
the.
B
F
Yeah
just
carrying
the
name,
we
don't
have
to
carry
the
certificate
into
the
application,
because
you're
really
just
authorizing
a
name,
so
it
would
be
a
different
header
value
than
that.
This
is,
you
know,
specifically
a
new
header
value.
I
think
let's
kick
to
the
next
slide.
I
have
a
little
bit
more
details
on
http
and
proxy
protocol
headers
and
how
those
might
play
out.
F
F
However,
this
the
identity
is
conveyed
within
the
tls
session
establishment
for
the
dane
client
identity
and
then
forwarding
that
up
into
the
application,
as
a
you
know,
or
through
the
middleware
layer
to
the
to
the
application
server
as
an
http
header
and
then
for
the
tcp
proxies
and
load
balancers,
we
would
look
at
something
like
the
the
proxy
protocol,
which
is,
I
don't
think,
that's
maintained
inside
ietf,
that's
maintained,
I
think
by
h.a
proxy
could
be
wrong
yeah.
F
So
this
would
be
implementing
a
you
know,
a
a
new
header
tlv
for
that
which
would
convey
the
dane
dns
name
that
the
identity
was
authenticated
against.
F
That's
sort
of
how
I
think
this
could
play
out.
Of
course,
this
is,
you
know,
definitely
open
to
discussion
about
the
the
best
way
to
accomplish
this,
but
I
think
that
if
we
get
this
into
something
that's
consumable
by
load
balancers,
it
would
make
it
easier,
for
you
know,
that's
sort
of
the
a
a
narrower
space
to
implement
in
and
get
the
most
benefit.
You
know
so,
then
you
don't
have
to
worry
about
implementing
it.
F
For
every
single
you
know,
http
server,
because
very
often
times
you'll
have
an
http
server
behind
a
proxy
of
some
sort
and
having
the
proxy
do
the
authentication
and
then
just
pass
a
header
in
that
an
application
on
the
other
side
can
easily
process.
We
think
would
make
things
much
easier
for
adoption.
F
So
that's
sort
of
our
thoughts
on
protocol.
Headers
then
did
that
answer
your
question.
A
E
On
on
the
dash
cam
example,
I'm
a
little
slow
understanding
this.
So
what
are
the
assumptions
that
you
make
on
on?
The
dashcam
example?
Is
it
the
car
is
configured
to
know
what
the
recorder
in
the
home
is
and
also
since
you
use
eab
dls
initially,
you
are
obviously
have
configured
it
to
use
a
specific
network
at
home.
Is
that
correct.
F
Correct
so
that
would
be
part
of
the
onboarding
process
for
the
dash
cam
into
the
the
taxi
companies
organization
is
the
dash
cam
would
have
to
be
configured.
You
know
for
the
tls,
whatever
that
requires.
If
it's
using,
you
know
dane,
and
I
think
the
the
ideal
situation
is
where
we
would
have.
You
know
the
the
trust
you
know-
dns
sec
and
the
trust
chain
conveyed
via
the
the
tls
extension
for
dns
sec.
F
But
there
is
definitely
you
know
an
onboarding
process
whereby
you
have
to
configure
the
dash
cam
to
attach
to
the
network,
and
then
you
have
to
configure
the
dash
cam
with
the
the
name
of
the
dvr
system,
the
dvr
systems,
dns
name
yeah.
So
this
this
does
assume
that
there
is
some
configuration
of
of
dns
names
who
are
allowed
to
access
the
network
and
allowed
to
access
the
dvr.
F
And
for
what
it's
worth,
you
know
hope
the
the
hope
is
that
the
configuration
of
trust
for
in
an
application
like
this
could
look,
and
so
my
my
history,
professional
history
was,
I
used
to
do
net
ops
and
so
describing
things
in
the
terms
of
a
network.
F
Access
control
list
is
something
that
works
pretty
well
for
the
eyes
and,
and
so
what
we're
kind
of
going
for
is
that
from
an
operator's
standpoint,
it
would
be
really
nice
if
we
can
get
this
if
we
can
make
the
protocol
as
as
straightforward
as
possible,
and
if
you
can
configure
network
access
via
you
know,
these
are
a
list
of
allowed
entities
that
are
really
not
hard
to
look
at
just
simple
dns
names
and
so
being
able
to
describe
communication
patterns
in
lists
of
dns
names.
We
think
would
be.
F
You
know,
make
adoption
even
easier.
You
know
for
small
shops
and,
of
course
you
know
mega
scale
stuff.
You
would
have
automation
for,
but
that's
sort
of
the
the
ease
of
adoption
we
think
could
could
be
affected
by
just.
You
know,
having
sort
of
a
simplified
approach
to
describing
trust
like
that.
F
A
All
right,
so
we
probably
three
minutes
before
we're
going
to
cut
into
final
questions
for
the
buff
since
there's
about
seven
minutes
left
of
the
presentation.
Is
there
any
other
topics
that
you
guys
definitely
want
to
hit?
So
we
make
sure
you
get
those
on
the
table,
I'm
giving
you
the
opportunity
to
skip
around
if
you
like,
okay,.
F
Yeah,
because
we
we
definitely
have
a
handful
of
slides,
so
the
shivan
do
you
want?
Do
you
have
anything
you
want
to
cover?
I
have
a
couple
of
things,
but
if
you
want
to
do.
F
Cool
so
really
quickly.
You
know
there
are
a
couple
of
adjustments
to
jose
and
cozy
and
if
we
look
at
slides,
84
real
quick,
you
know
these
are
really
just
sort
of
defining
new
new
uris
that
are
valid,
for
you
know,
for
specific
fields
that
already
exist
in
these
standards
and
then
cozy
might
be
even
easier.
Next
slide.
Please,
because
really
we
just
need
to
support
the
application,
dns
media
type
so
eligible
for
inclusion.
Let's
run
through
these
really
quick
s,
mime
a
is
a
standard
which
exists
next
slide.
F
Please,
two
slides
sma
is
a
discovery
mechanism
for
s,
mime
certificates,
that's
based
on
dane,
and
this
exists
as
an
experimental
standard.
It's
already
out
there
it
would.
This
would
be
easier
to
adopt
for
folks
who
don't
have
dns
sec
using
something
like
pkx
cd
and
so
updating
this
you
know
would
really.
F
This
fits
with
the
pattern
that
we've
already
established
for
pkx
cd
identity,
naming.
You
know:
dns
name,
label
construction,
things
like
that
fits
really
easily
here.
We
think
this
would
be
a
quick
hit
if
anybody's
really
interested
in
picking
it
up.
The
next
slide,
please,
the
the
dnsec
chain
extension
for
tls,
we
think,
would
be
a
really
big
win,
because
then
that
would
further
reduce
the
onboarding
time
for
devices.
F
There
might
also
be
an
option
for
making
sip
authentication
easier
via
the
next.
Oh
victor,
you
want
to
jump
in
real
quick
on
this.
A
J
So
for
pxcd,
I
don't
even
think
we
need
a
new
gain
usage
for
it
frankly,
because
the
signaling
that
you
want
to
go
out
of
band
and
not
rely
on
dns
optionally,
it
can
happen
via
the
new
https
records
that
are
being
introduced
in
dns
that
hint
at
you
know
this.
This
session
should
be
your
trust.
Trust
building
should
employ.
J
You
know
the
well-known
uri
mechanism.
Some
key
word
in
https
record
can
signal
that
and
then,
when
you
contact
the
server,
you
get
a
regular,
dane
record,
but
the
securing
the
channel
against
tampering
is
done
via
web
pki.
So
I
don't
think
it
even
is
necessary
or
makes
sense
to
have
a
new,
dane
usage
for
this.
Https
can
carry
lots
of
information,
and
this
can
just
be
one
of
the
pieces
of
information
in
the
https
record
that
the
client
retrieves
before
it
builds
the
tls
connection.
A
F
Yeah
sure
dane
for
sip
authentication,
we
think
is
another
opportunity.
Updating,
oauth
2
for
mutual
tls
using
dane,
could
be
an
enabling
thing
as
well
and
then
mls
message.
Layer
security
might
benefit
from
using
dns
as
a
directory
for
for
public
keys
and
in
the
appendix
we've
got
a
list
of
you
know
some
of
the
adjacent
standards
and
drafts
that
we
discussed
throughout
the.
A
Topic
today
so
yeah,
I
I
must
say
that
appendix
is
just
awesomely
well
put
together,
so
all
of
these
slides
are
available
for
downloading
from
the
data
tracker.
So
I
encourage
everybody
to
do
that
so
that
you
can
take
a
look
at
the
full
presentation.
We
actually
did
get
pretty
much
all
the
way
through
it
are
there
any.
I
think
that
we're
fairly
well
understood
at
this
point.
I
think
that
we've
sort
of
answered
all
the
questions
from
the
buff
point
of
view,
roman
or
ben.
A
C
C
We
have
an
understanding
of
the
problem
and
it
looks
like
the
next
steps
are
to
return
to
the
mailing
list
and
really
just
hammer
on
the
specifics
of
how
much
scope
we
want
to
talk
about
and
to
reiterate
the
previous
conversation
that
let's
not
wait
for
an
in-person
meeting,
and
if
we
can,
you
know,
continue
to
discuss
productively
on
the
mailing
list.
We
can
get
to
the
point
to
an
on
an
agreed-upon
charter.
C
The
key
thing
I
would
ask
the
you
know
folks
discussing
on
the
mailing
list
is
that
that
we
get
a
better
sense
of
who
would
like
to
work
on
this,
as
that
will
be
another
key
ingredient,
in
addition
to
scope,
to
allow
this
to
progress
forward.
But
thank
you
for
all
the
work
that
went
into
this
and
thank
you
to
the
community
for
all
their
helpful
feedback,
both
here
and
the
very
active
jabber
channel.
A
And
thank
you
to
the
ads
and
the
proponents
for
putting
this
together
in
such
a
well,
well
organized
mechanism,
michael
anything
else,
you
want
to
add
nope.
I
just
thought
I'd
show
my
face
again
good
plan,
all
right
all
right,
so
I
think
that
we
will
call
it
here.
We
have
like
a
minute
left
and
I
encourage
again
everybody.
A
You
know
successful
working
groups
come
out
of
an
active
mailing
list,
so
if
you
want
to
participate
and
want
to
help
out,
certainly
joining
the
the
danish
mailing
list
is
a
the
best
way
forward.
At
this
point,
thanks
everybody
for
coming
and
please
enjoy
the
cookies
in
the
jabber
town
gathered
jabbertown.
I
like
that
we
should
call
jabbertown
how
come
we
didn't
call
it
jabbertown
yeah.
We
probably
could
probably
available
all
right.
Thank
you
all
right.