On Thu, Feb 20, 2020 at 11:27:38AM +0800, Harvy Chen wrote:
> Once studied the DANE RFCs, for the multiple tenant service providers,
> like this: Sender ----> Service -----> Rcpt.
With DANE for SMTP the client authenticates the MX host, not the
recipient domain. All the recipient domain has to do is have
DNSSEC-signed MX records.
As the provider your first responsibility to *monitor* your service
that you are promptly notified and take action to remediate any
situation in which your TLSA records for some reason stop matching
your certificate chain (e.g. poorly-executed certificate rollover).
Your next responsibility is to have a robust certificate rollover
process that avoids the potential outages that the monitoring
would detect.
https://github.com/internetstandards/toolbox-wiki/blob/master/DANE-for-SMTP-how-to.md
https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html
https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022/17
https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources
> How can it implement the DANE for inbound traffic? It requires the
> customer's (rcpt) certificate, in TLS connection setup stage, we even
> don't know who is the rcpt, and cannot decide to use which
> certificate.
You DO NOT need certificates for the recipient domain, you just need
certificates for the supported name(s) under which your MX hosts are
known.
Example:
; Some domains with DNSSEC-signed MX records that are MX-hosted
; by sitnet.dk (there are many more):
;
hirschsprung.dk. IN MX 10 mx5.sitnet.dk.
hirschsprung.dk. IN MX 10 mx6.sitnet.dk.
udbudsraadet.dk. IN MX 10 mx5.sitnet.dk.
udbudsraadet.dk. IN MX 10 mx6.sitnet.dk.
kunststyrelsen.dk. IN MX 10 mx5.sitnet.dk.
kunststyrelsen.dk. IN MX 10 mx6.sitnet.dk.
...
; The A records of sitnet.dk are also DNSSEC-signed
;
mx5.sitnet.dk. IN A 188.64.157.5
mx5.sitnet.dk. IN AAAA ? NODATA AD=1
; Both MX hosts also have DNSSEC-signed TLSA records.
;
_25._tcp.mx5.sitnet.dk. IN TLSA 3 1 1
d2a84de1a2049598ddc02f9a30f01f45c83d9fdde099657155d8e88d9515afe7
_25._tcp.mx6.sitnet.dk. IN TLSA 3 1 1
d2a84de1a2049598ddc02f9a30f01f45c83d9fdde099657155d8e88d9515afe7
; Their certificates matches these TLSA records. With RFC7672
; DANE SMTP, when using DANE-EE(3) (certificate usage 3) TLSA
; records, the names in the certificate are irrelevant. They
; are implicit in the TLSA RR owner name (_25._tcp + "TLSA base
; domain").
;
mx5.sitnet.dk[188.64.157.5]: pass: TLSA match: depth = 0, name = *.sitnet.dk
mx6.sitnet.dk[188.64.157.6]: pass: TLSA match: depth = 0, name = *.sitnet.dk
TLS = TLS12 with ECDHE-RSA-AES256GCM-SHA384,P256
name = sitnet.dk
name = *.sitnet.dk
depth = 0
Issuer CommonName = Sectigo RSA Domain Validation Secure Server CA
Issuer Organization = Sectigo Limited
notBefore = 2019-03-04T00:00:00Z
notAfter = 2021-03-03T23:59:59Z
Subject CommonName = sitnet.dk
pkey sha256 [matched] <- 3 1 1
d2a84de1a2049598ddc02f9a30f01f45c83d9fdde099657155d8e88d9515afe7
...
If your MX hosts support SNI, you can if desired have separate
certificates for a few different names of each MX host. If
your MX support both RSA and ECDSA (configured with separate
certificates for each algorithm), then you need multiple TLSA
records to match these:
https://mail.sys4.de/pipermail/dane-users/2017-August/000417.html
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
