►
From YouTube: IETF105-TLS-20190725-1000
Description
TLS meeting session at IETF105
2019/07/25 1000
https://datatracker.ietf.org/meeting/105/proceedings/
A
A
A
Do
we
have
a
minute
taker
birthday
Patrick?
Thank
you,
Jeff
scribe!
Oh
thank
you!
Jonathan!
All
right,
blue
sheets
are
going
around.
Please
make
sure
you
sign
them
to
reiterate
in
discussing
various
issues,
and
you
know
raising
comments.
Please
be
professional,
be
polite,
be
succinct
at
the
microphone
mistake,
your
name
to
help
the
minutes,
taker
and
jabber
scribe.
A
So
this
is
our
agenda.
First
start
off
with
a
quick
update
and
details,
1.3,
some
quick
bashing,
we're
gonna
reorganize
and
put
the
return
reach
for
bid,
I'll
check
and
the
connection
ID
draft
after
ESN
I
and
then
go
through
a
bunch
of
individual
drafts
that
had
been
brought
to
the
working
group
for
discussion.
So
we
went
through
this
earlier
this
week.
So
there's
no
change
here
and
same
so
alright,
I
guess
we
can
just
get
started
with
UTS
1.3.
There
are
no
slides
to
just
give
everyone.
A
quick
update.
A
B
Yes,
so
I
think
I
got
all
David's
issues.
There
was
like
one
editorial
issue
which
somehow
I'm
Minister
losing
can't
find
again,
but
if
someone
finds
it
I'll
fixate,
it
wasn't
major.
The
only
outstanding
technical
issue
is
that
the
question
of
whether
it
should
have
to
produce
key
separation
between
DL,
7.3
and
DTLS
1.3,
so
in
recap,
in
I,
hold
so
tell
us
what
went
to
a
details.
Remote
do,
I
do
believe,
do
not
have
key
separation
because
they
don't
include
a
transcript
in
the
hashes
in
quick.
B
What
we
did
was
we
did
key
separation,
but
not
internal
key
separation
so
that
the
internal
derivations
are
the
same
on
my
my
intuition.
Is
we
don't
need
this
reaches
1.3
because
we
hash
the
whole
transcript
for
the
transcript
will
be
different
because
all
the
version
numbers
not
different.
The
the
entire
Hammond
messages
get
Marshall
up
and
the
head
shake
messages
include
different
headers,
so
there
should
not
be
possible
these
a
detail,
some
point
through
transcript
for
a
tale,
some
point
to
be
transcript.
B
It's
also
not
entirely
clear
what
the
impact
that
would
be,
even
if
so,
even
if
the
leaf
key,
even
if
the
leaf
keys
were
the
same,
it
won't
be
possible
to
substitute
packets,
because
the
does
integrity
Church
is
different.
So
my
intuitions
don't
do
anything.
I
can't
actually
prove
that
I'm
curious.
If
people
think
about
how
they
want
to
result.
I
think
Martin
has
some
thoughts.
Resolving
we've
fairly
straightforward
yeah,
but
you
know
I
can
imagine
number
of
ways
I'm
changing
these
mention
point.
B
Changing
the
initial
see
the
initial
seed
initial
expansion
seed,
so
people
think
we
oughta
do.
Ski
separation
is
not
going
to
be
expensive
to
do,
but
I
I
think
when
we
did.
If
ur
quick,
there
were
some.
There
are
some
sadness
from
employers
about
having
to
dig
that
dig
that
deeply
their
key
schedule,
though,
that
may
be
different
with
it:
staff
which
is
well
integrate
these
guys,
as
opposed
to
quickly
kill
us
yeah.
C
So
someone
Thompson
the
concretely
the
the
difference
between
the
two
protocols.
Aside
from
maybe
the
choice
of
extensions
and
all
those
sorts
of
other
things
is
the
message:
sequence
numbers
that
we
have
in
in
the
handshake
messages
and
and
to
my
knowledge,
that's
really
the
only
thing
that
we
can
rely
on
big
difference.
That's
court!
That's
correct!
As
the
version
numbers
you
know,
that's
him
right
and
I'm,
not
especially
concerned
about
that
I.
Do
want
to
I
do
think
the
property
is,
is
important.
C
I
don't
want
someone
establishing
a
TLS
connection
on
the
assumption
that
they
have
certain
properties
head
of
that
and
then
get
DTLS
guarantees.
I
think
that
would
be
not
particularly
great
but
I
don't
see
any
anything
concretely
preventing
us
from
from
a
lie
on
the
message.
Sequence
number
stuff:
it's
doesn't
seem
that
important
how
it's
done.
Yeah.
D
C
B
Well
so
I
guess
in
that
I
mean
I'm
sort
of
like
I'm
tempted
to
be
conservative
unless
I'm,
pretty
I,
guess
the
reason
we
didn't
do
it
in
quick,
which
books
to
think
or
sad.
So
unless
someone
is
actually
sad
about
this,
which
is
to
be
conservative,
so
I
think
what
I
was
just
is
why
don't
I
go
count,
and
if
we
have
space
we
can
just
do
it
and
if
we
don't
have-
and
if
we
don't
have
space
in
the
back
and
ask,
we
can
choose
a
different
string
and.
B
B
C
A
All
right,
so
this
is
just
an
update
on
encrypted
SNI.
There
are
a
couple
major
changes
that
went
into
the
latest
version.
In
particular,
there
was
a
bug
around
how
we
deal
with
HR
and
potentially
leading
to
nonce
and
key
reuse.
So
we
fixed
that
with
the
temporary
patch
that
basically
uses
two
different
labels
when
doing
key
derivation
to
avoid
deriving
the
same
keys
and
once's
and
using
them
to
encrypt
two
different
messages.
A
A
Although
David
Benjamin
raised
an
issue
yesterday
indicating
that's
not
yet
finished,
and
not
yet
perfect,
so
there's
still
some
a
little
bit
more
work
to
be
done
there
and
we
also
move
the
DNS
extensions
out
of
the
es
and
I
key
structure
itself,
so
that
the
new
format
is
a
you
know,
a
single
structure
that
has
an
extensions
blog
for
DNS
things,
whatever
DNS
things
you
want
to
put
in
there.
That
would
be
the
address
set.
A
That's
currently
specified
or
some
other
thing
that
might
be
specified
in
a
later
drop
and
then
also
the
es
and
I
Keys
blog
next
slide.
Please,
and
then
there
are
some
minor
changes
as
well,
just
to
kind
of
clean
up
some
editorial
nits
and
improve
readability
of
the
text,
and
so
on.
So
I
encourage
you
if
you're
interested
just
check
the
diffs
for
these
thanks
please.
A
So
there
are
a
couple:
there
were
several
open
issues.
The
ones
on
the
left
are
the
ones
I'm
gonna
talk
about
today,
and
these
ones
require
some
discussion
and
potentially
some
non-trivial
changes
to
get
right.
The
ones
on
the
right
also
are
open
and
just
require
some
more
engagement
from
the
folks
here
to
sort
of
come
to
closure
as
to
what
to
do
particular
compressing
the
server
name
and
the
client
hello,
whether
or
not
that's
something
we
want
to
do.
There's
not
been
much
activity
on
that
particular
issue.
A
A
For
that
to
address
it
in
potentially
we
can
do
that
at
some
point,
or
we
just
you
know,
do
the
HP
service
record
thing
so
anyways
next
slide,
please
we're
sort
with
a
problem
that
is
existing
in
the
current
draft,
so
assume
you
had
the
the
following
topology,
where
two
servers
in
your
suppose
a
phenomenon
reset
have
different
cypress
tree
configurations
provided
or
just
enabled
for
whatever
reason
so
hosting
on
top
supports
both
AES
and
cha-cha
goes
beyond.
The
bottom
only
supports
a
yes
next
slide.
A
Please
and
then
suppose
your
client
sends
a
client
below
in
which
he
prefers
a
s
over
to
cha
and
sends
it
along
and
some
on
path,
adversary,
interception
slide,
please
and
then
swaps.
The
order
of
the
cipher
Suites
such
that
cha-cha
is
preferred.
Well
he'll
get
back
if
he
sends
this
packet
to
host
a
as
a
server
low
that
has
chosen
cha-cha,
and
if
he,
since
that
over
to
host
B,
you
will
get
back
a
server
low
that
only
or
yeah
a
server
low.
A
Right
because
the
only
thing
that
we
bind
to
the
es
monkey
extension
is
the
key
share
in
the
client,
hello
and
nothing
else,
and
so
this
simple
example
kind
of
illustrate
said:
oh,
the
cyber
sweets
must
also
be
bound
to
the
east,
my
extension,
but
it's
sort
of
perhaps
not
the
best
thing
to
the
best
approach
to
sort
of
patched
these
in
a
sort
of
piecemeal
fashion,
so
go
add
more
and
more
things
as
we
discover
they.
They
need
to
be
found.
So,
ideally,
all
non
ESI
extensions
and
content
in
the
client.
A
Hello
must
be
bound
to
the
sni
extension
and
then
we
kind
of
just
solved
this
problem
in
one
fell
swoop.
That
would
prevent
probing
based
on
modifying
any
parameters
in
the
client,
hello,
because
everything
is
bound
to
the
s
and
I
extension
and
by
virtue
of
including
the
key
share.
As
part
of
that
said,
you
prevent
the
cut
and
paste
attacks
that
are
currently
prevented,
so
I
think
what
needs
to
be
done
is
to
find
more
things
to
the
ESI
extension
next
slide.
A
Please,
but
there's
also
another
example
in
this
case
assume
the
client
hello
same
topology
setup
server
supports
the
tooth
host
supports
the
same
size,
tree
configurations.
This
client
sends
a
client
hello
in
which
he
prefers
to
try
over
yes
and
the
adversary.
Just
absolutely
nothing.
He
simply
just
forwards
them
to
two
different
hosts
and
gets
a
response
back.
A
He
can
then
distinguish
what
the
sni
value
was
based
on
a
prior
knowledge
of
what
the
ciphers
we
can
support
it.
So
board
ii
cities
are
for
those
particular
house
next
slide.
Please
there's
really
nothing.
We
can
do
about
this.
If
a
server
an
omni
set
of
quotes
is
configured
in
this
particular
way,
we
can't
stop
an
adversary
from
doing
this
sort
of
probing
without
modifying
any
of
the
client.
Hello
contents,
so,
ideally
servers
that
are
in
the
same
anonymous
that
respond
to
climb
level
message
is
the
same
way
for
every
done.
B
B
A
B
Yes,
I
mean
I,
mean
there's
a
basic
problem
that
I
think
that
it
I
mean
it
certainly
is
correct,
which
is
that
that
but
I
mean
so
David
and
I
were
talking
at
this
I.
Don't
really
see
him
here,
but
that
you
know
it's
really
the
case
that,
just
by
watching
you
can
probably
watching
how
the
server
responds.
You
can
learn
whether
it's
here
be
because
you
learn
whether
chooses
GCM
or
probably
13
or
5.
So
like
Polly,
something
like
as
a
practical
matter.
They
have
to
be
safe
or
speedy
attacks.
B
E
A
C
F
C
A
potential
solution
here,
I
think
what
you
really
want
to
say
here
is
that
servers
must
produce
similar
choices
for
its
server,
hello,
extensions
and
server
hello,
rather
than
having
completely
identical
responses
across
everything,
because
once
we
passed
the
server
hello,
everything
everything
is
encrypted.
So,
if
you
have
an
extension,
that's
responded
to
in
encrypted
extensions.
F
A
Could
you
open
an
issue
perhaps
for
that
that
would
be
great
right
so
moving
on.
So
this
is
the
the
more
interesting
attack
that
came
up
in
discussions
with
Eric
and
David
and
Stephen,
and
it
basically
works
like
so,
and
this
is
assuming
the
current
draft
client
sends
a
client
holo
with
es
and
I
valid
es
and
I
another
Greece
extension
to
a
particular
host
who
sends
back
in
HRR
the
on
path
adversary.
A
Then,
by
virtue
of
responding
to
an
HR
swaps
in
its
own
key
share
swaps,
an
attorney
s,
ni
encryption
of
encrypted
SMI
value
of
whatever,
and
then
sends
it
to
complete
the
connection
to
the
server.
If
the
server
doesn't
check
that
the
s
ni
value,
that's
in
the
second
client
below
matches
that
of
the
first
or
rather
checks
that
the
inner
contents
of
the
es
and
I
extension
matched.
That
of
the
first
client.
Hello.
A
Perhaps
because
he's
made
a
determination
based
on
what
sni
to
use
from
the
first
client
hello,
then
the
server
will
happily
complete
the
connection,
sending
the
certificate
and
corresponding
SMI
value,
which
is
so
I
could
based
off
the
SMI
value
from
the
first
client
hello.
So
the
adversary
can
just
finish
the
handshake
and
look
at
the
certificate
to
figure
out
exactly
what
s
and
I
or
probable
s
ni
was
used
to
complete
the
connection.
A
So,
ideally,
what
we
want
is
the
server
we
want
to
require
the
servers
to
do
this
check
and
we
can
say
in
text.
You
know
the
servers
must
absolutely
check
that
the
contents
of
the
first
years
and
I
extension
match
that
of
the
second,
otherwise
fall
back
to
the
public
name
or
do
something.
But
this
is
not
really
a
cryptographic
check
in
any
particular
way
and
it's
also
prone
to
implementation
mistakes
or
servers.
A
You
know
people,
including
servers
choosing
to
you,
know,
skip
over
that
part
of
the
text,
in
which
case
a
client
is
still
kind
of
in
a
bad
position.
So
ideally,
this
would
be
achieved
somewhat
cryptographically
and
the
proposal.
Actually,
if
you
just
go
forward,
the
proposal
is
to
our
a
proposal
rather
open
to
suggestions
as
we're
all
open
to
suggestions
to
include
something
from
the
ESN
I
extension
in
the
key
schedule
that
has
the
that
has
the
effect
of
effectively
binding.
A
That
PSNI
extension
from
the
first
client,
hello
to
the
duration
of
for
the
rest
of
the
handshake
effectively
and
I,
realized
that
people
may
react
negatively
to
putting
things
in
the
key
schedule,
but
I
think
of
all
the
options
that
gives
us
the
guarantees
that
we
want
in
a
pretty
intuitive
way.
So
I
mean,
of
course,
subject
to
formal
analysis
from
our
friends.
Yeah.
All.
C
C
Leaving
that
up
to
implementations
and
so
at
servers
to
do
that
on
their
own
discretion
and
there's
a
number
of
ways
in
which
people
might
take
information
from
the
first
client
hello
and
try
to
save
effort
in
processing
the
second
one,
and
because
this
is
a
pretty
significant
cost
in
terms
of
processing.
I
can
see
how
that
that
might
be
the
case
yeah,
particularly
when
you're
talking
about
using
the
innocent
I
extension
to
wrap
on
that
first
client.
C
A
Yeah
awkward
for
a
number
of
reasons
like
where,
in
which
direction
does
it
go
into
the
key
schedule?
How
do
you
like?
Is
it
coming
as
a
PSK,
but
what
would
you
do
then?
If
you're,
a
resuming
session,
has
a
PSK
or
put
it
in
HD
Sharon?
What
if
you
want
to
do
another
thing
that
happens
to
modify
the
key
schedule
which
will
be
discussed
later.
C
B
B
Absolutely
thank
you.
Thank
you.
Yeah
I
mean
it
seems
like
we
should
probably
separate
out
two
questions,
one.
What
is
the
general
strategy
was
to
follow
here?
The
second
is
part
of
the
specific
mechanics
of
how
it's
done
in
particular,
as
Martin
suggests.
If
we're
getting
to
the
point
where
we
think
when
I
do
a
lot
of
key
schedule
additions,
then
it's
probably
worth
cooking
up
some
mechanism
for
doing
that
generally,
that
that
allows
arbitrary
and
searches
at
each
point.
B
B
The
thing
I'd
like
to
understand
that
I,
don't
think
I
understand
yet
is
what
the
sufficiency
set
is
for
things
that
are
going
to
solve
this
problem,
namely
this
efficiency
set,
and
we
is
it
enough
to
just
have
something
in
the
key
schedule.
Do
we
also
have
to
do
a
digester,
or
you
know,
a
binding
across
the
line?
Hello
I
think
we're
getting
complicated
enough.
Now
that
we're
gonna
need
some
formal
analysis
to
reason
about
it.
B
We,
you
know,
we
had
some
initial
puts
on
this,
but
that's
so
super
the
next
step,
probably
rather
than
discussing
exactly
what
to
do
here
is
to
sort
of
leave.
This
is
an
open
question
and
for
input,
and
then
let
the
in
and
have
to
a
small
review
will
go
off
and,
like
interface
with
you
know,
Karthik
bhagavad
and
Kaz
and
like
have
them
help
us
work
through
the
problems,
but
I
think
no
kidding
getting
new
ideas
like
fantastic,
because
a
new
idea
is
great,
we're
trying
to
say
which
ones
did.
A
I
mean
we
could
even
form
like
a
design
team,
of
course,
to
go
off
and
focus
on
this
particular
problem.
The
current
thinking
now
is
to
do
both
the
binding
and
the
key
said
you
assert.
It
seems
like
be
most
conservative
and
kind
of
intuitively.
You
want
to
include
everything
in
the
client
hello
into
the
extension,
but,
of
course,
of
the
chicane
based
on
analysis
and
outcome
from
discussions
with
our
friends.
So
I
don't
know
which
of
you
is
first
I
believe.
H
It
was
me
Jonathan,
Holland,
CloudFlare
and
so
I'm
currently
trying
to
write
a
draft
on
how
to
inject
stuff
into
the
TLS
key
schedule
without
breaking
all
the
formal
proofs
with
Chris.
So
that
is
definitely
something
that
we
should
probably
do,
but
just
a
question
on
this.
You
comment
on
why
this
can't
be
done
in
exactly
the
same
style
as
the
PSK
binder.
So
you
just
include
the
same
stuff
as
the
PSK
binders
would
have
included
you.
H
A
That
is
one
of
the
options.
Yes,
it's
the
issue
with.
That
is
that,
if
we
have
to
do
this
again,
for
whatever
reason
then
are
we
going
to
start
just
stacking
up
extensions
on
the
bottom
of
the
client?
Hello?
What
about
the
ordering
for
these
things
and
it
it
becomes
tricky
and
there
are
other
bubbles
as
well
to
do
the
binding,
I'm,
not
I'm,
not
proposing
a
specific
solution
right
now,
I'm
just
saying
perhaps
we
should
do
that
we
should
do
the
formatting.
D
Yeah
I
mean
when
I
see
this
business
of
incorporating
all
es
and
I
all
client,
hello
extension
in
DSN
I.
You
know:
I
just
went
through
the
motions
of
updating
casual
code
from
the
drug
co2
to
the
grazie
Audrey
and
are
some
cut
paths
that
become
really
witty.
You
have
to
go
to
all
the
extensions
because
effectively
you
get
valuation
of
who's
on
top
and
and
if
we
have
to
solve
the
who's.
On
top
of
that,
oh
I
am
the
SNI
extension
and
on
top,
but
no
I'm,
the
bisque
extension
on
top.
D
A
A
This
proposal
is
trying
to
take
the
conservative
approach
where
we
might,
you
know,
say
we
minted
this
I
receive
just
I
mean
the
only
thing
we
included
with
Kiesha
in
the
service
suites,
and
we
discover
oh
shoot.
There's
this
other
parameter
that
could
possibly
be
unbounded
and
used
to
break
yes
and
I.
We
just
have
you
best
to
forget,
avoid
that
situation
and
doing
everything
does.
B
I
mean
the
message
here
is
clear:
we
went
through
a
couple
cycles
of
this
and
clearly
we're
not
you
know
the
trolls.
Yet
the
reason
about
it
so
I
think
what
I'm
interested
in
doing
as
I
indicated
earlier
is
getting
the
tools
to
reason
about
it.
So
I'm
perfectly
happy
with
all
the
suspenders
approach
in
which
we
have
several
things,
and
that
may
in
fact
be
valuable
for
other
reasons,
as
we've
discussed.
B
But
what
I'd
like
to
understand
is
what
every
individual
component
riding
is
doing
and
which
attacks
is
stopping
so
that
we
have
a
complete
model
of
attack
picture
because
it
seems
like
what
happened
here
and
you
know
not.
Maybe
anybody
cuz
I
was
involved.
This
is
just
anybody
else,
but
what
happened
here
is
we
had
a
partial
ma,
TAC
model,
and
so
we
closed
attacks
we
know
about.
But
then
we
didn't
have
a
way
of
reasoning
about
all
possible
attacks.
B
A
A
I
A
J
And
I
would
not
be
in
favor
of
firing
that
it's
different,
if
you,
even
if
you're
using
a
single
proxy
various
web
websites
or
domains,
will
have
different
configurations
for
different
reasons
and
forcing
them
to
conform
to
the
same
cipher
suite
said
is,
is
not
necessarily
going
to
work.
I
would
like
this
DNA
and
anybody
set
to
encompass
as
many
domains
as
possible,
rather
than
singling
out
the
ones
that
have
special
requirements.
I
suspect.
A
This
is
mostly
just
a
text.
Editorial
issue,
I
think
we're
in
agreement
that
yes,
ideally,
servers
that
have
similar
configurations
are
that
there's
many
servers
in
the
same,
and
only
set
that
have
this
particular
configuration,
not
like
all
the
servers
that
are
under
control
of
a
particular
operator
looking
shaped
exactly
the
same
way,
but
yes,.
K
About
suppose
I
anger
it
respectively,
yes
and
I,
it
seems
kind
of
undesirable
to
have
entity
generating
the
HR.
Our
client
follow
be
able
to
be
different
from
the
entity
generating
the
original
client
below
in
the
first
place
in
TLS.
Maybe
it's
a
more
general
problem
than
just
es
and
I've
fix
it
or
TLS
itself,
where
we
can
guarantee
that
the
entity
generating
that
new
client
hello
during
the
HRR
is
the
same
as
entity
to
generate
the
original
client
alone
in
the
first
place.
K
A
K
F
K
Just
a
TS
and
I
exposes
this
thing
like
we
don't
get
the
privacy
properties
out
of
this
because
there's
a
law
unanalyzed
case
in
TOS
in
such
a
way,
and
so
we
expect
it
to
get
these
privacy
properties.
But
we
didn't
get
these
private
properties.
Can
we
fix
TLS,
1
3
2
such
that
we'll
get
these
privacy
properties
back
from
the
TLS
protocol
itself?
Well,
you
don't
need
these
hacks
for
yes
and
I,
but
it'll
just
work
generally
for
any
other
extension
that
we
had
in
the
future.
Yeah.
B
Very
good
point
I
think
I'm
next,
so
on
this
question
one,
certainly
we
can
it's
possible
to
not
require
that
all
servants,
a
matinee,
missus
behave
identically
but
probate.
This
is
the
point
of
the
comments
making
earlier
that
definitely
does
leak
information,
because
the
way
you
think
about
this
is
imagine
that
you
have
an
enemy
set
of
K
servers
and
K
minus
one
servers
all
prefer
AES
GCM
and
the
K
and
and
the
case
server
and
the
other
remaining
server
first
chacha
poly.
B
So
all
I
have
to
do
is
what
watch
the
transactions
and
she
actually
comes
through
a
shop
Holly
I
know
it
must
be
that
Kaiba,
it's
one
server!
It's
like
that's,
not
a
probing
a
tactician,
observational
attack
and
so
like,
as
David
Benjamin,
pointed
out,
that's
not
as
good
as
a
program
attack,
but
it's
certainly
a
plausible
attack,
and
so
they
send
to
which
its
head,
to
which
servers.
B
Don't
you
know,
don't
have
the
enemies
that
maybe
I
know
they
don't
petition
to
me,
set
in
some
ways
and
there's
not
really
much
to
do
about
that
and
rich
Inglewood
I.
Think
and
the
advice
don't
want
to
be
do
the
best
you
can
have
like
uniform
configuration,
and
you
know
yes
and
I
is
not
a
pretty-
is
not
only
a
perfect
defense,
it's
a
partial
defense
and
but
the
advice
is
that
just
pursue
a
movie
set,
though
so
the
circumstances.
Thank
you.
M
Benkei
dark,
you
know,
I
had
been
thinking
similar
things
to
what
suppoed
was
thinking
about.
You
know
is
this
a
more
general
question
and
I
think
we
did
briefly
consider
this
when
we
were
writing,
kill
us
one
three
and
we
concluded
that
we
didn't
want
to
make
the
server
have
to
do
the
work
all
the
time
to
keep
the
state
because
didn't
matter
that
much
and
it
may
just
be
that
the
conclusion
here
is:
if
you're
gonna
do
yes
and
I
as
the
server
you
have
to
do
more
work
seems
reasonable.
M
G
L
I
You
panel
microts,
as
far
as
a
question
of
this
being
a
more
generic
prom
I
think
one
thing
that's
special
about
this
is
that
we
do
have.
We
do
have
the
potential
to
use
some
kind
of
a
shared
secret
with
the
client
key
share,
whereas
most
extensions
we
do
not
have
that
and
usually
we're
sending
a
HRR
in
response
to
not
having
an
acceptable
key
share
in
the
first
place.
So
I
think
this
would
be
a
little
bit
more
difficult
problem
to
solve
generically
yeah.
A
Good
point:
thank
you
all
right,
so
well
continue
that
discussion
on
the
issues
and
any
issues
in
on
the
list.
The
next
big
one
is
HP
key
and
whether
or
not
yes
and
I
should
adopt
it.
So
for
those
of
you
who
are
not
familiar,
HP
key
is
hybrid
public
key
encryption,
basically,
EC
is,
but
in
with
Kem's
and
Dems.
A
A
So
the
benefits
of
HP
adoption
here
are
that
we
don't
roll
our
own
crypto
and
we
use
something
that
the
CFR
G
sort
of
blessed
in
a
way
the
drawbacks
beyond
it.
Being
an
active
draft
currently
and
still
under
act
and
under
construction-
and
still
you
know
in
need
of
analysis-
are
that
by
changing
the
es
ni
key
share
effectively
on
HRR,
you
are
forcing
the
server
to
do
another
public
key
operation
and
processing
that
that
might
be
a
deal-breaker
I'm,
not
sure
so
I
mean
there
may
be
other
benefits
and
drawbacks
as.
C
N
C
You
have
to
put
two
separate
caches
in
you've,
expanded
that
you
see
space
and
we
have
primitives,
but
the
flipside
of
that
is
that
we
have
primitives
that
reuse
of
a
key
share.
It
doesn't
work
for,
and
so
we
need
to
be
aware
of
that.
So
we
were
looking
at
s
idh,
for
instance,
and
you
can't
reuse
a
key
share
in
that
context.
Sorry.
A
C
A
B
B
So
in
for
since
we
wanted,
you
know-
and
you
know,
I-
don't
know
you
call
it
but
HP
key
plus
and
slurry
random
output,
like
that
seems
like
pretty
easy
to
generate
so,
presumably
like.
Let's
you
know,
the
purpose
of
the
work
in
you
know,
CF
4G
is
partly
to
support
the
work
here.
So
all
right,
yeah,
that's
certainly
approaches.
A
A
One
more
important
issue,
hopefully,
can
get
this
really
quickly,
and
that
is
of
split
mode.
Currently,
the
drafts
supports
both
shared
and
split
mode
in
the
split
mode
case.
Basically,
the
the
client
facing
server
has
to
send
some
secret
key
material
to
the
back-end
server
right
now
we
suggest
basically
doing
that
by
sending
it
prepended
to
the
client,
hello,
on
the
TCP
connection
encrypted
under
symmetric
key,
that
the
two
endpoints
have
been
to
share,
and
you
might
want
this
for
some
use
cases
slide.
A
Please
next
way
so
benefits
there
may
be
use
cases
that
require
this
drawbacks,
of
course,
that
this
does
add
complexity
to
the
document
in
it,
depending
on
one's
perspective,
and
they
might
constrain
the
things
that
we
could
possibly
encrypt.
You
might
imagine
in
share
mode
and
ease
and
I
would
only
share
mode.
You
could
potentially
encrypt
more
than
just
the
SMI
like
AOP
and
etc.
It's
also
potentially
part
of
a
more
general
protocol
that
Ben
will
be
talking
about
a
little
bit
so
I
posed.
B
Erik
or
scroll
again,
the
document
is
not
really
included
or
not
included.
It
just
says
this
is
consistent
with
its
operational
mode,
and
then
it
has
some
hand-waving
about
how
you
implement
it.
So
I'm,
not
quite
clear
on
what
complexity
is
being
is
being
added
here.
If
we
get
to
the
point
where,
including
it
we're
having
a
docking
which
can
paddle
like
I,
see
as
a
requirement
rather
than
as
a
function
in
this
protocol,
maybe
be
requiring
it
to
be
compatible
with
the
split
mode.
B
If
it
turns
out
that
that
crime
is
like
clothing
with
a
lot
of
pain,
we
can
revisit
it,
but
until
then
I'd
like
to
have
the
requirement
key
to
be
written
down
so
that
we
remember
it
because
I
think
it
is
an
important
use
case
where
maybe
we
can't
get
them
all
but
like?
Let's,
not,
let's
not
like
shortener
sites.
Until
we.
A
B
P
N
This
is
Daniel
can
go
more,
so
I
definitely
think
this
is
an
important
requirement
for
this
case
they're
going
to
be
people
who
want
to
operate
a
protected
server
in
the
back
end
that
can't
share
the
content
with
the
front
end
server.
So,
yes,
please
make
sure
that
this
stays
is
a
requirement.
Okay,
see.
Q
A
Fine
with
me
yeah,
so
we
can
update
the
text
accordingly,
just
maintaining
the
requirement
and
then
describing
potentially
one
life.
One
might
go
about
doing
this
and
I,
don't
think
we
have
any
time
for
the
rest
of
it.
So
please
take
a
look
at
the
issues
there
on
the
github
page
or
on
the
github
repo
comment.
A
I
will
try
to
summarize
the
what
are
the
big
open
questions
that
send
lists,
encouraging
people
to
comment
and
regarding
the
earlier
more
non-trivial
changes,
I
guess
well,
if
anyone's
interested
in
working
on
this
particular
problem,
we
can
get
together
with
our
formal
analysis,
friends
and
kind
of
breakfast
Oh
Christian
raised
his
hand
and
I'm
sure
they
look.
People
who
we've
been
talking
about
will
be
interested
as
well,
so
I
think.
That's
it
unless
there
any
end
of
the
questions.
M
D
Try
to
be
brief,
so
the
connection
ID
topic
Dissidia
at
the
moment
three
documents
I
would
like
to
talk
about
the
first
two
on
the
top
are
the
connection
ID
for
the
me
TLS
1.2,
the
connection
ID
for
the
1.3,
which
is
in
the
detail,
s
1,
2,
3
specification
itself
and
then
there's
a
new
document
on
the
bottom
and
I
will
get
to
that
in
a
in
a
minute.
It's
like.
So
this
is
the
the
regular
behavior.
D
So
you,
if
you
remember
and
I'm,
not
going
to
repeat
the
the
use
of
the
connection
idea
again,
but
we
had
regular
client
ID
device
talking
to
a
server
via
NAT
and
the
not
obviously
changes
the
IP
address,
source,
IP
address
and
and
the
port
as
well
typically,
and
so
you
have
the
connection
ID
in
the
payload
which
associates
the
or
links
to
the
keys
and
the
algorithms.
So
everything
good
so
far,
the
not
makes
these
modifications
and
that's
exactly
the
intended
behavior
next
slide.
D
D
Imagine
that
Dennis
and
on
path
adversary',
who
is
kind
of
like
a
gnat
but
is
able
obviously
to
change
the
source
port
of
the
packets
that
pass
through,
and
so
he
changes
it
to
redirect
the
traffic
to
some
remote
server
any
in
case
there
is
an
asymmetry
between
the
traffic
that
goes
from,
in
this
case
the
client
to
then
finally,
the
victim.
Then
this
adversary
is
able
to
make
an
amplification
attack.
D
That's
obviously
a
problem.
What
I
didn't
describe
in
the
slide
is
the
case
where
there's
an
off
pass
adversary
who
injects
some
packets,
but
thanks
to
like.
Obviously,
there
are
properties
of
DTLS
with
authenticated
packets.
That's
not
possible
because
the
attacker
can't
mint
the
packets
with
the
correct
key
to
make
them
pass
through
the
security
checks,
and
so
you
wouldn't
update
the
the
finding
in
your
database
to
send
the
returned
traffic
to
this
newly
indicated
IP
address
without
actually
checking
the
cryptographic
parts
of
the
packet.
C
C
D
C
So
the
other
observation
here
is
that
routing
on
the
Internet
is
not
always
ideal,
and
so
you
might
end
up
with
in
a
situation
where
the
adversary
has
a
faster
path
and
can
they
they
can
copy
a
packet
and
replay
it
and
be
the
real
pack
to
the
server.
It's
a
it's
a
race
condition
thing,
but
you're
also
able
to
mount
the
same
attack
without
relying
on
the
anti
replay
properties
that
you.
D
So,
in
some
sense
we
don't
necessarily
you
don't
necessarily
need
to
enable
the
anti
replay
protection
which
we
TLS
offers.
You
could
rely
on
a
newly
defined
rule
which
we
haven't
added
to
the
document,
yet
it's
in
a
github
repository
Aztecs,
but
needs
some
discussion
on
that
the
server
needs
to
before
sending
it
to
this
new
IP
address.
He
would
actually
have
to
check
whether
this
is
indeed
the
newer
packet
in
terms
of
the
sequence
number
and
so
on,
even
if
the
reproduction
is
disabled,
that
would
be
one
possibility
to
deal
with
with
this
case.
C
D
If
you
go
back,
one
slide,
of
course,
there's
also
the
possibility
did
not
do
basically
black
hole
traffic
which
is
sort
of
what
this
figure
is
supposed
to
indicate.
Needless
to
say
that,
if
there's
an
adversary
on
along
the
path,
he
can
as
well
just
drop
packets
without
having
to
reroute
them
unnecessarily,
that's
also
a
possibility.
C
Yes,
amount
on
something.
The
other
thing
to
observe
here
is
and
I've
got
a
credit
Eric
here
who's
sitting
out
of
there.
Eric
Kinnear
has
done
a
lot
of
analysis
on
this
thing.
For
for
quick
and
there
are,
there
are
a
couple
of
other
cases
that
you
might
want
to
consider
in
your
throat
model.
Depending
on
on
the
decision,
you
make
there's
a
good
write-up.
Now
it's
it's
a
it's
in
a
pull
request
on
the
quick
specification.
I
can
send
a
link
to
that
to
the
mailing
list.
C
The
returned.
Your
ability
check
that
you
describe
does
not
necessarily
cover
all
of
these
cases
adequately.
Unfortunately,
and
so
there's
a
there's
logic
that
you
need
to
apply
in
both
both
endpoints.
In
fact,
in
order
to
make
sure
that
you're
not
subject
to
attack
so
I
would
encourage
you
to
read
what
we've
done
in
quick
and
read.
Eric's
analysis
event
and
I
would
suggest
that
you
copy
that
design.
Let's
not
do
this
to
us.
Yeah.
D
We
obviously
looked
at
the
quick
text
and
that's
a
good
idea.
That's
also
why
we
decided
to
have
a
separate
document
on
this,
because
it
can
advance
independently
of
the
other
stuff.
For
those
cases
where
that
type
of
concern
is
is
big
enough
warrant,
the
return,
routability
check
procedure
and
I
think
it
makes
sense
to
have
something
at
the
DTLS
layer.
Very
much
like
you
guys
did
in
quick.
B
Workers,
Cola
so
I
think
there's
two
questions
here:
one
of
technology
and
one
of
perhaps
three
one
of
the
layering
on
a
document
structure.
So
the
when
we
decided
to
add
the
connection
ADT
else,
one
point:
three:
the
general
concept
was
that
we're
gonna
have
the
machinery
that
you
would
need
to
do.
The
connection
ID
because
I
said
look
at
the
transport
layer,
but
that
any
of
the
machine
we
need
to
handle
the
changes
in
connection
changes
in
IP,
address
we
put
somewhere
else
and
I
think
that
this
existence.
B
B
And
then
it
should
say
here
are
some
considerations
about
what
you
would
generally
need
to
do
and
her
adjust
the
peer
address
and,
and
they
pits
responsibilities
of
the
application
or
some
future
extension
light
bill.
Or
he
draft
to
tell
you
how
to
actually
do
that
and
that
lets
us
advance
the
wire
format
Mechanics
for
people
who
need
them
and
then
on
and
then
and
codifying
the
return
reliability
check
with
quick
and
get
it
and
get
the
right
answer.
So
that's
how
I
program.
D
B
After
finding
a
little
bit
but
I
think
I
think
no
I
think
I
think
it
needs
to
duplicate.
The
text
did
see
in
duplicate
the
text.
D
R
B
B
Yes,
so
the
question
is
like
you
want
a
compact
key
exchange
like
what
do
you
do
so
we
feel
like
an
enormous
my
time
on
one
three,
getting
it
right,
or
at
least
as
right
as
we
know
how
to
get
on
skype.
Mr.
Feeny,
why
you
studied
with
all
these
papers
with
like
a
lot
of
implementations,
it's
already
a
pretty
large
fraction
of
traffic
from
browsers
and
we're
seeing
increased
on
other
places
as
well.
B
The
original
design
wasn't
that
compact
and
we
didn't
like
really
make
much
effort
to
make
it
more
compact,
but
a
few
places
we
try
to
shrink
things
down,
but
generally
this
was
not
a
design
goal
in
large
part,
because
so
many
the
applications
of
TLS
involved
certificates
and
certificates
are
so
large
that
basically,
that
dominates
the
size
of
the
packets
next
slide
so
there,
but
it's
turning
out.
There
are
other
applications
where
people
like
to
have
much
smaller,
much
more
transcript.
First
of
all,
all
not
transcript
I
should
say
a
much
more
wire
image.
B
This
is
I,
say
initially
prompted
by
some
work
on
IOT,
but
also
we
separately
had
conversations
in
quick
about
how
big,
like
the
quick
messages
are
and
how
nice
it
would
be
if
we
get
them
a
little
smaller,
especially
in
the
client,
hello,
we're
we're
narrow
or
narrow.
Your
strained
at
the
first
twelve
hundred
bytes,
unless
you
want
to
have
some
sort
of
extra
machinery,
is
david.
Benjamin
is
pointed
out.
B
I've
made
this
mistake
a
number
of
times,
I'm
sure
other
people
have
as
well
you're
gonna
move
all
the
redundant
life
fields,
there's
also
lots
of
places
where
we
have
like
fixed
length,
length
fields
for
things
which
are
almost
never
as
big
as
they
ostensibly
are
supposed
to
be.
So
a
really
common
pattern
would
be
like
handshake.
Messages
can
be
up
to
two
to
24
bytes
long.
B
So
a
good
example
here
is
that
if
you
only
support
one
one
with
the
curve
type,
then
why
are
you
bothering
to
say
here
the
curve
types
of
support,
and
here
are
the
key
shares
that
go
with
it.
So
you
can
imagine,
saying,
look
I
just
gave
you
the
key
shares
and
I'm
not
going
to
take
any
others.
Don't
bother
or
like
bothering
me,
with
an
HR
there's,
also
some
places
where
it
looks
like
there's
been
excessively
long,
crypt
of
variables,
the
random
is
a
good
example.
It's
not
really
clear.
B
We
need
a
30
talked
at
random.
Now,
of
course,
we
all
like
chewing
up
a
bunch
of
white,
but
we
increasingly
using
up
that
space
for
various
kinds
of
Sentinel
values.
So
it's
not
clear
how
much
room
we
actually
have
left,
but
it
does
seem,
like
you
slim,
that
some
there's
also
some
questions
about
whether
or
not
we
may
finish
earlier
because
face
is
quite
long.
B
So
this
is
effectively
just
like
TLS
1.3,
with
a
better
encoding
and
and
it's,
and
so
you
basic
and
morphism,
between
1/3
and
and
and
ctls,
and
it's
pretty
easy
to
convince
yourself,
those
the
same
protocol
and
if
you
look
at
all
the
analysis
working
the
proofs,
all
those
all
analysis.
Work
was
basically
done
without
really
looking
at
the
where
encoding
and
deal
anyway
and
certainly
doesn't
pay
much
attention
differences.
How
long
the
length
field
sign?
B
Basically,
a
compression
layer
between
those
two,
this
is
I,
think
has
the
nice
property.
Yes,
hi.
F
B
So
as
I
say
that
you
probably
want
to
eat
the
transcript
and
then
we
expand
it
back
into
the
full
TLS
transcript.
So
basically
you
have
this
tails
two
point,
three
for
all
the
key
schedule,
etc.
On
this
essence,
the
advantage
that
been
all
the
things
that
you
were
essentially
compressing
down
get
be
we
get
like
we,
we
materialized
back
in
the
transcript.
So
you
know
the
negotiation
is
correct.
This
probably
this
may
or
may
not
require
some
kind
of
cross
protocol
defense.
B
To
avoid
having
CTLs
talk
to
TLS
four
point:
three:
you
can
think
of
that
as
a
feature
or
a
bug,
depending
on
the
perspective.
So
that's
why
I
say
you
may
not
want
that
on
either
approach.
It
has
like
the
reasonable
chance
of
keeping
the
existing
proof
valid,
which
is
the
main
thing
we're
trying
to
do
that.
That.
B
The
main
theme
here
right
is:
we
have
a
protocol
which
is
spending
those
that
we
spend
a
lot
of
time
engineer
and
we
spent
a
lot
more
time.
Engineering,
adding
these
two
we'd
like
to
continue
getting
value
out
of
that,
while
still
having
a
compact
on
protocol
rather
than
having
just
have
a
separate
line
of
compact
protocols
that
then
have
to
increment
only
be
in
it
be
extended
all
the
same
ways
that
we're
sending
TLS.
B
To
give
you
a
concrete
example
of
this
I
was
80
back
when
we
did
the
conversion
we
did
colonel,
and
so
we
had
this
process
of
having
to
like
incrementally
add
curve
to
five
five
one,
nine
everywhere
across
the
IETF
stack,
and
it
was.
This-
is
a
giant
effort
of
like
crossing
out
like
P
256
I'm
writing
to
five
five
one.
Nine!
It's
not
happy
to
do
that
very
nice.
If
we
were
wanted
to
say,
say,
add
post
quantum
next
slide.
So
here's
like
a
concrete
example.
B
It
just
shows
how
much
like
redundancy
we've
managed
to
create.
Here's
like
the
client
holo
that
stray
up
tails
and
point
three
client
below
so
the
first
field
is
the
protocol
version,
which
now
we've
abandoned
because
need
ago
she
and
supported
versions.
The
second
field
is
the
random
value,
which
is,
as
I
said,
30
to
our
hats.
Long.
B
The
third
field
is
the
session
ID
which,
by
the
way,
we've
abandoned
because
we
now
we
do
PSK
be
the
fourth
field
of
cipher
suites
you'll
notice,
that
has
a
two
plate
length
field
and
can
allow
you
to
have
65,000
bytes
worth
of
cipher
suites.
Now
we
haven't
defined
65,000,
sorry,
32,000,
Severus,
wheats
and
I
can't
imagine
any
sensible
person
wanting
to
advertise
that
money.
So
there
seems
to
be
a
fair
amount
of
extra
slack
here
that
you
don't
need
on.
B
Then
we
have
professional
methods,
have
our
mentioned
removed
compression
and
then
finally,
we
have
extensions
and
again
the
extensions
could
be
up
to
65
kilobytes
long,
which,
like
is
pretty
long
and
you'll,
have
lots
of
reasons
to
believe.
You
might
only
need
like
a
couple
hundred
bytes
of
extensions
typical
client
hellos
range
in
there
sort
of
200-300
bite
range
for
this
area.
D
S
B
The
intuition
that
Karthik
gave
us
so
next
slide,
so
this
is
what
you
can
do
if
you're
like
trying
a
little
bit
and
really
only
a
little
bit,
so
you
say
well,
look.
The
protocol
version
will
cut
it
under
one
plate
because
we
don't
have
a
zillion
versions.
The
random
was
linked
by
half
because
we
don't
Lanie
deep
32
bytes
again,
we
don't
need
a
lot
of
cipher
suites
or
make
them
one
pipe
long.
Then
we
remove
other
things
that
we
didn't
need.
B
The
version
of
string
becomes
shorter
V
and
then
we
take
say
for
sweet.
So
we
have
a
variant
length
on
the
encoding
for
the
length,
and
so
you
don't
need
to
burn
up
to
us
extract
at
on.
Like
and
oh
by
the
way.
Oh
I
forgot
to
mention
the
extensions
fields.
You'll
notice
has
its
own
length
field,
but
it's
not
just
a.
However,
the
vector
is
even
though
the
extensions
takes
up
the
entire
remedial
message.
It's
like
simple
subtraction
will
tell
you
how
long
the
offenses
field
is.
B
So
once
again,
you
have
extra
slack
next
so
that,
hence
you
say.
Basically,
these
tensions
field
now
is
there
in
the
message.
So
if
you
take
this
treatment-
and
you
like
apply
it
to
tell
us
as
a
whole,
you
can
actually
a
pretty
substantial
amount
of
reduction
in
message
size.
So
this
is
like
strategy,
one
strategy
to
next
slide.
If
you
really
like
to
really
go
crazy
and
like
have
like
you
know
here
is
like
a
mail,
I
cup
say
three
or
four
octet
profile
that
describes
exactly
all
the
cryptographer
parameters.
B
B
But
in
any
case,
so
you
can
really
shrink
things
down
if
you
try
hard
next
time.
So
I
regret
that
I
didn't
have
like
the
original
versions,
because
it
trust
me
that
these
numbers
here
are
like
much
smaller
than
the
number
of
you
started
with,
and
so
you
do
a
pretty
good
job
next
slide.
So
this
is
like
pulmonary
work,
hence
informational.
B
There
are
another
obvious
places
to
do:
optimization,
we're
working
with
Bhagavan
other
people
too,
like
basically
the
other,
see
see
what
we
have
to
do
make
sure
we
have
enough
isomorphism
the
proofs
actually
carry
over,
because
that's
the
whole
point
of
exercise
I
see
Jonathan
Lawson's,
that's
on
that
on
where
she
will
try
and
decide
whether
we
want
to
follow
the
compression
strategy,
which
seems
like
more
compact
analysis.
It
did
where
I
spent
the
transcript,
but
I
think
the
converse
is
about
this
week.
We
can
beam
very
much
towards
capacity
expansion,
Adam.
P
B
P
P
B
P
B
K
B
V
Expect
this
might
be
redundant,
but
just
to
make
absolutely
sure.
The
intention
here
is
to
show
isomorphism,
as
you
say
in
this
slide
right
and
then
to
provide
whatever
arbitrary
transformations
during
that
demonstration.
So
you
could,
for
instance,
apologies.
You
could,
for
instance,
use
a
single
byte
and
have
a
bit
in
the
byte
to
say
the
presence
of
any
of
these
fields
and
then
interpret
you
could
do
protobufs
whatever.
That
is
the
intent
correct.
Yes,
awesome,
yeah.
B
M
M
B
There's
actually
the
vast
majority,
the
overhead
of
the
test.
Handshake,
of
course,
is
in
the
TLS
handshake.
It's
often
not
in
the
TTLs
extensions,
but
those
are
also
fairly
bloated,
and
so
this
places
to
remove
things
as
well.
Yeah.
B
U
B
There
are
couple
of
angles:
there
I
think
one
angle
obviously
would
be
to
have
you
know
to
have
a
like
non
CTLs,
quite
hello,
followed
by
the
server
sending
you
see.
Tls
another
angle
would
be-
and
this
is
the
one
perfect
and
I
talked
about-
is
to
have
sort
of
a
translating
device
who
only
gets
the
who
doesn't
get
any
of
the
eight
key
material,
but
only
gets
the
the
only
gets
the
a
ad
key
material
and
that
can
do
these
fashion
internally.
So
we
listed
a
bunch
options.
U
E
P
W
X
X
W
It's
like
the
usual
compression
trade-off,
like
the
more
you
pre-negotiate,
the
better
compression
you
get
and
in
this
experiment
that
we
did
we
kind
of
turned
the
compression
dial
all
the
way
to
nail
everything
down
and
see
how
far
we
get
I
expect.
You
know
when
we
look
at
you
know
the
comparables
and
ad
hoc
there's
likes
a
little
bit
of
negotiation
in
there
I
think
they
have
like
a
couple
of
Cypress
Suites.
They
can
negotiate
so
I.
W
Think
as
this
develops
my
answer
and
discussion
I
think
this
will
go
on
the
lake
working
group,
but
as
we
have
the
discussion,
some
of
that
will
be
added
in,
but
probably
in
using
some
of
these,
you
know
optimized
encodings,
that
the
Necker
mentioned
said
you
have
whatever
a
little
bit
of
negotiation.
We
need
to
to
make
this
work.
X
E
Y
Hello,
I'm
double
steel
from
the
University
of
Waterloo
and
I
want
to
talk
about
our
draft
on
design
for
hybrid
key
exchange
in
TLS
1.3
next
slide.
So
just
as
background,
there's
been
a
variety
of
interest
in
using
multiple
key
exchange:
algorithms
in
the
handshake
as
part
of
a
transition
to
post
quantum
crypto
and
a
variety
of
internet
drafts
Huynh
implementations
over
the
past
few
years.
I
the
idea
to
focus
on
key
exchange
rather
than
authentication,
is
that
we're
concerned
that
quantum
computers
could
retroactively
Li
decrypt,
but
they
can't
retro
actively
impersonate
parties
I.
Y
So
the
goal
here
is
to
develop
a
framework
for
using
multiple
algorithms
simultaneously
next
slide.
One
thing
we're
not
trying
to
do
is
pick
a
particular
post
quantum
algorithm,
we'll
leave
that
to
the
NIST
post
quantum
standardization
process
next
slide.
So
at
the
last
IDF
meeting,
Chris
presented
on
our
behalf,
the
first
draft,
which
contained
a
menu
of
design
options
on
overall
design
aspects,
so
how
to
negotiate,
which
algorithms
and
combinations
should
be
used.
Y
How
many
algorithms
can
actually
be
combined
just
two
or
more
than
two,
how
to
transmit
the
public
key
shares
and
how
to
combine
the
secrets?
The
feedback
we
got
from
the
working
group
was
to
avoid
changes
to
the
key
schedule
and
to
try
simplify
the
menu
of
options
and
down
to
a
couple
of
candidates
next
slide.
So
that's
what
we've
done
in
the
draft
today.
There
is
still
the
menu
of
design
options.
Just
so
that's
kind
of
reference.
We've
got
two
candidate
instantiations,
which
I'll
talk
through
today.
Y
The
first
option
directly
negotiates
each
algorithm
and
separates
the
key
shares.
The
second
one
kind
of
follows:
what
some
of
the
implementations
have
been
doing,
having
code
points
for
each
defined
combination,
copy
also
added
a
new
key
DF,
as
suggested
by
someone
in
the
mailing
list
next
slide,
so
in
the
first
instance
iation
we're
kind
of
taking
a
proper
approach
where
everything
is
done
separately.
Y
So
this
follows
an
earlier
draft
by
William
white
and
others
I,
the
algorithms
are
negotiated
individually,
so
there
are
new,
named
groups
called
hybrid
marker,
0,
hybrid
marker
1,
which
don't
actually
mean
anything
in
themselves.
They're
just
pointers
into
a
hybrid
extension
where
each
marker
is
mapped
on
to
the
groups
or
key
exchange
methods
that
are
meant
to
comprise
that
onto
each
part.
Y
You
can
suggest
as
many
combinations
as
they
like
and
they're
indicated
with
these
hybrid
markers
and
we
can
allow
you
know
multiple
algorithms,
we
put
a
maximum
of
10,
but
there's
no
reason
that
you
can
couldn't
have
more
than
that
next
slide.
So
once
those
have
been
listed
in
the
negotiation,
we
have
to
convey
multiple
key
shares,
one
for
each
algorithm.
So
in
this
approach
we
use
the
existing
list
of
client
key
shares,
send
one
key
share
per
algorithm,
and
so
we
don't
require
any
new
data
structures
on
this,
at
least
in
the
client
hello.
Y
Okay,
so
that's
the
first
candidate
on
the
next
slide,
there's
the
second
can
to
get
so.
This
follows
more
what
some
of
the
implementations
have
been
doing,
and
this
is
a
simpler
approach
from
an
implementation
perspective
on
you
define
new
code
points
for
each
combination.
You
want
to
consider
so
you
can
see.
We've
just
extended.
The
named
group
enum
here
to
list
new
combinations,
so
P
256
with
postpone
and
algorithm
1,
whatever
it
ends
up
being:
P,
256,
plus
quantum
algorithm,
2
and
so
on,
and
there's
no
internal
structure
to
these
code
points.
Y
It's
just
a
new
code
point
and
then
on
the
next
slide,
to
convey
the
key
shares.
Then
we
just
conveyed
the
concatenated
public
keys
for
each
of
these
new
code
points.
So
this
really
requires
no
changes
to
the
structure
of
negotiation
or
any
negotiation
logic.
Everything
is
just
a
new
key
exchange
method.
Next
slide.
Y
So
to
compare
these
the
first
instantiation,
we
have
new
negotiation
logic
and
a
new
extension
to
convey
these
the
list
of
algorithms,
but
it
doesn't
require
any
change
in
how
the
key
shares
are
conveyed
or
it
doesn't
require
multiple
groups
to
be
defined
for
each
combination,
whereas
in
Canada
instantiation
2,
there's
no
change
in
negotiation,
logic
or
protocol
logic.
We
had
this
combinatorial
explosion
of
named
groups
and
you
might
have
to
send
duplicate
key
shares,
so
you
wanna
advertise
P
256
with
algorithm
1
and
P
256
with
algorithm
2.
Y
H
Winning
CloudFlare,
it's
obviously
as
someone
who
did
one
in
the
formal
analysis,
analyses
I'm
very
against
changes
to
the
key
schedule
and
I
think.
Actually,
your
first
approach
could
be
wired
into
the
key
schedule
in
a
sort
of
standardized
way
and
given
the
other
things
that
we
want
to
do
with
the
key
schedule,
we
should
just
first
work
on
standardizing
how
to
inject
new
keys
in
to
tell
us
okay.
So.
P
Y
P
M
Yeah
benkei
doc,
so
I
mean
in
terms
of
the
trade-off.
I
know
I've
already
told
us
what
to
do,
but
you
know
sort
of
a
question
of
if
you
have
a
pretty
good
idea
that
everybody
is
going
to
be
doing
the
same
sorts
of
things
same
sorts
of
algorithm
combinations
and
it's
pretty
clear
if
it's
like
totally
out
there
and
you
can
be
trying
all
sorts
of
random
combinations,
that's
when
you
may
want
to
be
doing
it
independently.
T
Z
Not
going
to
have
a
large
number
of
algorithms
that
aren't
being
combined
most
of
the
time
it's
gonna
be
250
states
or
curved
55:19,
combined
with
some
post
quantum
algorithm
and
there's
only
going
to
be
sort
of
two
out
where
that
was
being
combined.
So
I
think
that
motivates
being
the
second
option
for
how
you
do
combinations
declare
a
hybrid,
hybrid,
Sabra,
sweet.
C
Y
T
Marko
NCSE
I'd
like
to
thank
you
for
bringing
this
draft
of
the
working
group,
but
I
found
it
a
useful
reference,
I'd
like
to
speak
in
favor
of
option.
One
here,
I
think
it's
good
to
have
the
informational
document
that
describes
the
different
ways
of
doing
these
hybrids
and
they're.
The
pros
and
cons
of
each
so
I
think
that
that's
useful
I
can
see
scope
for
both
of
these
actually,
but
I.
Think
they
doing
one
in
the
first
place
would
be
good.
T
S
People
have
been
as
okays
people
have
been,
assuming
that
nist
will
only
approve
to
our
rhythms
or
three
albums.
That
may
be
the
case.
However,
each
algorithm
of
that
they've,
been
under
discussion,
have
multiple
parameter
sets
and
we're
likely
to
want
each
premier
set
to
be
treated
separately.
Instead
of
only
having
three
algorithms,
we
might
have
a
total
of
12
parameter,
algorithm
primer
set
combinations,
and
that
should
needs
to
be
kept
in
mind.
C
Yeah
so
Martin
Thompson
in
responses
just
got
there.
I
think
this
is
something
that
we
would
ask
well.
I
would
want
us
to
ask
for
CF
RG
to
address,
because
I
don't
want
to
have
I
mean
this
explosion
of
parameter
sets.
I
want
one
option,
preferably
maybe
two,
and
that
maybe
two
different
options
and
there
may
be
different
sets
of
options
for
different
use
cases,
but
ideally
it's
one,
maybe
two
for
the
use
for
any
individual
use
case.
That
makes
sense.
Yes,.
P
C
B
Hi,
so
this
is,
as
mentioned
on
the
topic
of
of
yes
and
I
split
mode
next
slide,
so
I'm
going
to
use
the
term
load
balancer
here.
This
is
maybe
an
idiosyncratic
usage
of
the
term,
but
the
load.
Balancer.
Is
this
thing
in
the
middle?
That's
doing
the
splitting
or
the
forwarding
or
the
proxying
I'm
gonna
call
the
load.
B
Balancer
I
am
particularly
interested
in
a
kind
of
load
balancer
that
I
call
an
SN
I
proxy,
so
that
traditionally
has
been
something
that
inspects
the
SN,
I
and
then
forwards
to
a
back-end
that
is
determined
by
its
SM
by
the
connections.
Sn
I
and
the
nice
thing
about
SMI
proxies
is
that
they
don't
terminate
TLS
so
they're
in
a
sense
they're.
The
highest
point
in
the
stack
that
doesn't
terminate
TLS
is
the
most
information
you
can
get
while
maintaining
end-to-end
to
it.
Tls
next
slide.
B
So
the
motivation
for
this
is
split
mode,
es
ni
and
I'm
going
to
draw
a
distinction
here
that
I,
don't
think,
is
clear
yet
in
the
yes
and
I
draft
between
partial
and
full
split
mode.
So
the
the
key
difference
here
is
that
in
the
es
ni
draft,
you
must
know
the
es
ni
private
key
in
order
to
reply
and
formulate
a
working
server
hello.
B
But
if
you
have
a
variety
of
backends
and
they
all
have
this
private
key,
then
you
have
a
widely
shared
private
key.
So,
for
example,
if
you
are
operating
a
large
commercial
service
or
adversary
could
simply
sign
up
for
your
commercial
service,
learn
medias
and
I
private
key
and
then
use
it
to
decrypt
s
ni
on
the
wire.
B
B
Maybe
this
is
gonna,
be
a
rat
hole,
but
I'm
also
surprised
by
this
I
thought
that
the
way
I've
written
the
specification
aloud
was
designer
and
falsehood.
But
it's
of
course
possible.
I
made
a
mistake,
so
the
I
am,
if
I
remember
the
text
correctly.
The
current
es
and
I
draft
says
that
you
can
implement
split
mode
either
using
the
encrypted
Z
hat
or
by
sharing
just
pre
sharing.
That
was
dumb
if
I
did
bring.
M
B
B
So
the
proposed
architecture
here,
which
is
completely
lifted
from
the
es
ni
draft,
is
to
simply
use
a
PSK,
that's
pre-arranged,
somehow
between
the
load
balancer
in
the
backend
to
encrypt
some
proxy
data,
which
is
basically
just
a
bag
of
data,
and
that
includes
things
you
need
in
order
to
answer
the
yes
and
I.
If
you're
doing
yes
and
I,
it
includes
the
client
IP
address
if
you
would
have
otherwise
used
the
insecure
proxy
protocol
and
the
backend
just
does
some
symmetric
crypto
to
decrypt
and
use
that
info.
So
this.
B
This
is
what
the
draft
says
currently
and
in
response
to
the
draft.
There
was
some
very
thoughtful
and
detailed
analysis
on
the
list,
and
a
couple
of
other
architectures
were
proposed
next
slide,
so
one
proposal
which
I
believe
was
made
by
Stephen
Farah.
This
is
my
attempt
to
capture
a
proposal
by
Stephen.
B
Farrell
is
to
simply
do
TLS
in
TLS,
so
rather
than
specifically
encrypting
the
proxy
data
open,
a
new
TLS
section
between
the
load,
balancer,
the
backend
right,
the
proxy
data
into
that
stream
and
then
write
the
client,
hello
and,
and
everything
that
follows
from
the
client
and
similarly,
the
downstream
responses
from
the
server
would
be
in
TLS
would
be
decrypted
and
forwarded
to
the
client.
So
this
is
is,
is
very
clear.
I
think
it's,
the
the
cryptographic
properties
are
nice
and
clear,
but
it
is
computationally
intensive.
We're
spending
a
lot
of
time,
encrypting
ciphertext
again.
H
D
B
That
there
is
a
draft
in
the
quick
working
group
related
to
load
balancing.
I
think,
eventually,
we
are
going
to
have
to
square
these
two
concepts.
I
think
that
the
load
balancer
draft
and
the
quick
work
group
so
far
I
think
addresses
largely
separate
issues,
mostly
related
to
connection
ideas
and
my
diction.
It's.
B
V
Air
to
pee
on
there
was
some
theoretical
research
like
I,
don't
know
how
else
to
say
this.
That
was
done
before
quick
was
announced
to
the
IETF
about
client.
There's
our
intermediary
assisted
packet
loss
stuff,
which
has
many
very
similar
properties
and
I,
suspect
that
you
should
look
that
up.
Okay,.
B
Next
slide,
so
that
another
alternative
architecture,
this
is
my
attempt
to
capture
a
proposal
described
by
Martin
Thompson,
is
to
use
an
Oracle
to
decrypt
the
yes
and
I
in
the
simplest
implementation.
That
would
mean
that
the
connection
is
forwarded
to
the
back-end
completely
unmodified,
and
then
the
back-end
contacts
an
Oracle
and
asks
it
to
decrypt
the
yes
and
I
information.
B
B
B
The
my
questions
are:
should
we
be
pursuing
this
at
the
ITF
in
TLS,
especially
given
that
we've
also
been
talking
about
what's
appropriate,
to
go
inside
the
ESI
draft?
In
my
view,
there
is
an
interoperability
question
here.
There
is
essentially
existing
work
in
the
form
of
the
proxy
protocol
for
communication
on
this
link.
C
Long
Thompson
I'm
not
gonna,
get
up
to
talk
about
the
details
of
the
protocol,
but
I
think
we
also
have
a
third
question,
which
is
an
organizational
one
which
is
where
work
like
this
happens.
If
we
have
working
a
quick
working
group
that
is
addressing
a
very
similar
use
case,
it
seems
to
me,
like
this
straddles
this
working
group
and
that
one.
It
would
not
surprise
me
if
there
were
other
people
that
had
similar
similar
uses.
Maybe
maybe
this
is
something
that
needs
to
go
to
sec
dispatch
or
dispatch
or
I.
B
B
Perhaps
what
I
see
area
directors,
that's
very
helpful,
but
perhaps
some
of
the
considerations
ought
to
be
what
the
security
problem.
How
much
is
a
security
protocol
versus
like
an
application
information
protocol?
My
suspicion
is
it's
actually
a
security
protocol
based
upon
the
comments,
but
other
things
like
that
that
if
we
don't
think
about
the
security
aspects,
we
may
be
sad
people,
but
it
may
also
be
the
case
that
the
the
question,
the
security
questions
are
well
isolated
and
can
be,
you
know,
can
be
handled
separately.
M
H
Jonathan
oeid
and
clapper
again
I
do
think
that
there's
like
in
three
drafts-
and
there
are
six
currently
adopted-
drafts
that
all
do
basically
a
very
similar
thing
from
a
theory
level
in
terms
of
like
finding
stuff
into
TLS.
So
maybe,
as
a
working
group
item,
we
should
start
considering
how,
instead
of
doing
exporter
keys,
we
do
some
sort
of
importer
keys
and
not
directly
but
like.
There
are
a
bunch
of
drafts
that
try
and
do
this
we
should
just
solve
it.
Q
L
Nygren
Akamai
yeah,
this
topic
has
come
up
a
few
times,
I,
remember
even
I
think
in
the
first
HTTP
workshop.
This
came
up
as
a
big
topic,
because
the
current
proxy
protocol
or
the
Kirk
proxy
protocol
isn't
really
with
air
quotes,
isn't
really
standardized
and
there
are
plenty
of
cases
where
vendors
will
ask
for
implementation
of
it,
but
in
but
the
lack
of
security
here
does
not
make
it
appropriate
in
a
bunch
of
cases
where
it's
being
used,
but
any
finding
something
that
is
efficient
enough.
L
E
L
So
if
Nygren
talking
about
I'm
gonna,
be
talking
about
a
proposed
HTTP
service
record
next
slide.
The
topic
of
this
conversation
or
the
motivation
for
this
came
out
of
a
number
of
conversations
have
been
going
on.
It
came
out
of
ES
and
Ikeys
discussion
where,
as
we're
looking
at
having
this
ES
and
I
record,
which
would
be
a
new
record
for
clients
to
go,
look
up
a
lot
of
complexity
around
how
to
handle
things
like
multi,
CDN
and
proxies
and
other
use
cases
kept
showing
up
in
it.
L
And
yes
and
I
try
to
solve
that
as
a
well.
What
ends
up
being
kind
of
a
more
holistic
problem
solely
in
the
context
of
ES
and
I
started,
creating
both
either
a
complexity
risk,
but
also
a
composability
risk
of
how,
when
some
his
next
issues
start
coming
up.
We're
gonna
have
to
try
to
cram
those
into
that
yes
and
I
record,
or
maybe
we
should
take
a
step
back
and
look
at
some
more
things.
More
generally
on.
L
If
you
can
go
straight
straight
to
quick,
rather
than
having
to
go,
go
through
it,
tcp
on
indicating
origin
default
other
than
origin
defaults
to
http,
so
that
we
just
have
this
that,
when
someone
puts
a
a
bear
name
into
a
browser
and
types
in
example.com
being
able
to
have
a
clear
way
to
say,
hey.
This
goes
straight
to
HTTPS,
without
having
to
do
that,
redirect
through
it
clear
text
HTTP
and
having
a
more
secure
default
on
next
slide.
L
So
the
approach
here
is
to
look
at
things
that
is
having
a
single
new
record
that
browsers
can
resolve
in
parallel
with
the
a
and
the
clients
can
resolve
in
parallel
with
Inc
on
in
parallel
with
Ain.
The
Inc
soiree
and
particulars
is
not
really
browser
specific.
Despite
what
this
slide
says
on
the,
but
also
look
for
some
of
the
extents
that
is
is
have
reasonably
good
usability
from
an
operational
perspective
and
has
some
performance
optimizations
baked
into
it,
so
which
we
spend
a
lot
of
time
on
the
yes
and
I
key
side
of.
L
How
do
we
make
this
so
that
doing
this
extra
lookup
minimizes
the
performance
impact
impact?
An
overhead
number
of
round
trips,
but
also
having
it
be
extensible
enough
so
that
when
we
want
to
handle
the
next
case
beside
beyond
the
few
that
have
been
identified,
that
we
can
add
this
in
in
a
reasonable
fashion,
but
also
something
that
is
compelling
enough
for
to
convince
clients
to
implement
it.
L
Because
when
talking
with
the
DNS
off
group
over
the
years-
and
they
have
a
specific
issue
around
a
the
zone,
apex
problem
and
what
and
which
they
built,
S
or
the
SRV
record
to
address
a
number
of
years
back
and
there's
some
frustration
on
the
DNS
side
of
hey.
We
created
S
or
V.
We
kind
of
meant
it
to
be
for
the
HTTP
use
case.
L
Client
never
really
started
using
it,
and
so
something
that
can
break
this
chicken
in
the
egg
of
of
ok,
we're
gonna
introduce
in
your
record,
but
convinced
both
enough
clients
to
implement
it,
but
enough
server,
operators
and,
and
yes
providers
to
implement
it,
may
help
them
get
past.
Some
of
the
standoff
here,
but
also
gives
and
I
think
another
goal
is
look
at
Israel
way
to
to,
especially
as
clients
start
using
doe
or
other
things.
Is
there
a
way
to
have
more
more
secure
defaults?
L
We
can
move
to
this
help
close
out
some
of
these,
these
kind
of
insecure
by
default
straight
to
http
and
then
having
to
upgrade
up
to
our
use
cases
next
slide.
So
the
general
approach
here
on
has
is
you
can
look
at
it
as
being
somewhat
similar
to
extensible
SRV,
it's
that
and
a
reminder
here.
Is
it
within
DNS?
If
you
get
a
bunch
of
if
you
get
a
bunch
of
individual,
our
our
sets
back,
there's
no,
wouldn't
necessarily
associate
them.
L
So
if
you,
if
you
do
a
resolution
for
a
a
es
and
I
record
meu,
do
a
resolution
for
a
record
and
a
quad
a
record
on
there's
no
way
to
determine
that
those
actually
came
from
the
same
source
in
a
multi
CDN
case.
Some
of
those
may
have
come
from
one
CDN.
The
others
may
have
come
from
the
other
CDN.
So,
if
fundamentally,
what
you
need
to
do
is
have
something
where
you
have
a
single
resource
record:
that
kind
of
binds
the
number
of
attributes
together.
If
you
look
at
even
SRV
SRV.
L
The
I
won't
go
into
great
detail
in
in
this
here.
This
was
probably
more
some
of
these
details
of
being
talked
about
in
more
detail
in
in
the
DNS
and
DNS
op
and
HTTPS.
There
are
two.
There
are
two
forms
for
this:
I
won't
go
into
great
detail
on
this
forum,
but
if
next
slide,
the
alternative
services
forum
is
the
one
that
the
on
yes
and
I
keys,
which
would
come
into
play
for
the
HTTP
use
case.
There's
a
within
it.
You
have
a
service
roommate,
a
a
service
name.
L
L
If
I
fundamental
I
think
there's
a
it
makes
sense
to
separate
out
the
ESN
Ikey
format
itself
from
the
way
we're
distributing
it
through
DNS
and
looked
like
some
of
the
most
recent
draft
versions,
at
least
pull
some
of
the
DNS
extensions
out
of
that
that
record
and
then
the
question
becomes.
What
do
we
do
about
the
DNS
records
here?
L
I
think
I
see
there
being
a
few
different
options
here,
one
of
which
is
to
say
that
you
have
purse
a
per
application
protocol
binding
that
says
the
described
would
describe
how
you
would
want
to
use
on
yes
and
I
keys
for
a
given
protocol.
So
for
HTTP
we
could
say:
go
use
the
HTTP
service
record
and
then
there
could
be
a
generic.
You
know
simpler.
Finding
that
says,
hey
go.
You
see
yes
and
I
record.
Another
option
here
is
there's
been
some
interest
of
saying.
Ok,
HTTP
service
seems
useful
for
other
use
cases.
L
Next
Inc
terms
of
next
steps
when
I
wrote
these
slides
I
thought
that
http-based
we're
gonna
be
talking
about
this
afternoon
might
be
the
best
home
for
adoption
for
this
on
after
talking
into
DNS
in
DNS
off
and
talking
to
the
dots
and
the
chairs,
it
may
actually
be
that
DNS
off
is
a
better
home
for
that
and
the
DNS
up
and
HTTP.
This
chairs
are
talking
on
that
front.
There's
a
a
place
in
github
where
we've
been
working
on
this
until
we
get
it
adopted
in
a
particular
place.
L
There's
a
on
the
name
server
side:
the
on
the
DNS
are
there's
been
interest
in
this,
especially
because
it
solves
some
other
problems.
They've
been
interested
in
on
so
there's
a
bind,
nine
private
type
implementation
they
got
done
by
Mark
Andrews
and
in
the
hackathon
someone
did
an
unbound
implementation.
D
L
L
D
There
was
a
proposal
for
yes
and
I
for
the
multi
city
and
problem
and
well
the
were
two
proposals.
One
was
embedding
the
addresses
in
the
yes
and
I
record
and
the
other
one
was
like
advertising
a
separate
name
or
whatever,
and
the
reason
the
second
one
was
in
big
was
that
it
would
require
two
resolutions
and
that
wasn't
like
a
good
idea
and.
L
If
you
do,
if
you
strut,
if
you
structure
and
there's
some
recommendations
in
the
draft
of
history,
if
you
structure
things
right
on,
you
do
have
you
and
we
took
I
think
there
was
some
discussion
on
this
and
some
experimentation
on
this.
In
the
it's
a
nice
side,
you
can
get
cases
where,
where,
if
you
do
those
in
parallel
the
you
can
get
or
you
may
be
able
to
get
a
reasonable
enough
hit
rate
that
you
that
it's
not
that
bad
performance,
wise.
B
For
sending
this
I'm,
certainly
more
than
happy
to
outsource
the
work
of
DNS
hacking
to
again
as
people
as
long
as
it
actually
meets
our
requirements,
so
I
think
you
know
the
is
also
under
indicated.
The
reason
we
selected
the
current
design
was
because
we
felt
like
that
was
going
to
have
the
highest
probability
of
getting
you
an
answer
in
the
time
frame
the
efficient.
If
it
turns
out
that
that
assumptions
are
incorrect,
certain
look.
A
different
thing
seems
like
the
question
of
whether
inlining
is
possible.
B
Well,
certainly,
there's
you
say:
there's
no
reason
this
can't
contain
inlining,
so
it's
perfectly
compatible
with
that.
If
that's
the
way
you
decide
to
go,
I,
don't
really
understand.
Quite
the
relationship
between
TLS,
which
would
be
the
first
consumer
of
this
and
DNS
apple
wrapper
would
be
the
you
know.
Ultimate
producers
of
it
and
I
want
to
make
sure
that
that
rich,
it
was
well
specified
and
if
we
didn't
end
up
back
up
way
behind
something
that
was
very
complicated
or
complicated.
B
There
was
in
take
a
very
long
time,
another
working
group
because
we
serve
a
lot
of
deployed
yes
and
I
relatively
rapidly.
So
those
you
my
concerns,
but
if
we
can
manage.
J
L
L
Saying
for
the
HTTP
use
case.
Here
are
some
additional
ways
to
use,
if,
possibly
as
it
as
one
general,
one
HTTP,
our
name
and
one
or
one
HTTP
specific,
are
our
type
and
one
more.
Generic
are
our
type
that
have
roughly
the
same
form
roughly
the
same
or
have
the
same
format,
but
has
some
additional
semantics
layered
on
for
HTTP,
I,
guess.
J
L
Things
that
are
HTTP
specific
in
this
are
the
that
we
use
the
all
types
SVC
formatting
for
it
and
that
the
treating
the
that
not
using
the
underscore
labels
for
the
HTTP
443
scheme,
so
that
you
so
that
that
you
can
just
to
deal
with
some
of
the
wildcard
use
cases
for
it,
as
well
as
the
the
HHS
GS
style
for
proposed
default.
Behavior
Thanks.
P
As
I
mainly
I
think
you,
you
started
from
sort
of
an
SRV
record
and
that's
why
it
looked
me
that
the
sort
of
redirect
host
is
mandatory
in
this
textual
format.
But
why?
Why
do
we
need
that?
Why
do
we
need
to
name
say
that
the
CDN
like
I,
so
I'm,
assuming
your
stuff,
the
IP
address,
is
in
there,
because
that
makes
sense,
but
I
don't
understand
why
it's
not
just
a
blob
of
key
values
on
the.
L
P
You
don't
know
because
let's
say
that
I've
just
got
one
server
like
you
can
look
up,
it's
a
record
and
you
can
look
up
its
HTTP
SRV
record,
which
gives
you
a
bunch
of
other
information
like
I.
Don't
need
one
I,
don't
need
this,
redirect
name
and
like
I
wouldn't
need
IP
addresses,
but
obviously,
if
you've
got
multiple
CD
ends
and
sticking
IDs
makes
in
that
makes
sense.
I
don't
understand
why
this
host
name
field
is
mandatory
in
this
record
value
and.
L
AA
Tommy
Polly
Apple.
So
thank
you
for
sharing
this
in
a
very
fun
but
I'm.
Definitely
in
the
camp
of
people
who
says
this
should
be
a
generic
thing.
I
think
that
doesn't
it
core
sense,
so
just
+1
to
all
of
that
yeah
and
I
think
just
with
regards
to
how
much
is
in
line
versus
somewhere
else.
Maybe
one
way
of
kind
of
breaking
that
up,
because
I
think
there
are
a
lot
of
other
things.
L
I
think
to
some
of
the:
why
do
we
have
names
rather
than
IP
addresses
also
goes
to
that,
because
the
others
like
an
example
of
that
case
would
be
if
you
have,
if
you
want
to
advertise
both
h2
and
and
HTP,
1,
1
and
and
quick
for
a
set
of
a
and
quad-a
odd
records.
You
may
like
combinatoric
lee
you
otherwise
end
up
with,
and
I
think
you
end
up
with
a
potentially
huge
set
of
things
and
having
that
indirect
level
of
abstraction
helps
address
that
and
I
think
like
for
the
ESI
key
itself.
L
One
of
the
questions,
because
is
that
do
you
in
line
of
basics?
Before
of
that
or
do
you
have
a
name
reference
or
do
you
allow
either
case
on
Bulow,
either
case,
because
I
think
there's
a
trade-off
between
the
performance
impact
of
doing
in
Direction
versus
message
size
on,
especially
in
the
face
of
caching
right.
AA
AB
You
radically
a
plus-one
to
making
this
more
generic
I
think
that
sort
of
argues
against
putting
an
HD
abyss
but
could
be
either
Indiana
self
or
TLS.
I
want
to
point
out.
Maybe
that
you
know
perhaps
everyone's
aware
of
this
already
but
like
yes
and
IKEA,
is
a
property
of
the
IP
address
not
of
the
name.
So
it
does
seem
more
sort
of
straightforward
that
the
IP
address
be
in
here,
because
otherwise
you,
basically
when
you
do
a
parallel
implementation,
you
do
an
a
and
Akane
and
in
a
service
record
lookup.
AB
But
if
you're
unlucky
and
the
chordae
for
you
get
the
quad-a
for
a
different
CDN,
then
you're
like
oh
wait.
You
have
to
basically
walk
the
intermediate
cname
chain
of
the
of
the
of
the
HTTP
service
record
and
then
do
another
look
up
for
a
quad-a
for
the
name
that
you
had
and
so
that
the
CDN
Empire
is
good
or
you
get
lucky
it's
efficient.
But
if
not
and
it's
very
complicated
to
implement
on
the
client
so
+12
putting
IP
addresses
in
there.
I
guess.
AD
Dan
York
internet
society,
but
not
speaking
for
Internet
study
and
so
to
Lorenzo
and
Adams
case
I'm.
Somebody
who
wants
the
the
domain
name
in
there,
because
I'm
from
the
DNS
side
and
I
want
to
use
this
for
the
cname
at
Apex
fixed
to
be
able
to
point
for
our
food
comm
over
to
a
CDN
in
some
case.
So
that's
where
I'm
looking
for
that.
My
question
for
you,
though
Eric
and
thank
you
for
presenting
this
work
in
these
places
and
doing
all
this
will
require
client
implementation
across
all
the
clients.
L
AD
L
Been
having
some
Congress
we've
been
having
conversations
with
in
with
some.
Certainly
some
browser
clients
haven't
yet
had
that
as
many
conversations
with
non
browser,
clients
like
and
one
one
I
think
the
in
one
at
least
one
conversation.
It
was
clear
that
that,
when
you
stir,
when
you
start
having
a
fairly
rich
stack,
that
provides
an
abstraction
like
an
HTTP
abstraction
or
a
top
style
abstraction
that
you
can
fit
this
sort
of
thing
into
that
abstraction.
AD
I
mean,
and
so
I
would
I
hope,
other
people
who
are
here
who
have
clients
that
could
consume.
This
will
be
talking
to
you.
My
one
concern
just
looking
at
it
is
that
you
are.
It
is
capable
of
solving
a
good
number
of
different
use
cases,
and
with
that
comes
the
complexity
of
implementation.
That
I
think
we
just
there's
I,
guess
a
question
on
mind
around
the
scope
of
it
and
how
how
much
how
many
of
those
use
cases
we
really
try
to
solve
with
this
these
here
doing.
AD
L
I
think
that's
also
a
balance
on
how
general
to
make
it
cuz
the
more
general
it
starts
becoming
as
we've
seen
with
many
things
here,
the
more
risk
you
start
having
of
having
it
be
way
too
complicated
on
the
client
side.
One
one
reason
why
I'm
somewhat
less
concerned
about
the
that
that
some
of
the
client
complexity
is
is
for
enough
of
the
use
cases
for
enough
of
these
cases
that
want
it
I'm
having
robust
client
libraries
that
people
can
use
that
handle
things
like
TLS
verification,
well
and
DNS
in
connection
management?
L
Well,
it's
probably
it's
going
to
become
increasingly
important
because
a
lot
of
the
people
who
do
the
hey
I'm,
just
going
to
use
some
of
the
underlying
primitives
directly
without
really
understanding
them
well
have
there
seems
to
be
an
increasing
risk,
as
those
primitives
started
getting
more
and
more
complex
that
that
they
won't
do
some
of
this.
They
won't
understand
the
caveats
and,
for
example,
won't
do
Saint
Els
at
Vassar
verification,
we're.