►
From YouTube: TLS WG Interim Meeting, 2020-09-21
Description
TLS WG Interim Meeting, 2020-09-21
A
B
A
A
E
C
E
I
don't
know
what
those
variants
are.
I
was
just
thinking
of
the
I
was
just
thinking
of
the
oh
compute,
an
hmac
over
the
server
hello,
using
a
key
derived
from
the
master
key
or
from
the
main
key.
I
mean
secret
and
and
and
and
and
stick
the
prefix
of
that
hmac
in
the
server
hello
random.
Is
that
what
you're
describing
talking
about.
C
E
So
the
the
pr
for
this
is
converged
on.
Basically
the
proposal
is
you
compute,
you
you,
you
essentially
hash
the
client,
hello,
inner
and
the
the
first
24
bytes
of
the
server
hello,
random,
the
client,
hello,
inner
random
and
the
server
hello,
inner
random,
and
that's
how
you
get
the
that's?
How
you
get
the
confirmation
indication.
F
C
And
this
isn't
particularly
this
isn't
like
a
useful
thing
to
address
these
sort
of
replay
text
that
christian
laid
out.
Unfortunately,
he's
not
here
to
speak
for
it.
So
I
I'm
not
sure
how
far
we
can
get,
but
I
guess
I'd
like
to
pause-
and
you
know
ask
the
folks
here
if
they
have,
if
they,
if
they're
familiar
with
christian's
attack
and
if
they
are,
are
they
concerned
about
it
or
whether
or
not
we
can
just
press
onward
with
what's
written
in
the
pr
for
274.
G
G
G
So
so
I
think
you
know
like
I'm
on
the
fence
about
like
so
I'm
on
the
fence
about
whether
that
that
the
you
know
following
the
key
in
is
worth
doing.
But
I
I
mean
it's
like
you
know,
there's
always
sort
of
a
building
suspenders
kind
of
like.
Maybe
you
should
make
things
better
kind
of
thing,
so
I
wouldn't
fight
like
vehemently
against
it,
but
I'm
also
like
not
not
sure
we
need
it.
G
It's
worth
noting
that
if
we
decide
we
do
if
we,
if
we
decide
not
to
do
it
now
and
we
decide,
we
watch
it
later,
it's
actually
quite
straightforward
to
add,
because
you
can
simply
put
an
extension
in
the
ech
config
and
doesn't
appear
on
the
tls
on
the
wire
and
tls,
so
the
ech
config
would
just
say
you
know
I
speak.
I
speak
the
variant
in
which
you
know
in,
in
which
you
fold
the
tensions
so.
C
G
I
mean
this
is,
I
guess
I
guess
we're
throwing
this
is
like
not
like
you
know.
This
is
not
like
tours
on
it's
like,
not
a
technology
where
we're
attempting
to
like
make
this
completely
invisible.
If
we
were,
we
have
made
a
whole
bunch
of
different
design
choices,
so
it
says
analogy
where
we're
hoping
to
make
it
kind
of
a
pain
in
the
ass
to
determine
connections
using
yet
yeah.
I
think.
F
C
Yeah,
I
agree
that
actually
goes
it
right
into
the
threat
model.
There
is
a
separate
issue
for
actually
writing
down
sort
of
threat
model
and
the
security
goals
against
that
particular
attacker,
and
I
I
put
down
in
that
issue
just
a
high
level
summary
of
what
the
what
I
think
the
threat
model
should
be
and
what
we
should
be
targeting,
and
I
think
it
aligns
with
what
your
you
know
describing.
F
E
E
It
does
seem
possible
to
me
to
to
achieve
this
if
for
for
deployments
where
the
ech
configuration
is
not
easily
accessible
to
the
adversary,
but
that's
not
going
to
be
true
for
the
vast
majority
of
deployments,
at
least
initially.
So
I
think
this
is
a
I.
I
just
think
this
is
a
problem
worth
taking
some
time
to
study
before,
and
I
think
in
particular,
because
if
we
implement
something
complex
now
that
we
need
to
to
replace
later,
it's
going
to
be
a
lot
harder.
E
The
thing
the
the
current
pr
is
pretty
simple
and
it's
easy
to
replace
if
we
need
to-
and
I
also
really
liked,
ecker's
suggestion
of
of
using
an
extension
for
this
purpose.
It's
actually
a
pretty
nice
feature
of
the
of
the
of
the
protocol
that
the
signal
is,
you
know
it's
it's
kind
of
it's
kind
of
hidden
in
the
in
the
server
hello
random
already.
So
it's
easy
to
do
something
stronger
if
we
want
to
in
the
future.
E
E
C
So
chris
pointed
out
that
we
really
haven't
clearly
described
threat
model,
at
least
in
the
introduction
leading
up
to
the
design
or
maybe
in
the
secure
security
considerations.
We
have,
of
course,
documenting
some
of
the
attacks
and
some
of
the
design
flaws
that
we
had
in
earlier
versions
of
esi.
But
we've,
not,
I
guess,
been
a
bit.
We've
not
been
really
crisp
in
terms
of
what
the
attacker
is
and
what
its
goals
are.
C
These
might
be
our
stupid,
ossifying
middle
boxes,
things
that
can't
look
at
dns,
so
on
and
so
forth,
and
then
you
have
just
a
general
class
of
active
attackers
that
can
probe
do
all
sorts
of
crazy
things
and
these
are
more
or
less
sensors
and
and
the
goals
I
think
of
the
ech
are
to
I
guess.
First
and
foremost
not
you
know
negatively
affect
any
existing
security
properties.
Tls
1.3,
it
was
without
saying,
like
you,
shouldn't,
worsen
any
any
any
security
aspect
of
the
protocol.
C
It
should
be
from
a
privacy
perspective.
The
goal
is
to
make
it
so
that
every
ech
server
or
name
in
the
same
on
a
reset.
Our
connection
to
any
of
these
particular
servers
in
the
same
manner
reset
is
indistinguishable
from
one
another.
Much
of
the
traffic
analysis,
this
padding
might
change.
Padding
might
be
done
on
the
server
side.
It
might
not
be.
C
C
Moreover,
negotiation
of
ech
or
actual
usage
of
it
for
a
particular
connection,
a
secret
from
a
passive
attacker,
like
you
can't
figure
out
whether
or
not
ech
was
actually
used,
which
is
what
the
pr
that
chris
put
together
allows
us
to
do
similar
to
how
the
you
know.
Existing
trial,
decryption
and
functionality
works.
But
again
it's
not
meant
to
be
secret
against
active
attackers
and
there's
various
you
know
subcases
broken
down,
but
I
think
this
captures
the
gist.
G
G
C
F
So
so
chris
hey,
this
is
sean.
The
only
thing
I
can
think
of
is
that
we
need
to
make
sure
that
whatever
was
in
the
requirements
document
that
we're
not
doing
also
gets
captured
so
like.
If
there's,
if
there's
anything,
that's
different
between
the
two.
I
think
we
just
have
to
make
sure
that
we
document
that
does
that
make
sense.
C
Yeah
yeah
and
there
is
like
in
the
document
there's
a
section
on
going
through.
You
know
the
different
requirements
from
that
draft
and
and
commenting
as
to
why
we've
deviated
or
not.
But
I
I
don't
know
right
now,
whether
or
not
that's
up
to
date,
like
one
good
example
is
like.
I
think
the
the
requirements
document
says
that
you
know:
thou
shalt
not
stand
out,
though
clearly.
C
F
C
F
C
E
Chris
yeah,
I
just
comment
that
I
I
think
that
the
document
that
that
lays
out
that
don't
stick
out
requirements
is
not
is
is
a
little
less
precise
than
we're
trying
to
be
here
because
we're
you
know
we're
kind
of
trying
to
grab
the
problem,
so
I
think
I
think
yeah
we
should
we
should
document
what
what
what's
different,
but
I
really
don't
think
that
there's
much
that's
different.
I
also
want
to.
E
E
C
Yeah,
let's
see
if
we
can
frame
the
text
in
that
way,
I
think
we
we
sort
of
make
it
clear
that
the
intended
deployment
for
this
is
obviously
via
the
dns
like
we've
referenced,
the
service
record
use
the
term
dns
but
you're
right,
and
that
it
would
be
a
shame
if
you
know
whatever
broke
down
like
did
not
reflect
other
deployment
models
so
yeah
as
we
put
together
the
pr.
We
can
just
keep
an
eye
towards
that
to
make
sure
we're
future
proofing.
It
correctly
rich.
H
Yeah
yeah,
I
I
agree
with
the
others.
This
is
a
really
nice
piece
I
mean
even
just
if
they
exported
his
markdown
cut
and
paste
it
right
into
the
you
know.
This
is
the
pr,
but
I
do
think
that
we
should
say
some
words
about
censorship,
because
the
popular
technical
press
will
do
it
if
we
don't-
and
we
don't
have
to
spend
all
our
time
saying.
No.
This
is
not
a
censorship
prevention
tool,
censorship,
evasion,
tool
right.
C
H
G
C
C
Right
this
is
something
we
talked
about
last
time.
The
the
idea
was
that
we
have
this
ech
nonsense.
Currently
it's
kind
of
redundant
with
the
client,
hello,
random,
that's
also
secret
by
virtue
of
being
encrypted
in
the
inner
client
hello.
So
the
proposal
that
would
converge
towards
was
removing
the
ach
nonce
entirely
and
just
relying
on
the
randoms
in
the
inner
and
outer
clan
hello
being
different
generated
independently.
C
C
Yeah,
so
I
I
just
wanted
to
raise
this
and
and
pause
to
see
if
folks
have
had
a
chance
to
review
this,
the
the
text
is
fairly
self-explanatory.
It
does
the
associate
deaths,
it
removes
the
nonce
from
the
inner
client,
hello
extension
and
it
more
carefully
describes
how
to
specifically
construct
the
inner
and
outer
client
hello.
C
I
think
one
thing
that
came
up
during
this
particular
pr
that
is
sort
of-
I
guess
it's
not
directly
relevant
to
the
the
nonce
itself,
which
we've
agreed
to
remove
more.
So
it's
on
the
the
inclusion
of
padding
inside
the
inner
client
hello.
Can
you
scroll
on
just
a
little
bit
more
well?
Okay,
I
I
forget
where
it
is.
Oh
there
it
is
the
last
online
452.
C
Yeah,
I
I
don't
I
I
reviewed
this
pr
earlier
there
is.
This
must
include
padding
clause
specifically
using
this
particular
technique,
described
in
this
padding
section.
I
was
recommending
to
drop
it
from
a
must
to
a
should,
under
the
assumption
that
some
people
might
not
want
to
pad
a
particular
way,
or
they
might
not
want
to
pad
at
all,
depending
on
what
their
deployment
scenario
is.
Whatever
I'm,
I
think,
it'd
be
useful
just
to
like
quickly
flush
this
out.
G
I
mean
the
the
the
the
padding
there's
like
a
padding
section
and
if
you
wanted
to
use
padding
to
go
to
the
batting
section,
so
I
think,
like
I,
I
think
sure,
is
the
right
thing
here
or
even
may
I
mean
I
mean
the
key.
The
key
point
here
is
this
is
how
we
think
you
probably
ought
to
pad
if
you're
gonna
pad,
but
if
we're
gonna
tell
you
to
pad,
if
we're
gonna
say
you
have
to
pad.
If
you
go
to
padding
sessions.
C
Yeah,
basically,
I'd
be
fine
with
that.
So
I
think
a
shirt
is
right
here,
whatever
yeah
the
other.
Okay,
wasn't
just
anyone
else,
the
other
point
in
this
pr
christian,
I'm
sorry,
I
I
don't
mean
to
like
nitpick
your
pr
in
real
time,
but
these
are
just
like
things
that
we've
talked
about
in
various
places
of
different
threads.
That
I
think,
would
be
useful
to
just
air
right
now.
One
of
the
the
instructions
for
generating
the
hour
client,
hello,
is
to
be
careful.
C
C
So
I
guess
that
I
I
am
of
the
opinion
that
there
doesn't
really
make
much
sense
to
include
a
psk
binder
in
the
other
client
hello,
because
the
only
time
you'd
actually
be
making
use
of
the
outer
clan.
Hello
is,
if
you
are
going
to
retry
and
establish
a
fresh
connection
with
new
ech
keys,
and
it
just
it
seems
like
it's
easier
from
a
client's
perspective.
If
you
only
ever
attach
a
binder
to
one
client
hello
though
I
yeah,
okay,
I'm
from
the
chat,
I
think
that
makes
sense.
C
C
Jonathan,
the
the
issue
there
was
with
the
earlier
esi
design.
You
would
that
there
was
no
distinction
between
which
client,
oh,
that
you
were
actually
consuming,
because
there
was
only
one
client
hello
with
the
encrypted
sni
and
the
the
the
server
reaction
attack
or
the
ticket
or
oracle
attack
was
when,
like
the
ticket
might
encapsulate.
C
You
know,
like
the
actual
sni
that
was
used
to
fetch
the
ticket
and
if
the
server
checked
to
see
that
you
know
this
particular
ticket
sni
does
not
match
the
sni
inside
the
encrypted
ech
value
that
it
might
behave
differently
so
effectively
giving
an
active
adversary
in
oracle.
But
this
design,
like
the
server,
will
only
consume
either
the
inner
client
holo
or
the
outer
client
hello,
and
since
the
attacker
can't
augment
the
inner
client
hello
due
to
encryption.
D
C
C
G
Yeah,
so
I
think
I
I
agree
with
david
as
the
fundamentals,
I
think
I
think
I
guess
my
put
is.
I
think
we
have
a
straightforward
solution
for
this
for
sni,
which
is
to
either
invent
or
use
the
old
padding
extension
and
and
then
just
perm
and
then
unwind
the
restriction.
It
can't
be
an
ee
and
then
as
long
as
you're
able
to
project
how
long
the
circuit
will
be.
G
You
can
pad
it
as
much
as
you
want
me
and
remember
that
the
remember
that
the
boundary,
the
message
boundaries
should
be
should
be
concealed
in
any
case
that
that
doesn't
solve
the
problem
of
the
client
to
server
padding.
But,
as
I
said,
that's
a
problem,
that's
actually
a
problem,
irrespective
of
sni,
so
I
think
we
should
solve
that
separately.
C
Yeah
certificate
impression
is
very
far
along
at
this
point
and
we'd
have
to
like
burn
a
code
point
and
do
all
sorts
of
things.
If
we
were
going
to
change
that
alessandro
speaking
as
an
implementer
on
the
server
side,
how
allergic
are
you
to
you
know
using
padding
extension
in
ee
and
to
cover
or
hide
the
the
size
of
the
server's
flight?
G
C
B
So
if
certificate
compression
is
used,
then
the
padding
might
depend
like
the
size
of
the
padding
might
depend
on
the
result
of
the
compression
of
the
certificate
right.
But
presumably
you
would
know
if
certificate
compression
is
in
use
right,
yeah.
No,
what
I'm
saying
is
you
don't
know
how
big
the
certificate
is
going
to
be
before
you
actually
compress
it
right,
so
you
need
the
certificate
in
hand.
Basically,
let
me
see
the
compressed
certification.
G
B
I'm
saying
is
you
you
send
you
set
whatever
ee
and
then
later
the
certificate
is
sent
and
the
compression
might
happen
like
just
in
time.
So
when
you're
setting
the
ee,
you
don't
know
how
big
the
certificate
message
is
going
to
be
and
the
size
of
the
you
know
the
compressed
certificate
might
change
depending
on.
I
don't
know
the
the
common
names,
the
the
alternative
names
or
whatever
I
don't
know.
B
Yeah,
so
I
guess
I
I'm
not
really
sure
I
understand
how
an
implementation
would
choose
the
size
of
the
padding.
I'm
I'm
fine
with
the
with
the
ee
solution.
Putting
it
in
the
in
the
actual
certificate
message
might
be
problematic
if
you
pre-compress
the
certificate
message,
rather
than
doing
it
just
in
time,
because
then
you
wouldn't
be
able
to
actually
add
additional
extensions
later.
B
I
Yeah,
so
I
guess
to
answer
alejandro's
point
real,
quick.
I
I've
been
sort
of
assuming
that
the
way
you
choose
the
padding
is
that
you
have
some
target
size
or
something,
and
then
you'd
like
subtract,
like
the
padding,
would
be
like
size
of
the
certificate
message,
minus
target
size
or
something
along
those
lines,
some
function
of
of
the
of
the
size
of
the
final
certificate.
I
So
that's
a
little
annoying.
I
think
it's
probably
workable,
so
I'm
not
like
hugely
opposed
to
it.
It
does
sort
of
like
make
me
raise
my
eyebrows
slightly,
but
oh
well,
on
the
client
certificate
side
somewhat
tangentially
we've
been
looking
at.
I
think
ecker
suggested
for
the
alps
draft
that
we
switch.
The
message
that
we
added
to
an
encrypted
extensions-
and
so,
if
that
all
ends
up
going.
F
C
Yeah,
I
think
ecker's
right
in
that
treating
these
discord
two
separate
cases
like
the
the
client
side,
size,
leak
being
orthogonal
from
server
side
size
league,
treating
those
two
separate
things
and
potentially
trying
to
address
the
second
or
the
first
one
later
via
alps
or
ee,
or
new
handshake
message.
Whatever
makes
sense,
it
moves
us
forward.
C
We'll
know
right
now,
also
that
this
is
like
totally
optional
on
the
server
side
you
don't
have
to
pad,
but
you
should,
but,
like
I
mean
you
could
also
just
it
doesn't
have
to
be
like
for
super
precise
either
it
might
not
have
to
be.
You
could
imagine
just
like
padding
to
some
obnoxiously
large
size
and
then
just
like
running
with
that.
G
G
I
C
Okay,
so
I
think
what
I'm
hearing
is
that
the
ee
approach
right
now
is
is
not
too
onerous.
We,
it
might
require
us
to
revisit
some
things
depending
on
you
know,
future
server
side,
design
deployments
going
on
that
might
happen
later
down
the
road,
and
this
padding
of
the
certificate
verify
issue
might
be
a
little
bit
tricky,
but
on
balance,
perhaps
it's
the
right
approach.
It
allows
us
to
treat
separately
the
client
side
in
either
this
draft,
or
even
in
a
fallout
draft
like
alps,
or
something
david.
I
F
I
Okay
with
this
design
as
well
but
like
it
seemed
to
me,
the
new
message
was
sort
of
like
fairly
straightforward
to
process
and
it
was
analogous
to
like,
if
I
imagine,
sticking
in
the
quick
layer.
Probably
what
I
would
do
is
like
change
the
crypto
frames
so
that,
like,
rather
than
being
a
stream
of
bytes,
it's
like
a
stream
of
like
bytes
from
two
streams
that
didn't
make
a
whole
lot
of
sense,
and
that
is
approximately
what
happens
when
you
stick
like
a
padding
message
inside
the
handshake.
C
C
G
I
Like
if
we
were
to
do
this,
then
it
ends
up
like
like
a
client
that
wants
to
do
this
ends
up
having
to
pay
for
like
three
extra
rounds
of
three.
It's
super
expensive,
three
extra
round
trips
for
every
connection
which
like
if
we
want
to
build
a
way
to
do
ech
without
like
it
seems
the
use
case
for
this
is
for
a
server
to
deploy
ech
without
having
to
as
tightly
synchronize
their
server
their
server
configuration
with
dns,
which
seems
like
potentially
a
useful
thing
for
deployments.
I
But
if
we
were
to
do
that
like
I
don't
think
we
would
want
to
do
it
with
a
three-round
trip
penalty
when
we
could
actually,
when
like,
we
could
do
it
with
a
one-round
trip
penalty.
In
principle,
if
you
know
you
like
like
effectively,
all
of
ech
is
an
optimization
around
like
you,
you
you
do
the
client,
hello
and
server
hello,
and
then
once
you've
got
the
handshake
keys,
you
like
actually
send
the
sni
and
various
other
client
hello
bits,
which
is
a
one
round
trip
penalty.
I
B
G
C
C
C
So
fred,
the
question
whether
or
not
we
should
have
basically
mandatory
to
implement
comes
so
that
clients
know
which
one
to
choose.
I
know
when
discussion
with
people
who
are
working
on
ech,
that
the
choice
of
chem
is
fairly
obvious
and
like
people
are
probably
going
to
use
the
same
thing,
but
certain
people
don't
really
care
for
mandatory
to
implement
cypher
suites.
So
I
I'm
just
curious
to
hear
what
folks
think
about
this
particular
proposal.
G
F
Go
ahead.
Sorry,
chris,
I
was
just
thinking
like
from
a
getting
through
the
process
perspective.
I
understand
why
people
might
not
want
to
pick
one,
but
I
can
understand
the
isg
saying
you
know.
Why
didn't
you
pick
one?
Well,
you
know
you
picked
them
elsewhere.
Why
couldn't
you
pick
it
here?
Something
we'd
have
to
answer.
So
if
we
don't,
we
have
to
come
up
with
a
reason
why
it
seems
like
it
might
be
easier
just
to
pick
one,
because,
typically
that's
what
you
do.
C
C
G
Mls,
do
that's
a
great
question.
I
don't
know
I've
been
trying
to
figure
out.
Like
I
mean
when
we
do
p256,
it
was
like
on
the
edge
of
like
two
five
five
one,
nine
being
like.
You
know
the
thing
yeah
and
so
hp
things
have
changed,
but
that's
why
I'm
curious,
how
like
it
lost?
How
much
addressed
it
they
just
decided
to
fight
following
that.
G
I
mean
I
don't
think,
having
these
being
consistent
is
like
a
disaster
they're
like
no
they're,
not
connected,
I
mean
back
it
like
when
you
first
did
this.
They
were
like
really
connected,
but
now
they're
completely
disconnected.
So
I
mean
yes,
it
would
mean
you
do
two
five,
five
nine
stack
and
it
is
exact
but
like
so
what.
G
C
J
F
C
F
G
G
E
B
H
C
That's
it
for
the
issues
I
wanted
to
cover.
We
have
seven
minutes
left.
Is
there
anything
else
folks
would
like
to
talk
about
before
we
conclude
I'll
note
that
with
landing,
these
changes,
we're
probably
a
good
enough
state
to
ship
draft
8,
which
would
be
the
target
for
implementation
for
folks
and
all
the
remaining
issues
that
have
not
yet
been
resolved
are
mostly
editorial
in
nature,
so
we
can
address
them
separately
with
lower
priority.