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

Mechiel,

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.

-- 
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -----Original Message-----
> From: Uta <uta-bounces@ietf.org> On Behalf Of Mechiel Lukkien
> Sent: Tuesday, November 14, 2023 9:39 AM
> To: uta@ietf.org
> Subject: [Uta] SMTP TLS reporting (RFC 8460), policy domains and DANE
> 
> Hi all,
> 
> I'm implementing (outgoing) SMTP TLS reporting (RFC 8460) in my mail server
> (https://urldefense.com/v3/__https://github.com/mjl-
> /mox__;!!CQl3mcHX2A!D9Xu1BLWleyttI4TKEApW7sBSYzIfWJXnKC9vokcSZ4u
> XVYoL2HXiO0qvrZG0g8RwCGcIqNor_UY3c1kfSAv8a2QOOTA9F1juWS_PVpu$
> ) 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 "user@recipientdomain.example". 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://urldefense.com/v3/__https://www.xmox.nl/xr/dev/rfc/8460.html*L2
> 9__;Iw!!CQl3mcHX2A!D9Xu1BLWleyttI4TKEApW7sBSYzIfWJXnKC9vokcSZ4uX
> VYoL2HXiO0qvrZG0g8RwCGcIqNor_UY3c1kfSAv8a2QOOTA9F1jucfWS7K2$
> 
>    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://urldefense.com/v3/__https://www.xmox.nl/xr/dev/rfc/8460.html*L1
> 93__;Iw!!CQl3mcHX2A!D9Xu1BLWleyttI4TKEApW7sBSYzIfWJXnKC9vokcSZ4u
> XVYoL2HXiO0qvrZG0g8RwCGcIqNor_UY3c1kfSAv8a2QOOTA9F1jubyCcHZ5$
> 
>    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://urldefense.com/v3/__https://www.xmox.nl/xr/dev/rfc/8460.html*L2
> 68__;Iw!!CQl3mcHX2A!D9Xu1BLWleyttI4TKEApW7sBSYzIfWJXnKC9vokcSZ4u
> XVYoL2HXiO0qvrZG0g8RwCGcIqNor_UY3c1kfSAv8a2QOOTA9F1juV85luFC$
> 
>    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://urldefense.com/v3/__https://www.xmox.nl/xr/dev/rfc/8460.html*L2
> 89__;Iw!!CQl3mcHX2A!D9Xu1BLWleyttI4TKEApW7sBSYzIfWJXnKC9vokcSZ4u
> XVYoL2HXiO0qvrZG0g8RwCGcIqNor_UY3c1kfSAv8a2QOOTA9F1juXE1NEK9$
> 
>    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://urldefense.com/v3/__https://www.xmox.nl/xr/dev/rfc/8460.html*L3
> 78__;Iw!!CQl3mcHX2A!D9Xu1BLWleyttI4TKEApW7sBSYzIfWJXnKC9vokcSZ4u
> XVYoL2HXiO0qvrZG0g8RwCGcIqNor_UY3c1kfSAv8a2QOOTA9F1jueD9M9mL
> $
> 
>    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://urldefense.com/v3/__https://www.xmox.nl/xr/dev/rfc/8460.html*L4
> 62__;Iw!!CQl3mcHX2A!D9Xu1BLWleyttI4TKEApW7sBSYzIfWJXnKC9vokcSZ4u
> XVYoL2HXiO0qvrZG0g8RwCGcIqNor_UY3c1kfSAv8a2QOOTA9F1juQF7_ebn$
> 
>    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://urldefense.com/v3/__https://www.xmox.nl/xr/dev/rfc/8460.html*L7
> 04__;Iw!!CQl3mcHX2A!D9Xu1BLWleyttI4TKEApW7sBSYzIfWJXnKC9vokcSZ4u
> XVYoL2HXiO0qvrZG0g8RwCGcIqNor_UY3c1kfSAv8a2QOOTA9F1juVlgzThd$
> 
>    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://urldefense.com/v3/__https://www.xmox.nl/xr/dev/rfc/8460.html*L
> 541__;Iw!!CQl3mcHX2A!D9Xu1BLWleyttI4TKEApW7sBSYzIfWJXnKC9vokcSZ4
> uXVYoL2HXiO0qvrZG0g8RwCGcIqNor_UY3c1kfSAv8a2QOOTA9F1jucKTnjK1$
> ) 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
> 
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/uta__;!!
> CQl3mcHX2A!D9Xu1BLWleyttI4TKEApW7sBSYzIfWJXnKC9vokcSZ4uXVYoL2H
> XiO0qvrZG0g8RwCGcIqNor_UY3c1kfSAv8a2QOOTA9F1juR-QrKQn$