Institutionen för datavetenskap - DiVA portal128399/FULLTEXT01.pdf · 2008-12-16 · SE-581 83...

SE-581 83 Linköping, Sweden 581 83 Linköping

Linköpings universitet Linköpings universitet

2008-11-20

LIU-IDA/LITH-EX-A--08/055--SE

Rickard Bondesson

by

Deployment and analysis of DKIM with DNSSEC

Final thesis

Department of Computer and Information Science

Institutionen för datavetenskap

Linköping UniversityDepartment of Computer and Information Science

Final Thesis

Deployment and analysis of DKIM with DNSSECby

Rickard Bondesson

LIU-IDA/LITH-EX-A--08/055--SE

2008-11-20

Supervisor: Patrik Wallström

.se

Examiner: Juha Takkinen

ida, Linköping University

Avdelning, InstitutionDivision, Department

Division for Database and Information TechniqueDepartment of Computer and Information ScienceLinköping UniversitySE-581 83 Linköping, Sweden

DatumDate

2008-11-20

SpråkLanguage

� Svenska/Swedish� Engelska/English

�

�

RapporttypReport category

� Licentiatavhandling� Examensarbete� C-uppsats� D-uppsats� Övrig rapport�

�

URL för elektronisk version

http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-15899

ISBN—

ISRNLIU-IDA/LITH-EX-A--08/055--SE

Serietitel och serienummerTitle of series, numbering

ISSN—

TitelTitle

Driftsättning och analys av DKIM med DNSSECDeployment and analysis of DKIM with DNSSEC

FörfattareAuthor

Rickard Bondesson

SammanfattningAbstract

As the email system is widely used as a communication channel, and often iscrucial for the performance of organizations, it is important that users can trustthe content of what is being delivered to them. A standard called DomainKeysIdentified Mail (dkim) has been developed by the ietf to solve the problem withauthentication and integrity, by using digital signatures.

This master’s thesis goal is to evaluate the solution where an implementation ofdkim is extended with dnssec validation. dnssec is a solution which secures, amongother, the mapping between ip addresses and domain names. The implementationof dkim is deployed and evaluated with function testing, domain testing, threatanalysis, and interoperability testing.

dkim does not need any new public-key infrastructure, thus inflicting less coston the deployment compared with other cryptographic solutions such as s/mimeand pgp. We recommended to use dkim together with dnssec to secure the trans-portation of the dkim public key. The upcoming standard adsp can inform therecipient of whether a domain is signing its email or not and thereby a possibilityto detect any unauthorized signature removal. A further problem is that mailinglists often manipulate the email, thus breaking the signature. We therefore recom-mend to send email directly to the recipient or active dkim signing on the mailinglists.

NyckelordKeywords deployment, testing, analysis, DKIM, DNSSEC

AbstractAs the email system is widely used as a communication channel, and often iscrucial for the performance of organizations, it is important that users can trustthe content of what is being delivered to them. A standard called DomainKeysIdentified Mail (dkim) has been developed by the ietf to solve the problem withauthentication and integrity, by using digital signatures.

This master’s thesis goal is to evaluate the solution where an implementationof dkim is extended with dnssec validation. dnssec is a solution which secures,among other, the mapping between ip addresses and domain names. The im-plementation of dkim is deployed and evaluated with function testing, domaintesting, threat analysis, and interoperability testing.

dkim does not need any new public-key infrastructure, thus inflicting less coston the deployment compared with other cryptographic solutions such as s/mimeand pgp. We recommended to use dkim together with dnssec to secure the trans-portation of the dkim public key. The upcoming standard adsp can inform therecipient of whether a domain is signing its email or not and thereby a possibilityto detect any unauthorized signature removal. A further problem is that mailinglists often manipulate the email, thus breaking the signature. We therefore recom-mend to send email directly to the recipient or active dkim signing on the mailinglists.

v

Abbreviations

The following abbreviations will be used in this report.

.SE . . . . . . . . . . . . . . . The Internet Infrastructure FoundationADSP . . . . . . . . . . . . Author Domain Signing PracticesAES . . . . . . . . . . . . . . Advanced Encryption StandardCA . . . . . . . . . . . . . . . Certificate AuthorityCIA . . . . . . . . . . . . . . Confidentiality, Integrity, and AvailabilityCNAME . . . . . . . . . . Canonical NameDES . . . . . . . . . . . . . . Digital Encryption StandardDFD . . . . . . . . . . . . . Data-Flow DiagramsDKIM . . . . . . . . . . . . DomainKeys Identified MailDNS . . . . . . . . . . . . . . Domain Name SystemDNSSEC . . . . . . . . . DNS Security ExtensionsDoS . . . . . . . . . . . . . . Denial of ServiceDS . . . . . . . . . . . . . . . Delegation SignerEmail . . . . . . . . . . . . . Electronic mailI-D . . . . . . . . . . . . . . . Internet DraftIAB . . . . . . . . . . . . . . Internet Architecture BoardIETF . . . . . . . . . . . . . Internet Engineering Task ForceIMAP . . . . . . . . . . . . Internet Message Access ProtocolIP . . . . . . . . . . . . . . . . Internet ProtocolIPsec . . . . . . . . . . . . . Internet Protocol SecurityIRTF . . . . . . . . . . . . . Internet Research Task ForceISOC . . . . . . . . . . . . . Internet SocietyISP . . . . . . . . . . . . . . . Internet Service ProviderKSK . . . . . . . . . . . . . . Key Signing KeyLiU . . . . . . . . . . . . . . . Linköping UniversityMD5 . . . . . . . . . . . . . Message Digest algorithm 5MDA . . . . . . . . . . . . . Mail Delivery AgentMilter . . . . . . . . . . . . Mail filterMIME . . . . . . . . . . . . Multipurpose Internet Mail ExtensionsMIPA . . . . . . . . . . . . Mutual Internet Practices AssociationMSA . . . . . . . . . . . . . Mail Submission AgentMTA . . . . . . . . . . . . . Mail Transfer Agent

vii

viii

MUA . . . . . . . . . . . . . Mail User AgentNIC . . . . . . . . . . . . . . Network Interface CardNSEC . . . . . . . . . . . . Next SecurePGP . . . . . . . . . . . . . Pretty Good PrivacyPOP . . . . . . . . . . . . . Post Office ProtocolPRA . . . . . . . . . . . . . Purported Responsible AddressRFC . . . . . . . . . . . . . . Request for CommentsRIPEMD . . . . . . . . . RACE Integrity Primitives Evaluation Message DigestRR . . . . . . . . . . . . . . . Resource RecordS/MIME . . . . . . . . . Secure MIMESASL . . . . . . . . . . . . . Simple Authentication and Security LayerSHA . . . . . . . . . . . . . . Secure Hash AlgorithmSMTP . . . . . . . . . . . . Simple Mail Transfer ProtocolSMTP-AUTH . . . . SMTP Service Extension for AuthenticationSPF . . . . . . . . . . . . . . Sender Policy FrameworkTCP . . . . . . . . . . . . . . Transmission Control ProtocolTLD . . . . . . . . . . . . . . Top-level domainTLS . . . . . . . . . . . . . . Transport Layer SecurityTTL . . . . . . . . . . . . . . Time to LiveUDP . . . . . . . . . . . . . User Datagram ProtocolZSK . . . . . . . . . . . . . . Zone Signing Key

Contents

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.6 Target audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.7 Reference literature . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.8 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.9 Typographic conventions . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Background 52.1 History of the Internet . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 About the Internet Society . . . . . . . . . . . . . . . . . . . . . . 62.2.1 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.2 Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Domain name to IP address . . . . . . . . . . . . . . . . . . . . . . 72.3.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.2 DNS security risks . . . . . . . . . . . . . . . . . . . . . . . 92.3.3 Domain Name System Security Extensions . . . . . . . . . 10

2.4 The email system and its protocols . . . . . . . . . . . . . . . . . . 102.4.1 Internet Message Format . . . . . . . . . . . . . . . . . . . 112.4.2 Multipurpose Internet Mail Extensions . . . . . . . . . . . . 122.4.3 Simple Mail Transfer Protocol . . . . . . . . . . . . . . . . 122.4.4 Post Office Protocol . . . . . . . . . . . . . . . . . . . . . . 122.4.5 Internet Message Access Protocol . . . . . . . . . . . . . . . 122.4.6 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4.7 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.8 Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

ix

x Contents

3 Analysis of email security 153.1 Email spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Computer security . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.1 Cryptology . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.2 Cryptographic hash functions . . . . . . . . . . . . . . . . . 173.2.3 Digital signatures . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3 Email technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.1 Sender Policy Framework . . . . . . . . . . . . . . . . . . . 183.3.2 Author Domain Signing Practices . . . . . . . . . . . . . . . 183.3.3 SenderID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.4 Black-/grey-/whitelisting . . . . . . . . . . . . . . . . . . . 193.3.5 Secure MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3.6 Pretty Good Privacy . . . . . . . . . . . . . . . . . . . . . . 203.3.7 DomainKeys Identified Mail . . . . . . . . . . . . . . . . . . 203.3.8 DomainKeys . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.4 More about DKIM . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.4.1 Canocalization . . . . . . . . . . . . . . . . . . . . . . . . . 203.4.2 Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.4.3 DNS record . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4.4 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4.5 The need for DNSSEC . . . . . . . . . . . . . . . . . . . . . 23

4 Deployment and testing of DKIM 254.1 Server set-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.1 The lab environment . . . . . . . . . . . . . . . . . . . . . . 254.1.2 Supported mail servers . . . . . . . . . . . . . . . . . . . . . 264.1.3 Installation of necessary software . . . . . . . . . . . . . . . 26

4.2 Testing of DKIM Milter . . . . . . . . . . . . . . . . . . . . . . . . 294.2.1 Function testing . . . . . . . . . . . . . . . . . . . . . . . . 294.2.2 Domain testing . . . . . . . . . . . . . . . . . . . . . . . . . 304.2.3 Variables to test . . . . . . . . . . . . . . . . . . . . . . . . 304.2.4 Test cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2.5 Test results . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5 Threat analysis 395.1 Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2 Threat models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2.1 Data-flow diagram . . . . . . . . . . . . . . . . . . . . . . . 405.2.2 Attack trees . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2.3 Misuse cases . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6 Interoperability testing 556.1 Basic email routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.1.1 Test cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.1.2 Test results . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.2 Other technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Contents xi

6.2.1 Test cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.2.2 Test results . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.3 Other implementations . . . . . . . . . . . . . . . . . . . . . . . . . 756.3.1 Test cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756.3.2 Test results . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7 Statistics on DKIM usage 817.1 Measuring DKIM usage . . . . . . . . . . . . . . . . . . . . . . . . 81

7.1.1 Email in transit . . . . . . . . . . . . . . . . . . . . . . . . . 817.1.2 DKIM DNS records . . . . . . . . . . . . . . . . . . . . . . 82

7.2 Graphs on DKIM usage . . . . . . . . . . . . . . . . . . . . . . . . 837.2.1 At an email server . . . . . . . . . . . . . . . . . . . . . . . 837.2.2 Among the Swedish domains . . . . . . . . . . . . . . . . . 83

8 Summary and Conclusions 878.1 DKIM installation and testing . . . . . . . . . . . . . . . . . . . . . 878.2 DKIM Milter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888.3 Deployment of DKIM . . . . . . . . . . . . . . . . . . . . . . . . . 888.4 Interoperability tests . . . . . . . . . . . . . . . . . . . . . . . . . . 898.5 Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898.6 Statistics of current DKIM usage . . . . . . . . . . . . . . . . . . . 908.7 Demonstrations and presentations . . . . . . . . . . . . . . . . . . 908.8 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

9 Future work 93

Bibliography 95

A Installation of necessary software 99A.1 IP aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99A.2 OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100A.3 Key generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

A.3.1 DKIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101A.3.2 DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

A.4 Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102A.5 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102A.6 DKIM Milter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104A.7 IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108A.8 SASL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108A.9 Postfix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110A.10 Sendmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111A.11 Procmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114A.12 Masquerade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

A.12.1 Sendmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114A.12.2 Postfix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

A.13 Alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115A.13.1 Sendmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

xii Contents

A.13.2 Postfix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115A.14 Forward in the MTA . . . . . . . . . . . . . . . . . . . . . . . . . . 116A.15 Forward in the MDA . . . . . . . . . . . . . . . . . . . . . . . . . . 116

List of Figures2.1 The organization hierarchy of ISOC. . . . . . . . . . . . . . . . . . 62.2 A typical lookup of a domain name. . . . . . . . . . . . . . . . . . 92.3 The delivery of an email through the email system. . . . . . . . . . 13

3.1 Receiver validating the origin of the email with SPF. . . . . . . . . 19

4.1 The test configuration. . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1 Main DFD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2 Signing DFD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.3 Verifying DFD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.4 Simple attack tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.5 Attack tree 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.6 Attack tree 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.7 Attack tree 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.8 Misuse of email signing. . . . . . . . . . . . . . . . . . . . . . . . . 535.9 Misuse of email verification. . . . . . . . . . . . . . . . . . . . . . . 54

6.1 Description of test scenario 1. . . . . . . . . . . . . . . . . . . . . . 576.2 Description of test scenario 2. . . . . . . . . . . . . . . . . . . . . . 58

7.1 DKIM statistics 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . 847.2 DKIM statistics 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . 857.3 The number of Swedish domains using DKIM. . . . . . . . . . . . 86

Chapter 1

Introduction

This chapter will give an introduction to this thesis. The background and thepurpose of this thesis define why this thesis exists and are the foundation of themain thesis goal. A clear view of what to expect of this thesis is given by definingthe goals and the delimitations.

1.1 BackgroundThe Internet Infrastructure Foundation (.se) is located in Stockholm and is re-sponsible for the maintenance and administration of the Swedish national domainname registrar [50]. One of their main objectives is to actively contribute to theInternet’s development in Sweden. They are working at the frontier by looking atwhat technologies and practices are being developed and deployed on the marketand thereby continually starting new projects. The projects are meant to raisethe awareness of new technologies and practices or pushing the technologies andpractices closer to the end-users and the Internet service providers.

As the email system is widely used as a communication channel, and often iscrucial for the performance of organizations, it is important that users can trustthe content of what is being delivered to them. This can be summarized intotwo questions: “Is the information correct?”, integrity, and “Who has written thisinformation?”, authentication.

A standard called DomainKeys Identified Mail (dkim) has recently been de-veloped by the ietf to solve the problem with authentication and integrity [2].It makes a cryptographic hash of the email header and body and signs it with aprivate key, thereby making it possible to detect any unauthorized modificationsto the email. This signature is attached to the email header and then the messageis delivered to the recipient. The recipient verifies the header and the body bycomparing it with the hash value and the sender’s public key, which is stored inthe sender’s domain as a Domain Name System (dns) record.

This solution has been implemented as different software by various organiza-tions and the open source community, like for instance a mail filter called dkimmilter that can be plugged into the mail servers. The idea is to make this process

1

2 Introduction

fully automated and transparent to the end-users. dkim relies on the securityof the dns system, but there are known attacks that can create fake dns replies[7]. .se has responded to this weakness of the dns system by developing thedkim milter even further, by creating a patch to dkim milter that verifies the dnsrecord by using the functionality of DNS Security Extension (dnssec) to protectthe dkim public key. dnssec uses digital signatures to secure the dns responses,which for example including the mapping between ip addresses and domain names,from malicious manipulation by third parties.

1.2 Problem discussionBefore offering the solution with dkim and dnssec to the market, .se have toverify the functionality and compatibility of the extended dkim milter. The reasonwhy a server implementation, and not an end-user implementation, of dkim waschosen to be extended with dnssec support is because not many home routershave support for dnssec [1]. Most of the end-user implementation would thus notgain anything by the dnssec extension. The second reason is the fairly low usageof dkim. Not many big operators are using dkim and they need to be involvedbefore any end-users will have a gain of it.

1.3 PurposeThe purpose of this master’s thesis is to evaluate the solution where dnssec signsthe keys that dkim uses to validate the sender of an email.

1.4 GoalsFrom the problem discussion and the purpose of this thesis has the following goalsbeen drawn:

• A background study comparing relevant existing technologies. Examples ofrelevant technologies are spf and s/mime. spf verifies that the sender of anemail is allowed to use a specific email domain [57] and s/mime connects thecontent of an email with the author by using digital signatures [45].

• Deploy the dkim system and test it according to a list of test cases.

• Review the dkim milter according to relevant threat models, for exampleattack tree, and also look for any security risks.

• Do interoperability tests with, among others, spf and s/mime to see if theycan coexist with dkim without interrupting each other.

• Gather and present statistics about the current use of dkim.

1.5 Delimitations 3

• Prepare a demonstration and presentation that will be held at three seminarsand at the conference Internetdagarna, which occurs on 21-22 October 2008[49].

1.5 DelimitationsTo define the area of interest, some limitation to the thesis has been done.

• The focus is on dkim and it is explained in more detail than other similartechnologies. The descriptions of the other technologies are used to put dkimin a context.

• dkim as a standard is not tested, but rather an implementation of the stan-dard and its functionality.

• Only Mail Transfer Agents that support mail filters (milter) are used in thelaboratory equipment.

• dnssec as a system is not evaluated, but it is involved in the interoperabilitytesting with different set-ups.

1.6 Target audienceThe intended readers of this report are mainly the Research and Developmentteam at .se, students and teachers in computer science at Linköping University,and system administrators. Anyone not in this group may also read this reportproviding that they possess basic computer knowledge. This report is written sothat the enumerated groups above can understand the content of this report eventhough they are not familiar with the topic.

1.7 Reference literatureThe information written in this thesis is based on computer security books, com-puter networking books, documents published by the Internet Engineering TaskForce, and technical articles. Some websites are used as reference and they arefrom well-known and trusted sites.

1.8 OutlineThe background, chapter 2, and the analysis, chapter 3, provide a good intro-duction to the topic of this master’s thesis and are recommended for the readerinterested in the email functionality of the Internet. They also serve as the foun-dation of knowledge to the chapters further in the report. Chapter 4 presentshow the system is deployed and what the test results are. This is followed by athreat analysis of the patched dkim milter, chapter 5, and how interoperable it is

4 Introduction

with other similar technologies, chapter 6. The current use of dkim is presentedin chapter 7. The last chapters of the report contain the conclusions and futurework.

1.9 Typographic conventionsAll acronyms are spelled out when they are used for the first time. They can alsobe found under the chapter Abbreviations, page vii.

Chapter 2

Background

This chapter serves as the foundation of knowledge for the report. It is needed forthe basic understanding of how the different systems interconnect with each otherand what motivates the different solutions for email authentication. The journeyis started with the birth of the Internet and the administration surrounding themaintenance and future development of the Internet and is finished with how itsdifferent components work.

2.1 History of the InternetThe Internet was beginning to see its birth when Vinton Cerf and Robert Kahnstarted to interconnect the different types of computer networks in 1972 [34].In essence creating a network of networks and the term internetting was coinedafter their work. The three key protocols of the Internet, Transmission ControlProtocol (tcp), User Datagram Protocol (udp), and Internet Protocol (ip), werein operation by the 1980s.

2.1.1 Internet ProtocolThe transportation of information on the Internet relies on the Internet Protocol(ip). It delivers its packets on a best-effort practice [19]. Best-effort means thatip does not provide any error checking or tracking, meaning that the packets canarrive in an erroneous state and/or arrive in another order than they were sent.Thus relying on higher level protocols to take care of these problems, like udp andtcp.

Each host on the Internet needs a unique identifier so that the ip packet can bedelivered from the source to its destination. This identifier is called the ip address.The current version of ip, ipv4, has an address space of 32 bits or roughly fourbillion different addresses [34]. However, this address space is soon depleted due tothe enormous growth of the Internet. The next version of ip, ipv6, has an addressspace of 128 bits or approximately 3.4 ∗ 1038 different addresses.

5

6 Background

2.1.2 ApplicationsIt was not difficult to keep track of the different hosts when the Internet only hada few of them connected to it, but with the rapidly expansion this soon becameimpossible. The need for practical applications and tools were needed to organizeand make the environment more user friendly. Tools like the dns system, email,and World Wide Web evolved over the time to fill this gap.

