<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.36 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-barnes-dane-uks-00" category="info" updates="6698, 7250, 7671">

  <front>
    <title abbrev="DANE UKS">Unknown Key-Share Attacks on DNS-based Authentications of Named Entities (DANE)</title>

    <author initials="R." surname="Barnes" fullname="Richard Barnes">
      <organization>Mozilla</organization>
      <address>
        <email>rlb@ipv.sx</email>
      </address>
    </author>
    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization>Mozilla</organization>
      <address>
        <email>martin.thomson@gmail.com</email>
      </address>
    </author>
    <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
      <organization>Mozilla</organization>
      <address>
        <email>ekr@rftm.com</email>
      </address>
    </author>

    <date year="2016"/>

    
    
    

    <abstract>


<t>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.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>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)
<xref target="RFC5280"/> <xref target="RFC6125"/>.</t>

<t>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 <xref target="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.</t>

<t>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.</t>

</section>
<section anchor="attack-synopsis" title="Attack Synopsis">

<t>In an unknown key-share attack <xref target="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.</t>

<t>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
<xref target="W3C.CR-cors-20130129"/>.</t>

<t>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.</t>

<t>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 <xref target="RFC7671"/> <xref target="RFC7250"/>.</t>

<t><list style="symbols">
  <t>If the client does not verify the identity in the server’s certificate (as
recommended in Section 5.1 of <xref target="RFC7671"/>), then an attacker can induce the
client to accept an unintended identity for the server.</t>
  <t>If the client allows the use of raw public keys in TLS <xref target="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.</t>
</list></t>

<section anchor="attack-example" title="Attack Example">

<t>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.</t>

<figure><artwork><![CDATA[
  Client                         attack.example.com  victim.example.org
                                                         pubkey=P
    |-_443._tcp.attack.example.com TLSA?-->|                 |
    |<------TLSA usage=3 key=P-------------|                 |
    |                                                        |
    |<===============TLS==================>|<======TLS======>|
]]></artwork></figure>

<t>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 <xref target="RFC2818"/> or <xref target="RFC6125"/> certificate checks, but
<xref target="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.</t>

<t>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.</t>

<t>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.</t>

<figure><artwork><![CDATA[
  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========================>|
]]></artwork></figure>

<t>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.</t>

<t>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 <xref target="RFC6962"/> logs.</t>

</section>
</section>
<section anchor="mitigations" title="Mitigations">

<t>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.</t>

<t>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 <xref target="I-D.ietf-tls-tls13"/>).</t>

<t>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:</t>

<t><list style="symbols">
  <t>Even when using DANE, TLS clients MUST verify that the certificate presented
by the server represents the name they expect to connect to <xref target="RFC6125"/>.</t>
  <t>End entity certificates asserted through DANE (usage=3, selector=0) MUST
contain the name being authenticated.</t>
  <t>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.  <list style="symbols">
      <t>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, 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.</t>
    </list></t>
  <t>When using a public key asserted through DANE (usage=3, selector=1) the server
MUST NOT accept the use of raw public keys.</t>
  <t>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.</t>
</list></t>

<t>(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.)</t>

<t>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.</t>

<texttable>
      <ttcol align='center'>Usage</ttcol>
      <ttcol align='center'>Selector</ttcol>
      <ttcol align='center'>Match</ttcol>
      <ttcol align='center'>Raw key?</ttcol>
      <ttcol align='center'>Name must appear…</ttcol>
      <c>CA(2)</c>
      <c>*</c>
      <c>*</c>
      <c>n/a</c>
      <c>In TLS EE</c>
      <c>EE(3)</c>
      <c>Full(0)</c>
      <c>Exact(0)</c>
      <c>MAY*</c>
      <c>In TLSA or TLS EE</c>
      <c>EE(3)</c>
      <c>Full(0)</c>
      <c>Hash(1/2)</c>
      <c>MUST NOT</c>
      <c>In TLS EE</c>
      <c>EE(3)</c>
      <c>SPKI(1)</c>
      <c>*</c>
      <c>MUST NOT</c>
      <c>In TLS EE</c>
</texttable>

<t>The risk of unknown key-share attacks can also be removed by carrying DANE
records in the TLS handshake, as suggested in
<xref target="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.</t>

<t>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
<xref target="RFC6066"/> or the HTTP Host header field <xref target="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.</t>

<t>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.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This document makes no request of IANA.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>This section intentionally left blank.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>

<reference anchor="UKS" >
  <front>
    <title>Unknown Key-Share Attacks on the Station-to-Station (STS) Protocol</title>
    <author initials="S." surname="Blake-Wilson">
      <organization></organization>
    </author>
    <author initials="A." surname="Menezes">
      <organization></organization>
    </author>
    <date year="1999"/>
  </front>
  <seriesInfo name="Lecture Notes in Computer Science 1560, Springer, pp. 154–170" value=""/>
</reference>




<reference  anchor='RFC5280' target='http://www.rfc-editor.org/info/rfc5280'>
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials='D.' surname='Cooper' fullname='D. Cooper'><organization /></author>
<author initials='S.' surname='Santesson' fullname='S. Santesson'><organization /></author>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></author>
<author initials='S.' surname='Boeyen' fullname='S. Boeyen'><organization /></author>
<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></author>
<author initials='W.' surname='Polk' fullname='W. Polk'><organization /></author>
<date year='2008' month='May' />
<abstract><t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet.  An overview of this approach and model is provided as an introduction.  The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms.  Standard certificate extensions are described and two Internet-specific extensions are defined.  A set of required certificate extensions is specified.  The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions.  An algorithm for X.509 certification path validation is described.  An ASN.1 module and examples are provided in the appendices.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5280'/>
<seriesInfo name='DOI' value='10.17487/RFC5280'/>
</reference>



<reference  anchor='RFC6125' target='http://www.rfc-editor.org/info/rfc6125'>
<front>
<title>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)</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'><organization /></author>
<author initials='J.' surname='Hodges' fullname='J. Hodges'><organization /></author>
<date year='2011' month='March' />
<abstract><t>Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions.   [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6125'/>
<seriesInfo name='DOI' value='10.17487/RFC6125'/>
</reference>



<reference  anchor='RFC6698' target='http://www.rfc-editor.org/info/rfc6698'>
<front>
<title>The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></author>
<author initials='J.' surname='Schlyter' fullname='J. Schlyter'><organization /></author>
<date year='2012' month='August' />
<abstract><t>Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used.  This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers.  This requires matching improvements in TLS client software, but no change in TLS server software.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6698'/>
<seriesInfo name='DOI' value='10.17487/RFC6698'/>
</reference>



<reference  anchor='RFC7671' target='http://www.rfc-editor.org/info/rfc7671'>
<front>
<title>The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance</title>
<author initials='V.' surname='Dukhovni' fullname='V. Dukhovni'><organization /></author>
<author initials='W.' surname='Hardaker' fullname='W. Hardaker'><organization /></author>
<date year='2015' month='October' />
<abstract><t>This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience.  It also contains guidance for implementers, operators, and protocol developers who want to use DANE records.</t></abstract>
</front>
<seriesInfo name='RFC' value='7671'/>
<seriesInfo name='DOI' value='10.17487/RFC7671'/>
</reference>



<reference  anchor='RFC7250' target='http://www.rfc-editor.org/info/rfc7250'>
<front>
<title>Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
<author initials='P.' surname='Wouters' fullname='P. Wouters' role='editor'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig' role='editor'><organization /></author>
<author initials='J.' surname='Gilmore' fullname='J. Gilmore'><organization /></author>
<author initials='S.' surname='Weiler' fullname='S. Weiler'><organization /></author>
<author initials='T.' surname='Kivinen' fullname='T. Kivinen'><organization /></author>
<date year='2014' month='June' />
<abstract><t>This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS).  The new certificate type allows raw public keys to be used for authentication.</t></abstract>
</front>
<seriesInfo name='RFC' value='7250'/>
<seriesInfo name='DOI' value='10.17487/RFC7250'/>
</reference>



