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

[Viktor Dukhovni <[e-mail]>]

On Fri, Nov 17, 2023 at 09:11:40PM +0100, Mechiel Lukkien wrote:

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

Since DANE policy is managed by the email provider, and not the hosted
domain, one should expect to find any TLSRPT endpoints listed for
the MX hostname(s), with the MX operator being the primary responsible
party for monitoring for an resolving any issues.

If the (MX) hosted customer domain operator is also interested in
receiving TLSRPT messages, they could I guess also publish a suitable
TXT record, and you might then notify either or both the customer
and the service provided, deduplicating reporting endpoints, since
some self-hosted sites may list the same endpoints for both.

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

Go with the spirit, rather than the letter of the RFC.  The goal is to
provide information to operators about observed failures, where
"operators" means primarily those in a position to respond to any issue.

Doing TLSRPT with MTA-STS when email is hosted by a provider in practice
requires each customer domain to proxy or delegate the
"mta-sts.<domain>" HTTPS service to the provider's service endpoint and
to CNAME the TXT record to the provider's TLSRPT TXT record.

With DANE, both problems go away.

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

Notify both (after endpoint deduplication) when both are published.

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

I would prefer to not receive success report noise.  IIRC the TLSRPT
DNS record does not have a field to indicate that success reports are
not desired.  Software implementing TLSRPT should IMHO default to not
sending success reports, and have that be a feature that the (sending)
MTA operator has to turn on explicitly.

Ideally, it should also allow receiving domains to ask to opt-out of
success reports, and so the software should also support exclusion
lists for this case.

> > 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.
> 
> But if I'm understanding Alex correctly, he wouldn't expect this.

Do the *right* thing, regardless of what Alex, I, or the RFC might say,
defaulting to following the RFC when it is close-enough to the right
thing, but RFCs are not always clear and not always in hindsight
correct, so deviations or elaborations are sometimes necessary.

There is no RFC police.

> 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 am not following the space closely enough (or at all) to give you a
useful answer.

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

Some IANA registries are subject to expert review, and don't require
"standards action".  You when need just an informational RFC through the
ISE, so that others can find a stable reference for the code point.

Check the registry policy.  Of course if you want the new code point
to see wide use, a short standards-action RFC through the UTA or
other suitable WG may be best.

> I would think it's better to overreport the failure, than underreport
> it.

There's already too much email.  More junk is not helpful.  And
automated email sometimes results in mail delivery loops, reports about
reports, ...  So I rather differ with you on "overreporting".

When there's a problem, hearing about it once is good, hearing about
it from everyone is at least distracting.

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

What you're proposing is likely too large for errata.  It would a new
"Clarifications" RFC, or, if sufficiently large, a "bis" RFC that
rewrites and obsoletes the original.

-- 
    Viktor.