ietf-dkim
[Top] [All Lists]

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

2010-11-08 10:32:01
On Monday, November 08, 2010 04:20:19 am Barry Leiba wrote:
As participant:

Here's how I see the situation.  It's purely as a participant, and has
no chair weight.  I think it does represent a compromise position that
should work.

Problem description:
An "attack" has been described that can be mounted by adding a second
"from", "subject", or possible other header field that is only
supposed to appear once.  This situation might fool a UA, filtering
software, or some other software into considering the added, unsigned
field as the "real" one.

Who is responsible for dealing with this situation?  If the DKIM spec
is at least partially responsible, to what extent, and what should it
say?


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.

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.

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.

4. We should agree to this or some variant of it, and then move on.
This is not meant to satisfy everyone.  In fact, it isn't what I'd prefer,
if I had my full choice.  But it takes care of the problem in a way
that I think is sufficient, and allows us to resolve the issue.

I think this oversimplifies the issue from a DKIM perspective.  

If this were added, should signatures that sign a second (non-existant) from 
header specifically to ensure header addition breaks the signature verification 
be verified if in fact the message hasn't been modified?  

Rather than fall back purely on 5322, I'd prefer to see something in security 
considerations that says if the count of a particular header field that is 
supposed to be limited (e.g. From and Subject) present in a message exceeds 
the number of signed fields, then the signature shouldn't be verified.  

Additionally, signing a message with (for example) two From: fields is not a 
problem in the context of this issue, so the advice not to sign such messages 
isn't particularly related.

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