Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim

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