Forward Secrecy in the Postfix SMTP Client
On this page:
http://www.postfix.org/FORWARD_SECRECY_README.html#client_fs
There is:
Once the parameters are in place, update main.cf as follows:
/etc/postfix/main.cf:
smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
smtpd_tls_dh512_param_file = ${config_directory}/dh512.pem
I notice the line starting with 'smtpd_tls_dh1024_param_file' points to
a 2048 file.
Is that correct, or might it be a typo?
thanks.
Re: Forward Secrecy in the Postfix SMTP Client
On 8/9/2015 12:48 PM, Viktor Dukhovni wrote:
On Sun, Aug 09, 2015 at 12:42:00PM -0400, Mike wrote:
On this page:
http://www.postfix.org/FORWARD_SECRECY_README.html#client_fs
There is:
Once the parameters are in place, update main.cf as follows:
/etc/postfix/main.cf:
smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
smtpd_tls_dh512_param_file = ${config_directory}/dh512.pem
These are SMTP server not SMTP client settings (for some reason
your subject line says Client).
I cited the wrong subsection, both as you noted in my text and also the
URL. I should have pointed to
http://www.postfix.org/FORWARD_SECRECY_README.html#quick-start
I notice the line starting with 'smtpd_tls_dh1024_param_file' points to
a 2048 file.
Is that correct, or might it be a typo?
It is not a typo and rationale is explained in the document.
http://www.postfix.org/FORWARD_SECRECY_README.html#server_fs
EDH Server support:
...
Take a few minutes to read more of the document.
I had seen the rationale in the master.cf / submission section. I was
unsure if that same rationale also applied to the main.cf section.
Thanks for confirming it is correct as written.
Re: Forward Secrecy in the Postfix SMTP Client
On Sun, Aug 09, 2015 at 12:42:00PM -0400, Mike wrote:
On this page:
http://www.postfix.org/FORWARD_SECRECY_README.html#client_fs
There is:
Once the parameters are in place, update main.cf as follows:
/etc/postfix/main.cf:
smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
smtpd_tls_dh512_param_file = ${config_directory}/dh512.pem
These are SMTP server not SMTP client settings (for some reason
your subject line says Client).
I notice the line starting with 'smtpd_tls_dh1024_param_file' points to
a 2048 file.
Is that correct, or might it be a typo?
It is not a typo and rationale is explained in the document.
http://www.postfix.org/FORWARD_SECRECY_README.html#server_fs
EDH Server support:
...
Take a few minutes to read more of the document.
--
Viktor.
Re: New TLS Forward Secrecy document
Hi Viktor, Thanks for the reply. Viktor Dukhovni postfix-us...@dukhovni.org writes: On Thu, Jan 02, 2014 at 06:03:40PM -0500, micah wrote: I notice that you are using OpenSSL's private terminology (EDH and EECDH) instead of the standard terminology (DHE and ECDHE). Given cipherlist class names: kEECDH - cipher suites that support Ephemeral ECDH key exchange kEDH- cipher suites that support Ephemeral DH key exchange I'm sorry, but I have no idea what cipherlist class names are, would you mind clarifying what that is, I tried to search the web for those names, but was not able to uncover anything. Thanks, micah
Re: New TLS Forward Secrecy document
On Sun, Jan 05, 2014 at 06:31:46PM -0500, micah wrote: Given cipherlist class names: kEECDH - cipher suites that support Ephemeral ECDH key exchange kEDH- cipher suites that support Ephemeral DH key exchange I'm sorry, but I have no idea what cipherlist class names are, would you mind clarifying what that is, I tried to search the web for those names, but was not able to uncover anything. There's nothing to research. I meant to say cipher suite class names, and these are not surprisingly names of classes of cipher suites. That is names you can use in an OpenSSL cipherlist that match multiple cipher suites. aNULL - anonymous cipher suites aRSA - cipher suites with RSA certificate authentication. eNULL - cipher suites with no encryption kEECDH - cipher suites with EECDH (ECDHE) key exchange. AES- cipher suites that use AES payload encryption. ... each of which matches a set of ciphers suites whose elements have names that correspond to a single combination of algorithms, such as: RC4-SHA AES128-SHA ECDHE-ECDSA-AES256-SHA384 (OpenSSL 1.0.2 or later) $ openssl ciphers -v 'ECDHE-ECDSA-AES256-SHA384:AES128-SHA:RC4-SHA' ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 -- Viktor.
Re: New TLS Forward Secrecy document
Viktor Dukhovni postfix-us...@dukhovni.org writes: On Sun, Jan 05, 2014 at 06:31:46PM -0500, micah wrote: Given cipherlist class names: kEECDH - cipher suites that support Ephemeral ECDH key exchange kEDH- cipher suites that support Ephemeral DH key exchange I'm sorry, but I have no idea what cipherlist class names are, would you mind clarifying what that is, I tried to search the web for those names, but was not able to uncover anything. There's nothing to research. I meant to say cipher suite class names, and these are not surprisingly names of classes of cipher suites. That is names you can use in an OpenSSL cipherlist that match multiple cipher suites. Ok, thank you for clarifying. aNULL- anonymous cipher suites aRSA - cipher suites with RSA certificate authentication. eNULL- cipher suites with no encryption kEECDH - cipher suites with EECDH (ECDHE) key exchange. AES - cipher suites that use AES payload encryption. ... each of which matches a set of ciphers suites whose elements have names that correspond to a single combination of algorithms, such as: Yes, I understand this, now that I know what you are referring to. It is true that right now, kEECDH is a string you can currently pass to openssl ciphers. However, as the [1] footnote in my original message details, along with the series of patches to openssl: the Openssl input, API and output are being changed so *every* occurrence of EDH and EECDH will be changed to use the standard names DHE and ECDHE. it makes sense to have matching Postfix names in parameters and documentation. I completely agree, however it seems we do not agree with the matching names should be. That is precisely why I write this message. The postfix parameter names and documentation should adopt the standardized names that openssl is changing to. As it is written now, the postfix TLS Forward Secrecy Document currently uses the non-standard, proprietary names that are being replaced in Openssl. Changing these names, before postfix is released with these older names, seems like the most prudent thing to do to eliminate confusion. The best I can offer is to also mention ECDHE in the second bullet under http://www.postfix.org/FORWARD_SECRECY_README.html#tls_fs where we say that EDH also DHE, but don't say that EECDH is also ECDHE. I understand the desire to transition the old, non-standard names to the new ones, but I think the better thing to do is to replace *all* instances of EDH and EECDH with the standardized names (DHE and EECDH) and simply note the non-standard, proprietary names as an acceptable alternative, but one that is deprecated. micah pgpDodfdSagdD.pgp Description: PGP signature
Re: New TLS Forward Secrecy document
micah: I completely agree, however it seems we do not agree with the matching names should be. That is precisely why I write this message. The postfix parameter names and documentation should adopt the standardized names that openssl is changing to. As it is written now, the postfix TLS We'll adapt *after* OpenSSL is updated. Wietse
Re: New TLS Forward Secrecy document
Wietse Venema wie...@porcupine.org writes: Postfix has supported forward secrecy for TLS since version 2.2 when the TLS patch was adopted into Postfix. Things have changed a lot since then, both in TLS and in the real world. Viktor wrote up a FORWARD_SECRECY_README that summarizes the Postfix side of things all in one place. Available now: http://www.porcupine.org/postfix-mirror/FORWARD_SECRECY_README.html In the next 24 hours: http://www.postfix.org/FORWARD_SECRECY_README.html Thank you for writing this up. I notice that you are using OpenSSL's private terminology (EDH and EECDH) instead of the standard terminology (DHE and ECDHE). I realize that postfix is using openssl, and so it may seem natural to use those names, but when we are struggling with protocols where interoperability with other tools is critical, eliminating confusion wherever possible is a worthy goal. I don't know why openssl did that, it really introduces confusion all around[0]. Whatever the reason, it is being fixed to remove the confusion entirely[1], and Postfix should adopt the standard names as soon as possible. My suggestion for dealing with this in this FORWARD_SECRECY_README is to change to using the standard terminology and just include a footnote about the non-standard names until those fade from our collective nightmare. Micah 0. especially since https://tools.ietf.org/html/rfc4492 was clearly publicly announced -- they just chose EECDH by analogy with their EDH. Even the (admittedly-retrospective) SSL 3.0 RFC calls it DHE, not EDH: https://tools.ietf.org/html/rfc6101#appendix-A.6... It probably was a result of some pre-TLS ssleay struggle to work with mosaic or something. 1. http://thread.gmane.org/gmane.comp.encryption.openssl.devel/23577/focus=23579 pgpVSDgES1Nir.pgp Description: PGP signature
Re: New TLS Forward Secrecy document
On Thu, Jan 02, 2014 at 06:03:40PM -0500, micah wrote: I notice that you are using OpenSSL's private terminology (EDH and EECDH) instead of the standard terminology (DHE and ECDHE). Given cipherlist class names: kEECDH - cipher suites that support Ephemeral ECDH key exchange kEDH- cipher suites that support Ephemeral DH key exchange it makes sense to have matching Postfix names in parameters and documentation. The best I can offer is to also mention ECDHE in the second bullet under http://www.postfix.org/FORWARD_SECRECY_README.html#tls_fs where we say that EDH also DHE, but don't say that EECDH is also ECDHE. Dare I mention the fact that there are also kECDHe and kECDHr key exchange cipher suite class names in OpenSSL and the first of these has nothing to do EECDH/ECDHE? I think not. :-) My suggestion for dealing with this in this FORWARD_SECRECY_README is to change to using the standard terminology and just include a footnote about the non-standard names until those fade from our collective nightmare. May all your 2014 nightmares be so tame, happy new year! -- Viktor.
Forward secrecy (was: Certificate Error)
nanotek: Still, might be a good time to create my own CA and upgrade to 4096 bit keys/certificates using SHA512 algorithms and make use of some Diffie-Hellman ephemeral elliptic curve parameters for perfect forward secrecy. I've read http://www.postfix.org/TLS_README.html -- Postfix documentation is exceptional by the way -- are there any guides for DHE? There is a work-in-progress document on forward secrecy that covers both EDH and EECDH. It shows how to configure things (the defaults should be sufficient for many applications) and what you can expect to see in logging and message headers. http://www.postfix.org/FORWARD_SECRECY_README.html I am still fixing it for clarity, but it should be accurate. Feedback is welcome. Wietse
Re: Forward secrecy
On 24/12/2013 1:40 AM, Wietse Venema wrote: nanotek: Still, might be a good time to create my own CA and upgrade to 4096 bit keys/certificates using SHA512 algorithms and make use of some Diffie-Hellman ephemeral elliptic curve parameters for perfect forward secrecy. I've read http://www.postfix.org/TLS_README.html -- Postfix documentation is exceptional by the way -- are there any guides for DHE? There is a work-in-progress document on forward secrecy that covers both EDH and EECDH. It shows how to configure things (the defaults should be sufficient for many applications) and what you can expect to see in logging and message headers. http://www.postfix.org/FORWARD_SECRECY_README.html I am still fixing it for clarity, but it should be accurate. Feedback is welcome. Wietse Thanks, Wietse. Much appreciated. I'll put it to use and let you know if I encounter any problems. -- syn.bsdbox.co
RE: Forward secrecy (was: Certificate Error)
On 24/12/2013 2:09 AM, Viktor Dukhovni wrote: On Tue, Dec 24, 2013 at 01:29:38AM +1100, nanotek wrote: Still, might be a good time to create my own CA and upgrade to 4096 bit keys/certificates You can deploy 4096-bit RSA key if it makes you feel more cool, but there is little point in going beyond 2048-bit RSA at this time. The further you stray away from current practice into the land of extreme cryptography, the more likely you are to run into interoperability problems, without any real security gains. You're right; I'll keep 4096 bit for private data-, and key-encipherment and restrict service keys to 2048. using SHA512 algorithms TLSv1 and TLSv1.2 does not support negotiation of digest algorithms. Deploying digests beyond SHA1 will cause interoperability problems with systems that don't yet support the SHA2 family. I was just reading into this as I just upgraded to OpenSSL 1.0.1e (FreeBSD base system still installs 0.9.8y). I thought v1.x supported SHA256 cipher suites. Thanks for making me aware, Viktor. and make use of some Diffie-Hellman ephemeral elliptic curve parameters for perfect forward secrecy. This is enabled in Postfix = 2.8 by default. If you stuck with 2.6 or 2.7, see the new forward secrecy document. I'm running 2.11. Wietse provided the link, which I've read. It appears to contain all necessary intel. We obviously don't know which is stronger against hypothetical unpublished attacks, EDH at 2048-bits or the P-256 curve. Feel free to roll the dice. Against publically known attacks P-256 is both more secure and more computationally efficient than 2048-bit EDH. I think 384-bit ECDSA keys might be my choice then? I've read http://www.postfix.org/TLS_README.html -- Postfix documentation is exceptional by the way Thanks for the praise. It's deserved; thank you all for your great work! -- syn.bsdbox.co
Re: Forward secrecy (was: Certificate Error)
On Tue, Dec 24, 2013 at 03:00:37AM +1100, nanotek wrote: We obviously don't know which is stronger against hypothetical unpublished attacks, EDH at 2048-bits or the P-256 curve. Feel free to roll the dice. Against publically known attacks P-256 is both more secure and more computationally efficient than 2048-bit EDH. I think 384-bit ECDSA keys might be my choice then? I don't have any interoperability information for NIST P-384 (i.e. secp384r1). Like its P-256 cousin it is part of Suite B, and thus generally also supported by software that supports P-256, but it likely not as widely used as P-256. If there are any practical unpublished attacks on P-256, one might guess they would be due to the curve being cooked to be vulnerable. In that case, it would seem prudent to assume that P-384 is also suspect. If you're sufficiently paranoid, there is nothing you can trust. I don't see any compelling reason to prefer P-384 over P-256, but also know of no reasons to avoid it. P-384 has higher CPU cost, but this is generally tolerable in MTAs, since unlike web servers the SMTP connection rate is generally well below CPU performance limits. -- Viktor.
Re: Forward secrecy
On 24/12/2013 3:19 AM, Viktor Dukhovni wrote: On Tue, Dec 24, 2013 at 03:00:37AM +1100, nanotek wrote: We obviously don't know which is stronger against hypothetical unpublished attacks, EDH at 2048-bits or the P-256 curve. Feel free to roll the dice. Against publically known attacks P-256 is both more secure and more computationally efficient than 2048-bit EDH. I think 384-bit ECDSA keys might be my choice then? I don't have any interoperability information for NIST P-384 (i.e. secp384r1). Like its P-256 cousin it is part of Suite B, and thus generally also supported by software that supports P-256, but it likely not as widely used as P-256. If there are any practical unpublished attacks on P-256, one might guess they would be due to the curve being cooked to be vulnerable. In that case, it would seem prudent to assume that P-384 is also suspect. If you're sufficiently paranoid, there is nothing you can trust. I don't see any compelling reason to prefer P-384 over P-256, but also know of no reasons to avoid it. P-384 has higher CPU cost, but this is generally tolerable in MTAs, since unlike web servers the SMTP connection rate is generally well below CPU performance limits. Thanks, Viktor. I will conduct some research and weigh my options. Whatever choice, a significant improvement on my current cryptographic protocol will be made. -- syn.bsdbox.co
Re: Forward secrecy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23-12-13 15:40, Wietse Venema wrote: nanotek: Still, might be a good time to create my own CA and upgrade to 4096 bit keys/certificates using SHA512 algorithms and make use of some Diffie-Hellman ephemeral elliptic curve parameters for perfect forward secrecy. I've read http://www.postfix.org/TLS_README.html -- Postfix documentation is exceptional by the way -- are there any guides for DHE? There is a work-in-progress document on forward secrecy that covers both EDH and EECDH. It shows how to configure things (the defaults should be sufficient for many applications) and what you can expect to see in logging and message headers. http://www.postfix.org/FORWARD_SECRECY_README.html I am still fixing it for clarity, but it should be accurate. Feedback is welcome. After reading, I'm having some questions. The document states that forward secrecy is supported by default on recent postfix installs. However, the quick-start still has some settings that apparently need tweaking. Setting 'smtpd_tls_eecdh_grade = strong' is already available as default (tested with postfix 2.10), so no actual work here. Setting the files (and refreshing them using a cronjob) specified by 'smtpd_tls_mumble_param_file' is a bit unclear though. The default for these params is empty, and setting them does not really show a different behavior in postfix (i.e. using different ciphers and keys) as far as visible from the logged information. But since forward secrecy is supported by default, what does it help to specify these params, and re-generate them once in a while? I've no deep ssl knowledge, but the smtpd_tls_dh1024_param_file postconf documentation seems to indicate that openssl distributes some kind of defaults for these contents? Maybe it's a nice idea to make the forward secrecy and/or postconf documentation a bit verbose on how this works, and what benefits manual generation of these params has? Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSuGmkAAoJEJPfMZ19VO/1FbIP/jKzjUXPTGQLigTS5gZZzJA+ cEOuokXnYsUxcsce/kLfYvY0nPMI+YsByAPtcde8aNQ0efGJGI/sol4cfeJ2aXj0 ZGp3yUVN0RY+vcAdCvfL5Exa5nVM4UxMHfYuwJElZcid0ZpS/46D32EBZStq39n7 WbdPOqM2L3ey1PtsJZ4U9V0LSSz0uDfLTQRxtpK2nQJloPZHHShlWRZLsW3Sny4H UdUdMijR8tpItOeLedaxmCeoBRyNEYxO++J+PRVp4feeeUVUicyU4CwUkx/wbS13 mE5EUttUmOU5GYF34B+9z+HdpyecnZjlr1s51Sfb5pKwSid6PxIeuNS6IvsgvSDQ N0fP0wMNcTpgyDM196TctZc9OMtjhsUntXk90EnS34fOfEomjduXBHVGabZ+FARw /pmJWeGNPdi7WtZJ/Ptr8ZgzdiIfZhqEkJWL5nhdCPzZGBX/2aI1ZRk236guhRkv HOi6sRzrWw/iDdbfjbb31XqV4fsXCBUQ07SnVorCGcckt8PA5+KG6o/LRynhVK6r RdlDs7iKGjQtHN2/SgKvgrenSxUYXyuHaN6hH+yihKZJ4JwHVTcDOarfUBTTJpi1 lr/AWQcKDHau5QtVr6s/YlzcRyv50ejgecViIfNcuwYjZoVgAVrGCfT7NJhcRA5H 2lxFvOTrFKxlvFlBg3Mx =QrH8 -END PGP SIGNATURE-
Re: Forward secrecy
Tom Hendrikx: Setting the files (and refreshing them using a cronjob) specified by 'smtpd_tls_mumble_param_file' is a bit unclear though. The default for these params is empty, and setting them does not really show a different behavior in postfix (i.e. using different ciphers and keys) as far as visible from the logged information. But since forward secrecy is supported by default, what does it help to specify these params, and re-generate them once in a while? I've no Note: greater security against pre-computation attacks against EDH can be obtained by periodically regenerating the EDH parameters as above (an hourly or daily cron job running as root can automate this task). The parameter files are not secret, after all these are sent to all SMTP clients in the clear. Mode 0644 is fine. However, this comment is (still) in the wrong place. It should precede the commands that compute the parameters and that set smtpd_tls_mumble_param_file stuff. Wietse
Re: Forward secrecy
On Mon, Dec 23, 2013 at 05:49:40PM +0100, Tom Hendrikx wrote: I am still fixing it for clarity, but it should be accurate. Feedback is welcome. After reading, I'm having some questions. s/reading/skimming/ :-) The document states that forward secrecy is supported by default on recent postfix installs. However, the quick-start still has some settings that apparently need tweaking. They don't *need* tweaking. However, the tweaked settings are *recommended. Setting 'smtpd_tls_eecdh_grade = strong' is already available as default (tested with postfix 2.10), so no actual work here. As stated. Setting the files (and refreshing them using a cronjob) specified by 'smtpd_tls_mumble_param_file' is a bit unclear though. The default for these params is empty, and setting them does not really show a different behavior in postfix (i.e. using different ciphers and keys) as far as visible from the logged information. http://www.postfix.org/FORWARD_SECRECY_README.html#server_fs ... Postfix = 2.2 support 1024-bit-prime EDH out of the box, with no additional configuration, but you may want to override the default prime to be 2048 bits long, and you may want to regenerate your primes periodically. But since forward secrecy is supported by default, what does it help to specify these params, and re-generate them once in a while? The default non-export prime is 1024 bits. As explained in the document, you should consider using a 2048 bit non-export prime. The best-attacks on prime EDH are pre-computation attacks, where one spends a bunch of time computing a bunch of data about a particular prime, and is then able to quickly solve the underlying problem much faster for any input. Though prime lengths are chosen based such pre-computation attacks (rule of thumb is that for equivalent security EDH primes should be about as long as RSA moduli) which are believed to be out of reach for 2048 bit primes and perhaps still out of reach even for 1024 bit primes, one can make the attacks much less attractive by frequently generating new primes independently at each site. The compiled-in default prime in the Postfix source code is perhaps within reach of the best-funded adversaries, who may have performed the requisite pre-computation. Primes you generate on your server, and use for a short time are unlikely to warrant the extraordinary cost of the pre-computation attack. I've no deep ssl knowledge, but the smtpd_tls_dh1024_param_file postconf documentation seems to indicate that openssl distributes some kind of defaults for these contents? I don't believe that OpenSSL provides default parameters, but Postfix does. Maybe it's a nice idea to make the forward secrecy and/or postconf documentation a bit verbose on how this works, and what benefits manual generation of these params has? The more advanced material we put in the document, the more intimidating it will be for the average reader. But of course an empty document is not optimal, so we have to aim for the middle. There is a range of reader sophistication we can support, it is a trade-off between readable hands-on knowledge and a more detailed, but technically demanding presentation of the rationale. -- Viktor.
Re: Forward secrecy
Viktor Dukhovni: On Mon, Dec 23, 2013 at 05:49:40PM +0100, Tom Hendrikx wrote: I am still fixing it for clarity, but it should be accurate. Feedback is welcome. After reading, I'm having some questions. s/reading/skimming/ :-) In this section, the commands that compute the parameters PRECEDE the text that says why one might want to do this. This is not a skimming error, it is a presentation error. Wietse
Re: Forward secrecy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23-12-13 18:30, Viktor Dukhovni wrote: On Mon, Dec 23, 2013 at 05:49:40PM +0100, Tom Hendrikx wrote: I am still fixing it for clarity, but it should be accurate. Feedback is welcome. After reading, I'm having some questions. s/reading/skimming/ :-) The document states that forward secrecy is supported by default on recent postfix installs. However, the quick-start still has some settings that apparently need tweaking. They don't *need* tweaking. However, the tweaked settings are *recommended. Setting 'smtpd_tls_eecdh_grade = strong' is already available as default (tested with postfix 2.10), so no actual work here. As stated. Setting the files (and refreshing them using a cronjob) specified by 'smtpd_tls_mumble_param_file' is a bit unclear though. The default for these params is empty, and setting them does not really show a different behavior in postfix (i.e. using different ciphers and keys) as far as visible from the logged information. http://www.postfix.org/FORWARD_SECRECY_README.html#server_fs ... Postfix = 2.2 support 1024-bit-prime EDH out of the box, with no additional configuration, but you may want to override the default prime to be 2048 bits long, and you may want to regenerate your primes periodically. But since forward secrecy is supported by default, what does it help to specify these params, and re-generate them once in a while? The default non-export prime is 1024 bits. As explained in the document, you should consider using a 2048 bit non-export prime. The best-attacks on prime EDH are pre-computation attacks, where one spends a bunch of time computing a bunch of data about a particular prime, and is then able to quickly solve the underlying problem much faster for any input. Though prime lengths are chosen based such pre-computation attacks (rule of thumb is that for equivalent security EDH primes should be about as long as RSA moduli) which are believed to be out of reach for 2048 bit primes and perhaps still out of reach even for 1024 bit primes, one can make the attacks much less attractive by frequently generating new primes independently at each site. The compiled-in default prime in the Postfix source code is perhaps within reach of the best-funded adversaries, who may have performed the requisite pre-computation. Primes you generate on your server, and use for a short time are unlikely to warrant the extraordinary cost of the pre-computation attack. I've no deep ssl knowledge, but the smtpd_tls_dh1024_param_file postconf documentation seems to indicate that openssl distributes some kind of defaults for these contents? I don't believe that OpenSSL provides default parameters, but Postfix does. Maybe it's a nice idea to make the forward secrecy and/or postconf documentation a bit verbose on how this works, and what benefits manual generation of these params has? The more advanced material we put in the document, the more intimidating it will be for the average reader. But of course an empty document is not optimal, so we have to aim for the middle. As stated, I assumed that the default primes came from openssl, based on the smtpd_tls_dh1024_param_file description in postconf(5). While reading 'using the exact same parameter sets as distributed with other TLS packages', I was assuming 'other TLS packages' to be other (non-postfix, non-SMTP) software packages also using openssl. After another re-read of the forward secrecy document (and from your reply), I now found the part that states that the default primes are postfix builtins. I missed this link. So it doesn't have to be more technical or advanced. There were some connections between dots missing in the higher level picture. Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSuHsrAAoJEJPfMZ19VO/1MY0P/RkJMxLYu77l8QVfQjuwQdk1 4xgMXiyR0IC8tSKFuulwX/sl+YoFcv2wkjupx0ZwTkVg32feccAUgnzy3wVfe3UM Di5sxIdNq7M2MOb/O3nuoGkKiFDTtd/PXpInI6iLtKL9ADKXPwsbikQda1BEbV++ lO9BsVA1sJsAJOl40nOvx639cFQCEoLyAkuIgk6dZ//7sn1jmIFpYnZhkFvPo2rT Y+3xwGtK+kz2E/b2uutkCO203iCf6hSkyV/jSF2rHl9L/iOkH2ohwt3ICrlH3r38 9Q3TUeMkJzWrHC1ME+LHA5bPhmKdtFsPywZHCWEMK/91U1EQSw8MI6JLHwiC9SZQ JspWkm2JroIrkHl1mKHWi3IazI2hRTgjhmGwkaHy8+m3Cvkq5u9W8jEIBQ045luF gKnCQdaDnfA0htg1dGmvpFItQeddraG+7DcXFDKtPny/mo3oTfAoSgiO3dKIjEDm NihRXgJAtfJRXZG+vLGW0G/+h1DHT5u+l0l9W+TntJi9F2gBk1L6Lz+RSH9Jg5Cc WBAvu2FH1HpoiTNKfdJu3Oi8P0PaSIbnwtODWZ0VVaRVT+YQgGkgjyMcMsvJkEF7 WknGNWBGk5/2n5/x7E/yX1VIV0416ehZSom0C/eBUZxCWAiidZwrRB+hQrcqGJUU UfgkVU/WR+i9bBSxByEa =i2Yp -END PGP SIGNATURE-
Re: Forward secrecy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23-12-13 18:40, Wietse Venema wrote: Viktor Dukhovni: On Mon, Dec 23, 2013 at 05:49:40PM +0100, Tom Hendrikx wrote: I am still fixing it for clarity, but it should be accurate. Feedback is welcome. After reading, I'm having some questions. s/reading/skimming/ :-) In this section, the commands that compute the parameters PRECEDE the text that says why one might want to do this. The text currently reads like: - - you need to generate the params files once - - for greater security, re-generate every now and then The improved security that is gained in the first step is not obvious, which is why I went looking for the details on the params that Postfix uses when the settings are left untouched. You might want to make it clearer that providing customized params is more secure than using the builtins. After that, running a cronjob to refresh them is another improvement. Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSuH0qAAoJEJPfMZ19VO/18wsQAIwzLUl26Q6+j43vXudQpEq2 x8JUt/jjTcRz+PkurynM51YLlmikxzhwC3J/reUvp2zSvHojOAsbomDdp6NN72Km eJdvxSgxc5i05tcoPxtoUZ3aKZUHHFdQ/p/HtnG2zXiU77AWnBzPPBwaZd0qo0f0 Ao22oL68qltuc23APMSYI78acwLFZO/X3Lky+UquyPiwn8qK1JkX3WtzOwsTiNX6 Xv4taIxLSn6sje3DCyWv2lAX0mPTo6B9mKzi7zO1PyUtym/jBo/6WUbW9QxB8ZWC D3hRVkarDdUlWHPOHx1P3nkaA9aiZgy93rVCT0yrB14KS57GvGCBptjo36QHzsvP QUSPo79jjIL/Z3YE+g/HbonFMiHdP0vCioFVU8rgRBZXH1/UbdKHu7eJxxgR6Ggm GssbJkz3hx+JJNzXJcrPjlCrERn9cROKIY0gkE0shjMMcgUG41H9OGBR8GzEOYvm wUOoORAkzaJddeApRrEPGQqQcnlCRulbkQYk8UmnkxH+/P+YSHZqbMXFbxOZzW6Z +5ueiasIxlXA3+Dgmj0xlpOsWFRArFiJLBxfpvkE9Cl/ZhBV31t6DR09doCJznvn 5fFS803QEiwVPuQc0OGg7xYJUG4iDv5gqRxZh27Zuzz2SF5zKxMzTYb7xBxcJCqf QGxvbqtkzTpKC1tE5wxv =bwAN -END PGP SIGNATURE-
Re: Forward secrecy
Tom Hendrikx: So it doesn't have to be more technical or advanced. There were some connections between dots missing in the higher level picture. Please check out the updated text at http://www.porcupine.org/postfix-mirror/FORWARD_SECRECY_README.html#quick-start This clarifies what is/isn't optional and why one might want to make some change. Only those who want the gory details should have to consume the entire document. Wietse
Re: Forward secrecy
Am 23.12.2013 13:13 schrieb Wietse Venema: Please check out the updated text at http://www.porcupine.org/postfix-mirror/FORWARD_SECRECY_README.html#quick-start This clarifies what is/isn't optional and why one might want to make some change. Only those who want the gory details should have to consume the entire document. I read up to the bottom. I find the Untrusted/Trusted/Verified explanation very usefull. But I'm still unsure about what an SMTP client could do to change a remote servers state from Trusted to Verified. (or what's wrong on a server that is only Trusted but not Verified) Andreas
Re: Forward secrecy
Andreas Schulze: Am 23.12.2013 13:13 schrieb Wietse Venema: Please check out the updated text at http://www.porcupine.org/postfix-mirror/FORWARD_SECRECY_README.html#quick-start This clarifies what is/isn't optional and why one might want to make some change. Only those who want the gory details should have to consume the entire document. I read up to the bottom. I find the Untrusted/Trusted/Verified explanation very usefull. But I'm still unsure about what an SMTP client could do to change a remote servers state from Trusted to Verified. The text says: Trusted (peer certificate signed by trusted CA, unverified peer name) Verified (peer certificate signed by trusted CA, verified peer name) The difference is that the client verifies that the name(s) in the certificate match with the name of the host that the client wanted to connect to. TLS_README goes into the details of verification. (or what's wrong on a server that is only Trusted but not Verified) You could be talking to the wrong server, some man in the middle, or anything else than the desired host. Wietse
Re: Forward secrecy
On Mon, Dec 23, 2013 at 09:45:45PM +0100, Andreas Schulze wrote: I read up to the bottom. I find the Untrusted/Trusted/Verified explanation very useful. Good. But I'm still unsure about what an SMTP client could do to change a remote servers state from Trusted to Verified. If you must-have MITM protection for a particular destination, configure in smtp_tls_policy_maps a suitable TLS security level that unconditionally verifies the server, such as: - fingerprint - secure - dane-only (**) Or to authenticate all servers opportunistically via DANE TLSA records, set: smtp_tls_security_level = dane (*) (or what's wrong on a server that is only Trusted but not Verified) If mail delivery proceeded anyway, nothing is wrong: Postfix was not configured to verify the server certificate. This is the norm, MX record indirection makes it impossible to verify SMTP servers without explicit policy entries or help from DNSSEC (hence all the work to implement DANE support in Postfix 2.11). If mail delivery did not proceed, then the server certificate did not contain any of the expected names. -- Viktor. (*) Requires Postfix 2.11 on a platform with OpenSSL 1.0.0 or greater, with EC support not disabled by the vendor. Also requires minimal DNSSEC support in libresolv (the DO and AD bits must be implemented and the option RES_USE_DNSSEC must be defined). For actual security the MTA needs a DNSSEC validating caching nameserver on localhost. Systems with DNSSEC validated MX records and DNSSEC validated TLSA records for the MX hosts will be subject to mandatory TLS authentication. Other systems will be subject to opportunistic TLS. (**)As above, but secure TLSA RRs are required.
Re: New TLS Forward Secrecy document
On Wed, 18 Dec 2013 15:15:34 -0500 (EST) wie...@porcupine.org (Wietse Venema) wrote: Postfix has supported forward secrecy for TLS since version 2.2 when the TLS patch was adopted into Postfix. Things have changed a lot since then, both in TLS and in the real world. Viktor wrote up a FORWARD_SECRECY_README that summarizes the Postfix side of things all in one place. Available now: http://www.porcupine.org/postfix-mirror/FORWARD_SECRECY_README.html In the next 24 hours: http://www.postfix.org/FORWARD_SECRECY_README.html Wietse Wietse, Viktor Thanks for this, it's a great help. Cheers
New TLS Forward Secrecy document
Postfix has supported forward secrecy for TLS since version 2.2 when the TLS patch was adopted into Postfix. Things have changed a lot since then, both in TLS and in the real world. Viktor wrote up a FORWARD_SECRECY_README that summarizes the Postfix side of things all in one place. Available now: http://www.porcupine.org/postfix-mirror/FORWARD_SECRECY_README.html In the next 24 hours: http://www.postfix.org/FORWARD_SECRECY_README.html Wietse
