►
From YouTube: IETF97-TCPINC-20161118-0930
Description
TCPINC meeting session at IETF97
2016/11/18 0930
B
A
A
So
since
Berlin
there
hasn't
been
a
huge
amount
of
work,
but
there
were
two
very
long
discussions
on
the
mailing
list.
The
those
two
discussions,
one
of
them
was
around
the
urge
and
thin
bits
and
the
other
one
was
around
a
sin
data
and
both
involved
long
drawn-out
discussions
with
Joe
and
some
other
folks
that
actually
were
produced.
Some
very
subtle
semantic
changes
in
the
documents,
but
I
think
that,
as
a
result
of
that,
the
last
remaining
real
blockers
to
work
group
last
call
have
been
resolved.
B
A
B
A
Yes,
actually
that's
a
good
question.
Do
we
want
to
add
a
specific
agenda
item
for
discussing
the
api
doc?
Okay,
so
why
don't
we
do
that
after
I
want
to
put
mine
last
just
to
maximize
the
potential
for
TLS
people
to
be
in
the
room,
so
why
don't
we
put
it?
Third,
so
after
TCP
Krypton,
okay,
this
quick
check
Aaron,
you.
B
B
C
B
B
B
A
E
B
B
F
Okay,
great
so
yeah
update
on
TCP,
you
know,
went
through
a
bunch
of
drafts
right
off
the
last
meeting
and
then
a
couple
more
recently.
So
just
to
remind
everybody
of
how
you
know
works
and
what
the
goals
are.
You
know
the
goal
is
to
facilitate
adoption
of
future
TCP
encryption
protocols.
So
we
used
to
call
these
things.
Encryption,
specs.
F
We've
now
coined
the
term
tap
for
a
tcp
encryption
protocol,
and
so
the
idea
is
that
we,
when
there
are
going
to
be
new
taps
because
we
didn't
want
to
like
try
to
be
all
things
to
all
people
and
solve
all
problems
and
when
you
taps
come
along,
we
don't
want
them
to
have
to
go
through
the
trouble
of
getting
a
new
tcp
option
kind
because
those
are
limited
and
it's
a
pain
to
get
them.
We
don't
want.
F
We
want
you
to
have
to
be
incrementally
deployable,
so
you
can
fall
back
to
existing
ones
and
possibly,
more
importantly,
once
we
get
this
stuff
deployed,
there
may
be
applications
that
then
take
advantage
of
TCP
ink
and
we
want
to
make
sure
that
those
applications
continue
to
be
forward
compatible
with
future
taps.
If
you
actually
go
through
the
trouble
of
integrating
the
TCP
the
session
ID,
for
example,
in
your
user
authentication,
you
want
to
make
sure
that
that
works
with
the
future
tab
taps.
F
So
the
goal
of
Ino
is
to
kind
of
abstract
all
these
things
away
from
the
application
and-
and
so
we
also
want
to
you-
know-
minimize
consumption
option
space
since
that's
at
a
premium
and
avoid
unnecessary
round
trips,
and
you
know,
of
course,
because
this
is
has
to
be
backwards.
How
do
we
want
to
make
sure
we
fall
back
to
unencrypt
the
tcp,
rather
than
causing
connections,
to
fail
as
much
as
possible,
so
just
an
overview
of
how
it
works?
F
In
the
common
case
of
a
three-way
handshake,
you
have
an
active
opener,
we
sent
the
sin
segment
and
the
sin
segment
contains
a
an
e
no
option
and
inside
that
II
no
option
is
a
list
of
type
identifier
saying
you
know
what
TTP
level
encryption
protocols
are
supported
by
the
accubow.
Then
the
the
passive
opener
replies
of
the
syn
ACK
and
replies
with
a.
G
F
You
go
good
and
so
replies
with,
ideally
the
one
tap
that
that
the
act
that
the
pass
opener
wants,
there's
also
this
new
change.
We
made
last
time
where
you
have
to
add
this
this
this
be
bit
here
to
say
that
you're,
the
passive
opener
and
that
was
in
a
way
you
know
I,
never
want
to
say
it's
nice
to
have
middleboxes
doing
horrible
things,
but
we
didn't
have
kind
of
like
all
these
debates
about.
F
Should
we
have
this
like
perfectly
symmetric
protocol
whatever
and
all
that
turned
out
to
the
irrelevant,
because
we
found
out
the
places
like
Baidu
just
like
have
these
these
middleboxes,
that,
like
echo,
any
unknown
TCP
options
back
to
the
opener,
and
so
it
just
had
to
be
the
case.
If
somebody
echoes
your
option
that
it
just
you
know,
is
disabled,
because
it
would
be
disastrous
to
start
encrypting
when
the
other
side
didn't
know
that
it
was
encrypting.
So
basically
one
side
has
to
set
the
Biba
20.
F
The
other
side
has
to
set
the
be
bit
to
one.
Otherwise
we
fall
back
unencrypted
TCP
and
that
just
makes
a
lot
of
things
simpler
and
then
you,
in
the
third
leg
of
the
handshake,
keep
sending
the
e
no
option
to
make
clear
that
it.
You
know
that
you
know
didn't
get
stripped
off
the
syn
ACK
segment
and
you
keep
sending
a
no
option
until
such
point
as
you.
F
You've
received
a
segment
that
doesn't
contain
a
sin
flag,
and
at
that
point
you
know
you're
done
and
both
sides
know
that
they're
encrypting
and
the
connection
is
encrypted.
If
any
of
the
e
knows
our
options
are
missing
the
beginning,
then
you
fall
back
to
unencrypted
TCP
and
also
gives
us
the
backwards
compatibility.
Okay.
So
what's
a
nanny,
no
option,
Willis,
two
kinds
of
you
know:
options
or
two
forms
of
you
know:
options
there's
the
ones
that
are
in
sin
segments
and
the
ones
that
are
nonsense
segments.
F
So
at
the
top
you
see
in
a
sin
segment
the
e,
no
options
they
say
container
for
a
bunch
of
sub
options
in
otherwise
it's
just
ignored
right.
Just
the
presence
of
the
you
know.
Option
is
a
flag,
but
the
contents
is
ignore,
but
you
know,
and
unless
the
temp
that
you've
selected
that
you
negotiated
specifies
that
you
should
put
some
bytes
in
there.
It
must
be
zero
bytes.
So
it's
just
an
empty
option,
but
it's
available
if
the
pep
wants
it.
Okay.
F
So
within
the
sin
segments
each
sub-option
starts
with
an
initial
sub-option
bite
and
that
bite
has
two
components.
It
has
this
high
bit
v,
which
stands
for
variable
like
data
and
then
has
a
7-bit
thing
that
used
to
be
called
CS,
but
now
we're
calling
it
g
LT,
which
stands
for
global
sub-option
length,
ortep
identifier
and
we've
sort
of
broken
it
up
into
four
quadrants.
When
the
GLT
field
is
less
than
32,
then
if
v
is
0,
it's
what
we
call
a
global
sub-option
music,
all
that
a
general
sub-option
with
the
name
global.
F
It's
clear
these
other
options
of
by
across
all
taps
and
and
if
it's
one,
then
it's
a
length
bite
and
reset
this
more
complicated
thing
with
length
words
whatever
we
just
got
rid
of
that,
so
that
now
it's
simpler
and
then
for
values
of
32
or
greater.
It's
a
temp
identifier
that
seven
value
is
a
temp
identifier
and
if
the
V
bit
is
0,
that
is
just
a
one-bite
kept.
Otherwise,
oh,
it
has
variable
length
data.
So
in
one
more
detail,
there's
basically
three
kinds
of
tap
identifiers
that
you
can
embed
inside
a
sin.
F
Sorry,
my
popping
my
PS
or
am
I
am
I
not
louder
with
oh
yeah.
Sorry,
because
I
don't
have
my
slides
in
front
of
me.
So
I'll
try
to
I'll
try
to
speak
across
the
mic
like
this.
Actually
I
guess
I
can
speak.
Usually
when
you
speak
into
a
mic,
you
pop
your
P's,
better
talk
across,
but
ok,
so
so
yeah.
So
here's
the
one
bite
when
when
the
V
bit
is
0,
otherwise
there's
two
options.
F
If
you
just
set
the
V
bit
to
one
and
you
set
a
type
identifier
which
is
where
the
low
7
bits
are
3qr
higher,
then
it
means
that
the
data
extends
to
the
end
of
the
tcp
option,
and
we
special
case
this,
because
we
think
the
common
cases
there's
only
going
to
be
one
tap.
That
actually
has
data
just
cuz.
F
You
don't
have
that
many
bytes
inside
us
in
header
and
then
the
other
option
is
that
you
have
this
link
bite
and
then
you
have
a
temp
ID
with
the
veba
set
one,
and
then
you
have
that
many
bytes
of
data.
So
that
way
you
can
actually,
if
you
want,
have
multiple
taps
of
options
that
have
data
and
then
the
other
option
is
this
global
sub-option.
The
global
sub-option
starts
with
30
bits
and
then
has
three
Reserve
bits
that
must
be
zero,
and
then
then
these
two
bits
ambi.
F
F
If
the
active
opener
happens
to
admit
this,
this
global
sub-option-
that's
because
like
in
the
very
first
sin
packet,
that's
one
up,
you
know,
option
spaces
at
the
greatest
premium
and
then
the
second
thing
is
this
application
of
where
bit,
which
is
a
bit
that's
available
to
the
application,
to
negotiate
something
out
of
band
that
triggers
authentication
of
the
TCP
level
encryption
right.
So
that's
how
you
have
some
legacy
protocol.
There's
no
way
to
add.
Like
a
you
know,
a
start
TLS
command
to
it.
F
F
If
you
remember
last
time,
I
used
to
be
this
M
bit,
you
know
we
decided
to
push
us
that
offer
later.
We
still
think
that
there's
room
for
application,
independent
authentication
protocols
and
that
we
should
negotiate
those
out
of
band,
but
we
now
have
these
three
bits
named:
Z
3,
Z,
2,
n.c,
one
that
we
can
use
so
ideally
xiii.
You
know
at
some
future
draft
will
become
a
you
know,
and
a
separate
document
would
say
like
how
could
you
combine
dane
and
tcp?
F
You
know,
for
example,
okay,
so
you're
only
allowed
to
have
one
global
sub-option,
you
have
to
ignore
subsequent
ones.
That
means,
if
five
bits
turns
out
not
to
be
enough,
we
could
just
say
when
you
get
a
second
sub-option.
It
has
these
five
new
bits
that
have
five
new
meaning.
So
probably
what
happened,
but
at
least
we're
future
compatible
if
you'd
be
okay,
so
now
the
the
interesting
stuff.
F
Tab
and
thus
in
tap,
is
responsible
for
defining
the
meaning
of
data.
That's
inside
that's
inside
that
that's
in
segments,
so
in
particular,
if
the
sin
tab
doesn't
say
anything
about
sin
data,
then
you
are
not
allowed
to
put
data
in
a
sin
segment
right,
but
we're
leaving
the
option
open
for
future
taps
that
that
might
wish
to
do
this
right
and
then,
of
course,
the
symptom.
I
turn
out
not
to
be
the
negotiated
tap
right.
F
You
might
propose
a
bunch
of
peps
the
last
one
is
one
thing
you
embed
a
bunch
of
data
for
that,
and
it
turns
out
that
you
know
you're.
The
active
open
of
the
passive
opener
decides
to
choose
a
different
one.
So
at
that
point
you
have
to
discard
the
data
because
it
doesn't
because
it
was
the
data
only
had
meaning
to
one
particular
tap
and
you
chose
a
different
tab.
So
we
say
that
you
have
to
discard
the
sin
data.
F
If
the
sin
tap
is
not
the
negotiated
that
including
the
case
where
ino
fails
entirely
and
it's
not
an
encrypted
connection,
and
we
also
say
they
have
to
discard
the
data.
If
there's
any
off
any
other
tcp
option,
that
implies
something
about
the
meaning
of
the
sin
data
so
right
now,
the
the
one
that's
most
relevant
btfo.
So
if
you
have
a
non-empty
TFO
option,
you
just
you
have
to
discard
the
sin
data.
F
Basically
it's
it
that
doesn't
make
sense,
because
if
you
have
the
TFO
option
telling
you
hey,
this
is
some
plain
text,
application
data
and
you
have
say
a
sin,
tap
telling
you
like
hey
this
is
you
know
some
part
of
a
key
exchange
or
something
then
like
that
which
is
it
right?
You
don't
know
so
so
you
know
you're
not
supposed
to
use
TFO
in
conjunction
with
this.
So
that's
one
safeguard
that
you
can't
use
the
data
if
it's
unah,
if
it's
ambiguous
what
it
means.
F
The
second
safeguard
is:
what
happens
if
there's
a
host
that
you
know
receives
its
data
and
appears
to
discard
it
because
doesn't
actually
act,
the
bytes
that
were
in
the
ascendant,
but
it
actually
caches
those
bites
anyway,
and
when
you
re
transmit
the
those
sequence
numbers
with
different
bites,
it
uses
the
cash
original
version
of
that
and
because
we
don't
know
that
TCP
implementations
don't
do
that.
We
say
that
we
require
you
to
do
it.
If
you
implement
you
know,
but
of
course
the
other
side
might
not
implement
you
know.
F
C
F
F
And
what
we're
saying
is
it's
fine
if
you
want
to
do
that,
but
it
has
to
be
off
by
default
and
and
you're
going
to
have
to
reset
the
connection.
If
you
talk,
if
the
remote
site
doesn't
support,
you
know,
and
you
sent
it
a
bunch
of
protects
your
key
exchange
stuff
that
it
probably
doesn't
understand.
Therefore,
and
therefore
you'll
have
to
reset
the
connection.
Okay,.
F
That
is
up
its
up
to
the
it's
up
to
the
debt:
tap
the
specific
tab
and
and
right
now,
no
taps
actually
do
this,
but
I
could
one
could
imagine
that
it
would
be
like
if
we
did
this
for
TCP
crypt.
It
would
be
one
a
few
things
in
the
case
of
session
resumption.
It
would
be
encrypted
application
data
and
in
the
case
of
like
a
fresh
connection,
it
would
be
key
exchange
data
or
you
know,
symmetric
cipher
preferences
or
both.
F
Okay,
so
the
the
second
thing
is
in
either
berliner,
argentina.
There
it's
been
at
this
and
long
enough
that
starting
to
blur,
but
we
became,
we
became
forcefully
convinced
that
in
under
no
circumstances
doing
what
tcp
you
know
to
be
like
required
to
modify
RFC
793,
and
so
there
was
this
problem
that
we
were
saying
things
like
well,
you
know
you
can
have
some
mechanism
for
end
the
file,
that's
separate
from
fin
and
and
the
language
kind
of
made
it
sound
like.
F
Maybe
the
fin
bit
was
no
longer
the
fin
bit
and
so
I
so
and
same
for
urge,
and
so
instead,
what
we've
done
is
we've
rewritten
these
tap
requirements
to
make
everything
in
terms
of
like
authenticating,
the
existing
TCP
mechanism,
so
we're
not
abandoning
TCP
mechanisms
right
so
particularly
say
that
you
know
taps
have
to
authenticate
the
fin
bit
and
you
know
they
can
do
that
with
some
parallel
mechanism.
But
if
the
parallel
mechanism,
the
fin
bit,
don't
match
them,
that
means
you've
got
some
packet
corruption.
F
So
there
you
can
discard
the
segment,
that's
corrupted
or
reset
the
connection
with
an
error
or
something,
but
you
can't
treat
it
like
an
authentic
and
defiled,
and
similarly
so
this
is
this
is
where
things
get
a
little
tricky.
We
want
to
kind
of
walk
this
fine
line
with
with
urgent
data
that
it
is
part
of
TCP,
but
a
lot
of
people
don't
use
it
but
like
if
people
could
inject
urgent
data,
it
could
like
mess
up
existing
applications.
F
So
we
want
to
make
clear
that
you
know
a
temp
cannot
cause
urgent
data
to
be
delivered
when
none
has
been
sent
by
the
sender.
That's
really
like
the
important
thing
and
the
the
problem
is
that
there's
no
way
in
hell
that
TCP
use
TLS
is
going
to
support
urgent
data
properly,
look
exactly
the
way
TCP
does
TCP
does,
but
but
it'll
be
hard
to
fit
in
the
TCP
use.
F
Tls,
and
so
we
want
to
do
is
make
sure
that
you
know
can
accommodate
TCP
use
TLS,
but
not
that
we're
like
modifying
RFC
793.
In
particular.
You
know
there's
this
more
recent
RFC
69
degree
that
kind
of
reaffirms,
urgent
data
and
talks
about
how
it's
supposed
to
how
supposed
to
work.
So
we
have
this
thing.
You
know
it's,
maybe
theoretically,
used
by
some
really
old,
FTP
servers
and,
and
maybe
telnet
and
rsh,
which
people
aren't
using
that
much
anymore.
F
F
So
we're
saying
that,
basically,
you
know
it's
okay
to
you,
you
might
have
some
taps
that
would
just
basically
ignore
the
urgent
flag,
pretend
it's
clear,
no
matter
what
and
but
you
shouldn't
enable
that
kind
of
tap
by
default,
except
when
you
know
for
a
fact
that
the
application
is
not
going
to
use
urgent
data
and,
like
it
just
happens
that
we
know
for
a
fact
that
almost
all
applications
are
not
going
to
use
urgent
data.
So
so
that's
our
hope
that
this
the
week
minutes
a
kind
of
thread.
The
needle
okay.
B
Let
me
say
one
quick
thing
about
threading
the
needle.
It's
basically
another
way
to
think
about
the
phrase:
everything
in
terms
of
technique,
TCP
functionality
from
a
functional
point
of
view.
One
way
to
think
about,
what's
going
on
with
with
the
temps,
is
that
you've
got
crypto
function
between
the
TCP
implementation
and
the
wire,
which
means
on
receipt
you
get
to
go.
B
Do
the
decrypt
look
at
what
the
temp
put
in
there
to
tell
you
where
the
thin
bit
is
authentic
or
not,
and
if
the
TCP
header
contained
a
thin
bit,
but
the
decrypted,
a
tech
payload
said
no
Finn
bit
here
at
that
point,
you
discarded
the
regular
TV
implementation,
never
see!
Is
it
and
it's
basically,
if
all
else
fails
we
will.
F
Okay,
so
so
yeah,
so
these
are
really
the
only
two
big
changes.
This
is
kind
of
summary
of
everything.
We've
changed
I've
got
these
new
terminology
that
specs
are
now
called
taps.
The
general
sub
drop
shin
became
the
global
sub-option.
We've
got
this
notion
of
a
sin.
Tap.
We
get
rid
of
the
length
word
so
now,
the
other
than
the
last
tap
sub-option.
You
can
only
have
32
bytes
of
sub-option
data,
but
remember
the
total
space
for
all
options
is
40
bytes,
so
that's
not
you're
not
going
to
have
more
than
one
sub
option.
F
F
We
talked
about
data
and
since
segments
another
kind
of
changes
that
we
changed,
some
shoulds
to
musts
and
for
the
remaining
shoulds
we
tried
for
everyone.
That
way
actually
say,
like
the
exception
is
whatever
because
basically
have
pushed
back
on
the
mailing
list.
You
shouldn't
just
blindly
throw
around
shoulds
if
there
is,
if
you're
saying
should.
F
Instead
of
must
because
it's
an
exception,
like
explicitly
state
with
the
exception,
so
we
try
to
be
clear
about
that
and
then
you
know
we
tried
to
improve
the
wording
for
the
temp
requirements
already
talked
about
the
pin
and
urge
the
other
thing
is
someone
I'm,
sorry
I
forget
who
did
this
but
brought
up
the
issue
of
forward
secrecy
on
the
mailing
list
and
saying
that
you
know?
Basically,
we
didn't
want
to
rule
out
some
application.
Some
possible
implementations
right.
F
You
could,
you
know,
imagine
an
application
where
you
have
to
like
seed
your
system,
random
generator
from
some
seed
file
but
stored
on
an
SSD,
and
you
know
because
of
your
flash
translation
layer
like
we
technically
it's
like
really
hard
to
do
forward
secrecy
and
that
kind
of
scenario.
But
the
important
thing
is
we
want
the
at
the
protocol
level,
all
the
tests
offer
forward
secrecy.
F
So
basically
we're
saying,
like
you
can't
depend
on
long-lived
secrets,
Percy
on
long
live
keys
for
secrecy
and
and
and
yeah,
and
that's
it
so
just
a
few
tiny
things
left
to
do.
I
hope.
So
you
know
one
question
that
still
have
I.
Don't
think
discussed
this
before,
but
should
there
be
a
way
to
signify
that,
like
a
host
implements
Ino,
but
it's
just
disabled
and
one
reason
you
might
want
this
is
because
it
would
help
in
the
case
of
in
that
corner
case,
where
you
have
to
discard
some
sin
data.
F
That's
like
because
there's
a
sin
tap
ended
up,
not
governing
the
connection.
Well,
if
you
know
the
other
side
implements,
you
know,
even
though
it's
not
enabled
you
know
it
will
discard
that
data.
So
that
might
be
nice.
It
might
also
be
useful
in
terms
of
like
data
gathering
to
be
able
to
you
know,
people
well
advertised,
hey,
like
my
kernel,
supports
I.
F
Another
thing,
I
think
this
is
just
an
omission,
but
we
should
have
some
kind
of
in
the
API
document,
some
kind
of
TCP.
You
know
mandatory
thing
that
says:
hey
abort,
the
connection,
if
I
don't,
if
it's
not
encrypted,
and
that
that
option
would
allow
us
to
enable
taps
that
Duty
fo
like
things
that
have
sinned
data,
you
know,
then
we
need
to
get
get
our
actual
option,
still
hoping
we
get
69,
since
we
had
used
that
earlier
and
yeah
I
hope
not
much
else.
F
There's
other
stuff
kind
of
fond
work,
so
we
still
need
TCP.
You
know
middle
box,
probing
document,
there's
this
experimental,
spec
ID,
so
we'll
need
another
drop.
Just
talks
about
how
to
multiplex
that
and
I
think
some
exi
d
like
thing
I,
think
that
should
be
very
simple
and
then
yeah
ideal.
It
also
like
this,
you
know
see
application,
independent,
middleware
authentication
so
that
you
can
like
load
a
shared
library
that
you
know
when
Dane
is
deployed
or
whatever
it
can
actually
do
like
server,
authentication
and
transport
application.
So
this.
F
B
Few
suggestions
from
up
here
and
I'll
go
bottom,
the
top,
since
that
seems
we
seem
that
stack
a
life
of
you
way.
My
brain
is
working
this
morning.
Application
independent
authentication
would
be
a
fine
follow-on.
I
would
strongly
suggest
writing
the
draft
against
a
specific
mechanism
as
opposed
to
writing
a
general
drive.
So
you
could
do
this
figure
out
how
to
use
Dane
and
bright
then
write
down
the
details.
Yeah.
F
G
H
Yeah,
so
there's
an
address,
so
the
question
was
whether
we
use
da
bit
in
our
prototyping,
and
we
certainly
did.
We
had
a
drop-in
replacement
for
lib
ssl,
a
binary
for
placement
actually
and
the
idea
was
to
use
the
a
bit
if
the
other
end,
you
know
supported
TCP
crypt,
we
just
kind
of
use,
TCP
crypt
and
then
do
the
authentication
ourselves.
We
get
the
session
ID
using
a
cell
and
if
it
didn't
support
the
a
bit
we
just
did
vanilla
TLS,
basically
reason.
B
Mean
the
rest
of
us
would
be
the
same
level
as
opposed
to
the
end
of
it,
which
is
something
something
will
come
back
to
later.
Okay,
working
our
way
up,
dedicated
TCP
option.
Okay,
I
suspect
I
spec
house
gonna,
make
me
go
Sydney
a
shepherd
for
this
draft
in
part,
because
this
one
well
I
believe
you
are
the
Shepherd
for
the
stress.
Yes,
okay,
game
plan.
B
Here
we
get
through
worker
blast
call
first,
and
then
we
will
at
that
point
with
it
or
do
I
believe
the
rough
consensus
of
this
working
group
is
to
ask
for
69.
However
I
don't
even
have
I
would
ask
Joe
touch
to
do
a
working-class
core
of
you.
I
suspect
that
request
is
not
going
to
be
necessary
now,
but
let's
be
serious.
F
B
Options:
fine
well
I,
understanding
options.
Fine,
however,
I'm
pretty
sure
based
on
discussion,
I,
think
in
berlin,
yes,
16,
not
that
the
rough
consensus
is
this
working
group
is
to
reuse
69,
and
we
can
then
have
an
argument.
It's
where
the
work
group
is
working
group
is
right
or
wrong
about
that,
but
we
will
have
that
argument
on
the
list.
Yeah
I
believe
the
the
the
philosophy
behind
that
was.
You.
B
B
Finally,
I
would
speaking
now
as
an
individual,
not
you're,
working
group
chair
and
not
your
draft
Shepherd
and
I've
osteria.
The
gratuitous
walk
walk
before
Mike.
To
make
the
point,
I
would
suggest
not
doing
the
first
item
on
this
slide.
This
is
already
subtle,
complex
and
unlikely
to
be
used.
Let's
just
not
do
anything
more
that
we
don't
need
to
do.
There's
we
can
get
all.
B
F
A
I'm
gonna
have
to
start
kairos,
not
speaking
as
chair,
I'm
gonna
have
to
disagree
with
with
David
on
this,
actually
think
this
is
a
really
good
idea
for
the
exactly
the
reason
you
specified,
which
is
that,
which
is
that
it
solves
the
problem
of
knowing
whether
a
peer
support
you
know,
but
just
has
it
disabled
for
purposes
of
dealing
with
early
data,
and
it
doesn't
seem
like
it
complicates
the
protocol
in
any
way.
So
it
seems
like
it
seems
like
a
good
idea.
If
the.
A
F
C
F
Know
one
thing
that
week
one
thing,
that's
kind
of
like
been
a
thorn
in
our
side
for
the
whole
time
is
like
people
talking
about.
You
know
whether
middleboxes
are
gonna
like
strip
options
and
this
kind
of
stuff
so
be
kinda.
Nice,
a
like
you
know
what
like
okay
nobody's.
You
know.
Most
people
are
using,
you
know
yet,
but
like
it
appears
that
it
like
it
gets
through
middleboxes.
But
but
again
it's
not
well.
If
the
consensus
is
don't
put
it
in
then
we
won't
put
it
in.
This
is
a
small
change
either
10.
F
No
I'm
saying
suppose
that,
like
you
know,
you
know,
gets
deployed,
but
just
it's
going
to
be
off
by
default
at
first
right,
and
so
people
are
going
to
want
to
know
like
well.
Should
I
turn
this
on
and
if
you
say
like,
oh
well,
it
does
appear
that,
like
when
I
send
an
e
no
option
to
this
person
on
getting
one
with
the
B
bit
set
properly
back
and
that
that
they're
our
path
appears
to
be
clear
through
this
network.
Then
that
might
encourage
people
to
turn
it
on
to
configure
it
on.
So.
C
I
So
the
other
one
has
to
be
able
to
ignore
it
anyway,
because
and
fall
back
to
that
clear,
fixed
anyway,
so
it
doesn't
affect
it
doesn't
affect
any
implementation
if
you
allow
it
or
not,
it
can
allow
it
can.
Allow
you
to
you
know
to
you,
know
probing
in
any
cases
where
you
for
a
point,
for
example,
want
to
do
you
know
measurements,
how
many
things
works,
and
you
know
this
without
one
of
the
things,
for
example:
ipsec
we
doing
better
revenge.
It's
always
that
you
sent
a
proposal
and
you
get
same
response,
regular
basis.
I
You
know
enabled
at
all,
but
it's
too
running
or
if
you
had
just
available
from
corporations.
This
would
allow
you
to
the
propane.
Without
you
know,
caring,
if
that
don't
support,
CC,
pink
or
epic
ripped
or
TLS
racer,
so
you're
in
favor
or
actually
I,
think
it
because
I
mean
it
doesn't
affect
the
normal
implementations
without
because
I
mean
yes,
you
could
you
just
put
it
in
there
and
you
know
other
ones,
just
okay,.
A
Yeah
Kyle
rose
yeah,
the
the
two
cases
it
helps
are
the
probing
case
and
the
preventing
spurious
resets
case
and
I
think.
Maybe
what
we
want
to
do
is
kind
of
go
into
more
detail
on
the
mailing
list
on
the
on
the
the
ups-
and
you
know
the
upsides
and
downsides
of
this,
because
myriad
pointed
out
some
some
good
downsides
to
doing
this,
including
option
space
and
the
fact
that
you
that
you
know,
ideally,
you
would
like
an
implementation
to
have
a
way
to
say
really
turn
it
off
and
don't
even
send.
A
You
know,
don't
even
recognize
that
this
option
exists,
but
that
adds
complexity
to
the
API,
so
I
think
outlining
it
on
the
mailing
list
and
then
getting
making
a
consensus
call.
There
is
probably
the
right
way
to
do
that,
because
I
just
want
to
make
sure
that
everyone
understands
all
of
the
the
implications
of
this
fully
before
making
a
decision.
Good.
E
B
B
E
F
C
F
I
would
you
have
to
set
the
be
bit
to
one
so
wouldn't
exactly
reflect
it,
and
but
basically
the
idea
is
if
you,
if
I
send
a
TC,
if
I
send
tcp,
you
know
to
some
server
and
then
the
server
like
support
ccpe
know
but
like
doesn't
want
to
actually
encrypt
it
would
just
send
back
an
empty
TCP.
You
know,
would
be
equal
one,
so
ba3
bite
option,
including
the
kind
kind
length
and
the
global
option,
would
be
equal
one
and
no
proposed
taps,
and
then
encryption
would
be
disabled.
F
F
It
could
also
be
the
initial
Sam
I,
don't
know
that
doesn't
seem
like
as
useful
just
in
terms
of
functionality
in
the
spec.
If
we're
gonna
define
what
it
means
to
have
no
tap
IDs,
say
it's
zero
or
more
tap
ideas
instead
of
one
or
more,
we
might
as
well.
Have
it
both
but
I,
don't
see
or
probably
more
useful
and
are
in
reply
from
the
server,
but
we
could
also
have
it
be
from
the
sin
for
like
explicitly
like
measurement
stuff.
I.
F
F
B
Good
heart,
I
think
the
path
forward
sounds
like
proposed
proposed
two
diff
on
the
list
proposed
that
the
text,
if
on
the
list
and
it
comes
out,
is
comes
out.
As
short
as
you
think
it's
going
to
come
out,
we
could
leave.
We
can
write
a
consensus
calling
the
list
of
this,
but
but
my
concern
up
there
isn't
so
much
technical
merit
or
lack
thereof.
It's
a
colonizer
it
it's
a
reasonably
short
path
from
here
to
work
or
blast
call
because
I
know,
I
know
that
one's
when
I
know
that's
going
to
be
interesting.
Okay,.
A
B
A
H
H
So
the
second
round
trip
is
about
symmetric,
Seifer
negotiation
and
exchanging
public
key
material.
So
in
this
case
the
act
of
opener
saying
escort,
aes-128
and
256.
It
sends
its
nonce
and
it's
public
key
and
the
passive
opener
selects
the
symmetric
cipher
this
case
aes-256
and
sends
its
own
non,
send
its
own
public
key
material.
So
we
basically
extended
TTP's
three-way
handshake
by
adding
one
extra
leg
for
negotiation,
and
the
fundamental
reason
for
this
was
that
you
know
public
keys
are
large.
H
So
after
we've
done
this
key
exchange,
both
ends
compute
their.
You
know
their
do
their
diffie-hellman
or
whatever
algorithm
they're
using
them.
They
get
their
key
agreement,
result
which
is
not
transmitted
on
the
wire.
Obviously,
that's
how
you
get
your
protection
against
passive
eavesdropping,
so
we
take
all
that
information,
the
key
agreement,
material
and
all
the
bits
of
the
handshake
and
the
hash
that
all
together
and
you
you
get
your
session
secret
from
that.
You
derive
your
session
ID.
H
So
you
can
see
from
this
that
intuitively,
if
you
create
a
TCP
connection
and
the
two
session
IDs
match,
it
means
that
nobody
tampered
with
your
handshake.
Nobody
modified
your
bits
in
the
unit
one
or
nobody
modified
your
publicly
or
something
like
that,
and
that's
how
applications
could
do
their
authentication
top
of
TCP
creek
by
verifying
that
the
session
IDs
match
and
from
that
session
secret.
You
also
derive
all
your
keys
for
your
symmetric
ciphers,
your
max
and
essentially
for
your
authenticated
encryption.
H
So
once
you
have
your
key
material,
how
do
we
actually
encrypt
the
data?
So
we
take
the
user
data
and
we
create
records
out
of
it.
So
we
have
our
own
framing
the
user.
You
know
in
the
user,
data
of
the
T
speed
portion
and
we've
got
a
control
bite,
a
cipher
text
length
and
a
cipher
text,
so
the
controlled
by
currently
has
only
one
bit
defined,
which
is
the
rekey
bit
and
that's
used
for.
I
You
know
rotating
your
keys
question.
Yeah
I
have
actually
question
about
previous
lighter
one
of
things
I
would
say
so
so
you
put
both
the
Holy
no
transcript.
We've
mean
this
a
secret.
You
know
this
means
that
if
middle
box
are
anything
necessary
single
bit
there,
this
will
generate
the
different
keys
it's
built,
and
how
do
you
detect
that
that
the
keys
are
wrong
because
they
take
us
one
of
the
problems
with
ike
ike
wash
one
was
that
they've
used
to
same
thing?
I
I
F
I
Actually
I
was
to
get
bite
more
or
less
that
they
eat,
because
there
is
there's
no
possible
that
there's
something
else
wrong
with
this,
and
it's
it's
usually
better
to
get.
You
know
clear
feedback
that
okay,
something
wrong
una,
authentication,
failure
right
and
do
something
else
than
to
just
get
you
know,
I
get
random
garbage
in
because
I
my
decryption
fails
for
it
for
every
pocket.
After
that
point,
so
it
yeah,
but
it
was
still
getting
out
indication
failure
in
in
that
you
know
you
don't
get
weeded
back
at
okay,
there's
something
wrong.
The
system.
I
B
H
Okay,
cool
so
yeah,
so
that
is
a
difference
with
us
which
has
key
verification.
Okay,
good,
so
we
got
our
keys
and
we
frame
our
user
data.
I
was
saying:
there's
a
controlled
by
currently
there's
only
one
bit
defined
in
that
controlled
by
which
is
a
rekey
bit
used
for
rotating
keys
and
long
live
session,
there's
a
length
and
then
there's
a
cipher
text
inside
the
ciphertext.
H
We
replicate
some
of
the
TCP
flags,
so
we've
got
a
flag
bite.
Currently
we
replicate
the
fin
bit
and
the
urgent
bit
so
we
could
support
you
know
clean
connection
shut
down
an
urgent
data.
If
urgent
data
is
present,
we
actually
have.
We
include
the
urgent
pointer
and
then
we
just
follow
it
with
the
actual
application
data,
and
all
of
this
is
both
Mac,
then
encrypt
that
it's
authenticated
encryption.
H
So
I
want
to
talk
a
little
bit
about
session
caching,
because
that
was
one
of
the
biggest
change
since
Berlin.
So
if
I
talk
to
you
in
the
past
and
I
want
to
talk
to
you
again,
we
could
optimize
things.
We
don't
need
to
do
public
here,
operations
anymore,
but
what
we
could
do
is
we
could
take
our
previous
session
secret
and
compute
the
next
session
secret
for
the
next
communication
I
have
with
you
and
based
on
that
I
could
compute
the
you
know
the
next
session
ID
and
the
next
encryption
keys
and
so
on.
H
We
could
keep
doing
this
essentially
forever
until
we
just
clear
our
cash.
So
that's
good.
It
saves
us
computation
power,
you
don't
have
to
do
public
key
operations
anymore,
but,
more
importantly,
I
think
it
saves
us
on
latency,
because
now
we
could
re-establish
a
TCP
crypt
connection
in
the
existing
three-way
handshake.
We
no
longer
have
to
add
that
extra
fourth
leg,
so
the
way
it
works
is
it's
very
similar
to
the
original
handshake.
H
We
say:
hey
I
support,
you
know,
p
5
to
1
and
p
5
to
6,
but
in
this
case,
what
we're
signaling
in
the
p55
21
case
is.
I
want
to
resume
a
session
with
this
session
ID
and
in
this
example.
It's
you
know,
392
and
so
on.
So
we
use
iNOS
variable
length,
a
sub
options.
It's
a
signal
session
resumption.
So
we're
basically
saying
we
want
to
resume
that
previous
session
of
p52,
with
the
set
with
this
new
session
ID
and
then
in
the
response.
H
If
session
resumption
was
successful,
we
reply
yeah
sure,
let's
do
that
and
we
use
a
variable
length
sub
on
tenth.
So
basically
we're
saying
yeah
resume
521,
it's
a
variable-length
sub
and
nothing
there
so
that
one
bit
lets
us
distinguish
whether
it's
a
fresh
key
negotiation
or
whether
it's
a
resumption
attempt
and
then
we
just
send
a
knack
with
the
email
option,
and
at
this
point
we
could
start
sending
encrypted
data
right
away.
H
So
that's
how
we
do
session
resumption.
This
is
a
little
bit
different
from
the
original
TCP
crypt
spec
were
or
hint
back
from
a
couple
of
meetings
ago,
where
we
would
have
an
explicit
tip
for
session
resumption.
So
it
would
be
something
like
TCP
crypt
dash
session
resume
and
then
that
could
have
been
that
could
have
meant
any
cipher
effectively
here
we're
being
explicit
and
saying
what
the
cipher
is,
and
that
has
some
nice
properties
which
I'll
talk
about
later.
H
So
really
what
changed?
Since
the
last
meeting
was
we
cleaned
up
session
assumption,
so
one
of
the
things
we
did
is
that,
if
we're
resuming,
you
know
p
five
to
one
that
also
implicitly
means
that
we're
willing
to
start
fresh
with
p
521.
So
we
don't
have
to
say,
hey
resume
key
521
and
also
by
the
way,
include
a
couple
of
extra
bytes
saying
we're
also
willing
to
do
five
to
one
fresh,
so
we're
kind
of
saving
options
space
there
because
it
seems
like
this
is
a
pretty
common
use
pattern.
H
The
other
thing
we've
done
is
we
explicitly
forbid
resuming
you
know
two
sessions
in
the
same
connection,
so
I
can't
say:
resume
five
to
one
session
idx
and
resume
five
to
one
session
ID.
Why?
Because
now
this
creates
ambiguity,
and
it
also
feels
like
unnatural
I.
Don't
you
know,
there's
no
real
application
for
this,
so
we
explicitly
disallow
that
you
can
only
resume
one
specific
session
intuitively
makes
sense
and
also
something
that
changed
that
I
briefly
mentioned
from
the
previous
meeting
in
Berlin.
Actually,
this
change
happened.
H
Berlin
is
this
notion
of
being
explicit
about
which
cipher
your
resuming,
so
we
have
an
API
after
you
connect
the
TCP
crib.
That
tells
you
what
cipher
was
used
in
your
public
key
negotiation.
Previously
we
used
this
generic
session
resumption
tip
and
our
session
ID.
It
sorry
in
our
session
resumption,
and
that
would
mean
that
if
the
app
asked
what's
I
forgot
negotiated,
he
would
get
back.
This
answer
saying
you
know
the
session
resumption
tap,
which
is
not
very
informative.
H
So
these
are
kind
of
the
you
know
the
main
changes
that
happened
since
the
last
meeting.
With
regards
to
session
resumption,
there
were
a
few
other
changes
in
TCP
crypt.
Some
of
them
were
where
we
are
explicitly
disabled
disallowing
sending
data
in
the
sin
segment.
So
you
know,
if
you
want
to
do
stuff
like
TFO,
it
just
doesn't
work
out
of
the
box.
You
would
have
to
build
something
on
top
of
TCP
grip
than
you
know
like
David
mentioned
before,
and
we
also
move
the
TCP
crypt
specific
api's
to
the
API
documents.
H
So
now
the
TCP
crypt
document
just
focuses
on
Krypto
aspects.
Nassib
document
got
shorter
that
respect
to.
So
that's
really
it.
You
know
not
a
lot,
not
a
lot
changed.
I
feel,
like
you
know,
I've
been
saying
this
for
the
past
couple
of
meetings
in
terms
of
crypt
I
think
we're
getting
for
the
end.
You
know
it's
like
really
small,
tweaks
and
polishing.
The
you
know
we
haven't
gone
from.
You
know
packing
base,
that's
y
lv,
you
know
the
big
changes
already
happened
in
the
last
couple
of
years.
Now.
H
I
think
we're
really
getting
for
the
end.
So
in
terms
of
the
draft
yeah
like,
is
it
complete?
It
sounds
like
we're
getting
to
a
last
call
pretty
soon
the
implementation.
We
still
need
a
kernel
implementation.
We
personally
haven't
made
progress
on
that
and
also
which
was
mentioned
by
the
chairs.
We
are
always
seeking
for
independent
implementations.
I
think
this
is
where
we're
going
to
kind
of
weed
out
the
bugs
and
and
possibly
even
fine.
You
know,
ambiguity
in
the
spec.
You
know
if
somebody
actually
sits
down
and
tries
to
write
code.
H
B
I
Are
given
in,
I
think
you
should
try
to
you,
know,
use
the
chicago
hackathon
or
suchlike,
that
predicate
people
to
come
there
and
without
through
implementation
and
testing
and
so
on,
because
the
Teotl
s1
poetry
is
using
tacit
owns
throughout
the
interrupt
testing
and
writing
the
code
and
so
on,
and
I
would
expect
if
you
just
get.
You
know,
try
to
get
students
or
something
like
that
will
come
there
and
to
make
making
all
implementation
of
that
you
bring.
A
F
A
I
I
obviously
the
web
pateros
if
there
were
some
student
teams
this
time,
also
for
a
for
do
not
do
some
other
things,
and
I
was
thinking
about.
There
is
some
you
know
university
people
here
could
actually
you
know
try
to
get
anna.
Some
of
the
students
were
actually
working
from
there.
You
know
not
traveling,
actually,
the
ruptured
working,
no
over
the
lines
and
so
on
some
but
I
starts
to
get
but
I
I
don't
have
time
to
do
the
TCP,
crib,
sorry,
but
I
was
thinking
about.
That
would
be
something
that
actually
also
they
take.
H
B
C
Could
even
there's
also
a
new
initiative,
I
would
say
a
website
which
was
called
code
my
match,
and
it's
now
called
somehow
differently
forgot
name.
It's
a
website.
Basically,
I
can
say
what
what
you
need,
where
you
need
implementations
and
people
can
look
up
if
they
want
to
do
an
implementation.
I
can
send
information
the
nativist
it.
F
B
F
Yeah
David
misers
that
that's
the
idea,
yeah
I
think
you
were,
you
know
I,
as
I
was
doing.
The
slides,
I
realized
were
missing
this
mandatory
bit
and
then
maybe
there'll
be
another
option
to
stay
like
you
know,
disabled
completely
versus
like
respond
with
an
empty.
You
know
option
but
I
think
we're.
You
know
a
very
small
patch
away.
From
being
final,
this
look.
B
My
inclination
is
to
sequence.
The
last
calls
to
send
to
do
a
first
last
call
on
the
protocols
take
ino
and
TCP
crypt
as
a
package
in
one
work
with
last
call
and
that
one
might
run
a
little
long
because
we're
going
to
have
to
go
find
outside
experts.
We
know
where
to
find
at
least
one
expert
on
the
options
I'm
sure
we
can
find
one
or
two
other
other
dtp
people
take
a
look.
Kyle
probably
has
some
some
likely
suspects
to
go
triple
check
the
crypto
and
then,
but
not
include
the
API
document.
F
B
F
B
F
A
A
Id
feeds
the
transcript
and
and
some
other
information,
the
the
key
agreement
and
whatnot,
and
so
is
it
necessary,
for
instance,
for
that
for
that
session
ID
to
in
order
to
in
order
to
have
the
the
security
properties
that
we
want
out
of
this
protocol?
Is
it
necessary
for
that
ID
to
be
to
be
unpredictable
or
is
it
or
does
it
just
need
to
be
unique
overall
time
so
that
you
can't
have
you
can't
possibly
have
two
connections
with
the
same
ID
unless
they
were
engineered
by
two
endpoints
colluding,
which
is
kind
of
dumb?
A
So
so
that
was
the
first
question
that
I
had
and
there's
actually
like
a
it's.
It's
probably
written
better
in
the
email
that
I
sent
so
so,
if
you
want
to
take
a
look
at
that,
it's
on
the
CFR
gmail
enlist
from
october
second,
and
actually
got
some
really
good
responses
to
this.
The
best
response
I
got
was
off
list
and
it
was
by
someone
named
Nataniel,
el
I.
Don't
know
if
any
of
you
guys
know
who
that
is,
I,
don't
know
who
who
what
L
is.
A
But
he
sent
me
a
fairly
long
analysis
of
of
how
he
you
know
of
how
the
cryptid
works
and
what
properties
he
thinks
is
that
it
requires,
and
so
I
think
I
sent
that
to
you
guys
if
anyone
else
wants
to
see
it
I'm
happy
to
forward
it
along
I
didn't
want
to
put
it
on
the
list
because
he
didn't
respond
to
the
list,
but
but
I'm
happy
to
give
it
to
anyone
individually.
So
just
send
me
send
me,
or
they
did
an
email
and
I
could
forward
that
along
and
then
there
were.
A
There
were
some
other
responses
as
well
that
were
of
interest
and
those
all
went
to
the
list.
So
that
was
the.
That
was
the
first
question.
So
the
second
question
that
I
sent
was
around
the
the
generic.
How
does
the
generic
nature
of
Ino
as
a
negotiation
protocol
for
Tepes
a
feed
into
what
the
requirements
for
session
IDs
are
right,
and
so
the
idea
here
is
that
that
you
use
an
application
that
makes
use
of
you
know
in
mandatory.
Application-Aware
mode
is
assuming
I
mean
it's
it's
it's.
A
It's
mandating
that
that
you
know
is
available
and
that
there
is
some
tip
that
is
in
common
between
two
machines
and
it
produces
a
session
ID
that
is
then
used
for
endpoint
authentication.
What
properties,
for
instance,
does
that
session
ID
need
to
have
and
what
properties
should
be
no
guarantee
to
applications
that
are
mandatory
application-aware,
so
the
the
situation
that
I
was
concerned
about
I,
know
I
sent
an
email
about
this
like
a
year
ago
and
we
stood
around
for
a
while
on
it.
I
didn't.
A
In
that
case,
publishing
a
signed
list
of
session
IDs
to
you
know
to
a
public
web
server
and
using
that
as
your
out-of-band
authentication
channel
is
not,
is
obviously
not
something
you
want
to
do,
because
you
might
be
able
to
derive
session
piece
from
that
or
whatnot
right.
So
going
back,
I
made
these
slides
in
a
rush,
so
I
didn't
get
them
in
quite
the
right
speaking
order,
but
like
so
one
of
the
one
of
the
questions
I
had
was
well.
Does
the
session
ID
need
to
be
computationally
indistinguishable
from
random?
A
Well,
not
really,
and
in
fact
it
isn't,
because
the
first
byte
is
always
is
is
predictable,
or
at
least
it's
in
a
small
space
right.
So
and
even
even
if
the
session
ID,
even
if
every
bit
of
the
session
ID
was
slightly
biased
toward
one,
for
instance,
it
would
still
be
secure
as
long
as
there
was
enough
entropy
in
the
whole
thing
to
prevent
someone
from
from
guessing
it
and
there,
and
as
long
as
there
are
mechanisms
in
place
to
guarantee
that
its
unique
overall
time
right.
A
So
what
I
really
would
like
is
some
is
some
generic
crypto
guidance
on
the
right
way
to
phrase
some
of
the
properties
that
we
want
out
of
this
thing,
because
I
think
like
right
now,
they're
either
over
specified
or
under
specified
and
I'm,
not
entirely
sure
which
I'm
also
not
sure
that
this
is
that
this
is
worth
all
the
trouble,
because
I
think
this
is.
This
may
be
one
of
the
situations
where
people
see
the
spec
and
they
kind
of
they
know
what
it
means.
F
Yeah
so
David
Mazouz,
so
I
think
that
in
you
know
in
general
the
sort
of
what
we've
learned
and
encrypt,
though,
is
you
want
to
like
over
specify
these
things?
Like
most
people?
Don't
actually
you
know
most
attacks,
don't
actually
take
the
form
of,
like
you
know,
a
chosen
ciphertext
attack,
but
the
idea
is
that
like,
if
you
can
survive
vacuum,
if
your
algorithm
can
survive
that
game,
then
it
can
survive
any
game.
So
we've
attempted
in
the
Eno
draft
to
be.
F
A
B
That
David
black,
if,
if
specifying
it
that
way,
which
is
that
the
the
first
byte
is
it
is
on
its
own
and
everything
else
is
computation-
is
indistinguishable
from
random
is
sufficient
to
solve
the
problem.
There
may
be
a
tighter
necessary
condition,
but
we
don't
have
to
go
looking
for.
We
simply
need
to
be
convinced
that
that
the
problem
is,
we
understand,
is
solved.
I.
F
F
There's
no
other
way
to
do
it
right.
There
is
no
no
cryptographers
out
there,
so
you
know
they
say
you
can't
find
a
sháá
512
collision.
You
can't
find
a
catch
a
collision,
but
nobody
is
assuming
that
you
can't,
you
know,
provide
one
message
that
who's
sha-512
hashes
the
same
as
another
messages
like
ketchup,
hash
right
like
that's,
just
not
a
common
assumption.
People
are
making.
We
can't
make
those
kinds
of
assumptions
across
this
all
right.
B
A
Yeah
I
think
one
of
the
just
again
I
think
this
is
more
like
food
for
thought
than
anything
else,
and
I
want
to
get.
What
I
really
want
is
some
input
from
from
cryptographers
who
are
who
have
worked
on
stuff
like
this
before
and
just
sort
of
understand,
maybe
maybe
get
a
better
understanding
of
what
they
think
these
properties
are,
should
be
and
should
be
called.
You
know,
like
we
talked
about
like
unlink
ability,
for
instance,
right
to
protect
to
protect
client
privacy.
What
does
that
really
mean
like?
A
Is
there
a
formal
definition
for
that
somewhere
and
if
so,
what
does
that
mean
for
like?
Does
the
session
ID,
as
defined
in
TCP
crypt,
achieve
that
and
does
TV?
You
know
properly,
require
that
so
I
I
mean
I
don't.
I
don't
think
that
this
this
stuff
is
going
to
hold
up
working
with
less
call
like
that's,
not
my
intent,
it's
more
just
to
get
input
and
see
if
there
are
ways
to
refine
the
the
language
and
if
there,
if
there
aren't,
then
that's
fine
too
I
mean
David.
F
Again,
to
be
clear,
unlink
ability
is
not
provided
by
session
assumption
right.
This
is
a
trade-off
right,
so
one
one
or
the
other,
but
if
you're
behind
a
not
like
in
your
resuming
TCP
crepes
look,
even
though
at
the
API
level
they
look
the
same
but
like
obviously
someone
could
instrument
there
Colonel
or
their
TCP
stock
and,
like
figure
out
that
they're
using
session
resumption
to
the
same
person.
D
This
is
dkg
just
wondered
whether
there
are
two
different
kinds
of
ability.
What
is
unlink
ability
to
the
pier
the
others,
unlink
ability
to
the
network
and
I
think
it
does
session
resumption
here
does
provide
on
my
ability
to
the
network.
So,
just
again,
if
we're
talking
about
being
clear
about
what
we're
specifying
there
are
just
say,
unlike
ability,
unlink
ability
to
whom
and
dkg.
B
Could
you
see
the
microphone
because
I
got
a
question
for
which
you
might
have
have
an
insightful
answer?
Discussion
is
really
interesting
on.
It
sounds
like
we're.
Looking
for
some
precise
terms
this.
This
working
group
is
not
the
place
to
write
those
definitions
they
buy.
They
belong
somewhere
over
in
the
security
areas
response
to
of
the
pervasive
monitoring
and
the
like.
Where
do
you
do?
You
have
any
idea
where
we're
in
security
area
that
ought
to
be
I.
D
B
D
A
D
B
Right
at
the
very
least,
we
could
pray
I'm,
sorry
at
the
mic.
Folks,
at
the
very
least,
we
could
record
a
a
sense
that
that
something
more
general
ought
to
be
done
and
we
would
have
found
it
useful
if
we
could
have
gotten
to
these
terms,
but
it's
probably
a
security
area.
Uh-Uh-Uh
activity,
not
not
not
transport,
let.
D
Me
just
say
that
this
is
dkg
and
I'm,
not
sure
that
something
more
general
should
have
been
done
right.
This
is
we
have
a
specific
use
case
here,
where
specific
needs
and
I
think
that
if
we
do
this
specific
to
TCP
crypt,
that
would
be
a
useful
contribution
and
if
that
turns
out
to
be
generalizable,
that's
fine,
but
I
don't
want
to
block
this
kind
review
were.
B
All
invited
women
on
the
head
that
the
objects
are
trying
to
make.
I
panted
garbled
is
if
somebody
had
written
down
definitions
of
the
relevant
crypto,
oriented
properties
like
privacy
and
virginal
mobility,
and
what
that
Kyle
could
have
just
pointed
to.
We
would
have
found
that
useful,
but
not
having
that
should
not
block
us.
I
agree.
A
Completely
yeah
I
mean
I
again,
I
wasn't
suggesting
holding
up
the
documents
on
this
basis,
but
it's
more
like
education
and
dissemination
of
knowledge
about
the
right
ways
to
phrase
these
things
it
seems
like
we
need
to.
It
seems
like
that.
Stuff
doesn't
actually
exist
at
the
moment
that
we
need
to.
We
need
to
build
up
that
knowledge,
maybe
have
a
set
of
informational
dogs
that
that
describe
these
properties
more
precisely.
More
formally.
K
B
B
Yeah
I
think
that's
it
any
other
comments,
questions
dead,
cats,
rotten
tomatoes
that
was
a
shockingly
short
session.
Lots
of
really
good
songs
like
thinking
about
what
happened
here.
More
importantly,
what
didn't
happen
here?
I
think
I
agree
with
nebula
who
said
this.
This
really
does
feel
like
we
are.
We
are
at
the
point
where
we
r
group
last
call
is
the
next
step
and
the
drafts
are
ready.
So
many
thanks
to
all
the
hard
work
from
the
team
from
the
team,
that's
working
on
the
giraffes,
and
I
think
I
think
this
this
is.
B
I
think
the
chair
is
going
to
have
to
do
a
little
bit
of
well
before
we
go.
We're
gonna
have
to
run
a
round
of
a
round
up
a
few
known,
expert,
reviewers,
I
think
we're
looking
for
for
ween
top
of
my
head
2
1402
for
tcp
crypt.
We
know
we
know.
Joe
touch
is
going
to
be
one
of
one
of
the
Eno
experts.
I
only
have
to
find
one
more
kyle
has
fine
too
fabulous.