[ietf-dkim] DKIM SSP: Security vulnerability when SSP record doesnot exist?

[Arvel Hathcock]

> That nicely summarizes the problem I have with the fixation
> of *requiring* a tie-in to the origination domain.

I've seen no evidence that such a fixation actually exists on this list so 
you shouldn't have anything to worry with on this point.

> It's not that the tie-in does not provide incremental benefit.
> It is that it is incremental, rather than fundamental.

This is precisely the debate - whether the benefit of DKIM SSP is 
incremental or fundamental.  It largely depends on what your view is of the 
problem DKIM is attempting to address.  If your view of the problem is that 
the world lacks a signature based filter input then DKIM base is fundamental 
while DKIM SSP is incremental.  If your view of the problem is that email is 
plagued by unauthorized domain use in a RFC2822 identity header then DKIM 
SSP is fundamental and DKIM base is merely an arbitrarily designed servant 
of DKIM SSP.

I think that this group isn't going to go any further until it decides what 
the problem is.  I now fully embrace the wisdom of the "threat analysis" 
doctrine.

> Today we have no confirmable domain name identity to assess.
> With the DKIM basic mechanism, we do.  That's not a small
> improvement in the world.

One side continually makes this point as if the other hadn't already agreed 
to it a thousand times over.  Once more, yes, DKIM base is useful. Yes, DKIM 
base provides value.  Yes, DKIM base is an improvement, etc, etc, so on, and 
so on, ad nausium!  BOTH sides in the SSP debate will take FULL advantage of 
any "improvement in the world" that DKIM base can provide.  It's just that 
one side isn't content to stop there.  One side wants _ALL OF DKIM_ - not 
merely the mechanistic "how do I make a signature" half of it.  One side 
wants DKIM to play a role not only when a signature is found, but most 
especially and importantly when one IS NOT found.  Clearly, the authors 
envisioned this as it's fully 1/2 of the DKIM specifications as we have them 
today.  Clearly, the parent technologies from whence DKIM is supposedly the 
cross-product envisioned it as both have required SSP provisions.  Beyond 
doubt, the draft charter language assumes it.

The "threat analysis" will clear all this up.  By defining the problem that 
DKIM is meant to address we will also be defining the relative import of 
DKIM's SSP provisions.  So, you've seen our answers.  What are the answers 
to Russ' questions from the "signature-only" folks?

--
Arvel