Subject: RE: [Asrg] porkhash: flexible anti-impersonation mail signatures

From: "Bob Atkinson" <[email-masked]>
Date: Thu, 3 Apr 2003 09:56:46 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, April 02, 2003 11:00 PM

> This is not unique to porkhash, many if not majority of proposals
either
> directly or indirectly rely on source or some central server being
> reachable for confirmation (all certificate based proposals, my
callback
> verification proposals, RMX - have to have working dns server, etc.)

True.

However, one notable difference is that RMX and similar ideas make use
of the one central server (DNS) that must necessarily *already* exist in
order that one can even receive mail in the first place.

This is a qualitative difference from having to set up some additional
server, though the exact flavor and degree of that difference isn't
clear (to me at least).

	Bob

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

---

From: J C Lawrence <[email-masked]>
Date: Thu, 03 Apr 2003 10:36:55 -0800

On Thu, 3 Apr 2003 09:56:46 -0800 
Bob Atkinson <[email-masked]> wrote:

> of the one central server (DNS) that must necessarily *already* exist
> in order that one can even receive mail in the first place.

> server, though the exact flavor and degree of that difference isn't

First thoughts: 

  DNS is cacheable, DNS is distributed, DNS has well developed authority
  delegation structures, DNS behaviour as both a service and a control
  point is well understood and exercised, requirements and costs for
  running DNS (in whatever configuration) are well defined, and DNS
  involves no inventions of new wheels with new threat models.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
[email-masked]               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked]
Date: Thu, 3 Apr 2003 08:55:06 -0800 (PST)

So if say we have porkhash but for verification is somehow done through 
dns server. Then you would have no problem?

---

From: [email-masked] (Justin Mason)
Date: Thu, 03 Apr 2003 11:40:50 -0800

> dns server. Then you would have no problem?

Yep -- there's nothing saying the verification server can't respond
via DNS queries.   The only issues I'd see would be (a) max size of DNS
query packets (the query has to contain the sender_id data, which could
be an entire Received header), and (b) current DNS server software does
not have an easily-extensible design for dynamic responses (a la HTTP's
CGI).

DNS would definitely be more lightweight, in terms of network traffic
and latency, though.

Also, regarding cachability.  Note that the verification query operation
uses the following data:

  - sender_id (usually email addr?)
  - timestamp
  - opaque_md5_sum = md5(sender_id, timestamp, secretkey)

For each unique message, regardless of which recipient is doing the query,
those pieces of data will not change; so the response is cacheable.

Also worth noting that in the original design, there's no state held on
the verification server, apart from the shared secret.  So a farm of
verification servers (whether using DNS as the transport or not), can be
used to deal with heavy load.   (adding state, such as a db of valid
Message-Ids, would complicate this of course.)

--j.

---

From: [email-masked]
Date: Thu, 3 Apr 2003 10:41:47 -0800 (PST)

I was trying to be somewhat sarcastic or at least trying to make a point 
based on the response I was expecting, though it appears you took my 
words too seriously (note that I'm not saying its good or bad to do 
verification by dns, its just one of the options). I'll have to be more 
direct with what I was going to say...

The point was that its not the problem with requiring persistant connection
for verification server, because we already do that by using dns protocol. 
So really the issue being raised is about choosing (or creating) verification
protocol to be flexible enough for many enviroments. It does not mean we 
can not create dns-like protocol for verification that will work just find 
for usually disconnected nodes or for that matter if http is used, its 
also quite flexible, widely deployed, has cashing system, etc.

---

From: J C Lawrence <[email-masked]>
Date: Thu, 03 Apr 2003 12:41:51 -0800

On Thu, 3 Apr 2003 10:41:47 -0800 (PST) 
william  <[email-masked]> wrote:

> The point was that its not the problem with requiring persistant
> connection for verification server, because we already do that by
> using dns protocol. So really the issue being raised is about choosing
> (or creating) verification protocol to be flexible enough for many
> enviroments. It does not mean we can not create dns-like protocol for
> verification that will work just find for usually disconnected nodes
> or for that matter if http is used, its also quite flexible, widely
> deployed, has cashing system, etc.

My concern there is distribution of the secret.  There's relatively
little value in cacheing the value of an authenticity check.  Its not
something that a given site tends to repeat.  However repetitive checks
of *different* messages from the same MTA will be common, each one
hammering the possessor of the secret.  

