The EDNS(0) Padding Option

Mayrhofer, Alexander

doi:10.17487/rfc7830

Cited by 16 publications

(12 citation statements)

References 2 publications

(3 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…To explore this issue, we ran a set of tests with different resolvers. In our tests, we observed three basic approaches to padding among several recursive resolvers: 1) always pad responses, 2) never pad responses, and 3) pad responses when the client sends the EDNS(0) option, indicating padding (12) [41]. For recursive resolvers that pad, we found two padding approaches: using fixed block size padding (128 or 468 octets) or variable amounts of padding.…”

Section: Comparison Of Recursive Resolvers the Ability To Identifymentioning

confidence: 89%

“…By contrast, DNS messages have historically been constrained to be less than 512 bytes when transmitted over UDP (which is by far the most common method) [44]. DNS Extensions now allow DNS messages over 512 bytes [41], and DNSSEC often generates messages over 512 bytes [57]. However, the DNSSEC deployment is still relatively low [7,8].…”

Section: Insights Of Dot Trafficmentioning

confidence: 99%

See 1 more Smart Citation

An investigation on information leakage of DNS over TLS

Houser

Cotton

et al. 2019

Proceedings of the 15th International Conference on Emerging Networking Experiments and Technologies

View full text Add to dashboard Cite

DNS over TLS (DoT) protects the confidentiality and integrity of DNS communication by encrypting DNS messages transmitted between users and resolvers. In recent years, DoT has been deployed by popular recursive resolvers like Cloudflare and Google. While DoT is supposed to prevent on-path adversaries from learning and tampering with victims' DNS requests and responses, it is unclear how much information can be deduced through traffic analysis on DoT messages. To answer this question, in this work, we develop a DoT fingerprinting method to analyze DoT traffic and determine if a user has visited websites of interest to adversaries. Given that a visit to a website typically introduces a sequence of DNS packets, we can infer the visited websites by modeling the temporal patterns of packet sizes. Our method can identify DoT traffic for websites with a false negative rate of less than 17% and a false positive rate of less than 0.5% when DNS messages are not padded. Moreover, we show that information leakage is still possible even when DoT messages are padded. These findings highlight the challenges of protecting DNS privacy, and indicate the necessity of a thorough analysis of the threats underlying DNS communications for effective defenses. CCS CONCEPTS • Security and privacy → Privacy-preserving protocols.

show abstract

Section: Comparison Of Recursive Resolvers the Ability To Identifymentioning

confidence: 89%

Section: Insights Of Dot Trafficmentioning

confidence: 99%

An investigation on information leakage of DNS over TLS

Houser

Cotton

et al. 2019

Proceedings of the 15th International Conference on Emerging Networking Experiments and Technologies

View full text Add to dashboard Cite

show abstract

“…Motivated by our exchange with Cloudflare after responsible 1 disclosure, we evaluate existing traffic analysis defenses: the standardized EDNS0 padding [23] and the use of Tor [24]. We find that in our setup, contrary to what was suggested by Cloudflare engineers, EDNS padding strategies cannot completely deter our attack.…”

Section: Introductionmentioning

confidence: 93%

“…is a specification to increase the functionality of the DNS protocol [65]. One of the options is the addition of padding [23] by both DNS clients and resolvers in order to prevent sizecorrelation attacks on encrypted DNS. The recommended padding policy is to pad DNS requests to the nearest multiple of 128 bytes and DNS responses to the nearest multiple of 468 bytes [66].…”

Section: Edns(0) Padding Edns (Extension Mechanisms For Dns)mentioning

confidence: 99%

Encrypted DNS --> Privacy? A Traffic Analysis Perspective

Siby

Juárez

Díaz

et al. 2020

Proceedings 2020 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

Virtually every connection to an Internet service is preceded by a DNS lookup. These lookups are performed in the clear without integrity protection, enabling manipulation, redirection, surveillance, and censorship. In parallel with standardization efforts that address these issues, large providers such as Google and Cloudflare are deploying solutions to encrypt lookups, such as DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH). In this paper we examine whether encrypting DoH traffic can protect users from traffic analysis-based monitoring and censoring. We find that performing traffic analysis on DoH traces requires different features than those used to attack HTTPS or Tor traffic. We propose a new feature set tailored to the characteristics of DoH traffic. Our classifiers obtain an F1-score of 0.9 and 0.7 in closed and open world settings, respectively. We show that although factors such as location, resolver, platform, or client affect performance, they are far from completely deterring the attacks. We then study deployed countermeasures and show that, in contrast with web traffic, Tor effectively protects users. Specified defenses, however, still preserve patterns and leave some webs unprotected. Finally, we show that web censorship is still possible by analysing DoH traffic and discuss how to selectively block content with low collateral damage.

show abstract

“…Even with encrypted messages, a well-positioned party may be able to glean certain details from an analysis of message timings and sizes. Clients and servers may consider the use of a padding method to address privacy leakage due to message sizes [RFC7830]. Since traffic analysis can be based on many kinds of patterns and many kinds of classifiers, simple padding schemes alone might not be sufficient to mitigate such an attack.…”

Section: Security Considerationsmentioning

confidence: 99%

Specification for DNS over Transport Layer Security (TLS)

Wessels¹,

Heidemann²,

Zhu³

et al. 2016

181

115

View full text Add to dashboard Cite

This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.

show abstract

The EDNS(0) Padding Option

Cited by 16 publications

References 2 publications

An investigation on information leakage of DNS over TLS

An investigation on information leakage of DNS over TLS

Encrypted DNS --> Privacy? A Traffic Analysis Perspective

Specification for DNS over Transport Layer Security (TLS)

Contact Info

Product

Resources

About