Subject: Re: Last Call: 'Email Submission Between Independent Networks' to BCP

From: Bruce Lilly <[email-masked]>
Date: Sat, 11 Jun 2005 09:27:01 -0400

>  Date: 2005-06-11 03:04
>  From: "Christian Huitema" <[email-masked]>

> Steve Bellovin was alluding to the "evil twin" attack on wireless
> network. Allow me to elaborate.
> 
> The technique allows an attacker to lure unsuspecting travelers to
> connect to an un-protected wireless network under the attacker control.
> Very often, laptops are programmed to fetch pending e-mail as soon as
> they connect to a network. The laptop will try resolve
> "mail.example.com", and start a POP3 or IMAP exchange. The attacker
> controls the DNS service on the wireless network, and will easily spoof
> the server. It will then respond to the connection with a CRAM-MD5
> challenge, and harvest the e-mail address of the victim as well as the
> answer to the challenge. The attacker is now in a position to obtain the
> e-mail and password pair for the victim. The attack lasts a few seconds,
> and may not require any particular action by the victim. 

Thank you, Christian; we now have a concrete description of a specific
problem.

There is however, a subtle difference between POP3/IMAP and SMTP as
used by the draft under discussion.  POP3/IMAP authenticate a user as
authorized to access the contents of one or more mailboxes, whereas
SMTP involves a client host and a server. [while SMTP provides for
specification of a mailbox (for delivery notifications), during multi-
hop transfers that mailbox remains unchanged as the message is
transferred from client to server/client to server, so is not usable
for authentication of a client host]

For the "evil twin" problem, the following seem to apply to SMTP:
o the client cannot be certain of the server's identity.  This seems
  to be characteristic of the SMTP protocol; the client identifies
  itself, but the server does not (at least not other than in optional
  text which is (a) easily forged and (b) specifically required to be
  disregarded by the client)
o the "evil twin" could harvest client (host) identity and credentials,
  that would allow the "evil twin" to spew spam and malware as if it
  were the client
o the "evil twin" could harvest mailbox information (but not access
  credentials) from SMTP MAIL FROM and RCPT TO commands, and could
  collect or modify any unencrypted message (header and body)
  content
o TLS doesn't seem to help, as the "evil twin" can certainly use TLS,
  either on port 465 or via STARTTLS on either port 25 or 587 to lure
  the client into revealing host credentials; worse, it may give
  message senders a false sense of privacy if message content is not
  encrypted by a separate mechanism such as S/MIME or PGP/MIME.
o As I understand it, control of DNS does not appear to be necessary.
  The "evil twin" is in effect a man-in-the-middle, which can "proxy"
  the application protocol between the traveler's host and the
  legitimate remote server, both for collection of information and
  for modification of application-layer content.  That could, for
  example, be implemented as port-based TCP filtering without the
  need to affect DNS transactions. Specifically, even if the
  traveler uses a hard-coded IP address of the SMTP server, the
  "evil twin" can intercept the session data.

[the assumption in the above analysis is that the attacker can use an
access point implemented as or connected to a router, rather than as
a pure bridge, and that the network configuration behind the AP is
not easily determined by the victim]

o Again, as I understand it, the mode of access need not be wireless;
  the same sort of "proxying" could take place via any sort of
  network connection (e.g. wired Ethernet connections as provided
  by some hotels)
o On a wired network implemented via hubs (as opposed to switches),
  eavesdropping is of course possible by third parties. TLS may be
  effective against that case and the one immediately below. 
o unprotected wireless access opens the communications to attacks
  other than man-in-the-middle by eavesdroppers.
o even protected wireless access (for some unspecified meaning of
  "protected") is susceptible to attacks by an unscrupulous provider
o Even "protected" wireless access is susceptible to man-in-the-
  middle attacks; there exist wireless APs implemented as routers
  which are capable of operating in multiple modes, including
  as a type of range extender.  Firmware modification could
  provide for eavesdropping or content replacement or session
  redirection, and a no-firmware-modification implementation
  could tie two units (one acting as an access point, the other
  operating as an AP client to the genuine access point), providing
  the man-in-the-middle attacker with access to data via the wired
  connections between the two APs.

> IETF protocols should not endorse the use of unprotected
> challenge-response mechanism. They certainly should not lure clients to
> accept challenges from unauthenticated servers.

Has either been codified in an approved RFC (BCP or otherwise)?

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

---

From: [email-masked]
Date: Fri, 17 Jun 2005 03:51:37 +0000

