►
From YouTube: IETF112-TLS-20211109-1600
Description
TLS meeting session at IETF112
2021/11/09 1600
https://datatracker.ietf.org/meeting/112/proceedings/
A
A
A
A
Alrighty,
I
think
the
next
thing
is
just
a
quick
check
on
document
status.
We
have
a
number
of
things
coming
up
into
the
rfc
editor
queue.
There
are
some
drafts
that
have
been
in
this
state
in
their
various
states
for
some
significant
amounts
of
time,
usually
waiting
on
author
action
in
in
oauth
48
or
waiting
for
some
revisions.
A
A
C
C
So
again
we
got
one
comment
from
ben
and
could
basically
be
summarized
that
he
noted
the
are
there
any
security
issues
caused
by
the
fact
that
the
exported
authenticators
is
based
on
the
exporter
secret,
which
is
not
incorporate
the
entire
transcript
and
this
issue
kind
of
arose
during
the
tls
1.3
discussions
that
were
on
the
mailing
list
and
nick
basically
said:
hey
it'd,
be
great.
If
jonathan
could
look
at
this
jonathan
did
take
a
look,
he
did
an
analysis
and
proposed
two
ways
forward.
C
There's
links
there's
to
the
emails
and
the
proposal.
The
response
basically
was
like
hey.
We
could
have
security
considerations
to
address
this
or
we
can
change
how
the
exporter
works
and
what
he
proposed
was
the
security
consideration
and
that's
what
we're
going
to
review
next
and
so
we've
basically
taken
the
approach
that,
since
no
one
has
suggested
the
other
option
that
we're
gonna
go
with
this.
So
we
we,
he
proposed
some
text.
C
C
Going
once
going
twice,
I
did
note
that
martin
thompson
suggested
in
the
draft
that
the
short
answer
is
that
this
is
fine
and
that
tls
1.4
or
whatever
the
next
version
will
be
numbered,
might
want
to
include
the
entire
transcript
under
the
exporter.
Secret
watson
also
suggested
that
it
was
ready
to
go
so
with
that.
I
think
we're
going
to
go
ahead
and
go
ahead
and
get
this
merged
and
get
this
draft
done
and
get
it
in
the
rc
utter
skew.
So
thank
you
for
your
time.
E
G
G
H
H
H
So
the
only
thing
that
includes
the
client
finished
is
the
resumption
master
secret,
so
producing
a
message
that
uses
the
resumption
master
secret
first
before
you
make.
This
request,
guarantees
that
the
client
and
server
already
agree
on
the
client
finished
okay.
How
does
any
application
need
to
do
that
because
it's
a
implicit
versus
explicit
authentication
thing
once
you
send
your
first
thing
of
application
data?
H
H
E
E
E
Like
this
isn't
clear
enough
for
me
to
like
agree,
it's
just
like
ready
to
move
forward
so,
like
I
think
like
like,
I
guess
I
mean
we
have
to
go,
read
the
read
the
issue
but,
like
I
don't
think
this
text
like,
like,
I
don't
think
like.
I
guess
what
I
would
say
is.
I
don't
think
this
text
is
clear
enough
to
put
this
specification.
E
J
K
I
don't
think
I
made
that
specific
suggestion.
What
I
was
concerned
with
was
the
very
specific
set
of
rules,
specific
boundaries
that
you'd
set.
So
you
had
no,
no
I'm
just
running
off
memory.
I'm
gonna
have
to
go
and
look
at
the
draft
again,
but
there
were
specific
points
that
you
had
that
you
said
I
have
to
follow
particular
rules
now.
Flags
0
to
7,
have
to
be
out
of
the
working
group.
K
8
to
31
have
to
be
standard
track
documents
with
very
specific
conditions
on
that
and
32
to
63
are
experimental
and
and
that
sort
of
thing,
and
I
think
that
what
you
want
to
provide
is
general
guidance
to
experts
and
maybe
reserve
the
top
few
flags,
because
they're
super
super
important
or
something.
But
the
level
of
specificity
here
is
far
in
excess
of
what
I
think
is
reasonable.
J
E
I
I
basically
agree
with
martin's
guidance
which
is
like
if
we
think
that
we
I
mean
so
obvious,
obviously
like
just
we're
all
on
the
same
page.
To
restate
the
obvious,
you
know
the
resources
being
conserved
is
a
big
pile
of
zeros
at
the
front
of
the
front
of
the
flags
for
the
fly's
word,
and
so
I
grew
them
t
like
and
first
of
all,
I
guess
like
this
is
already
a
relatively
small
idea,
so
that's
a
better
shape
than
that.
E
E
Everything
else
should
be
allocated
in
sequence
right
after
that,
and
if
this
turns
out
to
be
like
a
nightmare-
and
we
have
like
a
usually
sparse
thing,
then
we
can
event
like
a
new
flags
thing
with
like
romantic
coding
for
zeros
or
something
but
but
like
I
just
like
you
know,
trying
to
spend
a
lot
of
effort
trying
to
like
optimize
down
that
last
night
or
two
I
mean
that's,
the
kind
of
thing
ctls
tries
to
do.
I
don't
think
it's
particularly
helpful
in
class.
I
mean
the
handy
is
already
quite
large.
E
J
Okay,
so
can
we
go
on
to
the
next
issue?
Okay,
so
the
next
issue
about
is
about
the
recommended
flag
well
flag
in
the
yana
registry,
so
the
recommended
flag
is
in
the
new
registry.
The
relative
flags
is
what
it
says.
Right
now
is
recommended,
which
is
either
wire
or
y
or
n
value
determined
in
the
document
defining
the
optional
feature
and
doesn't
say
really
anything
about
when
we
should,
when
it
should
be
recommended
when
the
flag
should
be
recommended
when
it
should
not.
J
L
L
L
M
E
I
think
this
column
should
look
exactly
like
the
column
for
other
extensions,
and
so
we
should
defer
this
discussion
84
47.,
and
we
want
to
just
go
especially
if
we're
saying
this,
like
whatever
the
heck
we
decide
like
the
you
know
what
it'll
be
what's
applied
here,
because
these
are,
as
you
say,
just
like
regular
extensions.
The
purpose
of
the
the
purpose
of
this
field
is
not
to
cons,
not
to
say
space
is
to
indicate
to
people
what
like
what
things,
what
things
itf
has
confidence.
E
In
one
thing,
it
does
not
have
confidence
in
and-
and
you
know,
it's
certainly
possible
to
have
a
one
bit
extension,
which
you
have
no
confidence
in
there's.
Everyone
essentially
says,
like
don't
cook
anything
like
we
have
like
very
little
confidence
and
that
would
actually
have
very
high
confidence.
It
was
bad
so,
like
I,
I
don't
really
think
it's
possible
to
have
one
bit
extensions
which,
like
we
have
an
opinion
on
positive
or
not
so
so
so
I
don't
think
that,
like.
E
C
Hey,
I
think
the
easiest
thing
to
do
is
just
reference
8447,
because
then
you
don't
have
to
worry
about
updating
it.
This
document,
if
you
end
up
deciding
to
change
the
other
values,
because
then
that
document
has
to
update
two
things.
So
it's
probably
best
just
to
point
and
then
move
on
and
just
kind
of
deal
with
it.
This
thing
will
go
in
the
rfc
editor's
queue
and
it
can
wait
for
the
best
document
which
hopefully
shouldn't
take
all
that
long
to
catch
up.
C
J
Right
so
I'll
go
to
the
last
issue,
probably
the
more
controversial
one
so
about
dtls
1.2.
So
I
can
cross
sorry,
I'm
from
butchering
your
name
opened
issue
number
13
asking
for
the
flag
extension
to
be
defined
in
dtls
1.2
as
well.
It's
already
relevant
for
tls
1.3
and
dtls
1.3.
They
want
it
for
dtls
1.2
as
well.
J
C
The
backstory
here
is
for
the
working
group
is
that
typically,
when
we
start
working
on
new
extensions,
the
default
is
that
they
apply
to
d
to
1.3
and
later
and
not
backwards.
And
then
we
have
to
kind
of
make
an
explicit
decision
to
go
back
and
try
to
support
something
that
essentially
back
port
it
to
1.2.
J
F
F
L
F
And
there's
there
is
the
conclusion:
the
corollary
is
that
all
of
the
individual
flags
are
also
1.3
only
so
if
we
start
saying
that,
okay,
the
flags
extension
itself
can
now
be
used
in
1.2,
like
is
the
scope
of
that
literally
just
the
flags
extension.
And
then
we
have
to
say
something
else
about
each
individual
flag
or
is
the
implication
that
all
of
the
flags
contained
within
it
are
also
applicable
to
tla
to
tls
and
dtls
1.2
as
well,
because
if
that's
the
case,
then
there's
a
really
severe
implementation
burden.
F
F
L
Honest
yeah
this.
For
me,
this
is
really
a
very
practical
issue
like
I
was
working
on.
The
update
of
our
implementation
for
the
cid
and,
and
also
this
our
this
return.
Routability
check
is,
is
part
of
that
story
and
we
have
the
1.2
and
the
1.3,
and
the
question
for
me
was
like:
I
have
to
provide
features
for
both
because
both
provide
this
cid
for
dtls.
L
L
And
in
general,
of
course
it
raises
the
question
of
like
what
happens
with
the
details
or
with
dls
and
details
1.2
in
general,
like
if
someone
wants
to
sort
of
define
an
extension,
and
probably
this
is
less
fewer
people
want
to
do
that,
but
it
it
will
be
out
in
the
field
for
a
while,
because
there's
it's
still
a
fine
brother
code
like
this.
It's
not
broken.
If
you
use
it
with
the
right
algorithms
in
the
right
settings,.
J
I
guess
we
could
work
around
the
complexity
of
having
the
same
extension
by
making
this
two
extensions,
one
flags
for
1.2
and
one
flags
for
1.3,
and
if
you
want
a
certain
flag
to
apply
to
both,
then
you
just
update
both
registries
and
to
add
the
flag
to
each
extension.
It's
a
bit
more
complex,
but
the
complexity
then
dies
with
1.2.
E
I
guess
I
kind
of
think
this
is
a.
This
is
a
set
of
paramedic
questions,
because
no
answer
seems
ideal.
You
know,
basically,
it
is
a
is
as
ben's
as
a
hassle
to
have
half
like
been
maybe
been
support
like
this
for
1.2
1.3.
I
I
think
if
we
were
going
to
do
that,
we
would
have
to
say
whether
it's
two
cup
points
or
one
that
the
flags
are
valid
from
one
point
two
and
not
knowledge,
one
point
three,
and
vice
versa.
E
Right
and
probably
we
shouldn't
define
any
that
are
right
home,
but
two
only
you
know
like
it's
not,
I
think,
like.
I
guess.
The
question
I
would
have
is
like
you
know
like
is
like
the
people,
the
people
who
the
people
would
like
to
have
this
from
1.2
like
how
inconvenient
is
it
to
like?
Not
have
it.
E
If
the
answer
is
like
really
inconvenient,
then
we
should
do
it
and
at
the
end,
unless
the
end,
because
because
I
already
heard
from
david
ben
and
ben
and
benjamin
kadek-
that's
like
not
that
inconvenient
to
like
implement
it's
just
kind
of
inconvenient,
and
so
I
don't
feel
that
strongly
about
it.
So
I
guess,
like
you
know
I
like
to
hear
from
honest
and
and
other
people
who
sort
of
like,
like
that.
This
is
valuable
like
like
this
is
getting.
C
Echo
to
your
point
and
that
that's
where
I
was
going
to
go
is
that
you
know.
Apparently
this
could
be
useful.
Well
like
useful,
like
how
useful
like
you're
going
to
use
it
every
time
you
you
send
a
dtls
1.2,
you
know
set
up
details,
1.2
and
handshake
or
not
so
that's
kind
of
where
I'm
I'm.
I'm
kind
of
thinking
about
this.
E
L
E
Okay,
okay,
why
can't
I
just
talk
multiples?
No,
I
can
only
share
one
okay.
That
would
have
been
awesome
so
yeah,
but
obviously
I
I'm
too
clear.
I've
heard
like
temporary
bankruptcy,
any
four
forty
six
ps
I
just
wanted
to.
I
still
plan
to
work
on
it,
but
I
I
prefer
this
meeting.
I
went
through
a
bunch
of
comments.
E
E
No,
it's
me,
isn't
it
that's
right,
okay,
yeah!
I
just
did
that.
It's
not
used
to
being
I
used
to
have
net
control,
so
the
status
of
g203
is
that
we're
all
48,
but
we've
had
two
celsium
issues
raised
that
we
thought
we
had
to
deal
with,
and
so
this
is
hoping
to
get
this
issues
out
as
fast
as
possible
and
then
get
this
out
the
door.
E
So
that
seems
like
not
it's
worth
noting
that,
like
that.
This
is
also
a
problem
with
details
1.2,
it's
just
that
we
didn't
actually
write
anything
about
about
the
key
record
limits
in
dlc
1.2,
so
we're
trying
to
be
more
rigid
about
1.3.
So
we
have
two
poles
in
front
of
us
that
both
kind
of
are
relatively
similar
one
by
chris
wood.
E
So
one
option
is
to
just
encode
the
lower
16
bits
in
the
in
the
knots,
so
the
nods
would
be
you
know
to
still
be
16
bits
of
epoch
and
48
bits
of
of
record
identifier.
So
this
obviously
requires
you
to
spend
the
act,
112
bits
to
incorporate
the
entire
epoch,
but
it's
still
the
same.
It's
still
the
same,
underlying
formatting
for
the
details
records.
So
that's
more
consistent
with
gl's
1.2.
E
The
other
option
is
to
expand
the
sequence,
number
64
bits
use
the
entire
sequence
number
and
the
knots
and
just
remove
the
epoch
entirely.
So
I
think
the
argument
that
I
think
to
try
to
argue
for
like
what
one
or
the
other,
the
argument,
I
think
for
the
235
is
it's
a
simple
change
and
and,
and
you
still
have
the
app
on
the
not
you
know
the
lower
1650
at
back
of
the
knots.
E
Well,
now
you
have
to
worry
about
cycling
around
2016.,
and
so
it's
not
going
to
actually
helps,
and
so
what
you're
really
saying
is,
and
so
we
went
to
the
analysis
we
actually
said
each
outback
has
to
have
separate
keys
and
that's
what's
giving
you
separation
between
the
epochs
not
having
that
block
bit
in
the
nonce.
So
the
argument
for
257
is
once
we
had
to
accept.
The
keys
had
to
be
separate
anyway,
which
they
already
are,
and
we
were
depending
on
that
property.
E
Then
it
didn't
matter
what
that
was
what
was
in
the
knots
and
so
and
and
so,
and
this
allows
you
to
be
to
a
have
264.
You
know
possible
sequence
numbers.
If
you
had
a
cipher
permitted
that
and
b
it
looks
more
like
t
tl's
from
point
three,
so
it
harmonizes
the
tail
some
point
three,
instead
of
being
a
special
dcls.
E
L
E
Run
by
the
255
by
karthik,
so
I
I
think
I'm
seeing
scott
flores
comments.
My
my
impression
is
because
we're
also
randomizing
we
because
we
randomized
the
sequence
numbers
we
have
the
xor
against
the
epoch.
As
martin
was
saying
yeah.
I
don't
think
that
actually
as
much
difference,
you
think
so.
I
guess
I
think
I
prefer
2d7.
I
think
that
being
closer
to
sales,
1.3
is
better
than
being
closer
to
details.
E
Okay,
then
I
will
find
287.
I
will
run
it
quickly
by
some
of
the
usual
suspects
and
we
will
call
soup
okay
next.
So
this
is
saying
this
thing
dave
benjamin
raised
that
the
because
the
dc,
so
gtl's
handshake
structure
is
different
from
the
dlc
structure
and
it
has
these
three
fields
which
are
used
for
reconstruction
of
the
handshake
of
the
firing
hand,
tape
messages,
and
so
the
question
becomes
like
and
so
like.
E
If
you
like,
ordinarily,
you
would
say
the
transcript
like
consists,
and
so,
even
when
you
reconstruct
the
messages,
what
you
do
is
you
instead
of
instead
of
basically
saying
we
didn't,
need
this
framing?
What
you
do
is
you
basically
set
the
message
question
to
be
what
it's
supposed
to
be
and
then
use
the
fragment
offset
and
the
fragment
length
to
be
like
zero
and
length
and
the
length
of
the
message
right,
and
so
so
so
these
are.
E
These
are
fixed
values,
but
they
still
go
in
the
transcript
currently
and
they
eventually
pointed
out
that
this,
like
is
a
little
weird
in
the
message
hash
that
we
use
that
we
use
for
you
know
for
hr,
and
he
also
pointed
out
that
in
this
case
it's
not
entirely
clear.
You
convince
yourself
the
tl,
0.3
and
details
1.3
transcripts,
like
don't
overlap
in
some
way,
because
this
sequence,
number
and
stuff
is
overlapping
with
message
contents.
So
I
think
david
sort
of
said
like
well.
E
This
is
just
annoying
and
grumpy,
but
we
should
like
live
with
it,
but
I
actually
am
wondering
if,
in
line
with
a
previous
thing,
we
should
just
bite
the
bullet
and
like
say
that
that
the
dtls
message
transcript
does
not
include
these,
whatever
six
eight
octets
and
then
it
would
look
the
same
as
the
tails
with
the
message
transcript,
and
so
I
I
think
you
know
like,
I
don't
think
it's
much
harder.
I
think
this
would
not
be
harder
for
us
in
any
meaningful
way.
E
E
E
I
O
O
I
originally
found
it
just
because
it
was
like
ambiguously
specified,
it
wasn't
sure
which
one
was
supposed
to
be,
but
I
guess
it's
true
that
the
only
like
by
the
time
the
only
mess
is
only
the
first
client
hello
that
ever
is
in
this
like
ambiguous
stage
so
and
at
that
point
you
haven't
even
picked
the
hash
yet
so
you
could
just
like
keep
the
clientele
around
and
just
sort
of
like
erase
the
extra
bites
as
needed.
Maybe
it's
okay.
O
E
E
C
I
I
Imagine
you
had
a
normal
tls
1.3
connection
in
which
you're
connecting
to
a
server
revealing
in
the
sni
extension,
potentially
sensitive
information
about
what
you're
doing
specifically,
what
server
you're
connecting
to
ech's
name
suggests
is
just
some
mechanism
for
encrypting
that
information
to
the
the
target
server
that
you're,
eventually
trying
to
connect
to
such
that
you
know
passive
ease,
droppers
on
the
on
the
wire
between
client
server,
can't
figure
out
any
of
that
potentially
sensitive
information
beyond
the
sni.
Other
extensions
in
the
future
might
be
sensitive.
I
Since
the
last
itf
we
sort
of
declared
drop
13
as
the
interop
and
deployment
target
to
get
some
initial
experience
to
avoid
sort
of
circling
on
issues
that
we
had
open,
particularly
around
you
know
what
is
the
right
mechanism
for
signaling
acceptance
versus
rejection?
How
do
you
deal
with
hrr
in
greece,
practically
speaking
how
you
would
implement
server-side
padding
for
the
purposes
of
hiding?
You
know
which
certificate
was
actually
chosen
for
the
particular
connection
and
there's
also
been
other
questions
around
extensibility
in
the
ech
configuration
that's
published
in
the
https
record.
I
There
are
a
number
of
implementations
out
there
right
now
bring
us
open,
ssl,
forks,
nss
and
so
on.
Some
of
these
are
interoperable
than
others.
Others
are
you
know
working
their
way
up
towards
draft
their
team,
which
is
good,
if
you
know
of
other
implementations,
request
that
you
please
add
it
to
the
wiki.
You
can
find
the
wiki
page
under
the
the
esni
or
ech
repository
on
github.
I
You
know,
for
example,
configuring
your
stack
such
that
things
from
dns
are
plumbed
into
the
the
tl
stack
accordingly
and
parsed,
and
validated
in
the
right
way
has
been
somewhat
annoying.
There's
a
there's,
the
required
text
for
checking
the
public
name
in
the
ech
config
inside
the
tls
stack,
which
requires
you
know
an
ip
address,
parser,
which
typically
was
or
previously
was
not
a
requirement
for
for
most
tls
stacks.
I
So
the
I
mean
what's
currently
in
the
draft
right
now
is,
is
not
the
best
in
terms
of
the
technical
procedure
for
validating
that
particular
ech
config.
So
it's
no
surprise
that
this
became
somewhat
of
a
pain
point
when
implementing
things.
Perhaps
we
can
do
something
in
the
future
to
fix
it,
but
you
know
something
to
be
mindful
of
if
you're
gonna
spit
up
an
implementation
of
your
own
also
been
noted
by
several
people.
I
That
split
mode
is
kind
of
challenging
to
deal
with
as
well,
not
aware
of
any
experiments
or
deployments
that
are
planning
on
using
split
loan
right
now.
But
if
there
are
folks
who
do
specifically
try
to
implement
this
use
case,
it'd
be
very
good
to
know
what
sort
of
obstacles
you
run
into
specifically
around
coordination
between
the
front
end
and
the
the
client-facing
server
and
the
back-end
server
similar
to
the
implementation.
I
I
Just
so
we
you
know
can
be
mindful
of
potentially
ways
to
simplify
the
specification
going
forward
or
you
know
areas
we
might
expand
upon,
and
you
know
the
draft
and
appendix
or
what
have
you
for
the
purposes
of
helping
implementers
similar
to
what's
in
the
rfc
8446
steven?
Did
you
have
a
question,
or
did
you
want
to
elaborate
on
anything.
P
Yeah,
just
on
the
on
the
split
board
thing
split
mode
itself
was
was
pretty
straightforward.
You
just
required
a
new
api,
but
it
was.
It
was
easy
enough.
It's
split,
node
plus
hr.
That
was
the
problem,
and
the
issue
was
with,
in
particular
with
h
a
proxy
you
either
operate
as
a
kind
of
a
tls
endpoint
in
non-split
mode
or
in
what
they
call.
P
Basically,
a
tran
you
know:
tcp
mode
is
what
they
call
it,
where
they're
trying
to
do
go
faster,
stripes,
essentially,
and
in
that
mode
they
only
look
at
the
first
packet.
So
I
don't
know,
there's
any
way
to
fix
the
issue
that
with
hr
you
have
to
change
the
second
packet
as
well
as
the
first
one,
but
on
the
other
hand
it's
presumably
when
hr
might
happen
more
often,
so
it
might
indicate
that
what
we're
doing
with
hrr
is
less
likely
to
be
of
real
interest
in
the
real
world.
P
I
Okay,
yeah
thanks
for
clarifying
no
surprise
that
hr
is
problematic.
I
guess
I
think
you
also
raised
an
interesting
point
in
that
this
was
particular
to
particular
or
to
a
specific
server
implementation.
Aj
proxy.
The
interesting
thing
to
know
is
people
are
integrating
ech
as
it
exists
in
various
tls
stacks,
like
boeing
ssr.
What
have
you
into
different
server
implementations?
I
P
Yeah,
so
you
remind
me
of
something
I
meant
to
say
there,
which
is
the
it's
not
on
the
list.
I
think
it's
on
the
wiki
page,
though,
with
coral
one
of
the
big
issues
is
going
to
be
supporting
svcp,
it's
not
ech
per
se,
that's
tricky,
it's
all
the
dns
handling
and
caching
that
might
go
around
that.
That
I
think,
would
be
a
giant
piece
of
work
for
carl.
N
I
N
I
N
N
I
If
that
matches
the
existing
parsers
that
are
present-
and
you
know
existing
dls
stacks
or
elsewhere
in
host
stacks,
so
it's
mainly,
I
guess
a
problem
of
you-
know
ensuring
parity
between
what's
available
and
what's
expected
from
the
perspective
of
vch
and,
as
you
may
recall,
trying
to
carve
out
specifically
in
language
what
is
considered
to
be
a
valid
or
not
public
name
the
world
would
be.
I
guess
a
lot
simpler
if
we
did
not
have
to
deal
with
this
ipv4
nonsense,
but
last
year
we
are.
O
So
the
the
web
with
parser
did
also
recently
change
in
a
way.
That's
actually
probably
useful
to
us,
because
we
realized
that,
if
the
the
that
you
really
want
dns
names
to
be
closed
under
a
subset
of
other
under
suffixes,
and
so
we
can
instead
simplify
our
rule
to
if
the
last
component
is
all
numeric
or
looks
like
hex
then
reject
it,
which
should
be
a
lot
simpler
than
the
like.
I
P
P
It
was
really
really
easy
to
to
upgrade
him
from
vs9
to
ech
so
and
we
got
a
drop
with
with
with
I
think
mozilla
for
about
10
and
with
boring
for
13
without
too
much
hassle,
I'm
a
cloud
player
as
well,
I'm
not
sure
what
on
13..
So
you
know,
I
think,
there's
quite
a
bit
good
news
as
well
as
red
flags,
more
good
news.
I
Yeah,
sorry,
I
didn't
mean
to
to
cast
out
on
sort
of
the
the
future
of
ech,
but
mostly
just
to
point
out
that
the
few
implementation
sharp
edges
that
have
come
up.
It
is
good
news
indeed,
that
it's
been
relatively
easy
to
upgrade
existing
servers
to
support
ech,
as
you
say,
it'd
be
great
if
this
list
was
empty,
but
you
know,
I
can't
have
it
all.
I
guess
all
right,
that's
pretty
much
it
I
I
you
know
between
now
and
I
guess
ihf
113..
I
I
guess
the
expectation
is
still
still
targeting
draft
13
for
interoperative
deployment
and,
as
you
know,
client
stack
server
stacks.
You
know
proceed
in
adding
more
support
for
this.
We
should
have
a
better,
better
picture
in
terms
of
you
know
how
deployable
ech
is
on
the
internet.
At
that
meeting,
any
questions.
I
A
Okay,
here
we
are
again
so
this
is
going
to
be
a
little
bit
of
a
re
hash
of
the
some
of
the
discussion
we
had
in
the
flags
spec.
So
in
rfc
8447
we
have
this
recommended
column
which
is
supposed
to
indicate
okay.
If
it's
yes,
then
this
is
an
extension
or
a
parameter.
That's
generally
recommended
for
an
implementation
to
support,
and
if
it's
no,
it
means
it's
not
generally
recommended
for
an
implementation
support
to
support.
A
The
feedback
that
we
got
from
here
is
that
well,
this
isn't
really
perhaps
enough
information.
You
know
n
could
mean
a
number
of
different
things
from
what
hey
we
didn't.
It
was
not
evaluated
by
us.
It
was
not
recommended
in
any
circumstances.
This
cypher
is
not
safe
at
any
speed.
Can't
you
know
you
should
should
not
use
it
or
could
mean
that
it's
only
recommended
in
specific
cases.
A
A
P
Yeah,
I
gotta,
maybe
argue
the
opposite.
I
think
the
semantics
of
no
can't
be
defined
precisely
and
therefore
has
to
be
vague,
and
I
think
we
can't
do
any
better,
really
because
sometimes
no
means
maybe
it'll
be
good
in
future
and
sometimes
no
means
we
absolutely
hate.
This
sometimes
no
means.
This
is
something
that
somebody
else
thinks
is
good,
but
we
have
no
opinion
on
if
we
try
and
get
any
more
fine
grained.
P
E
E
Yeah,
I
guess
I
guess
I'm
persuaded.
I
think
that
we
need
to
have
something
more
fancy
than
we
have
now.
I
think
that,
like
what
we
have
now
is
innovation
and
that,
like
it,
you
know
it
it.
It
avoided
us
having
to
like
spend
a
lot
of
time
evaluating
things
we
didn't
care
about,
but
I
think
it's
also
clear
people
are
confused.
I,
I
think
martin's
suggestion
is
actually
pretty
pretty
solid.
E
I
don't
care
what
things
are
called,
but
I
think
that,
like
the
like,
I
think
the
minimum
things
we
need
to
be
able
to
say
are
we're
in
favor
of
this.
We
think
this
is
bad
and
we
have
no
opinion
about
it
and
there's
many
things
we
have
to
say,
and
I
think
there's
like
room
for
here
were
some
nuanced
opinion
like
that.
E
A
J
J
Rsa
is
no
and
we're
not
saying
anything
about
the
brain
pool
curves
that
that
makes
sense,
but
for
extensions.
What
possible
extension?
Are
you
going
to
say?
No,
don't
use
that
testing,
standardize
that
we
just
added
this,
so
it
might
be
a
change
that
we
make
later
to
this
extension,
but
I
don't
see
how
we're
making
new
extensions
and
making
them
not
recommended
with
this.
With
these
semantics.
C
Answer
that
question
the
the
ones
that
have
come
up
before
typically
do
not
get
adopted
by
the
working
group,
and
then
they
go
to
the
ise
to
get
published.
But
what
I
got
on
the
queue
to
say
was
that,
instead
of
having
an
open-ended
section
where
we
could
put
it
in
this
column,
we
could
also
just
put
notes
in
the
in
the
actual
registry
and
point
so
that
there's
less
ascii
art
problems.
B
Yeah,
I
think
I
thought
I
heard
steven
say
he
was
against
having
a
no
and
I
think
we
need
that
or
when
we
have
yet
another
die
die,
die
rfc
that
says,
don't
use.
You
know
these
ciphers.
Okay,
it
wasn't
steven.
If
somebody
else
I
thought
said.
No,
I
think
notes
as
a
one
of
the
designated
experts
is
a
slippery
slope.
Where
do
we
get
the
note
text
from?
B
A
M
For
any
standards
draft,
I
think
it
would
be
good
with
a
text
column
to
complement
this.
Yes,
no
reference
that
could,
for
example,
like
explain
what
any
limitations
would
be
or,
for
example,
a
specific
use
case.
This
is
recommended
for
iot
and
so
on.
That's
similar
to
what
ipsec
is
doing
today,
at
least
in
their
drafts,
but
I
think
that
should
only
be
used
for
standards
track,
not
for
any
individual
registrations.
B
A
N
Hi
so
yeah,
then
the
concept
of
freeform
notes
seems
pretty
strange
because
it
seems
like
we
a
lot
of
the
places
where
we
want.
These
notes
are
on
ise
submissions,
and
so
we,
I
guess,
be
in
the
position
of
writing
an
ietf
standards
track
rfc.
That
adds
a
comment
to
an
entry
created
by
an
isd
commission.
It
seems
at
best
hostile
and
also
pretty
complicated.
N
N
I
think
what
might
be
most
straightforward
and
clear
would
be
to
simply
note
the
status
of
the
mining
document
in
the
registry.
So
if
we're
allowing
code
points
to
be
registered
from
documents
that
are
independent
stream
or
standards
track
or
experimental,
let's
just
have
a
column
that
tells
you
the
status
of
the
accompanying
document.
Q
So
speaking,
just
for
myself
joe,
what
I
like
about
this
is
that
it
doesn't
take
a
lot
of
itf
arcane
process
interpretation
to
parse
those
words,
even
if
we
want
to
put
a
little
more
nuance
in
it.
So
I
think
we
may
need
some
finesse
but
top
line.
I
like
the
starting
point
of
just
the
clarity
of
of
what
that
might
mean
to
someone,
that's
not
steep
in
in
an
itf
process
and
back
to
kind
of
your
comment
been
pre
that
you
previously
made
to
list
kind
of
status.
Q
A
A
A
K
So
I
think
this
is
this
is
a
good
direction.
The
the
idea
that
we
give
someone
a
con
experiment
within
the
experiment
turns
into
success,
and
then
they
have
to
pick
a
different
code
point
and
deal
with
the
deployment
come
from.
That
is,
is
kind
of
annoying
at
the
same
time,
having
the
entire
space
available
for
experimentation,
perhaps
with
a
a
process
that
streamlines
the
registration
would
be,
would
be
a
good
thing.
I
think
we
want
to
encourage
people
to
register
the
code,
points
that
they're
going
to
use
and
keep
that
as
simple
as
possible.
A
B
So
you
got
to
see
my
face.
I
don't
think
the
registration
is
overly
complex.
I
mean
sometimes
you
have
to
wait.
You
know
the
email
delay
for
one
of
the
experts
to
respond,
but
you
know
it's
only
like
a
week
or
two
in
general
and
no
experiment
that
lasts
a
year
is
really
going
to
be
offset
by
a
week.
You
can
always
pre-allocate
ask
for
a
pre-allocation.
B
A
I
Yeah
thanks
joe
that
that
that
sounds
reasonable
to
me.
I
know:
there's
been
some
discussion
about
this
on
the
list.
There's
been
interest
in
doing
this
for
sort
of
a
while.
So
I
guess
the
the
question
that
we'll
ask
the
list
is:
is
it
you
know?
What's
in
the
document
right
now,
pending
the
changes
that
were
discussed
in
the
last
15
minutes?
I
P
So
I'm
just
pulling
that
there
was
two
drafts
I
had
back
when
eth
was
esi
and
I
I'm
just
this
is
kind
of
a
heads
up
and
to
get
some
feedback.
I'm
gonna
I'm
proposing
to
maybe
refresh
these
with
a
general
substitution
of
the
smi
for
ech,
and
then
I
think
last
time
we
talked
about
this
a
couple
years
ago.
People
seemed
like
okay
with
maybe
adopting
them,
but
we
didn't
do
an
adoption
call.
So
I'd
hope
to
get
back
to
that
state.
Pretty
quick.
P
The
text
could
go
into
ech
as
an
appendix
or
something
that'd
be
fine.
The
first
one
basically
just
defines
a
pem
format
for
a
private
key
and
an
ach
config,
and
that's
really
useful
for
loading
into
a
server
when
you
want
to
have
multiple
key
keys
supported,
so
you
load
one
file
for
ech,
config
plus
private
key
pair,
and
then
you
can
load
a
whole
directory
of
them
or
do
various
things,
and
it's
just
just
a
pen
file
format.
P
The
second
one
is
a
well-known
uri
and
last
time
I
did
it,
I
found
it
very
useful
to
be
able
to
have
a
web
server,
publish
its
ech
config
so
that
a
dns
process
could
pick
it
up
and
then
publish
it
if
you're
refreshing
keys,
and
so
that
was
the
well
known
the
well-known
uri
one.
So
that's
what
I
propose
doing
I'd
love
to
get
any
feedback,
I'm
happy
to
do
that,
the
next
little
while
and
then
see
if
the
work
group
want
to
adopt
them
or
not.
E
Pam
thing
seems
seems
harmless,
but
I
don't
think
it
needs
to
be
specified
here,
it's
pen
file,
so
so
no,
I
don't
think
we
should
adopt
that.
The
other
thing
I
I
guess
I
I
don't
know
yet
until
I
know
whether
or
not
anybody
who
deploys
dns
would
be
interested
in
it.
If
they
do,
then
I
think
we
could.
Then
I
think
the
question
would
be
I'd.
E
Ask
your
ids,
where
the
appropriate
places,
because
that
could
it's
not
like
a
team
like
a
tls
thing
in
particular,
so
it's
not
clear
to
me.
It
belongs
here.
If
that's
the
case,
but
I
guess
the
question
would
be
like
I
mean
I
mean
no
particular
is
like
epp
or
something
right.
It's
like
you
know,
so
so
so
I
guess
you
know.
I
guess
I
I
would
defer.
I
guess
like
the
answer
I
try
to
give
is
like
is.
E
P
E
P
I
I
Yeah,
I
think,
if,
if
you're
able
to
spend
some
cycles
on
it,
just
updating
it,
then
we
we
can
talk
with
the
the
chairs
or
the
other.
I
can
talk
with
the
other
chairs
to
see
you
know
whether
or
not
this
is
something
we
want
to.
You
know
actively
pursue
here
or
elsewhere.
It
does
seem
like
there's
some
interest
in
at
least
the
the
well-known
draft,
whether
that's
tls
or
not.
I
I
N
I
N
N
So
what
are
we
talking
about?
We
are
talking
about
an
experimental
extension
for
ctls,
so
ctls,
that's
the
also
relatively
new,
still
an
underdevelopment
version
of
tls
that
has
a
pre-shared
template
that
the
client
and
server
somehow
agree
on
out
of
band
before
they
attempt
the
connection,
an
extension
to
that
that
makes
the
wire
image
purely
pseudorandom.
In
other
words,
it
makes
all
of
the
transport
contents
pure
pseudorandom
bytes.
N
So
this
is
possible
because
we
have
a
template
and
because
ctls
already
has
essentially
an
unpredictable
wire
format
where
the
wire
format
varies
in
arbitrary
ways,
depending
on
the
contents
of
the
template,
that's
very
different,
of
course,
from
mainline
tls,
1.2
or
1.3.
That
has
a
very
deliberately
carefully
structured
wire
image.
N
This
extension
sits
between
ctlx
and
the
transport,
so
the
transport
like
tcp
or
udp
is
not
modified
and
ctls
is
also
not
modified.
This
is
layered
between
them
with
the
goal,
basically
of
simplifying
security
analysis
right
all.
The
security
analysis
that
holds
for
tls
or
ctls
should,
for
the
most
part,
continue
to
hold.
N
N
Where,
where
one
party
causes
the
other
party
to
emit
text
on
the
mid
bytes
on
the
wire
that
are
confusing
to
a
badly
written
parser
in
the
middle,
so
that's
that's
one
for
concern.
There's
also
a
privacy
benefit
here,
because
because
each
ctls
template
results
in
a
different
wire
image,
ctls
reveals
which
template
is
in
use
normally,
but
this
extension
causes
all
ctls
templates
that
use
this
extension
to
be
indistinguishable
on
the
wire
there's.
N
N
So
the
current
model
that
we've
that
we've
specced
out
in
our
draft
is
based
on
something
called
a
strong
tweakable,
pseudo-random
permutation
or
sometimes
in
the
literature.
This
is
called
a
tweakable
super
pseudorandom
permutation
or
a
wide
block,
cipher
or
variable
input,
length,
block
cipher,
there's
a
lot
of
different
terminology
around
this,
but
it's
fundamentally
just
a
slightly
trickier
cipher
mode
like
the
usual
block,
cipher
modes
like
aes
cbc,
but
more
complicated,
and
it
gives
you
one
one
really
big
block
cipher.
N
Our
extension
takes
that
and
applies
it
to
any
tls
messages
that
are
plain
text
that
aren't
already
ciphertext
and
also
then,
to
segments
that
contain
both
the
headers,
which
are
clear
text
and
at
least
16
bytes
of
the
ciphertext.
This
is,
we
chose
this
setup
because
it
has
no
ciphertext.
Expansion
has
zero
space
overhead,
so
the
output
and
the
input
are
exactly
the
same
size
and
we
believe
and
and
hope
to
be
able
to
prove
that
it
is
still
very
highly
secure.
N
So
this
is
just
a
a
quick
outline
of
what
we're
talking
about
here.
This
is
a
typical
seat,
a
diagram
of
a
typical
ctls
stream.
So
you've
got
a
handset
handshake
message
like
a
client,
hello
that
can
be
fragmented,
especially
in
a
dtls
style
situation,
into
multiple
fragments,
handshake
fragments,
which
are
then
prefixed
with
headers
and
sent
to
the
other
party
and
then
eventually,
when
the
handshake
is
over,
the
the
bytes
that
follow
those
handshake
messages
are
aad,
ciphertext
output,
so
they're
they're
already
pseudorandom.
N
So
in
our
extension,
we
take
two
steps.
First,
we
use
this.
This
stprp
the
cipher
to
render
the
handshake
message
itself
pseudorandom
before
it's
fragmented,
I'll
note
that
this
cipher
this
sdprp
takes
a
key
and
a
tweak
tweak
is
a
little
bit
like
a
nonce,
but
we
don't
actually
require
it
to
be
non-repeating.
N
So
this
is
very
early
days.
We
are
seeking
working
group
input.
Most
importantly,
I
think,
on
the
cryptographic
construction
here,
so
we've
we've
chosen
stprp
for
this
draft,
but
there
are
a
lot
of
other
options
here
with
different
trade-offs
in
terms
of
simplicity
of
description
and
and
also
how
complicated
the
analysis
is,
especially
under
active
attack
assumptions.
N
We
do
have
some
requested
changes
to
ctls
itself,
so
I
sent
an
email
a
few
weeks
ago
with
a
bunch
of
input
based
on
based
on
this
work,
things
that
could
change
in
ctls.
That
would
make
it
clearer
in
general,
or
that
would
make
this
extension
easier
and
we
do
hope
to
pursue
working
group
adoption
at
some
point,
but
I
think
right
now.
Really.
The
question
is:
what
would
you
like
to
see
in
a
version
of
this
that
was
ready
for
adoption.
D
Yes,
I
just
I
was
just
gonna
say
I
don't
think
this
prevents
that
slipstream,
because
the
you
know
the
so
far
as
the
server
can
force.
You
know
the
server
obviously
knows
the
key
stream
and
can,
insofar
as
they
can
should
get
a
you
know,
select
what
the
client
sends
as
plain
text.
They
can
therefore
select
what
could
set
a
cipher
text,
which
is
what
you
need
for
for
that
substrate.
D
D
N
That's
that's
a
very
interesting
observation.
I
think
that
we
have
been
thinking
about
this,
principally
in
the
handshake
messages
where
there's
clear,
client
provided-
or
rather
you
know,
source
provided
entropy
each
side
is
providing
their
own
entropy
there
you're
right
that
gets
harder
in
the
in
the
body
of
the
stream.
So
we'll
have
to
give
that
some
more
thought.
Thanks
for
thanks
for
noting
that
ecker.
E
This
is
quite
fancy
and
interesting.
Those
are
independent
observations,
not
one.
So
I
mean
I'm
not
sure
I
think
of
the
not
split
screening.
I
guess
you
know.
Obviously,
if
we're
going
to
expand
the
data,
then
it's
to
remember
about
that.
This
ring,
depending
on
how
this
construction
actually
works.
It
may
be
it.
E
Then
it
may
be
the
case
that
you
have
to
essentially
iterate
through
a
large
number
of
plaintext
in
order
to
get
in
order
to
get
advertisers
of
choice,
but
I
wouldn't
be
able
to
guarantee
that
because
I
don't
understand
construction
well
enough,
so
I
guess
one
thing
I
should
a
question
about
that.
I'm
not
sure
I
understand
is:
does
this
mean
that
a
server
that,
if
a
server
supports
multiple
profiles,
it
is
then
required
to
trial
to
correct
in
order
for
which
profile
the
client
is
using.
N
N
E
N
N
N
E
E
N
E
The
thing
I
want
to
see
is,
I
would
surprise,
not
see
this
in
the
specification,
but
I
may
use
that
around
time
is
at
least
one
concrete
puzzle
for
for
the
stdrp
because,
like
when
I
would
specification
I
was
kind
of
like
we
just
don't
define
one
thanks.
I
think,
like
I'd
like
to
see
a
definition
for
one,
even
if
it
wasn't
great
I'm
gonna
now
be
honest.
I
don't
want
to
see,
but
maybe.
E
N
L
S
P
I
I
I
would
encourage
further
work
on
this.
I
think
it's
it's
interesting.
I
really
like
how
many
people
this
will
annoy.
I
would
encourage
you
to
maybe
think
about
this
as
a
way
of
kind
of
pushing
the
envelope
and
breaking
things
for
a
while
at
least,
and
you
know
see
if
you
did
all
this
and
succeeded
even
ignoring
some
of
the
security
goals.
What
would
you
break?
It
would
be
interesting
to
learn
that
and
then
last
comment
is.
P
S
S
I
I
S
I
think
that's
true.
I
think
I
think
that
we
it's
I
mean
the
the
the
very
informal
idea
is
by
tampering
with
the
the
bits
on
the
wire.
You
can't
predict
an
adversary
can't
predict
how
it
impacts,
what
is
deciphered
and
how
the
server
like
interprets
the
handshake.
So
the
idea
is
that,
like
that,
should
cause
there
with
you
know
you
can
you?
N
E
Yeah,
so
I
I
I
would
think
like
for
the
moment
it
sounds
like
it
sounds
expression's
pretty
simple,
so
I
would
just
like
pick
one
you
like
and
kind
of
like
set
a
reference
and
stuff
and
stuff
and
stuff
in
appendix
or
like
or
something
I
mean,
there's
just
like
they
need
to
complete.
Then
you
have
a
complete
specification
right.
It's
like
that.
I
put
and
then
like
I
could
just
you
know,
hold
up
loosely.
T
I
would
I,
if
you're
talking
about
which
stprp
you
want
to
use.
Well,
once
you
it's
up
to
you
to
to
decide
what
are
the
security
properties
you
need
from
it,
but
once
you
do
it
really
really
that's
what
the
cfrg
is
there
for.
You
really
should
go
to
them
and
saying
gee,
here's
what
we
need.
What
do
you
recommend.
L
I
U
U
Okay
thanks
chris,
so
today
I'm
going
to
be
talking
about
zero
knowledge.
Proofs
meets
tls,
so
I'd
like
to
well
sorry
at
first
I'd
like
to
say
that
this
is
based
on
joint
work
with
urasu
arun,
joe
bonneau
zach
de
stefano
mike
wallfish,
and
yes,
and
I'd
like
to
start
by
just
saying
that
I
think
tls
is
pretty
awesome.
U
U
So
an
example
of
these
policies
would
be
like
dns
filtering
data,
loss
prevention
and
enterprise
networks,
malware
scanning,
and
the
list
goes
on
and
on
there's
a
ton
of
these
security
network
security
policies.
So
obviously,
though,
by
design
tls
prevents
the
network
from
scanning
the
traffic
and
enforcing
these
policies.
So
this
this
this
causes
a
challenge
for
for
network
operators,
and
so
these
visibility
challenges
are
are
are
pretty
old
and
even
in
the
in
the
development
of
pls
1.3.
U
And
so
this
this
challenge
still
persists
today
and
there's
lots
of
companies
that
have
kind
of
sprung
up
to
address
these
challenges
with
tls
1.3.
So
I
googled
last
week-
and
I
found
this
extra
hop
company
that
is
talking
about
security
operations,
visibility
for
tls,
1.3
and
interestingly
also
nist.
Now
has
a
some
kind
of
working
group
that
specifically,
is
is
focused
on
finding
solutions
to
these
kind
of
visibility,
problems
with
tls
1.3.
U
U
Probably
the
most
mature
is
multi-context
tls,
which
changes
the
tls
record
layer
to
a
lot
of
different
kind
of
contexts
to
have
different
keys,
which
some
of
which
can
be
shared
with
the
network
or
or
a
middle
box,
to
allow
them
to
kind
of
enforce
policies
in
a
more
fine-grained
way,
but
directly
on
plain
text.
Other
proposals
are
like
enterprise
tls,
which
is
or
like
ets,
which
is
a
protocol,
that's
kind
of
a
variant
of
tls.
U
That
retains
some
like
some
some
properties
of
older
tls
versions
that
make
monitoring
easier,
and
there
are
lots
of
proposals
based
on
like
trusted
heart,
like
sgx,
on
the
client
or
or
in
the
network.
But
all
these
solutions
basically
focus
on
keeping
scanning
and
other
kinds
of
network
functionality
in
the
network
by
weakening
or
modifying
tls.
U
U
So,
first
I'll
talk
about
this.
This
recent
work,
but
first
I'll
give
just
a
very
quick
primer
on
zero
knowledge.
Proofs,
so
zero
knowledge
proof
is
a
cryptographic
primitive.
That's
focused
on
allowing
approver
to
convince
a
verifier
that
a
public
statement
like,
for
example,
an
arithmetic
or
a
boolean
circuit,
is
true.
So
in
the
circuit
sense,
this
would
be
that
the
this
circuit
has
a
satisfying
assignment.
U
So
the
approver
wants
to
convince
the
verifier
that
the
statement
is
true
without
revealing
why
it
knows
that
it's
it's
true,
so
zero
knowledge
proof
is,
is
a
is
a
string
like
a
bit
string
that
the
prover
generates
and
it
will
send
to
the
verifier
and
the
verifier
can
check
this
bit
string
along
with
this
public
statement,
and
by
checking
this
bit
string
it
can
it
can
gain
an
assurance
that
the
approver
knows
why
this
public
statement
is
true,
but
but
not
not.
Why
so
so?
U
The
zero
knowledge
proof
kind
of
guarantees,
the
verifier
that
the
statement
is
true
but
but
prevents
the
verifier
from
learning.
Why
the
prover
knows
it's
true.
So,
for
example,
in
the
circuit
case
this
this,
the
provers
knowledge
could
be
something
like
a
satisfying
assignment
to
this
to
the
circuit,
so
zero
knowledge,
middle
boxes
use
zero
knowledge
proofs
to
allow
network
operators
to
enforce
security
policies
on
traffic
without
decrypting
it.
U
So
this
is
this
addresses
a
lot
of
these
visibility
challenges,
especially
with
things
like
like
filtering
and
scanning
in
in
traffic.
So
the
way
zero
knowledge
middle
box
works
is
as
follows.
So,
when
a
client
first
joins
the
network,
the
the
middle
box
gives
a
description
of
the
security
policy
to
the
client.
U
Then
the
client,
when
it
wants
to
make
an
outbound
connection
to
a
server,
can
just
perform
a
normal
handshake
and
establish
a
session
key
with
that
server.
Then,
when
the
client
wants
to
send
some
traffic,
the
client
enforces
the
policy.
The
security
policy
locally
on
its
own
traffic
and
additionally
creates
a
zero-knowledge
proof
that
it
enforced
this
policy
correctly
on
its
traffic,
and
so
it
sends
the
the
encrypted
traffic
as
well
as
zero
knowledge
proof
that
the
underlying
plaintext
is
compliant
with
this
policy.
U
And
finally,
the
middlebucks
can
verify
this
proof
and
block
the
traffic
if
the
proof
verification
fails
so
just
to
make
this
setting
a
little
bit
more
concrete
I'll
explain
a
use
case
from
the
paper
that
my
co-authors
and
I
wrote
so.
The
use
case
is
filtering
dns
queries
that
are
sent
using
either
dns
over
tls
or
dns
or
https,
which
are
too
increasingly
deployed
ways
to
encrypt
dns
traffic.
U
So
how
do
we
build
these?
Your
knowledge
proofs
in
the
paper
we
describe
a
three-step
pipeline
and
in
my
talk
I
really
don't
have
time
to
go
into
it
in
too
much
detail,
but
the
this
three-step
pipeline,
the
first
step,
is
basically
a
zero-knowledge
like
a
circuit
that
can
decrypt
the
tls
1.3
records
in
in
zero
knowledge,
and
then
in
the
paper
we
describe
how
this
these
circuits
can
be
composed,
with
other
circuits
that
are
kind
of
responsible
for
checking
policy.
U
U
So
the
question
is:
how
do
we
decrypt
tls
1.3
records
in
in
zero
knowledge?
Proof?
The
most
obvious
way
to
tackle
this
is
to
just
re-run
the
record
layer
decryption
in
this
in
the
xero
north
group,
so
basically
express
record
layer
decryption
as
a
circuit
and
just
decrypt
the
encrypted
traffic
in
the
in
the
in
the
circuit.
U
So
this
means
that
a
malicious
client
could
lie
about
what
it's
putting
in
the
proof,
basically
craft,
a
cipher
text
that
has
multiple
decryptions
and
then
issue
a
zero-knowledge
proof
about
one
of
these
decryptions,
but
actually
send
a
different
one
to
the
to
the
server.
So
so
this
this
problem
of
kind
of
lying
in
the
proof
about
the
key
that
is
used
is
one
we
need
to
tackle.
U
So
the
question
really
boils
down
to:
how
do
we
build
an
efficient
zero-knowledge
key
consistency
check
for
zeal
for
tls
1.3,
and
so
because
tls
1.3
key
schedule
and
the
handshake
are
are
quite
complicated.
I
I
could
get
into
the
fine
details
here
and
I'm
sure
everybody
here
would
understand
them,
but
it
would
take
a
lot
of
time
that
I
really
don't
have.
U
So
I
would
I'll
I'll
just
skip
most
of
the
details
here,
but
I
first
would
like
to
thank
the
dowling
at
all
tls
1.3
analysis,
paper
of
like
cryptographic,
analysis
of
the
tls
1.3
handshake
for
this
incredible
diagram
of
the
tls
key
schedule,
which
I
think
is
like
this
is
like.
Maybe
the
best
diagram
I've
ever
seen
in
a
crypto
paper
but
anyway,
so
we
don't
really
have
time
to
get
into
the
details
here.
U
U
So
I'll,
just
talk
very
very
briefly
about
the
results
of
our
prototype
implementation.
We
talked.
We
used
the
xj,
smart
development
environment
and
the
graph
16,
zero
knowledge,
proof
system,
and
so
the
cost
of
this
key
consistency
check.
The
proof
generation
is
about
15
seconds,
and
so
in
the
paper
we
explained
that
this
consistency
check
really
only
has
to
be
done
once
per
tls
session,
which
ameliorates
the
high
cost
of
doing
this
somewhat,
but
it
still
is
quite
a
high
cost.
U
So
the
tldr
here
is
that
these
techniques
are
not
practical
yet,
but
they're
they're
really
really
close,
and
there
are
a
lot
of
interesting
optimizations
that
are
possible
here,
so
like,
for
example,
ongoing
work,
we're
using
a
different
zero-knowledge
proof
system
that
reduces
the
client
cost.
Here
by
about
70x,
but
there
are
some
some
caveats
here
which
I
can
get
into
if
people
are
curious-
and
I
encourage
you
if
you're
interested
in
more
of
these
numbers
or
more
context,
to
see
the
paper
online.
U
So
finally
I'll
just
conclude
with
some
general
thoughts
about
zero
knowledge,
proofs
and
and
tls.
So
whatever
people
think
of
of
this,
this
particular
research
that
my
co-authors
and
I
have
done.
I
hope
you'll
agree-
that
zero
knowledge
proofs
are
a
really
really
interesting
tool
for
lots
of
of
practical
network
security
and
privacy
problems.
N
U
Well,
the
the
glib
answer
to
your
question
is
that
tls
1.3
is
already
the
zkp
hostile
version
of
cls,
and
that
sounds
like
a
criticism
and
it's
honestly,
it's
not
a
criticism.
Tls
1.3
is
extremely
well
designed
for
the
the
use
cases
that
the
designers
envisioned,
but
the
the
like
some.
Some
of
the
reasons
why
tls
1.3
excuse
me
is
well
designed
are
also
reasons
why
it's
it's
quite
quite
hostile
to
zero
knowledge.
U
So,
for
example,
the
the
kind
of
extreme
precision
and
detail
of
the
key
schedule
is
something
that
makes
it
quite
hard
to
do:
efficiency
or
knowledge
proofs
about,
because
in
the
key
schedule,
not
only
do
you
need
to
do
a
lot
of
kind
of
hkdf
operations
hk,
you
know
you're
using
hkdf
on
a
primitive
like
like
hmac
shot
56,
which
is
like
not
zero,
knowledge
friendly,
so
shot.
56
is
extremely
expensive
to
evaluate
and
zero
knowledge
proof.
U
So
the
key
schedule
having
this
you
know
there
are
lots
of
context
hashes
and
like
like
label
inputs
and
everything,
there's
lots
of
like
the
there's
kind
of
a
hierarchy
of
keys.
This
is,
this
is
quite
quite
hard
to
do
efficiently
in
zero
knowledge
and
zero
knowledge.
Proof
yeah
yeah.
I
guess
another
thing:
well,
yeah,
yeah!
T
U
U
Is
that
there's
a
kind
of
trade-off
between
the
succinctness
of
the
proof
and
the
work
that
the
proverb
has
to
produce
it
so
we're
exploring
like
kind
of
different
trade-offs
here
like
maybe,
if
you
were,
if
you
were
able
to
accept
like
a
one
kilobyte
proof,
you
could
get
a
much
faster
proverb,
but
currently
our
prototype
is
128.
Bytes
per
proof.
P
U
P
U
U
Well,
the
the
back
end,
the
zero
knowledge
backing
that
we're
using
I
mean
exists
today
I
mean
we're
using
code
that
was
written
by
actually
like,
like
a
researcher
at
northwestern
xiao
wang.
So
the
the
70x
speed
up
is
is
the
caveat
here
is
that
there
are
other
trade-offs,
so
the
the
middle
boxes,
verification
cost
is
also
quite
a
bit
higher
in
this
in
in
the
70x
speed
up.
U
So
so
200
milliseconds
is,
you
know
quite
a
bit
faster
than
15
seconds,
of
course,
but
to
be
doing
this
on
every
packet
on
every
network
packet
is
probably
still
impractical.
So
there
are
there's
a
lot
of
research
ongoing
in
like
these
zero-knowledge
proof
systems,
and
I
think,
like
in
the
next
five
years.
I
expect
that
people
will
develop
techniques
that
kind
of
achieve
the
best
of
both
worlds,
where
you
have
kind
of
more
succinct
proofs,
but
that
are
also
faster
to
generate.
P
U
Well,
thank
you.
I
appreciate
that,
although
I
would
I
if,
if
I
can,
I
would
just
kind
of
like
to
push
back
a
little
bit
on
on
the
the
first
thing
you
said
about
visibility.
I
think
it's
it's
it's
very,
very
natural
to
oppose
like
like
efforts
towards
the
kind
of
network
visibility,
but
I
think
it's
important
to
remember
that
the
starting
point
like
if
you
are
taking
a
very
pro
privacy
standpoint.
I
think
it's
important
to
remember
that.
The
starting
point
here
is
not
tls
1.3
security
guarantees.
E
U
Yeah
yeah,
that's
a
good
question,
so
having
committing
ciphers
would
help,
however,
committing
ciphers.
They
actually
aren't
the
best
way
to
solve
this
problem.
They
are
the
way
that,
like
kind
of
in
the
past,
people
have
approached
this
and,
like
the
kind
of
receiver
wisdom
in
the
crypto
community
about
doing
verifiable
decryption.
Is
that
you
know
as
long
as
your
encryption
is
committing,
then
you
can
just
kind
of
verify
the
commitment
and
everything's
fine.
U
However,
in
this
paper,
one
of
the
interesting
things
we
found
is
that
it's
actually,
if,
if
your
sessions
are
long-lived,
it's
actually
much
more
efficient
to
do
a
one-time,
key
consistency
check
and
then,
rather
than
having
to
kind
of
check
the
commitment
in
every
ciphertext
every
time
you
do
a
proof.
So
one
thing
that
tls
could
do
is
send
as
part
of
the
handshake
a
commitment
to
the
session
keys,
even
even
just
as
an
extension
like.
U
If,
if
you,
if
you
sent
this
and
had
both
both
parties,
kind
of
check
these
commitments,
then
this
whole
key
consistency
check
this
15
second
cost
that
I
described
would
go
away
pretty
much
immediately,
because
the
handshake
would
actually
to
have
a
like.
Like
a
correctly
set
up
tls
connection,
you
would
need
to
check
a
commitment
to
the
session
key,
and
if
the
middle
box
can
extract
this,
then
they
can
just
check
subsequent
proofs
against
this
commitment
that
is
sent
by
the
client.
I
M
I
That's
our
fault,
this
chairs,
for
not
managing
the
time
better.
As
discussed
in
the
chat,
the
the
paper
was
shared
on
the
list.
So
if
you're
curious,
please
check
it
out,
be
interesting
to
see
how
things
can
be
improved
or
or
not
one
way,
the
other,
and
unless
anyone
else
has
any
burning
questions,
I
think
we
can
wrap
up
here.