2.2 About the Internet SocietyA standard organization is needed to support the development of the Internet,because the Internet is a network of networks operated by different companies andorganizations, which can make the interoperability slightly more complicated. Thedifferent standards organizations of the Internet were gathered under one umbrellaorganization called Internet Society (isoc) in 1992 [10]. isoc’s main objective is toprovide support for the Internet standards process by acting as their legal umbrellaand administrative home.

2.2.1 Organizationisoc is in the top of the organization and directly below it is the Internet Architec-ture Board (iab) [10], see figure 2.1. iab is responsible for the overall architecturaladvice and oversight to the different branches in the isoc. The branches consistof the Internet Research Task Force (irtf) and Internet Engineering Task Force(ietf). irtf focus mainly on long term problems in the Internet like spam, crypto,and other future technologies, while ietf focus on Internet standards.

IETFIRTF

IAB

ISOC

Figure 2.1. The organization hierarchy of ISOC.

2.3 Domain name to IP address 7

2.2.2 DocumentsThe work within the isoc and mainly ietf often results in a Request for Comments(rfc) [10]. The content of a rfc is a standard, but it can sometimes representother types of documents like a requirement document, an experimental standard,a policy, a white paper, or a process document. These standards are not enforcedby any law, but they are used as de facto standards.

Before a document is published as a rfc it has to be an Internet Draft (i-d)[10]. The i-ds are a series of working documents typically intended to become rfcsin the future. Any information from an i-d should be treated as work-in-progresssince the documents are under constant reviewing and upgrading. Each i-d isvalid for six months and will be removed if not replaced by a newer version of it.

The rfcs and the i-ds can be found at: www.rfc-editor.org

2.3 Domain name to IP addressAn ip address can be represented as a domain name, like www.google.com, withthe help of the Domain Name System (dns). This is useful for an ordinary userbecause the domain name is more mnemonic than the ip address. The mainobjective for the dns system is to translate the domain name into an ip address,but it can also do load balancing, host aliasing, mail server aliasing, and more[34]. The mail server aliasing is useful when a host want to know the address tothe mail server of that specific domain. If a domain name is very long, it can beshortened by using the host aliasing.

2.3.1 ArchitectureThe domain names are created in a hierarchical fashion according to a specificscheme. The domain name in example 2.1 can be divided into three parts [55]:

• Top-level domain (tld) - seThe tld is typically a country-code tld like .se (Sweden), .uk (United King-dom), and .us (United States). There are also non country-code tlds like.com (commercial), .edu (education), .org (organization), and .arpa (Addressand Routing Parameter Area).

• Second-level domain - tset.seNext to the tld is the second-level domain. It is usually the name of thecompany, product, service, or a name suitable for that particular domain.

• Third-level domain - exempel1.tset.seThe hierarchy can extend to even lower level domains. It can be usedto indicate the type of service provided by this domain name. Examplewww.gmail.com for the web server and smtp.gmail.com for the mail server.

8 Background

Example 2.1: Domain name

exempel1.tset.se

The dns system is a distributed and hierarchical database, designed to cope withthe large scale of use. There are three types of dns servers.

• Root dns servers

There are 13 root dns servers in the Internet and they are the entry point tothe dns system [6]. Each server is actually replicated into a cluster of serversand their job is to give the address to the correct tld server in question.

• tld servers

The tld servers are responsible for each of their own top-level domain. Theygive direction to the correct authoritative dns server.

• Authoritative dns servers

Each organization that have a publicly accessible host on the Internet canprovide dns records that map their domain name to their ip address [34].Most of the larger companies and organizations have their own dns servers,but it is possible to have a service provider that hosts the dns records.

The host connect to their default dns resolver, usually provided by the InternetService Provider (isp), when doing a lookup of a domain name. See figure 2.2.The resolver starts by asking the root server where it can find the specific top-leveldomain. A new question is directed to that top-level domain of where it can findthe specific second-level domain. The final question is asked to the authoritativeserver of what ip address the host in question has.

It is not necessary that it works like this in the real world. Commonly useddomain names are cashed for a limited time in the resolvers [34]. The address ofthe top-level domain could for example be cashed and then the resolver does notneed to go via the root server.

The information in a dns is stored in Resource Records (rrs), see example 2.2.A rr can for example hold the translation from a domain name to an ip address(a record) or where the mail server is located (mx record).

Example 2.2: Resource Records

exempel1.tset.se. IN A 88.131.68.181exempel1.tset.se. IN MX mta.exempel1.tset.se.

2.3 Domain name to IP address 9

Root

.se

tset.se

dns.ex.com

user.ex.com

1

2

3

4

5

678

Figure 2.2. A typical lookup of a domain name.

2.3.2 DNS security risksThe dns system is a service that has been around for many years and vulnerabilitiesare inevitably found in the system and its protocols. There are several know classesof threats to the dns system [7]. More detailed information can be found in ThreatAnalysis of the Domain Name System (dns), RFC3833.

• Packet InterceptionIs a form of man-in-the-middle attack where a third party intercepts thecommunication between the resolver and the name server. Unencryptedudp traffic makes this easy and an attacker can change the response to whatever it wants.

• id Guessing and Query PredictionThe communication mostly uses udp/ip and for an attacker is it fairly easyto generate a spoofed answer without looking at the communication betweenthe resolver and the name server. The thing that makes the traffic unique isthe id field in the dns header and what port the answer should go to. Thereare techniques, for example phase space analysis [51], that can predict theserandom values with high percentage.

• Name ChainingIs a subset of an attack that is called Cache Poisoning. Possible with theaid of the previous attacks. There are several combinations of this attack,

10 Background

but they all involve dns records that do not contain an ip address but aregular domain name. If these types of records are returned to the resolver,an attacker could inject false information about that domain name.

• Betrayal By Trusted ServerThe users trust its resolver to deliver the correct information, but this canbe breached if the resolver decides to give faulty information.

• Denial of ServiceThe dns system is vulnerable to a type of attack called Denial of Service(dos), as with any networking service. The idea is to flood the server withtraffic and exhaust its resources, making it crash or unable to provide itsservices. The dns system could also be used as an amplifier for this kind ofattack, because the response packets are larger than the query packet. Thisis done by having the source address of the queering host spoofed so thatthe dns server thinks the query is from the target of attack.

2.3.3 Domain Name System Security ExtensionsThe dns system is vulnerable to protocol attacks as mentioned in the previoussection. This problem was addressed at an ietf meeting in November 1993 wherethe first organized work started on the Domain Name System Security Extentions(dnssec) [7]. The resolver can, by the help of public-key cryptology and digitalsignatures, detect any modifications by third parties on the information from thedns system [20]. The dnssec is although vulnerable to the dos attacks.

With the dnssec each of the rrs (see example 2.2) are signed with the server’sprivate key and the public key is published in the dnskey record. The resolverthen simple validates the answer with a local copy of the public key. It is notpractical to have a copy of the public keys from all of the dnssec enables zones,but there is a rr called Delegation Signer (ds) which gives a trusted pointer fromthe parent to the child zone. The resolvers then only need one key from eachisland-of-trust if this technique is used, because within these zone are there securepointers to the other public keys. The idea is to have the dns system signed allthe way up to the root zone, but to date only a few tlds like .se, .bg and .br aresigned.

2.4 The email system and its protocolsThe need for electronic communication between human beings started to grow withthe use of mainframes and expansion of the computer networks. The computerscientists and engineers needed a way to easily communicate and coordinate theirwork with each other. A response to this was the birth of electronic mail (email)[28]. In the beginning email could only be delivered locally on the computer sincenot many of the computers, in the 1960s, were connected with each other. But theincreased usage of computer networks made the email system evolve into a crucialtool that provides an easy way of communication between users around the world.

2.4 The email system and its protocols 11

2.4.1 Internet Message FormatThe email system is divided into two parts; the message itself [46] and the deliveryof the message [32]. The format of a message is quite similar to the real worldexample of a letter and its envelope. When sending a real letter, the message isput in an envelope that has the recipient’s address and the sender’s return address.This is the information needed for the post office to be able to deliver the messagefrom point a to point b. The difference with the email message is that it consistsof headers and a body, where the headers holds information about the messageand the body contains the actual content. The equivalent to an envelope is createdby the delivery system.

The Internet Message Format, RFC2822, specifies how the email message mustbe formatted [46]. The email message consists of 7-bit ascii characters and thebody can also include a structured message according to the Multipurpose InternetMail Extensions (mime) standard.

The first five lines, in example 2.3, is the header. The message body are thelines after the header. Each header field is a line that consists of a field name,followed by a colon and a field body. The header fields represent different messageproperties and these are a selection of them [46]:

• Date: The date and time at which the message were sent to the recipient.

• From: The address(es) from which the message originates.

• Reply-To: The address(es) where any replies should be sent.

• To: The address(es) where the message should be delivered

• Subject: A text field which indicate the topic of the message.

• Cc: The address(es) that should receive a carbon copy of the message.

• Message-ID: A unique identifier for the current message. Used to distin-guish messages from each other.

Example 2.3: RFC2822 formated emailDate: Mon, 23 Jun 2008 11:50:27 +0200From: [email protected]: [email protected]: [email protected]: Meeting

Hi again!

The meeting is cancelled due to sickness.

Yours trulyAlice

12 Background

2.4.2 Multipurpose Internet Mail ExtensionsOnly 7-bit ascii characters are allowed in the email message body [46]. Thislimits for example the language in use since many languages needs more than 7-bit to represent all their possible characters. This problem is addressed with theMultipurpose Internet Mail Extensions (mime) [28]. mime gives the possibility toencode arbitrary data in plain 7-bit ascii and allow multipart messages with thepossibility to attach text, video, audio and other attachment to the message.

2.4.3 Simple Mail Transfer ProtocolThe second part of the email system is the transportation system. It is definedby the Simple Mail Transfer Protocol (smtp) and its purpose is to transfer emailto the correct destinations [32]. It is a simple text-based protocol which can onlysend messages from one host to another host, push, and not receive message fromanother host on demand, pull. To be able to retrieve a message from a server, amail client needs to use protocols like pop or imap.

The way a smtp host determines the destination of an email is by looking atthe email header [32]. The To: header of the email specifies the recipient and itsdomain. The ip address of the receiving smtp server is determined by doing a dnslookup of the recipient’s domain and the dns mx record of that domain. Thuscreating a layer around the email similar to a real envelope.

2.4.4 Post Office ProtocolIt is not often practical to deliver the email directly to the user since they mightnot be online or would like to access the mail box on different workstations. Themail is then stored on a server. There are several ways of accessing the mail boxand the Post Office Protocol version 3 (pop) is one of them. The user connectsand login to the server with the pop and retrieves the messages stored in the mailbox [42]. Once an email is retrieved from the server it is permanently removedfrom the mail box and is only available on that workstation.

2.4.5 Internet Message Access ProtocolAnother method of accessing the mail box is with Internet Message Access Protocolversion 4 (imap) [13]. The difference between imap and POP is that imap doesnot remove the email from the mail box unless explicitly told so by the user. Onlya copy of the message is sent to the user and thus making the server as the primarystorage space of all the emails.

2.4.6 ArchitectureThe email system is built upon different servers and programs that interact witheach other, see figure 2.3. The user uses a Mail User Agent (mua) to send andreceive messages [24]. The mua is program accessible by the user. It could forexample be an email client like Microsoft Outlook or a web based interface like

2.4 The email system and its protocols 13

GMail.com. When the user wants to send a message, the mua forwards it to aMail Submission Agent (msa). The msa then connects to a Mail Transfer Agent(mta) and delivers the message to it. The message is then forwarded to the correctmta and is stored in a Mail Delivery Agent (mda) until the receiver wants to readit.

InternetMTA MTA/MDA

MUA/MSA MUA

Figure 2.3. The delivery of an email through the email system.

2.4.7 SecurityIt is not good to have an open mail server where anyone can send an email throughit, because this will allow spammers to send spam with the mail server as theoriginating server [8]. One solution is to only forward mail that has its origin withinthe internal network, but this leaves the server fairly open for abuse. Anothersolution would to only let authenticated users to send email through the mailserver. This can be done with the smtp-Service Extension for Authentication(smtp-auth) [53] and the Simple Authentication and Security Layer (sasl) [39].The user can be authenticated by different mechanisms like Kerberos and plain-text logon.

An issue with the logon process to a server is how the password is treated. Thepasswords for pop, imap, and smtp-auth are usually sent in plain text [27]. Anattacker could capture these passwords and replay them in his own session withthe server. The protection is to encrypt the connection by using the TransportLayer Security (tls) protocol [15].

2.4.8 SpoofingThe problem with the smtp standard is that it does not validate or authenticatethe content of an email message when a message is received [8]. Normally does

14 Background

the recipient and the sender addresses in the smtp header and the email headermatch each other. The recipient header in the smtp is needed to have the emaildelivered to the correct destination, but the email header can be spoofed by thesender without disturbing a simple email transaction. This makes it possible tocraft an email that can make the recipient into believing that it is from someoneelse than the originating sender.

Chapter 3

Analysis of email security

There are several ways to fight spam and forged emails but the focus of thismaster’s thesis is on automated filters and add-ons to the email system. Thetechnologies within this area handle and solve different parts of the problems.

3.1 Email spoofingIt is, as stated in the previous chapter, fairly easy to create an email that lookslike it is from a source other than the originating one. A financial and personalintegrity problem is the phishing attacks related to email spoofing [35]. Spammerscan create a faked message telling the recipient to reveal personal informationlike credit card numbers, user names, and passwords. This is done by spoofingthe origin of the email so that it looks like it is coming from the targeted site orcompany. The message often has some kind of bate telling the user that is musttake some urgent actions or else something bad will happen. This pressure on theusers will make them more likely to follow the instructions in the message.

A user must take some things in consideration when reviewing an email. Thefirst task is to identify the author of the email and figure out if that is the correctidentity. The second task is to validate the information in the message, to see ifthe text is written by the author and that nothing is missing from the originalmessage. This can be done in two ways; either by doing some logical thinking orwith the aid of extensions to the email system.

3.2 Computer securityBefore the different extensions to the email system can be discussed, some defini-tions of computer security must first be explained. According to Dieter Gollmann[21] can computer security be defined as:

“The prevention and detection of unauthorized actions by users of acomputer system.”

15

16 Analysis of email security

Or as:

“The measures we can take to deal with intentional actions by partiesbehaving in some unwelcome fashion.”

One of the core principals of computer security is the cia criteria [21]. cia is anabbreviation for confidentiality, integrity, and availability. There are also someother important keywords like authentication, non-repudiation, authorization, andaccountability.

• ConfidentialityConfidentiality is the act of only revealing the information to authorizedentities. This can be achieved by restricted access and/or encryption of theinformation.

• IntegrityIntegrity is about making sure that the information is only modified byauthorized entities. This often involves means of detecting any modificationsby non-authorized entities.

• AvailabilityAvailability is achieved when the information is accessible and usable whenit is needed by an authorized entity.

• AuthenticationAuthentication is when an entity proves that it is who it says it is. Theentity can do this by presenting something that only it have, knows, or arelike driver license, password, or fingerprint.

• Non-repudiationNon-repudiation can be provided when there is unforgeable evidence thatan action must have been performed by a specific entity. A typical use ofnon-repudiation is to prove the integrity and origin of specific informationand is often performed with the aid of digital certificates.

• AuthorizationThe act of giving privilege access to resources and information to those whoare permitted to use them.

• AccountabilityAn entity can be accountable for its actions if it is proper identified andauthenticated. By keeping audit trails for each event, any actions can betraced and associated with the correct entity. The presence of accountabilityis often used as deterrence for any perpetrators, since they do not want tobe accountable for their actions.

3.2 Computer security 17

3.2.1 CryptologyCryptology is needed to be able to have confidentiality and integrity over a publiccommunication channel. Confidentiality can be achieved by doing encryption ofthe information and there are two methods of encryption: symmetric-key cryptol-ogy and public-key cryptology.

In symmetric-key cryptology, a single key is used for both encryption anddecryption [54]. Thus must both the sender and the recipient have the secret key.The encryption and decryption of information can be performed very fast with thistype of algorithms. Digital Encryption Standard (des) and Advanced EncryptionStandard (aes) are some examples of symmetric algorithms.

Public-key cryptology gives the possibility to secure communication betweentwo parties without a shared key [54]. Each party has its own set of private andpublic key. When transmitting information, it is encrypted with the recipient’spublic key and the only way to decrypt it is with the private key that is only knownto the recipient. The down side with this type of algorithms is that it takes muchcomputing resources to do the encryption and the decryption. rsa and Elgamalare some examples of asymmetric algorithms.

3.2.2 Cryptographic hash functionsCryptographic hash functions are needed as part of the integrity check when usingsecure communication. Hash functions are used to calculate a message digest of amessage. The calculated hash value is then sent together with the message. Therecipient does a new message digest and compares it with the one delivered withthe message. The message is intact if they match up.

There are some requirements for a cryptographic hash function. It should beable to take any length of message and produce a fixed length of output [54]. Itshould be a one-way function and collision resistant, meaning that it should not bepossible to know what the original message looks like by just looking at the hashvalue and that it should be impossible to find two messages that gives the samehash value. Message Digest algorithm 5 (md5), Secure Hash Algorithm (sha), andrace Integrity Primitives Evaluation Message Digest (ripemd) are examples ofcryptographic algorithms.

3.2.3 Digital signaturesCryptographic hash functions does not solve the integrity check entirely, sinceanyone, with the knowledge of what hash function is in use, could modify themessage and replace the hash value with a new one [54]. This can be prevented byusing public-key cryptology and encrypting the calculated hash value. The hashvalue is encrypted with the sender’s private key and the recipient decrypts it withthe sender’s public key and compares it with the calculated hash of the message.Only the sender could have signed the hash value, since it is the only one whoknows the private key. Anyone trying to modify the message can not produce anew digital signature and thus making that message invalid.


3.3 Email technologiesThere are different types of technologies related to the email system that will miti-gate parts of the email spoofing problem. They can be divided into two categories:sender authentication protocols and content authentication protocols.

The goal with sender authentication protocols is to protect the sending identityin various ways [44]. The sending identity of an email is placed in both the envelopeand in the header of an email. The envelope is a part of the smtp transmissionand the header is a part of the actual message.

Content authentication protocols is about protecting the author rather thanthe sender of an email [44]. The authentication is done with the help of contentsigning using public-key cryptology.

The following first four technologies works with sender authentication and therest with content authentication.

3.3.1 Sender Policy FrameworkSender Policy Framework (spf) authenticates the helo and mail from com-mands in the smtp communication between servers (the email envelope) [57]. Thehelo command is used to announce who the connecting server is and the mailfrom command is used to declare which email address the email is originatingfrom. By publishing the spf information in the dns, can a domain tell otherswhere email from its domain can have its origin.

When an email is going to be delivered to the mail server a tcp connectionmust be established. The actual ip address of the sending server can then befound from the tcp connection. By doing a dns lookup of the spf record of theemail domain, given by the mail from command, can the server determine if thesending server is allowed to send email with that domain name [57]. See figure 3.1.

3.3.2 Author Domain Signing PracticesAuthor Domain Signing Practises (adsp) have a similar agenda to spf but withthe difference that it is an aid to determining if a domain signs all their emailwith DomainKeys Identified Mail (dkim) or not [17]. This will help the receivingpart to know if an unsigned message can come from that particular domain andthus knowing if it is spoofed since only the owner of the private key can producea correctly signed message. A domain can publish, in the dns, the recommendedactions to be taken by the receiving server when an unsigned message is received,like if the email should be discarded. This system is currently only in the draftstage, but is expected to become a standard.

3.3.3 SenderIDsenderid is a protocol derived from spf that aims at authenticating the mail fromand one of the addresses in the email header [38]. Which header to use in theauthentication is decided by the Purported Responsible Address (pra) algorithm[37]. The domain publishes its sending policy in a similar fashion to spf.

3.3 Email technologies 19

host.bogus.com

dns.domain.com mta.domain.com

mail.network.com

MAIL FROM: domain.com

domain.com. IN TXT “v=spf1 mx -all”domain.com. IN MX mtamta IN A 1.2.3.4

Figure 3.1. Receiver validating the origin of the email with SPF.

3.3.4 Black-/grey-/whitelisting

