►
From YouTube: IETF102-TLS-20180716-1330
Description
TLS meeting session at IETF102
2018/07/16 1330
https://datatracker.ietf.org/meeting/102/proceedings/
A
C
C
So
this
is
a
no
well
it's
Monday,
so
you
might
not
have
seen
it
take
your
time.
Basically,
the
gist
of
it
is
that
you
say
anything
at
the
microphone.
You're
gonna
be
recorded,
you're
being
recorded.
Now,
if
you
have
an
IPR
disclosure,
you
need
to
disclose
it.
That's
one
of
the
reasons
why,
when
we
talk
about
pretty
much
everything
on
this
agenda,
it
all
has
a
draft
so
that
you
have
to
go
through
the
process
of
clicking
the
buttons
to
make
sure
you
understand
the
Apgar
rules
figure
out
that
requests.
C
Luckily,
we
have
already
have
a
minute
taker.
We
have
a
jabber
scribe.
The
blue
sheets
are
currently
going
around.
Please
state
your
name
at
the
mic
and
let's
keep
it
professional
at
the
mic
as
well.
I'll
just
get
this
right,
so
this
is
our
administrivia
for
our
agenda
bashing
time
we
have
two
sessions
today.
Monday
is
what
we
have
here.
We
moved
a
couple
of
things
around
based
on
an
early
agenda
bash
from
Victor.
C
If
you
want
some
extra
time
else
and
we
have
more
on
Thursday
originally,
we
also
had
a
cryptid
ESI
to
dip
or
encrypted
SMI.
Today,
but
we
decided
to
move
it
because
it's
gonna
be
a
long
and
lengthy
discussion
and
we
thought
it
would
ask
the
kind
of
time
doubt
it
at
the
end
there.
C
So
next
the
document
stats,
we
have
two
documents
in
all
48
right
now
on
the
TLS
1.3
draft
is
going
through
the
the
process
of
getting
the
updates
done
and
hopefully
we'll
get
that
done
fairly
soon
and
obviously
the
ECC
for
Cyprus
sweets
for
Till's,
from
which
earlier
is
also
going
through.
We
have
three
other
documents
that
have
been
approved
by
the
ISD
and
they're
kind
of
waiting
through
the
cycle.
Another
draft
that
we'll
be
talking
about
later
today
is
the
dane
record
for
Dena
cycle
dedication,
Jain
extension
for
TLS.
C
We
have
an
ITF
last
call
going
now
for
the
example,
handshake
traces
and
exported
authenticators.
We're
also
going
to
talk
about
today,
which
is
gone
through
working
with
Les
Paul.
We're
trying
to
make
sure
we
have
all
of
the
outstanding
comets
addressed
and
I
know
that
Christian
Whitman
isn't
here,
but
basically
the
issues
and
requirements
for
SMI
encryption
and
TLS.
The
strap
was
split.
So
last
time
there
was,
there
was
solutions
and
as
well
as
requirements,
we
decided
to
split
the
last
time
and
the
actual
issues
and
requirements
trap
is
ready
to
go.
C
C
We
can't
we
can
move
it
or
he
wants
it
back.
So
he
said
that
in
the
image
out-
okay,
great
so
will
will
we
can.
We
can
bash
that
so
that
essentially
we're
gonna
do
export
it
authenticators.
First
then
we'll
do
the
dns
chain
extension
stuff
and
then
we'll
talk
about
to
tell
us
the
press
so
for
those,
why
we're
doing
it?
This
way
is
because
these
straps
are
working.
Your
blasts
call
don't
want
to
make
sure
your
predatory
said
first
to
make
sure
we
get
to
the
issues
all
right.
D
Okay,
so
in
April,
so
this
is
just
you
know
some
some
numbers
to
impress
in
April
we
turned
on
the
public
beta
for
TLS,
one
three,
and
we
told
you
know
all
of
our
customers.
If
you
want
to
do
it,
you
know
go
to
the
UI
and
make
these
portal
changes.
You
know
config
changes,
because
this
was
like
the
first
time
where
our
life
cycles
synced
up
with
the
browser's
life
cycle
in
terms
of
the
drafts
I,
did
a
snapshot
every
5
days
and
by
you
know.
D
D
The
other
interesting
thing
about
the
chart
is
the
dips
or
the
weekend,
which
means
people
are
using
this,
whether
they
know
we're
not
in
production
for
real
world
real
world
work,
it's
been
kind
of
stable,
so
a
couple
of
people
have
come
in
and
out
of
the
beta
and
I
think
Firefox
is
now
drafting
compatible
with
us,
but
in
terms
of
traffic.
This
is
like
you
know,
1
or
2
percent,
but
that's
not
bad.
Considering
that
it's
as
I
said,
zero
percent
of
our
customers
can't
give
you
any
more
numbers
than
that.
D
Sorry,
the
most
other
interesting
thing
for
us
is
that
nobody
reported
any
incidents
and
in
fact
we
went
back
to
our
support
team,
since
it
really
nobody's
complained
it
all
just
works
and
well
nobody's
complained.
So
anyhow,
I
just
wanted
the
show
we're
now
averaging
about
700
million
connections
that
handshakes
a
day
with
TLS
130,
which
is
pretty
neat
part
me
talk.
E
E
We
deployed
TLS
1.3
of
various
draft
versions
starting
a
year
and
half
ago,
it's
now
up
to
in
terms
of
number
of
percentage
of
requests
served
by
CloudFlare
5%,
so
5%
of
requests
are
TOS
1.3
and
it's
enabled
by
default
for
all
customers
who
didn't
explicitly
disable
it,
and
so
I
can't
give
you
know
apples,
apples,
number
of
connections
per
second,
but
it's
it's
a
pretty
decent
percentage.
Nick
are
you?
Are
you
23
and
28
28,
only
that's
actually
no
23
and
28
right
now.
E
These
are
magnitude
estimates.
Basically,
you
know
our
client
sent
back
telemetry
and
you
know
you
have
to
like
filter
out
or
has
an
outlier
problems,
because
if
you
don't
you
get
people
recording
like
8
million
connections
a
day
and
like
they're
like
prism,
we
lying.
So
this
is
a
one
person
sample
a
lot
of
our
clients
and
then
the
phonology
is
I.
Take
I.
E
Take
clients
have
Bucknam
by
I,
pluck
it
on
my
client,
ID
and
then
I
treat
them
is
like
that,
because
your
fraction
per
client
of
1/3
and
then
you
average
all
that
fractions.
You
normalize
my
client
and
so
anyway.
This
shows
a
sexually
no
1
1
on
the
presentation
in
preparation
for
students,
presentation
not
much
100
and
we're
you
know
we'll
in
the
3%
1/3
on
this
is
release.
Beta
shows
more
like
5
to
7
percent.
E
Don't
know
why
I
wouldn't
trust
a
I,
wouldn't
trust
these
numbers
to
within
0.3,
so
I
wouldn't
trust
these
numbers
to
within
more
than
a
factor
of
2
or
so,
but
obviously
we're
getting
quite
a
bit.
I'm
a
CEO
honestly
I'm
surprised,
Nicola
seems
so
little
given
the
Chrome
and
Firefox
are
both
1/3
by
the
fault
and
surprise
you're,
not
seeing
more.
But
we
need
to
break
that
later.
F
Hi,
so
is
it
time
to
deprecated,
TLS,
1.0
and
1.1
and
we're
trying
to
get
the
bottom
of
that
and
thank
you
to
everyone
for
providing
statistics
on
the
list
and
information
on
problems
that
you
foresee.
So
this
is
short
because
we'd
like
it
mostly
to
be
discussion,
go
ahead.
Please
all
right!
So,
oh
good,
it's
right
here,
so
we
do
want
meaningful
statistics
across
different
applications.
We've
gotten
some
that
are
non
HTTP,
the
Apple
ones
posted
yesterday
or
today
thank
you
included,
non-http.
So
that's
helpful.
F
Examples
of
systems
or
applications
for
which
no
upgrade
path
is
available,
is
of
interest
and,
if
they're
showstoppers.
So
are
they
systems
that
if
a
major
vulnerability
was
announced
and
your
configuration
possibilities
didn't
cover
it,
would
there
be
a
big
issue
or
could
the
system
be
isolated
or
even
just
saying
what
this
is?
Maybe
the
vendor
will
step
up
right
so
putting
it
out
there
and
that
pretty
much
covers
that
next
section:
okay,
and
are
there
other
considerations
we
should
be
thinking
about.
F
So
you
know
I'm
thinking,
statistics
showstoppers
to
help
us
figure
out
timelines
and
of
course,
if
it's
adopted
right
away,
it
doesn't
mean
it's
gonna,
be
published
right
away
and
then,
even
when
it's
published,
we've
had
several
vendors
say:
they're
gonna
continue
to
sport.
This,
in
their
next
release,
like
Richard,
said
that
for
OpenSSL
they're
going
to
be
putting
out
the
next
version,
so
for
the
next
five
years,
both
of
these
versions
will
be
supported
and
OpenSSL.
G
Jeff
Hodges
PayPal,
something
we
noticed
in
our
PCI
mandated
upgrade
here
over
the
last
couple
of
years-
is
that
in
the
case
where
you,
where
somebody
doesn't
operate,
also
operate
the
client
side?
Okay,
it's
like
they're
out
there
on
their
own
you're,
offering
service
over
the
net
from
your
server.
There's
no
way
to
tell
when
you
upgrade
what
happens
other
than
warn.
G
Just
have
mini
flag
days
and
and
try
to
roll
it
through
your
customer
base
and
also
you
may
not
catch
everybody
because
they
may
make
changes
in
in-between
the
windows
where
you're
trying
to
do
your
testing
and
such
so
gee
we'd
like
to
put
our
heads
together
with
various
interested
parties.
You
know
self-nominated
and
you
know
brainstorm,
there's
any
something
we
can
do
in
this
context.
Itf.
G
I
Yes,
I'm
on
Thompson
I
think
the
the
ultimate
answer
here
is
going
to
depend
a
bit
on
the
deployment
context
in
which
we're
talking
about
for
the
web,
at
least
we're
starting.
These
discussions
now
we're
seeing,
as
you
saw
on
on-air
Co
slide
there
on
usage
rates,
we're
now
getting
pretty
close
to
the
point
where
we
can
probably
start
turning
off.
Tell
us
100
in
web
browsers,
at
least
maybe
not
straightaway
but
Layton
in
eighteen
year.
I
Eighteen
months
time,
I
think
it's
perfectly
reasonable
to
expect
that
to
sort
of
quietly
go
away
and
you're
actually
seeing
sites
now
just
deploying
one
too,
and
that's
something
that
sites
can
do
already
and
that's
not
a
big
problem
for
them,
because
browsers
tend
to
be
evergreen
and
they
all
have
tell
us
one
to
enable.
Then
there's
not
really
a
whole
lot
of
point
in
trying
to
talk
to
someone.
Who's
only
got
till
s1
o
because
they
also
probably
have
a
bunch
of
other
problems
at
the
same
time,
and
so.
J
I
But
the
discussion
Lisp
was
pretty
clear
that
there's
a
large
population
of
use
of
TLS
100
in
other
contexts,
and
it's
going
to
be
a
lot
more
difficult
for
those
contexts
to
do,
and
so
I
don't
think
it's
a
problem
for
us
publishing
a
document.
I
would
be
perfectly
happy
having
this
document
published
tomorrow.
F
Well
because
so
I
agree,
because
vendors
will
continue
to
support
it
until
their
customers
are
off,
but
this
is
a
way
to
help
get
customers
off
these
older
versions.
So
you
could
reduce
your
footprint
of
code
and
we
have
that
too
right.
We,
where
I
work
at
Dell
EMC
its
largest
IT
company
right.
We
still
have
some
customers
on
1.0,
even
though
our
official
stance
is
that
it's
been
deprecated,
I
think.
I
It's
important
for
the
IDF
to
send
a
signal,
yeah
and
publishing.
This
now
is
a
pretty
effective
way
of
doing
that,
so
I'd
be
sort
of
on
board
with
doing
a
little
bit
more
of
the
groundwork
to
be
talking
about,
but
then
just
publishing
this
when
we're
ready
to
publish
it,
which
hopefully
is
soon
right.
K
Bingo
Franken
Bank
of
America,
so
I
guess
my
point
is
similar
to
Martin's
in
that
I.
Don't
think
we
need
to
consider
use
of
statistics
at
all
in
this
decision,
because,
even
if
it
no
matter
how
many
users
it
has
our
putting
our
putting
out
a
standard
track
document
entitled
die,
die
die,
does
not
actually
RM
all
those
implementations
and
make
them
die
die
die.
Nothing
actually
breaks.
K
E
Sprott
thanks
for
publishing
this
I
think
it's
read
idea:
I
was
gonna,
get
up
in
the
system
with
Daniel
said,
which
is
that
you
know
we're
telling
people
as
the
IETF
no
longer
thinks
easier
or
safer
to
calls,
and
we
should
be
and
that's
the
principle
why
we
did
one
too
so
I,
don't
think
it's
a
problem
to
say
like
we
understand
you
have
reasons
why
it's
our
freedom
away
from
them,
but
we
advise
you
to
do
so.
It's
positioning
so
I
mean.
F
L
Jordan,
thanks
for
publishing
this
I
think
it's
a
great
idea.
I
agree
with
accurate
and
Martin
I
do
think.
The
fundamental
problem
is
not
whether
or
not
we
published
this,
and
we
come
out
with
a
public
stance
saying
the
IETF
thinks
these
two
go
away
because
they
should
have
come
away
a
long
time
ago.
L
It's
the
fact
that
most
people
to
implement
TLS
don't
have
a
clue
as
what
they're
doing
and
they
go
out
and
they
search
google
and
they
find
something,
and
they
just
say:
oh,
this
is
what
will
make
it
work
and
they
just
copy
and
paste
that
in
and
boom
it
it.
That's
all
that
goes
so.
So
that's
our
fundamental
problem
with
a
lot
of
this,
but
I
thanks
for
publishing
it
I
do
think
it's
a
great
idea.
Yeah.
F
M
M
M
There
are
multiple
audiences
for
documents
like
this
and,
if
we're
careful,
we
can
make
sure
that
the
document
is
useful
to
all
of
them
and
when
I
think
about
different
audiences
I'm
thinking
about
both
implementers
and
deployments,
and
if
the
document
actually
provides
clear
advice
for
implementers
such
as
given
the
state
of
the
network.
Today,
you
may
not
be
able
to
remove
this
entirely,
but
we
recommend
that
you
do
the
following
things
right.
So,
like
cipher
su
prioritization,
you
know
version
prioritization
warnings,
logs
warnings
out
to
the
other
end
party
that
we
can.
M
N
An
overall
aggregate
number
are
a
little
bit
misleading
I
was
digging
into
some
on
someone's
I,
have
access
to
and
we're
seeing
that
it
was
that
that
it
ends
up
being
very
you
have
a
distribution
of
different
use
cases.
You
have
some
use
cases
where
people
have
happily
turned
off
everything
other
than
below
TLS
one
two
and
things
just
work,
fine
for
significant
fractions
of
customer
sites.
N
Then
you
have
other
cases
at
the
other
end
of
the
spectrum
where,
where
you
have
significant
numbers
of
sites
where,
where
80%
of
the
traffic
is
still
using
old
versions
of
TLS,
often
times
because
they
have
custom,
they
have
custom,
client,
software
and
we'll
just
so.
We'll
just
need
to
be
be
a
little
cognizant
about
not
wanting
to
force.
Everyone
just
cuts
all
the
plugs
off
on
the
pull.
The
rug
under
some
of
these
custom
implementations
that,
where
their
use
cases
with
100
might
action
might
be
better
off
than
the
alternatives.
H
Nene
Elkins
and
enterprise
data
center
operators,
yeah
I,
actually
find
myself
in
in
in
with
the
number
of
things
that
have
been
said,
I
think
Jeff's
idea
of
how
do
we
reach
out
and
educate
people
to
do
this,
and
also
what
our
friend
from
the
ACLU
said
about
I
find
myself
in
a
grito
Legree,
surprisingly,
ISM
yeah.
We
need
to
have
guidance
for
implementers,
but
it's
it's
a
tricky
problem.
H
People
really
are
trying
it's
not
so
easy,
that's
as
I
say
so,
so
any
help
and
it's
the
client
software
at
these
hands,
and
so
maybe
reaching
out
to
those
vendors.
You
know
I
mean
I'm,
just
throwing
people.
You
know
that
that
there's
a
ton
of
these
guys
out
there
and-
and
so
that
might
be
it's
just,
but
it's
a
somewhat
smaller
subset,
so
so
some
kind
of
reach
out
and
I'd
be
totally
up
for
up
for
a
you
know
a
word,
a
group
that
got
together
and
thought
about
some
of
these
things.
Yeah.
G
C
Alright,
so
I'm
gonna
do
it
can
I
have
a
show
of
hands
who's,
actually
read
this
draft
Wow,
so
fair
amount.
My
plan
is
that
we're
probably
gonna
run
a
working
group.
Adoption
later
I
should
note
I
tried
to
do
this.
Five
years
ago,
I
got
my
head
handed
to
me
by
the
working
group,
so
I'm
glad
I
can
put
it
back
on.
C
The
second
thing
is
we
had
this
working
group
called
Utah
in
the
art
area
right
and
they
years
ago,
when,
like
2013
was
when
this
work
started
and
I
guess
in
2016
or
something
they
finally
put
out
a
draft
that
said
hey,
you
should
be
doing
1.2,
so
this
is
not
new.
This
is
something
that
we
should
just
be
doing.
So
that's
it
so,
alright,
guys
great
next.
C
D
E
This
was
adopted
last
year
and
the
latest
update
to
the
draft
was
earlier.
This
week
last
I
80
F.
There
was
a
formal
proof
of
security
presented
and
a
paper
published
by
Jonathan
appointment,
all
right
so
between
the
last
IETF
and
now
this
went
through
a
last
call,
and
there
were
several
comments.
The
main
request,
or
the
made
change
that
was
requested
during
the
last
call,
was
the
idea
of
an
empty
Authenticator.
E
As
the
draft
was
written
before,
every
exported
Authenticator
was
tied
to
a
certificate
in
a
certificate
chain
and
there
was
a
need
for
a
server
to
do
a
explicit
refusal
for
a
given
Authenticator
request,
and
so
this
was
added
to
the
draft
in
response
to
these
comments.
Next
slide,
please,
alright!
So
in
any
case,
that's
that's
sort
of
where
we
stand
right
now.
There
has
been
a
lot
of
traffic
on
the
the
mailing
list
about
this,
but
there
has
been
some
discussion
and
I
propose.
O
E
P
P
Mike
Bishop
Akamai
and
offer
on
the
secondary
search
draft.
We
already
have
the
requirement
that
the
context
be
unique
within
the
connection,
so
adding
that
at
the
TLS
layer
would
be
fine.
Now
we
do
need
to
be
able
to
generate
multiple
Authenticator
for
the
same
certificate.
Potentially
I
presume.
That's
not
all
it.
O
No,
no,
not
as
if
you
were
to
send
a
spontaneous
one,
not
in
response
to
requests
so
for
some
reason
you
sent
in
the
a
and
then
you
recreated
and
sent
the
exact
same
ei
later
in
the
connection
that's
complicated
to
prove
I
mean
you
can
prove
it,
but
it's
just
so
requiring
it
to
be
unique
in
the
context
concept.
Con
would
make.
O
Q
Q
R
C
So
will
you
be
able
to
spin
another
version
of
that
to
include
the
the
guy
thinking
Jonathan
just
asked
for
yes
great
and
the
quicker
you
do
that
then
the
quicker
we
can
hit
the
button.
Okay.
Thank
you.
S
Okay,
sure
okay
go
next
like
so.
This
is
a
summary
of
what's
happened
in
like
a
hundred
email
messages
on
the
list,
so
just
to
quickly
summarize
for
people
who
skipped
all
that
there's
a
dainty
last
record
that
tells
you
what
public
key
to
use,
what
certificate
to
use
or
what
CA
to
use
you
can
put
it
in
DNS
can
be
protected
by
DNS
SEC
and
it's
either
in
the
DNS
or
not.
S
So
if
you
publish
this
in
a
DNS,
then
it's
live,
and
if
it's,
if
your
key
in
the
server
does
not
match
it,
TLS,
that's
like
a
permanent
error.
Okay
next
slide.
So
there
are
some
obstacles
using
TLS,
a
records
and
browsers
they'll.
Add
the
added
latency
for
additional
round
trips,
the
network
part
not
being
always
clean
and
things
being
stripped
or
manipulated.
So
there
was
a
need
to
put
this
inside
the
TLS
handshake,
so
next
slide
so
there's.
S
Basically,
this
is
a
TLS,
a
stapling,
so
you
get
a
record
from
DNS
you
staple
into
the
TLS
handshake,
and
then
everybody
is
happy
to
be
able
to
get
that
information
to
you
stain
to
varalu
to
verify
the
certificate
so
just
to
be
clear,
there's
no
pinning
of
DNS
data
involved.
It
is
basically
a
live
snapshot
of
the
DNS
data,
so
the
TLS
surf
is
expected
to
regenerate
this
blob
that
it's
sending
in
the
extension,
whatever
15
minutes
every
one
hour.
S
So
what
is
the
problem?
If
the
extension
is
not
paint?
You
cannot
detect
whether
or
not
you're
under
attack
or
whether
you're
just
hitting
a
server
that
doesn't
support
the
extension
or
whether
the
administrator
turned
off
the
extension.
So
the
problem
is:
if
you
really
want
to
do
Dane,
and
you
want
to
increase
the
deployment
of
it
in
the
various
protocols,
then
you
need
to
have
a
way
of
pinning
the
extension.
S
So
so,
when
this
was
found
out,
were
various
suggestions
of
changing
the
scope
of
the
document,
which
we
believe
is
the
wrong
approach.
I
think
that
we
should
actually
cover
this
disused
days.
So
can
we
get
you
to
hold
your
comments
to
the
in
Richard,
so
we
can
just
get
through
the
slides,
real,
quick
and.
S
So
next
page,
so
basically,
these
are
the
options
that
have
been
discussed
in
the
working
group.
One
is
do
nothing
to
fix
everything
in
a
new
TLS
extension
that
obsoletes
this
one
three
to
zero
bytes
in
this
RFC
meaning
do
not
do
any
pinning
and
in
the
future
we
can
do
pinning
of
the
extension
again
not
pinning
of
the
data.
But
pending
of
the
extension,
some
people
thought
that
I
was
a
bit
too
ambitious
and
maybe
we
need
to
think
about
it's
a
little
bit
longer.
S
S
This
is
the
same
saying:
let's
just
do
one
new
extension
from
scratch,
but
then
you're
basically
deferred
throwing
all
of
this
document
that
we're
currently
working
on
a
way
replacing
it
with
the
exact
same
document
except
then
you
add
the
two
bytes
or
whatever
the
solution,
so
you
come
up
with
so
so
it's
not
a
very
good
solution.
So
a
next
slide.
So
we
can
specify
two
zero
bytes
now,
which
basically
mean
don't
ever
pin
this
extension.
So
people
can
experiment
with
it.
They
can
enable
it
on
a
server.
S
It
doesn't
give
any
commitment
to
the
future
of
it
being
there
and
later
on.
We
can
specify
what
non
zero
byte
means
and
then
both
service
and
clients
can
implement
the
non
zero
versions,
which
we
think
would
be
enough
to
do.
Any
kind
of
extension
pinning,
but
not
everybody,
agree
to
that.
That
would
be
enough
and
they
were
a
little
bit
nervous
about
it.
So
next
slide.
S
So
this
is
why
do
we
think
the
two
bytes
are
going
to
be
enough,
because
the
dns
already
has
a
TTL
and
an
hour
SiC
value
that
specifies
lifetimes
and
protects
against
replay
attacks
and
so
anything
less
than
one
hour.
Ttl
doesn't
really
make
any
sense,
because,
especially
if
you
look
at
Dee's
records
at
the
parents,
they're
not
gonna
expire
within
the
hour.
So
there's
no
granularity
that
you
really
have
within
the
hour
and
there's
really
no
way
of
of
needing
more
than
seven
and
a
half
years
of
extension.
S
Pinning
so
two
bytes
ought
to
really
be
enough
for
every
scenario
we
can
come
up
with
so
next,
but
as
a
compromise
proposal
for
those
who
were
too
nervous
that
two
bytes
were
not
enough
and
those
who
were
nervous
that
we
couldn't
really
specify
the
two
bytes.
The
proposal
from
Ben
knows
to
do
variable
lengths
where
we
put
in
a
reserved
field
so
that
they're
committing
to
fixing
the
extension
pinning
in
the
future.
But
then
we
have
a
little
more
leeway.
S
We
could
do
something
a
little
more
complicated
than
selling
two
bytes
next
and
then
Acker
came
up
with
another
idea
of
a
whole
new
extension
block
set
to
zero
first
and
fill
it
in
later.
It
is
sort
of
the
same,
that's
the
same
issues
as
doing
a
new
TLS
extension,
because
this
is
sort
of
just
a
sub
extension
inside
this
extension.
So
it
has
the
same
two
things:
spinning
each
other
kind
of
complexity.
So
now
the
next
slide.
S
T
T
T
Know
when
you're
using
Dane
in
that
flavor,
even
if
you
are
under
attack,
if
you
are
under
attack
in
that
scenario,
it's
a
downgrade
attack
against
TLS.
As
typically
you
know,
standard
protections
against
stripping
things
out
of
TLS
handshake
messages
apply
and
they
can't
remove
the
surgeon
to
get
in,
replace
it
with
a
new
one
like
I'm.
T
I
T
U
There's
question
of
the
attack:
you
know
somebody
got
a
fraudulent
PKK's
certificate
and
you
maybe
they
also
can
redirect
your
DNS
traffic
goes
to
them.
So
it's
question
like
what
attacker
capabilities
do
you
have
in
terms
of
just
testing
with
bits
on
the
wire
and
stripping
extensions
out
or
actually,
your
being
the
real
other
endpoint?
That's
the.
S
Tells
the
server
and
self
do
something
different.
It's
only.
The
authentication
of
the
Dame
part
is
all
via
the
DNS
SEC
information
and
nothing
of
the
PQR
information.
So
all
of
that
is
it's
going
to
be
either
there
or
not
there
and
you're
saying
that
if
it
is
there
and
it's
not
mangled
with,
then
you
can
use
it,
and
yes
I
agree
to
that.
But
that's
not
the
problem
case
I'm
worried
about
right,
but
but.
T
S
Sir
there's
a
look:
there's
this
a
use
case
for
all
of
those
clients
that
currently
do
not
support
wipe
a
key
I
could
still
go
running
with
that
which
is
currently
none
right.
So
the
use
case
is
really
small
and
if
we
want
to
grow
this
Dane
usage
and
obviously
data
tooth
have
to
live
together
for
a
while
right.
So
so
your
use
case
is
a
use
case
where
this
is
the
theoretical
use
case,
and
it's
not
a
real
life
use
gates.
I
mean
okay,.
T
C
E
E
Than
tastic
right
so
during
the
I
mean
I'm
published
repeating
myself,
but
during
the
last
meeting
on
this
topic
was
raised
mind
there
was
a
fair
amount
of
concern
about
any
kind
of
pinning
of
this
and
I
appreciate
that
you
and
Victor
and
Nick
Nico
believe
this
is
the
same
as
H
P
KP,
but
I
remain
concerned.
S
S
So
I
understand
of
that
your
view,
but
I'm
also
a
little
bit
sad,
that
in
in
four
or
five
months
of
time,
you
have
not
come
up
with
anything
more
concrete
and
say
like
it
feels
like
this
other
pinnings
of
data
and
not
extension,
and
it
feels
that
I'm
a
little
nervous,
but
I
haven't
really
managed
to
substantiate
the
claims
of
whites.
Actually
problem,
like
I
haven't
seen
you
come
up
with
the
use
case,
where
it's
actually
problem
that
you
do
this
pinning
well.
M
This
is
dkg
I
think
this
draft
has
value,
as
it
is
I
understand
that
it
doesn't
do
all
the
things
that
you
want
to
do,
but
I
would
really
like
to
try
to
get
something
like
this
working,
because
there
are
potential
clients
that
don't
use
the
web
to
PKI.
That
could
use
it
and
so
by
by
blocking
the
conclusion
of
this
on
allowing
pinning
what
we're
doing
is
we're
defeating
those
clients
that
could
otherwise
of
this.
So.
S
M
M
Maybe
we
shouldn't
be
encouraging
people
to
do
that
kind
of
stuff,
but
that's
why
this
looks
a
lot
like
HP
KP
I'm,
a
fan
of
each
HP,
KP
and
I'm,
sad
that
it
went
away,
but
I
can
understand
why
people
who
were
nervous
about
HP
KP
are
also
nervous
about
this,
because
it's
not
about
a
foot
gun
that
kills
other
certificates.
It's
a
foot
gun
that
kills
the
entire
weapon.
S
But
but
again,
just
just
to
clarify
we're
asking
for
one
or
two
bites
set
to
zero.
That
just
basically
ensures
that
we
will
solve
this
problem
in
the
future
and
that
people
are
not
going
to
come
here
next,
the
next
IETF
and
say
we
will
never
do
any
kind
of
extension
whatsoever.
The
drafters
did
it's
an
RFC,
you
don't
go
home,
because
that
is
what.
M
I'm
afraid
of
I'm
afraid
of
joints
that
we
think
we
won't,
we
that
we
think
we
will
exercise
that
we
don't
know
what
they
mean
and
adding
extension
capabilities
into
stuff
extension
capabilities
are.
We
know
that
they
that
the
extra
complexity
is
really
hard
to
get
right
and
I
would
prefer
a
simpler
draft,
because
I
want
to
see
this
thing
published.
Yes,.
S
But
but
but
again
the
dangers
that
four
months
from
now
we're
sitting
here
with
the
exact
same
draft
called
this
with
the
exactly
same
explanation
to
falsify.
We
think
the
two
bytes
are
enough
and
all
of
you
saying
we
haven't
looked
into
it
and
we're
sort
of
concerned.
That
looks
like
this
other
thing
and
we
can't
really
decide.
Then
you
cannot
move
forward.
So
if
you
can
give
me
some
way
where
we
can
guarantee
to
move
forward,
that
would
make
me
happier.
J
U
Hat
on
so
I
think
it's
probably
useful
to
remind
ourselves
here
that
sort
of
the
core
issue
is
that
we
have
our
existing
pica-x
trucking
trust
anchors,
and
we
have
our
DNS
trust
anchors
and
you
know,
there's
lots
of
different
ways
in
which
you
could
use
one
or
the
other
try
to
combine
them
answer.
The
problematic
case
here,
which
we
sort
of
have
to
acknowledge
as
being
a
significant
case,
is
the
incremental
deployment
case.
U
Where
are
you
currently
trusting
PKK's
and
you
want
to
add
on
deigned
in
a
sec
in
some
form
you're,
whether
that's
to
replace
it
or
supplement
it?
You
know
just
really
matter,
and
the
key
point
is
that,
because
you
have
these
different
trust
anchors,
you
cannot
rely
on
the
pica-x
trust
anchor
to
tell
you
anything
about
the
status
of
the
DNS
trust
ink
and
that
sort
of
the
key
problem.
We
really
don't
know
how
to
solve
this
and
you
talk
about.
U
So
the
question
that
we
have
is
well:
what
do
we
do?
How
do
we
go
forward
and
you
know
there's
several
things
that
you
most
of
us
did
I
mean
we
could
publish
this
document
as
is
and
replace
it
entirely
in
four
months
with
either
something
that
you
know
supplements
the
behavior
of
this
extension
or
it
could
just
wholesale.
Do
AB
is
you're
allocating
new
code
point
and
I.
Think
that's
fine.
U
If
we
do
that,
and
then
sort
of
the
other
option
is
to
leave
a
hole
that
we
will
fill
in
later
and
if
I
take
off
my
ad
out,
I
really
share
dicus
G's
concerns
that
you
know
if
we
leave
a
hole
that
we
think
we
know
how
we're
gonna
fill
like.
We
don't
have
anybody
just
applying
this?
It's
if
we
look
at
other
pending
sorts
of
schemes.
U
J
W
Of
there
is
no
certainty,
it
all
didn't
quite
explain.
The
story
is
that
if
you're
a
server
in
a
web
PKI
world
and
your
clients
are
mostly
doing
web
PKI-
and
you
say
you
know
what
I'm
going
to
you
know
not
have
a
web
pick
a
certificate,
I'm
gonna,
detain,
you're,
not
gonna,
get
too
many
clients,
you're
gonna
fail
nobody's
gonna,
do
that
the
restrictive
use
case
doesn't
work
because
of
stripping,
and
they
sort
of
use
case
is
unreliable.
W
So
the
only
applications
that
work
for
the
draft
as
originally
written
are
those
that
mandate,
the
extensions
and,
furthermore,
as
originally
written
only
with
servers
that
have
TLS
a
records
and
have
DNS
SEC
I
must
remind
you
that
we,
after
that,
the
draft
was
pulled.
We
managed
to
get
some
consensus
around
denial
of
existence
which
substantially
broadens
the
scope
of
the
draft
by
allowing
servers
that
implement
the
extension
to
deliver
the
bad
news
that
they
don't
have
gain
or
don't
have
DNS
SEC
and
thereby
the
Greenfield
clients
that
mandate.
W
The
extension
can
interoperate
with
not
just
servers
that
you
know
do
all
three
things,
but
can
also
interoperate
with
servers
that
aren't
ready
for
Dane
or
DNS
SEC
yet,
but
can
deliver
the
extension.
So
we
now
have
a
much
broader
scope,
but
we're
still
scoped
only
two
servers
and
clients
that
mandate,
the
damn
thing
and
we'd
like
to
be
able
to
deploy
it
incrementally
and
deploying
it
incrementally
means
that
there
has
to
be
some
value
from
such
incremental
deployment
and
the
value
goes
away.
W
W
The
extension
itself-
sorry
Allah
strike
it's
4:00
a.m.
apologies,
so
so
dkg
rightly
concerned
about.
We
don't
know
how
this
will
play
out.
I
did
not
hear
any
similar
objections
for
MTA
STS.
Lots
of
people
are
very
excited
about
MTA
fps.
The
draft
is
getting
published
it
pins,
a
mechanism,
it
doesn't
pin
data.
In
fact
it
pins
a
little
bit
more
data
than
this.
Does
it
pins
the
MX
records
needlessly
copying
them?
You
know
arguably
needlessly
copying
them
from
DNS
into
the
the
policy.
That's
that's
pinned
by
by
MTA
SPS.
Here,
there's
no
such
need.
W
We're
just
pinning
a
capability
to
deliver
the
extension
no
data
gets
pinned.
This
is
simple.
As
an
MTA
STS,
it's
simpler
than
STS
for
HTTP
I
know
we
haven't
had
the
details
of
that
debate,
but
I
can
assure
you
there.
This
is
this
is
STS
de
minimis
and
if
you
support
any
other
kind
of
STS
and
didn't
make
a
fuss
about
it,
I
see
no
reason
why
there
would
be
fuss
about
this.
W
A
W
M
My
concern
Victor,
this
is
dkg.
My
concern
was
not
about
what
is
being
pinned.
My
concern
was
about
who
is
doing
the
pinning
and
him
the
proposal
that
we
have
here
the
entity
doing
the
pinning
is
the
TLS
end
point
itself
in
MTA
STS,
the
operator
doing
the
pinning
is
a
controller
of
the
zone,
the
DNS
zone
and
the
operator
of
the
HTTP
endpoint
right.
It's
not
that
the
MTA
itself
saying
I'm,
gonna
pin
start
TLS.
Y
H
Y
Mean
there's
no,
you
know,
there's
no
silver
bullet
for
we're
trying
to
do
here.
We
I
mean
we
in
a
very
general
sense,
for
example,
if
if
we
were
all
trying
to
move
away
from
the
web
PKI
to
the
DNS
sack
over
time
right,
you
know
eventually,
we'd
want
to
have
a
permanent
pin
for
everybody,
but
that's
not
what
we
Victor
Paul
and
I
are
really
trying
to
do
we're,
not
trying
to
say
that
everybody
must
be
on
the
NSX
only
and
that
web
PKI
or
anything
like
that.
Y
The
second
thing
I
wanted
to
say
was
that
you
know
again
the
thing
about
pinning
this
is
really
just
pinning
the
extension
I
think
this
is
completely
different
from
all
the
other
pinnings,
except
as
Victor
just
pointed
out.
The
fact
that
the
user,
agent
or
whatever
client
would
be
doing
pinning
of
the
extension
isn't
very
interesting,
I,
don't
think
right,
because
it's
the
same
thing
in
SMTP
or
or
whatever
someone
has
to
do
the
pinning
on
the
client
side,
and
it's
just
about
the
extension
being
present.
You
can
start
out
without
DNS
SEC.
Y
You
can
start
out.
You
can
add
the
NS
SEC
you
can
then
add,
then
you
can
then
remove
these
things,
and
as
long
as
you
have
the
extension
there,
it
just
works
right.
It
does
create
a
problem.
If
you
want
to
be
able
to
to,
you
know,
go
back
to
an
earlier
version
of
your
server
that
doesn't
implement
the
extension
or
whatever,
but
I
mean
I.
Don't
think!
Y
The
last
thing
I
want
to
say
about
the
two
bytes
is
that
you
know
it's
speculative
in
one
sense,
but
it
isn't
really
speculative.
We
know
what
we
would
put
there
right
and
we
know
that
we're
going
to
write
that
draft,
and
you
know
unless
world
you
know,
unless
there
are
people
who
are
opposed
to
the
idea
of
pinning
under
any
circumstance,
as
opposed
to
yeah
like
are
you
guys
opposed
to
having
the
pinning
at
all
ever
or
or
what?
Z
Thanks
guys,
we're
gonna
have
to
get
everybody
to
be
concise.
Err
thanks,
Wes,
we'll
try
thanks
Wes
heard
acharya
say
a
couple
of
things
I
mean
to
me.
The
extension
setting
is
extremely
different
than
data
pinning,
so
there's
not
a
whole
lot
of
correlation
between
the
two
but
I
understand
the
nervousness
of
it.
Z
The
thing
I
worry
most
about
is
that
when
you
rush
a
document
through
because
it
should
get
out
the
door
immediately,
that
you
end
up
with
a
greater
complex
situation
in
the
future,
so
specifically,
you
know
when
I'll
cut
out
some
stuff
look.
The
way
I
think
that
we
have
the
avoiding
complexity.
Right
is
the
worst
thing
that
you
could
do
is
create
two
extensions
that
have
to
mitigate
how
they
interact
with
each
other.
Z
That
is
much
more
complex
than
dealing
with
one
extension
field
that
may
or
may
not
ever
get
used
or
defining
pinning
in
the
future.
So,
in
terms
of
optimizing
for
least
operational
complexity
in
the
future
and
implementation
complexity
in
the
future,
it
seems
to
me
like
putting
in
an
extension
that
basically
says
if
you
see
this
extension
and
it's
empty,
regardless
of
whether
it's
2,
bytes
or
actual
length,
you
don't
do
anything
right
that
lets
the
protocol
go
forward.
Z
As
is
we
get
to
define
the
the
aspect
of
it
later
and
it
leaves
a
space
so
that
we
can
put
it
back
without
adding
the
complexity
of
having
multiple
version
interactions.
We
already
have
that
now.
Otherwise,
we're
going
to
end
up
with
this
thing
die
die,
die
as
well
to
get
rid
of
the
older
extension
right
now.
The
second
option
is
to
fill
it
in
now,
but
I'm
not
sure,
based
on
the
consensus
that
was
actually
filling
it
now
is
my
original
preference,
but
listening
to
the
room,
there's
not
consensus
on
that.
X
S
Because
the
whole
idea
is
that,
for
instance,
you
might
get
service
provided
at
strips
old
DNS
SEC
records,
so
you
cannot
get
anything
certified
through
I
thought.
This
was
coming
from
one.
You
got
the
first
one,
no,
no,
but
but
the
data
you're
pinning
is
DNS
SEC
data
that
presumably
you
couldn't
get
from
your
local
transport,
so
your
own
resolver
can
get
to
it
and
so
you're
getting
it
via
this
TLS
extension
as
a
sort
of
workaround.
S
E
Yeah
so
I
think
there
are
two
questions:
Ericka
Scarlett
there
are
two
questions.
One
is
painting
is
good
for
this,
and
the
other
is
if
pitting
is
good
for
this.
Should
we
you
know
how
should
we
proceed
hum
my
sense,
this
is
real
concern
where
the
printing
is
good.
You
asked
for
some
reasons.
First
of
all,
as
I
said,
paying
is
food.
E
You
quite
brutal
deployment
on
and
even
if
you
don't
think
sprawl
in
deployment,
we
show
the
problem
of
takeover
and
I
appreciate
that
you
think
that
you
can
stall
the
taker
for
problem
by
publishing
your
new
on
publishing
your
new
dialogue
assistance
records,
but
that
tastes
a
server
which
pre-decide
no
capabilities
to
do
DNS,
SEC
or
any
of
these
engines
at
all
and
force
the
new
mass
upgrades
source.
They
can
publish
the
record.
It's
completely
unacceptable
for
any
operational
perspective,
the
so,
but
it
may
be
as
possible.
E
Putting
is
good
study
that
problem
I'm
gonna,
be
skeptical.
I've
heard
a
lot
of
kuving's
skeptical
as
well,
so
the
question
becomes:
what's
the
appropriate
way
to
deal
with
the
potential?
Offending
is
good
number
possibilities
here.
One
is:
we
could
just
hold
this
entire
draft
until
two
years,
all
those
problem
with
other
ideas.
E
Q
So
cristinaw
Co
Carnegie
Mellon,
it's
a
to
Eric's
point.
It's
not
clear
to
me
that
you
know
if
you
do
zero
out
the
bytes
you
actually
have
to
solve
it
like
it
gives
you
the
time
right.
So,
if
I
feel
like
that's
a
false
boys,
we're
you
know,
reserving
the
bytes
now
and
specifying
them
as
zero,
like
the
Dvorkin
group,
can
pick
that
up
later
and
decide
that
you
know
what
Eric
we
looked
at
the
problem
and
you
were
right.
We
shouldn't
do
it.
We
can
just
leave
them
zero,
forever.
Q
I'm,
not
sure,
with
the
downside
that
that
is
other
than
you
know,
someone
might
feel
the
urge
that
boy,
it's
zero
bytes.
We
should
use
those
for
something.
I
mean
two
bytes
of
protocol
and
efficiency
doesn't
seem
like
the
end
of
the
world
to
me
when
we're
moving,
you
know
some
of
these
certificates
and
stuff
around
right.
So
it's
not
clear
to
me
how
reserving
that,
assuming
we
can
come
up
with
some
kind
of
useful
mechanism
that
we
can
define
as
a
problem.
T
All
right
Richard,
so
one
clarification.
One
piece
of
argument
so
wanted
to
clarify
this
incremental
deployment
issue
that
Victor
raises
is
not
an
issue.
If
it
were
an
issue,
we
wouldn't
be
able
to
do
this
delegated
credential
stuff,
which
requires
switching
between
one
modality
of
authentication
and
another
modality
of
authentication.
Depending
on
what
the
client
supports,
you
can
do
exactly
the
same
thing
with
this
extension.
If
the
client
advertises
that
it
can
do
Dane
based
authentication,
you
do
Dane
based
classification
if
it
doesn't
advertise
that
you
use
your
regular
old
PKI,
sir,
so.
S
S
T
S
S
T
T
A
T
Case
I'm
talking
about
is
where
you
are
trying
to
authenticate
and
you're,
not
trying
to
bind
yourself
to
a
specific
type
of
authentication.
So
it
is
the
case
that
dkg
mentioned
where
I
want
to
use
a
dane
asserted
certificate
to
authenticate
I,
don't
care
that
someone
might
be
able
to
get
a
PKI
certificate
with
that
name
and
I'll
use
that
to
authenticate.
That's,
not
the
thing
I'm
trying
to
address
with
this
extension
I'm
trying
to
use
this
to
extend
the
set
of
authentication
options.
I
have
not
to
rule
out
authentication
options.
I.
AA
T
Have
it
figured
out
so
that
was
just
my
first.
Let
me
briefly
make
the
point
I
really
want
to
make
here,
which
is
the
people
have
made
been
making
these
future-looking
statements
about
like
what
happens
if
we
do
nothing
here,
the
thing
I've
learned
about
this
is
the
way
this
discussion
has
been
helpful
to
me
is
to
underscore
how
much
we
screwed
up
date
in
the
sense
that
we
conflated
two
very
different
use
cases.
We
took
this
assertive
use
case
where
you
want
to
do.
T
S
S
Method,
I,
like
you
speak,
can
you
at
least.
Let
me
finish
my
sentences
and
dentox.
Thank
you,
I'm,
saying
that
you
are
not
actually
addressing
the
Dane
use
case
and,
if
you're
removing
it
from
a
scope,
you
should
remove
that
from
the
document
title
from
the
document
abstract,
and
you
should
say
this
is
only
for
these
specific
payloads
that
don't
that
are
not
bothered
by
download
by
downgrade
attack.
This.
T
T
T
S
Did
that
as
in
the
github,
and
we
did
provide
many
like
we
have
four
different
proposals
here,
come
on,
you
can
see,
we
didn't
try
to
help
you
out
and
coming
to
an
agreement
here
we
did
all
the
work
we
sent
to
80
hundred
emails
that
everybody
complained
about
to
TLS.
This
I
did
not
see
anyone
incorporating
to
get
our
use
case
working
what.
T
C
Mean,
unfortunately,
we're
kind
of
back
where
we
were
before
do
either
of
you
have
any
grant
suggestions
for.
B
It
would
be
nice
if
we
did
something
potentially
decide
whether
or
not
to
just
put
this
right
back
in
the
artsy's
header
DQ
to
let
it
move
forward
and
then
do
as
Richard
suggests
just
address
the
different
UK's
in
a
different
draft
or
you
know,
potentially
something
else
so
I
don't
know
if
we
want
to
have
our
own
source
to
do
that
particular
thing.
Take
that
particular
course
of
action.
C
Is
everybody
following
along?
What's
going
on
here?
Have
you
all
read
the
draft
I
see
lots
of
heads
nodding?
Okay,
that's
good!
So
we're
not
like
having
you
how
many
people
have
read
to
draft
Oh
fair
amount,
a
lot
more
than
I
thought
the
last
time
all
right.
So
let's
just
do
this
all
right.
I
know
here
comes
more
people
yeah.
We
did
kind
of
close
the
line
multiple
times.
AB
C
U
V
U
And
RFC
editor
queue
like
I,
don't
think
we
can
publish
that
as
it
is,
whether
we
you
add
some
additional
text
to
it
and
say
you
know,
try
to
describe
what
the
issues
are
and
what
use
cases
we
think
is
a
good
solution
for
and
what
uses
we
think.
It's
not
a
good
solution
for
I.
Think
there's
some
potential
for
that
to
be
your
way
forward
and
get
something
published.
Bowl
I.
U
Mean
I
think
there
are
other
options
open
for
the
working
group.
If
you
people
want
to
leave
an
extensible
hole
that
we
can
think
we
can
use,
but
like
I,
don't
have
a
great
sense
for
like
I
was
in
the
front
of
room
I
couldn't
see,
but
heads
were
shaking
or
nodding,
as
people
are
talking,
it's
my
fine
I,
don't
know
if
you
have
a
good
sense
or
not
know
so.
C
E
Is
that
made
part
ways
from
Richard
here,
but
I
I?
Don't
think
this
document
husband?
It
says
at
this
point:
I,
don't
think
it's
gonna
have
consensus
with
the
you
know
with
with
reposed
denial,
citizens
changes
either
so
I
don't
see,
I
mean
I
think.
Obviously
we
can't
publish
that
as
it
is,
but
I
also
don't
think
we
plausibly
I
mean
there's
the
parts
the
PR
everybody
agrees
on
and
I
think
we
can
merge
this
perfectly
well,
but
I
don't
think
like
God
I
would
be
uncomfortable
personally.
U
T
So
I
may
be
reaching
too
far
back
in
history
here,
but
we
had
a
home
at
the
last
night
CF
about
this
and
there
was
pretty
strong
consensus
on
the
side
of
doing
nothing
or
the
very
narrow
down.
Scoping
I
believe
was
the
contestants
at
that
point
and
we
want
to
confirm
it
on
the
list
and
that
exploded
into
a
big
discussion,
but
I
think
none
of
that
netted
a
broader
body
of
support
for
making
a
change.
It
was
just
a
lot
of
discussion
and
people
indulging
the
same
proponents
on
that,
so
I
mean
I.
T
I
would
be
glad
to
have
another.
If
you
wanted
to
refresh
that
here
to
have
another
hunt
that
can
engage
the
temperature
of
the
room
but
I'm
not
sure
yeah.
We
we
did
that
once
we've
gone,
there
were
strong
consensus
in
the
room
and
I'm,
not
convinced
that
the
the
mailing
was
discussion.
The
voluminous
actually
demonstrated
any
additional
support
which
the
change
position.
Okay,.
S
AC
C
All
right
so
we're
gonna,
postpone
this
discussion
and
come
back
to
figure
out
something
on
Thursday
I.
Think
at
this
point
it's
pretty
clear
that
we're
probably
in
it
maybe
being
out
of
the
our
sitter,
is
key
but
we'll
revisit
this
on
Thursday.
Hopefully,
everyone
will
have
a
chance
to
meet
and
greet
and
talk
and
maybe
see
if
there's
any
way
out
of
this
hole.
Thanks
next
I
believe
is.
E
C
E
I'm
like
get
down
the
floor
like
like
I'm,
you
know
or
something
okay
great
now
we
have
no
slides,
but
if
that
was
awesome,
okay,
so
so,
and
and
I
still
remember
back
in
IETF
101,
you
know
we
had
this
long
long
discussion
about
whether
or
not
we
should
explicitly
or
implicitly
mark
the
CID
and
I
think
people
were
kind
of
like
in
on
it,
but
we've
only
decided
we're
gonna
split,
we
mark
it
on
the
idea
was
to
mark
that's
there
not
to
mark
the
length.
E
E
That
says,
there's
a
huge
amount
of
like
you
know,
quick
style
screwing
around
because
like
trying
to
pack
the
length
of
the
first
three
bytes
and
like
have
like,
you
know,
like
only
values
between
1
and
16
or
something
so
we
also
agreed
that
the
DQ
less
one
free
work
might
not
be
quite
as
picture
as
we
were
hoping,
partly
because
they
were
actually
quick,
and
so
we
split
the
work
into
a
what,
though
the
kinda
shiny
draft
would
be
a
one
two
draft,
but
come
first.
E
We
take
all
the
CID
work
and
move
it
all
the
way
into
the
one
three
draft,
as
well
as
just
having
like
separate
craft
so,
but
they
both
use
the
condition
ID
extension
and
we
ended
up
putting
that
into
one
two
drafts.
But
the
way
they
did,
we
can
get
against
that
now.
We
could
just
moist
it
in
by
reference
next
slide.
E
So
the
the
big
question
for
1/2
was
basically
how
do
you
encode
that
the
CID
is
present
and
the
two
things
were
float
at
the
time
was
a
bit
in
the
length
field
or
having
shadow
content
types.
That
meant
you
know,
unlike
a
application,
did
the
message
but
CCC
ideas
present
and
we
were
concerned
about
like
whether
or
not
having
the
length
field.
You
know
some
of
these
a
that
light.
The
fight
the
packets,
for
you
know,
were
sixty
sixty
five
thousand,
not
chest
long
was
gonna
like
make.
E
No
boss
is
sad,
so
we
decided
not
to
do
that,
and
so
we
came
up
with
this
content.
Type
pack
turned
out
that
washes
work,
hard
defining
for
new
continent
types
and
minimum.
You
need
three,
maybe
don't
like
heartbeat,
but
it
still
is
three
and
that
started
to
make
like
actually
a
fun
reflection
or
make
people
sad,
starting
the
Martin
Thompson,
so
good.
E
E
So
the
co
points
are
pretty
scarce,
so
that
was
more
in
design,
which
I
think
is
actually
not
bad.
Yeah.
I
E
No
III
think
I
persuaded
me
that
we
shouldn't
take
it.
We
shouldn't
take
them
all.
Now
we
get
this
heart
because,
like
our
PETA
service,
a
well
loved
uh-hum,
so
right
so-
and
the
good
news
is
right-
is
that
if
you
do
this,
then
all
the
remaining
code
points
become
very
available
to
you,
so
so
you're
you're
chewing
up
one
code.
Point
that
basically
says
listen
I've
got
like
I
got
no
more
code
points.
Yeah
I
got
plenty
more
room,
so
that's
nice.
E
So
after
reading
this,
which
I
thought
was
a
pretty
cool,
so
proposal
I
was
like
well.
Maybe
like
is
this
too
much
for
people
swallow
so
maybe
there's
another
way
to
do
it.
It
is
like
less
hard
to
swallow,
and
so
my
alternate
alternate
design
on
their
site
is
basically
to
do
the
same
thing
with
a
marker
content
type
that
means
to
see
ideas
present
but
then
have
later
outside
the
encryption
boundary
have
a
true
content
type
that
field,
which
is
just
the
gashel
content
type,
and
so
this
is
basically
like.
E
This
is
conceptually
hortons
idea,
but
doesn't
involve
encrypting
it.
So,
like
obvious,
that's
except
your
inferior
from
a
security
perspective,
but
it's
like
easier
to
implement
and
so
like
you
can
have
to
decide,
like
you
know,
am
I
like
am
I
trying
to
make
one
to
better
or
am
I
just
like
one
to
kind
of
sucks
and
I'm
gonna
like
have
all
the
good
stuff
in
one
three,
so
I
think
like
I.
This
is
viable,
I,
don't
feel
strongly
about
it.
E
I,
don't
think
part
in
full
storming
about
it,
but
we
have
to
have
one
of
the
other
end.
So
I
don't
know
like
we
just
like.
Let's
just
decide
this
real,
quick
and
like
a
halt
scribble
on
the
draft,
and
we
don't
with
that
piece,
I
guess
I
think
I
personally
prefer
Martin's
proposal.
I.
Think
it's
like
like.
Why
not
do
the
right
thing
when
we're
in
the
game,
but
if
anybody
thinks
morals
like
too
much
work
and
like
you
know,
this
is
available
too.
AE
Thomas
I
might
have
an
alternate
alternate
alternate
design
here
and
I
might
have
a
third
opinion.
Okay,
which
is
we
go
back
to
the
original
problem,
which
is
the
fact
that
the
wave
the
1.3
header
is
laid
out
at
the
moment,
implicit
ereserves,
two
to
the
fifth
good
points.
That's
why
we
end
up
with
38
minus
30,
32
problem
marking
is
saying
so.
If
we
instead
pin
one
of
these
bits
of
the
reserved
bits
say
bit
7
or
equivalently,
we
instead
of
doing
0
1
1,
we
do
0
1,
1
0.
AE
E
I
I
E
We
only
have
one
left:
no,
we
will
do
to
fight
thing
as
two
dozen
is
it
is
it
20?
Is
it
I
thought
it
was
16
we're
just
we're
losing
them
you're,
really
gonna
flag
that
we're
not
losing
as
you
can.
You
can
us
go
forward.
We
have
on
the
slides
oq
guy,
so
we
have
the
diagram
that
one
yeah.
Okay,
sorry
so
have
four.
We
have
14
bits
of.
We
have
14
deaths,
so
you're
gonna
take
only
one
over
one
of
our
flight
bets
right.
That's
reversal.
E
Take
away
this
axis
right
so
like
I,
want
to
make
T
less
1.3
better
and
I.
Don't
really
care
much
that
tells
from
point
2.
So
the
fact
that
you
have
to
like
pay
one
point,
a
less
1.2
to
have
connection
ID,
because
you
don't
have
moved
1
3,
like
elitism
with
me
like
this,
is
like
a
piece
of
recession
points
we
like
we
have.
Why
should
we
place?
We
give
it
up
just
for
this,
for
one
tail.
AF
AF
E
AD
H
E
E
E
Next
lie:
okay,
so
Newton
I'm,
now
a
new
person
speaking
for
different
good
for
authors,
this
is
TTLs
one
three,
so
this
actually
has
like
almost
the
same
topics
as
previously
next
slide.
So,
as
I
said,
you
know,
despite
my
previous
principles,
we're
gonna
put
some
extra
flag
bits
in
here,
because
we
just
like
need
it
to
fly.
It
needed
some
flag
this
already,
and
now
we
have
some
spares.
That
would
not
be
more
ordinary
preference.
So
we
discussed
this
unified
packet
format
that
basically
is
sort
of
vaguely
prick
inspired,
but
not
entirely.
E
That
gives
it
give
us
one
well
enough.
Sequence.
Number
also
doesn't
interface
interfere
with
any
other
code
points
and
and
also
gives
us
room
for
these
two
to
flag
bits
that
tell
you
whether
or
not
the
connection
is
present
so
like
the
way
to
read
this
first
word
is
things
that
say:
zero,
zero,
one
actually
or
zero
zero
one.
The
Z
says
a
connection
ideas
present.
The
else
has
a
length
fill
is
present
and
the
exes
are
reserve
reserve
bits
which
might
be
something
in
the
future
and
I
can't
remember.
E
We
wrote,
but
we
should
write.
Is
if
you
receive
these
bits
and
there's
something
else
that
you
didn't
expect
other
than
like
zero
and
there's
no
Ascension
telling
you
that
you
should
joke.
Unless
this
David
things,
we
should
grease
them,
which
might
be
a
possibility.
You
think
you
should
grease
them.
Should
we
grease
the
bits?
I
E
E
I
I
realized
that
I
missed
this
when
I
was
reviewing
this
and
I'm
sorry
for
that,
but
the
having
reserved
bits
there
is
a
little
awkward
okay,
because
you
have
to
worry
about
this
question
of
greasing.
And
if
you
look
at
this
look
at
this
layout,
you
can
potentially
only
have
one
bit
free
puck
in
the
very,
very
short
hitter.
I
Gonna
be
used
once
the
connection
is,
yeah
is
up
yep,
and
that
gives
you
potentially
the
three
fixed
bits.
The
three
bits
that
you
have
there
would
be
the
connection
idea
bit
the
long
bit
or
and
the
epoch
bit,
and
then
you
have
ten
bits
of
sequence
number,
which
is
a
lot
for
a
bunch
of
use
cases.
If.
E
Kind
of
where
I
came
down
yeah,
if
you
feel
strongly
about
him
happy
too
yeah.
Well,
we've.
U
E
E
Could
do
that?
That's
possible
D
I,
don't
feel
real
strongly
about
a
lot
there
right.
I
mean
I
only
made
this
exact.
This
will
reserve
pixels,
like
though
there.
E
E
E
So
there's,
unlike
one
to
where
we're
not
gonna,
have
any
way
to
refresh
the
connection
IDs
one
three
doesn't
refresh
second
Hades,
which
is,
like
you
said,
a
new
condition.
Any
message
that's
missed
of
underscores
in
it
I
think
I,
you
just
screwed
up
with
tech,
there's
also
a
request.
Kadesh
I
need
messages,
says
I'd,
like
some
more
connection.
Ids
has
exactly
semantics:
do
you
think
it
does,
which
is
send
me
a
new
cache
ID?
This
is
her
board
I.
E
Think,
let's
it's
getting
increasingly
hard
to
tell
which
ideas
start
up
for
some
TTL.
So
much
open,
correct.
To
be
honest,
comment
some
of
the
same
people
so
anyway,
we
have
this
thing,
so
you
don't
need
to
renegotiate
next
slide.
So,
like
all
this
grip,
these
really
great
to
have
a
connection
IDs.
But
if,
like
you've,
been
increasing
sequence
number
then
like
basically,
the
whole
thing
was
kind
of
pointless.
So
this
is
definitely
a
quick
idea
home.
E
So
the
idea
is
to
steal
the
quick
style
packet
number
encryption
and
for
all
the
GTL
s1p
safer
to
fix
packets
and
I
want
emphasize,
with
or
without
the
connection
ID
like
we're,
always
gonna
have
this
here,
and
so
it's
exactly
the
same
function
as
in
quick
more
successfully,
which
is
you
take
some
sample
sum
of
the
ciphertext
and
use
that
as
the
input
to
a
pseudo-random
potion,
which
you
XOR
with
the
which
is
an
extra
with
the
micro
sequence
number.
E
You
can
emulate
this
with
counter
mode,
those
like
not
really
counter
mode,
but
whatever
there's
like
a
draft
redraft
PR
at
this
location
here
and
that's
what
there
is
so
I
think
this
is
like
kind
of
a
small
improvement
to
DTLS
in
the
sense
that
I
mean
I
said
that
encrypted
sequence
numbers
are
a
nice
thing,
so
we
must
we'll
have
them
the
whole
time
program
help
at
all,
I
don't
promise.
The
PR
is
good.
Hence
the
term
crafty
draft
yeah.
E
E
H
E
With
not
without
one
one
yeah,
okay
next
slide,
so
anything
else.
Anyone
else
to
raised
about
details,
one
three
like
we're
kind
of
getting
down
to
the
wire
here,
so
we
have
to
implement.
We
have
no
point
this
header
yet,
but
we're
going
to
really
soon
so
so.
I
Quick
is
having
a
bunch
of
discussions
about
new
commission
IDs,
how
you
manage
connection
IDs,
have
a
get
rid
of
them
and
all
of
that
they're
on
a
plea
of
horror
that
comes
with
that.
We
should
probably
not
make
any
serious
moves
until
that
sells
down
over
there.
I'd
like
to
see
that
designs
be
relative,
a.
H
E
E
Well,
I'm
happy
to
hold
the
hold
it.
I
mean
I,
agree
that
there's
no
reason
why
they
shouldn't
the
same
design
hum
but
yeah,
that's
a
you
know.
We
are
like
details,
one
three
is
closer
to
being
done
than
quickest,
and
so
that's
the
problem
yeah.
So
I'd
like
I'd
like
to
resolve
these
issues
in
quick
sort
of
like
we
can
have
the
same
thing
and
we
get
this
other
door
we
should
be.
We
should
be
talking
about
this.
This
okay.
AF
We're
in
the
quick
working
group
is
that
discussion
happening
there's
some
building,
no
no
I
mean
as
I
check
the
mailing
list
before
working
on
on
the
PR,
and
things
are
it's
sometimes
hard
to
find?
Is
it?
Is
it
on
mailing
list?
Is
it
in
some
github
repository
where
where's
the
discussion
so
quick
has
the
has
adopted.
I
A
policy
of
having
substantive
discussions
on
github
and
there
are
a
number
of
issues
that
track
this
particular
class
of
problems.
Unfortunately,
the
discussion
is
split
across
a
number
of
different
issues,
because
there
are
a
number
of
interrelated
issues
that
were
discussing
and
so
I'm
happy
to
give
anyone
a
bit
of
a
set
of
pointers
if
that's
necessary
or
since
I
makes
it
listed.
Just
worry.
AF
I
We
don't
necessarily
do
other
groups
of
service
with
respect
to
the
the
work
that's
going
on,
because
of
the
way
that
the
discussion
is
fractured,
but
that's
just
a
not
effective,
well
want
to
work
going
on
so
now
different
github
issues
after
on
yeah,
if
you
needed
help
with
that,
all
right,
there's
a
discussion.
How
about
we?
Have
the
discussion?
Be
quick
and
we'll
see
how
what
turns
up
there
and
and
hopefully
there'll
be
something
that
you
can
use
and
capture.
That's
a
little
less
yeah.
I
E
C
C
E
E
The
motivation
for
this
is
to
reduce
the
exposure
of
private
certificate,
private
keys
to
compromise
of
one
way
or
another
of
the
web
server
in
which
that's
serving
TLS,
so
you
have
a
server,
that's
serving
TLS
and
commonly
right
now,
the
long
term
secret
key,
the
long
term
private
key
of
the
certificate
is
held
in
the
memory
space
of
that
application.
That's
connected
directly
to
the
Internet.
E
There's
been
a
history
of
compromises
that
a
lot
of
these
web
servers
are
written
in
memory,
unsafe
languages,
Hark
lead
is
the
most
most
famous
of
which,
so
the
idea
for
this
is
to
reduce
the
exposure
of
long-term
private
keys
to
this
type
of
vulnerability,
so
the
latest
subject
was
mainly
editorial.
The
action.
E
So
the
client
will
validate
that
this
delegated
credential
was
correctly
signed
by
the
end
entity
certificate
and
that
the
data
is
in
the
valid
range
and
it's
only
useful,
or
only
to
be
used
with
certificates
that
have
a
specific
object.
Id
that
identifies
that
it
is
the
person
owning
the
certificate
is
willing
to
do
delegated
credentials
next
slide,
please.
E
It's
meant
to
be
a
very
limited
scope,
object
that
allows
you
to
simply
swap
the
public
key,
reduce
the
time
complete
time
validity
of
the
credential,
and
so
it
has
some
nice
properties
and
that
it's
actually
bound
to
the
certificate
that
is
signing
it,
and
it
has
this
very
sort
of
simple
credential
structure
that
has
the
signature
scheme
that
it's
signed
with
the
signature
the
valid
time
the
public
key
next
slide,
please.
So
in
terms
of
implementation,
this
is
the
the
major
progress
that's
happened
is
we've
built
some.
E
E
These
as
well
I,
know,
there's
also
a
implementation,
picot
TLS
that
we
haven't
intervene
tested
with
the
latest
draft,
but
we
expect
to
have
more
comprehensive
testing
done
soon
and
if
this
is
on
the
path
to
being
adopted
and
and
secure,
then
CloudFlare
has
a
plan
of
serving
these
for
certain
certificates,
starting
in
fall
of
this
year,
especially
this
before.
But
eva
CA
he's
willing
to
give
you
the
code
point:
it's
it's
pending
on
the
it's
coming
up,
it's
waiting
on
us
no!
E
E
E
So
in
the
draft
right
now
there's
an
object,
ID
proposal,
that's
basically
blank.
We
have
been
using
in
interoperability
tests.
One
that's
defined
under
under
cloud
source
object
space,
so
the
question
number
one
I
want
to
raise
here
is
whether
or
not
we
should
move
to
an
object
ID
that
is
more
fit
for
purpose.
For
this
something
that's
defined
for
IETF
security,
or
maybe
we
should
even
consider
changing
this
from
an
object
ID
to
an
extended
key
usage
in
the
peek
exert
if
Achatz
so
this
is.
This
is
an
open
question
right
now,.
C
V
V
D
E
That
sounds
like
we
should
stick
with
what
it
is
right
now,
which
is
just
an
annoyed,
more
picket.
Next
next
slide,
please
so
proposal
number
two.
This
was
brought
up
as
a
way
to
ensure
that
these
certificates
that
are
used
for
delegation
are
not
used
for
TLS.
So
there's
this
TLS
feature.
Extension
that's
used
for
OCSP
must
staple.
It
allows
you
to
have
an
array
of
enumerations
where,
if
a
client
sees
one
of
these
certificates
and
the
feature
is
not
used
by
the
server,
then
it
can
disconnect.
E
So
the
question
is
here:
can
we
should
we
add
an
optional
TLS
feature
value
for
requiring
the
use
of
a
delegated
credential?
The
advantages
of
this
are
that
you
separate
the
the
use
of
the
private
key
for
this
certificate
to
not
be
used
in
TLS,
so
it
should
not
be
used
in
TLS
and
would
only
be
used
for
issuing
these
short-lived
delegated
credentials.
E
The
complications
here
are
that
if
you
are
going
to
serve
a
website
and
use
delegated
credentials
and
have
clients
that
are
but
supporting
and
not
supporting,
then
you
need
to
have
two
certificates
and
be
able
to
switch
between
the
two
and
a
lot
of
client.
Software
is
unable
to
really
do
that
efficiently
or
do
that
in
practical
sense
of
switching
dynamically
choosing
a
certificate.
So
this
would
be
an
option
for
servers
that
do
to
have
that
capability.
E
Proposal
number
three:
this
is
was
raised
by
Christopher
patent.
Currently,
a
delegated
credential
is
really
a
public
key,
so
it
can
be
used
for
any
signature
scheme
that
that
public
key
can
be
used
for
so
in
the
case
of
RSA.
There's
a
whole
list
of
these
PSS
cipher
suites,
with
different
hash
algorithms
that
you
can
use.
E
The
proposal
is
to
pick
one
ahead
of
time
when
you're
issuing
when
you're,
basically
creating
a
delegated
credential,
bind
it
to
the
only
one
signature
algorithm
that
you
can
use
for
that
delegated
credential
it
it
makes
the
it
makes
the
analysis
slightly
simpler.
It
requires
you
to
if
you
want
to
support
clients
that
do
all
sorts
of
different
signature
schemes
or
want
different
signature
schemes.
E
I
E
I
E
That's
a
good
point:
the
pull
request
as
written
does
not
include
the
signature
of
them
in
the
explicit
delegated
credential.
Just
in
the
signature
trim.
The
value
that's
signed
by
the
signature
but
having
it
explicitly
in
the
delegated
credential
will
make
debugging
easier.
If
you
have
a
failed
signature
on
a
DC,
you'll
you'll
be
able
to
figure
it
out
much
more
more
quickly.
A.
O
E
E
C
I
Some
of
them
Thompson,
the
the
question,
then,
would
be
what's
the
cost
to
doing
this
in
1.2,
because
if
it's,
if
it's
more
expensive
for
us
to
say
you
can't
do
it
in
1.2,
then
I'd
be
sort
of
well
just
let
it
drive,
but
I
suspect.
What
you've
got
here
is
an
extension
you
you
currently
in
tell
us.
1/3
would
put
the
delegated
credentials
as
an
extension
on
a
certificate
message,
which
is
something
that
doesn't
happen
in
1.2
I.
E
Okay,
so
this
is
this
is
something
that
we've
been
doing
for
a
lot
of
these
dresses
is,
let's
get
some
actual
assurances
with
cryptographic
tools
that
this
is
actually
a
solid
thing
to
do
cryptographically,
and
so
we
don't
have
a
formal
validation
of
this
protocol
as
currently
designed.
So
this
is,
this
is
sort
of
an
open
call.
E
K
E
O
Okay,
I'm
Jonathan
talk
about
layering
sports
authenticators
next
slide,
please
so
one
of
the
things
I
did
the
formal
analysis,
sort
of
explores
to
authentic
ages,
and
one
of
the
things
it
says
it
doesn't
do
is
provide.
Joint
authentication
of
multiple
certificates
applies
in
multiple
EA's
I
can
prove
that
I
control
them
individually,
but
not
together,
and
so
what
it
actually
means
is
joint
authentication
would
mean
that
all
the
A's
were
generated
by
the
same
actor.
Next
slide.
Please
I
think
Ben.
Do
you
want
to
interrupt?
Oh,
please,.
O
The
I
joined
authentication
means
that
you
can
prove
that
all
of
the
certificates-
sorry
all
of
the
EAS-
were
created
by
the
same
entity
for
each
side.
Obviously
the
client
ones
aren't
created
by
the
Sun
or
anything
next
slide,
please,
okay,
so
generally,
you
would
expect
this
not
to
be
able
to
happen,
because
only
one
person
can
write
to
this
other
side
of
the
TLS
channel
or
whatever.
O
However,
there's
actually
a
bunch
of
different
scenarios
where
multiple
people
could
be
right
into
the
channel.
If
you
have
a
static,
RSA
key
exchange,
then
it
could
be
some
middle
box,
an
attacker
who's
compromised,
difficut,
CDN,
coalescing,
multiple
keyless,
SSL
Certificates,
together
or
if
you-
and
this
was
just
me
last
night.
If
you
have
a
server
a
resumption,
then
you
can
the
resumption,
whilst
the
secret
might
be
passed
around
within
a
data
center
and
so
that
multiple
different
places
could
accept
the
resumption
other
than
just
the
original
server
next
slide.
O
Please
so
I
propose
an
extension.
The
previous
difficult
quest
context
is
now
not
necessary
because
it's
guaranteed
to
be
unique,
but
basically
you
just
put
the
previous
finished
in
the
difficult
quest,
and
if
it's
echoed
back
it
means
the
server
or
sorry
means.
The
sender
believes
that
all
of
the
previous
certificates
are
valid.
So
this
is
a
not
quite
the
same
thing
as
joint
authentication
because
it
includes
the
client
and
the
server
certificates
are
all
valid,
so
it
means
the
server
has.
O
So
if
a
server
sent
this,
it
would
mean
it
has
accepted
the
client
certificates
as
well,
but
it
also
only
applies
to
this
difficut
scre
interchange.
It
changed
once
the
certificate
together.
It
says
all
previous
ones
are
valid,
doesn't
say
anything
about
future
certificates.
Next
slide,
please
so
one
use
case
could
be
updating.
O
Another
use
case
that
suggests
to
me
last
night
was
again:
you
could
chain
or
thent
occations
from
resumption.
So
at
the
moment,
if
you
sends
in
the
a
and
then
do
a
resumption
you'd
have
to
resend
that
ei
and
now
you
could
make
it
so
that
you
wouldn't
have
to
resend
it.
You
could
just
prove
that
you
controls
it.
O
P
O
You
would
make
a
chain
of
them
and
therefore
they
would
have
to
be
in
order
in
the
chain.
Not
everything
has
to
be
in
the
chain
and
if
and
the
chain
can
diverge
and
that's
still
fine,
you
can
have
a
forest
of
authentication
if
you
so
choose
the
only
case
where
that
would
be
an
issue
really
is,
if
you
have
certificates,
cross
mid-flight
and
then
one
side
or
the
other
has
to
do
an
extra
sign.
If
you.
P
O
Only
joins
on
your
branch,
so
if
I
have
two
separate
branches,
they
can
have
two
completely
different
authentication
properties,
but
it
doesn't
break
the
authentication.
It's
just.
You
can
end
up
with
some
ridiculously
complicated
authentication
mechanism.
Yeah
I
wouldn't
suggest
as
a
you
should
do
this
that
that's
more
of
it.
It
doesn't
break
so.
P
O
To
achieve
I
wouldn't
expect
it
to
make
a
difference,
because,
as
long
as
the
safety,
the
server
sending
them
as
long
as
the
server
knows,
what
order
it's
sending
them
back
in
it
all
works.
E
E
E
That's
a
very
odd
design,
Hausa.
Typically,
we
don't
ask
people
to
attest
to
random
crap
the
third
guy
sent
across
the
wire
didn't.
Also
people
soon
feel
to
test
a
random
stuff,
their
guy
sent
across
the
wire.
So
there's
an
immediate
problem.
I
see
with
this
wishes
that
beam
visit
a
very
easy
way
to
implement
this.
That
is
completely
screwed
up,
isn't
doesn't
the
request
contain
the
contain
the
requested
certificate?
Is
that
correct
the
the.
O
O
O
O
E
E
E
Failure
right
so
yeah
I,
don't.
C
Know
so
more
thoughts
required
since
we're.
We
have
like
one
minute
remaining
I
guess
I
want
to
ask
who's.
Read
this
draft:
oh
I'm,
actually,
a
pretty
good,
fair
number,
yeah
I
think.
Maybe
it's
a
little
early
to
ask
for
working
group
adoption,
but
I
think
that
I
I
just
wanted
to
get
people
to
pay
attention
to
yeah
fair
enough,
so
go
ahead.
We
got
time.
We
have
an
obsession
and
I
think
that's
it
for
today.