Re: postfix and multiple TLS certificates (SNI support?)

[Viktor Dukhovni]

On Fri, Dec 11, 2015 at 11:50:40AM -0600, Brian Sebby wrote:

> other.mail.server:smtp inet n - n - 0 smtpd
> -o myhostname=other.mail.server
> -o smtp_tls_cert_file=/path/to/certfile.pem
> -o smtpd_tls_cert_file=/path/to/certfile.pem
>
> It seems to work pretty well for us. A wildcard certificate or one with
> multiple subject alternate names will also work, but those tend to be more
> expensive.

Over the years there have from time to time been requests for
server-side SNI support in Postfix, but most users have found
workable alternatives, such as above.

A key reason that SNI support is not there yet, is that we like to
do things right(TM) in Postfix or not at all, and it is not entirely
clear what the "right" configuration interface for server-side SNI
might me (we can ignore implementation difficulties for now).

The main obstacle is that the primary cert/key are as "root" *before*
smtpd(8) drops privileges, while SNI information arrives during
the connection, when smtpd(8) is already running as the unprivileged
"postfix" user, possibly within a chroot jail. This means that
smtpd(8) would need to arrange to gain access to all requisite keys
and certificates while still running root during process startup.

Now we certainly don't want to pay the cost of loading all the
certificates and keys into memory, so the options are perhaps:

