►
From YouTube: IETF108-EMU-20200731-1300
Description
EMU meeting session at IETF108
2020/07/31 1300
https://datatracker.ietf.org/meeting/108/proceedings/
A
A
B
A
Yeah,
so
we
do
have
a
packed
agenda
today,
so
please
keep
your
presentations
on
track
and
comments
on
at
the
mic.
Kind
of
briefing
to
the
point
would
be
great.
Here's
the
note.
Well,
you
should
all
be
familiar
with
this
by
now,
but
we'll
put
it
up
here
for
just
another
10
seconds,
so
you
can
get
a
good
look
at
it
all
right.
A
A
C
C
So
when
we
started
writing
this
first
version
of
the
specification
in
2016,
we
looked
at
the
json
c-bor,
which
was
relatively
new
at
the
time
and
asn
1
and
then
decided
to
go
with
json
because
of
the
availability
of
implementations,
basically
and
for
seabor.
At
the
time
there
were
not
so
many
implementations
and
the
specific
case
and
didn't
seem
to
cover
everything.
But
now
now
there
is
more
like
the
seabor
signatures
or
the
specification
which
has
the
max
hmax
as
well
so
kind
of
those
arguments
about
functionality
and
implementations
there.
C
C
So
one
reason
for
us
to
use
json
was
that
wpa's
applicant,
which
is
the
linux
implementation
of
the
that
has
a
json,
encoder
and
parser
built
in,
and
we
didn't
want
to
add
new
libraries
to
that.
So
try
to
suggest
new
libraries
to
wpa
supplicant,
okay.
So
now
there's
a
question
of
whether
the
seabor
is
the
new
big
thing
and-
and
everyone
should
jump
to
that
and.
C
Then
I
just
want
to
note
that
this
will
cause
a
major
delay
to
the
specific
case
and
which
is
kind
of
close
to
ready
and
and
there's
now.
As
far
as
you
know,
complete
implementation
of
the
current
specification,
it
would
require
updates
to
the
specification
and
lots
of
proofreading
and
implementation
and
testing.
C
There
is
one
aspect
that
I
just
today
posted
to
the
mailing
list.
That
has
been
my
kind
of
biggest
concern
about
these
encodings
and
it
is
the
lack
of
canonical
encoding,
which,
which
makes
it
difficult
to
verify.
Hmax
or
compute
them
create
an
unambiguous
input
to
an
hmac.
So
we
receive
some
messages
with
message
fields
we
want
to
take
some
of
those
fields,
combine
them
into
a
new
structure
that
is
then
of
which
we
compute
an
hmac
or
a
hash
function,
and
well
without
the
canonical
encoding.
D
C
A
third
option
that
that
just
occurred
to
me
is
that
if
we
had
this
nested
object
structures
we
could
possibly
use
that
now,
karsten
pointed
out
is
on
the
queue
like
you
see.
He
pointed
out
on
the
mailing
list
that
seabor
has
this
deterministic
encoding
rules
and
to
me
that
seems
more
like
a
tool
kit
that
I
can
use
to
define
my
own
deterministic
encoding
or
not.
It's
not
like
one
canonical
encoding
that
every
implementation
will
support.
So
I
just
wonder
if
that
actually
will
will
help
here.
C
D
D
What
choice
should
be
taken
so,
but
for
many
applications,
the
the
the
whole
thing
reduces
to
pointing
to
these
rules
and
then
saying
do
that
and
then
we
have
it.
8152
actually
goes
one
step
further
and
avoids
maps
maps.
Have
this
ordering
ambiguity
so
they
have
a
even
simpler
form
of
deterministic
encoding.
They
need
fewer
rules,
but
you
don't
need
to
do
that.
D
C
C
D
So
in
your
sibo
you,
you
have
a
place
where
you
say:
here's
a
byte
string
and
the
byte
that
byte
string
in
turn
is
sibo,
but
you
kind
of
delay
the
the
decoding
of
that
subpart
by
putting
it
into
a
byte
string.
So
your
application
gets
the
whole
byte
string
and
can
send
back
that
whole
byte
string
without
making
any
changes
to
the
encoding.
So
you
don't
need
deterministic
encoding
for
those
parts.
D
D
My
implementation
of
canonical
that
I
use
every
day
actually
works
by
rearranging
the
data
in
such
a
way
that
my
my
encoder
simply
produces
the
right
encoding.
That's,
of
course,
not
something
that
every
implementation
will
be
able
to
do,
because
your
platform
may
have
no
way
at
all
of
ordering
maps
so
yeah
you,
you
actually
have
to
look
for
an
implementation
that
can
does
that.
But
it's
it's
not
not
like
it's
right,
yeah,
impossible.
C
C
C
There
was
a
very
nice
review
by
dave
taylor,
where
he
really
kind
of
found
some
marginal
parts
of
the
specification
that
we're
not
clear,
and
we
added
some
explanations
and
then
also
change
some
maze
to
must
where
it
there
was
no
particular
reason
to
to.
You
know
kind
of
from
the
point
of
view
that
anything
that
is
me
or
just
recommended,
then
we
don't
expect
it
to
be
implemented
in
many
cases
and
also
like
character.
C
But
I
don't
want
to
include
in
this
specific
case
and
those
because
I
don't
want
to
speculate
at
this
time
about
who
will
use
eap
new
once
we
know
some
applications,
then
we
can
define
the
contents
of
those.
Otherwise,
we
would
be
writing
pages
and
pages
of
device
description
specifications
without
knowing
what,
whether
that
such
devices
will
ever
exist,
and
they
might
be
completely
the
wrong
type.
C
Okay
and
the
next
page.
So
hannes
also
did
a
review,
and
this
was
more
on
the
the
questions
may
on
the
level
of
what
is
the
purpose
of
the
documents.
What
assumptions
we
are
making
and
I've
tried
my
best
to
to
clarify
those
parts,
especially
the
discussion
on
cloning,
where
we
also
now
pointing
to
to
this
honesty's
token
specification
and
and
actually
also
dave's,.
C
That
is,
that
is,
I
think,
all
we
need
to
talk
about
here.
The
other
things
you
can
see
in
the
notes
about
the
implementation
that
we
now
have
max,
who
was
working
the
time
at
ericsson,
did
a
kind
of
more
complete
implementation
of
the
current
draft,
so
it
should
be
up
to
date,
and
we
have
managed
managed
to
compare
between
two
implementations
update
message.
Examples
in
the
draft
which
is
nice
to
know
that
they
are
correct
at
the
moment
and
possibly
will
I
hope,
to
merge
that
back
to
the
university.
B
Hi,
I
don't
know
if
you
can
open
the
google
doc
itself
and
I
can
just
start
by
saying
what's
the
problem
so
basically
the
heap
in
tls,
the
servers
can
send
any
number
of
both
handshake
messages,
and
this
is
this
is
where
they
send
resumption
psks
that
are
later
used
for
what
is
called
fast,
free
authentication
and,
and
the
problem
was
that
you
can
in
eep.
You
can't
leave
the
peer
in
this
unconditional
state
where
it
doesn't
really
know
like.
B
Are
there
going
to
be
more
post
handshake
messages,
because
the
tls
tunnel
is
eventually
torn
down,
unlike
the
web
use
of
of
tls,
and
we
had
early
on
in
the
draft
introduced
a
commitment
message
which
basically
allows
the
server
to
tell
that?
Okay,
I
am
done.
These
are
all
the
post
handshake
messages
I
wanted
to
send
and
it's
time
to
move
on,
and
and
basically
this
handshake
message
was
governed
based
on
on
what
the
libraries
currently
support,
specifically
open,
ssl
and,
as
you
see
on
in
the
text.
B
This
is
this
is
the
text
that
we
have
currently
in
the
draft,
but
this
caused
some
confusion
to
people
on
the
list,
including
hardness,
and
so
on
that
initially
it
felt
that
this
one
byte
of
application
data
was
unencrypted,
which
is
not
the
case.
So
it's
basically
when
you
encrypt
the
one
byte
of
zeros,
which
is
the
indication
of
this
commitment
message.
The
encrypted
data
is
obviously
larger.
B
I
don't
know
if
someone
else
wants
to
chime
in
on
how
to
edit
this
text
to
make
it
more
clear
or
precise,
because
this
is
the
only
thing
that
kind
of
remains
otherwise.
The
document
has
passed
working
group
last
call
and
has
was
our
ad
roman
did
a
review
and
I
fixed
the
issue.
So
this
is
pretty
much
the
only
thing
that
is
now
blocking
it.
B
F
F
F
G
B
B
G
G
H
A
E
Yeah,
but
I
mean
I
guess
talking
about
what
kind
of
messages
you're
not
prepared
to
handle
in
phase
two:
you
can
have
like
new
session
ticket
or
you
can
have
key
update,
or
you
can
have
anything
that
we
define
in
the
future
and
a
new
session
ticket.
You
can
just
drop,
but
a
key
update.
You
kind
of
can
also
drop,
but
it
may
not
be
a
good
idea
and
you
know
the
other
stuff
in
the
future.
Of
course
we
don't
know
about
yet.
H
H
E
A
B
It
would
just
have
required
and
like
because
now
we
are
sending
the
the
commitment
message
with
the
server
tls
finished
and
and
then
the
client
sends
the
tls
finished
and
and
then
we
send
the
success,
whereas
if
it
was
sent
after
the
client
tls
finished,
it
would
have
required
another
round
trip.
That's
what
I
remember
as
of
now,
but
I
am
happy
to
receive
more
feedback
on
this
from
maker
ben.
Please
do
that.
A
I
B
G
G
So
it's
like
ben
seems
definitely
concerned
about
this
specif
about
the
semantics.
The
message
like,
I
don't
understand
the
situation
enough
to
comment
on
the
semantics
of
the
message,
but
ben
says
just
concerns
about
that,
but
I
was
just
like
talking
about
like
which
bits
you
send.
So
I
agree
that
I
agree
that,
if
the
bit,
if
the
situation
is
as
jim
says
then
like
the
bits
I
suggested
won't
work
so
so
so
like.
I
A
F
George
had
a
good
review
of
all
the
different
heap
types
and
I've
gone
over
his
comments
and
the
various
specifications
and
updated
the
document
to
address
those.
It
now
references
the
public,
microsoft
documentation
for
peep,
and
we
have
interoperability
between
a
number
of
implementations
for
tls,
ttls
and
peep,
not
so
much
for
fast
and
deep,
but
we're
hopeful
there.
B
If,
if
if,
if
some
implementation
of
team
is
going
to
move
to
tls
1.3,
it's
not
just
the
key
derivations
that
is
going
to
change
like
how
is
the
pack
sent
for
assumption,
and
then
there
are
various
places
in
the
deep
specification,
for
example
like
you're
supposed
to
do
something
after
this
server
finish
handshake
message
so
so
on
and
so
on
in
phase
two,
how
about
all
those
changes?
So
it
would
be
the
case
that
we
are
defining
the
key
derivation
here,
but
then
leaving
out
a
lot
of
things
which
are
kind
of
unknown.
F
E
Sense,
hi
hi
again,
hey
hi
alan
thanks
for
the
update
the
my
thinking
about
the
the
chief
work
is,
first
of
all,
it's
really
slow
going
like
literally
I'm
slogging
through
a
bunch
of
stuff.
We
have
a
guy
who's
working
on
it
on
our
side
and
and
oleg
is
going
to
speak
to
this
later
too.
The
reason
to
not
mention
heat
in
that
draft
other
than
to
say
something
like
teep
is
going.
It
will
be
covered
elsewhere.
You
just
don't
want
to
create
a
normative
block
on
it.
E
That's
all
so
just
I
wouldn't
normatively
block
your
draft
on
that.
If
you're
going
to
move
the
t,
if
you're
going
to
push
the
tv
stuff
to
the
stuff
that
we're
doing-
and
you
know
it's
going
to
be
a
while-
I
think
before
a
real,
full
teep
update-
is
done.
Like
there's
a
lot
of
work
to
be
done.
I
think
okay.
E
J
J
B
J
J
J
J
Maybe
it's
worth
to
add
that,
after
together
with
sending
intermediate
results,
you'll
be
after
basic
password
authentication,
we
also
must
send
crypto
binding
tlb.
Nevertheless,
it
only
can
use
the
zero
msk,
because
there
is
no.
It
is
not
an
inner
method.
So
there
is
no
inner
methods,
cryptographic
material
to
derive
keys
from.
B
B
J
J
J
Okay,
this
is
just
a
clarification
about
sending
that
sending
intermediate
results
you'll
be
in
basic
password
authentication
is
must
so.
This
is
just
adding
a
few
words
that
we
have
to
send
intermediate
result
till
the
after
basic
password
authentication,
and
whenever
inner
method
is
mentioned,
we
are
just
adding
mentioning
also
basic
password
authentication,
because
it
it
is
under
the
same
rules
as
the
inner.
J
This
is
continuation
of
the
previous
rata
item.
We
also
need
to
fix
the
example
of
basic
password
authentication
with
two
examples
of
successful
and
failed
basic
password
authentication.
They
currently
don't
have
intermediate
results
early,
so
we
just
add
in
the
intermediate
results:
we
send
them
in
both
of
them
in
the
appendix
section.
J
J
So
it
was
decided
to
specify
exactly
the
the
one
byte
chip
type
just
to
make
it
clear
and
avoid
confusion,
and
I
also
suggest
to
put
the
explanation
that
we
got
in
our
discussions
why
this
is
present
here,
because
it
helps
to
protect
against
cross-protocol
attacks.
If
cryptobinding
tv
was
reused,
means
crypto,
binary
was
reused
from
it
fast
protocol
or
maybe
p
protocol.
So
if
we
put
exactly
the
chip
type
here,
we
are
just
preventing
the
reusing
of
cryptobiontilly
from
other
protocols.
B
Every
time
you
calculate
this
compound
mac,
I
guess
you
can
run
several
leap
methods
inside
and
every
time
you're
calculating
this
compound
mac,
and
I
thought
it
was
the
e
type
of
whatever
was
running
inside
that
was
being
included
in
this
calculation.
But
I'm
not
deep
expert,
so
just
trying
to
make
sure
that
indeed
it
was
the
case
that
it
it
was
trying
to
refer
to
the
type
of
the
outer
method
and
not
the
inner
methods
that
were
then
going
to
run.
J
A
J
J
J
J
So
we
need
to
keep
all
the
key
derivation
for
boss
in
their
method,
msk
and
emsk,
and
then
after
we
all
know
what
was
selected
msk
as
a
source
of
all
the
key
derivation
or
msk.
We
use
the
specific
keys,
the
cmk
derived
from
msk
and
cmk
drive
from
msk,
and
so
on.
This
this
makes
makes
the
fix
like
on
the
slide,
makes
this
very
clear.