Discussion:
DANE, DNSSEC, GnuTLS, Postfix, Exim
(too old to reply)
Bry8 Star
2013-01-13 07:34:24 UTC
Permalink
Hi,
When can we expect a Postfix release, that will support DANE
protocol ? so that it(postfix) can verify (using DANE & DNSSEC
protocols) the signed (and free) SSL/TLS certificates(cert) (or
fingerprints) which we can pre-add in TLSA, (CERT, HASTLS, etc) DNS
(DNSSEC) records, and then it(postfix) will use those(cert) for
secure (smtp) communication, and to verify SMTP servers.

Currently (Jan 12, 2013), the last+stable GnuTLS, now supports DANE,
(and as of right now, OpenSSL (or any openssl modules) yet does not
support DANE). Can postfix utilize DANE libraries from gnutls for DANE ?

And, it seems "Exim" (last+stable version) can already use server's
DNSSEC supported local DNS resolver/server software, and so it(Exim)
is able to show/add header info like "sender host verified by DNSSEC
(AD)" in "Received:" meta/header, if DNSSEC protocol based
authentication succeeded, or "host not verified by DNSSEC" message
in header when failed:
http://jpmens.net/2012/06/07/exim-mta-with-dnssec-verification-of-sender/
(AD = Authenticated Data).
And Exim also uses (or, can use) GnuTLS, (other than OpenSSL).

The DnsSec-Tools.Org site shares PATCH (developed by Sparta) for
(older) Postfix (and other software) to support DNSSEC, can someone
expert apply it(patch) on the last+stable postfix ?
http://www.dnssec-tools.org/howtos/postfix-2.3.x-dnssec-howto.txt

Is there any other patch for postfix ? (for dane and dnssec
functionalities).

Thank you (in advance),
-- Bright Star.



References / More info:

DANE (DNS-based Authentication of Named Entities) :
https://datatracker.ietf.org/wg/dane/

https://wiki.mozilla.org/Security/DNSSEC-TLS-details

http://www.dnssec.net/software

Compare MTA, MSA, etc:
http://en.wikipedia.org/wiki/Comparison_of_mail_servers

Exim : ( Google+ ) :
https://plus.google.com/101257968735428844827
https://plus.google.com/101257968735428844827/posts/hbvE6f9nYuq

https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/

https://www.dnssec-tools.org/wiki/index.php/Main_Page

http://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec

http://www.internetsociety.org/deploy360/resources/dane/

http://www.gnutls.org/manual/gnutls.html
http://www.gnutls.org/manual/html_node/Verifying-a-certificate-using-DANE-_0028DNSSEC_0029.html

http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Tools

https://www.dnssec-deployment.org/wiki/index.php/Tools_and_Resources

https://addons.mozilla.org/en-us/firefox/addon/dnssec-validator/

https://addons.mozilla.org/en-us/firefox/addon/extended-dnssec-validator/

http://www.internetsociety.org/deploy360/blog/2013/01/verisign-labs-dane-demonstration-page-and-test-sites/

http://www.isc.org/software/bind/dnssec

http://www.nlnetlabs.nl/projects/dnssec-trigger/

http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_15-1/151_dane.html

https://github.com/pieterlexis/swede

http://dane.verisignlabs.com/
http://tools.verisignlabs.com/

http://dyn.com/dane-dns-server-authentication-ca-flaws-ssl-security/

https://www.dns-oarc.net/oarc/services/odvr

http://www.internetsociety.org/deploy360/resources/hashslinger-a-tool-for-creating-tlsa-records-for-dane/

DNSSEC:
RFC 5910: Domain Name System (DNS) Security Extensions Mapping for
the Extensible Provisioning Protocol (EPP)
RFC 4033: DNS Security Introduction and Requirements
RFC 4034: Resource Records for the DNS Security Extensions
RFC 4035: Protocol Modifications for the DNS Security Extensions
RFC 4641: DNSSEC Operational Practices
RFC 5155: (March 2008) introduces an alternative resource record,
NSEC3, which provides additional measures against zone enumeration
and permits gradual expansion of delegation-centric zones.
Stefan Sels
2013-01-13 08:43:49 UTC
Permalink
Hi Bright Star,

