On Sun, May 08, 2016 at 10:24:37AM -0700, Daniel Margolis wrote:
> It sounds to me from the tail end of this thread that the main argument
> here is contrasting out of band reporting (via HTTP) with SMTP-based
> reporting in a separate message and in-band reporting via some SMTP status
> indicator. Is that right?
Yes, I'm advocating for simple in-band signalling as one of the
mechanisms that should probably be supported. This won't carry
very detailed information, but will be timely and will be seen by
the *actual* MX host that is misconfigured.
With MX hosts on anycast addresses, behind load-balancers or both,
the client will often not be able to accurately identify which
actual host it was talking to in out-of-band reports.
> - HTTP
> pro: works with hosted mail, works with outsourcing reporting (a la
> dmarcian), works even if the only MX for a domain is down
Right, though if the only MX host is down, one has a bigger problem
than TLS authentication. Presumably the site's operators are
working to fix that.
> - SMTP-separate-message
> pro: similar to DMARC, can be outsourced, requires no new infrastructure
> con: requires senders to not validate STS/DANE or requires recipients to
> have a different dedicated domain/outsourced recipient; potentially fails
> in the same way as the original message
Right, and may cause a flood of notices to a single address, creating
congestion (processing and/or storage bottleneck). Naive designs
that "pipe" the notices to a script or append them to a mailbox
can easily fail to scale.
> - SMTP-in-band
> pro: doesn't require aggregation, allows indication at a fine granularity
> ("this transaction failed"), no extra infrastructure required
Though it does require (as noted up-thread) an upgraded MTA that supports
the proposed feature.
> con: doesn't provide aggregation, in-band means if the MX is really
> misconfigured or the sender never talks to the right MX there's no way to
> get reports across
The assumption is that the MX host in question will report the
alerts to the administrator, performing reasonable aggregation when
alerts arrive quickly. This can be as simple a cronjob that looks
at the last 10 minutes of logs and sends a report if some threshold
is met. A daily report can be sent to summarize any missed events
below the threshold.
> These don't strike me as mutually exclusive. Having an in-band indicator of
> why the sender terminated the connection (like "STARTTLS wasn't supported
> and I require it") seems useful. Having out-of-band aggregation also seems
> very useful.
Definitely not mutually exclusive. The case I'm trying to make is
that the initial operational priority is timely notification of
misconfiguration (expired, untrusted or wrong name certs).
> In particular, one of the methods by which we would hope an *intermittent
> MITM* would be revealed is that reports of the occasional STARTTLS failure
> would indicate exactly this. If reports can only be sent *during the MITM
> to the MITM'ed MX*, this property is lost, is it not?
That depends on what the MITM does of course, but yes an MITM may
be able to suppress the in-band reports. The purpose of the in-band
reports is to maintain the health of the ecosystem against operator
error, not MiTM attack. I believe this is a pre-requisite for
broad deployment of authenticated SMTP transport. Once we are able
to reach broad deployment we can then think about doing more, like
reporting potential MiTM sightings.
> So I believe we need to keep some method for aggregate reporting; I don't,
> however, think the option for aggregate reporting precludes more verbose
> in-band indicators of why a connection is terminated.
Indeed neither precludes the other. Both have their place, and
some sites might elect to not solicit the aggregate reports, while
others might not implement the in-band mechanism (though they really
should, if they care about the reliability of their inbound mail
flow).
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
