Re: covert channel and noise -- was Re: proposal ...
On Sun, 15 Feb 2004, Ed Gerck wrote: > Dean Anderson wrote: > > > > It isn't the case that the spammer intended to send a message about > > the superbowl, but somehow "noise" altered the message to a > > solicitation on viagra. Rather, they intended to send a message on > > viagra, and you recieved their message, noise free. But seeing the > > solication for viagra, you became upset, and reported a complaint > > about the inappropriate use of the channel. In > > information-theory-speak, you report a "communication in violation of > > the security model"; a covert or sneaky channel. > > I guess we agree that if the message can be read by the intended recipient > then it's not in a covert channel. A covert channel is one that can't even > be detected by the intended recipient. But, you may ask, "who" is the > intended recipient? Err, we do not agree on that. You still misunderstand the nature of a covert channel. I suggest you re-read the definitions and references in the reposted messages from Ellis Cohen and Stavros Macrackis. A covert or sneaky channel is merely one in which the communication is //not authorized by the security model// It has nothing to do with readability or detectability. There is no theorem that says covert channels cannot be detected. Quite obviously, they are detected, and some action might be taken. Theory just says that you cannot prove they aren't there. Let me put it another way: A "null" reading on your "covert channel detector" does not mean there aren't any covert channels--Just that you haven't detected any. This is a subtle, yet significant difference. In yet other words: you whack-a-mole when you find one, but you can't say that there aren't any moles. It is not a game you can win. You have to keep looking and keep whacking, so long as there are moles to pop up. The arcade whack-a-mole game stops when you run out of time, but our game only stops when no one wants to spam or conduct abuse or government intervention prevents them from playing. We now have a legal process to use against abusers who are not commercial--most, if not all, genuine commercial spammers will simply comply with the law. That leaves those who aren't genuinely commercial, and whose intent it is to annoy people. > An example of such a covert channel is if a spammer hides information > in the subject line by using wrongly spelled forms of "viagra", This could be a covert channel. But its also possible that the whole spam message even with a correctly spelled viagra would be a covert or sneaky channel if it is not //authorized by the security model//, and the "security model" is simply an Acceptable Use Policy statement not to do that. In this case, you may have a very weak "covert channel detection" process. But extreme weakness in the process is irrelvent to the theory. What, if anything, has to be done to get past the detection process and the security model and into your mailbox is irrelevant. The security model can be made quite extensive, such as with Mandatory Access Controls as implemented in secure operating systems. Even so, one cannot say that there aren't covert channels. One can say other things about them, but not that thing. Information theory has proved itself useful to the analysis of anti-spam schemes. Besides being able to rule out a number of schemes which promise to be complete technical solutions to spam, we also see what range of solutions can be implemented about spam and what results we can expect to see from that range. Consider the case of Mandatory Access Controls (MAC) for operating systems. We see that if we tighten up the controls on the flow of information, that we improve our chances of detection. Particularly, we hope to detect people trying to find covert channels before they succeed in finding one. This is very expensive, both in supervision costs, and in the difficulty of training workers to use such systems. In the case of classified government information, the cost is justified. Having a potential spy create a denied MAC security event while probing for a covert channel is well worth the effort, even if you can't be sure that they will be caught. The spy, or even potential spy or stupid user, is then removed from the secured areas. Even honest, but stupid users are removed, and this can be rationalized because they don't have the capacity to be trusted with sensitive information. It works because the same 'mole' doesn't get repeated chances to find the channel that will be successful, and there are legal processes to make that happen. You cannot lie on a security clearance application when it asks your identity, and if you've ever had a clearance revoked or denied. Expensive checks are made to ensure that your answers are truthful. But the same can't be said about spammers/abusers. We can't escort them out, and we can't even be sure of their identity in a civil context. Frequently, they are using someone else's identity or
Re: covert channel and noise -- was Re: proposal ...
"Robert G. Brown" wrote: > a) All hosts must resolve with DNS. If you list why this isn't used today perhaps you will change "must" to "may". > b) All hosts must support an encryption key registered with DNS that > permits all message hops to occur between registered hosts encrypted > with the destination host public key. Mail privacy can only be guaranteed with an end-to-end encryption. Securing email in message hops does nothing to prevent monitoring at each host in the hop -- with some hosts not even advertised in the header. > c) The header autogenerate a postmaster-recursive email address for > reporting abuse to the entire delivery path. This would put a rather > large burden on the main network backbone administrators -- they'd need > automated tools to help handle it. OTOH, it would REALLY give them an > incentive to shut down networks that are a primary source of abuse until > they manage to police themselves. This would create a huge liability for the backbone administrators -- for example, one false abuse report and they could be sued for disrupting lawful communications. Human supervision actually increases the liability -- it can't be blamed on a software glitch. > d) With keyed host registration, tools that can QUICKLY isolate an > originating host and bop its (ab)user (minimally get them off the > network, ideally "instantly" fine them or charge them money such as a > reconnection fee AFTER getting them off the network). Machines running amok, quickly killing off other machines without recourse, without explanation. A kangaroo court for email, penalizing the users. > This would give > end users a strong incentive to police their own systems against viruses > and would give spammers additional costs to pay or additional charges to > be brought against them, should they try to skip out. Again, what you propose is to penalize the victim -- the user. That's exactly what we should stop doing. > I personally would ALSO like it if AV vendors STOPPED bounce messages > altogether. Free speech, good luck.
Re: covert channel and noise -- was Re: proposal ...
"Robert G. Brown" wrote: > a) All hosts must resolve with DNS. If you list why this isn't used today perhaps you will change "must" to "may". > b) All hosts must support an encryption key registered with DNS that > permits all message hops to occur between registered hosts encrypted > with the destination host public key. Mail privacy can only be guaranteed with an end-to-end encryption. Securing email in message hops does nothing to prevent monitoring at each host in the hop -- with some hosts not even advertised in the header. > c) The header autogenerate a postmaster-recursive email address for > reporting abuse to the entire delivery path. This would put a rather > large burden on the main network backbone administrators -- they'd need > automated tools to help handle it. OTOH, it would REALLY give them an > incentive to shut down networks that are a primary source of abuse until > they manage to police themselves. This would create a huge liability for the backbone administrators -- for example, one false abuse report and they could be sued for disrupting lawful communications. Human supervision actually increases the liability -- it can't be blamed on a software glitch. > d) With keyed host registration, tools that can QUICKLY isolate an > originating host and bop its (ab)user (minimally get them off the > network, ideally "instantly" fine them or charge them money such as a > reconnection fee AFTER getting them off the network). Machines running amok, quickly killing off other machines without recourse, without explanation. A kangaroo court for email, penalizing the users. > This would give > end users a strong incentive to police their own systems against viruses > and would give spammers additional costs to pay or additional charges to > be brought against them, should they try to skip out. Again, what you propose is to penalize the victim -- the user. That's exactly what we should stop doing. > I personally would ALSO like it if AV vendors STOPPED bounce messages > altogether. Free speech, good luck.
Re: covert channel and noise -- was Re: proposal ...
"Robert G. Brown" wrote: > > On Sun, 15 Feb 2004, Ed Gerck wrote: > > > We can't lock the > > spammers' doors everywhere, we have to lock our door at our house. > > No, what we can do is the same thing we do with our real mail box. Make > it illegal to send certain classes of mail, for example letter bombs and > envelopes containing anthrax, and prosecute the hell out of anybody we > catch who does so. On the flip side, this is a good example of how the anthrax threat was not handled. The solution was not to rely on the illegality of sending anthrax (which, obviously, wasn't enough of a deterrent) or the probability of prosecuting the sender (which we have not yet done), but on a "lock" that was put on all mail coming in. Mail that came from unknown senders was more carefully verified and even sterilized, some was backtraced and the sender was verified. But postal mail, contrary to email, cannot put a burden on the sender that is higher than the postage cost. Email, rather than being cost-free for all senders, can be made expensive to senders we don't know. And the way to do it mandatorily is by using code -- not law. This is useful because our email is laced with the "anthrax" called spam. Filtering by subject line, email headers and body text is not enough, and frequently backfires by making us delay and even not read what would otherwise be a message of interest. BTW, the technique of imposing a task that burdens the sender in order to reduce interference due to rogue senders has a parallel in spread-spectrum technology, for example. By only receiving messages that are frequency-keyed as expected, my receiver can withstand jamming (i.e., noise messages that are in-band -- "spam"). This is in addition to other filters I have for post-processing.
Re: covert channel and noise -- was Re: proposal ...
> From: "Robert G. Brown" <[EMAIL PROTECTED]> > ... > I agree. However, all of the observations made so far regarding > spam/virus filtering in general still apply to filtering at the SMTP > level. I would say that NO keyword filtering could take place. The > best that one could do at the protocol level would be to reject messages > that fail to meet a tighter criterion than is currently required. What is "the SMTP level"? Is that during SMTP transactions between MTAs? Is "the protocol level" the same or something else? If both of those "levels" refer to SMTP transactions between MTAs, then the conclusion is wrong. Except for local administrative hassles, all spam and virus filtering that can be done later can instead be done during SMTP transactions between MTAs. Your SMTP server may need to wait to until the end of the DATA command to object to messages containing viruses, missing or bad SMTP headers or other objectionable content, but that works fine. I know of many millions of spam that are filtred during the DATA command every day, and I don't claim to know about any really big sites. The only problems are: - local administrative choices that keep bastion SMTP servers ignorant of per-user filter preferences - filtering at the DATA command requires either (1) rejecting for all or no targets or (2) accepting for all targets and siliently discarding the message for those targets that want it filtered. In theory the second problem could be fixed if the DATA command could accept a vector of 250-OK/4yz-try-later/5yz-fatal responses, one for each target named with a Rcpt_To command. In practice the spam problem will be solved one way or another long before such a protocol change would be sufficiently widely deployed to matter. Vernon Schryver[EMAIL PROTECTED]
Re: covert channel and noise -- was Re: proposal ...
>In fact, we are now facing a _second_ denial-of-service problem > (the first being spam itself clogging your mailbox): excessive bounce > messages automatically directed to mailboxes forged by spammers. And > this by its nature is a distributed-denial-of-service problem, even > harder to protect against. I agree, and in fact pointed out that bounce messages from AV programs are similar problem a week ago. So perhaps the discussion should separate into three different threads: a) Encryption and host authentication on the smtp channel. This might embrace open mail programs used as forwarding agents by both spammers and viruses. b) What to do about bounces in general. Bounce messages are useful or even essential in many contexts, but they are a source of both intentional and unintentional abuse in a world where headers are routinely forged. c) Spam, what (if anything) to do about it at the IETF level. It may be that good solutions to a) and b) may, together with some support in the form of laws, suffice to greatly ameliorate both spam and header-forged viruses by increasing the accountability of the enabling networks. Most of this traffic is ALREADY in violation of corporate acceptable use agreements -- part of the problem is that many ISP's have been very lax in enforcing acceptable use and tracking down violators. Part of THAT problem is that the networks selling access to the ISP's have in turn turned a blind eye to the ISP's. Perhaps a header-level/protocol-level solution would be a generalization of the postmaster address that points to a HUMAN responsible for policing the network(s) where spam/viruses originate. Yes, one could argue that postmaster already is such an address, but many of the smaller originating networks are run by amateurs and have no real postmaster. One really needs to be able to hit a recursive list of postmasters along the message's delivery route with warnings about violations of acceptable use. > >Spam-filtering _after_ the SMTP session _should_ be deprecated by > IETF, IMHO. While there is no question that any recipient has the > right to ignore any message, SMTP was intended to either deliver the > message or send back an error; and the loss of this feature reduces > the utility of e-mail. I agree. However, all of the observations made so far regarding spam/virus filtering in general still apply to filtering at the SMTP level. I would say that NO keyword filtering could take place. The best that one could do at the protocol level would be to reject messages that fail to meet a tighter criterion than is currently required. Perhaps: a) All hosts must resolve with DNS. b) All hosts must support an encryption key registered with DNS that permits all message hops to occur between registered hosts encrypted with the destination host public key. c) The header autogenerate a postmaster-recursive email address for reporting abuse to the entire delivery path. This would put a rather large burden on the main network backbone administrators -- they'd need automated tools to help handle it. OTOH, it would REALLY give them an incentive to shut down networks that are a primary source of abuse until they manage to police themselves. Automated tools at the highest level might just generate an "abuse histogram" that triggers a human response only when levels rise above that which might be identified as "reasonable" for a network participating in the eternal battle with the bad guys. d) With keyed host registration, tools that can QUICKLY isolate an originating host and bop its (ab)user (minimally get them off the network, ideally "instantly" fine them or charge them money such as a reconnection fee AFTER getting them off the network). This would give end users a strong incentive to police their own systems against viruses and would give spammers additional costs to pay or additional charges to be brought against them, should they try to skip out. I personally would ALSO like it if AV vendors STOPPED bounce messages altogether. SMTP bounce messages have a point and are even necessary; AV bounce messages are a joke, a waste of time, and a potential source of serious abuse. NO viruses currently exist that don't forge the header, it is just that most viruses nowadays use random forged headers out of the infected host's address books. They could, however, all claim to be from e.g. SCO or Microsoft (some already exist that do the latter, but more for social engineering reasons than DDOS, I think). rgb > > -- > John Leslie <[EMAIL PROTECTED]> > Robert G. Brownhttp://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:[EMAIL PROTECTED]
Re: covert channel and noise -- was Re: proposal ...
Robert G. Brown <[EMAIL PROTECTED]> wrote: > > THIS IS NOT A MATTER OF PROTOCOL! This is not the business of the IETF! > Tools exist to help you filter spam. Some, like spam assassin, are very > good and quite sophisticated. However, there is ALWAYS a tradeoff with > using this sort of tool -- too narrow a criterion for acceptance and you > lose real mail, too broad and you get all the spam anyway. I can choose > my level of tradeoff, and be fully aware of the risks. While the parameters of individual spam-filtering _should_ not be the business of IETF, there is a very real issue raised by filtering _after_ the SMTP session: During the SMTP session, it is quite possible to give an error which is likely to reach the right person; after the SMTP session, you have to "trust" the various header fields -- which are routinely forged by spammers. In fact, we are now facing a _second_ denial-of-service problem (the first being spam itself clogging your mailbox): excessive bounce messages automatically directed to mailboxes forged by spammers. And this by its nature is a distributed-denial-of-service problem, even harder to protect against. Spam-filtering _after_ the SMTP session _should_ be deprecated by IETF, IMHO. While there is no question that any recipient has the right to ignore any message, SMTP was intended to either deliver the message or send back an error; and the loss of this feature reduces the utility of e-mail. -- John Leslie <[EMAIL PROTECTED]>
