Re: [Asrg] 6. Proposals - Challenge/response - CRI

[Yakov Shafranovich <[e-mail]>]

At 04:48 AM 8/20/2003, Andrew Akehurst wrote:
>Hello everyone
>
>Some forwarded further reaction to the CRI proposal here from David.
>I've had a few ideas myself over the past couple of days and I'll be
>posting them shortly.
>
>Thanks
>
>Andrew
>
>----- Forwarded message from david nicol <[e-mail]> -----
> >
> > I think it's too complex and fiddles with too many preexisting
> > protocols.
> >

Keep in mind that CRI is a larger subset of the general protocol used to 
exchange consent tokens - CRI is a subset used for C/R system.

There are many problems with creating new protocols and structures, and 
various issues involved. One of them is backwards compatibility which CRI 
accomplishes by providing a section of the message that is intended for 
human beings.

> >..........
> > I am opposed to level three.  As computing power keeps increasing,
> > as well as the availability of human brains, when properly organized,
> > turing test systems become useless.
> >

Someone has pointed this issue out before and we had even tried to 
calculate how much it would cost to create software that lets spammers hire 
cheap labor and quickly reply to messages. Labor costs were also taken into 
account.

HOWEVER, keep in mind that in order to answer any form of C/R challenge or 
exchange consent tokens via C/R, the spammers MUST use a valid return email 
address. That already brings us to a closer solution for traceability of spam.

> > I think a good thing to agree on might be an XML DTD for challenges
> > and responses, which could be embedded into a human-readable
> > challenge message that states the same thing as the XML challenge,
> > for those users (initially everyone) who do not use a CRI-enabled
> > MUA.
> >

XML might be used for the machine readable body of the message but you 
would still need MIME headers and an ESMTP extension in order to make this 
work in the world of email.

As for the DTD, I believe that the general consent token exchange protocol 
is a larger superset of CRI, and could be used to define the generic format 
for consent tokens, which then can be used by CRI in this specific context. 
Additionally, IANA registry considerations must be taken into account if we 
want consent token types to be consistent across the Internet.

> > What information would beed to be in there, to have level two
> > functionality?  Last night I came up with what I believe is a
> > workable set:
> >
> > 1: message-ID of the message in question.  Message-IDs are generated
> > by the MUA (well they can be) and the MUA can remember which ones it
> > generated.  Message-ID alone allows a valid Message-ID to be attached
> > to an invalid message, so Message-ID is not sufficient.
> >

That is assuming the MUA is the one repling to the challenge. Many times it 
is possible that the intermediate MTA would do so, and in that case, it 
would have to memorize the message IDs.

> > 2: MD5 hash of the body of the message.  By including this information,
> > it is only possible to forge a message that was actually sent.
> >
> > 3: subject line.  It appears in the header, not the body, and it
> > is good to include the subject line in human-readable forms.
> >............
> > __END__
> >
> >
> > I suppose this could all be done with headers instead of
> > a block in the message body, but headers often get lost.
> >
> >

CRI as it is now would require a multi-part MIME message with the headers 
located inside the machine readable message block.

> >
> > I think the only really significant semantic suggestion I'm making
> > is that a hash of the body of a message should be included to
> > prevent forgeries of level-two systems.
> >

That has been mentioned before and is a pretty good idea. It also 
alleviates some privacy concerns since the originating MTA/MUA does not 
have to store copies of messages, but can store MD5 hashes instead.


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