RIPE 53

Anti-Spam Working Group - RIPE 53, Amsterdam:
Thursday, 5 October 2006 14:00-15:30 (UTC+2)

Chair - Rodney Tillotson
Scribe - Rob Allen
Jabber Scribe: Susannah Gray
About 40 people present for most of the session

A. Administrative Matters

Thanks to Rob Allen (RIPE NCC) for taking minutes, and to Susannah Gray (RIPE NCC) for being the Jabber endpoint. Agenda agreed as published at http://www.ripe.net/ripe/meetings/ripe-53/agendas/anti_spam.html.

Draft minutes from RIPE 52 are at http://www.ripe.net/ripe/wg/anti-spam/r52-minutes.html.

There were no changes suggested and they will now be marked as final.

Priority Items:

Review of ISP Spam Measures - Pascal Manzano (ENISA)
DKIM and e-mail abuse - Eliot Lear (Cisco)

Review of ISP Spam Measures - Pascal Manzano (ENISA)

http://www.ripe.net/ripe/meetings/ripe-53/presentations/isp_spammeasures.pdf

Significant findings from a survey of provisions made by ESPs in Europe:

• Increasing Transparency
  • Reporting of security breaches
  • Becoming aware of a security or spam problem
• Defining Appropriate Security
  • State of the art and cost of implementations
  • Email security versus privacy
• Setting Standards
  • Technical and Organisational Security Measures
  • Measures to fight spam

Points arising from questions afterwards:

ENISA do not know whether the 1% of service providers who wished they could do more to fight spam had legal or sales reasons for not doing so. The survey did not ask for that information.

Some North American ISPs had said they were concerned at the possibility of retaliation by spammers. It seems this had been in the form of legal threats which are now less of a problem.

Pascal noted that ENISA are thinking of continuing with their survey and if WG attendees or others want to help with this, they can still fill in the ENISA questionnaire. http://www.enisa.europa.eu/doc/pdf/deliverables/enisa_security_spam.pdf

DKIM and e-mail abuse - Eliot Lear (Cisco)

http://www.ripe.net/ripe/meetings/ripe-53/presentations/dkim.pdf

The core DKIM specification is now slated to become a Proposed Standard, having successfully completed Last Call and been approved by the Internet Engineering Steering Group (IESG). It specifies a method for authorities within a domain to sign a message in such a way that the signature is verifiable through DNS.

On its own DKIM should be able to reduce the number of bogus Mail Delivery Notifications (MDNs). Combined with other mechanisms DKIM provides a necessary set of tools to fight spam and phishing.

There are unfinished components to DKIM. One in particular is what is currently known as the Sender Signing Protocol (SSP). For instance, does a domain sign all of its mail or just some, and who does it allow to sign its mail? We are currently reviewing requirements for such a protocol and will discuss them at the San Diego IETF meeting in November.

Points arising from questions afterwards:
DKIM records include semicolon separators, which must be escaped in the DNS. People who are not DNS experts are at risk of breaking their zones while trying to set up SPF for their domains. This is a symptom of a bigger issue, that administrator tools will be necessary for this and other aspects of DKIM management (compare the BIND tools for DNSSEC management). It should be possible for scripts to generate and install most of what is needed for a domain.

It is important for the deployment of DKIM that such tools emerge in good time. Eliot hopes to release some early (Perl) versions as the standards are developed. The underlying tasks (eg key generation) are not difficult, but installation of the private key in an MSA will be product specific.

Spammers learned from the SPF experiment that they could use it to make them seem legitimate, and it is important that DKIM does not become discredited in the same way. That will be largely a matter of education and PR, and of avoiding hasty and ill-considered deployment.

SPF and DKIM are two sides of the same coin. Opinions differ on which is better and more scalable, and the IETF have decided to standardise on DKIM. Currently 20-25 companies are involved with the DKIM effort. Eric Allman and Sendmail Inc are committed to DKIM and the Sendmail MTA/MSA product will make it accessible to many ISPs.

A major distinction between the two technologies is that while SPF is path based, DKIM focuses on origin and destination. This choice affects the threat analysis and the way in which common scenarios are accommodated. A mailing list reflector, for example, will normally change the originator and SPF will be unable to verify it against the sending domain. DKIM can deal with this by preserving the original values for "From:" and perhaps "Subject:" in the DKIM signed header field. The interpretation of a DKIM signature is then somewhat complex and it is not yet clear how to present signed and unsigned messages to the recipient (though SPF would have faced similar issues).

The major ESPs are not yet united. Yahoo! and Google are using DKIM (or the earlier Domain Keys) for signing; MSN and AOL SPF or Sender ID. All are cautious about making hard delivery decisions on this basis. All recognise that it is essential for consensus and convergence to emerge as soon as possible.

It is reasonable to hope that the IETF will approve the base DKIM specifications this year, and that SSP will follow during 2007, although there is still a lot of work to do.

