►
From YouTube: IETF110-SECDISPATCH-20210311-1600
Description
SECDISPATCH meeting session at IETF110
2021/03/11 1600
https://datatracker.ietf.org/meeting/110/proceedings/
A
B
C
C
E
B
E
No
worries
so
yeah,
as
I
was
saying,
new
chair,
so
hello,
everyone,
let's
you
know
let
richard's
always
problems.
We
can
stop
the
session,
so
this
is
sec.
Dispatch
next
slide,
I'm
sure
by
thursday
you're
familiar
with
the
note
well.
But
if
you're
not
please
read
through
this,
let's
give
it
a
minute,
hopefully
you're
familiar
with
all
this.
By
now.
E
E
So
here
here
are
some
relevant
links,
so
hopefully,
hopefully
you
are
joined
into
the
meeting
with
meet
echo.
We
are
taking
notes
in
kodi
md,
the
slides
are
posted
in
data
tracker,
and
this
working
group
is
about
dispatching
items
and
not
really
adopting
drafts.
So
when
you
do
give
feedback,
try
to
also
give
feedback
on
on
the
fact
how
to
dispatch
this
work
item,
whether
it
should
be
adopted
or
whether
there
should
be
a
new
working
group
and
so
on.
E
E
E
Yeah,
I
I
guess
this
slide
kind
of
emphasizes
that,
so
it
recommends
the
next
steps
and
does
not
adopt
drafts.
So
there
are
several
possibilities:
it
can
go
to
some
existing
working
group
or
start
a
new
working
group
or
then
you
can
untwist
the
ids
into
sponsoring
documents.
If
you
feel
that's
the
appropriate
step
and
there's
always
the
possibility
where
you
think
that
ietf
should
not
work
on
on
this
topic,
because
it
is
completely
out
of
scope
all
right
next
slide.
E
Oh
thanks
to
francesca
who
has
prepared
this
so
hopefully
you're
familiar
with
these
buttons
by
now.
But
if
not,
you
know
this
hand
is
to
join
the
queue
and
you
can
unmute
yourself
and
show
your
video
and
hopefully
you
won't
need
to
share
your
screen,
but
we
might
run
some
polls
later
so
hopefully
you
know
how
to
raise
your
hands
by
now
next
slide.
E
So
this
is
our
agenda.
I
guess
we
are
still
on
on
time
with
the
administrative
is
still
10
minutes.
Does
anyone
want
to
bash
the
agenda?
Is
there
some
new
items
that
should
be.
B
F
Yeah,
I
just
wanted
to
say
that
yeah
just
highlight
the
fact
that
this
is
my
last
meeting
as
satisfactor.
So
I
want
to
thank
everybody,
and
I
want
to
thank
mohit
for
coming
in
and
taking
the
the
job
and
I'm
sure
he
will
do
great.
I
don't
know
if,
if
our
ads
want
to
say
something.
B
Francesca
you
jumped
the
gun
there.
I
I
was
going
to
wait
until
finish
the
chair,
slides,
thank
you
for
your
service
as
a
sec
dispatch
co-chair
and
welcome
moget
to
the
to
the
crowd.
We
are
a
bit
unique
at
the
moment
and
having
four
co-chairs
as
an
ad
pointed
out
to
be
impact
channel.
I
promise
we
are
going
to
be
reducing
that
number
imminently,
but
I
think
we're
tremendously
thankful
to
francesca
for
for
your
help
here
and
looking
forward
to
having
working
with
movie
going
forward.
C
I
also
want
to
thank
francesca
too.
She
did
a
lot
of
the
heavy
lifting
for
for
us
for
the
last
few
meetings.
It's
really
very
much
appreciated
and
wish
you
the
best
of
luck.
As
you
become
an
ad
congratulations.
A
B
You
that
being
appointed
to
the
iesg
is
apparently
an
occupational
hazard
of
being
sick
dispatch
co-chair.
So
I
look
forward
to
your
standing
for
that
next
time.
Around.
E
Well,
I
have
big
shoes
to
fill,
so
thank
you
francesca.
As
you
can
see,
she
still
prepared
the
slides
and
she's
still
sharing
the
slides
from
her
her
laptop
so
yeah.
She
has
been
doing
a
lot
of
the
heavy
lifting
even
for
this
meeting.
So
thanks
a
lot
and
good
luck
with
the
isg.
E
F
E
Thank
you
richard.
You
can
take
the
reins
so
I'll.
B
B
Through,
oh
all,
right
did
we
sorry
I'd
forgotten.
Do
we
have
that,
in
the
remainder?
Just
a
reminder,
folks,
that
this
is
dispatch?
This
is
not
a
working
working
group,
and
so
we
are
focused
on
those
dispatch
outcomes.
What
should
we
do
with
this
work?
Should
we
send
it
to
an
existing
working
group
start
up?
Another
working
group
recommend
to
the
ads
they
d
sponsor
it
or
tell
it
to
go
away.
We're
not
gonna,
do
any
work
on
this.
B
So
as
you're
listening
to
these
presentations,
please
keep
those
outcomes
in
mind
because
that's
the
discussion,
we're
gonna
have
when
the
presentations
are
done
and
try
and
come
to
a
conclusion
as
to
what
we
should
do
with
this
work.
So
with
that
martin,
please
take
it
on.
G
Thanks
richard,
so,
yes,
I
will
give
an
overview
of
what
this
is.
I
think
there's
been
a
bit
of
discussion
about
that
and
some
some
confusion.
We
do
have
an
updated
version
of
the
draft.
I
I
think
that
has
addressed
some
of
those
things
since
the
discussion,
but
I'll
make
sure
that
everyone
understands
the
same
thing.
Can
we
go
to
the
next
slide?
G
Please
right.
So
what
this
is
is.
Oh,
I
use
system
and
method
here
for
making
unlinkable
http
requests
and
one
of
the
things
we're
trying
to
get
to
is
a
system
whereby
servers
that
gather
information
about
requests,
aren't
able
to
do
things
to
build
profiles
of
the
people,
making
those
requests
and
use
that
for
reasons
so
there's
two
parts
to
this.
G
We
have
a
proxy
that
hides
all
of
the
source
addressing
and
the
the
request
information
that
we
don't
want
the
server
to
see
and
an
additional
layer
of
encryption
to
ensure
that
that
proxy
doesn't
get
to
see
the
contents
of
requests
and
responses,
which
kind
of
most
sensitive
information
that
that
there
is
so
it's
all
about
it.
Information
separation,
a
simple
mixnet!
G
So
how
this
works?
It's
pretty
simple:
the
server
publishes
an
hpk
configuration.
The
client
makes
a
fresh
context
for
every
request,
encapsulates
it
sends
it
via
the
proxy,
the
server
unbundles.
That
information
gets
the
request
and
processes.
It
encapsulates
a
response
using
the
context
and
some
does
some
computations
based
on
the
context,
and
we
have
to
use
hpk
exporters
to
get
the
keying
material,
but
the
the
response
is
encapsulated
and
sent
back
via
the
proxy.
G
G
So
why
you
would
want
to
do
this,
so
there
are
a
lot
of
contexts
in
which
there's
information
contained
in
requests
that,
if
linked
together
in
a
in
a
series,
might
provide
the
server
with
information
that
maybe
clients
don't
want
them
to
have.
A
big
discussion
that
we've
had
in
the
dns
groups
has
been
about
oblivious
dns
and
obviously
the
name
here
is
a
nod
to
the
original
name
that
was
given
to
the
oblivious
dns
system.
This
is
largely
based
on
that
work.
G
The
main
use
case
here
that
we
imagine
would
be
something
where
we
make
dns
queries
using.
Something
like
do,
and
you
can
use
this
to
encapsulate
those
queries
and
protect
the
sequence
of
queries
that
you
make
and
telemetry
queries
and
what's
unique
about
these
ones.
Sorry,
I
should
expand.
I
know
in
telemetry
submission
for
for
something
like
this.
We
maintain
in
in
firefox
a
telemetry
system
where
we
would
like
to
know
information
about
what
people's
clients
are
doing,
but
we
don't
really
want
to
connect
that
information
with
the
people.
There's
nothing.
G
Nothing
really
that
we
gain
from
having
that,
except
for
access
to
what
is
essentially
toxic
information.
So
we've
been
looking
to
do
things
like
that
for
telemetry
and
what's
also
unique
about
these-
is
that
there
is
no
real
need
to
carry
information
from
one
request
to
the
next
in
series.
There
is
value,
however,
in
breaking
them
into
discrete
units.
G
The
advantages
of
something
like
this
is
that
it
has
less
overhead
than
some
of
the
alternatives
that
we
have
available
to
us.
So
if
we
look
at
doing
regular,
http
proxy
there's
no
protocol
changes
in
order
to
get
something
like
that
working,
but
it
requires
that
you
make
a
new
connection
for
every
single
request
by
the
proxy.
So
you
have
a
connection
to
the
proxy,
and
then
you
make
a
new
request
for
every
new
connection,
for
every
request
to
the
server
that
you
make.
That
has
a
lot
of
overhead
and
round
trips
in
particular,.
G
You
can
do
that
same
sort
of
thing
as
with
a
proxy,
except
that
now
you've
got
the
the
full
multi-layer
mix
net
involved
and
that's
much
much
higher
overheads
in
terms
of
latency
and
also
cryptographic
and
whatnot,
and
then
there's
systems
like
preo,
which
work
for
telemetry
submissions,
where
you
can
make
information
about
the
what's
going
on
available
to
to
people
in
an
aggregated
fashion.
But
you
can
don't
get
any
responsiveness
and
things
like
that.
G
All
right,
so
why
not
there's
plenty
of
reasons
why
this
doesn't
really
work
for
all
sorts
of
use
cases?
This
is
not
general
purpose
http
in
the
sense
that
you
don't
carry
state
because
between
requests-
and
that
means
cookies
on
one
hand
which
some
people
might
go.
Yes,
that's
a
great
thing,
but
it
also
means
that
you
can't
do
things
like
follow
links
because
links
carry
state
between
requests,
and
so
the
general
pattern
of
use
of
http
for
things
like
web
browsing
doesn't
really
apply
in
this
case.
G
It's
also
a
lot
more
expensive
to
make
requests
this
way
and
if
you
don't
have
any
basis
for
trust
in
the
in
the
parties
that
are
involved
in
this
one,
so
in
particular,
if
you
can't
arrange
a
situation
where
a
server
trusts,
a
proxy
or
the
user
trusts
the
proxy
to
the
extent
that
they
need
to
be
trusted,
then
then
this
doesn't
work
and
that's
where
you
might
want
to
go
to
things
like
tor,
where
those
those
requirements
for
trust
are
much
much
much
lower.
G
So
if
we
look
at
the
performance
characteristics
of
this,
when
we
compare
it
to
the
very
simple
scenario-
that's
most
like
this,
which
is
the
one
request
per
connection
through
a
proxy,
it
seems
it's
quite
favorable
if
you,
if
you
look
at
the
the
overheads
involved,
and
so
when,
when
we
look
at
this,
we
say
that
we're
trading
some
of
the
security
advantages,
perhaps
for
performance.
G
So
there
are
some
replay
protection
things
that
are
not
quite
as
good
in
this
system
and
post-compromise
security
is
not
as
great,
but
you
can
do
things
like
reduce
the
number
of
cryptographic
operations
that
are
involved
and
probably
the
killer.
One
for
us
is
that
you
reduce
the
number
of
round
trips
involved.
G
G
G
G
There's
a
bunch
of
things
that
you
might
need
to
do
in
order
to
to
get
better
traffic
analysis
resistance
and
the
nature
of
the
system
is
that
replay
attacks
are
possible
if
the
proxy
wishes
to
to
act
in
a
in
a
bad
fashion.
So
there's
either
a
requirement
for
trust
or
a
set
of
protections.
You
put
in
place
to
ensure
that
replay
attacks
aren't
possible
and
we
can.
G
We
can
reuse
some
of
the
anti-replay
mechanisms
that
we've
used
for
zero
rtt
in
in
tls,
but
not
all
of
those,
and
also
probably
the
worst
one
is
that
if
the
server
keys
which
are
static
are
compromised,
all
of
the
messages
can
be
read
if
the
proxy
makes
those
those
messages
available
to
to
an
attacker.
G
In
order
to
make
this
work,
we
could
probably
get
this
working
by
reusing
the
existing
definition
for
message
as
a
number
of
reasons
why
that
would
be
awkward.
It
has
some
fairly
difficult
implementation
characteristics,
including
some
awkward
stateful
characteristics.
You
have
to
understand
the
request
in
order
to
make
sense
of
the
response
in
a
lot
of
cases.
G
So
as
part
of
this,
we've
got
a
short
draft
that
describes
a
simple
binary
encoding
for
http
messages
that
allows
you
to
make
those
reasonably
efficiently.
It
doesn't
do
any
of
the
fancy
features
that
http
3
does
doesn't
do
header
compression
and
various
other
things
like
that,
and
the
only
flexibility
is
to
allow
for
streaming
processing,
which
is
a
common
use
case
in
a
lot
of
these
things,
but
even
that's
negotiable.
G
I
think
yes,
this
is
the
question
that
we're
here
to
here
to
ask
now
there's
a
relatively
small
and
largely
self-contained
specification.
There
there's
a
couple
of
opportunities
that
we
have
for
doing
things
like
discovery
of
the
various
actors
involved
and
and
advertising
formats
and
whatnot.
But
the
the
core
of
the
specification
is
isn't
really
that
much.
It
took
not
very
long
to
implement
as
chris
and
I
will
both
attest.
G
We
have
implementations,
they
interoperate,
there's
a
test,
client
server
that
people
will
play
with
if
they
so
choose.
So
the
question
would
be:
is
there
interest
in
doing
the
work?
Is
there
enough
people
willing
to
do
the
work
and
where
do
you
think
it'd
be
best
to
do
the
work?
I've
got
some
ideas,
I'm
suggesting
here
a
working
group,
but
the
question
for
the
group
will
be
to
answer
that
question
based
on
their
on
your
own.
C
Run
through
with
rich
first
and
try
to
keep
your
questions
brief,
just
in
the
interest
of
keeping
to
time
sure.
H
Nice
haircut,
martin,
I'm
jealous
how
does
this
relate
rich,
sol
zakamae?
Have
you
looked
at
the
the
chrome,
anonymous
prefetch
stuff,
I'll
post,
a
link
in
the
in
the
chat,
and
I
want
yeah.
G
Yeah,
if
it's
this,
this
does
relate
to
that
yeah
thanks
richard
there's
a
there's
a
bunch
of
things
in
this
space
that
do
relate
to
the
to
this
general
area
of
work,
whereby
you
have
the
ability
to
fetch
things
more
or
less
anonymously,
and
this
does
give
you
some
of
that
that
ability
it
doesn't.
This
doesn't
have
necessarily
the
right
set
of
guarantees
for
that
work
because
of
the
unlinkability
properties
that
we
have
here.
G
It's
not
particularly
well
suited
to
doing
things
like
stateful
prefetching
things,
particularly
when
you
think
about
prefetching,
an
entire
web
page,
which
might
include
include
multiple
requests,
multiple
resources.
So
I
do
think
it
is
adjacent,
but
not
entirely
the
same.
I
Cool
thanks
thanks
for
the
presentation,
martin,
I
think
this
is
a
really
cool
tool.
I
think
it
complements
nicely
a
lot
of
the
other
tools
we're
building
in
mask
in
other
places
at
the
atf.
I
think
this
fits
a
different
use
case,
which
is
great,
so
I
would
be
very
much
in
favor
of
us
working
on
this
like
at
the
atf,
and
I
think
your
proposal
of
a
short-lived
small,
specific
well
narrowly
focused
working
group
is
the
right
one.
So
I
would
advocate
for
that,
as.
B
Well,
I
was
waiting
for
kathleen
to
introduce
the
next
person
in
the
queue
and
then
I
realized
it
was
me.
So
I
think
I
have
a
couple
of
concerns
about
this.
Mainly
I'd
like
to
understand
better
sort
of
concerns.
One
is
this
distinction
between
applications
of
http
that
for
which
this
makes
sense
and
which
is
it
for
which
it
doesn't
make
sense,
which
you
seem
to
draw
there.
B
I
wonder
if
there's
how
sharply
we
can
draw
that
line,
and
the
other
concern
I
have
is
that
there
seems
to
be
kind
of
a
collection
of
intermediation
strategies
being
adopted
around
ietf
nowadays
and
it
seems
like
it
would
be
good
to
do
a
little
bit
of
work
to
collate
those
and
understand,
what's
good
where
so,
like.
I
would
contrast
you
there's
this.
There's
the
oblivious
dns
stuff.
There's
the.
I
understand
some
work
being
done
on
multi-layered
masks,
so
you
can
tunnel
mask
total,
quick
tunnels.
B
You
know
stacked,
quick
tunnels,
so
I
mean
and
then
of
course,
there's
all
the
legacy
of
tor
work
and
the
protocols
they've
got
there.
So
it
seems
like
some
degree
of
housekeeping
would
be
useful
and
having
in
terms
of
having
an
understandable,
comprehensible
tool
set
for
folks
yeah.
Absolutely.
G
So
I
think
yeah,
I
think,
to
your
first
point:
the
the
distinction
between
sort
of
the
continuous
use
of
http,
with
with
context
the
representation
representational
state
transfer
or
cookies
or
whatever,
whatever
you
have,
the
highfalutin
version,
or
the
thing
that
everyone
uses
is,
is
very
different
from
this,
and
this
imagines
it
imagines
a
more
atomic
style
of
interaction
which
is
well
suited
to
things
like
the
dns
case
or
the
telemetry
submission.
The
question.
B
I'm
wondering
is
like:
is
there
a
technical
like
clearly
defined
line?
One
could
draw
to
like
put
a
bounding
box
around
this
and
say
it's
safe.
G
Yeah,
and
so
that's
what
I
was
thinking
that
the
when
it
comes
down
to
to
this
general
strategy
of
intermediation
for
this,
I
I
I
think
we're
we're
kind
of
reaching
the
point
now,
where
we're
using
this
individual
intermediation
strategy
for
privacy
purposes
for
a
number
of
different
purposes
and
having
the
the
spread
in
the
toolkit
is
starting
to
become
necessary.
G
I
do
think
that
you're
right
in
identifying
the
pattern
and
being
deliberate
about
our
choices
in
selecting
from
this
space,
but
I
think
this
is
an
underserved
point
in
that
space
at
the
moment,
and
so
we're
seeing
this
with
the
oblivious
dns
and
the
oblivious
doe,
and
things
like
that.
One
of
the
things
I
was
trying
to
do
was
find
something
that
was
generic.
G
That
would
be
able
to
be
applied
across
a
number
of
different
things,
rather
than
look
for
the
point
solutions
that
we've
had
in
the
the
case
of
tommy's,
oblivious,
dns
or
oblivious
doe
proposal.
I
I
think,
that's
that's
something
that
I
was
uncomfortable
with
for
the
reasons
that
you
stated.
You
know
thanks.
B
And
finally,
I'd
just
like
to
read
in
some
comments
that
I
got
from
matthew
finkel
the
tour
projects
on
back
channel.
He
says
that
he
is
generally
supportive.
Tor
might
not
use
it
directly,
but
it
could
be
something
they
could.
Leverage
to
reduce
some
of
their
constraints
may
be
allowed
to
get
get
away
with
one
less
op,
less
latency,
etc.
So
some
support
there
for
doing
the
work
from
the
tour
project.
B
G
J
All
right
thanks
for
presenting
this,
so
I'm
I'm
definitely
supportive
of
this.
I
think
of
the
options
having
short-lived
working
group,
I
think,
is
the
right
solution.
There's
enough
conversation
to
have
around
this.
J
J
I
agree
that
this
is
kind
of
one
of
the
tools
in
the
toolbox
that
we
can
use,
and
I
think,
having
a
working
group
for
this
would
complement
well
the
work
that's
going
on
in
mass,
because
I
essentially
see
the
mask
proxying
as
ways
improving
the
ways
we
have
more
stateful
long-lived
proxy
connections
for
privacy-
and
this
is
this
solution-
covers
all
of
the
less
stateful
things
that
are
more
just
transactional,
one-off.
J
And
so,
if
you
put
those
two
together,
I
think
you
have
a
relatively
complete
toolbox
and
I
would
actually
hope
that
the
in
deployments,
the
actual
nodes
that
are
proxies,
support
both
that
essentially
a
proxy,
would
have
some
connections
that
it's
doing,
connect,
connect
udp
for
long-lived
things
that
the
client
wants
and
everything
else
that's
transactional
like
dns
and
stats
reporting
goes
through
an
oh
http
solution.
G
K
Oh
yeah,
okay,
so
I
was
wondering
so
if
we
have
the
proxy
and
the
end
server,
I'm
just
wondering
in
in
your
scenarios,
are
they
managed
by
the
same
entity
or
are
they
managed
by
different
independent
entities?.
G
Yeah,
so
presumably
the
client
and
server
are
operated
by
different
entities
and
the
the
proxy
has
to
be
from,
from
the
client's
perspective,
a
different
entity
of
the
entity
to
the
server
primarily
because
they
have
to
trust
that
one
won't
be
passing
information
to
the
other
and
usually
find
that
the
best
way
to
achieve
that
is
to
make
sure
that
they
have
some
sort
of
incentive
aligned
in
that.
In
that
way,
and
being
a
different
organization
is
usually
the
best
way
to
do
that.
There's
discussion
of
this
in
the
draft.
G
So
in
the
trial
we're
doing
with
a
related
thing,
which
is
for
the
dns
thing,
there
are
independent
people,
not
the
isp,
but
it
certainly
could
be.
I
imagine,
but
there
there's
an
independent
party
running
the
proxy
completely
independent
of
of
either
us
or
the
the
server
operator.
L
There's
a
presentation,
martin,
I
don't
think
it
may
be
surprised
here,
I'm
in
favor
of
this
anything
I
haven't
encrypted
anything
people
know.
I
love
that
the
I
think
a
short-lived
working
group
is
the
right
answer.
I
know
there's
some
questions
about
the
relationship
between
this
and
odo.
You
know,
I
think
just
to
mentioned
was
in
the
chat.
I
think
it's
a
clear
generalization
of
odo
what
you
know
whether
I
think
eventually
we
do.
L
You
know
odell
will
be
a
ohtp
there's
right
here
from
talking
like
tommy
and
and
chris
and
others.
So
you
know
the
question
you
know
we
have
to
resolve
would
be
you
know,
odor
perceiving
parallels,
experimental
or
just
weight
on
this,
and
that
would
depend
on
how
how
long
without
that
would
take
to
get
this
done.
But
I
think
I
don't
there's
not
a
there's.
G
Yeah,
my
intent
was
certainly
that
this
be
used
for
odo,
but
if
it's,
if
it
turns
out
that
we
can't
make
that
work
or
something
happens,
that
that
means
that
we
need
to
move
faster
on
that,
then
obviously
we
can
work
that
out.
M
Payne
hi,
thank
you
yeah,
so
I
just
wanted
to
touch
on
some
of
the
replay
attacks
and
the
sort
of
security
model
that
you're
operating
on
in
here
and
and
you've
already
mentioned,
that
you
have
to
put
a
lot
of
trust
in
the
proxy
that
you
expect
the
clients
who
need
to
really
put
quite
a
bit
of
trust
in
the
proxy.
A
couple
of
questions
in
the
specification.
M
It
mentions
that,
like
co-location
of
the
request
resource
and
the
target
resource,
like
simplifies
kind
of
interactions
and
but
to
have
to
like
what
extent
do
you
technically
mitigate
this
kind
of
independence
from
the
server?
And
to
what
extent
are
you
expecting
it
to
be
done
on
like
a
out
of
technical
scope,
so
you're,
just
hoping
that
the
client
designates
the
proxy
in
like
a
policy
way,
rather
than
a
technical
sense
of
trust?.
G
Right
yeah,
so
that's
that's
a
good
question,
so
the
draft
actually
specifies
four
different
functions
but
imagines
that
two
of
those
functions,
the
the
target
resource
and
the
the
thing
that's
removing
the
encryption,
which
is
the
request
resource,
are
actually
operated
by
the
same
entity
in
a
lot
of
cases,
and
and
so
it's
the
it's-
the
interaction
between
the
the
server
operator
and
the
proxy
operator
that
that
are
most
interesting
to
the
client
and
those
are
the
ones
that
need
to
be
separate
entities.
G
When
you
say
a
lot
of
trust,
I
don't
think
this
is
a
lot
of
trust,
but
it
does
require
some
of
some
degree
of
trust.
And
so
what
we
had
imagined
is
a
range
of
things,
whether
that
be
contractual
and
so
enforced
by
some
system.
G
But
there's
also
the
possibility
to
have
audits
or
any
other
sort
of
system
in
place
to
ensure
that
the
the
proxy
maintains
the
the
level
of
trust
that
we
we
require
of
it,
which
is
mostly
that
it
doesn't
pass
client
information
or
information
about
client
identity
specifically
to
the
server.
M
Yeah,
I
guess
when
I
say
a
lot
of
trust
is
just
you
mentioned,
like
the
need
to
avoid
like,
if
the
proxy
abuses
its
position,
you
can
end
up
with
overload.
You
can
have
replay
attacks
if
the
proxy
chooses
to
act
in
a
bad
fashion,
and
so
it
would
be
helpful
to
know
if
you
plan
to
like
have
a
technical
mitigation
for
that
or
if
the
trust
is
kind
of
yeah
out
of
scope,
and
it's
just
going
to
be
determined
policy
basis.
G
Yeah,
so
you
mentioned
a
number
of
things.
The
overload
stuff
is
something
we're
continuing
to
to
work
on,
but
ultimately
it
it's
likely
to
come
down
to
those
sorts
of
technical
non-technical
constraints.
G
L
Yeah,
so
I
think
it's
probably
worth
like
just
like
trying
to
frame
this
question,
how
much
you
trust
the
proxy
a
little
bit,
so
I
think
there
probably
are,
and
the
first
thing
they
recognize
is
that
in
many
cases
this
is
a
replacement
for
existing
situations,
where
the
client
would
connect
directly
to
the
server.
L
So
in
the
case
of
like
of
like
odo
right,
the
climate
is
behind
the
desert,
ordinarily,
and
so
like
from
the
client's
perspective,
like
anything
is
like,
so
even
the
pro
the
prostate
fat
situation
is
no
worse
than
if
that
than.
If
then
this
had
been
deployed.
So
now
now,
certainly
that
once
you
have
this
in
place,
there
will
be
situations
in
which
you
know
you
might
want
to
use
it
that
you
weren't
prepared
to
do.
L
In
that
case,
you
of
course
have
to
try
to
proxy
in
the
and
the
server
not
to
collaborate.
The
I
think
the
the
the
emergency
questions
are
what
the
situation
is
referred
to
the
server
and
what
it
has
to
expect
from
the
proxy.
The
you
know
the
ng
replay
stuff,
obviously,
is
an
issue
note
the
interview
there's
a
not
nation
on
the
client.
The
client
has
built
into
replay
it's
only
the
server,
which
is
right
where
we
play.
L
This
is
like
think
about
this,
like
tls0tt
or
like
sending
s5
messages
around
so
so
the
questions
are
partly
like.
You
know
this
question
of
of
replay,
there's
questions
about
overload,
and
I
think
that
you
know
that
the
reason
that
overloads
an
issue
is
not
because
the
proxy
has
superpowers,
but
because
the
ordinary
anti-dos
mitigations
that
the
server
would
apply,
which
look
at
like
ipad
reputation,
won't
work
properly
because
everything
else
that
comes
from
the
proxy,
so
there
are
mechanisms
for
preventing
that.
L
But
yes,
typically,
it's
assumed
that
the
proxy
isn't
dosing
you.
If
the
process
is
drossing,
you
basically
have
like
one
giant
handle.
You
can
turn
where
you're
like.
I
don't
I
don't
want
the
price
to
connect
to
me
anymore,
and
so
the
proxy
is
a
strong
incentive.
That's
not
cheat
here
because
the
proxy
does
cheat
and
what
happens
is
all
the
people
behind
them
get
get
cut
off.
So
I
I
don't
think
you
know.
I.
I
don't
think
that's
like
something.
I'm
too
worried
operationally
the.
L
I
know
that
unless
there's
a
bunch
of
chat
here
about
the
about
like
are
we,
you
know
reconstructing
tour,
I
think
actually,
when
we
get
started
here
at
mixmaster,
more
than
tour,
so
I'm
typically
there
are
two
anonymity
kind
of
things.
There's
like
like
high
latency
mixed
networks
and
there's
like
things
like
tour,
I
think
mass
the
mass
tunneling
is
actually
more
like
tor.
I
I
I
also
will
be
in
favor
of
like
trying
to
like
have
several
enemy
networks
for
different
latency.
L
N
Just
done
your
the
point
about
the
replay
attacks,
it
seems
like,
if
I'm
understanding
this
properly
cases
like
dns
replay
attacks,
are
not
a
consideration
because
they're
important
requests
anyway.
Is
that
true?
Or
am
I
missing
something?
So
it
could
be
that
your
solution
to
replay
taxes
for
this
case,
because
I
don't
care.
G
That
is
going
to
be
the
case
for
a
lot
of
these
scenarios.
So
if
you
imagine
this
is
simple
information
retrieval,
which
is
what
dns
is,
then
your
response
might
well
be.
I
I
don't
care
it's
a
little
more
interesting
when
it
comes
to
things
like
telemetry
submission,
you
have
to
have
a
structure
in
place
to
to
ensure
that
a
replay
doesn't
result
in
multiple
submissions,
but
those
are
relatively
straightforward
to
to
build,
but
for
things
like
that,
it
does
sort
of
limit
what
you
can
do
with
the
mechanism,
though,.
K
C
C
C
L
C
C
M
M
I
have
a
good
enough
sense
of
it
like
how
yeah
how
much
is
in
and
out
of
scope
for
this
problem
if
it
is
a
really
tightly
scoped
we're
not
going
to
talk
about
discovery
of
proxies
or
anything
like
that,
and
it's
just
standardizing
the
protocol
rather
than
any
of
that
other
stuff.
So
it's
just
a
question
if
that's
included
in
support
for
a
short-lived
working
group,
but
it
would
be
like
a
discussion
about
charter
and
scope.
B
Yeah,
I
think
what
I
had
in
mind
was
the
tight
scope
that
martin
had
on
his
last
slide,
just
focusing
on
the
protocol,
as
opposed
to
all
the
discovery
aspects
and
how
you
would
instantiate
this,
and
I
was
thinking
we
would
workshop
the
charter
on
the
second
dispatch
mailing
list
to
give
people
a
chance
to
comment
on
that
before
we
final
send
out
for
last
call
and
finalization.
B
I
would
also
throw
in
as
a
scoping
question
whether
we
might
want
to
include
a
deliverable,
some
sort
of
like
systematization
documents,
I'm
talking
about
some
of
these
security
properties.
You
know
what
happens
depending
on
your
selection.
How
does
this
you
know
what?
How
does
this
relate
to
other
intermediation
protocols?
Things
like
that,
but
that's
not
at
all
clear
that
belongs
in
scope.
So
I'm
happy
to
debate
that
on
the
mailing
list.
M
A
Hi,
so
I'm
just
jumping
on
to
confirm
that
ben
and
I
have
caught
the
action
we're
going
to
coordinate
with
the
other
areas
to
figure
out
what
the
right
formula
is
to
mix
what
area
with
what
responsible
id
with
what
composition
of
the
working
group
shares
to
make
sure
we
get
the
right
cross
area
oversight,
because
I
think
that's
absolutely
kind
of
the
right
thing
to
do,
and
we
saw
a
lot
of
discussion
about
that
in
the
chat.
Thank
you.
B
All
right
thanks
everyone
for
your
input.
I
think
we
can
consider
that
one
dispatched
and
thank
you,
martin
for
the
presentation,
so
with
that.
I
think
we
are
done
with
our
first
topic
of
the
meeting
and
we
are
on
to
your
own
talking
about
a
common
ciphertext
format.
O
Okay,
so
I'm
iron
chef.
This
is
joint
work
with
glebka,
salman
and
joshner,
and
this
is
a
proposal
for
a
generic
ciphertext
metadata
format.
O
O
Thank
you
so
documents
that
define
encryption
or
ciphers
or
algorithms
often
define
the
format
of
the
output,
that's
clear
and
simple,
but
that's
the
bare
minimum.
It's
not
what
you
need
if,
if
you
are
to
manage
huge
amounts
of
ciphertext
so
stored,
addressed,
basically
all
over
your
data
stores
stored
in
databases
stored
in
data
lakes,.
O
Stored
in
the
data,
mods
and
all
sorts
of
of
places
where
people
keep
data,
including
sensitive
data
in
the
the
point
to
remember,
is
that
we
actually
have
three
personas,
not
just
whoever
creates
and
encrypts
the
data
and
whoever
decrypts
the
data.
That's
clear,
but
we
also
have
a
third
persona,
which
is
a
data,
a
suite
of
data
governance
tools.
O
People
who
manage
data
at
scale
need
to
need
to
have
tools
for
that,
and
they
will
go
into
details
in
the
next
slide,
but
to
enable
er
to
manage
encrypted
data,
we
will
need
to
define
ciphertext
metadata
that
can
be
handled
by
multiple
tools,
and
so
the
basic
thing
you
need
is
a
key
identity
and
probably
a
key
version
just
so
that
you
can
go
back
and
decrypt
the
data,
but
this
needs
to
be
extensible
people,
people
have
different
requirements
when
encrypting
data
at
scale-
people,
for
example,
apply
key
wrapping
and
key
derivation
and
those
require
additional
information.
O
O
O
O
O
With
a
high
probability
detect
what
is
what
is
encrypted,
so
you
need
to
have
a
format
that
can
be
recognized
across
the
enterprise
or
across
the
data
store,
so
that
you
know
what
data
is
encrypted
and
then
you
you
want
to
have
the
next
step
so
like
which
key
management
system
is
responsible
for
this
data,
or
perhaps
what
what
specific
key
has
been
used
for
this
data
to
go,
so
so
that
if
the
data
needs
to
be
decrypted,
it
can
be
acted
upon,
but
even
before
decryption,
the
the
the
two
requirements
are
to
detect
and
identify
encrypted
data
and
to
attribute
data
back
to
who
owns
it
so
that
again,
if
data
access
needs
to
be
granted
the
the
person
who
is
looking
or
the
tool,
that's
looking
at
the
data
can
know
who
owns
the
data
and
who
is
responsible
to
grant
access
into
the
encrypted
data.
O
So
we
started
with
this
set
of
requirements
and
ended
up
with
a
rather
simple
header
format
that
we
proposed
to
use
for
for
ciphertext,
and
it
consists
of
a
very
short
two
by
two
octet
fixed
header,
followed
by
a
variable
length,
additional
header,
that's
expressed
as
sibo.
We
started
off
with
generic
tlv.
O
Then
we
got
the
feedback
that
instead
of
reinventing
tlv
and
various
ways
of
optimizing
and
improving
until
we,
why
not
just
use
sibo
and
obviously
that's
the
right
thing
to
do
so.
The
current
version
zero
one
uses
sibo
and
on
the
next
slide,
some
some
more
details
of
what
this
sibo
is
so
next
slide.
Please.
O
We
are
using
the
the
cddl
definition
language,
but
never
mind
the
language
itself.
I
think,
even
if
you're
not
familiar
with
cddl,
it's
it's
quite
clear
what
we
have
here.
So
we
have
two
data
items
that
are
mandatory:
the
key
provider
and
the
key
id
one
is
a
an
unsigned.
Integer
one
is
a
byte
string
and
this
is
followed
by
a
collection
of
of
other
either
integer
or
byte
string,
attributes.
O
The
two,
the
two
mandatory
fields,
obviously
the
most
important:
what
what
is
the
key
management
system
that
owns
the
key
or
who
should
they
go
to
ask
for
more
details
about
this
piece
of
data
and
then
a
key
identity
that
you
can
hand
over
to
this
key
management
system?
O
And
it
will
do
its
thing
and
then
additional
details
that
you
might
want
to
have
is
a
key
version
number,
which
is
the
simplest
way
to
to
enable
key
rotation
on
on
data,
addressed
auxiliary
data
that
you
can
use
for
either
key
derivation
or
key
wrapping
and
three
fields
that
are
useful
when,
when
you,
when
you're
doing
aead
for
for
the
data
trust.
O
O
And
the
reason
why
this
actually
needs
to
be
standardized,
if
it
was
clear,
is
that
often
large
enterprises
use
key
management
coming
from
different
windows,
different
cloud
cloud
providers
and
then
the
different
encryption
libraries
coming
from
here
and
there
and
the
more
we
can
have
it
standardized
the
more
we
can
streamline
management
of
a
very
diverse
and
and
complicated
data
stores
and
next
slide.
O
So
speaking
of
implementations,
my
own
company
into
it
implements
a
similar
format
internally
and
not
specifically
the
one
we
we
specify
here
but
a
similar
one
and
where
we
have
been
using
it
for
very,
very
significant
amounts
of
data
across
the
enterprise
and
then
just
two
examples
of
cloud
providers
that
define
their
own
encryption
or
ciphertext
formats,
amazon,
web
services
and
google
each
defining
its
own
format.
O
And
so
what
we
would
like
to
see
is
a
very
narrow,
scoped,
a
working
group
to
take
on
this
work
working
very
specifically
on
the
format
and
nothing
else,
and
that's
it
I'll.
Take
questions.
P
Some
lad
cloudflare.
This
seems
like
a
xccd
997
issue.
If
all
these
incompatible
formats-
and
I
are
saying,
okay-
let's
make
one
format
to
unify
them
all
that
does
a
bunch
of
things
for
each
one.
Why
isn't
that
just
going
to
lead
to
okay
there's
another
format
and
it's
incompatible
with
all
the
others
and
people
haven't
switched
to
it.
O
L
So
so
I'm
also
confused.
It
seems
to
me
we
have
like
already
formats
that
like
allow
you
to
encrypt
things
with
fixed
keys
and
allow
you
to
have
identities
for
those
keys
and
describe
the
algorithms
like
cos.
A
is
one
such
one
as
is
jose
as
for
that,
since
the
cms
so
like,
I
don't,
I
guess
I
don't
quite
understand
what
like
like.
O
I
don't
think
this
is
true,
to
this
extent,
focus.
O
Because
I
was
was
envisioned
or
is
envisioned
as
a
solution
for
for
data
and
transit
and
has
a
different
different
require
a
different
set
of
requirements.
L
Okay,
well,
then,
I
think
the
place
to
start
would
be
not
with
a
proposal
but
with
an
enumeration
of
the
requirements
and
how
and
how
busy
conclusions
don't
meet
them.
But
I
will
say
that,
like
when
I
hear
like
things
are
too
big,
I'm
automatically
suspicious
until
I
see
some
very
strong
evidence
that
life,
I
think,
is
what
the
overhead
we're
talking
is
really
too
big.
Your
average,
like
you
know
when
things
are
encrypted,
like
that
off
tags
out
a
lot
of
data
and
a
lot
of
space
that
that
nonsense.
L
A
lot
of
space
like
as
a
practical
matter
like
you
know,
I
I'm
not
persuaded
that
the
the
overhead
of
co,
because
you're
wrapping
is
going
to
be
too
big.
So
until
I
saw
that
I
would
not
be
in
favor
of
this
more
strictly
on
a
central
question:
does
something
bind
this
header
to
the
content.
O
L
Right
well,
this
seems
like
a
great
opportunity
to
re,
to
remake
all
the
errors
that
people
made
with
previous
formats
so
anyway,
this
is
a
the
dispatch
question
special
question.
I
don't
think
we
should
do
this,
so
I've
said
a
lot
more.
D
Gilmore
with
the
aclu
also
co-chair
of
the
open
pgp
working
group
just
wanted
to
add
to
the
list
of
standards
that
this
seems
to
potentially
duplicate,
which
includes
open
pgp,
which
is
actually
designed
for
data
at
rest,
not
just
data
in
transit.
So
again
the
the
gap
analysis
would
be
useful
if
this
is
actually
doing
proposed
work.
I
also
want
to
put
a
bit
of
a
challenge
to
one
of
the
proposed
justifications
here.
The
claim
that
we
need
to
tag
data
that
is
pii
versus
not
pii.
D
I
find
that
dubious.
I
think
the
whole
term
pii
is
actually
pretty
dubious,
because
information
is
personally
identifiable
in
combination
with
other
pieces
of
information
and
that's
incredibly
difficult
to
determine.
Even
when
you
have
clear
text,
I
don't
think
that
a
simple
flag
on
the
outside
of
a
ciphertext
packet
is
sufficient
to
be
able
to
track
that
sort
of
thing,
and
so
I'm
also
similar
to
ecker
before
very
dubious,
about
the
usefulness
of
this
work
and
its
ability
to
accomplish
the
stated
goals.
D
So
I
would
move
towards
not
putting
this
into
the
itf
unless
we
have
a
much
clearer
understanding
of
what
it's
trying
to
do
and
how
it's
going
to
actually
do
it.
O
D
D
It
seems
a
little
bit
like
you
are
reintroducing
the
problem
that
it
claims
to
solve.
If
the
goal
is
protecting
from
person
identifiable
data
being
leaked
in
certain
places,
right,
you're,
basically
adding
pii
to
the
outside
of
the
packet.
O
Yeah
so
again,
no
I'm
not
proposing
to
tag
pii
or
to
add
pii
on
the
outside
of
the
of
the
encrypted
data.
Please
don't
call
it
a
packet.
It
is
not,
and
but
I
mean
a
a
complete
discussion
of
why
people
are
scanning
data
and
what
it's
useful
for
is
very
interesting.
But
it's
very
much
outstep
outside
of
the
scope
of
this
discussion
or
in
fact,
the
scope
of
the
of
the.
I
Proposal,
hi
davidskenazi.
I
First,
I
want
to
slightly
echo
what
people
have
said
before
and
but
additionally,
it
sounds
like
the
problem
that
you
want
to
solve,
has
already
been
solved
before
there
appear
to
be
open
source
projects
that
have
solved
this
to
some
extent
and
I'm
not
seeing
what
the
role
of
the
itf
is
here
like
this
isn't
a
networking
protocol.
I
This
is
a
file
format
and
I'm
not
seeing
folks
like
who
already
have
let's
say
their
own
formats
lining
up
to
say:
we
need
something
new,
so
unless
we
really
have
proof
that
there
is
interest
from
the
community
here
and
additionally
proof
that
this
fits
into
the
charter
of
the
itf,
which
I'm
not
seeing,
I
don't
think
we
should
move
forward
with
this.
I
would
love
to
see
those
points
elaborated
on.
First.
O
O
Q
Phil
yeah,
I
was
gonna,
say
almost
more
of
the
same,
a
constant
anti-pattern
that
I
see
in
standards
development
is
people
say
there
are
six
of
those,
let's
standardize
them
and
create
a
seventh.
Q
Another
anti-pattern
is,
and
we
want
to
focus
on
just
this
set
of
concerns,
and
I
think
that
that's
that
that's
the
anti-pattern
I'm
seeing
there.
The
combination
of
those
two
in
that
this
is
a
very
point
solution
to
the
problem
of
encryption,
and
I
don't
think
that
it
can
hope
to
meet
more
meet
a
wide
range
of
stuff.
Q
You
know:
we've
got
things
like
pks7
that
address
a
wider,
the
problem
in
the
large
already-
and
I
don't
see
how
adding
another
solution
that
only
addresses
one
particular
niche
set
of
requirements
where
you
want
it
is
relevant
and
in
the
days
when
I've
got
90
terabytes
of
disks
sitting
next
to
me,
I'm
getting
really
skeptical
about
arguments
of
we've
got
to
scrape
ever
compress
every
bite
and
therefore
we
need
a
new
standard.
I
mean
like.
O
Wat
outcomes,
the
deliverables
of
the
itf
are
not
addressing
this
problem.
Q
Yeah,
but
I'm
of
whether
itf
has
a
spec
I
mean
like.
I
don't
use
cose
in
my
work.
I
never
read
the
cosy
spec
because
it
doesn't
address
my
problems.
I've
got
a
different
set
of
problems
and
it
is
easier
for
me
to
generate
a
new
specification
that
actually
meets
my
needs
than
to
reuse
and
I
don't
see
an
advantage
of
getting
of
the
reuse.
C
This
is
kathleen
without
a
chair
hat
on.
I
am
curious
to
hear
more
on
the
use
cases
just
thinking
you
know
I
recently
left
dell
emc
and
was
there
a
long
time,
so
you
know
seeing
that
there
is
someone
from
dell
on
there.
We
have
someone
from
aws
who
are
thinking
about
these
problems.
I'd
want
to
know
is
this
working
towards
some
multi-cloud
type
solution
for
compatibility.
C
O
B
All
right,
I
think
we
have
trained
the
queue.
So
looking
at
the
discussion
here
and
the
discussion
on
java,
it
sounds
like
folks.
I
think
we
need
a
little
bit
more
precision
on
the
requirements
and
especially
kind
of
gap
analysis.
These
are
the
the
current
solutions
that
are
out
there.
Things
like
cose
in
particular,
so
I
think
the
the
this
my
proposed
dispatch
outcome
here,
the
kind
of
no
no
concrete
action,
further
discussion
needed.
I
think
we
can.
B
The
dispatch
list
or
a
new
mailing
list
so
folks
won't
have
a
focused
menu
for
this.
Does
that
sound
about
right
to
people
open
the
floor
for
feedback
on
that
that
outcome.
L
So
I
think
the
spirit
of
this
process
is
that
we
should
specify
what
we,
what
would
be
required,
roughly
speaking
for
that
for
to
proceed
beyond
the
mailing
list,
and
I
think
what
we
heard
was
like
a
real
gap.
Analysis
of
why
the
translation
is
going
to
do
it
and
some
evidence
that
there
are
people
who
would
actually
apply
this
technology.
B
All
right,
thank
you
all
right.
Thanks
for
the
presentation,
you're
on
all
right
now,
we
are
on
to
our
third
topic,
which
is
rich
sol,
to
talk
about
usage
of
subject,
alt
name
in
certificates.
S
H
Sorry
about
that,
thank
you
very
well.
All
right
go
ahead.
So
no
slides
you
can
look
at
the
text
or
the
dinosaur
behind
my
head.
Rfc
6125
is
10
plus
years
old.
At
the
time
it
said.
Oh,
we
shouldn't
use
the
common
name
field
to
identify.
H
You
know
servers
anymore.
The
industry
has
moved
forward.
Nobody
really
uses
the
common
name
except
they
have
to
because
nobody
has
said,
don't
use
the
common
name.
H
Comment
in
the
chat
there
says:
should
this
have
been
called
cn
die,
die,
die,
yeah,
but
die
die,
die
should
die,
die
die,
so
the
joke's
got
jokes
played
out
so
anyhow,
6125
was
a
d
standard,
a.d
sponsored
I
don't
care
where
this
goes.
I
would
rather
not.
I
saw
some
discussion
on
the
mailing
list
about
increasing
you
know
doing
more,
but
I'd
rather
keep
this
pretty.
H
D
Hi,
rich,
hey,
I'm
sorry,
I'm
getting
an
echo,
I
think
through.
I
don't
know,
I
don't
know
who
now
I'm
not.
So
I
apologize
for
not
having
read
this
draft,
but
I
could
you
speak
a
little
bit
to
how
this
applies
to
non-tls
uses
of
x-509,
in
particular
s,
mine,
where
I
believe
the
common
name
is
typically
used
to
identify
the
person's
natural
name.
H
Or
I
think,
as
with
6125,
it
only
talks
about
tls
use.
T
I
think
this
draft
can
be
worked
on
in
utah,
but
I
agree
with
dkg
that
some
qualification
is
needed
in
the
text
that
the
draft
is
taken
about
to
less,
because
currently
tls
is
not
mentioned
at
all
in
the
draft,
except
for
reference
to
rfc
6125,
and
when
I
first
read
it.
My
first
impression
was
that
it's
very
generic
approaches
it
can
be
gets
rid
of
common
name
from
distinguished
name
and
certificate.
It
can
be
applied
for
a
arbitrary
security
protocol
like.
T
So
if
you
clarify
that
you
are
talking
only
about
ls
explicitly,
I
think
that
utah
looking
group
is
a
suitable
home.
H
Sure
I
mean
I
just
assume
that
you
know
when
you
post
a
draft
people
read
the
draft
and
what
it
updates
so,
but
anyhow,
yes,
putting
use
the
sand
field
for
tls
authentication
and
putting
it
in
the
abstract
sure.
Absolutely.
Q
Oh,
it's
me
yeah.
I
was
gonna.
I
really
like
this.
I
think
that
we
should
do
it.
I
think
it
could
probably
be
done
as
ad
sponsored.
Q
Q
You
should
only
be
doing
a
subject,
alt
name
at
this
point,
and
I
think
that
we
obsoleted
it
back
in
97.
Q
So
I
think
it's
highly
unlikely
that
there's
anything
out
there
in
tls
land,
certainly
certainly
nothing.
That's
a
browser
that
is
using
this
capability
and
anything
that
is,
is
probably
using
a
set
of
cert
of
routes
that
is
just
so
old
that
it's
not
necessary
to
consider
it
either.
You
know
most
of
the
roots
are
expired,
so
I
I
I
think,
yeah.
H
I
think
I
well,
I
ryan
sleevy
read
it
and
I
took
him
as
the
cab
form
rep,
so
they're
they're,
fine
with
it
at
least
unofficially.
But
yes,.
K
Q
H
Right
yeah
ryan
has
said:
he'll
do
that
right
bring
that
forward.
S
Bob
okay,
I
kind
of
like
this
draft,
but
in
practicality,
using
subject,
alt
name
with
open
ssl,
is
at
least
was
extremely
hard
on
the
command
line
for
rich.
You
know
what
I
I
did
some
years
ago
when
I
worked
on
this
my
drafts.
What
it
took
to
to
use
this,
maybe
as
we
push
back
to
the
open
sale
people
to
make
it
easier
to
make
certs
that
have
subsequent
name
and
don't
have
common
name,
because,
yes,
there
are
products
which
do
this,
but
trying
to
use
the
opus
open,
ssl
toolkit
command
line.
H
It
was
hard
it
isn't.
There
is
a,
I
forget
what
the
command
line
flag
is,
but
you
can
just
specify
the
sand
field
on
there,
and
some
of
the
docks
could
be
updated.
Okay,
dkg,
I'm
no
longer
part
of
the
openssl
team
and
soon
to
be
no
longer
part
of
the
project.
S
H
S
R
R
R
I
like
this
document,
but
I
am
not
sure
that
the
lack
of
reference
to
current
c
browser
forum
recommendation
is
reasonable.
R
As
far
as
I
remember
it's
a
car,
it's
a
currently
the
current
practice
of
c
browser
forum,
and
I
think
this
reference
could
be
useful.
Thank
you.
H
P
B
Thanks
and
I
think
my
comments
are
going
to
be
along
the
same
lines,
I
think
this
this
makes
a
lot
of
sense
in
the
context
of
the
tls
pki
web
pki.
It
might
not
make
sense
in
other
pkis
like
dkg
pointed
out,
so
I
think
kicking
this
back
to
utah
makes
a
lot
of
sense.
B
D
Just
wanted
to
voice
support
for
putting
it
in
uta,
since
I
just
put
that
in
the
chat,
I
want
to
say
it
out
loud,
and
I
also
wanted
to
clarify.
There's
been
a
little
bit
of
discussion
here
as
though
this
is
somehow
constraining
the
cas,
and
it
doesn't
look
to
me
like
it
is.
It
is
constraining
the
verifiers
and
I
don't
think
we
should
get
that.
We
should
let
ourselves
get
mixed
up
by
that.
D
What
we're
saying
is
when
you're
verifying
don't
look
at
this
thing
and
obviously
that
will
have
a
downstream
impact
on
what
the
cas
do.
But
I
think
it
should
be
very
clear
that
we
are
talking
about
how
the
verification
stack
works.
Not
the
issuance
stack.
B
So
I
think
there
actually
is
a
provision
in
the
document
that
constrains
cas.
That's
certainly
something.
H
Yeah,
the
working
community
dkg
is
right.
It's
about
verification
and
there's
like
a
paragraph
that
says,
and
if
the
ca
needs
to
do
it
puts
a
cn,
feel
don't
make
it
look
like
a
name,
don't
make
it
look
like
a
dns
name,
but
sure
I
mean
we've
been
backwardly
compatibly,
doing
cn
and
equivalent
sand
fields
for
10
years.
U
Yeah,
I
I
agree
with
the
uda
place
and
ricky
if
you
can
post
a
link
to
the
document
about
how
to
do
the
configuration
before
ssl,
if
it's
not
so
easily
definable.
That
would
be
really
helpful
because
the
guys
I've
been
working
with
have
been
struggling
with
this
as
well
in
the
ied
context
for
device
certificates.
H
B
All
right
so
we're
through
our
queue.
It
sounds
like
we've
got
pretty
good
agreements
here
to
shift
this
back
to
uta
utah.
However,
we
pronounce
it
so
we'll
consider
that
to
be
the
dispatch
outcome.
Last
last
call
for
objections
to
that
all
right,
seeing
no
one
leaping
to
the
mic,
let
it
be
so
decided.
Thanks
for
the
presentation,
rich.
H
A
B
All
right
is
russ
helsley
here,
I
think
he's
our
last
topic
for
the
day.
V
Slide
the
ers
or
evidence
record
syntax
is
in
rfc
4998.
It
was
produced
by
the
ltans
working
group
a
long
time
ago.
V
V
In
addition,
ltans
produced
rfc
5276
and
in
that
rfc
they
only
provided
one
asn,
one
module
that
used
the
older
syntax.
V
V
V
So
glad
me
to
go
put
that
auto
reconnected.
I
was
like
oh
no
now
what
okay
I'm
back,
also
provides.
These
two
follows
those
conventions
from
jim
shodd's
rfcs,
59,
11,
59,
12.
next
slide.
V
V
So
implementers
have
found
59,
11,
15
9,
very
useful,
we're
just
trying
to
bring
forward
those
same
things
that
implementers
have
found
useful
to
the
ers
specification
as
well
in
my
last
slide,
and
so
we
just
recommend
that
these
become
informational,
rc's
and
since
it's
one
document,
we
just
thought
the
easiest
thing
to
do
is
have
it
80
sponsored
and
I'd
like
to
hear
what
people
think.
B
Now
philly
disappeared
too
quickly
like
what
what's?
How
do
you
think
we
should
do
it?
We
have
a
working
group
80
sponsor
what.
Q
I
think
it
should
be
80
sponsored
I
mean
like
this
is
cleanup
stuff
from
from
what
from
what
I
gather,
we're,
not
expanding
semantics
or
whatever
we're
it's
a
clarification
of
the
documentation.
Q
B
And
for
what
it's
worth,
that
was
my
analysis
as
well.
This
is
a
straightforward
piece
of
work.
It
doesn't
need
a
whole
lot
of
technical,
broad
review,
so
it
made
sense
as
80
sponsored
for
a
minute
as
a.d.
You
have
to
come
in.
A
V
Sure
so
I
have
been
making
open
source
contributions
to
the
pi
asn
1
module
library,
and
so
I
this
was
one
of
the
specifications
that
was
missing
and
I
found
I
had
to
do
this
in
order
to
implement
that.
V
N
V
Yes,
I
was
careful
to
make
no
semantic
or
syntactic
changes
to
the
bits
on
the
wire.
B
So
it
seems
to
me
like
it
would
be
good
if
we
could
have
someone
review
to
verify.
That's
the
case
sometime
during
last
call,
but
doesn't
exactly
much
more
than
last
call
for
that
all
right
unless
there
are
further
comments
or
objections,
this
course
of
action.
I
think
we'll
declare
a
recommendation
for
80
sponsorship
as
our
dispatch
outcome
here.
Anyone
want
to
jump
to
the
mic
and
raise
their
hands
in
that
position.
K
A
B
B
Hearing
none,
we
will
go
ahead
and
proceed
to
the
chairs
sum
up.
Let
me
try
and
do
this
from
memory,
and
someone
can
correct
me
if
they've
got
better
notes
so
for
oblivious
http.
I
think
we
agreed
to
spin
up
a
small
working
group
for
that
and
the
charter
will
be
workshopped
on
insect
dispatch,
mailing
list
and
we'll
figure
out
what
the
precise
scope
is.
There
kick
that
over
to
the
80s
for
last
call
for
its
review
cycles
and
whatnot
for
the
ciphertext
format.
B
The
decision
there
was
that
it
needed
some
more
discussion
to
clarify
the
requirements,
views
of
the
existing
formats
and
to
clarify
who
the
the
constituency
is
that
for
whom
this
matters
and
then
make
sure
it
would
get
some
uptake
so
more
discussion
on
the
second
specialist.
B
B
Okay,
new
mailing
list,
so
yeah,
please
contact
the
ids
for
your
mailing
list.
S
B
On
the
use
of
sand
that
got
dispatched
back
to
uta,
that
was
an
easy
one
and
finally,
the
asn
1
module
is
going
to
be
80,
sponsored
by
roman
there's,
our
outcomes,
good
job
being
decisional
folks,
and
with
that
I
think
we're
at
the
end.
Thank
you
for
your
time.