Re: [Uta] reporting, was CBOR, XML, JSON (was Re: Updated SMTP STS Draft)

[Daniel Margolis <[e-mail]>]

Sorry, everyone. I've been out of the office the last few days on holiday
and haven't had a chance to catch up on the whole thread.

Regarding big providers' ability to monitor for misconfigurations, I think
we should not assume they will always catch errors. Especially in the early
stages of deployment, as Viktor noted, a small percentage of dropped mail
could go unnoticed, so having a means to accurately report failures and
their causes strikes me as valuable to everyone. Anyway, I'm not really
seeing an argument that only certain classes of mail hosts would benefit
from this, and of course that's not anyone's goal.

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?

If so, can I guess at the pros and cons (non-exausively) as something like:

- HTTP
pro: works with hosted mail, works with outsourcing reporting (a la
dmarcian), works even if the only MX for a domain is down
con: requires a separate HTTP endpoint (that can handle POST or PUT, which
is more than STS requires)

- 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

- SMTP-in-band
pro: doesn't require aggregation, allows indication at a fine granularity
("this transaction failed"), no extra infrastructure required
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

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.

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?

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.

(I will sit down and read the rest of the thread in the next day or two, so
if I've missed something, please be patient.)

Dan


On Fri, May 6, 2016 at 6:43 PM, Viktor Dukhovni <[e-mail]>
wrote:

> On Sat, May 07, 2016 at 01:08:44AM -0000, John Levine wrote:
>
> > > It is the long tail of much smaller domains where SMTP transport
> security needs
> > > an effective alerting channel.
> >
> > So they can point the reports at some place like dmarcian.com, which
> > does the analysis for small mail systems for free.  Once again, this
> > is not a new problem, and practical solutions are well known to people
> > who take a few seconds to look for them.
>
> Most of the small domain operators will not do that.  And this leaks
> sensitive data.
>
> If you can't send DMARC reports to some domain, no big deal nobody
> cares.  There's little operational impact.  If their certs expire,
> and they don't notice, everybody who's trying to send them email
> (and their postmaster staff getting support calls) feels the pain.
>
> I am not buying the outsourced processing model as sufficiently
> broadly applicable.  Why are you so opposed to recognizing that
> perhaps we have two different use-cases to address, and might well
> address both?  I am not denying your use case, just saying it is
> less urgent based on operational experience of resolving TLS issues
> in forward delivery.
>
> As for the authors of the draft, they should not be focused on
> *just* the large provider problem if this is to be broadly applicable
> technology.  If their part of the elephant requires aggregate report
> flows, so be it.  Not everyone will send them such reports, they
> require a bunch of heavy-lifting.  A simple in-band status indication
> stands a better chance of being enabled by default.
>
> [ I am really hoping to not hear a counter-argument, I don't think
>   I am saying anything radically controversial, but I keep being
>   surprised ... ]
>
> --
>         Viktor.
>
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>