[ietf-dkim] draft-ietf-dkim-base-02 typos?
Eric Allman
eric+dkim at sendmail.org
Thu Jun 1 07:32:02 PDT 2006
As near as I can tell, every single one of these came up at the IETF
end --- I checked the version I sent them and the doubled characters
do not exist.
eric
--On May 31, 2006 2:22:23 PM -0700 Douglas Otis
<dotis at mail-abuse.org> wrote:
> Errors are highlighted using [[error]] notation. This was based
> upon the draft located at:
> http://ietf.org/internet-drafts/draft-ietf-dkim-base-02.txt
>
> There seems to be a type of corruption introduced and were not
> noted in Jim's nits.
>
>
>
> 3.4.6 Example
>
> Example 3: When processed using relaxed header canonicalization
> and
> simple body [[canoniccalization]],
>
> 3.5 The DKIM-Signature header field
>
> h= Signed header fields (plain-text, but see description;
> REQUIRED). A colon-separated list of header field names
> that
> identify the header fields presented to the signing
> algorithm.
> The field MUST contain the complete list of header fields
> in the
> order presented to the signing algorithm. The field MAY
> contain
> names of header fields that do not exist when signed;
> nonexistent
> header fields do not contribute to the signature computation
> (that is, they are treated as the null input,
> [[includiing]] the
>
> z= Copied header fields (plain-text, but see description;
> OPTIONAL,
> default is null). A vertical-bar-separated list of selected
> header field names and copies of header field values that
> identify the header
> fields present when
> the message was signed. It is not required to include all
> header
> fields present at the time of signing. This field need not
> contain the same header fields listed in the "h=" tag.
> Copied
> header field values MUST immediately follow the header
> field name
> with a colon separator (no white space permitted). Header
> field
> values MUST be represented as Quoted-Printable [RFC2045]
> with
> vertical bars, colons, semicolons, and white space encoded
> in
> addition to the usual requirements.
>
> Verifiers MUST NOT use the header field names or copied
> values
> for checking the signature in any way. Copied header field
> values are for diagnostic use [[onnly]].
>
> 3.6.1 Textual Representation
>
> It is expected that many key servers will choose to present the
> keys
> in an otherwise unstructured text format (for example, an XML
> form
> would not be considered to be unstructured text for this
> purpose).
> The following definition [[MMUST]] be used for any DKIM key
> represented in
> an otherwise unstructured textual form.
> ...
> y This domain is testing DKIM. Verifiers MUST NOT treat
> messages from signers in testing mode differently from
> unsigned email, even should the signature fail to
> verify.
> Verifiers MAY wish to track testing [[modee]] results
> to assist
> the signer.
>
> 3.7 Computing the Message Hashes
>
> In hash step 1, the signer or verifier MUST hash the message
> body,
> canonicalized using the body canonicalization algorithm
> specified in
> the "c=" tag and truncated to the length specified in the "l="
> tag.
> That hash value is then converted to base64 form and inserted
> into
> the "bh=" tag of the [[DKIMM-Signature:]] header field.
>
> All tags and their values in the DKIM-Signature header field are
> included in the cryptographic hash with the sole exception of
> the
> value portion of the "b=" (signature) tag, which MUST be
> treated as
> the null string. All tags MUST be included even if they might
> not be
> understood by the verifier. The header field MUST be presented
> to
> the hash algorithm after the body of the message rather than
> with the
> rest of the header fields and MUST be canonicalized as
> specified in
> [[the€]] "c=" (canonicalization) tag. The DKIM-Signature
> header field
> MUST NOT be included in its own h= tag.
>
> 5.1 Determine if the Email Should be Signed and by Whom
>
> A signer MUST NOT sign an email if it is unwilling to be held
> responsible for the message; in particular, the signer SHOULD
> ensure
> that the submitter has a bona fide relationship with the signer
> and
> that the submitter has [[tthe]] right to use the address being
> claimed.
>
> 5.4 Determine the header fields to Sign
>
> The From header field MUST be signed (that is, included in the
> h= tag
> of the resulting DKIM-Signature header field); any header field
> that
> describes the role of the signer (for example, the Sender or
> Resent-
> From header field if the signature is on behalf of the
> corresponding
> address and that address is different from the From address)
> MUST
> also be included. The signed header fields SHOULD also include
> the
> [[Subjectt]] and Date header fields as well as all MIME header
> fields.
>
> 6.3 Compute the Verification
>
> INFORMATIVE IMPLEMENTATION NOTE: Verifiers that truncate
> the body
> at the indicated body length might pass on a malformed MIME
> message if the signer used the "N-4" trick described in the
> informative note in Section 5.5. Such verifiers may wish to
> check
> for this case and include a trailing "--CRLF" to avoid
> breaking
> the MIME structure. A simple way to achieve this might be to
> append "--CRLF" to any "multipart" message with a body
> length; if
> the MIME structure is already correctly formed, this will
> appear
> in the postlude and will not be [[displayeed]] to the end
> user.
>
> 6.6 MUA Considerations
>
> This sort of [[addrress]] inconsistency is expected for mailing
> lists, but
> might be otherwise used to mislead the verifier, for example if
> a
> message supposedly from administration at your-bank.com had a
> Sender
> address of fraud at badguy.com.
>
> 8.2 [[Misappropriateed]] Private Key
>
> 8.3 Key Server Denial-of-Service Attacks
>
> Since the key servers are distributed (potentially separate for
> each
> domain), the number of servers that would need to be attacked to
> defeat this mechanism on an Internet-wide basis is very large.
> Nevertheless, key servers for individual domains could be
> attacked,
> impeding the verification of messages from that domain. This
> is not
> significantly different from the ability of an attacker to deny
> service to the mail exchangers for a given domain,
> [[aalthough]] it
> affects outgoing, not incoming, mail.
>
> 8.5 Replay Attacks
>
> In this attack, a spammer sends a message to be spammed to an
> accomplice, which results in the message being signed by the
> originating MTA. The accomplice resends the message, including
> the
> original signature, to a large number of recipients, possibly by
> sending the message to many compromised machines that act as
> MTAs.
> The messages, not having been modified by the accomplice, have
> valid
> signatures.
>
> Partial solutions to this problem involve the use of reputation
> services to convey the fact that the specific email address is
> being
> used for spam, and that messages from that signer are likely to
> be
> spam. This requires a real-time detection [[mechanissm]] in
> order to
> react quickly enough. However, such measures might be prone to
> abuse, if for example an attacker resent a large number of
> messages
> received from a victim in order to make them appear to be a
> spammer.
>
> B.1 Simple Message Forwarding
>
> In some cases the recipient may request forwarding of email
> messages
> from the original address [[tto]] another, through the use of a
> Unix
> .forward file or equivalent.
>
>
> B.4 Mailing Lists
>
> There is a wide range of behavior in forwarders and mailing
> lists
> (collectively called "forwarders" below), ranging from those
> which
> make no modification to the message itself (other than to add a
> Received header field and change the envelope information) to
> those
> which may add header fields, change the Subject header field,
> add
> content to the body (typically at the end), or reformat the
> body in
> some manner.
>
> Forwarders which do [[noot]] modify the body or signed header
> fields of a
> message with a valid signature may re-sign the message as
> described
> below.
>
>
> Appendix C. Creating a public key (INFORMATIVE)
>
> This public-key data (without the BEGIN and END tags) is placed in
> the DNS. With the signature, canonical email contents and
> [[puublic]]
> key, a verifying system can test the validity of the signature.
> The
> openssl invocation to verify a signature looks like this:
>
> -Doug
>
>
>
>
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
>
More information about the ietf-dkim
mailing list