Re: RFE: DANE functions + log

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view

Re: RFE: DANE functions + log

Viktor Dukhovni
> On Nov 15, 2018, at 10:32 AM, J. Thomsen <[hidden email]> wrote:
> 1) logging
> More informative logging of what is happening, when smtp is trying to establish a TLS connection
> using dane e.g. on dns lookups, TLSA lookups and the results

Please be more specific.  What exactly would you like to see logged,
perhaps with a suggested format.

See the posttls-finger(1) manpage, do any of the fine-grained
(-L logopts) logging features there do what you need?

> Better documentation of what is actually meant by these messages:
> Anonymous TLS connection established
> Trusted TLS connection established
> Verified TLS connection established

> 2) problem with no ad flag when the resolver is querying an authoritative DNS
> In this case Postfix is running on the same server as the authoritative server and using it as a
> recursive resolver. I had to change the resolv.conf file to an external DNS, but for various reasons
> this will not work properly in all cases.

The simplest advice is split the authoritative and recursive services.
I have authoritative servicing the machine's public IP, and the recursive
servicing only and ::1.  Separating authoritative and recursive
services is good for many reasons, not just Postfix's use of the AD bit.

> This issue should be solved, and at least be mentioned in the documentation
> for DANE, as it can be a showstopper.

Yes, a comprehensive DANE_README document is needed.

> 3) TLS SNI
> The documentation states, that there are no plans to implement SNI in the Postfix
> SMTP server.  Is this still valid?

No, SNI support is under development.


Reply | Threaded
Open this post in threaded view

Re: RFE: DANE functions + log

Viktor Dukhovni
> On Nov 20, 2018, at 7:53 AM, J. Thomsen <[hidden email]> wrote:
> From the log it should be obvious
> 1) does Postfix lookup the TLSA record

Always does, with "smtp_tls_security_level = dane"

> 2) did Postfix receive the TLSA record and which ones

Domains that have TLSA records will be "Verified" or the delivery
will fail with a certificate authentication failure.  Other domains
will be logged as "Anonymous" or "Untrusted".  So the presence of
TLSA records is implicit in the connection security status.  The
actual TLSA records should not IMHO be logged on a routine basis.

> 3) does Postfix use the TLSA record and which one

Probably not useful on a routine basis.

> 4) is the TLSA record valid and how is Postfix using it

Probably not useful on a routine basis.  As for "how",
the answer is per RFC7672.

>> I think that 5 log messages where one was looks reasonably sufficient
>> to me are probably too much.
> Well, yes, it was just a suggestion for an easy copy-paste from posttls-finger to the smtp client :)

I am looking for "correct", not "easy".

>>> When implementing DANE it is helpful to increase the value of smtp_tls_loglevel to at least X.
>> I've always found level 1 to be sufficient for routine logging.
> As always a more detailed level (pt 1-3) is needed during the implementation or error diagnosis and
> a less detailed level (pt. 4) during production.

So are you asking to change the routine logging, or just more
options for verbose logging when doing trouble-shoots and testing?


Reply | Threaded
Open this post in threaded view

Re: RFE: DANE functions + log

Viktor Dukhovni
In reply to this post by Viktor Dukhovni
> On Nov 21, 2018, at 11:28 AM, J. Thomsen <[hidden email]> wrote:
> This may be true in the production phase, but hardly an issue in an implementation phase, when the
> implementor needs to know, if the system is acting as expected and the loglevel is increased.

So it seems you're NOT asking for more verbose routine logging under
"normal" ("production") conditions.  That changes the discussion.

Any fine-grained TLS log mask beyond the legacy "levels" (0, 1, 2, 3, 4)
is essentially an implementation artefact.  So this is not described in
the documentation of "smtp_tls_loglevel", and may change incompatibly.

The"smtp_tls_loglevel" and "smtpd_tls_loglevel" parameters are two rare
departures (no others immediately come to mind) from the Postfix design
principle of no undocumented features.  The syntax that you see for the
"-L" option with posttls-finger(1) is actually also available with the
"smtp_tls_loglevel" and "smtpd_tls_loglevel" parameters.

Perhaps this thread can resolve the tension between making sure that the
interfaces we document are stable, and also making sure we don't have
undocumented features.

The idea would be to document for "smtpd?_log_level" only 0--4 (as is now
the case), but also note that more fine-grained logging options are
available as described for the "-L" option in the posttls-finger(1)
manpage.  The posttls-finger "-L" log mask is not a stable interface, all
I can say is that it does not change capriciously.

So to be clear:

 * No promise that any "loglevel" other than 0--4 will work in production.
 * However, values documented for posttls-finger(1) for the *same* Postfix
   release should work in practice.

It seems you're looking for:

        smtp_tls_loglevel = summary, certmatch

Or perhaps even:

        smtp_tls_loglevel = summary, certmatch, verbose

Maybe along with:

        smtp_tls_fingerprint_digest = sha256

Repeat warning: unstable interface.