On Fri, May 06, 2016 at 12:57:15PM +0700, Aaron Zauner wrote:
> > 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:
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.
> The last sentence explicitly mentions "detect potential attackers".
That nice, but it's way down the priority list of what's actually
relevant. First we need the protocols to be usable, which means
sufficiently resilient to be deployed, which means timely error
reporting.
> So if there's a MITM you'd rather have him intercept (and possibly modify!)
> the feedback reports as well?
Yes! The vast majority of the failures will not be MiTM-related,
and if there is an MiTM, well then you can't send the report to
the right party anyway.
> 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's little need for very detailed information. We just want
to distinguish between a few classes of failures.
* Lack of STARTTLS (this too is often self-inflicted!)
* Lack of shared protocol protocol parameters (protocol version/ciphers)
* Lack of shared trust anchors
* Reference identifier mismatch
* (Perhaps one or two others I'm forgetting right now)
> There're many other attack vectors. Also see the IAB statement I referred
> to before, I took it seriously.
None of this matters if the protocol cannot be widely adopted, and
wide adoption requires infrequent and short additional outages.
The reporting feature needs to focus on this, and everything else
is secondary.
> > ...
> >
> > 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".
This is an *email* security protocol. It certainly needs to deliver
the mail properly, the result should an a working email protocol
that is used and is more secure. An unusable email security protocol
is pointless.
> 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 primarily role of the reporting spec needs to be to maintain
the operational stability of inter-organizational email transport.
It needs to have as much or as little security as best fits that
role. Reporting is NOT a security protocol, its job is to help
keep the actual security protocol usable.
> > 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",..
There will first be non-IETF documents in this space, and perhaps
ultimately some IETF BCPs once we have even more operational
experience.
> > 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.
That's still a bit shaky, the early adopters of LE for SMTP are
where some of the most frequent DANE problems show up. This is
because automated LE cert rotation ignores the necessity to update
TLSA records from time to time. Survey says 424 MX hosts with
stable "IN TLSA [23] 1 ?" records and 109 MX hosts with fragile,
soon to break "IN TLSA [23] 0 ?" TLSA records. The ratio is
improving, over time, but needs to be much better.
There are things LE can do to make this better:
* More prominent documentation of best-practice for combining DANE
and LE certs, and monitoring their correctness:
; Keep server key fixed when doing automated rotation via "--csr"
; option option. Rotate server key manually, from time to time,
; and update "3 1 1" record accordingly. Do so only while the
; "2 1 1" LE key is not also changing.
;
; Ensure MX hostname matches the certificate SAN
;
_25._tcp.smtp.example.org. IN TLSA 3 1 1 <sha256(server public key)>
; Track LE issuer public key, update TLSA RR promptly when it changes.
; Stable server key above makes it possible to tolerate brief mismatches
; if the LE issuer key changes unexpectedly.
;
; Ensure the issuer CA cert is part of server's chain file
; (i.e. is sent to peer in server TLS Certificate message).
; [ This is of course also necessary for STS, as the LE issuer
; CA is an intermediate CA, not a trust anchor. ]
;
_25._tcp.smtp.example.org. IN TLSA 2 1 1 <sha256(LE issuer public key)>
* Better advance notification of planned changes in the LE
issuer public key, not just via the blogs, but also via email sent
locally to the administrator by the key rotation scripts.
* Provide tools to compute the new "3 1 1" and "2 1 1" records
and compare them to what's in DNS. Avoid deploying new cert
chain if neither match. If just one changes, deploy, but
send alert to admin to update the TLSA RRs.
* As explained a recent post to this list (NEWSFLASH thread),
the "3 1 1" + "2 1 1" combination is quite resilient if
sensibly monitored.
* The "mail in a box" project has done a good job of integrating
LE and DANE and DNSSEC for a complete turn-key system, and
I see very few errors from those machines. They just routinely
have correct working TLSA RRs across cert rollovers. Kudos
to that project. <https://mailinabox.email/>
I've for a long time been deeply involved in the day-to-day practice
of MTA SMTP transport security. Designing and implementing the
Postfix TLS interface, supporting Postfix TLS users on the mailing
list, authoring DANE support in OpenSSL, monitoring DANE adoption.
Monitoring and resolving DNSSEC interop issues at hosting providers,
...
So yes, I don't just view this as a pure security protocol issue.
All the pieces have to fit together to actually create something
that gets used. Think systemically, optimization of the security
of a small component of a large system can easily turn out to be
at the expense of the security system as a whole.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