I like the idea of a CAless TLS trust layer with DNS(sec) based
certificates. I stumbled about DANE a while ago, it is working on some
browsers (chrome, firefox will probably follow; there is a add-on like
the dnssec plugin:
http://hu.reddit.com/r/netsec/comments/12up0t/dane_patrol_firefox_addon_fork_of_certificate/)
yet.

DANE is a marketing name of RFC 6698 https://tools.ietf.org/html/rfc6698

To get an adpotion in the mail world (and stuff like that, with 2-3
specifications involved, tls, dns and smtp) takes time and is usually
painfull (too many broken MTAs).

First, I never saw postfix compiled against gnutls, google showed some
bug reports regarding that, please correct me if I am wrong about that.

So if openssl would support DANE, life would be a lot easier. It is
similar to SNI (server name indication) gnutls was first, but after
openssl integrated it, adoption started to accelerate.

I see two ways to reach a first milestone on your goal

a) make postfix compile against gnutls
b) wait on the integration of DANE in openssl

I would favor b), just because IMHO it is probably faster then a),
having postfix compile/linking against two TLS library would not do
harm, it is just a lot of work. And encryption and authentication is not
something you want to have broken.

But the above scenarios would just be a first step, then you would need
to improve/add the DANE/TLS handling within postfix, make sure nothing
of the current TLS/SSL handling brakes during the integration.

I would be happy if we could improve postfix with DANE, I am just not a
good enough coder to do so. I would be willing to help with all the
other stuff (compiling, testing, documentation) of the process.

