On 12/16/2015 02:03 AM, Michael Storz wrote:
Am 2015-12-15 20:36, schrieb Viktor Dukhovni:
On Mon, Dec 14, 2015 at 04:34:58PM +0000, Viktor Dukhovni wrote:
So, we've managed to hold off on offering SNI support for a decade
since TLS was integrated into Postfix 2.2. I just wanted to see
whether anyone still wanted it in Postfix, but perhaps if they
really did they've moved on to other solutions.
So far I'm not sensing any burning desire for server-side SNI in
Postfix, and it is quite late in the 3.1 cycle, so if we're going
to do SNI, it'll be in 3.2 or later.
At present, the Postfix SMTP client only sends SNI with DANE, where
it is clear what name to ask for (the TLSA base domain). With
"verify" and "secure" it is far from clear that sending SNI would
do more good than harm, and we match multiple names or name patterns,
so the choice of what to send in SNI is not so clear.
I think we're set for now with Postfix as-is.
Could you explain, why you think sending SNI could harm?
Lets look at the different cases assuming no DNSSEC is used. In the
general case the only trustable reference identifier therefore is the
domain of the recipient address. If you do not send SNI then the server
sends the default cert attached to the ip address of the server (TLS
connection endpoint). If it was possible to put all hosted domains into
the SAN of the cert you get a match for your reference identifier and if
the cert could be verified you get an authenticated TLS connection. If
the domain was not in the set of presented identifiers at the maximum
you get a trusted TLS connection (cert verified) but no authenticated
TLS connection.
But with port 25, certificate authorities do not matter, so an admin
running the same smtp server on multiple hostnames can generate a new
self-signed cert at no cost every time they add a domain that resolves
to that IP address.
Thus even with multiple domains resolving to the same IP address, I
don't see a need for port 25 to have more than one cert.
Am I missing something?
