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)
                        draft-barnes-dane-uks-00

Abstract

   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 http://datatracker.ietf.org/drafts/current/.

   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



Barnes, et al.           Expires April 12, 2017                 [Page 1]


Internet-Draft                  DANE UKS                    October 2016


   (http://trustee.ietf.org/license-info) 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Attack Synopsis . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Attack Example  . . . . . . . . . . . . . . . . . . . . .   3
   3.  Mitigations . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

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.






Barnes, et al.           Expires April 12, 2017                 [Page 2]


Internet-Draft                  DANE UKS                    October 2016


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].

   o  If the client does not verify the identity in the server's
      certificate (as recommended in Section 5.1 of [RFC7671]), then an
      attacker can induce the client to accept an unintended identity
      for the server.

   o  If the client allows the use of raw public keys in TLS [RFC7250],
      then it will not receive any indication of the server's identity
      in the TLS channel, and is thus unable to check that the server's
      identity is as intended.

2.1.  Attack Example

   In the natural version of this attack, the attacker convinces a
   client that it has a TLS connection to attack.example.com (operated
   by the attacker) when in reality, it has a TLS connection to
   victim.example.org (operated by some innocent third party).
   victim.example.org 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 attack.example.com authorizing
   victim.example.com's public key.






Barnes, et al.           Expires April 12, 2017                 [Page 3]


Internet-Draft                  DANE UKS                    October 2016


   Client                         attack.example.com  victim.example.org
                                                          pubkey=P
     |-_443._tcp.attack.example.com TLSA?-->|                 |
     |<------TLSA usage=3 key=P-------------|                 |
     |                                                        |
     |<===============TLS==================>|<======TLS======>|

   When the client connects to attack.example.com, the attacker forwards
   the TLS messages to victim.example.org, 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 attack.example.com, the client
   accepts the connection as coming from attack.example.com - even
   though it's actually to victim.example.org.

   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.

  Client                           attack.example.com victim.example.org
IP=192.0.2.2                         IP=198.51.100.1     IP=192.0.2.1
                                                           pubkey=P
    |-_443._tcp.attack.example.com TLSA?-->|                  |
    |<------TLSA usage=3 key=P------------ |                  |
    |                                      |                  |
    |------ attack.example.com A? -------->|                  |
    |<------------- 192.0.2.1 -------------|                  |
    |<============================TLS========================>|

   As before, the client connects to victim.example.org, thinking it is
   attack.example.com, with the result that any data retrieved is same
   origin to attack.example.com 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.





Barnes, et al.           Expires April 12, 2017                 [Page 4]


Internet-Draft                  DANE UKS                    October 2016


   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:

   o  Even when using DANE, TLS clients MUST verify that the certificate
      presented by the server represents the name they expect to connect
      to [RFC6125].

   o  End entity certificates asserted through DANE (usage=3,
      selector=0) MUST contain the name being authenticated.

   o  When using a full EE certificate provided directly in a TLSA
      record (usage=3, selector=0, match=0), clients MUST verify that
      the certificate represents the name they expect to connect to.  If
      so, the client MAY accept the use of raw public keys in the
      resulting TLS connection.  When raw public keys are used in TLS,
      the client MUST verify that the EE certificate presented in the
      TLSA record is validly self-signed.

      *  It is only strictly necessary for the client to verify that the
         EE certificate is correctly self-signed when the certificate is
         asserted through DANE and raw public keys are used in the TLS
         handshake.  When the certificate is presented in the handshake,



Barnes, et al.           Expires April 12, 2017                 [Page 5]


Internet-Draft                  DANE UKS                    October 2016


         the name is authenticated by the Finished MAC or
         CertificateVerify signature (as noted above), so the client
         only needs to check that the name is correct.

   o  When using a public key asserted through DANE (usage=3,
      selector=1) the server MUST NOT accept the use of raw public keys.

   o  In general, TLS clients MUST NOT use raw public keys in TLS unless
      the client is identifying the server by its public key directly,
      as opposed to a name.

   (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      |
     |       |          |           |          |                     |
     | EE(3) | SPKI(1)  |     *     | 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.



Barnes, et al.           Expires April 12, 2017                 [Page 6]


Internet-Draft                  DANE UKS                    October 2016


   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", draft-ietf-tls-tls13-16 (work in progress),
              September 2016.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
              DOI 10.17487/RFC2818, May 2000,
              <http://www.rfc-editor.org/info/rfc2818>.

   [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,
              <http://www.rfc-editor.org/info/rfc5280>.

   [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, <http://www.rfc-editor.org/info/rfc6125>.







Barnes, et al.           Expires April 12, 2017                 [Page 7]


Internet-Draft                  DANE UKS                    October 2016


   [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, <http://www.rfc-editor.org/info/rfc6698>.

   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
              Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
              <http://www.rfc-editor.org/info/rfc6962>.

   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., 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, <http://www.rfc-editor.org/info/rfc7250>.

   [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, <http://www.rfc-editor.org/info/rfc7671>.

   [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",
              draft-ietf-tls-dnssec-chain-extension-01 (work in
              progress), July 2016.

   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
              Extensions: Extension Definitions", RFC 6066,
              DOI 10.17487/RFC6066, January 2011,
              <http://www.rfc-editor.org/info/rfc6066>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

   [W3C.CR-cors-20130129]
              Kesteren, A., "Cross-Origin Resource Sharing", World Wide
              Web Consortium CR CR-cors-20130129, January 2013,
              <http://www.w3.org/TR/2013/CR-cors-20130129>.




Barnes, et al.           Expires April 12, 2017                 [Page 8]


Internet-Draft                  DANE UKS                    October 2016


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: rlb@ipv.sx


   Martin Thomson
   Mozilla

   Email: martin.thomson@gmail.com


   Eric Rescorla
   Mozilla

   Email: ekr@rftm.com



























Barnes, et al.           Expires April 12, 2017                 [Page 9]