►
From YouTube: IETF98-UTA-20170328-1450
Description
UTA meeting session at IETF98
2017/03/28 1450
A
B
C
E
A
A
A
F
G
G
A
F
Do
thank
you
very
much
cool,
so
I
do
quality.
I
hope
is.
Ok
I
wanted
to
apologize
that
none
of
us
are
able
to
be
there
in
person,
but
hopefully
this
works.
Alright,
so
I'm
going
to
give
a
brief
overview
of
both
TLS
rpt
and
the
STS
draft
serve
as
they
stand,
I
think
for
a
lot
of
people
in
the
audience.
This
is
probably
familiar,
and
so
hopefully
you'll
kind
of
bear
with
me,
but
I
wanted
to
just
give
sort
of
some
background
first.
So
next
slide.
If
you
would
please.
F
The
second
draft.
I
think
that
the
sort
of
larger
one
is
MTA
SDS,
which
is
for
strict
Transport
Security
for
server
to
server
smtp,
and
the
idea
here
is
to
provide
some
guarantees
about
what
kind
of
server
authentication
and
what
kinds
of
encryption
you
can
expect
change
servers.
So
next
slide.
If
you
would
so
sort
of
a
refresher
of
people
again,
I
think
not
everybody
in
the
audience
is
super
familiar
with
this
stuff,
but
I
think
there
are
basically
multiple
opportunities
with
the
way
that
server
to
server
has
interview
works
today
for
mana
mental
attacks.
F
So
the
obvious
one.
If
the
recipient
terrain
is
not
using
DNS
seconds
and
there's
not
validating
it
is
MX
injection.
Have
the
sender
speak
to
your
host
instead
of
the
actual
host?
Another
option,
of
course,
is
to
do
a
downgrade
attack
at
some
point
along
the
way.
Bgp
injection
simply
serving
you
know
pretending
to
be
the
recipient
host,
but
serving
assert
that
matches
your
host
and
not
that
not
the
actual
recipient
works.
Fine,
because
pretty
much
nobody
absent
dane
today
does
certificate
validation.
F
You
know
requires
TLS
in
any
manner
and
and
so
I
think
in
the
last
sort
of
handful
of
years,
we've
seen
that
opportunistic
TLS
in
the
form
of
start
TLS,
has
really
taken
off
and
is
really
widely
deployed,
which
is
great,
I,
think
it's
really
good
for
sort
of
preventing
passive
and
the
middle
attacks.
But
you
know
I
think
there
are
sort
of
a
headful
of
attackers
who
are
still
sort
of
able
to
do
active
in
the
middle
attacks
against
specific
targets.
So
next
slide,
please
so
quoting
well.
F
This
didn't
work
out
well,
this
slide
I
think,
but
quoting
from
some
research
that
some
colleagues
of
ours
submitted
to
the
ACM
two
years
ago,
we
had
sort
of
a
survey
of
what
a
creator
btls
danggit
attacks
in
the
wild
by
region,
as
seen
by
incoming
gmail
messages,
and
some
of
the
data
are
missing
from
the
slide.
Unfortunately,
but
I
think
people
are
probably
widely
familiar
with
this
survey,
and
you
know
essentially
like
this
does
happen
in
the
wild.
F
I
think
we
think
that
this
is
sort
of
something
of
a
real
threat,
that's
kind
of
the
main
motivator
for
this
work.
I
also
want
to
call
out
that
in
the
in
the
frame
of
TLS
rpt,
one
of
the
main
points
is
actually
just
to
get
this
kind
of
insight
on
an
ongoing
basis.
So,
instead
of
gmail
sort
of
able
to
see
this
because
we're
a
big
provider-
and
we
have
a
lot
of
users-
you
know
we'd
like
to
actually
have
a
standard
where
people
could
sort
of
get
this.
F
So
all
of
that
said,
STS
in
a
minute
or
less
I,
think
you
have
a
txt
record
on
your
on
your
recipient
domain,
indicating
you
participate
in
sts
and
indicating
the
latest
version
of
the
policy
that
you're
serving
you
have
an
HTTPS
endpoint,
actually
serving
the
policy
effectively
and
there's
sort
of
a
handful
of
things.
I
want
to
call
out
about
how
this
works
effectively.
F
The
policy
says
whether
you
expect
to
have
encryption
and
what
centers
should
do
if
it's
not
present,
if
they
should
actually
continue
to
deliver,
but
tell
you
about
it
with
TLS
rpt
or
if
they
should
actually
not
deliver
messages.
It
specifies
what
the
expected
identity
is
of
the
MX
hosts
and
there's
sort
of
an
open
question
on
this
point.
F
Next
slide,
please
so
TLS
rpt
in
about
five
seconds.
It's
basically
like
DMark,
you
say
I'd
like
to
receive
reports
about
failures,
send
them
here
and
reports
have
some
sort
of
predefined
semantics
for
failure,
categories
and
I
think
you're,
basically
fairly
verbose,
fairly
free
form,
and
we
expect
people
to
share
a
relevant
information
about
TLS
negotiation
failures
of
all
sorts.
F
You
know
not
be
able
to
find
a
cypher.
You
agree
on
not
having
a
certificate
that
validates
according
to
dinner
or
SDS
of
that
kind
of
thing.
So
next
slide,
so
current
status,
I
think
there's
been
actually
a
lot
of
traffic.
Quite
recently,
maybe
no
surprise
on
the
UT
a
mailing
list
about
this,
but
worse
on
version,
3
of
the
drafts
and
I
think
both
I
mean
22.
F
Points
I
want
to
point
out
is
that
we're
sort
of
working
at
Google
and
a
handful
of
other
providers
on
pilot
implementations
and
we'd
actually
really
like
to
sort
of
settle
things
enough
that
we
can
launch
code
without
worrying
about
formats
changing
too
much
I.
Think
the
other
thing
is
I
read
says
were
really
trying
to
sort
of.
F
F
So
the
fur
open
question
is
fairly
sort
of
aesthetic,
I
would
say,
but
I
think
an
important
one.
Obviously
people
sometimes
feel
strongly
about
this.
The
policy
as
shown
in
that
screenshot
earlier
is
JSON.
We
picked
this
basically
because
its
standards
track
and
it's
widely
implemented
and
I-
think
everybody
especially
sort
of
security
minded
people
felt
like
asking
people
to
write
their
own
parsers
is,
you
know
not
totally
desirable.
F
On
the
other
hand,
I
think
I
think
the
alternative
proposal
we're
entertaining
right
now
is
basically
key
value
pairs,
not
a
complicated
parser,
widely
implemented
by
MTA's
I.
Think,
potentially,
some
downsides,
not
tremendous
ones,
potentially
some
upsides
again,
not
tremendous
one.
So
I
see
this
is
sort
of
not
a
really
really
pressing
argument,
but
I
think
we'd
like
to
sort
of
basically
get
feedback
and
reach
them.
Consensus
I
think
the
main
points
raised
by
proponents
of
the
the
key
value
pair
approaches
that
a
lot
of
MTA
is
deployed
on
sort
of
smaller
footprint
servers.
F
F
Open
question
number
two
and
and
this
one's
a
little
more
nitty-gritty
but
I
think
we've
mostly
resolved
it,
which
is
victa.
Do
company
had
I
think
a
very
good
suggestion
that
the
semantics
of
the
sort
of
MX
constraint
that
we
have
in
the
policy
as
we
originally
designed
it.
It
was
a
constraint
on
the
hostname
and
the
hostname
should
match.
You
know
this
list
of
valid
MX's
and
should
present
a
certificate
which
matches
its
own
name
and
I.
F
It
matches
like
the
domain
that
the
mailbox
is
at,
and
so
we
sort
of
want
to
make
it
easy
people
to
deploy
this
without
having
to
deploy
new
certificates.
So
I
think
there's
a
pretty
compelling
argument
for
making
this
change
and
I've
actually
already
made
this
change
in
the
current
sort
of
github
version
of
our
draft.
F
But
again,
I'd
like
to
sort
of
get
feedback
from
people
on
this,
and
I
think
the
big
counter-argument
to
this
approach
actually
is
that
we're
suggesting
people
implement
sort
of
custom
certificate
matching
logic
and
in
particular
the
MX
list
could
have
a
wild
card
like,
as
shown
here,
anything
that
example.com
and
the
certificate
could
have
a
wild
card,
and
so
there's
kind
of
this
possibility
of
wild
ride.
The
wild
card
matching,
which
might
be
sort
of
mild
and
complicated.
So
I
think
these
are
the
main
open
questions.
G
F
So
I'm
happy
to
take
questions
now.
I
think
that
the
remaining
slides
of
people
are
curious
is
sort
of
where
we
on
the
implementation
stage
I'm
having
talked
about
it
but
I
think
we
gave
the
slides
actually
before
and
we
have
sort
of
minor
updates
and
that
we're
farther
along
than
the
pigmentation.
So
maybe
so
the
phone
seems
so.
G
I
F
Obviously,
because,
like
I
think,
if
I
remember
right,
HST
s
doesn't
have
an
expiration,
but
we
were
sort
of
worried
about
the
possibility
that
you
sort
of
keep
yourself
in
the
foot
and
can't
receive
mail.
You
know
ever
so
now.
You
can
update
a
policy
as
long
as
you
have
a
certificate
for
your
domain,
but
seems
safe
to
have
a
max
age.
G
A
A
K
Alright,
thanks
so
about
the
Jason
issue.
The
main
thing
I
wanted
to
make
sure
is
that
the
folks
who
are
addressing
it
really
are
focused
on
mta's,
as
opposed
to
some
other
hypothetical
environment
in
which
they
might
like
to
see
Jason,
because
you
know
if
it's
just
sexy,
because
you
write
all
your
Python
code
in
you
know,
with
Jason,
but
you're
not
planning
to
write
a
Python
MTA,
then
you
know
really,
you
know,
enjoy
Jason
elsewhere.
So
I
hope
that
people
come
at
this
with
a
very
practical
viewpoint.
L
Hi
this
is
Jim
Fenton,
so
I
have
a
question
about
TLS
important.
What
about
and
what
about
sts
they
in
the
reporting
graph.
We
have
a
an
existing
example
of
a
policy
that
calls
for
reporting
in
D,
mark
and
I
was
wondering
if
you
had
and
I
apologize,
I
still
haven't
gone
through
and
then
a
detailed
review,
but
how
this
compares
with
the
DMark,
because
one
of
the
things
that
I
noticed
isn't
there
that
day
mark
has
is
the
ability
for
a
recipient
of
a
report
to
advertise
their
willingness
to
accept
reports
from
certain
domains.
F
F
Wavy
I
had
sort
of
a
more
solid
argument
for
specifically
why
we
thought
this
wasn't
necessary
when
we
discussed
it
I'm
happy
to
dig
it
out
of
my
email
and
share
with
you,
but
I
think
we
felt
that
because
the
the
person
sending
the
reports
is
actually
a
person
already
sending
the
mail
to
begin
with,
there
wasn't
an
opportunity
to
trick
somebody
else
that
is
sending
a
report
for
you.
Unless
they
send
you
mail
right.
L
F
I
think
that
yes,
I,
think
that
leads
me
to
the
point
actually
said.
Instead,
it
more
clearly
now
that
I
have
it
back
in
like
sort
of
in
my
head.
The
point
is
basically,
if
I
wanted
to
get
you
to
send
reports
to
somebody
else
to
spam
them,
you
would
have
to
send
me
a
bunch
of
mail
anyway,
and
it
seemed
unlikely
that
you
would,
as
a
good
person,
send
me
the
malicious
person.
A
lot
of
mail
and
I
would
sort
of
have
TLS
failures,
and
then
you
would
sort
of
send
them
somewhere
else
right.
F
So
it's
sort
of
didn't
and
on
the
on
the
flip
side,
for
sort
of
somebody
else
being
able
to
receive
my
mail.
My
reports,
I'm
sorry
4d
market
makes
sense
because
people
receiving
demark
reports
may
not
themselves
have
a
male
receive
infrastructure.
But
here
are
the
only
people
interested
in
receiving
reports
of
those
who
are
receiving
l
anyway.
So
hopefully
that
makes
sense.
L
Okay,
my
other
question
I,
have
that
have
some
question
about
sort
of
4
4
sts
about
the
deployment
dynamics
of
of
the
enforce
mode.
I
I
just
have
this
feeling
that
you
know
they're.
Obviously,
there
will
be
particular
particular
domains
that
are
interested
in
enforcing,
but
by
and
large,
no
larger
email
providers
and
so
forth
will
not
be
interested.
L
You
know
they
they
wouldn't
want
to
turn
it
on,
because
all
of
a
sudden,
some
of
their
users
wouldn't
be
able
to
receive
mail
from
certain
of
their
other
users
and
they
get
a
whole
lot
of
complaint
reports.
So
I
guess
my
question
is
sort
of
from
the
standpoint
of
say:
Google
would
Google
Mail
be
likely
to
deploy
a
sts
in
force.
F
So
I
think
it's
a
very
good
question.
I,
don't
know
if
I
could
say
for
sure.
I
would
say
that
you
know
what
are
the
lessons
we've
learned
from,
for
example,
p.
Equals
reject
with
Demark.
Is
that
users
already
confused
about
these
things
and
demarcus
I
think
actually
much
more
confusing,
because
the
the
example
case
that
I've
seen
is,
you
know
you
have
a
gmail
account
set
up
where
you're
from
headers
set
to
your
old
yahoo
account
and
yahoo
switches
on
people's
reject,
and
who
do
you
complain
to
that?
Your
mail
isn't
getting
delivered.
F
You
don't
complain.
The
iou
complied,
the
gmail,
so
I
think
actually
demark
created
a
world
where
users
expectations
were.
You
know,
for
sound
reasons,
sort
of
heavily
violated
and
in
comparison
in
gmail
you
know
we
already
have
a
UI.
That
tells
you
if
we
think
the
the
message
will
be
sent
encrypted.
I
think
it's
less
of
a
change
and
I
mean
to
caveat
that's
heavily
I'm,
not
the
product
manager.
F
Look
I
can't
speak
for
them,
but
I
think
it's
significant
less
of
a
change
to
say
we're
going
to
warn
users
that
this
message
can't
be
guaranteed
to
deliver
this
encryption,
and
you
know,
perhaps
to
tell
people
male
shouldn't
be
sent
at
all.
If
the
other
domain
says
that
they
want
enforcement
and
vice
versa,
so
kind
of
a
hand
wave
your
response,
because
I
can't
say
for
sure
but
I
mean
I
I,
think
that
we.
C
A
All
right,
so,
I
would
like
to
ask
a
couple
of
questions.
Daniel.
Are
you
comfortable
doing
a
couple
of
humps
on
these
two
core
questions,
getting
some
feedback
from
the
room,
so
one
of
the
things
that
I
would
like
to
hear
is
about
if
we
can
step
back
to
the
previous
slide,
starting
with
your
open
question
number
one
of
our
policy
formats,
so
I
want
to
make
sure
we
have
people
in
the
room
or
I
implementing
this
or
planning
to
implement
that.
A
There
are
some
and
and
I'm
assuming
there
are
some
people
on
jabber
or
sort
of
virtually
raising
their
hands
too
yeah
excellent.
So
the
view
people
would
you
prefer
Jason
or
a
key-value
policy
format.
You
can
just
express
your
your
invocation
or
your
preference
by
well
raise
your
hand
for
Jason
and
then
race,
you,
it's
okay,
to
raise
your
hand
for
both
actually
yeah
and
raise
your
hand
for
four
key
value.
We.
A
A
C
Several
more
votes
for
JSON
on
jabber
have
come
in
I'm,
not
clear
whether
they
were
just
whether
they're
on
lag.
There's
an
errand
zahner
also
says
JSON.
Parsing
is
a
potential
security
concern.
There's
one
vote
that
says
just
JSON
and
one
that
says
I
would
really
like
to
avoid
JSON.
So
there's
two
should
go
for
whom
it
sounds
very
serious
and
a
several
more
about
saying
preference
for
JSON,
but
not
like
absolute
all,
right.
G
M
F
M
E
M
F
Know
we
have
we
have
some
code
Whitney,
but
it's
sort
of
six
of
one
half
of
that
doesn't
really
for
us,
yeah,
I,
can't
say
I
care,
I
think
obviously
I'm
in
a
poor
position
away
and
because
Google,
you
know
it's
not
code
that
other
people
are
using
exactly
know.
We
have
our
own
MTA
and
so
it's
sort
of
hard
to
speak
to
like
Victor's
concerns
with
postfix
and
lenox
deployments.
N
My
comment
about
key
value
pairs
is
that
yes,
mta's
implement
a
number
of
versions
as
the
number
of
places
in
MTA,
where
you're
going
to
look
at
key
value,
pairs
and
they're
all
different.
So
in
practice,
what
you
end
up
doing
is
writing
a
slightly
different
parser
for
every
case
that
you
need
to
look
at
key
value
pairs.
The
one
advantage
of
JSON
that
I
see,
which
is
significant,
is
that
at
least
if
this
becomes
a
trend
and
the
future
extensions
use
JSON,
you
only
need
1
parser.
N
The
downside
of
JSON,
though,
is
that
it
now
sort
of
admits
a
number
of
kind
of
silly
cases
that
you
wouldn't
see
before,
for
instance,
a
string
value
you're
expecting
a
string
value,
but
now
it's
a
list
or
something
like
that.
So
you
have
to
take
that
into
account
when
you're
implementing
not
a
bad
thing,
but
it
is
a
different
way
of
thinking.
So
I
don't
have
a
strong
opinion
either
way,
but
I
I
don't
see,
I
mean
at
least
potentially
in
the
future,
there's
a
bit
of
it
for
using
JSON.
O
Quickly,
I
suggest
that
people
who
want
to
key
value
pairs
that
they
write
a
proposal
to
the
mailing
list,
how
it
going
to
look
like
so
I
mean
I,
know
it's
not
a
huge
difference,
but
so
that
we
don't
talk
an
abstract,
something
that
is
specified
because
something
is
not
specified.
Then
we
have
an
incomparable,
strap
this
good
point,
generator
pull
request
or
whatever
enabling
T
it
merited
all.
A
Right
after
that,
passive-aggressive
mad
bit
of
management,
let's
go
and
hit
next
and
see,
go
revisit
the
obesity
know
the
post
versus
identity,
yeah,
alright,
so
the
same
kind
of
feel
from
from
the
room
and
for
again
from
implementers,
you
know:
option
one
option
versus
option
to
show
hosts
vs.
identity.
You
know
you
raise
your
hand
in
preference
for
for
the
first
version
here.
The
the
host
version.
O
F
F
A
O
F
A
A
H
C
A
A
J
N
N
Okay,
so
that's
the
scope
of
the
document
and
there's
basically
two
mechanisms
that
implements
the
first
is
that
the
user
can
specify
a
minimum
confidential
confidentiality
assurance
level
and
the
user
is
not
going
to
see
that
term.
But
the
idea
is
that
you
want
confidentiality
assurance
or
not,
at
least
as
far
as
the
current
draft
is
concerned,
there's
only
two
settings
that
are
defined
and
the
default
should
be
when
you're
configuring,
an
email
account
that
you
do
want
that.
And
then,
if
you
say
you
don't
and
your
mail
user
agent
will
say.
N
Okay,
if
you
insist,
I,
will
not
enforce
these
minimum
standards
on
your
connection,
but
mua
should
encourage
users
to
request
the
confidentiality
separately
from
this
there's
a
separate,
a
second
set
of
criteria,
which
is
that
user
agents
are
if
the
server's
indicate
that
in
the
future
they're
going
to
support
certain
security
features
that
if
the
mail
user
agent
is
capable
of
implementing
those
in
requiring
it
that
the
mail
user
agent
upgrades
expectations',
so
the
server
can
say
I
will
always
support
TLS
1.1
and
from
then
on
the
middle
user
agencies.
Okay,
TLS
is
always
available.
N
N
Both
of
those
criteria
have
to
be
met,
so
you
have
to
make
both
the
users,
minimum
expectation
and
the
security
attributes
that
you
have
seen
from
the
server
before
separately.
From
this,
this
document
has
made
a
decision
to
prefer
TLS
on
a
known
port
which
we're
calling
implicit
TLS
instead
of
using
start
TLS.
Oh,
this
is
just
based
on
experience
with
starchy
Ellis
over
the
years,
and
this
is
ok.
We
tried
it
we're.
N
Basically,
it
seems
like
moving
to
none.
Ports
is
actually
the
better
solution
and
then
also
has
provisions
for
some
protocol
fixes
some
minor
protocol
fixes
for
some
of
these
protocols
and
in
band
reporting
of
these
security
directives
and
whether
they
were
met.
Ok
next
slide
the
major
changes
in
version
6
are
we
change
the
names
of
the
conf
of
the
confidentiality.
P
N
As
levels,
so,
the
previous
version
had
no
confidence
or
no
confidentiality
at
high
confidentiality,
and
that
seems
limiting,
because
what
happens
when
you
need
a
value
higher
than
high,
which
I
think
we
will
need
so
I.
I
change
this
a
0
in
one
so
that
that
you
don't
have
to
think
about
what
was
the
name
of
the
next
highest
value
or
how
high
can
you
go,
or
things
like
that?
N
The
second
change
in
major
change
in
06
is,
but
you
know
five.
The
TLS
sir,
could
have
a
value
of
P
kicks
or
could
have
a
value
of
Dane.
There
was
really
no
way
to
say
how
to
specify
that
the
server
is
going
to
commit
to
supporting
both
in
the
future
so
of
the
various
ways
to
kind
of
remedy
that
this
seemed.
N
Like
the
one
that
was
Lisa
treu
civ,
which
is
to
define
a
new
keyword
which
is
P
kicks
plus
dating
we
can
discuss
if
he
will
want
to
discuss
what
the
alternatives
were,
why
I
thought
they
were
worse?
We
can
do
that,
but
this
seemed
like
the
simplest
change
and
also
this
can
be
used
both
in
the
security
assertion
that
the
server
is
making.
So
it
can
say
I'm
using
the
kick
send
day,
I'm
supporting
both
of
these
in
the
future.
The
client
can
also
use
this
for
reporting.
N
N
N
E
N
At
a
given
session
that
can
have
a
confidentiality
assurance
level
which
is
higher
than
the
minimum.
So
that's.
Why
there's
a
distinction
there
make
it
clear
that
those
two
criteria,
the
minimum
confidentiality
assurance
level
and
the
security
directives-
must
both
be
satisfied
in
order
to
continue
with
the
connection,
make
it
clear
that
clients
may
use
protocols
that
if
you
have
several
protocols
associated
with
a
mail
account
and
some
of
them
meet
this
minimum
confidentiality
assurance
level
and
sub,
the
client
can
still
use
the
ones
that
do
so.
N
For
instance,
the
client
could
read
mail
if
that
connection
met
that
confidentiality
assurance
level,
but
it
might
not
be
able
to
send
mail
at
the
moment,
because
that's
that
connection
subject
to
an
attack,
it's
kind
of
a
minor
point
but
I
wanted
to
make
it
clear.
Tls
version,
1.1
or
greater
is
required
to
meet
the
minimum
confidentiality
assurance
level
of
one
and
either
p.
Kicks
ordained
suffices
to
meet
that
confidentiality
assurance
level.
N
The
previous
draft
is
kind
of
ambiguous
about
that
and
then
also
there's
some
clarifications
about
interaction
with
antivirus
and
it
just
and
mechanisms
most
of
these
I
think
are
minor,
but
trying
to
be
completely
Thanks
like
there's
a
question
about
I.
Something
I
need
to
look
at
is
how
TLS
served
a
value
of
P
kicks,
plus
Dane
might
affect
other
protocols
using
this
I
haven't
looked
at
that
yet
is
there
a
need
for
confidentiality
assurance
levels
greater
than
one
in
this
document?
I'm
thinking
not,
but
this
future
work.
N
I
believe
it
was
previously
agreed
to
separate
out
of
the
iata
portions
I.
Didn't
I
didn't
get
that
memo
before
I
was
editing
this
document,
but-
and
I
actually
think
it's
a
bad
idea-
it
will
slow
down
progress,
but
we
could
we
could
go
back
there
if
we
need
to
and
then
also
I'd
like
to
add
some
language
about
exactly
what
it
means.
If
you
get
a
connection
that
doesn't
meet
these
criteria,
then
let's
specify
it
a
little
more
detail.
N
L
Hi
Jenn
Penton
again
I
see
there
being
two
different
specifications
here.
One
specification
is
the
confidentiality
insurance
levels.
It
really
doesn't
define
a
protocol.
It
really
defines
a
set
of
practices
and
I
guess
I
would
see
that
as
being
some
sort
of
a
bcp
sort
of
thing
that
you
know
sort
of
defines
how
anyways
ought
to
ought
to
behave
and
not
not
to
be
configured
and
how
to
how
they
ought
to
represent
that
to
users.
L
Seeing
the
utility
of
what
seems
like
a
great
deal
of
complexity
there
when
the
Nu
amt
ache
or
the
the
MUA
is
always
talking
with
the
server
through
a
direct
connection,
and
you
know
either
side
there's
a
protocol
negotiation
that
goes
on
and
perhaps
if
you
have
the
confidentiality
assurance
levels
implemented,
then
that
will
be
sufficient
in
order
to
make
sure
that
the
connection
between
the
MUA
and
the
MTA
or
submission
agent
or
whatever,
is
sufficiently
secured.
Okay,.
N
First
of
all,
I
disagree
on
your
first
point.
It
is
a
protocol
because
this
it
documents
that
implement
this
specification
are
required
as
a
matter
of
protocol
to
abandon
a
connection
that
does
not
meet
the
user
specifications
that
is
protocol
and
it's
appropriate
for
standards
track.
The
second
point,
I
think,
is
that
I
get
I.
Also.
I
would
say
that,
if
you,
if
you
separated
these
into
two
specifications,
then
it's
complicated
because
both
of
them
effective
user
interface
and
both
of
them
affect
the
negotiation
of
the
connection
and
things
like
that.
N
So
I
think
it's
cleaner.
If
these
are
both
part
of
the
same
specification,
the
latter
point,
though,
I,
think
overall
broader
picture.
We
are
trying
to
increase
the
level
of
privacy
that
email
users
experience
now
we
have
because
of
the
complexity
of
email
and
that
some
of
it
you
know
it's
hot
to
hop
in
this
kind
of
thing
like
we
need
a
different
solution
in
the
MTA
relay
case,
then
we
need
for
the
interactions
between
mail,
user
agents
and
the
servers
they
talk
to
those
are
different
cases.
N
One
has
an
explicit
relationship,
that's
already
defined
the
other.
That's
not
so
on
and
so
forth.
So
that's
we
started
out
at
least
I
started
out
with
micros
document,
putting
everything
in
the
same
document
that
really
was
a
mess,
because
the
relay
case
was
so
different,
but
we
factored
it
I
mean
I
narrowed
the
scope
of
the
document.
N
I
was
working
on
and
then
merged
with
chris
to
her
this
this
document,
because
the
interactions
between
the
MUA
and
the
servers
clearly
was
something
that
needed
to
be
worked
on,
but
this
is
part
of
a
bigger
picture,
which
is
we
really
need
for
all
these
things
to
be
encrypted,
and
this
is
a
legacy
protocol
or
our
legacy
protocols
that
didn't
that
you
know
existed
long
before
TLS
existed
and
we're
trying
to
rectify
that.
So
this
is,
you
know,
kind
of
a
paddle
patchwork
effort
to
raise
the
bar
overall
for
email.
N
J
K
I
almost
forgot
my
point
during
the
previous
question
anyway.
So
I
think
this
specification
assumes
that
Dane
is
well
defined
for
mail
user
agent
to
smtp
or
IMAP,
but
I'm
not
sure
that
that's
the
case.
I
mean
we
have
a
general
purpose
day
in
protocol
in
66
98,
and
then
we
have
an
MTA
specific
definition
in
76-72
that
nails
down
some
of
the
loose
ends.
K
You
know
which
certificate
usages
are
applicable,
which
wild-card
patterns
are
support
and
so
on
and
so
forth
and
I
haven't
seen
any
real
specification
of
gain
between
em
mua
and
any
of
its
various
server
flavors.
Nor
do
I
know
if
there's
really
any
appetite
to
do
the
work
in
you
know
and
mail
user
agents
to
add
support.
K
So,
while
I'd
love
to
see
that
happen,
I
think
there
needs
to
be
some
interest
in
doing
Dane
for
mua's
before
we
wonder
about
whether
to
define
pickax
plus
stain
for
muh,
because
this
dane
thing
doesn't
have
any
meaning.
Yet
I
think
for
the
MUA
to
imap
or
submission
interaction
am
I
on
the
right
track.
There
I.
N
Think
you
raise
an
interesting
point
and
it's
something
I
want
to
look
at,
but
but
I
certainly
agree
that
if,
if
there's
no,
if
it's
not
well
defined,
how
you
verify
a
cert
of
a
server
that
in
any
way
talks
to
using
gain,
then
we
either
have
to
find
a
simple
way
to
define
it.
Or
we
have
to
factor
that
out
of
this
document,
because
I
don't
want
to
I,
don't
want
to
wait
six
months
or
a
year
to
define
all
that
stuff.
N
A
A
questionnaire
you
have
you
on
a
related
note,
have
you
if
you
have
discussions
going
on
with
the
implementers
I
mean
major
mmua
implementers
would
actually
implement
this
I
personally,
have
not
Kris
might
have.
Oh,
ok,
but
I.
Think
that,
being
in
the
interesting
sort
of
I,
think
it'd
be
used
for
the
information
to
get
that
at
least
I'm.
P
From
Gondwana,
my
question
is:
from
a
user
perspective,
what
does
this
setting
actually
mean?
There's
the
my
email
doesn't
work
in
my
email
works
option.
They
will
choose
the
my
email
works
option
without
carrying
what's
happening
underneath
for
ninety-nine
point
something
percent
of
users
in
which
case
why,
while
they're
having
a
switch
at
all,
if
it's
going
to
work
almost
all
the
time,
why
not
leave
it
turned
on
and
not
give
them
the
option
of
switching
it
off?
It
seems
to
be
a
switch
that
either
doesn't
do
anything
or
does
the
wrong
thing.
I
think.
N
K
P
Every
day,
so
what
we
do
it
fast
mail
for
this
is
exactly
what
you
said,
which
is
requiring
that
you
use
the
implicit
TLS
port
and
we
don't
even
listen
on
the
start,
TLS
port,
in
which
case
that
problem
is
solved,
but
it's
also
an
mua
that
has
is
using
this
standard
will
also
be
an
mua
that
requires
TLS
by
default
and
doesn't
need
anything
else.
It's
just.
You
must
use
TLS
before
I
send
the
password
over
the
wire
and
the
problems
already
solved.
Well,.
N
P
N
P
N
Think
the
real
problem
is
that
what
you'd
like
is
let's
say
that
I,
you
know
because
I've
had
this
happen,
a-anyway
that's
been
configured
for
years.
To
talk
to
say,
mail
accounts
and
the
mail
service
provider
has
upgraded
and
now
supports,
kill
us
consistently
and
I
shouldn't
have
to
go
back
as
a
user.
I
have
to
know,
and
users
in
the
wild
have
to
know
that
they
have
to
go
change
their
configurations
in
order
to
raise
a
little
expectation,
new.
P
N
The
dip
between
a
service
provider-
you
know
turning
on
TLS
for
some
connections
and
there
and
they're
making
an
explicit
commitment
to
do
that.
So
the
question
I
had
this
discussion
early
wrong
when
we
were
trying
to
do
the
graph
and
said
well
just
because
someone
enable
TLS
does
not
mean
they're
going
to
commit
to
supporting
it
that
they're
going
to
commit
to
putting
dollar
certificates
out
there
so
on
and
so
forth.
And
so
that's
why
we
made
that
part
explicit
protocol.
P
N
P
N
Thank
you,
pardon.
The
purpose
of
the
standard
is
to
specify
minimum
requirements
for
implementations.
So
and
again
it
is
a
matter
of
protocol,
because
if
something
claims
to
meet
this
specification
and
then
doesn't
close
the
connection
when
those
standards
aren't
met,
it's
failing
to
meet
the
protocol.
So
that's,
why
is
the
work
force
and
this
track
is
actually
something
that
can
be
tested
in
implementations
and
so
on
and
so
forth?.
C
E
Already
so
Neil
Jenkins
there's
already
there
serve
mechanism
for
looking
up
what
the
browser
supports.
We
already
have
the
so
what
the
configuration
is
for
particular
mail
service,
there's
already
a
set
purport
defined
as
we've
seen
we're
going
to
use
for
complicity
LS.
So
again,
if
anyways
want
support
they,
they
can
just
look
that
up.
We
can
say
just
met,
you
know,
if
you're
a
service
you
should
implement
this.
They
look
it
up
if
they
see
now
that
there's
one
with
TLS
there,
they
use
TLS
and
don't
offer
to
not
use
TLS.
E
N
I
think
that
if
this
actually
ends
up
being
a
huge
amount
of
extra
complexity
that
you
know,
we
should
look
at
it
the
more
it
wasn't
intended
to
be
that,
at
least
when
we
started
drafting
this
document,
that
mail
user
agents
that,
for
instance,
already
expect
TLS
and
don't
ever
do
anything
else,
are
I.
Think
trivially,
compiling
complying
I
have
to
go
back
and
look
again
to
make
sure
and.
N
But
again,
the
overall
goal
and
well
also,
I
want
to
address
your
point
about
the
service
discovery
mechanisms.
My
understanding
is
that
they
they're
not
that
widely
used
and
also
that
they
are
subject
to
attack
unless
you
use
the
intersect
assigned
by
the
units
that
can
use
the
intersect
to
verify
them
and
all
that,
so
the
mechanisms
we
have
here
are
using
TLS
to
ensure
that
those
things
are
not
attacked.
N
Okay,
so
I
think
what
we're
trying
to
do
here
is
make
this
overall
upgrade
email
to
always
using
TLS
incrementally
right
without
breaking
existing
things
that
people
are
doing
but
get
to
the
point
where
email,
at
least
every
hop
of
email
is
encrypted,
and
that's
really
the
overall
goal,
or
this
this
seemed
to
be
at
a
minimum
set
of
things
needed
to
get
to
that
goal.
I.
E
Guess
the
main
thing
is
a
lot
of
providers
and
a
lot
of
the
major
providers
only
offer
a
TLS
connections
like
I
think
gmail
does
past
not
as
we
haven't
offered
a
non
TLS
version
pages
and
just
don't
open
the
port,
and
that
seems
the
services
that
want
to
ensure
the
privacy
and
security
that
seems
some
its
influence,
something
they
can
just
do
now.
So
it's
what's
the
advantage
over
that
I
guess
is
my
house
I.
N
N
P
N
P
P
N
P
N
It
only
works
if
the
user
agent
gets
upgraded.
That's
true
right!
If
you're,
never
upgrading
your
user
agent,
it
will
never
comply
with
the
spec,
it
will
never
implement
or
any
other
spect
that
we
might
write.
So
yes,
it's
some
point
down
the
road.
When
you
only
have
you
to
attend
two
percent
of
your
subscribers
still
connecting
and
clear
text,
then
turning
them
off
and
dealing
with
that
tenth
of
a
percent
makes
sense,
I'm,
not
sure
it
makes
sense.
You
know
when
half
of
your
subscribers
are
doing
that
so.
E
P
E
Quite
a
new
standard
at
all
and
also
as
compatible
all
anyways,
because
we
actually
have
the
log
in
log.
So
we
know
who
is
connecting
to
us
and
we
know
what
security
they're
connecting
to
us
over,
and
so
we
would
start
with,
say:
1%
move
up
to
two
percent
and
of
the
ones
using
the
Institute
connections.
Email
them
say
you
need
to
upgrade
and
after
time
cut
them
off
at
the
server.
So
it
sure
they
would
still
connect
on
that
port,
but
we
would
reject
the
log
into
forcing
them
to
upgrade
that
way.
E
You
can
do
partial
users
over
time
until
you've
moved
everyone,
and
then
you
shut
the
whole
port
off
and
the
whole
thing's
gone
that
lets
you
do
this
incremental
upgrade
to
a
higher
security
lets
you
control
how
fast
and
who
the
customer
support
side
of
that
and
doesn't
require
any
new
standards.
We've
done
this
several
times.
We
have
bourse.
Do
because
there's
always
new
security,
stuff
who's.
N
All
right
I
mean
I'll,
go
and
take
a
look
at
that.
I
wanna
I
want
to
see
if
we
really
can
affect
all
this
because
there
maybe
we
should
write
a
draft
about
that.
If
we
can,
we
can
solve
this
problem
without
adding
protocol.
Maybe
that's
the
right
thing
to
do
and
then
we
could
publish
a
document
about
that.
E
Yeah
the
great
thing
about
that,
as
you
know,
it's
a
process,
not
a
new
standard.
It's
that
you
can
do
it
without
requiring
any
new
spool
from
the
mua's
every
mua
that
supports
TOS.
You
can
do
this
with,
because
it's
just
you
managing
this
on
the
server
and
yes,
it
does
mean
the
users
themselves
have
to
update
the
settings,
but
you
control
how
many,
how
fast
and
cut
them
off
incrementally
and
that
incremental
stuffs
really
important
I,
don't
know
if
there
was
anything
this
spec
about
that
and
it
looked
like
it
was.
E
Everyone
well
would
be
hard
to
make
it
incremental.
There's
always
support
issues
with
any
kind
of
change
like
this,
and
so
at
once
you're
at
a
sufficient
size.
You
need
to
be
else.
Do
it
in
stages,
so
yeah
I
think
that
as
a
process
seems
to
get
most
of
what
this
is
trying
to
achieve
without
acquiring
new
standards,
yeah.
N
I,
don't
want
to
go
over
the
document
cuz
I
mean
this
document
is
trying
to
achieve
number
of
different
things
and
I
want
to
go
over
and
say
what
is
it
that
we
can't
get
by
what
you're
proposing
the
other
thing,
I
want
to
say
is
like
how
again
stepping
back
the
broader
problem
is.
How
do
we
get
all
email
encrypted
email,
and
this
is
not
Indian-
that's
a
separate
problem,
which
is
also
still
needs
to.
N
G
H
D
L
Sometimes,
when
you're
sending
a
message
like
if
I
may
be
talking
with
my
financial
advisor
or
maybe
if
I'm
often
often
some
other
country,
where
I
don't
know
what
their,
what
their
policies
are
there,
it's
not
entirely
clear
whether
that
message
is
going
to
be
in
the
clear
on
the
on
the
internet
or
not
so
start
TLS
is
I.
Think
everybody
knows
it's
opportunistic
and
but
not
only
is
the
question
whether
to
negotiate,
TLS,
opportunistic
but
also
certificate.
L
Verification
is
typically
ignored
that
if,
if
the
the
certificate
of
the
smtp
server
doesn't
doesn't
verify,
we
just
kind
of
log
that
and
keep
going.
This
is
often
what
you
want,
but
it's
not
always
what
you
want.
Some
centers
want
to
prioritize
security
over
delivery
and
that's
what
this
is
about
next
slide.
P
L
In
the
in
the
message
app,
this
is
a
different
approach,
complementary
to
the
STS
sorts
of
things
where
the
recept
ian
domain
advertises
the
policy.
It's
very
fine-grained.
It's
it's
done
in
a
message
by
message
basis,
so
you
know
you
don't
have
the
potential
for
causing
large
scale
breakage
of
you.
If
you
implement
this,
this
provides
some
control
over
how
certificates
are
to
be
verified.
Whether
or
not
you
insist
that
the
the
recipient,
mta's
authenticate
with
with
valid
certificates
or
not,
and-
and
this
is
this
is
just
between
between
mta's.
L
Although
it
occurred
to
me
when
I
was
writing
the
slides.
You
know
the
recipient
got
a
mess.
The
the
last
hop
MTA
got
a
message
that
was
that
was
tagged
require
TLS.
Maybe
they
might
require
that
the
message
be
retrieved
securely
or
not
I'm.
Really,
given
that
much
thought,
it
seems
like
something
that
could.
P
L
L
P
L
The
the
requirements
follow
the
message
if
it
goes
through
multi
hops,
each
each
hop
keeps
track
of
their
party
LS
status
of
that
message
and
then
uses
that
when
it's
sending
the
message
on
board
and
there's
no
there's
no
policy
record
here.
So
there
isn't
a
discovery
problem.
It's
like
so
I
put
out
this
new
version
of
the
draft
mid-february
with
the
things
that
I
described,
particularly
the
required
TLS
equals
know.
P
L
There
are
now
two
prototype
some
implementations,
one
for
XM
and
one
for
EM
demon
that
have
been
done
and
we've
done
some
limited
interoperability
testing.
We
have
some
more
to
do
there,
but
we
have
at
least
the
ability
to
exchange,
require
TLS
protected
messages
with
those
and
then
here's
a
little
more
detail
on
on.
What's
new,
the
required
TLS
equals
know
which
I
already
described
and
some
additional
guidance
on
what
to
do
about.
L
L
The
only
time
you
could
do
require
TLS
was
after
you
had
negotiated,
start
TLS,
which
meant
that
maybe
we
should
only
advertise
it
on
the
hollow
that
occurs
after
start
after
TLS
had
been
negotiated.
So
that
was
that
was
one
of
the
questions
on
the
the
counter
argument
is
that
if
you
advertise
it
on
All
Hallows,
then
at
least
you
have
some
early
indication
whether
the
recipient
is
likely
to
be
able
to
accept
the
message.
Not
so
you
can
abort
before
actually
negotiating
TLS.
L
If
you
have
a
require
TLS
message,
and
but
this
may
be
kind
of
a
mood
issue
because
required
TLS
equals
no
doesn't
require
the
negotiation
of
TLS,
so
I
guess
we
need
to
advertise
it
earlier.
Are
the
there's
been
some
question
about
the
the
different
options?
I
I
used
the
names
Damon
chain?
It's
really
danan
p
kicks,
probably
are
probably
better
names
for
much
the
same
reasons
as
keith
was
talking
about
with
his
draft.
The
question
was:
are
there
other
situations
where
an
attacker
might
have
the
ability
to
manufacture
valid
certificates?
Some
of.
L
That
we
contemplate
our
perhaps
state-level
actors,
and
so
that's
a
possibility,
although
that's
you
know,
maybe
a
very
narrow
corner
case
right.
So
the
question
has
been:
is
it?
Are
we
over
engineering,
the
spec,
by
providing
this
level
of
granularity
this
level
of
detail
about
how
we
require
certificates
to
be
verified,
or
should
we
just
kind
of
say
verify
equals?
Yes,
oh
I.
M
L
L
Kind
of
a
similar
question
here
about
the
DNS
SEC
option:
there's
unusual
skepticism
about
DNS
SEC
deployment,
whether
or
not
having
requirement
that
the
MX
records
look
up
with
the
DNS
SEC
is
something
that
people
will
actually
deploy
and
then,
as
I
mentioned
earlier,
the
question
about
bounce
messages
or
whether
there's
some
way
that
we
can
send
some
sort
of
redacted
bounce
message
that
doesn't
reveal
sensitive
information
but
kind
of
will
allow
the
originating
MTA
to
be
able
to
figure
out
which
message
was
that
didn't
make.
It
may
be
alert
they
next.
L
L
You
know,
we've
got
interoperable
implementations,
so
I
think
that
represents
a
certain
level
of
maturity
of
the
specification.
Actually,
we
don't,
we
often
adopt
things
that
we
don't
have
implementations
of
yet
I'm.
Looking
for
other
people
like
to
try
this
out,
you
know
using
using
one
of
the
implementations,
we've
got
or
create
one
and
I'm
looking
for
questions.
Yes,
Victor
I,
guess
you're
on
okay.
K
Thanks
so
I
guess
I'm
one
of
the
strongest
people
behind
the
it's
over-engineered
viewpoint,
I'd
like
to
very
much
suggest
that
anything,
more
specific
than
must
TLS
or
must
Els
with
authentication
is,
is
unlikely
to
to
be
deployable.
So
please
no
specificity
as
to
whether
DNS
SEC
is
used
where
the
Dane
is
used,
where
the
pickax
is
used,
I
think
no
user
is
going
to
know
even
how
to
specify
it
or
what
it
means.
K
K
The
other
thing
I
wanted
to
mention
is
that,
as
the
instigator
of
require
tlf
equals,
no
I've
been
having
some
thoughts
about
how
that
should
really
work
on
the
side
and
I'm
wondering
whether
that
should
be
specified
via
esmtp
commands
with
require
TLS
or
maybe
this
particular
facility
is
better
handled
as
a
header
in
the
message,
rather
than
as
a
verb
in
the
protocol,
and
the
reason
for
that
might
be
that
require
TLS
equals
no
can
safely
travel
from
TAS
that
don't
understand
the
verb
right.
If
I
have
a
legacy.
K
Mta
that
doesn't
do
TLS
doesn't
know
that
it
won't
require
TLS,
it's
okay,
because
we
can
send
the
message
on
and
if
then,
the
following
hope
up.
Somebody's
are
very
clever
and
mike
otherwise
bounce.
The
message,
christy
less
policy
by
the
receiving
system
is,
is
hostile
to
delivery.
Here,
the
if
we
pass
it
through
a
header,
then
the
header
can
tunnel
to
each
and
every
node
that
might
be
able
to
be
a
little
bit
more
permissive
in
its
policy.
K
O
L
H
L
Let
me
just
respond
very
quickly
to
Victor
I
guess
with
respect
to
putting
it
in
in
a
header.
I
understand
the
motivation
to
that.
That's
that's
an
interesting
idea.
A
little
bit
it's
from
a
sort
of
protocol,
layering
standpoint,
it
seems,
seems
to
be
a
little
bit
a
little
bit
tricky
to
handle
trying
to
to
get
that
information
out
of
the
head
or
in
order
to
affect
it.
But
we've
done
things
like
that.
L
P
K
N
Ok,
Keith
more
broad
comments
on
this.
This
document,
or
at
least
this
facility
I,
believe
it's
useful
in
in
sort
of
marginal
cases,
but
it's
still
useful
it.
I
also
believe
it's
orthogonal
to
mts-
yes,
yes,
and
that
those
this
to
really
have
different
use
cases
as
a
user
I
find
it
unlikely
that
any
time
soon,
anyone
would
enable
this
for
all
outgoing
messages.
No
I,
don't
think
the
video.
N
L
N
Right,
so
they
could
do
that
because
they
know
that
the
newspaper
infrastructure
supports
it
and
they
know
hopefully
their
mail
I.
Their
MSP
supports
it,
so
they
can
for
that
particular
case.
They
can
make
that
and
so
they're
not
likely
to
have
this
balance.
Yes,
so
yeah,
okay,
so
it
sounds
like
we're
on
the
same
page.
That's
good!
So
I
like
the
idea
I'm
not
going
to
dig
into
the
details
yet
but
I
like
the
idea.
I
just
want
to
point
out.
This
is
a
different
problem,
so
yeah
yeah.
L
P
L
A
K
A
O
A
A
What
we
could
do,
we
could
sort
of
also
try
to
figure
out
whether
there
is
interest
in
the
in
the
working
group
for
adopting
implementing
something
like
this
right
yeah,
and
that
that
way,
you
know,
Jim
knows
whether
he
should
to
keep
sort
of
spinning
on
this
or
whether
it's
sort
of
work
this
time
to
do
so
I
and
then
we
can
decide
to
actually
adopt
at
a
later
time.
That
makes
sense
yes,.
A
A
Right
all
right,
so
there
there
seems
to
be
at
least
some
support
for
something
like
this
in
the
implementation,
and
you
already
have
two
implementations
in
that
case.
I'm
going
to
the
other
question
who
you
know-
and
this
is
for
the
general
working
group
to
use-
would
you
support
adopting
a
this
something
that
looks
like
this
as
a
work,
your
document
and
you
can-
and
you
can
hum
now.
H
A
There's
something
all
right,
we'll
take
this
as
an
indication
that
it
this
isn't
there.
There
is
some
interest
here
and
we'll
definitely
revisit
this
I
guess
you
should
take
this
as
an
indication
to
keep
sort
of
keep
spinning
Jim
and
with
that
I
think
we're
three
minutes
to
the
end
of
our
meeting.
If
somebody
has
open
issues
to
race
now
is
the
time
or
you
get
three
minutes
back.