Discussion:
TLS support
(too old to reply)
Kurt Roeckx
2014-01-05 12:49:34 UTC
Permalink
Hi,

I've been looking at the current state of TLS support in postfix.
I notice that the documentation on the website says it will
support DANE in the 2.11 version.

DANE will make it possible for us to have mandatory encryption, so
I would like to see that we can get the best out of that.

So one thing I've noticed is that you currently only have settings
for dh512 and dh1024. I would really like to see an option to
have at least 2048 and maybe even 4096 bit DH parameters.
As far as I know you can set anything in the dh512 and dh1024
file, but the documentation doesn't make that clear.

So I've been looking at which ciphers are currently selected. The
documentation (TLS_README) says that log level 0 should log
"summary message on TLS handshake completion" with 2.9. I don't
see any such messages. If I change it to 1, I do get messages as:
Anonymous TLS connection established from [...]: TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)

With smtpd_tls_received_header = yes you also see this in the
headers then:
(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))

It would be nice that it could also say something about the (EC)DH
parameters, and maybe about the other side's certificate.

The documenation about dane says:
| When TLSA records are not found or are all unusable the effective
| security level is "may" or "encrypt" respectively.

So does that mean:
- No TLSA records: may
- TLSA present but unusable: encrypt
- TLSA present and usable: fingerprint for type 3 (and 1), or nexthop, hostname for type 2.

unusable would be a certificate contraint type is 0.
I assume that the "trust-anchor (TA)" is type 2, and end-entity
(EE) is type 3.

(I think it's all documented somewhere, but some parts are
repeated and not exactly the same, and so it's a bit spread
out.)


Kurt
Viktor Dukhovni
2014-01-05 21:18:08 UTC
Permalink
Post by Kurt Roeckx
I've been looking at the current state of TLS support in postfix.
I notice that the documentation on the website says it will
support DANE in the 2.11 version.
Correct. Have not yet had time to write a separate comprehensive
DANE_README.html tutorial. Getting the underlying IETF drafts out
the door has been a higher priority.
Post by Kurt Roeckx
So one thing I've noticed is that you currently only have settings
for dh512 and dh1024. I would really like to see an option to
have at least 2048 and maybe even 4096 bit DH parameters.
As far as I know you can set anything in the dh512 and dh1024
file, but the documentation doesn't make that clear.
See the whole document, but in particular the quick-start section:

http://www.postfix.org/FORWARD_SECRECY_README.html#quick-start
Post by Kurt Roeckx
So I've been looking at which ciphers are currently selected. The
documentation (TLS_README) says that log level 0 should log
"summary message on TLS handshake completion" with 2.9.
If that is still there, that's an error, log level 0 logs nothing
about TLS. The summary log level is log level 1.
Post by Kurt Roeckx
It would be nice that it could also say something about the (EC)DH
parameters, and maybe about the other side's certificate.
The handshake parameters are not reported by the OpenSSL client API,
and the logging would get unwieldy.
Post by Kurt Roeckx
| When TLSA records are not found or are all unusable the effective
| security level is "may" or "encrypt" respectively.
- No TLSA records: may
- TLSA present but unusable: encrypt
Correct. Hence "respectively".
Post by Kurt Roeckx
- TLSA present and usable: fingerprint for type 3 (and 1),
or nexthop, hostname for type 2.
unusable would be a certificate contraint type is 0.
Yes, or some martian value not understood by the implementation,
or bogus digest lengths and/or invalid encodings of certificates
or public keys.
Post by Kurt Roeckx
I assume that the "trust-anchor (TA)" is type 2, and end-entity
(EE) is type 3.
Correct.
Post by Kurt Roeckx
(I think it's all documented somewhere, but some parts are
repeated and not exactly the same, and so it's a bit spread
out.)
Thus the need for a DANE_README.html, any volunteers? All the
required material is scattered about in:

http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-05.html
http://www.postfix.org/postconf.5.html
http://www.postfix.org/TLS_README.html
http://www.postfix.org/FORWARD_SECRECY_README.html
--
Viktor.
Patrick Ben Koetter
2014-01-06 10:33:26 UTC
Permalink
Post by Viktor Dukhovni
Post by Kurt Roeckx
(I think it's all documented somewhere, but some parts are
repeated and not exactly the same, and so it's a bit spread
out.)
Thus the need for a DANE_README.html, any volunteers? All the
http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-05.html
http://www.postfix.org/postconf.5.html
http://www.postfix.org/TLS_README.html
http://www.postfix.org/FORWARD_SECRECY_README.html
I can work on it this and next week, but my English writing will need some
review from a native speaker.

