►
From YouTube: TLS WG Interim Meeting, 2020-09-03
Description
TLS WG Interim Meeting, 2020-09-03
A
A
You
can
try
that
out
and
see
how
it
works
but
make
sure
you're
muting
your
microphone
unless
you're
speaking
just
to
minimize
the
extraneous
noise
we'll
try
to
use
the
queuing
mechanism,
although
with
a
smaller
group
of
people
here,
we
may
not
have
to
be
quite
as
formal
but
I'll
try
to
monitor
the
queue
and
maybe
chris
can
as
well.
There
are
blue
sheets.
The
kodi
md
link
is
in
the
chat
which
you
may
have
access
to.
A
B
A
Yeah
and
the
slides
should
be
in
the
meeting
materials
for
this,
but
they
may
not
be
obvious
because
how
to
get
to
that
I
apologize
for
not
including
that
information
in
the
announcement.
So
hopefully
people
can
do
that.
Here's
the
note
well
for
folks
that
are
you've
all
seen
this
before
I'm
sure
so
just
make
sure
you
adhere
to
the
best
practices
and
we're
here
to
talk
about
ech.
So
what
I'm
gonna
do
is
bring
up
the
github
pages
and
then
go
on
mute
and
listen
to
chris.
D
C
C
Perhaps
paramount
is
that
it
complicates
the
quick
tls
interface
in
a
needless
web,
so,
ideally,
clients
have
a
way
or
that
the
tl
stack
has
a
way
to
determine
which
of
the
client
hellos
was
chosen
without
consulting
quick
earning
any
part
of
the
protocol.
So
there
are
a
number
of
options
here:
option
zero,
one,
two,
three
three
prime!
C
C
E
E
Yeah,
so
the
idea
is
basically
to
provide
an
explicit
signal
of
acceptance
so
that
you
don't
have
to
that.
You
don't
have
to
do
trial
decryption.
So
what
happens?
Is
the
the
client
sends
an
ech
extension
in
its
client,
hello,
inner,
which
has
this
eight
byte
random
value
that
it
expects
to
see
in
the
server's
server
hello
random?
E
E
From
from
an
analytical
perspective,
it
doesn't
seem
to
do
that
much
damage
because
we're
just
using
eight
bytes.
An
active
attacker
could
of
course,
control
these
eight
bytes
and
and
and
increase
the
probability
of
a
of
a
a
server
random
colliding
with
a
previous
server
random.
But
there
are
still
24
bytes
of
entropy,
so
this
risk
seems
seems
pretty
pretty
minimal.
B
Yeah
I
mean,
I
think
this
is
probably
I
I
we
spent
a
lot
of
time
on
this.
Obviously
I
think
this
is
probably
the
best
approach.
I
have
some
complaints
about
the
way
it's
spelled,
which
I
can
like
put
in
comments.
Specifically,
I
don't
think
having
two
variants.
The
extension
is
a
good
idea.
We
should
have
two
different
code
points,
but
I
think
this
is
a
fine
general
approach,
and
I
just
I
think,
probably
that's
the
thing
is
people
agree
on
the
normal
approach.
C
F
Okay,
so
I
was
thinking
about
this
a
little
while
ago,
and
the
server
could
in
an
unencrypted
extension,
send
back
a
blob
like
a
number,
and
the
indication
of
acceptance
would
be.
It
would
compute
the
whatever
key
for
the
inner
client,
hello,
hash
it
with
some
label,
and
that
would
be
its
response
and
otherwise,
if
it
was
rejecting
or
if
it
didn't
it
couldn't
decrypt.
F
It
would
just
put
random
data
in
this
unencrypted
extension,
and
that
would
mean
you
end
up
with
the
external
observer,
can't
determine
whether
or
not
you
have
the
server
actually
accepted
and
rejected.
You
can
tell
if
the
server
doesn't
support,
but
it
can
tell
that
anyway,
you
can
tell
if
the
server
accepted
or
rejected,
and
otherwise,
but
it
can't,
but
the
excel
episode
can't
tell
sorry
the
external
observer
can't
tell
whether
acceptor
rejects,
but
the
clients
can.
B
F
F
C
Nope,
this
is
taking
basically
a
secret
value
that
the
client
sends
in
the
inner
client,
hello
and
putting
it
in
the
server
hello,
random
and,
from
the
midwest
perspective,
that's
not
actively
probing
to
figure
out
whether
it's
not
just
ech
is
supported.
It
just
looks
like
any
other
random
names,
so
I.
B
B
If
we
get
rid
of
vch
knots,
then
then
we
can
just
have
the
low
eight
bytes
be
a
digest
of
client
random,
which
line
runner
has
to
be
random
anyway,
and
then
we
can
dispense
with
the
signal
in
the
client,
hello,
yep
good
point,
so
I
mean
it's
just
distributed
optimization,
but
it's
it'll
make
life.
It
makes
life
somewhat
simpler.
B
C
F
B
Yeah,
I
think
I
think
I
think
that
would
be
quite
difficult
because,
because,
given
that
you're,
probably
quite
possibly
offering
different
client
different
different
key
shares
in
the
two
client
hellos,
then
you're
effectively
having
to
try
out
the
crypt
at
that
point
so
as
you're
trying
to
do
to
feed
humans.
Like
I
mean
I,
I
think
it's
certainly
this
only
idea
worth
iterating
on,
but
after
after
like
after,
like
five
minutes
at
one
full
start,
I'm
less
confident
we
can
make
it
work.
B
B
C
Okay,
unless
there's
any
other
objections,
chris,
let's
just
work
forward,
closing
out
this
pr
incorporating
all
the
suggestions
from
everyone.
So
again,
the
pr
is
linked
here,
number
287!
You
have
specific
comments
on
how
it's
spelled
by
chatting
whatever.
Please
take
a
look
at
your
comments.
There,
your
feedback
there
we'd
like
to
close
on
this
one
soon,
because
it's
one
of
the
big
things
that's
blocking
implementation,
going
forward.
C
C
But
given
how
the
design
has
morphed
lately
and
the
fact
that
the
interclan
hello
presumably
has
a
different
secret
random
value
than
that
which
is
in
the
outer
client,
hello,
it
may
be
redundant
and
we
might
consider
removing
it
rather
than
clarifying
its
existence.
There
are
a
couple
caveats
here.
C
In
particular,
it
does
need
to
remain
secret
in
order
for
this
to
be
like
effective,
that's
a
key
property
of
the
echoes
right
now
like
if
it's
revealed,
then
this
reaction
attack
is
potentially
possible
and
there
may
be
servers
that
somehow
leak.
You
know
bits
of
the
client
hello
at
the
client,
hello,
random
or,
like
maybe
even
other
extension,
values
like
the
ech
nonce.
C
So,
if
we're
reasonably
sure
that
the
a
the
random
values
from
the
inner
outer
claim,
hello
are
different,
that
is
independently
generated
at
random
and
that
the
inner
hello,
client
random,
is
never
leaked
by
any
entity
who's.
Actually,
who
has
visibility
into
it?
Then
we
may
be
able
to
remove
it
after
discussions
with
karthik
and
some
others,
so
ecker.
E
E
I
changed
the
I
updated
the
the
the
discussion
in
security
considerations
about
this
client
reaction
attack
to
say
that
the
secrecy
of
the
client,
hello,
the
inner
client,
hello,
random,
prevents
that
attack.
I
guess
we
should
all
you
know
we
should
all
agree.
We
should
all
try
to
agree
that
that's
actually
the
case
worth
talking
about.
B
Yeah
so
yeah
I
mean,
I
think
chris
aren't
hurting
this
chris
wood
and
I
was
again
this
morning.
The
reason
we
kept
this
was
because
there
was
some
fear
that
servers
might
leak
declining
a
little
random,
for
instance,
a
ticket
so
and
bear
in
mind
that,
like
the
the
the
ticket
doesn't,
the
ticket
does
not
currently
have
a
secrecy
requirement.
The
so
I
mean
like,
for
instance,
you
might.
B
I
mean
I
don't
know
why
you
do
this,
but
you
might
like
basically
embed
the
entire
client
hello
in
the
in
the
in
in
the
ticket
and
obviously,
if
that
were
the
case,
then
you
would
that
wouldn't
work.
They
always
had
that
with
the
case
that
this
would
not
work.
But
with
that
said,
if
you
leave
the
client
hello
in
the
ticket
and
you
leak
the.
D
C
B
I
B
Okay,
so
what
I
was
saying
was
that,
given
that
we're
hypothesizing
servers,
which
have
which
have
unknown
behavior
and
leaked
parts
of
things,
the
only
way
to
fix
that
is
by
pulling
stuff
out
of
the
key
schedule
and
shoving
it
back
in,
and
we
can't
do
that
without
making
major
modifications
like
the
clock.
The
communication
between
the
facing
and
the
back
end
server.
C
Okay,
so
I
guess
the
question
on
the
table
is:
do
we
believe
that,
with
this
sort
of
change
where
in
which
we
make
it
clear
that
the
the
two
client
hello
randoms
need
to
be
different
and
that
the
inner
one
needs
to
remain
secret,
whether
or
not
that's
sufficient,
or
we
need
something?
A
bit
stronger.
E
C
F
D
B
G
C
C
C
F
C
C
C
I
Yeah
I
I
I
was
looking
at
that
I
was
going
to
add
a
me
too.
Yes,
I
like
it
to
287,
and
then
I
think
I
have
an
attack
against
that
and
the
attack
is
suppose
a
man
in
the
middle
observes
the
client
hello
forwards
it
to
the
server
receives
the
server's.
Hello,
blocks
it
and
sends
and
creates
its
own
response,
as
if
it
was
a
server
responding
to
the
outer
initial
client
hello,
but
does
copy
the
first
eight
byte
of
the
server
hello
random
into
its
own
server,
hello,
random.
I
Then
I
think
you
have
an
oracle.
Is
that
the
the
client
will
cda?
If
the
client
is
doing
ech,
it
will
react
to
the
eight
bytes
and
try
to
use
the
the
ech
secret
and
the
connection
will
fail,
and
thus
the
server
can
see
that,
because
the
question
doesn't
progress.
Your
client
with
and
the
server
are
doing,
the
ech.
C
Yeah,
I
don't
think
this
design
is
specifically
intended
to
prevent
that
sort
of
active
attack.
I
mean
there's
certainly
other
ways
to
figure
out
whether
or
not
a
particular
connection
it
makes
use
of
ech,
depending
on
like
what
sort
of
capabilities
you
assume
the
beyond
path
attacker
to
have
and
how
much
active
probing
or
what
not
it's
willing
to
do.
C
I
C
C
Yeah,
okay,
so
let's
follow
up
on
the
pr
there
and
think
through
that
case,
just
to
make
sure
that
there's
no
inherent
problems
but
yeah
thanks
again
for
flagging
it.
So
back
to
this
one,
that's
open
right
now
it
doesn't
look
like
there's
any
particular
strong
objections
to
it.
So,
chris,
your
pr
is
linked
from
this
issue.
Right.
C
C
All
right,
okay,
so
one
of
the
details
we
lay
on
the
spec
is
that
endpoints
must
pad
parts
of
their
handshake
flight.
In
order
to
hide,
you
know
metadata
that
would
leak
otherwise
like
size
certificate
that
might
depend
on
the
s
and
I
or
other
things
we
can't
rely
on
record
layer
padding
to
do
so,
but,
as
david
lays
out
on
the
issue,
this
could
be
problematic
for
quick
implementations.
C
There's
also
a
potential
to
do
it
with
extensions
on
certain
messages
in
the
handshake,
like
you
could
add,
it
make
an
exception
for
padding
being
added
to
the
certificate
message
or
to
ee
or
whatever.
There
are
some
comments
in
here
that
suggests
that
doing
it
you
do
going
down.
The
extension
route
is
perhaps
not
the
best
or
best
path,
particularly
if
you
consider
what
happens
with
certificate
compression.
C
So
I
think
the
the
proposal
here
is
to
add
a
new
handshake
message.
That's
specifically
designed
for
to
carry
padding
bytes
and
the
part
of
the
record
layer
that
looks
at
the
handshake
message
and
dispatches
it
to
the
state
machine
similar
to
ccs.
We
just
you
know,
consume
this
padding
message
and
drop.
It
on
the
floor.
Unfortunately,
david
is
not
here
to
speak
to
it.
I
don't
think
so.
B
C
B
C
B
K
Sorry,
I
added
myself
to
the
queue
to
comment
that,
from
the
quick
perspective,
managing
padding
at
the
quick
layer
will
be
horribly
complicated,
so
we
need
some
sort
of
padding
in
the
tls
layer.
I
don't
have
strong
opinions
on
where
tls
puts
that
padding
in
so
what
ecker
was
suggesting
of
putting
an
e
instead
of
in
a
new
handshake
message,
I
think,
sounds
fine
yeah.
B
C
B
But
I
mean
I
guess
right.
I
think
that's
certainly
true,
but
bear
in
mind
that,
like
I
mean
like
lots
of
things,
are
going
to
vary
based
on
what
server
it
is
right.
You
know
once
talking
like
my
message.
High
traffic
analysis,
like
what
you
know
is,
is
the
uri
gonna
vary.
So
I
don't
think
that's
actually
that
helpful,
but
in
any
case
so
I
think
yeah.
I
think
that's
that's
that,
like
this
seems
like
a
separate
problem.
B
I
guess
because
let
me
point
out
that,
like
the
seems
like
it
seems,
the
client
certificate
leakage
has
like
much
more
serious
problems
than
than
then
with
sni,
because
you
know
you
have
multiple
clients
going
into
the
same
known
server
and
you're,
apparently
looking
at
any
of
those.
So
it
seems
like
if
that's
an
issue
like
that's,
that's
a
solution
which
can
be
detached
from
this
particular
problem.
E
Chris,
I
just
wanted
to
mention
the
thing.
One
thing
we're
not
talking
about,
which
is
definitely
less
of
a
risk
than
leaking
the
sni
is
there's
a
lot
of
there's
a
lot
of
things
in
the
spec
about
don't
stick
out
like
padding
to
make
sure
like
on
ech
rejection,
you
pad,
like
it's
optional,
for
non-ech
servers
to
pad
to
hide
the
fact
that
ech
rejection
has
happened.
I
don't
I
don't
know.
I
don't
know
how
that
concern
relates
to
the
questions
on
the
table.
I
just
wanted
to
bring
that
up
all
right.
B
I
think
one
more
point:
you
know
david
ben
points
out
that
the
reason
you
can't
do
just
a
gen
extension.
The
certificate
message
is
because
the
certificate
compression
draft
you
know
compresses
the
entire
method,
exactly
like
we
could
just
pull
out
of
the
rfc
or
can
fix
that.
I
mean
if
we
decide
that
was
the
wrong
answer
like
we
need
to
fix
that.
C
C
But
all
this
is
sort
of
like
extra
anyways,
I
mean
different
implementations
might
go
to
different
degrees
of
how
much
padding
they're
willing
to
do
to
hide
these
things,
like
padding's
not
required
to
make
the
protocol
work.
So
I
don't
consider
this
a
real
blocker,
but
it's
something
which
should
grow.
E
One
thing
is
that
if
we
should,
we
should
double
check
the
draft
to
see
if
there's
any
must
pads.
I
don't
know
that
there
are,
but
that's
worth
that's
worth
following
up
on
just
in
case.
You
know
we
don't.
Actually
you
know
if
we
don't
actually,
if,
if,
if
yeah
yeah,
basically,
if,
if
implementations
do
different
things,
we
still
want
to
make
sure
that
the
standard
they're
standard
compliant.
So
it's
worth
coming
through
the
spec.
I
think.
C
G
All
right
can
we
go
to
263
next
ben
schwartz.
I
just
wanted
to
on
the
on
the
topic
of
unsolicited
padding
extensions.
I
just
wanted
to
ask:
is
there
a
way
to
to
implement
the
client,
hello,
the
inner
client
low,
padding
using
the
unencrypted
client,
hello,
padding
extension,
which
would
then
be
encrypted
by
ech.
B
Yeah,
I
think
that's
exactly
right.
I
think
that
the
client
pads,
so
my
thesis
would
be
that
the
client
pads
with
the
standard,
padding
extension
and
the
server
then
and
then
we
remove
the
restriction.
The
server
can't
add
their
own
padding
extension
and
they
put
it
in
the
e
and
then
it's
not
unsolicited
and
we're
good
to
go
and
then
there's
an
edge
case
where
the
client
doesn't
have
what
the
server
wants
to.
B
C
B
I
I
think
I
mean
but
bear
in
mind
that
you
could
solve
actually
by
having
that
you
can
actually
solve
by
having
a
by
by
pat.
So
I
mean
that
this
is
why
super
compression
thing
is
relevant
right
because
that
you
could
solve
by
having
a
certificate
in
the
second
message
having
the
server
and
although
unsolicited
certificate
extensions,
I
think,
are
forbidden
that
this,
because
that's
a
response
to
certificate
request,
you
could,
you
could
have
the
extension
there.
Yeah.
C
C
C
Okay,
so
this
next
issue-
oh
right,
so
for
the
extension
compression
mechanism
that
we
have
in
the
spec
right
now
there
is
this
hash,
that's
included
of
the
what
should
be
the
effectively
reconstructed,
client,
hello
and
chris
is
asking
here
whether
or
not
that's
actually
useful.
Chris.
Do
you
want
to
elaborate.
E
Yeah,
so
from
where
I
from
where
I
stand,
it
seems
to
be
redundant,
at
least
in
so
far
as
if
the
client
hello,
if
the
outer
extensions
are
manipulated.
It's
going
to
change
the
client,
hello,
inner,
the
client
and
and
back-end
server
aren't
going
to
agree
on
that
value.
So
that's
basically
just
an
active
attack.
That's
what
it
amounts
to,
but
ecker
pointed
out.
This
kind
of
you
know
kind
of
weird
corner
case.
E
Where
there's
you
know
you,
you
have
these
sort
of
it's
it's
it's
possible
to
come
up
with
contrived
examples
of
extensions
that
that
kind
of
break
the
privacy
of
s
I
and
the
this
this
mechanism.
Basically
this
this
this
this
binding
of
the
outer
extensions
to
the
client,
hello,
inner,
prevents
this
attack.
So
basically,
what
we
have
is
a
strictly
stronger
security
property
for
the
client,
hello,
inner,
that's
consumed
by
the
back-end
server
than
what
is
usual
for
like
tls.
E
B
So
I
don't
have
a
more
natural
example.
I
think
part
of
what
happened
here
is
that
you
know
we
found
it
so
hard
to
reason
about
everything
involving
ech,
that
that
I
decided
that
when
I
th
that
this
was
a
sketchy
enough
kind
of
like
situation
that
that
that
it
was
better
to
be
there
on
the
safe
side,
I
think
is
basically
what
happened
here
that
you
know
a
lot
of.
I
mean.
B
Basically,
we
have
a
lot
of
problems
with
the
substitution
of
individual
parts
of
the
internet,
hello
and
the
advantage,
and
so
like
here.
Here's
how
you
get
to
this
point
is
you
say:
look
we've
had
problems
substituting
inner
parts
to
client,
hello
and
so
now
we're
gonna
we're
gonna,
we're
gonna,
take
the
entire
thing
and
bundle
an
ech,
and
that
provides
both
confidentiality
and
integrity
for
the
entire
thing.
And
so
like
that's
a
good
property
and
we
agree,
we
can
analyze
that
easily
and
then
you
say:
okay,
but
that's
too
big
how
you
compress
it.
B
And
so,
when
you
compress
it,
you
don't
want
to
remove
the
property
of
having
integrity
for
the
entire
thing,
and
so
that
that
that
means
binding
between
the
inner
hour.
So
I
guess,
unless
we
had
a
very
like
this-
is
a
complicated
system
that
it
seems
like
like
leaving
the
door
open
for
obvious
mistakes.
Later
is
not
a
good
idea.
B
E
I
don't
I
don't
necessarily
I
don't
I
don't.
This
is
kind
of
maybe
nitpicky,
so
I
I'm
not
gonna,
I'm
not
really.
I
don't
really
have
a
strong
opinion
about
this
at
this
point.
I
think
that
though,
basically
I
don't
know
that
it's
providing
additional
integrity,
but
it's
certainly
it's
kind
of
like
it's
kind
of
like
encryption
with
associated
data.
E
E
C
E
Oh
yeah,
okay,
so
yeah.
Where
are
we?
Basically,
we
wanna
what
we
want,
what
the
so
the
people
who
have
like
chimed
in
on
this
issue.
We
all
basically
agree
that
we
would
like
for
the
extension
compression
compression
mechanism
to
preserve
the
order
of
the
extensions
which
the
current
mechanism
doesn't
so
there's
a
proposal
for
doing
this
and
we
haven't
gotten
much
feedback,
there's
some
pushback
from
martin
thompson.
If
he's
here,
he
he
can.
E
E
Yeah,
so
right
now
the
idea
is
we
have
so
this,
so
this
sort
of
this
sort
of
okay,
I
this
sort
of
breaks
the
semantics
of
of
extensions
as
usual.
My
thinking
is
that
client,
hello,
inner,
isn't
a
real
handshake
message.
Sure
it's
it's
something
that
you
need
to
actually
inflate
and
send
to
the
back
end
server.
So
I
figured
that
it
would
be
okay
to
violate
that
rule.
Sure
yes,
you're
triumphantly.
B
E
E
No
so
there's
two
extension
points
for
this
for
this
mechanism:
there's
outer
outer
extension
and
for
each
for
each
extension.
You
want
to
shallow
copy
into
the
client,
hello
inner.
You
replace
that
extension
with
that
extension
point
and
then
the
payload
is
just
the
the
extension
type.
That's
right.
Yeah
pointed
to
okay,
yeah,
okay
and
then
there's.
B
Right,
okay,
yeah,
because
that
was
the
objection
to
my
design,
which
is,
I
had
n
hashes,
which
my
thesis
was
by
the
way
that
like
why
not
because
you're
not
so
so
my
original
design
was
each
each
hash
was
the
hash
of
the
thing
you
were
plugging
in
as
opposed
to
being
a
total
hash,
and
so
so
I
think
I
think
the
objection
was
so.
I
think
I
think
the
question
here
is
is:
is:
are
there
yeah?
So
this
is
fine.
E
Yeah,
I'd
like
to
I'd
be
curious.
Okay,
I
mean,
because
I
know
that
martin
thompson
has
so
he's.
You
know
he's
suggesting
something
that
actually
provides
better
compression.
So
this
my
mech,
the
current
proposal
is,
is
really
simple.
It
only
actually
provides
a
benefit
if
you
compress
enough
extensions,
so
there's
a
threshold
that
you
need
to
cross
for
it
to
be
valuable,
which
is
worth
discussing,
and
I
think
the
other
issue
is
whether
people
are
going
to
be
fine
with
using
multiple
extension
points
in
the
same
synthetic
message.
D
E
G
B
E
B
G
I
just
want
to
try
to
understand
whether
this
is
motivated
by
allowing
the
representation
of
arbitrary
extension
orders
or,
if
there's
some
other
reason,
why.
You
think
the
current
model
is
insufficient,
because
I'm
not
aware
of
a
reason
that
we
need
to
be
able
to
represent
extensions
in
an
arbitrary
order.
E
That's
a
good
question.
The
thing
I
worry
about
is
there's
already
a
rule
in
8446
that
says
when
like
when,
when
that,
when
you
can
send
a
pre-shared
key
extension
like
in
what
order
in
this
in
the
in
the
client
hello,
I
worry
about
messing
things
up,
if
which,
if
the
the
order,
like
somehow
our
transformation
of
client
hello,
enter
to
compressed
client,
hello,
inner
if
it
changes
the
orders
of
things
that
could
change
the
expectations
of
the
client
and
mess
up
mess
up
logic
on
the
client
side.
E
So
basically,
I'm
worried
about
ossification
of
ex
around
extension
order
on
on
on
the
client
side
that
I
mean
so
that
the
issue
like
I
mean
there.
I
think
that
people
generally
seem.
That's
generally
seem
to
agree
that
that's
a
that's
a
that's
a
safe
thing
to
do.
I
forget,
if
you,
if
you
chimed
in
on
this
issue
or
not.
G
E
But
there
then
there's
also
like,
like
eight
four
four
six
makes
an
ex
like
you
know
it.
Doesn't
it
doesn't
assign
the
order
of
extensions
except
for
one
I
forget
which
one
it
was,
but
I'm
pretty
sure
it's
pre-shared
key
yeah.
It
has
to
appear
last.
So,
if
you're,
if
somehow
you
use,
if
somehow
your
implementation
of
client,
hello,
inner
compression,
messed
up
that
order,
then
you
would
end
up
with
a
non-compliant
client.
So
it's
something
to
be
careful
of
it
for
a
particular
implementation
of
the
the
compression
mechanism.
E
I
think
it
makes
sense
to
simplify
the
spec
and
that's
what
I'm
that's,
what
I'm
aiming
to
do
with
this?
It's
basically
to
you,
know
it's
it's
it's
it.
It's
it
prevents
preventing
preventing
the
order
of
extensions
from
changing,
ensures
that
it
it
no
logic
anywhere
else
in
the
stack
is
screwed
up
and
that's
kind
of
my
aim.
B
Yeah
so
I
think
like
to
put
my
cards
on
the
table.
My
suggestion
is
for
people
asking
at
psk,
even
if
there
is
psk
psk's,
clearly
not
compressible,
because
because
the
binders
prefer
the
rest
of
the
rest
of
the
handshake
right.
So
that's
like
that's
not
going
to
work
anyway,
so
I'm
not
worried
about
that
one.
B
Let's
do
that
research
and
then
do
that
simple
thing,
and
the
thing
I
would
note
is
that
this
is
not
like
an
all-time
commitment
in
the
sense
that
that,
because
there's
a
an
effectively
a
negotiation
when
ech
is
done,
if
we
end
up
with
some
other
extension,
then
we
can
just
we
can
effectively
rev
the
ech
back
or
have
a
way
for
the
server
to
indicate.
I
speak
compression
v2
and
has
a
more
fancier
thing.
E
That's
fine,
I
think
one
thing
about
like
just
just
requiring
the
compressed
extensions
to
be
contiguous.
You
want
to
put
the
outer
extension
extension
in
the
right
order,
so
if,
if
you're
gonna,
if
you're,
if
the
extensions
are
a
b
c
and
d
and
you're
gonna
compress,
b
and
c,
then
in
the
the
representation
of
the
client
in
the
client,
hello
enter
needs
to
be
a
and
and
then
outer
extensions
for,
b
and
c
and
then
d.
B
If
we
already
have
a
bunch
of
implementations
which
serializes
some
random
order
or
if
you
have
for
some
reason,
extensions
which
really-
which
for
some
reason,
don't
want
to
be
contiguous
right
like
in
the
same
ways
the
same
way
as
psk
psk
is
now,
and
so
I
guess
what
I'm
saying
is
unless
we,
unless
we
find
ourselves
in
that
situation,
now
like,
let's
like
burn
that
bridge,
I
think
that's
fair
so
see.
If
we,
I
guess
like
what
I'm
saying
is
like
someone
should
go.
Look
some
clown,
hellos
and
like
see.
Is
there
anything
else.
C
E
Yeah
thanks
so
what's
going
on
here
is
right.
So
if
the
structure
of
the
encrypted
client
hello,
that
is
the
payload
that's
sent
in
the
outer
client
hello,
if
that
changes,
then
if,
if
that's
changed
in
future
versions
of
ech,
then
th
that'll
break
backwards.
Compatibility
because
of
the
because
of.
E
E
B
So
what
what
you
need
on
the
server
side
is
to
be
able
to
determine
which,
because
the
versions
and
the
configs
are
one-to-one,
you
need
to
determine
which
config
was
used
and
in
order
to
do
that,
you'd
be
able
to
process
the
first
two
fields,
namely
the,
namely
the
sephora
sweet
field,
to
tell
you
which,
which
hash
to
use,
and
then
the
and
the
in
the
next
field,
with
the
has
the
hashtag
and
everything
else
can
be
freeform
right.
So
what
we're
committing
to
I
mean
what
we're
commit.
B
I
B
So
I
think
I
guess,
like
I
think,
I'm
with
david
in
the
sense
that
like
if
we,
if
we
really
decided,
we
were
like
sad
about
like
that.
This
isn't
the
first
two
field
structure.
Then
we
could
just
invent
some
nukes
instead
of
code
points.
So
I
think
I
I
am
balanced
performance
remove
version,
but
I
mean
if
it
were
there,
I'm
like.
If
we
were
in
last
call
over
there.
I
probably
wouldn't
fight
about
it.
C
I
think
I
would
agree
as
well
like
the
first
two
fields.
Being
an
invariant
seems
pretty
much
are
pretty
insane
to
me.
I
don't
think
it's
documented
anywhere
in
particular
that,
like
these
two,
we
expect
these
two
to
not
change,
but
we
could
do
that
and
then,
if
we
need
to
make
something
new
down
the
line,
because
we
want
to
share
the
variance,
we
just
use
a
different
code
point
well
very.
E
You
know
we
people
have
discussed
various
ways
of
of
indicating
which
configuration
was
used
basically,
like
you
know,
like
nick
sullivan,
once
proposed,
like,
let's
just
let's
have
like
a
super
truncated
hash,
which
I
guess
I
guess
is
the
same.
Like
you
know
it's
still,
it's
still
a
config
hash
technically,
but
I
guess
I'm
concerned
that,
in
order
to
you
know
as
a
as
an
anti-ossification
measure
we
these
might,
these
might
change
in
the
future.
E
So,
like
I'm,
not
sure
that
we
want,
we
want
to
commit
to
them.
I'm
happy,
I
don't
see
a
reason
to
change
them
from
where
I
sit
like
it
seems.
Like
a
you
know,
this
is
like
the
necessary
information
for
picking
the
configuration
today.
We
just
can't
change
the
way
the
configuration
is
picked.
So
if
anyone
can
envision
changing
that
in
the
future,
I
think
then
we
should
add
the
version.
C
G
A
G
A
We're
we're
out
of
time
and
so
to
respect
everybody's
time.
I
think
we'll
call
it
here
and
take
some
of
this
discussion
of
the
list.
I
think
we'll
also
try
to
schedule
another
one
of
these
in
roughly
a
week,
maybe
a
little
bit
longer
to
get
rid
of
it
to
find
a
good
time
or
two
weeks.
Okay,
two
weeks
and
yeah
thanks
for
joining
and
remember
to
sign
the
attendance
sheets.