On Sun, Jun 8, 2014 at 10:22 PM, Jim Fenton <fenton(_at_)bluepopcorn(_dot_)net>
wrote:
On 06/06/2014 04:12 PM, Brandon Long wrote:
Now that more servers are offering STARTTLS, it would seem beneficial
to move forward towards certificate validation.
Before we get too far down the road with how to accomplish this, I'd
like to ask about the "beneficial" part: What behavior we would like to
occur with respect to certificate validation?
Preventing MITM attacks. Really, that's more certificate-pining than
validation itself.
Currently, if certificates don't validate correctly for SMTP, most
clients just let the TLS connection complete anyway. This has the
obvious problem with man-in-the-middle attacks, but is effective against
passive attacks.
If this changes, we'd presumably be bouncing messages when the cert
doesn't validate. That might be the right thing to do for some very
sensitive messages, but the vast majority aren't. Email is biased to
favor delivery over security, and our usage assumes that in various ways.
Yes, we would bounce messages, or at least temp fail them for re-try later.
With pining, a domain is choosing that having messages bounce/delayed is
preferably to the MITM hole.
The sender can still choose to ignore that and send anyways.
To me, there are a couple reasons why a cert-pin would fail:
1) Domain switched certs suddenly
2) Traffic is being intercepted
I agree that delaying/bouncing mail for #1 is not what one would want. The
http pining spec allows for you to pin intermediate certs, which means you
can switch the leaf cert with no issues to reduce the chance of this
problem. That said, there are plenty of other ways in which email can be
disrupted in a similar fashion (domain expires, DNS misconfigurations,
DNSBL and reputation)
As for #2, most people would say they don't want their email watched there.
Now, its possible that there are countries, government agencies,
companies, schools that would insist on being able to intercept, and their
citizens, employees, students are subject to their rules and willing to
allow it. I think in most of those cases (well, besides countries), its
easy enough for the admins to block outbound port 25 and install their own
relay server for sending mail, and in many cases this is already done. If
people allow access to external web mail or allow outbound MSA, they've
already lost the ability to guarantee interception at some point anyways.
I should point out that many MTA's (including Google Apps for your Domain),
allow the admin to require TLS or require a valid certificate or matching
certificate for talking with specific hosts. This would be a way of
expanding that at the will of the sender/receiver.
If these messages do bounce, what happens if it isn't possible to
establish a TLS path with validated certificates on the return path?
Obviously we've moved to a world where such bounces are less likely, but
they still occur. We're not talking about a "require encryption" statement
for the message like was proposed by my colleagues in the "Manadatary
Secure Mail Delivery" proposal (
http://www.ietf.org/mail-archive/web/ietf-smtp/current/msg07557.html).
Example wise, we're talking about A -> B -> C where B -> C fails a pin, so
the message is bounced either to A or to some other D. Either all paths
from B are compromised, in which case, yes, the bounce will expose, or its
C which is compromised, so the bounce to A|D isn't any more likely to be
compromised.
It's the receiving SMTP server that sets the level of security (pins the
certificate) here, while it's only the SMTP client that could possibly
know what the sensitivity of the message is and therefore how important
that might be -- and we don't have mechanisms to convey that to the SMTP
client either.
Well, in reality its both. The receiver says it wants you to pin its
certs, but there's nothing preventing the sender from ignoring the pin.
I'd like to improve the resistance to MITM attacks, sure -- but I
wouldn't want collateral damage to the bulk of traffic, which doesn't care.
Presumably the traffic that doesn't care isn't encrypting today. Our
transparency report shows that many senders of promotional mail don't care,
for example, and why should they if they're sending the same thing to
millions of users.
I also think that certificate pining like this helps to prevent bad
behavior by removing the holes.
I think without something like this, you're likely to see people doing
manual federation instead, where Gmail talks to Facebook and agrees on a
cert pin to ensure our traffic is encrypted.
And, there is already DANE TLSA, the concept of doing this is not new. I
don't know where that was discussed in order to read the discussion and
understand what was already learned.
Brandon
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp