ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments

2010-10-15 08:11:58
On Wed, 13 Oct 2010 23:22:07 +0100, Jim Fenton <fenton(_at_)cisco(_dot_)com> 
wrote:

Here's some text I propose for section 8.14, in place of the current
text. Bear in mind that this is in the context of the Security
Considerations section of the spec, so it is really a discussion of the
threat and how it is dealt with, rather than normative text.

OK, we're gradually moving towards an acceptable text, but we're not there
yet.

... Most of this is good advice, but section 5.3 is in the
context of section 5, "Signer Actions", and is therefore the wrong place
to add normative language for verifiers.  So I have added a new section
6.1.1 ...

+1

8.14.  Attacks Involving Addition of Header Fields

Many email implementations do not strictly enforce the message syntax
specified in [RFC5322]. One potentially exploitable consequence of this
is that an attacker who is capable of modifying a message in transit
could insert additional header fields that, if properly placed, could be
rendered to the recipient in preference to the originally signed header
fields.

I don't quite see what an attacker can usefully do by modifying messages
in transit. If they message was already signed (say by ebay), then the
attacker must somehow get ebay to sign a message with a useful (to him)
text in its body. So what is the benefit to him of making it appear From:
someone who is not Ebay (except maybe to ensure that replies get sent to
him - since I assume that MUAs that only display the first header will
also Reply-To that header)?

So I think there is a wide range of possible attacks involving duplicated
headers, and the text needs to be general enough to cover them.

According to [RFC5322] ... signed header fields
occurs.

Multiple occurrences ... as discussed in Section 3.5.

Suggested update to paragraph 2 of section 5.3:

Similarly, a message not compliant with [RFC5322], [RFC2045], and
[RFC2047] can be subject to attempts by intermediaries to correct or
interpret such content. See the Section 8 of [RFC4409] for examples of
changes that are commonly made. Such "corrections" may break DKIM
signatures or have other undesirable effects. Therefore, a DKIM signer
SHOULD confirm that a message is compliant with those specifications
prior to processing. </t>

+1

Insert prior to current section 6.1.2 (which becomes 6.1.3, etc.):

6.1.1 Validate the Message Syntax

The verifier SHOULD meticulously validate the format of the message
being verified against the requirements specified in [RFC5322],
[RFC2045], and [RFC2047].  In particular, limitations on the number of
occurrences of particular header fields specified in [RFC5322] section
3.6 SHOULD be verified. Messages found to be in violation of these
checks MUST return a PERMFAIL (message syntax error) verification result.

I have a problem with "meticulously validate". That is so hard to do that
most implepemters will take advantage of that "SHOULD" and omit the tests.
Much better to specify a less meticulous validation (header counting for
example) and then elevate that "SHOULD" to a "MUST".

Here is an alternative text that I published on Oct 6th (and on which
nobody commented). It is intended to go in section 6.1.1, presumably after
the paragraph beginning "If the "h=" tag ...":

"If the "h=" tag includes any header field for which, according to
[RFC5322], the maximum number within the header section is limited to 1,
and if more than 1 occurrence of that header field is present in the
message, the verifier MUST ignore the DKIM-Signature header field and
return PERMFAIL (multiple occurrences of XXX header field). Moreover, it
SHOULD so treat any header field defined in any other standards track
document to have a maximum occurrence of 1."

If you think that is a bit too vicious, here is a slightly more
permnissive version:

"If the "h=" tag includes any header field for which, according to
[RFC5322], the maximum number within the header section is limited to 1,
and if the number of occurrences of that header field present in the
message exceeds its number of occurrences in the "h=" tag, ......".



-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>