Implications of a common private keys directory in 2.1

[Peter Lebbing]

On 23/11/16 10:53, Andrew Gallagher wrote:
> If the message is being automatically decrypted at the MTA then it
> provides no more security than TLS.

I could concur with this statement if we amend it a little: when two
MTA's are explicitly configured as TLS peers. They have to abort the
mail exchange when TLS can't be negotiated and when the certificate is
not as expected. "Expected" can mean: DN checking, issuer checking,
fingerprint checking, perhaps CRL checking.

There are many problems preventing succesful TLS on SMTP. It's trivial
to downgrade, and certificates are only checked whether they are valid
in the general sense, not even the DN is checked. I could MITM a
connection to mail.example.org, present a valid certificate for
mail.digitalbrains.com, and the peer would accept it even though it
isn't valid *for mail.example.org*. Basically, it only works for passive
adversaries.

But since the OpenPGP-protected mail payload would also require explicit
configuration, I don't think it is actually a disadvantage of TLS in
this case...

I'm not completely sure the "explicitly configured TLS" doesn't have a
snag somewhere that complicates stuff more, though... I vaguely remember
something like that from a presentation...

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>