Thanks Victor. Though there are few refinements possible to some of the
arguments, I do not have any followup comments for the moment.
-binu
From: Viktor Dukhovni <[email protected]>
To: [email protected]
Sent: Thursday, 11 August 2016 5:41 PM
Subject: Re: [Uta] review of mta-sts-01
On Fri, Aug 12, 2016 at 12:02:18AM +0000, Binu Ramakrishnan wrote:
> > Keep in mind that polling for fresh policy (synchronous or not)
> > will only happen as part of a mail delivery to the destination
> > domain. A quick DNS lookup as part of each delivery works just
> > fine. It is far from clear under what conditions an MTA delivering
> > a message would choose to contact the HTTPS policy endpoint.
>
> The first statement is not necessarily true. A DNS polling is required
> (as part of the delivery) only if the policy is not previously cached.
If STS is to scale, refreshing the entire cache each day over HTTPS
is not an attractive option. A more attractive design is to query
the DNS signal on every delivery, and either synchronoushly update
the policy or schedule an asynchronous update if the DNS id has
changed.
This leads to more timely detection of changes, and less needless
retrieval of unchanged policies.
> Once the policy is in cache, a separate process can actually keep the
> cache in sync.
The separate process would need to ignore cache entries that have
been recently accessed, otherwise the cache becomes a roach motel
for live, but disused policies. This is not an attractive option
for smaller scale systems like Postfix.
> One argument against relying on DNS TTL is that TTL can vary from minutes
> to days.
The STS specification should recommend short TTLS (an hour or less)
for the DNS TXT record.
> This can affect the refresh time. Lets say we have a policy with
> max-age sets to 24 hours.
Don't do that, unless you are happy with 24 hours of stale data.
> There are two arguments against directly hitting HTTP endpoint,
> (1) It is [much] more expensive for senders to make calls to HTTPS than a DNS
> (2) Hammering HTTPS endpoint. Let us discuss some points related to this:
>
> - The initial policy discovery is still based on DNS TXT, so the impact on
>sender is minimum.
For domains that have no policy, yes, early in the deployment
lifecycle of STS. Is STS designed to be a long-term mechanism,
that seeks very broad adoption, or a placeholder for the large
providers, while they figure out whether/when they can do DNSSEC?
Once many domains have policies, there'll be more HTTPS traffic.
> - Policy refresh: Policies are refreshed in the following two cases
> (1) max-age reached
Or not at all, if there is no traffic to the destination, in which
case the policy is aged out.
> (2) Validation failures.
Perhaps, or queue the mail and wait for the sender to change the
DNS id, if they don't do it, then mail is not delivered. Similar
issues happen with misconfigured A records, MX records, expired
certificates, ...
The problem with refresh on validation error, is that this becomes
a major bottle-neck, absent a rate limiting mechanisms. It makes
no sense to refresh on every delivery failure. This is too expensive
for the sender. A sender would need to limit the rate at which
policy is refreshed for each destination with some sort of hold-down
timer.
Failures will be dominated by negligent operators, who not only
misconfigure their systems to no longer match the live policy, but
will also not make timely updates.
> Depending on the implementation, it can be an async job - a cron that
> refreshes cached policies that are about to expire or already expired,
> at regular time intervals).
This creates a roach-motel problem, unless only recently accessed
policies are refreshed.
> In the case of validation failures, we
> need to force a policy fetch to make sure we are using the latest
> policy.
I think this is a waste of time. Failure will rarely be resolved
via a policy update. Order of magnitude or two more likely is a
belated replacement of an expired certificate, in which case one
just waits until the operator notices, a policy poll won't help.
> Relying on DNS alone is not safe because, policy would have
> changed, but not DNS record.
Nothing is fool-proof, there are always better fools.
> One argument against direct HTTPS is to avoid hammering HTTPS endpoint.
> I think it is not entirely true. If the policy is changed, the recipient
> must get a new policy. Whether we use DNS or not, ultimately we need to
> hit HTTPS.
At most at the rate at which mail is sent. If the HTTP servers
can handle the same request rate as the SMTP servers, all's well.
Periodic updates might have a poor temporal distribution.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
