Subject: Re: [ietf-dkim] New Issues: bunch of nits for base

From: Eric Allman <[email-masked]>
Date: Wed, 05 Apr 2006 21:35:47 -0700

That's a lot of nits.  Comments below.

> #1 Overview is still somewhat sales-ish. A bit more objectivity
> would arguably be more appropriate. E.g. "requires minimal new
> infrastructure" would be better stated as "reqiures no extensive
> new infrastructure", "transparent to..." is also a bit inaccurate,
> since there are some cases where DKIM is not transparent, e.g. some
> mailing list cases.

I guess I disagree with you on this one --- I think you're being a 
bit over-sensitive.  What's the difference between "minimal" and "no 
extensive"?  From a "sales-ish" point of view they seem equivalent to 
me.  I did change the "transparency" comment to "is compatible with 
the existing email infrastructure and transparent to the fullest 
extent possible" though.

> #2, section 1.2, 1st sentence, maybe "the question of the identity
> of..." would be better. As it is, the words don't quite make sense,
> even though I know what's meant.

Done.

> #3, section 1.2 "Recipients can..." should be "Verifiers can..."
> since most recipients won't look at DKIM stuff (unless I've gotten
> this wrong again;-).

Done.

> #4, section 2.5, an informative note after the 1st para might be
> nice, or is it obvious that obs-* are obsoleted? Are there no
> others to exclude?  Why not? That stuff is not obvious to me as it
> happens.

So noted.

> #5 section 3.3.3: "keys smaller than... are subject to brute
> force.." The fact is that every algorithm is subject to brute
> force. Whether or not factoring is considered brute force is also
> perhaps debatable. I suggest replacing with something like "using
> keys with a modulus shorter than 1024 bits may be considered unwise"

I've changed this to read:

        <t>Selecting appropriate key sizes is a trade-off between
        cost, performance and risk. Since short RSA keys more easily
        succumb to off-line attacks, signers MUST use RSA keys of at
        least 1024 bits for long-lived keys. Verifiers MUST be able
        to validate signatures with keys ranging from 512 bits to
        2048 bits, and they MAY be able to validate signatures with
        larger keys. Security policies may use the length of the
        signing key as one metric for determining whether a signature
        is acceptable.</t>
        <t>Factors that should influence the key size choice include:
        <list
        style="symbols">
        <t>The practical constraint that a 2048 bit key is the
        largest key that fits within a 512 byte DNS UDP response
        packet</t>
        <t>The security constraint that keys smaller than 1024 bits
        are subject to brute force attacks.</t>
        <t>Larger keys impose higher CPU costs to verify and sign
        email</t>
        <t>Keys can be replaced on a regular basis, thus their
        lifetime can be relatively short</t>
        <t>The security goals of this specification are modest
        compared to typical goals of public-key systems</t>
        </list>
        </t>

> #6 section 3.5 says that "Unknown tags MUST be signed but MUST
> otherwise be ignored by verifiers." I think s/signed/verified/
> would be a little better there on the basis that the tag presumably
> wasn't unknown to the signer. Feel free to ignore this though.

Updated to "Unknown tags MUST be signed and verified but MUST be 
otherwise ignored by verifiers."

> #7 section 3.5 defines the 'c' tag as Body c14n, but it actually
> specifies both c14n uses, so s/Body canon.../Canon.../

Changed to be "Message canon...".

> #8 section 3.5, "d=" bit, introduces the "i=" tag without
> explanation (its a forward reference). Suggest adding something in
> brackets to explain

Done.

> #9 section 3.5, "i=" tag. I think the "If the ...is
> unwilling...MUST be omitted" sentence is wrong, since its hard for
> a programmer to know who's willing to do what. Suggest saying that
> the localpart MAY be omitted and put anything else in an
> informative note.

Intro now reads "Identity of the user or agent (e.g., a mailing list 
manager) on behalf of which this message is signed (quoted-printable; 
OPTIONAL, default is an empty local-part followed by an "@" followed 
by the domain from the "d=" tag). The syntax is a standard email 
address where the local-part MAY be omitted.  The domain part of the 
address MUST be the same as or a subdomain of the value of the "d=" 
tag."

I've added: "INFORMATIVE NOTE:  The local-part of the "i=" tag is 
optional because in some cases a signer may not be able to establish 
a verified individual identity.  In such cases, the signer may wish 
to assert that although it is willing to go as far as signing for the 
domain, it is unable or unwilling to commit to an individual user 
name within their domain.  It can do so by including the domain part 
but not the local-part of the identity."

> #10 section 3.5, "i=" tag text says that if the local part is
> absent then the key MUST be valid for signing any address in the
> domain, but having read this far I've no idea how that's
> determined. A forward reference is needed here I think (or else I'm
> confused again:-).

