►
From YouTube: IETF103-TLS-20181105-1350
Description
TLS meeting session at IETF103
2018/11/05 1350
https://datatracker.ietf.org/meeting/103/proceedings/
A
C
Here's
the
note!
Well,
it's
Monday!
You
may
not
have
seen
this
yet.
Basically,
you're
gonna
get
recorded
bade
professionally.
You
got
IPR,
you
need
to
discuss
it,
disclose
it
I'll,
give
them
well
request.
We
got
a
minute
taker.
Thank
you
got
a
jabber
scribe.
The
blue
sheets
are
being
distributed
now,
make
sure
to
sign
those
put
your
name
and
your
affiliation
on
there
when
you
get
to
the
microphone.
Please
sleep
state
your
name
at
the
mic
for
the
note
takers.
C
Let's
keep
it
professional
at
the
mic
and
I'm
adding
a
new,
a
new
one
to
keep
it
succinct
at
Mike.
I
know
some
people
do
monologues.
We
don't
always
need
those
alright.
So
the
next
thing
is
the
agenda.
I
think
there
won't
be
any
agenda,
bashing,
asthama,
hope,
basically
we're
doing
the
administrivia.
Now
then,
we'll
look
at
the
details.
C
4.3
draft
then
I'll
spend
a
couple
of
minutes
talking
about
that
deprecating,
TLS,
1.2
and
1.1,
then
a
bunch
of
time
of
a
encrypted
SMI
and
TLS,
and
then
we're
going
to
kick
over
to
proposed
charter
checks
that
we
suggested.
Then
we
have
some
non
working
group
drafts.
That's
what
that
line
is
trying
to
figure
out
if
they
want
to
be
adopted
or
not.
C
What
PS
k
plus
certificates
additional
certificate
types,
the
support
be
able
to
do
communications,
and
then
we
have
these
two
ideas
about
PSK
and
quarters
and
universals
and
trying
to
figure
out
what,
if
anything,
we
want
to
do
there
and
then
we
have
another
one
called
to
get
requests
the
agenda
for
Wednesday.
Our
next
session
is
all
about
DNS
like
chain
extension,
and
what,
if
we
can
do
anything
to
move
it
too
long?
There
are
some
preliminary
slides
already
uploaded
for
those
as
well
document
status.
C
C
Slant
some
I
annan
registry
update
drafts
a
record
size
limit
extension
for
TLS,
which
was
probably
has
the
record
for
being
the
quickest
one.
Ever
through
the
working
group
we
have
in
the
RCA
turkey.
Now
we
have
currently
have
an
example,
handshake
traces
for
TLS
1.3.
I
guess
that's
gonna
get
spun
as
soon
as
it
gets
to
the
off
48
stage,
it's
kind
of
a
pain,
apparently
to
pull
the
crank.
So
we
only
want
to
do
it
once
more.
C
Since
the
last
working
group
meeting
cycled
the
the
a
dane
record
and
indiana
sec
authentication
chain
extension
for
TLS
back
to
the
working
group,
we
also
adopted
two
new
drafts,
which
are
this
deprecating
TLS,
1.2
and
1.1
and
encrypted
sni
for
TLS.
We
did
a
working
group
last
call
for
the
issues
and
requirements
for
SMI,
encryption
and
TLS
that
were
thinking
they
keep
probably
pretty,
was
pretty
easily
resolved
without
those
issues
on
list
and
then
get
it
out
of
the
working
group
soon
to
be
in
working
group.
C
Basically,
I
need
to
get
together
with
the
office
for
greece
to
get
them
to
include
a
couple,
but
then
I
think
it's
pretty
much
ready
to
go
and
in
progress
we
have
DTLS
1.3
a
certificate
compression
draft,
which
seems
to
be
going
pretty
well
they're
experimenting
with
it.
Now,
with
the
early
code
points
level,
we
had
I'm
the
delegated
credentials,
which
we
suspect
that
we
will
hear
a
lot
more
about
next
time
in
Prague
or
wherever
we're
gonna
go.
C
Okay.
What's
next,
so
the
Dilys
designated
experts
stuff
got
set
up
as
a
result
of
our
c4
for
seven.
So
we
wanted
to
let
you
know
who
they
were
in
case.
You
missed
it
in
the
email
that
got
fired
off
their
rich
salts,
Nick,
Sullivan
and
yo
gear.
You
have
a
request.
You
can
fire
it
off
to
that
mail
list.
The
archives
are
now
publicly,
so
you
can
see
the
requests.
We
don't
want
this
to
become
an
alternative
place
to
discuss
Els
things.
This
is,
if
you
have
a
request,
it
goes
over
there.
C
They
round-robin
figure
out
how
they're
gonna
do
it
and
they
get
back
to
you
if
they
don't
get
back
to
you
in
time.
There's
ways
to
fix
that.
So
far,
we've
had
these
values
registered.
C
Only
one
was
recommended
as
a
yes,
because
it
came
out
of
the
token
blind
working
group.
The
other
ones
were
all
kind
of
individuals
stuff.
So
the
first
floor,
I
think
were
one
was
for
peer,
Guttman's,
long-term,
stable
TLS
drafting.
They
would
have
been
three
for
Dan
Harkins,
dragonfly
draft
three
brain
pool
curves
for
supported
groups
and
then
a
bunch
of
exported
label
values
for
one
them
to
them.
C
D
E
C
F
E
G
I
All
right,
so
this
actually
appreciate
forward
I'm
going
to
start
with
summary.
The
changes
we
made
then
have
a
few
not
really
open,
but
quasi,
open
issues
and
then
say
I'm
done
so
we
screwed
around
with
the
header
format
repeatedly
and
in
the
last
version
of
this
we
had
a
header
format
with
like
a
bunch
of
empty
blank
space
that
we
have
marches
reserved
and
Warren
Thompson
played
out
that
we
could
shift
things
around
and
wouldn't
have
and
make
the
sequence
number
longer,
but
also
have
less
blank
space.
I
So
we
have
the
following
structure
now
so
the
first
as
it's
been
for
quite
some
time,
the
first
three
bits
have
to
be
zero:
zero.
One,
that's
like
math,
saw
for
a
specific
region
of
the
of
the
other
code
points
based
the
there's
a
C
bit,
which
means
the
CID
is
present
or
absent.
One
means
present
there's
a
L
bit
which
says
the
length
is
present
or
absent,
and
then
there's
a
and
then
there's
a
sequence
number
length
bit
which
says:
Helen
sequence
number
is
and
then
two
bits
of
the
epoch
and
I've
forgotten.
I
To
mention
this.
When
I
looked
at
this
I
think
these
are
probably
in
a
Roman
order,
so
I'm
actually
probably
shuffle
them
around
but
other
than
those
are
your
order,
but
it's
done
so
probably
I
move
around
a
bit,
but
other
than
that.
No
one
cares.
These
bits
go
so
the
basic
idea
is,
there
was
like
I,
don't
know,
there's
eight
separate
forms
depending
on
which
bits
are
set,
but
they're
all
fairly
straightforward.
Basically,
things
are
present
or
absent.
I
This
gives
us
a
unified
header
with
a
nice
range
of
with
a
width
length
or
not,
and
a
nice
sequence
numbers
that
should
be
big
enough
for
anybody.
No
I,
don't
think
anybody
thinks
more
than
16
business
sequence
numbers
needed.
So
this
was
an
initial
draft.
Nobody
complained.
This
is
what
we
discussed
last
time.
So
this
is
just
a
briefing.
Some
of
you
have
just
you
know
who
speak
up,
but
I'm,
just
gonna
keep
going.
I
Okay,
the
second
big
change
is
we
did
we
added
record
number
encryption
or
record
secret
or
encryption.
This
is
basically
the
same
technique
uses
that
we
just
stole
on.
So
the
basic
idea
is
that
you
establish
your
sure.
Key
is
part
of
the
key
schedule.
It's
not
the
it's,
not
the
record
layer,
key,
it's
a
sequence
number
key
and
that
key
is
used
to
generate
a
mask.
We
have
the
it's
effectively
a
PRF
using
the
using
some
of
the
ciphertext
as
the
input,
the
PRF.
I
The
specific
function
actually
is
depends
on
the
Associated,
but
for
AES.
Basically,
you
compute
a
es
e
CB
of
T.
You
give
it
a
sec
V
of
the
ciphertext,
and
then
you
take
that
mask
you
XOR.
The
sequence.
Number
quick
has
a
somewhat
different
description
at
this.
This
is
a
national
algorithm
that
Martin
and
I
disagree
about
what
the
most
of
what
specific
way
to
describe.
It
is
oh,
who
was
it?
I
I
To
leave
it
the
way
it
is,
but
if
somebody
thinks
more
in
detail
is
generally
not
as
aggressive
quick,
isn't
working
everything
anyway.
Okay,
third
major
announcement,
I
D
here
so
tails
for
three
is
its
compatibility
mode.
That
would
let
you
get
through
screwed
out
middle
boxes.
There's
like
no
point
having
that
for
DTLS
0.3.
As
far
as
anyone
can
tell
so
the
spec
kind
of
said,
you
should
use
it
and
this
Becker
line
where
it
says
it
really
says,
don't
use
it.
I
So
that's
just
like
concretizing
that,
okay,
so
now
to
the
actual
technical
matters
such
as
they
are
on
so
TLS.
One
three
has
this
message:
called
Hinch
investors
called
a
OED
end
of
early
data.
Have
you
cut
over
between
the
early
data
fields
and
the
and
the
clients?
Second
handshake
flight
said
so
in
tell
us
what
this
tells
you
is
now
is
the
time
when
I'm
not
sending
any
more
early
data,
and
then
the
next
thing
you're
gonna
see
is
gonna,
be
handshake,
and
so
in
TLS.
I
You
need
this
to
avoid
a
trial
decryption,
because
the
state
machine
is
like
it
was
like
a
block
step
state
machine.
It
also
has
the
effect
that
it
prints
truncation
attacks,
because,
because
we're
changing
keys
and
your
genes,
you
can
sequence
numbers.
If
you
don't
know
when
early
date
ends,
then
the
attacker
can
just
pull
a
bunch
of
early
data
and
have
that
go
away,
and
then
you
just
think
the
early
data
did
you
get.
I
You
basically
got
a
slice
cut
out
of
the
data
between
the
early
data
and
the
one
and
then
wonder
who
did
it?
So
none
of
these
things
applies
to
detail
us
DT
loss
is
like
a
perfectly
good
like
field
that
says
like
which
keys
things
are
encrypted
ins.
You
know
what
you're
doing
and
because
details
has
lost
anyway,
the
truncation
attacks
don't
apply
and
it
would
just
say
well,
they
apply
in
the
sense
that
you
can
always
mount
them
in
the
end
that
the
Yui
did
not
prevent
them.
I
So,
however,
if
you
do
heavy
OED
in
the
protocol,
this
is
a
potential
cause
of
blocking,
because
you're
gonna
lose
the
OED
and
then
like
you
could
be
processing
data,
but
you
can't
now
and
so
like
this
is
irritating
and
when
quick
did
the
tail
Centauri
binding,
we
just
removed
you
IDI
from
for
the
whole
thing,
and
this
leg
gave
everybody
like
a
little
bit
of
angst,
but,
like
nobody
could
figure
out
a
real
problem
with
it.
We
thought
about
it
pretty
hard
so
months.
I
Rosalyn
here
is
the
same
thing
here,
which
is
basically
just
strikeout
eud.
This
is
done
in
PR
number
62,
which
has
a
part.
This
is
effort,
even
though
there's
not
one
here-
and
one
thing
note
is.
This
affects
the
Trangia
transcript
so
because
Ely
DS
presidentially
transcript.
This
affects
the
transcript,
but
that
really
shouldn't
be
a
problem
anyway.
My
famous
last
words
I
know
we're
gonna
attempt
to
convince
you
know
Karthik
or
someone
to
analyze
this
for
us,
but
it's
this
pretty
straightforward.
I
I
So
when
the
set
and
the
receiver
issues
you
see
IDs,
you
can
send
you
one
and
when
the
sender
asked
for
a
CID,
he
asked
for
one-
and
this
is
this
is
tend
to
be
workable,
but
as
a
few
annoying
properties
in
particular,
because
one
because
when
you,
when
you
send
a
connection
ID
one
of
the
things
you
say
is,
should
you
wash
out
every
other
connection
ID
you
already
had,
and
so,
if
I
want
to,
if
I
want
to
basically
send
you
if
I
want
to
say,
if
so
say
the
way
I
got
things
structured
is
I've
got
a
bunch
of
about
just
a
bunch
of
receiver
state
whose
job
it
is
to
remember.
I
Election,
IDs
and
I
want
to
issue
a
new
I
want
to
blow
away
that
state
machine.
You
see
IDs
right,
so
what
I
do
right
now
is
I
have
to
say
here
is
one
new
connection.
Id
forget
everything
else,
also
here
new
ones,
one
at
a
time
right
and
so
those
get
reordered.
Then
it's
like
I'll
pay
in
the
after
process.
I
So
if
you
basically
just
maybe
just
take
each
of
those
fields,
that's
like
one
and
make
it
n.
Then
this
problem
goes
away
because
then
you
can
basically
say
here:
eight
new
ones
for
Galilee
or
once
so
there's
a
conversation
Erik,
Kinnear
and
I
had-
and
this
is
quite
a
substantial
simplification
on
the
so
the
changes
I
made
are
the
new
connection.
Id
has
an
arbitrary
number.
Cid
I
was
not
to
manage
the
same.
The
request,
connection
ideas,
account
that
says
how
many
more
you
want
and
the
other
thing
I
did
was.
I
You
can
only
have
one
of
these
each
of
one.
You
only
have
one
of
each
type
in
the
flight
from
you
at
a
time,
so
that
then
you
don't
to
worry
about
reordering
each
other.
So
that
makes
things
a
lot
easier.
There's
you
know
there
probably
is
are
some
edge
cases
like
where
you
can
be
like
connection
ID
starved,
you
know,
even
in
quick,
we
didn't
really
like
we're
sore,
like
someone
has
to
go,
write
a
camera
prove
to
ourselves.
I
You
can't
starve
yourself,
but
they
seem
pretty
edgy
and
most
of
the
migration
which
was
pathetic.
So
this
is
my
plan
here.
I
have
a
PR
for
it,
so
not
seeing
anybody
standing
up
I
plan
to
merge
this
as
well.
I
I
We
should
ask
them
for
that,
but
I
think
we
shouldn't
wait
for
what's
called
okay.
Other
thing
is
I'd
like
to
see
I'd
like
to
see
a
deal
with
implementation,
which
we
plan
to
do
very
soon,
so
so
I
think
I,
like
I
mean
if
you,
if
you
prefer
your
your
the
chairs
but
I
no
longer
plan
to
work
on
this
document,
I
plan
to
start
a
charter
plane.
Yet
so,
if
you
want,
if
you
want
to
do
working
across
call
and
then
pause
or
close
in
your
nose
call
I,
don't
care
I.
B
J
D
L
L
So
there's
only
a
few
issues
with
this
really
in
terms
of
the
texts,
so
basically
I
think
a
tricky
issue
is
going
to
be,
which
does
this
updater
obsolete
for
the
hell?
That's
probably
making
a
long
list.
There's
will
issue
is
the
it's:
it's
changing
something
in
a
BCP,
so
it
does
look
it
compared
to
that
PCP
I'm
guessing
this
is
all
kind
of
boring,
so
we
can
just
kind
of
work
there
with
two
tears
and
the
ABS
and
the
ISP
will
mind
about
it
later.
L
So,
yes,
absolutely
most
people
will
not
care
about
any
of
this
right
and
there's
some
text
in
there
about
perhaps
current
measurements
and
the
question
is
a
freshman.
We
leave
that
a
nerd
just
to
leave
before
co-star
see
alright.
If
anybody
has
an
opinion,
just
stated,
I
don't
really
care
too
much.
J
Yes,
I'm
told
so
no
there's
a
lot
of
documentation
in
the
draft
motivating
its
existence,
and
some
of
that
is
is,
quite
so
within
the
sense
of
you
know:
outdated
algorithms
and
all
sorts
of
other
things,
but
the
the
measurement
related
stuff
I,
don't
think,
really
has
much
much
place
in
the
sort
of
permanent
record
that
we're
looking
to
create
here.
So
yeah
I'd.
L
L
If
Hubert
suggested
that
the
EP
came
as
a
PR,
so
he
said
to
do
it
in
and
then
ask
the
working
group
from
stopping.
So
unless
there's
some
other
reason
to
do
this
here
we
take
it
out,
I,
don't
know
if
this
somewhere
in
some
other
place
to
do
you
guys
can
think
about
that.
So
those
are
the
only
kind
of
stuff
text,
II
kind
of
issues
really
but
then
I
guess
the
bigger
issue
is
render
progress.
L
It's
and
again
there
are
steams
chairs
will
tell
us
the
answer
or
whether
they
think
the
answer
is
so
basically
I.
Guess
the
quaint.
The
real
kind
of
question
seems
to
be:
is
the
mail
infrastructure
sufficiently
different
to
the
web
to
want
to
do
this
at
different
times
or
not
and
I?
Think
myself
and
Kathleen
think
going
ahead
is
probably
fine,
but
the
numbers
are
have
a
difference.
So
if
people
have
opinions
on
that,
I
guess
now
is
the
time
I
do
want
to
wait
until
you
do
working
with
basketball
or
something.
J
It's
a
lot
until
tonight,
I'd
be
happier
seeing
this
published
relatively
soon.
Now
you
might
have
noticed
that
work
from
at
least
some
of
us
have
taken
steps
in
this
direction
already
in
terms
of
deployment.
So
it
would
be
good
for
us
to
have
something
more
concrete
if
they
would
have
published
sometime
before
the
start
of
next
year.
That
would
be
also
good,
maybe
the
year
after
even
I
mean
I'm,
not
I'm.
Only
huge
rush,
but
I
don't
see
any
reason
to
hold
this.
M
I
Yeah
I
mean
I,
think
that,
like
that's,
I,
think
that
part
of
motivation
for
moving
the
measurement
is
that,
like
the
ideas
position,
is
this
stuff
is
no
longer
like
current
standards
and
you
should
stop
using
it
and
you
stopped
eating
it
at
whatever
pace
is
practically
to
stop
using
it,
and
maybe
you
have
a
situation
where
it's
impractical
and
I
never
take
a
longer
but
like
as
brightly
you
weights
or
a
pin.
You
should
stop
okay.
L
D
N
N
And
we've
had
version
zero
version.
One
version
two
published
these
early
versions
have
been
deployed
for
testing
situations
with
the
CloudFlare,
so
all
buckler's
customers
have
yes
and
I
support,
as
well
as
Firefox
nightly,
has
implemented
a
compatible
version
about
this
that
this
was
not
without
its
pitfalls
as
I
guess
we'll
discuss
later,
and
there
was
also
a
lot
of
discussion
on
the
list.
I
had
an
you
slide,
but
I
was
too
late
to
get
it
to
the
to
the
chairs,
but
the
general
overview
of
encrypted
S&I.
N
This
is
combined
with
a
client-side
diffie-hellman
key
to
create
an
encryption
key
for
the
SN
I
volume
and
the
public
key
for
this.
Encryption
is
sent
along
with
the
club
with
the
the
client
alone,
so
this
has
some
features
in
it
to
prevent
it
from
being
replayed
and
the
goal
is
for
SII
to
no
longer
be
clear
text
on
the
wire
and
so
forth.
I
was
following
along.
N
There
were
some
some
changes
from
the
original
proposal
and
the
original
proposal.
The
diffie-hellman
key
share
that
was
used
to
encrypt
yeah.
The
s
and
I
value
was
also
the
one
used
in
the
TLS
handshake.
This
has
been
separated,
there's
now
a
separate
key
for
yes
and
I,
and
this
this
was
meant
to
protect
from
essentially
DNS
being
able
to
dictate
with
which
diffie-hellman
share
was
being
is
going
to
be
used
for
the
connection.
There
was
also
a
few
additional
features
added
for
replay
protection.
N
This
is
a
nonce
as
well
as
the
AE
ad
for
the
the
key
share.
An
ad
aid.
The
additional
data
in
the
aad
for
the
encrypted
S&I
value
covers
the
key
share
in
the
client,
hello,
and
this.
This
is
prevents
prevents
rate,
but
there's
a
version
at
it
as
well
for
future
compatibility,
not
many
changes.
So
there
are
some
pending
changes
being
discussed,
that
the
main
one
was
the
use
of
a
specific
RR
type
for
es
and
I,
rather
than
a
text
record.
This
does
simplify
some
situations.
N
O
Edward
Dean
semantics,
so
I
have
a
statement,
a
question
in
a
follow-up,
so
several
middle
boxes
that
do
TLS
inspection
depend
on
the
s
and
I
in
order
to
make
a
policy
decision
about
whether
or
not
to
do
a
decrypt
on
that
session,
and
with
this
proposal,
that's
gonna
break
the
metal
boxes,
ability
to
do
that
at
Montreal.
We
had
talked
about
okay.
O
And
if
chooses
not
to
do
the
SSL
inspections
or
the
TLS
inspection,
it
can
just
pass
through
the
remainder
of
the
stream
untouched
and
there's
nothing
that
would
break
and
if
it
does,
and
it
can
proceed
to
do
the
the
termination
of
the
TLS
and
do
its
inspection
at
that
point.
This
has
a
couple
of
benefits.
It
makes
it
a
bit
more
transparent
that
there's
a
middle
box
there.
So
the
client
now
knows
that
there's
a
potential
middle
box
that
wants
to
participate
in
the
TL
cells
in
the
TLS
session.
O
P
P
K
Q
Lorenz
clearly,
what
are
the
implications
for
anyone
who
wanted
to
sign
that
DNS
record,
though
right
so
you're,
basically
moving
the
problem
where
you
want
to
do
intercepted
at
the
s
and
I
layer?
Two
now
you
have
to
like
you're,
basically
like
running
away
from
the
security
train.
That's
gonna
hit
you
and
it's
like
well,
okay.
The
first
line
of
defense
is
encrypted
s
and
I.
Q
Okay,
well
we'll
monkey
around
with
DNS,
because
DNS
SEC
isn't
all
out
yet,
but
so
basically
we're
just
moving
the
problem
down
to
see
DNS,
so
that
proposal
would
have
essentially
it
would
mandate
inability
to
do
DNS
SEC,
which
kind
of
means
you
basically
because
the
NSX
is
a
decision
of
the
of
the
sort
of
person
owning
the
domain.
You
basically
disable
it
for
the
clients
for
every
hostname.
So
that's
kind
of
a
very
different
impact
and
I.
Guess
you
just
just
blocking
this
right.
I.
I
Mean
I'm
not
enthusiastic
the
result,
but,
given
that
the
premises
proposal,
is
it
the
that
these
guys
are
just
playing
a
trust
anchor
on
your
client?
The
fact
that
they're
gonna
be
a
DNS
SEC
does
not
seem
like
the
simply
serious
part
of
the
problem
on
the
I
I.
Guess:
I,
don't
think
this
is
the
right
place
to
do
this.
It
might
be
the
case
that
one
would
want
to
have
some
mechanism
for
clients
might
never
not
be
the
case.
They
find
seconds
of
clients
to
exfiltrate
to
the
little
box.
I
B
I
O
Yeah,
my
only
response
to
that
would
be
TLS
is
designed
to
be
a
point-to-point
protocol,
but
in
practicing
use
and
enterprise.
It's
not.
There
are
multiple
parties
in
the
system
and
we
have
to
work
around
the
way
TLS
was
designed
and
effectively
hide
the
fact
that
we're
doing
inspection,
whereas
here
we
have
the
opportunity
to
do
it,
quote-unquote
the
right
way
and
in
a
more
transparent
way,
so
that
we're
actually
recognizing
the
fact
that
some
enterprises
want
to
have
the
ability
to
participate
in
this.
P
Authority
I
tend
to
support
a
KERS
point
that
this
is
probably
not
the
right
place
to
do
this,
partly
for
the
the
reasons
that
Lorenzo
already
put
forward,
but
also
because
it
now
creates
a
dependency
that
you're
kind
of
getting
your
DNS
from
the
right
server,
because
the
chances
that
the
public
server
that
that's
able
to
look
at
this
are
r-type
from
from
beyond
your
enterprise.
Has
this
available
is
very
small,
which
means
that
if
you
have
a
doe
server
or
some
configured
server,
that's
not
using
the
local
enterprise
server.
P
Now
the
enterprise
is
both
going
to
have
to
block
access
to
that
in
order
to
force
you
onto
some
locally
configured
server.
That
has
this
additional
RR
type
record.
In
order
to
do
that,
as
well
as
block
any
DNS
SEC
validation,
you
might
have
done
as
a
client
in
order
to
trust
the
DNS,
SEC
validation,
that's
being
done
servers
so
I
think
that
the
the
analogy
Lorenzo
said
was
you've
moved
the
stop.
You've
moved
one
stop
down
the
set
of
train
stations,
but
the
train
is
still
coming
for
you.
P
R
S
S
B
Regarding
I
having
a
separate
key
for
is
in
a
photo,
a
middle
box
to
show
well,
my
point
would
be
that
server
name
server
selection
is
a
our
it's
a
client
and
service
role,
so
the
sailors,
so
clients
first
signals
what
the
service
wants
to
send
to
the
collector
and
then
the
server
is
in
response,
tells
you
to
which
service
actually
being
collected
by
using
the
search,
get
message
so
either
I
give
just
looking
for
it
and
I
see
technically.
Well,
it's
not
ideal.
Q
What
was?
Was
there
any
thought
to
basically
like
allowing
at
filtration
only
this
essentially
on
device
as
opposed
to
on
network,
because
a
device,
that's
an
enterprise
zone
device,
may
have
different
security
zones
where,
if
you
do
this,
the
enterprise
that
man
has
you
know
all
the
keys
to
the
kingdom.
Q
Wonder
if
there's
something
which
makes
it
hard,
because
the
proposal
was
basically
doing
this
in
the
network
in
the
middle
box,
but
I
think
all
of
these
devices
these
days
they
have
enterprise
management,
algorithms,
that
you
know
and
and
and
modes
that
we
could
use
so
I,
wonder
if
there's
something
that's
inherently
hard
about
doing
it.
That
way,
as
opposed
to
this
way
it
not
this
way
the
way
that
was
proposed
and
I
don't
see
anyone
coming.
N
Q
But
you
don't
even
want
that
right
because
you
you
want
to
spy
on
your
users,
but
you
don't
want
the
internet
to
spy
on
your
users
right
so
see
suit
as
an
enterprise
admin.
You
want
to
basically
see
everything
that
they're
doing.
Presumably
assuming
the
law
allows
you
to
do
that,
but
you
don't
want
the
internet
to
see
what
they're
doing
right
so
yeah.
K
Q
So
I
wonder
if,
like
a
wonderful
way
out
of
this
conundrum
is
to
say
look,
this
is
how
it's
gonna
work
and
if
you
have
the
ability
to
push
a
root,
client
a
root
cert
on
the
device
or
if
you
have
the
ability
to
run
code
on
the
device,
then
this
is
how
you
do
it
and
then
all
that
of
all
the
implementations
could
do
this
or
not.
If
they
didn't
want
to
sell
to
enterprise
markets,
and
then
we
have
a
solution
right.
So
it
is.
Q
O
I
apologize
for
hijacking
most
your
time
just
to
respond
to
the
one
question:
why
can't
you
just
always
do
it
in
the
end
point
for
most
enterprises
they
want
to
run
the
situation
where
you
don't
trust
the
endpoint.
You
don't
trust
the
network,
so
you
want
to
have
a
layered
security
model
where
you
can
do
exploration
in
multiple
places
so
that
you've
got
yourself
covered.
So
that's
why
the
desire
to
doing
the
network
exists.
L
N
N
If
the
dns
and
the
server
get
out
of
sync
and
then
the
other
one
that
was
raised
on
the
list
was
the
multi
CDM
case,
so
I'm
not
going
to
propose
solutions
for
these
a
for
the
first
one,
I'll
sort
of
hint
at
some
potential
ideas
for
getting
around
it,
but
I
want
to
raise
I
guess
the
problem
statements
around
these
are
potential
operational
issues.
First,
the
heart
failure.
So
your
risk
is
your
DNS
caches,
your
yes
and
I
longer
than
your
server
keeps
it
around,
and
this
is.
N
Also,
if
you,
if
the
organization
has,
if
there's
two
different
organizations
that
manage
DNS
and
they
choose
yes
and
somehow
they
get
out
of
sync,
these
things
happen.
It's
not
common,
but
it's
it
is
a.
It
is
a
risk
because,
yes,
and
is
currently
defined,
the
way
that
clients
would
deploy.
It
is
to
not
have
a
fallback.
So
if
the
key
has
a
mismatch,
this
would
be
a
vector
for
the
for
an
attacker
to
force
the
client
to
reveal
the
SNI
that
it's
going
to
so
the
impact
of
this
is
is
unavailability.
N
You,
as
a
client
you'd,
not
be
able
to
see
the
site,
so
there's
a
possible
idea
for
solution
which
is
to
distribute
the
ESN
Aiki
through
TLS
through
the
connection
one
idea
around.
This
is
typically.
If
you
connect
to
a
site,
there
are
servers
that
are
able
to
handle
requests
that
do
not
have
sni
and
therefore
having
a
default
certificate
installed.
You
could
potentially
imagine
a
scenario
where
the
server
has
a
default
certificate
for
no
sni
and
then
another
default
certificate
for
an
es,
and
I
that
can't
be
decrypted.
N
You
could
indicate
in
the
SMI
record
that
if
you
see
the
default
certificate,
this
is
a
trusted
channel
for
updating
ESI.
So
you
would
make
a
request.
The
server
does
not
know
how
to
decrypt
B
ES
and
I
the
encrypted
s
and
I
extension.
Instead,
it
replies
back
with
an
es,
ni
ki,
and
this
handshake
is
signed
by
a
certificate
that
covers
the
say,
distinguished
hostname,
for
that
es,
ni
key
and
then
you
would
terminate
the
connection
and
you'd
resume
with
another
TLS
connection,
using
the
new
es
and
Ikey.
So
this
this
is.
N
This
is
a
case
that
should
be
rare,
because
miss
configure
and
this
miss
configuration
in
this
manner
should
be
rare.
But
there
are
definitely
issues
with
caching
in
DNS
vs.
and
you
know
transitioning
from
one
key
to
another,
and
we
ran
into
situations
that
I
mirror
this
and
our
in
our
initial
deployment.
Q
Clarification
question:
let's
say
that
you
wanted
to
implement
this,
where
they
resolve
our
library
with
an
HTTP
library
or
with
that
sort
of
HTTP,
quick,
whatever
transport
layer,
library,
you
would
need
a
sort
of
richer
communication
mechanism
between
those
two
than
just
here's,
an
acai
record
and
and
here's
the
key
right.
You'd
have
to
also
return
the
host
name
as
well,
but
is
that
all
it
takes
or
is
it
sort
of
visit
like
complicate
the
interaction
between
these
components?
More
I.
N
I
Structure
so
I
mean
all
these:
the
existing
stacks
that
I've
seen
that
the
NS
s1
and
Pico
TLS
one
you
just
you
just
give
the
stack
a
giant
whatever
the
heck
appeared
in
DNS
is
one
giant
monolithic,
blob
I
think
that
the
difficulty
here
is
gonna,
be
that
this
is
gonna
manifest
manifest
itself.
I
As
a
as
a
connection
depends:
afghans
implemented,
it's
gonna
manifest
adele
is
a
very
funny
connection
state
where
it's
like
I've
connected,
but
like
this
all
along
hum
and
so
you're
gonna
need
some
way
to
basically
say
basically
that
the
bypass
whole
sort,
validation,
logic
and
say
like
listen,
you
connected
on
but
like
this
is
not
really
a
connection
and
like,
if
you
make
this
api
call,
the
other
api
call.
Well,
you
do
serve
validation,
but
it
gets
a
different
search
because
you,
because
the
connection
is
not
live
right,
and
so
it's
like
listen.
I
This
connection,
don't
try
to
write
in
here
international
for
God's
sake,
but,
like
you
know,
but
on,
but
but
like
if
you
call
this
other
API
key
API
call
you'll
get
the
yes
and
I
blob,
which
you're
good
back
to
me.
Then,
like
a
begin,
new
connection
and
that'll
work,
good,
so
I
think
you
lenses
right,
it
would
be,
it
would
complicate
the
API
substantially.
I
I
mean
while
saying
it's
unfixable,
but
it
wouldn't
be
like
totally
straight
for
and
the
condemned
the
fear
I
would
have
would
be
making
sure
at
this
does
not
ever
put
you
in
a
position
where
you're
the
this
first,
this
suicide
connection
that
doesn't
it
doesn't
it
doesn't
work
properly,
is
writable
and
you're
sending
data
down
the
essentially
the
wrong
pipe.
The
because
it's
not
like
that.
That's
not
a
because
that
really
I
mean
that
is
not
a
secure
relationship.
Right
I
mean
that
is
like.
N
T
Civil
diner,
so
this
also
assumes
that
the
fallback
hostname
does
not
change
as
well,
and
so
that's
right
and
so
or
changes
slower
than
the
yes
and
IKEA.
It's
a
point,
and
also
like
you
could
get
into
other
situations
by
this
fallback
connection
is
used
as
a
look.
Sorry,
this
suicide
connection
is
ekor
called.
It
is
used
for
the
other
requests.
For
example,
if
the
fallback
hostname
certificate
actually
does
contain
a
valid
host
name
of
the
yeah
or
a
star
dot
or
something,
then
you.
What
is
the
policy
that
the
clients
should?
L
N
L
N
L
More
generally,
I
mean
I.
Think
the
the
point
of
previous
slides
I
think
there
isn't.
That
I
think
it's
probably
fair
to
say
that
the
the
current
proposal-
and
maybe
this
is
friendly
towards
TLS
developers.
I,
don't
know
if
it's
friendly
towards
TNS
operators
and
because
I
think,
like
you
know,
having
it
been
up
before
not
after
in
the
es
Mikey's
seems
to
me
to
be
a
bit
odd.
L
It
seems
to
create
new
corner
cases
when
you
compare
with
other
kind
of
TTI's
and
our
RC
kind
of
eligibility
periods
and
so
on,
and
so
I
guess.
I'm
just
I
would
ask
that
at
some
point
we
try
and
make
sure
that
what
we're
proposing
to
put
in
dns
is
something
that
people
would
like
to
put
in
DNS.
More
generally
than
just
the
initial
two
people
deploying.
J
Q
It's
very
damaging
configuration
error.
How
like
how
much
do
we
think
it
would
hurt
adoption
of
this
proposal
if
we
basically
declared
it
to
be
a
configuration
error,
I
mean
you
can
create
other
configuration
errors
like
hand
out
the
wrong
ap
v4
address
in
your
DNS
and
yeah.
The
site's
also
unavailable
in
that
way.
So,
if
you
like,
you
know,
have
we
you
know,
have
we
tried
to
say,
look
yeah,
we
could
say
this
is
a
configuration
error.
Q
R
Sol's
Akamai
yeah,
we
would
have
a
real
hard
time
the
we
want
to
deploy
some
kind
of
encrypted
S&I.
We
would
have
a
real
hard
time
deploying
something
that
had
this
kind
of
failure
case,
because
people
who
want
yes
and
I
really
want
that
privacy
guaranteeing
and
if
all
of
a
sudden
we
all
and
we're
running
the
DNS
server,
and
we
it's
not
it's
not
just
a
configure
our
you
know,
networks
break
apart.
R
R
P
To
Ted
Hardy
pretending
to
be
a
DNS
vote
for
just
a
moment
that
they
actually
been
recommending
using
newer
types
for
quite
a
while
now
so
really
not
their
fault
there.
There
been
deployment
issues
that
have
made
other
people
recommend
that
you
do
not
do
it,
but
from
the
from,
though,
what
what
is
the
one
true
way
you
are
are
types
if,
in
the
one
true
way
for
a
good
long
time,
but
I
actually
wanted
to
kind
of
go
back
to
a
question
that
I
think
both
Stephen
and
in
chat.
P
P
You
basically
say
any
of
these
records
can
be
used
that
they're
all
valid.
If
there's
multiple
ones
of
these
records,
they're
all
valid,
you
could
actually
cause
the
structure
of
what
you
include
in
the
record
to
include
validity
dates
or
or
other
timing
information
that
would
allow
you
to
tell
that
the
two
different
ones
you
got
are
actually
meant
to
be
use.
Sequentially,
oh
sorry,
does
have
that
and
I
just
missed
I'm.
Sorry,
okay,.
M
U
John
colonics,
so
I
was
I
misunderstood
the
suicide
connection
thing
in
a
way
that
I
think
might
work
better,
which
is
why
can't
you
just
restart
the
TLS
handshake
from
scratch
over
the
same
connection
after
you've
gone
through
this
dance,
which
could
then
hide
all
this
complexity
within
the
TLS.
That
could
hide
all
this
complexity
from
the
from
the
application
or
the
transport
layer.
I
mean.
Obviously
it's
going
to
cost
you
two
round-trips,
but
in
the
in
this
weird
configuration
error,
state
I
think
costing
a
few
round
trips
rather
than
a
heart.
E
U
N
I
N
N
N
You
can
have
it
configured
so
that,
depending
on
who's
requesting
or
the
location
or
the
time,
you
could
have
your
the
authoritative
DNS
provider
return
estate
of
a
records
corresponding
to
one
provider
or
another
provider,
and
these
providers
are
likely
not
going
to
be
sharing
es
ni
keys
and
you
have
the
option.
It's
ten
there's,
potentially
a
situation
where
one
provides
the
pro
one
provider
does
not
know
about
the
other
provider
or
one
provider
supports
the
sni
and
one
does
not.
N
So
the
question
is:
if
you
do
obtain
these
two
queries
would
be
you
query,
a
a
a
sorry,
a
or
quad
a
well,
and
then
you
also
could
query
for
yes
and
I
record
and
they
could
end
up
pointing
you
to
different
providers.
There's
no
nothing
atomic
connecting
these
two
requests
together,
so
getting
out
of
sync
would
result
in
encrypting
sni
to
the
wrong
providers
key
or
to
a
provider.
That's
not
have
yes
and
I
enabled,
and
as
another
case
for
this,
this
is
I
guess
more
common
is.
N
It
does
result
in
connections
failing
and
unlike
the
previous
slide
in
this
situation,
there's
no
way
to
do
a
default,
hostname
and
recover,
because
you're
you're
explicitly
getting
a
different
es
and
I
record
from
a
completely
different
provider.
So
this
is.
This
is
an
open
question
and
one
that
seems
like
a
very
difficult
design
space
to
work
in.
Q
Q
N
N
Okay,
so
requirements
for
a
solution.
You
want
to
prefer
soft
failures
too
hard
failures.
These
are
also
open
up
for
debate.
No
serialization
of
DNS
queries
is
another
potential
requirement
for
this.
If
you
have
to
do
two
DNS
queries
in
sequence,
it's
not
desirable
compared
to
right
now,
or
you
can
query
them
both
simultaneously.
V
X
Brief
I'm
sure,
yes,
just
a
question
about
the
dependency
on
the
backend
server,
so
notice.
There's
a
remark
in
the
current
draft
which
says
that
the
backend
server
can
be
unmodified
but
with
the
introduction
of
the
nonce
has
to
be
sent
back
yeah.
So
that's
a
so
I
I
guess
I
just
want
to
clarify
that
the
draft
needs
to
be
clear
on
the
dependencies
on
the
back-end
server
imports.
W
J
I
realized
the
rule
of
threes
is
quite
nice
and
you've
done
that
very
well.
Here.
Three
bullet
points
three
actual
points,
but
the
first
one,
given
the
discussion
that
we
had
earlier
in
this
session
might
have
already
happened,
and
so
I
I
suspect
that
we're
gonna
find
that
this
Charter
is
no
good
by
the
time
it
gets
approved
and
published.
If
that
first
item
is
in
there,
so
maybe
we
can
take
the
detail
s1
out
and
just
concentrate
on
the
other
things.
I
Most
likely
yeah
so
I
was
gonna,
pour
something
different,
which
was
just
to
sit
on
this
for
a
couple
months
and
then
I
mean
feel
free
to
write
any
juror
details
in
it,
but
then
we
can
and
then
sit
on
it
until
until
we
call
the
call
us
and
then
we
can
return
her
value.
My
pros
I
mean
that
there's
an
ad
right
here,
so
we
can
ask
him
what
he
thinks,
but
it's
kind
of
a
I
find
return.
You
kind
of
pain
and
I'm,
constantly
screwing
it
up
so
uh-huh.
J
W
But
that's
perfectly
fine
as
well.
I
guess
we're
interested
to
know.
If
the
remaining
issues
you
know
putting
details
aside
are
of
interest
to
the
working
group
should
be
in
scope,
should
not
be.
We
don't
have
to
necessarily
do
the
recharging
right
now.
We
can,
of
course,
wait
for
details.
1
3
be
finalized,
but
sort
of
identifying.
What
are
the
next
big
things
we
should
be
working
on.
I
think
is
a
useful
exercise.
I'm
Stephen.
L
Well,
yeah
I
mean
I,
think
maybe
leaving
this
for
few
months
might
make
some
sense
just
to
get
simplify
that
the
change
I
don't
have
a
proposal
for
how
to
do
it.
But
if
you
guys
are
clever
enough
to
figure
out
some
text
to
say
what
we
don't
want
to
do,
that
would
be
very
useful
because,
as
we've
seen
against
there
every
time
you
try
and
do
something.
There's
somebody
who
wants
to
do
kind
of
the
opposite
I
would
encourage
you
to
try
and
think.
N
Know
didn't
find
your
children
just
one
word
that
I'm
not
seeing
in
this
second
working
group
goal
is
security.
It's
I
mean
it's
part
of
the
security
area,
but
if
you're
talking
about
proposals
regarding,
say,
new
threat
models,
P
Q
etc
could
be
worth
explicitly
saying
that.
W
W
Does
anyone
have
any
other
comments,
criticisms,
etc
on
the
existing
text?
If
not,
we
can
move
on
and
you
know
we'll
discuss
when
we
want
to
actually
do
the
retiring.
Like
I
said
we're
perfectly
fine
to
sort
of
table
is
for
a
while,
while
details
one
three
four
one
three
is
finalized,
there's
no
rush,
but
just
sort
of
getting
a
feel
for
what
the
next
big
things
are
to
work
on.
What's
the
what's
the
point
here
so.
Y
H
H
So
I
want
to
go
through
a
little
bit
of
history
in
Montreal.
No
one
objected
to
the
base
case.
That
was
in
the
document,
but
two
cases
were
discussed
that
people
wanted
to
include
in
addition
to
that
base
case,
one
of
them
was
to
provide
some
proof
that
the
server
still
had
access
to
the
private
key
that
was
in
the
certificate
and
the
second
one
was
on
resumption
to
provide
a
different
certificate.
H
B
H
So
I
added
those
two
cases
in
into
the
document,
and
then
there
was
a
complaint
that
well
now
we've
gone
too
far.
It's
got
too
much
complexity.
So
the
question
is
that
I'm,
hoping
this
presentation
will
answer
is:
where
does
the
group
want
to
go
from
here?
So
just
as
a
bit
of
providing
you
enough
context
to
answer
the
questions
that
are
coming,
this
is
the
handshake
where
there
it's
for
the
initial
handshake,
where
you're,
including
a
nish,
a
pointer
to
an
external
PSK,
to
be
mixed
into
the
key
schedule.
H
Than
the
case,
where
resumption
and
you're
proving
that
you
still
have
the
key,
that
is
in
the
certificate
or
the
private
key
that
corresponds
to
the
scheme,
the
certificate.
What
is
this
one
and
when
you
are
changing
it,
you
can't
have
early
data
and
that's
what
leads
to
this
case.
So
I
have
three
questions.
I
would
like
to
have
the
chairs
ask
the
group-
and
there
are
these
three
homes,
so
I,
don't
know
which
of
the
chairs
I'm
handing
it
over
to
at
this
point.
W
I
Sucker
yeah
I
mean
I,
get
I,
guess
I
want
to
take
the
tip
before
we
do
any
other
stuff
on
it.
The
amateur
on
like
how
much
enthusiasm
there's
for
this
document
as
opposed
to
how
much
not
objection
those
for
this
document,
so
particular
I
like
to
see
other
to
ask
if
people
actually
intend
to
employ
this
so.
I
This
is
I'm,
not
sure
I
don't
like
this,
but
it's
not
on
my
limitations,
real
map
and
I
wonder
presenting
on
anybody
else's
because
I
think
I
guess
like
this
isn't
about
this
particular
just
be
clearly
so
at
this
particular
document.
But
I
feel
like
it's
working
around
a
lot
of
trouble
over
the
years
by
like
by
like
taking
just
things
that
people
didn't
have
got
to,
and
so
I
want
to
take
things.
Well,
any
people
enthusiastic
about.
L
If
you've
got
a
positive
home
for
all
three
of
these,
are
we
still
may
need
it?
Does
that
mean
that
people
still
can
later
on
decide?
They
don't
like
the
document
overall
and
don't
want
to
adopt
it.
So
is
it?
Is
it
a?
Are
you
asking
that
for
an
answer
of
the
form?
If,
if
the
working
group
were
to
do
this,
I
would
like
one
two
and
three
but
I,
you
actually
don't
want
the
work
me
to
do
it
I'm
not
saying
that's
my
position,
I'm
just
this
is
the
clarifying
question.
H
M
C
R
Rich
sauce
yeah,
but
you
know
it's
open
source
and
we
take
full
requests,
and
if
this
is
meet
somebody's
real
need,
then
it
could
show
up.
They
don't
have
to
mean
that
I'm
gonna
write
the
code
or
they've
been
you
know,
would
write
the
code.
So
it's
not
quite
a
fair
question.
I
mean
I.
Understand.
Yes,
it's
good,
but
I.
Don't
think
the
lack
of
answers
you
got
are
definitive.
I
B
I
Like
appealing
is
a
positive
good
idea,
then
you
then
of
you're
willing
to
implement
their
solicit,
someone's
importation
or
hope
somebody
else.
It'll
result
them
right
and
that's
I
mean
I
can
imagine
a
bunch
of
questions
but
I
guess
what
I'm
asking
is
for
other
people.
If
the
microphone
who
like
this
and
say,
we
think
we
should
adopt
this
and
we're
in
favor
of
it.
M
L
Nikka's
disentangle
himself,
I
think
so
I
mean
I.
Guess
there
is
a
real
need
here,
but
it
does
I
have
a
slight
concern
that
maybe
we're
being
a
bit
premature
and
trying
to
figure
assume.
We
know
that
this
will
solve
the
need.
So
you
know
it
may
be
that
do
after
having
this
type
of
competition
with
new
algorithms
and
so
on.
Maybe
there's
gonna
be
something
that
people
would
want
to
implement
much
more
than
this.
So
I
don't
know
I'm
not
against
this,
but
I.
Don't
I.
H
N
C
J
U
J
J
This
document
came
up
in
discussions
related
to
the
pipedraft
that
was
going
on
at
the
moment
as
well.
There
was
a
desire
there
to
to
use
some
combination
of
certificates
and,
and
the
pake
stuff
so
just
wanted
to
blow
your
mind
just
a
little
bit
and
expand
the
scope
even
more,
but
that's
exactly
what
I
was
thinking
right
so
yet
definitely
I
think
the
experimental
sounds
like
a
reasonable
way.
This
done
stop
thinking
about
this
way.
N
N
I
So
I
think
I
think
where
I
am
on
this.
Is
that
I
don't
think
right
now
people
have
the
energy
to
properly
analyze
2n3,
and
so
so
I
think
that
I
would
not
be
in
favor
of
taking
two
and
three
I
would
like
to
two
and
three
at
some
point,
but
I
just
I'm
like
that
sec.
How
does
it
like
how
wiped
out
everybody
is
from
like
doing
eighty,
four,
forty
six
and
presumably
would
have
a
korean
call?
I
One
details,
Mosley
and
so
I
think
I
would
I
was
like
I
would
hum
like
definitely
against
taking
two
and
three.
If
he
want
to
take,
one
is
experimental.
I
got
to.
C
Put
it
like
a
finer
point
in
this
writer
like
Russ,
wrote,
number
one
and
I
think
Martin
was
like
hey
number
two
to
be
great
and
then
Nick
said:
hey
I'd,
like
to
number
three
to.
If
Martin
and
and
and
Nick
are
willing
to
say
yeah,
we
can
wait
to
do
it
later
and,
let's
that
won't
go
through
his
experimental
and
was
a
lawless
hums.
That
hum.
C
N
C
C
Please
some
now,
if
you
do
not
so
that's
rough
and
we're
gonna,
have
it
go
as
experimental
I.
G
C
E
Z
Hello
I
represent
you
today,
the
transport
layer,
security
extension
to
support
I,
Triple
E,
and
it's
a
certificate
with
it
on
vehicular
network,
so
the
agenda
would
be
I
will
give
some
motivation
and
the
objective
our
of
our
extension
then
an
overview
and
also
some
use
cases
how
and
why
we
are
using.
We
need
this
extension.
Finally,
I
will
give
some
details
of
how
we
made
it
under
the
raft.
So
competitive,
intelligent
transport
system
is
high
mobile
environment.
Z
We,
with
with
a
limited
bandwidth,
that's
why
x.509
certificate
is
not
optimized
for
delay,
sensitive
and
limited
bandwidth,
its
application.
That's
why
your
on
C,
80s
and
vehicular
environment?
We
are
not
using
x5
online
and
we
switch
it
for
I,
Triple,
E
and
HC
certificate.
I
Triple
E
is
1609
point
to
Eckstein
1609
point
two
and
the
81
is
one.
Oh
three,
oh
nine,
seven
and
I
have
to
mention
here
that
the
81
is
just
the
profile
of
the
I
Triple
E.
Z
Some
use
cases.
We
can
use
this
extension
for
self
or
for
uploading
logs
from
vehicle
to
to
server
of
log
R,
to
make
updates
of
vehicular
software
r2
to
make
a
date
of
configuration,
just
the
configuration
of
of
software
on
embedded
on
the
vehicle,
and
it
can
be
used
also
for
connected
cloud
services
connected
and
fun
payment,
and
it
can
be
used
for
authentication
between
client
and
server
server,
for
example,
of
the
parent
company
for
car
manufacturers,
servers
and
wireless
electric
vehicle
charging.
Though.
Z
Z
So
just
just
to
add
one
information
about
privacy,
privacy,
a
consideration
made
by
this
kind
of
safety
key.
In
fact,
it's
provide
privacy
relying
to
temporal
and
the
locality
and
geographical
and
temporal
validity
criteria
and
minimizing
the
exchange
of
private
data,
the
F.
So
if
this
this
draft
would
be
accepted,
we
will
ask
enough
for
a
new
value
for
to
register
this
certificate,
a
still
a
certificate
that
new
TLS
certificates
I'd.
Thank
you.
AA
Just
honest
I
was
I
was
wondering
why
you
conscious
registered
a
value?
Is
there
really
to
be
established
to
register
in
such
a
way
that
requires
an
RFC
for
in
this
group
specific
lines,
so
why?
Why
can't
you
just
do
that
like
it
sounds
like
it's
great
you
use
TLS
1.3
in
or
DTLS
monetary
in
a
vehicular
environment.
AA
AA
No,
you
apparently
there's
some
work
going
on
in
the
I
Triple
E
on
this
con
future
star.
In
your
specification
at
the
end,
like
send
a
request
to
Ayane,
there
will
be
an
expert
review
and
then,
with
this
new
value
being
added
to
the
registry,
I,
don't
think
there's
any
other,
there's
a
barrier
on
defining
a
new
certificate
that,
like
you,
don't
need
a
ITF
document
to
do
that.
K
Z
AA
You
know
because
I
I
was
working
with
raw
public
key
some
other
guys
here
and
I.
Remember
that
at
that
time,
I
didn't
have
to
do
anything.
It
was
just
to
be
added
some
other
extensions
that
why
we
had
to
add
write
an
a
draft
for
it.
Why
didn't
later,
which
later
became
an
RFC
but
I?
Think
in
your
case,
since
you
only
need
this
well,
he
registered
I.
Don't
think
you
need
to
do
anything
in
the
IDF.
Besides,
writing
sending
a
mail
Ayanna
to
add
that
today
already.
R
G
C
B
C
You
don't
even
need
to
go
through
the
rest
of
the
process
or
get
us
to
adopt
it.
You
don't
even
need
a
draft.
The
thing
that
is
interesting
in
this
draft,
though,
is,
if
we're
good
we're
gonna
progress.
C
I
think
that
I
probably
takes
some
of
the
things
out
like
there's
the
security
considerations,
there's
like
a
recommendation
for
a
minimal
profile
that
doesn't
really
kind
of
seem
to
fit
in
this
draft
I
think
that
would
be
better
in
an
IP
wave
document
or
somewhere
else
to
specify
that
over
there,
because
this
is
like
this
is
the
steals
extension
thing
you
know
if.
C
C
AA
C
Great
disgust,
but
the
point
I'm
saying
is
the
ones
that
are
already
defined
and
you're
saying
when
you,
when
you
do
a
connection,
you
should
only
be
using
these
extensions
that
I
don't
know
that
that
even
applies
here
and
that
in
the
document
just
doesn't
make
any
sense
to
me.
It's
a
pro
it's
a
profile
essentially
of
how
you
would
do
it
and
I
think
that
goes
someplace
else.
It
doesn't
belong
in
this
particular
extension
document.
C
The
other
thing
is
I
think
you
would
put
a
big
ole
warning
in
the
security
considerations
to
say:
hey,
look:
we
define
new
certificate
formats,
which
also
have
new
processing
rules.
They
are
different
than
what
is
done
in
regular
x.509
and
Dragons,
be
there.
They
finally
got
fudged
or
fuzz
enough
to
kind
of
work
right
and
we
kind
of
know
the
pitfalls
at
this
point.
These
are
new
I've,
never
looked
at
them.
I
sure
hope
they
work
properly.
Sometimes.
B
AB
H
Z
W
Right,
so
this
is
something
we
talked
about
right
near
the
end
of
finalizing
TLS,
1.3
particular
there's
some
oddities
around
external
PSK
and
how
you
use
them
properly
for
this
new
version
of
the
protocol.
So
they
were
to
basically
design
basic
designs
that
were
discussed
in
on
the
list.
One
is
from
David
been
describing
Universal
vs
case.
Another
one
was
his
key
import
or
idea
the
ekor
and
I
had
talked
about.
W
So
this
is
just
kind
of
getting
that
down
in
writing,
and
hopefully
we
can
kind
of
make
a
decision
as
to
which
two
we
are
fond
of
I
guess
you
may
want
to
address
this
particular
issue
going
forward,
so
just
some
pointer
to
the
facts.
They're,
not
four.
Four
six
that
says
you
know
if
you're
going
to
use
a
PSK
make
sure
you're
gonna
use
it.
W
Our
PSK
with
a
single
hash
function
entails
1.3,
whereas
ds-12
has
no
particular
restriction,
and
we
want
to
make
sure
that
if
we
are
to
use
PS
case
that
were
provisioned
for
1.2
or
other
versions,
the
protocol,
it's
safe
to
use
and
1.3,
and
ideally
do
it
in
such
a
way
that
you
don't
have
to
tie
details
of
TLS
to
the
provisioning
processes.
Vs
case
you
can
kind
of
just
reuse
the
machinery,
that's
there
and
then
sort
of
stuck
them
in
Steel's
1.3
and
use
them
as
such.
W
W
You
know
a
particular
like
a
protocol
in
which
you
would
import
the
the
PS
case.
So
if
you're
using
TLS
1.3
over
tcp,
the
label
might
be
TLS.
1
3
using
TLS
1.3
in
the
context
of
quakin
might
be
quick
so
on,
and
you
have
a
particular
like
I
said
a
particular
hash
algorithm
that
you
want
to
use
this
particular
PSK
with
you.
Might
the
basic
idea,
the
importer?
Is
you
form
the
identity
of
that
PSK
as
the
topo?
W
The
top
will
affect
the
value
of
all
these
fields,
and
you
use
that
to
derive
a
per
hash
function.
Hash
algorithm
PSK,
but
you
would
then
use
to
compute
binder
values
and
send
to
the
server
and
the
client
hello.
So
finding
out
how
many
hash
relatives
you
support
in
your
particular
stack,
you
may
have
one
or
more
actual
PSK
finder
values
that
are
sent
in
the
client,
hello
to
the
server
seems
pretty
straightforward.
W
Some
constraints
for
this
particular
importer
design,
or
that
if
you're
going
to
use
it
for
early
data
SPECT
clearly
can
indicates
that
you
need
to
know
information
about
the
context
in
which
you're
going
to
use
it
so
values
for
a
LPN.
Another
quick
transport
parameters.
The
draft
right
now
is
sort
of
just
kind
of
hand
wavy
in
that
particular
spec.
So
you
know
we
could
certainly
do
some
thing
to
improve
it.
W
There
is
the
issue
that
was
raised
on
the
list
with
respect
to
privacy
in
a
privacy
respected
the
labels
that
are
being
used,
but
perhaps
that
was
my
own
fault
and
not
being
clear
and
what
the
actual
labels
are.
So
they
were
really
intended
to
diversify
importing
PS
case
for
different
protocols,
be
it
quick
or
TS,
1
3
or
whatever
you're
going
to
use
TLS
1,
3
4,
not
as
identities
associate
with
external
PS
case.
W
The
privacy
issue,
with
external
PS
case,
is
still
very
much
an
issue
that
potential
users
are
thuggin
all
through
this
whole
problem
and
there's
not
really
much
specific
details
around
how
you
would
how
these
are
sort
of
compatible
with
TLS
1.2.
The
TLDR
is
that
you
don't
really
do
anything
specific
retail
1.2
there
have
been.
AA
K
AA
Yeah
because
otherwise
you
would
suddenly
have
you
have
a
client
that
doesn't
have
that
extension
that
you're
proposing
and
then
a
server
that
has
it
and
then
but
it's
the
same
key
identity
issues
that
gets
confusing.
Yes,
would
that
go
into
the
TLS
stack
or
detail
s
stack
or
would
that
stay
at
the
application
layer?
When
you
say
that
what
you
mean
that
the
implementation
of
your
document
of
this
inside
the
geo
stack?
Okay,
yes,.
W
I
mean
clarify,
but
that
my
understanding
was
that
Maya
implement
the
invitation
that
we
put
together
was
inside
stack.
You
would
in
importing
PSK
you
be
just
be
given
an
external
identity,
a
PSK
associated
with
it,
and
then
the
stack
internally.
We
do
the
transformation
and
dryable
he
escapes
afterward.
Oh
I,.
W
I
W
I
I
AA
Just
worried
about
sort
of
exactly
this
compatibility
between
a
client
implementing
something
a
server
implementing
some
party,
not
implementing
that
extension
and
the
other
one
does,
and
so
you
get
this
weird
error
cases
up
if
PS
case,
like
we
already
had
previously,
both
appears
case
when
people
use
different
encoding
at
the
user
interface
and
then
it
just
they're
just
failures
and
you
have
to
go
through
the
lock
of
the
TLS
handshake
to
figure
out
what
what
the
failure
case
is,
because
the
error
messages
in
TLS
for
PSK
are
not
very
enlightening.
Yeah.
W
Something
that
you
consider
I
mean
you
might
be
possibly
consider
some
other
signals
to
indicate
that
this
client
is
using
this
particular
extension,
and
maybe
the
server
can
operate
on
that,
and
maybe
that
will
help
your
debugging
issue.
What
yeah
so
there's
a
lot
of
things
missing
from
the
container.
M
B
M
So
miss
just
a
fact:
you've
got
you,
so
if
it's
like
a
mismatch
between
one
side
implements,
the
other
side
doesn't
implement.
It's
just.
You
know,
you're
getting
a
PSK
identity
offered
that
you
don't
recognize
yeah
and
you
know
yes,
the
durable
behavior
in
this
case
is
not
super
great,
but
it's
not
catastrophic
either.
Yep.
J
Yep
sometimes
I
assume
that
in
in
the
case
where
you
plug
one
of
these
in
you're
plugging
this
entire
struct
in
as
the
identified
entity,
not
just
the
first
piece
of
it.
So
it's
it's
it's
possible
for
someone
who's
when
there's
a
confusion
between
the
two
endpoints,
the
identifiers
that
are
used
for
the
keys
are
different,
because
this
is
this
is
an
extra
in
it.
So.
W
I
It's
all
set
yeah
I
guess
so,
let's
take
a
step
back,
a
conventional
kills.
1
3,
you
know
stack
right
there
when
you
have
today.
If
you
had
PS
case,
what
it
would
do
is
it
would
take
a
external
PSK
and
it
would
be
attached
to
it
would
be
the
the
key
to
using
the
hash
function
to
use
the
TLS,
handshake
and
a
label.
I
Those
are
the
triplets
árbol
things
you
get
right
in
a
and
so
the
there
there
are
two
implementations
options
for
doing
this,
and
with
this
option
one
is
to
externally
generate
a
new
set
of
PS
k's
from
that
initial
triple
that
have
that
that
each
have
that,
each
of
which
itself
is
a
triple
of
with
the
new
pit
attached
hash
function
and
to
show
them
the
interface
exactly
as
exactly
as
they
currently
work
option
and
they
have
names,
are
synthesized
in
the
way
Chris
indicated
option
two
is
to
have
a
new
interface
on
the
outside.
I
W
W
The
design
basically
takes
the
external
PSK
uses
it
to
derive
a
new
PSK
to
compute
the
binder
values
in
the
client,
hello,
and
if
the
server
does
indeed,
you
know,
verified
the
binder
and
negotiate
cyber
sweetie.
You
then
afterwards
derive
a
purr,
cipher
suite
or
a
new
PSK
or
using
the
key
schedule
based
on
the
negotiated
cipher
suite
for
the
hash
algorithm
associated
with
the
cipher
suite,
so
in
effect,
you're
sort
of
changing
what
PSK
value
is
injected
to
the
key
schedule.
W
But
the
benefit
is
that
you're
only
sending
exactly
one
vsk
over
the
wire,
which
is
the
sort
of
fundamental
comparison
difference
between
the
two.
So,
with
the
embroiderer
proposal,
you
have
an
inflation
in
the
number
of
PS
KS
that
you're
actually
the
binders
that
you're
actually
sent
over
the
wire
you're,
not
changing
the
protocol
in
any
particular
way.
With
universal
feeis
case,
you
are
changing
some
of
the
key
schedule
details
but
again
you're
not
inflating
the
climb
hello
unnecessarily
so
which
one
we
prefer
is
sort
I,
don't
really
care.
W
M
All
right,
thank
you.
No,
because
so
I
mean
we
should
be
clear
about
what
we're
actually
doing,
if
you're
sending
multiple
PS
case
over
the
wire
you're,
sending
the
PS
K,
which
is
you
know,
or
what
so
you're
saying
that
the
label
and
then
you're
also
sitting
in
the
binder
yeah
and
the
binder,
is
the
full
width
of
the
hash
output.
And
so
you
know
if
you're
talking,
you
know,
that's
minimum
33
bytes.
M
You
know,
because
you
got
the
length
field
for
each
binder,
you're
sending
and
you
more
for
the
larger
hashes,
and
so
you
know,
if
we're
only
gonna,
be
sending
sha-256
and
sha-512
hashes,
currently
with
TLS
one
two
three
sacred
suites
associated
to
them.
You
know,
maybe
that's
not
so
bad,
but
if
we
start
getting
into
know
we're
sending
six
things
on
the
wire,
that's
kind
of
large
and
you
might
start
to
impact
our
decisions
yeah.
Absolutely
something
is
there.
I
I
Felt
like
University
s,
cases
like
wheat,
in
which,
if
I,
wants
to
tell
us
for
something
which
I
didn't
think
was
like
actually.
B
I
Valuable,
as
perhaps
other
people
did
so,
the
design
of
the
importer
specifically
designed
not
to
do
that
by
all
steal
us
so
I
guess
you
know
I'm
sort
of
like
a
lukewarm
on
the
whole
thing,
but
like
I'm
negative
on
I'm
negative
on
your
40s
today,.
W
M
M
W
S
W
W
More
little
plug
sort
of
orthogonal,
especially
with
respect
to
the
issue
of
privacy.
It
was
various
on
the
list
kind
of
wanted
to
discuss
this.
Very
briefly.
There
is
this
sort
of
issue
with
tickets
and
resumption
PSK
is
in
that
you
may
use
them.
Servers
may
use
them
sort
of
traffic
clients
across
resumption
attempts,
depending
on
your
perspective,
that
may
or
may
not
be
a
good
thing
say.
W
W
In
our
implementation,
in
our
system,
Apple's
implementation
in
system-
this
is
not
a
big
performance
it
at
all.
So
that's
what
we're
doing
other
option
is,
if
you
want
to
resume
and
send
some
early
data
potentially
use
the
semi
static
approach
was
it
has
not
yet
seen
significant
Syrian
Alice's
John
to
encrypt
the
early
data
with
a
public
key
that
has
shared
amongst
many
people
instead
of
a
PS
ksoc
with
the
ticket
that
share
beat
specifically
between
one
client
and
one
server
that
has
some
nice
properties.
W
We
also
had
this
crazy
idea
to
at
one
point,
use
the
view
of
the
fort.
Whatever
you
want
to
call.
It
I
think
that's
how
I
pronounce
it
barb,
instead
of
simply
recover
the
encryption
of
a
PS
gate,
but
to
use
them
to
derive
PS
case
in
an
anonymous
way,
and
you
potentially
use
that
to
resume
and
send
really
data
as
well.
W
I
Yeah,
so
right
so
I
guess
I
think
that
this
is
not
a
crisis.
I
think
if
we
do
anything,
we
should
well.
We
do
to
at
some
point:
I
am
having
trouble
wrapping
around
how
number
three
works,
perhaps
perhaps
yeah
there.
I
I
I
I
think
I
mean
one
is
fine,
I,
don't
know,
I,
don't
think
we're
gonna.
Do
it
hey
I
guess,
like
I
guess
I
I
I
I.
I
think
that
like
justjust
in
the
setting
of
like
it's
just
because
of
the
way
like
the
system
is
kind
of
constructed
like
there's
like
87,000
state
vectors
and
so
like
trying
to
like
remove
this
particular
one.
While
I
not
fixing
all
the
other
ones,
so
I
got
pretty
helpful
and
so
I'm.
J
I
I
Gonna
say
is
like
that.
The
right
thing
to
do
is
like
when
you,
when
you
decide
to
when
you
decide
to
create
a
cut
point
like
you
flush
all
your
state
that
includes
this,
and
you
know
II,
just
don't
resume
at
all
and
like
saying
like,
oh
I'm
gonna
like
send
my
like
my
CP
cookies,
but
I'm,
not
gonna,
like
semi
TLS,
like
session
ideas
like
doing
all
so
like
like
French.
Are
it's
like
much
more
sensitive,
a
clean
cut?
J
W
J
Got
a
key
identifier
in
there
for
it
obviously,
and
that
key
identifier
is
state
that
the
client
is
now
mirroring
back
to
the
server,
so
I
think
I
think
proposition
number
one
is
really
the
only
feasible
one.
That's
the
sort
of
thing
that
way
of
welcome
to
implement
and
I
I,
don't
know,
I,
don't
know
that
this
is
used
as
a
motivate
motivation
to
do
the
second
one,
although
we
might
want
the
second
one.
For
other
reasons,
yeah.
W
So
I
second,
one
in
particular,
still
very
much
a
work
in
progress.
We're
still
trying
to
actually
show
that
the
you
know
using
semi
static
for
the
regular
tails
handshake
is
safe
and
we're
actually
making
some
progress
there
with
tiwa
and
mozilla,
but
yeah
doing
it
for
early
data
is
still
something
that
we
have
not
really
looked
at
and
we
just
have
really
good
feeling
hearts
that
it
will
be
safe.
That's
what
matters
Christian.
E
Chris
Christian
Rita
man,
Chrissa
I,
never
be
disappointed
because
you
present
here
a
lot
of
mitigations
for
the
resumption
issues.
My
Dussel
risk
that
sees
that
if
you
have
a
PSK,
you
need
a
big
identifier
that
PA
identifier
uniquely
identifies
the
key
that
you're
gonna
use
and
as
such
is
a
tracking
device.
So
if
you
reuse
vsk
identifiers
multiple
times
you
get
talked
yeah.
W
So
this
is
like
I
was
saying
when
I
transition
to
the
slide.
This
is
sort
of
authorial
I.
Just
have
this
like
here
in
particular,
to
talk
about
privacy
issues
with
presumption,
not
privacy,
issues
you
to
dump
them
with
extra
PS
case
and
the
identifiers
and
labels
associated
with
them.
So
this
is
for
the
normal
like
forget
that
this
is
actually
a
slide
in
the
external
PSK
presentation.
This
is
just
sort
of.
Are
you
going.
M
W
N
Think
hi
to
Martin
just
to
address
your
comment
about
the
th
secret,
not
knowing
whether
this
is
rotated
I
believe
you're,
pointing
here
the
whole.
The
whole
point
of
this
is
is
at
a
network
adversary
in
which
both
the
client
and
the
server
are
trusted.
So
you
would
trust
the
client
and
server
to
you
know
not
the
server
not
to
try
to
trick
the
client
into
losing
its
anonymity.
But
here
you're,
looking
for.
N
T
T
Right
so
that's.
C
The
end
of
it
sorry
for
the
quick
detour
with
the
presumption
PS
case,
but
can
we
get
a
sense
of
the
room
if
we
had
to
go
down
the
two
approaches,
whether
there's
two
options
right,
basically,
one
if
I
can
is-is-is
is
bigger.
Client
handshakes,
the
other
one
is
mucking
with
the
key
schedule.
Two
people
have
a
preference
if
we
were
to
support
this,
whether
they
prefer
accepting
the
bigger
handshakes
or
mucking,
and
we
could
have
both,
but
we
probably
do
not
gonna
try
for
that.
It's.
J
W
C
W
D
M
D
AA
I'm
going
into
the
next
working
group
meeting
later
this
week
and
there
I
will
be
told
that
TLS
and
DTLS
103
is
awful.
We
can't
use
that
because
it's
so
heavy
and
we
shave
off
one
byte
and
that's
why
we
need
to
crank
out
and
completely
new
sterilization
effort,
and
then
it
would
be
promoted
in
all
sorts
of
other
organizations.
Just
because
of
that
argument
makes
me
implement
the
two
different
protocols
that
essentially
do
the
same
thing.
You
know
what
I'm
getting
to.
J
J
The
the
point
that
people
are
making
here
is
that,
in
a
lot
of
these
cases,
you've
got
a
constrained
implementations.
They
only
implement
one
cipher
suite
you're.
Only
ever
gonna
have
one
hash,
so
you're
never
going
to
have
to
run
into
this
problem
with
the
the
binders.
Now
it
might
be
that
you
want
to
define
something:
a
new
cipher
suite
that
has
a
shorter
binder
so
that
you
can
have
save
even
more
bytes,
but
that
will
require
some
more
analysis,
all
that
business,
but
the
key
right
right.
J
AA
So
since
you
looked
at
this
crits
for
one
hash
algorithm,
what
is
the
by
difference
between
the
two
options
before
I.
AA
C
D
G
C
W
W
So
the
initial
design
we
came
up
with
was
basically
wait
for
clients
to
requests
tickets
on
demand
post
handshake.
There
are
several
issues
with
this.
In
particular,
we
don't
I
think
as
a
whole.
We're
not
really
fond
of
post
handshake
things
for
censoring
messages.
In
particular,
this
would
have
been
the
first
one
or
the
first
draft
which
introduced
a
client
originated
or
client
initiated
post
handshake
message,
which
is
sort
of
okay
yeah
right.
Sorry,
it
is
sort
of
a
non-trivial
protocol.
Change
is
adding
this
request
response,
so
that's
potentially
undesirable
and
then
there's
a
story.
W
It's
not
clear
how
you
actually
buffer
these
reads
and
writes
of
Depot
centric
messages
on
the
client
side,
potentially
especially,
if
you
have
them,
arrive
out
of
order
from
the
server,
so
the
feedback
we
got
from
the
room
is
that
potentially
this
is
useful.
It
might
be
simpler
if
you
just
have
the
client
tell
the
server
upfront
how
many
tickets
it
actually
needs,
and
then
the
server
can
choose
a
use
that
as
a
hint
to
determine
how
many
to
vent
back.
W
So
if
you
are
server,
who
only
spends
two
tickets
and
the
client
says
he
only
needs
one,
then
the
server
could
potentially
just
some
one
ticket
instead
or
is
it
the
client
says:
I
need
250
five
tickets,
because
I'm
going
to
be
doing
a
lot
of
resumption
and
server
only
supports
to
the
server
can
still
send
back.
Call
me
too,
it's
simply
just
a
hint
that's
sent
in
the
client
below
in
a
new
extension.
That
says.
Please
give
me
this
number
of
tickets
I
expect
to
use
these
in
the
future
connections.
W
In
the
case
and
for
the
Apple
case
in
which
you're
using
or
racing
TLS
connections
across
different
address
families
across
different
network
interfaces,
we
would
request,
for
example,
for
and
hopefully
we
would
get
those
so
we
could
not
use
the
same
ticket
across
each
of
these
particular
interfaces
and
address
families
if
we're
resuming
connection
later
on
orthogonal
to
this
whole
issue
is
that
of
post
and
check
buffering
so
Thank
You
Martin
for
sort
of
bringing
this
quick
issue
to
the
list.
Are
we
sharing
a
pointer
to
it?
W
There's
also
the
issue
of
you
know
these
messages
potentially
arriving
out
of
order,
so
this
client
would
have
to
buffer
all
these
massive
new
session
ticket
messages,
which
may
not
be
great
also
that
there's
no
way
currently
could
restrict
the
handshake
message
size
that
is
sent
from
client
or
server
in
the
protocol.
Maybe
that's
something
we
just
do
in
a
separate
draft
that
are
now
an
extension
to
negotiate
that
it
seems
sort
of
orthogonal
to
this
particular
proposal
here,
but
certainly
an
issue
to
consider
yeah
Martin,
not.
J
K
J
T
So
super
Langer
I
would
like
to
point
out
that
there's
a
slight
distinction
between
the
number
of
session
tickets,
they're
sending
and
the
size
of
each
individual
session
ticket
so
that
the
handshake
message
size
limit
would
that
we
discussed
would
apply
to
the
size
of
an
individual
session
ticket.
Yes
versus
the
number.
Yes
I.
I
Mean
so
easy
I
mean
these
general
issues
came
up
both
and
quick
and
tell
us
it's
effectively
possible
given,
like
any
kind
of
you
know,.
I
Fragmentation
reassembly
protocol
to
force
the
other
side
like
attempt
it
buffer
like
an
arbitrary,
my
crap
in
that
like
I,
mean
the
only
way
I'm
aware
of
this
really
of
dealing
with
this
is
like
I'm
checking
the
maximum
amount
of
outstanding
data.
Ievo
control
I
mean
like
not
as
I
can't
shake
message
size
at
the
issue
so
much.
It's
probably
handshake
message
size
but,
like
martin
says
you
can
have
that
what
are
messages
so
ultimately,
it's
like
if
you
actually
want
to
seduce
me
about
this.
I
I
You
mean,
but
by
this
problem,
hung
like
I'm,
certainly
aware
of
like
why
you
want
flow
control
for,
like,
like
you,
have
a
bunch
of
concurrent
HTTP
connections,
but
it's
a
practical
matter
like
I
strongly
suspect
you
can
set
like
really
quite
narrow
limits,
I
like
what
you
lot
of
people
to
do
and
if
they
violate
them
just
like
half
the
phone
I,
don't
think
I
mean
hey
the,
but
that
is
a
practical
matter.
The
amount
of
outstanding
data
should
be
relatively
modest
and
so
like.
I
If
you
said
like
any
reasonable
limit,
you
should
be
able
to
just
deal
with
it
yeah
so
I,
I,
guess
I.
Think
I
was
opposed
like
h2
or,
like
really
wasn't
for
another
foot,
control.
I.
Think
if
you
were
to
be
like
I,
don't
want
more
than
32
kilobytes
of
a
standing.
It
like
you've
actually
been
a
pretty
fine
situation
more
than
that
I'm
gonna.
Hang
you
up
that.
T
And
kind
of
book
on
yourself
there
yeah
suppose
I
I,
don't
know
whether
we
should
be
discussing
that
particular
issue
at
the
moment.
There's
a
long
diarrhea
die
have
about
this
and
the
quick
mailing
list
about
flow
post,
tantric
flow
control
and
that's
a
whole
discussion
which
will
be
painful
to
have
so
probably
we
should
keep
those
to
this
if
we
want
to
make
progress
in
this,
just
keep
those
two
separate,
I'm
good.
M
T
M
W
C
We
see
a
show
of
hands
who
have
read
the
document.
Yeah,
that's
actually
not
bad.
Can
we
get
a
hum
for
those
of
you
who
would
support
adopting
it
as
a
working
group
item.