►
From YouTube: IETF105-EMU-20190724-1330
Description
EMU meeting session at IETF105
2019/07/24 1330
https://datatracker.ietf.org/meeting/105/proceedings/
A
Up-Gunned
I'm
going
to
do
that.
So
everybody
seen
the
note
well,
yet
anybody
not
see
the
note
well
yet
I
didn't
think
so
all
right.
So
we
have
a
pretty
packed
agenda
today
with
lots
of
excitement
discussing
some
working
group
documents
going
through
some
errata
and
then
a
couple
of
new
items,
including
some
discussion
about
reach
ordering
for
some
additional
items.
A
C
C
D
Yeah,
do
you
hear
me
yeah?
We
can
hear
em
great
yeah.
Yes,
didn't
know
how
to
end
the
presentation
mode
so
yeah
we
removed
all
the
text
about
other
TLS
based
method.
According
to
the
decision
last
meeting,
this
should
move
to
a
separate
draft,
probably
dropped
the
cookie
mu
till
SCP
types
that
will
be
discussed
later.
D
We
added
reference
to
draw
the
idft
as
old
versions.
This
is
a
draft
in
the
TLS
working
group
that
is
updating
or
fc5
t16
and
prohibits
use
and
negotiation
of
TLS
1.0
and
1
TLS
1.2
bomb.
So
this
the
TLS
103
draft
now
reference
that
and
describes
this
update.
It
also
slightly
changed
the
language
in
the
text
to
not
refer
to
TLS
102
or
earlier,
as
they
are
or
soon
will
be
forbidden
to
negotiate
in
any
use
of
TLS.
D
D
There
are
several
changes
based
on
the
review
by
yim,
shot.
I
think
there
is
nothing
major,
there's
some
editorial
recordings
and
there
are
some
technical
rewording
changing
from
what
not
to
do
to.
Instead
what
to
do
and
then
there
are
updated
requirements
on
the
ll
be
tested
by
Oleg
and
what
was
decided
was
to
decide
what
to
do
but
to
be
flexible
in
what
clients
and
servers
accept.
D
As
you
could
see
on
the
last
lurid,
the
TLS
103
allows
you
to
send
this
in
two
different
ways:
either
with
the
and
the
problems
here
is
that
open
SSL
does
not
support
everything
in
TLS
103.
It
does
not
support
you
to
send
completely
empty
TLS
record,
and
it
also
it
does
not
currently
support
the
server
sending
early
application
data
without
an
ex
declined.
First,
a
sent
an
extension,
so
this
needs
to
be
sold
somehow
and
also
think
we
can
go
to
the
next
slide
and
then
Joni
also
had
more
editorial
comments.
D
That
needs
to
be
changed
that
the
language
it's
not
really
empty
and
we
should
change
it
to
a
better
technical
description
and
also
that
there's
slightly
different
wording
in
the
text
and
the
figures
that
should
be
fixed
but
they're,
two
problems
that
we
need
today.
Decisions
on
and
Joanie
and
Alan
had
quite
good
discussion
on
the
list.
So
the
first
problem
is
that
OpenSSL
1.1.1
does
not
support
an
empty
empty
string
to
be
sent
as
application
data
Jonas
just
use
one
byte
with
zeros
instead
and
I.
D
Think
Ireland
agreed
that
that
was
a
good
and
there
is
what
needs
to
be
decided
here
in
the
group
is:
do
we
go
with
this
approach
and
then
do
we
go
with
a
single
solution,
or
do
we
allow
the
current
to
or
in
Surbiton,
to
send
several
the
server
to
some
different
things
and
also
what?
How
should
the
client
react
if
the
server
some
something
unexpected?
Should
it
ignore
it
or
him
so
I
think
it
would
be
boarding?
D
C
Anything
else
I
think
there
was
some
some
comment
on
the
list
saying
that
perhaps
that
could
indicate
that
there
is
other
post
handshake
messages
that
that
the
server
is
trying
to
send
I
think
it
makes
the
implementation
more
complex,
because
now
you
are
in
this
state
that
there
may
be
more
messages
coming
so
I,
I
I
would
prefer
to
keep
this
more
strict
than
just
say
that
once
you
are
done,
send
this
one
byte
of
zero
is
to
say
that.
Okay,
that's
the
end
of
the
handshake.
D
So,
let's
try
to
update
a
draft
with
this.
If
you
have
any
further
comments
on
the
list
as
soon
as
possible,
then
the
second
problem
we
need
to
discuss
is
that
open
SSL
does
not
support
the
server
to
send
early
application
data
to
a
unauthenticated
client
unless
the
client
has
sent
the
early
data
extension
and
the
client
has
send
early
data.
If
I
understand
the
comments
on
the
list.
D
D
E
Jim
shot
I,
don't
like
the
ideas
to
need
a
new
session
ticket,
because
the
server
may
not
actually
want
to
send
a
session
ticket
I.
Also,
don't
understand
why
you
think
this
is
a
problem,
because
in
the
OpenSSL
case
they
can
send
the
they
can
send
this
message.
After
the
quiet
authenticates,
they
just
have
to
send
a
send
a
data
record
which
says:
I'm
done
we're
not
going
to
do
anything
more.
It
doesn't
matter
whether
it
comes
before
or
after
the
client
authenticates.
D
E
E
D
D
I
think
so
that
seems
to
work
them.
We
make
it
optional
when
the
client
this
or
server
sends
this
application
data
to
signal.
It
will
not
sin
anymore.
Handshake
the
in
open
current
version,
openers
cell.
It
will
still
introduce
an
additional
round
trip,
but
the
server
does
not
need
to
to
send
a
new
session
ticket.
That
seems
good,
yep,
I,
agree.
I
will
send
the
I
will
send
to
the
list.
Summary
I
will
try
to
implement,
write
it
down
and
and
send
it
to
the
list
to
confirm
this
and
get
more
discussion.
A
D
D
D
Then
we
have
added
text
to
section
4.3
about
updating
authenticators.
This
section
existed,
but
it
was
empty,
and
this
basically
describes
the
reasons
why
authenticators
might
want
to
limit
the
amount
of
round-trips
packets
and
also
shortly
why
updating
existing
authenticators
is
hot,
and
this
text
is
quite
a
lot
up.
Based
on
the
discussion.
Comments.
Explanation
by
yoni
I
think
over
a
year
ago
on
the
mailing
list
and
the
formation
of
the
EMU.
That's
basically,
it
I
think
it's
in
a
good
shape,
quite
good
shape.
A
D
B
F
G
Likely
vendor
eat
methods
have
the
same
problem:
I
tried
pinging,
some
people
haven't
got
response,
so
I
suspect
most
of
the
vendor
eat
methods
are
dead.
At
this
point,
draft
has
minor
changes
from
zero,
zero
updates
to
eat
sim,
noting
that
there
may
be
a
varying
number
of
triplets
other
than
that.
There
hasn't
really
been
much
in
the
way
of
comments
or
negative
feedback,
but
I'll
wait.
C
Now
I
think
we
should
adopt
and
do
last
call
as
soon
as
possible.
I
had
one
other
comment:
can
we
change
the
title
because
now
it
says
session
ID
derivation
for
EEP
and
not
like?
Can
we
make
it
a
little
bit
more
specific
because
otherwise
it
feels
like
this?
Is
this
draft
defines
how
to
drive
session
ID
for
all
eat
methods?
Sure,
okay,.
A
So
we
had
some
discussion
on
the
list
a
while
back
beginning
of
this
year,
but
no
other
alternatives
have
been
proposed
for
this
work
item
in
general,
there
is
consensus
that
this
document
is
needed
and
should
move
forward
and
in
addition,
this
IPR
situation
isn't
any
different
than
what's
for
essentially
a
KN
aka
prime
and
the
document
is
targeted
for
an
informational
document.
So
my
proposal
is
that
we
accept
this
as
a
working
group
item.
Unless
there's
people
are
wanting
to
object.
H
I
Okay,
so
just
real
quick,
so
this
has
gone
through
working
group.
Last
call
and
there's
been
some
feedback
from
from
that,
as
well
as
feedback
from
various
IETF
and
3gpp
participants
and
as
well
as
importantly,
implementer
feedback,
and
so
we
published
a
new
verb
before
the
deadlines
and
and
that
new
version
has
a
few
sort
of
relatively
minor
changes.
I
We
had
in
the
security
considerations
to
XP
mistakenly
had
said
that
must
not
communicate
the
the
privacy
friendly
identifier
and
must
communicate
the
you
know
permanent
identity
of
the
user
and
that,
of
course,
it
was
exactly
the
other
way
around.
Fortunately,
that
was
said
the
correct
way
elsewhere
in
the
document,
not
in
the
security
considerations
part.
So
we
changed
that
that's
a
big
bug,
but
hopefully
people
understood
the
other
parts.
I
We
also
changed
because
we
were
sort
of
carefully
going
through
the
3gpp
specifications
and
the
idea
specifications
and
the
some
cases
for
like
what
do
you
need
to
do
in
you
know
when
you
receive
different
types
of
identifiers
requests.
You
know
in
a
5g
network
and
the
3gpp
language
talked
about.
You
know
you
shall
do
this
and
that,
and-
and
our
previous
text
was,
should
do
change
it
to
a
must
to
match
better
the
3gpp
language.
I
So
we
took
that
added
the
entries
that
belong
to
EI,
PA
K
Prime,
just
to
be
sort
of
crystal
clear.
You
know
what's
what's
needed
and
and
what's
not
so
there's
a
actually
two
attribute
tables,
depending
on
the
situation
that
you're
in
and
yeah
that's
at
least
I
personally
felt
that
that's
that's
useful.
There
were
some
attacks.
I
Of
course
I
mean
the
aka
protocol
receives
quite
a
lot
of
interest
from
the
academic
community,
so
different
side
to
security
problems
or
potential
problems
are
I
looked
at
over
and
a
couple
more
attacks
have
been
discussed
now
in
the
security
consideration,
sections,
including
what
the
impact
or
lack
thereof
might
be.
So
do
take
a
look
at
that.
I
There's
some
more
really
minor
things
we
just
you
know
made
absolutely
sure
that
we
say
what
to
do
with
the
length
field
calculations
or
we
say
things
more
explicitly.
Now
we
clarified
a
little
bit
the
language
around
the
80
KDF
negotiation
procedure,
as
well
as
what
to
do
in
the
case
of
the
synchronization
failure,
messages
and
and
at
80
KDF
attribute
and
then
a
hugely
controversial
change.
I
I'm
sure
we
moved
from
decimal
to
hexadecimal
for
the
e
type
values
just
to
make
sure
that
different
documents
are
in
line
with
each
other
and
then
some
reference
updates
and
editorial
clarification.
So
that's
that's!
Basically
it
people
have
any
particular
points
to
raise
here
about
these
changes
or
other
other
things
we
can.
We
can
have
some
discussion,
I.
Think
I,
don't
think
these
require
any
sort
of
re
process
in
the
in
the
working
group.
I
I
A
Uni
has
been
busy
working
on
a
cheap
implementation
apparently,
and
he
filed
some
errata
against
the
t,
p--
RFC,
so
there
was
already
exists.
There
were
some
existing
arad
already
there.
These
two
that
I
have
on
here.
What
I
want
to
try
to
do
is
go
through
some
of
these
here
and
see
if
anybody
has
any
opinions
on
them.
A
I
have
a
feeling
that
some
of
them
will
need
to
take
to
the
list
to
continue
well
continued
discussion
on
the
list
because
they're
a
little
bit
complicated,
but
these
first
errata
seem
pretty
straightforward
and
that
the
function
signature
for
the
TLS
PRF
was
represented
incorrectly,
and
so
these
are
just
as
pretty
straightforward
changes
that
were
reported.
These
were
reported
a
while
ago,
so
my
proposal
is
to
accept
these
changes.
Is
that
believe?
It's
just
a
you
know
a
kind
of
a
mistaken
in
that
function.
Signature.
A
G
A
A
L
A
C
L
A
A
There
were
some
confusion
as
to
the
intermediate
result
to
TLB,
and
you
only
proposed
a
you
know,
clarification
in
the
wording
here
and
clarifying
what
the
authentication
method
text
you
know
how
we
define
an
authentication
method
versus
a
non
authenticating
method,
so
each
identity
versus
a
method
that
performs
an
authentication
I
think
this
is
pretty
straightforward.
My
pearls
would
be
to
accept,
but
if
there
are
people
implementing
at
this
time,
I'd
like
to
you
know,
we
can
certainly
hold
off
until
the
implementations
implementers
come
back.
H
A
A
The
next
one
is
the
compound.
Mack
is
specified
as
20
bytes,
which
is
kind
of
fixed
to
this
length
of
sha-1
sha-1
is
no
longer
used
by
most
TLS
cipher
suites.
So
we
need
to
decide
what
to
do
here.
It
could
either
be
I.
Think
you
Oni
said
his
simple
fix
was
just
to
truncate
the
the
max
to
20
bytes,
it
seems
like
maybe
would
be
better
to
have
a
variable
length
Mac.
A
H
L
A
A
A
And
then,
finally,
what
to
do
if
there
is
no
key
generating
method
executed,
the
the
draft
does
not
specify
what
the
compound
Mack
key
is,
in
that
case,
what
CM
k0
and
so
presumably
there's
a
couple
options
here,
but
we
just
need
to
decide
which
one
it
is
and
then
do
that.
So
the
the
changes
here
or
could
you
know,
are
significant
in
that
they
do
in
fact
interoperability
and
implementations,
and
so
we'd
like
to
get
these
resolved
and
then
we
can
certainly
file
their
errata.
L
L
If
we're
going
to
open
up
that
document,
we
just
cram
our
stuff
into
that
then,
but
otherwise
we
just
do
it
as
each
extensions
and
I'm
I'm
sort
of
easy
as
to
how
we
go
about
that
right,
if,
whatever
whatever
they
were
working
for
plots,
I
think
the
real
question
is
whether
people
want
to
do
the
implementation
along
with
us
decreasing
stuff.
You
know
at
the
base
level,
oh.
G
This
is
a
lunch
that
will
follow
up
to
that
I
know.
My
next
document
talks
about
fixing
t4
TLS
1.3,
but
if
it
doesn't
sort
of
mostly
work
for
TLS
1.2
right
now,
I'd
be
more
than
happy
to
remove
that
text
from
the
document,
because
almost
I
have
no
idea
what
it
should
say
and
there
has
been
very
little
feedback,
so
I'm
happy
just
to
remove
that
push
it
off
to
a
tee
bids
or
T
updates
or
something
okay.
A
G
G
So
if
we
can
punt
on
that
specifically
for
teep,
that
makes
this
document
pretty
trivial
eat
fast.
I
fewer
opinions
on
that's
mostly
historical,
cisco
thing.
I
guess
the
question
for
cisco,
maybe
nancy
or
some
elliot
or
someone
else,
is
whether
you
have
opinions
on
this
and
what
should
be
done
or
perhaps
there
could
be
just
a
statement
saying:
yeah
I,
don't
use
eat
fast
with
TLS
1.3.
G
C
Sure
so,
over
the
last
couple
of
five
years
we
have
had
several
new
drafts,
which
don't
necessarily
are
unnecessarily
covered
by
by
the
existing
charter.
So
the
draft
that
Alan
presented
just
now
it's
somewhat
covered,
but
but
it
would
be
nice
to
clarify
the
charter
text
further.
We,
as
you
saw,
we
discussed
several
deep,
deep
aratus,
and
perhaps
it
would
make
sense
to
open
that
document
and
fix
those
things,
especially
if
people
are
implementing
it
so
perhaps
including
that
on
the
Charter
would
make
sense.
C
Also,
we
have
had
like
a
couple
of
drop
drawers
which
are
completely
out
of
the
current
charters.
One
has
been
this
OB
authentication
for
EEP,
which
is
draft
outer
loop
and
then
also
a
couple
of
drafts
that
try
to
try
to
do
things
where
you
start
with
certain
credentials
and
and
then
you
end
with
certain
other
types
of
credentials.
So
let's
say
you
start
with
certificates
that
are
put
by
one
guy
and
then,
after
you
run,
EEP
authentication.
C
G
G
It's
more
just
asking:
what
do
we
do
a
little
bit
right,
I
mean
allegedly,
if,
if
the
IETF
is
in
change,
control
for
eat
and
people
are
implementing
things
and
vaguely
sort
of
standardizing
them
that
finally,
the
various
RF
seeds
and
do
some
inventive
things
with
that
review?
The
question
is:
what
can
we
do?
What
should
we
do?
G
F
G
There's
so
as
background
there
there
was
some
work
in
3gpp
on
encrypted
MCS
in
sin
and
a
K
and
a
ka
prime.
That
work
is
now
continuing,
partly
outside
3gpp,
from
what
I
understand
and
and
doing
things
that
are
not
really
clear.
It's
it's
it's!
It's
not
clear
overall.
Even
to
me
why
this
kind
of
thing
is
happening
and
then
the
question
I
guess
is:
do
we
have
a
charter
item
to
work
with
people
to
get
review
before
these
things
get
standardized
outside
the
IETF
or
well?
C
Method
number
right,
IANA,
locates
them,
and
there
is
expert
review
for
for
doing
that,
and
there
is
no
requirement
that
all
the
methods
are
published
as
RFC
Schloss
I
counted.
There
are
52
EEP
methods,
perhaps
that
some
guy
we
could
provide
some
things
to
the
experts
that
when
they
are
doing
the
method
allocation,
no.
F
M
G
G
C
H
Romania,
to
reiterate
you
go
talk
to
people,
we
don't
need
to
change
the
Charter.
If
we're
going
to
formally
do
something
in
terms
of
producing
a
draft,
we
certainly
would
need
to,
and
we've
already
said,
liaison
statement.
So
we
have
license
to
the
right
organizations.
We
can
absolutely
find
those.
C
C
H
If
the
working
group
wants
to
kind
of
tackle
some
of
those
issues,
I
will
support
them.
Editorially
I
think
we
should
structure
those
work
items.
Similarly,
to
the
way
we
structure
the
other
work
items
unless
we're
rewriting
the
text
of
them,
because
all
the
rest
of
the
murray
provided
guidance
or
updates
to
update
foo,
and
this
one
is
more
as
more
background
than
some
of
those
explicit.
C
C
L
A
A
A
When
I
say
adding
takes
me
an
authoring,
okay,
not
necessarily
doesn't
necessary,
have
to
be
a
primary,
but
we
definitely
need
people
to
author
the
documents
and
then,
instead
of
just
reviewing
and
in
making
comments,
it's
very
useful
to
have
people
who
will
actually
contribute
the
text
that
will
fix
the
document.
Dieudonné.
L
C
C
Second
paragraph,
so
so
the
second
last
line,
the
the
reason
it
says,
minimal
mechanisms
is
try
to
use
existing
things
where
it
would
be
hopefully
deep
or
some
some
method
that
has
a
TLS
outer
tunnel,
but
because
there
is
also
this
other
draft
which
it
cred
so
I
didn't
want
to
tie
it
down
to
EEP
deep.
But
the
fact
that
it
says
minimal
mechanisms
with
which
limited
use
credentials
can
then
be
used
for
creating
general
use,
long
term
credentials.
L
C
Reason
is,
there
is
true
drafts,
so
there
is
he
creds
and
I'm,
not
authoring
any
of
those
two
drafts
I'm
just
saying
there
were
two
drafts
and
I
try
to
capture,
essentially
what
they're
trying
to
do
with
the
same
text.
But
if
you
want
to
put
deep
here
specifically
that's
something
we
can
discuss
on
the
list
as
well.
Yeah.
L
C
L
C
L
Probably
there's
there's
little
recent
if
you
guys,
just
when
I'm
singing
the
charters
giving
that
not
part
of
the
text,
and
that
goes
to
Romans
point
right,
which
is
you
might
want
to
put
the
you,
might
want
to
separate
out
that
text
in
perfect
terms.
The
third
third
line
stick
that
into
V.
It
stick
that
into
your
deliverables
text
or
something
like
that.
M
Okay,
okay,
pepsin
I
think
you
already
covered
the
question.
I
was
gonna,
ask
but
I
think
the
second
second
second
paragraph
is
generally
enough
and
I
assume
that
it
kind
of
already
covered
the
it
creds
use
case.
Also
right
so
I'm
fine
with
it.
Then
we
can
probably
do
some
word
spinning,
but
I
think.
A
E
N
So
just
this
slide
is
a
kind
of
segue
to
the
retiring
discussion.
So
just
a
reminder
that
out-of-band
means
a
second
independent
communication
channel
which
is
used
for
authenticating
something
on
the
primary
channel,
and
this
has
become
a
kind
of
common
way
of
boosting
security
in
applications
and
devices.
But
if,
even
though
it
is
the
scenario,
authentication
framework
with
the
all
kinds
of
authentication
methods
doesn't
currently
support
an
open
authentication
and
that's
why
we
set
out
to
to
specify
the
ignore
protocol
for
this
purpose.
N
Next
slide
here
is
our
timeline.
We
have
been
working
actually
over
three
years
on
this
and
kind
of
polish,
the
specification
and
the
in
written
implementation
for
linux
and
the
modeling
and
verification
of
the
protocol
and
as
a
new
thing,
there
is
no
peer
implementation
for
Contiki
in
progress,
and
the
draft
is
in
version
6
next
slide.
Please.
N
So
I
have
two
slides
just
to
remind
us
what
is
in
old
an
overview,
so
it
isn't
leap,
a
method
for
bootstrapping
devices
out
of
the
box
without
professional
administration.
That's
kind
of
the
use
case
that
we
trying
to
solve
and
the
authentication
is
based
on
user,
assisted,
out-of-band,
authentication
that
success
the
user
using
a
mobile
phone
to
spend
a
dynamic,
QR
code
or
NFC
tag
and,
in
addition
to
doing
just
one
time
out
indication
the
method
registers
the
device
these
two
Triple
A.
N
Next
slide.
Here
is
an
art
picture
picture
of
the
use
case
when,
when
this
method
is
used
for
network
attachment,
so
we
have
a
new
device.
That
is
not
reality
stirred
on
the
network,
and
then
we
have
the
network
infrastructure
with
an
access
points
and
the
Triple
A
architecture,
and
most
of
the
communication
in
this
method
happens
over
the
EAP
Channel
in
band
between
the
new
device
and
the
Triple
A
server.
N
That
kind
of
critical
thing
is
that
normally
in
device
bootstrapping,
you
have
the
problem
that
you
would
like
to
register
a
device
in
the
server,
but
you
need
network
connectivity
for
that.
But
then
you
don't
have
network
connectivity
because
the
device
is
not
yet
registered
and
we've
solved
that
by
using
the
EAP
panel
for
communicating
between
the
new
device
and
the
server
before
the
device
is
registered
and
clearly
this
is
has
been
a
successful
idea.
It's
been
now
copied
by
at
least
two
other
tracks
next
slide.
N
However,
this
time
we
did
make
one
slightly
bigger
chains,
so
in
earlier
versions
of
the
draft
we
have
overloaded
the
network
access
identifier
now
so
that
it
conveyed
the
peer
ID
and
the
state,
and
this
doesn't
really
comply
with
the
with
the
Evo
RFC's
guidance,
where
it
says
that
the
identity
response
should
be
used
primarily
for
routing
and
for
selecting
the
eat
method.
And
for
that
reason
we
now
cleaned
up
the
draft
and
got
rid
of
this
overload
of
the
NIE
and
the
cost.
N
So
that's
the
only
bigger
change
for
a
while.
Then
there
is
some
of
these
smaller
cleanups.
We
added
earlier
a
key
identifier.
We
to
help
the
peer
implementation,
but
after
some
thinking
we
may
want
to
in
the
future
randomize
the
identifiers
in
the
protocol
for
privacy
reasons
and
the
key
identifier
would
then
leak
the
peer
identity.
So
it's
better
get
rid
of
that.
N
Then
we
made
some
editorial
changes,
so
all
the
exchanges
in
the
protocol-
all
the
it
conversation,
have
this
common
apart
kind
of
handshake,
and
we
move
that
to
a
separate
text
section.
Of
course,
anyone
who
implements
the
protocol
would
do
this
necessarily
in
this
order.
So
you
do
first,
the
common
part
and
then
branch
out
to
the
different
exchanges,
and
now
the
text
follows
more
closely
there:
how
we
would
expect
people
to
implement
it,
and
this
previously
caused
some
confusion
with
the
implementers.
N
Finally,
another
thing
is
related
to
roaming
support,
so
the
method
allows
the
server
to
assign
realm'
to
the
peer
with
the
peer
will
later
use
in
future
conversations
forum,
so
that
the
requests
can
be
routed
over
the
Triple
A
architecture
to
the
correct
server,
and
this
is
especially
useful
in
cases
like
Eddie
Rome,
where
roaming-
and
there
was
a
question
about.
When
should
the
peer
start
using
the
the
realm
and
that
it
received?
And
the
answer
to
that
is
now
written
in
that
that
text.
N
N
N
H
A
N
N
Ok,
I
ate
it
was
the
video
completely
ok,
so
so
that
here
is
my
to-do
list
and
we
don't
plan
any
major
changes.
I
don't
have
any
plans
to
make
major
changes
to
the
specification
anymore.
Unless
there
is
some
someone
else
comes
up
with
a
reason,
but
there
will
be
small
polishing.
So
one
thing
is
that
the
message
examples
need
to
be
updated
with
the
changes
made
to
the
version
6
and
then
I
am
still
a
bit
worried
about
the
time
outs
and
the
usability
aspect
related
to
time
out.
N
So
we
may
need
to
do
some
modeling
user
testing
about
that
and
we
have
solved
the
problem
of
lost
last
met.
Cities
can
recover
from
that
and
what
we
formally
verified
that
it
works,
but
that
should
be
written
up
and
reported
in
some
way
and
not
in
the
draft
but
somewhere
else.
And
finally,
we
maybe
should
write
into
the
draft
these
hooks
for
future
expansions,
which
we
have
been
thinking
about
along
the
way
so
things
that
I
already
mentioned
device
registration.
N
We
have
implementations
for
Linux
and
the
implementation
of
the
pier
on
contiki,
ongoing
work
and
then
formal
models
of
the
protocol
and
of
the
security
aspects.
The
authentication-
and
this
seems
to
be
some
interest
in
this
protocol
that
people
asking
questions-
and
this
could
be
a
work
item
related
to
the
paragraph
for
each
other
in
that
way.
So
just
stop.
L
L
Doesn't
seem
to
be
advancing.
Thank
you
all
right,
sir
review
RFC
7170
specifies
teep,
there's
TLS
based
authentication
as
well
as
some
enrollment
support.
Some
really
nice
TVs
in
there,
which
essentially
I,
would
say
mimic
est
in
some
way
shape
or
form.
Rfc
83
66
specifies
a
voucher
format
in
which
do
you
trust
an
introduction.
L
At
least
the
results
of
that
are
the
draft
IETF
anima
bootstrapping
key
infra,
says
here's
how
you
do
the
request
to
get
the
83
66
voucher,
and
this
draft
incorporates
all
three
into
a
flow
next
slide.
Okay,
so
I'm
not
going
to
go
through
how
everything
works,
because
I've
done
that
several
times
in
this
room
before
and
I
want
to
respect
your
time.
Here's
what
we
did.
The
first
thing
is
the
last
time
you
saw
the
draft
in
Prague.
There
were
no
security
considerations.
L
It's
not
that
there
aren't
security
considerations,
it's
just
that
we
haven't
gotten
to
him
yet
and
I
pleaded
prodded,
poked
and
otherwise
convinced
Dan
Harkins
to
help
us
out
on
this,
and
he
did
and
filled
in
what
I
think
is
pretty
good
claim
section
to
begin
with
the
Security's
consideration
section.
So
I'd
ask
you
to
please
review
that
diagrams
have
been
updated.
L
The
diagrams
are
not
yet
to
my
liking.
We
have
a
few
ASCII
humps
in
them,
which
I
think
I
can
remove
just
by
splitting
a
couple
of
diagrams
into
two
and
removing
elements
in
various
places
which
are
which
would
otherwise
be
redundant,
but
that's
very
cosmetic.
What's
really
needed
now
is
just
to
do
implementation
development
testing.
We
started
that
just
by
testing
out
teeth
to
make
sure
it
works,
so
we
are
obviously
finding
some
of
the
same
ambiguities
that
you
Andy
found
and
so
we're
going
through
all
those
right
now.
L
Our
next
step
is
to
to
go
further.
We're
we're
developing
on
both
sides
of
this,
in
terms
of
both
a
server
implementation
and
we're
developing
in
the
WPA
stuff.
Looking
codebase
as
well
and
we're
doing
a
little
bit
of
testing
and
hosts
a
DBA
PD
to
make
sure
that
that
this
will
all
work
smoothly.
So
what
we're
hoping
then
a
next
slide
if
I
even
have
a
next
slide.
Yeah,
okay,
good
yeah
coding
happening
now.
A
couple
things
that
we're
still
thinking
about
along
these
lines
is
whether
there
are
some
802
11
interactions.
L
Here's
the
basic
problem.
So
in
order
to
get
to
the
point
where
you're
doing
the
the
t,
p--
transaction,
what
happens
if
you're
in
the
middle
of
Tokyo
and
you
have
2,000
VSS
IDs
that
are
blasting
at
you
saying
join
me
join
me
join
me,
and
so
you
have
it.
The
device
has
a
choice:
can
it
hunt
through
all
of
those
to
go,
find
something
that
I
can
join?
It
might
take
a
very
long
time.
L
In
the
meantime,
its
battery
is
done,
and
so
that
might
mean
that
we
might
need
to
do
a
little
bit
of
802.
11
integration
in
some
cases
might
not
be
802.
11
integration
might
be
integration
with
with
with
Wi-Fi
Alliance
componentry
or
something
like
that
with
it's
all
based
on
802
11.
We
haven't
quite
worked
any
of
that
out,
but
we're
thinking
about
it
and
that's
really
an
optimization
optimization
on
the
flow
that
you
see
in
the
draft.
L
The
draft
basically
makes
various
different
portions
of
the
exchange
conditional
based
on
whether
or
not
you're
able
to
use
the
authentication
material
that
you
have
so
I'm
going
to
I
will
do
a
quick
redraw
of
the
diagrams
to
avoid
the
humps
again
its
aesthetic
and
then
what
I'm
hoping
for
is
adoption
in
time
for
Singapore.
If
we,
as
we
begin
to
see
some
code
and
produce
some
results.
So
that's
the
update
questions,
comments,
thoughts,
criticisms,
Tomatoes,.
A
L
Is
it
partly
could
be?
Let
me
give
you
an
example
of
how
it
might
be,
so
this
ties
into
the
animal
architecture,
and
so
there
are
two
possibilities
in
that
architecture.
One
possibility,
is
you,
go
all
the
way
out
to
the
manufacturer
and
say:
hey
is
this
yours
and
if
so,
can
I
have
a
voucher
please
and
that
I
wouldn't
call
that
out-of-band
I'd
call
that
in-band,
even
though
we're
not
specifying
the
the
mass
of
communication.
L
The
second
part
is,
instead
of
that,
I've
been
given
a
voucher
through
whatever
means
I've
been
given
it
right
and
I've
shoved
it
into
my
join
registrar
right
at
which
point
you've
received
this
thing
out
of
and
you've
shoved
it
into
your
join
registrar.
Maybe
it's
you
know
as
simple
as
an
Excel
import
or
hopefully
something
a
little
bit
more
structured,
and
then
from
that
point
you
could
you
could
just
as
easily
authenticate.
L
B
J
Mminton
ban
by
exchanging
pic
you
see
is
ten
and
seven
messages
with
the
chief
server
teak
doesn't
define
how
the
deep
server
interacts
with
the
CA
Acme
defines
how
a
client
can
interact
with
a
CA
and
get
certificates
issued
a
dramatically
what
this
draft
covers.
It
recovers
multiple
things,
but
the
thing
that's
most
relevant
here
is:
it
shows
how
to
stitch
these
things
together.
J
How
a
teep
a
client
can
interact
with
a
teep
server
exchange
because
he
has
ten
seven
messages
with
the
teep
server
and
the
tips
are
going
to
turn
around
and
talk
to
an
acme
CA
to
get
those
certs
issued
and
there's
probably
no
changes
required
to
Acme
your
T,
but
possibly
T.
Pisander
specified
and
want
to
talk
about
that
little
bit,
so
there's
multiple
different
use
cases
covered
in
the
draft
and
the
one
that's
important
is
three
here.
T
p--
and
Hana
me
presents
this
that
Acme.
J
So
what
that
means
for
for
client
integrations
is
that
and
the
client
which
we
teach
server
in
this
use
case
and
would
prove
ownership
of
a
domain
once
and
then
that
client
would
be
able
to
get
certs
from
acne
from
multiple
different
clients
hurts
against
some
of
the
means
of
that
primary
domain.
These
cases
we've
talked
about
EST
and
brewski
in
anima.
J
We
had
a
side
meeting
this
morning
and
there's
strong
interest
in
pursuing
and
progressing
the
EST
and
brewski
work,
so
that
a
client
will
be
able
to
talk
EST
or
a
clang
to
be
able
to
talk
brewski
to
a
server
and
then
that
server
can
turn
around
and
talk
mapping
to
a
CA
to
get
searched.
That
work
would
be
progressed
and
but
a
logical
extension
and
this
as
well
is
we
talk,
client
talks,
cheap
to
a
server
and
that
tip
server
turns
around
and
talks
Acme
to
a
CA
call
flows.
Here.
J
This
is
just
boilerplate
stuff.
This.
This
is
lifted
from
my
draft,
its
standard
Acme
authorizations
of
it
straight
from
the
Acme
draft
as
well,
and
it
simply
illustrates
how
a
server
interacts
with
acne
and
DNS
to
prove
ownership
of
domain.
There's
nothing
new
here,
it's
pod
repaired
acne
and
what
I'm
showing
here
is,
and
it's
a
bit
of
an
eye
strain.
But
it's
taken
from
this
current
draft.
J
It's
just
standard
boilerplate,
TLS,
1.2
tunnel
establishment
using
tip
nothing
new
here
at
all,
and
this
is
the
interesting
thing
here
is
once
the
teep
tunnel
is
established
and
the
client
sends
a
PK.
C
is
10
T
of
the
request
in
that
tip
tunnel
to
the
tip
server.
We
can
see
the
tip
server
is
turning
around
and
interacting
to
acne
CA
and
to
get
that
certificate
issued,
but
there's
a
couple
of
things
that
are
not
fully
specified
here
and
we
haven't
really
thought
through
properly.
J
Yet,
how
does
the
tips
ever
signal
to
the
client
that
yes,
I
am
willing
to
give
you
a
pkcs7
response,
but
not
yet
so
tip
doesn't
cover
how
to
do
that
and
discussion
dot.
That's
it
really
short
presentation
and
it's
just
a
broader
interest.
It
is
of
interest
to
the
est
and
brewski
communities
of
interest.
Here
is
two
rakat.
The
next
existing
tip
an
existing
tip.
J
Do
we
need
something
to
back
off
or
retry
mechanism
in
response
to
a
PK
c
as
ten
TLV,
and
are
there
any
channel
binding
issues
not
covered
by
section
3,
a
2
of
t,
I'm,
not
sure
I,
don't
think
there
are,
but
I
need
to
review
that
as
well.
There
are
some
related
drafts
as
well.
There's
a
couple
of
realtor
offs
hear
that
reef
at
house
and
Kathleen
has
for
issuing
acne
being
used
to
issue
device
certs,
but
they
don't
explicitly
touch
on
deep
integration.
That
is
it.
L
L
Think
what
you're
asking
about
the
teeth
work
is
that
we
need
to
have
the
equivalent
of
a
202
under
a
response
code
in
the
draft
that
we
put
together
and
I
think
the
answer
is
yes,
we
do
I,
think
one
of
the
things
that
we
need
from
the
security,
our
area
as
we
go
through
a
lot
of
the
review
around
this
is
what
are
our
resource
concern?
What
is
resource,
where
is
resource
consumption
occurring
and
in
the
process
of
doing
that
and
and
the
fun
of
the
fundamental
layer?
L
O
J
I
guess
that
would
be
in
the
CSR,
but
then
that's
exactly
the
open
issue
that
I
mentioned
going
through
one
open
issue
is
how
to
ensure
that
the
device
the
station
knows
exactly
what
fqdn
are
identified
to
put
in
subject
your
sand.
Key
cap
keep
acme
happy
and
in
east
EST
and
brewski.
The
way
that
could
happen
is
the
device
sends
a
CSR
out,
treats
requests
to
the
server
and
the
server
responds
and
tells
it
what
to
put
in
the
subject
how
it
works
here.
It's
an
open,
I
do
not
know.
Okay,.
B
A
Solloway,
so
it's
kind
of
interesting
to
have
that
the
the
kind
of
I
can't
give
you
a
certificate
now
come
back
later.
I
mean
the
net
result.
There
is
probably
you're
gonna
not
get
any
network,
I
mean
I,
think
it
actually
could
work
that
you
you,
you
basically
reject.
You
know
you
do
it,
eat,
fail
and
and
give
the
person
a
token
to
call
back
later
within
this
state
could
all
be
maintained,
probably
in
the
in
the
back
end.
You
could.
J
A
Probably
see
I'm
token
that
the
client
would
have
to
maintain,
but
you
did
acne
would
be
maintaining
the
state
on
whether
their
sir
was
no
on
how
to
get
the
cert
back.
So
I
think
it
would
be
possible
you're,
just
you're
not
going
to
have
any
network
connectivity
until
that
point
which
I
you
know
may
or
may
not
be
a
problem.
A
C
Boy
so
do
do
questions
or
remarks.
Anything
that
happens
beyond
the
deep
server
is
not
really
concern
of
this
group,
whether
you
Zack
may
or
full
bar
right,
whatever
happens
between
the
e
pier
and
the
observer,
is
what
eeep
is
doing
and
I
mean
sure
you
could
use
Acme
I
have
no
tact,
Acme
expert,
but
I,
don't
know
whether
Acme
does
client
certificates,
nor
does
it
even
distinguish
between
client
certificates
and
server
certificates,
because
my
understanding
was
activist
mostly
for
like
domain
validation
and
and
server
certificates
and
not
for
issuing
device
certificates.
J
J
So
that
there
may
be
like
there's
a
couple
of
things
here
right
first,
there
may
be
work
required
in
the
peak
is
he
is
ten
pkc,
seven
back
off
retry
and
there
may
also
be
work.
The
question
that
I
asked
in
the
question
that
I
open
question
anyways
as
well
is
the
mechanism
by
which
the
station
or
the
peer
knows
exactly.
J
P
C
So
yeah,
maybe
there
is
something
we
can.
We
can
look
into
that.
The
second
kind
of
note
I
wanted
to
make
it
should
not
be
the
device
or
the
peer
that
says,
issue
made
this
certificate.
It
should
be
the
deep
server
which
is
authenticating
the
peer
saying
that
so
so
so
the
server
is
the
one
that
sees
this
is
this:
is
the
device
that's
trying
to
connect
to
me?
This
is
the
knife
that
it
sent
to
me
and
whether
I
issue
it
a
certificate
for
deny
that
it
sent
me
or
for
some
something
completely
different.
C
A
F
H
I'm,
just
bringing
up
a
pet
topic
that
I'm
sharing
in
all
the
working
groups,
I
love
the
fact
that
we're
talking
about
kind
of
drafts
and
I
love
the
fact
that
we're
saying,
let's
wait
for
the
code
to
tap
to
help
us
I
think
that
tremendously
improves
kind
of
the
quality.
One
thing
I
would
ask
that
kind
of
this
working
group
is:
can
we
put
a
list
of
those
implementations
relative
to
those
drafts
somewhere
where
it's
easily
accessible,
perhaps
not
to
those
that
regularly
come
to
these
meetings?
H
H
You
know
running
code
versus
this
draft
and
potentially
even
which
version
of
that
draft
and
that'll
help
if
we
decided
to
interrupt
testing-
and
it
certainly
helps
me
when
I
advance
drafts
to
say
it's
not
just
us
having
written
some
words,
it's
we
have
some
code
backing
us
to
give
us
confidence
to
progress.
The
droughts,
great.