DANE SMTP behavior with inconsistent initial CNAME response

[Gael Roualland]

On 6/12/18 17:16, Viktor Dukhovni wrote:
>> 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.

This is what we offer as an option too (default on) and which is enabled 
in that case.
However we could still have a similar behavior if the original domain is 
signed, but the MX hostname is in a non-signed zone or an alias to a 
non-signed name.

>> 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.

Indeed...

>> 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.

Agreed, we could look only at the validation result here.
But assuming we get the same inconsistency in a secure way, then would 
that also be enough to apply DANE using the initial name as the TLSA 
domain ?

>> 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.

OK.

> 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?

Thanks.

I'm referring to the Cloudmark Security Platform product. Cloudmark was 
acquired by Proofpoint a year ago. I can't speak for DANE support status 
in other Proofpoint products.

We do support DANE-EE and DANE-TA, and try to adhere to the 
specification as much as possible. We have a blog post about it at [1] 
but that doesn't go into technical implementation details.

Gaël.

[1] https://blog.cloudmark.com/2017/03/27/dane-and-email-security/