hangText="NOTE:"> The use of wildcard TXT records in
the
DNS will produce a response to a DKIM query that is
unlikely to be valid DKIM key record. This problem
applies to many other types of queries, and client
software that processes DNS responses needs to take
this
problem into account.</t>
I realize that 4871 is already too long, but this is too simplistic.
Wildcards within the _domainkey subtree can do reasonable things, e.g.,
this revokes any unknown key:
*._domainkey.example.com. TXT "v=DKIM1; p=; n=revoked"
_adsp._domainkey.example.com. TXT "DKIM=unknown" ;; override wildcard
I agree wildcards higher up the tree are unlikely to produce useful
results.
3. The issue of multiple occurrences of header fields that may only occur
once.
Proposed change: Add text to section 5.3 recommending that verifiers
check that the message complies with specs, and that they not validate
a non-compliant message. Add a new section 8.14 to the Security
Considerations, explaining the attacks that can be done using this
exposure.
Those are two different changes. My own sense is that each has some
controversy, with the first being pretty substantial and with the first having
some significant counter-proposals.
My preference is still that verifiers reject messages that are likely to
display misleadingly in MUAs, e.g., multiple copies of headers that MUAs
render one of. This is a rathole if you consider all the junk a bad guy
can do in HTML body parts, but at if you insist that the entire body is
signed, you can at least say that the garbage the user sees is same
garbage that was signed.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html