►
From YouTube: IETF115-TLS-20221110-0930
Description
TLS meeting session at IETF115
2022/11/10 0930
https://datatracker.ietf.org/meeting/115/proceedings/
A
So
yeah
in
case
anybody's
afraid
of
taking
notes.
All
we
really
care
about
is
the
decision
points
you
don't
really
need
to
do
the
play-by-play
there's
some
people
in
here
that
speak
pretty
quickly.
So
I
don't
know
if
that
helps
anybody
willing
to
well.
Thank
you,
I
mean
don't
work,
don't
get
me
wrong,
I'm,
one
of
those
people
that
speaks
really
fast
to
you,
but
I
appreciate
it.
Thank
you.
A
A
Also
I'll
be
watching
the
zulup
room,
but
if
anybody
else
wants
to
help,
so
if
anybody
wants
anything
on
the
mic,
then
they're
in
the
in
the
chat
room
you
can
put.
You
know,
Mike
colon
and
then
your
comment
and
we'll
get
it
right
out
at
the
microphone
and
if
we
miss
it,
keep
pestering
us.
B
All
right,
I
think
we're
going
to
get
started,
welcome
to
TLS
at
ietf
115..
B
If
you're
watching
this
already,
you
probably
already
know
about
the
meeting
tips,
but
please
we'd
like
to
use
the
the
the
tool,
the
on-site
tool
to
keep
track
of
the
meeting
queue.
So
please
join
that,
so
your
attendance
is
taken
and
so
that
you
can
put
yourself
in
the
line
to
go
speak
at
the
mic.
C
B
Need
here
let's
see
and
please
note
The
Mask
policy
and
please
wear
your
mask
when
you're,
not
speaking.
B
By
this
time,
you
should
be
familiar
with
the
note.
Well,
so
just
a
reminder
of
a
code
of
conduct
and
rules
of
participation.
B
There
we
go
so
TLS
working
group
has
been
pretty
good
in
recent
times,
but
we'd
like
you
to
make
sure
that
you
please
treat
each
other
with
respect
and
keep
the
contributions.
Technical.
B
Okay,
I
think
we
have.
We
have
two
note
takers.
Even
this
is
going
to
be
a
great
meeting
and
again
log
into
the
on-site
tool
and
also
when
you
speak
at
the
mic.
It's
always
good
to.
Let
us
know
who
you
are
so
that
we
can
note
it
in
the
minutes
properly.
B
We
do
have
a
fairly
full
agenda,
but
we
should
be
able
to
get
through
it
all
I
think
in
our
time.
A
So
since
last
time
we
had
two
rfcs
published,
they
were
actually
published
during
the
the
week,
the
days
after
the
the
last
time
we
met,
but
it's
RFC
9257
guidance
for
external
pre-shared,
Keys
usage
in
TLS
and
an
accompanying
one
that
was
9258
for
importing
external
pskas
for
Tails
1.3.
A
We
have
delegated
credentials
in
the
queue
Nicks
out
for
a
couple
of
months,
but
Richard
Barnes
has
nicely
agreed
as
co-author
to
kind
of
as
one
of
the
co-authors
to
take
over
and
Shepherd
that
through
so
we're
in
the
process
of
trying
to
get
that
done.
We
have
two
drafts
that
are
kind
of
paused.
A
Maybe
we
could
consider
redoing
those
after
we
get
this
current
crop
done.
The
rrc
for
TLS,
1.3
and
1.2
draft
is
through
working
group.
Last
call
I
actually
think
through
multiple
working
group
last
calls.
It
is
waiting
on
me
to
do
the
write-up.
I
will
get
that
done
shortly
and
then
we'll
progress
that
forward
I
did
note.
Already.
There
were
a
couple
of
things
missing
out
of
it
like
there's,
not
a
security
consideration,
so
we
kind
of
got
to
fix
that
before
I.
Send
it
to
fall.
A
Compact
TLS
has
expired,
I,
don't
I,
don't
think.
That's
means
it's
going
away
permanently.
I
just
think
that
we
we,
the
authors,
got,
got
busy
doing
something
else,
and
today
we're
going
to
talk
about
84,
46
bits,
84,
47,
bits,
the
well-known
ech
config
list
and
another
draft
the
encrypted
client
hello
is
kind
of
in
pause
mode.
A
At
this
point,
while
they're
still
getting
implementation
experience
and
the
hybrid
ke
in
TLS,
1.3
is
kind
of
in
the
same
boat
and
snip
I
think
we're
just
kind
of
there's
not
much
to
it.
We're
just
kind
of
waiting
for
people
to
like
see
what
they
think
about
it
and
then
eventually
we'll
get
to
it.
So
I'm,
hoping
maybe
in
the
next
cycle,
Maybe
by
March
or
slightly
after
March,
we'll
be
moving
that
one
forward.
Next,
please.
A
And
we
have
two
expired
drafts,
so
maybe
at
the
end,
if
we
have
some
free
time,
we
can
talk
about
them
is
David
Benjamin
here,
but
anyway
we
can
maybe
talk
about
these
two
drafts
because
they
were
things
that
we
adopted
and
they
kind
of
stalled,
and
that's
it
so
I
think
now,
unless
there's
any
questions
or
any
further
agenda,
bash
we're
gonna
hand
it
over
to
Ecker
to
talk
about
8446
bits.
D
So
just
since,
since
we
asked
about
ctOS
yeah,
this
is
still
a
live
item.
I
just
proved
in
PR's
for
been
there
today
and
I'm,
not
I
think
he
may
have
just
forgotten
just
a
minute
because,
like
like,
he
was
like
approve
my
PR
as
like
in
public,
so
I
think
he
just
forgot.
So
we
can.
We
can
take
care
of
that.
D
D
So
the
current
status
is
I
had
a
bunch
of
outstanding
PRS
I
merged
them.
Nobody
seemed
to
eject
I,
did
run
someone
by
people
check
the
change
log.
If
you
disagree
and
of
course,
we'll
have
a
working
across
call,
so
you
could
disagree.
Then
there
are
a
few
outstanding
PRS
and
open
issues
which
I
hope
to
mostly
resolve
now,
with
the
objective
of
like
cranking
on
new
version
and
being
done
next
slide.
D
So
I'm
just
going
to
work
through
the
things
that
are
that
continue
to
be
outstanding
is
that
they
are
so
first
we
had
this
PR
1275
or
on
unsolicited
extensions.
D
So
the
the
backstory
here
is
that
the
I
thought
the
text
was
supposed
to
say
and
I
think
everybody
else
thought
the
texture
was
supposed
to
say
that,
basically,
you
couldn't
send
extensions
that
the
other
side
hadn't
offered,
but
when
we
rewrote
the
text
to
sort
of
talk
about
request
and
response
extensions,
the
Jonathan
hoylan
felt
that
so
on.
D
Your
call
that,
like
so
the
pattern
here
is
like
ch,
contains
like
offer
like
requests
and
ee
contains
responses
and
Jonathan
hoyland
I
think
came
to
conclusion
that
perhaps
you
could
send
extension
requests
that
were
in
request
mode
in
ee
because
they
were
request,
not
responses.
That
was
not
the
intention,
so
this
PR
basically
attempts
to
make
that
clear.
D
It
was
actually
Bank.
It
was
for
that
clarification.
I,
don't
see
him
here.
So
if
anybody
disagrees
with
assumptions
here,
you
know
please
say
so,
and
if
you
don't
describe
the
substance
here,
you
know
take
a
look
at
the
text
or
don't
and
I'm
going
to
merge
it.
D
D
We
realized
afterwards
that
those
update
limits
actually
apply
just
as
well
to
TLS,
and
so
we
pulled
them
in
here
we
had
some
text
that
kind
of
went
through
like
the
process
and
I
merged
it
in
and
Mt
was
sort
of
I
and
I
put
a
PR
up
for
It
MTV,
like
this
text,
isn't
actually
very
good,
which
I
think
it
has
some
Merit
as
a
point,
so
I
think
there's
really
a
question
of
like
do.
D
We
want
to
just
like
not
be
consistent
versus
try
to
work
this
text
I
can
go
either
way
if
anybody
I
feel
strongly
about
it
and
now's
a
good
time.
D
Otherwise,
Martin
and
I
will
just
work
it
out
great
next
up
we're
going
to
burn
right
through
this,
so
we
had
a
bunch
of
discussion
about
what
to
do
with
bogus
tickets
and
in
the
last
time
we
discussed
this
I
suggested
we
should
add
a
new
alert
that
would
say
like
invalid
ticket
or
ticket
invalid,
or
something
and
I
in
fact
wrote
up
a
PR
for
that
which
is
this
PR
and
then
the
process
that
I
noticed
we
actually
added
previously
unknown
psk
identity
between
80,
40,
46,
8446
and
here,
and
so
my
claim
is
that
does
the
job
for
this,
and
maybe
a
word
Smith
around
they'll
text
around
it.
D
Finally,
we
have
a
PR
from
John
Matson
about
there's
all
this
text
about
how
you
can't
use
psks
with
certificates
and
8773
updates
that
and
the
text
kind
of
says,
like
you
can't
do
it
unless
there's
a
extension
that
says
you
can
do
it,
an
a773
says
you
can
do
that
in
light,
is
sort
of
the
confusion
about
the
exact
security
properties.
This
I
need
to
carefully
review
this
text,
I'd
appreciate
if
someone
else
would
too
but
I
think
generally.
This
is
like
probably
on
the
right
track.
D
D
It's
not
like
it's
super
complicated,
so
I'll,
again
I'll
bounce
off
other
people.
What
else
is
that
I
said
that
next
slide?
Finally,
we
have
two
open
issues
raised
by
David
Benjamin,
clarifying
the
behavior
hrr
I'm,
not
here
to
tell
you.
The
behavior
of
hrr
is
entirely
clear,
but
I
am
here
to
tell
you
that
after
many
discussions
we
have
not
we
have
not.
D
We
have
not
come
to
a
conclusion
that
made
anybody
happier
and
so,
and
we
discussed
last
time
the
put
was
either
someone
comes
up
with
a
proposal
to
actually
improve
this
text
that
we
can
agree
on
which
nobody
has
done,
or
we
just
say,
like
Hey
we're
going
to
leave
it
the
way
it
is
I
want
to
free
frame
this
discussion
by
pointing
out
that
the
purpose
of
this
draft
is
to
clarify
8446
and
make
it
better,
and
this
text
is
the
same
text
as
an
8446
which
is
no
worse,
and
if
we
can't
improve
it,
we
are
clarifying
A
lot
of
other
things
and
so
being
finished
is
a
feature
and
I
propose
you
defer
these
and
then
we
can
always
if
people
feel
like
that
to
clarify
even
more
later,
we
can
do
so.
D
My
my
suspicion
is:
this
will
turn
out
to
be
pronouncing
a
substantive
change,
not
just
a
clarification,
and
so
probably
like
I
prefer
to
defer
someone
feel
strongly
about
it,
and
David
and
I
talked
about
this
a
bit
and
he
didn't
have
any
I
think
so
you
know
everybody
sort
of
timed
out
when
I
talked
to
David.
He
was
kind
of
like
I.
D
Don't
even
remember
exactly
what
I
wanted
to
do
here
so
never
be
trying
to
reconstruct
the
state
here
seemed
very
difficult,
so
I
posted
it
for
these
this
is
it
so
I'm
not
hearing
any
objection
to
any
of
this
stuff.
So
this
is
like
your
next
to
last
call
for
this
oh
empty.
E
D
Think,
probably
very
difficult:
fine,
okay,
so
I
will
I
will
finish
these
things
and
I
will
produce
a
new
draft
and
we
can,
let's
call
it
so.
A
I'll,
let
you
know
that
my
long-term
plan
is
is
not
to
stick
Ecker
with
this.
This
idea,
but
I'd
like
to
move
this
to
internet
standard
I,
know
some
of
you
think
that's
great.
Some
of
you
could
give
a
sorry,
but
good,
don't
care
less,
but
in
six
months
we
can
do
a
protocol
action
and
just
move
it,
because
there
is
enough
deployment
and
there
is
enough
interoperability.
I
may
need
to
lead
on
some
of
you
to
make
sure
that
the
features
are
actually
all
implemented
properly.
A
G
David
schenazi
deployment
Enthusiast.
If
we've
managed
to
make
IPv6
a
full
standard,
we
can
probably
make
trs13
a
full
standard.
Well,.
D
A
B
All
right,
so
this
is
for
RFC
84
47
bits,
which
is
the
ionic
considerations
for
TLS
1.3
So.
Currently
this
draft
is
written
so
that
it
obsoletes
8447,
which
means
it
takes
all
of
the
text
from
8447
and
then
tries
to
modify
it
in
place,
which
is
really
kind
of
very
confusing
and
difficult
to
read
and
difficult
to
review
and
I.
Think
it'll
be
difficult
for
Ayanna
to
apply
so
I
kind
of
I'm
proposing
we
just
make
it
update.
So
we
can
just
include
the
changes.
B
A
Now
I
mean
I
I
think
this
is
kind
of
an
editorial
thing
and
again
remember
this
whole
document
is
instructions
for
Ayanna
and
at
the
end
of
the
day,
whatever
is
easier
for
them
to
understand.
I
think
is
probably
a
good
thing
and
they're,
like
should
was
updates
throughout
the
document
made
it
kind
of
confusing.
You
know
like
at
least
the
Laurie
was
like.
What
are
you
trying
to
say
here
so.
D
Hope
people
will
forgive
me
not
getting
the
queue
I'll
do
that
shortly.
I've
seen
a
number
of
times
when
the
isg
gets
very
bad
out
of
shape
about
these
kind
of
diff
documents,
and
so
I
guess
I
would
just
like
make
sure
our
ad
is
happy
with
that
with
that
plan,
because,
if
they're,
if
not
then
like
we'll
be
you
know,
we
then
we'll
be
back
here
like
in
two
months,
so
I
don't
object
but
like
I,
just
like
want
to
make
sure
I
fly
that
okay.
F
G
I
Follow-Up
is
80.,
so
normally
the
reason
for
a
div
document
is
that
people
are
afraid
that
they're
going
to
open
up
a
can
of
worms
on
other
changes
in
the
document,
and
so
they
just
want
to
specifically
say
this:
if
that
div,
we
don't
want
to
read,
argue
and
we
discuss
the
entire
other
bulk
of
the
document.
I
think
it
doesn't
apply
here.
So
in
that
sense,
I
think
the
diff
does
not
make
any
sense
whatsoever.
B
Yeah
great
yeah,
so
we'll
we'll
get
this
revised
as
an
update
so
that
it
is
clearer
within
the
next
couple
weeks,
rich.
What's
up
rich.
F
Hi
Rich
Sauls
is
one
of
the
designated
experts.
It's
not
just
Diana.
Who
cares
and
it's
fine
if
it's
simpler,
it
seems
I've
read
both
versions
and
yeah.
We
can
follow
the
directions
either
way.
B
B
Next
slide,
so
we
added
some
text
as
to
what
d
should
mean
so
because
now,
if
you
remember,
we've
added,
we
have
in
the
recommended
column.
Yes,
no
and
d,
and
here
we
say
d,
the
item
is
discouraged
and
should
not
or
must
not
be
used.
B
That's
the
text
that
we
propose
right
now
we'll
have
time
to
resolve
that.
But
if
people
have
comments,
it
would
be
great
to
get
them
now.
E
Yeah
go
ahead:
yeah
yeah,
whatever
I'm,
not
the
cue
thing
takes
too
long
to
get
into
so
who
chooses
the
should
or
the
must
or
the
should
not
on.
The
must
not.
Is
that
just
based
on.
B
Yeah
I
think
it
was
intended
I.
Don't
remember
why
we
did
this
I
think
it
was
intended
that
it
depends
on
what
the
context
is.
You
might
have
some
items
that
are
are
discouraged
and
they're
only
applicable
in
certain
contexts.
So
unless
you're
in
that
context
of
you
know,
yeah.
E
It's
kind
of
weird
to
put
sort
of
normative
language
in
the
registry
in
this
way,
because
it
applies
to
things
that
have
their
own
each
one
of
the
things
with
a
D
in
there
probably
has
a
document
describing
why
it's
bad
idea
right.
So
maybe
just
like
end
end
of
the
sentence.
B
B
B
Any
other
comments.
B
All
right,
then,
we'll
we'll
reorganize
this
so
that
those
normative
should
nuts
and
must
knots,
are
not
there
anymore.
Next,
then,
we,
we
also
added
some
text
to
the
policy
registration
policy,
saying
that
as
standards
action.
B
Oh
sorry,
that
isg
approval
is
required
for
transitions
from
yes
to
no,
yes
to
discouraged
or
discouraged
to
yes
or
no,
and
we
probably
could
clarify
that
text
a
little
bit,
but
that's
the
policy
that
we
have
outlined
for
this
and
I
think
that's
reflects
what
we've
discussed
previously.
B
I
B
B
E
Not
simply
say,
I
asked
you,
approval
is
necessary
for
all
other
state
transitions.
C
So
I
I
reviewed
this
text
because
we
were
copy
and
pasting
it
for
MLS
and
I,
convinced
myself,
at
least
that
it
did
cover
all
the
state
transitions
because
it
talks
about
entering
the
y
or
n
States
requiring
approval
and
then
the
conditions
for
moving
from
either
of
those
to
D.
So
I
think
I.
Think
that
covered
all
three
legs
of
the
triangle.
E
Yeah
I
I
think
I'd
prefer
if
it
was
a
little
clearer,
I
think
the
goal
is,
you
know:
isg
approval
for
all
State
transitions
and
then
standards
action
for
for
getting
a
y.
That's
so.
B
You're
saying
for
All
State
transitions
it's
this.
Basically,
this
last
sentence
should
be
for
all
their
state
transitions.
Isg
approval
is
required.
J
E
If
you're
going
from
D
to
y
That's
standards,
action,
which
is
in
contradiction
to
the
next
sentence,
already
yeah
yeah
right.
I
So
it
may
take
a
little
bit
Paul,
just
speaking
as
myself,
is
there
a
reason
like
if
you're
redoing
this
part
anyway?
Is
there
a
reason
why
we're
using
one
letter
abbreviations
like?
Are
we
trying
to
save
money
on
the
website.
A
So
it
fits
in
the
columns,
I
mean
it
just
it's
a
it
looks
horrible
when
you
put
it
in
the
document
spins
across
there's
a
note
in
there
to
explain
what
it
is
so
yeah
it's
just.
It
is
a
single
letter
that
we
have
in
the
column
because
they're
so
long
and
like
think
of
The
Cypher
Suite
names,
but
there's
other
places
where
it's
explained.
What
that
means.
B
We
we
could
expand
it
out
here,
but
in
the
in
the
call
middle
I
think
it's
better
for
a
single
letter.
G
David
David
schenazi,
so
that
from
looking
this
looks
like
it's.
Your
last
slide
and
I
followed
an
issue
on
the
document
a
few
weeks
ago
and
no
one
has
commented
on
it.
So
I
figured
I'd
just
come
and
tell
you
all
about
it.
So
I
can
get
opinions,
which
is
the
Explorer
labels
registry
is
currently
specification
required
and
we
were
using
an
Explorer
for
something
internally
at
Google
and
I
was
like
well
crap.
Now
we're
just
gonna
squat
on
it,
because
we
just
can't
put
a
create
a
specification
for
this
specific
thing.
G
Given
that
it's
a
string
registry
with
infinite
room,
can
we
just
make
it
expert
review
since
we're
opening
the
can
of
worms,
feel
free
to
tell
me
it's
how
to
scope.
B
G
I
mean
not
not
currently
it's
the
entire
thing.
Okay,.
D
Well,
David,
you
can
just
generate
a
random
uid
and
put
your
things
after
it.
So
I
think
for
so.
First
of
all,
I
think
specification
requires
the
wrong
standard
in
any
case,
because
what
we've
been
doing
is
the
way
because
specification
required
is
the
I
guess
some
unclarity,
whether
it
incorporates
IDs
and
so
the
way
we
handled
it
everywhere
else.
Was
we
made
an
expert
review
and
then
said
id
is
good
enough
and
so
I
think
a
minimum.
We
should
do
that
for
this
topic.
I.
D
I
guess
I'm
Davis
used
to
think
we
didn't
I
I
haven't
checked
myself,
but
I
guess
I
would
be
supportive
of
this
change.
In
fact,
I'd
be
supportive,
I.
Think
generally
of
the
change
like,
like
I,
think
I
think
I
think
this
plan
we
had
of
like
you
know,
making
incredibly
easy
code
points
was
like
super
successful
and
you
know
and
I
actually
wonder
if
like
we
should
make
it
even
easier
and
be
like
you
know,
like
an
email
will
be
sufficient
and
like
with
no
description
of
the
mechanism.
D
You
know
you
know
these
spaces
are
not
the
reason
we
did
this,
because
these
spaces
were
not
the
reason.
So
the
reason
we
require
a
specification
was
not
out
of
some,
like
rate,
limiting
exercise,
to
make
it
hard
to
get
the
code
points
but
was
merely
out
of,
like
I,
think
a
kind
of
a
good
government
theory
about
having
a
good
to
have
things
on
the
internet
documented,
but
I
think
that,
like
maybe
that
was
like
the
wrong
Theory.
D
But
in
any
case
you
know
so
I
wonder
I,
wonder
I
wonder
if
we
should
make
an
even
bigger
car
about
this,
as
maybe
a
document
required.
The
document
could
just
say
like
need
or
neater
we're
not
going
to
tell
you
what
this
does.
I.
A
Mean
so
it
it
does,
it
does
have
the
language
that
we
have,
for
the
other
ones
is
sufficient
to
have
an
internet
draft
that
is
posted
and
never
published,
or
a
document
from
another
standards,
body
unit
consortia
University
site.
The
thing
with
spec
required
is
it's
supposed
to
be
public
you're
supposed
to
be
able
to
get
to
it
so
David's
Point,
still
kind
of
stands.
D
Right
well,
I,
guess
I
guess
I'm
wondering,
would
it
be
sufficient
to
have
to
have
a
to
have
have
a
redacted
description
of
the
protocol
and
again
like
maybe
maybe
the
answer
is
merely
first
come
first
serve
I,
guess
I
just
again,
I
do
what
I
do
want
to
encourage
people
to
have
specifications
to
be
better
for
the
internet,
but
I
also
don't
want
to
make
it
I.
Don't
think
it
serves
any
useful
purpose
to
make
it
impossible
to
get
code
points
if
you're
not
going
to
publish
what
your
thing
is.
G
Well,
I
mean
that's
why
I
was
thinking
expert
review
because
first
come
first
serve
sure.
You
probably
don't
want
me
registering
tls14
and
Ecker
stinks,
but
if
it's
you
know
anything
like
there's
no
point
in
saying
you
have
to
publish
something
and
that
thing
can
be
empty
like
that's.
What
expert
review
means
you
know.
B
Okay,
I
think
we'll
kind
of
review
this
and
I.
A
Think
submit
a
PR
and
we'll
we'll
review
it
like
every
other
time,
so
so
David's
out
yov.
K
So,
just
to
make
sure
I
understand,
standard
section
implies
isg
approval
because
all
rfcs
are
approved
by
the
ISD.
So
if
the
working
group
wants
to
do
say,
chapter
20
die
die
document,
that's
a
fine
way
of
turning
that
from
y
to
n.
I
I
So
I'll
take
this
to
the
IEC
as
a
discuss
item
because,
like
like,
we
need
to
figure
out,
but
my
view
is
that
a
draft
gets
you
at
most
an
early
allocation
and
either
your
draft
expires.
And
then
your
early
allocation
expires
or
it
becomes
an
RFC,
in
which
case
you
are
an
RFC.
So
I
don't
consider
a
draft,
a
publication
in
the
sense
of
publication
required,
but
I'm
going
to
verify
that
with
the
rest
of
the
iuc.
So.
A
A
D
Right,
one
issue
is
what
the
operational
practice
do
we
want,
and
the
operational
practices
here
to
four
has
been
that
you
need
to
describe
the
protocol
and
some
level
of
detail
in
some
some
document
which,
like
someone,
could
eventually
see,
including
an
ID,
and
that
was
the
consensus
of
working
group
in
the
consensus
of
the
ITF
and
if
we
like
wrote
the
wrong
thing
in
the
document
and
like
with
the
wrong
thing,
then
we're
like
then
we'll
call
this
review
instead
of
specification
or
whatever,
like
for
the
IEC,
to
tell
us
what
to
do
on
that
respect.
D
Right.
That's
already!
That's
already
the
way
things
are
I
think
what
we're
discussing
now
is
a
potential
change
change.
That
policy,
which
does
not
require
the
description
of
a
full
description
thing
at
all,
right
and
David
I.
Think
I,
just
wanted
to
like
I
saw
you
respond
to
what
you're
saying,
which
is
like
I'm,
trying
to
thread
a
needle
here,
which
is
I,
would
like
people
to
document
their
protocols
and
I
wish.
D
People
would
do
so
and
I
understand
they
may
not,
and
so
I'm
trying
to
figure
out
and
maybe
I'm
just
trying
to
be
too
clever
but
I'm,
trying
to
figure
out
some
way
to
sort
of
vaguely
encourage
them
to
do
so,
while
also
not
requiring
it
and
again,
maybe
I'm,
just
being
too
clever.
But
that's
that's
what
I
was
trying
to
accomplish
with
sort
of
okay,
an
empty
graph
would
be
okay,.
A
G
Right,
yes,
I
mean
like
all
of
these
are
very
well
defined
in
the
INF
policy.
Rfc
and
I
expert
review
is
fine
and
also
for
expert
review.
You
can
add
a
note
that
is
instructions
to
the
experts
that
shows
up
on
the
Anna
page
and
say,
like
a
specification,
is
highly
encouraged
there
with
forexpert
review.
That
might
be
the
simplest
way
to
do
this.
D
I
mean
just
to
be
clear:
the
purpose
the
expert
review
in
this
like
there
there
seems
to
me
that
the
purpose
expert
review
historically
has
been.
It
is
a
reasonable
allocation
size
like
are
you
asking
some
ridiculous
number?
Are
you
asking
for
a
misleading
name
and
is
the
protocol
specification
like?
Does
it
kind
of
exist
right?
And
so
what
were
you
talking
about?
Is
relaxing
that
last
that
last
Point
and
I
think
you
know
I
do
I,
I,
think
I,
don't
want
I,
think
Chris
Davis,
just
because
these
are
meaningful
strings.
D
We
don't
want
to
have
entirely.
First
come
first
serve
because
we
want
to
ensure,
like
that
that
the
first
instance
that
someone
doesn't
register
a
string
but
like
just
as
highly
misleading
for
I,
don't
actually
care
less
about
this
for
the
numeric
ones.
Where
someone
wants
to
register
three,
you
know
register.
You
know
three
one:
three,
three
atom
prefix
singers,.
B
B
Any
other
Ayanna
considerations
comments.
B
B
N
N
All
right,
so
my
name
is
Eric
battle
is
also
here
and
we
shall
never
stop
on
our
quest
to
defecate
of
Select
key
exchange
methods
in
TLS.
N
N
The
only
open
issue
is
around
groups
in
ffdhe.
Discussions
on
the
mailing
list
concluded
that
clients
are
unlikely
to
verify
the
group
structures
and
it's
too
expensive.
N
There
was
also
the
suggestion
of
creating
a
safe
list
for
all
safe
groups,
but
that
seems
impractical
or
at
least
unlikely
to
catch
all
safe
groups
on
the
entire
internet,
so
asking
clients
to
verify
the
group,
oh
about
the
connection.
If
they
can't
is
unlikely
to
work.
N
So
for
moving
forward,
first
we'd
like
to
discuss
a
reasonable
suggestion
that
was
made,
but
does
not
seem
to
have
consensus.
N
So,
in
light
of
everything
we
said,
our
suggestion
is
to
impose
no
requirement
around
the
group
structure
and
we'd
like
to
question
to
what
extent
this
even
matters
so
web
clients
have
already
disabled
ffdhea
and
are
not
going
to
bring
it
back.
N
Email
clients
are
not
going
to
about
opportunistic
TLS
connections
of
a
group
structure
issues,
and
this
single
issue
is
the
primary
thing
holding
back
the
drafts
and
surround
itf-113.
N
So
we
recommend
moving
forward
with
this
compromise.
It
is
a
compromise,
but
it
really
doesn't
matter
much.
On
the
other
hand,
this
issue
is
the
primary
reason.
There
is
still
no
IDF
document
that
formally
deprecates
RSA
key
exchange
and
deprecating
RSA
key
exchange
and
other
absolutely
exchange
methods
would
matter
a
lot.
So
we
strongly
recommend
moving
forward
with
these
suggestions,
thanks
and
I'm
happy
to
take
questions.
A
So
I
guess
to
drive
this
issue
forward.
Is
there
anyone
that
disagrees
with
the
way
forward,
as
suggested
we
can
do
a
poll
and
then
take
it
to
the
list?
But
if
nobody
I
I,
don't
know
what?
What
do
we
think
is
the
best
way
forward
here?
Maybe
we
should
just
do
a
poll
and
get
it
on,
get
it
on
record,
and
then
we
can
take
it
to
the
list
for
an
actual
consensus
call
to
kind
of
nail
this
that
sound
good.
All
right,
let
me
see
if
I
can
work.
N
Daniel,
would
you
like
to
speak?
Please
go
ahead.
N
O
So
I'm
trying
to
understand
over
in
the
chat
Europe
asks
a
reasonable
question
about
who's.
The
who's
proposing
deprecation
here
and
Ben
Schwartz.
Well,
so
I
think.
The
idea
is
that
opportunistic
TLS
clients,
you
said
email,
clients
here,
I'm,
pretty
sure
you
meet
SMTP
clients
who
are
in
opportunistic
mode,
which
is
different
than
email
clients.
O
Don't
don't
those
same
opportunistic
clients
have
the
same
concerns
about
all
the
other
key
exchange
applications
I
mean
if
you're
doing
opportunistic
TLS.
Surely
RSA
key
exchange
is
better
than
nothing.
O
O
So
you
know
your
last
question
is
who's
who's
opposing
the
deprecation?
If
the
opposition
is
coming
from
opportunistic
folks,
can
we
just
make
a
carbot
here
and
say:
opportunistic
clients
can
do
whatever
they
like
and
then
go
ahead
with
saying
the
explicit
deportation?
What's
the
like
who's
who's,
actually
blocking
the
consensus,
I'm
not
saying
bring
anything
back,
I'm
just
saying
obvious
declines
are
simply
not
going
to
do
this
right.
They
know
that
their
fallback
is
clear
text
they're
not
going
to
follow
this.
This
guy.
N
So
the
opposition
to
full
ffd
deprecation
came
mostly
from
I.
Think
Victor,
dukovy
Victor,
are
you
here
by
any
chance,
although
should
I
represent
your
position
to
the
best
on
viability.
N
All
right,
I
guess
Victor,
isn't
here
so
I
think
his
take
was
that
it's
quite
feasible
for
SMTP
clients
to
deprecate
RSA
with
their
update
cycle
which
is
low,
and
then
we
would
get
finite
field.
Dpm
one
is
I,
don't
know
if
the
primary
key
exchange
used
in
that
ecosystem,
but
like
a
a
key
exchange
with
like
a
noticeable
market
share,
and
it
would
be
with
custom
groups
because
of
advised
that
was
given
to
operators
of
of
SMTP
servers
to
generate
their
own
custom
groups.
N
N
O
O
O
O
N
Yes,
so
I'm
not
sure
I'm
familiar
with
the
policies
of
all
browsers
on
the
matter,
but
I
think
there
are
still
some
unencrypted
web
connections
somewhere
on
the
internet.
D
D
What
that's,
what
I
was
going
to
say
is:
it
turns
out
that
the
arc
that
there
are
browser
settings
now
which
will
tempt
https
first
and
then
we'll
fall
back
to
http
I.
Think
I
can
just
tell
you
we
are
not.
We
would
not
be
interested
that
that
be
that
as
it
may,
we
would
not
be
interested
in
like
supporting
these
other
Suites.
D
D
Think
more
generally,
I'd
like
to
understand
the
scope
of
the
problem
here,
like
how
many,
if
we
just
were
to
say,
like
you
know
if,
if
if
we,
if
we
were
to
like,
have
a
requirement
that
was
a
requirement
structure,
how
many
connections,
how
many
things
would
really
go
from
like
in
groups
of
divine
text?
D
And
if
the
answer
was
small
I'm
going
to
go
back
to
good
government
and
ecosystem
again,
which
would
be
better
if
everybody's
doing
good
things
so
sure
how
big
is
the
scope
with
so
imagine,
we
were
to
like
deprecate
ffd
entirely,
just
as
a
is
a
strong
counter
example
as
a
strong
point,
how
many
connections
would
go
from
encrypted
to
clear
text?
What
fraction.
N
N
So,
according
to
Victor,
much
of
the
email
ecosystem
would
stop
being
encrypted
in
transit.
What's.
D
N
I
did
try
to
interest
people
who
are
good
in
generating
these
statistics,
but
I
haven't
had.
D
Such
luck
so
I
guess
my
position
is
like
this:
is
we're
not
going
to
send
people
out
to
like
people's
houses
and
make
them
turn
off
design
for
sweets
or
in
the
data
centers
I
mean
you
know,
I
will
be
over
it.
I'll
be
over.
You
know,
send
grid
later,
but
I'll
just
take
care
of
that,
but
I
mean
more
seriously
like
so
like
we.
D
Our
point
is
to
require
people
to
do
smart
things
and,
if,
like
people
and
and
like
we
I,
think
the
policy,
the
ietf
is
we'd
like
people
to
transition
from
finite
field,
to
helmet,
to
elliptic
curve
to
feel
and,
and
so,
if
Ryan's
are
trying
to
like
create
this.
Like
intense
negotiation
about
exactly
what
tests
we
should
say,
we
should
tell
people
not
to
do
this.
D
The
thing
we
think
is
bad
and
then,
like
the
email,
guy's
gonna
ignore
it
for
a
while
and
or
they
don't
ignore
it,
but
like
like
our
positions,
they
should
do
something
in
particular,
and
now
I'm
not
like
I'm
I'm,
a
little
unclear
what
the
options
are
and
exactly
what
recommendation
we
should
make.
We
should
make
the
right
recommendation
and
not
make
a
silly
recommendation
just
because
some
people
are
behind.
O
O
They
do
disable
that
all
of
the
servers
that
are
the
old
ones,
that
we
are
scared
about,
suddenly
dropping
our
connections
to
codex,
will
see
their
percentage
of
fair
text
connections
go
down
if
they're
looking
at
the
stats,
if
they
care-
and
they
see
those
things,
go
down,
they'll
say:
okay,
we
need
to
add
the
cards.
If
you
helmet
I
mean
if
this
is
black,
like
the
other
thing
so
Ecker.
Thank
you
for
your
your
observation
of
the
https.
Only
or
https
preferred
modes
for
browsers
those
modes
should
be
Universal
as
far
as
I'm
concerned.
O
If
we
make
the
text
say,
you
know,
must
not
accept
finite
field,
home
and
key
exchange
unless,
but
in
in
standard
TLS
mode
in
optimistic
mode,
May
accept
ffdhe
that
doesn't
require
browsers
to
accept
ffdhe
in
in
their
mode.
It
just
gives
a
carve
out
so
that
SMTP
clients
like
Victor's
are
willing.
You
know
who
are
clenching
at
the
nfdhe
straws
for
their
five
percent,
of
whatever
their
connections
are
like
like.
It
just
seems
that
that
is
at
least
a
clearer
statement.
D
I
agree
with
that
Generation
like
I,
say
even
I,
don't
speak
for
any
other
browser,
but
like
I
can't
see
us
I
can't
see
us
doing
like
I
can't
see
us
apply
in
different
policy,
optimistic
versus
optimistic
mode
because,
like
I
say
the
the
those
are
the
same
origin.
And
so,
if
you
do
that
the
security
properties
get
very
weird.
E
Yeah
so
I
think
I
think
the
the
split
the
dkg
just
articulated
is
probably
the
right
one:
I,
don't
I,
don't
actually
see
what
we
do
in
browsers
and
they
sort
of
forced
upgrades
to
https
or
opportunistic
upgrades
as
to
TLS,
really
as
being
an
opportunistic
mode
at
all.
We're
just
we're
just
applying
the
same
policies
that
we
would
for
https
anyway.
E
E
But
I'm
sort
of
on
the
on
the
in
the
sort
of
direction
of
saying
well
put
your
requirements
on
the
groups
or,
whatever
validation,
that
you
can
and
then
say
that
you
can,
if
you're
doing
an
opportunistic
mode
you
can
you
can
do
anything
you
like
really
at
that
point
it
seems
to
be
Victor's
attitude
towards
the
to
the
use
of
opportunistic
TLS
he'd
be
happy
with
rock
13.
N
I'm
sorry
so
you're
saying
you're
not
saying
deprecate
ffdhe
entirely.
Are
you
you're
saying
move
forward
with
group
structure
requirements,
but
but
those
are
interactable
or
at
least
they
seem
to
be,
do
I?
Have
your
position
correct.
E
N
Yes,
so
just
to
make
sure
I
understand:
where
are
we
going
with
this
discussion?
So
the
suggestion
is
to
have
the
most
stringent
requirement
applied
to
non-operogeneistic
DLS
connections
and
for
opportunistic
connections,
basically
yellow.
K
Yes,
so
my
my
suggestion
is
just
deprecated
entirely
and
if,
if
somebody
can't
stand
it,
then
they
don't,
then
they
don't
comply
with
the
new
RFC
and
we've
had
this
before
and
if
they
can't,
if
they
can't
get
there,
I
mean
if
you're
using
open,
SSL,
then
you're
then
you're
fine
anyway,
because
it
has
had
the
ecdh
essence.
I
know
version
one
and
if
you're
using
something
worse
than
openssl,
then
you
should
be
using
something
at
least
as
good
as
open
as
yourself.
N
A
Right,
okay,
so
number
and
I
just
wanted
to
double
check.
I
know
that
dkg
is
offered
to
put
synopsis
of
what
he
proposed
in
the
text
for
all
of
us,
because
up
here
the
audio
is
pretty
horrible,
so
I'm
not
sure
I
caught
all
of
it.
But
Nimrod
do
you
have
a
good,
a
good
feel
for
the
way
forward.
N
So
one
of
my
forward
is
to
move
with
our
suggestion
and
just
be
done
with
it,
but
I
I
think
that's
not
the
consensus
of
this
discussion.
The
consensus
of
this
discussion
is
for
a
non-opportunistic
TLS
connections,
deprecate
ffdhe
entirely
or
require
anything
that
is
necessary
to
make
it
safe.
That
would
include
group
structure
for
opportunistic
TLS
connections
either
that
that
other
you
can
do
whatever
you
want,
or
you
can
fall
back
to
ffdhe
without
any
requirements.
N
M
M
Of
efforts
I'm
a
little
worried
if
we
start
to
have
this
carve
out
for
opportunistic
clients
here.
Where
is
this
going
to
end
I
mean
you
could
use,
say
this
for
pretty
much
every
single
issue?
M
What
about
any
kind
of
specific
validation,
of
any
kind
of
guidance
we've
ever
any
protocolvers
and
ciphers
and
I'm
not
sure
why
this
specific
issue
is
somewhere,
where
we
should
makes
a
specific
carve
out,
as
opposed
to
recognizing
that
this
is
probably
an
issue
that
the
opportunity
clients
are
it's
going
to
decide
not
to
follow
a
recommendation
anyway.
N
Yeah
I
I
agree
with
God.
Also
there's
a
this
would
beg
the
question
of
what
counts
as
opportunistic.
So
if
there's
like
a
a
credit
card
processing
or
anything
like
that,
does
that
count
as
opportunistic
so
I
think
we're
opening
up
the
Pandora's
Box
to
be
honest,
but
yeah
David.
Please
go
ahead.
G
David
skanazi
consensus
Enthusiast,
so
just
for
future
reference,
I
highly
urge
you
to
never.
You
know,
put
no
consensus
on
your
slides
because
you're,
just
like
kind
of
painting
yourself
in
a
corner
and
either
way
it's
the
chair's
job
to
declare.
If
there
is
consensus
or
not
so
I'm
gonna
do
something.
That's
both
gonna
help
and
be
a
pain
in
the
ass
you're.
G
Welcome
I'm
gonna
say
that
this
opportunistic
thing
I,
don't
like
it
and
I'm
strongly
opposed
to
it
there
so
now
number
two
is
also
no
consensus,
so
we
can
go
back
to
looking
at
option,
one
which
might
become
a
rough
consensus
if
there
are
only
a
small
number
of
people
who
don't
like
it
so
I'm
just
trying.
A
To
help
fair
enough,
so
I
mean
I.
Think
the
point
here
is
that
we
haven't
actually
done
a
formal
consensus.
Call
it's
just
been
kind
of
the
author's
kind
of
reading
the
tea
leaves
for
all
the
mail
list.
If
we're
stuck
on
this
point
and
in
a
deadlock,
and
we
have
to
pull
up
the
heavyweight
consensus,
email
do
all
that
stuff.
We
can
do
that.
I
just
need
the
words
that
I'm
going
to
put
in
the
consensus
call,
and
so
we
can
work
to
try
to
get
those
and
actually
get
that
going.
G
E
So
John
Thompson
I
think
that
the
arguments
I've
heard
since
I
last
stood
up
here
pushed
me
towards
option.
One
deprecate
ffdhe
entirely
option
two
deprecate
ffe
without
the
the
good
groups,
which
is
a
weak
second,
because
it
requires
a
lot
more
text
and
is
a
little
bit
more
vague
I.
Don't
think
we
need
to
do
anything
for
opportunistic
clients.
E
David
Benjamin
found
a
quote
from
RFC
7435,
which
is
the
opportunistic
security
RFC
that
sort
of
talks
about
it
and
that
basically
says
that
if
you,
an
opportunistic
protocol,
May
employ
more
liberal
settings
than
would
be
best
practiced
when
security
is
mandated
by
policy.
So
basically
they're
already
in
this
sort
of
carve
out
and
someone
who
wants
to
do.
This
can
ignore
this
RFC
that
we
publish
now
and
follow
the
other
one
and
everything's
fine,
because
they're
doing
opportunistic
and
that's
that's
totally
cool.
So.
E
Just
deprecate
the
the
the
non
the
the
groups
that
are
not
known
as
good,
which
is
not
great
but
I,
would
I
would
certainly
be
in
the
in
the
option.
One
Camp
here,
the.
E
N
So
I
I
think
there
are
at
least
three
options,
but
so
we
can
deprecate
ffdg
entirely.
We
can
allow
ffdhe
only
with
standardized
groups
and
we
can
allow.
N
Ffdhe
with
any
safe
group-
or
we
can
allow
ffdhg
with
any
group
large
enough
without
requiring
anything
about
group
structure,
so
that's
actually
at
least
four
options
that
I'm
aware
of
but
I
think
we're
going
towards
deprecating
ffdh
entirely.
N
To
be
honest,
I
wasn't
aware
of
the
RFC
quoted
mating
where
opportunistic
settings
May
employ
more
liberal
policies.
That
sounds
like
a
good
way
forward
to
me,
but
yeah
Stephen.
Please
go
ahead.
J
All
right,
Stephen,
Farrell,
so
I
I,
don't
actually
disagree
with
David
on
this
really,
but
I
know
that
people
do
including
Victor,
and
he
usually
has
some
good
arguments
so
I
don't
think
it
would
be
really
correct
to
say
we
don't
have
any
of
the
room
today
who
disagrees
I'm.
A
A
J
So
yeah
and
and
recent
ones
so
and
then
the
only
other
thing
I
wanted
to
say
was
I.
Don't
think
option
two
is
is
I
know,
there's
any
point
in
option
two,
because
as
far
as
I
know,
it's
only
Victor
and
that
kind
of
you
know
set
of
deployments,
he's
discussing
that
have
an
issue
and
they
generally
use
custom
groups.
So
I
don't
think
option
two
gets
us
anywhere
so
option,
two
being
just
have
a
safe
list
of
groups.
N
J
No
option:
two,
as
in
Martin's
option,
two
all
right
all
right,
I,
don't
need
any
point
and
started
saying
you
know
it's
so
yeah,
so
I
think
throw
that
one
away
and
don't
ask
Apollo
about
that.
I
would
suggest.
N
Yeah
all
right,
anyone
else
wants
to
speak
Echo.
D
Yeah
so.
D
Concerned
about
the
viability
of
option
two
for
the
reason
Stephen
is
which
I
suspect
it
will
actually
not
work.
If
someone
showed
me
a
measurement
that
would
work,
I
might
feel
differently.
So
let's
take
a
measurement
and
be
like.
No,
actually
all
these
guys
use
one
of
the
defined
groups.
Then
you
know,
maybe
that
feels
differently,
but
I
suspect
that
it's
not
going
to
be
false.
D
The
I
I
guess
I
mean
I.
Think
you
know
the
there
seems
to
see
some
question.
There's
a
discussion
on
a
chat
about
whether
there
already
is
enough
of
a
carve
out
in
the
opportunity
descriptions
to
Simply
a
honesty.
A
must
like
I
would
I
mean
I
can
take
this
list,
but
I
would
strongly
prefer
not
to
have
like
some
weird
explicit,
like
opt
out
here
like
the
purp
like
like
the
like
again,
the
instructions
like
we
have.
D
How
long
did
it
take
between
like
when
we,
when
we
like
said
banned
rc4,
and
we
actually
turned
off
our
G4
I
mean
like
like
basically
like
every
decade,
yeah
we
like
routinely.
We
like
routinely
pass
these
these
these
deprecations
and
then
actually
take
quite
a
while
to
execute
them
on.
The
purpose
of
deprecations
is
a
single
to
people,
the
way
they
should
behave
and
that
we're
trying
and
so
and
like
if
and
and
I
think
it
ought
to
be.
D
I
G
To
quickly
add
to
what
Ecker
said,
just
gonna
tell
a
quick
story
that
is
mainly
Chris
Wood's
story,
but
he's
enjoying
his
vacation
go
ahead
back
I
used
to
work
at
Apple
with
him
at
the
time
when
the
working
group
deprecated
tls-10
and
tls11,
and
he
actually
did
all
the
work
to
removing
like
disable
it
from
our
general
boring
SSL
code
at
the
time,
and
it
blew
up
I
forget
if
it
was
a
male
thing
or
an
EP
TLS
thing
or
one
of
those
things
that
like
there's
a
box
somewhere
that
hasn't
been
updated
since
I
was
born
kind
of
thing,
and
that
didn't
mean
we
opposed
publishing
the
RFC.
G
D
I
forgot
the
one
more
thing
I
wanted
to
say,
but
which
I
agree.
What
you
just
said,
which
is
that
the
purpose
of
this
document
in
in
of
this
this
requirement
in
the
context
of
opportunistic,
is
to
tell
people
in
that
ecosystem
that
they
ought
to
be
changing
so
that
in
a
year
they
can
turn
it
off,
and
if
we
have
an
explicit
carbon
for
opportunity.
D
A
Have
a
car
problems
I
mean
that
was
part
of
why
we
did
rc4
right
like
we
did
the
rc4
draft,
because
people
were
like
please.
If
you
write
something
I
can
then
go
whack
people
over
the
head
and
get
it
changed.
So
all
right,
so
I
think
what
we've
come
down
to.
We've
had
lots
of
suggestions
for
various
polls,
we're
going
to
do
a
simple
one
which
is:
do
you
support
deprecating
ffdhd?
A
So
please
get
to
the
feed
Echo
tool.
You
will
raise
your
hands
if
you
support
and
you
will
not.
If
you
don't.
A
Oh,
if
you're
seeing
the
rocketing
live
things
and
again
we're
taking
this
back
to
the
list.
A
So
there's
93
people
in
the
room,
as
you
might
be
able
to
see
and
we've
got
about
30
35-ish
people.
A
Yeah
go
ahead
if
you've
Richard.
A
N
All
right,
so
it
sounds
like
we're
moving
towards
deprecating
it
entirely
and
I.
Guess
we
take
it
to
the
list
to
get
a
Battlefield.
A
So
I
think
that
the
action
item
is
actually
going
to
be
on
the
chairs,
not
on
you,
so
we
will
figure
out
the
right
phraseology
to
get
this
conversation
going
and
I
look
forward
to
a
polite.
Yet
Lively
conversation
on
the
mailing
list.
N
All
right
I
will
be
available.
If
you'd
like
to
consult
me
on
the
phrase
analogy
also
Daniel,
would
you
like
to
speak
again.
O
A
I
mean
yeah,
fair
enough,
dkg
I
think
the
the
point
is
we
want
to
at
least
have
some
place
to
start.
O
A
A
A
J
He
is
great
there.
He
is
great,
so
I'm
only
Ben
would
present
this
if
he
was
here
but
and
do
jump
in
Ben.
If
you,
if
you
want
to
correctly
so
the
base,
what
we
did
was
we
had
some
discussion
and
Ben
and
Rich
agreed
to
help
co-author.
J
So
what
we
did
in
this
version
is
essentially
try
out
to
see
if
some
of
the
ideas
of
Ben
and
Richard,
mostly
Ben
I,
think
are
something
that
the
working
group
find
better,
and
so
this
is
a
suggestion.
J
J
So
and
but
yes,
people
will
rotate
keys,
so
we
need
somebody
to
handle
it
and
dynamically
generate
zones
and
yeah.
So
so,
yeah
again
another
thing
Ben
wants.
He
wanted
to
make
it
easier
to
do
it
a
good
way
than
the
wrong
way.
So
next
slide.
J
So
what's
different
in
this
one
is
in
zero,
zero.
You
were
talking
to
the
ech
front
end
essentially
to
get
the
ech
config
that
the
the
zone,
the
authoritative
for
the
origin,
was
talking
to
the
ech
front,
end
to
get
the
ech
key
and
then
to
put
it
into
the
origins
Zone
in
this
one.
It's
talking
to
the
origin
itself,
because
that
allows
covering
kind
of
more
deployment
cases
that
Ben
thinks
are
interesting,
which
is
I,
think
true
and
it
otherwise.
J
Jump
in
and
correct
me
if
I
say
something
wrong
here,
so
this
is
the
picture
for
this
one
where
we
have
the
Zone
Factory,
which
creates
the
resource
records
and
write
some
DNS.
J
It
has
to
occasionally
fetch
values
because
keys
are
being
rotated
and
the
origin
in
this
case
might
have
to
talk
to
the
ech
front
end
because
that's
where
the
the
ech
keys
are
actually
being
generated,
and
so
what
you
could
think
of
is
that
the
bottom
part
there
in
lighter
blue
is
draft
zero
sort
of,
whereas
and
then
in
this
draft,
because
you're
going
to
the
origin,
you
can
do
a
bit
more
so
next
slide
and
then
there's
a
comparison
between
you
know,
Json,
blobs
and
again,
I
think
we
have
no
problem
changing
these
in
any
particular
way,
because
they're
they're
pretty
sketchy
at
the
minute,
but
basically
it
allows
you
to
have
the
same
kind
of
information.
J
Next
slide
json's,
not
that
interesting,
and
then
these
are
the
kind
of
https
aurors
that
you
might
end
up
with
I'm,
not
entirely
sure
I
know
even
I
even
know
what
a
template
horror
is,
but
I
could
kind
of
guess.
But
I'm
not
sure
how
accurate
that
guest
would
be,
but
in
any
case
the
Zone
Factory
can
use
the
Json
to
make
resource
records
next
slide.
J
This
is
the
thing
that's
kind
of
new
is
that
Ben
I
think
rightly
points
out
that
the
the
draft
zero
kind
of
handles
a
like
the
kind
of
weird
case
that
I
was
interested
in
for
my
test
sites.
J
Probably
many
more
people
will
just
use
a
c
name
or
something,
and
he
wanted
to
provide
a
way
to
make
that
a
bit
easier
and
a
bit
less
error
prone,
and
so
that's
kind
of
the
main
reason
why
you
want
to
talk
to
the
origin.
I
guess
so.
That's
kind
of
a
nice
thing
about
it
is
that
you
can
just
create
a
Json
blog,
but
then
eventually
turns
into
a
c
name
or
one
of
the
other
ways
of
editing,
which
I
think
is
nice.
J
On
the
other
hand,
it
also
kind
of
feels
a
bit
dangerous,
but
I'm
not
quite
sure
why?
But
nonetheless,
this
this
version
that
I've
envisages
supporting
that
kind
of
use
case,
which
I
guess
would
be
by
far
the
most
common
way
of
doing
this.
But
I
don't
know
for
sure.
J
I'm
just
pausing
there
in
case
Ben,
wants
to
add
something,
or
somebody
wants
to
scream
that
this
is
mad
for
some
reason
nobody's
screaming.
Okay
next
slide,
this
still
has
the
kind
of
support
for
the
multi-cdn
I.
You
know,
I
I,
wouldn't
say
we
put
a
huge
amount
of
work
into
this.
It
probably
needs
a
bit
more
thought,
a
bit
more
working
out
and
playing
around
to
try
and
make
it
work,
but
it
should
work
I,
think.
J
Basically,
where
you
can,
you
can
pick
up
these
CH
keys
from
the
cgn
and
then
put
them
on
the
origin.
It's
essentially.
This
is
like
saying
that
you
know:
do
the
draft
zero
thing
between
the
origin
and
the
CDN
and
then
you'd
use
this
to
get
the
resource
records
created.
So
it's
a
little
bit
of
a
two-step
thing.
Put
your
work
next
slide.
J
Ben
prefers
I,
had
you
know
in
version
zero
we
had
ttls
in
the
Json.
Ben
prefers
to
use
HTTP
freshness,
I,
don't
know
if
that
makes
sense.
If
I
have
a
very
simple
kind
of
script
that
just
uses
Coral
or
something
to
pull
these
things,
I'm
not
sure
how
easy
it
is
to
get
that,
but
I
haven't
looked
so
maybe
you
can
and
again
we
you
know
I
think
as
before.
J
It
was
pretty
clear
that
people
didn't
want
ordinary
kind
of
clients
for
ech
using
these
URLs.
So
we
should
discourage
us
next
slide,
yeah
this
template
stuff.
For
that
we
figured
out.
There's
probably
with
this
version.
Yeah
there's,
probably
some
things
about
IP
addresses
and
so
on
that
might
get
tricky.
J
Q
All
right,
hi,
thank
you:
Ben,
okay,
yeah
I
I
mean
uses
of
ech
and
TLS
for
things
other
than
http.
A
A
J
Last
year,
even
though
I'm
doing
very
badly
presenting
bands
ideas,
I'm
it's
a
good
job
I'm
here.
So
there
you
go
yeah,
there's
a
bunch
of
things
we
figured
out.
So
next
slide.
I
think
is
the
last
one.
Is
this
okay?
That's
that's
the
question.
It's
well!
Okay.
What
do
you
think
I
mean
you
know.
N
A
J
Have
opinions
it
might
be
a
little
bit,
can.
J
A
I
see
a
couple
of
hands
up
there
good
and
then
well.
I'll,
be
honest.
One
of
the
reasons
why
I
was
concerned
about
this
draft
being
in
this
working
group.
Is
there
weren't
a
lot
of
DNS
people,
but
at
least
there's
a
couple
of
people
around
here.
I
know
that
are
really
smart
about
this
stuff.
So
don't
be
bashful
now's
your
chance
to
learn
so.
J
A
J
Okay,
any
other
feedback.
C
J
Q
Yeah,
so,
okay,
sorry
yeah,
my
Miracle
has
not
been
stable
for
me
this
week.
The
the
the
template
thing
is
an
attempt
to
balance
this
competing.
These
competing
desires,
on
the
one
hand,
we're
trying
to
stick
to
only
talking
about
ech
and
information.
You
need
to
know
to
make
use
of
an
ech
config
and,
on
the
other
hand,
the
ultimately,
your
HTTP,
your
your
Zone
Factory,
is
going
to
produce
DNS
records
that
have
a
bunch
of
other
stuff
in
them
that
are
telling
you
things
like.
Does
the
support
HTTP
3?
Q
You
know?
Is
this
actually
something
about
oblivious,
though,
like
all
this,
all
this
different
metadata
about
the
origin?
And
so
we
said
you
know,
let's
focus
on
ech
here
and
and
leave
that
to
the
DNS
side,
so
that
that
means
the
Zone
Factory
has
to
know
all
this
other
stuff
in
advance.
All
we're
doing
is
is
moving
the
ech
keys
across,
but
then
you
need
a
matching
algorithm.
You
need
some
way
to
say
well.
I
G
Hi
David's,
kanazi,
DNS,
Enthusiast,
first
I
think
the
more
generic
approach
I
I
like
it
just
conceptually
having
a
way
to
do
this
sounds
good,
the
so
first
a
clarifying
question:
how
is
your
intent
here
that
browsers
always
query
this
well-known
on
all
websites?
G
G
Q
No,
please
go
ahead.
The
intention
is
that
browsers,
do
not
know
about
this
at
all.
The
client
here
is
a
Zone
Factory,
which
is
a
term
that
Stephen
sort
of
appropriated
for
a
component
of
an
authoritative,
DNS
server
that
is
populating
the
zone.
J
A
E
I
was
looking
for
more
birthday
party
things.
This
should
be
short,
I,
hope.
Everyone
knows
what
this
is
I'm,
not
going
to
really
explain
it
very
much,
because
the
next
slide
has
basically
all
that's
really
necessary.
On
this
point,
I
know
a
lot
of
people
use
an
environment
variable
of
this
name
to
to
do
debugging
of
their
TLS
stacks
I.
Think
it's
pretty
widely
implemented,
not
particularly
widely
deployed,
which
is
a
good
thing
and
I
think
it
feels
like
Wireshark
and
whatnot
use
this
natively.
E
We
also
have
a
draft
in
some
Ops
area
working
group
that
I
think
it's
the
Ops
area
working
group
that
they're
trying
to
define
the
pcap
format
in
RFC
form
that's
going
to
rely
on
this
next
place.
E
Okay,
why
so,
currently,
the
authoritative
documentation
for
this
file
format
is
sitting
in
the
NSS
Source
tree.
That's
not
great.
It
gets
published
on
a
web
page,
it
used
to
be
published
on
n
mdn,
and
then
they
decided
they
didn't
want
all
of
this
documentation,
and
so
it's
now
in
the
Firefox
Source
docs
thing.
That's
pretty
hard
to
find
and
I
think
it's
probably
more
appropriate.
That
has
a
stable
home
the
next
slide.
E
So
we
take
that
documentation
and
we
put
it
in
an
RFC,
that's
it
and
the
idea
is
to
give
change
controls
to
the
ITF
next
done.
Foreign.
E
Look
at
that
very
easy,
I
guess.
The
question
is:
is
this
work
that
this
working
group
wants
to
take
on?
Should
I
ask
an
operations
area
working
group
instead,
I'd
rather
not.
A
So
I
can
take
a
poll
if
there's
support
for
adopting
this,
and
then
we
can
take
it
to
the
mailing
list.
My
excuse
me,
my
understanding
is
that
this
would
be
informational,
not
necessarily
standard
track,
because
it's
not
interoperability
formats,
so
to
speak
or
are
we
in
the.
E
Minutia,
it
is
an
interoperability
thing,
I
mean
one
stack,
produces
something
and
some
other
tool
consumes.
It
there's
an
argument
to
be
had
here
for
for
making
it
standards
track
all.
B
L
Yeah
yeah
sorry,
Eddie
I
can't
get
my
meat
Echo
to
work,
so
I
couldn't
get
in
the
queues,
but
but
yeah
no
I
think
I
support
this
work.
A
great
deal,
I
think
it's
very,
very
useful.
Just
just
out
of
curiosity
is
there
any
I,
don't
know
if
it's
in
scope
or
out
of
scope,
but
is
there
any
thought
of
saying
like
that
browsers
or
other
things
should
Implement
something
like
this
just
a
question.
E
Now,
there's
there's
a
great
deal
of
debate
about
this,
even
even
within
my
own
project.
There
are
people
who
would,
rather,
this
not
be
enabled
in
release,
builds
and,
and
things
like
that,
it
carries
significant
risks
to
both
security
and
privacy.
To
enable
this
thing,
and
so
rightfully
people
are
concerned
about
implementing
this.
This
is
not
uniformly
implemented
as
I
understand.
E
There
are
a
number
of
stacks
that
simply
don't
do
this
and
that's
okay.
Some
people
don't
need
it.
J
So
so
Stephen
question
and
a
possible
comment,
an
inevitable
comment,
but
the
question
is:
to
what
extent
does
the
current
documentation
contain
warnings
and
guardrails?
It
just
tells
you
how
to
do
it
right.
So.
J
E
J
E
A
look
at
what
I
put
in
there
I
I
spent
maybe
an
entire
hour
on
this
document,
so
it's
probably
not
complete,
but
there
is
a
fairly
substantial
section
on
you
know.
What
do
you
do
when
you've
got
one
of
these
things?
What
are
the
risks
to
the
to
the
active
connections
and
and
the
connections
that
happened
in
the
past
that
might
be
logged
in
this
way
and
various
other
things
right.
J
P
P
E
E
E
P
E
C
A
A
E
A
And
ding
it
all
right,
so
33
participants,
28,
raised
hands
and
five
do
not
raise
hands.
I'll
end
this
session
now
and
is
there
anybody
who
said
who,
who
kind
of
doesn't
want
to
do
this
they're
willing
to
get
to
the
microphone
to
say
why.
A
Okay,
all
right,
thank
you
very
much.
So
I
guess
the
only
thing
since
we're
actually
done
early
for,
like
once
in
like
the
last
10
years
in
like
in
like
in
the
last
in
the
last
and
so
there's
there's
definitely
some
chatter
in
the
room
about
just
close
the
session.
But
we
have
a
few
drafts
that
have
been
out
that
were
adopted
and
then
expired.
So
I
guess.
The
question
is:
what
should
we
do
with
those?
A
The
two
that
come
to
mind
specifically
are
the
batch
signatures
and
the
other
one
is
the
semi-static
draft,
so
I'm
curious.
If,
if
David
Benjamin
wants
to
get
to
the
microphone
and
say
anything
about
batch
signing
or
if
you'd
like
it
to
quietly
go
away
and
not
getting
the
microphone
is
a
perfectly
fine
answer
so
that
we
know
not
to
keep
harping
on
this
and
we
can
just
kind
of
let
it
quietly
just
drift
off
into
space.
H
David
Benjamin
at
one
point
batch
signing
Enthusiast,
but
at
this
point
I
had
like
the
the
thing
that
I
was
interested
in
it
for
no
longer
happened,
it's
it
seems.
No
one
has
picked
it
up
like
I.
Think
if
someone
wants
it,
it's
a
cool
mechanism,
but
I
don't
have
time
to
drive
it
fair
enough.
No
one
else
does
either
so.
A
So
what
we'll
do
is
we'll
it
will
it's,
it's
expired.
We
will
let
the
process
do
its
thing
and
it's
expired,
and
if
anybody
else
wants
to
take
it
over
and
run
with
it,
we
will
they
can
contact
us
and
we
will
see
how
we
can
go
from
there
on
the
semi-static
Becker.
D
Orange
is
ahead
of
me
in
the
queue.
Oh
sorry,
oh
okay,
so
yes
I
still
do
care.
Somebody
static,
I,
think
others
do
too
it
just
I
can
only
do
about
one
thing
at
once
right
now,
so
so
ask
me
again
when
8446
business
done.
Okay,
great
thanks,
Martin.
E
So
I
understand
that
there's
some
wife
a
chairs
to
sort
of
Mark
a
document
as
like,
abandoned
or
something
like
that
right,
I
suggest
we
do
that
drafts
can
be
unabandoned
at
any
time.
So
for
for
the
batch
signing
thing
just
say:
look
we're
not
working
on
this
right.