Key exchange

Niels Möller nisse at lysator.liu.se
27 Oct 2004 21:35:42 +0200


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