►
From YouTube: IETF110-TLS-20210308-1600
Description
TLS meeting session at IETF110
2021/03/08 1600
https://datatracker.ietf.org/meeting/110/proceedings/
A
It's
the
top
of
the
hour
and
time
to
start
tls
at
ietf
110..
First,
I
want
to
thank
everybody.
Who's
joined
for
joining
this
edition
of
our
online
tls
meeting.
A
A
Ieps,
okay,
so
we
have
a
minute
takers.
I
think
folks
would
be
helpful
if
people
were
on
jabber
to
see.
A
A
Going
on
there
to
make
sure
we
don't
miss
anything
blue
sheets
are
now
automatic.
We
don't
have
to
pass
anything
around
as
usual
state,
your
name
and
your
affiliation
when
talking
at
the
mic
and
as
always,
keep
it
professional.
A
For
the
agenda,
we
have
a
short
presentation
on
tls
interop
runner,
then
we'll
talk
about
encrypted
client,
hello,
rfc,
8446,
bits,
deprecating,
ffdhe,
tls,
proof
of
knowledge
and
opaque
tls.
Are
there
any
other
additions?
I
think
that
we'll
also
give
a
brief
document
update
as
well
as
part
of
the
agenda.
Are
there
any
other
additions
to
the
agenda
or
comments
on
the
agenda?
A
All
right
great,
so
other
chairs
feel
free
to
step
in.
If
I
misspeak
on
this
slide
sean
did
you
wanna.
A
Okay
yeah,
so
we
have
a
couple
of
drafts
that
are
in
the
rfc
editor
one
rc
editor
queue,
which
is
deprecate
old
versus
tls
and
ticket
requests.
A
We
have
requested
publication
on
a
number
of
these
there's
a
dtls
one.
Three,
I
think.
That's
still
in
the
publication
requested
state
exporter,
authenticators
and
deprecate
md5
and
sha-1.
Do
you
have
any
additional
updates
on
these
strong.
D
A
Yeah,
so
I
had
that
noted
in
heading
to
ietf
last
call
or
was
heading
until
last
night,
where
it's
actually
in
last
call
now
which
is
dtlscid.
Did
you
have
another
comment,
then.
D
A
Okay,
awesome
waiting
for
write
up.
We
have
external
psk
guidance
and
delegated
credentials.
There's
still
a
couple
open
issues,
I
think,
with
delegated
credentials
that
we
need
to
just
tie
off,
and
I
think
pfk
guidance
may
be
the
same,
although
I
think
there
may
have
been
a
new
draft
published
recently.
B
A
Yeah
we'd
like
to
get
those
drafts
moving
forward,
we're
looking
to
do
a
working
group
last
call
on
flags
extension
soon,
and
we
have
a
number
of
drafts
in
progress,
some
of
which
we'll
be
talking
about
today,
mainly
encrypted
client,
hello
and
rfc
8446-bits.
A
E
E
So,
to
begin
with,
implementing
tls
is
not
easy
and
it
does
not
get
easier
as
new
features
and
new
extensions
are
proposed
and,
in
addition
to
the
usual
testing
mechanisms,
it'd
be
nice
to
know
that
the
different
implementations
of
tls
agree
with
each
other
on
how
the
the
protocol
and
how
its
extensions
are
supposed
to
work
and
the
spreadsheet
on
the
right
is
a
basically
concerns
a
future
call
known
as
ech
or
encrypted
client
flow,
and
it
maintains
interoperability
data
for
this.
E
For
this
feature
and
as
you
might
be
able
to
guess,
it
is
an
easy,
as
there
are
more
like
implementations
and
more
tls
features
such
as
delegated
credentials,
for
example,
this
becomes
more
error-prone
and
it's
it's
difficult
to
scale,
and
it
would
be
nice
to
automate
everything
about
this
from
the
actual
testing
to
the
to
the
presentation
of
the
results.
E
And
that's
basically
where
the
tls
interop
runner
comes
in
so,
for
example,
at
a
very
high
level.
The
way
it
works
is
if,
if
we
have
like,
let's
say
a
test
case,
we
want
to
test
several
authentication
using
delegated
credentials.
For
example,
the
runner
starts
off
by
generating
some
keys
and
some
certificates,
and
it
then
passes
them
to
a
client
and
server
which
are
basically
docker
images.
E
The
ns3
network
captures
all
the
packets
and
generates
a
packet
trace
and
the
clients
and
and
the
client
server
output
their
logs
and
their
key
log
files,
and
then
the
runner
uses
it
decrypts
a
packet
trace
and
then
checks
it
to
see
if,
if
the
transcript
was
as
what
we'd
expect
of
the
for
that
particular
test
case,
and
if
we're
considering
the
example
of
server
authentication
using
delegated
credentials
again,
then
one
of
the
things
we'd
want
to
check
for
is
that
the
client
actually
did
indicate
support
for
delegated
credentials
in
its
client
flow.
E
So
here's
a
small
demo
of
what
we
have
so
far.
This
is
a
work
in
progress,
but,
as
you
can
see,
on
the
on
the
left
hand
side
we
have
in
like
an
automated
ci
system
that
basically
builds
all
the
endpoints
and
then
pairs
them.
E
E
We
also
plan
to
we're
also
working
on
including
fuzz
performance
and
regression
testing
using
tools
such
as
tls
attacker,
and
since
we
have
ns3,
we
can
also
use
that
to
in
performance
testing
to
like
drop
packets
or
to
add
additional
traffic
or
and
whatnot,
and
it
is
it's
it's
a
github
repository
it's
easily
available.
E
It
can
be
cloned
and
run
locally
and
we're
working
on
a
website
to
present
the
results
and,
of
course
I
should
mention
that
yeah,
except
for
third
party
code,
it
is
licensed
under
mit,
and
we
welcome
all
sorts
of
pull
requests,
comments,
issues,
feedback,
they're,
certainly
welcome,
and
that's
that's
it
essentially.
Thank
you
for
listening.
E
Is
there
any
questions
happy
to
take
them
now.
C
Yes,
I'm
trying
to
trying
to
speak.
Did
you
document
that
this
somewhere
or
artists,
hidden
somewhere
in
some
script,
also.
E
Oh
so
right
now
the
test,
there's
a
wiki
on
the
in
the
github
repository
that
like
documents,
what
tests
we
have
so
far
right
now,
we
only
have
delegated
credentials
and
like
two
basic
tests
related
to
encrypted
client,
hello.
But
yes,
once
we
get
the
website
up
and
running,
we
plan
to
like
present
that
all
in
a
nice
aesthetic
way.
G
Dkg
has
a
question.
I
don't
know
if
you
can
see
the
chat
go
to.
E
Is
it
oh,
the
process
for
getting
an
employee?
What
is
the
process
for
getting
an
implement
implementation?
Added
to
this?
It's
essentially
it's
adding
a
docker
file.
So
we
already
have
like
a
couple
of
client
server,
implementations
that
and
it's
a
matter
of
just
copying,
some
of
the
conventions
that
they
follow
and
then
yeah
just
adding
a
docker
file
to
the
repository.
A
H
E
We
have
like
a
I'm,
not
completely
sure
the
like.
It
was
chris
patton
out
of
that
test
case,
but
the
I
think
so
so,
if
you're
talking
about
like
resolution
like
client
server
resolution,
we
just
like
those
are
like
sort
of
hard
hard
coded
into
the
endpoints
and
we
sort
of
like
the
endpoints
there.
The
client
is
supposed
to
connect
to
like
example.com,
and
that's
that
resolution
is
like
taken
care
of
by
the
interrupt
runner.
A
Great,
I
mean
I
think
this
will
be
pretty
useful,
especially
as
we
build
out
more
test
cases.
E
G
G
Right
so
there
was
a
message
that
went
out
to
a
list
a
while
back
throws
moving
the
interrupt
target
from
draft
nine
to
draft
ten
there's
a
pr
up
right
now.
That
includes
the
change
log
between
these
two
versions
and
thanks
to
martin
thompson
for
pointing
out
that
we
should
probably
be
including
change
logs
going
forward,
especially
as
we
now
have
a
primary
official
interrupt
target.
Given
that
draft
10
or
what
is
now
the
editor's
copy
of
the
draft
uses
the
the
final
version
of
hpe.
G
That
is
the
version
that
won't
change
test
factors
again.
It
won't.
It
won't
likely,
unless,
like
something
major
happens
with
the
protocol,
past
isrg
or
isrg
review,
and-
and
you
know,
perhaps
additional
community
analysis
we'd
like
to
I'd
like
to
propose
you
know
just
getting
the
hpp
dependency
out
of
the
way
bumping
the
draft
version
to
10.
Ideally
today,
if
it's
not
controversial
and
then
just
moving
our
interrupt
target
from
nine
to
ten
and
there
is,
there
was
some
support
for
this
on
the
mailing
list.
G
But
I
just
I
wanted
to
pose
it
to
the
group
now
to
see
if
there's
any
violent
objections.
As
far
as
I
know,
most
people
who
are
implementing
it
are
supportive
of
moving
forward,
but
just
like
confirmation,
so
I'll
pause
briefly,
if
there's
any,
you
know
burning
desire
to
not
do
so.
Please,
let
me
know
ben
asks.
If
the
publish
vacation
process
closed.
Do
you
mean
the
data
tracker
yeah?
The,
as
I
points
out
that
the
tracker
is
back
open
for
submission,
so
we
can
wrap
the
document
today.
G
G
Oh
it's
plus
one.
I'm
sorry
plus
q
can't
read
okay,
great,
so
hearing
no
objections.
I'll
do
so
and
then
I'll
follow
up
on
the
thread
saying
that
the
are
up
with
the
pointer
to
the
latest
version.
Then
we
can
go
from
there
as
a
reminder
there
isn't
inspired
by
quick.
There
is
a
matrix
which
has
the
various
clients
and
servers
that
we'd
like
to
use
for
tracking
interop
results,
we're
also
trying
to
pull
them
into
the
interop
runner
as
well.
G
So
we
can
automate
this
thing
going
forward,
but
as
as
you
start
bringing
up
your
implementations,
please
feel
free
to
either
add
them
to
the
matrix.
If
you
don't
have
access
request
it
or
leave
a
comment
or
so
on,
and
hopefully
we
can
get
some
good
interrupt
results
between
now
and
the
next
ietf
version.
G
Next
slide,
please
all
right,
so
there's
there's
a
couple
of
small
issues
up
right
now.
Some
of
them
have
pull
requests
and
up
some
of
them
don't
and
then
there's
one
whopping
issue
that
doesn't
yet
have
a
pull
request
up
that.
Unfortunately,
it
looks
like
we're
not
ready
to
talk
about
yet.
G
So
what
I'd
like
to
do
now
in
the
time
that
we
have
is
try
to
go
through
each
of
these
smaller
issues,
just
discuss
them
see
what
people
think
see
if
we
can
get
towards
some
sort
of
you
know
shared
vision
of
what
we
should
do
with
them,
potentially
throw
up
prs
to
accommodate
them
and
then
move
forward
so
joe
if
we
could
just
start
marching
through
these
issues,
that
would
be
great.
G
H
H
G
Yeah
I
mean
yeah
if
we
have
time
to
talk
about
them,
but
then
we
can.
Ideally
all
these
issues
are
tracked
in
github,
so
we
can
have
the
conversation
there,
but
yeah
once
once
we
get
through
these
I'll
turn
it
over
to
you.
If
you
want
to
just
start
merging
through
yours,
I
think.
G
Like
45
minutes,
I
forget
how
much
time
for.
G
I
so
I
I
think
we're
all
under
no
illusion
that
this
is
a
complicated
thing
to
implement
and
and
surely
we're
not
trying
to
make
the
thing
more
complicated
than
it
needs
to
be.
So
I
I
think
we're
all
trying
to
be
mindful
of
complexity,
as
we
propose
resolutions
to
particular
issues
and
resolve
things
like
hr
and
so
on.
The
the
the
final
slide
for
this
particular
section
will
be
a
proposal
or
talks
about
a
proposal
in
helping
to
deal
with
complexity
going
forward.
G
So
I
I'll
note
it
now,
but
I
don't
think,
there's
much
we
can
do
other
than
say
you
know
what
we'll
try
to
not
make
things
more
complex
than
they
need
to
be,
which
I
think
is
a
like
sort
of
your
design
goal
that
we
all
have.
H
G
Right
so
the
the
issue
up
on
the
screen
right
now,
if
you
can
scroll
up
a
little
bit
joe
just
so,
the
title
gives
contacts
to
people.
It's
basically
that
right
now
there
is
a
a
sort
of
obvious
distinguisher
for
ech
versus
non-ech
in
that,
if
you're
using
eca
to
prohibit
you
from
attaching
a
psk
on
the
outer
client
holo
for
various
reasons
c,
the
draft
and
the
various
attacks
that
we
encounter
with
sort
of
ticket,
oracles
and
whatnot.
G
But
if
you're
using
greece,
you're
you're
allowed
to
send
a
resumption
psk,
which
means,
if
you
see,
if
you
see
a
psk
you're
likely
to
determine
that
this
is
definitely
not
ech
and
and
therefore
it
sticks
out.
So
I
think
there's
a
proposal
down
at
the
bottom.
In
terms
of
addressing
this,
can
you
scroll
down
joe.
G
Right
so
effectively
what
the
proposal
is
to
recommend
or
suggest
that
clients
may
or
or
should,
depending
on
how
strongly
you
feel
about
this,
send
a
dummy
psk
if
you're
using
ech,
and
you
have
an
inner
psk
as
well,
because
one
of
the
interesting
edge
cases
is
wherein,
if
you
have
a
psk
and
the
inner
client,
hello
and
the
server
and
its
response,
inter
after
accepting
ech
replies
with
a
psk
extension,
some
middle
boxes
might
interpret
that.
G
As
you
know,
compliance
like
there
was
no
psk
extension
in
the
client
hello,
but
there
is
one
in
the
outer
client
hello
or
in
the
server
hello
rather
so
trying
to
deal
with.
That
seems
at
least
useful
from
a
sort
of
deployability
perspective,
and
that's
probably
the
most
we
can
do
in
terms
of
this
particular
issue.
Anything
more
in
terms
of
trying
to
like
hide
the
fact
that
you're
doing
ech
by
like
playing
with
dummy,
ech
or
not
or
hardwood
case
or
not,
seems
complicated.
G
So
I
I
think
the
concrete
proposal
here
is
to
just
stick
with
stick
a
recommendation
in
texas
says:
you
know
if
you
have
a
psk
and
you're
using
ech,
you
may
also,
additionally,
send
a
dummy
one
and
the
outer
ech
and
the
dummy
one
being
like
it.
It's
obvious.
It's
generated
randomly.
You
know,
length,
cvd
and
so
on,
and
we
can
bike
shut
on
that
later
on.
But
that's
that's
the
proposal.
So
I'm
curious
to
hear
what
folks
think
about.
G
G
Okay,
I
guess
there
are
no
objections,
we'll
just
go
out
to
pr
to
propose
that
and
move
that
forward,
and
then
we
can
discuss
particulars
in
terms
of
like
length
of
wpsk
in
the
in
the
pr.
G
G
Right
so
one
of
the
changes
in
the
energy
distribution
right
now,
which
would
be
included
in
draft
10,
basically
a
reversal
of
a
change
that
landed
long
ago
from
a
client-side
computer
config
identifier,
based
on
the
hash
that
was
negotiated
with
ech
back
to
a
server
chosen,
config
identifier,
which
is
now
a
variable
length,
architect
string.
This
issue
is
tracking
the
possibility
of
potential
to
make
this
connection.
Identifier
shorter,
you
know
length
tpd.
I
think
the
proposal
in
the
text
is
a
single
byte,
but
there's
been
you
know.
G
You
know.
I've
also
heard
like
four
bites:
eight
bites
or
just
like
keeping
it
as
is,
and
there
I
think
there
are
good
arguments
potentially
to
be
made
for
both
so
people
who
feel,
I
guess
strongly
one
way
or
the
other
about
this
issue.
I
very
much
like
to
hear
what
you
think
in
terms
of
what
we
should
do,
be
it
close
it
yeah
ecker
go
ahead.
J
Yeah
I
mean
so
I
think
I
was.
I
was
the
person
who
made
both
changes,
the
the
arbitrary
one
and
then
the
freaking
it
down
to
something
else,
one,
but
I'm
happy
to
have
a
fixed-length
thing,
but
I
think
I
think
one
bite
is
too
short,
and
I
just
think
this
is
one
of
these
things
where,
like
people
think
it's
like,
you
know,
people
think
it's
like.
Oh
we're,
never
gonna
need
it
and
then
you're
like
really
sorry
later.
So,
if
you.
J
Four
cuts:
I'm
fine,
but
like
I'm
like
not
cold,
one.
G
I
mean
four
octets
would
be
fine
for
me.
I
guess
I
I'm
just
like
there.
There
have
been
other
my
primary
objective
here
is
basically
convergence
with
other
potential.
You
know
structures
that
have
the
same
semantic
information
that
is
like.
Oh
here's,
all
the
hpk
information
that
you
might
need.
Oblivious
http
is
one
particular
proposal
which
happens
to
use
a
single
fight
right
now,
but
it'd
be
great.
G
If
these
things
could
share
the
same
code
because
there's
no
distinction
between
them
beyond
this
particular
length
right
now,
so
one
of
my
one
bite
is
fine.
For
me,
four
bytes
would
be
fine
as
well.
I
think
martin
pointed
out,
unfortunately,
he's
not
here
that
in
a
proposal
to
actually
land
this
change
that
getting
consensus
on
this
is
going
to
be
quite
challenging.
So
I
I
I
feel
like
not
everyone's
going
to
feel
strongly
about
this,
so
this
is
somewhat
of
a
bike
shed.
G
L
Hi
yeah
so
variable
length.
It
concerns
me
because
it,
the
the
variable
length
itself
becomes
another
piece
of
implementation
leakage
that
tells
you
information
that
that
we
we
don't.
It
creates
divergence
between
implementations
and
creates
more
more
leakage
about
exactly
how
the
client
and
server
are
implemented,
as
different
implementations
choose
different
lengths
and
also
it
invites
injection
of
arbitrary
information
there
that
could
be
used
in
all
sorts
of
strange
ways.
L
I
oh
and
it's
it's
all
in
clear
text
on
the
wire
right
so
like
creating
more
clear
text
is,
is
not
really
in
line
with.
I
think
the
goals
of
tls,
so
a
fixed
length
is,
is
preferable
to
me.
I
would
appreciate
a
reference
to
the
to
the
hpke
key
identifier
that
you're
talking
about
you
mean
the
oblivious
http
one.
L
G
L
L
I
do
think
we
need
to
understand
what
it
is
that
we're
talking
about
here.
Right
to
me,
the
the
fundamental
discussion
we
are
having
here
is
is
trial.
Decryption
required
for
service.
Are
servers
required
to
implement
trial,
decryption
and
we're
trying
to
make
sure
that
they
actually
do
that
or
are
we
trying
to
say
the
trial
description
is
not
required.
G
So
I
mean
I
I
I
don't
see.
G
If
we
go
for
one
bite
or
four
bytes,
a
server's
gonna
have
to
support
transcription.
Nonetheless,
most
likely-
and
I
I
find
it-
I-
I
I'm
not
seeing
right
now
how
we
could
get
around
potentially
having
like
just
that
code
path
in
the
stack.
L
So
at
four
bytes
I
think
trial
decryption
essentially
is
no
longer
required.
Basically,
you
know,
as
a
server
operator
can,
can,
can
reasonably
expect
to
be
able
to
assign
every
every
key
present
in
the
fleet
a
unique
id.
L
G
No,
I
mean
the
the
primary
motivation
was,
but
we
don't
want
more
bids
for
tracking
it
wasn't
so
much
about
trial
decryption.
But
okay.
L
So
yeah,
I
I
mean,
as
my
my
overriding
concern
really
is
about,
is
about
the
impact
on
greece
because,
with
with
one
bite,
it's
not
easy
to
tell
the
difference
between,
say,
sequential
allocation
of
keys
and
random,
randomly
identified
keys,
but
with
four
bytes
it
becomes
pretty
trivial
to
look
at
this
and
say:
well,
you
know
this
server
normally
allocates
its
keys
starting
at
one
and
go.
You
know
walking
upwards
and
your
key
is
a
random
four
four
byte
integer,
so
that
doesn't
look
like
real.
G
Would
agree,
although
it's
not
clear
to
me
that
that's
a
design
constraint,
we're
we're
trying
to
operate
under
that
is
specifically
making
it
so
that
someone
who's
looking
can't
distinguish
this
from
greece
or
non-greece
for
the
purposes
of
doing
nefarious
things
not
potentially.
G
Being
an
interop
or
a
deployment
issue
or
whatever
so
so,
yes,
it's
possible
to
you
know,
choose
your
config
identifiers
and
update
them,
rotate
them
whatever
in
the
dumb
way
such
that
they
stick
out,
but
also
note
that,
like
it's
probably
also
possible
to
see
when
a
client
is
reusing,
a
config
identifier,
regardless
of
how
the
server
chooses
it
like.
G
So,
for
example,
if
the
if
the
client
happens
to
connect
to
the
same
server
back
to
back,
it's
going
to
use
the
same
config
identifier,
whether
or
not
it's
like
it,
looks
like
a
random
byte
or
looks
like
a
random
four
bytes
or
whatever,
whereas
if
it
was
using
greece
each
time
that
would
be
in
theory
different
because
it's
randomly
chosen
assuming
that's
actually
how
you
would
spell
it
so.
L
I'm
not
sure
how
we
work
on
to
be
more
concrete.
I
think
that
we
there
are
things
we
could
do
here.
That
would
help
like,
for
example,
a
four
or
eight
byte
id
that
comes
with
a
an
instruction
that
says:
thou
shalt
generate
this
randomly
when,
when
constructing
your
ech
config,
I
think
would
be
better
for
greece
on
the
client
side,
I
think
instruction
degrees.
That
says
you
know
maybe
try
to
make
this
consistent
over
subsequent
connections
could
be
useful.
G
The
the
current
proposal
does
suggest
accept
language,
so
it's
not
just
like
you
use
a
counter.
It's
like
you
do
rejection
sampling
when
choosing
a
config
identifier,
specifically
for
the
reason
that
you
say,
although
we
can
only
like
require
servers
to
do
that,
just
ask
them
to
do
it
nicely
and
there's
probably
something
you
can
do
in
the
client
side
as
well.
It
says
yeah
be
smart
about
how
you
are.
You
know,
choosing
your
config
ids
if
you're
greasing.
G
If
this
is
something
you're
concerned
about
but
like
specifying,
that
very
clearly
seems
quite
difficult
to
do,
and
so
it's
not
clear
to
me,
especially
given
what
it
reveals
it's
worth
fighting
off,
but
but
maybe
it
is
carrick's
in
the
queue.
M
So
hopefully
people
can
hear
me,
it
seems
to
me,
like
you
know,
because
of
the
tracking
vector
there's
a
you
have
to
decide
like
where
that's
no
longer
an
issue,
and
it
seems
to
me
like
four
bytes
would
be
an
issue.
So
if
one
is
too
little
because
you
know
it's
just
not
big
enough,
you
might
need
more.
Then
why
not
two
I
mean
I
don't
know
how
you
can
quantify
like
at
what
point.
M
G
That's
my
response
to
that
would
be.
What,
basically
is
what
ecker
has
pointed
out
and
that
the
the
the
tracking
argument
doesn't
is
not
great
in
particular,
because
we
kind
of
already
assume
that
the
adversary
controls
dns
and
if
it
wanted
to
track,
we
could
just
like
vend
out
unique
ip
addresses
to
tag
specific
clients
that
way.
G
M
J
Yeah,
okay,
I
think
I'm
somewhat
persuaded
by
ben's
argument,
but
I
think
I'm
mostly
persuaded
that
like
because
this
is
largely
that
like
we
should
have
one
bite
so
well,
I
think
well,
I
think.
K
N
And
as
a
ration,
I
guess
the
alternative
would
be
a
to
keep
it
at
variable
length,
but
have
a
recommendation
that
you
should
do
one
byte
or
it's
a
concern
there,
that
that
the
that
an
attacker
controlling
dns
could
could
inject
stuff
that
they
they
then
observe
the
client
using
because
a
malicious
server
operator
has
a
bunch
of
other
ways
they
could
do.
They
could
do
things
or
could
just
not
enable
ech.
G
I
think
that's
the
crux
of
I
mean
I
don't
speak
for
acker,
but
I
think
that's
the
the
I
I
interpreted
that
to
beat,
of
course,
at
his
point
and
so
if
like,
if,
if
shortening
the
config
identifier
yields
no
concrete
benefit,
then
perhaps
I'll
do
it
at
all
and
allow
servers
to
be
flexible.
G
But
it
does
sound
like
more
people
were
in
favor
of
shorter
than
longer.
O
One
minor
thing
on
the
variable
length
stuff
is
that
it
does
give
a
pretty
large
vector
for
the
dns
to
inject
arbitrary
contents
into
the
like
bytes.
The
client
sends
over
the
wire
which
it's
not
like.
This
is
the
only
source
of
this
sort
of
thing,
but
occasionally
we've
had
issues
with
like
confusing
one
like
confusing
a
target
server
with
expecting
another
protocol
or
like
weird
stuff,
like
that.
G
Just
to
to
firmly
sort
of
make
it
concrete,
joe
or
sean,
would
you
mind
kicking
one
off,
I
think
the
hum?
Oh,
we
don't
have
virtual
home
tool
this
time.
G
A
A
A
A
All
right,
it
looks
like
the
numbers
are
starting
to
give
it
a
couple
more
seconds
here,
so
people
can
find
the
function.
A
A
Okay,
okay,
now
this
is
not
in
favor
of
one
fight.
A
A
Okay,
I
think
we're
stabilizing
on
our
results
now.
So
it
looks
like
to
me
for
not
in
favor
of
one
bite
we
had
10
in
favor
of
one
bite.
We
had
21,
so
there's
a
a
pretty
strong
leaning
towards
the
one
bite,
but
there
are
still
some
folks
who
are
uncomfortable
with
that.
G
It's
not
surprising,
this
is,
this
is
sort
of
an
epic
bike
show
in
a
way.
F
G
I
will,
I
will
note
the
results
of
the
poll
in
the
issue
and
I
will
drop
to
pr
accordingly.
A
G
Yes,
sorry
so
I
filed
this
issue
a
while
back
this
is
this
is
sort
of
also
a
bike
chat.
But
again,
when
we're
trying
to
reduce
complexity
of
things,
there
is
the
way
we're
using
hp
key
right
now
in
the
config
identifier
is
currently
wrapping
the
public
keys
that
we
get
in
configs,
with
basically
a
length
prefix
hp
was
specifically
designed
such
that
that
is
not
necessary.
G
G
The
the
the
similar
encapsulated
key
that
is
carried
inside
the
client,
hello
extension
is
also
in
practice
fixed
length,
but
making
this
fixed
length
could
complicate
trial
decryption.
So
I'm
not
sure
where
people
feel
about
this,
I'm
perfectly
happy
to
close
it,
but
just
noting
this
is
a
potential
optimization
that
we
might
do
david
go
ahead.
O
So
I
think
it's
fine
in
that
like
for
an
ecconfig
context,
if
you
don't
recognize
the
chemid,
you
may
as
well
drop
it
on
the
floor
and
likewise
with
the
client
ech
structure,
but
this
would
be
introducing
a
new
place
for
this,
whereas
previously
we
said
that
well,
if
you
don't
understand
the
version,
you
can
drop
it
on
the
floor,
but
everything
else
you
can
at
least
expect
to
parse
it.
G
P
Watson
live
cloudflare.
I
can't
remember,
but
I
thought
there's
something
where
you
don't
necessarily
have
a
length
for
a
struct
if
you
just
if,
if
all
the
fields
are
fixed,
but
maybe
that's
not
the
case,
and
I
worry
that
when
you
have
this
thing,
we
need
to
look
inside
to
see
the
length
of
the
whole
thing
and
that
might
be
a
problem
for
the
tls
wrapping
by.
I
can't
quite
remember.
J
Yeah-
and
I
think
this
one
is
actually
okay
in
that
respect,
because
as
far
if
I'm
reading
this
this
language
correctly,
the
ech
config
has
exactly
one
hp,
hpk,
config
and
and
the
ech
config
itself
has
length
version.
So
you
can
skip
past
the
ech
config
like
well,
I'm
I'm
sort
of
like
the
on
this
either
way.
I
mean,
I
think,
like
I
understand
why
people
want
to
do
it,
but
it's
honestly
actually
harder
to
like
it's.
B
G
G
Thanks
sean
yeah,
I
I'm
perfectly
fine
with
that.
Why
don't
we
just
close
this
and
move
on
then
and
implementing
this
elsewhere,
that
you
know
that
chem
table
dependency
was
kind
of
annoying.
So,
if
folks
want
to
use
general
purpose,
parsers
to
you,
know
parse
these
configs.
That's
that's
reasonable!
So
I'll
note
this
and
close
the
issue.
G
Right
so
david,
I
don't
want
to
speak
for
you,
but
we
filed
this
issue
to
just
sort
of
now
we're
using
it
to
track
all
sorts
of
interesting
dos
factors
and
processing,
client,
hellos
and
outer
extensions
and
whatnot.
We
did
land
some
texts
to
address
one
of
the
particular
mitigations
and
that
mistakenly
closed
the
issue,
but
we
opened
it
back
up.
I
guess
the
question
for
the
group
here
is:
to
what
extent
do
we
want
to
either?
G
Maybe
this
sort
of
you
know
carries
over
into
steven's
point
to
an
extent,
do
we
want
to
note
that
these
potential
factors
exist
versus
like
modify
how
the
the
compression
mechanism
thing
works
entirely
to
to
avoid
them
all
together?
So,
oh,
thank
you
so
long.
So
I'll
just
turn
over
to
the
cube.
O
Yes,
I
think
we
reopened
it
in
part,
because
there
there
was
a
second
dos
vector
that
we
forgot
to
document,
but
yeah.
The
the
current
decompression
thing
is
a
little
bit
fussy.
It
is
possible
to
implement
it
without
problems,
but
I
think
we
should
probably
like,
like
my
feeling,
is
that
if
we
can
come
up
with
a
simpler
thing
that
still
meets
our
goals,
then
we
should
switch
to
that.
O
And
but
until
we
do
that,
we
should
go
and
document
the
the
couple
of
tricky
points,
and
I
think
we
documented
one
of
them
and
then
we
realized
there
was
a
second
one.
So
hopefully
we
can
go
document
that
too.
G
That's
my
impression
as
well
stephen.
H
Yeah
I
mean,
I
guess,
there's
in
addition
to
what
was
said.
G
That's
just
dropping
the
the
outer
extension
compression
mechanism
entirely.
I
G
Great,
I
mean
yeah,
it's
a
reasonable
proposal.
I
think
we
should
just
it
might
be
worth
them
to
see
where
people
stand
on.
H
H
G
Thanks
go
ahead.
M
If
you
want
to
discuss
this
now,
but
just
it
doesn't
seem
necessary
to
me
to
just
throw
out
the
outer
extensions
thing
completely.
G
Thanks
yeah,
I
I
I
given
the
interest
of
time.
So,
yes,
we
just
take
this
to
a
list
steven.
Would
you
mind
just
spinning
up
like
a
new
thread
specifically
for
this
issue
on
proposing
dropping
this
just
so,
we
can
track
that
outside
of
the
the
longer
thread
that
you
have.
G
Yeah
sure
excellent
thanks
all
right,
so
I
guess
then,
for
this
particular
issue.
While
we
sort
out
the
you
know
whether
or
not
this
thing
should
exist
at
all,
we
can
just
make
sure
we
note
the
other
vectors
that
exist
and
then
close
this
one
accordingly,
okay,
so
the
the
last
one
not
for
review
just
pinning
it
here
for
people
to
look
at
this
is
the
the
whopper
the
hr
issue.
K
G
To
do
is
start
meeting
a
bit
more
regularly
with
regular
interims,
specifically
for
ech
between
now
and
111,
with
the
primary,
with
primarily
with
the
the
sole
purpose
of
resolving
the
hr
issue
and
getting
sort
of
the
spec
feature
complete
and
then
potentially
trying
to
you
know,
get
rid
of
any
necessary
complexity.
If
we
have
it
so
I
I
don't
have
a,
I
guess.
A
preference
in
terms
of
cadence
biweekly
seems
pretty
reasonable
to
me
every
other
week.
G
That
is
so
what
I
would
recommend
or
propose.
We
do
just
send
out
a
dutiful
to
arrange
a
time
for
this
meeting
to
take
place,
and
then
people
who
are
available
and
interested
can
jump
in
and
we
can
drive
these
issues
into
the
ground.
B
G
Sounds
good,
so,
let's
set
up
the
duty
poll
then
to
get
that
going
and
then
we
can.
We
can
hopefully
kick
off
the
first
meeting
shortly
thereafter.
G
Okay,
stephen,
then
I'll
I'll
just
turn
it
over
to
you.
If
you
want
to
talk
about
the
issues.
H
Great
thanks
thanks
for
taking
the
time,
so
I
I
put
in
a
in
the
chat
room
I
put
in
a
link
to
the
mail
I'd
sent
to
the
list
and
I
think
the
best
thing
to
do
with
their
time
available
is
just
go
through
them
in
kind
of
reverse
order
from
the
second
last
one,
because
those
are
kind
of
quickest
towards
longest
and
hopefully
we
might
get
some
of
the
quickest,
so
the
quickest
one
is.
The
current
text
requires
the
outer
sni
to
be
the
public
name
and
has
a
must.
H
H
L
So
I
I
don't
have
to
tell
you,
but
the
must
is
there
to
support
the
fallback
mechanism
and
without
the
the
that
name
and
the
s
the
fallback
mechanism
doesn't
work.
I
think
it's
totally
reasonable
to
imagine.
There
might
be
sort
of
specialty
specialty
use
cases
where
you
don't
need
the
fallback
and
therefore
you
don't
aren't
subject
to
this
requirement,
so
I
think
we
can
probably
come
up
with
a
phrasing.
L
O
David,
this
is
a
quick
clarification.
Are
you
are?
Are
you
saying?
Are
you
talking
about?
The
client's
muscle
requirement
include
the
public
name
or
the
ser,
or
a
server
requirement
to
check
the
public
name,
because
it
sounded
like
you
were
talking
about
the
client,
which
does
have
a
must,
but
the
server.
I
don't
think
there
is
such
a
check.
There
is
such
a
requirement
right
now.
H
I'd
have
to
go.
I'd
have
to
open
I'd,
have
to
open
this
back
again
to
look,
but
I
I
just
think
the
restriction
isn't
needed.
I
don't
plan
on
implementing
it
on
the
client
or
the
server.
O
O
J
Okay,
so
thanks
to
ben
for
reminding
us
why
the
bus
is
there,
I
I
don't
see
any
way
to
get
around
having
the
mustard.
If
you
want
interoperability
for
the
client
to
send
it,
you
know
if
people
if
steven
wants
to
suggest
you
know
some
language
that
would
like
cut
out
for
people
who
have
reasons
not
to
do
it.
I
suppose
one
could
imagine
doing
that
as
long
as
it
clears
that's.
What
the
consequences
are.
J
You
know
sounds
like
nobody
thinks
we
need
the
must
check
and
if
people
may
think
it's
not
there,
so
perhaps
if
it's
there,
someone
could,
if,
even
if
you
think
it's
the
air
pressure
you
could
file
appear
to
remove
it
yeah
also,
I
I
guess
I
I
I'm
not
particularly
moved
by.
You
know
quite
nipple
that
you
could
be
feel
free
to
be
done.
H
J
But
I
think
I
understand,
but
there
are
reasons
for
it
to
be.
There.
G
In
the
interest
of
time
stephen,
I
I
just
did
a
quick
look
through
the
dock
and
I
can't
find
it
on
the
server
side.
I
can't
find
the
server
side
bust,
but
I
recommend
is
just
a
violent
issue
pointing
to
the
text
that
you
think
is
problematic
and
then
we
discuss
it
there,
but
that's
okay.
H
That's
maybe
worth
just
spending
a
minute
on
what
we
have
everybody
is.
This
is
just
too
complex,
and
I
I
would
I'd
love
to
get
us
to
agree
that
our
goal
is
to
make
it
simpler,
because
I
in
in
what
I've
seen
from
the
github
discussion,
it
tends
towards
more
complexity
and
no
apparent
focus
on
trying
to
make
it
simpler.
That
may
be
just
perception.
G
I
mean
I
can't
speak
for
everyone
else,
but
in
working
on
this
it's
been
a
distinct
design
goal
to
not
make
this
thing
more
complex
than
it
needs
to
be.
So
I
I
I
don't
know
to
say
much
more
beyond
that.
I
think.
J
I
guess
I'm
the
only
person
in
the
queue.
Yes,
I
also
think
it
should
be
simpler
and
I'm
interested
in
concrete
puzzles
to
make
it
simpler.
Like
certainly,
we
did
attempt
to
do
so,
and
I
recognize
that
things
got
more
complicated.
J
I
think
I
think
in
some
respects
the
use
of
ech
rather
than
esli
was
attempt
to
roll
up
a
bunch
of
pieces
of
complexity,
which
it
kind
of
crept
in
to
make
yes
and
I
work
the
door
it
needed
to
be
ch
so,
but,
but
I
think
the
highest
priority
is
at
work
and
do
what
it's
supposed
to
do
so
so
I
I'll
be
interested
in
brussels
if
it's
important,
consistent
with
continuing
to
work.
H
Yeah
so
I
mean,
I
think,
if
you
know
again
given
time
we're
kind
of
out
of
time,
but
if,
if
these
interim
meetings
have
a
focus
on
trying
to
keep
it
simple
or
make
it
simpler,
that,
I
think
would
be
good
and
I
think
it's
too
easy
to
with
hr,
particularly
to
try
and
end
up
with
something
that's
more
complex.
I.
G
H
I
A
Okay,
so
I
think,
are
we
wrapping
up
aph
now.
G
A
Cool
that
sounds
good
all
right,
then,
moving
on
to
our
c8446
bits,
ecker,
you
are
up.
J
I
can't
figure
out
how
to
tell
how
to
tell
which
camera
it
wants.
So
I
guess
you
will
not
have
a
video
okay
so
right
as
people
know,
a46
bits
is
just
a
minor
revision
to
j446
focused
on
cleaning
up
some
ambiguity
and
also
turning
towards
more
inclusive
language
next
slide.
J
So
I
think
I'll
I'll
I'll
get
the
I'll
I'll
get
to
the
the
end
of
this
first.
So
hopefully
we
can
close
these
issues
and
any
other
editorial
ambiguous
type
stuff
then
do
issue
some
kind
of
call
for
remaining
issues
to
make
sure
we
capture
the
ball,
because
I
want
to
do
you
know:
80
40,
84,
46,
business
and
then
I'll
issue,
a
new
draft
and
maybe
do
a
working
class
call.
J
I
I
do
think
we
probably
should
do
the
final
call
for
meeting
issues
before
you
do
working
class
classes.
I'm
sure
we'll
flesh
out
a
a
few
next
slide.
J
J
So,
as
people
may
recall,
when
we
initially
designed
the
registry
scheme
that
we
have
for
one
three
with
the
new
registry
documents,
what
we
were
trying
to
do
was
deal
with
the
fact
that
a
lot
of
people
wanted
to
register
cypher
suites
that
we
didn't
want
to
review
and
that
might
be
bad
or
might
be
good
and
we
didn't
want
to
have
the
tls
working
group
have
to
spend
a
lot
of
time
or
the
experts
reviewing
the
code
points
for
quality.
J
So
what
we
did
was
we
basically
opened
the
registers
way
up,
but
then
had
a
thing
where
you
recommend
we
had
recommended
in
a
non-recommended
column
and
recommended
basically
meant
hey.
This
is
standard
track
and
b.
We
think
it's
a
good
idea
and
not
recommended
meant
anything
other
than
those,
and
what
we're
finding
is
that
that
actually
doesn't
work
as
well
as
we're
hoping
in
a
specific
respect,
which
is
two
specific
perspectives.
K
J
The
second
is,
or
sometimes
when
those
recommendations
or
non-recommendations
be
nuanced,
so,
for
instance,
I
think
people
are
comfortable
with
ben
yeah.
I
think
I
thought
that
already
yes
ben.
That
should
happen,
so
I
I
I
think
it
already
did,
but
man
I
forgot
to
write
it
down
so
the
and
also
their
cases
like
as
with
ccm8,
where
maybe
it's
okay
in
some
circumstances,
but
not
others.
So
my
proposal
is
to
have
four
categories.
J
Not
two
there's
recommended,
which
is
what
it
currently
means
conditionally
recommended,
is
the
same
as
recommended,
except
that
it's
good
for
someone,
almost
some
limited
scope.
So
so,
like,
oh,
you
know,
a
asgcm246
would
charge.
Six
would
be
continually
recommended,
for
instance,
and
so,
like
ccm8,
maybe
will
be
conditionally
recommended
that
we
say
it's
not
good
for
generally
for
like
the
web,
but
if
the
iot
and
a
lot
of
data
around
then
it's
then
it's
conditionally
recommended,
and
you
have
to
explain
in
that
what
that
meant.
J
Dkg
asked
how
it's
supposed
to
be
annotated.
I
was
hoping
we'd
have
a
column
in
the
in
the
iana
registry,
the
not
recommended
we
mean
what
it
currently
means,
and
we
have
no
opinion
on
this
and
discourage
your
being.
I
think
it's
actively
bad
and,
like
you
shouldn't,
do
it,
but
we're
just
letting
the
coping
register
an
example
that
would
be.
These
authentication
only
said
for
suites,
which
you
know
don't
currently
meet
the
tls
security
guarantees.
J
My
proposal
would
be
so
obviously
recommending
condition
recommended
continue
to
require
working
group
support,
but
that
we'd
allow
we'd,
allow
the
experts
to
decide
between
not
recommended
and
discouraged
and
allow
them
to
put
the
registry,
the
the
external
sorry,
I'm
reading
dkg's
comments
as
well.
J
I'm
getting
confused
we'd
allow
them
to
indicate
what
the
reason
why
something
was
discouraged
was,
I
think,
there's
some
question
about
exactly
how
what
ayanna
would
be
willing
to
put
in
these
columns
and
what
and
I'm
not
quite
sure
about
that,
but
I'm
sure
we
could
sort
that
out
with
ayanna.
I'm
also
happy
by
the
way
people
seem
to
be
not
not
thrilled
about
recommended.
J
Perhaps
that
maybe
we
want
to
change,
recommend
not
recommended
to
me
something
else,
so
I'm
not
quite
sure
what
that
would
mean
no
opinion,
maybe
anyway,
but
I
think
I
think
these
four
levels
are
probably
the
right
four
levels.
So
maybe
people
can
give
us
opinions
of
whether
those
four
levels
are
are
right
and
then
we
can
discuss
the
names
we
use
for.
J
J
R
R
This
working
group
has
at
least
as
many
opinions
that
has
speakers,
maybe
even
as
many
or
more
as
it
has
participants
and
often
you
know
we're
gonna
stalemate
on
some
of
these
discussions
and
and
land
back
in
that
in
that
spot,
saying
no
opinion
makes
it
sound
like
whatever
you
can
use
it
if
you
want
to-
and
I
think
we
do
want
to
really
make
sure
that
recommended
retains
the
private
place
of
saying
this
is
fully
endorsed
by
the
working
group.
So
no
endorsement,
maybe.
S
That
I
jump
in
next
then,
okay,
it's
discouraged
strong
enough.
A
word
for
something
that
to
read
from
your
side
is
known
not
to
provide
the
rated
tls
1.3
security
guarantees.
T
Can
you
hear
me?
Yes,
okay,
so
two
things.
The
first
thing
is,
I
see
that
the
recommended
term
might
be
misleading,
so
it
might
be
good
to
rethink
that
term.
I
have
no.
I
don't
know,
I
don't
have
any
proposed
proposals
for
that
and
the
second
one.
If
we
had
different
categories,
I
I
I
think
I
am.
I
agree
with
dkg
saying
that
it
might
put
the
working
group
into
a
position
that
is
going
to
put
a
judgment
on
any
extension
or
stuff
assets
which
might
be
difficult.
J
What
we
already
have
for
anything
we've
recommended
in
it.
We
already
have
to
make
a
judgment
because
we
just
because
it
has
to
be
standard
track,
and
so
I
guess
I
figure
once
or
bother
and
make
a
standard
judgment.
We
can
probably
decide
whether
applicability
as
well.
D
So
to
just
jump
in
real
quick
as
ad
the
ayana
experts
have
to
be
involved
in,
like
any
code
point
allocation,
and
so
what
we
would
be
doing
here
is
to
be
writing
rules
about,
like
which
code
points
the
experts
can
approve
for
what
and
if
there's
like
some
state
transition
that
we
would
have
to
come
to
the
working
group
and
do
that.
D
J
I
thought
that
the
ian
experts
were
not
involved
in
the
working
development.
D
J
J
K
So
yeah
as
one
of
the
experts
we're
designated
the,
I
think,
the
the
above
the
line
and
below
the
line
in
terms
of
working
group
and
non-working
group
involvement
makes
a
lot
of
sense.
I
noticed
I
know
that,
generally,
we
have
deferred
to
cfrg
when
we
were
looking
for
algorithms.
So
presumably
the
working
group
would
also
want
to
still
do
that
and
I'm
guessing
that
the
where
it
says
at
the
bottom
known
to
not
provide
the
the
rated
tls-130
security
when
tls,
2.0
or
2012.
K
J
J
U
Hi
is
the
audio
working?
Yes,
okay,
yeah,
just
a
really
quick
thought
and
probably
a
naive
one,
but
I
mean
we
have
rfc
2119
and
that
sets
out
may
and
should.
Are
we
just
trying
to
reinvent
that
here
and
how
do
other
specifications
that
include
may
and
should
qualify
the
options
within
those
those
terms
I
mean
we
must
have
run
into
this
before
in
other
specs.
B
J
B
So
I
think
it's
not
your
problem,
but
I
think
the
problem
you've
identified
as
an
actual
problem,
because
we've
had
this
problem
where
basically,
like
the
discouraged
use
case
now,
people
are
claiming
that,
like
the
tls
working
group
is
uninviting
and
not
helpful
and
you
know
close
cabal,
etc.
So
we
have
to
figure
out
some
way
to
be
able
to
signify
these
things
that
you,
you
can
run
this
protocol
in
any
in
any
way.
You
see,
fear
right.
B
Some
are
more
secure
than
others,
and
this
is
just
one
way
for
us
to
kind
of
put
a
slant
on
it.
I
don't
have
any
problem
with
trying
to
come
up
with
four
categories
and
naming
them
or
numbering
them,
or
giving
them
colors
or
something,
but
we
have
to
come
up
with
some
better
way
for,
for
things
to,
you
know,
be
categorized
essentially.
H
J
J
Okay,
next
issue
12
12.,
so
I
suppose
that
we
have
a
sort
of
general
alert
which
basically
means
something
went
wrong.
People
sometimes
think
internal
error
works
for
that.
J
That's
not
internal
errors
for
until
errors
for
like
I
am
screwed
up,
as
opposed
to
you
sent
me
something
I
don't
like,
and
the
idea
was
that
you
could
just
like
always
emit
like
error
instead
of
instead
of
having
to
admit
the
specific
error,
there's
also
some
opposition
to
this
from
for
some
people,
but
my
proposal
is
that
we
define
something
at
the
main
level
and
say
you
should
send
something
more
specific
if
you
can,
which
has
the
you
know,
unique
benefits
for
the
difference
between
everybody.
J
J
D
Yeah,
banking,
no
hats-
I
mean,
I
think
in
general,
there
is
some
value
to
allowing
implementations
to
be
as
black
box
as
they
can
and
just
always
emit
the
single
error
or
no
error
signal.
So
I
think
there's
probably
enough
use
case
here
to
put
in
the
general.
D
J
Hearing
no
other
real
objections.
Maybe
someone
could
note
this
in
the
issue.
J
Okay,
so
the
current
texture,
my
user
cancelled,
is
pretty
confusing,
and
actually
I
know
david
benjamin
is
here,
so
I'm
really
hoping
he
can
help
just
letting
this.
I
know
people
send
user
cancelled,
and
so
you
shouldn't
be
treating
it
as
a
fatal
alert.
I
think
the
text
doesn't
quite
say
that
it
seems
there
are
two
not
two
options
here
on
the
other
side,
one
is
to
ignore
it,
and
the
other
is
to
treat
as
different
and
just
like.
J
It's
pretend
it
wasn't
sent
and
they're
just
reading
the
alias
for
close
notify
like
as
in
it's
a
you
know.
This
is
it's
so
what
we
know
is
some
implementation
send
these
are
canceled
and
then
close,
notify
david.
What
I
don't
know
is:
do
we
ever
send
user
cancelled
and
then
a
bunch
of
crap
and
then
close
it
on
fire?
They
just
send
them
a
succession,
because
if
it's
the
latter,
then
probably
you
could
just
like
always
tweet
it
before
it
was
closed
out
of
five.
O
I
don't
believe
they
send
anything
in
between
the
two
alerts,
but
I
might
still
suggest
doing
ignoring
because
if
you
like
one
of
the
use
cases,
I've
never
seen
a
protocol
that
does
this
but
closed.
O
Notify
is
supposed
to
signal
that,
like
nothing
comes
after
this,
but
something
does
actually
come
after
it,
and
so,
if
you
like,
like
stop
speaking
tls
but
then
reuse
the
transport
for
something
else,
which
I
think
closed
notify
was
supposed
to
support,
then
you
might
be
a
little
bit
sad
if
we
like
terminated
slightly
early
ignoring
it
also
matches
what
I
think.
Every
implementation
that
I
know
of.
J
So
right
so,
as
I
understand
I
I
see
see
so
and
user
cancel
does
mean,
as
I
recall
like
the
handshake,
it
failed
and
we're
not
gonna
we're
not
gonna
complete
the
handshake
for
you.
O
Yeah,
the
implementations
that
are
sending
user
cancelled
are
like
entirely
violating
the
spec
they're,
sending
it
after
the
handshake
fails
as
they
like
right.
This
came
about
because
we
got
rid
of
the
we
made
shutdown
unidirectional
rather
than
bi-directional,
to
match
tcp
and
they're
using
this
as
a
like
funniest
signal
to
the
same
orientation.
On
the
other
side
that
like
oh,
I
want
you
to
do
the
old
behavior.
J
J
Okay,
so
actually,
I
think
we're
basically
done
with
this.
There
were
some
there's
some
question
out
of
the
other.
Unsolicited
extensions
text
is
clear
enough
for
extensions
that,
like
are
just
indications
that
don't
have
responses,
but
I
think
we
touched
budget
which
discussion
they
have
issue
and,
as
far
as
I
can
tell,
jonathan
does
not
think
that
we
actually
need
to
leave
this
open.
Merely
the
test
wasn't
clear,
so
I
submitted
a
pr
to
make
the
text
clear.
J
J
B
B
J
O
It's
not
so
much
a
conflict
in
the
text,
it's
the.
If,
there's
an
if
you
don't
say
an
extension
in
hr,
then
the
client
is
obligated
to
send
it,
as
is
which
is
kind
of
annoying
and
probably
was
the
wrong
decision.
At
least
the
current
thinking
for
eck
or
amongst
some
of
us
has
like
not
been
confirmed
or
anything
would
avoid
this
issue.
I
do
think
it
seemed
like
from
the
last
meeting
that
we
generally
believed
that
the
current
text
was
a
mistake.
O
J
Strictly,
I'm
not
sure,
I'm
not
sure
I
understand
as
well
before
I
discuss
it
now.
Dude,
do
you
mind
filing
a
specific
issue
on
the
specs
so
that
we
can
talk
about
it?
Yeah,
that's
good
I'll.
Do.
T
That
daniel
yeah,
I'm
just
wondering
I
remember
we
raised
a
few
errors
some
time
and
I'm
wondering.
T
These
minor
issues.
J
Yes,
I
went
through
every
erotum
and
and
and
either
filed
issues
for
all
of
them
and
then
either
addressed
them
or
or
declined
to
rush
them.
You
can
find
that
in
the
github
in
the
in
the
in
the
github
errata
a
circuit
hub
issue
list.
So
you
know,
if
you
disagree,
my
treatment
is
one
of
their
so
like
you
should
be
able
to
figure
this
out.
But
if
you
disagree
with
iran,
please
fly
it
to
me.
J
I
mean
I
mean
there's
like
there's
like
there's
like
30
of
them
so
like
you
could
just
go
through.
Like
I
said
I
I
I
I
did
clear
these
with
it
with
the
chairs,
so
so
I
our
earliest
chris
they're
working
together.
So
I
think
there
was
like
no
one
was
like
thoughtfully
wrong.
Anything
was
at
all
controversial.
I
tried
to,
like
I
tried
to.
I
tried
to
jack
up
to
a
to
a
real
shitty
disgust.
T
D
Thanks
hi,
this
is
ben
again.
I
guess
I
have
two
points
now,
one
in
response
to
the
errata
question.
So
most
of
the
errata
are
still
in
the
state
reported,
and
so
I
think
when
the
document
gets
sent
to
me
for
publication
requested.
J
Call
for
my
part,
I
do
not
care
very
much
is
long
enough
to
do
as
long
as
I
just
long
enough
to
do
very
much
so
if
I
have
to
do
work,
I
definitely
am
in
favor
of
post
standards.
If
I
don't
do
work
whatever.
D
B
I
think
we
can
do
two
things
one.
We
can
point
to
the
interoperability
matrix
in
the
interoperability
report
that
the
interoperability
report
is
required.
We
can
point
to
the
interrupt
matrix,
that's
not
relevant,
oh,
but
I
mean
I
thought
you
had
to
write
something
and
you
could
just
you
could
pick
your
pain
level
and
that's
what
I'm
saying
is
like
hey.
We
did
all
this
interop
it's
over
here.
Thanks
sure.
J
All
right:
well,
I'm
gonna,
I'm
gonna
leave
this.
I
think
to
that,
given
that
it
sounds
like
the
chairs
that
didn't
work,
and
I
do
not-
I
mean
there's
other
people
yeah.
So
I'm
happy
to
I'm
happy
to
produce
a
report,
though
about
the
iran
about
how
we
handle
each
of
them.
I
can
probably
I
can
probably
like
force
github
into
producing
some
kind
of
document
which
I
can
like
like
set
up
different
site
work
on
I'm.
J
Actually
you
know
I
mean
if
I
don't
think
I'm
allowed
to
actually
do
theorata
myself
if
you
want,
so
I
thought
I
think
you're
gonna
have
to
do
it
yourself,
but
if
someone
wants
to
give
me
the
keys,
I'm
happy
to
also
from
them
yeah.
D
I
think
I
have
to
do
it
myself
and
I
somehow
thought
that
there
would
have
been
some
preliminary
version
of
this
report
that
went
by
at
some
point
like
months
ago,
but
thank
you
for
for
offering
to
put
that
together.
J
I
think
that's
I
know
it
might
be.
I
might
be
an
email
I'll
I'll
see
if
I'll
share
it
sure
thanks.
A
All
right,
then,
I
think
next
we
have
deprecating
ffbh.
M
Yeah
hi,
so
I
I'm
kirk.
I
don't
know.
Probably
most
of
you
don't
know
me,
but
together
with
nimrod
and
filippo,
I'd
like
to
propose
a
draft
that
deprecates
non-ephemeral
finite
field,
diffie-hellman's
cyber
suites
and
also
discourages
the
reuse
of
ephemeral,
ffdh,
cypher
suites
so
last
september.
If
you
can
go
to
the
next
slide,.
M
Here
we
go
so
last
september.
Some
security
researchers
disclosed
an
attack
that
they
called
the
raccoon
attack
on
tls
connections
that
use
static,
finite
field,
dippy
home
and
cypher
suites,
and
also
a
finite
field,
difficult
cipher
suites.
If
the
public
key
is
reused
and
it's
a
timing
attack
and
it
basically
uses
the
server
as
an
oracle
to
figure
out
the
premaster
secret,
you
can
go
to
the
next
slide.
M
M
So
these
already
aren't
recommended,
since
they
don't
provide
forward
secrecy
so
really
we'd
just
be,
I
guess,
prohibiting
them
to
the
extent
that
we
can
discourage
use
and
they're
already
not
recommended.
Okay
next
slide.
M
So
ecbh
is
not
vulnerable
to
the
raccoon
attack,
but
they
are
vulnerable
to
other
side
channel
attacks,
including
the
invalid
curve
attacks.
So
most
attacks
of
this
type
exploit
the
fact
that
the
server
reuses
a
public
key
and
don't
work
when
the
keys
are
fully
ephemeral.
So
we'd
like
to
take
this
opportunity
to
discourage
the
use
of
non-ephemeral
ecdh
cypher
suites
and
prohibit
the
reuse
of
ephemeral,
pcbh
keys
next
side.
Please.
M
So,
in
summary,
deprecate
ffdh
prohibit
forbid
the
the
reuse
of
ffdhe
and
ec.
That's
a
miss
of
their
dhe
keys
and
then
also
discourage
ecdh.
M
I
guess
I
don't
know
if
the
chair
do
the
chairs
lead
the
question
part.
Should
I
just
call
out
people.
V
Okay,
renee
go
ahead,
hello.
I
just
have
a
question:
isn't
this
raccoon
attack
essentially
an
attack
against
variable
size
representations
of
the
shared
key,
because
it
seems
that
you
you're
confusing
the
attack
this
the
cause
of
the
attack?
I
think
it's
due
to
the
refestation
issues
and
not
due
to
ephemeral
or
reuse
of
ephemeral,
keys.
M
V
V
That's
so
so,
so
what
I'm
kind
of
objecting
against
is
that
you
rule
out.
I
think
it's
an
important
mechanism
to
be
able,
at
least
in
some
cases,
to
reuse
some
thermal
key
material.
V
You
rule
it
out
because
of
essentially
an
implementation
or
a
specification
flaw
in
old
versions
of
tls,
where
keys
are
not
represented
in
the
fixed
way.
M
It's
only
in
tlst,
1.2
and
below,
but
I
mean
yeah
basically,
so
the
alternative
would
be
to
actually
change
the
spec
and
that
just
doesn't
seem
really
realistic
and
these
cipher
suites
aren't
recommended
anyway.
So
it
doesn't
seem
like
a
good
idea
to
change
the
spec
instead.
Well.
V
I
I
can
see,
for
example,
all
these
encrypted
client
hellos,
and
so
on
that
they
all
use
one-sided
algomal.
They
would
all
be
not
recommended
by
your.
M
Suggestion,
sorry,
I'm
not
sure
I
caught
that
that
what
would
be
recommended.
V
So
so
so,
if
you
do
a
protocol
where
you
have
a
client
talking
with
a
server
with
a
fixed
public,
key,
have
various
clients
clients
doing
doing
this
handshake.
If,
in
the,
if
this
is
a
oneplus
protocol,
then
you
could
arguably
do
this
lagoon
attack
anyway,
if
there's
a
non-fixed
representation
of
the
shared
key.
So
I
think
you
should
fix
the
problem
and
not
come
up
with
some
kind
of
focus
recommendation
that
is
much
wider
than
fixing
the
problem.
D
So
if
I
can
jump
in
renee,
it
sounds
like
you
are
wanting
to
get
clarification
as
to
the
thing
being
banned
is
specifically
like
the
tls
key
exchange
part
as
opposed
to
other
ways
in
which
you
might
use
divi
helmet
exchange
in
different
aspects
of
the
protocol.
V
Sorry,
I
I
didn't,
I
didn't
catch.
What
were
you
saying.
D
So
there's
the
the
actual
like
tls
key
exchange
in
the
handshake
and
that's
the
problematic,
because
the
stripping
of
the
leading
zeros
is
in
the
protocol
spec
and
so
the
the
question
that
I
think
is
what
you're
asking
is.
Should
we
just
be
prohibiting
that
particular
flawed
usage
of
david
hillen,
or
should
we
be
applying
these
prohibitions
to
all
places
where
we
might
use
diffie-hellman
in
the
tls
context,
regardless
of
the
handshake
key
exchange
versus
other?
You
know
encrypted
client,
hello,
sorts
of
usage.
V
V
Yes,
but
as
I
understand
it
from
this
presentation,
the
the
proposers
want
to
rule
out
the
reuse
of
an
ephemeral
key
by
sorry.
The
use
of
one-sided
ecdh.
V
I've
just
I've
just
scratched
the
raccoon
attack
here
on
a
piece
of
paper,
and
I
commented
on
it
in
the
girdle
review
of
the
last
call
of
the
cats
suite
last
week
and
did
this.
This
is
definitely
a
out
a
very
large
class
of
applications
of
the
difficult
scheme
without
a
reason,
without
solid
reason.
M
Well,
maybe
we
should
take
that
debate
to
the
list
and
ecker
do
you
want
to
go
next.
J
Yeah,
I
mean
so,
are
they
taking
a
step
back?
You
know
in
general,
like
long-term
difficulties
are
like
harder
to
use
right.
You
know
the
the
raccoon
is
there's
a
specific
class
of
a
specific
is
a
general
class
of
oracle
type
attacks
on
on
the
on
them.
Nevertheless,
you
know
we
do
and
of
course
they
don't
offer
pfs.
In
many
scenarios,
though,
not
not
every
scenario,
for
instance,
opt
ls
does
offer,
you
know,
does
rpfs,
because
it
has
a
secondary
home
exchange.
J
So
you
know
in
general,
some
care
has
to
be
taken
to
you
when
you're
using
any
kind
of
laundry
filming
key
with
that
said,
I
think,
as
rene
is
pointing
out
we're
not
going
to
get
away
from
like
having
long-term
to
film
keys
being
used
for
encryption,
because
we
have
too
many
things
that
need
them
a
lot
hpke
or
somebody's
attitude
and
tls
so
we're
going
to.
We
will
have
to
face
that
at
some
point.
J
I
think
that
the
the
the
the
financial
part
of
this,
I
think,
is
good
and
I
think
we
should.
I
think
we
should
definitely
do
it.
The
the.
I
also
think
that
the
forbidding
the
static
on
diffie,
hellman,
electrocuted
home
is
also
good.
I
think
that
the
I'm
a
little
less
a
little
more
iffy
on
the
prohibiting
reuse
of
ecdhe
keys.
We
for
two
reasons
one
I
know
there
are.
J
I
know
they're
stacks
which
already
do
this,
and
so
you
should.
You
won't
be
able
to
check
it
on
the
client
and
also
just
generally,
so
I
think
you
know
this
maybe
should
be
achievable.
Obviously,
rather
than
muscle
brushes.
M
J
This
terminological
question
turns
out
to
be
quite
fraught,
as
I
recall,
I'm
just,
but
I'm
just
telling
you
there
are
stats
before
you
use
them.
M
Okay,
watson
go.
P
Ahead,
so
I'm
looking
at
the
draft
and
it
all
it
does-
is
prohibit
a
certain
name
class
of
cypher
suites,
and
if
we
were
to
fix
the
cipher
suites,
we
would
have
to
introduce
new
numbers,
because
otherwise
we
have
an
interoperability
issue.
So
I
think
that
we
don't
have
that.
There's
no
way
to
get
around
this.
We
have
to
ban
these.
With
regards
to
the
reuse
of
ecdhe
keys,
I
don't
think
there's
a
much
of
a
problem
with
re.
P
P
M
Okay
looks
like
we'll
continue
discussing
this
and
I'll
hand
it
back
to
the
chairs.
A
Okay,
thanks
kirk,
let's
move
on
to,
I
think
our
next
was
p-o-s-p-o-k.
W
Hey
joe,
I
think
this
is
the
the
later
version
of
the
slide
director
john
uploaded.
A
W
Okay,
excuse
some
context
here,
so
this
this
is
presented
at
immune
109
and
the
goal
here
is
to
reuse
some
of
the
mechanisms
that
are
used
by
the
wi-fi
alliance
device
provisioning
profile
and
then
use
them
for
a
wired
for
a
wired
device
to
go
onto
the
next.
W
W
Some
context,
wi-fi
alliance
tpp
protocol,
defines
how
a
supplement
bootstrap
keypair
can
be
used
to
boost
traffic
against
wi-fi
network.
It
gives
a
guarantee
to
the
to
the
subsequent
through
the
device
that
it's
connecting
to
a
network.
That
knows
boosts
your
public
key
and
it
gives
a
guarantee
to
the
network
that
the
device
that's
connecting
is
the
whole
draft
associated
private
key
dpp
defines
a
format
for
the
booster
public
key.
It's
encoded
using
an
asn1
sequence
from
rfc
5280.
W
It's
a
rocky
pair
doesn't
necessarily
have
to
be
part
of
a
and
it
may
be
static
and
embedded
in
the
supplicant.
It
may
be
printed
on
the
qr
label
or
including
the
bom
equator,
or
could
be
generally
again
written
if
the
supplicant
has
a
mechanism
for
generating
and
displaying
a
bootstrap
key.
So
the
boost
repeats
a
public
private
key
pair
and
the
public
keys
is
provisioned
on
the
network.
W
And
so
we
want
to
reuse
the
same
bootstrap
public,
private,
key
pair
mechanism
to
enable
the
device
to
secure
the
bootstrap
against
a
wired
network
using
etls
by
tls
extension,
and
we
want
to
reuse
the
same
dpp
and
bootstrap
key
format,
which
means
that
if
a
device
has
a
dpp
key,
a
bootstrap
key
provisioned
and
available
on
a
qr
code
on
a
bomb
or
whatever
the
same
exact,
same
booster
key
can
be
used.
Robot
wired
and
a
wi-fi
bootstrap
next
slide.
W
So
outline
the
dpp,
the
public
booster
keys
provision,
the
dpp
configurator
and
the
configurator.
It's
typically
a
mobile
app
for
the
dpp
use
case,
but
it
could
also
be
embedded
in
a
wi-fi
access.
Point
proof
of
knowledge
takes
place
by
tiffy
helmand,
using
the
booster
key
and
the
configurators
ephemeral
key,
and
so
the
subsequent
proves
that
it
knows
the
private
key.
W
So
what
we
want
to
do
is
reuse
the
dpp
booster
keypad
for
wired
lan
use
cases,
so
the
public
key
of
the
booster
key
is
scanned
into
network
unknown
to
the
aaa
server
or
the
tls
server,
and
the
the
mutual
proof
that
needs
to
take
place.
W
Is
the
device
wants
to
network
to
prove
that
it
knows
it
boots
your
public
key
and
the
network
wants
the
device
to
prove
that
it
knows
the
associated
private
key
and
that's
pretty
easy
to
achieve
by
exchanging
two
sets
of
different
keys
in
the
client,
close
server
law.
So
the
standard
key
chair,
which
both
sides
generate
thermal
key
pairs
and
then
what
we
were
defining
in
this
draft
is
a
bootstrap
extension
where
the
client
sends
a
one-way
hash.
W
If
it's
publicly
to
the
server,
the
server
can
use
that
to
look
up
the
full
public
key
and
then
the
server
will
generate
a
second
firmware
key
and
exchange
at
a
framework
unit
server
law.
W
W
And
so
this
is
just
taken
straight
from
the
draft
it.
It
shows
the
tls
extensions
that
we're
defining
so
the
bootstrap
key
extension
in
decline
to
load.
What
happens?
Is
the
client
sends
a
hash
of
its
public
key
to
the
server
the
server
use
that
to
look
up
then
the
server
will
respond
with
it
with
a
ephemeral,
key
exchange
in
the
response.
W
W
So
what
that
means
is
that
if
you
have
a
supplicant
that
has
a
booster
public
key,
either
statically
embedded
in
it
or
dynamically
generated
if
the
subsequent
has
an
output
device,
then
that
booster
key
can
be
used
for
onboarding
the
device
against
about
a
wi-fi
network
using
dpp
and
against
a
wired
network
using
this
tls
proof
of
knowledge.
Extension
on
top
of
eep
next
slide.
W
W
We're
proposing
just
piggybacking
on
top
of
the
holland
key,
extend
the
key
schedule
draft
and
for
booster
key
security.
The
tls
proof
of
knowledge
has
exact
same
security.
Stance
as
dpp
would
respect
your
bootstraps
and
with
dpp.
W
If
an
attacker
knows
the
bootstrap
public
key
of
the
device
you're
trying
to
bootstrap
that
attacker
can
then
bootstrap
that
device
against
their
network.
The
same
holds
true
for
this
retailer's
proof
of
knowledge.
If
you
know
the
booster
public
key,
you
can
claim
the
device.
So
it's
exactly
the
same
posture
as
dpp
next
slide.
W
So
we
presented
this
is
emu,
109
and
those
general
and
consensus
to
progress.
This
work,
the
street
general
work
areas,
there's
some
trivial,
fearless
extensions
to
transport,
the
booster
key
identifier
and
the
extra
diffie-hellman
key
pair.
W
The
key
schedule
enhancements
the
highlands
rapture
took
care
of
that,
and
then
there
will
be
some
eep
and
deep
extensions
required
to
leverage
a
new
tls
proof
and
knowledge
handshake
and
the
open
questions
we
have
is
how
many
documents
do
we
need
to
to
close
his
work
off
with
the
holland
draft
for
the
extended
key
schedule
and
but
for
the
work
we
want
to
define
this
there's
two
major
pieces
of
work
left.
W
One
is
defining
the
tls
extensions
and
two
is
defining
exactly
how
you
leverage
those
tls
extensions
inside
in
an
eep
exchange,
and
so
should
that
be
one
document
that
falls
under
emu.
W
Should
it
be
a
short
tls
working
group
draft
that
justifies
with
this
extensions
and
those
those
are
the
open
questions
we
have
and
when
we
discussed
this
emu
the
recommendation
was
presented
tls
and
get
some
feedback
from
here.
P
So
I
I
rejoined
for
this
draft.
Okay,
go
ahead,
you're!
First,
all
right,
watson
live
cloudflare
in
case
anybody
didn't
here
all
right,
so
one.
I
do
not
think
this
draft
actually
uses
the
security
properties
of
tls
and
the
reason
I
think
that
is
tls
was
designed
assuming
the
public
key
is
public.
P
If
you
were
to
do
this
with
ecdsa
and
and
raw
public
keys
instead
of
this
funny
dh
pre-handshake
thing,
it
would
be
totally
broken
because
any
attacker
could
look
at
the
at
the
east
at
the
easy
dsa
signature
recompute,
the
public
key.
So
clearly
it
doesn't
compose
that
way,
and
so
now
you
have
to
answer
a
security
question.
Okay,
well
did
what?
How
do
you
preserve
that
property
when
you're
composing
it
with
tls,
which
wasn't
designed.
P
P
W
Okay,
I
need
to
think
about
that
because
well
we're
just
trying
to
mimic
exactly
what
dpp
does,
which
is
the
network
proves
to
the
server
sorry,
the
network
proves
the
device
that
knows
the
public
key
to
boost
your
public
key
without
them
to
boost
your
public
key,
transmitting
clear
text
over
the
over
the
wire
from
the
client
to
the
server
we're
not
really
trying
to
use
digital
signatures
over
that
public
key
at
all,
and
this
is
kind
of
independent
of
independent
of.
W
J
So
I'm
not
like
persuaded
that
this
has
the
same
security
properties
as
tls
at
all,
in
particular.
Those
tls,
always,
I
think,
is
the
server
and
the
fact
that
you're,
not
authentic
in
the
server
strategy
is
having
some
like,
like
I'm,
not
sure
how
to
reason
about
that
at
all
and
as
watson
suggests,
you
know
this
also
is
is
weirdly
not
not
generically
impossible.
So
I
guess
I'd
like
to
unders.
J
I
I
bend
beneath
says
you
know,
you
know
we
don't
in
the
chat
about
like
we
don't
really
haven't,
haven't
analyzed
dpp
either.
So
I'd
like
to
understand
the
requirements,
but
in
particular,
do
you
have
to
use
exactly
the
same
keying
material
which
you're
personally
using
or
can
we
have
a
different
set
of
key
material,
so
in
email
I
suggested,
for
instance,
having
a
separate
pre-shared
key
and
as
well
as
the
the
the
clients
keeper
is
that
imperative.
W
J
W
So
this
so
dpp
gpp
allows
the
proof
to
happen
in
both
directions,
but
this
draft
is
just
it's.
The
the
the
the
client
is
just
trying
to.
J
W
J
I
mean
that
the
the
the
core,
the
core
design
of
this
mechanism,
is
that
this
the
cord
is
the
tls
is
designed
to
have
mandatory
server,
authentication,
optional,
client,
authentication
and
you're
inverting
that
you're
inverting,
those
invariants
and
you're,
creating
you're
and
you're,
creating
mandatory
client
authentication,
optional,
server,
authentication,
and
that
is
the
and
that
is
the
course
of
the
source
of
the
disruption
in
the
requested,
distilled
state
machine.
J
And
so
so
the
question
I'm
asking
is:
okay,
if
you,
if
you
invert
that,
if
you
invert
those
and
have
the
person
who
is
the
person
authenticating
be
be
the
supplicant,
then
that
then
it
will
work
much
better
than
the
tail
state
machine
and
the
other
and
their
branch
is
all
the
problem.
W
Well,
that
well,
okay,
so
that
seems
kind
of
that
seems
kind
of
strange
as
well,
though,
in
that
the
the
the
client
who's
trying
to
connect
to
the
network
is
going
to
turn
around
to
be
the
server
for
the
purpose
of
this
exchange
and
the
client
will
advertise
something
to
the
network.
And
then
the
network
will
turn
around
and
initiate
a
tls
handshake
with
the
client.
J
So
I
mean
there's
a
bunch
of
the
pad
about
exactly
what's
happening
in
the
in
the
chat
but
like,
but
like
the
the
core
design
of
tls
is
that
the
public
keys
publicly
authentication
is
done
by
the
is
done
by
the
server
and
not
necessarily
about
the
client
and
so
you're,
not
authenticating
the
server.
You
know
the
server
is
like
if
you
look
at
your
handshake,
the
server
like
isn't
signing.
So
it's
just
like
this.
Doesn't
it's
not
really
like
exactly
the
same
number?
J
Errors
is
tls,
but
it's
not
kill
us
at
all.
Any
case
like
we're,
probably
not
going
to
resolve
this
here.
So
let
me
just
take
a
step
back
which
is
like
this
is
nowhere
near
ready
for
adoption.
What
we
need
is
a
clear.
J
Of
the
actual
requirements,
so
we
can
actually
try
to
design
something
that
like
works
with
tls
and
doesn't
like
just
like,
like
close
date
machine
so
not.
B
X
Just
with
respect
to
the
security
properties,
I
I
actually
agree
with
ecker's
analysis
that
watson's
that
the
secret
public
key
changes
things,
but
the
the
purpose
of
the
draft
this
is
based
on
is
such
that
it
shouldn't
be
possible
to
weaken
the
tls
guarantees,
no
matter
what
you
stick
in
there,
and
so
this
should
avoid
the
need
for
as
much
analysis
as
you
might
otherwise
think.
Y
Okay,
this
is
scott
fleur.
Basically,
one
of
the
things
is
to
note
is
that
this
is
not
this
is
this
is
a
different
use
of
cryptography
and
it
really
needs
to
undergo
some
cfrg.
C
Hi,
this
is
a
a
quick
comment,
so
I,
while
it's
not
ready
for
working
group,
last
call
yet.
I
think
this
is
useful
work
and
should
be
done
in
the
idf
and
dls
working
group
in
particular,
because
after
reading
the
dbp
specification,
I
realized
that
it.
It
basically
replicates
a
lot
of
the
the
things
in
your
dls
handshake
for
no
good
reason,
and
all
these
devices
then
have
to,
for
onboarding,
have
to
then
implement
all
sorts
of
different
protocols
which
make
it
very
difficult
on
on
lower
end
devices.
A
Thanks
for
the
presentation
owen,
I
think
there's
more
to
discuss
on
this
particular
topic
which
we'll
have
to
take
to
the
list.
So
next
up
we'll
have
opaque
and
tls.
One
three
is
sophia
on.
Q
Yes,
so
thank
you
very
much,
joseph
I'm
foreign,
allowing
me
to
speak
here
so
today
on
behalf
of
the
authors
which
are
nick
sullivan
and
christopher
wood,
I'm
going
to
present
a
draft
that
basically
aims
at
integrating
opaque
with
tls
1.3.
My
name
is
sophia
and
I'm
from
clavler.
That's
the
slide.
Please.
Q
Is
it
working?
Okay?
Oh
yes,
okay,
thank
you
so
just
to
give
a
little
bit
of
context,
so
it
is
opaque.
Q
Opaque
is
a
new
mutual
authentication
method
that
is
currently
being
standardized
by
cfrg
and
you
can
find
it
in
the
draft
that
I
have
listed
here
and,
as
I
said,
it's
a
mutual
authentication
method
that
enables
establishment
of
of
an
an
authenticated
cryptographic
key
between
a
client
and
a
server
based
on
a
user's
password
without
ever
revealing
the
password
to
servers
or
other
entities
other
than
the
client
machine,
and
the
idea
opportunities
is
basically
trying
to
solve
the
problem
that
most
of
the
time
passwords
are
stored
in
servers
and
when
the
server
gets
compromised
and
the
passwords
get
compromised
as
well
as
it
is
written
right
now,
opaque
consists
in
two
phases:
the
first
one
is
a
registration
phase
in
which,
obviously
a
user
is
registering
the
password,
but
not
the
password
server,
rather
something
generated
around
it,
and
this
is
stored
in
the
server
as
encrypted
credential.
Q
The
results
of
this
mechanism
also
generate
a
key
pair
for
the
client
and
for
the
server
as
well,
which
is
important,
because
it's
an
important
part
that
is
going
to
be
put
into
the
second
phase
of
the
protocol.
The
second
phase
of
the
protocol
is
the
authentication
preface
which
is
the
one
that
we
are
interested
in
it
today
and
basically,
the
idea
is
that,
in
the
authentication
phase,
the
client
proves
the
knowledge
of
the
password
to
the
server
and
both
client
and
the
servers
agree
on
a
mutually
authenticated
shared
secret.
Q
Next
slide,
please,
okay,
so
one
of
the
ideas
has
already
defined
a
little
bit
what
the
authentication
phase
is,
but
it
basically
consists
on
a
concurrent
oprf
mechanism
and
a
key
exchange
flow
and,
as
I
said,
one
of
the
results
of
the
registration
phase
is
that
you
were
going
to
have
a
key
pair
for
the
client
and
the
server.
So
they
didn't
in
order
to
to
achieve,
to
achieve
the
proving
of
the
knowledge
of
the
password
by
the
client
and
the
both
of
the
client
and
the
server
agree
on
a
mutually
authenticated.
Q
Shared
secret
is
to
use
tls
for
that
and
how
we
combine.
This
in
tls
is
by
less
than
two
mechanisms.
The
first
one
called
opec
sign
and
the
second
one
called
opaque
x
in
opex
sign.
Basically,
the
idea
is
to
have
it
as
part
of
the
handshake
itself
and
the
keypads
that
we've
generated
for
the
client
and
for
the
server
act
as
sign-in
keys,
and
they
are
going
to
be
used
for
the
authentication
in
the
tls
handshake.
This
mechanism
cannot
be
used
in
conjunction
with
certificate-based
authentication.
Q
If
it's
needed
to
be
used
with
in
conjunction
to
with
certificate-based
authentication,
then
it
can
be
used
as
a
post-handshake
mechanism
in
which
you
first,
you
will
have
a
tls
handshaking,
which
you
authenticated
with
a
certificate
with
a
certificate,
and
after
that
you
can
use
exported
authenticators
to
authenticate
it
with
the
password.
Q
The
second
mechanism
is
called
pickaxe
and
in
this
one
is
also
part
of
the
handshake,
but
the
keepers
that
were
generated
for
the
client
and
for
the
server
will
not
be
used
for
signing,
but
rather
they
will
be
divi
monkeys
and
the
idea
is
to
generate
a
shared
secret.
Q
The
secret
is
fed
into
the
key
schedule
for
the
handshake,
which
uses
the
certificate
based
authentication
and
establishes
the
share
key
using
difficult,
in
this
case,
there's
no
unilateral
authentication,
because
mutual
authentication
is
only
achieved
after
explicitly
processing
the
finished
messages,
and
these
two
mechanisms
are
an
extension
that
gets
advertised
in
the
clan
hello
and
all
the
messages
next
slide.
Please,
okay
and
just
to
finalize
there's
still
some
need
to
actually
look
into
the
security
privacy
considerations
that
this
extension
will
actually
have
one
of
the
pr
one
of
the
considerations.
Q
What
we're
thinking
about
in
the
privacy
perspective
is
that,
of
course,
with
this
mechanism,
the
identity
of
the
client
is
not
hidden
because
you
send
the
identity
of
the
client
as
part
of
the
extension
in
the
client,
hello
message,
and
this
could
be
a
problem
if
you're
using
this
mechanism
with
exported
authenticators.
Q
You
don't
have
this
problem
because
at
the
beginning,
you
already
have
a
tls
connection
when,
when
you're
using
this
mechanism,
you
can
further
use
something
like
encrypted
client,
hello
to
hide
the
identity,
and
if
you
want
to
look
at
the
drop
location,
it
is
found
here
with
that.
Thank
you
very
much
and
take
any
questions
or
discussions
comments.
If
there
are
any
thank
you.
D
Hi
this
has
been.
I
had
typed
this
into
the
chat,
but
if
you
could
go
back
to
slide
three,
I'm
not
sure
I
quite
understood
whether
or
not
so
it
seems
to
be
saying.
Well,
I
guess
my
real
question
is:
can
I
use
opaque
to
authenticate
the
client
using
the
password
but
then
use
the
certificate
to
authenticate
the
server
in
the
same
handshake.
Q
Q
B
So
I
like
to
get
a
sense
of
how
many
people
have
read
this
draft,
so
I'm
going
to
do
a
show
of
hands
poll
here,
because
I
think
I
figured
out
how
to
do
it.
So
let's
do.
B
B
Nope
all
right,
so
I
think
that's
probably
good.
We
had
about
seven
people
raise
their
hand
that
they
did
read
it
and
about
23
didn't
out
of
94..
I
guess
what
I
want
to
do
is
because
we've
talked
about
this.
A
couple
times
is:
make
sure
that
people
start
to
review
this
and
that
we
see
whether
or
not
the
working
group
is
going
to
be
interested
in
adopting
this
on
the.
B
B
I
believe,
if
there's
no
other,
nobody
else
wants
to
say
anything.
That's
it
for
our
session.