-----BEGIN PGP SIGNED MESSAGE-----
I have been avoiding this thread, because it does not apply to a
particular issue, but it seems to go on and on...
Jon Callas wrote:
It's been hard over the last few days to keep pace with all of the
messages here, so my comments are on the basic notion that Dave
had brought up.
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.
What is the modest SSP that everyone speaks of? The first SSP draft
that I know of is draft-allman-dkim-ssp-00, dated July 9, 2005, prior
to the chartering of the DKIM Working Group. It contains the
"unknown", "all", and "strict" policies (although they were known as
~, -, and ! respectively), as well as a "no mail" policy. It not only
checks the local-part of the email address, it has a provision that
allows sender signing policy (as it was known then) to be expressed at
the user level. It searches up 5 levels of hierarchy to protect
against sub-sub-sub-domain attacks. It includes a reporting address
and a testing flag.
The only substantial thing that has been added is the handling tag.
In so many ways, SSP is much more modest now than before.
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
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
By "do what you did before DKIM", I gather you mean that you consider
the signature not to exist. If broken signatures are treated any
better than non-existing signatures, this invites attackers to attach
invalid signatures to messages.
Secondly, if you consider the senders for whom DKIM is most
valuable -- big phishing targets -- they want the illegitimate
message thrown away.
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
This is the "handling" flag, which was just introduced in the latest
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
No, that's not what the "I sign everything" policy says at all. Since
the message doesn't have a valid signature, SSP says the message is
Suspicious. The verifier can use that information however it pleases.
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.
Again, not dropped, unless you're talking about the handling tag.
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.
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.
Application of SSP to only messages containing broken signatures has
*never* been proposed in any SSP draft. To do so would create an
incentive not to deploy DKIM: there would be the fear that
application of a DKIM signature might hinder delivery of messages,
because of the potential for breakage that would not exist for
(2) It changes SSP from being *guidance* that a sender gives to a
receiver to a *mandate* that the sender gives to the receiver.
Again, you are confusing the practices with the handling tag, and even
the handling tag isn't a mandate.
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.
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.
I'd like to know what part of the charter you think this violates.
So, let me get this right: We allow domains to optionally publish a
policy (practice) that says "I sign everything" but we don't even
check that when we get something that isn't signed. How can that
possibly be useful?
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.
It's about as non-mandatory as I can think of making, other than
making it a non-normative implementation note (which of course I'll do
if the WG consensus says so). Beyond that, we're in the "treat the
message (hint-hint, nudge-nudge) with prejudice" realm, which is more
dangerous than being more specific, as Scott Kitterman has noted about
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 would like to know *when* it changed, and then I would have context
for *how* it changed.
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). 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
SSP in no way turns DKIM from opt-in to you-must. Domains that don't
publish SSP have their mail treated as non-Suspicious, regardless of
the presence or absence of signatures, which is the most favorable
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
NOTE WELL: This list operates according to