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

[Daniel Margolis <[e-mail]>]

Thanks for the comments! Comments inline.

On Mon, Feb 20, 2017 at 9:16 PM, David Illsley <[e-mail]>
wrote:

> 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.
>

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.

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.
>

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


>
> 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.
>

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.


> 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).
>

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


>
> 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 <
> [e-mail]> wrote:
>
>> 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
>>
>>
>> _______________________________________________
>> Uta mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/uta
>>
>
>
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>
>