►
From YouTube: IETF115-ADD-20221108-1300
Description
ADD meeting session at IETF115
2022/11/08 1300
https://datatracker.ietf.org/meeting/115/proceedings/
C
C
B
D
C
C
I
I
appreciate
it
very
much
yeah
yeah
right,
so
you
have
presenter
Grant
yourself,
presenter
right.
C
F
C
F
C
F
C
F
D
I
C
F
Right
all
right,
so
this
so
the
way
this
is
work
setup
is
we're
doing
show
slot
D5
is
going
to
go
first
and
then
add
we
have
slide
sets
for
both
of
them
and
so
I
guess,
Tim's
gonna
remotely
run
the
agenda
for
that
and
I'll
manage
the
slides.
So,
of
course
notewell
applies
this
it's
an
ITF
meeting
and
we
are
all
subject
to
know.
Well,
please
read
it
and
be
familiar
with
it,
especially
ECP
79.
That's
the
best
ITF
meeting
tips.
This
session
is
being
recorded.
F
F
There's
additional
resources
for
itf-150
in
London
you've
already
seen
this
probably
in
other
sessions
and
then
deprive
I'm
told
it
has
a
couple
of
slides,
you're
gonna
show
I.
C
F
You
so
Tim
I
guess
you're
you're
in
charge
here.
E
All
right,
that's
fine,
hi
everyone.
This
is
Brian
Haberman,
quick,
quick
update
from
the
from
the
Deep
Rock
chairs
perspective.
E
Paul
will
talk
a
little
bit
more
about
the
the
unilateral
probing
draft,
but
the
big
thing
that
we
wanted
to
push
across
is:
is
we're
really
starting
to
look
for
for
more
implementations
of
it?
Currently,
the
only
one
that
we're
aware
of
is
the
power
DNS.
So
you
know
thanks
to
Peter,
Tim
and
I
have
been
chatting
about
this,
and-
and
we
have
a
couple
of
thoughts
about
what
we
should
do
going
forward
next
slide.
E
E
While
while
we
wait
for
more
implementations
or
potentially
you
know,
do
the
working
group
Last
Call
on
the
document
to
then
park
it
and
wait
for
more
implementations,
so
that
we
were
sure
that
what
we
put
forth
to
the
iesg
for
submission,
as
an
RFC
is
is,
is
that
stable
and
and
and
as
well
defined
as
possible?
E
So
with
with
that,
you
know
next
slide,
I'm
just
curious.
If
anybody
has
any
comments
or
thoughts
on
that
approach,
especially
on
the
you
know,
waiting
on
implementations
or
the
the
the
state
at
which
we
want
to
park
it.
If
we
do
want
to
wait
for
implementations.
F
And
I'll
just
add
I'm
going
to
assume
that
deprive
as
well
we're
going
to
use
the
in
me
tool
for
doing
queue.
Selection.
So
you've
probably
seen
this
in
other
working
groups
already
this
week,
but
please
use
that.
So
it
subscribes
can
see.
Who
is
making
comments
and
and
going
up
yeah.
J
Hi
Ben
Schwartz
I
work
at
alphabet
I
do
not
work
on
for
the
most
part
on
on
Google,
public
DNS,
I.
Think
the
people
who
do
it,
probably
in
the
room,
but
you
know
I
I-
think
that
Google
public
DNS
is
is
headed
toward
an
implementation
of
something
along
these
lines.
J
But
it
probably
won't
be
precisely
what's
in
the
RFC
and
I
suspect
that
that's
true
of
essentially
many
large-scale
resolver
systems,
which
are
not
going
to
take
the
sort
of
parameters
and
state
machine
directly
out
of
the
draft,
but
are
going
to
internalize
the
ideas
and
and
write
their
own
similar
kind
of
functionality.
J
So
I
think
that
if
you
want
to
talk
about
interoperability,
given
that
this
isn't
really
a
specific
protocol,
so
much
as
a
general
family
of
behaviors
I
think
that's
a
subtle
question.
But
I
do
think
that.
J
It
I
see
Victor
behind
me
in
the
queue
he's
better
positioned
to
talk
about
that.
K
So,
yes,
we
are
doing
probing
of
some
form,
whether
it's
by
the
draft
or
not.
One
of
the
things
that
I
think
might
be
good
to
hear
from
other
implementations
is
questions
around
timing.
I
see
a
lot
of
authoritative
server
implementations,
even
under
light
loads.
You
know
closing
connections
early,
you
know,
after
a
small
number
of
queries
or
after
a
small
time
has
passed,
and
this
creates
complications
for
implementations.
There
are
probably
other
issues
that
other
implementers
will.
C
Great,
thank
you
both
Ben
and
Victor,
and
it's
back
to
you.
Brian.
E
All
right,
thanks
guys
and
I,
appreciate
the
input
there.
The
the
things
that
we
want
to
figure
out
and
Tim
and
I
will
take
the
mailing
list
to
make
sure
that
you
know
we
get
everybody's
input
on
it
is,
is
making
sure
that
what
what
we,
what
else
gets
specified
is
is
as
clear
as
possible
and
as
functional
as
possible.
C
L
C
L
L
Okay,
so
this
is
going
to
be
quick,
not
quic.
This
was
gonna
be
fast.
This
is
just
really
the
status
of
where
we're
at
this
is
not
to
cause
discussion
here.
This
is
really
talking
about
status.
L
L
There
I
only
asked
her
seven
times
to
get
the
presentation,
but
so
for
those
of
you
who
are
only
following
deprive,
you
know,
meeting
to
meeting
what
has
happened
since
the
last
meeting
was
that
Punit
sued
for
from
Google
public
DNS
sent
a
nice
lengthy
list
of
suggestions
and
questions
to
the
mailing
list.
L
We
responded,
we
didn't
do
everything
he
asked,
but
we
responded
to
everything
and
we
did
a
bunch
of
the
stuff
that
he
asked
and
put
out
a
significantly
revised
draft.
Nothing
technical,
changed
I
believe,
but
in
fact
there
was
a
bunch
more
there
and
referencing.
What
Brian
was
just
saying.
We
want
to
know
what
implementers
and
potential
implementers
oh
I
was
like
I.
Don't
need
to
wear
that
at
the
moment.
We
want
to
know
what
implementers
and
potential
implementers
are
not
finding
in
the
draft.
L
What
we're
sure
of
is
that,
once
this
is
deployed
and
there's
two
more
implementers
out
there,
there's
going
to
be
implementation
experience.
What
we
want
is
the
draft
ready
to
go
to
work
in
group
last
call
with
as
much
as
we
can
know
in
that
state.
L
So
we
asked
for
more.
You
know.
After
we
put
out
the
last
draft,
we
asked
for
more
comments
on
on
the
mailing
list
and
we
only
heard
crickets
now
this
is
most
likely,
because
the
only
people
who
actually
need
to
care
about
this
draft
are
resolver
implementers.
It
turns
out
that
authoritative
implementers
don't
need
to
do
anything
in
the
draft.
The
whole
section
on
suggestions
for
authoritative
implementers
there's
only
one
thing
that
you
might
want
to
do
and
you'll
either
do
it
or
not.
L
Everything
else
is
we
suggest
you
look
at
this
and
you
watch
out
for
that.
It's
the
recursive
implementer,
so
there
aren't
that
many
of
them
out
there
that
some
of
the
people
from
those
recursive
implementations
are
in
the
room,
I,
don't
think
punitz,
actually
in
the
room
and
Victor
is,
is
you
know
off
so,
as
Brian
said
on
his
slides,
we
know
that
powerdns
recursor
has
done
an
implementation.
L
They've
talked
about
it,
a
bit
we'd
love
to
to
hear
more,
if
there's
anything
else
in
there,
but
that's
where
we're
at
now.
This
is
what's
happened
since.
A
L
There
are
some
open
issues,
there's
a
few
open
issues
that
we
have
on
the
GitHub
repo
within
a
month,
we're
going
to
close
them
out
we're
going
to
do
them
or
close
them.
Sarah
I'm
going
to
point
at
you
right
through
the
camera
there
we're
not
sure
if
we've
done
what
you
asked
for
eons
ago,
we
think
we
might
have.
But
if
you
have
time
in
the
next
month,
can
you
check
our
work?
L
Sarah
gives
a
thumbs
up
any
other
implementers
who
are
reading
this
or
people
who
are
not
implementers
but
think
they
know
how
it
is
to
make
a
recursive
implementation.
Please
review
the
draft
like
Brian
said
we
aren't
saying:
You
must
do
this.
You
can't
do
this
as
much
as
you
really
should
do
this
and
such
like
that.
L
Please
check
our
work
so
we'll
have
a
new
draft
in
about
a
month,
we'll
turn
it
in
and
then
we're
going
to
ask
for
more
discussion
on
the
mailing
list,
and
then
we
were
going
to
ask
for
a
working
group
last
call
in
January
as
Brian
just
indicated.
L
We
don't
know
whether
it's
a
working
group
last
call
that
will
then
fling
this
towards
the
ietf
or
be
parked
or
whatever
I
think
we
could
get
enough
implementation
experience
by
then,
if
some
of
the
implementers,
even
the
ones
who
haven't
implemented
but
looked
at
the
pseudo
code
and
said
oh
I,
can
do
that.
I
can't
do
that.
K
Note
is
that
authoritative
server
operators
are
also
implementers
when
they
turn
it
on
and
we're
beginning
to
hear
back
from
some
of
them.
You
know
wanting
to
tune
things
with
us
and
so
on
so
I
think
there's
room
to
invite
authoritative
server
operators
to
also
talk
about
their
experience
in
terms
of
scaling
or
various
other
things
or
what
they
would
like
to
see
from
resolver
Behavior.
L
Some
of
the
some
of
the,
even
though
the
document
doesn't
say,
here's
what
resolver
operators,
here's
what
authoritative
operators
should
do.
Some
of
them
have
been
testing,
especially
with
the
Power
DNS
implementation.
They
may
have
come
up
with
some
thing,
and
that
may
be
an
addition
to
this
or
not
we're
trying
to
be
again.
The
whole
idea
is
this
is
unilateral,
probing
we're
trying
to
be
as
unprescriptive
as
we
can
to
make
a
system
that
works
and
doesn't
fail.
L
Anybody,
that's
a
funny
balance,
but
I
think
we're
pretty
much
already
there,
but
we
need
to
hear
more
is
that
it
for
the
cube,
yeah.
Okay,
thank
you
so
great.
If
you
want
to
read
now,
please
read
now:
if
not
please,
plan
on
reading
in
December
a
lot
of
people
don't
like
to
read
in
December,
so
if
you'd
rather
read
in
November,
please
do
now.
Let
us
know!
Thank
you.
Lots
of
eggnog
helps.
C
Thank
you,
Paul,
thank
you
Victor
and
thank
you
in
advance.
Sarah.
E
No
Glenn
and
Dean
that
I
think
that's
it
for
the
deprived
sessions.
Unless,
unless
folks
have
other
comments,
they
want
to
make
I
will
turn
it
over
to
you
guys
for
ADD.
F
This
is
an
ITF
meeting,
so
notewell
does
apply
and
if
you
haven't
heard
of
bcp79,
it's
awesome.
Itf-150
meeting
tips
is
being
recorded.
Just
like
the
previous
session.
Was
these
resources.
F
I
will
remind
you
that,
because
this
is
a
an
ITF
meeting
for
those
who
just
joined
the
room,
we
are
required
to
wear
masks
in
here.
So
please
mask
up
and
let's
actively
speaking
of
the
microphone
I'm
glendina
with
your
add
co-chairs.
F
So
We've
selected,
the
Scribe
we've
walked
from
the
chairs
we've
any
comments
from
the
80
Eric
that
you'd
like
to
make.
G
H
I'm
so
used
to
being
in
the
mic
line.
So
the
main
comment
I
have
is
about
the
document,
the
three
document
that
has
been
approved
by
the
isg,
the
DNA
Diddy
and
the
svcb
they
are
approved.
They
are
into
the
rscd
Tokyo
waiting
for
DNS
up
document,
which
is
also
approved
waiting
into
the
rsd2q
for
a
TLS,
encrypted
Sni
or
ech
hello,
which
is
still
not
in
real
quick
as
far
as
I
know.
So
we
can
expect
those
document
meeting
a
lot.
H
We
are
trying
to
find
inventive
way
and
making
some
kind
of
a
process
engineering
mostly
to
remove
part
of
the
DNS
of
blocking.
And
then,
if
you
remove
DNS
up
blocking
DNS
of
progress
and
then
our
three
LED
document
will
be
going
forward
and
do
we
be
published.
So
it's
basically
outside
of
our
controller.
F
Thank
you,
okay.
So,
let's
get
on
to
the
drafts,
the
first
one
tiru
you
want
to
come
on
up.
C
Well,
did
you
want
to
attend
the
dash,
though.
M
I
wanted
to
discuss
a
draft
that
was
created
by
us
to
address
some
of
the
discusses
that
were
raised
during
the
publication
as
part
of
Isaac
review.
Paul
and
a
few
others
had
raised
comments
and
we
wrote
a
draft
specifically
for
the
texts.
If
you
have
time,
we
would
like
to
discuss
that.
F
Well,
we're
you
know
we're
running
good
on
time,
so
I
don't
see
any
problem
with
that.
So
let's
do
that.
Yeah
thanks
a
lot
about
it,
okay,
so
onto
the
drafts
that
we're
scheduled
and
we'll
get
to
the
other
one.
At
the
end,
the
very
first
one
was
your
split
Horizon
DNS
configuration
draft
and
let
me
bring
that
up.
M
Thanks
so
this
is
mainly
the
changes
we
have
done
to
address
comments
from
the
working
group
next
slide,
please.
M
M
So
in
the
previous
versions
of
the
draft,
the
scope
was
restricted
to
just
using
DNR.
Then
Tommy
Polly
had
come
up
with
a
comment
that
we
could
leverage
this
draft
even
with
when
DDR
is
present,
and
we
update
to
the
graph
so
that
we
can
use
TDR
both
in
verified,
Discovery
and
opportunity,
Discovery
modes.
M
So
if
you
look
at
this
figure,
if
even
though
IB
address
is
used
to
discover
and
validate
the
discovered
certificate,
if,
if
the
subject
all
time
extension
within
the
certificate
has
the
name
server
records
that
you
would
later
find
by
doing
a
DNS
query,
either
using
a
external
resolver
or
DNS
SEC,
and
if
they
both
match,
then
it
proves
that
the
discovered
encrypted
resolver
is
in
hybrid
resolver,
which
is
authentic
to
provide
responses
for
this
split
Horizon
domains
and
in
that
way,
DDR
can
also
be
used
similar
to
the
way
DNR
is
being
used.
M
That's
first
part
of
the
change.
The
second
part
was
next
slide.
Please
yeah.
The
next
slide
was
with
regard
to
opportunistic
Discovery
in
opportunistic
Discovery.
There
are
two
modes,
basically
where
the
client
does
validation
of
the
pka
certificate,
or
it
basically
skips
and
does
not
do
any
certificate
validation.
M
If
it
doesn't
do
any
search
validation,
then
this
mechanism
is
not
applicable,
but
if
it
does
PKA
validation
and
even
though
it
is
an
let's
say,
a
private
IP
address
that's
being
discovered,
but
if
the
name
that
you
find
in
the
subject
alternate
matches
that
what
you
find
in
the
name
server
records,
then
you
know
that
it's
an
that's
a
successful
match
and
you
could
use
DDR
way
of
verified
Discovery
even
in
the
opportunity
discovery
mode.
M
Next
slide,
yeah
one
of
the
comments
from
Ted
lemon
was.
We
could
not
use
the
mechanisms
discovered
in
discussed
in
the
draft
for
specialization
domain
names.
They
are
not
unique
to
any
specific
DNA
servers
Authority
and
they
should
be
kept
outside
the
scope
of
this
draft.
So
we
added
added
a
paragraph
to
say
explicitly
that
these
scdns
are
outside
the
scope
and
added
some
normative
text
to
say
that
scdns
must
not
be
validated
using
the
two
mechanisms
that
we
have
defined
in
this
draft
next
slide.
N
F
Okay
and
yeah.
F
M
Okay,
thanks
yeah.
This
is
another.
This
is
an
individual
draft
that
we
have
it's
been
discussed
in
several
previous
IQs
and
we
have
been
updating
the
draft
to
address
the
comments
next
slide.
Please
yeah.
The
last
common
major
comment
that
we
got
at
the
last
ITF
was:
don't
use,
Json
encoding,
it's
not
the
right
way
of
doing
it
and
the
suggestion
was
to
use
key
value
syntax.
Just
like
the
way
dnsst
does
so
we
changed
the
entire
draft
to
abandon
using
Json
encoding.
Now
it
uses
key
value
pairs.
M
M
Yeah
discovering
presolver
information
is
part
of
the
charter
and
I
think
this
is
also
one
of
one
of
the
reasons
this
working
group
got
created
and
we
would,
since
we
have
addressed
all
the
comments-
and
there
was
some
traction
on
this
draft-
we
think
it's
ready
for
working
to
production.
C
No
I
can
skip
that.
That
was
just
for
backup.
Okay,
do
you
actually
go
and
want
to
get
a
sense
right
now
of
how
people
feel
about
working
group,
adoption
or.
F
C
Don't
even
know
if
we
have
to
do
that,
but
first
with
anybody,
the
queue
is
open.
If
anybody
would
like
to
comment
on
that
either
way,
and
then
we
can
also
run
a
quick
hum
on
the
tool
as
far
as
a
working
group
adoption.
But
of
course
the
actual
official
adoption
call
would
be
on
the
mailing
list,
but
it
would
be
nice
to
have
a
sense
of
the
room,
at
least
as
far
as
how
people
are
feeling.
C
N
C
There
is
a
slight
bias
toward
adoption,
we'll
be
brought
up
on
the
list
again,
so
that
people
can
say
explicitly
if
they
were
opposed
to
adoption
or
not,
because
sometimes
the
do
not
raise
hand
is
a
little
inscrutable
to
interpret,
but
so
be
be
on
the
lookout
for
a
request
on
the
list
toward
working
group.
Adoption
on
this.
Thank
you.
O
O
So
this
is
normally
load
balancing
among
multiple
encrypted
DNS
servers
globally
is
handled
by
any
cast,
so
you
can
hand
out
one
configuration
to
clients
and
then
they
magically
end
up
where
they
need
to
be.
However,
this
requires
significant
resources
to
get
correct,
not
that
anyone
has
experienced
any
major
issues
with
bgp
missteps
recently,
but
it
has
been
known
to
happen,
and
so
this
tends
to
have
a
centralizing
effect
right,
because
you
have
to
have
a
large
enough
infrastructure
to
do
it
correctly
to
get
the
benefits
of
any
cast
next
slide,
please.
O
Otherwise.
You
end
up
with
Distributing
unicast
configurations,
and
so
you
say:
well,
we
have
these
30
servers
and
the
clients
need
to
be
aware
of
them,
or
we
have
to
somehow
distribute
each
individual
config
to
the
right
client,
depending
on
where
they're
at
which
brings
in
its
own
complications
and
then
even
when
you
do.
If
the
client
ends
up
in
the
wrong
place,
you
have
compliance
or
performance
issues
and
then
for
the
server.
It
has
no
flexibility
to
shed
traffic
that
is
being
overloaded
with
next
slide.
O
Please
so
we're
looking
to
find
a
way
to
allow
servers
to
redirect
to
one
another
to
address
those
problems
such
that
you
wouldn't
need
to
have
any
cast
bail
to
redistribute
clients
where
they
need
to
be
and
still
only
have
to
distribute
whatever
configurations
you
want
for
your
setup.
O
We
don't
want
to
reduce
the
security,
like
whatever
new
connection
you
end
up
on
shouldn't,
be
less
secure
than
the
one
you
started
on
it.
Shouldn't
Break
compat
following
redirections
shouldn't
end
up
with
a
connection
that
you
don't
know
how
to
support
or
to
a
server.
You
don't
know
how
to
support
and
it
should
work
across
protocol
versions.
We
have
three
major
implementations
of
encrypted
DNS
today
and
we
shouldn't
be
doing
one
of
these
drafts
for
each
one
and
then.
Finally,
as
always,
let's
not
waste
too
many
milliseconds
next
slide,
please.
O
So
what
we're
proposing
is
a
reuse
of
the
DDR
mechanism
for
those
who
are
familiar,
we're
going
to
use
the
resolver.arpa
sudn
and
just
ask
the
server.
So
when
you
first
set
up
your
encrypted
DNS
connection,
you
send
a
query
for
resolver.arpa
and
ask
the
resolver
about
itself.
Are
you
designating
anyone
in
this
case
as
a
redirection
and
not
as
a
companion
encrypted
DNS
server?
O
Note
that
this
is
slightly
different
from
the
use
case
that
DDR
covers,
which
is
that
you
already
starting
with
encrypted
DNS,
which
DDR
mentions
when
you're
looking
up
other
resolvers?
This
is
asking
to
resolver
about
itself,
which
DDR
supports
over
plain
text
since
we're
starting
with
encrypted
and
ending
with
encrypted.
We
can
go
back
to
the
traditional
authentication
model
and
we'll
authenticate
the
name
of
the
destination
server
without
having
to
do
any
of
the
IP
address.
Tie-Ins
next
slide,
please.
O
So
as
an
example,
let's
say
that
a
client
is
configured
to
use,
dodash
sydney.site.example
and
then
you
start
traveling
abroad.
You
go
to
a
conference
and
the
server
sees
you
coming
from
a
parasite
p
and
says,
and
he
really
belongs
somewhere
else,
and
so
when
the
client
sends
the
query
for
the
a
and
a
quad,
a
and
service
binding,
ignore
that
AAA
it'll
send
back
a
service
binding
record.
O
That
says,
you
should
actually
be
talking
to
dodash
Paris,
and
the
client
will
then
establish
a
TLS
connection
to
that
server
and
check
to
make
sure
the
certificate
is
valid
for
DOT
or
dodash
Paris
and
when
it
is
we'll
replace
the
connection
and
then
move
on
with
our
lives
happily
ever
after
the
security
model.
Here
is
something
that
we're
trusting
because
by
using
the
contents
of
a
DNS
query,
it's
exactly
as
trusted
as
if
we
just
stayed
on
this
resolver
in
the
first
place.
O
In
other
words,
if
an
attacker
were
able
to
compromise
this
redirection,
they
were
also
compromising
your
query.
Contents
next
slide.
Please.
C
Tommy,
would
you
mind
an
interruption?
No.
J
O
O
So
a
couple
considerations
so,
as
with
any
other
redirect
there's
a
potential
for
leading
the
clients
around.
There
should
be
some
considerations
that
just
like
C
names,
don't
don't.
Please
don't
do
that.
O
Additionally,
there's
a
potential
for
breaking
compat
here,
let's
say
that
the
original
server
you
start
with,
supports
dot
and
you
contacted
over
dot
and
you
ask
it
for
a
redirection,
and
it
gives
you
one
to
a
doe
only
server,
it's
possible
that
the
client
also
supports
dough,
but
it's
possible
that
it
doesn't,
and
this
would
be
a
broken
scenario
that
would
result
in
either
the
client
losing
encrypted
DNS
connectivity
or
deciding
to
just
hang
around
on
the
original
server,
which
obviously
it
didn't
want
either,
and
so
it
requires
you
to
redirect
to
a
server
that
at
minimum
supports
the
same
protocol
and
IP
family.
O
That
this
connection
is
using
such
that
it
knows
that
the
client
ought
to
be
able
to
talk
to
the
next
one.
Maybe
additional
information
is
in
the
service
binding
and
it
can
choose
to
do
a
different
protocol
if
it
wants
that'd
be
great,
but
at
least
make
sure
that
it
can
speak.
O
Something
next
slide:
please
shh
all
right,
so
there
were
some
Alternatives
that
we
considered
when
designing
the
solution,
one
when
talking
about
redirection,
there's
an
obvious
solution
in
the
300
return
codes,
except
that
that's
very
specific
to
http,
which
means
that
we
have
a
dose
solution
and
not
a
DOT
or
doc
solution,
and
so
we
didn't
consider
that
ideal.
O
The
other
is
alt
service
binding
and
for
those
of
you
who
are
unfamiliar,
there's
some
work
going
on
in
the
HTTP
working
group,
where
we're
introducing
a
DNS
record
that
or
we're
using
service
binding
to
replace
all
service.
Eventually,
it's
a
strong
and
overloaded
term
replace,
but
for
now
augmenting
the
scope
of
this
is
a
little
different,
though
that
allows
you
at
a
domain
level
to
say
these
are
alternatives.
For
me,
that's
not
exactly
what
we're
looking
for
right,
because
this
is
per
connection
Behavior.
O
It
may
be
that
I
actually
want
that.
The
original
server
wants
to
receive
these
and
it
doesn't
want
an
alternative,
but
once
every
at
once,
every
year,
on
the
day
after
Thanksgiving
I
want
to
redirect
start
redirecting
people
to
other
servers
that
I
spun
up
that
one
day
a
year
to
handle
all
the
excess
traffic
that
I'm
getting
next
slide.
Please.
O
All
right,
so,
in
conclusion,
we
believe
we've
identified
a
one-size-fits-all
solution
so
that
if
the
working
group
were
to
adopt
this
and
move
forward,
that
we
would
not
need
to
revisit
redirection
again,
this
should
work
for
all
common
encrypted.
Dns
scenarios
it'll
help
level
the
playing
field
a
little
bit
to
help,
simplify
and
lower
the
bar
for
what
it
takes
to
deploy
a
multi-node
DNS
system
across
the
world
for
smaller
operators.
O
C
J
Okay
hi,
can
you
hear
me.
J
So,
okay
I
think
this
is
a
great
goal
I'm
all
for
it.
There's
no
reason
that
DNS
server
has
to
live
on
a
single
IP
address
in
this
world.
J
It
sounds
to
me
like
you're,
assuming
that
you
are
bootstrapped
from
a
name.
You
already
have
a
trust
anchor
name
for
this
service.
J
That's
great!
That
means
presume
that
to
me
that
suggests
that
we're
in
DDR
section
five
Discovery
using
resolver
names,
so
the
client,
in
order
to
make
this
connection
in
the
first
place,
started
from
a
name.
Did
a
service
B
query
for
underscore
dns.name
and
got
back
its
list
of
service
bindings
with
with
different
options.
J
So
so
at
that
point
we
already
had
an
opportunity
to
send
the
client
out
to
into
into
the
right
node
right,
because
we
can
serve
geolocated
load,
balance
and
optimized
answers
to
that
service.
B
query-
and
it
sounds
like
your.
This
draft
is
about
the
case
where
that
step,
didn't
work
right
and
the
user
ended
up
at
the
wrong
place.
Is
that
right.
O
So
I'd
say
that's
one
narrow
scenario
where
this
applies,
but
it's
much
more
General
than
that.
So,
first
of
all,
you're
right.
If
the
client
got
to
it,
the
first
server
via
DDR,
there's,
probably
an
implementation
opportunity
for
whoever
runs
the
plain
text
resolver
it
bootstrapped
from
to
have
re
directed
them
correctly.
In
the
first
place,
however,
this
is
generic
to
wherever
I
got
it,
and
so,
if,
as
a
user
I
type
in
dot
Sydney
into
my
Android
UI
Windows,
UI,
Chrome,
UI,
Firefox,
UI,
anything
and
then
I
travel
abroad.
O
J
O
Five
is
about
asking
for
a
given
name
and
yes,
so,
for
example,
it
doesn't
use
resolver.arp.
If
I'm
thinking
of
the
right
section,
you're
you're,
asking.
O
You
say:
hey
server
and
maybe
it's
the
same
server
or
not
whatever
I
want
to
ask
for
records
for
dodash
Sydney.
The
problem
is
I,
don't
know
anything
about
in
the.
If
you
wouldn't
mind,
reversing
to
the
example
slide
so
that
I
can
refer
to
right.
You
start
with
dodash
Sydney
I
know
about
dodash,
Sydney,
everything's,
great
I,
don't
even
know
as
a
user
or
my
device
that
dodash
Paris
exists.
N
J
I
understand
that
that's
how
this
is
is
set
up
here,
where
you
have
distinct
names
for
each
of
these
entry
points,
but
I
don't
see
why
you've
set
it
up
that
way,
why
not
just
use
the
same
name
for
all
of
the
sites
and
use
and
use
geodns
essentially
to
serve
the
right,
IP
addresses
and
have
you
know
so
all
of
these
various
IP
addresses
they're
all
IP
addresses
of
Dot
site.example.
O
Sure
John
I
don't
know
if,
if
you're
on
Mike
available,
but
I
can
already
hear
the
IP
database
shortcomings
argument
coming.
I
Sure,
that's
that's
one.
Additionally,
I
would
say
that
this
also
permits
cross-domain
repointing
as
well,
so
you
can
actually
pass
off
responsibility
to
different
operators,
so
in
other
words,
you
can
Rendezvous
on
one
domain
but
then
re-transfer
to
another.
That
may
be
good
or
maybe
bad,
that's
going
to
be
site
or
implementation
specific,
but
this
does
allow
that
versus
having
to
have
everything
in
one
single
database
with
one
single
lookup
at
this.
At
the
very
first
point
of
interaction.
J
Validation,
names
and
I
want
to
be
clear
that
this
is
not
about
managing
a
single
set,
a
a
very
large
number
of
of
a
records
on
a
single
name,
because
service
B
provides
that
level
of
indirection.
Where
you
can
say,
okay,
you
wanted
to
resolve
underscore
dns.do.site.example,
here's
a
list
of
RRS.
You
know:
here's
the
here's
Paris
Dot
site,
that
example
in
the
Target
names,
here's
a
bunch
of
different
Geo
Target
names,
those
don't
affect
the
the
identity
of
the
service,
the
the
security
anchor
so.
J
I'm
not
sure
I
understand
the
I
think
I've
been
kicked
off
of
the
network.
C
And
then
we
do
have
a
long
Queue
at
the
moment.
So
if
you
want
to
hop
on
the
the
end,
I
want
to
hear
from
a
few
other
people
right
now
so
Ted
you
dropped
out
of
the
queue
but
you're,
but
take
the
mic,
because
you
were
next.
B
B
Me
yeah
Ted,
Hardy
Cisco,
also
Arthur,
one
of
the
original.
H
B
Dns
drafts,
3258
and
I
think
what
I'm
coming
to
ask
about
is
similar
to,
although
slightly
different
from
Ben's
question,
which
is
from
this
slide.
You
start
from
a
fact
that
a
client
is
configured
to
use
dot
sydney.site
to
exam
and
because
it's
configured
to
use
a
specific
name
later
during
its
lifetime.
When
it's
been
geolocated
by
the
server
that
it's
talking
to
to
being
somewhere
else,
the
server
triggers
a
what's
in
essence,
a
reconfiguration
was
why
don't
you
call
it
by
the
same
name?
B
My
question
is:
why
are
you
driving
the
reconfiguration
from
the
server
side
and
not
the
client
side
if
you've
got
this
set
up
with
a
client,
that's
configured
to
use
a
particular
example
forever,
then
this
is
a
problem
you
have
to
solve
at
the
server
side,
but
if
you've
got
it
set
up
so
that
the
client
knows
that
it's
reattaching
to
a
new
network,
which
is
something
we
use
to
drive
other
things
like
mac
address
changes
for
privacy
Etc,
you
could
use
that
to
drive
whatever
the
initial
configuration
is
that
it
would
use
to
find
out
what
it's
appropriate
server
would
be.
B
That
means
that
you're,
starting
from
the
same
place
both
times
that
looks
like
a
logical
thing
to
do
and
I
didn't
see
it
in
your
Alternatives
considered
so
I'd
like
to
know
whether,
when
you
considered
it
and
why
you
rejected
it,
if
not
and
if
you
didn't
consider
it,
why.
O
Thank
you.
That's
a
good
question,
so
I'm
also
noticing
you
can
get
into
the
queue
if
you
want
I'm,
seeing
some
emphatic
reactions
in
the
crowd,
so
I'm
going
to
defer
to
John
in
a
moment.
But
this
is
something
that
we
had
talked
about
and
we're
looking
at
operator.
Flexibility
right,
so
you're,
correct,
I
mean
I
work
on
a
OS
platform,
right,
endpoint
configuration
and
doing
it.
O
That
way
we
usually
prefer
to
network
configuration
because,
like
you
said
this,
is
you
could
look
at
it
that
way
as
a
reconfiguration
of
the
device,
but
it's
far
less
flexible
right
like
if
I'm,
if
I'm
working
for
a
company
and
and
we
have
a
custom,
encrypted
DNS
Fleet
and
we
have
30
locations.
Let's
say
we
add
five
more
do
I
need
to
go
teaching
all
of
them
when
and
where
they
apply
or
can
I
just
let
the
system
handle
it,
I've
configured
them
with
one.
Then
it
will
do
another
now.
O
I
do
think
that
there's
a
a
ux
opportunity
there
right,
maybe
whether
through
login
or
through
UI
or
whatever
else.
You
need
to
be
honest
about
what
your
new
endpoint
is,
but
both
with
this
and
with
the
sharing
names
we
just
didn't
see
the
it
seems
like
an
artificial
burden
to
require.
Whoever
is
configuring
this
to
have
to
do
that
at
the
end
point
when
the
DNS
could
just
handle
it
for
you,
so.
B
This
is
going
to
be
an
interesting
conversation
in
the
working
group.
If
this
is
brought
to
the
working
here,
because
I
completely
disagree
I
think
it's
actually
far
more
flexible.
If
the
client
does
it,
because
the
client
may
decide
based
on
attachment
to
specific
networks
that
it
doesn't
want
to
use
this
at
all,
it
wants
to
go
someplace
completely
different,
and
if
it's
getting
redirected
from
something
that's
in
essence,
hard-coded,
it
doesn't
get
that
flexibility,
so
I
think
we.
We
may
have
a
philosophical
discussion.
B
We
have
to
have
here
on
whether
it's
up
to
the
DNS
to
determine
what
your
next
resolver
is
or
up
to
you
to
reconfigure
with
advice
from
the
DNS.
What
your
next
resolver
is
and
I
think
the
DDR
actually
does
the
advice
from
the
the
DNS
for
the
client,
configuration
and
I.
Don't
think,
that's
quite
what
you're
doing.
O
Okay,
so
thank
you
and
it
sounds
like
that'll,
be
a
good
mailing
thread
discussion
as
a
co-author
on
DDR
I,
whether
it's
advice
or
configuration
I
guess
could
be
debatable.
Thank
you
regardless,
let's,
let's
start
an
email
thread,
yep
Ralph,
please
that'll.
A
O
Good
question:
it's
not
directly
called
out
or
accounted
for,
but
since
because,
unlike
plain
text,
bootstrapping
DDR,
the
identity
here
is
the
name.
If
it
redirects
to
the
same
name.
No
action
should
be
necessary.
P
P
P
I'll
just
speak
loudly,
so
I
do
see
that
the
server
may
be
able
to
give
a
better
response
when
it
has
more
information
about
the
client.
That's
more
direct
indis,
TLS
connection
I
also
do
agree
with
Ted
that
we
should
have
things
be
mainly
driven
by
client
Network
changes
for
handling
different
regions
Etc,
but
certainly
when
I
first
joined
a
network
and
I
use
a
UDP
query
over
the
network
resolver
to
find
the
location
of
sydney.site.example.
P
It
may
route
me
incorrectly
due
to
the
client
subnet
not
being
available
through
the
UDP
resolver
or
some
other
issue,
and
in
the
experience
we
have
with
our
doe
and
oblivious
dough,
resolvers
that
we're
using
for
private
relay.
We
already
do
some
what
we
call
Doe
bootstrapping,
which
is
when
once
we
connect
to
our
resolver,
we
ask
it
for
its
own
records
again
to
see
if
it
has
better
higher
Fidelity
answers
for
us,
so
I'm
wondering
if
maybe
we
could
just
do
that.
P
I
think
that's
agreeing
with
what
Ben
was
saying
instead
of
doing
resolver
about
arpa.
Just
do
the
original
the
svcb
query
for
the
original
name
again
so
like
when
I
join,
a
new
network,
I
find
my
resolver
and
then
I
immediately
ask
it
for
its
own
identity.
Again,
just
to
see
if
my
local
network
resolver
routed
me
slightly
incorrectly.
O
So
if
I'm
following
is
there
a
significant
difference
other
than
querying
for
the
name
of
the
resolver
you're
currently
using
versus
the
sudn?
Is
the
behavior
otherwise
the
same
or
is
there
another
difference?
I'm
missing.
P
O
Okay,
okay,
so
yeah.
Obviously
we
have
some
thinking
to
do.
Thank
you,
you
and
Ben
for
bringing
that
up.
I
can
see
how
that
might
be
simpler,
but
I
I
haven't
had
enough
time
to
chew.
On
that
and
say
we
haven't
forgotten
about
something
that
drove
our
original
decision.
Thank
you.
Yeah.
C
G
G
As
soon
as
you
start,
switching
people
with
different
resolver,
you
run
into
all
the
problems
that
we
already
discussed
with
99,
and
so
at
least
this
should
be
the
subject
about
the
privacy
and
operational
consideration
section
because
I
mean,
if
you
really
use
this
just
to
switch
people
to
a
result
which
is
in
in
the
same
jurisdiction
run
by
the
same
company
and
under
the
same
policies.
Nothing
bad
happens.
G
G
We
might
leave
this
to
whoever
is
running
this,
to
take
care,
that
everything
is
actually
legal
and
in
line
and
in
line
with
user
expectations,
because
I
agree
that
if
we
assume
that
people
actually
wrote
a
type
of
the
sleep
name,
maybe
they
really
want,
even
if
they
are
in
France,
they
want
to
speak
to
a
server
in
Australia
not
to
serve
in
France,
which
maybe
maybe
forced
to
apply
French
law.
So
I
mean
I
I'm
fine
with
this,
but
at
least
this
needs
to
be
documented
in
the
draft.
If.
I
You
want
to
proceed,
but
I
might
have
actually
a
comment
on
that.
One
I
would
argue
that
this
actually
makes
that
kind
of
policy
decision
easier,
because
when
you
have
an
any
cast
array,
of
course,
your
packets
are
going
to
go
whatever
is
closest.
As
far
as
the
network
is
considered.
This
allows
redirection
to
a
unicast
address
which
is
in
the
same
policy
zone
or
the
belief
at
least,
is
that
it's
in
the
same
policy
Zone
as
the
queryer.
I
C
Limon
said
we
know
with
unicast,
but
that's
a
whole
separate
thing.
Thank
you,
Victoria
Victor,
please.
K
Direct
it's
mandatory
or
are
they
just
advisory
and
the
client
can
keep
going
with
the
same
resolver?
And
secondly,
you
mentioned
multiple,
redirect
hops,
I'm,
very
skeptical,
about
the
need
and
wisdom
of
allowing
second
and
third,
and
so
on.
Redirects.
O
So
let
me
answer
the
second
I
might
have
to
have
you
repeat
the
first,
the
audio
started
cutting
in
halfway
through,
but
for
redirects.
That's
actually,
that's!
Actually
our
point
is
we
don't
want
you
doing
multiple
redirect
chains?
So
if,
if
what
you
want
to
see
is
stronger
guidance
about
you
know,
clients
are
free
to
start
ignoring
them
after
the
first
one,
I'm.
Certainly
fine
with
that,
but
agreed.
K
Right,
the
the
first
question
was
whether
redirects
are
mandatory.
Do
you
have
to
follow
them,
or
can
you
just
stick
with
the
resolver,
despite
its
preference,
to
send
you
elsewhere.
O
So
that's
a
good
question.
I
think
that's
going
to
inform
some
of
the
other
comments
about
consent
and
policy
which
is
no
they're
not
intended
to
be
mandatory.
It's
it's
all
about
optimization
right
now,
I'll
John
feel
free
to
to
chime
in,
but
currently
it's
not
a
mandatory,
and
so
the
server
is
required
to
be
able
to
handle
the
case
where
the
client
persists.
Now,
if
it's
overloaded,
it's
of
course
free
to
Simply
close
the
connection,
but
it
isn't
mandatory
because
we
don't
have
servers,
dictate
policy
to
clients
in
this
working
group.
I
C
I
I
saw
you
just
turned
on
your
mic:
yeah
there's
also
backwards.
Compatibility
of
you
know.
No,
that
I
would
say
that
it
is
not
mandatory.
This
is
for
better
performance,
but
it
is
not
a
requirement
for
the
clients
at
all.
Q
Yeah,
so
you
obviously
HTTP
has
similar
use
cases
that
exist
and
those
are
being
worked
on
there.
You
call
them
out
as
alternative
proposals
and
say
they
don't
quite
work
here
but
same
time.
Hp
is
still
HTTP
and
those
will
still
exist
for
encrypted
DNS
over
HP.
So
how
do
you
see
them
interacting
together?
Should
we
are
you
proposing
we
ban
using
those
mechanisms
like
redirect
and
alternate
service
for
DNS
servers
operating
on
DNS
over
HPS?
Do
you
see
them
just
being
able
to
use
both
which,
in
that
case,
do
they
have
the
problem?
Q
We
might
have
two
completely
different
redirects
and
we
might
have
the
ambiguity
case
of
inconsistent
Behavior.
If
one
client
follows
one
and
the
guy
follows
the
other,
do
we
mandate
specific
mechanisms,
for
you
must
follow
this
one?
If
you
get
both?
What
was
the
interaction
story
here?
Is
this?
Do
you
have
the
vision
for
that,
or
is
it
something
that
needs
to
be
developed.
O
The
latter-
and
so
we
can
go
entirely
into
Tommy
opinion
land
now,
but
I
really
don't
want
to
do
both
right
per
query.
Overhead
on
redirect
is
something
I
don't
ever
want
to
support,
because
I
I
I'm
configured
to
use
a
resolver
right,
it's
a
little
different
from
HTTP,
where
each
resource
is
located
somewhere
else.
A
recursive
resolver
is
supposed
to
answer
all
my
questions,
and
so
no
I
don't
want
them
to
coexist.
I
don't
want
to
use
300
at
all
when
I'm
using
dough.
Q
But
at
the
same
time,
I'm
thinking
for
some
clients
that
may
only
use
DNS
or
HBS
because
they're
encrypted
DNS
mechanism,
some
servers
that
only
use
that
they
may
be
looking
at
saying,
hey,
we
only
care
about
HTTP
HTTP
is
a
mechanism
that
can
solve
these
problems.
We
should
just
solve
it
there,
even
if
nothing
perfectly
exists
to
solve
our
use
cases
there
today.
Q
Let's
add
it
to
hdb
saw
our
use
cases
what's
motivating
them
to
not
say
we
just
want
to
sell
this
nation
B,
and
then
we
have
this
problem
of
some
servers
will
be
trying
to
do
some
to
solve
some
cases,
and
we
have
that
interaction.
So
I
feel
like
this
is
we
can't
just
say
as
well
exist,
there's
going
to
be
the
interaction
I
think
we
need
to
solve
it
somehow
and
that
gets
into
the
question
of
maybe
some
people
might
say
we
don't
want
this
at
the
same
time.
Q
I
Yeah
I
guess
I
would
say
that
it
seems
like
a
more
Universal
solution,
would
be
the
preferred
choice.
I
agree
that
they're
they're,
in
fact
there
are
going
to
be
probably
multiple
different
ways
of
doing
this
in
a
variety
of
the
different
subprotocols
and
DNS.
Why
wouldn't
you
just
pick
the.
Q
One
more
Universal
solution
is
especially
tricky
here
because,
yes,
I,
agree.
More
Universal
Universal
is
better,
but
is
more
Universal
as
in
solving
more
DNS
cases
or
you
more
Universal
as
an
HTTP
is
a
much
bigger
thing
than
DNS,
and
so,
if
you
that
fits
within
your
scenario,
that's
more
Universal.
So
while
more
Universal
is
a
good
goal
to
go
for
it's
not
really
clear
in
this
case,
which
one
is
more
Universal,
so
I
think
we
still
end
up
with
this
situation,
where
It's
tricky
to
make
decisions.
J
Hi
sorry,
my
my
connection
to
me
that
throw
has
been
unstable,
so
Tommy
mentioned
earlier.
That
Apple
has
a
bootstrap
process
that
that
repeats.
Some
of
the
discovery
queries
through
the
encrypted
channel
to
see
if
the
resolver
has
an
opinion
about
its
own
location.
That's
different
from
the
bootstrap
resolver's
opinion.
Chrome
actually
also
has
a
version
of
that.
This
draft
is,
is
also
essentially
proposing
a
bootstrap
mechanism,
so
I
think
that
we're
on
to
something
here
we
should
write
it.
J
We
should
have
a
document
that
talks
about
bootstrap,
but
this
specific
proposal-
I
I,
don't
like
in
the
details,
because
I
think
it's
actually
insecure.
Remember
that
DDR
was
in
invented
deployed
later
than
encrypted
DNS,
so
imagine
that
I
am
connected
to
an
encrypted
DNS
resolver
that
doesn't
know
about
DDR.
J
If
I
send
this
discovery,
query
that
Discovery
query
can
totally
pass
all
the
way
through
that
resolver
and
out
into
the
public
internet
over
UDP,
at
which
point
anybody
on
the
network
can
can
inject
and
synthesize
a
response
that
that
claims
to
be
the
correct
answer
for
underscore
dns.resolver.arpa
and
since
in
this
proposal,
that
response
can
overwrite
the
trust
anchor
for
my
resolver
I
can
be
redirected
to
do
you
know
to
to
do.attacker.example
via
this
mechanism
and
then
validate
the
certificate
for
DOT
attacker.
That
example
all.
J
That's
that's
one
example:
that's
sort
of
one
example
of
a
more
General
problem
here,
which
is
something
we've
talked
a
lot
about
a
lot
in
the
past,
which
is
a
transient
to
persistent
attack
upgrade.
So
if
I
can
transiently
compromise
your
if
I
can
essentially
inject
one
response
in
any
somehow
in
any
way
to
to
this
discovery,
name
I
can
change
the
validation
Point
used
by
the
client
and
and
from
then
on
have
at
least
for
the
length
of
the
TTL,
get
them
to
use
my
resolver
instead
of
the
one
they
intended
to.
F
It
seems
like
we're
having
a
really
awesome
design
discussion
going
on
here
and
it
says
to
me
there's
a
lot
of
energy
and
interest
in
this
topic.
As
Ben
pointed
out
similar
parallel
thinkings
going
on.
Maybe
a
suggestion
you
guys
should
maybe
step
back
go,
have
a
coffee
virtually
with
Ben,
remote
and
iterate
on
a
Next
Generation,
but
it
does
seem
like
there's
interest.
So
that's
really
awesome,
but
does
it
seem
reasonable.
C
Oh
yeah,
totally:
okay,
a
lot
of
good
list
discussion
here,
Eric,
please
yeah.
H
N
Changes
the
I
think
a
bunch
of
the
challenges
with
the
original
alt
service
header
had
been
around
some
of
these
issues.
That
then,
was
referring
to
around
like
what
hap
what
happens?
If
you
get
a
a
single
response
back
and
you
hold
on
to
it
for
too
long,
and
then
things
change
like
which
CDN
was
being
used
changed
or
the
trust
of
the
the
person
you
originally
got
it
from
changed.
N
O
Agreed
and
I
appreciate
the
pointer,
because
that's
something
that
I'm
currently
involved
in
so
we'll
definitely
be
discussing.
I
I
will
point
out
not
and
I
promise
not
to
grab
a
hole
in
this,
but
that's
something
where
I'm
I
the
Upstream
case
makes
perfect
sense
and
I
hadn't
considered
that
the
transient
attacker
case
is
interesting,
because
once
we're
talking
about
the
ability
to
change
a
query
response,
I
don't
see
that
it
matters
what
you
queried
for
name-wise.
If
the
result
is
the
same,
but
it's
certainly
something
that
obviously
needs
more
discussion.
C
H
M
That's
right,
I
mean
I
mean
this
draft
is.
Is
we
wanted
more
comments
and
feedback
on
this
draft
and
we
need
to
find
a
working
group
for
this
and
if
there
is
any
interest
in
implementing
this
in
the
first
place,
but
this
draft
got.
M
We
started
writing
this
proposal
when
we
saw
the
comments
from
Isaac
review
and
we
realized
that
there
are
security
issues
that
need
to
be
fixed
right
and
we
thought
we'll
just
highlight
the
problems
and
some
potential
solutions
that
would
address
those
concerns
that
were
raised
right
next
slide.
Please.
M
Yeah,
so
the
problem
statement
is
quite
clear
that
one
of
the
main
reasons
is
that
Totten
X
is
not
widely
deployed
in
several
networks.
Evil
twin
is
a
very
prevalent
attack
that
you
see
that
an
attacker
emulates,
the
actual
Network,
that
you're
trying
to
connect
to
the
attacker
uses
the
same
SSID
and
the
psk
is
probably
leaked
to
the
attacker
because
your
device
is
compromised
or
the
psk
is
kept
on
a
board
wherever
you
can
see
and
pick
it
up
right.
Coffee
shops
use
psk,
which
is
put
on
a
QR
code.
M
Home
networks
use
psks,
small
office,
home
networks,
use
psks
all
the
time
and
we
have
seen
evil
twin
attacks
happen
in
those
kind
of
networks,
and
and
how
do
you
address
the
scenario
that
user
believes
that
a
user
is
trusting
the
network
and
and
the
DNS
resolver
it's
providing
and
the
DNS
queries
are
encrypted
to
it,
but
you're
actually
connecting
to
an
attackers.
Network
next
slide.
C
M
Okay,
that's
the
same
problem:
if
you're
using
operationalistic
wireless
encryption,
where
there
is
no
psk,
it's
it
uses
different
element
to
basically
mutually
establish
a
shared
key
and
then
encrypt
them
free
handshake.
We
saw
similar
problems
in
where,
as
part
of
the
supply
chain
attacks,
there
is
a
possibility
that
your
sim
card
could
be
compromised
and
the
attacker
could
get
access
to
your
preset
key
and
that's
one
of
the
reasons
we
see
a
fast
forward
secrecy,
epic
extension
being
discussed
in
the
Emu
working
group.
M
So
with
all
that
we
were
wondering,
is
there
a
potential
way?
We
can
address
these
threats
without
going
back
to
the
Wi-Fi
Alliance
right
up
next
slide.
Please.
M
Yeah
so
since
we
are
learning
and
network
advertised
encrypted
DNS
server,
we're
wondering
whether
we
could
use
that
to
help
identify
whether
it's
an
evil
twin
or
not.
So
we
figured
out
a
way
where,
if
you're,
using
the
traditional,
WPA2
or
wpa3,
whether
you
want
to
rely
on
the
society
names,
if
you
don't
rely,
then
we
figured
out
and
Trust
on
first
use
so
that
you
can,
on
the
second
connection,
to
the
network,
you
would
check
if
13
a
server
identity
has
changed.
M
M
So
it's
trust
one
first
uses
you
either
use
DNR
or
TDR
to
discover
the
resolver.
Then
you
create
and
fingerprint
for
the
network.
You
basically
use
the
SSID
hash
of
the
pre-shared
key,
that's
being
used,
the
discovery
method
being
used
and
the
identity
of
the
resolver
that's
being
discovered.
For
instance,
in
this
case,
if
it's
TNR,
it's
the
fqdn,
if
it
is
TDR,
it's
the
IP
address,
so
you
basically
create
a
fingerprint
of
the
network
using
the
discovered
encrypted
resolver
and
next
slide.
Please.
M
So
once
you
create
this
fingerprint
in
the
first
connection
to
the
network
on
subsequent
connections,
you
check
if
the
DNS
server
identity
matches
or
it
doesn't
match.
If
it
doesn't
match,
it
gives
a
hint
that
it's
probably
an
equal
twin,
which
is
trying
to
look
at
your
TNS
or
even
modify
your
DNS
responses.
M
It
would
probably
work
for
public
welfare
hotspots
which
have
which
you
don't
have
anything
private
to
change,
and
they
could
probably
have
something
like
an
example
that
we
listed
here
but
may
not
be
a
viable
option
for
home
networks,
where
we
don't
want
to
change
and
typical
home
admin
to
go
and
change
the
SSID
name,
and
maybe
it
starts
revealing
some
privacy
Pi
related
information
in
this
in
the
SSID
related
to
probably
the
router
who
has
given
this,
who
is
assigned
this
fqdn
to
the
home
router
or
it
could
be
the
security
vendor
who's
managing
this
home
router.
M
M
Yeah
the
alternative
was
like:
if
there
are
networks
which
which
already
do
epls,
then
it's
it's
it.
It
works
perfectly
in
those
cases
that
the
SSID
name
has
to
match
the
the
server
certificate.
Subject:
alt
name
this
this
would
be
pretty
useful
for
networks
where
endpoints
are
not
being
managed
by
the
MDM.
Etls
allows
a
mode
where
client
certificate
authentication
is
not
mandatory,
for
example,
for
emergency
services,
where
only
server
site
validation
is
required.
M
In
those
cases,
the
match
would
be
quite
useful
and
it
would
also
be
useful
during
the
device
registration
process
where
the
device
doesn't
trust.
The
network
and
device
is
kept
in
a
quarantine
to
get
its
credentials
to
during
that
process,
for
the
device
to
know
that
it's
indeed
creating
the
configuration
profile
from
from
the
right
Network
that
it
is
supposed
to
attach
to
next
slide
next
slide.
Yeah.
M
Yeah
does
it
solve
all
the
threat
vectors?
Yes,
it
solves
threat
vectors
to
a
great
extent.
For
example,
an
attacker
could
still
use
the
same
DNS
server
as
the
legitimate
Network,
for
instance.
If,
if
the
legitimate
network
is
using
a
public
resolver,
it
would
still
advertising
that
I'm
gonna
use
the
same
network,
but
it
definitely
reduces
the
capability
of
the
attacker.
It
would
not
have
access
to
the
DNS
messages
and
in
near
future,
when
clients
start
using
tls1.3
and
encrypted
client
hello.
M
The
capability
of
the
attacker
to
see
what
domains
the
endpoint
is
visiting
will
be
reduced
dramatically
and
the
attacker
will
not
be
able
to,
for
instance,
remove
the
ech
keys
from
the
DNS
records
to
cause
the
client
to
downgrade
to
a
non-ech
mode.
So
these
are
some
of
the
advantages
that
we
see
and
we
would
like
to
have
feedback
from
the
working
group
and
if
there
is
any
interest
to
implement
it
and
a
better
ways
of
solving
that,
so
we
would
like
to
hear
from
people
on
how
we
take
this
forward.
C
And
I
saw
Ben
popped
up,
but
right
now
David
is
the
active
one.
So.
R
Was
open,
hi,
yeah,
wow?
Sorry
I
really
have
to
eat
the
mic:
David
schenazi
internet
architecture
Enthusiast.
R
This
feels
like
a
non-trivial
solution
like
this
feels
like
it
has
a
quite
a
bit
of
complexity
to
solve
a
very
small
part
of
the
problem.
Space
like
I
totally
agree
with
you
on
the
evil,
twin
attack
and,
in
some
cases
that's
a
problem.
In
many
cases,
it's
not
like
if
I
connect
to
a
coffee
shop,
I,
don't
care.
I
have
T.
I
have
https
that
takes
care
of
everything
that
I
personally
do
on
a
on
that
and
then
I
have
my
mask
thing
for
anything
else.
R
So
what
I
would
suggest
is
if
you're
worried
about
this
problem.
I
would
solve
it
at
a
more
holistic
level,
so
perhaps
at
the
802-11
layer
or
or
something
different.
But
this
feels
like
all
of
this
tofu
infrastructure
seems
smart,
seems
good,
but
once
we
have
all
of
that
and
we're
saving
all
that
state
and
we're
checking
certificates
and
we've
done
all
this-
just
protect
all
the
traffic.
Don't
do
this
just
for
DNS,
it's
not
worth
the
effort.
Sure.
M
And
the
reason
for
doing
DNS
was
that,
because
endpoints
would
discover
the
encrypted
resolver
they
are
attaching
to
the
network
if
they
are
using
a
pre-configured
resolver.
This
is
not
ensure
at
all
right.
This
is
when
you're
using
TNR
DDR.
You
don't
have
a
pre-configured,
resolver
and
you're
using
the
local
resolver
to
discover
these
encrypted
resolvers.
You
want
to
make
sure
the
comment
that
we
got
was.
M
So
for
that
right
we
are
looking
for
ways
that
are
practical
enough
right
and
and
base
that
could
be
implemented
rather
than
going
to
eight
or
two
level
I've
seen
those
discussions
happening
in
the
past
and
and
and
and
then
they're
not
changing
the
way
they
are
doing
it
and
then
it's
becoming
quite
difficult
right,
I
mean
whatever
the
solution
could
be.
If
it's
practical
enough
and
Deployable,
it's
also
a
problem
for
the
implementations
which
are
using
DNR.
Indeed,
here.
R
Absolutely
and
I'll
just
say:
one
quick
thing
before
I
go
sit
down
is
I,
think
you're
gonna
run
into
the
same
problem.
That
is
the
reason
that
IEEE
hasn't
fixed
this
for
Wi-Fi,
because
you
know
they're
no
less
smart
than
we
are.
Is
that
in
the
like
this,
what
you're
saying
is
not
for
Enterprise
networks,
the
Avenue
21x.
R
This
is
for
the
mom
and
pop
coffee
shop
where
in
practice
all
they
did
is
they
bought
the
router
and
they
got
the
the
neighbor's
kid
to
configure
our
name
and
a
password
if
that
router
breaks,
because
they
bought
one
for
from
Target
for
20
bucks,
they're
gonna
go
tell
them.
Can
you
put
the
same
thing
on
the
next
router
and
then
you're
all
sorts
of
screwed,
because
your
users
can't
connect,
because
you
have
some
keys
that
were
in
the
other
one
that
otherwise
they
would
have
done
this
tofu
at
that
layer.
C
J
Hi,
so
I
I
agree
that
it's
not
not
going
to
be
so
easy
to
to
deploy
something
like
this,
but
I
still
think
it's
fun,
I
think
it's
worth
a
try.
You
know
it.
Doesn't
it
kind
of
doesn't
cost
us
anything
I
think
that
as
an
experimental
draft
you
know
it
has,
but
it
has
potential.
However,
I
I
think
that
the
only
authentication
layer
that
makes
sense
here
is
eptls
and
I.
J
Don't
think
that
that
connecting
this
to
the
name
of
the
local
resolver
makes
makes
any
sense
here,
it's
essentially
conflating
the
identity
of
network
with
the
identity
of
some
DNS
servers
that
the
network
is
is
mentioning
to
people
who
are
on
the.
J
My
local
network
announces
Google's
DNS
servers
on
my
home
network,
like
does
that
mean
that
I
need
to
name
my
wireless
network
dns.google,
because
that's
going
to
be
a
very
strange
name
for
my
home
wireless
network,
but
if
I
could
just
say
that
the
name
of
my
wireless
network
isn't
is
a
domain
that
I
control
and
prove
ownership
over
of
that
over
eptls,
then
I
can
do
DNR
over
DHCP
with
dhcpguard
on
the
local
network
and
actually
have
a
fully
secured
secured
chain
where,
where
each
link
in
the
chain
is
authenticated
or
secured
by
the
appropriate
mechanism,
so
I
think
this
should
just
link
the
SSID
to
the
the
network
Association
and
from
then
on
local.
J
You
know,
relevant
mechanisms
can
apply,
which
means
it's
not
an
add
problem.
It's
not
that
far
from
dance.
Actually,
if
you
are
looking
for
for
a
home
for
it.
J
D
F
F
Well,
that's
the
wrap
up.
Essentially
I
mean
we
we've
done
our
drafts.
We've
done
our
thing.
We
have
things
in
the
process
for
publishing,
I,
think
we're
in
good
shape
and
I.
Think
we've
been
successful
at
itf115
to
have
a
very
productive,
add
session.
So
thank
you
very
much
for
coming
in
and
the
people
at
home.
Thank
you
for
joining.
F
The
one
thing
I
will
say
is
if
you
are
in
the
room-
and
you
have
not
gone
to
the
local
tool
to
sort
of
say
I'm
here,
that's
how
we
do
the
blue
sheets
now
so
go
in
there,
so
that
you
get
your
name
recorded
in
the
blue
sheets
on
the
local
tool.
That's
off
the
agenda
on
the
ITF
site,
or
you
can
do
that.
C
And
it
does
matter
for
a
couple
of
different
reasons,
notably
for
logistics
for
the
future,
but
also
for
historical.
Sometimes
they
need
to
be
back
referenced
about
who
was
actually
present.
C
D
D
It's
the
all
right.