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
