Hi, Barry,
I think we are in general agreement. I'm just trying my best to see how to
make sense out of DKIM. Who knows maybe DKIM is simply not a consideration
for the MTA software. Maybe it should be left for sysops to implement on
the external edges.
But if its something we are to consider for implementation into our
framework, well, I can only tell give you my honest engineering assessment
because in the end, it all has to make sense for our customers and for our
support staff as well. We will not going to introduce something that will
cost more in support.
In a direct 1 to 1 topology, a signature is expected to survive.
In a topology where there is middle ware, the ideal "backward compatible"
model is to describe what it will take to make sure the signature survive.
You can't do anything about legacy software and it would be the
responsibility of the DKIM domain to be well aware of the repercussions of
submitting signed mail into a world of unknowns. He can not expect it to
survive.
However, If we are being asked to find out what it will take to allow DKIM
signatures to survive a mailing list in a modern, still supported software
market, well, I think SSP is cost effective way to control the impact and
also help keep the DKIM security blanket intact.
What I do not accept (or rather do not normally work as such) is the
incremental "fix it later" design approach when the most obvious is right
there in front of us. It is unreasonable to expect that verifiers will
emerge simply to extract the valid messages of a 80% chaotic sea of
uncertainty, and to ignore those that purport to be DKIM ready yet fail for
some unknown reason. This is unreasonable and it is makes DKIM harder to
justify.
My main points are can be summarized and itemize as such:
1) Recognize we do have legacy software and to do our utmost to help
minimize impact.
2) Recognize we do have current supported software and to do our utmost to
help prepare them to minimize impact.
3) Recognize and highlight to DKIM implementators to consider the impact
they will have on the potential damage of their domain reputation.
What does this mean?
Well maybe when targeting DKIM mail for a mailing list path, it might mean:
1) Binding consideration should probably not include the subject header
because it is at risk of being altered. Same with any other header that is
subject to change in a list environment, i.e., Reply-To:
2) The length Z= tag should be used.
3) Consider not using DKIM domains at all for public list mail.
4) Use policies that help control the abuse.
DKIM domains need to take responsibility of what they are signing and do so
in appropriate manner to minimize impact. A domain can not expect a
signature that is most often found to be abused (broken) most of the time,
to be viewed with trust the few times it is found to be successfully
validated.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Barry Leiba" <leiba(_at_)watson(_dot_)ibm(_dot_)com>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Wednesday, March 15, 2006 9:44 AM
Subject: Re: [ietf-dkim] Concerns about DKIM and mailiing lists
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
(leiba(_at_)watson(_dot_)ibm(_dot_)com)
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html