I realize I'm a few days behind (traveling immediately followed by
jury duty), and that Jim already did a pretty good job of answering
this, but I think I can still add something to the discussion.
--On December 9, 2007 12:33:31 PM -0800 Jon Callas <[EMAIL PROTECTED]>
wrote:
I agree wholeheartedly with his basic premise, that SSP started off
being modest, and has grown into the experimental and
encompassing. I also agree that this isn't good.
IAWJ (I Agree With Jim): what is this early, modest SSP? The
earliest published in the DKIM work was draft-allman-dkim-ssp-00
(July 2005). In most ways, this was more complex than what we have
today, as Jim has noted, with the exception of handling=.
So I'm going to pull back and describe how I think we got here.
Back in the days of DKIM-base, we started with considering what
happens with broken signatures. We also believed that it would be
not uncommon for a legitimate message to get its signature broken
in flight.
Actually, we (or at least, I) started thinking about unsigned
messages first, since it seemed pretty obvious that senders that
wanted to sign everything would want recipients to be able to make
use of that information. I didn't originate this concept: it came
from DK (RFC 4870).
The next step was realizing that if messages with unverifiable
signatures were treated better than messages with no signature at
all, attackers would just insert bad signatures. There were two
options: treat messages with unverifiable signatures with more
prejudice (more suspicious, more likely to be the result of an
attack, whatever words you want to use) than unsigned messages, or
treat the two the same. Since we had reason to believe that there
might be a large number of unverifiable signatures in the short run
as a result of modifications during transport, treating them
differently seemed imprudent.
When you consider what the receiver is supposed to do with a broken
signature, the first suggestion is, "Well, do what you did before
DKIM." This is legitimate, if unsatisfying. It is more unsatisfying
the more that signatures can be expected to land unmolested.
Except that the first suggestion applied to unsigned messages, not
broken signatures. Otherwise, IAWJ.
Secondly, if you consider the senders for whom DKIM is most
valuable - -- big phishing targets -- they want the illegitimate
message thrown away.
Here's where the "how much can senders impose on verifiers?" question
starts to come into play. Some sites would like unsigned and
unverifiable messages thrown away, others might prefer that you treat
them like you would in a pre-DKIM world. Some large ecommerce sites
have arranged side agreements with large receivers to enable this
(such as PayPal and Yahoo), but this obviously does not scale.
This leads us to a nice confluence of events. The receiver has a
message it isn't sure what to do with, and the sender can offer
helpful advice. If the sender says, "I'd rather you threw away a
good message than accept a bad one," then the receiver has a hint
as to what to do with it. Don't bother trying to process it, just
junk it.
Thus is born SSP, and thus is born the "I sign everything" policy.
This is non-controversial, we all think it's great. As a receiver,
if I see a broken signature, do an SSP check and if it says "sign
all" I can now just throw the message with the broken signature
away.
Actually, thus is born handling=, and it apparently is controversial.
IAWJ: "I sign everything" means something else. This may be wrong;
perhaps "dkim=all" should imply that the sender would prefer that the
receiver immediately discard any messages without legitimate
signatures.
However, next comes an addition to that. If we assume there are
active bad guys, they'll just send their bad messages with no
signature. Consequently, we can solve this by redefining a broken
signature to include messages with no signature. It doesn't take
much of a stretch to consider no signature to be merely the most
extreme form a broken signature. This way, we end up will all
forged messages pretending to be from a signing domain to be
dropped at the receiver.
Historically this was not an addition. This was the very first
consideration.
This is undeniably a Good Thing. I support it, myself. However, it
is also precisely the place where SSP jumped the shark. All the
further mission-creep of SSP comes from this one
seemingly-innocuous, well- meaning change.
Again, it was original. I don't see how it jumped the shark at all.
This *radically* changes SSP in two fundamental ways:
(1) It changes SSP from being a protocol that governs the error
condition of an optional protocol to being a protocol that governs
*every* email received by *every* MTA.
Not true. It remains an optional protocol (the receiver doesn't have
to read information that it isn't prepared to use), and it does not
apply to messages with valid, first party signatures. I personally
expect that to be the majority of legitimate mail once DKIM is widely
adopted, but that's a personal opinion, and in any case the
legitimate mail is swamped by the garbage.
(2) It changes SSP from being *guidance* that a sender gives to a
receiver to a *mandate* that the sender gives to the receiver.
I think you've made a huge leap of faith here. For better or for
worse, even pre-DKIM the sender doesn't really know what the receiver
is going to do with the message (for example, if the receiver dropped
the message into the limbo of some quarantine or spam folder). You
described it correctly up above: ``the sender says, "I'd rather you
threw away a good message than accept a bad one," then the receiver
has a hint as to what to do with it.'' I don't see the a "mandate"
anywhere in that sentence, but I do see "hint".
The first one is troubling for a number of reasons. When we started
DKIM, we told the rest of the IETF that this was an optional
protocol, you didn't have to use it, and so on. We also cooed
softly at the people who worried about the increased DNS use,
arguing many ways that this wouldn't dramatically increase the
global load on DNS all that much.
And I don't personally believe it does increase the load
"dramatically". Yes, there will be additional DNS queries --- in
addition to the queries that most receiving MTAs do when the
connection opens (typically two or three: PTR then possibly AAAA then
A), on the MAIL command (varies based on implementation, but can be
as many as three --- MX, AAAA, A), possibly on the RCPT command (also
possibly as many as three), and to fetch the DKIM selector (one TXT
query). As Jim has pointed out, the current SSP draft maxes at three
queries, one of which is just to verify the existence of the
purported sending domain. We should probably change that to not
mandate an MX lookup, since the actual record type is irrelevant (an
ANY lookup might be good enough if we trusted the implementation,
which I have found to be spotty).
While this addition (SSP check on every message) is certainly a
Good Thing, it means that we've gone back on our word to the rest
of the IETF. I think it could be argued that that this violates
the DKIM charter, in spirit, if not in the letter.
This is pretty subjective. But for the record I disagree.
The second one is much subtler. It's a principle of email sending
that the receiver can do whatever they want, no matter how stupid.
While it may be useful for the sender to offer hints and guidance
to the receiver, the sender cannot mandate. While I don't know
how, I see here the makings of an exploitable architectural flaw.
And I don't see how SSP changes the underlying principle. The sender
isn't mandating, it's providing hints, or at most requesting.
I think we need to take a big step back from SSP. We need to
seriously look at all policies other than the original "sign
everything" policy and discuss them thoroughly. We need to
seriously look at that one little change and discuss how it
changed, as Dave said, the very *paradigm* of SSP.
I offer as a suggestion that we issue an SSP document that
describes only the basic broken-signature-only model of SSP with
only the one policy (sign-all).
I strenuously disagree with at least the first half of this proposal.
If you don't look at SSP on messages with no signatures, then SSP is
vanishingly close to useless. Attackers will simply send their
phishing messages without a signature, thereby guaranteeing at least
a chance of getting through. If SSP is that weak, receivers have no
incentive to consult it at all, and we get no operational experience
and hence cannot progress.
After that, we look at
enhancements to the model carefully. We seriously discuss whether
they are outside the charter because of the effect it has on the
global email infrastructure to turn DKIM from an opt-in protocol
to a you-must protocol. We also seriously have to look at other
policies to discuss their effectiveness along with their
environmental effects.
I'm not sure if you intentionally changed the topic from SSP to DKIM
here. Regardless of the details of SSP, DKIM remains optional. For
that matter, receivers don't need to do any scanning of their mail at
all today, and that isn't going to change. I certainly hope that
DKIM information will become valuable enough that most receivers will
/want/ to consult it, and I hope that they will care enough about the
information that senders care to provide in SSP to use that as well.
eric
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
