> On Apr 22, 2017, at 1:35 PM, Daniel Margolis <[email protected]> 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.
>> 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".
> 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.
> 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.
> I think for publishing (i.e. the duration required in #2 above) the answer is
> "no"; obviously the "opt out" must be published in the same way (i.e. for the
> same duration) as any new policy. Similarly, because it must be published as
> (effectively) a new policy, senders must still cache it (or else hit the
> endpoint every time), so we're still talking about knock-on effect (a).*
>
> So I think the only argument for adding an explicit opt-out--which I think is
> otherwise extra complexity to be avoided--is to avoid (b), i.e., to avoid any
> cost of a "report-only" policy which has no reporting endpoint defined. And I
> suspect that cost is low, and does not justify even the minimal additional
> complexity of an "opt out".
How does the "report" policy ultimately go away? When can clients stop doing
policy lookups and the HTTPS service be decommissioned?
> But I may be missing something here, as usual. ;)
Yes, how does the refresh cycle stop...
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
