►
From YouTube: IETF97-TUTORIAL-DNSPRIVACY-20161113-1345
Description
TUTORIAL DNSPRIVACY meeting session at IETF97
2016/11/13 1345
A
B
B
C
D
D
E
G
Thank
you.
Everyone,
sorry
for
late
start,
so
welcome
today
to
the
ed
ed
you
tutorial
on
dearness
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
rise
and
to
kick
that
off
and
Daniel?
G
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
deprived
working
group
and
then
finally,
I'll
talk
about
the
current
status
of
implementations,
deployment
and
tools
that
are
available
today.
H
So
I
want
to
talk
just
a
little
bit
to
set
the
frame
for
why
DNS
privacy
matters
more
generally,
it
matters
sure
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
look
at
it.
Full
screen
thing.
H
Yeah
all
right
so
so.
The
concern
here
is
that
there's
sort
of
an
issue
of
possibility
of
sort
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.
H
I
find
that
troubling
and
I'd
like
to
make
sure
that
the
network
where
the
smarts
are
at
the
edges
doesn't
make
it
so
that
the
center
actually
has
control
over
those
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.
H
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.
H
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
tells
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.
So
you
can
do
the
next
slide.
H
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
the
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
ITF,
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.
But
in
fact
there's
a
bunch
of
other
stuff.
H
That's
coming
down
the
pike,
there's
old
stuff
like
MX
records,
which
which
will
actually
leaked
information
about
what
what
domain
you're
emailing
to
and
then
there's
things
like
Oakland
pgp
key,
where
you
might
actually
end
up
sending
the
name
of
whoever
you're
contacting
directly
at
the
DNS
so
or
another
name,
but
the
individual
email
account
which
is
sniffing
larger
privacy
leak.
So
there's
a
bunch
of
other
stuff
that
could
go
on
in
the
DNS,
and
people
want
to
use
the
DNS
for
that.
H
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.
I
think
this
this
year,
at
the
beginning
of
this
year,
where
they
basically
took
a
bunch
of
people
and
they
asked
them
their
opinion
on
some
topics
that
were
fairly
contentious
and
then
they
asked
them
their
opinion
of
about
the
sentence.
Is
it
like?
H
Basically,
it's
an
is
centralized
surveillance,
okay
and
it
turns
out
that
this
is
sort
of
a
long
lines
of
if
you're
not
worried
about
it.
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
in
turn
of
the
people
who
say
if
you're
not
you
know,
I've
got
nothing
to
hide.
H
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.
So
this
is
actually
an
ecosystem
problem,
where
the
fact
that
we
have
all
of
this
additional
leakage
means
that
people
are
less
likely
to
dissent
and
our
society
is
less
likely
to
be
able
to
evolve.
H
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.
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
if
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
you
as
like
how
to
society
change?
H
Has
a
behavior
change
as
a
result
of
having
this,
so
we
want
to
make
protocols
that
encourage
people
to
not
to
feel
that
they
are
projected
so
that
they
actually
can
communicate
with
people
even
in
an
environment
where
they
might
otherwise
feel
like
it's
house.
Island,
Ragnar
and
I
want
to
point
out
that
DNS
is
one
little
piece
of
these
leakages
right.
So
this
is
a
boat
here.
H
Dns
is
leaking
in
the
middle
of
the
boat,
but
there's
leaks
coming
from
the
TLS
layer,
the
server
name
indication
in
TLS
leaks,
there's
leaks
from
the
traffic
size
of
different
kinds
of
packets
that
you
send
timing
patterns.
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
legal
just
happening
somewhere
else.
H
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.
We
want
the
boat
to
stay
afloat,
so
the
motivation
here
is
to
try
to
make
sure
that
we
can
actually
get
I
mean
there's
a
lot
of
work
ahead
of
us.
We
actually.
H
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.
It's
not
going
to
solve
all
the
problems,
but
it's
a
step
in
that
direction.
G
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
d
into
what's
been
happening,
DNS.
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
ITF
napping.
G
But
what
I
want
to
illustrate
here
is
that
really
really
isn't
true.
The
ITF
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
dress
in
a
very
similar
manner.
G
As
to
the
way,
security
considerations
are
quite
naturally
put
in
drafts,
so
the
folks
behind
that
started
back
in
2011
and
they
were
right
on
the
verge
of
getting
it
published
as
an
RC
when
Edward
Snowden
revealed
his
them
a
data
to
the
world,
so
you
kind
of
got
a
feel
for
these
guys.
A
little
bit
gave
me
were
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
a
pervasive
monitoring.
G
A
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.
There
are
many
drafts
in
progress,
so
I
just
want
to
illustrate
that
there
is
a
lot
of
work
going
on
at
the
leadership
level
in
the
ITF
with
regards
to
privacy.
G
I
just
wanted
to
pull
out
just
a
couple
of
statements
from
roc
2558
in
terms
of
clarifying
that
the
iits
position
on
this
is
that
pervasive
monitoring
is
an
attack
on
internet
users
and
organizations
and
the
declared
aim
in
future.
Protocol
developments
is
to
mitigate
the
effects
of
monitoring
through
protocol
design,
so
doing
it
at
the
lowest
level,
not
necessarily
patiently
but
making
sure
protocol
design
takes
this
into
account
so
to
move
on
to
see
where
this
inter
intersected
with
DNS.
So
if
you
think
back
back
in
time
a
little
bit.
G
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!
So
there's
a
lot
of
bad
hair,
a
lot
of
good
music
and
the
DNS
is
being
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.
G
So
those
are
the
things
that
for
most
in
the
people
who
are
developing
the
protocol
in
previously
turns
the
DNS
is
described
as
an
enabler.
It's
a
system
that
you
use
to
get
to
other
services,
so
you
want
to
get
to
a
web
page.
You
go
via
the
DNS.
You
want
to
email,
something
you
go
via
the
DNS,
so
that's
where
it
sits.
Now
the
Sun.
G
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
the
more
cowbell
tool,
it
really
wasn't
a
tricky
job
for
them
to
monitor
dinis
traffic
because
of
the
way
it
moves
over
the
internet.
G
There
was
also
at
this
time
and
for
much
of
these
sort
of
25
year
time
period
here
that
I'm
spanning
a
perception
that
the
dearness
is
public
right
I
mean
anybody
can
query
these
records.
Anybody
can
get
to
them.
They
don't
contain
personal,
sensitive
information.
So
we
really
don't
need
to
worry
about
encrypting
this
or
protecting
it
in
any
way.
It's
the
dns,
and
that
was
out
there
for
a
long
time.
G
So
you
have
to
bear
those
things
in
mind
when
you
look
at
the
design
of
the
deer
and
ass
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.
G
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
with,
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
new
queries
are
leaking
information
who
at
root
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.
G
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
that
was
flexible.
It
could
contain
capability
options.
It
could
allow
clients
and
services
to
negotiate
things
like
paths
empty
use.
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.
G
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
is
how
recursos,
if
we
know
who's
making
those
queries.
G
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
buffer
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.
G
In
some
cases
it
was
observed
that
it
was
usernames
or
user
IDs
something
unique,
and
that
meant
they
could
do
their
filtering
it
recursive,
but
it
also
meant
that
anybody
who
is
passively
monitoring
that
link
could
immediately
correlate
all
those
queries
with
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.
G
That
said
well,
we
know
who
centers
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
to
the
authoritative
again
creating
correlations
within
the
data
with
the
activity
of
users
or
groups
of
users.
G
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
you're
a
curse,
the
only
thing
you've
got
anonymity,
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
great
and
there's
dkg
alluded
to
the
kind
of
cruise.
G
You
do
reveal
quite
a
lot
about
you
on
both
of
these
legs.
So
I
don't
know
about
me,
but
I'm
home
before
I
came
here.
I
was
looking
up.
What
conference
I
was
going
to
hotel
I
was
staying
a
hat
with
flight,
so
I
was
taking.
So
this
reveals
an
awful
lot
about
me,
including
how
abstracted
I
can
get
when
I'm
trying
to
put
a
big
slide
deck
together
and
what
sites?
I
go
wandering
off
ting,
but
this
is
all
information
they
can
correlate
back
to
me.
G
So
I
hope
at
this
point
I've
got
your
spidey
sense
is
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
so
take
this
another
step
further.
So
we've
looked
at
the
kind
of
leakages
you
get
on
DNS
queries
that
are
in
flight.
G
This
is
thinking
about
them
at
rest,
so
you
have
a
recursive
resolve
that
you're
using
so
you
have
to
start
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
their
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?
G
Could
there
be
breaches,
and
also
those
concerns
will
change
as
you
move
around
different
curses,
so
I
sure
at
home
or
at
work
as
you're
in
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
your
thority
tips,
because,
as
you
can
see,
information
can
make
it
up
to
that
level
about
the
activity
of
individuals.
G
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
ice
P
level
organizational
level
and
its
activities
whereby
people
running
with
curses
will
have
a
black
list
of
sites.
They
don't
want
people
to
get
to
and
they
will
actually
tell
the
initialize
in
order
to
block
access
to
those
sites.
G
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
your
cursor,
that
engages
in
this
kind
of
behavior
with
these
black
lists.
G
G
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.
G
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.
That's
nice
and
most
of
the
services
that
utilize
this
are
secure.
The
problem
comes
in
advertising.
G
Those
services
now
I
can
see
a
whole
bunch
of
max
here
and
I
know
that
if
you
simply
just
open
finder
and
look
in
your
sidebar,
you
can
probably
see
a
whole
load
of
devices.
Advertised
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
Stewart
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
ITF.
If
you
tap
the
air
print
button
on
your
phone
it'll,
do
a
query
for
IP
p,
t
CP
doc,
meeting
that
ITF
dog
dog
hey,
which
will
go
across
the
Pacific
to
Virginia
or
wherever
the
authoritative
server
is
for
IETF
dog
yeah.
E
H
E
What
I
was
saying
is
when
you
do
it
over
unicast,
it's
going
over
the
public
Internet
in
the
clear
unencrypted.
Every
time
you
tap
the
air
print
button
on
your
phone
and
printed
documents
on
the
terminal
room
printer
here
yeah,
even
though
you're
printing
it
on
a
printer
down
the
hallway
you're,
sending
a
query
to
the
US
and
back
to
ask
for
the
address
of
that
printer
right.
I
mean
I'm,
assuming
the
authoritative
server
for
IETF
torgus,
not
isn't.
G
So,
in
terms
of
advertising,
what
you're
doing
here
and
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
by
Alice.
G
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.
G
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
purse
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.
G
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,
say
back,
then.
If
he
were
savvy
to
dinner,
is
he
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
dear
script
was
developed
and
it's
still
around.
G
There
are
a
number
of
implementations
so
and
in
fact,
opened
in
us
offer
that
as
a
mechanism
when
you
use
their
resolvers,
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,
priority
mechanisms
to
protect
users
also,
although
these
were
documented,
neither
actually
made
it
to
through
the
standards
process.
G
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
is
a
better
choice
but
than
using
an
intermediate
recur.
Sir
also,
what
came
out
around
this
time
was
a
talk
of
dearness
trigger
now
again.
G
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
attempt
DNS
over
TLS
on
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.
G
So
having
talked
about
the
historical
context
for
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.
G
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?
G
This
was
a
big
problem
and
what
the
working
group
decided
in
its
initial
charter
was
to
focus
solely
on
the
stub
to
recursive
and
step
of
this,
and
there
are
various
reasons
for
this
to
our
summarize.
Our
one
is
that
that
stub
to
recursive
stage
leaks
the
most
information,
so
if
you
can
tackle
that
you're
going
a
long
way
towards
helping
and
users.
G
G
You
have
the
one
use
at
home
work
when
you're
asking
about,
but
generally
you
either
have
a
relationship
with
that
recursive
resolve
or
you
make
a
conscious
choice
to
use
it
by
going
to
a
captive
portal
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
of
those
you
may
never
ever
talk
to
you
before.
So
that
makes
authenticating
the
one
too
many
unknowns,
difficult.
G
G
So
the
first
thing
that
the
working
group
did
is
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
discussion
here
today,
but
in
much
more
detail,
and
it
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
key
thing
that
this
document
does,
though,
is
it
robots?
G
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.
G
So
having
established
the
problem,
we
now
start
looking
at
solutions
and
there
were
various
ones
that
could
have
been
looked
at
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
50
three.
It
could
be
incrementally
deployed,
it
was
a
known
technique
that
was
all
nice
on
downside,
though.
G
G
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
none
known
so
discussion
moved
on
to
looking
at
doing
tearless
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
were
some
concerns
about
scalability
of
it.
G
G
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
spawns
and
it
has
to
request
client
to
retry
over
another
mechanism
when
you're
dealing
to
privacy.
G
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
asked
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.
G
What's
going
on
with
dns
tcp,
I
mean
some
people
sort
of
shocked,
shocked
to
find
that
tcp
amused
for
dns
at
all,
but
it
was
but
not
in
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
the
TTP-
they
would
do
one
shot
over
tcp
and
go
straight
back
to
UDP,
and
that
was
a
pattern
that
clients
implemented
across
the
dns.
G
So
on
the
server
side,
the
service
were
all
sitting
there
going.
Well,
I
don't
really
have
to
worry
about
TCP
I'm
gonna
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
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.
G
In
fact,
I'm
completely
wrong
slide.
Okay,
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.
G
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
an
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
sol
bunch
of
stuff
about
what
individual
users
are
doing.
G
Okay,
so
top
of
that
list
was
getting
your
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,
port
853
was
assigned
for
use
for
encrypted
DNS,
who
our
next
problem
deal
with
this
issue,
with
DNS
over
TCP
to
enable
TLS
over
TLS.
So
this
wasn't
an
insurmountable
problem.
It
was
really
just
a
question
of
engineering.
So
what
do
we
do?
G
G
So,
for
example,
when
DNS
clients
and
servers
assessing
at
connections,
you
need
to
make
sure
that
they're
using
techniques
like
fast
open
session
resumption-
and
you
want
to
have
a
really
close
eye
on
till
s-
1
point
3,
because
that's
going
to
do
good
things
in
terms
of
reducing
latency
for
setting
up
these
connections.
When
you
set
the
connections
up,
you
want
to
stop
this
behavior
of
one
shot.
Tcp.
You
want
to
recommend
that
clients
once
I
have
a
connection
open.
G
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.
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.
G
There
was
no
standard
way
for
a
DNS
client
and
a
DNS
server
to
agree
that
they
wanted
to
do
persistent
tcp.
It
just
wasn't
there
in
spec.
It
is
now
also
in
terms
of
managing
TCP
connections
on
a
DNS
server.
Then
there's
there's
a
huge
amount
that
we
can
just
learn
from
the
HTTP
URL.
This
guy
been
doing
it
for
a
long
time
and
not
just
https.
G
Is
thank
you
yeah
keep-alive
is
28,
isn't
it?
Thank
you
very
much.
Apologies
I
am
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
little
illustration
of
sort
of
bad
to
NSO,
tcp
versus
good
dearness
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.
G
So
at
the
moment
what
specified
are
two
profiles:
strict,
San,
opportunistic,
so
the
strict
profile
is
one
where,
as
a
client,
you
decide
that
if
I'm
going
to
do,
Dennis
I
want
to
get
an
encrypted
connection
and
I
want
to
authenticate
my
server
and
if
I
can't
do
both
those
things,
then
I
am
not
prepared
to
compromise
my
privacy,
so
I
just
won't.
Do
dns
resolution
and
I
can't
get
to
the
internet,
but
that
is
somebody
saying
my
privacy
is
more
important
than
my
connectivity
and
that's
a
choice
to
make
as
a
user.
G
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
the
DNS
folks
and
aren't
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
an
authentication
by
day.
G
G
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.
G
The
alternative
mechanism
is
one
using
something
called
the
TLS
d
in
a
sec
chain
extension.
This
is
a
draft
which
is
currently
going
through
the
TLS
working
group.
What
this
does
is
it
starts
from
exactly
the
same
point,
but
it
shifts
the
responsibility
for
getting
those
damn
records
onto
the
dearness
privacy
server,
because
after
all
it's
a
DNS
server.
G
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
in
this
case,
once
that
server
has
the
records
the
client
can
then
in
the
client,
hello
indicate
that
it
supports
this
new
extension
tippity
LST
in
a
sec
extension,
so
hey
server,
I
I,
know
all
about
this
new
extension.
Do
you
yes,
I
do
here,
have
my
dane
records
in
server
hello,
along
with
my
credentials,
have
at
them
client
goes
fine,
lovely,
okay.
G
First
up
I'm,
going
to
validate
your
day
records
with
doing
a
stake
because
I'm
a
validating
crime
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
date
records,
so
the
streamlines
a
whole
process.
G
Okay,
so
on
this
slide,
I'm
just
presenting
were
deprived
is
today
in
terms
of
the
documents
it
has
in
the
solution:
space
for
the
stub
to
recursive
part
of
the
problem.
So
in
May
of
this
year,
78
58
got
it
right
that
was
published,
which
is
a
specification
for
DNS
over
TLS
alongside
that,
7830
was
published,
which
is
the
ed
and
I
serum
mechanism,
so
that
you
can
pad
a
DNS
query
by
an
amount
and
there's
more
follow-up
work
to
talk
there
about
what
algorithms
to
use
to
pad
that.
G
But
at
least
we
have
the
basic
mechanism
in
place.
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
rascal
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.
A
lot
of
progress
has
been
made
so
what?
G
G
One
thing
I
do
want
to
touch
on
is
that
okay,
we
don't
have
an
encryption
solution
for
recursive
to
authority
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.
Whether
bad
idea
fairy
said
leaked
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.
G
This
looks
totally
trivial
and
it's
not
quite
as
some
really
icky
corner
cases
in
this
when
you
have
to
go
following
see,
names
and
the
like,
but
the
good
news
is
those
are
being
solved
in
implementations,
and
this
is
now
being
rolled
out
into
the
major
open
source
name.
Several
implementations
today.
G
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.
We're
focusing
there
I
mean
so
I
can
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
and
I'm.
G
Not
one
of
them
say:
wow
you'll
have
lies,
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
like
some
recent
political
events.
We
might
all
want
to
be
thinking
about
this
headset.
G
G
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,
then
least,
we
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.
G
Others
were
bypassing
middle
box
interference,
others
works
posing
higher-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
ever
HTTPS
service
using
a
non-standard
implementation,
but
there's
actually
now
a
nonworking
big
mailing
list
and
there's
going
to
be
a
boffin
Tuesday
night
on
this
topic.
G
We
have
encryption
and
authentication
today
for
recursive
to
authoritative
we
have
the
mitigation
of
QA
minimization
and
we're
working
on
the
encryption,
and
it's
just
recognizes
that
the
area
of
data
policies
is
something
we
really
need
to
be
working
on,
and
also
to
mention
that
that
is
a
draft
to
solve
the
dss
d
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.
G
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.
G
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
the
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.
G
I'm
on
the
stub
side
and
most
of
the
energy
and
effort
has
been
expended
over
the
last
few
years
towards
get
dns
and
I'll
talk
about
that.
A
little
more
on
the
next
slide
and
you'll
notice,
some
emission
notable
emissions
from
this
in
terms
of
deployed
and
used
at
libraries
and
that's
a
real
challenge
in
terms
of
getting
new
features
into
those
libraries.
G
So
essentially,
there's
uptake
of
this
as
implementations
of
dennis
of
TLS
we're
waiting
for
an
implementation
of
dennis
l,
ET
les,
the
guitar
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,
how
you
do
DNS
over
TLS
so
and
on
that
labs
are
running
100
our
car
running
one
as
a
few
hosted
by
surf
net
dkg.
G
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've
been
asked
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
there
at
the
web
page
under
that
link,.
G
So,
in
order
to
use
a
service,
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
doing
a
second
abled
api
bunch
of
information
at
the
website.
G
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.
G
G
You
can
configure
it
for
a
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
will
interrupt
or
Allison
mankan,
who
are
busy
hacking
at
the
moment
in
the
hackathon.
G
So
just
to
mention,
what's
still
ongoing
at
the
moment
and
as
I
mentioned,
have
been
a
lot
of
work
in
hackathon
this
weekend.
We're
doing
a
lot
of
interrupt
testing
between
study
and
some
of
these
upstream
servers,
so
we're
hopefully
maturing
this
and
making
it
much
more
usable
and
a
challenge
that
I
haven't
really
touched
them.
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
today
in
a
sack
in
that
respect.
G
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
loosened
space.
There
isn't
get
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.
G
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
they
are
thinking
about
it
and
I
do
have
hopes
that
one
day
there
might
be
an
IDF
the
movie
to
recognize
all
the
folks
here.
Operators
and
all
the
influences
fighting
good
fight
to
defeat
vasive
monetary
and
that
that
will
have
one
day
and
casting
suggestions
for
that
movie
will
be
very
gratefully
received
in
the
bar
later
on.
So
with
that,
I
will.
Thank
you
for
your
time.
G
I
H
I
H
H
H
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
sni
cover
traffic,
basically
and
I'm,
not
going
to
go
into
that
right
now,
because
I
think
there's
other
people
with
questions
about
the
DNS,
but
I'm
happy
to
talk
with
you
afterwards,
and
if
anyone
has
other
specific
ideas
about
doing
it
jealous
s
and
I.
Here
also,
this
is
not
just
for
TLS.
So
right.
J
G
What
has
been
remarked
as
this?
It
will
be
quite
interesting
if
these
there's
uptake
in
terms
of
this
test
servers
and
it's
observed
that
DNS
traffic
is
being
routinely
encrypted
and
how
certain
monitoring
authorities
might
react
to
that
in
terms
of
exact
office.
Gation
of
personal
data,
I,
don't
know,
that's
an
unanswered
question.
I'm.
J
Just
thinking
this
memory
to
help
with
optic
of
these
technologies,
once
the
big
become
more
widely
accepted
and
widely
deployed,
and
as
also
as
you're,
probably
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,
so
if
there
are
reasonably
that
problem
can
be
can
be
minimized
from
their
point
of
view
by
using
some
of
these
office
keys
and
technologies.