No need to go against your nature just to make me feel comfortable Larry, post any which way you like as I'm capable of following the thread whichever way you do it.
I understand your point about the prepaying but the reason I don't think that's the answer is that if money were the cause then there'd be at least some spill-over (companies that once in awhile shelled out the bucks or defrauded the post office using tampered stamp machines which some snail-mail advertising companies have done to the tune of $20 million).  Since I've never been offered herbal viagra or a piece of Nigeria via the post office I have to assume there's yet another reason.  Am I right, how could I know, that's why this is just food for thought if you will.
--
Best regards, 
Nick Staff
[email-masked]
-------------- Original message -------------- 
> Since you top posted, I will, against nature, respond in kind. 
> 
> The one "item" you missed from your analogy is that postal mail is "paid" for 
> up front, by the person "posting" (anon or not) - eg the post-office gets 
> paid _before_ your letter gets delivered. The problem with spam is that the 
> receipient is "paying" the cost (cod with no chance to refuse delivery)... 
> 
> -- 
> Larry Smith 
> SysAd ECSIS.NET 
> [email-masked] 
> 
> 
> On Thursday 16 June 2005 21:50, [email-masked] wrote: 
> > I'm sure many will think this a stupid comment, but in the hopes that some 
> > don't I'll point out that the largest and arguably most efficient messaging 
> > system in the world is built upon open relay. Anyone can anonymously drop 
> > a letter in any mailbox in the US and while there's junk mail it's 
> > proportions are certainly nothing like spam. Why the difference? Well 
> > first I split spam into 2 categories: 1. legitimate advertisements for 
> > legitimate products (whether solicited or unsolicited). 2. Fraudulent 
> > mail, scams, cons, etc. 
> > I think the email abusers almost entirely fall into the second category and 
> > that nobody would be complaining if spam primarily consisted of 
> > Bloomingdale's catalogues and coupon val-paks. So I think we are attacking 
> > things the wrong way. The methods we are using - whether blacklists or 
> > 'authorized email' is going to either prove fruitless or end up ruining the 
> > big picture, which for me is electronic communication for everyone, to 
> > everyone. Using electronic means, I don't see how we can ever prevent spam 
> > and still have open global communication among disparate systems. It would 
> > be a different story if one organization ran all email servers worldwide 
> > but that horrible thought aside there will always be holes and breaks in an 
> > authentication/authorization scheme unless people limit who they can 
> > communicate with, and even then there will be spam. There's also the 
> > returns we see on our efforts to consider. Think of the millions of 
> > man/woman hours spent trying to stop spam - so many hours it probably would 
> > have taken less to inspect every email by hand. And then when you think 
> > (if you believe as I do) that everything can be gotten around and that 
> > security holes are as infinite as the imagination, well then you know there 
> > will always be some kid with a script (which also includes any real 
> > spammer) who will be able to get around your defenses within a week of them 
> > being implemented. My last unconstructive comment is that simple systems 
> > scale lossless and complex systems grow in a complexity proportionate to 
> > their size. Funny enough, I think the postal inspector's department came 
> > about because of the amount of scams being sent via mail shortly after the 
> > civil war (such a glut that it was bringing the postal service to their 
> > knees). Yet the postal service remained open-relay - why? Maybe because 
> > they realized that they didn't need to 'trace' scam-mail because scams are 
> > trace-inclusive as the scammer must include a point of contact. Sure 
> > there's the occasional anonymous letter bomb but since their resources 
> > aren't spent blocking coupon mailers they are much more likely to catch the 
> > big stuff. I know there are 8 trillion problems with this idea but I think 
> > in general, email fraud needs to become like mail fraud and there needs to 
> > be a team of inspectors who follow up on such reports and arrest violators 
> > (I know the Internet is bigger than the US, so of course it's up to each 
> > country how to handle it). I'm sorry for the non-technical post but I 
> > think blacklists are disgusting (I don't care if they help or not) and I 
> > just think so much brilliance could be directed elsewhere. Thanks and best 
> > regards, 
> > Nick Staff 
> > [email-masked] 
> > -------------- Original message -------------- 
> > 
> > > > it's possible to have open relays that don't contribute to spam. but 
> > > > those relays need to employ some other means, e.g. rate limiting, to 
> > > 
> > > Rate limiting is a relatively recent technique. Though very useful it 
> > > has... ummm, limited applicability. 
> > 
> > mostly because of blacklists. it was working fine for its intended 
> > purpose. 
> > 
> > > One needs to be careful not to dismiss established techniques in favor of 
> > > the latest fashionable one that is not as well fully understood. 
> > 
> > I don't know what you mean by "relatively recent", but I was doing it at 
> > least as early as April 1999 - that's the last mod date on my source files. 
> > RFC 2554 only dates from March 1999. 
> > 
> > > For example, rate limiting is used to control a single source. It's quite 
> > 
> > useful 
> > 
> > > when used at the destination. At a sufficiently well-run source network, 
> > > it 
> > 
> > also 
> > 
> > > can be pretty useful. 
> > 
> > It's also pretty useful for preventing a relay from being exploited by 
> > spammers. 
> > 
> > > The problem is with zombies. They make mush of old-time models of spam, 
> > > since they demonstrate that a very small data stream from a single source 
> > > can be leveraged into a very, very large data stream, given enough 
> > > sources. 
> > 
> > Rate limiting of this type (based on source IP address), if done properly, 
> > doesn't 
> > help or hurt zombies. The rates need to be set such that zombies can send 
> > directly 
> > to the recipients' MXes as easily, and more reliably, as they can send the 
> > same mail via the rate limiting SMTP servers. 
> > 
> > > One can start imagining more complex rate-limiting models, but then we 
> > > would 
> > 
> > be 
> > 
> > > talking about research efforts. A BCP is not supposed to rely on 
> > > research, especially when it hasn't been done. 
> > 
> > Maybe you should stick to talking about things that you know something 
> > about. 
> > 
> > > > block spam. the goal of such relays is to make it at least as easy 
> > > > for the spammer to simply contact the appropriate MXes for the 
> > > > destination addresses as to use the relays. of course it is necessary 
> > > > for such relays to record source IP addresses, etc., so that they are 
> > > > as traceable to their origin as messages sent directly to MXes. 
> > > 
> > > I don't know how much experience you have trying to do such tracing, but 
> > > the spamops folks have made quite clear that it is both vastly more 
> > > effort and considerably less productive, than one might expect. 
> > 
> > That's a problem with mail relaying in general, not just with open relays. 
> > Now if you want to discourage multi-hop mail relaying, that might actually 
> > be useful for lots of reasons besides just traceability. 
> > 
> > > > unfortunately, the vigilante character of various open-relay 
> > > > blacklists 
> > > 
> > > blacklists are not the subject of this BCP. 
> > 
> > This thread has pretty much diverged from the subject of your draft 
> > document anyway. 
> > 
> > > > killed any attempt at this kind of innovation. just as we're now in 
> > > > danger of various kinds of brain-dead "authentication" methods and 
> > > > meaningless requirements killing useful email functionality. 
> > > 
> > > new authentication methods are not the subject of this BCP. 
> > 
> > You mean "your draft document". It's certainly not a BCP as it's 
> > currently written. 
> > 
> > Keith 
> > 
> > -- 
> > Best regards, 
> > Nick Staff 
> > -------------- Original message -------------- 
> > 
> > > > > it's possible to have open relays that don't contribute to spam. but 
> > > > > those relays need to employ some other means, e.g. rate limiting, to 
> > > > 
> > > > Rate limiting is a relatively recent technique. Though very useful it 
> > > > has... ummm, limited applicability. 
> > > 
> > > mostly because of blacklists. it was working fine for its intended 
> > > purpose. 
> > > 
> > > > One needs to be careful not to dismiss established techniques in favor 
> > > > of the latest fashionable one that is not as well fully understood. 
> > > 
> > > I don't know what you mean by "relatively recent", but I was doing it at 
> > > least as early as April 1999 - that's the last mod date on my source 
> > > files. RFC 2554 only dates from March 1999. 
> > > 
> > > > For example, rate limiting is used to control a single source. It's 
> > > > quite 
> > > 
> > > useful 
> > > 
> > > > when used at the destination. At a sufficiently well-run source 
> > > > network, it 
> > > 
> > > also 
> > > 
> > > > can be pretty useful. 
> > > 
> > > It's also pretty useful for preventing a relay from being exploited by 
> > > spammers. 
> > > 
> > > > The problem is with zombies. They make mush of old-time models of spam, 
> > > > since they demonstrate that a very small data stream from a single 
> > > > source can be leveraged into a very, very large data stream, given 
> > > > enough sources. 
> > > 
> > > Rate limiting of this type (based on source IP address), if done 
> > > properly, doesn't 
> > > help or hurt zombies. The rates need to be set such that zombies can send 
> > > directly 
> > > to the recipients' MXes as easily, and more reliably, as they can send 
> > > the same mail via the rate limiting SMTP servers. 
> > > 
> > > > One can start imagining more complex rate-limiting models, but then we 
> > > > would 
> > > 
> > > be 
> > > 
> > > > talking about research efforts. A BCP is not supposed to rely on 
> > > > research, especially when it hasn't been done. 
> > > 
> > > Maybe you should stick to talking about things that you know something 
> > > about. 
> > > 
> > > > > block spam. the goal of such relays is to make it at least as easy 
> > > > > for the spammer to simply contact the appropriate MXes for the 
> > > > > destination addresses as to use the relays. of course it is necessary 
> > > > > for such relays to record source IP addresses, etc., so that they are 
> > > > > as traceable to their origin as messages sent directly to MXes. 
> > > > 
> > > > I don't know how much experience you have trying to do such tracing, 
> > > > but the spamops folks have made quite clear that it is both vastly more 
> > > > effort and considerably less productive, than one might expect. 
> > > 
> > > That's a problem with mail relaying in general, not just with open 
> > > relays. Now if you want to discourage multi-hop mail relaying, that might 
> > > actually be useful for lots of reasons besides just traceability. 
> > > 
> > > > > unfortunately, the vigilante character of various open-relay 
> > > > > blacklists 
> > > > 
> > > > blacklists are not the subject of this BCP. 
> > > 
> > > This thread has pretty much diverged from the subject of your draft 
> > > document anyway. 
> > > 
> > > > > killed any attempt at this kind of innovation. just as we're now in 
> > > > > danger of various kinds of brain-dead "authentication" methods and 
> > > > > meaningless requirements killing useful email functionality. 
> > > > 
> > > > new authentication methods are not the subject of this BCP. 
> > > 
> > > You mean "your draft document". It's certainly not a BCP as it's 
> > > currently written. 
> > > 
> > > Keith 
> > >