Subject: [Uta] review of mta-sts-01

From: Stephen Farrell <[email-masked]>
Date: Tue, 9 Aug 2016 15:49:46 +0100

Hiya,

The authors were hassling me (nicely:-) to do a review of
this and since I'm no longer the AD for the WG I figured
that'd be a good idea, as I'm very supportive of this, so
long as we (the WG/IETF), figure out how to do this without
that damaging deployment of DANE/TLSA. Overall, my take is
that there's a set of folks for whom this will be usable,
and who won't yet deploy DANE/TLSA, and so I think this
should improve the security of mail, so I'm keen, but as
I said don't want to see this damage DANE/TLSA deployment
either. Properly figuring out what RFC-text is right for
that might take a bit of discussion.

Anyway, my detailed review is below. The draft does need
a chunk of work, but I see no reason at all why that can't
be done pretty quickly and result in something good.

Cheers,
S.

PS: Apologies if I've forgotten some of the discussion on
this in Berlin (which I have), hopefully I'm not going to
contradict something I said there:-)

- Too many authors: the IETF has a strong preference for 5 or
fewer authors. (There's a long history for why that's the case,
but it's worth abiding by.) Probably the best thing here is to
pick one or two of the current set of folks and list those as
"editors" and have the rest of those listed as contributors.
See RFC7322, section 4.11 [1] for some instructions, and/or ask
the UTA WG chairs about how to do it.

   [1] https://tools.ietf.org/html/rfc7322#section-4.11

- Title: Suggest including "MTA-STS" in the title if you want
to use that acronym in the abstract. The title would then be
"SMTP MTA Strict Transport Security (MTA-STS)"

- 1.1: I think an example in the definition of "policy domain"
would help me at least, e.g. say that when sending mail to
"[email-masked]" then "example.com" is the policy domain.

- 2.1: I'm not sure if this is better included or not tbh.  I
do think we want to say "TLSA also does this and in some ways
better" but not sure if it's best done as pros and cons, which
may generate more controversy than is worthwhile. I'd say best
would be to start a thread on the WG list specifically about
what this ought say about DANE/TLSA and see what consensus
emerges. My bet is that after a bunch of discussion the WG
might come to consensus on a fairly short paragraph or two
that'd do the trick.

- section 3: I'd delete the forward reference to the "future
work" section, and indeed that entire section. RFCs don't
usually have that. (Also see below.)

- section 3: What exactly does "plain-text" mean? I guess you
mean ascii but you need to say. You also need to say something
that clearly works both for TXT RRs and for JSON.

- section 3: "rua" is I guess from the reporting draft, in
which case please say so and add the reference here.  (And that
becomes a normative reference because of this.) I'm not sure if
it'd be better to define "rua" here or not.

- section 3, "mx": the wildcards here would seem to open an
attack - if mail is supposed to go to foo.example.com and I
operate a web server on bar.example.com and see
"mx=*.example.com" then the operator of bar.example.com can
mount an attack (if they can inject an MX RR). Pretty easy to
get that wrong I'd say if the value of "mx=" is complex. I'd
say you need to warn explicitly about that in the security
considerations section.

- section 3, "policy_id": you need to say that this MUST be the
same as an "id=" value seen in a TXT RR I think.

- section 3, "id": I think you ought say that there's no
implied ordering (i.e. newer vs. older) in the value of the
"id" field, but then how can I tell which policy or policies to
apply at run time?

- section 3, "max_age": "integer seconds" could include
"-100000", (a negative number) I think you want only positive
values.

- section 3: "A lenient parser SHOULD accept a policy file
implementing a superset of this specification, in which case
unknown values SHALL be ignored." That implies that no
additional fields (for v=STSv1) can ever be restrictions, they
all need to be advisory. That is ok, but worth saying.  You
also repeat this statement twice in section 3, I'm not sure
why, but those should be merged, or maybe the 1st one is meant
to be about the TXT RR and not the policy file? In any case,
merging will be better.

- 3.1: I didn't check the ABNF. You should get a few folks to
do that. I bet a beer that domain-match will have some
issues:-)

- 3.1.1 and 3.1.2: you should add examples to both, or
elsewhere. The more the merrier probably, esp. if there are
corner cases. I see they're down at the end - I think they
may be better in-line as they're easier on the reader than
ABNF.

- 3.3: Don't you need to say that the value of the TXT RRs I
find at _mta_sts.example.com needs to include one (or more)
with "v=STSv1" and that's how I know there's some STS policy?
People will I guess include other stuff in TXT RRs at
_mta_sts.example.com even if you said they MUST NOT;-)

- 3.3: "Web PKI is the mechanism" - I think you need to say
that you're depending on the set of CAs/roots in the sending
MTA, being similar to those in a typical web browser or OS. I
don't think you can mandate that but saying something should
help the sending MTA implementer pick e.g. what libraries or
configs to use/support.

- 3.3: I forget why "policy.mta-sts" is what's prepended to the
policy domain. Personally, I dislike the two-level thing there
and don't see that it's useful. If you do keep it, then it'd be
good to justify it. But that's mostly a matter of taste I
think. OTOH, it might be a small barrier to deployments in some
places, not sure.

- 3.3: is the "current" in ".well-known/mta-sts/current"
hardcoded? If so, then "To consider the policy as valid, the
"policy_id" field in the policy MUST match the "id" field in
the DNS TXT record under "_mta_sts"." seems problematic as it
implies there's only one JSON object in the HTTPS response
there. Why not fetch ".well-known/mta-sts/<id>" where <id> is
what I got from the TXT RR? Or, if not that, then you need to
say how I get and parse >1 JSON object in the response (in
which case "current" seems a bit wrong).

- 3.4: You're missing a MUST I think - the MX name MUST also
match something in the domain_match from the JSON version of
the policy.

- 3.5, 1st para: I think the "MAY apply" there is bogus use of
2119 terms. s/MAY apply/applies/ would be fine I think. I also
think you should be clearer in saying that "report" vs.
"enforce" is up to the sending MTA as well being influenced by
the "mode" in the JSON thing.  (Which you neglect to say.)

- 3.5, "enforce" mode: what is the exception that causes you to
say "SHOULD" and not "MUST" here? I don't get that.

- 3.5, step 4: I'd replace the "*" bullets with letters or
numbers like "4.1" for ease of reference when those are
discussed (e.g. on the mailing list).

- 3.5, step 4, 1st bullet: is there any way I can make use of
this check to attempt a DoS against someone? Not sure, but it
smells a bit like there may be.

- 3.5, step 4: What happens if I check for a new policy, find
something, but it's crap? Or what if it is crap, but new crap
each time I retrieve it? Seems like there may be an infinite
loop there.

- section 4: I'd say delete this and just add references to the
reporting draft as and where needed.

- section 4: Where does it say what to do if the TLS session
establishment fails? Are you assuming that's handled within
"deliver mail"? I think you need to say and presumably if in
"enforce" mode, that the sending MTA does not fall back to
plain.

- section 5: The .well-known stuff needs an IANA considerations
section to register "mta-sts" as per RFC5875, see for example
[2] for what that'd look like.

   [2] https://tools.ietf.org/html/rfc7486#section-9.2

- section 6: "protects against" may be a bit overstated, I
think "provides some enhanced protection against" would be more
accurate.

- section 6, 2nd last para: I don't agree that compromised CAs,
nor fraudulently matching domain_match cases are "out of scope"
- you should instead note that those are residual threats that
are real.

- section 7: I think this should be deleted. The first two are
speculative, and the last two seem to break the earlier
statements about lenient parsing. It's fine that someone has to
define "v=STSv2" later to handle any such extensions, and
there's no need to predict now what that'd be.

- section 8: I'm not sure this is useful at that level of
detail.

- section 9.1: Is this the 1st time you say "HTTP GET"? If so,
that needs to be earlier and I didn't spot that it was
missing:-)

- section 10: I think this also disappears to somewhere else?

- order of text: If/when you've taken the above into account,
I'd suggest an editing pass that considers the order in which
things are presented in the draft. Right now, there's a lot of
forward referencing that I think could be avoided by moving
text about, and which'd lead to an easier read, that's more
easily understood.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 9 Aug 2016 15:08:41 -0400

My review below.  Executive summary, at least a -02 (and likely then an -03) is needed to correct many issues before this is ready for WGLC. 

> 1. Introduction
> 
> The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and hosts to establish secure SMTP sessions over TLS. In its current form, however, it fails to provide (a) message confidentiality — because opportunistic STARTTLS is subject to downgrade attacks — and (b) server authenticity — because the trust relationship from email domain to MTA server identity is not cryptographically validated.

Replace: allows SMTP clients and hosts to establish secure SMTP sessions over TLS.
With:    allows SMTP clients and servers to negotiate the use of a TLS channel security.

The rest of the paragraph is not accurate as stated, and is redundant given the next
paragraph, which is a better statement of the issues:

> While such opportunistic encryption protocols provide a high barrier against passive man-in-the-middle traffic interception, any attacker who can delete parts of the SMTP session (such as the "250 STARTTLS" response) or who can redirect the entire SMTP session (perhaps by overwriting the resolved MX record of the delivery domain) can perform such a downgrade or interception attack.

> This document defines a mechanism for recipient domains to publish policies specifying:

s/specifying/that specify/

> 	* whether MTAs sending mail to this domain can expect TLS support

Yes.

> 	* how MTAs can validate the TLS server certificate presented during mail delivery

Left-over from the original that tried to mix STS with DANE I think,
now obsolete, since authentication is always PKIX when used.

> 	* the expected identity of MXs that handle mail for this domain

Replace this with:

         * how to validate the names of the domain's MX hosts.

Should this still apply when the names are DNSSEC validated?  Or
should clients that obtain DNSSEC "secure" MX RRsets (or denial
of existence) skip the MX constraints in the STS policy, whose
primary purpose is to harden STS against DNS reply forgery?

Allowing DNSSEC to handle DNS forgery when available, makes STS
less fragile when the MX RRset legitimately differs from the published
or cached STS policy.

> 	* what an implementing sender should do with messages when TLS cannot be successfully negotiated

s/implementing sender/conforming client/

> The mechanism described is separated into four logical components:
> 
> 	• policy semantics: whether senders can expect a server for the recipient domain to support TLS encryption and how to validate the TLS certificate presented

See above, it seems to me that the "how to" is fixed.

> 	• failure report format: a mechanism for informing recipient domains about aggregate failure statistics

This moves to a separate report format draft IIRC.

> 1.1. Terminology
> 
> We also define the following terms for further use in this document:

s/also//

> 	• STS Policy: A definition of the expected TLS availability and behavior, as well as the desired actions for a given domain when a sending MTA encounters different results.

The phrase "definition of the expected TLS availability and behavior" seems rather amorphous.  Perhaps the authors can say something more concrete here.  Something along the lines of "A commitment by the server to support PKIX authenticated TLS via the specified MX hosts".

s/different results/contrary behavior/

> 	• Policy Domain: The domain against which an STS Policy is defined.

s/against/for/ ?

> 2. Related Technologies
> 
> The DANE TLSA record [RFC7672] is similar, in that DANE is also designed to upgrade opportunistic encryption into required encryption.

Better:  ..., in that DANE is also designed to upgrade optional unauthenticated TLS to required authenticated TLS.

> DANE requires DNSSEC [RFC4033] for the secure delivery of policies; the mechanism described here presents a variant for systems not yet supporting DNSSEC.
> 
> 2.1. Differences from DANE
> 
> The primary difference between the mechanism described here and DANE is that DANE requires the use of DNSSEC to authenticate DANE TLSA records, whereas SMTP STS relies on the certificate authority (CA) system to avoid interception.

Partly redundant, given the above, also "to avoid interception" is too imprecise.
Just say that STS relies on CAs rather than DNSSEC to authenticate the published policy.

> (For a thorough discussion of this trade-off, see the section Security Considerations.)
> 
> In addition, SMTP MTA-STS introduces a mechanism for failure reporting and a report-only mode, enabling offline ("report-only") deployments and auditing for compliance.

Since reporting is moving a separate document, that will also work with DANE, only "report-only" is now in scope.

> 
> 2.1.1. Advantages of SMTP MTA-STS when compared to DANE
> 
> SMTP MTA-STS offers the following advantages compared to DANE:
> 
> 	* Infrastructure: In comparison to DANE, this proposal does not require DNSSEC be deployed on either the sending or receiving domain. In addition, the reporting feature of SMTP MTA-STS can be deployed to perform offline analysis of STARTTLS failures, enabling mail providers to gain insight into the security of their SMTP connections without the need to modify MTA codebases directly.

The claim about not requiring MTA modifications is unsubstantiated, and I think false.
Clients need code changes to support either DANE or STS.  Servers don't need code changes
to support either.  Since "report-only" is discussed in the next bullet the "In addition, ..."
text should be deleted.

> 	* Offline or report-only usage: DANE does not provide a reporting mechanism and does not have a concept of "report-only" for failures;

The reporting draft will apply equally to DANE and STS, it is only the "report-only" mode
that is (at present) not defined for DANE.

> as a result, a service provider cannot receive metrics on TLS acceptability without asking senders to enforce a given policy;

This is not completely accurate, since a partial deployment is possible with DANE enabled on the primary MX, and not enabled on secondary MX hosts.  In that case, metrics from the primary MX host are generally adequate to guage interoperability, and the secondary MX hosts can be DANE-enabled once a sufficient comfort-level is achieved with the configuration of the primary.  DANE operators may not be aware of this option, but that's just a matter of publishing suitable "HOW-TO" documents, or even an informational RFC (though MTA administrators don't generally look for implementation guidance in RFCs).

> similarly, senders who cannot enforce DANE constraints at send-time have no mechanism to provide recipients such metrics from an offline (and potentially easier-to-deploy) logs-analysis batch process.

This part makes no sense.

> 2.1.2. Advantages of DANE when compared to SMTP MTA-STS
> 
> 	* Security: DANE offers an advantage against policy-lookup DoS attacks; that is, while a DNSSEC-signed NXDOMAIN response to a DANE lookup authoritatively indicates the lack of a DANE record, such an option to authenticate policy non-existence does not exist when looking up a policy over plain DNS.

More specifically, on "first-contact" DANE resists downgrade attacks, while STS does not.  Indeed STS does not resists attacks also when policy expires from the cache for destinations to which email is sent sufficiently infrequently.

Another important omission here is that when an MX-provider publishes TLSA records for an MX host, all customer DNSSEC-enabled domains that use that MX host are automatically secured.  The customers don't need to publish
any policies at all.  The security policy is published by the MX provider.  Thus the majority of DANE-protected
email domains (that I managed to find) are currently hosted by providers that host customer domains:

23317 transip.nl
 6135 udmedia.de
 1093 nederhost.net
  700 ec-elements.com
  663 bhosted.nl
  211 core-networks.de
  140 frobbit.se
  113 mailbox.org
  111 omc-mail.com
  ...

the customer domains just publish signed MX RRsets, for example:

   ; customer zone:
   mailous.com. IN MX 10 mx.transip.email.

   ; transip zone:
   mx.transip.email. IN A 149.210.149.76
   _25._tcp.mx.transip.email. IN TLSA 3 0 1 ee1b4c6e2fc82b542e456cea62452676c8049881e7feea8d2d7c7b0fccdc383f

