►
From YouTube: IETF106-TLS-20191121-1000
Description
TLS meeting session at IETF106
2019/11/21 1000
https://datatracker.ietf.org/meeting/106/proceedings/
B
B
B
C
C
All
right,
so
this
we
have
like
15
minutes
for
this,
but
it
shouldn't
take
that
long.
We've
been
talking
about
this
for
a
while
importing
the
external
piece
case
for
TLS.
There
have
been
a
number
of
updates
since
the
last
draft.
In
particular,
we
used
to
have
this
weird
way
to
express
what
was
the
protocol
for
which
we
were
importing
a
PSK,
and
what
was
the
specific
hash
algorithm
that
you
wanted
to
use
to
import
that
PSK?
We
sort
of
simplified
things
and
now
the
way
you
import
and
target
particular
protocols.
C
By
saying
this
is
specifically
the
protocol
I
want
to
use
the
you
know,
the
two
byte
code
point
value,
and
then
here
is
the
specific
KBS
for
which
I
want
to
import
this
PSK.
There
was
a
new
registry
defined
in
the
document
for
identifying
these
KDF.
Currently,
it's
just
the
TLS
1.3
kts,
and
if
we
have
more
in
the
future
for
TLS,
1.12
or
whatever,
we
can
add
them
as
needed.
C
We
also
added
a
new
slot
to
the
imported
identity
struct,
which
is
this
opaque
contacts
field,
primarily
to
help
mitigate
and
deal
with
the
selfie
attack.
So
the
idea
is
that,
if
you
or
have
a
deployment
in
which
selfie
is
relevant,
fill
out
the
contents
of
this
context
field
accordingly
and
there's
guidance
and
how
to
do
that
in
an
appendix,
and
we
also
added
some
security
considerations
to
document
where,
as
previously,
they
were
just
sort
of
TBD
and
still
there's
kind
of
all
still
TBD.
C
There
are
two
outstanding
PRS
right
now,
the
first
of
which
is
a
clarification
on
the
selfie
attack.
It
rewrites
the
appendix
in
a
way,
to
help
provide
more
crisp
guidance,
in
my
opinion,
I
think
that
a
lot
of
it
can
be
simplified
by
just
stating
that
role
should
be
unique.
However,
the
author
of
the
PR
is
here
to
make
the
case.
Oh
boy,.
E
Yeah,
you
can
leave
me
for
sending
this
pool
request
and
it
may
seem
overly
complicated,
but
one
challenge
I
faced
when
I
posted
the
paper
on
the
mailing
list
is
somehow
people
thought
that
this
is
a
Mis
configuration
issue
and
not
not
really
not
really
a
problem
with
the
TLS
external
PSK.
So
maybe
was
my
poor
explanation,
but
I'll
use
another
example
and
cheers.
Please
please
let
me
have
my
minute
of
Fame.
E
So
if
Joe
and
Joe
and
I
are
chairing
another
working
group-
and
we
want
to
have
secret
chat
or
communication,
we
I
call
up
Joe.
We
exchange
a
PS
k
and
a
PS
K
identity,
and
now
he
can
open
a
connection
to
me
and
send
a
message
and
I
can
open
a
connection
to
him
and
send
a
encrypted
or
protected
message,
and
this
is
vulnerable
to
selfie
attack
and
attacker
doesn't
need
to
know
the
PS
K.
So,
depending
on
how
you
look
at
it,
some
people
say
this
is
not
group
communication.
E
E
There
is
also
your
shin,
so
selfie
attack
where
it's
possible
to
do
this
without
knowing
the
PS
K,
and
this
is
the
reason
I
had
added
that
text-
that
if
the
PS
K
is
shared
between
two
parties,
you
only
need
to
make
sure
that
that
the
identities
are
or
the
identity
of
the
the
part
is
not
the
same
as
yours.
And
if
you
share
the
PSK
across
a
whole
group,
then
you
definitely
need
some.
Some
better
information
about
the
identity.
I
also
go
to
comment
from
Martin
Thomson
that
this
requires
some
kind
of
signalling.
E
I
actually
disagree,
because
you
can't
open
a
TCP
connection
without
knowing
like
the
MAC,
address
or
IP
address
of
the
other
party.
So
you
don't
necessarily
need
need
the
signaling
to
do
that.
I'm
happy
to
make
changes
to
the
pull
request,
but
my
question
to
the
working
group
is
soon:
this
be
a
rata
on
it
for
4:6
and
like
shouldn't,
we
fix
it
once
and
for
all
in
this
draft
burn.
Do
you
want
to
comment
on
that
wrong?.
F
Yeah
the
I
said
that
then
I
think
there
may
be
a
comment
on
the
text,
not
the
design
as
much
and
I.
Think
there's
a
point
in
here.
That's
really
important,
which
is
that
understanding?
What
role
you
you're
expected
to
play
in
here
is
is
critical.
One.
The
text
in
the
appendix
preceding
this
poor
request
was
I
think
adequate
to
that
task.
F
E
C
I'm
sort
of
viewing
the
PRS
and
it
like
I,
say
an
attempted
clarification
of
the
existing
text,
so
I
don't
have
a
strong
opposition
to
it.
Personally.
I
just
want
to
make
sure
that
you
know
to
Martin's
point
we're
not
like
regressing
other
properties
in
introducing
and
trying
to.
You
know
flush
out
more
details
about
the
mitigation.
D
G
So,
like
that
seems
like
a
reasonable
line,
not
the
only
one,
every
single
design
and
I
don't
quite
understand,
like
I,
guess:
I'm,
not
understanding
what
they
said
towards
the
text.
The
prayer
is
different,
it
seems
to
be,
it
seems.
It
seems
to
be
somewhat
confusing
and
worse,
like
I,
don't
understand
what
is
recommending
each
10
points
less
one
globe.
You
identify
images
in
all.
Psk
handshakes
means
like
we're
aware
that,
if
how
is
that
enough
are
used,
I
mean
I
mean
the
the
text
here
is
like.
G
C
Current
textures
choice
yet
to
punt
that
sort
of
to
the
application,
because
that's
a
strictly
and
deployment
sort
of
problem.
So
that's
the
goal
of
the
current
text
and
whether
or
not
we
need
to
be
more
specific
in
this
particular
document
is
the
question:
I,
guess
and
I.
My
opinion
is
no,
so
bang
hey
Doc,
it
seems
to
me
like
when
we
were
doing
a
four
four
six.
We
were
thinking
a
lot
about
the
resumption
tsks
and
we
sort
of
left
external,
pious
k's
off
to
the
side,
and
we
didn't
think
about
them
too
much.
C
E
C
So
I
don't
think
we
should
remove
any
mention
of
selfie
because,
like
we
specifically
added
that
spot
to
deal
with
to
like,
but
let
this
other
draft
that
Ben
just
mentioned
possibly
exist
in.
You
know
the
details
about
how
it's
used
to
go
there
I,
don't
think
we
need
an
errata
on
a
four
for
six
to
deal
with
this
and
I'm.
Not
sure
we
can
say
much
about
like
PSK
is
not
being
sure
I
mean
applications
will
do
crazy
things
and
deployments
with
you
crazy
things.
So.
F
F
We
need
another
document,
because
an
appendix
is
definitely
not
the
place
to
start
embarking
on
something
as
complicated
and
as
nuanced
as
this
and
and
that's
I
think
where
my
objection
was
coming
from,
and
so,
if
we
can
do
this
in
and
in
another
document
and
keep
this
high-level
advice,
that
would
be.
That
would
be
fine.
F
Recognizing
the
existence
of
the
problem
is
kind
of
kind
of
important
because
of
this
assumption,
Jonathan
talked
about,
but
yeah
all
the
stuff,
with
how
we
agree
on
what
the
identifier
czar
and
how
you
construct
those
identifiers
and
how
they
might
be
might
be
exchanged
and
and
built
into
PSK,
IDs
or
not,
is
is
kind
of
complex
and
I'd,
rather
not
do
that
yet.
Yeah.
I
So
so
what
I'm
hoping
to
do?
What
I'm
kind
of
hearing
is
that,
like
we
know,
we
have
this
problem
and
we
need
to
identify
and
write
it
somewhere.
So
we
need
to
mention
selfie
here,
so
we
have
text
already.
So
what
I'm
hearing
is
this
PR
gets
rejected?
We
start
another
draft,
possibly
led
by
a
design
team
to
delve
more
into
this,
but
that
basically
means
when
you
reject
this.
We
push
this
draft
forward
like
immediately.
No
does
that.
Does
that
basically
sound
like
a
plan?
G
G
Gonna
get
this
for
a
little
bit
now
and
I
think
it's
probably
for
tonight
in
between
several
things,
which
I
think
are
not
well
just
not
having
been
that
well
fleshed
out
this
discussion.
So
first
of
all,
on
Sophie
is
an
active
network
attack
bicep
idol.
If
your
attacker
doesn't
none
of
the
endpoints
right
and
so
on,
and
so
it
has
two
modes.
G
G
You
have
a
client
server
that
you,
you
only
use
one
Kishore
as
a
client
one
case,
your
server,
the
one
client
server
role
on
the
as
a
separate
class
of
attacks,
which
are
about
rerouting
between
rerouting
between
multiple
clients
of
server
pairs
and
yet
a
sort
of
and
and
then
and
the
typical
way
to
solve
this
problem.
This
is
the
Canada
have
identifiers
in
the
protocol,
as
opposed
to
as
opposed
to
diversify,
key
the
key
material
and
and
now
so
finally,
to
get
to
the
point
of
the
text
here.
G
In
fact,
the
trivial
role
of
agent
and
shake
as
I
say
is.
This,
like
you
know,
is,
is
for
the
two
party
cases,
just
it's
just
like
that.
Reflection
comparison
and
the
end
party
case
actually
is
like
put
something
if
I
was
mistaken,
handshake
and
don't
treat
the
PS
Cayden
if
I
were
to
humor
than
if
I
as.
I
Like
we're
gonna
I
think
we've
come
did
a
conclusion
right.
Basically,
unless
somebody's
going
to
get
up
and
radically
screen
is
that
we
are
gonna,
reject
this
PR,
then
I'll
kick
out
the
processing
River
before
it
will
form
a
design
team
to
get
some.
You
know
some
additional
information
up
about
self.
You
know
how
to
deal
with
it
that
well.
E
I
won't
lose
sleep
over
rejecting
this
PR.
That's
fine
if
there
seems
to
be
consensus
for
that,
maybe
my
only
quibble
was
if
we
are
going
to
add
identities
to
they
say
into
to
importing
external
peers
case.
At
least
the
text
could
still
give
some
guidelines
on
how
to
mitigate
cell
C.
So
the
previous
text,
in
my
opinion,
was
not
saying
that
the
other
identity,
the
identity
or
the
other
party
should
be
different
from
any
of
your
own
and
and
perhaps
at
least
it
could
do
that.
D
C
C
So
there's
actually
one
other
outstanding
pull
requests
and
Jonathan.
You
might
not
want
to
sit
down
because
it's
just
your
poll
request.
So
basically
the
idea
is
in
addition
to
or
the
proposal
is
in
addition
to
you
importing
an
external
PC
and
doing
the
key
deprivation
based
on
the
protocol
and
the
KDF.
C
D
So
I
I
think
it's
needed,
is
it
I
think
it
need?
Is
a
general
thing,
I'm,
not
sure
it
should
happen
here.
My
presentation
later
also
has
this
change
and
I
I.
Think
if
it's
better
in
the
other
document
than
here
so
so
we
should
still
use
when
the
labels,
but
where
those
binder
labels
are
defined,
I
think
should
move.
K
G
Let's
sort
that
problem
that
separately,
that's
document
engineering,
not
protocol
engineering,
so
I
mean
well
now
we
have
a
video
document.
Yes
it
they
have
to
be
here
right.
So
I
read
oblique
included
that
we
have
to
do
this.
It
makes
me
sad,
a
sad
panda,
but,
like
we
just
like
had
too
many
problems
with
people
with
complicated
attacks
where
people
would
you
know,
we
would
take
a
take
the
drive
key
and
then
stuff
it
in
in
some
separate
slot.
G
Separate,
like
I
mean
the
way
they
this
like,
like
we've
introduced
another
rung
in
the
ladder
right,
we're
you
know,
here's
where
the
keys
went
in
and
now
we're
have
a
thing,
and
we
put
them
in
here
and
I.
Don't
want
somebody
going
in
here,
which
is
what
this
prevents
so
we're,
Greta,
bleah
I
think
we've
made
this
change
great.
G
L
C
K
C
D
C
C
F
Quick
yeah
I,
you
were
just
summarizing.
I
realized
in
this
discussion
that
I
wasn't
sure
about
something
in
the
document.
I
just
went
back
and
checked.
You
say
in
here
that
you
there
are
no
changes
on
the
wire
in
the
protocol,
except
for
expanding
the
set
of
identifies
that
appear
on
the
wire
yeah
and
that's.
F
It's
a
very
important
statement
to
make,
but
I
also
realize
that
you
don't
really
capitalize
on
you,
don't
really
expand
on
what
it
means
to
expand
the
set
of
identifies
and
I'm
wondering
whether
or
not
there's
a
formal
structure
of
those
identifiers
employed
by
the
document
or
whether
there's
an
expectation
that
people
work
out
what
those
identifiers
are,
because
it's
not
very
explicit
in
here
so
I
just
like
to
raise
one
more
issue
and
on
the
structure
of
the
imported
identifies.
Yes,
that
I'm,
not
here,
say
identified
that
you
use
one
on
the
wire
I.
F
C
A
A
N
Cut-And-Paste
I'll
fix
that
so
we're
on
the
back
nine
for
TLS
expert,
Authenticator
sis,
but
we're
gonna
have
a
bug
on
both,
so
this
has
gone
through
last
call
and
it's
gone
through
reviews,
and
essentially
there
is
one
last
point
that
needs
to
be
addressed.
This
is
right
raised
by
your
own
Scheffer
and
it
comes
down
to
the
specific
line
right
here.
As
a
reminder,
TLS
exported
authenticators
is
a
way
to
export
a
a
piece
of
data
that
corresponds
to
essentially
a
certificate
request
and
then
a
certificate.
N
N
One
of
the
use
cases
here
for
export
authenticators
is
for
client
initiated
server
authentication.
So
this
is
a
use
case.
That's
not
present
in
TLS,
so
it's
you
can
think
of
it
as
the
server
has
already.
If
you've
already
made
a
connection,
the
server's
already
authenticated
for
one
certificate
and
you
wanted
to
authenticate
for
a
second
certificate,
and
so
the
mechanism
for
doing
that
exported
authenticators
is
to
create
an
Authenticator
request
on
the
client
and
then
a
which
mirrors
what
would
be
in
the
certificate
request
in
in
TLS.
N
And
then
the
server
responds
with
an
export
Authenticator,
which
contains
the
certificate
certificate,
verify
and
finish
message,
because
in
TLS
this
is
something
that's
almost
all
with
that
is
always
initiated
by
the
server.
The
set
of
extensions
that
fit
into
the
certificate
request
is
determined
by
the
list
in
Ayana,
so.
N
Mcclee,
something
like
SNI
is
only
a
client
extension
where
it's
not
it's
not
a
server
extension,
and
so
this
use
case
implies
that
you
have
an
extension
in
certificate
request.
That's
not
allowed
according
to
TLS
1.3,
so
the
suggestions
were
to
change
the
document
to
update
RFC
84
46,
which
seems
like
a
pretty
heavyweight
change
for
this
document
that
actually
does
not
update
this
RFC
significantly.
N
The
other
suggestion
is
to
kind
of
spin
out
a
new
extension
point
for
s
and
I.
Well,
that
is
basically
an
extension
point
that
says
this
is
an
S
ni,
but
it's
in
a
certificate
request,
not
an
S
ni
that
sits
in
the
client,
hello
that
that
seems
like
it
also
might
be
a
bit
of
an
anti-pattern
there
you
might
have
to
if
there's
any
other
extension,
that's
going
to
fit
into
this,
and
you
have
to
spin
out
a
duplicate
mean,
meaning
folks,
extension
sni
is
exists
in
client,
hello.
I
F
Right,
good
I
think
this
is
the
right
approach.
One
of
the
things
we
did
in
tail
s13
was
start
to
pull
apart
the
various
extensions
and
the
and
there,
but
we
never
really
did
that
for
client,
hello,
and
there
are
multiple
different
types
of
extensions
that
that
exist
in
client
helotes.
We
have
the
ones
that
change
the
shape
of
the
protocol.
We
have
the
ones
that
are
the
govern
key
exchange.
We
have
the
ones
that
are
used
in
selecting
certificates
and
some
of
them
are
overlapping
and
they
fill
multiple
roles.
F
I
think
this
is
the
simplest
way
to
manage
this
by
simply
saying
that
yeah.
This
is
the
client
asking
for
a
certificate.
That's
exactly
what
it
does
with
a
lot
of
the
extensions
in
the
client
below
there
are
some
in
here
that
won't
make
any
sense
key
share,
for
instance,
but
you
just
ignore
them
as
once.
It's
fine.
O
N
I
think
the
text
that
I
proposed
does
not
say
treated
like
a
client.
Hello,
just
allow
client,
hello,
enabled
extensions,
so
it
wouldn't
have
the
mandatory
requirement
it
wouldn't
be
at
mine.
Hello
would
be
a
certificate
request.
Looking
structure
then
allows
specifically
one
client,
hello
extension,
which
is
sni
and
so.
D
G
Yeah
I'm
not
not
sure
what
I
do
like,
but
I,
don't
like
see,
I'm
concerned
of
the
same
thing
Ben
Schwartz
just
raised.
It
just
seems
like
really
like
what
the
heck
does
that,
what
the
heck
does
like
Keisha
I
mean
here
and
I,
don't
want
to
ignore
and
I
want
to
like
I
want
to
follow
draft
IEP.
You
know:
what's
it
called
now,
the
stuff
was
wrong,
you
know,
and
and
and
reject
it.
G
N
N
Okay,
this
is
also
not
CFR.
Gene
whoops,
alright
delegated
credentials.
This
is
another
one
that
is
been
moving
along
pretty
nicely,
particularly.
We
have
an
update
here
of
running
code.
There's
some
public
announcements
of
support
for
the
draft
version
of
this
protocol
in
Firefox
nightly,
as
well
as
CloudFlare
and
Facebook
has
done
been
doing
they
they
have
an
endpoint
that
supports
it
and
have
talked
about
supporting
it
more
thoroughly
in
their
in
their
infrastructure.
N
N
One
of
the
one
of
the
issues
in
TLS
1.3
that
came
up
was
this
idea
of
having
supported
algorithms
and
supported
algorithms
certificate
as
to
lists
of
supported
algorithms,
one
for
which
spki
is
allowed
in
the
leaf
certificate,
verses
which
spki
is
allowed
to
be
used
in
the
certificate
chain
for
signing
the
leaf
certificate
and
because
the
peak
a
stack
is
sometimes
different
from
the
TLS
stack.
These
two
things
are
potentially
just
disjoint
lists
or
different
lists
in
kind
of
polling.
N
N
Extension
spki
to
sign
the
sun
handshake,
so
there's
potential
for
a
mismatch
here.
If
your
TLS
stack
supports
an
spki,
but
your
PKI
stack
does
not
support
that
spki
in
assert.
So
the
the
specific
use
case
here
is
say
you
advertise
support
for
an
IDI
to
55.9
signature
scheme
as
a
supported,
algorithm
and
delegated
credentials,
and
you
support
at
255
or
ninth
Ella
gated
credentials.
N
But
your
PKI
stack
does
not
support
extracting
the
IDI
five
nine
spki
from
the
leaf
cert
then
you'd
be
in
the
situation
where
the
server
supports
this
type
of
key
and
doesn't
support
delegated
credentials
that
could
send
down
a
cert
that
supports
this
key
type
and
your
stack
isn't
not
able
to
effectively
communicate
that
distinction
to
the
server.
So
this
this
is
not
necessarily
a
problem
in
in
some
of
the
stacks
that
we've
seen.
N
F
F
We
have
multiple
pieces
of
the
stack
and
multiple
pieces
of
the
policy
enforcement
infrastructure
that
all
have
to
support
this
thing
before
we
can
turn
it
on,
and
it
turns
out
that
it's
okay
for
us
at
the
point
that
we
can
turn
on
PSS
generally
we'll
be
able
to
use
it
here,
but
I
can
see
how
others
might
be
affected
by
this
I'm.
Okay,
with
this
I
think
that
having
a
very
small,
controllable
set
of
signature
schemes
for
delegated
credentials
is
a
nice
feature.
I
don't
think
it's
absolutely
essential,
but
I
can
I.
N
G
P
G
You
see
you're
privileged
to
put
field
in
the
DC
extension
that
is
like
here.
They'll
remove
the
support.
That's
right,
just
a
list,
yeah
I
guess
I
like
how
you
have
the
with
it
here,
because
I
guess
I
can
live
with
that.
If
I
can
also
live
with
not
having
it
I
think
you
know,
yeah
I,
think
I
guess
this
is
like
one
of
these.
Like
beauty
contest
things,
so
I
guess
is
there.
Is
there
anybody
feel
strongly
on
one
side
of
there?
K
O
Kyle
nekritz
I
agree,
there's
a
use
kiss
for
this,
but
I
guess
my
question
is:
is
anyone
going
to
actually
use
this
I,
don't
think
we
would
use
this
like
advertise
a
different
algorithm
or
advertise
a
different
set
of
algorithms.
So
as
online
you
mean
or
as
a
server
is,
this
is
that
this
is
advertising
as
a
client
somewhere.
N
Yeah
I
think
this.
The
the
reason
that
this
will
come
into
play
is
in
moving
forward
with
new
algorithm
types.
It
likely
gives
us
more
flexibility
with
adding
new
things
like,
for
example,
on
the
semi
static,
th
side.
We
might
be
able
to
advertise
in
this
without
necessarily
supporting
semi
static,
th
and
the
leaf
cert
yeah.
F
Not
in
Thomson
I
was
just
about
to
get
up
and
say,
let's
not
add
something
that
when
we
don't
have
a
good,
clear
use
case
for,
but
that's
a
good
reason
to
do
this,
we're
having
a.
We
have
a
little
bit
of
trouble
getting
all
of
the
different
pieces
in
place
when
it
comes
to
our
certificate,
validation,
infrastructure
and
being
able
to
say,
do
a
PQ
algorithm.
F
K
I
would
like
to
comment
on
on
a
separate
issue
which
is
okay
can
I
do
that
yeah
is
this
from
so
the
maximum
lifetime
of
the
delegated
credential
appears
to
me
pick
pretty
randomly
and
seven
days
so
I
wonder
what
is
that's
really
good
idea
in
in
use.
Cases
that
we
are
looking
into
seven
days
seems
a
little
short
and
I
was
wondering
whether
you
can
sort
of
motivate
someone
in
the
seven
days
or
why
I
would
want
to
do
that
rather
than
five
days
or
10
days.
K
N
F
F
Endpoints
should
set
a
policy
of
seven
days
maximum,
but
that
would
leave
it
otherwise
unspecified
so
that
those
deployments
that
want
to
do
things
like
I,
don't
know
putting
a
certificate
on
a
camel.
That's
gonna
then
go
across
the
desert
and
then
have
to
be
valid
at
the
other
end
of
it
and
I.
Don't.
N
K
So
yeah
I
can't
talk
entirely
about
the
use
case,
but
it's
originated
in
the
IOT
space,
where
some
of
the
devices
are
not
always
connected
and
so
having
them
sort
of
the
connect
to
just
to
get
that
delegated
credential.
Just
for
the
sake
of
fulfilling
that
Cerf
requirement
appear
to
be
a
little
tricky,
given
that
today,
there
OCS
B
is
not
even
used
at
all,
let
alone
a
certificate
revocation,
which
is
more
used
in
a
in
a
sort
of
like
firmware,
update
a
sort
of
scenario.
We
can
argue
better.
K
That's
a
good
approach
or
not,
but
I
think
using
that
work.
This
this
recent
work
there
in
those
environments
would
improve
security
overall,
so
I
think
Martin's
approach
of
tying
it
or
augmenting
it
in
to
the
specific
context
and
I
I
the
web
context
in
a
bad
context.
That
makes
total
sense
to
me.
Okay,
so
you
understand
the.
K
I
F
F
O
G
And
then
you
like
screwed,
so
I
mean
in
what
you
want
is
like
thee
and
so
either
we
have
to
have
like
a
rule
written
down
or
if
the
signal
light
and
suddenly
it
seems
like,
are
right
on
the
I
guess.
What
I
would
suggest
is
that
when
we
get
to
the
point
where
those
an
aggressive
use
case,
it
needs
a
longer
value
like
we
can
there's
a
way
to
signal.
A
death.
Nice
I've
Hannes
is
saying,
like
I,
have
a
use
case
right
now.
Our
new
super
long
value
like
they
may.
K
Yeah
I
was
I
was
one
I'm,
specifically
also
in
a
TLS
specification.
We
have
some
some
wording
specific
for
the
algorithm
Sunda
mandatory
to
implement
algorithm
absent
a
specific
profile.
We,
those
are
the
mandatory
to
implement,
algorithm
and
and
I,
could
imagine
in,
in
this
case
its
symbol,
a
similar
absent
to
a
specific
profile.
The
default
is
seven
days
and
yeah.
N
I
I
G
A
K
A
D
Hi
everyone,
okay,
so
I
want
to
talk
about
TLS,
extended
petite
schedule.
So
why
would
you
want
to
extend
the
key
schedule?
Tls
has
some
like
really
nice
properties,
but
maybe
we
want
more,
better,
more
exciting
properties.
Fine,
for
example,
we
might
want
some
privacy
properties
for
the
client,
hello.
We
might
want
to
do
some
sort
of
hybrid
key
exchange
where
we
use
quantum
safe
keys
as
well
as
classical
keys,
and
the
question
is:
can
we
achieve
these
new
different
properties
without
breaking
anything?
D
So
so
I
was
motivated
to
do
this
because
there
are
a
bunch
of
drafts
that
are
like.
We
want
to
change
how
the
key
schedule
works,
and
we
want
to
do
this
or
we
want
to
do
that
so
for
obvious
examples,
hybrid
key
exchange.
If
you
want
to
be
able
to
use
a
quantum
safe,
key
exchange
simultaneously
with
TLS
without
having
to
allocate
new
code
points,
you
could
just
define
yourself
hybrid
key
exchange
draft,
and
this
would
that
you
include
these
keys
and
injecting
key
schedule
with
having
to
worry
about
all.
D
D
D
All
the
drafts
are
just
mentioned,
modify
the
key
schedule
in
neutrally
incompatible
ways,
and
they
generally
haven't
had
huge
amounts
of
security
analysis
and
they
definitely
haven't
had
security
analysis
of
when
you
what
happens
when
you
use
them
with
other
key
schedule,
modifications-
and
there
is
lots
of
dragons
there.
So
this
draft
attempts
to
do
two
things
capture
all
of
the
work
already
done
with
key
schedule,
changes
and
providing
a
framework
that
lets
us
use.
All
of
these
key
schedule
changes
in
a
consistent,
secure
and
composable,
most
importantly,
composable
way.
D
So
this
is
a
TRS
key
schedule,
truncated
at
master
secret
and
we're
proposing
to
inject
at
two
and
perhaps
three
points
we
want
to
modify
the
way
PS
k's
are
are
used
such
that
we
can
do
fancy
things
and
we
want
to
inject
an
extra
secret
before
the
diffie-hellman
Karthik
suggested
that
we
could
also
inject
just
before
master
secret.
But
you
know
that's
for
discussion,
so
the
zeros
are
actually
non-trivial
the
to
zero
aren't
the
same,
even
though
they
look
the
same.
The
top
zero
is
a
salt
and
actually
just
says.
G
No,
maybe
ignore
the
top
oh
yeah,
and
the
bottom
is
their
bottom.
Zero,
like
everywhere
else
in
this
key
schedule,
but
then
it
comes
on
the
left
is
this
is
isn't,
is
the
is
the
is
the
one
IP
k
right,
the
initial
random
ikm
and
the
thing
that
comes
the
top
is
a
salt
right
so
like
and
if
you
just
like
scroll
up
like
1
HK
DF
craft
above,
do
your
extract?
Has
a
DHE
secret,
as
I'm
saying
like
when
you
want
to
when
you
want
to
do
like
I.
G
D
D
F
M
D
It
should
probably
be
a
channel
binding
if
you're
doing
anything
complicated
but
leave
I
sort
of
leave
that
implementers,
if
you're,
going
to
design
complicated
to
sound,
complicated
okay.
So
what
is
this
change?
Give
us
and
you
combined
extra
information
into
the
handshake,
so
I
can
bind
non
secret
information
to
the
handshake,
and
this
is
analogous
to
the
TLS,
export
or
interface,
so
in
the
same
way
that
I
can
layer
something
on
top
of
TLS.
D
This
lets
me
layer
two,
he
LS
on
top
of
something
else
and
that's
where
you
would
effectively
end
up
with
channel
bindings
and
this
sort
of
just
harmonizes
the
sort
of
structure
that
we
should
have
done
in
the
first
place
and
if
we
I
don't
think
it
affects
the
security
proofs
and
we
shouldn't
have
to
do
anything.
Fancy
well.
G
I'm
not
gonna
feature
trolling
there
about
what
was
your
in
the
first
place,
but
I
just
want
to
have
a
question
so
one
might
the
this
at
least
one
more
reason
about
as
injecting
into
the
transcript,
instead
of
injecting
into
the
key
schedule
right,
mm-hmm,
okay,
just
running
sorry,
like
I
mean,
if
we
like
had
if
like,
if,
like
every
message,
had
light
like
if
every
message
had
like
a
extra
like
a
like
a
notional
like
here's
extra
crap
like
it
could
hold
in
the
transcript.
That
would
be
the
same
as
this
right.
G
D
D
F
Q
Daniel
kind,
Gilmore,
I,
don't
think
this
is
exactly
the
same
as
putting
stuff
into
the
transcript
where
that
car
said
earlier,
in
particular
a
few
stuff
arbitrary
stuff
to
the
transcript.
It
might
look
the
same
as
stuff
that
is
already
that
might
already
have
been
in
the
transcript,
and
this
case
is.
D
Additive,
yes,
so
this
is
that's
why
you
have
to
use
a
different
point:
a
label.
If
you
look
on
the
bottom
right,
there's
impact
minder
and
in
res
binder,
basically,
if
you're
doing
an
extent,
an
out-of-band
PSK
using
impact
pointer
as
your
label,
we
might
need
to
shorten
that.
And
basically
that
says
you
can't
confuse
and
also
fan
PSK
using
this
and
that's
been
key.
Not
using
this.
Oh
yeah.
G
I'm
sorry,
my
my
hypo
was
it
we
like
injecting
my
favor
was
like.
We
don't
like
a
faked
handshake
message
that
was
like
additional
crap
in
the
hint
in
the
in
transcript,
don't
put
it
in
there
and
that
bad
I
think
will
have
the
same
properties
as
this
in
my
head
and
if
it
doesn't
that
I
want
to
reason
about
like
the
same
way
we
did
with
the
with
with
the
reinjection
for
ch1,
like
I
hope,
so
because
otherwise,
I'm
not
reason
about
this
correctly.
G
D
D
The
second
piece
is
here:
you
have
a
an
extra
drive
secret
and
an
extra
HK
D
F
extract,
which
is
an
extra
expand
extract,
and
the
idea
is
that
this
will
isolate
the
injected
material
from
the
rest
of
the
handshake
and
in
the
inputs
are
injected
in
a
fixed
order.
We'll
have
an
eye
on
a
registry
that
says
you
know
this
goes
first.
This
goes
second,
this
goes
third
okay.
D
So
what
does
this
give
us?
It's
not
the
same.
It
gives
us
to
add
new
secrets
to
the
handshake.
Before
we
could
only
add,
we
could
only
commit
to
new
public
values
in
the
handshake,
so
we
for
doing
cryptic
line
hello
extensions
or
we
can
add
quantum
safe
secrets
without
giving
up
any
classical
crypto.
D
D
If
we
do
really
care,
we
can
use
this
design,
so
this
basically
just
uses
the
dual
PRF
property
of
HK
DFS
and
we
inject.
This
is
copied
from
drafts
tabular
and
labels
combining
ATF
one
and
basically,
we
extract
from
the
EC
DHE
and
the
well.
In
this
case,
we
next-gen
would
be
post
B,
quantum
safe,
but
we'd
replace
that
with
just
anything
downsides
to
this.
F
And
I
would
also
propose
neither
of
the
two
options
you've
presented
on
the
screen:
okay,
so
yeah
I'm,
perfectly
comfortable
with
taking
all
of
the
inputs
that
we
have
at
a
given
point
in
the
key
schedule
and
then
combining
them
in
some
fashion.
I,
don't
think
we
need
H
KDF
extract
for
that.
We
we
just
need
a
mapping
that
is
clear
and.
G
F
Directive,
you
do
just
concatenate
them
in
in
a
simple
case,
because
of
that
most
of
these
things
are
fixed
length,
but
if
they're
not
fixed
length,
we
put
length
prefixes
on
and
but
everything's
gravy.
The
reason
that
I
say
that
is
that
we
have
in
most
implementations
all
the
necessary
machinery
in
order
to
switch
out
the
thing
that
appears
on
that
left-hand
side.
F
G
G
That's
a
curry
yeah
so
like
attack,
so
it's
like
it's
like
I
think
they
like.
If
you
sort
of
scroll
back
and
Inter
like
acceptor
trolling
previously,
we
should
have
done
right.
You
know
the
the
annoying
thing
about
the
current.
A
loss
and
shouldn't
tell
askew
schedule
is
that
we
basically
only
allow
one
secret
each
of
those
insert
points
right
and
so
like
when
you're
trying
to
send
that
you're
like
well.
G
This
one
says
now
we
have
to
and
it
has
the
same
annoying
problem,
and
so
does
it
invokes,
is
like
the
same
annoying
problem
as
well.
There's
only
us
two,
and
so,
like
the
you
know,
the
original
sin
here
is
like
our
failure
to
like
allow
an
arbitrary
number
of
key
values,
ation
certain
points
and
so
on,
and
so
whatever
we
do.
Is
you
fix
that?
G
If
we
think
it's
good,
we
should
fix
that
and
so
like
either
we
should
do
it
by
being,
like
you
know,
like
so
users,
do
it
by
being
like
you
can
have
it
over
terminal
things.
You
just
expect
justice
justice
tracked,
that's
one
possibility
and
the
other
is
you
have
a
combiner
and
then
you
glue
them
in
I.
Think
the
combiner
and
glue
them
in
like
obviously
makes
more
sense.
I'm
willing
to
like
you
know,
I'd,
be
a
caveman.
G
D
P
D
P
G
P
G
G
If
you
have
one
you
just
you
just
shove
it
in
and
and
then
and
then,
and
then,
like
very
simple
and
like
and
in
fact,
Martin's
things
nice,
because
Martin's
thing
like
actually
couldn't
find
it
in
coding,
which
is
exactly
this
property.
It's
just
a
serialization.
Now
her
forceplate
do
and
actually
this
XOR
by
the
way,
if
we're
forced
to
do
some
sort
of
like
nonsense
with
like
multiple
HK
TF
stages,
that
won't
work
but
yeah.
G
I
K
We
are
making
it
incremental
e,
more
complicated
and
I
would
wish
that
someone
actually
looks
at
how
to
simplify
the
proofs
or
to
tailor
it
proves
a
little
bit
so
that
we
don't
have
to
make
is
more
and
more
complicated,
because
if
you
look
at
the
code
and
that
we
have
today
in
1.3
it's
it's,
this
part
is
actually
one
area
where
it
where
you
have
way
more
cryptographic
operations
that
you
need
to
do
way
more
code,
and
that
also
is,
has
its
there's
side
effects
of
that
right.
Yeah.
K
D
P
P
R
I
G
S
G
Yes,
okay,
so
this
is
some
work
done
by
me:
Richard
Barnes
and
Hannes,
the
yes
see,
I,
guess
I
guess
I
felt
like
if
I
thought,
I
didn't
ever
actually
name.
What
it
is
see
is
compact
by
the
way,
that's
why
the
C
is
lowercase,
so,
okay,
what
problems
were
trying
to
solve.
So,
despite,
like
the
you
know,
with
the
fact
that
everyone's,
like
really
thrilled
with
how
one
three
turned
out
jonathan,
especially
the
you
know,
things
are
not
perfect.
G
There's
still
someone
annoying
like
a
legacy
craft,
the
TLS
handshake,
especially
in
like
the
like
the
client
hellos,
if
it
feels
like
a
wave
of
legacy,
can't
be
changed.
Those
are
awesome
now,
like,
unfortunately
like
in
many
con
has
like
stuck
with
that
because,
like
welcome
to
the
web
and
like
you,
can
never
send
anything
different
ever
ever
ever
but,
like
maybe
I,
saw
something
had
a
little
bit
forever.
It's
like
like,
particularly
like
we
did
quick.
It
was
kind
of
still
later
like
we
have
these
quick
messages
that
contain
like
like
a
legacy.
G
He,
like
version
numbers
that
nobody
uses
on.
Second,
even
from
the
beginning
of
one
three,
there
was
sadness
about
the
sort
of
rich
feature
set,
and
that
has
a
number
of
problems.
Sometimes
one
is
it
made
it
hard
to
do
like,
say:
I,
don't
want
zero
duty
and
I
made
only
and
I
like
like?
How
do
you
define
like
what
the
minimal
feature
set
that,
like
maybe
ease
your
implement,
is
and
maybe
there's
a
reason
about
is
so,
and
second
obviously
makes
the
it
makes
the
constraint
up.
G
It
makes
the
partition
size
bigger
and
the
joints
that
you
need
to
make
work
also
make
the
make
the
call
the
wire
bigger
so
like,
in
particular
like
if
you
only
have
a
phone
key
share
like.
Why
do
you
have
like
a
bunch
extra
values
telling
you
how
many
he
shares
you
could
have
and
if
you
only
for
one
key
share
like
why
he
needs
it?
Why
thrr,
and
if
only
for
one
key
share
like
why
do
you
need
some
way
to
like
say
these
are
the
these?
G
Are
the
name
groups
that
support
because
it's
got
all
the
same,
stinking
thing
and
so
finally,
the
you
know
there's
there
is
a
separation
in
one
three
between
a
handshake
and
the
record
layer,
but
it's
not
like
quite
as
clean
as
you
might
have
hoped,
oops
and,
and
so
like,
and
you
see
that,
like
it
looks
fine,
we
did
one
three,
but
then
we
tried
to
do
quick.
It
was
like
obvious
that,
like
maybe
that
was
not
like
quite
as
clean
a
set
of
cuts
as
you
wanted
I'm.
G
So
quick
is
really
like
t
lost
one
point
three
like
handshake
with
a
quick
record
layer,
and
that,
like
you,
know
like
that
works,
but,
like
you
know,
it's
like
like
the
document
is
like
take
these
ports
or
to
your
lesson
like
throw
away
these
little
parts
to
0s
and
so
try
to
cut
that
out
would
be
it
would
be.
Nice
there's
also
an
issue
if
you
look
at
like
lake
and
when
you
might
think
I'm.
Oh
s
course
your
record
layer.
G
G
So
there's
a
bunch
of
motivating
use
cases
for
this
work.
Ij's
one
is
quick
other
than
I
was
indicating.
Another
is
a
TLS
is.
Is
that
what
you
call
it
as
a
TLS
set?
Okay,
the
Google
thing
has
some
other
name
like
alts
or
something
there's
a
lake
for
the
screen,
key
for
hand,
constrain
sizes
and
there's
eat
as
well.
We're
also
has
been
issued
to
have
like
a
message
sizes
and
anytime.
G
You
try
to
map,
there's
also
kind
of
an
issue
for
DTLS
I'm,
not
as
not
as
much
but
kind
of
one,
so
so
say
that
there's
a
but
and
and
again
in
a
TLS,
you
might
think
about.
Maybe
you
don't
need
the
record
layer,
for
instance,
on
and
like
the
same
way,
so
there's
like
two-and-a-half
technical
pieces
here
which
we
might
adopt
somewhere
all
off
or
none
of
for
that
matter.
G
So
one
is
some,
don't
clean
up
on
the
handshake
messages
to
make
them
like
less
like
kind
of
gross
and
crafty
I'll
talk
about
each
of
these
in
detail.
The
second
is
this
kind
of
like
vaguely
advanced
specialization
mechanism
for
describing
substance.
The
TLS
like
in
a
way
that
isn't
just
writing
new
document
profiles
and,
finally
or
more
clearly
delineate
the
handshake
in
the
records
record
cutscene.
So
it's
no.
G
G
That
tells
you
how
big
the
integer
is.
That's,
like
really
amazingly
awesome
on.
You
know,
I
feel
right.
If
you
like
this,
if
you
just
didn't
see
you
like
how
like
decode
you
int
X
and
like
there's
a
field,
this
is
a
big.
It
is,
if
you
do
in
C++
you,
like
start
thinking,
function
overloading
and,
like
my
time,
fly,
specialization
and
like
that
does
work,
except
that
then
I
said
then
there's
no
there's!
No!
You
ain't
24,
and
so
things
don't
work
out
so
well
uh-huh.
So
it's
like
not
great!
G
So
like
replace,
every
integer
with
a
variant
is
like
actually
makes
life
substantially
easier.
It
also
means
they,
like
you,
don't
have
these
goofy
situations
or
you're
not
trying
to
decide
like
like
I
I,
can't
tell
you
how
many
arguments
I've
been
we're
arguing
about,
like
should,
like
the
maximum
length
of
this
field
being
code,
be
65,000,
Val,
65,000,
like
objects
or
up
bytes
or
like
255
bytes.
So
like,
let
me
solve
this
go
away
which,
like
is
it
your
crease,
is
loaded
on
us
on
so
removing
some
unnecessary
legacy.
G
Fields
like
as
I
say
these
like
these
like
veiled
fields,
which
I
only
exist
to
make
1/3
look
like
1/2
hum
session.
I
need
a
good
example
of
that.
Also
Richard
Barnes
suggested
removing
the
handshake
message
length
from
the
handshake
framing
on
and
just
saying,
look
the
handshake
messages
like
are
self
describing
in
terms
of
lengths.
There's
nobody
get
confused.
This
is
actually
quite
a
point
of
confusion.
Your
implementations
were
like
you
have,
like.
You
know,
think
about
that
on.
So
one
difficulty
here
is
backward
compatibility.
G
Obviously,
you
can't,
like
you,
wouldn't
be
able
to
emit
a
client
hello
like
according
to
these
rules,
it
was
possible
by
like
but
person
why
existing
implementation,
so
so
I
think
we
probably
have
to
do
realistically.
Is
you
would
do
this,
but
then
you'd
say
like
hey,
you
know
you
also
have
to
be
like.
If
you
don't
know
what
the
server
does
you
have
to
be
able,
if
it
won't
quite
hello
as
well
and
receive
it
the
server
hello,
I'm
sure
we
can
find
some
way
to
make
it
obvious.
G
So
they'll
only
change
the
first
message,
so
this
is
like
semantically
identical
right.
This
is
just
like
what
you
thought
you
might
have
thought
of,
if,
like
you
like,
had
a
different
kind
of
online
philosophy,
went
where
necessary.
3
was
designed
by
25
years
ago,
I'm
exact,
we're
just
inheriting
the
structures
from
V
3
right
on
this
would
be
like
a
non-trivial
simplification,
at
least
in
my
implementation.
I
suspect
that
others
next
slide
now
on
the
next
slide.
G
G
That's
good
in
the
sense
like
you
get
a
very
powerful
object
and
you
have
a
powerful
object
and
particularly,
we
have
like
an
analysis
of
entire
thing,
and
so
we
can
tell
you,
like
you
know,
when
the
opportunity
to
tell
you
this
is
like
this
whole
secure
profile,
she'll,
us
and
but
like
with
that
said,
maybe
you
don't
want
all
that
stuff
and
so
on,
and
it's
like.
Why
are
you
paying
for
that
book
from
the
wire
and
the
implementation?
G
And
so
the
idea
we
had
actually
do
to
karthik
Bhargav
on
is
to
I'm
your
sole
term
from
rust,
run
or
vice.
So
you
have
a
on.
You
have
like
a
Jarek
system
which
is
polymorphic
and
what
you
do
is
you
Mon
Amour
physis,
so
you
take
a
given
axis
of
flexibility,
say
the
version
number
and
you
say
well
in
principle
like
the
system
supported
like
1.3,
1.4
1.2,
but
we're
gonna
model
mortifies
it
down
to
1.1
and
so
all
1.3,
and
so
all
the
code.
G
You
need
like
process
versions,
negotiations
just
go
away
and
all
the
wire
machine
where
you
need
to
negotiate
goes
away,
and
so
you
can-
and
the
idea
here
is-
you
can
like
independently
montemor
flies
in
every
axis
and
then
and
here's
the
cool
part,
the
karthik
suggested,
which
is
you
reconstruct
the
transcript
as
if
you
had
not
montemor
as
if
you
had
not
specialized,
and
so
you
get
the
same
wire
transcript
as
you.
Otherwise
do
you
have
the
same
thing
and
then
in
the
key
minute
in
the
key
schedules
you
otherwise
would
have
it.
G
So
you
can
just
think
of
it
as
a
piece
of
compression,
so
so
that
I
have
italicized
my
term.
So
we
have
monomer
files
and
reconstruct
I
thought
you'd
appreciate
that.
So
the
key
idea
here
is
you
got
specialization,
but
you
also
get
forward
compatibility.
So
we
like
remove
extensions.
You
don't
need
cuz
you're,
not
using
them,
but
if
you,
if
there
are
new
extensions,
you
need
they
just
work,
fine
and
so
on,
and
so
as
an
example,
you
know
we
can
ends
and
so
otherwise
unknown
extensions.
Just
work.
G
G
So
one
way
of
thinking
about
this
I
think
also
do
a
Karthik
is
that
this
is
like
a
compression
layer
between
the
handshake
and
the
end,
the
record
layer
and
so
on.
Like
a
mission,
you
compress
using
that
using
the
profile
as
input
to
tell
you
what
to
compress
out
and
on
parsing
you
decompress,
using
the
profile
as
input
to
tell
you
how
to
decompress
DG's
love
in
the
second
al.
G
This
is
like
a
lot
simpler.
That
sounds.
Barnes's
are
like
really
compact
implementation
of
this
in
it.
So
especially
themselves
are.
This
was
supposed
to
be
hidden.
I
apologize,
I,
didn't
mark
it
hidden,
especially
since
elves
are
like
basically
defined
in
JSON.
So
here's
like
a
simple
specialization
this
it.
This
says,
like
you,
do
only
tell
us
more
three
and
do
only
these
on
the
cipher
suite,
and
so,
when
you
do
this,
you
just
don't
put
those
things
in
the
mark.
They
just
appear.
G
So
you
just
save
yourself
what
like
I,
don't
know
like
a
octets
so
like
that
was
some
the
but
again,
and
so
when
you
decompress
the
transcript,
you
have
only
the
fields
as
you
have
like
those
long
things
reported.
That
means
you
have
a
once.
One
version
in
the
version
supported
verses
list
and
you
have
on
both
directions
and
you
have
one
cypher
Swedish
brushes
well,.
F
G
Yes,
yes,
quite
so,
and
so
that
the
nonsense
previously
they
thought
I
admitted
was,
you
might
imagine
actually
having
a
way
to
signal
on
the
wire
that
actually,
you
was
always
like
injective
and
you
could
figure
out
what
was
going
on,
but
on
my
supposed
registration,
okay,
so
like
so
they
we
have
a
whole
bunch
of
percenter
points.
You
can
actually
see
c'mon
horrifies
on
it's
worth
on,
dealing
with
extensions
cuz,
that's
probably
most
complicated
one
in
the
source
of
most
of
the
hold.
G
I
was
the
actual
size
of
Chalfont
3,
so
whether
they
did
a
whole
predefined
extensions
and
basic
the
ideas.
You
say
this
extension
only
has
this
value
so
like
here's,
it
only
a
OPN
value
and
you
just
basically
spit
on
a
fixed
text,
string
your
stuff
in
the
profile
on
you
on
the
extensions
do
pair
of
the
transcendent.
G
As
I
say,
this
allows
you
to
have
other
extensions
which
are
encoded
as
usual,
which
aren't
the
ones
that
are
predefined,
so
it's
just
pop
in
normally
and
we
we
in
order
to
make
the
the
the
decompression
work
properly
and
the
question
work
properly.
We
require
extensions
to
appear
in
code
point
order,
which
is
a
change
from
1
3,
but
it's
a
compatible
change,
namely
you
can
so
you're
always
allowed
to
do
this,
isn't
for
PSK
and
PSK.
Just
has
to
be
at
the
end
of
our
call.
G
Crypto
had
this
property
to
their
didn't
have
PSK.
So
now
we
have
a
few
places
where
their
asses
and
their
sort
of
non
orthogonal
axes
that
we've
defined.
That
I,
don't
think
appears
here,
yeah
that
don't
just
involve
predefined.
So
as
a
given
example
like
if
you
say
why,
only
due
to
curve
two
five,
five
one,
nine
that
like
has
implications
on
a
bunch
of
things,
but
it's
one
axis
about
an
organization.
So
here's
like
a
good
example.
G
This
is
like
a
sort
of
highly
compressed
profile,
so
you
can
see
a
center
version
has
one
cipher
suite.
There's
this
D
age
group
parameter,
which
means
I
only
support
to
5
5,
a
9,
which
means
I'm
not
going
to
send
supported
groups
and
I'm
only
gonna
send
one
key
share
and
like
by
the
way,
don't
do
HR,
because
I
doesn't
make
any
sense.
This
has
like
reduced
random
the
finish
sizes
to
give
you
a
high,
a
compact
on
thing.
G
This
is
like
this
is
going
back
to
the
lake
use
case
and
then
here
the
extensions,
so
that's
s
and
I,
and
that
and
their
signature
algorithms
as
well
force
difficut
requests.
So
this
also
implies
you're
gonna
do
TLS
indication,
so
this
is
sort
of
like
both
conditional
convenience,
but
I'll
see
you
might
imagine,
having
a
machine-readable
implementation
which
could
process
this
and
then
either
either
enforce
this
automatically
or
actually
to
go
back
to
the
circuit
or
extended
rust
example.
G
Really
Mont
amorphous,
where,
like
I,
have
an
implementation,
which
is
really
too
many
implementation.
It
processes
this
and
it
spits
out
a
straight
line.
Implementation,
which
only
does
these
things
and
the
idea
is
in
that
case.
What
you
do
is
you
just
like
pick
over
the
you
just
pickle
the
strings
on
the
Indira
publication
directly,
one
special
point
which
is
worth
getting
at,
which
is
this
million
certificates
so
like
in
any
real
on
any
real
situation,
we're
a
vast
majority.
The
data
on
the
wire
is
the.
G
If
we
were
certificate
and
as
long
as
you
make
sure
that,
like
you
can
distinguish
them
from
certs,
then
it's
not
a
problem
so
like
don't,
have
them
begin
with
o
x3
o
or
have
them
be
like
holy
short
on,
and
then
these
get
blown
over
the
transcript.
Like
everything
else,
that's
actually
a
really
important
point,
because
you
don't
want
to
have
like
very
short
names
that
don't
appear
in
the
transcript,
because
that
creates
confusion
about
in
the
transcript
you're.
G
Talking
to
so
like
you
know,
you
can
type
seductive
attacks,
so
this
is
like
very
straightforward,
but
it
works
nicely.
It's
kind
of
analogous
it's
kind
of
like
it's
kind
of
like
a
specialized
version
of
cash
info.
So
this
gives
you
an
enormous
amount
of
compression.
If
you
do
all
this
stuff,
where
the
profile
I
just
showed
you.
Basically,
you
like,
reduce
the
size
of
TLS.
By,
like
you
know,
a
factor
of
three
or
four
so
like
this
oppress
are
pretty
good
about
of
reduction.
G
U
G
That
means
they're
like
if
he's
like
a
minimum
size.
The
handshake
is
like
is
like
we're
also
it's
large,
so
this
is
all
about
reducing
things
about
that.
So
like
just.
Let
me
like.
Let
me
open
with
like
I
understand
that,
like
this,
like
this,
like
pressurization
thing,
looks
a
little
fancy
and
like
and
like
we're
sort
of
back
and
forth
on
like
how
overwrought
it
is,
I
may
be
a
little
overwrought.
So
definitely
you
know
feedback
who
desired.
G
Unlike
maybe,
we
got
too
fancy
and
pieces
of
it,
but
it
actually
worked
out
pretty
well
and
I.
Think
it's
a
good
way
to
define
sir
these
noble
profiles,
as
I
say
both
for
compassion
and
also
for
and
also
for
you
know,
implementation
want
to
be
simple
as
I
sort
of
the
cost
of
some
at
the
cost
of
the
simple
limitations
of
having
a
bunch
of
like
fixed
strings
floating
around
at
this
system.
G
G
No
hooks
to
do
this
with,
and
so
the
proposal
here
is
is
to
actually
do
the
like
do.
The
document
engineering
describes.
This
is
where
the
cut
point
is.
This
is
the
expectations
TLS
has
about
the
record
layer.
This
is
the
points
at
which
the
keys
get
emitted.
This
is
what
you
can
do
here
here
and
here
and
that
and
that,
and
that
basically,
this
is
arising
after
interface,
be
the
record
layer
intention
and
the
handshake
layer
on
so
yeah
as
I
say
here,
this
is
really
retconning.
G
What
we
did
we
didn't
quick,
but
the
idea
is,
if
you
wanted
like
another
thing
like
that,
like
say
for
like
say
for
OS
Koroth,
it
would
then
be
straightforward.
You
know
exactly
with
interface
points
work,
so
I,
don't
have
anybody
read
this
okay
I
see
some
people
raising
their
hands.
I
mean
these.
Are
your
questions
online?
The.
I
Question
really
is
right
so
where
this
would
go,
the
80s
directed
us
that,
basically,
if
it
was
going
to
get
adopted
anywhere,
it
was
going
to
get
adopted
in
this
working
group.
So
this
is
a
request,
but
we
can
only
really
adopt
this
after
we
change
the
Charter,
so
I'm
going
to
take
this
home
because
I
want
to
do
this.
It's
obviously
module
on
the
fact
that
we
can
get
an
agreement
on
the
Charter
Daniel.
I
R
Daniel
me
go
Ericsson
I
think
it's
not
the
first
time
we're
compressing
protocol.
It's
a
well-known
thing.
The
IT
I
forgot
a
lot
of
experience
in
that
and
the
LP
one
working
group
has
been
focused
on
that
and
they've
defined.
A
framer
I
think
we
should
work
with
them
and
try
to
be
as
close
as
I
was
I
mean
to
reuse
the
concept
at
least
ever
use
the
dimension
and
use
the
same
syntax,
at
least
to
express
the
compression.
So
I
think
we
should
work
with
them
enough.
G
I
think
I
think
certainly
like
this
is
like
these
V,
like
negative
one
so
like,
if
like,
if
they're
working,
who
wants
to
work
on
this
and
like
go
in
this
general
direction,
like
I,
think
we'd
have
like
a
lot
of
like
a
room
to
like
screw
around
with
what
the
actual
syntax
was
like.
This
was
like
made
up
by
me
like
in
two
hours
over
a
beer
dudes.
S
G
G
T
T
G
V
Tommy
Polly
Apple,
so
yeah
I
think
this
is
very
good
work.
I'd
love
to
see
it
adopted
here
so
I,
also
working
on
quick
I
think
it
would
make
a
lot
of
sense
to
streamline
things
but
to
the
point
that,
like
Daniel
was
making
earlier
I
mean.
Yes,
we
have
a
lot
of
other
things
that
do
compression,
but
I
kind
of
see
this
being
having
other
benefits.
V
Besides
just
making
the
handshake
smaller
and
giving
compression
it's
not
merely
that,
because
I
also
see
a
lot
of
trends
in
you
know
people
doing
kind
of
like
new
application
cases
in
which
people
look
away
from
TLS
because,
like
oh,
it's
too
complex,
it's
too
extensible
or
these
other
things
so
I
think
this
will
also
make
I'm
TLS
more
attractive
to
people.
Looking
for
these
lightweight
use
cases
and
that's
a
really
big
benefit
in
my
mind,
yeah.
G
That's
really
something
we've
been
thinking
about
and
I
think
that's
a
bit
of
a
point
where
Richard
and
I,
but
going
back
and
forth
a
little
bit
and
that
there's
like
syntactic
compression
mechanisms
you
can
use
and
there's
semantic
compression
mechanisms
you
can
use
and
I've
been
definitely
more
her
semantics.
In
many
cases,
that's
the
cost
of
some
some
syntactic
complexity,
so
I
think
that's
the
part
worth
is
it
where
is
to
think
about.
G
Like
is
what's
the
most
awesome,
ol
mix
of
those
and
I
think
there's
geese
and
you
can
see
even
here,
there's
some.
You
know
like
there's
some
pieces
with
your
basic
syntactic,
which
is
like
replace
this
extension
with
this
like
string
and
there's
some
places
with
your
semantics,
which
is
like
we
only
do
this
diffie-hellman
group
and
trying
to
find
the
right
mix
of
that
is
very
difficult.
Daniel
I
cut
the
line.
G
It
is
not
enormous
you
get
probably
I
mean
I
loved.
When
I
looked
at
this
I
think
we
got
like
we
offer
a
basic
TLS
handshake.
We
probably
saved
off
like
30
or
40
octets,
so
it
wasn't
like
enormous.
It
was
partly
like
so
like
I'd,
be
I'm,
not
fixated
on
keeping
that
it's
just
like,
like
I,
felt
like
doing
any
kind
of
like
doing
any
kind
of
work
here
and
not
cleaning
from
those
gross
bothered
me
a
little
bit
but
like
I'm,
not
I'm,
not
gonna
lie
down
on
the
road
over
it.
Alright.
I
I
I
W
Tardy
it
was
really
no
and
which
is
the
the
unusual
variation
of
yes
and
I,
actually
think
all
of
the
work
is
interesting,
but
that
it
should
be
decomposed.
The
retconning,
for
example,
I
think,
is
going
to
be
much
faster
and
very
very
useful
quickly
where
some
of
the
the
compression
stuff
there's
lots
of
different
ways.
You
can
approach
this
and
that,
if
you
split
the
split
the
work
up
in
it
might
be
significantly
faster
to
get
some
pieces
of
it
done
that
that's
not
a
no
to
the
work.
W
G
C
Great
all
right,
so
this
is
the
heavy
stacked.
If
you
helmand,
draft
the
looting
to
earlier.
We
have
talked
about
this
previously
in
London
Nick
gave
the
presentation.
Draft
has
been
sort
of
revved
a
couple
times
since
then
not
much
changes,
but,
given
the
you
know,
renewed
interesting,
come
back
to
LS
and
how
this
helps
we
figured.
We
bring
it
back
to
the
working
group
and
see
if
there's
interest
so
for
those
of
them
for
those
of
you
that
are
not
familiar.
C
The
semi
psychic
tiffy
Hellman
is
basically
plugging
a
hole
in
the
opt
LS
design
that
was
not
yet
filled
by
TLS
1.3,
which
supports
the
normal
one.
Rt
t
case
non
semi
static,
where
the
server
actually
gives
you
a
certificate.
Instead
of
you
know,
a
Tiffany
share
getting
them
both
PSK
variants,
so
the
semi
static
case
is
instead
of
the
server
sending
a
cert
and
a
signature
computed
over.
C
This
sort
of
that
looks
like,
if
you
think
of
it,
in
the
opt
loss
flow
so
claim
hello
goes
out
the
door
server
low
comes
back.
You
get
both
a
diffie-hellman
key
shear
and
a
femoral
one,
which
is
G
the
Y
here
and
is,
and
in
addition
to
that,
a
semi
static
key,
which
is
typically
represented
to
you,
the
s
and
then
the
rest
of
the
computation
is
sort
of
the
same.
Instead
of
my
signature,
we
there's
a
Mac
great.
C
A
motivation,
for
this
is
I,
guess
they're
a
couple
points
that
we
want
to
highlight,
the
first
of
which
is
there.
There
may
be
scenarios
where
you
only
want
to
use
a
single,
primitive.
You
might
not
to
use
signatures
at
all.
Like
you
can
imagine,
clients
and
servers
supporting
70
settings.
Iffy
Holman
client
only
need
to
you
know:
support
like
have
code
to
do
diffie-hellman
operations.
They
wouldn't
have
to
do
any
signature
verifications
assuming
that
the
server
did
not
deliver.
C
You
know
the
semi
said
a
key
share
by
a
certificate
or
anything
like
that,
and
potentially
also
that
the
client
is
like
pinning
the
diffie-hellman
visit
a
static
share
that
the
server
gets.
So
it
knows
like
we're,
saying
to
use
and
doesn't
have
to
like
basically
punting
but
punts
the
authentication
of
the
semi
static
share.
In
that
context,
and
in
the
web,
where
a
semi
static,
he
shares
deliver
vital
you
credential,
you
still
have
to
do
a
signature
verification
on
the
certificate.
C
This
just
allows
you
to
potentially
do
different
algorithms
like
the
ones
that
Nick
was
referring
to
earlier
and
also
has
benefits
in
that
it's
potentially
a
lighter
key
exchange
variant,
not
in
the
you
know,
certificate
case.
But
in
this
you
know
sort
of
deployment
model
where
you
have
only
diffie-hellman
using
semi
static
instead
of
massive
signatures
or
massive
certificates
and
signatures
is
potentially
more
appealing
in
those.
Those
contexts
also
has
the
benefit
of
mixing
explicitly
missing
a
long-term
secret,
which
is
the
static
share
into
the
master
secret.
C
Of
course,
there
are
other
ways
to
go
about
sort
of
mixing
things
into
the
master
secret
or
like
potentially
helping
with
bad
randomness,
or
something
like
that.
There's
a
draft
in
the
CFR
G,
which
kind
of
talks
about
something
different
or
a
different
proposal.
But
this
is
you
know
this.
Has
that
consequence?
So
that's
nice!
C
The
the
idea
is
basically
to
where
we.
This
is
the
current
TLS
1.2
1.3
key
schedule.
We're
in
the
master
secret
is
derived
you'll
notice
that
there's
this
nice
convenient
little
zero
on
the
left.
That
Jonathan
was
actually
referring,
or
you
know,
covering
earlier
in
his
presentation.
The
change
with
the
semi
static
key
schedule
is
basically
to
take
the
output
of
the
client,
ephemeral
and
server
static
and
put
it
in
that
slot
more
or
less,
and
then
computer
Mac
with
that
secret.
C
How
convenient
that
we
have
that
zero
there
to
negotiate
this
thing
there
will
be
a
extension
of
art.
You
know
addition
to
the
signature
scheme,
enumeration
that
says:
I
support
signatures
with
p2p
physics
or
whatever
in
the
name
group
you
want,
and
if
the
server
supports
it
it
would
just
you
know,
send
back
either
a
delegate
or
credential
if
you
who
also
supported
delegated
entries
or
whatever
mechanism,
I,
think
the
actual
like
details
of
how
we
get
the
keys
deliver
to
the
client
and
potentially
something
we
can
work
out.
C
F
C
G
So
they
think
pieces
right,
I
mean
I.
Think
that
the
reason
we
did
this
way
that
the
design
were
like
is
indicating
is,
is
like
the
size.
The
purpose
that
is
the
function
these
are
serving
right,
I
mean
it
is,
it
is
verifying
their
certificate
is
binding
the
certificate
to
the
to
the
transcript
to
the
traffic
you're
sending.
G
G
G
F
I
was
I
was
more
worried
about
this,
extending
to
changes
in
the
protocol
that
were
more
than
just
confined
to
the
signature,
negotiation
and
construction,
because
the
insertion
into
the
key
schedule
is
is
is
a
new
thing
that
that
some
implementations,
maybe
you're,
prepared
to
do.
If
you
do
that
solving
inside
the
certificate.
G
G
We
do
not,
in
fact
we
not
in
fact
mix
them,
and
so
it
is
a
little
goofy
honestly
and
so
like
I
would
not
actually
I
think
Karthik
was
was
pushing
for
basically
keeping
the
current
TLS
like
structure
and
not
using
that
last
joint
in
the
protocol,
so
I'll
be
a
totally
valid
thing
to
do.
It
would
be
I
am
like
different
people
have
different
laws.
I
guess
you
weren't
in
Lake
yesterday,
but
different
people,
different
levels
of
sympathy
for
this
petitioner
at
the
long
term
versus
short
term
secrets.
G
G
D
C
Cheap
plug
yeah,
so
there's
also
open
question
of
how
we
have
want
to
do
clarification.
The
draft
has
one
particular
approach.
Maybe
that's
not
the
one
we
go
with.
There
is
a
entire
open
question
about
whether
or
not
you
use
the
semi
sector
for
zero
RTT
and
how
you
actually
deal
with
early
data
instead
of
like
using
tickets
to
you,
know,
potentially
internalize
like
early
data
encryption
to
a
server
and
how
you
get
the
semi
set
of
key
and
those
particular
scenarios
and
they're.
C
Considering
that
we
have
compact
TLS
going
on
and
there's
interest
in,
this
particular
work,
and
this
has
benefits
relevant
to
that
like
to
know
if
the
working
group
is
interested
in
adopting
this
and
moving
it
forward.
Of
course,
there
are
a
lot
of
holes
to
plug
and
things
to
work
on,
but
I
think
we
could
sort
them
out,
especially
in
you
know,
in
cooperation
with
Hugo
and
Karthik,
and
folks
like
that,
going
forward
so
yeah.
B
I
B
I
X
X
Yes,
so
if
we
look
at
TLS
handshake
cost,
we've
got
like
various
symmetric
junk,
which
is
basically
free
as
far
as
we're
concerned
compared
compared
to
the
other
stuff,
client
and
server.
Will
each
do
any
CDH
operation,
which
is
much
slower
than
the
symmetric
stuff,
but
you
know
we
can
negotiate
a
fast
DC
curve
and
that's
pretty
independent
of
like
other
things,
and
then
you've
got
like
a
signature
with
a
long-lived
key
which
can
get
kind
of
expensive
in
some
scenarios.
X
X
Maybe
you
stick
it
in
some
hardware
thing
and
these
things
make
them
more
expensive,
and
so
can
we
lower
the
signature
costs
so
other
proposal
is
you
go
combine
a
bunch
of
concurrent
batching
signatures
into
a
Merkle
tree,
sign
one
thing,
and
then
that
will
cover
exponentially
many
clients
and
that
way
we
can
amortize
the
cost
of
things.
So
yeah
the
structure
is
fairly
boring.
You
have
you
can
like
either
hash
a
leaf
or
hash
two
nodes
together
and
then
the
signature
is
a
path.
This
is
more
useful
with
a
picture.
X
So,
if
you
have
say
three
clients
come
in
at
once
and
you're
signing
thread
wakes
up
and
you're
like
oh
okay,
I
need
to
go,
make
a
signature.
They
build
a
Merkel
tree
on
top
of
this
I'll
talk
about
what
the
weird
blind
or
nodes
are
later
sign.
The
signature
sign
the
root,
and
then
you
ship
a
path,
or
rather
the
nodes
to
the
side
of
the
path
to
each
client
and
this
constantly
logarithmically
many
okay,
it's
not
very
coherent.
X
X
So,
basically
you
do
not
care
about
your
signing
throughput
anymore
at
all.
The
TLS
implementations
need
to
be
modified,
but
yours,
but
you
can
use
the
same
certificate.
You
can
use
the
same
like
signing,
RPC
or
whatever,
because
the
only
thing
that
changes
as
far
as
the
signing
machine
is
concerned
is
the
input
we
do
require
modified
peers,
and
so
presumably,
if
you
have,
if
you
have
a
new
deployment,
you
could
say
just
require
this,
and
then
you
don't
care
about
the
legacy
case.
X
If
you
have
an
existing
deployment,
then
you
can
still
get
some
benefits
here,
because
the
average
load
will
decrease
if
many
peers
support
it
and
under
load.
When
you're
doing
the
Austin
have
to
decide
which
piers
to
which
requests
to
like
throw
away,
you
can
preferentially
serve
the
basketball
ones
since
they're
much
cheaper
and
I've
been
essentially
saying,
piers
and
everything,
because
this
applies
symmetrically
on
client
or
server,
although
usually
the
dose
concerns
are
on
the
server
side.
X
Some
details,
the
domain
separation
of
the
inputs
is
preserved
because
we
don't
throw
away
the
contact
string.
The
signature
on
the
root
has
its
own
context
string
so
that
can't
be
mixed
up
with
non
batch
signatures,
since
presumably
your
client,
it's
your
your
key
is
going
to
be
servicing
both
kinds
of
clients,
the
blinding
nodes
which
may
not
actually
be
necessary,
but
since
in
yes
and
I,
the
signing
the
assigning
payload
is
secret.
X
And
if
you
look
at
the
tree,
the
first
know
you
would
get
is
the
sibling
the
bottom
node
in
the
path
would
be
the
sibling.
It
would
be
the
hash
of
a
sibling
in
your
tree,
then,
in
order
to
not
have
to
think
about
it
or
like
well,
it
will
just
cost
you
to
pay
one
extra
level
of
the
tree
to
just
put
some
randomness
in
there
and
all
the
other
nodes
will
have
randomness
merged
into
it
doesn't
actually
leak
the
information.
X
What
else
do
we
have
at
some
point?
Unicode
pad
stuff?
It's
not
a
power
of
two,
so
just
copy
of
them
from
other
nodes
of
the
tree
levels,
and
then
some
information
is
revealed
about
signing
loads.
Sorry,
oh
yes,
sorry
there
are
details
on
this
slide.
They're
not
super
important
and
there's
a
draft.
Are
there
questions
hey.
L
G
X
So
I
think
the
the
main
thing
is
that
this
will
work
with
like
without
change.
Like
the
DC
thing,
you
have
to
go,
build
some
infrastructure
to
go
and
and
like
deploy
new
news
new
certificate.
New
DC
is
regularly.
You
need
to
deal
with
the
DC's
only
work
if
these
are
only
useful
if
the
lifetime
is
bounded
by
something
relatively
short,
and
so
that
means
the
verifier
needs
to
have
working
clocks.
G
X
F
Q
Con
Gilmore
I'm
supported
this
work.
You
mentioned
that
it
may
leak
some
information
about
the
server
load.
I,
don't
think
you
need
to
do
that.
The
signer
can
always
sign
a
tree
of
arbitrary
depths
and
it's
going
to
be
cheap
when,
especially
when
you're
not
under
load,
which
is
when
you
need
to
extend
the
size
of
the
tree
so
yeah
well,.
J
B
H
X
L
Christianity
mom,
that's,
we
could
walk,
but
it
kind
of
makes
me
sad,
and
the
reason
it
makes
me
sad
is
that
it
makes
the
big
servers
more
efficient.
And
thus
it
reinforces
the
advantage
of
the
big
servers
above
the
small
ones,
and
it
pushes
towards
ever
more
concentration
on
the
market
in
the
internet.
And
that's
what
makes
me
sad
and.
X
I
J
I
At
the
last
hour
here,
we
think
when
indulge
hopefully
you'll
indulge
me
and
stick
around
for
the
last
two
minutes,
so
we
can
do
these
requests.
There
are
a
number
of
requests,
or
a
number
of
people
study
that
they
were
in
support
of
this
draft.
So
I
would
also
like
to
do
or
can
group
adoption
hums
for
this
draft.
So
two
questions
yes
or
no,
basically.
Well,
let's
start
off
without
other
people
interested
in
working
in
this
draft.
If
you
are
interested
in
working
in
this
draft,
please
home
now.