ietf-mailsig
[Top] [All Lists]

RE: In response to Housley-mass-sec-review

2005-03-06 10:08:16

How about if there was a means of obtaining BOTH message and user level
revocation in one go?

Consider the following, we put a unique opaque identifier code in each
message which looks just like a base64 string:

Yrpwqefhkjfoiuh2q3poiu32198ry2qph23p8ru2==

Active code on the DNS server unpacks to a structure:

NameID : MessageID


Nah, why not just do a hierarchical query?

Base64(SHA1(messageID)).Base64(sha1(userID))._revocation.example.com


Standard DNS config can then be used to revoke the user or the individual
message:

*.Base64(sha1(userID))._revocation.example.com TXT "status=revoked
reason=spam"


This type of mechanism would have to be signalled in the policy mechanism so
the recipient knows whether to do the check or not.



-----Original Message-----
From: owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org 
[mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of 
Douglas Otis
Sent: Sunday, March 06, 2005 10:02 AM
To: mlibbeymail-mailsig(_at_)yahoo(_dot_)com
Cc: Andrew Newton; MASS WG
Subject: Re: In response to Housley-mass-sec-review



On Sat, 2005-03-05 at 12:43 -0800, Miles Libbey wrote:
--- Andrew Newton <andy(_at_)hxr(_dot_)us> wrote:
Let's say Yahoo has 40 million email accounts (that's probably 
pretty
high)

or low.  Neilson Netratings indicates there are about 60M 
unique Ymail 
users in the US alone (and they only measure web mail 
users, not POP 
users -- and I'd guess their methodology doesn't include the 
spammers).  However, there are very few providers at an order of 
magnitude more than your estimate -- there are a few more 
in the same.

I don't think it changes your point (just the example org), 
however, 
I'd be surprised if there are organizations that add or 
subtract 100s 
of thousands or millions of A records on a more than daily basis.

When the opaque revocation-identifier is persistent and 
derived from the access server, as example, then the number 
of revocation records needed to remove an abusive account 
would be one per account.  If the revocation-identifier is 
sequential, then a revocation for each abusive message would 
be needed.  For larger domains, it would be far more 
practical to use persistent identifiers.  This helps with the 
revocation process as well as correlation of abuse.

Likely the source for abuse will be a compromised system.  
Being able to easily locate those accounts could provide a 
means to automate a walled-garden approach when dealing with 
abuse reports.  (Compromised systems are not a problem for 
Yahoo or Google, but then they offer free mail services and 
invite direct abuse.)  Inclusion of the revocation A record 
should be part of the script that disable the account.  The 
revocation-identifier, especially for smaller domains, 
affords the possibility of maintaining anonymity while still 
enabling the revocation of replay attacks.  If a key per user 
were used, then the key itself would be a clue of who is 
sending the message in the same manner as a revocation-identifier.

When the revocation is prompt, the number of revocations due 
to abuse should be reduced as there would be much less profit 
abusing those that ensure such accounts are quickly removed.  
This would be working on the broken window approach.  The A 
records could be removed following the removal of the next 
subsequent key.

-Doug
  





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