[ If I can convince "one.com" to sign their zone and publish TLSA records for their MX hosts, there'll be at least another 500k new DANE domains, without any changes in the customer zones.  If anyone has good contacts at "one.com", please drop me a note. ]

> 3. Policy Semantics
> 
> SMTP MTA-STS policies are distributed via a "well known" HTTPS endpoint in the Policy Domain. A corresponding TXT record in the DNS alerts sending MTAs to the presence of a policy file.

s/alerts/informs/ or perhaps "signals".

> (Future implementations may move to alternate methods of policy discovery or distribution. See the section Future Work for more discussion.)

I am quite skeptical about the "Future Work" section, this is a draft RFC, not a grant proposal, and much of it seems rather speculative. I'd like to see that section deleted.

> The MTA-STS TXT record MUST specify the following fields:
> 
> 	* id: (plain-text, required). A short string used to track policy updates. This string MUST uniquely identify a given instance of a policy, such that senders can determine when the policy has been updated by comparing to the id of a previously seen policy, and must also match the policy_id value of the distributed policy.
> A lenient parser SHOULD accept a policy file implementing a superset of this specification, in which case unknown values SHALL be ignored.

If both the published policy and the DNS record carry just one "id", then changing these in concert becomes difficult.  If the HTTPS resource is updated first, then clients that see the new policy will constantly
refresh it via HTTPS because until the cached DNS record catches up.  If the DNS is updated first, similar
behaviour results.

Furthermore, the statement that these "MUST" match is then wrong, the "id" in the DNS policy is just a "refresh" signal, and the retrieved policy would sometimes legitimately not match.

Consequently, a better design is to publish multiple matching "id" values in the HTTPS policy which can list a few recently published DNS "id" values, in particular at least the current one published in the authoritative DNS zone, and typically also the previous that may still be present in some DNS caches.

The recommended update process woud then be to update the HTTPS policy "<id1>,<id2>" -> "<id2>,<id3>" and then update the DNS TXT record from "<id2>" -> "<id3>".  Clients that still have "<id2>" in their cached DNS record would then accept the new policy as fresh since it still matches "<id2>".

> Policies MUST specify the following fields in JSON [RFC4627] format:
> 
> 	* mode: (plain-text, required). If "enforce", the receiving MTA requests that messages be delivered only if they conform to the STS policy. If "report" the receiving MTA requests that failure reports be delivered, as specified by the rua parameter.

There is no longer any "rua" parameter, that moves to the reporting draft, and need not be "secured" via HTTPS.

> 	* mx: MX patterns (list of plain-text MX match patterns, required). One or more comma-separated patterns matching the expected MX for this domain. For example, ["*.example.com", "*.example.net"] indicates that mail for this domain might be handled by any MX whose hostname is a subdomain of "example.com" or "example.net". The semantics for these patterns should be the ones found in the "Checking of Wildcard Certificates" rules in Section 6.4.3 of [RFC6125].

I think this confuses the syntax for "presented identifiers" that are found in the peer certificate, with a new syntax for names that the client considers to be valid "reference identifiers" that are then compared with the presented identifiers.  The wildcard syntax in [RFC6125] describes the latter, and I think it is best to not
confuse the two semantically distinct usages.  Therefore, I would propose ".example.com" as the wildcard syntax
for the MX name.

Please also decide/describe whether this specifies a suffix that supports deeply nested MX hosts.  That is, should "mail1.mx.example.com" be valid for a policy that specifies ".example.com" (or "*.example.com" if the above proposed syntax is retained).

> 	• policy_id: A short string used to track policy updates. This string MUST uniquely identify a given instance of a policy, such that senders can determine when the policy has been updated by comparing to the policy_id of a previously seen policy.

See above, this needs to be multi-valued to make rollover work more smoothly.

> 
> 3.1.2. SMTP MTA-STS Policy
> 
> sts-id          = %x22 "policy_id" %x22 *WSP %x3a *WSP ; "policy_id":
>                   %x22 1*32(ALPHA / DIGIT) %x22        ; some chars

See above, should be multi-valued.

> 
> sts-mx          = %x22 "mx" $x22 *WSP %x3a *WSP      ; "mx":
>                   %x5B                               ; [
>                   domain-match                       ; comma-separated list
>                   [WSP %x2c domain-match WSP]        ; of domain-matches
>                   %x5B                               ; ]

See above, possibly omit "*" prefix for wildcards.

> A size limitation in a sts-uri, if provided, is interpreted as a count of units followed by an OPTIONAL unit size ("k" for kilobytes, "m" for megabytes, "g" for gigabytes, "t" for terabytes). Without a unit, the number is presumed to be a basic byte count. Note that the units are considered to be powers of two; a kilobyte is 2^10, a megabyte is 2^20, etc.

There ain't no "sts-uri", this is vestigial.

> 3.2. Policy Expirations

s/Expirations/Expiration/

> An important consideration for domains publishing a policy is that senders will see a policy expiration as relative to the fetch of a policy cached by their recursive resolver.

This is rather poorly worded.  The policy expiration time is always measured from the time it is fetched via HTTPS, not from the retrieval of any DNS record.  Thus a policy will be used for up to its max-age.

The DNS TTL only comes into play when signaling a policy refresh via a new "id", in which case some clients may not notice the new "id" until the previous DNS TTL expires.

> Consequently, a sender MAY treat a policy as valid for up to {expiration time} + {DNS TTL}. Publishers SHOULD thus continue to expect senders to apply old policies for up to this duration.

This is wrong, no policy will be cached beyond the last time it was available via HTTPS + its max-age.  The DNS TTL is only of interest when policies are replaced, and makes it possible (barring DNS MiTM) for clients to notice that cached policies are stale, and thus refresh them sooner.

> 3.2.1. Policy Updates
> 
> Updating the policy requires that the owner make changes in two places: the _mta_sts RR record in the Policy Domain's DNS zone and at the corresponding HTTPS endpoint.

Please avoid internal "_" in DNS names.  Thus use "_mta-sts" instead.  See precedents with "_xmpp-server", "_xmpp-client", ...

> In the case where the HTTPS endpoint has been updated but the TXT record has not been, senders will not know there is a new policy released and may thus continue to use old, previously cached versions. Recipients should thus expect a policy will continue to be used by senders until both the HTTPS and TXT endpoints are updated and the TXT record's TTL has passed.

Here, consider describing the rollover process with multiple "id" values in the HTTPS policy record.

> 3.3. Policy Discovery & Authentication
> 
> Senders discover a recipient domain's STS policy, by making an attempt to fetch TXT records from the recipient domain's DNS zone with the name "_mta_sts".

s/with the name "_mta_sts"/by prefixing the label "_mta-sts" to the recipient domain/

Also note that the "recipient domain" here is really the SMTP "nexthop" domain, and, when using explicit routing overrides (smarthost, or bilaterally agreed "custom" route from sender to recipient), the relevant domain is the domain name of the nexthop relay (which may or may not be subject to MX lookup, and in the latter case the STS policy MX constraints are out of scope).

> A valid TXT record presence in "_mta_sts.example.com" indicates that the recipent domain supports STS. To allow recipient domains to safely serve new policies, it is important that senders are able to authenticate a new policy retrieved for a recipient domain.

s/recipent/recipient/
s/safely/securely/

> Web PKI is the mechanism used for policy authentication.

s/for policy/for STS policy/

> In this mechanism, the sender fetches a HTTPS resource (policy) from a host at policy.mta-sts in the Policy Domain.

This is redundant and imprecise, the below is better and sufficient.

> The policy is served from a "well known" URI: https://policy.mta-sts.example.com/.well-known/mta-sts/current.

Insert ", with "example.com" replaced by the actual Policy Domain"

> To consider the policy as valid, the policy_id field in the policy MUST match the id field in the DNS TXT record under _mta_sts.

s/_mta_sts/_mta-sts/  Also update for multi-valued "id" in the policy.  Finally, no "MUST"s here, if the HTTPS id does not match the DNS, the policy is still valid, but now the client will check for updates as frequently as the client implementation allows since the DNS always seems to indicate a requisite refresh.  DNS is not authoritative here, and a freshly retrieved and authenticated HTTPS policy holds regardless of any "id" values in DNS.

> When fetching a new policy or updating a policy, the new policy MUST be fully authenticated (HTTPS certificate validation + peer verification) before use.

s/peer verification/peer name verification/ and make it clear that the peer being verified here is the HTTPS server, not the MX host.

> A policy which has not ever been successfully authenticated MUST NOT be used to reject mail.

This is misleading.  An unauthenticated HTTPS response MUST be ignored (typically the HTTPS handshake fails, and no policy is retrieved), so the issue of whether it is used to "reject" is moot, there is no "it" that can be used to make policy decisions.

> 3.4. Policy Validation
> 
> When sending to an MX at a domain for which the sender has a valid and non-expired SMTP MTA-STS policy, a sending MTA honoring SMTP MTA-STS MUST validate that the recipient MX supports STARTTLS, and offers a valid PKIX based TLS certificate.

Note that some domains have no explicit MX records, rather, absent any MX records for "example.com", the MX RRset for "example.com" is implicitly "example.com. IN MX 0 example.com."  So it should be stated somewhere, that "MX" here includes the implicit case.

> The certificate presented by the receiving MX MUST be valid for the MX name and chain to a root CA that is trusted by the sending MTA. The certificate MUST have a CN or SAN matching the MX hostname (as described in [RFC6125]) and be non-expired.

Early in this section the "report only" mode needs to be mentioned.  While the client still needs to figure out whether the peer matches the policy or not, in "report only" mode, the client proceeds to deliver the mail regardless, but presumably attempts to report the failure in some appropriate way.  This is covered in the next section, but should also be mentioned here, lest this text be misread.

> 3.5. Policy Application
> 
> When sending to an MX at a domain for which the sender has a valid non-expired SMTP MTA-STS policy, a sending MTA honoring SMTP MTA-STS MAY apply the result of a policy validation one of two ways:
> 
> 	* report: In this mode, sending MTAs merely send a report to the designated report address indicating policy application failures. This can be done "offline", i.e. based on the MTA logs, and is thus a suitable low-risk option for MTAs who wish to enhance transparency of TLS tampering without making complicated changes to production mail-handling infrastructure.

This is misleading.  Client MTAs that are unaware of STS policy, would not be in any position to log policy violations, and so also not able to generate meaningful reports.  Reports require a non-trivial population of
suitably enabled clients.

Still the claim that "report only" mode avoids production changes is largely unfounded.  What report-only
does is make it possible for the operators of receiving MTAs to test their policy before proceeding to make
it mandatory (assuming they have working reporting and a sufficiently representative pool of STS-enabled
reporting clients).

> 	* enforce: In this mode, sending MTAs SHOULD treat STS policy failures, in which the policy action is "reject", as a mail delivery error, and SHOULD terminate the SMTP connection, not delivering any more mail to the recipient MTA.

This fails to describe the behaviour when the nexthop domain has multiple MX hosts.  It also fails to describe how to handle MX RRsets in which some MX hosts match the "mx" policy component, and some do not.

My suggestion would be that non-matching MX hosts and any MX hosts with a worse (higher) MX preference
be removed from the MX RRset, leaving only matching hosts at an equal or better (lower) preference.  Mail
delivery can proceed only if that set is non-empty.  If a first matching MX host fails authentication, then
a second matching MX host is tried, ... until one passes, all are tried, or some sender limit on the number
of MX hosts to try is reached.  Mail is deferred if none of the attempted MX hosts pass authentication.

Naturally, if the sending MTA finds itself in the destination RRset, then it MUST remove all MX hosts with
a preference equal or greater (worse) than its own preference, EVEN IF its own name does not match the "mx"
field in the destination policy.  Loop elimination trumps all other considerations.

Also "not delivering any more mail to the recipient MTA" is rather an overstatement.  All one can reasonably say is that the message in question is not sent via the problem MX host.  Later messages may well be sent via the problem MX host, provided it meets the policy requirements for those messages.

> In enforce mode, however, sending MTAs MUST first check for a new authenticated policy before actually treating a message failure as fatal.

It is rather unclear how this is supposed to work in the presence of multiple MX hosts.  When a first MX host fails, MUST the policy be refreshed there and then, or do we skip to the next MX host, and refresh the policy only when all fail?  Secondly, this requirement makes implementation rather more complex.  It is far simpler to defer the mail, and wait for a signal from an updated "id" in DNS.  Receiving systems should use short TTLs on the TXT RRs that carry the "id" value.  Refreshing the policy and trying the same message again synchronously is rather more complex.  A sending MTA might however trigger a background policy refresh if the current policy was not cached "recently".  A background refresh would limit the duration of any "outage" while holding a stale policy (negligent receiving system operator practice).

> Thus the control flow for a sending MTA that does online policy application consists of the following steps:
> 
> 	1. Check for cached non-expired policy. If none exists, fetch the latest, authenticate and cache it.

Only if a DNS TXT record signals that a policy is expected.

> 	2. Validate recipient MTA against policy. If valid, deliver mail.

This is ill-defined, since multi-MX behaviour is not described.

> 	3. If not valid and the policy specifies reporting, generate report.

Reporting is no longer specified in STS policies.  Rather they just specify
"soft" vs. "hard" failure, with mail delivered anyway in the former case, and
any reports requested (separate draft) sent in either case.

> 	4. If not valid and policy specifies rejection, perform the following steps:
> 
> 		* Check for a new (non-cached) authenticated policy.

Possibly in the background, with the current message deferred.  Thus either a
synchronous retry, or an implicit "stale id" signal, that triggers an asynchronous
policy refresh.

> 		* If one exists and the new policy is different, update the current policy and go to step 2.

That's the synchronous behaviour.  Also what happens when retrieval fails (connection timeout,
failure to authenticate the HTTPS server, HTTPS error other than 404, ...)?

