►
From YouTube: IETF111-DPRIVE-20210729-1900
Description
DPRIVE meeting session at IETF111
2021/07/29 1900
https://datatracker.ietf.org/meeting/111/proceedings/
A
Hello,
everyone,
my
clock,
tells
me
that
it's
1900
utc,
so
it's
time
to
get
started.
This
is
the
deprived
working
group
at
ietf,
111.
Welcome
to
virtual
san
francisco.
A
Your
host
for
today,
I'm
brian
and
my
my
my
affable
sidekick
tim
is-
is-
is
driving
all
the
slides.
The
the
main
goal
today
is
we're
going
to
basically
cover
four
four
main
topics:
a
piece
of
logistics.
Just
so
everyone
is
aware
of
d5
is
actually
meeting
in
two
separate
slots
with
a
30
minute
break
in
between.
A
We
will
have
to
switch
meet
echo
rooms
when
we
do
that.
So
you
know
our
goal
is,
is
to
get
as
much
of
the
agenda
into
the
first
slot
and
then
whatever
bleeds
over
to
the
second
slot
will
be
in
in
the
in
the
second
session.
A
So,
first
things
first,
no
well.
A
More
importantly,
the
you
know,
all
of
the
all
the
rules
here
in
the
bcps
everybody
should
be
aware
of.
I
would
expect
most
of
the
people
that
had
been
to
ietf
meetings
or
are
know
what
these
rules
are.
If
you
don't,
please
ask
tim
or
I
or
check
in
with
an
ad
or
just
go,
read
all
these
fun
documents
and
and
you'll
be
well
informed
of
of
your
responsibilities
for
participating
in
the
ietf.
A
Before
we
get
started,
I'd
like
to
request
a
couple
of
volunteers,
we
would
like
someone
who's
willing
to
take
notes
using
the
code.
Emd
link,
that's
in
the
in
the
chair
slide
and
we
need
someone.
Who's
willing
to.
You
know
help
relay
any
questions
that
come
up
in
the
in
the
jabra
room.
A
Thank
you,
jonathan
anybody
willing
to
act
as
a
note
taker
and
collaborate
in
the
in
the
note-taking,
so
we
have
a
accurate
minutes
of
what
goes
on
today.
A
D
A
So
kind
of
the
meta
agenda
we'll
go
over
what
we're
going
to
talk
about
today
and
and
ask
if
there
are
any
updates
or
changes
to
it.
We
don't
have
to
worry
about
blue
sheets
because
meet
echo
will
capture
everybody
who
joins
the
meeting
and
those
will
report
it
as
the
official
blue
sheets
updates
on
old
work.
A
Really
the
only
thing
to
report
and
I'll
just
go
ahead
and
do
it
now
is
we
we
do
have
the
the
zone
transfers
document
in
and
off
48,
so
that's
getting
very
close
to
being
an
rfc
and
then
the
rest
of
the
agenda
will
be
broken
up
between
current
working
group,
business
and
new
working
group.
Business
next
slide
tim.
Please.
A
If
you
have
questions
on
any
of
the
documents
that
we
talk
about,
you
can
find
that
on
on
our
data
tracker
page
and
for
our
current
working
group
business.
We're
going
to
go
over
the
status
of
the
dns
over
quick
document
and
then
we'll
have
an
update
on
the
the
unauthenticated
encryption
from
recursive
to
authoritative
any
changes
or
additions
for
current
working
group.
Business
on
the.
A
A
A
The
the
second
part
will
be
new
working
group
business.
We
have
two
topics:
one
is
a
discussion
by
paul
reuters
on
new
record
types
and
parent
zones,
and
the
second
one
will
be
on
the
status
of
the
signaling,
authoritative,
dns,
encryption
from
from
eric
scorla
any
changes
or
additions
or
deletions
to
our
new
working
group.
Business.
E
Since
the
the
first
discussion
is
actually
part
of
this,
what's
being
done
in
the
second
discussion,
it
might
make
sense
to
flip
these
two
around.
I
haven't
seen
the
other
presentation,
so
I'm
not
sure
if
that
makes
sense,
but
maybe
ecker
can
say
something
if
he
agrees
that
it
might
be
better.
The
other
way
around.
B
But
I
think,
oh,
if
alice,
wants
to
go
first,
I'm
happy
to
have
that
too.
B
Yeah,
I'm
happy
to
go
either
way,
but
I
just
looked
over
paul
slides
and
it
seems
like
I
think,
my
slides,
I
think
paul
and
I
agree
that
svcb
is
not
not
immediately
practical
and
like
the
immediate
term,
probably,
but
on
the
other
hand,
I'm
more
sanguine
on
the
other
alternatives,
so
I
think
we
need
to
have
the.
I
think
we
certainly
need
to
have
paul's
negative
view
represented
if
we're
going
to
make
any
progress
in
discussion
on
the
other
thing.
B
So
I
I
don't
care
who
presents
first,
I'm
happy
to
present.
First
or
second
I
mean
one
might
see
that.
Maybe
that's
we'll
have
me
go
first
in
the
sense
that
like
then,
I
can
say
like
well.
I
think
this
is
probably
okay
and
then
paul
can
say
it's
like
not
okay,
but
I
think
we
shouldn't,
I
think
we're
gonna
have
the
discussion
jointly.
F
Alex
mayo
for
nick
today
t
I
just
want
to
mention
very
briefly
that,
as
an
author
of
the
required
phase,
two
requirements
draft,
I
understand
that
the
the
the
consensus
of
the
working
group
has
been
that
we,
we
won't
renew
that
draft
and-
and
it's
like
being
overtaken
by
the
other
documents
that
we
have
in
the
working
group.
So
unless
somebody
speaks
up,
we
won't
put
any
additional
work
in
that
document.
A
So
if,
if
other
people
have
disagreements
with
that
assessment
and
and
they
see
value
in
that
work
moving
forward,
then
we
would
like
to
hear
about
it
and
and
how
it
might
address
some
of
the
comments
and
and
concerns
that
were
raised
about
trying
to
keep
that
document
up
to
date
and
moving
forward.
A
All
right
so
so
maybe
to
you'll,
get
to
paul's
request,
we'll
go
ahead
and
do
these
presentations
in
in
the
reverse
order
and
we'll
have
eric
go
first
and
then
paul
can
talk
afterwards,
and
I
do
like
the
idea
of
having
it
as
being
a
more
of
a
joint
discussion
after
both
presentations,
so
that
we
can.
We
can
talk
about
the
issues
rather
than
specific
presentation,
materials.
A
A
All
right,
so
let's
go
ahead
and
get
going.
Sarah,
are
you
ready
to
talk
about
dns
over
quick.
G
G
G
The
draft
was
adopted
by
deprive
in
2020
earlier
this
year,
quick
was
published
as
an
rfc,
and
we
also
presented
on
this
draft
at
the
last
ietf
meeting
at
110,
and
there
was
quite
a
bit
of
discussion
there
about
the
scope
of
the
document
on
and
thoughts
on,
the
mapping,
and
so
we've
done
an
update
where
we
hope
that
we
have
captured
everything
that
we
said
in
that
last
discussion
about
what
people
want
to
do
with
this
specification.
G
So
the
updates
that
we
made
in
the
latest
draft
after
that
discussion,
the
biggest
one,
is
that
based
on
feedback,
we
have
redefined
the
scope
of
it
to
make
it.
What
we've
said
is
a
general
purpose
transport
for
dns,
so
we
explicitly
make
clear
that
it
covers
stub
to
recursive,
as
it
originally
did
in
the
earlier
versions,
but
now
also
recursive
to
authoritative,
for
which
I
guess
the
acronym
is
a
doc
and
also
zone
transfer,
which
was
something
people
were
keen
to
see.
G
G
The
other
update
you
did
is
we
have
clarified
the
handling
of
protocol
errors
and
introduced
a
specific
protocol
error.
This
is
for
things
like
non-zero
transaction
ids
and
the
use
of
some
edius
idiosira
options
which
are
not
appropriate
when
used
over
quick
we'd
appreciate
feedback
that
the
approach
that
we've
got
at
the
moment
is
quite
strict
and
we
treat
all
of
these
as
errors
it
does.
G
It
will
make
it
interesting
for
proxies
and
that
they
will
have
to
handle
this
if
they're
proxying
from
other
transports
so
feedback
on
whether
the
current
approach
is
the
right.
One
would
be
appreciated
next
slide,
please
and
lastly,
again
based
on
the
feedback
that
we
got
last
time,
we've
changed
the
port
request
and
the
document
now
suggests
that
we
request
853.
We
haven't
put
any
request
in
at
the
moment,
so
this
is
another
thing
we
would
very
much
like
feedback
on.
G
G
G
G
Next
slide,
please
so
questions
on
the
draft
that
we
would
like
the
working
group
to
weigh
in
on
or
is
there
general
support
for
the
new
mapping?
That's
now
in
the
specification
and
for
the
new
scope.
G
G
G
I've
done
some
proof
of
concept
work
on
the
new
mapping.
So
that's
a
starting
point
and
I'm
hoping
to
work
more.
If
the
working
group
supports
the
change
in
mapping
on
updating
the
other
implementations
and
some
interop,
I
think
that
would
be
the
next
step.
If
we
have
support
for
this,
we
did
reach
out
to
andre
from
ad
guard
to
see
if
he
had
any
more
operational
feedback.
G
He
had
a
few
performance
numbers,
but
I'm
not
sure
we
can
draw
any
clear
conclusion
because
they
look
quite
implementation
specific.
He
did
say
I
don't
think
he's
here,
no
he's
not
so
I'll.
Just
relay
some
of
his
comments,
the
other
one
was
that
they
are
happy
enough
with
their
doc
implementation
that
they're
considering
making
it
the
default
for
their
apps,
and
he
also
made
a
comment
that
he
thought
doc.
G
Sorry,
quick
worked
rather
well
across
the
great
firewall
of
china,
in
that
he
thought
tls
and
https
degraded
a
lot,
but
quick
seems
to
perform
much
better.
It
was
his
quote,
so
that's
just
operational
reference
points.
G
One
thing
just
to
clarify
for
people
who
haven't
read
the
draft
is
that
the
authentication
model
for
adoc
is
deliberately
deferred
in
the
specification.
We
say
that
it
is
a
work
in
progress
and
it
will
be
defined
in
other
documents
produced
by
the
working
group.
So
essentially,
what
we're
doing
here
is
specifying
purely
the
transport
aspect,
which
should
be
enough
to
enable
experimentation
with
this
between
recursive
and
authoritative,
there
have
been
a
few
discussions
around
message:
size
limits
for
this
specification.
G
Our
intention
is
to
retain
the
64
kilobyte
limit
for
exactly
the
same
reasons,
as
was
done
for
doe
and
dot
largely
to
do
with
proxying.
We
don't
see
a
compelling
use
case
at
this
point
to
complicate
the
specification
by
lifting
that.
So
that's
all
the
updates
on
the
specification.
G
So
I'm
happy
to
take
questions
and
comments.
I
saw
some
talk
scrolling
past
on
ports
in
the
chat,
so
I
presume
somebody
will
want
to
speak
to
that.
C
F
Alex
marioffer
first
off,
I
really
like
the
change
of
doq
to
a
general
purpose
protocol.
I
think
it's
worthwhile
because
it
will
evolve
over
time.
It
will
undoubtedly
be
used
in
other
scenarios
that
the
zero
two
craft
was
was
like,
allowing
and-
and
the
second
thing
that
that's
more
like
a
minor
thing.
Draft
at
some
point
says
that
server
initiated
transactions
are
out
of
scope.
F
A
G
I
think
at
this
point
we're
pretty
happy
with
how
it
looks.
What
we
would
like
to
be
sure
of
is
that
we've
captured
what
the
working
group
wants
on
the
question
of
scope
and
mapping,
and
I've
had
some
offline
comments
to
say
that
other
people
think
it's
in
the
right
direction
and
beyond
that.
G
I
think
we're
at
the
stage
of
tidying
some
things
up
and
clarification,
particularly
around
the
error
handling,
because
that's
new,
so
my
feeling
would
be
an
initial
round
of
review
based
on
what
are
some
big
changes
and
if
those
are
mostly
minor,
I
I
think
we
would
be
looking
to
move
it
towards
working
group.
Last
call
at
that
point
in
time.
A
Okay,
shane.
H
Yes,
thank
you
hey
sarah.
I
I
admit
I
haven't
read
this.
So
don't
hate
me,
but
you
mentioned
that
that
that
x,
o
q
transfers
are
now
in
this
draft.
We
have
kind
of
separate
rfcs
for
a
lot
of
other
transfer
stuff
transfer
over
tls
is
separate
right.
H
G
So
what
we
do
in
the
current
draft
is,
we
essentially
say
it's
just
like
zone
transfer
over
tls,
except
you're.
Using
quick
in
the
sense
of
the
authentication
model
is
the
same
and
connection.
Reuse
is
largely
the
same.
Okay.
I
G
Did
think
about
trying
to
dive
into
that,
and
I
did
just
find
myself
repeating
a
lot
so
I'm
50
50
on
that.
I
think.
G
Me
going
back
and
taking
another
look,
whether
it's
a
sub
section
to
clarify,
because
there
are
subtle
differences
in
you
know
in
obviously
in
the
tls
one
we're
talking
about
we're
tcp
connections,
as
opposed
to
using
quick
connections.
G
I
guess
the
big
question
is:
is
there
anything
that
would
be
ambiguous
to
an
implementer
that
would
cause
interrupt
problems,
so
maybe
it's
worth
revisiting
it
with
that
kind
of
thinking
head-on
to
see
if
it
does
need
more
specification
here
or
even
splitting
out.
H
Okay,
I
think
that
makes
sense
I'll
I'll,
have
a
read
and
see
if
I
can
have
an
informed
opinion
about
that.
Thank
you.
A
Thanks
shane
paul.
K
Paul
hoffman,
so
I
have
read
the
recent
draft
and
I
think
it
is
just
fine
for
zoc
that
is
that
the
level
of
trying
taking
that
out
making
that
a
two-page
or
a
three-page
rfc,
actually,
I
think,
would
be
harmful
because
really
the
interesting
parts
are
doing
the
the
quick
stuff.
So
if
we
know
that
that's
a
thing
that
we
want,
I
would
certainly
leave
it
in
and
I
think
it's
well
defined.
K
I
mean
not
that
I'm
a
xfr
expert,
but
I
think
it
it
hit
the
points
that
I
expected
in
the
current
draft.
So
I
would
suggest
leaving
it
in
thanks.
A
All
right,
sarah,
what
tim
and
I
will
do
is
we'll
take
an
action
item
to
ping
the
working
group
to
see
how
they
feel
about
the
current
state
of
the
document.
And
if
we
get
more
positive
responses,
then
we'll
probably
start
working
through
last
call.
K
Great,
thank
you
so,
as
some
of
you
may
have
noticed
that
the
chairs
gave
us
30
minutes
for
this
slot,
I
have
four
slides,
which
would
indicate
either
I
have
to
talk
really
really
slow
or
you
have
to
ask
a
million
questions.
So
hopefully,
folks
have
been
following
along
on
the
working
group
about
this.
This
draft.
K
This
is
just
an
update
of
where
we
are
today
next
slide,
so
we
recently
published
the
03.
This
was
a
little
bit
before
the
deadline
of
for
the
meeting,
but
before
that,
since
the
last
meeting
there
had
been
a
discussion
of
oh,
it
seems
like
there's
going
to
be
a
lot
of
overlap,
common
stuff
between
unauthenticated
and
the
fully
authenticated.
K
So
we
actually
split
out
features
that
we
thought
would
be
in
common
and
published
two
drafts,
the
comp.
You
know
common
features,
draft
and
o2,
and
people
really
didn't
like
that.
So
we
went
back
to
recombining
it
and
again
things
can
be
split
out
later.
If
people
change
their
mind,
if
the
working
group
changed
their
mind
yet
again,
but
this
is
where
we're
at
now
it's.
It
seems.
Okay,
next
slide.
K
So
we
we
know
that
there
are
a
couple
of
outstanding
issues.
None
of
these
are
horrible
and
I
think
it
will
come
down
to
just
having
a
little
bit
of
discussion
about
each
the
first
one
is
port.
Probing,
especially
for
dot,
could
also
be
port
probing
for
doh
and
doq.
K
So
for
the
unauthenticated
case,
port
probing
is
not
a
big
deal
because
it
can
happen
lazily.
You
know
you
look
at
in
your
cache,
you
say,
look,
there's
an
ns
record
and
I
don't
know
whether
they
do.
K
Dot
or
whatever,
therefore-
and
I
want
to
know-
and
I
go
out-
and
I
look
for
an
svcb
record-
and
I
don't
see
it-
I
think
well,
let's
just
check
the
port,
maybe
they
haven't
published
an
svcb
record
and
the
ports
open
is
like
great.
I
will.
I
will
mark
that.
We
certainly
don't
want
to
say
to
do
that,
because
that
would
cause
a
lot
of
probing
and
especially
for
tcp
connections.
K
That
could
add
overhead
and
things
like
that,
but
it
maybe
it's
just
fine
to
to
do
that,
and
the
result
would
would,
of
course,
for
allowing
port
probing
would
be
we'd
have
more
encryption
on
the
internet,
so
that
would
be
good.
So
really,
if
people
agree
with
that
thought,
it
would
really
be
for
the
draft
the
eventual
rfc.
K
We
would
want
to
say
at
what
level
you
know
like.
I
don't
think
it
should
be
a
should.
It
could
be
a
may
and
there'll
be
plenty
of
people
who
don't
want
to
do
port
probing,
so
just
as
a
possible
option,
we
know
people
are
doing
it
now
right
now,
the
draft
it
really
talks
about
the
advance.
K
You
know
like
the
advantages
and
disadvantages
because
of
tcp,
which
completely
ignores
doq
and
truth,
be
told,
I
think,
five
years
from
now
after
this
is
well
implemented,
the
vast
majority
was
going
to
be
over
doq,
so
we
need
to
do
a
better
job
of
actually
talking
about
doq,
not
just
in
the
it's
possible,
but
also
in
the
specifics
about
how
much
overhead
there's
going
to
be
and
such
like
that.
K
So
we
need
to
add
more
there
and
we'd
love
help
on
that
and
the
iana
considerations
is
basically
a
stub
with
questions
right
now.
So
once
we
get
closer
to
being
finished,
we'll
obviously
fill
that
in,
but
that's
about
it
for
our
known
outstanding
issues
next
slide.
K
So-
and
this
is
the
last
slide
you
know-
is
that
all
probably
not
there
will
probably
be
more
issues.
We
certainly
hope
to
hear
from
y'all
on
that,
the
more
issues
that
you
bring
up
with
this
document,
the
more
issues
that
can
be
dealt
with
earlier
in
the
fully
authenticated
work
and
also
the
sooner
we
can
get
it
done
so
we'd
love
to
see
this.
You
know
get
moving
forwards
a
little
bit
faster.
K
You
know
with
a
little
bit
more
interest,
because
this
this
can
be
completed
without
waiting
for
the
fully
authenticated
work
to
complete
or
even
to
get
very
mature.
That
is,
this
can
be
done.
There's
a
lot
of
people
who
are
interested
in
doing
this,
who
are
also
interested
in
doing
fully
authenticated
when
it
gets.
You
know,
finally
done
so.
It
might
be
good
to
have
this
out
there
and
people
actually
implementing
and
such
like
that.
K
We
would
love
to
hear
more
either
on
the
list
or
right
now,
certainly
right
now,
but
on
the
list,
and
if
there
isn't
that
much
more
than
peter,
and
I
can
do
a
quick
revision
to
handle
the
stuff
on
slide
three
and
we
can
be
ready
for
working
group
last
call
if
that's
what
people
want.
K
G
Just
to
say
that
I
I
do
think
it
would
be
nice
to
generalize
this
to
all
the
encrypted
transport,
particularly
with
the
level
of
interest
we're
seeing
in
docs.
So
I
could
certainly
try
and
help
out
those
edits.
K
L
I'm
way
behind
on
contributing-
and
you
want
to
contribute
so
expect
me
to
find
more
cycles
on
this
and
some
related
things
for
the
the
the
parental
side
thing
so
both
of
those
it's
unrelated
to
this
per
se,
but
the
the
other.
The
other
thing
that's
going
to
be
presented.
L
K
We
have
removed
any
discussion
at
all
of
the
parental
side
in
the
03
document.
We
had
mentioned
it
in
o2
as
it
might
be
there,
but
because
of
the
questions
that
are
going
to
come
up
later
in
the
meeting,
and
we
don't
need
it,
we
took
that
out.
So
that's
not
at
all
relevant
for
us
moving
forward.
L
Exactly
I
want
to
keep
it
separate
as
well,
and
I
think.
K
L
Even
the
parental
securing
the
parental
delegation
piece
is
probably
something
that
it's
needed
for
deprived
work,
but
I
think
it
might
actually
belong
in
guinness
off.
So
I'm
gonna.
M
Look,
I
was
just
going
to
take
up
your
your
final.
Your
final
point
on
that
slide
in
front
of
me,
where
you
say
this
document
can
be
completed
without
waiting
for
the
fully
authenticated
work
and
merely
putting
in
a
request
to
say
this
document
either
should
or
will
be
completed
without
waiting
for
the
fully
authenticated
work
to
complete.
M
I
think
indication
is
a
much
thornier
issue,
given
that,
and
also
given
that
authoritatives
are
promiscuous
answerers
the
whole
issue
around
authentication
of
who
you're
asking
versus
what
you
are
asking
about,
needs
more
thought,
but
that
shouldn't
preclude
this
transport
and
this
approach
being
used
without
authentication
pumped
out
right
now,
with
the
caveat
that
authentication
will
follow,
is
probably
a
better
approach,
so
my
own
preference
would
be
ship
it
now
and
leave
the
full
authentication
as
a
placeholder
for
further
work.
Thank
you
great.
Thank
you.
I
E
Okay,
of
course,
I'm
just
going
to
say
the
exact
reverse
of
that.
I
think
we
should
like
authentication
is
relatively
straightforward
these
days,
especially
if
you're
going
to
use
the
same
transports
like
tls
and
quick.
You
should
really
be
able
to
figure
out
what
certificate,
to
use,
what
identity,
to
use
and
just
complete
that
work
and
skip
this
part,
so
that
it
can
just
be
clear
that
a
client
connecting
and
has
some
sort
of
t-less
negotiation
error.
K
A
And-
and
I
think
the
order
of
of
work
and
the
the
ex
the
interest
has
been
expressed
in
the
two,
this
is
this
is
something
where
we
need
to
at
least
get
it
to
a
point
where
it's
it's
ready
for
experimentation,
so
that
we
can
actually
see
if
it
works
the
way
that
people
expect
it
to
work,
or
it
breaks
the
way
that
people
expect
it
to
break
all
right.
Watson.
N
Yeah
watson-
I
I'm
maybe
a
little
confused
because
of
my
relative
lack
of
knowledge
about
the
dns,
but
it
looks
like
the
signal
is
entirely
dependent
on
being
able
to
resolve
the
name,
server's
name,
and
so
in
particular,
they
have
names
and
you
can
get
a
certificate
and
validate
against
it.
And
it's
not
clear
to
me
why,
like
what
is
unauthenticated
here,
is
it
just
that
we're
not
going
to
use
the
web
pki
for
some
reason,
or
is
it
merely
that
the
signal
about
that
you
support
encryption
could
be
interfered
with?
K
I
think
your
question
is
actually
for
the
next
group
of
people
not
for
this
one,
that
is
it
we.
I
thought
we
were
clear
in
this
draft
and,
if
not
I
can.
I
can
redo
it
that
we're
simply
saying
go
through
tls,
but
if
the
authentication
fails
keep
going
so
the
how
you
got
an
authenticated
identity
where
you
got
it
and
things
like
that
is-
is
not
at
all
for
this,
and
it's
very
much
important
for
the
fully
authenticated
version.
Does
that
make
sense.
K
Okay,
so
it
would
be
hard
to
answer
your
question
without
repeating
things
that
have
been
being
said
on
the
list
for
the
last
year,
but
basically
there
are
two
use
cases.
One
is
where
you
never
want
to
fail,
but
you
do
want
to
have
encryption
and
the
other
use
case.
Is
you
really
want
to
have
very
good
privacy?
K
K
C
Hi,
so
this
draft
has
changed
a
little
bit
since
the
last
time
I
looked
at
it.
I've
generally
been
of
the
opinion
that
we
should
have
a
draft
documenting
how
to
do
opportunistic
adot,
but
after
looking
at
this
one,
I
don't
think
so.
So
I
think
I
disagree
with
a
few
different
things
that
have
been
said.
I
disagree
with
the
idea
that
this
can
proceed
or
should
proceed
ahead
of
the
authenticated
encryption.
I
think
they
have
to
proceed
together,
they're
actually
very
tightly.
C
K
C
Be
able
to
be
wild
because
this
draft
says
you
can
set
up
a
server
with
an
svcb
rec,
a
name
server
with
an
svcb
record
on
it,
and
you
can
put
the
wrong
certificate
on
that
and
nothing
is
going
to
break.
I
C
You're,
a
if
you're,
a
recursive
resolver
and
you
run
into
a
a
name
server
that
sets
up
that
has
the
wrong
certificate
on
its
has
an
svcb
record
and
the
wrong
certificate.
You
fail
hard.
J
C
That
the
result
of
that
is
that,
if
I
you
know
if
this
comes
out
first
and
name
servers
out
in
the
wild
start,
relying
on
it
and
putting
up
self-signed
certificates
and
have
working
unauthenticated
encryption
encryption,
then
any
recursive
resolver
that
tries
to
implement
draft
a
docs
will
find
that
they're
unable
to
connect
to
those
servers
and
and
will
actually
you
know,
serve
fail
for
those
servers.
C
So
I
think
we
need
to
fix
this
and
make
these
drafts
compatible,
and
I
think
that
watson
is
basically
on
the
right
track
here
to
you
know
my
looking
at
this
draft
now,
it
seems
to
me
that
what
it's
describing
or
what
it
should
be
describing
is
not
really
unauthenticated
encryption,
but
late,
authenticated,
encryption
or
or
possibly
actually
something
that
resembles
old
fat.
It
rebels,
the
ietf's
official
opportunistic
encryption.
C
So
you
attempt
to
do
the
encryption
setup
and
an
intermediary
can
block
your
access
to
the
svcb
record,
potentially
in
which
case
you're
stuck.
You
can't
do
this
upgrade
and
you're
probably
going
to
do
this
late,
because
you
don't
want
to
block
the
resolution
process,
so
you're
asynchronously
trying
to
fetch
this
record,
but
once
you've
got
it,
then
you
need
to
be
fully
authenticated
and
fail
hard.
If
tls
tells
you
to
fail.
K
So
that's
on
the
assumption
that
the
working
group
adopts
web
pki
as
compared
to
using
game
records
and.
C
Oh
okay,
we
need
to.
K
K
Against
the
use
case
that
you
should
go
forwards
regardless,
because
there
may
be
a
later
use
case,
where
authentication
is
the
normal
kind
of
authentication
that
we're
used
to
in
tls
is
required
right.
Okay.
So
if
the
working
group
agrees
on
that
and
wants
to
change
the
use
case,
we
would
obviously
have
to
change
the
the
document
name
yet
again,
but
we
could
and
then
simply
go
with
that
direction
of
not
being
the
fully
privacy.
K
Enhanced
kind
of
thing
that
we're
going
to
talk
about
next,
where
you
have
the
parent
stuff
ahead
of
time,
so
that
the
attacker
that
the
viewer
cannot
see
what
you're
trying
to
get
but
then
say,
and
if,
if
you've
gone
through
tls
and
it
doesn't
authenticate
with
whatever
authentication
mechanism,
then
stop
and
you're
going
to
get
a
serve,
fail
right.
K
J
Tony
with
the
google
public
dns
hat
on,
so
I'm
not
going
to
rehash
just
the
very
technical
discussion
between
ben
and
paul,
but
I
just
wanted
to
say
that
google,
public
dns
is
reviewing
what
we
can
do
in
terms
of
opportunistic
encryption
to
various
name
servers.
Given
our
capacity,
I
think
for
us
for
high
volume
connections
being
able
to
do
even
some
amount
of
unauthenticated.
Encryption
has
value
because
it
prevents
passive
eavesdropping
on
user
queries
and
we
are
willing
to
experiment
with
name
servers
who
want
to
test
test
this
functionality
out.
C
A
B
So
I
think
so
I
think
I
mean
I
think.
First
of
all,
I
I
share.
I
think
ben's
can
ben
watson's
concern
about
like
this
document.
I'm
gonna
have
to
go
forward
at
this
stage,
but
I
think
more
generally,
it
seems
to
me
that
there
are
three.
B
B
What
what
this
document
says
is
you
can
stand
up
a
authoritative
with
it
with
no
valid
credentials
whatsoever,
and
then
people
might
find
someone
discover
it
and
but
you're,
but
you're
going
to
there's
no
way
to
practice
middle
attack
or
any
kind
of
active
attack,
because
they
could,
because
there's
no
discovery,
authenticate
discovery
mechanism.
B
What
what
the
adoc
graph
says
is:
here's
an
authenticated
discovery
mechanism
and
then,
once
you
get
authenticated
governments
that
boost
drops
you
up
to
an
expansive
credential
and
therefore
you
need
to
authenticate
a
credential
or
make
the
connection.
There
is
a
there's
at
least
one
there.
B
One
other
point
in
the
spectrum,
which
is
that
we
just
do
not
describe
how
you
discover
that
the
server
ought
to
be
authenticated,
but
the
server's
required
of
a
valid
credential,
and
so
I
think
I
think
this
is
roughly
the
case
that
that
bill
is
alluding
to
which
is
you
remove
the
section
of
this
draft
that
says,
if
you
don't
you
keep
this
guy
the
same
as
it
is,
but
except
you'd
say:
if
you
connect
the
thing
and
you
don't
get
a
valid
like
what
pki
cert,
then
I
don't
know
you
fall
back.
B
I
think
right
and
whether
that
be
good
or
not,
I
think,
is
unclear
or
what
pi
ordained
and
I'm
not
fighting
about
that.
There
is
another
point,
another
point
in
the
space
right.
It's
like
not
clear
to
me
that,
like
just
because
it's
very
much
I
wanted
that.
That's
that's
relevant,
the
you
know.
B
Yeah
I
mean
I
think
it
is.
It
is
important
that
semantics
that
it
is
in
towards
this
signal,
but
svcb
those
semantics
have
to
be
the
same
or
we
need
to
have
disjoint
svc
semantics
right.
It
can't
be
the
case
that
spc
says
simultaneously
expect
and
do
not
expect
a
secure
connection
right.
That's
right
now
I
mean
that's
reasonable.
I
want
to.
B
Not
like,
but
that's
it
and
it
wouldn't
be
a
disaster
if,
like
it,
turned
out
that,
like
that,
like
we,
why
don't
this
document
is
like
what
I
would
do
if
we
were
to
publish
this
document
and
then
we
would
later
decide,
we
want
to
use
this
vcb
signaling
for
a
docs.
We
just
like
invent
some
new
flag
that
says
like
you
have
to
be
encrypted
so,
like
I,
don't
think
it's
like
the
end
of
the
world.
If,
if
these
things
advance
in
maryland,
these.
F
K
For
that
reason,
so
before
you
go
after
you
set
a
thing
in
the
middle
which
I
have
not
heard
anyone
say,
but
then
you
hand
waved
it
and
I'd
like
to
hear
your
opinion.
Well,
I.
K
Hey
well,
if
let
me
say
it,
then
so
you
said
somebody
a
resolver
attach
goes
to
a
a
authoritative
server
they
get
through
tls
and
and
and
they
try
to
authenticate
and
it
fails
and
then
you
said
well,
maybe
they
start
over,
but
that
was
a
maybe
in
that
case.
If
for
given
that
you
don't
like
this
use
case
at
all
and
you've
said
that
many
times
and
that's
fine,
what
would
you
say
would
be
the
correct
thing
because
we're
saying
move
forwards.
Anyways?
B
B
I
think
in
your
so
I
guess
what
I
would
say
is:
is
it's
not
clear
to
me
why
it
makes
sense
to
have
an
svcb
record
that
says
I
do
tls,
but
an
invalid
certain
or
an
invalid
thing
or
whatever
right
like
like,
given
that
they're
so
easy
to
get
both
of
those
like?
Why
is
that
an
asset
and
the
advantage?
That
would
be
that
that
as
ben
indicated,
that
would
be
forward
compatible
with
some
sort
of
sccb
in
the
parent
thing
right.
B
So
you
the
way
so
when
you
think
about
this
is
like
you
know
is,
is
light,
is
like
a
ssh
right.
Is
that
if
you
were
to
say
that
the
semantics
of
svcb
work
they're,
better
btls
and
a
better
work,
then
once
you
got
to
the
once
you
got
to
there,
then
you,
because
you
would
toe
food
into
some
sort
of
like
something
before
compatible
and
then,
if
you
ever
invented
a
mechanism
to
like
help
for
the
parent
to
tell
you
this
would
be
tls.
B
That
would
always
work
magically,
as
opposed
to
the
situation
where
you
have
to
sort
of
like
and
and
then,
and
I
think
like
that
would
still
allow
you
to
have
some
probing
case
where,
when
you
probed,
you
were
like,
if
you
didn't
have
no
no
extra
knowledge,
you
could
say.
Well,
I
don't
think
any
bogus
cert
I
want
because,
like
whatever,
but
then,
if
I
get
but
then,
if
you
get
like
that's
a
cb
thing,
then
you
assume
that
you
used
to
write.
B
K
Right,
I
I
agree
with
you,
because
I
you
know,
even
though
I
don't
have
the
fully
authenticated
use
case,
I
never
want
a
resolver
to
you
know
to
to
give
a
wrong
answer.
I
know
that
many
people
do
want
that.
So
you've
just
suggested
a
few
things
I'm
gonna
think
about
it.
I
almost
think
I
mean,
even
though
it's
a
terrible
suggestion,
it
might
be
the
least
terrible
one,
which
is
the
last
thing
you
said,
which
is
for
the
unauthenticated
use
case.
K
B
Yeah,
well,
it
would
allow
yeah
and
why
you
want
to
have
no
idea,
but
it
would
allow
actually
bootstrap
up
from
mike.
It
would
allow
bootstrap
up
from
from
doe
53
to
go.
If,
for
some
reason
you
want,
I
mean
or
from
d.o.t
to
dough
right,
I
mean
yeah.
Okay,
like
I
say,
yeah,.
B
G
O
Robert
evans,
I'm
I
work
with
google
cloud
dns.
I
wanted.
O
Out
that
I
don't
see
any
compatibility
here
between
the
two
proposals
for
unauthenticated
opportunistic
versus
authenticated,
the
the
distinction
is
about
signaling.
If,
if
we
invent
a
protocol
specification
or
other
means
to
say
this
name,
server
should
have
an
authenticated
identity,
then
we
can
apply
that
to
connections
for
resolvers
that
support
it.
O
When
that
signal
is
not
present
or
the
resolver
does
not
support
that
signal,
then
we
can
proceed
with
an
authenticated
or
opportunistic
and
it's
a
matter
of
evolution
where
we
begin
with
experience
around
the
encryption
and
then
we
can
move
on
to
signaling
in
a
protocol
that
says
it
should
have
an
authentication
and
we
need
to
be
able
to
convey
that
securely
for
the
ecosystem
to
work
securely.
So
it
is
sort
of
a
stage
deployment
where
we
will
see
more
and
more
security
around.
O
Conveying
that
fact,
and
today
the
parents
cannot
cannot
convey
that
with
security.
Today,
maybe
in
the
future
we
can-
and
it's
going
to
take
some
iteration
before
we
can
convey
the
authentication
signal
securely
so
anyway,
just
reiterating
that
my
perspective
is
they're.
They're
compatible.
If
we
say
future
authentication,
signaling
becomes
a
requirement
for
resolvers
that
adopt
it.
P
Victor
hi,
so
robert
provided
the
perfect
intro
to
what
I
was
going
to
say,
which
is
that
way
back
in
rfc
7435,
one
of
the
things
that
was
defined
was
opportunistic,
but
with
downgrade
resistant,
signaling
of
authentication
versus
not,
and
so
that's
certainly
anticipated
quite
some
years
back,
and
the
other
thing
is
that
in
the
smtp
specs
for
opportunistic
dane
one
of
the
things.
P
That
said
is
that
if
your
dane
parameters
are
unsupported
but
tlsa
record
is
found
and
is
secure,
that
you
go
ahead
and
mandate
tls,
but
don't
authenticate
because
you
don't
have
parameters
that
you
can
use
so
unusable.
Dane
is
a
signal
for
unauthenticated
but
required
tls
in
the
smtp
space
that
can
be
repeated
here
if
desired.
So
you
could
use
dane
with.
P
P
K
I
think
paul
waters
had
suggested
earlier
and
just
for
the
folks
in
here
who
are
not
familiar
with
the
work
that
victor
has
done
on
dane
with
smtp.
There
are
tens
of
millions
of
servers
doing
this
constantly.
The
fact
that
you
get
email
at
all
is
is
based
on
this.
So
it's
not.
This
would
not
what
he
is
suggesting
is
not
like
a
new,
weird
experiment.
It's
something
that
is
is
is
widely
widely
used
today.
Quite
frankly,.
P
L
Keep
it
simple
not
go
too
far
into
the
weeds.
I
think
one
of
the
things
for
a
weak
signal,
but
a
signal
that
needs
to
be
trusted
is:
is
the
name
server,
the
the
name
of
the
name
server?
Is
it
it's
if
it
isn't
in
a
signed
zone,
and
if
it
is,
then
it's
reasonable
to
then
expect,
or
at
least
look
for
a
tlsa
record,
and
if
it's
not
there
do
some
kind
of
opportunistic.
L
If
it
is
there,
if
there
is
a
tlsa
record,
use
it
and
hard
fail,
I
think
that
that's
a
weak
signal.
It's
very
much
like.
L
Yeah
and
the
other
observation
is
for
some
of
the
adox
things
like
doh.
L
If
there
is
a
need
from
their
side
to
do
web
pki,
the
tlsa
record
types
support
a
requirement
for
web
pki
validation.
L
So
I
think
if
we
could
then
say,
if
you're
gonna
do
that,
you
have
to
do
tlsa,
because
it's
really
easy
to
do
and
say:
okay,
tlsa
type,
the
zero
which
says:
okay,
here's
your
ca,
fingerprint
and
that
that
is
scalable.
It's
validatable,
it
forces
web
pki
by
the
tlsa
of
the
other
types,
doesn't
require
or
force
web
pki.
L
L
A
All
right,
daniel.
D
D
I
just
want
to
point
out
that
we
are
thinking
we
have
to
think
about
two
different
cases
here.
We
have
to
think
about
the
perspective
of
the
recursive
resolver
and
what
do
they
want
to
do
when
they
run
into
failures,
and
we
have
to
think
about
the
deployer
of
the
authenticated
of
the
authoritative
resolver,
the
authoritative,
authoritative
name,
server,
not
a
resolver
right.
Do
they
want
to
deploy
this
thing
at
the
risk
of
getting
their
entire
zone
locked
out
if
they
screw
it
up,
and
there
is
always
a.
D
Screwed
up
right,
it
can
get
screwed
up
because
you
forgot
to
renew
a
cert.
It
can
get
screwed
up
because
your
dns
signatures
didn't
work
right.
It
can
get
screwed
up
because
of
a
range
of
different.
You
know
reasons
that
you
know
there's
this
software
right,
software
fails
and
people
might
want
with
with
smtp.
D
We
said
with
the
mta
sts
mechanism,
we
said:
look
we
want
to
be
able
to
operator
wants
to
be
able
to
to
ask
for
reports
when
there
are
failures.
Not
just
automatically
have
the
thing
take
their
zone
out
right.
They
want
to
collect
reports,
they
want
to
deploy
over
time
and
and
do
it
gradually,
that's
the
kind
of
thing
we
need
to
be
thinking
about.
How
do
we
build
the
mechanism
so
that
we
can
encourage
the
managers
of
an
authenticating
of
the
authoritative
server?
To
pick
this
up?
D
That's
the
only
thing.
I
think
that
this
particular
draft
is
doing.
Is
it's
saying,
look,
here's
a
mechanism.
You
can
roll
it
out
for
it's
not
going
to
break
your
zone
right.
You
can
roll
this
out.
You
don't
have
to
think
about
the
signaling.
You
shouldn't
have
to
think
about
the
signaling
and
you
can
just
roll
this
out
and
we
should
be
thinking
about
how
do
we
get
a
report
in
for
it
right?
This
is
to
specify
for
an
authoritative
operator
so
that
they
can,
they
can
roll
it
out.
D
They
can
say
I'm
offering
encryption,
but
I'm
not
worried
that
I'm
going
to
break
things
for
people
who
are
querying
the
zone
right.
That's
that's
the
question
that
we
should
be
looking
at
and
I
want
to
I
want,
but
my
second
point
was
just
that.
I
think
it
was
brian
who
said
you
know
the
presence
of
the
tlsa
record.
We
have
to
consider
the
in
bailiwick
question
here
right.
I
D
Server,
you
have
an
issue
now
people
can
say
in
baileywick
name
servers
are
not
a
good
idea.
There
certainly
are
cases
where
they're
not
a
good
idea,
but
at
some
point
there's
a
loop
right
if,
if
every,
even,
if
no
one
did
in
bailiwick
name
servers,
if
you
want
to
resolve
anything,
you
need
to
resolve
stuff
in
some
kind
of
you
know,
to
learn
what
imagine
this
was
deployed
for
everyone,
there's
going
to
end
up
being
a
loop
and
that
loop
is
the
equivalent
of
an
invalid
with
name
server
right.
D
So
we
need
to
be.
We
need
to
be
thinking
about
about
that
for
the
signaling
part
of
it
as
well.
Anyway,
I
think
that's
it.
A
Thank
you
and
christian.
Q
I
am
looking
at
this
from
an
implementer
point
of
view,
if
I
am
implementing,
say
a
recursive
or
something
like
that,
and
I'm
going
to
use
a
stack,
I'm
going
to
use
a
tls
stack
or
quick
stack.
Something
like
that
and
those
stack
in
practice
require
that
I
use
a
server
name,
I
mean,
and
they
require
that
there
is
a
certificate
that
matches
the
server
name.
Q
They
don't
require
that
that
server
name
has
any
particular
characteristic
or
tied
to
the
dns
hierarchy.
But
if
I
do
not
have
a
server
name,
the
the
connection
is
just
going
to
fail,
because
I
mean
it
will
fail
somewhere
in
the
middle
of
a
weird,
open,
ssl
stack
or
whatever
that
I
have
no
control
about
so
yeah.
It
might
not
be
entirely
false
in
true
in
theory
that
you
need
that,
but
in
practice
it
sucks.
K
Q
K
And
then,
if,
if
you're,
using
a
stack
that
will
fail
when
the
authentication
fails,
then
that's
your
choice
to
use
that
stack.
Yes,
absolutely.
Q
Well,
it's
not
every
exactly
a
choice,
because
the
average
developer
doesn't
want
to
dive
too
too
deep
into
re-engineering.
The
ssl
stack
so
yeah,
okay,
and
so
the
choice
would
be
clear
I
mean
for
me,
I
mean
what
makes
it
the
I
would
say.
Opportunistic
part
is
that
okay,
that
may
fail
for
some
reason,
and
if
I
am
in
a
sneak
mode,
I
mean
it's
okay
to
go
back
to
using
the
port
53
or
something
like
that.
That's
a
that's
really
a
choice!
For
me.
K
Okay,
so
I'm
hearing
that
from
a
few
people,
I
think
that
that's
something
that
would
be
really
good
to
discuss
on
the
mailing
list
of
having
this
be
a
higher
level,
with
a
fallback
to
unencrypted
and
see.
If
that's,
if
that's
of
interest,
we
certainly
heard
the
other
from
other
people
as
well.
So
since
we're
about
two
minutes
before
we
have
to
shut
off
anyways,
I
want
to
be
clear
that
that
that
is
that
all
is
was
incorrect.
I
was
also
incorrect
about
us
not
taking
our
whole
30
minutes.
K
A
Yeah,
that's
a
good
point
paul
and
and
what
we
want
the
minutes
to
reflect
is
tim,
and
I
will
take
an
action
to
try
and
kick
off
discussions
on
on
some
of
these
points.
Once
we
we've
gotten
over
the
the
ietf
meeting,
and
we
can,
we
can
yeah.
K
And
the
big,
the
biggest
point
on
that
brian
would
be
which
are
new
use
cases
and
which
are
improvements
to
this
use
case.
A
Right
got
it
yeah.
Okay,
we
have
10
seconds
left
we're
going
to
reconvene
at
20
30,
so
you've
got
a
half
hour
for
your
various
caffeine
breaks
that
you
want
and
the
goal
will
be
to
discuss
the
next
two
presentation
items
and
then
use
the
rest
of
the
time
for
discussions
of
those.