ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] FW: Getting resolution on the "double header" issue

2011-02-18 12:17:09
On Wed, Feb 16, 2011 at 3:52 PM, Murray S. Kucherawy 
<msk(_at_)cloudmark(_dot_)com> wrote:
This is the last text that I circulated on the bogus header matter, in reply 
to Barry's proposed path to resolution.  The group was pretty exhausted from 
debate at that point so there was little response.

-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Barry Leiba
Sent: Monday, November 08, 2010 1:20 AM
To: IETF DKIM WG
Subject: [ietf-dkim] Getting resolution on the "double header" issue

Proposal:

1. The DKIM spec is responsible for describing the problem in terms of
how it relates to signed and unsigned versions of the fields.  That's
the stuff in 8.14.

Concur.  I worked through an 8.14 proposal a couple of weeks ago using input 
from the list.  The last text I have was:

8.14 Malformed Inputs

DKIM allows additional header fields to be added to a signed message without 
breaking the signature.  This tolerance can be abused, e.g. in a replay 
attack, by adding additional instances of header fields that are displayed to 
the end user or used as filtering input, such as From or Subject, to an 
already signed message in a way that doesn't break the signature.

The resulting message violates section 3.6 of [MAIL].  The way such input 
will be handled and displayed by an MUA is unpredictable, but in some cases 
it will display the newly added header fields rather than those that are part 
of the originally signed message alongside some "valid DKIM signature" 
annotation. This might allow an attacker to replay a previously sent, signed 
message with a different Subject, From or To field.

Because of this, DKIM implementers are strongly advised to reject or treat as 
suspicious any message that has multiple copies of header fields that are 
disallowed by section 3.6 of [MAIL], particularly those that are typically 
displayed to end users (From, To, Cc, Subject).  A signing module could 
return an error rather than generate a signature;  a verifying module might 
return a syntax error code or arrange not to return a positive result even if 
the signature technically validates.

Senders concerned that their messages might be particularly vulnerable to 
this sort of attack and who do not wish to rely on receiver filtering of 
invalid messages can ensure that adding additional header fields will break 
the DKIM signature by including two copies of the header fields about which 
they are concerned in the signature (e.g. "h= ... 
from:from:to:to:subject:subject ...). See Sections 3.5 and 5.4 for further 
discussion of this mechanism.

Specific validity rules for all known header fields can be gleaned from the 
IANA "Permanent Header Field Registry" and the reference documents it 
identifies.

2. The DKIM spec should probably say that signers need to sign valid
messages, and, therefore, SHOULD NOT sign things like this.  Text
along the line of this might work well:
"Signers SHOULD take reasonable steps to ensure
that the messages they're signing are valid according to [RFC 5322,
etc]."  Leaving the definition of "reasonable" out allows flexibility.
It may be waffly, but I like the approach in this case.

Works for me.  How about:

3.10. Input Requirements

DKIM's design is predicated on valid input.  Therefore, signers and verifiers 
SHOULD take reasonable steps to ensure that the messages they are processing 
are valid according to [MAIL], [MIME], and any other relevant message format 
standards.  See Section 8.14 for additional discussion and references.

3. It'd be reasonable for the DKIM spec to remind verifiers that
signers aren't supposed to sign stuff like this, so they might
consider that when deciding what to do with it after verification.
It'd be reasonable to remind them of this particular case.  But
I think that all ought to be informative text.

Yup; the above two amendments cover both cases.


+1

-- 
Jeff Macdonald
Ayer, MA

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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