RE: [Asrg] C/R Interworking Framework

["Peter Kay" <[e-mail]>]

In addition to what you have below, the C/R internetworking must define
how C/R systems respond to each other's challenges. For example:

1. The Titan Key (TTK) sends out an email to someone the first time. The
recipient's email is automatically added to TTK  whitelist.

2. The recipient does not have me on their whitelist, so they send a
challenge. But because their "FROM" address in the MAIL command is NOT
the sender's address, TTK doesn't have that address on its whitelist so
it sends a challenge to the challenge.

End result is that the TTK user never sees the recipients challenge and
the recipient never gets the email.  So what ends up happening is the
recipient has to go through their quarantine folder and pull out the
email.  The TTK user never gets the email because the challenge was
killed in the MAIL command. 

So, to me, C/R systems need to at least use their end-users email
address on the MAIL  FROM address in the mail command. Assuming that a
CR system dynamically adds a recipient email address to the whitelist,
the process would then go as follows:

1. The sender Y (SY) using CR system A (CRA) sends an email to recipient
Z (RZ) not currently on CRA's whitelist.

2. CRA dynamically adds RZ's email to CRA's whitelist.

3. RZ's CR system B (CRB) receives SY'z email

4. CRB sends a challenge to SY. The MAIL FROM address is RZ's email
address.

5. CRA receives CRB's challenge and since RZ's email address has been
already added to CRA's whitelist, the challenge passes through to SY.

6. SY responds to the challenge.

7. Mutual authorization to correspond is completed and email may flow.



