►
From YouTube: IETF105-DPRIVE-20190725-1550
Description
DPRIVE meeting session at IETF105
2019/07/25 1550
https://datatracker.ietf.org/meeting/105/proceedings/
A
B
D
B
Everybody
should
be
familiar
this
with
this
by
the
time
you've
gotten
to
Thursday.
This
is
a
note.
Well,
here
are
all
the
documents
that
you
should
have
read
at
some
point
in
time.
There
is
no
quiz,
so
you're
on
your
own.
If
I
get
any
closer,
I
think
I'm
going
to
eat
it,
so
I
wa
III
will
talk
louder.
So
is
that
Shawn?
It
is.
Are
you
sure?
B
B
B
Awesome
so
a
couple
of
quick
things
before
we
move
along
over
in
the
DNS
SD
working
group.
There
are
two
documents
that
are
looking
at
privacy
implications
of
this,
of
the
their
discovery.
Mechanisms
and
they've
been
looking
for
people
willing
and
able
to
review
them
and
provide
feedback.
So
part
of
this
is
due
to
the
fact
that
DNS
SD
is
potentially
winding
down.
B
So
there
may
be
a
pole
at
some
point
as
to
whether
or
not
we
might
want
to
adopt
these
documents,
but
in
the
meantime,
anybody
with
an
interest
in
in
DNS
service,
discovery
and
privacy
implications.
Please
go
take
a
look.
These
drafts
then
provide
some
comments
to
either
the
authors
or
the
that
mailing
list.
B
If
you
recall
coming
out
of
Prague's,
we
did
an
adoption
call
for
the
76
26
business
document.
We
have
adopted
that
that
first,
that
document
is
now
available.
The
authors
would
really
really
really
like
to
see
some
reviews
and
comments.
The
big
thing
here
is
that
this
is
a
normative
reference
for
the
BCP
document,
so
we
want
to
make
sure
this
moves
along
as
quickly
as
possible.
So
we
can
finish
up
the
BCP
any
comments,
questions
going
once
going
twice
all
right.
So
let's
do
the
DNS
over
TLS
and
early
data
Alessandra.
E
Hello,
so
for
those
not
aware,
TLS
120
introduced
a
feature
called
zero
et
essential
session
presumption,
which
allows
clients
to
send
application
data
before
the
TLS
and
check
has
completed
in
order
to
reduce
latency
or
whatever.
This
can
be
useful
for
DNS
over
TLS
in
cases
where
keeping
long-lived
TLS
connections,
the
connection
might
not
be
feasible.
For
example,
all
mobile
clients,
where
the
network
might
be
shaky
or
on
resolvers,
were
maintaining
a
large
number
of
connections
to
authoritative
servers
might
not
be
useful,
a
weber.
E
This
comes
with
with
caveats,
notably
the
early
data
can
be
intercepted
by
own
path,
attackers
and
replayed
to
the
server.
The
attacker
cannot
directly
decrypt
the
data,
but
the
replay
might
have
unexpected
consequences
or
bad
consequences.
So
so
the
TLS
1.3
RFC
defines
some
mechanisms
to
mitigate
mitigate
this
replay
potential
and
also
says
that
application
protocols
have
to
define
a
profile
so
that
that
defines
like
safe
ways
to
use
early
data
for
the
specific
application
protocols
in
order
to
actually
use
a
real
data.
So
this
is
what
the
drug
does.
E
It's
mostly
based
on
RFC
8470,
which
is
the
using
early
data
with
HTTP
HTTP,
because
most
of
the
the
mechanisms
are
common.
There
are
some
Vienna
specific
bits,
for
example,
defining
which
DNS
messages
are
safe
to
or
unsafe,
to
send
over
early
data,
as
well
as
on
the
some
of
the
security
considerations.
So
the
was
a
there
was
a
discussion
on
the
mailing
list.
There
was
some
interest
in
the
draft
arm
and
some
suggestion
were
proposed.
E
So,
for
example,
currently
the
draft
defines
a
blacklist
of
DNS
messages
that
should
not
be
sent
over
early
data
because
of
the
replay
problems
or
like
Denis,
updates
or
zone
transfers.
It
was
suggested
that
it
might
be
better
to
define
a
whitelist
of
messages
that
are
safe
to
send,
for
example,
using
a
NR
registry
and
then
the
privacy
considerations
sections
need
some
work.
E
F
E
E
B
H
H
Brief
introduction
are
the
end
goal
of
today
is
that
we
want
to
ask
whether
the
working
group
thinks
that
this
can
go
to
working
group
masks
or
not
the
just.
To
recap,
all
the
document
goals
the
goal
is
document
is
to
set
operational
policy
and
security
considerations
for
DNS
operators
that
operate
DNS
privacy
service,
and
it
also
includes
the
DNS
privacy
policy
practices
statement,
which
is
a
framework
that
operators
can
use
to
sort
of
describe
how
they
run
their
service,
and
we
combine
these
two
in
a
document
I'll
get
back
to
that
too.
H
H
If
you
run
a
DNS
privacy
surface,
because
we
specifically
consider
the
potential
for
misdirection
through
poisoning
attacks
a
privacy
problem,
because
you
could
be
redirected
and
sort
of
tricked
into
entering
sensitive
data
into
websites
that
you
don't
trust,
we
added
a
reference
to
our
c7
766
for
mitigations
of
available
availability
threats,
as
we
consider
bad
availability
of
a
service,
also
a
privacy
risk,
because
people
might
switch
to
different
services.
If
it's
not
is
unavailable,
we
looked
at
TLS
version
and
cipher
suite
combinations
as
to
mitigate
tracking
risks.
H
So
we
think
that
we've
addressed
all
the
suggestions
that
were
raised
in
a
meanness
and
in
other
discussions
we
think
that
we
were
sort
of
ready
for
for
working
with
Glasgow
and
we
want
this
to
remain
a
living
document
right.
So
this
is
not
the
the
be-all
and
end-all
of
the
document.
What
we
would
like
to
do
is
say
do
a
base
in
say
two
years
time,
because,
especially
if,
though
uptake
happens,
it's
going
to
happen,
then
we
believe
that
changes
will
be
required
to
this
document
and
that
needs
to
be
reflected
in
the
future.
H
We
are
open
for
it
as
to
your
opinions
on
this.
Where
do
you
believe
this?
This
is
ready
to
go
to
last
call
or
not.
We
decided
not
to
separate
the
policy
framework
from
the
operator
guidance.
That
was
something
that
was
raised
on
the
listening
discussions
previously
and
there
was
not
a
real
consensus
on
whether
to
do
one
or
the
other.
H
So
we
debated
this
between
the
authors
and
we
decided
that
we
would
rather
keep
it
in
the
same
document,
because
we
believe
that,
as
the
document
sort
of
gets
updated
over
time,
that
the
operator
guidance
and
the
DPP
DPP
PS
sorry
need
to
be
sort
of
updated
in
parallel.
So
separating
them
into
two
documents
is
just
going
to
be
sort
of
an
epitaph
nightmare,
and
that's
it
any
other
things
that
you'd
like
to
discuss.
Please
come
to
the
mic,
Oh.
I
Paul
Hoffman
very
briefly,
so
we
heard
yesterday
from
somebody
the
chrome
team
that
they're
also
thinking
of
doing
a
TR
R
and
such
like
that.
Maybe
we
wait
for
last
call
until
we
get
some
more
clarity
on
that,
it
would
seem
funny
to
have
the
Firefox
one
and
not
Chrome
one
I
don't
know,
and
we
could
be
waiting
forever
because
Firefox
one
is
also
still
a
proposed
skiing,
yeah,
necessarily
the
one
they're
using
so
I.
I
H
So
it
yeah
I
kind
of
agree
with
that
that
including
one
and
not
the
other
would
be
weird
but
I.
Given
on
what
on
the
comments
that
the
chrome
people
made
in
in
a
discussion,
I,
don't
think
that
they're
actually
going
to
publish
something
that
is
sort
of
a
policy
on
what
they
want
to
do.
They
they
basically
sketched
what
they
what
they
plan
to
do.
B
J
K
J
Please,
and
here
the
time
line
for
South
craft.
It's
only
this
year
in
March,
we
have
introduced
the
first
version
of
thought
in
ITF
below
four
and
I
kept
the
same
hacksaw
a
secretary
side,
ax
ax,
are
over,
TLS
was
implemented,
I
am
bound
by
billion.
After
that
we
updated
this
dropped
a
lot.
We
included
them.
Many
details,
including
the
detailed
mechanisms
for
axfr
XFR,
based
on
thought
and
some
authentications
discussions
of
policy
and
configurations,
and
some
of
them
will
be
discussed
in
later
slides
like
slide.
Please,
and
there
are
three
use
cases
for
facade.
J
The
first
one
is
confidentiality,
which
means
the
salt
billion
create
the
zone
transfers,
and
in
this
case
the
attackers
cannot
collect
the
zone
data
by
just
passively
monitoring
the
network.
The
second
one
is
authentication,
currently
the
existing
tip
some
transfers
authorized
by
using
TC
and
the
in
this
drop.
We
discussed
the
possibilities
of
using
different
other
options,
for
example
single
to
your
eyes,
due
to
TOS
this
combination
of
ACLs
for
authentication,
and
this
one
will
be
discussed
in
a
later
slide.
The
third
way
is
performance,
so
the
existing
are,
except
for
the
exact
ours.
J
J
In
contrast,
the
solvent
implementations
will
be
required
to
implement
the
optimized
transfers,
which
means
multiple
zone
transfers
can
be
done
in
single
connection.
Similarly,
current
usage
of
the
TCP
for
XFR
is
suboptimal.
For
example,
the
TCP
connections
are
closed
after
a
single
XFR,
but
this
is
odd.
Multiple,
except
for
our
can
be
done
in
single
persistent
connection
next
slide,
please,
and
now,
let's
look
at
the
comparison
between
the
existing
axfr
mechanism
and
self-paced
axfr.
So,
as
you
can
see
in
this
slide,
maybe
next
slide.
Please
we
have
an
animation
here.
Yes,
please
thank
you.
J
So
after
the
notify
on
the
solar
request,
all
the
song
transfer
will
be
done
in
the
TLS
session
and
that
the
song
transfer
will
be
encrypted
and
that
the
TLS
session
will
be
using
the
path
853
or
some
other
part
that
is
mutually
agreed
by
both
the
server
and
the
client.
So
now
I'm
going
to
hand
over
this
to
blobby.
Thank
you.
K
Thanks
so
now,
I'm
going
to
do
a
comparison
between
ike
so
far,
the
existing
mechanism
of
iuck
so
far
and
the
way
XFR
iook
so
far
would
be
done
using
zort,
so
I
thought
so
in
the
existing.
So
the
with
notifies.
There
is
not
much
difference
between
the
existing
mechanism
and
I
thought.
The
notifies
from
primary
to
secondary
still
go
over
UDP
and
it's
kind
of
the
same
for
the
so
request
and
response.
K
If,
like
you
know,
the
zone
size
is
big,
there
is
GN
SX
signs
owns
with
multiple
dynamic
updates
type
of
thing,
so
the
what
we
have
seen
is
some
of
the
latest
versions
of
bind
and
NS
t
do
TCP
by
default,
but
even
when
they
do
TCP
by
default.
For
every
single
zone,
except
for
transfer,
request
and
response,
a
new
TCP
connection
is
opened
and
closed
for
like
every
time
it,
despite
the
fact
that
if
the
zone
is
dynamic,
the
zone
is
tired,
nsx
sign
and
is
doing
a
lot
of
iock.
So
far.
K
K
The
second
thing
that
would
like
to
talk
about
is,
and
that
we
have
brought
out
in
the
latest
version
of
the
draft,
is
authentication
mechanisms
for
Zod.
We
evaluate
the
authenticate.
The
three
existing
authentication
mechanism
like
PC,
TLS,
opportunistic,
strict,
mutual
and
ACL
on
master
and
the
criteria
that
we
are
used
for
evaluation
is
data,
authentication,
channel,
confident
confidentiality
and
channel
auth,
and
we
are
doing
this
comparison
for
primary
and
secondary.
So
because
TC
is
entity
to
entity
of
gives
us
data
protection.
K
It
works
perfectly
for
data
auth,
so
TC
is
very
good
candidate
for
data
or
before
secondary
and
primary.
Then,
of
course,
TLS
provides
channel
confidentiality
to
the
data
that
is
on
wire
during
the
transport.
So
all
the
three
modes
of
TLS,
opportunistic,
strict
mutual,
give
you
channel
confidentiality,
but,
as
you
can
see,
when
you
look
at
channel
or
strict
TLS
provides
channel
or
to
the
secondary,
because
of
course
the
secondary
will
do
either
the
domain
name
or
key
pinning
to
figure
out
which
is
the
primary.
K
So
it
provides
good
protection
channel
or
to
the
secondary,
but
it
doesn't
provide
the
same
protection
to
the
primary
because
primary
doesn't
know
which
client
it's
talking
to.
So
in
that
case,
mutual
TLS
offers
the
channel
or
type
of
protection
to
both
primary
and
secondary.
So
that
is
one
option
for
channel
auth,
but
another
option
that
we
are
considering
is
ACL
on
master,
which
provides
good,
which
is
one
of
the
existing
mechanism,
and
it
also
provides
good
channel
authentication
to
the
primary,
because
now
it
knows
the
second
rate
wants
to
talk
to.
K
So
the
conclusion
of
this
analysis
is
that
a
combination
of
t6,
strict
TLS
and
ACL
on
the
masters
kind
of
fulfills,
all
the
three
criterias
that
we
have
set
for
the
authentication
and
if
we
can
get
that
with
like
reasonable
overhead,
so
policy
management
for
Zod.
In
this
draft
we
have
defined
sort
of
a
term
called
transfer
group.
Now,
in
this
case,
transfer
group
is
kind
of
captures.
K
All
of
the
servers
that
are
involved
in
zone
transfer
of
a
zone
for
a
particular
zone
like
all
primaries
all
secondaries,
and
we,
the
tired
the
entire
transfer
group,
should
have
the
same
policy
in
terms
of
teasing
TLS
of
whether
it
uses
opportunistic
strict
of
mutual
TLS
and
ACL
for
primary.
Because
even
if
one
of
the
server
doesn't
follow
the
same
policy,
it
can
be
the
weak
point
for
any
kind
of
attack.
K
But
the
challenge
that
we
want
to
flush
out
in
the
draft
is:
how
do
we
configure
tests
and
also
a
lot
of
enforce
and
test
policy
implementation,
because
sometimes
the
secondaries,
the
primaries
could
be
across
operators
could
be
across
different
type
of
implementation.
So
that
is
one
of
the
challenges
that
we
have
and
we
would
love
to
get
some
feedback
from
the
working
group
related
to
this
challenge,
and
the
last
slide
for
our
presentation
is
just
to
talk
about
the
current
and
future
work
related
to
short
unbound.
He
has
released
version
9.
K
One
point
nine
point:
two
with
secondary
side
is
that
this
was
the
work
done
by
William
during
the
previous
hackathon,
and
now
it's
released,
the
server
side
is
or
can
be
implemented
using
TLS
proxy
ITF
105
hackathon.
We
tried
to
implement
a
support
for
dot
and
zort
for
DN
a
Java
libraries,
but
that
still
work
in
progress.
So
some
of
the
open
questions
that
we
have
asked
in
the
draft
just
for
performance
and
better
security
would
be
sure.
K
Should
we
recommend
a
must
for
so
awkward
to
happen
over
an
existing
TLS
connection,
should
we
say
a
must
for
using
TLS
1.3,
and
the
open
question
is
about
padding
to
prevent,
like
traffic
analysis
type
of
thing.
So
our
next
request
of
the
working
group
is
to
review
this
draft
and
we
are
calling
for
working
group
adoption.
C
What
say,
and
if
I'm
and
I'm
sorry
I
haven't
read
it
in
detail
I've
at
least
given
it
fairly
well
and
I,
like
the
presentation,
I'm
glad
this
is
being
documented,
I
think
it's
really
good.
My
one
question
is
you're
not
adding
anything
new
right,
isn't
it
more
you're
describing
the
best
way
to
use
the
existing
pieces
that
we
have
like
the
protocol
operations,
the
transport
mechanisms
and
things
like
that.
C
L
I'm
also
co-author
on
this
stuff,
so
I
want
to
reply
to
you
to
discussion
too.
So
this
is
also
opportunity
to
improve
on
existing
aches
of
art
and
sorry,
but
we
want
to,
for
example,
by
introducing
pipelining
right
if
some
points
that
out
already
was
currently
if
you
have
a
lot
of
incremental
Tom's.
First,
current
implementations
will
open
for
each
incremental
terms
for
a
new
TCP
session
and
if
it's
all
from
the
same
primarily
to
the
same
secondary,
this
could
be
pipelines
over
the
same
Channel.
L
C
M
Benkei
duck
so
I
think
with
respect
to
the
you.
Should
the
SOA
crave
be
on
the
Telus
connection,
I
think
should
in
general
we
don't
want
people
to
use
some
insecure
data
to
deter
whether
or
not
they
should
do
something
securely.
You
might
notice
that
your
your
credit
card
submission
form.
Your
payment
forms
on
a
website
are
on
websites
that
are
entirely
HTTPS
now
ten
years
ago.
Maybe
it
was
a
HDTV
site
that
would
send
you
to
HTTPS,
but
we
realized
you
should
just
be
using
TLS
the
whole
way.
I,
don't
think.
M
There's
a
particular
compelling
reason
to
say
that
you
must
use
TLS.
Well,
not
3G
lost
103
is
great
I.
Think
people
should
use
it,
but
we
don't
need
to
use
this
as
a
forcing
function.
There
are
other
versions
to
tell
us
they're,
just
fine,
they
provide
adequate
security.
Padding
is
good,
but
you
should
have
dkg.
Tell
you
how
to
do
that.
H
Rosa
can
download
apps.
Can
you
go
back
to
slide
9?
They
give
us
like
nine
yeah.
So
one
thing
I
was
wondering,
and
maybe
this
is
a
minor
consideration.
If
you
keep
the
session
open
for
a
multiple
xfr-s,
then
to
an
observer,
they
suddenly
see
that
there
is
a
relationship
between
the
primary
and
the
secondary,
because
you
keep
that
open.
H
It's
gonna
send
through
keepalive
message,
so
there
be
a
persistent
sort
of
stream
of
messages
going
on
that
channel
and
maybe
that
it
is
a
consideration
as
well,
because
if
this
is
ephemeral
and
you
have
a
connection
that
sort
of
happens
once
in
a
while,
then
the
observer
needs
to
sort
of
constantly
observe
that
and
otherwise,
by
looking
for
a
short
time,
they
can
see
that
there
is
this
traffic
going
on
that
they
will.
They
can
always
observe,
and
that
might
be
something
worth
considering.
K
K
N
O
O
This
is
actually
related
to
the
Alessandro's
presentation,
because
if
you,
whether
you
need
to
keep
the
session
open
or
not,
depends
on
whether
or
not
you're
capable
of
going
ahead
and
spinning
up
another
one
rapidly,
which
the
zero
RTT
would
be
useful
for.
So
particularly,
if
you
say
do
this
with
TLS
1.3,
then
you
can
do
your
Iook
so
far
and
when,
as
you
do
it,
you
get
the
PS
k
that
you
would
use
to
do
the
0r
TT
and
then,
when
you're
ready
to
send
the
next
one.
You
just
do
the
next
one.
O
O
If
you
just
write
a
blob
into
T
into
a
TLS
stack
and
you
have
corked
it,
then
it's
likely
to
send
that
out
as
its
TLS
record
on
its
own.
So
even
if
you're
doing
it
as
fast
as
you
can,
if
each
record
comes
out
as
its
own
TLS
record,
then
it's
visible
on
the
outside
on
the
wire.
So
you
want
to
think
I
would
recommend
that
you
that
you
do
include
guidance
and
I
do
think.
O
K
C
Yesterday,
I
again,
yeah
plus
wonder
that
that
was
excellently.
First,
with
respect
to
the
the
should
must
SOA
query.
I
would
say
it
must
be
a
teasing
protected
right,
that's
critical,
but
whether
or
not
it
should
be
over
an
encrypted
TLS
connection.
Very
much
depends
on
whether
the
the
sender
and
receiver
care
that
the
name
of
the
zone
is
being
transferred,
so
like
coda,
UK,
probably
doesn't
care
because
the
authoritative
servers
are
known.
You
know
if
they're
transferring
between
each
other,
but
they
don't
want
the
contents
of
the
zone
itself
disclosed.
K
So
about
the
solar
that
must
is
what
we
are
recommending
in
terms
of
performance,
like
you
know,
using
an
existing
connection
open
between
the
secondary
to
primary.
So
that's
where
our
idea
was
about
the
must
not
in
terms
of
security,
what
you
mentioned.
So
it
was
just
kind
of
performance,
enhancement,
type
of
thing,
but
yeah.
P
Hi
Sean
Turner
I'm
not
implementing
this,
but
I'm
thinking.
This
is
a
new
protocol.
Why
don't
you
just
must
tell
us
1.3
I,
understand
that,
then
you
can't
do
it
with
1.2,
but
just
it's
not
like
it's
not
available
right.
It's
already.
Some
appreciable
percentage
of
the
internet
just
go
1.3,
and
then
you
can
just
it's
an
easier
way
to
write
it.
You
have
to
write
if
you
do
1.3
you
do
this.
P
L
Sorts
of
many
major
problems
for
privacy
of
some
transfers,
but
it
still
depends
on
bi-directional
exchange
for
notified
records.
Incremental
sensors
assault
is
still
there
for
a
pulling
mechanism
for
incremental
transfers,
but
there's
potential
to
use
in
this
mechanism
a
subscribe
and
publish
for
zone
updates.
L
Dina
stateful
operations
are
a
protocol
in
which
built
upon
state
Hall
connections
that
are
kept
open,
there's
where,
for
first
assistant
stage
for
session
satisfy
and
desire,
uses
a
new
opcode
to
convey
new
type
of
messages.
Besides
the
ordinary
DNS
queries
and,
in
essence,
s1
/
add-ins
stateful
sessions,
the
three
types
of
Oh
Sarah's,
already
there,
okay
Sarah.
L
Q
Q
I
think
we're
trying
to
explain
the
basics
behind
how
the
stateful
operations
actually
work.
So,
first
of
all,
a
session
needs
to
be
initiated
by
the
exchange
of
a
keepalive
message
between
the
client
and
the
server.
After
that,
the
normal
session
rules
apply
and
normal
dinners
message.
Exchange
could
take
place
within
the
session,
though
you
get
exchange
of
DSA
messages
and
there's
two
key
things
to
point
out
about
them
in
how
they're
different
to
normal
DMS
messages.
One
is
that
there's
two
types:
there
are
DSA
messages
which
require
a
response,
and
there
are
also
DSO.
Q
You
need
directional
messages
that
do
not
require
a
response,
and
that's
okay,
because
we're
using
a
reliable
transport.
Secondly,
a
key
difference
with
DSO
is
that
either
the
client
or
the
server
can
initiate
one
of
these
messages.
So
that
means
you
have
bi-directional
data
exchange
within
the
session.
A
last
thing
to
mention
is
that
a
DSA
message
can
contain
more
than
one
TLV.
The
first
TLV
found
is
called
the
primary
T
of
V,
and
that
dictates
the
operation
that's
actually
occurring,
but
there
can
be
additional
two
of
these
that
supplement
that
operation.
Q
So
what
you
can
see
from
this
is
that
the
tlvs
and
DSO
messages
can
be
used
in
several
different
contexts.
Next
slide,
please.
So
the
key
thing
is
that
when
you
specify
deal
TLV,
you
have
to
say
precisely
which
context
it
can
be
used
in
next
slide,
please.
So
the
easiest
way
to
do
this
is
to
develop
a
matrix
like
this.
So
we
have
messages
which
are
initiated
on
client
side
which
are
shown
in
the
left
panel
here
and
messages
that
are
initiated
from
the
server
side
in
the
right
panel.
Q
Here
next
slide,
please,
and
in
each
of
those
context,
you
separate
the
two
plate,
two
ways
a
TLB
can
be
used.
So
in
the
left
box
there
we're
saying
which
contexts
a
TLV
can
be
used
in
when
a
client
initiates
a
message:
can
it
be
a
primary
TLV?
Can
it
be
used
in
a
unidirectional
message,
or
can
it
be
an
additional
TLV
and
in
the
Box
on
the
right,
you
specify
in
the
response
to
that
message
whether
the
tlb
can
be
a
primary
or
an
additional
next
slide
please.
Q
So
what
you
can
see
here
is
that
the
keepalive
TLB,
for
example,
can
be
used
in
a
message
response
para,
where
the
client
initiates
a
DSO
message
with
that
as
the
primary
TLV
and
the
server
responds
with
that
as
a
primary
TLV.
However,
it
can
also
be
used
in
a
different
context
where
a
server
sends
a
unidirectional
message
just
to
the
client,
so
there's
a
lot
of
flexibility
and
how
the
tlbs
can
be
used
and
as
I
mentioned
earlier,
you
can
see
here
that
padding,
for
example,
is
always
an
additional
TLV.
Q
There
is
no
sense
in
using
it
as
a
primary
TLV.
Next
slide,
please
so
the
major
place
today
that
has
used
DSO
beyond
the
base
specification.
Our
drafts
that
have
come
out
of
the
service
discovery
working
group
and
the
one
to
draw
your
attention
to
is
called
DNS
push.
Notifications
and
the
motivation
for
that
draft
is
that
clients
can
be
asynchronously
notified
of
changes
to
specific
DNS
records.
So
this
is
effectively
a
publish/subscribe
model
for
specific
our
assets.
Q
It's
also
used
in
a
couple
of
other
places
proxy
and
the
relay,
but
the
push
is
the
one
relevant
to
this
work
next
slide,
please.
So
we
actually.
Oh
the
push
notifications
draft
a
huge
debt,
because
we've
built
directly
on
top
of
all
the
concepts
there,
we've
simply
extended
them
so
that
they
can
work
for
publish/subscribe
different
are
zones.
The
reason
we
wanted
to
do
this
is
because
we
thought
this
fulfilled
a
number
of
use
cases
that
went
beyond
what
normal
zot
can
do.
Q
So
obviously
it
takes
a
box
of
constant
confidentiality
because
DSO
can
use
TLS
do
so
itself
doesn't
require
TLS,
but
anything
building
on
it
could,
in
theory,
Makua
TLS.
We
think
there's
additional
confidentiality
gains,
because
the
mechanism
could
eliminate
the
notify,
SOA
queries
or
do
equivalents
of
them,
always
within
the
DSO
session.
Q
Q
If
you
have
an
untrusted
Network
around
your
secondary,
we
think
we
could
potentially
improve
the
performance,
because
we
can
reduce
the
total
number
of
messages
we
can
do
better
error
handling,
because
we
can
define
new,
specific
error
codes
as
to
why
things
fail,
and
a
more
general
thought
about
this
in
the
future
is
that
it
has
the
potential
to
be
a
command
channel
where
servers
could
initiate
commands
towards
clients
so
primary
to
secondary
and
I'll
touch
on
this
slightly
again
later.
Next
slide,
please.
Q
Q
The
first
exchange
is
then
the
client
sending
a
subscribe,
xfr
DSA
message
and
the
content
of
the
TLV
in
that
message
is
the
zone
name
and
the
current
SOA
that
the
client
holds
and
if
all
is
well,
the
server
can
reply
back
in
affirmative,
acknowledging
that
the
subscription
is
now
active
next
slide,
please.
So
what
happens
after?
Q
What
you
can
see
from
that
flow
is
that
it's
possible
for
a
server
to
refuse
it's
a
subscription
and
in
the
draft
we
specify
a
number
of
error
codes
that
could
be
used
to
convey
meaningful
information
to
the
secondary.
In
that
case,
clients
can
obviously
subscribe
to
multiple
zones
on
the
same
connection
and
do
the
transfers.
In
parallel,
we
have
proposed
that
clients
can
request
a
full
zone
transfer
in
the
rich
subscription
by
omitting
the
SOA
and
anytime.
Q
Q
To
my
knowledge,
no
major,
open
source,
authoritative
implementations
currently
support
DSO,
because
it's
so
new.
So
clearly
that
would
also
have
to
be
implemented
before
you
can
move
forward
with
this.
But
I
hope
you
can
appreciate
that
if
you
did
implement
this,
you
can
see
that
the
actual
data
flow
is
much
cleaner
and
the
whole
mechanism
is
much
more
naturally
extensible
and
flexible
and
would
certainly
be
very
suitable
for
zones
where
you
have
a
very,
very
high
rate
of
art
so
far,
something
on
the
order
of
seconds,
for
example.
Q
Q
However,
I
have
had
a
number
of
use.
Cases
proposed
where
TCP
would
be
sufficient,
so,
for
example,
if
the
zone
file
is
already
public,
it
might
be
seen
as
an
unnecessary
overhead.
So
there's
a
question
there
about.
Should
we
allow
TCP?
My
inclination
is
to
say
that
if
we
do,
we
should
still
have
a
must.
The
implementations
support
TLS.
We
don't
split
that
capability
and
if
we
allow
TCP,
there
is
somewhat
of
a
question
as
to
whether
this
work
should
stay
here
or
go
to
dearness
op.
Q
Q
We
clearly
need
to
think
about
more
signaling.
While
subscriptions
are
active,
for
example,
their
clients
may
want
to
restart
the
transfers
at
a
different
SOA
or
request
and
xfr.
We
need
to
think
about
things
like
what
happens
if
the
SOA
refresh
time
expires.
While
a
subscription
is
active
in
the
current
spec,
we
haven't
specifically
specified
an
equivalent
axfr
message
for
do
so,
but
maybe
there's
a
use
case
for
that.
I
can
certainly
imagine
some
use.
Q
If
primaries
could
send
instructions
secondary's
to
do
things
like
stop
serving
a
zone
or
delete
a
zone
and
I
will
also
say
the
c-word
here
covert,
because
obviously
that's
been
talked
about
this
week,
and
what
you
can
see
is
that
this
mechanism
could
quite
naturally
lend
itself
to
sending
other
data
within
an
established
DSO
session.
So
the
feedback
we're
looking
for
today
is
really
do
people
think
this
is
working
on
and
where
do
they
think
that
work
should
happen.
R
R
To
answer
a
couple
of
sarah's
questions,
I
think,
while
it
would
be
fine
to
require
implementers
to
support
TLS,
I
don't
think
it
should
be
required
in
in
the
operations
of
it.
I
can
think
of
a
few
cases
where
I'd
like
to
use
something
like
this
purely
as
a
performance
optimization
where
the
the
data
is
already
going
over
either
private
networks
or
there's
encryption
at
a
lower
lip
layer
on
the
network
already
and
and
the
tcp
or
TLS
would
just
be
an
unnecessary
overhead.
S
Hello,
dice
I,
see
also
going
into
the
questions.
Should
we
support
multiple
zones?
I
think
the
answer
should
be.
Yes,
almost
thinking
about
cases
where
people
are
at
hundreds
of
souls,
there
are
thousands
of
Sun
sizzles
they
host
like
the
hosting,
and
that
would
be
a
lot
of
subscriptions
to
maintain
if
you
have
to
have
separate
subscription
for
his
own
about
the
order
types
I
think
there's
need
for
order.
S
Messages,
like
you
mentioned
to
refresh
time
or
I,
could
see
that
being
a
different
diesel
message
and
then
there
are
additional
features
like
command
channels
and
coverts.
But
you
should
really
think
about
the
scope
of
the
document
and
probably
those
will
be
separate,
separate
drafts.
In
my
opinion
and
finally
I
would
say
obviously
I'm
supporting
supportive
of
this
work,
so
I
think
it
should
be
adopted.
Q
T
That's
signaled
to
an
observer.
So
I
I
encourage
you
to
continue
with
the
requires
TLS
in
operation,
as
the
draft
currently
has.
Rather
than
relaxing
it,
and
while
I
realize
that
there
are
cases
which
people
have
enumerated
or
there
might
be
closed
networks
or
for
other
situations
where
TLS
is
simply
a
small
amount
of
additional
overhead
I.
Believe
in
modern
implementations
that
it
over
that
is
sufficiently
small
and
the
advantage
of
keeping
to
this
always
doing
it
the
same
way
sufficiently
large
that
I
encourage
you
to
keep
it
as
it
is.
Thank
you.
U
Ritesh
patrick
sees
ethnic
as
one
of
the
officers
operative
server
software.
I
think
that
we
badly
need
a
new
transfer
protocol.
That's
a
good
idea,
but
I
don't
think
that
it
should
be
this
one,
because
it's
a
lot
of
work
to
implement
and
I
think
it
for
the
transfer
protocol
itself.
It
doesn't
go
far
enough,
so
we
should
do
like
proper
transfer
protocol
analysis
and
not
just
say
well.
L
U
L
O
O
I'm
a
little
puzzled
by
the
use
of
t
SIG's
within
this
when
you
have
as
an
establishing
secure
session
the
we
talked
a
lot
about
this
in
in
the
web
packaging
side
meeting
earlier
this
week,
but
the
relationship
between
the
transport
model
of
authentication
and
the
object
model
of
authentication
which
DNS
is
super
used
to
using,
is
unclear
and-
and
you
here
you've
got
this
weird
mix
of
things
so
I'm
not
sure
we
don't
get
from
the
from
the
pairing,
and
it
just
feels
a
bit
like
a
mismatch
and
I
don't
understand
it.
This.
L
Show
tea,
fake
authentication
is
enter,
enter
authentication
of
the
primary
and
the
finally
receiving
name
server
that
will
serve
the
zone,
so
there
could
be
a
number
of
proxies
between
them
doing
just
such
a
or
talking
of
a
TLS
right,
and
you
have
to
twist
all
these
without
tisha.
You
have
to
trust
other
fractions
that
they
conveyed
data
yeah,
but.
O
So
if
there
are
foxes
involved
in
this
which
it
hadn't
really
talked
about,
then
I
mean
the
thing
with
e-cig
is
that
it's
also
replayable
right?
So
if
I
get
a
copy
of
it,
I
can
now
replay
that
T
cig
and
do
it
in
other
contexts
that
maybe
it
wasn't
appropriate
to
do
and
I.
Don't
understand,
T
cig
well
enough
to
be
able
to
investigate
that,
but
I'm
just
saying
that
to
take
the
TLS
model,
which
says:
here's
a
stream
you've
established
the
stream.
O
O
If
you
were
to
go
to
the
TLS
working
group
and
say
we
need
a
way
that
the
that
we're
trying
to
use
to
do
something
like
this
in
in
DNS
over
TLS
and
the
server
needs
a
way
to
authenticate
something
about
who
the
client
is.
Then
you'll
get
answers
that
are
very
different
from
tea
sake.
There
you'll
get
answers
that
are
bound
specifically
to
the
encryption
channel.
O
V
R
That
there's
a
common
operational
paradigm
for
for
free
zone
transfers
is
I
trust
you
to
execute,
to
transfer
this
zone
and
I
don't
care
where
you
transfer
it
from
so
mutual
TLS
authentication
is
inconvenient
in
that
in.
In
that
case,
all
I
would
care
about?
Is
that
we've
negotiated
TLS
so
that
it's
encrypted
and
I
don't
but
I
don't
care
where
you're
negotiating
it
from
so
I?
K
So,
just
as
we
suck
so,
what
we
mentioned
in
the
data
earth
during
the
presentation
was
what
the
thing
does
and
which
applies
equally
to
the
third
piece.
Also,
is
that
what
TC
would
do
is
whatever
the
primary
is
saying
that
I'm
going
to
send
you
in
terms
of
the
ike
safar
response?
K
It
will
take
that
data
whatever
like
two
hours
or
three
hours,
and
it
will
do
a
hash
on
it,
sign
that
hash
using
this
shared
secret
and
then
send
it
to
the
client
so
that
the
client
knows
that
once
I
verify
that
using
what
shared
secret
I
have
he
didn't
mean
to
send
three
errors
and
I
did
get
three
hours,
so
it's
kind
of
like
you
know.
The
data
itself
also
gets
authenticated
from
both
sides,
not
just
the
TLS,
not
just
protect
encrypting
the
data
but
authenticity
of
the
data
itself.
C
What's
harder
is
I
again
so
correct
me
if
I'm
wrong,
but
there's
two
halves
of
this
essentially
right,
there's
there's
one
half
of
this
is
how
we
want
to
do.
You
know:
secure
push,
notifications
and
stuff
the
secure
and
the
push
are
seemed
to
be
totally
independent.
There
is
nothing
in
the
document
that
requires
TLS
in
terms
of
functionality,
there's
a
requirement
we
want
to
do
it
and
deprive,
and
we
want
to
talk
encrypted
great,
but
the
push
notification
side.
C
This
seems
like
completely
the
wrong
working
group
and
it
should
really
be
India
and
I
saw.
All
you
really
require
is
a
streaming
transport
and
you
know
being
able
to
specify
Indiana
stop.
We
need
a
streaming
transport,
oh
and
it
must
be
TLS.
One
point
three
is
just
fine,
but
I
want
the
experts
in
the
DNS
off
Group
two,
although
I
keep
looking
around
and
they're
all
here,
but
it
still
feels
like
the
wrong
place.
Okay,.
W
Hi,
who
needs
with
no
hats
on
I,
think
I'm,
echoing
better
spastics,
coming
that
the
J
seems
to
be
a
general
to
redesign
zone
transfers
so
I'm,
also
in
favor
of
starting
from
scratch
and
looking
at
the
requirements
for
zone
transfers
and
then
building
on
top
of
that,
rather
than
trying
to
retrofit
and
the
other
observation
on
complexity.
This
assumes
that
DSO
is
also
implemented,
which
is
a
fairly
large
spec.
So
I
think
to
get
to
this
point
would
require
an
implementer
to
do
a
lot
of
work.
Okay,.
B
W
I
C
It
work:
okay,
okay,
not
for
me,
clicker
doesn't
work
for
me
all
right.
It's
a
treacherous
computing
module
hi!
My
name
is
Michael
Richardson
I'm
here
mostly
talking
on
behalf
of
Peru
and
Dan,
who
couldn't
come
to
this
meeting.
I
roped
into
this
because
they
decided
to
incorporate
my
protocol
into
their
stuff.
So
what
this
is
about?
This
is
about
how
your
let's
go
to
the
thing.
What
we're
talking
about
document
has
advanced
a
bunch
okay.
What
are
we
talking
about?
C
We're
basically
talking
about
how
to
bring
on
install
trust
anchors
for
DNS
over
TLS
or
DNS
over
HTTP
things
and
the
scope?
Is
you
show
up
with
a
device
or
an
IOT
device
at
an
enterprise?
And
you
would
like
it
to
use
the
DNS
over
TLS
with
with
the
local
trust
anchors,
because
you
would
like
to
get
local
names
and
not
remote
names,
because
you
would
like
to
have
access
to
whatever
Enterprise
mandated
malware.
C
Defense,
that's
dns-based,
and
we
have
a
new
use
case,
which
is
particularly
care
is
that
we
have
this
manufacturer
usage,
description,
mud
files,
and
this
is
essentially
a
mechanism
by
which
IOT
devices
can
express
here's
a
whitelist
of
traffic
and
communications.
That
you
should
expect
me
to
do.
Do
I.
Do
anything
else,
I'm
compromised
and
please
act
appropriately
problem.
C
Is
that
we'd
like
to
write
those
ackles
in
with
DNS
names
and
not
IP
addresses,
and
you
may
have
noticed
that
firewalls
mostly
don't
speak,
that
in
the
low
level
they
need
IP
addresses
to
do
enforcement
and
the
only
way
that
works
as
if
essentially
the
request
for
the
DNS
name
that
the
firewall
does
and
the
request
of
the
IOT
didn't.
It
does
essentially
resolve
through
the
same
resolver.
C
Otherwise
we
get
into
all
sorts
of
geolocation
and
all
sorts
of
other
DNS
things
that
happens
with
cloudy
things
and
the
result
is
the
firewall
has
a
different
set
of
addresses
than
the
IOT
device
in
terms
of
what
goes
on,
there's
also
some
efficiencies.
If
they
turn
out
to
both
go
to
the
same
resolver,
then
it's
already
cached
and
there's
some
other
things
that
you
can
do
and
it
reduces
some
of
the
stuff.
So
this
is
about
how
do
we
get
this
to
happen?
C
So
there's
a
couple
different
ways
that
describe
in
the
document
document
describes
three
or
four
different
ways
and
there's
another
document
I
believe
it's
almost
Asadi
that
talks
about
doing
this
in
in
DHCP
v4
in
a
slightly
different
way
than
we've
described
and
I'm
actually
not
qualified.
To
tell
you
the
differences
at
this
point.
But
if
you
do
this
with
an
IOT
device
or
an
enterprise
router
of
some
kind,
that's
that's
running
the
anima
brewski
docx
process.
C
Then,
essentially,
what
happens
is
that
in
that
process
you
enroll
their
device
enrolls
into
a
enterprise
PKI
and
when
that
device
does
that?
Well,
you
get
the
trust
anchors.
That's
the
whole
point
is
you
are
now
at
rate
device
on
the
network
and
you
get
to
trust
other
devices,
and
so
now
the
only
real
question
is:
what's
the
name
of
the
the
dot
or
doe
server.
And
how
do
you?
How
do
you
look
it
up
in
a
certificate?
So
it's
actually
really
easy
in
that
case
is
almost
no
removing
parts
to
add.
C
If
you
are
bootstrapping
a
desktop,
this
kind
of
machine
into
a
this
PKI,
then
you're,
probably
going
to
have
some
kind
of.
If
you
use
est,
which
was
RFC
70:30
to
do
certificate
enrollment
for
that
device,
then
it
you
may
have
a
password
of
some
kind
and
you
need
to
authenticate
over
that
thing
and
you
can
use
Paik
or
something
else
like
this
to
authenticate,
in
which
case
again
you
get
back
trust
anchors
and
you
an
end
certificate.
You
can
validate
the
DNS.
C
This
kind
of
thing
happens:
I'm
told
regularly
right
now,
actually
using
CMP
with
I
think
it's
Apple
devices
which
are
in
a
in
enterprises
I'd
have
no
first-hand
knowledge
of
that.
There's
a
discovery
phase.
This
is
the
part
that
I'm
going
to
say
I'm
least
qualified
to
understand.
So
if
you'd
like
to
ask
me
questions
that
would
be
funny,
but
essentially
you
you
look
up
this
DN
net
domain
dash
S
and
you
do
a
service
just
go
on
it
and
it
tells
you
where
the
the
NS
server
is
and
you
go
and
find
it.
C
And
then
you
find
it
has
a
certificate
which
is
signed
with
the
appropriate
mean
in
the
the
thing,
and
you
had
a
trust
anchor
from
before,
and
everything
is
good
and
there's
a
other
document
that
tells
you
how
to
how
to
do
that
part
how
to
how
to
get
the
right
URLs
out.
So,
if
you're
doing
dough,
you
need
a
URL
that
you're
gonna
add
to
it
and
there's
another
documents,
not
a
doctrine
that
says
how
that's
happening
and
I
mentioned.
C
You
have
to
do
the
connection
and
you
have
to
match
all
the
things
so
I
jumped
ahead
of
my
slides
there
we
go
one
of
the
things
we
would
like
to
have
is.
We
would
like
to
have
some
way
of
asserting
what
the
privacy
considerations
of
the
server
that
you're
talking
to
is
I
recently
learned,
I
think
that
that
Mozilla
has
a
statement
that,
for
instance,
relates
to
CloudFlare
and
how
that
happens,
and
one
of
the
interesting
questions
is
well.
C
How
can
others
play
and
get
an
attestation
from
some
third
party
that
says
that
the
DNS
server
running
your
enterprise
is
not
scribbling,
DNS
requests,
you
know
out
the
unencrypted
channel
somewhere
to
somebody
right
and
or
writing
them
or
logging
down
or
whatever
whatever
it
is
your
policy
we
would
like
to
be
able
to
write
it
down
somehow
and
attest
it
to
the
end-user
so
that
their
device
can
say.
Oh
okay,
this
actually
is
a
religion
thing
or
Wow,
while
I'm
at
this
particular
location,
my
Tuesday
job,
maybe
I,
won't
be.
C
C
They
should
be
able
to
enable
this
discovery
and
if
they
don't
want
to
enable
it-
and
they
don't
want
to
discover
the
local
thing-
they're
not
gonna,
get
local
names
and
this
kind
of
stuff
and
that's
really
applicable
to
devices
that
you
would
bring
with
you
for
an
enterprise
with
IOT
devices
that
they
want
to
unboard
then
well.
They
want
to
enable
it
and-
and
they
particularly
want
to
enable-
because
otherwise
they
have
difficulty
defending
the
IOT
devices
from
malware.
They
also
have
difficulty
defending
the
internet
against
the
IOT
devices,
properly
comments
and
questions.
P
P
P
C
Gonna
say
that
we
wrote
that
in
because
of
a
partial
ignorant,
a
partial
will
throw
in
urines
that
we
don't
really
want
to
go
into
that
space,
but
I
accept
that
what
you're
saying
is
that
probably
we
need
to
be
in
that
space.
I.
Think
the
more
interesting
question
is
what
who
is
going
to
provide
that
attestation,
because
it's
caught
the
enterprise,
it's
going
to
say
we're
trustworthy.
It's
got
to
be
something
that
goes
into
the
certificate
that
says
this
key.
That
you've
just
found
in
this
enterprise
has
some
something
and
we
reviewed
their
policy.
C
C
X
We
put
out
the
draft
right
before
the
deadline
and
I
think
we've
already
published
the
a1
version
and
then
wear
it.
One
of
the
main
comments
that
came
out
of
it
is
we're
not
trying
to
discuss
the
comment
of
the
merits
of
running
dot
to
the
authority.
We're
trying
to
discuss
some
of
the
considerations
that
anyone
who
may
run
dot
on
an
authoritative
server
might
want
to
think
about,
or
we
as
a
group
may
want
to
try
and
look
into
before
it
starts
getting
wide
deployment
around
the
world.
X
So
the
here's,
the
list
of
the
key
topics
that
were
that
we
talked
about
in
the
draft,
mostly
focusing
on
things
that
we
see,
is
mostly
different
for
someone
running
an
authoritative
versus
of
recursive,
where,
if
a
recursive
goes
down,
the
end
user
may
choose
the
secondary
recursive.
But
if
all
of
your
authoritative
servers
go
down
the
domains,
gonna
be
unresolvable
anyway,
you
can't
pick
a
new
authoritative
for
it
and
then
like
system
tuning.
X
The
current
status
of
the
draft
is,
we
said
we
put
out
the
old
one.
We
have
a
couple
more
items
from
the
list
from
some
of
the
comments
and
feedback
we
got
already.
We've
I
pushed
a
new
update
to
the
1.1
section
of
the
draft
that
will
try
and
get
out
in
the
next
couple
days
and
then
we're
gonna.
We
have
a
couple
more
things
to
address
from
the
comments
we
got
so
already,
but
we
should
be
done
with
that
fairly
soon.