►
From YouTube: IETF106-DPRIVE-20191122-1000
Description
DPRIVE meeting session at IETF106
2019/11/22 1000
https://datatracker.ietf.org/meeting/106/proceedings/
A
Good
morning,
all
I
was
just
waiting
for
the
some
of
the
presenters
to
finish
their
last
minute
conversations.
So
it's
Friday
morning
and
we've
been
here
a
long
time,
so
welcome
to
deprive
Dena's
privacy,
I'm
Tim
Bennett,
filling
in
for
Brian
Brian's
on
the
other
side
of
the
world.
So
if
there's
any
mistakes,
we
can
throw
him
under
the
bus
unless
that's
poor
form
so
and
our
very
responsible
area
director
Eric
there
in
the
front
row,
so
Paul
opt-ins
offer
to
do
minutes.
So
thank
you.
A
We'd
need
a
jabber
scribe
because
we
all
fail
it
during
Jabbar.
So
if
anybody
can
manage
to
make
that
work,
that
would
be
super
great
I
know,
there's
a
bunch
of
people
at
meet
echo
as
well.
You
all
know
the
note.
Well,
you
should
know
it
by
now.
We
should
be
able
to
sort
of
repeat
it
by
heart
because
it
is
Friday
morning.
So
just
keep
that
in
mind.
A
A
So
three
documents
updates
the
BCP
of
course,
has
been
finished
and
we
submitted
it
done
the
Shepherd
right
up
and
it's
now
in
our
very
responsible
eighties
hands
the
seventy
six.
Twenty
six
biz
has
been
done
and
that
actually
looks
like
I
think
it's
moving
forward
for
pretty
quickly
and
then
we
adopt
that
the
expert
over
TLS
draft
and
so
that
ones
in
our
queue.
A
So
that's
pretty
much
the
only
current
one,
that's
actually
in
our
queue,
but
we've
you
know,
we've
got
lots
other
stuff,
that's
sort
of
floating
around
and
of
course,
since
most
of
you
are
at
the
pretty
excellent
ABCD
Bob
earlier
this
week,
there's
always
good
times
there.
So
some
stuff
will
probably
end
up
floating
this
way
and
some
of
those
documents
are
gonna
be
on
the
menu
today.
A
The
adaptive
DNS
privacy,
which
Tommy
just
had
in
the
buff
and
then
also
the
oblivious
dope
draft
and
then
the
deep,
deep
ride
privacy
policy
that
looks
like
I've
there's
a
double
tape
in
there.
So
those
are
the
big
three
drafts
and
then
the
big
one
is
actually
the
Phase
two
requirements
document
that
we
had
the
in
term
on
Alex
Jason,
who
I
didn't
think
was
gonna,
be
here
and
Ben
are
gonna.
Do
that
we're
trying
to
prioritize
some
of
those
requirements?
A
We're
not
trying
to
solve
everything
here
today
that
that
we're
just
gonna
go
down
and
rat
holes
for
that
and
our
plan
is
to
adopt
that
as
a
working
group
document
only
so
it
will
be
adopted,
but
it's
busy
for
us
to
work
on
and
to
sort
of
help,
sort
of
sort
all
those
requirements
out,
and
so
that's
essentially
our
agenda
today.
So
there's
basically
the
three
drafts
and
then
the
big
discussion
about
the
requirements
and
that's
gonna
be
a
pretty
free-flowing
conversation.
So
so
I
think
what
we'll
do
is.
That's
it
so
Tommy.
A
B
C
B
All
right,
good
morning,
everyone
happy
Friday.
You've
made
it
this
far,
so
I'm
Tommy,
Polly
I'm
from
Apple
I'll
be
presenting
this
document
that
I've
worked
on
with
Chris
Wood
Eric
on
our
team,
as
well
as
Patrick
McManus,
and
so
this
one
is
presented
in
the
ABCD
Boff.
The
main
focus
I
tried
to
have.
There
was
on
the
way
that
we
do
discovery,
how
we're
trying
to
approach
the
problems
and
particularly
how
we
interact
with
the
local
networks,
because
that's
very
much
the
focus
of
that
off
for
this
I'm
gonna
cover
a
bit
of
that.
B
But
I
also
want
to
talk
about
some
of
the
mechanisms
that
we're
trying
to
do
at
a
bit
more
technical
layer,
so
it'd
be
great
to
have
everyone's
input.
Here
we
did.
You
know
these
drafts
are
marked
as
being
under
deprived
because
it
seems
like
they
fit
under
the
category
of
DNS
privacy.
However,
I
think
there's
still
discussion
about
where
exactly
this
work
should
progress.
B
All
right
so,
of
course,
some
background
to
start
with
here's
our
picture
of
our
status
quo.
Dns.
We
have
you
know
three
parties
generally
involved
when
we're
not
doing
any
other
privacy
mechanisms.
We
have
our
client,
we
have
our
local
network
resolver
that
we're
assigned
via
DHCP
or
Ras,
and
we
have
the
actual
names
and
origin
servers
we're
trying
to
reach.
B
So
we
see
this
common
trend
right
now
of
looking
at.
How
do
we
use
these?
You
know
private
trusted,
resolvers
oftentimes.
These
are
public,
recursive
doe
servers
and
it
often
ends
up
skipping
entirely.
The
local
resolution
infrastructure
and
this
it
has
some
concerns,
certainly
for
people
who
are
running
that
local
infrastructure,
but
also
as
an
operating
system
vendor.
It
does
have.
B
So
the
goals
that
we
have
in
this
document,
which
we're
calling
adaptive
DNS
privacy
in
this
is
kind
of
the
overall
architecture
document,
the
other
one
that
Chris
is
present,
is
more
of
a
detailed
technical
bit
for
how
we
add
some
extra
privacy
on
top
using
oblivious
queries.
But
the
goals
here
are
to
overall
improve
our
DNS
privacy
for
client
requests
without
requiring
that
we
have
some
fixed
or
whitelisted
lists
of
public
resolvers
that
we're
doing
and
skipping
all
the
local
infrastructure.
B
We
think
that
we
need
to
discover
many
different
encrypted
DNS
servers,
and
we
need
to
have
clear
indications
of
when
to
use
them
and
there's
a
basic
premise
here,
that
there
are
scenarios
in
which
we
don't
necessarily
want
to
send
all
of
our
queries
through
the
local
resolver
I.
Think
these
in
these
represent
a
lot
of
scenarios
in
which
I
may
be
on
a
network
that
I,
don't
totally
trust
and
I,
don't
think
it's
appropriate
for
it
to
see
all
the
names
that
I'm
accessing
and
be
able
to
build
up
a
profile
about
the
user.
B
It's
such
that
we
don't
even
have
to
worry
about.
Is
this
public
resolver
that
I'm
talking
to
something
that
I
really
can
trust
to
not
log
what
I'm
doing
to
make
sure
that
even
it
cannot
see
everything
I'm
doing
and
build
up
a
profile
about
me?
So
that's
the
scope
of
this
document
so
specifically
I.
Think
one
of
the
interesting
parts
technically
is:
how
do
we
discover
the
encrypted
resolvers
that
are
appropriate
to
use
for
different
names,
and
there
are
many
different
options
that
you
can
have
here.
You
can
have.
B
Why
listing
you
could
have
information
that
comes
over
DHCP
or
Ras,
but
what
we
are
proposing
in
this
document
is
to
have
the
information
about
what
I
should
use
to
do.
My
encrypted
resolution
come
from
the
DNS
itself,
because
that's
kind
of
the
system
that
we're
working
in
and
it
seems
to
make
most
sense.
B
So
this
proposal
is
using
the
service
binding
records.
The
names
are
still
in
flux.
Current
links
are
called
SVC,
B
and
HTTP
service.
Now
these
are
records
that
are
able
to
communicate,
amongst
other
things,
alt
serve
and
ES
ni
keys,
but
we
also
want
to
use
them
to
indicate
the
information
about
what
doe
servers
are
being
designated
for
a
given
zone
essentially,
and
we
also
want
to
make
sure
that
these
designations
are
things
that
we
can
validate
and
trust
such
that
people
can't
intercept
it.
B
So
we
do
want
to
use
DNS
SEC
to
assign
these
records,
particularly
and
that's
a
very
important
part.
So
a
lot
of
people
have
also
even
brought
up
questions
about
DNS
SEC,
we'll
get
into
that
a
little
bit
later,
so
the
picture
ends
up
looking.
If
we
just
add
one
more
step,
something
like
this,
we
do
have
our
local
resolver.
We
definitely
will
use
it,
but
let's
say
I
then
discovered
that
there
is
a
designated
doe
server
for
the
zone
under
example.com,
so
for
any
names
within
that
zone
that
may
be
private
or
sensitive.
B
I
know
that
it's
safe
to
use
that
DOE
server
and
I
also
have
a
pretty
good
chance
that
this
doe
server
is
something
that
maybe
I
could
use
for
a
better
coalescing,
because
this
is
actually
something
that
is
being
managed
by
the
same
entity
that
is
managing
the
main
example.com
server.
So
as
a
difference
from
just
using
a
public
recursive,
it's
kind
of
still
more
a
three-party
system.
We
haven't
added
that
fourth
party
into
this,
and
then,
of
course,
you
know
this
thing
could
expand
to
be.
B
You
know
much
bigger,
because
we
actually
have
many
different
designated
servers.
We
also
need
to
make
sure
that
these
things
play
well
with
VPNs,
etc.
So,
one
of
the
pieces
of
complexity
that
this
does
add
is
that
clients,
in
this
case,
do
need
to
be
aware
of
the
right
rules
for
when
to
use
what,
as
someone
who
you
know,
implements
our
VPN
slip,
dns
logic.
This
is
something
that
we
definitely
have
the
ability
to
do
today,
and
so
one
of
the
questions
is
how
this
scales,
beyond
that.
B
If
we
want
to
be
able
to
bootstrap
doing,
oblivious
queries
to
this
same
server
and
I
do
want
to
point
out
that
you
know
a
lot
of
the
benefit
of
this
is
related
to
when
we
do
have
es
ni
keys.
So
today
oftentimes
we,
if
we're
doing
doe
to
some
server.
Yes,
we
are
encrypting
that
name,
and
maybe
that
is
private
from
the
local
network,
but
it
is
pretty
trivially
easy
and
people
are
already
doing
this
to
look
at
the
SNI
that
is
going
through
the
TLS
handshake
and,
if
they're,
not
using
TLS
they're.
B
Even
more
obvious
about
what
they're
accessing,
so,
it
is
a
requirement
to
really
get
a
fully
private
name
solution
that
the
server
infrastructure
of
who
owns
this
name
does
need
to
change.
They
need
to
add
any
s,
ni
key
and
so
essentially
we're
saying
at
the
same
time
give
us
the
information
that
helps
us
bootstrap
the
encrypted
dns
as
well.
B
So
the
details
of
the
formatting-
these
are
two
different
examples
of
how
you
can
encode
this.
The
service
binding
record,
has
an
alias
form
in
a
non
aliased
form.
These
are
just
two
ways
that
that
can
play
out
it's
relatively
simple,
all
right,
so
some
common
questions,
I
just
want
to
address
and
have
some
discussion
about-
are
your
thoughts
on
so
one
is:
why
are
we
using
doe
and
not
dot,
we'll
get
into
that?
Why
are
we
using
DNS
SEC?
Some
people
are
allergic
to
D
in
a
second,
some
people
love
it.
B
So
it's
an
interesting
conversation
to
have
and
then
also
how
does
this
overall
system
get
bootstrapped
because
it's
you
know,
it
seems
that
you
need
to
do
a
query
over
some
resolver
that
you
may
not
trust
in
order
to
find
out
who
you
do
trust.
So,
let's
go
through
each
of
those
three
now
all
right,
so,
first
the
choice
of
protocol.
Right
now
we
are
focusing
on
doe.
Some
of
the
discussion,
if
you
may
have
seen
on
the
ad
D
list
has
been.
B
B
There
are
other
benefits
we
see
in
doe
that
work
well
in
this
architecture,
so
one
it
does
allow
the
possibility
of
connection
reuse
with
HTTP
so
like
if
I
end
up
doing
a
doe
connection
to
example.com
I
can
potentially
start
doing
more
requests
to
that
same
server
if
it
happens
to
be
co-located,
I
think
when
the
biggest
ones
for
me
is
that
it
allows
us
to
migrate
to
quick
very
easily.
Of
course,
we
can
define
a
DNS
over
quick
mapping.
B
You
could,
of
course,
add
these
things
to
protocols
like
dot,
but
the
format
for
that
is
simple
enough,
that
it
was
a
little
bit
too
much
work
to
extend
all
that
to
say,
though
this
you
know
system
for
saying
how
we
want
to
designate
encrypted.
Dns
servers
could
equally
work
well
for
saying
that
here
is
a
dot
server
that
we
should
use
for
this.
B
So
if
the
DOS
server
destinations
are
not
signed,
they
can
be
steered
around.
What
we
currently
have
in
the
document
is
the
requirement
that
these
designations
are
DNS
X
signed,
because
this
provides
a
mechanism
to
tie
this
destination
to
the
person
who
signs
the
zone,
and
this
is
a
good
route
of
trust
for
the
information
about
what
we're
getting
from
DNS.
B
It
also
allows
us
to
have
a
fairly
public
record
that
you
could
follow
and
easily
corroborate.
From
other
vantage
points.
One
of
the
concerns
here
is
that
it
does
seem
like
you
know,
certain
deployments
find
it
a
barrier
to
entry.
There
are
a
lot
of
large
deployments
that
are
not
necessarily
signing
all
of
their
zones,
so
if
people
do
have
thoughts
about
ways
to
make
this
easy
to
do
or
other
some
people
have
talked
about
it.
Ok,
we
have
other
signing
mechanisms
here.
B
So,
along
with
that
initial
traffic,
we
could
easily
imagine
that
there
would
be
some
generic
non
user
identifying
queries
that
go
out
that
help
us
discover
that
as
designations
for
kind
of
the
system
default
traffic,
so
on
an
iOS
device,
we're
probably
going
to
be
connecting
back
for
push
notifications
to
Apple
servers,
and
so
that's
an
opportunity
to
do
a
non
user.
Specific
query
that
allows
us
to
discover
some
designated
doe
server.
So
those
we
will
have
queries,
of
course,
that
go
always
over
the
local
DNS
infrastructure.
B
And
then,
after
that
point,
depending
on
the
stance
we
have
towards
that
local
network,
we
have
a
couple
different
options.
So
if
this
is
a
network
that
maybe
is
you
know,
my
carrier
is
B
that
if
the
user
has
an
explicit
relationship
with
and
that
they
do
trust,
we
didn't
imagine
that
some
of
this
designated
doe
is
really
done
at
a
kind
of
ekam
best
effort
basis
right
like
when
we
know
that
we
do
have
some
destinations.
B
We
make
those
private
those
correspond
to
servers
that
have
ES
and
Nikes,
and
we
do
it
that
way.
If
we
are
a
bit
more
paranoid
and
we
don't
trust
this
network
I'm
at
some
sketchy
cafe
you
and
I'm
on
vacation
I,
don't
know
what's
going
on.
We
could
instead
use
oblivious
doe,
which
we'll
talk
about
a
bit
later
and
that,
as
long
as
we
have
knowledge
of
some
doe
server,
that's
out
there
that
allows
this
as
well
as
some
way
to
proxy
to
it.
B
It
will
then
find
out
with
a
DNS
xn
record
that
there
is
a
designation
to
DNS
example
net,
and
it
will
know
where
that
doe
server
is.
At
that
point
we
can
say
we
have
essentially
bootstrapped
our
doe
connections.
We
then
ask
it
for
any
names
within
that.
Maybe
these
are
private
names
that
it
may
be
sensitive
for
some
reason,
and
then
we
can
have
connectivity
there.
So
the
local
network
can
certainly
know
that.
B
B
So
if
I
talk
to
Apple,
maybe
it
says
oh
yeah
I
host
iTunes
I
host
iCloud,
and
these
are
other
things
that
you
can
get
here
and
then
the
client
would
request
the
same
records
to
prove
that
designation
and
validate
that
there
is
a
DNS
sex
signature
that
says
that
this
server
is
also
Thorat
ativ.
For
those
and
there's
some
nice
things
you
can
do
with
doe
here,
because
HTTP
2
can
start
pushing
some
of
these
default
records
to
prove
its
designations
for
more
of
the
different
zones
without
actually
wasting
a
roundtrip.
B
Those
are
some
of
the
answers
to
the
basic
questions
that
often
come
up.
We
have
a
couple
different
issues
that
we
are
working
on
and
we
are
having
various
conversations
with
people
about.
We
didn't
mean
to
make
sure
that
we
have
a
good
story
around
multi
CDN
deployments
when
you
have
names
that
are
being
managed
by
multiple
different
entities
that
we
do
want
a
good
story
about
what
we
should
do
and
what
the
recommendations
are
for
zones
that
maybe
aren't
DNS
SEC
ready.
B
Yet
there
may
be
an
option
here
there
may
not
be
if
people
have
ideas,
I'd
love
to
hear
them.
We
also
want
to
have
guidance
on
when
it's
appropriate
to
reuse,
HTTP
connections
that
were
used
for
dough
and
start
using
for
other
connections
in
a
way
that's
not
going
to
abuse
privacy,
and
we
also
want
to
dig
into
more
about
the
failure
options
about
how
you
fall
back
between
these
different
server
configurations.
B
So
at
the
bottom
there
is
a
github
link
to
where
we
have
these
documents.
We
have
a
bunch
of
issues
and
pull
requests
filed
by
people
and
I
encourage
you.
If
you
have
thoughts
to
chime
in
there,
because
that's
a
great
way
to
interact
with
the
authors,
all
right,
I
think
that's
my
last
slide.
Chris
will
talk
a
little
bit
more
about
our
oblivious
dough
in
a
bit.
But
if
there
are
questions
now
comments
that'd
be
great
to
hear.
Oh
I.
A
D
A
B
A
C
B
D
That
Alex
meal
for
Nick
today
t
I
think
that
is
a
pretty
broad
impact
on
the
on
the
summit
of
the
general
concept
of
the
DNS,
because
essentially,
you
can
like
designate
a
server
to
be
sort
of
authoritative
for
domain,
even
if
it's
not
authoritative
according
credit
delegation
and-
and
you
also
like
get
into
a
grey
area
between
this
is
authoritative,
and
this
is
recursive
because
the
server
could
like
provide
other
responses.
So
it's
a
completely
new
world
of
how
DNS
works,
essentially
so
I
think
we
should
treat
that
pretty
carefully
yeah
yeah
yeah
this.
D
C
B
D
B
B
G
From
the
jabber
room,
a
peter
spot-check
says
I'm
against
adoption
in
its
current
form.
Basically,
this
is
a
combination
of
custom-made
pour
network
limited
to
Dinah's,
plus
auto
configuration
magic
on
top.
At
the
same
time,
latest
research
and
privacy
field
has
shown
that
hiding
only
dns
traffic
does
not
actually
help
much,
because
just
the
set
of
server
IP
addresses
client
is
connecting
to
is
sufficient
to
reveal
what
website
the
client
is
accessing.
For
this
reason,
this
humongous
complexity
is
not
justified.
G
B
That
point
absolutely
agree
that
the
IP
address
alone
does,
in
a
lot
of
cases,
give
away
a
lot.
This
is
trying
to
make
it
possible
for
us
to
have
good
DNS
name
encryption,
as
I
mentioned
before.
It
also
does
require
that
you
do
have
encrypted
sni
and
beyond
that.
It
requires
that
whoever
is
hosting
these
IP
addresses
has
a
sufficient
in
a
non
anonymity
set
of
the
name
to
address
mappings.
So
essentially,
it
is
possible
to
build
a
deployment.
B
H
Stephen
comment
on
two
questions,
which
are
kind
of
really
one
question
and
I
kind
of
generally,
like
it
I
think
you're
a
bit
optimistic
about
the
NSX
but
yeah
okay
eater.
Can
you
go
to
the
slide
with
the
bit
of
JSON
there
yeah
so
about
this?
These
names
here
the
DNS
zones,
you
name
here
and
about
the
oblivious
feature
yep.
H
It's
really
not
clear
to
me
how
a
client
is
going
to
react
differently
to
those
versus
things
that
are.
You
know
how
to
decide
to
use
the
oblivious
feature.
How
would
the
decide
to
treat
names
below
foo
Burnette
differently,
as
it's
trying
to
resolve
stuff
I
mean?
How
would
a
client
decide
that
is
it?
Are
you
intending
that
that
would
be
a
standard
behavior
that
we
would
specify
yeah.
I
B
H
B
I
Yes,
similar
concerns.
This
I
mean
I.
Think
one
thing
with
this
particular
specifically.
Is
you
know
how
do
I?
How
does
the
client
know
that
the
tow
servers
actually
has
any
sort
of
relationship
with
an
example
come
right,
so
it
sounds
like
this
information
is
actually
duplicating
the
information
in
the
in
the
HTTP
service
record.
That
tells
you
I
am
the
DOE
forever
for
this
domain.
Okay,.
B
I
B
I
If
you--if,
instead
of
just
an
optimization,
it
was
actually
I'm
gonna
optimize
by
giving
you
the
information
that
you
will
need
anyway.
If
you
use
any
of
these,
then
that
would
be
I
think
it'll
be
simpler,
but
we
could
take
that
offline
sure,
just
just
by
giving
you
the
reference,
because
at
the
end
of
the
day,
if
I
get
this
I'm,
like
sure
you,
you
think
your
authority
for
example.com.
That's
just
your
opinion.
Do.
H
B
J
B
I
J
Ben
Schwartz,
so
there's
a
lot
of
details
here.
I
think
it's
tempting
to
to
dive
right
into
all
of
the
diesels.
Oh
thanks
for
the
detailed
proposal.
I
think
we
should
still
be
thinking
a
little
bit
more
about
architecture.
Yes,
it
seems
to
me
that
some
people
have
said
this:
that
you're
you're
building
a
spectrum
between
recursive
and
authoritative
here,
I
think.
That's
a
cool
idea.
I
think
that
there's
it
would
be
worthwhile
trying
to
harmonize
this
with
the
recursive
to
authoritative,
encryption,
mm-hm.
C
J
K
Rock
on
my
end,
to
announce
a
bit
of
this,
encourage
you
really
to
look
in
the
other
transport
like
dot
and
DNS
over
over
over
Quaker.
Eventually,
I
mean
we
don't
need
the
NSI
and
I
Forge
dot.
For
instance,
I
mean
there's
just
some
simplicity,
that
is
there
and,
if,
echoing
what
Ben
said,
if
we
really
could
make
that
similar
to
what
we
have
in
the
regular
recursive
to
authoritative,
it
would
be
probably
better
make
the
same
print.
Okay,.
L
M
L
B
A
Sort
of
you
know
so
so
Brian
and
I
are
gonna,
sit
down
and
talk
with
Ben
and
David
as
well
as
about
this
and
see
where
this
goes
sort
of
thing,
but
if
so
that
conversation
probably
should
end
up
start
moving
over
to
deprive
out
of
the
deal
it's
just
a
sort
of,
so
we
have
a
better
way
of
tracking
some
of
that.
That's
good!
Thank
you.
Okay,
great
thanks.
N
All
right,
hello,
everyone,
my
name,
is
Chris
Wood
and
I'm.
Gonna
talk
about
the
specifically
the
oblivious
part
of
this
proposal,
so
thank
you,
Tommy
for
sort
of
giving
the
big
architectural
overview.
This
is
going
to
specifically
focus
on
how
we
want
a
proxy
of
livius
queries
in
the
case
where
we
don't
trust
our
particular
resolver
to
do
resolution
for
us
so
Libya
snow.
Much
like
oblivious
DNS
is
designed
to
support
proxy
inquiries
between
clients
and
an
untrusted
resolver
pretty
simple
and
concept.
N
We
have
a
couple
assumptions
we're
making
about
actually
running
this
in
practice,
in
particular,
there's
that
the
clients,
in
order
to
run
an
oblivious,
don't
need
to
know
the
public
key
of
what
we
call
a
target
resolver,
which
will
eventually
we
actually
do
the
resolution
of
the
name
that
the
clients
are
after
and
needs
to
know
the
public
encryption
key
of
that
particular
resolver.
It
also
needs
to
know
the
address
of
a
willing
proxy
willing
is
very
important
here.
N
As
far
as
assumptions
about
what
we're
making
about
this
overall
system
minimally,
we
require
that
the
targets
and
the
proxies
are
not
colluding.
Otherwise,
the
whatever
you
would
get
from
keeping
these
two
entities,
disjoint,
is
completely.
It
completely
falls
apart,
and
the
goal
much
like,
oblivious
DNS,
which
I
assume
must
be
here
are
familiar
with,
is
to
make
sure
that
an
entity
which
gets
the
actual
name
to
be
resolved
doesn't
learn
the
IP
address
of
the
entity
which
issued
the
query.
N
You
know
modulo
traffic
analysis
and
things
like
that,
so
we're
focusing
strictly
on
like
what
we
can
do
best
with
cryptography
traffic
analysis
is
certainly
important
and
something
we
will
kind
of
keep
under
advisement,
but
you
know
DVD,
future
work,
etc,
etc.
So
to
actually
look
at
what
an
oblivious
doe
message
looks
like
it's
very
similar
to
a
doe
message
right
now,
except
that
the
body
instead
of
containing,
potentially
you
know
a
plaintext
doe
message
or
whatever
our
DNS
message.
It
just
has
an
encryption
of
an
envelope.
N
Livius
DNS
query
the
contents
of
which
I
will
describe
in
a
little
bit.
The
path
for
the
DOE
message
indicates
the
target
to
which
the
message
should
be
sent.
So
in
this
particular
example,
we
have
the
client
sending
an
oblivious
query
to
the
target
example
net
target
with
a
specific
euro
path,
indicating
the
content
type,
that
this
is
an
oblivious
DNS
message
with
some
other
headers
another
HTTP
group
to
make
it
all
work.
N
So
this
is
the
scenario
we
have
client
wants
to
resolve
a
particular
name
through
nutbar
in
this
particular
case,
using
the
target
DOE
server
target
example
net
and
the
client
has
learned
the
public
encryption
key
via
one
of
the
mechanisms
described
in
the
update
of
Jean
s
draft
or
via
carrier
pigeon
or
by
some
provisioning
mechanism.
You
know
that's
sort
of
out
of
the
scope
of
this
particular
document,
so
he
does
is
quite
simple.
Much
like
in
the
oblivious
DNS
case.
N
He
basically
takes
that
name
encrypts
it
alongside
a
randomly
generated,
symmetric
key,
which
is
K
in
this
particular
case
packages
that,
up,
as
the
you
know,
in
the
oblivious
DNS
message,
sends
it
to
the
proxy
indicating
the
target
target
example.com,
who
will
happily
forward
the
message
over
to
target
example.com
using.
You
know
that
the
the
target
name
that
was
identified
in
the
message
target,
then
naturally
decrypt
using
its
public
key
to
you
know,
discover
the
name
that
the
client
wishes
to
resolve.
N
N
And
so
the
idea,
much
like
oblivious
DNS,
is
that
by
having
this
proxy
effectively
in
between
the
client
and
the
target,
the
separation
there
is
a
separation
between
you
know
the
entity
which
knows
the
name,
which
is
the
target
in
this
particular
case,
and
the
entities
which
know
the
IP
address
of
the
client,
of
course
like
if
they
are
colluding
the
proxy
in
the
target
proxy
could
say,
oh
by
the
way,
here's
the
IP
address
of
the
target.
So
that's
not
great.
So
that's
an
assumption.
N
We
sort
of
make
in
the
system
and
I'll
get
to
that
in
just
a
little
bit
later.
I'd
also
like
to
point
out
that
the
threat
model
that
we're
sort
of
considering
here
is
an
adversary
which
would
potentially
sit
in
multiple
places,
the
network,
in
particular
between
the
client
and
the
proxy,
as
well
as
between
the
proxy
and
the
target,
which
is
why
these
connections
are
encrypted
by
TLS.
N
It's
if
you
were
not
concerned,
for
example,
about
an
adversary
sitting
between
the
proxy
and
the
target,
it
might
not
be
necessary
to
use
TLS
at
all
anywhere.
The
message
is
already
encrypted.
You
could
just
have
something
like
a
simple
TCP
proxy
for
any
messages
on
behalf
of
the
client,
but
because
we're
trying
to
assume
sort
of
a
worst
case
scenario
we
put
TLS
everywhere
and
it's
sort
of
just
good
hygiene
to
use
to
get
less
everywhere.
N
So
I
also
know
that
the
adversary
could
be
sitting
to
the
right
of
the
target
as
well
between
the
target
and
the
upstream
authoritative
I
didn't
draw
that
here,
but
that's
sort
of
included
in
the
threat
model
right.
So
there
are,
of
course,
some
oblivion
concerns
that
one
might
have
in
considering
whether
or
not
to
deploy
oblivious,
though
first
one
you
know,
is
the
public
key
encryption
overhead
of
processing
for
each
individual
query
too
much.
N
It
seems
not,
of
course
you
know,
says
the
client,
but
considering
that
you
know
we're
going
towards
a
world
in
which
we
have
ES
and
I
and
I
guess
I'll
assign
eyes
the
motivating
factor
here.
Every
single
new
TLS
connection,
most
likely
will
require
at
least
two
public
key
operations
to
even
get
things
going,
so
it
doesn't
seem
like
much
more
of
a
stretch
to
do
another
public
key
decryption,
again
caveat
I.
Am
the
client
you're,
not
speaking
after
the
server.
So
if
the
server's
are,
you
know
think
this
is
terrible.
N
Please
tell
us
if
initially
we
could
reuse
connections
or
do
something
like
that,
but
to
make
sure
that
each
query
was
not
linkable.
We
use
public
key
encryption
for
each
individual
query
so
that
there's
no
like
state
across
consecutive
queries
from
clients.
A
second
big
one
is
what
motivates
an
entity
to
proxy
traffic
so
currently
in
the
draft.
N
N
Another
question
is:
how
do
we
know
for
sure
that
the
client,
how
does
the
client
know
for
sure
that
the
target
and
the
proxy
are
not
the
same
entity?
Of
course
I
was
saying
earlier.
Sort
of
you
know
makes
everything
kind
of
fall
apart
and
I
think
at
the
end
of
the
day,
there's
really
nothing
technically
mechanically.
That
clients
can
do
to
sort
of
you
know
get
that
assurance.
N
You
can
tweak
with
and
play
with
the
resolution
algorithms
and
how
you
choose
your
proxies
and
your
targets
to
sort
of
try
to
improve
or
decrease
the
chance
that
they
are
the
same
entity.
You
might,
for
example,
choose
like
a
proxy,
that's
very
close
to
you
in
a
target,
that's
very
far
away
for
some
definition
of
far
and
some
definition
of
distance,
and
maybe
that
has
a
good
chance
of
then
not
being
the
same
entity,
but
really
the
clients,
don't
really
have
any
visibility.
N
The
last
question
is
why
you
doe
like
why
use
doe
is
the
transport
as
a
proxy
and
I
just
want
to
go
back
to
the
earlier
slide
this
one
about
the
threat
model,
because
we're
assuming
that
the
adversary
can
say
to
multiple
vantage
points
in
the
network.
We
want
to
encrypt
that
connection,
because
this
oblivious
doe
just
makes
sense
to
use
doe
which,
as
HBS,
which
has
TLS
now
like
I,
said
earlier.
If
you
are
assuming
sort
of
a
you.
C
N
Weaker
adversary,
one
that's
not
proliferate
throughout
the
network.
Perhaps
it's
simple
TCP
proxy
might
suffice,
but
for
now
we're
sort
of
assuming
the
worst
case
and
we're
going
we're
using
doe.
There
are
possible
with
different
directions.
You
could
take
this,
for
example,
if
you
wanted
to
build
tor,
perhaps
I
should
have
said
that.
But
if
you
wanted
to
do
something
like
tor
in
which,
instead
of
having
just
a
proxy
that
forwards
an
encryption
along
from
the
client.
N
So,
instead
of
having
a
proxy
that
yeah
just
forwards
a
message
and
having-
and
you
wanted
one
that
decrypt
actively
decrypt
something
from
the
client
discovers
something
else
that
could
potentially
be
you
know
another
encrypted
message
itself
or
something
to
resolve
and
send
it.
You
know
you,
you
could,
in
theory
build
that
into
the
protocol,
but
it's
not
clear
right
now
that
that's
the
direction
we
want
to
go
in
I
guess
another
concern-
or
you
know,
observation
that
has
been
raised-
is
that
this
is
a
bit
too
specific
to
doe
itself.
N
You
might
want
to
generalize
it
to
say
just
you
know,
HTTP
messages
and
make
go
I
specific
DNS,
a
specific
type
of
HB
message
that
you
might
send
and
might
be
proxy
from
a
client
to
a
particular
target.
So
what
would
that
variants?
Look
like
oblivious,
HTTP!
Well,
quite
simple!
You
would
just
instead
of
having
an
encrypted
DNS
message
or
inside
the
client
request.
You
would
have
an
encrypted
HTTP
message
and
you
would
have
the
content
type
indicate
that
this
is
in
particular.
This
is
an
oblivious
message
and
the
proxy
would
forward
it
as
such.
N
I'm
not
advocating
for
right
now,
that's
absolutely
the
direction
we
should
go
in
there.
You
know
potential
questions
to
be
asked
about
whether
or
not
this
opens
up
or
turns
the
DOE
specific
target
into
like
an
oak
dos
Pacific
proxy
into
an
open
proxy,
but
I
think
those
are
things
we
can
sort
of
work
through
and
it'd
be
nice.
If
this
this
general
mechanism
was,
you
know,
potentially
used
outside
of
DOE.
So
as
Tommy
mentioned
earlier,
we
have
a
couple
places
where
you
can
get
more
information
about
this
particular
work.
N
O
Paul
Hoffman:
this
is
the
third
oblivious
food
thing,
I've
seen
always
the
first
one
was
oblivious
DNS
in
general,
yeah
so
and
I
forget
what
the
middle
one
will.
O
Yeah
so
I
think
you
should
do
this
as
oblivious
HTTP
and
I
think
you
should
not
do
it
here.
It
is
actually
not
appropriate
for
deprive
I
could
totally
see
a
working
group
getting
spun
up
with
other
things
like
that,
but
this
is
this
has
so
little
to
do
with
DNS
and
so
much
to
do
with
oblivious,
take
it
somewhere
else,
but
it's
certainly.
Then
we
would
have
that
here
both
for
Stubbs
recursive
and
such
like
that
yeah.
N
Thank
you
that
that
makes
perfect
sense
a
it's
here
because
it
has
dough
in
the
name
right
now.
But
yes,
if
we
happen
to
go
down
the
oblivious
HB
message
route,
perhaps
we
date
somewhere
else,
lovely.
K
Back
I'm,
a
bit
scared
by
the
sort
of
network
of
open
proxies
that
we
are
generating
I
mean
DNS
still
has
a
imbalance
when
it
comes
to
the
Curia
and
response
and
I
can
easily
see
how
you
could
abuse
that
to
kind
of
kill
a
doe
server.
A
designate
doe
server
by
just
kind
of
blasting
episode
amounts
graphic
it
from
a
kind
of
a
small
to
medium
botnet,
I'm.
N
N
P
P
N
P
G
H
If
you
standardize
I
need
it
so
technically
it
might
be
nice
to
standardize
to
expand
this
to
be
a
more
generic
thing,
but
then
you
might
not
get
the
relays
offering
service
and
you
might
not
get
the
sacrum
engine
you
need.
H
So
it
might
actually
be
a
better
to
think
about
this
as
a
purely
DNS
or
e2
thing,
because
maybe
in
that
case
you
don't
need
the
agility
that
you
need
for
kind
of
more
full
circumvention,
and
perhaps
people
would
be
willing
to
offer
relays.
So
I
don't
know
well
either.
I
think
is
a
good
thing
to
do,
or
maybe
both
yeah.
N
Thank
you,
I.
That's
a
very
good
point.
I
will
note
that
in
if
we
don't
do
any
generalization
right
now,
if
you
have
a
colluding,
client
and
target,
you
can
still
use
the
posse
to
like
send
things
that
are
not
not
tudo
messages.
You
could
say
like.
Oh
this,
this
looks
like
an
oblivious
tone
message
and
the
proxy
will
happily
move
it,
but
actually
it's
you.
C
A
R
We
go
ahead,
so
Mike
Bishop
couple
observations,
one
being
that
if
your
proxy
is
far
from
the
client,
then
you
will
get
poor
CDN
mapping.
So
your
results
may
not
be
as
good.
Also
some
observations
from
the
structure
of
tor
tor
uses
a
consistent
first
node
over
a
long
period
of
time
because
it
under
the
theory
that
it
is
better
for
a
small
fraction
of
clients
using
that
new
to
be
compromised
all
the
time,
then
for
all
clients
to
be
to
be
surveilled
a
certain
percentage
of
the
time.
N
R
I
Forensic
evading
just
please
bear
in
mind
latency
as
well,
I
think,
for
example,
the
fact
that
you,
you
know
that
it
uses
post
means
you
can't
do
0,
TT
reconnect,
and
so
you
know
the
DNS
does
need
to
be
latency.
Sensitive.
Also
bear
in
mind
that
you
know
DNS
is
extremely
lightweight
at
the
moment
and
and
instead
of
a
full
TLS
handshake
can
be
for
quick,
couldn't
be
like
you
know,
10
K,
so
we
sort
of
try
to
keep
that
cheap
as
well.
Yeah.
N
E
X
and
Caretti
have
you
thought
about,
or
looked
at
a
three-way
party
encryption
for
at
least
part
of
it?
So
you
don't
have
to
rely
on
the
trust
between
the
proxy
and
the
target.
I'm,
not
sure
what
you
mean
by
three-way
party.
It's
one
of
the
diffie-hellman
things
you
can
do
with
three
parties
to
set
a
to
my
group
diffie-hellman.
P
Yeah
the
agenda
is
to
go
the
problem
statement
and
the
solution
view
and
the
privacy
policy
of
the
DNS
server
it's
rejected
by
token
and
then
the
examples
of
some
privacy
assertion
tokens.
Why
do
you
need
Tina,
so
privacy
policy
right?
What
are
the
user
needs?
Basically,
one
of
the
one
is
that,
even
with
today,
the
user
does
not
know
what
the
DNS
servers
privacy
policy
is.
P
He
has
to
go
and
search
and
find
out
what
the
DNS
of
a
privacy
policy
he
is
and
the
other
bigger
problem
is
what
happens
if
the
DNS
server
privacy
policy
changes.
The
user
would
not
even
be
aware
that
the
DNS
server
privacy
policy
has
changed,
and
the
third
one
is:
how
do
we
know
that?
What
the
DNS
server
is
saying
is
actually
the
true
statement
of
the
DNS
server
privacy
policy
right
and
fourth,
one
is
because
many
of
the
networks
doo-deen
is
filtering.
P
The
solution
is
in
is
basically
to
let
the
user
know
what
is
the
the
URL
of
the
readability
in
a
server
privacy
policy,
so
that
user
can
go
all
right.
The
second
part
of
it
is
to
provide
a
machine
possible
dinosaur
privacy
policy
that
allows
a
DNS
server,
that
the
client
can
pick
which
complies
with
the
DNS
clients,
privacy
policy.
P
The
other
advantages
of
this
mechanism
would
be
that
the
client
would
notice
any
updates
to
the
privacy
policy
changes
and
the
user
would
be
notified
if
the
privacy
policy
claims
of
the
DNS
server
changes.
And,
finally,
the
client
can
select
a
Lina
server
that
meets
the
privacy,
preserving
data
policy
requirements
of
the
client.
P
How
do
we
the
solution
proposal?
Is
we
have
DNS
of
a
privacy
policy?
It's
in
Jason,
it
would
be
signed
by
the
domain
operating
the
DNS
server.
It
has
to
be
signed
by
the
domain
operating
the
DNS
server,
because
the
DNS
transaction
data
could
be
used
by
various
entities
within
the
organization
for
analytics
for
DNS,
filtering
anomaly,
detection
and
other
purposes.
Typically,
many
of
the
DNS
servers
would
be
subjected
auditing
by
a
third
party
for
security
and
privacy.
So
an
auditing
company
can
also
optionally
sign
the
privacy
policy
statement.
P
This
would
at
least
prevent
malware's
from
hosting
and
getting
a
domain
and
getting
a
certificate
for
that
come
in
and,
and
the
last
part
of
it
would
be
to
determine
what
kind
of
DNS
filtering
would
be
done,
whether
the
DNS
server
is
doing
malware
blocking
or
has
some
policy
which
could
be
censorship
or
some
blacklisting
organizational
a
twisting
rule.
It
has
to
basically
block
certain
domains.
P
This
is
a
huge
list
of
attributes
that
we
have
listed
in
the
draft.
I
mean
I'll
go
through
some
of
them,
whether
the
IP
address
is
PA
or
not,
logging
of
transaction
data
and
it's
corresponding
duration,
whether
the
user
identity
is
logged
and
the
duration
for
that
and
type
of
DNS
filtering
malware
or
or
any
specific
policy
for
blocking
that.
P
Many
of
the
DNS
providers
today
share
the
transaction
data
with
partners
and
the
name
of
the
partners
and
whether
anonymous
data
or
pseudo
anonymous
data
is
shared
with
partners
and
if
any
data
is
transferred
to
third
parties
and
typically
DNS
servers
which
do
filtering
a
log.
The
DNS
data,
which
is
being
blocked
for
notifying
users
and
any
logging
for
analytics
like
anomaly
detection
and
whether
it
does
queue
name
minimization
and
a
human,
readable,
URL
privacy,
URL
and
an
audit
URL.
P
So
what
are
we
doing
to
get
the
privacy
session
token'?
This
is
very
similar
to
the
work
happening
in
several
working
groups
like
we're
at
straight
out
of
the
working
groups,
while
using
pact
which
is
chasing
the
token
and
Jason
web
signatures,
client
retrieves,
the
privacy
session
token,
using
one
of
the
methods
being
discussed
in
the
DNS
of
working
group.
The
object
has
to
be
created
by
the
domain
hosting
the
do.
Tt,
webserver
and
optionally
can
also
be
attested
by
the
third
party,
which
has
done
a
privacy
and
security
audit
of
the
devotee
works
over.
P
So
this
is
just
a
simple
example
of
a
pad
object.
You
have
an
authentication
domain
name,
the
time
it
was
issued,
the
expiry
time
and
the
privacy
information
blob,
which
includes
all
the
privacy
details
for
the
client
and
the
machine
to
parse,
and
this
would
have
the
JW's
protected
header,
which
would
point
to
the
signature
algorithm
and
the
certificate
public
key
to
use
for
finding
the
payload.
And,
as
you
see
in
this
example,
we
have
this
payload,
both
protected
by
C
assigned
by
the
operator
who
is
operating.
S
Yeah
I'll
make
it
Richard.
I
said
it's
also
on
a
list
already.
I
think
this.
This
seems
like
a
sort
of
reinvention
of
like
Evie
certificates
for
DNS
servers,
there's
a
lot
of
policy
from
from
companies
and
auditors
that
are
not
technical,
so
specifying
all
of
these
technical
things
in
in
the
pretense
that
Deena's
clients
can
use
that
policy,
even
though
they
can
verify
most
of
the
policy
seems
a
good
way
to
me.
T
Mark
Nottingham
member
of
the
now
along
defunct
p3p
working
group
I,
would
very
much
encourage
you
to
explore
deeply
why
that
effort
failed
so
badly,
because
this
seems
to
have
many
of
the
same
problems
beyond
that.
I,
don't
know
that
you
know
requiring
a
new
kind
of
consent
to
use
the
internet
and
for
users
to
understand
a
new
kind
of
consent
model
is
the
right
thing
to
do.
We
already
have
a
consent
problem
on
the
internet.
J
So
I
think
there
are
several
different
layers
here
where
or
we
we
start
with
this
idea
of
getting
some
blob
of
potentially
essentially
opaque
information
from
the
DNS
server,
a
self
description
of
some
kind
and
then
potentially
that
that
can
be
machine,
readable
and
then
potentially
that
can
have
signatures
layered.
On
top
of
it,
so
I
think
that
I
am
I'm
supportive
of
the
idea
of
being
able
to
get
and
essentially
opaque
human
readable,
set
of
of
information
about
a
DNS
server.
J
I
think
that
could
be
could
be
very
useful
and
essentially
usable
I
think
that
the
idea
of
stating
it
as
a
privacy
policy
already
dips
our
tone
into
policy
areas
that
are
not
really,
in
my
view,
not
really
our
domain
I.
Don't
think
that
that
we
are
well
equipped
to
specify
that
Deanna
to
even
distinguish
between
things
that
are
and
are
not
privacy
policies.
J
I
think
that
the
reason
for
that
from
my
perspective
is
that
lawyers
are
very
particular
about
the
precise
words
that
they
use
in
legally
binding
text
and
trying
to
reduce
that
that
legal
language
which
uses
the
the
full
scope
of
human
expression
to
a
machine,
readable
format,
I
think,
is
yeah
in
my
experience,
not
something
that
lawyers
would
be
be
willing
to
do
for
it.
For
example,
you
one
of
the
things
that
comes
to
mind
is
you
mentioned
retention
lifetimes
here.
J
Most
policy
is
describing
a
retention
lifetime
have
various
kinds
of
exceptions,
explicit
or
implicit
for
for
different
investigating
attacks
on
the
system
for
sometimes
different
kinds
of
law
enforcement
requests
may
be
some
kinds,
but
not
other
kinds.
I,
don't
think
this
can
be
reduced
to
a
fixed
schema,
so
I
think
that
the
the
thing
that
I
think
is
great
here
is
I
would
love
to
be
able
to
get,
for
example,
a
URL
from
a
DNS
server.
That
says
this
is
a
web
page.
You
can
go
to
to
get
more
information
about
this
server.
P
You're
not
avoiding
the
human
readable
created
by
lawyers,
we
still
provide
that,
but
I
understand
the
concerns
that
you're
raising
with
the
machine
parts,
but
at
least
one
that
was
interesting
was
the
teen
is
filtering
one.
For
example,
like
today,
Mozilla
uses
can
be
dopamine's
to
block,
so
that
would
at
least
be
coming
as
part
of
a
secure
communication
shuttle.
L
As
a
user
life
would
find
this
useful
and
I
think
I
would
like
to
have
both
so
the
URL
pointer
to
properly
know
your
written
statement
and
as
much
as
possible
a
few
data
which
can
be
machine
consumed
and
presented
by
my
client
in
a
useful
way.
But
then
it
depends
on
clients
whether
they
want
to
implement
this
I
think
this
will
have
to
merge
with
any
work.
We're
gonna
do
on
server
discovery,
so.
L
P
P
L
L
P
J
Eric
rajala,
so
I
guess
I'm
a
little
understanding
how
this
has
this
works
in
practice.
So
let
me
just
write
to
work
through
an
example.
So
I
join
a
network
and
I
get
some
DHCP
exercise
meant.
That
says
here
is
the
server
we
assume
you
have
to
do
a
server
for
now
or
a
doubt
server
already,
assuming
it's
any
kind
of
server
book.
J
A
it's
a
creates,
a
secure,
server,
yeah
and
so
I
I
connect
that
server
and
I
I
I
connect
over
TLS
and
I
I.
Guess
we
assumes
got
a
web
peek.
Yes,
sir
and
I
checked
about
peek.
Yes,
sir
yeah
that's
got
some
new
mania
and
then
I
fetched
this
object
over
that
or
that
okay
and
this
Arjun
self
is
signed
and
I
assume
a
little
unclear
in
the
draft,
but
that
adn
is
supposed
to
be.
J
Q
P
J
P
Q
U
V
J
Well,
I
was
trying
to
reverse
that
point.
I
trying
to
view
at
that
point,
which
is
that
the
nature
of
the
word
PGI
is
mechanical
comparisons
between
names
that
the
user
already
has,
which
is
a
domain
names
and
things
that
and
then
things
arts.
It
is
not
examination
of
the
names
in
the
search
by
humans
to
see
if
they
are
cool
and
if
and
this
system
does
not
have
that
property.
This
is
of
the
property
I'm.
Somehow
examining
the
search
and
like
look
at
the
organization
name
or
look
at
our
god
forbid.
J
Look
at
the
domain
name
and
be
like
is
like
you,
a
Airlines
internet.com,
something
I
like
that
is
not
going
to
work
and
is
the
reason
why
browsers
of
compar
are
increasingly
abandoning
the
display
the
certificates
of
users,
so
until
so
like
for
the
seats
are
like
doubling
down.
A
marks
point
like
like
this
is
not
gonna
work
for
security
reasons,
because
your
face
is
like
unacceptable
to
like
it
for
any
actual
progress
and
Eve.
You
will
not
solve
that
problem.
W
Elisa
Cooper
just
coming
back
to
the
machine,
readable
policies,
but
so,
in
addition
to
the
example
of
p3p,
this
is
actually
a
technique
that
has
been
tried
in
a
multiplicity
of
different
venues
and
different
ways
and
has
failed
like
basically
every
time
we
even
have
an
example
from
the
ITF
itself.
We
tried
to
do
this
for
a
location
privacy.
It
was
a
working
group
called
geo
proof.
We
specified
the
policies
in
a
machine-readable
format
and
nobody
was
interested
in
using
them
in
any
way,
shape
or
form.
W
So
I
think
you
would
have
to
think
about
why
this
is
different
in
some
way
from
all
those
other
examples-
and
it's
not
really
obvious
to
me-
I-
understand
that
that's
fairly
unsatisfactory,
given
I
mean
if
you
believe
what
ekor
said
that,
like
neither
a
machine
readable
way
of
negotiating
this,
nor
a
way
in
which
the
human
being
is
involved
actually
gets
you
very
far,
but
I
think
that's
just
unfortunately,
kind
of
the
state
of
privacy
on
the
web.
Okay,.
D
C
D
D
Pretty
impressive
yeah,
so
we
had
an
interim
meeting
where
we
discussed
that
that
that
document-
and
we
identified
during
the
creation
of
the
of
the
of
this
word
diversion
for
this
meeting-
that
we
have
a
couple
of
specific
areas
of
feedback
and
working
group
discussion
that
we
would
need
to
address
and
we've
put
them
on
the
slides
here.
So
the
idea
of
the
document,
if
I
get
it
right,
two
chairs
you
disagree
is
that
we
are.
D
We
are
not
going
to
publish
that
so
so
we
it's
gonna,
stick
around
in
the
working
group
as
a
working
group
item
eventually
for
a
while,
but
it's
not
gonna
get
another
scene
a
stick
on
top
of
it
yeah,
so
yeah,
so
so
I
mean
the
basic
structure
of
the
document
we
have.
We
have.
We
have
a
section
that
that
identifiers,
like.
D
This
red
model
got
it
and
and
in
a
subsequent
section
we
have
those
perspective
as
we
called
it
search
for
each
of
the
of
the
different
entities
interested
in
like
operating
or
or
using
encryption
between
request
of
an
authoritative.
We
have
different
perspectives
and
there's
a
lot
of
use
cases
in
there,
that's
quite
an
extensive
section
and
in
in
the
subsequent
section
we
have
the
actual
requirement.
D
D
We
have
all
the
open
question
is
one
issue
we
might
want
to
split
that
out
at
some
point,
if
there's
more
discussion
about
it,
so
the
idea
is
that
as
soon
as
we
have
no
open
issues
in
a
github
account
anymore,
we
are
done,
and
that
means
that
as
soon
as
we
close,
all
of
them
successfully
not
ready
to
eat
them.
So
the
first
thing
that
we
have
that
probably
pre-game
important
this
is
anything
missing
from
the
actual
stret
model
and
problem
statement.
So
we
can.
D
J
Then
I
don't
know
if
you're
missing
it
I
read
this
start
model
as
required,
so
we
had
a
long
discussion
list
of
a
threat
model
right
and
in
particular
about
whether
it
was
intended
to
prevent
you
know,
downgrades
effect
weather.
Is
that
downgrades
all
the
way
through
the
system
right-
and
this
seems
to
encode
I-
guess
my
view,
which
is
that
the
system
should
print
down
grades
and
the
referential
integrity?
J
Although-
and
so,
if
you
start
from
the
top-
and
you
like-
and
you
have
you
know
dot
to
the
top,
then
you
should
be
able
to
like
they
do
have
referential
integrity
all
the
way,
but
I
heard
a
lot
of
people
saying
we
shouldn't
do
that.
We
should
necessarily
do
that.
So
I
think
that
probably
is
the
topic
we
should.
We
should
not
just
pass
over
in
silence,
but
rather
have
discussion
of.
G
Peter
Sawchuk
from
the
Java
room.
Maybe
we
should
explicitly
state
that
attacker
who
has
access
to
all
traffic's
out
of
scope
again,
in
that
case,
traffic
analysis
will
give
that
almost
all
the
data,
even
without
decrypting
DNS
traffic
ekor,
says
he
doesn't
agree
with
it
at
all
and
since
I'm
at
the
mic,
I'll
say
I,
also
don't,
but
as
jabber
relay
that's
what
eater
said.
J
So
I'm
not
up
to
date
on
the
threat
model,
I
mean
read
in
a
while,
but
one
thing
that
was
mentioned
I
think
by
a
Christian
winema
that
that
I
think
is
valuable.
Is
we
should
we
should
think
carefully
about
any
interaction
here
with
CAA
Acme
and
domain
validated
certificates?
That
is
if
there
is
any
dependency
here
on
the
web
PKI,
we
have
to
make
sure
that
we
haven't
created
a
circular
dependency.
That
is
actually
a
owner
ability,
yeah.
D
D
The
next,
the
next
issue
that
we
we
discussed
internally
was
is:
do
we
to
be
actually
imply
that
do
T
is
always
used
between
recursos
and
authoritative
servers
or
are
there
situations
where
some
other
type
of
privacy
enhancing
mechanism,
privacy,
protective
mechanism,
you
name
minimization,
whatever
is
good
enough.
So
it's
a
different
story.
Whether
we
require
we
require
do
t,
so
the
first
requirement
is
use.
Do
t
alter
all
of
the
time
yeah
or
not?
Yeah.
That's
that's!
That's
not
an
important
issue.
I
guess
then,.
J
Short
I
don't
understand
the
question
you're
asking,
but
we
never
had
the
ability
to
tell
people.
You
know
we
were
not
the
protocol
police.
We
can't
force
people
to
do
anything
so
we
can
define
this
protocol,
but
we
can't
make
people
implement
it.
So
what
does
it
mean
for
for
the
protocol
to
be
defined
but
not
always
required?
I,
don't
understand.
Let
me
put.
D
U
Just
to
chime
in
I
think
we
noticed
that
there
were
some
people
in
the
list
that
suggested
that
DoD
would
be
appropriate,
say
from
a
single
level
domain
between
a
recursive
server
and
a
single
domain,
but
maybe
up
to
the
root
like
maybe
some
of
them
or
some
TL
DS
didn't
want
to
do
dot
in
some
scenarios
and
there
would
be
other
mechanisms
that
you
could
use.
So
you
could
conceive
that
the
protocol
might
have
different
sort
of
you
know:
selection
criteria,
for
which
pop
of
recursion,
you
were
doing.
J
I
think,
though,
so
I
think
we
should
be
in
the
business
of
defining
this
protocol
and
describing
the
properties
that
it
that
it
has,
and
you
know
we
can,
we
can
certainly
compare
it
to
other
protocols
and
properties
that
they
have.
Maybe
there
are
cases
where
there's
equally
good
alternatives.
So
short
answer
is
yes,
dot
is
always
required
right,
no
I,
think
dot
is
always
required
if
you're
doing
dot
and
whether
you're
doing
dot
is
not
something
that
we
can
tell
you.
Okay,.
U
J
So,
let's
like
like
hypothesize
that
there
is
some
way
in
there's
some
way
in
in
or
in
unspecified
now,
but
in
order
to
discover
that
a
delegation
or
the
next
a
thought
to
be
like
it
supports
secure
transport
right,
so
I
think
you'd
want
to
say
what
you
say
would
be
here
is
like
how
you
indicate
that
like
this
is
that
this
and
that
this
is
ns,
the
reference
support,
secure
transport,
and
this
is
what
how
it
tells
you,
what
kind
of
secure
transport
it
supports,
and
this
is
what
you
want
to
do
when
you
get
that
if
you're
like
you're
like
a
compliant
dude
and
I,
apply
resolver
and
you
know,
and
then
some
separately
I
suppose
we
could
say,
and
you
and
we
encourage,
you-
know
Allah
hosts
requirements.
J
We
encourages
all
of
us
to
do
this
kind
of
thing
right,
but
I
I,
guess
I
agree
with
Ben
on
that
it,
like
that's
kind
of
like
the
limits
of
our
thing.
I
guess
it
seems
like
you
might
want
to
have
an
equivalence
class
of
what
what
secure
transports
means.
J
So
I
guess
you
know
I
don't
want
to
get
into
do
over
to
stop,
but
certainly
something
we
may
imagine
that
made
DNS
sever,
quick,
Oh,
hum
and
or
des
already
tell
us,
I
suppose
and
I
think
you
know
you
could
imagine
having
a
variety
of
secure
transport.
You,
you
think,
have
a
cooler,
know,
Cleveland's
class
I.
Think
cumin
is
not
medical
Volans
class,
but
I
think
so
you
surely
wouldn't
want
to
be
like
dot
forever,
like
you
can't
DDS
ever
quick
but
but
I
do
think
like.
D
J
V
West
heard
occur
is
I,
am
pulling
it
up
and
relabeling
sort
of
what
echo
just
said
when
I
read
to
you,
the
document
I
I
would
love
large
portions
of
it.
I
like
the
fact
that
you
broke
down.
You
know
that
there's
different
levels
of
the
DNS
name
and
things
above
the
PSL
is,
you
know,
possibly
need
to
be
dealt
with
in
a
different
way,
especially
when
talking
to
the
route,
if
you're
doing
Communion
minimization
I
thought
that
was
fantastic.
V
The
problem
is,
is
that
a
lot
of
the
text
is
not
talking
about
requirements,
but
rather
solutions
and
I
know
it's
been
mentioned
on
the
list,
but
but
a
function
of
functionally.
Even
this
little
statement
is
really
saying:
is
this
solution
always
required
right,
so
you're,
pre
picking
the
solution
rather
than
saying,
is
encryption
always
required
and
what
are
the
requirements?
You
know
if
encryption
is
required?
What
are
the
requirements
of
bootstrapping
that?
How
do
we
get
the
trust,
anchor
lists
and
things
like
that?
K
D
E
If
it's
signed
versus,
if
it's
not
and
whether
in
order
to
achieve
privacy,
and
if
you
are
using
Dane,
then
you
need
to
have
a
secure
delegation
all
the
way
down
to
the
domain
name,
server
that
you're
gonna
connect
to
over
an
encrypted
transport.
The
other
thing
would
be
potentially
looking
at
what
the
mandatory
to
implement
is
and
whether,
depending
on
that,
that
may
actually
turn
into
requirements
for
what
the
client
supports,
as
opposed
to
what
the
server
has
to
support.
D
J
D
J
U
J
I,
don't
I
don't
agree
with
that.
Characterization
of
the
previous
comment,
I
think
that
what's
needed
there,
you
know
you
mentioned
alternatives,
I
think
what's
needed.
There
is
not
a
recommendation
to
use
or
not
use
encrypted
transports,
but
a
comparison
of
the
properties
of
an
encrypted
transport
versus
Qun,
a
minimization
in
different
scenarios.
So
I
don't
think
that
that's
a
requirement
that
we
need
to
think
about
now.
J
It's
just
it's
just
something
that
we
need
in
the
explanatory
text
at
some
point
in
the
document
to
help
explain
people
what
they're
buying,
if
they're
implementing
to
UT
and
what
their
other
options
might
be
on
this
topic.
I
do
think
it
could
be
useful
to
enumerate
a
few
different
cases
here,
but
I,
don't
think
that
we
can
determine
now,
which
ones
will
be
able
to
solve.
I.
Think
that
we're
going
to
have
to
explore
the
solution
space
to
figure
out.
What's
tractable,
it
wasn't
and
Eirene.
J
This
point,
I
think
I
mean
I,
guess
Barret
ticket
thickens
to
back
right.
There
are
two
effective
settings
right.
That's
right!
Three
one
setting
is
where
you
have
out-of-band
information
about
the
resolve,
your
connection
to
which
is,
of
course,
this
way
shouldn't
with,
like
you
know,
the
the
dot
and
dot
endo
client
or
two
recursive
situations
where,
like
you're,
giving
domain
name,
and
you
just
connect
to
the
thing.
J
The
the
second
second
second
setting
is
one
where,
during
the
during
during
the
resolution
chain,
you
learn
here,
go
somewhere
here
and
you're
supposed
to
connect
that
person
now
and
somewhere
in
there
that's
got
it.
There's
got
to
be
an
if
that's
going
to
be
secure
against
it
gets
active
attack.
J
There
has
to
be
has
to
be
enough
information
that
when
you
talk
to
that
next
guy
you're
able
to
determine
that
the
the
reference
you
were
given
corresponds
to
the
thing
that
you're
connecting
to
and
there's
a
compiled
ways
to
do
that
and,
like
I,
think
some
of
the
more
attractable
others
we
could
like.
We
don't
the
decide
if
I'm
not
here
on
that.
The
key
point
is
a
referential
integrity
and
then,
finally,
there
are
these.
J
There's
there
there's
the
opportunity
of
discovery
where
people
are
like
hey,
I'm,
gonna,
happy,
eyeballs
and
see
if
this
guy's
supports
dot
or
just
like,
go
fifty
three
and
like,
in
that
case,
there's
like
no
really
no
point
in
getting
the
person
in
there
and
because,
like
is,
it
is
what
it
is.
So
so
I
think
those
are
the
three
cases.
It's
it's
really
the
case.
J
It
is
important
that
leads
on
that
needs,
like
some
definition
is,
that
is,
if
we
choose
to
build
something
that
has
referential
I,
go
all
the
way
down,
it
has
to
have
referential
integrity.
At
that
stage,
they're
the
reference
has
to
be
correspond
about.
The
credentials
were
given
to
you
by
the
person.
You're
cracking
up
are
secure
transport.
F
Thank
you
later
Christian.
We
tomorrow,
it's
not
directly
related
to
using
what
you
use
to
secure
the
whatever
secure
connection
you
are
between
the
client
and
the
authoritative.
But
I
am
scared
about
the
circular
dependencies
between
PGI,
Acme
and
DNS
security.
So
it's
easy
to
envisage
a
case
in
which
you
can
only
get
a
certificate
for
some
them.
F
If
you
can
prove
that
you
control
the
wizard
above
about
Nam,
but
then
you
can
only
get
to
the
wizard
off
of
that
name
before,
where
you
have
a
way
to
assess
that
you
are
the
right
with
with
a
certificate
for
that
name.
So
these
this
notion
of
circular
dependencies
should
be
put
in
the
requirements
as
in
this
is
a
single
char,
not
break.
E
Brian
Dixon
GoDaddy,
so
I
think
one
of
the
things
that
might
need
to
be
called
out
is
the
fact
that
this
is
what's
agreed
on
between
the
resolver
and
authoritative
server.
The
authoritative
servers
are
depending
on
how
we
define
these
documents
and
requirements
free
to
use,
if
they're
doing
deign
for
different
models,
which
can
include
non
CA
signed
certificate.
E
It
can
either
be
self
signed
or
signed
by
some
non
CA
parent
search,
which
can
be
protected
through
the
deign
delegation
and
the
deign
validation,
which
means
that
giving
the
the
list
of
what
the
methods
are
and
what
the
security
properties
are.
If
you
do
or
do
not
support,
these
validation
mechanisms
is
I.
Think
critical
to
the
implementers
to
understand,
especially
if
large
Authority
servers
effectively
commit
to
not
doing
anything
other
than
Dean
becomes.
That
becomes
a
critical
aspect
of
it.
Working
as
well.
X
Then,
on
Gilmore,
so
my
head
is
spinning
at
the
thought
that
we
care
at
one
about
avoiding
circular
dependencies
and
two
that
we
might
want
to
do
some
sort
of
hybridized,
Dane,
plus
web
PKI,
plus
a
third
party,
perhaps
not
any,
of
the
above
certification
models.
So
I
think
that
sounds
super
complicated
and
the
idea
that
we're
gonna
get
that
right
that
all
of
the
players
in
the
game
writing
up.
That
right
is
really
scary
to
me.
X
So
in
some
sense,
I
find
myself
and
I
know
we're
not
supposed
to
be
talking
about
solutions
here,
but
I
actually
think
that
we
should
put
in
the
requirements.
That's
something
that
we're
gonna
have
is
going
to
be
simple
enough
to
be
analyzable,
which
I'm
not
convinced
by
by
some
of
the
proposals
that
I've
heard.
Secondly,
I
wanted
to
generally
agree
with
eckers
break
down
the
sort
of
three-part
model
right:
pre,
pre-ordained
knowledge,
hierarchical
delegation
and
happy
eyeballs,
as
sort
of
the
paths
as
you
get
to
these
sorts
of
privacy
things,
but
I
wanted
to.
X
Having
just
said
we
shouldn't
complicate
things,
complicate
things
I,
think
that
there
is
it
spot.
So
a
lot
of
this
one
has
to
do
with
there's
a
temporal
dependency
in
these
things
as
well
right.
A
delegation
that
you
get
is
time
limited
by
a
number
of
different
things:
the
certificates,
if
we're
doing
web
PK
I,
have
limits
the
DNS
records
have
have
TTL
all
these
other
time
limitations
and
I.
X
Wonder
if
the
happy
eyeballs
opportunistic
mechanism
might
also
opportunistically
provide
you
with
something
that's
more
verifiable
than
you
would
have
gotten
from
the
strict
delegation
and
I
wonder
how
that
interacts
with
like
what?
What
are
the
temporal
aspects
of
that.
So,
for
example,
rather
than
getting
an
explicit
delegation,
I
might
get
a
happy
eyeballs
approach
where
hey
well,
we've
got,
you
know:
we've
got
dot
and
somehow
by
having
gotten
dot.
A
J
Why
I
just
thought
was
not
what
I
was
saying
what
I
was
saying
was:
do
not
discuss
themed
person
web
PPI
at
this
moment,
not
I
was
not
saying
say:
don't
do
a
peaky,
I
I
think
I
think
like
I
think
like
there
I
see
different
people
in
the
room,
different
opinions
about
whether
or
not
it's
key
viable
to
have
these
big
web
peaky
I
search,
ordained
sorts
and
I.
Just
don't
think
at
this
point
in
the
game
like
I,
said
a
requirement
as
when
you
engage
with
I.
J
Think
later
may
often
be
a
true
that,
like
so
I,
think
dick
eg
on
you,
we
just
comes
up.
You
were
thinking
basic.
It
sound
like
HSTs
right
we're
like
I
connect,
I
connect
to
the
server,
and
it
goes
like
I
promise.
I
will
be
dot
for
the
next
two
weeks,
right,
yeah,
I've,
never
extremely
valuable
kind
of
idea.
J
D
X
E
Right,
so
we
need
to
move
on
I'm.
Sorry,
I
do
want
to
respond
very
very
quickly.
One
of
the
things
about
any
of
those
other
pin
up
things
is.
It
does
not
honor
things
that
are
in
the
DNS
itself.
If
there
is
a
Dane
thing
with
a
TTL
that
absolutely
has
to
be
honored,
otherwise
it
breaks
a
security
model.
J
It
seems
like
you're,
offering
three
options.
One
is
that
the
client
says
don't
only
ever
use
dot,
yep,
Swiper
or
and
I
don't
see
how
that
works
because,
like
then
like
like,
but
they
II
try
that
on,
like.
J
J
The
the
I
think
that
the
similarly
for
backup
compatibility
reasons
the
most
on
the
on
the
authoritative
domain,
obviously
has
to
advertise
a
way
to
talk
to
talk
to
talk
to
the
next
guy,
the
chain
like
not
via
dot,
because,
like
otherwise
people
who
only
speak,
tout
well,
I
like
people,
everybody
who
currently
in
existence
will
just
choke
right.
So,
like
all
your
so
I
think,
the
only
things
you
can
plausibly
say
are
you
know
here
is
how
to
talk
to
me
via
Dodd,
and
here's
how
to
talk
to
me.
J
If
ya,
like
not
dot
and
and
and
then
you
know,
we
could
talk
about
the
semantics
of
like
how
you're
supposed
to
do
just
behaving,
you
can
send
information
on
the
my
instinct
obviously
would
be
to
has
have
to
say
that,
like
if
you
were
given
both
of
those
and
you're
like
a
modern
person,
then
you
ought
to
take
dot
and
you
what
refuse
to
connect
the
other
one,
but
but
I
mean
they,
because
the
temporalities
was
not
much.
J
Also,
you
can
say
I
think
that
that
I
mean
it
was
really
the
truce
minutes.
You
can
pause
that
we
have
at
this
point,
for
the
to
be
advertised,
are
number
one
like
I
speak
dot,
and
you
really
ought
to
use
it
and
I
promise
to
have
it
on
like
indefinitely.
So
if
it
doesn't
work
like
you
know,
that's
an
attack
or,
conversely,
I
speak,
but
like
I,
don't
like
promise
that
might
not
work
and,
like
maybe
I,
think
you
were
happy
I.
J
Those
are
the
only
sensible
things
you
can
plausibly
say:
I
think
the
second
one
is
not
super
valuable,
but
I
can
understand.
It.
I
think
wouldn't
be
a
tragedy
to
have
liked
both
settings
both
indicators,
but
like
I
say
you
know,
you
have
to
build
advertise
both.
Otherwise
people
are
breaking
okay,.
J
Ben
Schwartz
I
I,
don't
think
it
makes
sense
for
the
stub
resolver
to
provide
any
instruction
about
this
to
the
recursive.
I
would
be
strongly
in
favor
of
removing
any
of
that
from
the
requirements
and
and
instead
saying,
for
example,
that
there
be
no
change
required
or
or
involved
at
all,
in
the
construction
of
queries
formed
by
the
stub,
in
particular.
Where
we're
talking
about
something
here
that
is
completely
unbearable
from
the
stubs
perspective.
J
Stub
has
no
way
to
prove
whether
this
happened
at
all,
in
contrast
to,
for
example,
the
DNS
SEC
okay
bit,
where
at
least
if
things
are
working
right,
you'll
get
an
RR
cig
back.
That
tells
you
that
that
tells
you
that
you
can
use
to
verify
locally,
that
the
recursive
did
what
you
wanted
it
to
do.
Also,
I
think
that
the
bit
we're
talking
about
here
gets
extremely
strange
very
quickly.
For
example,
it's
not
clear
what,
if
you
imagine
that
the
stub
is
allowed
to
say
only
do
do
T.
J
Then
you
have
to
try
to
understand
what
that
means
about
reading
results
out
of
the
resolve
out
of
the
recursive
cash.
You
have
to
think
about
what
that
means
about
whether
the
route
has
implemented
do
T
or
not,
or
whether
a
local
copy
of
the
route
that
was
fetched
over
an
insecure
transport
with
DNS,
SEC
validated,
is
considered
appropriate
I.
Think
it's
a
gigantic
can
of
worms,
and
we
should
exclude
it
cool
thanks.
K
Got
a
favor
I
come
by
with
my
sort
of
resolver
vendor
on
it,
no
I
mean
really
resolving
is
already
complicated
enough.
We
have
to
shout
at
the
cash
for
ECS,
there's
jr.,
minimization,
there's
and
next
domain
I
mean
there's
lots
of
stuff,
that's
going
on
there
and
it's
really
complicated.
If
the
client
wants
to
have
an
assertion,
you
should
do
the
things
themselves.
K
Maybe
the
way
that
yeah
yep
that
the
NSA
was
was
prepared,
but
the
result
really
should
do
it
stuff
and
I
mean
if
you,
if
any
client
would
have
to
say
turn
it
on
now.
That
reminds
me
a
bit
of
the
early
versions
of
the
Microsoft
DNS
server,
where
you,
if
you
turned
on
the
in
a
sec
on
the
domain,
everything
I
don't
need,
has
to
be
validated.
So
it
doesn't
work
at
the
moment
and
it's
really
complicated
so
I
mean
we
should
not
do
have
a
requirement.
Okay,
so
I'm
hearing.
X
Lots
of
Plus
Ones,
don't
do
the
client
side
stuff,
so
yeah,
one
more
plus
one
from
the
page
me
here.
So
this
reminds
me
a
lot
of
the
required
TLS
mechanism
in
SMTP,
which
is
very
difficult
to
figure
out
how
to
deploy
it.
Even
in
a
situation
where
we
had
start
TLS
available
for
a
long
time,
I
want
to
call
out
the
similarities
between
this
project
and
start
TLS
for
the
SMTP
network.
X
I
think
we
did
a
great
job
at
getting
start
to
us
out
there
and
SMTP,
and
we
didn't
do
a
good
job
of
figuring
out
how
to
ratchet
ourselves
into
a
majority
start
TLS
world
until
another
decade.
After
that,
so
I
appreciate
the
attempt
to
think
about
how
we
get
there,
but
we're
not
even
at
the
stage
of
start
TLS
is
deployed
in
this
mechanism
and
I
think
we
need
to
get
there
first,
it's
just
the
curse
of
the
deployed
base
right.
That's
what
we
do
here
at
the
IETF
yep.
V
V
That
makes
for
an
interesting
week,
so
he
thought
long
and
hard
about
how
to
deal
with
situations
where
the
user
is
removed
from
the
decision-making
process
of
starting
up
TLS,
and
so
that
76-72
is
actually
defined
as
an
opportunistic
encryption
role
to
where
you
you,
you
do.
The
best
that
you
can
under
the
guy
is
with
the
information
that
you
have,
and
you
know
you
may
end
up
starting
TLS.
V
Even
when
you
don't
necessarily
know
the
other
side,
if
you
can't,
you
know,
find
the
right
gain
record
to
get
you
all
the
way
there,
but
the
important
part
is
not
actually
the
semantics
of
actually
how
to
make
that
connection,
but
rather
the
fallback
logic
of
he
put
in
a
lot
of
very
good
description
of
you
know.
What's
the
best
you
can
hope
for
and
here's
why
and
here's
the
logic
to
walk
through.
E
Brian
Dixon
GoDaddy
+12,
what
Wes
just
said:
+12,
not
the
client
I
think
from
the
authority
side
there
may
be
some
value
to
guidance
from
the
authority
on
how
to
deal
with
the
happy
eyeballs
requirement
or
just
intent,
such
as
using
some
version
of
serve
stale.
If
the
d-o-t
isn't
reachable,
while,
rather
than
trying
to
go
over
Deal
53
versus
the
information
effectively,
not
having
a
lot
of
privacy
value
and
just
allow
it
to
fall
back
without
trying
to
do
serve.
Stale.
Y
Patman
minutes
with
fastly
I'm,
just
to
sort
of
riff
on
TKG
saying,
maybe
the
requirement
should
be
that
we
deal
with
discovery
an
advertisement
of
non
down
down,
readable
services
right
so
the
way
G
B
solves.
This
is
with
your
ice
cube
I
mean
yes,
does
that
right
in
maybe
the
SMTP
didn't,
so
that
might
be
the
requirement
to
focus
on.
U
All
right,
great,
all
right
so
now
we're
to
requirements
on
discovery.
So
what
requirements
do
we
have
for
a
recursive
to
determine?
Availability
of
you
know
dot
in
this
case
on
an
authoritative
server,
so
I
think
you
know
mostly.
This
is
via
whitelist
today.
So
are
there
any
requirements
that
we
want
to
place
on
this
like
it
has
to
be
in
the
DNS
or
it
should
be.
You
know
completely
automatable,
independently
from
different
entities,
any
requirements
that
we
haven't
thought
of,
or
that
have
come
up
on
the
mailing
list.
E
Brian
excellent
GoDaddy,
at
least
my
opinion.
It
has
to
be
in
the
DNS,
should
be
Dane,
sorry,
DNS
X
signed
and
it
should
be
associated
with
the
name
of
the
name.
Server
rather
than
domain
being
served.
I
think
it
scales
much
better
that
way
and
it
provides
all
the
the
necessary
parts.
As
far
as
delegation
signatures.
V
J
U
We've
gotten
a
lot
of
notes
here,
we'll
compare
as
co-authors
and
look
at
the
notes,
of
course,
from
the
session
and
Java
room
and
make
those
changes-
and
you
know
I,
guess
updated
quite
honestly,
a
couple
weeks
after
the
meeting
to
get
back
and
catch
up
on
other
work
and
then
do
an
update.
So
certainly
before
end
of
year,
I
think
we'll
have
a
next
revision
and
then
the
question
is
like
did
we
just
you
know,
keep
this
document
and
keep
on
yeah.
U
A
Brian
and
I
talked
about
was
just
adopting
it.
Having
you
guys
like
you'll,
do
some
updates
and
we'll
just
adopt
it
as
a
working
group
only
document
we
won't
have
to
go
through
a
lot
of
that
sort
of
process
stuff,
and
then
we
can
just
then
the
group
can
just
start
chewing
on
it
that
way
and
and
making
all
their
suggestions
and
stuff,
yeah
and
I
think
one
that.
U
We
said
at
the
beginning
just
to
be
clear,
so
we
will
be
looking
in
particular.
At
the
perspective
is
and
use
cases
there
are
much
of
requirements
there
that
we
probably
miss
that
we'll
have
to
pull
in
so
we'll
do
a
quick
gap
analysis
the
rest
of
that
will
just
put
into
appendix
so
it
could
be
deletable
later
just
to
make
this
as
simple
as
possible
in
the
main
body.
Yeah.
V
E
Brian
Dixon,
GoDaddy,
I
think
just
from
a
very
high
level
from
building
the
requirements.
I
think
definitely
making
the
distinction
between
things
that
are
for
providing
the
service
on
the
authority
side,
what
what
the
value
propositions
are
and
what
things
should
be
recommended
versus
what
things
should
be
mandatory
to
implement
versus
in
order
to
achieve
the
privacy
on
the
client
side.
If
you
want
to
get
the
privacy,
you
may
need
to
implement
certain
things,
but
it
doesn't
need
to
be
mandatory
because
it's
always
the
choice
of
the
resolver
yeah.
U
H
Steve
Marisa
I
think
this
might
be
more
a
question
for
the
chairs
than
you.
But
so
at
what
point
are
you
encouraging
people
to
sort
of
actually
write
into
a
trash,
saying
here's?
How
I
would
do
the
signalling
here's,
how
I
would
use
a
funny
name
for
an
NS
or
because
I
think
I've
seen
a
bunch
of
discussions
on
the
list
for
people
kind
of
put
in
little
snippets
of
these
ideas
in
mail
and
it
gets
confusing
and
so
I'm
just
wondering
at
what
point
would
you
like
to
see
more
I.
A
Think
fairly
soon,
I
think,
once
we
sort
of
do
an
update
on
this
and
sort
of
get
it
more.
A
little
structured,
Brian
and
I
actually
already
meeting
scheduled
on
Tuesday
to
sort
of
go
through
some
of
this,
but
I
figure.
You
know
once
that
happens,
you
know
I
would
say
like
you,
then
we
can.
Yes,
we
can
start
people
can
start
submitting
stuff
on
on
here's,
how
we
think
about
solving
it
this
way
or
here's
how
we
can
look
at
it.
This
way,
current
thing
great.
H
A
U
E
A
Also,
one
thing
that
came
up
before
Paul
speaks
is
Brian
and
I.
If
we
do
get
a
lot
of
good
feedback,
if
people
start
submitting
drafts,
like
Stephen
says
we
are
we're
totally
open
to
having
another
intern
before
Vancouver
to
sort
of
chew
through
some
of
this
in
a
very
focused
way.
So
just
keep
that
on
I
just.
Y
U
O
I
haven't
gotten
to
the
mic,
because
I've
been
trying
to
take
notes.
A
major
major
thing
that
is
not
covered
in
this
document
is
name.
Sir
zones,
whose
name
servers
are
not
all
controlled
by
one
one
organization.
So
there's
two
issues
here
that
again
is
not
covered
at
all
and
I.
Don't
I
believe
that
we
do
have
requirements
about
it
from
the
DNS
one
is:
are
all
NS
records
considered
equal
and
a
very
simple
case
would
be
a
zone
that
has
two
NS
records,
one
that
offers
dot
and
one
that
does
not
right.
O
U
J
Yeah
that
actually
seems
like
my
paper,
has
for
what
for
client
policy,
but
I
just
wanted
to,
in
reference
to
Patrick's
question
about
the
state
of
this
document.
I'd
like
call
your
attention
to
that
November
2016.
I
HT
statement
on
supporting
documents
for
working
groups,
which
strongly
suggests
the
documents
like
this
do
not
end
up
being
RFC's.
E
A
A
So
if
there's
not
anything
else,
if,
hopefully
everybody
signed
the
blue
sheets,
we're
doing
pretty
good.
Actually,
so
surprisingly,
considering
how
late
everything
sort
of
ran
the
as
I
said,
Brian
and
I
will
talk
to
next
week,
we'll
probably
actually
a
couple
of
these
documents
that
we
talked
about
earlier.
We
want
to
go
back
with
the
other
chairs
on
the
other
groups
and
sort
of
discuss
how
they
sort
of
fit
in
if
they
do
or
not,
focusing
on
our
sort
of
tight
charter.
A
A
Like
I
said,
if
it
looks
like,
we
get
a
lot
of
good
stuff
going
on
with
the
face
to
requite,
especially
with
solution
stuff,
we'll
probably
plan
on
doing
an
interim
in
February
before
the
March
meeting,
so
well-well
chairs
will
take
that
up
and
sort
of
see
what
we
can
do
with
that
all
right
thanks
all
so
where
are
the
blue
sheets?
Oh
cool?
Thank
you.
Daniel.