> -----Original Message-----
> From: John Fenley [mailto:[e-mail]] 
> Sent: Tuesday, June 03, 2003 8:21 AM
> To: [e-mail]
> Subject: Re: [Asrg] C/R Interworking Framework
> 
> 
> Here is an informal C/R interworking system I have been 
> working on lately:
> 
> I see 3 different types of C/R systems with varying levels of 
> verification based on what kind of information is wanted by 
> the challenger:
> 
> 1. Address verification. Challenge gets delivered therefore 
> address is valid. 2. Address + Message verification. Asks if 
> system really sent the message being challenged. 3. Address + 
> Message + Human verification. Requires human response to challenge.
> 
> These differences in motivations should be taken into account 
> when working to ensure interoperability because these types 
> of challenges will take different forms, and must be 
> responded to differently.
> 
> 1 is just an address probe. RFC 821 describes a VRFY command 
> for this purpose (does it work?). If this can be used I 
> recommend it's use for address verification to all makers of 
> C/R systems.
> 
> 2 could be done in SMTP time, but might be better done at the 
> MUA. This type 
> of challenge could be answered automatically at the MUA. This 
> type of check 
> would be useful to do to all messages, even ones for whom the 
> address is 
> already whitelisted as it essentially authenticates the 
> sender, and spoofing 
> a sending address becomes difficult or impossible, though there are 
> tradeoffs, and another form of authentication would probably 
> be better. This type of check would also eliminate the 
> possibility that a spammer would 
> specify a random address to be challenged (see original 
> message section) in 
> the hopes that the random party would answer the challenge, 
> and help a spam 
> message pass through another person's system.
> The challenged party should be able to say "no, I didn't send that".
> 
> 3 must be done at the MUA. Hashcash and other proof of "x" 
> checks would require human agreement, and would fall under 3.
> 
> A person should only see challenge type #3 after the message 
> passes type 2 verification. This eliminates any advantage a 
> spammer would receive from faking a C/R subject to an auto 
> answering C/R system, yet allows challenges that require a 
> human response to reach the inbox.
> 
> 
> 
> ===============================================
> The original message: ===============================================
> The original message can have an optional machine/human 
> readable top body line requesting that the body either not be 
> included in challenges, or that it should be included. This 
> line could be placed automatically.
> 
> This line can also specify an address that challenges should 
> be sent to. This will allow anyone to use an auto-answering 
> services to automatically 
> answer the
> challenges (you send a cc: or Bcc: to the company so they can 
> check #2 type challenges), and allow all challenges received 
> at an address to be deleted without processing (except type 3 
> challenges requiring human response that 
> come from the service, and could have a user defined subject line).
> 
> C/R systems should detect and respect this by never including 
> the message body if that request is made (even if a message 
> checksum is not available), 
> and
> by sending challenges to only the address listed here (to 
> clear up confusion about which address to use).
> 
> ===============================================
> The Challenge
> ===============================================
> I see the following as the minimum necessary to ensure that 
> no loops form:
> 
> Standard Subject deformation such as the addition of "CR#:" 
> for all C/R system challenges where # corresponds to 
> challenge types 1,2, or 3 in the list above. The rest of the 
> subject should be unchanged (may truncate overflowing 
> subject lines).
> 
> The top of the body should contain instructions for a human 
> reading the message, and outlining the mail handling 
> procedure of the challenger in the event of no response.
> 
> The date of the original message should be included.
> 
> A unique random identifying number to be repeated back in the 
> response so 
> that the challenger can know that this is truly a response to 
> the challenge 
> sent, and not a faked response sent at the same time as the 
> message. This 
> also proves that the sender can answer challenges sent to the 
> challenged 
> address.
> 
> A message specific identifier (such as an MD5 checksum of the 
> body) so that the challenged system can determine which 
> message was challenged... the entire body could be used, or 
> the entire full message with headers could be included.
> 
> ===============================================
> The Response to a "CR#:" message 
> ===============================================
> Once you have the right information, proper handling of the 
> message is necessary.
> 
> Messages with "CR(any #):" Should never be challenged.
> Messages with "CR(1-3)" should be responded to in either the 
> affirmative or negative.(automatically if possible) The 
> system should be smart enough to realize when it doesn't know 
> if it sent a message or not. Messages with "CR(4-6)" should 
> be Processed, and the original message(s) should be delivered 
> or deleted based on the response content, and the local policy.
> 
> Responses to a challenge should retain the subject from the 
> challenge with one change. The number in the "CR#:" tag 
> should be increased by 3 to show that this is a response to a 
> challenge. thus numbers 1,2, and 3 are challenges. And 4,5, 
> and 6 are responses. This should eliminate the possibility of 
> loops. If you receive a "CR7:","CR8:", or "CR9:" then a 
> broken Challenge response system on the other end would be 
> detected. A "CR#:CR#:" Tag would indicate a broken C/R system as well.
> 
> 
> The identifying number should be included in the response.
> 
> And most importantly an answer to the challenge should be 
> included (yes, no, 
> or unknown, plus Hashcash work/human response) if one is 
> required by the 
> type of challenge being answered.
> 
> ==============================
> analysis:
> ==============================
> 
> These guidelines for C/R seem to me to solve a lot of the 
> problems that C/R 
> would have normally:
> 
> Relative simplicity of implementation guidelines.
> 
> Provides support for varying goals of C/R systems.
> 
> Automatic responses to some challenges are possible, and would not 
> inconvenience the original sender at all.
> 
> Human responses are possible in old equipment, or C/R by proxy (for 
> automatic response) could be used..
> 
> Does not rely on any outside protocols in order to operate as 
> it requires 
> only 2 way message transfer (does not require SMTP tweaks)
> 
> Header information not required.
> 
> Falsity in any part of the transaction is detected with C/R 
> systems using 
> this method (spammers cannot use it to help reach users 
> unless they are 
> stable enough to correctly answer the challenges themselves, 
> and are thus 
> easier to track down).
> 
> Loops are virtually impossible between C/R systems using 
> these methods.
> 
> Address to challenge confusion can be cleared up.
> 
> Local policy regarding un-cleared mail is up to the user.
> 
> Is open ended enough that it could be used as an unlimited 
> proof of work system (semi-equal access to all regardless of 
> language/handicap/education/Etc...except CPU power)
> 
> If Choicelist is used, then mailing lists would never be 
> challenged, and 
> wanted automatic mailings would pass through this system with 
> no problems.
> 
> Adoption population should rise rapidly as an auto-responding 
> MUA will, most 
> likely, be demanded by many senders after they receive only a few 
> challenges. Such an MUA would probably be able to ?play both 
> roles? and 
> challenge mail as well, thus creating a feedback loop of 
> increased adoption 
> pressure and C/R volume.
> 
> 
> =============
> Problems I see:
> =============
> widespread adoption would make it difficult or impossible to 
> send or receive 
> truly anonymous email.
> 
> This does nothing to combat spammer evolution. In fact 
> spammers may speed up 
> their evolution unless this evolution issue is addressed. I 
> feel confident 
> that ?ADV:? whitelisting could provide a solution to this, 
> and would end the 
> escalating arms race against spammers.
> 
> =====================================================
> Asrg Requirements from ?draft-irtf-asrg-requirements-xx? 
> addresses here =====================================================
> 
> 2.1
> I have not yet searched the RFCs for support or 
> contradictions 2.1.1 MD5 and hashcash are accepted and 
> established systems, and I believe that 
> randomly generated number comparisons are routinely used to 
> prove that 
> message delivery has succeeded
> 2.2
> The burden falls mostly on the recipient for storage until 
> delivery, though 
> the sender would carry a small Checksum storage burden as 
> well. The burden 
> imposed on the challenged party is there by design in C/R 
> systems. 2.2.1 Avoidance of the manual burden of answering 
> challenges might spur adoption 
> of auto-responding MUAs, and act as a support to adoption.
> 2.3
> The proposed system would be mostly transparent for end users if an 
> auto-responding MUA is used. Mail providers would be 
> pressured to implement 
> this system to remain competitive. This is a symptom of C/R 
> itself, and 
> interoperability concerns would be decreased by a standard 
> framework to 
> follow.
> 2.3.1
> Not sure what atypical situations I should be evaluating, but 
> in multiple 
> party messages, each recipient would independently challenge 
> the message, 
> and the original sender would need to respond to each 
> challenge individually 2.4 Only minor changes to most 
> existing C/R systems would be needed, and 
> deployment of new C/R systems is already progressing without 
> needing a push. 2.4.1 C/R already exists, this method would 
> just allow interoperability between 
> them.
> 2.5
> C/R would be interoperable under this method.
> 2.5.1
> Old mailers are supported through Proxy Challenging to a 
> service address. C/R is already independent of SMTP, yet 
> compatible with it. I believe this method can be equally 
> implemented  on all platforms. 2.6 The subset of spam C/R 
> will be most effective against will be anonymous mail 
> from unknown parties that cannot respond to the challenges. 
> 2.6.1 I feel this interworking method is contiguous. 2.7 If 
> C/R cannot be made workable then I see little hope for email. 
> 2.7.1 Possible abuses are mentioned along with the solutions 
> I have proposed. 2.8 Auto answering of minor challenges 
> should be trivial, and would provide a 
> minimal barrier to legitimate message delivery.
> 2.8.1
> this method does not limit content types, though it may introduce 
> significant delays in the delivery of email. Those delays are 
> a part of C/R 
> and the auto response capability mentioned minimizes that 
> delay in most 
> cases.
> 2.9
> This proposal is not a C/R system, but a standard method that 
> will allow C/R 
> systems to increase their interoperability
> 2.9.1
> This has attempted to provide a solution that any party can 
> use, and find 
> effective.
> 2.10
> Legal aspects were not considered.
> 2.10.1
> Patent law would be the only possible deterrent for this 
> method, but that is 
> being discussed separately
> 2.11
> This method is a simple as I could make it.
> 2.11.1
> People can easily understand C/R on a basic level.
> 2.12
> C/r is already being implemented.
> 2.12.1
> I believe these have all been addressed
> 2.13
> This method may be effective on SMS and other messaging 
> platforms. 2.13.1 Specific implementations for other 
> platforms have not been evaluated yet, 
> but seem possible to me.
> 2.14
> Anonymity is reduced by this system, though through use of a 
> third part 
> challenge answering service anonymity may be preserved 
> through masking 
> challenge delivery through them.
> 2.14.1
> Challenge forgery is addressed, and I feel solved. 
> Accountability consists of punishment of senders by possible message 
> deletion if  a challenge is not received, and perhaps 
> elevated status if a 
> response is received.
> 
> Preserving anonymity, and allowing sender tracing seem like 
> contradictory 
> goals to me, and I can't think of any system that could do 
> both well. ====================================================
> 
> 
> John Fenley
> 
> _________________________________________________________________
> Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
> http://join.msn.com/?page=features/junkmail
> 
> _______________________________________________
> Asrg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/asrg
> 
> 
> 


_______________________________________________
Asrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg