Folks,
I've been reviewing 4871bis for the IESG review on Thursday. I've got a
huge number of comments. Some of them (e.g., the first two below) are
quite trivial or simple issues that I expect you'd either have no issue
with or that I'm happy to ignore; some of them are clearly not trivial
at all. I have not entered a ballot position yet, and I haven't sorted
through all of the comments to decide if any are worthy of entering a
DISCUSS, but I suspect that some of them are. I therefore wanted to post
this to the WG list so you all get an idea of what I'm thinking about.
Tomorrow I'll spend some time cleaning these up and sorting them by
category instead of by order of the document.
I apologize for the lateness of this review; it's probably something I
should have done a long time ago.
Comments:
1. I find the use of the word INFORMATIVE throughout the document
superfluous. No other word (e.g., NORMATIVE) is used in its place. I
think they should all be removed. They serve no purpose.
2. The ABNF 0* construct is not normally used. Why not just *?
3. Section 2.7: I don't understand what the word module means in this
context. It sounds like some sort of specific implementation, not part
of a protocol. I don't know what it means to deliver values to a module.
4. Section 3.4.4:
INFORMATIVE NOTE: It should be noted that the relaxed body
canonicalization algorithm may enable certain types of extremely
crude ASCII Art attacks where a message may be conveyed by
adjusting the spacing between words. If this is a concern, the
simple body canonicalization algorithm should be used instead.
This is not an attack, or at the very least it is not an attack on DKIM.
You can play this same game with MIME encodings or other textual tricks.
I don't see any justification for this note being in this document.
5. Section 3.4.5:
INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables
an attack in which an attacker modifies a message to include
content that solely benefits the attacker. It is possible for the
appended content to completely replace the original content in the
end recipient's eyes, such as via alterations to the MIME
structure or exploiting lax HTML parsing in the MUA, and to defeat
duplicate message detection algorithms. To avoid this attack,
signers should be wary of using this tag, and verifiers might wish
to ignore the tag, perhaps based on other criteria.
I don't understand how this is an attack. If the signer said, I'm
signing the first n bytes of the body of this message and the verifier
is able to verify that the signature is valid for n bytes of the body,
the algorithm has succeeded. At most, this should lead to an admonition
that unsigned data is not verified and therefore should not be trusted,
but that seems obvious. There might be an attack on an MUA that does not
verify the DKIM signature, but that seems outside the scope of this
document.
6. Section 3.5:
v= Version (MUST be included). This tag defines the version of this
specification that applies to the signature record. It MUST have
the value 1. Note that verifiers must do a string comparison on
this value; for example, 1 is not the same as 1.0.
Why string comparison here? There's no case sensitivity to worry
about. There's no character encoding to worry about. Why not instead
say, Note that verifiers must (MUST?) ensure that the value is '1'; for
exmaple '1' is not the same as '1.0'? (Seem similar text in 3.6.1.) And
why is the value not listed as plain-text?
7. Section 3.5: It would be nice to subsection each tag here. (e.g.,
v= could be 3.5.1, etc.)
8. Section 3.5, h=:
It would be nice to add a sentence similar to the one in 5.4: The field
MAY contain multiple instances of a header field name; this means that
multiple occurrences of the header field are being signed by the signing
algorithm.
9. Section 3.5, h=:
INFORMATIVE EXPLANATION: By signing header fields that do not
actually exist, a signer can allow a verifier to detect
insertion of those header fields after signing. However, since
a signer cannot possibly know what header fields might be
created in the future, and that some MUAs might present header
fields that are embedded inside a message (e.g., as a message/
rfc822 content type), the security of this solution is not
total.
a. I don't understand what MUAs presenting header fields that are
embedded inside a message has to do with anything.
b. I don't know what the words, the security of this solution is not
total are supposed to mean.
Don't you simply mean: However, since a signer cannot possibly know
what header fields might be defined in the future, this mechanism can't
be used to prevent the addition of any possible unknown header fields.?
10. Section 3.5, h=:
