-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
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.
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.
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 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.
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.
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.
(2) It changes SSP from being *guidance* that a sender gives to a
receiver to a *mandate* that the sender gives to the receiver.
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.
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.
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). 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.
Jon
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII
wj8DBQFHXFEosTedWZOD3gYRArbyAKC7+DSfw/EE+wypgwa6UCZ7kjkyaQCfcLUe
ddkd6xwsal8GEUeI2YmgM2o=
=KSjY
-----END PGP SIGNATURE-----
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html