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

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 20 Aug 2003 11:40:59 -0400

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 <[email-masked]> -----
> >
> > 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Deven T. Corzine" <[email-masked]>
Date: Wed, 20 Aug 2003 13:42:17 -0400 (EDT)

> have to store copies of messages, but can store MD5 hashes instead.

Using a hash is an obvious thing to do, but it begs the question of exactly
what you're hashing.  You can't safely hash the entire message because the
headers change on every hop, at least for Received: lines.  Other headers
might be mangled or normalized as well.  You can ignore the header, but it
would be good to validate parts of it.  Even if you just hash the body, you
have to be concerned about the message being mangled by intermediate MTAs.

Now, you could Base64-encode the content to protect it against mangling, 
but that renders the plaintext of the message unreadable.  You could strip 
out all characters but the ones used for Base64 encoding, and hash that.  
Perhaps quoted-printable encoding would be another semi-readable option.

PGP has to deal with this issue for "clear-signed" messages -- how does it 
address this issue?  (Or does it depend on the body not getting mangled to 
be able to verify the signature?)

Of course, another option is to simply use PGP.  This seems the obvious 
answer for mailing lists -- the mailing list should clear-sign all valid 
messages with a private key used only for that mailing list, and have the 
user whitelist that PGP key (perhaps by keeping a copy signed with their 
own PGP key?) -- then no spammer could forge messages appearing to be from 
that mailing list...

Deven

---

From: "Eric Dean" <[email-masked]>
Date: Wed, 20 Aug 2003 16:12:51 -0400

Yes considering many CR systems use CR URLs such as
http://cr.foo.com/?sender=[email-masked]&rcpt=[email-masked]

There's a lot of room for improvement.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Deven
> T. Corzine
> Sent: Wednesday, August 20, 2003 1:42 PM
> To: Yakov Shafranovich
> Cc: Andrew Akehurst; [email-masked]
> Subject: Re: [Asrg] 6. Proposals - Challenge/response - CRI
> 
> would be good to validate parts of it.  Even if you just hash the
body,
> you

---

From: david nicol <[email-masked]>
Date: 20 Aug 2003 18:11:59 -0500

> have to be concerned about the message being mangled by intermediate MTAs.

I imagine one would hash all the MIME parts together.  Or do whatever
GPG does with a MIME message.  This but has been solved, there is only
to select an approach and approve it.

-- 
David Nicol / If at first you don't succeed, use a bigger hammer. 
                                        http://gallaghersmash.com

---

From: "Eric Dean" <[email-masked]>
Date: Thu, 21 Aug 2003 10:54:51 -0400

I'm not sure that we have to approve anything...we just have to have a
protocol provide capabilities for interoperability..we don't have to
select a method..but rather design a protocol that will accommodate.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
david
> nicol
> Sent: Wednesday, August 20, 2003 7:12 PM
> To: Deven T. Corzine
> Cc: Yakov Shafranovich; Andrew Akehurst; [email-masked]
> > > alleviates some privacy concerns since the originating MTA/MUA
does
> not
> > what you're hashing.  You can't safely hash the entire message
because
> the
> > might be mangled or normalized as well.  You can ignore the header,
but
> it
body,

---

From: david nicol <[email-masked]>
Date: 27 Aug 2003 19:51:26 -0500

In the terms of my quoted message, listing a method or methods in the
protocol would constitute approval.

Don't want to get bogged down in the morass of "violent agreement."

Cheers

---

From: "Eric Dean" <[email-masked]>
Date: Thu, 28 Aug 2003 15:48:39 -0400

I guess what I would like is for a variety of authentication methods be
considered and determine if additional functionality is required within
CRI to accommodate.  I'm not endorsing a particular method, but would
like someone to possible show a scenario or two where one or more might
be used and determine if we require modifications.

david
> nicol
> Sent: Wednesday, August 27, 2003 8:51 PM
> To: Eric Dean
> Cc: 'Deven T. Corzine'; 'Yakov Shafranovich'; 'Andrew Akehurst';
> [email-masked]
> Subject: RE: [Asrg] 6. Proposals - Challenge/response - CRI
>