Pete:
I'll mostly let the editors reply to this, but there are a couple of
things I want to say first.
The first thing is that it's out of scope to address changes to things
that were in RFC 4871, which was approved by the working group, the
community, and the IESG in 2007, if it's simply a question of one or
two people not liking those things so much -- even if one or two of
those people now sit on the IESG. The working group has really made
an effort to avoid casual changes, and I support that, as chair and
document shepherd.
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.
This is one category of those things that appeared in 4871. I also
strongly disagree that they serve no purpose. It's useful to make it
clear when we have informative text that readers might misunderstand
to be normative. In any case, it's harmless, even if you don't like
it for stylistic reasons. But the bottom line is that these were
there before, and should stay there now... except, of course, for
removing or changing ones that are wrong or truly unclear.
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.
It's a very weak attack, and might be something we shouldn't bother
mentioning, but it is an attack, and one that the working group
decided to put into 4871. One thing that DKIM ensures is that someone
can't put, say, a line that says "viagra" into the middle of an
otherwise legitimate message without invalidating the signature. But
with relaxed body canonicalization, an attacker can insert and remove
spaces at will, wherever there's already a space, and that can be used
to create the word "viagra" in ASCII art, though quite crudely.
Personally, I think it's a silly thing to worry about, and that we
shouldn't mention it. But it's not up to me: it has working group
consensus from before RFC 4871 was published.
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.
Of course, that's why it's an informative implementation note. You're
saying that it's not worth pointing out pitfalls, and that we should
stick to the facts of the protocol. Maybe. Maybe this should be in
the informative documents, the overview and the deployment guide.
Maybe several of the similar items should. The working group chose to
put it into RFC 4871 instead.
It's worth noting that this is warning about a tag that the working
group considers VERY problematic, and that the WG thought hard about
removing in the progression to DS. In the end, we did not have
consensus to remove it. We do have consensus to leave in the
warnings.
10. Section 3.5, "h=":
INFORMATIVE EXPLANATION: The exclusion of the header field name
and colon as well as the header field value for non-existent
header fields allows detection of an attacker that inserts an
actual header field with a null value.
I cannot parse that sentence. I have no idea what it means.
It's a horrible sentence, and needs rewording (or removal). But I
know what it means. When you sign an empty header field (like
"Floob:"), you are signing the field name ("floob"), the colon, and
the terminating CRLF (with a null value). When you "sign" a header
field that doesn't exist in the message, you are signing a complete
null string: a null field name, and a null (absent) colon, value, and
CRLF. This is trying to point out the difference, and is explaining
how it prevents the insertion not just of "Floob: bleeg", but also of
an empty "Floob:".
24. Section 6.1:
A verifier SHOULD NOT treat a message that has one or more bad
signatures and no good signatures differently from a message with no
signature at all; such treatment is a matter of local policy and is
beyond the scope of this document.
The two clauses in that sentence seem contradictory. Is there an
interoperability requirement that I not treat messages in a particular
way, or is it a matter of local policy?
Yes, this is awkward. It is a requirement to prevent attacks that
rely on absent signatures being treated more favourably than "broken"
ones, or vice-versa.
I have serious issues with your comments on section 8, the Security
Considerations. But I'll leave that to the editors (and perhaps the
security ADs) to talk with you about.
Barry, DKIM chair
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html