►
From YouTube: IETF112-DPRIVE-20211111-1200
Description
DPRIVE meeting session at IETF112
2021/11/11 1200
https://datatracker.ietf.org/meeting/112/proceedings/
A
Greetings
everyone.
This
is
the
the
deprived
working
group
session
for
ietf
112.,
I
believe
we're
sort
of
in
madrid.
If
I
remember
the
schedule
correctly,
we're
gonna
go
ahead
and
get
started.
My
name
is
brian
haberman
and
I'm
joined
by
my
illustrious
co-chair
tim
wisinski
and
I
believe,
sitting
in.
A
Quick
quick
couple
of
notes
here:
jabber
room,
is
pretty
much
where
it's
always
been
at
the
private
ietf.jabra.org
and
we'll
be
keeping
minutes
in
the
in
the
in
the
through
the
tools
link.
That's
provided
on
the
page.
Tim
is
going
to
try
and
keep
notes
as
much
as
possible,
but
we
do
have
the
ability
for
anybody
else
to
jump
in
and
help
if
they
feel
the
the
interest
to
to
make
sure
that
we're
we're
getting
all
the
correct
action
items
and
important
points
down
for
posterity.
A
A
They
include
a
number
of
of
important
pieces
here,
including
the
standards
process,
harassment
procedures,
anti-harassment
procedures,
copyright
processes,
code
of
conduct,
etc,
etc.
So,
if
you
have
not
read
this
recently,
please
go
do
so
and
we
just
promised
not
to
have
a
pop
quiz
at
the
end.
For
these.
A
Other
piece
of
administration
we've
been
trying
to
you
know
push
code
of
conduct
guidelines
that
have
been
documented
in
rfc
7154.
You
know
a
quick
set
of
of
introductory
meta
points
for
this.
I
don't
think
there's
anything
here.
That
is,
you
know
of
surprise
we're
trying
to
be
as
inclusive
as
possible
and
basing
everything
based
on
our
on
our
best
engineering
judgment
and
and
as
tim
indicated,
you
know,
these
slides
came
from
from
west
hartaker.
A
So
our
agenda,
you
know
pretty
much
a
standard
flow
for
the
deprived
working
group.
Anybody
who
has
updates
they
want
to
make
to
the
agenda
we'll
solicit
those
in
a
second
we'll
go
through
some
updates
of
existing
current
work
and
then
we'll
talk
about
current
working
group
business
and
then
we'll
cover
any
new
working
group
business
that
that's
been
brought
to
the
to
deprive.
A
A
A
That
would
be
an
iesg
action,
but
we
would
need
to
you
know
first
discuss
in
the
working
group
whether
or
not
we
want
to
move
dns
over
dtls
to
historic,
and
I
don't
think
we're
going
to
try
and
discuss
that
here.
We'll
probably
have
this
as
a
as
a
point
of
discussion
on
the
mailing
list,
or
if
we
have
some
time
left
at
the
at
the
end
of
the
session,
we
could
we
could
revisit
this
point
if
people
want
to
have
a
an
in-person
discussion.
A
And
then
for
the
agenda,
we'll
we'll
have
the
the
authors
of
the
unoff,
the
authoritative,
give
their
presentation
on
on
what
they've
been
doing.
They
do
not
have
slides
and
so
they'll
just
be
talking
to
points
that
they
want
to
make
and
then
going
forward.
We're
going
to
have
a
presentation
from
joey
salazar
on
on
some
a
new
draft
that
they
had.
A
A
B
A
good
morning,
at
least
for
those
of
you
from
the
west
coast,
so
we
have
no
slides
and
we
were
allocated
30
minutes,
but
we're
going
to
use
way
less
than
that
which
is
okay,
because
we
would
be.
When
I
say
we
I
mean
peter,
and
I
would
be
happy
to
have
more
time
to
talk
about
the
next
presentation
from
joey
and
dkg.
B
Basically,
the
status
of
the
unoff
to
authoritative
document
is
we
posted
the
o4
draft
about
six
weeks
ago
we
announced
it
on
the
mailing
list.
We
asked
for
comments,
there's
still
a
few
open
issues,
especially
with
respect
to
how
this
might
interact
with
a
fully
authenticated
system,
and
we
got
absolutely
no
replies.
So
I'm
not
sure
what
that
means
for
now,
but
it
either
could
mean
the
documents
perfectly
stable,
which
seems
unlikely
or
that
the
working
group
is
thinking
about
use
cases
again,
which
would
actually
be
good.
B
I'd
like
to
see
more
thought
put
into
use
cases.
If
the
working
group
is
happy
with
the
current
draft,
with
the
with
unoff
to
authoritative,
o4
and
the
fact
that
it
uses
svcb
as
the
protocol
for
tracking-
and
we
have
just
a
vague
mention
of
probing
in
there-
maybe
we
want
more
or
maybe
the
working
group
wants
more.
If
that's
the
case,
then
peter-
and
I
have
talked
about
starting
some
interop
testing
the
status
currently
is
that
it
would
be
experimental.
B
So,
basically,
we're
waiting
on
working
group
input
and
we've
tried
so
far,
and
I
think
we've
been
successful
at
keep
making
changes
in
all
in
every
draft
forum.
Based
on
working
group
input,
you
know
we
started
off
with
doing
just
probing
and
the
working
group
said
no.
We
can't
be
doing
probing
because
that
won't
work
in
parallel
with
a
fully
authenticated
use
case.
So
we
included
a
fully
authenticated
use
case.
We
took
that
out
when
there
was
a
draft
that
started
to
describe
the
fully
authenticated
use
case.
B
Please
make
these
changes
in
this
draft
or
we're
looking
for
a
new
way
of
doing
things
and
such
as
the
the
one
that
we're
about
to
hear,
which
is
just
fine
peter,
and
I
both
our
desire
here
is
not
to
have
finished
an
rfc
but
to
get
more
encryption
on
the
internet
and
the
best
way
to
do
that
is
to
have
a
document
that
there
are
a
lot
of
vendors
and
developers
behind.
That's
our
document
great.
B
If
it's
a
different
document
great,
I
guess
I'm
pushing
for
a
little
bit
more
input,
regardless
of
what
it
is
and
that's
that's
all
we
have
until
we
hear
more
on
the
mailing
list.
There
isn't
much
we
can
be
doing
so
back
to
you,
brian
and
tim,
or
if
people
have
questions
on
this,
that's
fine,
but
again
our
preference,
strong
preference
is
always
to
be
getting
discussion
on
the
mailing
list,
especially
on
a
document
like
this,
where
there
was
strong
interest
in
the
use
case,
but
also
strong
pushback
against
the
use
case.
B
C
Thank
you.
I
just
wanted
to
say
that
first,
apologies,
a
personal
level,
because
I
have
been
meaning
to
get
some
input
for
this
draft
in
the
mailing
list.
I
will
get
to
it,
I
promise
so
in
the
meantime,
I
just
wanted
to
say
that
at
least
from
my
perspective-
and
I
believe
that
dkg
shares
it-
and
he
will
probably
talk
about
this
more
when
he
presents-
is
that
I
don't
think
that
is.
C
This
should
be
a
question
of
either
or
I
think
that
the
use
case,
the
use
case
that
you
guys
are
working
currently
on
this
draft.
The
unauthorized
encryption
is,
is
good
and
like
the
development
of
this
document
shouldn't-
or
at
least
from
my
perspective,
I
wouldn't
like
it
to
be
like
trumped
by
the
development
of
other
use
cases.
I
also
think
that
more
encryption
internet
is
is
the
way
to
go.
C
So,
like
my
perspective
from
for
about
the
draft
that
dkg
is
about
to
present
is
that
we
should
simply
talk
about
the
different
use
case
scenarios
and
and
work
on
them,
and
I
think
that
as
we
move
along
or
as
we
go
down
that
route,
we
will
simply
get
more
clarity
in
either
all
of
the
use
cases,
or
we
will
focus
on
one
use
case
at
a
time
and
then
yeah,
that's
just
my
perspective
and
I
just
wanted
to
to
make
it
public.
Thank
you.
B
Great,
thank
you
and-
and
I
do
think
that
us
rekindling
the
use
case
discussion
on
the
mailing
list
without
it
being
about
a
particular
draft,
would
be
good,
and
I
don't
want
to
foreshadow
the
next
document,
but
just
to
be
clear,
peter,
and
I
feel
like
that.
Their
use
case
is
just
fine,
you
know
so
it
it's
not
a
one
use
case
is
better
than
the
other.
It's
just
our
draft
has
evolved
in
a
certain
way.
B
Their
draft
is
starting
from
a
certain
perspective,
and
but
again
we
think
that
we've
stated
the
use
case
for
the
current
working
group
draft
as
clearly
as
we
can
we're
really
happy
that
they
stated
their
use
case
very
clearly
from
the
beginning.
It's
not
just
hey.
We
have
an
idea
of
how
to
do
something,
so
I
would
love
to
see
more
on
that.
Maybe
the
working
group
does
want
us
to
both
go
at
the
same
time.
We're
happy
to
do
that,
but
we
want.
We
need
to
hear
from
the
working
group.
D
Obviously,
I'm
presenting
later
in
the
session,
I
think
the
only
places
there
might
be
some
concern
I
didn't
apply
yet
on
the
mail
list
was
because
I've
only
just
done.
The
work
on
the
authoritative,
sorry
authenticated
to
authoritative
proposal,
and
it
would
be
premature
to
comment
until
actually,
I
have
the
the
drafts
ready
to
to
compare
and
that's
really
only
just
been
done,
plus
getting
feedback
from
the
working
group
on.
B
And
again,
yeah.
Thank
you.
Thank
you,
brian.
But
again
the
working
group
has
to
decide
whether
a
use
case
is
that
the
unauthenticated
use
case
needs
to
be
in
aligned
with
the
fully
authenticated
use
case
we
had.
We
currently
are
doing
that
because
the
working
group
asked
us
to
do
that
about
nine
months
ago.
So
the
current
draft
has
has
that
alignment
as
part
of
its
use
case,
but
then
the
interest
in
the
fully
authenticated
fell
off,
at
least
from
the
the
document
authors.
B
A
E
E
Give
me
please
give
me
more
sure,
I'm
about
to
I
wouldn't
say
interesting
news
from
the
document.
Authors,
I
would
say,
interest
is
remain
constant.
I
would
say
my
estimation
of
like
how
likely
the
working
group
to
be
interested
in
doing
this
has
fallen
off,
and
so
my
interest
in
community
fight
about
it
has
also
fallen
off
so
like
based
on
this
discussion,
with
based
on
based
on
how
ben's
draft
is
received.
B
Yeah
and
and
very
fair
point
is
that
that
you
know
we
had
some
good
input
on
your
draft
and
then
it
fell
off.
And
yes,
there
is
the
question
of
and
peter,
and
I
are
feeling
this
as
well
of
how
much
are
we
supposed
to
be
selling?
Is
it
worth
worthwhile
doing
the
selling,
and
I
totally
hear
you
on
the
not
wanting
to
spend
time
on
doing
selling
so
great.
A
All
right,
so
I
guess
the
question.
I
have
yeah.
Sorry,
sorry
go
ahead,
brian,
oh
sure,
sorry,
paul
yeah!
I
don't
see
anybody
else
in
the
queue,
so
I
so
I
think,
there's
a
couple
of
different
ways
that
I
could
see
going
here
and
I'd
like
to
get
your
opinion
on
them.
You
know
one
is
is
to
do
a
working
group
last
call
to
make
sure
that
people
are
at
least
happy
with
what's
been
specified
in
the
document
today,
but
I
think
at
that
point
it
would
be.
A
A
We
would
just
keep
it
in
a
steady
state
and
mark
it.
Some
way
that
it's
it's
the
stable
version
for
experimentation,
the
the
the
other
option
would
be
to
then
the
other
option
would
be
to
to
hold
off
on
doing
that
kind
of
working
group.
Last
call
and
do
more
of
that
use
case
discussion
that
you've
talked
about.
B
B
A
Oh
no,
no
right,
I'm
just
saying
with
what
you
mentioned
today
is
where
I
was
going
right.
You
know
my
concern
there
is
is
that
you
know
we
seem
to
have
intermittent
interest
from
other
working
group
participants
to
do
that,
and
so
I'm
just
curious.
As
do
you
have
a
preference
for
one
of
those
two
approaches
as
as
an
immediate.
B
Next
step
I'll
speak
for
myself
and
maybe
peter
will
get
in
the
queue
I
prefer,
the
second
one.
I
prefer
that
we
don't
say
that
this
is
finished
for
two
reasons:
one
is
it
only
vaguely
hints
at
the
use
of
ds
glue
and
we
haven't
gone
far
with
ds,
glue
and
such
like
that,
or
some
ds
glue
equivalent,
maybe
some
of
the
stuff
that
brian's
going
to
be
presenting.
B
So
I
don't
feel
that
we
are
actually
complete.
I
don't
think
that
we
are
even
complete
with
the
stated
use
case,
so
I
would
prefer
more
use
case
discussion
that
peter
and
I
can
track
and
stick
into
the
document
and
again
the
document's
sort
of
waving
around,
depending
as
the
working
group
goes,
but
we're
okay.
With
doing
that,
I
would
I
would
prefer
that
than
to
have
anyone,
see
a
stable
document
and
feel
that
they
were
supposed
to
be
implementing
from
it.
B
F
Hi
thanks
thanks
thanks
brian
thanks
paul.
Would
it
help
us-
and
maybe
we
can
get
our
80
to
weigh
in
if
we
had
reviews
from
some
of
the
other
directorates
on
the
document
like
now,
while
we
sort
of
go
through
the
experimentation
process
just
to
see
if
we're
covering
all
our
security
bases
or
things
of
that
nature
right,
it's
just
more
of
an
open-ended
question
right.
I
don't
know.
B
My
personal
feeling
is
my
personal
feeling
is
no,
because
what
you're
asking
is
is
the
is
what
is
specified
there
correct
and
good
enough
and,
like
I
said,
it's
got
holes
because
the
working
group
has
had
holes
so
for
the
same
reason
I
don't
want
to
have
implementers
spend
time
on
something
that
might
change.
I
don't
want
the
directorate
to
feel
like
that.
This
is
something
that
they
should
be
evaluating.
If
we
know
it
has
holes
because
the
holes
as
they
fill
in
will
certainly
add
security
properties,
I
mean
I
don't
want.
E
I
think,
like
also,
I
think
we
understand
like
pretty
well
what
it
does
and
what
security
properties
are,
and
I
think,
like
you
know,
like
there's
a.
I
think
you
know
that
that
that's
much
clearer
than
any
of
the
financial
authenticator
proposals.
Obviously,
but
I
think,
like
you
know
like
the
like,
the
question
is:
what
is
the
work
we
want
to
move
forward
with?
E
As
like
the
place
where
it
wants
to
like
focus
its
effort
for
the
next
year
or
so
in
terms
of
like
in
terms
of
like
in
terms
of
like
you
know,
driving
both
specification
and
rollout,
and
I
think
until
we
decide
that
like
trying
to
get
like
any
trying
to
like
run
the
ietf
machinery
of,
like
you,
know,
publishing
specification
we'll
have
the
same
sort
of
like
well.
What
well
you
know
we'll
we
will
be
positioned
in
in
five
years
of
being
like
do.
We
would
deprecate
the
port.
E
You
know
that
would
detail
us
now
we
deprecate
the
port
that
we,
like
all
things
like
like
a
new
thing
or
or
or
the
thing.
So
I
think
that
that's
that's
like,
like
the
other
way
to
go.
It's
like
we
gotta
like
get
to
a
point
of
consensus,
and
I
don't
know
like
you
know,
or
I
think
the
clear
failure
by
the
way
would
be
also
an
alternative.
A
All
right
thanks
eric,
so
so
what
what
tim
and
I
are
going
to
do
is
we're
going
to
go
off
and
probably
huddle
with
the
with
with
eric
to
discuss
ways
to
try
and
get
this
discussion
facilitated
in
a
way
that
gets
us
to
a
point
where
we
can
actually
determine
whether
or
not
there's
consensus
on
on
any
of
this
stuff,
because
you
know
both
paul
and
and
eric
are
right.
You
know,
we've
been
we've
been
around
on
these.
G
Thanks,
I
so
are
you
you're
running
the
slides
brian?
Yes,
great
thanks
so
joey
and
I
wrote
this
draft.
I
would
run
video,
but
last
time
I
tried
that
my
ancient
laptop
started
crapping
out
on
the
audio,
so
I'll
stick
with
audio
for
now.
So
I'm
going
to
present
this.
This
is
joint
work
with
with
joey,
and
this
is
an
unusual
sorry
that
we
haven't
posted
this
directly
to
the
data
tracker.
G
G
G
G
How
could
you
probe
as
you're,
doing
authoritative,
queries
and
end
up
contri
encrypting,
the
bulk
of
your
traffic?
Even
if
it
doesn't
mean
100
protection
and
it
doesn't
mean
protection
against
active
attacks?
How
can
we
reduce
the
visibility
to
a
passive
monitor,
and
we
want
this,
this
proposal
to
really
be
out
of
the
way
and
not
interfere
with
or
or
provide
sort
of,
conflicting
guidance
with
a
more
robust
approach,
along
the
lines
of
like
fully
authenticated,
potentially
with
hard
fail
and
what's
interesting?
G
G
Okay,
so
if
we
start
a
new
probing,
what
are
the
things
that
could
go
wrong?
The
draft
tries
to
figure
out
what
we
can
do
to
minimize
certain
bad
things
right.
So
we
don't
want
to
see.
Dns
query
suddenly
become
much
slower.
We
don't
want
to
see
the
recursive
resolver
consume.
You
know
a
thousand
times
as
many
resources
or
the
authoritatives.
We
don't
want
to
see
them
flooded
with
annoying
overload.
G
We
don't.
We
certainly
don't
want
to
penalize
resolvers,
authoritative,
servers
that
adopt
these
things,
and
likewise
we
don't
want
to
we.
Don't
we
wouldn't
want
a
recurser.
That's
doing
this
probing
to
degrade
its
service
to
to
in
other
cases,
and
we
certainly
don't.
We
also
want
to
minimize
the
amount
of
data
that
we
accidentally
leak.
G
G
G
G
G
G
We
looked
at
asking
the
authoritative
servers
to
opportunistically
offer
do
on
port
443,
but
if
we
did
that,
we
need
to
specify
what
the
path
part
of
the
url
would
be
and
we
didn't
want
to
like
make
up
what
a
standard
path
would
be
for
dough,
so
we
just
kind
of
left
it
at
dot
and
doq.
If
folks,
I
think
that
what
we
specified
in
the
rest
of
the
draft
will
actually
work
fine
if
we
throw
doh
in
there
as
well.
G
G
G
G
Sorry,
the
the
str,
whatever
the
stronger
proposal
ends
up
being.
I
I
want
to
note
a
similarity
here
that
this
has
to
the
happy
eyeballs
guidance.
So
this
is
not
novel
for
the
itf.
Isn't
it's
not
like
recommending
implementation
guidance
without
specific
protocol
changes
is
a
totally
novel
thing.
The
ietf
has
recommended
some
happy
eyeballs
work
for
ipv4
and
ipv6.
G
Obviously
this
is
not
exactly
the
same
as
happy
eyeballs
for
ipv4
and
ipv6,
but
it's
a
similar
type
of
guidance.
It
says:
hey,
you
know,
try
these
different
channels
at
once.
If
you
get
one
that
works,
here's
how
you
should
prioritize
the
one
that's
working,
so
we
map
out
like
a
specific
set
of
internal
state.
It's
relatively
minimal.
We
don't
think
it's
a
big
burden
to
implement
and
outlines
how
to
update
that
state.
Depending
on
what
you
encounter
on
the
network
next
slide,
please.
G
G
G
Maybe
you
want
to
have
distinct
parameters
depending
on
the
zone,
the
ip
address,
or
the
name
server
that
you're
looking
up,
you
could
do
those
things.
I
think
the
simplest
approach
and
the
goal
here
is
to
provide
a
simple
recommendation
if
you
just
have
this
as
a
global
parameters
for
their
cursive
resolvers
right.
So
we
want
to
know
how
long
do
you
remember
that
you
had
success
at
making
an
encrypted
connection
that
we
call
that
persistence?
G
We
want
to
know
how
long
you
avoid
retrying
encrypted
transports
once
you've
found
that
none
of
them
work,
and
we
call
that
damping
and
then
we
want
to
know
you
know
if
you're
trying
encrypted
transports,
because
you
knew
that
they
were
good
and
then
they
start
to
fail.
We
want
to
know
how
rapidly
you
fall
back
to
your
text
transport,
and
so
we
call
that
timeout.
G
So
I'm
not
getting
into
the
exact
steps.
The
draft
actually
outlines
fairly
detailed
like
what
do
you
do
when
a
connection
fails?
What
do
you
do
when
you
run
out
of
resources?
How
you
know,
how
should
you
try
them
in
a
happy
eyeball
sense?
You
open
the
connections
all
at
once.
You
see
what
one
comes
through.
G
The
clear
text
will
probably
give
you
a
response
first,
but
leave
the
you
know,
leave
the
attempts
at
encrypted
transport
open
to
make
sure
that
you
have
the
connection
it
gives
you
guidance
on
sort
of
all
of
those
steps.
I'm
not
going
to
go
into
detail
on
what
that
guidance
is.
I
hope
people
read
the
draft
and
correct
the
things
that
joey
and
I
have
missed
or
places
where
we
might
have
gotten
it
wrong.
G
You
know
the
implementers
people
who
who
have
existing
recursive
resolvers
could
look
at
that
and
tell
me
probably
no,
no
you
you
forgot
this
particular
failure.
State
we'd
love
to
get
that
kind
of
feedback,
but
one
of
the
things
that
outlining
this
does
is
it
sort
of
gives
us
a
clear
sense
of.
If
you
wanted
to
signal
which
this
draft
does
not
do.
G
G
It's
just
as
easy
for
me
to
make
one
query
to
the
authoritative
server
on
port
853
or
two
one
on
tcp
and
one
on
udp
and
get
an
answer.
Is
this
thing
available?
What
we
really
need
from
the
signal
is
an
indicator
by
the
by
the
zone
operator.
That
says
we
do
expect
encrypted
transport
to
be
running,
and
we,
when
we
expect
you
to
be
able
to
authenticate
to
it.
G
We
here's
how
we
expect
you
to
authenticate
okay
and
here's
the
thing
that
you
need
to
authenticate
now
we
might
decide
that
you
don't
need
to
explicitly
mark
this
in
the
signal
because
you
might
decide.
For
example,
it's
only
going
to
work
with
x
509,
it's
only
going
to
work
with
the
ns
name
rather
than
zone
the
zone
name
or
something
like
that,
this,
whatever
we
define
for
how
the
signal
should
work
needs
to
answer
these
questions,
but
this
is
information
that
we
need.
G
G
Let
us
know
now
note
that
that's
distinct
from
hard
fail.
You
might
want
to
initially
say:
don't
hard
fail
as
an
authoritative
and
just
collect
reports
from
people
that
says
you
know
hey
I
tried
encrypted.
I
tried
to
do
an
encrypted
connection.
That
was
authenticated
and
I
didn't
get
it
so
it
looks
a
lot
like
tlsrpt.
Then
I
see
you
in
the
queue
I'm
happy
to
hear
your
feedback.
G
So
if
we
think
that
a
signal
could
have
the
types
of
details
that
we
just
outlined
in
those
two
past
slides,
the
next
question
for
unilateral
probing
is:
how
is
this
going
to
interact
the?
How
is
this
going
to
interact
with
the
strong
with
the
strong
crypto,
so
the
signal
that
we
get
for
strong
crypto
is
likely
to
be
bound
either
to
the
domain
that's
being
queried
or
to
or
to
the
name
server
name,
but
the
probing
information
that
we
have
is
bound
to
ip
addresses.
G
G
So
I'm
raising
these
questions,
because
I
don't
have
any
answers
for
them,
but
I
think
thinking
about
it
with
this
unilateral
way
encourages
us
to
sort
of
work
through
those
problems
I
see
brian
and
eric
in
the
queue
I'm
happy
to
take
you
questions
I
realize
there's
been
some
stuff
going
on
in
the
chat
that
I
have
not
had
a
chance
to
read.
While
presenting
brian,
you
want
to
talk.
D
G
G
A
G
So
if
we
get
a
signal
again
so
so
one
thing
that
we
noted,
as
we
were
sort
of
sketching
out,
what
this
unilateral
probing
would
look
like
was
that
the
probe
doesn't
need
to
send
sni,
because
it's
not
gonna
care.
What
the
authentication
looks
like
it's
going
to
do
a
connection
and
if
the
tls
handshake
or
the
quick
handshake
ends
up
working,
fine,
we're
good.
We
protect
it
against
passive
attackers
anyway,
but
a
signal
connection
might
send
sni
and
that
itself
might
be
a
privacy
leak.
G
So
there's
some
interesting
interactions
there
and
then
we
have
this
final
sort
of
thought.
Experiment
is:
is
there
some
situation
where
a
signal
connection
would
succeed
where
a
probe
fails?
The
only
thing
I
could
think
of
when
I
was
trying
to
like
work
through
the
problem.
Space
was
a
situation
where
the
signal
connection
does
send
an
sni
and
somehow
that
allows
the
server
to
offer
a
connection.
G
The
the
authenticated
server,
the
sorry,
authoritative
server,
to
offer
a
connection
that
it
wouldn't
do
if
no
s
I
had
come
in,
which
is
why
we
gave
the
guidance
that
authoritative
servers
should
ignore
sni
when
they're
offering
these
things.
That
is,
if
sni
comes
in,
don't
if
you
get
a
probe
with
no
s,
I
don't
abort
just
because
you
can't
figure
out
what
the
name
is
just
serve
any
old
certificate
or
identification,
but
maybe
there's
some
other
situation
where
signal
connection
could
succeed
where
a
probe
is
failing
next
slide.
G
G
But
you
know
if
folks,
who
have
been
thinking
hard
about
these
other
drafts,
want
to
weigh
in
on
how
to
improve
this
unilateral
step.
That
would
also
be
great
next
slide.
I
think
that's
it
right.
So
there's
the
get
lab
link.
It's
in
my
personal
gitlab
account.
We
will
publish
it
to
the
data
tracker
shortly.
I
think
we
have
provoked
a
queue
of
seven.
So,
let's
get
to
it,
I
recognize
that
ben
is
at
the
tail
of
the
queue,
even
though
he
was
the
first
one
in
the
queue
earlier.
G
D
D
But
the
other
comment
I
have-
and
this
comment
is
actually
applicable
to
both
the
the
probing
and
to
the
unoff
as
well
as
any
any
other
related
proposals
is
at
least
on
my
proposals.
It's
what's
being
proposed
is
the
how,
but
what
is
left
unanswered
is
the
when
right
now
it
seems
to
be
the
case
that
especially
both
the
probing
and
the
unoff
case,
it
seems
to
be
an
all
or
nothing,
and
I
don't
think
authority.
D
Server
operators
are
going
to
be
happy
with
that
or
are
going
to
be
likely
to
enable
encrypted
connections
if
all
the
traffic
is
going
to
go
over
that
all
of
a
sudden,
I
would
be
interested
in
soliciting
suggestions
from
the
working
group
on
ways
that
a
client
could
signal
to
a
resolver
that
it
wants
privacy
on
the
upstream
queries
from
the
resolver
to
the
authoritative
so
that
it
can
reduce
to
the
absolute
minimum.
The
traffic
that
is
authentic
is
encrypted
so
as
to
not
overly
consume
resources,
I.e.
G
No,
I
think
this,
I
think,
that's
a
that's
a
really
interesting
point.
I
think
you
and
I
might
disagree
about
what
the
goals
are
here.
Ultimately,
my
goal
here
is
to
get
as
many
of
the
precursor
to
authoritative
traffic,
that's
flowing
across
the
network
to
be
encrypted,
so
I
am
not
contemplating
at
least
this
draft
explicitly
does
not
contemplate
the
idea
of
marking
specific
queries
as
sensitive
it
is.
It
is
strictly
about
getting
as
many
queries
to
be
encrypted
as
possible,
and
I
want
to.
G
It
says,
stop
answering
you
know
if
you
as
an
authoritative
server,
can't
afford
to
answer
encrypted
queries,
then
stop
answering
on
port
853.
Just
send
back
port
closed,
that's
the
cheapest
thing
you
can
possibly
do,
and
so
so,
while
I
agree
with
you
that
we
want
the
the
clients
to
do
something
explicit
so
that
the
server
knows
they
want
encrypted
connections,
I'm
pretty
sure
that
just
making
the
connection
seems
sufficient
for
that.
G
Now,
if
you
think,
if
you
think
that
we
can't
have
my
the
motivation
for
this
draft
is
a
world
where
all
recursive
to
authoritative
traffic
is
encrypted.
If
you
think
that
is
not
possible,
if
you
think
that
authoritative
servers
will
rebel
and
refuse
to
offer
it,
then
we
have
a
whole
different
set
of
thinking
to
do.
I
think,
as
a
working
group,
but
the
goal
here,
in
my
opinion,
is
to
have
all
of
the
recursive
to
authoritative
traffic
encrypted.
D
Okay,
so
I
realized
you
know:
itf
were
participating
as
individuals,
but
my
day,
job
is
with
godaddy
and
we
run
authoritatives
for
the
bulk
of
the
long
tail
of
domains,
and
I
can
say
for
absolute
certain.
There
is
no
way
we
could
accommodate
with
our
current
infrastructure
or
even
our
proposed
expansion
of
infrastructure,
all
queries
coming
over
tls
connections
or
even
over
tcp
connections.
D
The
same
same
deal,
the
the
state
that's
required
and
the
the
overhead,
even
with
establishing
connections-
I
I'm
pretty
sure
we
will
do
experiments
for
sure,
but-
and
I
don't
think
the
signaling
would
be
between
the
recursive
and
the
authoritative.
I
think
the
signaling
would
be
from
the
client
to
the
recursive,
the
recursive
choosing,
whether
to
use
an
existing
open
connection
for
the
query
over
dot
or
doq
versus
sending
it
over
udp
or
tcp.
D
There
are
other
mechanisms
for
associating
domains
with
encrypted
or
not
using
the
name
server
names,
because
a
name
server
can
have
multiple
names
at
the
same
ip,
but
this
is
this
is
this
is
getting
a
long
way
down
the
discussion,
but
I
think
that
that
needs
to
to
start
the
conversation
needs
to
start
in
terms
of.
Is
there
a
way
to
do
this
and
how?
C
Okay,
sure,
is
this
better
perfect?
Thank
you
all
right,
thanks
yeah,
that
maybe
what
we
could
add
is
simply
in
the
authoritative
servers
recommendations,
part.
It
could
be
some
sort
of
sentence
explicitly
mentioning
what
you
say:
tkg,
that
if
an
authoritative
server
is
faced
with
resource
exhaustion
or
something
then
the
the
cheapest
way
to
signal
that
would
be
simply
by
closing
the
ports.
I
say
this
in
order
to
like
keep
consideration
to
what
brian
said,
and
also
with
the
understanding
that
that
should
not.
A
E
Presenting
this,
this
is
rather
more
rather
more
careful,
workout
than
perhaps
necessary.
So
so
thank
you.
You
know.
I
originally
wanted
to
talk
about
the
sort
of
like
the
the
issue
of
sni
and
like
labels
and
whatever
and
scoping
for
the
hscs
type
mechanism,
but
I
think,
like
brands,
comments,
I
think,
like
forced
us
to
step
back
right.
You
know
like
I
I
I
had
heard
what
you
just
you
used
to
research
that
dkg
that
you
hadn't
heard
anybody
say
like.
Oh,
we
just
want
to
donate
this
at
all.
E
I
don't
think
that
like
trying
to
like
say
like
which-
which,
like
I
don't
think
like,
if
like,
if
like
the
if
the
the
prize
at
the
end
of
this,
is
like
that
the
clients
get
to
label
like
one
percent
of
their
queries
as
sensitive
and
like
those
getting
encrypted
like
that.
Just
does
not
like
that.
That's
not
just
worth
the
squeeze
so
so
so
I
think,
like
you
know
now,
I
I
must
say
I'm
like
quite
surprised
to
hear
that
people
think
the
load
is
excessive.
E
Like
I
mean
compared
to
like
the
load
that,
like
you,
know
that,
like
a
modern
cdn
takes,
this
is
just
like
not
like
a
trivial
important
amount
of
data,
which
is
why
I,
like
all
these
people,
are
offering
free.
You
know,
while
these
people
are
offering
free
gis
like
those
services
but
but
like,
if
that,
if
the
people
I
think
about
anybody
want
to
do
so,
then
like
that's
the
place
to
start
not
not
just
sort
of
spend
like
endless
hours,
trying
to
find
like
a
new
way
to
like
do
something.
E
Nobody
wants
to
do.
So.
I
think
that
that
I
would
definitely
encourage,
like
the
working
group
placements
on
that
topic,
which
I
think
circles
back
to
this
point
I
was
making
earlier
about
my
draft
impulse
draft,
which
is
like
you
know
like
we
should
like.
I
think
we
have
like
a
broad
understanding
of
like
what
the
solution
space
looks
like
and
if
I
can,
and
we
ought
to
figure
out
what
pieces
loosen
space
people
like
are
actually
willing.
E
The
players
are
actually
willing
to
do
and
if
I
and
like
only
focus
on
this,
but
on
my
pieces
that
are
relevant,
so
I
guess
I
would
definitely
see
some
people
queuing
up,
which
is
great.
I
would
love
to
hear
like
people
who
operate,
authoritative,
servers,
you
know,
you
know
say
you
know
we
will.
We
would
not
be
willing
to
do
like
like
we
would
be
interested
in
something
which,
like
leads
us
to
like
universal
encryption
from
like
authoritative,
represent.
G
G
E
Yeah
running
authoritative,
I
I
just
selfishly
want
your
intellectual
effort
on
something
else:
it's
not
before
no
one's
gonna.
Do
this
the
I
do
wanna
say
one
more
thing
actually,
which
is
you
know,
brian
suggested
that,
like
you
know
that
servers
that,
like
the
the
clients
should
like
somehow
they
know
like
I
want
this
or
not.
You
know
like
cert
like
it.
E
We
don't
need
a
mechanism
for
servers
to
gradually
roll
out
support
for
this
under
the
in
the
design
you
pose
like
they
can
simply
stochastically
send
por
sprayport
closed
some
to
like
some
fraction
of
the
ip
addresses,
and
that
is
like
the
cheapest
way
for
this
to
be
done.
Trying
to
like
build
some
sort
of
gradual
internet.
Why
gradual
element
is
not
a
good
plan
like
just
like
just
like
you
know,
just
like
select
a
ipad
address
range
and
return.
Okay
versus
port
closed.
G
I
G
I
I
I
guess
we'll
have
a
few
other
conversations
before
we
get
to
fixing
that
like
do.
We
even
want
encryption
everywhere,
as
discussed
before
the
queue
on
the
sni
note.
I
believe
that
the
content
served
by
a
name
server
should
never
depend
on
the
sni,
but
indeed
sni
might
make
sense
in
some
authenticated
scenario.
I
Yep
and
finally,
several
people
said
this
today.
Several
people
said
this
in
the
past.
If
a
name
server
does
not
want
to
serve
some
encrypted
transports,
it
should
just
return.
Tcp
resets
when
I
proposed
this
earlier
brian
dixon
told
me
that
would
be
too
expensive
I,
but
I
don't
know
what
to
make
of
that.
G
J
J
G
Thanks
eric,
that's
a,
I
think,
that's
a
really
good
point
and
that
you
know
that's.
The
goal
of
this
proposal
is
to
try
to
flesh
out
what
we
think
would
would
achieve
the
results
that
you're
describing.
I
don't
know
how
often
the
remapping
that
you're
describing
happens.
It
probably
depends
on
the
particular
infrastructure
provider,
but
I
agree
with
you.
You
know.
Maybe
maybe
the
answer
is
we
want
to
fiddle
with
the
default.
Timeout
parameter,
that's
described
in
the
draft.
G
G
G
H
Quick
notes:
I
am
aware
of
real
offside
interest
in
100
encryption,
not
like
name
conditional.
I
I
know
auth
implementers,
who
believe
that
this
is
totally
deployable
and
wanted
to
play
it.
So
please,
please
make
it
possible.
I
don't
think
the
impedance
mismatch
you
mentioned
is
a
real
problem.
I
just
kind
of
think
that
you'll
you'll
check,
if
you
can
do
the,
if
you
have
the
authentication
support
and
if
that
works,
you
won't
even
get
to
the
stage
of
checking.
H
G
H
H
D
Yeah,
I
just
want
to
make
clear
that
we
definitely
want
to
provide
the
ability
to
do
encrypted
transport,
so
my
suggestion
that
it
not
be
100
is
not
that
we
don't
want
it
to
be
a
hundred
percent.
We
don't,
I
don't
think
we'll,
be,
have
the
facilities
to
do
that
and
the
problem
with
all
or
nothing
if
that
ends
up
consuming
resources,
that
it
ends
up
being
nothing.
D
I
think
that's
not
to
the
benefit
of
of
the
the
efforts
here
or
to
the
group
if,
if
it's
a
resource
consumption
thing
not
being
greedy,
not
having
resolvers
that
are
greedy
and
consuming
all
the
resources
is
an
important
part
to
make
the
analogy
between
udp
and
tcp.
Udp
allows
you
to
be
greedy.
Tcp
has
back
pressure
through.
D
But
it
was
not
the
case
that
resolver
to
off
all
encrypted
as
being
a
request
requirement
for
what
dpriv
is
doing
and
that
to
me
at
least
seems
to
fly
in
the
face
of
what
previous
expectations
were.
And
I
don't
I
don't.
I
don't
know.
I
don't
have
an
answer,
but
I
think
that's
something
that
needs
to
happen
in
terms
of
discussion.
Thanks
thanks
brian.
G
I
I
think
I
agree
with
you
that
it
would
be
a
shame
if
greedy
clients
caused
the
ecosystem
to
refuse
to
adopt
and
that
the
the
goal
of
this
draft
actually
is
to
describe
mechanisms.
You
can
do
as
a
client
to
to
reduce
the
amount
of
greediness
and
also
to
sort
of
give
authoritative
server
operators
the
guidance
that
they
need
to
say:
hey
yeah.
G
It
is
okay
to
prioritize
my
clear
text
traffic
while,
while
my
resources
are
constrained,
so
if
you
have
specific
suggestions
for
how
to
ensure
that
these
things
are
less
greedy,
that
don't
involve
the
stub
saying
to
the
recurser
hey,
this
is
a
sensitive
query,
I'm
all
for
it.
The
reason
I'm
concerned
about
stub
signaling
to
the
recurser
like
hey.
I
need
this
query
to
be
private.
Is
I
have
I
I
honestly
cannot
imagine
end
users
making
that
decision
in
a
way
that
makes
sense.
G
The
trouble
with
these
with
these
leaks
is
that
they
are
privacy
leaks.
We
don't
know
when
something
is
going
to
turn
out
to
be
private.
You
might
only
learn
later,
even
even
if
you
could
distinguish
between
things
that
caught
queries
that
cause
harm
when
they're
leaked
in
queries
that
don't
you
might
only
distinguish
between
that.
G
After
the
fact,
you
might
never
know
that
it
was
a
problem
and
I
think,
introducing
some
new
mechanism
that
asks
dns
clients
to
to
bin
their
queries
into
sensitive
queries
that
need
encrypted
transport
between
authoritative
and
and
recursive
and
queries.
That,
don't
is
just
pretty
implausible
to
me
and
if
the
goal
is
a
wide
scale
deployment,
then
we
need
to
think
about
how
to
do
that
wide
scale
deployment
without
introducing
that
kind
of
signaling.
G
D
Sure-
and
I
I
would
just
offer
two
two
more
comments
along
those
lines.
One
is,
it
might
be
the
case
that
it's
not
on
a
per
query
basis,
but
on
a
per
client
basis,
so
there
might
be
some
small
percentage
of
your
clients
that
have
to
have
privacy
if
those
queries
are
coming
over
encrypted
transport
from
the
client
to
the
resolver.
The
the
existence
or
non-existence
of
the
request
to
be
have
those
queries
be
treated
as
sensitive
would
not
be
visible
to
a
an
on
path,
observer
or
off
path.
D
G
Thanks,
so
let
me
just
so.
This
is
interesting.
We
just
had
one
person
say,
must
not
send
s,
and
I,
and
we
just
had
somebody
else
say
you
know,
should
send
sni
or
maybe
even
must
send
sni.
So
that's
something
that
we'll
need
to
sort
out.
As
far
as
your
point
about
this
being
a
per
client
rather
than
per
query
configuration
your
description
of
that,
and
maybe
this
was
not
exactly
what
you
meant
to
say,
but
your
description
was
if
a
client
must
have
their
queries
encrypted.
G
I
want
to
point
out
that
this
mechanism
is
a
failure
for
any
such
requirement,
because
this
mechanism
does
not
defend
against
an
active
attacker.
In
fact,
it
doesn't
even
defend
against
a
resource,
exhausted,
authoritative
server.
There
will
be
like
this
mechanism
is
designed
to
fall
back
to
the
clear
text.
So
if
you
have,
if
we,
if
the
recurser
has
a
signal
from
the
client
that
says
my
queries
must
be
encrypted
from
recursive
to
authoritative
leg.
This
mechanism
is
the
wrong
mechanism
to
do
that.
A
Maybe
not
so
what
I
would
say
dkg
is.
I
I
think
there's
been
a
lot
of
good
comments
here,
so
I
I
think
the
what
I'd
like
to
do
is
if
ralph
or
or
jim,
want
to
you
know
either
chime
in
on
chat
or
or
reach
you
via
via
email
to
to
get
their
questions
and
ask.
That
would
probably
be
the
best
way
to
go
forward
and
then
I'd
just
encourage
you
and
joey
to
get
your
draft
posted
to
the
data
tracker.
H
So,
to
be
clear,
the
this
is
the
scope
of
this
presentation
is
almost
the
opposite
of
dkgs.
This
is
only
about
authenticated
ada,
and
maybe
I
need
to
be
a
little
bit
clear
about
what
authenticated
means.
It
seems
like
we've.
We've
had
some
some
different
definitions,
so
here's
what
I
mean
I
mean
basically
downgrade
resistant.
I
mean
an
active
network
adversary
cannot
ever
gain
access
to
the
dns
query
or
the
response
all
they
can
do
is
force
a
denial
of
service.
H
Authenticated
out,
I
have
this
abbreviation
a2
dot
authenticated
adot
is
possible
without
any
modification
to
the
parents.
We
can
actually
do
this
today,
using
components
that
already
exist.
You
know
we
could
just
sort
of
walk
away
and
declare
victory
almost,
but
it
requires
resolvers
to
be
very,
very
patient.
So
first,
the
resolver
has
to
do
an
ns
revalidation
before
using
a
name
server.
So
I
get
an
ns
record
in
glue.
It
says
you
know
this
name.
Server
is
the
name
server
for
this
child
zone.
H
Now
I
have
to
go
use
that
name
server
and
ask
for
the
ns
record
again
and
use
dns
sec
to
validate
that
that's
actually
correct,
and
then
I
can
use
that
name
server
and
also
before
I
actually
use
the
name
server.
I
need
to
send
an
svcb
query
is
assuming,
in
this
model
that
we
we
settle
on
on
using
svcb
I'll
note
that
the
the
svcb
for
dns
draft
is
now
adopted
in
add.
H
H
The
problem
is
that
this
slows
down
resolution
of
all
domains,
not
just
domains
that
are
participating
in
this
experiment,
a
resolver
that
implements
this
quality
policy,
slows
down
resolution
of
every
domain
that
it
tries
to
resolve.
So
for
that
reason
it
seems
like
this
is
not
likely
to
be
deployed
at
scale,
although,
if
you
disagree,
I'd
be
interested
to
hear
okay
next
slide.
H
So
we've
had
a
lot
of
different
proposals
in
this
working
group,
and
we've
got
a
few
more
today
about
adot
parent
signals,
so
within
the
framework
that
I've
just
specified
an
a
dot
parent
signal.
Anything
in
the
parent
telling
you
to
use
a
dot
is
purely
a
performance,
optimization,
it's
a
way
to
make
a
dot
faster,
and
that
may
be
really
important
because
resolvers
are
impatient.
H
So
if
we
can't
make
this
pretty
fast,
it
may
be
that
we
can't
get
it
widely
deployed,
but
helping
it
helps
me
a
lot
to
think
about
these
parent
signals
in
this
performance.
Optimization
context
where
there's
there's
a
slow
path
that
we
know
would
work
and
we're
just
trying
to
find
a
shortcut
next
slide.
H
This,
I
think,
is
the
most
important
slide
of
this
presentation.
This
is
the
slide
that
I
really
want
to
focus
on.
The
thing
that
makes
these
parent
signals
hard
is
that
there
are
a
lot
of
questions
that
we
need
to
answer
to
figure
out
the
shape
of
the
solution,
and
there
are
a
lot
of
plausible
answers
to
these
questions,
so
I'm
not
going
to
walk
through
all
of
these
on
this
slide.
This
is
just
to
say
this
is
a
long
list
of
possible
questions.
H
And
these
are
those
questions
again
with
the
answers
that
that
I
put
in
to
to
produce
the
ds
glue
result.
So
I
would
argue
that
if
you
pick
these
answers,
then
the
ds
glue,
design
kind
of
falls
out
and
if
you
propose
a
different
design,
it's
probably
because
you
have
different
answers
for
some
of
these
questions,
and
maybe
those
are
valid
answers
really.
H
We
do
care
about
authenticated
dns
over
tls
under
non-adot
parents.
An
example
of
that
is
the
dkg.gitlab.io
link
that
was
just
sent
around
right.
So
if,
if
dot
io
is
as
a
tld
is
not
doing
a
dot,
then
we
might
still
want
authenticated
a
dot
for
subdomains
of
gitlab.io
so
that
we
don't
see
that
we're
actually
accessing
dkg.getgitlab.I.
H
H
So
the
result
of
this
those
assumptions
for
from
my
perspective,
is
the
the
ds
glue
structure.
So
this
is
a
new
algorithm
type
called
ds
glue.
It
also
relies
on
a
digest
type,
which
has
previously
been
proposed
called
verbatim,
which
is
a
fake
digest
type
so
effectively.
It
lets
you
just
plop
arbitrary,
arbitrary
bytes
into
what
would
normally
be
the
digest
field,
and
so
the
the
ds
glue
each
ds
glue
record
contains
a
tlv
encoding.
A
compact
encoding
of
an
rr
set
a
glue
r
set.
H
What
does
it
mean?
So
if
you
get
a
ds
glue
record,
it's
a
ds
record,
and
so
it's
subject
to
the
standard
rrsigs
over
dsr-r
sets
and
the
whole
resolution
fails
due
to
bogus
if
anything
is
tampered
or
removed.
That's
the
real
authentication
value
of
all
this,
and
how
do
you
interpret
the
contents?
So
the
contents
of
this
ds
glue
record
the
rr
set
inside
the
record
is
a
glue
rr
set.
That
means
it's
only
for
delegation
following
it's
not
authoritative,
for
the
child
zone,
it
cannot
be
returned
to
a
stub
resolver.
H
In
principle,
you
can
represent
any
r
glue
of
any
rr
type
this
way,
but
the
draft
says
basically
don't
do
anything
crazy
because,
like
originally,
I
had
tried
to
put
nsec
rr
sets
inside
the
ds
glue
and
it
became
clear
that
that
was
very
confusing.
So
instead
we're
just
going
to
say
you
have
to
stick
to
some
rr
types
that
are
understood
and
we
can
expand
that
as
we
understand
more
next
slide.
H
H
Here's
the
same
example
with
as
I
was
talking
about
at
the
beginning,
the
slow
a2
dot.
So
all
you
have
to
do
is
drop
an
svcb
record
into
the
client
and
in
principle
a
sufficiently
patient
resolver
could
revalidate
the
ns
record
check
for
the
presence
of
an
svcb
record,
find
it
upgrade
to
dot
and
then
actually
issue
the
the
query
that
it
wants
to
issue,
but
this
is
slow,
so
next
slide.
H
H
H
As
long
as
cds
is
working,
the
the
parent
just
gets
some
more
ds
records
and
and
that's
the
end
of
the
story,
but
to
to
a
resolver,
a
resolver
looks
in
the
parent
zone
and
if
the
resolver
is
ds,
glue
aware
it
sees
that
the
ds
record
contains
these
authenticated
glue,
r
sets
and
it
can
use
them
to
go
directly
to
dns
over
tls,
notably
if
the.
If
the
resolver
isn't
aware
of
ds
glue,
then
these
just
look
like
ds
records
of
some
unknown
algorithm
type,
they're
ignored
next
slide.
H
So
my
point
here
is
ds.
Glue
shows
that
we
can
do
authenticated
a
dot
even
under
some
very
challenging
assumptions.
We
can
do
it
with
no
slowdown
for
non-participating
zones.
We
can
do
it
with
minimum
latency
for
participating
zones.
We
don't
actually
even
need
the
child
zone
to
be
signed,
but
really
this
is
a
very
large
design
space.
There
are
a
lot
of
different
possibilities
here
and
we
are
going
to
have
to
figure
out
where
we
want
to
be
in
that
design
space
that
could
take
a
while,
but
also
we're
not
blocked.
H
If
we
can
agree
on
some
of
the
details
of
the
slow
path,
we
can
actually
get
started
with
that
today
and
start
experimenting.
Maybe
we
can't
deploy
at
scale,
but
we
could
at
least
set
up
experimental,
resolvers
or
very
privacy,
conscious
resolvers
that
are
willing
to
make
that
performance
for
for
privacy
trade-off.
K
K
K
K
K
K
D
L
Great
okay,
so
I
I
I
like
where
you're
coming
from
with
this,
I,
like
particularly
the
idea
of
setting
out
you
know
this
idea
of
these
are
the
questions
that
I've
answered
in
this
way,
and
that's
how
I
got
here.
I
think
that's
great
one
thing
I
kind
of
want
to
quibble
with
is
this
idea
of
whether
or
not
we
can
ever
add
new
r
types?
You
know.
C
L
Seen
I
think
many
proposals
here
in
other
groups
of
using
ds
for
things
that
are
not
really
dns
sec,
there's
clearly
a
need
for
a
a
better
record
type
in
the
parent
of
some
type,
whether
it's
ns2
like
to
maple's
proposal,
whether
it's
some
general
purpose
thing
it
doesn't
matter,
there's
clearly
a
need
for
that,
and
we
also
now
have
a
mechanism.
That's
been
relatively
successful
for
a
couple
of
years
for
breaking
changes
which
is
flag
day.
L
So
as
part
of
this
work,
I'd
like
us
at
a
minimum,
deprived
and
ideally
bringing
it
to
dns
lab
to
agree
on
whether
or
not
we
can
ever
add
new
rr
types
to
a
parent,
and
if
we
say
no
great,
let's
say
that
out
loud
and
let's
say:
you've
got
ds
and
that's
it
have
fun.
If
we
don't
believe
that,
let's
say
that
as
well,
because
I
think
we're
all
making
this
assumption
that
we
can't
do
it
with
that.
But
clearly
it's
happening.
L
Clearly,
we've
done
it
in
the
past,
so
let's
either
decide
that
we
could
never
do
it
or
let's
decide
that
we
really
need
to
do
it.
I
I
don't
like
this
middle
ground
of
we'll
just
assume.
We
can't
do
it
so
we'll
overload
something
that
was
not
its
original
purpose
and
that's
not
you
know
a
complaint.
I
like
the
way
the
draft
works.
I
really
just
want
us
to
tackle
that
question
as
part
of
this
and
agree
as
a
group
on
the
answer
to
it.
If
we
can.
H
L
Sure-
and
that
makes
sense
and
maybe
another
aspect
of
it
is
you
know
we
decide
that
there's
a
time
aspect
to
it
and
you
know
yes,
you
can
have
them
if
you're
willing
to
wait
10
years
or
something,
but
I
also
think
we
can
play
with
that
time.
So
I'd
like
us
just
to
all
think
about
that
as
group
going
forward.
Thank
you
thanks.
E
Eric
it's
me
actually
yeah.
Thanks
for
the
presentation
ben,
I
appreciate
your
attempt
to
smuggle
the
entire
dns
into
into
the
parent
zone.
That's
that's
never
solving
this
problem,
so
whenever
I
have
to
deal
with
it
again,
I
I
think
that
this,
the
the
most
important
slide,
or
rather
most
important
side
of
the
answers,
is
a
great
contribution
to
like
how
to
think
about
this.
E
But
if
the
answer
is
like
that,
no
basically
those
things
are
all
have
no's
on
them,
then
like,
let's
just
admit
that
and
go
home
because
like
because,
like
it's
just
not
worth
like,
you
know
like
refining
these
proposals
over
and
over
again
merely
discover.
They
cannot
be
done,
though.
I
think
this
is
a
good
work
and,
like
I'd
be
more
if
this
were
the
answer.
I'd
be
more
than
pleased
I'd
like
for
this
to
be
the
answer
right
away,
so
I
I
I
don't
mean
to
discourage
you
in
any
way.
E
B
G
H
I
haven't,
I
haven't
attempted
to
do
that.
The
I
mean
yes,
the
the
truth
is
that
I
think
there
are
some
barriers
to
doing
this,
as
is
today
at
the
specifically
at
the
tld
layer.
You
know
below
you
know,
for
for
lower
zone
cuts.
You
can
you
can
do
whatever
you
want,
but
but
with
clds
you
need
some
way
to
push
those
ds
records
into
the
parent,
which
means
you
need
cds
support.
H
There
are
only
a
small
number
of
tlds
that
have
their
own
that
have
their
own
cds
support
and
a
lot
of
those
cds
implementations
have
filtering
for
defined
algorithms.
So
it's
common
to
for
parents
to
validate
the
not
validate
sorry
but
perform
a
little
bit
of
of
basic
format.
Checking
on
the
cds
record,
including
checking
that
it
that
it
has
a
known,
algorithm
type.
G
Right,
oh,
we
can't
distribute
spf
records
because,
most
you
know
a
bunch
of
dns
hosts,
refuse
to
publish
them
and
now
we're
saying
that
the
parent
zones
refuse
to
publish
certain
things.
So
there
is
clearly
a
need
for
this
to
be
published
either
the
parent
zones
can
decide
to
publish
these
whatever
these
hypothetical
new
code
points
are
within
ds
or
they
can
publish
them
as
new
record
types.
G
The
parent
zones
that
refuse
to
do
that
are
basically
directly
blocking
progress
and
we
just
need
to
say
this
is
what
we
need
you
to
do
if
we
think
it's
a
bigger
lift
to
ask
them
to
accept
new
record
types
than
to
that
and
to
ask
them
for
this.
We
should
ask
them
for
this.
I
don't
like
ben's
right,
we're,
not
blocked
unless
we
just
let
ourselves
get
stuck
between
these
two
choices.
I
would
be
fine
with
this
being
a
result.
H
Thanks
yeah,
I
do
think
just
adding
new
record
types
is,
is
a
bit
more
complicated
than
it
sounds
because
if
you
just
add
new
record
types
to
the
glue
they're,
not
authenticated,
so
we
need.
We
also
need
to
figure
out
what
our
plan
would
be
for
authenticating.
Any
new
authenticated
record
type.
That's
never
been
done
before
right.
M
Yeah,
so
if
you
can
hear
me
so
I
think
the
goal
that
was
mentioned
in
the
beginning
of
the
presentation
was
that
an
active
attacker
can't
learn
anything
about
the
query,
and
you
said
that
you
could
also
do
that
without
the
s
glue.
If
you
perform
an
s
revalidation
by
asking
the
name
server
what
the
s
records
are-
and
I
think
at
that
point-
you're
already
leaking
the
child
zone,
name
to
that
name,
server
that
you're
querying,
which
has
not
been
authenticated.
M
So
I
don't
think
the
statement
is
true
that
nothing
is
learned
by
an
active
attacker
and
if
you
want
to
avoid
that,
I
think
using
bs
glue
is
one
way
to
do
it
and,
as
far
as
I
understood,
the
bs
clue
would
contain
information
from
the
child
zones,
such
as
the
scvp
record,
for
example,
svcp
record.
But,
as
I
just
said,
it's
not
good
enough
to
query
that
stuff
from
the
child
name
server,
because
at
that
point
it's
not
authenticated.
Yet
you
have
to
query
from
the
parent
anyways.
M
H
H
H
But
maybe
that
maybe
that
answers
part
of
your
question
in
general,
my
my
attitude
here
has
been
that
for
conceptual
simplicity,
this
stuff
is
glue.
Glue
is
supposed
to
also
is
supposed
to
be
replicating
things
that
are
actually
in
the
child
zone.
So,
even
if
it's
not
necessary,
it
seems
like
a
good
idea
to
also
have
it
in
the
child
zone.
H
N
Okay,
great
different
browsers,
so
I
mean
what
this
draft
and
others
are
doing-
is
pretty
much
changing
the
way
how
resolvers,
iterate
or
recurs
to
the
domain
stream
and
basing
this
change
on
pretty
much
a
heck
by
cleverly
reusing
some
existing
record.
I
don't
think
it's
good
engineering
and
I
echo
what
john
said.
N
We
certainly
can
change
stuff
at
the
parent
and
the
slides
we
had
there
with
the
here's.
What
we
can
we
can't
do.
Some
people
in
the
working
group
might
have
different
opinions
on
what
you
can
and
what
you
can't
do.
So
I
think-
and
that's
the
basis
that
what
may
be
accurate,
that
we
seem
to
be
impossible
to
common
consensus
on
this
so
but
for
recursing.
N
I
would
really
rather
see
something
that
is
more
in
line
with
how
the
dns
works
and,
of
course,
if
you
want
to
introduce
that
you
have
to
introduce
records
at
the
parent
and
the
and
the
child,
possibly
also
to
make
that
bulletproof,
rather
than
hacking
it
onto
an
existing
record.
That's
just
my
opinion.
H
H
You
know
we're
talking
about,
I
think,
a
new
set
of
rrsigs
from
the
parent
and
possibly
new
bits
in
the
super
parent,
because
we
need
an
authenticated
way
to
tell
the
resolver
about
whether
these
records
are
present,
so
that
an
intermediary
can't
remove
them
and
claim
that
a
resolver
is
is
implementing
the
old
behavior
instead
of
the
new
behavior.
Sorry
that
an
authoritative
has
the
old
behavior
instead
of
the
new
behavior.
N
A
very
involved
change.
It
definitely
is
hard,
but
I
don't
think
it's
impossible
and
dns
sec
rules
are
also
something
I
mean
if
we
are
going
to
this
way,
revisiting
dns
after
so
many
years.
We
probably
also
can
change
stuff
there,
but
it
would
be
a
proper
kind
of
dns
solution
rather
than
a
hack
that
we
seem
to
push
on.
That's
what
I
just
think.
H
Sure
I
you
know,
I
think
that
anybody
who
writes
a
hack
tends
to
get
a
little
bit
attached
to
it.
So
you
know
I
have
a
view
of
this
where
you
know
this
is
maybe
just
an
expansion
of
the
idea
of
what
constant
of
what
a
ds
record
is.
Maybe
it's
actually
all
of
the
signed
data
required
for
a
delegation,
but
but
that's
a
matter
of
opinion.
O
And
robert
you're
last
in
the
cube,
hey
thanks
ben
for
presenting,
I
just
wanted
to
close
on
some
thoughts
on
this
versus
the
other
drafts
we've
heard
about
today.
I
think
we
need
to
have
multiple
paths
to
getting
a
dot
and
authenticated
a
dot
out
there,
if
not
today,
like
eventually,
the
signals
are
going
to
change.
Whatever
we
hear
about
today
is
going
to
through
experience,
turn
out
to
be
wrong
and,
from
my
point
of
view,
having
coexistence
and
transition
are
key
requirements.
O
You
know
some
of
the
other
comments
we've
heard
today
about
onboarding
load
or
making
safe
changes
to
infrastructure.
Those
all
those
all
are
very
important,
so
you
know,
I
think,
maybe
we
need
to
shift
away
from
perfect
towards
us
accepting
any
draft
that
has
promise,
even
if
it's
flawed
full
of
flaws
or
like
tons
of
flaws.
If
it
works,
we
should
perhaps
accept
it.
I
guess
what
I'm
saying
is.
We
should
lower
the
bar
from
to
could
work
instead
of
works
universally
or
has
unanimous
support
by
by
the
working
group.
H
A
A
A
D
So
this
is
what
I
was
taking
as
a
takeaway
or
how
I
was
viewing
what
what
would
be
goals,
at
least
in
terms
of
my
view,
on
things
for
dns
over
tls
to
authority.
With
the
you
know,
authentication
and
I
think
they're
pretty
straightforward.
This
is
going
to
be
kind
of
similar
to
what
ben's
questions
and
answers
were,
but
with
different
answers.
D
D
I'm
not
sure
that
those
will
be
up
deployable
in
a
short
time
frame.
What
I'm,
taking
as
goals
is
making
it
deployable
as
quickly
as
possible
and
including
avoiding
any
use
of
non-dns
elements
and
limiting
new
dns
protocol
elements
to
those
that
are
strictly
required.
So
if
there
is
some
portion
of
the
the
design
that
could
be
done
with
dns
protocol
elements
or
could
be
done
without
them,
I'm
picking
the
do
it
without
them.
D
That's
for
downgrade
resistance
and
to
avoid
needing
to
probe,
I
see
probing
as
something
that
itself
could
be
abused
or
generally
something
that
is
not
strictly
needed
or
desirable,
absolutely
validate
server
identity.
That's
what
the
authenticated
piece
is
in
terms
of
the
goals
protect
against
downgrade
attacks
and
resolve
reversal,
authoritative,
server
roles,
I'm
looking
at
this
from
both
sides
of
the
equation.
D
D
D
Dnsec
exists
for
that,
so
this
is
not
something
that
is
a
goal
for
what
I'm
proposing
and
I
think
it
should
not
be
a
goal
for
any
implementation
or
any
any
proposal
for
any
kind
of
adot
does
not
require
use
of
web
pki.
And
the
reason
for
this
is
this
is
all
dns
the
resolver
to
authoritative
it's
strictly
dns
queries
and
dns
answers.
I
I
see
web
pki
requirement
as
being
something
that
would
be
questionable.
It
may
not
be
acceptable
to
all
participants
or
all
operators,
and
it's
not
necessary.
D
So
I'm
saying
this
is
a
non-goal,
the
other.
The
next
one
does
not
require
a
single,
unique
server
identity.
That's
actually
a
goal
is
to
actually
have
multiple
server
identities
which
allows
for
distinguishing
the
behavior
whether
or
not
it
supports
adot
for
a
particular
server
as
signaled
by
the
name
and
attaching
the
behavior
to
the
names
of
the
name.
Servers
a
server
and
an
ip
address
can
have
multiple
names.
This
is
actually
a
really
good
way
to
allow
incremental
deployment
of
adot.
D
D
Oh
sorry,
the
name
server
name
on
the
delete
on
the
dns,
the
validation
from
the
delegation
from
the
parent,
so
the
parents
doing
a
delegation.
The
ns
record
is
not
signed.
You
have
to
have
some
way
of
protecting
that
name
of
the
name
server.
In
order
to
do
any
kind
of
up.
This
is
where
the
authentication
piece
actually
is
is
tied
to
the
the
parent.
D
D
This
is
necessary
for
explicit
transport
signaling
and
for
the
discovery
by
resolvers
and
that's
necessary,
but
that
only
applies
on
the
child
side.
It's
a
new
ir
type,
the
glueless
guidance,
I
think.
Actually
I
can
ignore
this
for
now,
so
I'm
not
even
going
to
talk
about
it.
I
think
it
ends
up
not
being
necessary.
D
D
If
you,
you
need
to
find
the
right
ip
address
and
that's
based
on
the
name
in
the
ns
record
in
the
parent,
the
delegation
side
and
that's
unsigned
in
the
parent,
because
that's
how
dnsec
was
defined,
it's
an
unfortunate
thing.
So
if
you
got
an
ns
record
in
the
parent,
you
got
the
domain
name,
that's
being
delegated
ns
and
then
the
name
server
name,
the
ns
record
is
non-authoritative
can't
be
signed.
The
target
name
can
be
glued
or
unglued.
D
The
resolver
contacts,
the
name
server
by
ip
address
only
and
the
the
dns
protocol
on
the
wire
actually
does
not
involve
the
name
server's
name
only
its
ip
address
in
glue
for
the
ip
address,
not
not
authoritative,
but
that's
irrelevant.
If
you
are
going
to
revalidate
that
delegation
as
part
of
the
the
overall
authentication
process
next
slide,
please
again,
I'm
just
skipping
over
some
of
the
stuff
that
I
put
in
the
original
draft,
but
I
think
they're
no
longer
needed
so
bold
face
things
here,
just
highlighting
what
this.
D
Tls
adot,
which
is
basically
just
tlsa
records,
so
tls
needs
the
ip
address,
plus
a
domain
name.
Resolver
connects
to
the
ip
address.
The
resolver
has
to
revalidate
the
name
and
the
if
you've
protected
the
ns
name,
the
with
the
nsb.
You
can
now
talk
to
the
ip
address
and
look
for
signed
data
within
the
child
related
to
tlsa
records,
the
name
server,
transport
dnst
as
a
signaling
mechanism,
and
you
can
also
reconfirm
the
address
record
for
the
name
server.
D
D
Nsv
is
name
server,
validation,
you're,
basically
putting
a
a
hash
of
the
name,
server
name
in
a
ds
record
and
hashing
it
in
a
ds,
key
record
and
then
hashing
it
to
the
ds
and
that
allows
the
resolver
to
take
the
delegation.
Ns
records
the
to
the
target
names
and
use
that
as
the
input
to
construct
reconstruction
reconstructing
the
dns
key
and
then
hashing
it.
Comparing
that
against
the
ds
record
that
is
seen
and
if
it
matches
you
can
now
use
that
delegation,
the
ns
name.
D
D
D
D
C
D
D
D
D
A
That's
right:
we
we
had
some.
We
had
a
couple
of
different
discussion
points
that
kind
of
ran
a
little
bit
long,
so
yeah,
but
I
I
also
want
to
make
sure
everybody
realizes
that
brian
you're
going
to
be
talking
about
these
slides
again
in
indiana,
stop
in
a
few
hours.
So,
yes,
you
know
there
is
an
opportunity
there
for
for
on
mic
discussion.
A
F
Oh
okay,
the
ones
I
put
in
the
minutes
and
people
if
they
want
us
to
have
more
action
items,
just
you
can
add
them
to
the
ether
pad
action
item
on
taking
to
the
mailing
list
on
moving
dns
over
dtls
to
historic
and
then
update
the
port
name.
And
of
course
you
know
how
how
we
describe
the
name.
Can
you
know
believe
that
as
an
as
something
for
us
also,
we
will
talk
with
the
av
about
use
case
discussions
from
the
unauthoritative
draft.
F
That's
a
pretty
good
comment
and
I
believe
the
last
one
is
we're
going
to
follow
up
on
ecker's
mechanism
crafting
comment,
and
we
will
take
any
and
all
sort
of
suggestions
on
that
one.
But
I
believe
those
are
the
three
action
items
we're
currently
sitting
on.
So
if
anyone
wants
to
add
more,
please
do
so.
A
A
Otherwise,
I
will
take
this
opportunity
to
thank
everybody
for
participating.
I
I
actually
was
very
grateful
to
see
you
know
some
of
the
robust
discussions
that
we
had
around
some
of
these
documents
and
and
and
hopefully
we
can
come
up
with
a
with
some
approaches
to
help.
You
know
get
some
of
this
stuff
unstuck
and
get
more
people
engaged
in
in
looking
at
these
proposals
and
and
either
doing
experiments
or
pointing
out
where
they
may
be
implementation
or
deployment
issues.