Re: [Asrg] E-mail Postmarks

["william(at)elan.net" <william at elan.net>]

> 	http://www.lessspam.org/EmailPostmarks.pdf

Well this is extremely unusual for me to say when it concerns document by 
Microsoft, but I like concept implementation in this draft better then 
what is in Yahoo Domain Keys draft (I note that concept is basicly the 
same), this is what I was expecting from them...

I do have certain questions now (and additional comments):
1. I did not quite understand what would happen if message is already 
S/MIME with user signature. Am I correct in understanding that additional
signature would be added to be part of multipart/signed mime structure?
Can you describe that that would be done if:
 a. The message data is contained within SignedData?
    (the above would also be the case if message itself is encrypted, right?)
 b. A S/MIME user signature is attached in SignedData?
    (using signerInfos part I suppose)

2. I hope the intent is that not only the originating server is to sign 
the message but that intermediate servers may choose to do it as well.
That means additional signatures would be added. Would this be done
by additing new mime part or by extending existing signature structure
and adding this new "signature" as part of certificate set?

3. There maybe cases when server wants to add additional data as part
of signature. I'm assuming that its expected that signedattributes and 
unsignedattributes are to be used? This can be orbitrary text, right?
Can we then extend it to allow data from certain headers to be added as 
part of this?

4. What happens when message is signed with PGP rather then S/MIME?
I'm assuming that in that case PGP signature is treated as part of 
original message data but unfortunetly there are multiple known problems
in handling of message by MUAs when both PGP and S/MIME are mixed like 
that in the same message...

5. In general I'm concerned that yet more data is being proposed to be 
added into the same TXT domain field as MARID. With number of signatures 
as part of TXT record, it'll be easily possible to grow above 512 bytes
limit. In fact its possible that this will happen even if "indirect" is 
used when we have too many signatures that belong to the domain.

My particular comment in regards to postmark document is that possibly 
certain field in signatureinfo should indicate full dns record where 
public key is to be looked up in (something like DK draft).

In regards to DNS in general, as many others have commented DNS is by 
design protocol that provides small pieces of data as the answer, this 
provides for effective caching (for 95% of  records, this piece of data is 
actually < 20 bytes long!). When we require that every domain have a 
MARID record, this increase amount of data that dns servers would be 
required to process and store in cache by factor of 10 to 100 (that means 
most likely at least 10 times larger and possibly up to 100 times larger). 
This brings possibility that current dns infrastructure may not be able to 
handle such increase of data flow. Also necessity to cache such large 
amount of data (remember most caching dns servers already require lots of 
RAM in order to cache the data, but if we increase the data that needs to 
be cached, the hardware requirements maybe too much to handle or it may 
require sacrifices in effective caching).

As such I believe it might be better to start thinking if new protocol 
should be invented that can be used (i.e. policy exchange protocol). This 
can be an effort similar to CRISP where XML structures are used and BEEP 
is used as underlying protocol. In this case DNS could provide reference 
through SRV or some other record to the actual location of such policy 
server. Such comprehensive system would allow to store additional data
such as for recepient server to indicate to sender what kind of policies 
in has for example it can indicate what reputation services it trusts
or what kind of policies it has in regards to messages (i.e. something 
like "no soliciting" but in more complex ways), or it could provide key
to be used to sign incoming message that is particular to the sender request.
This opens wide variety of extensions and ability to provide policies
on per-user basis as well. 

On Wed, 2 Jun 2004, Bob Atkinson wrote:

> Over the last several months, indeed, since somewhat well before last
> Christmas, if my memory serves, there has in these and other circles
> been floating general discussions concerning the use of digital
> signatures on e-mail for accomplishing purposes *other* than the
> traditional mail-author-signs-mail mechanism found today in systems like
> S/MIME and PGP.
> 
> >From what I can tell from these discussions, there appears to be at
> least a moderate degree of consensus that some sort of signature-based
> scheme along these lines might be useful in helping to deter spam
> (though whether the increase in deterrence is worth the cost of the
> effort still seems open to debate). However, there is some significant
> divergence of opinion as to how to best go about achieving that end.
> 
> Specifically, in this divergence there seem to be those who would like
> to digitally sign the literal entire bytes of (a suffix of) an RFC2822
> message body, and those (myself included) who quite strongly believe
> that such an approach is so fragile so as to ultimately be of quite
> little value.
> 
> But the core of the idea seems to me at least to be well worthy of
> continued investigation and discussion. To that end, trying to be
> constructive by painting a picture of how best I think this could
> actually be made to work, on
> 
> 	http://www.lessspam.org/EmailPostmarks.pdf
> 
> can be found a first, preliminary draft for discussion of an approach to
> non-user-level signing of e-mail that supports the ability to affix
> domain-related or other signed information to a message while taking
> pragmatic steps to be robust in the face of transformations that occur
> to messages as they flow in the Internet.
> 
> 	Bob
> 
> _______________________________________________
> Asrg mailing list
> Asrg at ietf.org
> https://www1.ietf.org/mailman/listinfo/asrg


_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg