On 6/29/11 11:11 AM, Barry Leiba wrote:
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.
Yup, absolutely agreed. As I said, I do need to sort these comments into
"serious", "I hope the WG looks at", and "Pete makes a comment that can
be ignored". I didn't want to spring this long list on folks Thursday
morning and not at least give people a chance to digest them. I'll work
today on that list.
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.
Yes. Definitely in the category of "Pete makes a comment that can be
ignored". If the WG finds that implementation of 4871 was not hindered
by this, and it wasn't added without consideration, so be it. I hold my
nose and put up with it.
I also strongly disagree that they serve no purpose.
Bar BOF to be arranged on the "INFORMATIVE/NORMATIVE" verbal tick that
has developed in the IETF.
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.
So I don't understand. You're saying that a MITM can insert and delete
spaces freely, so they're going to be able to change my text to make it
appear that it has a different message? That would be an attack, but
rather insane.
I *suspect* that what this really means is that the *signer* can insert
funny messages. But (see below) *the signer cannot be the attacker*.
It's nonsense.
Either way, the paragraph needs clarification.
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.
Though this appears again later in the document.
You're
saying that it's not worth pointing out pitfalls, and that we should
stick to the facts of the protocol.
No, that's not what I'm saying. If you want to put in an admonition, so
be it. It's just not an attack.
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:".
Yes, it needs rewording or removal. :-)
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.
Clarification would be helpful.
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.
Ack.
Again, sorry for the brain dump. I thought it better to dump and fix
later than dump late. I am willing to accept that I did not make the
best of two non-wonderful choices.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html