On Fri, May 06, 2016 at 02:14:37PM +0700, Aaron Zauner wrote:
> > The current form is not the final form. To the expect that the
> > draft emphasizes statistical reporting over problem alerting it
> > needs to be corrected.
>
> I'm aware of that, but if the draft turns out to be a delivery reporting
> system, I'm not going to support it.
The draft will likely move forward with at least one of us not
entirely in agreement with its content. I think the most productive
approach is to raise your issues as best you can. You can of course
walk away as or when you see fit.
I think we should stop the deep dive and come back to prioritizing
goals. Rank and/or replace the below, and then we can figure out
how to address the right problem:
* Near real-time forward-path alerting of (likely) receiver
misconfiguration?
* Aggregate reporting of authentication success/failure
stats?
* CT-like reporting to public "observatories"?
* Other goals?
We may also have to pin down some technical details:
* Reliability of report delivery? (DMARC is not trying
to defend against MiTM attacks so is not concerned with
MiTM attacks on the reporting channel, here things are
different).
Relevant issues for aggregate reporting might include:
* How long should a sender keep on trying to deliver a report?
* How often to retry?
* How does one avoid DoSing a target site with reports?
The above will require some care.
The simplest thing to in the near term do is to just communicate
authentication failure inline, and either continue delivery (if
authentication is not yet in hard-fail mode) or move on to the next
MX host. This gets to the right party in near real-time.
Sites that want real time reports of this sort would enable
a new ESMTP feature advertisement that makes it possible for
the client to send:
TLSSTATUS DANE|STS NOSTARTTLS
TLSSTATUS DANE|STS UNTRUSTED
TLSSTATUS DANE|STS NOTMATCHED
TLSSTATUS DANE|STS SUCCESS
TLSSTATUS FALLBACK
(handshake failures are communicated via TLS alerts)
(the FALLBACK status is for cleartext retries after
STARTTLS failure in opportunistic mode).
The MTA on the receiving end can log these, and raise alarms under
appropriate conditions. This would need support in sending and
receiving MTAs and does not require either a "mailto:"; or "http"
reporting address. Just new inline signalling.
If the status is signalled as part of an actual delivery it might
also be recorded in new message trace headers. Tony Finch some
time ago suggested "Transmitted:" as a sender-added trace header
to complement "Received:". It did not get traction at the time,
but still looks like a reasonable idea.
> I understand this is what you consider relevant. I'd like to know why and
> how attacks happen as well, if possible.
Reporting that conveys longer-term metrics is admittedly also of
some interest, but we rather strongly disagree on its relative
importance at this early stage of the evolution of authenticated
MTA-to-MTA transport.
> > There will first be non-IETF documents in this space, and perhaps
> > ultimately some IETF BCPs once we have even more operational
> > experience.
>
> Which non-IETF documents? Where?
Some folks are writing a DANE BCP for SMTP with Postfix, and we'll
try to include as material as possible that is MTA-neutral. I'll
let you known once we have something ready.
> No it isn't shaky, it's non-existent. People that currently deploy LE
> certs on their mailservers do so on their own, without guidance and without
> any support nor automation.
Well some guidance is available in the LE community forum posts,
one of mine is even administratively pinned. But more is possible.
> And I'm sorry to say: I don't care about DNSSEC
[ This sounds needlessly dogmatic. ]
> Again: there's currently neither incentive nor effort within LE to look
> at DANE. Nor enough man-power available. Nor is it really relevant in my
> opinion.
At least one of the folks behind LE has been reasonably supportive,
though admittedly not yet to the extent of explicit support for
DANE in the tooling.
> I'd rather consider every detail than rush a standard through the IETF
> process.
I am also not in a hurry to skip important details.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
