►
From YouTube: IETF112-DANCE-20211112-1200
Description
DANCE meeting session at IETF112
2021/11/12 1200
https://datatracker.ietf.org/meeting/112/proceedings/
A
B
All
right
now,
I
no
longer
see
it
climbing.
So
let's
go
ahead
and
get
started.
This
is
the
dane
authentication
for
iot
service,
hardening
and
or
dance.
Actually,
that
title
is
the
old
title:
isn't
it
anyway?
I
am
west
hartaker,
I'm
here
with
my
co-chair
paul
wooters,
that
is
the
mailing
list,
and
that
is
our
official
icon
for
ietf112,
hopefully
I'll
find
other
official
icons
for
the
future.
B
One
of
the
things
that
we
are
trying
to
do
is
make
sure
that
all
members
of
the
atf
are
welcome
to
participate
and
are
treated
with
respect.
Please
do
sleep
speak
slowly.
We
english
is
not
the
native
language
of
everybody
dispute
your
ideas
by
reasoned
argument,
not
by
emotional
statements.
I
think
that's
something
that
I
was
just
talking
to
high
school
students
about
this
week.
B
It's
not
a
single
meeting
do
be
aware
that
all
of
these
rules
do
apply
to
the
jabber
meet
echo
im
system,
2,
not
just
the
microphone,
because
everything
is
logged
permanently
on
web
archives
and
also
in
youtube
for
working
group
information.
We
have
a
data
tracker,
you've
probably
seen
it,
and
the
purpose
of
dane
in
particular
is
to
extend
dane
to
encompass
tls,
client
authentication,
which
is
what
we
talked
about
in
the
boss
that
we
had
about
how
to
use
certificates
to
do
client,
authentication
and
not
everything
under
the
sun.
B
B
The
mailing
list
has
been
kind
of
quiet,
it's
time
to
stir
up
the
pot
a
little
bit,
and
hopefully
this
meeting
will
be
able
to
kick
that
off
as
well,
and
then
there
are
three
drafts
that
we'll
talk
about
today
as
well
to
bootstrap
our
working
group.
So
welcome
to
the
inaugural
meeting
the
chair,
introduction
is
being
done.
Tim
has
agreed
to
take
notes
and
is
hopefully
in
the
medical
or
in
the
notes.ietf
room
right
now.
B
C
B
B
Oh
yeah,
it's
not
my
it's
not
mine
either!
So
all
right,
so
our
conversation
this
morning
we'll
talk
the
way
we've
structured.
It
is
we're.
Gonna
talk
about
use
cases.
First,
I
think
one
of
the
things
that
came
out
of
the
buff
was
people
weren't,
sure
exactly
how
it
was
going
to
be
used
or
where
it
might
be
deployed.
So
we've
put
together
three
use
cases
this
morning
for
how
we
expect
the
dance,
outputs
or
the
tls
client
usage
to
work
in
in.
D
B
B
D
E
Yes,
great
all
right,
whoa,
now
it's
advancing
automatically
all
right.
So
basically,
I'm
not
gonna
try
and
go
into
any
great
technical
detail.
I'm
happy
to
answer
any
questions
in
q
a
so
forth.
I'm
just
gonna
try
and
give
an
overview
of
the
use
cases
that
I
am
aware
of.
So
one
obvious
thing
is
that
using
dane
to
secure
the
dns
is
a
demonstration
of
good
faith,
eating
our
own
dog
food
etc,
and
it's
feels
to
me
kind
of
ridiculous
to
do
anything
else.
E
So
I
think,
as
a
matter
of
principle,
we
should
be
using
dane
to
secure
the
dns
in
addition,
ca,
certs
or
one
of
our
big
known
vulnerabilities.
At
this
point,
the
ca
cert
system
is
trash,
and
anybody
who
wants
to
see
a
cert
saying
that
they're
somebody
else
has
no
particular
difficulty
getting
it
at
this
point,
and
so
those
little
green,
lock
icons
don't
actually
mean.
E
E
So
I
think
we
we
really
need
automatic
tools
there,
things
that
are
applied
by
default,
rather
than
assuming
that
the
people
who
have
the
unsigned
zone
data
are
fully
capable
of
defending
it
against
attack
and
dnsec
is
fine.
If
everybody's
going
to
see
the
same
records
right,
if,
if
you're
never
going
to
distinguish
between
different
people
and
hand,
different
records
to
different
people,
then
no
issue,
but
that's
also
something
that
people
want.
E
So
dns
great
for
authenticating
the
content
but
doesn't
deal
with
authorization
and
we
already
do
authorization
throughout
the
dns
publishing
chain.
We
just
do
it
in
a
variety
of
awful
hacky
ways
and
what
I
would
like
to
see
is
one
nice
clean
way
that
applies
at
every
stage
here,
like
each
of
those
little
red
arrows
is
done,
the
same
way
not
using
a
different
hack.
E
Where
people
in
enterprise
do
a
lot
of
split
horizon,
they
depend
on
a
lot
of
split
horizon.
Everybody
gets
that's
ugly
and
not
a
good
idea,
but
you
know
we
also
get
that
it's
not
going
away
anytime
soon.
So
what
do
we
do
with
people
working
from
home?
And
you
know
kovid
and
zero
trust,
security
and
so
forth?
We
need
some
way
of
supporting
split
horizon.
That
does
not
depend
upon
an
ass
in
a
seat
in
an
office
in
a
specific
location,
so
tls
client
authentication
solves
that
problem
very
neatly.
E
But
if
all
you
want
to
do
is
give
somebody
a
different
dns
answer,
it's
a
very
heavy
weight
mechanism
for
doing
it
requires
a
lot
of
moving
parts
that
are
sort
of
outside
the
dns.
There's.
Also
a
huge
demand
for
closed
community
recursive,
resolvers
recursive
resolvers
that
are
not
public,
recursive
resolvers
in
the
sense
of
answering
any
query
that
comes
to
them
from
anybody
on
the
internet,
but
are
recursive
resolvers
in
the
sense
that
an
enterprise
would
have
had
them
internally
prior
to
zero
trust,
work
from
home,
blah
blah
blah.
E
So
we
have
people
who
want
to
run
a
recursive
resolver
that
has
a
closed
user
community
and
is
not
answering
for
anybody
in
the
whole
world.
So
we
need
a
way
of
authenticating
a
client.
For
that
and
again
that's
you
know.
People
are
trying
to
do
vpn
auth
for
that
which
is
a
hassle
between
recursive
and
authoritative.
E
This
again
isn't
probably
visible
to
everybody,
but
there
is
a
huge
amount
of
iplayer
prioritization
that
happens
between
authoritatives
and
recursives.
So
if
you're
operating
large
authoritative,
you
have
a
list
of
the
ip
addresses
of
all
of
the
major
recursive
name
servers
all
of
their
upstream
transit
interfaces
and
you
try
and
keep
that
list
up
to
date
and
when
a
ddos
comes
in
those
are
the
ip
addresses
that
get
the
answers.
First,
that
is
an
immense
headache.
E
E
E
E
Then
we've
got
the
authoritative
anycast
to
the
hidden
primary
to
the
dnsx
signer.
That
section
is
all
handled
with
xfr
and
tcig
and
so
forth
that
all
works,
but
tcig
is
shared
secret.
So
it's
super
clunky
and
the
net
effect
of
this
is
that
people
wind
up
reusing,
dcig,
keys
across
multiple
sessions,
multiple
partners,
you
know,
organization
to
organization.
They
may
have
a
unique
key,
but
then
they've
got
a
whole
bunch
of
servers
on
each
side
and
they're
reusing
they're,
having
t-sig
keys
floating
around
in
configuration
documents
in
documentation
in
email
in
chat.
E
Tls
solves
this
problem
and
then
lastly,
the
the
thing
I
mentioned
up
front
zone
data
is
typically
authored
on
a
machine
and
by
parties
who
are
not
capable
of
doing
dns.
For
the
vast
majority
of
zone
data
that
winds
up
signed.
The
person
who
authored
the
zone
data
is
not
the
one
who's
applying
the
zone,
signing
keys
to
it
and
getting
the
zone
data
safely
into
the
dns
signer.
E
The
person
who
operates
the
dns-expiner
may
be
perfectly
capable
of
securing
everything
downstream
from
that,
but
the
upstream
side.
You
know
it's
one
of
those
situations
that
we
hope.
Nobody
looks
very
closely
because
garbage
in
garbage
out
so
having
something
that
worked
by
default.
That
gave
transport
layer
security
between
the
authorship
of
the
unsigned
data
and
the
signer
would
make.
E
You
know,
give
me
one
fewer
reason
to
chew
my
fingernails.
So
that's
it
for
me.
I
think
we
need
to
be
able
to
authenticate
both
parties
of
any
dns
transaction
wherever
it
is
in
that
chain.
I
think
tls
bidirectional
auth
is
the
only
reasonable
way
of
doing
that.
I
think
dane.
Tlsa
records
are
sort
of
the
the
reasonable
way
of
getting
tls
keys
distributed
at
scale,
but
you
know
your
mileage
may
vary
and
I
don't
really
care
how
other
people
do
it.
E
B
All
right,
thank
you
for
that
bill.
As
a
reminder,
you
know
not.
Everybody
has
to
agree
that
all
of
these
use
cases
are
for
them,
but
we're
just
trying
to
find
some
of
where
different
people
will
apply
this
resulting
technology.
Dkg.
Do
you
have
a
clarifying
question?
We're
not
going
to
do
much
discussion
or
bashing
about
things
nope?
Okay,
victor.
You
have
a
clarifying
question.
F
Clarifying
one
of
the
things
people
didn't
mention
is
using
dainty
lsa
to
authenticate
ongoing
maintenance
of
dainty,
let's
say
or
decide,
may
have
missed
it.
If
you
didn't
say
it
so
I'd
like
to
see
that
discover
discussed,
because
if
we're
actually
going
to
rely
on
it,
we
also
need
to
be
able
to
keep
it
working.
B
G
B
H
F
Okay,
what
I
mean
by
that
is
that
some
people
are
in
the
habit
of
publishing,
dainty
lsa
records
and
then
not
doing
a
good
job
of
keeping
them
correct
as
they
roll
with
ease
in
part
for
lack
of
sensible
mechanisms
to
make
changes
to
the
dns
in
part.
Other
kinds
of
planning
things
that
I
may
be
able
to
help
them
with
software.
For
but
I'd
like
to
see
name
servers
provide
a
dane-based
mechanism
to
keep
dan
records
updated,
not
just
initially
published.
H
Yeah
no,
this
is
this.
Is
me
back
again
thanks
victor.
I
understand
that
now
I
do
have
a
clarifying
question
about
the
use
cases
here.
The
use
cases
that
were
presented,
I
think,
are
well
motivated.
I
see
the
need
for
something
that
solves
those
problems,
but
I
am
not
entirely
convinced
that
client
authentication
is
the
thing
that's
needed
to
solve
those
problems,
so
so.
B
H
B
Right
that
that
not
all
of
these
cases,
you
know
you
may
want
to
solve
something
differently,
but
this
is
where
people
might
want
to
deploy
it.
This
we're
not
actually
arguing
that
that
this
is
where
we
are
targeting,
but
it's
at
least
a
use
case
to
consider
when
we're
developing
the
protocol
right
so.
H
Typically,
do
it
the
other
way
around
right
where
we
say:
okay,
what's
the
problem
that
we're
trying
to
solve,
and
then
what
are
the
possible
protocols
that
we
could
use
to
solve
it?
And,
let's
figure
out,
you
know
what
what
those
protocols
are
as
someone
who's
seriously
concerned
about
the
tying
dns
queries
to
individual
identities.
H
I
would,
if
we're
going
to
be
talking
about
how
to
solve
some
of
these
problems.
I
mean
I
I
think.
Maybe
this
is
a
I'm,
I'm
more
comfortable
with
the
recursive
resolver
to
authoritative,
authentication
side
of
things
here,
but
the
the
client
like,
if
we're
trying
to
solve
the
problem
of
how
do
we
work
with
a
closed
community
resolver
that
has
special
rules.
H
B
So
that
makes
sense
right.
This
is
not
the
use
case,
or
it's
not
even
a
guaranteed
use
case.
This
is
trying
to
get
models
around
when
we're
talking
about
the
architecture
document
and
framework
that
that
somebody
has
the
opportunity
when
they
start
talking
about
it
later
that
we've,
you
know,
seen
a
presentation
on
what
they're
thinking
ahead
of
it.
You
are
right
absolutely
that
that
we
are
not
going
to
take
this
on
as
the
use
case.
B
B
B
I
I
So,
let's,
let's
jump
in
this,
is
going
to
be
brief
and
it's
not
going
to
go
extremely
deep
into
the
the
protocol.
But
I
do
want
to
talk
about
two
different
approaches
we
might
consider
for
anti-abuse,
and
so
this
is
some
stuff
that
kind
of
came
up.
I
was
doing
some
playing
around
with
some
how
this
might
be
implemented
and
and
at
least
should
be
recorded,
and
we
should
contextualize
the
way
that
we
build
the
final
standards
with
with
this
stuff
in
mind.
I
I
I
We'll
talk
about
some
of
the
challenges
with
getting
client
authentication
to
work
for
https
and
tls
at
scale
for
a
great
number
of
devices
and
we'll
discuss
sort
of
two
sort
of
ten
thousand
foot
view
two
different
approaches
that
we
might
consider
for
anti-abuse
purposes
for
the
protocol,
and
then
we
can
have
a
brief
q.
A
the
problems
specifically
that
we
seek
to
solve
have
to
do
with
using
public
key
based
identity
at
scale
web
applications
and
especially
when
you
start
looking
at
cloud
applications.
I
The
cloud
side
can
get
decoupled
very
easily
because
of
orchestration
tools.
Make
that
easier
to
do
so.
You'll
have
a
you
know.
Your
tls
termination
might
be
happening
on
the
front
of
the
application
in
a
dedicated
load,
balancer
and
then
you'll
have
web
applications
behind
that
you'll
manage
client
configuration.
You
know,
roles
and
and
and
identify
your
association
inside
the
application.
I
But
you
know
when
you
start
it
becomes
very
difficult
to
do
that
with
with
pki,
because
you
may
have
to
synchronize
settings
between
your
application
and
your
load,
balancer
and,
and
that
can
become
problematic,
also
problems
that
you
know
that
we
heard
earlier
with.
You
know
the
problems
of
pki,
where
you
can
have
identifiers
in
one
pki,
may
also
appear
under
another
pki,
and
so
naming
collisions
impersonation
happening.
That.
D
I
I
However,
a
challenge
that
comes
with
that
is
that
you
really
need
to
have
an
allow
list.
If
you
don't
have
an
allow
list,
then
anyone
presenting
a
client
certificate
and
supporting
the
dane
client
id
protocol
could
possibly
trigger
a
dns
lookup
against
maybe
a
maliciously
configured
resolver
that
doesn't
respond
very
quickly.
I
I
I
Some
thoughts
that
come
out
of
doing
some
test
implementations
and
you
know
for
by
way
of
illustration.
This
is
what
that
might
look
like.
You
have
a
the
device
abc.device.example
on
the
left
has
a
certificate
presented
in
dane
or
using
a
tlsa
record
in
dns,
as
it
attempts
to
authenticate
to
the
load.
I
Balancer
load
balancer
is
configured
to
authenticate
any
certificate
to
make
sure
that
the
private
key
is
is
held
by
the
client,
and
then
it
passes
that
through
to
the
application
behind
it,
the
the
application
behind
it
then
make
sure
that
the
the
client
name
that's
coming
through
in
the
post.
Data
is
actually
on
the
list
of
allowed
clients,
and
then
it
checks
that
against
dns
and
then
it
can
allow
it
into
the
application,
and
so
this
makes
it
comparing
this
to
a
situation
where
one
might
have
to
to.
I
You
know
if,
if
the
tls
handshake
is
held
up
to
do
a
dns
query
and
the
client
is
able
to
sort
of
game
that
process
to
have
a
bunch
of
tls
handshakes
open
at
the
same
time,
that
might
be
a
dos
opportunity.
So,
there's
probably
a
really
good
way
to
solve
this
in
the
tls
handshake.
You
know
with
managing
timeouts
or
making
sure
that
there's
an
allowed
clients
list.
I
D
D
D
B
F
I
agree
in
part
with
ben,
but
I
wonder
whether
that
should
be
an
optional
feature.
If
some
server
wants
to
ensure
freshness
of
the
data,
the
client
may
be
shipping
slightly
stale
information
right
subject
to
rrsig
and
all
that,
so
it's
a
it
should
be
possible
to
do
that.
We
may
need
tls
extensions
to
negotiate
which
of
those
scenarios
happens.
J
Yeah,
so
I
think
that's
an
option
we've
discussed
in
the
past.
We
haven't
written
it
down
anywhere,
but
the
possibility
is.
We
have
a
mechanism
that
can
kind
of
do
that
right.
The
tls
chain
extension,
which
victor
is
very
familiar
with
too
only
then
we
would
have
to
kind
of
configure
it
to
go
the
other
way
from
the
client
to
the
server
rather
than
the
server
to
the
client,
which
is
how
it
was
originally
envisioned
to
work.
But
I
think
that's
that's
a
possibility
that
could
be
implemented
as
part
of
the
dance
floor.
B
I
B
I
So
the
the
tls
use
case
is
a
network
access
use
case
and
this
this
could
work
for
wireless
or
wired
access
for
devices
and
so
similar
flow
to
the
last
one,
except
a
little
bit
less
into
the
into
the
protocol.
We'll
talk
about
some
of
the
challenges
with
client,
identity
and
and
then
we'll
look
at
how
dane
maps
to
the
to
the
use
case.
I
I
I
You
know:
guest
guest
wireless
for
instance,
and
so,
if
you
think
about
you,
know
the
the
hoops,
then
we
oftentimes
see
organizations
jumping
through
to
implement
something
that
you
know
that
isn't
too
complicated
for
guest
wireless
access
having
time
down
tokens
and
everything
like
that
for
accessing
a
very
specific
network.
It's
a
lot
of
hoops
and
a
lot
of
automation
that
kind
of
comes
into
play,
and
I
think
that
using
dane
for
client
identity
can
cut
through
a
lot
of
that
unnecessary
complexity.
I
And
so
that's
a
really
good
way
of
you
know
disowning
a
device
that
might
be
compromised
and
and
then
you
also
get
the
benefit
you
know
of
having
a
third
party.
You
know
poor
manufacturer,
providing
an
identity
that
can
then
be
consumed
by
an
organization
and
and
used
without
them
having
to
operate
their
own
pki.
And
so
that's
how
you
kind
of
get
to
a
you
know.
I
A
very
low
friction,
pki
onboarding
process
for
the
network,
and
then
you
have
the
uk
use
case
for
even
leased
devices,
and
so,
if
you
have
one
organization
that
provides
devices
and
to
another
organization,
onboarding
those
to
the
network
becomes
very
easy.
You
can
say:
well,
I
allow
you
know
you
could
even
do
a
wild
card
match.
You
know
to
say:
well
I
allow
any
camera
coming
from
this
vendor
to
access
this
portion
of
my
network
and
things
like
that.
I
I
Then
you
would
install
the
ca
certificate
for
maybe
the
radius
server.
That's
that's
performing
the
the
other
server
side
of
the
tls
connection
we
have
discussed,
you
know
passing
you
know
like
passing
the
dns
chain
in
the
tls
handshake.
That
might
be
a
way
around
having
to
install
a
ca
certificate.
I
I
And
then
your
network
bootstrapping
is
complete,
and
this
is
without
having
to
you
know
to
deal
with
the
process
of
you
know,
signing
a
certificate
or
issuing
you
know
a
device
identity.
It
arrives
with
a
usable
identity
and
getting
it
onto
the
network
is
just
a
matter
of
a
couple
of
configuration
items.
I
The
way
that
this
might
look
is
a
vendor
supplies,
the
implementer
with
devices
and
the
vendor
places
those
device,
certificates
or
public
keys
and
dns
the
implementer
configures
network
access.
It
just
adds
the
the
names
of
the
devices
into
you
know
the
radio
servers
access
list,
for
instance,
and
then
after
configuring,
the
devices
to
point
to
that
access
point
or
whatever.
Then
those
devices
are
able
to
authenticate
and
be
authenticated
by
by
the
radius
server
just
using
the
the
dns
name
to
do
the
certificate
comparison
using
dane.
H
H
Yeah,
so
I'm
trying
to
understand
how
a
client
would
be
expected
to
choose
an
identity
when,
when
doing
when,
when
doing
eep
right,
I
think
the
the
use
case
you
described
is
sort
of
a
distributed,
one
where
the
client
is
using
the
same
identity
to
multiple
providers,
and
I'm
I'm
just
wondering
if
you
have
any
thoughts
about
how
a
client
might
like.
Is
this
going
to
encourage
people
to
always,
you
know,
publish
their
citizen
id
as
they
make
a
connection,
or
do
we
think
that
people
are
going
to
be
able
to
like?
H
I
This
might
be
a
case
where
you
have
multiple
identities,
having
identities
issued
in
this
way
in
a
way
that
doesn't
require
the
implementer
to
to
operate
the
pki,
you
could
purchase
a
number
of
identities
from
a
from
an
identity
vendor
like
this.
So
if
I
go
to
you
know
identity.example
and
I
purchase
you
know
a
number
of
pki
identities
to
install
into
my
device.
Then
I
might
be
able
to
select
one
and,
depending
on
the
network,
I'm
accessing
you
know
if
it's
a
public
public,
wi-fi
network.
I
I
B
F
B
Right,
so
we
will
we
will.
We
will
talk
about
that
when
we
get
to
actually
solving
that
problem,
but
fair
point
right,
all
right,
so
ash,
let's
go
on
to
your
actually
also
for
the
architecture
presentation
right
so,
instead
of
if
you
could
unscreen
share
and
then
use
the
second
button
from
the
left
of
which
is
in
between
the
screen,
share
and
the
hand
icon
to
share
using
that
slide
deck
instead,
assuming
your
slide
deck
is
up
to
that
should
save
bandwidth
for
some
of
our
downstream
users.
Thank
you
very
much
perfect.
I
This
does
include
some
non-chartered
items,
so
we
talk
you
know
later
on
about
what,
if
object,
security
were
part
of
this?
This
isn't
intended.
You
know
to
require
the
working
group
to
go
in
that
direction.
This
is
to
say
in
the
fullness
of
time,
and
if
there
were
interest,
you
know
beyond
a
rechartering.
I
I
Again,
the
problems
with
pki
based
identities:
it's
too
expensive,
smaller
organizations
can't
adopt
it
easily
and,
and
it
doesn't
really
work
very
well
across
organizational
boundaries.
It's
operationally
burdensome
that
comes
along
with
the
expense
you
have
to
have
people
to.
If
you're
doing
it
right,
then
it's
not
cheap.
You
have
to
have
people
maintaining
it
and
protecting
it
and
resource
constrained
organizations
are
left
vulnerable
because
it's
hard
for
them
to
adopt.
I
And
then
the
restrictive-
you
know
I've
already
kind
of
spoken
to
this
before,
but
you
know
getting
trust
to
work
across
organizational
boundaries
and
using
policies
within
the
you
know.
Within
the
context
of
peak,
kicks
is
sort
of
a
challenge,
and
then
you
still
one
pki
does
not
have
a
way
of
preventing
other
pki
from
signing
identities
with
the
same
identifier
and
so
the
challenges
that
come
along
with
that.
I
I
I've
already
talked
about
that,
so,
let's
talk
about
best
practices
for
a
second.
The
cloud
security
alliance
recommends
that,
in
their
summary
guidance
document
for
identity
and
access
management
for
the
internet
of
things,
they
say
that
step
one,
a
you
should
define
a
common
name
space
for
your
iot
devices,
and
that
makes
a
lot
of
sense.
I
think
most
people
would
pretty
much
agree
with
that,
and
so
from
this
decision
point
a
lot
of
architects
will
say
all
right.
I
Well,
I
want
to
use
you
know
this
strategy
or
that
strategy
I
want
to.
You
know,
indicate
the
taxonomy
of
my
device
it's
from
this
vendor
it
does
this
thing
this
is
a
serial
number
or
maybe
it's
just
using
the
hash
of
the
public
key
as
the
identifier,
but
then
you
end
up
when
you're
trying
to
troubleshoot
an
audit.
You
then,
are
describing
trust.
I
I
I
I
The
example
that
I'll
walk
through
is
one
of
let's
say
an
autonomous
car
use
case,
and
the
cars.example
organization
has
autonomous
cars
that
they
allow
to
drive
around
a
you
know.
A
city
and
the
city
is
falls
within
the
jurisdiction
of
gov.example
gov.example,
says
you're
only
able
to
drive
that
on
certain
roads
that
we
say
are
okay
and
you
have
to
report
where
your
cars
are
driving
regularly,
and
so
these
autonomous
cars
also
generate
a
lot
of
data
while
they're
driving.
I
You
know
the
sensor
readings
things
like
that
all
kinds
of
telemetry
pictures,
and
so
they
frequently
need
to
upload
this
stuff
to
a
you
know,
to
a
cloud
storage
platform
for
parsing
and
for
training,
machine
learning
models.
Things
like
that,
and
so
the
cars.example
organization
has
a
relationship
with
isp.example.
I
Isp.Example
runs
a
bunch
of
consumer
premise,
equipment
all
over
the
the
jurisdiction
and
so
they're
able
to
stand
up
a
you
know,
a
wi-fi
ssid,
that's
more
or
less
pervasive
everywhere
these
cars
are
going
to
drive,
and
so
this
allows
the
car
to
or
any
car
in
the
fleet
to
access
these
networks
for
periodically
uploading.
You
know
these
massive
amounts
of
telemetry.
I
In
some
cases,
that's
not
ideal,
but
for
the
purpose
of
simplicity,
that's
how
I'm
going
to
describe
this
use
case
so
car's
driving
down
the
road
and
it
has
the
cars
configuration
says
that
it
knows
that
it
can
authenticate
to
public.isp.example.
Ssid
is
named
public.isp.example
and
and
so
as
it's
driving
along.
It
detects
that
ssid.
If
it
needs
to
upload
information,
then
it's
able
to
do
eat.
I
I
And
it
uses
that
identity
to
perform
eptls
client
authentication
with
multiple
wireless
networks.
Also
sorry,
tls,
client
authentication
with
multiple
wireless
networks,
tls
client
authentication
with
with
its
home
organizations
api
server,
as
well
as
the
report.gov
that
example
mqtt
server
for
delivering
that
sort
of
the
geolocations
and
times.
I
Now,
what
we
see
is
as
possible
protocol
use
cases,
and
these
are
listed
in
the
in
the
architecture.
Document
start
tls
for
for
the
email
ecosystem,
eat,
tls
for
network
access,
https
and
mqtts,
which
are
particularly
useful
for
iot,
sip
and
webrtc,
as
well
as
some
some
use
cases
for
lorawan
object
security.
I
Should
we
decide
to
go
that
direction
after
a
recharter,
jose
and
cozy
make
a
lot
of
sense?
There
are
some
metadata
fields
already
defined
where
this
fits
really
well
and
xmpp.
End-To-End
encryption
seems
like
it
also
might
be
a
really
good
fit
and
client
public
key
discovery
for
ssh
is
something
that
might
be
worth
considering
later
on,
as
well.
I
And
there's
a
we
should
also
bear
in
mind
as
we
do
this,
even
though
this
is
not
going
to
be
defined.
You
know
necessarily
in
our
you
know,
within
the
scope
of
our
charter.
We
should
also
keep
in
mind
that
anti-abuse
efforts
can
really
be
aided
by
having
a
good,
solid
identity,
especially
where
the
identifier
indicates
the
owning
organization,
and
so
you
know
being
able
to
report
misbehaving
devices
using
a
dns
names
using
a
dns
name.
I
You
know
sort
of
takes
out
the
you
know,
so
some
of
the
what
might
be
subjectivity
and
processing
a
you
know
a
distinguished
name
from
a
certificate
or
you
know,
client
common
name.
So
these
are
things
that
we
should
keep
in
mind
for
security's
sake.
I
think
it's
important
to
recommend
dns
over
tls
for
integrity's
sake.
The
stub
resolver
should
be
doing
dns
validation
and
availability
wise.
B
Anyway,
so
q
a
so
anybody
have
questions
about
ash's
presentation,
I
will
say
some
of
those
items
you
know
were
out
of
scope
again
the
year
for
for
the
working
group.
At
this
point,
the
goal
is
to
create
an
architecture
that
may
be
usable,
for
you
know,
lots
of
cases
you
know
like
epls,
for
example,
is
even
I
think,
declared
out
of
scope
initially
and
things
like
that,
but
enabling
it
if
we
want
to
if
the
itf
wants
to
take
on
that
work
in
the
future
is
important.
B
J
So
this,
since
the
architecture
presentation
that
ash
did
talked
about
some
for
future,
looking
use
cases
too,
I
just
wanted
to
go
back
to
the
suite
of
use
cases
that
we
did
discuss
prior
to
that
and
the
one
that
I
know.
I
mentioned
this
on
the
chat
to
the
one
that
I
noticed
that
was
conspicuously
absent
was
the
smtp
transport
security
use
case,
and
I
was
wondering
if
I
could,
if
we
could
volunteer
victor
to
say
just
a
few
words
about
that.
Just
to
you
know,
make
sure.
D
B
F
In
fact,
they're
trying
their
hardest
to,
in
most
cases,
to
convince
the
server
that
they're
legitimate
and
should
not
be
spam
filtered,
and
it
would
sure
be
nice
to
be
able
to
not
only
have
audit
trails
in
smtp
received
headers
that
show
you
that
a
message
came
from.
You
know
a
source
that
you
can
trust,
but
also
to
be
able
to
apply
a
reputation
to
instead
of
ip
addresses
to
pre-trusted
domains.
F
F
F
F
You
might
start
with
dns
to
you
know,
authenticate
yourself
to
some
point
in
the
network,
but
having
achieved
that,
having
authenticated
to
some
sort
of
authentication
provider,
we
then
I
need
to
think
about
whether
that's
the
whole
story
or
whether
we
you
know
federate,
you
know,
sort
of
in
in
some
way
trust
brokers
of
various
sorts.
That
can
then
authenticate
you
to
other
networks
by
other
means
than
than
this
mechanism
you
know
is:
is
there
a
more
complete
architecture
here?
F
One
of
the
things
that
I
had
been
looking
at
but
never
had
cycles
to
do
was
in
fact
bootstrapping
cross-realm
kerberos,
with
dane,
which
would
allow
kdc's
to
authenticate
each
other
and
then
make
it
possible
to
have
a
kerberos
mesh,
that's
kind
of
internet
scale
by
using
dane
between
the
kdc's,
but
then
user
authenticates
to
local
kdc,
not
to
some
remote
entity
and
kdc's
have
wonderful
things
in
terms
of
you
know.
Probably
dan
gilmore
will
be
happy
to
hear.
Kdc's
can
support
anonymous
credentials.
F
If
the
architecture
is,
you
know,
single
party
all
the
way
to
the
end,
and
this
is
a
much
bigger
problem
of
course,
but
I
think
it's,
the
more
ambitious
architecture
has
some
merit.
We
ought
to
think
about
what
is
the
full
life
cycle?
Is
there
a
federation
story
here,
in
addition
to
dns
being
federated
in
terms
of
trust
and
so
on,
being
federated
as
well?
G
Thank
you.
So
this
is
related
to
the
architecture.
Draft.
There's
a
question
about
scalability.
You
mentioned
that
a
client
identity
zone
is
essential
for
actually
authenticating,
but
in
the
event
let's
say
the
client
identity
zone
goes
offline
or
it's
unavailable
and
you're
not
able
to
authenticate.
I
I
that's
that
is
certainly
worthy
of
discussion.
We
didn't
put
that
in
the
architecture
document
for
fear
that
it
would.
That
could
be
a
whole
other
sort
of
area
of
of
study
that
could
be
addressed,
maybe
by
a
caching
strategy
on
the
server
side
of
the
tls
connection,
whatever
application
that
happens
to
be,
but
it's
you
know
is,
if
that's
worth
pulling
in
the
architecture
document,
I'm
happy
to
and
getting
some
discussion
around
it
because
having
having
a
good
fallback
mode
could
be
useful.
B
B
J
J
We've
gone
through
a
little
bit
of
this
already
during
the
boss
sessions
leading
up
to
this
point,
so
some
of
you
may
have
seen
bits
and
pieces
of
this
already,
but
now
that
we
finally
have
a
working
group,
I
think
it's
useful
to
kind
of
rehash
and
refresh
everyone
just
to
make
sure
we
all
have
a
common
understanding.
So
we
have
two
drafts
listed.
J
J
The
goal
is
to
be
able
to
authenticate
the
client
side
of
a
tls
connection,
with
dane
today,
as
many
of
you
may
know,
dane
is
used
primarily
to
authenticate
tls
servers,
so
this
mechanism
is
about
extending
it
to
do
client
authentication
too
a
little
bit
about
the
history.
These
drafts
were
originally
written,
quite
a
while
back.
J
But
then
the
dane
working
group
shut
down
because
it
had
finished
its
original
charter
of
work,
and
this
item
wasn't
on
that
charter
and
kind
of
the
authors-
didn't
really
have
the
time
or
energy
to
continue
pursuing
it,
but
the
original
target
use
cases
at
that
time
were
iot
device,
authentication
and
and
also
authenticating
clients
in
smtp
transport
security.
I
think
those
use
cases
are
still
valid
as
you've
heard
today
and
it
looks
like
there
are
several
more
application
areas
that
may
benefit
from
these
protocols
to
the
next
slide.
J
J
The
tls
server
sends
a
certificate
request
message
in
the
handshake
and
the
client
in
its
certificate
message
includes
a
dane
client
id
extension
I'll
describe
that
extension
in
the
next
slide.
The
tls
server
then
extracts
the
client's
identity
from
the
presented
certificate
and
then
obtains
the
dns
tlsa
record
authenticates
its
signature
and
validates
its
sort
of
record
data
against
the
certificate
or.
D
J
Okay,
so
there
is
also
a
proposed
new
tls
extension
for
conveying
a
client
stain
identity.
So,
generally
speaking,
the
tls
server
can
find
the
client
name
in
the
client
certificate
itself.
So
why
would
we
need
this?
Well,
it
has
a
couple
of
purposes
first,
to
signal
support
for
this
protocol,
which
can
be
done
by
the
client
just
sending
an
empty
extension.
J
So
technically,
both
the
server
and
client
could
signal
this
capability
advertisement.
It's
particularly
useful,
though,
for
the
client
to
do
this,
because
then
it
can
communicate
to
the
server
that
it
has
a
date
record
that
it
wishes
to
be
authenticated
with
and
in
environments
that
may
support
a
mixture
of
clients.
J
We
can
ensure
that
the
tls
server
attempts
to
do
data
authentication
only
for
the
clients
that
are
suitably
configured
to
make
that
possible
right,
and
secondly,
this
extension
can
be
used
to
convey
the
actual
client's,
dns
identity
and
maybe
their
domain
name
in
cases
where
it
may
be
required.
So
there's
two
cases
where
it's
probably
required.
The
first
is
if
clients
are
using
raw
public
key
authentication,
that's
rfc
7250.
J
J
So
the
client
has
to
communicate
that
in
some
manner
and
this
extension
can
be
used
to
do
that.
Another
case
is
if
the
client
certificate
has
multiple
identities
in
it,
and
we
want
to
be
able
to
kind
of
surgically
tell
the
server
which
specific
identity
has
a
dane
tlsa
record
associated
with
it
to
kind
of
minimize
the
amount
of
unnecessary
work
the
server
might
otherwise
have
to
do
to
hunt
down
which
of
those
identities
has
a
date
record.
J
So
I
also
want
to
make
a
note
about
the
privacy
implications
of
this,
this
extension,
which
was
kind
of
brought
up
when
we
originally
talked
about
this
drafts,
because
we
are
potentially
sending
the
client
identity
in
the
extension.
So
when
we
first
started
this
work
in
2015,
we
didn't
really
have
a
good
solution
to
privacy
protection
at
the
time.
But
now
we
have
tls
1.3,
which
does
address
this
so
in
tier
in
the
tls
1.3
version
of
this
protocol.
J
Sort
of
the
record
data
format
is
exactly
the
same
as
defined
in
rfc
6698,
detain,
spec.
What's
different
is
the
record
owner
name
format,
which
has
to
be
adapted
to
something
more
suitable
for
client
names,
so
the
spec
currently
proposes
two
formats
that
we
think
have
wide
applicability,
but
I
think
we
recognize
that
applications
could
choose
something
else
if
they
needed
to,
and
the
draft
is
trying
not
to
be
prescriptive
on
this
point.
J
So
in
the
original
version
of
the
spec
in
going
back
to
2015,
we,
we
had
actually
proposed
the
use
of
different
subject:
alternative
name
types,
so
there's
something
called
srv
name,
which
is
described
in
49.95,
which
supports
kind
of
like
a
more
flexible
way
to
encode
application,
specific
identifiers.
But
in
the
end,
we,
you
know
kind
of
assess
that
nobody
really
uses
that
in
the
ecosystem
at
all
and
we
kind
of
took
it
out
and
instead
now
we
have
this
format
next
slide.
Please.
J
J
And
here's
a
general
diagram
of
the
protocol
protocol
flow,
it's
just
some
minor
enhancements
to
the
typical
tls
client
certificate
authentication
flow.
So
I've
just
pointed
out
the
main
deltas
in
red
here,
namely
that
the
dane
client
id
extension
is
sent
along
with
the
client
certificate
from
the
client
to
the
server
and
that
the
tls
server
needs
to
perform
a
lookup
of
the
client
state
and
tlsa
record
and
validate
the
client's
certificate
of
public
key
against
the
contents
of
that
authenticated
record
and
next
slide.
J
I've
also
tried
to
annotate
the
tls
1.3
handshake
message
flow
with
the
new
protocol
elements.
This
should
be
fairly
self-explanatory
to
folks
familiar
with
the
tls
protocol,
but
so
this
is
this
slide.
Is
the
vanilla
tls
1.3
handshake?
So
let's
move
on
to
the
next
slide
and
in
red,
so
this
part
is
optional.
So
originally
this
wasn't
in
the
spec.
J
J
And
lastly,
what
the
tls
server
then
has
to
do
is
get
the
client's
identity.
Look
up,
the
tlsa
are
set
authenticated
and
match
it
against
the
client
certificate
of
public
key,
so
in
the
draft
is
currently
written,
requires
the
tls
server
to
do
this
in
band
in
in
the
tls
handshake.
But,
as
has
already
been
mentioned
today
in
previous
conversation,
that's
not
the
only
possibility.
J
We
could
envision
the
client
kind
of
conveying
building
its
full
day
and
authentication
chain
and
sending
it
along
in
a
tls
extension
to
the
server.
The
reason
we
hadn't
originally
put
that
in
the
draft
is
we
were
concerned
that
one
of
the
prominent
use
cases
for
this
protocol
was
iot
devices
which
could
potentially
be
constrained,
and
that
may
be
too
high
of
complexity
and
implementation
bar
for
them.
J
But
you
know
since
we're
discussing
it,
we
can
certainly
have
a
debate
about
whether
or
not
that
enhancement,
whether
it's
optional
or
not,
should
go
into
into
this
protocol
and
next
slide.
Please
yeah,
okay,
so
I'll
stop
here
for
a
discussion.
One
parting
question
before
that
to
the
chairs,
and
the
working
group
generally,
though,
is:
are
these
drafts
suitable
as
protocol
building
blocks
for
dance?
And
if
so,
you
know
when
should
we?
B
J
Yeah,
so
I
mean
I
was
when
we
were
originally
doing
this
work.
Tls
1.3
didn't
exist
right,
so
we
had
to
kind
of
support
it
until
s
1.2
and
I
had
to
grapple
with
the
with
the
with
the
privacy
question
a
little
bit
harder.
Now
that
we
have
tls
1.3,
I
guess
it
depends
on
you
know
the
use
case
and
what
kind
of
deployed
field
of
of
client
devices
we're
dealing
with
right.
J
So
if
it's
the
case
that
it's
like
green
field
applications
where
tls
1.3
is
omnipresent,
then
yeah,
I
think
we
could
easily
do
that,
but
it
may
not
be
the
case
in
certain
environments
right.
So
I
think
that
question
I
don't
know
the
answer
that
question.
I
think
you
would
need
some
some
research
to
see.
You
know
which
sort
of
environments
we're
trying
to
apply
these
solutions
to.
H
H
H
H
J
J
H
So
that's
just
just
a
wrinkle,
that's
worth
thinking
about
the
second
thing
that
when
I'm
looking
at
this,
it
occurs
to
me
that
if
this
is
being
done
in
a
situation
where
you
basically
already
know
your
peer,
then
you
have
some
out
of
like
you
have
no
other
way
to
authenticate
yourself.
Besides
this
client
search,
you
could
there's
no
necessary
reason
for
an
extension
for
this
at
all.
H
H
J
So
yeah
so
daniel,
I
I
agree
there
are
so
there
are
many
situations
where
you
may
need
not
need
this
at
all.
So
there
are
situations
where
you
might
know
right
if
you
have
a
like
a
kind
of
like
a
mixed
mode
field
of
tls
clients,
and
some
of
them
can
do
dane
authentication
some
of
them.
Can't
you
want
a
signal
from
the
tls
client
to
the
server
that
I
have.
J
D
H
J
H
D
H
J
K
So
you
know,
regardless
of
whether
I'm
using
tls1213,
I'm
going
to
have
to
update
my
stack
here
with
this
extra,
dane
kind
of
and
logic,
and
so
you
know
are
we
saying
we
have
circumstances
where
we
can
update
the
code
to
do
a
slightly
better
or
fancier
tls
one
two
processing.
But
there
are
certain
clients
where
you
know.
While
we
can
make
that
change,
we
can't
make
the
stack
upgrade
to
1.3.
J
Yeah,
so
that
I
don't
know
you
may
very
well
be
right,
roman,
so
I
was
envisioning
a
situation
where
you're
right
stats
have
to
be
upgraded
regardless
to
use
this
mechanism,
but
it
may
you
know
there
may
be
situations
I
was
imagining.
I
could
be
wrong
where
it's
easier
to
just
enhance
the
tls
1.2
stacks
to
do
this
rather
than
upgrading
whole
hog,
everyone
to
tls
1.3.
First,
I
could
be
wrong
about
that.
Maybe
maybe
that's
not
a
concern
and
we're
looking
more
at
greenfield
tls
1.3
deployments.
B
B
D
D
J
J
D
D
B
F
F
But
it
would
need
to
do
it
periodically
and
well
in
advance
of
the
expiration
of
the
resource
record
signatures
on
this
data
that
it
obtains
at
some
point
and
needs
to
again
have
a
fresh
copy
of
every
realistically
every
few
hours
I
signed
records
for
one
hour.
The
I
don't
know
if
that's
enough,
but
yeah.
J
J
J
D
F
F
Ca
names
are
subject,
dms
and
subject,
dns
have
components,
you
know
ous
and
countries
and
all
that
kind
of
stuff,
and
there
could
certainly
be
a
format
for
the
subject.
The
ends
of
the
case
that
the
server
requests
that
essentially
implies
a
dns
namespace
and
could
even
you
know,
say
you
know.
I
want
a
client
credential
issued
by
essentially
gained
from
this
domain,
and
that
could
be
a
form
of
you
know,
x,
509
name.
All
we
need
to
do
is
get
an
o
it.
You
know
it's
a
free.
F
We
could,
you
know,
write
one
down
on
a
napkin
and
you
know,
and
then
we
have
a
way
of
signaling
that
you
want
if
that
name
component
appears
in
the
certificate
list
from
the
server.
That
means
that
the
server
is
willing
to
accept
dane
identities
from
this
portion
of
the
dns
tree
and
similarly
the
client
certificate
could
in
at
least
in
the
use
cases
where
the
tlsa
records
are
of
the
dane
ee
variety
right.
Three,
you
know
just
just
carry
a
public
key.
F
Essentially,
the
client
can
mint
its
own
certificate
on
the
fly
right,
because
all
it's
presenting
is
a
public
key
and
then
it
can
embed
in
that
certificate.
Any
name
it
chooses
at
that
point
in
time
or
has
chosen
recently,
so
it
can
again
signal
its
name
in
a
freshly
baked
cert
to
indicate
you
know
I
am
so
and
so
at
such
and
such
a
domain,
so
there's
lots
of
opportunities
to
move
the
signaling
from
extensions
into
bits
of
you
know
certificate
like
metadata
that
we
could
consider,
if
appropriate,.
B
F
And
at
some
point
I
may
think
harder
and
deeper
about
the
role
of
an
architecture
in
which
we
have
things
like
kdc's
mediating,
multi-hop
interactions
here
and
then
we
potentially
take
advantage
of
existing
protocols.
There
maybe
even
get
advantages
in
terms
of
post
quantum
and
so
on.
If
kdc's
negotiate
symmetric
keys
with
each
other
periodically,
then
we
can
use
symmetric
keying
for
bunches
of
this
anyway,
all
kinds
of
interesting
stuff
to
research
but
yep.
B
B
L
J
B
B
Okay
dog
point:
nope
nobody's
joining
the
queue.
So
the
next
question
I
think
to
the
participants
in
general
is
at
what
point
we
want
to
consider
adopting
these
documents.
I
believe,
schumann,
that
you
have
said.
You
believe
that
the
two
solution
documents
are
functionally
ready.
If
the
working
group
feels
that
that
is
the
case,
is
that
correct.