Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal.

[Viktor Dukhovni <[e-mail]>]

On Thu, Aug 10, 2017 at 03:56:29PM -0700, Jim Fenton wrote:

> I have been following the discussion, although not in as much detail as
> the two of you.
> 
> One small adjustment: When removing the policy, after removing the TXT
> record, you should probably wait the former record's TTL before removing
> the "none" policy because the TXT record could be cached elsewhere, even
> if it looks like it's gone when you ask for it.

Actually, not so much the DNS record's TTL, but the max_age of any
previous "!= none" policy.  All other policies need to expire will
all caches having "none" (or be cleared) before the "none" policy
is removed.

Under that condition, there's no need to wait to remove the TXT
record, removal of the record (being a change in the record) will
in this variant of the design trigger a refresh, and the sending
MTA will see a "none" policy and proceed to promptly flush it.

However, since refresh will often only happen in the background
when delivering mail to the domain in question, not all domains
will do the refresh in a timely manner, hence the "max_age" delay
to remove the policy.

> At a higher level: I agree that including a procedure policy removal is
> an essential part of the specification. But we also have to make sure
> that that procedure doesn't present an opportunity for an attacker to
> downgrade the policy associated with a recipient domain. I *think* this
> satisfies this requirement but I'm not completely sure.

Agreed.  My goal was to make sure that deliberate removal "by the
book" can be distinguished from an attack.  And thus that MTAs
would be able to noisily log "abnormal" policy refresh failure,
while not generating any warnings for the proper policy removal
procedure.

-- 
	Viktor.