ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Proposal for specifying syntax and semantics for multiple signatures

2006-03-30 18:01:17
Some comments below.

Paul Hoffman wrote:
Greetings again. This follows up on the desire to allow multiple
signatures in the same message.

---------------------
Summary:
A sender signing a message that already has one or more DKIM-Signature
headers keeps the earlier headers, signs over them, and optionally says
whether or not they were verified before signing.

---------------------
Rationale:
Signers need a way to attach multiple signatures when transitioning from
one signature algorithm to another, when transitioning from one hash
algorithm to another, and even from one protocol version to another.
Further, there are many scenarios where a sender is forwarding a message
that is already signed,  and wants to add its own signature. This must
be done in a way to prevent bid-down attacks during transitions, and
also must be done in a way so the recipient can unambiguously determine
the order in which the signatures appeared.

---------------------
Changes:

Add to section 3.5:

    p= Earlier signatures (plain-text; REQUIRED if there is already one
    or more DKIM-Signature header in the message). This tag lists the
    hashes of the DKIM-Signature headers that exist before this
    DKIM-Signature header is added, possibly adding the result of a
    verification of done by the party creating the current
    DKIM-Signature header. The hash is computed using the hash algorithm
    that is used in the signing algorithm (taken from the "a=" tag),
    using "simple" header canonicalization on the DKIM-Signature header.
I believe that some signer and verifier APIs have trouble handling
"simple" canonicalization because they don't present the whole header
field.  It may be problematic to mandate "simple" here; why not use the
same header canonicalization specified for the signature?
    The signer MAY include an indication of whether or not a particular
    DKIM-Signature header was verified; the absence of this indication
    is interpreted by the recipient that the verification was not
    performed. The order of the hashes MUST be from the last
    DKIM-Signature header in the message to the first.

    sig-p-tag = %x70 [FWS] "=" [FWS] sig-p-tag-body
                       0*( *FWS ":" *FWS sig-p-tag-body)

    sig-p-tag-body = sig-p-tag-hash [ "," sig-p-tag-result ]

    sig-p-tag-hash = base64string

    sig-p-tag-result = "verified-ok" / "verified-failed"
                         / "not-verified" / x-sig-p-tag-result
I'm concerned that including verification results is going to introduce
a whole bunch of new semantics (and possibly transitive trust) to the
multiple-signature case.  If a later signer says they didn't verify the
previous signature, or that verification failed, are they taking
responsibility for the message or not?  If they are in either case, how
is their verification result relevant to the recipient's verifier?

Change in the "h=" description of section 3.5:
OLD:
    The field MUST NOT include the DKIM-Signature header field that is
    being created or verified.
NEW:
    The field MUST NOT include any DKIM-Signature header field.

Change section 4 to read:

    4.  Semantics of Multiple Signatures

    A signer that is adding a signature to a message inherently signs
    all DKIM-Signature headers that exist in the message before the new
    signature using the "p=" tag. If a single signer adds multiple
    signatures, such as using different signing or hashing algorithms,
    each signature stands on its own, meaning each signature covers all
    of the previous signatures, even ones from the same signer.

    A receiver can always determine the order in which the signatures
    were applied based on the "p=" tag. If the tag is absent, that
    signature is the first signature on the message. If the tag is
    present, the number of hashes in the value indicate how many
    signatures were present before this signature was applied.

    A signer applying multiple signatures with different signing
    algorithms SHOULD first sign with its most-preferred algorithm, then
    with the next-most-preferred, and so on. This ordering prevents an
    attacker from removing more-preferred signatures from a message
    without the recipient being able to detect the removal.

    Signers MUST NOT remove any DKIM-Signature headers from messages
    they are signing, even if they know that the headers cannot be
    verified. Doing so would break the chain of signatures.
Aside from wording nits ("header" -> "header field") I don't see
anything else wrong with this proposal, other than its complexity.  As
far as the bid-down attacks are concerned, I think this is an
overreaction; signers wouldn't have a good reason to use any algorithm
that's that thoroughly broken.  I'm also concerned about the prospect of
DKIM verification yielding other than a binary result, if valid
signatures cite others that they say they couldn't verify.

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