►
From YouTube: IETF109-DPRIVE-20201120-0900
Description
DPRIVE meeting session at IETF109
2020/11/20 0900
https://datatracker.ietf.org/meeting/109/proceedings/
A
A
All
right
greetings:
everyone,
we're
gonna,
go
ahead
and
get
started.
I'm
gonna
dispense
with
trying
to
figure
out
who's
in
what
time
zone
so
I'll
just
say
hi
to
everyone.
A
Welcome
to
the
the
last
session
on
the
last
day,
always
the
fun
place
to
be
for
ietf
meetings.
This
is
deprived.
I'm
brian
and
my
illustrious
co-chair
tim
is:
is
writing
shotgun.
A
The
the
agenda
for
today
is
is,
is
going
to
be
fairly
light
on
on
different
topics,
but
we're
going
to
have
a
an
in-depth
discussion
of
of
of
one
particular
topic
before
we
get
started.
A
A
So
you
know,
if
you're
bored
of
listening
to
me,
stand
here
and
and
run
my
mouth,
you
can
go
off
and
read
all
these
bcps
and
make
sure
you
understand
everything
that
is
is
required
of
you
as
a
participant
in
the.
A
Ietf,
I'm
sure
most
of
you
know
that
we
don't
have
to
sign
blue
sheets.
While
we're
doing
all
this,
virtually
the
that
information
will
be
collected
automatically
for
meat
echo.
A
So
the
agenda
for
today
we're
going
to
do
any
check
for
agenda
updates,
we'll
do
a
quick
document
status
on
7626
and
then
we'll
go
through
and
do
the
essentially
the
three
active
documents
that
we
that
we're
currently
focused
on
zone
transfer
over
over
dot
dns
over
quick
and
then
we'll
have
a
a
longer
working
session
to
to
start
trying
to
hammer
out
some
of
the
details
that
go
into
the
phase
two
requirements
document.
B
So
there's
been
a
lot
of
active
discussion
in
the
last
two
weeks,
not
on
the
phase
two
requirements,
but
on
things
that
relate
to
phase
two.
So
I'm
hoping
that
that
last
bullet
point
where
you
say
phase
two
requirements
actually
can
encompass
some
of
the
things
that
we've
been
talking
about.
Specifically
how
some
of
the
mechanisms
that
would
come
out
would
relate
to
each
other
would
relate
to
things
like
dns
hop
and
such.
B
A
A
Okay,
so
just
a
quick
update
on
on
7626
biz,
there
is
a
discuss
tim
and
I
have
been
talking
about
how
to
respond
to
it
and
working
through
the
details
of
of
the
the
of
that
response
and
and
hopefully
we're
going
to
get
something
out
into
that
inevitable.
Real
soon
time.
C
A
All
right
so
moving
on
so
we're
gonna,
we're
gonna
have
a
a
couple
of
quick
talks
to
to
do
an
update
on
the
zone,
transfers
and
and
dns
over
quick.
So
I'm
going
to
turn
things
over
to
sarah,
who,
I
believe,
is
going
to
be
doing
the
presentation
and
I
will
I'll
drive
this.
You
got
that
you
ready
to
go.
Sarah.
E
Okay,
what
I
need
to
do
is
share
my
screen,
which
it
is
not
very
happy
with
me
doing,
come
on.
E
D
Okay,
thanks
right,
so
I'm
going
to
talk
about
the
zot
draft.
That's
stone
transfer
over
tls.
D
One
of
the
reasons
for
that
is
that
we
have
had
no
comments
to
date
on
this
version
on
the
list.
So
just
so,
I
can
understand
where
to
pitch
this
presentation
and
the
in
a
quick
discussion
with
the
chairs,
it
seemed
that
if
people
who'd
read
it
could
just
do
a
plus
one
in
the
chat
that
might
be
the
simplest
and
quickest
thing.
It
just
will
give
us
context
for
people's
comments.
D
Okay,
thank
you.
Next
slide,.
D
So
what
is
that?
It's
essentially
using
tls
as
a
transport
to
do
zone
transfers,
and
the
major
use
case
for
this
is
confidentiality
it's
in
order
to
protect
the
contents
of
the
zone
from
passive
surveillance,
there's
also
implications
in
terms
of
authentication
and
also
in
terms
of
tcp
performance
that
we
discuss
in
the
draft
next
slide.
Please.
D
D
So
the
current
status
is
that
the
draft
itself
was
adopted.
In
november
of
last
year
by
the
working
group,
we
had
no
two
version
out
that
we
presented
at
itf
108.
We
got
a
lot
of
feedback
during
that
presentation,
particularly
on
the
proposed
use
of
alpn
for
this
mechanism,
which
it
was
clear
in
reviewing
those
comments
did
not
have
consensus,
so
we
produced
an
o3
version
of
the
draft
in
october
this
year.
D
We
hope
that
we
have
incorporated
all
the
feedback
that
we
got
back
on
the
o2
version
I'll
run
over
some
details
in
the
next
few
slides
quickly.
We
think
we've
addressed
most
of
the
open
questions
that
are
in
the
draft.
There's
only
a
couple
left,
and
so
what
we're
looking
for
today
is
some
feedback
on
whether
the
working
group
feels
the
document
is
now
going
in
the
right
direction
and
that
we
can
start
pushing
it
towards
a
working
group
classical
next
slide.
Please.
D
D
We
use
zot
for
transfers
over
tls
and
we
differentiate
isotoxfors
and
azot
just
because
there
are
some
very
small
differences
between
how
they
get
treated.
D
The
main
structure
of
the
draft
is
that
we
start
by
talking
about
use
cases
and
the
threat
model.
We
touch
on
the
existing
xfr
mechanisms
and
some
of
the
limitations
and
specifics
on
the
data
leakage.
We
now
have
a
significant
section
where
we
talk
about
updates
to
the
existing
specifications.
I'll
go
over,
that.
We
then
talk
about
the
zot
specification
in
detail,
and
then
we
touch
on
a
couple
of
other
topics:
authentication
mechanisms
and
group
transfer
policies.
D
So
this
draft
now
updates
both
1995
and
5936,
but
really
what
we're
doing
here
is
we're
making
explicit
all
the
implicit
requirements
that
are
there
because
of
rsc
7766,
which
is
the
draft
that
basically
says
how
we
should
be
doing
tcp
in
dns.
So
the
main
two
things
are
to
say:
we
should
be
using
persistent
connections.
We
can
use
keep
alive
to
manage
the
idle
timeouts
clients
should
be
pipeline.
Queries
responses
can
be
intermingled.
D
We
can
use
the
same
connection
for
rxpr
and
xfos,
so
it's
just
explicitly
clarifying
these
things
in
the
context
of
the
tcp
transfers,
and
we
have
a
very
small
update
to
776
to
make
sure
that
the
concurrency
of
connections
is
treated
identically
for
tcp
and
tls.
We
noticed
a
small
discrepancy
when
we
got
back
to
do
this
next
slide.
Please.
D
Okay,
so
the
other
things
that
have
changed
in
the
section
on
the
dot
specification
are
that
we're
now
clearer
on
how
the
authentication
of
the
two
ends
will
work,
so
clients
must
authenticate
servers
and
servers
must
authenticate
clients.
In
other
words,
the
two
ends
of
the
connection
must
be
happy
that
they're
talking
directly
to
the
other
entity
and
there's
a
later
section.
That
gives
the
rationale
for
which
mechanisms
we're
using
here
and
that's
been
modified
again
based
on
feedback
having
removed
alpn.
D
D
We
have
a
section
on
how
you
can
use
extended
error
codes
to
refuse
any
traffic
on
a
tls
connection
that
you
are
not
willing
to
answer
and
what
we
do
in
an
appendix
is
we
outline
some
of
the
options
around
operational
policy
decisions
about
how
a
authoritative
operator
could
choose
to
handle
these
incoming
tls
connections
and
we
basically
just
enumerate
the
possibilities
and
try
and
outline
the
pros
and
cons,
and
that's
now
as
far
as
this
draft
goes
next
slide.
Please.
D
So
at
the
moment
for
the
case
where
a
server
chooses
to
refuse
traffic
on
a
tls
connection,
we're
proposing
in
the
draft
that
you
use
not
supported,
there's
a
possibility
of
using
prohibited
instead
we'd
like
feedback
on
that
or
whether
or
not
this
is
a
specific
enough
case.
We
should
create
a
new
error
code
to
deal
with
it.
D
Similarly,
there's
a
case
where
bind
in
particular
at
the
moment
has
a
quota
on
the
number
of
concurrent
xfls
if
it
exceeds
that
it
will
serve
fail,
and
we
could
also
think
about
adding
a
specific,
extended
error
code
to
signal
that
if
it's
thought
useful
so
that
it
could
potentially
have
something
like
a
back
off
for
the
clients
so
again
feedback
on
that.
Please,
a
small
update
to
the
implementation
section.
That's
in
the
o3
draft.
D
We
have
a
patch
that
we
are
about
to
submit
to
nsd,
where
it
will
do
reuse
by
default,
that
that's
not
its
current
implementation,
but
it's
actually
quite
a
small
delta
to
switch
it
over
to
doing
that.
D
We
are
working
on
a
patch
to
add
zot
capability
to
nsd
when
it's
acting
as
a
secondary
we've
been
testing
against
nsd
itself
and
against
a
tls
proxy,
and
this
week
I
was
actually
able
to
pull
down
the
latest
developmental
bind
code
which
has
very
early
support
for
vanilla
servers.
I've
got
there's
no
explicit
zot
support
in
bind
yet,
but
I
was
able
to
get
zone
transfers
happening
between
patch
dynasty
and
bind
which
was
brilliant.
D
Thank
you
bind
people,
and
so
I
think
we're
moving
towards
a
stage
where
there
are
other
implementers
interested
on
working
on
this.
We
can
start
doing
some
proper
interop
next
slide.
Please.
D
F
Alex
thank
you,
sarah.
I
will
review
that.
I'm
just
wondering
how
do
you
want
to
receive
suggestions
back?
Do
you
want?
Is
there
a
github
for
that
for
that
draft,
or
do
you
want
the
best
comments
on
the
list.
D
There
is
a
github
so
either
I
mean
in
perhaps
that's
a
question
for
the
chairs
in
terms
of
general
mechanisms
within
dprive.
I
probably
prefer
on
the
mailing
list,
because
I
think
it
gains
a
bit
more
visibility,
but
also
happy
to
take
issues
in
github
and
I'm
just
checking
the
draft
to
see.
If
we
put
the
github
link
in
the
draft,
which
I
don't
believe
we
did.
C
Yeah
the
bigger
issues
to
the
mailing
list.
If
it's
editorial
type
stuff,
I
figure
it
can
just
go
through
the
repo
right.
You
know,
spelling
stuff,
you
know
grammar.
You
know
random
small
stuff
like
that.
So,
okay,
if
you
need.
G
G
Basically,
there
may
be
connections
on
port
853
which
are
trying
to
do
regular
or
qrt
queries
which
you
may
want
to
reject
if
the
server
doesn't
support
it.
I'm
wondering
if
it
makes
sense
at
this
point
in
time
to
just
say
that
xfr
is
a
different
nf
operation,
that
it
should
be
on
a
different
port
by
default,
and
then
we
don't
have
to
deal
with
regular
queries
and
xfr
operations
happening
on
the
same
channel.
D
I'm
not
sure
that's
really
warranted
at
the
moment.
I
I
mean
if,
if
the
group
wants
to
go
down
that
route,
of
course,
we'll
look
at
it,
but
it's
not
historically
how
extra
files
are
managed
in
tcp
it.
The
existing
drafts
explicitly
allow
mixing
traffic
on
connections.
D
D
What
one
of
the
things
we
suggest
in
the
draft
is
that,
of
course,
authoritative
operators
are
free
to
use
different
ip
addresses
for
their
xfls,
and
then
they
can
impose
response
policies
on
a
different
ip
address,
so
not
the
published.
They
can
refuse
all
xfrs
on
the
published
ip
address
of
the
name
server
and
they
can
hand
out
a
dedicated
ip
to
just
the
members
of
their
transfer
group
and
that
then
gets
used
for
zone
transfers,
and
that's
something
that's
that's
already
done
operationally.
D
G
C
Definitely
give
it
some
review,
it
there's
been
a
lot
of
changes
since
o2
a
lot
of
good.
It
looks
like,
but
I
think
we're
getting
pretty
close
to
working
group
last
call.
So
that's
that's
why
we
want
to
sort
of
get
folks
to
do
the
due
diligence
and
give
some.
H
Quick
question
for
you:
are
you
going
to
set
a
deadline
for
review
comments.
A
All
right
christian,
are
you
ready
to
go.
A
A
I
Okay,
well
I
mean
this
is
a
presentation,
it's
an
update
on
dns
of
a
quick
and
showing
the
work
that
we
have
been
doing
for
the
last
well,
since
the
last
meeting
and
well
I'll
get
directly
to
the
next
slide,
which
is
the
only
slide
in
this
talk.
I
The
basic
observation
is
that
the
draft,
the
dns
of
a
quick,
has
not
changed
in
a
while,
I
mean
we
did
an
update
recently
to
make
sure
that
we
are
not
kicked
out
of
the
dwarf
repository.
But
apart
from
that,
we
don't
change
anything.
I
I
I
We
did
not
have
a
whole
lot
of
feedback,
but
I
mean
which
means
that
people
are
probably
happy
with
the
spec.
It
also
may
mean
something
else.
I
mean
the
the
reason
we
did
not
have
a
whole
lot
of
feedback,
maybe
that
not
many
people
care,
and
so
I
I
would
actually
like
to
test
that
and
to
see
whether
people
will
be
willing
to.
I
I
don't
know,
start
prototype
developments.
Try
quick
in
in
tools
that
do
performance
measurements.
Try
quick
in
other
places
to
see
whether
it
can
be
deployed
in
the
infrastructure.
We
don't
know
whether
there
are
some
requirements
about,
maybe
in
practice
doing
some
tunneling
or
some
proxy
before
hitting
the
server.
I
I
I
know
that
the
reminder
of
this
session
will
be
discussing
authoritative
and
using
of
encryption
for
traffic
to
authoritative.
I
I
The
reason
for
that
is
that
quick
allows
for
views
of
connection
allows
for
management
of
multiple
streams,
parallel
things
etcetera,
which
are
probably
less
of
a
head
for
a
server
than
running
tls
over
tcp.
When
you
don't
have
to
manage
all
those
tcp
connections,
you
can
do
with
a
single
udp
port
and
that
may
be
beneficial.
I
But
again
that's
something
I'd
like
to
get
the
feedback
of
the
group
on
there,
and
so
that's
pretty
much
my
my
point
I
mean:
do
we
have
feedback,
or
should
we
say
that
we
are
done
and
just
go
for
publication?
Should
we
go
as
standard
or
experimental?
J
Yes,
thanks
christian,
you
say
several
implementations
are
available,
but
the
draft
does
not
have
an
implementation
status
section
and
I
think
that
would
be
would
have
to
be
very
clear
before
we
can
say
we
are
done.
I
K
Hi,
I
I
agree
with
your
assessment.
I
think
that
there's
I
think
dns
for
quick,
is
much
more
interesting
for
recursive
to
authoritative.
You
know
we
have
good
deployment
feedback
already
on
for
dns
over
http
3
for
a
stub
to
recursive.
That
seems
to
fit
pretty
well.
K
K
I
think
that,
based
on
the
data
tracker,
it
doesn't
look
like
this
draft
has
been
adopted,
so
I
would
I
would
support
adoption.
I
think
that
we
still
there's
kind
of
no
reason.
K
K
The
yeah,
I
think
it's.
K
I
think
it's
worth
pursuing,
at
least
as
at
least
as.
I
C
C
C
C
Okay,
while
daniel
figures
out
his
mic
mic
world
and
with
some
good
feedback
from
peter
actually
can.
L
L
So
you
mentioned
that
dns
over
tls
requires
the
server
to
track
a
bunch
of
tcp
state
instead
of
udp
state,
but
I
think
the
difference
is
really
just
about,
at
least
for
typical
deployments.
What
happens
in
the
kernel
versus
what
happens
in
user
space
because
it
seems
like
there's
still
a
comparable
amount
of
state,
maybe
even
more.
That
needs
to
be
tracked
in
the
doq
scenario
than
in
the
dot
scenario.
I
Well,
the
one
thing
from
an
implementation
point
of
view
is
that
if
you
have
to
manage
just
one
udp
circuit,
it
is
simpler
than
managing
one
circuit
by
tcp
connection.
I
So
so
there
is
that
which
is
very
clear.
The
stat
per
quick
connection
in
my
implementation
is
about.
I
So
I
I
think,
that's,
I
think,
that's
a
good
scaling.
L
I
I
The
point
is
that
it's
very
easy
to
handle
low
activity
connections,
so
I
mean
the
override
of
handling
a
connection
there
is,
is
not
very
high
there
and-
and
you
can
also
then
go
into
scaling
by
multiple
threads
and
things
like
that.
If
you
want
to,
but
I
said
I
mean
that
the
the
actual
mean
the
state.
The
memory
set
is
large.
The
memory
state
is
part,
maybe
for
cable,
the
connection
because
of
all
the
the
security
stats
and
things
like
that.
C
B
So
responding
to
one
or
two
messages
in
the
chat
where
someone
asked
are
we
talking
about
dna?
You
know
raw
dns
over
quick
or
dns
over
http
three
over
quick
and
since
this
strap
is
very
clearly
about
the
former.
You
know,
and
I
don't
see
any
any
reason
to
put
hgp3
in
the
middle
there
based
on
what
we
learned
from
the
doe
work
it
just
it.
I
I
can't
see
an
advantage,
and
so
I
would
you
know
as
as
this
moves
forward.
B
I
would
like
it
to
stay
where
it
is
now,
which
is
raw
dns
queries
over
quick
transport
thanks.
M
I
think
that,
in
order
to
I
think
we
really
need
public
benchmark
numbers,
comparing
dns
over
quick
versus
dns
over
http
3..
I
think
that
will
add
that
will
clarify
whether
or
not
this
this
should
be
expanded
to
be
stopped
to
recursive
or
to
other
use
cases
that
are,
you
know,
outside
of
the
current.
I
I
Yeah
I
mean
clearly
we
need
more
benchmarks,
that's
that's
something
we
can
do,
but
I
mean
I
I
hesitate
of
doing
too
much
benchmark.
If
it's
just
I
mean
when
you
do
benchmark,
you
always
have
so
many
variables
that
it's
it
makes
much
more
sense
to
see
that,
in
the
context
of
somebody's
implementation,
somebody's
server,
I
mean,
if
I
do
a
benchmark
in
a
on
a
virtual
machine.
I
I
I
The
size
of
the
response
is
maybe
10
percent
larger,
but
the
my
main
worry
with
doing
h3
for
this
kind
of
application
is
that
you
bring
all
the
complexities
of
the
http
service.
I
mean
either
you
do
a
bespoke
h3
and
there
are
tiny
h3
stack.
I
have
one
I
could
do
h3
with
like
2
000
lines
of
code,
but
that
means
that
you
are
doing
something
which
is
specifically
designed
for
your
server
and
when
people
say
I
want
to
run
that
on
my
web
server,
20,
not
what
they
mean
they
mean.
I
I
N
I
was
about
to
give
up
and
just
go
so
I'm
torn
I'll
I'll,
be
honest
because
I
I
think,
dennis
over
quick,
likely
shows
some
promise
over
other
things,
but
the
ietf
has
notoriously
had
a
difficult
time
with
deploying
you
know
some
protocol
over
multiple
transports.
N
E
N
Security,
transport,
you
know
if
we're
trying
to
move
away
from
over
unencrypted
udp
and
tcp
and
and
the
rest
become
optional
and
a
lot
of
times
the
optionals
don't
actually
end
up
getting
used
and
implemented.
N
That
being
said,
I
want
dns
over
quick
on
the
table.
Hence
the
reason
I'm
torn
right.
You
know
to
be
able
to
pick
between
them,
but
I
do
wonder
in
the
long
run
you
know.
Are
we
going
to
fall
down
to
one
that
actually
gets
implemented,
deployed
and
becomes
sort
of
the
de
facto
standard
of
which
one
people
use.
N
Right,
but
how
much
work
do
we
go
through
standardizing
the
rest
and
making
them
work
and
writing
code
around
them
only
then
to
rip
them
out
later?
You
know
it's
a
waste
of.
It
would
be
nice
if
we
had.
You
know
this
big
summary
table
of
of
all
of
them
with
their
perfect
characteristics
and
benchmarks
on
every
potential
platform,
and
you
know
that's
impossible.
Of
course,.
I
C
K
Hi,
so
in
terms
of
making
progress
on
this
draft,
one
thing
that
I'd
like
a
little
more
thought
on
is
the
axfr
use
case.
So
the
draft
currently
says
no
effort
is
made
to
support
axfr.
K
It
seems
like
supporting,
supporting
that
kind
of
transfer
should
be
straightforward
as
a
protocol
matter
in
dns
over
quick
and
given
the
previous
previous
presentation
on
interest
in
doing
that
with
dns
over
tls.
I
think
it
would
be
really
good
to
have
parity
with
between
dns
over
tls
and
dns
over
quick,
especially
since
we're
talking
about
working
the
emphasis
here
toward
recursive
to
authoritative,
so
where
authoritative
servers
would
be
implementing
dns
over
quick
yeah.
I
K
Right
drive
has
rechartered,
so
this
is
now
in
scope.
I
think
it
may
just
be
a
small
change
to
the
text.
K
K
One
deployed
example,
you
can
see
now
is
next
dns,
which
makes
user
accounts
and
uses
http
account
and
path
mechanisms
to
distinguish
many
thousands
of
different
dns
servers
on
a
single
domain,
a
single
potentially
a
single
ip
address,
with
different
behaviors
policies,
privacy,
settings
logs
that
relies
on
the
http
semantics.
It
would
not
be
possible
with
any
other
transport.
E
I
Yes,
I
mean
I
I've,
I've
heard
two
things
I
mean
the
implementation
and
also
adding
the
axfr
support.
I
mean,
basically,
compatibility
is
either
by
reference
to
the
xot
draft
or
by
adding
some
text
or
crossing
the
two
that
we
can
certainly
do
that.
I
A
Yeah
christian,
I
would
suggest,
starting
with
the
with
the
implementation
information,
so
that
people
can
start
doing
some
comparisons
and
testing
and
and
then
I
I
think,
some
of
the
the
the
axfr
functionality
we
can
discuss
as
we
as
we
kind
of
push
the
the
phase
two
work
now
and
and
see
how
those
two
relate.
I
I
C
So
is
this
getting
into
the
phase
two
section
of
the
meeting
yep
so
and
and
as
mr
paul
politely
pointed
out,
there
has
been
a
bunch
of
conversation
in
the
on
the
mailing
list
in
the
past
couple
weeks
and
a
lot
of
discussion
about
opportunistic,
which
is
something
that's
you
know,
has
sort
of
come
up,
not
it's
not
in
the
phase
two
stuff,
but
it's
there
seems
to
be
a
lot
of
interest
in
that
and
before
I
started
kicking
off
on
some
of
this,
I
wanted
to
see
if
any
any
folks
wanted
to
step
up
and
sort
of
chat
about
opportunistic
and
why
they
feel
it's
it's
better
than
what's
going
on
here,
etc,
etc
and
so
paul
you
may
speak.
B
But
the
thing
two
requirements
apply
equally
to
opportunistic
and
and
fully
authenticated.
So
I
I
I
I
think,
that's
a
false
dichotomy
and
I
made
a
few
comments
in
the
github
repo
for
the
phase
two
stuff,
but
they
were
mostly
editorial
or
asking
for
extensions.
I
I
I
don't
see
any
competition
at
all
there.
I
I
think
that,
with
the
phase
two
requirements,
once
once,
we
have
those
down-
that's
orthogonal
to
the
use
cases
of
either
opportunistic
or
you
know,
force
forced
authentication.
B
J
I
agree
with
what
paul
said:
I
don't
think
of
genetic
and
pinned
authenticated
signals.
Whatever
are
competitors,
so
we've
seen
an
email
where
people
enable
tls
on
their
m
axis
and
people
just
connect
to
that
without
any
dane
records,
present,
etc.
J
Also,
right
now
we
don't
have
any
standards
for
signaling
pinning
authenticating
whatever
the
one
problem
I
have
opportunistic
is
that
it
might
involve
some
probing
on
there's
oversight.
I
don't
like
that,
and
the
the
pulse
draft
currently
really
skips
over
that,
but
bottom
line.
I
think
opportunistic
and
authenticated
are
two
valid
things
that
we
should
both
pursue.
J
D
D
Is
it
written
down
anywhere
what
we
think
we
mean
by
full
authentication,
and
by
that
I
mean
the
details
of
aspects
like
I
mean
that's,
really
a
recursive
decision
and
it
will
be
dependent
on
what
signaling
information
it
gets.
So
is
it
the
case.
We
mean
that
if
any
one
ns
server
for
a
zone
advertises
any
secure
protocol
and
no
authenticated
connection
can
be
made,
then
the
recursive
must
hard
fail
and-
and
it's
just
a
question
of-
is
that
an
assumption
everybody's
making
or
is
it?
Is
that
the
policy
around
that
written.
D
C
I
I
don't
think
it's
fully
written
down
and
maybe
that's
the
part
of
the
problem
is
there
some
assumptions
there
that
looking
at
the
requirements
for
the
phase
two
you
you
may
be
onto
something
there.
So,
let's,
let's
have
paul
and
peter
sort
of
chime
in
first.
B
A
quick
answer
is
no,
it
hasn't
been
written
down.
It
is
a
lot
of
assumptions.
Some
of
the
people
who
have
been
you
know
vehemently
against
opportunistic,
who
you
know
and
they're
against
it,
because
they
want
fully
authenticated,
have
made
some
assertions
invaria
in
and
things,
but
there's
not
a
draft
or
anything
like
that.
J
L
Yep
thanks,
I'm
hoping
I'm
not
underwater
again,
so
it
seems
to
me,
like
we
have
three
distinct
cases
here.
Thinking
about
what
sarah
was
was
considering.
So
one
case
is
sorry.
Well,
there's
four
with
the
the
null
case
right,
the
current.
In
all
cases,
none
of
the
recursives
do
any
secure
confidential
transport
to
the
authoritatives
right.
The
second
one
is
a
form
of
probing
opportunistic
transport.
L
The
third
case
is
a
signaled,
opportunistic
transport,
and
the
fourth
case
is
the
is
the
hard
fail
case
that
sarah
was
describing
where
there
is
a
signal
that
indicates
that
the
recursor
should
expect
a
authoritative
transport
sort
of
the
the
sts
dns
sts.
If
you
will
right-
and
so
the
question
is,
do
we
want
to
deal
with
all
three
of
these
variants?
L
If
we
just
want
two,
then
the
question
is:
do
we
want
probing
opportunistic
or
do
we
want
signaled
optimistic
right?
So
I
think
that's
the
way
to
break
down
the
question
that
we're
facing
here
and
I'd
be
curious
to
know
if
other
folks
in
the
working
group
have
a
preference
in
those
broad
categories.
I'm
setting
aside
what
the
signaling
mechanism
is
to
be
clear
and
whether
the
signaling
is
done
by
zone
or
by
server.
Those
are
those
are
the
sort
of
orthogonal
questions.
D
I
just
wanted
to
throw
in
a
couple
of
related
comments
while
on
the
topic,
so
they
get
captured,
which
is
that,
if
we're
going
to
think
about
this
from
a
recursive
centric
approach-
which
I
I
think
is
what
this
part
of
the
problem
is,
I
think
it's
also
interesting
questions
to
ask
about
how
recursives
might
describe
their
policies,
and
we
should
also
remember
that
they
may
need
to
signal
back
to
their
clients
why
they
failed,
for
example,
with
new
extended
error
codes,
because
this
seems
very
analogous
to
the
dns
case
of
of
upstream
failures.
K
Hey
ben
schwartz,
so
dkj
listed
four
different
categories
of
behaviors.
I
think
those
those
are
good
categories,
but
I
actually
think
this
problem
is
kind
of
irreducibly
complicated
with
a
lot
more
interesting
corner
cases
like
more
axes
that
that
have
interesting,
unavoidable
knock-on
effects
like
distinctions
and
behavior
between
okay.
What,
if
there's
a
what?
If
there's
a
signal
that
tells
us
that
we're
in
the
sts
case?
K
C
C
No
and
I
think
when
we
look
at
some
of
the
off
the
phase
two
stuff
when
we
talk
about
requirements
about
you,
know,
authoritative
domains
and
I
think
daniel
had
a
good
point
about
focusing
on
the
cases
without
separating
you
know,
without
worrying
about
the
the
name,
servers
or
the
zones
or
how
that's
all
managed
right,
because
I
think
if
you
do
the
first
one,
then
we
can
deal
with
sort
of
the
the
set
of
issues
that
come
up
with
like
you
brought
up,
then
right
where
the
security
postures
don't
quite
match
and
we
can
sort
of
like
work
through
those.
C
I
thought
that
that
was
a
good
way
of
of
saying
that
I
tried
to
write
that
down.
I'm
sure
daniel's
got
it
in
a
minute
so,
but
that
was
I
thought
that
was
a
good
way
of
approaching
that
dkg.
C
Is
it
split
it
up
that
way?
And
yes,
I
think
it
sounds
like
if
we
can
keep
it
to
two
keep
it
simple
to
start
off
with
that's
probably
a
great
great
way
to
start
prototyping
right.
So
okay
did
anyone
else.
C
Looking
at
a
lot
of
the
comment,
yeah
looking
a
lot
of
the
millions
I
wish
tony
was
here
because
he
had
done
some
work
on
this
as
well,
but
sadly
he's
not
because
they
had
sort
of
put
together
a
draft
and
then,
of
course,
in
dean
asap.
We
had
the
mr
fujiwara
son's
draft
about
the
information
signer
bit
the
new
dis
record
and
stuff,
which
I
brought
to
brian
at
like
at
the
last
minute
and
he's
like.
I
said,
we'll
we'll
sort
of
talk
about
that.
C
I
thought
that
was
very
interesting
work
and
it
may
be
relevant
here
about
how
parents
get
delegation
data
and
you
know
and
what's
signed
and
what's
not
signs
and
things
of
that
nature.
So
and
I
think
when
we
even
look
at
the
phase
two
stuff,
we
only
look
at
it's
funny
because
we're
talking
about
you
know
domains
it's
sort
of
at
the
you
know
the
second
level
and
but
we're
not
looking
at
sort
of.
You
know
where
a
domain
has
many.
C
You
know
child,
you
know
subdomains
and
it
has
different
ns
delegations
and
how
that
all
sort
of
you
know
sort
of
plays
out,
and
I
think
that
will
be.
You
know
a
crazy
place
to
go.
So
I
think,
if
we
want
to
dig
into
these,
then
let's
we
can
jump
into
like
the
the
list
of
requirements
that
looks
like
they've
been
broken
down.
A
A
So
what
I
did
is
I
took
the
11
requirements
that
were
that
were
documented
in
section
5.1
of
the
requirements
draft,
and
I
I
I
put
a
an
ordering
on
them
based
on
the
discussions
that
I
saw
on
the
mailing
list,
so
the
ones
that
that
were
were
seem
to
be
fairly
popular
in
in
in
people's
comments
on
the
mailing
list
got
moved
up
to
the
top
of
the
list,
but
my
expectation
is:
is
that
you
know
we're
gonna,
we're
probably
gonna,
be
doing
revisions
of
these
as
we
as
we
cover
other
requirements.
A
A
The
the
other
thing
that
I'm
going
to
say
is
that
I
know
we're
not
going
to
get
through
all
11
today.
My
thought
was
is
that
we
could
do
an
interim
in
january
and
an
interim
interim
in
february
to
keep
working
on
these
and
keep
the
the
ball
rolling
forward,
rather
than
letting
things
sit
for
three
or
four
months
in
between
meetings.
So
you
know
my
my
goal
here
is:
is
to
to
to
get
the
working
group
actively
looking
at
these
requirements
and
making
sure
that
we're
we're
identifying
the
right
ones.
A
C
Thanks
brian
I'm
going
to
drop
daniel
from
the
queue,
so
he
doesn't
confuse
me
so
we'll
kick
off
with
the
requirement:
seven,
which
is
about
authoritative
domain
owners,
and
this
this
is
sort
of
a
long
one,
but
it
this
goes
into
the
opportunistic
strict
you
know
what's
being
specified
and
and
how
these
are
being
specified.
Basically,
so
must
have
the
option
to
specify
the
secure
transport
preferences
and.
C
That's
yeah
so
any
comments
on
this
one,
because
this
one
I'm
wondering
like
how
should
those
things
get
published,
et,
cetera,
et
cetera.
That's
where
I
think
opportunities
becomes
very
interesting.
Okay,
go
ahead,
mr
ben.
K
So
this
is
just
to
remind
everybody
that
I
I
have
a
draft
proposal
for
how
to
express
which
protocols
are
supported.
I'm
not
the
only
one
who
has
such
a
proposal.
There
are
a
few,
the
one
that
I
wrote
is
called
service
binding
for
dns
svcb
for
dns,
and
it's
currently
named
in
the
add
working
group.
It
is
not
adopted.
C
C
Me
so
paul.
B
So
I
brought
this
one
up
on
the
mailing
list,
specifically
the
end
part,
which
is
you
know,
and,
and
it's
just
appeared
in
the
chat
now
again
the
idea
that
an
authoritative
server
could
say
to
a
resolver.
You
must
authenticate
me
or
whatever
is
sort
of
absurd,
even
in
the
in
the
case
of
authentication.
B
That
is
it's
a
preference.
It's
fine
to
say.
I
would
prefer
that
you
ignore
me
if
you
can't
authenticate
me,
but
making
any
demand
seems
pretty
over
the
top
and
in
specific,
because
there
will
probably
be
multiple
ways
of
authenticating,
and
so
if,
for
example,
a
resolver
who
is
trying
to
authenticate
gets
a
positive
authentication
using
one
mechanism
and
a
negative
using
another,
what
is
it
supposed
to
do
with
that
demand?
B
So
I
would
like
to
see
that
latter
part
not
necessarily
dropped,
but
you
know
cranked
down
to
being
a
requirement
that
an
authoritative
server
might
be
able
to
suggest
preferences.
I
also
on
the
list
I
had
said
on
the
early
part.
Well,
you
can
just
probe
reports
and
I
agree
with
people
who
have
said
that
that
has
some
some
problems.
B
I
think
it's
still
doable,
especially
if
there's
a
transport
cache,
but
it
seems
likely
that
this
requirement
of
there
should
be
a
deterministic
way
that
is
faster
than
waiting
for
a
timeout
on
a
porch
is
a
really
good
idea.
Thank
you.
Okay,.
C
J
C
L
So
I
just
wanted
to
respond
to
paul's
comment
in
that
right.
Any
any
announcement
that
I
as
a
server
would
prefer
you
to
connect
to
me
over
an
encrypted
channel
is
like
it's
not
enforceable,
but
it
it
can
be
stated
as
a
strong
preference
right.
It
says
I'm
not
going
to
offer
these
these
services
in
the
clear
if
you
find
them
in
the
clear
you
know,
I'm
making
no
guarantees
about
what
you
get,
because
I
don't
offer
them
that
way.
Right.
We
have
this
in
http,
it's
hsts
right.
L
It
says,
don't
don't
connect
me
in
cleartext.
I
promise
you.
I
have
the
secure
transport
set
up,
don't
do
it
and
you
could
still
do
it,
but
it'll
tell
you
don't
do
it.
We
have
it
in
mtas
ts.
It
says
when
you
send
mail
and
mtists
has
a
has
a
flag
right
that
says
enforce
says
I
promise
you
that
that
star
tls
will
be
available,
and
I
would
prefer
that
you
don't
deliver
until
you've
got
the
secure
transport
right
now.
L
Of
course,
it
can't
enforce
that
the
client
does
that
the
network
operator
can
always
you
know
the
network-based
attacker
can
always
offer
clear
text
transport
for
any
unwitting
person.
You
know
client
that
refuses
to
honor
it,
but
I
think
we,
I
think
it's
still
safe
to
say
that
this
is
a.
This
is
a
strict
proposal
right.
It's
saying
I
guarantee
you
the
secure
transports
available.
L
You
should
use
it,
you
shouldn't
use
anything
else
and
if
we
try
to
qualify
it
more
than
that,
I
think
it's
a
mistake
right
that
that's
the
that's
the
strict
statement.
It's
like
the
enforce
variant
of
mta
sts.
I
mean,
I
think
I
think
it's
there's
there's
two
things
right.
One
says
I
offer
secure
transport
and
the
other
one
says
I
would
prefer
that
you
enforce
strict
transport.
Do
not
fall
back
to
clear
text.
C
L
I
wouldn't
want
you
to
have
to
say
that
in
order
to
stand
up,
you
know
doq,
authoritative,
you
must
tell
the
world
that
they
must
that
that
clear
text
transports
are
broken
for
you,
I'm
saying
that's,
that's
it's!
A
simple
boolean
switch
that
you
can
as
long
as
there's
a
signaling
mechanism.
You
need
to
be
able
to
say
this.
You
know
and-
and
I
think
you
shouldn't
try
to
connect
to
me
in
the
in
the
clear.
L
C
L
C
L
C
O
Okay,
so
I
mean
in
dns
having
such
kind
of
upgrade
is
always
harder,
because
the
space
that
we
have
of
different
kind
of
actors
that
do
stuff
and
operate
stuff
is
much
bigger.
So
if
you
have
a
signal
preferred
I
mean
the
first
thing
is
you
have
to
understand
the
signal,
but
this
will
only
happen
shortly
over
time
and
the
other
thing
we
have
that
I
don't
think,
is
there
in
http.
O
If
you
have
a
signal
for
that
domain,
that
you
only
want
to
connect
over
a
secure
transport,
however,
either
coming
down
the
chain,
there
is
something
that
requires
integer
transport
or
there
is
a
name
server
out
of
a
different
domain
that
doesn't
have
the
same
secure
transport.
Then
what
do
you
do?
I
mean
there
are
lots
of
edge
cages
there
that
make
it
hard
for
the
server
to
decide.
O
If
I
see
a
secure
transport
do
I
really
need
to
take
that
as
face
value
and
then
drop
stuff,
or
shall
I
resolve
it
and
the
other
thing
is:
I
mean
the
people
who
are
operating
resolvers,
you
get
a
call
if
something
doesn't
resolve
and
so
the
on
the
on
the
operator
side.
It's
often
more
important
to
give
an
answer
than
to
not
give
an
answer.
C
Okay,
thanks
ralph
dwayne.
P
Thanks
tim,
we
started
off
talking
about
requirement,
seven
right,
which
is
focused
on
domains.
You
know
zones
signaling
their
preferences
and
I
feel,
like
the
discussion,
may
have
wandered
off
a
little
bit
into
server-based.
Signaling
names
are
basically
so
I
just
want
to
make
sure
we're
focused
on
the
right
thing
here
and
clarify
that
that
we're
talking
about
zones
signaling
their
preferences
rather
than
servers
signaling
their.
K
Hey
so
I
actually
want
to
argue
against
a
bunch
of
these
requirements.
I.
K
These
requirements
are
too
strict.
They
presuppose
a
a
bunch
of
aspects
of
the
solution
and
I'm
not
sure
that
I
want
a
solution
that
actually
meets
all
these
requirements.
So,
for
example,
requirement
7
says
that
the
that
the
indication
has
to
include
a
way
to
distinguish
strict
and
non-strict.
K
Descriptions
you
know
it's,
it's
not
clear
to
me
that
it's
important
to
be
able
to
express
non-strict
endpoints,
especially
given
that
non-strict
endpoints
can
also
just
be
discovered
opportunistically
over
the
network
without
indication.
K
Similarly
requirement.
Nine
says
that
a
name
sir,
that
it
effectively
says
that
it
it
must
be
possible
for
a
name
server
to
to
support
use
of
secure
transport
protocol
for
one
zone,
but
not
for
another.
Maybe
I
misunderstand
the
normative
language
here,
but
that
also
seems
like
a
an
intriguing
possibility,
but
not
something
that's
crucial
for
us
to
support
to
declare
success.
L
I
I
have
an
answer
yeah
sure,
so
I
agree
with
ben
that
these
requirements
seem
a
little
bit
strange
to
me
that
they're
not.
L
They
don't
distinguish
in
some
cases
between
whether
the
the
secure
transport
is
expected
to
be
opportunistic
or
not
like
requirement
nine.
I
I
don't
know
why
we
care
if
a
name
server
wants
to
offer
opportunistic
transport
for
a
given
zone,
and
I
also
don't
know
why
requirement
7
does
focus.
Just
speaking
to
the
to
the
earlier
point,
I
think
dwayne,
who
said
it,
that
the
signaling
needs
to
be
per
zone
and
not
per
server.
L
Is
that
a
decision
that
we've
made
collectively
as
a
group?
And
if
so,
what's
the
justification
for
it?
I'm
not
saying
it's
the
wrong
decision.
I
just
think
that,
like
I
can
see
three
different
ways,
you
could
scope
a
signal
if
we're
talking
about
how
to
do
signaling
right.
The
three
different
ways
that
I
can
see
are
by
the
name
of
the
name
server
by
the
zone
and
by
the
ip
address
of
the
main
server.
So
I
could,
I
can
imagine
three
different
forms
of
signaling,
there's,
probably
more,
I'm
sure
we're
all
clever
people.
L
C
So,
generally,
in
the
world
of
zone
transfers,
it's
usually
done.
You
know
it's
consenting
parties
with
ip
addresses
and
stuff
and
names,
don't
usually
pop
up
in
this
sort
of
the
conversation,
and
I
think
I
saw
that
in
the
chat
as
well
from.
I
think
it
was
peter.
Are
we
talking
about
recursive
to
authoritative?
C
Oh
sorry,
sorry
I
you're
right.
I
got
off
on
the
I
got
off
on
the
on
the
transfer
thing
because
but
you're
yes,
but
I
think
also
the
name
of
the
name
server
gets.
You
know
it
that
one's
a
little.
It's
it
it's
an
interesting
way.
I
don't,
I
I
think,
to
zone
an
ip
address,
yes,
but
yes
and
zone
versus
server.
C
So
I
I
don't
think
we,
oh
so
going
back
to
your
first
con
first
thing
and
brian
you
may
want
to
speak
up.
We
didn't,
I
don't
believe,
we've
actually
decided
if
we're
doing
it,
based
on
a
on
a
zone
or
server
kind
of
thing.
I
think
when
they
started
writing
the
document,
that's
what
they
sort
of
decided.
You
know
they
picked
oh
alexander's
here.
So
as
one
of
the
authors,
so
maybe
he's
got
some
comments
on
that.
So,
let's
alexander,
why
don't
you
go
ahead?.
F
Thank
you
team.
Well,
generally,
I
I
agree
with
them
right
now.
They
appear
a
bit
a
little
bit
like
misleading
and
I
think
they
don't
like
reflect
the
original
intent,
and
I
think
that
what
we
could
say
before
is
that
he
nailed
it.
Actually,
we
haven't
yet
decided
whether.
F
To
me,
when
a
client
sees
that
one
stone
that
is
hosted
on
the
name,
server
can
be
accessed
by
a
secure
one
code
protocol.
Is
it
to
assume
that
all
the
other
phones
that
are
delegated
to
the
name
server
can
be
accessed
by
the
secure
transfer
protocol
as
well?
That's
the
point,
and
I
think
that
what
what
daniel
said
before
is
very
important,
that
we
need
to
make
a
decision
on
that.
F
So
so,
if
the
key
to
the
transport
capabilities
of
a
certain
name,
server,
the
zone,
the
name
server
or
the
ip
address
yeah,
and
I
think
before
we
can
before
we
make
up
our
mind
on
this,
it
doesn't
make
any
sense
to
to
to
to
rehash
those
requirements.
J
J
I
don't
think
we
can
decide
that
today,
for
opportunistic
ip
might
make
more
sense
for
something
signaled
per
zone
might
make
more
sense.
We
shouldn't
decide
that
today
or
put
it
as
a
hard
thing
in
requirements.
Thank.
C
D
D
C
No,
you
have,
and
I
thought
and
that's
actually
you
know
a
fine
question
right.
C
I
think
that's
requirement.
Eight
authority
of
domain
owner
must
have
the
option
to
vary
the
preferences
of
a
particular
dns
zone
that
may
be
delegated
to
multiple
parties,
such
as
cdns.
C
And
daniel
made
a
comment
and
I'm
gonna
go
back
and
read
it
because
he
said
he
makes
much
more
sense
than
I
do.
He
likes
having
two
options:
opportunistic
by
probing
and
signal
strict
mode
and
those
are
actually
that's.
That's
two
of
your
your
four
basically.
L
Yeah
so
the
reason
the
more
we
talk
about
this,
the
more
I'm
leaning
in
that
direction.
I
I
hadn't
made
that
list
with
the
intention
of
advocating
specifically
for
those
two
but
but
here's.
Why
I'm
thinking
that
we're
struggling
right
now,
with
figuring
out
how
to
handle
signaling
the
scope
of
signaling,
what
the
signaling
is
all
of
that
stuff
and
that's
a
legitimate
struggle
like
there
are
a
bunch
of
smart
people
talking
about
this,
that
that
disagree
with
each
other.
L
Here
I
think,
that's
an
interesting
struggle,
but
I
think
we
can
declare
it
sort
of
out
of
bounds
if
we're
just
talking
about
the
opportunistic
by
probing
model.
Now
we
need
to
answer.
We
need
to
have
that
struggle.
We
need
to
figure
it
out
if
we
want
signaling
to
be
possible,
but
I
don't
see
any
reason
why
we
would
need
the
signaling
to
do
opportunistic,
so
it
seems
like
there's
one
track
of
work,
which
is
guidance
on
how
to
do
probing
effectively
a
bunch
of
folks
in
the
in
the
chat
have
already
identified.
L
A
number
of
you
know
real
sort
of
pain
in
the
ass
things
you
have
to
do
for
probing,
but
hey,
that's
that's
what
you
get
right,
yeah!
So
that's
one
channel
of
work
and
the
second
channel
of
work
is:
if
you
wanted
to
do
strict
mode
like,
let's
not
repeat
the
mistakes
of
smtp
star
tls
right
where
smtp
start,
we
had
start
tls
for
maybe
decades
before
someone
said
hey,
we
ought
to
figure
out
how
to
lock
this
thing
on.
L
So
we
could.
We
can
start
that
as
an
independent
channel.
It
works
that
says.
How
do
we
make
sure
that
it's
possible
to
lock
this
thing
on,
even
if
we
know
that
most
authoritative,
either
servers
or
zones
or
whatever?
However,
we
scope
that
aren't
going
to
lock
it
on
yet
we
can
do
those
those
work
channels
in
parallel.
K
Ben
schwartz
paul
is
up
next.
He
has
smarter
things
to
say
I
suspect,
but
what
I'd
really
like
to
see
is
an
experimental
draft
that
just
specifies
opportunistic
by
probing
on
port
853,
and
that
specifies
in
great
detail
the
state
machine,
trickery
and
time
constants
and
back
off
and
all
the
rest
that
we
think
is
likely
going
to
make
it
work
reasonably.
Well,
we
can
experiment
with
that.
We
can.
We
can
tune
that
while
it's
in
progress
and
then
hopefully
we
can
obsolete
it
once
out
of
the
actual
signaling
mechanism.
B
So
a
couple
of
things
here,
one
is,
I
think
people
are
using
the
term
opportunistic
incorrectly
and
in
my
draft
I
I
started
off
by
you
know
referring
to
the
rfc
that
defines
opportunistic
opportunistic
means.
You
should
try
to
authenticate.
B
So
you
know
people
think,
oh,
let's,
let's
not
do
any
of
the
the
you
know
the
more
advanced
things
of
of
like
you
know,
tlsa
record.
I
think
they're
missing
something
on
on
it,
that
that
opportunistic
folks
might
actually
use
that.
The
other
thing
is,
I
cannot
imagine
that
probing
just
by
port
number
is
going
to
end
up
being
anything
that
people
want
to
do
exclusively
long
term.
B
I
think
at
least
we
will
have
something
that
is
tlsa
like
or
something
in
the
domain
name
like
or
whatever,
and
there's
no
reason
to
you
know
going
back
to
what
ben
just
said.
There's
no
reason
to
start
with
this
and
trying
to
figure
out
good
timing
and
stuff,
because,
as
soon
as
we
have
the
ability
to
do
something
with
a
dns
lookup,
where
the
responses
you
know,
even
with
speed
of
light
issues
are
often
under
half
a
second,
that's
that's
way
less
than
most
people
would
turn
off
their
probes.
For
so
really.
B
The
big
thing
here
is:
is
the
transportation
cache
that
I
mentioned
that
I
said
in
the
draft
that
I
sent
out
today
could
be
actually
a
separate
document,
because
I
think
that's
needed
for
both
the
fully
authenticated
case
and
the
opportunistic
case
and
doing
probes
that
don't
expose
anything.
There's
no
reason
you
know,
given
that
even
an
opportunistic
resolver
might
not
want
to
expose
what
it's
it's.
B
You
know
the
first
query
and
if
it
doesn't
have
to
that's
great,
so
I
don't
want
to
go
to
just
let's
just
look
at
port
numbers
and
and
and
assume
that
that's
going
to
be
good
enough.
I
would
rather
that
we
start
doing
some
of
the
hard
work
that
we've
been
doing
this
week
and
do
that
as
a
start
for
opportunistic
as
well,
but
at
the
same
time,
going
back
to
sarah's
question
from
about
half
an
hour
ago.
B
We
also
need
to
have
an
idea
of
exactly
what
the
people
who
want
to
fail
if
they
cannot
authenticate
what
they're
going
to
do.
That
is
like
an
example.
I
don't
know
if
she
brought
it
up
or
someone
else
did
of
so.
Example.Com
has
two
name
servers,
one
of
which
can
be
authenticated
and
the
second
one
can't
for
you
know
that
they've
just
screwed
up
their
their
authentication.
Somehow.
B
So
if
a
resolver
that
is
doing
script
goes
to
the
second
one
first,
does
it
fail
immediately
or
does
it
try
the
first
if
it
tries
both
the
first
and
the
second
and
sees
that
it's
only
getting
half
z's?
B
F
F
The
information
that
a
resolver
keeps
about
whether
or
not
to
connect
to
it,
to
authoritative,
server
via
secure
transport
and-
and
it
depends
on
on
a
lot
more
dimensions
that
I
initially
saw
because,
for
example,
I
think
that
that
if
in
case
that
the
secure
transport
is
authenticated
with
a
host
name,
I
think
that
it
would
be
safe
to
assume
that
other
zones
that
are
delegated
onto
that
same
host
name
could
be
accessed
by
the
same
secure
transport
protocol
as
well,
which
is
probably
not
necessarily
the
case.
F
If,
if
it's
it's,
it's
opportunistic
or
let
me
put
it
that
way
on-
include
unauthenticated,
secure
transport
so
and
and,
as
paul
said,
it
also
affects
other
decisions,
because
name
servers
already
keep
a
lot
of
state
about
their
authoritative
name
servers
so
including
availability,
information
and
whatever.
So
so,
it
could
be
just
another
factor
in
selecting
a
certain
name,
server
and
yeah,
and
then
again
it's
about
what.
What?
F
If
the
last
name
server
that
provides
secure
transport
for
a
domain
name
fails,
which
would
would
the
result
then
return
to
your
fail,
or
would
it
rather
go
to
an
unknown,
unsecured
protocol
yeah?
So
things
like
that,
it
has
a
lot
of
dimensions
and
I
maybe
we
can
make
progress
by
sketching
down
those
dimensions
in
the
first
place
and
then
investigate
how
they
interact
with
each
other
or,
as
a
couple
of
people
have
said,
I'm
also
a
big
fan
of
like
simply
trying
out
things
and
see
where
it
goes.
C
Yes
agreed
and
ben's
idea
of
a
narrowly
scoped
draft
kind
of
really
sort
of
sinks.
You
know
sits,
sits
well
here
if
you
sort
of
focus
on
opportunities
by
probing
and
then
what's
involved
there
right
and
if
you
look
at
like
requirements,
two
and
three,
which
are
basically
about
how
to
determine
whether
servers
you
know
what's
supported,
and
how
do
you
signal
it
there's
you
know
that
kind
of
digs
into
a
bunch
of
that.
You
know
if
you're
probing,
then
you
can
see
it's
a
different
sort
of
ballpark.
So.
A
And
the
other
part
here
tim
is:
is
that
requirement
two
and
three?
The
way
I
read
them
is
is
implicitly
stating
that
it's
a
it's
per
server
functionality
and
not
per
zone,
and
so
the
question
of
whether
or
not
we're
doing
this
per
zone
or
per
server
is
going
to
directly
tie
into
whether
or
not
these
requirements
even
stay
around.
C
Yeah,
and
actually
in
part
of
some
nearly
scope
draft
should
really
kind
of
just
see
the
you
know.
How
are
we
going
to
address
that
right?
I,
I
think,
that's
something
and
there's
lots
of
different
pieces
that
go
in
there
right.
You
do
it
per
zone
it
it.
It
allows
you
to
be
a
little
flexible,
especially
with
requirement
eight.
C
Where
you
you
know
a
zone
is
sitting
on
multiple
different
types
of
name
servers,
different
vendors
different,
you
know
et
cetera,
et
cetera,
managed
by
different
parties,
so
that
you
know,
I
think
we'll
have
to
sort
of.
I
will
want
to
sort
of
make
that
decision
as
well
as
the
and,
if
we,
I
wrote
down
something
here,
per
zone,
signaling
versus
per
server
signaling,
and
I
think
that
kind
of
gets
down
to
the
the
other
question
of
you
know.
C
Are
we
letting
people
do
it
on
a
per
zone
basis
or
per
server
basis,
and
I
think
there's
pluses
and
minuses
on
both
of
those?
I
think
you
know
note
that
per
server
signal
might
mean
per
name
or
per
ip,
okay,
I'll
I'll.
You
know.
C
C
C
C
B
Block-
and
I
think
that
that's
probably
not
a
good
use
at
this
point-
I
think
that
the
who
wrote
the
current
draft
I
mean
really
because
the
the
zero
one
had
only
minor
changes
and
such
like
that
they
started
a
year
ago
with
a
very
different
set
of
assumptions
than
what
we're
dealing
with
today
and
so
trying
to
shoehorn
it
into
the
current
draft,
I
think,
is
not
a
great
idea.
B
I
think
it's
great
for
us
to
have
a
requirements
draft,
but
I
would
say
that
that
let
the
authors
of
that
take
a
look
at
what's
happened
on
the
mailing
list
in
the
lab
and
maybe
and
and
scrub
and
and
basically
widen,
but
trying
to
do
it
on
onesie
twosie
right
now.
I
don't
think
it's
going
to
be.
Yes,.
C
I
I
agree
and-
and
that's
what
I
was
kind
of
looking
at
this
sort
of
saying.
Oh
yes
be
mostly
because
the
very
you
know,
big
question
of
per
server
versus
per
zone
right
and
the
draft
sort
of
goes
back
and
forth
almost
in
some
ways,
and
I
think
that's
a
big
question
that
I
think
people
really.
We
need
to
really
get
the
working
group
to
sort
of
nail
down
on.
So
that's
what
I
feel
so
others
may.
J
So
early
2019
in
prague
when
maneuver
tell
proposed
dspi
my
first
reaction
was
people
will
hate
this
because
it
allows
people
to
get
some
security
while
not
doing
dns
sec
and
then
a
year
later
we
propose
dot,
pin
which
also
allows
people
to
get
some
security
in
an
unsigned
zone
as
long
as
the
parent
is
signed,
but
it
turns
out
people
don't
hate
that
and
then
later
often
pointed
out.
J
J
C
No
ag
agreed
and
thank
you
no,
I
I
understand
this
there's
a
coupling
that
you
know.
Do
you
have
to
say
dns
people
love,
you
know
we
love
doing
the
dnsec
stuff
and
that's
not
always
the
the
place
folks
can
go.
I
totally
agree.
No
go
ahead.
Wes.
N
Ears
gone,
oh
right,
so
I
will
point
out
that
we
have
one
one
well
worked:
example
of
how
to
do
opportunistic
fallback
from
the
best
to
the
worst
and
even
though
you
know
so,
if
you
start
with
7672,
which
is
which
is
dnsec
based
secured
mail
with
authenticated
records
by
the
by
the
publishing
side
saying
you
know,
you
must
do
authentication
to
me
falling
back
to
opportunistic
encryption,
even
if
you
can't
falling
back
to
smtps.
N
If
you
know,
if
you
can't
do
that,
falling
back
to
straight
smtps,
sorry
straight
smtp,
smtp,
it's
very
late
in
the
night!
For
me,
sorry,
you
know.
There's
some
well
worked
examples
of
where
we've
actually
done
this
in
the
past
and-
and
maybe
one
of
the
right
things
to
do-
is
to
look
at
some
of
those
models
where
that
environment
has
been
growing
steadily.
B
Funny
that
you
should
say
that,
because
one
of
the
parts
of
that
that
people
here
will
probably
really
hate
is
the
fact
that
one
of
the
ways
that
authentication
is
done
in
the
smtp
world,
in
fact,
is
not
tlsa,
but
it
is
using
cas
and
that
a
reasonable
number
of
the
smtp
servers
out
there
that
are
doing
tls,
don't
have
tlsa
records
because
it's
a
hassle
for
them
or
they
don't
know
their
dns
server
operator,
but
they
can
get
assert
and
the
search
they
get
are
horrible.
E
B
For
yeas,
that
is
not
as
gross
and
ugly
as
it
is
in
the
web
or
is
wider
used
in
the
smtp
world.
I
I
see
no
reason
to
say
it
has
to
be
done
in
the
dns,
especially
for
the
opportunistic
case
and
the
opportunities
the
case
where
someone's
willing
to
fall
back,
anyways,
letting
them
authenticate
with
a
ca,
might
be
a
reasonable
way
of
getting
any
of
the
value
of
authentication.
N
B
It
turns
out
that
we
aren't.
You
know
that
we
have
too
many
edge
cases
with
tlsa
or
its
equivalent,
but
I
think
it
can
be
thrown
in
the
mix
just
in
the
same
way
it
has
in
the
smtp
world-
and
I
say
this
as
somebody
who
started
the
fmtp.
You
know
tlso
or
smtp.
If
you
look,
that's
that's
got
my
name
on
it
from
a
bazillion
years
ago
and
that's
when
we
only
had
cas
that
was
that
was
like
a
decade
before
the
route
was
signed.
So
thanks.
K
So
I
agree
with
with
paul
that
we
should
be
open-minded
about
what
the
different
routes
of
trust
we
we
might
end
up
with.
Are
I
think
that
we're
likely
to
find
that
there
are
some
people
in
this
ecosystem
who
won't
touch
the
certificate
authorities
with
a
10-foot
poll,
and
there
are
some
people
in
this
ecosystem
who
won't
touch
dns
sec
with
a
10-foot
pole
and
we're
going
to
have
to
somehow
get
them
all
into
one
big,
happy
family,
and
I
think
it
is
possible.
K
K
But
I
wanted
to
focus
in
on
this
question
of
authentication
from
my
perspective,
in
the
specific
case
where
the
client,
which
is
to
say
the
resolver,
is
willing
to
fall
back
or
expect
to
fall
back
to
clear
text.
If,
if
connection
fails,
I
don't
think
there
is
any
use
in
any
form
of
authentication.
K
So
I
I
don't
think
that
we
even
need
to
worry
about
authentication.
In
that
case,
authentication
is
only
interesting
if
you
will
terminate
the
connection
and
not
deliver
the
query.
If
authentication
fails.
B
Then
I
might
agree
with
you
that
is
in
fact
two
weeks
ago
I
would
have
agreed
with
you,
but
on
the
list.
In
the
last
couple
weeks
a
couple
of
people
have
come
up
with
reasons
for
authenticating
that
are
not
just.
I
absolutely
want
to
guarantee
that
the
communication
was
private
and
that
there
was
no
interloper.
B
So
I
want
to
be
open
about
that
as
well,
given
that
the
definition
of
opportunistic
includes
trying
to
authenticate
if
there's
any
value
at
all.
In
my
previous
draft
I
said
there
wasn't
in
the
draft
I
put
out
today,
I
said
hey,
there
are
some
people
who
are
talking
about
at
least
one
case,
which
I
don't
know
and
again
this
is
just
stuff.
That's
on
the
mailing
list
so
far,
but
I
would
not.
B
C
C
Brian,
what
you
just
sent
me,
I
think
we
should
sort
of
bring
up
a
little
bit
so.
A
What
I'm
getting
out
of
this
whole
conversation
is
is
that
we
we,
we
have
a
group,
a
set
of
requirements
in
the
document
right
now
that
I
think,
for
the
most
part,
have
become
a
bit
obsolete,
because
some
of
the
assumptions
have
gone
by
the
wayside,
and
I
I
would
I'd,
be
curious
as
to
what
the
working
group
thinks
of
of
trying
to
turn
this
conversation
into
more
of
a
you
know
what
we,
what
is
it
that
we
need
to
consider
as
we
develop
these
requirements
from
from
the
use
scenarios
and
and
and
try
and
get
at
some
of
the
the
nitpicky
details
that
we've
covered
today,
like
you
know,
authentication
per
zone
authentication
per
server,
regardless
of
how
the
server's
identified
and
and
and
really
drill
down
on
those
types
of
of
discussions.
C
And
and
take
daniel's
four
four
cases
and,
like
he
said,
break
it
down,
maybe
to
two:
you
know,
opportunities
by
probing
or
signal.
Strict
are
those
the
two
that
we
want
to
focus
on
and
and
go
down
that
road,
and
we
should
sort
of
hash
that
out
too
and
see
what
the
working
group
says.
I
I
I
think
it
was
sarah
who
even
said
keep
it
to
two
if
possible,
because
that
would
make
things
simply
at
least
to
start
off
with,
as
we
start
experimenting.
F
Alexander,
thank
you.
I
think
that
what
I
just
thought
is
that
maybe
some
of
the
experiments
could
even
be
on
paper
like
we
could
identify.
We
have
a
name
server
that
offers
everything
that
currently
offers
over
port
53
udp
over
a
secure
transport
protocol.
That's
unauthenticated!
Let
me
put
it
that
way.
What
does
that
mean
and
play
through
a
couple
of
use
cases
and
scenarios
server
failures
whatever
and
see
whether
we
get
get
more
insight
from
that?
So
we
don't
necessarily
just
need
to
write
code.
G
Hi
punit
here,
I'm
speaking
with
my
resolver
hat
on
and
listening
to
the
discussion
on
the
requirements,
especially
requirement.
Seven,
I
think
one
thing
I
would
like
to
note
is
that
the
whether
the
transport
is
secure
or
not,
is
really
the
server's
server
property,
meaning
multiple
servers
for
a
zone
couldn't
have
can
independently
be
secure
or
not
so
signaling
that
at
the
server
level,
seems
to
make
more
sense,
while
the
strictness
requirement
is
really
the
requirement
or
preference
of
a
zone
owner
right.
G
If
someone's
running
a
super
secret
website,
they
may
want
to
say
do
not
connect
to
me.
Do
not
resolve
names
over
an
insecure
transport
right.
So
I
think
for
the
requirement.
I
would
split
it
that
way,
and
the
other
thing
with
the
strict
requirement
is,
I
think
it's
a
little
premature
as
some
other
people
have
also
mentioned,
that
we
don't
even
have
much
secure
transport
right
now.
So
to
say
we
are
going
to
make
a
secure
transport
require.
A
strict
requirement
is,
I
think,
a
little
premature.
C
K
Hey
so
I
wanted
to
put
you-
and
I
have
have
talked
a
lot
about
this
topic.
I
wanted
to
argue
with
one
point
that
punit
just
mentioned,
which
is
that
the
strictness
should
be
a
preference
or
or
might
be,
might
logically
be
a
preference
of
the
zone.
K
So
I
think
this
goes
back
to
our
conversation
of
about
an
hour
ago.
In
my
view,
the
interesting
thing
to
signal
the
important
thing
to
signal
is
whether
the
whether
the
secure
transport
name
server
is
reliable,
is
essentially
backed
by
the
full
reliability
guarantee
of
the
name
server
operator.
If
the
name
server
operator
signals
explicitly
or
implicitly,
depending
on
our
design
that
the
secure
transport
is
reliable,
then
it
is
up
to
the
recursive
resolver
whether
to
treat
any
failure
as
an
attack.
C
J
J
G
Sure
so
I
think
to
the
reliable
the
point
about
the
service
being
reliable.
I
think
the
point
to
raise
there
is
a
scalability
which
is
a
concern
off
and
on
I've
heard
on
private
conversations,
meaning
udp
is,
of
course,
cheap
to
run.
If
some
operator
turns
a
pls,
can
we
assume
that
will
be
able
to
handle
the
same
query
load
over
the
encrypted.
C
Opportunity
by
probing
as
a
sort
of
a
sort
of
a
narrow
scope
thing
is
a
is
a
place
to
start
and
this
the
strong
signaling.
I
think
people
are
still
debating
the
per
zone
per
server
kind
of
discussion
and
there's
good.
C
You
know
arguments
for
that,
and
so
maybe
that
this
is
where
the
the
first
interim
goes
is
sort
of
working
out
these
scenarios,
though,
even
before
that
we
should
you
know
we
can
sit
down
with
the
authors
at
the
chairs
and
sort
of
rework
the
requirements
to
sort
of
focus
on
a
couple
of
these
things.
C
And
yes,
so
I
think,
as
we
sort
of
look
at
some
of
this,
we
realize
these
requirements
are.
You
know,
have
issues
and
I
think
paul's
made
comment
earlier,
like
you
know,
when
he
told
me
to
stop
trying
to
shoehorn
my
thoughts
into
the
requirements
it.
It
makes
perfect
sense
right
and
that's,
I
think,
what
we're
going
to
have
to
start
start
thinking
about
so
because
you're
right
requirement,
nine,
just
you
know
it's
just
sort
of
it-
makes
things
sort
of
messy.
C
So
I
I've
decided
to
not
try
to
shoehorn
my
thoughts
into
those
requirements.
That's
probably
a
good
way
to
go.
C
B
I've
got
some
drafts
that
I've
been
putting
on
the
list
already.
I
am
happy
to
keep
doing
that.
I'm
happy
to
slice
and
dice
them
in
ways
that
the
working
group
might
want
I'm
happy
if
this
is
considered
super
early
and
not
like
oh
yeah.
Let's
adopt
this
as
a
working
group
draft.
I
you
know,
I
I
think
that
there's
at
least
five
different
dimensions
that
we've
talked
about
in
the
last
couple
weeks
so
saying.
Let's
make
a
working
group
draft
seem
sort
of
daft,
but
I'm
totally
happy
to
do
it.
B
I'm
happy
if
somebody
wants
to
do
a
completely
different,
take
on
opportunistic
and
we
can
see
if
we
can
match
them
together
or
if
theirs
is,
you
know
easily
better?
I
I'm
I'm
not
wedded
to
being
a
document
author,
I'm
wedded
to
the
fact
that
I
have
the
for
myself
just
as
a
person.
B
The
use
case
of
I
would
like
to
see
more
encryption
happen
there.
So
I'm
I'm
happy
to
be
active
on
it.
I'm
happy
for
people
to
throw
stuff
at
me.
You
know
suggestions
and
I'm
happy
to
turn
through
drafts
fairly
quickly.
But
having
said
that,
I
would
like
to
see
the
work
that's
being
done,
especially
that
that
tony
finch
started
of
looking
at
some
of
the
signaling
to
keep
going,
not
waiting
for,
let's
see
how
it
comes
out
with
the
unsignaled
opportunistic.
B
I
just
I
I'm
95
sure
that
what
will
come
out
is
something
where
it
will
be
a
faster
turnaround
and
you'll
get
better
information
from
you
know
one
one
of
the
things
one
of
the
half
dozen
things
that
people
have
talked
about
today,
so
I
I
don't
want
it
to
be.
I
don't
want
the
working
group
to
focus
on
opportunistic
with
you
know,
port
probing,
even
though
that'll
be
something
that
I'm
happy
to
work
on.
A
So
paul
before
you
drop
off,
let
me
kind
of
tell
you
what
I'm
I'm.
What
I'm
thinking
here
is
is
that
we,
if
we
do
if
we
do
two
interim
meetings
between
now
and
our
virtual
prague
meeting,
one,
could
be
focused
on
the
opportunistic
with
with
probing
and
the
other.
One
could
be
focused
on
on
whoever
wants
to
lead
a
discussion
on
on
on
strict
signaling,
and
in
that
way
we
can.
B
Do
I
you
know,
am
I
doing
tls
and
what
is
what
is
a
a
public
key
that
you
might
look
for,
or
you
know
would
expect,
and
I
consider
those
to
be
two
separate
aspects
I
think
a
tip,
for
example,
just
using
the
tlsa
record
as
an
example,
a
tlsa
record
that
I
can't
use
because
I
am
not
a
validating
resolver-
is
still
a
signal
for
me.
That's
a
lot
faster
than
port
probing.
B
C
No,
I
I
agree,
and,
and
do
we
have,
I
would
be
good
to
see
if
we
had
some
folks
who
wanted
to
lead
some
of
the
scenario
type
things
I
know.
Alexander
talked
about
sketching
stuff
out
on
paper,
though
I
figure
most
people
just
want
to
go,
beat
on
some
code
and
see
how
it
sort
of
plays
out.
I
figure
we
can
go
in
either
direction
and
maybe
that's
an
option
before
prague
as
well
as
we
do
some
sort
of
mini
hackathon.
F
C
I
know
I'm
about
to
go
through
and
read
the
chat
more
carefully
and
mr
york.
I
know
I'll
probably
end
up
going
back
through
the
minutes
as
well
and
listening
to
this
again
to
sort
of
catch
a
lot
of
this
stuff,
because
there's
a
lot
of
things
that
sort
of
went
by
me,
because
I
was
doing
a
couple
things.
So
thank
you
for
doing
that.
Sarah.
D
I
want
to
make
a
comment
on
a
different
topic
just
to
see
what
folks
think
of
it.
So
thinking
about
the
the
threat
model.
Here,
I
noticed
in
the
requirement
document
that
the
two
motivations
were
around
protecting
the
potential
exposure
of
user
data,
and
I
think
the
other
one
was
interference
with
the
responses.
D
I
think
there's
a
third
consideration
which
could
be
added.
I
don't
think
it
changes
the
requirements
or
the
solution
space,
but
it
might
also
be
worth
worth
mentioning
that,
if
you're
thinking
about
zone
owners
who
are
interested
in
privacy
and
who
already
are
actively
trying
to
defeat
enumeration
of
their
zone
are
likely
to
deploy
zot,
they
might
also
well
have
an
interest
in
encrypting
as
many
queries
as
they
can
to
their
authoritative
to
prevent
passive
monitoring
of
those
queries
in
exposing
their
own
contents.
D
So
perhaps,
if
that
can
just
be
acknowledged
in
that
requirements
document,
I
think
it'll
be
helpful.
C
No-
and
there
are
there's
a
lot
of
great
comments
in
the
chat
folks,
like
you
know,
ray
and
daniel
and
folks
have
commented
here,
but
also
have
been
quiet-
have
made
some
good
some
good
remarks
there.
So
some
of
it's
I'm
gonna
we're
gonna
have
to
sort
of
sift
through.
C
And
so
that's
that's
what
I
have
to
say.
I've
got
to
sort
of
rethink
this,
but
this
was
good.
The
the
conversation,
the
mailing
list
in
the
past
couple
weeks
about
the
the
opportunistic
bit
and
and
I'm
gonna
try
it
we'll
try
to
track
down
tony
and
see
about
his
draft
and
see
where
he
wants
to
go
with
that,
because
I
thought
there
was
some
like
paul
said:
there's
there's
things
there
and
I'm
just
sorry.
C
He
he
couldn't
make
it
today,
so
we'll
find
him
brian,
any
other
final
words,
because
I
think
actually
we're
kind
of
getting
close
to
the
top
of
the
hour.
A
Yeah
we're
getting
close
to
stop
the
hour
and
I
would
say
that
what
I
would
like
to
to
do
is,
as
tim
said,
get
get
some
people
to
volunteer
to
to
kind
of
do
some
of
these
scenario.
Developments
with
with
the
with
the
aim
at
having
some
interim
meeting
between
now
and
our
virtual
prague
meeting,
which
I
believe
is
supposed
to
start
like
march
6th.
So
you
know
clearly
we're
gonna
have
to
avoid
the
the
holidays
in
some
way,
but
I
think
we
can
probably
get
it.
A
C
Yeah
and
as
always,
throw
stuff
at
the
mailing
list,
those
you
know
yell
at
us,
we'll
try
to
sit
here
and
see
if
we
can
sort
of
make
some
headway
on
this,
but
this
has
been
really
good.
It's
kind
of
really
done
a
good
job
to
reset
my
thoughts
here.