On 2/16/11 9:18 AM, Dave CROCKER wrote:
Folks,
A new version of rfc4871 has just been posted as an I-D. A diff is
attached.
The draft is available at:
<http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-03>
This version does NOT contain text that resolves two outstanding
issues:
Subject: [ietf-dkim] Focusing on 4871bis Date: Fri, 22 Oct 2010
11:28:10 -0400 From: Barry Leiba <barryleiba(_at_)computer(_dot_)org>
...
2. Advice about wildcards in TXT records. Proposed change: Add a
note in section 6.1.2 warning about the effect of wildcard TXT
records on finding DKIM key records.
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.
As John Levine noted, there is incorrect text in 3.6.2.1. Namespace.
,--
INFORMATIVE OPERATIONAL NOTE: Wildcard DNS records (e.g.,
*.bar._domainkey.example.com) do not make sense in this context
and should not be used. Note also that wildcards within domains
(e.g., s._domainkey.*.example.com) are not supported by the DNS.
'--
Change to:
,==
Wildcard DNS records (e.g., *.bar._domainkey.example.com) could be used
for logging purposes.
'==
3.6.1. Textual Representation
t= Flags, ...
There might be some informative text added to clarify repeated use of a
tag-list identifiers, unlike tags, is allowed. It seems some domains
create separate t=y and t=s entries rather than t=y:s, for example.
6.1.2. Get the Public Key
...
Was:
,--
NOTE: The use of wildcard TXT records in the DNS will produce a
response to a DKIM query that is unlikely to be valid [a] 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.
'--
Change to:
,==
NOTE: The use of wildcard TXT records in the DNS might be used for
logging proposes, but its use is discouraged as it will have a
detrimental effect on DNS caching.
'==
CHARTER FAIL:
8.14. Attacks Involving Addition of Header Fields
Was:
,--
For example, a message with multiple From: header fields violates
Section 3.6 of [RFC5322]. With the intent of providing a better user
experience, many agents tolerate these violations and deliver the
message anyway. An MUA then might elect to render to the user the
value of the last, or "top", From: field. This may also be done
simply out of the expectation that there is only one, where a "find
first" algorithm would have the same result. Such code in an MUA can
be exploited to fool the user if it is also known that the other
From: field is the one checked by arriving message filters. Such is
the case with DKIM; although the From: field must be signed, a
malformed message bearing more than one From: field might only have
the first ("bottom") one signed, in an attempt to show the message
with some "DKIM passed" annotation while also rendering the From:
field that was not authenticated. (This can also be taken as a
demonstration that DKIM is not designed to support author
validation.)
To resist this specific attack the signed header field list can
include an additional reference for each field that was present at
signing. For example, a proper message with one From: field could be
signed using "h=From:From:..." Due to the way header fields are
canonicalized for input to the hash function, the extra field
references will prevent instances of the cited fields from being
added after signing, as doing so would render the signature invalid.
The From: field is used above to illustrate this issue, but it is
only one of > several fields that Section 3.6 of [RFC5322] constrains
in this way. In reality any agent that forgives malformations, or is
careless about identifying which parts of a message were
authenticated, is open to exploitation.
'--
Change to:
,==
A message with multiple From: header fields violates Section 3.6 of
[RFC5322]. With the intent of providing a better user experience,
many agents tolerate these violations and deliver the message anyway.
Any message containing multiple orig-date, from, sender, reply-to,
to, cc, message-id, in-reply-to, and subject header fields will not
produce a valid signature. See Section 5.3. Verification and
presentation layers will not always process headers in the same order
or confirm content synchronicity. Allowing multiple singleton
header fields within a message to verify as having a valid DKIM
signature enables trivial spoofing exploits not always remedied by use
of h=from:from, for example.
'==
From: accounts(_at_)big-bank(_dot_)com (Displayed)
From: accounts(_at_)mallory-bank(_dot_)com (Not Displayed)
DKIM-Signature: d=mallory-bank.com... (signature valid when From:
accounts(_at_)big-bank(_dot_)com not prefixed.)
Users may expect DKIM messages from big-bank.com to be rejected when not
signed by big-bank.com on the basis of ADSP or ISP policy. Unless
multiple-singleton headers are prohibited from receiving DKIM pass
results, then users are likely to believe a message with a prefixed
From: accounts(_at_)big-bank(_dot_)com will be assumed to have been signed by
big-bank.com. Use of h=From:From: would be controlled by
mallory-bank.com, and not big-bank.com, which could simply use h=From.
The primary use of DKIM was to serve as protection from phishing, where
checking for multiple singleton header fields represents a trivial
amount of overhead compared against signature validation.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html