►
From YouTube: IETF99-DPRIVE-20170718-0930
Description
DPRIVE meeting session at IETF99
2017/07/18 0930
https://datatracker.ietf.org/meeting/99/proceedings/
A
C
All
right
good
morning,
all
I
guess
we'll
slowly
get
started
here.
I've
run
out
of
tea
to
drink,
so
I
guess
the
day
we'll
have
to
begin
for
us,
so
welcome
to
debride
it's
Tuesday
morning,
yeah,
so
I'm
Tim,
that's
not
Warren,
as
you
know,
warrants
and
got
promoted
to
management.
So
we
lost
one.
So
so
Brian
here
made.
C
Actually
a
rant
about
back
in
London
a
few
years
ago,
is
stepping
into
his
shoes
so
treat
him
as
well
as
you
I
guess,
treated
worn
it
myself
Terry
our
ad
is
back
there,
so
complaints,
criticisms
etc.
You
know
where
to
find
the
man
we
we
asked
for
like
an
hour.
We
didn't
think
we'd
have
a
lot
of
stuff,
but
of
course
you
know
they
gave
us
two
and
a
half
hours.
So
you
know
I
guess
we
can
have
stuff
to
go
on
so
we'll
go
through
the
little.
C
The
quick
agenda
sure
give
you
rundown
on.
What's
going
on
things
of
that
nature,
we
need
a
java
scrub.
If
we
can
find
one
I
know,
I
asked
for
one
I
never
heard
anything
back
and
I'm
gonna
take
her.
If
I
can
find
one
mr.
Hoffman,
thank
you
for
taking
minutes,
though,
and
jabbered
dan.
Thank
you
thank
you
for
that.
So
there
another
one.
So
that's
the
new,
no
well
I,
actually
updated.
The
text.
I
didn't
think
I
was
going
to
do
that.
So
you
all
have
to
sort
of
follow
with
you.
C
What
the
new
text
I
actually
didn't,
even
do
a
diff
to
figure
out
what
the
tip
change
was.
So
I
was
just
proud
of
myself
that
I
managed
to
do
updated.
So
hey,
it's
tough
work
fill
in
the
blue
sheets,
so
actually
the
room
filled
up
a
lot
more
than
I
thought.
So
at
least
can
tell
us.
You
know
tell
us
the
Secretariat
how
many,
how
many
microphones
we
need,
though
so
we'll
go
through
the
agenda.
C
We've
got
a
couple
updates
on
something
going
on
some
current
working
group
stuff
and
some
new
stuff,
including
something
that
I
guess
Warren.
Just
can't
quit
us
I
guess
he
just
told
mr.
Laurin
said
he's
got
some
slides.
He
wants
to
send
to
us
to
present,
even
though
he's
not
here.
So
that's
that's
Warren
for
us,
so
see
what
that
goes.
So
the
big
thing
we
wanted
to
talk
about
was
the
TLS
profiles.
Draft,
which
is
NIS
G
review,
got
a
lot
of
feedback
from
the
ICC,
of
course,
they're
really
great.
At
that.
C
What
we
sort
of
pushed
on
the
list
about
was
there
were
a
lot
of
changes,
a
lot
of
editorial
stuff,
but
some
content
stuff,
and
we
wanted
to
make
sure
that
we
saw
working
group
folks,
you
know
sort
of
like
yes,
I've
read
this,
and
this
is
not
crazy.
So
perhaps
a
little
show
of
hands
of
anybody
read
the
latest
version
with
all
the
different
changes.
Okay,
so
a
few
I'd
say
maybe
a
half
dozen
or
so
mm-hmm.
C
That
makes
me
a
little
squeamish
I.
You
know
we
want
to
go
back
and
talk
to
the
roaring
at
the
80s
to
basically
lift
there
discusses,
but
they're
gonna
want
to
see
some
more
folks
in
the
group
that
basically
have
read
it
and
say:
yes,
you
know
this
is
good.
You
know
that.
So
if
you
have
a
change,
look
at
the
dips,
you
know
sort
of
pass
your
eyes
over
it
and
give
us
a
little
bit
of
feedback
on
that.
C
D
Districts
at
things-
and
it's
like
we
want
a
little
bit
of
clarity
here.
You
add
a
sentence
here
or
you
didn't
cover
this
yet
a
paragraph
here
this
was
bigger
than
yes,
it
was,
and
so
please
don't
assume
that
it's
fine
I
read
it.
I
thought
it
was
fine,
but
a
lot
of
people
disagree
with
me
a
lot.
So
it's
worth
the
time
to
read
it
read
the
diffs
and
to
read
the
whole
thing
again,
because
in
fact
it's
different
than
what
we
sent
the
ISG
III
agree
and
I
I
disagree
with.
C
E
I
disagree.
We
spoke
this
time,
but
yeah
is
our
a
lot
of
gems.
If
you
take
into
account
the
number
of
different,
but
most
of
the
change
are,
in
my
opinion,
detailed
most
of
the
iesg
me
markzware,
in
my
opinion,
mostly
a
matter
of
details
on
when
there
were
more
serious.
It
was
about
side.
The
problems,
for
instance,
or
the
old
discussion
about
DHCP,
was
a
distraction
because,
even
though
the
left
D
is
not
very
important,
it's
something
to
do
in
the
future,
etc.
E
F
C
Thanks
so
okay,
it's
good
yeah,
there's
a
lot
of
disk
there's
there.
It
has
changed
some,
but,
as
everyone
said,
some
of
the
stuff
was
basically
clarifying
that
we're
not
gonna
care
about
certain
things,
but
I
do
think
it's.
You
know
it's
important
for
us
to
move
that
forward
and
I
think
you
know.
I
know
that
I
before
we
go
back
to
the
80s
to
sort
of
have
them
push
on
there
discusses.
We
want
to
feel
confident
that
you
know.
We've
got
some
good
consensus
going
on
here
that
people
have
sort
of
done
that.
C
Do
we
fold
these
two
together
to
make
them
one
ours
you
know
Jacob
is
which
is
just
one
hour
see
that
has
the
padding
as
well
as
the
profiles,
or
do
we
have
two
different
things
right,
and
so
that's
just
a
discussion
point
something
to
think
about
sort
of
thing
right,
rather
than
giving
implementers
two
different
things
to
work
on
and
give
them
one.
But
you
know
there's
just
options
for
you
guys
that
for
your
folks
to
talk
about
next
one,
what
else
do
we
and
I
know
that
Christian
is
going
to
talk?
C
I
guess
it
could
have
put
it
though,
and
then
Dan's
got
talk
about
his
little
DNS
demarks
idea
so
and
he
can
because
he
gave
us
slides
at
2:00
a.m.
so.
You
know
he's
allowed
to
now
talk
and
we
may
have
a
final
presentation
with
David
Lawrence
talking
about
something
that
Warren
has
to
do.
Some
slides
were
in
another
meeting,
he's
going
to
send
them
supposedly,
but
you
know
and
we'll
give
him
that
former
chair
privilege
one
time
only
so
and
but
and
then
the
we
had.
C
We
had
left
a
lot
of
time
for
an
open
session,
because
we
want
to
talk
about
this
step
to
I
know.
Stefan
had
worked
on
this
step
to
you
know
the
first
pass
of
a
document
and
we've
had
some
good
discussion
on
it,
but
you
know
it's
going
to
take
a
little
bit
of
sussing
out
so
we're
you
know
where
our
next
steps
and
words
of
groupthink
we're
going
to
go
sort
of
thing,
so
it'll
be
sort
of
good
to
sort
of
have
a
more
free-flowing
type
of
discussion
in
that
regard.
C
You
know
stuff
that
the
that's
on
the
IETF
Network
here
but
I
think
if
anybody
should
we
should
be
so
if
not,
we
should
be
ashamed
of
ourselves
and
one
of
the
things
that
I
know
from
an
Operations
person
like
you
know
it.
That's
my
my
fault
in
life
is
I.
Think
about
this.
Is
our
people
deploying
this
or
people
trying
to
use
it
where
they
kind
of
run
into
problems?
That
kind
of
thing,
so
you
know,
and
what
we
want
to
see
as
we
go
to
the
next
step.
C
Re
I
think
the
next
thing,
as
we
start
to
think
about
Phase
two
people
are
going
to
easily
push
back
and
say
also,
how
is
it?
How
is
it
working
operationally
in
phase
one?
You
know
that
kind
of
you
know
I
think
that's
a
big
thing.
You
know,
and
so
really.
Where
do
we
go
from
here?
So
we
only
ask
for
an
hour.
We
had
two
and
a
half,
so
you
know
I,
don't
think
we
use
the
whole
time.
You
all
may
think
otherwise,
so
surprises
or
it
don't
surprise
us,
you
know
it's
early.
C
H
I
I
It
was
totally
my
fault
because
I
should
have
updated
it
by
the
time
I
left,
Chicago,
I
actually
didn't
so
I
was
a
little
bit
for
it
that
the
IDE
submission
system
would
not
allow
my
zero
one
version
since
the
zero
zero
was
expired,
but
well
it
cuts
through
so
I
posted
zero
one
two
weeks
ago.
Actually
there
is
just
one
significant
change
in
the,
which
is
that
the
document
now
contains
a
recommended
strategy.
Yeah
I'm
gonna
talk
about
that
on
the
next
slide
and
there
were
some
editorial
changes.
I
The
document
text
is
still
pretty
rough.
So
before
we
like
push
that
to
publication,
we
would
still
need
to
to
clear
the
text
and,
like
probably
reduce
some
of
the
text
regarding
that
strategies.
So
I
got
a
little
bit
of
feedback
on
the
mailing
list,
the
first
one
that
I
said
that
I
got
was
that
we
should
also
mention
the
strategy
to
pay
it
to
the
maximum
message.
Size
I
can
echo
net
that
in
the
next
version,
Paul
said
wording
seemed
fine.
I
Shane
actually
said
that
packet
counts
is
maybe
more
important
than
actual
packet
size.
From
an
operational
perspective,
I
can
see
anything
to
that
because
I'm
not
from
the
operations
stuff
and
in
private
feedback
I,
actually
got
the
call
equation.
Vitam,
we
do
random
pairing
because
the
person
said
that
random
pairing
would
actually
prevent
analysis
on
block
accounts.
I
That's
essentially
that
you
should
pay
at
the
queries
to
a
block
size
of
128,
bytes
yeah,
and
you
should
pet
responses
to
468
and
also
assert
recommendation.
He
found
out
that
it
doesn't
really
make
sense
to
pair
the
response
when
the
query
was
not
padded
because
the
signature
of
the
queries
when
unpaired
it
is
so
easily
distinguishable
that
it
doesn't
make
sense
to
hide
the
responses.
Anyways
I
think
still.
I
I
He
essentially
did
a
shoot
out
of
all
the
various
pairing
strategies,
with
with
a
cost
function
that
he
defined
to
both
answer
to
the
attacker
and
to
the
defender
so,
and
this
is
sort
of
like
the
curve
of
the
optimum
strategies
in
terms
of
a
certain
costs
ratio
between
at
a
current
and
a
defender
cost,
so
the
cost
function
as
far
as
I
know
sent.
Of
course,
that's
critical
to
the
understanding
what
the
actual
impact
is.
I
So
the
cost
function
is,
as
far
as
I
understand
for
the
strategy
that
he
recommends,
which
is
128
bytes
on
the
client
side
and
the
query
side
and
468
on
the
response
side.
Is
that
essentially
means
that
about
93%
of
all
packets
have
the
exact
same
size
yeah?
If
that's
correct,
so
1.0
would
mean
that
all
the
packets
have
the
same
size
and
the
strategy
that
he
recommends
would
mean
a
93%
of
all.
The
packets
have
identical
size.
J
K
K
What
are
the
if
you
pick
that
pack,
if
there's
a
set
of
query
response
pairs
that
an
attacker
might
be
interested
in,
which
is
all
of
the
query,
query
response
pairs
that
you
get,
and
so,
if
we
pick
one
of
those
at
random,
how
many
other
queries
are
likely
to
be
in
that
same
to
have
the
same
size
signature?
So
it's
not
just
that
93%
are
in
the
same
bucket
and
that
all
the
rest
might
be
totally
in
different
buckets.
K
I
K
Well
so
I
can
I
mean
I
can
speak
to
that
I
actually
included
random
padding
policies.
If
you
there's
a
list
on
the
right-hand
side
of
that
slide,
there
that's
light.
It's
I'm
happy
to
do
deeper
explanation
of
what
of
how
that
was
calculated
if
folks
are
interested,
but
basically
the
every
hourglass
shape
on
that
slide
represents
a
padding
policy
combination,
the
query,
padding
policy
on
the
bottom
and
the
response
padding
policy
on
the
top
and
they're
color-coordinated.
I
M
Yeah
we'd
like
to
support
what
Dan
said
and
also
implementing
when
a
buddy
is
excuse
me
I'm
Christian.
We
came
up
to
support
what
dance
there
is
another
issue
about
random
body.
Is
that
it's
much
harder
to
implement
right
than
the
path
to
the
next
la
banda
way
and
and
it's
very
easy
and
try
to
do
random
stuff?
Two
of
them
cannot
pseudo
random
and
actually
leak
information.
K
K
In
the
course
of
looking
at
the
different
random
padding
policies,
I
noted
that
the
DNS
crypt
work
included
some
random,
padding
and
I
believe
one
of
those
strategies
up.
There
was
a
rough
approximation
of
their
work,
but
one
of
the
things
that
they
did
with
their
random
padding,
and
this
is
something
that
hadn't
even
occurred
to
me
until
I
looked
at
what
their
code
was
doing,
was
that
the
client
sent
a
nonce
with
the
query.
K
Okay
and
the
server
had
a
its
own
secret
state
upon
initialization,
and
it
chose
its
random
padding
on
a
basis
of
a
combination
of
the
nonce
and
the
query
specifically
because
they
are
not
protected
against
replay
attack
and
they
observed
that
an
attacker
who
could
do
a
replay
attack
with
with
the
DNS
crypt
query
could
just
if
it
was
random,
padding
see
what
the
random
response
was
from
the
server.
By
sending
it
several
times,
and
you
know
yeah,
you
can
narrow
it
down
to.
K
I
L
I
Right
now,
in
a
document,
do
we
need
to
do
more
research?
If,
if
we
need
to
do
more
research,
does
anybody
like
volunteering
to
do
that?
I
think
that
what
we
should
actually
research
would
be
like
the
cost
function.
Yeah
is
that
the
cost
function
that
we
need,
of
course,
to
be
interesting
to
hear
someone
from
the
attacker
side,
yeah
I'm,
not
seeing
them
volunteering
to
reveal
that
kind
of
information.
Furthermore,
there
is,
of
course,
a
trade-off.
I
First,
we
have
seen
in
the
previous
slide
between
the
bandwidth
cost
and
follow-up
cost,
so
is
the
sweet
spot
that
daniel
chose
the
right
one
yeah?
What's
the
what's
the
what's
the
reason
for
that
and,
of
course
out
of
field
date
that
we
had
data
from
one
reasonably
big
precursor,
but
might
be
interesting
to
look
at
other
data
and
something
that
I
came
up
in
a
hallway
discussion
yesterday.
I
If
we
feel
that
that's
the
best
knowledge
that
we
have
at
that
moment,
but
we
could
like
find
out,
we
have
a
more
reasonable
strategy
in
the
near
future.
We
could
actually
declare
that
document
is
experimental,
yeah,
which
also
would
answer
your
question
regarding
rolling
in
the
pending
policy
into
the
RFC
7h30,
because
I
think
essentially
III.
I
Can
go
wrong
with
that?
Well,
so
the
other
questions
with
regards
to
the
document
is:
do
we
want
to
keep
the
description
of
the
strategies?
Do
we
want
to
like
compress
that
a
little
bit
I
can
add
a
little
bit
of
more
strategies
like,
as
we
said
that
to
the
maximum
size,
and
we
need
review
is
because
a
lot
of
to
do
words
in
the
draft
yet
and
nobody
like
complained
about
them
yet
and
of
course,
why?
Four
six
eight!
If
it's
a
trough,
if
it's
a
it's
in
a
document,
that's
the
recommended
strategy.
I
M
I
You
would
like
to
be
able
to
reverse
engineer
whether
the
original
TNS
message
was
like
on
the
edge
of
a
block
size,
yeah,
but
I
haven't
added
to
the
draft,
but
but
you're
right,
Christy
and
I
will
need
to
add
considerations
for
well
known
transports
at
that
time.
Yeah
I
have
no
idea
about
quick,
so
we
would
probably
update
that
need
to
update
that
in
the
first
place
anyway.
As
soon
as
we
have
more
transports,
we're.
M
I
C
M
M
M
That's
basically,
if
you
can
do
padding
of
your
query
to
the
expected
size
of
the
rest
cause,
then
you
get
some
built-in
dose
protection.
Oh
you
mean
like
a
proof-of-work
analytical
because
because
well
like,
if
you
have
a
policy
on
the
server
that
you
will
basically
send
a
TC
bit
if
the
answer
in
the,
if
the
response
is
longer
than
the
query.
K
M
M
I
M
K
K
I
support
keeping
this
as
a
separate
draft
I
do
think
that
it's
relevant
for
DNS
over
TLS,
just
because
it's
the
best
that
we
currently
have
I
am
under,
despite
being
the
person
who
did
the
research
to
come
up
with
this
split
here
I'm
under
no
illusions
that
this
is
perfect
and
in
fact
that
the
what
is
the
best
padding
policy
may
change
as
the
network
changes
over
time.
So
I
think
it's
important
that
we
can
say.
K
K
If
anybody
wants
to
do
it,
then
you
can
just
upgrade
your
library
to
get
the
new
best
recommendation
as
the
as
the
recommended
policy.
You
know
changes
so
I'm
happy
to
see
this
as
a
starting
point.
I
support,
publication
and
I
would
also
be
super
happy
if
somebody
wanted
to
immediately
revise
it
because
hey
they've
got
better
data.
Thanks.
N
N
If
we
can
convince
the
client
to
send
some
queries
that
are
on
the
edge
between
our
block
size,
we
might
be
able
to
discover
them.
I,
don't
know
what
these
kind
of
techniques
are
and
I.
Don't
know
how
they're
gonna
extract
signal
from
the
noise.
So
as
long
as
we
recognize
that
there
may
be
attacks
like
this,
that
we
don't
know
about.
That's
why
I
think
experimental
is
probably
good
for
this.
N
K
K
There's
crypto
overhead
in
each
packet,
and
so
you
need
to
account
for
some
amount
of
cryptographic
overhead
when
the
thing
is
encrypted.
So
we're
talking
about
padding
the
clear
text
size
up
to
roughly
1,400.
If
you
get
three
four
sixty
eights,
you
get
1402
and
that
leaves
you
a
little
bit
of
room
below
the
common
m
to
use
that
people
encounter
for
your
crypto
overhead.
I
L
E
If
we
don't
have,
but
if
you
don't
have
a
FC
there
is
a
risks
at
implementers
will
start
to
design
your
own
adding
strategies
which
is
almost
certain
to
fail,
because
it's
not
obvious
in
the
document
we
have
data.
We
just
have
salty
code
analysis.
We
have
data
thanks
to
D
K
G,
so
we
can
be
reasonably
confident
on
any
weight
better
than
the
strategies
that
people
take
out
of
the
manifest
type
date.
So
I
think
we
should
move
for
water.
Yes,
I
will
send
a
with
you.
Okay,.
C
C
Yeah
I
think
we're
people
are
going
to
experiment
and
see
what
is
the
best
policy
and
that
kind
of
thing.
So
unless
anybody
finally
opposes
that
I
believe
that's
probably
the
best
way
forward
on
that,
and
you
know
the
the
topic
of
the
sort
of
merger
was
more
of
just
a
you
know
it
wasn't
like.
Oh,
we
think
this
is
the
the
right
answer,
but
we
see
the
difference.
C
You
know,
70/30
is
a
very
simple
straightforward
document,
and-
and
this
is
definitely
something
at
some
point
down
the
road,
as
this
thing
connected
may
be
sort
of
you
know,
coalesce,
as
you
could
sort
of
see
that
happening
where
the
implementers
had
like
just
one
draft
to
basically
sort
of
build
and
sort
of
you
know,
and
here's
like
sort
of
the
best
way
to
sort
of
attack
it
but
yeah.
Definitely
it
was
more
of
a
discussion
point
just
to
make
sure
people
are
sort
of
paying
attention
this
morning.
C
Sort
of
thing
so
and,
and
so
I
did
hear
from
Stephan.
He
agreed
to
review
it
we'd
like
to
get
actually
a
few
more
folks
to
review.
If
we
can
have
some
show
of
hands
so
folks
to
review
so
I
see
Sarah
dkg
I
see
mr.
Lawrence
I
see
Christian
who's
in
the
back
there
Shane
Paul.
Can
you
I'm
writing
these
down
as
well?
Although.
C
So
way
in
the
back,
okay,
so
I
appreciate
that.
Well,
oh,
it
was
Sarah
Christian,
Lawrence,
dkg
Shane
and
whose
way
in
the
back
I
know
Oh
fair
way
in
the
back
so
and
we
can,
we
can
hold
them
to
do
it
sort
of
thing.
So,
but
yes,
we
I
do
like
where
this
is
going
and
so
I
think,
with
the
wisdom,
clean
up
and
folks
sort
of
addressing
some
of
the
to
dues,
yeah
we're
looking
pretty
good.
So
mr.
Hartigan.
P
C
Q
K
So,
what's
linked,
there
is
a
set
of
presentation
slides,
which
does
include
in
sort
of
presentation
format,
but
not
in
a
textual
format.
I
would
be
interested
in
having
enough
time
to
write
this
down
in
sort
of
like
a
more
sort
of
la
techie,
formal
paper
that
describes
it,
but
it
does
describe
the
formula
used
for
the
follow
up
cost
the
formula
used
for
the
bandwidth
cost
and
how
the
combinations
were
done
in
some
visualizations
of
the
underlying
data.
K
So
it
includes
a
bunch
of
that
stuff,
but
it
is
in
presentation,
format
and
not
in
like
a
draft
format
like
what
we
would
be
used
to
seeing,
given
that
we
can
do
SVG
I
hear
in
RFC's,
maybe
I
could
put
it
into
an
RFC
draft
or
something
but
I'm
not
like
I,
have
a
lot
of
other
things
to
work
on
right
now,
so
I'm
not
about
to
do
that.
I
was.
K
If
there's
anyone
who
wants
to
try
to
replicate
the
measurements
I
have
source
code,
I
can
I'm
happy
to
give
you
a
copy
of
maybe
I'll,
even
just
clean
it
up
and
publish
it,
because
I
think
that
would
be
useful
if
you've
got
data.
If
you
run
a
recursive,
resolver
I
can
give
you
a
specification
for
what
kind
of
data
I
could
run
the
code
on,
and
you
could
just
give
me.
The
data
I
only
need
counts
of
the
packet
sizes,
queries
and
responses
correlated
without
any
other
information.
I,
don't
want
any
other
information.
M
M
M
If
you
make
them
too
short,
you
create
a
lot
of
overhead
again
because
you
have
to
reestablish
them.
What
you
get
with
availability
of
zero
RTT
is
that
your
policy
can
be
much
simpler
because
the
cost
you
pay
for
a
reestablishment
is
much
lower.
You
don't
have
this
overhead
of
waiting
for
the
handshake
to
complete
before
you
can
follow
the
query.
You
can
followed
it
immediately,
and
so
it
becomes
easier
to
do
a
policy
us
as
well
in
something
something
complex
about.
I
have
to
wait
a
long
time
or
I
have
to
do
some
good.
M
If
you
get
it
a
bit
wrong
and
you
cut
it
too
soon,
it
still
doesn't
matter
very
much
because
you
can
reestablish
it
very
quickly.
The
other
feature
is
head
of
queue
blocking
so
head
of
crew.
Blocking
is
the
idea
that
if
you
lose
one
packet
say
in
TCP,
you
will
only
deliver
the
packet
of
are
transmitted
after
that,
after
the
packet
that
you
lose
lost
was
corrected
because
TCP
effective
is
a
arise
all
those
transmissions.
It
turns
out
that
when
you
do
dns
the
DNS
traffic
is
very
bursty.
M
M
While,
if
you
have
this
parallel
processing,
that
quick
enables
you
can
just
repeat
the
one
that
was
transmitted
that
one
gets
delayed
because
that's
we
corrected,
but
the
also
one
can
be
processed
immediately
and
with
an
immediate
e
and
that's
a
big
win
that
gets
you
effectively
what
you
get
with
UDP.
Otherwise,
you
have
a
retransmission
efficiency.
M
Well,
that's
the
difference
between
it's
basically
on
par
with
TCP,
as
of
modern,
TCP,
selective
acknowledgment,
etc.
But
it's
better
than
UDP.
One
thing
we
notice
on
UDP
is
that
the
retransmission
process
of
UDP
is
end
to
end.
If
a
query
doesn't
get
responded
to
in
some
time,
you
retransmit
it
that
sometime
has
to
scare
with
the
end-to-end
processing
of
the
query.
M
On
the
other
hand,
if
you
do
something
at
TCP
or
quake,
your
retransmission
can
be
as
short
as
your
RTT
to
the
resolver,
so
the
retransmission
with
TCP,
always
quick,
is
much
more
efficient
than
the
retransmission
with
UDP,
and
the
next
thing
is
the
long
messages.
If
the
message
is
larger
than
the
MTU
with
UDP
you,
basically
after
the
strategy
of
falling
back
to
TCP-
and
that
is
not
a
problem-
is
quick
because
quick,
like
TCP,
suppose,
message
of
arbitrary
length.
M
M
Bye-Bye
tree
we
uncheck
as
TCP.
Does
it
also
provides
you
the
same
encryption
and
authentication
processes
as
TLS?
In
fact,
the
implementation
of
quakes
that
we
have
now?
The
specification
relies
on
theorists,
1.3
and
a
EAD,
so
basically
the
same
as
a
ste
res
1.3,
so
that
that's
the
features
and
those
features
are
interesting
if
I
do
a
comparison
table
of
the
the
values
transporters
that
can
think
of
and
I
look
at
those
figures
that
I
want
for
my
transport.
M
Ok
I
see
that
basically
the
collection
setup
time
is
the
best
with
with
UDP,
because
there
is
no
connection
whatsoever.
All
the
also
transport
of
a
handshake
is
all
TCP
handshake
or
the
TCP
and
TLS
handshake
or
in
the
case
of
DT,
as
the
original
handshake
to
establish
there.
The
session
keys
now
quick
as
that
patellas
are
just
once
and
then
you
can
do
the
oddity
with
you.
So
quick
is
not
quite
as
fast
in
connection
setup.
That
was
UDP,
of
course,
but
it
will
be
most
of
the
time
as
good
as
UDP.
M
You
can
have
also
the
next
video
is
head
of
queue
blocking,
which
is
really
a
pain
for
TCP
and
TLS.
Because
of
the
budget
nature
of
the
arrival
of
processes,
so
that
is
solved
with
UDP
itself
with
details,
it's
always
quick.
It's
not
soft
with
the
other
one
retransmission
efficiency
I
mean
basically
here.
M
The
the
classic
end-to-end
retransmission
gives
you
worse
performance
than
something
based
on
an
actual
organised,
retransmission
and
log
messages
where
the
UDP
bears
protocol
of
to
fall
back
then,
in
terms
of
security,
you
need
to
have
the
three
worst
handshake
and,
yes,
you
can
bring
back
the
to
erase
and
check
with
UDP.
You
should
have
a
quorum
for
UDP
plus
session
cookies,
which
will
give
you
this
the
truest
handshake.
But
then,
in
that
case,
if
you
do,
if
you
know
session
cookies
in
UDP,
then
you
lose
the
connection
setup
time
issue
because
I
mean
it.
M
M
Now,
let's,
let's
add
a
caveat
to
that
nice
sales
pitch?
Okay,
so
that
nobody
panics
hey
all
of
those?
Don't
happen
not
happen
to
be
useful,
very
often
like
the
connection
setup
times,
it
happens
once
every
200
transactions
about
in
the
classic
TCP
saying
so
it's
largely
amortized
the
head
of
queue
blocking.
It
only
happens
when
you
have
a
consumption
of
a
packet
loss
and
a
burst.
M
M
The
best
statistics
I
have
on
long
messages
is
they
happen
on
once
every
1,000
transaction,
or
something
like
that
that
you
have
to
actually
use
the
truncation
because
of
the
message
is
too
long.
So
if,
instead
of
doing
that,
you
plot
the
response
curve
of
the
voice
transport
given
the
same
load.
There
are
almost
same
when
those
difference
are
nice
difference,
but
they
are
almost
same
actually
for
disturb
to
recursive,
because
the
DePalma
taught
her
battles
most.
R
So
for
me
the
big
advantage
of
doing
quick
is
I
can
have
a
completely
ident
resolver
I,
don't
really
care
at
all
about
the
resolver
to
authoritative
loop,
because
the
way
that
you
do
that
in
a
really
large
farm
is
it's
completely
decoupled,
except
in
the
case
that
you're
doing
a
request
for
something
that
you
don't
have
in
cache.
If
I
don't
wait
and
you
know,
I
have
a
cache
of
DNS
record
requests,
I
go
when
one
of
those
things
timeout
I
will
prefetch
before
it
times
out.
R
I,
don't
wait
for
somebody
to
ask
and
then
do
it
on
the
demand
cache
load.
So
my
entire
interest
is
actually
in
the
client
to
resolve
a
loop.
The
resolver
to
authoritative
attack
is
out-of-band
and
not
in
the
critical
loop
yep.
So
I'd
like
to
see
on
the
quick
side
can
I
do
that
ident
completely
stateless
loading
I'd
be
sure
you
should
be
able
to.
It
might
require
a
bit
of
trickery
and
a
deeper
understanding
of
quick
than
I
have
already,
but
that
to
me
is
the
real
payoff.
Yes,
in
fact,.
M
That's
that's
a
very
good
question.
If
you
look
at
the
feedback
from
deployments,
you
see
that
very
few
people
deploy
DNS
about
here
is
our
TCP
later
on
Tara's
and
the
usual
reason
for
that
is
because
running
a
server
with
a
large
number
of
tiras
of
TCP
connection
tends
to
be
much
more
expensive
than
running
a
server.
Who
is
just
forcing
data
grams.
M
One
of
the
question
that
as
phil
says,
is
whether
we
can
have
an
implementation
of
quick
that
reduces
that
load
on
the
server
and
the
motivation
for
me
is
that
I
believe
that
will
in
any
case
need
to
do
security.
So
we'd
have
to
have
some
state
if
only
to
manage
their
the
encryption
and
things
like
that.
But
can
we
minimize
the
cost
of
having
that
state
and
the
beauty
of
quick
there
is
that
quick
is
implemented
in
application
processes
as
a
library,
and
that
means
two
things.
M
That
means
that
you
can
experiment
with
different
implementation
so
that
you,
you
can
very
quickly
change
your
library.
You
don't
have
to
wait
for
an
update
of
your
underlying
operating
system
to
get
a
change
in
your
stack.
So
it
means
that
you
can
be
much
more
agile
and
try
new
stuff,
and
the
other
thing
is
because
you
do
that
in
a
library
you
don't
necessarily
have
to
have
a
one-size-fits-all
API
on
your
transport.
M
S
I
anger
so
currently
as
quick
as
specified
so
echoing
Phil's
point
that
I
think
that
the
stateless
case
is
very
important
that
resolver
should
be
had
able
to
handle
DNS
responses
in
stateless
way.
So
the
current
way
that
quic
is
specified
is
that
one
UDP
packet,
it
corresponds
to
one
quick
packet,
and
so
encryption
is
done
at
the
quick
packet
layer.
So
what
that?
What
that
means
is
that
the
first
UDP
packet,
which
is
the
TLS
1/3
client
hello?
S
So
it
is
the
currently
specified
it's
called
the
client
initial
packet
has
to
be
in
a
separate
UDP
payload
from
the
from
the
first
encrypted
packet,
which
is
the
route
is
which
is
a
request?
Yes,
so
since
it
is
across
multiple
UDP
packets,
that
necessarily
implies
that
we
have
to
have
some
state
for
some
amount
of
time
to
handle
that
transition
between
payloads.
S
M
A
look
at
that
absolutely,
and
in
fact
that
was
one
of
the
big
motivation
we
had
to
start.
These
DNS
of
a
quick
effort
was
precisely
to
see
what
that
tells
us
about
the
figures.
We
are
missing
in
quick
that
we
should
have
and
what
what
you
described
about
being
able
to
pass
several
frames.
Several
encryption
frames
in
a
singer'
UDP
packet
is
clearly
something
we
might
want
to
explore.
Even.
T
Sweat
Google
I
was
mostly
gonna
echo.
The
fact
that
yes,
I,
think
there's
already
an
open
issue
on
the
github.
For
you
know
trying
to
do
this
and
I
am
fairly
certain.
It's
going
to
happen
partially
because
it
would
be
beneficial
for
HTTP
applications
as
well.
Even
if
it's
a
minor
optimization
and
so
it
seems
that
seems
valuable
and
then
the
other
thing
I
was
gonna
say,
is
I,
wouldn't
discount
the
fact
that
the
head-of-line
blocking
advantage
versus
TLS
over
TCP
when
I
just
pulled
up
some
tail
latency
numbers
95th
percentile
on
DNS
resolution.
M
Iii
have
summation
curls
and
what
they
say
is
that
basically
your
curve,
if
you,
if
you
take
your
classic
community
frequency
distribution,
curves
and
you
see
they're
exactly
the
same
up
to
the
95th
percentile
for
all
transports,
and
then
you
do
see
differences
and
if
you
assume
a
1%
loss
rate,
for
example,
in
both
direction.
You
see
that
the
difference
happen
like
in
five
percent
of
the
case.
They
between
95
and
98
TCP
will
be
slower
than
UDP
because
of
ahead
of
queue
blocking
and
then
from
98%.
M
U
My
only
concern
about
about
this
is
that
what
I
really
want
from
this
is
to
be
able
to
to
multiplex
this
with
other
services
over
quick
inside
the
inside
the
crypto
context
inside
the
ciphertext
stream.
If
I
have
to
run
this
on
a
separate
port,
for
example,
from
from
other
quick
services,
then
then
that
defeats
a
lot
of
the
confidentiality
advantages.
In
particular,
it
allows
network
operators
who
already
interfere
with
DNS
to
continue
interfering
with
DNS
by
forcing
clients
to
fall
back
to
insecure
DNS.
U
M
U
M
I
I
L
W
I
M
J
I
To
the
IGF,
but
so
I'm
a
little
bit
careful
about
this
is
a
smaller
group
and
if
we
invest
all
the
effort
into
a
single
transport,
that's
maybe
more
efficient,
rather
than
rolling
out
three
or
four
transports.
On
the
other
hand,
I
assume
that
the
implementers
of
the
potential
software
that
would
use
DNS,
Oh,
HTTP
or
HTTPS,
of
course
they
have
much
more
resources
than
we
probably
have
in
the
working
group.
So
yeah.
S
Spanger
so
most
existing
deployment,
these
seven
ARS
deployed
in
stateless
mode,
and
it's
like
request
response
immediately
and
we
only
deployed
and
ours,
the
so
I
mean
doesn't
quick,
seem
quite
a
heavy
weight
for
that
purpose
like
that
is
we're
trying
to
solve
a
were
denied
a
shot
of
a
quick
server
now
into
a
DNS
server,
and
then
that
seems
heavyweight
that
we're
trying
to
solve
all
the
problems
at
once.
I
would
actually
like
to
see
a
solution
which
kind
of
is
simple
and
works
for
the
DNS
case
as
well.
S
That
is
like
I
am
a
stateless
server
and
I
want
to
not
make
that
many
modifications
to
my
DNS
server
to
actually
have
encrypted
transport.
So
in
terms
of
yeah,
like
quick
exists,
it
provides
the
properties
that
we
want,
but
it
is
like
it
provides
a
whole
host
of
additional
properties
that
we
might
not
want
not
sure
what
we're
gonna
use
them
for,
but
well
and.
L
X
My
name
is
Andrew
Sullivan
IP.
So
let
me
just
preface
this
by
saying:
I
think
that
quick
is
pretty
promising
for
for
a
use
cases
and
I
I'm
pleased
to
see
this
work,
but
I
I'm
a
little
nervous
about
the
way
you
find
this,
the
sort
of
stub
to
recursive
versus
you
know,
recursive,
Zoar,
forwarders
or
whatever
to
other
stuff
and
the
reason
I'm
I'm
nervous
about
it
is.
X
If
you
think
that
the
purpose
of
quick
is
really
just
to
enhance
privacy,
then
this
would
be
a
reasonable
split
once
again,
but
I.
Don't
think
that
that's
the
only
advantage
here
and
I
think
that
that
the
plain
fact
is
that
if
we
embrace
quick,
what
we're
doing
is
we're
introducing
a
new
transport
for
DNS.
Yes,
I'm
very,
very
nervous
about
splitting
the
DNS
protocol
kind
of
permanently
into
the
stub
to
recursive
versus
everything
else
on.
X
The
protocol
doesn't
really
work
that
way,
and
there
are
a
number
of
ways
in
which
in
which
the
symmetry
of
the
protocol
is
lost.
If
we
start,
we
start
making
that
kind
of
division,
yeah,
so
I
would
be
uncomfortable
actually
with
with
tackling
things
in
this
way,
and
I
would
really
actually
much
rather
just
say:
okay,
new
transport,
we're
gonna,
we're
gonna,
do
the
whole
thing.
That
of
course,
now
creates
like
a
whole
bureaucratic
problem,
because
I
don't
think
this
working
group
is
very
well
chartered
to
solve
the
problem
that
way.
M
When
I
do
measurements
of
performances-
okay,
because
I
mean
the
large
part
meant
down
to
motivation
for
Quake
security
and
performance,
the
when
I
do
measurement
of
performance.
It
appears
that
if
you
look
at
the
distribution
of
your
query
response
time
about
less
than
half
of
your
queries
of
served
by
your
cache
of
the
resolver
because
of
TTL
management
and
all
that
the
other
half,
obviously
you
see
a
tail
of
response
time.
M
That
indicates
that,
obviously
it
has
been
going
to
the
internet
to
find
a
query
recurse
at
cetera
and
those
have
a
much
longer
delay.
So,
if
we
think
about
performance,
we
have
to
consider
the
reference
potential
performance
gain
on
the
wide
internet
scenario,
which
we'll
be
your
points.
Basically,
the
transport
for
DNS
and
I
think
that
people
understood
the
issues
with
UDP
retransmission,
because
the
UDP
retransmission
is
very
inefficient.
M
It's
typically
you
have
long
timers
and
because,
if
you
do
this
resolution
for
the
internet,
you
end
up
with
a
chain
of
resolutions
like
like
7
CMS
of
some
CDN
providers
and
things
like
that.
Amina
look
behind
you
and,
and
that
means
that
you
have
many
opportunity
to
lose
a
packet
and
go
into
this
inefficiency
or
further
Commandments
port,
so
there
is
actually
a
strong
motivation
for
having
something
more
efficient
on
the
white
internet
at
the
same
time.
M
X
So,
there's
a
small,
firm,
mrs.
Andrew
again
that
there's
a
small
problem
in
the
way
you
just
described
that
because
you're
only
talking
from
the
perspective
of
one
side
of
that
of
that
communication,
but
but
the
problem
is
of
course,
on
the
other
side,
the
servers
have
a
different
set
of
trade-offs
with
respect
to
efficiency
and
overhead
and
all
the
rest
of
it.
Yet
on
the
retransmission,
things
are
actually
non-trivial
for
the
server
side
as
well,
because,
of
course,
under
conditions-
and
you
know
given
where
I
work,
but
I'm
not
allowed
to
talk
about
them.
X
The
the
plain
fact
is
is
that
you
know
that
hurts
on
the
server
side
as
well,
so
I
think
that
there's
a
whole
bunch
of
considerations
there.
That
are
that.
That
really
actually
need
to
be
analyzed
at
this
at
the
outset,
because
if
you
do
this,
only
in
the
first
in
the
in
the
first
hop
of
this
of
this
potential
hop-by-hop
protocol,
you
can
make
decisions
in
there
that
are
not
going
to
are
not
going
to
carry
through.
Maybe
that's
the
right
answer,
but
at
that
point
we're
talking
really
about
a
new
protocol.
I'm
not.
L
X
M
R
Phil
Han
Baker
again
so
responding
to
the
previous,
but
one
speak.
Somebody
did
actually
propose
doing
a
simple
UDP
transport
that
was
custom
to
DNS
in
the
original
meeting
proposal
and
the
reason
it
was
rejected.
I
think
it
was
three
years
ago
now
was
that
this
was
work
that
was
very
important
and
had
to
be
done
in
nine
months
yeah,
which
is
one
of
those
you
know,
spec
smells
whenever
I've
been
in
an
organized
standards.
Meeting
where
somebody
has
said:
we've
got
to
do
this
fast,
so
we've
got
to
do
it.
R
Sloppy
they've
never
ever
met
their
schedule.
The
reason
that
I
prefer
quick
over
what
I
propose
now
is
twofold:
one
of
them
is
quick
exists.
People
are
going
to
do
quick
over
there
now,
so
it's
people
are
going
to
do
dear.
Let's
have
a
quick
yeah.
Yes,
actually
people
are
going
to
do
quick
over
DNS.
Sorry
as
well,
but
yes,
quick
is
quick,
is
rapidly
becoming
the
new
SSH
yep,
it's
the.
Currently,
it
is
going
to
subsume
everything,
and
so
that's
one
reason.
R
The
other
reason
is
that
there
are
very
few
people
in
IETF
who
really
are
going
to
propose
a
new
cryptographic
protocol.
If
you
look
at
the
number
of
proposals
that
have
been
accepted,
in
fact,
the
number
of
proposals
has
been
made.
There
are
very
few
individuals.
Who've
ever
proposed
a
new
cryptographic
protocol.
R
M
R
That
the
subtle
part
that
original
character
I
think
that
what
you're
going
to
find
following
over
all
Anderson,
we
are
going
to
effectively
change
the
DNS
protocol,
no
matter
what?
Because
the
DNS
protocol
is
now
what
30
years
old
the
the
spec
is
awful,
it's
younger
than
me,
you
know
it's,
it
is
written,
understand,
yeah
it.
It
is
worse
than
you
typical
draft
and
there's
a
lot
of
things.
R
The
rent
of
your
requests
is
effectively
bounded
because
the
request
format.
Well,
they
blew
it.
So
you
can
only
effectively
have
one
request.
Yeah
the
protocol
allows
multiple
requests,
but
because
of
the
way
the
protocol
is
written,
you
can't
actually
use
that.
So
it's
one
request
per
packet
and
that
limits
the
size
of
the
request.
The
way
that
we've
limited
the
size
of
response
has
been
purely
that
the
infrastructure
will
blow
up.
R
If
you
try
and
create
DNS
record
sets
that
are
too
large
and
one
of
the
things
that
you're
going
to
end
up
doing
regardless,
where
you
use
TLS
or
quick
or
whatever
you're
going
to
take
away
that
limit,
and
that
limit
has
to
be
there
because
we're
talking
about
bootstrap
for
discovery,
and
so
you
do
not
want
that
infrastructure.
Accepting
indefinite
unbounded
length
Palos,
actually
to
think
that
the
protocol
limit
is
about
a
megabyte
or
whatever
in
quick.
R
R
Think
that
what
I
want
to
see
in
order
to
understand
quicker,
but
it's
IDNs
over
quick
I'd
like
to
see
some
some
documents
that
actually
give
me
the
wire
line
and
what
it
actually
turns
out
to
be.
I
like
cities,
see
some
traces
and
then
I'd
be
able
to
understand
it's
a
lot
better,
because
at
the
moment,
I
had
to
read
the
quick
documents
which
are
a
moving
target
and
then
I
have
to
read
the
DNS
documents.
If
I
saw
that
in
a
document,
I
think
I'd
understand
it
better.
Okay,.
O
All
over
go
Amazon
Thank,
You
Christian.
This
is
the
second
time
in
this
working
group
that
I
start
questioning.
This
is
the
existence
of
reason
for
DNS
and
basically,
what
is
DNS.
Is
it
the
wire
format?
Is
it
the
protocol,
and
actually
it
is
a
wire
format
with
two
protocols
embedded
in
it?
It
is
the
question
it
is
the
end
of
the
way
we
select
between
the
two
protocols
is
by
use
of
the
Rd
bit
and
what
you
are
exactly
pointing
out
here.
O
O
Q
C
I
Alex,
my
over,
we
have
too
much
time
sitting
discussion
so
interesting.
Well,
thinking
about
it
again,
I
think
that
the
quick
awareness,
of
course
is
very
interesting,
because
what
we
see
in
other
areas
of
protocol
design,
it
seems
like
TCP,
it's
like
coming
to
be
I'm,
nothing
towards
the
n-well
to
use
my
degrees
in
the
next
coming
years.
I
M
E
Stephanie
Australia
speaking
I
won't
go
into
the
details
of
DNS
server,
quick
because
I
don't
know
quickly
enough
on
anyway.
My
remarks
are
also
for
DNS
other
HTTP.
If
we
have
three
possible
solutions
of
DNS
encryption,
DNS
server
to
Adele's
DNS
workweek
DNS
for
HTTP,
which
will
create
two
problems,
one
is
a
practical
problem.
The
resolve.
Well,
the
DNS
client
will
have
some
difficulty
making
the
right
choice
which
one
to
use
in
which
so
we
need
meta
guidance
for
the
client
on
the
other
problem
would
be
a
marketing
or
product
relations
problem.
E
C
So
yeah
then
there's
yes,
thank
you
for
all
that
the
part
of
the
read
we
ask
christian
is
sort
of
presented,
but
mostly
as
a
different
sort
of
privacy
thing.
Our
big
thing,
though,
is
my
big
concerns.
Were
you
know?
Quick
is
still
a
moving
target
right,
so
we're
sort
of
trying
to
hash
out
a
lot
of
things
that
they
still
haven't
kind
of
hashed
out
in
the
protocol
itself
and
I
know
in
reading
the
draft.
There's
a
lot
of
questions
introduced
and
things
like
that
that
are
sort
of
framed
in
there.
C
M
C
So,
yes,
your
your
district,
yeah
you're,
trying
to
basically
help
them
if
you're
gonna
do
quick
and
we
want
to
do
DNS
over
it.
You
know,
please
consider
these
considerations
sort
of
thing,
which
is
I
believe
what
a
few
things
that
sort
of
came
up.
I
think
you
know
I
heard
earlier
sort
of
thing:
yes,
I,
just
I
I
think
it's
early
for
us
to
sort
of
sit
there
and
say:
oh,
let's
go
deploy
a
bunch
of
stuff
over
this.
Oh
no
yeah,
I.
M
Think
we
basically
what
I
mean
success
for
these
in
the
short
term
would
be
to
have
experimental
implementation,
doing
measurements
and
comparisons
and
I
would
expect
that
to
happen
in
the
next
six
months
about
okay,
once
we
have
this
measurement
and
comparison,
then
we
would
have
several
iterations
of
the
twelfth
yes
doing
that.
Okay,
so
I
was
Michael
here.
The
presentation
here
was
really
to
get
feedback
yep
and
and
get
people
to
cooperate
and
send
us
their
requirements
and,
in
particular,
a
damage
like
to
have
cooperation.
One
people
running
big
server.
Yes,.
G
C
M
I
May
over,
while
it
may
be
tempting
to
solve
other
DNS
issues
while
adding
confidentiality.
Each
wife
is
not
a
working
group
to
do
this,
that's
what
in
the
current
Charter.
So
if
we
do
something
like
this,
we
would
I
suppose
require
a
significant
preacher
during
that.
Yes,.
C
And
I
I,
don't
think
we'd
actually
couldn't
felt
that
this
was
something
that
we
would
actually
bring
into
the
group.
There
was
something
good
to
discuss.
You
know
as
sort
of
another
sort
of
you
know,
here's
someone
out,
you
know
here's
another
sort
of
way
of
attacking
the
privacy.
Our
ad
is
gonna,
stand
up,
Oh
glorious
one
yeah.
Y
V
Y
Much
broader
encompasses
some
of
the
things
that
Andrew
mentioned
some
of
the
thoughts
that
I
have
as
well,
which
many
may
not
agree
with,
and
it's
from
an
architectural
sense
and
from
the
understanding
of
being
a
root
server
operator.
So
there's
an
expansion
here
great
to
start
it
here
great
to
have
discussion
but
keep
working,
keep
thinking.
C
Thank
you
exactly.
We
there's
a
there's
a
lot
of
the
solid
you
know
minds
of
people
doing
privacy
and
DNS
and
stuff
here
it's
a
good
place
to
actually
have
sort
of
some
of
that
discussion,
but
it's
not
that
it's
not
going
to
be
the
end
end
result
right,
so
we
figured
this
will
sort
of
go
out
into
the
creek
groups
into
other
places,
and
you
know
you
guys
will
sort
of
you
know
sort
of
seed,
the
seed,
the
IETF
with
with
good
ideas,
hopefully
or
just
quick
over
DNS
yeah,
okay,.
C
K
K
The
answer,
of
course,
is
that
they
were
just
blocked
port
853,
so
I'm.
Looking
at
that
and
said,
how
do
we
defend
against
that
and
then
the
obvious
arms
race?
We
simply
want
to
squat
on
port
443
so
that
the
network
at
adversary
can't
distinguish
between
our
traffic.
However,
if
you
have
your
main
server
running
on
a
well-known
on
an
easy
name,
but
people
for
configuration,
people
like
to
type
that
stuff
into
the
web
browser-
and
then
you
get
you
know
so
like
this.
This
is
a
web
browser.
K
That's
looking
at
a
web
service
running
on
port
443
HTTP.
This
is
a
real
thing.
It's
out
there
and
hey.
Why
can't
we
do
the
same
thing
also
on
port
443.
This
is
a
DNS
query
over
TLS
on
port
443
I,
don't
know,
can
you
guys
see
my
pointer?
Is
there
lasers
shoot
you
guys
with
lasers
yeah,
so
port
443
TCP
right
there,
so
this
is
the
same
server
running.
At
the
same
time,
nothing
has
changed
and
it's
simply
doing
both
HTTP
and
DNS
over
TLS.
So
how
does
it
do
that?
K
Well,
the
difference
is
that
we
look
at
the
clear
text.
Packets
and
we
just
do
multiplex
on
them-
turns
out.
There's
a
pretty
easy
proof
that
for
HTTP,
1.1
and
DNS,
you
can
guarantee
that
the
clear
text
if
the
initial
frames
are
distinct
from
one
another.
The
proof
is
in
the
draft,
but
you're
welcome
to
read,
but
you
can
distinguish
between
them.
Trivially.
Here's,
the
algorithm,
look
at
the
first
fourteen
octet.
K
If
any
of
them
are
in
this
range,
then
it's
DNS,
otherwise
its
HTTP
not
too
hard
easy
to
implement,
in
fact,
so
is
in
the
moment
that
even
I
could
implement
it.
It's
functional
it's
in
Debian
testing,
it's
running
on
that
server
that
I
announced.
So
this
is
just
an
attempt
to
get
people
thinking
this.
K
You
might
be
totally
horrified
by
it,
but
I
have
some
explicit
caveats.
So
it's
a
demultiplexing
port
TLS
connection,
not
per
query,
so
we're
not
going
to
interleave
DNS
n
HTTP
on
a
single
query.
It
only
works
when
you're
working
with
HTTP
1
one.
Fortunately
we
can
distinguish
between
1.1
and
http2,
based
on
the
ALP
n
on
the
server
side,
so
the
server
can
also
offer
HTTP
to
the
server
that
I've
got
up
there
right
now
is
not
offering
h2.
Although
I
plan
to
do
that,
and
so
the
AL
p.m.
K
will
be
multiplexed
between
1
1,
&,
2,
2
and
inside
the
packet
will
be
multiplex
HTTP
and
DNS
by
the
complicated
algorithm
I
just
showed
earlier
for
demultiplexing
with
eh
I,
actually
recommend
draft
Hoffmann
or
something
whatever
comes
out
of
draft
Hoffmann.
The
dope
work
I
think
would
be
the
way
to
go,
and
that
also
lets
you
do
on
a
single
on
a
single
TLS
connection.
You
can
do
the
multiple
you
can
do.
Multiplex
separate
queries,
so
this
is
not
an
in
any
way
an
attempt
to
override
that
I'm.
K
K
I
want
to
make
sure
that
if
this
gets
more
widely
deployed
because
hey
it
happens
to
already
be
available
in
Debian
that
we're
not
going
to
block
that
if
we
are
I
will
rip
it
out
of
Debbie
and
I,
don't
want
it
to
to
block
DNS
server
TCP
and
of
course,
if
you
try
to
combine
this
with
some
additional
multiplexing,
the
approaches
are
unclear.
So
that's
your
horrifying
idea
for
the
day
it's
functional.
M
K
Z
M
K
Agree:
that's
why
I
did
not
explicitly
did
not
ask
for
a
new,
a
LPN
choking,
because
that
would
defeat
the
purpose
of
right.
The
LPN
will
become
the
the
port
that
the
network
adversary
will
block
on.
So
my
point
here
my
demonstration
here
is
that
this
makes
DNS
over
TLS
indistinguishable
from
an
HTTP
1.1
client.
K
Is
not
it
count
the
in
competition
with
false
proposal
at
all,
so
this
is
a
demonstration
of
something
that
works
today.
That
is
functional,
which
is
not
the
case
for
pass
through
puzzle,
no
offence
Paul,
but
this
works
today,
it's
out
there
and
it
works
to
make
your
queries
indistinguishable
from
HTTP
1.1
queries.
Paul's
proposal
is
a
better
proposal.
It
will
work
better
for
h2.
It's
it's
demultiplexing
at
the
pull
request
layer
rather
than
perched
per
connection,
so
there's
all
kinds
of
reasons
to
prefer
Paul's
proposal,
except
for
the
fact
that
this
is
happening
and.
M
K
M
K
AA
AA
The
TLS,
which
is
another
concept,
called
server
name
indication
which,
despite
the
huge
work
by
Christian,
is
still
unencrypted
and
I,
can't
think
of
a
possible
tokens
in
the
surname
indication
in
this
use
case.
That
I
will
not
disclose
the
purpose
of
client
connecting
to
the
service,
and
your
draft
doesn't
tell
me
either,
but
that's
the
concept
of
hiding
the
server
name
in
this
case.
So
it.
K
Doesn't
have
the
server
name
if
you
were
to
use
the
server
that
I
have
set
up.
You
will
obviously
put
a
token
in
the
clear
text
of
the
TLS
connection,
which
is
DNS
CMR
Ginette
in
that
situation.
Obviously
a
network
attacker
could
filter
on
that.
If
you
are
someone
who
wants
to
offer
this
on,
your
own
website
say
a
normal
website
that
is
not
actually
dedicated
to
address.
Specifically.
K
This
is
one
that
I've
set
up
specifically,
but
if
you
put
it,
you
could
do
this
on
google.com
I'm,
not
saying
Google
is
going
to
do
it
I'm
sure
they
won't
do
it
in
fact,
but
my,
but
then
you
could
make
it
so
that
the
the
network
adversary
would
have
to
block
your
web
connections
as
well
as
DNS
connections.
If
they
wanted
to
do
that
which
I
suspect
most
network
adversaries
are
not
willing
to
do.
Q
K
I've
written
it
as
an
informational
draft
I
have
not
even
attempted
to
get
working
group
adoption,
although
I
would
be
interested
if
folks
have
some
suggestions
for
what
the
next
step
should
be.
I
wrote
it
down
to
document
what
I'm
doing
and
what
I
found
when
I
investigated
the
protocols
to
see
whether
they
were
distinguishable
and
I
wrote
the
code
to
demonstrate
that
it's
functional
so
I'm
putting
this
out
there
to
the
community
to
make
it
visible
that
this
is
something
that's
possible
and
something
that
can
be
done
on
today's
network.
R
R
K
R
R
Yes,
that's
what
and
so
right
now,
rather
than
picking
an
old
forest,
maybe
what
we
could
do
is
to
hide
it
inside
quick,
which
is
a
new
forest
that
is
going
to
be
growing
quite
quickly,
and
one
of
the
things
that
I've
been
looking
at
in
the
web
services
world
is
at
the
moment
we
layer
web
services
over
HTTP.
And
if
you
look
at
what
HTTP
does
for
the
average
web
service,
it
basically
does
one
thing,
and
that
is
expand
the
number
of
ports,
because
you've
got
instead
of
a
URI.
You
can
use
URI.
R
This
is
the
port
number
to
distinguish
between
web
services
are
the
same.
So
maybe,
if
we
were
to
work
out
some
way
of
systematically
expressing
that
in
quick
language,
we
could
get
two
things
at
once.
One
would
be
a
way
of
efficiently
dealing
with
these
web
services,
so
we
can
get
a
get
rid
of
this
HTTP
layer
which
actually
for
web
service,
isn't
doing
you
any
real
service,
and
then
things
like
this
hack
would
no
longer
be
a
hack
they'd
just
be
another
way
of
doing
it.
So
you'd
like
to
solve
lots
of
problems
at.
K
K
N
N
There's
a
an
SSH
and
HTTP
Luxor
which
works
I,
don't
know
if
you've
seen
it,
but
it's
also
in
Debian
I
use
it
on
my
server
for
the
same
reason,
which
is
this
sometimes
you
can
only
get
to
port
443
right
so
and
I
suspect
there
are
other
protocols
like
VPN
protocols
and
things
like
that,
which
may
may
do
similar
things
so
I
think
it's
I,
think
it's
a
reasonable
approach.
I
think
it's
a
good
idea.
N
I
think
it
make
I
think
either
just
for
shooting
with
yours
as
informational,
make
sense
or
if
you
want
to
maybe
looking
at
a
more
general
approach
for
this
kind
of
thing
for
other
protocols
as
well.
The
problem
with
that
is
that
probably
doesn't
belong
in
this
working
group
then,
and
how
many
protocols
do
you
do
and
how
general
do
you
make
yeah.
K
V
So
Martin
Thompson
I
appreciate
that
you've
taken
the
time
to
do
this
and
we're
having
this
discussion.
I
have
a
suggestion
for
next
steps
and
that
would
be
declare
victory.
I,
don't
think
we
need
to
publish
this
as
an
RFC.
You've
already
got
the
software
running.
It's
out
there
it's
available
to
people
with
they
want
to
do
it.
As
pointed
out,
there
are
other
things
that
do
similar
things
in
this
space
and
they
never
came
to
the
ITF
and
published
an
IRC
either.
It's
great
that's
thank
you.
Z
K
Z
K
Answer
that
question
specifically,
the
answer
is
existing
clients
do
not
need
to
be
modified
to
use
this
mechanism
well
sure,
which
is
existing
DNS
server.
Tos
clients
do
not
need
to
be
modified
to
just
to
do
this,
in
fact
that
there
are
client
pictures
that
I've
shown
you
here.
This
is
an
existing.
If
this
is
not.
Z
And
this
is
Chrome.
This
is
these
are
unpatched
clients
site,
but
then
you
create
an
incentive
to
perpetuate
the
use
of
those
legacy.
Clients
if
you
will
right
to
stay
on
an
h1
version
of
this
in
order
to
move
that
forward
and
like
I,
think,
that's
largely
my
concern.
We're
saying
this
like
motivates
the
other
work
to
specify
DNS
over
HTTP,
where
you
can
do
like
a
really
great
sort
of
mix
in
kind
of
application
of
this
I
think
that's
got
more
long-term
potential.
AB
Ever
saw
so
yes,
interesting
observation,
so
on
your
part
that
you
can
you
bucks
these
this
way,
I
guess
two
things
one
is
I
think
I
mentioned
yesterday.
This
circuit
does
depend
critical
people
willing
to
co-host
web
services
and
DNS.
Otherwise,
like
you
see
the
force
connection
and
it's
like
obviously
DNS,
and
they
just
block
that
s
and
I
heard
odd.
So
so
you
have
to
have
co-hosting
unless
you
disagree
in
terms
of
yes
in
terms
of
hiding.
This
is
the
the.
AB
Even
if
the
SSRI
is
innocuous
appearing,
if
they're,
if
they're
host,
only
does
this,
then
this
is
obvious
sure
right.
Okay,
the
same
thing
is
on
wall
I.
Do
appreciate
this
sort
of
the
observation
that
these
are
naturally
and
missed.
It
naturally
distinguishable
previous
times.
We've
taken
advantage
of
the
fact
that
two
protocols
happen
to
not
occupy
the
same
sort
of
initial
cocoa
space.
AB
We
were
extraordinarily
sorry,
and
so
it
turns
out
to
you,
know
a
handcuffs
number
of
them,
and
it
seems
that,
given
the
relatively
modest
deployment
at
present
of
DNS
over
TLS,
you
know
I
he
before
with
this.
It
might
be
nicer
to
have
some
prologue
that
you
committed
to
I'm,
not
saying
after
like
HTTP,
but
that,
like
the
first
eight
bytes,
be
something
which
is
it,
which
is
really
you're.
AB
AB
AB
In
this
working
group-
yes,
no
I
agree.
You
know
I'd
assumed
it
was
about
that's
how
this
idea
commune
forward
in
some
reasonable
way.
I'm
saying
doing
that,
like
other
people,
I
want
this
and
two
I,
just
sort
of
say
I
mean
if
you
really
think
it's
important
to
be
able
to
hide
stuff
under
relation
kohai
with
HTTP,
then
to
like
chew
up
all
that
amassing
space
for
like
this
web
protocol
is
very
annoying,
and
these
are
much
simpler
in
the
Box.
AB
When
you
say
all
this
D
muxing
space,
you're
saying
we
want
to
preserve
the
ability
to
D
mocks
other
protocols,
I'm
saying
to
you
what
you
think,
it's
a
good
idea
to
have
a
MUX
here,
then
why
is
it
only
ready
for
the
NHS?
He
was
good
at
your
table.
I
mean.
Are
you
aware
of
other
protocols
which
are
attempting
to
do
this?
AB
X
X
So
that
is
why
I
wrote
it
down
right.
So
I
actually
think
it's
great
that
you
wrote
it
down.
I'm,
appalled
that
this
is
actually
the
way
the
Internet
is
going
because
it's
the
right
answer
for
a
particular
use
case,
and
yet
it's
the
wrong
answer
for
the
network
architecture.
Yes,
and
fundamentally,
that's
the
problem
that
we're
facing
I,
don't
know
what
to
do
about
it,
but
I'm
terrified
at
the
prospect-
and
this
is
the
reason
that
I
got
off-
that
we
would
declare
it
as
a
victory.
It
really
is
Jenny
a
terrible
defeat.
K
Can
if
I
can
comment
on
that?
One
of
the
reasons
that
I've
written
this
down
is
to
document
that
this
is
a
functional
way
of
hiding
metadata
that
protects
against
a
network
adversary
and
if
we
do
not
continue
to
hide
metadata
in
our
protocols.
This
is
what
we
will
end
up
with
so
I
want
to
I
want
people
who
look
at
this
and
think
that
this
is
horrifying.
I
want
those
people
to
be
pushing
back
in
all
the
other
places
in
the
IETF,
where
we
are
planning
to
expose
metadata
in
our
protocols.
X
C
K
U
U
Yesterday,
we
we
had
a
dispatch,
we
had.
We
had
DMS
over
HTTP
in
in
dispatch,
and
there
was
a
lot
of
debate
about
whether
and
how
to
to
move
forward
with
Paulin
Patrick's
Draft.
There
I
think
this.
This
draft
can
serve
as
a
great
reminder
to
people
who
were
who
were
concerned
about
that
draft.
But
if
we
don't
move
forward
with
VMs
over
HTTP,
you
are
not
going
to
like
what
comes
instead.
R
There
is
actually
amongst
mechanism
in
HTTP,
in
that
we
invented
it
when
we
had
to
upgrade
from
HTTP,
not
0.9
to
HTTP
1
point,
and
that
is
HTTP.
Servers
are
actually
required
to
check
for
the
string,
HTTP,
slash,
1
point,
naught
or
1.1,
and
there
is
normative
language
that
actually
requires
them
to
reject
some
any
request.
That
does
not
have
that
string.
So
what
you
could
do
in
order
to
make
this
fully
consistent
would
be
to
simply
put
instead
of
it
being
get
/h
be
1.1.
R
M
The
christian
with
Emma
and
I
I've
been
listening
to
what
eco
and
and
who
are
saying
about
architecture
issues.
It
turns
out
that
we
have
many
points
of
multiplexing
in
the
current
architecture.
We
can
multiplex
by
port
number.
We
can
multiplex
by
LP
n
and
we
can
multiplex
inside
HTTP
using
the
world
own
mechanism
and
also
mechanism.
M
M
So
if
you
assume
that
we
can
hide
the
lb
n
using
any
of
the
s
ni
encryption
tricks,
then
you
get
a
clean
solution
there
that
basically
you
do
have
an
LPN
that
says
this
is
TNS,
and
then
you,
you
have
a
much
cleaner
hockey
texture
because
made
structure
because
it
does
a
high-level
point
of
multiplexing
and
so-
and
we
are
thinking
here
about
privacy.
We
are
pretty
much
hitting
that
point
here.
M
That's
basically
we
have
to
deal
with
privacy,
but
we
also
have
to
deal
with
censorship,
and
if
we
tend
to
ink
consideration,
maybe
what
we
want
to
do
is
work
on
the
TLS
protocol
uses
or
quake
for
that
matter.
That
says:
ok,
we
are
going
to
use
some
encrypted
token
to
do
the
D
mixing
and
we
can
do
that.
V
So
so
Martin
Thompson
and
you
do
have
to
modify
the
clients.
Unfortunately,
maybe
that's
not
what
I
got
to
say.
I
got
up
to
renege
on
my
statements
previously
after
listening
to
Andrew
I
think
I
was
insufficiently
facetious
in
my
original
comments,
I
was
I
meant
to
say
thank
you
for
your
contribution,
but
now
I'm
gonna
say
something
else
which
is.
This
is
perhaps
one
of
the
most
elaborate
threats
of
violence
to
the
architecture
that
I've
ever
seen
and
don't
like.
So
sorry,
the
opposite
of.
Thank
you.
Please
don't
do
this
ever
again.
V
C
Were
successful,
yeah
and
the
note
that
we
put
on
our
chairs
things
within
the
agenda
was
lie
again
right
like
what
you
know,
and
it
wasn't
so
much
like.
Oh
this
is
you
know,
I
want
to
be
able
to
sort
of
like
look
at
this
and
yes
be
like
shocked,
impressed
and
horrified
at
the
same
time,
right
and
I
think
people
got
too
excited
about
trying
to
solve
the
problem
rather
than
realizing.
C
There's
like
an
architectural
flaw
there
right
and
so
I
I
think
there's
some
interesting
stuff,
but
much
like
we
have
a
draft
Andina
software,
which
is
DNS
over
wider
format,
Y
format
over
in
HCP,
where
the
HCP
booking
people
said
this
won't
work
and
I'm
like
I've,
seen
running
code.
That
does
this.
This
doesn't
work
right,
which
is
should
horrify,
of
course,
HCP
people
right.
That's
why
there's
many
things
going
on
about
trying
to
resolve
these
kind
of
issues?
C
That's
the
wire
format,
the
one
that
vixy
and
oh,
no,
no,
they
were
no
I
had
some
pushback.
That
said,
they
didn't
think
it
would
work
it
would
it
would.
You
know
it.
David
I
think
it
was
a
little
bit
of
horrified
as
well
yeah,
so
and
I
think
that's
you
know
and
I
wasn't
saying
this
was
half-baked
in
a
bad
way,
because
I
have
many
half-baked
ideas
and
I
I.
Think
the
things
that
I
am
probably
flawed
for
us
are
working.
C
Pictures
I
will
accept
any
sort
of
crazy
idea
that
comes
through,
because
I
think
you
know
they
should
be
at
least
looked
at
and
sort
of
considered,
especially
if
there's
code
behind
it,
and
it
doesn't
mean
that
I
want
to
adopt
it
or
I.
Think
the
working
group
should
adopt
it.
But
it's
like
we.
You
know
we
should
at
least
you
know,
give
it
some
sort
of
thought
and
drive,
like
you
say,
drive
future
conversations
right.
Let's
make
sure
we
don't
make
these
kind
of
mistakes
moving
forward
kind
of
thing,
yeah.
F
B
Daniel
I'm
gonna,
add
one
more
thing
here
is
that
you
know,
as
a
researcher
I
really
get
tired
of
hearing
about
dark
data
that
nobody
can
get
our
access
to,
and
so,
if
you
think
that
pushing
it
forward
with
the
health
warning
on
it,
saying
look
what
I
did
but
don't
ever
do
it
then
I
think
we
can
work
with
with
someone
to
get
it
published.
Just
to
say,
don't
do
it.
C
K
Not
willing
to
publish
this
with
a
statement
that
says:
don't
do
this.
Okay,
I
am
quite
serious,
but
and
and
I
don't
like.
Let
me
also
be
clear.
This
is
not
my
threat
of
violence,
people,
the
threats
of
violence
are
the
network
operators
that
are
shutting
down
traffic
on
the
network
that
people
need
to
use
to
communicate,
potentially
in
some
cases
to
survive,
right
and
traffic
will
squeeze
through
whatever
remaining
ossified
tunnel.
We
allow
it
or
the
network
operators
allow
it.
K
So
this
is
a
document
that
says
if,
if
all
else
fails
fall
back
to
this,
because
you
need
to
get
your
DNS
responses
somehow
and
again,
you
need
to
be
able
to
get
them
privately.
So
I'm,
not
willing
to
say,
don't
do
this
as
long
as
the
network
operators
are
killing
traffic
that
they
don't
understand.
Okay,.
P
Q
M
Q
And
and
same
with
the
ICO
fatigue
speed
when
we,
when
we
talked
about
that
document,
they
also
said:
please
do
not
mention
even
port
four
four
three,
even
though
everybody
knows
you're
going
to
do
it
anyway
and
and
I,
don't
know
how
to
solve
this
and
ITF,
because
we're
basically
writing
specifications
that
say
read
between
the
lines
and
that's
really
bad,
but
but
yeah
I,
don't
know
how
to
do
this
better.
No,
it's
a
good
point
that.
C
Is
a
good
point?
Thank
you
Paul.
So,
okay,
thanks
I,
the
you
know,
we've
had
some
interesting
discussions
about
stuff,
that's
sort
of
not
in
our
Charter,
but
I
wanted
a
lot
of
the
smart
minds
in
the
room.
To
sort
of
you
know
give
some
thoughts
that
stuff
like
that.
That
Deena's
are
quick
and
you
know
Daniels
idea
that
you
know
for
better
or
for
worse.
You
know
it.
C
You
know
things
exist,
sort
of
thing
and
and
so
this
we're
sort
of
you
know-
and
maybe
we
need
at
the
time
because
people
wanted
to
sort
of
like
about
the
good
stuff.
But
where
do
we
go
from
here
right?
We
we've
got
working
implementations
Warren,
sent
some
slides
that
I've
uploaded
into
the
into
the
meeting
material
stuff
about
the
DNS
usage
and
I
would
say
the
TLS
stuff
is
pretty,
is
pretty
low,
and
so
it's
sad
as
I
would
say,
and
so
we
should.
You
know,
I,
guess,
here's
your
question.
C
We
should
be
deploying
the
TLS
and
games
or
each
other
who's
actually
like
sort
of
running
running
that
on
the
ITF
network.
Yeah.
It's
like
gold
stars
for
you
guys
and
okay,
so
so
yeah,
and
so
it's
sort
of
sort
of
sad
that
you
know
we
you
know.
As
our
group,
we
don't
have
a
larger
set
of
people
that
you
know
actually
deploying
something.
Sir.
L
People
that
precede
our
org,
which
the
website,
which
is
tracking
the
deployment
of
the
experimental
servers
in
the
wild
we
have
12
of
them.
Okay,
so
there
are
servers
out
there
that
are
running
this
and
that
site
has
information
about
where
they
are
how
to
authenticate
against
them.
We
have
some
monitoring
software
looking
at
the
status,
it
tells
you
whether
dink,
you
know
minimization.
L
L
C
C
I
think
getting
that
stuff
to
mature
is
much
like
being
home
net
and,
listening
to
the
discussions,
discussions
about
you
know,
try
and
deploy
agency
P
and
stuff
like
that
is,
is
the
more
people
that
do
it.
The
more
things
we
sort
of
iron
out
all
the
sort
of
the
things
so
become
something
very
simple
that
you
know
gets
stuck
in
distributions
rather
than
add-on
sort
of
thing.
L
V
N
C
Right,
you
know,
as
we
talk
about
the
next,
the
next
steps
right.
Do
we,
as
we
do.
You
know,
recursive
to
authoritative,
and
you
know
that
opens
up
a
big
can
of
worms.
I
think
the
first
thing
that
would
come
back
as
anybody
who
had
ran
any
sort
of
authority
have
sort
of
be
like
so
how's.
It
run
right.
You
know,
you
know,
I'm
a
very
simple
man
right,
I
live
in
a
world
of
a
lot
of
operations
and
stuff,
and
so
the
first
thing
I
think
of
is,
is
you
know
how
how's
that
stuff?
C
N
Based
on
this
requirement,
which
I
think
makes
sense,
we
have
whole
bunch
of
the
licious
requirements,
so
the
work
right
now
is
getting
DNS
over
TLS
pushed
into
the
components
that
we're
using,
which
we're
looking
at
and
we're
going
to
be
doing.
But
getting
software
changes
in
open
source
projects
and
things
like
that,
there's
kind
of
negotiation
that
has
to
occur
there.
These
things
don't
happen
overnight
once
they're
there,
even
if
all
the
software
components
supported
it,
we'd
still
have
a
month's
law.
N
Many
months
long
of
work
to
test
it
and
make
sure
that
we
have
our
processes
updated
and
things
like
that
so
and
I
think
we're
probably
ahead
of
the
curve
here.
So
I
think
looking
for
other
people
to
do
large-scale
adoption,
it's
going
to
take
a
long
time
and
I,
don't
think
we
should
wring
our
hands
too
much
about
saying
well,
no
one's
using
it
and
so
on
and
I
think
having
the
protocol
space
be
far
ahead
of
the
vendor
space
and
then
the
operator
space.
It's
not
weird,
and
that's
okay
and.
C
It
may
be
and
I'm
not
saying
we're,
wringing
your
hands,
but
you
know-
and
it
may
just
be
that
as
these
as
time
moves
on
quick
over
DNS
becomes
the
you
know
right.
You
know
something
that
people
sort
of
actually
fall
into
a
lot
faster,
because
the
the
the
software
stack
is
is
more
available
or
something
like.
C
L
So
one
thing
I
thought
might
be
worth
bringing
up
to
discuss
again.
Is
that
I
remember
in
previous
meetings
there
was
a
argument
that
just
said
we're
not
even
gonna
think
seriously
about
recursive,
authoritative
until
we
know
what's
going
on
with
this
until
we
have
data
and
I
think
I
want
to
challenge
that
as
well
and
say
you
know
this,
how
would
you
define
success
or
defeat
here,
and
how
would
you
really
take
those
input?
The
next
step
and.
C
It
wasn't
so
much
like
we're.
We
wanted
serious
data,
but
you
know
and
I
think
we
and
we
felt
that
we
should
be
able
to
start
moving
in
that
direction.
Knowing
and
I
think
when
we
think
about
authoritative,
I,
think
every
one
two
of
us
I
think
the
general
person
who's
got.
You
know,
who's
running,
second-level,
domains,
sort
of
thing
and
they've
got
servers,
running
stuff
and
then
you've
got
the
those
really.
You
know
there's
like
he.
C
You
know:
root
zone,
people
right
and
they're,
another
reality
right
and
and
to
actually
try
to
affect
change
on
that
level
becomes
a
layer,
nine
type
issue
right,
that's
sort
of
really
out
of
our
pay
grade
sort
of
thing.
So
you
know
just
one
thing,
but
no
I
think
we
should
be
able
to
start
thinking
about
it,
but
just
realizing
that
I'm
sure
that
will
be
sort
of
the
discussions
that
will
sort
of
come
up
along
the
way
right.
C
U
Ben
Schwartz
I'm
somebody
who
cares
a
lot
about
the
client
side
of
this
I'm
trying
to
put
work
into
that.
But
you
know:
there's
a
there's
a
time
delay
measured
in
years
from
from,
like
approval
to
do
to
make
some
client
change
even
from
code
is
committed
to
like
substantial
fraction
of
users.
Have
the
code
never
mind
are
in
a
configuration
where
they
can
actually
use
it.
U
C
I,
don't
know,
I,
don't
actually
feel
it's
a
failure
at
all.
I
think
it's
it's
it's
a
very
I
think
is
a
very
solid
basis
for
us
to
sort
of
move
forward
and
I.
You
know
I'm
just
it's
it's.
He
said
it
takes
a
while
right.
So
it's
like
how
can
are
there
things
that
we
can
do
to
sort
of
help
sort
of
prime
that
pump
in
some
ways
you
know,
and
then
you
know,
as
we
sort
of
and
then
and
part
of
that
discussion
day
was
seeing
Oh.
C
I
You're
not
offering
any
public
Els
with
the
necessary
creative
servers.
We
I
don't
have
actual
measurement
data.
However,
what
I
did
recently
was
I
took
the
packet
traces
from
one
of
our
authoritative
servers
and
ran
it
through
a
simulation
to
identify
what
like
the
approximate
cost
of
running
TLS,
so
I
tried.
There
were.
I
Estimate
in
there
so
what's
the
deal
s
session,
setup,
cost
and
so
on
and
so
forth
and
I
came
up
with
the
magic
number
eight
yeah,
which
means
that
running
100%
of
the
DNS
traffic
and
all
the
authoritative
servers
that
currently
reaches
us
over
UDP,
which
require
about
eight
times
as
much
resources
as
it
currently
does.
So
that's
like
a
way
it
could
be
like
three,
it
might
be.
25
I
have
no
idea.
I
did
a
couple
of
assumptions,
but
it
sounds
reasonable.
Hi
me
hi
and
it's
just
a
simulation.
Oh
God.
L
C
In
a
previous
life,
I
do
I
teach
a
cheapy
performance
stuff
and
you
know
there's
a
lot
of
work
in
that
space
right
like
how
to
scale
TCP.
You
know
I
think
those
folks
have
done.
You
know
pretty
fantastic
work
on
that.
So
I
think
you
know
there's
a
lot
of
places.
We
can
sort
of
you
know
lead
on
their
expertise
in
that
regard,
but
and
I
think
yeah.
It's
an
interesting
number
I,
don't
know
if
it's
that
high,
but
yeah.
V
Y
Just
say
anyone
measuring
the
importance
of
measuring
and
doing
the
experimentation
on
what
is
being
deployed
is
for
the
data
points
for
that
next
question:
I,
don't
want
to
walk
into
that
next
question
blind,
because
that
would
be
painful.
Then
we're
going
to
have
a
world
of
bad
idea
fairies
in
a
really
long,
knocking
yes,.
N
Come
so
think
it's
this
is
Shane
again.
Shanker
is
I.
Think
it
interesting
that
there
was
some
estimates
of
performance
cost
on
the
authoritative
side.
I
think
we
saw
some
earlier
estimates
of
just
TCP
alone
being
a
factor
of
six.
So
a
factor
of
eight
for
open
TLS
doesn't
surprise.
Me
I
think
we
need
to
be
a
bit
careful
about
that,
because
we
know
that
current
dns
authorities
infrastructure
is
heavily
over
built
to
handle
DDoS
attacks
and
things
like
that
and
a
lot
of
that
cost
comes
from
UDP.
N
C
C
C
H
Dan
york,
just
as
may
not
as
Chaves
cried,
I
I
would
just
echo
their
comments
over
here.
I
mean
whether
these
have
anything
to
do
with
the
Charter
or
anything.
The
measurements
of
this
are
important,
because
I
spent
a
good
chunk
of
my
time
in
the
work
of
deploying
the
protocols
that
are
here,
and
this
kind
of
measurements
of
any
form
help
make
the
case
for
those
things
to
be
used
and.
H
We
all
want
the
stuff
we
do
here
to
be
deployed
out
there
in
the
real
world,
so
you
know
in
the
regular
networks
that
are
out
there,
so
this
kind
of
Statistics
any
kind
of
information
can
help
with
this
and
I
think
the
work
that
Sara
and
the
folks
are
doing.
That
is
a
great
step
in
that
regard
and
I
think
if
anyone
else
can
duplicate
that
or
or
provide
not
duplicate,
provide
other
measurements
of
that.
That
would
be
ideal
or.
C
H
L
I
L
I
just
wanted
to
qualify
what
I
said
earlier,
I
completely
accept.
We
need
the
measurements
and
they're
going
to
inform
what
we
do.
My
feeling
is
that
there
are
other
problems
we
can
solve,
that
aren't
related
to
this,
the
measurements
and
the
you
know
the
idea
of
performance
about
the
recursive
to
authoritative,
step,
and
we
kind
of
stopped
work
on
everything.
Yes,
so
questions
of
how
we
do
or
sent
occation
on
that
like
we're,
not
looking
at
them
and
that's
disjoint
from
the
field
exactly.
C
And
I
don't
want
to
stop
that
discussion.
It's
like
I
was
hoping
before
the
deadlines.
If
I
would
sort
of
resubmit
is
step
to
document
just
so
we
have
sort
of
a
place
to
sort
of
start
that
conversation
and
I'm
not
going
to
call
you
out
or
anything
like
that.
I'm
sorry,
you
know
I
know
you're
busy
so
but
I
thought
that
was
a
really
good
place
to
sort
of
start.
Some
of
that
discussion,
but
you're
right
there
are
places
in
terms
of
how
do
we
do
the
authentication?
C
How
do
we
do
various
places
like
that?
That
I
think
we
should
start
digging
into
yeah?
So
how
do
we?
You
know
I
wanted
to
see
if
there
is
actually
still
interesting
and
people
sort
of
going
after
that
or
you
know,
are
they
just
going
to
take
a
flag
in
the
ground
and
say
you
know,
let's
do
tkg's
ID
match
the
idea
and
be
done
with
it
kind
of
thing.
So.
E
Speaking
about
the
step
to
do
after,
indeed,
it
expired,
partly
because
of
other
things
to
do,
but
partly
also
because
I
was,
in
my
opinion,
very
little
discussion
about
it.
I
expected
the
discussion
was
strong
opinions
and
have
been
very
few.
Maybe
one
of
the
reasons
that
step
to
draft
was
careful
not
to
mandate
or
to
make
specific
techniques
over
it,
so
the
listing
of
other
possible
solutions
with
some
pros
and
cons,
but
not
so
maybe
a
better
solution.
K
C
So
yeah-
and
there
was
a
fair
bit
of
discussion
initially
Stephan
on
your
draft,
but
maybe
you're
right.
You
know,
maybe
if
he
just
picked
some
outlandish
idea
and
saying
this
is
what
we're
gonna
do.
That
will
really
get
discussion
going
right
because
then
people
will
be
like.
Oh,
this
is
crazy,
so
but
you're
right
and
I
mean
and
I
do
think.
There's
places
to
go
I
just
what
I
just
wanted
to
I
guess
I
was
sort
of
cautioning
about
was
you
know
we
want
to
sort
of
measure.
C
C
C
Okay,
so
I
know,
of
course,
I
sort
of
wouldn't
let
my
co-chair
talk
so
I
apologize
for
that.
So
they
know
Brian
seems
very,
very
much
at
peace
right
now,
yeah.
So,
okay,
that's
you
know.
If
that's
the
thing
I
think
you
know
it
sounds
like
Stefan
is
gonna,
probably
think
about
a
step
to
draft.
Then
you've
got
a
few
people
that
seem
interested
in
working
with
you,
I
see
Sarah
and
I
see
TKG
so
that
you
know,
if
others
want
to,
please
you
know
reach
out
to
him.
C
You
know
he's
Stefan,
you
know
he's
very
easy
to
work
with
so
have
no
problems
there,
though.
Okay
any
last
words
from
anybody.
Oh
I
have
more
slides,
I
uploaded
them
into
the
meeting
materials
and
mostly
they
were
showing
sort
of
DNS
usage
of
the
of
the
network
and
also
the
TLS
usage
and
the
TLS
usage
was
very.
It
was
very
low,
is
very
sad.
C
As
I
said
you
know,
there's
you
know
so,
but
not
zero,
so
you
know
at
least
or
some
usage
and
hopefully
by
the
other
week,
we'll
simply
get
a
little
bit
more
going
out
of
it.
Sort
of
thing,
though,
all
right,
thank
you
all
for
coming.
Thank
you
all
for
listening
to
all
the
crazy
ideas,
and
so
I
always
appreciate
that.
So.