See above.

> #11 section 3.5, "t=" I think it'd be no harm to specify the
> timezone here, its seconds-since-197001010000Z isn't it? (Modulo
> leap seconds or whatever.) And there should be a sentence saying
> the the x= value had better be less than the t= value if both are
> present, right?

"No harm"?  Downright important.  Done.

> #12 section 3.6, 1st para is a bit defensive while at the same time
> overselling DKIM. How about the following instead: "Signature
> applications require some level of assurance that the verification
> public key is associated with the claimed signer. Many applications
> achieve this by using public key certificates issued by a trusted
> third party. However, DKIM can achieve a sufficient level of
> security, with significantly enhanced scalability, by simply having
> the verifier query the purported signer's DNS entry (or some
> security-equivalent) in order to retrieve the public key." Maybe a
> bit wordy though.

Your definition of defensive is clearly different than mine.  I think 
your proposed wording is actually more defensive than the 
matter-of-fact statement we had before.  However, I've changed it 
anyway.

> #13 section 3.7 would be better off talking about the signature
> input bytes rather than hash calculations which will often happen
> inside some signature API. (This might change if the existing issue
> about separate body and header hashes gets accepted.)

I didn't understand this point.  In any case, the separate hashes has 
been accepted.  The whole section now reads:

        <?xml version="1.0"?>
        <ns:clipboard
        xmlns:ns="http://www.xmlmind.com/xmleditor/namespace/clipboar
        d"
        ><section
        anchor="hashing"
        title="Computing the Message Hashes"
        ><t
        >Both signing and verifying message signatures starts with a
        step of computing two cryptographic hash over the message.
        Signers will choose the parameters of the signature as
        described in <xref
        target="signer-actions"
        >Signer Actions</xref
        >; verifiers will use the parameters specified in the
        "DKIM-Signature" header field being verified. In the
        following discussion, the names of the tags in the
        "DKIM-Signature" header field which either exists (when
        verifying) or will be created (when signing) are used.  Note
        that <xref
        target="canonicalization"
        >canonicalization</xref
        > is only used to prepare the email for signing or verifying;
        it does not affect the transmitted email in any way.</t
        ><t
        >The signer or verifier must compute two hashes, one over the
        body of the message and one over the header of the message.
        Signers MUST compute them in the order shown.  Verifiers MAY
        compute them in any order convenient to the verifier,
        provided that the result is semantically identical to the
        semantics that would be the case had they been computed in
        this order.</t
        ><t
        >In hash step 1, the signer or verifier MUST hash the message
        body, canonicalized using the header 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 "XXX=" tag of
        the DKIM-Signature: header field.</t
        ><t
        >In hash step 2, the signer or verifier MUST pass the
        following to the hash algorithm in the indicated order.</t
        ><t
        ><list
        style="numbers"
        ><t
        >The header fields specified by the "h=" tag, in the order
        specified in that tag, and canonicalized using the header
        canonicalization algorithm specified in the "c=" tag.</t
        ><t
        >A single CRLF.</t
        ><t
        >The message body, canonicalized using the body
        canonicalization algorithm specified in the "c=" tag, and
        truncated to the length specified in the "l=" tag.</t
        ><t
        >A single CRLF.</t
        ><t
        >The "DKIM-Signature" header field that exists (verifying) or
        will be inserted (signing) in the message, with the content
        of the "b=" tag deleted (i.e., treated as the empty string),
        canonicalized using the header canonicalization algorithm
        specified in the "c=" tag, and without a trailing CRLF.</t
        ></list
        ></t
        ><t
        >After the body is processed, a single CRLF followed by the
        "DKIM-Signature" header field being created or verified is
        presented to the algorithm. &#160;The value portion of the
        "b=" tag (that is, the portion after the "=" sign) must be
        treated as though it were empty, and the header field must be
        canonicalized according to the algorithm that is specified in
        the "c=" tag. &#160;Any final CRLF on the "DKIM-Signature"
        header field MUST NOT be included in the signature
        computation.</t
        ><t
        >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.</t
        ><t
        >When calculating the hash on messages that will be
        transmitted using base64 or quoted-printable encoding,
        signers MUST compute the hash after the encoding. Likewise,
        the verifier MUST incorporate the values into the hash before
        decoding the base64 or quoted-printable text. However, the
        hash MUST be computed before transport level encodings such
        as SMTP "dot-stuffing."</t
        ><t
        >With the exception of the canonicalization procedure
        described in <xref
        target="canonicalization"
        ></xref
        >, the DKIM signing process treats the body of messages as
        simply a string of characters. DKIM messages MAY be either in
        plain-text or in MIME format; no special treatment is
        afforded to MIME content. Message attachments in MIME format
        MUST be included in the content which is signed.</t
        ><figure
        ><preamble
        >More formally, the algorithm for the signature is:</preamble
        ><artwork
        >    body-hash = hash-alg(canon_body)
            header-hash = crypt-alg(hash-alg(canon_header ||
        DKIM-SIG), key)</artwork
        ></figure
        ><t
        >where crypt-alg is the encryption algorithm specified by the
        "a=" tag, hash-alg is the hash algorithm specified by the
        "a=" tag, canon_header and canon_body are the canonicalized
        message header and body (respectively) as defined in <xref
        target="canonicalization"
        ></xref
        > (excluding the DKIM-Signature header field), and DKIM-SIG
        is the canonicalized DKIM-Signature header field sans the
        signature value itself, but with body-hash included as the
        "bh=" tag.</t
        ></section
        ></ns:clipboard
        >