Greetings,
Stefan
Post by Bry8 Star
Hi,
When can we expect a Postfix release, that will support DANE
protocol ? so that it(postfix) can verify (using DANE & DNSSEC
protocols) the signed (and free) SSL/TLS certificates(cert) (or
fingerprints) which we can pre-add in TLSA, (CERT, HASTLS, etc) DNS
(DNSSEC) records, and then it(postfix) will use those(cert) for
secure (smtp) communication, and to verify SMTP servers.
Currently (Jan 12, 2013), the last+stable GnuTLS, now supports DANE,
(and as of right now, OpenSSL (or any openssl modules) yet does not
support DANE). Can postfix utilize DANE libraries from gnutls for DANE ?
And, it seems "Exim" (last+stable version) can already use server's
DNSSEC supported local DNS resolver/server software, and so it(Exim)
is able to show/add header info like "sender host verified by DNSSEC
(AD)" in "Received:" meta/header, if DNSSEC protocol based
authentication succeeded, or "host not verified by DNSSEC" message
http://jpmens.net/2012/06/07/exim-mta-with-dnssec-verification-of-sender/
(AD = Authenticated Data).
And Exim also uses (or, can use) GnuTLS, (other than OpenSSL).
The DnsSec-Tools.Org site shares PATCH (developed by Sparta) for
(older) Postfix (and other software) to support DNSSEC, can someone
expert apply it(patch) on the last+stable postfix ?
http://www.dnssec-tools.org/howtos/postfix-2.3.x-dnssec-howto.txt
Is there any other patch for postfix ? (for dane and dnssec
functionalities).
Thank you (in advance),
-- Bright Star.
https://datatracker.ietf.org/wg/dane/
https://wiki.mozilla.org/Security/DNSSEC-TLS-details
http://www.dnssec.net/software
http://en.wikipedia.org/wiki/Comparison_of_mail_servers
https://plus.google.com/101257968735428844827
https://plus.google.com/101257968735428844827/posts/hbvE6f9nYuq
https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/
https://www.dnssec-tools.org/wiki/index.php/Main_Page
http://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec
http://www.internetsociety.org/deploy360/resources/dane/
http://www.gnutls.org/manual/gnutls.html
http://www.gnutls.org/manual/html_node/Verifying-a-certificate-using-DANE-_0028DNSSEC_0029.html
http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Tools
https://www.dnssec-deployment.org/wiki/index.php/Tools_and_Resources
https://addons.mozilla.org/en-us/firefox/addon/dnssec-validator/
https://addons.mozilla.org/en-us/firefox/addon/extended-dnssec-validator/
http://www.internetsociety.org/deploy360/blog/2013/01/verisign-labs-dane-demonstration-page-and-test-sites/
http://www.isc.org/software/bind/dnssec
http://www.nlnetlabs.nl/projects/dnssec-trigger/
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_15-1/151_dane.html
https://github.com/pieterlexis/swede
http://dane.verisignlabs.com/
http://tools.verisignlabs.com/
http://dyn.com/dane-dns-server-authentication-ca-flaws-ssl-security/
https://www.dns-oarc.net/oarc/services/odvr
http://www.internetsociety.org/deploy360/resources/hashslinger-a-tool-for-creating-tlsa-records-for-dane/
RFC 5910: Domain Name System (DNS) Security Extensions Mapping for
the Extensible Provisioning Protocol (EPP)
RFC 4033: DNS Security Introduction and Requirements
RFC 4034: Resource Records for the DNS Security Extensions
RFC 4035: Protocol Modifications for the DNS Security Extensions
RFC 4641: DNSSEC Operational Practices
RFC 5155: (March 2008) introduces an alternative resource record,
NSEC3, which provides additional measures against zone enumeration
and permits gradual expansion of delegation-centric zones.
Wietse Venema
2013-01-13 15:08:50 UTC
Permalink
Post by Bry8 Star
When can we expect a Postfix release, that will support DANE
protocol ?
A new feature is implemented when there is the time and the need
to do so. Pluggable features such as DKIM and policies could be
added in one development cycle, while more invasive features such
as DSN and MIME were added in the course of multiple cycles.

BTW Postfix should not be used with GnuTLS: last time I looked,
they wrote to stderr and terminated the process after some error.
A well-behaved library returns an error code to the application.

Wietse
Viktor Dukhovni
2013-01-13 18:22:03 UTC
Permalink
Post by Wietse Venema
Post by Bry8 Star
When can we expect a Postfix release, that will support DANE
protocol ?
A new feature is implemented when there is the time and the need
to do so. Pluggable features such as DKIM and policies could be
added in one development cycle, while more invasive features such
as DSN and MIME were added in the course of multiple cycles.
The DANE specification is still a bit bleeding edge. Paragraph 4 of

https://tools.ietf.org/html/rfc6698#section-1.3

states

... Note that this document does not cover how to associate certificates
with domain names for application protocols that depend on SRV, NAPTR,
and similar DNS resource records. It is expected that future documents
will cover methods for making those associations, and those documents
may or may not need to update this one.

Since MX records used with SMTP are essentially a simple form of
SRV records, there is perhaps not yet a clear specification for
associating TLS certicates with SMTP servers.

SMTP with TLS has not received much attention from the IETF. There
is little discussion of the interaction between certificate names
and MX records in <https://tools.ietf.org/html/rfc3207#section-4.1>:

- A SMTP client would probably only want to authenticate an SMTP
server whose server certificate has a domain name that is the
domain name that the client thought it was connecting to.

- A publicly-referenced SMTP server would probably want to accept
any verifiable certificate from an SMTP client, and would possibly
want to put distinguishing information about the certificate in
the Received header of messages that were relayed or submitted
from the client.