The receiving mail server can have policies on how it treats different individualdomains and email addresses. The information in the smtp and the email headersis validated against different lists. There are three types of listings: White-, black-, and greylisting. Addresses on the whitelist are automatically accepted to bedelivered through the server, whilst the blacklist disallows the delivery. Greylistingis a combination of white- and blacklisting, where the delivery is delayed for a shorttime. There are different ways of implementing the graylisting, but the main goalis to temporarily reject the first delivery from an unknown hosts and accepting theemail when the host tries resending the email [25]. Most legit mail servers will tryto deliver the email until it is accepted, but most spammers do not try a secondtime and thus having less spam coming through the server.

3.3.5 Secure MIME

Secure mime (s/mime) is an extension to the mime standard and provides securetransfer of mime data [45]. It can give content integrity, authentication, and non-repudiation with the help of digital signatures. Data confidentiality is obtainedwhen encryption is activated. s/mime is an end-to-end solution working on themuas. The public keys are distributed with digital certificates attached to theemail message. These digital certificates are called x.509 and are a part of thepublic-key infrastructure used for secure transmissions on the Internet.


3.3.6 Pretty Good PrivacyPretty Good Privacy (pgp) is a family of software developed in 1991 by PhilipZimmerman [11]. This implementation is standardized under the name openpgp.It works in a similar way as s/mime, with exception to the key management. Thepublic keys are distributed with the so called web-of-trust or trusted key servers.The web-of-trust can be summarized as: A key can be trusted if it is trusted bysomeone the user already trusts.

3.3.7 DomainKeys Identified MailDomainKeys Identified Mail (dkim) secures the email body and parts of the emailheader [2]. It provides authentication and integrity with digital signatures anddoes not encrypt the content. The public key is published in the sending domain’sdns record and the private key is used to sign the email. The recipient of a signedmessage verifies the signature by comparing it with the hash value, of the headersand the body, and the sender’s public key.

3.3.8 DomainKeysDomainKeys is the predecessor to dkim and was created by Yahoo [14]. It is ahistorical and obsoleted standard, but it is still in use by various entities on theInternet [2].

3.4 More about DKIMThe following part will explain dkim more in detail. It is selected because of itsgood properties with sender and content authentication which includes verificationof some headers and the content of the email [2]. The system is also transparentto end-users compared to s/mime and pgp which manipulates the content of anemail [24]. This is because the signature is part of the email header and not inthe email body. This also results in a smoother transition since not everyoneneeds to activate dkim at the same time because of the transparency. The keysused for signing and verification are mainly connected to the domain rather thanthe user, thus preserving the user’s integrity. By using the dns system for thepublication of the public keys, no new public-key infrastructure is needed to bemaintained. If a signature in an email can not be verified due to inconsistencies,then the email should not be treated differently than an email without a signature.But if this would be combined with adsp, then the author’s domain could give arecommendation on how to treat an email with broken signature.

3.4.1 CanocalizationEvery email delivered through the Internet is modified in some more or less intru-sive way. For example can headers be added or modified, lines be wrapped, andwhitespaces be removed [2]. The email must go through a preprocessing method

3.4 More about DKIM 21

to eliminate some of these factors from breaking the signing and the verificationprocess of an email. This process is called canocalization and has two modes ofoperation: simple and relaxed. A combination of these modes is applied to boththe header and the body and is selected by the signing party. Canocalizationonly prepares the email for the signing and the verifying algorithms and does notmodify the transmitted data.

• Simple header canocalization does not allow any modification duringtransit to the headers used when the message was signed [2]. The signatureof the email will become invalid if any of the signed headers are modified.

• Relaxed header canocalization converts all header names to lower case,unfolds all header fields, merges a sequence of whitespace character into onewhitespace character, removes all whitespace after the end of each headervalue, and removes any whitespace before and after the colon between theheader name and value [2].

• Simple body canocalization only removes any empty lines at the end ofthe body [2].

• Relaxed body canocalization removes all whitespace at the end of lines,reduces sequences of whitespace characters into one whitespace character,and removes all empty lines at the end of the message body [2].

3.4.2 SigningSigning is done at the mua, the msa, or the mta and only when it has the knowl-edge of the private key to the corresponding domain or user and if the entity wantsto take responsibility for that message [2]. The signer must decide which headersto sign. The From: header is the only one required and the rest is up to the signer.It is although recommended not to sign headers that are likely to be modified orremoved during transit. The signer may also sign nonexistent headers to provethe denial of existence. If there are several instances of one type of header, thenthe header closest to the body is used first.

The signer calculates two hashes, one over the message body and one over theselected header fields including the body hash, using either the sha1 or the sha256hash algorithm [2]. The header hash is then signed using the rsa algorithm and aprivate key. All the configuration parameters and signature is then placed in theDKIM-Signature: header field.

Example 3.1 shows a typical dkim signature. This specific signature indicateswhich version of dkim is in use, currently only version one exists. The a= and c=indicates which hash algorithm and canocalization algorithms are in use. Then itshows which domain who signed this message, d= and the corresponding publickey, the selector, s=. The time the message was signed and the body hash isindicated by the t= and bh=. Finally are the signed headers enumerated andplaced in the h= and the signed header hash is placed in b=.


Example 3.1: A DKIM-Signature: headerDKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;

d=exempel1.tset.se; s=ex1; t=1216375318;bh=F49+TW8nMriWgjHxXsVGiPa+xLNWevC3bGAT+Zl8Qag=;h=Reply-To:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=AsmD11IU0TwqQwK9fGWIlV7TPtBRgEzcFwuhgbvaoipwcI9hA8M1TzE025rPzbLlJbEJKz8T2WSfmg7BbmSQ4rklSaq5ou1BrwxGTQWn/I37sOPhzg+pRfAjq7IWo6ZysOOgDkbCcOjL46kECDFQBWSvgKD3oOID4FOj5huSdzw=

3.4.3 DNS recordThe public key is stored in the dns related to the signing entity. The following isa typical example of a dns record for the public key [2].

Example 3.2: A DKIM DNS text recordex1._domainkey.exempel1.tset.se. IN TXT "v=DKIM1; k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC6oekzH849jUK1EYJnfUM72OlhpaTxqBhvNu3UTGsbRywFWBHCPfoeHAZKnYhN+pLAXuJ49oUNO1kybAqUfxPMOpTbupY0zVdaJCtcMHi7j7rFgSrRi8nH55Frhq4aiS00ocdw1po0p72c7TkTNm5E1Q2jZ4pGpjEXJtjzb9YckwIDAQAB"

All dkim information is stored under the _domainkey.“domain” and a uniqueselector is used for each public key [2]. The selector is ex1 in this example. Thereason to have multiple selectors for a single domain is to have easier key manage-ment, for example different keys each month, keys for different branches withinthe company or one for each user.

Key revocation is simply done by removing the key from the p variable in thedns record, thus invalidating any message signed by that key pair [2].

3.4.4 VerificationVerification is performed at the mta, the mda, or the mua and it is recommendedthat the validation is performed closest to the recipient to prevent any maliciousaction by a third party [2]. The verifier starts by validating the dkim-Signature:header field to find the configuration parameters and any inconsistencies. Thesignature contains the information of how to reconstruct the signature as the signerdid it. The signing process is reconstructed and compared with the values storedin the signature header. If everything matches, then the message is authenticated.This can by indicated by adding a header, like Authentication-Results:, to the emailso that processes later in the chain can take appropriate actions. See example 3.3.

3.4 More about DKIM 23

It is recommended that the verification is performed when the message arrives,but it can be done later as long as the sender does not remove the associated dnsrecord [2].

Example 3.3: DKIM verification resultsAuthentication-Results: exempel2.tset.se; dkim=pass

(1024-bit key) [email protected];dkim-asp=none

3.4.5 The need for DNSSECOne big weakness with the dkim system is how trustworthy the dkim public keysare. The dkim system depends on the reliability of the dns system to deliverthe correct dkim public key, but there are vulnerabilities to the dns system thatwill aid attackers doing malicious distribution of dkim public keys. Some of theseattacks, as discussed in chapter 2, can be detected by introducing dnssec [7].The sending domain must sign its rrs by using dnssec and the dkim validatorcan then verify the origin of the dkim public key and thus knowing that it is notspoofed by a malicious entity.

Chapter 4

Deployment and testing ofDKIM

The dkim milter with patched dnssec capabilities is tested by deploying it in alab environment that simulates the fundamental properties of the real world emailsystem. Test servers are installed and configured to interact with each other.The basic functionality is evaluated against different test cases and the results arepresented at the end of this chapter.

4.1 Server set-upThe first part is to have the different servers installed and configured before anytesting can be done. The following section shows how the testing environmentlooks like.

4.1.1 The lab environmentThe verification and testing are done with different mail servers, both locally onsite and public servers on the Internet. The local mail servers are a collection ofthe mail servers that support dkim milter. There is a server available for testingpurposes at .se that run the operating system Ubuntu.

A dnssec system for test purposes is already running and no specific configu-ration is needed, except adding records to the dns.

25

26 Deployment and testing of DKIM

4.1.2 Supported mail serversSince the project concerns the dkim milter, only mtas that support the milter apican be used in the test cases [56].

• Sendmail 8.12.0 and laterOpen sourcewww.sendmail.org

• Postfix 2.4 and laterOpen sourcewww.postfix.org

• Postoffice SMTP server 1.3 and laterOpen sourcewww.tsfr.org/~orc/Code/postoffice/

Only Sendmail and Postfix are used in the test suite due to their popularity.

4.1.3 Installation of necessary softwareThe basic idea for the test environment is to have two mail servers that can sendand receive email. Each mail server has its own domain name, so that they actindependently of each other. The first mail server runs Postfix and the second oneruns Sendmail. To each mail server there are different mail filters and securitysoftware connected to it.

A single dns server hosts the dns records for both of the domains. Thesedomains are subdomains of a dnssec enabled domain called tset.se. Figure 4.1illustrates the test configuration.

Each step of the installation and the configuration parameters are documentedin appendix A.

IP aliasing

There is only one computer available for testing purposes in the lab environmentand all test servers must be running on this computer. The problem is thatboth Postfix and Sendmail need exclusive rights to certain ports on the NetworkInterface Card (nic). There is therefore a need of multiple ip addresses to be ableto provide the mtas with their own set of ports. This can be solved by havingmultiple nics installed in the computer or by using a technique called ip aliasing.ip aliasing gives the computer access to multiple ip addresses by letting one nichost them. The difference between these two solutions is a performance issueregarding how the traffic are flowing to the computer through the network, butthis has no importance for the test cases since they are not performing any stresstesting.

4.1 Server set-up 27

SASL SMTP

TLS

Postfix exempel1.tset.se

Sendmail exempel2.tset.se

DNS

DKIM Milter DKIM Milter

Procmail

Microsoft Outlook Microsoft

Outlook

SMTP SMTP

User 1 User 2

IMAP

TLS

Password file

Figure 4.1. The test configuration. User 1 sends an email to User 2.


DNS

When the ip addresses of the machine are configured it is time to publish theirexistence by using the dns system. This is done by having a dns server installedon the machine, which will answer for any queries about these domains. Bind 9 isthe dns server of choice because of the default configuration of the lab equipment.dnssec is enabled and the domains are connected to the trusted zone of .se by adelegation from the domain tset.se. Two domains are in use, exempel1.tset.se andexempel2.tset.se and each of them represent one of the mail servers.

Mail servers

There are two mail servers that will serve as a the base of the test suite. Sendmailand Postfix are selected because of their widespread use and reliability. Postof-fice is neglected because it is mainly intended for use in the NetBSD operatingsystem. Further more, there should not be any big differences between these sys-tems regarding dkim milter since they all communicate with it through the Milterinterface.

DKIM Milter

dkim milter is an implementation of the dkim standard. It attaches it self to themail servers by using the Milter api and thus getting access to the informationabout the emails in transit through the mail server. dkim milter can with thisinformation decide if it should sign the particular email and validate the signatureof incoming emails. The results are put in the header of the email and any entitylater in the chain can take specific action with this result in mind. The dkimmilter is extended with a patch from .se that will make it to evaluate the dnsqueries with the aid of dnssec.

IMAP

An interface to the mail servers are needed to be able to retrieve the deliveredemails. Dovecot is an implementation of imap and is used in the test suite to beable to read message from an external computer. There are other implementationsof imap, but the selection of implementation should not influence the test resultssince it is just an method of retrieving email from the mail server.

SASL

The mail servers are configured so that only authorized users can send email outfrom them and with Cyrus sasl can an external user authenticate it self to the mailservers and thus be able to send email to other domains. The smtp-auth func-tionality is thus enabled. The discussion concerning the choice of implementationis similar to the one for imap.

4.2 Testing of DKIM Milter 29

Key generation

To be able to secure the system, there is a need of asymmetric keys. The keys areneeded to the dkim signature and when signing the dns zones.

The first key generated for each zone is the Zone Signing Key (zsk) and is usedfor signing the rrs within the zone [33]. The second key is the Key Signing Key(ksk) and it is used for signing the zsk when it is published as a dnskey record.The reason to have two sets of keys is for easier key management when changingkeys. The ksk is used as a secure entry point to the zone and if a new key is usedfor signing the zone, no one needs to be informed of this because they already havea copy of the ksk and thus a secure path to the zone. It is recommended that thekey length is longer for the ksk than the zsk since it should be more secure. It iscurrent recommended to use either rsasha1 or dsa as a key algorithm.

dkim on the otherhand uses the rsa algoritm and those keys are used forsigning and validating the dkim signature. [2]

Certificates

Digital certificates are needed to create the secure channels between the user andthe mail server. The certificate shows the identity of the public key owner andthus the ability to validate the origin of the connection. They are usually obtainedfrom an Certificate Authority (ca) like VeriSign.com or Thawte.com and is thebase for this type of public-key infrastructure. The other possibility it to generatea self-signed certificate locally on the server, but then no one can really trust thecontent of the certificate since they do not have a trusted relationship to the serverlike with the cas. These types of self-signed certificates are used in the test suite,since the certificates from the cas are a service you have to pay for and that thesecure channel between the user and the mail server is not a top priority for thetest suite.

4.2 Testing of DKIM MilterThere are two types of tests that are performed, function testing and domaintesting. The first one verifies the functionality and the second one tries to find anyunexpected events. The tests focus on the new inputs to the dkim milter that arecreated because of the patch.

4.2.1 Function testingThese types of tests are suitable for the first set of tests, because they are aimedat the smallest building block visible to the outside of a program [30]. The idea isto focus on one variable or function and see how they react to middle-of-the-roadvalues as input data. That is, values that are expected to pass the test. It is easyto evaluate the outcome of the tests because the complexity of the procedures isfairly low. The result is often predictable and the program will not fail these setsof tests, but it will fail if there is something fundamentally wrong in the program.


The functionality of the program can be verified by doing these tests and if thetests fail, the problems can be fixed before the more complex test scenarios arestarted.

4.2.2 Domain testingThe domain testing takes the function testing one step further by testing a widerange of input values to a given function or variable [30]. A problem with thisis that the combinations of possible input values often are enormous and wouldtake very long time to go through all these tests. What the domain testing doesis that it reduces this massive set into subdomains. A subdomain is a set of inputdata that are similar in property and will give similar outcome of the function.Then at least one representative value is selected from each subdomain, often theboundary or the extreme values.

4.2.3 Variables to testThe first basic tests focus on the new inputs to the dkim milter and how they affectthe system. The reason of doing this is because different inputs will make thesystem behave in different ways. The patch introduces the dnssec functionalityto the system and two components are needed to have this functionality functionproperly. The first is that the dns response from the email author’s domain isneeded to be dnssec enabled. The second component is the trust anchor neededto be able to trust the origin of the dns response.

There are three types of dns rrs that are of interest for this test [5]:

• dnskey

Holds the public key of the dns server. The variables consist of flags, protocolnumber, algorithm type, and the public key.

• rrsig

Holds the signature of a rr. The variables consist of type covered, algorithm,labels, original Time to Live (ttl), signature expiration, signature inception,key tag, signer’s name, and the signature.

• ds

Holds a secure pointer to the dnssec enabled child domain. The variablesconsist of key tag, algorithm, digest type and digest.

Each of these rrs is defined in the RFC4034. It describes how and what valuesshould be used and what actions are expected to be taken by the recipient. Readthe rfc for a more detailed explanation of the different rrs.

The second component to test is the trust anchor file and it is formatted justlike the dnskey rr. It acts as a local copy of the public key to the trusted zone.


4.2.4 Test casesThe test cases are made according to model recently discussed. The first part isto verify that functionality, table 4.1, and the second part tries to interrupt thesystem by using boundary values, table 4.2. The tests are performed by sendingan email from one email server to the other. Each direction is tested.


Table 4.1: Function test cases.

1 Function testingAll variables in the trust anchor and in the dns response are cor-rect. The different valid combinations of the variables are testedand it is expected that dkim milter should pass all the tests.

1.1 dkim milter without dnssecThe original functionality of dkim milter with signing and veri-fying is tested without having the dnssec functionality activatedon the email author’s domain.

1.1.1 AlgorithmThere are two sets of algorithms that can be tested.

1.1.1.1 rsa-sha-11.1.1.2 rsa-sha-256

1.2 dkim milter with dnssecdnssec is enabled on the email author’s domain. Then each ofthe possible combinations of algorithms, flags, and delegation aretested.

1.2.1 rsa dnskey and rsa rrsig.1.2.1.1 Trust anchor directly to the server, flag 256.1.2.1.2 Trust anchor directly to the server, flag 257.

1.2.2 dsa dnskey and dsa rrig.1.2.2.1 Trust anchor directly to the server, flag 256.1.2.2.2 Trust anchor directly to the server, flag 257.

1.2.3 rsa dnskey and rsa rrsig. rsa ds and sha-1 Digest.1.2.3.1 Trust anchor to the parent server, flag 256.1.2.3.2 Trust anchor to the parent server, flag 257.

1.2.4 dsa dnskey and dsa rrsig. dsa ds and sha-1 Digest.1.2.4.1 Trust anchor to the parent server, flag 256.1.2.4.2 Trust anchor to the parent server, flag 257.

1.2.5 rsa dnskey and rsa rrsig. rsa ds and sha-256 Digest.1.2.5.1 Trust anchor to the parent server, flag 256.1.2.5.2 Trust anchor to the parent server, flag 257.

1.2.6 dsa dnskey and dsa rrsig. dsa ds and sha-256 Digest.1.2.6.1 Trust anchor to the parent server, flag 256.1.2.6.2 Trust anchor to the parent server, flag 257.


Table 4.2: Domain test cases.

2 Domain testingThe second part has all the different variables valid except thosespecified under each test case. The point is to see how the systemreacts to invalid boundary values and if it does something it shouldnot do when trying to get the dkim public key. These values arebased on the RFC4034. The rrsig used is this test is the oneassociated with the dkim public key record.

2.1 dnskey FlagThe flag indicates what type of key this is.

2.1.1 Value 0Boundary value. Record should be ignored.

2.1.2 Value 1Only the secure entry point flag is set and the record must not beused to validate the rrsigs.


2.2 dnskey ProtocolIndicates which protocol is in use. Only value 3 is valid.



2.3 dnskey AlgorithmIndicates which algorithm is in use.



2.4 dnskey Public keyContains the public key.

2.4.1 Invalid public keyThe public key does not correspond to the private key used tosign the records.

2.5 rrsig AlgorithmIndicates which algorithm is in use.




2.6 rrsig LabelIndicates the number of labels used in the domain name. Shouldbe less than or equal to the number of labels in owner name.

2.6.1 Value 6Larger value. Record should be ignored.

2.7 rrsig Signature ExpirationIndicates when a signature expires.

2.7.1 The date yesterday when testingThe signature is expired and should be ignored.

2.8 rrsig Signature InceptionIndicates when signature starts to be valid.

2.8.1 The date tomorrow after when testingThe signature is not valid yet. Record should be ignored.

2.9 rrsig Signer’s NameIndicates the owner name of the dnskey.

2.9.1 Not the signer’s nameDo not match with the real owner name. Record should be ig-nored.

2.10 rrsig SignatureContains the signature of a rr.

2.10.1 Invalid signatureThe signature do not match the rr. Record should be ignored.

2.11 No rrsig for dkimThere is no signature for the dkim public key record and thus itcan not be trusted. Record should be ignored.


4.2.5 Test resultsEach of the function test cases were performed in each direction by sending mailfrom the Sendmail mta to the Postfix mta and from the Postfix mta to theSendmail mta. The first domain, exempel1.tset.se, is represented by the Postfixmta and is marked with ex1 in the transcript below. The second domain, exem-pel2.tset.se, is represented by the Sendmail mta and is marked with ex2 in thetranscript below.

