Hector points out something that I was planning to say about this: that
it's really an issue for SSP (and so maybe that's the doc that's really
held up by this discussion). Here's how I see it:
From a base-spec point of view, as Dave says, we have the length tag,
the list of signed headers, and the canonicalization that all help
protect signatures against existing mailing-list behaviour. That means
that the base spec mostly has the issue covered, and I think a brief
discussion needs to be in there about what signers should consider with
respect to mailing lists, and what mailing-list software developers
should consider with respect to signatures.
The biggest issue that existing mailing lists have is what they do to
the subject header, since we particularly recommend signing the header
and since so many lists (including this one) modify the header. And, in
fact, many subscribers insist on that modification, even though they
could filter on headers such as List-ID instead.
One note here: the base spec COULD suggest that if the signature fails
to verify and the subject is signed and begins with "[", that the
verifier might retry after removing the "[xxx]" part. And then, much as
with that part of the message that comes after the signed length, the
verifier must decide what to do if the retry succeeds.
But in the worst case, the list has simply invalidated the signature,
and we say that this SHOULD be considered equivalent to no signature at
all. Absent SSP, this is no bad thing.
When we add SSP in, though, we have to consider the issue of a policy
that says "we sign everything" and a mailing list that breaks the
signature and does not add its own (remember, we're talking, now, about
existing mailing-list software that is not DKIM-aware). I DO think the
problem gets complex here, because we do not want to take this
behaviour, which is now considered acceptable, and suddenly declare it
to be "suspicious". And yet bad actors could take advantage of this
loophole.
Hector says:
> SSP is what sold me on DKIM when it was
first presented last year. Unfortunately, the deemphasis or movement away
from SSP has made DKIM a lot harder to justify.
I don't think we're de-emphasizing SSP nor moving away from it. What
we've said is that DKIM signatures and keys are defined by a pretty
mature spec that's gotten a lot of work put into it, but that SSP is
much less mature and needs significantly more work. And that we believe
DKIM has value without SSP, so the work on SSP should wait until after
the base spec is done. We've allocated several months to work on SSP
and, while some have opinions that differ markedly from Hector's about
it, we DO aim to spend the time on it.
In short, the responsible DKIM domain must have a way to tell potential
verifiers and "resigners" (LS or not) how to best handle their DKIM
messages.
If the domain doesn't care about potential downlink problems, then it can
only expect to be using a relaxed policy and therefore should not have any
reasonable expectation for protection. If he wants protection, then it
needs to declares the stronger, more 3PS restrictive or none/never policies.
I don't think this considers the issue I discussed a couple of
paragraphs up, where a signer wants to say that it signs everything, and
a DKIM-unaware mailing list breaks the signature. That is the very
issue that was brought up in Vancouver, and that some are quite
seriously concerned about. The complexity isn't in the changes needed
to mailing-list software; the complexity is in sorting it out WITHOUT
causing existing mailing lists, which are considered well-behaved today,
to be looked at suspiciously.
Barry
--
Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