<reference  anchor='RFC2818' target='http://www.rfc-editor.org/info/rfc2818'>
<front>
<title>HTTP Over TLS</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2000' month='May' />
<abstract><t>This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='2818'/>
<seriesInfo name='DOI' value='10.17487/RFC2818'/>
</reference>



<reference  anchor='RFC6962' target='http://www.rfc-editor.org/info/rfc6962'>
<front>
<title>Certificate Transparency</title>
<author initials='B.' surname='Laurie' fullname='B. Laurie'><organization /></author>
<author initials='A.' surname='Langley' fullname='A. Langley'><organization /></author>
<author initials='E.' surname='Kasper' fullname='E. Kasper'><organization /></author>
<date year='2013' month='June' />
<abstract><t>This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves.  The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.</t><t>Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.</t></abstract>
</front>
<seriesInfo name='RFC' value='6962'/>
<seriesInfo name='DOI' value='10.17487/RFC6962'/>
</reference>



<reference anchor='I-D.ietf-tls-tls13'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>

<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>

<date month='September' day='22' year='2016' />

<abstract><t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tls-tls13-16' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-16.txt' />
</reference>




    </references>

    <references title='Informative References'>





<reference anchor='W3C.CR-cors-20130129'
           target='http://www.w3.org/TR/2013/CR-cors-20130129'>
<front>
<title>Cross-Origin Resource Sharing</title>

<author initials='A.' surname='Kesteren' fullname='Anne van Kesteren'>
    <organization />
</author>

<date month='January' day='29' year='2013' />
</front>

<seriesInfo name='World Wide Web Consortium CR' value='CR-cors-20130129' />
<format type='HTML' target='http://www.w3.org/TR/2013/CR-cors-20130129' />
</reference>



<reference anchor='I-D.ietf-tls-dnssec-chain-extension'>
<front>
<title>A DANE Record and DNSSEC Authentication Chain Extension for TLS</title>

<author initials='M' surname='Shore' fullname='Melinda Shore'>
    <organization />
</author>

<author initials='R' surname='Barnes' fullname='Richard Barnes'>
    <organization />
</author>

<author initials='S' surname='Huque' fullname='Shumon Huque'>
    <organization />
</author>

<author initials='W' surname='Toorop' fullname='Willem Toorop'>
    <organization />
</author>

<date month='July' day='7' year='2016' />

<abstract><t>This draft describes a new TLS extension for transport of a DNS record set serialized with the DNSSEC signatures needed to authenticate that record set.  The intent of this proposal is to allow TLS clients to perform DANE authentication of a TLS server certificate without needing to perform additional DNS record lookups. It will typically not be used for general DNSSEC validation of TLS endpoint names.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tls-dnssec-chain-extension-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-dnssec-chain-extension-01.txt' />
</reference>



<reference  anchor='RFC6066' target='http://www.rfc-editor.org/info/rfc6066'>
<front>
<title>Transport Layer Security (TLS) Extensions: Extension Definitions</title>
<author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'><organization /></author>
<date year='2011' month='January' />
<abstract><t>This document provides specifications for existing TLS extensions.  It is a companion document for RFC 5246, &quot;The Transport Layer Security (TLS) Protocol Version 1.2&quot;.  The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6066'/>
<seriesInfo name='DOI' value='10.17487/RFC6066'/>
</reference>



<reference  anchor='RFC7230' target='http://www.rfc-editor.org/info/rfc7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the &quot;http&quot; and &quot;https&quot; Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='7230'/>
<seriesInfo name='DOI' value='10.17487/RFC7230'/>
</reference>




    </references>


<section anchor="acknowledgements" title="Acknowledgements">

<t>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.</t>

</section>


  </back>
</rfc>

