Re: [ietf-dkim] updated threat analysis outline

On Aug 25, 2005, at 8:44 AM, Tony Finch wrote:

> On Thu, 25 Aug 2005, Douglas Otis wrote:
>
>
> > Example.com could decide to discontinue the use of the account  
> > used to
> > send the marketing material.
>
> > Had the RCPT TO hash idea been used, then example.com could also  
> > have an
> > idea where not to send their next run of mail to help prevent future
> > occurrences
> Neither of these will stop Mr Vendetta's spam run.

The intent of the RCPT TO hash would be to provide an indication when  
to check for the revocation, instead of depending upon the HELO for  
example.  There should be practical methods used on the RCPT TO line  
which obfuscates the hashed information.  Perhaps a special parameter  
could be dedicated as a salt.  The goal was to mitigate extra DNS  
lookups, albeit small in this case.  I hope this answers Jim's  
question as well.  The RCPT TO hash option would also instill a  
practice that provides better tracking abilities when problems occur,  
without depending upon other steps being taken.  It forces senders to  
do the right thing. : )

> > It could be that example.com has marked each message so they know  
> > where
> > Mr. Vendetta obtained the initial copy, as this has been a problem in
> > the past.
> In effect they are using the revocation ID to do this.

Yes, this could be an approach used.  I envision two normal modes for  
the revocation-ID, static and sequential.  One where the identifier  
is associated with an account determined any number of ways, or a  
sequentially assigned when not associated with an account.   
Example.com could add a prefix to the revocation-ID which keeps these  
ID spaces separate.
> > This ignores the opportunistic identifications made possible by the
> > revocation-identifier.
> I would say "raises problems with" rather than "ignores" - my point  
> was
> that the assumptions behind your opportunistic identification  
> heuristic
> are not solid.
>
>
> > However, example.com will have recommended the bindings of the
> > mailbox-domain and the signing-domain which excludes the
> > revocation-identifier, as they completely control the use of their
> > domain's mail and want their mail accepted without causing any user
> > prompts for approval.
> So you'd need a more flavoursome SSP.

No.  This scheme would not depend upon SSP based information.  This  
would be out of concern that the SSP approach imposes too much  
overhead for minimal benefits, and may even create support related  
issues as well.   Information within the message should directly  
recommend the desired binding needed to properly isolate senders  
within that domain.  There should be two things included to permit  
this direct mode of communication.  One, any key that has been  
delegated and is not trustworthy should be marked as such, where the  
revocation-ID must be a copy of the selector.  This delegated key MAY  
also create an exception when a WIDE binding has been previously  
recommended.  It would be assumed these binding recommendations are  
cached.   It may be practical for the MTA to cache WIDE bindings.   
Two, there be a tag within the signature that indicates WIDE or  
NARROW bindings.
Although I shudder to mention this, it is possible to include within  
this direct communication approach other binding limitations.  This  
approach assumes when the information is cached at the MUA, the  
danger of being spoofed occurs primarily within subsequent  
communications.  When the WIDE bindings are also cached at the MTA,  
this would enable protections that extend to initial contacts as  
well, even though any such message would typically be examined by the  
recipient.  A DKIM aware MUA would allow the user to request a  
binding for messages they wish to track, where at that time, the  
details would be displayed when the MUA seeks approval of the  
binding.  Some bindings may be made in an automated fashion.  Wide  
bindings where the signing-domain and the mailbox-domain match could  
represent a case where automatic bindings are safe.
-Doug


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