►
From YouTube: IETF 97 - DNS Privacy Tutorial
Description
DNS Privacy Tutorial, Studio 3
13:45-14:45 KST (UTC+9)
B
B
C
You
everyone,
sorry
for
the
late
start,
so
welcome
today
to
the
EDT
edu
tutorial
on
DNS
privacy.
My
name
is
Sarah
Dickinson,
very
glad
to
see
so
many
faces
here
today.
So
I'll
move
forward
on
to
the
overview
of
what
we'll
talk
about
today.
So
the
tutorial
is
basically
split
up
into
three
sections.
The
first
section
is
going
to
be
a
background
of.
Why
are
we
talking
about
dearness
privacy
as
an
issue,
and
how
did
this
arise
and
to
kick
that
off?
C
After
that,
we'll
move
on
to
talk
about
the
huge
amount
of
work.
That's
been
done
over
the
last
three
or
four
years
in
this
area,
a
lot
of
it
through
the
ITF,
a
lot
of
it
through
the
deep
I
working
group
and
then
finally,
I'll
talk
about
the
current
status
of
implementations,
deployment
and
tools
that
are
available
today.
A
So
I
want
to
talk
just
a
little
bit
to
set
the
frame
for
why
dns
privacy
matters
more
generally,
it
matters
sort
of
there's
a
bigger
picture.
Why
does
privacy
on
the
Internet
itself
matter
so
just
to
try
to
motivate
it
so
that
we're
thinking
about
this
stuff
sort
of
on
the
same
page,
you
can
looks
like
it
doesn't
want
to
do
the
full
screen
thing.
A
Yeah
all
right
so
so.
The
concern
here
is
that
there's
sort
of
an
issue
of
possibility
of
a
centralized
surveillance
state
acting
as
a
form
of
social
control.
Now
you
might,
you
might
be
concerned
about
governmental
control.
You
might
be
concerned
about
criminal
control,
blackmail,
a
range
of
other
things,
but
basically
whoever
controls
the
network
if
the
network
is
transparent
about
what's
going
on,
has
potentially
a
lot
more
power
over
the
citizens,
so
the
people
who
use
the
network.
So
this
is
a
this-
is
a
plan
for
the
panopticon
which
is
a
prison.
A
I
find
that
troubling
and
I'd
like
to
make
sure
that
network
where
the
smarts
are
at
the
edges
doesn't
make
it
so
that
the
center
actually
has
control
over
the
smarts
at
the
edges,
so
the
next,
so
so
the
DNS
when
we
think
about
what
goes
on
in
the
DNS.
We're
often
thinking
about
sort
of
that
is
basically
like
little
bits
of
metadata.
Like
what
host
names
are
you
looking
up
and
that's
associational
host
data?
So
a
request
comes
from
you
for
a
particular
name.
A
Those
names
potentially
mean
things
and
I
want
to
just
point
out
that,
like
associational
surveillance
is
actually
probably
the
most
sophisticated
form
surveillance
that
we
have.
If
you're
thinking
about
global
surveillance,
the
it
feels
creepy
to
think
of
somebody
knowing
what
you're
saying,
but
actually
the
things
that
machines
can
learn
at
scale
are
significantly
more
powerful
these
days
than
just
content
analysis,
and
so
this
associational
stuff.
This
is
a
slide
from
the
elite
slide
from
the
NSA.
A
Their
only
one
of
the
groups
who
are
doing
sir,
like
intense
associational
surveillance,
but
the
the
kind
of
associational
surveillance
they
can
do,
is
mapping
particular
people
to
particular
groups.
So
you
can
imagine
with
the
DNS
the
mapping,
the
sorts
of
mappings
that
could
go
on
like
did
you
visit
Alcoholics
Anonymous
that
well,
that
tell
somebody
something
so
whoever
controls
the
network
has
an
opportunity
to
know
if
they're,
just
watching
what
traffic
goes
on,
what
sorts
of
people
have
connected
to
what
sorts
of
groups,
so
the
DNS
is
part
of
that.
A
So
it's
also
not
just
host
names
right.
The
DNS
has,
we
think
of
it
as
most
commonly
it's
just
we're
going
to
look
up
an
address
from
a
name
but
there's
lots
of
other
stuff
that
can
be
stored
in
the
DNS.
And
if
you
look
around
what's
going
on
at
the
IETF,
there
are
a
bunch
of
other
opportunities
to
use
the
DNS
that
are
not
just
host
names,
they're,
not
as
widely
used,
of
course,
as
the
address
lookups
that
we're
all
familiar
with.
A
So
there's
a
bunch
of
other
stuff
that
could
go
on
in
the
DNS,
and
people
want
to
use
the
DNS
for
that,
and
so
we
need
to
make
sure
that
DNS
queries
aren't,
as
obviously
subject
to
associational
surveillance
and
so
so,
just
just
to
sort
of
reinforce.
Why
I
think
the
social
control
issue
is
a
thing
here,
so
this
is
a
study
that
was
done.
A
If
you
have
nothing
to
hide,
you've
got
nothing
to
worry
about
right,
there's
a
lot
of
people
who
have
that
sort
of
instinctive
response,
and
it
turns
out
the
people
who
say
if
you're,
not
you
know,
I've
got
nothing
to
hide.
I'm,
not
worried
about
surveillance.
Surveillance
is
justified
to
eat
society,
safe
the
people
who
say
that
when
it
comes
to
things
where
they
are
in
the
minority
where
they
feel
like
they
are
more
in
conflict,
they're,
actually
less
likely
to
speak
up.
A
So
this
is
actually
an
ecosystem
problem,
where
the
fact
that
we
have
all
of
this
additional
means
that
people
are
less
likely
to
dissent
and
our
society
was
less
likely
to
be
able
to
evolve.
So
these
are
the
like:
these
are
different
groups
of
people
who
have
different
opinions
about
the
legitimacy
of
surveillance
and
the
graph
here
shows
friendly,
neutral
and
hostile.
A
So
if
you
think
you're
saying
something
into
a
hostile
environment-
and
you
think
surveillance
is
okay,
you're
actually
less
likely
to
speak
up
at
all,
so
there's
a
chilling
factor
of
having
the
centralized
surveillance.
So
it's
not
just
about!
Are
you
individually
concerned
about
being
spied
on?
It's
about?
What
can
society
do
as
a
like?
How
to
society
change?
Have
the
behavior
change
as
a
result
of
having
this?
A
So
we
want
to
make
protocols
that
encourage
people
to
not
to
feel
that
they
are
protected,
so
they
actually
can
communicate
with
people
even
in
an
environment
where
they
might
otherwise
feel
like
it's
hostile
environment
and
I
want
to
point
out
that
DNS
is
one
little
piece
of
these
leakages
right.
So
this
is
a
boat
here.
Dns
is
leaking
in
the
middle
of
the
boat,
but
there's
leaks
coming
from
the
TLS
layer
of
the
server
name,
indication
in
TLS
leaks,
there's
leaks
from
the
traffic
size
of
different
kinds
of
packets
that
you
send
timing
patterns.
A
There's
probably
lots
of
other
leaks
that
we
don't
know
about
and
a
lot
of
times
in
IETF
we're
working
in
these
little
silos
and
I've
heard
in
multiple
situations.
People
say
oh
well,
we
don't
have
to
worry
about
that
leakage,
because
it's
just
as
bad
as
this
other
leakage,
that's
happening
somewhere
else.
Well,
in
a
leaky
boat
scenario,
you
actually
need
to
fix
all
the
leaks.
You
can't
just
say
I'm
not
going
to
fix
my
leak,
because
this
other
leak
over
here
is
leaking
also
right.
A
We
actually,
these
are
theoretical
concerns,
and
some
of
these,
like
the
question
marks,
there
are
real
question
marks
like
these
are
there's
ongoing
academic
research,
about
what
kind
of
information
can
be
determined
from
things
like
timing
patterns,
and
we
don't
have
all
the
answers,
but
we
know
that
if
we
don't
fix
the
things
that
we
know
how
to
fix,
we're
not
going
to
get
to
all
of
them.
So
that's
just
a
motivation
for
why
we
care
about
DNS
privacy.
B
C
Okay,
thank
you
very
much,
so
I
hope.
That's
given
you
a
flavor
for
some
of
the
context
of
what
we'll
talk
about
today.
So
what
I
first
like
to
do
is
before
we
dive
right
deep
into
what's
been
happening.
Doing
as
well,
it's
talk
a
little
bit
about
what's
been
happening
at
the
ITF
level
in
general,
in
terms
of
privacy.
Now,
of
course,
the
Snowden
revelations
were
a
big
thing
and
it
got
popular
awareness
about
mass
surveillance
and
out
there
a
lot
of
people
sort
of
tend
to
think
that
kind
of
caught
the
IETF
napping.
C
But
what
I
want
to
illustrate
here
is
that
really
really
isn't
true.
The
IDF
was
very
actively
involved
in
all
sorts
of
privacy
work.
Well
before
that
there
were
numerous
workshops
and,
quite
importantly,
in
March
2011
work
was
started
on
a
draft
that
was
to
guide
protocol
developers
on
how
to
add
privacy
considerations
into
their
drafts
in
a
very
similar
manner.
As
to
the
way
security
considerations
are
quite
naturally
put
in
draft,
so
the
folks
behind
that
started
back
in
2011,
and
they
were
right
on
the
verge
of
getting
it
published
as
an
RC.
C
When
Edward
Snowden
revealed
his
a
data
to
the
world,
so
you
kind
of
got
a
feel
for
these
guys.
A
little
bit
get
me
my
Thunder
stolen
there,
but
what
the
IDF
did
is
it
came
back
swinging.
It
very
quickly
reacted
with
a
very
important
document,
which
is
RFC
7258,
and
this
declares
clearly
that
pervasive
monitoring
is
an
attack.
I'll
talk
about
that
a
little
more
in
a
moment.
The
work
at
the
idea
level
has
continued,
though
there
are
several
other
RFC's
in
this
area.
C
So
to
move
on
to
see
where
this,
inter
intersected
with
DNS,
so
if
you
think
back
back
in
time
a
little
bit
first
of
all,
I'd
like
to
time
travel
you
back
to
nineteen.
Eighty
seven
so
pick
your
your
DeLorean,
your
TARDIS,
your
phone
booth
time,
machine
of
choice
and
go
back
to
nineteen,
eighty
seven!
C
So
there's
a
lot
of
bad
hair,
a
lot
of
good
music
and
the
DNS
has
been
standardized
at
that
time
and
to
put
it
in
context
at
that
time
it
was
a
building
block
in
the
internet
and
the
main
goals
behind
the
design
of
the
infrastructure
of
the
DNS
were
availability,
redundancy
and
also
speed.
So
those
are
the
things
that
for
most
in
the
people
who
are
developing
the
protocol
in
privacy
terms,
the
DNS
is
described
as
an
enabler.
C
C
It
was
still
true
of
the
standards
in
2003
that
the
standard
transports
for
DNS
work,
UDP
and
TCP,
and
even
last
year
over
ninety-nine
percent
of
the
traffic
going
up
to
the
route
went
over
UDP
and
importantly,
this
is
clear
text,
so
all
you're
doing
as
queries
are
going
clear
text
over
the
internet,
so
this
meant
this
was
fair
game
for
somebody
like
the
NSA
with
their
more
cowbell
tool.
It
really
wasn't
a
tricky
job
for
them
to
monitored
in
ass
traffic
because
of
the
way
it
moves
over
the
Internet.
C
There
was
also
at
this
time
and
for
much
of
the
sort
of
25
year
time
period
here
that
I'm
spanning
a
perception
that
the
DNS
is
like
right,
I
mean
anybody
can
query
these
records.
Anybody
can
get
to
them.
They
don't
contain
personal
or
sensitive
information.
So
we
really
don't
need
to
worry
about
encrypting
this
or
protecting
us
in
any
way.
It's
the
DNS,
and
that
was
out
there
for
a
long
time.
C
So
you
have
to
bear
those
things
in
mind
when
you
look
at
the
design
of
the
dns
and
be
a
bit
forgiving.
So
this
is
the
basics
of
how
the
dns
works
you're
on
some
client
machine.
You
want
to
resolve
a
name.
You
send
the
full
name
up
to
the
recursive
server
that
you're
using
now
what
the
DNS
does
is.
If
it
doesn't
have
that
name
in
cash,
it
sends
the
entire
name
up
to
a
root
server,
to
get
a
delegation
for,
in
this
case,
dot
org.
C
Then
it
sends
the
entire
query
to
the
doctor
or
authoritative
server
and
so
on
down
the
chain
until
it
gets
to
the
one
that
can
provide
the
answer.
Now,
with
hindsight,
we
and
your
privacy
hat
on
you
look
at
this
and
go
oh
that
infamous
bad
idea.
Ferry
was
around
when
they
thought
of
this
right,
because
those
do
queries
are
leaking
information
who
a
troop
needs
to
know
the
full
question
that
the
client
asked
they
don't
need
to
in
order
to
resolve
it.
But
this
was
how
the
DNS
was
designed.
Originally.
C
Something
else
interesting
happened
just
about
this
time
frame
as
well
2013,
and
that
was
the
standardization
of
a
mechanism
called
Eden
s0.
Now
this
was
a
really
nice
idea
and
something
the
DNS
really
needed.
It
enabled
embedding
information
inside
DNS,
query
that
was
flexible.
It
could
contain
capability
options.
It
could
allow
clients
and
service
to
negotiate
things
like
path
MTU.
It
was
great
the
dearness
needed
it
as
a
side
effect,
though,
what
this
did
is
it
enabled
certain
organizations
to
take
advantage
of
this
to
embed
user
data
directly
inside
those
DNS
queries.
C
But
the
way
this
was
positioned
at
the
time
was
that
it
was
all
for
the
greater
good.
So,
for
example,
one
of
the
mechanisms
here
was
ISPs
saying
we
want
to
offer
you
filtering
parental
filtering,
protect
your
kids
or
even
more
sophisticated
filtering,
and
we
can
do
this
at
our
cursors
if
we
know
who's
making
those
queries.
C
Similarly,
CDNs
argued
that
if
we
know
where
you
are
located
geographically,
we
can
divert
you
to
your
nearest
server
and
you
will
get
great
streaming
and
your
cat
videos
will
never
bother
again.
Isn't
that
wonderful?
Aren't
we
doing
you
a
great
customer
service,
so
this
all
sounds
great
and
people
sign
up
for
it.
What
they
don't
realize
is
what
this
means
in
practice.
C
In
some
cases
it
was
observed
that
it
was
usernames
or
user
IDs
something
unique,
and
that
meant
they
could
do
their
filtering
at
recursive,
but
it
also
meant
that
anybody
who
is
passively
monitoring
that
link
could
immediately
correlate
all
those
queries
with
the
activities
of
individuals
behind
that
router,
so
that
could
allow
not
only
for
identification
of
individuals
but
tracking
of
individuals
as
well
in
a
very
similar
manner.
The
way
the
client
subnet
worked
was
that
there
was
an
implementation
in
the
recursive.
C
That
said
well,
we
know
who
sent
us
this
query
pick
up
the
subnet
and
send
that
up
to
the
authoritative,
so
it
can
figure
out
their
geolocation.
But
again,
this
is
leaking
information
to
anybody
passively
monitoring
that
link
up
the
authoritative
again
creating
correlations
within
the
data
with
the
activity
of
users
or
groups
of
users.
So
what
this
really
means
is
even
when
you're
sat
at
home
you're
behind
in
that-
and
you
think
you've
got
anonymity,
you
don't
necessarily,
and
even
though
you're
behind
a
recursive
only
think
you've
got
anonymity.
C
You
don't
necessarily-
and
both
of
these
were
done
originally
with
non-standard
options.
Some
of
them
are
now
coming
through
the
standards
process,
but
there
really
wasn't
anything
to
stop
organizations
doing
this,
because
people
happy
to
sign
up
to
the
services
which
sounded
eight
and
as
dkg
alluded
to
the
kind
of
cruise.
You
do
reveal
quite
a
lot
about
you
on
both
of
these
legs.
So
I
don't
know
about
me,
but
I'm
at
home
before
I
came
here,
I
was
looking
up.
C
What
conference
I
was
going
to
what
hotel
I
was
staying
a
hat
with
flights,
I
was
taking,
so
this
reveals
an
awful
lot
about
me,
including
how
distracted
I
can
get
when
I'm,
trying
to
put
a
big
slide
deck
together
and
what
site
so
go.
Wandering
off
ting,
but
this
is
all
information
they
can
correlate
back
to
me.
C
So
I
hope
at
this
point,
I've
got
your
spidey
senses
tingling,
with
the
idea
that
there's
all
sorts
of
stuff
going
on
in
the
DNS
that
you
don't
necessarily
know
about
an
end
user,
even
if
you're
quite
technically
aware
to
take
this
another
step
further.
So
we've
looked
at
the
kind
of
leakages
you
get
on
DNS
queries
that
are
in
flight.
C
This
is
thinking
about
them
at
rest,
so
you
have
a
recursive
resolve
that
you're
using
so
you
have
to
stop
considering
who
are
the
people
who
have
authorized
access
to
the
data
there
to
what's
been
blogged
about
all
the
queries
coming
in?
What's
third
parties,
are
they
sharing
it
with
what
legal
commitments
do
they
have
to
gather
data
on
users?
Equally,
what
are
the
risks
of
unauthorized
access
to
that
data?
How
solid
is
the
security?
C
Could
there
be
breaches,
and
also
those
concerns,
will
change
as
you
move
around
different
curses
so
as
you're
at
home
at
at
work?
I
should
rent
a
coffee
shop
as
you're
in
a
hotel
so-
and
these
are
things
that
people
aren't
necessarily
aware
of.
Equally
those
concerns
extend
up
to
the
authoritative
because,
as
you
can
see,
information
can
make
it
up
to
that
level
about
the
activity
of
individuals.
C
So
those
are
the
sort
of
salient
points
about
DNS
data
leakage.
There
are
an
awful
lot
of
complications.
I
want
to
just
touch
on
one
here,
which
is
something
which
particularly
lately,
has
become
more
active
and
that's
Dennis
filtering.
So
this
is
happening.
A
country,
level
and
isp
level
organizational
level
and
its
activities
whereby
people
running
recursos
will
have
a
black
list
of
sites.
They
don't
want
people
to
get
to
and
they
will
actually
tell
Dina
in
order
to
block
access
to
those
sites.
C
Again,
this
is
trying
to
be
done
for
the
greater
good,
keep
you
away
from
websites
infected
with
malware,
etc.
Although
accidentally,
some
other
sites
get
blocked
every
now
and
again
that
you
might
want
to
get
to
like
Google,
this
has
happened
by
accident,
but
the
thing
to
think
about
is,
if
you
are
using
a
recursive
it
engages
in
this
kind
of
behavior,
with
these
black
lists.
C
So
that's
a
picture
in
classic
DNS.
As
you
know,
it
I
want
to
spend
just
a
little
bit
of
time
talking
about
something
which
is
called
dns
service
discovery.
So
this
happens
within
local
networks,
and
the
mechanisms
used
can
be
regular,
DNS
constrained
to
that
local
network,
or
it
can
be
multicast
DNS.
C
What
this
does
is
essentially
the
procedure
whereby
a
device
can
advertise
some
services
that
it
is
willing
to
make
public
and
other
devices
can
discover
those
services
and
use
them,
and
this
is
really
cool
because
it
means
you
can
do
stuff
like
file
sharing,
photo
sharing,
all
sorts
of
stuff
directly
over
the
network
and
that's
nice
and
most
of
the
services
that
utilize.
This
are
secure.
The
problem
comes
in
advertising.
C
Those
services
now
I,
can
see
a
whole
bunch
of
max
here
and
I
know
that
if
you
simply
just
open
find
when
look
in
your
sidebar,
you
can
probably
see
a
whole
load
of
devices.
Advertised
and
I
bet
a
whole
bunch
of
them
have
names
or
identifies
in
them,
and
very
typically.
The
kind
of
thing
you
might
see
is
something
like
this
Stuart
I
was.
E
Going
to
add
one
pedantic
point,
you
said
this
is
on
the
local
network,
but
it's
not
it's
on
the
global
network
sitting
here
at
the
IDF.
If
you
tap
the
errant
button
on
your
phone
it'll,
do
a
rufa,
appt
cebu
meeting
ITF
dog,
which
will
go
across
the
Pacific
to
Virginia
or
wherever
the
authoritative
server
is
for
IETF
dog
yeah.
E
F
C
So,
in
terms
of
advertising,
what
you're
doing
here
in
leaking
information
the
problem
comes
with
the
way.
This
information
is
advertising
the
amount
of
detail
it
contains.
So,
for
example,
you
might
quite
easily
see
this
kind
of
information
advertised
from
an
individual
user
and
you
think
well,
okay,
so
what
they
want
to
share
this
stuff
they're
willing
to
make
it
public
but
think
about
what
you've
learned
about
Alice.
C
Just
from
this
information,
if
you're
in
a
very
small
room
and
say
they're
only
handful
of
females
and
only
one
has
a
laptop
open,
then
suddenly
you've
got
a
really
good
idea
of
who
Alice
actually
is.
You
also
know
that
she's
got
two
devices
and
you
know
she's
willing
to
share
photos
and
that
she
uses
a
chat
application
that
supports
presence.
C
It
can
go
deep
dive
into
exposing
information
about,
for
example,
when
you
advertise
these
services,
you
also
often
advertised
attributes
about
them,
so,
for
example,
which
ports
they
use,
which
part
it
says
you
they
use
lots
of
details
and
intelligent
attackers
it
has
been
shown
can
actually
use
this
to
determine
things
like
which
software
version
you
are
running
and
therefore
that
means
they
might
be
able
to
detect
known
exploits
in
unpatched
software.
Similarly,
they
can
actually
dive
right
down
to
specific
devices
if
they
have
enough
information.
C
So
again,
this
is
leakage
of
personal
information
that
non-technical
users
are
probably
very
unaware
of,
and
even
technical
users
might
not
understand
the
full
gravity
of
okay.
So
what
I
wanted
to
do
quickly
was
just
say:
okay,
so
back,
then,
if
he
were
savvy
to
dinner
perfectly
being
a
problem,
what
were
your
choices
at
the
time
there
were
a
couple
of
things
available.
Dns
curve
was
around
for
a
little
while
Dena
script
was
developed
and
is
still
around.
C
There
are
a
number
of
implementations
so
and
in
fact,
OpenDNS
offer
that
as
a
mechanism
when
you
use
their
resolvers
and
what
I
do
want
to
spell
out,
though,
is
that
the
real
motivation
behind
these
mechanisms
was
authentication
of
the
information
exchanged
between
clients
and
servers.
So
it
was
about
anti
spoofing
and
anti
dosing,
and
the
privacy
benefits
largely
came
as
a
side
effect,
because
crypto
is
used
to
achieve
that.
These
weren't,
first
and
foremost
privacy
mechanisms
to
protect
users
also,
although
these
were
documented,
neither
actually
made
it
to
through
the
standards
process.
C
Other
things
that
people
were
doing,
some
people
chose
to
run
local
resolvers
on
their
machines,
and
the
main
aim
here
was
to
bypass
those
intermediate
recursos,
so
you
weren't
exposing
your
data
to
them.
It
doesn't
solve
the
whole
problem
because
you're
then
exposing
your
client
address
directly
to
the
authoritative,
but
some
people
felt
this
was
a
better
choice
than
using
an
intermediate
worker.
Sir
also,
what
came
out
around
this
time
was
a
total
dns
trigger.
C
Now
again,
the
motivation
for
this
was
to
enable
DNS
SEC
on
an
end-user
computer,
and
the
privacy
aspects
were
a
byproduct,
but
what
it
did
was
it
used
as
a
last
ditch
to
tempt
DNS
over
TLS
port
443.
But
what
this
did
mean
is
there
was
an
implementation
of
encrypted
DNS
out
in
the
wild
that
some
users
were
able
to
monopolize
and
use
for
their
own
ends
to
do
private
DNS,
even
at
this
early
stage.
C
So
having
talked
about
the
historical
context
of
this,
I
wanted
to
move
on
and
talk
about,
what's
been
happening
in
the
most
in
the
recent
years.
So
when
the
main
places
this
work
has
happened,
is
the
deprived
working
group,
and
this
was
created
in
2014
in
the
wake
of
the
Snowden
revelations
and
the
desire
by
the
IETF
to
mitigate
monitoring
through
protocol
design.
C
Now
this
had
no
small
task
before
it
you're
talking
about
taking
the
DNS,
which
has
been
a
bass
rock
of
the
internet
for
30-some
years
and
worked
in
largely
the
same
way
for
all
those
30-some
years
and
what
you
have
to
magically
do:
sprinkle
it
with
a
layer
of
privacy
with
minimal
impact
and
try
not
to
disrupt
the
internet
while
you
do
it.
So
where
do
you
start
well?
C
Secondly,
the
recursive
to
authoritative
stage
is
quite
challenging
when
you
come
to
think
about
how
you're
going
to
do
authentication
of
connections
in
that
environment.
And
the
reason
is
this:
if
you're
an
end-user
you,
your
relationship
with
recursive
services,
is
one
to
a
few.
You
have
the
one
use
at
home,
work
when
you're
out
and
about.
But
generally
you
either
have
a
relationship
with
that
recursive
resolver.
C
All
you
make
a
conscious
choice
to
use
it
by
going
through
a
captive
portal
or
joining
a
network
whatever,
whereas
if
you're
a
recursive
server,
your
job
is
to
talk
to
all
and
any
authoritative
servers
that
you
need
to
in
order
to
resolve
a
name
that
you
have
been
asked
for,
and
many
you
may
never
ever
have
talked
to
you
before,
so
that
makes
authenticating
the
one
too
many
unknowns,
difficult.
So
think
of
this
a
little
bit
like
your
phone
contacts
compared
to
your
Twitter
followers.
Who
do
you
know
best?
C
So
the
first
thing
that
the
working
group
did
has
it
decided
to
enumerate
the
problem
space
and
it
produced
RFC
7626.
Now
this
is
highly
recommended
read.
It
basically
goes
through
the
kind
of
situations
that
I
talked
about
in
the
first
part
of
the
discussion
here
today,
but
in
much
more
detail
and
also
goes
through
other
cases
of
leakage.
So
that's
really
worth
looking
at
to
understand
the
details
of
what's
going
on,
I'm,
really
keeping
that
this
document
does,
though,
is
it
robots?
C
The
alleged
public
nature
of
the
DNS
and
the
distinction
it
makes
is
that
yes,
the
data
in
the
DNS
might
be
public,
but
an
individual
DNS
transaction
is
not
and
should
not
be
public.
So
to
use
the
same
example
as
earlier,
and
this
is
actually
directly
taken
from
this
RFC.
The
website
for
Alcoholics
Anonymous
is
public.
The
a
record
for
that
is
public.
The
fact
that
you
as
an
individual
do
the
DNS
requests
to
get
that
record
is
not
and
should
not
be
public.
That
is
your
personal
data.
C
So
having
established
the
problem,
we
now
start
looking
at
solutions
and
there
were
various
ones
that
could
have
been
looked
at
and
some
of
the
well-known
technologies,
some
dns
specific
solutions
were
offered
as
well
and
drafts
on
all
of
these
came
forward
to
the
working
group
at
the
time,
the
ones
that
got
really
serious
consideration
with
these
three
starts
here
less
initially
seemed
very
attractive.
It
could
be
done
on
port
53,
it
could
be
incrementally
deployed.
It
was
a
known
technique
that
was
all
nice
on
downside,
though.
C
Obviously
the
negotiation
can
be
susceptible
to
a
downgrade
attack.
That
negotiation
can
also
introduce
latency
and
l
word
dear
folks,
really
don't
like,
and
there
was
also
sort
of
big
question
mark
about
hang
on.
There's
all
these
Reuters
that
get
DNS
traffic
on
port
53.
Are
they
certainly
going
to
freak
out
if
they
start
seeing
encrypted
traffic
and
just
block
it
Oh
again,
I
have
real
deployment
problems
here
it
was
an
unknown.
C
So
if
discussion
moved
on
to
looking
at
doing
TLS
or
detail
s
over
a
brand
new
port,
if
we
could
get
one
now,
if
we
could
TLS
is
you
know
a
very
well-known
technology,
there's
a
lot
of
implementations,
it's
quite
widely
deployed,
so
that
was
attractive.
There
was
some
concerns
about
scalability
of
it.
If
you
try
and
use
it
within
the
DNS
and
then
in
some
ways
you
might
want
to
look
at
detail
s
and
say
well:
isn't
that
a
more
natural
solution
for
DNS,
because
it's
UDP
based
and
initially
it?
You
might
think
that.
C
However,
it
runs
into
the
same
problem
that
UDP
does
and
the
reason
there's
this
scattering
of
tcp
around,
which
is
that,
if
the
answer
to
a
DNS
query
is
too
big
to
fit
within
the
MTU,
then
the
server
has
to
indicate
the
client
it
needs
to
retry
over
TCP,
because
you
can
send
that
large
response
over
TCP.
The
same
problem
happens
over
dtls.
If
the
response
won't
fit
in
the
packet,
the
server
cannot
send
the
whole
response
and
it
has
to
request
the
client
to
retry
over
another
mechanism
when
you're
dealing
with
privacy.
C
That
means,
if
you
want
to
maintain
privacy,
you
have
to
use
another
protocol
like
TLS.
All
you
have
to
completely
sacrifice
your
privacy
and
retry
over
clear
text.
So
the
upshot
of
that
was
that
detail
s
couldn't
be
a
standalone
solution
to
DNS.
Previously
you
had
to
do
dns
over
TLS,
regardless
if
you
wanted
a
deployable
solution,
so
in
that
case
it
meant
we
had
to
revisit.
C
What's
going
on
with
dns
and
tcp,
I
mean
some
people
sort
of
shocked,
shocked
to
find
the
tcp
is
even
used
for
dns
at
all,
but
it
was
but
none
such
a
great
way
and
the
reason
was
a
historical
one.
It
was
that
clients
took
the
easy
route
and
if
they
were
doing
lots
of
UDP
queries-
and
they
got
this
signal
to
say
you
need
to
retry
over
TCP,
they
would
do
one
shot
over
TCP
and
then
go
straight
back
to
UDP,
and
that
was
the
pattern
that
clients
implemented
across
the
DNS.
F
C
Really
have
to
worry
about
TCP
I'm
going
to
get
one
query.
You
know
every
now
and
again
so.
Servers
had
very
basic
TCP
capabilities.
Operators
didn't
routinely
worry
about
tuning
for
TCP
or
a
bust
us
against
TCP
attacks.
So
you
know
it's
sort
of
in
some
ways
at
this
point
treated
as
a
second-class
protocol.
Oh
sorry,
Lykos.
C
In
fact,
I'm
completely
wrong
side.
Ok,
so
we
will
have
to
go
and
deal
with
tcp
/,
TLS
implementations
at
a
later
point
in
time.
Another
problem
that
we
will
have
to
deal
with
is
authentication,
so
what
do
most
other
protocols
do
when
they
want
to
authenticate
something
they
do
a
DNS
lookup
first,
so
we're
gonna
have
to
get
around
that
in
the
DNS.
C
The
other
thing
to
worry
about
is
some
really
interesting
work
that
was
done
on
traffic
analysis
and
what
this
showed
was
great,
go
ahead
and
crypt
your
DNS,
that's
fine,
but
if
I'm
observer
and
I
can
see
both
sides
are
recursive,
then
I
can
see
lots
of
messages.
I
can
still
figure
out
how
big
they
are
and
I
can
still
see.
The
timing
correlations
between
them,
which
means
with
a
bit
of
work.
I,
can
still
do
juice
a
whole
bunch
of
stuff
about
what
individual
users
are
doing
so
just
encrypting.
C
Okay,
so
top
of
that
list
was
guessing
you
port.
How
easy
is
that?
Well,
it
turns
out
if
you
have
a
really
solid
use
case,
which
this
was
it's
pretty
easy.
We
asked
and
we
got
fantastic
so
a
year
ago,
poor
853
was
assigned
for
use
for
encrypted
dns,
who
are
next
problem,
deal
with
this
issue
with
DNS
over
TCP
to
enable
DNS
over
TLS.
So
this
wasn't
an
insurmountable
problem.
It
was
really
just
a
question
of
engineering.
So
what
do
we
do?
C
C
When
you
set
the
connections
up,
you
want
to
stop
this
behavior
of
one
shot.
Tcp.
You
want
to
recommend
that
clients
wants
to
have
a
connection
open.
They
pipeline
their
queries
over
it,
not
waiting
for
responses
just
send
them
that
when
the
server
gets
them,
it
actually
processes
them
concurrently,
not
see
really
and
that
when
it
gets
the
responses,
it
sends
them
as
soon
as
it
gets
it
now.
C
That
will
sounds
really
obvious,
but
that
is
not
what
dn.m
implementations
have
done
historically,
so
work
was
done
to
ensure
that
in
the
standards
this
was
how
implementations
should
mature
moving
forward.
You'll
also
note:
there's
a
persistent
connections
are
see
here
until
last
year.
There
was
no
standard
way
for
a
DNS
client
and
a
dealer
server
to
agree
that
they
wanted
to
do
persistent
tcp
it
just
wasn't
there
and
spec.
It
is
now
also
in
terms
of
managing
TCP
connections
on
a
DNS
server.
C
C
Is
thank
you
yeah
keep-alive
is
28,
isn't
it?
Thank
you
very
much.
Apologies
I'm
fast.
Okay,
it's
been
youtubed,
yes,
yeah!
Sorry!
So
there's
a
correction
to
the
RFC
number
for
persistent
connections.
It
should
be
78
28,
Thank,
You,
Stuart,
chatter,
okay,
and
this
was
just
a
little
bit
of
illustration
of
sort
of
bad
in
sotc
p
versus
good
dns
over
tcp,
which
is
where
we
want
to
be
okay.
So
having
done
some
work
on
that,
we
now
move
on
to
authentication
the
work.
C
So
it's
kind
of
a
purist
take
on
if
you
like,
I
like
to
think
of
it
as
a
kind
of
Jedi
way
of
doing
this
I've,
let
the
words
of
Master
Yoda
described
the
philosopher
here
and
whereas
the
opportunistic
profile
is
much
more
pragmatic,
it's
I
really
like
the
idea
in
its
privacy
and
I.
Think
it's
important
I'm
going
to
try
every
mechanism.
C
So
how
do
you
do
this
authentication?
Well
right
now
there
are
two
ways
specified
one
that
starts
off
from
a
domain
name
and
one
that
starts
off
from
an
SP
ki
pin
set
now,
if
you're
out
there
you're
thinking,
okay,
these
are
doing
as
folks
and
not
these
the
folks
that
tell
every
other
protocol.
If
you
want
to
do
authentication,
you
should
be
using
Dane
so
shouldn't
we
be
kind
of
eating
our
own
dog
food
here.
Well,
yes,
so
we
do
specify
how
to
do
authentication
by
day.
C
C
You
can
figure
it
with
a
domain
name
and
IP
address,
and
one
of
the
bootstrapping
problems
here
is
that
it
may
need
to
do
opportunistic
so
not
necessarily
encrypted
lookups
to
get
that
information
to
start
with
again
at
this
point,
I
don't
have
a
connection
to
a
privacy
server.
So
if
I
want
to
get
those
damn
records,
that
also
has
to
be
opportunistic.
C
The
alternative
mechanism
is
one
using
something
called
the
TLS
DNS
SEC
chain
extension,
and
this
is
a
draft
which
is
currently
through
the
TLS
working
group.
What
this
does
is
it
starts
from
exactly
the
same
point,
but
it
shifts
the
responsibility
for
getting
those
Dane
records
onto
the
day
and
its
privacy
server,
because,
after
all
it's
a
DNS
server,
it
should
know
how
to
get
them
and
it
should
it
can
prefetch
them
and
it
can
cash
them
or
it
can
get
them
on
demand.
C
In
this
case,
once
that
server
has
the
records
the
client
can
then
in
the
client,
hello
indicate
that
it
supports
this
new
extension
tip
the
tea
LSD
in
a
sec
ascension,
so
hey
server,
I
I,
know
all
about
this
new
extension.
Do
you
yes,
I
do
here?
Have
my
Dane
records
in
the
server
hello,
along
with
my
credentials?
C
Have
at
them
client
goes
fine,
lovely,
okay,
first
up
I'm,
going
to
validate
your
Dane
records
with
doing
a
sec,
because
I'm,
a
father
dating
client
I,
can
do
that
next,
up,
I
validate
your
credentials
against
them
and
off
we
go
dns
resolution
begins
because
the
beauty
of
this
is
that
all
that
happened
inside
the
TLS
handshake
in
this
case.
So
what
you
avoid
is
the
latency
of
those
separate
lookups
by
the
client,
and
you
also
remove
the
need
for
a
separate
resolver
that
can
provide
the
dane
records
so
the
streamlines
the
whole
process.
C
C
C
There's
also
a
draft
going
through
the
working
group
which
is
completed
working
group
last
call
to
specify
DNS
over
TLS
and
there's
a
separate
draft,
which
is
in
working
group
last
call
to
specify
all
the
details
of
the
authentication
maxims
that
I
touched
on
earlier.
So
this
is
pretty
good
work
for
two
years
of
a
working
group.
I
think
hats
off.
You
know
this
wasn't
an
easy
problem
and
a
lot
of
progress
has
been
made.
C
C
One
thing
I
do
want
to
touch
on
is
that:
okay,
we
don't
have
an
encryption
solution
for
recursive
to
authorities
yet,
but
what
came
out
of
the
dns
up
working
group
is
a
nice
piece
of
work.
You
know
minimization,
so
we
go
back
to
this
picture
earlier,
where
the
bad
idea
fairy
said,
leak
all
your
information
and
we
come
along
with
an
idea
from
the
better
idea
fairy
who
says:
well,
no,
you
don't
do
that.
Just
send
what
you
need
to
and
stop
leaking
information
now.
C
So
I
got
this
slide
up
here
and
this
is
to
do
with
the
day
to
handling
and
honestly.
I
think
this
is
the
area
that
has
had
the
least
attention
and
probably
has
the
least
progress
and
needs
to
be
somewhere
with
kissing
now
I
mean
so
I
could
start
by
saying
hands
up
who,
in
this
room,
has
read
the
small
print
of
the
ISP
contract
and
knows
exactly
what
their
isp
does
with
their
DNS
data.
C
Alan
I'm,
not
one
of
them
say
wow
you'll
have
lives,
that's
great,
so
that's
a
thing
and
we're
the
kind
of
people
who
should
really
know
and
care
about
that.
So
what
we
need
to
be
doing
here
is
looking
at
more.
It
needs
to
be
done
so,
for
example,
government
policy
and
practice
in
terms
of
surveillance
and
data
sharing,
particularly
in
like
some
recent
political
events.
We
might
all
want
to
be
thinking
about
this
headset.
C
C
You
can
still
do
a
lot
with
the
data,
but
but
in
terms
of
certainly
academic
exercises
where
you
try
and
collect
data
day
in
the
life
of
the
internet
and
the
like,
there
needs
to
be
thought
given
to
D
identifying
that
data
to
protect
users.
A
very
quick
note
on
a
couple
of
topics
here
so
DNS
over
HTTPS
has
actually
been
around
for
a
while
non-standard
but
used
there's
a
really
good
review
of
why
it
was
used
and
some
of
the
motivations
well,
one
was
privacy.
It
brings
that
with
it.
C
Others
were
bypassing
middle
box
interference,
others
were
exposing
high-level
api's,
but
this
is
kind
of
gathering
a
bit
of
momentum,
so
it's
not
actually
being
positioned
as
a
previously
solution.
First
and
foremost,
it's
much
more
a
new
technology
and
their
address
to
specify
how
to
do
this.
Google
is
actually
offering
a
DNS
over
HTTPS
service
using
a
sort
of
non-standard
implementation,
but
there's
actually
now
a
non-working
Vic
mailing
list
and
there's
going
to
be
a
buff
on
Tuesday
night
on
this
topic.
C
So
if
you
interested
in
this
side
of
things,
I'd
encourage
you
to
go
so
this
is
the
matrix
that
I
showed
earlier,
where
what
we're
trying
to
show
is
the
current
mitigations
that
we
have
for
those
hot
spots
so
recursive
to
us
two
story:
stub
to
recursive.
We
have
encryption
and
authentication
today
for
recursive
to
authoritative.
C
We
have
the
mitigation
of
kino
minimization
and
we're
working
on
the
encryption,
and
it's
just
recognizes
that
the
error
of
data
policies
is
something
we
really
need
to
be
working
on
and
also
to
mention
that
there
is
a
draft
to
solve
the
DNS
SD
problem.
That's
been
adopted
by
the
working
group.
So
there's
progress
in
this
area
as
well
so
to
quickly
move
on
to
implementation
status.
C
So
I
just
want
to
show
these
very
briefly
just
to
show
that
there
is
activity
in
the
uptake
of
the
new
standards
within
dns.
So
these
are
three
well-known
open-source
dns
nameservers
other
implementations
are
available.
I
should
stress
I've
just
chosen
three
to
illustrate
it,
but
there's
work
in
all
of
these
on
the
new
standards
that
are
happening.
C
The
purple
box
in
front
of
bind
is
there
because
at
the
moment
the
approach
of
the
buying
folks
is
not
to
put
tier
less
directly
into
the
name
server.
Rather,
what
there
and
proposing
is
using
a
TLS
proxy
in
front
of
a
name
server,
and
there
are
lots
of
technical
reasons.
This
makes
sense
and
there
are
lots
of
one's
available,
so
this
is
certainly
a
viable
way
to
do
it.
I'm
on
the
stub
side,
most
of
the
energy
and
effort
has
been
expended
over
the
last
few
years
towards
get
dns
and
I'll
talk
about
that.
C
So
essentially,
there's
uptake
of
this
as
implementations,
I've
Dennis
of
TLS
we're
waiting
for
an
implementation
of
Dennis
every
TLS
that'll,
be
good
to
add
to
the
mix
and
bii
has
a
DNS
over
HTTP
implementation,
that's
available
as
well,
so
to
talk
about
what's
deployed
and
what's
actually
out
there.
There
are
a
handful
of
test
servers
available
today
that
are
up
and
running
to
start
on
getting
operational
experience
that
how
you
do
DNS
over
TLS
so
and
on
that
labs
are
running
10
our
car
running
one
as
a
few
hosted
by
surf
net
dkg.
C
The
man
has
put
one
up
there,
and
so
these
are
there
to
start
doing
activities.
There's
a
question
marking
its
ITF,
because
we've
sort
of
started
exploratory
talks
about
well,
maybe
the
next
ITF
could
offer
a
privacy
server.
Maybe
this
one
even
I'm
getting
faces
from
Warren
I
won't
ask
that,
but
but
that
would
be
a
nice
step
just
to
offer
that
so
people
can
get
experience.
And
if
you
want
to
know
the
details
of
these
servers
they're
at
a
web
page
under
that
link.
C
So,
in
order
to
use
those
servers,
you
need
some
client
software
that
will
connect
to
them
and
what
has
been
being
developed
over
the
last
few
years
is
based
around
get
dns.
So
if
you're
not
familiar
with
it,
get
dns
is
a
modern,
asynchronous
dinner.
Second
abled
api
bunch
of
information
at
the
website.
C
What
it
does
do
is
it
already
implements
DNS
over
TLS,
and
it
is
already
a
natively
validating
DNS
SEC
client
stub,
so
it
takes
two
boxes
in
terms
of
enabling
privacy.
So
what
has
recently
been
developed
in
the
last
release
is
a
new
mode
of
using
get
dns,
which
is
called
stubby.
This
is
the
mascot
for
it
sergeant,
stubby
I'll.
Let
you
google
him
if
you're
interested.
C
C
You
can
configure
it
for
our
configuration
file
in
that
file.
You
can
set
up
all
the
name.
Servers
that
you
need.
You
can
specify
the
authentication
information
you
might
want
to
use
you
can
specify
which
of
those
two
profiles.
Do
you
want
to
do
stricter,
opportunistic?
This
is
all
configurable,
there's
a
web
page
on
how
to
build
stubby,
configure
it
and
use
it,
and
if
anybody's
interested
in
actually
getting
hands-on
with
this,
then
come
and
find
me
or
William
turret
or
Alison
mankan,
who
are
busy
hacking
at
the
moment
in
the
hackathon.
C
So
just
to
mention,
what's
still
ongoing
at
the
moment,
as
I
mentioned,
have
been
a
lot
of
work
in
hacking
on
this
weekend.
We're
doing
a
lot
of
interrupt
testing
between
stubby
and
some
of
these
upstream
service,
so
we're
hopefully
maturing
this
and
making
it
much
more
usable.
A
challenge
that
I
haven't
really
touched
on.
Much
is
that
of
integrating
not
only
study
but
other
client
solutions
into
os's,
making
them
accessible,
making
them
usable
for
users,
and
this
face
is
very
similar
challenge
to
do
in
a
sack
in
that
respect.
C
C
So
to
summarize,
I
hope,
I've
convinced
you
that
DNS
privacy
is
is
a
real
problem
and
it's
relevant
problem
as
well
one.
We
need
to
be
thinking
about
and
working
on,
that
there
is
active
work,
but
this
is
a
large
loose
and
space.
There
isn't
gonna
be
an
overnight
solution,
but
that
work
is
in
progress
and
that
there
are
tests
implementations
out
there
that
you
can
use
today
if
you're
interested-
and
there
are
more
privacy
services
and
more
solutions
on
the
way,
also
I
think
in
the
very
near
future.
C
The
public
awareness
of
this
is
going
to
continue
increasing
after
all,
edward
snowed
and
got
hollywood
film
out
of
this.
So
people
are
aware
of
the
problem,
are
thinking
about
it
and
I
do
have
her
that
one
day
there
might
be
an
IDF
the
movie
to
recognize
all
the
folks
here
all
have
braces
and
all
the
implementers
fighting
the
good
fight
to
defeat
vasive
monitoring
and
that
that
will
happen
one
day
and
casting
suggestions
for
that
movie
will
be
very
gratefully
received
in
the
bar
later
on.
So
with
that,
I
will.
C
G
A
So
it's
not
going
to
be
a
automatic
in
TLS
1.3
at
any
rate,
so
we
have
there's
a
couple
of
possibilities
that
would
allow
s
and
I
cover
traffic,
basically
and
I'm
not
going
to
go
into
that
right
now,
because
I
think
usually
people
with
questions
about
the
DNS
but
I'm
happy
to
talk
with
you
afterwards,
and
if
anyone
has
other
specific
ideas
about
tina's
taylor
says
and
I
I
don't
hear
him
also.
This
is
not
just
for
TLS.
So
right.
H
C
What
has
been
remarked
is
that
it
would
be
quite
interesting
if
these
there's
uptake
in
terms
of
this
test
servers
and
it's
observed
that
DNS
traffic
is
being
retained
encrypted
and
how
certain
monitoring
authorities
might
react
to
that
in
terms
of
exact
outfit
occasion
of
personal
data.
I,
don't
know,
that's
an
unanswered
question.
I'm.
H
Just
thinking
this
memory
to
help
with
optic
of
these
technologies,
once
the
big
become
more
widely
accepted
and
widely
deployed,
and
there's
also
should
probably
where
there's
a
lot
of
operators.
Particular
the
European
Union,
a
very
concerned
about
data
retention
and
all
those
other
considerations
so
stuff
like
DNS
query.
Traffic
is
already
an
issue
for
them.
H
So
if
there's
a
reason
which
that
problem
can
be
can
be
minimized
from
their
point
of
view
by
using
some
of
these
office
keys
and
technologies,
that
could
also
be
a
good
thing,
but
the
message
didn't
have
to
be
coming
from
things
like
the
data
protection
authorities
disease.
We
can
serve
this
personal
data.
You
need
to
start
taking
things
much
more
sisa
by
how
you
treat
than
handle
that
data
yeah.