Viktor Dukhovni via Postfix-users:
> On Sun, Dec 21, 2025 at 05:58:05PM -0500, Wietse Venema via Postfix-users
> wrote:
>
> > I'm about to finish the Postfix 3.11 stable release so things can
> > still be changed.
> >
> > In addition to keeping the current behavior we can also
> >
> > - Revert the default lmtp_tls_security_level change.
> >
> > - Limit the scope of lmtp_tls_security_level to type "inet:" connections
> > and ignore the setting for type "unix".
> >
> > - Something else.
> >
> > I'd like to decide this soon.
>
> A particularly sophisticated Postfix administrator could use TLS client
> and/or server certificates to implement TLS LMTP authentication in
> either or both the server to client or client to server directions even
> with unix-domain sockets.
>
> For this to be effective, TLS needs to be mandatory, but *encryption* of
> data transfer is not needed. With TLS 1.2 and earlier we had access to
> null ciphers:
>
> $ postconf -d tls_null_cipherlist
> tls_null_cipherlist = eNULL:!kDH:!kECDH:!aDSS:!MD5:!aNULL
>
> Which, combined with OpenSSL security level 0, gives:
>
> $ openssl ciphers -v -s -tls1_2
> 'eNULL:!kDH:!kECDH:!aDSS:!MD5:!aNULL:@SECLEVEL=0'
> ECDHE-ECDSA-NULL-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=None
> Mac=SHA1
> ECDHE-RSA-NULL-SHA TLSv1 Kx=ECDH Au=RSA Enc=None
> Mac=SHA1
> NULL-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=None
> Mac=SHA256
> NULL-SHA SSLv3 Kx=RSA Au=RSA Enc=None
> Mac=SHA1
>
> These enable peer authentication via ECDSA or RSA certificates and
> (redundant over unix-domain sockets) traffic integrity via SHA256 or
> SHA1 MACs.
>
> With TLS 1.3, the "null" ciphers are gone, and authentication is no
> longer possible without encryption, which, with AEAD, is
> performance-competitive with the "null" MAC-only ciphers.
>
> Bottom line, the sensible security levels with LMTP over unix-domain
> sockets are basically anything other than "may" or "dane" and
> "dane-only".
>
> - "encrypt" is only useful if the client is authenticating to the server
> via a TLS client certificate (that the server requests and uses for
> access control).
>
> - "dane" and "dane-only" are not available because there's no DNS name
> to find the server's TLSA records.
>
> - "fingerprint", "verify" and "secure" are all available when the client
> is configured to verify the server's certificate.
>
> For a majority of Postfix users, "none" is a sensible default for
> unix-domain socket LMTP delivery. Authentication in either direction
> is likely rare, and it may be easier to restrict access to create or
> write to the LMTP socket through file permissions.
I don't think that one default TLS security level can meaningfully
cover both UNIX-domain and TCP conenctions. Maybe we need two (one
parameter for each connection type, or one list-valued parameter
that is indexed by connection type).
We can still revert lmtp_tls_security_level back to its Postfix
3.10 default (empty), and then figure out in Postfix 3.12 what
the configurtation model shuld be.
Wietse
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
