Re: [Uta] SMTP TLS reporting (RFC 8460), policy domains and DANE

[Mechiel Lukkien <[e-mail]>]

Hi Alex & Viktor,

Thanks for you responses, much appreciated. It seems to me like you have somewhat different views. If I'm interpreting your responses correctly, Alex is saying the reports are only about/to recipient domain (including with DANE), and Viktor is saying the reports could be sent for MX targets (possibly with external operator) with their own DANE and TLSRPT policies. From a high-level view, I'm seeing mentioning of "recipient domain" in the initial sections of the RFC (Abstract, Introduction), but pointers to per MX target TLSRPT policies in the details of the RFC. Comments below, followed by ideas for errata.

Alex wrote:
> TLSRPT is going to look for its information at _smtp._tls.<rcpt domain>.  That same <rcpt domain> should  be the policy-domain in the report.  The domain for the MTA-STS/DANE policies may be different such as you mentioned with DANE.  The MX for foo.com could point at mx.example.net.  The TLSRPT will look for policy at _smtp._tls.foo.com, but DANE will look at _25._tcp.mx.example.net.

If TLSRPT would only be about the recipient domain, why would the term "Policy Domain" (with capitals, so referring to the definition in the Terminology) be used in some places in the RFC, like:

   A domain publishes a record to its DNS indicating that it wishes to
   receive reports.  These SMTP TLSRPT policies are distributed via DNS
   from the Policy Domain's zone as TXT records [...]

If the goal is to always evaluate that to "recipient domain", there would be no need for the indirection through "Policy Domain". As a reader, that makes me think an author is using the indirection to make it variable based on the DANE or MTA-STS context.

About the "policy-domain" field in the report, the RFC says:

   o  "domain": The Policy Domain against which the MTA-STS or DANE
      policy is defined. [...]

