DANE SMTP behavior with inconsistent initial CNAME response

[Viktor Dukhovni]

On Thu, Dec 06, 2018 at 04:42:44PM +0100, Gael Roualland wrote:

> - some of these serve a valid zone content such as (A):
> domain.tld.	IN 	MX	1	mail.domain.tld.
> mail.domain.tld	IN	A	192.168.1.1
> 
> - others server a "parking" like zone (B):
> *.domain.tld.	IN	CNAME	domain.tld.
> domain.tld.	IN	A 	192.168.1.2

> None of these zones are signed.

A careful DANE implementation will generally not employ DANE for
unsigned domains.

> 1) MX lookup for the domain: returns "1 mail.domain.tld." (from zone A)

This is unsigned, and so you could stop DANE processing at that
point.  However, some DANE implementations (e.g. recent Postfix
versions) still employ DANE even for domains with "insecure" MX
records, when the selected MX host is in a signed zone. 

> 2) A/AAAA lookup for "mail.domain.tld": returns "A 192.168.1.1" through 
> "CNAME domain.tld." (from zone B)

Yes, that can happen, what a mess.  The destination domain's DNS
is broken, and DANE or not, it is lucky to get any mail at all.

> 3) Since the A reply is insecure and is from a CNAME alias, as per 
> §2.2.2 of the RFC we issue an explicit CNAME request on 
> "mail.domain.tld." to check if this is secure: this returns a NODATA 
> answer (from zone A)

So long as the NODATA answer is "insecure", the fact that it denies
the CNAME's existence is tolerable, the sole purpose of the CNAME
lookup is probe for DNSSEC in the original zone, and an "insecure"
NODATA shows the zone to be unsigned.

> In that case, our implementation considers that having a NODATA answer 
> to a CNAME that it received previously in a former response is 
> suspicious, and temporary fails this delivery attempt as if we hit a DNS 
> error.

I would suggest that it is OK to be less "suspicious".  While zone
content can vary between nameservers, the DNSSEC status of a domain
should be robust.

> AFAIK, this particular case is not covered by the RFC, and we're trying 
> to assess if degrading to Opportunistic TLS in that case instead of 
> temporary failing could actually introduce some security flaw in the 
> process.

You should be fine.

> It seems to me that for an attacker to be able to purposely return such 
> inconsistent answers, he would need to be able to spoof answers if zones 
> are not signed (like here) or have either control of the zone DNS key or 
> of the MTA's resolver, both which would allow other ways to skip DANE.
> 
> I'd like to get your opinions on this. Does that sound safe ? What do 
> other implementations do in that particular case ?

Your instinct is reasonable.  It is OK to continue with this domain.

By the way, it is news to me that Proofpoint supports DANE.
Congratulations and welcome to the club!  Do you support both
DANE-EE(3) and DANE-TA(2)?  The most recent opensource Sendmail
snapshot I can find still has fairly minimal DANE support.  Is there
somewhere a public description of DANE support in Proofpoint?

-- 
	Viktor.