What standard email security technologies are we testing?

The MECSA platform checks the security and privacy offered by email providers, by testing their support of a set of standards we identified in a previous publication

1. StartTLS

The StartTLS [RFC3207, RFC7817] command is an extension to the Simple Mail Transfer Protocol [RFC5321] (SMTP) used to enable Transport Layer Security [RFC5246] (TLS) encryption in the communications between client and server (sender and recipient). Following the SMTP protocol, the server will announce its support of the StartTLS command in the response to an EHLO command.
The client will send the StartTLS command to indicate she wants to initiate a TLS negotiation. During this negotiation, two things will happen:

1. The server will authenticate himself using an X.509 certificate. Optionally, the client must be requested to authenticate too.
2. Client and Server will negotiate a secret key K, that will be used to encrypt the communications between them hence for.

Example of SMTP dialog extracted from RFC3207:

S: <waits for connection on TCP port 25>
C: <opens connection>
S: 220 mail.imc.org SMTP service ready
C: EHLO mail.example.com
S: 250-mail.imc.org offers a warm hug of welcome
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 DSN
C: STARTTLS
S: 220 Go ahead
C: <starts TLS negotiation>
C & S: <negotiate a TLS session>
C & S: <check result of negotiation>
C: EHLO mail.example.com
S: 250-mail.imc.org touches your hand gently for a moment
S: 250-8BITMIME
S: 250 DSN

2. x509 Certificates

X.509 certificates are used to validate the identity and/or public key of servers (e.g. during the TLS negotiation). X.509 Certificates (sometimes also called Secure Socket Layer (SSL) certificates) take their name from the certificate format adopted by Netscape when it designed the first version of the SSL protocol. An X.509 certificate acts as a container for some specific information regarding the identity to which the certificate has been issued and the identity of the issuer.
Among the most important fields stored into an X.509 certificate we find:

Version: version of the X.509 format that applies to the certificate.
Serial number: unique number assigned by the issuer.
Algorithm information: description algorithm used to digitally sign the certificate.
Issuer distinguished name: name of the issuer (usually a certification authority) of the certificate.
Validity period of the certificate: Start and end of validity of the certificate.
Subject distinguished name: the name of the subject to which the certificate has been issued.
Subject public key information: public key of the owner of the certificate.

The format of the certificate is established in the RFC5280. The ways to access it and to process it are defined in RFC4210. RFC3739 defines what it calls a Qualified Certificate, which is related to the European Directive on Electronic Signature (Directive 1999/93/EC).

3. SPF

Sender Policy Framework [RFC7208, RFC7372] (SPF) is a protocol that allows email providers to announce a list of hosts (IP addresses) authorized to deliver emails on his behalf. Following the SMTP protocol, when a client identifies himself (HELO or EHLO commands), she must indicate a hostname or IP address, and when she initiates the transmission of an email, she must send the MAIL-FROM command, indicating the email address of the sender.

These two fields, the hostname (or IP address) from the HELO (or EHLO) command and the email from the MAIL-FROM command must be confronted against the SPF record published by the corresponding email provider to check whether the client has permission to send emails on behalf of that email provider. SPF records are published as TXT records in the DNS domain of the email provider. Example: SPF record of the et.dcslab.eu domain:

v=spf1 a mx ip4:139.191.36.5 -all

v=spf1 version
a accept IP if are one of the et.dcslab.eu A record
mx accept IP if are an et.dcslab.eu MX record
ip4:139.191.36.5 accept IP if are in the given range
-all default is Fail

4. DKIM

DomainKeys Identified Mail [RFC6376] (DKIM) is an authentication mechanism used to verify the legitimate origin of an email.

It uses digital signatures to verify the identity of the sender host. An email provider generates a pair of public/private keys for a domain, and publishes the public one as DNS record.
Every time it sends an email, it signs it using the private key. Once the recipient server receives the message, it can validate the signature against the record published. By doing so, the recipient can verify two items:

• The sender had the authorization of the domain controller, the person in charge of the domain DNS.
• The message has not been modified during its transport from the sender to the recipient.