> 		* If one exists and the new policy is same as the cached policy, treat the delivery as a failure.

Again, synchronous behaviour.  I would treat the delivery failure as transient (4XX) and queue the mail,
and say so in the spec.

> 		* If none exists and cached policy is not expired, treat the delivery as a failure.

This does not seem right.  What does "none exists" mean?  If the HTTPS server returns an authenticated "404",
then presumably the domain no longer implements STS, and the cached policy should be deleted!  Hanging on to
a stale no-longer published policy feels rather wrong.

Which I think suggests that "404" should be clearly specified as a mechanism to revoke all STS policy.

> Remember that each policy has an expiration time (which SHOULD be long, on the order of days or months) and a validation method.

There is no longer a "validation method" (i.e. just PKIX, no DANE).  The "mode" (enforce or report-only) if that's what is meant here, should be consistently called by some other name (failure mode?).

> With these two mechanisms and the procedure specified in step 4,

What "mechanisms"?

> recipients who publish a policy have, in effect, a means of updating a cached policy at arbitrary intervals, without the risks (of a man-in-the-middle attack) they would incur if they were to shorten the policy expiration time.

What makes timely refresh possible is primarily the combination of the "id" fields in the policy and the DNS TXT record, but that's not what's described above.  Refresh on failure is only a last-resort in case of operator incompetence.  A competent operator will ensure that the MX hosts always pass the currently published policy
and any recently published policies whose max-age has not yet expired since the last time at which they were published.  Such an operator will also use the TXT record "id" field to signal policy changes in a timely manner.

> 6. Security Considerations
> 
> Since we use DNS TXT record for policy discovery, an attacker who is able to block DNS responses can suppress the discovery of an STS Policy, making the Policy Domain appear not to have an STS Policy. The caching model described in Policy Expirations is designed to resist this attack,

Provided that email is sent to the destination sufficiently frequently.  STS does not protect first contact and does not protect email to infrequently contacted peer domains.

> and there is discussion in the Future Work section around future distribution mechanisms that are robust against this attack.

"Future work" is IMNSHO out of scope.

> 
> 7. Future Work
> 
> The authors would like to suggest multiple considerations for future discussion.

I would like to see this section deleted.

> 	* Certificate pinning: One potential improvement in the robustness of the certificate validation methods discussed would be the deployment of public-key pinning as defined for HTTP in [RFC7469]. A policy extension supporting these semantics would enable Policy Domains to specify certificates that MUST appear in the MX certificate chain, thus providing resistence against compromised CA or DNSSEC zone keys.

IMNSHO completely impractical, and since we're trusting CAs to deliver the pinning policy, largely ineffective.
I shan't bother to point out editorial issues.

> 	* Policy distribution: As with Certificate Transparency ([RFC6962]), it may be possible to provide a verifiable log of policy observations (meaning which policies have been observed for a given Policy Domain). This would provide insight into policy spoofing or faked policy non-existence. This may be particularly useful for Policy Domains not using DNSSEC, since it would provide sending MTAs an authoritative source for whether a policy is expected for a given domain.

Much too speculative.  Major "spamming" hurdles, since policies are not signed, just their transport is via HTTP, but that fact can't be verified by the log operators.

> 	* Receive-from restrictions: Policy publishers may wish to also indicate to domains receiving mail from the Policy Domain that all such mail is expected to be sent via TLS.

This breaks forwarding, ...  TLS is a hop-by-hop mechanism, but envelope sender addresses are end-to-end.
As before "Future work" is for future RFCs.

> 	* Cipher and TLS version restrictions: Policy publishers may also wish to restrict TLS negotiation to specific ciphers or TLS versions.

Major interoperability issues.  Bad idea IMHO, and "Future work" should not be here.

> 8. Appendix 1: Validation Pseudocode
> 
> policy = policy_from_cache()
> if not policy or is_expired(policy):
>   policy = policy_from_https_endpoint()  // fetch and authenticate!
>   update_cache = true

The HTTPS endpoint is only queried when a DNS TXT record indicates that it
may be present.

> if policy:
>   if invalid_mx_or_tls(policy):  // check MX and TLS cert

	This step is much too condensed.  Only some of the MX hosts
        may be "invalid" per the policy.  Only some may fail the
        TLS requirements, ...

>     if rua:
>       generate_report()

	The "rua" is not described here, so "if reporting requested".

>     if p_reject():
>       policy = policy_from_https_endpoint()  // fetch and authenticate #2!
>       update_cache = true

	Possibly async refresh

>       if invalid_mx_or_tls(policy):
>         reject_message()
>         update_cache = false

	s/reject_message/defer_message/ or more typically skip to next MX if any.
        This whole state-machine may need an outer loop over the MX hosts, and a
        description of how the MX host list is initially constructed....

>   if update_cache:
>     cache(policy)

Are policies cached when only some of the MX hosts match the "mx" field?
What if verification succeeds only for a second MX host?  What is the
definition of "success" that makes a policy validated for caching?

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 10 Aug 2016 00:10:44 +0200

Thanks to the both of you. Lots of feedback, but hopefully we can get a new
draft together to incorporate this shortly.

I really appreciate it.

Dan

On Tue, Aug 9, 2016 at 9:08 PM, Viktor Dukhovni <[email-masked]>
wrote:

>
> My review below.  Executive summary, at least a -02 (and likely then an
> -03) is needed to correct many issues before this is ready for WGLC.
>
> > 1. Introduction
> >
> > The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and hosts
> to establish secure SMTP sessions over TLS. In its current form, however,
> it fails to provide (a) message confidentiality — because opportunistic
> STARTTLS is subject to downgrade attacks — and (b) server authenticity —
> because the trust relationship from email domain to MTA server identity is
> not cryptographically validated.
>
> > While such opportunistic encryption protocols provide a high barrier
> against passive man-in-the-middle traffic interception, any attacker who
> can delete parts of the SMTP session (such as the "250 STARTTLS" response)
> or who can redirect the entire SMTP session (perhaps by overwriting the
> resolved MX record of the delivery domain) can perform such a downgrade or
> interception attack.
>
>
> >       • policy semantics: whether senders can expect a server for the
> recipient domain to support TLS encryption and how to validate the TLS
> certificate presented
>
> >       • failure report format: a mechanism for informing recipient
> domains about aggregate failure statistics
>
> >       • STS Policy: A definition of the expected TLS availability and
> behavior, as well as the desired actions for a given domain when a sending
> MTA encounters different results.
>
> The phrase "definition of the expected TLS availability and behavior"
> seems rather amorphous.  Perhaps the authors can say something more
> concrete here.  Something along the lines of "A commitment by the server to
> support PKIX authenticated TLS via the specified MX hosts".
>
> > The DANE TLSA record [RFC7672] is similar, in that DANE is also designed
> to upgrade opportunistic encryption into required encryption.
>
> Better:  ..., in that DANE is also designed to upgrade optional
> unauthenticated TLS to required authenticated TLS.
>
> > DANE requires DNSSEC [RFC4033] for the secure delivery of policies; the
> mechanism described here presents a variant for systems not yet supporting
> DNSSEC.
> >
> > The primary difference between the mechanism described here and DANE is
> that DANE requires the use of DNSSEC to authenticate DANE TLSA records,
> whereas SMTP STS relies on the certificate authority (CA) system to avoid
> interception.
>
> > In addition, SMTP MTA-STS introduces a mechanism for failure reporting
> and a report-only mode, enabling offline ("report-only") deployments and
> auditing for compliance.
>
> Since reporting is moving a separate document, that will also work with
> DANE, only "report-only" is now in scope.
>
> >
> >       * Infrastructure: In comparison to DANE, this proposal does not
> require DNSSEC be deployed on either the sending or receiving domain. In
> addition, the reporting feature of SMTP MTA-STS can be deployed to perform
> offline analysis of STARTTLS failures, enabling mail providers to gain
> insight into the security of their SMTP connections without the need to
> modify MTA codebases directly.
>
> >       * Offline or report-only usage: DANE does not provide a reporting
> mechanism and does not have a concept of "report-only" for failures;
>
> > as a result, a service provider cannot receive metrics on TLS
> acceptability without asking senders to enforce a given policy;
>
> This is not completely accurate, since a partial deployment is possible
> with DANE enabled on the primary MX, and not enabled on secondary MX
> hosts.  In that case, metrics from the primary MX host are generally
> adequate to guage interoperability, and the secondary MX hosts can be
> DANE-enabled once a sufficient comfort-level is achieved with the
> configuration of the primary.  DANE operators may not be aware of this
> option, but that's just a matter of publishing suitable "HOW-TO" documents,
> or even an informational RFC (though MTA administrators don't generally
> look for implementation guidance in RFCs).
>
> > similarly, senders who cannot enforce DANE constraints at send-time have
> no mechanism to provide recipients such metrics from an offline (and
> potentially easier-to-deploy) logs-analysis batch process.
>
> >       * Security: DANE offers an advantage against policy-lookup DoS
> attacks; that is, while a DNSSEC-signed NXDOMAIN response to a DANE lookup
> authoritatively indicates the lack of a DANE record, such an option to
> authenticate policy non-existence does not exist when looking up a policy
> over plain DNS.
>
> More specifically, on "first-contact" DANE resists downgrade attacks,
> while STS does not.  Indeed STS does not resists attacks also when policy
> expires from the cache for destinations to which email is sent sufficiently
> infrequently.
>
> Another important omission here is that when an MX-provider publishes TLSA
> records for an MX host, all customer DNSSEC-enabled domains that use that
> MX host are automatically secured.  The customers don't need to publish
> any policies at all.  The security policy is published by the MX
> provider.  Thus the majority of DANE-protected
> [ If I can convince "one.com" to sign their zone and publish TLSA records
> for their MX hosts, there'll be at least another 500k new DANE domains,
> without any changes in the customer zones.  If anyone has good contacts at "
> one.com", please drop me a note. ]
>
> > 3. Policy Semantics
> >
> > SMTP MTA-STS policies are distributed via a "well known" HTTPS endpoint
> in the Policy Domain. A corresponding TXT record in the DNS alerts sending
> MTAs to the presence of a policy file.
>
> > (Future implementations may move to alternate methods of policy
> discovery or distribution. See the section Future Work for more discussion.)
>
> I am quite skeptical about the "Future Work" section, this is a draft RFC,
> not a grant proposal, and much of it seems rather speculative. I'd like to
> see that section deleted.
>
> >       * id: (plain-text, required). A short string used to track policy
> updates. This string MUST uniquely identify a given instance of a policy,
> such that senders can determine when the policy has been updated by
> comparing to the id of a previously seen policy, and must also match the
> policy_id value of the distributed policy.
> > A lenient parser SHOULD accept a policy file implementing a superset of
> this specification, in which case unknown values SHALL be ignored.
>
> If both the published policy and the DNS record carry just one "id", then
> changing these in concert becomes difficult.  If the HTTPS resource is
> updated first, then clients that see the new policy will constantly
> Furthermore, the statement that these "MUST" match is then wrong, the "id"
> in the DNS policy is just a "refresh" signal, and the retrieved policy
> would sometimes legitimately not match.
>
> Consequently, a better design is to publish multiple matching "id" values
> in the HTTPS policy which can list a few recently published DNS "id"
> values, in particular at least the current one published in the
> authoritative DNS zone, and typically also the previous that may still be
> present in some DNS caches.
>
> The recommended update process woud then be to update the HTTPS policy
> "<id1>,<id2>" -> "<id2>,<id3>" and then update the DNS TXT record from
> "<id2>" -> "<id3>".  Clients that still have "<id2>" in their cached DNS
> record would then accept the new policy as fresh since it still matches
> "<id2>".
>
>
> >       * mode: (plain-text, required). If "enforce", the receiving MTA
> requests that messages be delivered only if they conform to the STS policy.
> If "report" the receiving MTA requests that failure reports be delivered,
> as specified by the rua parameter.
>
> >       * mx: MX patterns (list of plain-text MX match patterns,
> required). One or more comma-separated patterns matching the expected MX
> for this domain. For example, ["*.example.com", "*.example.net"]
> indicates that mail for this domain might be handled by any MX whose
> hostname is a subdomain of "example.com" or "example.net". The semantics
> for these patterns should be the ones found in the "Checking of Wildcard
> Certificates" rules in Section 6.4.3 of [RFC6125].
>
> I think this confuses the syntax for "presented identifiers" that are
> found in the peer certificate, with a new syntax for names that the client
> considers to be valid "reference identifiers" that are then compared with
> the presented identifiers.  The wildcard syntax in [RFC6125] describes the
> latter, and I think it is best to not
> Please also decide/describe whether this specifies a suffix that supports
> deeply nested MX hosts.  That is, should "mail1.mx.example.com" be valid
> for a policy that specifies ".example.com" (or "*.example.com" if the
> above proposed syntax is retained).
>
> >       • policy_id: A short string used to track policy updates. This
> string MUST uniquely identify a given instance of a policy, such that
> senders can determine when the policy has been updated by comparing to the
> policy_id of a previously seen policy.
>
> > A size limitation in a sts-uri, if provided, is interpreted as a count
> of units followed by an OPTIONAL unit size ("k" for kilobytes, "m" for
> megabytes, "g" for gigabytes, "t" for terabytes). Without a unit, the
> number is presumed to be a basic byte count. Note that the units are
> considered to be powers of two; a kilobyte is 2^10, a megabyte is 2^20, etc.
>
> > An important consideration for domains publishing a policy is that
> senders will see a policy expiration as relative to the fetch of a policy
> cached by their recursive resolver.
>
> This is rather poorly worded.  The policy expiration time is always
> measured from the time it is fetched via HTTPS, not from the retrieval of
> any DNS record.  Thus a policy will be used for up to its max-age.
>
> The DNS TTL only comes into play when signaling a policy refresh via a new
> "id", in which case some clients may not notice the new "id" until the
> previous DNS TTL expires.
>
> > Consequently, a sender MAY treat a policy as valid for up to {expiration
> time} + {DNS TTL}. Publishers SHOULD thus continue to expect senders to
> apply old policies for up to this duration.
>
> This is wrong, no policy will be cached beyond the last time it was
> available via HTTPS + its max-age.  The DNS TTL is only of interest when
> policies are replaced, and makes it possible (barring DNS MiTM) for clients
> to notice that cached policies are stale, and thus refresh them sooner.
>
> > 3.2.1. Policy Updates
> >
> > Updating the policy requires that the owner make changes in two places:
> the _mta_sts RR record in the Policy Domain's DNS zone and at the
> corresponding HTTPS endpoint.
>
> Please avoid internal "_" in DNS names.  Thus use "_mta-sts" instead.  See
> precedents with "_xmpp-server", "_xmpp-client", ...
>
> > In the case where the HTTPS endpoint has been updated but the TXT record
> has not been, senders will not know there is a new policy released and may
> thus continue to use old, previously cached versions. Recipients should
> thus expect a policy will continue to be used by senders until both the
> HTTPS and TXT endpoints are updated and the TXT record's TTL has passed.
>
> > Senders discover a recipient domain's STS policy, by making an attempt
> to fetch TXT records from the recipient domain's DNS zone with the name
> "_mta_sts".
>
> Also note that the "recipient domain" here is really the SMTP "nexthop"
> domain, and, when using explicit routing overrides (smarthost, or
> bilaterally agreed "custom" route from sender to recipient), the relevant
> domain is the domain name of the nexthop relay (which may or may not be
> subject to MX lookup, and in the latter case the STS policy MX constraints
> are out of scope).
>
> > A valid TXT record presence in "_mta_sts.example.com" indicates that
> the recipent domain supports STS. To allow recipient domains to safely
> serve new policies, it is important that senders are able to authenticate a
> new policy retrieved for a recipient domain.
>
> s/recipent/recipient/
> s/safely/securely/
>
> > In this mechanism, the sender fetches a HTTPS resource (policy) from a
> host at policy.mta-sts in the Policy Domain.
>
> > To consider the policy as valid, the policy_id field in the policy MUST
> match the id field in the DNS TXT record under _mta_sts.
>
> s/_mta_sts/_mta-sts/  Also update for multi-valued "id" in the policy.
> Finally, no "MUST"s here, if the HTTPS id does not match the DNS, the
> policy is still valid, but now the client will check for updates as
> frequently as the client implementation allows since the DNS always seems
> to indicate a requisite refresh.  DNS is not authoritative here, and a
> freshly retrieved and authenticated HTTPS policy holds regardless of any
> "id" values in DNS.
>
> > When fetching a new policy or updating a policy, the new policy MUST be
> fully authenticated (HTTPS certificate validation + peer verification)
> before use.
>
> s/peer verification/peer name verification/ and make it clear that the
> peer being verified here is the HTTPS server, not the MX host.
>
> This is misleading.  An unauthenticated HTTPS response MUST be ignored
> (typically the HTTPS handshake fails, and no policy is retrieved), so the
> issue of whether it is used to "reject" is moot, there is no "it" that can
> be used to make policy decisions.
>
> > 3.4. Policy Validation
> >
> > When sending to an MX at a domain for which the sender has a valid and
> non-expired SMTP MTA-STS policy, a sending MTA honoring SMTP MTA-STS MUST
> validate that the recipient MX supports STARTTLS, and offers a valid PKIX
> based TLS certificate.
>
> Note that some domains have no explicit MX records, rather, absent any MX
> records for "example.com", the MX RRset for "example.com" is implicitly "
> example.com. IN MX 0 example.com."  So it should be stated somewhere,
> that "MX" here includes the implicit case.
>
> > The certificate presented by the receiving MX MUST be valid for the MX
> name and chain to a root CA that is trusted by the sending MTA. The
> certificate MUST have a CN or SAN matching the MX hostname (as described in
> [RFC6125]) and be non-expired.
>
> Early in this section the "report only" mode needs to be mentioned.  While
> the client still needs to figure out whether the peer matches the policy or
> not, in "report only" mode, the client proceeds to deliver the mail
> regardless, but presumably attempts to report the failure in some
> appropriate way.  This is covered in the next section, but should also be
> mentioned here, lest this text be misread.
>
> > 3.5. Policy Application
> >
> > When sending to an MX at a domain for which the sender has a valid
> non-expired SMTP MTA-STS policy, a sending MTA honoring SMTP MTA-STS MAY
> apply the result of a policy validation one of two ways:
> >
> >       * report: In this mode, sending MTAs merely send a report to the
> designated report address indicating policy application failures. This can
> be done "offline", i.e. based on the MTA logs, and is thus a suitable
> low-risk option for MTAs who wish to enhance transparency of TLS tampering
> without making complicated changes to production mail-handling
> infrastructure.
>
> This is misleading.  Client MTAs that are unaware of STS policy, would not
> be in any position to log policy violations, and so also not able to
> generate meaningful reports.  Reports require a non-trivial population of
> >       * enforce: In this mode, sending MTAs SHOULD treat STS policy
> failures, in which the policy action is "reject", as a mail delivery error,
> and SHOULD terminate the SMTP connection, not delivering any more mail to
> the recipient MTA.
>
> This fails to describe the behaviour when the nexthop domain has multiple
> MX hosts.  It also fails to describe how to handle MX RRsets in which some
> MX hosts match the "mx" policy component, and some do not.
>
> Also "not delivering any more mail to the recipient MTA" is rather an
> overstatement.  All one can reasonably say is that the message in question
> is not sent via the problem MX host.  Later messages may well be sent via
> the problem MX host, provided it meets the policy requirements for those
> messages.
>
> > In enforce mode, however, sending MTAs MUST first check for a new
> authenticated policy before actually treating a message failure as fatal.
>
> It is rather unclear how this is supposed to work in the presence of
> multiple MX hosts.  When a first MX host fails, MUST the policy be
> refreshed there and then, or do we skip to the next MX host, and refresh
> the policy only when all fail?  Secondly, this requirement makes
> implementation rather more complex.  It is far simpler to defer the mail,
> and wait for a signal from an updated "id" in DNS.  Receiving systems
> should use short TTLs on the TXT RRs that carry the "id" value.  Refreshing
> the policy and trying the same message again synchronously is rather more
> complex.  A sending MTA might however trigger a background policy refresh
> if the current policy was not cached "recently".  A background refresh
> would limit the duration of any "outage" while holding a stale policy
> (negligent receiving system operator practice).
>
> > Thus the control flow for a sending MTA that does online policy
> application consists of the following steps:
> >
> > Remember that each policy has an expiration time (which SHOULD be long,
> on the order of days or months) and a validation method.
>
> There is no longer a "validation method" (i.e. just PKIX, no DANE).  The
> "mode" (enforce or report-only) if that's what is meant here, should be
> consistently called by some other name (failure mode?).
>
> > recipients who publish a policy have, in effect, a means of updating a
> cached policy at arbitrary intervals, without the risks (of a
> man-in-the-middle attack) they would incur if they were to shorten the
> policy expiration time.
>
> What makes timely refresh possible is primarily the combination of the
> "id" fields in the policy and the DNS TXT record, but that's not what's
> described above.  Refresh on failure is only a last-resort in case of
> operator incompetence.  A competent operator will ensure that the MX hosts
> always pass the currently published policy
> and any recently published policies whose max-age has not yet expired
> since the last time at which they were published.  Such an operator will
> also use the TXT record "id" field to signal policy changes in a timely
> manner.
>
> > Since we use DNS TXT record for policy discovery, an attacker who is
> able to block DNS responses can suppress the discovery of an STS Policy,
> making the Policy Domain appear not to have an STS Policy. The caching
> model described in Policy Expirations is designed to resist this attack,
>
> Provided that email is sent to the destination sufficiently frequently.
> STS does not protect first contact and does not protect email to
> infrequently contacted peer domains.
>
> > and there is discussion in the Future Work section around future
> distribution mechanisms that are robust against this attack.
>
> >       * Certificate pinning: One potential improvement in the robustness
> of the certificate validation methods discussed would be the deployment of
> public-key pinning as defined for HTTP in [RFC7469]. A policy extension
> supporting these semantics would enable Policy Domains to specify
> certificates that MUST appear in the MX certificate chain, thus providing
> resistence against compromised CA or DNSSEC zone keys.
>
> >       * Policy distribution: As with Certificate Transparency
> ([RFC6962]), it may be possible to provide a verifiable log of policy
> observations (meaning which policies have been observed for a given Policy
> Domain). This would provide insight into policy spoofing or faked policy
> non-existence. This may be particularly useful for Policy Domains not using
> DNSSEC, since it would provide sending MTAs an authoritative source for
> whether a policy is expected for a given domain.
>
> Much too speculative.  Major "spamming" hurdles, since policies are not
> signed, just their transport is via HTTP, but that fact can't be verified
> by the log operators.
>
> >       * Receive-from restrictions: Policy publishers may wish to also
> indicate to domains receiving mail from the Policy Domain that all such
> mail is expected to be sent via TLS.
>
> >       * Cipher and TLS version restrictions: Policy publishers may also
> wish to restrict TLS negotiation to specific ciphers or TLS versions.
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 9 Aug 2016 18:33:37 -0400

> On Aug 9, 2016, at 3:08 PM, Viktor Dukhovni <[email-masked]> wrote:
> 
>> 

By the way, feel free to fix obvious errors in my suggested text, e.g. above it should have been "the use of TLS channel security" not "the use of a TLS channel security".  The extra indefinite article was left over due to an incomplete edit.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 11 Aug 2016 17:59:08 +0200

Trimmed to a few parts I have immediate comment/questions on:

> primary purpose is to harden STS against DNS reply forgery?

When would you want to do this but use STS instead of TLSA for the actual
cert validation? Conceivably if your MX domain isn't your mail To domain
and only the latter supports DNSSEC, I suppose. So I can see an argument
for it.

On the other hand, wouldn't a lot of senders have a stub resolver that
doesn't know the validation status for DNSSEC (as the recursive resolver is
the validating resolver)? In that case, how would this work? I guess if
this is a MAY or a SHOULD that's still OK...

