Subject: Re: [ietf-dkim] draft-ietf-dkim-base-02 typos?

From: Douglas Otis <[email-masked]>
Date: Wed, 31 May 2006 23:59:17 -0700

On May 31, 2006, at 2:22 PM, Douglas Otis wrote:

A few more typos noted at the end.

> 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 [email-masked] had a Sender
>    address of [email-masked].
>
> 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:
>

  t=   Signature Timestamp ([[pplain-text]]; RECOMMENDED, default is an
        unknown creation time).  The time that this signature was

3.6.2.1  Name Space

    All DKIM keys are stored in a subdomain named  
[[""_domainkey""]].  Given
    a DKIM-Signature field with a "d=" tag of ""example.com"" and an  
"s="
    tag of [[""sample""]], the DNS query will be for
    [[""sample._domainkey.example.com""]].

6.3  Compute the Verification
...
    3.  Using the signature conveyed in the "b=" tag, verify the
        signature against the header hash using the mechanism  
appropriate
        for the public key algorithm described in the "a=" tag.  If the
        signature does not [[validatee]], the verifier SHOULD ignore the
        signature and return with DKIM_STAT_INVALIDSIG.

6.5  Interpret Results/Apply Local Policy
...
    [[Oncee]] the signature has been verified, that information MUST be
    conveyed to higher level systems (such as explicit allow/white lists
    and reputation systems) and/or to the end user.  If the message is
    signed on behalf of any address other than that in the From:  header
    field, the mail system SHOULD take pains to ensure that the actual
    signing identity is clear to the reader.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Eric Allman <[email-masked]>
Date: Thu, 01 Jun 2006 07:32:02 -0700

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 
<[email-masked]> wrote:

>         The field MUST contain the complete list of header fields
> in the
>         (that is, they are treated as the null input,
> [[includiing]] the
>
>         header field values MUST immediately follow the header
> field  name
>             Verifiers MAY wish to track testing [[modee]] results
> to  assist
>             the signer.
>
>     [[the€]] "c=" (canonicalization) tag.  The DKIM-Signature
> header  field
>        INFORMATIVE IMPLEMENTATION NOTE:  Verifiers that truncate
> the  body
>     impeding the verification of messages from that domain.  This
> is not
> -Doug