[Top] [All Lists]

Re: [ietf-dkim] Collection of use cases for SSP requirements

2006-11-10 09:49:46
Thanks Pat, this is useful feedback. Inline:

Patrick Peterson wrote:

3 months and 1300 mailing list posts ago, I wrote that I was going to
survey some senders on SSP use cases and report results back to the
list. At long last, here are the results.
Requirement #1. More aggressive practice options
Senders are concerned the current options aren't aggressive enough to
cause change in how spoofed email is handled. Without such a change
implementing DKIM is of little value to them.

Another way to state this requirement is that there is a difference
between, - I sign all email, and
- I sign all email, treat unsigned or invalid signature with suspicion,
- I sign all email AND have enough confidence in the reliability of
signatures AND the risk of allowing spoofed email is high enough that I
choose to accept the risk and therefore state that receivers should drop
unsigned/invalid signature email.

The current taxonomy only has bullet 1 and something inbetween bullet 2 and 3. There's quite a bit of contention about flat out stating what a receiver should do, which is quite reasonable: we really can't predict why receiver's do what they do (should a honey pot, for example, drop them too?). In the requirements draft, SSP was presented as being an information service first and foremost. In that vein it seems fine for a service to report some bogosity scale, but stop short of declaring the actual message disposition. In reality, if the protocol is successful I can't imagine that the receivers won't do exactly what you hope. But by not specifying drop it does save us from a really unpleasant rathole which is ultimately futile for us to specify anyway: a receiver will dispose of the message as they see fit regardless
of what we say.

Requirement #3. Feedback of invalid signature/unsigned mail
Senders are concerned that the #1 item that will prevent them from
moving to aggressive practices is the inability to identify errors.
Errors on their part (failure to implement signing, improper signing),
receiver errors (noncompliant implementations of DKIM validation) or
anything else that Murphy's Law says will happen. They would like a
feedback mechanism to be defined that provides this feedback. Defining
this mechanism does not require it to be implemented by any receiver;
failing to define this mechanism makes it impossible to implement easily
for anyone. (Without going too far down the solution avenue, senders
felt one possible solution to receiving an excessive number of
invalid/unsigned feedback emails during a large-scale spoofing attack
was to state that they only wanted feedback for emails which originated
from their IP space as defined by their SPF record. Not a complete
solution as envelope sender not equal From: and mailing list traffic
doesn't originate from their IP space, but many felt this might be a
good compromise solution.)
Here's a question: is this a severable problem from SSP itself? My limited experience with Murray's auto-magic error reporting in his DKIM milter is that this a very complicated problem and that we have not considered it in any depth. What are the security considerations (ddos?)? What is the reporting mechanism? What exactly do they need to glean from the report? Should these be summaried? What about the information leakage implications? Etc, etc. I'd be *extremely* nervous to just throw this in without much thought as the likelihood of unintended consequences seems really high.

4.2.  Problem Scenario 2: Illegitimate Domain Name Use
  3. A provides information that it signs all outgoing mail, but places
an expectation that it should arrive with an intact signature, and that
the receiver should be suspicious if it does not.
  4. B could use this information to bias its filters such that it
looks much more suspicious.
A set of senders really want B to drop this email. Giving them to
vocabulary to state this is their desire. ISPs are of course free to do
as they see fit, but providing them with more granular information is

Yeah, but I'm afraid that actually offering disposition advise is going to lead us down that problematic rathole. Frankly, I'm rather worried about just the opposite of what you're customers have been saying: that receivers will *overreact* to a
failed signature, especially in the 1st scenario.

NOTE WELL: This list operates according to

<Prev in Thread] Current Thread [Next in Thread>