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

[Mechiel Lukkien <[e-mail]>]

Hi all,

I'm implementing (outgoing) SMTP TLS reporting (RFC 8460) in my mail server (https://github.com/mjl-/mox) and am getting confused by TLSRPT's use of "domain"/"recipient domain"/"policy domain", especially related to DANE. It seems to me these concepts are getting mixed up.

Since TLSRPT is a companion document to MTA-STS, targeting MTA-STS has probably been its focus. MTA-STS specifies a policy for a recipient domain. But DANE policies are specified per mail hosts (typically MX target), not recipient domains. The terminology section about "policy domain" says:

   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.

Consider delivering a message to "[e-mail]". The recipient domain is "recipientdomain.example" (with an MTA-STS policy), an MX target could be "mx.recipientdomain.example" (the TLSA base domain with a DANE policy). Given the terminology section, I would think this would find a policy-typ "sts" at policy-domain "recipientdomain.example", and a policy-type "tlsa" at policy-domain "mx.recipientdomain.example". Since the terminology section for Policy Domain (above) says TLSRPT is defined against a policy domain, that means the operator of mx.recipientdomain.example should create a TLSRPT record at _smtp._tls.mx.recipientdomain.example to receive DANE-related TLS reports (along with one at _smtp._tls.recipientdomain.example for sts). 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. And that's also how my initial prototype implemented it, with TLSA results gathered into a report for the recipient domain. When I thought I was done implementing (after struggling with merging the various "sts", "tlsa" and "no-policy-found" results), and reading the RFC again, I found the terminology of "policy domain" (which feels like the correct approach to me) and changed the implementation to match its conceptual explanation. 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. 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.

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.

Below are some references to specific lines in the RFC related to policy/recipient domains. The RFC  is cross-referenced with the implementation, sometimes with todo-annotations. Aside: Is there a way to link to specific lines of an RFC at the datatracker or rfc-editor.org? I haven't found it yet.

Mentioning recipient domains in "Abstract": https://www.xmox.nl/xr/dev/rfc/8460.html#L29

   This document
   describes a reporting mechanism and format by which sending systems
   can share statistics and specific information about potential
   failures with recipient domains.

This says the recipient domain "uses" DANE in "Introduction": https://www.xmox.nl/xr/dev/rfc/8460.html#L193

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

SMTP TLSRPT describes itself as sending reports to recipient domains, in "Related Technologies": https://www.xmox.nl/xr/dev/rfc/8460.html#L268

   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.

Domain and policy domain in "Reporting policy", not recipient domain: https://www.xmox.nl/xr/dev/rfc/8460.html#L289

   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 [...]

Talking about recipient domain instead of policy domain in "Reporting policy": https://www.xmox.nl/xr/dev/rfc/8460.html#L378

   If the number of resulting records is not one, senders MUST assume
   the recipient domain does not implement TLSRPT.

The following may be talking about a recipient domain with an MX target equal to the recipient domain (or no MX record at all), in "Reporting schema": https://www.xmox.nl/xr/dev/rfc/8460.html#L462

   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
   case where only a single policy was applied, the "policies" field of
   the report body MUST be an array and not a singular value.

The "policy-domain" field should be the domain the policy is defined against. I would say that's the MX target with the TLSA record for DANE. In "JSON Report Schema": https://www.xmox.nl/xr/dev/rfc/8460.html#L704

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

Some more notes/feedback I wrote down while implementing:

- Implementors need to carefully handle combinations of sts vs no-sts and tlsa vs no-tlsa, and possibly combine those into a no-policy-found result. MTA-STS and DANE aren't mutually exclusive. What about just having policy results "no-sts" and "no-tlsa"? Seems more explicit to me and is easier to implement. There can also be cases where only some MX targets of a recipient domain have a DANE policy.
- Since detecting injected MX targets is one of the goals of MTA-STS, I would expect a specific result type for when an MX target does not match the policy, but it seems missing. I think "certificate-host-mismatch" (https://www.xmox.nl/xr/dev/rfc/8460.html#L541) is about the TLS connection and certificate (a TLS connection will not be made when a MX target doesn't match the policy). Similarly, a result type for "none of the TLSA records match" seem like a relatively likely failure case and could have its own result type.
- I think more fields in the failure details should be optional. SMTP IPs and/or MX hostnames aren't always in play, e.g. when reporting on MTA-STS policy fetch/parse or TLSA lookup failures. While the RFC is called "SMTP TLS reporting", it is also reporting about MTA-STS and DANE policies without TLS involved yet.
- A "TLS-Required: No" header from the Require TLS RFC can cause a verification failure to be ignored. I think it's still useful to report failure details, but the connection would succeed. How this case should be reported could be up for discussion.
- I don't submit TLS reports to HTTPS reporting addresses because I don't see a way the receiver can authenticate and use them. Report messages must have a DKIM signature (I'm sending it with d= exact/strict host name, but accept domains up to the public suffix domain for incoming reports, I think the RFC requires the exact match). But reports submitted over HTTPS seem to be just the JSON (optionally with gzip). Submitting a report _message_ over HTTPS, with DKIM signature, could solve the problem. I think the RFC could be stricter with its use of "report" (the JSON document) vs "report message" (email message with a report as attachment).

Cheers,
Mechiel