Re: [Uta] back to smtp-sts-04

[Daniel Margolis <[e-mail]>]

On Sun, Apr 23, 2017 at 4:50 AM, Viktor Dukhovni <[e-mail]>
wrote:

>
> >
> >> Speaking of the policy, what should be done if the HTTPS policy
> >> contains multiple JSON objects, no JSON objects, or broken JSON?
> >
> >    "If a valid TXT record is found but no policy can be fetched via
> >    HTTPS, and there is no valid (non-expired) previously-cached policy,
> >    senders MUST treat the recipient domain as one that has not
> >    implemented MTA-STS."
> >
> > If you can't parse it, it's not a valid policy, so you fall back to
> cached-non-expired or none.
> > Same as if there's an HTTP timeout, an HTTPS cert validation error, etc.
>
> Getting an authenticated invalid policy seems rather different from failure
> to retrieve the policy.  The latter is obviously a temporary condition and
> one can stick with what's cached.  On the other hand when an authentic
> policy
> fails to parse, it seems clear whatever we had in the cache is no longer
> the
> current policy.  So what is the right course of action is not so clear.
>

It's not clear, to be sure, but any other strategy is complex. If we can't
parse the new policy, do we assume a misconfiguration and fail open? It's a
corner case where the most predictable behavior, to me, would be to ignore
new policies which are unparseable. I think predictability here is a
virtue.

Of course, my intuition about expected behavior may be wrong. But if I'm
correct on what's "predictable", overriding that intuition with explicitly
specified behavior (like, "unparseable policies should be taken as a sign
that the recipient domain is confused and has opted out of STS, despite any
valid cached policy") seems not desirable to me, unless the risks are very
high.


> >> How does a domain get rid of its STS policy?  I thought we had discussed
> >> using "max_age = 0" for this, which after being in place long enough to
> >> assure that all previously cached policies have expired can be removed.
> >> Or might just "404" suffice
> >
> > Yes, I remember discussing this. But I am not sure such a mechanism is
> needed.
>
> I rather think it is needed.  When a domain changes hands, or no longer
> wishes
> to deal with the hassles of certificate expiration, it must be possible to
> revoke the policy.
>
> > 1. Domains can publish a "report" policy (with or without a TLSRPT
> record!)
> > with a low expiration
>
> What happens when that expires?  It is again found and refreshed unless
> there's
> a way to ultimate say "no policy".
>

Sure, but as I explained, given *any *hypothetical "opt-out" mechanism, it
is theoretically not possible to design one which you do not have to keep
publishing until $time_you_last_had_a_different_policy +
$that_policy's_max_age has passed.

(Since I'm referring to this time below, let's call it "old policy
expiration time.")

In other words, publishing a report-only policy with a low expiration is
just as good as publishing an "opt out" policy, in the sense that in the
former case you have to publish the report-only up until the old policy has
expired everywhere, and in the latter case it's identical.


> > 2. They have to keep this policy published until "last time the old
> policy was
> > published" + "old policy's max_age"
>
> Yes, but that's not actually policy removal.  Clients will likely still
> end up
> collecting stats for reports, even if they later prove undeliverable or
> there's
> no address to send them to.
>

As I discussed, the only consideration here seems to be one if, "Are the
costs of 'reporting' (i.e. stats collection, etc) sufficiently high to
warrant the need for an explicit opt-out mechanism?"

I don't personally think so, but I may be wrong here.


> > Let's consider in comparison an implementation with a special "opt out"
> mechanism
> > (however it works). Would it avoid the above two knock-on effects, or be
> easier
> > to publish?
>
> It seems to me that "age=0" is simpler and more clear than "report".
> Combined with
> ultimate removal of the DNS TXT record the policy is eventually flushed
> from caches.
>

Here and below in your email, it seems your main question is (to
paraphrase), "When will senders know to stop caching a policy, even if it
is a 'report only' policy?"

In fact there are two different things to consider here:

1. When can the recipient stop publishing the "opt out" policy?
2. When can the sender stop caching the policy?

The point I attempted to make in my previous email is that #1 is invariant,
regardless of mechanism: in all cases, the recipient must publish the "opt
out" signal until the max time at which the previous policy was published
*plus* that policy's max_age has passed. (I believe this is obvious.)

However, #2 is also mostly unchanged in most of these various designs:
assuming any "opt out" indicator that uses the usual TXT "id" string as an
indicator of presence, senders will want to cache the "id" seen in order to
see if the "opt out" policy has been supplanted by an "opt in", if only to
avoid repeated policy refreshes.

(Of course senders could merely cache the last version seen for that domain
and a null policy; they don't need to cache anything else for the sake of
supporting opt-outs. And in fact, we could achieve the same security
properties as exist now by purging the cache on opt-out and instead
embedding one new boolean indicator in the TXT record, indicating that the
new policy is an opt-out policy, to be fetched only by senders who have
cached a non-opt-out policy. I trust the functioning of this approach is
obvious, but regardless, it's needless complexity and I would rather not
explain it if it's not. :) )

So the long and short of it is that one *cannot* design a system in which
the recipient does not have to publish the "opt out" signal for this amount
of time; I'm fairly sure that's an invariant.

Contrarily, one *could* design a system in which senders do not have to
cache anything at all for domains that have opted out, but, at least as far
as I can see, only by modifying the TXT record format, which is not
desirable to me.

Two questions for you:

1. Is your main concern point 1 above (i.e. when can recipients stop
publishing) or point 2 (i.e. how can we save cache space of cached "opt
out" policies)?
2. If #2, can you propose with more detail how you suggest a different
mechanism to work? Does it involve the TXT modification I describe above?
Or is there a simpler way?


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