DANE SMTP behavior with inconsistent initial CNAME response

[Viktor Dukhovni]

> On Dec 6, 2018, at 12:37 PM, Gael Roualland <groualland at proofpoint.com> wrote:
> 
> 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 ?

If the originally observed CNAME's fully expanded target is
insecure, or there are no TLSA records with that name as the
base domain, then you can indeed proceed to probe for TLSA
records at the original name.  If the full CNAME expansion
result is secure, then necessarily the origin is also secure,
so you don't even need to make the "initial CNAME" query.

	mx.original.example. IN CNAME mx.step1.example. ; AD=(0|1)
	... mx.step<i>.example. IN CNAME mx.step<i+1>.example. ; AD=(0|1)
	mx.step<N>.example. IN A 192.2.0.1 ; AD=(0|1)

	[ Typically the resolver delivers the whole chain with a single
          AD bit value, so it is either "1" for all, or 0 for the whole
          response, but then you don't know where in the chain it stopped
          being secure. ]

  a.  "mx.step<N>.example" is secure (all the AD bits are 1), and
      associated secure TLSA RRset found.

      * use "mx.step<N>.example" as TLSA base domain with corresponding
        TLSA records

  b. expanded CNAME is secure (all AD bits are 1), and no secure TLSA
     associated with the expanded name.

     * check for secure TLSA at original name

  c. expanded CNAME is insecure (one of the AD bits is 0).  Check security
     status of initial name via an "mx.original.example. IN CNAME ?"
     query.  You only need the validation status (AD bit) not the result.

     * If "insecure", done no DANE.
     * If "secure", look for TLSA RRset with "mx.original.example"
       as TLSA base domain.
     * If lookup failure (timeout, servfail whether DNSSEC-related or not),
       try a different MX host or defer.

-- 
	Viktor.