Should XHASHCASHNEWKEY be accepted only after MAIL and before RCPT, as the draft says?
We want a way of charging lots of hash cash for accepting keys. Accepting as non-tentative, that is. We also want accepting of keys to depend on other criterias. But this is all policy.
What should the draft say and what are the ideas on how to implement some of the foreseeable policies?
Linus Nordberg linus@nordberg.se writes:
We want a way of charging lots of hash cash for accepting keys. Accepting as non-tentative, that is. We also want accepting of keys to depend on other criterias. But this is all policy.
What should the draft say and what are the ideas on how to implement some of the foreseeable policies?
There are several questions which must be answered.
1. How are MTA:s identified? That's section four of the draft, I really appreciate comments on that.
2. If you want hash cash challenges outside of the mail transaction, how should the challenge string be constructed?
But I'm not yet conviced the large one-time payment need be explicit in the protocol. Let me think loud...
Perhaps it works just as well to charge a large amount the first few times any given MTA wants to send email? (The theory is that if a new MTA is highly abusive to it's environment, it is likely to be shut down within a few days). And then the new MTA's are also the ones you're not sharing keys with.
Say you have the following policy:
1. Sending MTA does not share a key with you: => Challenge difficulty 10 minutes cpu time.
2. Sending MTA shares a key with you, and uses it properly to authenticate itself. However, the key is not trusted by your local receiver: => Challenge difficulty 30 seconds of cpu time.
3. Sending MTA shares a key with you, authenticates porperly, and key is trusted by local user: => No challenge.
Does that make sense to you? Do you see any advantage of an additional charge for the key exchange?
One simple consequence is that in the mail transaction, the client should tell the mailserver which keyid it is going to use before asking for a challenge (and the server should remember it when the client comes back).
/Niels
nisse@lysator.liu.se (Niels Möller) wrote 21 Oct 2004 15:49:11 +0200:
| 1. How are MTA:s identified? That's section four of the draft, I | really appreciate comments on that.
Perhaps keys should be associated with the domain part of envelope recipient and not with two "MTA names"? I'm not sure if this solves any problems, I just came up with it when going through some of the possibilities. Some thoughts follow.
Associating key to sending MTA (speaking of an MTA as a program running on a single host) is not fruitful because a sending MTA may serve multiple domains. It also poses great trouble with asymmetry when sending and receiving MTA are separated, at least as long as we consider mail going both ways to be a sign of mutual trust.
Or is it that I haven't grasped the concept of user policies yet? Argh, this is hard!
| 2. If you want hash cash challenges outside of the mail transaction, | how should the challenge string be constructed?
Are you referring to the i'll-be-back-later-with-the-answer thing?
| But I'm not yet conviced the large one-time payment need be explicit | in the protocol. Let me think loud...
The protocol should allow it, that's all.
| Perhaps it works just as well to charge a large amount the first few | times any given MTA wants to send email? (The theory is that if a new | MTA is highly abusive to it's environment, it is likely to be shut | down within a few days). And then the new MTA's are also the ones | you're not sharing keys with. | | Say you have the following policy: | | 1. Sending MTA does not share a key with you: => Challenge | difficulty 10 minutes cpu time. | | 2. Sending MTA shares a key with you, and uses it properly to | authenticate itself. However, the key is not trusted by your | local receiver: => Challenge difficulty 30 seconds of cpu time. | | 3. Sending MTA shares a key with you, authenticates porperly, and | key is trusted by local user: => No challenge. | | Does that make sense to you? Do you see any advantage of an additional | charge for the key exchange?
Criteria for transition from 1 to 2 is still that mail has been going both ways between the MTA:s? As an alternative, a large payment might be wanted.
| One simple consequence is that in the mail transaction, the client | should tell the mailserver which keyid it is going to use before | asking for a challenge (and the server should remember it when the | client comes back).
When speaking of client coming back, we mustn't forget to demand that the client connects to the very same MTA the second time. We don't want to replicate the database with outstanding challenges between all MX hosts for domain. The time span might be short.
Linus Nordberg linus@nordberg.se writes:
nisse@lysator.liu.se (Niels Möller) wrote 21 Oct 2004 15:49:11 +0200:
| 1. How are MTA:s identified? That's section four of the draft, I | really appreciate comments on that.
Perhaps keys should be associated with the domain part of envelope recipient and not with two "MTA names"?
That's one possibility; identify the sending MTA with the domain part of the envelope addresses. It makes sense for the receiving MTA. But I think we need something different för the sending MTA (consider forwarding/relaying; then the envelope sender address is unrelated to the sending MTA).
Associating key to sending MTA (speaking of an MTA as a program running on a single host) is not fruitful because a sending MTA may serve multiple domains.
Hmm. I think the reason we need an id for the sending MTA is as follows:
1. Say a@a.com sends email to b@b.com for the first time. They exchange a key k, and now a.com knows that this key is associated with b.com, and it will try to use it next time it sends mail to b.com.
The problem is the reply; how can b.com know that it should use this key for email to a.com?
2. The sender MTA id is also used for XHASHADVISE: There may be several independent machines receiving mail for the same domain, not sharing key databases. Sending MTA:s will have several keys for this domain. Each time it connects, it uses XHASHADVISE, and the server will tell it the right keyid to use. For the server to be able to do that, it needs to know who it is talking to. (In case sending and receiving domains have n independent machines each, there will be n^2 keys, and XHASHADVISE will list n of them.
I like the idea to have bidirectional exchange of mail automatically imply some level of trust. But it doesn't work in the asymmetric case. Perhaps we have to give up on that, or at least provide some alternative.
With unidirectional keys, there is less need for sender MTA id, but (2) may still apply.
at least as long as we consider mail going both ways to be a sign of mutual trust.
Or is it that I haven't grasped the concept of user policies yet? Argh, this is hard!
The user table determines which keys are trusted when receiving mail for a particular user. The automatic mechanism just modifies the corresponding entry in the user table automatically when the same user sends email.
| 2. If you want hash cash challenges outside of the mail transaction, | how should the challenge string be constructed?
Are you referring to the i'll-be-back-later-with-the-answer thing?
No, the context was "Should XHASHCASHNEWKEY be accepted only after MAIL and before RCPT, as the draft says?". The challenge in the spec is constructed from the envelope addresses of the current mail transaction. If we want to to do hashcash challenges outside mail transactions (i.e. before MAIL FROM:), this way of constructing the challenge makes no sense.
| Say you have the following policy: | | 1. Sending MTA does not share a key with you: => Challenge | difficulty 10 minutes cpu time. | | 2. Sending MTA shares a key with you, and uses it properly to | authenticate itself. However, the key is not trusted by your | local receiver: => Challenge difficulty 30 seconds of cpu time. | | 3. Sending MTA shares a key with you, authenticates properly, and | key is trusted by local user: => No challenge. | | Does that make sense to you? Do you see any advantage of an additional | charge for the key exchange?
Criteria for transition from 1 to 2 is still that mail has been going both ways between the MTA:s?
No. The transition 1 -> 2 is an execution of the XHASHCASHNEWKEY protocol. The transition 2 -> 3 is bidirectional exchange of mail, and it doesn't have to apply globally to all users.
As an alternative, a large payment might be wanted.
I agree that makes some sense. I'd like to see a motivation for the key-setup cost, though, I think there are some hidden assumptions there, like on the number of emails a spammer wants to send to the same user.
Say we allow a large payment C_3 as an alternative way to force the transition, and let the cost sending email be C_1 and C_2 in states 1 and 2 above. Then, if a spammer wants to send N messages each to M users on the same mailserver, depending on spammer's actions, the total cost, and cost per mail, can be
Spammer never establishes any key: N*M*C_1 per email: C_1
Spammer exchanges a key, but never gets to state 3: C_1 + (N*M-1)*C_2 = (C_1-C_2) + M*N*C_2 per email: C_2 + (C_1-C_2) / (N*M)
Spammer exchanges key, and pays to go to state 3: C_1 + M*C_3 per email: C_1 / (N*M) + C_3 / N
It seems clear that a large "one-time" cost, be that C_1 (per MTA) or C_3 (per receiver) is amortized over the number of mails sent. And I see no reason to believe that N will be small.
When speaking of client coming back, we mustn't forget to demand that the client connects to the very same MTA the second time.
What does "same" mean? Same A-record (IP address), or the same MX-record?
/Niels
nisse@lysator.liu.se (Niels Möller) wrote 22 Oct 2004 10:49:27 +0200:
| Linus Nordberg linus@nordberg.se writes: | | > nisse@lysator.liu.se (Niels Möller) wrote | > 21 Oct 2004 15:49:11 +0200: | > | > | 1. How are MTA:s identified? That's section four of the draft, I | > | really appreciate comments on that. | > | > Perhaps keys should be associated with the domain part of envelope | > recipient and not with two "MTA names"? | | That's one possibility; identify the sending MTA with the domain part | of the envelope addresses. It makes sense for the receiving MTA. But I | think we need something different för the sending MTA (consider | forwarding/relaying; then the envelope sender address is unrelated to | the sending MTA). | | > Associating key to sending MTA (speaking of an MTA as a program | > running on a single host) is not fruitful because a sending MTA may | > serve multiple domains. | | Hmm. I think the reason we need an id for the sending MTA is as | follows: | | 1. Say a@a.com sends email to b@b.com for the first time. They | exchange a key k, and now a.com knows that this key is associated | with b.com, and it will try to use it next time it sends mail to | b.com. | | The problem is the reply; how can b.com know that it should use | this key for email to a.com?
a.com will suggest the key k in its response to XHASHCASHADVISE, based on the domain part of the envelope sender?
| 2. The sender MTA id is also used for XHASHADVISE: There may be | several independent machines receiving mail for the same domain, | not sharing key databases. Sending MTA:s will have several keys | for this domain. Each time it connects, it uses XHASHADVISE, and | the server will tell it the right keyid to use. For the server to | be able to do that, it needs to know who it is talking to. (In | case sending and receiving domains have n independent machines | each, there will be n^2 keys, and XHASHADVISE will list n of | them. | | I like the idea to have bidirectional exchange of mail automatically | imply some level of trust. But it doesn't work in the asymmetric case. | Perhaps we have to give up on that, or at least provide some | alternative.
I think we should keep it but provide alternative ways of establishing mutual trust. Ideas include manual configuration by sysadmins (of involved MTA:s), manual configuration by end users (MUA talks to MTA somehow) and large single payment (configured by user or admin).
It's tempting to throw in lots of stuff here but we should probably consider what happens if we get software that's hard to configure properly and we end up with something like the open relay problem of the old days.
| > | 2. If you want hash cash challenges outside of the mail transaction, | > | how should the challenge string be constructed? | > | > Are you referring to the i'll-be-back-later-with-the-answer thing? | | No, the context was "Should XHASHCASHNEWKEY be accepted only after | MAIL and before RCPT, as the draft says?". The challenge in the spec | is constructed from the envelope addresses of the current mail | transaction. If we want to to do hashcash challenges outside mail | transactions (i.e. before MAIL FROM:), this way of constructing the | challenge makes no sense.
My ignorance. Please ignore.
| > | Say you have the following policy: | > | | > | 1. Sending MTA does not share a key with you: => Challenge | > | difficulty 10 minutes cpu time. | > | | > | 2. Sending MTA shares a key with you, and uses it properly to | > | authenticate itself. However, the key is not trusted by your | > | local receiver: => Challenge difficulty 30 seconds of cpu time. | > | | > | 3. Sending MTA shares a key with you, authenticates properly, and | > | key is trusted by local user: => No challenge. | > | | > | Does that make sense to you? Do you see any advantage of an additional | > | charge for the key exchange? | > | > Criteria for transition from 1 to 2 is still that mail has been going | > both ways between the MTA:s? | | No. The transition 1 -> 2 is an execution of the XHASHCASHNEWKEY | protocol. The transition 2 -> 3 is bidirectional exchange of mail, and | it doesn't have to apply globally to all users. | | > As an alternative, a large payment might be wanted. | | I agree that makes some sense. I'd like to see a motivation for the | key-setup cost, though, I think there are some hidden assumptions | there, like on the number of emails a spammer wants to send to the | same user.
We should include Torbjörn here. He's been thinking about this more than I have.
| Say we allow a large payment C_3 as an alternative way to force the | transition, and let the cost sending email be C_1 and C_2 in states 1 | and 2 above. Then, if a spammer wants to send N messages each to M | users on the same mailserver, depending on spammer's actions, the | total cost, and cost per mail, can be | | Spammer never establishes any key: N*M*C_1 | per email: C_1 | | Spammer exchanges a key, but never gets to state 3: C_1 + (N*M-1)*C_2 | = (C_1-C_2) + M*N*C_2 | per email: C_2 + (C_1-C_2) / (N*M) | | Spammer exchanges key, and pays to go to state 3: C_1 + M*C_3 | per email: C_1 / (N*M) + C_3 / N | | It seems clear that a large "one-time" cost, be that C_1 (per MTA) or | C_3 (per receiver) is amortized over the number of mails sent. And I | see no reason to believe that N will be small.
Unless the key is tied to originating IP address some way or another, perhaps through MX records.
I'm answering the easy parts now , hopefully getting back to the harder parts later. I'll be pretty busy with teaching and stuff the rest of the autumn.
Linus Nordberg linus@nordberg.se writes:
nisse@lysator.liu.se (Niels Möller) wrote 22 Oct 2004 10:49:27 +0200:
| Hmm. I think the reason we need an id for the sending MTA is as | follows: | | 1. Say a@a.com sends email to b@b.com for the first time. They | exchange a key k, and now a.com knows that this key is associated | with b.com, and it will try to use it next time it sends mail to | b.com. | | The problem is the reply; how can b.com know that it should use | this key for email to a.com?
a.com will suggest the key k in its response to XHASHCASHADVISE, based on the domain part of the envelope sender?
Makes some sense. I think the effect is about the same as to specify that the "mta id" is the domain-part of the envelope address. But it won't work if b.com is a relay (but I'm not sure that matters, perhaps bidirectionality is broken anyway in that case).
From what I've heard, many spammers send 10k messages or less from each single zombie machine nowadays to avoid that the operator notices what's happening.
And if that is beneficial for the spammer, the work could be divided between the zombies in such a way that all the 10k email transmitted by one zombie goes to a single or to a small number of MTA:s.
Generally, I would like to avoid tying keys to IP addresses, but it might be what's most effective after all.
One simple thing one could do is to associate the keys that are established by the big upfront payment mechanism with an IP address, without having such an association for keys in general. But I'm still sceptic to the usefulness if this mechanism. Are there any legitimate email use cases?
| > When speaking of client coming back, we mustn't forget to demand that | > the client connects to the very same MTA the second time. | | What does "same" mean? Same A-record (IP address), or the same | MX-record?
Same machine,
"Same machine" is not an answer that makes sense to the client at the other end of the network. Say the smtp client is sending mail to user@example.com, and we have
example.com MX mail1.example.com # (precedence/priority doesn't matter) example.com MX mail2.example.com
mail1.example.com A 1.2.3.4 mail1.example.com A 1.2.3.5
mail2.example.com A 1.2.3.6 mail2.example.com A 1.2.3.7
Say that the client connects to 1.2.3.4, gets a challenge, disconnects, solves challenge, and then connects again. Do you want it to connect to
* 1.2.3.4 (i.e. same IP as last time)
* Either of 1.2.3.4 and 1.2.3.5 (i.e. any A record associated with mail1.example.com, which was the domain used for the A lookup last time)
* Any of 1.2.3.4-7 (i.e. any A record associated with any MX associated with example.com)
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) wrote 27 Oct 2004 21:35:42 +0200:
| > | Hmm. I think the reason we need an id for the sending MTA is as | > | follows: | > | | > | 1. Say a@a.com sends email to b@b.com for the first time. They | > | exchange a key k, and now a.com knows that this key is associated | > | with b.com, and it will try to use it next time it sends mail to | > | b.com. | > | | > | The problem is the reply; how can b.com know that it should use | > | this key for email to a.com? | > | > a.com will suggest the key k in its response to XHASHCASHADVISE, based | > on the domain part of the envelope sender? | | Makes some sense. I think the effect is about the same as to specify | that the "mta id" is the domain-part of the envelope address. But it | won't work if b.com is a relay (but I'm not sure that matters, perhaps | bidirectionality is broken anyway in that case).
The bidirectionality seems deemed when the sending and receiving MTA's for a domain are not sharing key and policy databases. I can't see how this can be fixed regardless of how the id for the sending MTA is constructed. The relationship between sending and receiving MTA's might perfectly well be nil.
| > | > When speaking of client coming back, we mustn't forget to demand that | > | > the client connects to the very same MTA the second time. | > | | > | What does "same" mean? Same A-record (IP address), or the same | > | MX-record? | > | > Same machine, | | "Same machine" is not an answer that makes sense to the client at the | other end of the network. Say the smtp client is sending mail to
I thought I was speaking to a human being. :-)
I mean the same machine, the very same host running a single instance of MTA software listening on port 25. But of course, we'll have to specify "same IP address" if we want the client to understand that and hope that people putting their MTA's behind load balancing equipment realise that SMTP has changed.
mta-hashcash@lists.lysator.liu.se
-
Linus Nordberg -
nisse＠lysator.liu.se