►
From YouTube: IETF112-UTA-20211112-1600
Description
UTA meeting session at IETF112
2021/11/12 1600
https://datatracker.ietf.org/meeting/112/proceedings/
B
B
B
B
B
C
B
E
B
F
B
H
I
I
I
So
specifically,
we
worked
on
airpn
and
request
support
for
some
application
protocols
that
still
do
not
have
a
lbn
defined
for
them.
We
added
text
from
the
draft
deprecates
md5
and
show
one
a.
We
went
deeply
into
integrity
and
confidentiality
limits
which
are
described
for
tls
1.3
in
rfc
8446,
but
for
tls
1.2.
I
This
actually
required
some
some
new
work
and
I'd
like
to
thank
the
authors
of
the
aad
limits
for
their
help,
and
we
we
added
the
requirement
for
the
extended
muscle,
master
secret
extension,
so
non-trivial
work,
but
still
in
the
big
scheme
of
things
relatively
minor
changes
to
the
to
the
draft,
and
there
are
a
few
remaining
open
issues,
all
of
them
actually
around
tls
1.2.
So,
even
though
the
rfc
will
cover
both
a
1.2
and
one
1.3
and
we're
more
conservative,
more
careful
about
adding
requirements
for
1.2.
I
I
But
what
do
we
do
about
certificates
and
especially,
what
do
we
do?
What
do
we
do
about
certificates,
given
that
real
world
certificates,
at
least
on
the
open
web,
are
simply
not
using
pss
as
far
as
we
can
see
so,
do
we
really
add
the
requirement
for
support
of
pss
and
support
of
the
signature,
algorithm,
cert
extension
question
here
next
slide.
I
There's
a
draft
in
in
the
tls
working
group
about
obsoleting
key
exchanges,
it's
kind
of
stalled
for
for
the
last
few
months
and
we
are
waiting
for
it
to
mature.
It
is
not
adopted.
Yet,
although
we
believe
the
general
sentiment
is
to
adopt
it
into
the
working
group-
and
we
would
like
to
be
in
sync
with
this
draft,
especially
if
it
is
adopted
and
next
slide.
I
A
question
that
came
up,
I
believe
in
itf
111
by
mr
farrell,
where
he
asked
whether
we're
breaking
consumer
documents
so
actually
there's
progress.
Since
this
slide
thomas
and
I
went
through
the
101
rfcs
that
site
rfc,
75
75-25,
the
vast
majority
of
them,
do
it
in
a
very
generic
way,
either
they
just
say:
hey,
here's
a
tls
recipe
and
it's
a
good
idea
or
they
said
it's
a
should
or
even
a
must
to
support
it,
but
no
no
specific
details.
I
There
are
some
exceptions.
I
didn't
see
anything
of
note
in
the
50
of
them
that
I
went
through
and
thomas
might
want
to
disagree
with
me.
He
read
the
situations
in
the
other
50,
but
assuming
nothing,
no
surprise.
There
are
like
formally
breaking
changes,
or
in
other
words,
if
you're
compliant
with
75
25.
A
This
is
peter
yarrow,
thanks
for
for
working
on
that
with
thomas
I
I
know
I
didn't
get
to
it
as
quickly
as
you
did.
I
think
the
only
other
point
is
if
people
have
rfcs
that
or
other
specs,
because
there's
probably
people
outside
the
ietf
for
citing
this
as
well
that
they
are
concerned
about.
I
think
at
this
point
I
think
we've
done
our
due
diligence
to
you
know,
go
through
the
consuming
documents,
but
if
people
have
concerns
they
should
raise
those
now
or
during
the
working
group.
Last
call.
E
So
I
put
myself
on
the
on
the
queue
I'll
just
taking
off
my
chair
head
for
a
while.
So
you
know
there
was
a
discussion
in
in
sag
around
sort
of
the
you
know
the
work
they're
doing
on
deprecating
or
promoting
or
or
some
somehow
signaling
around
crypto
suites,
and
you
made
the
comment
that
you
know
this
work
really
should
have
been
or
could
have
been
in
and
done
in
utah.
Is
there
any
like
synchronization?
We
should
be
doing
there
any
comment
on
that.
E
D
E
Oh
yeah
that'd
be
great
to
appreciate
it.
I
mean
there
is
sort
of
an
apparent
jargon
called
that
out
during
saga.
There
is
sort
of
an
apparent
conflict
here
I
mean
some
tls
is
essentially
doing
sort
of
a
a
work
making
recommendations
on
crypto
switch,
which
is
kind
of
duplicates
at
least
the
intention
of
what
the
uta
was
supposed
to
be
doing,
and
others
had
made
also
made
comments.
I
think
harness
made
a
comment
that
well
you
know
there
is
a
there's.
E
D
A
Yeah,
just
to
put
my
hand
up
quickly
to
say
that
last
time
around
we,
you
know
we
did
cross
post
when
there
was
a
working
class
call,
I
believe,
in
in
the
utah
working
group
we
cross
posted
to
probably
dls
working
group
and
zag
and
other
places,
so
that
folks
were
aware
that
this
was
the
place
to
provide
feedback
on
that
document.
But
it
sounds.
A
B
B
I
A
I
Know
yeah:
we
already
ran
through
this
review
couple
of
hours
and
we
need
to
to
get
together
and
make
sure
that
there
are
no
surprise
findings,
but
bearing
that
we
can
close
that
issue
as
well.
I
believe,
as
the
other
issues
again,
we
do
need
working
group
feedback
on
these
issues,
but
I
think
we
have
a
way
forward,
and
so
we
are.
We
are
very
near
work
and
group
last
call.
B
I
A
A
Yeah,
just
one
more
quick
note
on
that,
I
guess
you
know
people
are
going
to
be.
People
are
always
deprecating
things,
and
you
know,
two
weeks
after
we
published
the
the
rfc
that
replaces
75
25
bit,
someone
could
decide
to
replace
something
else
right,
so
these
documents
are
sort
of
a
snapshot
in
time
at
some
level,
the
best
current
practice
and
that's
what
the
current
is
all
about.
You
know,
so
I
I
would
expect
at
some
point
we're
going
to
you
know,
have
another
update
to
this
document
at
some
point.
A
J
Yeah,
I
guess
my
question
would
be:
is
there
would
it
be?
Is
there
anything
useful,
you
could
say,
pay
attention
to
this
for
whatever
this
to
see
what
gets
deprecated
in
the
future,
whether
that's
the
ayanna
registry
or
pls?
Is
there
a
easy
way
just
to
point,
you
need
to
point
somebody
out
and
say
hey.
This
is
where,
when
things
get
deprecated,
this
will
be
where
you'll
find
out
so
attention.
There.
I
K
Okay,
hi
jeff
galloway,
one
of
the
co-chairs
of
tls
yeah,
so
I
I
think
the
intention
is
to
to
adopt
that
we
were
trying
to
merge
the
content
of
two
drafts
and
we're
waiting
for
some
action
from
the
officer
so
I'll
take
that
action
item
to
follow
up
at
least
on
this
rsa
kicks
or
the
kickstart
there
is.
As
to
the
broader
coordination
question
I
think
yeah.
K
We
should
definitely
have
a
have
a
chat
between
the
chairs
and
make
sure
that
we're
you
know
kind
of
working
with
the
two
groups
as
best
we
can,
because
I
don't
think
there
should
be.
You
know,
conflicts
of
interest
here
I
mean
you
know,
we're
all
kind
of
working
towards
the
same
goal
and
I
think
the
things
we're
putting
together
to
kind
of
signal
recommended
are
you
know,
mechanisms
that
any
group
in
the
ietf
can
use
to?
G
G
G
G
So
a
couple
things
like
to
discuss
brian
had
submitted
some
text
on
multiple
identifiers,
as
in
what
you
do,
if
the
client
isn't
sure
which
identifier
it's
using
and
if
the
certificate
the
presented
identifiers
have
multiple
things
in
them,
there's
some
security
implications
from
that
that
was
posted
to
the
list.
It
hadn't
gotten
much
comment,
but
I'd
like
the
working
group
to
look
at
that
I'll
post
a
reminder.
C
G
Week
or
two
after
the
ietf,
when
things
have
settled
down
and
say,
hey,
please
let
me
know
if
you
disagree,
there's
also
some
editorial
changes.
Minor
wording
things.
Nothing
semantically
changes
with
this
pr
that
I've
got
hopefully
a
better
title,
so
maybe
something
like
naming
in
verifying
service
names
in
tls.
G
I
look
at
the
the
hedge
dac
minutes
and
you
know
the
the
title
there
of
that
agenda
item
takes
up
the
whole
page,
so
we
should
obviously
fix
that
it
doesn't
have
to
be
completely
descriptive.
There's
enough
context,
you
know
people
aren't
gonna,
say:
oh
what
should
I
name
my
baby?
Let's
look
at
this
ietf
rfc
and
see.
Oh,
it's
got
naming
in
here.
G
Peter's
been
obviously
kind
of
busy
with
the
rfc
editor
program.
So
he
and
I
need
to
sync
up
see
if
there's
more
from
what
he'd
wanted
to
do
or
was
hoping
to
get
done
from
61.25
jeff
has
already
said:
no,
it
might
be
ready
for
working
group
last
call
in
january,
depending
on
how
much
the
maybe
list
is
right.
So
that's
it!
That's
the
update.
B
My
comment
on
this
slide.
I
strongly
support
the
idea
to
change
the
title,
because
currently
the
title
is
way
too
long.
It
takes
three
lines
of
two
or
three
lines
of
text
and
if
you
can
do
it
with
more
condensed
way,
not
losing
the
sense
of
the
document,
it
will
be
great
and
I
strongly
support
this
idea
because
it
is
it's
easy
to
reference.
The
document
is
a
short
title
and
yeah.
A
A
A
We
might
want
to
do
the
same
thing
that
garon
and
thomas
just
did
it's
not
that
hard
most
things
are
just
have
sort
of
a
perfunctory
citation,
but
so
I
think
that
would
be
a
good
thing
for
us
to
do
before
working
group
last
call
and
and
the
I
think
that
the
rfc
editor
stuff
should
sort
of
calm
down.
Here
after
I
publish
the
next
version,
so
I'll
have
some
I'll
have
some
cycles
to
help
with
that.
G
A
I
F
F
So
there's
really
four
issues
which
I
would
like
to
talk
about
today.
One
is
on
an
issue
with
ccm8
when
so
ddls103
is
in
in
us,
48
and
and
there's
in
appendix
there's
some
very
clear
analysis
on
what
the
security
is,
that
ccma
provides,
and
so
that's
a
little
bit
even
to
someone
who
is
remotely
familiar
with
cryptography
a
little
bit.
F
It
raises
the
question
of
whether
the
security
of
ccm8
is
actually
a
good
thing
going
forward,
so
we
had
a
lot
of
discussions
on
this
in
different
groups,
so
I
would
like
to
summarize
those
and
make
a
proposal
on
the
way
forward.
The
second
item
is
about
the
initial
timer
values
and
the
idea
of
relaxing
those.
We
made
some
recommendations
in
the
1.2
version
of
the
of
the
pcb
and
the
dls
and
ddls
103,
specifically
dds-103
handles
retransmissions
differently
than
before.
So
so
that's
something
to
look
at
again.
F
There
was
also
a
longer
discussion
on
the
dls
mailing
list
about
long
collect
connections
that
people
use
in
in
the
industrial
iot
space,
and
so
there
are
some
problems
associated
with
that
and
that's
the
the
third
item.
And
finally,
that's
the
topic
of
what
identifiers
go
into
these
end
entity
certificates
and
what
recommendations
or
examples
could
we
provide
there
or
probably
provide
better
guidance
what
people
use?
F
My
our
conclusion,
thomas
and
and
mine,
was
after
revisiting
that
literature
and
and
the
reference
specifications
we
kind
of
came
to
the
conclusion
that
we
have
really
difficulties
recommending
ccm8
to
anyone
these
days.
Unfortunately,
it's
the
only
mandatory
to
implement
cyber
suit
in
co-op
and
so
there's
some
some
side
effects
of
making
any
recommendations.
It
sounds
kind
of
weird
to
make
a
recommendation
not
to
use
it
when
others
idf
specifications
do
otherwise
and-
and
of
course,
we
can't
just
change
it,
and
then
people
are
upset.
Of
course.
F
F
But
there's
also
a
downside,
as
you
probably
know,
is
like
developers,
are
often
not
really
in
a
good
position
to
make
that
type
of
risk
assessment,
because
they
may
not
necessarily
always
know
all
the
parameters
on
on
the
deployment
environment
or
like
you,
deploy
it
initially
here
and
then
you
would
deploy
it
there.
So
so
the
environments
may
be
very
different.
F
So
that's
that
was
our
approach.
I
see
daryl
suggesting
having
other
sort
of
approaches,
and
I
that
was
the
rickard
mentions
the
oscar
document
that
was
just
referring
to
and
and
maybe
maybe
this
is
a
place
where
utah
can
provide
recommendations,
so
at
least
consolidate
the
discussion
so
that
we
have
a
kind
of
a
uniform
approach
to
this.
But
this
is
just
my
take
on
the
story
from
also
reading
the
mailing
list
so
in.
F
F
F
F
Some
people
mentioned
police,
certainly
the
cha-cha
poly
algorithm,
but
that
may
be
maybe
a
possibility
if
it's
specifically,
if
it's
implemented
in
software,
another
approach
would
be
to
wait
a
little
bit,
because
there's
that
nist
lightweight
crypto
competition
ongoing
and
maybe
there's
something
that
falls
out
of
that.
That
is
more
constraint
friendly.
But
in
general
I
have
to
say,
like
it's
not
so
easy
to
say.
Like
what
would
be
a
suitable
alternative
here-
and
at
this
point,
I
would
welcome
feedback
from
the
folks
in
a
group.
F
What
you
think
should
be
best
done
whether
this
whole
idea
of
moving
on
from
ccm8
is.
Is
it's
a
bad
idea
and
we
should
just
reinterpret
the
analysis
which,
of
course,
we
can
do
by
picking
different
what
setting
the
parameters
to
different
values
or
what
theirs,
maybe
they're,
totally
different
ideas
as
well.
B
A
few
comments
as
participants,
not
as
the
chair
so
and
probably
john
will
john,
I
think
john
betson
is
a
queue
and
probably
he
will
have
a
better
provides
a
better
comment,
but
I've
today,
I've
reread
his
message
to
cephergy
with
analysis
of
ccm8
and
the
bottom
line
as
I
got
it
is
that
well,
htm
8
is
has
a
limitation,
but
it
is
not
a
disaster.
It
is
not
a
disaster.
B
If
you
limit
the
number
of
messages
that
are
sent
and
if
we
are
talking
about
iot,
we
are
not
talking
about
gigabits
and
tens
of
gigabytes
links.
It's
usually
a
relatively
small
number
of
messages
that
are
sent,
so
that
is
probably
not
so
bad
but
well,
I
think
john
will
comment
better
on
it.
So
john,
please
go
ahead.
H
Yeah
so
sorry
to
honest
that
I
promised
hummus
to
comment
more
on
this
in
cf
audi,
and
I
have
not
done
that.
I'm
sorry
for
that,
but,
as
I
said
in
song,
I
think
it
the
analysis
down
for
tls,
dtls
and
quick
turns
out
very
wrong
for
cccm
a
what
the
process
does
is
that
it
calculates
integrity
advantage
for
a
single
key.
H
I
think
that
is
does
not
have
much
value
for
when
you
are
in
the
security
protocols,
when
you
have
multiple
keys
and
you're
doing
frequent
re-keying,
so
I
think
basically
re-keying
ccm8,
as
the
dkls
suggests,
every
future
power
of
8
doesn't
improve
security
at
all.
I
don't
think
there's
any
denial
of
service
attacks
here.
I
think
the
important
security
measure
in
ccm8
is
the
64-bit
tagline.
I
think
that
is
very
much
okay
for
for
iot
raid,
you
have
basically
never
seen
any
practical
attack
on
64
or
hardly
on
32
max
either.
H
So
I
think
I
think,
the
only
and
for
a
64-bit
mac
ccm8
is
quite
it's
very
good,
as
you
can
see
from
the
equations
in
the
see.
If
audi
drops,
I
think
you
wouldn't.
There
will
not
be
any
better
mac
with
64
bits
from
the
from
the
mist.
You
might
get
something
more
lightweight
with
128
bits.
I
think
yeah
I'll
comment
more
on
tfr
in
the
coming
weeks.
When
I
get
some
time.
F
Yeah,
I
can
echo
yeah,
we
we
obviously
went
through
them.
Ira
posted
the
the
link
to
the
document
and
the
references
to
further
there's
references
to
further
materials,
and
we
went
through
those
and
also
discussed
it
with
internally
with
cryptographers.
We
have
there's,
there's
nothing
wrong
in
the
analysis.
F
Do
you
then
re-key
and
that's
that's
sort
of
the
question,
of
course,
in
some
of
the
iot
networking
technologies,
the
bandwidth
is
indeed
very
limited,
so
so
that's
they
are,
and
maybe
maybe
those
they
have
their
own
link.
Clear
security
making
like
I'm
thinking
about
laura,
laura
van,
but
others.
That's
why
it
gets
tricky
is
like
in
some
other
technologies.
Let's
say
a
device
that
is
connected
using
wi-fi,
let's
say
a
wi-fi
camera
and
or
something
something
like
this:
what
did
what
are
they?
F
H
H
B
H
Yeah,
I
don't
know
if
I
have
them,
I
don't
think
you
need
to
do
any
reason
very
frequent
readings.
I
don't
think
any
denial
of
service
is
a
problem
at
all.
You
do
need
to
do
a
re-keying
for
all
of
these
protocols,
but
I
don't
think
you
need
to
do
any
more
frequent
reading
for
ccm8
than
you
need
for
ccm
ccm,
the
full
order
for
gcm.
I
think
that
conclusion
this.
If
our
draft
is
wrong,
I
don't.
F
Think
that's
true
on
that
aspect.
My
understanding
is
that,
in
order
to
not
provide
the
attacker
an
advantage,
you
need
to
after
a
number
of
attempts,
failed
attempts
to
to
send
packets
sort
of
fabricated
packets.
You
need
to
re-key
that's
the
or
terminator
connection,
and
that
would
be
a
problem
right.
F
H
B
L
L
It
can
only
send
certain
amount
of
tries
per
second,
you
know
15.
Four,
for
example,
I
have
a
100
byte
max
127
byte
maximum
pocket
length
and
there
is
2
to
the
32
pockets
maximum
for
each.
You
know
session
and
it
takes
about
a
year
to
send
those,
so
you
know
wreaking
once
per
month-
and
you
know
it
limits
very
much.
F
F
F
So
if
you
had
some
radio
technology
where,
for
whatever
reason,
because
of
the
high
latency
or
because
of
some
congestion,
you
had
difficulties
getting
the
the
as
a
flight
through
in
time,
then
that
was
obviously
a
a
big
obstacle,
because
then
you
would
retransmit
the
whole
thing
and
then
you
make
the
whole
situation
worse.
So
that's
why
the
there
was
this
high
initial
timer
value,
selected
and
and
also
not
just
over
the
wire
transmission,
but
also
the
operations
that
take
place
on
the
device.
F
So
nine
seconds
sounds
pretty
pretty
high
like
when
you
when
you
hear
it,
but
if
you
take
also
into
consideration
that
some
of
the
devices
are
actually
also
constrained
devices
that
talk
to
each
other.
So
there's
you
can
seconds,
add
up
slow
communication
and
so
on.
We
also
had
the
use
of
at
that
time
when
he
worked
on
his
the
use
of
ddls
over
over
sms
and
for
some
of
the
network
deployments,
which
were
had
very
limited
cell
coverage.
F
F
And
then
in
dtls
1.3
we
changed
the
retransmission
mechanism
from
a
flight
base
to
a
record-based
mechanism,
and
we
added
this
message,
and
that
is
obviously
gives
more
possibilities
than
what
we
had
available
in
in
the
102
version.
And
so
we
thought
I
that
it
would
be
time
to
reduce
and
or
relax
that
initial
timer
value
down
to
something
like,
like,
obviously,
multiple
options.
F
We
thought
maybe
something
like
three
seconds
like
it's
suggested
in
in
rc,
29,
8080
or
even
going
further
down
like
some
of
the
other
rfcs
do.
Maybe
a
middle
ground
would
be
would
be
good,
but
definitely
having
something
lower
would
be
beneficial
for
implementations
to
actually
have
a
reasonable
performance,
because,
first
of
all,
many
of
the
networks
changed
in
the
meanwhile
deployments
changed
and
also
the
the
capabilities
of
1.3
is
different.
F
F
F
So
I
think
that
that's
that's
something
we
wanted
to
add,
and
if
someone
of
you
has
a
deployment
with
similar
characteristics,
I
think
that
would
be
extremely
valuable
input.
I
know
like
the
iot
segment
is
very
fragmented
people
work
in
all
sorts
of
different
environments,
and
so
it's
sometimes
difficult
to
get
sort
of
the
inputs
from
all
these
different
environments,
whether
you're
working
on
a
sort
of
more
industrial
setup
or
a
more
home
iot
deployment
or
whatsoever.
Whatever.
H
Yeah,
I
think
it
might
be
good
to
mention
that
you
get
a
bit
lower
security.
I
haven't
read
what
you
write
in
the
document,
but
tls.3
for
long
connections
give
forward
secrecy,
but
that
only
protects
you
in
one
direction.
Kls
1.2
with
frequent
renegotiation,
protects
you
in
both
directions.
So
if
an
attacker
steals
a
key,
they
can
only
they're
limited
in
the
date
double
forward
and
backward.
But
that's
I
don't
know
most
iot.
You
cannot
it's
more
a
consideration
than
any
technical
exchange.
F
F
It
has
a
couple
of
different
identifiers
specified
and
to
give
some
guidance,
because
that's
often
a
point
that
confuses
what
people
like
to
discuss
about
identities
of
iot
devices
I
like
to
prefer
to
talk
about
identifiers
makes
it
less
dramatic.
But
and
then
there
are
also
different
types
of
identifiers
at
different
stages.
F
Whether
we're
talking
about
things
that
happen
during
manufacturing
or
whether
we're
talking
about
the
identifiers
that
are
then
used
sort
of
like
the
operational
certificates,
as
some
people
used
to
call
them-
and
I
think
in
even
in
the
idf
there's
some
for
some
of
the
iot
related
protocols,
there's
some
diversity
of
what
gets
populated
for
these
client
these.
These
identifiers
for
client
certificates.
F
F
Do
that
and
and
and
the
client
side,
I
don't
think
we
can
make
the
same
recommendations
on
the
client
set
as
we
do
on
the
server
on
the
server
side,
because
they're
just
different
requirements,
and
not
just
only
like
the
way
how
the
authorization
works
for
for
the
so
for
what
you
get
from
the
server
to
match.
It
up,
for
example,
match
the
sni
with
what
you
get
from
the
service
certificate.
F
The
the
authorization
is
very
different
on
an
iod
in
an
iot
deployment,
from
the
client
side
to
the
server
or
to
multiple
servers.
If
you
have
something
like
anima,
so
so
there's
some
difference,
and
it's
probably
in
in
the
end
like
if
you
see
it
from
a
from
a
high
level,
of
course,
there's
a
little
bit
of
annoyance
on
the
server
side,
because
you
now
need
to
look
at
different
places
for
the
identifiers
rather
than
in
one
specific,
but
on.
F
On
the
other
hand
like
for
most
for
most
deployments,
it's
it's.
It
doesn't
matter
that
much
there's
no
sort
of
like
intro
ability
problem.
I
think
the
intro
ability
issue
of
identify
matching
and
identify
against
something
else
that
occurs
in
in
in
fewer
places
like
like
anima
or
maybe
maybe
some
other
protocols
that
work.
Similarly,
okay,.