A host may provide both HTTPS and SMTP services, and may reasonably
not want or be able to use the same (private-key, public cert) pair
for both HTTPS and SMTP. However, the traditional name binding in
PKIX X.509 certificates is to a hostname, not a (service, hostname)
pair. Thus, while one may expect that SMTP server certificates should
have a subjectAltName of:

_smtp.<hostname>

as in https://tools.ietf.org/html/rfc4985#section-2, in practice
no SMTP certificates bear such (subjectAlt) names, and no SMTP clients
expect them.

Finally, there is not yet a widely deployed client API for DNSSEC.
The legacy BSD libresolv does not provide any DNSSEC information.
An SMTP client that wishes to use DANE must verify that the MX
RRset it obtained is protected by DNSSEC and also that any
certificate binding information obtained via DNS is protected
by DNSSEC. This requires a standard API for secure DNS lookups.

So I don't expect immediate progress on this front, but partial
progress can perhaps be made. Postfix already supports matching
peer-certificates by their certificate or public-key fingerprint
(on the assumption that the selected digest is immune to second
preimage attacks so given a fingerprint it is no easier to construct
a matching certificate than a matching public key).

What we don't yet have, but will be needed for DANE, is support
for specifying a trust-anchor (root CA) fingerprint, so that
a per-site basis one can specify which root CA should be used
to verify the peer certificate.

I've been thinking of adding such an attribute to the tls_policy
table for some time. With this, the Postfix tls policy engine is
capable of supporting all the TLSA Certificate Usage Fields specified
in <https://tools.ietf.org/html/rfc6698#section-2.1.1>.

So it is perhaps time to add support for root CA fingerprints.

There is a subtle issue to consider. There is a somewhat perverse
distinction in section 2.1.1 between a "CA constraint" and a "trust
anchor assertion". The former requires that the verifier already
trusts the CA in question, and merely restricts the choice of
already trusted CAs, while the latter asserts a new trusted CA.

I see no need to support this distinction, either way we trust
the peer certificate it if it is signed by the CA in question,
and if we didn't already have the given CA as a trusted root CA,
the peer's DNS is free to "assert" it rather than "constrain" it.

Why would a peer ever want to be authenticated only by sites
that already trust its chosen CA and no others, rather than
by all sites capable of supporting DANE? So I would ignore
the distinction between certificate usage 0 and 2 (and
similarly 1 and 3).

In any case, I propose that we add support for root CA fingerprint
matching to the Postfix TLS engine allowing verification of trust
chains that contain a matching, possibly not a-priori trusted, root.

With this it becomes possible to map the results of a DANE DNS lookup
to a Postfix TLS policy. The rest is just additional glue to compute
such a policy on the fly when appropriate DNS APIs are broadly available,
and corresponding records are obtained via DNSSEC.

Concretely, to support DANE, we need two additional attributes in
the policy table, one to override the smtp_tls_fingerprint_digest,
so as to support <https://tools.ietf.org/html/rfc6698#section-2.1.3>
and another to specify the root CA fingerprint (which is computed
from the full certificate is that is provided in DNS).

So when a CA is involved (certificate usage 0 or 2) the imputed
TLS policy would be:

example.com secure \
digest=sha-256 \
rootca=<some-fingerprint> \
rootca=<another-fingerprint> ... \
match=<already-supported-match-syntax>

and when a CA is not involved (certificate usage 1 or 3) the imputed
TLS policy would be:

example.com fingerprint \
digest=sha-256 \
match=<fingerprint> \
match=<another-fingerprint> ...

The DANE specification potentially supports mixed security models,
wherein some of the elements of a TLSA RRset specify usage 0 or 2,
and others usage 1 or 3. This is not easily accomodated by Postfix
at this time, since the TLS library supports exactly one of the
two security models for a given connection.

I would be inclined to ignore usage 0 and 2, when 1 or 3 is present,
since given the expected peer certificate, there is no need for
any CAs.

Comments?
--
Viktor.
Stefan Sels
2013-01-13 19:17:47 UTC
Permalink
On 13/01/2013 19:22, Viktor Dukhovni wrote:
[..]