1. Use a table lookup that maps domain names (or domain name
suffixes) to base64-encoded chain (PKCS#7) and key (PKCS#8)
objects. The table would be a "cdb" or "lmdb" database owned
by root, mode 0[46]00.

example.com
chain=MIIByQYJKoZIhvcNAQcCoIIBujCCAbYCAQExADALBgkqhkiG9w0BBwGgggGcMIIBmDCCAT6gAwIBAgIBATAKBggqhkjOPQQDAjAWMRQwEgYDVQQDDAtleGFtcGxlLmNvbTAeFw0xNTEyMTExODUyMDlaFw0xNjAxMTAxODUyMDlaMBYxFDASBgNVBAMMC2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEb2rusHCpKLrDj0tOIqr+g22Iq9eDg4atYtRhKVas6ve2L9o9d3cRnnGIt9qTJV3E6vjvGfxBPV6q+H14Q8XDbqN9MHswHQYDVR0OBBYEFELpnC1wAEKrfE2xJuRt/lX6FF2MMB8GA1UdIwQYMBaAFELpnC1wAEKrfE2xJuRt/lX6FF2MMAwGA1UdEwQFMAMBAf8wEwYDVR0lBAwwCgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0EAwIDSAAwRQIgRtBQtdE4AGJozAVkGs81uYW/KVBquoHYBP7XxBC/z6YCIQDXzLBOw5ivFiWf1a/9tl1ddHL0IWYBX61NM0clM/oDJqEAMQA=
key=MHcCAQEEIMoR3bMT+b2/5NCa/ZGZom/a3cMoE1wGu+awdw8pOII2oAoGCCqGSM49AwEHoUQDQgAEb2rusHCpKLrDj0tOIqr+g22Iq9eDg4atYtRhKVas6ve2L9o9d3cRnnGIt9qTJV3E6vjvGfxBPV6q+H14Q8XDbg==

The PKCS#12 content would be protected by file-system permissions,
not a password. The smtpd(8) server is not a human, and any
required password would have to be stored along with the
certificates. In such cases, since passwords are not optional
with PKCS#12, I tend to use passwords such as "umask 077",
which convey where the effective security lies.

There would need to be a tool that "compiles" a directory
of PKCS#12 files into such a table.

2. Leave the keys and certificates in files, and use strong
passphrases for the keys, but configure smtpd(8) with a root
owned table (mode 0[46]00) that maps domains or domain suffixes
to a (password, key, chain) triple.

# Filenames are relative to the queue directory, because
# that's the chroot jail.
#
example.com
pw=ABLLUpNBh8eakVs4Qinv,
key=sni/example.com.pem,
chain=sni/example.com.pem

The private key files would then be owned by "postfix" (mode
0400) and protected from other non-privileged Postfix processes
via the associated strong passwords.

example.com.pem:

-----BEGIN ENCRYPTED PRIVATE KEY-----
MIHeMEkGCSqGSIb3DQEFDTA8MBsGCSqGSIb3DQEFDDAOBAiCQc48rR0diwICCAAw
HQYJYIZIAWUDBAECBBCwIPRri8y1TOo872zl1It/BIGQfPsiJk83asYBOgJ60a44
IBq1v/wSE9v8yD9jTq8Cb/jQBvie9tdMSCr8xjwVlvC/vDfbNx6W+d3wjQRM6rzY
sXWVBeSb2TzxKGfZ9xD9ejZhUGXADIYsuoUDfZlz3vl6htViq7sjYWL8Dgz/PDit
Sf4Rk1tiqV3cnFMY2OgQz06HGn0U22elq2MpYExL3BCz
-----END ENCRYPTED PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIBmDCCAT6gAwIBAgIBATAKBggqhkjOPQQDAjAWMRQwEgYDVQQDDAtleGFtcGxl
LmNvbTAeFw0xNTEyMTExODUyMDlaFw0xNjAxMTAxODUyMDlaMBYxFDASBgNVBAMM
C2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEb2rusHCpKLrD
j0tOIqr+g22Iq9eDg4atYtRhKVas6ve2L9o9d3cRnnGIt9qTJV3E6vjvGfxBPV6q
+H14Q8XDbqN9MHswHQYDVR0OBBYEFELpnC1wAEKrfE2xJuRt/lX6FF2MMB8GA1Ud
IwQYMBaAFELpnC1wAEKrfE2xJuRt/lX6FF2MMAwGA1UdEwQFMAMBAf8wEwYDVR0l
BAwwCgYIKwYBBQUHAwEwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCgYIKoZIzj0E
AwIDSAAwRQIgRtBQtdE4AGJozAVkGs81uYW/KVBquoHYBP7XxBC/z6YCIQDXzLBO
w5ivFiWf1a/9tl1ddHL0IWYBX61NM0clM/oDJg==
-----END CERTIFICATE-----

Beyond that, support for this may require sufficiently recent
OpenSSL releases (1.0.2 is enough, 1.0.1 may suffice), as the
server-side SNI interface is IIRC a pain to work with in older
releases.

So the question is whether either interface proposal is usable and
desirable. Is there a better way to do this?

--
Viktor.

[Dirk Stöcker]

On Fri, 11 Dec 2015, Viktor Dukhovni wrote:

> Over the years there have from time to time been requests for
> server-side SNI support in Postfix, but most users have found
> workable alternatives, such as above.
>
> A key reason that SNI support is not there yet, is that we like to
> do things right(TM) in Postfix or not at all, and it is not entirely
> clear what the "right" configuration interface for server-side SNI
> might me (we can ignore implementation difficulties for now).

I hope that SNI is dying long term. E.g. for IPv6 I again use the one
IP for one service so SNI is not needed anymore. This has a lot of
benefits, but sadly you need to still have the all-in-one approach for the
parallel IPv4 (my reason why I hope IPv4 is also dying soon, probably
unrealistic, I know).

And SMTP has the big advantage, that you can define the name of the host
in MX, so the name of the mail server can be independent from the domain
of the email address.

Simply wait a bit longer and maybe that issue solves itself :-)

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

[Alice Wonder]

On 12/12/2015 04:26 AM, Dirk Stöcker wrote:
> On Fri, 11 Dec 2015, Viktor Dukhovni wrote:
>
>> Over the years there have from time to time been requests for
>> server-side SNI support in Postfix, but most users have found
>> workable alternatives, such as above.
>>
>> A key reason that SNI support is not there yet, is that we like to
>> do things right(TM) in Postfix or not at all, and it is not entirely
>> clear what the "right" configuration interface for server-side SNI
>> might me (we can ignore implementation difficulties for now).
>
> I hope that SNI is dying long term. E.g. for IPv6 I again use the one IP
> for one service so SNI is not needed anymore. This has a lot of
> benefits, but sadly you need to still have the all-in-one approach for
> the parallel IPv4 (my reason why I hope IPv4 is also dying soon,
> probably unrealistic, I know).