A system which doesn't require either distribution of the secret, or
ready access to the secret by uninvolved parties would seem better.

---

From: [email-masked] (Justin Mason)
Date: Thu, 03 Apr 2003 13:42:51 -0800

> ready access to the secret by uninvolved parties would seem better.

Well, there's no *need* to distribute the secret beyond (a) the MTA
and (b) the verification server for that MTA. 

It *can* be distributed to roaming users, allowing them to "impersonate"
an account on that domain no matter where they're mailing from, but that's
just sugar, strictly speaking; it's not really a core part of the
protocol.

BTW I'm not sure what you mean by "uninvolved parties" -- there's only

  (a) the MTA
  (b) the verification server
  (c) -- optionally -- MUAs of roaming users who should be allowed
  to impersonate an address at that domain

--j.

---

From: [email-masked]
Date: Thu, 3 Apr 2003 23:26:25 -0800 (PST)

> ready access to the secret by uninvolved parties would seem better.

There is very little we can do if server can not verify what it just got. 
In current email system all information regarding the message is contained 
in the message itself and this is exactly what got us in the situation we 
currently have because spammer can enter whatever he wants and email appears
to be right to the receiving system since it does not do any validation.

There are 3 ways around it (very generalized):
1. Email (or some kind of other property of connection, such as connecting
system name or ip) can have some information that receiving system will 
check (during delivery or shortly afterwards) with another system to 
verify that this is correct. This is direct verification, like porkhash, 
like rmx, like message tracking verification, etc. 
2. Email (or connection property) can be assumed to be correct if certain
parameters match (or even no parameters) such as it contains a S/MIME or 
if name of the server that sent it matches name in "From:", etc. However 
to avoid spammers using valid parameters, a verification would still need 
to be done with some server/service that has "bad parameters list",for 
S/MIME  this would be revocation server. In this category goes also all 
blacklists and similar systems (email assumed right, check with blacklist).
Ther are two subclasses here:
  a. Verification service is external to receiving system and requires check
     through internet at the same time or shortly after email is received.
     All blacklist dns servers go into this category.
  b. Bad parameters list is distributed to each system prior to it receiving
     email and it can then use this list to verify each email at the time
     of delivery but it does not require separate lookup. Example of this
     would be certificate revocation list distributed to all systems.
     Another example of this is your /etc/mail/access file, which is 
     static blacklist which you setup prior to receiving email.
3. Email (or connection property) can be assumed to be bad unless it is 
expected and contains some specific parameter negotiated with receiver 
prior to the email transmission. Example of this are all challenge/response
systems. The benefits of this are, of course, that receiving server already
knows this unique email parameter that it is expecting and does not need 
to do any lookup, but this is done only because it has already negotiated 
this parameter with sender before. Another example of this would be my 
opt-out system, where also a key is somehow provide to sender to be used 
in sending out the message. Also all whitelists go into this category as 
here verification parameter is "From" which is checked against prior made 
lists of good addresses.

Of the above 2b and 3 do not require any lookup during transmission, but 
unfortunetly they all require prior negotiation and generally this may not 
work very well with such a widely used media as email (huge lists of 
good/bad that needs to be ready prior to receiving email).

Also while we're on this subject, the above 1, 2a, 2b, 3 are actually kind 
of attempt to classify solutions (taxonomy), if you notice #1 and #3 are 
example of fail-close system where email is assumed bad unless it contains 
some parameter that system is able to verify. With #2 its fail-open where
email is considered good but is check with some service to see if its actually
bad. On the other hand 1 & 2a are examples of systems that require real-time
check with external service/database during delivery (note that this includes
dns checks) to see if email is good or bad, while 2b and 3 are examples of 
systems where prior to receiving email the particular paramters for the 
email being received are already present on receiving end - so basicly for 
1/2a & 2b/3 we have another on how to classify a solution.

The presence of many of these components that can be used to classify every
solution is why I dislike all taxonomies that have been done so far - they 
are all binary trees and assume some comon top-level property (why any one 
in particular?). The better approach to taxonomy in my view would be to 
create a matrix where on X-axis we can have list of parameters and on 
Y-axis list of solutions. I'd like to create something like this, but
I just done have time...

----
William Leibzon
Elan Communications Inc. 
[email-masked]