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
