►
From YouTube: IETF101-TLS-20180321-0930
Description
TLS meeting session at IETF101
2018/03/21 0930
https://datatracker.ietf.org/meeting/101/proceedings/
B
B
D
E
B
C
I
I
I
Brice,
if
we
find
anything
we're
pulling
it
back,
that's
been
the
deal
all
along.
So
everyone
should
remember
that.
However,
to
commemorate
that,
we
did
make
some
stickers
so
we're
going
to
give
out
some
stickers-
and
you
can,
you
know,
take
some
and
pass
them
around.
Add
some
other
things
planned,
but
it's
stuck
in
customs.
So
that's
life
all
right.
Do
you
want
to
go
ahead
kind
of
hand
these
out
there
go
from
there,
don't
take
them
all.
We
got
a
lot,
but
just
in
case.
I
K
So
it
turned
out
so
it
turned
out
that,
like
the
only
thing
I
want
to
talk
about
with
DTLS
1/3
was
the
same
thing.
One
higher
connection
ID,
so
we're
just
gonna
glue
this
together,
so
I'll.
Let
you
figure
out
which
part
of
the
talk
this
is
next
slide,
please!
So
the
when
we
showed
you
so
when
we
first
did
it
like
to
tell
us
one
point:
three:
we
found
up
to
a
pressure
ID
in
and
then
like
people
like
we're
sad
about
that
specific.
Actually,
you
draft
out,
and
then
people
were
like.
K
This
ID
yesterday,
which
was
basically
there's
like
a
little
bit
of
question
about
whether
or
not
the
deals
1.3
headers
that
were
posing
or
like
exactly
we
want
and,
and
also
has
a
bunch
of
conversations
are
correct
about,
like
maybe
we
should
heart
still
some
of
their
stuff
or
or
you
know
whether
they
should
be
the
same
or
whatever
on,
and
so
me
whenever
I
scroll
down
a
little
bit
so
keeping
with
that
is
good,
but,
on
the
other
hand
like
dragging
down
details
for
a
new
connection
ID,
while
we
think
about
two
or
three
cash
ID,
like
not
great
so
next
slide.
K
We
need
resolved
that
we
need
to
do
if
we're
going
to
do
this,
so
if
you're
going
to
have
connect
so
so
like
in
quick,
there's,
always
a
connection
ID,
but
we
have
other
big,
install
bases,
GL's
1.2
and
that
does
not
have
a
connection
ID
and
so
a
server
client
or
so,
but
most
likely
a
server
may
find
itself
in
the
position
where
it
has
client
support
and
do
not
support
the
connection
ID,
you
know
extension,
and
so
now
they
get
packets
and
they
and
they
have
to
determine
with
that
fisheye
in
them
in
order
in
order
to
like
rock
them
down
the
right
pipe
on
that
is
affordable,
writing
or
to
do
cie
base
writing,
and
so
it
was
suggested
that
one
way
to
do
this
an
obvious
way
to
do
this.
K
It's
definitely
indicate
a
bit
ahead
of
your
president,
could
actually
absent
as
I'll
be
splitting
in
a
minute.
This
isn't
like
necessary.
You
can
make
it
work
without
this,
but
it
like
is
convenient
for
various
kinds
of
like
packet
parsing.
It's
particular
convenient
if
you're
like
something
passive
is
special
like
Wireshark,
where
you
don't
know
exactly
the
server's
behaviorist.
This
might
be
a
little
less
necessary
in
1/3
than
1/2,
because
in
principle
you
have
like
a
1/3,
1/2,
C
ad,
no
C
ad
server
and
like
refusing
to
go.
K
K
Basically,
two
technical
options
here,
which
I've
been
calling
implicit
and
explicit
connection
IDs
worth
noting
quickest
side,
is
do
both
in
the
quick
long
header
it'll,
be
explicit
connection
IDs
and
the
quick
shortcut
it'll
be
implicit
connection,
ID,
so
Merry
Christmas,
the
so,
if
you're
ready
to
implicit
but
as
I
say
in
quick,
that's
easy
because
in
quick
you
know
where
the
thing
is
present
or
not.
So
so
it's
easier
so
important.
Remember
that
in
details,
1.3
and
now
in
quick,
the
receiver
controls
a
connection
ID.
K
So
you
have
an
opportunity
to
stress
the
connection
ID
in
a
way
that's
easy
to
deem
ox
in
the
eye.
This
is
everything
here
should
say:
DTLS
instead
of
TLS
I
like
I've
written
TLS,
so
many
times,
I,
just
like
Oh,
alrighty
TLS,
but
actually
true
story
like
I
I
took
TCP
as
TLS
lots
of
times
so
anyway,
so
regardless
in
the
current
headers,
the
connection
ID
goes
right
in
the
lonely,
header
and
details
123
and
in
the
Choson
put
do
better.
K
The
CID
was
right
for
the
length,
and
so
all
you
need
to
do
is
determine
where
the
next
byte
is
length
or
CID,
so
because
links
going
to
get
into
it
create
an
equation
to
the
1404
forbidden.
If
you
just
set
the
high
bit
in
the
CID,
then
you
can
like
look
at
that,
and
you
know
it's
the
length
for
a
CID
now,
maybe
you
have
no
box
problems?
Maybe
you
don't?
That's
your
fault.
That's
your
problem.
Like
we're
cars,
less
you
go
to
detox
the!
K
The
short
header
is
harder
because
there's
no
length
filled
the
d-max,
and
so
the
thing
of
doom
I
saying
against
is
like
just
a
random
trash,
but
that
gives
the
opportunity
to
which
is
basically,
you
fix
the
first
inputs
of
the
connection
ad
to
something
and
the
server
knows
that
something
is,
and
this
is
the
first
n
bits
of
sefar
no
random,
then,
if
you
do
a
chance
of
collision
is
2
to
the
minus
M
right,
and
so
you
can
pick
any
error
rate
you
please
by
like
the
cost
of
n
bits,
and
then
you,
if
there's
somewhere,
to
send
rate
of
false
positives
and
if
you
get
a
false
positive,
try
to
decrypt
and
if
it
fails,
you
can
here
to
score
the
packet
or
you
can
be
like.
K
Oh
now,
I'm
going
to
fall
back
to
enter
port
running
so
so
this
is
my
argument.
That
is
not
in
fact
necessary
to
have
any
any
extra
indicator
indicator
bit
in
the
protocol
proper.
That
said,
one
might
think
this
was
nasty
and
particularly
for
like
Wireshark
guy.
You
might
think
this
is
like
really
nasty,
because
you
don't
know
you
know,
because
server
a
chooses,
the
magic
string,
FF
and
sort
of
each
use
the
matters
of
string
like
you
know,
dead
thief
and
that
you
don't
know
how
to
parse
it.
K
So
so
you
might
think
that
you
want
like
a
bit
next
slide
so
like
yeah
again
like
so,
it's
like
the
thing
we
got
stuck
on
is
like
the
bit
like
for
the
one
two
in
the
long
header.
This
like
seems
like
an
aesthetic
choice,
namely
it's,
like
you
know,
there's
a
bit.
We
got
some
rooms
like
really
like
just
aesthetic
right
put
the
short
hair,
because
I
have
no
room,
it's
actually
like.
We
have
to
pay
for
that.
K
K
K
It's
occurred
to
me
that
we
may
have
crammed
the
header
down
a
little
too
hard
and
the
details
won't
put
your
sequence
number
in
the
short
header
is
like
12
bits,
and
it's
like
it's
actually
quite
possible
to
have
a
situation
where,
like
you're,
referring
that
12
bits
and
you're
forcing
the
long
header
just
because
you
don't
have
the
ambiguity
about
the
sequence
number
so
like
I,
was
sort
of
against
this
and
then
I
sort
of
think
it's
sequence.
Every
t-shirt
and
I
started
getting
more
for
it.
So
what
about
to
show?
K
You
is
like
one
of
a
number
of
options
for
basically
trying
to
like
make
lemonade
out
of
this
lemon.
That,
arguably,
like
makes
the
world
better
on
several
problems
and
also
get
some
space
for
the
CID
bit.
It's
important
to
note.
This
is
not
the
only
way
to
do
this.
There's
a
number
options.
Well,
I'm,
hoping
to
get
your
sense
on
today
is
like
we
think
this
is
like
worth
being
in
principle
and
we
can
discuss
how
to
pack
the
bits
lit
next
slide.
K
So
just
they're
just
all
reserves
we
probably
have
to
grease
them,
but
that's
easy
enough
to
do,
and
then
the
epic
and
the
sequence
are
packed
together
in
the
innovate,
arraigning,
two
bytes,
so
three
right,
headers,
those
who
the
so
this
gives
you
to
attribute
expansion
of
the
sequence
number,
which
is
quite
a
bit
more
room
than
probably
is
enough
room
for
anybody,
because
pretty
hard
together,
I
get
that
far
out
ahead
of
it.
This
is
not
the
most
optimal
packing
on
this.
The
packet
is
most
flexibility.
K
K
If
you
want
them
another
possibility,
if
we
decided,
we
wanted
a
longer
sequence
number,
a
stash
of
the
two
epic
bits
into
the
go
back
for
a
second
into
those
two
xx's,
and
then
we
have
one
more
flight
that
remaining.
If
we
wanted
it,
and
then
we
have
a
fixed
16-bit
sequence,
number,
there's
now
a
variety
of
other
things
you
could
do
to
you
could,
like
you
know,
you
can
also
have
one
of
those
bits
be
like
how
long
the
sequence
number
is.
K
You
could
have
like
a
like
a
rather
I
got
like
an
8
and
a
16
or
18
or
24
like
a
lot
of
stuff.
You
could
do
here
right
depending
on
exactly
how
how
much
flexibility
the
flexibility
versus
like
compactness
Draft
at
the
stages
again
so
nice
Lovelace,
so
so
I.
Certainly
again,
we
don't
need
to
exactly
this.
We
might
did
that
in
a
day
decide
to
rip
off
the
quick
headers
which
have
other
merits
or
key
merits.
K
So
I
think
the
question
I
want
to
ask
is
is
like,
if
people
like
sufficiently
persuasive
to
people,
but
this
makes
them
comfortable
with
having
a
CID
indicator
bit,
in
which
case
we
got
to
see
the
indicated
bit.
We
can
close
the
T
to
tell
us
where
to
issue
and
spend
a
little
time
by
shedding
about
it
about
the
structure.
Next
slide,
I
think
I,
just
to
say,
I
just
said
right,
so
I
mean
I,
guess
that's
the
question.
I
think
we
should
focus
on
is
do
we
want
this
bit
at
all?
K
If
we
do
want
a
bit,
if
we're
doing
a
bit,
then
like
we
can
just
publish
the
CIT
you're
after
and
we
can
be
finished.
If
we,
if
we
do
in
a
bit,
then
we
can
just
basically
define
this
piece
of
details
and
point
you
right
away
and
then
there's
some
question
about
whether
or
not
like
is
best
used
a
common
type
of
length.
K
I'm
one
argues
there's
best
to
use
the
Piper
to
think
he's,
probably
right
about,
but
you
might
think
about
the
length
where
other
spits
another
place,
and
then
we
could
spend
a
little
time
tuning
the
details.
We
play
three
format,
but
there's
no
actual,
like
there's
like
less
urgency
for
dealing
with
that,
so
I
guess
I'm
eventually
I
was
eventually
persuaded.
This
was
the
right
that
the
right
answer
was
to
have
the
bit
and
to
go
that
way,
but
I,
like
the
other
people,.
L
So
I
was
previously
more
in
favor
of
implicit
approach,
but
now
I'm,
leaving
today
explicit
one
that
you
proposed
I,
think
it's
just
Tina
I,
also
like
this
new
headed,
a
sign
I,
don't
care
much
on
what
I
we
encode
the
information
in
in
the
content
type
or
in
the
lens
to
it.
I
I,
don't
have
an
opinion
about
that.
L
Also
that
sort
of
splits
are
having
a
two-stage
approach.
First,
trying
to
do
something
for
one
or
two
appears
to
be
better
because
that's
where
what
people
are
currently
deploying
and
you're
seeing
and
if
we
could
get
them
to
to
support
this
functionality
as
quickly
as
possible
apathy.
That
would
be
very
useful
in
40d,
less
one
two
three:
they
have
a
few
months
additional
months
time
to
do
that.
So
so
I
think
it's
a
great
idea.
M
K
We
probably
should
mention
Sony
with
that
I.
Think
generally,
my
sense
is
it's
pretty
obvious
when
the
see
the
attacker
can
generate
I
want
to
see
ID
as
far
as
I
can
see,
is
constant,
so
I
think
it's
in
it
I
think
I
think
it's
I
think
it's
like
one
of
these
things
that,
like
it's
extremely
annoying
to
parse
but
actually
doesn't
have
like
any
privacy
impact.
I
mean
the
CID
existing
is
a
privacy
at
bat,
but
like
I,
don't
think
I
don't
think
is
like
what
doesn't
tell
you
much
our
secret.
That's
there.
N
N
O
E
To
be
a
STONER
wowie
I'm
in
favor
of
the
explicit
version,
mostly
for
the
same
reason
as
Hannes
mentioned,
because
it's
cleaner
and
like
I'm,
really
scared
of
things
like
metric
number
type
of
approaches.
The
first
one
has
that
kind
of
feel
and
this
potential
volatility
about
unpredictable
behavior,
so
I
think
that's
better.
The
second
Pro
second
comment
I
would
make
is
if
we
can
see
that
we
can
do
this
relatively
soon,
as
that
would
be
very
good,
because
there's
a
lot
of
need
out
there.
That's
really
waiting
for
this
to
be
finalized.
So.
K
P
Thompson
I've
previously
been
pretty
strong
advocate
for
the
implicit
one
I
just
like
to
make
it
clear
that
the
getting
what
we
gained
in
this
case
really
largely
accrues
to
middleboxes
Rather's,
load,
balancers
tools
and
whatnot,
and
that's
not
a
bad
thing.
I
I
think,
based
on
the
discussion
here
and
and
talking
with
people.
I
think
that
this
this
is
probably
the
right
design
and
plenty
of
paint.
If
we
want
to
talk
about
yeah.
P
P
P
K
P
K
N
K
If
you
have
multiple
C
IDs
and
you
chip
in
you
and
you
do-
and
you
like,
do
you
like,
you
know,
you
know,
change
your
path,
change
and
the
sequence
numbers
just
like
a
linear
doesn't
like
you
instantly
like
there's
no
point
home
with
little
C
IDs
because,
like
is
like
oh,
this
is
like
you
know,
ff01,
and
this
one's
FS,
0
or
2
and
like
CID,
is
random,
but
I
can't
doesn't
matter
it's
like
I.
What
came
next
right?
So
when
you
do
something
and
in
1
2
we
so
something
like
in
quick.
We're.
K
Currently
quick.
Has
this
thing
which
I
think
I
think
I
invented,
which
is
like
random
skipping
based
on
the
based
on
like
a
digest
of
the
current
traffic
seekers,
and
so
the
idea
is
that,
like
basically
when
you,
when
you
move
to
the
next,
the
next
CID
there's
like
a
there's
like
basically,
you
communicate
EF,
and
that
tells
you
how
much
to
increment
sequence
number
so
for
one
to
like,
like
let's
not
get
clever,
we
can
use
the
same
track
now.
You
don't
like
a
Martin
yeah.
P
Someone
Thompson
I
think
the
the
skipping
trick
from
quick
is
kind
of
annoying
great
and
we
can
come
up
with
with
I
think
rather
than
use
the
skipping
trick.
Where
you
you
effectively
skip
seconds
numbers
I
think
we
should
probably
move
to
what
is
effectively
brought
13
and
so
that
every
connection
ID
has
an
has
an
additive
factor
that
you
add
to
the
the
sequence
number
and
you
just
remove
that.
So
that
addition.
K
K
K
These
are
two
approaches.
I
I
think
you
know
I'm
not
certain.
P
Idea,
I'm
not
sure
so
the
advantage
of
doing
that
is
that
you
don't
have
to
worry
about
the
strict
sequence
of
connection
IDs
as
they
as
they
come
out.
I
say
and
that's
that's
the
primary
advantage.
So
so
the
come.
Quick
design
requires
that
you
guess
why
all
the
secret
over
connection
IDs
in
strict
sequence,
because
the
yes
is
skips
accumulative,
yes,
I,
think
you
would.
You
would
simply
just
say
that
every
connection
ID
has
a
corresponding
add
and
then
you
just
carry
on
sure.
K
This
is
like
far
from
ideal,
which
is
why
I
think,
which
is
why
it
would.
This
is
far
from
ideal,
which
is
why
the
president,
each
else
from
a
three
we
go
much
further,
so
I
I
think
Martin.
Martin
persuaded
me
so
I
think
from
the
amendment
well,
I
suggest
to
all
right
up
the
addition
trick,
instead
of
the
skipping
trick,
they're
actually
quite
similar
mathematically.
K
So
for
one
three,
however,
I
think
we
should
agree
with
the
sequence
numbers,
and
this
is
gonna,
take
a
little
time
to
work
out.
We
I
think
we
need
to
figure.
We
should.
We
should
use
the
same
like
again,
quick
and
easy.
Less
are
harmonized,
I
think
with
the
sequence
numbers
either
they
should
two
hundred
on
to
it
and
they
should
approximately
the
same
way.
K
So
we're
still
screwing
around
with
that
in
quick,
so
I
think
like
I
suggest,
was
like
this.
It's
like
all
the
same
people
hey
it's
me
and
Martin.
Suppose
it's
like
intervenes
are
like,
like
we
get
a
hike
in
sweat,
so
I
think
like
we
can
just
like
figure
it
out
and
like
they
come
to
book
places.
The
same
answer
yeah
so
boats
gonna
tell
you
this.
S
K
E
K
K
Unfortunate
doesn't
because
they
sequence
numbers
are
high,
entropy
values,
and
so
that's
really
hide
repeat
values
but
say
but
say
you
have
like
say
you
have
a
trivially
say
you
have
two
devices
right,
one
of
which
is
sent
a
thousand
packets
or
one
if
it's
at
five
thousand
packets.
If,
if
you
then
randomize
the
see
IDs
and
look
at
the
sequence,
numbers
or
just
race
to
see
IDs,
then
then
you
can
tell
which
ones
which,
by
looking
at
which
one
goes
2001,
which
goes
to
5,000,
won.
Okay,.
T
E
P
P
K
Yeah
I
agree,
so
I
guess
like
we
can
tell
it
as
a
word,
but
like
I,
strongly
perform
courtesy
with
numbers.
It
conceals
more
information.
Yes,
yes,
that
one
still
shows
linear.
Just
the
linear
sequence
for
like
any
given
flow,
constitute
so
it's
okay
again,
like
I,
think
like
this
seems
something
the
ITF
wanna
be
able
to
agree
about
as
a
general
policy
matter
and
then
implement
I
mean
if
you
like
two
protocols
like
a
few
similar
like
conceptual
wire
images.
K
Okay.
So
to
recap
what
I
proposed
to
do
is
do
what
I
said
here:
I
stepped
across
out
skipping
track
and
right,
adding
trick
and
I'll
write
that
up.
Okay,
that's
like
okay!
So
last
point
and
my
decision
in
the
opposite
order
is
C.
Ie
D
update
curl.
The
draft
has
a
DT
Ellis
1.3
post,
an
investor
VI
D
update,
which,
like
as
far
as
we
can
tell
works
fine,
it
doesn't
do
anything
for
TLS
1.2.
There
are
three
options
for
1.2
as
far
as
I
can
tell
one
continue
to
nothing.
K
I
think
we've
heard
of
the
people
don't
think.
That's
a
great
idea,
though,
by
the
way,
if
it
was
a
good
idea,
then
like
we
could
not
have
to
worry
about
the
additive
Trek.
The
the
second
is
during
the
Rehan
shake
which
ordinarily,
like
we
hate,
we
handshake
and
I,
still
continue
to
hit
rien
Jake
but
their
hand
like
to
finding
the
mechanisms
also
I
hate,
and
the
third
is
to
put
the
appreciate
check
messages.
I
P
K
K
Hey
one
thing
that's
worth
noting
is
that
is
going
to
have
a
somewhat
negative
impact
on
privacy,
because
you're
not
going
to
be
able
to
you're
not
going
to
be
I
mean
what
would
be
hard
to
conceal
I
mean.
So
if
you,
if
you
Rehan,
shake
and
then
you
start
using
the
definition
of
you
right
away,
basically
doesn't
do
anything.
So
I
didn't
thought
about
that
thought
through
until
just
now
so.
P
J
P
V
K
The
problem
is,
you
need
to
promise
you
near
supply,
a
PID,
I
connection,
a
unpack,
a
for
later
use,
I'm,
happy
right.
If
you
don't
take
the
pass
right
so
so
in
in
quick
and
in
the
one
pre
mechanism,
what
happens
is
you
can
supply
a
pile
of
ones
and
then
the
idea
is
that
uses
the
next
time
right,
despite
underlies
useless
right,
and
so
that's
the
handshake
completely.
K
K
I
think
I
think
what
you
think
there's
a
simpler,
a
simpler
way
to
do
this,
which
is
like
even
quite
eager
but
like
what
we
call
spare
will
be
a
great
recalls
or
we
can
call
or
we
can
call
it
many,
but
the
bottom
line
is
we
just
make
the
cardinality
the
fashion
of
these
more
than
one
and
it's
and
and
then
you
offer
and
they
in
the
offer
in
the
extension
and
now
I
understand.
K
One
of
my
core
test
proposals
are
following,
which
is
we
change
the
we
change
the
minimal
extension
that
does
the
offer
answer
to
allow
more
than
one
connection
ID
and
then
with
the
semantics
that
they're
all
co-equal,
basically
right
and
then
in
the
initial
hanges.
No,
no
reason
not
for
more
than
one
week,
even
perimeters,
but
in
the
rehand
shake
you
can
offer
a
shit-ton
of
them
and
then
you
can
and
then
and
then
and
then
you
now
have
enough
that
you
can
change
when
you
go
multipath.
S
Quick
we're
trying
to
support
a
mode
where
quick
client
can
kind
of
trying
the
new
path
that
the
Eric
uses
it
and
suicune,
and
the
new
back
when
it
does
that
challenge
requested,
could
potentially
get
a
new
connection
ID,
but
it
won't
use
it
immediately.
So
so
we
would
like
a
concept
in
Europe
for
I.
Don't
know!
Maybe
it's
useful
for
ETLs
as
well.
That
is
primary
new
path.
Yeah
you
want
to
do
so.
Then
you
can
store,
get
ready
for
a
bath.
How.
K
W
X
D
X
X
K
K
Do
you
tell
some
points
right
and
so
like,
given
that
we
don't
know
how
to
do
this
in
a
like
efficient
way
in
one
to
I
mean
if
people
like
like,
if
you
were
like
well,
the
rehan
shake
is
useless.
Then
we
won't
do
it
right
there,
like
that's
fine,
but
if
like
people
were
like
the
Adrian
is
annoying
well
like
that,
can
you
choose
right,
I.
L
Agree
victor
who
mentioned
that
the
main
news
kiss
was
the
natural
timing
and
they're
the
private
persons
are
different
than
the
ones
discussed
in
in
quick
where
you
have
Deb's
moving
around
I
think
we
should
aim
for
something
that
gets
gets
done
fairly
quickly.
We
handshakes
are
not
really
that
common
in
the
IOT
case
to
begin
with,
and
so,
if
you
have
something
even
not
doing
anything
for
one
or
two
and
just
have
the
basic
functional
in
India.
N
K
To
support
that
right,
I
mean
you:
could
you
could
sort
of
bang
that
into
the
one
three
mechanism,
I
suppose?
But
none
of
these
Becca's
that
I
support
that
I
think
like
we
true,
like
I
spent
I
spent
hours
and
hours
of
my
life,
trying
to
figure
how
to
build
an
efficient
rotating
CID
mechanism
and
just
gave
up
so
I'm.
I
Gonna
ask
the
chairs
any
matters
this
is
like
like
I
would
he
was
like
I
mean
so
at
the
end
of
the
day.
Right,
if
we
end
up
trying
to
like
get
all
these
great
features,
we're
redesigning
1.2
to
look
a
whole
lot
like
1.3,
so
I
think
what
we're
looking
for
is
a
sweet,
quick
win
and
then
we
move
on
and
actually
like,
try
to
do
1.3
the
right
way,
and
then
we
just
kind
of
have
to
like
a
little
bit
what
the
implementers
decide
right.
L
I
E
That
I
I
think
if
you
go
with
the
require
we
handshake,
that
should
be
minimum
change
because,
basically
you're
doing
nothing
to
just
say
you
do
a
new
handshake
that
that
would
be
hurtful
for
IOT
devices,
but
it
yeah.
Okay,
if
you
want
to
privacy,
okay,
you
have
to
pay
a
price
I
like
the
idea
that
you
mentioned
before,
with
the
set
of
ID's.
If
that's
too
much
okay,
I
think
yeah.
P
I
think
I
think
we've
kind
of
hit
the
sweet
spot
here.
Tobias
objection.
It's
not
withstanding!
I
think
that
yeah
we're
doing
this
because
yeah
it's
gonna,
take
a
little
while
to
tell
us
once
we
do
deploy
and
people
are
kind
of
out
there
hanging
for
this
anyway.
So
it
fixes
the
the
net
rebinding
case
rather
well.
I.
Think
yes,
which.
P
J
K
E
K
K
K
C
I
All
right
folks,
so
this
is
a
draft.
That's
been
lingering
in
the
working
group
for
a
while
got
all
the
way
to
the
is
G,
and
then
we
had
some
discussion
so
we're
basically
bouncing
it
back
to
the
working
group
to
try
to
deal
with
the
questions
and
the
open
issues
and
I
know
that
Victor
has
probably
remotes.
So
when
he
little
Pacman
comes
up.
Please
let
us
know,
because
I
can't
see
the
thing
and
then
we'll
walk
him
in
the
button.
Oh
there's
all
right.
So
thanks.
Y
Thanks
Jimmy
folks,
so
we're
going
to
talk
about
the
remaining
issues
with
the
DNS
SEC
authentication
chain
extension.
So
this
has
been
through
is
G
evaluation.
There
were
a
number
of
comments
and
discuss
issues
raised.
We
believe
we've
resolved
most
of
those
on
list,
with
the
exception
of
one
of
them,
so
we're
almost
ready
to
push
out
a
draft.
Oh
seven,
next
slide.
Please.
Y
So
this
is
the
remaining
issue.
There
was
an
inadvertent
keyword
discrepancy
in
our
description
of
the
mechanism
for
TLS
1.2
vs.
1.3.
So
it
says
servers
receiving
a
DNS
section
extension
in
the
client
hello
and
which
are
capable
of
being
authenticated
by
Dane
may
return
an
authentication
chain.
That's
what
the
original
wording
said
for
TLS
1.2.
At
some
point
we
did
version
specific
descriptions
of
the
mechanism
and
for
the
1.3
description,
I
think
just
accidentally,
it
said
should
right.
Y
So
the
question
is
I
had
suggested
on
list
that
maybe
it
should
be
should
in
both
places
and
I,
think
Eric
pushed
back
and
saying
we
need
to
figure
out
what
their
working
group
consensus
is.
So
that's
why
we're
here
I
think
we
were
waiting
for
some
feedback
from
the
working
group
shares
an
ad
about
this
specific
issue.
Yeah.
P
Yeah
thanks
not
in
Thompson.
This
is
not
a
matter
of
interoperability
requirement,
you
can
say
can
and
everything
works.
So
the
fact
that
the
fact
that
the
extension
exists
makes
it
permissible,
but
that
this
is
not
a
choice
that
you
make
on
interoperability
grounds
are
simply
a
choice
that
you
make
as
an
implementation
choice.
Basically
do
I
choose
to
paint
it
red
or
do
I
choose
to
paint
it
red,
so
I
think
we
just
okay.
V
Z
J
Z
K
K
K
Y
We
kind
of
thought
we
were
definitely
this
raft
and
then
a
couple
of
folks
in
the
working
group
brought
up
a
new
issue.
So
that's
I
think
why
we're
primarily
on
the
agenda
today.
So
the
first
one
was
raised
by
Paul
routers
and
that's
the
data
format
in
the
chain
extension.
He
was
arguing
strongly
that
the
format
should
be
a
complete
DNS
message
rather
than
what
it
says
now,
which
is
a
sequence
of
wire
format.
Y
Dns
resource
record
sets
I
believe
after
some
back-and-forth
on
the
list
that
he
has
been
successfully
persuaded
that
full
message
isn't
needed,
but
I'll
stop
here
for
a
few
seconds
too
in
case
he
or
anyone
else
has
any
comments
on
this
issue.
Yes,
I'm
convinced
you're
right,
okay,
all
right.
Anyone
else,
yeah.
Y
So
I
want
to
say
that
this
issue
was
well
known
to
the
authors
and
actually
documented
in
the
draft
with
possible
mitigations,
and
it's
fundamentally
tied
to
the
fact
that
this
protocol,
as
it's
written
today,
does
not
provide
authenticated
denial
of
existence
and
what
that
means
is
there's
no
no
way
for
the
TLS
server
to
cryptographically
prove
that
it
does
not
possess
a
signed
TLS.
A
record
victor
is
suggesting
that
we
need
a
more
robust
defense.
Okay,
so
I
have
a
few
more
slides,
but
okay
go
ahead.
All
right
next
slide,
please!
Y
O
Y
Manages
to
induce
the
client
to
connect
to
it.
We
have
you,
know,
spoofing
or
met
in
the
middle,
somehow
ignores
the
DNS
SEC
chain
extension
and
offers
just
plain
PKK's
authentication,
with
the
fraudulently
obtained
potentials
next
slide,
please.
So
our
the
position
of
the
authors
on
this
was
that
this
was
preventing
this.
These
kinds
of
attacks
was
not
an
original
goal
of
this
draft.
Y
I
remember
in
the
very
early
days
of
this
draft,
when
we
had
discussions
with
some
web
browser
folks
who
were
interested
at
the
time
and
implementing
this,
that
there
was
a
debate
about
what
it
means
to
publish
a
TLS
a
record.
Is
that
actually
a
policy
signal
that
compels
the
use
of
Dane
or
is
the
use
of
Dane
entirely
a
client
specific
decision,
a
local
decision
right?
So
so
the
extension
as
it
stands?
It
provides
a
mechanism
to
use
Dane.
Q
Follow
us
so
first
I'll
channel
myself,
I
think
if
the
server
removes
a
Dane
record,
it
should,
in
the
extension,
put
the
denial
of
existence
of
that
Dane
record
in
the
extension.
So
you
just
get
the
insect
change
again:
sick,
three
change.
Let's
say
this
record
is
no
longer
there
and
then
so.
If,
if
the
server
violently
removes.
Q
Because
they
change
their
mind
on
the
policy
of
using
this
extension,
they
should
run
for
a
while,
with
this
extension,
with
no
TLS
record
in
it,
so
that
anyone
who's
contacted
the
server
before
it
now
knows
that,
there's
a
validly
cyan't
answer
saying
I
stopped
doing
this,
and
then
it
can
do
local
policy
in
determining
how
long
or
when
it
decides
that
it
can
accept
the
connection
without
a
TLS
extension
at
all.
I
do
think
that
when
a
client
connected
at
Eli's
extension
suddenly
magically
has
disappeared.
J
Q
It
should
do
something
but
I'm
happy
that
I've,
it's
a
local
client
policy.
It
can
decide.
Oh
well,
you
know,
I
will
go
use
the
real
DNS
instead
and
see
if
I
can
get
the
denial
of
existence
answer
there
if
I'm
not
under
attack,
affirm
under
attack
and
the
DNS
is
also
blocked.
You
know,
I,
don't
know.
I'll
tell
the
use
of
this
looks
fishy,
I'm,
fine,
with
all
of
those
solutions.
Q
Now
putting
on
my
hat
of
victory
company.
He
is
saying
he
really
wants
some
sort
of
time
period
associated
with
this
exchange.
So
when
you
feed
his
extension,
it
means,
like
you,
know,
you're
pinning
it
for
30
days
or
for
actually
he's
I,
think
he's
thinking
of
a
year
or
something
he
wants
it
to.
Okay,
he
can.
G
So
I
just
want
to
highlight
the
fact
that
the
extension
it
could
be
adopted
has
to
useful
for
something
and
presumably
at
scale
rather
than
just
a
few
niche.
You
know
cases
where
you
know
a
priority
that
you
can
do
day
and
and
because
it's
not
currently
in
the
field,
most
servers
are
not
going
to
have
it.
The
only
way
it's
going
to
be
useful
is
if
it's
useful
incrementally
right.
G
The
NICS
tension
offers
no
security
advantage
right,
so
either
pickax
is
secure
and
then
it's
secure,
and
why
bother
with
this
thing
or
there's
a
flaw
in
PKK's,
but
then
it
strips
dein,
potentially
so
I'd
like
to
see
some
purpose
for
this,
and
so
the
client
has
to
have
some
sort
of
sticky
mechanism.
Now
I
heard
Schumann
mention
that
you
know
clients
will
decide
for
themselves
how
long
to
pin
implicitly
pin
the
extension
but
I'm
not
convinced
that
that
should
be
a
solely
a
client-side
decision.
G
G
Excuse
me
have
recalled
some
servers
will
be
able
to
the
awesomer
operators
will
know
that
they're
committed
for
this
forever
and
definitely
whatever
they'll
do
it
until
they
provide
a
veil,
a
valid
denial
of
existence,
and
we
need
to
make
sure
that
the
packet
format
supports
denial
of
existence.
You
know
in
Sec
records,
as
Paul
mentioned,
and
other
servers
may
only
be
comfortable
initially
for
days
weeks
months,
but
it
would
be
good,
I
think
if
that
signal
were
there.
G
On
the
other
hand,
if
there
is
accept
you
know
if
everybody
likes
guidance
which
says
something
like
six
months
or
three
months
or
whatever,
and
we
think
that's
long
enough,
protect
most
clients
that
you
know
if
they
haven't
come
back
in
three
months
to
a
site.
Perhaps
they'll
never
come
back,
then
maybe
you
know
some
fixed
period
can
be
recommended,
but
without
any
recommendation
to
store
the
server's
deign
capability
and
insist
on
it
and
reconnect
until
the
server
provides
denial
of
existence.
I
think
the
standard
is
kind
of
useless.
K
That
would
let
you
get
the
way
they
you
prayed
for
people
who
thought
that
sort
of
the
temporary
period
where
clients
ostensibly
maybe
had
both
on
this
particular
visit.
But
there
you
are,
if
the
rationale
for
this
for
this
the
feature
is,
that
is
that
it's
only
useful
for,
and
hence
all
of
that
sort
of
thing.
If
the
rationale
for
this
feature
is
it
intended
as
a
to
stop
except
red
hairs,
compromising
PA
certificates
like
a
musical
entirely
back
to
the
drawing
board
and.
K
You
know,
and
not
I
have
this
stuff
tacked
on
at
the
very
last
minute,
after
a
tea
review
with
that
said,
the
idea
that
my
clients
won't
take
the
clients
are
gonna.
Take
the
existence
of
Dane
and
then
refuse
to
not
accept
Dane,
for
any
period
of
time
is
like
easily
out
of
touch
with
the
way
web
server
point.
So.
L
K
Have
a
big
farm
of
web
servers
and
I
turn
on
Dane
on
10%
of
them,
and
then
clients
come
back.
They
all
hold
the
same
domain
name,
the
same
origin.
Their
clients
come
back
server
and
now
they
just
can't
reconnect
I
mean
we're
in
the
process
of
work,
people
that
lost
her
rip
out
HTTP,
which
is
a
much
much
better
story
about
not
working
or
stuff
than
this
does,
but
even
so
as
too
terrified
to
run.
K
It's
like
simply
not
lie
the
situation
in
which
the
clients
you're
allowed
to
decide
that,
just
because
you
just
play
Dane
they're
not
accept
PGI.
In
that
feature,
it's
just
like
not
gonna
work
and
in
fact
they
I,
don't
think
it's
going
to
work.
I,
don't
think
the
mechanism
were
like
where
the
server
says
that
is
gonna
work
either,
but
I
certainly
have
a
client
Yolanda's
eyes.
Not
only
is
pulling
the
one.
V
V
V
It
says
whether
you're
in
the
restrictive
or
assertive
cases,
but
you
could
restrict
the
code
point
in
the
TLS
a
record
to
say
this
must
be
an
assertive
Dame
record.
If
you
want
to
make
it
real
clear
on
VI
I
would
suggest
we
rule
the
restrictive
cases
out
of
scope,
at
least
for
this
talk
I'm,
not
saying
we
shouldn't.
We
should
never
do
it
for
sure
we
could
just
copy
and
paste
most
of
the
mechanism.
We
have
here
and
add
some
extra
policy
considerations.
V
Y
Yeah
so
I
think
you
know,
since
one
of
the
target
audiences
for
this
extension
was
the
web,
we
originally
were
trying
to
be
sensitive
to
the
way
that
they
see
positioned,
Dana's
authentication
mechanism,
so
the
TAC
we
were
taking
was
a
model
where
pickax
and
Dana
authentication
coexists
rather
than
Dain
Trump's
pickax,
or
vice
versa,
or
Dana's
used
to
constrain
things
right.
So
that's
where
we
were
originally
Daniel.
Z
AD
AC
Z
That
we're
gonna
hold
this
out
by
child
like
I,
think
that
if
you
want
to
do
try
it
context
specific
policy
that
policy
needs
to
be
done
in
the
place
where
those
clients,
the
client
policy,
is
being
decided
right.
So
if
we
define
the
mechanism
this
as
a
mechanism
for
transport
and
get
the
hell
out
of
the
way
of
the
places
that
actually
want
to
use
it,
those
places
can
decide
whether
clients
should
have
policies
about
caching
or
rejection
or
deferral
or
whatever.
G
G
The
next
time
it
connects
no
matter
which
server
it
connects
to
or
the
server
could
say,
sorry
I'm
not
ready
to
commit.
Yet
my
proposal
specifically
addresses
that
issue.
Now
Esther
Richards
comment
about
additive
versus
you
know,
restrictive
I
think
that's
completely
orthogonal
to
this
extension
I'm.
G
You
know,
given
that
most
of
them
are
domain
validated
whose
strengths
I,
you
know,
I'm,
not
that
confident
about
then
I
think
we're
we're
we're
fumbling.
This
extensions
value,
we're
not
we're
not
using
it
thoroughly
gained
it.
You
know
proper
security
in
the
weapon
it'll
continue
to
be
ignored
in
the
web.
G
Now,
maybe
that's
the
idea
that
we
really
don't
care,
we'll
never
be
done
in
web
servers
and
clients
and
I
should
just
give
up,
but
I
think
it's
worth
making
it
possible
to
use
it
in
the
web
in
a
way
that
actually
offers
some
protection,
which
requires
downgrade
resistance
and,
as
written,
there's
no
downgrade
resistance.
It's
simply
not
there.
Unless
the
client
is
in,
you
know
knows
that
it
will
be
there.
Maybe
with
d-pryde.
G
Y
V
Y
So
you
need
to
service,
deplores
need
to
be
worried
about
pickax
threats,
so
you
may
have
a
server
that
supports
both
Dane
and
traditional
pickax,
in
which
case
are
probably
paying
attention
to
CT
logs
and
even
if
it's,
the
Dane,
only
server
the
operator
of
that
service
may
be
concerned
that
other
attackers
are
not
able
to
impersonate
their
service
to
Dane
unaware
clients.
So
then
you're
going
to
have
to
look
at
pickax
solutions
to
this
problem
anyway.
Y
So
that's
there's
another
mechanism
that
I
offered
by
which
you
may
be
able
to
gain
some
downgrade
downgrade
attack
protection.
So
can
you
advance
next
slide
so
I'll
just
but
I
think
we've
already
discussed
what
Victor's
proposal
is,
but
I'm
just
going
to
leave
it
on
on
the
slide.
So
you
can
look
at
it
in
detail
and
then
we
can
continue.
O
Very
nicely
summarized
what
I
wanted
to
say
so
I
strongly
support,
Victor's
idea
that
there
should
be
one
integer
which
says
I'm
committed
to
doing
this
for
next
and
seconds
and
if
it's
zero,
the
server
is
not
committed.
Maybe
it's
doing
the
roll-out
incremental
rewrite.
Then
the
server
can
use
some
longer
value
and
then,
if
this
every
size,
oh,
this
was
a
horrible
idea
and
I'm
going
to
something
else
and
I
want
to
rip
off
this
extension
and
never
see
it
again.
O
Y
So
I
imagine
that
the
change
is
proposing
is
not
only
introducing
that
integer
and
the
and
the
the
pinning
commitment
period,
but
it's
also
introducing
an
implementation
that
requires
the
server's
to
send
a
full
authenticated
denial
of
exchange
or
non-existence
of
the
TLS,
a
record
which
it
doesn't
do
now.
There
is
some
authenticated
denial
stuff
there.
It's
related
to
wild
card
proofs
and
stuff
right,
but
not
for
an
X
domain
responses.
So
that
would
be
another
change.
Yes,
specifically,
the
text
about
the
negative.
O
AE
Sriman
sir
I
had
some
questions
on
sort
of
this
extension
with
regards
to
large-scale
rollouts,
so
troubleshooting
large-scale
rollout,
so
is
their
ability
to
turn
it
on
in
passive
mode.
Is
there
a
way
of
getting
from
the
clients?
Some
logging,
for
example,
with
the
content,
security
policy
or
a
tea
mark?
They
have
sort
of
reports
URI
to
return
information
there,
and
then
it
provides
a
little
bit
more
signal.
So
we
understand
that
organically.
This
works
over
time.
Y
Right
so
I
mean
that's
something
that
the
clients
could
passively
inspect
today,
there's
no
explicit
pledge
or
anything
that
tells
this-
is
report
mode
versus
authentication
mode.
Today,
yeah
lines
could
examine
the
presence
of
this
extension
without
actually
using
it
to
perform
authentication
of
the
server.
That's
that's
always
possible
sure.
AE
Y
Y
Q
AB
Q
J
Q
Because
all
the
the
information
lives
authority
in
the
DNS
and
it
should
be
updated
there
and
it
can
be
updated
based.
You
know,
we've
got
TTL
values
that
deal
with
all
of
these
conditions.
Of
you
know:
migration
from
adding
or
removing
this
information.
Now
we're
putting
it
into
this
DNS
extension
and
this
TLS
extension
as
an
optimization
and
a
way
of
making
sure
that
we
can
obtain
this
information,
even
if
our
DNS
path
is
unclean
and
even
if
you
know
in
order
to
avoid
extra
latency
of
doing
these
lookups
so.
L
W
M
Q
You're,
if
this
optimization
cannot
be
used
because
suddenly
you
know
you're
under
attack
and
someone
that
someone
has
taken
another
peak,
exert
and
put
it
in
the
server.
You
know
your
fallback
method
is
not
to
use
the
optimization
and
go
look
Indian
s,
and
if
you
cannot
look
it
up
in
DNS
separately
from
a
separate
path,
just
assume
you're
under
attack,
so
so
to
me.
I
think
we
do
not
need
any
kind
of
pinning
in
this
extension,
because
we
have
we've
got
the
exact
lifetimes
and
validity
in
DNS.
Q
This
is
just
an
optimization
where
we
need
to
do
this,
so
the
draft
only
needs
to
say
if
the,
if
it's
removed
from
DNS,
we
must
make
sure
that
this
optimised
path
is
also
updated
to
put
in
the
information
of
non-existence.
So
that's
to
me
is
the
only
thing
that
should
be
added
to
the
draft.
Then
everything
else
can
become
just
behavior
right.
Y
Yes,
I
understand
that,
so
the
problem
is
introducing
full
authenticated.
Denial
in
this
mechanism
is
difficult,
because
then
it
imposes
a
barrier
to
incrementally
deploying
the
extension
in
the
field
because
it
requires
all
TLS
servers
to
understand.
Dns
second
be
able
to
build
negative
proofs
for
the
fact
that
they
don't
have
a
TLS
record.
Okay,
let's
say
a
record
so.
Q
If
we
can
answer
that
I'm
so
so
you
have
something.
The
reason
we
use
DNS
format
is
that
the
extension
can
use
Dinah's
libraries
that
support
all
of
this
so
also
eating.
These
extensions
should
be
easy
for
all
those
kinds
of
do
if
you're
talking
about
the
the
way
how
you
deploy
it
as
incrementally
in
some
service
to
and
some
servers,
don't
support
this
extension.
Q
V
V
Kp
is
ekor
mentioned
it
got
CT,
both
of
which
had
CT,
especially
much
more
momentum
and
deployment
than
date,
and
still
we've
had
to
be
very
cautious
in
that
mechanism
to
be
because
people
expect
CT
is
still
pretty
controversial,
even
as
the
universal
requirement
is
on
its
way,
and
so
talking
about
things
that
are
restricting
authentication
making
deployable
and
has
all
pointing
up
coming
up
with
a
fallback
story
when,
when
things
get
interfere
with,
it's
super
complicated
into
this
lots
of
subtle,
edge
cases
and
deployment
cases-
and
you
know
if
we're
going
to
launch
down
that,
it's
going
to
be
a
big
pilot
work
so
back
to
the
meta
points,
let's
not
snatch
defeat
from
the
jaws
of
victory.
V
Here,
let's
take
the
thing
that
we've
got
that
can
deploy
in
certain
circumstances.
It's
dkg
points
out
can
be
used
for
things
like
deprive,
let's
polish
it
up
and
and
get
some
use
out
of
that,
and
then,
if
there's
interest
in
history
restrictive
case
later
by
all
means,
let's
let's
do
the
work
and
get
something.
Z
Z
K
Yeah
I
think
so,
as
I
said,
any
mechanism
which
requires
you
to
update
to
arrange
that
the
client
experiences
the
same
thing
has
a
consistent
experience
across
all.
Your
servers,
like
as
a
condition
of
employment,
is
like
total,
non-starter
and
I
need
and
any
and
any
and
any
like
an
even
one.
That
requires
the
servers
that
have
deployment
to
serve
Dane
records
and
the
servers
that
don't
have
deployment
to
serve
a
non-dangerous
so
that
the
design
of
the
Thank.
K
You
know
from
the
from
the
server's
perspective,
given
the
like
apply
it
like
you
know
to
to
require.
That
is
really
another
negative
impact
on
deployment
of
this
functionality.
We
know
how
to
add
that
functionality
later,
if
we
want
it
and
and
as
DG
said,
we
have
a
number
of
situations
where
clients
cuz
we
configure
themselves
to
require
this
like
this
is
not
gonna,
be
like
you're
gonna
write
this
down
and
then
you're
gonna,
like
you
know,
be
a
mess
call
again
in
two
weeks.
This
is
going
to
be
like
than
a
year
doing
this.
AF
Erica
Negron,
Akamai
and
kind
of
add
on
to
that
I
think
the
the
if
the
peak
keep
pinning
stuff
pH
PKA
stuff
makes
you
be
the
really
good
thing
to
look
at
in
terms
of
how
badly
that's
failed
and
all
the
problems
with
it,
and
in
particular
it's
not
just
the
canyon
brick
yourself,
which
is
a
huge
foot
gun,
but
it's
also
the
security
vulnerabilities
associated
with
that
it's
being
used
for
ransomware
attacks
and
what
you
can
see
here
is
once
you
do.
This
is
even
as
a
restrictive
mode.
AF
The
state
of
DNS
SEC
is
not
great
right
now,
like
those
map,
RG
talk
was
talking
about
how
many
new
people
are
using
non-rotating
RSA
1024
bit
keys
is,
you
know,
get
into
a
situation
where
people
just
start
pinning
compromising
the
keys,
pinning
and
then
trying
to
pin
these
records
in
Tobruk
to
brett
people
who
aren't
really
to
Folly
go
ahead
and
deploy
things,
and
that
seems
like
could
make
things
worse
rather
than
better,
even
for
the
restrictive
case
right.
Y
AF
G
G
The
there
is
no
there's
no
bricking
involved
here
regulates
what
are
likely
don't
indicate
time
from
the
server,
because
clients
will
make
the
wrong
assumption
because
they
need
to
right.
If
the
server
can
explicitly
said
you
know
no
to
cache
that
I'm
not
ready,
then
the
client
will
know
the
server
is
not
ready
as
to
pause
comment
that
you
know
you
can
fall
back
to
DNS.
G
Unfortunately,
that's
completely
wrong,
because
the
the
reason
that
that
clients
don't
do
the
DNS
lookup
is
because
it's
it's
too
slow,
you're
not
going
to
do
it
for
every
server
that
fails
to
offer
the
extension.
You
know
right.
The
web
browsers
have
avoided
this
precisely
because
the
cost
of
all
the
extraneous
lookups
too
high,
so
the
web
clients
are
not
going
to.
You
know,
do
the
fallback
for
every
single
server
on
the
web
because
it
looks
like
all
of
them
are
under
attack.
G
So
that's
all
back
isn't
going
to
happen
and
the
pinning
is
just
a
single
bit.
It
isn't
there's
no
breaking
risk
here,
we're
just
asking
the
server
to
not
stop
offering
the
extension
for
a
time
of
its
own
choosing,
and
let's
be
quite
clear
on
that.
It
is
not
the
client
that
decides
the
time.
If
we
don't
specify
that
in
the
extra
bite,
then
the
client
will
in
fact
incorrectly
make
assumptions
some
implementations
right.
G
Let's
future
proof
list
and
make
it
possible
later
desirable
in
the
servers
to
offer
a
nonzero
cache
time.
We
can
in
fact
write
the
recommendation
that
initially
servers
should
always
put
0
there
for
the
moment
that
we'd
gain
more
experience
with
it
and
then
later
that
it's
right
when
they're
ready
and
then
clients
could
start
caching
it.
But
let's
the
future
proof
is
to
make
it
usable
it
locks
out
all
kinds
of
use
cases
by
not
having
the
element
there.
So
we.
C
So
I
think
the
what
I'd
like
to
do
is
get
a
sense
of
the
room
if
it
was
kind
of
brought
up
that
we
have.
The
the
current
draft
is
sort
of
additive
in
its
authentication
mechanisms
versus
being
restrictive
and
like
to
get
a
sense
of
people
think
that
this
additive,
you
know,
authentication
without
any
sort
of
pinning
or
does
not
denial.
C
A
big
non-existence,
I
think
out
that
right,
yeah
I,
think
will
do
a
home
to
make
sure
that
to
see
if,
if
people
think
they're
still
value
in
the
additive
case,
in
just
an
additive
authentication
mechanism,
so
I'll
ask
two
questions
and
we'll
do
it
based
on
on
this
draft
to
make
it
a
little
bit
clearer.
So
do
you
think
that
the
current
mechanism
in
the
draft
is
useful
and
sufficient?
C
Z
Go
ahead
with
that
or
if
we're
saying
don't
say,
like
don't
put
any
restrictions
on
the
current
draft,
if
you
put
a
little
bit
of
guidance
in
the
current
draft,
that
says
note
that
if
you
put
restrictive
things
in
there,
clients
may
not
make
mint.
It
may
disagree
about
what
to
do
with
them
right.
There's
a
difference
between
saying
this
is
be
possible
for
pudding
and
I.
Wish
I
could
remember
whether
it's
Dean
two
and
three
year
game,
one.
Z
Z
So
you're
exactly
which
which
direction
like
are
we
saying
we
should
add
that
explicit
restriction
or
are
we
saying
just
put
a
note
that
says
we
encourage
the
use
of
this
with
with
zero
and
one,
and
you
know
there
be
dragons
with
two
and
three:
let.
K
K
They
ought
to
have
they
just
they
just
they
just
take
it
as
it
comes
and
I
agree
that
a
consequence
of
that
is,
it's
not
usable
first
to
diffuse
cases,
but
that's
not
like
that's
that's.
That's
that's
taxes,
not
and
so
I
think
we
should
first
decide
whether
we
want
to
do
whether
we
want
to
do
anything
along
those
lines
and
if.
Y
C
C
C
I'm
sure
I'm
sure
humming,
but
we
couldn't
hear
them
so,
but
yeah
yeah.
So
in
summary,
you
know
the
general
feeling
of
the
room
is
that
this
draft
is
useful
without
pinning
and
I
think
well,
that's
kind
of
the
direction
we're
going
to
try
to
take
it
on
the
list,
and
you
know
this
doesn't
preclude
us
from
developing
a
painting,
extension
and-
and
if
you
know,
people
think
that's
really
critical,
then
that
work
should
continue
should
be.
You
know,
started
and
continued.
J
Would
that
definitely
be
start
it
in
a
different
draft,
or
might
this
be
amended
right
because
then
there's
different
drafts,
so
in
effect,
there's
been
no
changes
to
the
strap
and
any
new
work
to
it
would
happen
in
a
different
draft
anyway.
Yet
the
discuss
is
cleared.
Should
this
be
approved
today,.
Z
J
C
Q
If
the,
if
there's
text
that
said
you,
if
you've
put
in
a
TSA
record
before
and
you
remove
it,
you
should
put
in
a
denial
of
existence,
proof
would
be
extremely
helpful
for
those
people
that
already
want
to
do
more.
I
want
to
think
about
pinning
later
I.
Don't
think
it
actually
harms
that
people
who
don't
want
to
do
that.
So
it.
J
G
J
Y
Y
K
B
Y
AI
Y
J
I
So
one
of
the
reasons
the
exported
authentic
areas
were
the
kind
of
sitting
on
it
is
waiting
for
some
formal
analysis
and
now
we're
gonna
get
to
hear
about
that.
So
thank
you.
Hi.
AH
So,
what's
are
they
very
briefly
they're
a
post,
handshake,
authentication
mechanism,
that's
supposed
to
replace
TLS
1.2
renegotiation
and
provide
a
more
versatile
version
of
post
handshake
authentication
than
the
post
handshake.
Client
authentication,
that's
already
there.
So
how
is
it
more
versatile?
It
allows
multiple
identities
for
the
client
and
the
server
next
five,
please,
okay,
very
brief
version
of
the
protocol.
AH
Either
party
is
allowed
to
send
typical
requests
and
they
get
back
an
export
Authenticator
or
the
server
can
just
send
an
exportable
Authenticator
and
the
expulsion
Authenticator
is
certificate
if
you
could
verify
finished,
which
is
just
copied
straight
from
the
TLS
handshake
and
because
that's
really
been
quite
well
analyzed.
So
next
slide,
please!
AH
So,
if
I
have
a
run
of
layered
authentication
of
layered
authentication
protocol-
and
at
least
one
of
those
one
of
my
peers,
identities
has
not
been
compromised
to
one
of
the
peers
secrets
is
unknown
to
the
attacker.
Then
I
know
that
the
peer
agrees
with
me
on
everything,
all
the
identities
and
all
the
bindings.
So
this
is
a
bit
of
a
counterintuitive
property,
it's
actually
very
powerful
property.
AH
But
basically
it
says
that
in
our
case
that
the
as
long
as
either
the
TLS
channel
is
good
or
the
private,
their
private
key
of
the
certificate
is
uncompromised.
Then
we've
got
what
we
want
next
slide,
please.
So
what
we
did
was,
we
did
a
two-part
analysis.
We
did
a
manual
or
by
hand
proof,
and
then
we
did
a
tool
supported
proof.
AH
And
we
then
did
a
tool-assisted
proof,
and
so
we
did
this
secondary
proof
such
that
we
can
explore
the
guarantees
that
we
get
so
the
compound
earth
property,
as
defined
in
the
literature,
says
under
a
particular
threat
model.
You
achieve
a
particular
property,
so
we
used
tamarin
to
explore
what
happens
if
we
change
the
threat
model
and
what
happens
if
we
vary
the
property
and
try
improve
this
sort
of
in-between
thing
and
another
benefit
of
tamron
is,
if
it
says
no',
then
you
get
a
counter
example.
AH
That
says
here
is
a
run
at
the
protocol
that
breaks
your
property
next
slide
please.
So
the
results
of
our
overall
analysis
is
that,
yes,
the
TLS
channel
and
Explorer
Authenticator
are
securely
bound
to
each
other
and
achieve
compounds
authentication.
So
what
that
means
in
practice
is
to
forge
an
exported
Authenticator.
Some
attack
would
have
to
know
the
master
secret
of
the
TLS
Channel
and
the
private
key
of
the
certificate.
AH
So
you
know
basically
the
attacker
knows
all
the
secrets
and
you
lose,
but
otherwise
you're
fine,
but
what
that
means
is
if
the
master
secrecy
uncompromised.
So
if
you
don't
have
a
threat
model
that
considers
the
master
secret
being
compromised,
then
you
have
a
join
to
authentication
between
two
aids.
So,
if
I
receive
two
EA's
over
the
same
to
your
last
connection,
I
know
that
they
were
both
created
by
the
same
person.
Next
slide
please
so
this
was,
you
know
a
little
bit
I'm
exciting
from
a
formal
analysis.
AH
It
just
said:
yeah,
everything's,
fine,
so
I
thought.
How
far
can
we
push
this
right?
Can
we
get
even
stronger
guarantees,
and
actually
you
can?
How
far
can
we
push
this
for
this
breaks?
You
actually
have
to
have
a
ridiculous
attacker
model
before
things
break,
which
is
if
the
attacker
can
compromise
of
the
master
secret
and
knows
some
private
keys,
because
the
Explorer
authenticators
are
not
explicitly
bound
to
each
other.
AH
You
can't
guarantee
that
they're
all
created
by
the
same
person
and
that's
what
we're
trying
to
prove
that
all
the
exported
authenticators
are
created
by
the
same
person
and
we're
working
on
potentially
stronger
version.
If
anyone
wanted
it.
So
is
this
a
threat
model,
that's
actually
plausible.
Well,
potentially,
if
something
like
draft
green
or
drafts
are
HRD
had
been
taken
up
or
even
if
the
industry
decide
to
just
export
the
server
keys
to
enable
visibility
that
could
potentially
break
exported.
AH
AJ
AH
K
P
Know
that
I
guess
the
difficult
question
for
the
room
here
is
whether
or
not
we
care
about
this
throat
model
enough
to
do
something
about
it.
Now
I'm
talking
to
Johnson
about
this
quite
a
bit,
and
there
is
a
fix
right,
there's
a
yes
there's
a
fix
for
this,
and
it
simply
means
some
modifications
to
the
program.
Now
these
modifications
can
be
essentially
voluntary
in
a
sense.
No,
but
there's
some
value
and
having
the
counterparties
actually
understand.
What's
going
on.
J
AH
So
there's
two
versions-
I
guess
of
my
fix
one
of
them-
is-
doesn't
require
any
on
the
wire
changes.
It
just
changes.
So
a
one
at
the
moment.
There's
a
requirement
on
the
certificate
request.
Context
have
a
particular
have
a
particular
form,
ie,
it's
less
than
a
certain
length
and
that's
the
only
requirement,
and
so
we
can
use
that
to
pack
some
other
stuff
in
it,
or
this
could
be
done
as
a
TLS
extension
and
then
that
requires
on
the
wire
changes,
but
it
and
you
can
achieve
yeah
bindings
between
different
days.
So.
P
Myself,
I
think
that
it
would
be
a
reasonable
tweak
to
the
formula
to
actually
add
this
I
suspect
that
we
might
be
able
to
do
it
as
a
separate
document,
and
so,
if
we
do
that,
then
I
would
rather
have
it
be
explicit
rather
than
the
yet
something
with
certificate
request
contexts.
But
if
we,
if
we
build
that
little
extra
piece,
then
we
can
get
some
sort
of
assurance.
P
Not
only
do
we
have
this
property
in
the
case
where
the
master
secret
or
resumption
secret
or
anything
that's
derived
in
that
particular
path
is
secure,
but
also
we
have
the
property
in
the
case
where
hey
someone
decided
that
with
the
master
secret
somewhere
and
it's
built
in
races,
but
it
you
see
that
little
bit
of
extra
short
even
about
how
things
are
operating
and
it
doesn't
appear
to
cost
all
that
much
so
for
context.
You
put
the
finished
message
from
the
last
one
in
the
next
one
and
you're
done
and
that's
under
number
yeah.
P
There's
a
there's,
a
bunch
of
ways
in
which
that
fails-
and
you
have
to
deal
with
that,
particularly
in
the
usage
model
that
we
envisage
HTTP.
But
essentially,
that's
that's
the
intuition
that
yeah
yeah,
it's
pretty
straightforward,
really
quite
simple,
and
it
can
fix
a
bunch
of
problems.
You
can't
make
it
inclusive,
unfortunately,
which
would
be,
which
would
have
been
a
great
way
to
do
this,
but
we're
not
quite
there.
Yet
we
don't
have
reliable
protocols.
It
turns
out.
M
Been
Caidic
so
Martin
just
asked
you
do
we
care
about
this
threat,
basically
and
you're
just
to
make
it
really
clear.
Any
attacker
can
get
a
certificate
and
the
private
key
for
it.
So
this
sort
of
degenerates
to
the
case
where
the
master
secret
is
leaked,
and
we
have
examples
where
that
happens.
So,
yes,
correct
with
superior
and
yeah.
AH
M
M
AH
R
AG
Thanks
thanks
for
doing
this,
Nick
solving
parlors
thanks
for
the
analysis,
I'm,
not
entirely
convinced
that
the
compound
authentication
adds
hoo-wah
and,
at
least
in
the
use
case,
additional
certificates
hb2
best
draft.
The
threat
model
seems
a
little
bit
bizarre
in
that
you
have
a
connection
that
you've
established
now
you're
going
to
be
using
to
try
to
send
these
authenticators
and
it
is
compromised
partway
through
where
the
connection
has
been
compromised.
Partway
through
and
the
exported
authentic
air
had
been
put
on
the
wire
before
a
key
update
mechanism.
So
otherwise
you
can.
AG
AH
AG
AH
The
the
guarantee
you
would
get
in
the
in
the
joins
case
is
actually
only
until
the
last
good
certificate.
So
if
I
knew
that
a
particular
certificate
was
compromised,
I
could
still
and
I
so
I'm.
You
know
whatever
CloudFlare
and
I
have
I
know
one
of
my
stiff.
It's
been
compromised
and
then
I
have
another
certificate
that
is
now
good.
Then
I
can
join
those
together
as
long
as
they
there's
only
you
only
get
the
guarantee
for
the
last
good
certificate
and
all
ones
before
it.
AG
So
so,
I
think
from
the
analysis.
It
seems
that
the
current
draft
is
written
is
relatively
robust,
with
respect
to
being
able
to
add
a
certificate
to
and
associated
with
the
connection,
not
necessarily
with
other
certificates.
Yeah,
that's
very
long,
and
my
recommendation
would
be
to
go
forward
with
that
and
then
have
if,
if,
if
there
was
the
demand,
the
need
for
the
stronger
compound
authentication
in
it
had
a
specific
use
case
that
we'd
go
forward
with
a
different
draft
on
that
that
would
build
on
on
it
explicitly
with
the
TLS
extension.
AI
K
I
mean
I'm
not
to
change
it
here.
It
changes
here,
I'm,
I,
guess,
I'm
I
see
a
lot
of
work
for
the
past
couple
years
and
people
trying
to
like
Creeper
choice.
Three
situations
reports
are
compromised
like
they
properly
I
mean
CTLs
like
that
is
really
about
that,
and
my
experience
is
the
answer
is
typically
pretty
terrible
and
that
like,
if
you
couldn't
a
lot
of
trouble,
I
try
to
like
you
know
design
for
them
in
those
cases,
often
in
order
to
issue
their
pulse.
AH
K
K
K
K
To
be
no,
the
fresh
is
enough.
Let's
imagine
imagine
what
I
did
is
I
just
use
a
counter
right,
yeah,
that's
fresh,
but
the
problem
is
the
attacker.
The
attacker
compromises
the
key
he's
using
the
sine
the
EI
at
time
T
and
he
has
temporary
access
right
and
then
he
generates
regenerates
in
da
right
now.
If
you
have
a
random
value
that
just
happens
to
work,
but
if
you
have
a
non
random
value,
even
if
it's
fresh
that
fact
does
work.
So
that's
why
that's?
Why.
P
AH
O
AH
P
So
everyone
has
a
little
more
context,
does
actually
address
this.
This
question
reasonably
well,
if
I
actually
putting
both
values
in
there.
That's
fine
yeah,
but
I
was
actually
gonna
suggest
that
what
we,
what
we
might
want
to
do
is
given
that
there's
this
self-service
option
available
to
people
that
sort
of
want
to
do
this.
P
We
we
leave
the
self-service
option
as
as
a
possibility,
and
we
leave
open
the
possibility
of
adding
an
extension
to
have
the
explicit
communication
about
the
fact
that
the
self-service
option
is
there
or
have
some
sort
of
explicit
way
to
bind
things
together
in
the
future,
but
I
think
we
can
probably
proceed
with
the
draft,
as
is
based
on
the
feedback
on
fruit.
That
would
be.
P
K
As
I
understand
it,
because
the
way
you're
designing,
but
it's
the
way
of
because
of
binding,
who
is
a
previous,
you
know
finished
right
now
you
created
a
new
application
in
variant,
which
is
these
they've
got
an
order
and
they
sent
in
the
portal
right.
So
right
now
the
application
in
Burien.
They
don't
give
in
an
order.
You
could
do.
You
could
make
two
per
customer
cart
you
it.
You
can
like
do
two
for
to
the
nikah
doors
and
they
could
be
delivered
in
either
work
right
and
so
and
so
like.
J
K
AH
So
what
it
basically
boils
down
to
is
you
you
don't
actually
build
a
linear
thing.
You
build
a
tree
and
if
the,
if
you
have
certificates
across
a
TAS
crossing
in
midair
yeah,
then
you
at
you
might
end
up
with
to
a
tree
that
splits
and
then
each
side
has
to
process
one
more
EA,
and
now
we
get
back
to
might
might
think
about
like
this
game
for
garnish
yeah
yeah
I
mean
oh
well,
I
can
reason
about
it.
Fine,
yes,.
M
AK
I
All
right
so
I
think
we
got
to
wrap
up
here,
so
I
think
what
basically
I've
been
hearing
is
that
we
can
progress
forward
with
the
kind
of
draft
as
is,
and
then
we
want
to
have
a
more
stronger
mechanism.
We
need
to
do
it
in
another
extension
and
you're,
going
to
happily
provide
a
paper
for
us
right
sure
it'll
be
great,
all
right
cool.
Thank
you
very
much.
Vicki.
L
Cloudflare
I'm
one
of
the
authors
of
the
certificate
compression
draft
along
with
Victor
from
Google.
That's
like
a
bit
of
context.
First
for
those
that
missed
the
previous
discussions,
we
want
to
compress
certificates
for
couple
reasons.
One
is
quick:
quick
Sanjay
combines
both
TLS
and
chicken
connection
establishment
in
the
same
mechanism,
so
it
reduces
the
amount
of
round
trips
required
to
establish
a
connection
compared
to
TLS
over
TCP,
but
it
also
makes
it
very
easy
to
mount
reflection,
attacks
with
a
fairly
big
amplification
factor.
L
So
quick
provides
a
an
optional
source
address
verification
mechanism,
which
adds
an
additional
round
trip
to
the
end
check.
But
if
we
can
reduce
the
amplification
factor,
then
we
can
remove
the
need
for
this
address
verification
and
the
additional
round
trip,
at
least
in
some
cases.
The
other
reason
is
that
sending
fewer
bytes
can
be
advantageous
for
Kaos
over
TCP
as
well.
Your
pockets
are
needed
that
can
be
lost
and
would
need
to
be
retransmitted
and
that's
right.
So
it
turns
out
that
compressing
certificate
is
actually
quite
effective.
L
Victor
presented
some
measurements.
He
did
that
idea.
90,
eight
from
a
sample
of
a
few
thousand
certificates.
He
measured
at
30
percent
size
reduction
at
median
and
almost
50
percent
at
95th,
percentile
using
broadly
and,
of
course,
fewer
packets
than
are
needed
to
send
those
chains,
and
that's
like
the
draft,
went
through
a
few
rounds
of
discussions.
Already,
thanks
to
everybody
who
participated,
we
now
support
both
compression
for
server
and
client
certificates
for
server
certificates.
The
client
advertises
the
algorithms
it
supports
as
part
of
a
client,
hello
extension
called
compress
certificates
and
then
the
server.
L
If
the
server
decides
to
compress,
then
it
sends
back
compressed
certificate
message
rather
than
the
usual
certificate
message.
This
message
contains
all
the
information
needed
to
decompress,
as
well
as
the
compressed
certificates
and,
of
course,
if
the
server
doesn't
want
to
compress
or
doesn't
support
compression,
and
it
just
sends
the
normal
certificate
message-
that's
like
for
client
certificates,
the
server
advertises
the
algorithms
it
supports
as
part
of
the
same
extension,
but
this
time
inside
the
certificate
request
message
and
then
the
client
sends
back
either
compress
certificate
or
the
normal
certificate
message.
L
So
the
main
point
here
is
that
server
certificate,
compression
and
client
certificate
compression
can
be
negotiated
independently
next
slide.
One
change
that
we
did
was
to
only
define
this
mechanism
for
Kilis.
One
point:
three:
one
reason
is
that
extensions
as
part
of
certificate
request
are
jealous.
One
point
three
feature,
but
also
this
prevents
middleboxes
from
intercepting
compressed
certificate
and
then
get
confused
by
it,
because
in
TLS,
1.3
certificate
and
compress
certificate
would
be
encrypted
next
slide.
I
The
basic
premise
of
this
is
that
they
think
they're
ready.
We've
asked
enough
questions.
They've
changed
some
things
around.
Are
there
other
people
that
are
planning
on
implementing
to
experiment
with
this,
so
that
we
can
actually
start
the
early
coop?
What
assignment
this
lot?
That
does
not
mean
that
the
draft
is
done,
but
do
people
think
it's
clear
enough
and
staple
enough
to
actually
get
an
early
couplets
on
that?
That's
that's
really.
The
question
now.
K
To
say
is,
like
you
know
it
they
just
based
on
my
previous
appearance.
Oh
that's
kind
of
stuff
like
we're
gonna,
probably
find
some
stuff.
We
don't
wanna
learn.
We
have
to
change
a
lot
of
code
points,
so
I
think
the
earlier
point
assignment
you
know
mechanism
is
not
really
great
fit
for
the
kind
of
work
we
do
here.
But
given
some,
we
got
I
think
if
the
chairs
or
chairs
an
ad
you're
going
to
bend
the
rules
a
little
bit.
K
I
think
you
know
it's
fine
to
do
a
complete
assignment
that
you
know
we
squat
on
here
right
I
mean
like
this
is
I
mean
the
too
many
our
basic
like
we
just
write
something
down
in
the
wiki
and
like
then
we
squatted
it.
Well,
we
do
a
couple
assignment,
we
squat
in
it
and
either
case.
You
know
the
thing
that
they're
either.
J
K
K
AD
I
So,
generally,
that's
why
we're
doing
the
eye
on
a
registry
draft
update
right
is
to
kind
of
lower
the
bar.
So
we
can
do
this,
so
that's
I
mean
I'm
kind
of
like
our
people
violently
objecting
and
if
no
one
is
then
great,
we
can
just
get
that
process
started
at
some
process.
Thing
or
I
send
a
message,
the
mailing
list
and
we
go
yeah
yeah
yeah.
So
the
abies
has
something
to
watch.
Yeah
I.
AD
I
L
S
Ian's,
when
Google
I'm
very
supportive
of
this
as
a
person
who
operates
a
bunch
of
servers
that
I
don't
want
to
make
them
play
attacks,
and
I
also
don't
want
to
make
all
my
aunt
HT
to
our
titties
so
obviously
like
yeah.
Thank
goodness
because
I
mean
if
people
looked
in
Victory's
numbers,
my
memory
is
basically
without
this,
something
like
half
or
more
of
Surtur
large
enough
that,
under
the
current
with
guidelines,
you
would
have
to
have
a
2
R,
2,
T
n
Sheikh.
He
didn't
have
a
resumption.
Okay,.
AA
AL
L
K
K
I
U
AL
I
L
L
Because
that's
where
I
assess
what
we
have
that
the
dwarf
has
basically
five
parts,
this
first
and
an
introduction
which
provide
the
motivation.
Why
you
want
to
do
that
and
why
you
want
to
do
that?
Is
that
effectively?
There
are
two
pieces
of
metadata
that
are
sticking
out
on
the
Internet
today
outside
of
the
encryption
domain.
L
One
are
the
DNS
names
that
you
send
in
DNS
queries
and
the
other
one
is
the
sni
that
you
send
in
TRS
heroes,
and
it
turns
out
that
we
have
a
good
ender
now
on
DNA
on
DNS
encryption,
the
several
solutions
are
available,
so
the
SNI
in
clear-text
really
sticks
out
and
as
sweet.
The
motivation
we
have
to
have
a
way
for
people
want
to
be
discreet
to
encrypt
the
sni
or
hide
it
somehow.
L
We
don't
have
that
much
consensus
on
the
proposed
solutions
and
one
one
of
the
solution
when
the
HIV
solutions
of
your
solutions,
documentation
of
stuff
that
does
exist
in
h-e-b
today,
but
the
proposed
solution
using
either
tunneling
or
session,
resumed
of
basically
low
consensus.
So,
let's
be
clear,
my
proposition
is
that
we
want
to
make
forward
progress
there
and
that
what
progress
will
mean
discussing
the
solutions
and
to
do
that.
I
would
like
to
first
I,
mean
least,
provide
this
list
of
attack
in
some
kind
of
information
or
RFC
by
excising.
J
I
Yeah,
thank
you
know.
D
I
make
normally
TLS.
Doesn't
we
haven't
done
these
kind
of
things
where
we
split
it
out,
but
like
the
kind
of
analysis
over
here
that
have
other
documents
that
explain
the
protocol?
It's
just
not
something.
We've
done
a
lot.
So
it's
the
kind
of
question
is:
are
we
okay
with
that
would
be
okay
like
separating
it
out
and
having
behaved
you
sponsor
the
first
part,
and
then
we
just
work
on
the
solutions
and
that's
kind
of
the
the
range
of
questions
I
was
hoping
we
could
kind
of
like
track
down.
I
P
This
is
somewhat
of
an
exceptional
case,
a
lot
of
the
other
things
that
we're
doing.
There
is
a
solution,
and
we
just
made
a
bid
on
it
till
everyone's
happy
with
that
solution.
But
here
no
one's
really
unhappy
with
any
of
the
solutions,
because
all
of
them
have
various
costs
and
there's
various
trade-offs
that
you
might
make
in
a
particular
deployment.
There
would
move
you
toward
towards
one
solution
over
the
other,
or
maybe
you
just
can't
deploy
any
of
the
solutions,
and
you
know
it's
just
too
hard
a
problem
for
you.
P
I
think
I
think
this
is
a
reasonable
strategy
for
dealing
with
that.
Having
having
the
description
of
the
problem
statement
and
the
requirements
and
some
of
the
reasons
that
people
do
SNI
in
a
document
helps
establish
a
bit
of
a
bit
of
a
footing
on
which
we
can
then
talk
about
solutions,
and
the
solution
was
honestly
each
one
of
those
is
gonna,
be
yeah,
take
it
or
leave
it.
This
is.
P
I
AG
AG
So
what
the
semi
static
mode
is.
It
is
rather
than
when
you
do
a
resumption
using
a
PSK
that
was
established
from
a
previous
connection.
You
use
a
diff
in
public
key,
that's
sent
from
the
server
whether
as
a
as
part
of
the
the
session
ticket
or
through
other
means,
and
one
of
the
issues
we
had
was.
What
does
this
other
means
mean?
AG
There
are
suggestions
of
doing
it
through
DNS
and
and
other
mechanisms,
but
none
of
them
really
made
a
lot
of
sense
versus
versus
a
PSK
there
weren't,
so
many
use
cases
to
justify
being
part
of
the
main
draft.
So
the
technically
speaking,
the
way
that
this
would
work
is,
rather
than
signing
the
entire
handshake
as
a
certificate,
verify
what
you
would
do.
Is
you
compute
a
Mac
over
the
transcript
up
to
that
point,
using
the
server's
diffie-hellman
key,
as
well
as
the
client
ephemeral
diffie-hellman
key
next
slide,
please.
AG
So
the
motivation
for
the
straf
is
there's
multiple
ones,
one
of
which
has
to
do
with
with
tracking
or
with
the
the
idea
that
if
you
do
a
resumption,
the
server
knows
exactly
what
the
first
connection
is-
and
this
is
this
is
trackable
and
there's
certain
influence.
Certain
applications,
notably
DMS
over
TLS,
where
you're
most
likely
to
just
have
one
interaction
with
the
client
and
server
during
the
connection,
so
in
likely
will
be
used
the
zero
RTT
mechanism.
AG
So
you
end
up
having
a
situation
where
this
first
connection
is
actually
every
every
request
to
the
server.
Although
it's
one
RTT
the
entirety
of
the
the
protocol,
it
is
linkable
from
one
request
to
another,
so
it's
desirable
to
have
some
unlink
ability
from
one
to
the
next.
Another
motivation
here
is
the
simplicity
of
single
primitive
protocols.
AG
If
you
have
Diffie,
if
you
have
TLS
and
you
have
the
ability
to
have
divyam
in
certificates
or
diffie-hellman
authentication
from
the
server
side,
then
you
can
implement
TLS
without
implementing
any
of
the
signatures
and
in
some
constrained
cases
this
is
better
because
then
you
only
have
to
implement.
If
you
Hellman,
you
don't
have
to
have
multiple
algorithms,
it
makes
a
smaller
piece
of
smaller
code
code
based
on
either
the
client
or
the
server
side
and
on
the
client
side,
if
you
have
key
pinning
or
more
things
like
this,
it
helps
there's.
AG
P
AG
K
So
I'm
not
sure
L,
agree,
I
mean
so
I
think
the
current
draft,
as
Nick
says,
really
supports
a
somewhat
about
B,
TLS
and
easy,
except
for
sweets
with
replace
the
signature.
We.
K
The
part
of
the
reason
we
have
removed,
the
you
know
further
is
removes
the
0tt
sort
of
easy
th
mode
was
we
had
a
lot
of
reasoning
about
it
and
it
was
in
duplicative,
so
I
I,
guess
I'm
less
excited
about
that
they
were
prepared
to
sort
of
engage
with
it.
I
think
we
would
PR
for
me
or
PR
from
from
from
Chris
about
that.
K
So
I
think
like
on
death
for
things,
we're
thinking,
I
think,
frankly,
there's
also
a
lot
of
questions
about
whether
or
not
you
know
without
any
will
redistribute
the
keys
that
you
need.
You
made
that
work.
What
other
reason
we
initially
did
us
at
that
so
I
think
like
and
I.
Even
the
final
professional
is
like
we're
not
quite
sure
how
that
composes,
because
that
was
definitely
a
source
of
like
potential
security
problems
we
do
with
the
house.
No
thanks.
Oh.
AM
Contras
and
I've
only
just
seen
this
for
the
first
time,
so
I'm
doing
kind
of
live
crypt
analysis
here
as
well.
So
isn't
it
honorable
to
KCI
attacks
key
compromised
impersonation
sites
where,
if
I
have
until
they're
on
a
client,
ephemeral,
then
of
course
I
can
somehow
impersonate
that
client
they
suffer.
But
now
it
can
also
impersonate
the
server
to
the
client,
because
the
keys
only
derived
from
thy
feminine
a
long-term.
K
Just
so
no
I,
don't
think
so.
So
you
to
be
clear,
I
mean
if
you
were
quite
ephemeral,
then
see
so
I
think
suicides.
They
say
jørgen
is
a
good
climate
control.
Then
you
can
push
the
server,
but
you
look
kind
of
ephemeral.
You
can
merely.
You
can
really
a
start
and
he
merely
allow
this
connection
to
go
through
and
then
and
then
and
then
sit
in
subjects
after
things
are
quiet,
I,
don't
think
I,
don't
think
that
I
don't
mean
the
fellows.
AG
K
K
You've
been
now
generate.
A
transcript
or
client
will
accept
like
dependent
server,
because
you
can
pair
the
client
ephemeral
with
the
cert
with
both
these
services,
a
republic.
You
are
right,
I'm,
saying
that
it's
true
but
the
primary
different,
but,
as
I
said,
if
you
like,
your
alternative,
would
be
to
take
two
along.
The
clients
reaffirm
local
server,
capsule
the
rustic
capsule,
the
server
server
side,
the
transcript
so.
K
A
lot
of
client
services,
the
message:
that's
a
surfer,
you
capture
the
server's
transcript
and
then
you
just
gagney
servers
are
transmitted
directly.
So
the
primary
difference
between
these
two
is
in
one
case.
You
need
to
certainly
outline
their
case.
You
going
to
survey
online
unless
I'm,
asleep
and
I
think
I
believe
he
is
that
not
is
that
not
in
fact
real
quite
is
then
upfront
right
is
that
I've
had
to
copy
police
to
feeling
systems
I.
AM
AG
AG
In
here
about
like
exactly
what
makes
it
right
next
slide,
please
so
moral
motivation,
so
one
of
the
one
of
the
other
reasons
that
this
diffie-hellman
based
TLS
1.3
wasn't
possible
was
because
it's
very
unlikely
that
TLS
certificates
for
ECD
age
shares
would
be
practical
in
the
near
term,
where
this
construction
called
delegated
credentials
makes
this
possible
and
time
bounded
key
swap
is,
is
sort
of
a
it
says
echo.
What
is
this,
but
this
is
a
this-
is
a
Richard
bounce
way
of
explaining
it?
AG
Basically,
it's
whatever
the
key
is
used
to
compute
the
certificate
verify
is
swapped
with
what's
in
the
delegated
credentials,
this
is
an
adopted
draft
that
is
still
being
worked
through
and
also,
if
you
use
something
like
this,
then
you
can
do
you
don't
have
to
do
the
expense
of
RSA
signature
operation
in
the
handshake.
So
this
this
helps
with
server
performance.
AG
All
right,
so
this
is
the
current
key
schedule,
at
least
for
deriving
things,
deriving
master
secret
and
here's
the
if
you
take
one
step
forward
next
slide
here
is
the
place
in
which
it's
proposed
that
the
semi
static
negotiation
is
SS.
Is
the
client
ephemeral
with
the
server
semi
static?
It
gets
mixed
in
other
than
the
zero
into
the
the
extract
for
the
master
secret.
AG
Next
slide,
please.
This
would
be
practically
implemented
as
a
set
of
new
signature
schemes,
and
these
would
be
TV
home
and
signature
schemes.
It's
not
technically
a
digital
signature,
but
it
it
takes
the
form
of
a
signature,
because
the
certificate
verifies
a
Mac
derived
from
a
diffi
Hellman.
With
with
this
key
the.
Obviously,
these
should
not
be
in
the
signature
algorithm
certificate
scheme,
so
the
split
in
TLS
1.3
between
certificate
algorithm
since
Jeff
Gallagher
algorithms
for
the
certificate
is
is,
is
good
here,
because
certificates
are
not
typically
signed
by
him
to
thielemann
in
trace.
AG
So
in
the
next.
The
last
set
of
these
are
the
set
of
open
questions.
Should
we
keep
a
certificate
verify
message?
It
was
suggested
that
potentially,
the
keys
could
be
rolled
into
the
eventual
finished
message
and
rather
than
have
a
certificate
verified
be
rather
than
having
to
max
in
the
middle
handshake.
I
think
probably
have
some
comments
on
this,
but
you
could
potentially
have
just
one
finished
message
and
can
client
authentication.
Can
it
happen
the
same
way?
Can
you
do
diffie-hellman
keys?
This
is
not
fully
fleshed
out.
AG
Another
open
question
is
if
you're
doing
semi
static
diffie-hellman,
it's
semi
static,
you're,
not
using
ephemeral
keys.
So
if
you
have
some
sort
of
diffie-hellman
group
that
can
only
be
used
once
this
does
not
work
with
those
compared
to
the
signature
scheme,
so
we
we
usually
work
with
and
and
then
again,
the
question
is
the
semi
static.
AG
Key
should
be
part
of
the
key
schedule,
or
should
it
only
be
looked
into
the
certificate
verify
the
this
has
different
effects
on
the
analysis,
the
analysis
that
we
have
currently
of
TLS
1.3
wouldn't
map
really
closely
to
this.
If
the
semi
static,
he
was
only
mixed
in
two
certificate:
verify
message
rather
than
the
actual
key
transcript.
So,
but
it's
it's
not
clear.
If,
if
these,
what
the
exactly
right
consideration
is
for
this,
so
we
just
need
to
keep
it
short
done
next
slide,
please
all
right!
So
there's
also.
AJ
AJ
AG
AG
AG
So
these
are
generally.
The
questions
that
we
wanted
to
raise
for
the
group
is:
is
this
something
people
are
interested
in
pursuing?
Should
the
this
is
an
extension,
should
this
hand
extension
be
able
to
radically
change
the
handshake?
There's
you're
significantly
changing
the
key
schedule
here,
and
you
know
removing
signatures
from
the
algorithm
and
also
our
people.
Are
there
anybody
out
there
who's
willing
to
review
the
draft
and
provide
comments.
H
H
To
think
about,
the
captain
says:
I'm
not
doing
this,
like
so
from
the
viewpoint
of
all
the
proofs.
They
have
already
been
done
using
the
semi
static
key
to
generate
the
PS
k40
RT
t,
even
in
the
first
message,
that'll
be
completely
fine
using
it
as
a
Mac
key
in
the
certificate
verify
or
be
completely
fine.
You
can
even
use
it.
It's
all
client
authentication,
that'll
be
fine.
H
There
is
a
KCCI
attack
there,
but
it
is
almost
inevitable
when
you
make
this
from
an
asymmetric
signature
based
scheme
to
a
more
symmetric
demon,
whisky,
whatever
that's
mainly
for
the
handshake
at
the
record
layer,
anybody
ever
forced.
So
that's,
ok,
but
the
moment
you
mix
in
the
key
into
the
key
schedule.
H
AG
K
Primary
advantage
of
Sookie
go
back
Lots
that
the
show
then
the
change
to
change
the
key
schedule
for
where
you're,
injecting
the
key
right.
So
the
primary
advantage
of
making
this
change,
the
nominal
primary
admittedly
has
changed,
is
not
keeping
the
ER
key
schedule,
but
is
requiring
compromise.
Have
both.
K
Sorry
is
requiring
compromising
with
a
server
static
and
the
server
run
rule
to
compromise
the
connection.
So
in
the
in
the
current
tool,
supply
crate
mode,
you
you
don't
need
you'll
need
to
compromise
the
server
signature
key
to
come
right
to
compromise
that
was
I
thinking
and
so
the
not
being
the
same
preserves
that
property
and
mixing
it
in
makes
this.
You
have
to
compromise
call.
So
the
long
term
piece
of
the
hypothesis
is
say
say:
you've
had
a
really
bad
period.
A
good
pair
of
G's
make
your
long
term
key,
but
a
bad
one.
H
AK
AG
AK
H
And
but
many
of
those
things
have
changed
a
lot
now
and
now,
without
really
composing
those
things
in
the
same
way
anymore
and
similar
attacks
actually
hold
for
PSK
as
well,
but
we
fix
those
using
the
binders.
That's
what
the
binder
state,
so
hopefully
the
binders
will
solid
in
this
situation
is
well
word
analysis
to
be
done
right.
AG
AC
J
AC
Had
a
proposal
to
use
that
for
the
external
PSK
and
so
I'd
like
to
come
up
with
the
way
work,
the
two
could
both
live
and
I
think
that
we
can
probably
come
up
with
a
way
to
do
that.
Some
additional
hash
or
KDF
or
whatever,
but
I
I,
think
that
we
do
want
the
short
term
quantum
resistance
by
enabling
a
external
PSK
to
be
mixed
in
there.
So
I'd
like
to
I,
guess
I'm
offering
to
work
together
on
that.
Thanks.
R
AD
Feel
how
big
yeah
I
I
like
this
a
lot.
It's
always
seemed
wrong
to
me
that
we
use
signatures
in
TLS
in
the
first
place,
because
it
provides
a
proof
that
a
key
was
involved
in
setting
up
a
connection.
That
is
unfortunate,
and
maybe
that's
some
piece
of
information
that
I
never
wanted
to
give
away,
I
think
yeah.
AD
Obviously
we
need
to
look
into
the
security
of
this,
like
we've
looked
into
the
security
of
everything
else,
but
at
the
end
of
the
day,
it's
not
my
DSA
signatures
entirely
without
security
issues,
I
mean
you've
still
got
the
issue
of.
If
you
screw
up
doing
DSA
you
screw
up
really
badly
and
so
I
think
that
that
needs
to
be
weighed
in
and
I
suspect
that
when
you
get
down
to
it,
it's
the
same
sort
of
effect
that
is
driving
all
these
vulnerabilities
under
the
covers.
AJ
Chris
would
she
wanted
to
comment
that
we're
trying
to
look
at
modifying
Casas
Tamra
model
bird
in
draft
23
for
1/3
to
incorporate
this
every
sect
just
to
get
kind
of
some
more
assurance
and
we're
also
working,
whether
it
be
boys
early
to
China,
get
some
more
formal
analysis
of
this
to
maybe
a
text
like
those
that
Kartik
mentioned?
Alright,
the
Trump
workshop
don't
come
back
to
bite
us.
K
So
I
just
wanted
to
address
Russell's
point
about
the
PSK,
so
just
to
clarify
the
one.
Arti
chemo
doesn't
implicate
the
peace
case,
not
at
all
only
the
0rg
motive
case,
the
vsj
slot
on
the
Larkin
mode,
implicates
the
zeroes
lock,
which
we
are,
which
is
already
0,
which
we
left
in
there
for
this
purpose.
K
So
the
only
time
that
the
PSK
slot
will
be
implicated
with.
Ladies,
you
are
cutie
and
then
presumably
they
give
a
separate
problem,
because
that's
also
where
you're
cutting
your
pump
using
the
PSK
slot
in
be
like
in
the
handshake,
also
to
indicate
where
yeah,
which
PSK
you're
using
so
I,
think
you
think
that
you're
already
overloading
that
so
I
think
what
you'd
end
up
doing
is
having
some
structure
in
there.
That
said,
I
want
to
use.
You
know
this.
You
know
this
divvy
home
accommodation,
Plus
this
PSK
together
and
then
don't
use.
K
AG
K
AG
S
Secret
that
stroke
and
server
and
other
protocols
like
noise
framework
and
stuff
they're
able
to
use
the
semi
static
secret
without
using
a
signature
based
scheme
like
a
Mac.
It
would
be
really
nice
if
you
could
get
rid
of
the
if
check
so
max
Chen
they
come
with,
like
you
have
to
check
a
Mac,
those
valid
or
not
at
the
end
of
it.
So
it'd
be
really
nice
to
design
a
protocol
which
is
exist
without
having
any
it
checks
at
all
those
securities
bacon
tellurian
at
the
end,
you
drive
the
key
and
that's
it
so.
K
If
you
mix
in,
if
you,
if
you
mix
in
the
very
end
the
thing
that
they
guided
where
you
mix
it
instead
of
the
zero
that
you
also
I
mean
yes,
sorry,
you
get
that
property
and
formally
on
valuable
I,
do
not
to
get
the
property
formally
but
informally,
of
the
property
that
like
basically,
then
just
art
dating
boys.
I,
don't
know,
however,
if
you
get
the
property
and
then
they
in
the
CK
said
sort
really
at
the
property
respect
the
traffic
use
yeah.
I
Time
at
this
point,
so
I
think
we
have
to
take
this
to
the
list
that
there's
obviously
some
interest
since
there
was
a
lot
of
people
that
don't,
like
so
I'd
say,
keep
going
on
the
list
and
go
from
there.
There
wasn't
one
okay,
one
other
presentation
that
got
bumped.
Unfortunately,
a
restless
draft
to
p
s
kzo
most
certificate
authentication
so
also
take
a
look
at
that
I.
Take
it
to
list
and
thanks
for
your
time
folks,
oh
yeah,
where's
the
blue
sheets,
and
if
anybody
wants
some
stickers
come
to
the
front.