Re: [ietf-dkim] Tracing SSP's paradigm change

[Jim Fenton <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

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
> junk it.

This is the "handling" flag, which was just introduced in the latest
draft.

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

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
unsigned messages.
>
> (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
SPF.

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

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

- -Jim

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHYN7VR3t0p2Nw35URAre9AJ0UPKHDid1Lzf9ejdSPxqSMvc810gCghCbV
9y2u6y3ylbEW2JJ3vFHGIks=
=WnMn
-----END PGP SIGNATURE-----
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html