On Mon, 19 Nov 2018 10:25:25 -0500,Viktor Dukhovni <postfix-us...@dukhovni.org> 
wrote:

>> 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?

I think it would be a large improvement, if just the basic logging of 
posttls-finger -c could be added. Then increasing the smtp_tls_loglevel would 
make things clearer.
>
>Is there something specific you'd like to see in the documentation?
>Are you in a position to contribute documentation?

I don't think I have enough detailed knowledge, but it would help to have 
access to 
something like:

When implementing DANE it is helpful to increase the value of smtp_tls_loglevel 
to at least X.
Also using posttls-finger included with the source code of Postfix can be 
recommended.

Postfix is logging various messages at the end of the TLS negotiation:

Anonymous TLS connection ..
  This is logged, when ...

Untrusted TLS connection ...
  This is logged, when ....

Trusted TLS connection ....
  This is logged, when ....

Verified TLS connection ...
  This is logged, when ....


>
>> 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.

It would be the proper solution to use the AD flag, because also other software 
is depending on it
(e.g. tlsa). I am going to suggest this to the BIND developers.
I have not yet considered in which cases using the AA flag is safe enough, but 
maybe as an interim
solution (also when using other name servers than BIND) or if it is not 
possible to have it
implemented in BIND.

>
>> 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.

I agree, there will be more administration, but as LetsEncrypt automated updates
of certificates have already become common and by adding TLSA scripts to the
already defined hooks in LetsEncrypt, the risk of manual errors are reduced.

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)

- Jørgen Thomsen

Reply via email to