Subject: RE: [Asrg] MAC Constructed Message Ids.

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 7 Apr 2003 05:48:48 -0700

> Are you proposing that the message ID remain constant
> regardless of the number of relays it passes through?
> Or, does each point (MTA) in a relay alter the message ID?

I beleive there are a number of clients etc. that make
the assumption that the message ID remain constant so
it is not a good idea to have the message-id constantly
mutate.

On the other hand it is probably more advantageous for this
type of processing to be managed at the MSA level since
a user might have multiple clients and synchronizing the 
shared secrets in each one would be problematic.

The MSA/MTA can communicate the shared secret amongst 
themselves without too much difficulty.

The MTA could communicate the fact the message ID had been
authenticated to the MUA via a header Authenticated:
[rules, strip out all incomming headers, apply to outgoing]

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 7 Apr 2003 09:58:33 -0700

Alan,

	Much as I like the idea of public key signatures, I don't
think that messageID lengths are really compatible with public
key. Basically DSA is the only algorithm that will work (RSA
signatures are a minimum of 128 bytes these days) and that has
a few problems.

	The other problem you have is of binding, the message ID
cannot be bound absolutely to the message since you want to
be able to make minor modifications without issues. 

	The upshot is that if you want to add public key signature
that is a good thing to do, but specify a header for that purpose
rather than the message ID.

	There is certainly utility in an approach that is something
less overwhelming than S/MIME in order to combat spam. In particular
we only need to authenticate a single part of the message transfer
in this case, the hop from the border gateway of the sender to the
border gateway of the recipient. We don't need to worry about the
end to end integrity problem since this is not an end-to-end
problem.

		Phill

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]]
> Sent: Monday, April 07, 2003 12:30 PM
> To: [email-masked]
> Subject: Re: [Asrg] MAC Constructed Message Ids. 
> 
> 
> "Hallam-Baker, Phillip" <[email-masked]> wrote:
> > Let the MUA choose a random value X, store it in a place that
> > is persistent.
> > 
> > Each time a MessageID is constructed the following algorithm 
> > is used:
> > 
> > stem = date + serial + '@'
> > checksum = MAC (stem, X)
> > ID = stem + base32 (checksum)
> 
>   Alternately, use public/private gets to do something similar.  The
> benefit there is that the public keys can be put into DNS, and
> *anyone* can verify the validity of the Message-ID.
> 
>   Alan DeKok.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 7 Apr 2003 16:52:36 -0700

> That would require MTAs to detect MUA added Message-IDs and 
> remove them
> or to share the secret with the MUAs so they can correctly 
> generate the
> tokens.

That is not very hard to do. The problem is that it might screw
up the client if the client tries similar processing - although
this is a feature that really should be the MSA responsibility
if being an MSA means anything.

> There are two basic questions for such IDs:
> 
>   Who generated them and can that be shown?

No.

>   Was that ID generated for this specific message or some other (ie
>   possibly re-used)?

This is not really an issue, the only party that can decode 
them is the one that created them. The only information being
obtained is that a message is a reply to a previous message.

There is of course a cut and paste attack problem (unless
we believe the claim that spam senders don't forge). This is
why the technique is of limited use if you don't have an 
authentication mechanism as well, but even though limited the
attack is not very easy.

  *  The stolen token only works for a single end user!

  *  The sending MSA can put time limits on validity

It is in any case no more attackable than intrusive 
challenge/response.

		Phill