►
From YouTube: IETF115-DANCE-20221110-1530
Description
DANCE meeting session at IETF115
2022/11/10 1530
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
A
So
while
we
get
started,
I'm,
Wes,
hertiger
and
I'll
turn
it
over
to
Joey
here
in
a
minute
that
today's
graphic
every
time
I
have
these
skewed
up.
Graphics
and
I,
keep
finding
better
stuff
and
I
have
to
thank
Michael
Richardson
for
actually
finding
this.
He
actually
saw
this
sticker
on
somebody's
laptop
and
actually
sent
me
a
picture
of
it
and
I
assume
you
found
like
the
actual
Source
image
on
Amazon
or
something
yeah.
So
so
this
is
today's.
Today's
graphic
is
sponsored
by
Michael
Richardson.
B
All
right,
so,
let's
get
this
party
started
so
hi
everybody
welcome
to
this
ITF
session
of
Dance.
B
We
are
your
chairs
with
and
Joey
a
reminder
for
the
people,
the
new
arrivals,
to
scan
the
QR
code
to
make
sure
that
you
are
signed
in
the
blue
sheets
next
slide.
Please
all
right!
So,
let's
begin
by
mentioning
the
note
wheel,
which
I'm
sure
most
of
you
are
already
pretty
familiar
with,
either
with
the
at
this
ITF
meeting
or
at
the
previous
ones.
B
This
is
to
highlight,
for
you
guys
to
remember
that
there
could
be
some
legal
repercussions
right
or
some
legal
implications
to
some
actions
here
right
to
keep
it
to
keep
that
in
mind.
Right,
Wes
next
slide,
please,
and
then
the
second
part
of
the
note
will
is
to
highlight
some
important
BCPS,
like
BCP
54.
That
includes
the
code
of
conduct
which
is
mentioned
in
the
next
slide,
all
right.
So
the
most
important
thing
here
is
to
continue
treating
everybody
with
respect.
B
This
group
has
constantly
been
quite
respectful
right,
so
let's
keep
that
going.
Let's
try
to
speak
slowly
and
clearly,
remembering
that
not
everybody
is
an
English
native
speaker
right
so
on
that
on.
That's
on
that
note
and
also,
let's
not
be
afraid
to
ask
somebody
to
repeat
themselves
or
ask
slower
or
speak
more
clearly,
all
right,
similar
reasoning
for
whenever
we
are
discussing
stuff
right
and
well
a
couple
more
notes
up
there
next
slide,
please
yep.
B
So
here
we
have
some
dance
information
right,
pointing
to
the
data
tracker.
The
mailing
list-
hopefully
you've
all
already
survived-
I
mean
subscribe
to
it.
B
And
also,
hopefully,
you
will
survive
the
mailing
list,
discussions
and
yeah,
hopefully,
you've
also
read
at
least
the
abstracts
of
the
of
the
three
drops
that
the
working
group
is
currently
dealing
with
next
slide.
Please
so
another
reminder
that
this
session
is
being
recorded
and
very
very
important
for
everybody
to
remember
to
wear
your
masks
unless
you're
actively
at
the
mic
right
and
then
in
that
case
it
will
be
optional.
B
So
here
this
couple
of
notes
for
both
in
person
and
remote
participants
and
I
think
we
can
proceed
to
the
next
slide
all
right.
So
this
is
for
the
agenda
and
I
don't
know.
First
West
did
I
miss
anything
in
the
previous
slides.
No,
all
right.
A
All
right,
so
thank
you.
First
off
for
the
note
takers,
Jim,
Fenton
and
Tim
wazinski.
You
have
both
offered
to
take
notes,
I'm
sure
that
they
would
appreciate
help.
In
fact,
I
know
that
they
would
the
note
taking
application
is
a
little
pencil
icon
on
the
agenda
and
the
more
people
that
help
the
easier
it
is
for
everybody.
A
So
we're
going
to
start
off
with
the
sort
of
the
current
document
status
and
then
talk
about
working
group
activity
level
discussions
a
little
bit
as
we
always
do,
and
then
the
two
presentations
we
have
today
are
sort
of
one
is
about
the
architecture
and
the
other
is
about
sort
of
some
dance
use
cases
we'll
have
an
open
mic
for
anybody
that
wants
to
discuss
other
things
and
then,
if
you
guys,
don't
use
it
all
of
the
time
the
scary
chairs
are
going
to
introduce
a
topic
because
because
you
guys
didn't
give
us
enough
agenda
material.
A
So
what's
our
current
document
status?
We
have
three
documents:
one
is
the
ietf
dance
architecture
and
then
the
two
other
are
the
TLs,
Dane
client
ID
and
the
Dane
client
ID
certificate.
A
The
last
two
we
have
just
put
into
last
call
yesterday
so
awesome
that
we
have
actually
progressed
to
the
last
call
stage
in
two
of
the
documents.
These
came
in
the
door
to
dance,
you
know
pretty
well
established
and
it
was
time
to
kick
them
in.
So
we
set
a
three-week
last
call
and
Joey
and
I
did
it
I
want
to
say
two
days
ago,
so
it
puts
the
three-week
expiration
on
November
29th.
A
So
please
do
read
comment
most
importantly
indicate
whether
there
are
changes
needed
and
even
if
you
see
nothing
wrong,
please
indicate
on
the
mailing
list
that
you
are
happy
with
the
documents
and
they
are
ready
to
progress
and
you
support
them.
A
We
need
active
counts
of
who
has
read
it.
The
mailing
list
activity
is
still
generally,
you
know
pretty
slow.
There
was
actually
a
fair
amount
in
September,
but
only
three
in
October
and
and
they
were
announcement
related
stuff,
not
actually
active
discussion
and
zero
in
August,
but
everybody
takes
vacation
in
August.
So
we
still
wonder
you
know,
maybe
there's
just
not
that
much
to
do,
but
we
have
so
many
interesting
use
cases.
A
We'd
love
to
see
them
discussed
more
so
with
that
we
are
going
to
turn
it
over
to
the
to
I.
Guess
we
agreed
you
were
going
to
go
first
right,
okay
with
the
architecture
document.
So
let
me
load
your
slides
and
you're
welcome
to
come
up.
C
So
I'm
Ole
Johansson
I
got
dragged
into
this
by
Ash
who
started
it
all
by
not
keeping
my
mouth
shut
and
now
I'm
standing
here
we
can
take
the
next
slide,
we're
going
through
the
documents.
C
The
way
I
see
us
sorting
out
the
documents,
because
I
have
a
big
problem
with
the
current
architecture
document
is
to
have
one
document
that
covers
the
general
idea
of
dancing
right,
an
architecture
document,
and
then
we
have
documents
now
about
secure
dancing,
meaning
the
TLs
changes
and
I
would
like
to
see
how
to
dance
a
document
that
is,
if
I
have
my
own
protocol.
How
would
I
implement
this?
How
would
I
write
a
document?
What
are
the
requirements
for
applying
dance
to
all
kinds
of
protocols?
C
C
C
D
A
E
Hi,
my
name
is
Rick
Moran
I'm,
a
modern
dancer,
but
also
I
was
with
this
group
when
it
was
founded,
lost
track
of
it
I'm
afraid
what
we
discussed
in
the
beginning
is
will
be
really
attractive
to
have
users,
just
people
behind
browsers
or
behind
a
milltool
to
also
be
able
to
use
something
that
t
less
and
authenticate
towards
towards
an
end
point
I
didn't
find
it
back
in
the
architecture
would
search
it.
Such
an
extension
be
welcomed.
Is
that
the
sort
of
thing
you're
asking
about.
E
The
dance
standards
speak
predominantly
about
devices
that
register
as
clients.
It
doesn't
speak
of
end
users,
people
sitting
behind
desks,
and
that
is
the
sort
of
thing
we
discussed.
Okay,.
E
That,
okay,
so.
C
E
C
C
I've
seen
in
the
documents
we
have,
that
all
of
them
refer
to
a
very
flat
namespace
and
I
talked
with
some
of
the
DNS
gurus
that
I
regularly
meet
for
various
reasons
from
fish
and
ships
to
real
DNS
discussions,
and
they
say
that.
Well,
you
really
want
to
consider
that
if
you're
going
to
have
a
lot
of
entries,
you
may
not
need
a
flat
namespace.
You
need
a
tree
of
some
kind,
like
enamor
ptrs,
for
DNS
to
be
able
to
manage
this
properly.
C
For
me,
this
is
how
to
dance
a
requirements
document
for
setting
up
various
records
types
and
so
next,
and
if
we
like
Rick
Mansion
producers
into
dancing,
then
we
really
need
to
consider
how
we
can
protect
the
privacy
of
these
I've
checked
around
and
talked
with
people,
and
there
are
a
couple
of
documents
describing
ways
to
handle
this
by
putting
hashes
into
DNS
instead
of
saying
oag
at
Edwina
net,
or
something
like
that-
and
this
could
also
be
mentioned
in
the
requirements
document
on
protocol
implementation.
C
E
Know
if
it's
okay
to
interrupt
Rick
from
Ryan
modern
dancer,
one
one
other
way
typical
of
keyless
a
records
would
be
to
have
a
root
certificate.
Authority,
that's
representing
their
plans.
Yep.
D
C
H
C
I
I'm
not
too
customer
just
just
a
check
on
the
previous
comment:
I'm.
Actually,
the
author
of
this
RFC.
I
There
is
some
subtlety
there,
because
with
SMTP
on
the
email
level,
There's
issues
where
Paul
with
a
capital
P
is
a
different
endpoint
and
Paul
with
a
lowercase
p
and
in
DNS
you
have
no
K
sensitivity.
So
so
there
are
some
more
complications
if
you're
doing
anything
with
users,
mapping
to
DNS.
C
So
now
I'm
stepping
on
shimon's
toes
a
little
bit
here,
but
I
prepared
him
for
that.
The
the
clients
are
document
we
could
take
into
a
implementation
requirement
document,
but
since
we're
entering
last
call,
we
may
have
to
reconsider
that
it
was
just
an
idea.
C
We
need
to
find
candidates,
people
that
can
help
us
write
protocol
specific
documents,
so
we
at
least
get
a
few
up
on
the
table
early.
So
we
can
test
our
ideas
and
focus
on
where
we
have
energy
in
the
group,
not
just
all
the
ideas
that
was
in
the
original
architecture
document.
C
We
need
at
least
one
for
the
underscore
service
and
one
for
underscore
device,
one
document
each
one
example.
If
we
still
want
them
both
and
maybe
discuss
if
we
want
some
other
tags,
I'm
kind
of
hesitant
for
underscore
service,
because
it
kind
of
syntactically
is
very
close
to
the
tags
used
for
SRV
records
and
it's
only
half
the
tag
for
SRV.
We
have
service
and
protocol
and
right
now
the
document
refers
to
that
registry,
but
only
use
half
of
it
and
we
need
to
figure
out.
C
If
there
are
other
patterns
we
can
use
not
only
email
addresses
or
device
IDs
or
so
how
to
code
an
identity
into
a
DNS
name,
but
as
well
said
we
need
energy.
So
we
maybe
we
should
try
to
get
more
practical
closer
to
the
real
application
problem.
We
do
need
a
TLS
extension,
so
Sherman
a
big
thank
you
for
promoting
that
and
moving
that
forward.
But
now
we
need
to
start
looking
to
rest
next.
C
I
know
that
there
was
some
code
somewhere
at
some
point.
I
lost
track
of
it,
but
do
we
need
to
prepare
some
cool
stuff
happening?
Maybe
a
hackathon
next
to
ATF
and
look
into
some
libraries
like
I
mean
this
won't
get
anywhere
unless
open
SSL
and
the
libraries
people
use
have
it
so
curl
open,
SSL,
some
server,
some
co-op
libraries,
something
need
to
figure
out
how
this
works
and
how
big
changes
we
need
to
do
to
the
existing
platforms.
A
Any
questions
that
is
the
last
slide
any
discussion
on
the
architecture
document
originally
in
the
charter.
During
the
buff,
we
agreed
that
the
the
architecture
document
would
be
part
of
the
deliverables,
but
we
knew
that
the
other
ones
were
sort
of.
You
know
much
more
done,
but
this
really
describes
the
use
cases
that
most
people
had
a
hard
time
wrapping
their
head
around
by
just
reading
the
protocol
documents.
So
hence
this
is
an
important
one.
Jim.
F
Hi
Jim
Fenton,
as
I,
was
reading
through
the
architecture
document.
I
got
to
this
section
on
use
cases
and
I
thought.
Oh
great.
This
is
going
to
describe
the
problem
that
we're
solving
and
it
seems
to
just
dump
jump
right
into
details
without
describing
the
problem,
so
I'd
like
to
suggest
that
some
use
case
information.
You
know
you
know,
probably
the
problem
statement
therapy
be
included
somewhere.
C
J
K
Michael
Richardson,
so
one
of
the
things
I
quickly
noticed
today
was
that
there
are
other
documents,
don't
actually
reference
the
architecture
document
that
might
be
intentional
so
that
they
don't
get
caught
in
that.
But
I
suspect
it
should
be
a
normative
reference.
A
So
so
let
me
ask
a
follow-up
question
to
that:
I,
don't
remember
the
intended
status
of
the
architecture
document,
but
there's
a
good
question
whether
it
be
proposed
or
informational
and
I.
Think
I
could
make
arguments
either
way.
So
I
will
let
the
working
group
decide
what
to
do,
but
is
there
something
in
the
architecture
document
that
should
be
normatively
referenced
like
you
cannot
and
you
cannot
do
or
implement
the
other
protocol
pieces
without
it
without.
K
Having
read
it
that
it's
the
having
read
it,
that's
the
point:
it's
you
know,
so
we
may
not
have
protocol
content
but
generally
they're
informative,
not
not
pro,
not
proposed,
and
so
referencing
them.
Non-Normatively
is
okay.
K
So
just
something
we
should
think
about
before
we
get
too
far,
for
the
simple
reason
that
if
we
suddenly
change
things,
then
we're
going
to
change
our
our
timing
and
our
process
for
these
documents.
So
I
think
that's
an
important
part.
So.
K
I'm
going
to
say
exactly
that
yeah
so,
but
I
thought
it
should
be
useful
to
do
that
as
well.
The
the
other
thing
that
that
I
I
wonder
about
and
based
upon
my
understanding
of
where
we're
going
is
that
one
of
the
things
that
this
is
totally
unrelated.
K
Sorry,
second
comment:
one
of
the
the
scenarios
that
we
imagined
is
that
a
manufacturer
creates
device
populates
it
with
certificate
which
they
populate
into
manufacturer's,
DNS,
Zone
and
device,
says
I
am
device,
4378
blah
blah
blah
blah,
and
that
gets
us
out
of
the
whole
a
lot
of
our
our
issues.
K
Okay,
so
that's
a
kind
of
well-established
pattern.
The
question
is:
are
there
scenarios
where
owner
operator
of
device
actually
wants
to
own
that
zone
and
I
think
that
it
doesn't
matter
from
the
other
end's
point
of
view
from
the
the
there
what
it
is?
But
if
that
is
that,
if
it
is
a
scenario
that
we
want
to
support,
then
we
probably
need
to
decide
somehow
it
goes
somewhere
and
I'm
actually
not
sure
that
it's
not
another
document
or
I'm,
not
even
sure
it
requires
any
text.
K
But
it
is
a
different
pattern
of
who
trusts,
who
and-
and
it
also
matters
who
you're
talking
to,
and
there
was
a
bunch
of
of
comments
about
you
know
browsers
and
this
kind
of
stuff
I'm
pretty
sure
that
I'm
not
going
to
get
a
browser
with
a
ID
in
google.com
if
it's
Chrome
right
so
I'm,
pretty
sure
that
the
browser
use
case.
If
someone
has
that
that
the
DNS
identity,
that
I
assert
as
a
client
is
going
to
be
in
my
zone
or
in
some
friendly
zone.
K
K
K
It
just
works.
It
should
just
work
but
but
suddenly
says
well
but
hang
on
here.
What's
the
what's
the
relationship
that
I
have
or
what
are
the
other
things
and
I
think
we're
going
to
get
Security
review
feedback
on
that
question,
and
so
either
we
say
as
little
as
possible
or
we
wind
up
having
to
say
a
lot.
C
Well,
it
kind
of
borders
to
BCP,
but
your
question
is
basically
I
mean
if
I
have
a
device
ID
and
the
manufacturer
creates
an
entry
and
I
want
to
take
over
that.
If
I
create
an
answer,
should
it
be
my
zone
or
should
I've
been
his,
we
need
to
figure
out
what
we
want
right
and
do
we
allow
to
concurrent
the
entries
in
different
DNS
for
the
same
device.
C
K
K
A
Joey
just
pointed
out,
this
is
a
great
discussion
for
the
mailing
list
that
doesn't
have
enough
traffic
on
it.
So
Michael,
let's
start
a
thread
please
and
Ben.
G
If,
if
it
is,
if
the
Zone,
the
manufacturer
zone
is
still
live
basically,
and
if
the
manufacturer
goes
out
of
business
or
drops
this
product
line,
then
the
device
is
bricked.
So
I
really
think
we
should
not
end
up
in
that
situation
and
I
do
think
that
there
is
some
actual
protocol
level
work
to
talk
about
there,
for
example,
being
able
to
con
ask
the
device
in
a
standard
way.
A
Okay,
I
think
that's
a
good
point
too
I
mean
the
Tails
extension
covers
that
a
little
bit
too
again.
Having
these
discussions
on
the
mailing
list
would
be
absolutely
fantastic
and
I
think
I.
Think
one
of
the
takeaways
that
I
heard
from
this
conversation
personally
is
there
may
be
elements
of
the
architecture
document
that
might
actually
pull
into
some
of
the
protocol
documents
to
make
sure
that
the
protocol
document
is
Standalone
enough.
So
especially
I
hope
you
might
have
guidance,
you
know
with
that
of
what
pieces
might
be
injectable
into
the
other
ones.
C
I
would
personally
like
to
focus
on
those
should
take
your
documentary
get
in
that
into
shape
by
throwing
out
bits
and
pieces
and
leave
the
leftovers
somewhere
else
in
the
GitHub
repo
and
then
we'll
start
working
with
the
bits
and
pieces,
but
trying
to
get
an
architecture
document
that
is
easy
to
read
and
get
an
overview
of
the
protocol.
Like
we
said
earlier,
the
solution.
B
I,
don't
quite
remember,
but
was
the
GitHub
repo
studying
the
additional
resources
for
this
draft,
because
if
it's
not,
then
it
would
be
very,
very
good.
To
put
it
there.
A
J
Thank
you,
yeah
I.
Don't
have
science
am
I
ready
to
go
okay,
so,
although
I
may
refer
to
all
those
slides,
if
you
don't
mind
so
you
may
want
to
put
those
back
so
before
I
start
I
just
wanted
to
before
I
forget
I
wanted
to
quickly
mention
to
all
those
questions
about
implementations,
AF
Nick,
the
French
registry
actually
has
one
so
I
think
Sanders.
J
If
you're
here
you
are
yeah,
he
may
want
to
mention
that
when
he
speaks
later
on
so
I
just
want
to
put
in
a
plug
for
that
on
all
those
points.
So
the
architecture
document
I
agree.
It's
a
little
bit
unstructured.
In
my
view,
it
was
intended
generally
to
be
a
general
framework
to
describe
how
things
use
dance,
not
about
specific
application
use
cases,
but
over
time
what
happened
was
people
to
kind
of
describe
how
the
things
work
they
had
to
describe
applications.
J
So
that's
why
iot
came
in
and
various
other
things
and
I
think
one
of
the
prop
challenges
is
the
application.
Architecture
for
iot
may
be
significantly
different
from
something
else
like
SMTP,
Transport,
Security
or
Sith,
for
example.
So
that
makes
it
a
little
bit
challenging,
so
we
should
take
in
that
into
consideration
if
we
want
to.
As
you
suggested
separate,
we
have
a
separate
architecture
document
and
a
use
case
document,
so
we
need
to
figure
out
how
how
those
two
would
work
in
concert.
J
So
that
is
my
comment
about
that.
So
on
always
assertion
that
most
of
the
our
docs
document,
a
flat,
namespace
I,
don't
actually
think
I
agree
with
that.
The
record
name
format
specifically
defines
a
structure
that
is
very
amenable
to
hierarchical
structure.
Right,
so
I
would
like
to
Olay
to
read
the
document
and
tell
me
if
you
disagree
and
I
can
explain
to
you
why
that
is,
we
can
elaborate
and
I
can
show
you
examples.
J
A
I,
don't
remember
if
any
of
the
current
documents
really
discuss
handling
transfer
of
ownership.
So
when
a
device
moves
from,
you
know
one
manufacturer
to
be
owned
by
an
institution
that
that
or
that
wants
to
overtake
the
the
client
authentication
yeah.
J
They
don't
right,
so
that's
a
good
thing,
so
that
would
be
an
iot
iot
architecture.
Specific
discussion
that
doesn't
belong
in
the
two
protocol
documents,
I
wrote,
belongs
somewhere,
I
think
so
that's
a
very
good
point.
J
J
So
again,
the
draft,
if
you
read
the
draft
carefully,
it's
not
prescriptive
about
the
record
name
format,
so
it
shows
two
examples:
none
of
them
hashes
any
component
of
the
client
identity,
because
the
two
examples
were
a
service,
specific
identity
and
a
device
identity.
Presumably
those
are
not
as
privacy
sensitive.
J
So
if
a
Dane
client
application
we're
using
email
like
identities
or
sip
user
agents,
I
think
it
would
be
perfectly
appropriate
for
them
to
use
the.
What
about
the
truncated
hash
formats
that
you
have
in
your
document
and
and
ask.
J
Is
the
other
one
that
uses
that
format
I
think
right?
So
if,
if
it
helps
to
include
an
example
of
such
a
record
name,
then
we
can
do
that.
I
have
no
objection
to
doing
that.
Sorry.
I
Parlocks
just
you're
referring
to
the
the
open,
PHP
hashing
mechanism-
yeah,
that's
not
a
privacy
mechanism,
that's
just
a
normalization!
So
you
can
you
shouldn't
be
using
that
as
a
security,
that's
a
masking
or
hiding
identity
property.
It's
definitely
not
meant
for.
J
That,
okay,
fair
enough,
no
security,
right,
okay,
yeah!
So
there's
an
open
question.
Then,
if
you're
using
applications
that
have
privacy
sensitive
client
identities,
should
we
use,
should
you
be
using
this
protocol
at
all
right?
So
that's
another
question:
I'm
not
going
to
answer
that
now
people
want
to
weigh
in
on
that.
Please
do
so.
E
Yes,
it
would
be
helpful
to
have
an
example
for
a
client
at
using
youth
at
domain
name
example.
Okay,
personally,
I
would
also
be
interested
to
have
something:
that's
not
for
a
specific
service
like
I'm
happy,
but
also
to
have
something
that
just
says
in
general.
I
use
all
sorts
of
protocols,
and
this
is
the
identity
I'm
using
this
is
the
Dane
record
that
specifies
it.
E
I
do
not
care
or
do
not
feel
that
it's
in
line
with
my
privacy
to
publish
all
sort
of
protocols
I'm
using
so
maybe
something
with
a
wild
card
that
might
do
this.
J
But
yeah
yep
sure
so
yeah
I
guess.
The
question
is
that
discussion
does
that
belong
in
the
protocol
document
or
some
application
architecture
document?
We
have
to
figure
that
out
right
all
right.
So
let
me
Okay
so
your
other
comment
about
the
service
specific
identity,
only
including
one
half
of
an
SRV
record.
That's
true!
That
was
deliberate
because
we
thought
it
probably
won't
be
the
case
that
a
client
would
have
distinct
security
credentials
for
distinct
transport
protocols,
UDP
or
DCP
right.
J
Okay,
so
I
think
that's
the
bulk
of
my
comments
back
to
you
Olay
and
feel
free
to
engage
us
on
suggested
changes
to
the
core
protocol
documents.
Their
last
call.
But
you
know
we
can
take
additional
feedback
and
and
adapt
them
as
needed.
L
Hear
me
in
the
last
meeting
the
topic
came
up
of
having
yet
another
TLS
extension
that
asks
servers
to
solicit
a
client
certificate.
I
haven't
had
a
chance
to
progress.
That
is,
there
still
need
or
interest
in
seeing
that
move
forward.
J
Very
good
question:
Victor
yeah
I
think
you
anticipated
something.
I
was
about
to
say
so.
Michael
Richardson
and
I
just
had
a
chat
about
this
prior
to
this
meeting,
and
we
do
we
were
intending
to
put
out
a
draft.
So
this
is
the
TLS
extension
to
explicitly
solicit
a
Certificate
request.
Message
from
the
server
is
that
right.
J
I
was
Victor
agreed,
but,
yes,
we
are
planning
to
write
that
I
think
there's
several
people
who
have
come
up
with
use
cases
for
that
we
do
intend
to
do
that.
I
was
gonna,
make
an
attempt
to
put
it
out
before
itf115
I
failed,
but
we
will
do
it.
The
question
is
that
extension
is
more
General
in
nature
than
dance,
so
should
it
go
to
the
TLs
working
group
or
where
should
that
work
be
done?
So
that's
there
is
an
open
question
about
that.
A
J
Yeah
I,
agree
and
I
think
that's
all
I
had
oh
there's
one
last
topic,
so
the
other
thing
that's
come
up.
A
few
times
is
the
suggestion
about
doing
Dane,
Klein
authentication
another
way,
such
as
moving
the
authentication
to
the
application
layer
using
TLS
exported
authenticators
and
Channel
Finding
I.
Don't
think
I
didn't
see
any
appetite
for
for
for
proposing
such
a
mechanism.
But
anyone
wants
to
do
that.
J
So
this
is
so
that,
right
now
the
pr
authentication
happens
in
the
TLs
layer
right.
So
there's
a
mechanism
well
TLS
exported
authenticators,
where
you
can
do
it
at
the
application
layer
and
then
communicate
the
results
back
and
bind
it
to
the
TLs
Channel
underneath
right.
So
that
makes
it
there's
a
set
of
use.
J
Cases
like
I
can't
remember
all
of
them,
but
if
you
want
to
do
things
like,
you
know,
authenticate
with
a
different
certificate
later,
rather
than
a
different
identity
later
in
the
Taylor
stream,
or
a
variety
of
other
things,
you
can
do
that
right.
So
the
problem
I
think
this
poses
for
dance
clients
is
that
each
application
has
to
complicate
their
infrastructure
by
implementing
this
authentication
of
the
app
layer
rather
than
just
punting
it
to
the
TLs
layer.
Right,
it's
it's
easier
for
applications.
J
There
may
be
some
benefits
of
security
advantages
to
the
applicational
layer,
authentication
architecture,
but
I,
don't
I,
don't
see
anyone
jumping
up
and
proposing
to
do
it
that
way,
right
so.
D
L
Right
on
that
topic,
you
know
if
we
were
to
attempt
to
authenticate-
let's
say
email
users
to
their
submission
service,
then
indeed,
an
application
layer
authentication
makes
a
bit
more
sense
and
then
one
would
want
such
a
mechanism
to
ultimately
be
a
sassal
mechanism,
leveraging
tls's
export
capabilities
and
so
on.
So
we
would
design
a
new
Cecil
mechanism
that
incorporates
today.
On
the
other
hand,
if
we're
talking
MTA
to
MTA,
then
the
current
kind
of
ntls
that
client
auth
makes
more
sense.
J
Yep
thanks
and
I
think
that's
all
I
had
right.
E
Rick
foreign
I
I'm
still
figuring
out
what
you
mean
exactly,
but
when
it
hits
upon
authentication
and
extracting
either
identities
or
keying
material,
I'm
very
eager
to
look
at
that
at
least
and
not
say
no.
At
this
point.
E
B
Maybe
also
talking
a
bit
more
about
it
in
the
mailing
list.
Your
mom.
I
H
My
name
is
sandosha,
and
today
this
is
one
of
the
use
cases
for
the
dance
working
group.
So
lauravan
is
a
long
range
wide
area
network.
It
is
the
iot
technology
that
comes
under
the
lp
van
range.
Lp
van
is
local
right
area
network.
So
here
we
are
using
the
technology
as
low,
very
low
bandwidth
next
track.
Please.
H
So
lauravan
also
has
the
usual
challenges
like
in
other
iot
Technologies,
where
the
key
needs
to
be
shared
with
different
stakeholders.
So
these
are
the
root
keys
for
the
device
which
needs
to
be
shared
with
different
stakeholders
who
will
be
operating
at
the
IP
end.
So
that
is
a
problem,
and
that
is
a
problem
for
all
most
of
the
iot
Technologies.
So
next
slide
please.
H
So
this
is
the
architecture
for
lauravan,
it's
a
star
topology
where
we
have
the
end
device
and
the
end
device
is
connected
to
the
radio
Gateway
via
the
Laura
technology.
And
after
that,
in
the
internet
side
we
have
different
stakeholders,
a
different
servers.
Sorry,
the
NS
is
the
network.
Server
JS
is
the
joint
server
and
the,
as
is
the
application
server.
So
there
are
cases
these
different
servers
can
be
operated
or
managed
by
same
stakeholders
or
could
be
operator
or
managed
by
different
stakeholders.
H
So
what
happens
is
that
there
are
two
keys
here:
root
Keys
here.
One
is
the
network
key
and
the
application
key,
so
the
network
key
and
the
application
key
is
with
the
device
during
the
manufacturing
stage
and
after
that,
those
two
keys
are
AES.
128-Bit
symmetric
Keys
has
to
be
shared
with
the
stakeholders
in
the
internet
side
either
the
network
server
needs
to
have
the
network
key.
The
application
server
needs
to
have
the
application
app
Root
key
so
yeah,
so
this
enables
so
the
price
sharing
is
needed
to
enable
the
iot
device
onboarding.
H
So
the
com
once
the
for
communication,
the
the
communication
between
the
end
device
and
the
network
server
is
encrypted.
Why
are
the
session
Keys
generated
by
these
Network
root
key
and
the
communication
between
the
end
device
and
the
application
server
is
encrypted
by
the
session
Keys
generated
by
the
app
key,
so
that
is
for
end-to-end.
But
for
this
to
be
done,
we
have
the
JS,
which
is
the
join
server.
It
acts
as
the
AAS
server
authentication
and
authorization
server,
so
the
network
server
and
the
AS
application
server
needs
to
communicate
with
the
Js.
H
So
for
this
they
need
to
do
Mutual,
authentication
and,
as
per
the
lorovan
specifications,
how
the
network
server,
for
example,
the
network
server
and
the
joint
server
mutually
authenticate
each
other
is
not
normative.
So
it
is
up
to
the
implementer's
point
of
view
how
how
they
do
that.
So
what
we
try
to
do
is
that
we
wanted
to
do
with
the
web
pki
when
we
wanted,
when
we
do
with
the
whip,
pick
I
and
the
certificate
Authority
model.
We
found
out
certain
issues,
for
example
from
a
cost
point
of
view.
H
H
So
also,
we
were
not
able
to
use
certificates
like
let's
encrypt,
because
here
the
device
here,
the
identification
is
hierarchical
and
it's
like
a
Mac
ID
we
had
which
has
16
digits,
and
it
is
possible
that
there
is
a
point
between
these
16
digits
and
so,
let's
couldn't
do
it
more
than
eight
labels.
So
these
are
the
different
issues
that
we
found
out.
H
So
the
solution
was
that
using
selfline
certificates,
but
when
we
use
self-signed
certificates,
what
happens
is
that
there
is
a
requirement
for
all
the
servers
in
in
this
ecosystem
needs
to
get
from
one
root
CA,
and
that
is
an
issue
so
next
slide,
please
so
Dane
Comes,
This,
Dance
architecture
and
the
Dane
client,
ID
and
Lane
certificate
authorization.
H
Drafts
comes
as
a
solution
for
this
issue
where
we
need
not
have
a
single
root
CA
we
can
have
Federated
Cas
and
each
of
these
C
ecosystem
or
the
servers
could
have,
could
create
self-signed
certificates,
but
could
authenticate
between
the
servers
in
the
different
ecosystem
based
upon
client
or
add
an
identity.
So
we
had
an
implementation
and
this
implementation
has
been
presented
during
the
ietf
113
and
my
colleague
here
a
gal.
He
has
implemented
that
and
next
slide.
Please
excellent.
H
Sorry,
so
I
I'm
not
going
into
the
details
of
this,
because
these
are
already
been
implemented.
So
my
colleague
here
he
took
the
go
library
of
Dane,
tlsa
authentication
that
is
done
by
Shimon
and
he
developed
it
and
he
implemented
both
the
client
ID
and
the
client
certificate
draft.
So
these
are
the
details
of
what
has
been
done
so
this
we,
we
were
able
to
test
with
the
different
servers
which
had
a
root
CS
from
different
certificate
authorities
of
self-signed
certificates
and
were
able
to
mutually
authenticate
each
other
each
other.
H
So
that
was
a
point.
That
was
one
that's
why
we
are
here,
because
it
proves
that
the
Dane,
the
dance
working
group
documents
or
the
work
enables
Mutual
authentication
with
the
Federated
CS
and
yeah
ID
of
one
on
five
next
slide.
Please
we
were
sorry
yeah.
This
is
not
actually
client-side
authentication
but
because
for
the
I
from
the
end
device
point
of
view
it
needs
the
server
needs
to
be
authenticated.
H
So
my
colleague
here
implemented
that
also
he
tried
to
send
the
DNS
authentication
chain
from
the
server
side
to
the
device.
Even
though
the
network
is
very
constrained,
we
were
we
fragmented
the
complete
chain
to
so
that
the
device
can
authenticate
the
server,
but
I
think
this
is
not
part
of
the
dance
chart
on
it.
D
A
Thank
you
for
the
excellent
use
case.
Is
anybody
have
questions
about
it?
A
Joey
we
have
15
minutes
left.
Do
you
think
the
dance
working
group
is
ready
for
The
Talk.
D
A
A
See
first
off
protocol
start
is
just
this
fledgingly
of
specification
and
they're
not
able
to
dance
yet
they
have.
They
haven't
actually
done
much
in
life,
they're,
brand
new
and
so
first
they
must
learn
to
interoperate
and
play
nicely
together
and
they
get
together
and
they
play
and
they
learn
how
to
behave
and
be
nice.
A
A
A
A
A
A
Thank
you.
So
one
of
the
first
questions
is
I
am
planning
on
implementing
Dane
Technologies
right
you're,
an
implementer
I'm,
going
to
put
it
into
the
counting
Cube,
because
I'm
curious
how
many
people
out
there
are
actually
going
to
actively
work
on
this.
If
you
do
not
raise
your
hand,
that
means
that
you
are
intentionally
prohibiting
and
going
to
get
in
the
way
of
somebody
implementing.
So
just
don't
don't
use
the
do
not
raise
hand
button.
It
doesn't
make
sense.
A
All
right
so
excellent,
so
that
actually
shows
11
people
that
are,
you
know
actively
working
on
deploying
or
implementing
I
should
say
dance,
Technologies,
I
think
that's
very
good,
although
there's
eight
people
that
I
can
get
in
your
way,
so
I
watch
out
for
them.
But,
okay,
great
is
there.
Anybody
that
wants
to
speak
to
the
challenges
of
oops
did
I
just
make
the.
D
A
J
Well,
I'm
not
directly
answering
your
question,
but
I
was
just
reminded
that
I
think
Robert
Moskowitz
dropped
in
some
questions
earlier
today
about
Dane
and
did
we
about
dance
and
did
we
address
them?
I?
Think
one
of
them
was
he
wanted
to
ask
whether
we
should
Define
a
new
Dane
usage
mode
and
Michael
already
answered
and
I
think
I
agree
with
him.
I
don't
see
any
need,
it's
probably
going
to
be
Dane
e
or
Dane
ta.
A
J
J
He
asked
whether
we
need
to
define
a
new
Dane
selector
for
seabor
encoded
certificates
and
that
one
I'm
not
sure
I
have
an
opinion
on
but
like
to
see
if
anyone
else
does
so
right
now,
if
I
recall,
the
Dane
spec
has
two
selectors:
one
is
the
full
certificate
in
endure
format,
and
one
is
the
subject
public
key
info
in
their
format
or
or
a
raw
public
key.
There's.
L
There
are
only
two
selectors:
it's
the
public
key
and
the
full
binary
blob.
The
binary
blob
I
guess
is
defined
to
be
der,
but
really
I.
Don't
think
it
was
necessarily
the
case
that
it
must
be
there.
It's
just
the
full
certificate
in
whatever
form
it
appears
in.
So
we
could
make
that
clearer
or
Define.
A
new
selector
is
seabor
supported
in
TLS.
You
see,
the
tlsa
record
is
TLS
specific.
L
If
seabor
is
outside
TLS,
then
the
whole
question
is
kind
of
moot
right,
because
it's
no
longer
tlsa,
so
I've
never
seen
TLS
use,
Seaboard
coated,
certs,
so
I,
don't
know
what
we're
talking
about
exactly.
A
E
Fluorine
I'm
so
eager
about
client
certificate
recognition,
I
already
have
to
implemented
in
a
TLS
demon
where
I
go
all
the
way,
look
up,
sap
record
and
showing
dnsack
looking
up
an
ldap
server,
parsing,
what's
in
there
and
so
on,
and
so
on.
I'm
really
eager
to
rip
that
out,
because
nobody's
using
it
and
I
would
very
much
like
to
have
something
as
simple
and
elegant
as
this
excellent.
A
Okay,
any
other
comments
on
that
I
think
we
probably
have
time
for
one
more
question
then
so
my
next
question
is
going
to
be.
I
am
planning
on
deploying
dance,
so
we
need
operators
right.
We
need
people
that
actually
you
own
a
dnsl
and
you
own
something
rather
where
you
can
actually
make
use
of
dance
technology,
I,
don't
care
if
it's
a
gigantic
infrastructure.
You
know
a
company,
that's
going
to
deploy
millions
of
iot
devices
or,
if
you're,
just
going
to
use
it.
You
know
in
your
small
operational
Network.
A
F
A
A
Okay,
I
think
that
looks
pretty
good.
As
I
said
in
the
last
buff
I
just
drilled,
we
don't
actually
attract
operators
here
much.
You
know
the
ITF
is
not
an
operator
convention
so
having
having
any
is
actually
somewhat
of
a
good
sign.
A
If
anybody
wants
to
stand
or
raise
hands
to
speak
to
how
they
are
planning
on
using
it.
Aside
from
we've
seen
some
you
know,
presentations
in
the
past,
anybody
that
hasn't
spoken.
Yet
that
wants
to
give
a
quick
description,
we'd
love
to
hear
it.
B
Well,
I
guess
we
can
just
close
for
now
with
yet
another
reminder
to
try
and
keep
the
oh.
We
have
somebody
here
all
right,
good.
B
Well,
what
topics
do
you
think
should
we
should
be
discussing
at
the
interim
and
are
there
other
people
that
feel
the
same
way.
A
K
K
So
what
are
the
topics
pretty
much
everything
we
talked
about,
I
think
that
the
architecture
document
and
the
other
use
cases
we're
not
in
we
are
in
working
group
last
call
for
some
of
them,
so
that
may
be
appropriate
after
that
point
to
deal
with
whatever
issues
that
we
can't
res
authors
can't
resolve,
so
I
wouldn't
mind
seeing
two
virtual
interims
before
the
next
ietf.
That
would
be
my
goal.
I
think
we
would
make
much
better
progress
that
way.
A
Okay,
that's
good
I
mean
so
we
are
your
chairs
and
we
will
do
whatever
the
group
wants
in
at
your
behest.
So
it
sounds
like
probably
January
for
an
interim,
and
what
we
will
do
is
propose
that
people
pitch
topics
for
they
actually
want
to
discuss
right.
So
we
actually
drug
you
guys
drug
agenda
items
out
for
this
one
in
probably
even
the
last
hour,
so
we
need
we
need
stuff
more
in
advance,
it's
very
hard
to
put
together
an
agenda
at
the
last
second,
so.
B
Yeah
I
guess
the
very
least
it
could
be
a
follow-up
on
the
topic.
Streamon
was
telling
us
about,
but
yeah
just
like
we
said
it
will
definitely
be
mostly
up
to
you
guys
all
right.
So
then
that
seems
to
be
it
for
today.
Thank
you,
everybody
and
see
you
next
time.