It is true that TLS/SMTP is often used but rarely discussed while making
new SMTP/TLS RFCs. Most stuff is written with https and browsers in
mind. There is a RFC-draft for S/MIME TLSA though:

http://tools.ietf.org/html/draft-hoffman-dane-smime-00
Post by Viktor Dukhovni
In any case, I propose that we add support for root CA fingerprint
matching to the Postfix TLS engine allowing verification of trust
chains that contain a matching, possibly not a-priori trusted, root.
With this it becomes possible to map the results of a DANE DNS lookup
to a Postfix TLS policy. The rest is just additional glue to compute
such a policy on the fly when appropriate DNS APIs are broadly available,
and corresponding records are obtained via DNSSEC.
That sound like an good idea.
Post by Viktor Dukhovni
Concretely, to support DANE, we need two additional attributes in
the policy table, one to override the smtp_tls_fingerprint_digest,
so as to support <https://tools.ietf.org/html/rfc6698#section-2.1.3>
and another to specify the root CA fingerprint (which is computed
from the full certificate is that is provided in DNS).
ok.
Post by Viktor Dukhovni
So when a CA is involved (certificate usage 0 or 2) the imputed
example.com secure \
digest=sha-256 \
rootca=<some-fingerprint> \
rootca=<another-fingerprint> ... \
match=<already-supported-match-syntax>
and when a CA is not involved (certificate usage 1 or 3) the imputed
example.com fingerprint \
digest=sha-256 \
match=<fingerprint> \
match=<another-fingerprint> ...
that would be computed parameters? or fixed configuration (just to
understand the example correctly) ?
Post by Viktor Dukhovni
The DANE specification potentially supports mixed security models,
wherein some of the elements of a TLSA RRset specify usage 0 or 2,
and others usage 1 or 3. This is not easily accomodated by Postfix
at this time, since the TLS library supports exactly one of the
two security models for a given connection.
Maybe the client could signal the security model/use case within the TLS
handshake? Like an extension to STARTTLS (or even STARTTLSA but that
would be messy). Just brain storming here..
Post by Viktor Dukhovni
I would be inclined to ignore usage 0 and 2, when 1 or 3 is present,
since given the expected peer certificate, there is no need for
any CAs.
Yeah. Currently we just look if any client cert is given. It would be
actually an improvement if we could at least verify that it is
associated with the given DNS records.
Post by Viktor Dukhovni
Comments?
You are right that DNSSEC is not wide spread enough (client wise and
general acceptance, and thereof TLSA would need time to grow, too). But
I think if you give a good reason why you actually want to use it, like
to make TLS or authentication with SMP more trustworthy (even with some
minor flaws), that would motivate people to implement it. It is the old
chicken and egg problem. TLS with diginotar like CAs is broken already,
maybe TLSA could provide a solution which "sucks less"...

