►
From YouTube: IETF115-TDD-20221107-0800
Description
TDD meeting session at IETF115
2022/11/07 0800
https://datatracker.ietf.org/meeting/115/proceedings/
A
B
B
A
A
A
A
So
if
you
are
sitting
in
a
room
called
Kensington-
and
you
do
not
see,
people
probably
are
in
Kensington
2
or
Kensington
3.,
which
is
very
confusing
because
when
you
first
cut
the
stairs,
you
see
Kensington
and
you
walk
in-
and
it's
not
here.
So
if
there
are
not
a
bunch
of
people
in
the
room
with
you,
you're,
probably
in
the
wrong
place,
get
up
walk
down
the
passageway
with
all
the
glass
and
then
turn
left
already.
So
hi
welcome
to
the
technology
deep
Dives
on
quick,
I'm,
Warren.
A
And
let's
skip
to
the
next
slide,
this
is
the
ietf
note.
Well
we're
the
first
sort
of
like
official
sessions,
so
it's
entirely
possible.
You
have
not
seen
this.
You
should
probably
read
this
and
figure
out
what
all
it
means
and
talk
to
Legal
Etc,
if
you
don't
know
what
it
means
but
Yep.
This
is
our
ietf
note
well
and
thank
you.
B
So
I've
actually
had
this
question
in
the
hallway.
A
lot
so
do
I
have
to
come
to
the
technical
Deep
dive
on
Monday
and
on
Tuesday.
Well,
that's
really
early
both
days,
it's
even
earlier
on
on
Tuesday,
actually
at
7
30
tomorrow
and
you
know,
I
was
asked.
Okay,
that's
a
joke
right,
no
I
mean
it
might
be
a
joke,
but
it's
also
the
truth.
B
B
B
C
Have
to
stand
in
the
spot,
I
think
I.
Do
no
I,
don't
we'll
see
the
camera
follows
me
well.
Thank
you.
Thank
you,
everybody
for
being
here
early
this
morning.
Hopefully,
hopefully
this
talk
will
wake
you
up.
If
it
doesn't
I'll
ask
Martin
to
wake
you
up,
but
anyways.
Let's
get
started
with
this
thing.
Are
we
doing
question
and
answer
everything?
Q,
a
long
side?
What
are
we
doing
with
q?
A.
C
Be
tomorrow,
so,
if
you
have
any
questions,
write
them
down,
you'll
forget
them
through
the
day
and
ask
us
tomorrow
or
catches
in
the
corridors,
so
I'm
going
to
start
with.
Just
this
brief
agenda,
it's
basically
what
is
quick-
and
this
is
for
well
I'm-
going
to
talk
about
Quick's,
immediate
value,
proposition
and
I'm
going
to
talk
about
really.
C
What
is
quick,
enable
next
slide,
so
the
subtext
here
is
that
the
first
piece
is
simply
a
short
primer,
a
very,
very
short
primer
on
Quake
I
can't
do
more
than
that,
and
we
want
to
talk
about.
How
did
we
get
the
world
interested
in
this
like?
What
did
we
do
to
make
the
world
interested
in
this
in
this
particular
technology?
And
finally,
what
was
the
real
goal?
What
was
the
thing
that
we
were
really
wanting
to
do?
C
What
did
we
set
out
to
do
from
the
get-go
next
slide,
so
before
I
get
going
on
to
Quick,
who
am
I?
I
am
janayagar
I'm
VP
of
infrasection
Network
Services,
said
fastly.
I
am
an
editor
of
the
ID
of
quick
specifications.
I'm,
a
chair
of
the
iccrg
irtf
iccrg
research
group
and
I've,
worked
on
transport
for
for
way
longer
than
I
care
to
remember
and
on
quick,
also
for
way
longer
than
I
care
to
remember,
but
that's
me
next
and
now
on
to
a
short
primer
on
quick
next
slide.
C
I'm
gonna
tell
you
this.
This
is
going
to
be
a
very
short
primer.
There's
not
going
to
be
I.
Don't
have
a
lot
of
slides
here
talking
about
the
details
of
the
protocol,
the
details
of
the
bits
we've
done,
I
and
others
have
done
talks
on
these
in
various
places.
So
if
you
go
on
YouTube
and
do
a
search,
you'll
find
a
bunch
of
these
things.
C
So
my
goal
here
is
not
to
go
into
the
details
of
this,
but
to
give
you
a
a
base
from
where
you
can,
you
can
dig
in
and
and
get
deeper,
but
I'm
just
going
to
start
off
by
saying
quick
is
a
new
transport
protocol.
Now,
if
you
look
at
this
picture,
this
sort
of
has
a
depiction
and
Martin's
going
to
come
in
thrash
this
picture
and
say:
well,
that's
not
quite
how
this
works
later.
C
So
that's
that's
fun
for
later,
but
this
is
roughly
a
schematic
understanding
of
where
quick
sits
in
sort
of
the
protocol
stack
so
to
speak.
We
have
the
TCP
TLS
and
HTTP
protocols
in
the
traditional
stack
and
where
quick
sits
is
basically
parallel
to
TCP
and
TLS
and
sum
of
http.
So
yes,
it's
weird,
but
that
was
kind
of
the
the
it's
all
weird.
It
was
just
a
compression
of
multiple
layers
so
to
speak,
and
TLS
sits
sort
of
within
quick,
but
it's
not
within
quick.
C
However,
it
sort
of
does
sit
within
quick
in
in
depending
on
how
exactly
you
look
at
it,
but
that's
sort
of
the
layering
picture
here.
It
is
deliberately
compresses
multiple
layers
and
it
deliberately
sits
at
these
in
these
spaces,
because
the
goal
here
was
to
accelerate
and
deploy
something
that
we
could
for
the
web
next.
C
So
what
are
these
these
features
of
quick
that
really
made
it
viable
and
useful
for
the
web?
Well,
first,
it's
multi-streamed
multi-streaming
is
a
very
powerful
feature.
It's
a
very
powerful
service.
The
idea
here
is
that
you
get
within
one
end-to-end
connection.
You
get
multiple
ordered
byte
streams.
Now
this
is
not
just
multiple
ordered
byte
streams,
it's
a
more
General
abstraction.
Now
this
works
really
well
for
the
web,
because
the
web
has
that
every
website
has
a
lot
of
objects.
They
are
all
multiple
effectively
parallel
independent
objects
and
so
on.
C
But
this
is
a
more
General
abstraction
streams
are
designed
to
be
lightweight
they're,
designed
to
be
built
and
toned
down
rapidly
efficiently,
and
if
your
implementation
does
it
right,
you
can
use
this
as
even
a
message
abstraction,
so
you
can
think
about
this
as
a
protocol
that
Inc
that
gives
you
a
message
abstraction
in
the
form
of
streams
and
for
the
transport
nerds
among
you.
You
can
build
partial
ordering
on
top
of
this
thing
or
you
can
build
complete
ordering
inside
this
thing,
so
you
have
those
degrees
of
freedom
with
multi-streaming
next
slide
foreign.
C
C
This
doesn't
necessarily
mean
that
the
protocol
has
to
live
in
user
space.
However,
remember
that
if
you
wanted
to
build
something
on
top
of
Ip,
you
are
necessarily
stuck
to
being
inside
the
kernel,
and
that
is
a
big
problem
for
us.
Also
in
terms
of
building
deploying
shipping
things
so
being
on
top
of
UDP
gave
us
two
significant
benefits.
One
of
them
was
that
we
could
get
through
the
internet
as
it
as
it
as
it
is
with
middle
boxes
and
firewalls
and
everything
else
and
it
allowed
us
to
deploy
in
user
space.
C
So
those
were
two
significant
benefits,
which
is
why
we
use
them.
However,
it
requires
us
to
recreate
a
bunch
of
TCP
functions
on
top
of
it,
so
we
had
to
redo
all
the
TCP
functions
on
top
of
this,
but
we
didn't
simply
redo
them.
We,
we
did
a
better
job
of
doing
them,
because
you've
learned
from
the
past.
We
we
wanted
to
incorporate
all
the
learnings
of
TCP
and
we
did,
and
importantly,
quick,
has
encryption
baked
in
this
means.
C
Data
or
everything
that
is
carried
by
the
quick
protocol
and
quick
headers
are
all
protected,
and
this
uses
Steelers
1.3
for
key
negotiation,
and
this
is
basically
a
really
important
premise
and
I'll
come
back
to
this
in
a
moment
and
again,
the
Martin
is
going
to
go
into
more
detail
on
exactly
how
this
is
done
in
in
in
quick,
but
this
was
really
important
to
us.
Why
was
this
important
to
us?
Well,
of
course,
it
was
important
to
us
to
protect
the
metadata.
C
We
know
today
that
if
we
were
to
design
protocol
that
was
not
fundamentally
protected.
That
seems
like
we're,
not
learning
the
lessons
of
the
past
20
years,
so
we
did
that,
but
there
was
an
even
more
important
lesson
here
or
an
even
more
important
reason
for
doing
this
middle
boxes.
Ossify
protocols
that
are
exposed
we
did
not
want
quick
to
be
ossified
TCP
is
today
ossified
many
other
protocols
that
have
been
deployed
in
the
wild
in
plain
text
are
completely
ossified.
C
C
Oh,
that's
the
next
one,
so
with
sorry,
go
back
one
slide
so
with
baking
and
encryption.
What
we
were
able
to
do
is
basically
say
that
only
the
endpoints
can
really
understand
and
change
the
metadata,
the
headers
in
the
protocol,
as
well
as
the
body
and
that's
an
important,
important
thing,
because
now
middle
boxes
are
unable
to
change
the
headers
or
to
obfuscate
or
to
to
mess
with
the
headers
or
even
read
the
headers.
C
C
So
that
is
my
rough
introduction
into
quick
and
I'm.
Sorry,
if
you
didn't
see
all
the
header
bits
that
you
wanted
to
see
and
I
don't
want
to
do
that
here
to
you
early
in
the
morning
on
Monday
you're,
going
to
see
plenty
of.
If
you
want
header
bits,
walk
into
any
room
this
week,
you'll
see
plenty
of
those
I'm
going
to
talk
to
you
about
what
Quick's
immediate
value
proposition
was.
How
did
we
get
the
world
in
so
this?
These
are
the
features
right.
This
is
what
I
talked
about.
C
This
is
how
we
talk
about
quick.
Why
did
we
get?
How
did
the
world
get
interested
in
quick,
but
it's
a
quick
broke
new
ground
in
several
ways.
The
first
thing
was
the
zero
RTD
transport
and
crypto
handshake
again,
you're
going
to
hear
more
about
that.
After
my
talk-
and
this
is
fundamentally
difficult
to
do
with
TCP
and
the
split
TCP
TLS
models,
you've
got
dealers
sitting
on
top
of
TCP.
C
They
end
up
having
different
Scopes
when
I
say
different
Scopes
I
mean
scopes
of
identity
Scopes
in
terms
of
where
the
connection
gets
terminated
in
the
network,
and
that
makes
it
fundamentally
difficult
to
do
something
like
zero
RTD
people
have
argued.
People
would
say
you
know,
isn't
it
the
same?
Isn't:
zero
rtt
in
quick,
so
before
I
talk
about
the
same
as
TCB,
what
zero
Oddity
and
crypto
handshake?
What
what
that
gives
you
is
a
low
latency
connection
setup
for
those
of
you,
who've
not
been
paying
attention.
C
Zero
rdd
means
zero
round
trip
time
delay
before
data
is
exchanged
on
a
connection.
Excuse
me,
so
we've
created
a
zero
RTD
transfer,
transport
and
crypto
handshake.
Now,
TCP
could
do
this
with
TCP
fast,
open
in
TCP
and
with
TLS
1.3
and
zero
RTD
and
TLS.
However,
because
of
the
split
model,
you
still
end
up
having
different
Scopes,
you
have
TCP
that
doesn't
understand
domains
certs
things
like
that.
C
It
understands
only
IP
addresses
TRS
operates
in
a
different
space
and
you
have
a
split
between
an
understanding
of
what
the
endpoint
identity
itself
is
at
these
two
levels.
You
can
reconcile
these
things,
but
there's
a
lot
of
nuanced
work
to
be
done
there.
If
you
want
to
make
this
work
in
the
split
TCP
model,
next
slide
collection.
Migration
was
another
thing
that
we
wanted
for
20-25
years
to
build
into
transport
Technologies,
and
we
finally
got
it
in
and
we
were
able
to
build
this
into
Quick
again.
C
C
We
want
this
to
get
deployed
everywhere
with
mpdcp.
You
still
have
to
play
nice
with
the
operators
with
the
network
devices
and
so
on.
I
don't
mean
that
we
shouldn't
play
nice
with
the
operators.
What
I
mean
is
that
we
can't
wait
for
every
operator
and
every
metal
box
vendor
to
come
on
board
before
we
consider
a
protocol
deployed.
C
That
is
a
very,
very
long
poll,
and
that
makes
the
tent
unlivable
and
it's
it's
too
loud,
too
long
a
pole.
So
that's
basically
connection
migration.
Again,
we
were
we've
deployed
it,
it's
being
used
already
next
slide
and
we
are
able
to
build
troubleshooting
and
debugging
capabilities.
You
want
to
hear
about
this
a
little
bit
more
from
Lucas
tomorrow,
but
the
the
difference
here
is
this.
The
the
value
prop
here
is
this
right.
So
with
anybody
who's
anybody
here,
who's
done,
debugging
kernel,
debugging,
anybody,
okay,
a
fair
number
of
fans.
Excellent!
C
Companies
that
have
managed
to
successfully
build
those
things
have
used
them
very
very
effectively.
However,
it's
not
a
small
order.
It's
difficult
right
so
being
in
user
space
for
for
quick
basically
gives
you
the
ability
to
log
it
log
transport,
Network
level,
traces
alongside
application,
Level
traces.
That
is
huge
because
you
don't
have
to
go
around
doing
this
separately.
You
can
log
alongside
the
application
traces.
You
cannot
log
things
like
what
is
the
conditional
window
value?
What
is
the
state
of
the
connection?
C
So
actually
go
back
one
thing:
yeah
I
missed.
Oh
right,
I
meant
to
say
this
here.
There
is
a
another
really
really
cool
thing
which
I
you
know
I'll
show
at
the
end
of
today.
If
you
have
time,
I'll
demo
it,
but
one
thing
that
you
have
a
problem
with,
for
instance,
is
is:
if
you
have
poor
Behavior
at
the
client
side,
for
instance,
it's
you
can
grab
client-side
packet
traces
or
you
can
report
it
to
the
server
side.
C
Who
whomever
is
at
the
server,
and
you
can
say
Hey,
you
know,
go
dig
into
this
particular
Trace.
I'll.
Give
you
an
identifier
for
a
connection,
for
instance,
go
find
out
what
happened
with
that
connection.
Why
was
it
behaving
poorly?
You
have
no
other
recourse
and
on
the
server
side,
what
we
would
do
at
the
server
side
is.
Generally
we
end
up
having
to
find
your
connection.
Now.
That
is
an
impossibility.
C
C
So
this
is
really
really
valuable
at
the
client
you're
able
to
see
a
service
packet
race
now
I'm
gonna
move
to
the
next
thing,
which
is
transforming
server
architecture.
So
I
won't
go
into
the
details
of
this,
but
deg
server
return
is
an
ability
for
a
server
to
be
able
to
hand
off
a
request
to
another
server
and
have
that
server
serve
the
user
directly.
C
So
it's
sort
of
like
if,
if
a
client
requests
a
resource
from
a
server,
the
server
doesn't
have
the
resource,
but
knows
another
server
that
has
it
is
able
to
sort
of
Kick
the
connection
over
or
the
request
over
and
have
the
response
served
directly
from
there.
This
is
called
direct
server
return.
It's
called
direct
server
return
because
normally
what
what
and
what
commonly
happens
and
the
easier
way
to
solve
this
problem
of
I
don't
have
the
content.
C
C
We
are
able
to
design
this
in
quick
and,
and
some
of
us
have
been
designing,
building
this
into
into
our
server
infrastructures
and
the
reason
we're
able
to
do
this
is
because
in
quick
again
in
terms
of
how
we
build
the
transport
protocol
itself,
we
were
able
to
separate
the
sender's
view
from
the
receiver's
view
of
the
world
and
in
this
particular
case,
that
plays
very
nicely
allows
us
to
actually
build
something
like
direct
server
return.
We
can
have
multiple
servers
sending
with
one
receiver
receiving.
C
So
this
is
how
we
got
the
world
interested.
These
are
the
different
things.
These
are
the
different
benefits
that
we
brought
out
and
we
when-
and
this
is
how
all
of
us
got
excited
about,
quick
and
so
on,
but
I'm
going
to
now
talk
about
what
quick
is
enabling
right
next
slide.
What
does
quick
enable
so
quick
enables
multiple
new
technologies
that
you
can
build
within
quick,
so
you
can
hear
about
you
know.
C
You
won't
hear
these
experiments
today,
but
maybe
tomorrow,
you're
gonna,
there
are
new
condition
controllers
that
you
can
easily
build
and
deploy.
I
know
that
meta
has
done
this
Google's
done
this
fastly
we've
done
this
so
that
it's
it
makes
it
much
much
easier
easier
to
deploy
these
things
in
in
in
in
quick
than
it
has
been
in
TCP
next
slide.
C
So
quick,
I've
I've
told
you
that
the
quick
makes
the
web
faster,
more
resilient,
more
responsive,
but
this
is
just
the
beginning.
Next
slide
quick
enables
these
Technologies
I
talked
about,
so
it
all,
it
becomes
a
platform
for
these
new
technologies.
Moq
mock
mask
other
stuff
that
we
want
to
deploy
next
and
I've
also
told
you
that
quick
is
a
transport
technology
that
can
be
evolved
on
the
internet
because
we
managed
to
encrypt
everything
we
can
evolve
this
thing
going
forward.
C
It
is
already
continuously
evolving
in
multiple
versions
of
quick
already
exist
in
parallel
on
the
internet
today
and
next
slide
I'm
going
to
offer
that
we've
pulled
a
sleight
of
hand.
We
basically
convinced
everybody
that
these
are
the
reasons
we
wanted
to
deploy.
This
thing
HTTP
was
the
reason
and
getting
these
these
milliseconds
of
latency
Improvement,
and
these
features
were
the
reasons.
But
next
we
used
HTTP
on
the
web
as
a
vehicle
to
deploy
quick
into
almost
serve
all
server
and
client
deployments.
C
The
quickest
deployed
now
widely
it
also
it
it.
Almost
every
server
deployment
has
quick
in
it.
Almost
every
client
browser
and
other
client
libraries.
They
all
have
quick
in
them
now
next,
but
our
goal
really
was
to
create
an
end-to-end
transport
that
allowed
for
end-to-end
transports
and
Technologies
to
thrive
through
an
ossified
internet
and
I
would
say
that
we've
we
are
sort
of
somewhere,
not
at
the
beginning
of
this
journey.
C
B
D
D
D
There's
a
couple
of
things
in
here:
I
may
not
get
to
some
of
the
later
things
in
any
real
detail,
but
that
layering
diagram
that
Jonah
was
talking
about.
I.
Think
we'll
spend
a
little
bit
of
time
on
that,
quite
possibly,
the
most
difficult
part
of
getting
quick
working
was
integrating
the
the
TLs
handshake
into
quick.
D
So
what
we
wanted
to
do
was
avoid
replicating
a
lot
of
the
security
work.
It
turns
out.
They're
building
a
good
security
handshake
is
extraordinarily
difficult
and
tls13
is
the
result
of
a
number
of
years
of
work,
and
we
didn't
want
to
have
to
redo
all
of
that
work
because
we're
also
building
all
of
the
TCP
bits
in
tiling
on
top
of
UDP,
which
is
an
entirely
new
protocol
and
that's
more
than
enough
work,
and
it
turned
out
to
be
even
more
work
than
we
anticipated
when
we
we
came
into
this.
D
So
the
way
to
think
of
this
is
that
TLS
provides
all
of
the
cryptographic
assurances
that
you
might
expect
from
a
protocol
and
quick
provides
all
the
things
that
that
TCP
would
provide
being
reliable
audit
delivery
and
in
turn
they
each
provide
services
to
the
other.
Tls
requires
ordered,
reliable
delivery.
D
D
Look
as
much
as
we
can.
The
other
thing
is.
We
were
looking
to
do
better
than
any
of
these
protocols.
We
have
a
new
protocol
that
we
we're
implementing.
Here
we
took
every
opportunity
we
could
to
make
things
better
and
I'll
touch
on
a
few
of
those
points
as
we
go
through
next,
please
so
rtts
TLS
1.3
is
optimistic
in
the
sense
that
a
client
will
guess
what
configuration
will
work
for
a
server,
and
that
will
in
the
case
that
the
guess
is
correct,
save
a
round
trip
time.
D
D
If
the
client
guesses
wrong,
you
have
another
round
trip
added
to
that,
and
one
of
the
sort
of
themes
that
we'll
have
with
quick
is
that
it
has
a
very
short
handshake
if
everything
goes
correctly,
but
it
turns
out
that
you
can
add
multiple
round
trips
if
you
have
packet
loss,
the
client
guess
is
wrong.
The
server
is
under
duress
and
wants
to
tell
the
client
to
back
off
and
and
wait
a
little
long
while
longer,
and
so
we
have
this
very
flexible
handshake.
Ultimately,
the
key
Insight
is
we.
D
I
think
the
messages
we
exchange
is
two
round
trip
times,
but
under
normal
circumstances,
if
the
client
guesses
correctly
and
the
server
is
willing
to
communicate
with
the
client,
we
can
send
data
from
either
side
after
that,
first
exchange
between
the
client
server
we're
actually
sending
before
the
handshake
is
complete,
and
in
the
extreme
case,
if
the
client
has
been
to
that
server
in
the
past
and
set
up
the
zero
round
trip
time
thing
that
there
is
no
delay
for
either
end.
The
client
sends
immediately
application.
D
So
this
is
what
the
TLs
handshake
looks
like.
We
have
some
care
agreement
and
configuration
that
is
exchanged
more
or
less
in
the
clear
and
then
some
authentication
information-
and
you
can
sort
of
see
here-
we've
got
these
lighter
lines
that
say
where,
where
the
data
is
being
exchanged,
there's
a
flow
from
the
client.
There
might
be
some
some
application
data
following
after
that
one
there's
a
flow
from
the
server
there
might
be
some
application
data
and
then
finally,
at
the
end,
some
more
messages
lots
lots
more
data
at
that
point.
D
So
we
have
what
we
call
Initial
Keys,
which
are
not
secure
in
any
meaningful
sense,
but
they
provide
us
protection
against
ossification
to
to
the
points
that
Jonah
was
talking
about
before
every
single
version
of
quick
uses
a
different
set
of
keys.
If
you
don't
know
the
keys,
you
can't
speak
that
version
a
quick
sort
of
a
a
nice
little
protection
against
someone
who
might
be
inclined
to
interfere
with
the
handshake.
D
D
The
packets
are
protected
with
these
keys
and
we
we
put
multiple
packets
in
the
one
UDP
datagram,
as
it
turns
out
and
quick
after
many
iterations
between
first
going
with
something
that
was
based
on
dtls,
because
why
not
dtls
does
UDP
turns
out
to
be
a
bad
idea.
We
went
to
TLS
and
tell
us
exporters
for
for
getting
Keys.
Ultimately,
what
quick
does
is
runs
the
TLs
handshake
and
then,
when
TLS
produces
Keys
quick
reaches
in,
takes
those
keys
out
and
uses
it
for
packet
protection.
D
Tls
doesn't
TLS
record
protection,
isn't
engaged
in
in
this,
the
raw
bytes
coming
out
of
the
handshake
of
TLs
are
used
directly
by
quick.
So
the
final
two
types
of
keys
we
have
are
zero
watt,
CT
Keys,
which
the
client
uses
to
send
to
the
server
if
it
happens
to
be
attempting
zero
ITT
and
then
the
final
application
data
Keys,
which
are
used
for
everything
once
the
handshake
is
completed.
We
also
have
a
key
update
process
that
that
rotates
those
keys
periodically
to
prevent
to
prevent
them
from
wearing
out
next
place.
D
So
this
is
what
the
simplified
handshake
looks
like.
We
have
the
client
sending
an
initial
packet
which
contains
a
crypto
frame
which
contains
a
TLS
client,
hello
and
on
the
server
end,
we
have
an
initial
packet
and
that
contains
a
crypto
frame
that
contains
a
server
hello
and
that
is
all
effectively
sent
in
the
clear.
D
Now
this
is
a
quirk
of
TLs,
but
what
you
will
actually
see
here
is
the
there's
a
final
message
that
confirms
the
handshake
is
done
at
the
bottom
there
that
the
server
sends
once
it's
received,
everything
from
the
client
and
we
spent
years
trying
to
avoid
putting
this
message
in
it
turns
out
to
be
absolutely
crucial.
In
a
number
of
scenarios,
we
had
the
worst
problem
with
handshake,
Deadlocks
and
all
sorts
of
weird
Corner
cases
before
we
decided
look,
let's
just
put
another
message
in
here.
D
What
this
means
is,
ultimately,
this
is
a
two
round
trip
protocol.
You
can
see
two
round
trips
on
this
on
this
diagram
here,
but
you're
sending
data
a
lot
sooner
than
that,
and
that's
one
of
the
weird
things
about
operating
this
protocol.
Next,
please,
of
course,
all
of
this
integrates
with
quick
and
so
quick
underneath.
All
of
this
is
providing
acknowledgments
for
all
of
the
data,
that's
being
exchanged
back
and
forth
here,
and
so
that's.
D
What
you
see
here
is
that
every
single
message
that
is
sent
is
acknowledged
using
packets,
protected
by
the
same
types
of
keys,
for
various
reasons.
That
should
be
obvious.
You
can't
acknowledge
something
with
a
different
key
because
well
maybe
the
other
side
doesn't
have
that
key
yet,
and
so
there's
this
weird
interlocking
thing
that
that
goes
on
here,
including
some
implicit
acknowledgments
in
the
in
in
certain
cases,
which
gets
a
little
bit
interesting
as
well.
D
But
this
is
to
sort
of
illustrate
that
that
quick
is
providing
all
of
the
transport
reliability
features
that
TLS
requires
TLS
sends
very
large
messages
that
need
to
be
sent
and
received
in
a
very
particular
order.
Otherwise
it
just
doesn't
work
and
provides
those
those
facilities
next,
please
so
this
is
ultimately
what
we
have
in
terms
of
the
layering
diagram
and
I.
Think
thinking
about
layering
in
the
classic
sense,
where
you
have
a
protocol
that
sits
on
top
of
another
protocol,
doesn't
really
work
for
quick.
D
The
the
key
thing
to
realize
here
is
it's
more
like
a
software
architecture
diagram
where
there
are
certain
components
that
provide
different
capabilities
and
they
have
interactions
with
other
components.
If
you
think
of
the
TLs
stack
as
taking
handshake
messages
and
returning
handshake
messages
and
then
providing
information
about
State
changes
and
the
the
various
secrets
that
it
might
be
generating,
then
you
have
the
ability
to
to
build
a
component
that
then
sits
inside
the
grader
protocol.
And
so
you
have
crypto
streams
responsible
for
exchanging
those
handshake,
bytes
back
and
forth.
D
D
So
the
other
part
of
all
of
this
is
actually
mostly
new
in
the
protocol.
We've
taken
inspiration
from
from
protocols
that
proceeded
at
TCP
and
and
other
things,
but
the
denial
of
service
mitigations
in
quick
as
part
of
the
handshake
and
later
somewhat
more
interesting
than
the
software
engineering
exercise
of
getting
a
quick
TLS
stack
crammed
in.
So
we
have
a
few
basic
rules.
D
We
had
a
long
debate
a
little
while
ago
about
where
this
number
three
came
from
and
no
one
knows
concretely.
We
had
a
number
of
people
involved
in
the
design
of
this,
and
none
of
them
can
remember
where
the
number
three
comes
from,
but
there's
there's
this
basic
rule
that
we
follow
in
quick
is,
if
you're
sending
to
an
address
that
you
haven't
confirmed,
is
willing
to
receive
the
packets
that
you're
sending
only
send
three
times
as
much
data
to
that
as
what
you've
received
from
that
apparent
address.
D
B
D
So
the
the
basic
handshake
amplification
attack
is
that
a
client
sends
an
initial
packet
that
happens
to
have
zero
rtt
in
the
same
datagram.
You
can
put
a
request
in
the
same
packet
as
your
your
initial
thing
that
might
be
a
totally
valid
packet
that
a
server
would
accept
under
normal
circumstances.
D
It
might
be
very
happy
to
accept
that
packet
from
the
client,
but
if
the
client
manages
to
spoof
the
address
the
return
flow
from
the
server
which
contains
all
the
quick
handshake
information
and
potentially
the
answer
to
the
question
that
they
asked
could
be
very
large
and
the
poor
victim
who
genuinely
owns
that
address
might
find
themselves
on
the
receiving
end
of
a
large
flight
of
packets
from
a
very
well
connected
server.
We
don't
want
this
to
happen
so
next
slide.
Please
so
TCP
solved
this
I
think
a
long
time
ago.
D
I
don't
know
when
that
was,
but
it
was
before.
I
was
involved
in
any
of
this
and
it
has
a
three-way
handshake,
of
course,
when
we're
doing
TLS
and
TCP.
This
adds
an
extra
round
trip
to
the
setup,
which
is
a
little
Annoying.
That's
slows
things
down
a
little
bit,
but
essentially
TCP
confirms
his
willingness
to
communicate
before
you
start
doing
any
of
the
TLA
stuff,
but
in
quick
we
put
this
all
together.
So
we're
doing
the
cryptographic
handshake
and
this
confirmation
to
communicate
all
at
once
and
of
course
not.
D
D
This
looks
approximately
this
like
this,
the
client
sends
a
packet,
maybe
some
extra
packets
and
the
server
says:
hey.
No,
please
confirm
before
proceeding
and
it
sends
the
client
a
token
and
if
the
clients
are
genuine
type
client,
it
will
receive
that
token
and
can
stick
it
in
the
packet
that
it
generates
for
the
next
attempt
and
everything
moves
moves
on
from
there
and
the
server
has
now
received
confirmation
that
the
client
is
able
to
receive
the
messages
that
the
server
is
sending
and
the
client
is
willing
to
participate
in
the
protocol.
D
Retry,
of
course,
is
probably
not
something
that
you
want
to
do,
because
you're
adding
a
round
trip
time
to
the
connection
setup.
It
is
particularly
good
for
cases
where
the
server
is
under
stress
and
they
want
to
make
sure
that
every
client
is
genuine.
If
they're
under
attack,
then
then
it
might
be
might
be
a
good
way
to
manage
that
or
if
you
think
that
the
traffic
is
coming
from
somewhere.
D
That
is
unreliable
for
various
reasons:
the
reputation
systems
that
you
have
indicate
that
it
may
be
a
little
a
little
shonky,
but
that
round
trip
is
expensive.
So
we
have
some
tricks
for
the
case
that
the
handshake
is
is
shorter.
Next,
please,
so
what
we
need
to
do
is
prove
to
the
server
that
the
client
saw
this
over
initial
packet.
How
do
we
do
that?
D
It's
very
simple.
The
first
exchange
that
happens
in
the
clear
between
the
client
and
server
establishes
some
cryptographic
cryptographic
keys,
and
it
does
that,
based
on
information
in
those
packets,
the
next
set
of
packets
from
the
client,
these
handshake
packets,
use
those
cryptographic
keys
to
generate
new
packet
protection
keys
if
the
client
produces
a
valid
handshake
packet.
D
That
is
because
it
saw
everything
that
the
server
produced,
and
so
we
we
have
what
what
amounts
to
an
implicit
token.
At
that
point-
and
until
this
point,
the
the
the
three
and
three
out
for
for
one
in
rule
applies,
but
next
slide,
we'll
show
you
the
same
thing
that
you
saw
before,
but
as
the
initial
from
the
server
reaches
the
client,
the
client
generates
some
new
cryptographic
keys
to
protect
the
handshake
packets.
D
D
D
So
not
only
does
This
Server
proven
that
it
understands
the
version
of
quick,
that's
being
involved.
It's
also
proving
that
it's
willing
to
talk
to
the
client
by
responding
to
it
in
this
way
and
that
retry
thing
that
we
talked
talked
about
before
we
need
to
have
the
same
sort
of
mechanism
there.
That
has
a
different
mechanism
for
for
managing
that
that
same
process,
but
there's
an
Integrity
check
in
there
as
well.
D
Okay
yeah,
so
all
of
this
is
somewhat
fiddly
to
get
right.
There
were
a
lot
of
Deadlocks
that
we
discovered
in
the
process.
I
think
we
spent
what
the
better
part
of
two
years
going
back
and
forth
over
some
of
the
the
more
tricky
ones.
Certain
people
had
a
very
good
habit
of
finding
new
ones.
Every
time
we
thought
we
fixed
them.
D
We've
spoken
to
academics
about
this
one
and-
and
there
are
systems
out
there
that
might
might
be
able
to
prove
these
sorts
of
things,
but
it's
it's
rather
challenging
and
I
didn't
even
talk
about
version
negotiation,
which
adds
even
more
complexity,
but
I
won't
talk
about
that
here,
because
we
don't
have
the
time
next.
Please
brief!
On
migration,
the
migration
process
follows
the
same
three
out
for
everyone.
In
rule
we
have
migration
for
a
number
of
reasons.
D
Probably
the
most
interesting
one
is
a
client
that
is
sitting
behind
a
Nat
and
they
get
given
an
address
and
they
happily
talk
to
us
over
back
and
forth,
and
then
they
go
quiet
for
a
little
while
because
well,
they
just
don't
have
anything
to
say
at
that
point
and
when
they
restart
the
communication.
After
that
brief
period,
the
NAT
has
decided
that
it's
going
to
give
it
a
different
IP
address
on
that
flow,
and
so
what
the
services
is
a
message
from
the
client
that
has
a
new
IP
address.
D
That
is
completely
unvalidated
and
that
could
be
maybe
an
attack,
and
so
if
it
were
to
continue
sending
large
amounts
of
data
to
that
new
address,
bad
things
might
happen,
because
that
might
be
spoofed.
Of
course,
in
a
lot
of
cases,
most
cases,
in
fact
it's
just
the
Nats
doing
what
Nats
do
next
please.
D
D
D
There
we
go
so
migration
looks
like
this.
You
have
an
established
connection
between
client
and
server
and
maybe
an
attacker
takes
one
of
your
packets.
Maybe
it's
a
packet
that
you
had
dropped
and
sends
it
from
a
new
address.
The
server
looks
at
this
packet
and
says
I'm,
not
sure
about
this
one.
This
might
be
legitimate,
I,
don't
know,
and
so
what
it
does
is
probes
that
address
saying.
D
If
it's
legitimately
moving
to
the
new
address,
then
it
will
respond
from
the
new
address
and
proceed
if
it's
still
on
the
old
address
and
the
attacker
decided
that
it
wanted
to
force
the
client
to
migrate
to
A
New
Path,
then
the
attacker
should
be
unable
to
produce
the
the
correct
response
and
whichever
one
wins,
whichever
one's
legitimate
will
produce
a
response
that
the
server
will
then
respect
and
migration
will
proceed
next.
Please.
D
Migration
is
very
simple
at
some
levels,
you
simply
detect
that
an
address
has
changed
on
the
other
end
and
you
start
sending
data
to
that
address,
but
you
only
Follow
You
Follow,
the
three
times
rule
until
you've
managed
to
validate
that,
and
the
validation
process
was
on
the
previous
slide.
Next,
please
and
I
think
we're
up
so
having
this
very
simple
three
times,
anti-amplification
rule
applies
to
all
addresses,
it's
pretty
straightforward
to
plot
to
apply.
D
You
need
to
validate
all
paths
before
you
speak
on
them,
and
simplifying
to
the
client
only
means
that
we
don't
end
up
with
complications
in
the
protocol
State
machine,
where
both
sides
decide
to
migrate
at
the
same
time,
which
doesn't
really
work
very
well,
and
then
that
leads
into
a
whole
set
of
other
design
problems
where
we
use
connection
IDs
on
different
paths.
But
I
haven't
spoken
about
connection
IDs
and
probably
shouldn't
because
I
don't
have
time
next,
so
that's
only
sort
of
a
taste
of
all
the
security
relevant
things.
D
D
B
B
B
B
To
him
talk
to
Ian
Ian,
we'll
talk
about
that
tomorrow
is
to
wear
that
three
three
yeah,
oh
yeah,
that
makes
a
lot
of
sense
cool.
So
thank
you
all
very
much
for
being
with
us
so
early
this
morning,
thanks
especially
to
our
speakers,
excellent
excellent,
excellent
presentations.
We
hope
to
see
all
of
you
and
more
tomorrow
morning
at
7
30,
not
at
8.
We
have
a
little
bit
of
extra
time
for
the
panel
discussion
and
we
ran
early
as
opposed
to
running
late
on
that
one.