> record would then accept the new policy as fresh since it still matches

I notice that you and Stephen both caught this issue. We had been
discussing it recently among the authors as well. Stephen's suggestion, in
comparison:

Why not fetch ".well-known/mta-sts/<id>" where <id> is
> what I got from the TXT RR?

I happen to favor this suggestion over the more complex one Viktor proposes
above. I think not all of the co-authors agree, however.

Any concerns (Viktor, or anyone else) with Stephen's suggestion? It seems
like the smallest possible fix for this issue, and a very coherent one.
Once the TXT update is out for >DNS TTL, of course, admins can remove the
old JSON policy files to avoid a DNS MITM serving an old policy (for
whatever gain).

The primary counterargument here is, I think, the operational overhead of
having to update the TXT on every policy update, but I think that's
basically a given so long as we rely on DNS for the "there's a new policy!"
signal.

> freshly retrieved and authenticated HTTPS policy holds regardless of any

I think you missed the point of the directive (which is fairly easy to do,
because on rereading this sentence is worded completely incorrectly!).

My point here was actually that a policy *once fetched MUST be applied to
at least one message to one MX* before it is cached as valid. The reasoning
here is to prevent caching and perma-DoS'ing someone who just serves up a
totally broken policy. So we want to not only require the HTTPS fetch to
succeed and the policy to fetch, but the policy to actually *work*. This is
a higher burden on implementors (who must now cache the "success bit" per
policy), but it seems worth it, I think. Thoughts?