***@rick
--
Patrick Ben Koetter
***@state-of-mind.de
Corey Quinn
2014-01-06 13:46:29 UTC
Permalink
I'll handle editing and review if you'd like.

--Corey
Post by Patrick Ben Koetter
Post by Viktor Dukhovni
Post by Kurt Roeckx
(I think it's all documented somewhere, but some parts are
repeated and not exactly the same, and so it's a bit spread
out.)
Thus the need for a DANE_README.html, any volunteers? All the
http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-05.html
http://www.postfix.org/postconf.5.html
http://www.postfix.org/TLS_README.html
http://www.postfix.org/FORWARD_SECRECY_README.html
I can work on it this and next week, but my English writing will need some
review from a native speaker.
--
Patrick Ben Koetter
Viktor Dukhovni
2014-01-06 15:28:57 UTC
Permalink
Post by Patrick Ben Koetter
Post by Viktor Dukhovni
Thus the need for a DANE_README.html, any volunteers? All the
http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-05.html
http://www.postfix.org/postconf.5.html
http://www.postfix.org/TLS_README.html
http://www.postfix.org/FORWARD_SECRECY_README.html
I can work on it this and next week, but my English writing will need some
review from a native speaker.
Fantastic. One important point to get accross is that TLS security
for MTA SMTP to MX is very much unlike TLS security for HTTP or
even mail client SMTP to static MSA. Even though the TLS protocol
is the same, the MTA SMTP protocol context is so different, that
one MUST first shed most of the mental baggage that one may have
learned from HTTP. For many users the first problem will be letting
go of pre-conceptions.

The second point, which is critical, is that Postfix DANE will
offer only an illusion of security unless the ONE AND ONLY nameserver
in /etc/resolv.conf is 127.0.0.1 (yes, ::1 is also OK). That
nameserver must implement DNSSEC and be configured with a suitable
set of trust anchors. At least the correct trust anchor for the
root zone, plus any additional trust anchors that are stable enough
to configure locally and important enough to not yield control over
those domains to the root.

There need to be appropriate mechanisms handle trust-anchor key
rotation. Some linux packages for unbound come with scripts to
refresh the root trust anchor, I don't know whether these can
also handle other trust-anchors in a similar manner.

So there would need to be a bit of a DNSSEC tutorial as well I'm
afraid. Especially for people who want to operate domains with
DANE veriable MX hosts. They'll need to understand why (with
certificate usage 2) wildcard certs are not a very good idea (MITM
server substitution) and the pros/cons of "2 0 1", "2 1 1", and "3
1 1" TLSA records (it makes little sense to use any of the other
12 valid combinations, and none to use the 12 with certificate
usage 0/1).

They'll also need to understand the key rotation and digest algorithm
agility operational requirements for publishing TLSA records.

The rest, is largely combining the various Postfix docs about DANE
is a single logical document.

Those are my immediate thoughts that I thought would be helpful to
get you started, but you'll discover your own ideas as you go along.

-------------
Post by Patrick Ben Koetter
I'll handle editing and review if you'd like.
Thanks, that would be great.
--
Viktor.
Wietse Venema
2014-01-06 23:17:44 UTC
Permalink
Post by Viktor Dukhovni
Post by Patrick Ben Koetter
Post by Viktor Dukhovni
Thus the need for a DANE_README.html, any volunteers? All the
http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-05.html
http://www.postfix.org/postconf.5.html
http://www.postfix.org/TLS_README.html
http://www.postfix.org/FORWARD_SECRECY_README.html
I can work on it this and next week, but my English writing will need some
review from a native speaker.
Fantastic. One important point to get accross is that TLS security
Another important point: do not edit the HTML files in the Postfix
"html" directory.

Instead, edit the HTML files in the Postfix "proto" directory.

All the hyperlinks to Postfix parameters, map types and README files
are added autmatically with the command

$ make manpages

in the Postfix source tree top-level directory. This creates the
files in the Postfix "html" directory.

Please spell check and validate with http://validator.w3.org/

Wietse
Patrick Ben Koetter
2014-01-10 10:44:04 UTC
Permalink
Viktor,

we're lucky to have Carsten Strotmann on our team (here at sys4). You may know
him for his expertise on DNS. Carsten offered to assist in writing the
DANE_README.

I'd like you/others to go over the following TOC to make sure we cover all
necessary aspects:

- What is DANE

- Benefits of using DANE

- Prerequisites

