►
From YouTube: IETF99-TLS-20170719-0930
Description
TLS meeting session at IETF99
2017/07/19 0930
https://datatracker.ietf.org/meeting/99/proceedings/
E
F
B
B
C
B
We
go
ok,
so
we
have
our
blue
sheets
going
around.
Remember
when
you're
talking
at
the
mic
to
please
state
your
name
so
that
the
minute
takers
and
scribes
can
include
that
in
the
notes-
and
as
always,
please
be
professional
I
know,
there's
a
lot
of
passionate
discussion
that
may
occur
today,
but
let's
try
to
keep
it
all
friendly.
B
G
B
Can
you
I
need
to
just
get
to
that
window
yeah.
G
Okay,
okay,
so
we're
on
draft
21,
hopefully
close
to
the
end
next
slide
right,
so
I
guess
the
boss
call
number
2
ended.
Yesterday
we
had
a
very
small
number
of
issues
raised:
I'm,
just
gonna
run
through
them,
one
that
we
did
and
what
the
issues
were
next
slide.
G
So,
as
we
discussed
last
time,
my
shortened
HK
TF
labels,
the
scraping
off
a
few
extra
hashes
that
weren't
doing
us
any
good
and
we're
just
rotating
the
labels
are
now
a
goofy-looking,
but
they're
shorter
took
quite
a
bit
of
effort
to
turn
that
to
get
to
get
them
like
everything
into
one
hash
block,
but
we
did
find
they
do
that's
in
20,
as
per
also
discussion,
we
made
the
post,
handshake,
client
authentication,
option
and
there's
an
extension.
She
hit
that
option.
G
Tellis
div
and
other
places
Cole
McCarthy.
He
raised
her
when
she's
about
to
run
trip,
so
the
two
issues
he
raised
were
first,
that
PSK
n0h
have
both
didn't,
have
fantastic
42c
properties,
which
is
a
little
annoying,
and
we
came
up
with
kind
of
a
nice
trick
to
improve
forward
secrecy.
In
those
cases
it
doesn't
help
if
you're
using
ticket
specifically
refusing
a
session
cache.
Basically,
what
we
did
is
added
a
nonce
to
each
new
day
session.
Take
a
message
so
that
each
the
PSK
for
us
actually
take
a
message
is
distinct.
G
So
that
means
that
you
can
issue
twenty
session
tickets.
I
mean
the
tickets
in
some
level
and
if
you're,
using
a
if
you're
using
a
session,
cache
suppose
did
some
tickets,
then
you
can
just
basically
erase
them
one
at
a
time
and
once
they're
erased
you
can't
use
move,
go
back
to
climb
back
up
the
stack.
So
this
is
a
trivial
change.
We
made
well
sided
this
extensive
new
section
on
zero
and
trip
and
into
replay
I'll,
be
talking
a
little
more
about
that.
G
But
the
basic
idea
was
we
sort
of
taken
after
we
realized
that
we
couldn't
like
entirely
salty
and
do
we
put
probably
brassiere
on
trip.
We
took
the
sort
of
very
nihilistic
attitude
which
is
like
nothing
can
be
done
and
I
think
Cole
pulls
back
and
said.
Well,
maybe
we
should
do
something,
so
we
documented
several
techniques
for
printing
for
minimizing
the
replay
cost,
though
not
eliminating
entirely
and
there's
a
piling
and
stuff
in
there.
That
went
through
a
bunch
of
as
a
discussion
next
slide.
Ooh.
G
G
G
That
I
could
talk
about
this
anyway.
So
during
the
discussion
of
this
in
to
be
played
mechanisms,
there
was
sort
of
a
bunch
of
back
and
forth
to
that.
So
I
guess
it
just
took
a
step
back
that
all
the
methods
we
have
basically
are
bounded
into
replay
mechanism.
What
I
mean
by
that
is
that
the
only
guarantee
we
play
non
replay
within
a
zone
of
consistency.
So
if
you
have
like
a
single
server,
then
you
even
have
to
replay
that
server.
G
If
you
have
a
cluster
of
servers
that
you're
all
sure
consistent
state,
you
can
enter
you
play
between
that
cluster,
but
you
have
two
clusters
that
don't
share
like
it's
just
a
state.
You
don't
get
you
get
sort
of
when
we
played
per
cluster
and
that's
the
best
we
had
to
do
so.
That's
the
way
it
is
and
on
the
list
of
weddings,
right
I
do
that
and
the
all
of
these
techniques
are
out
of
should,
namely
we
say
we
should.
G
G
G
And
my
sense
was:
there
was
a
consensus,
but
part
of
that
sense
came
from
talking
to
Victor,
Vasily,
EV
and
so
I
talked
to
him
a
little
more
and
he
he
he
posted
this
PR,
basically
last
night,
which
on
representa
what
he
thought
he
could
live
with
or
think
Ben
also
can
live
with,
which
basically
requires
that
you
do
something
to
provide
it
boundary
any
replay
with
the
consistency
zone
and
doesn't
require
any
specific
technique,
and
this
isn't
a
must
level.
So
I
guess
I
can
look
I
think
we
can
live
with
this
I.
G
Don't
anybody
else.
Has
any
objections?
I
mean
it's
pretty
easy
to
sort
of
just
claim.
It's
pretty
easy!
If
you,
if
you
don't
want
to
be
conformed
in
here,
to
just
sort
of
claim
that
all
your
business
is
doing,
because
this
is
owns
our
one
machine
or
not
DS
Veron
trip.
So
is
anybody
object
to
having
a
requirement
like
this
and
I'm
sorry
that
they,
this
PR
just
came
in
last
night?
That's
what
it
is.
I
G
I
G
G
I
I
G
Right,
the
previous
life
there
we
go.
So
if
you
look
at
this
HTF
expanded
label,
it
has
this
thing
which
is
labeled
hash
value.
It
turns
out
that
we're
using
in
cases
where
the
thing
that
my
name
wasn't
hash,
so
this
kind
of
seems
annoying
in
semantics
and
Martin
in
size
of
PR
to
change
this
on.
That's
that's
easy
enough.
G
So
we're
just
changing
hash
the
context,
but
it
also
noticed
we
hi
like
how
many
increasing
at
the
time
of
looking
at
this
I,
also
noticed
that
there's
all
these
times
we
use
derive
secret,
which
then
basically
passes
this
thing,
which
is
supposed
to
be
hashed
into
H
KDF
label.
Even
the
thing
that's
being
hashed
is
basically
a
6-0
lengths
ring.
G
So
we
have
all
these
places
in
our
code
when
we're
like
taking
shots,
you
56
of
like
an
empty
string
and
passing
that
into
eh
KDF
flavo
expand,
and
this
isn't
like
inherently
wrong
your
sister
for
stupid
and
irritating-
and
it's
just
is
nested
by
the
by
the
API
I
happen
to
end
up
with
here.
So
I
think
it's
probably
worth,
even
though
it's
annoying
to
change,
I
think
it's
probably
worth
saying
and
I
can
figure
out
exactly
I'll
do
roughly
say
that
you
can
pastor
I've
secret,
no,
a
null
value.
G
Anybody
who's
implementing
this
have
an
opinion
on
it.
I
have
and
I
have
that
opinion,
but
perhaps
other
people
feel
differently
empty,
give
an
opinion.
I
K
G
H
G
I
won't
leave
it,
as
is
a
lot
about
next
line.
It's
the
last
piece
of
it
is
a
previous
slide
must
be
a
bit
irritating
news,
we're
starting
to
deploy
this
in
Chrome
and
Firefox
and
Facebook's
doing
so
as
well
and
and
we're
starting
to
see
increased
connection
failure
rates
it's
hard
to
get
clear
measurements.
I've
heard
numbers
anywhere
between
one
in
ten
percentage
points
on
the
numbers.
G
When
you
turn
on
one
three,
it
only
happens
when
the
server
accepts
one
three,
it
doesn't
happen
when
the
client
sends
it
so
something
that
the
problem
apparently
is
the
wrong.
Apparently,
is
that
when
the
handshake
is
accepted,
not
that
not
these
tensions
themselves,
so
the
problem
appears
to
be
middle
boxes
of
some
kind.
We
know
of
some
little
boxes
with
requesting
the
failures.
Specifically,
we
don't
that
doesn't
account
for
all
of
them.
So
there's
a
bunch
of
possible
things
we
can
do.
G
One
of
them
is
to
nothing
and
just
sort
of
you
know
gradually
use
fallback
and
I'm.
The
middle
boxes
fix
that
actually
may
not
be
crazy
depending
how
these
numbers
are
on.
There
are
two
proposals,
one
by
Kyle
nekritz,
which
is
to
make
the
connection
look
less
like
tail
as
we
went
to
buy
basically
throbbing
the
content
type
of
the
first
server
hello.
The
server
call
a
message
on
the
Facebook
reports:
does
it
improve,
improves
the
error
rate,
some
suppose
here?
G
So
you
may
want
to
talk
about
that
and
then
David
Benjamin
I
know
has
been
looking
at
making
the
flight
look
more
like
one
point,
two
and
I
think
Kyle's
adjusted
this
as
well,
but
basically
look
like
a
resumption
handshakes.
If
you
don't
get
freaked
out
by
the
data,
as
I
said,
the
third
thing
we
can
do
when
we
did
the
1
1
2
2,
1
1,
the
one
to
transition,
people
just
did
fall
back
and
they
and
basically
gradually
fix
the
middle
boxes.
G
Depending
on
how
big
the
error
rate
is
that
maybe,
if
I
have
all
possibilities
well
and
we've
been
looking
in
Firefox
about
how
does
tell
people
their
middle
box
you're
screwed,
so
they
could
report
them
so
between
us
and
Chrome
and
Facebook
and
final
clearance
where
people
were
collecting
data
on
this,
so
I
think.
Well,
hopefully,
that's
a
couple
months.
We'll
have
much
better
data
on
you
know
whether
anything
he's
done
at
all
and
if
so,
what
the
changes
are.
G
Hopefully
the
changes
will
be
outside
the
encryption
boundary,
so
it
will
only
be
just
like
annoying
wire
format,
protect
pretending
together
things
that
are
not
so.
Anybody
wants
to
actually
talk
about
the
data
here
or
wants
to
volunteer
to
help
that'd
be
great,
otherwise,
expense,
not
pay
for
me
and
others.
Perhaps
real
soon.
I.
G
I
think
it
depends
on
what
what
what
we
see
I
think
we'll
have
we'll
have
a
real
have
data
on
all
the
approaches
people
suggested
relatively
soon,
I
would
say
in
the
next
four
to
eight
weeks.
Okay,
it
takes
a
little
while
to
get
things
in
to
release,
but
we
definitely
try
them
on
these
in
Patos,
and
that
gives
us
some
indication
where
they
work
at
all
so
well
that
we
have
that
definitely
two
updates
quite
soon
definitive.
Damn
it
a
little
longer.
G
E
E
I'll
repeat
it:
this
is
the
second
working
group
last
call
for
this
document.
If
you
have
anything
that
you
would
like
to
bring
up
now
is
the
time
to
get
to
the
microphone.
L
Hi
we
just
completed
working
with
last
call
on
this
on
this
extension
that
we've
received.
We
were
expecting
basically
zero
comments,
and
that
is
not
what
we
got,
but
we,
the
comments
for
the
most
part,
are
uncontroversial
and
pretty
straightforward.
So
you
know
so
we
here
we've
got
a
list
of
stuff
that
basically
needs
clarifying
language
and
I.
Think
it's
pretty
straightforward
things.
Like
the
placement
of
the
extension.
We've
got
some
text
that's
redundant
between
descriptions
of
what
to
do
in
in
TLS,
1.2
and
1.3.
L
We
need
to
make
it
clear
that
on
the
RRS
and
an
RS
that
needs
to
be
Jason,
our
cig
records,
there's
a
need
to
make
this
a
plural.
We
need
to
beef
up
text,
providing
reasoning
for
including
a
DNS
key
are
set.
We
updated
test
vectors
to
send
ago
eight
instances
of
TLS
servers
and
DNS
servers
remove
some
stuff.
This
document
describes
the
data
structure
in
sufficient
detail
that
the
implementers
can,
if
they
desire,
write
their
own
code
to
do
this.
L
This
is
a
stuff.
That's
leads
needs
a
little
bit
more
discussion.
This
first
one
is
just
incredibly
annoying
because
we've
been
oscillating
on
it,
since
the
first
instance
of
the
draft.
It's
my
sense
that
pretty
much
everybody
has
an
opinion,
but
nobody
has
a
strong
opinion.
So
she
mine
proposed
that
we
just
basically
go
with
a
reference
to
what
DNS
SEC
does
and
not
word
worried
about
canonicalization.
E
L
Okay,
the
use
of
the
UDP
label
for
quick
probably
needs
a
little
further
discussion.
It
doesn't
seem
difficult,
but
it
does
seem.
It's
need
a
little
more
thought,
disagreement
about
where
the
extension
should
be
located,
and
this
is
something
that
we've
gone
around
a
bit
on
in
the
past
again
so
again,
if
you've
got
strong
feelings
about
this,
now
is
the
time
possibly
add
some
text
about
TLS
client
DNS
data.
Caching,
again
this
is
something
that
would
help
possibly
implementers,
but
something
with
opinions
good,
so.
M
L
M
M
L
Okay,
that's
it
yeah
absolutely
and
whether
you
know
what
we
should
tell
client
implementers
about
how
to
handle
unexpected
irrelevant
or
extraneous
records
other
than
that
there
were
not.
You
know
there
wasn't
anything
that
seems
like
a
showstopper
which,
which
is
nice.
So
what
I'd
like
to
propose
is
that
we
read
the
draft
and
so.
L
L
O
G
Actually
realized,
there
was
a
one
more
thing
that
got
mentioned
on
the
mailing
list.
That
I
forgot
to
cover
has
a
presentation
which
I
think
is
trivial,
but
I
wanted
to
mention
it
so
right
now
the
the
certificate
types
the
server
certificate
type
extension
goes
in
is
supposed
to
Anna
stiphu
c't
message
like
pyramind,
which
added
this
last
like
for
the
last
minute
and
like
it
was
all
kind
of
half-baked,
and
so
the
odd
part
about
that
is,
it
seems
to
imply
you
could
have
like
the
end
entity.
Extension.
G
The
like
an
entity
have
like
a
x.509
extension
associated
with
it
and
the
and
like
the
others
to
forget
having
a
PGP
is
a.
It
was
just
nuts,
so
in
TLS
1.2,
like
obviously
these
extensions
just
applied
to
the
entire
handshake,
and
so
my
strongest
just
is.
We
just
contain
that
property,
which
is
like
I,
changed
the
TI
chained
to
entering
the
table.
That
says
that
that
thing
goes
in
there's
difficut
message
and
put
it
back
in
the
crypt
extension,
which
will
make
which
will
retain
the
1.2
behavior
and
that,
if.
G
Fancier
thing
where
you
can
have
like
multi,
multiple
certificates
with
different
types
in
the
chain
like
they
can
do
that
later,
but
I'm
just
trying
to
keep
like
the
one
point
in
functionality
functional
rather
than
try
to
improve
it.
So
I
mentioned
this
in
list.
Oh
Laurie
was
the
only
person
to
seem
to
care.
What's
it
all
and
it
seemed
to
okay
with
it,
so
I'm
gonna
make
that
change.
Unless
somebody
cares,
that
seems
like
the
least
risky
change.
Okay.
G
Thank
you
now
details
from
point
three,
not
not
too
many
things
have
changed
and
I'm
gonna
start
trying
to
do
a
burned-down
of
all
the
things
that
are
left
in
an
effort
to
get
done.
I
I
don't
want
this
take
as
long
as
last
time.
I've
got
other
things
to
do
so.
The
only
real
change
in
draft
one
is
this
AK
stuff.
We
talked
about
this
at
the
last
session.
G
As
a
reminder,
DTLS
historically
had
this
kind
of
funky
implicit
act
structure
where
receiving
the
server's,
like
the
receiving
the
other
side's
flight,
meant
that
you
were.
He
meant
that
your
flight
had
been
received.
So
this
seems
like
really
clever
like
when
I
did
it
to
myself,
but
I
think
it.
Currently,
it
wasn't
clever
in
terms
of
you
kind
of
a
pain
to
implement
the
whoa.
No,
no
I
need
the
previous
slide.
It's
kind
of
a
pain
to
implement
you've
got
like
no
congestion
feedback
at
all.
G
If
you
have
like
situations
where
you
have
like
something
spread
across
a
bunch
of
packets
like
the
server
certificate,
like
you,
don't
learn
anything
about
that,
and
so,
if
you
like
one
package,
just
reach
into
the
entire
flight,
which
is
really
sucky
and
also
on
you,
oh
every
time
you
had
like
the
last
message
of
flight,
it
was
always
goofy
because
you
had
likes
it.
You
had
like
sit
on
it.
G
Basically,
you
had
you
like
sit
on
that
message
for
a
while,
and
eventually
you
time
down,
the
side
of
the
other
side
must
have
received
it,
because
there's
I
was
like
prompting
it
by
sending
you
stuff.
Unfortunately,
when
we
add
a
new
session
ticket
to
Tillison
point
three
that
just
had
the
pattern
of
a
message
sent.
One
direction
that
was
never
like
responded.
Juice
is
not
obvious.
G
So
obviously
it's
a
sack
because
sacks
what
you
want
it's
kind
of
ripping
off
the
quick
structure
a
little
bit,
though
less
than
I
thought
I
was
going
to
so
the
structure
is
that
ax
contain
the
sequence
number
of
all
the
records
you
received
from
the
current
handshake
fluent
and
that
part
is
actually
pretty
important
to
terms
house
so,
obviously,
more
for
this
to
work
on
the
senders
need
to
maintain
a
map
of
which
handshake
fragments
go
in
which
records
that's
easy
to.
Do.
G
You
got
the
sliders
are
supposed
to
selectively
you're
transmitted,
namely
that
once
they
know
a
pregnancy,
they
shouldn't
be
retransmitting
it
you
can,
but
you
just
shouldn't
and
okay,
and
what
the
Act
does
stop
once
that,
once
you
get
a
knack
for
the
entire
flight,
you
have
to
stop
retransmission,
so
you
don't
get
putting
pong
I
very
deliberately,
made
it
a
separate
record
type.
If
you
make
it
a
handshake
record
type
which
I
think
Martin
originally
proposed,
then
you
have
to
act
that
just
not
gonna
work
at
all,
so
I
was
gonna.
G
I
G
The
other
thing
I
did
we
toyed
with
we
toyed
with
requiring
gak
all
the
time
and
really
implicit
act,
but
experience
with
winning
quick
has
taught
us.
That
was
a
bad
idea.
Quick
has
azad
structure
now,
where
you
have
things
which
advance
the
state
machine
and
then
acts,
and
you
can
be
in
a
state
or
like
you're,
sending
the
message
you
may
send
like
the
client
initial,
which
eventually
the
state
machine,
and
you
receive
a
message
from
the
server
that
tells
you
like
that
must
have
been
received
because
work
can
accentuate.
G
It
may
be
hearing
quick,
cuz
the
layering
structure,
but
we
don't
have
to
have
it
here.
So
the
point
being
that
you
have
basic,
essentially
two
ways
that
have
something
act:
one
is
you
get
the
next
flight
and
the
other?
Is
you
get
the
act
next
slide?
So
what
this
means
is
that,
of
course,
the
receiver
also
has
an
option
about
how
to
act
and
guidelines.
G
Look
like
this
that
if
you
can
move
the
state
machine
forward
using
with
the
state
machine
forward
when
you're
supposed
to
AK
is
when
you're
not
moving
the
state
machine.
So
if
you
receive
a
message,
it's
like
an
NST
that
doesn't
have
any
enhancement
response.
Obviously
we
have
to
act
that,
because
those
are
more
color
wise
and
then
there's
a
sort
of
fuzzy
text
about
when
it
looks
like
messages
might
have
gotten
lost.
So
what
does
that
mean?
This
is
off.
G
The
guidances
has
been
like,
of
course,
put
tcp
for
like
for
eternity,
but
the
general
guidance
is,
if
you
could
add
a
border
record,
then
you
ought
to
be
like
acting
that
to
indicate
the
design
of
order,
and
if
you
get
a
partial
record
and
then
you
don't
get
the
rest
of
the
next,
the
something
that
would
keep
advancing
the
state
of
the
transcript
within
a
reasonable
time
and
my
guidance
might.
G
The
guidance
I
used
was
a
quarter
of
around
trip,
but
I
was
intended
to
be
to
suggest
if
people
do
what
they
want
on
the
it's
not
really
a
problem.
If
you
basically
Act
every
time
you
receive
a
packet,
I
mean
it'll
work,
it
just
causes
the
network.
So
this
is
a
ten,
so
I'm
an
attempt
to
sort
of
balance
that
and
very
explicitly
you
don't
act.
G
Anything,
that's
not
a
handshake
message,
because
there's
no
way
to
talk
about
that
anyway,
and
it
also
creates
the
voices
problem,
an
acts
of
acts
which
also
is
a
huge
pain.
Yes,
next
slide.
Oh
sorry,
back
up
so
anyway,
this
is
the
draft.
That's
been
there
for
a
week
or
so
so
I,
don't
think
anybody
necessarily
as
a
kind
of
really
study
it,
but
anybody
the
general
strategies
about
strategy.
Now
is
the
time
I
see.
We
have
some
kinds
for
people
in
the
room,
so
they
could
complain
about
it
if
they
wished.
G
This
is
intended
to
be
a
compromise
between
like
something
is
we're.
Just
a
quick
access,
I
think
is
poor.
Is
the
sort
of
TCP
non
sac?
The
open
questions
for
me?
I
think
we
talked
a
little
bit
about
time
stamps
in
the
way
click
does
any
in
sweat,
convinced
me
that
it
wasn't
adding
enough
value,
but
because
it's
a
very
short
introduction,
but
that
so
I
didn't
yet.
B
G
So
certainly
I
think
we're
gonna
need
the
implement
this
to
have
some
confidence
that
it's
going
to
work
already,
that
pretty
shortly
so
I'm
not
expecting
to
have
cuz.
That's
not
it,
but
this
is
what's
gonna
be
and
most
people
are
objecting.
So,
okay.
C
P
I
just
warned
against
making
it
blue
complicated,
pls
I
agree
completely
that
adding
timestamps
here
is
not
gonna,
be
a
particular
particularly
used.
I
like
that
quarter,
RTD
or
reordering
I
think
is
adequate
in
general
I,
don't
looked
at
the
structure
itself,
but
I'd
be
happy
to
look
at
it
and
talk
about
how
to
make
it
as
simple
as
possible.
I
appreciate.
G
That
thank
you.
One
thing:
I.
G
P
But
you're
right,
you're
right,
also
observing
that
this
this
use
case
is
far
simpler
than
the
general
case.
That
quick
is
built
for
you're
only
trying
to
do
this
for
the
handshake,
and
you
have
other
information
that
can
be
coalesced
and
other
information
that
you
can
semantically
use,
because
the
handshake
elicits
responses
and
so
on
and
so
forth.
I
do
think
that
this
can
be
fairly
simple
and
doesn't
need
to
be
complicated,
unnecessarily
complicated.
So
one
thought
that
occurs
to
me
is
instead
of
starting
from
quake.
P
G
Okay,
second
tactical
point
is
everybody's
always
been
sad
about
how
big
the
TLS
header
is.
The
details,
header
is
even
bigger,
so
we're
hoping
there's
like
a
non-law,
a
bunch
of
Nats
middleboxes
duty.
Tell
us
enforcement
I,
don't
think
there
are
I,
never
heard
of
one.
So
we
certainly
want
to
rue
the
nos
because
just
Croft
and
we
should
be
able
move
the
content.
Conversion
and
Thomson
contributed
this
sir
proposal
for
a
reduced
header
format.
G
So
his
suggestion
was
that
we
combine
the
upon
the
sequence
number
into
a
two
byte
block
with
a
basically
these
first
three
bits
are
on
des
mots
bits
because
we
have
like
other
stuff
which
depends
on
what
the
content
type
is
what's
up
with
the
first
byte
and
then
the
epoch
and
the
sequence
number
are
the
things
labeled
EE
and
SNS
and
they're
just
taking
mod.
What
the
size
of
the
thing
is,
so
we
I
think
I
don't
have
an
application
for
this,
but
it
seemed
straightforward.
G
It
should
work,
obviously
will
only
be
for
the
encrypted
traffic,
not
for
the
unencrypted
traffic,
and
the
cutter
was
very
clear,
so
ia.
This
is
a
pretty
good.
I
was
a
little
grossed
out
by
the
design
initially,
but
think
it's
a
pretty
good
design
so
I'm
playing
to
merge
that
in
unless
people
think
they're
sad
about
it.
This
basically
reduces
the
overhead
of
AD
etiology
record
to
four
bytes,
plus
the
integrity
check.
I
Yes,
so
so
more
on
this
one,
we
currently
have
I
think
the
range
between
20
and
64
or
something
reserved
for
us
in
this
Demark
thing,
and
we
use
the
space.
Only
the
lower
half
of
the
20s
I
think
yes,
and
this
uses
the
upper
half
of
that
range
from
32
onwards
and
I.
Think
that's
pretty
reasonable
in
terms
of
we
can
use
that
entire
space
and
it
allows
us
to
cleanly
distinguish
between
a
handshake
message
and
alert
and
the
encrypted
messages
that
we
might
send
and
I
don't
see
us
using
too
much
more
content.
G
G
Mean
that
the
I
mean
basically
the
only
way
you
know,
essentially
the
only
point
of
having
something
different
than
this
would
be
if
you
felt
like
for
some
reason,
you
wanted
to
have
much
longer
of
standing,
I
think
encounters
and
Martin
Kim
has
made.
This
is
enough
bits
for
the
sequence
number
yeah.
I
So
I
convinced
myself
I
might
convince
others
I
I'm,
not
sure
that
I've
actually
convinced
in
sweat.
Okay,
well
is
opinion
on
this
Oh
respect
so
I'd
like
a
little
more
time.
We
can
add
an
extra
bite
yeah
it
would
kind
of
suck,
but
because
then
it
then
it
was
genuinely
too
much
yeah
I
can
I
can
afford
the
analysis
that
every.
G
I
G
We
should
consider
right
so
I
thought
about
that
on
the
the
issue
with
that
is
that
it
actually
makes
it
make
some
of
the
things
you
it
makes
is
actually
more
problematic,
because
that
thing
that
separate
record
announcements
every
to
be
a
tearoom.
So
it's
a
trade-off.
One
thing
you
can
imagine
doing
I
think
is
happiness,
tension.
That
said,
like
I,
don't
when
we
first
looked
at
compressing
GCLs
for
the
things
we
said
was
about
having
extension.
That
said,
I,
don't
pack
multiple
things
basically
and.
I
I
I
Would
need
an
internal
length
for
those
content
types
so
in
the
I.
Imagine
that
for
something
like
an
AK
which,
which
is
usually
the
thing
that
you're
packing
with
other
things,
you
would
say
this
is
an
AK
frame
and
it
turns
out
that
the
first
part
of
it
like
this
is
an
act
packet
and
you
have
an
AK
in
there
and
something
else.
Having.
G
G
Can
do
which
I'll
hold
off
on
Virginia?
Okay
last
thing
that
we'll
talk
about
is
these
connection
IDs?
We
don't
know
spent
time
on
this,
so
the
base
situation
is
that
IOT
e
and
anything
doesn't
go
a
lot
of
transmission
and
these
behind
Nath's
have
these
I've
Kadesh
have
problems
with
not
rebinding,
and
things
like
that
and
quick.
Has
this
functionality
we'll
talk
about
interesting
for
details
a
number
of
times,
just
you
see
just
using
the
five
triple
causes
problems.
Unfortunately
connection.
These
are
also
like
a
clear,
perhaps
a
problem,
and
well.
G
Fortunate
speaking,
is
one
of
the
bakers,
so
this
is
a
huge
privacy
problem,
I
think
in
the
browser
contest,
unless
shirts
problem
the
IOT
contest,
where
people
aren't
actually
moving
around
a
lot,
it's
important
to
Sigma,
Xi
mobility
and
that
rebinding
and
go
woody.
This
is
like
a
lot
more
important
for
not
rewinding
through
the
privacy,
so
my
proposal
for
GCLs
actually
to
kind
of
punt,
which
is
to
say
to
use
II,
have
a
hunk
of
a
optional
put
fixed
connection
ID,
namely
the
negotiates
of
connection
ID.
G
Do
something
late
playing
the
better
later,
because
they're
organized
use
an
extension,
negotiate
the
functionality
in
particular,
we
keep
some
new
extension,
the
negotiates
the
federal
function
ality.
If
we
ever
figure
that
out
I
guess
the
limit
cards
the
table,
the
best
know
the
structure
I
have
I'm
aware
of
retention,
IDs
that
I
think
his
skill
skills.
The
best
requires
passing
a
token
back
and
forth
to
every
packet
effectively
and
I.
G
Don't
think
people
it
eight,
never
could
kill
us
I,
don't
think
you
for
quick
either
by
the
way,
so
that
we
had
that
conversation
in
Paris.
So
that's
one,
of
course
to
do
on.
Let
me
just
show
the
slide
of
what
actually
this
actually
would
look
like,
and
then
we
can
debate
it.
I
suppose
so.
There'd
be
a
very
simple
connection.
Idea
exhibition
like
that,
and
it
would
contain
the
connection
ID
that
you
propose.
G
The
other
person
you
send
in
to
you
and
so
structure
would
be
that
the
client
offers
this
functionality
and
sends
the
connection
he
wants
the
server
to
use
the
server
responds
or
not,
with
the
connect
ID.
He
wants
the
client
to
use.
These
can
be
0
length
and
0
length
means
I'm
happy
to
do
this,
but
I'm
not
gonna
I.
G
G
Think
you
I
think
the
way
you
would
use
this
uses
all
encrypted
records
that
weren't
early
data
Waverly
data
I
think
we
can
use
this
because
do
hard
to
figure
out
what
you
should
use
so
I
think
if
we're
going
to
do
something
like
this
is
so
pretty
reasonable
puzzle
I'd
be
happy
to
hear
objections.
This
turmoil,
Australia
G
as
well.
G
S
Wayne,
so
this
connection
idea
is
indeed
a
very
big
problem.
We
currently
have
in
the
IOT
space,
and
we
are
not
talking
like
I,
observed,
also
Hannah's
draft,
and
there
was
like
a
lack
of
entropy
space
in
the
connection
ID
because,
like
a
few
hundred
thousand,
doesn't
necessarily
cut
it.
When
you
talk
about
IOT,
it's
like
millions,
maybe
billions
so
I
hope
the
byte
length
is
kind
of
okay.
For
that
two
observations.
First,
we
need
this
as
soon
as
possible,
I'm,
not
sure
whether
we
can
fit
it
in
1.3
/.
S
G
When
you
say
server-sent
I
mean
I
said:
do
you
think
it
should
I
would
make
it
receiver
set
receiver,
meaning
meaning
the
device
or
the
server?
The
you
indicate
the
client
ID
DB
ii
actually
to
be
sent
to
you
so
the
server.
Would
it
was
that
the
connection
that
the
client
sent
him
and
the
client
wouldn't
send
the
collection
his
server
sent
him,
but
I
think,
is
what
I'm
people
actually
want.
G
S
Point
is
the
client
should
not
be
the
person
to
define
to
select
the
ID
in
the
space
yeah,
so
you
need
when
the
client
talks
to
the
server.
The
identification
is
done
by
an
ID
that
the
server
can
manage,
because
what
you
want
to
avoid
is
collision
in
the
space
and
if,
if
the
server
controls
the
ID,
then
you
avoid
the
collision
right.
G
K
So
response
to
the
visor
I
believe
this
proposal
does
what
you're
looking
for,
since
there
are
two,
the
data
flows
in
two
directions
similar
to
I
can't
be
a
sec
for
the
receiving
side.
You
have
to
pick
something
otherwise
you
may
have
collisions
because
you
talk
by
not
necessarily
true
for
IOT
cases,
but
you
may
talk
to
multiple
different
server,
so
you
want
to
for
the
incoming
traffic,
select
something
that
you
can
actually
be
multiplexed,
so
I
think
it
does.
M
A
territory
clarifying
question
on
how
this
might
get
used
if
we
were
trying
to
use
it
with
the
SCTP
over
DTLS
stuff
RTC
web.
Would
you
anticipate
that
we
would
need
about
the
same
side?
Connection
ID
is
to
get
NAT
rebinding
there
or
given
that
this
is
actually
browser-based
behavior.
Would
you
assume
that
the
browser's
would
be
a
little
a
little
bit
more
concerned
about
the
privacy
properties
that
you
you
you
described
before
and
and
would
not
use
it
in
that
context?
So
I
guess
I,
don't
think.
G
Me
give
it
given
the
put,
so
we
take
a
step
back
with
the
browser's
I.
Actually,
don't
would
anticipate
being
a
just
web
part
to
see
just
because
somebody
went
with
implications,
are
RTP
and
there's
no
mechanism
for
this.
An
RTP
really
know
I
was
thinking
of
data
channel
yeah
I,
understand
I'm,
just
rying
to
think
about
like
whether
or
not
we
have
a
and
just
anything
about
like
whether
oh
yeah,
I
guess
for
true
confession.
G
I
haven't
thought
that
much
about
any
of
the
un--
unaware
I
go
OD
situations
in
whether
he
see
and
emotionally
they
work
at
all.
So
I
mean
these.
These
designs
with
underwear,
not
rebinding,
typically
assume
that
one
side
basically
has
a
completely
open.
You
know
connection
because
otherwise,
otherwise
you
get
rebinding,
they
just
fall
on
the
floor,
and
so
I
just
haven't
thought
about
enough.
Whether
or
not
it's
even
viable
to
have
enough
WebRTC
settings
where
it
survived,
not
rebinding
at
all,
certainly
any
and
any
clients
clients.
M
M
T
G
No
use
for
a
number
that
big
I
just
chose
that
they
basically
my
general
practice
when
do
choosing
TOS
ranges
is
to
max
out
the
range
because,
if
you
do
say
foolish
in
your
foolish,
but
we
could
serve
it
for
some
reason.
There's
no
reason
to
a
question
D
larger
than
X
to
make
the
number
smaller
I
mean
it's
not
consuming
any
space
in
the
wire.
Unless
you
make
the
one
that
day,
I.
T
T
G
G
T
U
Daniel
condo
or
a
CEO
you
so
I
wanted
to
ask
two
questions
related
to
privacy
concerns.
One
is
that
you
seem
to
justify
this
on
the
basis
that
IOT
devices
are
unlikely
to
be
mobile.
Do
we
have
evidence
for
that
I'm?
My
understanding
is
that
IOT
is
also
active
in
vehicles,
so
it's
I'm
surprised
to
hear
that
we
think
that
there
that
IOT
are
not
going
to
be
mobile.
That's
that's
one
thing.
If
somebody
has
a
response
to
that,
I
know
maybe
I'm
as
well.
U
The
second
thing
is
that
this
looks
to
me
like
a
field
for
arbitrary
metadata
insertion
into
each
packet
and
particularly
with
the
long
length.
Basically,
each
peer
can
require
arbitrary
metadata
insertion.
This
looks
like
spud,
but
we're
not
gonna,
call
it
spud
and
and
and
I
would
I
would
rather
not
do
that.
Well,
let
me
make
my
throw
the
violins.
G
Yeah,
so
on
the
reason
it
is
in
metric
is
you're,
just
the
issue
that
nikos
sent
by
us
for
raising,
namely
to
allow
each
side
to
dictate
the
packets
that
they're
going
to
be
receiving
so
any
symmetric
scheme.
Because
if
you
have
unstructured
IDs,
it
doesn't
matter,
but
it
doesn't
mostly
matter.
But
if
a
structure
IDs,
then
typically
people
want
to
pack
the
target
thing
into
the
connection
ID
in
some
way.
I
Yeah,
just
not
in
Tulsa
to
expand
on
that
point.
The
whole
point
of
this
is
to
mark
packets
so
that
the
receiver
can
get
them
to
the
right
place
and
it
has
to
be
asymmetric.
I,
don't
there's
a
mess
in
in
quick
in
that
regard
and
I
think
this
is
a
far
better
design
for
something
along
these
lines.
I
got
up
to
say
that
I
think
this
is
enough
of
a
of
an
attractive
target
that
I
don't
want
to
see
this
in
detail.
I
S13
I
want
to
see
this
as
a
separate
document,
and
that
will
address
the
concerns
of
people
had
about
Patel
s12
because
we
can
hit
both
them.
At
the
same
time,
we
can
have
these
discussions
about
arbitrary
metadata
or
insertion,
because
I
think
that
it
requires
to
meet
and
I
think
we
should
probably
put
in
the
is
how
you
signal
the
ability
to
change
the
thing,
and
that
requires
some
thinking
about
asking
for
Telus
one
too
yeah.
So
maybe
we
just
don't
do
it
the
Telus
one
too,
but
the.
G
I
G
W
Christian
Redeemer
yeah
pretty
much
what
Parton
says
I
mean
we
have
to
do
this
thing
right,
not
fast
and
and
the
quick
and
dirty
stuff
is
not
going
to
cut
back.
You
absolutely
want
to
be
able
to
renegotiate
it
or
to
get
several
of
them.
Otherwise,
if
you
don't
have
the
renegotiation
mechanism,
the
privacy
hole
is
so
huge,
it's
bad
idea,
and,
and
yes,
you
might
try
to
justify
the
quick
and
dirty
same
bye.
Hey
the
use
cases
this
and
that,
but
it
is
not
its
WebRTC.
Is
that
the
pause
alright?
W
And
so
so
you
you
want
to
Africa
negotiation.
You
probably
want
to
make
it
optional,
so
it's
not
present
in
every
packet.
Okay,
that's
actually
course
yeah!
That's
a
word,
nothing
so
much
more
great
that
that
has
had
a
blood
and
and
you
and
you
want
to
have
some
kind
of
constraint
to
make
sure
that
you
don't
get
this
huge
privacy
holster
well,.
G
G
Most
legs
and
quick:
it's
just
a
minute
infection
IDs
in
some
cases,
because
we
couldn't
really
encrypt
yet
I'm,
not
saying
it
has
legs
does,
but
one
that
has
the
most
as
far
as
I
can
tell
so
I
think
the
question
is:
should
we
attempt
to
build
something
that
is
approximately
a
fixed
idea
with
the
way
of
changing
it
or
should
would
be
attempting
to
build
something
one
of
these
unknown
structures
that
has
a
way
of
like
costly
change
in
the
connection,
ID
and
I.
G
Think
the
thing
that
motivated
this
proposal
was
an
attempt
to
get
past
get
past
up
the
technical
problem
that
we
didn't
know
how
to
solve
and
solve
part
of
the
problem,
so
I
think
there's
something
like
Morton
suggested,
which
is
basically,
we
have
a
fixed
direction,
ID
that
we
can
change
and
that
we
know
how
to
do
the
other
things.
We
actually
know
how
to
do
so.
I
think
the
question
is
already
should
be:
building
up
on
down
yeah.
W
G
G
Between
it,
whenever
that's
when
they
get
cool,
sure
well,
I
think
so.
I
think
I
can
certainly
prepare
a
separate
draft
that
implements
this
strategy.
I
think
it
may
or
may
not
have
constant,
may
may
or
may
not
have
changes
GL's
from
point
2,
because
Martin
points
out
that's
much
more
difficult,
but
I
think
we
eat
tails.
More
three
changes
are
very
straightforward.
P
Hey
thanks
for
discussing
this
here,
III
I
think
I'd
actually
agree
with
what
Kristin
just
said,
but
I
have
three
I
trade,
I
or
maybe
I
think
I.
Really,
it's
I
think
it's
useful
to
have
the
ability
to
change
it
connection
ID,
because
in
quick
as
well,
we
we
I,
think
we
are
falling
on
the
side
of
warming
to
at
least
you
in
your
connection.
Idea
on
the
client
knows
that
there's
mobility,
then
there
is
actually
Network
change.
P
We
won't
be
able
to
change
it
if
you
only
keep
changing
it
throughout
the
connection
that
that's
something
that,
as
you
suggest,
it
is
possible
to
do,
but
it's
pushing
it
further
along,
but
that
middle
ground
is
important
and
I.
Don't
think
that
we
should
lose
that
by
having
a
fix
connection
ID
throughout
the
Commission.
J
Then
Schwartz,
so
in
addition
to
the
problem,
privacy
issues
within
a
connection,
it
looks
to
me
like,
if
you're
a
client
and
you're
trying
to
keep
track
of
a
bunch
of
different
servers.
The
logical
implementation
of
your
connection,
ID
in
this
situation,
especially
if
you're
really
concerned
about
length,
is,
is
as
a
counter
basically
and
so
I
think.
The
result
is
that
you
get
yellow.
J
You
may
encourage
clients
to
create
cross
connection,
link,
ability
or
I
can
see
a
bunch
of
connections
coming
out
of
an
atom
because
they're
all
in
some
sequential
range,
I
can
say
well.
This
is
different.
These
different
connections
might
actually
all
be
the
same
client,
so
it
would
be
nice
to
find
a
solution
that
doesn't
encourage
that
as.
K
Guidance
wanted.
This
is
honest.
I
would
like
to
talk
about
the
privacy
aspect
and
the
previously
raised.
We
everything
sort
of
we
wouldn't
have
a
problem
in
the
IOT
case
for
the
use
case
we
care
about.
If
the
Nats
are
lifted,
either
the
Nats
wouldn't
exist
and
wouldn't
do
an
repining
or
if
the
devices
which
just
continuously
or
more
frequently
centered
traffic
and
unfortunately
they
do
so
in
terms
of
privacy.
Therefore,
those
devices
there's
the
connection
ID
is
nothing
else
than
the
source
port.
It's
the
same.
K
K
So,
for
example,
if
you,
if
you
lose
your
IP
address,
because
you
get
it
reassigned
or
because
you
attached
a
new
access
network,
then
you'd
have
to
go
through
this
step
anyway.
The
connection
ID
will
not
make
a
big
difference.
You
just
use
the
full
exchange,
the
full
DTLS
exchange
and
because
it's
it's
more
optimized
will
actually
be
fast
anyway,
compared
to
what
we
had
in
DDS.
K
That's
why
we
don't
habit.
That's
why
we
have
a
simple
approach
and
if
you
want
to,
if
you,
if
you,
for
example,
switch
the
connection,
you
can
actually
do
a
resumption
PSK
exchange,
which
would
be
very
efficient
so
because
that's
what
indeed
Els
1.3
that's
what
an
alternative
design
has
to
compare
against
in
detail.
S12,
it's
really
little
bit
different
because
you
have
more
round
trips,
you
have
the
latency
and
so
on.
It's
on.
S
To
be
a
scholar,
more
away
so
for
these
connections,
so
first
yes,
mobile
devices
are
at
least
in
the
use
cases
that
I
see.
Having
said
that,
when
you,
when
you
consider
the
renegotiation,
consider
that
the
main
use
case,
that
at
least
I
see
currently
is
devices
with
power
constraints,
so
that
means
every
round
trip.
Every
kind
of
CPU
processing
time
is
really
really
costly,
so
smaller
bits
that
are
just
long
enough
to
qualify.
It's
good,
not
renegotiating
every
time.
S
Obviously,
what
is
like
this
you
side,
kind
of
in
that
scenario,
so
things
that
are
like
which
you
can
tailor,
which
you
can
customize.
Let's
say
you
can
choose
when
you
want
to
really
go
she
ate
or
not.
Now,
don't
don't
push
it
on
it
and
one
last
thing
so
I
I
rather
have
to
really
soonish,
because
the
problem
is
out
there.
It's
not
like.
We
are
sitting
on
something
in
our
ivory
tower
and
yeah.
If,
if
you
want
to
think
longer
about
this
41.3,
then
I
would
strongly
urge
the
chairs
to
consider
1.2.
S
P
What
Hana
said
I
agreed
are
generally
sending
something
in
every
packet
series,
quite
a
bit
of
information
and
quite
a
bit
of
work
to
do
in
complexity,
but
it's
doing
it
on
a
mobility
is
not
that
whole
Nerissa
bird.
It's
only
a
set
of
connection
IDs
that
you
would
have
to
send,
and
it's
no
I,
don't
think
it's
true
that
the
mobility
case
isn't
isn't
expected
to
be
the
normal
case.
We
don't
you
know
this
is
getting
into
predicting
the
future,
and
how
exactly
did
he
listen?
P
Frankly,
he
will
get
used
and
I
would
shy
away
from
that
in
that
there
are
likely
to
be
situations
where
that
you
do
have
mobility,
especially
going
between
Wi-Fi
answered
with
networks,
and
those
are
conditions
that
you
want
to
prepare
for.
So
if
it's
not
too
onerous,
and
if
it
can
protect
us
from
something
that
might
happen
in
the
future,
it
seems
completely
worth
it.
P
G
Usually
because,
just
because
the
way
the
Telus
framing
works,
that
any
fueled
that
when
you
have
a
when
you
have
a
variable
a
field,
then
you
have
to
put
a
ceiling
on
on
the
value
to
tell
you
how
long
the
length
base
has
to
be,
and
so
the
first
ceiling
up
is
255.
We
could
make
this
number
as
small
as
you
want
it.
This
is
a
variable
X
structure
of
thought,
fix,
nitrogen
understood.
P
G
I
G
So
so
what
I'm
so
I
in
terms
of
actually
aims?
What
I'm
hearing
is
that
I
should
go
back
in
collaboration
with
Hannes
and
Fran.
Some
other
people
try
to
produce
a
draft,
which
is
a
soft
contained
draft,
has
an
extension
for
the
has
an
extension
for
this
and
also
has
some
mechanism
for
rekey
for
reconnection
idea
and
bring
that
back,
and
then
we
can
discuss
it.
I
think
that's
last
line
these
are
so
these
I
guess
slightly
I
liked
before
I
guess
these
are.
G
These
are
the
only
actually
remaining
open
issues
I
know
about
for
DTLS?
Obviously,
if
there's
all
this
header
issue-
and
we
just
take
in
the
connectivity
issue
off
the
table-
so
you
know
I
would
very
much
like
to
come
over
there
grizzle
in
the
next
month
or
two
and
this
end
of
the
list
and
then
be
done,
and
so
other
people
have
things
I
know.
I
know
people
expressed
in
private
or
after
the
hacker
news
that
works
out
about
things
that
you
tell
us.
G
I
really
do
care
about
those
things
now,
if
we're
gonna
make
changes,
so
I
don't
hear
about
them
in
six
months.
So
there
are
things
that
make
you
sad
about
DTLS,
please
do
tell
me
so
I
can
fix
them.
So
to
echo.
E
That
point
for
all
the
people,
that's
sending
me
email
about
when
Wendy
hosts
give
a
trough
prepared
to
TLS
version
now's
your
chance,
if
you
think,
there's
something
that's
missing,
get
to
the
microphone,
send
email.
Do
it
because
there's
not
a
lot
of
issues
left
that
I
think
we're
actually
talking
about.
E
So
just
so
we're
gonna
do
a
little
interrupt
here
from
the
chairs
prerogative
perspective.
So
Steve
thanks
for
you.
The
first
thing.
If
the
next
set
is
that
the
rules,
the
road
we've
talked
with
everybody's,
presenting
pretty
much
we've
told
people
to
keep
it
short
kind
of
point,
not
to
kind
of
repeat
themselves.
We
have
lots
of
time
for
discussion
for
at
this
patear
topic.
E
So
let's
hold
the
particular
points
about
this
that
the
other
till
after
steven
is
done,
presenting
so
Steve's
gonna
present
and
then
Stevens
can
present
we'd
like
you
to
hold
that
we
want
to
kind
of
address
both
political
topics
and
technical
topics
in
this
discussion.
So
we
know
this
might
not
be
a
clean
split
and
we
would
like
you
to
think
that
about
that.
We
want
you
to
help
us
get
to
a
point
where
we
can
actually
do
the
chair
questions.
What's
the
next
library,
which
is
the
main
question
is,
is
some
something?
E
Is
this
the
subject,
something
that
the
worker
should
consider?
You
know
I'm?
This
being
you
know
passive
accretion
of
data
sent
of
traffic
and
why
you
might
do
that?
Is
it
some
question
I
think
is
it
like?
Is
this
wiretapping
or
not?
I
know
that
I've
talked
to
the
people
that
work
about
to
present.
They
have
a
file
on
that
and
let
them
do
that.
Let
them
have
their
slide
and
then,
after
that,
we'll
have
some
technical
discussion
about.
You
know
what
technical
solution,
sorry,
what
technical
solutions
are
available,
etc,
etc,
etc?
E
So,
and
the
point
is
that,
if
we
did
ever
get
to
the
point,
we're
gonna
adopt
something.
Everyone
has
to
understand
that
the
working
group
has
change
control
the
document.
So
what
you
can
do?
What
would
you
proposing
now
Steve,
you
know
and
there's
other
people
we
can
like
take
it
drop
it
rip
it
out
start
over.
Kick
that
the
authors
off
put
new
people
on.
If
you
wanted
to
you
the
whole
nine
yards
so
like
that
the
working
group
actually
has
change
control.
E
One
of
the
things
we
want
to
do
is
also
if
anyone
that's
presenting
on
this
particular
topic
would
like
mimosa
we're
willing
to
provide
one
so
from
there.
Steve
thanks
yeah.
So
we
have
a
kind
of
Steve,
has
there's
a
bunch
of
like
kind
of
flow
for
this,
so
we're
gonna
go
to
Steve,
Matt,
Tim,
Russ
and
then
Stephens
gonna
get
up
and
do
stuff,
and
we
have
like
multiple
there's
like
five
people
presenting
on
this
entire
topic
so
and
again,
like
we're.
Gonna
have
like
an
hour
after
Steven.
E
K
X
Hi
I'm
Steph
enter
I
want
to
try
to
talk
about
why
static
female
Minh
is
important
for
enterprises
and
for
TLS,
not
just
for
enterprises.
I
also
want
to
try
to
respond
to
some
of
the
comments
and
questions
on
the
list
in
terms
of
other
solutions
that
people
have
proposed
and
why
I
think
they
don't
work
and
why
we
need
something
like
stacked
if
you
helmet
in
order
to
get
our
work
done.
These
are
some
of
the
major
use
cases
for
out
of
an
encryption
and
data
centers.
Today.
X
A
lot
of
them
are
security,
related
I
think
there
are
good
reasons
for
them,
but
I'm,
not
a
security
guy,
so
I'm
not
going
to
wade
into
the
security
discussions.
I'm
a
troubleshooter
and
a
network
guy,
so
I'm
going
to
focus
on
the
first
one.
The
impact
of
TLS
1
3
on
troubleshooting,
particularly
Wireshark,
pcap
type
troubleshooting.
X
So
this
is
the
application
I
introduced
in
Seoul.
For
those
that
heard
my
presentation
there,
it's
an
eye
chart
on
purpose
to
show
the
complexity
of
an
internet
facing
application,
and
just
basically
you
know
you
come
in
the
Internet
on
the
upper
left.
You
hit
the
main
processing
path
in
the
middle
of
web
server,
app
server,
middleware
mainframes
at
the
bottom,
there's
load,
balancers
interspersed
and
when
a
problem
hits
oftentimes.
Nobody
knows
we're
in
this
group
of
400
boxes.
X
The
problem
is,
and
so
my
purpose
in
life
is
figuring
out
which
box
is
causing
the
problem.
It
can
be
an
application
problem,
it
can
be
an
infrastructure
problem
and
the
symptom
is
the
same.
The
application
slows
down
or
it
fails
so
I
need
packet
level
visibility
everywhere
in
this
diagram
in
order
to
be
able
to
troubleshoot
problems,
and
that's
more
than
you
can
do
with
proxies.
That's
one
of
the
points
I
want
to
make
so
I
got
called
a
month
or
two
ago
on
this
particular
application
to
troubleshoot
a
severity
one
problem.
X
X
K
X
Is
another
point
I'm
gonna
make?
There
are
no
log
messages
anywhere
that
gave
people
the
root
cause
the
problem.
This
had
happened
multiple
times
and
everybody
was
stuck
so
the
sniffer
guys
are
called
to
swoop
in
and
save
the
day
and
and
by
the
way
I'm.
Not
the
only
person
that
does
this
I
know,
counterparts
and
other
large
enterprises,
other
verticals
and
they're
all
doing
the
same
thing,
they're
all
getting
called
on
severity.
One
problems,
they're
all
decrypting
packets
to
figure
out.
X
What's
going
on
so
I
started
looking
at
packets
on
the
Internet
and
because
we
use
a
content
delivery
network,
the
source
IP
of
the
user,
I'm
looking
for
is
obfuscated,
so
I
have
no
way
to
find
that
user,
except
to
trace
everything
in
and
out
of
this
application,
three
to
four
million
packets
decrypt.
All
of
it
and
look
for
some
identifiers,
like
the
guy's
user,
ID
or
Origin
IP
address
so
I
was
able
to
find
this
particular
a
particular
users
transaction,
his
login.
X
That
was
failing,
and
there
was
one
particular
URL,
one
particular
get
that
was
getting
10-second
response
time.
So
I
knew
it
wasn't
an
internet
problem.
It
was
something
deeper
into
our
data
center,
so
I
moved
my
tracing
down
to
the
tier
2
load,
balancer
found
the
same
symptom,
same
URL,
10.
Second
response
time:
I
moved
down
to
the
reverse
proxy
above
and
below
the
same
symptom.
X
I
move
down
to
the
web
server
found
the
same
symptom
above
the
web
server
same
symptom,
so
I've
looked
at
five
tiers
of
the
application
already,
and
this
is
already
more
than
you
can
do
with
proxies.
So
for
the
for
the
proxy
question,
five
layers
of
proxy
is
huge.
It's
expensive,
it's
millions
of
dollars.
The
bigger
thing
is
that
it
adds
production
risk.
These
are
divided.
X
These
proxies
are
devices
that
can
fail
and
when
they
fail
now
they're
causing
a
production
outers
themselves,
they
complicate
troubleshooting
and
no
enterprise
wants
to
put
in
a
hundred
proxies
for
me
to
get
the
visibility
I
need
it.
It's
a
solution
that
doesn't
scale
doesn't
work
for
enterprises,
the
other
another
major
solution,
that's
been
suggested
is
endpoint.
Monitoring
I've
already
mentioned
that
logs
often
don't
have
a
clue
as
to
what
the
problem
is
and
running.
X
Full-Scale
packet
captures
on
endpoints
doesn't
work
because
of
NAT
and
because
of
encryption
we
often
have
no
way
to
tell
which
connection
is
the
right
one
until
we
decrypt
the
data
and
look
for
session
IDs
or
other
identifiers.
So
we
would
be
forced
to
run
full-scale
packet
captures
of
everything
on
app
servers
on
firewalls
on
load
balancers
and
those
boxes
are
not
made
for
it
and
I
have
many
anecdotal
stories
not
from
me
of
people
killing
boxes
trying
to
run
traces
on
them.
X
So
that's
also
not
a
scalable
solution
and
one
other
note
before
I
move
on
on
the
endpoint
monitoring
is
I
often
need
decrypted
packet
capture
where
there
is
no
endpoint
firewalls,
don't
always
terminate
TLS
load,
balancers,
don't
always
terminate,
but
yet
I
often
need
to
put
a
sniffer,
above
and
below
a
firewall
or
above
a
below
load,
balancer
decrypt,
the
traffic
to
find
a
transaction
and
then
identify
if
that
firewall
is
causing
my
slowdown.
And
if
my
only
trace
option
is
the
end
point,
there's
no
TLS
termination
I
have
no
way
to
get
it.
X
X
It
doesn't
solve
the
problems
so
anyways
I
am
I,
move
my
trace
point
below
the
webserver,
and
now
the
webserver
made
a
different
call
so
again
completely
different
TLS
connection
completely
different
URL
I
have
no
way
to
find
this
in
a
trace
that's
encrypted,
except
to
decrypt
it
and
look
for
identifiers
like
session
IDs,
so
that
there's
a
new
URL
and
then
down
in
the
application
payload
of
the
packet.
There
are
individual
application.
Layer
function
calls
get
LDAP
ID
and
that
got
a
fast
response.
X
There's
two
or
three
others
that
also
got
a
fast
response
and
then
the
fourth
call
at
the
application
layer,
ten-second
response
time
so
now,
I
know
exactly
where
this
this
particular
call
to
get
it
token
getting
ten-second
response
time.
So
the
problem
happened
again.
We're
all
in
the
bridge
call
and
I
said.
Look
when
this
problem
happens.
X
There's
this
one
call
and
that's
where
the
problem
is,
and
the
database
guy
said:
oh,
that
that
call
accesses
a
unique
database
table
and
a
unique
stored
procedure,
and
it
wasn't
15
seconds
later
that
the
other
database
guy
said
I
see
the
problem.
This
particular
stored
procedure
had
an
expensive
operation.
X
It
was
single
threaded
and
users
were
backing
up,
and
that
was
backing
up
the
database,
which
was
backing
up
the
app
servers
which
is
backing
up
LDAP,
which
was
backing
up
other
applications,
and
there
was
this
cascading
mess
happening
from
this
one
function
call
and
it
was
the
decrypted
payload
of
the
packet.
That
was
the
solution,
and
there
was
a
question
on
the
list.
Also,
that
said,
show
me
an
example
where
you
have
to
have
decrypted
packets
and
there's
no
other.
P
X
This
is
that
example.
There
was
no
other
way
except
to
look
at
the
pail
of
the
packet
to
figure
out.
What's
going
on
now,
there
is
another
alternative
which
I've
seen
from
other
environments,
where
we
don't
have
packet,
visibility
and
I'll
pick
on
VDI
for
the
moment,
because
VDI
obfuscates,
the
payload
of
the
packet
into
mouse,
clicks
and
keystrokes,
and
when
you
try
to
look
at
it
and
it's
encrypted
in
ways
you
can't
decrypt
and
in
a
sniffer
trace,
you
can't
see
anything
and
you
can't
find
a
transaction.
X
So
when
you
have
a
long
VDI
string
like
from
the
other
side
of
the
world
to
our
data
center
50
pieces
of
infrastructure,
firewalls
load,
balancers
and
multiple
data,
centers
and
circuits,
and
then
you
get
to
our
data
center
more
firewalls,
any
one
of
those
pieces
of
infrastructure
could
be
causing
your
slow
down
and
the
Troubleshooters
have
no
way.
If
there's
no
log
messages,
we
have
no
way
to
figure
out
which
piece
of
infrastructure
is
causing.
X
This
problem
and
I've
worked
on
problems
like
this
and
when
the
sniffer
guys
can't
get
in
there
and
say
it's
this
firewall,
then
everybody
is
reduced
to
guesswork.
Let's
try,
upgrading
the
software,
let's
try
downgrading
the
software,
let's
try
a
different
network
path
and
what
I've
seen
from
experience
is
severity
ones
dragged
out
than
a
week,
which
is
an
eternity
for
severity.
One
problem
severity,
two
problems
drag-out
four
months
and
we
only
survived
EDI
because
it's
not
everywhere-
and
this
kind
of
thing
only
happens
once
in
a
while,
but
TLS
is
different.
X
You
know
internal
infrastructure,
it's
all
TLS
encrypted
we're
troubleshooting
these
environments.
Every
day
we
have
a
team
of
six
people
looking
at
packets,
looking
at
payloads
like
I,
do
and
every
single
day
or
just
about
every
single
day,
we're
looking
at
payloads
of
packets,
to
figure
out
problems
and
what's
gonna
happen
if
TLS
1.3
rolls
out,
just
as
it
is
without
static
did
be
Helmand.
Is
that
we're
going
to
have
severity?
X
One
problems
that
drag-out
for
more
than
a
week
and
we're
going
to
have
severe
and
it's
going
to
be
far
more
frequent
than
what
we're
seeing
today
we're
going
to
have
severity.
Two
problems
drag-out
for
months
and
and
even
this
particular
problem,
I
described
I,
was
able
to
get
to
the
root
cause
in
three
or
four
days,
but
with
TLS
one
three.
If
I
lose
my
decryption
capability,
it's
going
to
be
three
or
four
months,
and
it's
going
to
be
a
level
of
pain
that
enterprises
aren't
going
to
be
willing
or
able
to
handle
it.
X
X
So
we
need
a
solution,
for
we
need
a
solution
for
TLS
1.3
in
the
datacenter,
and
if
we
don't
get
a
solution,
the
outcome
is
going
to
be
length
of
troubleshooting
time
that
we
can't
deal
with
all
the
all
the
focus
on
creating
a
secure,
Channel
and
keeping
the
bad
guys
out
of
it
is
also
locking
out
the
Troubleshooters
and
the
threat
detection
teams
from
doing
the
work
that
they
need
to
do
so.
We
need
a
solution
that
solves
his
problem
and
static.
X
Y
So
I
want
to
talk
briefly
about
this
draft,
so
the
motor
sorry,
my
name
is
matthew,
green,
I'm
one
of
the
authors
of
this
track.
Okay,
there
we
go
okay,
so
so
I
was
approached
with
this
problem
and
the
problem
was
basically:
how
do
we
get
enterprises
who
control
an
endpoint
to
be
able
to
access
traffic
on
this
endpoint,
and
the
interesting
thing
about
this
problem
is.
This
is
not
technically
a
problem
if
you
control
an
endpoint
in
the
tls
system,
you
control
access
to
secrets.
Y
There
are
a
handful
of
possible
solutions
to
this
problem,
many
of
which
already
exist.
The
first
solution
is
basically
to
have
end
points,
meaning
servers,
deliver
session
keys
or
deliver
master
secrets
that
they've
derived
through
some
kind
of
out-of-band
channel
on
this
is
actually
pretty
workable.
In
fact,
browsers
can
already
do
this.
Servers
can
certainly
do
it
without
too
many
changes.
The
problem
is,
the
number
of
keys
here
can
be
very
large.
So
in
order
to
do
this
and
remember
the
the
requirement
is
real-time
decryption
by
some
kind
of
middle
box.
Y
You
have
to
handle
two
problems.
First,
you
have
to
deliver
keys
in
a
very
timely
manner,
because
these
devices
that
are
actually
doing
monitoring
can't
cash
very
much
traffic.
So
if
you
get
D
synchronized,
if
you
can't
get
keys
to
the
right
place
in
the
right
time,
you
can
lose
large
amounts
of
traffic,
so
this
may
not
work
at
scale.
Y
The
second
solution
is
to
do
something
that
actually
encodes
secrets
or
session
keys
in
banned
in
the
TLS
protocol.
There
are
a
handful
of
different
versions
of
that.
One
which
I
actually
like
a
lot
and
might
be
a
workable
solution,
is
to
use
a
full
extension
where
the
client
says
I
want
to
participate
in
this
protocol
and
the
server
agrees,
and
then
you
do
an
invent
inclusion
and
that
may
be
fine.
Y
Unfortunately,
some
clients
which
are
already
present
in
the
data
center
are
legacy
systems,
and
they
don't
include
the
logic
to
do
that,
so
it
may
not
work
in
every
case,
but
I
do
like
it
as
an
alternative
approach.
What
I
don't
like
about
this
solution
is
that
there
are
a
lot
of
different
variants
of
this
idea,
some
of
which
are
very
hard
to
detect
I
included
a
kind
of
a
joking
suggestion
which
was
by
homage
chakram.
Let's
use
dual
EC
drbg,
which
is
you
know,
hilarious
right.
This
is
a
perfect
way
to
do
this.
Y
We
hack
our
random
number
generator
so
that
our
secrets
are
generated
using
something
that's
predictable.
We
include
something
into
the
protocol
where
everybody
can
monitor
this,
and
we
can
laugh
about
this.
But
the
truth
is
this
is
a
perfectly
workable
solution,
or
some
variant
of
this
is
a
workable
solution.
It's
very
easy
for
somebody
to
do
without
actually
harming
the
TLS
protocol,
and
if
this
group
says
that
that's
the
way
things
should
go,
I
really
suspect
that
that
somebody
is
going
to
implement
something
like
this
I.
Y
Don't
like
that,
because
it's
completely
undetectable,
if
you
do
it
this
way,
and
it's
kind
of
ugly
and
unpleasant
a
third
approach
which
actually
is
detectable
is:
let's
not
change
the
TLS
protocol.
Let's
do
something
other
people
can
recognize
let's,
and
this
is
actually
following
up
on
a
suggestion
by
Hugo
crossing.
Let's
just
have
in
the
particular
case
where
you
control
an
endpoint,
and
you
need
to
monitor
connections
to
that
endpoint.
Let's
just
have
it
use
a
static,
diffie-hellman
key
and
by
static
here
I
mean
it
doesn't
have
to
be
static
for
all
time.
Y
We
want
the
keys
to
change
it's
just
that
they'll
change
according
to
some,
maybe
you
know
not
per
connection
logic.
Maybe
they'll
be
they'll,
be
new
keys
pushed
periodically
once
a
day
once
an
hour
or
something
like
that.
The
nice
thing
about
this
is
it's
very
hard
to
deploy
this
at
scale.
As
a
kind
of
you
know,
nationwide
wiretapping
system,
you
can
tell
when
servers
exhibit
this
behavior
and
you
can.
You
can
take
a
call
it's
to
prevent
browsers
to
connect
to
them.
Y
It
does
reduce
forward
secrecy
depending
on
how
quickly
you
rotate
keys,
and
it
has
some
other
issues
that
may
come
up
as
well,
can
I
get
so.
This
is
what
was
proposed
in
the
draft
green
TLS
static
draft,
it's
version
one
now
and
basically
it
does
not
suggest
a
change
to
the
TLS
protocol.
It
says
do
two
things.
The
first
is
here
is
a
way
to
use
the
TLS
protocol.
That
is
consistent
with
the
current
TLS
1.3
draft,
without
changes
to
the
protocol
using
a
static
key.
So
this
is
really
just
a
configuration.
Y
The
second
thing
it
says,
is
you're
a
bunch
of
security
considerations.
If
you
do
this,
let's
be
careful
about
these
and
the
third
thing
it
does.
It
says:
okay,
let's
say
you
want
to
do
this
here
is
how
you
should
manage
those
static
keys
using
a
key
server.
Here's
the
protocol.
You
should
use
to
actually
push
them.
You
don't
have
to
do
that,
but
that's
the
majority
of
what's
actually
in
this
draft.
It
also
emphasizes
that
the
point
of
this
draft
is
for
servers.
Y
You
have
a
load
balancer,
that's
terminating,
a
connection
from
the
internet,
that's
a
normal
ephemeral,
EC,
Phe
connection,
and
then
you
have
a
bunch
of
craziness
going
on
in
the
backend
and
there
we
have
static
diffie-hellman
on
internal
servers
and
those
are
the
only
connections
that
can
be
monitored.
Of
course,
you
know
the
load
balancer
can
monitor
the
ephemeral
connections
too.
But
that's
you
know,
that's
something
that
can
always
happen.
Y
Okay,
I
just
want
to
talk
briefly
about
the
security
of
this
approach.
I,
don't
think
it's
very
controversial
that
static
diffie-hellman.
If
you
leave
aside
the
forward
security
forward,
secrecy
considerations
is
cryptographically
secure.
We
know
that
this
is
something
that
can
be
done.
Fips
856
a
talks
about
using
ephemeral
static
as
a
key
exchange.
Tls
1.2
already
has
a
static
mode.
We
know
the
implication
of
this.
Y
Y
There
are
some
risks
or
server
implementations
when
you
use
a
static
key
one
of
those
is,
for
example,
small
subgroup,
attacks
or
lift
a
curve
validation
problems,
one
of
the
things
that
we
did
as
part
of
this,
as
we
submitted
a
pull
request
to
the
TLS
1.3
standard,
which
was
accepted
actually
specifying
elliptic
curve
validation,
and
so
regardless
of
how
this
goes
at
least,
you
know
there's
one
kind
of
good,
concrete
output
from
this
project.
Okay,
so
so
we
know
that
this
is
something
you
can
do
last
couple
of
things.
Y
Yes,
so
the
majority
of
these
problems-
and
some
people
have
raised
this
on
the
list
is
yes,
implementations
can
trip
and
fall
and
they
can
fail
to
implement
these.
These
checks,
even
though
they're
required-
and
you
know
what
happens
if
that
happens.
Well.
People
who
implement
this
inside
of
their
data
center
deliberately
and
fail
to
test
for
these
implementations
laws
will
have
a
big
problem,
but
if
you
don't
implement
static,
diffie-hellman,
that's
really
not
going
to
affect
you
or
the
rest
of
the
internet
and
the
finite
field.
Diffie-Hellman
groups
also
help
address
these
things.
Y
Oh
yes,
sorry.
My
last
point
here
is
that
I've
kind
of
approached
this
as
a
question
I
said
this
before
kind
of
harm
reduction.
So
we
know
that
there's
a
solution
space,
certainly
one
part
of
that
solution.
Space
is
enterprises,
just
don't
adopt
TLS
1.3
today,
they're
using
1.2
with
static,
RSA
and
I.
Think
in
general,
that's
a
bad
thing,
but
they
may
continue
to
do
that.
I,
don't
know!
Maybe
that's
the
right
thing
to
do,
but
it
doesn't
sound
great
to
me.
Y
They
could
make
these
dramatic
kind
of
surgical
changes
to
endpoints
to
deliver
session
keys.
Doesn't
sound
terrifically
good
to
me,
there
is
a
whole
constellation
of
what
I
call
really
bad
ideas
which
I
won't
go
into,
but
I'm
sure
that
you
know
if
this
leaves
the
IETF
and
go
at
Z
or
ANSI
or
wherever
a
lot
of
that
ideas
will
be
considered.
I
prefer
ideas
that
are
detectable
to
those
bad
ideas,
and
then
there
are
extensions
which
actually
I'm
open
to
I.
Think
extensions
might
be
a
good
solution.
What
we
get
from
static.
Y
If
you
Hellman,
is
three
things
you
don't
have
to
change
the
TLS
protocol,
so
nobody
else
gets
broken.
We
understand
the
cryptography
here.
We
know
what
the
trade-offs
and
the
drawback,
but
we
know
how
to
control
for
them
and,
more
importantly,
we
can
detect
it.
If
somebody
puts
this
on
the
internet,
we
will
be
able
to
have
SSL
labs
to
give
them
an
F
very
easily,
and
we
may
have
browsers
that
can
actually
detect
and
even
block
connections
to
those
servers.
If
that's
something
we
want
to
do
so,
that's
pretty
much
it
from
you.
Z
Good
morning,
I'm
Tim
Polk
from
this
I
am
not
one
of
the
authors
of
the
draft,
but
I
am
actually
one
of
the
I
guess
we
say
sponsors
of
a
related
project
at
this
national
cybersecurity.
Center
of
Excellence
I
wanted
to
give
one
quick
plug
on
what
the
NCC-
oh.
He
is
since
it's
only
a
couple
of
years
old,
unlike
you
know,
NIST,
where
we
do
metrics
and
standards.
The
NCC
OE
mission
is
really
all
about
tech
transfer
about
adoption
about
deployment.
It
is
actually
we
don't
develop
new
standards
at
the
NCC
OE.
Z
We
try
to
take
the
standards
and
the
technologies
that
are
currently
available
and
demonstrate
how
we
can
really
provide
security
while
meeting
business
needs
while
meeting
operational
requirements.
So
from
that
respect,
so
you
know,
we've
been
hearing
that
there
was
an
issue
with
with
meeting
operational
requirements
with
TLS
1.3.
We
thought
that
was
actually
an
important
problem,
but
we
wanted
it
sounded
like
an
important
problem.
Z
Back
in
May,
we
convened
a
group
of
industry
folks
to
talk
about
a
couple
of
not
just
this
problem
with
a
couple
of
other
certificate
management
and
other
related
problems
that
have
to
do
with
a
really
wide
scale
use
of
TLS,
and
this
included
people
from
financial
sector
manufacturing
health
care
government
also
included
a
couple
of
our
partner
technology
companies.
We
had
this
roundtable
and
in
the
discussions
it
became
clear
that
even
the
people
who
had
come
to
this
session
to
talk
about
other
problems
when
they
heard
about
this,
they
said
oh
yeah.
Z
Z
We
looked
at
the
current
practices,
and
you
know,
staying
on
one
point.
Two
with
static
RSA
again
doesn't
seem
to
me
to
be
the
best
solution.
It
is
one
that
meets
the
operational
requirements,
but
when
we
looked
at
this,
we
came
to
the
conclusion
that
we
could
do
better
with
TLS
1.3
that
if
we
introduced
a
central
key
manager,
it
did
some
automation,
use
draft
green
and
this
key
management
guidelines
to
make
sure
that
we
are
being
as
secure
as
we
can
there
some
other
existing
standards.
We
think
that
we
could
do
better.
Z
Z
So
what's
next,
the
NCC
has
a
rather
rigorous
process
and
I'd
love
to
tell
you
all
about
it,
but
I
didn't
have
time
in
this
particular
I.
Don't
want
to
divert
the
attention,
but
we're
going
to
be
posting.
What's
called
a
proposed
project
description
it'll
go
into
the
Federal.
Register
it'll
also
go
on
our
website,
and
you
say
this
is
what
we
think
we
ought
to
be
doing
and
we're
looking
for
partners
who
want
to
work
with
us.
Z
That
will
happen
in
the
middle
of
August
over
the
next
month,
or
so
after
that,
maybe
two
months
we
will
collect
all
of
part
of
our
partners
and
we
will
do
some
negotiation
and
discussion
about.
Is
that
really
the
solution?
We
want
to
work
on,
or
there
may
be
tweaks
to
the
architecture
or
the
protocols
that
we
choose?
We
could
augment
the
scenarios
if
we
need
to
address
other
problems.
Z
Then
the
deliverables
that
we
would
be
doing
is
we
would
produce
a
proof-of-concept
implementation
and
then
a
number
of
documents
so
we'll
put
together
a
proof-of-concept
that
has
all
of
those
pieces
uses
the
protocols
and
what
we
would
be
trying
to
really
demonstrate
is
that
we
can
really
improve
the.
We
can
really
tighten
up
the
lifespan
of
those
keys
that
we
are
are
sharing
within
within
the
enterprise.
We
would
publish
a
missed,
1800
series
practice
guide,
maybe
familiar
with
some
of
our
800
series
documents,
which
are
security
documents
that
NIST
puts
out.
Z
The
1800
series
is
actually
these
practice
guides
that
tell
people
how,
if
you
want
to
do
what
we
did
in
the
proof-of-concept,
here's
all
the
steps
that
we
went
through
some
of
these
are
like
four
or
five
hundred
pages
long
I
mean
they're
really
completely.
You
know.
Every
every
breath
we
take
is
pretty
much
documented
in
there,
but
there's
three
parts.
So
there's
an
executive
summary.
There's
how
you
explain
this
to
your
your
decision
makers
and
then
there
is
the
the
every
every
step
you
take.
Z
The
third
thing
that
we
would
do,
which
is
not
actually
something
that
we
do
in
all
of
all
NCUA
projects,
but
something
we
would
do
in
this
one
is
that
we
would
submit
an
IETF
draft
that
says
this
is
what
we
did.
They
worked.
It
didn't
work.
This
is
how
these
were
the
problems
we
found.
This
is
how
the
kind
of
velocities
that
we
thought
we
could
cut
a
key
life
that
we
thought
we
could
manage,
and
that
would
be
documented,
since
we
think
that
would
be
useful
to
people
who
are
using
the
TLS
protocol.
AA
That's
why
we
thought
we'd
end
with
it.
Basically,
the
idea
is
that,
within
the
enterprise,
the
server
in
conjunction
with
the
key
manager
is
established.
The
server
is
working
with
the
key
manager
to
get
the
keying
material
to
all
of
the
places
where
the
decription
needs
to
happen.
When
that
visibility
is
required
and
our
seat
2804
describes
exactly
what
wiretapping
is
and
then
goes
on
to
say
that
the
ITF
will
not
work
on
that.
AA
But
basically,
what
it
says
is
it's
wiretapping
when
either
the
client
or
the
server
know
that
it's
going
on,
and
in
this
case
the
server
is
heavily
involved
working
with
the
key
manager
accepting
that
key
and
then
actually
proactively
using
it.
So
the
server
is
enabling
it
so.
For
that
reason
we
think
it's
not
in
violation
of
2804.
AA
C
AB
Okay,
quite
a
lot
so
I'll
just
skip
through
it
pretty
quickly,
I
like
to
you
like
to
extend
the
discussion
to
bits
and
we
keep
seeing
these
proposals
for
breaking
TLS,
and
this
is
yet
another
one.
So
the
question
I
have
what
the
working
group
is
aside
from
sending
this
to
dev
note:
should
we
or
is
it
worth
while
I'm,
trying
to
document
some
of
the
reasons
why
these
things
are
filed,
idea
bad
idea
in
the
ITF
and
would
that
help
us
to
kind
of
avoid
them
in
future?
AB
It
better
so
again,
I
have
this
repository.
There's
a
bunch
of
arguments
against
this
kind
of
madness
and
bear
in
mind
you
don't
need
to
accept
every
single
arguments.
I
need
one
killer.
Are
you
and
should
be
good?
So,
firstly,
generally
people
do
this
and
they
come
along
and
they
say
here's
my
thing:
I
care
about
it's
a
datacenter,
it's
an
enterprise
and
I.
Don't
care
about
all
the
rest
and
turns
out
TLS
is
so
widely
used.
That's
just
a
dumb
idea.
AB
Secondly,
we
also
should
the
ITF
has
been
census
on
this
considered
the
kind
of
pervasive
monitoring
aspects
of
this,
so
it
just
doesn't
kind
of
watch
to
say
everything
will
be
okay,
it's
only
in
my
data
center.
Nobody
else
goes
on
like
this.
Thirdly,
T
is
is
hard
right,
so
we've
seen
over
the
years
many
many
implementation,
Arizona
columns,
adding
complexity
like
this.
Adding
weaknesses
like
this,
the
Liberty
is
gonna,
make
it
worse.
Right.
AB
Implementations
like
this
will
keep
making
things
worse.
We'd
already
heard
just
the
argument
that
you
know
we
should
do
it
here,
because
if
we
don't
do
it
here,
it'll
be
done
worse
elsewhere,
I
think
go
find
an
elsewhere.
We
have
a
liaison
process
and
I
think
there's
one
DA's
long
statement
has
gone
to
some
lets.
You
recently
is
alright.
Athene
did
the
NC
liaison
okay,
so
we
used
the
IAB
recently
sent
of
the
A's
on
to
NCC.
AB
Also
the
meet
the
IAB.
If,
to
the
extent
that
we
trust
and
love
them,
it
gave
us
you
Satan
to
say
that
we
should
be
encrypting
work.
That's
a
good
thing
not
doing
the
opposite
is
a
good
plan
and,
lastly,
I
think
they
were
an
interesting
point
that
could
be
maybe
fleshed
out.
More
is
that
a
lot
of
these
proposals
may
be
a
little
less
so
between,
but
but
definitely
more
so
than
the
other
old
ones.
AB
They're
really
trying
to
turn
TLS
from
the
two-party
protocol,
ignoring
CAS
into
a
multi-party
protocol
and
not
change
the
interface
to
the
applications,
which
kind
of
just
doesn't
work
right
and
the
problem
that
people
have
and
why
they
seem
to
keep
going
back
is
that
they
know
that
if
they
proposed
a
new
multi-party
protocol,
it
has
zero
chance
of
being
deployed.
So
I
think
maybe
flashing
that
out
and
explaining
that
to
people
and
understanding
fed
ourselves
might
be.
Part
of
you
know
this
possible
work
item,
not
saying
don't
break
TLS,
so
spill
them.
AB
So
we
haven't
here.
A
bunch
of
specific
arguments
are
kind
of
fix.
You
Tamra
has
to
be
quickly
because
I
think
most
of
them
are
on
the
list.
A
lot
of
this
is
just
kind
of
scraped
from
from
reading
this
traffic
points,
other
people
made
basically
so
first
of
all,
breaking
TLS
is
not
part
of
the
working
group
Jared.
The
working
group
is
chartered
to
make
TLS
better,
not
to
make
it
worse.
AB
Another.
Our
Charter
is
ways
that,
even
if
you
did
accept
that
this
black
queen
proposal
was
something
that
was
crazy,
but
we
should
do
for
some
reason.
Then
it
still
sets
like
the
Charter
TLS,
because
they're
claimed
by
the
authors
is
it
doesn't
change
the
LS
accept
it
does
I,
have
this
wiretapping
API
and
that's
not
party
less,
so
they
should
if
they
want
from
come
back
and
argue
to
do
this
outside
here's
a
process.
Kind
of
thing
is
that
we've
seen
a
tea.
AB
That's
one
point
three
is
almost
done
and
DT
last
one
point
three
is
on
the
way.
If
you
look
at
the
abstract
of
TLS
one
point
three,
it
says
this
is
designed
to
prevent
eavesdropping.
If
this
working
group,
or
even
if
the
IETF
talked
on
this
kind
of
work,
that
would
no
longer
return,
are
we
gonna
issue?
You
know
one
of
our
most
important
security
RFC's
with
a
blatantly
false
statement
in
the
abstract.
Is
that
credible,
I?
Don't
think
so?
AB
On
the
same
lines,
Christian
I
think
proposed
a
PR
40's
1.3,
that's
designed
to
basically
make
it
harder
for
people
to
pull
this
bad
trick
again.
If
somebody
in
the
ITF
takes
our
network,
we're
just
getting
screening
we're
fighting
against
ourselves,
we've
had
I
think
it
quite
a
success.
It
is
one
point
three
in
attracting
and
getting
interaction
with
academic
cryptographers,
who
have
done
significant
work
and
big
analyses.
I
think
that
was
a
great
success.
I
think
it
would
be
great
to
kind
of
replicate.
AB
It
I
think
that
we
put
that
at
risk
in
the
sense
that
if
we
start
changing
the
protocol
like
this
and
regardless
what
people
say,
adding
a
wire
type
API
changes
the
protocol,
it
changes
the
environment
or
entities
that
might
invalidate
the
whole
bunch
of
analyses.
Certainly
those
analysis
analyses
that
have
been
done
did
not
take
this
into
account.
We
also
put
at
risk
the
process
of
them,
inviting
those
people
to
help
us
because
I
suspect
some
of
those
mucky
little
bit
pissed
off.
AB
If
at
the
last
minute,
we
kind
of
change
the
entire
kind
of
situation
say:
oh
by
the
way
were
talking,
there
are
some
specific
issues
with
static
POS
that
ironically
H
Kenny
has
pointed
out.
That
can
lead
imitation
failures
and
particularly
spectacular
ones.
If
you
look
there's
a
link
there
to
attack
from
Kenny
here.
AB
Second,
so
must
be
sober,
our
ski
sorry,
ok,
so
there
are
particular
attacks
and
that
can
be
really
kind
of
catastrophic
I.
Think
in
that
case
the
the
actual
private
key
leaks
out
so
that
the
DHCP
critique
self
or
the
a
secretly
accept
yes
and
quick
is
another
kind
of
process
issue.
So
I
think
the
quick
protocol
is
very
like
TLS.
If,
for
some
crazy
reason,
we've
made
the
wrong
decision
and
said:
let's
do
something
about
this:
that's
something
we'll
in
Piketon
pick,
because
exactly
the
same
stuff
will
happen.
AB
AB
Okay,
yes,
points
point
I,
see
this
within
the
enterprise.
Stuff
is
just
right:
it's
nothing
to
do
with
the
protocol,
there's
no
kind
of
magic
boundary
there.
The
author's
themselves
agree,
there's
nothing!
You
can
do
to
say
that
there's
any
way
of
enforcing
it.
If
you
do
it
and
specify
this
it's
going
to
apply
not
just
within
enterprises.
All
arguments
say
this
is
only
being
done
within
the
enterprise
or
just
assets.
So
I'm
again,
we
have
cases
so
I.
Think
the
lab
of
the
case
is
kind
of
interesting.
AB
If
you
argue
that
this
is
not
a
wire
to
everything
because
it
was
attacked
about,
but
what
they
wanted
was
to
extract
the
private
key
material.
So
we
have
cases
where
exactly
this
approach
was
sought
by
authorities
in
order
to
do
essentially
wiretapping
and
would
I
come
back
to
the
wiretapping,
so
you
can
school
them
in
it.
So
the
answer
is:
it
is
a
wiretapping
thing:
it
does
meet
2084,
so
you
get
into
the
level
it's
pervasive
monitoring.
AB
If
you
look
again
at
some
of
the
concerns
people
had
about
into
Jeffrey
Hammond
and
maybe
to
shorts
primes
it,
there
is
an
API
that
some
of
the
Decrypter
API
that
they
were
using
basically
would
need
to
call
out
to
exactly
this
kind
right
here.
So
the
point
is,
if
you
have
a
please,
please
give
me
your
private
if
you
haven't
by
your
API
that
would
fit
in
exactly
to
what's
been
reported
and
you
can
follow
the
links
to
have
been
done
in
cases
of
Perez
mark.
That's
a
perfect
tool
for
price
monitoring.
AB
Again
we
have
come.
We
have
kind
of
senses,
that's
an
attack.
Also.
We
have
DCP
200,
which
is
by
rather
old
RFC,
but
rather
new
PCP,
again
on
which
the
ITF
has
consensus,
and
it
says
don't
do
crap
crypto
and
essentially
we
know
the
statical
Gellman.
Here
is
worse
that
popularized,
a
that
means
is
crap
crypto,
there's
a
whole
bunch
of
text
in
that
PCP.
That
kind
of
does
apply
here,
even
though
the
context
was
slightly
different
from
that
was
with.
AB
It
was
more
about
foundation,
TTS
Pro,
but
essentially
this
is
kind
of
doing
the
same
thing
at
the
corporate
level,
as
opposed
to
necessarily
at
the
government
know
again
Nixon
point
of
some
issues
with
statically.
We
have
a
proposal.
Those
are
real
open
scrutiny
as
an
argument.
Well,
yeah,
it's
I
think
you
could
make
an
argument
that
again
this
would
be
neatly
fleshed
out
more
while
the
kind
of
scrutiny
we
provide
in
the
ITF
is
good
for
a
good
crypto.
It's
not
necessarily
good
for
bad
picture.
I
think
the
math
has.
AB
It
was
a
co-author
on
a
fine
paper
called
keys
under
doormats,
and
if
you
look
at
some
text
coded
to
Matt,
it
seems
pretty
clear
that
what
we're
talking
about
here
is
exceptional
access,
which
is
exactly
what
that
paper
argues
against
it
puzzles
me.
I
would
say
somebody
on
the
list,
I
think
I'm,
not
sure
with
procedures
are
not
suggested,
but
if
you
have
this
kind
of
wire
tapping
API
and
it
was
visible
or
invisible,
you
could
actually
say
this
is
part
of
my
terms
of
conditions.
AB
Okay,
the
question
visibility
is
interesting,
though,
and
again
it's
a
little
bit
a
little
bit
further
analysis.
The
claim
is
that
this
scheme
would
be
visible
to
people
in
the
internet
and
SSL
labs
would
give
you
an
X.
If
that's
the
case,
it
wouldn't
be
turned
on
what
we
would
do
is
they
would
change
the
scheme
to
be
something
that's
not
detectable
as
soon
as
you
have
the
API
as
soon
as
you're
able
to
do
that,
give
it
up.
AB
If
you
haven't
private,
there's
many
ways
you
can
come
up
with,
in
which
you
could
vary,
that
value
over
time
or
go
back
to
just
giving
a
seed
for
some
random
number
generation
or
whatever,
so
that
it
would
become
undetectable
all
right,
bad,
it's
100%
sure
that
would
happen.
So
the
argument
about
who's
being
detectable
I
think
is,
is
mistaken.
I'd
best
go
ahead.
AB
Okay,
so
again
an
argument
either
that
we
don't
develop
the
solution.
The
ITF,
worse
solutions
would
be
proud,
I
think
the
game
that's
wrong,
because,
with
the
exact
same
level
of
evidence
offered
for
this
island,
I
can
have
a
counter-argument
says:
no,
it's
the
opposite.
So,
basically,
the
worst
solutions,
I
think,
once
you
have
the
API,
if
we
did
work
on
this
API
lots
and
lots
and
lots
of
worse
solutions
and
many
definitions
of
words
pick
your
own
definition.
AB
You
can
find
them
then
that'll
happen
because
the
API
exists,
it'll
be
used,
it'll
be
expanded
and
it's
impossible
to
do
this
without
being
extensible.
The
draft
itself,
I
think
doesn't
seem
to
mention
active
attacks.
So
if
you
PM
out
this
value,
the
the
person
who's
got,
the
can
also
do
active
attacks.
AB
So
that
again,
would
be
the
punch
analysis.
Now
we
may
have
a
whole
bunch
of
different
things
happening.
I
think
you
know
again
the
appointments
made
under
this.
That's
if
we
sounded
like
this,
no
matter
how
much
people
say,
we
only
wants
to
use
in
the
data
center.
That's
not
what's
going
to
happen.
The
code
will
leak.
Oh
that
would
start
to
be
used
in
the
Internet
and
that's
what's
going
to
happen
so
again,
it's
not
an
enterprise
thing,
even
if
you
have
an
enterprise
motivation.
The
proposed
solution
are
any
proposed
solution
in
this
place.
AB
AB
So
we
want
to
be
lawyerly
about
the
definition
and
we
look
at
the
picture
there.
We
have
this
an
email
scenario
where
I
have
a
mail
sender
since
there's
the
mid
server
over
SMTP
over
TLS,
so
mid
server
forwards
down
to
the
MX
of
the
recipient
happens
to
be,
as
in
our
particular
college
network,
that
we
have
a
third
party
who
does
antivirus
coming
first,
so
it's
again
over
SMTP
or
DNS.
They
were
then
forwarded
on
it's
all
good
to
define
on
my
recipient
city,
the
NPA
who
they
know.
AB
AB
Personally,
without
deep
knowledge
of
the
sender,
the
receiver,
the
sender's
organization
of
the
receivers
arbitration,
the
idea
that
this
is
not
wiretapping
is
just
assets
scroll
down
for
one
more
example,
if
you
consider
hosted
websites
so
particularly
the
kind
of
hosting
that
let's
say
wordpress.com
Bo's,
we
maybe
get
a
vanity
domain,
but
you
don't
have
shell
access
to
the
machine
so
you're
using
this
website,
you
have
some
level
of
application,
error
control,
but
nothing
at
the
control
that
will
have
a
look
at
your
last
session.
That's
all
control
point.
AB
Let's
say
the
affirm,
the
wordpress.com
if
they
turn
this
on,
if
you
have
two
people
commenting
and
another
on
a
blog
there
be
Marta,
doesn't
matter
that
the
TLS
server
knows
about
it,
because
the
TLS
server
is
not
sander,
it's
not
the
receiver.
It's
a
third
part,
okay,
scroll
down
a
little
more
for
the
so
lasted
again.
I
would
like
to
see
us
kill
this
proposal
dead
and
after
having
done
that,
I
would
like
us
to
think
about
it
and
I
read
about
this
book
right
answer
is
here.
AB
Would
it
be
useful
first
document,
some
of
this
kind
of
stuff?
In
NRC
would
that
save
us
time?
The
next
time
bad
idea,
fairy
pops
up
and
or
what
so
I
think
it'd
be
interesting.
There's
a
whole
is
you
can
see
history
of
these
proposals,
they
very
different
ways,
but
they
come
up
at
a
certain
frequency
like
it's
more
than
it's
more
than
one
every
two
years,
and
so
the
question
is
a
group,
but
I
don't
know
the
right
answer.
AB
Do
we
people
would
save
us
time
if
we
document
some
of
this
so
that
the
next
time
it
comes
up?
We
at
least
point
them
there,
but,
as
you
can
see
already
we're
at
with
2804
with
PCP
272
58,
you
already
have
a
lot
of
things
at
which
the
point,
but
yet
they
keep
coming
back.
Anyway.
Sorry,
that's
my
question
to
the
group.
After
having
killed
his
pedigree.
E
So
again,
we've
had
hundreds
of
emails
about
this
particular
topic.
If
you
would
like
to
get
up
and
query
points
about
that
have
been
raised,
he's
D
so
now
we're
gonna
try
to
do
kind
of
strict
flow
control.
Remember
keep
it
professional
like
the
Mike
as
well.
AC
Pki
world
I
saw
what
happened
with
blue
curtain
Co,
though,
basically
we
didn't
make
holes
in
the
web
PKI
for
them,
so
they
blasted
them
through
with
Dharan.
Might
the
other
point
that
I'd
make
is
Stephen
made
a
great
argument
about
slippery
slopes
and
so
on?
There
is
a
slippery
slope
here,
but
cache
your
mind
back
to
the
origins
of
SSL
and
serve
a
gated
crypto
we've
actually
gone
in
the
reverse
direction.
AC
AC
Bits
I
mean
yeah.
I
would
like
to
have
this
written
in
such
a
way
that
if
it
gets
released
into
the
wild,
it's
less
likely
to
be
compatible
with
the
legacy
infrastructure
and
at
the
moment
it's
too
compatible.
But
the
other
thing
I'd,
like
people,
think
back
when
I
started
in
computing.
I
was
the
internet.
I,
CI
and
I
was
doing
SCADA
data
control,
real-time
process
control.
Before
we
had
the
name
SCADA
and
on
a
chemical
plant.
AC
You
do
not
encrypt
your
data
because
you
want
to
have
this
type
of
monitoring
and
I'd
like
to
encrypt.
So
you
have
a
security
choice
here
and
you
need
to
be
rather
careful
because
any
security
problem
I
know
is
really
really
easy
to
solve.
If
you
decide
to
solve
that
one
to
the
exclusion
of
all
others
and
to
achieve
real
security,
you
have
to
have
a
balance
and
I
would
rather
internal
data.
Centers
and
chemical
plants
are
encrypted
than
designed
the
crypto
in
such
a
way
that
they
can't
apply
it.
N
Paul
Volcker
threatened
I
want
to
quote
two
lines
from
RFC
43078,
a
proof
by
is
G
currently
in
the
RFC
editor
Q
talking
about
the
element
group,
22,
23
and
24,
which
are
basically
suspicious
ephemeral,
leash
like
diffie-hellman
groups.
This
is
results
that
in
group
22
to
be
devoted
to
must
not
group,
23
and
24
been
demoted
to
should
not
and
I
expect
it
to
be
further
downgraded
in
your
future.
Two
must
not
so
anyone
who
is
worried
about
TLS
I
welcome
you
to
use
IPSec
in
the
future.
AA
U
U
AD
I'll
sit
down
now:
yeah
rich,
rich
sauce,
Akamai
I
have
a
problem.
I'm
torn
between
yeah
I,
find
this
professionally
and
personally
not
a
good
thing,
but
I
also
remember
Dave
Clark
stalk
at
the
last
plenary,
which
was
you
know,
we
should
try
to
tilt
the
playing
field
of
things
if
people
are
going
to
do
things,
and
so
I
want
to
be
aware
of
that.
The
only
answer
I
come
up
with
so
far
is
sort
of
the
traditional
US
Congress
thing.
Is
we
just
kick
it
down
the
road?
AD
We
don't
have
even
finished
TLS
1/3,
it's
clear
that
anything
that
addresses
these
issues
is
not
going
to
be
part
of
the
core.
So
I
really
like
to
see
us
wait.
Two
years
until
we
get
TLS
ones
redeployed
see
what
the
real
problems
are.
Nobody
is
weak
being
required
to
deploy
TLS
1/3
now
PCI
hasn't
even
required,
TLS
1.2.
Yet
so
I
think
it's
premature.
Let's.
AD
AE
Am
Darren
Pettis
from
a
large
financial
organization?
It's
pretty
tough
to
follow
up
for
it
with
all
the
OP
applause
but
I'm
just
here
today.
Thank
you,
because
we
have
been
here
in
the
past
in
in
Seoul
Korea
part
of
the
organization,
with
the
gentleman
that
proposed
the
draft
just
to
understand
the
technical
issues.
We
do
it
today
with
RSA
and
we
aren't
asking
to
bring
it
back.
We
understand
that
would
move
forward
and
it's
gone
and
so
we're
looking
for
a
new
mechanism.
AE
We
took
a
lot
of
the
technical
solutions
that
were
offered
up
to
us
and
met
with
a
lot
of
individuals,
other
enterprises
to
understand
what
could
be
done.
We've
brought
on
a
lot
of
people
that
understand
the
technology,
much
better
than
I.
Do
the
encryption,
people
that
understand
the
ITF
and
we're
trying
to
work
with
you,
because
we'd
like
to
take
a
standards-based
approach
and
figure
out
the
best
way.
This
was
one
of
the
ones
that
was
come
up
with.
AE
It
seemed
like
the
best
one
to
us,
but
it
may
not
to
you,
as
the
experts
very
open
to
other
ideas,
and
we
definitely
don't
want
to
preclude
the
actual
1.3
draft
going
forward.
That's
that
has
to
happen.
I'm
a
privacy
advocate
myself
and
a
very
appreciative
of
that.
So
just
looking
for
this
groups
help
to
figure
out
what
the
best
way
for
it
is
and
I'd
like
to
ask
for
your
help.
Thank
you.
So.
E
Q
Okay,
Roman
dinelli
from
CMU
what
I
didn't
see
on
the
man
list
or
in
the
presentation
here
was
talking
about
the
security
use
case
for
this
specifically
in
incident
response
and
I
just
wanted
to
highlight
about
techniques
used
when
you're
hunting
active
compromised,
specifically
finding
lateral
movement
and
the
ability
to
do
ad
hoc
instrumentation
is
really
key
to
finding
those
IO
sees
that
you
can
then
put
in
all
those
proxies
and
firewalls
and
the
ability
to
do
that
pass
of
capturing.
The
decrypt
really
helps
helps
the
analysts.
P
AF
Fleming
Andreasen,
cisco
security,
business
cube
speaking
specifically
the
policy
issue
here,
I
think
the
operational
issues
are
very
real
I
think
our
other
use
key
scenarios
as
well.
That
could
greatly
benefit
from
this
and
I've
been
pushing
everything
to
the
endpoint
in
practice.
It
does
not
work
so
I'm
very
much
in
support
of
trying
to
take
on
this
issue.
AF
I,
don't
think
the
community
is
served
by
viewing
this
as
a
black
or
white
discussion
right
either
we
get
privacy,
you
or
you
know,
get
this
thing
and
it
to
a
complete
at
odds
with
each
other
I
think
having
a
pragmatic
approach
to
it
would
be
useful
to
some
extent.
This
reminds
me
of
some
did
NAT
discussions.
We
had
many
years
ago.
That's
a
bad
right,
they're
going
to
prevent
us
from
essentially
getting
ipv6
deployed,
so
we
should
ignore
them
forever.
I
think
we
all
understand
how
that
worked
out
right
in
the
end.
AF
AG
And
Billina
Elkins,
yes,
I
think
this.
There
are
some
very
real
problems
from
very
real
people.
Doing
real
things,
and
you
know
the
Internet
is
not
just
a
service.
It's
used
by
real
people,
grandma
to
do
real
things
like
internet
banking
and
if
you're
hearing
from
people
that
internet
banking
stopped
trading
insurance.
All
these
things
are
going
to
have
lots
and
lots
of
problems.
I
think
it
behooves
us
to
listen.
R
R
We
looked
at
that
when
we
had
some
discussions
around
the
Hawaii
time
frame
and
we
chose
not
to
accept
that
work,
and
the
reasoning
was
that
HTTP
is
defined
explicitly
as
an
end-to-end
encrypted
protocol
and
therefore
a
two
party
protocol,
and
we
did
not
have
a
way
to
get
the
informed
consent.
If
I
want
to
use
that
term
of
the
whole
population
of
the
planet
to
change
the
semantics
of
protocol,
they
were
already
using
I
kind
of
think.
R
M
Ted
Hardy
gloriously
affiliated
with
a
couple
of
different
things,
and
in
this
case
that,
though,
just
speaking
for
myself
I
think
there
are
two
points
here,
one
that
relates
in
some
ways
to
the
point
Marcus
made,
and
that
is
that
forward.
Secrecy
is
a
feature
of
this
protocol.
This
proposed
turns
off
forward
secrecy
in
certain
contexts,
without
it
being
obvious
to
the
end-users
that
fort
secrecy
has
been
removed.
In
particular,
you
can
tell
on
the
first
connection
where
a
particular
key
is
used.
M
I
do
not
believe
that
this
proposal
meets
that
basic
requirement
of
protocol
design
as
a
result,
if
it
came
back,
I
would
suggest
that
it
be
changed
fairly
fundamentally,
so
that
it
did
have
that.
Secondly,
if
it
comes
back
with
that
added
I
believe
there's
a
very
fundamental
question
that
the
working
group
has
to
answer.
M
What's
the
domain
of
analysis
and
I
believe
Russ
Redis,
section
three
of
particular
RFC
2048,
but
did
not
read
as
section
4,
which
is
an
interesting
follow-on
piece
of
reading,
because
it
says
we're
not
taking
a
moral
standpoint
here,
we're
taking
a
technical
one
and
a
very
basic
part
of
that
technical
one
is
that
if
you
define
a
piece
of
technology
for
use
in
a
specific
use
case
or
domain,
you
must
expect
it
to
be
used
in
other
places
as
well
and
I.
Believe
many
people
have
made
the
same
point
as
RFC
2048.
M
AH
Max
Bala,
CableLabs
and
I
just
want
to
say
that
I
really
support
what
and
Farrell
just
said
and
presented
and
all
the
arguments
about
not
adopting
these
three.
All
the
arguments
about
the
direction
of
the
TLS,
1.3
I
think
still
stand.
My
personal
experience
with
large
corporate
environment
is
that,
most
of
the
time
you
try
to
say
that
you
know
this
is
a
problem.
If
your
internal
architecture
is
outdated,
there's
many
different
ways
to
solve
this
problem
and,
if
you're
not
ready
to
for
TLS
1.3,
nobody
forces
you
to
do
it.
AH
AA
As
the
folks
here
in
the
room
and
outside
the
room,
consider
the
discussion
that
we
have
today
consider
the
presentations
have
been
made
and
consider
what
the
working
group
is
going
to
do
going
forward,
I'd
like
to
emphasize
keeping
separate
the
fundamental
abstract
questions
and
problems
that
are
being
discussed,
the
operational
problems,
the
pragmatic
operational
problems
that
the
enterprise
network
people
have
to
solve,
and
the
particular
proposal
that's
on
the
table
in
this
document,
there's
been
a
lot
of
discussion
to
the
effect
of
this
should
be
rejected.
This
should
not
be
accepted.
AA
This
document
should
not
be
taken
on
as
a
working
group
document
and
I
felt
as
though
there
wasn't
that
separation
between
the
consideration
of
the
fundamental
problem,
the
abstraction,
the
abstract
issues
that
the
operational
people
need
to
solve,
and
the
particular
solution
that
was
put
forward
exactly
as
you
emphasize
Shawn.
The
authors
of
this
proposal
are
more
than
happy
to
give
up
change
control
to
the
working
group.
AA
E
AI
Crypto,
it's
an
integral
part
of
their
business
model.
They
actually
end
up
facing.
You
know:
potential
fines
and
legal
liabilities
if
they
don't
safeguard
our
information.
The
bank's
the
healthcare
providers,
the
hospitals,
the
governmental
agencies
that
all
of
us
depend
upon
for
different
services
that
we
all
use
every
day
and
millions
of
other
people
do
around
the
world
as
well,
so
I
while
there
may
be.
AI
You
know
both
pros
and
cons
to
this
specific
proposal,
and
there
are
I
would
hope
that
the
sense
of
the
working
group
would
recognize
that
this
is
a
legitimate
issue
and
that
we
need
to
find
a
solution
so
that
we
don't
end
up
pushing
these
industries
into
crypto.
That
is
proprietary
in
nature.
That
has
been
dream
dreamt
up
by
groups
like
Etsy
or
the
I
Triple
E.
In
a
smoke-filled
room,
we
want
to
keep
them
on
the
standards
base,
crypto
path
with
strong
crypto.
Thank
you.
AJ
Hi
Jeff
Hodges
PayPal.
We
want
to
echo
the
points
that
Ralph
and
Darren
Pettis
and
Roland
and
Fleming,
who
was
in
line
before
us
that
you
know
there
are
from
the
enterprise
perspective.
Valid
needs
to
be
able
to
do
this
sort
of
thing
on
and
the
working
group
and
just
the
individuals
in
the
room.
It
would
be
great
we
all
kind
of
work
together
to
try
to
address
this
problem,
and
it's
not
just
a
single
point
in
time.
One
could
view
these
kinds
of
needs
as
transitional
over
many
years.
AJ
People
are
stuck
in
where
they
are
today
and
need
a
migration
path
to
get
to
the
point
where,
hopefully,
you
can
actually
have
forward
secure
inside
the
data
center,
but
it's
not
going
to
happen
tomorrow.
It's
it's
going
to
be
down
the
road
and
we,
it
would
be
great
to
have
a
migration
path
that
has
been
scrutinized
by
appropriate
experts
and
such
so
following
on
from
that,
there
have
been
folks
from
certain
organizations
in
the
argument
who
have
said
we
don't
have
to
do
this.
We
we
cover
the
bases
some
other
way
gee.
AJ
W
Christian
Rita
mom
I
would
like
to
comment
on
to
support
concert
Steve
and
that
Shivan
and
Ted
have
been
doing
and
take
the
lavabit
scenario.
When
the
lavabit
scenario
is
you
have
a
provider
of
service
and
that
provider
is
being
compelled
to
turn
on
a
feature
so
that,
basically
somebody
can
wait
all
the
traffic
that's
outside
cos
of
the
descent
of
scenario.
The
the
reason
why
this
draft
is
when
this
kind
of
approach
is
very
dangerous.
W
If
any
proposal
that
is
designed
for
data
center,
a
much
like
Ted
was
saying,
came
up
with
a
big
red
flag
in
the
wire
packet
that
says
I'm.
Turning
that
proposal
on
then
that
proposal
will
not
be
used.
That
would
not
be
as
easy
to
abuse,
because
if
someone
goes
to
the
lab
it
Center
and
says,
hey
don't
have
the
fit
your
please
you
are
between
your
software.
There
is
no
big
deal.
We
can
compel
it.
You
will
turn
it
and
then
all
your
packet
that
have
been
come
compelled
to
do
that.
W
We'll
also
have
the
big
red
flag
and
that
will
be
noticeable
by
everybody,
and
then
you
could
that
counteractions
and
I
think
that
this
big
red
flag
kind
of
requirement
is
something
that
we
should
absolutely
have,
and
we
don't
right
now.
That's
the
question:
I
was
asking
to
the
other.
What
kind
of
design
have
you
done
to
ensure
in
your
proposal
that
is
only
used,
but
everything.
O
Tengo,
franca,
Akamai,
so
I
support
adoption.
Adoption
of
this
proposal
with
graft
zero
as
a
starting
point,
but
I
oppose
draft
want.
The
reason
for
that
is
that
draft
grow
is
informational,
its
messages,
essentially,
here's
the
thing
that
it
is
possible
to
do
with
TLS
here
are
the
risks
and
benefits.
If
you
choose
to
do
it,
I
think
that's
a
good
message
that
is
indeed,
as
Professor
Green
characterizes
that
harm
harm
reduction.
It
helps
people
make
an
educated
business
decision
draft
one.
AK
Kenny
Patterson
from
Roe
Holloway,
and
also
a
co-chair
of
the
tryptophan
research
group,
thanks
Daniel,
and
so
it
was
said
earlier
that
this
proposal
will
be
an
advancement
on
what
we
were
doing
previously
with
static
RSA,
and
the
data
center
I'd
like
to
point
out
in
the
current
draft.
Absolutely
is
not
because
there's
nothing
that
requires
the
key
share
to
be
rotated
any
point.
It
says
it
should
be
rotate
at
my
suggestion,
for
the
working
group
is
to
adopt
the
draft
and
force
the
key
to
be
rotated
for
every
connection.
AK
AL
Hi
Sharon
Goldberg
from
Boston
University
a
lot
of
the
points
that
I
wanted
to
make
were
already
made.
I'll
just
make
the
one
main
one
I
want
to
support
what
Steven
Farrell
said
earlier,
and
I
also
want
to
point
out
that
this
proposal
is
not
tied
to
the
data
center
I,
don't
see
how
this
proposal
forces
this
mechanism
to
be
used
in
the
data
center
and
so
that,
for
that
reason,
I
don't
support
this
at
all.
Thank
you
all.
AM
Right
so
I'm
Deb
Cooley
from
NSA.
This
is
sort
of
a
personal
opinion,
though
so
I
believe
that
if
you
take
on
this
draft
here,
you
control
the
draft
and
you
control
it's
written
in
the
draft.
You
can
ask
for
mechanism
to
be
in
place.
That
shows
that
you,
you
know
that
states
that
this
is
what's
happening
right
so
that
the
other
end
knows
that
it's
happening.
AM
If
you
let
this
go
underground,
which
is
the
way
that
it
happened
with
static
RSA
in
the
past,
you
don't
know,
what's
going
to
happen
and
I
do
agree
with
PHP
right,
so
you
know
you're
they're
going
to
blow
through
it
with
a
stick
of
dynamite
as
opposed
to
controlling
it.
So
if
you
take
the
draft,
you
control
the
draft
and
it
happens
the
way
you
want
it
to
happen.
AN
AN
One
thing
I
wanted
other
is:
if
we're
also
worried
about
pushing
people
in
datacenters
away
by
adopting
this,
there's
also
lots
of
people
who
depend
on
TLS
and
depend
on
perfect
secure
forward
security
for
their
the
practice
of
their
rights,
their
human
rights
and
assume.
We
also
be
worried
about
pushing
those
people
away
from
TLS
we
adopt
that
should.
Thank
you.
B
Okay,
so
I
think
at
this
point
we've
heard
discussion
from
a
number
of
folks-
and
you
know,
there's
been
a
lot
of
different
points
raised.
I
think
we
would
like
to
at
this
point
take
a
hum
on
the
the
basic
question
here,
which
is:
is
this
wait
a
sec?
Is
this
particular
subject
of
passive
decryption
in
the
data
center,
something
the
work
working
group
should
consider
so
we'll
ask
for
a
yes
and
they
know.
B
AB
AB
F
AA
Right
right
once
again,
I'll
emphasize
that
point
I
made
a
little
while
ago
separate
the
particular
solution
in
the
draft
from
the
abstraction
of
the
operational
requirement.
So
this
is
talking
about
passive
decryption,
whether
or
not
static
eh
is
passive
or
active,
I,
don't
care!
What
we're
talking
about
about
right
now
is
passive
decryption.
AA
AD
AB
U
So,
sorry
to
add
another
nitpick
voice
to
the
questions
this
is
dkg.
We
have
been
considering
this
question
for
the
last
several
weeks
on
the
man
listened,
and
here
is
that.
So
what
is
this
question?
Like
I
mean
if
people
will
keep
if
people
keep
coming
back
here
and
trying
to
drag
this
in
I
will
continue
to
consider
it
and
push
back
on
it.
So
I'm
not
gonna,
say
that
I'm
not
going
to
push
back
on
it.
If
that
happens,
but
I
don't
know
how
to
hum
basis,
you
don't
say
so.
If,
if
you.
B
E
B
R
B
Okay,
so
now,
if
you
think
the
working
group
should
consider
this
topic.