I do not want SNI to die but IMHO SNI is not for mail servers.

Even with IPv6 I like SNI for web hosting. But it is not for mail servers.

I do however want to see IPv4 go away.

[Viktor Dukhovni]

On Sat, Dec 12, 2015 at 06:42:03AM -0800, Alice Wonder wrote:

> I do not want SNI to die but IMHO SNI is not for mail servers.

On Sat, Dec 12, 2015 at 01:26:06PM +0100, Dirk Stöcker wrote:

> And SMTP has the big advantage, that you can define the name of the host in
> MX, so the name of the mail server can be independent from the domain of the
> email address.
>
> Simply wait a bit longer and maybe that issue solves itself :-)

Thanks for the moral support. I agree that SNI is not particularly
compelling for port 25. The more strongest arguments for SNI that
I've seen are for port 587 submission, where there's no MX indirection,
users' MUAs have statically configured SMTP servers.

So if someone has feedback on either of the candidate interfaces,
or even a better suggestion, I'd still like to hear it. Or is it
the case that all the users who wanted SNI support in Postfix, but
did not get it, are on the Exim list now?

--
Viktor.

[Luigi Rosa]

Dirk Stöcker wrote on 12/12/2015 13:26:

> And SMTP has the big advantage, that you can define the name of the host in MX,
> so the name of the mail server can be independent from the domain of the email
> address.

I use this method.

Just one cert to manage/renew and no exotic configuration. KISS procedure.


--


Ciao,
luigi

/
+--[Luigi Rosa]--
\

Do you know the one... "All I ask is a tall ship... and a star to
steer her by..." You could feel the wind at your back, about you...
the sounds of the sea beneath you. And even if you take away the
wind and the water, it's still the same. The ship is yours...
you can feel her... and the stars are still there.
--James Kirk, "The Ultimate Computer"

[Dirk Stöcker]

On Sat, 12 Dec 2015, Viktor Dukhovni wrote:

>> And SMTP has the big advantage, that you can define the name of the host in
>> MX, so the name of the mail server can be independent from the domain of the
>> email address.
>>

>> Simply wait a bit longer and maybe that issue solves itself :-)
>
> Thanks for the moral support. I agree that SNI is not particularly
> compelling for port 25. The more strongest arguments for SNI that
> I've seen are for port 587 submission, where there's no MX indirection,
> users' MUAs have statically configured SMTP servers.

At least for Thunderbird and some open source mail software I got rid of
this issue as well by implementing the autoconfig procedure:
https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat
That's much more powerful than SNI alone. Parsing the postfix files
it gives each of my users the correct settings for all of their email
addresses.

Negative: If fully implemented it allows everybody to find the username
for a given mail address but I decided that's worth the additional
comfort. Usually guessing gives you the username not much slower (with
some uncertainity).

I tried also to implement the Microsoft variant but till now I do not
think setup is really correct. :-)

[Alice Wonder]

A big negative to Thunderbird autoconfig - it looks for http before
https resulting in MITM vulnerability.

They say it is because hosting companies like godaddy don't want to have
a TLS cert for every e-mail domain.

They should have a DNS TXT field like _moz_auto.domain.tld or something
that points to the authoritative TLS autoconfig server but they don't
want to do that.

[Wietse Venema]

Viktor Dukhovni:

> Thanks for the moral support. I agree that SNI is not particularly
> compelling for port 25. The more strongest arguments for SNI that
> I've seen are for port 587 submission, where there's no MX indirection,
> users' MUAs have statically configured SMTP servers.

And those clients need SNI because...?

Wietse

[Viktor Dukhovni]

On Mon, Dec 14, 2015 at 06:37:59AM -0500, Wietse Venema wrote:

> > Thanks for the moral support. I agree that SNI is not particularly

> > compelling for port 25. The strongest arguments for SNI that

> > I've seen are for port 587 submission, where there's no MX indirection,
> > users' MUAs have statically configured SMTP servers.
>
> And those clients need SNI because...?

Firstly, because MUAs actually do WebPKI certificate checks, so
the certificate content actually matters.

