►
From YouTube: ADD WG Interim Meeting, 2020-09-15
Description
ADD WG Interim Meeting, 2020-09-15
A
B
B
C
C
C
F
C
C
B
C
G
C
G
H
B
C
C
C
G
C
K
C
C
Okay,
so
we
have
two
notes:
takers
benchmarks.
With
assistance
of
chris
box,
we
have
a
jabra
scribe
through
andrew
champley.
Thank
you
andrew
thank
you
chris
thank
you
ben
and
it's.
We
have
three
game
participants
and
I
think
more
will
trickle
in
so
I
suggest
we
we
get
started
with
the
the
high
level
stuff,
especially
so
that
people
in
in
time
zones
where
their
bodies
saying
it's
time
to
go
to
bed.
C
C
C
We
are
using
webex
for
this
session,
so
like
the
previous
sessions,
webex
we're
going
to
use
the
format
of
doing
plus
q
and
minus
queue
in
the
webex
chat.
To
get
yourself
added
to
the
discussion,
please
use
the
jabber
room
for
other
discussions
and
keep
the
webex
session
chat
free
just
for
the
queuing.
Please
also,
we
have
notes
being
taken
over
there
on
etherpad
or
intended
by
comed.
C
C
And
so
hopefully
that
will
allow
us
to
have
enough
freedom,
but
at
any
major
topic
on
a
round
of
authentication
that
people
think
that
we
need
to
talk
about
today
does
get
covered,
and
that
is
the
agenda.
For
today.
These
eight
lines
is
there.
Anything
people
would
like
to
request
to
remove
or
to
add
to
this
list.
D
B
Okay,
before
we
answer
that
question,
I
want
to
point
out
two
things
appreciate
the
question
chris,
but
this
slide
that
glenn
just
blew
right
past
was:
we
are
going
to
again
be
doing
q
management
through
the
webex
chat,
to
which
tommy
paulie
has
added
himself
to
the
queue.
Chris,
I
mean
we'll
angle,
your
questions.
M
B
C
N
Yeah,
could
we
go
back
to
the
list
of
questions
yeah,
so
I
think
it's
fine
to
go
with
this
list.
My
one
suggestion
would
be
that,
as
far
as
the
order,
it
may
be
useful
to
talk
about
the
attacker
model.
Number
five
prior
to
getting
into
should
dhcp
play
a
role,
because
that
is
really
dependent
on
the
answer
to
number
five.
O
Yeah,
I
I
don't
think
I
don't
think
I
want
to.
I
think
I
think
I
think,
if
we're
gonna,
the
dhcp
question
is
contingent
not
just
on
the
also
the
authentication
model,
but
also
on
the
deployment
model,
and
so
I
guess
I
don't
know
how
you
want
to
manage
that
because,
as
I
put
out
the
list,
it's
pretty
common
to
have
user
provided
customer
purchase
equipment
between
you
and
the
carrier
provider,
customer
properties,
equipment.
There's
no
particular
reason.
You
think
it's
going
to
pass
unknown,
dhcp
options.
C
So
ecker,
if
I,
if
I
can
tease
out
of
that
the
you're
you're
agreeing
with
movie
number
five
up
to
the
first
thing,
we
discuss
sure
if
you
want
to
reduce
five
points
to
one
I
I
sorry
there
was
a
lot
of.
There
was
a
lot
to
decompress
right
there,
I'm
back
so
so
so
to
be
clear,
move
number
five
up
and
then
what
else
do
you
would
you
like
to
do
so?
I.
O
Don't
think
you
can
address
the
dhcp
issue,
I'm
not
unless
you
previously
discuss
what
deployment
model
we
intend
to
play
in,
because
that
tells
you
they're
intentionally
feasible,
regardless
of
authentication.
And
second,
I
think,
while
I
don't
think
we
have
to
decide
the
question
of
which
use
cases
we're
interested,
I
think
for
the
purpose
of
this
discussion.
It
is
most
useful
to
focus
on
the
local
use
cases,
because
the
other
use
cases
actually
have
much
more
straightforward
authentication
stories.
C
B
C
I
We
either
have
a
trust
anchor
that
the
user
is
already
holding
or
a
trust
anchor
that
they
got
through
some
unauthenticated
mechanism
and
those
will
certainly
relate
to
dhcp
and
such,
but
I'm
not
saying
that
that
should
be
a
separate
item,
but
I
think
that
that
has
to
be
part
of
certainly
five,
because
you
know
we
don't
know
how
the
attacker
is.
You
know
like
like
if
the
attacker
can't
do
something
that
can
push
a
trust
anchor
to
you,
that's
completely
different.
C
Q
Sorry,
okay,
I
just
wanted
to
make
a
note
that,
in
response
to
michael's
question
like
like,
no,
you
cannot
really
like
any
network
name
has
a
name
and
it's
public
knowledge,
because
otherwise
you
can't
see
or
join
it,
and
so
anyone
can
take
that
name
and
usually
you
only
have
a
name
as
an
identifier
to
the
network
you're
joining
if
you're
on
wi-fi.
So
names
are
just
not
enough,
so
you
can
never
know
what
network
you're
joining
if
it's
rogue
or
not.
C
Okay,
thank
you.
Thank
you,
paul,
okay.
So
what
I'm
teasing
out
of
that
is?
We
really
should
start
with
number
five
there's
a
number
of
sub
elements
that
number
five
drives
us
to
consider
and
I
think
ecker
listed
them
out.
So
if
people
want
to
have
a
record
of
that
that
they
can
refer
to
go,
look
at
the
notes
in
the
ether
pad
because
they
captured
the
ballistic
said,
and
so,
let's
juggle
the
the
discussion
over
and
start
with
number
five.
C
So
I
this
is
meant
to
be
a
discussion,
not
not
a
a
chairs
led
thing.
So
let
us
open
up
the
floor
to
discussion
about
this
particular
topic
space
and
we'll
capture
your
your
comments
and
then,
when
the
conversation
seems
to
sort
of
reach
a
natural,
either
we're
starting
to
repeat
ourselves
or
strain
off
things,
we'll
pull
it
back
in
and
and
refocus
it
on
the
next
question.
C
The
one
thing
I
will
suggest
is
you
know
this
conversation,
especially
the
local
discovery
can
possibly
start
straining
us
into
some
other
aspects
about
network
bootstrapping
models
that
are
sort
of
like
you
know.
What
would
it
be
nice
if
and
that
would
be
certain
a
outer
scope
for
the
adb
group
and
probably
a
much
bigger
rat
tool
for
us
to
try
to
actually
do
this
productive
work
and
do
so?
H
H
So
I
I
think
it
would
be
reasonable
to
say
that
the
majority
of
consumer
users
and
probably
sme
users
are
likely
to
be
using
ifp-provided
kit,
albeit
they're
perfectly
at
liberty,
to
either
unplug
the
isp
kit
completely
if
they
wish,
or
indeed
to
connect
their
own
kit
to
augment
its
capabilities.
But
the
default
is
they'd,
be
using
the
icp
provided
kit.
They
don't
need
in
most
cases
to
provide
anything
else.
L
O
Yeah,
I
think,
to
three
points
one
to
follow
up
on
what
andrew
said:
it's
reasonably
common
in
the
united
states
as
well
for
isps
provide.
You
know,
wi-fi
capable
access
points
cpe.
By
the
other
hand,
it's
also
quite
common
for
customers
to
plug
in
their
own
cpe
to
the
to
that
cpe,
especially
if
they
want
to
have,
for
instance,
a
wi-fi,
a
wi-fi
mesh
system,
or
something
like
that.
O
So
I
think
perhaps
the
question
that
what
the
supplementary
here
is,
what
level
of
success
is
one
interested
in
so,
for
instance,
if
empty
the
majority,
so
30
of
people
provide
their
own
cpe
and
it
doesn't
work
on
those
people.
This
is
70
success,
a
good
success
rate
right,
bad
success
rate.
So
I
think
that's
probably
one
thing
we
should
understand.
I
I
just
made
those
numbers
up.
Obviously,
second,
I
think
respect
to
ben's
suggestion.
O
Certainly
I
I
think
that
that
there's
certainly
are
gonna,
be
a
variety
of
situations,
but
you
know
if
we
have
25
different
threat
models
and
also
25
different
protocols,
specifically
these
threat
models.
Then
we're
going
to
be
here
a
really
really
really
long
time.
So
my
point
would
be,
if
there's
not
at
least
one
threat
model
which
occupies
a
fairly
large
fraction
of
the
people
and
which
has
a
solution.
Just
something
useful
in
that
situation
then,
like
probably
like,
we
should
be
taking
a
step
back
and
thinking
about
it.
O
R
B
R
Hey
so
what
they
do
from
mecca,
so
I
just
wanted
to
add
to
whatever
was
saying
that
nowadays
we
see
many
of
the
security
vendors
are
offering
the
network
system
security
services
from
home
routers.
It
could
be
an
offset
shelf
home
router
or
it
could
be
co-located
with
the
isp
provided
cd
in
both
the
cases.
R
If
you
see
it's
not
just
from
mecca
tv
offers,
the
keyhole
platform,
which
offers
the
network
security
services
data
filtering
device,
isolation,
various
other
security
features
to
protect
the
home
network.
These
routers
are
quite
advanced
that
we
see
that
it's
quite
easy
for
us
to
upgrade
the
firmware
or
configuration
on
these
routers
and
whatever
mechanism
the
working
group
decides
as
a
dsvp
or
a
new
resource
record
type
or
a
special
specialization
domain
name.
B
I
I
Lots
of
people
have
proposed
solutions
without
clearly
stated
use
cases,
and
I
put
myself
in
that
category
the
result
of
that
so
far
because
look
we've
been
we've
been
doing
this
for
like
a
year
now
is
that
people
attack
it
because
you
know
the
solution
because
it
doesn't
meet
their
use
case
or
they
support
it,
because
if
you
stretch
it
a
little
bit
in
this
direction,
it
does
meet
their
use
case
and
so
far
this
is.
This
has
led
to
no
progress
at
all.
I
I
strongly
believe
we
should
do
it
based
on
use
cases
and
attack
scenarios,
and
I
think
those
two
here
are
quite
related.
The
use
case
is,
I
want
to
get
x
in
this
environment
the
statement
of
this
environment.
Even
if
you
don't
remember
all
the
attackers
in
the
environment,
certainly
other
people
on
the
list
will
throw
some
at
you
leads
to
either
to
well
will
definitely
lead
to
two
things:
one.
It
will
lead
to
this
proposal
meets
the
use
case
and
two.
J
J
J
Let
me
say
the
next
itf
meeting
would
be
a
suitable
point,
so
it
should
be
incumbent
on
the
people
in
the
working
group
to
come
up
with
a
use
case
and
just
a
couple
of
sentences
about
the
threat
model
or
the
potential
problems
that
this
use
case
might
throw
up,
and
then
once
we've
got
all
that
information
together.
We
can
then
take
a
look
at
this
in
the
in
the
labs
and
say
well
that
particular
installation
is
our
scope
for
us,
or
it's
going
to
take
too
long,
but
it's
too
complicated.
J
We
don't
understand
it
and
then
make
engineering
decisions
about
which
ones
are
the
ones
we
can
work
on
and
achieve
solutions
in
a
reasonable
amount
of
time.
I
think
at
the
moment,
we're
going
around
in
circles
quite
a
lot
and
I
think
it
would
help
greatly
if
we
have
some
deadlines
and
some
focus
by
saying.
J
Let's
get
all
the
use
case
togethers
by
a
specific
date
and
with
some
outlines
of
the
threats
that
these
pose
then
have
a
discussion
about
those
kind
of
issues
and
then
think
about
how
we
work
from
there
on
forward.
Because
I
think
at
the
moment
we're
just
going
round
and
round
and
we're
not
really
making
a
lot
of
progress.
B
Q
Sorry
I
just
I
want
to
make
two
comments.
One
is
that
it
seems
people
are
thinking
a
lot
about
the
isp
scenario,
where
the
isp
gives
some
equipment
or
not,
and
you
connect
to
it,
but
that
leaves
out
a
lot
of
all
the
mobile
devices
that
have
5g
or
4g
connections
straight
up
where
the
control
is
a
lot
different.
The
security
is
a
lot
different
and
I
just.
Q
Q
So
I
would
like
the
discovery
model
to
more
focus
on
getting
the
information
to
the
user
and
letting
the
user
make
those
decisions
and
whether
or
not
you
can
secure
this
later
on.
That
would
be
great
if
we
can
do
that,
but
it
should
not
prevent
the
publication
of
this
information
so
that
the
user
can
make
a
decision
if
they.
R
Hello
I'll
try
to
be
slow
this
time.
So
I
see
I
see
two
different
types
of
networks
that
I
think
we've
been
discussing.
One
is
the
home
networks
or
free
wi-fi
networks,
where
the
users
log
into
a
necessity
that
is
well
known
to
everybody
and
users
typically
use
a
common
password,
and
that
seems
to
be
a
problem
that
the
user
may
not
even
know
whether
the
user
is
indeed
connecting
to
the
home
network
or
it
could
be,
and
he
will
train,
but
in
case
of
enterprise
networks.
R
It
would
be
typically
that
the
user
would
get
any
credentials
when
it
and
any
of
the
methods
and
it
could
be
an
unique
username
password
or
it
could
be,
an
unique
certificate
that
you
could
get,
and
in
that
case
the
endpoint
does
know
that
it
can.
It
is
actually
connecting
to
the
intended
organization's
network
and
not
to
any
building.
So
I
think
I
think
in
those
two
cases
the
attack
vectors
are
quite
different.
So
I
think
that
would
help
probably
to
understand
each
of
these
use.
R
N
Yeah
thanks
so
we're
talking
about
the
deployment
model
a
lot.
You
know
the
question
here
that
eckerd
raised
was
around
kind
of
what's
the
attacker
models,
I'd
like
to
discuss
a
bit
about
that,
so
I'd
send
a
mail
in
response
on
the
list,
so
I
guess
like
the
throughout
as
a
straw,
man
kind
of
like
an
attack
attacker
model.
We
can
talk
about.
So
it
seems
to
me
that
it's
useful
to
talk
about
an
attacker
that
can
inject
and
observe
your
dns
packets.
S
Yeah,
the
one,
the
one
I
think
thing
that
I
keep
thinking
about
as
I'm
listening
to
this
discussion
is
that
we
are
in
the
camp
of
you
know
we're
letting
perfect
be
the
enemy,
the
good
to
a
large
extent.
It
takes
a
long
time
to
be
perfect,
and
you
know,
even
things
like
dhcp
can
be
useful
across
boundaries
given
equipment
rollover
times
which
are
getting
faster
and
faster.
S
You
just
have
to
take
that
into
consideration
when
you're
building
a
longer
term
plan.
So
the
result
is,
you
know,
you
have
to
build
a
timeline
with
respect
to
a
rollout
and
there
seem
to
be
sort
of
two
solution.
Timelines
that
keep
getting
talked
about.
One
is:
what
can
we
accomplish
now
right
that
the
atf
is
always
trying
to
come
up
with
protocols
that
work
within
the
current
environment?
S
And
you
know
sometimes
that
means
you
know.
What
can
we
do
within
a
browser
update,
which
is
a
really
convenient
short?
You
know
often
three-month
kind
of
time
timeline,
but
you
know
there's
also
the
vision
of
what
can
you
do
with
a
longer
term
and
I
think
you've
got
to
consider
even
the
possibility
that
there
are
multiple
approaches
with
a
fallback
mechanism.
For
you
know,
while
dhcp
isn't
passing
anything.
Therefore,
I
have
to
go
back
to
another.
M
S
I
hate
to
say
that
within
the
ietf,
because
we
generally
only
like
to
do
one
solution
for
you
know
protocol
kind
of
concerns,
but
there
are
times
when
you
can't,
and
there
are
times
where
you
know
you-
you
can't
wait
for
something
to
come
out
or
you
have
to
wait
until
something
comes
out.
I
think
we
might
be
in
the
camper
we
may
need
to
do
both.
B
C
Exactly
so
from
what
I've
heard
from
the
conversation
which
has
been
pretty
good
and
when
I'm
also
trying
to
follow
the
jabra
chat,
you
know
we
seem
to
be
settling
around
my
observation
and
is
that
we
seem
to
be
sitting
around
a
couple
core
use
cases.
The
in-home
use
case
seems
to
be
one
that
a
lot
of
people
are
talking
about
and
are
comfortable
with,
with
some
sort
of
sub
cases
around
it.
Where
you
may
have
various
attackers.
I've
seen
some
proposals
here
in
the
jabber
chat
about
people.
C
Maybe
when
you
are
raising
an
issue
raise
tell
us
which
of
these
environments
you're
actually
directly
addressing
in
your
comments
and
maybe
as
well
give
an
indication
of
do
you
think
that
the
priority,
and
not
the
exclusive
thing?
But
the
priority?
Should
be
one
or
the
other
and
and
such
as
the
comments
by
west,
for
instance,
just
to
sort
of
help,
help
us
shape
and
direct
the
conversation
I'll
turn
my
mic
back
off.
O
O
They
really
think
the
the
environment
is
third
discussion
about
what
tommy
was
saying.
I
guess
I
don't
really
understand
what
capabilities
would
lead,
what
what
physical
capabilities
would
lead
me
to
not
be
able
to
spoof
dcp
messages,
but
with
the
immediate
dns
messages
they're,
both
just
raw
udp,
so
tommy,
I
guess.
Maybe
you
can
explain
to
me
how
that
situation
will
come
to
pass.
E
E
E
E
B
T
Thanks
the
eric
nygren
akamai,
I
think
that,
while
some
of
these
problems
are
certainly
no
way
to
deal
with
now,
and
while
the
scope
of
solving
some
of
them
now
is
certainly
not
something
you
want
to
have
as
part
of
the
scope
of
add,
it
would
be
nice
to
think
about
ways
and
that
didn't
necessarily
preclude
some
better
solutions
down
down
the
line.
So,
for
example,
what
when
paul
was
listing
the
categories
of
things
that
you
could
get
you
could
use
for
establishing
root
of
trust.
T
I
think
another
class
of
those
is
ones
where
there's
been
some
association
through
the
real
world
to
establish
trust,
whether
it's
like
scanning
a
qr
code
or
pressing
a
button
on
the
two
devices
to
establishing
a
pairing,
and
so
there
are
some
ways,
even
in
the
in
the
kind
of
home
network
environment
of
the
coffee
shop
environment.
To
to
do
that
is
trust,
establishment
and
in
many
cases
you
might
say
this
is
totally
out
of
scope.
T
Where
maybe
of
at
least
some
related
interest
here
is
that
is
given
the
association
between
naming
and
and
trust
establishment
we
make
and
how
naming
is
a
big.
A
big
part
of
what
you
use
is
interacting
with
trust,
it's
something
where,
where
we
may
want
to
think
about
it
sooner
rather
than
later,
even
if
it's
going
to
post.
N
Yeah,
so
in
response
to
ecker's
question
I
mean
yes,
if
an
attacker
can
inject
udp,
of
course
they
could
do
dhcp
or
dns.
They
still
seem
a
bit
different
to
me
doing.
The
man
in
the
middle
attack
for
dhcp
is
a
much
more
active
thing
that
you
have
to
do
some
of
the
models
for
just
injecting
one
dns
packet
to
someone
to
get
them
to
use
your
some
doser
that
you
choose
is
a
lighter
weight
attack,
as
people
mentioned.
Also
there
are
the
guards
for
dcp
and
ra
that
exist
somewhere.
N
If
you
are
already
attacking
my
dhcp
traffic
and
are
being
the
man
in
the
middle
you're
already
choosing
my
do53
resolver
and
you
essentially
are
already
my
network
provider,
and
I
may
as
well
trust
you
as
much
as
I
trust
the
network.
I
don't
trust
any
other
way
right,
you're,
you
are
my
cafe
network
and
maybe
it's
a
legit
one.
Maybe
it's
a
fake
one,
but
I
think
there
are
models
in
which.
N
You
could
attack
me
in
a
way
that
I
would
have
otherwise
been
better
off
to
just
use
the
do53
router
address
that
I
had
the
the
resolver
address
that
I
had,
because
that
one
was
legitimate
and
now
you
redirect
me
to
something
else
that
is
an
attacker's
encrypted
dns
server.
So
that's
really
the
attack.
I
want
to
avoid
here
and
say
that
if
you
already
control
the
the
unencrypted
dns
server,
I'm
less
interested
in
preventing
that
attack.
C
N
And
the
one
that
you're
using
for
encrypted
dns
to
do
or
dot,
I
that's
an
attack.
I
think
that
we
can't
solve
without
some
other
form
of
trust,
because
they
are
controlling
everything
here.
So
the
heck
I
am
interested
in
protecting
against
is
when
I
would
have
used
a
for
whatever
value
of
legitimate.
You
want
legitimate
udp
resolver
that
you're
redirecting
me
to
an
attacker's
encrypted
dns
resolver.
N
R
Unfortunately,
I
agree
that
the
client
never
knows
whether
the
network
has
deployed
the
services
but
yeah.
I
agree
with
tommy
when
he
says
that
if
the
cp
and
ray
are
spoke,
that
means
you're
actually
connecting
to
some
other
access
point
and
you
have
no
control
on
whom
you're
connecting
to
as
a
network.
L
So
I
don't
that
distinction
doesn't
seem
like
one
that
that
we
we
should
focus
on
the
the
thing
that
seems
most
appealing
to
me
here
is
to
focus
on
fine-grained
attacker
capabilities,
and
the
two
that
I
brought
up
on
the
mailing
list
are
transient
to
persistent
upgrades,
so
does.
Are
we
creating
a
system
where
a
transient
attacker,
who
briefly
has
the
ability
to
inject
packets,
can
become
a
persistent
attacker
who
gets
to
capture
and
modify
all
of
your
dns
traffic
and
and
also
essentially
where,
in
the
network,
the
the
attacker
is
able
to
act?
L
And
so
this?
This
is
in
fact
similar
to
what
tommy
is
talking
about,
maybe
from
a
different
perspective,
where,
if
you
have
an
injection
attacker
who
isn't
on
your
link,
but
is,
for
example,
on
the
link
upstream
of
your
recursive
resolver,
then
they
might
be
able
to
inject
traffic
into
the
recursive
cache.
L
B
B
U
Yeah,
I
think
the
one
area
we
keep
sort
of
glossing
over
in
all
these
discussions
is
sort
of
who
we're
authenticating.
It's
there's
sort
of
a
the
general
concept
of
oh
we're
supposed
to
make
sure
that
we're
getting
this
dhcp
information
or
whatever
information
from
whoever
is
supposed
to
be
getting
it.
We
haven't
really
agreed
on
who
that
is-
and
I
think
a
lot
of
this
is
use
case
specific
in
a
lot
of
use
cases.
The
client
might
know
specific
some
specific
entity.
They
want
to
get
the
information
from.
Maybe
they
want
from
the
isp.
U
Maybe
they
want
from
a
specific
enterprise,
something
like
that
and
in
a
lot
of
those
cases.
Well,
this
is
we
have
to
create
the
authentication
mechanisms
for
that
specific
use
case,
but
the
underlying
auth
mechanisms
are
a
fairly
easy
problem.
You
know
who
you
want,
so
you
probably
have
a
name
for
them
and
we
just
gotta
authenticate
that
name
through
dns
tech
or
certs
or
whatever.
U
The
the
more
general
case,
though,
is
just
sort
of
do.
We
ought
to
authenticate
that
the
network
is
giving
us
information
that
the
net
from
whoever
is
supposed
to
be
providing
information
from
the
network,
and
I
don't
think
this
is
really
an
authentication
problem
because
from
the
client's
perspective
they
don't
know
who
that
is.
They
just
need
to
trust
the
network
to
control
it
and
only
allow
through
information
from
the
proper
sources.
U
U
The
only
way
to
protect
against
this
is
to
stick
within
communication
mechanisms
that
the
network
already
knows
to
guard
against
things
like
staying
within
dhcp
as
much
as
possible,
because
the
network
knows
how
to
control
and
make
sure
only
the
proper
network
authority
is
able
to
give
dhcp
and
be
able
to
block
other
stuff,
but
yeah
versus.
If
you
invent
brand
new
mechanism,
someone
can
the
network
doesn't
know
to
control
that
and
people
can
get
in
signals
that
couldn't
get
through
before
and
even
though
there's
no
authentic
real
authentication
story.
O
Yeah,
so
I
think
the
most
interesting
thing
tommy
said
was:
that's
amazing.
Interesting
was
that
you
shouldn't
the
the
idea
is:
don't
like
the
idea
of
not
align.
This
accurate
situation
works
by
stringing,
a
result
that
you
otherwise
wouldn't
have
used,
and
that's
an
interesting
interesting
way
to
frame
this,
because
it
may
open
up
the
solution
space
quite
a
bit.
O
So
as
a
concrete
example,
you
know,
if
you're
willing
to
be
happy
about
the
ip
address,
you
could
simply
usually
do
effectively
optimistic
probing,
and
then
you
wouldn't
need
a
signaling
at
all,
and
so
that
so
the
question
is
and
what
does
signaling
do?
This
only
either
tells
you
whether
is
it.
There
is
a
there,
is
an
available
resolver
or
in
some
some
potentially
authoritative
way
or
potentially
tells
you
it's
over
here
instead
of
over
here.
K
Thank
you,
so
two
quick
things
on
the
dhep
thing,
one
something
which
I
think
we
seem
to
forget
is
in
order
for
an
attacker
to
do
a
useful
dhcp
injection.
They
almost
always
have
to
actually
be
local
to
where
the
client
is
right.
They
need
to
be
on
the
same
layer,
2
network,
which
is
a
fairly
large
change
from
a
normal
attack
model.
K
K
Yes,
there's
no
way
for
the
client
to
know
that
I
fully
agree
with
ecker,
but
I
think
this
might
be
another
case
of
the
perfect
becoming
the
enemy
of
the
good.
At
the
moment,
we
have
nothing
because
we
keep
getting
up
in
the
sort
of
situation
of
how
do
we
solve
this
for
everyone,
and
maybe
at
some
point
you
know
an
initial-
we
can
solve
it
for
some
set
of
people
some
of
the
time
and
that
ain't.
R
Hello
yeah,
I
was
able
to
say
what
saying-
and
I
totally
agree
with
him-
and
one
thing
I
like
about
dhcp
is,
since
it's
not
just
being
local
and
because
of
the
player
to
protection
that
you
get
in
cases
if
dhcp
is
not
available.
Maybe
we
should
consider
multiple
discovery
options
like
giving
dhcp
higher
priority
and
then
falling
back
to
dns,
because
dns
could
be
coming
from
any
any
external
entity
and
could
be
subjected
to
external
attacks.
R
So
maybe
that
a
fallback
mechanism
that
we
consider,
because
I've
seen
several
protocols
today
supporting
the
several
discovery
mechanisms,
not
just
one.
So
I
think
having
multiple
discovery
mechanisms
and
having
a
presence
between
them
would
be
a
way
of
making
progress
to
handle
the
various
deployment
cases
that
we've
been
discussing,
whether
the
home
browser
can
be
upgraded
or
cannot
accept
it.
V
Thank
you
tyrion
martin
thompson.
Please,
yes,
I've
been
hitting
on
something
that
I
think
was
really
kind
of
interesting.
He
suggested
that
he
wasn't
convinced
at
all
by
the
dhcp
arguments
that
we've
been
putting
forth
in
the
ones
that
tommy
put
put
out
and
then
talked
about
what
abilities.
Does
the
attacker
gain
by
by
mounting
a
particular
attack
and
identified
one
particular
attack
with
the
special
use
domain
names
that
that
was
potentially
quite
interesting
and
and
exposes
a
vulnerability
there?
V
That,
I,
I
think
is
pr
has
been
highlighted
as
one
of
the
many
things
that
special
use
domain
names
have
problems
with,
but
with
dhcp.
I
still
can't
see
any
specific
way
that
an
attacker
can
gain
something
that
they
don't
already
have.
If
the
attacker
is
able
to
tell
you
what
your
do
53
server
is,
then
it's
game
game
over
as
far
as
I'm
concerned
in
terms
of
resolver
selection.
So
I
don't
know
why
we
would
expect
a
higher
degree
of
security
for
something
that
we're
building
here
than
the
configuration
protocol
that
you're
already
using.
I
I
So
I
I
think
that
the
idea
of
doing
everything
in
dhcp
or
doing
everything
in
the
resolver
or
whatever
is
is
probably
not
good,
and
we
can
easily
describe
multiple
things
and
then
the
working
group
can
say
the
order
that
you
know
because
of
the
attacks
that
we
are
concerned
with,
and
how
many
we
are
concerned
with
and
as
ecker
keeps
bringing
up
how
good
we
expect,
how
you
know
what
percentage
of
users
we
expect
to
be
able
to
use.
Any
solution
can
be
prioritized
in
a
start
with
this.
I
C
C
If,
if
you
don't
think
the
warren's
sort
of
observation
of
what
you
need
to
actually
make
that
successful
helps
limit
the
the
attack
service,
maybe
you
could
post
the
list.
You
know
references
to
documented
attacks,
so
the
the
larger
group
could
understand
your
concerns
better.
I
just
want
to
throw
that
out.
There.
B
R
Forward
traffic
with
regard
to
cryptography
perceptions,
but
if
you
look
at
the
work
happening
in
rats
working
group
with
3r2
cryptographic,
recession
similar
to
the
way
I
think,
firefox
and
chrome
have
pre-configured
public
resolvers
in
the
browser
which
they
have
done
quite
a
few.
Quite
an
amount
of
background
verification
before
adding
them
into
that
that
background
verification
with
some
cryptographic
decisions
proving
that
it's
in
a
legitimate
organization
right,
would
reduce
the
attack
vectors
to
some
extent
where
an
attacker
could
easily,
for
example,
get
a
sign
certificate
and
say
hey.
B
Thank
you
teru,
and
that
is
the
current
end
of
the
queue
and
glenn,
and
I
had
been
talking
on
the
side
to
take
a
break
right
at
the
top
of
the
hour
and
we're
three
minutes
short
of
the
hour.
So
with
the
queue
having
been
run
for
the
moment,
good
time
to
get
some
coffee,
you
know
gather
your
thoughts
for
what
you
want
to
bring
to
the
mic
next
and
we
will
see
you
at
10
after
the
hour.
Thank.
B
K
K
K
M
K
Their
own
thing
it's
actually
written
in
tickle
and
all
of
the
sources
available
online.
So
you
can
oh,
what's
with
it
yourself,
but
what's
nice
is
they've,
got
a
pid
control
right
right,
right
right
at
the
head,
so
they've
got
a
heating
element
right
in
the
head
itself
and
a
pid
like
temperature,
or
you
know
a
thermistor
right
next
to
it
and
then
a
they
do
pwm
to
control
the
pump
itself.
K
P
My
wife's
favorite
machine
broke
on
her
and
she
is
something
subtle
inside
of
it,
involving
the
pump
right
and
and
we've
never
found
anybody
to
fix
it
successfully.
We
have
been
through
two
additional
machines,
each
one
of
which
have
are
functional,
but
don't
work
anywhere
as
near
as
the
first
one
did
when
it
when
it
was
working
and
the
the
original
one
is
sitting
there
neck
in.
K
F
M
K
K
G
G
K
G
C
P
G
K
G
B
C
I
feel
like
we
made
progress
in
capturing
a
lot
of
issues
and
compared
to
what
I
saw
on
the
list
over
the
last
six
months
to
eight
months
where
the
issue
of
dhcp
came
up.
I
think
this
actually
was
pretty
successful
in
drilling
down
into
the
nitty-gritty
parts
of
it
and
people's
concerns.
So
I'm
very
happy
with
that.
I
would
suggest
we
see
to
sort
of
come
to
a
close
on
that
local
discovery
and
model
discussion.
Thank
you,
ecker
for
raising
it.
C
Let
us
move
them
back
to
the
what
was
the
first
question
and-
and
I
I
think,
we've
covered
this
somewhat,
but
let's
just
close
out
on
it-
can
dhcp
play
a
role
in
discovery,
they're
very
simple
question
to
to
the
group
to
discuss,
and
I
don't
think
we
need
to
spend
a
lot
of
time
on
this,
because
we've
already
spent
a
good
amount
of
discussion
already.
But
just
that
simple
question.
If
people
would
like
to
weigh
in
do
you
think
dhtv
can
play
a
role
in
discovery
successfully.
Q
B
Q
C
B
B
B
F
F
B
X
Me,
okay,
I
would
echo
what
mike
said
that
I
think
http
is
absolutely
a
good
option
and
there
are
caveats,
obviously
grains
of
salt
etc,
and
it
may
not
provide
the
security
level
on
every
circumstance
and
every
use
case.
But
I
think
that
to
the
point
made
in
the
previous
session,
if
we're
trying
to
solve
every
use
case,
we
won't
ever
get
anything
done,
and
if
we
have
a
reasonable
level
of
expectation
of
security
with
dhcp
today,
then
we
should
at
least
explore
what's
required
to
do
doa
to
dot
or
any
resolver
discovery
that.
N
Yeah,
so
the
short
answer
have
is
yes,
because
if
you
know,
as
I
stated
earlier,
the
guarantee
that
I
want
to
get
is
that
whatever
discovery
mechanism
we
have
is
no
worse
than
what
we
get
from
dhcp.
Putting
it
in
dhcp
is
obviously
no
worse
than
that,
but
I
think,
as
several
people
have
commented
on,
jabber
there's
a
but
there,
and
I
think
it's
not
something.
N
U
Yeah
I'm
another
yes,
but
I'm
sure
dhsp
has
a
pretty
strong
role.
It
can
be
used
in
a
lot
of
different
mechanisms,
use
cases,
but
also
we
should
keep
in
mind
that
dhcp
can't
be
the
only
mechanism
or
the
root
of
all
of
our
mechanisms.
Stuff
like
that,
because
a
lot
of
the
clients
are
in
different
positions
and
just
speaking
for
chrome,
it's
chrome
doesn't
currently
look
at
dhcp.
U
I
don't
see
us
likely
looking
at
dhcp
in
the
general
cases,
we've
we're
doing
other
stuff
like
just
getting
the
configuration
from
the
os
and
sure
indirectly,
that's
dhcp,
because
oftentimes
it
gets
it
from
dhcp
but
other
times
not.
So
we
can't
assume
that
dhcp
will
be
this.
The
root
of
all
solutions,
it's
just
gonna,
be
one
part
of
the
problem
and
different
clients
are
gonna,
have
different
needs
and
be
gonna
need
to
get
their
discovery.
Information
from
different
sources.
C
Hey
glenn
here,
jumping
with
my
chair
hat,
so
eric.
Let
me
ask
for
clarification
on
that,
so
I
I
get
it
the
you
know
what
what
do
you
say
about
chrome
and
I'm
wondering?
Is
there
one
of
the
issues
being
that
we
have
some
something
space
being
the
application
which
doesn't
see
dhcp
messages,
it's
separated
out
from
that
versus
other
implementation,
which
might
be
at
the
operating
system
level,
which
then
potentially
could
have
a
much
more
interaction
with
dhcp?
Is
that
sort
of
those
different
modalities
giving
some
of
the
the
concern
here?
Maybe.
U
I
I
don't
know
if
it'll
be
a
hundred
percent,
but
there's
probably
a
very
strong
correlation
that
applications
are
probably
more
likely
to
be
interested.
In
one
thing,
os
is
another,
but
I'm
sure
it
can
come
down
to
specifics
of
the
use
case
of
the
individual
client,
whatever
it
is
like
some
clients,
even
if
they're
in
the
application
space
yeah
sure
we
could
look
at
dhcp,
but
just
for
various
reasons
and
various
policies
that
are
obviously
out
of
scope
for
this
group.
U
V
Martin
thompson,
please
yeah,
so
tommy
said
most
of
what
I
was
going
to
say.
I
think
eric
touched
on
one
of
the
reasons
that
I
think
dhcp
though
it
might
be,
an
easy
win
will
be
insufficient
and
that
being
that
applications
might
not
be
able
to
get
it.
The
other
reason
that
our
clients
may
not
be
able
to
get
dhcp
is
the
prevalence
of
forwarders
and
those
those
little
boxes
that
don't
get
updated,
that
that
won't
be
passing
on
dhcp
options
or
other
configuration
options
from
upstream.
Q
So
for
most
networks
that
you
connect
to
d2p
is
as
secure
as
the
entire
network.
Like
most
wi-fi
networks
are
now
segmented.
You
can't
like
spoof,
your
fellow
participant
on
a
network.
So
basically,
if
I
join
a
starbucks
network,
I
can
trust
as
much
as
I
can
trust
a
random
starbucks
network.
I
can
trust
a
random
dhp
server
to
give
me
a
hint
and
that
hint
can
then
later
be
used,
for
you
know
me
making
a
decision
whether
or
not
I'm
going
to
give
that
network
enough
trust
from
for
my
encrypted
dns.
Q
Y
Y
It's
a
convenience
that
can
be
used
to
advertise
the
metadata
necessary
to
connect
to
an
encrypted
dns
server,
and
that
will
help
protect
against
late
arriving
attackers
to
a
network,
among
other
things.
But
we
shouldn't
be
using
dhcp
as
a
way
to
convey
information
that
we
will
then
use
to
establish
greater
trust
than
we
had
before.
I
I
J
I
think
we
need
to
be
careful
here
that
we're
realizing
there's
not
going
to
be
a
single
overarching
security
model
or
security
solution
to
all
this
discovery
stuff.
So
there
may
be
one
that
applies
for
the
dhcp
use
case,
but
there'll
be
another
security
model
for
some
other
kind
of
discovery
mechanism
whatever
that
might
be
so.
J
I
think
we
should
be
very,
very
careful
about
how
we're
talking
about
these
things,
because
we
may
be
getting
ourselves
in
this
trap
yet
again
of
trying
to
look
for
an
overlapping
solution
to
a
general
thing
which
probably
is
unachievable,
and
we
should
maybe
recognize
that
there
will
be
multiple
security
models
and
multiple
threat
models
depending
on
the
individual
use
cases
or
potential
scenarios
that
could
be
looked
at.
I
think
we
should
be
careful
to
capture
that
information.
Make
sure
that
you
all
understand,
you're
working
towards
the
same
thing,
cheers.
Z
Miguel,
yes,
so
considering
the
the
responses
from
from
whether
dhep
should
be
included
or
not.
I
think
I'd
like
to
echo
what
eric
ought
just
mentioned
is
that
yeah,
I
I
see
dhcp
as
a
way
to
to
carry
some
bootstrapping
information
to
perform
a
discovery
protocol
rather
than
being
completely
part
of
that
discovery
protocol
itself.
So
in
that
sense
I
mean
we
should
have
a
discovery
protocol
that
can
be
provisioned
with
dhep
or
some
other
mechanisms
like
reading
directly
in
the
osr.
B
Thank
you
daniel,
and
I
believe
that
there's
some
other
messages
interspersed
here,
but
if
you,
if
you
think
you
were
in
the
queue-
and
I
have
somehow
missed
you-
please
add
yourself
to
the
queue
again
otherwise
we're
at
the
end
of
the
current
queue,
but
we
might
at
least
be
getting
some
direction
as
to
starting
to
have
a
more
meaningful,
perhaps
not
right.
Now,
dhcp.
B
C
Yeah
sure,
and
so
to
that
comment,
I
I
think
these
discussing
topics
can
be
kind
of
exhausting,
especially
not
in
person.
So
I
think
we
should
probably
limit
today's
session
to
only
two
hours
and
and
let
certain
participants
get
get
an
extra
half
hour
of
sleep.
Maybe
so
we
see
we've
covered
dhcp
very
well.
I
think
we've
in
fact,
in
the
last
conversation
here
just
now
touched
upon
the
whole.
C
C
Let's
talk
about
authentication
next
question,
which
is
question
number
two
on
the
slide,
what
is
authentication's
role
in
resolver
discovery
and
validation,
so
the
dhcp
and
the
network
bootstrapping
aside,
would
people
like
to
comment
on
what
they
feel
is
the
the
needed
role
here
as
part
of
the
discovery
and
validation
process
of
successfully
selecting,
not
selected?
But
you
know
I
mean
like
successfully
discovering
and
then
making
a
choice
ultimately
on
what
resolvers
you
will
talk
to?
B
I
Thank
you,
I'm
going
to
start
off
with
an
apology,
because
this
question
that
says
you
know
what
is
the
role
in
discovery
and
validation
for
those
of
you
who
aren't
completely
native
english
speakers.
It
sounds
like
discovering.
Validation
are
one
thing
there
and
that's
partially
due
to
the
draft
that
punit-
and
I
put
in
one
thing-
that's
completely
clear
to
me
now
and
I
apologize
for
not
having
seen
it
ahead
of
time.
I
Is
those
two
are
completely
different
topics
or
can
be
separated
by
people
more
careful
than
I
was,
and
we
should
not
discuss
them.
We
should
not
discuss
the
role
for
discovery
and
validation.
We
should
discuss
authentication's
role
for
discovery
and
authentication's
role
for
validation,
so
please
separate
them
out.
Thank
you.
V
Thank
you
paul
martin
thompson,
so
I
I
think
that
that
ben
schwartz
hit
on
this
during
the
the
lengthy
discussion
that
we
had
previously,
which
is
that,
if
we,
if
there
is
any
authentication
involved
in
this
process,
then
that
authentication
is
in
involved
to
the
extent
that
it
is
necessary
to
prevent
an
attacker
from
gaining
additional
privileges
that
would
not
otherwise
be
available
to
them.
So
in
the
dhcp
case,
I
don't
think
that
there's
any
pressing
need
to
add
additional
authentication
other
than
what
is
provided
in
the
in
the
configuration
protocol.
B
L
L
And
I
think
that
authentication,
one
role
that
authentication
can
play
is
to
essentially
make
sure
that
we
don't
violate
those
properties.
I
think
about
this.
I
like
acker's
formulation
that
we're
looking
for
solutions
that
can
make
things
better
and
can't
make
things
worse.
So
it
can't
make
things
worse.
B
Y
Y
N
N
O
I
do
want
to
push
back
slightly
tommy
on
the
suggestion
that
that
that
should
include
being
able
to
like
have
having
malleability
in
the
uri
template,
because
I
can
imagine
some
serious
problems
there,
but
I
think
otherwise,
I'm
generally
outboard
with
it,
and
I
think
I
think
I
don't
I
don't.
I
don't
yet,
I'm
not
yet
sure
I
understand
how
to
establish
the
same
person,
though
I
I
do
think
that
the
suggestion
of
having
a
certificate
with
the
sam
that
has
a
somewhat
compelling.
E
Yeah
for
in-band
kind
of
authentication,
you
could
also
think
about
something
token
based,
but
one
thing
I
wanted
to
address
is:
we
are
talking
about
dhcp,
but
just
to
be
precise,
I
assume
we're
also
including
ipv6
route
announcement
and
maybe
also
provisioning
domains
as
sort
of
a
local
butcher
mechanism.
Here.
I
I
This
goes
back
to
ecker's
question.
How
much
of
a
solution
do
we
want?
You
know
like
like?
If
it
covers
n
percent
are
we?
Are
we
good
enough,
and
it
also,
I
think,
speaks
to
where
the
trust
anchors,
because
today,
as
far
as
I
can
tell
you,
can
get
web
pki
certificates
with
ip
addresses
from
a
very
small
number
of
certificate
authority.
I
M
You
paul
vittorio,
please
thanks!
Well,
I
I
just
had
a
comment
on
the
question
about
authentication,
which
is
that
you
really
need
to
define
authentication
of
what
I
mean
it,
and
this
unfortunately,
changes
depending
on
what
your
deployment
model
is,
because
if
your
model
is
that
you
get
a
a
doh
uri
or
an
ip
address
from
the
user
or
from
the
client
itself,
then
of
course
you
need
to
authenticate
that
you
are
speaking
to
actually
to
that
address
or
to
that
uri.
M
But
in
the
same
provider,
auto
upgrade
deployment
model
you
need
to
authenticate
is
just
that.
You
are
actually
talking
to
the
same
entity
which
was
running
the
unencrypted
resolver.
You
don't
really
know
to
identify
who
they
are
or
to
know
who
is
actually
running
the
the
couple
of
resolvers,
and
in
that
case
the
solution
might
be
technically
slightly
different
from
the
solution
you
would
employ
to
authenticate
the
identity
of
who
is
a
resolver
or
the
fact
that
it's
actually
responding
to
a
certain
ip
address
so
yeah.
B
Okay,
thank
you
very
much
victorio,
and
I
will
note
that
we
currently
have
two
people
on
the
queue
but
we're
intending
to
close
the
queue
right
after
daniel.
So
if
you
do
have
a
last
minute,
because
glenn
wants
to
cover
just
a
few
more
things
before
the
end
of
the
meeting,
but
I'll
give
a
chance
if
somebody
needs
to
slide
in
under
the
wire
tyra,
please.
R
Quite
often
so,
if
you
have,
these
v6
addresses
it's
quite
a
difficult
to
again
require
search,
and
especially
with
regard
to
talking
to
ca
and
getting
answered
using
acne,
and
the
other
problem
is
what
I
see
is
that
if
there
is
a
name,
it's
very
easy
for
the
user
to
identify,
say
it's
provided
by
my
network
security
vendor
or
it's
provided
by
my
isp.
Rather
if
it
is
just
an
ip
address,
the
user
may
not
be
able
to
relate
to
the
who
is
providing
the
dns
result.
Z
So
well
I
I'd
like
to
echo
what
victorio
just
mentioned
is
that
the
question
is
I
mean
this
to
me
is
not
that
clear,
and
so
I
might
respond
out
of
scaff,
but
in
a
word,
what
I'd
like
to
mention
is
that
I
believe
that
the
discovery
protocol
should
should
be
based
on
authenticated
information,
because
then
I
mean
the
discover.
The
purpose
of
the
discovery
is
to
be
able
to
proceed
to
a
selection.
B
O
But
it's
important
to
think
about
exactly
which
path
which
passwords
have
to
block
for
the
attacker
from
doing
as
far
as
I
can
tell,
unless
you
have
an
outband
mechanism
like
the
same
provider
or
upgrade
mechanism
that
google
and
and
microsoft
are
using,
it's
not
possible
to
run
downgrade
attacks
by
an
attacker
controls,
the
dns,
the
the
local
network,
so
we'll
probably
should
live
with
that.
Unless
someone
figures
thing
out,
I
haven't.
C
C
L
L
L
I
think
where
we
want.
This
kind
of
constraint
is
when
we
are
trying
to
do
some
sort
of
in-band
post-dhcp
upgrade
and
the
reason
we
want.
This
constraint
is
related
to
specific
attack
models
where
we
believe
there
is
an
attacker
who
could
divert
us
to
a
an
incorrect
resolver
and
we
are
essentially
trying
to
use
dhcp
as
a
a
temporary
route
of
trust
to
say:
okay,
we'll
use
any
resolver
as
long
as
we
can
trace
it
back
into
the
dhcp
as
long
as
it's
essentially
no
worse
than
we
would
have
done
from
the
dhcp
source.
L
So
that's
what
I
think
we're
up
to
here
and
I
think
that
my
favorite
solution
so
far
is
to
say
effectively
if
we're
starting
from
an
only
an
ip
address
from
our
configuration
source.
Whatever
that
might
be,
then
you
have
to
prove
that
you
are
equivalent
to
that
ip
address
and
you
could
do
that
through
a
pki
or
you
could
also
do
it
by
being
on
that
ip
address.
L
B
M
Of
course,
we
can
devise
more
general
methods
and
methods
for
other
use
cases
or
so
on,
but
I
mean
I
think,
that
you
can
do
this.
I
mean
you
can
authenticate
this
relationship
securely
using
dnsec
and
tlsa
and
the
number
of
existing
technologies,
and
so
I
I
would
focus
on
this
as
one
of
the
most
immediate
use
cases
that
could
actually
find
deployment
in
the
real
world.
H
R
Is
giving
you
a
domain
name?
I
think
I
think
I
think,
if
it's
hosted
on
the
same
ftp
address,
that's
real
538.
It
just
solves
two
problems.
One
is
that
there
is
no
need
to
perform
another
lookup
to
find
out
the
ip
address
of
the
encrypted
dns
server,
and
the
second
problem
it
resolves
is
finding
the
association
whether
these
two
are
affiliated
or
not.
So
I
think
hosting
them
on
the
same
ip
address
makes
it
quite
simple
and
addresses
several
of
that
expert
for
discussion.
O
So
I
mean
tommy
and
I
were
having
a
chat
back
and
forth
on
on
on
jabber
at
this.
I
think
you
know
this
once
again.
This
goes
back
to
attacker
model
and
in
particular
we
talked
on
the
the
point
that
ben
raised
about
the
local
ip
addresses.
I
I've
not
yet
heard
any
mechanism
that
will
allow
you
to
authenticate
the
pulse
of
authenticate
the
local
ip
address
resolver
in
in
a
good
way.
Let
me
perhaps
get
invent
one.
O
So
if
the
question
is,
is
it
what's
the
value
proposition
of
having
a
secure
connection
to
the
local
resolver?
If
you
can't
authenticate
it
in
a
way
that
ties
back
to
itself
that
ties
back
to
the
dophy
3d
address
we
go
initially,
it
may
have
some
value,
but
it
depends.
You
will
have
to
really
flesh
out
what
the
attack
model
was.
U
Yeah,
I
just
want
to
comment
quickly
on
the
the
comments
that
it
would
be
an
interesting
validation
of
the
the
relationship
that
the
dose
server
is
on
the
same
ip
address
as
the
ip
address
that
was
used
for
the
other
stuff.
Yes,
that's,
probably
a
good
mechanism
in
some
cases,
but
we
have
to
open
mind
it's
not
the
only
solution,
because
I
keep
hearing
there's
plenty
of
situations
where
it
can't
be
hosted
on
the
same
ip
for
various
reasons,
maybe
different
server.
U
Maybe
I
don't
know,
I
think
a
lot
of
it
comes
into
stuff
around
just
routers,
acne
resolvers
and
things
like
that.
But
we
we
still
it's
still
an
unsolved
problem
for
the
other
cases
where
they
can't
get
the
same
ip.
We
still
need
some
way
to
validate
the
relationship,
whether
that
means
figuring
out
the
identity
of
the
ip
address
and
validating
that
and
then
matching
it
against
the
validation
of
the
or
dot
server
or
some
other
mechanism
of
validating
just
the
pure
relationship.
C
U
I
mean,
I
think,
in
this
case
you're
that
you're
using
the
fact
that
it's
on
the
same
ip
address
as
a
proxy
for
the
the
relationship
that
the
the
doe
url
is
at
least
to
some
extent
associated
with
whoever's
running
the
classic
dns
server
on
that
ip
address,
so
yeah
there's
multiple
urls
yeah.
This
is
just
case
of
there's
multiple
door,
dot
servers
that
are
associated
with
it.
So
you
still
have
that
relationship.
It's
just
not
a
one
one-to-one
relationship.
O
Yeah
I
mean
so.
This
is
what
I
was
alluding
to
earlier.
With
respect
to
learning
the
url
with
I've
talked
about
tommy.
The
key
point
is
you
cannot
imagine
imagine
you
have
a
imagine.
You
have
two
urls
this
build
measure.
You
have
two
urls,
one
of
which
actually
answers
the
question
and
the
other
of
which
forwards
the
query.
The
attacker
for
the
answer,
the
question.
So
obviously
you
can't
allow
the
attacker
to
steer
which
url
you.
M
O
And
I
think
you,
I
think
I
think,
if
we're
going
to
have
a
situation
in
which
in
which
the
ip
address
is
used
as
the
lookup
key
for
the
resolver,
that
would
have
to
be
the
case
that
that
deterministically
controls
which
url
template
template
use
as
well,
and
then
you
have
to
trust
the
server
to
separate
those
handles
templates
properly.
The
same
way
that
any
https
are
perhaps
too
but
yeah.
You
can't
you
can't
you
can't
use
you
can't.
B
R
I
think
it's
very
easy
for
an
isp
or
a
network
security
provider
to
host
a
dos
server
or
a
duty
server
and
get
it
from
invalid
insert
right.
I
mean
there
are
various
ways
to
automate
that
using
acme
and
the
isp
can
get
those
certs
and
use
the
tr-69
or
any
other
secured
management
protocols.
They
have
to
provision
those
managed
routers
and
you
don't
really
need
any
any
new
way
of
figuring
out
how
you
get
certificates
for
local
id
addresses.
C
C
What
I'd
like
to
understand
is
what
other
authentication
aspects
do
we
need
to
consider
so
that
we
can
have
these?
You
know
in
a
bigger
list
that
can
then
be
put
onto
the
discussion
list
and
gather
broader
input.
So
if
people
could
just
comment
on
very
briefly
what
other
authentication
aspects
need
to
be
considered,
but
not
going
into
great
detail
about
him?
Please
and
then,
then
that
will
be
well
when
we've
done
that,
we'll
we'll
finish
up
and
close
out
the
session.
O
Thank
you,
echo,
please
yeah,
so
I
don't
know
I
I
don't
know
if
this
is
an
authentication
topic
or
not,
but
as
I
was
just
saying
in
the
chat,
one
question
I
think
we
understand
is
is:
is
it
important
for
the
client
to
be
able
to
discern
whether
it
is
connected
to
a
secure,
a
securely
discovered
insecurely
discovered
to
a
server
or
dot
server?
So
you
know
at
the
beginning,
tommy's
sort
of
opened
by
saying.
Well,
that's
something
any
worse.
O
So,
like
you
know,
if
you
could
already,
if
you
were
already
attacked
connected
to
an
into
a
secure
server,
a
new
attacker,
then,
as
you
still
are,
but
the
number
a
number
of
these
pro
systems
have
the
property.
If
they're
designed
under
specific
designs
that
you
might
upgrade
to
encrypted
connection
to
sit
to
what
you
think
is
this,
they
think
is
the
same
person
and
actually
is
the
same
person
actually
the
attacker
and
but
then
and
which
is
fine
as
long
as
you
don't
treat
that
treat
that
connection
differently.
O
C
M
C
C
We
can
discuss
that
and
see
how
things
go,
but
there
is
a
the
sweet
spot
for
when
we
would
have
it,
which
would
be
near
the
end
of
october
is
coincident
with
an
icann
meeting
and
given
the
significant
overlap
between
the
two
groups,
I
think
that
asking
people
to
try
to
do
an
interim
for
this
and
participate.
I
can
discussions,
might
be
a
little
too
much
thing,
so
I
suspect
we'll
just
not
have
an
intern
between
now
and
the
next
itf
meeting,
but
we'll
have
lots
of
discussion
on
the
list.
B
C
B
Well
I'll
just
say
that
one
of
the
things
that
we're
also
considering
and
will
be
worthy
of
discussion
is
just
what
the
structure
of
our
next
meeting
at
the
ietf
should
look
like
you
know.
Traditionally,
many
itf
meetings
have
been
kind
of
presentation,
heavy
with
a
little
bit
of
discussion,
but
I
we
have
also
seen
groups
like
equip
and
https
run
pretty
effectively
by
running
a
working
group
meeting,
much
like
an
interim
actual
working
group
meeting
and
so
we'll
be
interested
in
hearing
feedback
about.