►
From YouTube: UTA WG Interim Meeting, 2020-04-23
Description
UTA WG Interim Meeting, 2020-04-23
A
A
C
C
C
C
B
A
C
A
We
are
getting
a
smattering
of
attendees,
those
who
you
are
just
about
just
joining.
We
are
about
to
start
it's
a
good
idea
to
take
the
time
when
we're
playing
around
with
audio
to
and
ensign
the
virtual
blue
sheet
at
the
end
of
the
bottom
of
the
etherpad.
If
you
are
curious
about
where
the
iPad
is
it's
actually
in
the
meeting
announcement,
and
also
on
the
jabber
channel,
which
is
you
ta
@
jabber,
dot,
ITF
told.
C
A
A
It
actually
helps
if
you,
even
if
they're,
true
or
else
it
actually
helps
if
we
have
somebody
too
some
minute
taking
and
keep
watch
on
on
the
Auburn,
all
other.
On
other
meetings
that
I've
been
to
this
virtualized
LTF
meeting
I've
seen
that
there
are
situations
where
people
need
to
be
channeled
to
to
WebEx
Mike,
even
though
you
know
we
were
supposed
to.
We
have
sort
of
working
here
management,
but
some
people
have
audio
issues
and,
in
that
case,
sort
of
speak
up
on
jabber
and
we'll
figure
it
out.
D
A
A
A
Pin
what
is
my
ID
rather
working
group
so
glad
to
have
you
back
now,
I
assume
since
you're
all
here
that
you
actually
found
the
WebEx
link
and
meeting
slides.
I
will
repeat
here
that,
if
you're
here
in
order
to
be
here,
please
add
your
name
to
the
virtual
blue
sheet
at
the
end
of
the
ether
pad
and
you
consider
joining
the.
A
B
A
You
right
can
we
you
switch
back
to
the
note
well
for
one
second,
if
this
is
your
first
ITF
virtual
or
otherwise
note
the
requirements
of
the
note
well,
especially
when
it
comes
to
respect
to
IP
or
it
it.
It
does
happen
that
we
get
idea
might
be
our
issues
in
the
idea
phone.
It
is
really
important
that
we
keep
on
top
of
this,
so
that
next
slide
and
I
haven't
heard
a
beep
in
a
while
so
I'm
sort
of
hoping
that
it's
safe
to
keep
kick
this
ball
into
play
now.
So.
A
We
have
15
minutes
each
on
three
presentations
and
the
first
is
just
refer
you
to
a
DCP
195
bits,
so
somebody's
taking
them
taking
it
upon
themselves
to
go
and
do
a
base
revision
of
our
one
of
our
core
specifications,
which
is
very,
very
good
work
and
I'm,
assuming
your
own
and
I
think
is
it
Peter
or
your
own?
That's
gonna
present
this
all
right,
so
I'm
assuming
you're
presenting
this
here
with
the
with
the
hope
of
getting
it
adopted
as
working
you're
talking
about.
A
C
C
E
E
A
A
And
then
we
have
a
few
proposed:
two
of
them
are
being
presented
today.
I,
don't
think
I
haven't
seen
any
anything
from
DTLS
security
module
in
a
while,
but
it
I
guess
it
has
been
revised
a
few
time
at
times
so
review
only
and
on
the
list,
as
always
appreciated
and
I'll.
I
won't
speak
to
the
other
graphs
because
they're
being
presented
today
and.
C
E
Okay,
so,
as
you
might
recall,
your
own
Ralph,
Holtz
and
I
worked
on
7525
quite
a
while
ago,
five
years
ago,
I
guess
it
was
and
you
can
work
we
would
like
to
have
the
working
group
consider
whether
we
should
do
a
best
version
of
this,
and
we
will
it's
rather
late
for
your
own
and
Ralph,
which
is
why
I'm
presenting
because
they
might
be
half
asleep.
But
here
we
are
and
perhaps
you'd
go
to
the
next
slide.
F
E
This
has
I,
can
I've
got
the
slides
on
my
computer
here,
so
I
can
start
talking
and
then
making
progress.
So
we,
this
document
is
like
I,
say:
five
years
old
we
have.
This
was
before
TLS
1.3.
Obviously,
so
at
the
time
we
were
actively
working
to
get
folks
moving
to
1.2
and
talking
about
what
some
of
the
issues
are,
that
folks
need
to
be
aware
of.
E
E
One
two
two
TLS
1.3
even
has
pretty
good
adoption,
and
those
numbers
continue
to
improve
the
this
RFC
or
BCP
has
also
been
highly
cited,
both
inside
and
outside
the
ITF
and
so
I
think
it's
been.
It's
helped
to
move
the
needle
on
people's
understanding,
especially
because
your
own
and
Ralph
and
I
tried
to
focus
it
on
folks
who
are
actually
using
TLS
and
not
for
TLS
experts.
So
we're
trying
to
provide
guidance
that
and
I
think
it
has
proved
useful
to
people.
Let's
see
next
slide,
please.
E
So
the
our
thought
is,
we
would
keep
it
targeted
at
that
same
audience.
Obviously,
TLS
1.3
was
came
out
in
2018
three
years
after
this
RFC,
so
we
definitely
want
to
mention
TLS
I,
don't
really
want
to
get
into
too
much.
You
know
we
don't
really
want
to
present
details
about
all
these
topics,
because
we'd
rathole
on
the
first
one
and
never
get
through
the
the
planning
idea,
but
we
just
wanted
to
lay
out
what
the
thoughts
are
and
then
take.
E
Some
questions
so
definitely
have
to
have
mentioned
TLS
1.3,
whether
as
I
should
or
must
there's
active
work
among
lots
of
folks
who
try
to
deprecate
the
older
versions
and
there's
the
old
versions.
Deprecated
document
in
the
TLS
working
group
that
we
would
like
to
reference
and
I
know
I
pinged
Benjamin
the
other
day,
and
he
said
it's
just
waiting
on
his
action
on
the
8th
each
side.
So
we
should
be
able
to
reference
that
there
was
the
CSV
stuff
in
RFC
7507,
which
came
out
right
about
the
same
time
as
this.
E
E
Just
as
a
side
note,
I
think
when
yarn
Ralf
and
I
worked
on
this.
The
working
group
discussed
this.
We
kind
of
thought
we
would
update
this
every
number
of
years
and
I
think
that's
where
we
are
eventually
we'll
probably
have
a
turd
och,
that
will
say
don't
use
TLS
1.2
anymore,
but
that's
going
to
be
some
years
down
the
line.
E
So
the
there's
some
TLS
1.3
challenges
that
people
have
in
the
field,
certainly
with
regard
to
the
zero
roundtrip
stuff,
and
we
might
want
to
say
some
things
about
that
and
there's
work
going
on.
Obviously,
the
certificate
transparency
work
has
proceeded
quite
well,
there's
also
the
encrypted
SNI,
which
is
not.
You
know
it's
the
winning
its
way
through
the
TLS
working
group.
Should
we
say
something
about
that?
Should
we
wait
until
you
know
a
future
version?
E
Those
are
some
of
the
open
issues
we
might
want
to
discuss
and
let's
talk
going
to
the
next
slide,
so
we
can
just
finish
walking
through
the
our
planning
for
the
document.
These
are
the
discussions
that
we've
just
had
amongst
the
co-authors
and
obviously,
if
we
adopt
this
in
the
working
group,
there
would
be
lots
of
discussion.
E
E
In
7525
and
ii.
I
know
that
the
DTLS
1.3
document
is
pretty
close
in
the
TLS
working
group.
So
we
might
want
to
reference
that
exactly
when
that's
going
to
be
approved,
I,
don't
know
or
progress,
but
we'll
need
to
have
some
text
around
DTLS
versions
as
well
as
TLS
versions.
There
are
some
things
these
days
that
are
kind
of
mostly
fixed
with
regard
to
compression
and
so
on.
E
There's
a
lot
of
background
information
in
there
that
we
would
probably
move
around
or
put
in
an
appendix
as
well.
We
were
not
planning
to
make
changes
to
or
update
or
replace,
74
57,
which
was
the
TLS
a
tax
document.
However,
either
we
would
continue
to
reference
that
so
that's
kind
of
the
the
broad
thinking
that
co-authors
have
had
and
we've
been
talking-
your
own
submitted
an
initial
version
which
has
none
of
these
changes.
All
it
does
is
copies
over
7525,
so
we
haven't
touched
the
document.
E
Yet
we've
just
had
some
discussions
among
the
co-authors,
and
ideally
we
feel
it
would
be
great
for
the
working
group
if
it's
going
to
be
around
long
enough
to
take
this
on,
so
that
we
can
have
some
open
discussion
and
come
to
consensus
about
what
we
should
do
with
regard
to
our
TLS
recommendations,
as
we
update
them
from
7525
and
that's
the
thinking
that
we
have
had
so
far.
Maybe
the
next
slide
that
we
talked
about.
A
A
A
A
G
E
A
E
A
E
A
Could
ask
for
a
virtual
ham
on
on
jabber,
or
maybe
a
combined
jabber,
and
here
people
can
a
plus
one
or
minus
one
to
the
following
question.
Should
the
working
group
seek
to
adopt,
with
the
permission
of
the
idea
of
course,
seek
to
adopt
drafts?
Refer
you
to
a
DCP
one
identified
this
as
UTA
working
with
document.
A
A
B
C
B
B
So
those
are
the
application
protocols,
security
using
using
TLS
and
the
dealers
and
and
also
at
the
same
time
like
these
protocols,
are
then
used
for
IOT
device
management,
and
we
have
sort
of
I
co-chair
in
a
group
in
in
the
Opel
alliance,
where
the
work
on
lightweight
m2m
has
been
done.
Bfi
at
modern
or
many
desk
fests,
with
more
than
40
independent
implementations
that
are
used
at
least
DTLS
and
later
we
provided
coop
over
TCP,
and
so
there
are
also
now
pls
implementations
for
for
IOT
used
in
those
devices.
B
So
that's
I
would
say
that's
pretty
good
and
in
general,
if
you
look
around
and
and
we've
done
sort
of
investigations
from
what
the
different
stacks
provide
lots
of
high
quality
imperative
implementations
of
TLS
and
detail
has
one
or
two
on
a
market.
So
that's
all
great,
however,
at
that
time,
when
we
worked
on
on
7925,
it
was
only
focused
on
version
1.2
and
in
there
is
obviously
nothing
in
there
for
103
next
slide.
So
this
is
what
this
document
is
about.
B
The
first
point
is
that
Els
won
the
3,
makes
algorithm
recommendations
very
much
like
we're
a
Shambhala
to
did
and
those
recommendations
have
been
sort
of
tailored
for
the
generic
web
usage
in
terms
of
algorithms
and
and
that
really
worked
well.
But
it
turns
out
that
IDE
communities
and
vendors
use
different
algorithms.
So
and
of
course,
the
TLS
1.3
specification
like
it
like
its
earlier
version,
have
foreseen
that
there
are
other
deployment
environments
that
may
have
different
recommendations
and
so
that
that
needs
to
be
done.
B
The
next
thing,
I'm
thinking
that's
a
little
bit
bigger,
is
that
1.3
added
0
roundtrip
functionally
functionality,
and
it
says
application
protocol
must
not
use
that
mode
without
the
profile
defines
its
use
and,
of
course,
for
HTTP
that
this
has
been
done.
There's
a
separate
under
of
see
on
that
8470,
but
since
we
use,
as
mentioned
on
a
previous
slide,
use
other
protocols,
mostly
in
the
IOT
space
that
are
more
optimized.
If
you
will
for
for
that
use
case,
we
added
something
on
on
coop.
Very
much
can
I.
A
B
Yeah,
so
to
finish
this
one
off,
so
we
added
this
this
profile
for
the
0
roundtrip,
in
line
with
what
the
RFC
8470
did,
but
just
for
coop
coop
is
conceptually
very
similar
to
HTTP
in
terms
of
its
restful
design,
so
that
feel
felt
applicable
for
MQTT.
We
still
have
to
do
more
work,
we're
trying
to
catch
up
on
like
the
deployment
situation.
Is
there
different
versions
that
are
and
not
backwards
compatible,
and
so
that's
a
slightly
different
story.
B
There
are
also
some
newer,
ide
developments
and
which
I
think
should
be
cavity,
as
well
as
a
kind
of
an
update
to
the
old
RFC.
One
is
the
further
developments
around
bandwidth
reduction
techniques,
and
there
was
a
discussion
on
the
list
about
the
C
were
compressed
certificates
John,
who
they
all
also
on
the
call
triggered
that
debate
and
made
a
contribution
in
form
of
an
ITF
craft
and
there's
also
the
whole
work
on
certificate
compression,
that's
newer
and
then
on
top
of
that
they're.
B
So
there's
this
more
work
on
two
or
more
extensions
to
make
Els
sort
of
consume
fewer
bits
on
the
wire
in,
as
many
of
you
know,
there's
also
a
compact
TLS
I'm,
a
sort
of
a
compressed
version
of
TLS
that
may
be
useful
to
consider
here
as
well.
Also
important
and
specifically
designed
for
IOT
deployments,
was
the
connection
ID
and
that's
something
that
is
being
finalizing
a
TLS
working
group
right
now.
B
What
for
a
little
while
now,
one
part
is
in
a
separate
extension
to
1.2
and
the
other
one
is
it's
indeed
sort
of
built
in
with
more
privacy
mechanisms
in
1.3.
It
sells
detail,
s103
it's
a
DTS
region,
and
then
they
have
been
also
updated
on
the
maximum
fragment
lengths
extension,
which
became
the
record
size
limit
extension,
which
is
a
mechanism
to
reduce
or
indicate
on
how
much
RAM
at
beer
has,
which
is,
of
course,
also
a
limiting
resource
on
an
IOT
device,
doesn't
have
a
huge
amount
of
RAM.
B
So
that's
good
to
know
for
the
other
side,
and
so
there
was
a
new
RFC
published
by
the
TLS
working
group
there,
which
I
think
we
should
sort
of,
because
the
previous
recommendation
sort
of
what
a
previous
previous
RFC
recommended,
the
use
of
the
mm
and
at
a
maximum
fragment
lengths
extension
for
exactly
that
reason,
and
then
there's
this
topic,
which
interest
is
a
coincidence,
I
would
say,
has
been
discussed
extensively
on
the
TLS
mailing
list.
The
last
couple
of
days
and
we
exist-
is
optimized
free
transmission,
stern
handshake,
which
so
just
deal
detail.
B
B
B
But
who
knows
what
they
will
come
up,
and
there
are
a
few
things
that
mentioned
to
me
already,
for
example,
specifically
on
the
use
of
sort
of
certificates,
certificates
that
are
put
into
the
devices
doing
manufacturing
and
then,
unfortunately,
for
lifetime.
That
is
too
short,
and
so
when
they
leave
their
the
department
store.
They
actually
already.
You
suddenly
turn
on
the
device
and
it
has
expired
certificates.
So
that's
an
issue,
some
problems.
B
D
B
B
B
If
we
just
want
to
say:
oh
there's
something
there
as
well,
it's
working
progress
that
may
be
fine
if
it's
more
documenting
sort
of
like
best
current
practices
in
in
CTLs,
then
I
agree
with
you
I
think
it's
more
in
the
line
of
why
I
was
thinking
more
in
the
line
of
the
former
for
that
purpose
in
the
same
I
think
also
what
the
work
that
Shaun
has
been
doing
and
also
I,
think
I
said
a
certificate
compression.
That's
a
newest,
that's
newer
stuff,
so
this
would
be
more
like.
B
D
B
A
E
A
B
A
D
A
A
I
know
choice
you
wanted
that
Mike
Tim,
but
that
he
would
also
be
curious
to
see
the
experience
and
issues
in
character
by
that
by
IT
companies.
All
right,
I
haven't
seen
any
anyone
disagree
and
we'll
send
out
the
usual
confirmation
email
to
the
list,
but
it
does
sound
like
you
should
be
prepared
to
resubmit
as
a
working
group
document
honest-
and
it
is
a
bit
and
with
that
we
are
switching
over
to
seaboard
compression
of
RFC
29
25
29
25
profile,
x.509
certificates,
that's
a
mouthful!
So
thank.
G
You
yeah,
so
this
is
mainly
about
draft
Matson,
TLS
Siebel
cert
compressed
and
which
uses
draft
Rosa,
OCC
bore
and
resources
who
see.
Draft
current
plan
is
to
merged
all
of
these
and
resubmit
to
cozy,
but
more
about
later
so
next
slide,
and
this
is
quite
relate
to
them
to
the
last
presentation-
the
TLS
profile,
because
this
SIBO
compression
is
aiming
for
them.
G
G
It
registered
a
new
compression
algorithm
for
the
TLS
compression
mechanism,
so
how
this
is?
This
is
from
a
TLS
perspective.
This
is
just
a
new
compression,
algorithm
or
and
how
you
negotiate.
It
is
clear
this
would
then
probably
get
number
four
or
something
unless
somebody
else
is
registering
a
compassionate
with
yeah.
G
Aim
is
to
support
all
RFC
795
profile
certificate
and
the
reason
why
a
new
compression
algorithm
is
necessary
is
that
general-purpose
compressional
widths
does
not
compress
these
highly
profile
certificate.
Much
at
all.
If
anything
and
the
submitted
is
dropped.
The
coop
see
working
group
has
decided
to
take
on
this
work
currently
reshot
ring,
and
this
is
basically
the
me
I
think
this
is
the
only
thing
the
working
group
will
focus
on
accept
standard,
registering
new
al
goods.
So
next
slide.
G
If
you
can
see
example
of
so
to
the
left,
you
have
a
or
fc7
token
five
profiles
advocate
taking
314
bytes
cept
Lib
doesn't
compress
it
well
as
much
at
all
in
this
example
19%,
and
that
is
actually
one
of
the
best
results
we
had
for.
Sadly,
by
changing
some
of
the
bytes
in
strings,
in
the
examples
that
we
get
that
live
often
increased
the
size
instead
by
Rhian
coding
everything
into
a
c
ball,
we
can
get
over
50%
in
this
case,
57%.
G
So
you
there's
a
one-to-one
mapping
between
this
next
slide,
which
is
the
main
discussion
so
is
so
the
main
thought
is
to
do
this
now
in
the
cosy
working
group
and
to
register
this
compression
algorithm
in
TLS
Coetzee.
So
it
is
interesting
for
TLS
103
CTLs,
I
would
say
yes
so
far-
seems
to
be
interest.
G
Okay,
to
make
such
et
les
I
on
a
registration
from
cozy.
Formerly
it's
definitely
okay,
but
of
course
Utah
or
TLS
should
state
that
they
want
is
I,
don't
think
there
was
any
meaning
to
have
a
separate
draft
in
the
TLS
or
Utah.
Registering
this
in
Guyana.
That's
not
very
interesting.
It's
better
to
inform
LS
utilities
is
happening,
and
if
they
have
any
comments
on
the
actual
compression,
the
next
question
I
think
is
already.
G
The
new
version
of
rock
opening
is
using
or
fc7
95%
certificate
profile
in
the
next
things
or
things
that
we
noticed
by
trying
to
compress
seven.
Nine
to
five
first
point
is
that
ace
and
Bonfim
jim
would
be
extremely
beneficial,
I
think
not
only
for
this
compression,
but
also
rather
trying
to
implement
the
profile.
I
would
and
I
think
right.
Now
we
have
that
in
Roger
also,
it
would
be
more
sense
to
actually
have
it
in
that
in
an
in
draft
softening
updating,
795
other
and
then
there's
the
rest
is
more
minor.
B
A
G
A
I
think
pointed
out
by
several
people
that
the
working
group
is
probably
looking
for
a
revision,
a
first
duration
which
doesn't
include
any
references
to
the
CTLs
work,
and
only
after
that
you
know.
So
you
know
how
much
of
what
you're
talking
about
now
is
only
in
CTLs
space,
and
with
that
you
know.
How
would
that.
G
G
Yeah
having
a
sand
one
and
making
the
having
a
certificate
profile
in
the
draft
and
making
that
very
strict
and
consists
would
be
very
good.
I
think
there
is
more
input
to
the
doc
Japanese
and
also
information
to
the
yuta
working
group
that
this
is
happening
likely
to
happen
in
the
koozie
barking
group.
C
G
Otherwise,
TLS
working
group
does
not
really
need
to
do
anything.
The
registration
space
in
Ayane
is
I,
think
is
it
can
be
done
from
cozy
also
but
and
I.
Don't
think
there
is
any
meaning
to
have
a
dragging
that
to
TLS
also,
but
unless
the
TLS
working
group
would
like
that,
I
will
I
will
check
with
the
chairs
if
they
want
to
short
presentation
of
this.
At
some
later
point.