> -----Original Message----- > From: Dave CROCKER [mailto:[email protected]] > Sent: Monday, April 25, 2011 3:00 PM > To: Murray S. Kucherawy > Cc: [email protected] > Subject: Re: [ietf-dkim] Revision to draft-ietf-dkim-mailinglists posted > > 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.
s/kinds/some kinds/ > 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. ...or the header and/or body is otherwise modified. > 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 One could argue that the MIME fields (omitted here) constitute the core of the message as they go to the representation of the content. However, they haven't been precluded by the above text so it's probably fine. I'd actually like to add Authentication-Results because an agent that wishes to claim that observed authentication meta-data should become part of the message core certainly should sign such a field, but that's not worth recycling at Proposed and basically RFC5451 already says that anyway. > 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... Works for me. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