Greetings,
Stefan
Viktor Dukhovni
2013-01-13 19:30:32 UTC
Permalink
Post by Stefan Sels
It is true that TLS/SMTP is often used but rarely discussed while making
new SMTP/TLS RFCs. Most stuff is written with https and browsers in
http://tools.ietf.org/html/draft-hoffman-dane-smime-00
S/MIME is of course quite unrelated to transport.
Post by Stefan Sels
Post by Viktor Dukhovni
So when a CA is involved (certificate usage 0 or 2) the imputed
example.com secure \
digest=sha-256 \
rootca=<some-fingerprint> \
rootca=<another-fingerprint> ... \
match=<already-supported-match-syntax>
and when a CA is not involved (certificate usage 1 or 3) the imputed
example.com fingerprint \
digest=sha-256 \
match=<fingerprint> \
match=<another-fingerprint> ...
that would be computed parameters? or fixed configuration (just to
understand the example correctly) ?
I said "imputed TLS policy". That is "assigned by inference". The
same policy could also be set explicitly in a policy table, for
example, by running a script the securely polss DNS TLSA RRsets
from time to time (for selected destination domains) and constructs
TLS policy table entries.
Post by Stefan Sels
Post by Viktor Dukhovni
The DANE specification potentially supports mixed security models,
wherein some of the elements of a TLSA RRset specify usage 0 or 2,
and others usage 1 or 3. This is not easily accomodated by Postfix
at this time, since the TLS library supports exactly one of the
two security models for a given connection.
Maybe the client could signal the security model/use case within the TLS
handshake? Like an extension to STARTTLS (or even STARTTLSA but that
would be messy). Just brain storming here..
This makes no sense.
Post by Stefan Sels
Post by Viktor Dukhovni
I would be inclined to ignore usage 0 and 2, when 1 or 3 is present,
since given the expected peer certificate, there is no need for
any CAs.
Yeah. Currently we just look if any client cert is given. It would be
actually an improvement if we could at least verify that it is
associated with the given DNS records.
The discussion in DANE is about server certificates, clients don't
fit into a "_service._proto.fqdn IN TLSA" lookup model. Postfix
supports certificate checks, but in practice only for a handful of
destinations.
--
Viktor.
Viktor Dukhovni
2013-04-01 03:37:04 UTC
Permalink
Post by Bry8 Star
When can we expect a Postfix release, that will support DANE
protocol ? so that it(postfix) can verify (using DANE & DNSSEC
protocols) the signed (and free) SSL/TLS certificates(cert) (or
fingerprints) which we can pre-add in TLSA, (CERT, HASTLS, etc) DNS
(DNSSEC) records, and then it(postfix) will use those(cert) for
secure (smtp) communication, and to verify SMTP servers.
If all goes well 2.11, with snapshots incrementally adding support
for DANE in the works. DANE support is code-complete, but requires
further code review and testing. To that end I would like to see
more mail receiving sites to sign their DNS zones, and publish TLSA
records for their MX hosts.

Thus far, I'm aware of just six MX hosts in four DNSSEC-enabled
domains that have TLSA records for SMTP. Of these:

- 5 publish "IN TLSA 3 1 1 ..." SHA256 public-key digest records,
which is a best practice, that's exactly what most people should
publish.

- 1 publishes "IN TLSA 3 1 2" which is also fine, since the only
difference is that the digest uses SHA512.

All six verify. I'd like to also test:

- "3 0 1" certificate digest RRs.
- "3 1 0" full public key RRs.
- "2 0 0" full certificate trust anchor RRs.
- "2 1 1" public key digest trust anchor RRs.

For "IN TLSA 2 1 1" the trust-anchor certificate must appear in
the server's SSL handshake trust chain. With just the public-key
digest, it is impossible to actually verify the chain.

I don't expect that administrators will publish their trust anchor
in full via DNS, rather they should publish the digest in DNS, and
provide the certificate in the SSL handshake. (In practice they
should shun all certificate usages other than 3).

If you have a DNSSEC-signed zone and operate MX hosts for that
domain that support inbound STARTTLS, please publish TLSA records,
and let me know which domain has said MX hosts.
Post by Bry8 Star
Currently (Jan 12, 2013), the last+stable GnuTLS, now supports DANE,
(and as of right now, OpenSSL (or any openssl modules) yet does not
support DANE). Can postfix utilize DANE libraries from gnutls for DANE ?
We don't need a new OpenSSL, its verification callback provides
sufficient rope.

The DANE code in the verification callback is a miniscule portion
of the new code. Most the hard work went into the SMTP policy
engine that finds, evaluates and caches TLSA RRs, making them
available to the SSL verification callback. A bunch more effort
goes into making sure that MX record and host to address resolution
tracks the DNSSEC validation status of the results.