Table 4.3: Function test results.

# Orig. MTA Events Result1.1.1.1 Sendmail Sign (ex2). Verify pass (ex1). Pass

Postfix Sign (ex1). Verify pass (ex2). Pass1.1.1.2 Sendmail Sign (ex2). Verify pass (ex1). Pass

Postfix Sign (ex1). Verify pass (ex2). Pass

1.2.1.1 Sendmail Sign (ex2). Verify pass (ex1). PassPostfix Sign (ex1). Verify pass (ex2). Pass













The domain tests are performed in the same manner as the function tests. Themalformed inputs are created by changing the appropriate values in the dns zonefile and publish them on the Internet. Tests 2.1-2.4 are also applied to the trustanchor file, since it has the same syntax as the dnskey rr, and this is marked byeither TA or Zone.

Table 4.4: Domain test results.

# Orig. MTA Events Result2.1.1 Sendmail/TA Sign (ex2). Verify neutral (ex1). OK

Postfix/TA Sign (ex1). Verify neutral (ex2). OKSendmail/Zone Sign (ex2). Verify neutral (ex1). OKPostfix/Zone The Postfix mta can not be

started, because it can not verifyits domain name due to brokenchain of trust.

N/A

2.1.2 Sendmail/TA Sign (ex2). Verify neutral (ex1). OKPostfix/TA Sign (ex1). Verify neutral (ex2). OKSendmail/Zone Sign (ex2). Verify neutral (ex1). OKPostfix/Zone Same as in test 2.1.1. N/A

2.1.3 Sendmail/TA Sign (ex2). Verify neutral (ex1). OKPostfix/TA Sign (ex1). Verify neutral (ex2). OKSendmail/Zone The program dnssec-signzone

can not sign the zone.N/A

Postfix/Zone Same as above. N/A







2.5.1 Sendmail/Zone Sign (ex2). Verify neutral (ex1). OKPostfix/Zone Sign (ex1). Verify neutral (ex2). OK




2.7.1 Sendmail/Zone Sign (ex2). Verify neutral (ex1). OKPostfix/Zone Same as in test 2.1.1. N/A

2.8.1 Sendmail/Zone Sign (ex2). Verify neutral (ex1). OKPostfix/Zone Same as in test 2.1.1. N/A




NOTE: The dkim milter produces the result neutral because the dkim dns recordstates that the email author’s domain is using dkim in test mode. This meansthat verification failures of emails from that domain should only soft fail and nothard fail. For further reflections about the test results, read chapter 8.

Chapter 5

Threat analysis

The implementation of dkim with dnssec is evaluated by using different threatmodels. These models look at the system from different angles and should revealthe threats to the system. The actual program code is not in focus, but rather thedesign of the system with its different components.

It is important to identify the critical assets of a system when doing threatmodelling [4]. Each entry point to the assets is then mapped to be able to identifythe treats and possible point of attack. The appropriate countermeasure can thenbe deployed to mitigate, delay or detect the attacks.

5.1 ThreatsA common way of categorizing threats is by using the acronym stride [26]. Eachof these threat categories is a way of breaking the foundation of security. Thefollowing list shows the categories and each of the security properties threatenedby them [12]:

• Spoofing - authenticationThe act of masquerading as another entity by giving false information.

• Tampering - integrityUnauthorized modification of information.

• Repudiation - non-repudiationThe ability to deny an action, although it actually has been performed, andno one can prove otherwise.

• Information disclosure - confidentialityInformation is exposed the entities which should not have access to it.

• Denial of Service (dos) - availabilityMaking a service unavailable to its intended entities.

39

40 Threat analysis

• Elevation of privilege - authorizationThe act of gaining more privilege access to resources and information thanthey are authorized to.

5.2 Threat modelsThree types of threat models are used in this study, namely data-flow diagrams(dfd), attack trees, and misuse cases. They give different point of perspective bylooking at various entry points, an attacker’s goals, and disruption of normal use.These models were selected because of there focus on the software rather then theenvironment that software resides in. There are for example models that assignsthe probability of an attack and the corresponding value loss, which will tell whatlevel of protection is appropriate. These types of models must be performed onspecific usage cases and not in general terms like this study.

5.2.1 Data-flow diagramThe data-flow diagram’s aim is to illustrate the data flowing through a system fromthe inputs to the outputs [29]. This will sometimes reveal security and design flaws.The diagram will model the system with different resources connected to it andby using different colors can the trust levels be illustrated. The color black is usedfor untrusted components, light grey is for trusted and dark grey is for somewhattrusted. Passive date stores are illustrated by double horizontal lines and externalentities by rectangles. Circles illustrate the logical processes of the system and arealways trusted since they are part of the code, but the data flow is represented byarrows and the data flow can be untrusted.

Figure 5.1, 5.2, and 5.3 describes the data flowing through the dkim milter. Adecision is made in figure 5.1 about the mode of operation and thus which of thebranches that should be activated; signing or verifying mode. The figures depictsthat the email can not be trusted because it can be modified by any externalentity. The dns is somewhat trusted because of the related vulnerabilities on thatsystem. Everything else in the system is trusted and a note is that these trustedcomponents all reside on one computer.

5.2.2 Attack treesAn attacker has specific goals with its attack and they can be achieved in differentways because of the complexity of computer architecture [48]. Countermeasurescan be placed to mitigate, delay, or detect the attacks, but only if the entry pointsare know to the designer of the system. Attack trees is a tool suggested by BruceSchneier that is designed to reveal theses points.

An attack is represented in a tree structure where the root node is the maingoal [48]. Each node is a subgoal and the children of that node are different waysof achieving that subgoal. There are two types of nodes, and node and or node.A node is by default an or node, meaning that only one of its children is needed

5.2 Threat models 41

Milter API

Select mode

Configuration file

Signing

Verifying

Email

1 2

3

4

Figure 5.1. Main DFD.1. Notification of email in transit2. Email headers and content3. Configuration parameters4. Activation of the correct mode

Signing Sign email

OpenSSL

Milter API Key file

1

3

2

4

5Figure 5.2. Signing DFD.1. Start signal2. Private key3. Request hashing and signing4. Digital signature5. Insert DKIM-Signature: header

Verifying Retrieve public key

Verify email

libUnbound

DNS

OpenSSL

Trust Anchor

Milter API

1

3

4

5

2

6

78

9

10 11

12

Figure 5.3. Verifying DFD.1. Start signal2. Anchors to trusted zones3. Requesting dkim public key4. Resolving dns servers5. dns response6. Request validation of dns response7. Validation results8. Public key9. Start verifying10. Request validation of signatures11. Validation results12. Insert Authentication-Results:header

42 Threat analysis

to be possible to perform the specific task. The and node defines that a set ofits children are needed for success. The possibility to perform the task of eachleaf node can be evaluated. The result is then aggregated upwards in the treestructure. See figure 5.4. The task is either possible (p) or impossible (i). Aneconomic evaluation can also be performed in a similar way and is used to see howmuch it would cost an attacker to perform the specific attack.

Open the safe P

Get combination P

Use dynamiteI

Eavesdrop I

Bribe I

Threaten P

Figure 5.4. Simple attack tree.

Figures 5.5 to 5.7 shows different ways of attacking the dkim system. The possibleoutcome of each event is evaluated with common sense and could differ in anotherenvironment. Each attack tree is explained further more in tables 5.1 to 5.3.


Let a mail server

sign a ro

gue em

ail

P

Deliver via an

auth

orized

use

r P

Steal a

n au

thenticated

channel

I

Trick th

e m

ail serv

er to sig

n it

P

Rogue u

ser

P

Malicio

us

softw

are on

an au

thorized

com

puter

P

Eav

esdro

p o

n th

e lo

gin tra

nsactio

n I

Bad

config

ura

tion

P

Faulty m

ail serv

er I

Open

relay

P

Let a paren

t dom

ain sig

n it

I

Betray

al of

paren

t dom

ain I

Take co

ntro

l of

paren

t dom

ain I

Figure 5.5. Attack tree 1.

44 Threat analysis

Table 5.1: Attack tree 1.

1 Let a mail server sign a rogue emailA correct signature can be produced and attached to the messageif the email goes through the originating mail server for thatdomain. The mail server must go into signing mode and notverifying mode.

1.1 Deliver via an authorized userAn email will be accepted for signing if it comes from an authen-ticated user of that domain.

1.1.1 Rogue userThe email can be delivered on behalf of a rogue user belongingto that domain. The system will not prevent an authorized userto have its email signed and delivered.

1.1.2 Malicious software on an authorized computerIf malicious software got installed on the user’s computer, itcould take advantage of the user credentials stored on that com-puter and thus successfully connect to the mail server.

1.1.3 Eavesdrop on the login transactionThe username and password can be stolen if the login transactionis not properly protected.

1.1.4 Steal an authenticated channelAn user authenticates itself in the beginning of the session withthe mail server. Once the user is authenticated it will stay thatway for the lifetime of that specific session. It could be possiblefor someone to steal this session if the transaction process ispoorly designed.

1.2 Trick the mail server to sign itThe mail server will sign a specific set of email and if the rogueemail fits into this set it will be sign and delivered.

1.2.1 Bad configurationThe configuration files used by dkim milter may contain infor-mation like the ip addresses of host that should have their mailsigned.

1.2.2 Faulty mail serverA message may be signed if the mail server does not tell thetruth to the dkim milter.


1.3 Open relayThe mail server is an open relay and accepts email from anyoneand forwards it to the correct destination.

1.4 Let a parent domain sign itThe standard allows a parent domain to sign messages on behalfof its child domains. For example can an email from the domainexempel1.tset.se be signed by exempel1.tset.se, tset.se, and .se.

1.4.1 Betrayal of parent domainThe parent domain can become rogue and betray its child do-mains by sending email with the children’s domain names andsign with its own private key.

1.4.2 Take control of parent domainAn attacker could take control over the parent domain and thussend and sign email on behalf of the child domain.

46 Threat analysis

Sig

n a m

essag

e in th

e n

ame o

f an

oth

er dom

ain P

Get h

old

of th

e private

key P

Mak

e the D

NS

server o

f that

dom

ain unavailab

le P

Spoof th

e public key I

Sen

d th

e email

from

a similar

dom

ain P

Abuse o

f the

disp

lay nam

e P

DN

S in

tegrity

attack I

Den

ial of

Service

P Brea

k the R

SA

encryp

tion

I

Get th

e key fro

m th

e se

rver

P M

ake so

meo

ne

to re

veal the k

eyP

Factor R

SA

modulu

s I

Bru

te-force

search

I

Rem

ote T

imin

g Atta

cks I

Rem

ote

access P

Physical

access I

Brib

e

P

Blackm

ail P

Insid

er

P

Bad

policy

P

and




2 Sign a message in the name of another domainThe rogue host can produce its own signature, but it must haveaccess to the keys associated with that particular domain.

2.1 Get hold of the private keyWith access to the private key can a message be signed andcorrectly validated with the public key in that domain’s dnsrecord.

2.1.1 Break the rsa encryptionThe private key can be obtained with the help of the signatureand the public key.

2.1.1.1 Factor rsa modulusUsing mathematical methods to calculated the private key fromthe rsa modulus and the public key.

2.1.1.2 Brute-force searchTry all combinations of possible private keys and see if the cal-culated signature matches the received signature.

2.1.2 Get the key from the serverThe private key is revealed by the server.

2.1.2.1 Remote Timing AttacksCareful timing of the time it takes for the server to sign themessage digest. Experiments have shown that it is possible toextract the private key by using this method [9]. This is possibleif no rsa blinding is activated, which obscures the cryptographicprocess. openssl have this activated by default in versions newerthan 0.9.7b.

2.1.2.2 Remote accessUsing some kind of vulnerability on the server to get remoteaccess with administrator privileges and thus having access tothe private key.

2.1.2.3 Physical accessThe private key is extracted from the computer hardware.

2.1.3 Make someone to reveal the keyA person with proper access can reveal the secret private key tosomeone on the outside.

48 Threat analysis

2.1.3.1 BribeIt can be done by bribing an employee.

2.1.3.2 BlackmailOr by using some kind of extortion.

2.1.3.3 InsiderThe attacker can have people working on the inside.

2.2 Make the dns server of that domain unavailableIf no public key is available, there is a chance of having a mali-cious email going through depending on the email handling pol-icy. The policy could reject any non-verifiable email, but mostlikely only mark the email telling that it could not verify thecontent and pass it on to the end-user. Most users will not scru-tinize the email header and thus not knowing that the verificationfailed.

2.2.1 Denial of ServiceThe public key can become unavailable by overloading that do-main’s dns server with a huge amount of traffic or making itcrash by using some kind of vulnerability.

2.2.2 Bad policyThe email handling policy must forward the email even thoughthe DNS was unreachable.

2.3 Spoof the public keyAn email signed with a false private key can get trough if thepublic key is spoofed.

2.3.1 dns integrity attackThere are numerous ways of spoofing the dns records [47]. nlnetLabs have created and analyzed an attack tree that shows thesedifferent threats. These are however mitigated with the use ofdnssec.

2.4 Send the email from a similar domainAn end-user can be fooled into believing that the email is comingfrom a trusted source, but is actually from a rogue domain. Thisis done by having a domain name similar to the trusted source.Domain names can look similar when only giving it a quick look,like [email protected] and [email protected].


2.5 Abuse of the display nameThe From: header in the email contains the address of the emailauthor, but also contains the display name for usability purpose.See example 5.1. Some muas only show the display name andnot the email address or some user only pay attention to thedisplay name, thus making it possible to have the email look likeit is from an trusted author.

Example 5.1: Abuse of the display nameFrom: "TheBigBank Security" <[email protected]>

50 Threat analysis

Misu

se o

f email

in tra

nsit

P

Appen

d in

form

ation

to co

nte

nt

P

Add n

ew

head

ers

P

Modify u

nsig

ned

head

ers

P

Take

adva

ntag

e of th

e ca

non

icaliza

tion

alg

orith

m

P

Repla

y of o

ld m

essage

P




3 Misuse of email in transitA correctly signed message can be modified or resent withoutbreaking the signature.

3.1 Append information to contentThere is an option to the DKIM signature telling the verifier thatonly a part of the email content was signed. The body lengthcount option, l=, is meant to increase the signature robustnesswhen the sender knows that for example a mailing list will addcontent to the end of the message. This will although open upthe possibility for an attacker to attach information to the emailbody without breaking the signature.

3.2 Add new headersNew headers can be added if their existence is not denied in thesignature.

3.3 Modify unsigned headersThe value of a header can be modified if it is not signed.

3.4 Take advantage of the canonicalization algorithmThe idea with the canonicalization algorithm is to allow sometypes of modifications to the email. This will make a messagemore likely to get correctly verified since the modifications area natural way of life in the email system. An attacker couldtake advantage of this and alter the message so that it will bepresented to the end-user in another way than intended.

3.5 Replay of old messageThe dkim standard has no built-in protection against replay at-tacks where a signed message is resent to the recipient or anotherparty. But the Date: header is a natural indicator to when themessage was sent, if this field was sign by the author domain, andmost mail servers will not accept messages with a too old datefield. It is also optional to include a timestamp in the signature,which reveals when the signature was signed.

52 Threat analysis

5.2.3 Misuse casesMisuse cases maps the regular activities within the system with activities per-formed by bad actors [4]. The use scenarios are based on the data-flow model,the server set-up, and the description of the dkim system. These activities aremarked as white circles in the following figures. The bad activities are the onesdisturbing the regular activities and is marked as black circles. They are based onthe previous attack trees. Each of the bad activities are, in the optimal scenario,mitigated by some kind of defense mechanism. The misuse cases will thus revealany bad activity that are not mitigated and is thereby a security threat to thesystem.

Figure 5.8 reveals that the big security threat for email signing are rogue users.The other cases can be mitigated by the use of proper countermeasures. The mailserver will sign all emails from an authenticated user and there is not much todo if this users sends bad information to a recipient. The positive side are theaccountability when logging is activated and thus are any action performed by theuser traceable.

Other security threats are depicted, like display name abuse and email sentfrom a domain with similar name, in figure 5.9. They are explained more in detailunder the attack tree section.


Sign email

from the domain

Authenti - cate users

Encrypted transmission

Non- obsoleted protocols

Send a rogue email

Rogue user

Eavesdrop on login transmiss -

ion

Steal an authenti -

cated channel

Malicious software on authorized computer

Updated software and AV patterns

Auto accept policy

Local host /

network

Strict policy

Have a computer

on the auto accept list

Open relay

Threatens

Uses

Aggregates

Aggregates

Includes

Includes

Uses

Mitigates

Mitigates

Mitigates

Uses May include

Mitigates

Uses

Uses

Uses

Uses

Uses

Figure 5.8. Misuse of email signing.

54 Threat analysis

Spoofed email

Verify policy

Tempfail when no

DNS

DNS

DNSSEC Fake DNS

DoS Get the real

private key

Remote timing attack

Insider

Remote access to

server

RSA blinding

Trusted employees

Updated software and AV patterns

Betrayal of parent domain

Send from a similar domain

Replay of old

message

Display name abuse

Modify email in transit Includes

Uses

Uses

Uses

Uses Uses

Uses

Uses

Uses

Uses

Uses

Uses

Uses

Uses

Includes

Threatens

Threatens

Mitigates

Mitigates

Mitigates

Mitigates

Mitigates

Verify email

Figure 5.9. Misuse of email verification.

Chapter 6

Interoperability testing

This chapter is about interoperability testing and shows how well the dkim miltercan coexist with similar technologies without interfering each other. Basic manip-ulations and email routing are also tested.

Each step of the installation and the configuration parameters are documentedin appendix A.

6.1 Basic email routingThe first step is to test if the test system works with a mesh of mail servers. Theidea is to make the mail servers do some modification to the email while it is intransit. This is a natural way of life for an email that passes through the Internet.It can for example be modified with new headers or forwarded to new locations.The basic services that a mail server can provide are, for example, the followingtechniques:

• MasqueradeThe mail server changes the From: header of an email when the masqueradeservice is activated. The idea is to hide the real sender and making it looklike the email is from somewhere else.

• AliasAliasing is a technique where a virtual email address is created at the mailserver. This virtual address is then either connected to a real email addressor an internal process in the mail server. Any email arriving to the virtualaddress is forwarded to the correct destination.

• ForwardAn email can forwarded from one destination to another. This can eitherbe done in plain text or by remailing the message content. The differenceis whether the email headers are kept or new ones are created. Forwardingcan be done at the mta, the mda, or the mua by using the .forward in the

55

56 Interoperability testing

email user’s home directory, .procmailrc in the email user’s home directory,or a script in the mua. These methods depend on what softwares are in useand can be replaced by others if not the current test configuration is in use.

• Mailing listA mailing list is where an incoming email is sent to a list of recipients. Thisis often done by using aliasing, either by using multiple recipients in thealias file or by sending the email to a mailing list software on the server. Themailing list software then remail it to the intended recipients.

All of these method mentioned above are tested together with the dkim milter.Mailman is the mailing list software that is tested. Procmail and Microsoft OfficeOutlook 2003 are used as the mda respectively mua.

6.1.1 Test casesThe basic mailing services are tested by mailing to local and external email ac-counts. External email accounts are the ones resided on the other mta in the testsuite. The reason of mailing both to local and external addresses are because theemails may be treated differently. The test cases are a combination of externaland internal addresses, see table 6.1. “From external to external and then local.”does for example mean that the email is sent from an external address to the mtawhere it is sent back to the other mta and then at this mta the email is sent toanother local address for final delivery, see figure 6.1 and figure 6.2.

The test scenarios are viewed from two accounts when using mailing lists, test1and test2, each on the different domains. The mailing lists are configured toappend a message in some of the emails to test if content altering will affect thedkim signature.

6.1 Basic email routing 57

test1

[email protected] [email protected]

test1

extloc@...

loc@...

test1@...

Figure 6.1. Description of test scenario: From external to external and then local.Originating MTA is Postfix.


test2

[email protected] [email protected]

test1

extloc@...

loc@...

test1@...

Figure 6.2. Description of test scenario: From local to external and then local.Originating MTA is Sendmail.


Table 6.1: Basic mailing test cases.

3 Basic mailing services

