On 4/25/2011 2:07 PM, Murray S. Kucherawy wrote:
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Dave CROCKER
Sent: Monday, April 25, 2011 9:11 AM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Revision to draft-ietf-dkim-mailinglists posted
My own primary concern, here, is that the document clearly mark the
difference
between what is currently withing the DKIM specification and what goes
beyond it.
So maybe just this (note the trailing paragraph):
Section 5.5 of [DKIM] includes a list of header fields that a
signature SHOULD include in its header hash and discusses reasons for
doing so. MLMs that sign MUST adhere to those guidelines, extended
as follows: {DKIM 12}
o Any [AUTH-RESULTS] fields added by the MLM;
o Any [LIST-ID] or [LIST-URLS] fields added by the MLM;
o Any [MAIL] fields, especially Sender and Reply-To, added or
replaced by the MLM.
Note that [DKIM] does not ascribe any specific meaning to what is or is
not included in the hashes that make up the signature. This is an
extension
to DKIM's semantics insofar as the MLM is taking responsibility for the
specific fields it added or altered.
I'm really sorry to be doing this, at this stage, but as long as the issue of
this section has come up, it ought to get cleaned up. This section contributes
to the continuing misunderstanding of DKIM semantics, since it promotes the
view
that there is differential "protection" being offered. The MLM text
demonstrates
this problem, I believe. The 4871 text It also contains a technical error.
Existing text in RFC 4871:
In order to maximize compatibility with a variety of verifiers, it is
Recommending a list of header fields to hash has nothing at all to do with
compatibility with verifiers. Presumably what was meant by this text was
compatibility with "expectations" among assessment mechanisms, but that's both
different and also wrong.
recommended that signers follow the practices outlined in this
section when signing a message. However, these are generic
recommendations applying to the general case; specific senders may
wish to modify these guidelines as required by their unique
This sentence was the only reason I kept quiet during the original error is
placating the AD. In effect, it emasculates the normative aspect of the
section... as it shuld.
situations. Verifiers MUST be capable of verifying signatures even
if one or more of the recommended header fields is not signed (with
the exception of From, which must always be signed) or if one or more
And this sentence provide the technical meat that offsets any potential
problems
when a signer chooses to deviate from the list. In effect, it further lessens
the import of the list.
of the dis-recommended header fields is signed. Note that verifiers
do have the option of ignoring signatures that do not cover a
sufficient portion of the header or body, just as they may ignore
signatures from an identity they do not trust.
The following header fields SHOULD be included in the signature, if
they are present in the message being signed:
o From (REQUIRED in all signatures)
o Sender, Reply-To
o Subject
o Date, Message-ID
o To, Cc
o MIME-Version
o Content-Type, Content-Transfer-Encoding, Content-ID, Content-
Description
o Resent-Date, Resent-From, Resent-Sender, Resent-To, Resent-Cc,
Resent-Message-ID
o In-Reply-To, References
o List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post,
List-Owner, List-Archive
In other words, this was an attempt to exhaustively list all potential
content-related "semantic" fields, and a few more (like MIME-Version) that
promote an erroneous sense of "protection".
The following header fields SHOULD NOT be included in the signature:
o Return-Path
o Received
o Comments, Keywords
o Bcc, Resent-Bcc
o DKIM-Signature
What is missing from all of this is any basic statement of guiding principle or
theory. Why should BCC not be signed? Why should MIME-Version be signed.
Optional header fields (those not mentioned above) normally SHOULD
NOT be included in the signature, because of the potential for
additional header fields of the same name to be legitimately added or
reordered prior to verification. There are likely to be legitimate
exceptions to this rule, because of the wide variety of application-
specific header fields that may be applied to a message, some of
which are unlikely to be duplicated, modified, or reordered.
Signers SHOULD choose canonicalization algorithms based on the types
of messages they process and their aversion to risk. For example,
e-commerce sites sending primarily purchase receipts, which are not
expected to be processed by mailing lists or other software likely to
modify messages, will generally prefer "simple" canonicalization.
Sites sending primarily person-to-person email will likely prefer to
be more resilient to modification during transport by using "relaxed"
canonicalization.
Strictly speaking, the above paragraph is not appropriate to this section,
since
it is not about "content". Since I don't see another, more appropriate venue
for this otherwise reasonable text, perhaps the easiest solution is to re-name
the sub-section to something like "Signature Practices".
Signers SHOULD NOT use "l=" unless they intend to accommodate
intermediate mail processors that append text to a message. For
example, many mailing list processors append "unsubscribe"
information to message bodies. If signers use "l=", they SHOULD
include the entire message body existing at the time of signing in
computing the count. In particular, signers SHOULD NOT specify a
body length of 0 since this may be interpreted as a meaningless
signature by some verifiers.
So with all that in mind, here's my suggestion for replacing the first part of
this section:
<<<<<<<<<<<
6.5 Signature Practices
The purpose of the DKIM cryptographic algorithm is to affix an identifier
to the message in a way that is both robust against normal transit-related
changes and resistant to kinds of replay attacks. An essential aspect of
satisfying these requirements is choosing what header fields to include in the
hash and what fields to exclude.
The basic rule for choosing fields to include is to select those fields
that constitute the "core" of the message content. Hence any replay attack
will
have to include these in order to have the signature succeed; but with these
included, the core of the message is valid, even if sent on to new recipients.
Common examples of fields with addresses and fields with textual content
related
to the body are:
o From
o Reply-To
o Subject
o Date,
o To, Cc
o Resent-Date, Resent-From, Resent-To, Resent-Cc
o In-Reply-To, References
o List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post,
List-Owner, List-Archive
The basic rule for choosing field to exclude is to select those fields for
which there are multiple fields with the same name, and fields that are
modified
in transit. Examples of these are:
o Return-Path
o Received
o Comments, Keywords
Note that the DKIM-Signature field is also excluded from the header-field
hash, because its handling is specified separately.
Typically, it is better to exclude other, optional fields because of the
potential that additional fields of the same name will be legitimately added or
re-ordered prior to verification. There are likely...
Folks will note that I've dropped a few, extraneous fields from each list. In
terms of the rules for going to Draft, this should be acceptable. Dropping
things is ok. Adding them is not.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html