On Mon, 19 Nov 2018 19:03:05 -0500,Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:
>That's not terribly specific, what specifically in those logs do >you find compelling and why? >From the log it should be obvious 1) does Postfix lookup the TLSA record 2) did Postfix receive the TLSA record and which ones 3) does Postfix use the TLSA record and which one 4) is the TLSA record valid and how is Postfix using it > >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 :) >> 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. > >> Also using posttls-finger included with the source code of Postfix can be >> recommended. > >Various Linux distributions, and FreeBSD do include posttls-finger. Yes, but, please, tell people about it. > >> Postfix is logging various messages at the end of the TLS negotiation: >> >> Anonymous TLS connection .. >> This is logged, when ... >> .... > >This is covered in FORWARD_SECRECY_README, as mentioned previously. Very good, but there is a difference between someone just wanting to implement DANE and someone wanting to understand every detail of forward secrecy. In the TLS_README.html there is a couple of references to the FORWARD_SECRECY_README to take maximal advantage of forward secrecy. Postfix has a huge number of parameters and people tend to focus on only the subset, they need. In the sections below there is no reference to actual logging details Server-side TLS activity logging Client-side TLS activity logging smtp_tls_loglevel (default: 0) I suggest adding Please, see the FORWARD_SECRECY_README for details about what is logged. > >> It also makes it possible to handle the key rollover as you suggest, but >> here it should also be >> noted, that the "3 1 1" format allows a certificate to be renewed without >> changing the TLSA record, >> as long as the private key is not changed (RFC 6698 A.1.2.2) > > https://tools.ietf.org/html/rfc7671#section-5.1 > https://tools.ietf.org/html/rfc7671#section-8.1 Yes, I see that valid reductions in complexity and error sources have been allowed. > https://imrryr.org/~viktor/ICANN61-viktor.pdf I see you already have pointed out my problem with BIND on slide 17 "Need DNSSEC validating resolver, local to the MTA" - Jørgen Thomsen
