[ietf-dkim] Tracing SSP's paradigm change

[Eric Allman]

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 <jon at callas.org> 
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