►
From YouTube: IETF102-TLS-20180719-1810
Description
TLS meeting session at IETF102
2018/07/19 1810
https://datatracker.ietf.org/meeting/102/proceedings/
A
Welcome
to
the
part
2
of
TOS
at
IET,
one
or
two,
and
you
probably
have
all
seen
this
know.
Well,
I'll
put
it
up
real
briefly
here,
so
you
can
peruse
it,
but
now
move
on
to
agenda
for
today,
I
think
there
were
a
couple
things
we
wanted
to
to
start
with.
One
is
that
we
did
have
a
side
meeting
this
week
on
the
DNS
SEC
chain,
extension
and
I
think
it
was
a
productive
meeting.
A
So
David
Benjamin
was
kind
enough
to
publish
a
new
version
of
the
TLS
Greece
draft
and
I
guess.
What
we're
going
to
do
is
try
to
just
go
directly
to
the
horse's
mouth.
Anger
talks,
the
IANA
people
I'm
gonna.
Do
that
to
try
to
make
sure
that
the
instructions
are
clear
enough
for
them
to
understand
what
we're
trying
to
do
so
that
we
could
actually
get
this
stuff
implemented
and
I
think
that
out
not
be
hard,
because
they're
here
and
I've
been
talking
with
them
about
lots
of
other
ion
a
registry
related
things.
C
All
right
so
before
we
get
into
the
main
talks,
does
anyone
know
the
agenda?
One
quick,
quick
thing
to
note:
Richard
Barnes
didn't
send
an
update
to
the
pig
draft
that
is
not
reflected
in
this
agenda,
so
he
will
have
five
minutes
before
to
take
a
request
sought,
but
anything
other
than
that.
Please
come
up
now.
C
Eric.
Is
this
on
bengi
duck,
so
you
with
no
hats
on
there's
a
questions
come
up
about
the
reuse
of
PSK,
t-shirt,
keys
between
TLS,
1,
2
and
T,
1,
3
and
sort
of
my
intuition
is
that
if
you
have
an
existing
PSK
using
for
TLS
one
two,
you
don't
necessarily
want
to
just
drop
that
into
TLS
1/3
the
different
key
schedule-
and
you
know
from
the
graphic
point
of
view-
I,
don't
know
that.
C
There's
any
real
value
in
us
talking
about
that
today,
but
I
do
think
that
if
we
decide
you
don't
want
to
do
if
we
decided
you
should
not
do
that.
We
might
want
to
have
some
text
about
that
in
the
TLS
1/3
document,
which
is
potentially
done
in
timescale
of
weeks.
So
if
you
do
feel
like
you're
qualified
to
have
your
cryptographic
opinion
on,
does
this
actually
matter?
Please
think
about
that
and
most
of
lists.
This
is
sort
of
related
to
the
the
topic
that
measurement
I
brought
up
about
the
universal
PDS
case.
D
C
C
The
executive
summary
is
that
the
the
crippled
epic
analyses
of
1
3
basically
assumed
that
any
PSK
is
only
used
at
the
single
key
generation
function
on
now.
Am
I
aware
of
any
actual
problem?
If
you
don't
do
this?
No,
but
basically
the
corners
are
like
all
one
make
any
guarantees
you've
ever
if
you
ever
mix
and
match
different
key
generation
functions
so
like
I'm
not
aware
of
any
reasonably,
this
is
actually
a
problem,
but
that's
that's
was
ground.
A
David
Benjamin
just
to
add
to
that
briefly,
the
the
reason
the
certificates
are
ok
to
be
reused
is
because
we
in
the
certificate
verify.
Oh,
we
can
I'm
sorry
to
the
Benjamin.
To
add
to
that
the
reason
the
certificates
are
ok
to
be
reused,
as
is,
is
because
we
explicitly
add
the
contact
string
in
the
protocol.
Has
the
64
spaces
to
call
the
client
random.
So
that's,
where
are
the
certificates
are
safe
to
use
between
the
two?
Well
PSK
does
not
immediately
hug
but
I
feel
it's.
A
C
C
Okay
and
the
subsequent
handshakes
are
based
on
the
resumption,
PSK
or
a
combination
of
the
resumption
PSK,
and
an
additional
difficulty
result
next
slide.
What
I'm
proposing
is
that
we
add
an
additional
option
to
the
initial
handshake
that
lets.
You
include
an
external
PSK
and
combine
it
with
the
diffie-hellman
result
next
on
it,
and
the
reason
I
would
like
to
do.
This
is
a
contradiction
just
in
case
that
quantum
computer
comes
to
pass.
C
C
C
C
So
a
few
thoughts
about
the
external
PSK
is
basically
a
group
that
need
to
be
a
group
of
entities
that
are
doing
TLS
would
need
to
get
a
hold
of
these
PS
KS
pairwise
PS
caves
between
everyone
that
might
be
communicating.
It
was
not
feasible.
That
would
recreate
all
the
key
management
problems,
but
the
idea
is
that
if
the
quantum
computer
comes
to
pass.
C
Have
to
get
both
of
the
values
you'd
have
to
compromise
one
of
the
members
of
the
group
at
the
PSK,
in
addition
to
getting
above
the
thing
yet
to
be
invented,
this
quantum
computer,
and
so
for
that
reason
the
external
PS
caves
will
be
more
suitable
for
some
applications
than
others,
but
let's
protect
the
ones
that
you
need
it
Anana
next
one.
So
the
ask
is
that
the
working
group
adopt
this
as
a
work
item
and
their
questions.
C
Question,
but
were
you
freezing
the
semantics
or
will
add
in
it?
An
external
Pierce
case
already
can
be
missing
if
you
haven't
and
that's
the
way
up
this
case
working
to
m13.
If
there's
diffie-hellman
you
involved,
so
the
semantics
it
seems
like
you're
saying,
is
not
not
anticipating
it's
not
to
curing
around
sort
of
a
this
is
instead
of
instead
of
bypassing
this
it
is.
I
would
like
you
to
send
a
service
an
inch
or
even
though
you're
doing
PSK.
That's
the
semantics.
I
think
that
is
relevant
here.
C
B
F
C
G
F
C
C
C
I
think
I,
don't
know,
there's
a
process
matter
where
we
should
be
but
like
before.
We
got
very
far
with
this.
I
want
to
see
a
formal
analysis
with
we're
sure
this
is
okay,
sure,
but
it's
my
belief
as
well
that
that
was
fixed,
Martin,
Thompson
I
think
you've
specifically
excluded
the
one
use
case
that
I
actually
care
about.
You.
C
Saying
that
you
wouldn't
allow
this
with
resumption
previous
case
I,
don't
think
the
distinction
is
actually
useful.
Yeah
I
think
at
this
point,
when
you,
when
you
complete
the
handshake
and
you
have
both
the
PSK
and
the
certificate
you
make
an
assessment
of
whether
or
not
to
continue
with
it.
That
was
that
that's
a
useful
property
to
mother
mind,
particularly
because,
if
you
call
I
wrote
a
draft
very
long
time
ago,
but
sort
of
the
middle
of
the
design
process
where.
F
C
Concern
was
that
there
was
no
fresh
proof
of
ownership
of
the
server
certificate.
If
you
have
a
long
series
of
resumption,
x'
and
clients
that
are
using
zero,
RCT
would
be
presented
with
a
trade
off.
They
would
mm-hmm
have
to
choose
between
0
82
or
bring
up
being
on
a
certificate,
and
if
you
were
able
to
combine
the
two.
F
C
E
C
A
C
A
C
So
you're
saying
you're,
supportive,
yes,
okay,
okay,
real
quick,
because
we're
kind
of
short
on
time
there
seem
to
be
some
people
who
are
in
favor
and
I
can't
get
a
show
of
hands.
Who's
actually
read
the
draft,
so
a
number
of
hands,
potentially,
you
know,
continue
discussing
on
the
list
and
then
maybe
next
time
we
call
for
adoption
if
you'd
like.
So
how
about.
When
you
start
a
call
for
adoption,
and
all
these
comments
will
come
out,
there
were
charming
all
right.
C
C
We
have
a
similar,
enlightening
talk,
shapes
I
talked
about
this
at
the
last
night's
yeah
and
produced
a
new
road.
This
slide
is
the
same
as
the
last
time.
Motivation
is
the
same.
Sometimes
you
need
a
password
that
doesn't
have
much
entropy
and
you
need
to
use
it
safely.
The
difference
between
last
time
is
we
published
a
row
of
our
draft
mid-cycle
this
time
which
contain.
C
Type
of
that
we
fixed
earlier
this
week,
but
what
that
does?
We
originally
proposed
binding
this
mechanism
specifically
to
a
spec
2,
and
the
new
draft
has
a
generic
big
container.
So
it's
got
basically
a
blanket.
You
know
put
whatever
you
want
here.
Extension
in
the
client
alone,
server,
hello,
that
any
any
given
paid
protocol
can
put
messages
in
provided.
F
C
The
finished
messages
provide
a
sufficient
key
confirmation.
The
other
thing
that
graph
does
is
say
when
you
get
a
symmetric
secret
out
of
this
pay
protocol.
Here's
where
you
put
it
in
the
key
schedule,
so
it's
pretty
general.
It
has
a
general
framework
and
it
has
a
realization
of
it
in
particular,
for
us
big
tube,
been
talking
with
you
guys,
I'm
about
doing
this
opaque
as
well,
so
that
nature
often
later
growth.
C
So
like
I
said
since
last
time
we
got
some
feedback
on
the
list
about
other
pigs.
People
are
interested
in
dragonfly,
we'll
pick
a
couple
more
more,
and
so
that
led
us
to
refactor
into
this
general
on
general
framework.
So
we've
still
got
a
couple
of
open
questions.
For
instance,
do
we
need
to
protect
the
identities
that
we're
sending
on
right
now?
The
first
message,
the
client,
hello,
first
message
in
the
cryo
has
to
specify
what
password
you're
talking
about
the
virtue
is
the
identity
and
there's
no
mechanism
right
now
to
protect
that.
C
Come
to
this
question
as
to
whether
you
know
we're
not
to
try
and
do
some
hello,
retry
requests
dance
to
do
identity
protection.
Similarly,
right
now,
there's
no
mechanism
to
negotiate
which
pic
you're
going
to
use
on
a
given
session.
There's
an
assumption.
That's
each!
When
you
pre
configure
the
password.
You
also
pre-configured
what
paint
you're
going
to
use
it
with.
So
you
know
I
say
what
I'm
using
a
password
one,
two
three
four
five.
C
To
use
that
with
opaque,
because
there's
there's
this
preset
up,
that's
assumed
between
the
client
server.
Now
that
may
not
always
be
the
case,
for
instance,
if
you're
just
typing
a
password
in
some
client,
it
might
need
to
discover
from
the
server
what
take
it
should
use
that
with,
and
so
there
might
again
need
to
be
some
hello.
A
C
C
G
C
Pushing
on
this
particular
thing
in
this
particular
moment
is
that
the
history
history
of
Pakes
in
TLS
has
been
like
a
long
efforts.
Bennett
and
it's
been
very
well
first
been
implementing
them,
and
so,
like
I'm,
not
opposed
to
this,
it
was
gonna,
be
is
gonna,
be
uptake,
but
I
want
to
make
sure
like
the
update.
A
C
A
C
So
so,
to
be
clear:
I'm
not
here,
because
I
have
an
academic
interest
in
cakes
I'm
here,
because
I
had
some
product
requests
for
people
who
needed
something
of
this
general
form
how
they
use
case
where
they
could
only
provision
the
line
should
be
secrets,
and
so
any
we
would
be
pushing
it
put
it
in
some
products.
Yeah
okay,
I
mean
generally.
C
All
right
so
which
are
not
all
for
this
presentation
and
we
really
snappy
because
we're
kind
of
short
behind
on
time.
This
is
something
we
bred
the
holistic,
while
back
I.
Think
in
April
take
a
request.
You
might
be
able
to
wager
what
that
means
so
get
right
into
it.
The
basic
problem
that
we
ran
into
is
that
service
generally,
just
when
you
a
fixed
number
of
tickets
upon
connection,
so
in
the
case
of
boring
itself,
for
example,
they
just
made
two
incentives.
C
You
each
time,
but
potentially,
if
your
university
in
connections
using
happy,
eyeballs
beat
you
and
you
or
you
want
to
open
up
your
connections
using.
You
know
resumption
more
than
one
more
than
two
tickets
or
you
want
to
do
some
kind
of
connection
for
anything.
You
may
want
to
get
more
tickets,
but
then
again,
if
you've
ended
more
tickets,
you
don't
use
them
all
you.
They
can
just
go
to
waste.
So
it'd
be
nice.
C
If
you
had
a
way
to
sort
of
explicitly
say
how
many
tickets
you
need
for
your
particular
use
case,
and
so
the
requests
we
outline
in
the
document
is
basically
the
requester
starts
protocol
post
handshake
as
a
post
and
check
message
where
clients
will
signal
support
for
this
particular
type
of
eccentric
message
and
servers
who
support
as
well,
though,
minting
a
new
new
session
tickets
until
white
then
later
asked
for
warmed
up
eccentric
message
and
a
request
and
the
request
cards
identifier.
It's
multiple
contacts
and
some
extensions
that
you
know
could
be
filled
in
later.
C
Pretty
straightforward
and
alternative
design
we
considered
was
basically
expressing
in
the
new
extension
how
many
tickets
you
might
need
up
front
and
then
server
doesn't
have
to
I
guess
in
your
way.
You
can
just
send,
however
many
watts
or
the
minimum
of
what
the
client
requests
anyway,
when
it's
going
to
VIN.
So
if
I,
you
know
asked
for
a
thousand
tickets
and
the
server's
willing
willing
to
then
for
then
it
would
then
for
and
I
you
know
that's
the
best
we
can
do
in
this
particular
case.
I
mean
this
is
sort
of
nice.
C
In
that
it
avoids
having,
to
you
doing,
add
any
more
posts
and
check
messages
which
can
be
quite
nasty
depending
on
your
implementational
actually
choose
to
go
for
doing
this,
but
it
doesn't
allow
for
dynamic
lending
of
tickets.
I
mean,
of
course
you
could
do
various
hacks
like
opening
up
a
connection
getting
four
tickets
and
then
repeating
that
over
and
over
again
it.
You
know,
it's
been
your
pull
the
tickets,
but
this
is
pretty
static
in
that
sense,
again,
you
tell
you
this
particular
mechanism
dependent
on
you
in
the
use
case.
C
So
if,
for
example,
we
clients
will
never
ask
for
more
than
four
tickets,
why
don't
servers
just
are
pending
for
tickets
all
the
time
instead
of
two,
and
then
we
can
just
call
it
a
and
go
home
and
make
any
changes
over,
as
I
was
saying
that
it
would
be
nice
if
we
could
kind
of
avoid.
You
know,
in
the
connection
between
use
case
where
you
might
want
to
just
build
up
a
pool
tickets
and
use
them
to
vend
out
the
other
process
needs
to
sort
of
connections
very
quickly.
C
C
That's
pretty
much
it.
There
were
some
comments
in
the
list
about
this
I
think
it's
pretty
simple
approach
and
interested.
If
anyone
else
is
in
favor
of
this
particular
lady
or
finds
it
pleasing
or
displeasing
I,
have
you
make
an
excellent
cloth
or
have
you
considered
making
this
an
exporter
in
some
way,
I'll
be
able
to
export
these
having
a
post
handshake
messages,
as
you
mentioned,
is,
is
pretty
tricky
in
a
bunch
of
implementations.
C
A
So
I
guess
I'm
going
to
say
something
which
suggests
exporters
but
I
feel
really
bad.
Making
just
tickets
exporting
so
I'm,
not
sure
what
the
answer
is.
But
so
one
thing
we
ran
into
with
the
key
update
message
was
that
so
suppose
you
have
your
read
stream
is
going
much
faster
than
your
right
stream,
like
you're,
going
over
TCP
and
the
other
side
is
just
not
reading
we're
not
reading
from
you.
A
So
your
right
is
backed
up
or
like
the
net
they're
down
like
it's
just
slower
whatever,
but
they're
sending
you
lots
of
ticket
requests,
you
can
sort
of
grow,
an
unbounded
number
of
ticket
requests
and
then
yeah.
That's
somewhat
awkward
for
DRS
reasons.
Things
like
HTTP
to
tend
to
solve
this
by
saying,
like
okay,
well,
you're
only
allowed
to
have
so
many
open
streams
at
a
time
and
like
the
HP
two
layer
knows
what
that
means
and
can
deal
with
it.
A
But
since
the
terrace
layer
tends
to
be
kind
of
this
dumb
pipe
things
where
stuff
builds
up
can
be
a
little
bit
awkward.
I
guess
one
obvious
answer
is
we
should
just
say
that
you're
not
allowed
to
have
more
than
like
seven
open
ticket
requests
that
time,
but
it
feels
kind
of
weird
and
arbitrary,
so
I'm
not
sure
what
to
do
about
this
sort
of
thing.
Yeah.
C
That
was
sort
of
the
nastiness
I
was
referring
to
really
would
be.
You
know,
potentially
avoiding
the
post
to
inject
message
and
just
shoving
it.
You
know
the
actual
number
of
tickets.
You
want,
and
you
know
the
client,
hello
extension
and
then
not
dealing
with
any
kind
of
course,
entry
message
so
I
mean
deem
a
that.
That
may
be
the
better
approach.
If
you
consider
this
particular
communication,
both
being
nasty
rich
yeah.
A
C
Tell
me
tell
me,
probably
so,
just
echoing
what
you
said,
I
think
I
want
to
re-emphasize
that
we
don't
want
a
solution
but
relies
on
http/2
or
a
higher
layer.
It's
we're
going
to
have
just
for
royalty,
less
rooms
or
any
random
application
without
having
to
extend
them.
I
agree
that
that
point
about
the
problems
that
can
happen
with
building
up
requests
is
pretty
bad,
so
I
think
that
makes
a
pretty
good
argument
for
including
them
just
in
the
initial.
C
A
E
C
A
Another
thing
that
occurred
to
me
we
haven't
actually
like
played
with
us,
to
see
if
this
works
out,
but
it
did
Kurtis
at
some
point.
But
if
I
said
my
game,
but
actually
even
if
you
need
say,
like
20
tickets,
because
you
make
20
tickets
in
parallel,
it's
not
obviously
wrong
to
send
only
even
one,
because
so
you're
the
number
of
tickets
you
want
is
like,
like
the
amount
of
like
parallelism,
you
have
in
your
connections.
If
you
make
20
connections
but
they're,
all
one
after
another,
one
ticket
is
just
wrong.
Correct.
F
C
Mean
potentially
I
mean
I.
Think
the
utility
like
I
said,
depends
upon
how
your
racing
things
and
how
quickly
you're
depleting
your
pool,
so
I
mean
you
could
start
by
racing
10
and
then
getting
10
and
then
just
continually
going
from
there
forward.
Every
time
your
resume
gets
them
or
forget
one
more
and
then
just
kind
of
march
forward
in
time.
Perhaps
a
misunderstanding:
a
particular
comment
looks
like
Ben's
gonna
get
up,
I,
don't
know
if
we
have
time.
Sadly,
yeah
I.
A
C
So
unfortunately,
we're
kind
of
running
short
time,
so
there
will
be
some
potentially
controversial
things
in
here,
especially
really
the
DNS.
So
please
ask
if
you
have
question
related
units
record
format
or
anything,
please
hold
them
to
the
end,
so
we
can
kind
of
get
through
the
TLS
bits
and
then
discuss
that
later
for
position
on
the
list.
So
getting
right
into
this
thing's,
pretty
clear
that
this
is
in
the
scope
of
the
working
group.
C
I
mean
we
want
to,
as
the
text
says,
basically
encrypt
as
much
as
possible
and
protect
against
massive
active
attacks,
and
yes
and
I
is
something
it's
in
the
clear:
let's
wrap
it
up
so
with
the
development
of
TLS
1.3,
we
should
do
pretty
well
in
that
respect.
Most
the
server
extensions
are
now
encrypted
everything
pretty
much
have
to
keep
share
and
stuff,
that's
it
encrypted
inside
with
the
extensions
or
certificate
and
the
client
certificate
or
both
encrypted.
Fortunately,
the
client
extensions
in
this
particular
context.
Yes
and
I.
C
So,
if
you're
doing
with
a
passive
attacker
who
just
wants
to
sort
of
surveil
you
and
learn
out
where
you're
going
hiding
this
and
is
certainly
a
good
thing,
I
wager
if
you're
dealing
with
an
active
attacker
who's
trying
to
censor
you
based
on
your
s
and
I,
basically
cut
off
active
connection
to
a
website.
This
is
also
a
good
thing.
I
mean
there's
little
asterisk
there
in
that
particular
detail.
C
Regards
to
sticking
out
put
just
move
right
along
so
there's
many
different
sources
of
survivability
leakage
which
the
s
and
I
you
know
presumably
had
that
indicates.
The
first,
of
course,
is
DNS
resolution.
The
first
thing
you
do
before
you
serve
a
connection
is
actually
just
go
talk
to
DNS
and
reveal
to
the
world
exactly
what
you're
after
and
there's
a
yes
and
I
itself.
C
Theirs
was
the
server
certificate
back
in
the
day,
there
is
the
server
IP
address,
which
may
or
may
not
be
unique,
depending
on
your
deployment
strategy
and
how
your
application,
it's
actually
hosted,
and
then
a
huge
whopping
bucket
of
traffic
analysis
and
what
you
can
do
to
learn
where
you're
going
and
what
who
you're
talking
to
so
many
things.
Fortunately,
IETF
have
kind
of
plugged
with
these
holes,
so
the
work
in
the
deeper
Ivan,
doe
group
working
groups
have
sort
of
you
know,
made
DNS
resolution
private.
C
You
know,
of
course,
module
traffic
analysis
and
so
on
and
so
forth.
This
particular
draft
is
again,
as
the
title
suggests,
interested
in
plugging
me.
Sni
whole
the
server
certificate
was
handled
by
TOS
1.3.
Thank
you
guys.
The
server
IP
address
handled
by
CBN's
multi
turning
I
asked
right
there,
because
you
know
it
might
be
the
case
that
particular
applications
are
given
a
dedicated
IP,
in
which
case
the
IP
just
reveals
exactly
to
where
you're
going,
but
there's
work
on
that
area
as
well.
C
Unfortunately,
this
is
still
subject
to
traffic
analysis
and
like
much
the
internet
so
can't
fix
all
the
world's
problems.
At
once,
and
as
a
working
group,
we
spend
a
lot
of
time
in
this
particular
issue,
going
back
pretty
much
the
surveillance
1.3.
There
has
been
many
different
proposals.
Many
different
injures
address.
If
you
were
to
go
through
the
archives-
and
we
have
spent
a
lot
of
time
trying
to
actually
nail
down
what
the
problems
they
would
be,
what
the
requirements
should
be
pointed
to
the
sni
encryption
draft
from
christian.
C
We
can't,
unfortunately,
could
be
here
today
and
Eric,
and
this
draft
they
recently
turned
in
to
propose
solutions
to
these
are
the
requirements
for
S&I
encryption,
and
you
know
how
you
should
assess
a
particular
solution.
So
we
try
to
take
care
to
assess
our
particular
design
in
the
context
of
this,
this
draft
and
its
requirements,
and
back
in
the
day
before
we
had
Dolan,
DNS
or
privacy.
We
basically
you
know,
decided
that
this
was
a
really
hard
problem
to
solve,
because
there
are
so
many
different
informations
or
multiple
ways
that
this
information
get
out.
C
So
you
know
I,
don't
want
to
say
why
bother,
but
it
was.
It
was
a
hard
thing
at
the
time.
Unfortunately,
that's
changed.
Now
we
have
Dina's,
we
have
been
at
privacy,
we
have
dough
and
if
you
have
massive,
you
know
CDN
servers
that
are
our
CDN
infrastructure
that
are
also
providing
you
with
your
TR,
your
trusted,
recursive
resolver
and
giving
you
do
functionality
who
also
happened
to
control
the
DNS
records
of
their
clients,
their
origin
servers.
C
They
could
flip
a
switch
and
turn
on
encrypted
s
and
I
for
all
their
origin,
applications
or
all
their
origin
sites
that
they
support,
so
they
mastery
configure
all
their
domains
and
then
pretty
much.
Everyone
belongs.
That
anonyme
said
you
know
benefits
from
this
particular
design,
carried
again
that,
depending
on
how
you
you
know,
assign
keys
in
particular
DNS
records
to
origins,
you
know,
determines
the
size
of
your
nominee
set.
C
So
just
a
quick
recap
today,
without
deprive
so
today,
I,
depending
on
what
system
you're
running.
This
is
what
you
know.
Generally,
the
your
connection
looks
like
this
is
where
your
traffic
goes
any
chance.
You
have
a
query
from
a
client
to
be
notice
for
customers
over,
for
bargain
address
back,
send
barring
the
SNR
into
this
client
facing
server,
which
was
identified
by
a
record
from
your
personal
resolver.
In
your
address,
your
adversary
basically
sees
everything
you're
doing.
E
C
We
want
to,
presumably
if
you
can
encrypt
the
Dinah's
traffic
and
encrypt
the
s
and
I
both
of
these
holes
abrupt.
So
the
high-level
summary
is
that
the
client
facing
server,
which
is
the
CDN
who
controls
the
DNS
records
for
all
of
its
clients,
installs,
yes
and
I
keys,
which
are
key,
is
used
to
encrypt
the
USMLE
into
the
dienes
claim.
C
F
C
I
should
note,
though,
I'm
going
back
to
the
previous
one,
that
it
is
the
case
that,
because
you
don't
want
to
share
PSNI
cans
between
the
CDN
or
the
client-facing
server
and
the
origin,
that
the
origins,
what
websites
don't
actually
see
what
the
real
sni
is.
So
there's
a
caveat.
There's
some
text
in
there
says
you
know
it's.
The
origin
server
has
to
serve
up
essentially
just
want
certificates,
otherwise
it
just
is
guessing
basically
what
the
one
certificate
it
should
provide
to
that
client.
C
So
this
is
what
the
record
looks
like
Indiana's,
it's
pretty
straight
forward
naming
could
be
Vegas,
so
it
starts
with
a
checksum
which
is
basically
the
upper
32
bits
or
they're.
Basically,
checksum
of
the
rest
of
the
contents
of
the
DNS
record,
starting
from
the
keys,
the
key
share
entry
vector
all
the
way
down
to
the
extensions,
and
we
included
this
basically
to
protect
against
potential
transmission
problems
of
the
DNS
record.
C
You
want
to
encrypt
before
sending
it
to
the
server,
and
this
is
important
because
you
want
to
make
sure
that
the
length
of
the
encrypted
sa9
does
not
reveal
what
SNR
you
are
actually
sending
some
not
before
not
after
timestamps
that
determine
the
validity
of
this
particular
ES
and
I.
He
record-
and
this
was
useful,
deem
useful
because
it
helps
operators
kind
of
handle,
key
rotating
and
quickie
rotation
rollover
in
a
more
straightforward
fashion
and
then
some
arbitrary
extension
block.
C
If
we
want
to
potentially
add
things
there
later-
and
this
is
all
stored
in
a
text-
record-
base64
encoded
with
the
name
underscore
yes
and
I-
with
the
actual
s
and
I
value
appended
to
that,
and
so,
for
example,
the
one
that's
hosted
on
the
cloud
flower
server
right
now
is
listed
below
I.
Don't
know
if
it's
changed
since
I,
don't
think.
F
C
Cuter
evasion
is
pretty
simple.
You
get
a
you,
have
your
client
key
share,
which
has
to
match
the
Group
one
of
the
groups
that
are
provided
in
the
es
and
IQ
structure,
and
you
mix
that
with
one
of
the
public
key
shares,
that's
in
the
SMI
key
structure.
This
has
some
interesting
effects.
In
particular.
That
means
that
the
client
facing
server
and
the
origin
have
to
use
the
same
group
effectively.
C
C
The
new
client,
hello
extension
is
exclusively
for
clipping
of
the
es
and
I
nothing
more,
and
one
subtle
problem
with
this
right
now
is
the
design
of
specify
it
has
a
potential
for
downgrade
attacks
in
this
layer,
and
this
is
different
from
the
downgrade
attack
that
I
was
kind
of
referring
to
earlier
by
including
the
record
digest
so
I
comment
on
interaction.
Two
little
boxes
from
section
93
in
the
texts
of
gs-13
basically
requires
that
you
know
a
middle
box
that
does
not
understand
any
extension
must
not
send
it
along.
C
So
presumably
the
server,
then,
would
you
know
reply
with
a
default
certificate
that
the
server
would
trust
or
the
client
would
trust.
So
you
should
have
a
way
to
be
able
to
detect
this
particular
problem,
but
for
non-compliant
middleboxes,
those
that
just
you
know
completely,
ignore
this
test,
unfortunately,
and
I'm
sure
there
will
be
some
David.
Benjamin
can
probably
comment
more
on
whether
or
not
you
know
he's
had
middle
box
problems
in
the
past,
so
we're.
C
This
particular
type
of
problem-
you
know
maybe
some
kind
of
captive
portal
thing,
but
this
is
yeah.
This
is
something
real
that
would.
This
is
still
very
much
an
open
issue
after
the
case
of
disabling
yes,
annoy,
say
your
inner
like
and
enterprise.
It
doesn't
want
to
use
it
or
say
your
server
that
is
under
heavy
low,
and
you
want
to
turn
it
off
and
start
doing
a
bunch
of
encryption.
Presumably,
you
could
just
strip
the
DNS
records
that
contain
yes
and
write.
C
The
records
that
contain
yes,
I
might
use
from
DNS
or
just
make
sure
that
the
TTL
is
are
relatively
short.
So
you're,
not
you
know,
your
client
has
to
go
on
fetch
a
new
record
and
then
unit
your
window
of
exposure.
Is
you
know
the
length
of
that
TTL,
for
example,
but
you
might
also
want
to
you
know
if
you're
a
client,
that's
implementing
this
particular
feature
provide
a
way
to
sort
of
push
down.
C
And
you
know
there
might
be
other
some
other
course
to
deal
with
this
particular
problem
as
well.
So
we're,
of
course
open
to
suggestions
for
that,
and
so
several
times
during
the
design
of
this
particular
work.
We've
got
us
a
question:
why
not
just
encrypt
everything,
and
the
reason
is
that
we
want
to
make
sure
that
you
know
the
ESN
is
kind
of
a
special
piece
and
that's
used
to
it
primarily
identify
the
certificate,
but
also
potentially
use
for
routing
like
information.
C
So
if
you
were
to
have
you
know,
if
you
were
to
encrypt
all
the
extensions
you
potentially
have
to
share
a
key
between
the
client
facing
server
in
the
backend
or
you
know
the
origin
server,
which
is
not
what
you
want
to
do.
In
many
cases,
I
mean
if
you
configure
your
origin
server
with
single
certificate
and
respond,
then
you
can
keep
the
key
separate
and
you
don't
have
to
worry
about
any
particular.
You
know
key
management
issue
or
at
a
larger
scale.
That
is
also,
if
you
happen,
to
encrypt
all
your
extensions.
C
You
might
run
into
middleboxes
what
just
happened
to
drop
all
of
your
new
extensions,
because
they
do
not
understand
them,
which
is
a
pretty
useless
client
hello,
I
would
say
so
I
mean
we
could
later
look
at.
You
know
proposing
alternatives
to
encrypt
the
rest
of
the
extensions
or
more
of
the
extensions,
for
example
the
hey
OPN.
C
Also,
a
very
big
disclaimer
that
you
know
mostly
content
in
this
draft
is
potentially
wrong
between
a
structure
being
one
of
them
received
many
comments,
particularly
for
those
people
medina
sauce
working
group,
which
is
really
great,
because
it's
nice
to
have
kind
of
feedback
and
cross-pollination
there.
You
know
they're
issues
such
as
it
should
be
removed
base64.
We
added
it
because
we
all
love
base64,
and
that
was
a
very
wise
engineering,
data-driven
decision.
C
There
is
also
talk
about
potentially
using
something
other
than
a
text
record
such
as
you
know,
just
dedicating
a
new
one
for
yes
and
I
honestly
I'm
just
deferring
to
these
experts
on
this
particular
one.
Who
could
tell
me
what
the
right
answer
is
so
happy
to
hear
that
you
might
even
use
if
he
goes.
Raisin
HB
AB
is
needing
using
a
service
to
publishing
es
mi
team
structure.
C
Yes,
there
are
some
also
problems
with
the
TLS
bits
of
it.
You
know,
maybe
you
might
not
want
to
use
the
key
share.
That's
used
for
the
actual
handshake
and
use
for
the
for
the
SNR
encryption,
but
the
caveat
there
are,
though,
is
that
you
have
to
bind
them
together.
Otherwise,
someone
can
just
come
along
and
strip
out
the
encrypted
s
and
I
blob
that
you
have
and
shove
it
in
their
own
coin,
hello
and
then
send
it
to
the
server
and
get
back
the
certificate
that
you
would
have
gotten.
C
So
we
need
to
there
are
some
proposals
floating
around
as
to
how
to
actually
do
this?
We
don't
have
a
you
know,
put
anything
down
concretely
in
writing
yet,
but
you
know
that
is
something
that
we're
thinking
about
over,
although
we
think
you
know
based
on
our
experience
at
the
hackathon,
and
you
know
the
ease
in
which
this
kind
of
came
out
and
how
it
kind
of
fits,
seemingly,
naturally
into
the
ecosystem
that
we
think
this
is
the
right
direction.
You
know
caveat
that
we
think-
and
you
know
other
people
may
think
differently.
C
So
just
a
quick
update
on
the
inter
up
status.
So
over
the
weekend
we
got
into
NSS
thanks
ekor
implement
it
and
the
client
side
of
boring
it's
to
sell
and
Kazu
implemented
and
equal
to
us.
Firefox
has
support,
so
actor
was
able
to
connect
to
oops
I,
didn't
think
I
thought
website
as
well,
which
is
really
great
and
working
on
getting
in
Safari
as
well
just
to
experiment,
and
there
are
two
test
servers
up
right
now.
C
You
go
to
us
and
believe
boring
us
or
so
not
sure
how
that
bit
is
actually
implemented,
but
so
very
much.
Hopefully
we
didn't.
You
know
gloss
over
too
many
details
in
the
interest
of
time,
but,
like
now
to
kind
of
you
know,
post
a
big
question
to
the
room
is
just
something
the
working
group
is
interested
in
and
if
so,
how
shall
we
proceed?
I
will
take
any
questions
and
comments
of
the
mic.
C
I'm,
just
gonna
bother
you
with
weird
ideas:
I
want
to
put
a
replacement
sni
field
in
me.
Yes,
an
IQ
structure
can
be
empty
or
you
know,
in
which
case
you
get
the
behavior.
That
client
doesn't
know,
that's
Venus
and
I,
or
it
could
have
something
there
I
think
that
could
be
useful
for
certain
deployment
architectures,
so
their
placement
nests
and
I
then
would
be
like.
Please
say
this
is
what
you
should
actually
put
in
yes
and
I
feel
like
I'm,
going
to
great
Randall
thing,
calm,
which
is
nowhere
near
bad.
C
So
please
don't
block
my
traffic
and
you
actually
put
the
bad
thing.
Example:
calm
and
encrypted
s.
Alright,
so
I
think
that's.
That
seems
a
little
silly,
given
the
Fiat
cryptic,
as
my
extensions
right
there
at
the
end
of
the
client
hello,
but
there
I
think
there
are
deployment.
Architecture
is
where
basically
there's
a
there's
a
front
end
that
only
inspects
the
SNI
and
and
then
there's
a
much
smarter
back-end.
C
And
so
you
know
your
your
topology
here
requires
that
front
end
to
BES
and
eyewear,
and
you
know
maybe
there's
maybe
there's
a
version
of
this
where
your
your
front
end
dispatches
based
on
based
on
a
clear
text.
That's
yes
and
I
that
doesn't
reveal
all
the
relevant
private
information
in
the
private
extension.
C
I
would
like
the
group
to
consider
is
potentially
trying
to
also
encrypt
other
things
that
are
in
the
client.
Hello
thanks
to
this
mechanism,
so,
like
I
was
mentioning
earlier
with
the
alien
like
I
am
of
the
opinion.
We
should
do
that
in
a
separate
route
because
of
the
reasons
that
I
discussed,
but
doesn't.
A
B
Bishop
I
also
think
this
is
moving
in
the
right
direction.
I
will
point
out
one
more
way
in
which
the
raft
is
wrong,
which
is
great.
It
feels
to
cover
multi
CDN
cases
and
the
way
it's
written
right
now
you
get
one
is
a
nike
per
first
name
per
origin
and
in
a
lot
of
cases,
they're
actually
a
multiple
cbn's
that
it
might
be
shared
amongst,
but
you
probably
don't
want
them
to
have
the
same
keys,
so
you
have
to
figure
out
some
way
to
disambiguate.
Yes,.
C
F
C
This
is
a
sick
hack,
there's
a
lot
of
details
to
work
out,
but
I
really
like
it.
I
think
this
is
the
place
to
do
it.
I
caution
you
against
I'm,
going
to
you
know
as
experts
and
asking
them
whether
tax
records
or
anything
to
do
but
yeah.
It's
a
detail.
So
I
would
say
that
I
would
say
that
there
doesn't
need
a
coordination.
A
A
C
Whatever
solution
we
have
does
need
to
solve
that
problem.
So
let's
keep
going
down
that
road.
One
thought
regarding
the
IP
address
solution
that
dkg
just
mentioned.
That's
very
cute
I'm
a
little
bit
concerned
about
the
latency
that
that
could
add
to
the
beginning,
as
I
was
thinking
about
how
I
would
implement
this,
because
you
know
we're
doing
das
Cruzes
already
happy
eyeballs
I
was
imagining.
I
could
essentially
do
the
text
record
query
before
I.
Do
the
aim
quality
and
then
just
fire
it
off
afterwards
to
make
it
really
fast.
C
G
You
good
secure,
Google.
One
thing
it
seems
missing
here
is:
there
is
no
at
all
acknowledgement
of
the
fact
that
yes
and
I
was
successfully
accepted
and
decrypted
by
the
server
or
whether
it
was
simply
ignored,
and
then
the
client
doesn't
have
an
indicator
whether
the
negotiation
was
successful
right
there.
The
draft
assumes
that
there,
what
bki
verification
will
fail
in
that
case,
but
that's
not
necessarily
true
with
white
birth
certificates
and
stuff
like
that
right,
okay,
yeah,
certainly
something
we
can
clear
up
in
the
text.
Yeah
thanks.
D
So
there
has
been
great
Hope
over
experience
that
has
not
changed
in
15
years.
The
other
thing
is
that
I
think
that
you
will
find
you
get
pulled
into
the
hole.
How
do
we
reform?
How
HTTP
streams
are
discovered
and
there's
a
whole
thing
of?
Should
you
use
SRV
or
whatever
and
doe
is
changing?
That
and
I
think
that
you
want
to
have
that
whole
world
separate
from
the
crypto
stuff.
C
A
A
He
was
probably
one
thing
that
is
probably
worth
thinking
about
is
the
draft,
at
least
as
is
is
kind
of
operationally
scary,
in
that,
when
there's
a
mismatch
on
the
key,
you
sort
of
have
no
record
like
the
connection
will
fail,
and
you
are
just
sad
until
the
details
expire,
and
so
if
we
can
avoid
weakening
the
threat
model
or
maybe
if
we
can
avoid
like
making
this
totally
useless
or,
like
you
know,
less
useful,
while
also
like
making
it
the
global.
That
would
be
a
good
thing
to
get
yeah.
C
A
It
solves
some
of
these.
It
has
some
perf
benefits
from
work
on
deployability
some
custom
ways
we
integrate
with
customers,
deployability
benefits
as
well
as
addresses
the
melting
CDN
case,
but
that
said
that
may
be
appropriate
for
the
revenues
case.
But
it
would
not
surprise
me
if
other
uses
cases
of
t
left/right
have
a
better
a
different
way
to
do
it.
For
there,
that's
not
out
service
for
Tom
for
there's
I
think
separating
out
the
from
the.
How
do
we
do
it
perspective?
I
will
add
in
the
should
we
caveat
again
on
that.
A
What,
unfortunately,
for
better
or
worse
SMI,
is
one
of
the
less
harmful
signals
to
middleboxes
that
they
can
use
to
do
for
during
and
I
would
I'm
seeing
some
grimaces,
but
it
see
the
we
should
think
through
the.
What
are
the
ramifications
of
this?
Their
middle
box
is
today
for
enterprise
use
cases
that
today
will
use
us
and
I
to
do
filtering
whether
or
not
this
is
a
good
idea
or
it
is
not
a
good
idea,
but
it's
what
they
do.
C
G
C
G
C
Spent
a
little
time,
thinking
about
this,
you
know
we
already
take
on
clients
and
general
profession
bars
already
take
signal
for
the
enterprise
about
what
they
shouldn't
shouldn't
do,
and
you
know
like
there's
like
a
price
policies
and
I
think
we
run
I
mean
dough
is
the
same
kind
of
funny
property
which
is
like
you
know,
like
less
enterprises.
Don't
really
would
prefer
you
didn't
you
don't
want
to
run.
You
want
to
date
a
specific
way.
C
A
Idea,
like
I,
want
to
hear
all
right
cool,
so
that
was
useful
for
it
to
be
in
this
working
group,
because
it's
clearly
in
scope,
I
think
that
point.
It's
not
debatable.
If
you
would
like
to
appeal
that
decision
feel
free,
I'll
write
it
for
you,
I,
don't
think
you're
gonna
win
anybody
who's
read
this
draft
I
find
this
son
shocking
for,
like
three
weeks.
I
would
like
to
do
a
call
for
working
group
adoption
this.
It.