ietf-clear
[Top] [All Lists]

[ietf-clear] Re: Make CSV backwards compatible with legacy SPF records?

2004-10-25 15:54:11
On Mon, 2004-10-25 at 14:29, Matthew Elvey wrote:
I was thinking about my using SPF records idea, and noted a new hurdle. 
I realized that even if we assume such records can sometimes be used as 
a stand-in for missing CSA* records, we still will have no DNA* records.
Analagous records will exist if  Accreditation and Reputation services 
(A&R services? ARS? AR?) pop up that work with SPF records, but for good 
reasons that Doug has outlined, such services are relatively infeasible, 
compared to A&R services that work with CSV records, so it's no surprise 
that none have popped up.  There is a very large set of SPF records out 
there, but AFAIK, the set of A&R services that work with SPF records is 
empty. 

I would not hang my hat on that point.  There will likely be
accreditation services that offer positive endorsements, but these
services will be relatively useless in assessing the rest of the world
that does not utilize their services. 

(I'm making an implicit assumption here: A&R services can't reasonably 
assign a good reputation to a bare domain; rather they can only do so to 
a tuple of a domain and a scheme for Identification and Authentication.

Making a good assessment incurs little risk.  It is making negative
assessments that need to ensure such an assessment is safely identifying
the proper entity.  
  
They also can't reliably assign a bad reputation to a domain without 
referencing a good scheme for Identification and Authentication.  Folks 
think this is a valid assumption?)

This is where things need to be ultra strict about identification. 
There is nothing that can be trusted in a message without digital
signatures.  Nothing. : (  

CSV can authenticate and authorize a specific host up to the strength of
the DNS/IP address infrastructure.  The principle use of this mechanism
should be seen as a diagnostic tool in locating security problems.  Of
course, the odd account will need to be disabled.  This is often done by
merging information accessible only by the domain administrator to map
the abuse to an account.  Should the domain administrator be responsive
to these problems and not chasing false reports where their domain is
being spoofed, there should be little need to lock down the mailbox
being used by an account.

Should major financial institutions wish to offer immediate
anti-phishing protection to their customers, then implementing a
CSV-MARK header would be an immediate and extremely safe solution.  This
would not modify any existing mail handling, but would require a
modification to the provider's MDA and MUA to safely pass CSV
information to the user.  This holds with the premise that no headers
can be trusted within an unsigned message.  A consistent CSV-MARK seen
by the consumer would help dissuade an extremely lucrative method of
fraud.  Taking this to the next step using a referenced HELO name list
could be next to protect even the very naive. : )

Things are awfully quiet.  I guess a lot is going on in private DT 
discussions and such...

There is still a fair amount going on behind the scenes.  I also think
several are getting ready for the next round at the IETF/FTC meetings.

-Doug

<Prev in Thread] Current Thread [Next in Thread>