SSP is critical for broad uptake and deployment. Without SSP you can already sign your own domain and check the signature in an incoming message, and that will add value immediately for both outbound and inbound traffic. For instance, you might wish to increase the SpamAssassin score for an unsigned message from a remote domain for which a signature was expected, although you could not decide it was spam from that DKIM result alone. The design intention is that SSP is the basis for knowing what to expect, and will clarify more complex scenarios: for example, a marketing company signing messages on your behalf.

There are questions (some of which applied also to SPF) over the use of DNS as the directory and key infrastructure; and support for SSP will further increase the demands on the DNS. The DKIM view is that the additional load will not be a problem; the information is highly read-optimised.

The underscore in the added domain name component seems strange, but it has only ever been a convention that underscores were not used elsewhere. An alternative is to add a new record type, but that is unlikely to be part of the initial deployment.

There is a critical level of implementation and deployment at which people will perceive that DKIM has tangible benefits. It is possible that frustrated end users will demand action before DKIM developers believe the service is ready. It is essential to get consensus as soon as possible on the choices to make now that will make e-mail better in the medium or long term.

The need to migrate a huge installed infrastructure is largely a social and business issue. SPF and Sender ID had the same deployment problems as DKIM. [since the meeting: Microsoft have now "freed" Sender ID", but it is not clear that this will increase take-up]

Although the spam problem is one of the drivers for it, DKIM is not the Final Universal Solution. Other key things needed include best practices, and mechanisms to see if a site is following those best practices.

The main question is what to do with a message from someone you don't know, and that's what DKIM begins to address. The DNSBLs from Spamhaus and others merely list some but not all bad actors; it is also necessary to recognise good sources, and having some assurance of their identity is a start.

DKIM does not help at all with some problems, such as phishing through a domain whose name is made to look or sound like the legitimate target.

There is a more general need to improve authentication methods on the Web. One relevant example in the IETF is PwdHash from Stanford: http://crypto.stanford.edu/PwdHash/

The idea is to hash your password against the domain name of the destination website so that the real password never goes across the wire. It should be easy to deploy and eliminates risk from use of the password, provided the target site is correctly identified when the password is registered.

Classes of phishing remain that we can't fix, such as tricking a user into providing credit card information independently of site credentials.

B Updates

B1 Developments in e-mail abuse

B1.1 Phishing

In the UK there has been a significant rise in targeted phishing; the targets are the users of some particular organization. The e-mail content and the phishing Web site are tailored to appeal to those users, apparently on the basis of public knowledge about the organization concerned but not necessarily with specific inside information.

Sites particularly exposed to phishing include North American and Asian banks whose authentication systems are not the best. European banks seem less commonly targeted, but a number of banks in Germany have recently been the subject of messages in well-written German. Phishing is a multi-lingual activity. There is no pattern of insider collaboration.

phishtank.com (run by openDNS) is a mechanism for reporting phishing scams and potentially coordinating response to them.

[Off-topic]
There was a case recently in a Swedish bank which was using two way identification where a man-in-the-middle attack succeeded in taking over a live session. Consumers have a potential difficulty when bank technology is supposed to be good, that denial is their first response to alleged security problems.

B1.2 Advance Fee fraud

419 type scams are on the increase now with multiple character sets and languages, and from countries other than Nigeria. Practice is to send directly from Internet cafes (no botnets yet). West African countries remain a major source; oddly enough, the Netherlands is also the source of much 419 abuse.

B1.3 Header forgery

Becoming steadily more effective; at last even the timestamps in some forged headers are indistinguishable from real ones.

B1.4 Bounce manipulation

Despite what it may feel like, it still seems unlikely that e-mail backscatter generated by bulk mail abuse achieves any business aim for the abusers.

B1.5 GIF content

There is a large class of bulk messages in which the whole advertising payload is contained in a GIF (possibly animated). The senders introduce small variations to the image, keep it fairly small and include a separate text body part (normally of chunks of borrowed literature, technical writing or even code fragments) to make the pattern of these messages very hard to match, and to ensure that in Bayesian analysis, the score for the text outweighs the presence of the image.

At present the images are harmless; they carry advertising content and the bulk mailers want you to read them without interference from anti-virus or similar software. In this case reading the message with a text-only mail program is slightly more irritating than with a graphical one, as you see pages of Bayes-blinding text. It is unfortunate that some e-commerce suppliers also send messages in graphics that are broken for some text e-mail clients. The practice lowers the resistance of some recipients to opening such messages, so letting in some spam and some viruses.

B2 Developments in anti-abuse

B2.1 Litigation

There continue to be a small number of criminal convictions for bulk mail senders.

B2.2 Sender authentication

Covered following the DKIM presentation.

B2.3 Internet Governance Forum (IGF)

Comments from Roland Perry (Public Affairs Officer, RIPE NCC). RIPE NCC were in at the start through WSIS (the World Summit on Information Society) and continue to take part in planning and organizing meetings through the NRO (Number Resource Organization). The next IGF is in Athens in November; among other things, they will be discussing spam. RIPE NCC members will get a report after the meeting.

Adiel Akplogan, AfriNIC CEO and a member of the IGF Advisory Group, invited any volunteers from the Anti-Spam WG who wanted to be part of the panel in the forthcoming IGF Workshop on Spam to contact him or the RIPE NCC and provide a brief resume.

B2.4 Legislation

Finland currently hold the EU presidency and their regulations (in place since 2004) are of particular interest. ISP open relays are explicitly forbidden, direct SMTP is not available by default and ISPs are expected to monitor traffic flows to detect abuse. The regulations have some impact on consumers who use ISPs or ESPs other than TeliaSonera or Elisa (the two largest).
Regulations: http://www.ficora.fi/englanti/document/FICORA112004M.pdf
Detailed specifications: http://www.ficora.fi/englanti/document/SMS11.pdf
We hope that for RIPE 54 we can get a presentation on the impact for local ISPs and on enforcement.

B2.5 Products

There were no new products to discuss.

C Technical Measures

C1 Filtering

AOL recently started rejecting e-mails on the basis that an IP address (with three colons) has been included in the content of an e-mail.

C2 Direct SMTP and Roaming

We heard from Finland (earlier), Sweden and Norway of arrangements to make it common for consumer connections to be prevented from making direct SMTP connections (blocking port 25). Obviously there are individuals for whom that is not convenient, and where the service they need is seen as non-standard they may be at a disadvantage. They may have to sign a more complicated contract accepting responsibility for misuse; or they may be asked to pay more, though nobody had any real-life examples of price increases.

It would be helpful to have a consensus on what "Internet service" means for consumers. One view is that the Internet must be free from access restrictions and unnecessary controls; on the other hand applying certain restrictions to the connections of a large class of non-specialist end users leaves them able to use all the facilities they need and can limit some kinds of abuse, to the benefit of all Internet users and their service providers.

Making two classes of service available avoids the issue of principle, but results in additional provisioning cost and complexity for service providers.

At least in Norway, it would be valuable to have BCP on this question (and others) recognised in the ISP community before putting in place specific legislation on spam. A further update to ripe-206 would be valuable and would support recommendations of ENISA and the OECD Anti-Spam Task Force too.

D Interactions

Database WG There is still work to do on on populating the RIPE NCC database with abuse contacts, by adapting the IRT object and possibly in other ways and then by encouraging maintainers to provide entries.

E Advice

E1 Initial update to ripe-206

Rodney gave a short presentation: http://www.ripe.net/ripe/meetings/ripe-53/presentations/ripe_206.pdf

The short-term need is to bring the RIPE BCP into line with the current LINX version. A draft showing the changes has been available for some time, and an informal last call on the WG mailing list produced only trivial further changes. At Rodney's invitation the WG session agreed that consensus had been reached; he will now get the document published.

E2 Possible enhancements to ripe-206

A few comments made by e-mail on the immediate update had been deferred to a future, significantly updated version of the document; and there are other things we should consider, such as:

• We ought to have a simpler document and one that is easier to read for readers whose first language is not English.
• The target audience is not well-defined; the structure and content need to be accessible to a variety of classes of reader such as big/small ISPs, consumers, users of medium sized ISPs.
• The business practices and the technology of e-mail abuse have moved on and new material is needed.
• Some content (eg open relays) is no longer so relevant and might be given less space.

This will require a lot of work; a lot of people have already written BCP documents they consider to be comprehensive. But as noted above, the RIPE document is widely referred to by organizations in Europe (eg OECD, London Action Plan, ENISA) and it is important that it is accurate and up-to-date. If we substantially update ripe-206, we should let such organizations know and invite their feedback.

Rodney will send something to the mailing list about how to move forward with the work, and will start to find offers of help.

X AOB

X1 AfriNIC tutorial

Adiel Akplogan, AfriNIC CEO, called for experts interested in providing a tutorial on issues associated with spam, phishing and e-mail security at the forthcoming AfriNIC Meeting (Mauritius 27 November to 1 December 2006) to contact him.

X2 Spamhaus

At the time of this session it had begun to emerge that Spamhaus, maintainers of the ROKSO information about spamming organizations and of the SBL and related IP address lists, were being subjected to litigation by a bulk mailing company in Illinois who had demanded (among other things) the suspension of their domain name www.spamhaus.org. Spamhaus give some details of the action at http://www.spamhaus.org/legal/index.lasso

Although Spamhaus are regularly subject to attacks of every kind by e-mail abusers, this has attracted some attention and the extent of the risk to them in practice is unclear. WG members were urged to indicate their support for Spamhaus if the need arose.

Z Agenda for RIPE 54

Rodney asked the Working Group to contact him if they had any input (requests or offers) for the working group session at RIPE 54. The outline of the agenda will be as usual.