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
Linköping University
Department of Computer and Information Science
Final Thesis
Deployment and analysis of DKIM with DNSSEC
by
Rickard Bondesson
LIU-IDA/LITH-EX-A--08/055--SE
2008-11-20
Supervisor: Patrik Wallström .se
Examiner: Juha Takkinen
Avdelning, Institution Division, Department
Division for Database and Information Technique Department of Computer and Information Science Linköping University
SE-581 83 Linköping, Sweden
Datum Date 2008-11-20 Språk Language Svenska/Swedish Engelska/English Rapporttyp Report 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 — ISRN
LIU-IDA/LITH-EX-A--08/055--SE Serietitel och serienummer
Title of series, numbering
ISSN —
Titel Title
Driftsättning och analys av DKIM med DNSSEC Deployment and analysis of DKIM with DNSSEC
Författare Author
Rickard Bondesson
Sammanfattning Abstract
As the email system is widely used as a communication channel, and often is crucial for the performance of organizations, it is important that users can trust the content of what is being delivered to them. A standard called DomainKeys Identified Mail (dkim) has been developed by the ietf to solve the problem with authentication and integrity, by using digital signatures.
This master’s thesis goal is to evaluate the solution where an implementation of dkim is extended with dnssec validation. dnssec is a solution which secures, among other, the mapping between ip addresses and domain names. The implementation of dkim is deployed and evaluated with function testing, domain testing, threat analysis, and interoperability testing.
dkim does not need any new public-key infrastructure, thus inflicting less cost on the deployment compared with other cryptographic solutions such as s/mime and 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 the recipient of whether a domain is signing its email or not and thereby a possibility to detect any unauthorized signature removal. A further problem is that mailing lists 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 mailing lists.
Nyckelord
Abstract
As the email system is widely used as a communication channel, and often is crucial for the performance of organizations, it is important that users can trust the content of what is being delivered to them. A standard called DomainKeys
Identified Mail (dkim) has been developed by the ietf to solve the problem with
authentication and integrity, by using digital signatures.
This master’s thesis goal is to evaluate the solution where an implementation of 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, domain testing, threat analysis, and interoperability testing.
dkim does not need any new public-key infrastructure, thus inflicting less cost on the deployment compared with other cryptographic solutions such as s/mime and 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 the recipient of whether a domain is signing its email or not and thereby a possibility to detect any unauthorized signature removal. A further problem is that mailing lists 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 mailing lists.
Abbreviations
The following abbreviations will be used in this report.
.SE . . . The Internet Infrastructure Foundation ADSP . . . Author Domain Signing Practices AES . . . Advanced Encryption Standard CA . . . Certificate Authority
CIA . . . Confidentiality, Integrity, and Availability CNAME . . . Canonical Name
DES . . . Digital Encryption Standard DFD . . . Data-Flow Diagrams
DKIM . . . DomainKeys Identified Mail DNS . . . Domain Name System DNSSEC . . . DNS Security Extensions DoS . . . Denial of Service
DS . . . Delegation Signer Email . . . Electronic mail I-D . . . Internet Draft
IAB . . . Internet Architecture Board IETF . . . Internet Engineering Task Force IMAP . . . Internet Message Access Protocol IP . . . Internet Protocol
IPsec . . . Internet Protocol Security IRTF . . . Internet Research Task Force ISOC . . . Internet Society
ISP . . . Internet Service Provider KSK . . . Key Signing Key
LiU . . . Linköping University MD5 . . . Message Digest algorithm 5 MDA . . . Mail Delivery Agent Milter . . . Mail filter
MIME . . . Multipurpose Internet Mail Extensions MIPA . . . Mutual Internet Practices Association MSA . . . Mail Submission Agent
MTA . . . Mail Transfer Agent vii
MUA . . . Mail User Agent NIC . . . Network Interface Card NSEC . . . Next Secure
PGP . . . Pretty Good Privacy POP . . . Post Office Protocol
PRA . . . Purported Responsible Address RFC . . . Request for Comments
RIPEMD . . . RACE Integrity Primitives Evaluation Message Digest RR . . . Resource Record
S/MIME . . . Secure MIME
SASL . . . Simple Authentication and Security Layer SHA . . . Secure Hash Algorithm
SMTP . . . Simple Mail Transfer Protocol
SMTP-AUTH . . . . SMTP Service Extension for Authentication SPF . . . Sender Policy Framework
TCP . . . Transmission Control Protocol TLD . . . Top-level domain
TLS . . . Transport Layer Security TTL . . . Time to Live
UDP . . . User Datagram Protocol ZSK . . . Zone Signing Key
Contents
1 Introduction 1 1.1 Background . . . 1 1.2 Problem discussion . . . 2 1.3 Purpose . . . 2 1.4 Goals . . . 2 1.5 Delimitations . . . 3 1.6 Target audience . . . 3 1.7 Reference literature . . . 3 1.8 Outline . . . 3 1.9 Typographic conventions . . . 4 2 Background 5 2.1 History of the Internet . . . 52.1.1 Internet Protocol . . . 5
2.1.2 Applications . . . 6
2.2 About the Internet Society . . . 6
2.2.1 Organization . . . 6
2.2.2 Documents . . . 7
2.3 Domain name to IP address . . . 7
2.3.1 Architecture . . . 7
2.3.2 DNS security risks . . . 9
2.3.3 Domain Name System Security Extensions . . . 10
2.4 The email system and its protocols . . . 10
2.4.1 Internet Message Format . . . 11
2.4.2 Multipurpose Internet Mail Extensions . . . 12
2.4.3 Simple Mail Transfer Protocol . . . 12
2.4.4 Post Office Protocol . . . 12
2.4.5 Internet Message Access Protocol . . . 12
2.4.6 Architecture . . . 12
2.4.7 Security . . . 13
2.4.8 Spoofing . . . 13 ix
3 Analysis of email security 15
3.1 Email spoofing . . . 15
3.2 Computer security . . . 15
3.2.1 Cryptology . . . 17
3.2.2 Cryptographic hash functions . . . 17
3.2.3 Digital signatures . . . 17
3.3 Email technologies . . . 18
3.3.1 Sender Policy Framework . . . 18
3.3.2 Author Domain Signing Practices . . . 18
3.3.3 SenderID . . . 18
3.3.4 Black-/grey-/whitelisting . . . 19
3.3.5 Secure MIME . . . 19
3.3.6 Pretty Good Privacy . . . 20
3.3.7 DomainKeys Identified Mail . . . 20
3.3.8 DomainKeys . . . 20
3.4 More about DKIM . . . 20
3.4.1 Canocalization . . . 20
3.4.2 Signing . . . 21
3.4.3 DNS record . . . 22
3.4.4 Verification . . . 22
3.4.5 The need for DNSSEC . . . 23
4 Deployment and testing of DKIM 25 4.1 Server set-up . . . 25
4.1.1 The lab environment . . . 25
4.1.2 Supported mail servers . . . 26
4.1.3 Installation of necessary software . . . 26
4.2 Testing of DKIM Milter . . . 29
4.2.1 Function testing . . . 29 4.2.2 Domain testing . . . 30 4.2.3 Variables to test . . . 30 4.2.4 Test cases . . . 31 4.2.5 Test results . . . 35 5 Threat analysis 39 5.1 Threats . . . 39 5.2 Threat models . . . 40 5.2.1 Data-flow diagram . . . 40 5.2.2 Attack trees . . . 40 5.2.3 Misuse cases . . . 52 6 Interoperability testing 55 6.1 Basic email routing . . . 55
6.1.1 Test cases . . . 56
6.1.2 Test results . . . 61
Contents xi 6.2.1 Test cases . . . 68 6.2.2 Test results . . . 71 6.3 Other implementations . . . 75 6.3.1 Test cases . . . 75 6.3.2 Test results . . . 78
7 Statistics on DKIM usage 81 7.1 Measuring DKIM usage . . . 81
7.1.1 Email in transit . . . 81
7.1.2 DKIM DNS records . . . 82
7.2 Graphs on DKIM usage . . . 83
7.2.1 At an email server . . . 83
7.2.2 Among the Swedish domains . . . 83
8 Summary and Conclusions 87 8.1 DKIM installation and testing . . . 87
8.2 DKIM Milter . . . 88
8.3 Deployment of DKIM . . . 88
8.4 Interoperability tests . . . 89
8.5 Threats . . . 89
8.6 Statistics of current DKIM usage . . . 90
8.7 Demonstrations and presentations . . . 90
8.8 Recommendations . . . 91
9 Future work 93 Bibliography 95 A Installation of necessary software 99 A.1 IP aliasing . . . 99
A.2 OpenSSL . . . 100
A.3 Key generation . . . 100
A.3.1 DKIM . . . 101
A.3.2 DNSSEC . . . 101
A.4 Certificates . . . 102
A.5 DNS . . . 102
A.6 DKIM Milter . . . 104
A.7 IMAP . . . 108 A.8 SASL . . . 108 A.9 Postfix . . . 110 A.10 Sendmail . . . 111 A.11 Procmail . . . 114 A.12 Masquerade . . . 114 A.12.1 Sendmail . . . 114 A.12.2 Postfix . . . 114 A.13 Alias . . . 115 A.13.1 Sendmail . . . 115
A.13.2 Postfix . . . 115
A.14 Forward in the MTA . . . 116
A.15 Forward in the MDA . . . 116
List of Figures
2.1 The organization hierarchy of ISOC. . . 62.2 A typical lookup of a domain name. . . 9
2.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. . . 41
5.2 Signing DFD. . . 41
5.3 Verifying DFD. . . 41
5.4 Simple attack tree. . . 42
5.5 Attack tree 1. . . 43
5.6 Attack tree 2. . . 46
5.7 Attack tree 3. . . 50
5.8 Misuse of email signing. . . 53
5.9 Misuse of email verification. . . 54
6.1 Description of test scenario 1. . . 57
6.2 Description of test scenario 2. . . 58
7.1 DKIM statistics 1. . . 84
7.2 DKIM statistics 2. . . 85
Chapter 1
Introduction
This chapter will give an introduction to this thesis. The background and the purpose of this thesis define why this thesis exists and are the foundation of the main thesis goal. A clear view of what to expect of this thesis is given by defining the goals and the delimitations.
1.1
Background
The Internet Infrastructure Foundation (.se) is located in Stockholm and is
re-sponsible for the maintenance and administration of the Swedish national domain name registrar [50]. One of their main objectives is to actively contribute to the Internet’s development in Sweden. They are working at the frontier by looking at what technologies and practices are being developed and deployed on the market and thereby continually starting new projects. The projects are meant to raise the awareness of new technologies and practices or pushing the technologies and practices closer to the end-users and the Internet service providers.
As the email system is widely used as a communication channel, and often is crucial for the performance of organizations, it is important that users can trust the content of what is being delivered to them. This can be summarized into two questions: “Is the information correct?”, integrity, and “Who has written this information?”, 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 a private key, thereby making it possible to detect any unauthorized modifications to the email. This signature is attached to the email header and then the message is delivered to the recipient. The recipient verifies the header and the body by comparing it with the hash value and the sender’s public key, which is stored in the 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 dkim milter that can be plugged into the mail servers. The idea is to make this process
fully automated and transparent to the end-users. dkim relies on the security of 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 the dkim milter even further, by creating a patch to dkim milter that verifies the dns record by using the functionality of DNS Security Extension (dnssec) to protect the 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 discussion
Before offering the solution with dkim and dnssec to the market, .se have to verify the functionality and compatibility of the extended dkim milter. The reason why a server implementation, and not an end-user implementation, of dkim was chosen to be extended with dnssec support is because not many home routers have support for dnssec [1]. Most of the end-user implementation would thus not gain anything by the dnssec extension. The second reason is the fairly low usage of dkim. Not many big operators are using dkim and they need to be involved before any end-users will have a gain of it.
1.3
Purpose
The purpose of this master’s thesis is to evaluate the solution where dnssec signs the keys that dkim uses to validate the sender of an email.
1.4
Goals
From the problem discussion and the purpose of this thesis has the following goals been drawn:
• A background study comparing relevant existing technologies. Examples of
relevant technologies are spf and s/mime. spf verifies that the sender of an email is allowed to use a specific email domain [57] and s/mime connects the content 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 example
attack tree, and also look for any security risks.
• Do interoperability tests with, among others, spf and s/mime to see if they
can coexist with dkim without interrupting each other.
1.5 Delimitations 3
• Prepare a demonstration and presentation that will be held at three seminars
and at the conference Internetdagarna, which occurs on 21-22 October 2008 [49].
1.5
Delimitations
To 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 similar
technologies. The descriptions of the other technologies are used to put dkim in 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 the
laboratory equipment.
• dnssec as a system is not evaluated, but it is involved in the interoperability
testing with different set-ups.
1.6
Target audience
The intended readers of this report are mainly the Research and Development team at .se, students and teachers in computer science at Linköping University, and system administrators. Anyone not in this group may also read this report providing that they possess basic computer knowledge. This report is written so that the enumerated groups above can understand the content of this report even though they are not familiar with the topic.
1.7
Reference literature
The information written in this thesis is based on computer security books, com-puter networking books, documents published by the Internet Engineering Task Force, and technical articles. Some websites are used as reference and they are from well-known and trusted sites.
1.8
Outline
The 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 reader interested 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 presents how the system is deployed and what the test results are. This is followed by a threat analysis of the patched dkim milter, chapter 5, and how interoperable it is
with other similar technologies, chapter 6. The current use of dkim is presented in chapter 7. The last chapters of the report contain the conclusions and future work.
1.9
Typographic conventions
All acronyms are spelled out when they are used for the first time. They can also be found under the chapter Abbreviations, page vii.
Chapter 2
Background
This chapter serves as the foundation of knowledge for the report. It is needed for the basic understanding of how the different systems interconnect with each other and what motivates the different solutions for email authentication. The journey is started with the birth of the Internet and the administration surrounding the maintenance and future development of the Internet and is finished with how its different components work.
2.1
History of the Internet
The Internet was beginning to see its birth when Vinton Cerf and Robert Kahn started to interconnect the different types of computer networks in 1972 [34]. In essence creating a network of networks and the term internetting was coined after their work. The three key protocols of the Internet, Transmission Control
Protocol (tcp), User Datagram Protocol (udp), and Internet Protocol (ip), were
in operation by the 1980s.
2.1.1
Internet Protocol
The 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 that ip does not provide any error checking or tracking, meaning that the packets can arrive 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 and tcp.
Each host on the Internet needs a unique identifier so that the ip packet can be delivered 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 four billion different addresses [34]. However, this address space is soon depleted due to the enormous growth of the Internet. The next version of ip, ipv6, has an address space of 128 bits or approximately 3.4 ∗ 1038 different addresses.
2.1.2
Applications
It was not difficult to keep track of the different hosts when the Internet only had a few of them connected to it, but with the rapidly expansion this soon became impossible. The need for practical applications and tools were needed to organize and 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 Society
A standard organization is needed to support the development of the Internet, because the Internet is a network of networks operated by different companies and organizations, which can make the interoperability slightly more complicated. The different standards organizations of the Internet were gathered under one umbrella organization called Internet Society (isoc) in 1992 [10]. isoc’s main objective is to provide support for the Internet standards process by acting as their legal umbrella and administrative home.
2.2.1
Organization
isoc 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 architectural
advice and oversight to the different branches in the isoc. The branches consist of 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.
IETF
IRTF
IAB
ISOC
2.3 Domain name to IP address 7
2.2.2
Documents
The 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 represent other types of documents like a requirement document, an experimental standard, a policy, a white paper, or a process document. These standards are not enforced by 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 rfcs in the future. Any information from an i-d should be treated as work-in-progress since the documents are under constant reviewing and upgrading. Each i-d is valid 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 address
An ip address can be represented as a domain name, like www.google.com, with the help of the Domain Name System (dns). This is useful for an ordinary user because the domain name is more mnemonic than the ip address. The main objective 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 to the mail server of that specific domain. If a domain name is very long, it can be shortened by using the host aliasing.
2.3.1
Architecture
The domain names are created in a hierarchical fashion according to a specific scheme. The domain name in example 2.1 can be divided into three parts [55]:
• Top-level domain (tld) - se
The 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 (Address
and Routing Parameter Area).
• Second-level domain - tset.se
Next to the tld is the second-level domain. It is usually the name of the company, product, service, or a name suitable for that particular domain.
• Third-level domain - exempel1.tset.se
The hierarchy can extend to even lower level domains. It can be used to indicate the type of service provided by this domain name. Example
Example 2.1: Domain name
exempel1.tset.se
The dns system is a distributed and hierarchical database, designed to cope with the 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 to the dns system [6]. Each server is actually replicated into a cluster of servers and 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. They give direction to the correct authoritative dns server.
• Authoritative dns servers
Each organization that have a publicly accessible host on the Internet can provide 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 Internet
Service 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-level domain. A new question is directed to that top-level domain of where it can find the specific second-level domain. The final question is asked to the authoritative server of what ip address the host in question has.
It is not necessary that it works like this in the real world. Commonly used domain names are cashed for a limited time in the resolvers [34]. The address of the top-level domain could for example be cashed and then the resolver does not need 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.181
2.3 Domain name to IP address 9
Root
.se
tset.se
dns.ex.com
user.ex.com
1 2 3 4 5 6 7 8Figure 2.2. A typical lookup of a domain name.
2.3.2
DNS security risks
The dns system is a service that has been around for many years and vulnerabilities are inevitably found in the system and its protocols. There are several know classes of threats to the dns system [7]. More detailed information can be found in Threat
Analysis of the Domain Name System ( dns),RFC3833.
• Packet Interception
Is a form of man-in-the-middle attack where a third party intercepts the communication between the resolver and the name server. Unencrypted udp traffic makes this easy and an attacker can change the response to what ever it wants.
• id Guessing and Query Prediction
The communication mostly uses udp/ip and for an attacker is it fairly easy to generate a spoofed answer without looking at the communication between the resolver and the name server. The thing that makes the traffic unique is the id field in the dns header and what port the answer should go to. There are techniques, for example phase space analysis [51], that can predict these random values with high percentage.
• Name Chaining
Is a subset of an attack that is called Cache Poisoning. Possible with the aid of the previous attacks. There are several combinations of this attack,
but they all involve dns records that do not contain an ip address but a regular 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 Server
The users trust its resolver to deliver the correct information, but this can be breached if the resolver decides to give faulty information.
• Denial of Service
The 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 with traffic and exhaust its resources, making it crash or unable to provide its services. The dns system could also be used as an amplifier for this kind of attack, because the response packets are larger than the query packet. This is done by having the source address of the queering host spoofed so that the dns server thinks the query is from the target of attack.
2.3.3
Domain Name System Security Extensions
The dns system is vulnerable to protocol attacks as mentioned in the previous section. This problem was addressed at an ietf meeting in November 1993 where the first organized work started on the Domain Name System Security Extentions (dnssec) [7]. The resolver can, by the help of public-key cryptology and digital signatures, detect any modifications by third parties on the information from the dns 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’s private key and the public key is published in the dnskey record. The resolver then simple validates the answer with a local copy of the public key. It is not practical 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 from the parent to the child zone. The resolvers then only need one key from each island-of-trust if this technique is used, because within these zone are there secure pointers to the other public keys. The idea is to have the dns system signed all the way up to the root zone, but to date only a few tlds like .se, .bg and .br are signed.
2.4
The email system and its protocols
The need for electronic communication between human beings started to grow with the use of mainframes and expansion of the computer networks. The computer scientists and engineers needed a way to easily communicate and coordinate their work 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 since not many of the computers, in the 1960s, were connected with each other. But the increased usage of computer networks made the email system evolve into a crucial tool 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 Format
The email system is divided into two parts; the message itself [46] and the delivery of the message [32]. The format of a message is quite similar to the real world example of a letter and its envelope. When sending a real letter, the message is put 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 message from point a to point b. The difference with the email message is that it consists of headers and a body, where the headers holds information about the message and the body contains the actual content. The equivalent to an envelope is created by the delivery system.
The Internet Message Format, RFC2822, specifies how the email message must be formatted [46]. The email message consists of 7-bit ascii characters and the body can also include a structured message according to the Multipurpose Internet
Mail Extensions ( mime) standard.
The first five lines, in example 2.3, is the header. The message body are the lines 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 message properties 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 email
Date: Mon, 23 Jun 2008 11:50:27 +0200 From: alice@exempel1.tset.se
Reply-To: alice@exempel1.tset.se To: bob@exempel2.tset.se
Subject: Meeting Hi again!
The meeting is cancelled due to sickness. Yours truly
2.4.2
Multipurpose Internet Mail Extensions
Only 7-bit ascii characters are allowed in the email message body [46]. This limits 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 the
Multipurpose Internet Mail Extensions (mime) [28]. mime gives the possibility to
encode arbitrary data in plain 7-bit ascii and allow multipart messages with the possibility to attach text, video, audio and other attachment to the message.
2.4.3
Simple Mail Transfer Protocol
The second part of the email system is the transportation system. It is defined by the Simple Mail Transfer Protocol (smtp) and its purpose is to transfer email to the correct destinations [32]. It is a simple text-based protocol which can only send messages from one host to another host, push, and not receive message from another host on demand, pull. To be able to retrieve a message from a server, a mail client needs to use protocols like pop or imap.
The way a smtp host determines the destination of an email is by looking at the email header [32]. The To: header of the email specifies the recipient and its domain. The ip address of the receiving smtp server is determined by doing a dns lookup of the recipient’s domain and the dns mx record of that domain. Thus creating a layer around the email similar to a real envelope.
2.4.4
Post Office Protocol
It is not often practical to deliver the email directly to the user since they might not be online or would like to access the mail box on different workstations. The mail is then stored on a server. There are several ways of accessing the mail box and the Post Office Protocol version 3 (pop) is one of them. The user connects and login to the server with the pop and retrieves the messages stored in the mail box [42]. Once an email is retrieved from the server it is permanently removed from the mail box and is only available on that workstation.
2.4.5
Internet Message Access Protocol
Another method of accessing the mail box is with Internet Message Access Protocol
version 4 (imap) [13]. The difference between imap and POP is that imap does
not remove the email from the mail box unless explicitly told so by the user. Only a copy of the message is sent to the user and thus making the server as the primary storage space of all the emails.
2.4.6
Architecture
The email system is built upon different servers and programs that interact with each other, see figure 2.3. The user uses a Mail User Agent (mua) to send and receive messages [24]. The mua is program accessible by the user. It could for example 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 a Mail 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 correct mta and is stored in a Mail Delivery Agent (mda) until the receiver wants to read it.
Internet
MTA
MTA/MDA
MUA/MSA
MUA
Figure 2.3. The delivery of an email through the email system.
2.4.7
Security
It is not good to have an open mail server where anyone can send an email through it, because this will allow spammers to send spam with the mail server as the originating server [8]. One solution is to only forward mail that has its origin within the internal network, but this leaves the server fairly open for abuse. Another solution would to only let authenticated users to send email through the mail server. 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. The passwords for pop, imap, and smtp-auth are usually sent in plain text [27]. An attacker could capture these passwords and replay them in his own session with the server. The protection is to encrypt the connection by using the Transport
Layer Security (tls) protocol [15].
2.4.8
Spoofing
The problem with the smtp standard is that it does not validate or authenticate the content of an email message when a message is received [8]. Normally does
the recipient and the sender addresses in the smtp header and the email header match each other. The recipient header in the smtp is needed to have the email delivered to the correct destination, but the email header can be spoofed by the sender without disturbing a simple email transaction. This makes it possible to craft an email that can make the recipient into believing that it is from someone else than the originating sender.
Chapter 3
Analysis of email security
There are several ways to fight spam and forged emails but the focus of this master’s thesis is on automated filters and add-ons to the email system. The technologies within this area handle and solve different parts of the problems.
3.1
Email spoofing
It is, as stated in the previous chapter, fairly easy to create an email that looks like it is from a source other than the originating one. A financial and personal integrity problem is the phishing attacks related to email spoofing [35]. Spammers can create a faked message telling the recipient to reveal personal information like credit card numbers, user names, and passwords. This is done by spoofing the origin of the email so that it looks like it is coming from the targeted site or company. The message often has some kind of bate telling the user that is must take some urgent actions or else something bad will happen. This pressure on the users will make them more likely to follow the instructions in the message.
A user must take some things in consideration when reviewing an email. The first task is to identify the author of the email and figure out if that is the correct identity. The second task is to validate the information in the message, to see if the text is written by the author and that nothing is missing from the original message. This can be done in two ways; either by doing some logical thinking or with the aid of extensions to the email system.
3.2
Computer security
Before 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 a computer system.”
Or as:
“The measures we can take to deal with intentional actions by parties behaving in some unwelcome fashion.”
One of the core principals of computer security is the cia criteria [21]. cia is an abbreviation for confidentiality, integrity, and availability. There are also some other important keywords like authentication, non-repudiation, authorization, and
accountability. • Confidentiality
Confidentiality is the act of only revealing the information to authorized entities. This can be achieved by restricted access and/or encryption of the information.
• Integrity
Integrity is about making sure that the information is only modified by authorized entities. This often involves means of detecting any modifications by non-authorized entities.
• Availability
Availability is achieved when the information is accessible and usable when it is needed by an authorized entity.
• Authentication
Authentication is when an entity proves that it is who it says it is. The entity can do this by presenting something that only it have, knows, or are like driver license, password, or fingerprint.
• Non-repudiation
Non-repudiation can be provided when there is unforgeable evidence that an action must have been performed by a specific entity. A typical use of non-repudiation is to prove the integrity and origin of specific information and is often performed with the aid of digital certificates.
• Authorization
The act of giving privilege access to resources and information to those who are permitted to use them.
• Accountability
An entity can be accountable for its actions if it is proper identified and authenticated. By keeping audit trails for each event, any actions can be traced and associated with the correct entity. The presence of accountability is often used as deterrence for any perpetrators, since they do not want to be accountable for their actions.
3.2 Computer security 17
3.2.1
Cryptology
Cryptology is needed to be able to have confidentiality and integrity over a public communication channel. Confidentiality can be achieved by doing encryption of the information and there are two methods of encryption: symmetric-key
cryptol-ogy and public-key cryptolcryptol-ogy.
In symmetric-key cryptology, a single key is used for both encryption and decryption [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 this type of algorithms. Digital Encryption Standard (des) and Advanced Encryption
Standard (aes) are some examples of symmetric algorithms.
Public-key cryptology gives the possibility to secure communication between two parties without a shared key [54]. Each party has its own set of private and public key. When transmitting information, it is encrypted with the recipient’s public key and the only way to decrypt it is with the private key that is only known to the recipient. The down side with this type of algorithms is that it takes much computing resources to do the encryption and the decryption. rsa and Elgamal are some examples of asymmetric algorithms.
3.2.2
Cryptographic hash functions
Cryptographic hash functions are needed as part of the integrity check when using secure communication. Hash functions are used to calculate a message digest of a message. The calculated hash value is then sent together with the message. The recipient does a new message digest and compares it with the one delivered with the message. The message is intact if they match up.
There are some requirements for a cryptographic hash function. It should be able to take any length of message and produce a fixed length of output [54]. It should be a one-way function and collision resistant, meaning that it should not be possible to know what the original message looks like by just looking at the hash value and that it should be impossible to find two messages that gives the same hash value. Message Digest algorithm 5 (md5), Secure Hash Algorithm (sha), and race Integrity Primitives Evaluation Message Digest (ripemd) are examples of cryptographic algorithms.
3.2.3
Digital signatures
Cryptographic hash functions does not solve the integrity check entirely, since anyone, with the knowledge of what hash function is in use, could modify the message and replace the hash value with a new one [54]. This can be prevented by using public-key cryptology and encrypting the calculated hash value. The hash value is encrypted with the sender’s private key and the recipient decrypts it with the 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 who knows the private key. Anyone trying to modify the message can not produce a new digital signature and thus making that message invalid.
3.3
Email technologies
There 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 identity in various ways [44]. The sending identity of an email is placed in both the envelope and in the header of an email. The envelope is a part of the smtp transmission and the header is a part of the actual message.
Content authentication protocols is about protecting the author rather than the sender of an email [44]. The authentication is done with the help of content signing using public-key cryptology.
The following first four technologies works with sender authentication and the rest with content authentication.
3.3.1
Sender Policy Framework
Sender Policy Framework (spf) authenticates the helo and mail from
com-mands in the smtp communication between servers (the email envelope) [57]. The helo command is used to announce who the connecting server is and the mail from command is used to declare which email address the email is originating from. By publishing the spf information in the dns, can a domain tell others where email from its domain can have its origin.
When an email is going to be delivered to the mail server a tcp connection must be established. The actual ip address of the sending server can then be found from the tcp connection. By doing a dns lookup of the spf record of the email domain, given by the mail from command, can the server determine if the sending server is allowed to send email with that domain name [57]. See figure 3.1.
3.3.2
Author Domain Signing Practices
Author Domain Signing Practises (adsp) have a similar agenda to spf but with
the difference that it is an aid to determining if a domain signs all their email with DomainKeys Identified Mail (dkim) or not [17]. This will help the receiving part to know if an unsigned message can come from that particular domain and thus knowing if it is spoofed since only the owner of the private key can produce a correctly signed message. A domain can publish, in the dns, the recommended actions 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 draft stage, but is expected to become a standard.
3.3.3
SenderID
senderid is a protocol derived from spf that aims at authenticating the mail from and one of the addresses in the email header [38]. Which header to use in the authentication 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 mta
mta 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 individual domains and email addresses. The information in the smtp and the email headers is validated against different lists. There are three types of listings: White-, black-, and greylisting. Addresses on the whitelist are automatically accepted to be delivered through the server, whilst the blacklist disallows the delivery. Greylisting is a combination of white- and blacklisting, where the delivery is delayed for a short time. There are different ways of implementing the graylisting, but the main goal is to temporarily reject the first delivery from an unknown hosts and accepting the email when the host tries resending the email [25]. Most legit mail servers will try to deliver the email until it is accepted, but most spammers do not try a second time 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 secure
transfer of mime data [45]. It can give content integrity, authentication, and non-repudiation with the help of digital signatures. Data confidentiality is obtained when encryption is activated. s/mime is an end-to-end solution working on the muas. The public keys are distributed with digital certificates attached to the email message. These digital certificates are called x.509 and are a part of the public-key infrastructure used for secure transmissions on the Internet.
3.3.6
Pretty Good Privacy
Pretty Good Privacy (pgp) is a family of software developed in 1991 by Philip
Zimmerman [11]. This implementation is standardized under the name openpgp. It works in a similar way as s/mime, with exception to the key management. The public 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 by someone the user already trusts.
3.3.7
DomainKeys Identified Mail
DomainKeys Identified Mail (dkim) secures the email body and parts of the email
header [2]. It provides authentication and integrity with digital signatures and does not encrypt the content. The public key is published in the sending domain’s dns record and the private key is used to sign the email. The recipient of a signed message verifies the signature by comparing it with the hash value, of the headers and the body, and the sender’s public key.
3.3.8
DomainKeys
DomainKeys is the predecessor to dkim and was created by Yahoo [14]. It is a historical and obsoleted standard, but it is still in use by various entities on the Internet [2].
3.4
More about DKIM
The following part will explain dkim more in detail. It is selected because of its good properties with sender and content authentication which includes verification of some headers and the content of the email [2]. The system is also transparent to end-users compared to s/mime and pgp which manipulates the content of an email [24]. This is because the signature is part of the email header and not in the email body. This also results in a smoother transition since not everyone needs to activate dkim at the same time because of the transparency. The keys used for signing and verification are mainly connected to the domain rather than the user, thus preserving the user’s integrity. By using the dns system for the publication of the public keys, no new public-key infrastructure is needed to be maintained. 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 a recommendation on how to treat an email with broken signature.
3.4.1
Canocalization
Every 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, and whitespaces 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 verification process of an email. This process is called canocalization and has two modes of operation: simple and relaxed. A combination of these modes is applied to both the header and the body and is selected by the signing party. Canocalization only prepares the email for the signing and the verifying algorithms and does not modify the transmitted data.
• Simple header canocalization does not allow any modification during
transit to the headers used when the message was signed [2]. The signature of 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 one whitespace character, removes all whitespace after the end of each header value, and removes any whitespace before and after the colon between the header name and value [2].
• Simple body canocalization only removes any empty lines at the end of
the 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
Signing
Signing 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 wants to take responsibility for that message [2]. The signer must decide which headers to 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 or removed during transit. The signer may also sign nonexistent headers to prove the denial of existence. If there are several instances of one type of header, then the header closest to the body is used first.
The signer calculates two hashes, one over the message body and one over the selected header fields including the body hash, using either the sha1or the sha256 hash algorithm [2]. The header hash is then signed using the rsa algorithm and a private key. All the configuration parameters and signature is then placed in the
DKIM-Signature: header field.
Example 3.1 shows a typical dkim signature. This specific signature indicates which 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 it shows which domain who signed this message, d= and the corresponding public key, the selector, s=. The time the message was signed and the body hash is indicated by the t= and bh=. Finally are the signed headers enumerated and placed in the h= and the signed header hash is placed in b=.
Example 3.1: A DKIM-Signature: header
DKIM-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=AsmD11IU0TwqQwK 9fGWIlV7TPtBRgEzcFwuhgbvaoipwcI9hA8M1TzE025rPzbLlJbEJKz8T 2WSfmg7BbmSQ4rklSaq5ou1BrwxGTQWn/I37sOPhzg+pRfAjq7IWo6Zys OOgDkbCcOjL46kECDFQBWSvgKD3oOID4FOj5huSdzw=
3.4.3
DNS record
The public key is stored in the dns related to the signing entity. The following is a typical example of a dns record for the public key [2].
Example 3.2: A DKIM DNS text record
ex1._domainkey.exempel1.tset.se. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC6oekzH849jUK1EYJnfUM72 OlhpaTxqBhvNu3UTGsbRywFWBHCPfoeHAZKnYhN+pLAXuJ49oUNO1kybAqUfxPM OpTbupY0zVdaJCtcMHi7j7rFgSrRi8nH55Frhq4aiS00ocdw1po0p72c7TkTNm5 E1Q2jZ4pGpjEXJtjzb9YckwIDAQAB"
All dkim information is stored under the _domainkey.“domain” and a unique selector is used for each public key [2]. The selector is ex1 in this example. The reason 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 within the company or one for each user.
Key revocation is simply done by removing the key from the p variable in the dns record, thus invalidating any message signed by that key pair [2].
3.4.4
Verification
Verification is performed at the mta, the mda, or the mua and it is recommended that the validation is performed closest to the recipient to prevent any malicious action by a third party [2]. The verifier starts by validating the dkim-Signature: header field to find the configuration parameters and any inconsistencies. The signature contains the information of how to reconstruct the signature as the signer did it. The signing process is reconstructed and compared with the values stored in the signature header. If everything matches, then the message is authenticated. This can by indicated by adding a header, like Authentication-Results:, to the email so 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 dns record [2].
Example 3.3: DKIM verification results
Authentication-Results: exempel2.tset.se; dkim=pass (1024-bit key) header.i=@exempel1.tset.se; dkim-asp=none
3.4.5
The need for DNSSEC
One big weakness with the dkim system is how trustworthy the dkim public keys are. The dkim system depends on the reliability of the dns system to deliver the correct dkim public key, but there are vulnerabilities to the dns system that will aid attackers doing malicious distribution of dkim public keys. Some of these attacks, 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 validator can then verify the origin of the dkim public key and thus knowing that it is not spoofed by a malicious entity.
Chapter 4
Deployment and testing of
DKIM
The dkim milter with patched dnssec capabilities is tested by deploying it in a lab environment that simulates the fundamental properties of the real world email system. Test servers are installed and configured to interact with each other. The basic functionality is evaluated against different test cases and the results are presented at the end of this chapter.
4.1
Server set-up
The first part is to have the different servers installed and configured before any testing can be done. The following section shows how the testing environment looks like.
4.1.1
The lab environment
The verification and testing are done with different mail servers, both locally on site and public servers on the Internet. The local mail servers are a collection of the mail servers that support dkim milter. There is a server available for testing purposes 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.
4.1.2
Supported mail servers
Since the project concerns the dkim milter, only mtas that support the milter api can be used in the test cases [56].
• Sendmail 8.12.0 and later
Open source www.sendmail.org
• Postfix 2.4 and later
Open source www.postfix.org
• Postoffice SMTP server 1.3 and later
Open source
www.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 software
The basic idea for the test environment is to have two mail servers that can send and receive email. Each mail server has its own domain name, so that they act independently of each other. The first mail server runs Postfix and the second one runs Sendmail. To each mail server there are different mail filters and security software connected to it.
A single dns server hosts the dns records for both of the domains. These domains are subdomains of a dnssec enabled domain called tset.se. Figure 4.1 illustrates the test configuration.
Each step of the installation and the configuration parameters are documented in appendix A.
IP aliasing
There is only one computer available for testing purposes in the lab environment and all test servers must be running on this computer. The problem is that both Postfix and Sendmail need exclusive rights to certain ports on the Network
Interface Card (nic). There is therefore a need of multiple ip addresses to be able
to provide the mtas with their own set of ports. This can be solved by having multiple 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 nic host them. The difference between these two solutions is a performance issue regarding how the traffic are flowing to the computer through the network, but this has no importance for the test cases since they are not performing any stress testing.
4.1 Server set-up 27
SASL SMTP
TLS
Postfix
exempel1.tset.se Sendmailexempel2.tset.se DNS
DKIMMilter DKIMMilter
Procmail Microsoft
Outlook MicrosoftOutlook
SMTP SMTP User 1 User 2 IMAP TLS Password file
DNS
When the ip addresses of the machine are configured it is time to publish their existence by using the dns system. This is done by having a dns server installed on the machine, which will answer for any queries about these domains. Bind 9 is the 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 a delegation from the domain tset.se. Two domains are in use, exempel1.tset.se and
exempel2.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. Sendmail and Postfix are selected because of their widespread use and reliability. Postof-fice is neglected because it is mainly intended for use in the NetBSD operating system. Further more, there should not be any big differences between these sys-tems regarding dkim milter since they all communicate with it through the Milter interface.
DKIM Milter
dkim milter is an implementation of the dkim standard. It attaches it self to the mail servers by using the Milter api and thus getting access to the information about the emails in transit through the mail server. dkim milter can with this information decide if it should sign the particular email and validate the signature of incoming emails. The results are put in the header of the email and any entity later in the chain can take specific action with this result in mind. The dkim milter is extended with a patch from .se that will make it to evaluate the dns queries with the aid of dnssec.
IMAP
An interface to the mail servers are needed to be able to retrieve the delivered emails. Dovecot is an implementation of imap and is used in the test suite to be able to read message from an external computer. There are other implementations of imap, but the selection of implementation should not influence the test results since 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 out from them and with Cyrus sasl can an external user authenticate it self to the mail servers and thus be able to send email to other domains. The smtp-auth func-tionality is thus enabled. The discussion concerning the choice of implementation is 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 are needed 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 used for 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 changing keys. The ksk is used as a secure entry point to the zone and if a new key is used for signing the zone, no one needs to be informed of this because they already have a copy of the ksk and thus a secure path to the zone. It is recommended that the key length is longer for the ksk than the zsk since it should be more secure. It is current recommended to use either rsasha1 or dsa as a key algorithm.
dkim on the otherhand uses the rsa algoritm and those keys are used for signing and validating the dkim signature. [2]
Certificates
Digital certificates are needed to create the secure channels between the user and the mail server. The certificate shows the identity of the public key owner and thus the ability to validate the origin of the connection. They are usually obtained from an Certificate Authority (ca) like VeriSign.com or Thawte.com and is the base for this type of public-key infrastructure. The other possibility it to generate a self-signed certificate locally on the server, but then no one can really trust the content of the certificate since they do not have a trusted relationship to the server like 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 the secure channel between the user and the mail server is not a top priority for the test suite.
4.2
Testing of DKIM Milter
There are two types of tests that are performed, function testing and domain
testing. The first one verifies the functionality and the second one tries to find any
unexpected events. The tests focus on the new inputs to the dkim milter that are created because of the patch.
4.2.1
Function testing
These types of tests are suitable for the first set of tests, because they are aimed at the smallest building block visible to the outside of a program [30]. The idea is to focus on one variable or function and see how they react to middle-of-the-road values as input data. That is, values that are expected to pass the test. It is easy to evaluate the outcome of the tests because the complexity of the procedures is fairly low. The result is often predictable and the program will not fail these sets of 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 the tests fail, the problems can be fixed before the more complex test scenarios are started.
4.2.2
Domain testing
The domain testing takes the function testing one step further by testing a wide range of input values to a given function or variable [30]. A problem with this is that the combinations of possible input values often are enormous and would take very long time to go through all these tests. What the domain testing does is that it reduces this massive set into subdomains. A subdomain is a set of input data 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 the boundary or the extreme values.
4.2.3
Variables to test
The first basic tests focus on the new inputs to the dkim milter and how they affect the system. The reason of doing this is because different inputs will make the system behave in different ways. The patch introduces the dnssec functionality to the system and two components are needed to have this functionality function properly. The first is that the dns response from the email author’s domain is needed to be dnssec enabled. The second component is the trust anchor needed to 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, protocol number, 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 variables consist of key tag, algorithm, digest type and digest.
Each of these rrs is defined in the RFC4034. It describes how and what values should be used and what actions are expected to be taken by the recipient. Read the rfc for a more detailed explanation of the different rrs.
The second component to test is the trust anchor file and it is formatted just like the dnskey rr. It acts as a local copy of the public key to the trusted zone.
4.2 Testing of DKIM Milter 31
4.2.4
Test cases
The test cases are made according to model recently discussed. The first part is to verify that functionality, table 4.1, and the second part tries to interrupt the system by using boundary values, table 4.2. The tests are performed by sending an email from one email server to the other. Each direction is tested.
