DANE requires a server operator to do three things:
1) run DNSSEC. This provides assurance to clients
that DNS lookups they do for the server have not
-been tampered with.
+been tampered with. The domain MX record applying
+to this server, its A record, its TLSA record and
+any associated CNAME records must all be covered by
+DNSSEC.
2) add TLSA DNS records. These say what the server
certificate for a TLS connection should be.
3) offer a server certificate, or certificate chain,
all of which point to a single TLSA record.
The TLSA record should have a Selector field of SPKI(1)
-and a Matching Type fiels of SHA2-512(2).
+and a Matching Type field of SHA2-512(2).
+
+At the time of writing, https://www.huque.com/bin/gen_tlsa
+is useful for quickly generating TLSA records; and commands like
+
+ openssl x509 -in -pubkey -noout <certificate.pem \
+ | openssl rsa -outform der -pubin 2>/dev/null \
+ | openssl sha512 \
+ | awk '{print $2}'
+
+are workable for 4th-field hashes.
For use with the DANE_TA model, server certificates
must have a correct name (SubjectName or SubjectAltName).
The use of OCSP-stapling should be considered, allowing
for fast revocation of certificates (which would otherwise
-be limited by the DNS TTL on the TLSA records).
+be limited by the DNS TTL on the TLSA records). However,
+this is likely to only be usable with DANE_TA.
For client-side DANE there are two new smtp transport options,
tls_verify_certificates
tls_crl
tls_verify_cert_hostnames
- hosts_require_ocsp (might rethink those two)
- hosts_request_ocsp
Currently dnssec_request_domains must be active (need to think about that)
and dnssec_require_domains is ignored.
+If verification was successful using DANE then the "CV" item
+in the delivery log line will show as "CV=dane".
+
--------------------------------------------------------------
End of file