3.1 Masquerade the domain as another domain.3.1.1 From local to local.3.1.2 From local to external.

3.2 Aliasing in the mta.3.2.1 From local to local.3.2.2 From external to local.3.2.3 From local to external.3.2.4 From external to external.3.2.5 From local to external and then external.3.2.6 From external to external and then external.3.2.7 From local to external and then local.3.2.8 From external to external and then local.3.2.9 From local to local and then local.3.2.10 From external to local and then local.3.2.11 From local to local and then external.3.2.12 From external to local and then external.

3.3 Forward in the mta.3.3.1 From local forward to local.3.3.2 From external forward to local.3.3.3 From local forward to external.3.3.4 From external forward to external.3.3.5 From local forward to external and then forward to external.3.3.6 From external forward to external and then forward to external.3.3.7 From local forward to external and then forward to local.3.3.8 From external forward to external and then forward to local.3.3.9 From local forward to local and then forward to local.3.3.10 From external forward to local and then forward to local.3.3.11 From local forward to local and then forward to external.3.3.12 From external forward to local and then forward to external.

3.4 Forward in the mda.3.4.1 From local forward to local.3.4.2 From external forward to local.3.4.3 From local forward to external.3.4.4 From external forward to external.3.4.5 From local forward to external and then forward to external.3.4.6 From external forward to external and then forward to external.3.4.7 From local forward to external and then forward to local.3.4.8 From external forward to external and then forward to local.


3.4.9 From local forward to local and then forward to local.3.4.10 From external forward to local and then forward to local.3.4.11 From local forward to local and then forward to external.3.4.12 From external forward to local and then forward to external.

3.5 Remailing with Mailman. dkim enabled mail-ing lists.

3.5.1 From local to mail list. Not adding content. Recipient test1.3.5.2 From local to mail list. Not adding content. Recipient test2.3.5.3 From external to mail list. Not adding content. Recipient test1.3.5.4 From external to mail list. Not adding content. Recipient test2.3.5.5 From local to mail list. Adding content. Recipient test1.3.5.6 From local to mail list. Adding content. Recipient test2.3.5.7 From external to mail list. Adding content. Recipient test1.3.5.8 From external to mail list. Adding content. Recipient test2.

3.6 Remailing with Mailman. dkim not enabledon exempel2.tset.se.




3.8 Mailing list with the alias file.3.8.1 From local to mail list. Recipient test1.3.8.2 From local to mail list. Recipient test2.3.8.3 From external to mail list. Recipient test1.3.8.4 From external to mail list. Recipient test2.


6.1.2 Test resultsEach of the test cases were performed by sending from both the Sendmail mtaand the Postfix mta. The first domain, exempel1.tset.se, is represented by thePostfix mta and is marked with ex1 in the transcript below. The second domain,exempel2.tset.se, is represented by the Sendmail mta and is marked with ex2 inthe transcript below.

Table 6.2: Basic mailing test results.

# Orig. MTA Events Result3.1.1 Sendmail Sign (ex2). Change header

sender to @exempel1.tset.se(ex2).

Fail 9

Postfix Sign (ex1). Change headersender to @exempel2.tset.se(ex1).

Fail 9

3.1.2 Sendmail Sign (ex2). Change headersender to @exempel1.tset.se(ex2). Verify neutral (ex1).

Fail 1

Postfix Sign (ex1). Change headersender to @exempel2.tset.se(ex1). Verify neutral (ex2).

Fail 1

3.2.1 Sendmail Sign (ex2). ok 3

Postfix Sign (ex1). ok 3

3.2.2 Sendmail Sign (ex2) and verify pass (ex1). ok 2

Postfix Sign (ex1) and verify pass (ex2). ok 2



3.2.4 Sendmail Sign (ex2) and verify pass (ex1)and verify pass (ex2).

ok 2

Postfix Sign (ex1) and verify pass (ex2)and verify pass (ex1).

ok 2


ok 2


ok 2

3.2.6 Sendmail Sign (ex2) and verify pass (ex1).Verify pass (ex2). Remove authand verify pass (ex1).

ok 2

Postfix Sign (ex1) and verify pass (ex2).Verify pass (ex1). Remove authand verify pass (ex2).

ok 2




3.2.8 Sendmail Sign (ex2) and verify pass (ex1).Verify pass (ex2).

ok 2

Postfix Sign (ex1) and verify pass (ex2).Verify pass (ex1).

ok 2








ok 2


ok 2








ok 2


ok 2


ok 2


ok 2

3.3.6 Sendmail Sign (ex2) and verify pass (ex1).Verify pass (ex2). Remove authand verify pass (ex1).

ok 2

Postfix Sign (ex1) and verify pass (ex2).Verify pass (ex1). Remove authand verify pass (ex2).

ok 2



3.3.8 Sendmail Sign (ex2) and verify pass (ex1).Verify pass (ex2).

ok 2

Postfix Sign (ex1) and verify pass (ex2).Verify pass (ex1).

ok 2









ok 2


ok 2

3.4.1 Sendmail Sign (ex2). Remove sign and re-sign (ex2).

ok 3

Postfix Sign (ex1). Remove sign and re-sign (ex1).

ok 3

3.4.2 Sendmail Sign (ex2) and verify pass (ex1).Remove auth and verify pass(ex1).

ok 2

Postfix Sign (ex1) and verify pass (ex2).Remove auth and verify pass(ex2).

ok 2

3.4.3 Sendmail Sign (ex2). Remove sign and re-sign (ex2). Verify pass (ex1).

ok 2

Postfix Sign (ex1). Remove sign and re-sign (ex1). Verify pass (ex2).

ok 2

3.4.4 Sendmail Sign (ex2) and verify pass (ex1).Remove auth and verify pass(ex1). Verify pass (ex2).

ok 2

Postfix Sign (ex1) and verify pass (ex2).Remove auth and verify pass(ex2). Verify pass (ex1).

ok 2

3.4.5 Sendmail Sign (ex2). Remove sign and re-sign (ex2). Verify pass (ex1) andverify pass (ex2).

ok 2

Postfix Sign (ex1). Remove sign and re-sign (ex1). Verify pass (ex2) andverify pass (ex1).

ok 2

3.4.6 Sendmail Sign (ex2) and verify pass (ex1).Remove auth and verify pass(ex1). Verify pass (ex2). Removesign and resign (ex2). Removeauth and verify pass (ex1).

ok 2

Postfix Sign (ex1) and verify pass (ex2).Remove auth and verify pass(ex2). Verify pass (ex1). Removesign and resign (ex1). Removeauth and verify pass (ex2).

ok 2


3.4.7 Sendmail Sign (ex2). Remove sign and re-sign (ex2). Verify pass (ex1).Remove auth and verify pass(ex1).

ok 2

Postfix Sign (ex1). Remove sign and re-sign (ex1). Verify pass (ex2).Remove auth and verify pass(ex2).

ok 2

3.4.8 Sendmail Sign (ex2) and verify pass (ex1).Remove auth and verify pass(ex1). Verify pass (ex2). Removesign and resign (ex2).

ok 3

Postfix Sign (ex1) and verify pass (ex2).Remove auth and verify pass(ex2). Verify pass (ex1). Removesign and resign (ex1).

ok 3

3.4.9 Sendmail Sign (ex2). Remove sign and re-sign (ex2). Remove sign and re-sign (ex2).

ok 3

Postfix Sign (ex1). Remove sign and re-sign (ex1). Remove sign and re-sign (ex1).

ok 3

3.4.10 Sendmail Sign (ex2) and verify pass (ex1).Remove auth and verify pass(ex1). Remove auth and verifypass (ex1).

ok 2

Postfix Sign (ex1) and verify pass (ex2).Remove auth and verify pass(ex2). Remove auth and verifypass (ex2).

ok 2


ok 2


ok 2

3.4.12 Sendmail Sign (ex2) and verify pass (ex1).Remove auth and verify pass(ex1). Verify pass (ex2).

ok 2

Postfix Sign (ex1) and verify pass (ex2).Remove auth and verify pass(ex2). Verify pass (ex1).

ok 2


ok 2


ok 3



ok 3


ok 2

3.5.3 Sendmail Sign (ex2). Verify pass (ex1).Remove sign and resign (ex1).

ok 3

Postfix Sign (ex1). Verify pass (ex2).Remove sign and resign (ex2).Verify pass (ex1).

ok 2

3.5.4 Sendmail Sign (ex2). Verify pass (ex1).Remove sign and resign (ex1).Verify pass (ex2).

ok 2

Postfix Sign (ex1). Verify pass (ex2).Remove sign and resign (ex2).

ok 3


ok 2


ok 3


ok 3


ok 2

3.5.7 Sendmail Sign (ex2). Verify pass (ex1).Remove sign and resign (ex1).

ok 3

Postfix Sign (ex1). Verify pass (ex2).Remove sign and resign (ex2).Verify pass (ex1).

ok 2

3.5.8 Sendmail Sign (ex2). Verify pass (ex1).Remove sign and resign (ex1).Verify pass (ex2).

ok 2

Postfix Sign (ex1). Verify pass (ex2).Remove sign and resign (ex2).

ok 3

3.6.1 Sendmail Verify none (no signature) (ex1). ok 5


ok 3

3.6.2 Sendmail - ok 4


ok 6

3.6.3 Sendmail Verify none (no signature) (ex1).Sign (ex1).

ok 3

Postfix Sign (ex1). Verify neutral (veri-fication failed) (ex1).

Fail 8


ok 6

Postfix Sign (ex1). Fail 9


3.6.5 Sendmail Verify none (no signature) (ex1). ok 5


ok 3

3.6.6 Sendmail - ok 4


ok 6


ok 3

Postfix Sign (ex1). Verify neutral (veri-fication failed) (ex1).

Fail 7


ok 6

Postfix Sign (ex1). Fail 9


ok 6

Postfix - ok 4


ok 3

Postfix Verify none (no signature) (ex2). ok 5

3.7.3 Sendmail Sign (ex2). Fail 9

Postfix Verify none (no signature) (ex2).Sign (ex2).

ok 6

3.7.4 Sendmail Sign (ex2). Verify neutral (veri-fication failed) (ex2).

Fail 8


ok 3


ok 6

Postfix - ok 4


ok 3

Postfix Verify none (no signature) (ex2). ok 5

3.7.7 Sendmail Sign (ex2). Fail 9


ok 6

3.7.8 Sendmail Sign (ex2). Verify neutral (veri-fication failed) (ex2).

Fail 7


ok 3

3.8.1 Sendmail Sign (ex2). Verify pass (ex1). ok 2



Postfix Sign (ex1). Verify pass (ex2). ok 2


3.8.3 Sendmail Sign (ex2). Verify pass (ex1). ok 2

Postfix Sign (ex1). Verify pass (ex2).Verify pass (ex1).

ok 2

3.8.4 Sendmail Sign (ex2). Verify pass (ex1).Verify pass (ex2).

ok 2

Postfix Sign (ex1). Verify pass (ex2). ok 2

Some comments on the test results. See chapter 8 for more discussions about theresults.

1 Masquerading will automatically break the signature, because it manip-ulates the From: header.

2 Signing and verification are performed successfully.3 The verification process is not performed due to internal delivery within

the mta, but it would probably be successful because other similar trans-actions passed the verification stage.

4 No dkim related events because it is not activated on this domain.5 No signature could be found in the email because dkim is not activated

on the other domain.6 The message is signed when it leaves Mailman for delivery to its recip-

ients. If a dkim validation would have been performed, it would havebeen successful.

7 The verification fails because Mailman added content to the message andthe the email was not resigned.

8 The verification fails although Mailman was configured not to changeanything in the received email. It apparently removes the angle bracketsin the Reply-To: header, which breaks the signature. The solution wouldto modify the source code of Mailman, but this is not feasible becausethe external mailing lists are not in the control of the sender.

9 The verification process is not performed due to internal delivery withinthe mta, but it would probably not be successful because other similartransactions failed the verification stage.


6.2 Other technologiesThe second step is to test how well the dkim milter is working together with othersimilar technologies. Those selected are the ones discussed in chapter 3, spf,s/mime, and pgp. s/mime and pgp are integrated in the test suite by adding thecertificates and private keys to Microsoft Office Outlook 2003. spf is integratedby using the smf-spf implementation. It attaches it self to Postfix and Sendmailby using the Milter api.

A commonly used spam filter is also used, SpamAssassin, and it is integratedwith the mail servers by using the interface SpamAssassin-milter. SpamAssassinvalidates the incoming and outgoing email by using different rule sets. Variousplug-ins can be activated and spf and dkim validation are among those.

6.2.1 Test casess/mime and pgp are, in this case, applied to the message content at the mua andvalidated when it arrives at a mua. It is only interesting to see if their messagescan get through the system and everything is validated correctly. They focuseson content authentication and not sender authentication, thus will various emailrouting not add anything to the test results.

spf, on the other hand, will yield different results depending on how the emailis sent on the Internet. That is why SpamAssassin and smf-spf are tested morecarefully.

The test cases in table 6.4 are constructed in the same manner as the previoustest cases.

6.2 Other technologies 69

Table 6.4: Technology test cases.

4 S/MIME in Outlook

4.1 Signing and no encryption.4.1.1 To local address.4.1.2 To external address.

4.2 Signing and encryption.4.2.1 To local address.4.2.2 To external address.

5 PGP in Outlook

5.1 Signing and no encryption.5.1.1 To local address.5.1.2 To external address.

5.2 Signing and encryption.5.2.1 To local address.5.2.2 To external address.

6 SPF

6.1 Basic.6.1.1 To local.6.1.2 To external.

6.2 Aliasing.6.2.1 From local to local.6.2.2 From local to external.6.2.3 From external to local.6.2.4 From external to external.

6.3 Forward in the mda.6.3.1 From local forward to local.6.3.2 From external forward to local.6.3.3 From local forward to external.6.3.4 From external forward to external.


7 Spamassassin with SPF- andDKIM-plugin

7.1 Basic.7.1.1 To local.7.1.2 To external.

7.2 Forward in the mda.7.2.1 From local forward to local.7.2.2 From external forward to local.7.2.3 From local forward to external.7.2.4 From external forward to external.

7.3 Remailing with Mailman. dkim enabled mail-ing lists.

7.3.1 From local to mail list. Recipient test1.7.3.2 From local to mail list. Recipient test2.7.3.3 From external to mail list. Recipient test1.7.3.4 From external to mail list. Recipient test2.






6.2.2 Test resultsEach of the test cases were performed by sending from both the Sendmail mtaand the Postfix mta. The first domain, exempel1.tset.se, is represented by thePostfix mta and is marked with ex1 in the transcript below. The second domain,exempel2.tset.se, is represented by the Sendmail mta and is marked with ex2 inthe transcript below.

Table 6.5: Technology test results.

# Orig. MTA Events Result4.1.1 Sendmail Outlook signs. Sign (ex2). Out-

look verifies.ok 2

Postfix Outlook signs. Sign (ex1). Out-look verifies.

ok 2

4.1.2 Sendmail Outlook signs. Sign (ex2). Ver-ify pass (ex1). Outlook verifies.

ok 1

Postfix Outlook signs. Sign (ex1). Ver-ify pass (ex2). Outlook verifies.

ok 1

4.2.1 Sendmail Outlook signs and encrypt. Sign(ex2). Outlook verifies and de-crypt

ok 1

Postfix Outlook signs and encrypt. Sign(ex1). Outlook verifies and de-crypt.

ok 1

4.2.2 Sendmail Outlook signs and encrypt. Sign(ex2). Verify pass (ex1). Out-look verifies and decrypt.

ok 1

Postfix Outlook signs and encrypt. Sign(ex1). Verify pass (ex2). Out-look verifies and decrypt.

ok 1

5.1.1 Sendmail Outlook signs. Sign (ex2). Out-look verifies.

ok 2

Postfix Outlook signs. Sign (ex1). Out-look verifies.

ok 2

5.1.2 Sendmail Outlook signs. Sign (ex2). Ver-ify pass (ex1). Outlook verifies.

ok 1

Postfix Outlook signs. Sign (ex1). Ver-ify pass (ex2). Outlook verifies.

ok 1

5.2.1 Sendmail Outlook signs and encrypt. Sign(ex2). Outlook verifies and de-crypt

ok 1


Postfix Outlook signs and encrypt. Sign(ex1). Outlook verifies and de-crypt.

ok 1

5.2.2 Sendmail Outlook signs and encrypt. Sign(ex2). Verify pass (ex1). Out-look verifies and decrypt.

ok 1

Postfix Outlook signs and encrypt. Sign(ex1). Verify pass (ex2). Out-look verifies and decrypt.

ok 1



6.1.2 Sendmail Sign (ex2). spf pass (ex1). Ver-ify pass (ex1).

ok 1

Postfix Sign (ex1). spf pass (ex2). Ver-ify pass (ex2).

ok 1




ok 1


ok 1


ok 1


ok 1

6.2.4 Sendmail Sign (ex2). spf pass (ex1). Ver-ify pass (ex1). spf fail (ex2).Verify pass (ex2).

spf Fail3

Postfix Sign (ex1). spf pass (ex2). Ver-ify pass (ex2). spf fail (ex1).Verify pass (ex1).

spf Fail3

6.3.1 Sendmail Sign (ex1). spf pass (ex2). Re-move sign and resign (ex1).

ok 2


ok 2

6.3.2 Sendmail Sign (ex2). spf pass (ex1). Ver-ify pass (ex1). Remove auth andverify pass (ex1).

ok 1

Postfix Sign (ex1). spf pass (ex2). Ver-ify pass (ex2). spf pass (ex2).Remove auth and verify pass(ex2).

ok 1


6.3.3 Sendmail Sign (ex2). spf pass (ex2). Re-move sign and resign (ex2). spfpass (ex2). Verify neutral (ex2).

Fail 4

Postfix Sign (ex1). Remove sign and re-sign (ex1). spf pass (ex2). Ver-ify pass (ex2).

ok 1

6.3.4 Sendmail Sign (ex2). spf pass (ex1). Ver-ify pass (ex1). Remove auth andverify pass (ex1). spf pass (ex2).Verify pass (ex2).

ok 1

Postfix Sign (ex1). spf pass (ex2). Ver-ify pass (ex2). spf pass (ex2).Remove auth and verify pass(ex2). spf pass (ex1). Verifypass (ex1).

ok 1

7.1.1 Sendmail Message is signed. ok 2

Postfix Message is signed. ok 2

7.1.2 Sendmail Message is signed and verified.spf Pass.

ok 1

Postfix Message is signed and verified.spf Pass.

ok 1


ok 5

Postfix Message is signed. ok 2


ok 1


ok 1


ok 1


ok 1


ok 1


ok 1

7.3.1 - 7.5.4 Verification fails sometimes be-cause of header manipulationfrom Mailman. spf always Pass.

Fail 6



1 Signing and verification is performed successfully.2 The verification process is not performed due to internal delivery within

the mta, but it would probably be successful because other similar trans-actions passed the verification stage.

3 The spf verification fails because the message is forwarded from a do-main that are not allowed, according to the spf dns record, to sendan email with that specific email address domain as the original sender.The dkim signature is however intact.

4 The smf-spf milter mixes its results headers, thus breaking the signa-ture when several spf verifications are performed along the path to therecipient. This would have been avoided if it only prepends the au-thentication results to the email header instead of mixing it in to themiddle of the email header stack. smf-spf milter does not fully complywith RFC4408, which states that a result header must appear above anyother result header in the email header stack. The reason that only theSendmail test mta has this problem is because it get its mda forwardedemails from the external smtp port and not via the internal process (asthe case with the Postfix test mta), thus activating more verificationstages along the path to the recipient.

5 The Sendmail test mta treats the mda forwarded emails as externalemail due to the test configuration, thus having different test resultsthan the Postfix test mda.

6 Any message that is signed and passing through a non-signing Mail-man will have its signature broken, because Mailman removes the anglebrackets in the Reply-To: header. Mailman can not be configured notto do this through its web interface unless the source code is rewritten.The spf result is however positive because Mailman is sending the mailas if the email were from it self and not the original sender.

6.3 Other implementations 75

6.3 Other implementationsThe final step to take is to test against other implementations on the Internet.There are several sites that offer a way of testing dkim by providing an emailaddress that will auto reply the verification results back to the sender who sentthem a message on that email address, thus giving the opportunity to view howother implementations interpret the dkim milter signed message.

