DNS-based Authentication of Named Entities

Public Key Infrastructure (PKI) has turned out to be useful when two parties negotiate about a shared secret in order to establish an encrypted connection between them. To verify the public key, a certificate is used. The certificate is issued by a public, generally trusted third party Certificate Authority (CA). Usually, the web browsers have a list of trusted CAs. It is a well-known problem that the number of security risks increases when the number of CAs grows. A compromised CA can, by an attacker's malicious action or by a human error, issue a trusted certificate to a party who does not own the domain. The purpose of this Master of Science Thesis is to research the applications of the DANE protocol, which is standardized by the IETF. The research question is, how to validate a target receiver while negotiating the encrypted connection. Special focus is on the secure email system. The DANE protocol makes use of the existing Domain Name System (DNS) and its Security Extensions (DNSSEC). This Master of Science Thesis begins with a theoretical part, where the technical background and current techniques are introduced. The DANE protocol and its features are also considered in this chapter. The latter part considers the method in practice, and describes how DANE can be used for the certificate verification instead of CA. The testing phase proves that the deployment of DANE is not complex and the increase of delay and traffic are not significant. DANE provides the needed association between the DNSSEC's chain of trust and the received certificate

DANE Trusted Email for Supply Chain Management

Supply chain management is critically dependent on trusted email mechanisms that address forgery, confidentiality, and sender authenticity. The IETF protocol ‘Domain Authentication of Named Entities’ (DANE) described in this paper has been extended from its initial goal of providing TLS web site validation to also offer a foundation for globally scalable and interoperable email security. Widespread deployment of DANE will require more than raw technology standards, however. Workflow automation mechanisms will need to emerge in order to simplify the publishing and retrieval of cryptographic credentials that are applicable for general audiences. Security policy enforcement will also need to be addressed. This paper gives a descriptive tutorial of trusted email technologies, shows how DANE solves key distribution logistics, and then suggests desirable automation components that could accelerate deployment of DANE-based trusted email. Pilot deployments are briefly described

A security analysis of email communications

The objective of this report is to analyse the security and privacy risks of email communications and identify technical countermeasures capable of mitigating them effectively. In order to do so, the report analyses from a technical point of view the core set of communication protocols and standards that support email communications in order to identify and understand the existing security and privacy vulnerabilities. On the basis of this analysis, the report identifies and analyses technical countermeasures, in the form of newer standards, protocols and tools, aimed at ensuring a better protection of the security and privacy of email communications. The practical implementation of each countermeasure is evaluated in order to understand its limitations and identify potential technical and organisational constrains that could limit its effectiveness in practice. The outcome of the above mentioned analysis is a set of recommendations regarding technical and organisational measures that when combined properly have the potential of more effectively mitigating the privacy and security risks of today's email communications.JRC.G.6-Digital Citizen Securit

How to Measure TLS, X.509 Certificates, and Web PKI: A Tutorial and Brief Survey

Transport Layer Security (TLS) is the base for many Internet applications and services to achieve end-to-end security. In this paper, we provide guidance on how to measure TLS deployments, including X.509 certificates and Web PKI. We introduce common data sources and tools, and systematically describe necessary steps to conduct sound measurements and data analysis. By surveying prior TLS measurement studies we find that diverging results are rather rooted in different setups instead of different deployments. To improve the situation, we identify common pitfalls and introduce a framework to describe TLS and Web PKI measurements. Where necessary, our insights are bolstered by a data-driven approach, in which we complement arguments by additional measurements

My Email Communications Security Assessment (MECSA): 2018 Results

This JRC technical report presents the results obtained by the My Email Communications Security Assessment (MECSA) tool. MECSA is an online1 tool developed by the Joint Research Centre to assess the security of email communications between email providers. Email communications continue to be one of the most widespread forms of digital communications with thousands of millions of emails exchanged on a daily basis. It is estimated that 72% of the European population use email either in mobile phones, tablets or computers. It is the means of digital communication used by most Europeans on a daily basis (Special Eurobarometer 462, 2017. Published July 2018.) MECSA is the outcome of our research on the security of email communications. It servers a triple purpose. Firstly, it allows us to monitor the adoption of modern email security standards in the current ecosystem of email providers, assessing their capability to protect the confidentiality, integrity and authenticity of the email exchange amongst them. Secondly, MECSA aims to become a one-stop shop for email users to receive an indication of the capability of their email providers to protect their email exchange in the communication with other providers of the ecosystem. Finally, MECSA aims to become a reference tool for professionals and a mean to promote the adoption of modern email security standards in Europe.JRC.E.3-Cyber and Digital Citizens' Securit

Extended Hell(o): A Comprehensive Large-Scale Study on Email Confidentiality and Integrity Mechanisms in the Wild

The core specifications of electronic mail as used today date back as early as the 1970s. At that time, security did not play a significant role in developing communication protocols. These shortcomings still manifest themselves today in the prevalence of phishing and the reliance on opportunistic encryption. Besides STARTTLS, various mechanisms such as SPF, DKIM, DMARC, DANE, and MTA-STS have been proposed. However, related work has shown that not all providers support them and that misconfigurations are common. In this work, we provide a comprehensive overview of the current state of email confidentiality and integrity measures, as well as the effectiveness of their deployment. On a positive note, support for incoming TLS connections has significantly increased over the years, with over 96% of reachable MXs in the top 10 million domains allowing for explicit TLS. Notably, 30% of presented certificates are invalid, though, with the majority of issues related to the presented hostnames. In light of this, all 47 providers we tested connect to hosts with expired, self-signed, non-matching certificates, making it trivial for attackers to intercept their connections. Our analysis also shows that still only around 40% of sites specify SPF, and even high-ranked providers like t-online.de do not enforce it. Similarly, while DNS lookups are performed for both DKIM and DANE, neither mechanism is validated or enforced by all providers. In addition, we show that MTA-STS is only slowly getting traction (six providers support it) and provide the first large-scale analysis into OPENPGPKEY and SMIMEA records. All in all, this still paints a grim yet slightly improving picture for the state of email security by late 2022

{SoK}: {An} Analysis of Protocol Design: Avoiding Traps for Implementation and Deployment

Today's Internet utilizes a multitude of different protocols. While some of these protocols were first implemented and used and later documented, other were first specified and then implemented. Regardless of how protocols came to be, their definitions can contain traps that lead to insecure implementations or deployments. A classical example is insufficiently strict authentication requirements in a protocol specification. The resulting Misconfigurations, i.e., not enabling strong authentication, are common root causes for Internet security incidents. Indeed, Internet protocols have been commonly designed without security in mind which leads to a multitude of misconfiguration traps. While this is slowly changing, to strict security considerations can have a similarly bad effect. Due to complex implementations and insufficient documentation, security features may remain unused, leaving deployments vulnerable. In this paper we provide a systematization of the security traps found in common Internet protocols. By separating protocols in four classes we identify major factors that lead to common security traps. These insights together with observations about end-user centric usability and security by default are then used to derive recommendations for improving existing and designing new protocols---without such security sensitive traps for operators, implementors and users