Subject: Re: [Asrg] CRI Header

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 04 Jun 2003 14:00:21 -0400

At 09:43 AM 6/3/2003 -0400, Eric Dean wrote:

>Trying to come up with the right place to shim in the CRI control headers.
>It seems we can do the following:
>
>1) Use SMTP headers: beyond the deployment issues, CRI is not limited to the
>envelope and there are often many mail relays in the path that could remove
>such headers.  We do not want to restrict mail clients from implementing
>CRI.

As I mentioned before, SMTP would be a good solution only for those cases 
when two C/R systems are inter-operable and there is a need for the sender 
to take the burden of storing the message. Otherwise, plain email should be 
used so us humans can read the challenge message.

>2) Use RFC 2822 headers: we could possibly introduce a new field altogether
>or use an optional field as spec'd in 3.6.8

Using RFC 2822 headers would limit the amount of information since each 
header is limited to 998 characters (as per section 2.1.1). Vernon Schryver 
(https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg05168.html) 
has already pointed out that MIME headers can store more information which 
would be a factor in case some kind of PKI signatures are used.. 
Additionally, some C/R systems might want to combine several challenges 
into one message and that would be awkward to do with RFC 2822 headers. On 
the other hand, if such headers are used for single sender-single receiver 
C/R headers are the simplest solution.

>3) Use MIME headers (registered or private): though CRI has little relavancy
>with MIME.  Private headers can not become a standard.  There isn't such a
>limitation on 2822 3.6.8
>
>Thoughts?

Some of the purposes of MIME as stated in RFC 2045 and look perfectly 
suited for us:

"(2) an extensible set of different formats for non-textual message bodies, 
(3) multi-part message bodies, and"

In our case we can utilize MIME to create a multi-part message with one 
part containing a human-readable challenge and other parts containing 
machine-readable challenges (i.e. non-textual message bodies). The 
advantages to using MIME is that:
1. We can include both human and machine requests in one messages, NOT 
limited in size.
2. We can include PKI signatures, hashcash codes, etc.
3. We can include multiple challenges and responses in one message.

I think that all three approaches are good and they fulfill different 
needs. I think all three should be used and we will allow C/R systems 
to  negotiate between themselves:
1. The basic CRI protocol should use RFC 2822 headers, with single 
challenge per each sender. This allows for easier use with existing email 
systems and non interoperable C/R systems. Such messages will have the 
regular challenge message for humans in the message body with additional 
information in the headers. Using custom MIME types can make email software 
choke and leave the information unreadable to a human being.
2. IF a C/R system is used by the sender, then it can identify itself 
either via ESMTP or an RFC 2822 header. Then the two systems can negotiate 
on the use of RFC 2822 headers, MIME headers or plain SMTP. This would be 
similar to the way HTTP clients negotiate with "Accept-Encoding" and 
"Content-Encoding" methods. This would allow interoperable C/R systems to 
use MIME and SMTP methods for cases like challenges to multiple senders, 
custom PKI, burden of storage on sender, etc.

Yakov  

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

---

From: "Eric Dean" <[email-masked]>
Date: Wed, 4 Jun 2003 15:54:07 -0400

> used so us humans can read the challenge message.

Split MX incoming from SMTP outgoing relay may or may not pose an issue.
Some mail servers allow for P2P clustering..like with SMTP VRFY, LDAP, or a
common database.  A CRI message could be queried against other servers..but
may be annoying.

> header is limited to 998 characters (as per section 2.1.1).

Uh..998 is probably enough...and they really prefer 78 chars anyway

> Vernon Schryver

ok

> C/R headers are the simplest solution.

2822 just seems more broad than MIME...I'm not leaning either way..it seems
that most people like to stick flotsam and jetsam in the MIME headers...but
I am not sure how the registration spec'd in 2048 will respond to us

> (3) multi-part message bodies, and"

In 2048, we should fit in one of two areas:

1) External Body Access
2) Transfer Encoding

The more I read 2048, the more I ask myself "why the hell am I considering
MIME private values?"
> 3. We can include multiple challenges and responses in one message.

Let's hope that IANA also sees our approach this way

> choke and leave the information unreadable to a human being.

ok..optional headers or do we introduce a new one?  There isn't an RFC 2822
registration process that I am aware of.

> custom PKI, burden of storage on sender, etc.

ok

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 4 Jun 2003 15:20:24 -0600 (MDT)

> From: "Eric Dean" <[email-masked]>

> ...

If you're worried about the IANA, you shouldn't even consider an
official message header.

> ...

See draft-klyne-msghdr-registry-06.txt

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Dave Aronson <[email-masked]>
Date: Thu, 5 Jun 2003 09:07:24 -0400

Yakov Shafranovich <[email-masked]> wrote:

 > Additionally, some C/R systems might want to
 > combine several challenges into one message

Maybe this is a dumb question, but I'm new to this stuff....

Why would this be of such benefit?  IMHO the message should be short 
enough, and there would be enough benefit to being able to put unique 
content in each, that it would not be worthwhile to combine them.  Do 
you have some scenario in mind, under which there might be multiple 
challenges issued to the same destination?

-- 
David J. Aronson, Unemployed Software Engineer near Washington DC
See http://destined.to/program/ for online resume, and other info

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 05 Jun 2003 10:59:33 -0400

>challenges issued to the same destination?

1. Two major ISPs, both operating C/R systems. They might want to combine 
multiple C/R challenges together to save on bandwidth.
2. Messages addresses to multiple users at the same ISP. It is easier to 
deal with one message then many. This would be good for mailing lists, 
where in case of AOL, instead of thousands of challenges, only one will be 
sent.

Yakov