One could interpret "Policy Domain" above as the "recipient domain" also for DANE in light of the following (but again, if that's the goal, why not just say "recipient domain"?):

   Recipient domains may also use the mechanisms defined by MTA-STS
   [RFC8461] or DANE [RFC6698] to publish additional encryption and
   authentication requirements;

But Terminology for "Policy Domain" specifies the DANE policy domain as the TLSA base domain, e.g. mx1.example.net. And I believe that's how a DANE implementer will interpret it.
"policy-domain" being in each policy result instead of at the top-level JSON document also hints that it can have different values within a report.

However, it may be more useful to indeed set "policy-domain" to the recipient domain: Assuming we have both (recipient) domain owners, and (possibly 3rd party) MX operators that want to receive TLS reports. An MX operator (that hosts potentially many recipient domains) would probably be interested in the recipient domain that is affected by TLS/policy failures. If the policy-domain would be set to the DANE Policy Domain (i.e. TLSA base domain, likely the MX target), the MX operator has no way to learn the recipient domain. For DANE policies, "mx-host" could be set to the TLSA base domain. That would allow a DANE operator to learn both affected recipient domains and the MX host that was involved (also in the case of success reports). RFC 8460 does not specify an expected value for the "mx-host" field in the case of "tlsa" (but only for "sts"), and the one "tlsa" policy I received from Microsoft doesn't have a value for "mx-host".

I do also see how it would be useful for recipient domain owners to receive TLS reports about success/failures of TLS connections to (3rd party) MX operators for their domains, regardless of TLSRPT policy presence for the MX target.

Viktor wrote:
> Just failure reports?  Or also success reports in the absence of any
> failures?

I'm also sending success reports, and have been receiving them. The RFC mentions this as a useful way to send a "heartbeat" signal that all is well. The reports I'm getting are almost all about successful connections, which indeed is good to know.

> >    o  Policy Domain: The domain against which a TLSRPT, an MTA-STS, or a
> >       DANE policy is defined.  For TLSRPT and MTA-STS, this is typically
> >       the same as the envelope recipient domain [RFC5321], but when mail
> >       is routed to a "smarthost" gateway by local policy, the
> >       "smarthost" domain name is used instead.  For DANE, the Policy
> >       Domain is the "TLSA base domain" of the receiving SMTP server as
> >       described in Section 2.2.3 of RFC 7672 and Section 3 of RFC 6698.
> 
> This is clear to me, the *policy* domain is the one that vends the
> policy data, and that (in the form of TLSA records) is the TLSA "base
> domain" (TLSA query name, less the "_port._protocol" attleaf labels).

I think my confusion is because "Policy Domain" (with capitals) is used in the RFC, which could be interpreted as either "TLSRPT Policy Domain" (i.e. recipient domain), or "Policy Domain in the context of MTA-STS or DANE" (either recipient domain or TLSA base domain). From my point of view there would be no point in using an indirection through "Policy Domain" if the intention for it is to always evaluate to "recipient domain".

> > That approach seems reasonable to me, but most of the RFC seems
> > written with the idea that only a recipient domain would have a TLSRPT
> > record/policy.
> 
> Whoever manages the policy should receive the reports.  If DANE MTA
> operators want to receive TLSRPT data, indeed they should publish
> the relevant records for each of the MX hosts.

Indeed this is what I would expect as a DANE implementer. Reports will be useful to (3rd party) MX operators. This concept of 3rd party operators specifying 1 policy that applies to many recipient domains became clear to me from reading the DANE RFCs. But if I'm understanding Alex correctly, he wouldn't expect this. By the way, even without DANE it would be useful for 3rd party MX operators to receive TLS reports (e.g. about TLS protocol version mismatch). So I would think any mail host (MX target) could benefit from a TLSRPT record, if only to receive reporting about deliveries to postmaster@<host>.

> It is also possible for the recipient domain to configure "_smtp._tls"
> TXT records, and if there's no reporting address for the affected MX
> host, it is reasonable to fall back to the recipient domain as a
> potential report destination.  So nobody will fault you for considering
> both.

Yes, this seems like a pragmatic approach. Though I can also see how (recipient) domain owners would want to receive all TLS results that affect their domains. I can send the TLSA results to both the TLSRPT for the MX host and the recipient domain. Better to overreport some numbers than underreport.

> > I haven't had a per-mailhost TLSRPT DNS record for long
> > on my mail host, but haven't received a TLS report for it.
> 
> DANE TLSRPT support for Postfix is under development at sys4.de I hear,
> so some day you might see a report, but perhaps only if there's
> something broken on your end.  If your domain is workign normally, I
> would not expect success reports.

More DANE TLSRPT implementations would be nice. I've been receiving TLS reports mostly from just a few providers. I think/thought it is because implementations aren't too common. But other implementations may indeed only be reporting failures. Are there known implementations with failure-only TLS reporting?

> > I've only received 1 TLSRPT with a "tlsa" policy so far (along with
> > the specified "sts" policy), from Microsoft, and it lists my recipient
> > domain as the tlsa "policy-domain" (not the mx target which has the
> > policy), so it seems they have an interpretation similar to what I
> > initially had.
> 
> Or the sending MTA is not DANE enabled, or the implementation of TLSRPT
> is presently only targetted at MTA-STS.

Good point. Policy-type's like "sts-unimplemented" and "tlsa-unimplemented" would have helped make that explicit. But maybe some operators aren't comfortable announcing they are not applying some security mechanisms.

> > I'm left wondering what the correct and/or intended interpration is
> > for recipient/policy domain, whether mail hosts should have their own
> > TLSRPT policy DNS record, and what the expected "policy-domain" values
> > are in TLS reports.
> 
> An operator of a multi-tenant MTA who publishes DANE TLSA records, and
> is interested in external reports of delivery issues to augment their
> own (naturally comprehensive and robust) monitoring should publish
> per MX host TXT records.  Since this is not a task that should fall
> on each hosted recipient domain.
> 
> A recipient domain that manages its own MX hosts, or wants to hear
> about delivery issues via their provider, might also publish a TLSRPT
> DNS record.  A report sender might notify both if both are published
> and specify different notification endpoints.

Yes, this seems like a useful pragmatic interpretation.

> The set of defined error conditions is not necessarily exhaustive,
> if, while implementing, you think of compelling additions, propose
> additional entires for the IANA registry.

What would the procedure be? A new RFC? I'm assuming I cannot just submit new values...

> > - A "TLS-Required: No" header from the Require TLS RFC can cause a
> > verification failure to be ignored.
> 
> And even the policy to not be queried or evaluated, so the "failure"
> might not even be observed, and would only have been a "failure" without
> the override.
> 
> > I think it's still useful to report failure details, but the
> > connection would succeed.
> 
> Perhaps, if the "failure" is observed, but ignored, though if mail
> delivery is successful, I'd be inclined to not report a problem.  Let
> the deliveries that actually enforce the policy provide the signal.  If
> there are none, then in some sense there's no immediate problem.

I would think it's better to overreport the failure, than underreport it. I see "TLS-Required: No" more as a workaround for connectivity problems (which should be solved), so the higher the "failures" count, the more likely an operator may take the problem seriously. By working around the issue, and not reporting failures anymore, an operator may think issues have resolved themselves.


Hopefully we can get agreement on the interpretation. I have two options for errata (hopefully not too intrusive to qualify...):

Option 1: Clarify as the per-MX TLSRPT interpretation (my latest interpretation, which seems helpful for external MX operators):

- Change some uses between "recipient domain", "Policy domain" or just "domain".
- Change report field "policy-domain" to be the recipient domain. Likewise for header field TLS-Report-Domain.
- Change report field "mx-host" to contain the destination hostname (typically the MX target) for policy-types "tlsa" and "no-policy-found".
- Mention explicitly that mail hosts (MX targets) can have their own TLSRPT records. Also mention that a report can contain multiple TLSA policy results (for multiple MX targets, which is already the case in either interpretation, just made explicit).
- Mention explicitly that reports must be sent to TLSRPT policies at both recipient domains at MX targets. Perhaps either could become "should" instead of "must.

Option 2: Clarify as the per-recipient domain-only TLSRPT interpretation (my initial interpretation):
- Replace most occurrences of "Policy Domain" with "recipient domain".

My goal is to have an interoperable implementation and to prevent confusion for future implementers. I don't think either interpretation would cause trouble for the other. Worst case, some TLS reports are not sent. But TLS reporting is already optional.
Below are two diffs against the RFC for the two options. Option 1 is a bit more verbose with examples to reduce chances of implementer confusion.

Cheers,
Mechiel


--- 8460.txt	2023-11-17 18:10:33.457357947 +0100
+++ 8460-option1.txt	2023-11-17 19:53:13.415702599 +0100
@@ -29,7 +29,7 @@
    delivery over unencrypted or unauthenticated channels.  This document
    describes a reporting mechanism and format by which sending systems
    can share statistics and specific information about potential
-   failures with recipient domains.  Recipient domains can then use this
+   failures with domains.  Domains can then use this
    information to both detect potential attacks and diagnose
    unintentional misconfigurations.
 
@@ -190,16 +190,16 @@
    to report on failures at multiple stages of the MTA-to-MTA
    conversation.
 
-   Recipient domains may also use the mechanisms defined by MTA-STS
+   Domains may also use the mechanisms defined by MTA-STS
    [RFC8461] or DANE [RFC6698] to publish additional encryption and
    authentication requirements; this document defines a mechanism for
    sending domains that are compatible with MTA-STS or DANE to share
-   success and failure statistics with recipient domains.
+   success and failure statistics with domains.
 
    Specifically, this document defines a reporting schema that covers
    failures in routing, DNS resolution, and STARTTLS negotiation; policy
    validation errors for both DANE [RFC6698] and MTA-STS [RFC8461]; and
-   a standard TXT record that recipient domains can use to indicate
+   a standard TXT record that domains can use to indicate
    where reports in this format should be sent.  The report can also
    serve as a heartbeat to indicate that systems are successfully
    negotiating TLS during sessions as expected.
@@ -267,7 +267,7 @@
 
    o  SMTP TLSRPT defines a mechanism for sending domains that are
       compatible with MTA-STS or DANE to share success and failure
-      statistics with recipient domains.  DANE is defined in [RFC6698],
+      statistics with domains.  DANE is defined in [RFC6698],
       and MTA-STS is defined in [RFC8461].
 
 
@@ -292,7 +292,11 @@
    Message Authentication, Reporting, and Conformance (DMARC) policies)
    under the name "_smtp._tls".  For example, for the Policy Domain
    "example.com", the recipient's TLSRPT policy can be retrieved from
-   "_smtp._tls.example.com".
+   "_smtp._tls.example.com". For the Policy Domain mx1.example.com,
+   the TLSRPT policy can be retrieved from "_smtp._tls.mx1.example.com".
+   TLS reports about an MX target MUST be reported through the TLSRPT
+   policy at the recipient domain if present, and MUST be reported
+   through the TLSRPT policy of the MX target if present.
 
    Policies consist of the following directives:
 
@@ -375,7 +379,7 @@
    If multiple TXT records for "_smtp._tls" are returned by the
    resolver, records that do not begin with "v=TLSRPTv1;" are discarded.
    If the number of resulting records is not one, senders MUST assume
-   the recipient domain does not implement TLSRPT.  If the resulting TXT
+   the Policy Domain does not implement TLSRPT.  If the resulting TXT
    record contains multiple strings (as described in Section 3.3 of
    [RFC7208]), then the record MUST be treated as if those strings are
    concatenated without adding spaces.
@@ -440,7 +444,7 @@
          a semicolon), and (3) the literal string "no-policy-found", if
          neither a DANE nor MTA-STS Policy could be found.
 
-      *  The domain for which the policy is applied
+      *  The TLSRPT Policy Domain, i.e. recipient domain, for which the policy is applied
 
       *  The MX host
 
@@ -460,8 +464,10 @@
    Note that the failure types are non-exclusive; an aggregate report
    may contain overlapping "counts" of failure types when a single send
    attempt encountered multiple errors.  Reporters may report multiple
-   applied policies (for example, an MTA-STS Policy and a DANE TLSA
-   record for the same domain and MX).  Because of this, even in the
+   applied policies (for example, an MTA-STS Policy and a DANE policy
+   with one or more TLSA records for the same domain and MX, or multiple
+   DANE policies each with multiple TLSA records for a recipient domain
+   with multiple MX targets).  Because of this, even in the
    case where only a single policy was applied, the "policies" field of
    the report body MUST be an array and not a singular value.
 
@@ -701,8 +707,8 @@
       of strings, whether it's a TLSA record ([RFC6698], Section 2.3) or
       an MTA-STS Policy.  Examples follow in the next section.
 
-   o  "domain": The Policy Domain against which the MTA-STS or DANE
-      policy is defined.  In the case of Internationalized Domain Names
+   o  "domain": The TSLRPT Policy Pomain, i.e. recipient domain.
+      In the case of Internationalized Domain Names
       [RFC5891], the domain MUST consist of the Punycode-encoded
       A-labels [RFC3492] and not the U-labels.
 
@@ -713,6 +719,8 @@
       [RFC8461].  In the case of Internationalized Domain Names
       [RFC5891], the domain MUST consist of the Punycode-encoded
       A-labels [RFC3492] and not the U-labels.
+      If "policy-type" is "tlsa" or "no-policy-found", it is the hostname
+      to deliver to, typically an MX target.
 
    o  "result-type": A value from Section 4.3, "Result Types", above.
 
@@ -969,7 +977,7 @@
                         [CFWS]                       ; per [RFC5322]
                                                      ; (as with FWS)
 
-   The first domain-name indicates the DNS domain name about which the
+   The first domain-name indicates the recipient DNS domain name about which the
    report was generated.  The second domain-name indicates the DNS
    domain name representing the Sending MTA generating the report.  The
    purpose of the "Report-ID:" portion of the field is to enable the



--- 8460.txt	2023-11-17 18:10:33.457357947 +0100
+++ 8460-option2.txt	2023-11-17 18:53:18.514183249 +0100
@@ -286,11 +286,11 @@
 
 3.  Reporting Policy
 
-   A domain publishes a record to its DNS indicating that it wishes to
+   A recipient domain publishes a record to its DNS indicating that it wishes to
    receive reports.  These SMTP TLSRPT policies are distributed via DNS
-   from the Policy Domain's zone as TXT records (similar to Domain-based
+   from the recipient domain's zone as TXT records (similar to Domain-based
    Message Authentication, Reporting, and Conformance (DMARC) policies)
-   under the name "_smtp._tls".  For example, for the Policy Domain
+   under the name "_smtp._tls".  For example, for the recipient domain
    "example.com", the recipient's TLSRPT policy can be retrieved from
    "_smtp._tls.example.com".
 
@@ -304,7 +304,7 @@
       information about policy validation results should be sent (see
       Section 4, "Reporting Schema", for more information).  Two URI
       schemes are supported: "mailto" and "https".  As with DMARC
-      [RFC7489], the Policy Domain can specify a comma-separated list of
+      [RFC7489], the recipient domain can specify a comma-separated list of
       URIs.
 
    o  In the case of "https", reports should be submitted via POST
@@ -440,7 +440,7 @@
          a semicolon), and (3) the literal string "no-policy-found", if
          neither a DANE nor MTA-STS Policy could be found.
 
-      *  The domain for which the policy is applied
+      *  The recpient domain for which the policy is applied
 
       *  The MX host
 
@@ -486,15 +486,15 @@
             return rand
           }
 
-          func generate_report(policy_domain) {
-            do_rpt_work(policy_domain)
-            send_rpt(policy_domain)
+          func generate_report(recipient_domain) {
+            do_rpt_work(recipient_domain)
+            send_rpt(recipient_domain)
           }
 
           func generate_tlsrpt() {
             sleep(generate_sleep_delay())
-            for policy_domain in list_of_tlsrpt_enabled_domains {
-              generate_report(policy_domain)
+            for recipient_domain in list_of_tlsrpt_enabled_domains {
+              generate_report(recipient_domain)
             }
           }
 
@@ -701,7 +701,7 @@
       of strings, whether it's a TLSA record ([RFC6698], Section 2.3) or
       an MTA-STS Policy.  Examples follow in the next section.
 
-   o  "domain": The Policy Domain against which the MTA-STS or DANE
+   o  "domain": The recipient domain against which the TLSRPT
       policy is defined.  In the case of Internationalized Domain Names
       [RFC5891], the domain MUST consist of the Punycode-encoded
       A-labels [RFC3492] and not the U-labels.
@@ -886,8 +886,8 @@
 
    "unique-id" allows an optional unique ID generated by the Sending MTA
    to distinguish among multiple reports generated simultaneously by
-   different sources for the same Policy Domain.  For example, this is a
-   possible filename for a compressed report to the Policy Domain
+   different sources for the same recipient domain.  For example, this is a
+   possible filename for a compressed report to the recipient domain
    "example.net" from the Sending MTA "mail.sndr.example.com":
 
    "mail.sndr.example.com!example.net!1470013207!1470186007!001.json.gz"
@@ -969,15 +969,15 @@
                         [CFWS]                       ; per [RFC5322]
                                                      ; (as with FWS)
 
-   The first domain-name indicates the DNS domain name about which the
+   The first domain-name indicates the recipient DNS domain name about which the
    report was generated.  The second domain-name indicates the DNS
    domain name representing the Sending MTA generating the report.  The
    purpose of the "Report-ID:" portion of the field is to enable the
-   Policy Domain to identify and ignore duplicate reports that might be
+   recipient domain to identify and ignore duplicate reports that might be
    sent by a Sending MTA.
 
    For instance, this is a possible Subject field for a report to the
-   Policy Domain "example.net" from the Sending MTA
+   recipient domain "example.net" from the Sending MTA
    "mail.sender.example.com".  It is line-wrapped as allowed by
    [RFC5322]:
 
@@ -1461,9 +1461,9 @@
 
 
    o  Reports as DDoS: TLSRPT allows specifying destinations for the
-      reports that are outside the authority of the Policy Domain, which
+      reports that are outside the authority of the recipient domain, which
       allows domains to delegate processing of reports to a partner
-      organization.  However, an attacker who controls the Policy Domain
+      organization.  However, an attacker who controls the recipient domain
       DNS could also use this mechanism to direct the reports to an
       unwitting victim, flooding that victim with excessive reports.
       DMARC [RFC7489] defines a solution for verifying delegation to