On Tue, Feb 17, 2015 at 05:01:33PM -0500, Olafur Gudmundsson wrote:
> I section 3.1 you say in paragraph 2:
>
> For this specification to apply, the entire DNS RRset that is returned MUST
> be ?secure? ?
>
> Well the word entire is redundant if you are talking about single DNS RRset,
> BUT I think there are missing words i.e. the sentence should be:
>
> For this specification to apply, the entire chain of DNS RRset(s) that is
> returned MUST be ?secure? ?
>
> If the second interpretation is right some minor word-smithing in paragraph 3
> is also needed.
Yes, if indeed there is a "chain" (of CNAME/DNAME RRs) leading from
the query domain to the owner domain of the answer records then
the entire chain must be "secure". IIRC this much is already
said elsewhere in the draft.
Note that with security-aware non-validating stub-resolvers that
trust the AD-bit from a validating iterative resolver (presumably
one to which they have a secure communications path) the "chain"
issue is largely handled by that upstream resolver. The upstream
resolver will return AD=0 if any link in the chain is insecure.
With for non-validating security-aware stub resolvers the application
need only worry about "chains" if multiple resolver queries are
required to get from the query domain to the final answer (i.e.
the iterative resolver returns one or more CNAME, but not the
final answer, and the application has to retstart with the
final CNAME).
Thus, for example, Postfix has code to chase CNAMEs by asking the
resolver multiple times, and in *that* case it makes sure that the
final AD bit is the "AND" of the AD bits of all the replies received.
That code is rarely exercised, since in practice most iterative
resolvers do the CNAME chasing internally before returning multiple
CNAME RRs and the final answer in a single response.
This creates an interesting edge-case for testing whether individual
MX hosts (or SRV target hosts) live in a signed zone (that's the
purpose of the A/AAAA queries in the SRV and SMTP drafts that
gate the applicability of TLSA lookups):
; example.com is a signed zone
;
example.com. IN MX 0 mail.example.com.
mail.example.com. IN CNAME mail.example.net.
_25._tcp.mail.example.com. IN TLSA 3 1 1
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
; example.net is an "insecure" zone:
;
mail.example.net. IN A 192.0.2.1
When a query for the "A" records of "mail.example.com." is
sent to a validating iterative resolver, the response has
a CNAME RR, an "A" RR and AD=0. However the query domain
is actually "secure", the reason for "AD=0" is that the CNAME
points into an "insecure" zone.
To accomodate this edge-case, when the A/AAAA record returns
an insecure CNAME, Postfix sends a second query:
mail.example.com. IN CNAME ?
and if that yields "AD=1", TLSA records are still requested:
_25._tcp.mail.example.com. IN TLSA ?
and used if returned (with AD=1).
Now this case is atypical, because with MX and SRV records the
target host is supposed to never be a CNAME (though it is in a
small fraction of cases). So this issue legitimately arises only
for email domains that have no MX RRs and use just A records to
publish the available SMTP server(s). Nevertheless many MTAs
tolerate MX hostnames that are aliases.
Therefore the SMTP draft in section 2.2.2 (which covers the A/AAAA
record lookup rationale and processing logic) says:
[ ... Cases for possible replies to A/AAAA queries ... ]
Insecure CNAME: The input domain is a CNAME alias, but the ultimate
network address RRset is "insecure" (see Section 2.1.1). If the
initial CNAME response is also "insecure", DANE TLS does not
apply. Otherwise, this case is treated just like the non-CNAME
case above, where a search is performed for a TLSA record with the
original input domain as the candidate TLSA base domain.
This type of detail is how the SMTP draft go to be 33 pages, while
the SRV draft is noticeably shorter. :-)
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