6.3.1 Test casesThe following list shows which addresses that will be used in the test cases, seetable 6.7.

• Port25They provide a mta called Powermta [43]. This software includes dkimvalidation and is used in their authentication [email protected]

• Eland systemsIs a consulting company that provides a verification service based on thedkim milter [41][email protected]

• DKIM.orgThe Mutual Internet Practices Association (MIPA) is hosting a site aboutthe dkim standard [16]. The following address bounces an answer of howthe authentication went on their [email protected]

• Alt-NThey are providing the mail server MDaemon and it has an implementationof the dkim standard [3][email protected]

• SendmailThe authors behind the Sendmail mta are providing a verification servicebased on the dkim milter [52][email protected]

• ExhalusThey are providing the mail server MailEnable which implements dkim intheir DKeyEvent plug-in [18][email protected]


• GMail.comGoogle provides an email service called GMail and they are signing andverifying their emails by using the dkim standard [22]. They are included inthe test suite by creating an email account at their website.

Linköping University is providing email accounts to its students. One of theseaccounts are configured to forward all of its emails to the GMail account. The testsuite will see if signed messages will get through their email system without beingtoo much modified.

Google, besides providing GMail, also have an mailing list service called Google-Groups and it is dkim enabled [23]. This mailing list will be tested to see how itis treating signed emails.


Table 6.7: Real world test cases.

8 Real world

8.1 GMail.com8.1.1 Send to.8.1.2 Receive from.

8.2 LiU.se8.2.1 Send to a student account and forward to GMail.

8.3 Port258.3.1 Send to.8.3.2 Receive from.

8.4 Elandsys8.4.1 Send to.8.4.2 Receive from.

8.5 DKIM.org8.5.1 Send to.8.5.2 Receive from.

8.6 Alt-N8.6.1 Send to.8.6.2 Receive from.

8.7 Sendmail8.7.1 Send to.8.7.2 Receive from.

8.8 Exhalus8.8.1 Send to.8.8.2 Receive from.

8.9 GoogleGroups8.9.1 Recipient test1.8.9.2 Recipient test2.


6.3.2 Test resultsThe following test results shows what happened during each test case. Each eventis marked with where it was generated.

Table 6.8: Real world test results.

# Orig. MTA Events Result8.1.1 Sendmail Sign (ex2). Verify pass (GMail). OK 1

Postfix Sign (ex1). Verify pass (GMail). OK 1

8.1.2 Sendmail Sign (GMail). Verify pass (ex2). OK 1

Postfix Sign (GMail). Verify pass (ex1). OK 1

8.2.1 Sendmail Sign (ex2). Verify hardfail(GMail).

Fail 2

Postfix Sign (ex1). Verify hardfail(GMail).

Fail 2

8.3.1 Sendmail Sign (ex2). Verify pass (Port25). OK 1

Postfix Sign (ex1). Verify pass (Port25). OK 1

8.3.2 Sendmail Sign (Port25). Verify pass (ex2). OK 1

Postfix Sign (Port25). Verify pass (ex1). OK 1

8.4.1 Sendmail Sign (ex2). Verify pass(Elandsys).

OK 1

Postfix Sign (ex1). Verify pass(Elandsys).

OK 1

8.4.2 Sendmail Sign (Elandsys). Verify pass(ex2).

OK 1

Postfix Sign (Elandsys). Verify pass(ex1).

OK 1

8.5.1 Sendmail Sign (ex2). Verify pass(DKIM.org).

OK 1

Postfix Sign (ex1). Verify pass(DKIM.org).

OK 1

8.5.2 Sendmail Sign (DKIM.org). Verify pass(ex2).

OK 1

Postfix Sign (DKIM.org). Verify pass(ex1).

OK 1

8.6.1 Sendmail Sign (ex2). Verify pass (Alt-N). OK 1

Postfix Sign (ex1). Verify pass (Alt-N). OK 1

8.6.2 Sendmail Sign (Alt-N). Verify pass (ex2). OK 1

Postfix Sign (Alt-N). Verify pass (ex1). OK 1


8.7.1 Sendmail Sign (ex2). Verify pass (Send-mail).

OK 1

Postfix Sign (ex1). Verify pass (Send-mail).

OK 1

8.7.2 Sendmail Sign (Sendmail). Verify pass(ex2).

OK 1

Postfix Sign (Sendmail). Verify pass(ex1).

OK 1

8.8.1 Sendmail Sign (ex2). Verify pass (Ex-halus).

OK 1

Postfix Sign (ex1). Verify pass (Ex-halus).

OK 1

8.8.2 Sendmail Sign (Exhalus). Verify pass(ex2).

OK 1

Postfix Sign (Exhalus). Verify pass(ex1).

OK 1

8.9.1 Sendmail Sign (ex2). Verify pass (Google-Groups). Sign (GoogleGroups).Verify pass (ex1).

OK 3

Postfix Sign (ex1). Verify pass (Google-Groups). Sign (GoogleGroups).Verify pass (ex1).

OK 3

8.9.2 Sendmail Sign (ex2). Verify pass (Google-Groups). Sign (GoogleGroups).Verify pass (ex2).

OK 3

Postfix Sign (ex1). Verify pass (Google-Groups). Sign (GoogleGroups).Verify pass (ex2).

OK 3


1 Signing and verification is performed successfully.2 The MTA at Linköping University does a form of header sanitation by

removing some angle brackets and cite signs from the email headers. Thevalue of the Content-transfer-encoding: was converted to upper case,from 7bit to 7BIT. All of these modifications are performed on signedheaders and thus breaking the signature.


3 GoogleGroups breaks the old signature by example changing the Reply-to: header and adding content to the message, but it fixes it by resigningthe message before sending it to the recipients. SpamAssassin was turnedoff in the test mtas because when GoogleGroups resigns the email it in-cludes the test results from the SpamAssassin (generated when the emailis sent from the test mtas). These test results are then overwritten whenthe email returns to test mtas and thus breaking the signature. Thisalso suggest that any signature validation should be performed beforeany other activities that could break the signature, because SpamAssas-sin did its work before the dkim milter in the test suite.

Chapter 7

Statistics on DKIM usage

Some organizations and companies are more willing to be the pioneers within anarea and others only want to enter that area when it has gained enough attentionand interest. That is why statistics about the current use of dkim is a vital toolwhen facing a decision about dkim deployment. The statistics can give a hint ofthe current use and how well dkim is performing within the email system. It canalso show the current trends, whether the usage is increasing or not.

7.1 Measuring DKIM usageThe statistics is gathered by measuring a selection of data and thereby determiningthe basic numbers. These measurements must be performed where any usage ofdkim can be revealed. This can either be in the dns system, where the publickeys are stored, or in an email, where the signature is located.

7.1.1 Email in transitThe best way of finding the actual usage of dkim is by counting the numbers ofemail that have a dkim signature. The problem is that there is no measurementpoint where all the emails in the world are passing through. This measurementcan then only be done at the various mtas and thus getting a measurement atthat specific location. The statistics for that mta only reflects the dkim usage ofits users and this could vary from mta to mta.

The signatures can also be validated to give an indication on how well theemails are surviving its passage through the email system. If only a small numberof the signed messages are validated correctly, then there is no idea to use dkimin the first place. It is thereby also important to measure the numbers of correctlyvalidated emails.

These measurements are done by counting the results that SpamAssassin putsin the mail log at the server. It indicates whether an email was spam or ham, bador good email, and if the message was signed and if the signature could be verified.Because SpamAssassin is a mail filter that is applied as one of the last steps before

81

82 Statistics on DKIM usage

delivering the message to the users, these numbers will only reflect the usage ofdkim in emails that have not been rejected along the path within the mta. Forexample will an email from blacklisted addresses not reach SpamAssassin, becausethey are rejected by the mta when it receives the email.

7.1.2 DKIM DNS recordsThe second method is to count the number of domains that have published a publickey for dkim in its dns records. The problem is that this location is not exactlyknown to an outsider. The rfc specifies that the public key should be stored underselector._domainkey.“domain” [2]. The selector is chosen by the administratorof the domain and could be any arbitrary combination of valid characters. Anexhaustive search must then be done to find the public key on a given domain,which is not feasible considering that there are for example more than 700 000second-level domains under the Swedish top level domain and the measurementsmust be done during a short amount of time. The reason that a recipient of adkim signed email knows where to get the public key is because the name of theselector is stated in the signature header.

There are other ways of finding out the existence of a public key. The firstalternative is to use a rr provided by the dnssec, the Next Secure (nsec) record[5]. It gives authenticated proof of the non-existence of dns owner names andtypes. This means that the content of a dnssec enabled zone can be enumeratedand thus revealing any dkim public keys. But since most of the Swedish second-level domains are not dnssec enabled, can this method not be used.

The second alternative is to look for the domain _domainkey.“domain” and seeif it exists. The dns server will respond with NXDOMAIN, if the domain was non-existent, or NOERROR, if the domain exists. This method also has a problem andthat is caused by something called wildcards in the dns system [36]. A wildcard isused to catch any queries for subdomains that do not exist and giving an answerto the query as if the domain actually existed. Example 7.1 shows a wildcard andit would catch the query for the domain somethingrandom.example1.tset.se butnot for letters123.host.exempel1.tset.se, since the host subdomain already exist.

Example 7.1: Wildcard in DNS

*.exempel1.tset.se IN A 88.131.68.181host.exempel1.tset.se IN A 88.131.68.183

There is no actual way of knowing if a wildcard answered the question or ifthe domain really existed, but the wildcard can be revealed by queering for a veryodd domain name and see if that domain gets any answer.

The summarization is that two queries must be performed to get a hint if adkim public key exists on a specific domain. One query for _domainkey.“domain”and one for “somethingveryrandom”._domainkey.“domain”. The first one tells that

7.2 Graphs on DKIM usage 83

a key could exist and the second one if it only was a wildcard answer and therebya false positive answer.

The last obstacle is that wildcards are allowed within the _domainkey domainand could be used together with the Canonical Name (cname) record to delegatethe key management to another domain, like in example 7.2 [40]. The previousmethod will not catch these cases and will thus not include them in the statistics.The statistics should then be considered as a lower number and an indication onhow current trend is looking like. The last obstacle is that the obsoleted standardDomainKeys stores its public keys under the same domain name as dkim [14] andnothing can be done to separate them from each other. The results could theninclude the DomainKeys usage, but this should not affect the statistics in a greatdegree since DomainKeys is an obsoleted standard.

Example 7.2: DKIM delegation*._domainkey.exempel1.tset.se IN CNAME dkim.trusted.hosting.se

7.2 Graphs on DKIM usageThe results gathered by the methods mentioned above are presented in the follow-ing graphs. The time intervals are noted in each graph. Further discussion aboutthe graphs can be found in chapter 8.

7.2.1 At an email serverFigures 7.1- 7.2 shows the measurements taken at a small mail server. The gap inthe middle of the graphs is caused by downtime when upgrading the mail serverwith new hardware. The first graph shows the dkim usage among the non-spamemail (ham). The lines represent the percentage of the ham email that has a dkimsignature respectively a positive verifiable dkim signature. The second graphshows the corresponding values for spam. It is known that the users within thisemail domain are often receiving email through external mailing lists, which hasbeen shown in chapter 6 to have a negative effect on the dkim signature. Thismight give less verifiable email than on average.

7.2.2 Among the Swedish domainsFigure 7.3 shows the number of Swedish domains that indicates, in their dns, thatthey are using dkim. There are, at the time of writing, around 750 000 Swedishdomains, but the statistics shows that only around 300 domains are using dkim.Among these domains can some important ones be found. One bank, two emailproviders, and two government authorities are using dkim. A closer look on theraw data shows that a big number of the domains in the statistics are hosted bydifferent web hotels. One of the big jumps happened when a single web hotelturned on dkim signing in their mail server.


Figure 7.1. The percentage of ham email that are signed with DKIM and the percentagethat are signed and positive verified.

7.2 Graphs on DKIM usage 85

Figure 7.2. The percentage of spam email that are signed with DKIM and the percent-age that are signed and positive verified.


Figure 7.3. The number of Swedish domains using DKIM.

Chapter 8

Summary and Conclusions

The outcome of this master’s thesis is summarized and conclusions related to eachof the goals are drawn in this chapter. The goals of this master’s thesis can befound in chapter 1.

8.1 DKIM installation and testingThere are known ways of spoofing the author of an email, but there are alsomethods that will work against this kind of spoofing, see chapter 3. spf specifieswhere an email with a specific email domain name can be sent from, whereass/mime, pgp, and dkim reveal if the author is who he or she claims to be. Theidentification is done by securing the content of the email with a digital signaturethus also giving an opportunity to detect any non-authorized modifications of theemail. dkim also protects some of the email headers.

dkim works in a non-intrusive way by inserting its signature into the emailheader and not into the email body, as is the case with s/mime and pgp. Thisgives a smoother transition when deploying dkim on the Internet, since a user thatdoes not have dkim validation will not notice any difference when just viewing theemail content.

The other positive thing about dkim is how the public key is treated. Therecipient must retrieve the public key of the sender to be able to validate thesignature. The key retrieval is performed automatically from a known locationand is called the public-key infrastructure. s/mime and pgp use dedicated serversfor this purpose, while dkim uses the dns infrastructure to distribute its publickeys. The dns infrastructure is needed for the email transportation and becauseof this dkim will not need any new infrastructure, thus inflicting less cost on thedeployment of it.

If a recipient does not know that the sender is signing its email with dkim,then an attacker could just remove the signature and do any modification of his orher choice. That is why adsp comes in handy, because it informs the recipient ofthis and gives recommendations on how it should treat the received email if it ismissing a signature or if the signature is non-verifiable. adsp is not, at the time of

87

88 Summary and Conclusions

writing (autumn 2008), an ietf standard, but it will be when all the formalitieshave been taken care of within the ietf.

8.2 DKIM Milterdkim is relying on the dns infrastructure to deliver the correct dkim public keyto the recipient, but there are methods that will give attackers the opportunityto distribute their own dkim public key. Packet Interception, ID Guessing andQuery Prediction, Name Chaining and Betrayal By Trusted Server are some ofthese methods, see chapter 2. An attacker could then sign an email with a differentprivate key and then send the corresponding public key to the recipient as if itwere coming from the domain of attack. These forms of attacks can be detectedby enabling dnssec on the sending domain’s dns server and enabling dnssecvalidation at the recipient.

The dnssec infrastructure is in its starting blocks and more top-level domainsare starting to sign their zones, thus enabling a widespread use and easier keymanagement by using secure delegations to their child domains, see chapter 2for further information. Each island-of-trust has a secure entry point to whicheach resolver needs a corresponding public key. The goal is to have the dnssystem signed all the way up to the root zone and then only one public key isneeded to securely validate the dns responses and thus knowing that the receiveddkim public key is the correct one. dnssec is an important extension to the dnsinfrastructure in order to be able to have a secure public-key infrastructure forthe dkim standard. dnssec is also equally important for the Internet as a whole,since most of the communication depends on the reliability of the dns system.

8.3 Deployment of DKIMThe test environment is easy to configure and install, but some parts needs a littlebit more thinking than other parts, read chapter 4 and appendix A. The mostnotable is the difference between Sendmail and Postfix. Sendmail gives powerfulconfiguration parameters, but at the same time more possibilities to get a faultyconfiguration. Postfix on the other hand does not need as much parameters tohave it running correctly. It is much easier for a first time user to install thePostfix mta than the Sendmail mta.

The goal of the first basic tests, section 4.2, were to see if the extended dkimmilter is functioning correctly with both middle-of-the-road values and with unex-pected input values. The conclusion is that it is functioning properly and followingthe current standard of dnssec. The dkim milter will produce a neutral result(soft fail) if something goes wrong (broken signature, no key retrieval) during theverification process and if the sending domain is using dkim in testing mode. Thisis perfectly normal and should be taken into consideration when configuring thedkim dns record.

dnssec is now available in dkim milter as of beta release for version 2.8.0 andthereby no patching is needed.

8.4 Interoperability tests 89

8.4 Interoperability testsThe dkim signature survives the basic email routing methods like aliasing, for-warding in the mta, and forwarding in the mda because these will not modify theemail message thus preserving the signature, see chapter 6. The exception is whenusing masquerading. This will change some of the addresses in the email and thusbreaks the signature, if a dkim signature is present. The interoperability testsshows that forwarding might not always work as intended This is the case withLinköping University’s forwarding service: An email is not forwarded directly butundergoes a kind of header sanitation and thereby the dkim signature will becomebroken, see section 6.3.2.

The next step in email routing is mailing lists, which forward a message toother recipients. A problem with the Mailman mailing list program is that itmodifies the Reply-To: header of an email and thereby breaks the signature if thatheader field has been signed. This can be fixed by having a mailing list whichre-signs the message and thus provides the message with a valid signature withthe mailing list as the origin.

dkim works well together with s/mime and pgp, since dkim only adds a headerto the email and thus does not break the signature of s/mime or pgp. But if dkimis applied before signing the email with s/mime or pgp, then the dkim signaturewill be broken because it does not allow either s/mime or pgp to add signaturesto the email body. s/mime and pgp are generally applied at the mua and dkimis applied at the mta, subsequently this situation will not occur.

In general, signing with dkim milter should be performed as the last step beforesending the email to the recipient and the validation should be performed as thefirst step when receiving an email. Other email technologies might add or modifyinformation, thereby making the dkim signature invalid. The exception to thisrule is if it is known that the specific technology will not modify the email; anexample of this is blacklisting which will reject any message when it arrives froma given sources.

8.5 ThreatsThe threat models show that there is a threat to the dkim system by rogue usersand malicious software on authorized computers, see chapter 5. dkim only protectsthe domain name and not the actual user, thus there is an opportunity for rougeusers and malicious software to act in the name of another user or the user itselfwithin the own domain. Proper countermeasures must be in place to deal withthis type of problem, like making sure that the user only can send messages in thename of him- or herself and making the user accountable for his or her actions byusing logging.

Another problem is that recipients might be tricked into believing that theemail is from a trusted source, when it actually is from a domain with a similarname or that the display name looks like a trusted source. This is something dkimcan not prevent since similar domain names are allowed to be registered by otherentities.

90 Summary and Conclusions

There is no natural protection against replaying of old messages except theDate: header in the email and an optional timestamp in the signature. TheDate: header indicates when the message was sent and most mtas will not accepttoo old messages. It is therefore important to sign this header field to give apossibility to detect any message replaying from malicious entities. An importantcountermeasure by the user is to not write anything that might do any harm if itis received more than one time by the recipient.

The dkim signature can be configured to only include a limited length of theemail body by using the length parameter. This will however open up the possi-bility for a malicious entity to add content to the email.

An attacker also has the possibility to add or modify unsigned headers to theemail without breaking the signature. It is therefore important to consider whichheaders are important to protect by signing them and which headers that mightalter the email in a bad way if they are added by a malicious entity, so that thepossibly malicious headers can be denied.

8.6 Statistics of current DKIM usageThe statistics were gathered during a short time period and because of this, infor-mation about actual trends cannot be concluded. The results from our small mailserver show that only a third of the signatures are valid for the ham email, butwe known that many of the emails are coming through mailing lists and they areknown to break the signature of an email. More mail servers must be monitoredto get a more accurate average number. Spam has a lower dkim usage and only atenth of the signatures were valid, see chapter 7.

Currently, there are not many Swedish domains using dkim, but more andmore are joining the community.

8.7 Demonstrations and presentationsComments and feedback to this master’s thesis were given by the participants dur-ing the seminars when preliminary results were presented. The participants wererepresentatives from different Swedish government authorities, local and interna-tional companies, and various organizations.

• An important question is whether or not the usage of dkim will interferewith other email software running on the server. This master’s thesis hasshown that dkim can coexist with other similar technologies. This is true ifsigning and verification are done in a proper order. There is software thatwill break the signature if it manipulates the email after it has been signedand before the email has been verified. There is a need for a deeper studyof which software that might interfere with the dkim signature.

• A problem for small companies and organizations is that they often rely onother software developers and service providers. This in turn means that

8.8 Recommendations 91

they can not use dkim if the software developers and service providers donot have any support for dkim. dkim is a relatively new standard and themarket needs some time to fully adapt to. Larger organizations are startingto experiment with and use dkim. This will hopefully raise the awareness ofthe dkim standard.

