Mark Delany wrote:
On Tue, Jul 04, 2006 at 09:22:17AM -0700, Michael Thomas allegedly wrote:
John Levine wrote:
Current DNS RRtypes which result in a leaf record will not loop.
CNAMEs can always loop, but that is a general problem that we aren't
making any worse.
It's my belief that DKIM selectors don't allow CNAME's. Am I correct?
Whilst that might be appealing if one is no fan of CNAMEs, it would be
very hard to enforce. In particular an amount of DNS client software
follows CNAMEs automatically for the caller so a verifier may not even
get the chance to make this decision. One example being the popular
CPAN module Net::DNS::Resolver. It wouldn't surprise me if some caches
do this too making detection impossible in some cases.
Furthermore, disallowing CNAMEs would be inconsistent with most (all?)
other RR type queries thus creating surprise for unknowning DNS admins
who might routinely use CNAMEs.
Which maybe brings up a documentation clarification about allowing
CNAMEs since at least one person assumed that they are not allowed.
I guess I'm uncomfortable with CNAME's because I don't understand their
effects on the protocol very well, and in particular the security
ramifications.
First off, lets suppose DKIM's query mechanism were a lot like it is
today, but
the base mechnism didn't have CNAME's. Suppose that somebody proposed
that we should introduce them as a feature. What are:
1) The benefits in general
2) The security implications of the base DKIM mechanism (ie, is the
delegation
model still correct, what about key rollover, etc, etc).
3) The unintended security implications (loops, dos, amplification...)
Would we adopt that proposal at all? If the answer is "no", then that
sort of implies that we should at least discourage their use and/or have
a good
bit of information about their use, most likely in the security
considerations.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html