Network Working Group R. Barnes
Internet-Draft M. Thomson
Updates: 6698, 7250, 7671 (if approved) E. Rescorla
Intended status: Informational Mozilla
Expires: April 12, 2017 October 9, 2016

Unknown Key-Share Attacks on DNS-based Authentications of Named Entities (DANE)


Unknown key-share attacks are a class of attacks that allow an attacker to deceive one peer of a secure communication as to the identity of the remote peer. When used with traditional, PKI-based authentication, TLS-based applications are generally safe from unknown key-share attacks. DNS-based Authentication of Named Entities (DANE), however, proposes that applications perform a different set of checks as part of authenticating a TLS connection. As a result, DANE as currently specified is likely to lead to unknown key-share attacks when clients support DANE for authentication. We describe these risks and some simple mitigations.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 12, 2017.

Copyright Notice

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 ( in effect on the date of publication of this document. Please review these documents carefully, as 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

TLS is very widely used to secure application protocols, and in particular to authenticate the use of domain names for TLS servers. Traditionally, TLS has authenticated a server’s use of a domain name by having the server present a certificate containing that name, then having the client verify that the certificate attests to the name of the server to which it was trying to connect (in addition to verifying that the certificate is issued by a trusted authority) [RFC5280] [RFC6125].

DNS-based Authentication of Named Entities (DANE) makes modifications to this process in order to accommodate the use of DNSSEC-signed assertions acquired outside of TLS instead of certificates provided in TLS [RFC6698]. This change, together with some recommended changes to TLS usage and operational practices, make it possible for an attacker to mount unknown key-share attacks against a TLS client that supports DANE.

In this document, we describe how unknown key-share attacks arise when a client supports DANE in the manner recommended by the DANE specifications, and we propose some changes to DANE that remove these risks.

2. Attack Synopsis

In an unknown key-share attack [UKS], a malicious participant in a protocol claims to control a key that is in reality controlled by some other actor. The victim client will believe that he is talking to the attacker, when in reality he is talking to the victim server.

While this attack may sound less severe than attacks that let the attacker claim an identity that is not his own, it can be used to subvert identity-based access controls in the same way as an impersonation attack. For example, a malicious web site could use an unknown key-share attack to make a cross-origin request appear to be same-origin, circumventing security checks on cross-origin requests [W3C.CR-cors-20130129].

TLS with PKI-based authentication is not vulnerable to unknown key-share attacks because the server explicitly states its intended identity in its certificate and the client verifies that the server’s asserted identity matches the client’s intent.

When the client acquires DANE information out of band with respect to TLS, it risks exposing itself to unknown key-share attacks if it takes some additional steps recommended by the DANE specifications [RFC7671] [RFC7250].

2.1. Attack Example

In the natural version of this attack, the attacker convinces a client that it has a TLS connection to (operated by the attacker) when in reality, it has a TLS connection to (operated by some innocent third party). need not even be using DANE; it may have a ordinary Web PKI certificate. In order to mount this attack, the attacker provisions a TLSA record for authorizing’s public key.

    | TLSA?-->|                 |
    |<------TLSA usage=3 key=P-------------|                 |
    |                                                        |

When the client connects to, the attacker forwards the TLS messages to, which responds with its ordinary certificate. With a non-DANE TLS connection, this would be detected by the [RFC2818] or [RFC6125] certificate checks, but [RFC7671] specifically instructs the client not to look at the name in the certificate when DANE is in use. Instead, because since the public key matches the TLSA record for, the client accepts the connection as coming from – even though it’s actually to

Depending on the application being run over TLS, this attack can lead to different application-layer vulnerabilities. For example, if the client uses the same TLS client authentication with both servers, the attacker can convince the victim client to dereference a link authorizing some action on the victim server, for instance transfering money from the victim client to the attacker.

With a little more sophistication, the attacker can use this type of attack to violate firewall restrictions. Consider the case where the victim client and the victim server are behind the same firewall but the victim server is unreachable to the attacker. The attacker can exploit the client to recover content from the victim server by combining this UKS attack with a DNS rebinding attack.

IP=                         IP=     IP=
    | TLSA?-->|                  |
    |<------TLSA usage=3 key=P------------ |                  |
    |                                      |                  |
    |------ A? -------->|                  |
    |<------------- -------------|                  |

As before, the client connects to, thinking it is, with the result that any data retrieved is same origin to and therefore is accessible to script from the attacker. This attack was already possible with HTTP resources, but the UKS described here extends it to HTTPS resources.

There are several subtleties to note about this attack. First, it requires the attacker to provide the client with two IP addresses in sequence; first its true IP address (so it can retrieve the attacker’s page), not shown, and then the victim server’s IP address so that the client can contact the victim. This is known as DNS rebinding. Second, the attacker must somehow retrieve the victim server’s public key (because it cannot contact the server directly). One possible way to do this is through the Certificate Transparency [RFC6962] logs.

3. Mitigations

At a high level, the mitigation to these attacks is to ensure that when two peers negotiate a secure connection, they agree not just on what public key the server is using, but also what name.

For TLS, this means that the server MUST assert some intended identity (or identities) by including that identity under a signature with its private key. In practice, there are two ways that this can happen. Either the DANE record can contain a self-signed EE certificate containing the identity, or the server can present a certificate in the handshake that contains the name, where it is transitively authenticated via the Finished MAC (and the CertificateVerify in TLS 1.3 [I-D.ietf-tls-tls13]).

In order to avoid vulnerability to unknown key-share attacks, then, TLS clients MUST verify that the server’s name appears in one of these two places:

(Note that TLSA usages 0 and 1 are inherently not vulnerable to unknown key-share attacks, since they are added checks on top of the normal PKI-based authentication.)

The following table summarizes the above requirements for when raw public keys may be used and where the server’s name must appear. “MAY*” indicates that the client MAY use raw public keys, but needs to perform some additional checks.

Usage Selector Match Raw key? Name must appear…
CA(2) * * n/a In TLS EE
EE(3) Full(0) Exact(0) MAY* In TLSA or TLS EE
EE(3) Full(0) Hash(1/2) MUST NOT In TLS EE

The risk of unknown key-share attacks can also be removed by carrying DANE records in the TLS handshake, as suggested in [I-D.ietf-tls-dnssec-chain-extension]. In this case, the client MUST verify that the name for which DANE information is provided is the name it intended to connect to.

The directionality of these mitigations is important (server asserts; client verifies). One might think that the opposite order would also work, i.e., for the client to send a desired identity (e.g., in Server Name Indication [RFC6066] or the HTTP Host header field [RFC7230]) and the server to verify it before accepting the handshake. However, servers today display a wide variety of behaviors when presented with unknown SNI values (as would happen during an unknown key share attack). While some fail safely, some reroute to a default hostname. Thus, it is not possible for the client to ensure that the server would fail safe.

In the longer term, DANE’s susceptibility to unknown key-share attacks could also be mitigated with a re-design of TLSA records themselves. If DANE records included (1) the names being vouched for, and (2) a signature by the key pair being asserted over the contents of the record, then DANE would effectively always be in the “EE / Full / Exact” case above, since the DANE record would have the same semantics as a self-signed certificate (at least in the ways that matter here). Then it would be safe to use all DANE cases with raw public keys, since no name checks would need to be done at the TLS layer.

4. IANA Considerations

This document makes no request of IANA.

5. Security Considerations

This section intentionally left blank.

6. References

6.1. Normative References

[I-D.ietf-tls-tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Internet-Draft draft-ietf-tls-tls13-16, September 2016.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R. and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012.
[RFC6962] Laurie, B., Langley, A. and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013.
[RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S. and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014.
[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015.
[UKS] Blake-Wilson, S. and A. Menezes, "Unknown Key-Share Attacks on the Station-to-Station (STS) Protocol", Lecture Notes in Computer Science 1560, Springer, pp. 154–170 , 1999.

6.2. Informative References

[I-D.ietf-tls-dnssec-chain-extension] Shore, M., Barnes, R., Huque, S. and W. Toorop, "A DANE Record and DNSSEC Authentication Chain Extension for TLS", Internet-Draft draft-ietf-tls-dnssec-chain-extension-01, July 2016.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014.
[W3C.CR-cors-20130129] Kesteren, A., "Cross-Origin Resource Sharing", World Wide Web Consortium CR CR-cors-20130129, January 2013.

Appendix A. Acknowledgements

The considerations in this document are largely based on Martin Thomson and Eric Rescorla’s work with Karthik Bhargavan on the analogous problem in DTLS-SRTP.

Authors' Addresses

Richard Barnes Mozilla EMail:
Martin Thomson Mozilla EMail:
Eric Rescorla Mozilla EMail: