RE: [Asrg] C/R Interworking Framework

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:pontifier(_at_)hotmail(_dot_)com] 
Sent: Tuesday, June 03, 2003 8:21 AM
To: asrg(_at_)ietf(_dot_)org
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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg