-----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