►
From YouTube: IETF-CORE-20220928-1400
Description
CORE meeting session at IETF
2022/09/28 1400
https://datatracker.ietf.org/meeting//proceedings/
A
A
B
A
A
A
A
A
This
is
an
officiality
of
meeting
we've
been
recorded
and
the
note
12
applies.
It's
not
just
about
IPR.
It's
also
in
the
special
about
our
code
of
conduct
so
be
nice
and
professional
to
each
other,
and
today
we
have
a
relatively
packed
agenda
compared
to
usual
entry
meetings.
We
are
supposed
to
start
with
a
number
of
open
points
to
discuss
about
the
Kudos
draft
on
key
update
for
Oscar,
and
then
we
have
a
point
that
we
can
really
discuss
with
Michael
Richardson,
especially
only
between
14
14
and
15
UTC.
A
C
B
B
Kudos
draft
and
I'll
start
with
a
short
recap
and,
as
you
may
know
it,
this
draft
mainly
contains
two,
let's
say:
porch,
one
related
to
the
actual
Kudos
procedure,
with
the
lightweight
way
to
renew
the
old
score,
Master
secret
and
master
assault,
and
also
a
part
about
the
aad
key
usage
limits
specific
to
oscore,
defining
appropriate
values
in
terms
of
a
number
of
decryptions
and
number
of
encryptions,
and
how
you
can
extend
those
core
contexts
to
take
into
account
the
counting
and
the
limits.
But
today's
main
focus
really
mainly
be
Kudos.
B
There's
one
point
about
the
limits
also
so
going
to
the
next
slide.
This
is
General
recap
of
the
Kudos
freaking
procedure,
so
the
fundamental
idea,
basically,
is
you
have
a
message
message
exchange
where
you
exchange
dances
and
one
and
two,
and
these
are
fed
into
a
update,
CTX
function
that
internally
produces
a
new
Oscar,
Master,
secret
and
master
result,
and
after
procedure
is
finished,
the
peers
can
continue
communicating
with
this
new
context,
and
part
of
this
procedure
is
relying
on
an
extension
of
those
corruption.
B
But
now
I
want
to
go
in
to
the
open
points
for
the
day,
and
these
are
the
ones
we
have
listed.
I'll
go
through
them
in
more
detail
later
on.
But
basically
it's
about
this.
The
first
one
is
about
the
flat
bits
in
those
corruption
and
some
considerations
on
those.
Then
we
talk
about
a
single
method
for
updating
the
key
material.
That's
related
to
this
update
CTX
function.
Next
is
whether
or
not
we
should
have
a
negotiation
for
the
followers
secrecy
mode
or
or
not.
B
Then
it's
related
to
the
content
about
the
key
usage
limits
and
possibly
relocating
that
next,
it's
about
extending
ad
hoc
with
EAD
items
for
Kudos,
so
peers
can
learn
through
an
adult
execution
with
another
party
support
skills
or
not.
The
last
point
is
where
and
how
we
should
Define
the
content
about,
update
and
all
score
send
and
recipient
IDs,
which
is
also
currently
a
part
of
this
draft,
so
yeah
to
start
going
into
a
bit
more
detail.
So
the
first
point
is
about
the
old
score
flag
bits.
B
So
there's
been
some
discussion
on
the
mailing
list
about
this.
You
can
see
in
reference
number
one
there,
but
basically
what
has
happened
is
first
of
all
our
ID
bit,
which
is
the
bit.
That
indicates
that
this
is
a
Kudos
message
and
that
Anonymous
component
is
present
has
been
registered
now,
as
for
other
things,
basically
the
current
situation-
and
this
is
about
the
actual
Oscar
flag,
Beats.
B
The
current
situation
there
is
that
bit,
0
and
1
are
resolved
from
those
currency,
and
the
current
text
in
Kudos
is
that
we
say
that
we
should
Define
bit
one
for
signaling,
a
second
flag
byte.
So
it's
an
extension
bit
for
those
score
Flag
by
basically
you're
saying:
okay,
I
want
a
second
flag
byte
and
the
as
you
can
see,
the
D
bit
is
then
present
in
this
second
flag.
B
But
the
point
is
that
this
document
is
already
updating
the
oscore
RFC.
So
these
points
can
then
be
a
part
of
that
update
as
further
elements
that
are
to
be
updated,
and
the
thing
here
is
that
the
Bit
Zero
there's
not
a
concrete
plan
for
using
Bit
Zero.
It's
only
earlier
considerations
about
possibly
using
it
for
an
uncompressed
cozy
object,
but
it
seems
that
that
is
not.
D
B
B
E
Sorry
I
came
late
here,
but
I
I
think
this
is
a
good
good
poster.
I,
don't
think
we
need
to
allocate
in
advance.
We
could
take
a
bite
at
a
time
or
or
maybe
the
next
bite
also
but
yeah,
but
I
think
this
is
a
good
approach,
and
the
interesting
thing
here
is
that
the
person
that
proposed
I
think
the
person
that
proposed
the
other
previous
use
of
zero.
It
is
the
same
person
as
now
is
proposing
the
other
way
of
using
it.
So
so
yeah
I
think
that's
there.
E
E
B
B
I
see
okay,
but
thanks
thanks
for
the
feedback
on
this
point,
I'll
jump
to
the
next
one,
then
so
yeah.
This
was
another
point
I
believe
triggered
by
some
discussions
and
also
an
issue
that
was
created
on
this.
So
the
point
is
that
currently
in
the
update,
CTX
function,
which
actually
practically
updates
those
core
context,
so
you
feed
it
the
nuns
essentially
or
the
nonsense,
and
it
produces
a
new
master
secret
Mass
result.
But
the
point
is
that
currently
we
have
two
internal
code
paths
it
can
take.
B
One
is
using
the
adoqi
update,
which
you
see
is
Method
one
in
the
green
box
and
that
can
be
used
if
the
original
context
was
established
using
ad
hoc.
So
you
have
the
Nokia
update
available.
The
other
path
is
that
you
base
the
update
on
an
hqdf
extract
and
expand,
and
you
see
in
the
blue
box,
and
that
is
intended
to
be
used
when
adult
was
not
used
to
generate
the
context
for
the
initial
context.
B
And
so
the
point
is
that
well
method,
one
first
of
all
assumes
and
requires
that
you
have
a
valid
adult
context
or
session
available,
because
otherwise
you
can't
use
that
okay
update,
and
it
may
also
be
the
case
that
you
need
us
kind
of
fall
back
that
okay,
what
if
you
know
the
pairs
originally
used
at
dock?
But,
okay,
that
look
session.
Someone
became
invalid.
So
your
you
wish
to
use
the
hqdf
extract
and
expand
method
rather
than
the
Adobe
update.
B
B
You
know,
only
use
metal
tool,
so
we
actually
removed
that
the
key
update
path
and
we
only
rely
on
the
hqdf
extract
and
expand,
and
it
seems
that
just
like
using
the
Ado
key
update,
it
doesn't
provide
an
additional
benefits
over
only
relying
on
the
hqdf
extraction
expand,
and
it
also
has
some
good
properties
in
terms
of
building
this
X
and
value
which
we
can
simplify.
Building,
because
that
okay
update
requires
that
it's
a
super
byte
string.
B
But
if
we
use
the
hdf
extract
and
expand,
we
no
longer
have
such
requirements,
so
it
simplifies
things
so
yeah.
To
summarize,
the
proposed
change
here
is
to
update
this
of
the
CTX
method,
to
remove
method
one
and
only
use
method,
to
only
use
the
hqdf
extract
and
expand
method,
and
that's
a
simplification
and
a
team
sits,
there's
no
drawbacks
in
terms
of
security.
B
Yeah
I
guess
that's
the
I
think
we
discussed
it
briefly
during
itf-14
I
guess
the
question
is
fundamentally
like:
are
there
any
Security
benefits
you
get
from
the
adoki
update
that
you
do
not
get
from
the
hkdf
extract
and
expand,
and
from
our
reasoning
and
and
discussions
we
have
not
been
able
to
identify
that
there
should
be
any
specific
benefits
for
using
educate,
update
compared
to
the
hqf
extract
and
expands.
So
I
know
how
to
if
we're
not,
let's
say
formally
prove
that,
but
from
what
we
have
discussed
and
thought
about.
E
Yeah
I
try
to
think
here.
So
what
what
okay
update
does
is
iterate
equal
to
an
iteration
with
the
hash
function
based
on
it?
It's
taking
the
to
the
random
key
comes
out
of
ad
hoc
and
it
reiterates
hashes
that
and
and
then
you
derive
from
that,
the
Oscar
Master
Secret-
and
this
is
just
doing
the
iteration
to
the
master,
Secret
and
I,
don't
see
any
difference
from
my
right.
B
E
B
Yeah
but
I
think
it's
it's
a
it's
a
good
point
to
think
that
you
that
you
mentioned
yeah
I,
see
there's
some
some
extra
feedback
there
in
the
in
the
chat
from
Christian.
On
the
previous
point,
but
fair
enough,
then
it
seems
the
yeah
there's
no
strong
objections
from
what
I
can
tell
to
proceeding
in
this
way,
and
of
course
we
should.
B
B
So
the
the
point
of
having
this
no
forward
secrecy
mode
is
to
allow
such
devices
to
actually
use
Kudos,
because
if
you
want
for
a
secrecy
mode,
you
have
to
be
able
to
remember
and
write
to
disk
the
intermediate
Master
secrets
that
you
generate,
and
currently
we
have
some
signaling
for
this
in
this
P
bit.
As
you
can
see
in
the
figure
on
the
right
hand,
side
and
essentially,
you
can
set
the
P
bit
to
zero.
B
If
you
want
to
use
Kudos
in
forward
secrecy
mode
and
one
if
you
want
to
use
the
no
forward
secrecy
mode-
and
the
point
is
that
both
players
have
to
agree
so
both
have
to
have
either
zero
zero
or
one
one.
So
they
match
they
agree
on
which
path
to
take
right.
But
the
point
is
that
there
is
the
case
where,
let's
say
the
initiator
says
P0,
so
it
wants
to
use
Kudos
with
forward
secrecy.
B
However,
the
responder
is
not
capable
of
that
because,
for
instance,
it's
a
very
constrained
device
which
cannot
save
to
disk.
Well,
then,
the
initiative
can
simply
respond
with
P
one
and
yeah
the
then
the
actual
procedure
can
be
aborted
and
the
initiator
can
re-rank
Kudos,
but
now
with
P0,
so
now
you're
running
with
a
no
forward
secrecy
mode-
and
the
point
is
that,
of
course,
this
is
all
you
it's
a
potential.
It's
a
learning
procedure
that,
after
you
have
one
at
one
time
run
codes
with
other
pair.
B
Can
we
make
an
assumption,
or
can
we
require
that
the
devices
know
ahead
of
time
whether
the
other
peer
supports
the
fs
mode
or
not?
Because
in
such
case
there
would
be
no
need
for
the
negotiation
at
all
right?
You
simply
know
what
other
parties
supports
and
that's
what
you
go
for
so
we
talked
about
that
I
mean
the
thing
is.
The
question,
though,
is
that.
B
For
instance,
if
you
use
those
core
Ace
profile,
there
may
be
no
way
to
convey
this
so
that
both
parties
know
what
the
other
one
is
capable
of.
So
if
we
make
this
requirement
that
they
must
know,
we
may
limit
usability
or
add
these
extra
requirement
of
pre-knowledge.
That
may
be
hard
to
fulfill
yeah.
Christian
I
see
it's
in
the.
D
I
think
the
the
ace
Oscar
profile
is
a
good
example
of
why
this
information
would
be
available,
because
the
authorization
server,
which
picks
a
secret
that
would
be
shared
between
the
peers,
has
to
know
already,
which
algorithms,
those
peers
support
and
whether
or
not
you
support
forward
secrecy.
Node
is
an
information
that
is
very
similar
to
the
information
about
the
algorithms
and
that
information
already
has
to
be
with
the
authorizations.
D
E
B
B
Basically,
having
this
requirement
may
need,
May
mean
that
we
have
to
extend
those
queries
profiles,
because
there
must
be
a
way
to
convey
this
information
to
both
peers,
which
means
putting
this
in
the
response
from
the
As
and
also
putting
this
information
within
the
token
itself
and
there's
no
appropriate
Fields
where
to
do
that.
Currently
right,
so
it
may
add
complications
in
terms
of
having
to
update
those
Grays
profile.
D
B
They
would
I
mean
they
they
wouldn't,
but
I.
Think
that's
one
of
the
strength
of
the
way
we
designed
Kudos
right
now
is
that
it's
not
necessary
that
you
know
if
the
other
players
support
Cruisers
are
not,
and
it's
not
necessary
to
know
in
which
mode
the
other
player,
which
mode
the
other
players
support,
because
you
can
actually
for
Kudos
you
can.
You
can
simply
try
to
initiate
Kudos
and,
as
far
as
the
mode
while
we
have
this,
let's
call
it
a
basic
negotiation
to
to
synchronize
on
the
mode.
D
B
E
Okay,
I,
don't
know
if
I'm
first
yeah
I
can
start
anyway.
So
the
I
think
the
trial
and
error
is
it's
good
enough
for
unless
I
don't
see
any
reason
why
this
needs
to
be
known
beforehand
really.
But
please
enlighten
me
on
that,
and
the
important
thing
here
is
that
the
negotiation
is
secured
but,
like
you've
talked.
B
E
Let's
see
yeah
I
I
think
could
ask
you
have
to
wrap
up
I.
Think
I.
Thank
you
and
I
think
that
what
is
it's
good
if
we
don't
add
more
things
that
you
need
to
configure
beforehand,
let's
go
to
people.
If
things
can
be
discovered,
because
that
would
mean
we
will
need
to
update
all
these
documents
containing
various
information
bits
and
the
protocol
becomes
more
complicated
and
so
on.
So
I
I'd
like
to
keep
it
separate
if
possible,
okay,
I.
C
Yeah
I
just
wanted
to
make
the
general
deployability
point
that
by
requiring
some
other
components
to
also
move
with
you,
you
make
it
harder
to
actually
start
using
Kudos,
so
I
think
I
agree
with
joran
here
that
we
should
reduce
potential
interactions
dependencies
here
to
make
sure
that
that
people
actually
can
start
using
cudas
scooters
as
soon
as
possible.
But
my
question
would
just
be
you
say:
kudas
is
about
it.
C
B
B
B
B
B
In
a
sense,
so
this
is
about
another
Point
here
about
splitting
out
the
context
related
to
update
of
Oscar
IDs,
because
currently
we're
in
one
section,
that
is
about
a
procedure
for
updating
the
old
score,
sending
recipient
IDs
based
on
early
mailing
list
discussion
and
also
an
oscore
issue,
and
this
can
be
related
to
privacy,
for
instance,
where
you
want
to
switch
IDs
to
not
be
trackable
across
different
networks.
Currently,
this
procedure
can
be
run
completely
Standalone.
It
can
also
be
run
as
port
and
integrated
within
aquila's
execution
and
yeah.
B
D
B
B
B
It
is,
however,
directly
related
to
oscore,
but
if
we
split
this
out,
the
Kudo
Strat
will
be
more
focused
on
Kudos,
and
this
is
a
independent
procedure
for
only
updating
the
old
score
sender
and
recipient
IDs.
So
that
was
one
thing
brought
up
during
the
previous
IDF
meeting
that
okay,
what
about
next
is
splitting
out
this
functionality
to
have,
let's
say
more
but
shorter
or
less
complex
drafts.
B
You
think
you
think
we
should
write
article
yeah.
It
was
you
who
had
brought
up
this
point
during
the
previous
meeting
yeah.
It
has
this
advantages,
of
course,
in
terms
of
making
the
draft
more
focused
on
on
the
core
content,
which
is
Kudos
and
the
limits,
and
this
can
be
used.
Possibly,
someone
would
be
only
interested
in
these
procedure,
updating
procedure
and
not
actually
kudos.
A
C
B
E
B
B
B
B
B
E
B
So
yeah
right
so
I
can
maybe
yum
in
to
the
next
one.
He
actually
let
me
Jump
Ahead
a
little
bit
so,
but
this
was
the
point
about
so
essentially.
You
could
argue
that
the
draft
has
three
main
parts
now,
which
is
Kudos
the
limit
part
and
the
Oscar
ID
update
so
One
path.
Is
we
keep
them
all
in
the
current
draft?
Another
part
is
we
split
into
two
new
drafts,
so
we
have
cures
and
limits.
We
have
the
update.
So
to
the
rest,
the
other
part
is.
B
We
have
three
drafts,
so
we
have
Kudos
only
the
limits
related
things
and
then
the
Oscar
ID
updating
things
so
there's
actually
multiple
options
there
on
terms
of,
if
we're
talking
about
splitting
the
draft
into
multiple.
As
far
as
the
content
about
the
limits,
there
are,
let's
say,
sub
options
there
on
what
to
do
with
it.
So
currently
the
limits
really
focus
on
three
things.
One
is
an
overview
of
the
limits:
calculations
with
recommended
values
to
use
building
on
the
C
for
G
draft.
B
The
other
part
is:
how
do
you
extend
those
core
context
in
terms
of
limit
and
counter
objects
in
there,
and
you
have
this
x
parameter
where
you
actually
can
define
a
lifetime
of
those
core
context
and
the
third
part
there
is
extending
the
score
message
processing.
So
practically
when
you,
when
you
encrypt
a
message,
you
want
to
increment
the
sort
encounter
yeah
and
also
tell
me
if
we
should
to
move
to
the
other
document.
I
know
there
was
had
a
limited
time
slot.
B
But
yes,
let's
finish
this
page,
there's
three
options
here
in
terms
of
what
to
do
with
the
limits.
One
is
keeping
this
second
move
some
parts
related
to
the
limits
to
the
appendix
third
move,
to
complete
a
new
draft,
so
in
general
it's
one
part
is
about
splitting
the
draft
to
be
a
one
to
a
two
to
a
three.
The
other
part
is
okay
as
far
as
the
limit,
specifically,
what
do
we
do
with
that?
B
A
To
be
fair
on
the
way
we
got
to
this
point,
the
very
original
plan
was
to
have
one
document
on
the
limits
and
one
on
Kudos
and
at
some
point
at
that
interim
meeting
quoted
their
John
had
a
very
strong
opinion
about
having
a
single
document.
Instead,
we
both
so
we
we
can
take
it
back
and
go
the
other
way,
but
but
just
for
the
record
to
document
how
we
got
where
we
are.
C
E
B
B
A
A
A
D
C
But
I'm
afraid,
yes
to
the
list
against
yeah
to
to
me,
it
seemed
that
the
discussion
we
were
having
was
actually
useful
in
that
it
seemed
to
uncover
at
least
a
new
way
of
looking
at
the
things
that
animal
is
actually
doing
there
and
I'm
not
sure
that
that
this
thinking
process
is
completed
at
this
point
in
time.
So
I'm
not
having
any
any
well-considered
opinions,
because
I'm
still
trying
to
digest
the
the
changes
in
perception
of
what
the
the
animal
points
actually
are.
C
C
A
A
D
C
D
B
E
So,
okay,
if
I
can
add
here,
I
think
that
when
we
talked
about
this
in
the
meeting
it
seemed,
it
seemed
like
pretty
clear
that
we
wanted
to
reduce
we're
actually
discussing
some
other
draft
first
and
then
discuss
this
draft,
and
then
we
support
this
was
a
good
idea
in
reducing
the
the
sizes
and
the
scope
of
the
document.
Now
with
when
we
discuss
this
now,
people
seem
not
equally
convinced
that
this
is
the
right
way
to
go.
B
C
B
C
C
Would
need
to
be
updated
each
time
we
we
pull
in
new
algorithms
and
so
on.
So
it's
kind
of
a
different
style
of
document
than
the
protocol
documents
which
agile
by
their
nature.
So
it
may
make
sense
to
separate
the
documents.
Just
from
that
point
of
view
that
it's
it's
easier
to
update
the
limits
discussion.
If
we
don't
have
to
update
the
the
protocol
documents
and
vice
versa,.
E
To
add
to
that,
I
think
that
the
limits
discussion
is
not
concluded
and
we
don't
really
know
what
the
conclusion
will
be.
We
are
referencing
the
cfrd
draft.
That's
not
has
not
passed
working
group
last
call
and
right
expect.
It
will
be
further
discussion
on
that
before
that's
finished.
So
that's
also
a
good
thing
too.
B
Separate
them,
for
that
reason
right,
that's.
We
need
to
follow
that
CPD
document
and
of
course
there
may
be
updates
there
that
that
end
up
happening.
Then
we
should
follow
along
with
updated
formulas
or
otherwise.
Yes,
true,
so
then
there
are
then,
those
two
benefits
of
splitting
out
the
limits
about.
Yes,.
B
B
B
But
yeah
so,
of
course,
just
feel
free
to
to
give
any
further
feedback
on
the
on
the
mailing
list,
or
otherwise.
I
will
go
to
this
last
point
then.
So
this
is
about
introducing
ad
hoc
EAD
items
for
signal
in
Kudos
support.
So
the
point
is
that
we
could
register
an
ed
item
in
ad
hoc
that
is
used
for
signaling,
whether
other
players
approach,
Kudos
or
not,
then.
B
Essentially,
the
benefit
is
that
the
appear
will
learn
if
the
other
peers
support,
Kudos
and
which
modes
during
endoc
execution-
and
we
have
a
idea
for
semantic-
is
you
could
rely
on
four
different
values?
Basically,
one
to
Simply
say
that
okay
I
want
you,
the
other
player,
to
tell
me
what
you
support.
B
Other
value
would
be,
but
I
don't
support,
kudos
and
third,
one
would
be
I
support
kudos
in
both
modes
and
also
asking
the
other
player
to
indicate
what
did
support
and
the
fourth
value
would
be
okay,
I
support
Kudos,
but
only
in
the
no
FS
mode,
and
also
to
indicate
whether
the
player
to
say
what
it
supports
if
it
have
not
already
done
so
so
it
has
the
benefit
of
yeah
being
able
to
buy
a
network
execution.
You
can
exchange
these
information,
so
both
peers
would
know
what
other
parties
approach
and
there's
no
ambiguity.
B
So
the
question
is:
should
this
be
done
or
not?
I
saw
Christian
had
a
comment
also
in
the
chat.
Early
related
to
this
point
can
I
find
it
now.
It
was
I
think
he
was
saying
split,
it's
a
bit
moot,
because
the
conclusion
before
was
that
Kudos
works
well
in
opt-in
mode,
so
sure
this
functionality
is
not
really
speaking
necessary
because
within
Kudos
you
do
have
this
negotiation
or
simple
negotiation
to
learn
this
regardless
and
you
can
do
a
trial
and
error
attempt
to
run
Kudos.
E
A
E
Thanks
my
thoughts
here
are,
if
we're
going
to
do
this,
I
think
that
Christian's
point
is
good.
So
now
we're
really
going
in
in
we
sort
of
we
started
a
line,
a
train
of
thought
here
and
we're
going
in
that
direction,
and
that
makes
sense
so
that
Kudos
already
is
can
can
be
opt-in.
So
that's
nice,
The,
Other
Extreme,
is
that
and
we
have
any
idea
item
which
is
actually
not
only
telling
you
whether
you
support
Kudos,
but
also
whether
you
will
use
adoky
update,
which
we
already
sort
of
taken
out.
B
Now,
but
that's
true,
there
could
be
I
mean
that's
also
something
we
were
thinking
about
in
terms
of
The
Advocate
update.
If
we
wanted
to
keep
that
around
it
would
it
would
need
some
kind
of
signaling
either
yeah
within
an
EAD
item,
or
even
maybe
even
actually,
signaling
within
the
Proto
within
the
Kudos
execution
itself,
because
you
may
need
to
on
some
Curious
executions.
Can
you
use
Adobe
update,
but
in
others
you
can't
right
so
having
a
even
an
ID
item
may
not
be
significant.
E
Okay,
so
that's
that's.
That's
a
good
point.
My
main
concern.
How
now
that
we've
taken
out
is
from
the
Kudos
execution
is
actually.
How
are
we
going
to
invoke
Advocate
updates
I
mean
we
haven't.
We
have
specified
the
the
function,
but
we
haven't
specified
how
it's
used.
That
might
be
a
problem
for
ad
hoc
rather
than
for
oscore,
but
it's
still
something.
E
B
B
A
I
just
wanted
to
remind
the
reason
why
we
started
to
think
about
removing
method,
one
actually,
the
fact
that
both
peers
support
it
by
by
learning
about
that
in
advance
or
by
trial
and
error
is
not
sufficient
to
actually
run
that
method
based
on
a
low-key
update.
The
the
edoc
session
established
back
then
also
still
has
to
be
valid,
whatever
valid
really
means
and
has
to
be
defined.
A
Document
I
think,
if
that's
not
the
case,
then
the
peers
have
to
go
also
in
this
case
for
an
agreed
fallback
and
that's
where
we
started
to
think
okay,
but
it
mattered
you
and
would
always
work,
then,
and
and
is
not
worse
in
terms
of
security.
Why
not
keeping
methods
you
alone
anyway,
and
that's
when
we
started
to
think
okay?
Maybe
we
can
forget
about
method,
one.
B
E
B
Yeah
the
point
like
Norco
said:
if
this
is
a
like
a
pure
simplification,
and
we
remove
that
okay
update
without
loss
of
any
with
having
the
same
functionality
with
that
doc,
with
the
hdf
extract
and
expand
and
also
security
properties.
Then
it's
simplification
in
terms
of
code
and
avoiding
this
negotiation
thing.
We
probably
have
to
introduce
the
hooky
boat
methods.
B
And
yeah,
probably
again
like
having
an
ed
item,
for
that
is
it's
not
enough
because
it
doesn't
help.
If
you
know
you
it's
not
enough,
just
to
know
what,
once
you
have
to
be
able
to
decide
for
every
execution,
because
what
if
you're
at
accession
became
invalid
due
to
for
some
reason
like
some
certificate,
expire
or
or
other
reasons,
then
practically
you
shouldn't
use
at
the
Caps.
You
need
to
be
able
to
signal
for
each
curious
execution
whether
you
want
to
send
a
key
update
or
the
hqdf
variant.
B
Yeah,
but
to
summarize
this
final
point
this
again,
the
question
here
is
yeah:
should
we
register
DC
the
item
in
edoc
and
again
it's
not
unnecessary
for
kudos
to
function.
It
is
so
nice
to
have
because
it
helps
the
players
learn
about
this
ahead
of
time
and
again
there's
then
they
know
for
sure
100
and
they
never
have
to.
A
B
B
B
A
A
A
One
was
an
indeed
group
comproxy,
where
you
have
a
proxy
taking
a
request
from
a
client
and
is
supposed
to
identify
the
client
through
a
secure
Association
before
forwarding
that
request
to
a
group
of
servers.
There's
a
similar
use
case
related
to
group
communication,
where
the
server
sends
back
notifications
over
multicast,
and
if
there
is
a
proxy
and
group
of
score,
is
used
end-to-end.
A
And
then
we
mostly
had
a
lot
of
time
to
in
related
use
case
where,
from
the
transport
binding
specification,
the
lightweight
endpoint
client
can
well
not
only
talk
to
the
light
effect
from
server
as
part
of
internal
exchanges
as
usual,
but
also
at
the
same
time,
use
the
lightning
server
as
a
proxy
to
talk
to
an
external
application
server,
and
that
external
exchange
can
also
be
a
protected
end-to-end
with
Oscar.
Again,
there
are
more
use
cases
on
the
draft,
but
these
have
always
been
the
the
main
ones.
A
A
With
this
in
mind,
we
took
the
opportunity
to
revise
a
bit
some
terminology,
especially
For
What
concern
what
we
call
a
proxy
related
options.
We
used
to
have
only
the
first
two
entries.
We
added
a
third
one,
so
Ur
iPad
options
present
not
together
with
proxy
skin,
which
is
basically
what
happens
if
you
are
trying
to
to
perform
a
sort
of
reverse
proxy.
A
A
But
it's
not
important
to
be
seen
already
during
any
processing
before
decryption
or
in
order
to
perform
the
decryption
itself,
and
this
is
really
typically
about
options
for
proxies
to
be
protected
when
you
are
using
oscore
to
protect
the
message
for
the
proxy.
There
are
more
examples
that
than
these
ones,
but
I
just
shown
the
one
we
are
reporting
in
the
draft.
A
Considering
the
two
points
put
together,
we
also
Revisited
the
message
processing,
but
actually
only
for
for
the
incoming
requests,
because
any
other
processing
is
as
it
was
in
in
the
first
version.
Basically
well
for
incoming
requests.
We
required
a
bit
more
of
engineering
and
we
were
actually
able
to
do
some
simplification,
especially
following
the
the
improved
definition
of
options
to
be
protected
anyway,
but
we
also
needed
to
add
an
additional
sub
step
again
to
cover
the
case
of
reverse
proxy
justified
by
the
use
case
from
David.
A
And
if
you
remember
from
the
first
versions,
this
processing
was
supposed
to
be
about
three
Alternatives
absc
and
the
endpoint
had
to
to
choose
which
one
was
applying
at
present.
We
slightly
present
now
in
a
different
way
as
three
steps,
including
the
possible
jumping
forward
or
or
looping
back,
and
it
is
really
about
looking
at
the
message.
You
have
at
your
hands
right
now
and
deciding
first
of
all,
if
that's
about
proxy
or
not,
if
it's
about
proxying
well,
consume
the
proxy
options
and
forward.
Otherwise
it's
about
consuming
the
application.
A
Is
this
about
proxy
or
not
based
on
the
visible
presence
of
some
options
about
proxy
and
it's
the
only
box
in
light
blue,
so
simplifying
things
a
bit
here?
If
it
is
about
proxying,
you
get
into
the
light
yellow
territory,
you
check
the
details,
other
than
error
handling,
not
shown
here
for
Simplicity.
If
you
conclude,
this
is
indeed
about
proxy
and
everything
is
fine.
You
forward
and
you're
done,
the
processing
ends.
If
it's
not
about
proxying.
Well,
you
check
for
the
presence
of
an
Oscar
option.
A
If
there
is
none,
you
are
the
original
endpoint
you
deliver
to
the
application.
If
there
is
an
Oscar
option
other
than
a
corner
case
for
your
handling.
Well,
do
what
dios
corruption
says
the
Crypt
accordingly
take
your
result
and
start
again,
so
you
will
eventually
end
because
either
you
are
consuming
at
your
application
or
because
you
are
forwarding
and
in
the
process
you
may
end
up
stripping
one
or
more
Oscar
layers
in
the
backup,
slides,
there's
a
slightly
extended
version
of
this
one,
with
more
boxes
for
error
handling.
Okay,.
D
I'm
I'm
just
looking
up
at
the
at
the
at
the
backup
slides,
but
it
doesn't
say
that
there
either
I
think
one
important
aspect
to
consider
of
foreign
for
the
document
is
before
forwarding
to
check
whether
the
sender
is
also
whether
the
sender
is
authorized
to
be
proxied
and
that
authorization
might
typically
come
from
the
request
not
originating
just
from
the
network
stack
on
the
left
from
the
white
circle.
But
from
having
been
decrypted
from
a
particular
context.
And
that
is
what
authorizes
the
forwarding.
A
A
Okay,
so
I
hope
we
can
have
one
day
and
ask
you
base
art
along
these
lines,
but
this
should
be
helpful
already
right.
We
added
an
appendix
with
a
message.
Exchange
example:
I
think
the
first
one
is
the
most
relevant
one
really
also
reported
here
when
you
use
Oscar,
both
end-to-end
and
also
between
the
client
and
the
proxy.
A
We
show
how
those
are
established
at
runtime,
using
using
edoc
so
first
between
client
and
proxy
and
then
end-to-end
between
client
and
server
through
the
proxy
protecting
the
like
between
client
and
proxy
already
with
oscore
yeah.
We
also
added
a
sectional
cachability
of
responses.
Simply
simply,
and
explaining
and
hopefully
convincing
that
that's
possible
in
this
case
too,
basically
using
the
approach
defined
in
the
cachable
score
document
that
doesn't
require
any
adaptation
or
extension
whatsoever.
A
That,
for
now
is
just
a
list
of
a
very
raw
bullet
points,
so
not
really
a
readable
section,
but
all
the
raw
content
should
be
there
and
basically,
what
they
find
in
the
document
body
is
a
set
of
building
blocks
that
can
be
used
to
to
build
something
quite
similar
to
Thor,
but
using
using
Oscar
instead.
I
think
we
need
to
mature
this
content
quite
a
bit
to
make
it
an
actual
section
in
the
first
place
for
later
on.
A
So
yeah
I
think
I've
gone
pretty
much
through
everything.
This
document
is
about.
We
are
not
done
yet.
We
have
a
number
of
next
steps
summarized
here,
related
to
Corner
cases
and
guidelines
on
the
establishment,
there's
an
ongoing
proposal
and
open
NPR
in
group
of
score
related
to
improving
some
handling
of
responses.
That
I
believe
will
have
an
impact
here
too,
to
extend
the
handling
on
the
incoming
responses
consistently.
A
Also
in
this
case-
and
we
plan
to
add
more
examples
in
particular,
for
when
edoc
is
used
with
the
optimized
workflow,
to
establish
the
context-
and
at
least
one
example
where
a
reverse
proxy
is
used
in
the
spirit
of
David's
use
case,
and
we've
also
started
to
look
at
the
Chic
compression
framework
and
especially
its
profile
for
Co-Op.
That
covers
also
the
usable
score
if
it
can
be
used
here
and
I.
A
Think
yes,
and
if
it
needs
some
adaptation
to
be
used
in
in
a
situation
where
you
protect
the
message
multiple
times
and
I,
think
it
needs
some
of
the
caption.
But
we
have
just
started
to
look
into
that
and
we
need
more
work
regardless.
We
think
the
core
mechanics
in
this
version
is
quite
stable
and
that's
especially
thanks
to
feedback.
A
E
D
If
I'm
in
Germany,
the
onion
is
The
Onion
work
is
not
not
so
much
part
of
what
I
did
with
tank.
This
is
this
is
this
is
really.
This
is
mainly
a
sketch.
This
is
about
hey
we
by
by
having
all
this
proxying
and
having
the
ability
to
Nest
or
score.
We
get
just
so
many
properties
that
that,
on
that
tool,
works
really
hard
for
possibly
for
free,
and
that's
the
reason
to
to
explore
this.
E
D
A
D
I
didn't
upload
any
slides,
because
I
was
a
bit
short
in
time
and
then
got
stuck
in
a
traffic
jam,
but
what
I'd
like
to
do
is
just
to
yes.
I
really
want
to
share
my
screen
so
now
I
just
have
to
so.
Basically
what
I,
what
I'm
screen
sharing
is
really
just
the
the
the
the
the
notes,
but
it
still
happens
to
be
practical
to
be
convenient
here
just
before
before
I
get
right
into
the
details,
I'm
summarizing.
What
this
is
about?
D
The
same
is
true
for
applications
on
on
cell
phones
and
especially
from
on
browsers
and
cell
phones,
because
they
might
be
able
they
might
have
the
physical
links.
They
would
need
the
physical
means
to
establish
a
link
to
say
a
co-op
enabled
sensor
that
has
Bluetooth
radio,
but
the
operating
system
and
the
browser
and
the
basic.
Basically,
the
whole.
D
So
this
would
enable
applications
such
as
having
having
a
website
be,
maybe
even
in
casual
local
application
on
your
cell
phone.
You
approach
a
device
that
is,
that
has
that
is
Bluetooth
enabled
and
you
can
use
all
your
security
contacts.
Like
is
the
whole
stack,
but
you
would
usually
use
to
connect
to
that
device
through
some
routing
infrastructure
to
interact
with
that
device
locally.
D
D
The
message
ID
participating
in
the
reliability
and
in
in
accounting
for
repeat
for
for
repetition,
message,
loss
and
the
token
for
matching
requests
and
response,
because
I
didn't
mention
this
here,
because
it's
not
different
but
UDP
doesn't
give
us
any
matching
request
response.
So
we
use
tokens
and
then
the
rest
is
in
in
the
the
rest
is
basically
the
the
tail
of
a
co-op
Co-op
method,
as
it
is
in
all
zero
relations.
D
Now
with
cat,
we
have
vastly
different
base,
so
the
communication
between
the
the
Gap
server
and
the
gut
client,
or
between
the
Bluetooth
Central
and
the
Bluetooth
peripheral,
both
of
which
rows
are
independent
but
I,
think
it
makes
sense
to
use
the
gut
server.
The
peripheral,
which
is
the
constraint
device
as
the
gut
server
and
the
central
as
the
gut
client,
so
that
the
cell
phone
in
the
typical
scenario
initiates
initiates
the
the
request
that
communication
is
strictly
ordered.
D
There
is
no
danger
of
mistake
of
mistaking
a
message
to
be
repeated.
It
is
connected,
so
a
loss
of
connection
and
complete
reconnect
are
detected,
and
there
is
this
very
weird
situation
that
we
have
unidirectional
reliability.
That
means
that
the
the
Gap,
the
gut
client,
so
the
cell
phone
can
know
that
this
operation
completed
and
that
there
are
lower
layers
that
will
keep
retrying.
D
So
what
I'm
working
on
for
Dasher
2
is
that
we
that
we
do
go
back
to
using
tokens
and
I
hope
I
did
get
the
numbers
right
and
the
most
recent
one
is
actually
is
to
actually
use
tokens
and
to
use
those
that
that
nibble,
that
is
unused
in
front
of
that
in
order
to
do
a
very
minimal
version
of
message
of
the
message
IDs
in
Google
UDP.
Our
message
IDs
are
16-bit
because
we
might
have
a
lot
of
messages
in
the
year
here.
D
It's
deviating
a
lot
from
what
we
have
on
corporate
VDP,
but
I
think
it's
saving
some
things
and
it's
just
making
good
use
of
the
properties.
We
have
on
that
particular
transport
versus
trying
to
force
identical
behavior
when
the
underlying
transport
is
not
behaving
identically
and
yeah.
I
think
it's
a
good
direction
to
go,
but
I
would
be
happy
to
get
some
feedback
from
the
group
on
on
well
with
whether
you
do
it
differently.