►
From YouTube: TLS WG Interim Meeting, 2021-04-01
Description
TLS WG Interim Meeting, 2021-04-01
A
Standard
for
all
atf
meetings
and
today
we're
discussing
ech
is
there
anybody
who'd
be
willing
to
take
some
notes
in
code.
B
Emd,
I
can,
can
you
post
the
link.
A
A
All
right
so
chris,
do
you
chris
wood.
Do
you
wanna.
C
Yeah
yeah,
so
in
the
in
the
go
dmd
page,
I
put
a
sorted
list
of
issues.
I
think
we
should.
That
would
be
good
to
go
through
and
discuss.
C
There
are
a
couple
other
like,
as
you
may
have
seen
on
the
list.
There
are
some
small
prs
that
went
up
that
are
not
really
contentious
or
shouldn't
be
contentious,
so
I
I
think
we
can
keep
those
discussion
of
those
sort
of
on
the
list
and
hopefully
resolve
that
and
merge
them
soon,
but
the
list
in
the
the
notes
page,
I
think,
are
sort
of
the
the
big
ticket
items
if
possible
I'd
like
to
because
we
only
have
an
hour.
C
I
believe
I
would
like
to
leave
half
of
the
meeting
to
talk
about
hr.
I
expect
that
to
be
how
we
spend
most
of
the
time
or
that
to
be
sort
of
the
most
contentious
issue
here,
the
other
one's
less.
So,
but
who
knows
this
thing?
These
things
always
go
well
in
various
ways.
So
dude,
I
don't
know
if
people
have
the
the
page
open,
but
if,
if
you
do
and
you'd
like
a,
I
guess
a
change
in
or
a
different
sorted
order
of
issues.
C
Okay,
I
guess
you're
nothing.
Let
me
just
pop
open
the
first
issue.
C
It
looks
good
for
my
view,
assume
the
same
for
everyone
else,
but.
C
Okay,
so
yeah
steven
filed
this
issue.
He
is
here
talking
about
how
the
the
current
use
of
hpe
does
not
allow
use
of
a
single
shot
api,
which
is
one
of
the,
I
guess
nicer
features
of
hpke.
There
are
various
reasons
for
why
this
was
done
david.
I
think
summarized
it
quite
nicely
in
the
last
comment
on
this
issue.
So
if
you
scroll
down.
C
D
Geez,
can
I
suggest
something.
D
I
mean
I
think,
if,
if
hr
or
stays
anywhere
like
it
is,
this
definitely
gets
closed
if
hrr
turns
into
something
that
allows
a
single
shot
api.
We
could
revisit
this.
So
maybe
just
leave
this
one
open
until
that's
clear,
which
is
probably
more
important
anyway,.
C
That
seems
like
a
reasonable
proposal.
I
I
don't
know,
I
guess
david
said
you've
been
engaged
on
the
thread.
Do
you
want
to
do
you
want
to
say
anything
about
this
particular
issue?.
E
Sorry
I'm
needed,
I
seem
as
reasonable
to
me.
I
I
mean
I
think.
Like
you
know,
all
of
these
decisions
are
like
secretly
are
like
subtly
linked
to
each
other.
I
think
like,
given
the
current
state
of
the
world
or
things
remotely
close
to
the
current
state
of
the
world.
This
is
the
right
formulation,
maybe
we'll
completely
change
out
of
them.
C
D
So
this
is
the
compression
yeah,
okay,
so
people
I
I
seem
to
be
in
the
roof
here.
I
still
think
it's
a
mad
terrible
idea,
but
if
I'm
in
the
rough
I
mean
they're
off
but
and
and
I
I
was
working
on
my
draft
10
code
today
and
I
had
an
off
by
one
count-
error
in
the
reconstruction
of
the
inner
ch.
Because
of
this,
so
I
think
we'll
hit
people.
But
if
I'm
in
the
rough
I
mean
they're
off.
C
Right
so
the
I
guess
the
the
key.
Well,
I
don't
want
to
speak
for
you,
stephen,
but
it
seems
like
the.
The
key
point
is
that
the
thing
is
over
the
general,
perhaps
overly
general
right
now
and
complicated
to
implement
and
given
that
we
might
not
need
to
compress
everything
and
maybe
only
need
to
compress
key
shares.
Why
don't
we
do
just
that
or
do
nothing?
I
guess
is
another
option.
I
see
ben's
in
the
queue
so
I'll.
Let
him
speak.
F
Hey,
I
guess
I'd
like
to
try
to
distinguish
a
little
bit
between
whether
we
want
to
develop
a
feature
now
and
how
it
actually
is
spelled
in
terms
of
spelling.
I
can
see
some
variations
that
might
make
people
a
little
happier
like,
for
example.
F
But
if
you
just
do
nothing,
then
the
inner
and
outer
are
the
same,
which
is
usually
what
you
want
that
so
that
that
sort
of,
but
that's
just
really
a
wire
formatting
question
and
another
possibility
to
split
the
difference
here
would
be
to
declare
this
as
an
extension,
an
ech
extension
and
and
do
it
and
still
do
it
now,
but
but
do
it
as
an
extension.
B
Yeah,
I
was
just
gonna
say
this
is
something
that
it's
up
to
the
client.
If
they
want
to
implement
it
or
not,
the
server
always
has
to
implement
it,
but
my
implementation
experience
is
that
the
server
side
is
fairly
straightforward.
B
It
always
does
the
same
thing,
no
matter
what
the
complexity
really
here
is
on
the
client
side.
So
it's
up
to
the
client
to
decide.
You
know
how
much
complexity
it
wants
to
eat,
but
yeah
that
yeah,
that's
all
I
was
gonna,
say.
C
Christian
axe
asked
the
question:
why
do
we
want
to
specify
this
before
the
implementation
experience
and
just
reply
that
we
do
have
implementation
experience?
I
believe
nss
and
boring
ssl
and
the
cloudflare
go
stack
of
all
implements
as
steven
in
this
particular
case.
So
right
so
I'd
like
to
hear
from
other
people,
who've
implemented
it
in
terms
of
what
they
want
to
do.
G
C
C
C
So
is
there
any
way
we
can
do
sort
of
like
there's,
not
a
lot
enough
people
in
the
room
to
sort
of
do
a
representative
or
anything,
but
I
I
I
think
like
we,
we
should
do
something
to
avoid
circling
on
this
particular
issue
and
yeah.
Oh
sorry,
steven.
D
Yeah
I
I
was
gonna
suggest
you
know.
I
I
think
I
know
a
bunch
of
people
have
expressed
opinions
on
the
list,
so
I
I
think
we
could
regard
me
as
more
or
less
in
the
roof
and
just
live
with
the
horror
for
now
anyway.
So
I
I
I'd
say
this
is
one
that
that
the
chairs
could
kind
of
declare
it's
reasonably
clear
that
I'm
in
the
roof.
H
See
if
my
earbud
is
working,
if
that's
the
case,
let's
go
ahead
and
do
that.
Let's
say
that
we're
gonna
go
ahead
and
close
this
one
and
declare
stephen
the
rough.
C
Stephen,
this
might
also
be
good
because
we're
keeping
open
the
the
complexity
issue,
basically
until
we
ship
this
thing.
It
might
be
good
to
note,
like
port
some
of
this
over
to
that
particular
issue.
Just
so
like
we
don't
lose
track
of
it,
I
mean,
among
the
other
things
that
are
complicated,
implement.
This
is
one
of
them.
So,
if
we're,
if
we're
going
to
like
do
a
comb
over
the
spec
to
see
how
we
might
simplify
things
in
the
future
might
as
well
include
this.
D
Yeah,
that's
fair
enough.
I
I
think
the
main
thing
is
that
you
know
the
the
main
complexity
it
brings
is
there's
no
kind
of
saying
api
that
you
can
offer
a
generic
application
client,
but
I
can
see,
but
I
I
could
take
an
action
to
try
and
I
guess,
write
a
comment
in
the
other
issue
on
complexity,
about
that
yeah,
like
put
it
up
here
or
later.
C
Yeah
that
sounds
good
and
david
left.
The
comment
in
chat,
which
I
think
it's
perfectly
reasonable,
which
is
like
keep
what
we
have
for
now
close
this
out,
keep
what
we
have
for
now.
If
something
simpler
comes
along
later
during
the
course
of
this
complexity,
investigation
by
by
all
means,
we
should
adopt
a
simpler
thing:
okay,
cool,
let's,
let's
move
on
to
the
next
one
right,
stephen!
Do
you
want
me
to
speak
to
this,
or
do
you
want
to
summarize.
C
I
don't
know
about
that.
Okay,
so
basically,
the
the
the
current
accepting
signal
is
like
as
conservative
as
we
could
possibly
be,
given
all
of
the
different
interesting
active
do
not
stick
out
attacks
that
brought
up
on
the
list
in
the
course
of
like
trying
to
figure
out
how
to
avoid
trial
decryption
way
back
when
and
by
conservative,
I
mean
it
goes
through
the
actual
key
derivation
step
for
the
handshake
secret
and
then
derive
just
a
signal.
C
An
acceptance
signal
from
that
then
pointed
out
that
this
is
somewhat
problematic
and
circular
in
that,
like
you,
might
have
to
process
the
key
share
extensions
more
than
once,
which
is
kind
of
annoying
and
there's
a
potential
relaxation
which
one
might
do
wherein,
rather
than
like,
actually
going
through
the
key
derivation
step
twice,
you
simply
derive
the
secret
from
the
the
or
the
signal
from
the
supposedly
secret
client,
hello,
inner
and
the
the
server
hello
that
would
be
used
as
the
transcript
during
the
the
handshake
secret
derivation,
and
this
seems
like
a
perfectly
sort
of
reasonable
approach,
but
just
to
kind
of
throw
my
opinion
into
the
room.
C
I
think,
given
the
the
the
problems
we've
had
with,
you
know,
lack
of
binding
and
just
odd
active
attacks
that
seem
to
creep
up
while
or
over
the
course
of
this.
You
know
the
development
of
this
particular
protocol.
C
I'd
be
inclined
to
just
kind
of
park
this
one
until
we
get
a
you
know,
a
grasp
of
the
protocol
and
its
formal
like
effectively
have
a
formal
analysis
of,
and
we
can
convince
ourselves
that,
like
you,
know,
relaxing
the
signal
computation
from
what
we
have
now
to
david's
proposal
is
safe
to
do
so.
C
And
I
guess
martin's
in
the
queue,
but
that's
the
gist
and
that's
my
proposal.
G
Yeah,
so
I
was
going
to
say
a
similar
thing,
but
more
to
the
more
toward
the
keep
it
as
it
is
side
of
things.
I
realize
that
this
is
a
stumble
that
potentially
exists,
because
you
do
need
this,
but
if
you
don't
have
different
key
shares
in
the
inner
and
outer
this
is
not
a
problem,
so
our
implementation
just
goes
ahead
and
and
uses
the
the
singular
key
share
that
we
have
to
derive
the
secrets
before
even
really
deciding
whether
whether
to
do
ech
or
not,
and
that
works
out
perfectly
fine.
C
Yeah,
there
is
a
sort
of
dependency
on
the
hr
thing
here,
so
like
parking
it
also.
While
we
resolve
that
hr
issue,
it
just
further
makes
sense
to
me.
I
don't
know
if
david
wanted
to
say
something
to
that
effect.
E
That's
mostly
what
I
want
to
say,
but
I
do
want
to
footnote
martin's
comment
on
the
key
share
that
you
do
need
to
rewind
back
on
the
psk
or
not
necessarily
rewind,
there's
some
like
weird
interaction
with
the
psk,
because
the
psk
is
inserted
into
the
key
schedule
before
you
decide
whether
or
not
you
accepted
things,
but
it's
only
sent
to
the
inner
client
hello,
so
you
sort
of
have
to
like
double
check
after
the
fact
that
the
server
hello
was
actually
invalid.
When
you
like
decide,
which
is
mildly,
weird,.
G
Yeah,
I'm
I'm
going
to
say
that
I'm
not
really
very
confident
in
my
understanding
of
how
psks
and
ach
worked
together,
and
so
it
might
be
that
we
have
bugs
in
our
code.
But
I
don't
know,
didn't
come
up.
C
C
C
Right
so
this
is
a
particularly
interesting
pull
request.
That's
received.
A
lot
of
discussion
is
dan
in
the
room
by
chance.
Yes,
he
is
dan.
Do
you
want
to
speak
to
this,
or
would
you
like
me
to
do
so.
I
About
that
yeah,
so
this
is
this-
is
this-
is
about
the
issue
raised
in
number
405,
that
david
wrote
up.
The
issue
is
that
stuff
from
the
dns
can
find
its
way
into
the
server
name.
Extension
right
now
on
the
client,
hello
outer
and
we're
talking
about
clamping
down
on
the
values
that
can
go
in
there,
david
david
raised,
like
a
sql
injection
steering
example,
and
so
the
question
on
this
is:
do
we
want
to
restrict
it
to
host
names?
I
Only
do
we
want
to
also
allow
ip
addresses
if
we
want
to
allow
host
names?
Only
do
we
want
to
exclude
ip
addresses,
like
ipv4
addresses
that
kind
of
look
like
a
dotted
hostname
representation.
C
So
I
I
think
and
david
I
think,
could
probably
summarize
it's
much
better
than
I
can,
but
from
my
perspective,
there
seems
to
be
like
two
things
floating
around
here,
the
first
of
which
is
like
what
actually
goes
in
the
the
public
name
field
in
the
config
and
how
is
how
are
clients
or
stacks
supposed
to
validate
that
before
actually
consuming
it
and
the
second
of
which
is
how
they
construct
a
client
hello,
using
that
information
to
connect
to
the
the
client-facing
server?
C
This
sort
of
ties
into
another
issue,
which
is
the
next
one
in
the
list
that's
even
filed,
which
is
like,
should
the
client
be
forced
to
put
something
in
the
server
name
field
or
not?
You
could
imagine
if
ip
addresses
are
permitted
for
the
you
know,
the
the
client
facing
servers
rejection
certificate
that,
like
certainly
like
you,
don't
put
ip
addresses
in
the
certain
end
field.
So
so
nothing
would
go
there.
So
we
need.
C
We
would
need
to
like
rework
that
language
a
little
bit,
but
I
think
it
might
be
useful
to
to
separate
these
two
concepts.
That
is,
you
know
what
actually
goes
in
this
particular
blob
and
then
how
you
construct
a
client
holo
using
this
blob.
So,
given
that,
I
guess
ben
is
in
the
queue.
F
Yeah
then
hey
ben
schwartz,
so
it
seems
like
this
question
would
be
a
lot
easier
if
we
were
willing
to
spend
one
byte
and
and
go
back
to
having
the
specified
public
name,
be
a
server
name
as
used
in
sni.
You
know
the
rfc
6066
server
name,
so
it's
just
one
byte
and
then
something
and
the
one
byte.
If
it's
a
zero,
it's
dns.
Otherwise,
maybe
it
could
be
something
else.
If
we
ever
want
to
extend
that,
you
know,
I
think
we're
we're
finding
that
we
need.
F
G
Martin,
so
I
think
the
only
thing
that
we're
really
concerned
with
here
is
the
distinction
between
dns
names
and
ip
addresses,
and
for
that
I
don't
think
spending.
The
extra
byte
is
really
necessary
that
they're
readily
distinguishable
aside
from
the
fact
that
an
ipv
v4
address
in
dotted
decimal
is
actually
a
valid
ldh
name.
But
aside
from
that,
we
routinely
distinguish
between
the
two
of
them.
G
I,
I
guess
the
the
real
question
for
me
is
what
the
expectations
the
the
client
is
given
with
respect
to
the
two
things,
and
I'm
actually
really
quite
happy
with
the
idea
that
that
dan
sort
of
suggested,
which
is
that
the
name
that's
in
that
field,
is
the
name
that
you
use
to
validate
the
certificate
or
the
identity,
rather
that
you
use
to
validate
the
certificate
that
the
server
offers
in
a
fallback
scenario,
and
that
you
would
include
a
dns
name
in
the
the
client
hello.
C
Yeah,
I
think
that's
sort
of
the
the
most
ergonomic
way
to
to
resolve
these
two
issues,
and
that
is
just
reframe
this,
as
the
name
used
to
verify
the
fallback
certificate
or
the
identity
that
you
use
to
verify
this
all
by
callback
certificate
and
that
could
be
ip
address.
If
it's
an
if
the
server
uses
an
id
cert
or
it
could
be
a
name
but
definitely
not
drop
tables.
C
G
Yeah,
I'm
less
enthusiastic
about
enthusiastic
about
being
entirely
rigorous
about
validating
the
contents
of
this.
I
think
we
can
probably
get
away
with
something
fairly
minimal.
C
Yeah,
I
I
don't
feel
strongly
about
the
language
it's
just
like
yeah
yeah,
provided
that
provided
that
that's
the
concept.
I
guess
that
we
want
to
you
know
or
that
that's
the
the
sort
of
composition
that
we
want
to
achieve
here.
I
I'd
be
okay
with
I'd,
be
okay
with
you
know
something.
That's
simple,
stephen.
D
Yeah
just
just
wanna
check,
I
understand
what
you
said
there
chris,
which
sounds
okay
to
me.
So
so,
basically,
what
we're
saying
is
that
the
the
public
name
should
be
a
name,
a
name
that
you
can
use
to
verify
the
fallback
cert
and
what
the
client
puts
in
the
outer
sni
should
similarly
be
such
a
thing.
D
C
So
I
I
think,
rather
than
being,
I
guess,
specific
in
terms
of
masjid
whatever
what
what
that
actually
goes
in
the
sni.
I
I
think
the
the
suggestion
that
I'm
trying
to
make
is
that
we
just
sort
of
rewrite
this
text,
so
it
talks
more
about
how
you
construct
an
outer
client
hello,
given
an
identity
that
you
would
use
to
verify.
C
C
I
I
don't
know
if
that
distinction
is
clear,
but
that
sounds.
C
Okay-
okay,
great
I
I
guess
ben
is
next
in
the
queue.
F
Yeah,
so
I
just
don't
like
the
idea
of
trying
to
parse
this
one
string
in
these
different
ways
and
if
we
really
so,
if
we,
if
what
we
really
mean
is
this-
is
the
identity
that
you
are
supposed
to
use
in
order
to
in
order
to
parse
a
in
order
to
validate
the
certificate
that
comes
back,
then
it
should
probably
be
something
like
an
x509
subject
or
like
an
x509
common
name
or
something
so,
but
regardless
of
of
exactly
how
it's
formatted,
I
think
it
needs.
F
It
needs
an
indirection
byte.
It
needs
a
tight
byte
if
we're
going
to
try
to
cram
in
multiple
things
here.
Otherwise
we're
going
to
end
up
with
something
where
we're
saying.
Oh,
this
is
the
identity
that
you
use
to
validate
the
certificate,
but
actually
only
domain
names
and
ip
addresses
are
acceptable.
Identities
and
and
other
kinds
of
identities
that
do
exist
in
the
world
are
like
non-expressible
or
maybe
expressible,
but
only
if
you
can
somehow
distinguish
them
by
parsing.
C
So
before
turning
over
to
david,
my
impression
for
the
resolution
of
this
would
be
that
yeah,
it's
the
only
permitted,
identities
are
names
and
ip
addresses.
C
C
Are
anyways,
so
I
I
I
I
think
perhaps
a
good
way
forward
for
this
issue
and
then
the
next
one
in
the
list
would
be
to
sort
of
re-jiggle
this
text
a
little
bit
so
that
it
focuses
on
the
this
being
an
identity
and
then
to
resolve
issue
396,
which
is
the
must
versus,
should
go
in
the
server
name,
rewrite
that
text.
C
So
it's
more
about
how
you
construct
the
client
hello
outer
based
on
that
identity,
rather
than
try
to
be
very
crisp
or
rigid
in
terms
of
like
what
must
and
must
not
go
with
the
server
name.
C
I
think
that
would
resolve
the
two
issues
quite
nicely:
okay,
great,
let's
I
guess.
Let's,
let's
start.
H
C
Sounds
good
lovely
so
we'll
work
on
pr's
for
those
two
things
and
then
close
them
out
shortly
all
right,
so
the
last
big
one
which
should
take
up
the
rest
of
the
meeting
is
hr.
C
So
I
I
don't
know
who
wants
to
speak
to
this
first
there's.
Obviously
a
lot
to
consider
in
this
particular
proposal.
In
terms
of
you
know,
client,
side,
server-side
complexity.
You
know
whether
or
not
you
want
like
rca446
compliance
or-
and
you
know,
slew
of
other
things.
I
think
either
chris
or
david
obviously
thought
a
great
deal
about
this.
So
would
one
of
you
like
to
sort
of
summarize,
perhaps
how
we
got
here
and
and
what
this,
what
this
particular
proposal
is
about.
E
E
E
Is
a
giant
disaster,
but
it
is
also
a
thing
that
exists,
so
we
are
kind
of
stuck
with
it.
We
have
a
few
issues
all
floating
around
here,
so
the
first
is
that
it
is
ambiguous.
So
you
can't
tell
whether
the
hello
retry
request
in
the
current
draft
applies
to
both
the
inner
and
the
outer
client
hello,
which
means
that
now
we
need
to
worry
about
what
happens
if
it
is,
if
you
can
construct
one
that
a
hillary
tried
request.
That
applies
to
one,
but
not
the
other.
E
D
E
E
Maybe
that
since
changed,
I
don't
know,
let's
see
split
so
eck
has
the
split
mode
thing:
we've
got
this
client-facing
server
and
the
back-end
server,
who
might
not
necessarily
know
a
whole
lot
about
each
other
and
if
the
split
mode
server
wishes
to
send
a
cookie
on
f
accept
because
it's
doing
stateless
hr,
there
is
no
way
for
it
to
do
this,
because
by
the
time
it's
constructed,
because
by
the
time
it's
gotten
the
hello
retry
request
to
forward
the
backend
server
has
already
filled
in
the
cookie.
E
So
we
would
need
to
either
declare
that
we
do
not
want
to
solve
this
problem
or
do
something.
Let's
see,
there's
this
compatibility,
slash,
rfc846
compliance
nuisance,
where
we
put
very
strict
rules
in
hello,
retry
request
that
unprompted.
You
cannot
change
an
extension
in
the
second
client
hello,
which
means
that
we
are
not
allowed
to
re-encrypt
the
second
client
hello.
E
Unless
we
stick
a
hello,
retry
request
extend
sorry
an
x
extension
inside
hello,
retry
request
unless
we
go
and
update
that
role,
which
probably
needs
to
happen
in
our
ca,
456
biz
that
has
some
extra
wriggles,
because
at
least
one
tls
implementation
libre
ssl
enforces
this
role.
The
the
a456
text
applies
just
to
the
client
and
it's
sort
of
ambiguous
what
you
do
on
the
server,
but
some
servers
have
decided
it
checked.
E
E
It
also
makes
it
introduces
a
way
to
distinguish
between
grease
and
non-grease.
By
forging-
and
this
I
think,
ben
schwartz
came
up
with
this.
You
can
just
forge
a
hello
retry
request
and
even
if
the
server
wasn't
going
to
do
hello,
retry
request,
you
can
see
if
the
client
would
have
switched
it.
E
I
think
that
may
be
most
of
them,
and
so
this
proposal
was
a
like
well,
given
we've
got
all
of
these
problems.
Let's
see
what
it
would
look
like
to
try
to
like
do
the
other
thing
and
yeah.
It
is
a
bit
of
a
headache,
unfortunately,
but
it
does
dispatch
all
of
these
problems.
Yeah-
and
I
guess
now
is
here
where
we,
where
we
debate,
complexity
and
motivations
and
problems
and
and
like
which
problems
are
in
art
worth
solving,
but
it
seemed
worth
putting
on
the
table.
G
Yeah
I'll
start
out,
so
let's
see
I
I
first
of
all,
I
just
realized
in
david's
summary
there
that
I
sort
of
misunderstood
the
the
framing
of
the
the
cookie
problem.
I
hadn't
realized
that
there
was
potentially
two
cookies
that
different
servers
wanted
to
provide.
G
Just
from
my
perspective,
I
think
I'm
happy
to
let
that
one
just
be
solved
by
the
two
servers
collaborating
more
more
fully
when
it
comes
to
dealing
with
the
split
mode
and
and
hr,
and
that
is
probably
easier
in
the
case
where
you
want
to
have
split
mode
with
the
front.
Doing
a
stateless
but
also
being
able
to,
in
the
case
of
the
stateless,
send
the
forward
the
inner
client
hello
to
the
back
end.
G
It
seems
like
a
pretty
narrow
sort
of
use
case
to
worry
about,
but
I
think
probably
the
thing
that
I
realized
once
I
went
through
all
of
this
was
that
the
the
requirements
that
we
have
are
completely
simple.
G
When
you
look
at
the
implementation,
if
you
assume
that
the
client
is
sending
the
same
thing
for
those
for
inner
and
outer
for
those
things
that
actually
matter-
which
is
not
a
lot
of
things,
as
I
pointed
out
in
my
email,
there's
really
only
one
thing
that
changes
between
the
the
first
and
the
second
one
and
that's
the
the
choice
of
which
groups
you
provide
key
shares
for
and
if
you
just
look
at
that
particular
problem,
it's
not
that
difficult
to
solve.
G
If
you
have
shares
for
the
same
groups
in
inner
and
outer,
which
is
probably
what
people
are
going
to
do
anyway.
So
I
don't
think
that
there's
anything
particularly
onerous
in
terms
of
client
side
for
dealing
with
a
model
where
hrr
applies
to
both.
G
What
other
things
were
there?
Oh
yeah,
the
the
whole
morass
of
problems
around
how
I
reached
a
request
in
in
the
core
spec,
seemed
to
be
fixed
by
david's
proposal
to
to
say
that
extensions
have
their
own
rules
for
how
they
might
change
in
response
to
how
I
retry
request,
even
if
they
aren't
present
in
it
and
that's
fine,
I
recognize
the
compatibility
problems,
but
I
think
that's
something
that
we
can.
G
We
can
work
through,
as
I
pointed
out
in
my
email,
there's,
not
really
any
concern
with
actually
deploying
ech
if
we
allow
for
the
grease
to
stay
the
same.
I
also
don't
care
about
the
this.
The
the
verification
attack
with
the
spoofed
hrr.
I
think
that's
just
something:
we've
already
accepted
what
else
was
there?
G
I
don't
think
we
need
an
accepted
signal,
nhri,
random
or
in
hr
period,
because
if
they're
the
same,
then
that's
that's
fine.
I
think
that's
that's
all
I
really
had
let
others
argue
from
the
complexity
I
for
me,
the
complexity
is
unacceptable.
E
So
the
matching
rule
is
a
bit
more
complicated
than
what
you
write.
It's
still
like,
it's
still
something
that
like
yeah.
I
agree
that
most
of
the
time,
you
should
do
it
anyway,
but
you
need
it's
not
anything
that
can
change
in
response
to
hr.
It's
anything
that
will
change
which
hrs
you
accept,
and
so
the
cipher
suites
need
to
match
as
well
and
also
sorry,
the
tls
one
three
up
subset
of
the
cypher
suites
must
match
as
and
also
the
tls
one.
E
Three
up
subset
of
the
versions
must
match,
and
also
we
need
to
come
up
with
like
words
that
capture
any
future
extensions.
We
may
add.
I
think
you
pointed
out
in
your
email
that
there
was
this
password
salt
extension,
which
I
also
need
to
go
and
dig
into
more,
but
at
a
glance
it
seems
like
something
where
you
might
not
actually
want
it
in
the
outer
client
hello.
E
Given
that
like
it's,
it
seems
to
be
about
authenticating,
some
client
identity
with
a
password,
and
you
wouldn't
want
to
present
the
client
identity
for
the
outer
client
hello,
but
I
also
haven't
looked
at
it.
So
I
could
just
be
totally
off
on
that,
so
that
was
like
the
like.
I
if
we
can
come
up
with
a
way
to
say
the
matching
rule
like
I
I
I
mean
that
is
what
we
originally
suggested
doing.
It
didn't
particularly
work
the
first
time.
E
I
think
I
think
you
actually
were
one
of
the
people
who
had
had
we
had
a
long
thread
with
on
the
comment
on
the
on
the
pr,
and
I
think
we
didn't
end
up
on
the
same
page
and
the
draft
actually
right
now
has
some
self-contradictory
information,
because
we
didn't
get
the
criteria.
E
D
Yeah,
I
guess
I
I
first
of
all
I'm
sorry
if
I
pissed
off
anybody
or
implied
anybody
had
bad
motivation
and
by
my
mail
to
the
list.
It
wasn't
intense
and
I've
made
these
mistakes
myself
a
lot.
I
I
just
wonder,
would
we
be
better
off
looking
to
see?
Can
we
get
rid
of
some
of
the
case?
D
The
current
pr,
I
think,
attempts
to
kind
of
solve
all
the
cases
via
hrr,
and
that
creates
a
bunch
of
complexity.
I
wonder,
would
be
better
to
just
accept
that
someone
a
bunch
of
these
cases-
maybe
not
all
of
them,
but
a
bunch
of
them
are
just
failures
and
we're.
You
know
we
require
you
to
not
do
something
that
that
shoots
yourself
in
the
foot
and
if
you
choose
to
you
know,
have
a
split
mode
back
end
server
that
only
supports
brain
pool
or
something
it's
likely
just
not
gonna
work
for
you.
C
G
G
In
terms
of
that,
my
analysis
of
the
inner
outer
constraints
that
we
would
have
to
apply
is
simply
that
the
client
has
the
same
preferences
for
anything
that
might
govern
what
the
handshake
keys
might
ultimately
be,
which
is
the
only
sorts
of
things
that
hr
can
actually
change
anyway,
and
so
that's
pretty
simple,
you
keep
the
same
set
of
cipher
suites
that
you
advertise
in
the
inner
and
outer,
and
that's
probably,
okay.
G
It's
not
really
that
much
of
a
secret
sort
of
suggests,
maybe
that
we
don't
need
to
encode
the
cypher
sweet
list
in
the
inner.
But
let's
not
go
there.
G
G
My
response
to
that
was,
if
you
have
something
different
in
the
inner,
it's
gonna
be
very
visible
that
that
different
in
some
cases
anyway,
it's
going
to
be
very
visible
that
that
difference
exists
depending
on
which
one
of
the
two
client
hellos
is
ultimately
accepted.
So
I
think
that
probably
we
ultimately
want
the
same
configuration
for
versions,
groups,
cipher,
suites
and
signature
route.
It's
not
secret
interact
with
it
as
psk,
so
I
think
it
was
the
other
one
in
in
both
inner
and
outer
solves
the
problem.
I
think.
J
Becker
yeah,
so
I
was
still
trying
to
figure
out
what
I
think,
but
I
have
a
few,
maybe
preliminary
questions
that
maybe
may
be
good
either
martin
or
david
benner,
both,
but
also
I
have
a
saying
when
I
say
here
for
that
there
are
two
kinds
of
complexity
here.
J
Well,
these
two,
maybe
three,
there's
implementation,
complexity,
there's
protocol
complexity
and
analysis
complexity,
and
what
I
see
the
I
mean
the
the
original
decision
to
go
to
ch
enter
and
ch
address
was
an
attempt
to
remove
analysis
complexity,
namely
that
every
time
that
every
time
we
tried
to
like,
like
only
cut
pieces
of
pieces
of
it
and
stuff
them
in
and
then
encrypt
their
envelope.
We
like
random,
analytic
problems
and
so
from
an
analytic
perspective,
it
seems
like
encrypting.
J
The
hr
is
also
is
also
just
the
same
kind
of
take.
People
may
recall
that
at
one
point
I
think
it
was
deb
cooley
suggested
just
tunneling
like
just
doing
tls
inside
of
tls
and
at
some
level.
That's
that
that's
what
that's
what
it
would
be.
If
you
just
did
you
know
if
you,
if
you
just
did
encrypted
client,
hello
and
then
and
then
encrypted
hr,
the.
J
It
would
be
helpful
to
me.
I
see
this
list
of
issues
in
github
very
helpful
to
me
if
we
had
a
document
which
I'd
be
happy
to
apply
for
preparing
which
had
like
a
succinct
description
of
each
of
the
problems
with
occur
with
like
the
current
pre-pr
design,
so
that
we
could
like
actually
think
about
them
independently.
J
Perhaps
and
finally,
oh
sorry,
two
more
things,
I'm
still
not
quite
following
the
double
cookie
issue,
so
maybe
everyone
can
walk
me
through
it
and
also
what
happens
in
the
case
where
that
martin
indicated
where
you
say
well,
they
have
to
be.
You
have
to
have
the
same
things
in
the
internet
or
what
happens
if
you
don't.
F
C
B
I
just
wanted
to
suggest
if
it's
possible,
you
know
we're
kind
of
responding
to
like
three
different
things.
The
last
person
said
about
three
different
points.
I
think
it
might
be
helpful
to
kind
of
narrow.
On
one
thing
I
mean
in
that
spirit,
I'm
just
going
to
respond
to
one
thing
I
so
the
martin
thompson's
suggestion
like
the
rule
should
just
be
that
the
inner
and
outer
preferences
have
to
be
the
same.
B
I
think
that's
a
very
difficult
thing
to
enforce
in
the
future,
because,
because
future
extensions
are
going
to
act
interact
with
ech
in
ways,
we
can't
really
predict
right
now,
and
I
think
that
the
the
main
reason
I
like
the
hello,
retro,
hr,
inner
and
outer,
is
that
it's
sort
of
it
sort
of
future
proves
things
it
it.
It
makes
it
see
it.
I
I
think
it's
gonna
make
it
ultimately
simpler
to
compose
ech
with
future
extensions.
C
It
so
I
don't
think
anyone
else
is
left
in
the
queue.
Oh
then
go
ahead.
F
Hi,
I
just
want
to
point
out
that,
while
while
we
can
reasonably
request
that
the
or
demand
that
the
client
use
the
same
keyshare
groups
in
the
inner
and
outer,
for
example,
I
think
it's
actually
much
more
difficult
to
demand
that
the
that
the
client-facing
server
that
the
fallback
and
the
back-end
servers
support
the
same
set
of
cipher
suites,
because
server
configurations
need
to
be
able
to
change
over
time.
E
I
mean
if
they
don't
share
configuration
there,
you're
you're,
going
to
have
few
smaller
anonymity
sets
than
you
actually
think
you
do,
but
I
don't
think
it
breaks
this
property.
E
I
was
going
to
suggest
that
the
that,
so
I
agree
that
the
so
so
it
seems
that,
like
the
the
main,
like
the
the
double
cookie
thing,
I
think
I
agree
with
martin
that,
like
you
know,
if
we,
if
we
decide,
we
don't
want
to
do
it,
we
could
not
do
it.
I
I
followed
the
issue
in
like
october
and,
like
there
wasn't
a
like
consensus,
not
to
do
it,
and
so
we
were
like.
Oh,
this
is
like
a
thousand
paper
cuts.
E
Let's
see
what
happens
if
we
try
to
fix
it,
I
think
probably
the
main
the
main
source.
The
the
main
question
is
around
this
like:
how
do
we
write
down?
E
How
do
we
and
do
we
try
writing
down
the
client,
hello
matching
roles,
and
so
maybe
a
way
out
a
way
forward
would
be
for
someone
to
take
another
stab
at
writing
down
those
rules
in
like
a
future-proof
way
that
so
that
we
can
compose
with
future
hr
extensions
and
such
and
then
we
can
just
see
how
it
goes
and
then
we'll
have
something
more
concrete
to
compare
against.
G
Martin,
I
sort
of
cued
and
dequeued
myself.
I
thought
I
dropped
to
the
back,
but
that's
that's
okay,
so
yeah
the
the
cookie
thing
I
think,
we'll
yeah
it
seems
like
we
can
probably
just
put
that
to
bed.
There's
a
real
corner
case
there.
That
is
different,
but
my
analysis
of
the
the
situation
was
basically
that
the
rules
we
have
which
people
aren't
particularly
happy
with,
are
actually
correct
in
that
they
work.
G
I
was
looking
at
the
draft
and
was
like
well
maybe
there's
a
hole
in
there
and
there
was
a
hole.
There
was
a.
There
was
a
hole
with
respect
to
the
starting,
the
handshake
over
again
ignoring
the
the
rules
in
8446.
G
If
the
key
shares
were
wrong
or
something
like
that-
and
so
that's
fine-
we
can,
we
should
get
rid
of
that,
but
the
the
rest
of
it
was
is
actually
correct
in
that.
If
your
extension
might
change,
then
you
have
to
provide
the
same
in
in
both
inner
and
outer
or
at
least,
but
that's
not
quite
right.
So
I
guess
that
it
was
almost
right
as
far
as
I
could
tell
the
the
other
thing
that
I
think
is
important
to
note
here
is
the
degree
of
complexity.
G
That's
involved
here
is
actually
higher
than
what
the
pull
request
suggests
because
of
exactly
the
comment
that
the
camera
makes
here.
So
it's
much
worse
even.
D
No,
no,
he
did.
I
think,
martin
just
pulled
a
fast
queueing
trick.
The
I
I
just
want
in
evaluating
this
complexity
versus
you
know.
Can
we
just
accept
failure
cases?
In
some
cases
it
might
be
useful
if
anybody
has
data
on
how
often
hrr
really
happens
in
the
wild
already,
and
I
can
imagine
that
could
be
something
somebody
would
have.
D
C
Yeah
chris
or
david,
both
in
the
queue.
B
Yeah,
so
I
I'm
not
sure
like
I
was
looking
into
this
today,
I'm
not
sure
I
can
I'm
allowed
to
give
a
precise
number,
but
I
will
say
that
cloudflare
does
see
a
small
number
like
we
do
send
hrr
in
a
small
number
of
connections.
It's
pretty
pretty
damn
small,
but
it's
enough
to
as
to
where,
like
I
wouldn't
feel
comfortable
bricking
on
a
bunch
of
edge
cases.
You
know
because
of
you
know
things
we
don't
deal
with
because
of
ech.
So
I
mean
it's.
B
C
B
B
E
I'm
unfortunately,
in
a
similar
boat,
but
like
we
it's
rare,
we
do
see
it,
but
I
think
the
point
is
the.
The
importance
is
less
like.
I
think
the
numbers
are
mostly
an
indication
like
that
it
being
there
that
it
is
rare,
is,
I
think,
mostly
an
indication
that,
like
we,
probably
got
the
design
of
this
wrong.
I
think
the
the
question
for
the
server
is
what
decisions
you
need
to
make
to
ensure
this
cannot
happen
because
it's
the
server
that's
going
to
need.
E
The
server
is
the
one
that
decides
whether
to
deploy
eck
and
if,
by
doing
so,
it
is
promising.
E
I
will
not
hrr,
then
it
needs
to
be
able
to
make
that
promise,
but
whether
it
hrrs
is
a
function
of
the
client,
not
the
server,
and
so,
unless
we
can
come
up
with
a
story
that
guarantees
that
there
is
not
going
to
be
an
hr
with
like,
like
possibly
like,
like,
for
instance,
the
hints
mechanism
might
be
a
path
towards
that,
but
that
doesn't
quite
work
because
we
need
to
like
account
for
recoveries
and
all
the
other
stuff,
and
because
I
think
if
we,
if
we,
if
we
go
down
the
route
of
like
forcing
service
to
make,
this
promise
we'll
end
up
making
it
and
the
promise
can't
be
made.
J
Yeah,
so
I
guess
I'm
still,
as
I
think
you
apparent
from
my
my
previous
yeah,
I
don't
know.
Martin
said
I
don't
think
it's
gonna
work
as
you're
preparing
for
my
previous
sort
of
going
back
and
forth.
I
think
I
think
from
like
a
conceptual
perspective
that
encrypted
encrypting
hr
is
like
attractive.
In
fact
like
I,
I
one
point
thought
that
encrypting
s8
would
be
attractive
too.
I
guess
I'd
like
to
understand
what
the
what
the
source
of
the
complexity
is
around
encrypting
hr.
J
I
think
like
the
most
I'm
getting
is
like
martin.
This
is
a
code
path.
One
is
the
copa
is
very
complicated,
but
that's
I
think
that
having
a
statement
that
would
be
clear,
I
mean
I
didn't
get
that
forms
email.
G
Yeah
this
is
a
this
is
kind
of
a
path,
complexity
problem
more
than
anything
else,
it's
the
the
analysis
here
is
probably
simpler
in
in
some
sense,
because
you
can
say
well
we're
following
this
path
or
we're
following
this
path
and
they're
discrete
separate
paths.
So
I
think
that
that's
that's
the
the
advantage
of
taking
something
like
this.
G
The
problem
that
I
have
is
that,
because
hrr
is
rare
and
the
the
problems
that
we're
talking
about
are
corner
cases,
even
then
inside
that
that
rare
case
we're
talking
about
code,
that's
not
going
to
get
tested
by
through
use.
So
that's
that's.
What
really
bothers
me
at
the
most
is
that
we're
piling
a
bunch
of
complexity
here
like
client,
hello,
generation
and
processing
is
fabulously
complex
in
in
ech,
and
I
don't
want
to
move
that
same
complexity,
to
how
I
retry
request.
J
D
J
Yeah,
so
so
so
I
so,
I
think,
as
I
attempted
to
make,
I
said,
I
pasted
the
wiki
a
link
to
like
my
attempt
to
list
the
issues,
and
maybe
I'm
like
dumb,
which
is
something
possible
or
I
haven't
enough.
Coffee
was
also
possible,
but
it
seemed
like
we
kind
of
agreed.
We
didn't
care
about
three
through
three
and
and
that
leaves
two
two
three
three
three
seven
three
and
three
five,
eight
and
like.
J
Why
aren't
all
these
addressed
by
just
having
an
ech
extension
in
the
hr
in
in
in
in
hr?
Because
it
seems
to
me
that
then
then
you
know,
then
you
can
read
that
extension
to
find
out
whether
ecstasy,
it
and
then
and
and
then,
which
is
233
and
373,
and
then
and
then
we
fix
this
this.
This
problem
with
8446
section
412,
with
with
the
interpretation
misinterpretation
in
our
opinion
of
the
of
the
ch
restrictions,
nature
restrictions.
J
Yeah
like
like,
it
seems
to
me
that
this
is
me
that,
like
that,
the
233
and
373
come
down
to
not
being
able
to
detect
whether
hr
was
in
use,
but
hr
took
the
inner
or
the
outer
right
and
an
ech
extension
an
easy,
some
kind
of
extension
in
hr
saying
which
one
it
was.
We
solved
that
problem,
given
that
we've
already
decided,
we
don't
care.
If
you
know
whether
we
don't,
we
already
decided
that
nature
that
we
hr.
J
We
don't
care
if
you
know
whether
ech
is
in
use
or
not
and
and
then
it
also
seems
to
solve
this
problem
about
exchanging
ca
jenner,
because
now
you
have
an
ech
extension,
and
so
it
is
not
allowed
to
change
so
like
again,
maybe
just
like
totally
done,
then
david's
gonna,
explain
why
I'm
wrong,
but,
like
I
just
understand
why
I'm
david
wrong
ahead.
E
You're
not
wrong
you're,
basically
describing
the
process
that
ended
up
with
this
design.
I
I
I
we
went
oh
well.
What
if
we
stick
an
extension
in
there,
then
you
go,
then
then
the
problem
is
split
mode
in
its
current
formulation
assumes
that
the
the
back
end
doesn't
really
know
what's
going
on,
and
so
we
can't
have
the
ech
extension
up
here
in
the
transcript,
which
means
there
needs
to
be
a
like
actual
hr,
inner
versus
the
thing
that
actually
gets
sent,
and
so
now
we've
invented
hr
inner.
J
E
A
good
point
I
had
not
thought
about
that
yeah.
Maybe
we
could
just
do
so
yeah.
I
guess
to
finish
my
thought:
the
333
hadn't
been
dropped
at
the
time,
and
so
we
were
like
okay.
Well,
we
need
a
cookie,
so
that's
clearly
two
of
them
and
then
from
there.
Oh
all,
right,
though
sorry
there
was
another,
so
the
other
half
of
this
is
merely
telling
the
clients
that
this
is
the
inner
client.
E
Hello
still
leaves
you
with
needing
to
know
how
to
generate
that
outer
dummy
client,
hello
that
you
know
is
going
to
be
ignored,
and
now
you
don't
even
have
a
syntactically
valid
hrr
to
speak
against,
and
I
think
that's
where
some
of
the
complexity
in
the
pr
comes
from
where
we
just
need
to
like
write
down
some
rules
to
formulate,
like
I
said,
like
we'll,
put
put
together
a
nominal
client,
hello.
J
E
Like,
like
the
the
the
seems
like
in
the
same
space
of
design
as
like
what
we
currently
wrote
down
like,
I
think
the
thing
we
wrote
down
is
probably
slightly
more
complicated
just
because
we
tried
to
solve
a
couple
of
other
issues
and
if
we
want
to
drop
some
of
those
issues
cool,
I
would
expect
that
complexity-wise
it's
about
the
same.
Oh
I'm
not
arguing
for
one
another,
I'm
trying
to
turn
the
space
okay!
No!
I
like,
I
think
I
think
you
have
like,
like
I
think
you
have
you.
C
F
On
the
participation
of
the
backend
server,
I
just
wanted
to
say
that
I
believe
that
the
the
the
back
end,
server
or
servers
in
general
can
generate
a
compatible
client,
hello,
dot,
random
unconditionally
all
the
time.
I
think
it
would
even
be
reasonable
to
make
that
just
like
the
default
behavior
in
your
in
your
ssl
server
implementation.
Although
that's
right.
F
Sorry,
the
so,
okay,
we
have
this
this
formula
for
the
backend
server
to
generate
a
tagged
server,
hello,
random,
my
apologies
and
that
in
general
is
just
a
safe
thing.
That
servers
can
always
do
so.
They
don't
need
to
be
necessarily
ech
aware
exactly.
Maybe
in
the
future,
all
tls
servers
will
generate
server.
Hello
randoms
in
this
manner.
G
B
Oh,
I
just
wanted
to
say
I
I
just
wanted
to
suggest
like
just
I
guess
I
could
have
just
plus
one
in
the
chat.
I
just
wanted
to
say
david
benjamin
suggests
that
perhaps
we
can
reduce
the
complexity
of
the
current
tr
and
maybe
that's
a
way
forward.
So
I
wanted
to
suggest
that
as
one
way
to
resolve
this
issue,
or
at
least
for
now,
like
the
the,
what
we
do
next
is
try
to
reduce
the
complexity
of
the
current
pr.
C
C
I'd
like
to
suggest
that
we
form
a
design
team
specifically
to
iron
out
hrr
and
have
a
number
of
meetings
between
the
next
interim,
where,
hopefully,
we
can
come
back
and
present
sort
of
the
conclusion
of
the
design
team
or
the
recommendations,
design
team
with
a
corresponding
pr
and
finally
resolve
this
issue.
C
H
To
the
list
I
was
just
gonna
say:
the
chairs
can
send
a
message
to
the
list.
We're
gonna,
please
try
to
be
reasonable.
The
last
time
we
did
a
design
team
we
had
like
15
people
on
it.
If
there's
you
know
what
I
mean
like:
let's
try
to
make
sure
we
have
a
concise
group,
so
it's
easier
to
schedule
and
get
things
done
and
trust
your
fellow
you
know
man
and
woman
to
get
it
right.
Thanks.
C
Yeah,
so
to
allocate
enough
time
for
the
design
team
to
work,
it
might
make
sense
to
probably
have
the
next
enter
in
a
month
from
now,
so
that
we
like
four
meetings
or
so
send
me
a
weekly
cadence,
and
then
that
should
be
enough
to
to
work
through
this.
H
Joe,
unless
you
have
anything
to
add
other
than
thank
you
for
your
time,
and
we
will
continue
to
press
forward,
you
know
thanks
for
taking
notes.
Chris.