RFC 7858

Specification for DNS over Transport Layer Security (TLS)

📅 published May 2016, from ietf

RFC 7858: Specification for DNS over Transport Layer Security (TLS) 🎀

okay bestie, this one is a glow-up for DNS privacy and I'm obsessed 💖 here are the deets before we dive in:

  • Title: Specification for DNS over Transport Layer Security (TLS)
  • Number: RFC 7858 🦋 (ISSN 2070-1721)
  • Stream: Internet Engineering Task Force (IETF)
  • Category: Standards Track ✨
  • Date: May 2016 🌸
  • Authors: Z. Hu, L. Zhu, J. Heidemann (USC/ISI), A. Mankin (Independent), D. Wessels (Verisign Labs), and P. Hoffman (ICANN) 👑
  • Obsoletes / Updates: this header doesn't list anything it obsoletes or updates 🙈

Abstract ✨

okay so this doc is all about using TLS to give DNS some privacy 🔒 TLS encryption shuts down eavesdropping and on-path tampering with DNS queries on the network, the kind of stuff RFC 7626 talks about. 🙅‍♀️

It also defines two usage profiles for DNS over TLS and gives advice on performance so that using TCP and TLS with DNS doesn't add a ton of overhead 💅

This doc is laser-focused on stub-to-recursive traffic, which matches the DPRIVE Working Group's charter 🧚 It doesn't stop future folks from applying the protocol to recursive-to-authoritative traffic though, so the door stays open 🚪

Status of This Memo

This is an Internet Standards Track document. 🌈

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. 💜

Info about the current status of this doc, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7858 🦋

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 🌸

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, since they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. ⭐

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Key Words . . . . . . . . . . . . . . . . . . . . . . . . . .   4
3.  Establishing and Managing DNS-over-TLS Sessions . . . . . . .   4
  3.1.  Session Initiation  . . . . . . . . . . . . . . . . . . .   4
  3.2.  TLS Handshake and Authentication  . . . . . . . . . . . .   5
  3.3.  Transmitting and Receiving Messages . . . . . . . . . . .   5
  3.4.  Connection Reuse, Close, and Reestablishment  . . . . . .   6
4.  Usage Profiles  . . . . . . . . . . . . . . . . . . . . . . .   7
  4.1.  Opportunistic Privacy Profile . . . . . . . . . . . . . .   7
  4.2.  Out-of-Band Key-Pinned Privacy Profile  . . . . . . . . .   7
5.  Performance Considerations  . . . . . . . . . . . . . . . . .   9
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
7.  Design Evolution  . . . . . . . . . . . . . . . . . . . . . .  10
8.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
  9.2.  Informative References  . . . . . . . . . . . . . . . . .  13
Appendix A.  Out-of-Band Key-Pinned Privacy Profile Example . . .  16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1. Introduction ✨

okay so right now almost every DNS query [RFC1034] [RFC1035] goes out unencrypted 😭 That means anyone on the network path with access to the channel can eavesdrop, which hurts the privacy of whoever is asking. Recent news reports have made people way more worried about this, and recent IETF work has written up privacy considerations for DNS [RFC7626]. 💅

Earlier work covered some parts of DNS security, but until recently there wasn't much on privacy between a DNS client and server. DNS Security Extensions (DNSSEC) [RFC4033] give you _response integrity_ by letting zones be cryptographically signed, so end users (or their first-hop resolver) can check that replies are correct. ✅ DNSSEC is not designed to protect the privacy of requests and responses, though. 🙈 Privacy used to be seen as either not needed for DNS traffic or as something the network already handled well enough. Those assumptions are changing because of recent events [RFC7258]. 🌈

Other work that could encrypt traffic between DNS clients and servers includes DNSCurve [DNSCurve], DNSCrypt [DNSCRYPT-WEBSITE], Confidential DNS [CONFIDENTIAL-DNS], and IPSECA [IPSECA]. Along with this spec, the DPRIVE Working Group has also adopted a proposal for DNS over Datagram Transport Layer Security (DTLS) [DNSoD]. 🧚

This doc describes using DNS over TLS on a well-known port, and it also offers performance advice to cut down on the overhead of using TCP and TLS with DNS. 🦋

Starting a DNS over TLS session is super straightforward 🥰 Clients connect to a well-known port, and clients and servers expect and agree to negotiate a TLS session to lock the channel down. Rollout will be gradual, though. Not every server will support DNS over TLS, and some firewalls might block the well-known port. Clients are expected to keep track of which servers support TLS and which ones don't. Clients and servers will follow the TLS implementation recommendations and security considerations in [BCP195]. 🔐

