Re: [ietf-dkim] SSP acceptance chart

On Nov 4, 2005, at 2:10 PM, Hector Santos wrote:
> > The criteria would be limited to that within the signing-
> > domain.
> Ok, ok, I think I am understanding now. :-)
>
> So now, the signing domain now has a "SDP " (Signer-Domain Policy),  
> that he
> defines and controls and can use to regulate the free-lancing and  
> possible
> fraudulent usage of OTHER domains From Header?
No, not other domain's From header.  Automatic acquisition of  
bindings requires both the signing-domain and related email-address  
domains match.  A message containing these items could then establish  
requirements for any subsequent messages.  Protocol mandates could  
also be established at server verification, as part of the DoS  
protection mechanism.
From: Jon Doe <ceo(_at_)big-bank(_dot_)com>
To: Joe <1234(_at_)some-isp(_dot_)com>
DKIM-Signature: a=rsa-sha1; d=big-bank.com; s=week23
 c=simple; q=dns; t=1117574938; x=1118006938;
 h=from:to:subject:date;
 w=b;             (broad binding assertion)
 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR

With this type of message captured with the w=b assertion, an email- 
address with the domain <big-bank.com> but not also accompanied by a  
signature <big-bank.com> would raise an automatic alert.
However, imagine you have a close friend that has an account of  
jane_doe at some-big-isp.com which allows any email-address to be  
sent.  The provider some-big-isp.com includes an opague-identifier,  
where a portion is declared persistent with the access account.   
Jane_doe uses the email-address Jane_doe(_at_)some-college(_dot_)edu sent from  
some-big-isp.com.  You want to be able to recognize your friend, so  
you manually capture the identifiers:
From: Jane Doe <jane_doe(_at_)some-college(_dot_)edu>
To: Joe <1234(_at_)some-isp(_dot_)com>
DKIM-Signature: a=rsa-sha1; d=some-big-isp.com; s=week14
 c=simple; q=dns; t=1117574938; x=1118006938;
 h=from:to:subject:date;
 w=n;            (narrow binding assertion)
 u=AAA023057;    (opaque-identifier)
 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR

Let's say there is a convention where the alpha portion is not  
considered persistent. The account of 023057 would be used to capture  
a pseudo-certificate that identifies Jane Doe.
<Jane_doe(_at_)some-college(_dot_)edu><some-big-isp.com><O-ID:023057>  (pseudo- 
certificate)
If anyone attempted to spoof as your friend from a different account  
at some-big-isp.com, you would receive an alert that this message may  
not be from your friend.  Perhaps you send back a message to your  
friend asking if they changed their account for some reason.  Perhaps  
they were using their neighbor's computer, so you merge this pseudo- 
certificate to their profile. (Perhaps part of the address book.)

> So the email service now defines how the policy of people's property?
No.  Now the signing-domain can define recommended bindings.  These  
bindings could only be automatically applied when the domains of the  
email-address and signing-domain match.  These bindings may cause an  
alert to be raised on messages that subsequently fail this match.

> For example, you might stop someone from using bgates(_at_)microsoft(_dot_)com 
> or
> mike(_at_)yahoo(_dot_)com but you allow, hector(_at_)santronics(_dot_)com or  
> user(_at_)public(_dot_)com(_dot_)
This type of automatic binding and subsequent blocking could not  
occur unless the signing-domains were within microsoft.com, or  
yahoo.com.

> What criteria do you use to decide unless you query some domain DNS  
> record?
The key, and only the key, is the DNS record queried.  If the key  
indicates delegated ('d='):
 TXT "v=DKIM1; p=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav 
+yuU4zGeeruD00lszZVoG4ZHRNiYzR; d=n"
Then the opaque-identifier and the selector must match, if present,  
and the binding assertion would be obtained from the key where, in  
this case. the assertion would be narrow.
If the key has not been delegated, which means the signing and  
signature header is controlled by the domain, then the binding  
assertions are obtained from the signature 'w=' and the opaque- 
identifier 'u=' is independent of the selector 's='.
> Or you query a common 3rd party repository DNA service, free,  
> commercial or
> otherwise to find out of santronics.com paid his fees?
An accumulation of broad-bindings of matching email-address/signing- 
domains can be automatically retained at the MDA/MUA as discovered.   
This would establish requirements for subsequent messages  
opportunistically.  There would not be any service queried, as none  
would be required.  Once santronics.com becomes known by the system,  
where perhaps unknown domains receive a Temp Error for a period of  
time, then whatever requirements santronics.com has established for  
santronics.com can be expressed automatically when a broad-binding is  
asserted.  Narrow-bindings would only be expressed manually at the MUA.

> > The signing-domain centric approach imposes fewer
> > constraints and works far better with exiting practices and
> > applications.
> I don't see that doug. I still have to modify my softare to do a  
> SDP and
> now, I have to get product liability insurance in case I am sued by  
> DOMAINS
> who claims mal-practice, negligence and possible tortious  
> inteference when
> their domains are blackListed due to user abuse originating from my  
> email
> service supporting SDP.
These are as strong or stronger assertions than that found in an  
unsigned DNS record which also pertains to just a single domain.  As  
this is expressed by way of the signing-domain, accountability for  
any abuse is kept at the signing-domain and not passed to the email- 
address.

> In other words, to minimize RISK for SDP, you are requiring all  
> DOMAINS to
> subscribe the the DNA service or some SDP repository.
You keep bringing up DNA, but I can not see why.  This is about how  
to identify unique sources of email, and to exclude non-complaint  
sources when there is an expressed desire by the _affected_ domain.

> Did I miss something?
I think so.

> > The signing-domain centric approach offers a means for
> > automatic limitations with respect to email-addresses, in a far more
> > flexible manner than can be achieved otherwise. When captured on-the-
> > fly, the signing-domain centric bindings also require far less
> > overhead. : )
> You mean an immediate SDP lookup at the point of entry?  Neat. So  
> instead of
> a SSP lookup, your proposal is to do a SDP lookup.
There is no lookup beyond what is retained locally.  This retention  
can be at either the MDA, or the MUA or both.  It is just a matter of  
retaining information as it is discovered.  For broad-bindings, it  
would be just the domain name itself that would need retaining.  How  
this gets accumulated and distributed is not really critical.  I  
suspect that over time, it can be assumed that just the MUA would  
deal with this information.  After a period of use, I doubt this  
technique would block much abuse, as spammers would adapt.

> And of course, the SDP functional specification will offer a policy  
> of some
> sort that will allow for an "Exclusive Domain" concept, right?
That would be the broad-binding assertion.

> > > If the SENDER is authorized, why do we need DKIM again?
> > As I said, there are exploits reducing the quality of IP address
> > based mechanisms.
> Ok, but if a IP machine is exploited and *DETECTED*, why does  
> anything else
> matter?  Why should I bother with the payload overhead?  and  
> conversely, if
> the IP address shows a PASS, but the PAYLOAD is exploited, should  
> that be
> enough to broadcast a IP ABUSE blacklist?
It is hard to detect a routing exploit. : (

If a server has been hijacked, but the server verification process  
(needed for DoS prevention) also requires DKIM signing from this  
domain, then this would thwart such a hijack with the added  
requirements established by server verification and DKIM.
See: Section 14. Domain Assertions for Signatures
http://www.sonic.net/~dougotis/id/draft-otis-mass- 
reputation-03.html#anchor14

> > > If DKIM fails, can we blacklist the authorized SENDER via DNSRBL or
> > > using> Local Blacklist tables?
> > It would likely be a better option to report the event.
> To whom?
To your reputation service provider.

> > Taking corrective action requires a fair amount of investigation with
> > respect to possible causes.
> True, but in the mean time, I should block the Email Server with the
> immediate SDP methodology who allowed malicious users from using other
> people's domains that your server could care about - admittely, on the
> record, per the specification and intentionally curved in your code.
>
> Correct?
What I have suggested does that automatically.


> > > Can DKIM and CSV and DNA co-exist separately? or do you need all
> > > three?
> > DKIM needs CSV-CSA for DoS protection.  This aspect of possible
> > threats has been largely ignored. : (
> I don't think so. I think the consensus is that is a SEPARATE  
> concept.  One
> can not depend on the other.  One can add CSA, SPF or CBV or the  
> next 821
> mouse-trap, but that has nothing to do with the payload.
Once the risks are better understood, this may change. : )


> I sincerely doubt DKIM is going to change any system out there that is
> currently using a 2821 base technology.  There is an awful lot of  
> investment
> in IP and 2821 methods.  The efficiency is much higher than use  
> 2821 as much
> as you can before accepting the payload.
CSV-CSA does not alter RFC-2821.  One may say it adds a recommended  
practice.

-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org