• Some participants wanted the possibility to encrypt the message content,which is not part of the dkim standard [2]. There are however other tech-nologies that will do this. The email body can be encrypted by using forexample s/mime or pgp. The smtp traffic between two mail servers canbe encrypted by using tls. A secure channel between two servers can becreated by using for example Internet Protocol Security (ipsec) [31].

• The downside with dkim is that there are many natural obstacles in theemail system that will interfere with the signature, like mailing lists andforwarding services that modify some of the email headers. The consensusis that these modifications, which are allowed by other standards, shouldbecome less common when the usage of dkim increases. This is becausethese changes do not hurt anyone now, but with dkim they will. This willthus give a greater demand for less intrusive services.

8.8 RecommendationsThe final recommendation is to use dkim together with adsp and dnssec to ensurethat the recipient does not get tricked by an attacker. The usage of dkim doesnot limit the concurrent usage of other technologies. A good complement is to usespf since it can detect if an email is not originating from the correct hosts, thuslimiting some of the replay attacks.

dkim and adsp are about protecting the email domain name from abuse. Thebest way to achieve this is to communicate as directly as possible with the finalrecipient to avoid any unwanted modifications to the email during its transit inthe email system.

Chapter 9

Future work

The work of this master’s thesis can be continued by looking at the followingtopics. There was no room for these topics in this thesis due to the delimitationspresented in chapter 1, but they still are interesting in a research perspective.

• Do a comparison of the different dkim implementations available on themarket and present the different properties. This will give a hint of whatimplementations that can be recommended to be used in for example a com-mercial environment.

• Do a deeper study of which software that might interfere with the dkimsignature.

• Have a look on what could motivate companies, organizations, and emailservice providers to start sign and validate their email with dkim.

• Collect more statistics on the current use of dkim. What implementations,mail servers, etc. are used?

• adsp is an upcoming standard that will handle dkim signing practices. Thisstandard could be investigated more thoroughly, since it did not have muchroom in this thesis.

• Cryptographic operations are resource demanding. It would be interesting tofind out how much overhead dkim with dnssec gives to the email handlingprocesses.

• Analyze if spammers could take any advantage of signing their emails withdkim.

93

Bibliography

[1] Ahlund, J., and Wallstrom, P. DNSSEC - Tester av routrar förhemmabruk. Tech. rep., .SE, Feb. 2008.

[2] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., andThomas, M. DomainKeys Identified Mail (DKIM) Signatures. RFC 4871(Proposed Standard), May 2007.

[3] Alt-N. Alt-N Technologies. Website. http://www.altn.com , Accessed2008-08-29.

[4] Ardi, S. Secure Software Development - Part 1. Software Security (TDDC90)lecture at Linköping University, 2008.

[5] Arends, R., Austein, R., Larson, M., Massey, D., and Rose, S.Resource Records for the DNS Security Extensions. RFC 4034 (ProposedStandard), Mar. 2005.

[6] Association, R. S. T. O. Root Server Technical Operations Assn. Website.http://www.root-servers.org , Accessed 2008-08-09.

[7] Atkins, D., and Austein, R. Threat Analysis of the Domain Name System(DNS). RFC 3833 (Informational), Aug. 2004.

[8] Blum, R. Open Source E-mail Security. Sams, 2001. ISBN 9780672322372.

[9] Boneh, D., and Brumley, D. Remote Timing Attacks are Practical. Tech.rep., Stanford University, 2003.

[10] Bradner, S. Newcomer’s Training. Presentation at IETF conference inDublin, July 2008.

[11] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and Thayer, R.OpenPGP Message Format. RFC 4880 (Proposed Standard), Nov. 2007.

[12] Clark, S. Server and Domain Isolation Using IPsec and Group Policy.Microsoft, Mar. 2005, ch. Appendix D: IT Threat Categories.

[13] Crispin, M. Internet Message Access Protocol - Version 4rev1. RFC 3501(Proposed Standard), Mar. 2003. Updated by RFCs 4466, 4469, 4551, 5032,5182.

95

96 Bibliography

[14] Delany, M. Domain-Based Email Authentication Using Public Keys Adver-tised in the DNS (DomainKeys). RFC 4870 (Historic), May 2007. Obsoletedby RFC 4871.

[15] Dierks, T., and Rescorla, E. The Transport Layer Security (TLS) Pro-tocol Version 1.1. RFC 4346 (Proposed Standard), Apr. 2006. Updated byRFCs 4366, 4680, 4681.

[16] DKIM.org. DKIM Testing. Website. http://testing.dkim.org , Accessed2008-08-29.

[17] E. Allman and J. Fenton and M. Delany and J. Levine. DKIMAuthor Domain Signing Practices (ADSP) - Draft 5. Website. http://www.ietf.org/internet-drafts/draft-ietf-dkim-ssp-05.txt , Ac-cessed 2008-08-10.

[18] Exhalus. MailEnable. Website. http://mailenable.exhalus.org , Ac-cessed 2008-08-29.

[19] Forouzan, B. TCP/IP Protocol Suite, 3rd ed. McGraw-Hill Education -Europe, 2005. ISBN 9780071115834.

[20] Gieben, M. DNSSEC: The Protocol, Deployment, and a Bit of Development.The Internet Protocol Journal 7, 2 (June 2004).

[21] Gollmann, D. Computer Security, 2nd ed. John Wiley & Sons, 2006. ISBN9780470862933.

[22] Google. GMail. Website. http://www.gmail.com , Accessed 2008-08-29.

[23] Google. GoogleGroups. Website. http://groups.google.com , Accessed2008-08-29.

[24] Hansen, T., and Crocker, D. DomainKeys Identified Mail (DKIM)Service Overview - Draft 10. Website. http://www.ietf.org/internet-drafts/draft-ietf-dkim-overview-10.txt , Accessed 2008-08-09.

[25] Harris, E. The Next Step in the Spam Control War: Greylisting. Web-site. http://projects.puremagic.com/greylisting/whitepaper.html ,Accessed 2008-08-10.

[26] Hernan, S., Lambert, S., Ostwald, T., and Shostack, A. UncoverSecurity Design Flaws Using The STRIDE Approach. MSDN Magazine (Nov.2006).

[27] Hoffman, P. SMTP Service Extension for Secure SMTP over TransportLayer Security. RFC 3207 (Proposed Standard), Feb. 2002.

[28] Housley, R., and Turner, S. Implementing Email and Security Tokens:Current Standards, Tools, and Practices. Pagina förlags AB, 2008. ISBN9780470254639.

Bibliography 97

[29] Howard, M., and Whittaker, J. Demystifying the Threat-Modeling Pro-cess. IEEE Security & Privacy (Oct. 2005).

[30] Kaner, J. C. What Is a Good Test Case? Tech. rep., Florida Institute ofTechnology, Department of Computer Sciences, May 2003.

[31] Kent, S., and Seo, K. Security Architecture for the Internet Protocol.RFC 4301 (Proposed Standard), Dec. 2005.

[32] Klensin, J. Simple Mail Transfer Protocol. RFC 2821 (Proposed Standard),Apr. 2001.

[33] Kolkman, O. NLnet Labs - DNSSEC Howto. Website. http://www.nlnetlabs.nl/dnssec_howto/ , Accessed 2008-08-26.

[34] Kurose, J., and Ross, K. Computer Networking: A Top-Down Approach,4th ed. Addison Wesley Publishing Company, 2007. ISBN 9780321497703.

[35] League, N. C. A Call for Action: Report from the National ConsumersLeague Anti-Phishing Retreat. Tech. rep., Washington, DC, Mar. 2006.

[36] Lewis, E. The Role of Wildcards in the Domain Name System. RFC 4592(Proposed Standard), July 2006.

[37] Lyon, J. Purported Responsible Address in E-Mail Messages. RFC 4407(Experimental), Apr. 2006.

[38] Lyon, J., and Wong, M. Sender ID: Authenticating E-Mail. RFC 4406(Experimental), Apr. 2006.

[39] Melnikov, A., and Zeilenga, K. Simple Authentication and SecurityLayer (SASL). RFC 4422 (Proposed Standard), June 2006.

[40] Mockapetris, P. Domain names - implementation and specification. RFC1035 (Standard), Nov. 1987. Updated by RFCs 1101, 1183, 1348, 1876, 1982,1995, 1996, 2065, 2136, 2181, 2137, 2308, 2535, 2845, 3425, 3658, 4033, 4034,4035, 4343.

[41] Moonesamy, S. DKIM. Email conversation. [email protected] , Accessed2008-07-17.

[42] Myers, J., and Rose, M. Post Office Protocol - Version 3. RFC 1939(Standard), May 1996. Updated by RFCs 1957, 2449.

[43] Port25. PowerMTA. Website. http://www.port25.com , Accessed 2008-08-29.

[44] Project, T. S. Sender Policy Framework. Website. http://www.openspf.org , Accessed 2008-08-10.

[45] Ramsdell, B. Secure/Multipurpose Internet Mail Extensions (S/MIME)Version 3.1 Message Specification. RFC 3851 (Proposed Standard), July 2004.

98 Bibliography

[46] Resnick, P. Internet Message Format. RFC 2822 (Proposed Standard),Apr. 2001.

[47] Santcroos, M., and Kolkman, O. DNS Threat Analysis. Tech. rep.,NLnet Labs, May 2007.

[48] Schneier, B. Attack Trees - Modeling security threats. Dr. Dobb’s Journal(Dec. 1999).

[49] .SE. Internetdagarna. Website. http://www.internetdagarna.se , Ac-cessed 2008-12-03.

[50] .SE. Om .SE. Website. http://www.iis.se/about , Accessed 2008-09-08.

[51] SecureWorks. DNS Cache Poisoning. Website. http://www.secureworks.com/research/articles/dns-cache-poisoning/ , Accessed 2008-08-09.

[52] Sendmail. Sendmail.org. Website. http://www.sendmail.org , Accessed2008-08-29.

[53] Siemborski, R., and Melnikov, A. SMTP Service Extension for Authen-tication. RFC 4954 (Proposed Standard), July 2007. Updated by RFC 5248.

[54] Trappe, W., and Washington, L. Introduction to cryptography: Withcoding theory, 2nd ed. Pearson Education, 2005. ISBN 9780131981997.

[55] Wikipedia. Domain name. Website. http://en.wikipedia.org/wiki/Domain_name , Accessed 2008-08-09.

[56] Wikipedia. Milter. Website. http://en.wikipedia.org/wiki/Milter ,Accessed 2008-08-26.

[57] Wong, M., and Schlitt, W. Sender Policy Framework (SPF) for Autho-rizing Use of Domains in E-Mail, Version 1. RFC 4408 (Experimental), Apr.2006.

Appendix A

Installation of necessarysoftware

The following commands and configuration parameters were the ones used in theserver set-up for the experiment with dkim and dkim milter, see chapter 4. Theoperating system in use is Ubuntu 8.04.1.

A.1 IP aliasingip aliasing is used to allow multiple ip addresses on one network interface card(nic). Follow these steps to have a permanent configuration that will not be lostafter a reboot of the system:

sudo pico /etc/network/interfaces

Append the information about eth0:1 and adjust the values according to the cur-rent network configuration. eth0 is the original nic:

auto eth0iface eth0 inet static

address 88.131.68.181netmask 255.255.255.240network 88.131.68.176broadcast 88.131.68.191gateway 88.131.68.177dns-nameservers 88.131.68.189dns-search blipp.com

auto eth0:1iface eth0:1 inet static

address 88.131.68.182netmask 255.255.255.240

99

100 Installation of necessary software

network 88.131.68.176broadcast 88.131.68.191gateway 88.131.68.177

Save the file and restart the network:

sudo /etc/init.d/networking restart

A.2 OpenSSLopenssl is required when performing cryptographic operations. Download thelatest release from www.openssl.org and install it.

tar -xzf openssl-0.9.8h.tar.gzcd openssl-0.9.8hmake clean./config shared --prefix=/usr/local/openssl-0.9.8h

--openssldir=/usr/local/openssl-0.9.8hmakesudo make install

The soft links to the directories are needed so that other application can easierfind this library.

sudo ln -s /usr/local/openssl-0.9.8h /usr/local/opensslsudo ln -s /usr/local/openssl-0.9.8h /usr/local/sslsudo ln -s /usr/local/ssl/bin/openssl /usr/bin/opensslsudo ln -s /usr/local/ssl/bin/c_rehash /usr/bin/c_rehashsudo ln -s /usr/local/ssl/include/openssl /usr/include/openssl

Bind will not find the soft links to the library and thus are the hard links used.

sudo ln /usr/local/ssl/lib/libcrypto.a /usr/lib/libcrypto.asudo ln /usr/local/ssl/lib/libcrypto.so.0.9.8

/usr/lib/libcrypto.so.0.9.8sudo ln /usr/local/ssl/lib/libssl.a /usr/lib/libssl.asudo ln /usr/local/ssl/lib/libssl.so.0.9.8

/usr/lib/libssl.so.0.9.8sudo ln /usr/lib/libssl.so.0.9.8 /usr/lib/libssl.so.0sudo ln /usr/lib/libssl.so.0 /usr/lib/libssl.sosudo ln /usr/lib/libcrypto.so.0.9.8 /usr/lib/libcrypto.so.0sudo ln /usr/lib/libcrypto.so.0 /usr/lib/libcrypto.so

A.3 Key generationSome asymmetric keys are needed to be generated. They will be used in differentparts of the system.

A.3 Key generation 101

A.3.1 DKIMFirst generate the private key and then the public key.

sudo mkdir /var/cache/dkimsudo openssl genrsa -out /var/cache/dkim/ex1.key.pem 1024sudo openssl rsa -in /var/cache/dkim/ex1.key.pem

-out /var/cache/dkim/ex1.public.pem-pubout -outform PEM

sudo openssl genrsa -out /var/cache/dkim/ex2.key.pem 1024sudo openssl rsa -in /var/cache/dkim/ex2.key.pem

-out /var/cache/dkim/ex2.public.pem-pubout -outform PEM

The base64 encoded string within the *.public.pem files are the keys published inthe dkim dns records.

A.3.2 DNSSECNote that Bind 9 must be installed to be able to access the dnssec-keygen com-mand. dnssec-keygen will also automatically generate the ds records that can bepublished by the parent domain for secure delegation.

RSASHA1

sudo dnssec-keygen -r /dev/urandom -a RSASHA1 -b 1024-n ZONE exempel1.tset.se

sudo dnssec-keygen -r /dev/urandom -f KSK -a RSASHA1 -b 1280-n ZONE exempel1.tset.se

sudo dnssec-keygen -r /dev/urandom -a RSASHA1 -b 1024-n ZONE exempel2.tset.se

sudo dnssec-keygen -r /dev/urandom -f KSK -a RSASHA1 -b 1280-n ZONE exempel2.tset.se

DSA

sudo dnssec-keygen -r /dev/urandom -a DSA -b 704-n ZONE exempel1.tset.se

sudo dnssec-keygen -r /dev/urandom -f KSK -a DSA -b 832-n ZONE exempel1.tset.se

sudo dnssec-keygen -r /dev/urandom -a DSA -b 704-n ZONE exempel2.tset.se

sudo dnssec-keygen -r /dev/urandom -f KSK -a DSA -b 832-n ZONE exempel2.tset.se


A.4 CertificatesFirst generate the root certificate.

sudo mkdir -p /etc/mail/certscd /etc/mail/certssudo openssl req -new -x509 -keyout cakey.pem

-out cacert.pem -days 3650

Then generate each of the needed certificates and sign them with the root cer-tificate. Certificates are needed for the secure connection with the imap and thesasl.

sudo openssl req -nodes -new -x509 -keyout sendmail.pem-out sendmail.pem -days 365

sudo openssl x509 -noout -text -in sendmail.pemsudo chmod 600 sendmail.pem

A.5 DNSDownload the latest release of Bind from www.isc.org/products/BIND/ and in-stall it.

tar -xzf bind-9.5.0-P1.tar.gzcd bind-9.5.0-P1./configure --with-openssl=/usr/local/openssl-0.9.8h

--prefix=/usr --sysconfdir=/etc/bind--localstatedir=/var/run/bind

makesudo make install

dnssec is not enabled by default. Edit the following file

pico /etc/bind/named.conf.options

Enable the dnssec option.

options {dnssec-enable yes;

}

Bind needs to know the zone information about the domains to be able to hostthem.

sudo pico /etc/bind/named.conf.local

Add the following information:

A.5 DNS 103

zone "exempel1.tset.se" {type master;file "/var/cache/bind/exempel1.tset.se.soa.signed";};

zone "exempel2.tset.se" {type master;file "/var/cache/bind/exempel2.tset.se.soa.signed";};

The location are to the signed zones files. The zone files contains the appropriateinformation about the domains including the public keys for dkim. They arecreated in this way:

sudo pico /var/cache/bind/exempel1.tset.se.soa


$ORIGIN exempel1.tset.se.$TTL 3600 ; 1 hour@ IN SOA mask.blipp.com. postmaster.tset.se. (

2008070403 ; serial10800 ; refresh (3 hours)3600 ; retry (1 hour)604800 ; expire (1 week)86400 ; minimum (1 day))

IN NS mask.blipp.com.IN NS boa.blipp.com.IN MX 10 mta.exempel1.tset.se.IN A 88.131.68.181

mta IN A 88.131.68.181ex1._domainkey IN TXT "k=rsa; t=y; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC6oekzH849jUK1EYJnfUM72OlhpaTxqBhvNu3UTGsbRywFWBHCPfoeHAZKnYhN+pLAXuJ49oUNO1kybAqUfxPMOpTbupY0zVdaJCtcMHi7j7rFgSrRi8nH55Frhq4aiS00ocdw1po0p72c7TkTNm5E1Q2jZ4pGpjEXJtjzb9YckwIDAQAB"$include Kexempel1.tset.se.+005+15045.key ; ZSK$include Kexempel1.tset.se.+005+55936.key ; KSK

The same procedure for domain number two.

sudo pico /var/cache/bind/exempel2.tset.se.soa


$ORIGIN exempel2.tset.se.$TTL 3600 ; 1 hour


@ IN SOA mask.blipp.com. postmaster.tset.se. (2008070403 ; serial10800 ; refresh (3 hours)3600 ; retry (1 hour)604800 ; expire (1 week)86400 ; minimum (1 day))

IN NS mask.blipp.com.IN NS boa.blipp.com.IN MX 10 mta.exempel2.tset.se.IN A 88.131.68.182

mta IN A 88.131.68.182ex2._domainkey IN TXT "k=rsa; t=y; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCnp9BmbPUEH16mIAL6mgvHHSUccvyn5uMMOcX29g7RgzuhXFwhAioAG2++LKjLdIa7f9t839nA9GTUkWEjg1GnLSOo+1gKDEjmiGzul2VAKcR96Zd/2nwsts0I7cd6WTYbuEInfWsEmdZPHqP9tL3HMORA3BWgqDw7hmxXfvwhVwIDAQAB"$include Kexempel2.tset.se.+005+60666.key ; ZSK$include Kexempel2.tset.se.+005+06901.key ; KSK

The next step is to sign the zones with the associated keys. The algorithm is eitherrsa or dsa and is chosen when the keys are generated.

sudo dnssec-signzone -r /dev/urandom -o exempel1.tset.se -kKexempel1.tset.se.+005+55936 exempel1.tset.se.soaKexempel1.tset.se.+005+15045

sudo dnssec-signzone -r /dev/urandom -o exempel2.tset.se -kKexempel2.tset.se.+005+06901 exempel2.tset.se.soaKexempel2.tset.se.+005+60666

Restart the dns server.

sudo /etc/init.d/bind9 restart

NOTE: Reverse dns is the processes of finding the domain name of an ip number.This is needed to some of the functionalities on the system to have proper function-ality. This was already fixed by the parent dns tset.se and thus not implementedin the files above. The reverse dns can be tested by:

nslookup 88.131.68.181

A.6 DKIM Milterdkim milter depends on the BerkeleyDB. Install it with this command:

sudo apt-get install db4.6-util libdb4.6 libdb4.6-dev

A.6 DKIM Milter 105

The patch to dkim milter also depends on the Unbound library. Download it fromwww.unbound.net.

tar -xzf unbound-1.0.2.tar.gzcd unbound-1.0.2./configuremakesudo make install

Then you have to download dkim milter 2.6.0 from http://downloads.sourceforge.net/dkim-milter/dkim-milter-2.6.0.tar.gz and patch it. The patch is neededto activate the dnssec functionality and can be found at http://opensource.iis.se. (dnssec is now available in dkim milter as of beta release for version2.8.0 and thereby is no patching needed.)