Dan

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 11 Aug 2016 17:46:39 +0000

> and only the latter supports DNSSEC, I suppose. So I can see an argument

The domain owner may have DNSSEC-validated MX RRs pointing to an
MX provider whose zone is unsigned, or in any case one that does
not publish TLSA records.  The provider's MX hosts may have usable
PKIX certs.

> this is a MAY or a SHOULD that's still OK...

The question applies to senders (really SMTP clients) whose stub
resolver is either validating or security-aware (via the AD bit of
a trusted iterator).  If the MX RRset is adequately protected,
should the "mx" attribute from the policy be strictly enforced?
(One could just log a warning and/or generate a report, but deliver
anyway, based on the validated MX RRset).

> > what I got from the TXT RR?

This has a fundamental weakness.  The "id" in the DNS TXT record
is untrusted data.  Attackers can redirect the client to a stale
id, or to an ID that returns "404".  Since IMHO "404" should signal
policy revocation, (otherwise there's no timely way to revoke a
policy) this is a problem.

> old JSON policy files to avoid a DNS MITM serving an old policy (for

See above.

> because on rereading this sentence is worded completely incorrectly!).

More than "easy to do", the sentence simply does not say anything along the
lines of what you suggest below.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 11 Aug 2016 21:37:47 +0200

> policy) this is a problem.

That's a good point.

Another option (also, IMO, simpler than multiple versions) is to simply not
indicate the ID string in the JSON at all, but only in the TXT. It's not
clear to me why it has to be in the JSON anyway (but I haven't thought this
through very far).

---

From: Binu Ramakrishnan <[email-masked]>
Date: Thu, 11 Aug 2016 20:19:06 +0000 (UTC)