- DNSSEC
- What is DNSSEC?
- Why does DANE require DNSSEC?
- "a bit of a DNSSEC tutorial..."

- Local Resolver
- DANE will offer only an illusion of security unless the *one and only*
nameserver in /etc/resolv.conf is 127.0.0.1
- trust-anchor key rotation

- Certificate Considerations

- Pros/Cons of "2 0 1", ...

- TLSA Key rotation


- DANE setup with Postfix

- Building a TLS certificate

- Basic TLS/SSL configuration
- Basics + refer to TLS_README for tuning, other policies etc.
- Testing basic TLS functionality

- Configuring DNS-Based Authentication of Named Entities (DANE)
- Creating a TLSA DNS resource record
-> tlsagen
-> Refer to "Pros/Cons of "2 0 1"..."
- Deploying the TLSA DNS RR
- Testing the TLSA DNS resource record
-> posttls-finger

- Enabling DANE support in Postfix SMTP client
- Params, Options, Policies
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane, dane-only

- Verifying DANE
- LOG
- Monitoring

- Troubleshooting

- References


Thank you
Post by Viktor Dukhovni
Post by Patrick Ben Koetter
Post by Viktor Dukhovni
Thus the need for a DANE_README.html, any volunteers? All the
http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-05.html
http://www.postfix.org/postconf.5.html
http://www.postfix.org/TLS_README.html
http://www.postfix.org/FORWARD_SECRECY_README.html
I can work on it this and next week, but my English writing will need some
review from a native speaker.
Fantastic. One important point to get accross is that TLS security
for MTA SMTP to MX is very much unlike TLS security for HTTP or
even mail client SMTP to static MSA. Even though the TLS protocol
is the same, the MTA SMTP protocol context is so different, that
one MUST first shed most of the mental baggage that one may have
learned from HTTP. For many users the first problem will be letting
go of pre-conceptions.
The second point, which is critical, is that Postfix DANE will
offer only an illusion of security unless the ONE AND ONLY nameserver
in /etc/resolv.conf is 127.0.0.1 (yes, ::1 is also OK). That
nameserver must implement DNSSEC and be configured with a suitable
set of trust anchors. At least the correct trust anchor for the
root zone, plus any additional trust anchors that are stable enough
to configure locally and important enough to not yield control over
those domains to the root.
There need to be appropriate mechanisms handle trust-anchor key
rotation. Some linux packages for unbound come with scripts to
refresh the root trust anchor, I don't know whether these can
also handle other trust-anchors in a similar manner.
So there would need to be a bit of a DNSSEC tutorial as well I'm
afraid. Especially for people who want to operate domains with
DANE veriable MX hosts. They'll need to understand why (with
certificate usage 2) wildcard certs are not a very good idea (MITM
server substitution) and the pros/cons of "2 0 1", "2 1 1", and "3
1 1" TLSA records (it makes little sense to use any of the other
12 valid combinations, and none to use the 12 with certificate
usage 0/1).
They'll also need to understand the key rotation and digest algorithm
agility operational requirements for publishing TLSA records.
The rest, is largely combining the various Postfix docs about DANE
is a single logical document.
Those are my immediate thoughts that I thought would be helpful to
get you started, but you'll discover your own ideas as you go along.
-------------
Post by Patrick Ben Koetter
I'll handle editing and review if you'd like.
Thanks, that would be great.
--
Viktor.
--
Patrick Ben Koetter
***@state-of-mind.de
Viktor Dukhovni
2014-01-10 13:52:17 UTC
Permalink
Post by Patrick Ben Koetter
Viktor,
we're lucky to have Carsten Strotmann on our team (here at sys4). You may know
him for his expertise on DNS. Carsten offered to assist in writing the
DANE_README.
Thanks. Very much appreciated.
Post by Patrick Ben Koetter
I'd like you/others to go over the following TOC to make sure we cover all
- What is DANE
- Benefits of using DANE
Since you're documenting DANE for Postfix, I think it is important
in the above two sections to keep the focus on "SMTP Opportunistic
DANE TLS" (even though you also will describe the mandatory
"dane-only" later in the document).

You need to briefly dispel the notion that public CA TLS (aka PKIX,
though PKIX spec also applies to DANE when a trust anchor is used)
is usable without DNSSEC on a large scale for SMTP to MX. It is
not, because with MX indirection the peer name is insecure sans
secure DNS, and since hop-by-hop security is not implied by the
email address, "STARTTLS" is is trivial to downgrade.

DANE for SMTP specifically deals with these problems, and along
the way solves Goedel's problem for CA bundles (any list of
CAs is either inconsistent or incomplete, where inconsistent
means too inclusive to be trustworthy).

