Subject: [Uta] Updated drafts for MTA-STS & TLSRPT

From: "Brotman, Alexander" <[email-masked]>
Date: Wed, 15 Feb 2017 19:57:48 +0000

Folks,

We uploaded new revisions for MTA-STS and TLSRPT.  There are minor changes to each:

1) Remove the "_" from DNS records to be consistent with A/AAAA records used with the HTTPS retrieval, and make this a bit less confusing for deployments.  We did this for both MTA-STS and TLSRPT.
2) Clarify language around punycode 

Please give these a review and get back to us with any comments.  Thank you.

--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast
x5364

---

From: David Illsley <[email-masked]>
Date: Mon, 20 Feb 2017 19:16:20 +0000

It's been a while since I looked at the drafts, and they're looking good.

The area I'm getting stuck on is max_age. It's a point of
user-configurability, with little guidance on what's good, and the strong
possibility that people will make weak or otherwise bad choices.

As someone who expects MTA-STS to have a similar effect to HSTS -
effectively ratchet security, it seems like it's desirable for it to be as
long as possible.

In general, the fact the a complete failure causes a policy update makes
this simple and safe. There are a couple of reasons why I think it's not
quite that easy:
1. It's not desirable for a 'report' configuration to be used beyond the
point that a domain has switched to 'enforce', and a long-cached 'report'
policy could do this.
2. It prevents new MX records (eg new servers for increased capacity or
backups) not covered by the cached policy from being used until the
max_age, or until a failure to send with all the covered servers.

There is also a downside that if policies are cached for a long time,
misconfiguration of the policy server is less likely to be noticed quickly
as fewer domains will be sending reports indicating a failure.

Having pondered it a bit, my suggestion is:
1. A SHOULD that max_age is set to at least 6 months, other than during
roll-out
2. A SHOULD that well-behaved clients with a cached policy should re-check
DNS TXT policy weekly, and retrieve via HTTPS if the policy id has changed.

An alternative to (2) would be to add an optional refresh_after field with
similar semantics which would have a default value of 7 days which could be
overridden if, for some reason there are concerns that weekly is too often
(but I'm generally of the opinion that fewer options are better).

I hope that makes sense, and do let me know if I've missed something.
Cheers,
David

On Wed, Feb 15, 2017 at 7:57 PM, Brotman, Alexander <
[email-masked]> wrote:

> 1) Remove the "_" from DNS records to be consistent with A/AAAA records
> used with the HTTPS retrieval, and make this a bit less confusing for
> deployments.  We did this for both MTA-STS and TLSRPT.
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 23 Feb 2017 22:35:40 +0200

Thanks for the comments! Comments inline.

> max_age, or until a failure to send with all the covered servers.

Right. And in fact, per section 5.2, if a policy covers only some of the
current MX records, a sender with that policy may continue to use that
policy unless/until none of the allowed MX records are reachable or
unless/until none of the MX records are valid under the policy. There is no
*requirement* that a sender refresh the cached policy as long as it
continues to work.

So you've pointed out a somewhat subtle pitfall. If I deploy a policy with
"mx: ['*.google.com']" and I later deploy additional MXs with higher
priority on mail.google.*net *(and, because I'm smart, I remember to update
my deployed policy), senders may nonetheless only send mail to the old
*.com* MXs, resulting in an unexpected traffic imbalance.

A few observations about this case:

1. I don't know that this is a serious issue; it depends heavily on how
specific the "mx" pattern is versus turnover in MX hosts. As far as I
recall we haven't changed our MX hosts as long as I've worked here...

2. This could be fixed if we said that senders MUST seek a new policy
whenever some MXs are filtered out by policy application (5.2 step 2).

3. This is optionally fixed by senders refreshing cached policies at an
arbitrary time, which they may (but need not) do. Since they can cheaply
discover the presence of new policies (and may in fact lookup the magical
TXT record prior to doing a cache-policy-check anyway, depending on
implementation), this isn't really far-fetched--but we don't require them
to do so.

> as fewer domains will be sending reports indicating a failure.

That's also a good point, and it is unaddressed by my hypothetical MUST
above (#2).

> DNS TXT policy weekly, and retrieve via HTTPS if the policy id has changed.

I think the phrasing you give here suggests that if I send mail to your
domain less than once a week, I should run a cron job to refresh the
cache--and I hate cron jobs.

So to be slightly pedantic, would it work just as well to say senders
SHOULD check for an updated policy *if* *using* a policy which is older
than one week? (My phrasing may be unclear, but I mean, of course, that
they need only check for an updated policy if they are otherwise sending
mail to that domain anyway.)

Of course, we could still simply suggest/require senders *always* check for
a new policy--it's one more DNS lookup to the recursive resolver
per-send--but I bet in some implementations there are good reasons not to
do this.

> (but I'm generally of the opinion that fewer options are better).

Agreed, I think extra options here are just extra complexity.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Feb 2017 16:00:15 -0500

> On Feb 23, 2017, at 3:35 PM, Daniel Margolis <[email-masked]> wrote:
> 
>> 2. It prevents new MX records (eg new servers for increased capacity or backups) not covered by the cached policy from being used until the max_age, or until a failure to send with all the covered servers.

This should be a non-problem.  The DNS record exists precisely to signal
a requirement for "early" policy refresh.  So when the domain's policy
changes, the DNS record policy "id" SHOULD change to alert remote caches
that the cached data is likely stale.

This applies whether or not the change is to the list of acceptable "mx"
hosts, or to some other property.

> So you've pointed out a somewhat subtle pitfall. If I deploy a policy
> with "mx: ['*.google.com']" and I later deploy additional MXs with
> higher priority on mail.google.net (and, because I'm smart, I
> remember to update my deployed policy), senders may nonetheless
> only send mail to the old .com MXs, resulting in an unexpected
> traffic imbalance.

Only if you're negligent, and fail to modify the DNS record.
Negligence can cause many other operational issues, there are
no designs immune to operator negligence.

> 2. This could be fixed if we said that senders MUST seek a
> new policy whenever some MXs are filtered out by policy
> application (5.2 step 2).

That's both unnecessary, and problematic.  The issue is that
this condition is "sticky", until the policy matches the MX
RRset, the sender is in a constant "refetch" condition.  It
is best to avoid this trigger.  The DNS record triggers a
single update, and then its "id" is cached with the same
or any new policy.

> 3. This is optionally fixed by senders refreshing cached
> policies at an arbitrary time, which they may (but need not)
> do.

In addition to the text record trigger, senders should
attempt to opportunistically (not triggered by DNS
changes) refresh the policy at or after the midpoint
between the last retry attempt and the expiration (but
at least an ~1 hour after that attempt).

Thus when a policy is published for 90 days, and then the
policy server goes off-line, the retries would be (approx):

	<= 45 days left
	<= 22 days
	<= 11 days
	<= 6 days
	<= 3 days
	<= 36 hours
	<= 18 hours
	<= 9 hours
	<= 4 hours
	<= 2 hours
	<= 1 hour

More retry attempts just short of expiration are likely pointless.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 23 Feb 2017 23:04:53 +0200

> hosts, or to some other property.

Yes, but my point was that we don't (to my recollection) actually require
senders to check for new policies on every mail send--they can legitimately
keep using an old, cached policy as long as it works.

As you say below, there are many optional strategies for senders to refresh
policies in a reasonable way, so I am not of the opinion this is a fatal
flaw. On whether it would be better to say senders SHOULD take one of these
policies, though, I am open to feedback.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Feb 2017 16:14:03 -0500

>> 1. A SHOULD that max_age is set to at least 6 months, other than during roll-out
>> 2. A SHOULD that well-behaved clients with a cached policy should re-check DNS TXT policy weekly, and retrieve via HTTPS if the policy id has changed.
> 
> I think the phrasing you give here suggests that if I send
> mail to your domain less than once a week, I should run a
> cron job to refresh the cache--and I hate cron jobs. 

That's extremely unlikely to be implemented in Postfix, for example.
To avoid a "roach motel" policy cache, refresh will be driven only
by actual mail flow.

The DNS record needs to be specified as the primary trigger for "early"
refresh, wil an optional refresh when >50% of the time from last refresh
to expiration has elapsed and sufficient (say 1 hour or more) time remains
that the policy isn't about to be refreshed due to actual expiration.  A
frequency cutoff avoids firing refresh triggers minutes or seconds apart
close to expiration.

> SHOULD check for an updated policy if using a policy which is older
> than one week? (My phrasing may be unclear, but I mean, of course,
> that they need only check for an updated policy if they are otherwise
> sending mail to that domain anyway.)

See proposed scheme.  It has no artificial scale (1 week), and is instead
based on the policy lifetime.  Sending systems should probably cap the
policy lifetime on their end to something sensible (shorter for sites
that send lots of mail, and are unlikely to not contact a given peer
for a long time, longer for sites that don't send much mail).  So
if a receiving system advertises a 100-year policy, something more
sensible will be stored in the sending side.

> Of course, we could still simply suggest/require senders *always*
> check for a new policy--it's one more DNS lookup to the recursive
> resolver per-send--but I bet in some implementations there are
> good reasons not to do this.

If/when Postfix implements STS, the DNS id will be checked for each
new SMTP connection.  Changes in the DNS id will trigger (background)
policy refresh.  Non-changes in the DNS id will continue to use the
cached policy until it is 50% closer to expiration since the last
refresh (with a sensible cutoff).

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Feb 2017 16:21:39 -0500

> On Feb 23, 2017, at 4:04 PM, Daniel Margolis <[email-masked]> wrote:
> 

Poorly crafted implementations will err in many interesting ways, but with
luck their users will clamour for fixes or switch to less broken systems.

The DNS lookup is cheap and should happen frequently, and doing so on each
SMTP connection should be recommended in the draft.

> policies in a reasonable way, so I am not of the opinion this is a fatal flaw.
> On whether it would be better to say senders SHOULD take one of these policies,
> though, I am open to feedback.

I think recommending well thought-out approaches to these issues is useful:

   1.  It makes implementors think about the issues.
   2.  It gives them usable solutions that they can adopt or improve on.

Nothing this proposed RFC can say will force compliance, the SMTP server
is a passive actor in this space, and has no idea whether the client is
using STS at all, let alone correctly.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Fri, 24 Feb 2017 16:44:39 +0100

Yes, I think we agree here. But presently the RFC doesn't really recommend
frequent updating of the policy, AFAIR, though of course doing so is indeed
cheap and a good idea. So we should recommend it!

On Thu, Feb 23, 2017 at 10:21 PM, Viktor Dukhovni <[email-masked]>
wrote:

> flaw.

---

From: David Illsley <[email-masked]>
Date: Fri, 24 Feb 2017 20:33:32 +0000

I think I agree with where you've got to, but I do want to clarify that I
think it's important that a shorter refresh period doesn't shorten the
policy expiry - we want a 6 month policy to be cached and relied on for 6
months, even if, for most of that 6 months an attacker is blocking a more
frequent DNS policy check.

---

From: David Illsley <[email-masked]>
Date: Fri, 24 Feb 2017 21:04:13 +0000

On: "1) Remove the "_" from DNS records to be consistent with A/AAAA
records used with the HTTPS retrieval, and make this a bit less confusing
for deployments.  We did this for both MTA-STS and TLSRPT."

Having just tried to implement this, I bumped into a problem that I can't
use a CNAME to an ELB for the https bit and set the TXT record in the same
zone because it has the same DNS name and CNAME is special.

Have I missed something, or does this mean it's not possible to use CNAMEs
for hosting the policy document? If so, I think that's going to be a pretty
painful blocker for a lot of people.

Cheers,
David

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 24 Feb 2017 16:43:23 -0500

> On Feb 24, 2017, at 3:33 PM, David Illsley <[email-masked]> wrote:
> 
> I think I agree with where you've got to, but I do want to clarify
> that I think it's important that a shorter refresh period doesn't
> shorten the policy expiry - we want a 6 month policy to be cached
> and relied on for 6 months, even if, for most of that 6 months an
> attacker is blocking a more frequent DNS policy check.

That's a given, modulo local policy on the sending side that might
set a lower ceiling on the length of time for which policies are
allowed be cached.  Remote systems should not be able to force
cache storage indefinitely.  The effective cache lifetime will be
the lower of the remotely requested lifetime and the local policy
ceiling.

Refresh failure with periodic probing does not invalidate already
cached unexpired data.

If you feel this needs to be said explicitly, that's OK.  It seemed
pretty obvious to me.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 27 Feb 2017 11:18:24 +0100

> painful blocker for a lot of people.

Oh, damn. I'd forgotten you can't have a CNAME where another record exists,
but yeah, you can't. And I don't think that's desirable--we should support
CNAMEs here, obviously.

So let's undo that change. *sigh*

---

From: Alberto Bertogli <[email-masked]>
Date: Tue, 28 Feb 2017 21:13:23 +0000

On Wed, Feb 15, 2017 at 07:57:48PM +0000, Brotman, Alexander wrote:
> 1) Remove the "_" from DNS records to be consistent with A/AAAA
>    records used with the HTTPS retrieval, and make this a bit less
>    confusing for deployments.  We did this for both MTA-STS and
>    TLSRPT.

Thanks a lot for this!

Even though unfortunately it will be reverted/changed due to the CNAME
incompatibility mentioned in the thread, FWIW I still appreciate it.

> 2) Clarify language around punycode 

I don't see any punicode related changes in the diffs. Are you sure they
went in?

In both MTA-STS and TLSRPT all I can find are removals of the "_". I'm
looking at the links included in the emails:

https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-smtp-tlsrpt-03
https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-mta-sts-03

What I assume is the/a corresponding issue in github is still open:
https://github.com/mrisher/smtp-sts/issues/127. There was a commit
adding some wording [1] which was removed the same day [2], maybe that
caused some confusion?

Thanks!
		Alberto

[1]: https://github.com/mrisher/smtp-sts/commit/4b5bed7b9faf0b23c701367b9e147e559e16b373
[2]: https://github.com/mrisher/smtp-sts/commit/dc8abacbb728863739bd24ffd44d5ce595f1e6b4