Implications of a common private keys directory in 2.1

[Carola Grunwald]

Peter Lebbing <peter at digitalbrains.com> wrote:

>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...

Pardon me when I disgress too much from the original problem, but my
system carries a TLS certificate database of all external servers it
ever contacted, and, based on the certificate's fingerprint, you can
choose from that list which host connections you allow.

Kind regards

Caro