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

[Viktor Dukhovni <[e-mail]>]

On Tue, Nov 14, 2023 at 03:39:21PM +0100, Mechiel Lukkien wrote:

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

Just failure reports?  Or also success reports in the absence of any
failures?

>    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).

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

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.

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

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

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

> - There can also be cases where only some MX targets of a recipient
> domain have a DANE policy.

Sure, and reports would go to the relevant operator when there's a
problem.

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

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.

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

Of course not all the senders that are failing will have TLSRPT support,
and perhaps only the bleeding edge server that also supports REQUIRETLS
is capable of TLSRPT as well, so the argument could go either way.

On Thu, Nov 16, 2023 at 01:59:16PM +0000, Brotman, Alex wrote:

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

Small correction, the TLS policy domain is the TLSA "base domain",
i.e. without the "_25._tcp" attrleaf labels.

-- 
    Viktor.