Food (or at least a light snack) for tought.
"Marc A. Pelletier" <[email protected]> Wed, 11 Feb 2004 02:31:03 -0500
| Newsgroups | gmane.ietf.asrg.msgverify |
|---|---|
| Message-ID | <002c01c3f071$01163870$6402a8c0@vampire> |
This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C3F047.17E0D260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My current toughts, in semirandom order, if only to start the discussion: Message verification consists of three orthogonal goals: a) Some means to asign to a message the identity ultimately responsible for= it being transmitted; b) some means to verify the authenticity of that assignment; and c) some means to assess the 'spamness likelihood' of the originating identi= ty in order to decide eventual disposition of the message (probably only as= a factor in that decision). While (c) above presumably falls outside the strict purview of msg-verify, = we nonetheless need to keep that goal in mind as any putative verification = scheme has value (at least as far as spam is concerned) only insofar as the= information gained can then be used. White- and blacklisting come to mind= , so is aggregating statistical information to help decide border cases. We also need to distinguish the case of a claim of identity that has been m= ade and disproven from the case where the sending system does not make any = claim at all-- a scenario that will remain frequent for a long time even in= the most optimistic of scenarios because of deployment delays, if nothing = else. I've been doing quite a bit of research on (a), and the only definitive con= clusion I have reached at this point is that to be ultimately useful, this = needs to be done at the level of the envelope (given that to be most useful= , any decision about the disposition of a message needs to be done as early= as possible-- preferably before the message itself has been transmitted). = My own original proposal [TORO] relied on the addition of a MAIL FROM para= meter to transmit that information in the envelope. In TORO, I had mostly punted on (b), relying on an ad-hoc RDNS-like solutio= n that leaves a number of vulnerabilities open (even though it did raise th= e barrier to spam). Such vulnerabilities have been (and are being) hashed = over and over on the main list. Now, a possible good idea might be to implement (b) with a "web of trust" s= imilar to PGP's; specifically that any MTA may "know" a number of other MTA= s, and be assigned a transitive trust level. If, say, I trust example.net = and example.net has signed example.com's public key then I can assign part = of the trust I have into example.net onto example.com's claims of identity.= Such a scheme allows fairly high reliability in establishing cryptographi= c identity without relying on a central authority, and has been proven to w= ork rather well in practice. A sender could transmit its (signed) public k= ey, or those keys could be found in some standardized location(s). This re= sists compromise of the repositories since a key that is not signed by some= one you trust (directly or indirectly) has little or no value. In TORO, which might be a fair basis, the MTA where the message was origina= lly submitted would attach an origin token to the envelope when it could es= tablish who the entity ultimately responsible for the message was. Custome= rs of an ISP, say, or employees, or simply users on a box. The token was = defined as opaque, and included the identity of the organization handling t= he MTA (in the form of a domain name; simply '[email protected]'). In the simple case where there are no relays, the receiving MTA would note = the origin, verify that the sender was trustworthy to not lie about it (ori= ginally simply by RDNS), and then possibly use that origin (or lack thereof= ) as a factor in deciding the disposition of the message. Things get a bit more hairy when relays are involved. Should the relay pas= s along the identity token to the next step if it trusted the sender? This= seems, at first glance, reasonable given the transitive nature of trust in= the web scheme-- you trust your peers to send you only information they h= ave made themselves or that they beleive. This is a presumption I had made= in TORO, but it was weaker there because of the lack of a cryptographical = means to assess trust. This means, of course, that there needs to be a way to revoke trust if you = find an MTA has been lying to you. This is a classical key management prob= lem, and there are known (although not always satisfying) solutions. We mi= ght consider the concept of signatures over keys with 'negative trust'. ex= ample.com may well sign 'I trust a.com, b.com and c.com, but d.com has lied= to me before'. Someone who trusts example.com might then use that informa= tion in order to decide how much (or not) to trust those domains. Nothing prevents the existence of 'trust blacklists', where you can check t= he trustworthiness of an uncertain server. Or, indeed, of public whitelist= s where some entity signs MTA keys who have met some criterion of accountab= ility or reliability. Which of such lists, if any, an MTA operator would c= heck would be a deployment decision. The nice part about this entire scheme is that it fails gracefuly. In the = case where you speak with an implementation that doesn't support the scheme= at all, or if there are technical problems in authenticating claimed origi= ns, then you are no worse off than right now: you don't get the additionna= l information but you do not loose the message or the rest of its envelope. Toughts? -- Marc A. Pelletier ------=_NextPart_000_0029_01C3F047.17E0D260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>My current toughts, in semirandom order, i= f only to=20 start the discussion:</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>Message verification consists of three ort= hogonal=20 goals:</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>a) Some means to asign to a message= =20 the identity ultimately responsible for it being transmitted;</FONT></= DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>b) some means to verify the authentic= ity of=20 that assignment; and</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>c) some means to assess the 'spamness= =20 likelihood' of the originating identity in order to decide eventu= al=20 disposition of the message (probably only as a factor in that=20 decision).</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>While (c) above presumably falls outside t= he strict=20 purview of msg-verify, we nonetheless need to keep that goal in mind as any= =20 putative verification scheme has value (at least as far as spam is concerne= d)=20 only insofar as the information gained can then be used. White- and= =20 blacklisting come to mind, so is aggregating statistical information to hel= p=20 decide border cases.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>We also need to distinguish the case of a = claim of=20 identity that has been made and disproven from the case where the sending s= ystem=20 does not make any claim at all-- a scenario that will remain frequent for a= long=20 time even in the most optimistic of scenarios because of deployment delays,= if=20 nothing else.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>I've been doing quite a bit of research on= (a), and=20 the only definitive conclusion I have reached at this point is that to be= =20 ultimately useful, this needs to be done at the level of the envelope (give= n=20 that to be most useful, any decision about the disposition of a message nee= ds to=20 be done as early as possible-- preferably before the message=20 itself has been transmitted). My own original proposal [TORO] re= lied=20 on the addition of a MAIL FROM parameter to transmit that information = in=20 the envelope.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>In TORO, I had mostly punted on (b), relyi= ng on an=20 ad-hoc RDNS-like solution that leaves a number of vulnerabilities open (eve= n=20 though it did raise the barrier to spam). Such vulnerabilities have b= een=20 (and are being) hashed over and over on the main list.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>Now, a possible good idea might be to impl= ement (b)=20 with a "web of trust" similar to PGP's; specifically that any MTA may "know= " a=20 number of other MTAs, and be assigned a transitive trust level. If, s= ay, I=20 trust example.net and example.net has signed example.com's public key then = I can=20 assign part of the trust I have into example.net onto example.com's claims = of=20 identity. Such a scheme allows fairly high reliability in establishin= g=20 cryptographic identity without relying on a central authority, and has been= =20 proven to work rather well in practice. A sender could transmit its= =20 (signed) public key, or those keys could be found in some standardized=20 location(s). This resists compromise of the repositories since a key = that=20 is not signed by someone you trust (directly or indirectly) has little or n= o=20 value.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>In TORO, which might be a fair basis, the = MTA where=20 the message was originally submitted would attach an origin token to the=20 envelope when it could establish who the entity ultimately responsible for = the=20 message was. Customers of an ISP, say, or employees, or simply users = on a=20 box. The token was defined as opaque, and included the identity= of=20 the organization handling the MTA (in the form of a domain name; simply <A= =20 href=3D"mailto:'[email protected]'">'[email protected]'</A>).</= FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>In the simple case where there are no rela= ys, the=20 receiving MTA would note the origin, verify that the sender was trustworthy= to=20 not lie about it (originally simply by RDNS), and then possibly use that or= igin=20 (or lack thereof) as a factor in deciding the disposition of the=20 message.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>Things get a bit more hairy when relays ar= e=20 involved. Should the relay pass along the identity token to the next = step=20 if it trusted the sender? This seems, at first glance, reasonable giv= en=20 the transitive nature of trust in the web scheme-- you trust your pee= rs to=20 send you only information they have made themselves or that they beleive.&n= bsp;=20 This is a presumption I had made in TORO, but it was weaker there because o= f the=20 lack of a cryptographical means to assess trust.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>This means, of course, that there needs to= be a way=20 to revoke trust if you find an MTA has been lying to you. This is a= =20 classical key management problem, and there are known (although not always= =20 satisfying) solutions. We might consider the concept of signatures ov= er=20 keys with 'negative trust'. example.com may well sign 'I trust a.com,= =20 b.com and c.com, but d.com has lied to me before'. Someone who trusts= =20 example.com might then use that information in order to decide how much (or= not)=20 to trust those domains.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>Nothing prevents the existence of 'trust= =20 blacklists', where you can check the trustworthiness of an uncertain=20 server. Or, indeed, of public whitelists where some entity signs MTA = keys=20 who have met some criterion of accountability or reliability. Which o= f=20 such lists, if any, an MTA operator would check would be a deployment=20 decision.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>The nice part about this entire scheme is = that it=20 fails gracefuly. In the case where you speak with an implementation t= hat=20 doesn't support the scheme at all, or if there are technical problems in=20 authenticating claimed origins, then you are no worse off than right now:&n= bsp;=20 you don't get the additionnal information but you do not loose the message = or=20 the rest of its envelope.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>Toughts?</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>-- Marc A. Pelletier</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV></BODY></HTML> ------=_NextPart_000_0029_01C3F047.17E0D260--