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

[Daniel Margolis <[e-mail]>]

On Thu, Feb 23, 2017 at 11:00 PM, Viktor Dukhovni <[e-mail]>
wrote:

>
> > On Feb 23, 2017, at 3:35 PM, Daniel Margolis <[e-mail]>
> 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.
>

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.


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