On Fri, May 06, 2016 at 01:37:02AM +0700, Aaron Zauner wrote:
> > On 06 May 2016, at 01:10, Viktor Dukhovni <[email protected]> wrote:
> >
> > On Fri, May 06, 2016 at 12:32:59AM +0700, Aaron Zauner wrote:
> >> So in that case why not prefer a secure HTTPS connection over an insecure
> >> SMTP connection?
> >
> > We're discussing an error reporting mechanism, not a secure message
> > delivery mechanism. It should be possible to deliver the bad news
> > even under adverse conditions.
>
> We're discussion a _feedback_ mechanism, at least that's what I understood
> from the draft.
Feedback on authentication failures, that is only really interesting
in near real-time. Once a problem is resolved, late feedback is
old news.
This is very much unlike DMARC reporting where domains are interested
the origin and frequency of potential phishing attacks, and processing
by a third party that provides aggregated data periodically is just
fine.
With STS and DANE one primarily wants the data from the last hour,
not the last month. This is real-time operational data.
> > If the reports contain sensitive data, let's simplify the reports
> > to contain less of it. In most cases, a boolean "your cert chain
> > fails to verify for domain D at MX host H" is quite sufficient.
>
> What if I want to send sensitive information about delivery failures? I.e.
> the way a MITM was attempted?
The MITM attacker already knows he was attempting to intercept the
traffic.
> > The SMTP message would be sent via opportunistic TLS, with fallback
> > to cleartext if STARTTLS fails or is not advertised.
>
> See above. Opportunistic TLS is the wrong approach here in my opinion. I
> never liked it and I never will. I think the reasons are obvious.
Too bad, and I'm not taking the bait to debate this. That'll take
us off topic. It suffices to say that given the need for real-time
notification, opportunistic TLS is needed for SMTP delivery of
reports.
--
Viktor.
P.S.
The main reason that DANE SMTP has a very low failure rate is that
I've been sending all the failure reports for ~2 years. In most
cases they would not have reached the guilty party if authentication
were required.
It is my hope that in the not too distant future more high volume
senders will implement outbound DANE support and tell everyone that
failure to publish correct TLSA RRs is the receiving system's
problem to fix not much different from failure to publish correct
A or MX records. At that point folks who DoS themselves will
quickly notice the outage and address the problem.
If we standardize a "MAYTLS" header, then an informed user will
alert their correspondent to contact their administrator as part
of or instead of sending an explicit override to unauthenticated
opportunistic TLS.
At present because so few DANE sending systems are live, a receiving
domain might not notice for some time, and might blame the sender
(the usual "nobody else is having that problem").
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
