> On 06 May 2016, at 11:47, Viktor Dukhovni <[email protected]> wrote: > > On Fri, May 06, 2016 at 10:39:57AM +0700, Aaron Zauner wrote: > >>> The MITM attacker already knows he was attempting to intercept the >>> traffic. >> >> The MITM does, the receiving party may not. > > You need to keep in mind that in the vast majority of cases > authentication errors will be operational errors (self-DoS) on > receiving systems, and the task at hand is to minimize the frequency > and duration of outages, so that security is used and not just > disabled as unusable. Maximalist approaches are highly counter-productive > here.
This is not what I understood from the draft in it's current form: ``` Abstract A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents, including STARTTLS [RFC3207], DANE [RFC6698], and SMTP MTA STS (TODO: Add ref). These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains. Recipient domains can then use this information to both detect potential attackers and diagnose unintentional misconfigurations. ``` The last sentence explicitly mentions "detect potential attackers". > If there is an MITM, we don't need confidentiality of the report > that there is an MITM. While we'd like the report to get through > to the right party in that case, sadly that's not possible, but > reports do get through to the majority of peers where the issue is > an operational SNAFU on one end or the other. So if there's a MITM you'd rather have him intercept (and possibly modify!) the feedback reports as well? Confidentiality may be needed as detailed information on MITM attacks can give indication as to which paths and systems are affected (e.g. to 3rd party attackers, not the original MITM). There're many other attack vectors. Also see the IAB statement I referred to before, I took it seriously. > Perhaps it would be wise to agree on the purpose and requirements > for reporting before we debate reporting "solutions"? > > As I see it, the top 20 goals of forward path authentication failure > reporting are: > > 1. Notify the receiving system they've partly messed up, > as some of their MX hosts fail authentication. > > 2. Notify the receiving system they've still partly messed up, > and you've independent evidence they've messed from various > 3rd party test sites that confirm your observations. > > 3. Notify the receiving system they've royally messed up, > and all their MX hosts are failing authentication. > > 4. Notify the receiving system they've still royally messed > up, and you're going to soon bounce all their back to the > senders. > > ... > > 20. Keep the receiving party appraised of possible MiTM attacks, > via post-event statistical reporting. > > Yes, the above is deliberately provocative, to jolt folks out of > their comfort zones and to think about the real goals and out of > those relevant requirements. It's called "Strict Transport Security" not "How to deliver mail properly". While I do agree on most points, we need to keep in mind that this is supposed to be a security standard not merely an email delivery feedback system. > The key requirement as I see is *timely* delivery of focused *alerts* > to operators who can fix the problem, ideally before it affects > the delivery of email, while the issue is still localized to just > a proper subset of the MX hosts. I think that may be a reason for another draft in another working group. This one is called "Utilizing TLS in Applications",.. > > Sites enabling DANE, STS, ... need to commit to superior operational > practices (reliable automation, monitoring, ...) and in many cases > to risk reduction by, for example, avoiding using a single wildcard > certificate for all their MX hosts that can DoS them all when it > expires. Staggering MX host certificate rotation, so if if goes > wrong, only a subset of the MX hosts is affected, ... > > Sites that don't have the operational discipline to do this right > are best off staying with opportunistic TLS and publishing neither > DANE nor STS policies. DoSing themselves periodically, and causing > pain for senders trying to do the right thing helps no one. Yea, we'll try to help them out separately with Let's Encrypt automation anyway. Aaron
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
