ietf-mailsig
[Top] [All Lists]

Re: MASS Security Review document

2005-02-06 00:40:28

On Sat, 2005-02-05 at 19:09, John R Levine wrote:
The information could take the form:

 <opaque-identifier>._rl.<signature-domain>
  or
 <opaque-identifier>._rl.<signature-domain>.<third-party-domain>

Encoding signatures as domain names is not a bad idea, but ...

Once the signature had been validated, a check against an identifier
could take this form.  It would be a method to revoke authorization
implied by a valid signature.

This mechanism, used together with signatures, should save time and
revenue.  For large domains, not doing so would be a missed opportunity.

This is the Project Lumos fallacy.  I have no interest whatsoever in
distinguishing between a domain's nice users and its nasty users.

Using DK or IIM with blackhole listing on an opaque identifier avoids
the onerous details advocated by Project Lumos, in that there is no
centralized key registry, and most domains would need to do nothing, not
even provide an identifier.  While the primary goal of adding an opaque
identifier would be to prevent replay abuse, it would also facilitate an
alternative to blocking an entire site with millions of users, where
perhaps the majority of these users have systems that are compromised. 

Anyone that has a clue about computers has become rather adept at
removing viruses.  I only wish there was a sure way to defend this 'O'
system. : (

If there was a reasonable response to this problem, blocking large sites
would provide an incentive for them to do the right thing.  When the
majority of spam comes from compromised systems, blocking the
residential address space is less effective with the use the provider's
SMTP servers across thousands of random systems.  Lets face it, they
need help.

The review already indicates a need to include signature settings within
signed content.  Allowing an innocuous optional opaque identifier within
the signature header would assist efforts to cull out compromised
systems.  Allowing a means to blackhole list these systems by the
provider themselves would also prevent replay abuse.  Providers should
refuse service to compromised systems, and identifying these problematic
systems would be greatly facilitated by the opaque identifier.

This is a very minor change with a major benefit.

-Doug



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