Implications of a common private keys directory in 2.1

[Stephan Beck]

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.

Looking at it from the Postfix SMTP client side (as an example), with the
smtp_tls_security_level (default: empty) main.cf configuration parameter
there are the following levels with increasing security from left to right:
none, may, encrypt, dane, dane-only, fingerprint, verify, secure

From dane-only upwards no MITM is possible. With mere "dane" there are 2
fallbacks: if DNSSEC lookup does not present any result (-->fallback to
may), if there are result, but they are not usable (--> fallback to
encrypt).

Even if the "verify" level seems to open the door once again to
unauthenticated DNS MX lookups (and possibly, MITM), the name
verification parameter smtp_tls_verify_cert_match keeps it locked.
But that's theoretical, as it is not considered to be appropriate for
systems that deliver mail to the Internet.

I have a spontaneous sympathy for the "fingerprint" level as it
suppresses (the need to rely on) any (CA) authorities :-)


Cheers,

Stephan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x4218732B.asc
Type: application/pgp-keys
Size: 4089 bytes
Desc: not available
URL: </pipermail/attachments/20161123/d6836f36/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20161123/d6836f36/attachment.sig>