Also highlight the need for authentication to be reliable, since
MTAs don't have interactive users to click OK (unlike browsers).

Then add quick-dirty link for client setup and server cert
chain / TLSA RR setup (that will be at the bottom of the
document).
Post by Patrick Ben Koetter
- Prerequisites
- DNSSEC
- What is DNSSEC?
- Why does DANE require DNSSEC?
- "a bit of a DNSSEC tutorial..."
- Local Resolver
- DANE will offer only an illusion of security unless the *one and only*
nameserver in /etc/resolv.conf is 127.0.0.1
- trust-anchor key rotation
- Certificate Considerations
- Pros/Cons of "2 0 1", ...
Right, I only recommend a choice between "2 0 1" and "3 1 1",
everything else is silly (at least for SMTP), but "2 1 1" could be
an option if the TA contains no useful data beyond its key, and is
in fact an intermediate or even root public CA, which might be
re-issued with new expiration dates, ... but an unchanged key.
Post by Patrick Ben Koetter
- TLSA Key rotation
- DANE setup with Postfix
- Building a TLS certificate
- Basic TLS/SSL configuration
- Basics + refer to TLS_README for tuning, other policies etc.
- Testing basic TLS functionality
- Configuring DNS-Based Authentication of Named Entities (DANE)
- Creating a TLSA DNS resource record
-> tlsagen
-> Refer to "Pros/Cons of "2 0 1"..."
- Deploying the TLSA DNS RR
- Testing the TLSA DNS resource record
-> posttls-finger
- Enabling DANE support in Postfix SMTP client
- Params, Options, Policies
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane, dane-only
There are also some DANE related parameters for the
TLS library:

tls_dane_digest_agility = on
tls_dane_digests = sha512 sha256
tls_dane_trust_anchor_digest_enable = yes
Post by Patrick Ben Koetter
- Verifying DANE
- LOG
- Monitoring
- Troubleshooting
- Quick and Dirty configuration

- Client in brief.

DNS and SMTP agent settings.
tls policy table for exceptions:
- non-dane for emergencies (assuming not an MITM attack).
- dane-only

- Server in brief.

Cert chain.
TLSA RR content.
TLSA RR content during key rotation (of EE or TA cert).
Post by Patrick Ben Koetter
- References
Thank you
Thanks again.
--
Viktor.
Wietse Venema
2014-01-10 14:06:11 UTC
Permalink
Post by Viktor Dukhovni
Post by Patrick Ben Koetter
- Troubleshooting
- Quick and Dirty configuration
- Client in brief.
DNS and SMTP agent settings.
- non-dane for emergencies (assuming not an MITM attack).
- dane-only
- Server in brief.
Cert chain.
TLSA RR content.
TLSA RR content during key rotation (of EE or TA cert).
Please follow this quick-start guide with a section that shows what
one can expect to see when Postfix uses TLSA (logging, headers,
other symptoms). This approach has worked well in the FORWARD_README
document.

Wietse
Viktor Dukhovni
2014-01-11 03:38:51 UTC
Permalink
Post by Viktor Dukhovni
There are also some DANE related parameters for the
tls_dane_digest_agility = on
tls_dane_digests = sha512 sha256
tls_dane_trust_anchor_digest_enable = yes
Another triplet of new in 2.11 parameters related to DANE:

- smtp_tls_force_insecure_host_tlsa_lookup

This one is not a good to change from the default of "no",
until all broken name servers are fixed. Set to yes on
today's Internet, mail to microsoft.com, nist.gov, ...
would never make it.

- smtp_tls_trust_anchor_file

This one is a bit like fingerprint security but with CAs. You
can specify a per-site set of trust-anchors (essentially
CAs, but the file can also hold raw public keys).

- tls_wildcard_matches_multiple_labels

This is not really DANE-specific, but allows sites like postini.com
to potentially use DANE with their wild-card certificate which
needs to match multiple labels:

postini.com. IN MX 100 postini.com.s8a1.psmtp.com.

posttls-finger: postini.com.s8a2.psmtp.com[64.18.7.11]:25:
Matched subjectAltName: *.psmtp.com
posttls-finger: postini.com.s8a2.psmtp.com[64.18.7.11]:25
CommonName *.psmtp.com

It is less strict than is common for wilcard cert semantics
in applications, and wilcard certs should play little role
in DANE, with sites being able to mint as many or few certs
as they please. So one might want to try setting this to
"no" and see whether theis is any negative fallout.
--
Viktor.
Loading...