More importantly, because some folks operate mail submission via
a shared IP address for multiple domains. And want to retain the
flexibility to re-target submission for some and not others by having
users set up to use "smtp.respective-domain.example" as their
submission server. Perhaps it is not for us to decide whether
their desire to do that is completely rational, or substantially
"emotional".

Hosting shared submission services is simply difficult, if the
domains are truly customer domains and not a handful of one's
domains then it is typically impractical to obtain all the necessary
certificates to do SNI at scale. Ultimately, the simplest model
is to just have all the users update their submission server settings
to point at a single shared name.

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.

--
Viktor.

[Wietse Venema]

Viktor Dukhovni:

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

Would haproxy/nginx be an option? If a site has hundreds of domains,
they may need a "submission" loadbalancer anyway.

Wietse

[Quanah Gibson-Mount]

--On Monday, December 14, 2015 12:07 PM -0500 Wietse Venema

Given nginx's complete disregard for RFC's (*) and unwillingness to examine
or fix issues related to the email proxy portion of their product (IMAP,
POP, SMTP), I'd definitely avoid it. I.e., I would not recommend nginx as
a solution in front of postfix to anyone.

*<https://forum.nginx.org/read.php?29,252772,253147>

--Quanah


--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration

[Viktor Dukhovni]

On Mon, Dec 14, 2015 at 09:36:33AM -0800, Quanah Gibson-Mount wrote:

> Given nginx's complete disregard for RFC's (*) and unwillingness to examine
> or fix issues related to the email proxy portion of their product (IMAP,
> POP, SMTP), I'd definitely avoid it. I.e., I would not recommend nginx as a
> solution in front of postfix to anyone.
>
> *<https://forum.nginx.org/read.php?29,252772,253147>

I would not characterize lack of a SASL implementation as "complete
disregard for RFCs". SASL is difficult to do right in a non-blocking
manner. I don't recall whether nginx is event-based or threaded,
but if it is the former, I too would be reluctant to do SASL (and
I'd be concerned about thread safety in the Cyrus SASL library and
especially the plugins).

--
Viktor.

[Wietse Venema]

Quanah Gibson-Mount:

> --On Monday, December 14, 2015 12:07 PM -0500 Wietse Venema
> <wie...@porcupine.org> wrote:
>
> > Viktor Dukhovni:
> >> 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.
> >
> > Would haproxy/nginx be an option? If a site has hundreds of domains,
> > they may need a "submission" loadbalancer anyway.
>

> Given nginx's complete disregard for RFC's (*) and unwillingness to examine
> or fix issues related to the email proxy portion of their product (IMAP,
> POP, SMTP), I'd definitely avoid it. I.e., I would not recommend nginx as
> a solution in front of postfix to anyone.
>
> *<https://forum.nginx.org/read.php?29,252772,253147>

[nginx sends plaintext credentials to the MTA] This should not be
a problem as long as the network between the TLS-terminating load
balancer and the MTA is trusted. If it isn't, use a VPN or tunnel.

Wietse

[Quanah Gibson-Mount]

--On Monday, December 14, 2015 6:03 PM +0000 Viktor Dukhovni

<postfi...@dukhovni.org> wrote:

> On Mon, Dec 14, 2015 at 09:36:33AM -0800, Quanah Gibson-Mount wrote:
>

>> Given nginx's complete disregard for RFC's (*) and unwillingness to
>> examine or fix issues related to the email proxy portion of their
>> product (IMAP, POP, SMTP), I'd definitely avoid it. I.e., I would not
>> recommend nginx as a solution in front of postfix to anyone.
>>
>> *<https://forum.nginx.org/read.php?29,252772,253147>
>

> I would not characterize lack of a SASL implementation as "complete
> disregard for RFCs". SASL is difficult to do right in a non-blocking
> manner. I don't recall whether nginx is event-based or threaded,
> but if it is the former, I too would be reluctant to do SASL (and
> I'd be concerned about thread safety in the Cyrus SASL library and
> especially the plugins).

Zimbra has already done this for nginx, and it has been in used in
deployments around the world. The goal was simply to contribute the work
back upstream.

Overall, this is just one of many issues that arise if trying to use nginx
as a proxy for email related bits. On the IMAP side, for example, a lack
of "ID" command support continues to exist, despite it having been sent to
upstream by more than one organization. Zimbra has had to extensively
modify nginx to make it functional for POP/IMAP, and there were a number of
hurdles to overcome to make it functional for SMTP the last time we looked.
At least they did finally take the SSL bits for email we submitted back.

[Wietse Venema]

Wietse Venema:

> Quanah Gibson-Mount:
> > --On Monday, December 14, 2015 12:07 PM -0500 Wietse Venema
> > <wie...@porcupine.org> wrote:
> >
> > > Viktor Dukhovni:
> > >> 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.
> > >
> > > Would haproxy/nginx be an option? If a site has hundreds of domains,
> > > they may need a "submission" loadbalancer anyway.
> >

> > Given nginx's complete disregard for RFC's (*) and unwillingness to examine
> > or fix issues related to the email proxy portion of their product (IMAP,
> > POP, SMTP), I'd definitely avoid it. I.e., I would not recommend nginx as
> > a solution in front of postfix to anyone.
> >
> > *<https://forum.nginx.org/read.php?29,252772,253147>
>

> [nginx sends plaintext credentials to the MTA] This should not be
> a problem as long as the network between the TLS-terminating load
> balancer and the MTA is trusted. If it isn't, use a VPN or tunnel.

Of course I assume that clients will send plaintext credentials to
nginx over TLS, just like they do now with the Postfix submission
service.

Wietse

[Dirk Stöcker]

On Sun, 13 Dec 2015, Alice Wonder wrote:

> A big negative to Thunderbird autoconfig - it looks for http before https
> resulting in MITM vulnerability.
>
> They say it is because hosting companies like godaddy don't want to have a
> TLS cert for every e-mail domain.

I agree with both :-)

> They should have a DNS TXT field like _moz_auto.domain.tld or something that
> points to the authoritative TLS autoconfig server but they don't want to do
> that.

Do you have a link for this information? Don't see a drawback with this
approach when they fallback to normal method without the record. Exchange
uses a SRV record (which is better than TXT I think
- _autodiscover._tcp....) but this has also issues, as they don't lookup
this first, but only after they tried some other things.

[Wietse Venema]

Michael Str?der:
> Sebastian Nielsen wrote:
> > Yes.
> > Its just a draft.
>
> Everything starts with a draft.
>
> > Which certificate should the server use for the encrypted transaction, even if
> > we use SNI?
> > emailservice1.com or emailservice2.com?
>
> The recipient domain would be used with SNI.

This session has multiple recipients, in different domains that
have the same MX host. Whose SNI shall be used?

Repeat after me: SMTP is not HTTPS, SMTP is not HTTPS.

Wietse

[Michael Storz]

Am 2015-12-15 12:22, schrieb wie...@porcupine.org:
> Michael Str?der:
>> Sebastian Nielsen wrote:
>> > Yes.
>> > Its just a draft.
>>
>> Everything starts with a draft.
>>
>> > Which certificate should the server use for the encrypted transaction, even if
>> > we use SNI?
>> > emailservice1.com or emailservice2.com?
>>
>> The recipient domain would be used with SNI.
>
> This session has multiple recipients, in different domains that
> have the same MX host. Whose SNI shall be used?
>

First, you check if you really need SNI. SNI is only needed if you try
to authenticate the TLS connection and the MX-record is not secured by
DNSSEC. Therefore, in the case of smtp_tls_security_level=may, you do
not use SNI. If smtp_tls_security_level is secure/verify you cannot
reuse the TLS connection. You must open a new connection for each domain
like in the case where the MX-records point to different hosts.

On the other side: if you do not want to use SNI, please describe a
scalable solution of how you authenticate TLS connections in this
situation under the assumption that emailservice1.com,
emailservice2.com, emailservice3.com ... do NOT belong to the same
organisation and therefore including the domains in the SAN of the
certificate is nearly impossible.

Michael

[Michael Storz]

Am 2015-12-11 20:33, schrieb Viktor Dukhovni:
> On Fri, Dec 11, 2015 at 11:50:40AM -0600, Brian Sebby wrote:
>
>> other.mail.server:smtp inet n - n - 0 smtpd
>> -o myhostname=other.mail.server
>> -o smtp_tls_cert_file=/path/to/certfile.pem
>> -o smtpd_tls_cert_file=/path/to/certfile.pem
>>
>> It seems to work pretty well for us. A wildcard certificate or one
>> with
>> multiple subject alternate names will also work, but those tend to be
>> more
>> expensive.
>

> Over the years there have from time to time been requests for
> server-side SNI support in Postfix, but most users have found
> workable alternatives, such as above.
>
> A key reason that SNI support is not there yet, is that we like to
> do things right(TM) in Postfix or not at all, and it is not entirely
> clear what the "right" configuration interface for server-side SNI
> might me (we can ignore implementation difficulties for now).
>

From an operational standpoint, I like solution 2 more than solution 1.
However, from a security standpoint, it looks like the opposite is
better since another non-privileged Postfix process is not able to
access the private key.

Michael

[Wietse Venema]

Wietse:

> This session has multiple recipients, in different domains that

> have the same MX host. Whose SNI [domain] shall be used?

Michael Storz:
[Examples that do not use SNI]

Nice try, but that did not answer the question.

> On the other side: if you do not want to use SNI

I have no problems with SNI in SMTP.

Please answer a simple question: when one SMTP transaction has
recipients in different domains, which SNI domain name shall be
used?

I can come up with lots of answers, ranging from one extreme (don't
send multiple recipients per transaction) to using the name in the
MX record.

Make your choice.

Wietse

[Viktor Dukhovni]

On Tue, Dec 15, 2015 at 10:12:56AM +0100, Michael Ströder wrote:

> SNI is a prerequisite for implementing something like [1] if a host is MX for
> more than one recipient domain.
>
> [1] https://tools.ietf.org/html/draft-friedl-uta-smtp-mta-certs

I'll likely end up a coauthor on that draft one day. And no, it
does not (or will not) need SNI. The main motivation for that
draft was IIRC some early interop issues for mandatory TLS between
Cisco Ironport and Microsoft's outlook.com email hosting service.
SNI does not scale to outlook.com. See recent IETF Last-Call
discussion of draft-ietf-uta-email-certs.

--
Viktor.

[Michael Storz]

Sorry for not writing it explicitly. In the case I described, you use
the domain of the recipient address, because this is the only
information you can trust (and this domain must be included in the SAN).
Since you have more than one recipient domain in the described case, you
must use more than one TLS connection to use the recipient domain for
SNI. You cannot use the MX record because you cannot trust it (I wrote:
it is not secured by DNSSEC).

Michael

[Alice Wonder]

On 12/15/2015 07:40 AM, Michael Storz wrote:

>
> Sorry for not writing it explicitly. In the case I described, you use
> the domain of the recipient address, because this is the only
> information you can trust (and this domain must be included in the SAN).
> Since you have more than one recipient domain in the described case, you
> must use more than one TLS connection to use the recipient domain for
> SNI. You cannot use the MX record because you cannot trust it (I wrote:
> it is not secured by DNSSEC).
>
> Michael
>

If you can't trust the MX record then you can't trust the IP address
returned either.

If you can't trust the IP address returned then you are only secure if a
certificate authority is used, and then you have to trust the
certificate authority.

My understanding is that there is no agreement upon which certificate
authorities can be trusted.

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

--
Viktor.

[Alice Wonder]

On 12/15/2015 11:34 AM, Michael Ströder wrote:

>
> Yes. It's your choice.
>
> With DNSSEC I don't have a choice at all. It's a single root key controlled by
> the entity which was the cause for RFC 7258 (besides the horrible key management
> practice out in the wild). And frankly I don't trust anybody who is endorsing
> DNSSEC as the sole solution for all trust problems.
>
> We should do better.
>
> Ciao, Michael.
>

Horrible management of TLS certificates has not caused people to abandon
TLS.

With the HBO outage (what people usually refer to), DNSSEC was doing
exactly what it is suppose to do. What other "horrible" management is there?

Similar configuration mistakes that cause lack of access to TLS sites do
not cause people to reject TLS.

