Subject: [Uta] Smallest practical MTA-STS maximum policy age?

From: Ivan Ristic <[email-masked]>
Date: Tue, 19 May 2020 09:10:06 +0100

I've been hearing anecdotal evidence that email providers don't accept
small values for the maximum policy age in MTA-STS, for example anything
smaller than a day. I searched around and  I found a few articles saying
things to that effect, but nothing specific.

Does anyone here have experience with this sort of thing? What should we
(Hardenize) advise users to use as the smallest maximum policy age?

Thanks!

-- 
Ivan

---

From: "A. Schulze" <[email-masked]>
Date: Sat, 23 May 2020 21:07:06 +0200

Am 19.05.20 um 10:10 schrieb Ivan Ristic:
> I've been hearing anecdotal evidence that email providers don't accept small values for the maximum policy age in MTA-STS, for example anything smaller than a day. I searched around and  I found a few articles saying things to that effect, but nothing specific.
> 
> Does anyone here have experience with this sort of thing? What should we (Hardenize) advise users to use as the smallest maximum policy age?

Hello Ivan,

I asked a similar question last year: https://mailarchive.ietf.org/arch/msg/uta/bnUjy9jxM_Va-lDXVtbB32zIkYI/
Currently I use ~ 3 days as "max-age" and receive reports from google that don't let me think they have any problem with my setting.

Andreas

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 23 May 2020 15:27:36 -0400

On Sat, May 23, 2020 at 09:07:06PM +0200, A. Schulze wrote:

> I asked a similar question last year:
> https://mailarchive.ietf.org/arch/msg/uta/bnUjy9jxM_Va-lDXVtbB32zIkYI/
> Currently I use ~ 3 days as "max-age" and receive reports from google
> that don't let me think they have any problem with my setting.

Keep in mind that I expect implementations of MTA-STS to not refresh
refresh policy caches pre-expiration in the *absence of traffic to the
destination domain.  So if any domain hosts users who in aggregate
correspond with you less often than every 3 days, MTA-STS is completely
ineffective at protecting that traffic against MiTM downgrades.

Thus, my take is that MTA-STS policies with a max_age less than ~30 days
are potentially ineffective, and perhaps not worth the bother.

--
    Viktor.

---

From: Ivan Ristic <[email-masked]>
Date: Sun, 24 May 2020 12:33:24 +0100

> are potentially ineffective, and perhaps not worth the bother.

Sure, for production use.

The issue I am seeing is this: New users are experimenting with MTA-STS and
wish to use a small policy duration until they're confident in their
configuration. They use values in hours and don't get any reports.

Perhaps there's a case for specifying a minimum acceptable policy duration
in RFC errata or something?

--
>     Viktor.
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

-- 
Ivan

---

From: "John Levine" <[email-masked]>
Date: 24 May 2020 12:18:50 -0400

>in RFC errata or something?

I publish 86400 max_age and get lots of reports, mostly from Google
and Comcast. If they're testing they should be using testing mode,
and the age doesn't matter so much.

version: STSv1
mode: testing
mx: <whatever>
max_age: 86400

My setup is a little odd because my mail servers have a different name
for each domain pointed at them so I'm also testing whether clients
provide SNI to ask for the right certificate and my servers correctly
provide it. As far as I can tell they all do. It's not a perfect test
because all of the certs for each server have the same key and so the
same TLSA which (I think, Viktor?) would work even if it provided the
wrong certificate.

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 25 May 2020 09:39:29 +0200

Gmail's max_age is (as you can see) 1 day (
https://mta-sts.gmail.com/.well-known/mta-sts.txt). (Looking at other big
mail providers, Comcast is at 30d, Outlook at 7d, mail.de at 28d, and Yahoo
at 1d--so I feel like we could raise Gmail's!)

It would be reasonable for an MTA to ignore a policy that had a timeout of,
like, 1 second, since for many lower-volume senders policy refreshes might
thus constitute a meaningful increase in traffic. So don't do that. ;)

On Sun, May 24, 2020 at 6:19 PM John Levine <[email-masked]> wrote:

> In article <
> [email-masked]> you
> write:

-- 
How's my emailing? http://go/dan-email-slo