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

I'm going to reply to this message twice.  This is a short note, but 
given the size of your critique and the fact that we got less than 24 
hours to look at it before the meeting, I'm planning on doing a more 
detailed reply later.
Briefly, please consider Patrick Peterson's response dated 12/4 
02:18:51 AM to be included here.  I agree with the gist of everything 
he and other people such as Scott and Wietse have to say.
* 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.
* You obviously dislike the way SSP handles multiple From field 
addresses, and yet you offer no alternative.  I don't like it either, 
but just complaining isn't constructive.  I will point out that using 
Sender: was considered and rejected, so unless we want to reexamine 
that, that's not the answer either.
* I agree with the folks who say that "Suspicious" is simply a 
defined term in this document, and (as in any contract) it doesn't 
necessarily carry the connotative baggage of broader language.  None 
the less I'm not wedded to that word; we can call it "Orange" if we 
want.
* 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.
* 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.
* You suggest moving _ssp out of the _domainkey subdomain.  However, 
I think it's worthwhile having it there in the event that the 
_domainkey subdomain is delegated.  It seems logical to keep 
everything together.
* 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.
OK, that's it for comments for now.  And really, this /is/ the short 
version.
eric
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html