Some Statistics From MECSA

StartTLS is an extension of the protocol used to send e-mails (SMTP), that the sender executes to indicate she wants to encrypt the communication channel between sender and recipient (TLS). The use of the StartTLS protocol has two objectives:

1. Authenticate the recipient. When we use the TLS protocol, the recipient has to send a certificate signed by a Certification Authority (CA). This certificate will prove that the recipient is who he says he is.

2. Protect the contents of the message from eavesdropping. When the TLS is initiated, a secret key shared only by sender and recipient is generated, and from that moment, all messages sent between them are encrypted using this secret key. Therefore, only sender and recipient will be able to read the content.

A certificate is an electronic document that binds a public key with a name. In this case it is the name of an email server (FQDN). To validate a certificate, we check the following claims:

1. It is signed by a Certificate Authority (CA). CAs are trusted providers that are responsible for issuing certificates.

2. It has not expired. The certificate is valid in the date it has been received. Typically, certificates are issued with an expiration time (1 year, 2 years, ...).

3. It has not been revocated. Certificates can be ‘cancelled’, by reporting them to a revocation list. There are different situations in which we may need to revocate a certificate: changing the name of the service (see FQDN), compromise of the private key, etc…

4. Full Qualified Domain Name (FQDN). The FQND is the name (hostname) of the machine where the email service is running. This name can appear in the certificate as a complete name like ‘et.dclabs.com’ or a domain with a wildcard ‘*.dclabs.com’.

The SPF is a TXT entry in the DNS record of a sender domain, that indicates which Ip addresses and/or hostnames are legitimated to send e-mails on behalf of that domain. It is an effective measure against SPAM and fishing attacks: every time a recipient receives a message, he can check whether the sender is legitimate or not.

DMARC is an entry in the DNS record of a domain, describing this domain policy regarding SPF and DKIM. In particular, it describes three aspects:

1. It indicates whether DKIM and SPF are supported.

2. It describes what to do when DKIM and/or SPF fail, e.g. accept, reject, accept or reject a certain percentage of failed messages, etc.

3. It provides the means to send feedback regarding the enforcement of SPF and DKIM.

It is an authentication method for email messages, that allows the recipients to check if a message received was indeed sent by the sender. An email provider that supports DKIM will sign all messages sent, and publish the public key required to validate them as a DNS record of the domain. When a recipient receives a signed message, he can retrieve the public key from the DNS record and validate the signature. If the signature is valid, the message was indeed sent by the sender. Moreover, it also means that the message has not been modified on the way from sender to recipient.

DANE is a protocol that binds X.509 certificates with services, using DNS records of type TLSA. In MECSA we focus on the use of DANE with SMTP services. When a TLSA records is present, it indicates that StartTLS must be used, and which certificate will be used to authenticate the email server. It is an effective measure against an attack known as StartTLS downgrade attack.

DNSEEC is a set of IETF specifications to secure DNS records. In particular, it assures the authenticity, and data integrity of the DNS records using digital signatures. SPF, DKIM, DMARC, etc… all these security mechanisms rely on DNS records to advertise themselves, and provide the required information to the participants. None will be effective if the corresponding DNS record can be manipulated.