• Automatically compute the TLSA hash (ideally 3 1 1 – SPKI SHA-256)
• Display the DNS record (like DKIM does)
• Optionally support: Multiple ports (25, 587, 465)

Hi,

Just to clarify my previous message — I am not asking for SmarterMail to modify or manage DNS zones in any way.

SmarterMail already provides a good example of this approach with DKIM: it generates the required DNS record, and the administrator is responsible for adding it to their DNS zone.

What I am suggesting is a similar mechanism for DANE/TLSA:

• SmarterMail could automatically compute the appropriate TLSA value (hex)
• Then simply display it in the interface
• The administrator would manually add it to their DNS provider

Currently, we generate this value manually using PowerShell based on the certificate file, for example:

$sha256 = [System.Security.Cryptography.SHA256]::Create()
$hash = $sha256.ComputeHash($cert.RawData)
$hashHex = ($hash | ForEach-Object { $_.ToString("x2") }) -join ""
Write-Host "_25._tcp.mail.domain.com IN TLSA 3 0 1 $hashHex"

This process works well, but it could easily be integrated directly into SmarterMail, especially since the platform already manages the SSL certificates.

To be clear:

The goal is only to generate and display the TLSA record, not to manage or update DNS zones.

This would significantly simplify DANE adoption while keeping full control of DNS in the administrator’s hands.

Just to clarify my previous message — I am not asking for SmarterMail to modify or manage DNS zones in any way.

Out of curiosity, for those using DANE, how do you manage the time gap between generating new certificates and updating DNS records? You need the certificate to generate the new hash, but you also need the hash in DNS for other servers to honor the DANE RFC. It seems there could be a period during which your server cannot receive email until DNS is updated. That would be particularly difficult to manage with automatic certificates.

• User triggers a connection to www.example.com 
• System resolves www.example.com to an IP address verified by DNS SEC
• User reaches www.example.com and the browser verifies that the certificate names include the requested name www.example.com.

• One way would be to get the browser connected to a fake www.example.com without using DNS, but I do not know how to do that.   
• Alternatively, you get the right IP address but a malicious NAT translator intercepts your traffic and redirects you to a different IP address which has been configured with the fake certificate.  So DANE helps you detect that your entire infrastructure needs to be disconnected from the Internet because of the malicious NAT translator.   

• Inbound Traffic:
  • For organizations that want to enforce DANE/TLSA, SmarterMail needs to be configured with a DANE-compliant certificate for those organizations.   This is not necessarily a SmarterMail task, but since they provide features for certificate automation, they may be able to help.
  • Client software is responsible for detecting DANE/TLSA settings and refusing connections if the verification test fails.   SmarterTools does not build any email client tools, so it has no tasking here.
• Outbound Traffic:
  • SmarterMail could detect an outbound SMTP session that attempts STARTTLS but receives a DANE/TLSA certificates that fails the verification test.  Then what?
  • What do we have to assume has happened for the SMTP session to reach a server with a fake certificate?
  • If we do get connected to the wrong server, the server owner has the option of not offering STARTTLS, or offering a self-signed certificate.   How does a fake certificate help them?
  • Assuming that DANE/TLS exposes a fraudulent site, what do you want SmarterMail to do?  It will probably retry until the certificate is replaced or the retry limit has been reached after N days and the user receives a belated non-delivery notice.    I suggest that if you are going to detect a malicious site at all, you need to have an alarming system that draws attention much more quickly than 2 days or more.  Additionally, the alarm needs to go to a system administrator, not the user.
• Exception Management:
  • What happens when a critical correspondent has a misconfigured DANE/TLSA environment and your connections get blocked because of their mistake?  All of my experience with DNS SEC is bad, because all of my security blocks have been false positives.    The worst example was when the U.S. Centers for Disease Control messed up their DNS SEC settings and took 6 weeks to get it fixed.   Fortunately, we had a way to reroute web traffic through a path that did not enforce DNS SEC, so we could still access their servers.