►
From YouTube: IETF99-UTA-20170720-1810
Description
UTA meeting session at IETF99
2017/07/20 1810
https://datatracker.ietf.org/meeting/99/proceedings/
A
B
If
you're
here
for
something
else
and
or
get
bored
by
TLS,
you
know
find
something
else
there
and
I
guess
we
have
Alexi
in
the
house,
so
it
means
we
can
get
started
so
you'll
notice
that
I'm
not
here
well
by
my
lonesome
today,
and
that's
because
my
co-chair
couldn't
make
it
here
for
a
personal
reasons,
so
be
gentle.
The
blue
sheets
are
going
round
and
and
I'll
ask
your
help
to
keep
an
eye
on
the
meet
echo
Q,
because
you
know
a
little
bit
about
wide
the
wide
angle
of
your
work
here.
B
So
you've
all
seen
the
note.
Well,
you
know
what
it
means
take
care.
We
have
a
pretty
packed
agenda
today,
so
we'll
have
to
sort
of
speed
up
and
keep
to
our
times.
The
I
thought
I
actually
would
start
with
a
quick
look
at
see.
If
I
can
do
that,
a
quick
look
at
our
document
status,
even
though
it's
sort
of
big,
let's
see
if
that
works,
all
right.
Something
like
that.
B
As
you
will
know,
we've
published
a
few
RFC's
in
this
work
working
group.
We
have
a
few
active
drafts
in
the
email
field,
and
one
of
them
is
in
working
group
last
call
the
TLS
reporting
we're
gonna.
Do
a
quick
for
hopefully,
a
quick
discussion
on
the
kV
vs.
Jason
issue
today
and
we're
also
gonna
do
run
through
a
deep
and
let's
see
if
I
can
get
this
back
in.
B
And
we're
also
going
to
do
a
quick
update
on
the
Iroquois
TLS
draft
as
I
stood
up
and
said
in
Sag
I.
Think
after
we
get
the
email
work
done
and
we
can
sort
of
see
that
on
the
horizon
there
isn't
that
much
sort
of
obviously
left
without
working
up
to
do
so.
If
you
in
your
various
networks,
know
about
people
who
are
thinking
about
bringing
stuff
to
UK
tell
them
it's
time
to
do
that
right
away.
B
Certainly
before
Singapore,
all
right,
I
haven't
actually
put
any
time
in
the
agenda
for
discussion
on
TLS
reporting
because
it
isn't
working
your
last
call.
If
you
do
have
things
there
do
send
it
to
the
menu
list.
So
with
that
I,
let's
see
do
we
have
some
of
the
people
from
the
the
TA
MTA
SDS
draft.
B
B
C
D
Artisan
in
CNL,
so
I
read
the
security
considerations
for
the
yes,
yes
draft
and
I
have
a
question
about
that.
I
I
get
the
feeling
that
there
is
a
difference
in
the
security
you
get.
If
you
use
tofu
between
having
a
lot
of
mail
and
seeing
a
lot
less
mail-
and
that's
not
the
case
for
start
Els
Dane.
So
it
is,
it
is
a
difference
and
the
start
of
the
document
points
to
the
Security
section
as
the
section
which
discusses
all
of
the
differences.
B
B
All
right
so
there,
in
the
absence
of
vigorous
discussion
here,
I'm
just
gonna,
do
a
get
a
sense
of
the
room
about
the
KB
vs.
Jason
issue.
So
as
you've
all
seen,
the
the
draft
authors
proposed
alternative
text
that
had
a
a
an
alternative
representation
of
the
same
data
that
goes
in
the
current
JSON
format.
So
you
made
a
good
point
there
Chris,
who,
in
the
current
who
here
or
on
job
role
remote,
have
like
read
both
proposals.
B
B
B
B
B
B
F
Think
this
is,
this
is
a
better
way.
It's
not
quite
bike
shed,
but
it
the
format
is
unlikely
to
be
extended
unless
people
have
examples.
So
I
think
that
the
point
about
you
know
part
of
the
decision
to
help
us
is
how
likely
this
is
going
to
be
extending
and
what
kind
of
data
we're
going
to
see
there.
F
B
All
right
so
Victor
for
you
and
for
everybody
who
might
be
joining
late
and
it'd,
be
helpful
if
you
would
reflect
the
list
on
on
the
average.
So
it
is.
This
is
the
time
to
speak
up.
If
you
have
strong
opinions
about
this,
if
you
don't
have
any
strong
opinions
either
way,
then
we
can
do
whatever
you.
B
F
B
B
All
right,
so
it
doesn't
seem
like
we
can
profitably
sort
of
conclude
this
here
but
I
to
me.
It
sounds
like
we
don't
have
strong
consensus
to
make.
A
change
will
confirm
that
on
the
list
that
may
change
depending
on
who
actually
turns
up
for
a
discussion
on
the
list,
all
right,
I
think
that's
all
we
can
actually
do
here.
B
H
H
I
tried
to
make
it
a
BCP
and
I'm,
not
really
sure.
I
was
successful
because
making
a
piece
making
the
document
of
BCP
pretty
much
meant
taking
out
all
the
protocol,
bits
and
Chris,
argues
and
I
think
I
agree
with
him
that
without
I
actually
left
some
protocol
bits
in
there,
but
that's
kind
of
a
bit
risky
I
think
because
things
that
are
actually
protocol
should
be
on
the
standards
track,
so
that
can
be
subject
to
interoperability
tests
and
that
kind
of
critical
review.
H
But
this
was
an
attempt
to
rewrite
the
document
as
a
BCP.
The
biggest
change
is
that
the
STS
stuff
has
now
been
removed.
I
did
get
a
little
feedback
in
private
mail.
That
said
that
they
didn't
the
the
person
said.
You
know
our
company
is
not
likely
to
implement
this
because
of
the
SES
stuff.
It's
just
not
enough
value
for
us
and
I
was
wondering
if
a
lot
of
this
sort
of
pushback
on
that
document
was
for
the
SES
stuff,
which
I
think
is
useful,
but
maybe
not
so
much
needed
in
the
near
term.
H
So
anyway,
it's
not
in
version
0,
7,
make
sure
didn't
miss
anything.
Okay,
go
ahead,
yeah,
so
it's
the
same
goal.
If
anything,
I
actually
tried
to
make
the
statement
a
little
bit
clearer,
basically
clear
text
for
interactions
between
the
mail
user
agent
and
the
mail
service
provider
should
be
considered
obsolete.
In
most
cases,
there
are
some
corner
cases
for
which
you'll
still
need
to
do
it.
If
you're,
if
you're
with
legacy,
clients
or
appliances,
they
can't
be
upgraded
but
I.
H
Can't
you
know,
aside
from
those
corner
cases,
it
seems
like
the
best
current
practice
really
is
you
should
encrypt
this
traffic?
You
should
encrypt
it
using
TLS
and
we
will
argue
further.
You
should
probably
do
this
using
implicit
to
us,
although
if
you
start
TLS,
that's
still
still,
okay
and
I-
guess
the
other
bit.
Is
that
there's
still
the
text
in
there
about
for
465
as
sort
of
the
the
best
way
forward
to
to
use
submission
over
TLS,
so
there's
still
sort
of
a
conflict
over
that
port,
but
the
language
hasn't
changed
so
next
slide.
H
So,
in
summary,
the
best
current
practices
for
mail
service
providers
provide
implicit
unless
versions
of
the
services
also
provides
start
TLS
versions,
at
least
in
the
near
term,
advertise
these
services
using
DNS
server
records,
advertise
the
TLS,
a
records
if
they're
signed
by
DNS
SEC,
so
that
they
can
use
Dane
and
deprecated
in
quotes
clear
text,
mail
services
as
soon
as
practicable.
So
if
you're
a
mail
service
provider,
this
is
sort
of
saying
you
should
we
in
your
users
off
of
clear
text,
mail
services.
But
what
that
means
is
up
to
you.
H
Okay
and
for
mail
user
agents,
you
know
support,
serve
record
discovery
for
discovering
configurations,
except
you
should
prefer
TLS
and
on
TLS
you
should
try
to
set
up
a
configuration
which
actually
encrypts
the
traffic,
and
this
notion
of
a
minimum
level
of
confidentiality
is
still
in
there.
Although
it's
a
bit
simplified
from
version
6,
but
basically
you
should
you
should.
H
If
you're
expecting
confidentiality
offer
this
mail
account,
you
should
require
at
least
TLS
point
1.1
and
have
a
valid
certificate,
and
if
you've
got
the
mail
account
configure
to
require
this
confidentiality
level,
then
you
shouldn't,
you
know.
If
you
don't
get
those
conditions,
you
shouldn't
try
to
read
mail
right.
There
shall
I
finish
or
you
won't
yeah
yeah.
I
H
And
that's
I
think
that
requirement
is
specific,
where
you're
encouraged
to
use
the
Ennis.
Oh
sorry,
you
said
DNS
serve
and
I
heard,
DNS
sick,
sorry,
DNS
server
records
is
just
a
discovery
mechanism
for
two.
So
to
help
mail.
User
agents
find
the
right
services
to
use
for
this
particular
mail
service
provider.
So
I
think
it's
useful
and
we
want
to
encourage
this
use
and
it
can
help
it
can
help.
You
find
the
TLS
versions
of
these
services.
That's
the
benefit.
H
And
then,
okay,
so
back
to
where
it
was,
if
you
don't
have,
if
you're
not
requiring
this
minimum
level
of
confidentiality
on
a
mail
account,
then
you
still
encouraged
to
use
opportunistic
encryption
and
if
you
do,
if
your
mail
user
agent
and
you
find
that
this,
this
set
of
mail
services
provides
TLS,
then
you're
sort
of
you're
encouraged
to
offer
the
user
a
chance
to
upgrade
to
require
that
confidentiality
rather
than
just
do
it
opportunistically
and
I.
Think
that's
it!
That's
the
that's
the
center!
E
Your
on
chef,
I
haven't
been
following
the
list,
so
I
apologize
in
advance
its
and,
let
me
know
if
you've
beaten
this
horse
to
death.
Tls
1.1
is
kind
of
strange.
Are
7525,
insists
on
TLS
1.2
in
that
browser
world
as
early
people
doing
TLS
1.1
people
are
you
thrown
1.0
1.2?
So
here
you
had
this
discussion.
No.
H
J
Neil
Jenkins,
just
having
quick
look
about
the
on
the
implicit
TLS
versus
start
TLS
thing.
I
agree.
We
should
recommend
simplicity
versus
is
better.
It
was
less
chance
that
passwords
and
credentials
get
sent
in
clear
text
with
regards
to
being
able
to
do
start,
TLS
kind
of
for
now,
I,
don't
actually
think
IMAP
or
pop
any
clients
who
are
doing
start
TLS
with
that,
it's
only
really
SMTP
where's
the
jar
seems
to
be.
We
found
all
three.
You
don't
think
that.
I
D
H
J
B
J
G
On
the
same
topic,
this
is
the
company
we've
spent
about
a
decade
and
a
half
now,
at
least
in
the
Pacific's
community
training
users
to
do
submission
and
587
I,
don't
think
it's
anything
will
quickly
be
able
to
reverse
so
I'm.
Not
seeing
a
rapid
migration
back
to
465
is
that
even
remotely
plausible
I
think
587
is
here
to
stay
for
a
long
time
as
for
star
TLS
for
IMAP,
it's
used
and
supported
it's
out.
G
A
H
K
G
C
Do
it
and
why
bother
now
what's
deployed,
you
know
if
you
go
look
at
the
ISPs
out
there,
it
surveyed
the
ISPs
I'm
a
pass
and
pop-ups
are
much
more
widely
implemented
than
start
start
TLS
on
I'm,
Evan
pop.
So
in
for
those
two
protocols,
if
we
wanted
to
drill
down
in
the
details,
we
could
say
yo,
don't
you
know
server?
Should
servers
shouldn't
bother
doing
this
if
they
haven't
already
done
yeah
but
for
Assam
dpi,
chromatic
Victor's
right
that
you
know
it's
not
gonna
go
away
in
the
future.
L
Al-Insana
just
a
comment
on
the
earlier
comment
with
regard
to
the
TLS
version
and
the
best
back
pass
current
practice
document
recommending
tillis
one
point:
one
point
two
is
even
from
this
working
group,
so
I
think
we
should
hear
that
I
haven't
read
this
document,
but
because
I've
been
out
of
the
loop
from
UTA
for
like
the
last
six
months,
but
I'll
do
so
and
provide
comment
on
the
mailing
list.
Thanks
yeah.
M
H
J
English
Incans
I
think
the
idea
as
I
understood
it,
although
maybe
this
is
not
fully
expressed
in
the
draft-
is
that
clients,
the
Akoni
set
up
on
insecure
connections,
could
automatically
detect
that
this
domain
has
a
secure
option
and
then
offer
to
upgrade
it
and
without
the
auto'
discovery
or
mechanism
they
would
have
to
manually.
Do
that?
Okay.
E
H
C
Okay,
the
one
other
issue
I
wanted
to
raise
about
this
is
the
the
status
of
the
document.
I
really
think
this
is
a
standard
track
document.
It's
about
one
third
standards
track,
two
thirds
BCP,
but
as
a
whole,
it's
a
very
it's
a
it's.
A
good
document.
I
actually
think
I
do
think
removing
the
STS
from
the
spec
made
it
made
it
a
better
spec,
so
good,
good
job,
editing.
This
way
keep
edited
this
this
round
of
it,
but
I
think
this
is
a
standard
track
document
yeah!
It's
you
know!
It's
me.
It's
register
it.
C
You
know
it's
registering
a
port,
it's
it's
prescribing
rules
for
client
certificates,
so
that
so
that
you
have
interoperability
it
you
know
it's.
It's
got
a
bunch
of
protocol
stuff
in
there
and
so
I
think
it's
I
think
it's
standards
track.
Yeah
I
wanted
to
see
if
anybody,
if
anybody
had
a
strong
feeling,
the
other
way.
H
And
I'll
say:
I
concur
with
Chris
I
mean
having
tried
to
make
it
a
BCP.
I
really
didn't
feel
like
I
could
take
out
all
the
protocol
bits
and
not
lose
some
very
important
details,
so
I
feel
like
a
standards
track
document
can
make
recommendations
in
private
about
practice,
but
a
BCP
can't
really
define
protocol
because
then
it's
not
subject
the
same
process.
H
B
F
E
B
I
B
I
E
B
We
did
actually
have
a.
We
did
actually
have
that
this
discussion
and
it
wasn't
peer
from
or
the
working
group
discussion
whether
we
actually
made
a
consensus
called
lost
time
to
change
it
or
not
right
so
I
think
it
was
a
good
idea
to
confirm
all
right
all
right,
any
other
questions
or
discussions
about
this
question.
H
B
N
F
C
C
C
B
E
F
M
M
M
And
so
the
idea
is
that
it's
that
it's
fine-grain,
you
specify
it
on
a
on
a
particular
message
and
we
have
some
some
control
over
the
way
that
you
express
some
some
requirements
with
respect
to
how
certificates
are
verified
and
it's
an
MTA
to
MTA,
only
sort
of
thing
next
slide
and
the
approach
is
that
there's
a
service
extension
called
require
TLS
and
you
specify
it.
You
negotiate
it
like.
M
M
Okay,
what's
new
about
it,
really
very
little.
I
haven't
had
time
really
since
Chicago
to
do
basically
any
work
on
require
TLS,
but
I.
Consider
that
this
solves
an
important
problem
and
it's
something
that
I
that
my
commitments
are
changing
and
I
I
do
intend
to
return
to
in
terms
of
at
least
the
document,
if
not
working
with
a
couple
of
implementers
that
that
we
have
next
slide.
M
So
what
I,
here's
here's,
my
my
ask
basically
is:
can
we
adopt
this
as
a
working
group
document
I
believe
that
it
solves
a
different
problem,
because
it's
sender
side
and
and
much
more
fine-grained?
We
have
a
couple
of
implementations.
There
is
some
maturity
to
the
spec
and
I
believe
that
it's
consistent
with
the
goals
of
the
working
group
and
that's
really
the
the
key
slide
for
the
for
the
presentation.
I
just
wanted
to
kind
of
T
it
off
with
a
little
bit
of
background
first.
So
that's
it.
B
B
All
right
now
that
is
that's
here
in
our
agenda.
That
is
actually
it
we're
at
open
mic.
Now,
a
couple
of
couple
of
points
I
didn't
mention
that
we
should
be
thinking
about
our
sunset
Sun
setting
this
group.
We
are
heading
towards
working
group
law
school
for
for
most
of
our
documents
and
we
have
required
here
less.
You
know
it
will
be
me.
It
will
mean
that
we're
around
for
one
or
two
meetings
more,
but
maybe
not
that
many
and
I
mean
or
it
discussed
we
could
or
should
do
next
and
with
rot
our
feelers.
I
B
Q
C
G
Bad
STS
you've
heard
my
support
for
the
kV
already
the
main
culprit
for
that
arguments.
I'm
not
gonna,
discuss
that
further.
For
the
moment,
I
just
want
to
point
out
that
this
one
issue
we
also
haven't
quite
closed
on
and
perhaps
I've
failed
to
explain
it
properly
for
everybody.
But
it
seems
to
me
that
there
isn't
currently
a
clean
way
to
just
continue.
G
An
STS
policy
and
I've
tried
a
number
of
times
to
motivate
a
special
value
of
max
age,
zero
as
signaling
that
the
STS
policy
should
be
deleted
from
any
cash
that
encounters
a
max
age,
zero
cleanly
without
lots
of
warnings
about
failing
to
connect
with
HTTP
resource
or
not
finding
stuff
there
and
various
other
ways
of
trying
to
flush
it
out
that
don't
look
nearly
as
robust
to
me.
So
I
think
we
should
try
and
get
closure
around
that
now.
G
I
O
N
I
B
Now,
I,
don't
know
whether
you
guys
heard
me
when
we've
had
this
on
the
earlier
in
the
meeting
and
I
think
at
this
point
there
is
not
clear
consensus
to
make
a
change.
I
think
we've
heard
Victor
express
a
strong
preference
for
at
least
a
preference
for
the
KD
format.
Very
few
people
who
are
stepping
up
today
to
oppose
that
or
to
say
other
things
or
just
we
didn't
support
that
and
I
think
we
need
in
order
to
change
this
and
I'm
gonna
say
this
one
more
time
in
order
to
change
what
the
drought
says.
B
I
Says
we're
pretty
neutral
on
one
hand,
KB's
ready
that
requires
custom.
Parsers
Jason
is
also
ready
and
fires
third-party
parsers,
which
is
either
a
plus
or
minus.
We
being
the
authors.
Also
aaron
emphasized
that
he's
been.
You
know,
out
of
the
loop
for
six
months,
he'll
come
back,
read
the
doc
and
also
express.
K
I
B
C
Chris
Newman,
just
for
humor
value,
I
just
did
a
word
count
on
the
key
on
the
key
value:
parser
and
the
JSON
parser
library.
In
my
code
base
and
the
JSON
parser,
it's
smaller
the
key
value,
but
the
key
value
parser
handles
a
bunch
of
variant
key
value
formats.
So
that's
why
it's
larger,
but
anyway
it's
yo.
This
is
not
a
significant
amount
of
code.
C
C
F
B
B
E
So
Danielle
amigo
and
I
I'm
Ron
Schara,
published
a
draft
called
ticket
pinning
which
uses
something
similar
to
tearless
such
an
resumption
tickets.
To
pin
the
server's
identity
well
think
of
it
as
certificate
pinning
with
some
twist
two
twists.
Actually
one,
and
this
is
easier
to
automate
and
then
HP
KP
HTTP
is
an
RFC
on
certificate.
Pinning
that
has
not
seen
wide
wide
adoption
to
say
the
least,
and
the
other
twist
is
this-
is
that
the
TLS
level,
as
opposed
to
HP
KP?
So
it
may
be
appropriate
for
other
protocols.