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