On Fri, May 06, 2016 at 04:20:47PM -0000, John Levine wrote:
> >> The most timely reporting mechanism may be neither HTTPS nor a
> >> separate email report, but an ESMTP extension that can signal
> >> authentication errors as they occur. ...
>
> I'm getting the impression that it would be helpful to try and write
> down some scenarios about what the reports are for. Here's a few:
>
> 1. Company has lots of MTAs, collect statistics to see which ones
> are misconfigured in preparation for publishing policy statements.
>
> 2. Company's published policy statements, monitoring to see if
> MTAs are screwing up.
>
> 3. Detecting various sorts of MITM attacks.
>
> 4. Detecting other attacks, details unclear.
>
> For items 1 and 2, the ESMTP extension won't work, since the MTAs as
> likely as not won't have it.
That's not a fair objection, they would have to deploy upgraded
MTAs that support the new extension, just as would deploy MTAs that
support DANE or STS to enjoy the benefits of those (yes at present
upgrades are only needed for outbound support).
They would also need upgraded MTAs to support any future DEEP
policies, or implement TACK, ...
> (If they did, they wouldn't be misconfigured.)
That's false. The most common misconfigurations are untrusted,
expired, non-matching or incomplete certificate chains, followed
by selectively enabled STARTTLS (perhaps based on client reputation,
...).
Once the upgraded MTA software is deployed, the extension would
only fail to be present if some non-conformant SMTP servers are
later added to the mix. Some basic self-monitoring is also expected.
For receivers that don't enforce, a "Transmitted:" header can also
convey the authentication status along the path, even past MTAs
that are not explicitly aware of their role in DANE or STS.
I also did not mention that sending MTAs should probably also
send
TLSSTATUS DANE|STS RETRYMX
when skipping a first MX host to use a second.
> For item 3 it probably won't work either since the
> MITM will block it.
Yes, the real-time in-band reporting is for the 99.9% of cases that
are self-inflicted.
> As I've said before, I expect that in practice people will send
> reports by mail because it's easier, but https could work if there
> is anyone who actually wants to use it.
If aggregate reporting is the only nail, then the email reporting
hammer is the only/primary tool needed in the tool-belt.
My experience strongly shows that the first-order problem is timely
misconfiguration alerting.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
