On Tue, Jul 29, 2014 at 07:53:41PM -0400, Wietse Venema wrote:
> I think it would help if someone can explain what an SMTP client
> certificate actually proves, without all the wishful thinking that
> every nugget of "security" is a worthwhile improvement.
>
> What does the certificate really prove about the SMTP client?
>
> What does the certificate prove about the connection from that SMTP
> client, and how useful is that really, bearing in mind that this
> SMTP connection is very likely only the last one in a sequence of
> network connections?
>
> What does it prove about the message envelope and message content
> that was sent over that SMTP connection, bearing in mind that the
> message very likely originated from some other system?
Others may have their views of what a client certificate actually
demonstrates, below is mine:
* It establishes an identity for the party at the other end of the TLS
connection be it the "true" client or the MiTM.
* This identity may or may not be the party attempting to send a
given message. To avoid MiTM attacks, the sending systems has
to authenticate the server.
* When a given organization (say an email service provider of
some sort) has non-default access permissions to inject mail
into a given server's queue, then a client certificate may be
used as an alternative to SASL authentication to authenticate
with an identity that is authorized for the desired access.
* If we add a feature that makes it possible to authenticate a
client reference identity (typically the HELO name) via DANE
or PKIX, then it becomes easier to grant non-default access
rights based on a more stable identifier than a certificate
fingerprint (which is difficult to coordinate across
organizational boundaries).
* Logging of DANE or PKIX verified HELO names may show positive
evidence that some messages originated where claimed and were
not intercepted in transit. However, in fact what learns is
the identity of either the "true" client or the "true" MiTM.
If one can reasonably rule out the possibility that the
authenticated party is in fact an MiTM attacker on some other
source, then one may cautiously conclude that the message in
question was delivered over a secure channel.
* That said, should an MiTM attack take place, and if the sending
system is not doing its job of authenticating the receiving server,
there is nothing the server can do to detect MiTM, rather all that
happens is that the MiTMed transmission either has no client
cert at all (along with a forged HELO name and/or source IP address),
or has a certificate for some untraceable throw-away domain. The
transmission will no longer have the authorization of the "real"
client, provided that client has non-default authorization based
on its special identity.
An astute administrator may be able to put enhanced functionality
in this space to good use. It seems likely that many will simply
enjoy a false sense of "security", where none exists. I am inclined
to add some functionality in this space, with strong disclaimers
in the documentation.
--
Viktor.
