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.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
