►
From YouTube: IETF111-DANISH-20210727-1900
Description
DANISH meeting session at IETF111
2021/07/27 1900
https://datatracker.ietf.org/meeting/111/proceedings/
A
And
ash,
while
we're
waiting,
did
you
want
to
share
your
own
slides
or
do
you
want
me
to
share
your
slides?
Either
way
is
fine
with.
B
Me
I
can
share
my
slides
if
that's
okay,.
A
A
All
right,
let's
go
ahead
and
get
started.
We
have,
I
guess,
71
people
in
the
room.
That
seems
roughly
about
right.
A
So
welcome
to
the
danish
buff,
the
second
danish
buff.
Really,
this
is
ietf
111.
We
had
one
at
110
as
well,
it
is
july
and
we
are
not
in
san
francisco
agenda.
We
did
modify
it
a
little
bit
if
somebody
looked
at
the
agenda
before
today.
Basically
we
had
the
note.
Well,
we
had
the
working
group
story
so
far,
which
is
really
where
we,
where
we
are
with
respect
to
buff
two
and
then
we're
going
to
repeat
portions
of
the
technology
pitch.
A
You
know
why,
where
the
problems
face
is
and
ash
will
go
over,
that
for
a
good
20
minutes
or
so
with
some
it's
a
little
bit
shorter
than
last
time
and
some
new
examples
that
I
think
hopefully
more
clearly
spell
out
exactly
what
we're
aiming
for
here
and
then
we'll
talk
about
the
current
state
of
chartering
and
and
where
that
is
and
we'll
come
back
to
that
at
the
time
and
then
we'll
have
an
open
mic
and
any
other
business
which
will
include.
A
Are
there
enough
participants
in
order
to
in
order
to
actually
carry
this
work
forward,
and
that's
where
we
really
need
to
hear
from
people
one
of
the
reasons
why
we
are
having
the
second
office,
because
we
really
didn't
get
enough
responses
for
people
that
agreed
that
the
charter
was
something
that
they'd
be
interested
in
working
on,
or
at
least
seeing
accomplish.
A
A
Administrative
there's,
a
comm
d
for
note,
taking
and
michael,
is
trying
to
take
notes
and
via
jabber
scribe.
Please,
hopefully,
if
you
could
help
him
out,
that
would
be
highly
beneficial.
This
probably
won't
require
a
huge
amount
of
notes.
So
it's
an
easy
one
to
take
up
if
you're
new,
to
note
taking
and
want
to
just
see
what
it's
like
and
co-md
is
a
whole
lot
of
fun
to
play
with
meek.
A
Echo
will
automatically
do
blue
sheets,
so
there's
nothing
to
sign
and
jabber
is
at
that
jabber
console
or
you
can
click
on
the
little
talk
button
on
on
meet
echo,
which
has
jabber
nicely
integrated.
A
We
just
hadn't
gotten
around
to
writing
a
charter
and
it
looked
like
the
problem
was
well
understood.
Last
time
there
was
generally
a
lack
of
disagreement
or
you
know
agreement.
There
wasn't
a
whole
lot
of
discussion.
There
was
a
general
consensus
that
it
did
look
like
a
good
problem
to
tackle,
but
the
discussion
occurred
later
when
we
started
putting
the
charter
up
in
the
last
couple
of
months.
A
It
was
originally
written
in
april
and
may
and
it's
been
trimmed
a
lot
after
various
people
had
terminology
issues
and
trying
to
very
clearly
spell
out
exactly
what
problem
space
we're
trying
to
tackle.
Yeah
robin,
please
do
go
help
michael
that'd
be
helpful
if
you,
if
you
can
so
the
revised
charter,
did
not
get
a
lot
of
agreement
or
disagreement.
It
was
sort
of
you
know
silent,
and
that
is
where
we
really
need
to
hear
from
everybody.
A
So
I'll
reiterate
that
a
few
times
today,
if,
if
we
don't
hear
enough
interest,
then
the
iesg
will
probably
make
the
decision
not
to
hold
not
to
have
a
working
group.
So
if
you're
interested
in
in
this
space,
you
know,
regardless
of
whether
you
want
to
actually
you
know,
participate
actively
and
write
text
or,
if
you
just
want
to
review
or
if
you're
just
thinking
it's
a
good
problem
to
be
solved.
A
We
want
to
hear
from
you
at
the
end
of
the
day
so
with
that
we're
not
going
to
go
into
the
charter
now.
So
this
is
the
charter.
Slides
are
next
and
we'll
break
apart
the
charter
later,
but
for
now
we're
actually
going
to
turn
over
to
ash.
Who
is
going
to
give
a
background
presentation
on
you
know
where
we
are
from
the
technology
pitch
point
of
view,
so
ash
you
can
request.
You
have
to
push
push
the
request,
share,
screen
button.
I
think,
and
then
I
approve
you.
A
D
A
B
Perfect,
all
right,
so
I'm
going
to
try
and
limit
this
to
about
20
minutes.
So
we
have
plenty
of
time
to
talk
about
the
charter.
There's
some
technical
detail
in
here
that
we
can
go
back
and
reference
if
we
need,
but
some
of
the
the
deeper
technical
slides
we
may
gloss
over
so
to
all
right.
Let's
define
the
problem
space.
The
challenges
that
we
see
in
the
iot
ecosystem
is
that
we
have
private
pki
everywhere
and
establishing
trust
between
entities.
B
You
know
one
pki
from
you
know,
naming
its
entities,
you
know
to
conflict
with
what
you
find
in
another
pki
and
discovery
apis
for
certification
authorities
for
ca
and
entity
certificates
are
oftentimes
proprietary,
and
so
you
end
up
with
what
kind
of
feel
is
an
over
consolidation
and
that's
to
prevent,
naming,
collisions
and
ease
trust
challenges
where
you
just
on
board
everything
to
the
same
organizational
pki,
that's
pretty
limiting,
and
so
what
we
need.
You
know.
Private
pki
needs
a
broadly
useful
lookup
mechanism,
and
specifically,
we
need
that.
B
B
Ideally,
it
will
also
make
credential
rotation
easier
and
it
should
work
well
for
constrained
platforms
because
we're
talking
about
iot-
and
you
know,
storage,
you
know
in
megabytes
and
very
limited
limited
compute
power,
and
so
what
we
want
to
do
is
to
create
you
know
safe
bridges
between
you
know
what
you
may
refer
to
these
as
islands
of
trust
or
pki
domains
digging
into
the
islands
of
trust
problem.
B
So
the
ca
bundle
is
what
makes
web
pki
work
well
without
the
ca
bundle,
then
web
browsing
would
really
be
pretty.
You
know
pretty
painful,
and
so
that's
really
what
we
have
for
client
identity
in
iot.
It's
just
a
bunch
of
private
pki,
and
it's
not
you
know,
particularly
interoperable
from
a
trust
standpoint.
B
We
don't
really
want,
we
really
don't
want
to
move.
You
know
toward
getting
everything
attached
to
web
pki
for
client
identity.
It
wasn't
really
built
for
that,
and
that
brings
a
whole
host
of
other
problems,
and
so
how
do
we
otherwise
get?
You
know
agreement
on
iot
routes
of
trust,
and
so
what
we
have
now
is
that
ends
up
being.
B
You
know
a
distribution
of
ca,
certs
or
consolidation
onto
the
same
organizational
pki,
because
when
you
have
multiple
pki
again
you
have
naming
collisions
and
consolidation,
sometimes
favored,
and
once
you
have
the
entire
organization
on
the
same
trust
island,
then
getting
communication
or
establishing
trust
across
organizations.
You
know
from
machine
to
machine
becomes
difficult.
So
what
we
end
up
with
are
sub-optimal
information
flows
right.
B
So
this
here's,
a
diagram
of
a
sensor
and
an
actuator
participating
in
the
same
activity,
but
their
information
flow
goes
up
to
a
hosted
platform,
because
each
of
those
has
has
an
identity
issued
by
different
different
pki,
and
so
this
is
sort
of
like
what
you
see.
You
know.
What
we
used
to
refer
to
in
telecom
is
from
boning,
where
you
have.
You
know
two
endpoints
that
are
communicating
through
a
sub-optimal
path.
B
B
So,
let's
talk
about
initial
work
areas
for
this
efforts.
This
is
one
of
the
slides
we're
going
to
split
going
to
skip
and
go
back
to.
If
we
need
to
go
into
detail,
tls
client
authentication
with
dane
the
original
drafts
were
developed
in
mid
2015
by
schumann
and
victor,
and
we
refreshed
those
later
last
year
to
sort
of
encompass
what
we
think
is
a
really
good,
a
really
good
way
to
to
bring
this
into
the
iot
space.
The
target
use
cases
for
this
are
iotp.
I
iot
and
smtp
transport
security.
B
These
two
drafts,
one
of
them,
covers
you,
know,
presenting
a
client
certificate
using
dane
tlsa
records
and
the
other
draft
covers.
You
know
changes
to
the
tls
protocol
to
enable
dane
client
authentication
and
so
the
you
know,
the
protocol
summary.
The
client
has
a
dns
name.
You
know
at
that.
You
know
tls
a
records
you
know
represented
in
dns
at
that
name,
you
know,
carry
a
you
know,
a
public
key.
The
device
has
the
private
key
and
a
certificate
can
be
found
in
dns
that
binds
the
public
key
to
the
domain
name.
B
Also,
support
for
using
a
raw
public
key.
The
tls
server
sends
a
request
message.
You
know
in
the
handshake
and
then
when
it
gets
the
response.
It
unpacks
that
pki
that
that
certificate
and
pulls
the
entity
name
out
of
the
certificate,
uses
that
to
authenticate.
B
You
know,
what's
presented
in
dns
at
that
entity,
name
the
the
tls
extension
sort
of
going
into
more
into
the
specifics.
B
You
know
we
have
a
way
of
the
client
needs
to
be
able
to
signal
to
the
server
that
it
intends
to
authenticate
using
dane
and
then
the
server
when
it
requests
that
when
it
gets
the
response
from
the
client
and
tls
1.3,
this
is
carried
in
the
encryption
in
you
know,
in
an
already
established
encrypted
session,
the
with
tls
1.2,
there
are
some
privacy
considerations
that
we
should
should
consider
the
we
propose
a
couple
of
different
naming
conventions.
B
They
are
not
exclusive
and
they
actually
work
together.
The
first
one
we'll
talk
about
is
a
service,
specific
client
identity,
and
that's
where
you
have
perhaps
multiple
identities
associated
with
the
same
entity
and
one
of
those
in
this
you
know,
as
represented
on
the
slide,
might
be
an
smtp
client.
B
B
Looking
at
you
know,
specifically
the
iot
use
case
here.
We
have,
you,
know
the
organizational
domain
and
the
the
device
name
separated
by
an
underscore
device
label,
and
what
this
allows
us
to
do
is
it
allows
us
to
delegate
that,
because
we
expect
that
you're
going
to
want
to
tie
that
dns
zone
to
a
certification
authority
right
via
that
proprietary
api
and
then
allow
dns
to
become
that
lookup
mechanism
for
that
private
pki.
That's
managed
in
another
system
that
carries
certain
security
considerations.
You
don't
necessarily
want
to.
B
You
know
to
have
that
sort
of
other
dns
zones
may
not
have
that
kind
of
churn
right
and
so
being
able
to
have.
That
delegation
point
gives
us
something
visual
where
we
can
see
that
okay,
we
have
devices
under
this
point
in
the
dns
tree.
It
prevents
you
know:
web
pki
from
issuing
recognized
pki
to
entities
represented
under
that
point,
because
there's
an
underscore
label
and
it
sort
of
gives
us
a
way
of
kind
of
compartmentalizing.
B
And-
and
this
is
what
a
record
might
look
like,
so
this
would
be
you
know,
a
sensor
device
with
a
you
know,
with
its
public
key
hash,
represented
in
a
tlsa
record,
I'm
going
to
skip
some
of
these
more
detailed
slides,
and
so
what
we
hope
to
get
out
of
this
is
to
simplify.
You
know:
pki
management.
You
should
be
able
to
rotate
your
own
client
certificates
when
you
want
via
dns
and
ttl,
is
really
the
only
delay
there.
B
And
then
you
know
when
you
start
looking
at
attribution
for
for
client
authentication,
it
becomes
a
lot
easier
because
you
have
a
dns
name
that
you
can
work
from,
and
you
know
you
can
tie
that
to
a
real
world
entity
or
organization
behind
the
the
dns
name
and
who
owns
it.
B
So
trust
can
happen
like
this
vendor
one
and
vendor
two
can
then
you
know
cross
communicate.
You
just
need
to
describe
trust
using
dns
names
and
you
take
the
whole
needing
to
contextualize
using
you
know
private
pki,
out
of
it.
B
An
architecture
document
is
also
proposed
and
the
architecture
dock
describes
how
dane
device
identity
fits
into
various
use
cases.
This
is
not
the
scope
for
this
document
is
not
as
well
defined
as
the
as
the
existing
drafts.
You
know
for
client
id
entity
and
client
certificate,
the
tls
updates.
B
So
I
expect
that
we'll
have
some
discussion
on
this
in
a
few
minutes,
but
some
of
the
talk
topics
that
we
would
propose
for
this
is,
of
course
we
need
to
have
some.
B
B
There
are
certain
use
cases
that
we
can
get
immediate
benefit
from
so
etls
radsec
things
where
we,
you
know
being
able
to
use
tls
client
certificates
can
can
be
enabling
for
other
for
other
standards,
decoupled
application,
authentication.
B
So
there's
in
our
last
boss
session,
we
had
a
great
series
of
slides
from
you
know
that
describes
how
some
of
the
challenges
and
establishing
trust
between
components
in
the
lorawan,
broader
application
ecosystem
could
be
simplified
if
we
could
just
use
dain
and
and
of
course,
the
client
server
authentication,
which
is
what
we're
talking
about
here,
how
this
might
fit
into
you
know,
how
does
a
tls
authentication
middleware
component
behave,
and
you
know
beyond
that?
B
What
is
it,
how
does
it
communicate
or
you
know,
maybe
what
headers
would
it
use
to
communicate
to
the
application
behind
it?
You
know
who
is
who
has
performed
tls
plan
authentication
using
day,
there's
an
object,
security
use
case
which
we
could
include,
or
we
could
exclude
and
just
update
the
document.
If
we
decide
to
recharter
to
cover
that
and
then
there's
sort
of
the
outstanding
question
of,
would
this
be
better
as
an
update
to
76.71,
or
should
this
be
a
separate
document.
B
So,
covering
sort
of
a
brief
use
case
of
cloud
service
authentication
the
the
desired
behavior
is
you
know
for
this
application?
We
want
to
use
supplier
provisions
day
night
entities
for
tls
authentication
and
the
this
would
allow
us
to
pick
best
breed
suppliers
and
use
supplier
issued
pki
identities
safely.
B
The
challenges
that
we
hope
to
mitigate
are
you
know
all
on
boarding
all
of
your
manual
manufacturer,
ca.
Certs,
you
know.
If
you
want
to
use
supplier
issued
pki,
then
you
have
to
manage
those
individual
supplier
ca
certificates,
in
whatever
application,
they're
authenticating
against
that
sort
of
a
challenge.
B
Authorization
becomes
complicated
because,
as
you
extract
those
names
from
certificates,
they
also
have
to
be
presented
to
the
application
within
the
context
of
the
pko
that
authenticated
them,
and
so
that
presents
some
challenges
as
well.
You
know,
especially
with
cross
ca,
impersonation,
that's
why
you
have
to
really
get
that
right
with
dane
klein
identity,
the
client
name
is
bound
to
a
dns
name
and
you
don't
have
to
onboard
devices
to
an
organizational
pki.
B
Authenticating
middleware
can
then
just
use
dns
to
authenticate
those
client
entities,
and
you
don't
have
to
make
sure
that
that
authenticating
middleware
has
access
to
all
of
those
trust
anchors.
You
know
from
the
various
pki
that
you
might
have
in
a
traditional
client-off
situation
and
the
client
identity
can
be
represented
by
the
authenticating
middleware
to
the
application
behind
it,
using
http
headers
so
diagrams
to
illustrate
this
the
with
traditional
pki.
B
You
know
are
owners
and
operators
of
taxi
services
as
well
as
commercial
vehicles
and
as
the
you
know,
they
receive
new
vehicles
from
mfr.example
and
those
new
vehicles
already
contain
dash
cams
with
pki
identity
from
the
manufacturer,
and
then
the
you
know
they
may
send
some
vehicles
off
to
taxi.example
for
customization,
and
then
they
come
back
from
taxi.example
with
dash
cams
with
their
own
pki.
B
But
in
order
to
you
know,
eliminate
the
possibility
of
naming
collision
and
the
challenges
of
managing
multiple
pki
with
storage.example.
B
You
know
who
manages
all
of
their
uploaded
dash
cam
videos
they
onboard
to
their
own
pki
through
whatever
process
and,
and
that
represents
some
overhead
some
time
consumed,
that
we
think
that
we
can
eliminate
in
a
lot
of
use
cases
the
challenges
with
this.
You
know,
in
addition
to
the
time
that
it
takes
the
time
and
effort
and
automation
that
it
takes
to
do
that
private
pki,
onboarding
process.
B
On
the
api
side
of
storage.example,
you
also
have
the
challenge
of
when
you
authenticate
those
entities
you
have
to
authenticate
those
clients
within
the
context
of
their
own
pki
or
the
in
associating
those
you
know
not
just
the
entity
name
but
the
pki,
with
the
customer
account
and
in
a
multi-tenant
platform.
This
can
get
a
little
bit
complicated.
B
B
Then
you
can
take
those
and
it
becomes
a
matter
of
you
know
from
the
implementer's
perspective.
They
just
need
to
keep
up
to
date,
a
list
of
the
devices
allowed
to
upload
to
their
account
at
api.storage.example
and
api.storage.example
when
it's
authenticating.
Those
clients
really
only
has
to
has
to
perform
the
action
of
authenticating
against
those
dane
dns
records,
and
it
doesn't
have
to
have
you
know
all
of
that:
private
pki,
accessible
to
authenticate
clients,
and
so
the
authenticating
middleware
within
api.
B
You
know
fronting
api.storage.example,
we
think
can
be
simplified,
so
it
becomes
easier
for
onboarding
for
fleet.example
and
the
application
code,
ideally
on
api.storage.example
becomes
a
lot
easier
too
again:
scope
of
work
thing
for
client
identity.
We
discussed
this
a
few
minutes
ago
and
those
two
are
currently
published
and
we've
iterated.
On
those
a
few
times.
We
have
not
published
a
draft
yet
for
the
architecture
document
and
then
the
appendix
and
links
these
will
be
accessible
later.
B
So
that's
that's
what
I've
got
and
I
can
hand
this
back
to
to
wes.
Okay,
great
questions
we'd
like
to
revisit
any
of
the
slides.
A
Yep,
so
I'm
going
to
shift
to
my
slides,
though
so
we
can
look
at
the
charter
text,
but
other
than
that
we
should,
or
I
can
pull
yours
up
again
too.
If
people
want
to
dive
in,
I
guess
the
first
thing
to
do
is:
does
anybody
have
clarifying
questions
for
ash
right?
So,
let's
not
go
into.
A
This
is
the
wrong
approach.
This
is
the
right
approach.
This
use
case
is
wrong.
My
use
case
is
better.
This
is
the
wrong
technology.
I
only
want
to
know.
Is
there
clarifying
questions
of
stuff
that
people
didn't
understand
we'll
get
to
the
rest
of
it
in
a
minute.
A
F
Sure
I
hope
it's
a
clarifying
question.
I
must
I'm
wondering
whether
any
of
the
manufacturers
are
actually
inclined
or
interested
or
have
plans
to
do
anything
like
this.
You
know.
What's
what's
the
story
with
you
know,
is
this
going
to
happen
and
the
other
question
I
have
is
on
the
client
side.
How
likely
is
it
that
people
will
expect
manufacturers
of
devices
to
be
around
in
the
long
term
to
continue
to
present
their
dane?
F
You
know
records
in
their
zones,
or
is
this
just
an
onboarding
technology
to
get
initially,
you
know
re-parented
into
a
private
pki
on
the
consumer
side
kind
of
clarify.
Where
are
we
going
with
this?
If
you
like
is
my
so,
I
think
it's
kind
of
a
clarifying
question.
I'm
not
challenging
the
use
case
as
such.
B
Actually,
so
I
would
say
that
you
know
specifically
the
concerns
about
you
know
representing
an
identity
if
a
company
goes
out
of
business,
that's
definitely
a
valid
concern
and
you
may
not.
You
know.
While
we,
you
know,
we
talk
about
the
simplification
that
can
come
from.
You
know,
supplier
issued
pki.
You
know
that
it
may
make
sense.
B
Also
to
still
you
know,
have
that
onboarded,
for
you
know
to
an
organization
wanting
to
represent
their
own
identities,
but
I
would
think
that
you
know
if
a
manufacturer
goes
out
of
business
and
they're
also
not
issuing
firmware
updates.
Then
there
are
other
concerns
that
come
along
with
that.
B
A
Question
victor
one
was
was:
who
was
going
to
be
implementing
stuff
too
right?
Is
there?
Is
there
definite
use
cases
where
I
guess
there
are
companies
that
are
planning
on
using
this
technology?.
A
Yes,
okay,
so
some
extent.
I
think
we
can
take
that
post
charter
when
we
try
and
figure
out
is
there
people
in
this
space
that
want
to
they
want
to
participate,
and
one
of
the
questions
for
participation
is:
are
there
people
in
the
space
that
want
to
do
implementation,
so
we
will
come
back
to
that
later.
That's
a
good
question
victor,
but
let's
table
that
for
the
moment
all
right,
ben.
H
Nothing
here
addresses
how
you
learn
the
name
of
a
device,
but-
and
so
if
the
name
of
the
device
were,
for
example,
a
public
key
fingerprint,
then
you
that
we
would
not
have
any
of
this
pki
question
at
all.
You
could
just
verify
the
the
device's
certificate
against
that
public
key
fingerprint,
but
that's
not
very
user
friendly
in
cases
where
those
names
are
ever
exposed
to
users
or
operators.
H
B
Is
one
benefit,
but
another
benefit
sort
of
speaking
to
your
use
case
is
that
if
you're,
you
know,
if,
if
your
public
key
identifier
is
your
is
also
the
name
of
the
device
device
being
identified,
then
you
can't
rotate
that
public
key
without
also
changing
the
name
of
the
device,
and
so
if
a
policy
is
bound
to
a
device
name
and
the
device
name
is
the
public
key
id.
Then
certificate
or
credential
rotation
becomes
kind
of
difficult.
H
A
Yeah,
so
if
carrie,
if
carrie
lynn,
that
is
if
there
should
be
a
microphone
button
underneath
your
name
and
you
can
just
click
on
that,
and
it
should
allow
you
to
start
talking.
Oh.
E
E
I
B
Yeah,
so
if
a
if,
if
a
domain
gets
transferred
to
a
new
owner-
and
I
don't
know
if
that
would
be
like
a
you
know-
supposing
one
identif
identity
provider
you
know
were
acquired
by
another,
you
know
there
would
be
certain
consider
to
consider
it
security
considerations
with
that.
If
a
domain
were
taken,
you
know
if
a
domain
registration
were
lost
and
then
acquired
by
you
know
another
entity,
then
those
identities
could
be.
You
know
that
would
definitely
cause
a
problem
here.
B
You
know
so
when
you,
when
you
sort
of
break
the
link
between
the
organization.
That's
you
know
that
owns
the
domain.
You
know
in
another
organization
takes
over,
you
know
for
for
good
or
ill.
That
would
be
something
that's
worth
documenting
as
a
security
consideration.
I
think
it's
a
good
point.
Thank
you.
A
To
that
question
right,
there's
the
half
of
what
happens
when
a
taken
over
domain.
You
know
changes
control
of
what
certificates
are
accepted
by
adding
and
removing
names
versus
who
owns
the
private
key
which
stays
on
the
device.
A
All
right
that
brings
us
to
kerry.
Do
you
want
to
try
again.
A
All
right
don't
hear
from
carrie
come
back.
I
guess
carrie
when
you,
when
you
want
or
type
your
note
into
chat.
In
the
meantime,
I
think
we
are
at
the
end
of
clarifying
questions.
It
looks
like
at
the
moment,
so
we
will
dive
into
charter
next,
which
was
the
next
item
on
our
agenda
and.
A
Okay,
all
right
so
back
to
the
charter,
so
when
we
last
left
our
heroes
as
we're
on
the
slides
earlier.
Thank
you,
michael
for
looking
at
the
timeline,
the
original
charter
that
you
know
was
proposed
back
in
april.
May
it's
gone
through
a
number
of
revisions
by
with
comments
from
various
people
that
we've
put
into
the
github
page,
that
is
in
michael's,
github
account.
A
This
is
essentially
the
charter.
There's
there's
a
number
of
things.
I
can
read
the
some
of
the
slides,
but
some
of
the
other
ones
are
longer
I'll.
Let
you
read
them
for
yourself,
but
really
the
dane
authentication
is
for
iot
service.
Hardening
working
group
seeks
to
extend
dane
to
encompass
tls,
client
authentication,
using
certificates
or
raw
public
keys.
A
This
is
sort
of
the
problem
statement,
so
I
will
leave
this
here
for
a
minute
one
of
the
things
that
we're
going
for
in
a
minute
and
then
I'll
stop
talking
so
you
can
read,
but
is
you
know
at
the
end
of
all
of
this?
Do
people
see
any
complaints
with
this
text
that
would
prevent
the
working
group
from
being
formed,
so
I
will
pause
here
for
a.
J
F
F
F
So
I
guess
I
owe
you
some
suggestions
which
I
haven't
yet
come
up
with
for
even
clearer
statements.
I
don't
think
I'm
disagreeing
with
the
intent,
but
I
think
it
could
be
stated
better.
A
F
A
K
A
F
A
Good.
Okay,
thank
you.
So,
let's
go
on
to
the
next
page,
which
is
more
about
the
problem
statement
in
part
two,
and
I
will
leave
that
there
for
a.
A
F
On
this
one,
I'm
not
sure
I
understand
who
the
private
pki
issuer
is.
Is
it
the
customer
who
purchased
the
devices
or
the
separate
providers
who
each
separately
enrolled
them
in
their
own
pkis.
A
Because
it's
a
little
confusing
yeah
okay,
so
one
of
the
I
think
one
of
the
biggest
challenges
that
this
working
group
has
going
forward
is
the
problem
space
is
lightly
documented
and,
and
is
not,
you
know
tuned
down
to
so
one
of
the
reasons
that
we
added
the
architecture
document
to
you
know
the
deliverables
later
was
I
apologize
using
for
using
the
word
deliverable
in
the
atf,
but
to
the
charter.
A
Items
later
was
specifically
to
narrow
this
down
with
the
the
time
scale
of
I
think
one
of
the
first
goals
is
really
to
better
document
the
architecture
with
respect
to
who
the
players
are.
You
know
what
are
the
examples
that
would
make
a
good
case
scenario,
which
you
know
you
saw
some
in
the
slides
and
other
people.
I
think
in
jabber
were
suggesting
you
know
alternate.
A
You
know
possible
venues
where
something
like
this
could
be
deployed,
but
we
need
to
get
those
down
to
make
sure
that
the
resulting
architecture
that
in
the
solution
can
actually
meet
all
of
the
potential
use
cases.
So
I
think
that's
a
good
question.
Do
you
believe
that
the
text
as
is
needs
to
be
clarified,
or
can
we
leave
it
somewhat?
Generic
with
respect
to
where
the
private
key
pki
and
the
ca
set
is.
F
Here
I
think
the
intended
meaning
is
that
the
private
pkis
are
per
provider
and
that's
why
there's
a
communication
gap,
and
yet
it
sounds
like
it's
stated
that
the
pki
is
implemented
by
the
user,
where
there
won't
be
a
communication
gap.
So
it's
a
little
confusing
as
it
stands
as
written.
C
I
think
so
the
words
application
owners
in
the
first
thing
is
kind
of
importing
that
yeah,
that
it
was
the
the
heating,
cooling,
company
or
consultant.
You
know
brought
on
one
pki
and
then
the
lighting
company
brought
in
a
different
one
and
whether
those
are
outsourced
or
in
source.
The
point
is
that
there
were
two
different
ot
type
people
that
were
involved
in.
E
C
That
for
this
you
know
thing
and,
and
then
three
years
later,
you
discover
there's
not
really
any
way
to
communicate
between
them
right
right,
you
don't
get
any
heating
cooling
savings,
because
you
can't
turn
the
lights
off
when
it's
too
warm
right.
F
C
It's
it
could
be
two
people
that
sit
at
opposite
ends
of
a
of
a
of
you
know
the
management
organization,
but
yeah.
L
C
L
F
Okay,
so
multiple
application
owners,
multiple
private
pkis,
all
right,
not
one
private,
pki.
Okay,
so
I
think
a
little
a
little
bit
more
clarity,
and
that
would
make
it
clear.
A
A
A
Can
you
post
your
comment
into
jabber
and
somebody
will
read
it
off
for
you
in
the
meantime,
I'm
gonna
go
on
to
the
next
slide,
but
we
can
come
back
to
this
when
just
to
let
people
read
up,
but
we
can
come
back
to
this
when
bob
posted.
A
Snow
of
work,
section
of
where
danish
should
concentrate
on
if
we
did
discuss
at
the
end
of
the
last
buff,
you
know
not
to
go
overboard
and
not
to
do
to
find
solutions
for
everything
under
the
sun,
but
keep
it
down
to
primarily
authenticating
clients
to
infrastructure
and
not
go
into
some
of
the
more
extravagant.
You
know
possible.
Other
protocol
modifications.
A
I
did
say
the
use
case
text
is
really
clear
to
him.
I
really
appreciate
that
comment,
but
I
think
that
it
is
too
close
to
the
problem.
Then
that
may
be
the
case,
but
certainly.
E
A
N
Can
you
hear
me
now
yeah
here
we
go
sorry,
I
just
wanted
to
chime
in
and
say
that,
regardless
of
the
iot
use
case,
the
client
authentication
is
really
important
to
me
and
I've
got
a
lot
of
people
sort
of
hung
up
on
wanting
tls
client
authentication
for
dns
connections,
so
that
by
itself
is
a
completely
sufficient
justification
for
me.
C
We
are
on
something
that
I
think
was
just
discussed
in
the
the
chat
about
the
relationship
between
this
and
smtp
start
tls,
client
off,
and
we
don't
have
any
words
that
say
it's
not
for
tls
or
smtp,
but
I
also
think
that
we
we
just
didn't
want
to.
At
least
I
didn't
want
to
make
that
a
bike
shed
kind
of
issue.
I
think
that's
something
that
we
would
reasonably
reach
harder
if
we
needed
to
do
that.
That's
my
take
on
it,
but
I
may
not
have
the
only
view
on
that.
A
I
can
hear
you
all
right.
Thank
you,
jacques
all
right,
so
I
think
there's
a
number
of
ways
that
we
can
take
this.
You
know
conversation.
A
We
definitely
want
to
hear
from
people
that
that
want
to
support
the
work
we
want
to
hear
from
people
that
you
know
probably
think
it's
the
wrong
direction,
because
this
is
a
buff
after
all,
but
hold
on
victor
before
we
before
we
dive
into
the
exact
question.
Next,
I
think
the
the
first
question
we
need
to
tackle
is
actually
the
charter
itself
right.
That's
where
we
left
off
last
time
and
that's
where
we
left
off
on
the
mailing
list.
So
before
we
dive
into
you,
know
technical
feasibility
of
the
various
implementations.
A
The
real
question,
in
my
mind,
is:
are
there
any?
Are
there
any
charter
modifications
that
need
to
be
made
if
this
working
group
is
forming,
and
that
does
not
mean
that
if,
if
there
are
no
modifications
being
made,
the
working
group
will
definitely
be
formed.
That'll
be
up
to
roman
to
sort
of
help,
help
us
determine
that
consensus,
but
any
remaining
topic
of
conversation
on
the
charter
text
itself
and
its
scope.
A
F
F
E
A
Okay,
thank
you
shaq
and
then
bill
posted
a
note
that
I'll
reread
here,
which
is
that
I'm
fine
with
what's
there,
but
I
guess
I
de-emphasize
the
iot
stuff
to
the
degree
necessary
to
make
it
clear
that
there
are
also
a
lot
of
other
use
cases,
and
I
think
that's
actually
a
very
fair
comment.
It
seems
to
be
that
there's
people
chiming
in
with
other
use
cases
that
they
want
to
do
really
if
we,
if
we
take
iot
out
and
leave
it
a
little
bit
more
directed
toward
just
client,
tls
authentication.
A
O
I'm
trying
to
understand
exactly
which
class
of
iot
devices
this
is
aimed
at
and
and
just
to
give
the
context
for
that.
If
this
is
working
through
dns
sec,
then
that
means
there's
going
to
have
to
be
public
key
operations
any
time
that
you
try
and
form
a
new
relationship
with
a
new
device.
O
Correct
me
if
I'm
wrong,
but
I'm
pretty
sure
that's
how
it
works.
So
that
means
that
you
are
looking
at
prescribing
devices
which
are
not.
You
know,
powered
on
a
coin
cell,
at
least
that's
how
it
looks
to
me.
So
I
mean
personally,
it
looks
to
me
in
the
in
the
battery-powered
iot
space
like
gateways,
are
the
right
answer
for
this,
but
I
mean
maybe
you're
targeting
a
different
class
of
iot
device.
So
I'd
just
like
some
clarification
on
that.
B
Yeah,
I
think
that's
a
that's
a
great
question,
so
the
the
super
lightweight
stuff-
I
don't
really
expect
to
you-
know
very
often
those
won't
even
be
establishing
tls
connections
right
and
so,
if
you're
talking
about
you,
know
the
the
decoupled
use
cases,
you
know
where
you
may
have
something
that
uses
something
like
laura
one
for
communication,
those
don't
those
I
can
you
even
I
think
you
can
do
you
know
some
some
loose
ip
type
communication
over,
but
it's
not
the
default
right
and
so
you're
looking
at
something
that
that
beacons
out
and
they
use
they
don't
use
public
key
encryption
typically
well.
O
I
mean
this
is
this
is
what
dtls
is
for
right?
Yeah,
I
mean
you
establish
a
session
and
it
lasts
for
a
long
time.
So
this
is,
you
know,
I
would
expect
a
gateway
type
solution
for
this,
where
the
gateway
is
a
third
party
in
the
communication,
and
it
manages
these
interactions
and
that's
why
we
have
dtls
with
long-term
connections.
B
Good
point
good
point
I
had
yeah,
we
certainly
don't
want
to.
We
want
to
include
as
much
as
we
can,
but
I
think
for
the
stuff
that's
operated
on
a
coin
cell.
B
K
P
Yeah,
so
I
think
that
you've
got
a
really
straightforward
problem
here
that
really
fits
dane's
capabilities
very
nicely
and
one
that
just
doesn't
and
is
really
complicated.
I
mean
like
client
auth
for
smtp
start
tls.
I
think
it's
a
no-brainer
and
I
just
thought
had
been
done
in
the
first
place.
There's
absolutely
no
reason
why
servicer
should
be
considered
some
really
special
type
of
certificate,
because
you
know
the
only
difference
between
client
and
server
in
the
smtp
case
is
the
client
starts
the
conversation.
P
The
server
responds
but
they're
using
dns
names
to
identify
things
on
both
ends
and
so
yeah.
I
that's
something
that
makes
perfect
sense
to
me
now:
the
iot
world.
On
the
other
hand,
I
mean
like
it's
not
at
all
clear
to
me-
that
dane
is
a
good
sorry
that
dns
is
a
good
fit.
Dns
sec
is
looks
like
a
really
poor,
fit
picks,
looks
like
a
really
poor
fit
and
the
tr
we're
trying
to
match
all
these
together
and
that's
a
really
really
complicated
endeavor.
P
I
think
that
if
you're
going
to
go
ahead
with
this,
do
the
tls
client
off
first,
because
we're
going
to
need
that
anyway
and
make
the
iot
stuff
I
mean
if
they
recharter
and
if
they,
but
even
then
I
mean
like
that's
just
not
the
way
that
I
would
do
this
problem
at.
Q
A
Her
comment:
that's
a
valid
constructive
criticism.
Ben.
A
H
So
yeah,
I'm
not
sure
about
this.
This
90
day
limit
that
that
was
alluded
to
I'm
be
curious
where
that,
where
that
concept
comes
from,
but
it
does
seem
like,
like
dane,
has
the
the
interesting
property
that
the
the
validity
of
your
your
identity
is
limited
by
the
minimum
of
the
validity
lifetimes
of
all
of
the
names
above
you
in
the.
E
H
Dns
hierarchy
of
all
the
the
zone
cuts
above
you
so
at
a
minimum.
You
know
the
the
root
has
very
long
validity
lifetimes,
but
I
don't
know
what
the
tld
dns
key
lifetimes
look
like.
That's
that's!
Presumably
your
limiting
factor
for
this
charter.
The
thing
that
that
seems
that
I'd
like
to
see
addressed
here
is
mixed
deployments.
H
So
in
general,
with
dane,
if
you're
presented
with
with
a
dns
name-
and
you
know
that
you're
in
a
dane
context,
then
dane
works
very
well
and
in
my
view
the
biggest
problem
that
dane
has
had
is
that
if
you're
presented
with
a
dns
name-
and
you
don't
know
whether
you
are
supposed
to
do
dane
then
dane-
does
not
work
really
at
all,
and
so
in
the
web,
where,
where
there's
a
pre-existing
pki
in
play,
the
dane
doesn't
work
well,
because
you
don't
know
whether
you're
supposed
to
use
dane
when
you,
when
you're
in
the
process
of
looking
at
a
name.
H
You
have
pre-existing
deployments,
they
have
their
own
identity
systems.
In
some
cases
those
identities
are
dns
names,
in
which
case
they're
not
using
dane
today,
and
you
need
to
somehow
interoperate
with
them
and
some
cases
those
identities
aren't
even
dns
names
at
all.
H
So
I
would
like
to
see
that
addressed
in
the
charter,
either
to
rule
it
out
and
say
that
this
is
strictly
limited
to
greenfield
applications
where
you
can
be
dane
only
from
the
ground
up
or
to
say
that
we're
really
going
to
try
to
figure
out
what
you
do
when,
when
it's
not
initially
clear
whether
dain
is
in
use.
Thank
you.
A
H
So
you
know
structures
in
terms
of
solutions.
I
think
that
if
you
wanted
to
support
this,
what
you'd
need
is
some
kind
of
agreement,
for
example,
on
the
format
of
a
name
where
names
of
a
particular
format
are
guaranteed
to
are
indicated
that
as
using
dane-
and
maybe
that
means
that
your
identities
aren't
as
simple
as
dns
names.
Maybe
your
identity
looks
more
like
a
uri,
so
that
there's
something
else
in
there
that
can
be
a
flag
to
say
yes
and
use
dane
to
validate
this,
but
for
the
charter.
J
Victor,
I'm
not
sure
if
you
can
hear
me,
I
think
victor.
J
Answer
ben's
question
so
I'd:
let
him
go
first:
okay,
victor!
Go
ahead!.
F
Sure
so
ben
was
asking
about
knowing
when
to
use
dane,
and
it's
pretty
explicit
you
use
dane
when
there
are
tlsa
records
published,
which
can
even
specify
whether
to
use
dane
alone
or
whether
you
stand
in
combination
with
the
web
pki
via
the
pkx
usages,
rather
than
the
dane
usages.
F
So
dane
usage
is
self-discoverable
and
without
downgrade,
at
least,
if
you
trust
dnsec,
you
have
a
denial
of
existence,
protection
in
dnsec.
So
it's
a
downgrade
free
mechanism
for
discovering
when
dane
cannon
should
be
used
so
and
the
naming
is
all
specified,
at
least
for
servers,
underscore
port
underscore
protocol,
tcp
or
udp.fqdn.
F
If
that's
published,
then
you
use
dane
it's
pretty
straightforward.
That's
how
it
works
in
smtp,
where
it's
not
a
priori
known,
whether
to
use
it
or
not.
Dane
is
used
opportunistically
by
discovering,
whether
it's
applicable,
so
that
question
solves
itself
and
it
can
solve
itself
in
additional
context,
including
in
the
web.
The
main
obstacle
to
using
dane
and
the
web
have
been
objections
about
latency
and
also
about
availability
of
dns
sec
in
various
captive
portal
or
broken
home,
cpe
or
various
other
environments,
where
clients,
rather
than
servers,
find
themselves
with
crippled
dns.
F
So
there
are
issues
on
that
front,
but
not
issues
are
undiscovering
where
the
dane
applies.
I
also
wanted
to
comment
on
the
battery
powered
thingy,
but,
like
maybe
I
should
let
dkg
speak
first,
since
he.
A
F
A
J
H
Has
a
response
to
your
response
right,
so
I
mean
I
I
understand
that,
but
I
think
that
the
things
get
a
lot
more
complicated.
First
of
all,
when
private
pkis
are
in
play,
because
private
pkis
are
are
typically
configured
to
override
other
forms
of
authentication,
they
have
priority,
and
so
there's
a
priority
conflict
between
dane
and
your
private
pki,
and
also
because
you
may
have
a
pre-existing
system
where
the
identities
in
play
aren't
actually
dns
names
and
so
that
we
have
a
typing
question.
If
you
just
are
presented
with
a
string.
A
So
I
think
this
this
is
getting
to
smell
a
bit
like
a
rat
hole,
it's
a
good
rifle,
but
I
I'm
I'm
questioning
whether
we
need
to
go
into
this
level
of
detail
today
that
the
real
question
is.
A
J
Hi
gilmore,
so,
as
I
see
it,
the
main
challenge
for
dane
in
tls
is
just
that
the
server
doesn't
know
what
name
the
client
is
using
right.
So,
in
some
sense,
all
we're
saying
here
is
that
we
want
a
way
that
the
client
can
say:
hey,
here's,
my
dns
name,
and
then
I
can
check
you
can
check
my
certificate
against
this,
in
the
same
way
that
I
as
a
client
would
have
checked
your.
If
I
was
using
gain,
I
would
have
checked
your
name
right
is
that
is
that
the
the
core
piece.
B
B
On
that-
and
I
apologize-
I
kind
of
glossed
over
that
portion,
but
that's
that's
actually
discussed
in
the
drafts
and
that,
as
far
as
how
we
update
the
tls
handshake,
so
that
the
client
can
signal
that
it
intends
to
authenticate
using
dane
and
then
the
server
says.
Okay
well
give
me
your
dain
credential,
and
so
it's
it
requires
updates
to
the
tls
handshake
in
order
to
support
it.
So
that
you
can,
you
know
specifically
authenticate
using
dane
and
it's
not
it's
not
necessarily
implicit.
J
J
Yeah,
so
the
one
additional
wrinkle
that
I
wanted
to
mention
here
is
that
this
is
now
a
client
getting
to
force
the
server
to
do
a
particular
dns
lookup,
and
I
don't
know
whether
there
are
any.
I
don't
know
whether
there
are
any
additional
privacy
concerns
there
in
terms
of
identifying
say,
public-facing
view
or
or
or
tracking
the
server
down
in
a
different
way
right.
The
server
may
have
a
different
address
publicly
than
it
does.
J
A
J
A
But
again,
probably
into
solution
space
rather
than
getting
working
group
off
the
ground
space
rich.
R
Yeah
tell
me
if
this
is
out
of
line
for
this
point.
I
think
we
should
not
do
this
and
I
don't
think
it's
deployable
and
do
you
want
to
have
that
kind
of
discussion
now
or
have
the
fans
work
on
the
chart.
R
I
I
think,
on
the
one
hand,
so
in
order
to
do
client
identities,
that
means
there
has
to
be
a
client
name
in
dns
somewhere,
and
that
means
correct
me
if
I'm
wrong,
since
I'm
kind
of
not
totally
up
on
all
the
dane
stuff,
but
if
you
have
to
have
a
client
name
and
it's
either
a
large
manufacturing
company,
let's
say
carrier,
doing
air
coolers
or
killers
in
data
centers
or
it's
a
small.
R
You
know
somebody
like
philip
wants
to
automate
their
home
their
home
system.
We
said:
oh
pki
is
too
hard,
so
instead
we're
going
to
add
keys
and
certificates
to
dns
to
people
who
are
not
experts,
not
only
not
experts
really
unfamiliar
with
this
stuff
right,
because
how
else
am
I
going
to
find
out
the
name
for
my
chiller
and
the
key
for
the
chiller?
R
If
I
want
to
tell
it
to
stop
cooling
because
there's
an
earthquake
coming
in,
I
don't
want
the
power
load,
yeah
they've
become
only
experts
are
using
no
they're,
not,
and
I
don't
think
we
should
continue
to
make
it
more
than
you
know.
A
And
that's
it!
Okay,
you
know,
that's
that's!
I
I
think
deployability
is
an
absolutely
fair
comment.
A
So
so
hold
on,
I
I
don't
want
to
dive
down
into
again
into
the
solution
space.
So
if
you
read
the
draft,
they
do
the
the
draft
does
discuss.
You
know
how
to
create
construct,
naming
and
things
like
that,
and
I
think
that
that
is
a
valid
concern
that
that
deployability
is
is
something
that
should
be.
You
know
mandatory
toward
the
end.
Is
it
deployable
in
large
systems?
Do
manufacturers
have
to
publish
you
know
a
tlsa
record
for
every
single
one
of
the
devices
they
ever
create?
A
F
A
couple
of
comments-
one
I
wanted
to
return
to
the
dtls
and
battery
device
dane-
would
only
be
used
on
initial
session
creation
in
tls
right
when
we're
doing
tls
resumption,
which
was
the
the
use
case
of
a
long-running
dtls
session.
Resumption
doesn't
exchange
certificates,
it
doesn't
exchange
public
keys
in
tls.
So
if
you
managed
to
establish
three
years
ago
a
dtls
session,
that's
still
running,
it
will
continue
to
work
exactly
the
same
way
with
or
without
dane
nothing
about,
dane
changes.
The
ability
to
resume
already
agreed
tls
session
keys.
F
So
if
you're
able
to
do
tls
at
all
and
you're,
avoiding
pki
by
doing
resumption
forever,
they'll
continue
to
work
to
riches.
Point
I'm
also
a
bit
skeptical
about
deployment
with
respect
to
iot,
which
is
why
I
asked
my
earlier
questions
about
whether
anybody
is
planning
to
do
this,
but
certainly
for
smtp
client.
We
have
natural
mta
to
mta.
We
already
are
in
the
dns
name
space.
You
announce
your
dns
name
in
the
hello.
F
We
were
going
to
do
this
in
the
dane
working
group
when
it
abruptly
got
shout
shut
down
on
me,
while
schumann
and
I
were
contemplating
the
dane
client
draft
now
about
seven
years
ago
and
it
kind
of
ran
out
of
steam
when
the
working
group
closed.
So
it's
seven
years
over
duo
was
already
interested
in
it
back
then.
So,
if
that's
all,
we
end
up
doing
and
finishing
something.
A
Yeah,
I
will
say
that
the
number
of
people
that
said
that
they're
thinking
about
implementing
it
or
have
talked
about
deploying
it
sort
of
pushes
back
a
little
bit
on
it's
not
deployable,
because
clearly
people
have
ideas
on
how
to
pull
that
off.
But
but
that's
a
good
again
future
discussion
for
ensuring
deployability
happens
or
solutions
in
that
space
bill.
N
This
is
a
dns
technique
which
will
be
invaluable
for
people
who
are
capable
of
doing
dns.
It
is
not
difficult
by
dns
standards.
Likewise,
anyway,
you
can
set
up
a
email.
Server
can
easily
do
this.
N
Yes,
this
is
not
intended
for
someone
who
buys
a
heater
to
go
and
set
up
dns
records
and
do
dnsx
signing.
That
is
not
the
use
case.
The
use
case
would
be
for
the
manufacturer
to
do
that,
not
for
end
users
to
do
that.
End:
user
hobbyists,
who
are
capable
of
running
their
own
mail
servers
and
running
up
their
own
dns
servers.
Sure
but
they're,
not
a
problem.
D
Yeah,
it's
impounded.
I
I
think,
if
we're
gonna
do
the
iot
parts
of
this
and
kind
of
emphasize
it
in
the
charter.
We
need
to
try
and
understand
how
it
relates
to
to
mata,
which,
if
I
understand
it
correctly,
is
addressing
some
of
the
same
kind
of
onboarding
from
multiple
manufacturers
and
generating
a
trust
tree
between
devices
from
multiple
manufacturers.
So,
and
I
think
we
need
to
either
make
clear,
blue
water
or
collaborate
or
something.
But
we
need
to
understand
what
our
relationship
is
with
that.
B
I'm
not
deeply
familiar
with
matter
and
the
way
put
together,
but
my
understanding
is
that
it
it
does
operate
a
private
pki
and
there
are
onboarding
processes
with
that
as
well.
I
don't
see
this
as
something
that's
incompatible
with
that,
but
I
don't
know
what
the
I
don't
have
off
the
top
of
my
head.
What
an
integration
avenue
would
look
like
for
that
open
to
feedback,
and
you
know
maybe
that's
something
that
you
know
that
we
could
contextualize
in
the
architecture
document.
A
Dan
harkins
nicely
posted
the
matter.
Most
matter
is
a
closed
protocol
from
a
vendor
consortium
which
does
definitely
play
differently
than.
O
A
The
ietf
space
brendan.
O
The
point
I
was
making
was
that
each
relationship
that
you
have
with
another
device-
you
know
you
know
a
one-to-many
or
many-to-many
kind
of
topology-
is
going
to
require
that
initial
resolution
and
that
initial
resolution
costs
you
energy,
whereas
if
you
use
something
like
the
gateway
solution
that
I
I
referred
to,
you
end
up
with
a
one
one
to
many
or
many
to
many
relationship
with
a
single
instance
of
pk
or
pki
resolution
or
or
session
establishment,
and
and
that
does
make
a
difference,
so
it
wasn't
necessarily
about
establishing
connections
many
times
it
was
more
about
establishing
many
different
connections.
A
O
Well,
and
indeed
that
what
they
accomplish
is
a
reduction
in
complexity.
In
your
end
devices
I
mean
we
haven't
even
talked
about
what
happens
when
nodes
disappear
to
the
relationships
that
have
been
established
and
the
complexity
that
you
have
to
put
into
your
end
nodes
in
order
to
account,
for
you
know,
I
have
a
furnace
and
suddenly
it
can't
find
my
thermostat
anymore.
What
do
I
do?
So?
That's
that's
a
complexity
that
you
have
to
put
in
the
end,
node
and
the
quest,
if
you're
doing
a
direct
device
to
device
communication.
O
A
H
So
I
would,
I
think
that
that
we
one
thing
that
would
make
me
happier
here
is
if
the
charter,
you
know
explicitly
wrote
in
a
requirement
to
to
essentially
address
orphan
devices,
ensure
that
that
orphan
devices
continue
to
be
accessible
and
functional,
or
that
users
have
a
mechanism
to
tear
their
device
out
of
the
manufacturer
ecosystem
and
and
point
it
at
their
own
infrastructure.
A
So
that
sounds
like
a
item
that
should
go
into
the
architecture
document
in
terms
of
you
know
how
what's
the
longevity
of
of
of
devices
in
general
or
manufacturers
in
general,
and
that
sounds.
H
Like
absolutely,
I
I
think
that
it's
a
charter
item,
because
it
generates
substantial
technical
work.
For
example,
it
might
generate
some
technical
components
that
resemble
something
around
the
the
domain
connector
or
the
cds
record,
the
systems
that
we
have
for
trying
to
manage
a
parent
zone.
H
I
think
it's,
you
know
it's
not
trivial
to
to
make
iot
devices
retargetable
to
say.
Okay,
now,
your
controller
is
no
longer
the
original
manufacturer,
it's
a
big
project
and
if,
but
I
think
that
that
has
to
be
in
charter,
if
we,
if
we
want
to
pursue
this.
A
All
right,
I
thank
you
for
your
point.
I
I
would
say
that
danish
is
not
the
only
place
with
that
problem,
though,
but
but
fair
point.
Phil.
P
Yeah,
I
just
wanted
to
say
that
in
the
chat
there's
a
lot
of
discussion
about
is
this
limited
to
tls,
and
one
of
the
things
to
remember
about
dane
is
that
it
is
two
things
it
is
a
way
to
publish
keys,
and
this
is
also
a
way
to
publish
security
policy
in
that
it
is,
must
use
tls
to
connect
to
this
website
and
it
the
conflation
of
the
two
is
unfortunate.
It's
something
I
argued
against,
but
it
is
there
it
will
be
use.
P
If,
if
there
is
going
to
be
a
working
group
chartered,
it
would
be
useful
to
see
that
dismantled
and
separating
out
a
way
of
expressing
security
policy
that
isn't
constrained
to
just
tls.
P
The
other
big
problem
with
tlsa
records
is
that
I've
not
found
any
provider
of
dns
services
that
has
a
cpanel
interface
that
allows
me
to
inter
input
a
tlsa
record.
You
know
I've
got
a
quad,
a
caa,
which
I
wrote
10
years
ago,
cname
mxns,
srv,
spf
txt,
and
that
is
it
and
for
a
very
large
number
of
web
of
internet
admins.
P
P
A
A
couple
of
things
phil,
one
tlsa
records,
do
not
mandate
that
you
use
tls
in,
except
for
the
smtp
case.
It
was
actually
explicitly
excluded
in
the
in
the
tlsa
draft
itself
that
it
was
not
allowed
to
indicate.
You
must
use
tls
so
that
that's
a
bit
of
history
it
is
mandated
for
for
for
smtp,
but
it's
not
for
for
http,
for
example,
as
for
cpanel,
and
things
like
that,
it
sounds
like
you
should
do
it
if
you
did
the
other
ones.
A
So
you
could
actually
fix
that
problem.
For
us,
that
would
be
wonderful,
yeah.
A
P
A
So
so,
with
respect
to
does
it
need
to
be
in
cpanel
or
not?
You
know
it's
a
totally
separate
question
because
there's
a
huge
amount
of
tlsa
records
that
exist
on
on
on
the
internet,
as
victor,
has
proven
through
a
lot
of
scanning.
So
your
point
is
valid
that
for
an
end
user
needing
to
do
to
use
this
solution,
this
could
be
a
problem
you're.
Absolutely
right.
I
don't
think
that's
the
target
audience
space
of
this
particular
group,
though
all
right
so
victor.
I
think
you're
next.
F
To
to
philip's
comment,
the
dutch
standards
organizations
are
now
working
with
cpanel
and
so
on
to
in
fact
directly
address
that
question.
So
I
expect
to
see
work
not
too
far
into
the
future.
To
make
tlsa
records
available
to
end
users.
They've
already
been
sending
me
questions
about
best
practices,
so
we
should
see
something
in
that
space
before
too
long,
barring
unexpected
obstacles.
F
So
I
think,
even
though
it's
taken
10
years,
you
know
for
lack
of
adoption
in
browsers.
One
can
understand
why
the
pressure
to
adopt
has
been
quite
light,
but
with
smtp
deployments.
Expanding
people
are
interested
in
having
cpanel
support
for
users
of
mail
servers
and
the
like.
So
I
think
that'll
that
can
change
and
if
we
add
more
use
cases,
the
incentives
will
go
up,
barring
incentives,
nobody
will
do
it,
so
some
things
take
time
to
be
current
and
relevant,
and
so
we
will
see
it's
a
solvable
problem.
F
C
All
right,
so
I
I
wanted
to
understand
phil
allment
better.
As
far
as
I
can
understand.
The
only
reason
I
would
need
a
tlsa
record
in
icpanel
is,
if
I
was
using
it
for
smtp
uses.
I
I
can't
I
can't
understand
when
otherwise
now
bill
writes,
if
I
can't
take
control
the
device,
I
don't
want
this
at
all.
Well,
that's
not!
I.
I
think
that
is
completely
out
of
scope,
because
none
of
the
other
systems
are
are
promising
you
to
take
control
of
the
device.
C
Well,
I'm
I'm
all
for
taking
control
the
device,
but
I
don't
see
how
this
helps
you
one
way
or
the
other.
C
C
So
I
also
wanted
to
say
something
about
chip
matter
and
I
couldn't
say
it
because
my
microphone
broke,
so
the
spec
is
not
public
and
my
impression
from
what
I've
understood
about
from
ash
and
schumann
is
that
the
target
use
case
is
definitely
outside
of
the
home
and
it
is
at
a
different
scale
of
of
of
things
that
really
doesn't
have
a
lot
of
overlap
with
matter.
C
Even
if
we
think
that
you
know
home
devices
will
round
up
in
hair
salons
they're
not
going
to
be
running
as
I
wrote
the
chrysler
building.
That's
that's
my
take
my
understanding
of
it,
but
I
can
be
corrected.
F
On
the
topic
of
the
dnsec
chain
extension
that
will
be
rfc
9102
any
day
now
through
the
independent
stream
we've.
Finally,
gotten
it
wrapped
up
it's
in
auth
48
today
and
should
be
done.
You
know
within
a
week
or,
however,
long
of
48
takes
so
rfc
9102,
look,
look
to
read
it
soon,.
A
Thanks
for
the
update,
all
right
with
that,
we've
drained
the
cues.
So
what
I
would
like
to
hear
from
next
is
there's
there's,
certainly
a
lot
of
interest
within
the
audience.
As
far
as
you
know,
my
read
goes:
there's
a
few
people
that
are
critical
of
it
and
makes
perfect
sense
and
there's
a
few
people
that
have
pointed
out
technical
difficulties
and
things
that
we
need
to
overcome
so
roman,
a
quick
call
out
to
you.
A
If
there's
things
you
definitely
want
to
hear
from
next,
please
let
me
know,
oh,
you
already
were
typing
I'll,
get
back
to
that
in
a
second.
A
What
I'd
like
to
hear
from
in
the
meantime
is
who
is
willing
to
work
in
this
space
and
you
know,
for
there
have
been
some
people
that
have
spoke
up
that
have
wanted
implement,
but
you
know
are,
are
do
we
have
enough
forward
movement
within
people
that
are
willing
to
participate
and
review
and
participate
in
mailing
list
discussions,
and
things
like
that
and
implement
anybody
have
comments
with
respect
to
that
in
terms
of
desire
to
move
this
work
forward.
A
A
Well
so
this
is,
you
know,
potentially
one
of
one
of
the
considerations
was
we
make
this
a
little
bit
more
generic
and
talk
more
generic
about
client
related
stuff
of
which
you
know
iot
falls
into
that.
G
There
are
a
couple
of
parties
that
definitely
have
voiced.
We
should
use
less
iot
words.
We
should
generalize
that
that
can
make
kind
of
perfect
sense.
I
guess
I'm
trying
to
understand
how
much
that's
technical.
We
need
better
technical
constraints
and
how
much
of
that
is
editorial.
So
the
thing
that
would
be
interesting
for
me
would
be
for
a
second,
let's
ignore
everything
above
the
work
items.
Let's
stare
at
the
work
items.
Is
there
something
to
iot
in
two
iot
specific
in
there
that
wouldn't
allow
for
a
gener?
A
N
No
so
so
again,
I've
got
nothing
against
iot
folks
and
you
know
more
power
to
them
if
they
can
find
ways
of
applying
this
and
solving
problems
and
so
forth.
I
just
need
this
for
dns
and
I
would
love
to
have
it
available
for
the
smtp
folks
as
well,
and
so
I
just
don't
see
a
reason
to
throw
iot
specific
references
into
a
general
purpose
technology
that
we
all
need,
because
that's
just
going
to
get
iot
rat
hole
conversations
tying
up
the
work.
I
think
we
need
to
move
forward
with
the
actual
work.
N
A
Okay,
thank
you
very
much
and
I
do
note
that
a
large
number
of
people
well,
a
five
to
ten
number
of
people,
have
spoken
up
in
the
chat,
indicating
support
and
things
that
you're
willing
to
do.
We
appreciate
that
very
very
greatly,
including
renaming
the
working
group
victor.
F
Yeah,
so
I
see
this
as
being
two
pieces
of
work.
One
is
sort
of
a
base
document
just
specifying
a
little
bit
of
how
to
publish
client,
tlsa
records
and
various
special
use.
Labels
for
that,
and
all
that
kind
of
fun
and
that's
general
and
cuts
across
the
board.
F
And
so,
if
that's
also
in
scope
for
this
working
group,
then
the
the
higher
level
issues
around
iot
are
serious
and
come
into
play.
So
I
don't
know
whether
you
know
it
makes
sense
to
do
first,
the
kind
of
basic
technology
and
then
iot
follow
on
it,
whether
through
them.
Concurrently,
you
know
how
to
structure
the
working
group
in
terms
of
work
items.
Do
we
carry
the
these
out
in
parallel
or
serially
is
kind
of?
I
think
where
bill
is
in
some
sense
kind
of
asking
a
question.
A
Okay,
thank
you
and
thank
you
dan
harkins,
for
getting
that
song
stuck
in
my
head.
Wonderful
shark.
E
A
All
right,
phil.
P
An
agreement
I
basically
it
seems
like
a
no-brainer
to
me
that
if
you
can,
you
can
charter
the
the
working
group
around
extensions
folk
that
will
be
servicing.
Smtp
start
tls,
that's
going
to
be
a
much
more
constrained
and
tight
and
narrow
charter
than
one
that
is
trying
to
solve.
A
So
so
let
me
stop
for
one
second
say
that
I
think
that
there
is
general
consensus
in
the
room
based
on
all
of
the
comments
and
reading
of
the
text
that
we
will
remove
iot
from
the
charter
and
make
it
more
client
specific
oriented.
I
don't
think
we
will
we'll
tie
it
directly
to
smtp
client
authentication.
That
is
way
too
narrow
based
on.
A
I
think
all
of
the
comments
that
we've
heard
today
so
my
plan
is,
is
that
we
will
do
some
wordsmithing
and
we
can
even
do
it,
live
as
roman
thought
about
as
well
to
remove
some
of
the
wording
around
iot
device
and
really
tie
it
toward
client
identity
and
then
we'll
we'll
need
to
do
that.
Wordsmithing.
Basically,
all
right,
I
think
that's
sort
of
the
end
of
the
list
of
questions
that
I
in
particular
want
to
pose.
A
There
definitely
seems
to
be
support
for
based
on
my
you
know:
random
buff,
chair
reading
of
lots
of
interest
in
people
continuing
on
the
work
for
this,
so
roman
is
there
anything
else
you
want
to
hear
from
us.
I'd
be
happy
to
shift
into
live
text
editing,
but
I
kind
of
want
to
wrap
up
the
the
exciting
parts
before
we
do
something
like
that.
G
No,
I
mean
I
would
concur
exactly
with
with
your
summary
there.
I
hear
that
this
there's
there's
support
for
the
work
items.
There's
some
concerns
about
the
framing
and
it
sounds
like,
depending
on
the
choice
of
the
framing,
for
example,
if
iot
is
chosen,
there's
a
desire
to
put
additional
constraints
on
what
that
solution.
Space
would
look
like,
I
don't
know,
but
it
would
seem
like
if
those,
if
that
specific
application
domain
was
removed,
perhaps
the
need
for
additional
constraints
in
the
charter
would
be
removed
and
that
might
be
easier
to
move
forward.
G
I
also
like
some
of
the
suggestions
I've
heard
with
with
multiple
speakers
that
we're
we're.
We
should
be
overly
ambitious.
We
can
recharter
as
we
want
more,
but
if
we
could
start
increment,
you
know
we
could
start
from
a
core
a
core
body
of
work.
We
all
agree
on
and
then
we
can
incrementally
add
more
add
more
scope.
I
prefer
that
just
so,
we
get
started
on
the
work.
A
G
G
We
thought
we
understood
the
problem.
Then
we
got
to
the
specifics
of
the
charter.
We
tried
to
pull
it
in
every
kind
of
direction
and
we
heard
crickets
and
we
got
no
working
group
we're
entering
the
second
time
to
kind
of
talk
about
the
buff.
I
think
we
need
to
set
aside
potentially
all
the
dimensionality
of
this
and
find
what
the
mvp
would
be,
that
we
all
can
agree
on
and
make
some
progress
here
and
then,
based
on
that
experience,
we
figure
out
what
additional,
what
additional
scope
we
want.
A
A
All
right
anybody
else
have,
I
guess,
from
an
open
mic.
You
know
point
of
view
things
that
you
think
that
we
should
definitely
the
word
we
have
missed
discussing
today.
That
is
important
before
the
formation
of
a
working
group
and
I'll
give
a
few
minutes
for
that,
and
then
I
think
we
will
shift
into
we'll
do
some
word
smithing
on
the
charter
live.
We
still
have
a
half
an
hour
left
and
that's
always
good
fun,
but
that
may
let
some
of
the
112
people
that
might
be
bored
watching.
F
I
have
a
question
as
to
whether
it
should
all
be
in
scope
to
update
7671
a
little
bit
with
hindsight
from
you
know,
seven
years
of
deployment
experience
should
that
be
re-examined
at
all,
or
do
we
just
assume
it's
close
enough?
It's
not
so
bad,
but
there
are
things
I
wish.
I
would
have
done
differently.
A
Yeah,
so
I
mean
certainly
I
understand
that
that
viewpoint,
my
my
read
of
of
how
hard
that
would
be
would
be.
That
would
be
dangerous
to
try
and
undertake
revamping
the
server
side
too,
and
that
I,
I
suspect,
that
a
future
7671
biz
you
know,
might
come
out
and
could
go
into
a
future
charter.
But
I
think
if
we
try
and
tackle
that
along
with
client
side
dane,
it
could
be
problematic,
but
you're
right.
We
could
also
run.
A
We
run
the
risk
of
of
needing
to
violate
7671
at
the
same
time
or
past
documents,
and
I
think.
G
G
Could
have
supported
exactly
what
you
said
wes.
What
we
were
talking
about
here
is
a
client
side.
Let's
focus
on
client
side.
If
it
turns
out,
we
are
engineering
our
way
and
we
realize
oh,
no.
We
really
cannot
continue
based
on
the
constraints
we
all
agree
on
and
we
got
to
touch
the
server
side.
Let's
revisit
that,
potentially
with
a
recharger
exercise,
but
the
going
in
position
of
opening
up
the
server
side.
I
think
we
will
definitely
struggle
to
come
up
with
come
up
with
a
manageable
scope.
A
Okay,
great
any
other
last
comments.
A
So
if
we
were
going
to
remove
iot
so
for
those
that
don't
want
to
help
actually
word
smith
charter
text
and
fight
over
minor
word,
changes
feel
free
to
leave.
I
appreciate
your
attendance
and
I
appreciate
we
all
appreciate
your
attendance
and
especially
those
that
spoke
up
willing
to
support
for
those
that
do
like
commute.
Committee-Based
wordsmithing
stick
around
all
right.
We
still
have
a
half
an
hour
left
and
we
can
already.
G
After
we
do
a
little
bit
of
committee-based
wordsmithing,
I
mean
I
would
like
to
ask
the
participants
that
are
here
or
what
they
think
of
that.
That
would
be
a
strong
signal
if
we
could
exit
exit
kind
of
this
meeting
with
some
texts
that
we
all
agree
on
here.
A
Yep,
I
think
the
people
that
care
about
the
wordsmithing
will
stick
around
and
give
you
support,
so
I
am
going
to
leave
off
the
whole
renaming
thing.
I
think
that
we
will
come
back
to
that
so
with
respect
to
whether
iot
is
in
the
title
or
not,
is
probably
beyond
scope
for
what
we
want
to
handle
in
the
next
30
minutes
and
roman
and
michael,
and
I
will
kibosh
afterwards
about
whether
that's
a
good
thing
to
do.
A
It's
a
very
valid
point.
I
do
like
dance
that
works
well,
but
I
think
russ
healthy,
brought
up
a
point
that
renaming
working
groups
can
be
a
pain,
so
let's
try
and
tackle
the
internet
of
things
stuff
first,
because
I
think
that
that's
what
has
caused
the
most
discussion
today
with
respect
to
things.
So
I
will
note
that
that,
in
the
background
in
the
challenge,
you
know
in
response
to
the
challenges
related
to
the
ambiguity
between
different
cas
named
identities.
You
know,
issued
by
the
same
by
two
differently
named
cias.
A
For
example,
application
owners
frequently
choose
to
onboard
iot
device,
client
identities.
That
is
more
a
problem
space.
If
we
look
down
at
the
scope
of
work,
you
know
iot
isn't
mentioned
anywhere
right.
So
maybe
maybe
that's
actually
the
right
thing
to
do.
I'm
sorry
for
thinking
out
loud,
but
essentially
we
should
start
from
the
bottom
up
right.
A
What
is
the
scope
of
the
work
based
on
all
the
discussion
that
we
just
had
and
we
can
more
sort
of
the
top
to
include
potentially
more
examples
than
than
iot,
as
I
think
was
discussed
on
the
jabber
list?
There's
a
lot
of
people
that
want
to
include
iot,
at
least
as
an
example,
and
I
think
that
makes
perfect
reasonable
sense.
A
A
C
Deliverable
you
want
to
even
go
further
down
the
thing
that
I
would
imagine
is
having
to
find
how
to
do
all
the
tls
and
how
to
do
this.
Other
things
that
someone
might
wish
to
write
an
applicability
statement,
or
maybe
it's
almost
an
architecture
that
basically
captures
the
solution
space
that
was
examined
by
the
taxi
situation.
A
That's
a
good
point,
so
maybe
the
architecture
document,
which
has
always
been
somewhat
nebulously,
defined
right.
So
michael,
is
there
any
words?
You
know
that
we
should
add
to
architecture
besides
architecture.
Are
we
looking
for
framework
examples,
I'm
blanking
on
sort
of
the
right
text.
There.
C
A
We
may
have
lost
you
for
a
second
you
blinked
out,
but
you're,
okay,
so
maybe
architecture
and
examples
example,
deployment
scenarios.
A
If
you
spelled
that
right
now,
hank
I
apologize.
S
Hey
this
is
hank,
so
you
are
shying
away
from
the
term
use
case
here
deliberately.
In
that
case,
user
scenarios
or
deployment
scenarios
are
fine,
but
why
not
give
a
few
example
use
case
says
at
the
start.
I.
C
A
Okay,
so
use
cases
so
things
like
io,
io,
t,
smtp,
client,
exactly
yeah
yeah.
S
This
fits
and
then
I
think
actually
I
have
to
highlight
that
hannah
said
that
he
would
be
happy
to
work
with
anybody
with
embed
tls
on
this,
so
that
would
be
somehow
complementing
text
writing
with
tangible
things.
So
yeah
would
be
nice.
S
That's
complementary
information,
not
not
for
text.
C
Actually,
I
I
I
would
be
quite
happy
to
have
the
word
industrial
iot
somewheres
in
in
the
text
here.
I
don't
think
it
necessarily
needs
to
go
here,
but
I
think
that
it
definitely
goes
it
needs
to
go
in
the
document.
I
think
that
would
be
helpful
to
as
people
said
it's
you
know
changing
all
the
time.
Well,
industrial
iot
is
not
changing
that
quickly.
A
Okay,
bill
woodcock.
Can
I
call
you
out
specifically?
Is
there
a
particular,
you
said
that
you
really
wanted
this
and
you
ran
a
completely
different
type
of
infrastructure
than
a
lot
of
what
we're
talking
about
today.
Is
there
a
particular
use
case?
You
really
want
this
for.
N
So
the
the
two
big
ones
are
for
authoritative
to
authoritative
server,
authentication
of
the
receiving
side.
So
a
lot
of
people
contractually
require
the
receiver
of
a
zone
file.
That's
on
transfer
to
not
let
it
go
any
further.
A
lot
of
people
get
really
paranoid
about
zone
enumeration
and
that
kind
of
thing,
t-sig
keys
or
everybody
would
like
to
move
beyond
t-sig
keys.
N
So
what
we
need
is,
I
mean
t6ks
are
great
for
what
they
are
and
they
got
us
a
long
ways
but
yeah.
So
we
need
authoritative,
servers,
they're
receiving
zone
transfers
to
be
able
to
authenticate
themselves
to
the
the
master.
N
Servers
are
sorry,
whatever
the
the
new
politically
correct
word
for
the
originating,
authoritative
server
and
then
the
second
case
is
recursive
servers,
so
you
got
hundreds
of
millions
of
users
out
there
using
something
and
we
got
to
be
able
to
distinguish
between
users
and
attackers,
and
we
got
to
be
able
to
distinguish
between
people
who
paid
their
bill
and
not
paid
their
bill.
N
A
N
Well,
the
recursive
is
stubbed
to
recursive
or
caching
to
resources.
A
N
But
but
again
I'm
I'm
honestly
not
for
naming
all
these
use
cases
at
this
level.
I
I
think.
N
A
A
A
A
Okay,
so
I
think
that
we're
good
for
deliverables
like
we
don't
need
to
change
anything
we're
talking
about
paying
for
these
are
really
client
certificates,
so
we'll
we'll
change
it
from
from
device
to
client
to
make
it
a
little
bit
more
generic
and
then
dane
for
tls
client
authentication.
A
So
those
can
be
two
separate
drafts,
colin.
Oh,
he
went
away.
A
Of
work,
there
was
sort
of
some
notes
earlier
I'm
going
to
go
back
to
this,
even
though
I
I'm
not
sure
that
there's
anything
to
change,
but
for
any
of
these
texts
do
we
feel,
like
things
need
to
be
improved
upon
here.
There
was
other
ones
before
that
were
in
the
chat
saying
leave,
as
is.
F
G
G
No,
the
week
included
the
future
work
bullet
previously
to
to
help
us
down
scope
to
the
three
we
have.
If
we
all
are
saying
listen,
we
accept
that
we
may
have
to
recharter
in
the
future.
Why
do
we
have
to
list
what
we
could
potentially
work
on
at
some
future
date?
We
could
have
as
wide
of
a
scope
as
we
want.
A
Yeah,
well,
we
were
trying
to
to
leave
out
the
eep
and
some
of
the
other
mechanisms
that
were
you
know,
truly
next
steps
out.
That
was
that
was
sort
of
the
purpose
behind
this
text
originally,
but
victor
is
your
hand
still
up.
I
didn't
put
it
down
no
jack.
A
A
A
Okay,
where
are
you
wanting
me
to?
I
don't
have
a
ball
there
wherever
it
says,
certificates.
A
Q
Q
Yep
now
we
can
okay
thanks.
So
I'm
good
about
you
know
future
work.
Just
alluding
to
you
know
other
protocol
services,
but
we
should
we
should
allow
for,
for
you
know,
links
to
be
to
be
made
to
those
other
protocol
services
and
to
that
end
I
kind
of
liked
dance
because
it
was
network
clients
everywhere
and
now
we're
going
back
to
adding
tls
in
front
of
everything,
so
is:
can
we
have
deliverables
that
are
not
necessarily
for
tls
client
certificates?
Q
A
Think
romano,
hopefully
back
me
up
here
there
there
is
a
certain
amount
of
if
we
try
and
reframe
how
to
do
all
object,
signing
we'll
end
up
spinning
for
a
long
time,
and
that
doesn't
mean
that
we
can't
reuse
things.
A
But
so
my
my
personal
belief
is
that
that
wide
of
a
charter
where
we
just
say
we're
going
to
authenticate
any
client,
any
server
is
a
much
more
challenging
problem
to
get
wide
agreement
on
and
that
we
should
start
specifically
with
with
tls
clients,
because
that's
how
dane
was
designed
if
we
want
to
go
back
and
do
you
know,
dns
object,
verification,
you
know
more
generically,
that's
no
longer
dane
right.
Dane
was
specifically
for
tls.
A
So
I
guess
you
know
my
view
is
in
roman.
I
would
love
to
hear
your
ads
perspective
on.
That
is
that
that
would
be
a
little
too
wide
to
accomplish
stuff
on.
G
F
We
do
have
dane
for
things
other
than
tls,
already
only
very
experimental
right.
We
have
the
s
prime
and
open
pgp
dane
records,
so
there
is
some
precedent
for
day
and
beyond
tls,
but
no
known
deployment.
Really,
although
there
are
some
people
even
using
the
open,
pgp
and
s5
stuff,
it's
very
narrowly,
it
didn't
get
off
the
ground
really.
A
H
Toward
dane
yeah,
something
like
that.
A
L
Sure
so
yeah
I'm
going
to
comment
on
that
in
a
minute,
but
I
was
going
to
follow
up
on
the
question
about
dane
being
limited
to
tls,
but
victor
beat
me
to
it.
I
was
going
to
point
out
this
open
pgp
key
and
s.
My
may
so
dane
is
not
really
only
about
tls.
I
mean
there
are
other
use
cases,
but.
L
Records,
but
on
the
deliverables
I
was
a
little
bit
confused
about.
Can
you
scroll
down
those?
Are
those
the
three
items
or
okay,
so
a
little
bit
confused
about
the
difference
between
the
dane
for
tls
client
certificates
and
keys
and
client
authentication,
and
then
occurred
to
me
later
that
here
we're
talking
about
the
two
current
drafts,
which
are
actually
the
first
one
is
dane
for
tls
client
authentication.
The
second
was
a
tls
extension
to
convey
dane
client
identity.
L
I
think
that's
what
was
meant
to
be
there
originally,
so
I
would
advise
putting
that
back
in,
because
those
are
the
two
active
drafts
that
we
are
trying
to
complete
right
and
if
there's
other
items,
we
want
to
add
there.
That's
fine
with
me,
but
those
I
think
those
two
things
should
be
covered
at
the
very
end.
A
F
I
think
actually,
the
third
item
should
be
reverted
right.
We
have
the
because
now
we've
lost
the
dane
client
off
publishing
in
dns
and
the
like
right.
So
we
have
the
client
extension.
No,
no,
but
but
also
the
separate
draft
is
in
fact
specifying
how
to
publish.
Is
that
what
you
mean
by
key
management
practices
to
miki
management
practices
sounds
like
you
know,
lifetime
and
rollover,
rather
than
where
it's
published,
and
how
it's
mapped
to
dns
so
and
that's
separate
from
the
tls
extension
right.
So
I
think
this.
F
A
L
F
E
L
Drafts
the
thing
that
victor
was
pointing
out
is
the
original
two
drafts
was
the
first
one
was
tls
client
authentication
via
dane
tlsa
records
that
showed
you
how
to
publish
client
gain
lsa
records
and
used
tls
to
authenticate
dain
clients,
and
the
second
was
the
tls
extension.
So
those
are
the
two
of
the
work
items
that
we
were
originally
planning
to
do
so
the
client
key
management
practices.
A
So
the
point
being
is
that
the
first
one
was
supposed
to
be
publishing
about
publishing,
dane
records
in
dns
for
clients,
and
the
second
one
was
a
tls
extension
to
you
know
provide
those
names
to
servers.
So
that's
the
dumbed
down
text
of
what
we're
trying
to
accomplish.
If
I've
followed
everything
correctly.
A
Yet
so
remember
this
is
this:
is
working
group
forming
meaning
we
may
change?
You
know
the
the
scope
of
the
original
proposed
drafts
according
to
the
needs
of
the
working
group,
so.
H
Ben
schwartz,
so
I
was
just
trying
to
reframe
this
line
about
device
keys
in
a
way
that
that
seemed
to
I
was
trying
to
capture
the
the
intent
behind
that
framing,
but
I
may
not
have
understood
what
the
intent
was
so
for
what
it's
worth.
I
think
you
know
now.
I
think
both
of
them
are
misnamed.
H
I
think
probably
we
need
so.
We
need
a
deliverable
for
how
to
publish
how
to
publish
dane
gain
tlsa
records.
Let's
be
specific.
H
The
the
tls
extension
we're
talking
about
is
not
is
not
required.
Right,
like
the
existing
dane
as
it
exists
today
is,
is
totally
sufficient.
You
don't
need
a
tls
extension.
The
tls
extension
is
an
optimization
or
possibly
applicable
in
certain
cases.
If
you
believe
that
the
the
other
end
point
can't
do
its
own
dns
lookups,
and
it
has
not,
it's
not
client
specific,
at
least
not.
N
H
Well,
so,
okay,
the
other
endpoint,
is
not
able
to
it.
It
turns
it.
It
avoids
some
denial
of
service
attacks.
I
guess
you
could
say,
but
that's
that
that
that's
not
the
the
main
point
from
my
perspective,
so
I
think
the
okay,
I
think
the
things
we
actually
want.
Yeah.
E
H
Client
key
management
thing
that
was
just
me
reading
what
what
I
thought
the
charter
said
before
generalized
past
that
you
know
not
for
iot
okay.
So
I
think
that
I
think
that
what
we
actually
want
here
is
is
very
specific
points
like
we
want
to
deliver
a
a
protocol
that
allows
tls
clients
to
identif
to
identify
themselves
by
dane,
and
we
want
a
tls
extension
to
deliver
dnsec
chains
during
dane
authentication.
A
A
A
Well,
the
extension
was
to
name
something
that
couldn't
be
derived
in
some
other
way.
Right
was
my
understanding
of
the
need
for
the
extension,
but
I
think
that
we're
gonna
rattle-
and
we
don't
really
have
enough
time
at
this
point
to
get
through
this.
So
let
me
run
through
the
remaining
people
and
then
I
think
that
we're
going
to
have
to
take
you
the
fine-tooth
comb
to
the
deliverables
to
the
mailing
list
bill.
N
The
whole
key
management
thing
from
the
operator
perspective.
What
I
hear
is
everybody
saying
that
there
are
two
pieces
to
this:
one
is
the
ability
to
authenticate
users
once
you've
got
a
dane
record
for
them.
The
other
is
the
ability
to
provision
keys
out
to
users,
two
very
separate
problems.
Everybody
recognizes
them
with
separate
problems.
Nobody
wants
to
try
and
fix
everything
in
one
draft
and
in
principle
I
am
opposed
to
anything
that
slows
down
the
two
existing
drafts.
N
A
Interesting
point:
okay.
I
I
understand
that
schumann.
L
So,
just
to
answer
ben
schwartz,
the
tls
extension,
let's
make
sure
we're
talking
about
the
right
tls
extension,
the
tls
extension
redane
client
identity
is
not
always
required,
but
could
be
required
in
certain
circumstances.
For
example,
if
you're
trying
to
do
raw
public
key
authentication,
there's
no
client
x509
certificate
from
which
the
client
identity
can
be
extracted,
so
you
do
need
it
there
yeah.
I
think
that's
what
I
wanted
to
point
out.
Thanks.
A
Okay,
good
point,
schumann!
Thank
you.
Victor
you're
gonna
get
the
last
word
of
the
day.
Ooh
victor
just
went
offline,
nope
victor's
back
victor.
You
get
the
last
word.
A
All
right
well
hearing,
not
victor,
I
think
we
get.
We
made
a
lot
of
progress.
You
know
on
the
charter,
even
in
the
last
half
an
hour,
but
clearly
we
need
more
to
be
done
for
the
for
the
working
group
mailing
list.
We
need
concrete
suggestions,
not
complaints
for
what
needs
to
be
changed
in
the
charter,
so
we
will
do
a
last
round
of
charter
bashing
in
on
the
mailing
list.
A
Thank
you
all
for
coming,
but
we
please,
if
you're,
going
to
if
you're
going
to
talk
about
the
charter,
please
give
specific
proposals
on
what
you
need
to
change.
We
have
edited
this
charter
for
far
far
far
too
long
at
this
point
and
the
only
way
to
make
forward
progress
is
not
through
complaining
what
you
know
is
or
good
or
bad,
but
rather
this
is
what
you
know.
My
proposed
changes
so
we'll
take
that
to
the
mainland
list.
Thank
you
all
for
coming.