tar -xzf dkim-milter-2.6.0.tar.gzpatch -p0 < dkim-milter-dnssec-07.patchcd dkim-milter-2.6.0

The installation process needs some configuration parameters. Open the configu-ration file

pico site.config.m4.dist

and add the following information. Adjust the paths to match the locations oflibmilter, libunbound and openssl:

APPENDDEF(‘bld_dkim_filter_INCDIRS’,‘-I/usr/include/libmilter ’)

APPENDDEF(‘bld_dkim_filter_LIBDIRS’, ‘-L/usr/lib ’)define(‘bld_USE_UNBOUND’, ‘true’)APPENDDEF(‘confINCDIRS’, ‘-I/usr/local/include ’)APPENDDEF(‘confLIBDIRS’, ‘-L/usr/local/lib ’)APPENDDEF(‘confLIBDIRS’, ‘-L/usr/local/ssl/lib ’)APPENDDEF(‘confINCDIRS’, ‘-I/usr/local/ssl/include/openssl ’)

Copy the installation file and install dkim milter.

cp site.config.m4.dist ./devtools/Site/site.config.m4./Buildsudo ./Build install

The dkim milter needs to be configured.

sudo pico /var/cache/dkim/dkim1.conf

The first domain uses the following information:


TAFile /var/cache/dkim/dkim-ta1Canonicalization relaxed/simpleDomain exempel1.tset.seKeyFile /var/cache/dkim/ex1.key.pemMode svQuarantine NoSelector ex1SignatureAlgorithm rsa-sha256Socket inet:8891@localhostSyslog YesInternalHosts /var/cache/dkim/dkim-hosts1ExternalIgnoreList /var/cache/dkim/dkim-hosts1AlwaysAddARHeader YesRemoveOldSignatures YesRemoveARFrom exempel1.tset.seRemoveARAll YesOmitHeaders "Return-Path, Received, Comments, Keywords, Bcc,

Resent-Bcc, DKIM-Signature, X-Spam-Status, X-Spam-Level,X-Spam-Checker-Version"

LogWhy Yes

The second domain is configured in the same way.

sudo pico /var/cache/dkim/dkim2.conf

The second domain uses the following information:

TAFile /var/cache/dkim/dkim-ta2Canonicalization relaxed/simpleDomain exempel2.tset.seKeyFile /var/cache/dkim/ex2.key.pemMode svQuarantine NoSelector ex2SignatureAlgorithm rsa-sha256Socket inet:8892@localhostSyslog YesInternalHosts /var/cache/dkim/dkim-hosts2ExternalIgnoreList /var/cache/dkim/dkim-hosts2AlwaysAddARHeader YesRemoveOldSignatures YesRemoveARFrom exempel2.tset.seRemoveARAll YesOmitHeaders "Return-Path, Received, Comments, Keywords, Bcc,

Resent-Bcc, DKIM-Signature, X-Spam-Status, X-Spam-Level,X-Spam-Checker-Version"

LogWhy Yes

A.6 DKIM Milter 107

The trust anchor files contains the trust anchors to the trusted zones. Each of thetest domains have its own trust anchor file. The swedish top domain is used in thiscase. The current trust anchor can be found on www.iis.se/domains/sednssec/publickey and the key is changed every year.

sudo pico /var/cache/dkim/dkim-ta1

se. IN DNSKEY 257 3 5AwEAAdKc1sGsbv5jjeJ141IxNSTdR+nbtFn+JKQpvFZETaY5iMutoyWHa+jCp0TBBAzB2trGHzdi7E55FFzbeG0r+G6SJbJ4DXYSpiiELPiu0i+jPp3C3kNwiqpPpQHWaYDS9MTQMu/QZHR/sFPbUnsK30fuQbKKkKgnADms0aXalYUuCgDyVMjdxRLz5yzLoaSO9m5ii5cI0dQNCjexvj9M4ec6woi6+N8v1pOmQAQ9at5Fd8A6tAxZI8tdlEUnXYgNwb8eVZEWsgXtBhoyAru7Tzw+F6ToYq6hmKhfsT+fIhFXsYso7L4nYUqTnM4VOZgNhcTv+qVQkHfOOeJKUkNB8Qc=

sudo pico /var/cache/dkim/dkim-ta2

se. IN DNSKEY 257 3 5AwEAAdKc1sGsbv5jjeJ141IxNSTdR+nbtFn+JKQpvFZETaY5iMutoyWHa+jCp0TBBAzB2trGHzdi7E55FFzbeG0r+G6SJbJ4DXYSpiiELPiu0i+jPp3C3kNwiqpPpQHWaYDS9MTQMu/QZHR/sFPbUnsK30fuQbKKkKgnADms0aXalYUuCgDyVMjdxRLz5yzLoaSO9m5ii5cI0dQNCjexvj9M4ec6woi6+N8v1pOmQAQ9at5Fd8A6tAxZI8tdlEUnXYgNwb8eVZEWsgXtBhoyAru7Tzw+F6ToYq6hmKhfsT+fIhFXsYso7L4nYUqTnM4VOZgNhcTv+qVQkHfOOeJKUkNB8Qc=

The host that are allowed to have its email signed is configured in the followingfiles:

sudo pico /var/cache/dkim/dkim-hosts1

88.131.68.181127.0.0.1

sudo pico /var/cache/dkim/dkim-hosts2

88.131.68.182127.0.0.1

Start dkim milter with these commands:

dkim-filter -x /var/cache/dkim/dkim1.confdkim-filter -x /var/cache/dkim/dkim2.conf


A.7 IMAPimap is needed for remote access to personal email. This is provided by theprogram Dovecot. It will allow users to login in with their password according tothe shadow file. Download it from www.dovecot.org.

sudo apt-get install libpam0g-dev

tar -xzf dovecot-1.1.1.tar.gzcd dovecot-1.1.1CPPFLAGS=-I/usr/local/openssl-0.9.8h/include/openssl

LDFLAGS=-L/usr/local/openssl-0.9.8h/lib ./configure--with-pam --with-shadow


Then copy and edit the configuration file.

sudo cp /usr/local/etc/dovecot-example.conf/usr/dovecot/dovecot.conf

pico /etc/dovecot/dovecot.conf

disable_plaintext_auth = yesprotocols = imapsssl_listen = *:993mail_location = maildir:~/Maildirssl_cert_file = ’path to file’ssl_key_file = ’path to file’

The mail accounts and the corresponding users needs to be created.

sudo adduser test1sudo adduser test2

Finally start the program.

sudo dovecot

A.8 SASLsasl will allow remote users to send email through the mail server. Install theservice with this command:

sudo apt-get install sasl2-bin libsasl2-dev libsasl2-2libsasl2-modules libsasl2-modules-gssapi-mitlibsasl2-modules-ldap libsasl2-modules-otplibsasl2-modules-sql

A.8 SASL 109

Activate the daemon and the correct mechanism.

pico /etc/default/saslauthd

START=yesMECHANISMS="sasldb"

Postfix gets the configuration parameters for sasl from a file.

sudo mkdir /etc/postfix/sasl/sudo pico /etc/postfix/sasl/smtpd.conf

pwcheck_method: saslauthdmech_list: LOGIN PLAINsasldb_path: /var/spool/postfix/etc/sasldb2

The login credentials associated with the Postfix mail server.

sudo saslpasswd2 -a smtpd -c -u exempel1.tset.se test1sudo mv /etc/sasldb2 /var/spool/postfix/etc/sasldb2sudo chown root:sasl /var/spool/postfix/etc/sasldb2sudo chmod 755 /var/spool/postfix/etc/sasldb2

Add the correct permissions to the directory.

sudo mkdir -p /var/spool/postfix/var/run/saslauthdsudo chown root:sasl /var/spool/postfix/var/run/saslauthdsudo chmod 755 /var/spool/postfix/var/run/saslauthd

Sendmail gets the sasl configuration from the following file.

pico /usr/lib/sasl2/Sendmail.conf

pwcheck_method: saslauthdmech_list: LOGIN PLAINsasldb_path: /etc/sasldb2

The login credentials associated with the Sendmail mail server.

sudo saslpasswd2 -a Sendmail -c -u exempel2.tset.se test2

Start the daemon.

sudo /etc/init.d/saslauthd start

Add the correct permissions to the daemon so that Sendmail will find it.

sudo chown smmsp:smmsp /var/run/saslauthd


A.9 PostfixDownload the latest version of the Postfix mail server from www.postfix.org andinstall it.

tar -xzf postfix-2.5.2.tar.gzcd postfix-2.5.2make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL

-I/usr/include/sasl -DUSE_TLS" AUXLIBS="-L/usr/lib/sasl2-lsasl2 -lssl -lcrypto"


The configuration of Postfix.

pico /etc/postfix/main.cf

# TLS parameterssmtpd_tls_key_file = /etc/postfix/ssl/smtpd.pemsmtpd_tls_cert_file = /etc/postfix/ssl/smtpd.pemsmtpd_tls_CAfile = /etc/postfix/ssl/cacert.pemsmtpd_use_tls=yessmtpd_tls_session_cache_database =

btree:${queue_directory}/smtpd_scachetls_random_source = dev:/dev/urandom

smtp_tls_note_starttls_offer = nosmtp_use_tls = no

# See /usr/share/doc/postfix/TLS_README.gz in the# postfix-doc package for# information on enabling SSL in the smtp client.

myhostname = exempel1.tset.sealias_maps = hash:/etc/postfix/aliasesalias_database = hash:/etc/postfix/aliasesmyorigin = exempel1.tset.semydestination = exempel1.tset.semynetworks = 88.131.68.181/32, 127.0.0.0/8home_mailbox = Maildir/mailbox_command = procmail -a "$EXTENSION"mailbox_size_limit = 0recipient_delimiter = +inet_interfaces = $myhostname

smtpd_sasl_auth_enable = yes

A.10 Sendmail 111

smtpd_helo_restrictions =permit_mynetworkspermit_sasl_authenticatedreject_invalid_hostnamereject_non_fqdn_hostname

smtpd_recipient_restrictions =permit_mynetworkspermit_sasl_authenticatedreject_unauth_destination

smtpd_sasl_path = smtpdbroken_sasl_auth_clients = yessmtpd_sasl_security_options = noanonymoussmtpd_sasl_local_domain = $myhostname

smtpd_sasl_authenticated_header = yes

smtpd_milters = inet:localhost:8891non_smtpd_milters = inet:localhost:8891

milter_connect_macros = b j _ {daemon_name} {if_name} {if_addr}

Then start the mail server.

sudo /usr/sbin/postfix start

A.10 SendmailRemember to move Postfix’s version of sendmail from /usr/sbin/sendmail to/usr/local/sbin/sendmail and change the paths in the start script for Postfix.Sendmail will compile a new version of /usr/sbin/sendmail. Download the lat-est Sendmail from www.sendmail.org and install.

tar -xzf sendmail.8.14.3.tar.gzcd sendmail-8.14.3/devtools/Sitecp site.config.m4.sample site.config.m4

Edit the installation script. Add the correct paths to the libraries.

pico site.config.m4

APPENDDEF(‘confENVDEF’,‘-DSTARTTLS’)APPENDDEF(‘confLIBS’, ‘-lssl -lcrypto’)APPENDDEF(‘confLIBDIRS’, ‘-L/usr/local/ssl/lib

-R/usr/local/ssl/lib’)APPENDDEF(‘confINCDIRS’, ‘-I/usr/local/ssl/include/openssl’)


APPENDDEF(‘confENVDEF’, ‘-DSASL=20122’)APPENDDEF(‘conf_sendmail_LIBS’, ‘-lsasl2’)APPENDDEF(‘confLIBDIRS’, ‘-L/usr/lib/sasl2 ’)APPENDDEF(‘confINCDIRS’, ‘-I/usr/include/sasl/ ’)

define(‘confEBINDIR’, ‘/usr/local/bin’)define(‘confMBINDIR’, ‘/usr/local/sbin’)define(‘confSBINDIR’, ‘/usr/local/sbin’)define(‘confUBINDIR’, ‘/usr/local/bin’)

Build and install Sendmail.

cd ../.../Buildsudo ./Build install

Add the correct permissions to the directories.

groupadd -g 25 smmspuseradd -u 25 -g 25 -d /var/spool/mqueue -s /dev/null smmspchown -R smmsp:smmsp /var/spool/clientmqueuechmod 770 /var/spool/clientmqueuechown -R smmsp:smmsp /var/spool/mqueuechmod 770 /var/spool/mqueuechgrp -R root /etc/mailchmod -R g+r /etc/mailchmod g+s /etc/mailchown root:smmsp /usr/local/sbin/sendmailchmod g+s /usr/local/sbin/sendmail

The target file must already exist and be world writable when creating the aliasdatabase. The source file’s timestamp must be more recent than the target’stimestamp.

touch /etc/mail/aliases.dbchmod 666 /etc/mail/aliases.db/usr/local/bin/newaliases /etc/mail/aliases

Add the correct configuration to Sendmail.

cd ./cf/cfpico sendmail.mc

divert(0)dnlVERSIONID(‘$Id: generic-linux.mc,v 8.1

1999/09/24 22:48:05 gshapiro Exp $’)OSTYPE(linux)dnl

A.10 Sendmail 113

DOMAIN(generic)dnl

FEATURE(‘no_default_msa’)dnlDAEMON_OPTIONS(‘Name=exempel2.tset.se,

Addr=mta.exempel2.tset.se, Port=smtp’)dnlCLIENT_OPTIONS(‘Name=exempel2.tset.se,

Addr=mta.exempel2.tset.se’)dnl

INPUT_MAIL_FILTER(‘dkim-filter’, ‘S=inet:8892@localhost’)dnldefine(‘confINPUT_MAIL_FILTERS’, ‘dkim-filter’)dnl

define(‘confRUN_AS_USER’, ‘smmsp:smmsp’)dnldefine(‘confQUEUE_FILE_MODE’, ‘0660’)dnldefine(‘confDOMAIN_NAME’, ‘exempel2.tset.se’)dnldefine(‘confDONT_PROBE_INTERFACES’,‘true’)dnl

define(‘confAUTH_OPTIONS’, ‘A p’)dnldefine(‘confAUTH_MECHANISMS’, ‘LOGIN PLAIN’)dnlTRUST_AUTH_MECH(‘LOGIN PLAIN’)dnl

define(‘confCACERT_PATH’, ‘/etc/mail/certs’)dnldefine(‘confCACERT’, ‘/etc/mail/certs/cacert.pem’)dnldefine(‘confSERVER_CERT’, ‘/etc/mail/certs/sendmail.pem’)dnldefine(‘confSERVER_KEY’, ‘/etc/mail/certs/sendmail.pem’)dnldefine(‘confTLS_SRV_OPTIONS’, ‘V’)dnl

FEATURE(‘virtuser_entire_domain’)dnlFEATURE(‘virtusertable’,‘hash -o /etc/mail/virtusertable’)dnlFEATURE(‘access_db’,‘hash -T<TMPF> -o /etc/mail/access.db’)dnl

FEATURE(local_procmail)dnlMAILER(smtp)dnl

LOCAL_CONFIGESASL_PATH=/usr/local/lib/sasl2

pico submit.mc

divert(0)dnlVERSIONID(‘$Id: submit.mc,v 8.14 2006/04/05 05:54:41 ca Exp $’)define(‘confCF_VERSION’, ‘Submit’)dnldefine(‘__OSTYPE__’,‘’)dnldefine(‘_USE_DECNET_SYNTAX_’, ‘1’)dnldefine(‘confTIME_ZONE’, ‘USE_TZ’)dnldefine(‘confDONT_INIT_GROUPS’, ‘True’)dnldnl


define(‘confDOMAIN_NAME’, ‘exempel2.tset.se’)dnlFEATURE(‘msp’, ‘[88.131.68.182]’)dnl

Build and copy the configuration files.

./Build sendmail.cf

./Build submit.cfsudo cp sendmail.cf /etc/mail/sendmail.cfsudo cp submit.cf /etc/mail/submit.cf

Start the Sendmail daemon.

sudo /etc/init.d/sendmail start

A.11 ProcmailProcmail is used as the MDA on the mail servers. It needs to be configured to usethe Maildir delivery option.

pico /etc/procmailrc

DEFAULT="$HOME/Maildir/"MAILDIR="$HOME/Maildir/"

A.12 MasqueradeMasquerade will change the source address of an email when activated. To activateit do the following:

A.12.1 SendmailAdd the text below to sendmail.mc and repeat the configuration steps in sec-tion A.10.

MASQUERADE_AS(‘exempel1.tset.se’)dnlMASQUERADE_DOMAIN(‘exempel2.tset.se’)dnl

A.12.2 PostfixEdit the Postfix configuration file with a new line.

sudo pico /etc/postfix/main.cf

smtp_generic_maps = hash:/etc/postfix/generic

Create and add information to the generic file.

A.13 Alias 115

sudo pico /etc/postfix/generic

@exempel1.tset.se @exempel2.tset.se

Create the database file and restart Postfix.

sudo postmap /etc/postfix/genericsudo /usr/sbin/postfix restart

A.13 AliasAliasing will create alternative virtual addresses to the real email accounts.

A.13.1 SendmailCreate and add information to the alias file.

sudo pico /etc/mail/aliases

loc: test2ext: [email protected]: extextloc: [email protected]: [email protected]: loc

Create the database file and restart Sendmail

sudo touch aliases.dbsudo chmod 666 aliases.dbsudo makemap hash /etc/mail/aliases.db < /etc/mail/aliasessudo /etc/init.d/sendmail restart

A.13.2 PostfixCreate and add information to the alias file.

sudo pico /etc/postfix/aliases

loc: test1ext: [email protected]: extextloc: [email protected]: [email protected]: loc

Create the database file and restart Postfix.

sudo postalias /etc/postfix/aliasessudo /usr/sbin/postfix restart


A.14 Forward in the MTAForward will send the email user’s messages to another location.

sudo pico /home/test22/.forward

[email protected]

A.15 Forward in the MDAThe email can be forwarded by Procmail. The file in the user’s home directory isconfigured differently depending on which MTA to use.

sudo pico /home/test11/.procmailrc

PATH=/usr/sbin:/usr/binMAILDIR=$HOME/Maildir/SENDMAIL=/usr/sbin/sendmail:0! [email protected]

or

sudo pico /home/test21/.procmail

PATH=/usr/local/bin:/usr/local/sbinMAILDIR=$HOME/Maildir/SENDMAIL=/usr/local/sbin/sendmail:0! [email protected]

UpphovsrättDetta dokument hålls tillgängligt på Internet — eller dess framtida ersättare —under 25 år från publiceringsdatum under förutsättning att inga extraordinäraomständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för icke-kommersiell forskning och för undervisning. Överföring av upphovsrätten vid ensenare tidpunkt kan inte upphäva detta tillstånd. All annan användning av doku-mentet kräver upphovsmannens medgivande. För att garantera äktheten, säker-heten och tillgängligheten finns det lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsmani den omfattning som god sed kräver vid användning av dokumentet på ovan be-skrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan formeller i sådant sammanhang som är kränkande för upphovsmannens litterära ellerkonstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se för-lagets hemsida http://www.ep.liu.se/

CopyrightThe publishers will keep this document online on the Internet — or its possi-ble replacement — for a period of 25 years from the date of publication barringexceptional circumstances.

The online availability of the document implies a permanent permission foranyone to read, to download, to print out single copies for his/her own use andto use it unchanged for any non-commercial research and educational purpose.Subsequent transfers of copyright cannot revoke this permission. All other uses ofthe document are conditional on the consent of the copyright owner. The publisherhas taken technical and administrative measures to assure authenticity, securityand accessibility.

According to intellectual property law the author has the right to be mentionedwhen his/her work is accessed as described above and to be protected againstinfringement.

For additional information about the Linköping University Electronic Pressand its procedures for publication and for assurance of document integrity, pleaserefer to its www home page: http://www.ep.liu.se/

c© Rickard Bondesson

Institutionen för datavetenskap - DiVA portal128399/FULLTEXT01.pdf · 2008-12-16 · SE-581 83...

Documents

Transcript of Institutionen för datavetenskap - DiVA portal128399/FULLTEXT01.pdf · 2008-12-16 · SE-581 83...