John Levine wrote:
This note seems relevant to DKIM. This draft says, predictably, that
the way you add new data types to the DNS is with a new RR type, and
all other approaches are ill-advised.
It also says that DNS tree climbing is always bad. We might want to
reconsider whether the small amount of tree climbing specified in -03
is worth the hassle it will doubtless cause on the route from final
draft to RFC.
The relevant section (4) of this document points out that by querying
the parent domain, it "may lead to incorrect results and may also put
security at risk," because the parent domain maybe under different
administrative control. What we need to consider is whether the risk of
undesired inheritance of an ASP from a parent domain is greater or less
than the risk presented by other labels (hostnames, etc.) being used in
From addresses without regard for the ASP of the domain they're in.
Since the default ASP is "unknown", the risk presented by a
separately-managed parent domain is that they will publish an ASP that
is stronger than that desired by the child. This can be countered
either by the parent publishing its record with the t=s flag that
prevents its application to subdomains, or by the child domain
publishing an explicit ASP of its own.
Without the parent query, any label in the domain is potentially able to
be used to circumvent the ASP record. Labels in the domain not having
an explicit ASP record would be interpreted as "unknown", which might be
looser than the ASP for the domain.
I have spent considerable time with the DNS folks, including two of the
editors of this draft, socializing what we are doing here. I believe
that security is better served by doing the parent query. I would hate
to compromise the effectiveness of ASP just to make it more expedient to
get it to RFC.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html