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

[Viktor Dukhovni <[e-mail]>]

On Wed, Aug 09, 2017 at 11:14:16AM -0700, Daniel Margolis wrote:

> > No, with "none" the policy refresh can stop (and cache flushed) as
> > soon as NXDOMAIN/NODATA is seen for the TXT lookup.  The same is
> > not true for "report", to avoid downgrade attacks.
> >
> 
> That's not true; once a policy expires, it can be flushed from the cache
> (as it can no longer safely be used).

You're missing the point, a robust STS implementation will rarely
encounter an expired policy because it will periodically refresh
policies (for domains to which email is still being sent) *before*
they are due to expire.

When an unexpired policy is being refreshed, there should not be
mysterious refresh failures.  So if the policy is not yet deleted,
its lifetime will be again extended by the published "max_age".

What signal *securely* indicates actual deletion of an unexpired
policy?  (Not the DNS TXT record, which just expedites refresh).
 
> > Because the TXT record presence/absense is *insecure* (no DNSSEC
> > or else we'd be doing DANE!).  Therefore the TXT record must ONLY
> > be used:
> >
> >     1.  To signal initial policy presence when none is cached.
> >     2.  To signal expedited policy refresh when the id changes.
> >     3.  [New] To signal policy removal when the policy is "none"
> >         and the TXT record "disappears".
> >     4.  [New] Conversely to signal policy removal when the policy
> >         transitions to "none" and was cached in the absence of a
> >         TXT record (still absent).
> 
> Can you point to what language in the current draft suggests that the
> behavior with respect to policy refreshing differs if you have a cached
> policy versus if you do not? I am still not understanding what difference
> you see here.

The draft under-specifies the requirements for getting refresh
right.  Let's forget the draft and think logically, then fix
the draft.

When a policy is cached, it should be easily downgraded to no
policy.  Therefore a signal forged DNS response MUST NOT flush
the cache.  STS is subject to downgrade at first contact, but
is supposed to be resilient there-after, so long as mail flow
to the domain happens often enough.

Therefore, already cached policies are refreshed periodically (for
domains that receive some mail) regardless of the TXT record, and
the TXT record is only there to *expedite* refresh and signal
cold-start policy presence.

> > Mere removal of the TXT record is *not* sufficient to stop policy
> > refresh.  Recall that policy refresh will typically happen
> > before the policy is expired (more robust continuity) and must
> > not at that time be subject to DNS downgrade.
> 
> I believe this is your mistake. While I agree that one should try to
> refresh a policy prior to expiration, "refresh a policy" means checking the
> TXT record.

Sorry that means STS is trivial to downgrade to cold-start.
If that's the spec, I'm not implementing it.

> Your first sentence ("mere removal of the TXT record...") does not follow
> from your second sentence.
> 
> There's zero security advantage in ignoring the TXT record and going
> straight to HTTPS, since HTTPS also relies upon the (insecure) DNS
> resolution.

No it does not.  That's the whole point of HTTPS.

> As a result, it makes no real sense to refresh the policy if
> the TXT does not say to do it.

I'm afraid you're missing the consequent attack, and that's why
we've failed to reach closure on this issue.

> A sender who implements this will appear to
> be compliant with the draft--there's no real harm from doing this, aside
> from maybe excessive HTTPS requests--but there's no great reason to do this
> unless you think attackers can only attack the TXT record and not the
> CNAME/A for the policy host.

Forged CNAME/A do not downgrade the policy.  They just cause a
(noisy in the mail logs) failure to do the policy refresh, which
will be retried, and hence the attack must stay on path for a good
fraction of the policy lifetime (some time back I proposed refreshing
the policy at 0.5 max_age, 0.75 max_age, ... but no less than the
larger of 0.5 max_age and say 1 hour; search the list archive).

STS policy refresh must not be suppressed by forged DNS replies.
Only first contact is inevitably subject to DNS downgrade.

-- 
	Viktor.