On Wed, Aug 10, 2016 at 04:20:01PM +0200, Mark Elkins wrote:
> I'm looking for some answers/clarification to various advantages of DANE
> vs normal MTA security and opportunistic TLS....
The basic issues are introduced in:
https://tools.ietf.org/html/rfc7672#section-1.3
> Without DANE/TLSA records.
>
> (1) When two Mail Servers talk and discover (opportunistically) that
> they can both talk SSL/TLS, does the Sender ever check the Receivers
> Certificate to make sure that Primary or Alternative names match the
> Receiving Server it is trying to connect to?
Generally no, and indeed many sites rely on this, and have self-signed
certificates or certificates whose names match neither the MX
hostname nor the nexthop domain. In any case, MITM MX RRset forgery
defeats certificate verification, and requiring the nexthop domain
in the peer cert does not scale given the large consolidation of
MX hosting at various providers.
> i.e. a Man-in-the-middle attack could also be using SSL/TLS Certificates
> (from anywhere), copy the email, then forward it on. I always told this
> part of the story with the Man-in-the-middle forcing the conversation to
> clear text.
Active (MiTM) attacks can defeat SMTP TLS even when STARTTLS is not
suppressed, though stripping STARTTLS is by far the simpler attack.
> -------------------
>
> (2) If I listen on port 465, should I also have a TLSA record for that
> port as well? e.g.
>
> _465._tcp.mail.mydomain.tld. IN TLSA 3 1 1 2A1492F9....
I am not aware of any MUAs that would look for such a TLSA record.
When/if such MUAs show up, the TLSA record would be useful.
> -------------------
>
> (3) What makes a Sending mail server ever connect to port 465 of a
> receiving mail server, except the obvious of some sort of static
> configuration?
MTAs don't do that, unless, as you say, they're statically configured
to do so for a particular domain.
> -------------------
>
> With DANE:
>
> (4) When running an ISP environment, single Mail Server with its own
> SSL/TLS Certificate, lots of virtual users with their own (Other)
> Domains, the Main Mail server has (I would think) just one SSL/TLS
> Certificate - presumable matching "mail.myisp.tld". Matching TLSA in the
> (secured) DNS. No problem for "DANE" styled e-mail to be sent to
> "user@???".
The canonical example is mail to "user@???" with that domain's
MX host operated by example.net, with both example.com and example.net
DNSSEC signed:
; Customer zone redirects MX to provider
;
example.com. IN MX 0 smtp.example.net.
example.com. IN RRSIG MX ...
; Another customer zone also redirects MX to provider
;
example.org. IN MX 0 smtp.example.net.
example.org. IN RRSIG MX ...
; A third customer chooses to use a name in their domain
; at the cost of duplicating the remote MX IP address.
;
example.edu. IN MX 0 smtp.example.edu.
smtp.example.edu. IN A 192.0.2.1
_25._tcp.smtp.example.edu. IN CNAME _25._tcp.smtp.example.net.
; A fourth customer pushes their luck with a CNAME for the MX
; host, this may break some senders.
;
example.gov. IN MX 0 smtp.example.edu.
smtp.example.gov. IN CNAME smtp.example.net.
_25._tcp.smtp.example.edu. IN CNAME _25._tcp.smtp.example.net.
...
; Provider zone publishes the address and TLSA records:
smtp.example.net. IN A 192.0.2.1
smtp.example.net. IN RRSIG A ...
_25._tcp.smtp.example.net. IN TLSA 3 1 1 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
_25._tcp.smtp.example.net. IN RRSIG TLSA ...
This allows a single provider to DANE-enable many customer domains.
> The many Other Domains can have a CNAME "mail.myname.tld" that points to
> "mail.myisp.tld".
Much more commonly, the mail is addressed to "user@???", not
"user@???". And the CNAME is instead an MX record.
> Do the Other Domains have to be DNSSEC Signed?
To protect against MITM attacks both domains have to be DNSSEC
signed.
> Ideally - I'd get
> everything signed. Will this work "DANE" style though if the hundreds of
> virtual domains don't have DNSSEC?
Virtual domains that don't have DNSSEC are not fully protected,
their MX records are subject to MITM tampering.
The most recent Postfix releases also support use of DANE TLSA for
unsigned nexthop domains with MX records in a signed domain, but
this is not secure against DNS forgery of the MX records of the
unsigned domain. You do however get tamper evidence, since the
sender's logs will typically record any forged MX hostname. So
the resulting protection is not entirely without merit.
--
Viktor.
