►
From YouTube: IETF96-UTA-20160719-1620
Description
UTA meeting session at IETF96
2016/07/19 1620
B
C
B
B
A
D
A
A
A
D
F
G
A
A
D
D
I
J
A
A
A
B
A
C
F
A
G
G
F
F
G
G
C
A
B
M
D
M
M
O
F
M
F
Okay,
ok
now
you
can
hear
me
so
today
our
gender
is
again
dedicated
to
email
with
TLS
and
and
basically
we
have
three
presenters
here
and
the
last
one
is
going
to
be
removed.
Hopefully,
and
we
start
in
the
gold,
according
to
our
gender,
we
start
with
the
first
one.
The
two
drafts
are
going
to
be
presented
by
the
same
person
insane
insane
my
deck
of
slides.
So.
D
M
D
M
O
You
when
I
flip
the
ethical,
ok,
so
I'm
den
Margolis
I'm
talking
about
two
drafts,
which
probably
most
of
you
have
already
seen
there.
Hopefully
you
have
already
seen
one
is
reporting
of
TLS
delivery.
Failure
is
for
us
into
P,
and
the
other
is
to
be
strict,
Transport,
Security
and
I'm
just
going
to
sort
of
mash
them
together,
so
there's
11
slide
deck
and
I
kind
of
covered
in
one
piece.
Mostly,
these
are
sort
of
small
updates.
O
Since
the
last
update
we
gave
it
ITF,
95
I,
think
no
big
changes
that
will
surprise
people
and
we'll
sort
of
talk
about
where
we
plan
to
go
where
our
deployment
efforts
are
and
sort
of,
hopefully
get
some
useful
feedback
from
you
guys.
So
next
slide,
please
so
sort
of
really
short
60-second
the
overview
of
SDS
TS
for
people
who
aren't
familiar
with
it.
We
have
a
txt
record
on
the
mail
delivery
domain,
which
says
I
support
SDS.
O
We
have
a
https
endpoint
with
the
policy
describing
when
you
expect
TLS
connections
to
this
domain
and
what
senders
should
sort
of
look
for
in
the
MX
and
this
kind
of
thing,
and
essentially
this
looks
like
a
chesty
s,
so
we
use
web
geek
a
validation,
so
certain
violations
based
on
a
trusted
certificate
authority.
We
enforce
this
by
sort
of
caching
the
policy
for
a
long
time
and
every
time
we
talk
to
this
domain
from
here
on,
we
sort
of
expect
the
policy
to
match
until
it
expires
updated.
O
And
finally,
we
have
this
reporter
enforce
mode.
So
we
consider
these
soft
deployments
and
report
failures,
but
not
actually
bounce
mail
until
we're
sort
of
comfortable
that
things
work
next
slide,
please.
So
between
the
last
draft
and
the
current
one,
we
made
I
think
three
significant
changes.
The
first
is
that
we
split
out
reporting.
O
We
thought
that
that
was
sort
of
generally
useful
and
the
people
who
didn't
implement
STS
might
still
benefit
from
reporting
either
because
they
want
to
know
about
TLS
failures
with
start
TLS
or
because
they
want
to
know
about
Dane
failures
or
just
sort
of
a
general
useful
thing.
That's
now
its
own
txt
record,
which
just
describes
where
to
send
failures
and
as
Jen
there
can
be
a
male
to
link
or
not
John,
there
can
be
hplink
instead,
so
you
can
report
out
of
band.
O
You
know
upload
a
report
sort
of
like
HP
KP,
supports
and
say
essentially
what
what
MX
is
you
talk
to?
What
failures
you
saw
and
sort
of
provide
general
stats?
There
I
think
that's
largely
I,
controversial
and
I'm
actually
not
going
to
spend
that
much
more
time
on
TLS
rpt,
because
I
think
it's
extremely
simple
and
sort
of
general
useful.
Second
change.
We
essentially
simplify
the
tax
records
to
the
point
of
the
text
record
and
our
first
proposal
was
it
how
to
copy
the
proposal,
but
because
we're
not
assuming
the
MS
sec.
O
It's
it's
really
just
a
contestar,
a
copy
of
the
policy
which
serves
just
to
indicate
which
version
of
policy
you
should
be
looking
at
whether
you
should
look
at
the
https
endpoint
and
so
we're
using
DMS
is
sort
of
a
signaling
layer,
and
so
we've
simplified
this
to
make
it
clear
that
you
actually
can't
rely
on
the
DMS
record.
It's
just
a
copy
of
sort
of
an
ID
that
uniquely
identifies
the
current
version
of
the
policy.
You
want
to
get
the
policy
you
go
to
the
HPS
endpoint,
so
this
was
discussed
also
on
mailing
list.
O
I,
don't
think
it's
usually
controversial
the
the
third
point
is
we
had
sort
of
previously
had
this
I
think
somewhat
hacked
up
effort
to
sort
of
coexist
with
DNS
SEC,
for
sort
of
validating
to
the
DNS
records
and
Dane
for
authenticating,
MX's
and
I
think
it
caused
a
lot
of
problems
both
in
terms
of
extra
complexity
and
in
terms
of
sort
of
the
lack
of
clarity
on
what
to
do.
If,
like
that,
the
recipient
domain
has
a
dane
policy
which
doesn't
validate,
and,
yes,
yes,
policy
said,
rely
on
Dane
and
do
report
only
mode.
O
So
this
is
sort
of
an
odd
scenario
where,
if
you
look
at
dane
only
you
would
fail
the
message.
But
if
you
look
at
sts
you
might
be
less
clear,
and
so
we
basically
just
wholesale,
eliminate
DFS
sec
from
the
proposal.
I
think
now
it's
sort
of
more
clearly
an
alternative
and
I
think
they
can
coexist.
I
think
there's
no
real
downside
to
implementing
both,
but
you
know
then
they're
now
separate
and
I
think
it
just
makes
things
a
lot
simpler.
So
those
are
the
three
significant
changes
next
slide.
O
Please
and
we
closed
a
bunch
of
other
issues
between
drops
to
zero
and
Jeff
01,
I
think
largely
syntactic.
So,
as
we've
been
going
along
actually
implementing
this
on
our
sides,
we've
discovered
cases
where
things
around
their
specified
or
like
the
ABM
f
is
incorrect
because
a
be
enough
is
hard
or
you
know
things
like
this
and
and
we've
just
sort
of
made
a
bunch
of
like,
as
you
can
sort
of
see
here
it
actually
on
the
next
slide
as
well.
L
O
L
O
And
the
screen
shots
were
just
sort
of
like
screen
shots
at
the
github
issues
list
and
I.
Think
you
know,
people
who
visit
this
URL
can
sort
of
see
that
the
recent
progress,
but
so
that's
that's
like,
though,
really
I
think
I
spent
five
minutes
right.
That's
like
the
five
minute
summary
of
sort
of
what
we
did
between
the
last
update
at
ittf,
95
I
think
nothing
hugely
surprising,
except
for
those
sort
of
three
fairly
significant
changes.
O
So
this
was
kind
of
one
discussion
we
had
whether
we
should
host
the
HTTPS
end
point
at
you
know:
policy
mt,
st
s:
dot
example
that
org
versus
just
like
a
one-level
sub
domain.
I
think
we
had
some
questions
on
the
mailing
list
about
how
smart
hosting
should
work
to
to
me
as
victors
nodding.
So
to
me,
smart
hosting,
is
sort
of
you
know.
O
O
Similarly,
some
of
the
assets
should
we
allow
hvs,
redirect
side
policy
location.
So
again
we
sort
of
didn't
specify
this
I
think
it's
quite
reasonable.
Obviously
you
shouldn't
be
able
to
redirect
from
https
to
http,
because
that
has
no
value
but
sort
of
a
reasonable
question,
and
then
we
had
sort
of
a
question
about
where
the
dot
well-known
policy
should
be
and
sort
of
how
it
makes
the
plugin
easier.
O
So
those
are
I
think
the
four
things
I
can
think
of
recently,
which
are
sort
of
like
likely
to
change
your
sort
of
noticeably
going
to
change
and
and
then
in
terms
of
current
efforts.
So
the
Google
policy
is
live
and
we
expect
send
time,
validation
and
logging,
and
you
know
eventually,
enforcement.
If
it
works
sometime.
This
quarter,
Microsoft
I
think
the
policy
is
like
half
live
or
soon
to
be
live
and
they're
working
on
sametime
validation,
comcast
the
policy
is
live.
O
The
hds
endpoint
has
the
wrong
certificate
right
now,
but
that
will
be
fixed
by
shortly
and
report.
Only
mode
is
planned.
Yahoo
report
only
mode
is
planned.
One
in
one
I
think
report
only
Motors
plant
for
a
number
of
domains
this
summer.
So
we
sort
of
know
of
a
handful
of
big
deployments.
Most
of
them
are
people
who
contributed
to
the
draft
which
I
think
report
only
mode
will
happen
in
the
near
future.
O
I
F
P
You
actually
go
one
more
forward,
it's
very
Reba
I
wasn't
easily.
This
is
Barry
liebe
the
I
see
this
is
a
no.
The
next
yeah
I
see
this
as
nice
list.
I
see
it
there's
nothing.
There's
no
implementation
section
in
the
document.
I
suggest
that
you
put
that
in
so
that
when
the
document
is
reviewed,
everyone
can
see
the
running
code.
That's
out
there.
You.
P
O
In
terms
of
centime
validation,
I
mean
we
at
Google.
We
anticipate
we'll,
have
sent
I'm
validation
working
this
quarter,
I
think
a
number
of
other
sort
of
co-authors
and
partners
expect
to
have
maybe
offline
report.
Only
implementations
like
this
summer,
this
quarter
I
think
one
reasonable
question
would
be
when
and
whether
we'll
have
an
implementation
in
an
open
source.
Mta
like
post
fix
that
people
can
use.
I
I
would
actually
like
to
contribute
open
source
code.
That
does
validation,
but
I,
don't
notify
the
time
to
do
that.
So.
G
So
I'm
postfix,
probably
nothing
before
Victor
company
inputs.
It's
probably
nothing
before
the
spec
is
finalized
and
perhaps
even
though
the
outline
you
know
that
very
high
level,
the
spec
is
not
too
bad.
The
details
need
a
great
deal
of
work.
So
if
we
think
that
oh
one
is
near
a
final
draft
I
think
we'll
see,
probably
in
05
before
it's
really
done.
G
O
O
G
New
policy
there
is
not
yet
in
DNS
caches
an
ID
that
matches
it
and
when
people
retrieve
the
policy,
the
IDS
won't
match.
They'll
keep
recruiting
the
policy
over
and
over
again,
but
their
cash
will
say
that
it's
the
wrong
ID
and
we
can
talk
about
that
offline.
So
the
ID
field
needs
revision.
The
entire
future
section
is
either
impractical
or
irrelevant
needs
to
be
deleted,
but
we're
gonna
get
discussed
that
on
the
list.
G
The
state
machine
is
under
specified
needs
to
be
expanded
to
take
into
account
multiple
amex
hosts,
there's
some
editorial
issues
about
just
how
the
motivation
in
terms
of
comparisons
of
dana
and
this,
that
not
so
much
by
advocating
for
Dave
I
think
needs
clarification.
Lee.
Some
of
the
descriptions
are
low,
yeah.
O
O
Ones
where
you
can
really
tell
us,
you
know,
as
I've
said
earlier,
I
think
these
are
issues
where
you're
likely
to
discover
maybe
different
implementation
issues,
and
we
are
certainly
I
think
I.
Think
the
normal
usage
of
postfix
looks
very
different
than
the
normal
deployment
of
an
mga
at
Google
and
I
I.
Don't
necessarily
have
as
much
insight
as
you
do
in
to
sort
of
the
former,
so
you
know
I'd
rather
not
do
four
more
revisions
before
I
get
all
the
postfix
feedback.
I'd
actually
rather
get
the
feedback
sooner.
O
If
it's
possible,
that
doesn't
mean
you
have
to
implement
it
and
tell
us
what
we're
being
stupid
about.
You
know
now,
but,
like
I,
do
think
the
sooner
that
we
have
that
working
open
source
implementation
in
sort
of
smaller
deployments,
the
sooner
we
would
get
that
feedback,
and
we
wouldn't
have
to
do
the
four
more
revisions
right.
O
So
we
don't
make
any
real
statements.
I
mean,
I
think,
aside
from
sort
of
a
mention
as
victor
saying,
that
there
are
other
systems
out
there.
We
don't
really
make
any
say
for
sure
how
it
should
relate
the
the
the
coexistence
that
I
would
imagine
is
you
know
onsen
time
you
can
certainly
validate
both.
I
think
we
hit
the
discussion
in
the
manual
about
you
know.
Potentially,
if
you
validate
dane,
you
don't
bother
as
a
sender
to
validate
SDS,
which
I
think
is
quite
reasonable
sure
I
don't.
F
O
O
O
G
O
O
Yeah,
that
was
exactly
my
point
earlier
with
why
we
got
rid
of
that.
The
Dane
references
right
I
think
that
the
way
we
had
it
before
was
this
sort
of
bad
state
Victor's
talking
about
where
we
said.
If
sts
says
soft
fail
but
authenticate
the
thing
like.
What?
What
do
you
do?
You
should
have
circumventing
game,
so
we
don't
have
that
now,
I
think
now
it's
as
you
were
saying.
It's
essentially
a
sender
policy
questions
as
a
senator
of
what
I
would
do
if
I
were
validating
both
Dane
and
SDS
is
I
would
fail.
O
F
Right,
so
what
we're
trying
to
do
here?
What
I
heard
from
the
others
they're
trying
to
do
is
to
get
as
much
as
possible
feedback
from
the
implementers
in
in
order
to
polish,
basically,
the
text
and
the
protocol
and
the
system
m
and
as
you
so,
the
companies
are
implementing
it,
and
so
it
would
be
great
to
get
this
feedback.
You
know
as
soon
as
possible
and
instead.
L
I
L
O
Hexham
I've
heard
of
it
yeah
yeah
I,
mean
I,
think
you
know
marks
saying
the
same
thing.
We
would
much
rather
have
some
working
open
source
implementation
that
we
could
get
some
feedback
from
and
I
think
I
think.
The
thing
that's
really
obviously
missing
from
our
perspective
is
just
what
it
looks
like
to
be.
Deploying
post
fix
your
XM
for
a
small
domain
where
you
have
maybe
a
backup
MX
by
somebody
else,
and
you
know
these
guts
of
things.
I'd
really
like
to
invite
people
to
sort
of
do
that
and
give
us
feedback
earlier.
G
So,
post
six,
we
tend
to
not
implement
anything
that
can't
be
done.
One
hundred
percent
right
so
it'll
take
a
while
for
us
to
be
convinced
that
this
can
be
done.
One
hundred
percent
right
in
particular,
you
know
the
timeouts
for
HTTP-
are
under
specified
here,
what
our
recommendations
there
and
the
like,
so
lots
of
things.
If
we
pin
down,
we
have
to
be
convinced
that
it
scales
with
positional.
G
G
So
that
one
can
reasonably
understand
what
the
expectations
are
in
the
sending
and
receiving
side.
The
the
other
thing
is
that
my
experience
with
Exim
is
that
they
tend
to
stop
short
of
dotting
all
the
I's
and
crossing
all
the
t's.
So
they
have
a
day
and
implementation,
but
it's
been
incomplete
and
they
think
they're
done,
but
you
know
not
entirely,
even
though
I
donated
code
to
them,
they
haven't
finished
the
for
integration,
yet
so
exit.
G
O
P
This
is
Barry
liebe,
so
wait.
There
are
six
documents
defining
HTTP
and
how
it
works.
And
are
you
really
saying
that
you
want
this
document
to
give
that
kind
of
HTTP
detail?
I,
don't
think!
That's
appropriate
I
think
this
points
to
those
and
say
that's
how
you
do
HTTP
and
here's
how
you
do
this
with
HTTP,
but.
G
G
Maybe
it
leaves
the
issue
entirely
open,
but
if
I'm
to
have
a
scalable,
MTA
I
need
to
know,
what's
expected
of
me,
because
the
person
provisioning
the
HTTP
infrastructure
might
plan
it
for
a
certain
scale
and
might
expect
people
to
wait
a
certain
amount
before
they
get
serviced
and
they
ought
to
know
that
they
should
monitor
for
responses
within
the
certain
budget
that
they
are
sierra
commands.
Or
else
you
know,
email
will
start
breaking
and
MTA's.
You
know
with
limited
concurrency
Pacific's
price
not
overwhelm
the
machine.
It's
running
on
it.
O
P
This
is
Mary.
What
I
will
agree
with
Victor
on
is
that
if
you
find
that
the
normal
way
HTTP
is
used
isn't
sufficient
for
this,
then
it
probably
is
reasonable
to
say
for
this
environment
here
are
different
parameters
that
you
need
to
use,
but
I
think
before
you
go
sticking
that
in
the
document
we
need
to
have
some
idea
that
that's
really
necessary
for.
O
F
Okay,
great,
it
seems
like
we
had
very
discussion.
Fluid
seems
we
didn't
know
discussion
to
follow
on
the
list.
It
would
like
to
ask
actually
who,
in
the
audience,
how
to
judge
how
many
people
in
the
audience
actually
read
this
latest
draft
okay.
Actually,
it's
sword
yeah
at
least
sort
of
the
audience.
Great.
That's
great
aim.
F
L
Q
Of
different
deployment
considerations
that
will
be
different
in
different
environments,
so,
for
example,
in
a
case
where
you
have
a
long-lived
HTTP
connection
where
you're
going
to
use
the
keepall
I
parameter,
there's
a
timeout
associated
with
that,
where
you
can
tell
the
the
other
party
how
long
the
connection
should
be
available
for
you
can
always
keep
it
open
longer.
That
won't
be
the
case
in
all
of
these
connections.
Right
that
you,
you
have
a
persistent
connection
available,
I
think
specifying
it
for
all
mta's
in
all
deployments
would
be
startling.
Q
You
might
have
some
advice
that
says
hey!
Please.
Please
consider
this
in
making
the
engineering
trade-offs
of
how
your
how
long
you're
willing
to
wait.
If
you've
got
a
very
high
performance
MTA,
you
might
wait
a
shorter
amount
of
time
before
moving
moving
on
then,
if
you've
got
a
one
that
basically
got
a
persistent
connection
to
one
or
a
very
small
number
of
hosts.
Writing
that
is
deployment.
Considerations
with
the
engineering
trade-offs
for
different
conditions
makes
sense.
To
me,
standardizing
on
on
a
particular
set
would
be
surprising.
Behavior.
P
O
O
O
Yeah
I
mean
agree
with
that.
I
think
I
think
two
questions
about
this.
One
is
I
think
this
goes
a
bit
to
the
comment
of
you
know.
These
are
different.
Trade-Offs
are
different
deployments.
I
think
it'd
be
hard
to
to
say
sort
of
normatively.
What
what
trade-off
you
should
make
I
guess
the
other
question
I
have
is
is:
is
this
a
situation
where
the
policy
host
needs
to
be
understanding
that
trade-off
on
part
of
sort
of
most
senders
like
it?
O
Is
it
the
case
that
if
I
deploy
my
policy
on
a
relatively
slow
H
to
BSN
point,
it
will
be
a
big
problem
for
people
who
have
a
short
message?
You
know
can't
tolerate
a
long
message
to
and
if
that's
the
case
then
yet
maybe
we
want
to
say
take
this
into
consideration.
People
may
have
trouble
delivering
dinner
to
your
domain.
If
the
policy
fetch
takes
a
while.
Q
Ted
Hardy
gandi
I
absolutely
agree
that
taking
into
account
on
both
sides
of
it
is
perfectly
reasonable.
We
also
have
to
acknowledge
that
the
system
must
be
at
least
reasonably
robust
to
delay,
simply
because
they're
there
are
delays
built
into
the
layer
below
TCP
I
mean
the
layer
below
comma
DCP,
and
there
there's
always
the
possibility
that
after
you've
done
the
TCP
handshake,
you
get
something
like
a
routing
change
that
that
causes
this
to
take
longer
than
you
expect
right.
Q
So
the
reasonable
amount
of
robustness
to
variation
in
this
is
also
part
of
what
the
system
has
to
have
and
I
think
describing
what
what
the
variations
can
be
is
useful
in
making
making
people
aware
of
what
the
engineering
traders
are,
but
really
demanding
it
of
of
the
internet
system
is
not
going
to
work.
Well.
Sorry.
G
G
O
An
effort
to
sort
of
generalize
the
errors
and
that's
actually
one
of
the
points
here-
sweet
I,
think
originally
said.
Oh,
we
can
come
up
with
a
taxonomy
of
ways
in
which
TLS
connections
fail
and
then
have
a
nice
sort
of
schema
here
and
we
realized
you
sort
of
can't
do
that
and
you
can
sort
of
do
it
for
openssl
in
general
cases,
cuz
a
lot
of
people
to
use
it.
But
you
can't
really
do
this
in
the
general
case,
I
think
well.
O
G
Thanks
go
there;
it
needs
to
move
on.
The
other
is
to
maybe
finish
off
the
topic.
The
main
reason
I
wanted
to
think
about
time
outs
is
that
if
they're
long
recommended
to
be
by
default,
you
know
you
be
generous
to
the
HTTP
server
that
might
change
the
design
in
terms
of
whether
you
recommend
that
the
MTA
proceed
to
send-
and
you
know
fresh
policy
in
the
background-
and
you
know
later,
this
was
my
question.
Sure
messages
might
benefit
from
the
policy,
but
the
one
you're
currently
sending
just
excess
a
probe.
F
O
R
R
O
R
O
F
So
I
don't
see
any
any
people
at
the
mic,
and
so
I
will
try
to
kind
of
summarize
the
points
and
tell
me
if
it's
correct
so
the
first
one.
It
seems
to
me
that
there
is
a
lot
of
a
tuning
of
parameters
that
is,
is
going
to
be
I
mean
it
will
need
to
be
done,
and
probably
this
is.
This
is
going
to
be
based
even
on
my
implementation
experience
going
forward.
But
basically
that's
that's
one
area
in
and.
O
I
think,
regarding
that,
like
I'm
I
I
am
NOT
still
entirely
sure
how
to
proceed
in
the
sense
that
yeah
I
think
some
of
that
will
be
very
implementation,
dependent
and
some
of
that,
like
the
degree
of
specificity,
I,
think
we're
not
all
idle
I.
Don't
know
that
I
think
Victor
wants
to
be
more
specific
than
I
do,
for
example,
and
I'm
should've,
not
sure
quite
where
the
metal
gathers
their
rights.
I
think
some
of
that
is
so.
Okay.
F
So
that's
all
it's
kind
of
you
know.
Maybe
it's
two
issues.
One
is
the
tuning
of
parameters
and
the
other
one
is
the
specificity
of
state,
machine
and
stuff
and
actually
explain
how
it
all
works
and
then
so
this
to
kind
of
be
discussing
identified.
Do
you
see
any
additional
issues
that
you
would
like
to
get
that
you
are
stuck
with?
Basically
you
as
the
team
of
autumn's,
that
you
would
like
feedback
for
or
you
have
enough
homework
sort.
S
P
Dan
York
and
I
have
read
the
draft
and
looking
through
that
I
just
I
think
as
I
looked
at
this
before,
but
now
I'm
seeing
again
you're
still
relying
on
trust
and
first
use
right,
you're
still
yeah.
It
is
still
some
mechanism
that
the
attacker
could
disrupt
that
before
they
get
to
you,
okay,
so
you're
still
I
think
the
security
considerations
could
spell
that
out.
P
O
O
P
Are
you
sure
this
is
also
space
where
you
know
working
with
DNS
SEC
for
people
published?
You
know
the
aether
MX
records
or
sign
through
that
and
the
validations
occurring.
Then
you
know
that
you're
getting
that
and
then
those
two
it's
a
space
where
they
can
work
together,
because
at
that
point
you
know
you
have
the
correct
MX
records
or
the
correct
and
you
can
be
able
to
connect
to
the
correct
sites.
So,
okay,
yeah.
A
P
E
G
I
don't
know
if
this
is
the
time
to
really
delve
into
detail.
How
much
time
people
have.
Are
you
interested
in
some
exposition
of
the
search?
I
mean
I'm
curious.
You
can
even
later
and
go
ahead.
Go
ahead.
Okay,
I'm
transparency
relies
on
the
log
servers
being
able
to
distinguish
between
completely
made
up
gibberish
reports
and
reports.
That
actually
are
true
observations,
because
the
certificate
chains
are
signed
in
here.
The
only
party
that's
able
to
validate
the
signature
is
the
client
that
connects
the
server
it
don't
have
a
signed
piece
of
data.
G
We
have
assigned
transmission
channel
in
the
form
of
HTTPS.
So
if
I
observe
a
particular
policy,
there's
no
way
I
can
convey
to
the
log
that
I
observed
a
valid
policy.
The
log
cannot
be
convinced
by
me
reporting
it,
and
so
the
log
can
be
spammed
into
irrelevance.
The
attackers
can
fill
the
log
with
so
much
gibberish,
but
you
won't
be
able
to
tell
the
good
from
the
bad,
and
this
is
a
fatal
obstacle
to
getting
CT
working
in
this
space.
For
example,
I.
G
F
G
And
em
ta
policies
have
to
wait
for
them
to
issue
you
a
signature
for
your
policy
before
you
can
deploy
it.
So
the
serious
issues
there.
If
you
really
want
to
think
about
it
on
it's
unlikely
to
fly
as
for
pinning
in
many
a
deployment.
If
you
want
to
not
absolutely
pin
down
the
names
of
your
mix
hosts,
so
you
would
say
start
on
examiner.com,
then
the
attacker
merely
can
substitute
another
amex
host,
for
example,
that
I
I
meant
I
meant
keeping
but
ya
know
keeping
it
keep.
G
Inning
is
our
house
because
different
has
a
lot
of
different
keys.
So
if
I
pin
the
key
for
MX
1
and
mx2
example.com,
the
attacker
man
in
the
military
will
say
at
this
moment
the
MX
hosts
rmx
3
and
the
contents
a
great
correct,
MX
host-
and
you
know
the
policy
matches.
He'll
use
a
certificate
that
you
know
is
a
CA
and
everything
checks.
G
G
This
is
actually
practical,
it'll
break
as
often
as
it
works,
but
I'm
leery
pinning
because
budge,
but
in
many
cases
the
pinning
across
all
the
MTA's
isn't
viable,
because
people
get
different
sets
of
different
ideas,
they'll
be
back
up
in
mex
hosts
and
the
like,
and
so
pinning
works
rather
poorly.
We
shouldn't
expect
it
to
be
a
savior.
I
would.
O
S
S
So
I
for
the
protocol,
but
that's
you
know
no
big
changes
here,
so
we
can
move
forward.
So
here's
the
key
changes
in
the
new
draft
I've
changed
the
terminology
and
I've
also
changed
using
the
term
directives,
which
is
the
term
that
h,
st
s,
uses
for
yo
for
what
I
was
calling.
You
know,
security,
keys
and
latches,
and
so
so
I've
switched
to
directives
for
that
I've
changed
the
protocol
syntax
to
the
key,
with
optional
value,
syntax
that
h,
st
s,
uses
and
I've
I
remove
the
DS
DSN
header
as
yo.
S
If
we
want
that
it
belongs
in
the
MTA
relay
SDS
document,
so
we
should
have
a
discussion
of
if
we
want
to
just
drop
that
feature
all
together
or
or
just
take
that
text
and
stuff
it
in
the
in
the
correct
document.
Then
then,
and
then
a
bunch
of
eddie
editorial
work
more.
You
know
more
details
on
that
in
the
draft,
so
next
slide
so
yeah.
S
The
big
issue
that's
open
on
this-
is
alignment
of
the
MUA
and
MTA
SDS
specs,
so
I
think
I've
moved
forward
on
this
by
changing
yo
yo
by
changing
the
terminology.
But
you
know
I
just
want
to
you
know,
but
I
I
think
it's
important
to
align
these
because
email
technology
is
already
very
complicated,
so
we
want
to
avoid
adding
more
complexity,
the
necessary
to
email,
so
the
The
Closer.
These
are
to
being
this
yeah,
just
sharing
appropriate
technology.
You
know
they're,
not
they're,
very
different
use
cases
for
sts,
so
you
can't
there.
S
You
know
they
need
to
be
separates
facts.
They
are
separate
proposals,
but
there
there
is
appropriate
technology
to
share
so
next
slide.
So
roughly
what
I
would
start
on
the
starting
point
for
a
alignment
proposal
is
so
I
I've
started
turning
the
registry
that
was
in
deep
into
a
directive
registry
for
sts
in
general.
S
That
would
cover
mua,
MTA
and
h
st
s,
so
it
would
be
one
registry
for
all
of
them
kind
of
like
the
email
header
like
the
header
registry,
covers
HTTP
and
email
headers,
so
it
would
be
a
shared
registry
along
those
lines
where
the
items
in
the
registry
say
what
protocol
those
items
apply
to
question
question
I'm
unsure
about
is
yo.
Do
it
should
we
have
a
preferred
directive?
S
Syntax
now,
right
now
the
the
current
sts
draft,
I
believe
it's
using
json
for
the
directives
and
h
SDS
is
using
HDD
parameter
value,
syntax,
which
is
yo
key
key
option,
optional
value
with
semi
colon
delimiter
&,
and
so
I
went
mostly
to
copying
the
hcp
syntax,
but
it
turns
out
if
you
allow
double
quotes
around
the
value
that
screws
up.
You
know
that
then
it
doesn't
slot
into
into
the
MUA
protocol.
So
I
remove
that
from
the
syntax.
The
question
is:
is
syntax
alignment
matter,
or
do
we
just
want
to
say?
S
O
S
O
S
The
separate
registries,
then
each
document
has
to
define
its
own
registry
and
describe
the
registration
process
and
have
its
own
expert
reviewer
and,
as
you
know,
go
through
the
whole
ITF
review
process
or
I
ana
review
process
to
create
the
registry,
and
so
there's
there's
a
certain
amount
of
overhead
to
creating
a
iono
registry
and
I'm
trying
to
share
that
overhead
that
that
that's,
why
I'm
leaning
towards
a
common
registry?
But
you
know
I'm,
not
firmly
in
that
direction,
so
hey
Dave,
Crocker.
T
T
Long
as
there
is
an
overriding
sense
that
it
makes
sense
for
these
to
be
together
that
that,
in
over
the
long
haul,
there's
a
fair
amount
of
overlap
and
very
likely
sharing
of
entries.
Even
if
there's
only
one
right
now,
then
it
would
make
sense
to
have
only
one
having
them
be
separate,
creates
the
problem
that,
should
there
be
sharing
you've,
just
created
a
whole
lot
more
work
and
the
opportunity
for
becoming
the
divergent.
S
L
O
Sorry,
Dan
Margolis
again
what
what
are
some
examples
of
extensions
that
we
would
want
to
add
in
the
future,
so
I
think
for
deep.
It's
it's
more
obvious
to
me
because
you're,
you
know
you're
trying
to
provide
security
constructs
which
might
rely
on
other
other
primitives
in
the
future
for
sts
we
might
but
I.
Think
STS
almost
is
the
primitive,
and
so
the
sensibility
case
is
less
clear
to
me.
S
Well,
I
mean
HTS
had
the
same
situation
where
they
you
know
when
they
published
it.
They
didn't
think
there
was
any
extensibility
and
there's
already
a
what
there's
already
a
limited
use
extension
to
HST
s
out
in
the
wild
that
I.
So
you
know
my
my
thinking
is
yo
is
we've.
Are
we've
we've
already
seen
an
example
where
an
extensions
needed,
let's
just
yo,
I've,
already
written
most
the
registry
work.
All
I
need
to
do
is
split
this
out
into
a
separate
draft.
We
we
reference
it
we're
done
Mexican.
G
S
S
Let's
see
okay,
so
oh
I
had
one
more
bullet
on
the
previous
slide
on
the
the
other
area
where
we
need
to
talk
about
alignment
is
reporting
mechanisms
so
right
now
the
MUA
STS
has
an
in-band
reporting
mechanism
and
smtp
SES
has
that
out-of-band
reporting
mechanism
that
was
just
split
out
into
a
shared
spec.
So
I
I
I
think
it's
interesting
to
share
the
out-of-band
reporting
mechanism
between
both
proposals.
G
S
So
there
is
an
in-band
mechanism
in
the
MU
ases
draft
right
now,
uh-huh
god,
I
really
don't
want
to
edit
edit
a
third
draft,
but
is
that
the
right
thing
to
do
is
split
that
out
into
a
third
draft
that
we
both
reference
and
it
would
be
kind
of
and
I
think
it
would
actually
be
a
non-normative
reference,
which
would
be
the
nice
thing
about
it
right.
So
I
think
tomorrow.
O
Us
again
on
the
on
the
invent,
I
definitely
don't
see
a
downside
to
having
you
know
a
different
error
code
for,
like
I,
mean
for
server
to
server
smtp.
If
you
say
I
terminated
the
connection
because
of
a
TLS,
a
failure
I
think
it's
quite
reasonable
to
have
a
different,
quick
code
for
that
I
think.
Presumably
that's
a
different
draft,
both
in
band
and
other
bands
seem
to
me
to
be
useful
and
conceivably.
You
would
implement
both.
So
you
know.
S
F
S
S
Okay,
the
shared
sts
registry
I,
was
noting
most
the
directives
are
protocol
specific
because
these
three
use
cases
are
quite
different.
You
know
in
you
know,
the
semantics
are
just
so
different
between
the
use
case,
even
though
it
it
really
is
the
same
function,
we're
performing
same
core
function.
S
F
S
F
O
S
F
Q
S
So
why
don't
I
go
ahead
with
the
assumption
that
we're
not
sharing
syntax
since
we're
not
right
now
and
and
that's
less
change
yeah
and
then,
if
somebody
has
a
strong
feeling
that
syntax
should
be
shared,
we
can.
We
can
address
that
when
that
comes
up
on
the
other
thing
about
the
shared
registry
is
I'm,
proposing
it
the
expert
review
and
that
there
be
a
limited
use
flag
you
either
it's
either
common
user
limited
use
for
a
registry
entry.
S
So
that's
why
that
Flags
there.
So
that's!
That's
it
for
the
shared
registry.
I
think
the
areas
where
we're
drafts
are
not
aligning
mtas.
Yes,
sorry,
it's
just
https
now
drop
them,
pretend
the
DNS
SEC.
Wasn't
there
well
muass
uses
in
band
TLS,
although
that's
they're,
just
different
on
how
that
works,
the
MTA
relay
and
h
st
s
use
match
max
age
in
the
MUA
sts.
We
decided
not
to
use
that
on
and
then
other
directives
are
protocol
specific.
So
this
is
where
the
protocols
don't
lie.
E
K
File,
there's
an
interlude
is
Lexi
here
earlier,
so
am
Alexei.
Melnikov
is
one
of
the
art,
IDs
and
Alexei
knows
like
crap
loads,
more
about
email
than
I
do
so
we
thought
it
might
make
sense
to
swap
kind
of
the
responsible
ad
for
the
working
group
at
some
point
in
the
near
future.
I
guess
so.
We
chat
about
it
with
the
chairs.
It
doesn't
make
any
real
difference,
but
just
so
you
know
and
are
not
shocked
or
surprised
wedding,
but
Alexei
will
be
the
responsible
helper,
as
opposed
to
me
from
sometime
near
in
the
future.
K
M
M
H
H
Okay,
bear
with
me
just
a
sec.
Oh
is
busy
with
me
dekho,
and
I
need
to
figure
out
how
to
to
get
my
slide.
So
I
can
see
them
here
as
well.
So
it'll
take
a
second
there.
We
go
alright,
so
I
don't
have
a
whole
lot
to
report
on
require
TLS.
This
time
around
I
presented
it
I
think
fairly
extensively
down
in
Buenos,
Aires
and
I.
H
Hope
people
remember
that,
but
I
have
some
backup
slides
if,
if
people
would
like
me
to
represent
some
of
some
of
that,
it's
a
different
approach
to
applying
stronger
requirements
on
TLS
transport
for
smtp,
where
this
comes
from
the
sending
side,
rather
than
a
policy
that's
published
by
the
by
the
recipients
ID.
So,
rather
than
having
some
sort
of
a
policy
record,
that's
published.
This
is
basically
a
tag
that
goes
along
it's
on
a
very
fine-grained
basis.
It's
it's
a
message
by
message
and
the.
H
The
essentially
that
tag
follows
along
and
essentially
make
sure
that
both
require
TLS
and
TLS,
with
the
the
proper
characteristics
are
used
whenever
the
messages
is
forwarded
onward.
So
please
go
on
to
I
think
it's
slide
to
review
problem
statement
you're
in
ok,
so
the
the
problem
that
I'm
that
I'm
trying
to
solve
here
is
that
TLS
is
opportunistic.
Now,
that's
often
what
you
would
really
like
to
have
happen,
you
want
email
to
be
delivered.
H
That's
kind
of
the
postal
paradigm
on
deliver
the
mail
whenever
you
can,
but
what
that
means
in
practice
here
is
that
if
you
can't
negotiate
start
TLS,
you
basically
send
the
message
without
start
TLS.
If
you
can't
verify
the
the
server
certificate,
you
basically
note
the
fact
that
it
failed
in
you
and
you
send
that
and
send
the
message
anyway,
but
this
is
often
what
you
want,
but
it's
not
always
what
you
want.
There
are
times
when
you
want
to
send
a
sensitive
message.
H
There
are
times
in
particular
where
you
would
like
additional
protection
for
even
the
the
header
information,
the
envelope
information
that
are
not
protected
by
end-to-end
encryption
and,
for
example,
think
about
a
foreign
correspondent.
That's
sending
a
something
from
a
war
zone
or
something
like
that.
There
might
be
situations
where
they
they
want
to
make
sure
that
that
message
either
is
sent
securely
or
isn't
sent
at
all
so
go
on
to
the
next
slide
and
so
I
I
missed
the.
I
missed
the
cutoff
for
the
internet
graft.
H
I
do
have
a
heavy
revision
kind
of
in
the
works,
but
I
kind
of
felt
that
since
I
missed
the
cutoff,
it's
inappropriate
for
me
to
try
and
present
a
new
revision
here,
but
be
looking
for
one
I,
just
kind
of
wanted
to.
Let
everybody
know
that
I'm
still
still
working
on
this
I
do
I
have
been
advised
that
there
is
one
commercial
MTA
that
is
planning
to
do
an
implementation
of
this.
So
we'll
have
something
to
test
it
with.
H
G
I
remember
on
the
list.
There
was
some
discussion,
this
victim
colony,
I,
remember
in
the
list,
though,
some
discussion
as
to
whether
the
thing
should
be
very
specific
as
to
the
properties
of
require
TLS
and
mandate,
ciphers
and
all
kinds
of
things
or
in
order
to
be
usable,
be
much
looser
and
to
allow
these
things
to
be
under
specified
and
I.
Don't
know
that
we
reach
consensus
in
that
one.
The
other
thing
I
wanted
to
mention
is
that
they're
probably
should
be
a
converse
specification
in
which
you
say
no.
G
H
H
M
Let
me
actually
asked
who,
who
here
in
the
room,
has
read
the
required
to
last
at
least
the
last
draft
Oh
couple
of
people
fair
number
of
people,
so
it
doesn't
I,
don't
know
if
anybody
feels
they
want
an
introduction
to
the
topic.
There,
there's
there's
one
hand
for
introduction.
I,
don't
know
if
that
count.
Now.
K
M
N
You
want
zone
coming
from
the
world
of
sick
I'm,
very
interested
in
this,
because
we
failed
miserably
and
sip
with
something
called
cps
URI.
Where
are
you
a
requires,
a
tela
session,
almost
all
the
way
to
the
other
you
a
because
there's
no
proof
what
happens
between
the
different
proxy
service
and
we're
trying
to
fix
that
in
various
ways,
but
still
haven't
fixed
it.
So
maybe
this
is
a
similar
problem,
have
a
feeling
that
you're
trying
to
solve
the
same
problem
as
we
do
and
how
to
set
up
a
secure
session.
N
H
Okay,
well
thanks
all
I'm
not
familiar
with
that
sip
s
specification,
all
I'll
have
a
look
at
it.
You
know.
I
will
note
that
we
are
expecting
a
certain
amount
of
good
behavior
on
the
part
of
inter
MIDI
intermediaries,
but
on
the
other
hand,
we're
expecting
that
anyway,
if
they're
handling
our
email,
yeah.
N
M
I
guess
where
we're
into
I'm
going
to
meet
you
off
Jim
thanks.
Is
there
anybody
we're
in
the
open
mic
so
open
for
other
business?
You
might
get
an
hour
back
approximately
oh,
not
quite
an
hour,
but
not
seeing
anybody
rushing
to
the
mic
I!
Guess
we
close
the
meeting
early
and
maybe
see
you
in
Seoul
or
maybe
not
thank
you.