►
From YouTube: IETF109-ADD-20201116-0730
Description
ADD meeting session at IETF109
2020/11/16 0730
https://datatracker.ietf.org/meeting/109/proceedings/
A
A
C
A
C
E
A
I'll
mention
also
that,
while
glenn
is
still
doing
this,
if
anybody
is
not
microphone
enabled
and
would
like
to
bring
something
to
the
mic,
it's
easy
enough
for
me
to
just
jab
rescribe
without
having
to
find
another
volunteer
to
do
it.
So
I'll
keep
an
eye
on
chat,
and
if
you
preface
your
line
with
mike,
I
will
know
that
this
is
something
you
want
said
to
the
group.
C
C
C
There's
a
bunch
of
material
in
this
zero-zero
draft,
which
will
talk
about
the
concept
of
equivalent
resolvers,
which
is
something
that
was
introduced
by
draft
box,
add
requirements.
So
what
we'll
do
is
we'll
do
the
presentation
by
tommy
and
then
we're
do
some
basic
questions,
but
the
meat
of
it.
This
concept
of
equivalent
resolvers
will
have
as
a
separate
discussion
after
that
draft
is
presented
and
that
will
probably
take
most
of
the
hour
and
then
we'll
have
a
very
quick
at
the
very
end.
C
C
C
F
Thank
you
all
right.
So
what
I'll
be
sharing
today
is
a
a
simplified
proposal
that
some
of
us,
the
authors
listed
here
on
the
slide,
have
worked
on
since
our
previous
interim
meeting
and
we've
called
this
proposal
dear
the
discovery
of
equivalent
encrypted
resolvers,
and
this
is
largely
reflecting
the
scope
that
the
working
group
seemed
to
want
to
take
based
on
our
interim
meeting
discussions
of
saying,
let's
just
have
a
very
simple
use
case
in
which
we
want
to
discover
the
actually
equivalent
encrypted
resolver
for
a
network.
F
Given
that
I
already
know
an
address,
as
the
chair
is
mentioned,
we'll
need
to
go
into
more
details
on
what
equivalent
really
means
and
what
are
the
guarantees
we
get
from
that?
Does
it
actually
give
you
any
security
properties
or
any
trust
properties
or
not,
but
this
proposal
hopefully
can
give
some
concrete
details
that
help
us
think
about
one
way
that
this
discovery
mechanism
can
work
next
slide.
Please.
F
All
right,
so
what
are
equivalent
resolvers
and
that's
again,
something
that
needs
to
be
discussed,
the
way
that
we
initially
defined
it
here.
We
essentially
had
two
options
and
we
talk
about
how
to
address
both.
One
is
when
there's
a
very
simple
case
in
which
I
have
another
dns
protocol,
that's
available
on
the
same
ip
address
on
the
same
server.
F
All
right,
so,
in
this
draft
we
define
two
different
use
cases
that
we're
trying
to
enable
discovery
of
encrypted
resolvers,
for
the
first
case
is
when
you
already
have
an
ip
address
of
a
resolver
generally,
a
unencrypted
dns
overport
53
resolver,
and
you
want
to
discover
what
is
the
one
or
multiple
equivalent
encrypted
resolvers.
I
can
access
for
this,
and
this
address
could
come
from
a
network,
provisioning
protocol
or
be
typed
in
manually.
F
F
F
So
for
the
first
use
case
when
we
have
an
ip
address-
and
we
essentially
just
want
to
upgrade
from
unencrypted
dns
to
encrypted
dns,
the
ip
address,
as
I
mentioned
before,
can
be
provisioned
a
number
of
different
ways.
It
can
come
from
the
network,
such
as
over
dhcp
or
ras.
It
can
come
from
a
vpn
protocol.
It
can
be
entered
manually
by
the
user.
F
Each
of
these
different
use
cases
of
these
different
provisioning
mechanisms
has
different
trust
properties.
Maybe
maybe
you
trust,
dhcp
and
ra.
Maybe
you
have
ra
guard
on
your
network,
but
there's
not
a
lot
of
user
trust
in
who
really
is
this?
That's
provisioning
that
information,
oftentimes,
a
vpn
or
a
user
entered
value
may
be
different,
and
that
may
be
something
that
we
have
more
trust
in,
and
so
some
of
the
guarantees
that
we
get
from
upgrading
discovery
could
be
stronger
for
this
approach.
F
The
draft
defines
sending
a
query
for
a
special
use
domain
name.
It
proposes
result
reserving
something
like
resolver.arpa
so
that
you
do
a
query
for
dnsresolver.arpa
and
you
can
get
from.
So
you
send
that
query
to
the
address
of
your
normal
dns
over
53
server,
so
I
can
send
a
query
to
quad
8.
Let's
say
for
this
special
use
domain
name,
and
it
could
send
me
in
the
response
one
or
more
answers
for
equivalent
resolvers,
which
will
present
the
different
protocols
that
this
resolver
supports.
F
F
The
draft
recommends
that
this
mode
only
be
used
when
the
ip
address
of
the
encrypted
resolver
is
identical
to
the
one
of
the
unencrypted
resolver,
so
that
essentially
it
is,
as
far
as
you
know,
the
same
entity
that
you're
talking
to
this
is
a
you
know.
I
want
to
use
encrypted
dns
because
I
think
it's
better
than
nothing,
but
it's
not
proving
anything
about
how
much
you
should
trust
that
entity
other
than
saying
it
looks
like
the
same
person
you
would
have
been
talking
to
anyway.
F
So
the
other
use
case
is
discovery
using
a
known
name.
You
may
already
know
a
resolver
name
in
for
a
couple
different
reasons:
one
we
may
be
defining
new
mechanisms
to
provision
a
resolver
name.
You
could
add
the
name
of
the
resolver
to
dhcp
ras.
It
could
be
in
a
pvd.
It
could
be
in
a
vpn
configuration
item
if
we
go
down
this
road.
F
The
name
could
also
be
something
that's
entered
manually
being
able
to
enter
a
resolver
name
may
be
simpler
than
having
a
user
type
in
a
full
doe
uri
template.
It's
also
an
interesting
use
case.
If
you
have
an
encrypted
resolver
that
you
know
about,
but
you
can't
access
it.
So
maybe
the
ports
for
dot
are
blocked,
but
you
want
to
discover
if
there's
an
equivalent
do
resolver
when
you
only
had
dot
configured
before
next
slide.
Please.
F
So
in
this
case,
we
don't
use
the
special
use
domain
name,
but
instead
we
can
simply
do
a
query
for
the
resolver
name
that
we
already
knew
about.
So
this
is
really
just
using
benchworth's
document
kind
of,
as
is
but
explaining
kind
of
how
it's
used
in
this
deployment,
and
in
this
case
the
certificate
must
cover
the
originally
known
name
in
general.
That's
going
to
be
the
same
thing,
but
it's
possible
that
let's
say
a
dot
server
has
a
slightly
different
name
than
the
dos
server.
F
A
F
Okay,
so
let's
say
I
know
well,
okay,
so
I
I
know
like
a
dns.google
for
dot,
I
learn
about
it's
dope
properties.
I
connect
to
dns.google
with
dough.
Now
I
in
that
case
it
sounds
like
that's
an
attack
that
could
happen
regardless
of
the
discovery
mechanism
that
just
trying
to
reach
out
to
the
dns
server
by
name
the
encrypted
dns
server
by
name
has
that
problem,
regardless
of
any
extra
discovery,
if
it
wasn't
already
with
a
hard-coded
ip
address,.
H
It
takes
a
little
while
isn't
it
so
I'm
I'm
really
not
very
clear
on
why
you
have
multiple
reference
identities
when
you
or
when
you
seem
to
have
a
clear
reference
identity.
So
if
you've
discovered
something
through,
for
instance,
dhcp
and
the
dhcp
is
giving
you
an
ip
address,
then
you
look
for
an
ip
address
and
right
and
that's
all
you
need.
If
you've
got
dns.google,
then
you
look
for
dns.google
in
the
certificate
and
that's
all
you
need.
The
draft
seemed
to
say
something
about
multiple
reference
identities
and
that
was
very
confusing.
F
You
would
be,
let's
say:
yeah
you,
the
dcp
gives
you
quad
8,
you
look
up
quad
8
and
it
says
I
have
a
do
resolver,
which
is
dns.google.
Dns
query.
I
think
it's
just
kind
of
by
default.
Your
sound
should
cover
the
name.
That's
in
the
uri
like
if,
if
the
uri
you're
accessing
has
a
name
in
it,
you're
validating
that
anyway,
and
in
addition
you
should
validate
the
ip
address.
I
think
maybe
we
should
kind
of
clarify
the
language.
Please
yeah,
that's
all
I
was
trying
to
say:
okay,
yep.
B
People
hear
me
now
all
right
now
we
can
yes
yep.
Okay,
great
sorry,
let
me
check
it
so.
The
first
question
is,
I
mean
we
are
you're
talking
about
the
discovery
of
a
resolver,
but
it
is
often
the
case
in
today's
world
that
people
have
configured
more
than
one
resolver
and
one
might
be
upgradable
and
the
other
not
is
there
any.
B
I
mean
how
do
you
want
to
handle
that
that
case
and
the
second
question
is
the
I
mean
private
ip
addresses
we,
we
can't
kind
of
have
certificates
about,
but
it
is
a
very
common
use
case
now.
If
I
read
the
draft
correct,
it
is
kind
of
okay
for
it
to
just
do
kind
of,
for
instance,
dot
853
without
checking
the
ip
address.
Is
that
correct?
On
my
how
I
understand
it.
F
To
your
first
question
about
multiple,
I
I
think
that
goes
more
into
how
the
client
would
end
up
using
this
information
in
presence
of
having
something
upgradable.
So
I'm
not
we
don't
get
into
that
here.
I'm
not
sure
if
we
should
get
into
that
we're
just
talking
about
the
mechanism
and
for
the
private
ipa
address
space.
The
kind
of
one
thing
we
allow
for
in
that
is
the
opportunistic
mode
which
says,
if
you
can,
if
you
manage
to
host
the
same
resolver
on
the
the
encrypted
resolver
on
the
same
ip
address.
F
I
Hi,
so
I
wanted
to
talk
about
ecker,
interesting
observation
that
an
attacker
in
the
network
could
redirect
your
encrypted
stream
in
order
to
in
order
to
make
your
apparent
client
ip
different
from
the
vantage
point
of
the
server
that
you're
talking
to.
Even
if
you
have
an
authenticated
connection
to
the
server.
I
So
I
think
that's
that's
an
interesting
and
novel
observation,
but
I
think
that
we
should
declare
it
out
of
scope,
and
my
reasoning
is
that
client
ips
are
not
validated
in
tls,
so
that's
a
security
property
of
the
secure
transport
that
https
inherits.
For
example,
the
whole
web
has
the
same
problem
and
dns
over
tls
inherits
because
it
uses
tls
and
dns
for
htdps
inherits.
I
I
And
more
generally,
the
the
same
ip
restriction,
I
think,
is
really
interesting,
and
I've
said
this,
I
think,
on
the
list,
but
I
think
that
the
same
ip
restriction
is
is
based
on
a
threat
model
that
I
haven't
quite
heard
stated
precisely
and
that
I'd
like
to
get
stated
precisely
somewhere.
I
think
this
goes
to
our
next
segment
discussion
about
what
equivalence
really
means.
So
I'd
like
to
think
some
about
that.
My
suspicion
right
now
is
that
this
comes
down
to
a
transient
to
persistent
attack,
upgrade
concern.
A
H
E
Hi
david
scanasi,
can
you
hear
me?
Yes,
we
can
it
works
cool,
so
I
was
wondering
and
it's
kind
of
a
10
000
foot
question,
but
one
when
our
team
on
chrome
was
you
know,
is
working
on
dough.
One
of
the
what
the
techniques
we
use
is
kind
of
like
auto
upgrading
to
the
same
ip,
and
one
of
the
main
feelings
of
that
technique
is
that
the
majority
of
users
have
conf
or
are
configured
with
a
dns
resolver.
That's
you
know
in
1918
space,
pretty
much.
E
F
E
So
I
wanna
my
point
is
that
they're,
not
the
great
majority
of
users
on
this
planet
have
a
router
that
they
don't
update
the
firmware
for,
and
so
that's
not
going
to
get
encrypted
dns,
and
so
is
that
a
problem
that
you're
not
trying
to
tackle
and
if
that's,
not
a
scope,
that's
totally
fine.
I'm
just
trying
to
make
sure
what
the
bounds
are.
F
Right
it,
it
is
not
something
that
we
think
has
a
clear
solution
that
doesn't
open
up
another
attack.
There
are
certainly
ways
that
you
know
we
can
update
those
networks,
but
it
is
possible
that
there
are
going
to
be
certain
routers
that
if
they
don't
update-
and
they
you
know,
don't
let
certain
options
be
passed
through,
that
you
will
not
be
able
to
just
upgrade
them
to
the
equivalent
one
without
having
some
other
provisioning
of,
like
the
name
that
you
should
be
using
for
that
network.
Customer.
E
E
G
Yeah,
so
I
I
actually
think
this
mechanism
is
fighting
with
that
a
little
bit,
so
I
mean
the
the
semantics
of
your
opportunistic
right.
Are
you
say
please
go
to
ip
blah
and
if
I
people
happens
to
match
the
ip
you
have
the
resolver.
The
mission
accomplished
you
upgrade
right,
but
the
solution
that
david's
talking
about
which
is
quite
a
common
situation,
is
where
the
the
client
knows
one
ip
and
the
server
is
unaware
of
that
ip.
G
F
G
Stop
you
they
just
don't
care
right,
right,
yeah,
they're,
trying
to
stop
you
like
game
over
right,
but
yeah
I
mean,
I
think
the
interesting
question
to
ask
is:
is
there
some
mechanism,
I
think,
as
david
says,
is
there
a
mechanism?
Where
is
there
some
set
of
cases
where,
in
the
what
you
have
is
basically
a
a
pretty
dumb
forwarding
resolver
to
one
of
the
large
you
know
to
one
of
the
large?
G
F
When
we
talk
about
the
definition
of
equivalency,
I'm
wondering
like.
Is
it
true
that
they
would
be
equivalent
to
whatever
it
is
because
if
they
are
a
forwarder
that
is
technically
intercepting
the
messages,
they
often
do
some
level
of
filtering
or
they
have
some
extra
override
for
showing
you
the
page
of
your
router
when
you
load
on
the
page
and
skipping,
it
would
change
it.
So
it
kind
of
out
by
definition
of
this
really
is
the
same
resolver,
and
if
you
want
something
that
is
equivalent,
you
need
to
change
your
original
resolver.
G
G
F
G
J
A
A
A
H
It
is
that
it
tells
you
to
do
and
we're
done
here,
because
what
we're
looking
at
here
is
a
case
where
you
don't
have
a
reference
identity.
Necessarily
it
does
mean
that
you
don't
get
any
of
the
properties
that
we
might
be
interested
in
terms
of
being
able
to
rely
on
the
dhcp
or
ra,
providing
something
that
we
might
trust
with
scare
quotes,
but
I
think
it
gets.
It
gets
a
lot
of
what
we're
kind
of
looking
for
in
the
end.
H
H
You
don't
have
a
reference
identity
in
that
case
right
and
then
the
question
is
what
what
name
do
you
go?
Go,
looking
for
and
and
that's
a
little
bit
challenging,
but
you've
already
started
out
in
in
completely
insecure
context
with
no
nobody
or
trust
in
anything.
So
I
don't
know
it's
even
weaker
than
that
than
the
other
model,
where
you
accept
that
the
dhcp
is
is
secure,
but
it
could
work.
F
F
F
A
Thank
you,
martin.
One
of
the
things
I'll
note
is
that
we
are
40
minutes
into
our
60
minute
session,
and
this
has
been
a
really
good
conversation
and
there's
still
a
couple
people
in
the
queue
and
could
well
be
another
couple.
While
we
did
have
another
item
on
the
agenda
about
talking
about
resolver
equivalence.
A
E
Hey
david
snazzy,
again,
chrome,
so,
first
off,
I
want
to
answer
edgar's
question
about
numbers,
so
these
are
numbers
collected
by
eric
horth
on
chrome.
Apparently,
what
chrome
sees
worldwide
is
only
15
of
users
have
non-private
addresses
configured
for
their
dns,
so
85
of
users.
The
vast
majority
of
the
internet
is
configured
with
a
1918
dns
resolver,
so
whatever
wi-fi
router
you
bought
10
years
ago,
that's
your
dns
resolver.
E
Another
stat
that
could
be
interesting
to
focus
is
of
those
15
half
of
them
map
to
known
dos
servers
like
quantitate
and
so
forth.
So
all
this
to
say
like
we,
it
sounds
like
we're
building
a
solution
for
an
incredibly
small
minority
of
users,
and
that
sounds
like
not
necessarily
the
first
priority
to
me.
I
I
want
to
also
second
like
what
mt
was
saying
you
could
make
this.
E
You
know
parts
of
this
work
by
using
queries
that
go
through
your
cheap
old
router
to
some
to
something
that
might
understand
them
in
the
isp
network.
If
the
isp
is
willing
to
stand
up
dough,
my
personal
two
sense
is
that's,
even
if
that's
not
properly
vetted
and
trusted
it's
still
better
than
what
we
have
today,
where
everything
is
in
the
clear,
so
maybe
kind
of
weakening
the
security
model
here
might
improve
user
security.
F
Yeah,
that's
good,
and
thanks
for
the
stats
on
that,
that's
very
useful
to
have
you
know
one
option
that
also
comes
to
mind
is
we
can
have
potentially
different
recommendations
for
what
to
do
when
we
have
1918
addresses
essentially
allow
more
goosey
opportunistic
upgrade
when
you
have
a
private
address
that
you
know
can't
be
authenticated
versus.
If
someone
has
configured
quad
one
or
quad
eight
and
making
sure
that
that
cannot
be
attacked.
I
Hey
so
ben
schwartz,
so
I've
heard
a
few
different
suggestions
of
ways
that
you
could
potentially
key
loosening
of
the
matching
requirements
in
opportunistic
mode.
So
I
heard
something
about
match
keying,
that,
on
the
basis
of
whether
the
ip
is
rxe
1918,
I
heard
keying
it
on
the
basis
of
whether
the
encrypted
resolver
ip
is
on
a
list
of
known
nicely
behaved
resolvers.
I
K
K
K
A
G
G
But
I
mean,
like
I
know
I
know
strategists
all
probably
think
you
can
solve,
but
I
think,
like
I
mean
if
we
know
that
85
percent
of
people
like
have
the
problem,
some
other
problem.
We
need
for
that
problem,
and
I
think
you
know
this
has
been
useful
to
flush
that
out.
But-
and
this
is
for
the
chairs,
like
we
really
need.
If
I
think
we
really
need
to
like
you
know,
we
can
fare
the
problem
definition
at
this
point.
A
Definitely
agree
on
that
we're
working
toward
that.
I
will
note
that
with
eric's
last
comments,
that
was
actually
the
end
of
the
queue,
but
there's
also
been
quite
a
lot
of
active
discussion
in
jabber.
If
anybody
there
would.
This
is
your
kind
of
your
last
call.
You
think
that
you've
made
a
salient
comment
there.
That
should
actually
make
it
into
the
notes
and
and
come
to
the
rest
of
the
group.
Then
please
step
forward.
C
So
this
is
a
slide
that
chris
box
has
made
pulling
out.
The
definition
that
is
currently
in
draft
box
add
requirements,
which
is
what
the
deer
draft
my
understanding
was
based
upon,
and
so
we
thought
that
given
there's
some
discussion
about
this
on
the
list-
and
this
is
kind
of
a
an
important
sort
of
discussion-
point
that
the
deer
draft
is
based
upon.
C
We
thought
that
it'd
be
really
good
topic
of
conversation
for
us
to
explore
what
this
group
really
wants
to
tease
this
out
to
mean
so
I'll
read,
you
know
for
for
everybody
here.
What
is
equivalence
given
two
resolvers,
a
and
b
equivalence
is
the
claim
that
a
and
b
can
provide
the
same
upper
layer.
Dns
function,
ie
response
messages
towards
the
client.
This
does
not
include
the
dns
transport
protocol,
such
as
a
regular
doe,
53
or
dns
over
https
or
or
dot,
which
can
differ
between
equivalent
resolvers.
C
So
far,
there's
been
two
modes
of
how
you
assert
this
claim
of
equivalence.
One
would
be
network
identified
where,
somewhere
at
the
network
level,
either
through
the
dhcp
or
ra
there
is
this
information
given
out
that
says:
hey
b
is
equivalent
to
a
and
you
can
go
with
that
and
then
there's
a
resolver
identified
where
resolver
a
says
that
b
is
equivalent
to
it.
C
H
That
is
absolutely
secure
and
you
can
communicate
it
with
it
through
means
that
are
also
absolutely
secure,
then,
using
that
information
find
an
equivalent
dot,
doh
or
dot
resolver
that
you
can
use
on
a
completely
insecure
network
and
that's
a
different
way
of
formulating
that,
and
it
still
has
the
same
sort
of
constraints
on
it
in
terms
of
network
identification
and
resolver
identification.
But
I'm
moderately
happy
with
this
with
this
formulation,
I
can't
see
anything
wrong
with
it.
Aside
from
that.
G
As
I
indicated
on
the
list,
I'm
not
having
this
regulation-
and
I'm
actually
surprised
martin
is
because
martin
said
is
incredibly
different
from
the
simulation
like
this
formulation
could
absolutely
include
a
resolver
which
gave
you
the
same
answers
but
posted
your.
Like
responses
posted
your
queries
to
twitter,
which
surely
is
not
okay,
so
including
one
was
operated
by
the
attacker.
So
I
think
you
know
tradition.
I
I
sent
some
text
to
the
list.
I
don't
think
it's
perfect,
but
I
think
it's
more
bright
lines
than.
G
I
Hey
so,
to
reiterate
something
I've
said
many
times
now.
I
think
the
we
need
to
talk
about
a
temporal
component
here
about
whether
two
resolvers
not
only
are
equivalent
but
are
going
to
stay
equivalent,
because,
if
there's
an
attacker
who
in
our
model
can
can
can
be
present
only
briefly,
then
I
think
that
that
changes
our
conception
of
what
it
means
to
be
equivalent.
L
I
think
that
the
claim
that
they
provide
the
same
upper
layer
functionality
is
closer
but
much
less
well-defined
and
I
think
you'd
actually
have
to
write
down
what
what
pieces
of
that
dns
functionality
are.
In
fact,
the
same
in
order
to
get
it
something
that
the
the
client
could
be
sure
of-
and
I
I
do
worry
that
most
of
that
is
completely
untestable
by
the
the
client,
so
they're
they're-
to
get
an
assertion.
But
there's
no
way
for
them
to
confirm
it,
except
the
response
messages
which
might
give
you
false
data.
D
I
just
wanted
to
note
that
the
definition
of
equivalence
that
was
used
earlier
was
that
it
is
managed
by
the
same
entity
or
at
the
same
ip
address.
I
think
this
is
at
least
a
step
in
a
better
direction
that
even
two
dns
servers
managed
by
the
same
entity
might
deliberately
have
different
policies
and
behave
in
different
ways.
A
M
Daniel
kahn
gilmore
aclu,
so
I
want
to
echo
what
other
folks
have
said
here
that
that
looking
at
the
response
messages
is
extremely
weak
for
the
questions
that
I
think
we
care
about
here.
The
reason
that
we're
doing
you
know
dns
privacy,
and
these
other
transports
of
change-
is
that
there
are
a
lot
of
factors
beyond
just
what
answers
do
you
get?
M
Ecker
pointed
out,
you
know
what
about
a
dns
server
that
that
sends
to
twitter
that
republishes
to
twitter,
but
there
are
several
others.
I
wanted
to
point
out
that
the
latency
may
be
another
factor
in
terms
of
the
cache
linkability,
whether
the
peer
can
even
link
your
queries
across
time,
whether
the
peer
requires
client.