Victor,
We appreciate your time and effort reviewing our draft.Lately we had some discussions related to policy cache and refresh in GitHub. One proposal was not to depend on DNS beyond initial discovery. We have some flow diagrams (#72) in the below links that provide some insights to what I'm referring to. 
https://github.com/mrisher/smtp-sts/issues/72https://github.com/mrisher/smtp-sts/issues/62

thanks,-binu

      From: Viktor Dukhovni <[email-masked]>
 To: [email-masked] 
 Sent: Thursday, 11 August 2016 10:46 AM
 Subject: Re: [Uta] review of mta-sts-01

See above.

-- 
    Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 11 Aug 2016 23:07:31 +0000

> clear to me why it has to be in the JSON anyway (but I haven't thought this

Yes, the client's cache could store the DNS id seen at the time of
the most recent cache fetch.  Then when the DNS id changes, a new
fetch happens, and the new cache entry records that.  In this case
there is no id in the policy itself.

Mind you, this can complicate debugging of problems, because the
client's cache id when a problem is encountered, might not uniquely
identify a given server policy.  Not a major problem, but something
perhaps to consider.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 11 Aug 2016 23:17:54 +0000

On Thu, Aug 11, 2016 at 08:19:06PM +0000, Binu Ramakrishnan wrote:

> We appreciate your time and effort reviewing our draft.Lately we had some
> discussions related to policy cache and refresh in GitHub. One proposal
> was not to depend on DNS beyond initial discovery. We have some flow
> diagrams (#72) in the below links that provide some insights to what I'm
> referring to. 
> https://github.com/mrisher/smtp-sts/issues/62

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.

Refreshing all cached destinations once a day seems rather wasteful
and needlessly slow to notice intra-day changes.

Changes in the DNS id can be more timely and are much cheaper to
detect than changes in the HTTPS resource.  I'm reluctant to
recommend just HTTPS polling for refresh.

-- 
	Viktor.

---

From: Binu Ramakrishnan <[email-masked]>
Date: Fri, 12 Aug 2016 00:02:18 +0000 (UTC)

Thanks Victor!
> 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. Once the policy is in cache, a separate process can actually keep the cache in sync. Direct HTTPS call is made only in this case. Separate process for refresh is one option, but it can also be an async operation in the mail delivery flow. 
> and needlessly slow to notice intra-day changes.> Changes in the DNS id can be more timely and are much cheaper to

One argument against relying on DNS TTL is that TTL can vary from minutes to days. This can affect the refresh time. Lets say we have a policy with max-age sets to 24 hours. Assume you want to update it. So you put a new policy policy in HTTP endpoint, and diligently updates the new policy version id in DNS, expecting the policy to propagate in 24 hours. If the DNS TTL is 7 days, it takes much longer than 24 hrs to to propagate. In most cases the policy owner may not even aware of this TTL. When you take into account that these systems are often administered by different team or org, this is an additional thing policy owner needs to be worry about.
Here is my original writeup on this issue for reference (with few minor edits) :==Use DNS TXT record for initial discovery, and there onwards fetch policies directly from HTTP endpoint without relying on DNS.
Why this revision?    
   - We no longer have to deal with ‘id’ mismatch or sync issues.
   - Remove the need to update DNS every time we change the policy. Less implementation complexity,  and one less thing to worry about for operations team.
   - As a best practice, and to bring more control, caching and refresh should be handled in application layer. DNS TTLs are inconsistent and can affect policy refresh cycle.
   - Forced policy fetch when the policy validation fails: Do we depend on DNS TXT or directly fetch from HTTP endpoint? At the least, this part is not covered in the current draft.

There are two arguments against directly hitting HTTP endpoint, (1) It is 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.
   - Once we have a policy and update DNS, we need to make an HTTPS call to fetch policy - which is unavoidable.
   - Policy refresh: Policies are refreshed in the following two cases (1) max-age reached (2) Validation failures. Policy will be cached either - just before expiry or after expiry. 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). In the case of validation failures, we need to force a policy fetch to make sure we are using the latest policy. Relying on DNS alone is not safe because, policy would have changed, but not DNS record. In such cases the sender never knows until you update DNS. Chances of making mistakes are high because DNS and HTTP endpoints are administered by different teams or even different organizations. On top of that we have to deal with DNS TTLs as well.

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. In the case of initial discovery, we still use DNS to discover the existence of a policy for the recipient domain. I would say relying on DNS beyond initial discovery is unnecessary. 
The main benefit with DNS record lookup as part of mail delivery is the ability to discover a policy change much before the max-age (by polling DNS frequently). Yes this will avoid hammering HTTP endpoint. But do we need to worry about checking policy whenever we send emails? My opinion is that honoring max-age is good enough that upholds the policy contract between sender and recipient. Ideally the policy should be cached directly from HTTP endpoint at regular intervals. The refresh interval may range from couple of times a day to couple of times a week. If required, we can introduce an additional field ‘refresh interval’ in the policy. Apparently, senders discover a policy change almost instantaneously when the policy validation fails. However this will lead to 'thundering herd' problem -  a side effect of a forced refresh.
Rolling a new policy:Updating a policy leads to validation failures in sender’s side - that forces a policy refresh. There will a time (upto max-age) period where we expect to see reports based on both old and new policies. If a forced refresh fails, the sender may move mail to a retry queue and send it later in time (after max-age?).
(low priority) One way to handle this overlap is to publish the new policy upfront and distribute it in the same file. We also need to state that the new policy will be effective from a UTC date time onwards. That means we need to start supporting ‘not-before’ and ‘not-after’ date time fields that represents absolute date and time (in contrast to max-age).
As a side note, we also need to alert the sender when ever a sender discovers a change related policy such as :  (a) A policy change (b) Policy removal/policy not found, but previously cached (c) Discovery of new policy. This should be a separate report different from our regular violation report- basically to report control plane issues.
==
thanks,-binu

      From: Viktor Dukhovni <[email-masked]>
 To: [email-masked] 
 Sent: Thursday, 11 August 2016 4:17 PM
 Subject: Re: [Uta] review of mta-sts-01

-- 
    Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 12 Aug 2016 00:41:26 +0000

On Fri, Aug 12, 2016 at 12:02:18AM +0000, Binu Ramakrishnan wrote:

> 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: 
>    

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.

---

From: Mark Risher <[email-masked]>
Date: Thu, 11 Aug 2016 17:54:37 -0700

>> A more attractive design is to query the DNS signal on every delivery,
and either synchronously 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.

This sounds interesting. So in this model, would we eschew the "max-age" in
the policy itself and rely solely on updates to the DNS? This seems like
the best leverage of the existing DNS caching capabilities, the lightest
impact on the HTTPS end, and a simplification around synchronizing
policy+DNS changes.

> providers, while they figure out whether/when they can do DNSSEC?

I agree; I think after initial deployment, these policies are likely to be
unchanged for years for domains of all sizes, so if this simplification
holds up, the HTTPS load becomes truly minimal.

/m

--
Mark E. Risher |   [email-masked] |  650-253-3123

---

From: Binu Ramakrishnan <[email-masked]>
Date: Fri, 12 Aug 2016 00:54:33 +0000 (UTC)

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-masked]>
 To: [email-masked] 
 Sent: Thursday, 11 August 2016 5:41 PM
 Subject: Re: [Uta] review of mta-sts-01

-- 
    Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 11 Aug 2016 22:44:51 -0400

> On Aug 11, 2016, at 8:54 PM, Mark Risher <[email-masked]> wrote:
> 
> This sounds interesting. So in this model, would we eschew the "max-age" in the policy itself and rely solely on updates to the DNS? This seems like the best leverage of the existing DNS caching capabilities, the lightest impact on the HTTPS end, and a simplification around synchronizing policy+DNS changes.

That's a possibility.  The expiration of data from the cache might
then become local policy for flushing stale cache entires that have
not seen repeat access for a sufficiently long time.  For domains with
steady traffic, the cached entry might indeed be retained indefinitely,
if the DNS signal does not change.

If the DNS entry is deleted, the cache could be refreshed, and if
HTTPS still returns anything other than a 404, the cached <id>
would become "unset", and the policy would finally be subject
to expiration.

So one still retain max-age, but it would be measured not from
the time the policy was last cached, but rather from the oldest
of:

    * The last time a message was sent via that cached policy.
    * The last time a DNS TXT record was seen for the domain.

This would ensure that deletion of the DNS record does not cause
constant refreshes, but rather a single refresh that unsets the
<id> (except that an authenticated 404 does clear the cached policy).
And deletion of the DNS record does eventually cause the policy to
be refreshed if the record is not seen in the DNS for an interval
of at least max-age.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Fri, 12 Aug 2016 11:16:54 +0200

> just waits until the operator notices, a policy poll won't help.

To be clear, the incentive to force a check for a new policy (via DNS, not
HTTPS, in my preferred design) is to ensure that recipient domains can
safely update non-expired policies without worrying about breaking
delivery.

I think you knew that, but I wanted to call it out explicitly here.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 12 Aug 2016 15:24:54 +0000

> I think you knew that, but I wanted to call it out explicitly here.

I am all for doing the DNS-triggered policy refresh, likely on
every delivery since the answer will typically come from the DNS
cache.  I was commenting on refresh "on failure".  I am not convinced
this warrants the suggested refresh and retry logic.  I would just
queue the mail and wait for the remote operator to get his act
together and fix the problem:

    * Replaces expired certificates.
    * Ensures that the certificate chain contains all the required
      intermediates.
    * Makes sure that the private key and certificate are compatible.
    * Disables anti-spam proxies that block STARTTLS.

Delivery disruption that's due to stale policy is IMHO far less
likely to be the cause of problems, and so doing synchronous HTTPS
refresh and retry is I think too much complexity and latency for
too little gain.  I'd like to see that part of the suggested state
machine go away.

Incidentally, issue "72" on Github completely misses the boat on
extending the state machine to describe the behaviour for multiple
*receiving* MX hosts.  There's some needless discussion of cache
coherence (state sharing) among multiple sending hosts, but no
discussion of how the sender state machine interacts with multiple
remote MX hosts.

If you drop refresh on failure from the spec, the state machine
gets simpler, but you still need to describe the handling of multiple
MX hosts when only some don't match the "mx" policy, or only some
fail to establish TLS or produce a trusted certificate chain with
a matching host name.  Nor do you discuss which names are valid in
this context:

    * Just the MX hostname
    * Either the MX hostname *or* the nexthop domain name?
    * (Wholly impractical at scale) Just the nexthop domain name.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 16 Aug 2016 11:49:34 +0200

> too little gain.  I'd like to see that part of the suggested state

I don't think this is incompatible with what you say. Refreshing doesn't
have to be synchronous from the sending MTA's perspective; it just has to
happen before the message is perm-failed. Your suggested implementation
seems to be:

1. Temp fail the message.
2. Check for policy refreshes on every delivery.

That has the same properties as the "synchronous" implementation. So I
think we can change the language here, but I do think it's important that
perm failures are not generated from stale policies.

That said, if we check the DNS record on every send, stale policies run
very little chance of being the cause of failures since recipients are
unlikely to break their cached policies within the difference between
time-of-policy-check and time-of-delivery-attempt, so this may be
superfluous if we explicitly require a check of the TXT record before
delivery (which we don't right now).

So in short, I think we can either (or both) a) *require* a check of the
TXT record before send (totally reasonable) or b) require at least one
check before a perm fail.

> discussion of how the sender state machine interacts with multiple

Yes, I think that's a separate discussion. I think one of the points in
https://github.com/mrisher/smtp-sts/issues/85, but I haven't looked in
detail yet.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 16 Aug 2016 15:09:18 +0000

> 1. Temp fail the message.

IMNSHO, the draft should unequivocally recommend soft failure on
policy failure.  Presumably policy failure is in most cases a
transient condition, that the receiving domain will attempt to
remediate as soon as they become aware of it.  (Cue in-band
notification, :-)

> perm failures are not generated from stale policies.

See above, more generally, I would discourage perm failures on
policy failure.  Persistent policy failure will result in eventual
message expiration.  Many sending systems implement "delay warnings"
for internal senders, so that mail that's been in the queue for
some designated time results in a notice to the sender that their
mail is struggling to get through, and may indeed ultimately bounce.

> check before a perm fail.

I read the current draft to require an HTTPS policy check on failure
even when the DNS TXT record showed no change.  Perhaps I misunderstood.

I do think it makes sense to require a TXT record check on every
delivery, but mention that any consequent HTTPS policy fetch may
be asynchronous.

In the asynchronous case, the first few messages to a domain never
seen before, may be vulnerable to active attack.  As they are
anyway, since the TXT record could well have also been suppressed.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 31 Aug 2016 16:00:15 +0200

> MX hosts pass authentication.

Not to be stupid, but why eliminate hosts with a higher preference than the
matching MX? It seems like they would still be valid candidate MXes in the
failure case.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 31 Aug 2016 10:57:01 -0400

> On Aug 31, 2016, at 10:00 AM, Daniel Margolis <[email-masked]> wrote:
> 
> Not to be stupid, but why eliminate hosts with a higher preference than the matching MX? It seems like they would still be valid candidate MXes in the failure case.

Perhaps I was not sufficiently clear, I was suggesting removal
of MX hosts at a worse preference than any non-matching host.

On second thought it would be sufficient for hosts (as usual)
to first eliminate all MX entries at an equal or worse preference
to any entry that matches themselves (by name or address), and
only then check which (remaining) MX host comply with STS policy.

The goal is to ensure that no loops result if an MX host applies
the STS filter first, and fails to remove other hosts at an equal
or worse priority.

-- 
	Viktor.