The protocol described here works for queries and responses between stub clients and recursive servers. It might also work between recursive clients and authoritative servers, but that use is out of scope for the DNS PRIVate Exchange (DPRIVE) Working Group under its current charter. 🙅‍♀️

This document describes two profiles in Section 4 that give different levels of privacy assurance: an opportunistic privacy profile and an out-of-band key-pinned privacy profile. 🎀 A future document based on [TLS-DTLS-PROFILES] is expected to describe more privacy profiles for DNS over both TLS and DTLS. 👑

An earlier draft described a way to upgrade a DNS-over-TCP connection into a DNS-over-TLS session, basically "STARTTLS for DNS." 🙃 To keep things simpler, this doc now only uses a well-known port to signal TLS use and drops the upgrade approach entirely. The upgrade approach no longer appears here, and the doc now focuses only on using a well-known port for DNS over TLS. 💜

2. Key Words 🔑

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 🌸

3. Establishing and Managing DNS-over-TLS Sessions 🧚

3.1. Session Initiation 🦋

By default, a DNS server that supports DNS over TLS MUST listen for and accept TCP connections on port 853, unless it has mutual agreement with its clients to use a port other than 853 for DNS over TLS. To use a port other than 853, both clients and servers would need a configuration option in their software. ⚙️

By default, a DNS client that wants privacy from DNS over TLS with a particular server MUST establish a TCP connection to port 853 on that server, unless it has mutual agreement with the server to use a port other than port 853 for DNS over TLS. That other port MUST NOT be port 53, but it MAY come from the "first-come, first-served" port range. 🚫 The reason port 53 is off the table is to keep it simple to decide whether TLS is in use and to reduce the risk of downgrade attacks. The first data exchange on this TCP connection MUST be the client and server starting a TLS handshake using the procedure described in [RFC5246]. 🤝

DNS clients and servers MUST NOT use port 853 to carry cleartext DNS messages. DNS clients MUST NOT send, and DNS servers MUST NOT respond to, cleartext DNS messages on any port used for DNS over TLS (including, for example, after a failed TLS handshake).

⚠️ Mixing protected and unprotected data causes significant security issues, which is why TCP connections on a port a server designates for DNS over TLS are reserved purely for encrypted communications. Hard boundary, no exceptions 💀

DNS clients SHOULD remember server IP addresses that don't support DNS over TLS, including after timeouts, connection refusals, and TLS handshake failures. They should not ask those servers for DNS over TLS again for a reasonable period (such as one hour per server). DNS clients following an out-of-band key-pinned privacy profile (Section 4.2) MAY be more aggressive about retrying DNS-over-TLS connection failures. 🔁

3.2. TLS Handshake and Authentication 🤝

Once the DNS client connects over TCP to the well-known port for DNS over TLS, it moves on to the TLS handshake [RFC5246], following the best practices in [BCP195]. 💖

The client will then authenticate the server, if required. This document doesn't propose any new authentication ideas. ✨ Depending on the privacy profile in use (Section 4), the DNS client may choose not to require authentication of the server, or it may make use of a trusted Subject Public Key Info (SPKI) Fingerprint pin set. 🧐

Once TLS negotiation finishes, the connection is encrypted and protected from eavesdropping. 🔒🎉

3.3. Transmitting and Receiving Messages 📨

All messages (requests and responses) in the established TLS session MUST use the two-octet length field described in Section 4.2.2 of [RFC1035]. For efficiency, DNS clients and servers SHOULD pass the two-octet length field, and the message described by that length field, to the TCP layer at the same time (e.g., in a single "write" system call). This makes it more likely that all the data goes out in a single TCP segment ([RFC7766], Section 8). 🚀

To cut down on latency, clients SHOULD pipeline multiple queries over a TLS session. When a DNS client sends multiple queries to a server, it should not wait for an outstanding reply before sending the next query ([RFC7766], Section 6.2.1.1). 🏃‍♀️💨

Pipelined responses can arrive out of order, so clients MUST match responses to outstanding queries on the same TLS connection using the Message ID. If the response contains a Question Section, the client MUST match the QNAME, QCLASS, and QTYPE fields. Getting this matching wrong can cause serious interoperability problems ([RFC7766], Section 7). 🧩🫶

