►
From YouTube: IETF106-LAKE-20191120-1520
Description
LAKE meeting session at IETF106
2019/11/20 1520
https://datatracker.ietf.org/meeting/106/proceedings/
A
A
Anybody
want
to
bash
the
agenda
so
just
to
explain.
I.
Think
John's
presentation
is
probably
the
media
space,
and
here
it
comes
in
kind
of
two
parts:
he's
got
about
six
or
seven
slides
the
beginning,
just
kind
of
providing
context
and
background.
If
you
can
kind
of
just
keep
it
to
clarifying
questions
for
that
that'll
be
great
and
then
there's
one
slide.
That
says
this
question
just
before
we
get
there
we'll
do
a
home
to
see
if
the
people
in
the
room
would
like
to
adopt.
A
That
draft
confirm
the
list
obviously
later
and
then
we
can
go
on
and
discuss
the
details
of
the
requirements
and
comments.
People
have
on
them.
That's,
okay,
so
any
other
agenda,
bashing,
I,
think
Michael
Richardson
had
to
be
in
the
LMO
working
group,
so
militias
gonna
just
present
a
couple
slides.
He
gave
us
is
that
all
good,
in
that
case,
John.
B
B
Background
lake
is
about
specifying
a
lightweight
authentication
key
protocol
for
Oh
score
and
light
weight
is
really
the
important
thing
here.
If
we
don't
do
it
lightweight,
it
will
not
work
well
for
six
days
and
orowan,
and
then
we
have
failed
requirements
for
light
weight
is
following
what
is
comes
to
constrained
by
environments
defined
in
RFC,
72
8.
B
What
we
need
to
discuss
here
is
how
do
these
constraint
environment
apply
to
an
aka
and
especially
which
radio
technologies
which
type
of
devices?
So
this
is
not
in
news.
This
is
the
first
working
group
session,
but
it's
not
a
new
subject
and
has
been
discussed
in
ace.
It
has
been
discussed
in
six
dispatch
interim.
There
was
a
both
and
has
also
been
discussed
in
other
group,
for
example,
extension
a
in
six
thick
dish,
so
the
requirement
dropped.
We
have
added
a
lot
more
material
for
basically
the
different
required
areas
of
requirements.
B
B
Think
there
is
this
sixth
type
of
things
we
go
through
them.
There
will
not
be
a
much
lightweight,
is
very
important
to
radio
technology,
but
that
will
not
be
repeated
here.
So
first,
the
lake
is
an
key
exchange
for
off
score.
What
does
that
mean
means
that
it
needs
to
provide
what
horse
core
needs?
So
if
you
don't
know
that
Oscar
is
a
security
protocol
for
co-op,
Oscar
needs
a
master
secret
and
that
should
have
good
properties
oscar
already
have
he
exchanged
without
if
a
Hellman,
so
this
aka
should
provide
PFS.
B
C
B
D
B
B
E
B
B
There's
been
a
request
on
the
list
that
it
should
take
a
should
support,
different
public
key
credentials
for
different
endpoints
ie,
one
endpoint
authenticate
with
a
certificate
and
the
other
with
a
or
PK
I
think
it
was
Michael.
Richardson
has
also
come
up
in
discussion
earlier,
should
also
support
any
are
UT
ways
to
identify
these
credentials
this.
Yes,
this
list,
the
list
of
what
is
currently
available
in
ku
has
been
discussed
and
is
on
the
way
of
being
designed
for
kausi.
B
A
Kay
should
support,
shall
support
identity
protection
definitely
here
for
for
public
keys
late
with
different
protection
for
for
practical
reasons
for
the
initiator
and
the
sponsor,
it
would
be
good
if
they
gave
supported
identity.
Protection
for
PSK
is
come
with
a
lot
of
trade-offs,
so
it
might
not
be
worth
it
in
them
which
occur
pointed
out
on
the
list
today
and
I.
That
is
part
of
the
discussion
later
today.
D
This
is
honest.
I
was
wondering
about
one
aspect
that
came
up
in
CFR
Qi
not
too
long
ago,
namely
the
use
of
password
based
strong
as
a
authenticated
key
exchanges
which
people
they
are
also
proposed
as
a
need
for
IOT
environments
and
I
was
it
didn't,
came
up
in
at
least
and
I
thought
it
was
supposed
to
be
an
intentional
omission
or
I.
Don't.
B
B
F
Harkins
are
the
public
keys
in
these
certificates
and
the
trusted
are
PRK?
Are
they
like
a
certified,
diffie-hellman
key
or
certified
signature
key?
Do
you
can?
Well,
though,
well,
can
you
do
a
like
without
doing
a
DSA?
For
instance,
could
you
do
it
with
just
a
few
almonds,
yeah
I
think
so,
and
yeah.
G
F
B
F
B
B
H
B
B
More
crypto
properties,
compromise
of
the
long
term
keys
we
need
to
protect
against,
should
come
an
attacker
compromising
the
long
term
kiss
you
not
be
able
to
compromise
past
session
key
so-called
perfect
forward.
Secrecy
should
also
protect
against
passive
attacker,
compromising
future
keys.
It
should
be
forced
to
be
active.
At
least
they
ke
should
provide,
keep
compromised
impersonation.
So
if
you
take
the
initiators
key
issue,
no
cable
to
the
attacker
should
not
be
able
to
authenticate
the
responder
towards
the
initiator,
and
then
they
should
provide
about
against
miss
panty
attacks
and
reflection.
I
Okay,
this
is
a
little
nitpicky,
but
I
noticed
this
in
the
document
too,
and
I
should
have
commented
so
on.
The
selfie
attack
actually
had
two
variants
right.
One
was
a
straight
up,
reflection
attack
and
the
other
was
when
you
have
multiple
endpoints,
with
on
the
same
the
same
key
material.
You
know
they're
both
actors,
client
and
server
like
so
are
you
saying
both
or
just
one
only.
B
I
I
say
that
that's
what
I'm
saying
so,
the
on
the
the
something
paper
right
describes,
a
setting
in
which
you
have
two
settings
right,
one
in
which
you
are
reflected
back
to
yourself
and
then,
which
you
have
two
endpoints,
each
of
which
can
act
as
client
and
server
the
same
key
say
you
have
like
a
VPN
gateway.
That's
got
concert
across
two
to
two
boxes
right
and
so
on.
So
you're
right,
the
thief
or
the
reflection
attack.
You
can
stop
that
by
comparing
by
comparing
someone
that.
I
Of
the
not
only
random
values,
but
for
the
for
the
sir
crossing
attack
you
actually
have
to
have
as
far
as
I
understand
it
I'm
something
different,
because
you
can't
get
on
to
separate
out
the
key
material
client
server
and
not
let
people
act
simultaneously
anyway.
It's
like
we
talked
about
it,
but
like
it's
probably
worth
flushing
metal
bar
yeah.
E
So
I
was
actually
going
to
say
the
same
thing
as
I
could
said,
because
protecting
against
all
kinds
of
selfie
attacks,
you
would
need
some
kind
of
strong
identities,
and
maybe
it
might
be
worth
saying
that
we
are
protecting
against
this
specific
kind
of
selfie
attacks
and
we
are
only
considering
two-party
communication.
Even
though
two
parties
is
a
group
of
two.
E
J
B
The
next
type
of
requirement
is
on
application.
Data
there's
been
requirements,
put
perform
60s
among
others
to
transfer
application
data
in
the
protocol
for
exam,
for
example,
authorization
tokens.
This
could
also
be
transferred
outside
of
the
protocol,
but
transferring
them
in
this
protocol
give
benefits,
even
if
it's
not
protected
and
for
later
messages
it
might
be
protected.
So
example,
this
type
of
application
data
is
authorization,
information
that
has
PA
proof
of
possession
tokens
authorization.
Vultures
could
also
be
certificate.
Enrollment,
request
and
there's
been
requests
from
academia
to
have
the
strict
requirements
for
this.
B
I
It
sounds
like
you
have
some
discussions
later,
but
this
is
actually
quite
it
seems
like
quite
a
subtle
point
to
describe
is
a
key
requirement
is
right,
exactly
how
it
specially
bound
in
you
know,
cetera
right.
Is
it
like,
in
particular,
just
part
of
the
protocol
transcript
in
like,
as
a
so-so,
probably
have
to
like
really
define
I,
something
like
carrying?
It
is
easy.
It's
it's
carrying
a
safe
weight.
Sorry
yeah.
B
Then
light
weight,
light
weight
is
a
big
discussion
in
itself,
but
as
the
both
and
SEC
dispatch
interim
focused
very
heavily
on
lightweight
ready
protocols,
we
are
not
repeating
that,
as
now
main
things
that
may
be
main
highlights
of
what
life
it
should
mean
is
that
it
should
have
a
few
round
trips.
Few
messages,
if
you
increase
it
to
more
messages
it
takes
in
some
cases
it
increases
the
latency
significantly.
B
And
two
of
the
radio
technologies
that
has
as
a
need
for
a
lightweight
aks,
lauraball
and
66
Laura
Vaughn
has
very
small
frames,
and
then
it
also
depends.
What
kind
of
things
do
you
put
in
them,
except
the
vacay?
A
number
that
was
mentioned
for
Laura
one
was
54
bytes
for
payload
60
is
a
bit
more
complicated
than
the
amount
of
payload
depends
on
the
amount
of
hops
estimates
for
five
hopes
are
similar
to
Laura
bond
around
54
bytes,
but
that
decreases
for
each
hope.
You
want
to
support.
G
B
Yeah
so
54
bytes
is
not
the
lowest
Laura,
Boehm
I,
don't
know
if
it's
possible
to
support
11
there's.
These
are
just
example
of
constrain
right
away.
There
is
Laura
bond
can
be
even
more
constrained.
You
have
six
folks
that
have
eight
byte
there's,
probably
audio
radio
technologies
current
and
future.
That
will
also
be
more
or
less
constrained.
B
E
I
K
I
Basically
I
mean
if
you
look
at
the
details,
one
for
details,
one
to
design.
You
can
see
this
or
basically
on.
Basically
the
the
the
person
transmitted
last
rise
that
drives
right
drives.
The
transmission,
except
for,
like
I,
said
for
the
last
light,
which
is
just
a
tail
and
then
the
and
so
like,
and
then
the
thermistor
protocol,
the
server.
Basically,
the
server
basically
view
transmits
until
it
receives
the
until
receives
a
client's
message,
and
then
it
just
stops.
I
didn't
I,
didn't
say
it's
not
a
pain,
I'm.
I
Just
saying
you
don't
need
it
only
solicit
acts
right
so
I
mean
like
I
mean
I
mean
you
can
do
it
on
about
things
good
about
I'm,
just
as
possible.
I.
H
Think
you
know
in
this
requirements
talk
when
you
could
make
a
distinction
between
like
a
clear
round
trips
like
in
other
context,
I,
say
application
they're
round
trips
and
like
transport
round
trips,
like
I,
think
we
probably
agree
that,
like
one
and
a
half
hour,
TT
at
the
logical
ache
layer
is
probably
worth
welcome.
Sorry,
even
if
that
requires
more
machinery
underneath.
L
Well,
it
is
Elizabeth
just
worried
about
the
requirement
for
three
or
four
messages
in
IPSec
American
group
in
eye
coercion,
one.
We
had
three
messages,
exchanges
and
it
was
a
real
pain
because
the
retransmission
logic
was
to
be
switched
from
initiated
to
responder
for
the
first
message
and
for
I
question
two.
It
was
switched
for
the
logic
said:
all
the
exchanges
must
have
an
even
number
of
messages
for
unreliable
protocol.
It
simplifies
implementations,
a
lot
yeah.
B
M
This
motion,
mature
cutoff,
just
regarding
the
sixties,
requirement
what
you
said
about
three
pass.
We
discussed
essentially
that
it
would
be
more
preferable
to
sometimes
to
have
a
four
pass
protocol
if
it
wouldn't
require
fragmentation
than
a
three
pass
protocol,
and
one
message
would
get
fragmented
into
into
two
frames.
B
The
last
slide
on
a
gave
frequency.
How
often
is
the
aka
going
to
run,
which
was
a
discussion
topic
on
the
list?
I,
don't
remember
who
raised
the
question,
but
that's
a
good
question.
I
think
it's
hard
to
give
an
exact
answer
for
all
devices
in
use
cases
for,
for
the
most
extreme
use
cases
running
a
defilement
is
probably
to
have
a
in
the
B
to
start
with.
They
are
out
of
scope
for
Lake.
As
far
as
I
see
it,
then
you
can
use
score
without
a
K.
B
D
Thomas
had
this
an
exam
I
mentioned
that
before,
specifically,
if
you
care
about
efficiency
and,
for
example,
taking
the
issue
of
the
recovery
and
how
often
you
run
into
inter
count
is
obviously
important.
So,
for
example,
devices
that
don't
have
persistent
storage
is
often
very
difficult,
because
where
does
the
code
actually
reside
right?
That's
hopefully
on
a
persistent
storage.
D
It
doesn't
get
sucked
in
from
from
the
network,
and
also
this
when
you
think
about
the
impact,
the
key
compromise
and
that's
those
recommendations
where
and
you
don't
mention
them
explicitly
here,
but
which
one
you
mean,
but
they
often
take
into
account
existing
work,
for
example
in
web
browsers
in
other,
in
other
environments,
where
their
communication
situation
is
somewhat
different.
Also,
the
assumptions
about
where
keys
are
stored,
for
example,
in
a
in
a
browser,
cache
etc,
are
also
different.
So
those
need
to
be
looked
at
before
of
a
grain
of
salt
I
believe
so.
A
How
does
just
as
a
reminder
before
you
came
in
I
asked
people
to
try
and
stick
to
clarifying
questions
until
after
this
slide,
I'm
gonna
do
an
adoption,
Carl
and
then
have
this
kind
of
discussion.
You
didn't
you
hadn't,
come
in
that
good
when
you
said,
but
we've
time
so
I'm,
not
yeah
I,
don't
know
I,
don't
think
we
need
to
be
strict.
We
do
have
time
so.
I
I
mean
where
did
this
third
point
on?
This
is
obviously
a
sort
of
security
requirement
that
we
struggle
with
in
MLS
as
well
so
on
in
terms
of
forward
secrecy.
Key
compen
keep
my
key
compromise,
namely
in
terms
on
internet
that
is
compromised
at
point
T
and
for
data
before
point
T,
then
it
suffice
is
simply
too
rash
to
the
keys.
It's
not
necessary.
Diffie-Hellman
is
change.
The
diffie-hellman
changes
required
for
doing
pcs
up
got
my
security,
however,
on
when
I
say
mr.
I
deverel
with
that,
because
on,
if,
unless
you're
doing,
basically,
unless,
unless
you're,
unless
you're
doing
like
continuing
registering
with
the
same
condition
as
president
a
new
connection,
you
don't
actually
get
pcs
because
he's
compromised
the
Fen
occasion
he's
vices
to
put
to
to
screw
things
up,
so
I
think
actually
I'm
not
entirely
sure
this
last.
This
last
point
is
correct:
Richard.
I
H
I
I
understand
it.
Oh
score
already
supports
effectively
hash
ratcheting,
though
I'm
trying
to
resign
and
may
not
be
a
traction,
but
it
doesn't
say
I.
Guess
because
does
think
this
is
a
master
key
I
guess
you
actually
rush
it
forward.
Is
it
a
ratchet
or
is
it
like,
as
like
more
like
session
recite
some
more
like
one,
two
session
assumption
remember.
I
B
Yeah,
so
in
the
in
the
reboot
scenario,
we
probably
have
just
assumed
that
there
is
no
state
to
fall
back
on
so
then
a
hashing
solution
probably
does
not
work,
but
that's
a
very
good
good
thing.
I,
don't
remember
what
the
requirements
documents
assess
it
might
be,
have
to
be
formulated
in
more
norm.
Diffie-Hellman
terms.
B
Requirements
cited
here
for
be
a
scientist
and
uncie
is
recommendation
requirements
for
IPSec,
which
they
don't
remember
if
it
BSI
or
ANSI,
but
for
IPSec
they
recommend
doing
it
if
Hellman
every
hour,
that's
not
doable
for
constraint,
IOT,
but
probably
the
constraint
IOT
should
protect
their
keys.
They
should
do
the
fireman
or
retching
more
often
than
their
time
10-year
life
cycle
right.
I
So
this
actually
I
think
is
like
quite
an
important
point,
which
is
that,
because
we're
also
trying
to
minimize
on
you
know
bandwidth
and
computation
if
the
purpose
is
having
pcs
or
or
or
DL
memory
refresh
in
any
case,
then
what
you
really
need
is
saying
smells
much
more
like
tail
a
session
resumption,
because
you
want
to
do
just
that
if
you
helmet,
but
you
don't
want
to
incur
the
RPK
authentication,
cost
the
the
signature
or
the
set
of
the
second
diffie-hellman
or
I.
Guess.
I
Third,
if
you
hum
in,
but
you
go
I
baby,
that's
right.
I'm
gonna,
like
a
signal
type
to
be
the
same
type
protocol
right,
has
basically
three
four
key
operations
as
opposed
to
one,
and
so
if
what
you
want
to
do
is
keep
you
fresh,
but
you're
not
concerned
about
you
aren't
going
with
us
right,
so
so
I
think
they're.
Definitely
a
sharp
in
this
point.
If
we
think,
if
we,
if
we
think
I
sort
of
read
this
is
background
material.
I
In
terms
of
like
on
this,
because
the
questions
are
frequency
often
come
up
in
there
like
how.
Why
does
it
really
have
to
be?
Because
you
didn't
like
once
a
year
so
who
cares
right,
but
if
this
is
actually
a
set
of
requirements
that
it's
like?
No,
you
have
to
support,
like
you
know,
refresh
you
know
running
it
in
the
egg,
every
every
two
hours
or
every
day
or
whatever
it
is,
then.
I
B
E
Mood
so
I'm
wondering
if,
if
we
can
have
this
possibility,
where
the
server
or
one
of
the
parties
can
decide
on
how
frequently
this
is
done.
If,
if
the
server,
for
example,
knows
information
about
the
device,
whether
you
know
it's
battery-operated
and
cannot
do
Kirra
fresh,
let's
say
more
than
once,
once
a
day
or
once
in
a
week
it
can
choose
and
then
then
the
other
side
has
to
kind
of
follow
that
yeah.
B
E
B
N
Giving
it
to
Ricky
it's
actually,
you
say
some
pretty
does
IPSec
in
one
hour,
that's
very
frequently,
I
think
more
common
is
eight
hours
in
VPN
environments,
and
this
is
not
VPN.
This
is
very
low
bandwidth
low
base
account
I
would
expect
them
to
do
Ricky
very
seldom,
be
like
like
a
once
a
week
or
something
like
that
and
they'll
be
have
to
do
about.
What
are
we
protecting
against
I
mean
if
you
are
sending
ten
packets
during
the
week?
N
What
is
the
you
know
the
benefit
for
attacker
to
actually
be
able
to
decrypt
those,
and
the
next
question
is
that
in
some
cases
the
keys
are
that
required.
We
know.
So,
of
course,
one
of
the
benefits
there
is
to
do
frequent
Ricky's
is
that
if
one
of
the
device
is
stolen
and
the
case
is
extracted
from
the
device,
but
then
we
intended
a
rekeying
is
much
more
expensive
than
such
24,
because
you
have
to
talk
to
each
other
if
you
have
to
wake
up
every
device
in
the
network
change
the
key.
N
So
it's
not
that
easy
thing
and
in
for
example,
IPSec
we
decided
so
that
we
actually
be
hey.
Mike
person
want
to
be
had
all
of
this.
You
know
we
have
to
do
Ricky
every
eight
hours.
We
have
to
do
this
and
we
chose
negotiate
it
and
then
we
these
are
the
actually
completely
because
we
don't
need
to
do
that.
Either
range
has
their
own
policy,
they
decided
to
do
Ricky,
they
can
imitate
Ricky
whenever
they
eat
and
if
they
might
have
a
completely
different
policy.
N
So
one
in
Mike
said
that
okay
I,
do
it
every
hour,
because
I
I
could
do
that.
The
other
one
says:
okay,
I,
do
it
after
the
four
gigabytes
and
whichever
you
know
reaches
first
he's
called
the
unfortunate
anyway.
The
one
who
has
all
of
our
policies
contain
forces
anyway.
So
that's
going
to
be
a
similar
kind
of
things
would
be
used
here.
Yeah,
that's
a
good
point.
E
B
B
A
John
you
can
sit
down
from
it
or
not,
or
whichever
you
like
for
a
minute.
Yes,
so
we're
planning
to
do
is
just
find
out
how
many
people
have
read
this
see
if
there's
a
sense
in
the
room
that
we
want
to
adopt.
This
ask
a
couple
questions
about
process.
Do
we
want
to
use
github
issues
that
kind
of
thing
and
then
kind
of
have
out
the
actual
substantive
requirements,
discussion
and
so
on?
So
is
that
ok
I?
Could
you
want
it
yeah.
I
Think
so
before.
I
So
I
think
I
guess
so.
I
think
this
is
a
concern.
I
agree
with
John,
I,
think
and
I
guess:
I
think
that
the
the
the
process
question
I
think
it
is
like
because
we're
not
publishing
RFC
we're
gonna
have
to
at
some
point
where
were
like
hey.
I
This
is
like
done
and
then
we're
like
turning
to
do
a
selection
process
right
on
so,
like
so
I
think
the
the
the
question
then,
is
like
what
the
home
for
adoption
means
and
hundred-dollar
means
the
conventional
thing,
which
is
that
you
know
this
is
we're
taking
this
audience,
you
can
store
the
becomes
a
working
document
and
we
work
on
it
for
a
while
and
at
some
point
the
future
we're
gonna
have
like
a
discussion
about.
I
Is
this
done
enough
to
destruction
process
then
like
let's
adopt
I'm
in
favor,
if
it
if
the
honey
is
hey,
this
is
like
really
a
selection
process.
That
so
can
you
repeat
the
one
you
don't
like
if
the
if
the
humming
for
is
oh,
this
is
done
enough
to
start
doing
a
selection
process,
then
I'm,
not
in
favor
of
that
so
but,
like
I,
said
I.
Think
it's
a
go
starting.
I
A
A
Including
previous
versions,
is
that
good
anymore?
Okay,
so
there's
about
a
dozen
or
so
great,
so
we
have
a
home
to
say:
do
we
think
this
is
ready
to
adopt
as
a
indem?
That's
with
the
cavity
of
the
backer
had
that
we're
gonna
work
on
it
and
then
do
a
working,
a
bass
call
type
thing
later
before
we
do
funny
selection
I
wanted.
A
A
I've
got
a
little
way
we
would
have
had
to
panic,
because
what
we'd
be
doing
for
the
rest
of
the
day
and
great
so
we're
gonna.
Do
that?
How
do
people
want
to
handle
kind
of
issue
tracking
or
not
know
that
we
just
uses
mailing
lists?
Or
do
people
want
to
do
other
things
like
with
github
and
issues?
Please
give
us
your
thoughts.
A
H
A
So
will
will
cause
that
to
happen
or
find
somebody's.
Do
it
for
us
I
think
that's
the
only
process,
e
type
thing
for
now
so
now,
I
guess.
The
question
is
the
discussion
of
the
actual
requirements.
So
John
has
a
couple
more
slides
unless
we've
gotten
some
mail
from
echo
recently.
So
there's
probably
a
couple
topics
to
bring
up
so
we'd
like
to
have
this
question
of
those
now.
Please.
A
A
J
B
Yep,
so
these
are
discussion
topics
mostly
from
Kartik
poster
on
the
list
in
different
one
about
static,
D,
H
requirements,
then
Khattak
posted
a
review
on
different
security
properties.
The
echo
poster
review
today
or
at
least
comments.
These
discussion
topics
has
not
been
updated
to
cover
that,
but
I
think
we
have
time
for
to
discuss.
Yeah
yeah.
B
I
I
guess
right
on
I
think
so
I
think
I
think
I
think
there
is
there's
a
consideration
here,
which
is
that
the.
I
Certainly
in
tell
us
and
I
think
in
deadlock
as
well
on
the
negotiation
is
partly
protected
via
the
signature
over
the
transcript
and
and
so
the
on
and
and
so
an
attacker
can't
downgrade
your
symmetric-key
symmetric
keys.
I
However,
in
this
mode
the
only
signature
protection
is
provided
by
these
by
the
symmetric,
cipher
suite
and
so,
and
so,
basically
in
so,
if
you're
using
CCM
a
you
only
had
a
64
bits
of
security
against
NC,
downgrade,
right
and
so
on,
and
so
it
seems
like
basically
and
thats
protest
less
than
a
shoo-in
on
in
this
engine
as
I
say,
because
because
because
the
way
a
tax
design
is
really
would
be
in
TLS,
like
I,
say
on,
but
I,
don't
sure
so,
I
guess
I'm
nitpicking,
because
I
think
you
Office
Lee
get.
I
You
obviously
guess
is
the
actual
advantage
with.
If
you
Almon
that
you
do
it,
they
do
over
a
person,
issues
I'm,
not
sure
it's
quite
as
large
as
this,
because
I
think
I
think
you
I
think
you'd
want
to
use
like
a
like
a
like
a
20,
octet
or
32
octet
Mac,
rather
than
simply
they
ate
out
at
Mac.
I
Only
storage
for
the
transfer
transcript
Mac
on
the
on
I
think
where
that
actually
brings
me
to
I
think
is
is
is
the
bigger
point
which
what
the
requirement
looks
like,
which
is,
which
is
what
is
the
sort
of
guarantee
that
the
this
RUC
guarantee
the
see
you
see
or
CR,
Garrett
or
CK
guarantees
of
the
of
the
eight
versus
the
guarantees
of
the
of
the
transport
protocol?
I
B
I
That
I'm
concerned
about
that
as
well
yeah
I
think
I
think,
basically
that
having
an
ache
were
the
only
security
for
the
anti
downgrade
is
provided
by
the
it's
provided
by
the,
but
by
that
by
the
channel.
But
application
security
transport
gives
you
a
Streamy
weekend,
young
great
defense
right,
because
it
means
that
you're.
Basically,
it's
only
the
strong
is
the
integrity
check
on
the
on
the
on
the
record
layer,
whereas,
whereas
if
you
have
a
arm,
whereas
you
have
either's
injury.
I
Transcript
or
you
have
a
strong
knock
of
the
entire
transcript,
then
you're
strong,
even
if
you're,
extraordinarily
weak,
record
layer
and
I
guess
Michael
here
right
as
a
magic.
Imagine
you
had
like
a
record
layer
were
like
no
integrity
or
you
had
one
with.
You
know
32
bits
of
into
a
check.
So
now
you
have
a
million
generator
all
in
there
are
in
the
PSK
case,
whereas
you
would
in
our
PJs
again
assuming
it's
only
sign.
The
whole
transport
I
think
does
yeah.
B
It
might
be
might
be
reason
to
allow
different
Mac
sizes
in
the
different,
but
it's
also
I
think
I
said
54
before,
where
I
think
45
is
the
number
in
close
to
the
available
payload
size
in
both
Laura
bond
and
six
dish
with
five
hopes,
so
it
might
be.
If
you
go
to
16
bit,
if
byte
Mac
in
the
PSK
you
you
need
to
change
to
fruit,
2
frames,
then
the
question
is:
is
that
it
were
yeah.
I
Yeah
I
think
my
guess,
yeah
I
mean
so
I
guess
also
important
distinguish
between
the
the
transport
level
Mac
and
the
eighth
level
Mac
right.
So
so
some
some
protocols
like
like
I,
mean
I,
think
like
so
so
it's
it's,
it's
quite
possible
say:
look
we're
just
gonna
absorb
an
extra,
an
extra
Mac
only
in
the
handshake
messages,
but
we're
not
gonna
it
in
every
message.
I
mean
it
and
so
like
one
advantage
that
is,
then
you
can
have.
I
I
A
I
Clarify
what
any
down
really
means,
because
actually
it's
actually
it's
subtle.
So
I
did
note
in
my
comments.
The
a
downgrade
on
doesn't
apply
to
this
annotation
scheme,
because
obviously,
is
what
printing
you
from
down
being
downright
in
the
first
place,
but
so
it's
like
just
important
to
like
clarify
what
a
downgrade
means
and
and
and
what
it
defends
against
want
those
not.
B
B
That's
not
important
for
them
requirement
discussions
but
I
think
the
important
discussion
here
should
we
work
on
a
solution
that
supports
static
diffie-hellman
keys,
especially
for
his
K
for
all
K
and
my
feeling
and
the
feeling
from
Karthik
is
yes,
we
should
I
think
the
solution
needs
to
be
chaotic
system
was
that
maybe
we
can
only
do
static.
Diffie-Hellman
key
I
think
that
in
some
theoretical
sense
that
would
be
good,
but
I
think
we.
We
will
probably
need
to
support
PSK
six
dishes
today
built
on
PSK
signature.
K
I
H
Know
what
I
was
gonna
say:
it's
like
I
wonder
if,
if
like
there's
an
underlying
extensibility
requirement
and
there's
there's
some
semi
static
drafts
in
TLS
working
group
right
now
that
are
basically
taking
advantage
of
the
extensibility
that
TLS
has
in
the
signature
types
and
in
the
public
key
type.
So
you
put
in
certificates
to
make
it
very
quite
seamless
how
you
can
take
what
was
originally
a
signature
based
protocol
and
swap
out
signatures
for
us
sending
static
max.
H
I
Think,
that's
probably
true:
I
was
gonna,
saying
different
they're,
not
necessarily
conflicting,
which
is
I.
Think
we
clearly
are
gonna
need
to
have
both
city
I
we
really
need
is
a
signature.
Store
works
just
get
away
too
many
cases.
People
not
gonna
have
to
feel
my
keys
right
and
and
I.
Don't
think
and
and
I
think
like
it'd,
be
good
to
support.
Actually
filmin
I
think
would
be
egg.
Okay,
I
mean,
like
you
know.
We
got
like,
like
you
know.
I
Six
months
ago,
instead
heard
of
this,
we
like
work
talking
a
sexy,
feel
min
so
like
we
thought
it
was
good
enough,
that's
integer!
So,
but
maybe
it's
not
like
a
hard
worker,
but
obviously,
if
I'm
we're
gonna
have
to
obviously
the
size
issue
or
earlier,
but
obviously
cuz
you're
substantial
size
advantage.
So
it's
worth
be
it'd
be
really
good
to
be
able
to
support
it
on
the
on
I.
I
B
B
Then
second
bullet
here
is
how
much
flexibility
in
using
different
types
of
public
key
credentials
we
should
allow
and
what
our
requirements
for
that
has
been
requirement.
Mitchell
Michael
Richardson
has
expressed
expressed
that
he
he
mode
like
the
solution
to
support
mixed
or
PK
certificate
authentication.
So
one
party
attempt
gauge
with
his
certificates.
One
party
attends
with
the
or
PK
I
had
picture
that
earlier.
B
B
No
comment,
then,
second
part
here
of
the
discussion
item
is
raised
by
was
raised
by
Karthik
couple
of
weeks
ago.
He
commented
on
the
protection
of
the
PS
PS
ki-10
to
fire
and
in
his
comment
he
took
current
ad
hoc
draft
as
an
example
where
the
PS
k
identifier
is
revealed,
not
confidentiality
protected
in
message.
1
pls
do
the
same
thing
and
the
question
here.
B
I
I
Yeah
I
think
I
think
my
concern
is
it
is
it
distorts
the
product
like
it
distorts
the
protocol
quite
a
bit
and
it
makes
it
hard,
as
you
say,
but
you
got
three
forms
of
protocol
also
means
that
that
as
you
that
on
some
things,
you
might
want
to
do
so.
You
alluded
earlier
the
idea
of
having
application
data
carried
along
with
these
messages
on
and
in
in
in
in
your
in
sorry,
can
you
can
you
go
back
to
this
either
one
of
them
any
of
the
public
key
verticals
yeah
perfect.
I
I
But
now
in
this
case,
that
is
not
true
and
I
have
a
protocol
like
while
we
despair
it
like
like
under
late,
like
security
security
properties,
depending
on
where
you
stuff
the
PS
k
and
so
I
think
that,
like
just
like
like
unless
we
have
like
you,
know,
we're
attached
to
do
requirements.
So
if
someone
comes
to
us
and
says
you
know
sick
petitioner,
whatever
says
we
obviously
have
to
have
this
property.
Well,
we've
gotten
pretty
far
like
in
the
IETF
or
that
reckoning.
I
B
B
The
next
slide
is
so.
This
is
following
up
Celtx
and
review
of
the
requirement
draft
couple
of
days
ago.
I
think
it
was
beginning,
probably
Monday
this
week,
and
he
suggested
that
the
requirement
dropped
described
the
desirous
gold
of
identifying
information
in
in
general,
and
he
suggested
four
different
levels
where
level
serie
would
be
all
identifying.
Information
should
be
protect
against
passive
network
adversary's.
B
B
Think
it's
good
to
clarify
this
stricter
I'm,
not
sure
this
protocol
should
we
will
reach
even
zero,
based
on
the
discussion
here
with
the
PSK
that
is
in
depending
on
what
you
count
us
identifiable
information,
but
in
general
the
PSK
identifier
would
be
identifiable
information
if
you
send
there
what
kind
of
algorithm
support
that
might
be
identifiable
information,
if
you
use,
if
you
send
sender,
IDs
or
TLS
connection
IDs,
then
whatever
number
you
put
there
might
be
identifiable
information,
so
I
I
think
already.
Zero
here
might
be
too
strong.
I
I.
I
Agree,
I,
agree
and
I
don't
actually
stand
point
three
that
seems
like.
Actually,
that
seems
like
actually
quite
a
strong
property
in
it.
I,
don't
think
any
signature
based
scheme
meets
that
property,
so
I
mean
the
that
the
diffie-hellman
basically
means
do,
of
course,
because
Yuka,
because
either
so
I
can
for
the
transcript
the
inertia
games
do
not
so
I
I
I.
Do
this
hierarchies
quite
weird.
I
My
impression
is
that,
like
essentially
every
ITF
protocol,
this
is
every
ITF
a
Kenny,
because
ever
designed
has
this
into
the
same
properties
here
well,
except
for
tails,
one
to
which
I
have
even
worse
properties.
So
I
think,
like
we've,
got
a
consensus
about
like
what
these
don't
look
like,
which
is
to
say
we
don't
worry
too
much
about
finger
printing
of
the
initial
messages
and
we
tried
it
and
we
try
to
do
the
protection
of
the
entities.
I
The
way
you
described
the
described
in
your
document,
which
is
to
say
that
the
initiators
identity,
the
funders
entities
secure
as
passive
attack
attackers,
the
initiators
against
active
attackers
I
think
that's
where
I
set
of
trade-offs
and
I
think.
Yes,
what
your
document
says
so
I
think
like
I'm,
not
sure
we
have
the
big
a
ginger
yeah.
B
What
I
get
agree
with
with
Kathy
is
that
we
should
document
the
requirements
or
properties
that
we
want
in
more
clear
way.
I
agree
with
a
cure
that
you
should
not
probably
not
choose
some
of
these.
These
are
good.
Better
come
with
this
properties,
come
with
trade-offs.
That
goes
probably
against
the
lightweight
Ness
I.
Think.
The
main
main
thing
we
want
to
achieve
here
is
like
less.
We
don't
want
to
create
the
most
theoretical
secure
protocol.
B
B
Then
third
part
of
this
discussion
is
security,
properties
and
properties
of
the
application
data
we
go
to
request
on
the
next
slide.
Comes
application
data.
What
request
from
academia
to
try
to
specify
the
security
property
of
this
in
requirements?
Growth
better,
so
any
solution
documents
could
be
for
many,
formerly
analyzed
and
checked
if
they
meet
the
requirement
document
or
not,
then
Karthik.
B
I
They
say
this
is
like
car
thieves
advertisement
for
it
if
a
helmet,
so
one
as
you
say
we
are
your
any
sensible
protocol
already
have
to
is
like
super
hard.
It
basically
requires
having,
basically
typically
do
it
is
with
these
diffie-hellman
protocols,
where
you
say
like
it:
the
that
you
listen,
it's
not
a
key
and
therefore
and
they're
in
there
for
mo
keys
compromised,
that's
like
their
environment.
So
that's
like
sensible,
like
where
the
static
is
like
stored
in
some
little
box.
If
I'm,
what
keys?
I
Not
but
it
like
these
environments
is
like
the
same
like
they're
used
in
memory,
so
I'm
not
really
worried
about
it.
On
the
I
mean
not
worried
about
it
like
like
beyond,
like
the
you
know,
I
think
I'm,
worried
about
it,
but
I
mean
like
I'm,
not
where
I
don't
understand
this
a
Nereo
in
these
environments,
where,
like
you,
lose
the
ephemeral
key,
but
not
the
static
keys,
other
ones,
much
more
likely.
I
The
bad
rng
on
the
good
news
is,
we
already
have
a
fix
for
that
which
I
think
would
is
which
is
the
CFR
GT
after
hardening
randomness
and
that
totally
compatible
with
the
signature
based
protocols.
So
but
the
good
news,
it's
not
it's
a
compatible
protocol
change,
so
I
think
we
don't
need
I.
Think
we
should
just
like
I
think
we
should
stick
with
number.
One
is
obviously
requirement
number
two.
We
should
nothing
about
as
a
requirement
and
number
three
like
when
we
finally
get
around
to
writing
the
protocol.
O
Chris
would
just
to
expand
on
the
the
basic
idea
of
the
CFD
draft.
Is
you
take
the
long
term
private
key
of
the
responder
in
this
particular
case,
and
you
compute
a
function
of
it?
You
mix
that
with
the
output
from
your
RNG
and
then
the
security
of
the
like.
Your
reminisce
is
the
minimum
of
your
bad
energy
or
your
private
key.
So
if
your
private
key
is
exposed
and
your
bad
energy
everything's
over
everything's
bad,
but
if
you
have
better
energy
and
you're,
probably
key
is
fine,
it's
always
well.
D
Honestly,
it
the
first
two.
It
depends
a
little
bit,
of
course,
on
how
you
implement
these
type
of
things
in
currently,
what
I've,
seen
people
doing
more
and
more
is
to
separate
out
the
key
exchange
implementation
from
the
way
how
you
handle
the
the
key
storage,
and
so,
if
you
can
properly
protect
the
long-term
key,
you
will
already
have
two
things
in
place
to
to
do
the
the
protection
of
the
ephemeral
key,
because
you
just
make
calls
and
then
basically
use
the
keys
kind
of
a
big
keys.
D
That's
what
we're
doing
MPLS
we
actually
separate
it.
Those
out
you
can
actually
look
how
how
this
is
done
in
our
code,
I
haven't
done
a
survey
on
some
of
the
other
embedded
implementations
if
they
actually
allow
you
to
do
the
same
or
where
they
gloss
over
that
issue.
It
was
a
fairly
substantial
change
in
a
way
how
you,
how
we
did
the
API
is,
but
it
may
be.
If
someone
has
some
spare
cycles,
some
researchers
here
in
the
group,
they
could
actually
take
a
look
at
this.
D
That
wasn't
that
wasn't
really
anything
we
like.
We
used
that,
obviously
we've
here
less,
so
we
didn't
had
to
do
any
changes
on
TLS.
It
was
just
the
implementation
on
the
way
how
we
pass
around
the
keys
and
there.
Obviously,
if
you
want
to
take
into
account
not
just
as
software
use
or
a
software
storage
of
the
key
like
in
pure
lean
software
handling,
but
rather
cryptographic
modules,
then
those
typically
use
different,
api's
and
so
used
making
the
API
to
work
with
all
these
different
designs
was
a
little
bit
tedious,
but
yeah.
B
B
B
Here
is
suggested
formally
requirement
for
the
80,
but
that
also
this
depends
a
little
bit
on
how
many
messages
the
solution
has.
If
you
have
a
typical
three
party
protocol
like
Sigma
I,
then
you
get,
the
first
matches
is
completely
unprotected.
Second
message
is
confidentiality
and
integrity
protecting
against
that
passive
attacker
and
what
you
can
put
the
message
tree
is
confidentially
integrity
protected,
and
you
know
who
the
other
party's
this
can
maybe
be
specified
more
clearly
acre
yessir.
I
Doesn't
doesn't
sound
quite
right,
I
think
a
g2
has
confidentiality.
It
gets
the
passive
attacker
but
integrity
against
an
active
attacker
because
at
least
in
Sigma
I
the
g2
is
GOI.
Is
a
vente
cated,
a
message
to
and
therefore
assuming
that
assuming
the
client
is
an
initiator
on,
you
know,
got
the
proper
GTX,
then
there's
and
then
he
has
integrity
for
the
data
that
came
from
the
server
yep
other
than
that
I
believe
you're,
correct,
yeah,
okay
yeah.
This
seems
like
this
seems
like
like
right.
Otherwise,
yeah.
B
D
Is
the
authorization
request
does
it
contain?
Just
is
it
kind
of
only
at
here?
Please
give
me
or
is
there
please
give
me
and
here's
a
nonce,
here's
some
other
stuff
like
what's
what's
in
the
authorization,
because
I
think
because
I'm
looking
at
this
through
sort
of
like
the
eyes
of
ours
and
I,
noticed
like
the
whole
dens,
the
information
you
carry
in
each
of
those
tends
to
be
quite
important
from
for.
Overall
security
is
not
just
a--.
D
B
D
B
G
M
B
I
That
actually
brings
up
an
important
point
when
about
Petra
key
separation
that
the
that
so
I
mean
the
second
message,
especially
right.
You
want
to
use
different
keys
to
and
safer
at
the
application
data
and
and
safer.
The
contributor,
so
I
mean
I,
think
I'm,
not
sure,
I'll
think
about
how
to
document
this.
I
This
is
a
nice
or
struggle
with,
as
you
remember,
a
lot
until
us
how
write
this
down
but
and
and
did
you
get
it
right
because
of
nestea
entirely,
but
so
I
think,
but
trying
to
like
there's
a
lot
hidden
under
the
under
those
last
two
polar
points,
and
so
we
should
probably
figure
how
to
document
those
better
yeah.
B
B
A
I
I
think
I
think
that
one
thing
that
I
think
we're
gonna
need
to
spend
time
on
is
like
trying
to
sharpen
up
the
sort
of
like
frontier.
What's
possible,
I
mean,
like
the
you
know,
I
mean
as
a
little
discomfort,
with
a
sort
of
like
as
small
as
possible.
I
mean
if
he
I
mean
a
wall.
It
is
true.
I
Obviously
everybody
costs
they're
like
we
know
there
were
cliffs
and
like
try
and
understand,
like
you
know
what,
where
those
clothes
are
a
little
bit
of
hope
because,
like
I
just
think
like
I,
don't
want
to
do
like
we're.
Seeing
this
in
quick
right
now
is,
like
you
know,
he's
like
it's
a
lot
of
fighting
about
like
how
much
screwing
around
to
do
at
the
very
end
and
I
sure
don't
want
to
be
like
it
were.
I
You
boss,
call
and
have
like
a
shard
of
the
basically
someone
says
well
like
I
like
I
can
remember,
like
you
know
what
want
yeah
like
you
know,
the
Chartered
risky
tells
us.
Oh,
my
god,
we
got
like
recycle,
so
I
was
trying
to
get
a
sense
of
like
we're.
The
you
know,
like
I,
think
I
think
we
spent
a
little
the
minister
work,
the
working
group,
so
it's
great
but
I
mean
like
doesn't
I'm
trying
like
document
week
like
what
the
requirements
meeting
practice.
I.
I
H
H
Clearly,
we
need
certain
fourth
degree
of
cipher
agility
at
the
very
minimum,
meaning
some
other
forms
of
extensibility,
but
invite
I'll,
try
and
think
about
how
to
put
that
more
precisely
and
then
send
some
feedback
to
the
list,
but
yeah
glad
to
think
about
your
what
the
authors.
Thank
you
spell
yeah.
B
H
An
interesting
thought
experiment
might
be
this
take
question
that
came
up
earlier,
like
it
might
be
that
in
an
initial
version
of
whatever
or
whatever
okay
we
come
up
with
here,
we
don't
have
a
baked
flavor
to
it,
but
it
might
be
nice
if
there
was
sufficient
extensibility
in
there
that
a
Paik
could
be
fit
in
later.
I'm,
not
quite
sure
how
to
express
that
in
like
requirements,
language
yeah.
B
B
For
example,
we
are
born
if
I
remember
correctly
there
you
have
to
make
assumption
what
kind
of
transport
protocols
you
have
in
and
what
options
you
have
in
these
and
so
on,
but
I
think
number
45
came
up,
something
like
45,
maybe
was
47
for
a
single
message.
I
think
there
are
similar
numbers
for
six
dish.
If
you
assume
five
hopes,
which
might
be
a
good
assumption,
you
should
probably
discuss,
but
there
the
number
of
bytes
available
for
the
body
decreases,
for
if
you
have
more
hopes
it
increases.
A
B
I
Yeah
I
mean
III
I
agree
with
you,
I
think
you
know.
We've
spent
a
lot
of
time.
Like
you
know,
screwing
around
with,
like
like
trying
to
reason
out
post
quantum
and,
like
you
know,
we're
nowhere
near
I
mean
I.
Think
I
mean
certainly
there's
two
questions
where
one
is
post,
one
on
key
change,
one's
post
content
occasion:
I,
don't
think
we're
ready
for
either
of
them.
I
think
this.
A
M
M
There
shouldn't
be
anything
controversial,
so
there
is
this
document
in
the
60s
working
group
that
specify
that
we
call
a
zero
touch,
drawing
this
specifies
essentially
in
a
draw
enrollment
solution
for
six
dish.
That
is.
The
document
is
a
profile
of
brueski,
of
constraint,
voter
and
constrained
voucher
documents
in
anima
and
and
also
the
ESP
over
coop
s
document
in
in
ace.
M
D
M
D
P
M
Sense
so
a
couple
of
requirements
there
that
being
brought
up
on
the
list
before,
essentially,
we
would
like
to
send
certificates
by
reference
rather
than
by
value
over
the
wire.
We
would
like
the
two
peers
in
the
run
in
the
a
cron
to
be
authenticated
by
different
types
of
credentials.
For
instance,
someone
use
case
that
we
discussed
is
server
being
identified
by
an
RP
k
and
the
client
being
an
identified
by
its
ID
of
ID,
which
is
a
certificate
that
it
uses
to
enroll
into
an
your
domain.
I
E
M
I
M
I
I
Right,
I
guess,
but
again
I
guess
then
I
want
to
push
back
on
this.
Then
I
want
to
push
back
on
this
requirement,
because
it
seems
to
me
that
a
better
design
would
be
for
the
server
to
send
a
digest
I.
Why
does
it?
Why
doesn't
it?
What
is
that?
What
like
my
point
is
like
is
like:
why,
like
is
that,
instead
of
having
the
server
send
the
client,
the
RPK
there's,
a
client
then
asks
some
Oracle.
I
I
I
I
I
think
one
thing
to
recognize
is
that,
like
I,
don't
know
exactly
what
sort
of
network
topology
have
in
mind,
but
in
some
of
these
apologies
they're
gonna
have
this.
What
this
air
interface,
which
has,
which
is
extremely
low,
bandwidth
and
they're
gonna,
have
I,
don't
know
how
you're
talking
to
that
the
server
you
did
about
your
request
for,
but
if
that's
not
over
the
same
your
interface,
if
it's
like
over
a
wire,
then
you
want
to
move
data
from
the
urn
or
face
onto
the
wire,
and
so
this
is
this.
I
Rpk
is
32
cats
or
so
right,
and
so
you
know
if
as
soon
as
that's
55,
509
and
so
on,
and
so
if
your,
if
your
your
interface
to
the
voucher
server
on,
is
like
faster
than
what
you
want
to
do,
is
you
want
to
how
to
identify
or
hear
your
server
give
you
the
RPK?
So
you
just
save
those
ready
to
our
tests.
M
E
E
To
start
that
the
client
has
devised
certificate
or
a
to
do
one
AR
certificate
and
server
has
our
PK,
and
then
we
want
a
ke
to
magically
give
a
session
keys.
Perhaps
that's
a
easier
way
to
frame
the
requirement.
Second
I'm,
not
sure
we
should
get
too
much
influenced
by
this
requirement
when
we
are
designing
our
ake,
a
ke.
But
that's
just
my
opinion.
E
M
A
A
A
A
So
we've
suggestions
there
for
December
January
February
month
and
the
same
bar
might
be
a
base
ambitious
because
in
terms
of
people
getting
home
from
here
and
doing
stuff
and
actually
making
progress,
I
mean
I.
Think
I'd
like
to
try
and
like
open
issues
and
get
hope
and
then
close
a
few
easy
ones
hopefully
and
then
have
an
interim
about
the
things
that
are
we're
talking
about
would
I
think
be
what
I
would
suggest,
so
that
would
be
more
January
than
December
I'm.