The ability to validate DNS results is critical to Internet security,
and there is no other system that allows validation that the results
from your query are authoritative.

Sure, if an attacker gets a key they can create a fake chain of trust
for anything from that key. That exists with TLS too, only with the TLS
the problem is worse, lot more signing keys to be compromised and when
compromised they can sign a cert for any domain.

Problems like the recent Lenovo or Dell fubar where they put a root cert
in the OS trust store can't happen with DNSSEC.

And with DNSSEC, someone can root all of my DNS servers and they still
will not be able to create a fraudulent record because the keys are not
on them.

It really is a beautiful concept, and I am glad to see it being embraced
in the e-mail server world. It is the right solution to the problem, in
my opinion.

[Wietse Venema]

Viktor Dukhovni:

For the client, maybe this can be configured with "sni=example.net"
(or nexthop) as a policy? I agree that a fully-automated solution
may not be feasible.

> I think we're set for now with Postfix as-is.

Wietse

[Michael Storz]

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.

If you send the recipient domain as SNI the server checks its certs:

- if it only has a default cert, it sends the default cert
- if it has multiple certs, it checks the presented identifiers (SAN of
cert) for a match with the SNI.
* if there is no match, it sends the default cert,
* if there is a match it sends the matching cert.

Therefore, if you send SNI and get back the default cert, there is no
difference to not sending SNI. If you get back a different cert than the
default cert, your reference identifier which you send as SNI is among
the presented identifiers of the cert. Therefore you have a match and
that is exactly what you want.

For the single recipient email I cannot see any possible harm.

If you have a multi-recipient email and

- the domain of all recipients ist the same there is no difference to
the single-recipient email
- if the domains are different and
* if the connection endpoints of the TLS connections are different,
you must create multiple TLS connections and each TLS connection behaves
the same way as in the single recipient email case
* if the connection endpoints are the same
+ you could ignore this and still use a different connection for
every domain as in the case above
+ you could try to optimize the number of connections and use the
domain of the first recipient for SNI and then check for the next
recipient if the domain is included in the presented identifiers
. if yes reuse the TLS connection
. if not open a new connection with that domain as SNI
In both cases you get back either the default cert and maybe a match
or another cert with a match

Therefore if you send SNI you are getting the highest chance for a match
for your reference identifier and therefore for an authenicated TLS
connection. The cost would be the higher number of connections is some
cases. Thats the only harm I can see. But the benefit of more possible
matches is much more important.

Michael

[Alice Wonder]

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?

[Michael Storz]

Am 2015-12-16 16:26, schrieb Alice Wonder:
>
> 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?

The goal ist to prevent an active man-in-the-middle (MITM) attack. To
reach this goal you need an authenticated TLS connection from the SMTP
client to the SMTP server. At the moment you have two possibilities to
authenticate a TLS connection:

- using DNSSEC/DANE which is finally standardized in RFC 7672
- using the traditional PKIX method, which is not standardized and
therefore not really used at the moment

The process of authentication uses two steps

- checking if the public key belongs to the domain
- checking if the domain you use as a reference identifier is related to
the domain from step one (this is the part about SNI and checking the
reference identifier)

For the PKIX method this means you have to verify the certificate (which
includes several steps) and to check if you trust the signer of the
certificte (CA). Only then you can trust that the key really belongs to
the owner of the domain in the certificate (this is only a very
simplified description of the whole process, read the relevant
literature about the problems with this approach). If the certificate is
self-signed or signed by a private CA the certifiacte could as well be
issued by a man-in-the-middle. Using an unauthenticated TLS connection
prevents passive attacks (eavesdropping) but not active attacks.

Therefore certificate authorities do matter for every protocol which
uses TLS and the traditional PKIX method of authentication.

Michael

[Alice Wonder]

The problem is there is no agreed upon list of certificate authorities
that must be used.

So my signed certificate may be signed by a certificate authority your
server doesn't trust.

As there is no opportunity for user interaction when the CA isn't
trusted by a particular server, that's a problem, so they don't require
CA validation.

Hence why DANE is needed to avoid MITM and guarantee encrypted transmission.