> On Nov 19, 2018, at 7:12 AM, J. Thomsen <l...@jth.net> wrote:
>
> 1) Postfix
> Later I have found the posttls-finger program in the Postfix distribution,
> but
> the logging in this program should be present in the Postfix smtp itself
> when using the
> smtp_tls_loglevel parameter (and still improvements in the documentation
> are needed)
Do you have a specific suggestion of what you'd like to see logged,
and a specific log message format? Would this be additional log
entries per connection, or more information in the summary TLS
connection log entry?
Is there something specific you'd like to see in the documentation?
Are you in a position to contribute documentation?
> 2) BIND
> It has only a partial implementation of the RFC 4035 AD bit handling.
> This, however, must be handled in another forum than this.
>
> We have been using BIND since 2001 (DNSSEC since 2013) as an authoritative
> name server
> for many domain names as well as a recursive resolver for all PCs on the
> LAN.
> It has been working flawlessly.
> It is not an option to have to mess around with additional resolvers and
> name servers just
> to implement DANE.
Does BIND return an accurate (AA, authoritative answer) bit? Would
you like to see Postfix consider authoritative answers as implicitly
validated? If not, what is it that you're asking for?
If BIND can be coaxed into setting the (AD) bit in authoritative replies
to queries that set the (RD) and (AD) bits, that would obviate any need
to implicitly infer (AD) from (AA) in Postfix.
> 3) TLS-SNI
> Single point of failures occur, when there is only one certificate for all
> virtual domains
> on a server and not one for every virtual domain. If the single certificate
> has expired or is
> damaged, mail for all customers is locked out from using TLS connections.
As already mentioned, SNI support is under development. Note
that experience shows that using multiple separate MX hostnames
for the same server makes DANE TLSA more fragile, because now
you have more TLSA records to manage, with increased odds of
neglecting to keep some of them up to date.
My suggestion is to avoid *wildcard* certificates where a single
certificate is used across the entire pool of MX hosts serving
your domains, and is rotated at approximately the same time across
all the hosts. These *have* been observed to cause outages when
all the MX hosts end up with non-matching TLSA records at the same
time.
Otherwise, by staggering certificate rotation across a small
handful (2 to 4) of MX hosts (each can have multiple IPs or
be in turn a server farm behind a load-balancer), you get
resilience against single points of failure without the complexity
of separate certificates and TLSA records for each domain.
Whatever you do, it won't be reliable if not monitored. MONITOR
your systems for correctness of TLSA records and near-expiration
of certificates.
Finally, for each logical MX host always publish at least two TLSA
records, bound to *separate* public keys, only one of which becomes
outdated as you rotate your certificates.
The most recommended model is: "3 1 1 + 3 1 1", where one of the
published TLSA records matches the *current* public key of the SMTP
server, and the other matches the *next* public key of the SMTP
server, pre-generated at time of deployment of the current key,
to become the next key when it is time to renew the certificate.
Each renewal cycle:
* Check that the pending "next" key already has a matching TLSA
record published in the DNS (ideally that this has been the
case for at least 2 DNS TTLs). If not, delay the key rollover.
* Obtain a certificate chain for this next key, and generate a
new next key. Deploy the obtained certificate chain and private
key and either "reload" your servers, or wait a while for all
servers to automatically cut over to the new key.
* Update your DNS TLSA records to match the new current (previously
next) key as well as the new next key:
Before: 3 1 1 <digest-of-key(N+0)> ; current (live)
3 1 1 <digest-of-key(N+1)> ; future (dormant)
After: 3 1 1 <digest-of-key(N+1)> ; current (live)
3 1 1 <digest-of-key(N+2)> ; future (dormant)
* If updating DNS TLSA records requires manual intervention or
is difficult to integrate as an automated part of the key rollover,
generate a notification email or other trigger to activate the
TLSA record update above. You have plenty of time to do it
during the lifetime of the current key, but don't procrastinate
do it early...
--
Viktor.