Also ~1000 lines of code in the command-line smtptls-finger utility
so one can test before deploying and debug TLS problems if something
goes wrong.
Post by Bry8 Star
The DnsSec-Tools.Org site shares PATCH (developed by Sparta) for
(older) Postfix (and other software) to support DNSSEC, can someone
expert apply it(patch) on the last+stable postfix ?
http://www.dnssec-tools.org/howtos/postfix-2.3.x-dnssec-howto.txt
Their patch is largely misguided, no need for explicit DNSSEC
validation in Postfix. You get that for free by deploying a
validating cache (say "unbound") on your machine, and configuring
Postfix to query that cache. Far better to have DNSSEC validation
code in software focused squarely on DNSSEC support.

Once you do have access to Postfix with DANE support, you'll find
that initially it makes no difference at all, since there are as
yet essentially no SMTP servers that publish DANE records.

Since this is a chicken and egg problem, let's hope I'm laying an
egg. :-)

Perhaps, motivated by an MTA that supports DANE, receiving sites
will start to deploy DNSSEC signed zones and publish TLSA records.
This is going to take a few years, with the early adopters feeling
a bit lonely for a while...

If you're willing to be on the bleeding edge and want to help test
code Wietse has not reviewed yet, you can try on a suitable
non-critical system:

$ git clone http://github.com/vdukhovni/postfix
$ cd postfix/postfix
$ make -f Makefile.init 'CCARGS=-DUSE_TLS' 'AUXLIBS=-lssl -lcrypto' 'OPT=' \
makefiles # Add whatever else you need
$ make
$ make upgrade

The default branch is currently "DANE10", it may change in the
future, in which case if you're trying to stay current, you'll need
to checkout "DANE11", ... as they become available.

The documentation for DANE is at:

html/TLS_README.html#client_tls_dane
html/TLS_README.html#client_tls_policy

and various parameters linked from these. The main immediately
usable feature is support for per-destination trust-anchors
(root CA replacements):

html/postconf.5.html#smtp_tls_trust_anchor_file

which you can configure for a set of destinations without waiting
for them to do DNSSEC and TLSA. Otherwise, until more of you deploy
DNSSEC and publish TLSA records, DANE will have negligible impact
on your outbound mail stream.
--
Viktor.
Viktor Dukhovni
2013-04-27 03:11:43 UTC
Permalink
Post by Viktor Dukhovni
Post by Bry8 Star
When can we expect a Postfix release, that will support DANE
protocol ? so that it(postfix) can verify (using DANE & DNSSEC
protocols) the signed (and free) SSL/TLS certificates(cert) (or
fingerprints) which we can pre-add in TLSA, (CERT, HASTLS, etc) DNS
(DNSSEC) records, and then it(postfix) will use those(cert) for
secure (smtp) communication, and to verify SMTP servers.
If you're willing to be on the bleeding edge and want to help test
code Wietse has not reviewed yet, you can try on a suitable
This is now available as a nonprod snapshot via the postfix.org mirrors
listed at:

http://www.postfix.org/download.html

e.g.:

http://cdn.postfix.johnriley.me/mirrors/postfix-release/experimental/postfix-2.11-20130426-nonprod.tar.gz

Online docs for the snapshot are at:

http://vdukhovni.github.io/postfix/

once this is a regular snapshot, the documentation will be at

http://www.postfix.org/documentation.html

Feedback appreciated on:

http://vdukhovni.github.io/postfix/TLS_README.html#server_cert_key
http://vdukhovni.github.io/postfix/TLS_README.html#client_tls_dane

If in the mean-time any one turns on more DNSSEC domains and
publishes TLSA RRs for the domain's MX hosts, please drop me a
note.

Recommendation is to publish either "2 1 1" (and of course include
the TA cert in the server's TLS trust chain) or "3 1 1". Feel free
to publish "3 1 1" for both RSA and ECDSA certs (Postfix MTAs can
be configured with both).
--
Viktor.
Loading...