►
From YouTube: IETF110-ADD-20210309-1430
Description
ADD meeting session at IETF110
2021/03/09 1430
https://datatracker.ietf.org/meeting/110/proceedings/
A
All
right,
we
have
a
scribe
and
I'm
assuming
that
people
can
watch
and
bring
their
own
issues
up
from
jabber.
We
don't
need
a
jabra
scribe,
so
if,
if
somebody
likes
to
would
like
to
monitor,
jabber,
though
feel
free
to
do
so
and
raise
your
hand
when
we
get
to
the
discussion
section,
so
we
have
a
pretty
full
session
today.
Let
me
just
go
ahead.
First
of
all,
I
want
to
make
everybody
aware
that
noteworld
does
apply.
This
is
an
official
icaf
meeting.
A
A
I
was
like
you
until
about
two
weeks
ago,
then
I
finally
got
the
chop.
So
there
is,
there
is
a
future
at
barbershop,
so
you
never
know
we
have
a
pretty
packed
agenda
today,
so
we're
in
the
first
five
minutes
here.
We've
done
our
jabless
drive
we've
done
about
well.
This
is
the
agenda
today.
We'll
have
two
sessions
this
week.
A
Different
than
we've
used
in
the
past,
so
we,
the
agencies,
always
thrive,
thrived
really
well,
when
given
the
opportunity
to
discuss
things
and
and
and
has
really
rejected
the
idea
of
being
sort
of
a
passive
listener
for
an
extended
period
of
time.
So
what
we've
done
now
with
these
two
adopted
working
group
drafts,
is
ask
the
the
editors,
the
authors,
to
pull
out
the
issues
that
they
need
to
raise
the
group
and
to
discuss
and
to
make
those
be
the
slides
to
get
presented
out.
A
And
so
the
format
we're
going
to
follow
today
is
a
very
interactive
one
where
at
each
slide,
issue
discussion
will
be
presented
and
we
will
open
up
the
mic
line
for
people
to
make
comments
on
that
issue
and
try
to
capture
them
and
then
once
that's
done
in
a
reasonable
amount
of
time.
We'll
move
on
to
the
next
slide
and
the
next
set
of
issues.
A
So
hopefully
that
works
out
really
well,
and
hopefully
we
have
enough
time
today
to
cover
all
this.
If
we
can't
carry
all
of
this
we'll
roll
whatever
is
remaining
from
today
into
the
beginning
of
the
thursday
session.
So
with
all
that
said,
does
anybody
have
an
agenda
bash
or
issues
they
want
to
bring
up.
A
A
Tommy
tommy,
tommy,
jensen,
okay,
sorry,
tommy
polly
has
sent
me
the
I
thought,
or
maybe
tommy
tommy's
in
plural.
My
apologies
for
getting
you
confused.
It's
so
much
easier.
We
can
see
real
people,
okay,
tommy
jensen.
The
floor
is
yours
and
then
after
you
do
a
slide,
are
you
ready
to
take
questions?
Tail
will
manage
the
cue.
B
D
D
D
B
D
E
E
B
D
So
issues
three
and
four
are
regarding
the
security
considerations.
One
being
concern
around
the
use
of
a
private
ip
address
is
as
a
security
mechanism.
We
need
to
clarify
that.
That's
not
the
case.
The
private
ip
address
identification
is
conducted
only
to
decide
when
to
enforce
same
address,
use,
meaning
that
if
a
private
ip
address
is
advertised,
then
we're
in
an
opportunistic
mode,
meaning
that
we
should
only
connect
if
we
are
connecting
to
the
same
ip
address
and
we
can
skip
the
name
certification
check.
D
B
E
D
E
B
E
F
E
I
you
know,
I'm
not
sure
that
I
can
summarize
this
all
okay,
you
know
in
a
nutshell
here,
except
to
say
we
we
just
need
to
be
very
clear
about
which
pieces
of
information
are
our
our
starting
points,
and
the
this
draft
has
a
few
different
modes.
Essentially,
I
think,
in
each
mode
we
just
need
to
be
very
clear
about
what
is
our
initial
identifier.
The
thing
that
we're
holding
on
to
that
tells
us
what
the
what
the
resolver
is,
and
then
you
know,
that's
the
only
thing
that
we
need
to
be
checking.
F
C
A
G
Hello
yeah,
so
I
think
you
know
we
definitely
should
iterate
on
this
and
clarify
things
to
give
a
concrete
example,
and
maybe
ben
or
wrecker.
If
you
want
to
comment
on
this,
the
thing
I'm
thinking
of
my
head
is
you
know,
let's
say
that
the
thing
I
start
with
is
that
the
user
typed
in
1.1.1.1
as
their
preferred
dns
server,
and
so
that's
the
only
thing
I
know
to
start
with
so
I'm
going
to.
G
If,
for
some
reason,
that's
going
to
point
me
somewhere
else,
I
want
to
validate
so
let's
say
it
points
me
to
a
v6
address
that
actually
serves
quad
one.
I
want
to
validate
that
you
can
cover
the
original
address
I
started
with,
but
also,
if
I'm
doing
do
here
and
you've
told
me,
hey
yeah,
you're
doing
https,
you
have
this
authority,
you
have
a
name
that
you're
actually
having
to
ask
for
cloudflare.dns.com
and
a
given
path.
G
It
would
seem
very
odd
to
tell
the
client
no
do
not
check
that
the
http
servers
tls
server,
that
you're
going
to
has
the
correct
name
in
the
authority
that
you're
using
in
your
http
request.
So
I
I
think
the
logic
here
is
that
you
know
you
cover
the
ip
address,
because
that's
the
original
identifier
you
started
with,
but
if
you
are
going
forward
and
making
http
requests
with
an
authority,
that's
a
different
name
or
doing
further
svcb
lookups
to
find
other
properties
off
of
the
dns
svcb
record.
H
And
now
you
have
to
ask
do
I
trust
this
certificate
for
the
name,
I'm
trying
to
contact,
and
that's
just
overall
general
thing,
and
so
in
this
case,
like
the
initial
name,
you're
trying
to
contact
would
be
the
ip
address,
as
I
think
both
ben
ecker
and
you
can
possibly
try
and
say
that
the
ip
address
is
going
to
be
the
authority
for
what
you're
doing
in
the
http
sense.
But
that's
not
a
great
fit,
and
you
know
what
tommy
paulie
said
makes
some
amount
of
sense.
H
But
I
think
that,
coming
at
this
from
the
model
that
6125
uses
in
terms
of
you
know,
I
have
a
connection
and
I
need
to
authenticate
that
connection
against
the
initial
identifier
I
used
to
to
start
making.
That
connection
is
going
to
be
pretty
valuable
here
and
if
we
want
to
maybe
also
do
other
stuff.
In
addition
to
that,
that
might
be
okay,
but
I
think
we
need
to
keep
in
mind
the
core
fundamental
model
of
authenticate.
The
initial
connection
I
tried
to
make.
D
Well,
I
didn't
know,
I
didn't
want
to
go
interrupting
people,
so
I
thought
models
everyone
else
to
to
highlight
what
tommy
said,
especially
in
the
comments
context.
There
are
two
pieces
of
identity
required
because
there
are
actually
two
different
identities
being
confirmed.
A
more
interesting
case
that
points
this
out
is
one
where
the
initial
dns
server
ip
address
and
the
referred
doe
server
ip
address
are
different.
D
D
I
need
to
make
sure
that
the
tls
certificate
can
claim
both
dozer.example
for
all
the
reasons
already
described.
That's
the
identity
of
the
server
I'm
trying
to
connect
to
that
information
alone
establishes
the
identity
of
the
destination
resolver.
But
the
other
thing
that
I'm
trying
to
confirm
is
that
this
resolver
was
expecting.
What
is
that
one
two
three
four
and
doe
server.example
are
cooperating
and
that
I
wasn't
hijacked
to
a
attacker's,
doze
server,
and
so
I'm
checking
for
one
two.
Three.
B
F
Right
so
I
think
we
had
a
bunch
of
discussion
in
the
jubber
so
maybe
like
it
will
have
people.
So
this
analogy,
I
think
there
are
two
ways
to
think
about
this.
This
indicator
this
svcp
indicator.
One
is
like
a
c
name,
and
the
other
is
like
a
302
and
in
a
c
name,
what
you
do
when
you
get
to
the
other
side,
is
you
spend,
as
you
expect
the
authority,
and
you
expect
the
certificate
to
match
the
original
thing
you
started
with
and
at
302.
F
F
If,
if,
if,
if
you
know,
if
you
started
with
1.1.1
and
then
it
got
bounced,
you
to
you,
know
cloudflare.cns.com
and
that's
what
you're
putting
in
like
the
host
center
in
the
url,
then
it's
like
super
goofy
to
not
check
the
stuff
for
that
that
that
seems
like
for
us
since
it'd
be
unfortunate.
So
I
think
maybe
that's
the
way
to
think
about
it
rather
than
a
certificate.
E
If
the
only
thing
that's
needed
is
to
is
to
put
the
ip
address
in
the
certificate,
then
we
have
a
relatively
straightforward
way
to
pass
this
information
across
to
an
http
stack
and
say
you
know:
here's
the
here's,
the
url
that
you're
supposed
to
connect
to-
and
you
know
here-
here's
a
url.
It
contains
an
authority
component,
that's
the
name
that
you're
checking
for
in
the
in
the
certificate.
E
If
we,
if
we
start
requiring
multiple
names,
then
it
gets
very,
it
gets
very
confusing.
It
no
longer
is
something
that
you
can
easily
plug
into
a
stock.
Https
client
stack-
and
I
do
think
that
you
know
this
is
there
is
a
close
analogy
here
to
the
way
that
we
use
cdns
generally,
you
know
we
do
not
ask
clients
to
when
they
follow
a
cname
record
in
the
dns.
We
do
not
ask
clients
to
validate
that.
C
I
G
All
right,
so
I
I
definitely
hear
the
point
that,
if
we
have
an
ip
address
would
be
sufficient.
I
think
if
that
is
the
case,
and
that's
all
you
are
validating,
I
think
we
would
want
to
say
that
for
the
case
of
dough
and
everything
else,
you
would
have
to
treat
the
authority
for
hp
purposes.
As
the
ipa
address.
G
Definitely
acceptable,
I
think
perhaps
we
could
go
with
the
solution
of
saying
yeah
from
the
ddr
perspective.
The
only
thing
you
absolutely
need
is
the
ipa
address,
but
then
have
an
addendum
that
says
if
you
want
to
use
an
authority,
that
is
the
name
that
you
learned,
then
you
must
also
validate
that
before
using
that
name
as
an
authority
or
using
it
for
future
operations
for
a
very
simple
case
in
which
there's
a
pretty
one-to-one
mapping
between
these
things,
it
doesn't
matter,
I
could
imagine
a
case
in
which
perhaps
we
have
different.
G
G
The
stack
has
a
list
like
some
stacks.
Do,
I
think
you
know
firefox
and
microsoft
currently
do
of
names
of
resolvers
that
they
have
preference
for
or
that
they
already
know
they
trust.
If
I
saw
an
address
that
said,
oh
yes,
I
actually
am
designating
over
to
one
of
these
names
that
you
already
do
trust.
G
J
Yeah
tommy
actually
just
made
most
of
the
point.
I
was
about
to
make
myself
but
yeah
a
lot
of
these
cases
where
the
one
the
one
case
where
I
can
think
of
where
it
would
be
useful
to
clients
to
have
this
name
is
if
the
clients
want
to
say
refer
to
a
white
list
of
names
they're
willing
to
upgrade
to
and
such
they
need
to
be
able
to
make
sure
this
is
the
thing
that
matches
our
white
list
for
the
most
part,
this
doesn't
seem
like.
J
It
applies
to
the
general
case
for
the
most
part,
if
you
want
to
use
a
white
list
of
known
things
well,
then
you
can
also
use
your
same
list
for
auto
upgrading,
like
a
lot
of
clients
are
doing
today,
so
that's
kind
of
like.
Why
would
you
be
using
ddr
if
you
want
to
do
that,
but
I
could
kind
of
imagine
there
might
be
cases
where
clients
might
optionally
want
to
do
checks
like
that.
So,
in
the
very
least,
I
think
it's
very
reasonable
to
say
optionally.
J
B
D
Thank
you,
everyone.
That
was
pretty
helpful,
so
I
will
update
the
issue
with
the
discussion,
but
we
need
to
move
forward
so
we'll
take
the
rest
to
list
in
github
issues,
numbers
six
and
seven
deal
with
the
special
use
domain,
name
and
forwarders.
This
is
pretty
straightforward.
We
plan
to
revise
the
document
to
highlight
that
resolvers
should
only
ever
answer
queries
for
themselves
and
otherwise
should
always
return
annex
domain.
D
There
is
an
asterisk
there
for
the
special
case
where
you
may
have
a
100
blind,
forwarder
and
one
may
choose
to
forward
the
s
vcb
record
from
upstream,
but
will
include
verbiage
that
calls
out.
The
implementer
should
be
aware
that
this
will
likely
result
in
client
authentication
failure
unless
the
certificate
can
claim
the.
I
p
address
of
the
blind
forwarder
as
well.
E
Ben
please,
so
this
is
a
fundamental
scope
question.
I
think
that
this
really
is
of
general
interest
to
the
add
group,
because
the
the
question
is:
do
we
want
to
try
to
enable
encrypted
dns?
Do
we
want
to
try
to
at
least
make
it
possible
for
clients
to
do
encrypted
dns
through
legacy
customer
equipment?
E
E
Can
I,
or
can
I
not
get
an
encrypted
dns
connection
to
my
isp
without
having
to
replace
my
access
point?
There
are.
I
know
there
are
a
lot
of
people
in
this
working
group
who
believe
that
that's
an
important
use
case
that
they
want
to
enable
I've
heard
a
lot
of
demand
for
that,
and
we
need
to
be
really
clear
that
the
draft
currently
does
not
enable
that
use
case
it.
It
does
not
support
upgrade.
D
So
I
believe,
we'll
touch
on
this
in
the
next
slide.
I.E
the
scope
of
the
draft
agreed
that
the
issue
definitely
exists
and
I
I
will
say
it
is
important
as
written
as
you
say,
that
scenario
is
out
of
scope
because,
right
now
we
don't
see
a
path
forward
that
would
allow
that
to
be
secured.
Having
said
that,
I
know
you
and
others
feel
differently,
and
so
that's
a
point
of
discussion,
but
right
now
we
should
definitely
clarify
until
future
text
is
added
that
that
scenario
is
specifically
out
of
scope.
D
So
the
final
pair
of
issues
on
github
are
eight
and
nine,
which
talk
about
document
scope.
We
should
specify
when
local
forwarders
represent
upstream
resolvers,
and
why
is
the
special
use
name
necessary
for
opportunistic
scenarios,
so
the
clarifications
we're
proposing
in
the
document
are
local
forwarders
designating
upstream
revolt
resolvers
is
out
of
scope
asterisk
unless
that,
unless
the
recommended,
doe
resolver
can
in
fact
claim
the
identity
of
the
local
forwarder.
D
But
the
point
is
the
everyday
scenario
here
that
can't
be
true,
because
a
local
forwarder
is
a
local
ip
address,
the
need
for
resolver
metadata
in
the
opportunistic
case.
The
reason
we
need
the
special
use
domain
name
is
so
that
we
can
retrieve
things
like.
Do
you
use
a
non-default
port
number,
the
name
to
be
used
in
the
cert
checking,
although
that
references,
the
issue
we
were
discussing
earlier.
C
J
Sort
of
continuing
the
discussion
of
ben's
argument
and
his
talking
about
his
previous
proposal,
I
don't
remember
exactly
what
the
proposal
was,
but
I
kind
of
recall
that
yeah,
it's
kind
of
in
the
gray
area,
that's
might
be
okay
for
some
clients,
desires
for
security
properties
and
not
for
others,
and
obviously
it's
obvious
again.
I
don't
remember
the
exact
proposal
that
well
so
this
might
be
something
to
examine
further,
but
I
think
maybe
we
should
make
it
the
case
that
we
just
call
it
as
optional.
J
B
D
Sorry,
please
go
on
tommy
sure,
so
this
is
an
interesting
proposal.
Let
the
other
authors
speak
for
themselves.
My
position
on
this
is
that
the
existing
proposal
is
likely
to
have
better
adoption,
given
the
rollout
of
dns
sec
compared
to
the
reliance
on
pki
in
a
nutshell,
but
certainly
what
you're
proposing
is
possible.
B
B
M
A
M
M
To
the
I
would
say
the
discussion
on
the
mailing
list,
because
we
don't
we
didn't,
want
it
to
to
interfere
with
the
call
for
adoption
for
itself
and
to
bring
more
technical
discussion
on
it,
but
we
didn't
close
that
and
we-
and
this
is
stored
on
the
I
would
say,
on
the
on
the
tracker
itself.
In
this
presentation
we
will,
I
would
say,
we'll
focus
on
one
of
the.
I
would
say
on
the
issues
that
I
would
say
triggered
more
discussion
on
the
list.
M
It
was,
I
would
say,
a
comment
from
from
from
then
it's
basically
to
say
that
yeah,
we
need
to
largely
write
the
the
document
so
that
we
we
are
moniz
with
the
what
the
ddr
is
in
our
are
doing
so
in
the
next
slide.
We'll
explain
in
order
to
assess
the
I
would
say
this
issue.
We
need
first
to
understand
what
are
the
information?
M
What
is
the
information
that
we
are
discovering
in
the
in
the
dinner
specification
so
that
to
be
sure,
if
there
is
really
something
to
be
written
or
if
that
is
true,
so,
as
you
can
see
in
these
slides,
we
it
it's
really.
The
the
information
that
we
are
discovering
here
are
really
minimal.
That
means
that
we
are
not
discovering
a
lot
of
information,
only
the
required
information
to
establish
a
connection
with
with
a
server
and
that
that
that
information
is
an
authentication
domain
name
and
also
a
list
of
ip
addresses.
M
The
list
of
ip
addresses
and
the
an
alternate
port
number
are
really
important
because
we,
as
we
explained
in
the
next
slide,
we
we
need
to
avoid,
I
would
say
probing
and
also
we
need
to
to
avoid
falling
into
to
the
legacy
dns,
because
otherwise
we
we
will,
we
will
be
inducing
other
security
constraints
into
the
the
the
proposal
and
we
want
to
to
master
and
to
control
the
information
that
you
will
convene
directly
using
the
dhcp
and
there
are
option
next.
Thank
you.
F
What
like,
when
we
discussed
adoption
in
this
craft,
I
think
there's
pretty
strong
consensus
that
we
should
not
attempt
to
reinvent
the
information
model.
Why
aren't
you
just
basically
putting
an
svcp
record?
I
mean
not
unsure.
How
do
we
encode
in
some
different
profession,
but
like
the
same
information,
is
what
you
need.
So
why
aren't
you
simply
why
we
can't
why?
Why
don't
we
simply
define
a
common
piece
of
information
and
shove
it
in
both
places.
M
Yeah
that
that
that's
one
option
to
do,
but,
for
instance,
in
if
you,
if
you
refer
to
to
ddr
the
need,
for
instance
and
name
in
order
to,
I,
would
say,
to
to
ignite
all
the
the
discovery
process
and
here
in
the
in
the
specification,
we
are
providing
a
means
to
provide
this
this
name.
So
that's
why
we
have,
I
would
say,
an
option
to
to
convey
to
you
and
a
name
so
that
you
can.
You
can
ignite
your
discovery
process.
M
F
M
Yeah
that
that's
true
for
the
I
would
say
for
the
the
list
of
ip
addresses
and
the
for
the
pert
number,
and
this
is
what
I'm,
what
I
was
explaining
in
the
I
would
say
on
the
next
slide
in
which
we,
in
a
previous
version
of
this
specification,
we
had
only
the
name,
the
authentication
address
name
and
that
authentication
address
name
you
can,
you
can
use
directly,
I
would
say
the
svcp
in
order
to
return
the
last
of
your
ip
addresses
and
the
internet
port
number.
That's
something
that.
M
Stuff
in
svcb
in
the
ipedus
and
the
port
number,
yes,
I
know-
and
this
is
an
issue
that
we'll
discuss,
I
would
say
in
one
of
the
of
the
slides
here
in
the
presentation
here.
We
are
just
explaining
why
we
are
just
restricting
ourselves
to
the
minimum
set
of
the
information
that
needs
to
establish
the
the
connection.
F
B
B
M
Yes,
so
so,
as
I
mentioned
earlier,
so
once
you
discover
your
name
and
you
would
say
the
the
list
of
api,
this
is
on
the
internet
port
number.
Then
you
can
use,
I
would
say
what
is
defined
in
the
in
dddr
document
in
order
to
retrieve
additional
information
from
from
from,
I
would
say
from
from
from
the
server
next
slide.
M
M
E
I
recognize
that
this
costs
some
small
number
of
round
trips,
but
this
is
a
this
is
only
on
network
association.
It's
not
like
a
delay
that
you
know
there
shouldn't
be
a
long
delay,
we're
talking
about
round
trips
to
the
local
resolver.
So
these
these
you
know
these
round.
Trips
should
be
fast
and
we're
not
talking
about
a
delay
that
occurs
on
every
page
load
or
something
it's
only
at
the
time
when
you're
connected
to
the
network.
E
E
If
that
information
is
all
being
hard
coded
into
dhcp
answers
that
are
being
handed
out
to
users
from
customer
devices,
then
they
have
to
actually
get
all
of
those
customer
devices
configuration
updated
first
before
they
can
change
their
resolver
configuration.
So
it
takes
the
details
of
resolver
configuration,
puts
it
farther
and
farther
away
from
where
the
resolver
is
keeping
those
together
is
has
operational
value.
I
think.
E
Is
too
much
of
a
concern,
then
I
would
maybe
optionally
for
people
who
really
care
about
this
performance.
Optimization
say
that
what
you
do
is
you
take
the
entire
dns
response
that
you
would
have
gotten
from
ddr
all
the
different
rr
types,
not
just
service
b,
but
whatever
you
know,
address
records
whatever
it
is
that
you
would
have
gotten
through
the
ddr
process
and
you
package
it
all
up,
and
you
include
it
all
inside
the
dhcp
option.
E
D
On
the
other
hand,
using
dnr
allows
the
network
to
use
protections
for
dhcp
and
ra,
as
discussed
in
the
draft
that
can
protect
against
attacks
on
those
technologies
without
necessarily
needing
to
have
something
similar
for
dns,
which
is
the
case
today.
Those
technologies
exist
for
dhcpra,
where,
and
so
we
protect
against
attacks
on
the
dns
is
another
reason
why.
E
Sorry,
I'm
gonna
just
jump
in
and
respond
and
say
I
don't.
I
I'm
talking
about
the
ddr
section,
5
discovery
using
resolver
names
mechanism
and
that
mechanism
doesn't
rely
on
any
security
properties
of
the
insecure
dna,
because
the
the
resolver,
the
ultimate
resolver,
is
authenticated
back
to
the
the
original
name
that
was
provided.
Then
it's
a
named
resolver,
so
a
dns
can't
do
anything
except
deny
you
service,
which
they
could
do
anyway.
G
G
That's
one
area
where
we
really
want
to
see
kind
of
alignment
here
of
wherever
that
document
goes
forward
and
again,
I
think
it'd
be
a
lot
cleaner
to
just
have
a
name
there
and
allow
the
rest
of
it
to
work.
And
when
we're
doing
this,
we
need
to
think
of
the
precedent
we're
setting
if
we
go
with
just
a
name
that
always
points
to
a
dns
record.
That
has
all
the
details.
G
G
F
Things
to
say,
we
just
didn't
hear
them.
I
think
tom's,
making
a
good
point
here.
I
guess
I
would
say
like
it
seems
to
me
that
there
are
two
coherent
positions.
One
is
like
just
have
a
name
and
then
do
ddr
basically
and
the
other
is
stuff
all
the
information
of
ddr.
I
think
what
is
problematic
is
the
compromise
position,
the
second
half
this
draft,
the
second
half
of
the
slide
above,
where
it's
like
here's
some
of
the
information,
but
not
enough
to
actually
do
the
job
that
seems
goofy.
F
B
C
B
M
I
I
think
I
am
hearing,
I
would
say
the
the
the
comment
we
are
receiving
and
yeah.
This
is
actually
that's
something
that
we
had
in
the
past
that
we
considered
we
started
only.
I
would
say
we
with
one
option
and
then
we
completed,
as
I
would
say,
as
the
working
group
is
progressing
on
the
on
the
security
assessment
part
we.
M
What
the
what
we
were
hearing
from
the
working
group
is
that
the
the
work
is,
as
I
would
say,
is,
is
really
a
sensitivity
to
the
attacks,
both
the
internal
one
and
the
I
would
say
the
external
ones,
so
that
that's
why
we
we
have
added.
I
would
say
this,
the
the
list
of
ip
addresses
to
be
directly
communicated
by
the
dhcp,
because
we
we
thought
that
at
least
we
solved
the
the
external
attack
and
there
is
only
the
room
for
from
from
the
international,
so
yeah.
M
M
What
we
have
so
far
in
the
document
is,
it
is
recommended
to
to
return,
I
would
say
the
name
and
then
you
can
return
directly
the
list
of
ip
address,
but
if
there
is
no
list
of
ip
addresses
that
are
returned
by
the,
I
would
say
by
the
server
to
to
to
the
client,
because
this
is,
I
would
say,
a
decision
by
a
local
deployment.
We
have
a
discussion
in
one
of
the
slides
that
you
can
you
we,
if
you
can
just
please
move
to
not
do
number
eight.
Please.
M
M
But
then
the
question
for
us
is
what
we
will
do
with
that
that
domain
name
should
we
just,
I
would
say,
use
the
the
list
of
the
legacy
dns
server
and
then
the
establish
your
authentication
connection
and
go
on
or
you
just
rely,
the
I
would
say
the
name
to
to
using
the
svcb
and
then
do
the
job.
So
this,
I
would
say,
there's
a
lot
of
trade-offs
there.
There
are
some,
I
would
say
some
parent
codes
we
so
yeah.
M
I
I
E
Hi,
so
I
wanted
to
try
to
answer
tyro's
question
about
dns
tech.
So
if
you
look
at
ddr
section,
5
you'll
see
that
it
it
specifies
how
to
connect
to
a
server
using
the
ddr
method.
When
you
start
with
an
authentication
name,
and
the
key
thing
is
that,
regardless
of
of
whether
the
dns
records
that
you're
using
along
the
way
were,
were
valid
or
were
in
fact
forged
when
you
finally
reach
the
server
you
do
tls
and
you
you
do
authenticated
tls
and
authenticate
it
back
to
its
name.
E
On
the
question
of
how
to
move
ip
addresses
around,
which
has
been
touched
a
couple
of
times,
the
thing
that
makes
sense
to
me
is
to
say
you:
you
can
just
take
a
and
quad
a
records,
and
if
you
have
a
if
each
res
named
resolver
is
associated
with
a
bag
of
records,
then
you
can
put
some
a
and
quad
a
records
in
that
bag.
Now
we
know-
and
we
know
the.
E
C
Yeah,
hey,
hey
ben!
I
got
your
point.
There's
no
point
that
the
tls
certificate
authentication
will
fail
if
an
attacker
modifies
it,
but
the
bigger
problem
is,
for
example,
if
the
client
prefers
to
use,
let's
say
doq
and
it
doesn't
support
others,
and
if,
if
the
attacker
strips
the
other
to
that
protocol
that
the
client
supports,
then
the
client
will
never
be
able
to
pick
that.
C
So
there
are
threat
vectors
possible
that
if
you
don't
use
dnsec,
then
the
client
would
be
forced
because
he
realizes
the
server
is
supporting
something
like
a
new
protocol
and
it
has
no
support
for
it
and
it
just
gives
up
right.
So
the
the
attack
modifying
the
dns
response
need
not
be
to
point
to
a
malicious
server.
It
could
be
just
to
show
some
properties
of
the
server
that
the
client
beams
it's
incapable
of
connecting
to
and
just
gives
up
right.
B
Thank
you
and
muhammad.
We
will
continue
in
our
next
adv
session
and
before
I
turn
it
over
to
glenn
for
the
wrap-up.
I
just
want
to
say
thank
you
very
much
to
chris
lemons
for
his
heroic
effort
in
keeping
up
with
all
this
note-taking
fantastic
job
tremendous
help
for
for
us
as
a
working
group.
Thank
you.
A
And
just
as
a
final
wrap-up
next
session
will
be
on
thursday
at
12
new
gmt,
I've
been
told
that
there
are,
there
is
no
coffee
and
there
are
no
cookies
in
the
lobby
currently.
So
if
you
need
those
things
you're
on
your
own,
somehow
we
didn't
get
them
provisioned
in
time.
So
thank
you
and
we'll
see
you
on.