Example of DKIM header on a received email:

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=et.dcslab.eu; s=102016; t=1476792726; bh=HS0o/CkH/ZCpSrfolDyH8IR5hX6n8GxWLzY59OuvtWo=; h=Date:From:From:Subject; b=OOlOO/jae1cPF2pllIF2QiENPJdUvGL70FdPMkKa89qkhXdvr D89eZwK6OZzEdLYncAbYCrEVi58jFqFAjKBcASrRpjSQXTJX6hM cRNZ295/1xp8vR/J9CQl9baqGxhYWID8Z0OrN/tbwXNN2UiNTmk MIm90UDJHdQnw/rd9rX4=

In the previous example, to recover the key to check the DKIM signature, we have to request a DNS record of type TXT for the domain: 102016._domainkey.et.dcslab.eu.

5. DMARC

Domain-based Message Authentication, Reporting and Conformance [RFC7489] (DMARC) is a mechanism that allows providers to publish policy directives regarding SPF and DKIM.

In particular, it allows email providers to indicate what to do when a message fails to comply with SPF or DKIM (reject, quarantine, none), and to indicate an email address to receive reports.

It can also be used to define a policy of accepting/rejecting certain percentage of failed messages, allowing a gradual deployment of these technologies. Example, DMARC record of the et.dcslab.eu domain:

v=DMARC1; p=reject; rua=mailto:dmarc_reports@et.dcslab.eu

v=DMARC1 DMARC language version
p=reject policy to apply by the recipient: none/quarantine/reject
rua=mailto.. address to send reports

6. DANE

DNS-based Authentication of Named Entities [RFC6698, RFC7218, RFC7671, RFC7672] (DANE) is a mechanism that binds x.509 certificates (or public keys) to services, specifying the port, protocol and domain where the service is running. The binding of certificate and service is published as a DNS record of type TLSA. DANE can be applied to any service, but for the particular case of email communications we have the RFC7672, which describes the application of DANE and DNSSEC to communications (SMTP) between MTAs. In particular the RFC7672 recommends to use DANE-TA or DANE-EE with DNSSEC.

A TLSA record contains 4 values: the Usage-Field, Selector-Field, Matching-Type-Field and Associated-Data. Following we have the description of the different fields of a TLSA record.

As example, the TLSA record for an SMTP server running on the default port (25), on the host mx.example.com, using DANE-EE and publishing the SHA2-256 of public key (SPKI) of the endpoint certificate would be:

_25._tcp.mx.example.com TLSA 3 1 1 1cf...6ab

7. DNSSEC

Domain Name System Security Extensions [RFC4033, RFC6014, RFC6840] (DNSSEC) is a protocol used to authenticate the answers of DNS servers. This mechanism is useful to prevent applications from using altered or forged DNS records. The protocol is able to authenticate a set of DNS records through the verification of a cryptographic signature associated. To achieve its purpose, DNSSEC introduces additional record types:

• Resource Record SIGnature (RRSIG): contains a cryptographic signature of a Resource Record SET (RRSET).
• DNS KEY record (DNSKEY): contains a public signing key.
• Delegation Signer (DS): contains the hash of a DNSKEY record.
• Next SECure record (NSEC) and NSEC3: for explicit denial of existence of a DNS record.
• Child copy of DNSKEY record (CDNSKEY) and Child copy of DS record (CDS): for a child zone requesting updates to DS record(s) in the parent zone.

To enable DNSSEC, the server must have two pairs of keys (public and private). The first pair are the public and private Zone Signing Keys (ZSKs) and the second pair are the Key Signing Keys (KSKs). With the private ZSK, the server digitally signs all the RRSET on the DNS (group of DNS records of the same kind, e.g. MX, TXT, etc.), and stores their signatures into an RRSIG record. The public ZSK is needed to verify their signatures and it is published as a DNSKEY record. The DNSKEY record of the public ZSK is signed with the private KSK. The public KSK is also published as a DNSKEY record, and it is self-signed, i.e. it is signed with the private KSK. This sequence of steps establishes the trust within the zone.

Since the DNS is a hierarchical system, the trust inside a zone, must be connected with the parent zone. For this purpose, the server hashes the public KSK and publishes this hash as a DS record in its parent zone.