►
From YouTube: IETF111-SECDISPATCH-20210726-2300
Description
SECDISPATCH meeting session at IETF111
2021/07/26 2300
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
A
Good
evening
or
good
morning,
it's
2
a.m,
where
I
am
in
in
helsinki,
so
welcome
everyone
to
ietf,
11,
111,
so
third
session
of
the
first
day.
Hopefully
you
had
product
productive
meetings
in
the
prior
two
sessions,
I'm
still
waiting
for
richard
to
share
the
screen
before
we
can
get
started
by
the
way
this
is
being
recorded
just
fi.
I
I'll
repeat
this
again
when
we
are
going
over
the
slides.
A
C
C
Yeah
there
was
some
delay
in
it,
starting
I'm
loading
the
slides
about
to
try
sharing
again
thanks
to
mac
os
security
features,
I
had
to
restart
firefox
to
enable
sharing.
A
B
D
C
E
A
A
Folks,
I
guess
you
see
my
slides
in
full
screen
I'll
get
started.
I
don't
want
to
cause
any
more
delays.
We
are
already
for
me
at
minutes
behind
our
schedule
so
good
evening
good
morning.
Welcome
everyone
to
ietf
111.
This
is
sec
dispatch,
let's
get
started
so
hopefully
you
have
seen
the
note
well
already
a
couple
of
times,
but
still
it's
good
good
to
remember
that
we
are
governed
by
these
best
current
practices.
A
A
As
I
stated
before,
this
session
is
being
recorded,
so
here's
some
useful
rules
to
help
you
along
the
meeting
make
sure
the
video
is
turned
off
and
mute
your
microphone
unless
you're
speaking
as
you
see
I'm
using
headphones,
and
I
recommend
all
of
you
to
do
the
same
as
well.
A
A
We
also
have
jabber,
and
I
think
one
of
the
coaches
will
be
monitoring
the
chat
and
and
bringing
your
questions
forward.
A
If
you
don't
want
to
unmute
or
or
show
your
video
yourself
there's
some
more
useful
links,
if,
if
you
need
help
with
how
to
join
the
meeting
and
and
if
you
need
some
assistance
more
links,
so
the
slides
are
all
for
most
of
the
presentations
the
slides
are
already
uploaded
and
available
in
in
the
materials
we
are
still
missing
a
couple
of
slides.
I
tried
to
ping
the
authors
couple
of
times
but
haven't
received
their
slides
here.
Yet
I
see
them
in
the
participant
list
by.
A
So
please
do
send
us
your
slides
or
upload
them
directly
to
data
tracker,
we'll
be
taking
meeting
minutes
brief.
Meeting
minutes
and
ross
has
kindly
volunteered
to
to
help
us
within
minutes,
but
if
there
is
anyone
else
who
wants
to
help
along
ross,
please
feel
free
to
do
so
it
will.
It
is
really
appreciated.
We
don't
really
want
like
detailed
meeting
minutes,
but
it's
important
to
capture
important
decisions
or
conclusions
we
arrive
at
in
the
in
the
meeting.
A
I
already
introduced
the
coaches.
We
have
a
mailing
list
and
a
charter,
so
maybe
some
ground
rules
that
you
should
know
this.
This
working
group
doesn't
adopt
documents.
It
only
recommends
next
steps
and
that's
what
we
are
going
to
do
with
all
the
drafts
that
are
presented
today.
We
have
several
possible
outcomes,
so
we
could
direct
a
draft
to
an
existing
working
group.
A
We
could
suggest
forming
a
new
working
group
and
going
through
a
buff
if
that's
needed.
We
could
also
request
our
ads
ben
keduk
and
roman
daniloo
to
sponsor
the
draft.
We
could
also
just
say
that
more
discussion
is
needed
or
then
the
last
possible
outcome
is.
That
idea
should
not
work
on
this
topic
at
all.
So
when
you're
at
the
mic
and
giving
comments,
it's
very
nice
for
the
authors
to
receive
technical
feedback,
but
for
us
the
chairs,
it's
also
important
to
get
feedback
on.
What
do
you
see
as
the
potential
outcome?
A
A
A
I
guess
going
once
going
twice:
we
can
start
with
the
tls
1.3
transport
model
for
snmpv3
ken.
I
didn't
receive
your
slides.
They
are
not
in
the
meeting
materials.
Do
you
want
to
share
your
screen
and
present
them
directly,
but
please
do
remember
to
send
us
your
slides.
In
any
case,
we
need
to
upload
them
to
the
data
tracker.
F
Yes,
so
my
screen-
and
I
just
seen
an
email.
A
It
is
a
little
bit
better.
Yes,.
A
A
F
Okay,
so-
and
I
did
send
you
a
copy
of
these
a
little
while
ago-
sorry
for
the
delay
on
that.
But
I
am
a
consultant
under
contract
to
the
usdot.
So
the
department
of
transportation
can't.
F
Okay,
I
am
a
consultant
to
the
department
of
transportation
in
the
us
and
they
are
asking
me
to
present
this
today
to
try
to
integrate
snmp
and
tls
1.3.
F
The
current
version
of
6353
is
based
on
tls
1.2,
and
there
is
one
significant
problem
that
does
not
allow
it
to
be
used
with
the
new
dtls
1.3,
so
we'll
review
those
changes
and
then
discuss
the
path
forward
after
we
give
a
little
bit
of
background
of
how
we
use
snmp,
it
is
our
primary
protocol
for
its
field
devices
for
both
center
to
field
and
field
to
field
communications
within
us,
and
it
is
also
used
fairly
extensively.
Probably
the
most
common
approach
internationally.
F
E
Okay,
so
excuse
me,
so
people
are
still
having
a
very
difficult
time.
I
can
hear
you
but
lightly,
and
so
some
of
the
the
people
are
wondering
they
just
can't
hear
at
all
they're
wondering
if
your
settings
are
set
to
your
computer
and
not
your
headset.
So
I
don't
know
if
maybe
you
could
bring
your
computer
closer
in
case.
That's
the
mic.
That's
in
use!
E
C
Would
it
maybe
be
good
to
move
to
the
next
presentation
while
we,
so
it's
a
lot
of
representation
time
to
work
out
audio
issues?
Okay,
okay,
so
moving
out
of
the
agenda?
Who
is
up
next
on
the
on
the
agenda.
C
I
can
pull
up
your
slides
or
you
can
draw
them
as
you
like.
I
can
do
it.
I
just
ask
okay,
okay,
great
looks
like
it's
starting.
H
H
Rails.
Okay,
so
you
should
see
those
hey,
so
I've
got
this
draft.
It's
been
discussed
a
bit
in
mls
on
the
mailing
list.
I
presented
it
at
the
last
interim
so
for
those
of
you
that
were
at
the
last
mls
interim,
these
slides
are
going
to
look
very
familiar,
but
we
have
had
an
update
since
then
so
I'll
move
on,
let's
see
great
yeah,
so
we
have
a
slew
of
authors.
A
couple
are
in
the
room,
so
olaf
and
sophia
I'm
gonna,
welcome
them
to
jump
in.
H
I
don't
know
fred
and
gerschabot
are
here,
but
yeah
we've
been
working
on
this
draft
since
I
guess
february
earlier
this
year,
and
the
goal
of
it
is
just
to
expand
existing
documentation
that
defines
intended
communications
from
a
few
different
perspectives
to
try
to
get
as
complete
and
coherent
definition
as
possible.
We
don't
want
to
be
verbose
at
the
same
time,
the
especially
the
rfcs,
but
other
things
out
there
tend
to
not,
I
think,
do
a
sufficient
job
of
explaining
exactly
what
an
intent
encrypted
system
is.
H
So
the
things
that
we're
hoping
for
with
this
draft,
but
that
maybe
you
don't
see
explicitly
in
the
text,
but
this
is
sort
of
the
I
don't
know.
If
you
want
to
call
it
the
ulterior
motives,
we
want
to
make
sure
that
things
that
are
not
into
end
encryption
can't
just
be
called
it.
So
we've
seen
I've
seen
in
the
in
the
press,
even
things
that
you
know
it's
like
an
encrypted
system
that
has
key
escrow
or
whatever
I
mean
it's
called
it's
like.
It's
don't
worry
it's
still
encrypted.
H
We
want
to
be
able
to
make
sure
that
there's
a
clear
definition
from
an
authority
and
ietf
is
the
best
one
I
can
think
of
that.
Has
it
well
defined
such
that
sort
of
thing
isn't
possible.
H
Working
group
is
that
we
could
draft
this
in
parallel
to
its
other
drafts,
such
that
it
could
potentially
be
a
place
where
other
definitions
live
as
well,
so
they
don't
that
sort
of
definitional
work
doesn't
have
to
muck
up
some
of
the
other,
the
the
protocol
draft
and
the
architecture
draft,
and
then
the
last
one
is
that
it
possibly
can
help
demystify
or
just
complement
some
of
the
implementations
out
there
of
intended
group
systems
by
setting
a
norms
and
principles
driven
approach
to
what
it
is,
people
are
trying
to
achieve
when
they
make
encrypted
messaging
apps,
so
things
that
we
don't
want
to
do
with
this
draft
we're
actively
and
consciously
intentionally,
avoiding
just
so
that
folks
don't
come
to
the
mic
and
suggest
these
things.
H
We
don't
want
to
say
what
it
isn't
explicitly.
We
want
to
make
it
sure
it's
a
proactive
definition.
It
also.
We
would
like,
in
that
same
vein,
to
avoid
invoking
threats
or
on
path
attacks.
Even
or
you
know
it
should.
It
should
be
able
to
stand
on
its
own
is
what
we're
hoping
and
also
you
know
as
much
as
possible.
H
There
has
been
there's
been
a
lot
of
agreement
about
what
constitutes
indian
encryption
and
and
implicitly
than
what
it
isn't,
but
I
think,
having
sort
of
very
public
and
ietf
is
public.
Its
lists
and
its
meetings
are
on
youtube.
Like
discord.
Disagreement
about
the
finer
points
would
possibly
do
you
know
more
damage
than
good.
So
if
there's
there's,
you
know
sort
of
view
that
that
ietf
can't
agree
on
what
intent
encryption
is.
That
would
be.
That
would
be
a
bad
external
view.
H
So
that's
we're
trying
to
avoid
avoid
that
in
general,
I'm
gonna
get
into
the
specifics
now
that
it's
broken
into
three
parts
we
started
with
a
very
the
first
section
was
really
succinct.
I
was
just
trying
to
attempt
a
formal
definition
based
on
the
constituent
parts
of
the
end-to-end
principle
in
encryption,
but
we
realized
that
actually
quite
a
bit
of
the
work
we're
going
to
end
up
doing
on
this
draft
lies
in
the
definition
when
end
is
for
a
variety
of
important
reasons.
H
So
we've
now
broken
that
out
into
the
formal
definition
piece
talks
about
end.
Then
it
talks
about
intent
principle
and
then,
lastly,
it
defines
encryption
and
again
formal
definition.
Just
means
we're
trying
to
like
succinctly
summarize
things
that
are
already
out
there
with
few
words,
crisply,
etc.
H
The
second
one,
the
second
section
we
felt
would
be
a
useful
thing
to
actually
talk
about
the
features
of
an
independent
encrypted
system
and
the
requirements
from
a
development
and
design
perspective,
which
I
think
it's
where
you
would
talk
about
things
like
perfect
forward
secrecy,
or
you
know
anonymity
and
that
sort
of
thing,
and
then
the
last
section,
which
I
really
am
glad
we
have
is
also
what
a
user
would
expect
so
trying
to
as
best
we
can
match
what
is
a
meaningful
understanding
of
an
independent
encrypted
systems
guarantees
for
users
as
a
way
of
defining
it.
H
So
we
think
that
these
three
sections
maybe
approach
the
way
to
define
a
technology
separately,
but
in
aggregate
as
a
whole,
they
might
constitute
a
full
and
so
yeah
the
changes.
So
it's
in
its
what
third
version
now
yeah
I
mentioned
already
that
the
first,
the
first
revision
we
had
to
make
was
to
get
a
lot
more
specific
about
endpoint,
and
that
was
feedback
that
came
from
a
variety
of
places.
H
It
probably
still
needs
a
bit
more
work
and
then
the
last
one
that
I
uploaded
on
the
day
of
the
doc
freeze
was
a
few
edits
on
the
text,
which
are
really
greatly
appreciated.
We
also
were
talking
about
how
you
know
cryptography
or
cryptographers,
use
sort
of
functional
definitions
in
the
formal
definition,
so
that
is
there
now
it's
a
pointer
at
the
moment.
So
it's
it's
sort
of
short
and
summarized
text
that
points
to
work
that
chelsea's
doing
on
them.
H
It
elaborates
a
lot
more
and
I
I
think
that's
actually.
Okay,
I
think
maybe
one
of
the
functions
of
this
draft
is
to
try
to
pull
in
what
we
think
are
really
good
attempts
at
definitions
to
sort
of
catalog
those
and
to
point
to
them,
and
then
the
last
thing
again
yeah.
We
tried
to
further
break
out
what
constitutes
an
end
by
also
linking
it
to
identity,
which
could
be
a
really
useful
thing
also
for
the
architecture
of
group
chats
given
how
those
are
those
the
protocol
works
for
those.
H
So
this
is
where
we're
going
with
it.
We
want
to
incorporate
more
feedback
in
some
of
the
list
traffic,
so
I
appreciate
we've.
There
been
some
really
deep
reviews.
I
don't
I
don't
I'm
not
satisfied
that
we've
addressed
all
of
those,
but
we've
documented
them
as
best
we
can
in
the
github
issue
tracker.
I
think
we
probably
need
in
the
second
section
that
goes
through
the
features
and
requirements
to
give
more
thorough
definitions.
I
know
that
sophia
is
one
thing
that
she's
she's
worked
on.
H
H
But
the
idea
that
a
best
practice
in
designing
into
endocrine
system
is
to
try
to
reduce
that
and
how
to
sort
of
explain
in
a
definitional
sense
that
trajectory,
because
if
we,
you
know
again
like
trying
to
think
of
the
possible
threats
to
indian
encrypted
systems,
one
of
those
is
like
enhancing
metadata,
and
so
we
just,
I
think,
want
to
figure
out
how
we
can
basically
say
that
you
know
metadata
reduction
is
like
compatible
with
you
know:
secure
intent,
group
systems
and
then
yeah
we'd
like
to
add
in
more
ideas,
more
features
such
as
like
forward
secrecy
and
backwards
security.
H
So
to
the
dispatch
question,
like
I
said,
we've
been
talking
about
this
in
mls
at
the
last
interim
folks
seemed
receptive
to
it
and
the
ways
that
we
were
sort
of
aligning
with
the
work
that
they're
already
doing
but
made
the
very
helpful
suggestion
that
we
should
come
to
sickness
batch
at
this
meeting
and
talk
about
if
it
shouldn't
be
elsewhere,
because
it
does
touch
on
potentially
other.
H
You
know
work
at
the
ietf,
so
there's
stuff
in
openpgp,
for
example
lamps
things
like
that
so
yeah,
I'm
curious
if
folks
want
to
weigh
in
on
that
and
your
thoughts
on
that.
So
that's
why
we're
here!
This
is
where
you
can
find
the
you
know,
issue
tracker
and
that
sort
of
thing,
so
I
think
I'm
going
to
stop
there,
but
I
would
like
to
just
before
we
go
on.
H
E
Yep,
so
it
looks
like
danielle
is
in
the
cube,
so
dkg
do
you
want
to
go
ahead.
I
Phil
was
ahead
of
me
in
the
queue,
but
I'm
happy
to
go
now,
so
I
this
is
definitely
relevant
as
out
of
mls.
I
said
in
the
chat
that
I've
been
struggling
with
this
with
some
of
the
work
I'm
doing
in
lamps
in
lamps.
I
I've
found
for
the
header
protection
work
that
we
actually
are
not
talking
about
end
in
encryption,
but
we're
talking
about
end-to-end
cryptographic
protections
just
because
we
do
care
also
about
things
like
signed,
only
messages
and
the
end-to-end
security
that
the
signed
messages
give
for
people
who
check
signatures.
I
I
I
I
recognize
that
that
alex
notes
said
end
to
end
secure
messaging,
which
may
also
mean
encryption,
but
anyway,
there's
a
bunch
of
different
ways
to
phrase
it,
and
I
don't
know
whether
the
goal
here
is
to
shift
generic
conversation
outside
of
the
ietf
or
to
shift
ietf
conversation,
but
yeah.
Just
it
is
definitely
relevant.
I
don't
know
where,
to
put
it.
H
If
I
could
just
respond
to
the
point
about
secure
messaging
or
whatever,
I
think
that's
that's
one
of
the
examples
of
internal
well
internal
to
the
technical
community
conflict
that
I
think
can
be
very
counterproductive,
because
if
I'm
a
user
and
I'm
trying
to
figure
out
what
is
better
for
my
privacy
and
security
and
my
confidential
communications
and
there's
two
sorts
of
ideas
out
there,
there's
one
that's
called
private
messaging
and
then
there's
another
one.
H
That's
called
end-to-end
encryption
and
potentially
depending
on
the
definitions,
depending
on
how
you
know
the
various
proposals
out
there
to
potentially
have
like
lawful
access
to
one
of
those
things
or
you
know
we
sort
of
compromise
on
one
of
them.
It's
going
to
be
hard
for
me
as
user
to
remember,
which
is
which
it's
going
to
be
hard
to
feel.
Like,
oh
yeah.
I
heard
that
you
know
this
app.
H
You
know,
does
this
thing
or
like
you
know
they
can
it's
it's
secure
but
like
they
can
actually
kind
of
get
access
if
they
need
to,
but
then
the
other
one
I
heard
about
like
is
really
really
secure.
I
mean
we
already
have
that
right.
We
already
have
an
ecosystem
where
users
aren't
always
secure,
like
aren't,
we
sure
about
the
security
they're
being
offered.
H
So
I
feel
like
I
really
appreciate
alex's
alex
effort,
but
I
think
that
trying
to
call
it
something
else
or
kind
of
trying
to
come
up
with
other
terminology
may
not
be
that
helpful.
I
think
we
should
try
to
stick
to
strengthening
the
definition
that
we're
already
sort
of
ubiquitously
using.
E
J
I
think
it
needs
to
go
to
a
working
group.
I
think
I
would
prefer
emma
lamp
over
mls
simply
because
slam
already
has
a
cross-section
sect,
multiple
working
group
products
in
its
scope,
rather
than
just
one.
J
The
other
point
I'd
like
to
make
is:
I
think
that
we
should
look
beyond
just
communication
security
and
also
look
at
data
at
rest,
security,
which
is
what
I've
been
focused
on
and
the
thing
is
you
know
in
the
preamble,
you,
you
said
you
can't
escrow
the
keys
and
be
end-to-end
secure.
Well,
actually,
if
you're
gonna
do
data
at
rest
security,
you
had
better
have
a
key
escrow
story,
or
else
if
the
user
loses
their
keys.
Well,
it's
a
ransomware
attack
on
themselves
and
so
yeah.
There's
a
lot
of
complexity.
J
It's
going
to
need
a
lot
of
discussion,
but
I
would
like
to
have
that
data
at
rest
in
scope
as
well,
because
that's
what
I
work.
K
H
I
think
that's
great.
I
think
that
that's
an
important
component
of
end
to
end,
even
if
we
were
talking
about
a
scenario
like
mls
or
encrypted
messaging
apps,
like
there's
a
storage
problem,
if
you
share
any
resources
whatsoever
in
those
group
chats
if
you,
if
you
do
have
like
key
recovery,
that
those
are
hard
problems
and
they're
sort
of
they've
been
like
the
hard
problems
of
encryption
have
informed
know
that
the
way
we
wrote
the
second
section
in
particular.
So
thanks
for
that.
A
You
so
I
I
would
kind
of
echo
what
stefan
was
saying
in
the
chat.
I
think
we
are
underestimating
how
much
work
it
would
be
to
sorry.
First,
I
should
preface
by
saying
I'm
speaking
as
an
individual
contributor
and
not
not
as
a
chair,
so
I
think
we
are
grossly
underestimating
how
much
work
that
would
it
would
be
if
we
want
to
make
it
like
more
general
definition
beyond
mls,
because
I
don't
think
users
are
always
the
end.
A
So
when
I
talk
like
to
a
server
one
of
the
end
points,
there
is
isn't
any
user
and
like
having
this
discussion
with
people
in
the
past,
like
we
don't
seem
to
have
any
sort
of
agreement
on
what
an
end
is
because
it
keeps
on
evolving
before
it
used
to
be
a
box
like
a
server.
Now
everything
is
virtualized.
It
you
used
to
be
virtual
machines
or
the
operating
system.
A
Then
it
used
to
be
the
apps
running
on
the
operating
system
and
we
never
seem
to
agree
even
within,
like
one
organization
or
our
colleagues,
that
what
what
the
end
point
ever
refers
to,
since
it
evolves
over
time.
So
either
we
keep
it
like
focused
on
mls,
where
the
ends
most
likely
are
are
some
users
and
not
involved
servers
and
then
even
with
servers,
things
get
more
complicated
because
there
might
be
cdns
on
the
path.
A
Is
the
end
point
the
cdn
or
is
the
end
point
the
origin
server
so
and
since
I
had
laid
the
ground
rules
of
also
recommending
where
to
do
this,
I
don't
think
lamps
or
mls
is
the
best
place
to
do
this.
I
would
rather
say
like
this
should
be
done
in
sag
and
when
the
document
is
mature
enough,
if
we
get
to
that
stage,
ask
one
of
our
ads
to
sponsor
it,
but
yeah
I'll
stop
here.
L
Thanks
for
pushing
this
by
the
way,
you're
still
sending
video
the
I
mean,
I
think
I
I
sent
a
review
which
of
course,
I
think
like
10
minutes
ago,
so
so
nobody's
had
a
chance
to
read.
I
mean
I
think
that
something
in
this
space
is
a
good
idea.
I
think
definitely
having
some
definitions.
Helpful
I
feel
like.
Maybe
this
is
maybe
this
has
a
bit
of
a
scope
problem.
I
think
you
know
it
seems
to
be
like.
There
are
two
kind
of
layers
here.
L
One
is
defining
like
what
end
n
means
is
a
conceptual
point
which
I
think
you
know
you
should
do
in
three
one
and
some
of
the
comments
earlier
and
then
it
started
trying
to
map
the
concept
to
end
to
end
onto
specific
application
settings.
So
I
mean
the
example
I
gave
is
you
know
like
when
I
read
my
gmail,
my
like
tls
connections
ended
encrypted
to
google,
but
the
email
was
not
and
then
encrypted
to
you
right,
and
so
I
think
you
know
it
sounds
to
me
like
you.
L
You
mostly
want
to
focus
on
like,
like
you're
trying
to
focus
on
on
this
mls
setting.
I
think
there's
an
adjacent
setting
as
people
pointed
out
and
in
terms
of
secure
messaging,
then
there's
some
like
less
adjacent
settings
like
you
know,
you
know,
like
channel
security,
you
know
even
further
electronic
coding.
You
know
something
like
that,
so
I
think
I
guess
what
I
would
suggest
is
try
to
like
you
know,
focus
on
maybe
like
maybe
can
we
like?
L
You
know
you
know
start
by
like
you
know,
trying
to
have
that
sort
of
like,
as
I
say,
this
is
a
301
definition
and
then
to
be
like
okay.
Now,
let's
like
actually
get
quite
concrete
and
map
it
on
to
under
messaging,
and
maybe
some
pieces
of
alex
document
can
be,
could
be
useful
there.
You
know,
unfortunately,
that
we
have
one
in
cfrg
and
one
here.
L
I
don't
mean
that
I
don't
mean
that,
like
they
were
each
like
being
done,
but
it's
weird:
the
presentations
aren't
like
overlapping
and
then
you
know.
If
that
makes
progress,
then
we
can
be
like
okay.
Well
now,
let's
try
to
solve,
like
you
know,
attack
on
these
other
ones.
So
I
think
that
would
be
maybe
helpful
in
terms
of
like
location.
You
know
sag
really
isn't
set
up
for
this
kind
of
work.
You
know,
frankly,
we
don't
really
have
like
a
place
for
this
kind
of
work.
L
Cfg
is
a
little
bit
the
closest,
but
also
not
quite
the
thing,
so
I'm
not
sure
what
to
suggest
I'm,
maybe
I'm
kind
of
hoping
I'm
not
going
to
keep
vamping
for
a
second
and
hope
that,
like
roman
or
our
ben
steps
in
and
actually
says
something
so
I
think
like
this
is
valuable,
but
we
don't
like
have
the
kind
of
like
structures
to
do
the
work.
H
C
Okay,
so
yeah
I
was
just
basically,
I
got
to
say
to
disagree
with
mode,
but
I'd
end
up
agreeing
with
eckerd.
I
think
there
is
a
definition
to
be
had
here.
It's
not
totally
ambiguous,
but
I
think
it
does
have
those
layers
that
becker
mentioned.
I
think
there
is
there's
like
a
general
abstract
layer
where
it's
about
kind
of
authorization
and
only
the
authorized
endpoints
being
part
of
the
transaction,
but
it
specializes
differently
when
you're
talking
about
like
the
the
https
connection,
gmail
or
the
the
email
transaction
so
yeah.
C
I
think
that
layered
approach
is
about
right
and
I
will
yield
the
floor
to
roman
to
to
talk
about
where
this
should
go.
M
Nice
segway
yeah
I've
been
waiting
for
all
the
folks
to
queue
up
with
the
mic
before
before.
Jumping
in
I,
I
think
what
we
want
this
document
to
be
really
determines
the
home.
If
we're
really
going
to
try
to
tie
it
to
something,
that's
a
little
closer
to
use
cases.
I
think
we
can
find
a
working
group.
M
I
mean
if
it's
messaging,
maybe
it's
lamps-
I
mean
maybe
it's
mls,
but
if
we
want
a
more
general
purpose
thing,
the
only
route,
I
think,
sadly,
is
an
80
kind
of
sponsored
thing
I
haven't,
you
know,
had
a
chance
to
really
talk
it
through
with
ben,
but
from
my
perspective,
to
be
able
to
get
to
ad
sponsor,
we
would
need
to
figure
out
the
shape
a
little
bit
better
to
make
sure
we're
bounding.
M
It
there's
definitely
good
things
kind
of
in
here,
but,
as
I
saw
future
work
and
everyone
talking
about
the
mic,
they're
all
great
ideas,
but
we
need
to.
We
need
a
cutoff
point
to
say:
you
know,
the
box
is
only
going
to
be
this
small
and
then
perhaps
we
didn't
need
additional
drafts
and
I
think
that
would
be
the
trick
we
would
need
to
ad
sponsor
or
to
make
the
decision
to
go
in
a
working
group.
H
Thank
you
all
for
your
feedback.
I
think
I
want
to
get
to
bin,
but
I
just
wanted
to
reiterate.
This
is
why
I
try
to
spend
a
lot
of
time
on
outcomes
like
what
we
want
from
this,
and
that
may
be
where
we
go
back
to
actually
make
deaf
make
decisions
about
scope
and
what
we're
trying
to
achieve
with
it
and
then
where
it
lands,
because
I
agree
it
shouldn't
get
too
big.
H
D
Yeah,
I
just
want
to
jump
in
to
basically
agree
with
roman.
You
know
there's
a
lot.
It
seems
like
there's
a
lot
more
discussion
left
to
figure
out
what
scope
we
actually
want.
There's
a
lot
of
good
topics
that
I
heard
in
the
presentation.
I
tend
to
agree
with
eckerd
that
the
document
as
it
currently
stands.
You
might
benefit
from
cutting
down
restructuring.
D
Something
like
that,
but
I
think
that
there's
definitely
need
to
be
more
discussion
before
we
can
try
to
adopt
this
or
think
about
a
working
group
like
if
we
were
going
to
say
we
were
going
to
try
and
make
a
working
group.
I
don't
think
we'd
know
what
the
working
of
charter
would
be.
So
it
seems
like
we.
We
need
to
figure
out
just
where
we're
going
to
do
the
continued
discussion
on
this
I'm
happy
to
make
a
new
mailing
list
for
this.
H
C
Yeah
go
ahead.
Yeah
the
new
mailing
list
idea
had
come
to
my
mind
as
well.
I
think
that
sounds
like
a
good
outcome
sounds
like
we
have
a
few
folks
here
who
are
interested
enough
to
sign
up
for
that
and
engage
in
that
discussion.
So
if
there
are
no
objections
that
I
think
we
could,
I
would
propose.
We
call
that
our
dispatch
outcome,
but
the
idea
that
you
know
once
things
get
refined
and
advanced
a
little
bit.
It
could
come
back
as
you
know,
something
to
run
through
a
working
group
or
ad.
C
F
E
And
if
you
want
to,
if
you
can
start,
we
are
going
to
run
short
on
time
from
all
of
this,
so
okay,
okay,.
F
Okay,
if
you
go
onto
the
next
slide,
so
this
is
being
used
heavily
within
the
intelligent
transport
industry,
both
within
the
us
as
a
a
primary
standard
and
internationally
as
a
in
several
other
countries
as
well.
It
is
related
to
an
international
standards
organization
or
iso
standard.
F
So
on
to
the
next
slide,
so
it
is
used
for
a
variety
of
field
devices,
some
of
which
are
sensitive
information,
such
as
signal
controllers
that
we,
you
know,
relate
to
safety
of
of
travel,
go
on
to
the
next
slide,
and
it
is
of
course
this
a
guidance
to
use
the
latest
security
standards.
F
That
guidance
currently
was
tls
1.2.
Obviously
we
wanted
to
update
that
to
1.3
and
that
breaks
rfc
6353,
it's
the
fingerprint
that
breaks
so
go
on
to
the
next
slide.
F
So
our
potential
solution
is,
we
can
either
migrate
to
an
alternative
protocol.
Some
certainly
have
suggested
that,
although
we've
had
that
discussion
within
the
transportation
industry,
there
is
strong
consensus
that
we
should
keep
using
snmp.
F
So
the
idea
is
then
to
update
rfc
6353,
that's
currently
not
being
addressed
in
the
ietf,
and
we
are
proposing
that
it
become
a
new
work
item
there
and
we're
certainly
interested
in
working
with
itf.
To
do
this,
we
recognize
we
could
develop
our
own
standard
to
do
that
same
thing,
but
it
makes
a
lot
more
sense
to
work
with
the
ietf
to
do
this.
So
that
is
our
proposal
on
to
the
next
slide.
F
F
And
next
slide,
so
the
the
quick
overview
of
the
changes
that
are
needed,
as
mentioned
before
this
is
all
driven
by
the
fact
that
the
1.3
update
uses
a
two
octet
cipher
suite,
rather
than
a
one
octet
hash
algorithm.
F
That
changes
the
fingerprint
algorithm
defined
by
rfc
6353
and
we're
proposing
to
update
that
there's
some
other
minor
clarifications
being
made
and
as
a
part
of
this
is
clarifying
that
authentication
and
privacy
will
always
be
provided
now,
because
that's
just
part
of
1.3
and
we
will
update
references
next
slide.
F
There
are
also
some
subjective
changes,
we're
prohibiting
the
use
of
zero
rtt
mode,
recommending
disabling
usm
mandating
some
previous
recommendations
and
some
other
subjective
kind
of
non-changes
of
we're
going
to
be
using
the
same
port
numbers
as
what
our
recommendation
is.
All
of
that
is,
of
course,
subject
to
discussions
in
a
working
group,
assuming
that
this
is
approved
as
an
ietf
work
item
next
slide.
F
F
And
the
other
question
that
really
is
at
play
is:
should
we
treat
this
as
a
complete
replacement
of
rfc
6353
or
simply
an
update
to
rfc
6353?
F
Most
of
the
document
now
is
actually
the
updated
mib
that
includes
the
rfc
fingerprint
update,
but
there's
still
another
eight
pages
or
so
of
of
other
details.
So
that
is
the
presentation
and
I'm
happy
to
hear
comments
and
what
people's
thoughts
are.
E
Thank
you
eric
miss
first
and
q.
L
So
I
I
think
this
like
seems
like,
like
generally
important
work
and
obviously
I
think
that,
like
if
we're
gonna
update
a
standard
track
document,
you
should
have
another
standard
track
document.
Probably
you
are
gonna
need
some
kind
of
working
group
unless,
like
there's
like,
I
don't
think,
there's
like
an
existing
like
snmp
group
like
hanging
around
anymore,
but
it
should
be
relatively
modest.
I
I
do
want
to
like.
L
I
don't
want
to
get
too
far
in
technical
details,
but
you
lost
me
a
little
bit
in
the
fingerprint
thing
because
they're
there
in
in
1.2,
also
the
I
mean
and
things
were
complicated
but
but
but
the
the
hash
algorithms
were
sort
of
identified,
I'm
in
the
cipher
suite
as
part
of
the
cypher
suite,
and
there
was
a
separate
identifier
for
the
signature,
algorithms
and
that's
the
same
thing
here
too,
except
we
just
didn't
decouple
the
hash
and
the
signature.
L
N
I
agree
with
ecker:
this
should
be
a
standard
track
document
somewhere.
It
should
be
a
complete
dock,
because
security
folks,
who
are
going
to
look
at
it,
probably
aren't
very
familiar
with
353.
So
don't
do
a
patch
or
a
diff
document
make
a
self-contained
full
thing
and
yeah.
I
don't
know
where
it
happens,
but
it
should
definitely
be
some
kind
of
working
group.
Thank
you.
E
M
Snmp
is
you
know
our
protocol?
We
really
should
maintain
it.
The
question
as
we're
seeing
in
the
chat
window
is
where
is
there
the
remaining
body
of
knowledge
on
snmp,
because
we
can
bring
the
tls
expertise
to
them
and
if
folks
have
ideas
on
where
that
is
kind
of
we're
all
ears,
I
mean
my
gut
reaction
in
talking
with
ben
was
well.
Yuda
is
the
place
where
we
do
protocol
updates
that
can
that
can
patch?
You
know
that
can
patch
tls
on
top
of
it,
but
it's
not
clear
that
there's
snmp
experience
there.
C
Yeah
uta
seemed
like
a
pretty
plausible
point
to
me.
The
other
alternative
that
came
to
my
mind,
was
just
forming
a
small
focus
working
group.
Just
for
this,
I
it
doesn't
seem
like
this
probably
has
a
whole
lot
of
overlap
with
other
work
in
uta,
which
I
think
might
guide
against
that.
But
I
don't
think
this
is
a
real
I
I
agree
this
seems
like
work.
It
should
be
done
either
in.
I
think
uta
seems
like
a
fine
suggestion
for
an
existing
working
group
or
in
a
small,
focused
working
group.
D
Yes,
so
I
think
that
the
it's
a
little
unfortunate
that
we
have
this
combination
of
sort
of
needing
to
update
to
be
talented,
not
three
compatible
and
then
also
having
other
changes.
We
want
to
make
that
are
more
specific
to
snmp3
if
it
was
just
the
tls
103
updates
that
I
think
would
be
quite
straightforward
and
find
people
to
review
that
very
easily
and
it's
the
addition
of
the
other
snmp
stuff
that
would
make
this
a
little
bit
more
challenging
and
so
on
the
whole.
D
M
Maybe
what
we
do
is
we
take
this
offline
talk
with
some
of
our
ad
peers
to
say
you
know,
maybe
they
can
kind
of
help
us
and
we
could
bring
the
tls
expertise
if
needed,
and
if
that
doesn't
turn
out
to
be
an
option,
we
would
suggest
a
small,
focused
working
group.
C
That
sounds
like
a
pretty
good
plan
to
me.
Are
there
just
sectors
best
chairs
or
ideas,
have
thoughts
on
that
or
folks
from
the
floor.
A
I
guess
we'll
dispatch
it
somewhere,
but
we
are
not
sure
yet
where
so,
maybe
that's
the
conclusion
from
this
discussion.
C
M
C
C
All
right
next
up,
I
think
we
have
jerome
on
opportunistic
wireless
encryption.
A
E
A
A
I
think
we
can
move
to
the
next
presentation.
I
don't
now
you're
always
in
there.
A
Yeah,
do
you
want
to
share
your
screen
and
present.
O
Almost
so
thank
you
for
for
giving
us
the
opportunity
to
present
this
I'll.
I
will
not
turn
on
my.
I
can
maybe
try
to
turn
on
my
cameras
if
I
do
not
destroy
too
much
the
experience
all
right,
so
this
draft
that
we
posted
is
about
owe
so
autobio
is
opportunistic
wireless
encryption
and
that
was
defined
in
sag
in
rfc
8110,
so
that
was
back
in
2017.
O
There
was
a
completion
of
the
draft
it
went
on,
I
think,
for
two
and
a
half
years.
So
what
the
draft
was,
what
the
the
document
was
about
was
to
provide
an
encryption
mechanism
for
unauthenticated
wi-fi,
so
you
know
back
then
you
imagine
you
go
to
a
mom
and
pop
shop.
O
You
either
have
the
choice
to
have
your
you
know,
pre-shared
key,
which
is
highly
insecure,
because
everybody
has
it
it's
on
a
post-it
note
in
the,
in
the
view
of
everybody,
more
complex
methods
like
hotspot
2.08,
when
you
were
too
complicated
1x
all
these
things
were
way
too
complicated.
So
people
resorted
to
nothing
and
nothing
was
not
really.
G
O
So
what
rca
110
is
describe
a
mode
by
which
there
is
a
difficult
man,
key
exchange
between
the
clients
and
the
access
point,
which
allows
the
two
to
create
a
secure
connection
by
which
you
know
they
can
protect
their
communication
from
view,
so
that
was
an
rfc
8110.
It
was
you
know,
defined
here
in
the
ietf
and
then,
of
course,
it
was
using
some
mechanism
from
the
ieee
8
to
11
working
group,
in
particular
the
key
exchange
beyond
the
initial
association,
etc.
O
O
That
draft
was
in
fact,
very
successful,
because
rfc
8110,
once
adopted,
became
part
of
a
larger
structure
in
the
wi-fi
alliance,
which
is
lpav3,
and
we
see
that
this
standard
is
going
to
become
very
common,
including
in
places
where
you
have
more
than
one
access
point
now
we're
thinking
here
you
know
small
shopping,
mall,
small
airports,
you
know
places
where
you
may
have.
Maybe
five
10,
maybe
20
access
points
where
they
go
into
the
same
id
where
they
say
we
don't
want
a
pre-shared
key.
We
don't
want
hotspot
too
complicated.
O
We
don't
want
the
one
x,
of
course,
so
we're
going
to
do
open
and
some
of
of
them
do
today.
If
you
went
through
places
like
san
jose
in
california,
airports.
You've
seen
you
know,
open
type
of
network
which
you
know
is
highly
insecure,
but
in
in
wi-fi
in
a2011
that
same
problem
happens,
and
there
was
a
solution
that
was
found
a
while
back
back
in
the
early
days
of
wi-fi
as
well.
O
The
communication
was
only
thought
between
an
access
point
and
a
client,
but
then
in
2008
the
8011
group
defined
what
was
called
you
know.
The
amendment
8
11
r
also
called
11
r
or
fast
transition
ft
for
for
the
friends
and
that
augments
eight
eleven
in
a
few
ways.
One
of
them
is
that
access
points
can
communicate
in
the
background
of
what
we
call
the
distribution
system,
the
ds
and
share
a
common
domain
name.
O
So
now
the
access
points
can
advertise
that
they
have
all
that
same
domain
name
and
then
the
station
knows
that
all
these
aps
communicate
in
the
background
and
then,
instead
of
having
a
secure
negotiation
with
one
ap
at
a
time
what
ft
does
is,
allow
you
to
have
a
sort
of
hierarchy,
constructor
where
you
have
a
main
pre-shared
key
pmk,
sorry
that
is
no
generic
to
the
ensemble,
that
we
call
pm
r0
and
there
is
a
key
which
is
specific
to
each
access
point
and
what
ft
defines
is
a
way
for
that
mechanism
to
be
enhanced
so
that
when
you
move
from
one
ap
to
the
other,
you
don't
have
to
renegotiate
everything
from
scratch.
O
O
So
that
mechanism
allows
you
to
pre-negotiate
these
keys,
while
you're
c
associated
to
the
access
points
you
first
joined
and
the
way
that
works
is
twofold.
You
can
either
go
through
that
old,
ap
and
say:
hey,
I'm
detecting
ap
number
two.
Can
you
connect
me
with
that
ap,
so
I
can
negotiate
key
without
ap
or
you
can
go
directly
to
that.
Ap
number
two
and
say:
hey.
You
know
I'm
having
this
pm
key
r0
and
I'm
coming
from
ap1.
O
Can
you
please,
you
know,
use
the
background
communication
to
establish
a
preset
key
with
me
and
you
do
all
that,
while
you're
still
connecting
and
associated
to
the
first
ap
and
then
as
soon
as
you
need
to
move
rapidly
to
the
next
ap,
you
have
already
the
key
established.
So
you
can.
You
know,
roam
faster,
however,
that
mechanism
that
ft
defined
in
2008
applies
to
the
80
to
the
11
mode.
It
does
not
apply
to
other
ue,
and
that
is
because
awe
was
defined
here
at
the
itf.
O
However,
we
see
that,
with
the
expansion
of
ode
adoption
in
places
where
there
are
more
than
one
ap,
we
also
see
more
and
more
use
cases
where
people
will
have
to
want
to
have
a
secure
association
to
modern
one
ap
as
they
move,
and
there
are,
you
know,
multiple
use
cases
and
in
the
beginning
of
the
draft,
you'll
see
a
few
of
those.
You
know
you
do
ranging
you
want
us
arranging
to
be
secure,
there's
a
new
standard
which
allows
you
to
look
for
a
broadcast
video.
O
You
want
that
communication
to
be
secure,
etc.
So
there
are
plenty
of
use
cases
where
you
will
want
this
protection
mechanism.
Excuse
me
without
necessarily
wasting
time
between
access
point,
so
our
proposal
is
to
expand
rfc
8110
by
adding
a
layer
of
fast
transition
of
11r,
so
to
speak
on
it.
O
The
draft
loop
proposes
that
essentially,
the
process
is
that
the
choreography
that
was
defined
in
rfc8110
with
the
supre
connection
at
association
phase,
where
you
have
this
a
public
key
exchange,
will
still
look
the
same,
but
we
would
add
a
sort
of
structure
on
top
of
which
we'll
have
these
ft
topics.
You
know
this
domain
name
structure,
this
hierarchy
called
name
of
of
keys
so
that
you
can
negotiate
an
auto
ue
security
between
one
ap
and
also
one
station
and
multiple
aps
and
therefore
have
this
too
fast
roaming.
O
So
the
question
is:
where
do
we
define
that
stuff?
It's
very
much
8.11,
so
we
thought
of
going
to
a2.11,
but
again,
lwe
does
not
define
over
there.
So
you
know
there
are
all
the
mechanisms
over
there,
but
not
auto
ue.
O
There
is
also
the
wi-fi
alliance
where,
although
he
is
strongly
adopted,
but
again,
their
idea
is
that
although
he
is
defined
as
the
itf,
so
we
we
came
to
you
guys
to
have
your
your
view
and
see
if
you
think
that
the
itf
would
be
a
good
vehicle
to
define
this
extension
of
rfc
to
add
this
ft
a
layer.
C
I
I'd
like
to
just
pick
up
on
that
that
point
you
raised
last
is
kind
of
why
I
I'd
be
interested
to
know
why
folks
think
this
is
ietf
or
clearly
we
did
8110.
This
is
an
ietf
published
document,
but
it's
not
looking
at
that
document.
It's
not
clear
to
me
why
that
was
done
in
the
ietf,
so
I
this
seems
more
much
more
naturally
than
I
either
I
triple
e
or
wi-fi
alliance.
C
Both
of
those
organizations
can
obviously
cross-reference
to
ietf
stuff,
so
it
doesn't
seem
to
me
like
this
requires
obviously
kind
of
internet
expertise
that
the
itf
is
really
core
at.
So
I'm,
maybe
maybe
I
see
dan
next
in
the
queue.
So
maybe
you
can
shed
some
light
on
how
8110
got.
P
Yeah,
okay,
thanks
so
810
was
done
in
the
itf
because
I
tried
to
do
it
in
dot
11,
but
some
people
are
kind
of
persnickety
and
they
objected
to
the
unauthenticated
nature
of
of
owe.
That
said,
I
I
think
it.
You
really
should
at
least
try
to
to
get
it
pushed
through
11,
that's
really
the
the
natural
home.
For
this.
P
G
O
And
unfortunately,
a2
11
has
another
mechanism
which
is
called
asm
pasn
and
the
feedback
we
got
was:
why
would
we
define
an
ieee
something
that
was
defined
in
the
itf?
Well,
we
have
an
ipoleo
mechanism
which
is
not
the
same,
but
can
pretty
much
maybe
do
the
same
job.
O
L
Yeah
hi,
I
share
with
you
concerns
here
I
mean
it
seems
like
like.
I
understand
that
we
have
8110,
but
it's
not
like
a
standard
document.
It
was
just
it
is
sponsored
and
like,
and
what
you're
telling
me
actually
is
right.
They
were
telling
me
like.
I
is
like
we
have
those
things,
so
we
don't
want
to
do.
Yours,
like
that's,
really,
not
a
good
reason
to
do
things
at
itf.
It's
like
quite
the
opposite
of
their
batteries
into
things
itf,
and
I
don't.
I
don't
really
think
a110
is
presidential.
L
So,
like
I
mean
you
know,
and
in
particular
I
feel
like
extraordinarily
ill-equipped
at
this
moment
to
determine
whether
or
not
in
fact
like
the
stuff
that
I
typically
has
is
satisfactory,
in
which
case
like
this
work
should
not
be
done
or
have
unsatisfactory,
which
case,
like
maybe
struck
how
this
work
gets
done
so,
like,
I
think,
absolutely
some
like
liaison
from
like
ieee
like
it
was
like.
L
We
think
this
is
just
fine,
but
we
don't
want
to
do
it
like
I
I
I
I
I
I'm
quite
concerned
this
is
working
at
itf
and
I
certainly
don't
think-
and
I
guess
you
know
whether
you
may
agree
with
me,
but
like
I'm,
not
enthusiastic
about
us
publishing
like
new
security
protocols
like
the
basis
of
80
sponsorship,
especially
when
there's
a
far
out
of
our
orbit
so
yeah.
I
think
I
I
guess
I
I
think
this
week.
L
This
needs
to
be
dispatched
in
some
way
other
than
like
workers
are
gonna.
Do
it.
You
know,
I
think,
if
you,
if
you
do
wanna,
pursue
this
at
itf,
like
you
know,
the
first
step
would
really
be
to
have
like
something
that
somebody
is
on
from
I
triple
a
like.
Perhaps
ib
can
manage
to
like
establish
that
this
is
not
just
duplicative
work
and
then
you'd
have
like
make
a
case
for
there
to
be
a
working
group.
Otherwise
I
think
they
should
not
like
before.
E
B
So
my
position
is
precipitation
and
models
after
the
ones.
A
Bob
bob
you're
very
choppy,
we
barely
understand
anything.
The
audio
is
very
choppy.
K
A
E
M
Roman
hi,
so
I
understand
the
precedence,
the
precedent
of
how
this
was
kind
of
80
sponsored,
but
you
know,
based
on
the
conversation
we
had
and
the
fact
that
we
do
have
a
liaison.
I
would
really
be
interested
in
at
least
going
through
the
traps.
We
did
last
time
to
talk
to
ieee
and
you
know
we've
needed
kind
of
wi-fi
lines
to
double
check.
What
makes
sense
here
and
assuming
we
get
the
all
clear
they
say
it's
not
a
do.
M
C
All
right,
so
it
sounds
like
we
can
kind
of
consider
this
dispatched
outside
the
ietf
for
the
moment,
and
if
we
clear
that
out
then
then
maybe
we
can
reconsider
it.
M
M
C
M
Question
I
I
don't
have
the
page
in
front
of
me.
I
feel
like
no
but
we'll
the
ieb
will
help
us
here.
We
do
not.
A
Next
up,
we
have
renee
and
I
do
want
to
share
your
screen
and
start
your
presentation.
D
Q
Okay,
one
sec.
Sorry,
I
just
came
in
okay,
sure,
yes,
oh
and
this
one
I
think,
do
you
see
something
now.
A
Q
All
right
all
right
so
well,
thanks
for
giving
me
the
opportunity
to
present
this
one
sec,
I'll
just
yeah.
Let's
do
this,
so
this
is
about
trying
to
squeeze
more
performance
out
of
easy,
dsa
and
acdj,
of
course,
have
been
around
forever.
Q
So
I
just
want
to
highlight
this,
and
I
presented
this
in
march
at
the
last
itf
meeting
at
the
lamps
working
group
and
so
far.
I
think
they
have
not
included
in
the
new
next
charter,
but
I
think
it's
of
more
right
applicability.
Q
So
that's
why
I
thought
this
would
be
good
venue
for
this,
so
the
outline
is
I'd
like
to
discuss
signature
schemes
based
on
the
curve,
crypto
and,
as
you
all
know,
there's
two
schemes
that
are
now
being
used
in
itf
protocols,
mostly
easy
dsa,
which
I
think
is
almost
ubiquitous
and
ed
dsa,
which
came
around
roughly.
Q
I
think
three
four
years
ago
from
this
crg
effort,
so
I'll
try
to
compare
some
performance,
metrics
and
some
constraints
of
it
and
then
I'll
introduce
a
slight
tweak
of
it,
which
I
indicated
with
this
little
star
notion
that
allows
you
to
speed
up
the
verification
operation
and
so
that's
item
number
two
is
diving
into
a
little
bit
of
detail.
Why
does
it
work
and
how
do
we
actually
make
it
happen?
Q
And
the
interesting
thing
is
you
can
get
the
speed
up
without
changing
any
on
the
wire
formats?
It's
it
can
still
be
processed
by
a
device
that
doesn't
know
about
the
speed
ups
and
that's
why
I
think
it
would
be
of
interest
to
the
writer
community.
Q
So
let's
have
a
little
look
here
so
essentially
for
for
a
very
long
time,
there
has
been
only
one
scheme
in
town
based
on
electric
curves,
with
ecdsa
and
ecdj
is
using
a
hash
function,
an
elliptic
curve
in
so-called
short
wire
class
formats,
which
has
been
widely
standardized
by
nist
by
bsi
and
other
groups
and
nc
and,
as
we
all
know,
it
has
a
signature
that
has,
if
it's
the
most
widely
used
curve.
Q
Q
So
so
this
is
ecdsa
and
then,
since
about,
I
think,
the
annual
2017.
We
also
have
e
d
dsa
and
if
we
just
go
down
like
to
the
second
part
of
the
screen,
we
see
again,
the
signature
is
like
two
components:
rms
similar
to
easy,
dsa,
there's
a
slight
difference,
and
that
is
that
the
second
component
is
exactly
the
same,
and
the
first
component
is
not
an
integer,
but
it's
a
circle,
compress
curve
point
and
in
ideas
it
has
been
only
found
in
terms
of
so
called
adverse
curves.
Q
So
I
have
on
the
next
slide.
I
just
have
some
comparison,
so
we
have
easy.
I
think
that's
probably
yeah.
It's
it's
probably
in
a
uses
mandatory
to
implement
if
you
use,
electrocurve,
based
arithmetic
for
like
98
of
the
protocols
and
edsa
is
at
least
as
huge
for
many
applications,
and
it
has
some
advantages
in
terms
of
speed
and
you'll.
Q
See
that
at
the
signing
operation
ecdsa
allows
you
to
create
a
signature
where
you
process
the
message
only
once
and
this
edd
is
a
you
have
to
process
it
twice
and
another
difference
is
that
with
ecdsa
you
can
create
your
so-called
thermal
signing
key
offline
before
you
have
received
the
message,
so
you
can
kind
of
catch
those
things
and
in
eddie
you
do
it
in
line
and
the
the
caveat
is
easy.
These
are.
Q
Is
you
need
some
kind
of
some
people
consider
to
be
a
little
bit
nasty
inversion
operation,
but
it
only
has
to
happen
once,
but
in
eddie
you
don't
have
to
do
that.
On
the
verification
side.
Q
I
think
it's
well
known
that
the
edva
allows
lots
of
speed
ups,
because
if
you
let's
say
you
receive
20
signatures,
you
can
receive
them
all.
You
can
verify
them
all
at
once
by
essentially
solving
a
linear
equation,
and
then
ecd
is
a
as
supposedly
that's
not
known
to
be
true,
because
the
the
the
format
doesn't
allow
you
to
dip
it
into
this
shape.
Q
Q
So
if
you,
if
you
look
at
the
difference
between
these
two
schemes,
if
you
find,
apart
from
you,
know
different
curves
that
you
can
plug
into
it,
you
find
on
the
wire
format,
there's
a
slight
difference.
So
you
see
you
have
a
signature
that
is
two
components:
r
and
s
which
are
both
integers
in
the
ecdj
case
and
in
the
eddj
case
you
have
an
elliptic
curve
point
and
a
sigma
2
component,
and
ideally
you
would
like
to
make
sure
that
verification
would
also
be
able
to
reap
similar
benefits,
as
ed
dsa
has.
Q
So
it's
a
slight
tweak
of
a
where,
instead
of
the
first
component
of
the
signature
at
this
small
r,
you
send
a
compressed
elliptic
curve
point
and
if
you
look
under
the
hood,
he
will
find
out
that
verification
actually
is
now
allows
all
the
tricks
that
you
can
apply
with
edd
and,
as
you
probably
saw
from
the
previous
slide
I'll
just
jump
back
to
it.
Q
It's
at
no
speed
up
possible
with
easy
dj
and
now
here.
If
you
look
at
the
third
column,
you
can
suddenly
speed
up
signal,
verifications
and
bad
verifications
and
actually
I'll
put
it
down
also
on
the
last
slide.
But
the
speed
up
for
signal
verification
has
been
around
for
at
least
16
and
a
half
years
and
for
bad
verification
has
been
known
since
1994,
but
for
whatever
reason
it
has
never
really
caught
on
too
much
in
in
the
wider
community,
and
I
think
it's.
Q
Q
So,
instead
of
having
a
signature,
that
is
a
pair
of
integers,
you
have
a
signature
that
is
elliptic
curve
point
and
a
signature
component
s
here,
and
the
verification
operation
is
slightly
different.
But
the
interesting
thing
is
that
both
signatures
are
valid
under
exactly
the
same
condition,
so
you
don't
lose
or
gain
any
security
by
moving
from
one
version
to
the
other
and
all
the
speed
ups
and
they're,
really
quite
considerable.
So
for
a
single
verification,
you
get
about
a
thirty
percent
increase
speed.
Q
If
you
have
the
second
version,
this
little
star
updation,
and
if
you
have
enough
signatures
that
you
have
to
verify
at
once,
for
example,
a
significant
chain,
then
you
can
get
the
speed
up
of
about
factor.
Six
and
all
these
speed
ups
are
based
on
essentially
some
algebraic
operations
that
allow
you
to
identify
common
terms
and.
Q
Put
some
scalars
in
get
them
in
the
right
form,
and
you
can
also
centralize
some
so-called
ecg
doubling
operations
instead
of
having
that
to
carry
them
out
individually
for
each
signature,
you
can
just
do
it
to
add
launch
and
that's
actually
the
background
for
this
speed
up
and
the
only
difference.
The
only
caveat
here
is
like
how
do
you
actually
make
this
work
in
and
how
do
you
make
it
work
while
still
not
using
introducing
in
our
signature
scheme,
and
that
is
based
on
the
following.
Q
So
in
ecdsa
the
this
signal
component
r
is
the
x-coordinate
of
an
ephemeral
signing
key
and
in
order
in
order
to
reap
all
these
benefits
of
speedups.
You
have
to
be
able
to
reverse
that
operation
and,
in
general,
that's
that's
not
really
possible,
because
there's
always
two
solutions,
a
point
and
the
negative
of
the
point.
Q
But
ecdj
has
a
very
nice
property
either
at
at
one
time
it
had
been
considered
as
a
disadvantage,
but
it's
it's
called
malleability
and
that's
that
is
you
can
change
the
signature
so
that
you
can
predict
the
y-coordinate
of
this
ephemeral
signing
key
and
once
you
can
do
that,
you
get
a
one-to-one
correspondence
between
the
signature
component
and
the
thermal
signing
key
and
essentially
you're
in
the
edva
situation.
Q
So
that's
in
the
green
box,
so
the
recipe
that
I
would
like
to
advocate
moving
forward
is
we
just
keep
generating
easy
dj
signatures,
as
we
have
been
doing
for
the
last
25
years,
and
if
you
want
to
reap
some
of
these
benefits,
we
want
to
make
sure
that.
Q
So
by
doing
that,
you
can
put
signatures
always
in
the
form
where,
let's
say
the
y-coordinate
always
has
even
parity,
so
it
ends
with
a
zero
bit
and
any
anybody
can
do
that.
So
it
doesn't
have
to
be
designer,
for
example,
if
you've
got
a
certificate
and
was
signed
by,
let's
say
verisign
or
digital
or
whatever
you
don't
have
to
go
back
to
them,
get
our
certificate
generated.
You
can
do
it
yourself,
because
this
property
is
independent
of
designer.
Q
And
so
remember
that
this
really
had
the
performance
at
pharmacies
for
the
verification
side.
The
question
is
like:
how
do
you
actually
get
there
and
there's
various
ways
of
doing
that?
So
one
of
them
is
you
look
at
the
whole
universe
of
each
dj
signatures
that
has
been
generated
since
25
years
ago.
Q
Q
That
is
step
two
from
the
previous
slide,
so
you
can
essentially
put
the
whole
universe
of
existing
deployments
in
the
proper
shape
and
from
that
moment
say,
oh
I'll
just
introduce
generate
them
only
that
way
and
then
any
device
that
wishes
to
implement
speed
ups.
They
can
do
so
and
they
don't
have
any
uncertainty,
whether
they
that
particular
format
was
already
there.
So
that's
what
they
call
the
big
bang
approach
and,
depending
on
the
the
specification,
so
there's
some
specifications
that
are
still
evolving
and
there's
no
deployment.
Q
Q
And
so
the
interesting
thing
is
really
that
it
doesn't
really
impact
existing
verifiers.
So
that's
service
option
three.
So
if
we
we
can
also
introduce
a
new
label
for
this
this
variant
and
that
all
essentially
it
always
flags
that
it
has
been
generated,
innovative
that
fosters
speedy
verifications.
Q
Q
So
I
gave
an
example
here
with
pkx
volume
is
open,
pgp
and
openpgp
is
still
an
existing
craft,
for
example,
and
another
one
is
the
so-called
lake
protocol
and
essentially
just
introducing
new
label
for
this
verification.
Friendly
formatting
would
be
enough.
So
in
the
first
case,
it's
as
stated
because
they're
called
the
ecdsa
star,
which
sha-256,
if
would
be,
let's
say
the
p256
curve,
and
then
you,
you
can
add
some
language
also
what
happens
to
devices
that
don't
understand
this
particular
new
label?
Q
And
that's
in
the
draft
that
I
submitted
two
weeks
ago
in
open
pgp.
You
can
just
add
this
ecdz
version
as
a
suite
in
a
particular
table.
So
that's
what's
listed
here
and
a
half
half
the
page
in,
for
example,
the
lake
protocol
ad
hoc.
Q
You
can
just
stipulate
that
you
will
always
generate
the
easy
thesis
in
this
particular
base.
So
the
only
thing
you
really
do
is,
if
you
just
go
back
to
slide
number
eight,
is
that
you,
you
flip
the
second
signature
component
and
make
it
plus
or
minus
this
component
s
depending
on
the
parity
of
the
y,
coordinates
of
thermal
key.
Q
So
it
doesn't
really
have
any
real
impact
on
the
computational
complexity,
but
obviously
it
requires
a
little
bit
of
work
if
you
would
implement
it
such
way
that
that
that
bit
would
not
be
rightly
available.
C
Q
Yes,
so
I'm
on
the
last
slide
already,
but
thank
you
so
so
this
trick
has
been
has
been
used
for
about
a
decade
in
vehicular
applications,
so
that
the
61609
protocol,
but
it
could
easily
be
used
far
more
widely
and
that's
why
I
would.
I
think
it
would
be
a
good
idea
to
consider
it
and
devices
they.
The
important
thing
is
devices:
don't
have
to
implement
this
particular
speed
up.
Q
So
if,
for
whatever
reason
they
don't
want
to
do
it,
they
can
still
do
whatever
they
have
already
been
doing,
and
the
effort
required
in
in
implementing
this
in
in
iedf
terms
in
writing,
specifications
and
so
on.
This
should
be
pretty
quick,
because
the
main
the
main
requirement
is,
of
course,
to
to
kind
of
put
in
the
document
what
I
presented,
which
I
already
did
and
define
some
code
parts.
Q
K
J
Oh
yeah,
I
I
was
going
to
say
I
think
you
should
be
because
I
don't
think
that
folk
are
going
to
have
the
confidence
to
use
it
unless
you've
had
examination
there.
E
D
This
is
maybe
not
relevant
to
the
dispatch
question,
but
I
was
not
sure
I
understood
when
you're
doing
the
batch
verification
that
gets
a
speed
up
is
the
only
constraint
that
all
the
signatures
need
to
be
on
the
same
curve
and
using
ecdsa
star.
There's
no
requirement
on
the
same
sign
or
anything
like
that.
Q
Oh
well
yeah,
so
the
the
the
speed
up
of
a
factor-
six,
I
think
it's.
It
depends
a
little
bit
on
this,
this
platform,
of
course,
but
the
factor
six
speed
up
you
would
get
if
the
the
sign
would
be
the
same
for
a
bunch
of
signatures
and
if
the
sinus
would
be
different,
then
the
speeder
would
be
lower,
but
it
would
still
be
in
roughly
the
two
and
a
half
to
three
times:
speed
up
ballpark.
E
I
Hi
thanks
for
bringing
this
up,
I'm
just
this
is
daniel
gilmore,
I'm
one
of
the
co-chairs
of
the
open,
pgp
working
group.
We
are
working
on
the
crypto
refresh
draft.
As
you
know
there.
I
would
not
be
inclined
to
include
this
in
the
open,
pgp
working
group
without
an
endorsement
from
a
group
like
cfrg.
I
There
are
also
additional
sort
of
store
and
forward
questions
that
we
need
to
think
about,
for
you
know,
certificates
that
sign
using
mechanisms
that
other
people
might
not
be
able
to
interpret,
but
I
really
think
that
putting
this
into
some
place
like
cfrg,
first
to
establish
that
this
is
a
you
know.
This
is
a
sensible
approach.
Would
would
make
things
easier
for
groups
like
opengtp
to
adopt.
I
I
mean
I
haven't
looked
into
this
in
enough
detail
to
be
confident
that
I
understand
what
the
trade-offs
are
here
so
yeah
the
cfrg
would
be,
and
I
don't
know
who
else
in
the
open
pgp
working
group
would
have
looked
at
it
as
well,
but
a
review
from
the
cfrg
that
endorses
this
as
a
as
a
reasonable
approach
and
call
you
know
and
highlights
the
potential
implementation
problems
that
people
might
have.
I
That
would
be
useful
for
me
to
consider
you
know
to
consider
it
as
as
part
of
the
work
for
openpgp
yeah,
so
so
yeah
cfrg's
endorsement,
even
if
all
they're
saying
is
this
is
a
like.
This
is
a
reasonable
approach.
Don't
worry
about!
It
would
be
useful.
Q
I
I
mean
from
open,
pgp's
perspective.
Defining
a
code
point
is
easy,
but
figuring
out
how
to
get
deployed
is
much
harder
and
that's
that's,
maybe
outside
of
the
scope
of
the
itf.
But
you
know
introducing
new
signing
code
points
that
implementations
don't
have.
The
ability
to
verify
is
an
awkward
multi-year
process
for
open
bgp.
Q
Yeah
yeah
yeah.
I
think
that
came
up
in
the
last
discussion
in
march
and
if
you
will
actually
dig
into
the
draft
document,
there's
a
section
four
and
discusses
what
happens
with
devices
that
don't
know
a
new
label
yet
right,
the
new
oid
or
whatever.
It
is
right,
and
definitely
I
see
that
as
a
it
is
something
that
needs
to
be
taken
into
account
and
obviously
you
have
to
start
somewhere.
If
you
want
to
effectively
change
you,
you
first
have
to
get
the
mechanism
out
there
and
then
the
other
one
is.
Q
E
N
E
C
Richard
I'm
just
going
to
basically
plus
one
that
you
know
this
is
this
is
a
big
enough
change
that
as
a
dumb
implementer
requires
me
to
like
break
the
seal
on
my
cryptographic,
library
and
take
your
own
signatures
and
that's
kind
of
my
trigger
of
saying
it's
real
cryptographers
to
look
at
it
so
yeah
the
code
points
can
be
assigned
eventually,
but
I
think
before
this
actually
gets
any
uptake,
I
need
a
cfrg
review,
so
I
would
propose
that
we
we
dispatched
this.
C
Our
dispatch
outcome
here
for
dispatch
be
be
know
that
the
icf
is
not
going
to
work
on
this
for
now,
but
you
know,
I
think
this
would
make
a
fun
thing
to
propose
to
cfrg
or
even
the
independent
street.
M
Yeah
I
strongly
I
strongly
endorse
that
kind
of
position.
We
have
two
different
things
here.
We
have
some
code
point
assignments,
but
the
core
thing
is:
we
have
a
body
of
work,
we
probably
sent
to
the
crypto
review
panels,
that's
general
purpose
and
if
that's
the
threshold,
we
really
should
take
this
to
the
irbf,
and
then
we
can
at
a
later
point
figure
out
how
to
get
the
code
points
assigned
for
it.
So
we
have
the
confidence
in
the
approach
here.
M
Q
You
know,
since
I
submitted
that
here,
is
that
if
you
require
good
points,
the
irtf
usually
doesn't
assign
any
code
points
right.
So
it
becomes
two
efforts,
and
I
just
I
just
thought
that
it
would
be
nice
if
this
would
be
short
effort
where
obviously
it
requires
insights
from
the
cfg
and
the
ability
to
get
those
coach
points
out
of
the
door.
Essentially
right.
C
Yeah,
I
think
this
is
just
an
ordering
point
that
before
we,
when
we
assign
code
points,
we
want
them
to
be
on
well-vetted
things,
and
so
we
just,
I
think,
the
feedback
I'm
hearing
from
the
room
is.
This
needs
a
little
bit
more
vetting
before
we
go
to
go
to
that
step
of
assigning
your
code
points.
Sure.
A
Yes,
we
are
off
to
the
last
presentation
for
today.
Brett
do
you
want
to
share
your
screen
and
present
or.
G
G
So
thanks
for
giving
me
some
time
to
talk
today,
this
quick
presentation
will
be
about
jws,
clear
text,
json
signatures
or
you
could
you
know
rephrase
this
to
be
plain
text.
Json
signatures.
I
want
to
preface
this
with
our
original
intent
is
to
go
through
the
ise,
but
we
were
asked
to
present
this
at
dispatch.
G
We
did
that
this
morning
and
then
I
guess
we
were
also
put
on
the
agenda
today
insect
dispatch,
and
so
I'm
just
going
to
go
through
this
presentation,
but
our
original
request
was
to
go
through
ise
and
so
in
fact
I
know
that
was
a
lot
of
chatter
this
morning
in
dispatch.
So
I
thought
I
would
just
bring
that
up
right
up
front
so
from
the
abstract
standpoint.
G
G
You
know,
as
in
many
situations,
json
data
structures
are
really
well
defined
and
to
have
an
option
to
add
the
signature
without
packaging.
The
data
inside
the
signature
is
really
important
to
improve
backwards.
Compatibility
and
adoption
of
the
signed
data
there's
also
very
large.
Data
structures
in
json
format
that
are
shared
across
the
ecosystem
and
between
organizations
and
then
the
use
case
or
the
desire
is
to
be
able
to
sign
those
and
sign
them
actually
at
a
later
stage,
possibly
after
they've
been
shared,
so
they
would
be
sent
as
a
detached
signature.
G
They
could
also
be
attached
embedded
and
a
lot
of
the
examples
will
show
show
them
embedded
inside
the
json
data
itself,
but
this
is
really
designed,
so
they
could
be
signed
separately
and
then
adding
multiple
signatures
and
nested
data
structures.
You
know
in
different
combinations
is
significantly
easier
to
handle
when
the
signature
is
packaged
within
the
data
and
not
the
other
way
around,
and
then
you
know
wanting
to
be
able
to
do.
You
know
counter
signing
and
be
able
to
have
multiple
people
sign.
The
same
data
is
another
use
case.
G
Then,
if
needed
wanting,
you
know
to
transmit
unsigned
data.
It
is
easy
to
admit
the
signature
instead
of
creating
a
jws
package
and
then
using
the
none
algorithm
and
then
lastly,
it's
just
maintaining
json
data
as
it
is,
while
in
transport
and
makes
reading
readability
and
debugging
easier
and
is,
is
much
more
friendly
for
the
web
2.0
world.
So
the
constructs
and
the
way
this
would
work
so
in
traditional
jcs
and
rxe
8785.
G
You
know
you
have
your
readable
format
of
json
data
and
then
you
can.
You
create
a
canonical
version
of
that.
It's
still
100
valid
json.
It
is
limited
to
the
I
json
specification,
but
a
lot
of
implementations
of
json
actually
are
restricted
to
the
ijson
format,
which
is
a
separate
rfc,
so
classical
jws
signatures.
This
is
just
level
set
and
bring
everybody
up
to
speed.
You
know
the
first
part
of
it
is,
you
know,
they're
all
separated
by
dots.
So
the
first
part
is
the
header.
G
The
next
part
is
going
to
be
your
data
and
then
the
last
part
is
the
signature
and
it's
all
base64
encoded
and
so
and
then
the
detached
signature
in
normal
jws
land.
You
can
see
that
the
payload
is
missing
between
the
two
dots
so
the
way
we
propose
this
to
be
done
and-
and
I
would
like
to
see
this
done-
is
you
know
you
have
your
initial
json
object?
Obviously,
in
most
implementations,
these
objects
would
be
very,
very
large
and
contain
a
lot
of
properties.
G
G
G
You
know
you've
defined
all
those
extra
properties
and
you're
going
to
fetch
out
the
signature
property
string
that
was
included
in
that
property
you're,
going
to
remove
that
property
from
the
the
payload
of
the
json
data
and
then
you're
going
to
run
it
through
canonicalization
and
then
you'll
be
able
to
go
through
and
do
the
validation
and
then
you'll
be
able
to
see.
You
know
whether
or
not
the
digital
signature
is
valid
and
be
able
to
to
do
those
comparisons.
G
So,
like
I
mentioned
you
know,
we
don't
dictate
what
the
property
or
the
signature
after
attribute
is
or
where
it's
located.
That
would
really
be
up
to
the
ecosystem
and
trust
group
that
is
using
this.
You
know
there
were
some
people
this
morning
that
requested.
Well,
maybe
that
should
be
defined.
G
I
I
think
you
can
have
very
strong
use
cases
for
why
you
wouldn't,
but
while
you
you
know,
you'd
leave
it
up
to
the
organizations
and
and
entities
and
trust
groups
and
stuff
like
that
to
define
that
for
themselves
and
the
document
does
not
define
counter
signatures
or
or
arrays
of
signatures
or
tax
signatures,
but
it
it
exemplifies
on
how
it
could
be
done.
So
we
show
some
examples
of
ways
that
you
could
actually
create
an
array
of
signatures.
G
It
is
based
upon
json
canonical
scheme,
which
is
8785,
and
that
was
also
published
through
the
independent
stream,
and
then
the
jose
working
group
is
not
active
and
that
the
list
has
previous
previously
expressed.
You
know
limited
to
no
interest
in
in
doing
any
additional
work
there,
so
we
felt
like
that
would
probably
be
the
best
option
and
the
best
solution,
but,
like
I
said
we
were
asked
to
present
this
and
so
we're
trying
to
follow
all
the
process
and
follow
all
the
rules
and
get
everybody's
feedback.
G
And
so
you
know,
if
you
have
questions,
or
you
know,
opinions
about
this
or
if
you
you
know,
read
through
the
draft
and
you
have
ideas
for
other
things
or
you
know,
maybe
examples
that
we
didn't
illustrate
well
enough.
We'd
love
to
hear
from
that
or
hear
from
you
and
be
able
to
add
that
so
it
can
be.
You
know
the
best
quality
draft
that
we
can
produce.
C
Yeah
just
to
clear
up
one
process
point:
the
independent
stream
is
independent,
so
there's
process
wise
no
need
to
come
to
this
group.
I
I
you
know
the
ise
is
welcome
to
impose
whatever
borrowers
he
does,
but
I
think
you
should
feel
free
to
submit
to
him
to
the
ise
and
there's
no
need
for
dispatch
to
sign
off
on
that.
G
G
Was
my
interpretation
as
well?
We
were
asked
to
present
at
dispatch
and
then
it's
like
dispatching,
so
we
we
did
what
we
were
asked
to
do
so.
E
A
E
C
I
am
actually
here-
and
I
can
I
can
go
on
for
the
next
couple
minutes,
so
I
can
read
through
back
through
my
notes.
So,
let's
see
so
on
mallory's
draft.
C
I
think
we
came
to
the
conclusion
we're
going
to
form
a
new
mailing
list
and
have
some
discussion
there
to
refine
scoping
before
we
take
a
firm
action
on
it
on
the
ssnp
upgrade
to
tls
1.3,
the
ads
are
going
to
check
with
the
op
saves
and
see
if
there's
a
slot
for
it
in
some
community
that
knows
snmp
better,
to
which
we
can
add
some
tls
expertise,
so
that
has
been
dispatched
to
the
ads
to
figure
out
whether
this
goes
to
some
existing
thing
or
to
some
new
rookie
working
group
on
owe
we're
going
to
take
no
action
in
the
ietf.
C
The
leds
will
work
with
our
liaisons
to
ieee
and
wifi
alliance
to
figure
out
if
there's
a
home
over
there,
for
it
on
renee's
ecdsa
star
proposal.
We
are
also
not
going
to
take
any
action.
I
think
the
impression
we
got
from
several
folks
is
that
if
there
was
going
to
be
any
ietf
action,
such
as
codepoint
assignments,
we
would
need
cfrg
endorsement,
so
no
action
in
the
ietf
encouragement
to
submit
cfrg.
C
Finally,
on
the
jwt
playlist
signatures
or
embedded
signatures,
whatever
we're
going
to
call
it,
I
didn't
hear
any
objections
to
that
going
over
the
isc.
So
that's
what
I've
got
in
my
notes.
Any
last
comments.