►
From YouTube: IETF101-TLS-20180319-1740
Description
TLS meeting session at IETF101
2018/03/19 1740
https://datatracker.ietf.org/meeting/101/proceedings/
B
C
B
B
A
D
Steven
barrel
I'd
like
to
push
the
agenda
a
little
or
to
understand
it.
I
asked
on
the
list
and
what
was
the
basis
having
this
visibility
discussion
again,
given
that
we
had
this
discussion,
there
was
no
consensus
to
do
anything.
He
had
this
draft.
It
was
discussed
at
length
on
the
lists
back
in
September
October
last
year,
and
here
we
are
again
I,
don't
understand
the
logic
by
which
were
having
this
discussion
today.
B
So
we've
we've
gone
back
and
looking
at
the
messages
in
that
have
been
around
this
draft
and
there
are
both
people
who
are
vehemently
against
this
idea
and
people
who
think
it's
critical
for
the
operation
of
what
they
do.
There's
also
people
who
have
different
technical
contributions
or
opinions
as
to
how
things
should
be
done.
So
we
felt
it
was
still
appropriate
to
have
this
discussion
here
in
London.
D
B
D
B
E
F
A
All
right
Thanks,
so
the
first
thing
we're
to
do
is:
do
the
document
status
on
a
slightly
happier
note
TLS,
1.3
I
guess
is
an
approved
point
raised
at
this
point.
We
spun
a
new
version
to
deal
with
one
little
thing:
I'll
talk
about
like
for
10
seconds
about
that
on
Wednesday,
ECC,
cipher
suites
for
TLS
1.2
and
earlier,
and
the
ECD
HPS
key
stuff
is
in
the
RFC
editors
queue.
It's
pinned
on
a
kernel,
pickax
draft
that
is
on
the
IHT
telex
Chad
I,
believe
in
the
first
week
of
April.
So
those
should
go.
A
The
DNS
SEC
draft
is
being
clawed
back
to
the
working
group
based
on
some
iced
tea
discusses
and
some
other
things
that
they
pointed
out
the
last
second,
and
we
have
two
drafts
and
on
the
tele
chat
again
for
early
in
April,
and
then
we
have
a
whole
bunch
of
drafts
that
are
kind
of
in
play
and
we're
going
to
be
discussing
most
of
those
on
Wednesday
all
right.
First
up,
it's
Thomas
the
record
header
extension.
G
G
Is
we
get
there
by
looking
at
places
where
we
could
actually
signal
the
presence
of
the
seed
and
and
and
and
and
and
we
were
looking
very
there's-
a
scarcity
of
place
where
to
actually
include
that
semantics,
but
there's
this
lonely
Emma's
being
in
the
length
which
is
unused
which
could
be
used
for
for
that
and
then
and
then
we
observe
the
thing
that
if,
if
you're
not
greedy-
and
we
don't
allocate
that
bit
for
the
seed
only
but
we
allow
we
sacrifice
one
more
more
more
bites.
A
for
for
for.
G
G
So
I'll
does
it
work.
The
MSB
is
a
scientist.
New
semantics
is
the
extension
bit.
If
it
is
asserted,
then
the
space
between
the
header
and
the
payload
is
we
can
carve
space
there
and
and
and
in
code
it's
a
certain
number
of
extensions
that
have
the
format
that
is
at
the
bottom
of
the
of
the
slide,
where
basically
a
TLV
with
a
bit
the
MSB
of
this
thing.
G
That
signifies
the
presence
of
a
further
extension,
so
you
can
stack
it
the
extension
and
effectively
by
asserting
that
M
bit
only
on
the
on
your
extensions
is
itself
next,
please
so:
okay,
what
are
the
design
criteria
here?
So
we
wanted
to
have
a
very,
very
limited
vocabulary
and
in
fact
we
have
four
bit
only
so
we
have
16
good
points
and
and
this
because
we
recognize
the
fact
that
this
mechanism
could
be
used.
G
So
there's
this
privacy
implications
here
and,
and
so
keeping
this
vocabulary
very,
very
narrow,
allows,
say:
CC
hell
I
was
a
working
group
to
exert
the
the
right
amount
of
you,
no
control
over
this,
this
code
space.
For
now,
the
only
envisaged
use
of
this
extension
is
the
connection
ID,
but
it
was
suggested
by
in
an
offline
conversation.
We
think
that
we
could
do
something
more
than
just
the
connection
ID
and
have
an
and
allocate
another
another
code
point
to
to
actually
resolve
the
asymmetry
that
we
have
in
1.3
1.2.
G
As
with
regards
to
the
connection
ID,
the
connection
ID
can
only
so
1.3
endpoints
can
update
the
seed
mid-life,
whereas
1.2
endpoints
are
stuck
with
the
with
the
actual
seed
that
was
negotiated
at
an
shake.
If
we
had
something
like
this,
we
could
use
a
new
extension
to
say
to
encode
the
semantics
right
and
have
feature
parity
between
1.2
and
1.3,
which
seems
rather
cool
the
other.
The
other
doesn't
design
criteria
is
that
this
thing
is
only
usable
when
both
endpoints
agree
right
and
in
order
to
do
that,
we
we
hook
this.
G
G
Okay,
so
we
can
start
using
the
e
bead
only
after
the
end,
shake
has
successfully
completed,
and
this
allows
also
backwards
compatibility
right
with
endpoints
that
don't
understand
the
semantics
next,
please,
okay,
so
an
example.
Let's
suppose
that
we
have
two
end
points
that
definite
one
point
two
end
points
that
I've
not
negotiated
the
the
seed.
How
would
you
use
this
this
framework
in
the
specific
case,
so
we
have
the
e
bits
so
next
place.
We.
G
We
assert
that
bit
next,
the
space
between
the
header
and
the
payload
which
opens
up,
and
you
read
the
first
two
bytes
and
next,
please,
you
identify
the
type
she
0
0
in
this
case
the
city
0
0,
because
the
first
one
that's
been
allocated
and
then
next,
please,
you
read
the
length
is
2
bytes,
so
you
next,
please,
you
consume
the
next
device.
41:42
a
be
perfect!
G
You
get
a
seed,
you
extract
it
next,
please,
you
read
back
the
top
bit
and
you
and
there's
no
other
extension,
so
you're
you're
done
with
it
and
then
explicit.
So
you
start
consuming
the
payload
given
the
length
so
the
line
that
must
be
you.
You
need
subtract,
of
course,
the
length
of
the
of
the
extension
or
the
stack
of
extensions
that
you
have
there
and
then
you
can
start
reading
and
payload
next,
please.
G
So
if
they
don't
understand
the
semantics,
they
will
just
break
the
connection
or
if
they,
the
other.
The
other
option
is
that
they
they
cancel
out
the
the
extension
because
they
don't
know
what
the
semantics
is,
and
so
the
thing
can't
be
negotiated
end
to
end
so
for
the
0
1
is
only
the
only
focus
for
0.
1
is
DTLS
next,
please.
G
I
Scarlett,
my
regular
hat
on
so
I
mean
the
usual
reason
why
you
in
band
signal
in
a
packet
whether
an
option
exists,
is
because
ambiguity
about
whether
the
state
of
that
the
state
of
the
packet,
because
it
can't
be
interpreted
independently,
but
in
this
case
the
because,
as
part
of
an
association
you
doona
factor
of
the
state
of
the
packet,
because
you
know
what
the
association
is
and
so
the
now
I'm
sure
you're
gonna
say
you
don't
know.
If
I
see
it
you
don't
if
you're,
not.
I
If
you
have
you
know
for
troop
overloading,
then
you
don't
know
which
Association
it
is.
But
for
that
use
the
CID.
So
I
guess
I,
don't
understand.
If
you
have,
if
you
have
a
way
to
indicate
the
CID,
then
you
can
look
up
the
packet
and
the
because
Association
and
then
you
know
the
state
and
you
know,
and
then
you
can
put
any
other
crap
you
want
after
that,
because
you
can
independently
you
can't
Lena,
go
she
ate.
Yes,
so
I,
don't
understand
why
you
need
a
generic
extension
mechanism.
I
This
is
key
off
of
this
key
off
a
bit
of
the
header,
and
I
mean
to
be
concrete
about
this,
like
that's,
weird,
really,
quick
and
quick
like
if
anything
can
be
inferred
from
this,
we
just
arrange
that
you
can
look
up
the
connection
and
once
you
go
look
for
the
connection,
everything
is
important.
They
say
the
connection
not
in
band
indicated
matter.
J
G
J
G
J
We
can
tell
people
not
to
use
the
space
or
we
can
not
design
the
space,
and
then
people
can't
use
it.
So
it
seems
to
me
like
if
your
goal
is
a
privacy
oriented
thing
where
you
say
we
have
this
one
goal,
which
is
the
connection
ID,
you
don't
make
the
generically
extensible
thing.
You
say
we're
gonna
use
this
one
bit
to
signal
the
presence
of
connection
ID
and
I
understand
why
that's
nervous,
by
the
makes
people
nervous
but
I'm
just
saying
we
had
this
fun
discussion.
L
The
I
think
I
think
I
agree
mostly
Whittaker
here.
There
are
sort
of
a
number
of
cases
that
you
you
concern
about,
but
the
only
thing
this
actually
souls
helps
with
is
in
the
case
where
you
have
packets,
that
arrive
from
on
a
different
four
tuples
than
the
one
that
the
connection
was
this.
That
was
done,
and
you
don't
have
any
expectation
about
whether
those
packets
came
from
a
connection
that
had
the
connection
ID
or
one.
L
L
Those
if
you,
if
you
look
at
this
and
you
assume
that
packets,
that
arrive
on
a
four
top
or
five
top
or
whatever
you
want
to
call
the
damn
thing,
is
that
you
don't
have
an
association
for
they
come
in.
You
don't
know
what
your
connection
it
belongs
to.
You
assume
that
it
has
a
connection
ID
and
you
proceed
based
on,
though,
on
that
you
were
very
quickly
realize
that
it
just
continues
to
work.
I'd.
L
G
K
Sort
of
Thomas
is
proposing
to
have
a
mechanism
to
indicate
in
Allen's
feed,
but
they
want
it
on
the
lens
field.
To
then
indicate
whether
the
series
they
are
not
and
then,
of
course,
that's
order.
The
you
bent
a
little
bit
to
further
to
generalize
this,
but
you
are
essentially
saying
that
you
want
to
use
a
more
approachable
istic
scheme.
In
some
sense,
no.
L
So
so
my
assertion
is
that
any
any
client
that
is
that
does
not
implement
connection
IDs
has
some
sort
of
expectation
already
that
they
have
stable
five
tuples
and
in
the
event
of
a
of
and
that
rebinding
or
some
of
these
events
that
we
actually
care
about
that.
My
courses
to
want
to
do
next
and
ID
then
you'll
get
a
few
packets.
Those
packets
will
drop
on
the
floor
and
then
the
story
will
be
over
I.
G
G
M
N
I'd
like
to
thank
the
chairs
for
letting
me
be
the
opening
act
for
the
big
show
this
was.
This
is
a
late
submission.
We
didn't
get
this
draft
put
together
until
after
the
deadline,
so
I
only
get
two
minutes
to
this
is
mainly
a
question
of.
Does
anyone
else
find
this
an
interesting
problem,
so
Owen
feel
and
I
came
across
a
use
case
where
we
wanted
to
use
TLS
with
a
short
low,
entropy
password
for
authentication.
N
If
we
were
looking
at
1.2,
we
could
have
used
SRP,
but
that's
turns
out
not
to
map
really
well
the
1.3,
so
we're
starting
to
look
at.
Could
we
use
an
extension
to
map
any
Paik
really,
but
we
went
with
s
pick
two
for
the
moment
for
the
key
exchange
in
authentication
in
see
last
one,
not
three.
So
next
slide,
please.
If
you
look
at
the
draft,
this
is
kind
of
what
we've
sketched
out.
N
You
stick
an
extension
in
the
client,
hello,
the
server
hello
that
does
the
key
exchange,
much
like
the
t-shirt
extension
and
then
you
use
the
finished
messages.
The
finished
max
to
do
the
key
confirmation
with
the
intermediate
results,
the
password
and
the
derived
keys
plugged
into
the
key
schedule,
the
appropriate
parts
so
I
think
I
don't
have
time
for
questions,
but
please
feel
free
to
see
me
on
the
break
or
follow
up
on
email.
I
would
love
to
find
out
if
there's
folks
interested
in
doing
cakes
for
TLS
1.3
Thanks.
A
So
I
mean
the
premise
of
this.
This
draft
of
this
discussion
release
to
figure
out
if
we're
gonna,
we're
gonna
end
up
in
a
point
where
we
didn't
make
a
home
for
adoption
for
this
draft.
Essentially,
the
the
draft
doesn't
have
to
be
perfect
when
it
gets
adopted
by
the
working
group,
because
the
working
group
gets
changed
control
of
the
document
and
we
can
change
it
if
we
were
to
adopt
it.
So
I
want
people
to
remember
that.
A
There's
not
an
idea
that
it
has
to
be
perfectly
polished
before
we
move
on
so
I
think
that's
pretty
much.
What
I
wanted
to
say
and
we're
gonna
have
a
rest.
Give
a
quick
discussion
about
the
technical
points
of
the
draft
and
then
we're
actually
gonna
go
ahead,
have
like
a
tenma
discussion
and
then
we've
reserved
ten
minutes
to
kind
of
go
through
the
hums
and
I'm
sure
that
you
will
agenda
bash
and
want
to
put
editorial
input
on
it.
A
That
is
arguably
some
will
make
that
argument
that
it's
in
scope
of
the
working
group,
because
it's
a
tailless
extension
and
to
be
honest
if
they
want
to
proceed
and
do
anything.
The
first
thing
that
they
have
to
do
is
come
to
us
and
ask
us.
So
that's
what
they're
actually
doing
and
that's
the
plan
for
today
dress.
O
Okay,
Russ
Housley
I'm
presenting
a
draft
the
Ralph
groms
that
I've
worked
on
together,
so
the
need
for
this
has
been
discussed
at
length
and
I'm
not
going
to
go
through
that
again.
But
I
do
think
that
you
should
take
a
look
at
these
two
drafts
if
you're
new
to
this
discussion.
So
you
know
why
we
have
it.
O
At
the
end
of
that
discussion
in
soeul,
we
heard
that
people
were
much
happier
with
an
opt-in
to
approach.
That
is
where
the
client
had
to
do
something
to
say:
I'm,
okay,
with
this
invisibility
happening,
as
opposed
to
the
previous
approach,
which
only
the
server
had
to
interact
with
the
key
manager
and
the
client
was
completely
unaware.
So
what
we
have
done
is
put
together
approach
that
does
that
Steven
I
like
to
go
through
all
the
slides
and
new
questions
is
that
okay,
it's.
D
O
O
Impress
the
impact
that
going
to
ECD
h
will
have
in
the
data
center
environment.
The
extension
provides
an
opt-in
mechanism
that
allows
a
TLS
client
a
server
to
negotiate
and
agree
whether
this
visibility
will
be
granted.
The
enterprise
key
manager
is
the
one
who
decides
who
the
other
parties
are.
That
can
see
it.
O
O
O
We
didn't
want
to
make
up
a
way
to
name
these
things,
so
we
just
used
a
fingerprint,
which
is
the
sha-256
hash
of
the
public,
key
to
name
that
that
wraping
key
pair
next
slide.
So
the
idea
is
that
the
client
includes
an
extension
that
has
an
empty
structure
that
says
I'm
willing
to
participate
in
this.
O
The
server
then
uses
the
public
key
that
it,
the
private,
the
public
key
that
it
has
and
the
private
key
that
the
other
parties
have
to
wrap
up
the
information
that
is
needed
for
the
decrypt
to
happen
and
passes
that,
along
so
any
of
the
parties
who
are
going
to
be
doing
the
decryption
decrypt
the
information
in
the
server
hello
in
order
to
get
to
the
things
that
allow
it
to
compute
the
key
schedule
to
decrypt
the
rest.
Earlier
this
week
we
heard
about
a
different
approach
that
didn't
include
the
resumption
key.
O
O
So
these
are
the
details
of
how
that
encryption
happens.
The
I
think
the
text
at
the
bottom
shows
that
we're
just
using
the
HK
DF
extract
and
expand
mechanisms
to
get
to
those
keys
very
much
similar
to
the
way
the
key
schedule
is
used
again
subject.
All
these
details
be
glad
to
talk
about
if
the
group
even
wants
to
go
forward
with
this.
O
D
D
Yeah,
that's
correct
right
so,
and
does
that
give
me
the
draught
vendor
that
you
mentioned?
Does
that
match
their
use
cases
at
all
because
they
mentioned
multiple
different?
You
know
many
different
reasons
why
they
want
to
snoop
on
the
data
all
over
the
place
right.
Yes,
so
you
think
it's
all
the
same
team.
That's
doing
it.
O
P
Been
Benkei
duck
so,
if
I
understand
correctly,
the
use
case
here
is
in
take
in
the
data
center
and
it's
server
the
server.
So
my
question
is:
does
there
need
to
be
a
negotiation
in
the
protocol?
Sense,
or
is
this
something
that
could
just
be
pre
agreed
that
you
are
going
to
do
something
of
this
nature?
Sure.
O
That's
that's
possibility
the
people
who
raised
concerns
and
wanted
the
opt-in
did
not
like
draft
green
because
drive
green
did
exactly
what
you
just
said.
It
was
totally
between
the
server
and
the
key
manager
and
the
key
manager
deciding
who
they
could
be
so
based
on
those
concerns.
We
took
this
approach.
P
O
P
So
in
TLS
we
have
these
extensions
that
are
frequently
used
to
negotiate.
The
use
of
certain
protocol
features
correct
in
the
data
center.
You
frequently
know
that
you're
going
to
be
talking
to
a
specific
pure
that
has
a
specific
implementation
and
specific
features.
So
in
principle,
you
could
bilaterally
decide
that
between
a
given
set
of
peers,
you're
going
to
do
some
particular
thing
which
may
look
a
lot
like
TLS
and
may
not
be
exactly
TLS
and
I'm.
Sorry
trying
to
understand.
Q
Darren
Thank
You,
Darren
Pettis
u.s.
bank
I
just
want
to
speak
to
Stevens
question.
Why
do
we
keep
talking
about
this?
I?
Think
the
fact
that
people
continue
to
come
here
and
share
the
reasons
of
why
this
needs
to
be
addressed
for
data
center
decryption
speaks
to
the
continued
need.
I
mean
we
all
go
up
to
the
doctor.
We
all
go
to
retail
stores
we
have.
This
is
going
to
affect
all
of
us
individually,
so
I
think
a
lot
of
good
things
have
been
done
on
the
Internet
I'm,
not
against
in
the
end
I'm.
Q
A
privacy
advocate
myself,
but
I
also
understand
that
we
have
to
look
at
the
data
once
it's
sent
to
us
is
its
Decimus.
It's
not
transitory
anymore,
it's
destined
to
us
and
we're
responsible
for
securing
it,
ensuring
the
performance.
So
you
know
just
like
to
say
that
we'd
like
to
ask
for
a
vote
forward
for
this
when
we
rip
the
band-aid
off
and
go
ahead
and
and
take
this
into
this
work
into
account,
voice,
Thank,
You,.
R
Philip
hon
Baker
comodo
group
I
agree
that
this
is
a
very
important
use
case
and,
in
particular,
in
the
SCADA
world,
when
I
was
working
on
a
chemical
plant.
There's
no
way
that
we
could
have
a
communication
going
on
that
we
couldn't
strap
an
analyzer
on
to
look
at
what
that
traffic
was
so.
Visibility
of
the
traffic
was
more
important
to
us
than
confidentiality.
Our
big
concern
was
always
integrity.
R
That
said,
I
think
that
the
are
I
think
that
this
proposal,
that
is
made
doesn't
quite
have
the
sufficient
degree
of
control,
so
I've
developed
my
own
proposal
and
applied
for
a
patent
on
it,
because
there
are
two
ways
to
adopt
a
standard.
Why
is
to
go
through
a
process
like
this
and
another
is
to
be
told
what
to
do
by
an
IPR
holder
who
can
get
everybody
to
do
it?
The
same
way.
S
Whichever
way,
the
connection
goes
and
run
all
the
malware
on
this
full
resource
that
at
that
point,
is
only
on
the
middle
box,
but
not
yet
it
on
the
client
without
breaking
the
connection.
So
I
don't
think
anti-malware
can
work
with
passive
inspection
of
TLS.
It
can
only
work
with
an
actual
proxy,
so
I'm
not
really
sure
why
we
in
why
we
need
disk
opposed,
though
that
alters
the
protocol,
only
get
us
passive
in
decryption,
where
I
don't
think.
It's
really
needed
so.
O
We've
looked
at
this
and
there's
use
cases
where
you
need
to
deal
with
it
real
time
immediately
and
there's
also
use
cases
where
the
traffic
is
stored
and
then
looked
at
later.
So
we
tried
to
come
up
with
one
that
accommodated
both
as
opposed
to
coming
up
with
two
solutions
for
each
of
those
environments.
Well,.
S
O
F
O
The
way
I
wrote
it
yes
and
then
I
own
the
the
list.
Last
week,
I
said
you
know
another
way
to
do.
This
would
be
to
pick
the
six
values
I
believe
that
were
necessary
to
decrypt
the
Reserve
Roundtree
of
zero
RTT
data,
the
handshake
data
and
the
payloads
without
giving
access
to
compute
the
PS
KS
for
subsequent
resumption
or
the
exporters.
And
if
the
group
wants
to
do
this,
we
can
have
the
trade-off
discussion
and
pick
whichever
thank
you.
Mm-Hmm.
P
T
Our
net
Scout
a
couple
of
comments:
I'd,
like
everyone,
I'm,
a
big
plus
one
previously
on
the
open,
Internet
I-
think
you
also
have
to
acknowledge
a
lot
of
the
value
of
the
internet
comes
from
the
content
provided
by
data.
Centers
I
know
that
the
vast
majority
of
large
data
center
operators
do
use
packet
flow
analysis,
network
assurance
application,
Shirin
cybersecurity
analysis
doesn't
matter
if
they're,
a
for-profit,
nonprofit
I,
know
from
my
own
dealings
that
minimum
of
85
percent
of
the
fortune
500
do
this
as
fer
for
the
draft.
T
You
know
the
way
I
look
at
it
is,
and
I
followed
this
quite
closely
that
the
authors
of
listen
carefully.
The
concerns
that
were
raised
by
draft
green
I
believe
that
they've
addressed
those.
They
found
a
technical
solution
that,
in
my
mind,
meets
the
requirements
of
both
privacy
on
the
open,
Internet
and
the
requirements
of
data
center
operators.
H
U
The
versus
live,
out-of-band
decryption,
certainly
after
the
fact
of
Krypton,
is
useful
for
troubleshooting,
but
there
are
a
number
of
live,
out-of-band
use
cases
for
decryption
application
performance
monitoring
with
packets,
for
example,
may
look
at
many
tiers
of
an
application,
and
the
packets
need
to
be
decrypted
immediately.
Metadata
is
created
in
the
packet
or
thrown
away.
Of
course,
IDs
customer
experience
monitoring
fraud.
U
Monitoring
is
another,
live
application,
that's
done
in
multiple
locations
and
a
last
example
I'll
mention
that
since
I'm
a
troubleshooter
for
very
large
complicated
applications
with
many
tears,
it
just
takes
too
long
to
take
one
sniffer
and
try
to
chase
around
the
problem
waiting
for
multiple
occurrences.
So
what
you
have
to
do
sometimes
to
be
effective,
is
to
put
traces
at
many
layers
of
an
application
at
once.
You
run
them
through
a
packet
broker
through
a
decryption
appliance
and
into
a
sniffer,
so
that
one
of
the
problem
hits
all
the
data
you
need.
A
O
D
O
D
You
know
this
is
maybe
getting
towards
commentary,
but
would
you
know,
would
you
not
agree
that
we've
you
know
we
have
learned
over
the
last
20
years
that
doing
the
kind
of
analysis
that
we
did.
40
that's
1/3
is
now
if
it's
the
right
thing
to
do
and
absolutely
back
to
an
envelope
kind
of
thing
that
which
disappears
to
me
to
me
now.
D
O
A
W
O
Or
data
center
servers
so
very
often
it
will
be
the
load
balancer
at
the
edge
of
the
data
center.
That
will
be
the
client,
but
we,
after
talking
to
a
bunch
of
different
financial
institutions,
found
that
there
were
some
cases
where
the
client
was
outside
the
data
center
and
therefore
it
could
even
be
a
browser
or
a
point-of-sale
terminal.
Ursula
like
that.
W
Thank
you
because
if
it's
purely
data
center,
then,
as
some
people
suggested,
you
don't
necessarily
need
to
be
using
TLS
and
if
it's
another
browser
clients
and,
hypothetically
speaking,
if
the
people
who
implement
those
browsers
have
expressed
discontent
hypothetically
and
do
not
wish
to
implement
this.
What's
the
point
indeed,.
V
There
are
a
fair
number
of
state
actors
who
might
require
that
particular
operators
share
such
information
within
their
territories
and
that
if
they
were
provided
this
facility,
that
King
material
might
go
to
them
for
later
analysis
and
I
think
that,
as
part
of
the
analysis
of
this
header,
if
it's
accepted
and
you
go
through
what
the
the
process
that
you
and
and
Stephen
just
agreed
would
occur.
If
it
did
that.
That
has
to
be
taken
account
in
the
analysis
and
I.
Think
that's.
V
H
V
A
J
Either
general
con
Gilmore.
Thank
you
for
acknowledging
that
the
goal
of
this
is
not
strictly
within
the
data
center
I
think
that
will
probably
change
some
people's
analysis
of
it.
I
have
a
technical
question
which
is
from
what
I
can
tell
from
the
way
that
the
draft
is
designed.
The
client
opts
into
the
server
sharing
data
with
someone,
that's
correct.
Anyone
well
the
key
manager
of
the
guy
who
GUP
doles
out
those
present
on
the
public
internet.
J
E
Some
pretty
major
concerns
that
could
be
enough
to
to
block
from
a
consensus
standpoint
right
and
what
I'd
like
to
see
is
I
do
think.
The
use
case
is
important.
Is
there
a
way
and
I
have
some
thoughts
and
I'll
throw
them
out,
but
is
there
a
way
this
could
be
constrained
to
the
data
center
usage
now
in
terms
of
the
identities?
I,
don't
know
that
end
user
would
be
able
to
decipher
them.
So
I'm,
not
sure,
that's
a
practical
solution
and
I
think
they
might
find
holes
with
that.
E
If
you're
presented
with
a
list
of
who's
monitoring
so
I'm
not
sure
that
that
would
be
an
adequate
solution.
But
what
if
this
was
server-to-server
within
the
data
center
and
in
the
client
case,
they're
terminating
in
a
load
balancer
or
some
other
function
on
the
edge
of
the
network
and
then
able
to
do
server
to
server
within
the
network?
And
then,
if
there
is
a
user
within
that
enterprise,
that's
connecting
there's
another
load.
Balancer.
Is
this
a
way
that
it
could
be
constrained
that
we
could
get
beyond
the
point
we're
at
in
this
argument?
I?
E
O
E
O
X
The
outside
one
question:
Brian
Witten,
it
sounded
like,
though
you
are
open
to
the
approach
where
the
client
authenticates
the
key
manager,
so
the
client
could
each
at
least
have
some
confident
and
information
about
who
the
key
manager
is
and
who's
facing
subpoena
risks,
and
things
like
that.
It
sounded
like
you're
at
least
open
to
exploring
that
I'd.
O
X
Yet
know
what
those
requirements
would
look
like,
so
that
the
the
related
question
is.
It
seems
to
me
that
a
fair
policy
logic
would
be
for
clients
on
the
open
Internet
that
by
default
not
accept
this
visibility
and
a
related
thing
would
be
maybe
for
employers
when
connecting
to
their
own
domain.
In
that
exceptional
case,
you
know
allow
domain
visibility
that
still
leaves
the
question
of
compulsion.
Could
people
be
compelled
but
related
to
compulsion?
Those
are
risks
that
we
run
today
with
or
without
a
standard
do
I
understand
all
the
credit
is
correct.
A
All
right
guys,
I,
think
I,
guess
at
this
point
we're
trying
to
figure
out
if
we
can
actually
put
the
questions
on
the
slides
and
if
we
can
actually
agree
to
the
questions,
because
I
know
that
people
like
to
edit
them
I've
already
been
told
that
I
missed
a
word
in
the
second
question.
A
A
Y
P
Benkei
duck
and
I
think
Ryan
sort
of
touched
on
this
tangentially
I
just
want
to
confirm
that
everyone
has
a
similar
understanding
with
respect
to
the
compulsion
question,
namely
with
the
client
offering
this
extension
and
server
having
to
echo
it
back.
There
is
the
potential
for
a
entity
that
controls
the
network
path
between
the
client
and
the
server
to
deny
connections
that
do
not
contain
this
extension
as
a
way
of
compelling
the
use
of
this
extension,
and
if
anyone
disagrees
with
that.
As
for
the
technical
reality
of
the
proposal,
please
flail
around
now.
A
Z
Next
Hey
Sharif
Mansour
I
share
my
colleagues
concerned
with
this
draft
that
it
might
increase
the
attack
surface
area,
while
other
approaches
such
as
active
proxying,
might
provide
the
same
kind
of
use
case,
bearing
in
mind
that
it
is
more
expensive.
So
my
question
is
just
how
much
more
costly
is
it
given
the
fact
that
it
can
provide
similar
use
cases
for
the
opt-in
is
by
installing
a
cert
on
the
browser
or
on
the
agent?
Thank
you.
A
AA
A
D
D
E
So
for
the
end-user,
if
there
were
a
capability
on
the
browser
side
or
the
endpoint
to
be
able
to
capture
the
session
logs,
so
that
user
is
knowingly
providing
that
information
to
the
party
who's
doing
the
bugging.
Would
that
meet
that
need?
No
okay,
I
just
wanted
to
ask
the
question
to
make
sure
that
there
weren't
other
mechanisms
that
might
be
more
agreeable
to
the
opposition's
that
we're
hearing
all.
A
Right,
don't
sit
down
Kathleen,
so
we're
gonna
do
two
hums.
The
first
one
is
the
support.
Adoption
and
one
is
to
not
to
oppose
so
the
second
one
like
do
you
support
adoption
of
draft
rhr
DTLS
steals
from
point
three
visibility.
As
the
tails
working
group
item
and
the
next
one
is,
do
you
do
not
do
pose
adoption?
A
AB
E
E
So
from
this
I
I,
don't
think
that
draft
as
is,
is
a
way
forward.
But
if
you
look
at
the
consensus
process,
if
the
objections
were
able
to
be
met
and
there's
some
other
way
to
do
this,
then
perhaps
there
is
a
way
forward.
I,
don't
see
it
with
this
draft
at
the
moment,
just
because
there
are
strong,
serious
technical
objections
and
they
haven't
been
met
and
that's
enough
to
break
the
consensus.
E
But
I
do
see
the
value
in
this.
Personally,
you
know
I,
don't
know
how
you
would
detect
some
of
the
threats
with
the
like
the
u.s.
cert
report.
That
was
just
announced
for
the
utility
industry,
and
so,
unless
there's
other
mechanisms
in
place
to
do
that
type
of
detection,
something
is
needed.
Maybe
it's
not
this,
but
but
I
do
think
something
is
needed
right
now.
A
D
D
A
AC
Squeeze
one
more
in
sure,
Mike
Ackerman.
My
question
is
a
matter
of
logistics,
so
we're
gonna
go
to
the
area
directors.
Most
of
the
issues
that
have
been
identified,
I
think
are
technical.
Are
the
area
directors
sufficient
to
address
those
issues,
or
should
we
start
to
assimilate
a
task
force
I,
don't
think
we're
going
away.
This
is
too
important
to
all
of
us.
That
is
something
you
should.