Eric Allman responding to Dave's Review:
* Several places you compare this version (unfavorably) to "the original
SSP specification". Which one would that be? There was _policy in DK,
and some stuff in draft-allman-dkim-base that got pulled out, but I
don't recall anything that got further than a very rough draft.
Personally, I thought the original "draft" was very clear and concise.
It simply lacked the 3rd party issues.
* Several places you refer to reputation. But if I recall correctly we
explicitly avoided using that word, at least in part because it's only
one of a number of mechanisms. Making an assumption that SSP will be
backed up by reputation dramatically expands the scope of the document
in a way that doesn't seem productive.
+1
* You seem to think that doing SSP lookups on third-party signatures
will increase traffic dramatically. I don't think that's at all clear.
By far the majority of the SSP traffic in the short run will be for
messages that have no signature at all. In the longer run it comes down
to what percentage of email traffic is one-to-some (i.e., a first-party
signature) vs. how much goes through mailing lists or other cases that
would have third-party signatures. Of course, the majority of email
will be spam/phishes, and that's a bit harder to predict since they
change so fast, but my first guess is that most of it will be unsigned
and hence require an SSP lookup anyway.
+1,
There is a double edge sword here and I think it all depends on the type
of policy domains begin or leans towards using, which is why I had an
"itch" with the "SSP only required if no signature" and "Ignore if
Failure" concept.
The logical and reasonable premise is:
Short Run --> More SSP lookups
Long Run --> Less SSP Lookups
The long run will include a higher rate of fraud, especially if there is
relaxed policies which is the default, hence, most likely the long run
will include more or equal me amount unsigned fraud attempts. IOW, the
bad guy does not have to adapt to anything related to DKIM or relaxed
policies.
The more stronger policies exist, theoritcally we will get less fraud.
However, two things might occur with the bad: a) Since there are more
stronger policies, all he needs to do is create a fake signature. It
doesn't have to be correct, and b) begin to target non-supportive
DKIM/SSP systems.
Therefore, IMO, there might be a tendency to do an SSP first in all
cases (of course, the better system will cache this) to address the long
run potential of higher fraud.
IOW, short or long run, if the majority are relaxed policies, the bad
guy doesn't had to anything. He doesn't need to adapt. We only begin to
see a shift, a change in pattern as the policies become stronger.
* You seem to think that declaring messages that come from domains that
are not accessible (i.e., a reply would fail with NXDOMAIN) "make(s) it
clear that SSP has moved seriously into more general aspects of
receive-side analysis." However, this step is required to make the
algorithm work; without it there is an obvious security hole. However,
I do agree that a flowchart would help. I think I have a fairly current
around somewhere already, but it's not in ASCII.
+1, the same applies to DKIM in the long run. The more DKIM signatures,
the more potential for NXDOMAIN key lookups.
This is partly why an upfront SSP lookup can assist in the process.
The whole theory of DKIM success is based on the premise that in the
long run, it will be standard practice to have DKIM "VALID" signatures
in the majority of messages.
The theory breaks down when the long run includes a signficant amount of
invalid signatures.
So SSP or no SSP, there will be a drastic overhead problem in HASH
computation.
In my view, the optimization will make it prudent that:
- SSP is lookup first, and
- we have stronger policies.
The only argument against SSP being looked first, is when we have
network wide design assumption of:
invalid signatures <<<<< valid signatures.
But what if the long run shows?
invalid signatures > valid signatures.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html