3.4. Connection Reuse, Close, and Reestablishment ✨

okay so DNS clients that use library functions like getaddrinfo() and gethostbyname() are known to open and close TCP connections for every single DNS query 💀. to avoid a pile of extra TCP connections that each carry just one query, clients SHOULD reuse a single TCP connection to the recursive resolver 🫶. or they may prefer to use UDP to a DNS-over-TLS-enabled caching resolver on the same machine, and that caching resolver then uses a system-wide TCP connection to the recursive resolver 🧚.

to amortize the TCP and TLS setup costs (aka spread them out so they don't hurt as much 💅), clients and servers SHOULD NOT immediately close a connection after each response. instead, clients and servers SHOULD reuse existing connections for later queries as long as they have sufficient resources 🌸. sometimes that means they need to keep idle connections open for a while ⏳.

proper management of established and idle connections is a big deal for the healthy operation of a DNS server 👑. an implementor of DNS over TLS SHOULD follow the best practices for DNS over TCP described in [RFC7766], bc failing to do so can lead to resource exhaustion and denial of service 💀. not it being the reason the server crashes 🙈.

the era of [RFC1035] clients and servers is known for having really bad TCP connection management, which is so relatable 😭. but this document says that successfully negotiating TLS shows that both parties are willing to keep idle DNS connections open 🔒. this holds no matter what timeouts or other recommendations exist for DNS over TCP without TLS. in other words, software implementing this protocol is assumed to support idle, persistent connections and be ready to manage multiple, potentially long-lived TCP connections 💜.

this document doesn't give specific recommendations for idle connection timeout values 🤷‍♀️. clients and servers should reuse and/or close connections depending on how many resources they have available. timeouts may be longer during quiet periods and shorter during busy ones 🌈. current work in this area may also help DNS-over-TLS clients and servers pick useful timeout values [RFC7828] [TDNS] ✨.

clients and servers that keep idle connections open MUST be robust to termination of an idle connection by either party 🫧. just like regular DNS over TCP, DNS servers MAY close the connection at any time (maybe because of resource constraints) 🦋. and just like regular DNS over TCP, clients MUST handle abrupt closes and be prepared to reestablish connections and/or retry queries 🔁.

when reestablishing a DNS-over-TCP connection that got terminated (see [RFC7766]), TCP Fast Open [RFC7413] is super helpful 🚀. and this really underlines the rule from Section 3.2 that only encrypted DNS data gets sent on a DNS-over-TLS port 🔐. so when using TCP Fast Open, the client and server MUST immediately initiate or resume a TLS handshake, and cleartext DNS MUST NOT be exchanged 🙅‍♀️. DNS servers SHOULD enable fast TLS session resumption [RFC5077], and this SHOULD be used when reestablishing connections 💖.

when closing a connection, DNS servers SHOULD use the TLS close-notify request to shift TCP TIME-WAIT state over to the clients 🎀. more requirements and guidance for optimizing DNS over TCP live in [RFC7766], so go check that out too 📚.

4. Usage Profiles

this protocol is flexible enough to handle several different use cases 🧩. this document defines two usage profiles: (1) opportunistic privacy, and (2) out-of-band key-pinned authentication, which can give you stronger privacy guarantees if the client has a trusted relationship with a DNS server that supports TLS 🔑. more methods of authentication will be defined in a forthcoming document [TLS-DTLS-PROFILES] 👀.

4.1. Opportunistic Privacy Profile

okay so opportunistic privacy is kinda like SMTP opportunistic security [RFC7435] 💌. you don't require privacy, but you want it whenever it's possible 🌷.

with opportunistic privacy, a client might hear about a TLS-enabled recursive DNS resolver from an untrusted source 🕵️‍♀️. one example flow: the client uses the DHCP DNS server option [RFC3646] to find the IP address of a TLS-enabled recursive resolver, then tries DNS over TLS on port 853 🍓. with a DNS server found that way, the client might or might not validate the resolver. those choices maximize availability and performance, but they leave the client open to on-path attacks that strip away privacy 😬.

opportunistic privacy can be used by any current client, but it only gives privacy when there are no on-path active attackers 🛡️.

4.2. Out-of-Band Key-Pinned Privacy Profile

this profile is for environments where a trust relationship already exists between DNS clients and servers 🤝. examples are stub-to-recursive in enterprise networks, actively maintained contractual service relationships, or a client using a public DNS resolver 🏢. the result is that the client gets strong guarantees about the privacy of its DNS data, because it only connects to servers it can authenticate 🔐✨. operators of a DNS-over-TLS service in this profile are expected to provide pins that are specific to the service being pinned (so, public keys belonging directly to the end entity, or to a service-specific private certificate authority (CA)), and not a public key or keys from a generic public CA 💅.

in this profile, clients authenticate servers by matching a set of SPKI Fingerprints, in a way that's analogous to what's described in [RFC7469] 🧁. with this out-of-band key-pinned privacy profile, client administrators SHOULD deploy a backup pin along with the primary pin, for the reasons explained in [RFC7469] 🗝️. a backup pin is especially helpful during a key rollover, so a server operator doesn't have to coordinate key transitions with every client at the same time 😮‍💨. after a key change on the server, an updated pin set SHOULD be distributed to all clients in some secure way, to prep for the next key rollover 🌟. the mechanism for an out-of-band pin set update is out of scope for this document 🙅‍♀️.

a client like this will only use DNS servers that have an SPKI Fingerprint pin set provided 📌. having a trusted, pre-deployed pin set lets the client detect and prevent person-in-the-middle and downgrade attacks 🚫.

BUT, a configured DNS server may be temporarily unavailable while the network is being configured 🥺. for example, clients on networks that require web-based login may depend on DNS interception and spoofing for that authentication 🙃. techniques like the ones used by DNSSEC-trigger [DNSSEC-TRIGGER] MAY be used during network configuration, with the intent of transitioning to the designated DNS provider after authentication 🌉. the user MUST be alerted whenever possible that DNS is not private during this bootstrap 🚨.

⚠️ bestie, the user MUST be alerted whenever it's possible that DNS isn't private during bootstrap. don't skip this one!

upon a successful TLS connection and handshake, the client computes the SPKI Fingerprints for the public keys in the validated server's certificate chain (or in the raw public key, if the server provides that instead) 🔍. if a computed fingerprint exactly matches one of the configured pins, the client keeps going with the connection as normal ✅. otherwise, the client MUST treat the SPKI validation failure as a non-recoverable error 🛑. Appendix A has a detailed example of how this authentication could be done in practice 📖.

implementations of this privacy profile MUST support calculating a fingerprint as the SHA-256 [RFC6234] hash of the DER-encoded ASN.1 representation of the SPKI of an X.509 certificate 🔢. implementations MUST support representing a SHA-256 fingerprint as a base64-encoded character string [RFC4648] 🔤. additional fingerprint types MAY also be supported 🌈.

5. Performance Considerations

okay performance time 🏎️. DNS over TLS adds latency at session startup 🐢. it also needs extra state (memory) and more processing (CPU) 🧠.

Latency: compared to UDP, DNS over TCP needs an additional round-trip time (RTT) of latency to set up a TCP connection ⏱️. TCP Fast Open [RFC7413] can get rid of that RTT when there's info from prior connections ⚡. the TLS handshake adds another two RTTs of latency 😩. clients and servers should support connection keepalive (reuse) and out-of-order processing to amortize connection setup costs 💫. fast TLS connection resumption [RFC5077] cuts the setup delay even further, and it also keeps the DNS server from having to store per-client session state 🧚‍♀️.

TLS False Start [TLS-FALSESTART] can also reduce latency in certain situations 🏃‍♀️. implementations that support TLS False Start need to be aware that it puts extra constraints on how you use TLS, on top of the ones stated in [BCP195] 📏. it is unsafe to use False Start if your implementation and deployment don't follow these specific requirements 🙅‍♀️. see [TLS-FALSESTART] for the full details of those extra constraints 🔗.

State: connection-oriented TCP needs extra state kept at the server, in both the kernel and the application 🗄️. state requirements are a big concern on servers with lots of clients, although memory-optimized TLS only adds a modest amount of state over TCP 💅. smaller timeout values reduce the number of concurrent connections, and servers can preemptively close connections when resource limits are exceeded 🧹.

Processing: TLS encryption algorithms use slightly more CPU 🔥. servers can choose to refuse new DNS-over-TLS clients if processing limits are exceeded 🚧.

Number of connections: to minimize state on DNS servers and cut down connection startup time, clients SHOULD minimize the creation of new TCP connections 🎯. a local DNS request aggregator (a particular type of forwarder) lets a single active DNS-over-TLS connection go from any given client computer to its server 🪄. more guidance is in [RFC7766] 📚.

a full performance evaluation is out of scope for this spec 🙃. a more detailed look at the performance implications of DNS over TLS (and DNS over TCP) is in [TDNS] and [RFC7766] 🤓.

6. IANA Considerations

IANA has added the following value to the "Service Name and Transport Protocol Port Number Registry" in the System Range 🗂️. the registry for that range requires IETF Review or IESG Approval [RFC6335]. such a review was requested through the early allocation process [RFC7120] for the well-known TCP port in this document 🎀.

IANA has reserved the same port number over UDP for the proposed DNS-over-DTLS protocol [DNSoD] 🦋.

 Service Name           domain-s
 Port Number            853
 Transport Protocol(s)  TCP/UDP
 Assignee               IESG
 Contact                IETF Chair
 Description            DNS query-response protocol run over TLS/DTLS
 Reference              This document

7. Design Evolution 🦋

Okay so earlier drafts of this doc wanted an upgrade-based approach to start a TLS session 🧚. The client would say it was interested in TLS by setting a "TLS OK" bit in the Extensions Mechanisms for DNS (EDNS(0)) flags field, and the server would say yes by replying with the TLS OK bit set ✨

Since we assume the client doesn't want to reveal (leak) any info before the channel is secured 🙈, we proposed a "dummy query" clients could send for this. The query name was STARTTLS, the query type was TXT, and the query class was CH 💅

The TLS OK signaling approach had pros AND cons, bestie 💀. The big pro is that clients and servers could negotiate TLS. If the server is too busy, or just doesn't want to give TLS service to a certain client, it can respond negatively to the TLS probe 🙅‍♀️. A bonus is that servers could collect info on adoption of DNS over TLS (via the TLS OK bit in queries) before anything got implemented and deployed 📊. Another pro we expected was that DNS over TLS would work over port 53. So no need to "waste" another port and deploy new firewall rules on middleboxes 🧱

But at the same time, it was unclear whether middleboxes would even pass the TLS OK bit, since the EDNS0 flags field hasn't changed in years 😬. Another con is that the TLS OK bit might make downgrade attacks easy, and they'd look exactly like broken middleboxes 🚨. Performance-wise, the upgrade-based approach also had the downside of adding 1xRTT of extra latency for the dummy query 🐢

After that, DNS over DTLS was proposed separately 🌈. DNS over DTLS claimed it could work over port 53, but only because a non-DTLS server reads a DNS-over-DTLS query as a response. The non-DTLS server sees the QR flag set to 1. Technically it works, but it seems unfortunate and maybe even undesirable 🙃

DNS over both TLS and DTLS can benefit from a single well-known port and avoid extra latency and queries getting misread as responses 👑

8. Security Considerations 🛡️

Okay, security time, and this part is SERIOUS 😤. DNS over TLS is designed to address the privacy risks that come from the ability to eavesdrop on DNS messages. It does NOT address other security issues in DNS, and there are a bunch of residual risks that could affect how well it protects privacy 👀

  1. There are known attacks on TLS, like person-in-the-middle and protocol downgrade 😱. These are general attacks on TLS and not specific to DNS over TLS, so check the TLS RFCs for the deets on these security issues. Clients and servers MUST adhere to the TLS implementation recommendations and security considerations of [BCP195]. DNS clients keeping track of servers known to support TLS lets them detect downgrade attacks 🕵️‍♀️. For servers with no connection history and no apparent support for TLS, depending on their privacy profile and privacy requirements, clients may choose to (a) try another server when one is available, (b) continue without TLS, or (c) refuse to forward the query 🤷‍♀️.
  2. Middleboxes [RFC3234] are in some networks and have been known to mess with normal DNS resolution 🙄. Using a designated port for DNS over TLS should avoid that interference. In general, clients that try TLS and fail can either fall back on unencrypted DNS or wait and retry later, depending on their privacy profile and privacy requirements 🔁.
  3. Any DNS protocol interactions done in the clear can be modified by a person-in-the-middle attacker 😈. For example, unencrypted queries and responses might happen over port 53 between a client and server. For this reason, clients MAY discard cached information about server capabilities that was advertised in cleartext 🗑️.
  4. This document does not, by itself, specify ideas to resist known traffic analysis or side-channel leaks 🫣. Even with encrypted messages, a well-positioned party may be able to glean certain details from analyzing message timings and sizes. Clients and servers may consider using 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 enough to mitigate such an attack 🧩. Padding will, however, form part of more complex mitigations for traffic-analysis attacks that are likely to be developed over time 🔮. Implementors who can offer flexibility in how padding can be used may be in a better position to enable those mitigations to be deployed in the future 💜.

As noted earlier, DNSSEC and DNS over TLS are independent and fully compatible protocols, each solving different problems 🫶. Using one does not diminish the need for or the usefulness of the other ✨.

9. References 📚

Okay bestie, the references are split into section 9.1 (normative) and section 9.2 (informative) 🎀.

9.1. Normative References 💖

9.2. Informative References 🌸

Appendix A. Out-of-Band Key-Pinned Privacy Profile Example

okay so this appendix is a worked example of the out-of-band key-pinned privacy profile, and it's built on a minimal pin set with just two pins 🎀✨

Picture a DNS client that's been set up with the key-pinned privacy profile by a network service. The pin set has two pins, and if we write them the way HTTP Public Key Pinning (HPKP) [RFC7469] does, they look like this:

  • pin-sha256="FHkyLhvI0n70E47cJlRTamTrnYVcsYdjUGbr79CfAVI="
  • pin-sha256="dFSY3wdPU8L0u/8qECuz5wtlSgnorYV2f66L6GNQg6w="

The client also has its expected DNS server addresses saved, maybe 192.0.2.3 and 2001:db8::2:4 💅

The client connects to one of those addresses on TCP port 853 and kicks off the TLS handshake. In this example that means TLS 1.2 with a Diffie-Hellman key exchange 🔥 The server sends a certificate message holding three certificates (A, B, and C), and it signs the ServerKeyExchange message properly with the public key from certificate A.

Now the client takes the SHA-256 digest of the SPKI in cert A and checks it against both pins. If either one matches, verification passes, the client keeps the TLS connection, and it can send its very first DNS query 😭🫶

If neither pin matches cert A's SPKI, the client checks that cert A was actually issued by cert B. If that holds, it takes the SHA-256 digest of cert B's SPKI and compares it against both pins. A match on either one means verification succeeds. If that still doesn't work out, it confirms that B was issued by C and then compares the pins against the digest of C's SPKI 👑

Heads up: if none of the SPKIs in the cryptographically valid chain match any pin in the pin set, the client closes the connection with an error and marks that IP address as failed. No second chances for that address 💀

Acknowledgments

The authors would like to thank Stephane Bortzmeyer, John Dickinson, Brian Haberman, Christian Huitema, Shumon Huque, Simon Joseffson, Kim-Minh Kaplan, Simon Kelley, Warren Kumari, John Levine, Ilari Liusvaara, Bill Manning, George Michaelson, Eric Osterweil, Jinmei Tatuya, Tim Wicinski, and Glen Wiley for reviewing this specification. They also thank Nikita Somaiya for early work on this idea 🌈💜

Work by Zi Hu, Liang Zhu, and John Heidemann on this document is partially sponsored by the U.S. Dept. of Homeland Security (DHS) Science and Technology Directorate, Homeland Security Advanced Research Projects Agency (HSARPA), Cyber Security Division, BAA 11-01-RIKA and Air Force Research Laboratory, Information Directorate under agreement number FA8750-12-2-0344, and contract number D08PC75599 🦋

Contributors

The below individuals contributed significantly to the document 🧚

Sara Dickinson Sinodun Internet Technologies Magdalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom

Email: sara@sinodun.com URI: http://sinodun.com

Daniel Kahn Gillmor ACLU 125 Broad Street, 18th Floor New York, NY 10004 United States

Authors' Addresses

Zi Hu USC/Information Sciences Institute 4676 Admiralty Way, Suite 1133 Marina del Rey, CA 90292 United States

Phone: +1-213-587-1057 Email: zihu@outlook.com

Liang Zhu USC/Information Sciences Institute 4676 Admiralty Way, Suite 1133 Marina del Rey, CA 90292 United States

Phone: +1-310-448-8323 Email: liangzhu@usc.edu

John Heidemann USC/Information Sciences Institute 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292 United States

Phone: +1-310-822-1511 Email: johnh@isi.edu

Allison Mankin Independent

Phone: +1-301-728-7198 Email: Allison.mankin@gmail.com

Duane Wessels Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States

Phone: +1-703-948-3200 Email: dwessels@verisign.com

Paul Hoffman ICANN

Email: paul.hoffman@icann.org

📦 where this page comes from