works for me (to the mailing list this time) On Nov 8, 2010, at 4:20 AM, Barry Leiba wrote:
> I have a chair statement to start with, and then the rest of this > message will be as a participant. > > As chair: > We have gone off in the weeds on the "double header" issue, and are > fighting with ourselves. The chairs need everyone to aim at getting > some rough consensus on this, so we're asking this: let's focus, as we > once did, on working together to achieve a result that most of us, at > least, can live with. That means that many people will not get it > just the way they want it, and you might not see a result that you > consider ideal. I think we're close enough, really, on this that we > can still get a result that we consider acceptable. > > Because we're in the middle of the IETF meeting, some of us -- > including the chairs -- are very busy this week. Let's set a deadline > of 24 November, and say that by that date we will have an answer that > has rough consensus. Please, folks, give and take, and work together > to reach that. > > As a side issue, I would like the 4871bis editors to post a message by > that same date summarizing the other open issues with 4871bis, and > their assessment of the current consensus state of them. We would > still like to get the issues resolved and get 4871bis to the IESG in > December, probably for the 16 Dec telechat. > > > 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. > > Barry > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