> #14 section 5.1 2nd para. I can't see much point in this - would
> the spec be worse were this deleted?

I think this would diminish the spec.  I think it's important to 
point out that a DKIM-compliant signer doesn't have to sign messages 
that it's not willing to take some responsibility for.

> #15 section 5.4, 3rd para. Text is a bit odd - how's the signer
> supposed to know which fields it wants the verifier to "treat as
> trusted"? Also, the 2nd sentence is very MUA oriented. Suggest
> deleting the paragraph (though I like the "extreme skepticism"
> phrase).

I've changed the first sentence to read "Signers MUST sign any header 
fields that the signers wish to assert were present at the time of 
signing" (although I'm not wild about this).  The 2nd sentence 
needn't be MUA-oriented at all; the verifier might be making 
server-level spam decisions on the basis of various headers.

> #16 (like #13 above) section 6.3, last bullet: "Compare the
> decrypted signature to the message hash..." is wrong. PKCS#1 (and
> later) signature schemes require more, in the case of pkcs#1v1.5
> there should be an algorithm OID in the recovered plaintext as
> well. As before, suggest rephrasing this in terms of calculating
> the bytes input to a signature verification API.

I don't understand this one either.

> #17 Why the MUST on the textual representation in section 3.6.1?
> Seems like anything that can be mapped to this would be ok, and
> there's only a need for a MUST for the DNS case. Suggest
> restricting it that way.  E.g. were an XKMS key server option to be
> defined, it would likely represent the keying material in xml as a
> ds:KeyInfo or xkms:KeyBinding and there's no reason to prevent that.

Yeah, but that wouldn't be a text form, it would be an XML form.  I 
could change it to read "otherwise unstructured text form" --- will 
that do the trick?  With that in mind, I now have "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 MUST be used for any DKIM key represented in an otherwise 
unstructured textual form."

Of course, we could pull this out entirely and put it in another 
document.  But if we keep pulling things out of -base we'll have 
nothing left.

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 06 Apr 2006 08:49:20 +0100

Hi Eric,

Eric Allman wrote:
> That's a lot of nits. 

Only because the document's worth reading closely!

Deleted bits where there's nothing to say other than "ok".

Other than the new text resolving 1193, which should have a
thread of its own, none of these need hold up issuing base-01.

> I guess I disagree with you on this one --- I think you're being a bit 
> over-sensitive.  What's the difference between "minimal" and "no 
> me.  I did change the "transparency" comment to "is compatible with the 
> existing email infrastructure and transparent to the fullest extent 
> possible" though.

It is a totally subjective thing so I'm fine with the above.

>        are subject to brute force attacks.</t>

I'll shut up about it, but you *will* get comments that factoring
is not "brute force" which is a "technical term", in this case I
guess meaning trying all possible values for the decryption exponent.

>        compared to typical goals of public-key systems</t>

I suspect that this section will generate some more suggested
re-wordings - maybe it'd be good to pass it by some crypto type,
just to catch crypto-buzzword nits, e.g. some of the above is
specific to RSA, some isn't, and the text isn't always exactly
right in how it expresses that, e.g. s/2048 bit key/2048 bit
RSA modulus/ Again though I wouldn't hold up the document to
fix it - can be done later.

> I didn't understand this point.  

I think its the same point as EKR made that this document shouldn't
be a tutorial on how signature calculations work.

 > In any case, the separate hashes has

That, I think, is not a nit-fix and deserves a thread of its
own - any chance you could start that? (Without angle brackets:-)

> I don't understand this one either.

Same as EKR's above point again - don't go into details about how
the crypto works, that's specified elsewhere (which ought be
referenced if it's not now) and a description here will inevitably
be inaccurate or incomplete in some way.

Cheers,
S.